From christer.holmberg@ericsson.com Sat Feb 1 09:36:12 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8201A03EC for ; Sat, 1 Feb 2014 09:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrn0f_lHMmam for ; Sat, 1 Feb 2014 09:36:10 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DDAFD1A0395 for ; Sat, 1 Feb 2014 09:36:09 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-ff-52ed3085a7c7 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 56.F8.10875.5803DE25; Sat, 1 Feb 2014 18:36:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Sat, 1 Feb 2014 18:36:04 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft initial submission: draft-holmberg-clue-datachannel-00 Thread-Index: Ac8fc83rGs7683oDQi+KR/2wIWixSw== Date: Sat, 1 Feb 2014 17:36:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D153633@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+JvjW6rwdsgg6PTJSz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE3/ulgLXjBW/PryhLGBcTNjFyMnh4SAicTpec1QtpjEhXvr 2boYuTiEBA4xShy++5YVwlnEKPHybx97FyMHB5uAhUT3P22QBhEBZYmjm/vZQGxhAVeJr4cv MEHEvSTebvvPCGHrSUy8dgushkVARWL7y2msIDavgK/E+2u72UFsRqDF30+tAetlFhCXuPVk PhPEQQISS/acZ4awRSVePv7HCmErSnx8tY8Rol5HYsHuT2wQtrbEsoWvmSHmC0qcnPmEZQKj 8CwkY2chaZmFpGUWkpYFjCyrGNlzEzNz0ssNNzECw/jglt+6OxhPnRM5xCjNwaIkzvvhrXOQ kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYYT8Nv0g6cIlf+Zk7IXOTvvqzl5as/FRV1oqaP pq9xTvVkOXMjpHjZ5IlHnC5bFpxR6FIN00lX+XD/8swJHcG8/1Lb70vdFYp9Lm8jmKEiYNXw 8dGv/W+nT3M2fCD79eBvT7sZJm9NJ1wXUn1+aM76rjef/6zeofToKq9O50UdM2XOfW1y68KU WIozEg21mIuKEwF+g5ceMQIAAA== Subject: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 Feb 2014 17:36:12 -0000 Hi, I put together an initial draft for describing the CLUE data channel. I realize that text is still needed, but now it will be easier to document = whatever we agree to, identity open issues etc. Regards, Christer= From pkyzivat@alum.mit.edu Sun Feb 2 12:44:49 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412541A010A for ; Sun, 2 Feb 2014 12:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gkJNrBaDuoz for ; Sun, 2 Feb 2014 12:44:47 -0800 (PST) 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 925AF1A0106 for ; Sun, 2 Feb 2014 12:44:47 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta08.westchester.pa.mail.comcast.net with comcast id MYDF1n0061wpRvQ58YkiQc; Sun, 02 Feb 2014 20:44:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id MYki1n00a3ZTu2S3eYki5m; Sun, 02 Feb 2014 20:44:42 +0000 Message-ID: <52EEAE3A.5000802@alum.mit.edu> Date: Sun, 02 Feb 2014 15:44:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D153633@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=1391373882; bh=6kwNfrg7Uhw+PeM5x5bHqkzhOEpIf9W8fiDF2bqFb+Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=j/YdzlypvTeNxswgbx51zWq7aTlYK+kVzieKhL7UEPbvkLJEOSgzWwXiaYoXeC1NA P1VxvmW1wKs0JGMcv1HA0iobBg9a1Rho1Z2x1VT8X4uTdHGEYhMQJAVFNWVGKs4d8D DtKpR7hwKJG+vInkjJKynb1a1ka5uzRTqMykIHBOy2Zzg+h6k3DQap8JAz+O5axHpq Q4+XV7BKZcL9qaW0z+249NdDbzySh+wFS4OsFTbbRC2eUIfD4mUt1kPPykI/WA08xO DAPIMz0ASnfDJkC0dWey0hSJjg5rSYPt1lCA8f7OV+rp6v0SaSyFfyXjmCQFIgHlIu 0egoWgPGouj8Q== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 02 Feb 2014 20:44:49 -0000 Christer, Thanks for getting this started, even though there is still much to decide. It is pretty early to do much reviewing of this, but here are a few things that I noted while reading it: Abstract/Introduction: This document specifies how the usage of the Stream Control Transmission Protocol (SCTP) on top of the Datagram Transport Layer Security (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol messages between CLUE entities. The above is an incomplete sentence. (... specified how the ... (what?)). One possible rewording: This document specifies how to use the Stream Control Transmission Protocol (SCTP) on top of the Datagram Transport Layer Security (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol messages between CLUE entities. Section 2: CLUE data channel refers to the SCTPoDTLS connection that is established between two CLUE entities in order to transport CLUE messages. IMO this isn't quite correct. - for one thing, for whatever reason, a single instantiation of SCTP is called an "association" rather than "connection". - CLUE doesn't use an entire SCTP association. It only uses one (ore maybe two) webrtc data channels. Also, in principle, there could be more than one SCTP association in the session. If so, for CLUE there will be a particular one of those associations that hosts the clue channel(s). I'm inclined to think, for purposes of terminology, that: - A "CLUE data channel" is a specific usage of a webrtc data channel (or whatever name that eventually gets - hopefully one without "webrtc" in it). Or, if we are trying to refer to webrtc stuff, that it corresponds to a matched pair of streams (one in each direction). - We may also want a term for the SCTP association hosting the clue data channel. E.g., "CLUE SCTPoDTLS association". - If we decide we want to use two channels, then we will probably want to agree that they are both on the same association. Section 3.2.1: CLUE entities MUST establish two uni-directional STCP streams between themselves, one for CLUE messages sent in each direction. This seems incomplete. How about: CLUE entities MUST establish a pair of uni-directional STCP streams, one in each direction, having identical stream IDs, between themselves. These are then used to send CLUE messages in both directions. Thanks, Paul On 2/1/14 12:36 PM, Christer Holmberg wrote: > > Hi, > > I put together an initial draft for describing the CLUE data channel. > > I realize that text is still needed, but now it will be easier to document whatever we agree to, identity open issues etc. > > Regards, > > Christer > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Sun Feb 2 23:52:32 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E251A0079 for ; Sun, 2 Feb 2014 23:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7RZWkghzk16 for ; Sun, 2 Feb 2014 23:52:31 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6A51A006B for ; Sun, 2 Feb 2014 23:52:30 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-42-52ef4ab92c16 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F7.FF.23809.9BA4FE25; Mon, 3 Feb 2014 08:52:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Mon, 3 Feb 2014 08:52:24 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 Thread-Index: AQHPIFed74gUOEYWPkmt8447BhqKT5qjGLag Date: Mon, 3 Feb 2014 07:52:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D154B81@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52EEAE3A.5000802@alum.mit.edu> In-Reply-To: <52EEAE3A.5000802@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje5Or/dBBhs2i1vsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGzrc97AVPxCuenb3C3MC4U6iLkZNDQsBE ounpAmYIW0ziwr31bF2MXBxCAocYJU72/GeGcBYBOaevsnYxcnCwCVhIdP/TBmkQEfCU2PFx ClizsECQxO37d1kg4sESi/ZvZYewjSQWnprFAtLKIqAicXI6L0iYV8BX4kBjJ1irkEC+xM3n N8HKOQV0JC6e+wQ2hhHonu+n1jCB2MwC4hK3nsxngrhTQGLJnvNQN4tKvHz8D+wyCQFFieX9 chDlOhILdn9ig7C1JZYtfM0MsVZQ4uTMJywTGEVnIZk6C0nLLCQts5C0LGBkWcXInpuYmZNe brSJERgHB7f8Vt3BeOecyCFGaQ4WJXHeD2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSgED fIq/245X1dschFPb9qQa5kd9MKgXZqxZ/eN2/Z+zDLUvvks58B3LmRawZEn5Ms0iq4fzeQ67 hfAtdH6RN+/y6ppcXpGQg3yTr9ossOrNWL/CNCvLePe6mQIZ1p6bz1k2Xl38w8jP5mKspNws Ce5pW0IqbgTU/39u0164ilnS0/J7n9nHxTlKLMUZiYZazEXFiQD5piQuUQIAAA== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 07:52:32 -0000 Hi Paul, Thanks for your comments! See inline. > Abstract/Introduction: > > This document specifies how the usage of the Stream Control > Transmission Protocol (SCTP) on top of the Datagram Transport Layer > Security (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol > messages between CLUE entities. > > The above is an incomplete sentence. (... specified how the ...=20 > (what?)). One possible rewording: > > This document specifies how to use the Stream Control > Transmission Protocol (SCTP) on top of the Datagram Transport Layer > Security (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol > messages between CLUE entities. Correct. > Section 2: > > CLUE data channel refers to the SCTPoDTLS connection that is > established between two CLUE entities in order to transport CLUE > messages. > > IMO this isn't quite correct. > > - for one thing, for whatever reason, a single instantiation of SCTP > is called an "association" rather than "connection". Correct. > - CLUE doesn't use an entire SCTP association. It only uses one > (ore maybe two) webrtc data channels. That is actually an issue which I have raised on the MMUSIC list. Currently= the sctp-sdp draft only seems to allow negotiation of one usage per associ= ation. > Also, in principle, there could be more than one SCTP association in the = session. If so, for CLUE there will be a particular one of those associatio= ns that hosts the clue channel(s). Correct. There can be multiple SCTP associations on top of the same DTLS as= sociation. > I'm inclined to think, for purposes of terminology, that: > > - A "CLUE data channel" is a specific usage of a webrtc data channel > (or whatever name that eventually gets - hopefully one without > "webrtc" in it). Or, if we are trying to refer to webrtc stuff, > that it corresponds to a matched pair of streams (one in each > direction). I tried to avoid "webrtc" on purpose, and the only reference is for the PPI= D values. However, I think it will be good to have some text about webrtc interoperab= ility somewhere, in order to justify some of the technical choices. > - We may also want a term for the SCTP association hosting the clue > data channel. E.g., "CLUE SCTPoDTLS association". Well, in my opinion that is the definition of the CLUE data channel :) > - If we decide we want to use two channels, then we will probably > want to agree that they are both on the same association. Yes. > Section 3.2.1: > > CLUE entities MUST establish two uni-directional STCP streams between > themselves, one for CLUE messages sent in each direction. > > This seems incomplete. How about: > > CLUE entities MUST establish a pair of uni-directional STCP streams, > one in each direction, having identical stream IDs, between > themselves. These are then used to send CLUE messages in both > directions. Yes. Thanks! Regards, Christer From pkyzivat@alum.mit.edu Mon Feb 3 07:05:30 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0936A1A00F9 for ; Mon, 3 Feb 2014 07:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.972 X-Spam-Level: X-Spam-Status: No, score=0.972 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.972] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXvlJruwnFRd for ; Mon, 3 Feb 2014 07:05:28 -0800 (PST) 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 A4D661A0130 for ; Mon, 3 Feb 2014 07:05:28 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id Mq8m1n0061c6gX858r5Uf5; Mon, 03 Feb 2014 15:05:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id Mr5U1n00G3ZTu2S3jr5UNs; Mon, 03 Feb 2014 15:05:28 +0000 Message-ID: <52EFB038.5000203@alum.mit.edu> Date: Mon, 03 Feb 2014 10:05:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52EEAE3A.5000802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D154B81@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D154B81@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=1391439928; bh=gPdbDa+LU7VvSi8X7idW0+tOKV8w4JuUReeOX9V57WE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fbIAGsloZ53hxxci9yqYMmKVsgn1tfE6n+FMrRfrISlP4r362xixnXa/i+TUzGxBH +ucuQhHEaxDxf+CLpHb+NzRkThn3RyWg0uGr9ztCC9rr5YyNfGtU1j2ydaVaKNyleA +ZWyq38pp5Sjuq3j//h1LrSF43AyRW3v2J2d/zskTfUM5qYFjnk8pLd8UyicqZjQzJ 3JghkCQg3DWYVi9NWmGos8mZH2nq595mvZQK8QeTzXc5Z4siZnqGo4/nRd2Xm5rQg3 cfXSBblp3ks4eRQgqfF+187P4dJT9fAqgHsmih4xyKaCscn9To4P85I88Vgg84qr4B FIqEr1RE+tu+Q== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 15:05:30 -0000 Inline On 2/3/14 2:52 AM, Christer Holmberg wrote: > Hi Paul, > > Thanks for your comments! See inline. > >> Abstract/Introduction: >> >> This document specifies how the usage of the Stream Control >> Transmission Protocol (SCTP) on top of the Datagram Transport Layer >> Security (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol >> messages between CLUE entities. >> >> The above is an incomplete sentence. (... specified how the ... >> (what?)). One possible rewording: >> >> This document specifies how to use the Stream Control >> Transmission Protocol (SCTP) on top of the Datagram Transport Layer >> Security (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol >> messages between CLUE entities. > > Correct. > >> Section 2: >> >> CLUE data channel refers to the SCTPoDTLS connection that is >> established between two CLUE entities in order to transport CLUE >> messages. >> >> IMO this isn't quite correct. >> >> - for one thing, for whatever reason, a single instantiation of SCTP >> is called an "association" rather than "connection". > > Correct. > >> - CLUE doesn't use an entire SCTP association. It only uses one >> (ore maybe two) webrtc data channels. > > That is actually an issue which I have raised on the MMUSIC list. Currently the sctp-sdp draft only seems to allow negotiation of one usage per association. I agree this is unclear. What I have inferred is that what the sctpmap line is negotiating is a usage for the collection of all the sctp streams within the association. But the text is certainly confusing about that. Calling this a "media-subtype suggests some relationship with mime types. But that doesn't fit well. In the absence of an SDP mechanism for negotiating individual streams or channels, I think this would probably name a documented mechanism for assigning those, such as the rtcweb data channel protocol. >> Also, in principle, there could be more than one SCTP association in the session. If so, for CLUE there will be a particular one of those associations that hosts the clue channel(s). > > Correct. There can be multiple SCTP associations on top of the same DTLS association. > >> I'm inclined to think, for purposes of terminology, that: >> >> - A "CLUE data channel" is a specific usage of a webrtc data channel >> (or whatever name that eventually gets - hopefully one without >> "webrtc" in it). Or, if we are trying to refer to webrtc stuff, >> that it corresponds to a matched pair of streams (one in each >> direction). > > I tried to avoid "webrtc" on purpose, and the only reference is for the PPID values. My preferred way of avoiding the use of webrtc here is for them to change their terminology to simply call it a data channel. :-) > However, I think it will be good to have some text about webrtc interoperability somewhere, in order to justify some of the technical choices. > >> - We may also want a term for the SCTP association hosting the clue >> data channel. E.g., "CLUE SCTPoDTLS association". > > Well, in my opinion that is the definition of the CLUE data channel :) You think the "CLUE data channel" is defined as an entire SCTP association??? IIUC we have been talking about an *abstraction* called a "CLUE Channel" (rather than "CLUE Data Channel"). And we are trying to map it onto specific technology. We have decided to map it onto a particular instance of (webrtc) Data Channel. And each webrtc data channel exists within a particular SCTPoDTLS association. Thanks, Paul >> - If we decide we want to use two channels, then we will probably >> want to agree that they are both on the same association. > > Yes. > >> Section 3.2.1: >> >> CLUE entities MUST establish two uni-directional STCP streams between >> themselves, one for CLUE messages sent in each direction. >> >> This seems incomplete. How about: >> >> CLUE entities MUST establish a pair of uni-directional STCP streams, >> one in each direction, having identical stream IDs, between >> themselves. These are then used to send CLUE messages in both >> directions. > > Yes. > > Thanks! > > Regards, > > Christer > > From christer.holmberg@ericsson.com Mon Feb 3 08:23:28 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1044E1A01A5 for ; Mon, 3 Feb 2014 08:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guCN1ar0QNmU for ; Mon, 3 Feb 2014 08:23:26 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B9D4C1A011F for ; Mon, 3 Feb 2014 08:23:25 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-d9-52efc27cb36a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CE.63.10875.C72CFE25; Mon, 3 Feb 2014 17:23:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Mon, 3 Feb 2014 17:23:24 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 Thread-Index: AQHPIPFgTcCdrdGNXkeVQyRG8uCbJJqjs+ZR Date: Mon, 3 Feb 2014 16:23:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D156580@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52EEAE3A.5000802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D154B81@ESESSMB209.ericsson.se>, <52EFB038.5000203@alum.mit.edu> In-Reply-To: <52EFB038.5000203@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvjW7NofdBBsdfGFrsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldG59sDTAV3VCtmvLzC2MC4SraLkYNDQsBE 4sEL1y5GTiBTTOLCvfVsXYxcHEIChxgl/r19ywzhLGKUuN+2jwmkgU3AQqL7nzZIg4iAp8SO j1OYQWxhgSCJafvOskLEgyXuHdjJCGEbSfz88o0dxGYRUJGYeXQWmM0r4Csx6fJBJoj5lxkl Hl/tZgFJcAroSLx4+BTMZgS66PupNUwgNrOAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP1YIW1Gi /WkDI0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm 5qSXG25iBMbCwS2/dXcwnjoncohRmoNFSZz3w1vnICGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MfVWH15g92397mryY1Iwt1tGtitt7plX8OullpMJ8saBm11/ZgIeT5Dq+csyf3x6RfeHC g5n/9wW0mJq+b5n0ffvH39PUrCNXtG+21b49I0RhodrcVYH7GK9Kl2+6yO3e/3uT0oWbGw+7 TLe31NY+PTk4wPA865xs+wVH07ssfFhlz2pFrppkrMRSnJFoqMVcVJwIAGXAVvRTAgAA Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 16:23:28 -0000 Hi, >>>> Section 2: >>>> >>> CLUE data channel refers to the SCTPoDTLS connection that is >>> established between two CLUE entities in order to transport CLUE >>> messages. >>> >>> IMO this isn't quite correct. >>> >>> - for one thing, for whatever reason, a single instantiation of SCTP >>> is called an "association" rather than "connection". >> >> Correct. >> >>> - CLUE doesn't use an entire SCTP association. It only uses one >>> (ore maybe two) webrtc data channels. >> >> That is actually an issue which I have raised on the MMUSIC list. Curren= tly the sctp-sdp draft only seems to allow negotiation of one usage per ass= ociation. > > I agree this is unclear. > > What I have inferred is that what the sctpmap line is negotiating is a > usage for the collection of all the sctp streams within the association. There are two things that I think need to be possible: 1) Indicate the SCTP associations on top of the DTLS connection 2) For each SCTP association, indicate the usages At the moment the draft does seem to allow 1), but for each SCTP associatio= n it only allows one usage. > But the text is certainly confusing about that. Calling this a > "media-subtype suggests some relationship with mime types. But that > doesn't fit well. In the absence of an SDP mechanism for negotiating > individual streams or channels, I think this would probably name a > documented mechanism for assigning those, such as the rtcweb data > channel protocol. Even with that, it is unclear what the type value (e.g. webrtc-datachannel)= in the sctpmap attribute really is, how such values are supposed to be reg= istered, etc. But, let's have THAT discussion on the MMUSIC list :) >>> Also, in principle, there could be more than one SCTP association in th= e session. If so, for CLUE there will be a particular one of those associat= ions that hosts the clue channel(s). >> >> Correct. There can be multiple SCTP associations on top of the same DTLS= association. >> >>> I'm inclined to think, for purposes of terminology, that: >>> >>> - A "CLUE data channel" is a specific usage of a webrtc data channel >>> (or whatever name that eventually gets - hopefully one without >>> "webrtc" in it). Or, if we are trying to refer to webrtc stuff, >>> that it corresponds to a matched pair of streams (one in each >>> direction). >> >> I tried to avoid "webrtc" on purpose, and the only reference is for the = PPID values. > > My preferred way of avoiding the use of webrtc here is for them to > change their terminology to simply call it a data channel. :-) We can suggest that :) However, I have been working on some text for the next version of the CLUE = draft, which talks about the SCTP considerations being selected in order to= be compatible with the rtcweb data channel. >> However, I think it will be good to have some text about webrtc interope= rability somewhere, in order to justify some of the technical choices. >> >>> - We may also want a term for the SCTP association hosting the clue >>> data channel. E.g., "CLUE SCTPoDTLS association". >> >> Well, in my opinion that is the definition of the CLUE data channel :) > > You think the "CLUE data channel" is defined as an entire SCTP > association??? No. So, the text probably needs to be modified that we are talking about th= e SCTP association used to transport the CLUE protocol, but clarify that th= e association may also have other usages. That also means that we need to be careful about how/if the SCTP associaton= affects the CLUE session. Because, even if a CLUE session is terminated, t= here may be other reasons to keep the SCTP assiciation alive, etc. Regards, Christer IIUC we have been talking about an *abstraction* called a "CLUE Channel" (rather than "CLUE Data Channel"). And we are trying to map it onto specific technology. We have decided to map it onto a particular instance of (webrtc) Data Channel. And each webrtc data channel exists within a particular SCTPoDTLS association. Thanks, Paul >> - If we decide we want to use two channels, then we will probably >> want to agree that they are both on the same association. > > Yes. > >> Section 3.2.1: >> >> CLUE entities MUST establish two uni-directional STCP streams betwee= n >> themselves, one for CLUE messages sent in each direction. >> >> This seems incomplete. How about: >> >> CLUE entities MUST establish a pair of uni-directional STCP streams, >> one in each direction, having identical stream IDs, between >> themselves. These are then used to send CLUE messages in both >> directions. > > Yes. > > Thanks! > > Regards, > > Christer > > From pkyzivat@alum.mit.edu Mon Feb 3 09:42:13 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA291A019F for ; Mon, 3 Feb 2014 09:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KDGnnqqMTuO for ; Mon, 3 Feb 2014 09:42:11 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC991A0122 for ; Mon, 3 Feb 2014 09:42:11 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id Mq4u1n00516LCl053tiBeL; Mon, 03 Feb 2014 17:42:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id MtiB1n0083ZTu2S3StiBvf; Mon, 03 Feb 2014 17:42:11 +0000 Message-ID: <52EFD4F3.8050608@alum.mit.edu> Date: Mon, 03 Feb 2014 12:42:11 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52EEAE3A.5000802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D154B81@ESESSMB209.ericsson.se>, <52EFB038.5000203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D156580@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D156580@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=1391449331; bh=F8HmdakCwUtb5JK5nsipM0YqEMX76km2frQx6TM5G+0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mTNxxhOhUVBlpAw4qd7CTNL9jQdFuQti3S72mTEL0TUD8RcT8m3PXpTdxF7z7i+zM ZD5Frb5pJpwnUyzNnFZxbL1LKgP/Pu4+KoaJoaS/e7bVFYd7ARpIYv7OSG8WMjJDfU 1c21EaQqAc/ptENR0HSBUsQx4hqApMlY7JysxRzIJ/cl+8DC7YjuGGvHkt6KxqNHmt x2tCkULjmfQY3FW/HioKjVJsHq3o7xcbQ98hRiFsvRDHt0T+3nwYJNdWLmTiOhKhk8 4rnr1wi/WS9yylNzVFPMMrXhORYul7bRLPFRGwp4t7K9bHMSpuiCDjNtG421p8acF/ qyS8NKEKpeT5Q== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 17:42:13 -0000 On 2/3/14 11:23 AM, Christer Holmberg wrote: > > Hi, > >>>>> Section 2: >>>>> >>>> CLUE data channel refers to the SCTPoDTLS connection that is >>>> established between two CLUE entities in order to transport CLUE >>>> messages. >>>> >>>> IMO this isn't quite correct. >>>> >>>> - for one thing, for whatever reason, a single instantiation of SCTP >>>> is called an "association" rather than "connection". >>> >>> Correct. >>> >>>> - CLUE doesn't use an entire SCTP association. It only uses one >>>> (ore maybe two) webrtc data channels. >>> >>> That is actually an issue which I have raised on the MMUSIC list. Currently the sctp-sdp draft only seems to allow negotiation of one usage per association. >> >> I agree this is unclear. >> >> What I have inferred is that what the sctpmap line is negotiating is a >> usage for the collection of all the sctp streams within the association. > > There are two things that I think need to be possible: > > 1) Indicate the SCTP associations on top of the DTLS connection > 2) For each SCTP association, indicate the usages > > At the moment the draft does seem to allow 1), but for each SCTP association it only allows one usage. And that is what the Ejzak draft addresses. >> But the text is certainly confusing about that. Calling this a >> "media-subtype suggests some relationship with mime types. But that >> doesn't fit well. In the absence of an SDP mechanism for negotiating >> individual streams or channels, I think this would probably name a >> documented mechanism for assigning those, such as the rtcweb data >> channel protocol. > > Even with that, it is unclear what the type value (e.g. webrtc-datachannel) in the sctpmap attribute really is, how such values are supposed to be registered, etc. > > But, let's have THAT discussion on the MMUSIC list :) Yes. >>>> Also, in principle, there could be more than one SCTP association in the session. If so, for CLUE there will be a particular one of those associations that hosts the clue channel(s). >>> >>> Correct. There can be multiple SCTP associations on top of the same DTLS association. >>> >>>> I'm inclined to think, for purposes of terminology, that: >>>> >>>> - A "CLUE data channel" is a specific usage of a webrtc data channel >>>> (or whatever name that eventually gets - hopefully one without >>>> "webrtc" in it). Or, if we are trying to refer to webrtc stuff, >>>> that it corresponds to a matched pair of streams (one in each >>>> direction). >>> >>> I tried to avoid "webrtc" on purpose, and the only reference is for the PPID values. >> >> My preferred way of avoiding the use of webrtc here is for them to >> change their terminology to simply call it a data channel. :-) > > We can suggest that :) This is confusing because of the overlap with the Ejzak draft. I have asked him to make the change, and he said he would (months ago). But I guess that doesn't get the change in other drafts that talk about it. > However, I have been working on some text for the next version of the CLUE draft, which talks about the SCTP considerations being selected in order to be compatible with the rtcweb data channel. > > >>> However, I think it will be good to have some text about webrtc interoperability somewhere, in order to justify some of the technical choices. >>> >>>> - We may also want a term for the SCTP association hosting the clue >>>> data channel. E.g., "CLUE SCTPoDTLS association". >>> >>> Well, in my opinion that is the definition of the CLUE data channel :) >> >> You think the "CLUE data channel" is defined as an entire SCTP >> association??? > > No. So, the text probably needs to be modified that we are talking about the SCTP association used to transport the CLUE protocol, but clarify that the association may also have other usages. > > That also means that we need to be careful about how/if the SCTP associaton affects the CLUE session. Because, even if a CLUE session is terminated, there may be other reasons to keep the SCTP assiciation alive, etc. Yes. If we have trouble with the clue channel, we may want to specify a "reset". But in general the reset should not involve resetting the association, because that would impact other channel usage. So we might just say that a reset means to close the channel and renegotiate a new clue channel over the same association. But if the association is broken to the extent that new channels can't be negotiated, then it makes sense to reset the association. (I doubt we want to specify *this* much detail, but we may need to say something.) Thanks, Paul > Regards, > > Christer > > > > > > IIUC we have been talking about an *abstraction* called a "CLUE Channel" > (rather than "CLUE Data Channel"). And we are trying to map it onto > specific technology. We have decided to map it onto a particular > instance of (webrtc) Data Channel. And each webrtc data channel exists > within a particular SCTPoDTLS association. > > Thanks, > Paul > >>> - If we decide we want to use two channels, then we will probably >>> want to agree that they are both on the same association. >> >> Yes. >> >>> Section 3.2.1: >>> >>> CLUE entities MUST establish two uni-directional STCP streams between >>> themselves, one for CLUE messages sent in each direction. >>> >>> This seems incomplete. How about: >>> >>> CLUE entities MUST establish a pair of uni-directional STCP streams, >>> one in each direction, having identical stream IDs, between >>> themselves. These are then used to send CLUE messages in both >>> directions. >> >> Yes. >> >> Thanks! >> >> Regards, >> >> Christer >> >> > > From internet-drafts@ietf.org Mon Feb 3 13:43:55 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B941A025B; Mon, 3 Feb 2014 13:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaIWDuDw2rV3; Mon, 3 Feb 2014 13:43:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C22231A025C; Mon, 3 Feb 2014 13:43:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140203214353.1163.54011.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2014 13:43:53 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:43:56 -0000 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 : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-03.txt Pages : 50 Date : 2014-02-03 Abstract: This document provides an XML schema file for the definition of CLUE data model types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-data-model-schema-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-03 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 roberta.presta@unina.it Mon Feb 3 13:46:35 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D058B1A0248 for ; Mon, 3 Feb 2014 13:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CO9-bHnE59nr for ; Mon, 3 Feb 2014 13:46:33 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 97BE71A0232 for ; Mon, 3 Feb 2014 13:46:32 -0800 (PST) Received: from [127.0.0.1] (2-237-80-133.ip237.fastwebnet.it [2.237.80.133]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s13LkTh2006544 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 22:46:30 +0100 Message-ID: <52F00E35.8020001@unina.it> Date: Mon, 03 Feb 2014 22:46:29 +0100 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "clue@ietf.org" , Christian Groves Content-Type: multipart/alternative; boundary="------------050609030505020500060706" Cc: "clue@ietf.org" Subject: [clue] New Version Notification for draft-ietf-clue-data-model-schema-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 21:46:36 -0000 This is a multi-part message in MIME format. --------------050609030505020500060706 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Dear Christian, thank you for your review. We have just uploaded a new version of the draft we have updated on the basis of your feedback. Please find comments inline. Cheers, Roberta > Hello Simon and Roberta, > > Thanks for the updated draft. A few comments / questions: > > 1. Clause 1 - 3 paragraph indicates "a straw man proposal". As this is > now a WG draft I think that paragraph could be removed. > [RP] Removed. > 2. Clause 3 paragraph above XML - The text refers to > "I-D.romanow-clue-data-model", is it still relevant to refer to this > expired document given the framework is the main document? > [RP] Removed. > 3. Clause 3 - Capture Encoding type: The type has elements for > "captureParameters" and "encodingParameters". The framework doesn't > allow parameters to be returned in a configure so these should be > removed. > [RP] Removed. > 4. Clause 10.6 & 10.7 > > For the MCC captures a "composed" and "switched" element has been > added (10.7 & 10.8) as attributes. However there are no "composed" or > "switched" attributes in the framework. Is this a proposal to add them > back in? otherwise the two documents won't be aligned. 4a: > [RP] They are actually proposals. That has been explicitely mentioned in the new version of the draft. There is an example of how to use them in multiple content captures provided in the end. I will show the example in the upcoming design team meeting presentation. > Clause 10.6: Editorial nit: ...can be alternative a > single media... > [RP] Removed. > 5. Clause 10.11 Single > > I was at first confused by this as it wasn't in the framework and I > also confused it with the case MCC(VC1). Would it be possible to add a > note indicating that the MCC(VC1) case where the MCC contains a single > individual CaptureID is not the same as the use of . Maybe > rather than say "single" we could use "individual" for the element > name? Also during discussions it was also noted that it should be > possible to specify an MCC without any captureIDs. So the XML should > probably indicate "minoccurs="0". 6. > [RP] We have added text to specify that "single"/"individual" is just a proposal to mark *non*-multiple-content captures. We have put minOccurs = 0 for the capture IDs. > Clause 10.13 Priority: This is actually contained in the framework. So > the reference could be updated and I-D.groves-clue-capture-attr removed. > [RP] Reference removed. > 7. Clause 10.14 Language: As per above comment. Its now part of the > framework. [RP] Reference removed. > > 8. Clause 10.17 Related to: As per above. Its now part of the framework. [RP] Reference removed. > > 9. Clause 10.?? > > The CLUE framework clause 7.2.1.3 has the synchronisation identity. > This appears to be missing from the data model? > [RP] Added. > 10. Clause 11.1 AudioChannelFormat: We had a discussion on the list > previously > (http://www.ietf.org/mail-archive/web/clue/current/msg02778.html) > requirements regarding using an integer to indicate the format rather > than "mono", "stereo" etc. Should we update the framework and data > model to align with the requirements? > [RP] We will update it in the next version. > 11. Clause 12.1 Embeddedtext: This is included in clause 7.1.1.13 of > the framework. So the last two sentences could be removed. > [RP] Done. > 12. Clause 15.3: Is the media type needed here? The media type would > be associated with the individual captures. It seems like a duplication. > > [RP] We think it can be useful for rapidly discriminating between audio entries and video entries, but it is redundant. We will remove it. > 13. Clauses 16/17/18: With the decision to use SDP for encodings could > these sections be removed? > [RP] At least we have to list encoding identifiers in order to build encoding groups. Since we have prepared an example with some consideration about the max bandwidth, we have left them in that version. > Regards, Christian > > --------------050609030505020500060706 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Dear Christian,

thank you for your review.
We have just uploaded a new version of the draft we have updated on the basis of your feedback.
Please find comments inline.
Cheers,

Roberta

Hello Simon and Roberta,

Thanks for the updated draft. A few comments / questions:

1. Clause 1 - 3 paragraph indicates "a straw man proposal". As this is now a WG draft I think that paragraph could be removed.

[RP] Removed.
2. Clause 3 paragraph above XML - The text refers to "I-D.romanow-clue-data-model", is it still relevant to refer to this expired document given the framework is the main document?

[RP] Removed.
3. Clause 3 - Capture Encoding type: The type has elements for "captureParameters" and "encodingParameters". The framework doesn't allow parameters to be returned in a configure so these should be removed.

[RP] Removed.
4. Clause 10.6 & 10.7

For the MCC captures a "composed" and "switched" element has been added (10.7 & 10.8) as attributes. However there are no "composed" or "switched" attributes in the framework. Is this a proposal to add them back in? otherwise the two documents won't be aligned. 4a:

[RP] They are actually proposals. That has been explicitely mentioned in the new version of the draft. There is an example of how to use them in multiple content captures provided in the end.
I will show the example in the upcoming design team meeting presentation.
Clause 10.6: Editorial nit: ...can be alternative <remove "or"> a single media...

[RP] Removed.
5. Clause 10.11 Single

I was at first confused by this as it wasn't in the framework and I also confused it with the case MCC(VC1). Would it be possible to add a note indicating that the MCC(VC1) case where the MCC contains a single individual CaptureID is not the same as the use of <single>. Maybe rather than say "single" we could use "individual" for the element name? Also during discussions it was also noted that it should be possible to specify an MCC without any captureIDs. So the XML should probably indicate "minoccurs="0". 6.

[RP] We have added text to specify that "single"/"individual" is just a proposal to mark *non*-multiple-content captures. We have put minOccurs = 0 for the capture IDs.
Clause 10.13 Priority: This is actually contained in the framework. So the reference could be updated and I-D.groves-clue-capture-attr removed.

[RP] Reference removed.
7. Clause 10.14 Language: As per above comment. Its now part of the framework.
[RP] Reference removed.

8. Clause 10.17 Related to: As per above. Its now part of the framework.
[RP] Reference removed.

9. Clause 10.??

The CLUE framework clause 7.2.1.3 has the synchronisation identity. This appears to be missing from the data model?

[RP] Added.
10. Clause 11.1 AudioChannelFormat: We had a discussion on the list previously (http://www.ietf.org/mail-archive/web/clue/current/msg02778.html) requirements regarding using an integer to indicate the format rather than "mono", "stereo" etc. Should we update the framework and data model to align with the requirements?

[RP] We will update it in the next version.
11. Clause 12.1 Embeddedtext: This is included in clause 7.1.1.13 of the framework. So the last two sentences could be removed.

[RP] Done.
12. Clause 15.3: Is the media type needed here? The media type would be associated with the individual captures. It seems like a duplication.


[RP] We think it can be useful for rapidly discriminating between audio entries and video entries, but it is redundant. We will remove it.

13. Clauses 16/17/18: With the decision to use SDP for encodings could these sections be removed?

[RP] At least we have to list encoding identifiers in order to build encoding groups. Since we have prepared an example with some consideration about the max bandwidth, we have left them in that version.


Regards, Christian


--------------050609030505020500060706-- From mary.ietf.barnes@gmail.com Mon Feb 3 16:29:55 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C11A1A026A for ; Mon, 3 Feb 2014 16:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgN-YI2Dbqei for ; Mon, 3 Feb 2014 16:29:46 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 461A61A0264 for ; Mon, 3 Feb 2014 16:29:46 -0800 (PST) Received: by mail-yk0-f171.google.com with SMTP id 142so43284787ykq.2 for ; Mon, 03 Feb 2014 16:29:46 -0800 (PST) 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=YFw983748Tv+NihCCkyERXblOt163ETLpKdnjY4sD9Y=; b=MFAvtd3E+jTkaydQUeXSl0v5B0hD724Lp5fDOevbtyLgbOgfZXVrTtagS7FQ+7Qtgt i1VLEjp99/oZGqeAnGVL1tNgE0g1qxIWHDpoK5otlZs6Qoj4LJmcpiVizaAE4gQPRNKi FZfWonCDKKw6VIEgIEYCqyFDJnaPBsauJRXAaFLglSrj/9C2FKI0vuDccvbIsO6ulvhp jrmROq9dCssM32J/EnzQxeIfvvoTvi1U1jXyerIyKXNg42/PYHlhqK7s4EOI/OvNGz1T 4dxzh0K+9AwQpnBFXSsyDsN1eqGGsCQC431lt9npqMibcQxPJ8ODwj/HHiQKXbKMc6LY +Uwg== MIME-Version: 1.0 X-Received: by 10.236.122.165 with SMTP id t25mr35368124yhh.46.1391473785918; Mon, 03 Feb 2014 16:29:45 -0800 (PST) Received: by 10.170.46.143 with HTTP; Mon, 3 Feb 2014 16:29:45 -0800 (PST) Date: Mon, 3 Feb 2014 18:29:45 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf301b64dbb95aa004f189bcb4 Subject: [clue] Minutes: CLUE WG Virtual Interim Jan. 27, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 00:29:55 -0000 --20cf301b64dbb95aa004f189bcb4 Content-Type: text/plain; charset=ISO-8859-1 HI all, I have finally uploaded the minutes from the meeting last week: http://www.ietf.org/proceedings/interim/2014/01/27/clue/minutes/minutes-interim-2014-clue-1 Thanks to Rob for his excellent notes. There are some new issues to be opened based on the meeting so you should see the new tickets posted on the list sometime tomorrow. Regards, Mary. --20cf301b64dbb95aa004f189bcb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI all,

I have finally uploaded the min= utes from the meeting last week:

Thanks to Rob for his excellent notes. =A0
<= div>
There are some new issues to be opened based on the meet= ing so you should see the new tickets posted on the list sometime tomorrow.= =A0

Regards,
Mary.=A0
--20cf301b64dbb95aa004f189bcb4-- From Christian.Groves@nteczone.com Mon Feb 3 16:37:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4761A026A for ; Mon, 3 Feb 2014 16:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OL32bcdJdfGR for ; Mon, 3 Feb 2014 16:37:02 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D7A1A02B4 for ; Mon, 3 Feb 2014 16:37:01 -0800 (PST) Received: from ppp118-209-246-29.lns20.mel6.internode.on.net ([118.209.246.29]:52886 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1WAU0Z-0007pA-S5 for clue@ietf.org; Tue, 04 Feb 2014 11:36:59 +1100 Message-ID: <52F0362C.1070500@nteczone.com> Date: Tue, 04 Feb 2014 11:37:00 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 00:37:06 -0000 Hello Christer, Thanks for making a start on this. Some comments: General: I think the "SCTP Considerations" section could benefit by something like section 6/[draft-ietf-rtcweb-data-channel-05]. i.e. "The Usage of SCTP in the CLUE Context". I think that provides a fairly complete list of the features required. Section 6.1 could pretty much just be copied. Section 6.2 could be made CLUE specific, I guess that's what section 4 of your draft is related to. 6.3 probably can be copied. It wouldn't hurt to state that for CLUE messages. Section 6.4 could be altered slightly for CLUE. Section 6.5 would need to be updated for the CLUE. Section 3: [I-D.stewart-tsvwg-sctp-ndata] defines interleaving for large messages. This is probably something we would want to support in CLUE given the potential for large messages. It would be captured if we were to follow section 6 as per above. General: As a clue document I think we shouldn't assume that a CLUE implementer is across the RTCWEB work. E.g. section 3.2.2 of your draft would be a bit bewildering. What relevance is a DOMstring (which isn't well defined by draft-ietf-rtcweb-data-channel-05) PID 51 to CLUE. Why PID50 for CLUE? Section 6: If we use draft-jesup-rtcweb-data-protocol then do we need to add an IANA consideration to add "CLUE" to the protocol element in the DATA_CHANNEL_OPEN message? Regards, Christian On 2/02/2014 4:36 AM, Christer Holmberg wrote: > Hi, > > I put together an initial draft for describing the CLUE data channel. > > I realize that text is still needed, but now it will be easier to document whatever we agree to, identity open issues etc. > > Regards, > > Christer > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Feb 3 16:39:55 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AF01A02B4 for ; Mon, 3 Feb 2014 16:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jeVM1uvewL1 for ; Mon, 3 Feb 2014 16:39:54 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) by ietfa.amsl.com (Postfix) with ESMTP id E3D6E1A026A for ; Mon, 3 Feb 2014 16:39:53 -0800 (PST) Received: by mail-yk0-f169.google.com with SMTP id q9so43459674ykb.0 for ; Mon, 03 Feb 2014 16:39:53 -0800 (PST) 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=g7ox4cfFWDSOPrFSGHbxhM72/FEZxBuMkZWJHILoIJ0=; b=Nqjlys4bHCqcZTFESDknwLaTc9rYelUHykLQ9PB5p6n90Dq7UEma+7VERPI0+deuUG STvKn06eeEmYp1v6gbrYQjU0fFQXTk2GWcP5RB2SKIZGL8Qg83sN9X5Tbly9/HnCvuWu 0F+Bs3wBe2ShzHuTTGCJm/MV6ozlj8aedJKhGbcsElgORWtSq/NNV1iRCmT9P1epzYb2 xcBxD3uvP7QD350P4ur2044YJxrRr31rWwLrrxqrK/HVM4ollhLmokwGeTRPY3zV2/Wj yfb9xLSBY6raQXSer4NKnYU9x4HbgOr/I+H3huE3O+TuQCJCkPiKHbiVI4Qxv4UXHIVm +e8g== MIME-Version: 1.0 X-Received: by 10.236.46.18 with SMTP id q18mr35360720yhb.21.1391474393713; Mon, 03 Feb 2014 16:39:53 -0800 (PST) Received: by 10.170.46.143 with HTTP; Mon, 3 Feb 2014 16:39:53 -0800 (PST) Date: Mon, 3 Feb 2014 18:39:53 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c1cf5af3905804f189e091 Subject: [clue] Consensus call: Spatial information within composed MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 00:39:55 -0000 --001a11c1cf5af3905804f189e091 Content-Type: text/plain; charset=ISO-8859-1 As Mark noted in his last email in this thread, there was consensus at the virtual interim last Monday (as well as previously when we closed ticket #5) that CLUE would not support the use of spatial information with regards to composed captures: http://www.ietf.org/mail-archive/web/clue/current/msg03304.html While there appears not to be unanimous consensus on the mailing list, the chairs believe that we do have rough consensus (based on majority support) within the WG per IETF procedures. Regards, Mary. --001a11c1cf5af3905804f189e091 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As Mark noted in his last email in this thread, there was = consensus at the virtual interim last Monday (as well as previously when we= closed ticket #5) that CLUE would not support the use of spatial informati= on with regards to composed captures: =A0

While there appears not to be unanimous consens= us on the mailing list, the chairs believe that we do have rough consensus = (based on majority support) within the WG per IETF procedures.


Regards,
Mary.=A0
<= /div> --001a11c1cf5af3905804f189e091-- From christer.holmberg@ericsson.com Tue Feb 4 01:20:00 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A2E1A03D2 for ; Tue, 4 Feb 2014 01:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJoRqe4fs-5M for ; Tue, 4 Feb 2014 01:19:57 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9CE1A03D0 for ; Tue, 4 Feb 2014 01:19:56 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-57-52f0b0bbb020 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C1.35.04249.BB0B0F25; Tue, 4 Feb 2014 10:19:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Tue, 4 Feb 2014 10:19:55 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 Thread-Index: AQHPIUE/n7wBAhvYG0i3SlgwBW0TLJqky7Ww Date: Tue, 4 Feb 2014 09:19:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> In-Reply-To: <52F0362C.1070500@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje6eDR+CDE518Vt8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugSvj2qMDzAWHpCtO3XjD1MD4SbSLkZNDQsBE orftFzOELSZx4d56ti5GLg4hgSOMEns/nGQFSQgJLGKU+HGWvYuRg4NNwEKi+582SFhEIFyi Y9sVRhBbWCBI4vb9uywQ8WCJRfu3skPYRhLbj29hArFZBFQkpn16BmbzCvhKfO/azw4xPl+i /8dVMJtTQEfiwrQDbCA2I9A930+tAatnFhCXuPVkPhPEnQISS/ach7pZVOLl43+sIKdJCChJ TNuaBlGuI7Fg9yc2CFtbYtnC18wQawUlTs58wjKBUXQWkqmzkLTMQtIyC0nLAkaWVYwcxanF SbnpRgabGIGRcHDLb4sdjJf/2hxilOZgURLn/fjWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDo4GayvmH7Uu4fV4ZBXZfEzZwVvn8eUdJmseEiaf7XNN0xBv/bzmy8JX91z/3C0VPTLv3 Z2v+nKZPn9hWLWT40rDq06niNXbbvZy7nuYuEQyW89PhP++8MejtywstbbsZ+w8tqPi98doU u1SGupJEs+xTkXbhkq3Jb8re/G5WVLwaMeG1b9Xuk0osxRmJhlrMRcWJAJhkcw1SAgAA Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 09:20:00 -0000 Hi Christian, > Some comments: > General: I think the "SCTP Considerations" section could benefit by somet= hing like section 6/[draft-ietf-rtcweb-data-channel-05]. i.e. "The Usage of= SCTP in the CLUE Context". I guess we could start by re-naming section 3.2 to something like that :) > I think that provides a fairly complete list of the features required. Se= ction 6.1 could pretty much just be copied. I agree that we might be able to copy most of the stuff. However, do we rea= lly need the partial reliability extension for CLUE? The suggestion is to a= lways use a reliable channel. > Section 6.2 could be made CLUE specific, I guess that's what section 4 of= your draft is related to.=20 Correct. If we want, we could use the section, have some text talking about the usag= e of the SDP Offer/Answer mechanism for negotiating the channel, and then r= efer to section 4 for the details. > 6.3 probably can be copied.=20 To me section 6.3 is teach-yourself-SCTP :) But, maybe we could add the text to section 2, as a definition for "SCTP st= ream"? > It wouldn't hurt to state that for CLUE messages. Section 6.4 could be al= tered slightly for CLUE. I think section 6.4 is more or less what I currently have in section 3.2.1.= But, maybe it should be added to a "Channel Definition" section. > Section 6.5 would need to be updated for the CLUE. Yes. Because, as we DO have an "external mechanism" (SDP Offer/Answer) to n= egotiate the channel, we don't need to be a generic. > Section 3: [I-D.stewart-tsvwg-sctp-ndata] defines interleaving for large = messages. This is probably something we would want to support=20 > in CLUE given the potential for large messages. It would be captured if w= e were to follow section 6 as per above. Well, we need to discuss whether we need to support/mandate interleaving, o= r whether application fragmentation is enough. > General: As a clue document I think we shouldn't assume that a CLUE imple= menter is across the RTCWEB work. E.g. section 3.2.2 of your draft=20 > would be a bit bewildering. What relevance is a DOMstring (which isn't we= ll defined by draft-ietf-rtcweb-data-channel-05) PID 51 to CLUE. Why > PID50 for CLUE? Yes. This is part of the general opinion that we need more details on why c= ertain selections have been done, and that 50 and 51 are used to provide in= teroperability with rtcweb. > Section 6: If we use draft-jesup-rtcweb-data-protocol then do we need to = add an IANA consideration to add "CLUE" to the protocol element in the DATA= _CHANNEL_OPEN message? Yes. I think it would be good to be able to, on the data channel, indicate when = a data channel is "openend", and when it is "closed". The question is wheth= er we would use the rtcweb data channel protocol for that, or whether we wo= uld define some message in the CLUE protocol. Regards, Christer On 2/02/2014 4:36 AM, Christer Holmberg wrote: > Hi, > > I put together an initial draft for describing the CLUE data channel. > > I realize that text is still needed, but now it will be easier to documen= t whatever we agree to, identity open issues etc. > > Regards, > > Christer > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Tue Feb 4 03:43:34 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA251A03F3 for ; Tue, 4 Feb 2014 03:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz0LKYRkj7tV for ; Tue, 4 Feb 2014 03:43:33 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7231A03FB for ; Tue, 4 Feb 2014 03:43:32 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-23-52f0d26372bd Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 58.67.23809.362D0F25; Tue, 4 Feb 2014 12:43:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Tue, 4 Feb 2014 12:43:30 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: CLUE Data Channel: Identical stream ID values in both directions? Thread-Index: Ac8hnlNVKx/zx1mwSsaGQD1SBC5QUg== Date: Tue, 4 Feb 2014 11:43:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D15838DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvjW7ypQ9BBu1XlCz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBWTlrIVvFCuOHllGlMD40e5LkZODgkBE4mDi/ezQdhiEhfu rQeyuTiEBA4xSkyfMo0JJCEksIhR4sDJwC5GDg42AQuJ7n/aIGERAWWJo5v7wXqFBbwk5i6b zApSIiIQKPHweSpEiZ5E36N+VhCbRUBF4vyOG2DlvAK+Eg+WnmcHsRmB1n4/tQZsE7OAuMSt J/OZIM4RkFiy5zwzhC0q8fLxP1YIW1Hi6vTlUPX5EpNP9TBDzBSUODnzCcsERqFZSEbNQlI2 C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8XInpuYmZNebrSJERjyB7f8Vt3BeOec yCFGaQ4WJXHeD2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwqlzY9PzpD+4NvYz/ZGQK lSpXF74t9duj3nIr7buU75NU3k9tqjzX1d7e/zX32BGxqP5ZH4NLGHe4vlieoSuyccaqAzH3 l9yr4un9zV6y60qUVvzq+kuczPnH997accPaL2F3jNHM2T+XHfkYIv78fb3+3JD0JJMA9W1f VZ1lz9VLPNPX5J8ar8RSnJFoqMVcVJwIAKe8nMhHAgAA Subject: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 11:43:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D15838DESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Paul earlier suggested that we, for the SCTP streams that form the CLUE Dat= a Channel, shall mandate the usage of identical stream ID values in each di= rection. Perhaps I missed it, but what was the reason for that? To use the stream ID= in order know on which stream CLUE messages are received? I do agree that we need a way to know on which stream CLUE messages are rec= eived, and we can for sure recommend using the same values, but until we kn= ow what will be negotiated in SDP I'd like to keep the MUST as an open issu= e. Also, the rtcweb data channel draft says: "Note that there's no requirement for the SCTP streams used to create a bidirectional channel have the same number in each direct= ion. How stream values are selected is protocol and implementation d= ependent." Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D15838DESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Paul earlier suggested that we, for the SCTP streams= that form the CLUE Data Channel, shall mandate the usage of identical stre= am ID values in each direction.

 

Perhaps I missed it, but what was the reason for tha= t? To use the stream ID in order know on which stream CLUE messages are rec= eived?

 

I do agree that we need a way to know on which strea= m CLUE messages are received, and we can for sure recommend using the same = values, but until we know what will be negotiated in SDP I’d like to = keep the MUST as an open issue.

 

Also, the rtcweb data channel draft says:=

 

“Note that there'= s no requirement for the SCTP streams used to create

         &nb= sp;      a bidirectional channel have the same num= ber in each direction.  How

         &nb= sp;      stream values are selected is protocol an= d implementation dependent.”

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D15838DESESSMB209erics_-- From pkyzivat@alum.mit.edu Tue Feb 4 06:12:43 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326A31A00E9 for ; Tue, 4 Feb 2014 06:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3Txfj4L6-FS for ; Tue, 4 Feb 2014 06:12:42 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id E57631A00DB for ; Tue, 4 Feb 2014 06:12:41 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id NCRZ1n0050SCNGk56EChfR; Tue, 04 Feb 2014 14:12:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id NECh1n00A3ZTu2S3VEChfs; Tue, 04 Feb 2014 14:12:41 +0000 Message-ID: <52F0F559.7070803@alum.mit.edu> Date: Tue, 04 Feb 2014 09:12:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391523161; bh=13NKBTBAZYqFckLHDI/oTzC8NtE6lDKC6DMiBn7hrB0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FfJ5FkX6QS65J9QoAkh97vUQeWkmmRebIjvfisxVmXCiyxQQvceXXnwecYDd8PYhR ki3sze5wH/UAULfneBEJA1nWjMAogfdaJ8hgN89kZR1ypIWAf4DjRc8T/bUbn6zYF5 LSG8ZH3idCoT2YESdNpW4DBN+Niwg7k1HzbwPujCq0koTuB67VfSS1HvOcXa1QJ0yN N1zACJHjjC03bwr5EaUI3rN4RnVlhnH5CuU4hCC1GLfXaXWjaeOdKdxcZz7VX7tVym fb6Wbl8ChD4j7VOl0BZ9C+wQPSto3E8c/7qpDp/xK2OXJ9KyqhzVF4lB4vA+I+gkXV kURhEdVXD7oZg== Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 14:12:43 -0000 On 2/4/14 6:43 AM, Christer Holmberg wrote: > Hi, > > Paul earlier suggested that we, for the SCTP streams that form the CLUE > Data Channel, shall mandate the usage of identical stream ID values in > each direction. > > Perhaps I missed it, but what was the reason for that? To use the stream > ID in order know on which stream CLUE messages are received? > > I do agree that we need a way to know on which stream CLUE messages are > received, and we can for sure recommend using the same values, but until > we know what will be negotiated in SDP I’d like to keep the MUST as an > open issue. > > Also, the rtcweb data channel draft says: > > “Note that there's no requirement for the SCTP streams used to create > > a bidirectional channel have the same number in each > direction. How > > stream values are selected is protocol and > implementation dependent.” I was thinking they had to match in rtcweb. If they *don't* have to match, then how are they correlated? I just looked, and found the text you quote. I *guess* if the negotiation is done externally they can just wave their hands like this. But for channels opened using the rtcweb data channel protocol I don't see how they can avoid specifying how the correlation is done. But I looked there too, and they don't seem to say. I think it is a hole in their spec. Thanks, Paul From christer.holmberg@ericsson.com Tue Feb 4 06:19:02 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9065D1A01FB for ; Tue, 4 Feb 2014 06:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpMgw8AqfYeF for ; Tue, 4 Feb 2014 06:19:01 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3545C1A00EC for ; Tue, 4 Feb 2014 06:19:01 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-dd-52f0f6d4a930 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 6E.CF.04853.4D6F0F25; Tue, 4 Feb 2014 15:19:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Tue, 4 Feb 2014 15:18:59 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: Identical stream ID values in both directions? Thread-Index: Ac8hnlNVKx/zx1mwSsaGQD1SBC5QUgADHU6AAAIuGcA= Date: Tue, 4 Feb 2014 14:18:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> In-Reply-To: <52F0F559.7070803@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvje6Vbx+CDJp+SVjsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG7zcbmAv+8VRc7H/N3MD4m7OLkZNDQsBE Ys7BVhYIW0ziwr31bCC2kMAJRon3MzK6GLmA7EWMEh3XfwIVcXCwCVhIdP/TBqkREfCU2PFx CjOILSwQLtFwfx4rRDxC4mfTflaQchEBK4mpzxRBwiwCKhJLjzYygti8Ar4Sq+b9YIRYlS9x p+EcE4jNKaAjcWrGTXYQmxHonO+n1oDFmQXEJW49mc8EcaaAxJI955khbFGJl4//sULYihLt TxsYIep1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilGyOLW4 ODfdyEAvNz23RC+1KDO5uDg/T684dRMjMFYObvlttIPx5B77Q4zSHCxK4rzXWWuChATSE0tS s1NTC1KL4otKc1KLDzEycXBKNTAq6jzYY9Zu3N2obXwsjG+WQVOuR2SeSMTz5RG30k/7qzyK PcWw3FFYsrxo/YyM/WUTDu2f+c7AQ3Xip51qe/c3L7WelOCm3mu8h+XMMscJV/Wri+o5Lqbt mnrXdVbti+UZ+rumOt8SNBTR2/91o8eNh7FtDokGRZdVKu4/mHjPPirzR4plXbwSS3FGoqEW c1FxIgBuvcMAYwIAAA== Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 14:19:02 -0000 Hi, >> Paul earlier suggested that we, for the SCTP streams that form the=20 >> CLUE Data Channel, shall mandate the usage of identical stream ID=20 >> values in each direction. >> >> Perhaps I missed it, but what was the reason for that? To use the=20 >> stream ID in order know on which stream CLUE messages are received? >> >> I do agree that we need a way to know on which stream CLUE messages=20 >> are received, and we can for sure recommend using the same values, but=20 >> until we know what will be negotiated in SDP I'd like to keep the MUST=20 >> as an open issue. >> >> Also, the rtcweb data channel draft says: >> >> "Note that there's no requirement for the SCTP streams used to create >> >> a bidirectional channel have the same number in each=20 >> direction. How >> >> stream values are selected is protocol and=20 >> implementation dependent." > > I was thinking they had to match in rtcweb. If they *don't* have to match= , then how are they correlated? As we discussed before, at the moment it seems like they assume a single us= age per association. ...which is perhaps the only thing rtcweb requires, but the mechanism have = to be general. > I just looked, and found the text you quote. I *guess* if the negotiation= is done externally they can just wave their hands like this. > But for channels opened using the rtcweb data channel protocol I don't se= e how they can avoid specifying how the correlation is done. But I looked t= here too, and they don't seem to say. I think it is a hole in their spec. Yes - among the others :) Regards, Christer From christer.holmberg@ericsson.com Tue Feb 4 06:29:34 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0951A00DB for ; Tue, 4 Feb 2014 06:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VyehO919A2q for ; Tue, 4 Feb 2014 06:29:31 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id CF8C21A00E4 for ; Tue, 4 Feb 2014 06:29:27 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-16-52f0f946ac1f Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B7.04.04249.649F0F25; Tue, 4 Feb 2014 15:29:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Tue, 4 Feb 2014 15:29:26 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: CLUE Data Channel: SCTP Considerations - which ones does CLUE require? Thread-Index: Ac8htYEgN7eZRc+7Td6fweMbfzckWw== Date: Tue, 4 Feb 2014 14:29:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1586CE@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1586CEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvja7bzw9BBk+7rCz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLbnp1kLrrtW3LyziKmB8ZhNFyMnh4SAicSVfSsYIWwxiQv3 1rN1MXJxCAkcYZToXXyCGcJZxChx5sdB9i5GDg42AQuJ7n/aIA0iAsoSRzf3s4HYwgKBEu// XWWFiIdJLL18gBnC1pNoOvcTbAGLgIrE9d8bwGp4BXwlOg7/BYszAi3+fmoNE4jNLCAucevJ fCaIgwQkluw5zwxhi0q8fPyPFcJWlGh/2sAIUZ8v0blnGtRMQYmTM5+wTGAUmoVk1CwkZbOQ lEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjBzFqcVJuelGBpsYgYF/cMtvix2Ml//a HGKU5mBREuf9+NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMjr1Np1QT9KuG123o2rPg9 ZZ//qvkPWDkXsv5Zo8VxaWlIjc3bi3yrnJM3uZWutDPkMFg+96LopjkMHVXnttQ8f+LJJ9q7 iPf0t7a9H37OVGCrKivdlfP4qHtnxt0NercWbWLoWflrr9zTa8yXJFg3JG0W7X+ptOfF2sPd eRp8sw/dvnhUfAbnASWW4oxEQy3mouJEAEAfKIBKAgAA Subject: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 14:29:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D1586CEESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Christian earlier suggested that we could copy/paste section 6.1 from the r= tcweb-data-channel draft into our draft. I think we need to consider whether we really need the features listed in t= hat chapter (unless, of course, the usage of them is mandated in order to b= e compatible with rtcweb). The features are listed below, with some initial comments ([CHH]). o The stream reset extension defined in [RFC6525] MUST be supported. It is used for closing channels. [CHH] I may have misunderstood RFC6526, but I don't think this is for CLOSI= NG channels. It's for reseting the number sequence, which I think is a diff= erent thing. In any case, I currently see no reason why we would need to mandate support= of this in CLUE. [/CHH] o The dynamic address reconfiguration extension defined in [RFC5061] MUST be used to signal the support of the stream reset extension defined in [RFC6525], other features of [RFC5061] MUST NOT be used. [CHH] It seems like this is only used for the reset extension. The other fe= atures are related to multi-homing, which is not supported by SCTPoDTLS to = begin with. [/CHH] o The partial reliability extension defined in [RFC3758] MUST be supported. In addition to the timed reliability PR-SCTP policy defined in [RFC3758], the limited retransmission policy defined in [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. [CHH] I see no reason for support of partial reliability - eventhough I hav= e to admit I am not sure what it really means. In any case, my suggestion i= s that CLUE always use "full" reliability. [/CHH] Once support for message interleaving as currently being discussed in [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported. [CHH] Assuming we can rely on application-level fragmentation, I assume we = would not need it. But, again, I am not familiar with the details of messag= e interleaving. [/CHH] Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D1586CEESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Christian earlier suggested that we could copy/paste= section 6.1 from the rtcweb-data-channel draft into our draft.<= /p>

 

I think we need to consider whether we really need t= he features listed in that chapter (unless, of course, the usage of them is= mandated in order to be compatible with rtcweb).

 

The features are listed below, with some initial com= ments ([CHH]).

 

   o  The stream re= set extension defined in [RFC6525] MUST be supported.

      It = is used for closing channels.

 

[CHH] I may have misunderstood RFC= 6526, but I don’t think this is for CLOSING channels. It’s for = reseting the number sequence, which I think is a different thing.

 

In any case, I currently see no re= ason why we would need to mandate support of this in CLUE. [/CHH]

 

 

   o  The dynamic a= ddress reconfiguration extension defined in [RFC5061]

      MUS= T be used to signal the support of the stream reset extension

      def= ined in [RFC6525], other features of [RFC5061] MUST NOT be

      use= d.

 

[CHH] It seems like this is only u= sed for the reset extension. The other features are related to multi-homing= , which is not supported by SCTPoDTLS to begin with. [/CHH]

 

 

   o  The partial r= eliability extension defined in [RFC3758] MUST be

      sup= ported.  In addition to the timed reliability PR-SCTP policy

      def= ined in [RFC3758], the limited retransmission policy defined in<= /span>

      [I-= D.tuexen-tsvwg-sctp-prpolicies] MUST be supported.

 

[CHH] I see no reason for support = of partial reliability – eventhough I have to admit I am not sure wha= t it really means. In any case, my suggestion is that CLUE always use ̶= 0;full” reliability. [/CHH]

 

 

   Once support for mess= age interleaving as currently being discussed in

   [I-D.stewart-tsvwg-sc= tp-ndata] is available, it SHOULD be supported.

 

[CHH] Assuming we can rely on appl= ication-level fragmentation, I assume we would not need it. But, again, I a= m not familiar with the details of message interleaving. [/CHH]<= /span>

 

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D1586CEESESSMB209erics_-- From pkyzivat@alum.mit.edu Tue Feb 4 08:17:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757621A0199 for ; Tue, 4 Feb 2014 08:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjXWttnfPwgN for ; Tue, 4 Feb 2014 08:17:55 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 314941A0164 for ; Tue, 4 Feb 2014 08:17:55 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta09.westchester.pa.mail.comcast.net with comcast id NF3R1n0090Fqzac59GHur3; Tue, 04 Feb 2014 16:17:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id NGHu1n00T3ZTu2S3UGHuuE; Tue, 04 Feb 2014 16:17:54 +0000 Message-ID: <52F112B2.8020002@alum.mit.edu> Date: Tue, 04 Feb 2014 11:17:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1586A4@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=1391530674; bh=bENtvtI6zN7THspvb9jAIvGn6pS2/hUVqBh2L6hNwV4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YpzZkp/wACXhXovWbN1CEPpTIyCXYG+9Sd8FXwHoCqQSqjXoKnHWurJhOuqOXtT1o z+Lz/SAgvVYDsogHiAJUiCZt57Uu9zz6/3ys4m9Hngrb+n1Rpc/+EoHWjoH+1IWe8I Y3aEKUHdCxREasfiVEzcxpGz2DM+NIDZOX5iwFk9+E4eF7441kbZTnHRQviPuKpPxv 1KcVzSR+shbHgtVZV5zmrhUwIQgo369yD4T0Z8SvVDxhUjzQSNRXQ8oeLrA2hZWaYx 5mxmY9oAF3MeZrO/0pcnxtc14SD1YZLPZbBMW/pipVoqQN0jSALqfVI+D/BjAfeQ9i 4Z8ICQZHMWP+A== Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 16:17:56 -0000 On 2/4/14 9:18 AM, Christer Holmberg wrote: > Hi, > >>> Paul earlier suggested that we, for the SCTP streams that form the >>> CLUE Data Channel, shall mandate the usage of identical stream ID >>> values in each direction. >>> >>> Perhaps I missed it, but what was the reason for that? To use the >>> stream ID in order know on which stream CLUE messages are received? >>> >>> I do agree that we need a way to know on which stream CLUE messages >>> are received, and we can for sure recommend using the same values, but >>> until we know what will be negotiated in SDP I'd like to keep the MUST >>> as an open issue. >>> >>> Also, the rtcweb data channel draft says: >>> >>> "Note that there's no requirement for the SCTP streams used to create >>> >>> a bidirectional channel have the same number in each >>> direction. How >>> >>> stream values are selected is protocol and >>> implementation dependent." >> >> I was thinking they had to match in rtcweb. If they *don't* have to match, then how are they correlated? > > As we discussed before, at the moment it seems like they assume a single usage per association. > > ...which is perhaps the only thing rtcweb requires, but the mechanism have to be general. It depends on what you mean by "usage". I agree that they are assuming that when an association is used by rtcweb, then the *entire* association is used by rtcweb. But it is entirely clear to me that the intent is to support multiple channels. So there will be multiple SCTP streams in each direction. And then it becomes essential to correlate *which* incoming stream pairs with each outgoing stream. >> I just looked, and found the text you quote. I *guess* if the negotiation is done externally they can just wave their hands like this. >> But for channels opened using the rtcweb data channel protocol I don't see how they can avoid specifying how the correlation is done. But I looked there too, and they don't seem to say. I think it is a hole in their spec. > > Yes - among the others :) I just posted a question about this. We will see what the answer is. Thanks, Paul > Regards, > > Christer > > From jonathan@vidyo.com Tue Feb 4 08:33:16 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432F61A0130 for ; Tue, 4 Feb 2014 08:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmKKlp3KgERc for ; Tue, 4 Feb 2014 08:33:14 -0800 (PST) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) by ietfa.amsl.com (Postfix) with ESMTP id 917CE1A013B for ; Tue, 4 Feb 2014 08:33:14 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/4/2014 11:33:13 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-215/SG:5 2/4/2014 11:32:29 AM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.739751 p=-0.952708 Source White X-Signature-Violations: 0-0-0-7483-c X-Note-419: 15.6005 ms. Fail:1 Chk:1345 of 1345 total X-Note: SCH-CT/SI:1-1345/SG:1 2/4/2014 11:32:56 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 94932194; Tue, 04 Feb 2014 11:33:12 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Tue, 4 Feb 2014 10:33:11 -0600 From: Jonathan Lennox To: Mary Barnes Thread-Topic: [clue] Consensus call: Spatial information within composed MCC Thread-Index: AQHPIcVuZ9FchLJQ7E6EIYicnPJbLJqlrqCA Date: Tue, 4 Feb 2014 16:33:11 +0000 Message-ID: <0D8D8A12-3772-4A8E-A7D8-5AE6C3E23BD5@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_0D8D8A1237724A8EA7D85AE6C3E23BD5vidyocom_" MIME-Version: 1.0 Cc: CLUE Subject: Re: [clue] Consensus call: Spatial information within composed MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 16:33:16 -0000 --_000_0D8D8A1237724A8EA7D85AE6C3E23BD5vidyocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Feb 3, 2014, at 7:39 PM, Mary Barnes > wrote: As Mark noted in his last email in this thread, there was consensus at the = virtual interim last Monday (as well as previously when we closed ticket #5= ) that CLUE would not support the use of spatial information with regards t= o composed captures: http://www.ietf.org/mail-archive/web/clue/current/msg03304.html While there appears not to be unanimous consensus on the mailing list, the = chairs believe that we do have rough consensus (based on majority support) = within the WG per IETF procedures. I just wanted to state more clearly my understanding of this consensus. I = don't think there was confusion about this among the people at the interim,= but it's good to have things explicit. 1. What we're not supporting is the spatial description of the individual s= ub-parts of a composed capture. A composed MCC may itself have spatial inf= ormation, to indicate, for instance, the intended geometric association of = several composed MCCs. 2. We're not saying that the CLUE protocol MUST NOT ever support this in an= y future extension; simply that we're not intending to define how to descri= be it in the initial version of the protocol. --_000_0D8D8A1237724A8EA7D85AE6C3E23BD5vidyocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <506AD2E1700A1C4E9E9193BD87E92E93@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Feb 3, 2014, at 7:39 PM, Mary Barnes <mary.ietf.barnes@gmail.com>
 wrote:

As Mark noted in his last email in this thread, there was = consensus at the virtual interim last Monday (as well as previously when we= closed ticket #5) that CLUE would not support the use of spatial informati= on with regards to composed captures:  

While there appears not to be unanimous consensus on the mailing list,= the chairs believe that we do have rough consensus (based on majority supp= ort) within the WG per IETF procedures.

I just wanted to state more clearly my understanding of this consensus= .  I don't think there was confusion about this among the people at th= e interim, but it's good to have things explicit.

1. What we're not supporting is the spatial description of the individ= ual sub-parts of a composed capture.  A composed MCC may itself have s= patial information, to indicate, for instance, the intended geome= tric association of several composed MCCs.

2. We're not saying that the CLUE protocol MUST NOT ever support this = in any future extension; simply that we're not intending to define how to d= escribe it in the initial version of the protocol.
--_000_0D8D8A1237724A8EA7D85AE6C3E23BD5vidyocom_-- From Mark.Duckworth@polycom.com Tue Feb 4 09:28:04 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5971A011F for ; Tue, 4 Feb 2014 09:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xW63513Ph_Q for ; Tue, 4 Feb 2014 09:28:01 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 815DB1A011D for ; Tue, 4 Feb 2014 09:28:01 -0800 (PST) Received: from PWEHUB01.polycom.com (10.236.2.221) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 4 Feb 2014 09:27:57 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 4 Feb 2014 09:27:57 -0800 From: "Duckworth, Mark" To: Jonathan Lennox , Mary Barnes Date: Tue, 4 Feb 2014 09:27:55 -0800 Thread-Topic: [clue] Consensus call: Spatial information within composed MCC Thread-Index: AQHPIcVuZ9FchLJQ7E6EIYicnPJbLJqlrqCA//+qgzA= Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D1ED819@CRPMBOXPRD07.polycom.com> References: <0D8D8A12-3772-4A8E-A7D8-5AE6C3E23BD5@vidyo.com> In-Reply-To: <0D8D8A12-3772-4A8E-A7D8-5AE6C3E23BD5@vidyo.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_49E45C59CA48264997FEBFB29B6BC2D60C9D1ED819CRPMBOXPRD07p_" MIME-Version: 1.0 Cc: CLUE Subject: Re: [clue] Consensus call: Spatial information within composed MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 17:28:04 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D1ED819CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Jonathan's clarifications. Mark From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Jonathan Lennox Sent: Tuesday, February 04, 2014 11:33 AM To: Mary Barnes Cc: CLUE Subject: Re: [clue] Consensus call: Spatial information within composed MCC On Feb 3, 2014, at 7:39 PM, Mary Barnes > wrote: As Mark noted in his last email in this thread, there was consensus at the = virtual interim last Monday (as well as previously when we closed ticket #5= ) that CLUE would not support the use of spatial information with regards t= o composed captures: http://www.ietf.org/mail-archive/web/clue/current/msg03304.html While there appears not to be unanimous consensus on the mailing list, the = chairs believe that we do have rough consensus (based on majority support) = within the WG per IETF procedures. I just wanted to state more clearly my understanding of this consensus. I = don't think there was confusion about this among the people at the interim,= but it's good to have things explicit. 1. What we're not supporting is the spatial description of the individual s= ub-parts of a composed capture. A composed MCC may itself have spatial inf= ormation, to indicate, for instance, the intended geometric association of = several composed MCCs. 2. We're not saying that the CLUE protocol MUST NOT ever support this in an= y future extension; simply that we're not intending to define how to descri= be it in the initial version of the protocol. --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D1ED819CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree w= ith Jonathan’s clarifications.

Mark

 = ;

From: clue [mail= to:clue-bounces@ietf.org] On Behalf Of Jonathan Lennox
Sent: Tuesday, February 04, 2014 11:33 AM
To: Mary Barnes
Cc:<= /b> CLUE
Subject: Re: [clue] Consensus call: Spatial information = within composed MCC

<= o:p> 

On Feb 3, 2014, at 7:39 PM, M= ary Barnes <mary.ietf.barn= es@gmail.com>

&nb= sp;wrote:



<= div>

As Mark noted in his last email in this thread, th= ere was consensus at the virtual interim last Monday (as well as previously= when we closed ticket #5) that CLUE would not support the use of spatial i= nformation with regards to composed captures:  

 =

While there appears not to be una= nimous consensus on the mailing list, the chairs believe that we do have ro= ugh consensus (based on majority support) within the WG per IETF procedures= .

 

I just wanted to state more clearly m= y understanding of this consensus.  I don't think there was confusion = about this among the people at the interim, but it's good to have things ex= plicit.

 

=

1. What we're not supporting is the spatial= description of the individual sub-parts of a composed capture.  A com= posed MCC may itself have spatial information, to indicate, for instan= ce, the intended geometric association of several composed MCCs.<= /o:p>

 

2. We're not saying that the CLUE protocol MUST NOT ever= support this in any future extension; simply that we're not intending to d= efine how to describe it in the initial version of the protocol.=

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D1ED819CRPMBOXPRD07p_-- From Christian.Groves@nteczone.com Tue Feb 4 15:16:28 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E201A0162 for ; Tue, 4 Feb 2014 15:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UauCHoY8evl for ; Tue, 4 Feb 2014 15:16:26 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516701A0135 for ; Tue, 4 Feb 2014 15:16:26 -0800 (PST) Received: from ppp118-209-63-14.lns20.mel4.internode.on.net ([118.209.63.14]:51160 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1WApDt-0008Pe-K5 for clue@ietf.org; Wed, 05 Feb 2014 10:16:09 +1100 Message-ID: <52F174C5.1020306@nteczone.com> Date: Wed, 05 Feb 2014 10:16:21 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: clue@ietf.org References: <0D8D8A12-3772-4A8E-A7D8-5AE6C3E23BD5@vidyo.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D1ED819@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D1ED819@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Consensus call: Spatial information within composed MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 23:16:29 -0000 Just a further clarification to 1. 1. What we're not supporting is the spatial description of the individual sub-parts of a composed capture (whether they are individual captures or other composed captures).... Was that the understanding from the meeting? Also the clarifications don't cover the "maxcaptures" issue that I raised in a previous email. Regards, Christian On 5/02/2014 4:27 AM, Duckworth, Mark wrote: > > I agree with Jonathan’s clarifications. > > Mark > > *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Jonathan Lennox > *Sent:* Tuesday, February 04, 2014 11:33 AM > *To:* Mary Barnes > *Cc:* CLUE > *Subject:* Re: [clue] Consensus call: Spatial information within > composed MCC > > On Feb 3, 2014, at 7:39 PM, Mary Barnes > > > wrote: > > > > As Mark noted in his last email in this thread, there was consensus at > the virtual interim last Monday (as well as previously when we closed > ticket #5) that CLUE would not support the use of spatial information > with regards to composed captures: > > http://www.ietf.org/mail-archive/web/clue/current/msg03304.html > > While there appears not to be unanimous consensus on the mailing list, > the chairs believe that we do have rough consensus (based on majority > support) within the WG per IETF procedures. > > I just wanted to state more clearly my understanding of this > consensus. I don't think there was confusion about this among the > people at the interim, but it's good to have things explicit. > > 1. What we're not supporting is the spatial description of the > individual sub-parts of a composed capture. A composed MCC may itself > have spatial information, to indicate, for instance, the intended > geometric association of several composed MCCs. > > 2. We're not saying that the CLUE protocol MUST NOT ever support this > in any future extension; simply that we're not intending to define how > to describe it in the initial version of the protocol. > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Feb 4 15:29:25 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7EC1A0168 for ; Tue, 4 Feb 2014 15:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cZ5zaK0XNrO for ; Tue, 4 Feb 2014 15:29:23 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CAC1A0167 for ; Tue, 4 Feb 2014 15:29:23 -0800 (PST) Received: from ppp118-209-63-14.lns20.mel4.internode.on.net ([118.209.63.14]:51366 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1WApQT-00024r-5E for clue@ietf.org; Wed, 05 Feb 2014 10:29:09 +1100 Message-ID: <52F177D1.5090700@nteczone.com> Date: Wed, 05 Feb 2014 10:29:21 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 23:29:25 -0000 Hello, On 5/02/2014 1:18 AM, Christer Holmberg wrote: > Hi, > >>> Paul earlier suggested that we, for the SCTP streams that form the >>> CLUE Data Channel, shall mandate the usage of identical stream ID >>> values in each direction. >>> >>> Perhaps I missed it, but what was the reason for that? To use the >>> stream ID in order know on which stream CLUE messages are received? >>> >>> I do agree that we need a way to know on which stream CLUE messages >>> are received, and we can for sure recommend using the same values, but >>> until we know what will be negotiated in SDP I'd like to keep the MUST >>> as an open issue. >>> >>> Also, the rtcweb data channel draft says: >>> >>> "Note that there's no requirement for the SCTP streams used to create >>> >>> a bidirectional channel have the same number in each >>> direction. How >>> >>> stream values are selected is protocol and >>> implementation dependent." >> I was thinking they had to match in rtcweb. If they *don't* have to match, then how are they correlated? > As we discussed before, at the moment it seems like they assume a single usage per association. > > ...which is perhaps the only thing rtcweb requires, but the mechanism have to be general. > >> I just looked, and found the text you quote. I *guess* if the negotiation is done externally they can just wave their hands like this. >> But for channels opened using the rtcweb data channel protocol I don't see how they can avoid specifying how the correlation is done. But I looked there too, and they don't seem to say. I think it is a hole in their spec. > Yes - among the others :) [CNG] I agree. I've been looking at this also in terms of gateway support for SCTP and CLUE, BFCP, T.38 etc. The differences between the SCTP SDP draft and RTCWEB transport ones and holes with regards to STCP channel -> protocol assignment makes it hard to specify any generic behaviour. Regards, Christian > > Regards, > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Tue Feb 4 17:48:15 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3661A01B5 for ; Tue, 4 Feb 2014 17:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULbfimrFS7cA for ; Tue, 4 Feb 2014 17:48:13 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B931A0196 for ; Tue, 4 Feb 2014 17:48:13 -0800 (PST) Received: from ppp118-209-63-14.lns20.mel4.internode.on.net ([118.209.63.14]:54494 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1WAran-0005wR-A0 for clue@ietf.org; Wed, 05 Feb 2014 12:47:57 +1100 Message-ID: <52F1985A.8070006@nteczone.com> Date: Wed, 05 Feb 2014 12:48:10 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D1586CE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1586CE@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 01:48:16 -0000 Hello Christer, Part of the reason I suggested to use those sections of rtcweb-data-channel is so that we can make an educated decision about what we want to support for CLUE. Please see below. Regards, Christian On 5/02/2014 1:29 AM, Christer Holmberg wrote: > > Hi, > > Christian earlier suggested that we could copy/paste section 6.1 from > the rtcweb-data-channel draft into our draft. > > I think we need to consider whether we really need the features listed > in that chapter (unless, of course, the usage of them is mandated in > order to be compatible with rtcweb). > [CNG] I agree. However if we say functions are not supported CLUE and RTCWEB says that they must be supported. What does that mean? e.g. We mandate the use of RTCweb data channel for CLUE. Therefore the rules of RTCweb data channel apply. Stream reset extension MUST be supported. However for CLUE we say it shouldn't be supported. The endpoint is not an RTCWEB endpoint it only supports CLUE over SCTP. So does it need to implement stream reset or not? > The features are listed below, with some initial comments ([CHH]). > > o The stream reset extension defined in [RFC6525] MUST be supported. > > It is used for closing channels. > > [CHH] I may have misunderstood RFC6526, but I don’t think this is for > CLOSING channels. It’s for reseting the number sequence, which I think > is a different thing. > > In any case, I currently see no reason why we would need to mandate > support of this in CLUE. [/CHH] > [CNG] I think the "resetting" is part of closing a channel. The resetting is done so that you can use the channel for another protocol. I'd say this has more of a general applicability An endpoint may want to close a channel and reuse it for CLUE or vice-versa. > o The dynamic address reconfiguration extension defined in [RFC5061] > > MUST be used to signal the support of the stream reset extension > > defined in [RFC6525], other features of [RFC5061] MUST NOT be > > used. > > [CHH] It seems like this is only used for the reset extension. The > other features are related to multi-homing, which is not supported by > SCTPoDTLS to begin with. [/CHH] > [CNG] I guess to be precise they only want the support of clause 4.2.7/RFC5061 "Supported Extensions Parameter"? Again this appears to be a generic function for SCTP. > o The partial reliability extension defined in [RFC3758] MUST be > > supported. In addition to the timed reliability PR-SCTP policy > > defined in [RFC3758], the limited retransmission policy defined in > > [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. > > [CHH] I see no reason for support of partial reliability – eventhough > I have to admit I am not sure what it really means. In any case, my > suggestion is that CLUE always use “full” reliability. [/CHH] > [CNG] For the current Advertise/Configure procedures I also would see no support of partial reliability. However is CLUE evolves to somehow signal speaker changes in real time then this could come in handy. i.e. Bullet 1 clause 1.3/RFC3758. Rather than retransmission what is more important is that the most recent speaker message is processed. It would prevent a momentary audio/video switch. As for limited retransmissions I'm not sure what the applicability would be to a CLUE channel? > Once support for message interleaving as currently being discussed in > > [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported. > > [CHH] Assuming we can rely on application-level fragmentation, I > assume we would not need it. But, again, I am not familiar with the > details of message interleaving. [/CHH] > [CNG] We currently don't have CLUE level fragmentation. Were you thinking of something else? > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Feb 4 18:02:02 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD811A0196 for ; Tue, 4 Feb 2014 18:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N69LjHMal7zL for ; Tue, 4 Feb 2014 18:02:00 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6B81A0190 for ; Tue, 4 Feb 2014 18:02:00 -0800 (PST) Received: from ppp118-209-63-14.lns20.mel4.internode.on.net ([118.209.63.14]:54685 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1WAro7-0008Bv-18; Wed, 05 Feb 2014 13:01:43 +1100 Message-ID: <52F19B94.5040306@nteczone.com> Date: Wed, 05 Feb 2014 13:01:56 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 02:02:02 -0000 Hello Christer, Please see below. Regards, Christian On 4/02/2014 8:19 PM, Christer Holmberg wrote: > Hi Christian, > >> Some comments: >> General: I think the "SCTP Considerations" section could benefit by something like section 6/[draft-ietf-rtcweb-data-channel-05]. i.e. "The Usage of SCTP in the CLUE Context". > I guess we could start by re-naming section 3.2 to something like that :) [CNG] OK > >> I think that provides a fairly complete list of the features required. Section 6.1 could pretty much just be copied. > I agree that we might be able to copy most of the stuff. However, do we really need the partial reliability extension for CLUE? The suggestion is to always use a reliable channel. [CNG] See other email. > >> Section 6.2 could be made CLUE specific, I guess that's what section 4 of your draft is related to. > Correct. > > If we want, we could use the section, have some text talking about the usage of the SDP Offer/Answer mechanism for negotiating the channel, and then refer to section 4 for the details. [CNG] Sounds OK. > >> 6.3 probably can be copied. > To me section 6.3 is teach-yourself-SCTP :) > > But, maybe we could add the text to section 2, as a definition for "SCTP stream"? [CNG] I don't think it hurt to give some back ground. We have to remember people who implement this won't necessarily be across of the discussions in RTCweb. > >> It wouldn't hurt to state that for CLUE messages. Section 6.4 could be altered slightly for CLUE. > I think section 6.4 is more or less what I currently have in section 3.2.1. But, maybe it should be added to a "Channel Definition" section. [CNG] Yes pretty much along the lines of section 3.2.1. Will an endpoint only ever have two CLUE channels (one send/one receive) per SCTP association? This is what I was trying to clarify on the MMUSIC list with respect to CLUE and other application protocols like bfcp/t.38 etc. > >> Section 6.5 would need to be updated for the CLUE. > Yes. Because, as we DO have an "external mechanism" (SDP Offer/Answer) to negotiate the channel, we don't need to be a generic. > >> Section 3: [I-D.stewart-tsvwg-sctp-ndata] defines interleaving for large messages. This is probably something we would want to support >> in CLUE given the potential for large messages. It would be captured if we were to follow section 6 as per above. > Well, we need to discuss whether we need to support/mandate interleaving, or whether application fragmentation is enough. > >> General: As a clue document I think we shouldn't assume that a CLUE implementer is across the RTCWEB work. E.g. section 3.2.2 of your draft >> would be a bit bewildering. What relevance is a DOMstring (which isn't well defined by draft-ietf-rtcweb-data-channel-05) PID 51 to CLUE. Why >> PID50 for CLUE? > Yes. This is part of the general opinion that we need more details on why certain selections have been done, and that 50 and 51 are used to provide interoperability with rtcweb. [CNG] If RTCweb is not used do we expect the CLUE data to be formatted as a "javascript strings"? What does using a "javascript string" imply with respect to the CLUE data model? Again we should assume no knowledge of RTCWEB for a CLUE implementation so I think we have to go into some detail what this means. > >> Section 6: If we use draft-jesup-rtcweb-data-protocol then do we need to add an IANA consideration to add "CLUE" to the protocol element in the DATA_CHANNEL_OPEN message? > Yes. > > I think it would be good to be able to, on the data channel, indicate when a data channel is "openend", and when it is "closed". The question is whether we would use the rtcweb data channel protocol for that, or whether we would define some message in the CLUE protocol. > > Regards, > > Christer > > > > > > > > > > > > > On 2/02/2014 4:36 AM, Christer Holmberg wrote: >> Hi, >> >> I put together an initial draft for describing the CLUE data channel. >> >> I realize that text is still needed, but now it will be easier to document whatever we agree to, identity open issues etc. >> >> Regards, >> >> Christer >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From internet-drafts@ietf.org Tue Feb 4 23:31:49 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CF51A0054; Tue, 4 Feb 2014 23:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd6DO7nXaCet; Tue, 4 Feb 2014 23:31:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6941A0055; Tue, 4 Feb 2014 23:31:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140205073148.7016.67498.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 23:31:48 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 07:31:49 -0000 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 : Use Cases for Telepresence Multi-streams Authors : Allyn Romanow Stephen Botzko Mark Duckworth Roni Even Filename : draft-ietf-clue-telepresence-use-cases-09.txt Pages : 17 Date : 2014-02-04 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-use-cases-09 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 christer.holmberg@ericsson.com Tue Feb 4 23:40:08 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0541A0056 for ; Tue, 4 Feb 2014 23:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeQqcZCPdln2 for ; Tue, 4 Feb 2014 23:40:06 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 59A301A0059 for ; Tue, 4 Feb 2014 23:40:06 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-bf-52f1ead47a14 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 98.4B.04249.4DAE1F25; Wed, 5 Feb 2014 08:40:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 08:40:04 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? Thread-Index: Ac8htYEgN7eZRc+7Td6fweMbfzckWwAVm/YAAA4NnfA= Date: Wed, 5 Feb 2014 07:40:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15B6B5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1586CE@ESESSMB209.ericsson.se> <52F1985A.8070006@nteczone.com> In-Reply-To: <52F1985A.8070006@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje6VVx+DDK4etrH48r6RxWL/qcvM DkweS5b8ZPJYcX4mSwBTFJdNSmpOZllqkb5dAlfGjqvn2QqWKlc8/fCRtYFxmUwXIyeHhICJ xIPps5ghbDGJC/fWs3UxcnEICRxhlFiy7zsjhLOIUeLu2vNMXYwcHGwCFhLd/7RBGkQEwiU6 tl1hBLGFBWIkutuOMUHEYyV+TJjJDmFbScw9/pEFpJVFQEXi96VYkDCvgK/E7NY2sHIhgXyJ 1/P2gY3hFNCRWHNmAZjNCHTP91NrwGqYBcQlbj2ZzwRxp4DEkj3noW4WlXj5+B8rhK0o0f60 gRGiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYOYpTi5Ny 040MNjECY+Hglt8WOxgv/7U5xCjNwaIkzvvxrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6p BsbpM8yWT8jkOu/hPpXxR0KRaPY2j6qZHvxfdubuNnz04fivaxIqbvetJjU1tPozx91a7rds lYTIXNb9Vo/PFAtvKs7eWfgtSGBTSPaGWam+1/4eZCuLdDFI3/3/hb3IYZYjtesz196LTj/A WyS4TdEv/uqsgtWcb7yzKqT7fWz+TU1r9Dyzll2JpTgj0VCLuag4EQC5iI0MUwIAAA== Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 07:40:09 -0000 Hi Christian, > Part of the reason I suggested to use those sections of rtcweb-data-chann= el is so that we can make an educated decision about what we want to suppor= t for CLUE. I could add the text, and indicate that the CLUE usage is FFS. >> Christian earlier suggested that we could copy/paste section 6.1 from=20 >> the rtcweb-data-channel draft into our draft. >> >> I think we need to consider whether we really need the features listed=20 >> in that chapter (unless, of course, the usage of them is mandated in=20 >> order to be compatible with rtcweb). >> > [CNG] I agree. However if we say functions are not supported CLUE and RTC= WEB says that they must be supported. What does=20 > that mean? e.g. We mandate the use of RTCweb data channel for CLUE. There= fore the rules of RTCweb data channel apply. Stream reset extension MUST be= supported.=20 > However for CLUE we say it shouldn't be supported. The endpoint is not an= RTCWEB endpoint it only supports CLUE over SCTP. So does it need to implem= ent stream reset or not? Those are things we need to clarify with RTCWEB. >> The features are listed below, with some initial comments ([CHH]). >> >> o The stream reset extension defined in [RFC6525] MUST be supported. >> It is used for closing channels. >> >> [CHH] I may have misunderstood RFC6526, but I don't think this is for=20 >> CLOSING channels. It's for reseting the number sequence, which I think=20 >> is a different thing. >> >> In any case, I currently see no reason why we would need to mandate=20 >> support of this in CLUE. [/CHH] >> > [CNG] I think the "resetting" is part of closing a channel. The resetting= is done so that you can use the channel for another protocol.=20 > I'd say this has more of a general applicability An endpoint may want to = close a channel and reuse it for CLUE or vice-versa. Sure. And, if someone wants to use it - fine. But, from a CLUE perspective = we only have one protocol, so we don't need to mandate it. >> o The dynamic address reconfiguration extension defined in [RFC5061] >> >> MUST be used to signal the support of the stream reset extension >> defined in [RFC6525], other features of [RFC5061] MUST NOT be >> used. >> >> [CHH] It seems like this is only used for the reset extension. The=20 >> other features are related to multi-homing, which is not supported by=20 >> SCTPoDTLS to begin with. [/CHH] >> > [CNG] I guess to be precise they only want the support of clause > 4.2.7/RFC5061 "Supported Extensions Parameter"? Again this appears to be = a generic function for SCTP. > >> o The partial reliability extension defined in [RFC3758] MUST be >> supported. In addition to the timed reliability PR-SCTP policy >> defined in [RFC3758], the limited retransmission policy defined in >> [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. >> >> [CHH] I see no reason for support of partial reliability - eventhough=20 >> I have to admit I am not sure what it really means. In any case, my=20 >> suggestion is that CLUE always use "full" reliability. [/CHH] >> > [CNG] For the current Advertise/Configure procedures I also would see no = support of partial reliability. However is CLUE evolves to somehow signal s= peaker changes in real time then this could come in handy. i.e.=20 > Bullet 1 clause 1.3/RFC3758. Rather than retransmission what is more impo= rtant is that the most recent speaker message is processed. It would preven= t a momentary audio/video switch. > > As for limited retransmissions I'm not sure what the applicability would = be to a CLUE channel? Also, don't think that you can't "switch" between reliable and non-reliable= . >> Once support for message interleaving as currently being discussed in >> >> [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported. >> >> [CHH] Assuming we can rely on application-level fragmentation, I=20 >> assume we would not need it. But, again, I am not familiar with the=20 >> details of message interleaving. [/CHH] >> > [CNG] We currently don't have CLUE level fragmentation. Were you thinking= of something else? That is what PPID value 51 is used for. It basically indicates "More inform= ation is coming", so the receiver will have to buffer the received data. I = don't think we need to add any extra to the CLUE protocol itself for this. My understanding is that this was used in the demo shown at the virtual int= erim? Regards, Christer From christer.holmberg@ericsson.com Wed Feb 5 02:38:21 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7B51A00D3 for ; Wed, 5 Feb 2014 02:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAs0HQ6S9W1E for ; Wed, 5 Feb 2014 02:38:19 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A8B551A00CB for ; Wed, 5 Feb 2014 02:38:18 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-92-52f214997166 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 86.81.23809.99412F25; Wed, 5 Feb 2014 11:38:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 11:38:16 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 Thread-Index: AQHPIhZDIhu/tODeLUWGz5Nb0CcnSpqmdYpw Date: Wed, 5 Feb 2014 10:38:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> In-Reply-To: <52F19B94.5040306@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje5MkU9BBneeyFh8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugStjxq/b7AUPZSv+txxlb2A8LN7FyMkhIWAi ceTGFDYIW0ziwr31QDYXh5DAIUaJM0vmMUI4ixgl1qxYzN7FyMHBJmAh0f1PG6RBRCBcomPb FUYQW1ggSGLavrOsEPFgiXsHdjJC2EYSr7edAIuzCKhIPO9fzQRi8wr4SixbcIAFYv5VRolN DfPAijgFdCR2bVsEdhEj0EXfT60Ba2AWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/scKcpuEgKLE 8n45iHIdiQW7P7FB2NoSyxa+ZobYKyhxcuYTlgmMorOQTJ2FpGUWkpZZSFoWMLKsYmTPTczM SS832sQIjIWDW36r7mC8c07kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODil Ghi9G4QYJy/dJ/Tq1pqbKRN6f4tE9X6XDf76OiEy0fek9tW38+bn1NxxPzDjfWxV5+eDdV6L ZLeGTdEU+P5VozqVo/NYibmSX+Py/LxFmwJ/OxXs9e13U2M5I7B9SeHK7boS4THSO7JX2d/Z +VBken/Wj8gajrP/p228qTb7yJxDRVs6J7jmOXkpsRRnJBpqMRcVJwIA8Hx2dFMCAAA= Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 10:38:21 -0000 Hi Christian, >>> 6.3 probably can be copied. >> To me section 6.3 is teach-yourself-SCTP :) >> > But, maybe we could add the text to section 2, as a definition for "SCTP = stream"? > [CNG] I don't think it hurt to give some back ground. We have to remember= people who implement this won't necessarily be across of the discussions i= n RTCweb. No, but it would be good if they had some knowledge of SCTP :) Anyway, what about something like the following for section 2: "[RFC4960] defines a SCTP stream as a unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. [RFC4960] defines a SCTP identifier as a unsigned integer, which identifies an SCTP stream." >>> It wouldn't hurt to state that for CLUE messages. Section 6.4 could be = altered slightly for CLUE. >> I think section 6.4 is more or less what I currently have in section 3.2= .1. But, maybe it should be added to a "Channel Definition" section. > [CNG] Yes pretty much along the lines of section 3.2.1. Will an endpoint = only ever have two CLUE channels (one send/one receive) per=20 > SCTP association? This is what I was trying to clarify on the MMUSIC list= with respect to CLUE and other application protocols like bfcp/t.38 etc. Something like this: "3.2. CLUE Data Channel Definition The realization of a bidirectional CLUE Data Channel is a pair of one incoming SCTP stream and one outgoing SCTP stream. These streams are then used to transport CLUE messages in both directions. The SCTP streams MUST belong to the same SCTP association. The SCTP streams SHOULD have identical SCTP stream identifier values, unless a specific value is already used for some other purpose. OPEN ISSUE: We need to see whether the usage of identical SCTP stream ID values need to be mandated." >>> Section 6.5 would need to be updated for the CLUE. >> Yes. Because, as we DO have an "external mechanism" (SDP Offer/Answer) t= o negotiate the channel, we don't need to be a generic. >> >>> Section 3: [I-D.stewart-tsvwg-sctp-ndata] defines interleaving for=20 >>> large messages. This is probably something we would want to support in = CLUE given the potential for large messages. It would be captured if we wer= e to follow section 6 as per above. >> Well, we need to discuss whether we need to support/mandate interleaving= , or whether application fragmentation is enough. >> >>> General: As a clue document I think we shouldn't assume that a CLUE=20 >>> implementer is across the RTCWEB work. E.g. section 3.2.2 of your=20 >>> draft would be a bit bewildering. What relevance is a DOMstring=20 >>> (which isn't well defined by draft-ietf-rtcweb-data-channel-05) PID=20 >>> 51 to CLUE. Why >>> PID50 for CLUE? >> Yes. This is part of the general opinion that we need more details on wh= y certain selections have been done, and that 50 and 51 are used to provide= interoperability with rtcweb. > [CNG] If RTCweb is not used do we expect the CLUE data to be formatted as= a "javascript strings"? What does using a "javascript string" imply with r= espect=20 > to the CLUE data model? Again we should assume no knowledge of RTCWEB for= a CLUE implementation so I think we have to go into some detail what this = means. As far as I understand, there is nothing strange about a "javascript string= " - it's a normal string. In my opinion, as the PPID values 50 and 51 are defined in the rtcweb data = channel draft, that draft needs to be clear on what it means. But, we can t= hen of course reference that definition in our draft. Regards, Christer From christer.holmberg@ericsson.com Wed Feb 5 03:14:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1091A00DE for ; Wed, 5 Feb 2014 03:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IypMn7FGCMF for ; Wed, 5 Feb 2014 03:14:49 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C9CFB1A00B2 for ; Wed, 5 Feb 2014 03:14:48 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-e5-52f21d277459 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 87.0B.04249.72D12F25; Wed, 5 Feb 2014 12:14:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 12:14:47 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Correct PPID values Thread-Index: Ac8iYw+fQNbHDJueSNqYzo9vUje5OQ== Date: Wed, 5 Feb 2014 11:14:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15BCF1@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_7594FB04B1934943A5C02806D1A2204B1D15BCF1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvja667Kcgg6uLtCz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujP1T97EX3JKuWL7wF0sD42mJLkZODgkBE4kjq84yQ9hiEhfu rWcDsYUEjjBKvNln28XIBWQvYpRYc2I3SxcjBwebgIVE9z9tkBoRAWWJo5v7weqFBWQkZl+e zQZSIiKgKHH0cy5EiZ7EkrWf2UFsFgEViU9nLrKClPAK+EqceesMEmYE2vr91BomEJtZQFzi 1pP5TBDXCEgs2XMe6jJRiZeP/4G1SgBNX94vB1GeL9Fw5RTYAbwCghInZz5hmcAoNAvJpFlI ymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDmKU4uTctONDDYxAgP+4JbfFjsY L/+1OcQozcGiJM778a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGGmnPOTu4upvMf57r Xz9FQaTskfyfaQ8mbDiVsUFwooNMO6/iw38d23v2uPedFlD7+dI6vT1oRnpEx++Z8ysm9wZt jZJ3zPqsaGzcYFY+I+nJbJtX/dc6FBKVdn2fe054qt7lTrUV6ydJP+24IhrZ3fDBsbE2e8fZ IPF8I/0n5X5vpye6PuJRYinOSDTUYi4qTgQAEVuDtUYCAAA= Subject: [clue] Correct PPID values X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 11:14:50 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D15BCF1ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I noticed that, in the CLUE data channel draft, and in the associated e-mai= l discussions, I have been talking about usage of PPID values 50 and 51 whe= n transporting CLUE protocol messages. The correct values are 51 (DOMString Last )and 54 (DOMString Partial). 50 is used for the rtcweb data channel protocol. Sorry for the confusion. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D15BCF1ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I noticed that, in the CLUE data channel draft, and = in the associated e-mail discussions, I have been talking about usage of PP= ID values 50 and 51 when transporting CLUE protocol messages.

 

The correct values are 51 (= DOMString Last )and 54 (DOMString Partial).

 

50 is used for the rtcweb data channel protocol.

 

Sorry for the confusion.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D15BCF1ESESSMB209erics_-- From Mark.Duckworth@polycom.com Wed Feb 5 05:02:05 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04171A00FE for ; Wed, 5 Feb 2014 05:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyMtwrEyKyMk for ; Wed, 5 Feb 2014 05:02:04 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id EB5271A00DD for ; Wed, 5 Feb 2014 05:02:03 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 5 Feb 2014 05:02:03 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Wed, 5 Feb 2014 05:02:01 -0800 Thread-Topic: [clue] Consensus call: Spatial information within composed MCC Thread-Index: Ac8h/yTcn6lhSFH+TR2romNInQHpmwAcxw7A Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FAB29@CRPMBOXPRD07.polycom.com> References: <0D8D8A12-3772-4A8E-A7D8-5AE6C3E23BD5@vidyo.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D1ED819@CRPMBOXPRD07.polycom.com> <52F174C5.1020306@nteczone.com> In-Reply-To: <52F174C5.1020306@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] Consensus call: Spatial information within composed MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 13:02:05 -0000 I agree with Christian's comment on 1. I think the "maxcaptures issue" is a separate thing, unrelated to Mary's co= nsensus call. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Tuesday, February 04, 2014 6:16 PM > To: clue@ietf.org > Subject: Re: [clue] Consensus call: Spatial information within composed M= CC >=20 > Just a further clarification to 1. > 1. What we're not supporting is the spatial description of the individual= sub- > parts of a composed capture (whether they are individual captures or othe= r > composed captures).... >=20 > Was that the understanding from the meeting? >=20 > Also the clarifications don't cover the "maxcaptures" issue that I raised= in a > previous email. >=20 > Regards, Christian >=20 > On 5/02/2014 4:27 AM, Duckworth, Mark wrote: > > > > I agree with Jonathan's clarifications. > > > > Mark > > > > *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Jonathan > > Lennox > > *Sent:* Tuesday, February 04, 2014 11:33 AM > > *To:* Mary Barnes > > *Cc:* CLUE > > *Subject:* Re: [clue] Consensus call: Spatial information within > > composed MCC > > > > On Feb 3, 2014, at 7:39 PM, Mary Barnes > > > > > > wrote: > > > > > > > > As Mark noted in his last email in this thread, there was consensus at > > the virtual interim last Monday (as well as previously when we closed > > ticket #5) that CLUE would not support the use of spatial information > > with regards to composed captures: > > > > http://www.ietf.org/mail-archive/web/clue/current/msg03304.html > > > > While there appears not to be unanimous consensus on the mailing list, > > the chairs believe that we do have rough consensus (based on majority > > support) within the WG per IETF procedures. > > > > I just wanted to state more clearly my understanding of this > > consensus. I don't think there was confusion about this among the > > people at the interim, but it's good to have things explicit. > > > > 1. What we're not supporting is the spatial description of the > > individual sub-parts of a composed capture. A composed MCC may itself > > have spatial information, to indicate, for instance, the intended > > geometric association of several composed MCCs. > > > > 2. We're not saying that the CLUE protocol MUST NOT ever support this > > in any future extension; simply that we're not intending to define how > > to describe it in the initial version of the protocol. > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Feb 5 07:11:04 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFCA1A01E0 for ; Wed, 5 Feb 2014 07:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcRBEeayddx3 for ; Wed, 5 Feb 2014 07:11:02 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id A55451A0192 for ; Wed, 5 Feb 2014 07:11:02 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id Ndi11n0061ap0As51fB1fo; Wed, 05 Feb 2014 15:11:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id NfB11n0163ZTu2S3ifB135; Wed, 05 Feb 2014 15:11:01 +0000 Message-ID: <52F25485.2070909@alum.mit.edu> Date: Wed, 05 Feb 2014 10:11:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D1586CE@ESESSMB209.ericsson.se> <52F1985A.8070006@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15B6B5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15B6B5@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=1391613061; bh=uxEfZtFtNCHqZM7GwvtLLRwvYOyfvjtP859S2ZVLmLc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=he62UcHob/Jm3HED+UGb9lllj3jAzy/1qNDkmIzWS5TM2rI2rWXgr1N2Rm4e7JBNy oCdC85x7Z6+iNYPqGpARxdoKJMdhvrsiMO5S6nmSEEzzzGfeG4vWp6hSeFmmnQcGTb ubge4AFAWaQfR8UPg5tjBpc2UhLcmtRVzbotgCtengJuQAC8C28Q+Y+BkVifXlTyxk rdWgOoW+StV4FObLJmoYtvF+lmak/TbSXEnHl0RdQkGuMYdvK5hZM8rp7y0YkJ/ZiS ezeDpnkAv/Y4/HBxk0ZJWv+01ED47kPxAiCueonuSL/kkFyg5Q8mt3S7vrwBd473Ka I9jO6B+nqbGvQ== Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:11:04 -0000 Regarding fragmentation, my understanding is that there is an SCTP extension that handles the fragmentation at the SCTP layer, but that it is not yet ready for prime time. So for the webrtc data channel they have proposes to do application level fragmentation initially. One purpose of fragmentation is to solve head of line blocking problems. That won't be a problem for clue *if* the clue channel is the only use of the association. But we should not assume that. If we want to be compatible with rtcweb, then we need to be compatible with their fragmentation rules too. Thanks, Paul On 2/5/14 2:40 AM, Christer Holmberg wrote: > Hi Christian, > >> Part of the reason I suggested to use those sections of rtcweb-data-channel is so that we can make an educated decision about what we want to support for CLUE. > > I could add the text, and indicate that the CLUE usage is FFS. > >>> Christian earlier suggested that we could copy/paste section 6.1 from >>> the rtcweb-data-channel draft into our draft. >>> >>> I think we need to consider whether we really need the features listed >>> in that chapter (unless, of course, the usage of them is mandated in >>> order to be compatible with rtcweb). >>> >> [CNG] I agree. However if we say functions are not supported CLUE and RTCWEB says that they must be supported. What does >> that mean? e.g. We mandate the use of RTCweb data channel for CLUE. Therefore the rules of RTCweb data channel apply. Stream reset extension MUST be supported. >> However for CLUE we say it shouldn't be supported. The endpoint is not an RTCWEB endpoint it only supports CLUE over SCTP. So does it need to implement stream reset or not? > > Those are things we need to clarify with RTCWEB. > >>> The features are listed below, with some initial comments ([CHH]). >>> >>> o The stream reset extension defined in [RFC6525] MUST be supported. >>> It is used for closing channels. >>> >>> [CHH] I may have misunderstood RFC6526, but I don't think this is for >>> CLOSING channels. It's for reseting the number sequence, which I think >>> is a different thing. >>> >>> In any case, I currently see no reason why we would need to mandate >>> support of this in CLUE. [/CHH] >>> >> [CNG] I think the "resetting" is part of closing a channel. The resetting is done so that you can use the channel for another protocol. >> I'd say this has more of a general applicability An endpoint may want to close a channel and reuse it for CLUE or vice-versa. > > Sure. And, if someone wants to use it - fine. But, from a CLUE perspective we only have one protocol, so we don't need to mandate it. > > >>> o The dynamic address reconfiguration extension defined in [RFC5061] >>> >>> MUST be used to signal the support of the stream reset extension >>> defined in [RFC6525], other features of [RFC5061] MUST NOT be >>> used. >>> >>> [CHH] It seems like this is only used for the reset extension. The >>> other features are related to multi-homing, which is not supported by >>> SCTPoDTLS to begin with. [/CHH] >>> >> [CNG] I guess to be precise they only want the support of clause >> 4.2.7/RFC5061 "Supported Extensions Parameter"? Again this appears to be a generic function for SCTP. >> >>> o The partial reliability extension defined in [RFC3758] MUST be >>> supported. In addition to the timed reliability PR-SCTP policy >>> defined in [RFC3758], the limited retransmission policy defined in >>> [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. >>> >>> [CHH] I see no reason for support of partial reliability - eventhough >>> I have to admit I am not sure what it really means. In any case, my >>> suggestion is that CLUE always use "full" reliability. [/CHH] >>> >> [CNG] For the current Advertise/Configure procedures I also would see no support of partial reliability. However is CLUE evolves to somehow signal speaker changes in real time then this could come in handy. i.e. >> Bullet 1 clause 1.3/RFC3758. Rather than retransmission what is more important is that the most recent speaker message is processed. It would prevent a momentary audio/video switch. >> >> As for limited retransmissions I'm not sure what the applicability would be to a CLUE channel? > > Also, don't think that you can't "switch" between reliable and non-reliable. > >>> Once support for message interleaving as currently being discussed in >>> >>> [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported. >>> >>> [CHH] Assuming we can rely on application-level fragmentation, I >>> assume we would not need it. But, again, I am not familiar with the >>> details of message interleaving. [/CHH] >>> >> [CNG] We currently don't have CLUE level fragmentation. Were you thinking of something else? > > That is what PPID value 51 is used for. It basically indicates "More information is coming", so the receiver will have to buffer the received data. I don't think we need to add any extra to the CLUE protocol itself for this. > > My understanding is that this was used in the demo shown at the virtual interim? > > Regards, > > Christer > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Wed Feb 5 07:18:39 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEBA1A020B for ; Wed, 5 Feb 2014 07:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcDXvUs7Ciz7 for ; Wed, 5 Feb 2014 07:18:35 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 347D41A0205 for ; Wed, 5 Feb 2014 07:18:35 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-3c-52f2564928b6 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 9E.CA.04249.94652F25; Wed, 5 Feb 2014 16:18:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 16:18:32 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? Thread-Index: Ac8htYEgN7eZRc+7Td6fweMbfzckWwAVm/YAAA4NnfAADfxtgAACSuqA Date: Wed, 5 Feb 2014 15:18:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15C54E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1586CE@ESESSMB209.ericsson.se> <52F1985A.8070006@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15B6B5@ESESSMB209.ericsson.se> <52F25485.2070909@alum.mit.edu> In-Reply-To: <52F25485.2070909@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvja5n2Kcgg2Wr9C32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj9c7FTAWr9Spetj1jb2Bcr9rFyMkhIWAi 8WTNWyYIW0ziwr31bF2MXBxCAkcYJT5e2QGWEBJYxCjR+JKzi5GDg03AQqL7nzZIWETAU2LH xynMILawQIxEd9sxJoh4rMSPCTPZIWw3iZ6/6xhBbBYBFYnpXz+xgti8Ar4Svx43skLsusoo MXX1UbBmTgEdicWzPoANZQQ66PupNWBxZgFxiVtP5kMdKiCxZM95ZghbVOLl43+sILdJCChK LO+XgyjXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDoLydRZSFpmIWmZhaRlASPLKkaO4tTi pNx0I4NNjMBYOLjlt8UOxst/bQ4xSnOwKInzfnzrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmD U6qBMf5KcoeSh9fB61qJKz88vPnsdrD79fdlqef2fPafLrLkyuVPTzh3CotdeP2pJHcGU5Dv owvdT17qH9md437/5ZVd6qp/t8634Yw9bc6vvnHmrzUit27lfLMVK4ppeSyxYOd/Vx+t5cEa NjUNs3fqHWI09e7l/OCcfrY1of1QyJF0wYjOJy2OpUosxRmJhlrMRcWJAMS0OiBTAgAA Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:18:39 -0000 Hi, >Regarding fragmentation, my understanding is that there is an SCTP extensi= on that handles the fragmentation at the SCTP layer, but that=20 >it is not yet ready for prime time. So for the webrtc data channel they ha= ve proposes to do application level fragmentation initially. > >One purpose of fragmentation is to solve head of line blocking problems.=20 >That won't be a problem for clue *if* the clue channel is the only use of = the association. But we should not assume that. > >If we want to be compatible with rtcweb, then we need to be compatible wit= h their fragmentation rules too. If the fragmentation can't be controlled by the JavaScript application, the= n I agree with you. If the fragmentation can be controlled by the JavaScript application, then = we can simply say not to use it. Anyway, I have no problem to align with rtcweb, if we think it's feasible. = Figuring such things out is part of the whole exercise :) Regards, Christer On 2/5/14 2:40 AM, Christer Holmberg wrote: > Hi Christian, > >> Part of the reason I suggested to use those sections of rtcweb-data-chan= nel is so that we can make an educated decision about what we want to suppo= rt for CLUE. > > I could add the text, and indicate that the CLUE usage is FFS. > >>> Christian earlier suggested that we could copy/paste section 6.1=20 >>> from the rtcweb-data-channel draft into our draft. >>> >>> I think we need to consider whether we really need the features=20 >>> listed in that chapter (unless, of course, the usage of them is=20 >>> mandated in order to be compatible with rtcweb). >>> >> [CNG] I agree. However if we say functions are not supported CLUE and=20 >> RTCWEB says that they must be supported. What does that mean? e.g. We ma= ndate the use of RTCweb data channel for CLUE. Therefore the rules of RTCwe= b data channel apply. Stream reset extension MUST be supported. >> However for CLUE we say it shouldn't be supported. The endpoint is not a= n RTCWEB endpoint it only supports CLUE over SCTP. So does it need to imple= ment stream reset or not? > > Those are things we need to clarify with RTCWEB. > >>> The features are listed below, with some initial comments ([CHH]). >>> >>> o The stream reset extension defined in [RFC6525] MUST be supported. >>> It is used for closing channels. >>> >>> [CHH] I may have misunderstood RFC6526, but I don't think this is=20 >>> for CLOSING channels. It's for reseting the number sequence, which I=20 >>> think is a different thing. >>> >>> In any case, I currently see no reason why we would need to mandate=20 >>> support of this in CLUE. [/CHH] >>> >> [CNG] I think the "resetting" is part of closing a channel. The resettin= g is done so that you can use the channel for another protocol. >> I'd say this has more of a general applicability An endpoint may want to= close a channel and reuse it for CLUE or vice-versa. > > Sure. And, if someone wants to use it - fine. But, from a CLUE perspectiv= e we only have one protocol, so we don't need to mandate it. > > >>> o The dynamic address reconfiguration extension defined in [RFC5061] >>> >>> MUST be used to signal the support of the stream reset extension=20 >>> defined in [RFC6525], other features of [RFC5061] MUST NOT be used. >>> >>> [CHH] It seems like this is only used for the reset extension. The=20 >>> other features are related to multi-homing, which is not supported=20 >>> by SCTPoDTLS to begin with. [/CHH] >>> >> [CNG] I guess to be precise they only want the support of clause >> 4.2.7/RFC5061 "Supported Extensions Parameter"? Again this appears to be= a generic function for SCTP. >> >>> o The partial reliability extension defined in [RFC3758] MUST be=20 >>> supported. In addition to the timed reliability PR-SCTP policy=20 >>> defined in [RFC3758], the limited retransmission policy defined in=20 >>> [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. >>> >>> [CHH] I see no reason for support of partial reliability -=20 >>> eventhough I have to admit I am not sure what it really means. In=20 >>> any case, my suggestion is that CLUE always use "full" reliability.=20 >>> [/CHH] >>> >> [CNG] For the current Advertise/Configure procedures I also would see no= support of partial reliability. However is CLUE evolves to somehow signal = speaker changes in real time then this could come in handy. i.e. >> Bullet 1 clause 1.3/RFC3758. Rather than retransmission what is more imp= ortant is that the most recent speaker message is processed. It would preve= nt a momentary audio/video switch. >> >> As for limited retransmissions I'm not sure what the applicability would= be to a CLUE channel? > > Also, don't think that you can't "switch" between reliable and non-reliab= le. > >>> Once support for message interleaving as currently being discussed=20 >>> in >>> >>> [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported. >>> >>> [CHH] Assuming we can rely on application-level fragmentation, I=20 >>> assume we would not need it. But, again, I am not familiar with the=20 >>> details of message interleaving. [/CHH] >>> >> [CNG] We currently don't have CLUE level fragmentation. Were you thinkin= g of something else? > > That is what PPID value 51 is used for. It basically indicates "More info= rmation is coming", so the receiver will have to buffer the received data. = I don't think we need to add any extra to the CLUE protocol itself for this= . > > My understanding is that this was used in the demo shown at the virtual i= nterim? > > Regards, > > Christer > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Feb 5 07:30:52 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426641A01BF for ; Wed, 5 Feb 2014 07:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eakec7y2vFp5 for ; Wed, 5 Feb 2014 07:30:50 -0800 (PST) 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 103131A0193 for ; Wed, 5 Feb 2014 07:30:49 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta10.westchester.pa.mail.comcast.net with comcast id Nd6E1n00317dt5G5AfWpFz; Wed, 05 Feb 2014 15:30:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id NfWo1n00u3ZTu2S3ZfWp5e; Wed, 05 Feb 2014 15:30:49 +0000 Message-ID: <52F25928.40404@alum.mit.edu> Date: Wed, 05 Feb 2014 10:30:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15BB42@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=1391614249; bh=GTuTqDaBd/W4Z7sH5FEbLu/iC85MDly9AGn9nUjppWs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Dp/jTfVkCvfNgdVyf/ZHrsjP3mMZL3ayBcdA1zfo8PA4KmucCqw668frAqlyN1zdA Pu4mfy/JLZ0qzs6JqnPldpmv+I/vz7VGUTDBGxERMGgbubYYiHvTbMQe9x4WGiKF41 c5EFRkpLULgDC1XKsWIUuRn2tULWynAEVMNz1LgkXH4sayecysDl5N3sW9+Yf5+xdu R1YkW5qzpBeo8MV8wy5bBx01cyU1Hs/wIhWGWqiBuEVD/rDObAWQX8YgoyBTT+N7bo AlrZdJqdONyEkNrBz+U7EDL3vH8O2HnkmrMW+T5hZAJJfenxvemL3maetdqZquR1+L B8mJfR1BsStFQ== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:30:52 -0000 Inline On 2/5/14 5:38 AM, Christer Holmberg wrote: > Hi Christian, > >>>> 6.3 probably can be copied. >>> To me section 6.3 is teach-yourself-SCTP :) >>> >> But, maybe we could add the text to section 2, as a definition for "SCTP stream"? >> [CNG] I don't think it hurt to give some back ground. We have to remember people who implement this won't necessarily be across of the discussions in RTCweb. > > No, but it would be good if they had some knowledge of SCTP :) > > Anyway, what about something like the following for section 2: > > "[RFC4960] defines a SCTP stream as a unidirectional logical channel > established from one to another associated SCTP endpoint, within > which all user messages are delivered in sequence except for those > submitted to the unordered delivery service. > > [RFC4960] defines a SCTP identifier as a unsigned integer, which > identifies an SCTP stream." > > >>>> It wouldn't hurt to state that for CLUE messages. Section 6.4 could be altered slightly for CLUE. >>> I think section 6.4 is more or less what I currently have in section 3.2.1. But, maybe it should be added to a "Channel Definition" section. >> [CNG] Yes pretty much along the lines of section 3.2.1. Will an endpoint only ever have two CLUE channels (one send/one receive) per >> SCTP association? AFAIK we have not settled on that yet. Two possibilities have been discussed: - one bidirectional channel (one outgoing and one incoming SCTP stream) used for: sending clue requests and responses, receiving clue requests and responses. - two bidirectional channels: . one for sending clue requests and receiving clue responses (provider role) . one for receiving clue requests and sending clue responses (consumer role) Using two leverages sctp stream multiplexing to handle the multiplexing of the provider role messages with the consumer role messages. So it can simplify the implementation of the clue protocol. OTOH this means that it would be harder to map the clue protocol onto a reliable transport that doesn't have multiple streams. My impression is that there has been a preference for using a single channel, but I don't recall that we made a final decision on it. > This is what I was trying to clarify on the MMUSIC list with respect to CLUE and other application protocols like bfcp/t.38 etc. The use of one or two is a clue decision, not an mmusic decision. > Something like this: > > "3.2. CLUE Data Channel Definition > > The realization of a bidirectional CLUE Data Channel is a pair of one > incoming SCTP stream and one outgoing SCTP stream. These streams are > then used to transport CLUE messages in both directions. > > The SCTP streams MUST belong to the same SCTP association. > > The SCTP streams SHOULD have identical SCTP stream identifier values, > unless a specific value is already used for some other purpose. If it is *possible* that the two stream ids might not be identical, then we need a way to determine which ones are paired. Thanks, Paul > OPEN ISSUE: We need to see whether the usage of identical SCTP stream > ID values need to be mandated." > > >>>> Section 6.5 would need to be updated for the CLUE. >>> Yes. Because, as we DO have an "external mechanism" (SDP Offer/Answer) to negotiate the channel, we don't need to be a generic. >>> >>>> Section 3: [I-D.stewart-tsvwg-sctp-ndata] defines interleaving for >>>> large messages. This is probably something we would want to support in CLUE given the potential for large messages. It would be captured if we were to follow section 6 as per above. >>> Well, we need to discuss whether we need to support/mandate interleaving, or whether application fragmentation is enough. >>> >>>> General: As a clue document I think we shouldn't assume that a CLUE >>>> implementer is across the RTCWEB work. E.g. section 3.2.2 of your >>>> draft would be a bit bewildering. What relevance is a DOMstring >>>> (which isn't well defined by draft-ietf-rtcweb-data-channel-05) PID >>>> 51 to CLUE. Why >>>> PID50 for CLUE? >>> Yes. This is part of the general opinion that we need more details on why certain selections have been done, and that 50 and 51 are used to provide interoperability with rtcweb. >> [CNG] If RTCweb is not used do we expect the CLUE data to be formatted as a "javascript strings"? What does using a "javascript string" imply with respect >> to the CLUE data model? Again we should assume no knowledge of RTCWEB for a CLUE implementation so I think we have to go into some detail what this means. > > As far as I understand, there is nothing strange about a "javascript string" - it's a normal string. > > In my opinion, as the PPID values 50 and 51 are defined in the rtcweb data channel draft, that draft needs to be clear on what it means. But, we can then of course reference that definition in our draft. > > Regards, > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Wed Feb 5 07:36:05 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBD51A019D for ; Wed, 5 Feb 2014 07:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jekptkq9GIG9 for ; Wed, 5 Feb 2014 07:36:02 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id F24401A0192 for ; Wed, 5 Feb 2014 07:36:01 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-94-52f25a600065 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id DB.BC.04249.06A52F25; Wed, 5 Feb 2014 16:36:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 16:36:00 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? Thread-Index: Ac8htYEgN7eZRc+7Td6fweMbfzckWwAVm/YAAA4NnfAADfxtgAACSuqAAACbc5A= Date: Wed, 5 Feb 2014 15:36:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15C604@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1586CE@ESESSMB209.ericsson.se> <52F1985A.8070006@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15B6B5@ESESSMB209.ericsson.se> <52F25485.2070909@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C54E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15C54E@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvjW5C1Kcgg10LDCz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj8u/57AUHTCrmTL3L2sC4Q6uLkZNDQsBE 4nbDeyYIW0ziwr31bF2MXBxCAkcYJWYcfcQC4SxilNi1fgZzFyMHB5uAhUT3P22QBhEBT4kd H6cwg9jCAjES3W3HmCDisRI/JsxkBykXEfCTaO3mBgmzCKhIzL80hQ3E5hXwldjVcAxq/Ewm iU8H+1lAEpxA9a/fXACzGYEO+n5qDdhMZgFxiVtP5kMdKiCxZM95ZghbVOLl43+sILskBBQl lvfLQZTrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJ2FZOosJC2zkLTMQtKygJFlFSNHcWpx Um66kcEmRmAsHNzy22IH4+W/NocYpTlYlMR5P751DhISSE8sSc1OTS1ILYovKs1JLT7EyMTB KdXAqLW99KBAmON1PZmJnmpKa5fmL/+SWBEtd/Rd4d/Lu432r2oqnK/tw37yj8i08pv3hbSb lu77uEriLGvDocnz/cLO3VzFKMzAp2B258nOpfpvqjrZ1kbufprAuOHX76lrChqqy1TP+094 Junx8m163KKfV5uX3lP6a+IWdZPpmGDNBp93Z+fZiSuxFGckGmoxFxUnAgCx+yAfUwIAAA== Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:36:05 -0000 Hi, I found the following text in section 3.1. draft-stewart-tsvwg-sctp-ndata-0= 3.txt: "A sender MUST NOT send a N-DATA chunk unless the peer has indicated its support of the N-DATA chunk type within the Supported Extensions Parameter as defined in [RFC5061]." So, it seems like there will be an in-band negotiation regarding usage of i= nterleaving. Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 5. helmikuuta 2014 17:19 To: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones doe= s CLUE require? Hi, >Regarding fragmentation, my understanding is that there is an SCTP=20 >extension that handles the fragmentation at the SCTP layer, but that it is= not yet ready for prime time. So for the webrtc data channel they have pro= poses to do application level fragmentation initially. > >One purpose of fragmentation is to solve head of line blocking problems.=20 >That won't be a problem for clue *if* the clue channel is the only use of = the association. But we should not assume that. > >If we want to be compatible with rtcweb, then we need to be compatible wit= h their fragmentation rules too. If the fragmentation can't be controlled by the JavaScript application, the= n I agree with you. If the fragmentation can be controlled by the JavaScript application, then = we can simply say not to use it. Anyway, I have no problem to align with rtcweb, if we think it's feasible. = Figuring such things out is part of the whole exercise :) Regards, Christer On 2/5/14 2:40 AM, Christer Holmberg wrote: > Hi Christian, > >> Part of the reason I suggested to use those sections of rtcweb-data-chan= nel is so that we can make an educated decision about what we want to suppo= rt for CLUE. > > I could add the text, and indicate that the CLUE usage is FFS. > >>> Christian earlier suggested that we could copy/paste section 6.1=20 >>> from the rtcweb-data-channel draft into our draft. >>> >>> I think we need to consider whether we really need the features=20 >>> listed in that chapter (unless, of course, the usage of them is=20 >>> mandated in order to be compatible with rtcweb). >>> >> [CNG] I agree. However if we say functions are not supported CLUE and=20 >> RTCWEB says that they must be supported. What does that mean? e.g. We ma= ndate the use of RTCweb data channel for CLUE. Therefore the rules of RTCwe= b data channel apply. Stream reset extension MUST be supported. >> However for CLUE we say it shouldn't be supported. The endpoint is not a= n RTCWEB endpoint it only supports CLUE over SCTP. So does it need to imple= ment stream reset or not? > > Those are things we need to clarify with RTCWEB. > >>> The features are listed below, with some initial comments ([CHH]). >>> >>> o The stream reset extension defined in [RFC6525] MUST be supported. >>> It is used for closing channels. >>> >>> [CHH] I may have misunderstood RFC6526, but I don't think this is=20 >>> for CLOSING channels. It's for reseting the number sequence, which I=20 >>> think is a different thing. >>> >>> In any case, I currently see no reason why we would need to mandate=20 >>> support of this in CLUE. [/CHH] >>> >> [CNG] I think the "resetting" is part of closing a channel. The resettin= g is done so that you can use the channel for another protocol. >> I'd say this has more of a general applicability An endpoint may want to= close a channel and reuse it for CLUE or vice-versa. > > Sure. And, if someone wants to use it - fine. But, from a CLUE perspectiv= e we only have one protocol, so we don't need to mandate it. > > >>> o The dynamic address reconfiguration extension defined in [RFC5061] >>> >>> MUST be used to signal the support of the stream reset extension=20 >>> defined in [RFC6525], other features of [RFC5061] MUST NOT be used. >>> >>> [CHH] It seems like this is only used for the reset extension. The=20 >>> other features are related to multi-homing, which is not supported=20 >>> by SCTPoDTLS to begin with. [/CHH] >>> >> [CNG] I guess to be precise they only want the support of clause >> 4.2.7/RFC5061 "Supported Extensions Parameter"? Again this appears to be= a generic function for SCTP. >> >>> o The partial reliability extension defined in [RFC3758] MUST be=20 >>> supported. In addition to the timed reliability PR-SCTP policy=20 >>> defined in [RFC3758], the limited retransmission policy defined in=20 >>> [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. >>> >>> [CHH] I see no reason for support of partial reliability -=20 >>> eventhough I have to admit I am not sure what it really means. In=20 >>> any case, my suggestion is that CLUE always use "full" reliability. >>> [/CHH] >>> >> [CNG] For the current Advertise/Configure procedures I also would see no= support of partial reliability. However is CLUE evolves to somehow signal = speaker changes in real time then this could come in handy. i.e. >> Bullet 1 clause 1.3/RFC3758. Rather than retransmission what is more imp= ortant is that the most recent speaker message is processed. It would preve= nt a momentary audio/video switch. >> >> As for limited retransmissions I'm not sure what the applicability would= be to a CLUE channel? > > Also, don't think that you can't "switch" between reliable and non-reliab= le. > >>> Once support for message interleaving as currently being discussed=20 >>> in >>> >>> [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported. >>> >>> [CHH] Assuming we can rely on application-level fragmentation, I=20 >>> assume we would not need it. But, again, I am not familiar with the=20 >>> details of message interleaving. [/CHH] >>> >> [CNG] We currently don't have CLUE level fragmentation. Were you thinkin= g of something else? > > That is what PPID value 51 is used for. It basically indicates "More info= rmation is coming", so the receiver will have to buffer the received data. = I don't think we need to add any extra to the CLUE protocol itself for this= . > > My understanding is that this was used in the demo shown at the virtual i= nterim? > > Regards, > > Christer > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Feb 5 07:42:37 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F211A0193 for ; Wed, 5 Feb 2014 07:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pDs8lBITHdf for ; Wed, 5 Feb 2014 07:42:35 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 071611A00FD for ; Wed, 5 Feb 2014 07:42:34 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta15.westchester.pa.mail.comcast.net with comcast id NfWo1n0060EZKEL5Ffiaax; Wed, 05 Feb 2014 15:42:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id NfiZ1n0133ZTu2S3Mfiau9; Wed, 05 Feb 2014 15:42:34 +0000 Message-ID: <52F25BE9.9080907@alum.mit.edu> Date: Wed, 05 Feb 2014 10:42:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1586CE@ESESSMB209.ericsson.se> <52F1985A.8070006@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15B6B5@ESESSMB209.ericsson.se> <52F25485.2070909@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C54E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15C604@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15C604@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=1391614954; bh=vr+IuFcOTicRbXpa2V9b+XSuXGNXlRyE9U5jACoPijo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KeHGcs4V8K94QhIiVRFV72shkTdkVvG7Qb/IXsnlTcH/QLHIOl7JiVZDR9AWc8O8q 09sW/hTQAJdNsmDAz0ekuWc876Nn6y77mjUCNlE3foXGaPW1CgG33V6a818Git7MAQ GSER5xQWUM4Y7JYM0puXQCzhfS0k2ERkp1TXr3cUe4T0sOMOixAVll8W8iUvyQu1Rf 8pb7O/heKtN+cN1vUzVuDJ/wwZMZSS/QiL+MYULX9FdoCNkAFFNbrEW8GMZhrqwAsz KmEwpc3VUpHZbHQzhLy9mQ1Vwvbi807ksvUXg6Isd7FzP1zNze5C9gXc9fgvnlgMx6 9A2tO9sT2KRfw== Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:42:37 -0000 Unfortunately it seems that fragmentation is an issue we will not be able to ignore. Thanks, Paul On 2/5/14 10:36 AM, Christer Holmberg wrote: > Hi, > > I found the following text in section 3.1. draft-stewart-tsvwg-sctp-ndata-03.txt: > > "A sender MUST NOT send a N-DATA chunk unless the peer has indicated > its support of the N-DATA chunk type within the Supported Extensions > Parameter as defined in [RFC5061]." > > So, it seems like there will be an in-band negotiation regarding usage of interleaving. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 5. helmikuuta 2014 17:19 > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? > > Hi, > >> Regarding fragmentation, my understanding is that there is an SCTP >> extension that handles the fragmentation at the SCTP layer, but that it is not yet ready for prime time. So for the webrtc data channel they have proposes to do application level fragmentation initially. >> >> One purpose of fragmentation is to solve head of line blocking problems. >> That won't be a problem for clue *if* the clue channel is the only use of the association. But we should not assume that. >> >> If we want to be compatible with rtcweb, then we need to be compatible with their fragmentation rules too. > > If the fragmentation can't be controlled by the JavaScript application, then I agree with you. > > If the fragmentation can be controlled by the JavaScript application, then we can simply say not to use it. > > Anyway, I have no problem to align with rtcweb, if we think it's feasible. Figuring such things out is part of the whole exercise :) > > Regards, > > Christer > > > On 2/5/14 2:40 AM, Christer Holmberg wrote: >> Hi Christian, >> >>> Part of the reason I suggested to use those sections of rtcweb-data-channel is so that we can make an educated decision about what we want to support for CLUE. >> >> I could add the text, and indicate that the CLUE usage is FFS. >> >>>> Christian earlier suggested that we could copy/paste section 6.1 >>>> from the rtcweb-data-channel draft into our draft. >>>> >>>> I think we need to consider whether we really need the features >>>> listed in that chapter (unless, of course, the usage of them is >>>> mandated in order to be compatible with rtcweb). >>>> >>> [CNG] I agree. However if we say functions are not supported CLUE and >>> RTCWEB says that they must be supported. What does that mean? e.g. We mandate the use of RTCweb data channel for CLUE. Therefore the rules of RTCweb data channel apply. Stream reset extension MUST be supported. >>> However for CLUE we say it shouldn't be supported. The endpoint is not an RTCWEB endpoint it only supports CLUE over SCTP. So does it need to implement stream reset or not? >> >> Those are things we need to clarify with RTCWEB. >> >>>> The features are listed below, with some initial comments ([CHH]). >>>> >>>> o The stream reset extension defined in [RFC6525] MUST be supported. >>>> It is used for closing channels. >>>> >>>> [CHH] I may have misunderstood RFC6526, but I don't think this is >>>> for CLOSING channels. It's for reseting the number sequence, which I >>>> think is a different thing. >>>> >>>> In any case, I currently see no reason why we would need to mandate >>>> support of this in CLUE. [/CHH] >>>> >>> [CNG] I think the "resetting" is part of closing a channel. The resetting is done so that you can use the channel for another protocol. >>> I'd say this has more of a general applicability An endpoint may want to close a channel and reuse it for CLUE or vice-versa. >> >> Sure. And, if someone wants to use it - fine. But, from a CLUE perspective we only have one protocol, so we don't need to mandate it. >> >> >>>> o The dynamic address reconfiguration extension defined in [RFC5061] >>>> >>>> MUST be used to signal the support of the stream reset extension >>>> defined in [RFC6525], other features of [RFC5061] MUST NOT be used. >>>> >>>> [CHH] It seems like this is only used for the reset extension. The >>>> other features are related to multi-homing, which is not supported >>>> by SCTPoDTLS to begin with. [/CHH] >>>> >>> [CNG] I guess to be precise they only want the support of clause >>> 4.2.7/RFC5061 "Supported Extensions Parameter"? Again this appears to be a generic function for SCTP. >>> >>>> o The partial reliability extension defined in [RFC3758] MUST be >>>> supported. In addition to the timed reliability PR-SCTP policy >>>> defined in [RFC3758], the limited retransmission policy defined in >>>> [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. >>>> >>>> [CHH] I see no reason for support of partial reliability - >>>> eventhough I have to admit I am not sure what it really means. In >>>> any case, my suggestion is that CLUE always use "full" reliability. >>>> [/CHH] >>>> >>> [CNG] For the current Advertise/Configure procedures I also would see no support of partial reliability. However is CLUE evolves to somehow signal speaker changes in real time then this could come in handy. i.e. >>> Bullet 1 clause 1.3/RFC3758. Rather than retransmission what is more important is that the most recent speaker message is processed. It would prevent a momentary audio/video switch. >>> >>> As for limited retransmissions I'm not sure what the applicability would be to a CLUE channel? >> >> Also, don't think that you can't "switch" between reliable and non-reliable. >> >>>> Once support for message interleaving as currently being discussed >>>> in >>>> >>>> [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported. >>>> >>>> [CHH] Assuming we can rely on application-level fragmentation, I >>>> assume we would not need it. But, again, I am not familiar with the >>>> details of message interleaving. [/CHH] >>>> >>> [CNG] We currently don't have CLUE level fragmentation. Were you thinking of something else? >> >> That is what PPID value 51 is used for. It basically indicates "More information is coming", so the receiver will have to buffer the received data. I don't think we need to add any extra to the CLUE protocol itself for this. >> >> My understanding is that this was used in the demo shown at the virtual interim? >> >> 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 Wed Feb 5 07:45:42 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581AE1A0192 for ; Wed, 5 Feb 2014 07:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Tai3vfj-z5I for ; Wed, 5 Feb 2014 07:45:40 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 922631A01D4 for ; Wed, 5 Feb 2014 07:45:39 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-f0-52f25ca165ee Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 1B.BC.04853.2AC52F25; Wed, 5 Feb 2014 16:45:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 16:45:37 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 Thread-Index: AQHPIodDilH1MCfnCk6DrsGswuJhzpqmy0SA Date: Wed, 5 Feb 2014 15:45:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> In-Reply-To: <52F25928.40404@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvje6imE9BBiuO81rsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGug8iBTNEK6aua2BvYDwu0MXIySEhYCLx fNVHVghbTOLCvfVsXYxcHEICJxglTjS9YoRwFjFKzLn0mr2LkYODTcBCovufNkiDiICnxI6P U5hBbGGBIInb9++yQMSDJRbt38oOYRtJnH/RzAhiswioSOzYNwesnlfAV+Ligbdg9UICO5kk NtxXBbE5BbQkpu7vAKtnBDro+6k1TCA2s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/VpDTJAQU JZb3y0GU60gs2P2JDcLWlli28DXUWkGJkzOfsExgFJ2FZOosJC2zkLTMQtKygJFlFaNkcWpx cW66kYFebnpuiV5qUWZycXF+nl5x6iZGYKwc3PLbaAfjyT32hxilOViUxHmvs9YECQmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamA0yRLtnvalvs9EadWl9HnSwX47w2dyXGp8v1TmqpLt5tSu 5xYL17FFVfO9nLRG6/Ppb8WHa7LSp7wrbMnOkP07kf8ia9P8O9s1stz8GK8efFa7eaagjEvg t04ttolbMnbzG144b83rYRP3tO31oTPq995kCTGzu5npN27acHlnybM2Vz/jx61KLMUZiYZa zEXFiQDAWQ0aYwIAAA== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:45:42 -0000 Hi, >>>>> It wouldn't hurt to state that for CLUE messages. Section 6.4 could b= e altered slightly for CLUE. >>>> I think section 6.4 is more or less what I currently have in section 3= .2.1. But, maybe it should be added to a "Channel Definition" section. >>> [CNG] Yes pretty much along the lines of section 3.2.1. Will an=20 >>> endpoint only ever have two CLUE channels (one send/one receive) per SC= TP association? > > AFAIK we have not settled on that yet. > Two possibilities have been discussed: > > - one bidirectional channel (one outgoing and one incoming SCTP stream) > used for: sending clue requests and responses, receiving clue requests > and responses. > > - two bidirectional channels: > . one for sending clue requests and receiving clue responses > (provider role) > . one for receiving clue requests and sending clue responses > (consumer role) > > Using two leverages sctp stream multiplexing to handle the multiplexing o= f the provider role messages with the consumer role messages. So it can sim= plify the implementation of the clue protocol. > > OTOH this means that it would be harder to map the clue protocol onto a r= eliable transport that doesn't have multiple streams. > > My impression is that there has been a preference for using a single chan= nel, but I don't recall that we made a final decision on it. My suggestion is to use one bidirectional channel. I am not even sure how/if rtcweb supports multiple data channels. At least = the current drafts seem to assume that only one will be used - at least per= a single SCTP association :) >> Something like this: >> >> "3.2. CLUE Data Channel Definition >> >> The realization of a bidirectional CLUE Data Channel is a pair of on= e >> incoming SCTP stream and one outgoing SCTP stream. These streams ar= e >> then used to transport CLUE messages in both directions. >> >> The SCTP streams MUST belong to the same SCTP association. >> >> The SCTP streams SHOULD have identical SCTP stream identifier values= , >> unless a specific value is already used for some other purpose. > > If it is *possible* that the two stream ids might not be identical, then = we need a way to determine which ones are paired. Yes, and there is a discussion (initiated by yourself, with some extra fuel= added by me :) on the RTCWEB list regarding that, so let's see what the ou= tcome will be. (Of course, one could use the Data Channel Protocol, and then the receiver = will see on which stream the messages are received, and assume that the str= eam will be used for whatever protocol is indicated. ) Regards, Christer From christer.holmberg@ericsson.com Wed Feb 5 07:46:48 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C111A01D4 for ; Wed, 5 Feb 2014 07:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DakTtkJODeDJ for ; Wed, 5 Feb 2014 07:46:46 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9B11A0192 for ; Wed, 5 Feb 2014 07:46:45 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-c9-52f25ce41b2c Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id B8.DC.04853.4EC52F25; Wed, 5 Feb 2014 16:46:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 16:46:43 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? Thread-Index: Ac8htYEgN7eZRc+7Td6fweMbfzckWwAVm/YAAA4NnfAADfxtgAACSuqAAACbc5D///GcgP//7kgQ Date: Wed, 5 Feb 2014 15:46:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15C679@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D1586CE@ESESSMB209.ericsson.se> <52F1985A.8070006@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15B6B5@ESESSMB209.ericsson.se> <52F25485.2070909@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C54E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15C604@ESESSMB209.ericsson.se> <52F25BE9.9080907@alum.mit.edu> In-Reply-To: <52F25BE9.9080907@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje6TmE9BBqf2KFvsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldG0+63jAVrrSsOfepgbWB8r9/FyMkhIWAi ceXtTnYIW0ziwr31bF2MXBxCAicYJX5dnswK4SxilGjc0g6U4eBgE7CQ6P6nDdIgIuApsePj FGYQW1ggRqK77RgTRDxW4seEmewQdpRET9srRhCbRUBF4uDh92A2r4CvxPYL/ewQ8/8zScxb vAOsmVNAR6LhRjtYMyPQRd9PrQGLMwuIS9x6Mp8J4lIBiSV7zjND2KISLx//YwW5TUJAUWJ5 vxxEuY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEbRWUimzkLSMgtJyywkLQsYWVYxShanFhfn phsZ6OWm55bopRZlJhcX5+fpFaduYgTGy8Etv412MJ7cY3+IUZqDRUmc9zprTZCQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGxhb54uuHa8uUFuRlPl+Xpn5ltj/bMnMf6eyvn3nnSrV2uhp+ nXguc03mzTN1e9a+3HbjwMw9Be++Pteb0pHz0+HVz8sGNT4fU6avZf/NJGy57rfqYY4Vy6rv nfjMsm9nrET5V4ONqtFfsztkCtYlfmtKerq0fEObo1oVb7LjzL2vqkKu6Tvrv1diKc5INNRi LipOBAC6I/wHZQIAAA== Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 15:46:48 -0000 Hi, My understanding is that basic fragmentation is already supported by vanill= a SCTP. Interleaving seems to be useful when one is sending VERY large messages. I = guess the question is whether a CLUE message is a VERY large message :) Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 5. helmikuuta 2014 17:43 To: Christer Holmberg; clue@ietf.org Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones doe= s CLUE require? Unfortunately it seems that fragmentation is an issue we will not be able t= o ignore. Thanks, Paul On 2/5/14 10:36 AM, Christer Holmberg wrote: > Hi, > > I found the following text in section 3.1. draft-stewart-tsvwg-sctp-ndata= -03.txt: > > "A sender MUST NOT send a N-DATA chunk unless the peer has indicated > its support of the N-DATA chunk type within the Supported Extensions > Parameter as defined in [RFC5061]." > > So, it seems like there will be an in-band negotiation regarding usage of= interleaving. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer=20 > Holmberg > Sent: 5. helmikuuta 2014 17:19 > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones d= oes CLUE require? > > Hi, > >> Regarding fragmentation, my understanding is that there is an SCTP=20 >> extension that handles the fragmentation at the SCTP layer, but that it = is not yet ready for prime time. So for the webrtc data channel they have p= roposes to do application level fragmentation initially. >> >> One purpose of fragmentation is to solve head of line blocking problems. >> That won't be a problem for clue *if* the clue channel is the only use o= f the association. But we should not assume that. >> >> If we want to be compatible with rtcweb, then we need to be compatible w= ith their fragmentation rules too. > > If the fragmentation can't be controlled by the JavaScript application, t= hen I agree with you. > > If the fragmentation can be controlled by the JavaScript application, the= n we can simply say not to use it. > > Anyway, I have no problem to align with rtcweb, if we think it's=20 > feasible. Figuring such things out is part of the whole exercise :) > > Regards, > > Christer > > > On 2/5/14 2:40 AM, Christer Holmberg wrote: >> Hi Christian, >> >>> Part of the reason I suggested to use those sections of rtcweb-data-cha= nnel is so that we can make an educated decision about what we want to supp= ort for CLUE. >> >> I could add the text, and indicate that the CLUE usage is FFS. >> >>>> Christian earlier suggested that we could copy/paste section 6.1=20 >>>> from the rtcweb-data-channel draft into our draft. >>>> >>>> I think we need to consider whether we really need the features=20 >>>> listed in that chapter (unless, of course, the usage of them is=20 >>>> mandated in order to be compatible with rtcweb). >>>> >>> [CNG] I agree. However if we say functions are not supported CLUE=20 >>> and RTCWEB says that they must be supported. What does that mean? e.g. = We mandate the use of RTCweb data channel for CLUE. Therefore the rules of = RTCweb data channel apply. Stream reset extension MUST be supported. >>> However for CLUE we say it shouldn't be supported. The endpoint is not = an RTCWEB endpoint it only supports CLUE over SCTP. So does it need to impl= ement stream reset or not? >> >> Those are things we need to clarify with RTCWEB. >> >>>> The features are listed below, with some initial comments ([CHH]). >>>> >>>> o The stream reset extension defined in [RFC6525] MUST be supported. >>>> It is used for closing channels. >>>> >>>> [CHH] I may have misunderstood RFC6526, but I don't think this is=20 >>>> for CLOSING channels. It's for reseting the number sequence, which=20 >>>> I think is a different thing. >>>> >>>> In any case, I currently see no reason why we would need to mandate=20 >>>> support of this in CLUE. [/CHH] >>>> >>> [CNG] I think the "resetting" is part of closing a channel. The resetti= ng is done so that you can use the channel for another protocol. >>> I'd say this has more of a general applicability An endpoint may want t= o close a channel and reuse it for CLUE or vice-versa. >> >> Sure. And, if someone wants to use it - fine. But, from a CLUE perspecti= ve we only have one protocol, so we don't need to mandate it. >> >> >>>> o The dynamic address reconfiguration extension defined in=20 >>>> [RFC5061] >>>> >>>> MUST be used to signal the support of the stream reset extension=20 >>>> defined in [RFC6525], other features of [RFC5061] MUST NOT be used. >>>> >>>> [CHH] It seems like this is only used for the reset extension. The=20 >>>> other features are related to multi-homing, which is not supported=20 >>>> by SCTPoDTLS to begin with. [/CHH] >>>> >>> [CNG] I guess to be precise they only want the support of clause >>> 4.2.7/RFC5061 "Supported Extensions Parameter"? Again this appears to b= e a generic function for SCTP. >>> >>>> o The partial reliability extension defined in [RFC3758] MUST be=20 >>>> supported. In addition to the timed reliability PR-SCTP policy=20 >>>> defined in [RFC3758], the limited retransmission policy defined in=20 >>>> [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. >>>> >>>> [CHH] I see no reason for support of partial reliability -=20 >>>> eventhough I have to admit I am not sure what it really means. In=20 >>>> any case, my suggestion is that CLUE always use "full" reliability. >>>> [/CHH] >>>> >>> [CNG] For the current Advertise/Configure procedures I also would see n= o support of partial reliability. However is CLUE evolves to somehow signal= speaker changes in real time then this could come in handy. i.e. >>> Bullet 1 clause 1.3/RFC3758. Rather than retransmission what is more im= portant is that the most recent speaker message is processed. It would prev= ent a momentary audio/video switch. >>> >>> As for limited retransmissions I'm not sure what the applicability woul= d be to a CLUE channel? >> >> Also, don't think that you can't "switch" between reliable and non-relia= ble. >> >>>> Once support for message interleaving as currently being discussed=20 >>>> in >>>> >>>> [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported. >>>> >>>> [CHH] Assuming we can rely on application-level fragmentation, I=20 >>>> assume we would not need it. But, again, I am not familiar with the=20 >>>> details of message interleaving. [/CHH] >>>> >>> [CNG] We currently don't have CLUE level fragmentation. Were you thinki= ng of something else? >> >> That is what PPID value 51 is used for. It basically indicates "More inf= ormation is coming", so the receiver will have to buffer the received data.= I don't think we need to add any extra to the CLUE protocol itself for thi= s. >> >> My understanding is that this was used in the demo shown at the virtual = interim? >> >> Regards, >> >> Christer >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Wed Feb 5 08:15:44 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C661A01F6 for ; Wed, 5 Feb 2014 08:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyiHuf0FoeAf for ; Wed, 5 Feb 2014 08:15:42 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8901A0172 for ; Wed, 5 Feb 2014 08:15:42 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id NeFV1n0021HzFnQ53gFhp8; Wed, 05 Feb 2014 16:15:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id NgFh1n0013ZTu2S3agFhdF; Wed, 05 Feb 2014 16:15:41 +0000 Message-ID: <52F263AC.2010707@alum.mit.edu> Date: Wed, 05 Feb 2014 11:15:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1586CE@ESESSMB209.ericsson.se> <52F1985A.8070006@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15B6B5@ESESSMB209.ericsson.se> <52F25485.2070909@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C54E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15C604@ESESSMB209.ericsson.se> <52F25BE9.9080907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C679@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15C679@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=1391616941; bh=KhSB1T9gVQzZ8DoN7amXGP+/8/26UbaGMX1GyhorwWI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DxUTTdQBKTFDZWlgIzNJhhAAE7AzCmaC/yEb8OuZo+ma5y3eQ0a/nbOWPkVxRPDHY z0PgFRaA01ZODLlrP8lSWjQsPd7TqJUInIsG5pZGrjCPDlwX6wmybfUsmyQzLt83BA SL6RQmft2NcGicWv83crh0wxxJkpRLdougGEk24aY4oH+xEZKy4Kqbi7O+raYjkNtu ExhToCr3jzaEQOVXP2PGLJ3GAa/2+s+DqZqcJrPQNb8zXlDqfm1x0ka/HTHqFM2VIp mpanD89X/lzuo2PxCeg0Neweh5ZC87nw8NAKzyiR2GSotjyFnqzA9W1EyUtybVjDSr spzpolttP0xtA== Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 16:15:44 -0000 On 2/5/14 10:46 AM, Christer Holmberg wrote: > Hi, > > My understanding is that basic fragmentation is already supported by vanilla SCTP. I don't claim to be an expert. > Interleaving seems to be useful when one is sending VERY large messages. I guess the question is whether a CLUE message is a VERY large message :) It remains to be seen how big clue messages will be. My *guess* is that even big advertisements aren't likely to be big enough to present head of line blocking issues, except perhaps if somebody is sending sensitive real time data on another channel. But if rtcweb mandates fragmentation, and does it it browser code, but above SCTP, then we may need to be prepared to see it. So we can't ignore it. > Regards, > > Christer > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 5. helmikuuta 2014 17:43 > To: Christer Holmberg; clue@ietf.org > Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? > > Unfortunately it seems that fragmentation is an issue we will not be able to ignore. > > Thanks, > Paul > > > On 2/5/14 10:36 AM, Christer Holmberg wrote: >> Hi, >> >> I found the following text in section 3.1. draft-stewart-tsvwg-sctp-ndata-03.txt: >> >> "A sender MUST NOT send a N-DATA chunk unless the peer has indicated >> its support of the N-DATA chunk type within the Supported Extensions >> Parameter as defined in [RFC5061]." >> >> So, it seems like there will be an in-band negotiation regarding usage of interleaving. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer >> Holmberg >> Sent: 5. helmikuuta 2014 17:19 >> To: Paul Kyzivat; clue@ietf.org >> Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? >> >> Hi, >> >>> Regarding fragmentation, my understanding is that there is an SCTP >>> extension that handles the fragmentation at the SCTP layer, but that it is not yet ready for prime time. So for the webrtc data channel they have proposes to do application level fragmentation initially. >>> >>> One purpose of fragmentation is to solve head of line blocking problems. >>> That won't be a problem for clue *if* the clue channel is the only use of the association. But we should not assume that. >>> >>> If we want to be compatible with rtcweb, then we need to be compatible with their fragmentation rules too. >> >> If the fragmentation can't be controlled by the JavaScript application, then I agree with you. >> >> If the fragmentation can be controlled by the JavaScript application, then we can simply say not to use it. >> >> Anyway, I have no problem to align with rtcweb, if we think it's >> feasible. Figuring such things out is part of the whole exercise :) >> >> Regards, >> >> Christer >> >> >> On 2/5/14 2:40 AM, Christer Holmberg wrote: >>> Hi Christian, >>> >>>> Part of the reason I suggested to use those sections of rtcweb-data-channel is so that we can make an educated decision about what we want to support for CLUE. >>> >>> I could add the text, and indicate that the CLUE usage is FFS. >>> >>>>> Christian earlier suggested that we could copy/paste section 6.1 >>>>> from the rtcweb-data-channel draft into our draft. >>>>> >>>>> I think we need to consider whether we really need the features >>>>> listed in that chapter (unless, of course, the usage of them is >>>>> mandated in order to be compatible with rtcweb). >>>>> >>>> [CNG] I agree. However if we say functions are not supported CLUE >>>> and RTCWEB says that they must be supported. What does that mean? e.g. We mandate the use of RTCweb data channel for CLUE. Therefore the rules of RTCweb data channel apply. Stream reset extension MUST be supported. >>>> However for CLUE we say it shouldn't be supported. The endpoint is not an RTCWEB endpoint it only supports CLUE over SCTP. So does it need to implement stream reset or not? >>> >>> Those are things we need to clarify with RTCWEB. >>> >>>>> The features are listed below, with some initial comments ([CHH]). >>>>> >>>>> o The stream reset extension defined in [RFC6525] MUST be supported. >>>>> It is used for closing channels. >>>>> >>>>> [CHH] I may have misunderstood RFC6526, but I don't think this is >>>>> for CLOSING channels. It's for reseting the number sequence, which >>>>> I think is a different thing. >>>>> >>>>> In any case, I currently see no reason why we would need to mandate >>>>> support of this in CLUE. [/CHH] >>>>> >>>> [CNG] I think the "resetting" is part of closing a channel. The resetting is done so that you can use the channel for another protocol. >>>> I'd say this has more of a general applicability An endpoint may want to close a channel and reuse it for CLUE or vice-versa. >>> >>> Sure. And, if someone wants to use it - fine. But, from a CLUE perspective we only have one protocol, so we don't need to mandate it. >>> >>> >>>>> o The dynamic address reconfiguration extension defined in >>>>> [RFC5061] >>>>> >>>>> MUST be used to signal the support of the stream reset extension >>>>> defined in [RFC6525], other features of [RFC5061] MUST NOT be used. >>>>> >>>>> [CHH] It seems like this is only used for the reset extension. The >>>>> other features are related to multi-homing, which is not supported >>>>> by SCTPoDTLS to begin with. [/CHH] >>>>> >>>> [CNG] I guess to be precise they only want the support of clause >>>> 4.2.7/RFC5061 "Supported Extensions Parameter"? Again this appears to be a generic function for SCTP. >>>> >>>>> o The partial reliability extension defined in [RFC3758] MUST be >>>>> supported. In addition to the timed reliability PR-SCTP policy >>>>> defined in [RFC3758], the limited retransmission policy defined in >>>>> [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. >>>>> >>>>> [CHH] I see no reason for support of partial reliability - >>>>> eventhough I have to admit I am not sure what it really means. In >>>>> any case, my suggestion is that CLUE always use "full" reliability. >>>>> [/CHH] >>>>> >>>> [CNG] For the current Advertise/Configure procedures I also would see no support of partial reliability. However is CLUE evolves to somehow signal speaker changes in real time then this could come in handy. i.e. >>>> Bullet 1 clause 1.3/RFC3758. Rather than retransmission what is more important is that the most recent speaker message is processed. It would prevent a momentary audio/video switch. >>>> >>>> As for limited retransmissions I'm not sure what the applicability would be to a CLUE channel? >>> >>> Also, don't think that you can't "switch" between reliable and non-reliable. >>> >>>>> Once support for message interleaving as currently being discussed >>>>> in >>>>> >>>>> [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported. >>>>> >>>>> [CHH] Assuming we can rely on application-level fragmentation, I >>>>> assume we would not need it. But, again, I am not familiar with the >>>>> details of message interleaving. [/CHH] >>>>> >>>> [CNG] We currently don't have CLUE level fragmentation. Were you thinking of something else? >>> >>> That is what PPID value 51 is used for. It basically indicates "More information is coming", so the receiver will have to buffer the received data. I don't think we need to add any extra to the CLUE protocol itself for this. >>> >>> My understanding is that this was used in the demo shown at the virtual interim? >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > From pkyzivat@alum.mit.edu Wed Feb 5 09:22:23 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97311A00F7 for ; Wed, 5 Feb 2014 09:22:23 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, MANGLED_SIDE=2.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz9eK8t7dYdX for ; Wed, 5 Feb 2014 09:22:22 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1E21A014B for ; Wed, 5 Feb 2014 09:22:21 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta04.westchester.pa.mail.comcast.net with comcast id Ne4p1n0030ldTLk54hNMC4; Wed, 05 Feb 2014 17:22:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id NhNL1n00l3ZTu2S01hNMXh; Wed, 05 Feb 2014 17:22:21 +0000 Message-ID: <52F2734C.7050000@alum.mit.edu> Date: Wed, 05 Feb 2014 12:22:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15C665@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=1391620941; bh=SrNOcpnWM7UELVpgzKnles7Hd3s273Ho+O2n2aremJ8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Nbjwyt6C1GGZp+SF4gojc7s/KFSE0ANBePjIag5el+bAbR4vuLthxPF7oyCgHcjYN 65UjGR1M2fJOjAPrCgbNYNLd8UpNiEkM5AUK1BV/vd1z/befe3LwpcaW58bI3+EGKo yqX5JzqWVHgDck1JKPoYQFPNdkc+/oTGfAEgpQM6KmxbrD71rII8vSzQNpStsyUfK+ j+VZ3k3IQApfp7X1fha6tlYbOh9xbzGfYrlg4Io1nGv8lKhLizq3x7wPXCJswu932d pjs9baFfPamNhmzDL3PWi2pB57TTXdwBhqKv0EQE+8k7RKYJ5pnTs4J9fhqp6gAhxg lLBGvKjBN52tg== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 17:22:24 -0000 A lot inline On 2/5/14 10:45 AM, Christer Holmberg wrote: > Hi, > >>>>>> It wouldn't hurt to state that for CLUE messages. Section 6.4 could be altered slightly for CLUE. >>>>> I think section 6.4 is more or less what I currently have in section 3.2.1. But, maybe it should be added to a "Channel Definition" section. >>>> [CNG] Yes pretty much along the lines of section 3.2.1. Will an >>>> endpoint only ever have two CLUE channels (one send/one receive) per SCTP association? >> >> AFAIK we have not settled on that yet. >> Two possibilities have been discussed: >> >> - one bidirectional channel (one outgoing and one incoming SCTP stream) >> used for: sending clue requests and responses, receiving clue requests >> and responses. >> >> - two bidirectional channels: >> . one for sending clue requests and receiving clue responses >> (provider role) >> . one for receiving clue requests and sending clue responses >> (consumer role) >> >> Using two leverages sctp stream multiplexing to handle the multiplexing of the provider role messages with the consumer role messages. So it can simplify the implementation of the clue protocol. >> >> OTOH this means that it would be harder to map the clue protocol onto a reliable transport that doesn't have multiple streams. >> >> My impression is that there has been a preference for using a single channel, but I don't recall that we made a final decision on it. > > My suggestion is to use one bidirectional channel. > > I am not even sure how/if rtcweb supports multiple data channels. At least the current drafts seem to assume that only one will be used - at least per a single SCTP association :) Christer - how can you say that? Supporting multiple channels is a major part of the data channel work in rtcweb and webrtc. In rtcweb you get multiple channels by sending multiple OPEN messages. (I don't follow the api work much, but the api for creating a channel can be called multiple times.) I am quite certain that there is no doubt about this. >>> Something like this: >>> >>> "3.2. CLUE Data Channel Definition >>> >>> The realization of a bidirectional CLUE Data Channel is a pair of one >>> incoming SCTP stream and one outgoing SCTP stream. These streams are >>> then used to transport CLUE messages in both directions. >>> >>> The SCTP streams MUST belong to the same SCTP association. >>> >>> The SCTP streams SHOULD have identical SCTP stream identifier values, >>> unless a specific value is already used for some other purpose. >> >> If it is *possible* that the two stream ids might not be identical, then we need a way to determine which ones are paired. > > Yes, and there is a discussion (initiated by yourself, with some extra fuel added by me :) on the RTCWEB list regarding that, so let's see what the outcome will be. > > (Of course, one could use the Data Channel Protocol, and then the receiver will see on which stream the messages are received, and assume that the stream will be used for whatever protocol is indicated. ) If you use the data channel protocol, then one end chooses an unused stream id and sends the OPEN message. The other end will receive that, necessarily on the *same* stream id. (That is how SCTP works.) Then the receiver of the OPEN must send an ACK. It must choose some stream ID to send that ACK on. And it must choose it in such a way that the other end will know that the ACK correlates to the correct OPEN. The Webrtc Data Channel Protocol says that one side always uses *even* stream IDs to send OPENs, and the other side always uses *odd* stream IDs to send OPENs. That already *implies* that the intent is that the paired stream use the same ID, but doesn't really require it. Consider the following Alice Bob | OPEN(id=1) | |------------------->| | | | OPEN(id=4) | |<-------------------| | | | OPEN(id=3) | |------------------->| | | | ACK(id=3) | |<-------------------| | | | DATA(id=3) | |<-------------------| | | | DATA(id=3) | |------------------->| | | | ACK(id=4) | |------------------->| | | | DATA(id=4) | |<-------------------| | | | ACK(id=1) | |<-------------------| | | | OPEN(id=2) | |<-------------------| | | | ACK(id=2) | |------------------->| The above is assuming that stream ids in one direction are paired with stream ids in the other direction to make a channel. So from a channel perspective the above would look like: Alice Bob | OPEN(id=1) | |------------------->| | | | ACK(id=1) | |<-------------------| Alice Bob | | | OPEN(id=2) | |<-------------------| | | | ACK(id=2) | |------------------->| Alice Bob | | | OPEN(id=3) | |------------------->| | | | ACK(id=3) | |<-------------------| | | | DATA(id=3) | |<-------------------| | | | DATA(id=3) | |------------------->| Alice Bob | | | OPEN(id=4) | |<-------------------| | | | ACK(id=4) | |------------------->| | | | DATA(id=4) | |<-------------------| The even/odd rule ensures that the ids used by one side for open won't be used by the other side for open, and so will remain free to be used for ack. *in principle* if an OPEN is received on an even stream id the paired return stream id could be some *different* even number. But then the issue of how to match them remains a problem. There are a whole bunch of labels involved in the above. Alice: - IP address (IP-A) - UDP port number (UDP-A) - SCTP port number (SCTP-A) - SCTP outgoing stream id (SID-1, SID-3) - SCTP incoming stream id (SID-2, SID-4) Bob: - IP address (IP-B) - UDP port number (UDP-B) - SCTP port number (SCTP-B) - SCTP outgoing stream id (SID-2, SID-4) - SCTP incoming stream id (SID-1, SID-3) The pairing of IP address, UDP port, and SCTP port is defined by SDP O/A: Alice: m=application UDP-A DTLS/SCTP SCTP-A c=IN IP4 IP-A a=sctpmap:SCTP-A webrtc-datachannel 16 Bob: m=application UDP-B DTLS/SCTP SCTP-B c=IN IP4 IP-B a=sctpmap:SCTP-B webrtc-datachannel 16 But the matching outgoing and incoming SCTP stream ids is not defined by SDP (at least not without something like the Ejzak draft). I wonder, are you getting the stream id issues mixed up with port number issues? Thanks, Paul > Regards, > > Christer > From roni.even@mail01.huawei.com Wed Feb 5 10:33:03 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6310E1A0138 for ; Wed, 5 Feb 2014 10:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crq79PpKf_o7 for ; Wed, 5 Feb 2014 10:33:01 -0800 (PST) Received: from hwsga02-in.huaweimarine.com (unknown [58.251.153.224]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6AF1A0132 for ; Wed, 5 Feb 2014 10:32:59 -0800 (PST) Received: from 172.24.1.79 (EHLO szxpml203-edg.exmail.huawei.com) ([172.24.1.79]) by szxrg12-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVI76081; Thu, 06 Feb 2014 02:32:52 +0800 (CST) Received: from SZXPML401-HUB.exmail.huawei.com (10.82.67.140) by szxpml203-edg.exmail.huawei.com (172.24.2.14) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Feb 2014 02:31:59 +0800 Received: from SZXPML507-MBX.exmail.huawei.com ([169.254.2.88]) by szxpml401-hub.exmail.huawei.com ([10.82.67.140]) with mapi id 14.03.0158.001; Thu, 6 Feb 2014 02:32:44 +0800 From: Roni Even To: "clue@ietf.org" , Gonzalo Camarillo Thread-Topic: New Version Notification for draft-ietf-clue-telepresence-use-cases-09.txt Thread-Index: AQHPIkRbVdqQyJiCS0q2dGiAMt0CWZqm/DRb Date: Wed, 5 Feb 2014 18:32:43 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C23E54F5EA@szxpml507-mbx.exmail.huawei.com> References: <20140205073148.7016.87448.idtracker@ietfa.amsl.com> In-Reply-To: <20140205073148.7016.87448.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [clue] FW: New Version Notification for draft-ietf-clue-telepresence-use-cases-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 18:33:03 -0000 ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Wednesday, February 05, 2014 9:31 AM To: Stephen Botzko; Mark Duckworth; Dr. Allyn Romanow; Roni Even; Mark Duck= worth; Roni Even; stephen.botzko@gmail.com; Allyn Romanow Subject: New Version Notification for draft-ietf-clue-telepresence-use-case= s-09.txt A new version of I-D, draft-ietf-clue-telepresence-use-cases-09.txt has been successfully submitted by Roni Even and posted to the IETF repository. Name: draft-ietf-clue-telepresence-use-cases Revision: 09 Title: Use Cases for Telepresence Multi-streams Document date: 2014-02-05 Group: clue Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-ietf-clue-telepre= sence-use-cases-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresen= ce-use-cases/ Htmlized: http://tools.ietf.org/html/draft-ietf-clue-telepresence-use= -cases-09 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepres= ence-use-cases-09 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. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From pkyzivat@alum.mit.edu Wed Feb 5 11:41:53 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808801A00FA for ; Wed, 5 Feb 2014 11:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqNWKbFsc7o4 for ; Wed, 5 Feb 2014 11:41:50 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id A22C01A00E2 for ; Wed, 5 Feb 2014 11:41:49 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id NilD1n00A1HzFnQ59jhoEk; Wed, 05 Feb 2014 19:41:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id Njho1n00H3ZTu2S3ajhoC1; Wed, 05 Feb 2014 19:41:48 +0000 Message-ID: <52F293FC.5080502@alum.mit.edu> Date: Wed, 05 Feb 2014 14:41:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> <52CB8BB9.70503@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E3E6@CRPMBOXPRD07.polycom.com> <52CF5885.2090002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4FF@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF15FFC@CRPMBOXPRD07.polycom.com> <52DC8BC8.7000204@nteczone.com> <52DD6047.4030101@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16388@CRPMBOXPRD07.polycom.com> <52DDAAF7.9020506@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF1646F@CRPMBOXPRD07.polycom.com> <52DF051B.5040809@nteczone.com> <52E00EE7.3020205@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D01E6DF@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D0F8123@CRPMBOXPRD07.polycom.com> <52E837F9.2090201@nteczone.com> In-Reply-To: <52E837F9.2090201@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391629308; bh=7lrSVsRDy4J6V7d+vqvyZ4VEd0CnprbPuXX6FmJTtEg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lcegffNVEe+PG0ZiFlDhu8iMoLbJFRhxXpnH42DUPQ7Tjpl15FdKHpois7oyjeigo cpJmEKq5+XjvLh0HBVaKHayK4Ilx5XbAwos/2JbBqAlwRtiIlK1hweH69lLQF0ze9Q T+3z4oFXWwu4OXD4qXWtHKEP4HalcxDBYvvoxRUPa1htqPIGREWjZpeFo9HF+IIwgt wRAy1oukum3snr2axZwbXj8+tVd5/ua6WbH+vuiOFERHjWc9cIBe3mFYC4dowa7MI0 d3RfE3xEDb5QD7Brb0eNiOX0eI6zZNch1YkalSkW03POaRO2zd/AZvIwOH8uoPu2Rk T8ytJKVTo/zUA== Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't describe video locations within composed MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 19:41:53 -0000 On 1/28/14 6:06 PM, Christian Groves wrote: > Hello Mark, > > I was simply replying to Paul. I wasn't seeking to over turn any > decision on spatial parameters (not that I was aware of the outcome of > the meeting). > > An issue was brought up several times about the maxcaptures parameter > meaning any number of sources up to a value and that this caused > uncertainty to the consumer. This parameter is independent of any > spatial parameters thus my reply to Paul. I was suggesting a > modification by apply this parameter to say "=" in addition to "<=" to > this to solve that problem. If the Advertiser is only going to send a > MCC with a fixed number of captures then it seems to me that its > semantically incorrect t =o imply less may be sent. I'm still not entirely clear what this means. IIUC, the intent is that if the MCC has N sources, and maxcaptures (or number-of-captures) is M, then: - if N>1 and M=1 then this is a "switched" capture - if N>1 and M=N then this is a "composed" capture But - that doesn't say anything about 1 Regards, Christian > > On 29/01/2014 4:20 AM, Duckworth, Mark wrote: >> >> Mary and Paul, could you please let us know if consensus is reached on >> this topic? >> >> At the interim meeting Jan 27, we reaffirmed the decision noted in >> Ticket #5 , meaning the >> group does not want to attempt to use CLUE to describe composed >> captures, particularly the layout of individual video images within a >> composed image. >> >> I think Christian is still opposed to this outcome from the interim >> meeting. >> >> Regards, >> >> Mark >> >> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, Mark >> *Sent:* Wednesday, January 22, 2014 7:16 PM >> *To:* Paul Kyzivat; clue@ietf.org >> *Subject:* Re: [clue] spatial information can't describe video >> locations within composed MCC >> >> Hi Paul, >> >> Paul wrote: "Lets first discuss if having this information would >> provide significant value. If so then we can discuss how to provide it." >> >> Yes, but we already did that, and decided it isn’t valuable enough to >> work on as part of CLUE. This was Ticket #5 >> . I think we should stick >> with that decision. >> >> Mark >> >> > -----Original Message----- >> >> > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> >> > Sent: Wednesday, January 22, 2014 1:33 PM >> >> > To: clue@ietf.org >> >> > Subject: Re: [clue] spatial information can't describe video >> locations within >> >> > composed MCC >> >> > >> >> > On 1/21/14 6:39 PM, Christian Groves wrote: >> >> > > Hello Mark, >> >> > > >> >> > > I think I know where the disconnect is between us. Its to do with the >> >> > > encodings. In my examples I've been assumed that Provider only >> >> > > provides the encoding for MCC1 not the constituent captures. Whereas >> >> > > you've been assuming that encodings are being provided for the >> >> > > individual and MCC captures. >> >> > > >> >> > > In the case of the encoding only being on the MCC the consumer knows >> >> > > because the VCs and MCC belong to the same Capture Scene. The >> >> > > Advertiser has provided the spatial positions of VC1 being left. VC2 >> >> > > being centre and VC3 being right. That is their position in the >> composition. >> >> > >> >> > That at best seems like a hack. It is repurposing the spatial info >> of the >> >> > captures without encodings for an entirely different purpose. >> >> > >> >> > And it doesn't work right if you want to have multiple MCCs that >> compose >> >> > the same sources differently. (Unless you introduce another layer of >> >> > indirection, such as you do in example below. Yet another hack.) >> >> > >> >> > > In the case of multiple encodings the spatial information associated >> >> > > with an individual capture is likely to be a difference between the >> >> > > individual encodings and the MCC encoding. >> >> > > >> >> > > So perhaps the way to address this is to allow spatial information in >> >> > > individual encodings in MCCs only when those individual encodings are >> >> > MCCs? >> >> > > >> >> > > E.g. taking your example below. >> >> > > >> >> > > Scene 1 >> >> > > VC1 - left >> >> > > VC2 - center >> >> > > VC3 - right >> >> > > MCC2(VC1) - left-composed >> >> > > MCC3(VC2) - center-composed >> >> > > MCC4(VC3) - right-composed >> >> > > MCC1 (MCC2,MCC3,MCC4) - whole scene, maxCaptures=3 >> >> > > CSE1 (VC1, VC2, VC3) >> >> > > CSE2 (MCC1) >> >> > >> >> > In effect what you have now done is introduce an explicit encoding >> for the >> >> > positions of the sources of a composition. (But used an obscure and >> >> > confusing notation.) >> >> > >> >> > If we really want that, then I suggest we just add syntax to the >> declaration of >> >> > the MCC to explicitly do it. >> >> > >> >> > But I don't really see the point of doing so. What can the consumer >> do when >> >> > it has this info that it wouldn't be able to do without it? >> >> > >> >> > > In order to address the maxCaptures issue perhaps we need to modify >> >> > > "MaxCaptures" slightly so that it becomes "NumberofCaptures" where we >> >> > > could say NumberofCaptures=3 or NumberofCaptures<=3. This would give >> >> > > more certainty to the Consumer about what will actually be sent. >> >> > >> >> > That is just another step towards describing the complete layout of the >> >> > composition. >> >> > >> >> > Lets first discuss if having this information would provide >> significant value. If >> >> > so then we can discuss how to provide it. >> >> > >> >> > Thanks, >> >> > Paul >> >> > >> >> > > Regards, Christian >> >> > > >> >> > > >> >> > > On 21/01/2014 11:54 PM, Duckworth, Mark wrote: >> >> > >> Hello Christian, >> >> > >> >> >> > >> I still don't see how the consumer can tell anything about how an >> MCC >> >> > >> is composed. Take this example, >> >> > >> >> >> > >> Scene 1 >> >> > >> VC1 - left >> >> > >> VC2 - center >> >> > >> VC3 - right >> >> > >> MCC1 (VC1, VC2, VC3) - whole scene, maxCaptures=3 >> >> > >> CSE1 (VC1, VC2, VC3) >> >> > >> CSE2 (MCC1) >> >> > >> >> >> > >> Here it is useful to give spatial information for all the captures, >> >> > >> so the consumer that chooses the individual captures knows they are >> >> > >> spatially related. But how is the consumer supposed to know how the >> >> > >> provider is composing them inside MCC1? It could be any number of >> >> > >> ways, and it could be changing over time. So my cases 2 and 3 below >> >> > >> apply to why the consumer can't tell how the MCC is composed. Yet it >> >> > >> still makes sense for the provider to give spatial information for >> >> > >> the captures themselves. >> >> > >> >> >> > >> Mark >> >> > >> >> >> > >>> -----Original Message----- >> >> > >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >> >> > >>> Groves >> >> > >>> Sent: Monday, January 20, 2014 6:02 PM >> >> > >>> To: clue@ietf.org >> >> > >>> Subject: Re: [clue] spatial information can't describe video >> >> > >>> locations within composed MCC >> >> > >>> >> >> > >>> Hello Mark and Paul, >> >> > >>> >> >> > >>> Please see my responses below. >> >> > >>> >> >> > >>> Regards, Christian >> >> > >>> >> >> > >>> On 21/01/2014 8:29 AM, Duckworth, Mark wrote: >> >> > >>>> Christian, >> >> > >>>> >> >> > >>>> I agree with Paul. >> >> > >>>> >> >> > >>>> Christian wrote: "I cannot see why in the static case spatial >> >> > >>>> information isn't >> >> > >>> valid? In the static case the concerns of 2, 3 and 4 don't apply." >> >> > >>>> That might be true, but how is the consumer going to know if it is >> >> > >>>> the "static >> >> > >>> case" or not? I don't see any way for the consumer to know this. >> >> > >>> [CNG] The consumer knows this because the Provider only provides >> the >> >> > >>> spatial information when it makes sense to do so. >> >> > >>> >> >> > >>>> Mark >> >> > >>>> >> >> > >>>>> -----Original Message----- >> >> > >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >> >> > >>>>> Kyzivat >> >> > >>>>> Sent: Monday, January 20, 2014 12:44 PM >> >> > >>>>> To: clue@ietf.org >> >> > >>>>> Subject: Re: [clue] spatial information can't describe video >> >> > >>>>> locations within composed MCC >> >> > >>>>> >> >> > >>>>> On 1/19/14 9:36 PM, Christian Groves wrote: >> >> > >>>>>> Hello Mark, >> >> > >>>>>> >> >> > >>>>>> Sorry for the delayed response. I was on vacation last week. I >> >> > >>>>>> see there's been quite a lot of activity over the last week with >> >> > >>>>>> respect to MCCs and the framework. >> >> > >>>>>> >> >> > >>>>>> I saw the minutes of the meeting and saw there was a mention >> that >> >> > >>>>>> I should argue :-). >> >> > >>>>>> >> >> > >>>>>> I don't agree with the outcome of the meeting. I think its >> >> > >>>>>> important to note that MCC doesn't equal switching. A MCC may >> >> > >>>>>> represent a dynamic switching case OR a static case. A static >> >> > >>>>>> case may be that a MCU offers a single stream where three >> >> > >>>>>> captures from an endpoint on separate streams are composed into >> >> > one video stream. >> >> > >>>>> Yes, we had that in mind when discussing this. >> >> > >>>>> >> >> > >>>>>> I cannot see why in the >> >> > >>>>>> static case spatial information isn't valid? In the static case >> >> > >>>>>> the concerns of 2, 3 and 4 don't apply. >> >> > >>>>> We may not have understood you. We were guessing what you >> >> > meant. >> >> > >>>>> >> >> > >>>>> Suppose there is an MCC that has three input captures, and >> >> > >>>>> composes >> >> > >>> them. >> >> > >>>>> It could compose them in many ways. It could put the three >> side by >> >> > >>>>> side, or one big one and two as picture-in-picture overlays, >> or ... >> >> > >>>>> And even with three side by side, they could be in any order. >> >> > >>> [CNG] Yes >> >> > >>>>> And the source captures could all be from multiple scenes or one, >> >> > >>>>> and if one, it could be the same one as the MCC or not. The >> >> > >>>>> simplest case is that they are all from the same scene as the >> MCC. >> >> > >>>>> But even then, the coordinates of the source captures are >> >> > >>>>> presumably meaningful if they are individually configured. We >> >> > >>>>> could see no reason to presume that their arrangement in the >> scene >> >> > >>>>> has anything to do with their >> >> > >>> arrangement in the MCC. >> >> > >>> [CNG] Paul you mentioned the idea of a virtual scene before. What I >> >> > >>> see an MCU doing is creating a virtual scene using these source >> >> > >>> captures. >> >> > >>> Giving Captures spatial co-ordinates within a virtual scene is a >> >> > >>> valid thing to do irrespective of the use of a MCC. The MCU may >> >> > >>> apply any transformation it wants based on the source capture >> >> > >>> information. I think this equally applies to the MCC itself. >> >> > >>> Now if the MCU constructs a composed image from several sources >> >> > >>> using a MCC I can't see why it cannot indicate the spatial position >> >> > >>> of the sources in the MCC as they also reside in the virtual space. >> >> > >>>>> So we need more info to understand your perspective on this. >> >> > >>>>> >> >> > >>>>>> From the minutes I didn't see an explanation of other people's >> >> > >>> concerns. >> >> > >>>>>> So rather than a complete prohibition of the spatial information >> >> > >>>>>> regarding individual captures I think it would be better to >> >> > >>>>>> explain that the Advertiser has a choice to include the >> >> > >>>>>> information and that the spatial information is only meaningful >> >> > >>>>>> if the individual capture's spatial information is static. >> That's >> >> > >>>>>> what I tried to capture in the text below. >> >> > >>>>> I already commented on this earlier. >> >> > >>>>> IMO the advertiser MAY provide spatial information on an MCC. >> That >> >> > >>>>> would describe a place within the scene of the MCC. IMO that is a >> >> > >>>>> suggestion by the advertiser, but doesn't have the same physical >> >> > >>>>> significance as will a non-MCC capture. >> >> > >>> [CNG] I don't understand why the spatial information of the MCC has >> >> > >>> less significance than a non-MCC capture? An Advertiser constructs >> >> > >>> the scene, it give the spatial positioning. If the MCC and non-MCC >> >> > >>> captures are part of the same CSE then equal weight should be >> given. >> >> > >>> >> >> > >>>>> The consumer could just use this, treating the MCC like any other >> >> > >>>>> capture. Or, if it is smarter, and the MCC is *switched*, it >> could >> >> > >>>>> ignore this and look into the spatial info for the source >> captures. >> >> > >>> [CNG] If the MCC is "switched" AND the spatial information changes >> >> > >>> between source captures then this would be the dynamic case. I >> think >> >> > >>> the advice is that a Advertiser shouldn't provide this information >> >> > >>> unless it also provides a means for the Consumer to determine when >> >> > >>> the switch takes place. If the MCC is "switched" and the source >> >> > >>> spatial information is the same then the Advertiser can simply >> >> > >>> supply the spatial information at the MCC level without the need to >> >> > >>> set it on the sources. >> >> > >>>>> But none of that has anything to do with the the arrangement of >> >> > >>>>> composed captures within an MCC. >> >> > >>> [CNG] I don't understand the point. You only focused on the >> switched >> >> > >>> case. >> >> > >>> MCC is for switching and composition. >> >> > >>>>> Thanks, >> >> > >>>>> Paul >> >> > >>>>> >> >> > >>>>>> Regards, Christian >> >> > >>>>>> >> >> > >>>>>> On 18/01/2014 9:50 AM, Duckworth, Mark wrote: >> >> > >>>>>>> We discussed this topic in the design team meeting Jan 14 >> >> > >>>>>>> >> > >> > >>>>> Team/minutes_140114.txt>. >> >> > >>>>>>> From the minutes: >> >> > >>>>>>> >> >> > >>>>>>> "Conclusion 1: Spatial information of the individual captures >> >> > >>>>>>> does not apply inside a composed MCC." >> >> > >>>>>>> >> >> > >>>>>>> We wanted to bring this topic back to the list to make sure we >> >> > >>>>>>> have consensus before clarifying the framework about this. >> >> > >>>>>>> Christian, or anybody else, do you still want more discussion? >> >> > >>>>>>> >> >> > >>>>>>> Regards, >> >> > >>>>>>> Mark >> >> > >>>>>>> >> >> > >>>>>>>> -----Original Message----- >> >> > >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >> >> > >>>>>>>> Duckworth, Mark >> >> > >>>>>>>> Sent: Friday, January 10, 2014 4:04 PM >> >> > >>>>>>>> To: Christian Groves; clue@ietf.org >> >> > >>>>>>>> Subject: Re: [clue] spatial information can't describe video >> >> > >>>>>>> locations within >> >> > >>>>>>> >> >> > >>>>>>>> composed MCC >> >> > >>>>>>>> Thanks Christian, that is an improvement. But I'm still not >> >> > >>>>>>> convinced the >> >> > >>>>>>> >> >> > >>>>>>>> consumer can always tell when the spatial attributes are >> >> > >>>>>>>> meaningful >> >> > >>>>>>> (even >> >> > >>>>>>> >> >> > >>>>>>>> within a scene) for discerning how contributors to a composed >> >> > >>>>>>>> MCC are arranged within the MCC. My concerns 2, 3, and 4 below >> >> > >>>>>>>> still apply. >> >> > >>>>>>>> Does anybody else have input to this topic? >> >> > >>>>>>>> Mark >> >> > >>>>>>>>> -----Original Message----- >> >> > >>>>>>>>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> >> > >>>>>>>>> Sent: Thursday, January 09, 2014 9:19 PM >> >> > >>>>>>>>> To: Duckworth, Mark; clue@ietf.org >> >> > >>>>>>>>> Subject: Re: [clue] spatial information can't describe video >> >> > >>>>>>> locations >> >> > >>>>>>> >> >> > >>>>>>>>> within composed MCC >> >> > >>>>>>>>> Hello Mark, >> >> > >>>>>>>>> How about something like the following? >> >> > >>>>>>>>> 7.2.1. MCC Attributes >> >> > >>>>>>>>> Attributes may be associated with the MCC instance and the >> >> > >>>>>>>>> Single Media Captures that the MCC references. A provider >> >> > >>>>>>>>> should avoid providing conflicting attribute values between >> >> > >>>>>>>>> the MCC and Single Media Captures. Where there is conflict >> the >> >> > >>>>>>>>> attributes of the MCC override any that may be present in the >> >> > individual captures. >> >> > >>>>>>>>> <> >> > >>>>>>>>> within a MCC and/or to the MCC itself the Provider should be >> >> > >>>>>>>>> aware that spatial attributes have no relation across Capture >> >> > Scenes. >> >> > >>>>>>>>> Therefore >> >> > >>>>>>>>> if the Provider intends to provide a spatial relation between >> >> > >>>>>>>>> the source Captures and the MCC then these MUST be part of >> >> > the >> >> > >>>>>>>>> same >> >> > >>>>>>>> Capture Scene. >> >> > >>>>>>>>> When assigning spatial information that would cause the >> >> > >>>>>>>>> spatial positioning of the source Capture to move within the >> >> > >>>>>>>>> MCC, the >> >> > >>>>>>> Provider >> >> > >>>>>>> >> >> > >>>>>>>>> should also be aware that a Consumer may not be able to >> >> > >>>>>>>>> determine >> >> > >>>>>>> that >> >> > >>>>>>> >> >> > >>>>>>>>> the source captures have moved.>> ... >> >> > >>>>>>>>> Regards, Christian >> >> > >>>>>>>>> On 8/01/2014 12:18 AM, Duckworth, Mark wrote: >> >> > >>>>>>>>>> Hello Christian, >> >> > >>>>>>>>>> So there are only certain circumstances in which spatial >> >> > >>>>>>> information >> >> > >>>>>>> >> >> > >>>>>>>>>> for >> >> > >>>>>>>>> components of a composed capture is relevant. For the case >> >> > >>>>>>>>> where you think it is important and relevant, can you please >> >> > >>>>>>>>> propose text for the framework to describe this? I think the >> >> > >>>>>>>>> framework should be more clear about when and how the >> >> > consumer >> >> > >>>>>>>>> can use >> >> > >>> this >> >> > >>>>>>>>> information for composed captures. >> >> > >>>>>>>>>> Mark >> >> > >>>>>>>>>>> -----Original Message----- >> >> > >>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >> >> > >>>>>>>>>>> Christian Groves >> >> > >>>>>>>>>>> Sent: Tuesday, January 07, 2014 12:08 AM >> >> > >>>>>>>>>>> To: clue@ietf.org >> >> > >>>>>>>>>>> Subject: Re: [clue] spatial information can't describe >> video >> >> > >>>>>>>>>>> locations within composed MCC Hello Mark, I agree with >> >> > >>>>>>>>>>> respect to the fact that spatial information isn't valid >> >> > >>>>>>>>>>> across Capture Scenes. i.e. If I have an MCC in one >> >> > >>>>>>> Cap.Scene >> >> > >>>>>>> >> >> > >>>>>>>>>>> referencing individual captures from other scenes. >> However I >> >> > >>>>>>>>>>> think there is a valid case where an MCC can reference >> >> > >>>>>>>>>>> Individual captures from the same scene as it. In this case >> >> > >>>>>>>>>>> I think the >> >> > >>>>>>> use of >> >> > >>>>>>> >> >> > >>>>>>>>>>> spatial >> >> > >>>>>>>>> information is valid, i.e. >> >> > >>>>>>>>>>> +-----------------------+---------------------------------+ >> >> > >>>>>>>>>>> | Capture Scene #1 | | >> >> > >>>>>>>>>>> +-----------------------|---------------------------------+ >> >> > >>>>>>>>>>> | VC1 | CapArea=Left | >> >> > >>>>>>>>>>> | VC2 | CapArea=Right | >> >> > >>>>>>>>>>> | MCC1(VC1, VC2) | | >> >> > >>>>>>>>>>> +---------------------------------------------------------+ >> >> > >>>>>>>>>>> or >> >> > >>>>>>>>>>> +-----------------------+---------------------------------+ >> >> > >>>>>>>>>>> | Capture Scene #1 | | >> >> > >>>>>>>>>>> +-----------------------|---------------------------------+ >> >> > >>>>>>>>>>> | MCC1(VC1) | CapArea=Left | >> >> > >>>>>>>>>>> | MCC2(VC2) | CapArea=Right | >> >> > >>>>>>>>>>> | MCC1(MCC1,MCC2) | | >> >> > >>>>>>>>>>> +---------------------------------------------------------+ >> >> > >>>>>>>>>>> where VC1 and VC2 are from different Capture Scenes. >> >> > >>>>>>>>>>> There are of course cases where the spatial information >> >> > >>>>>>> wouldn't be >> >> > >>>>>>> >> >> > >>>>>>>>>>> valid but in those cases the Provider wouldn't provide >> them, >> >> > >>>>>>>>>>> i.e. >> >> > >>>>>>>>>>> where the individual captures move. However there will be >> >> > >>>>>>>>>>> cases where the composition is static and the information >> >> > >>>>>>>>>>> would be >> >> > >>>>>>> valid. >> >> > >>>>>>> >> >> > >>>>>>>>>>> I don't think we can make a general assumption that the >> >> > >>>>>>>>>>> spatial information is >> >> > >>>>>>>>> valid or invalid in all cases. >> >> > >>>>>>>>>>> Regards, Christian >> >> > >>>>>>>>>>> On 7/01/2014 7:54 AM, Duckworth, Mark wrote: >> >> > >>>>>>>>>>>> Framework version 13 says a provider can use spatial >> >> > >>>>>>>>>>>> information of source media captures to describe how those >> >> > >>>>>>>>>>>> sources are placed within a composed multiple content >> >> > >>>>>>>>>>>> capture (MCC). In general I think this won't work, and I'm >> >> > >>>>>>>>>>>> not even sure under what specific conditions it might >> work. >> >> > >>>>>>>>>>>> So I propose removing that part, and instead add text to >> >> > >>>>>>>>>>>> say the spatial information of individual captures does >> not >> >> > >>>>>>>>>>>> relate to its relative position within a >> >> > >>>>>>> composed >> >> > >>>>>>> >> >> > >>>>>>>> MCC. >> >> > >>>>>>>>>>>> From section 7.2.1: >> >> > >>>>>>>>>>>> For example: The spatial related attributes can be further >> >> > >>>>>>> used to >> >> > >>>>>>> >> >> > >>>>>>>>>>>> determine how the individual captures "appear" within a >> >> > >>>>>>>>>>>> stream. A virtual scene could be constructed for the MCC >> >> > >>>>>>>>>>>> capture with two Video Captures with a "MaxCaptures" >> >> > >>>>>>>>>>>> attribute set to 2 and an "Area of Capture" attribute >> >> > >>>>>>>>>>>> provided with an overall area. >> >> > >>>>>>> Each of >> >> > >>>>>>> >> >> > >>>>>>>>>>>> the individual Captures could then also include an >> "Area of >> >> > >>>>>>> Capture" >> >> > >>>>>>> >> >> > >>>>>>>>>>>> attribute with a sub-set of the overall area. The Consumer >> >> > >>>>>>>>>>>> would then know the relative position of the content in >> the >> >> > >>>>>>>>>>>> composed >> >> > >>>>>>>> stream. >> >> > >>>>>>>>>>>> Here are some reasons why I think this will generally not >> >> > work: >> >> > >>>>>>>>>>>> 1.The spatial information for captures is relevant only in >> >> > >>>>>>>>>>>> relation to the capture scene to which the captures >> belong. >> >> > >>>>>>>>>>>> Spatial information from different scenes has no relation >> >> > >>>>>>>>>>>> to each other. So if the individual captures that are part >> >> > >>>>>>>>>>>> of a composed MCC come from different scenes (source >> >> > >>>>>>>>>>>> captures >> >> > >>> from >> >> > >>>>>>>>>>>> multiple scenes, or source captures from different scenes >> >> > >>>>>>>>>>>> than the >> >> > >>>>>>>>>>>> MCC) >> >> > >>>>>>>>>>>> then the spatial information of one capture has no >> relation >> >> > >>>>>>>>>>>> to >> >> > >>>>>>> the >> >> > >>>>>>> >> >> > >>>>>>>>>>>> spatial information of another capture. >> >> > >>>>>>>>>>>> 2.In the example with MaxCaptures = 2, that doesn't mean >> >> > >>>>>>>>>>>> there will always be 2 contributing captures in the >> MCC. It >> >> > >>>>>>>>>>>> just means maximum of 2, but sometimes there could be 1. >> >> > >>>>>>>>>>>> The contents of the MCC could actually be changing over >> >> > >>>>>>>>>>>> time between 1 and 2 >> >> > >>>>>>>> contributing captures. >> >> > >>>>>>>>>>>> If it changes between one full screen source image to two >> >> > >>>>>>>>>>>> source images side by side, then the spatial information >> >> > >>>>>>>>>>>> wouldn't always indicate the location of the source within >> >> > >>>>>>>>>>>> the MCC. We have no >> >> > >>>>>>> way >> >> > >>>>>>> >> >> > >>>>>>>>>>>> for the provider to advertise this level of detail, and I >> >> > >>>>>>>>>>>> don't think we want to get into this detail in provider >> >> > >>>>>>>>>>>> advertisements. >> >> > >>>>>>>>>>>> 3.Similarly, the MCC could always contain both individual >> >> > >>>>>>>>>>>> captures, but maybe it is a large image of the one that is >> >> > >>>>>>> talking >> >> > >>>>>>> >> >> > >>>>>>>>>>>> and a small image of the other. This would change over >> >> > >>>>>>>>>>>> time, so again the spatial information wouldn't always >> >> > >>>>>>>>>>>> indicate the location of the source within the MCC. >> >> > >>>>>>>>>>>> 4.Take a slightly different example, where the MCC >> contains >> >> > >>>>>>>>>>>> 4 contributing individual captures, but still with >> >> > >>>>>>>>>>>> MaxCaptures = 2. >> >> > >>>>>>>>>>>> So the resulting MCC again will change over time, as the >> >> > >>>>>>>>>>>> provider is free to choose which 2 out of the 4 to include >> >> > >>>>>>>>>>>> at any time. So again the spatial information wouldn't >> >> > >>>>>>>>>>>> always indicate the location of the source within the MCC. >> >> > >>>>>>>>>>>> Regards, >> >> > >>>>>>>>>>>> Mark >> >> > >>>>>>>>>>>> >> >> > _______________________________________________ >> >> > >>>>>>>>>>>> clue mailing list >> >> > >>>>>>>>>>>> clue@ietf.org >> >> >> > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >> >> > >>>>>>>>>>> _______________________________________________ >> >> > >>>>>>>>>>> clue mailing list >> >> > >>>>>>>>>>> clue@ietf.org >> >> > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >> >> > >>>>>>>> _______________________________________________ >> >> > >>>>>>>> clue mailing list >> >> > >>>>>>>> clue@ietf.org >> >> > >>>>>>>> https://www.ietf.org/mailman/listinfo/clue >> >> > >>>>>>> >> >> > >>>>>>> _______________________________________________ >> >> > >>>>>>> clue mailing list >> >> > >>>>>>> clue@ietf.org >> >> > >>>>>>> https://www.ietf.org/mailman/listinfo/clue >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> clue mailing list >> >> > >>>>>> clue@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/clue >> >> > >>>>>> >> >> > >>>>> _______________________________________________ >> >> > >>>>> clue mailing list >> >> > >>>>> clue@ietf.org >> >> > >>>>> https://www.ietf.org/mailman/listinfo/clue >> >> > >>>> _______________________________________________ >> >> > >>>> clue mailing list >> >> > >>>> clue@ietf.org >> >> > >>>> https://www.ietf.org/mailman/listinfo/clue >> >> > >>>> >> >> > >>> _______________________________________________ >> >> > >>> clue mailing list >> >> > >>> clue@ietf.org >> >> > >>> https://www.ietf.org/mailman/listinfo/clue >> >> > > >> >> > > _______________________________________________ >> >> > > clue mailing list >> >> > > clue@ietf.org >> >> > > https://www.ietf.org/mailman/listinfo/clue >> >> > > >> >> > >> >> > _______________________________________________ >> >> > clue mailing list >> >> > clue@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/clue >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Wed Feb 5 14:21:34 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550061A022B for ; Wed, 5 Feb 2014 14:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBvv8DuHdgb0 for ; Wed, 5 Feb 2014 14:21:29 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 08F081A012F for ; Wed, 5 Feb 2014 14:21:28 -0800 (PST) Received: from PWEHUB01.polycom.com (10.236.2.221) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 5 Feb 2014 14:21:27 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Wed, 5 Feb 2014 14:21:27 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 5 Feb 2014 14:21:24 -0800 Thread-Topic: [clue] Now Maxcaptures - Re: spatial information can't describe video locations within composed MCC Thread-Index: Ac8iqlfHwsAzhqyHQW26xBIXpo6whwAFdAjA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FAF30@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> <52CB8BB9.70503@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E3E6@CRPMBOXPRD07.polycom.com> <52CF5885.2090002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4FF@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF15FFC@CRPMBOXPRD07.polycom.com> <52DC8BC8.7000204@nteczone.com> <52DD6047.4030101@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16388@CRPMBOXPRD07.polycom.com> <52DDAAF7.9020506@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF1646F@CRPMBOXPRD07.polycom.com> <52DF051B.5040809@nteczone.com> <52E00EE7.3020205@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D01E6DF@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D0F8123@CRPMBOXPRD07.polycom.com> <52E837F9.2090201@nteczone.com> <52F293FC.5080502@alum.mit.edu> In-Reply-To: <52F293FC.5080502@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] Now Maxcaptures - Re: spatial information can't describe video locations within composed MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 22:21:34 -0000 I too am confused about Christian's suggestion for changing or clarifying t= he maxcaptures attribute. Christian, can you explain again please? For now, I think I agree with Paul that there is no reason to change the cu= rrent description of maxcaptures. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, February 05, 2014 2:42 PM > To: clue@ietf.org > Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't descr= ibe > video locations within composed MCC > > On 1/28/14 6:06 PM, Christian Groves wrote: > > Hello Mark, > > > > I was simply replying to Paul. I wasn't seeking to over turn any > > decision on spatial parameters (not that I was aware of the outcome of > > the meeting). > > > > An issue was brought up several times about the maxcaptures parameter > > meaning any number of sources up to a value and that this caused > > uncertainty to the consumer. This parameter is independent of any > > spatial parameters thus my reply to Paul. I was suggesting a > > modification by apply this parameter to say "=3D" in addition to "<=3D"= to > > this to solve that problem. If the Advertiser is only going to send a > > MCC with a fixed number of captures then it seems to me that its > > semantically incorrect t =3Do imply less may be sent. > > I'm still not entirely clear what this means. > > IIUC, the intent is that if the MCC has N sources, and maxcaptures (or > number-of-captures) is M, then: > - if N>1 and M=3D1 then this is a "switched" capture > - if N>1 and M=3DN then this is a "composed" capture > > But - that doesn't say anything about 1 cases where there are combinations of switching and composition. And of > course it also doesn't deal with composition where some images are smalle= r > than others, and overlapping that hides parts of some captures. > It also doesn't deal with what will happen if the Configure selects a sub= set of > the sources in the MCC. > > I see no way to deal with that with a single number. And I don't see any > compelling reason to do so. > > The "switched" and "composed" attributes cover the two extremes, and also > indicate (when both or neither are specified) that the situation is somet= hing > other than one of the extremes. Does having a number improve on that? > > Thanks, > Paul > > > Regards, Christian > > > > On 29/01/2014 4:20 AM, Duckworth, Mark wrote: > >> > >> Mary and Paul, could you please let us know if consensus is reached > >> on this topic? > >> > >> At the interim meeting Jan 27, we reaffirmed the decision noted in > >> Ticket #5 , meaning the > >> group does not want to attempt to use CLUE to describe composed > >> captures, particularly the layout of individual video images within a > >> composed image. > >> > >> I think Christian is still opposed to this outcome from the interim > >> meeting. > >> > >> Regards, > >> > >> Mark > >> > >> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, > >> Mark > >> *Sent:* Wednesday, January 22, 2014 7:16 PM > >> *To:* Paul Kyzivat; clue@ietf.org > >> *Subject:* Re: [clue] spatial information can't describe video > >> locations within composed MCC > >> > >> Hi Paul, > >> > >> Paul wrote: "Lets first discuss if having this information would > >> provide significant value. If so then we can discuss how to provide it= ." > >> > >> Yes, but we already did that, and decided it isn't valuable enough to > >> work on as part of CLUE. This was Ticket #5 > >> . I think we should > >> stick with that decision. > >> > >> Mark > >> > >> > -----Original Message----- > >> > >> > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> > >> > Sent: Wednesday, January 22, 2014 1:33 PM > >> > >> > To: clue@ietf.org > >> > >> > Subject: Re: [clue] spatial information can't describe video > >> locations within > >> > >> > composed MCC > >> > >> > > >> > >> > On 1/21/14 6:39 PM, Christian Groves wrote: > >> > >> > > Hello Mark, > >> > >> > > > >> > >> > > I think I know where the disconnect is between us. Its to do with > >> > > the > >> > >> > > encodings. In my examples I've been assumed that Provider only > >> > >> > > provides the encoding for MCC1 not the constituent captures. > >> > > Whereas > >> > >> > > you've been assuming that encodings are being provided for the > >> > >> > > individual and MCC captures. > >> > >> > > > >> > >> > > In the case of the encoding only being on the MCC the consumer > >> > > knows > >> > >> > > because the VCs and MCC belong to the same Capture Scene. The > >> > >> > > Advertiser has provided the spatial positions of VC1 being left. > >> > > VC2 > >> > >> > > being centre and VC3 being right. That is their position in the > >> composition. > >> > >> > > >> > >> > That at best seems like a hack. It is repurposing the spatial info > >> of the > >> > >> > captures without encodings for an entirely different purpose. > >> > >> > > >> > >> > And it doesn't work right if you want to have multiple MCCs that > >> compose > >> > >> > the same sources differently. (Unless you introduce another layer > >> > of > >> > >> > indirection, such as you do in example below. Yet another hack.) > >> > >> > > >> > >> > > In the case of multiple encodings the spatial information > >> > > associated > >> > >> > > with an individual capture is likely to be a difference between > >> > > the > >> > >> > > individual encodings and the MCC encoding. > >> > >> > > > >> > >> > > So perhaps the way to address this is to allow spatial > >> > > information in > >> > >> > > individual encodings in MCCs only when those individual encodings > >> > > are > >> > >> > MCCs? > >> > >> > > > >> > >> > > E.g. taking your example below. > >> > >> > > > >> > >> > > Scene 1 > >> > >> > > VC1 - left > >> > >> > > VC2 - center > >> > >> > > VC3 - right > >> > >> > > MCC2(VC1) - left-composed > >> > >> > > MCC3(VC2) - center-composed > >> > >> > > MCC4(VC3) - right-composed > >> > >> > > MCC1 (MCC2,MCC3,MCC4) - whole scene, maxCaptures=3D3 > >> > >> > > CSE1 (VC1, VC2, VC3) > >> > >> > > CSE2 (MCC1) > >> > >> > > >> > >> > In effect what you have now done is introduce an explicit encoding > >> for the > >> > >> > positions of the sources of a composition. (But used an obscure and > >> > >> > confusing notation.) > >> > >> > > >> > >> > If we really want that, then I suggest we just add syntax to the > >> declaration of > >> > >> > the MCC to explicitly do it. > >> > >> > > >> > >> > But I don't really see the point of doing so. What can the consumer > >> do when > >> > >> > it has this info that it wouldn't be able to do without it? > >> > >> > > >> > >> > > In order to address the maxCaptures issue perhaps we need to > >> > > modify > >> > >> > > "MaxCaptures" slightly so that it becomes "NumberofCaptures" > >> > > where we > >> > >> > > could say NumberofCaptures=3D3 or NumberofCaptures<=3D3. This woul= d > >> > > give > >> > >> > > more certainty to the Consumer about what will actually be sent. > >> > >> > > >> > >> > That is just another step towards describing the complete layout of > >> > the > >> > >> > composition. > >> > >> > > >> > >> > Lets first discuss if having this information would provide > >> significant value. If > >> > >> > so then we can discuss how to provide it. > >> > >> > > >> > >> > Thanks, > >> > >> > Paul > >> > >> > > >> > >> > > Regards, Christian > >> > >> > > > >> > >> > > > >> > >> > > On 21/01/2014 11:54 PM, Duckworth, Mark wrote: > >> > >> > >> Hello Christian, > >> > >> > >> > >> > >> > >> I still don't see how the consumer can tell anything about how > >> > >> an > >> MCC > >> > >> > >> is composed. Take this example, > >> > >> > >> > >> > >> > >> Scene 1 > >> > >> > >> VC1 - left > >> > >> > >> VC2 - center > >> > >> > >> VC3 - right > >> > >> > >> MCC1 (VC1, VC2, VC3) - whole scene, maxCaptures=3D3 > >> > >> > >> CSE1 (VC1, VC2, VC3) > >> > >> > >> CSE2 (MCC1) > >> > >> > >> > >> > >> > >> Here it is useful to give spatial information for all the > >> > >> captures, > >> > >> > >> so the consumer that chooses the individual captures knows they > >> > >> are > >> > >> > >> spatially related. But how is the consumer supposed to know how > >> > >> the > >> > >> > >> provider is composing them inside MCC1? It could be any number > >> > >> of > >> > >> > >> ways, and it could be changing over time. So my cases 2 and 3 > >> > >> below > >> > >> > >> apply to why the consumer can't tell how the MCC is composed. > >> > >> Yet it > >> > >> > >> still makes sense for the provider to give spatial information > >> > >> for > >> > >> > >> the captures themselves. > >> > >> > >> > >> > >> > >> Mark > >> > >> > >> > >> > >> > >>> -----Original Message----- > >> > >> > >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > >> > >>> Christian > >> > >> > >>> Groves > >> > >> > >>> Sent: Monday, January 20, 2014 6:02 PM > >> > >> > >>> To: clue@ietf.org > >> > >> > >>> Subject: Re: [clue] spatial information can't describe video > >> > >> > >>> locations within composed MCC > >> > >> > >>> > >> > >> > >>> Hello Mark and Paul, > >> > >> > >>> > >> > >> > >>> Please see my responses below. > >> > >> > >>> > >> > >> > >>> Regards, Christian > >> > >> > >>> > >> > >> > >>> On 21/01/2014 8:29 AM, Duckworth, Mark wrote: > >> > >> > >>>> Christian, > >> > >> > >>>> > >> > >> > >>>> I agree with Paul. > >> > >> > >>>> > >> > >> > >>>> Christian wrote: "I cannot see why in the static case spatial > >> > >> > >>>> information isn't > >> > >> > >>> valid? In the static case the concerns of 2, 3 and 4 don't apply= ." > >> > >> > >>>> That might be true, but how is the consumer going to know if > >> > >>>> it is > >> > >> > >>>> the "static > >> > >> > >>> case" or not? I don't see any way for the consumer to know this. > >> > >> > >>> [CNG] The consumer knows this because the Provider only > >> > >>> provides > >> the > >> > >> > >>> spatial information when it makes sense to do so. > >> > >> > >>> > >> > >> > >>>> Mark > >> > >> > >>>> > >> > >> > >>>>> -----Original Message----- > >> > >> > >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul > >> > >> > >>>>> Kyzivat > >> > >> > >>>>> Sent: Monday, January 20, 2014 12:44 PM > >> > >> > >>>>> To: clue@ietf.org > >> > >> > >>>>> Subject: Re: [clue] spatial information can't describe video > >> > >> > >>>>> locations within composed MCC > >> > >> > >>>>> > >> > >> > >>>>> On 1/19/14 9:36 PM, Christian Groves wrote: > >> > >> > >>>>>> Hello Mark, > >> > >> > >>>>>> > >> > >> > >>>>>> Sorry for the delayed response. I was on vacation last week. > >> > >>>>>> I > >> > >> > >>>>>> see there's been quite a lot of activity over the last week > >> > >>>>>> with > >> > >> > >>>>>> respect to MCCs and the framework. > >> > >> > >>>>>> > >> > >> > >>>>>> I saw the minutes of the meeting and saw there was a mention > >> that > >> > >> > >>>>>> I should argue :-). > >> > >> > >>>>>> > >> > >> > >>>>>> I don't agree with the outcome of the meeting. I think its > >> > >> > >>>>>> important to note that MCC doesn't equal switching. A MCC > >> > >>>>>> may > >> > >> > >>>>>> represent a dynamic switching case OR a static case. A > >> > >>>>>> static > >> > >> > >>>>>> case may be that a MCU offers a single stream where three > >> > >> > >>>>>> captures from an endpoint on separate streams are composed > >> > >>>>>> into > >> > >> > one video stream. > >> > >> > >>>>> Yes, we had that in mind when discussing this. > >> > >> > >>>>> > >> > >> > >>>>>> I cannot see why in the > >> > >> > >>>>>> static case spatial information isn't valid? In the static > >> > >>>>>> case > >> > >> > >>>>>> the concerns of 2, 3 and 4 don't apply. > >> > >> > >>>>> We may not have understood you. We were guessing what you > >> > >> > meant. > >> > >> > >>>>> > >> > >> > >>>>> Suppose there is an MCC that has three input captures, and > >> > >> > >>>>> composes > >> > >> > >>> them. > >> > >> > >>>>> It could compose them in many ways. It could put the three > >> side by > >> > >> > >>>>> side, or one big one and two as picture-in-picture overlays, > >> or ... > >> > >> > >>>>> And even with three side by side, they could be in any order. > >> > >> > >>> [CNG] Yes > >> > >> > >>>>> And the source captures could all be from multiple scenes or > >> > >>>>> one, > >> > >> > >>>>> and if one, it could be the same one as the MCC or not. The > >> > >> > >>>>> simplest case is that they are all from the same scene as the > >> MCC. > >> > >> > >>>>> But even then, the coordinates of the source captures are > >> > >> > >>>>> presumably meaningful if they are individually configured. We > >> > >> > >>>>> could see no reason to presume that their arrangement in the > >> scene > >> > >> > >>>>> has anything to do with their > >> > >> > >>> arrangement in the MCC. > >> > >> > >>> [CNG] Paul you mentioned the idea of a virtual scene before. > >> > >>> What I > >> > >> > >>> see an MCU doing is creating a virtual scene using these source > >> > >> > >>> captures. > >> > >> > >>> Giving Captures spatial co-ordinates within a virtual scene is > >> > >>> a > >> > >> > >>> valid thing to do irrespective of the use of a MCC. The MCU may > >> > >> > >>> apply any transformation it wants based on the source capture > >> > >> > >>> information. I think this equally applies to the MCC itself. > >> > >> > >>> Now if the MCU constructs a composed image from several sources > >> > >> > >>> using a MCC I can't see why it cannot indicate the spatial > >> > >>> position > >> > >> > >>> of the sources in the MCC as they also reside in the virtual spa= ce. > >> > >> > >>>>> So we need more info to understand your perspective on this. > >> > >> > >>>>> > >> > >> > >>>>>> From the minutes I didn't see an explanation of other > >> > >>>>>> people's > >> > >> > >>> concerns. > >> > >> > >>>>>> So rather than a complete prohibition of the spatial > >> > >>>>>> information > >> > >> > >>>>>> regarding individual captures I think it would be better to > >> > >> > >>>>>> explain that the Advertiser has a choice to include the > >> > >> > >>>>>> information and that the spatial information is only > >> > >>>>>> meaningful > >> > >> > >>>>>> if the individual capture's spatial information is static. > >> That's > >> > >> > >>>>>> what I tried to capture in the text below. > >> > >> > >>>>> I already commented on this earlier. > >> > >> > >>>>> IMO the advertiser MAY provide spatial information on an MCC. > >> That > >> > >> > >>>>> would describe a place within the scene of the MCC. IMO that > >> > >>>>> is a > >> > >> > >>>>> suggestion by the advertiser, but doesn't have the same > >> > >>>>> physical > >> > >> > >>>>> significance as will a non-MCC capture. > >> > >> > >>> [CNG] I don't understand why the spatial information of the MCC > >> > >>> has > >> > >> > >>> less significance than a non-MCC capture? An Advertiser > >> > >>> constructs > >> > >> > >>> the scene, it give the spatial positioning. If the MCC and > >> > >>> non-MCC > >> > >> > >>> captures are part of the same CSE then equal weight should be > >> given. > >> > >> > >>> > >> > >> > >>>>> The consumer could just use this, treating the MCC like any > >> > >>>>> other > >> > >> > >>>>> capture. Or, if it is smarter, and the MCC is *switched*, it > >> could > >> > >> > >>>>> ignore this and look into the spatial info for the source > >> captures. > >> > >> > >>> [CNG] If the MCC is "switched" AND the spatial information > >> > >>> changes > >> > >> > >>> between source captures then this would be the dynamic case. I > >> think > >> > >> > >>> the advice is that a Advertiser shouldn't provide this > >> > >>> information > >> > >> > >>> unless it also provides a means for the Consumer to determine > >> > >>> when > >> > >> > >>> the switch takes place. If the MCC is "switched" and the source > >> > >> > >>> spatial information is the same then the Advertiser can simply > >> > >> > >>> supply the spatial information at the MCC level without the > >> > >>> need to > >> > >> > >>> set it on the sources. > >> > >> > >>>>> But none of that has anything to do with the the arrangement > >> > >>>>> of > >> > >> > >>>>> composed captures within an MCC. > >> > >> > >>> [CNG] I don't understand the point. You only focused on the > >> switched > >> > >> > >>> case. > >> > >> > >>> MCC is for switching and composition. > >> > >> > >>>>> Thanks, > >> > >> > >>>>> Paul > >> > >> > >>>>> > >> > >> > >>>>>> Regards, Christian > >> > >> > >>>>>> > >> > >> > >>>>>> On 18/01/2014 9:50 AM, Duckworth, Mark wrote: > >> > >> > >>>>>>> We discussed this topic in the design team meeting Jan 14 > >> > >> > >>>>>>> > >> >> > >> > >>>>> Team/minutes_140114.txt>. > >> > >> > >>>>>>> From the minutes: > >> > >> > >>>>>>> > >> > >> > >>>>>>> "Conclusion 1: Spatial information of the individual > >> > >>>>>>> captures > >> > >> > >>>>>>> does not apply inside a composed MCC." > >> > >> > >>>>>>> > >> > >> > >>>>>>> We wanted to bring this topic back to the list to make sure > >> > >>>>>>> we > >> > >> > >>>>>>> have consensus before clarifying the framework about this. > >> > >> > >>>>>>> Christian, or anybody else, do you still want more discussio= n? > >> > >> > >>>>>>> > >> > >> > >>>>>>> Regards, > >> > >> > >>>>>>> Mark > >> > >> > >>>>>>> > >> > >> > >>>>>>>> -----Original Message----- > >> > >> > >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > >> > >> > >>>>>>>> Duckworth, Mark > >> > >> > >>>>>>>> Sent: Friday, January 10, 2014 4:04 PM > >> > >> > >>>>>>>> To: Christian Groves; clue@ietf.org > >> > >> > >>>>>>>> Subject: Re: [clue] spatial information can't describe > >> > >>>>>>>> video > >> > >> > >>>>>>> locations within > >> > >> > >>>>>>> > >> > >> > >>>>>>>> composed MCC > >> > >> > >>>>>>>> Thanks Christian, that is an improvement. But I'm still > >> > >>>>>>>> not > >> > >> > >>>>>>> convinced the > >> > >> > >>>>>>> > >> > >> > >>>>>>>> consumer can always tell when the spatial attributes are > >> > >> > >>>>>>>> meaningful > >> > >> > >>>>>>> (even > >> > >> > >>>>>>> > >> > >> > >>>>>>>> within a scene) for discerning how contributors to a > >> > >>>>>>>> composed > >> > >> > >>>>>>>> MCC are arranged within the MCC. My concerns 2, 3, and 4 > >> > >>>>>>>> below > >> > >> > >>>>>>>> still apply. > >> > >> > >>>>>>>> Does anybody else have input to this topic? > >> > >> > >>>>>>>> Mark > >> > >> > >>>>>>>>> -----Original Message----- > >> > >> > >>>>>>>>> From: Christian Groves > >> > >>>>>>>>> [mailto:Christian.Groves@nteczone.com] > >> > >> > >>>>>>>>> Sent: Thursday, January 09, 2014 9:19 PM > >> > >> > >>>>>>>>> To: Duckworth, Mark; clue@ietf.org > >> > >> > >>>>>>>>> Subject: Re: [clue] spatial information can't describe > >> > >>>>>>>>> video > >> > >> > >>>>>>> locations > >> > >> > >>>>>>> > >> > >> > >>>>>>>>> within composed MCC > >> > >> > >>>>>>>>> Hello Mark, > >> > >> > >>>>>>>>> How about something like the following? > >> > >> > >>>>>>>>> 7.2.1. MCC Attributes > >> > >> > >>>>>>>>> Attributes may be associated with the MCC instance and > >> > >>>>>>>>> the > >> > >> > >>>>>>>>> Single Media Captures that the MCC references. A provider > >> > >> > >>>>>>>>> should avoid providing conflicting attribute values > >> > >>>>>>>>> between > >> > >> > >>>>>>>>> the MCC and Single Media Captures. Where there is > >> > >>>>>>>>> conflict > >> the > >> > >> > >>>>>>>>> attributes of the MCC override any that may be present in > >> > >>>>>>>>> the > >> > >> > individual captures. > >> > >> > >>>>>>>>> < >> > >>>>>>>>> captures > >> > >> > >>>>>>>>> within a MCC and/or to the MCC itself the Provider should > >> > >>>>>>>>> be > >> > >> > >>>>>>>>> aware that spatial attributes have no relation across > >> > >>>>>>>>> Capture > >> > >> > Scenes. > >> > >> > >>>>>>>>> Therefore > >> > >> > >>>>>>>>> if the Provider intends to provide a spatial relation > >> > >>>>>>>>> between > >> > >> > >>>>>>>>> the source Captures and the MCC then these MUST be part > >> > >>>>>>>>> of > >> > >> > the > >> > >> > >>>>>>>>> same > >> > >> > >>>>>>>> Capture Scene. > >> > >> > >>>>>>>>> When assigning spatial information that would cause the > >> > >> > >>>>>>>>> spatial positioning of the source Capture to move within > >> > >>>>>>>>> the > >> > >> > >>>>>>>>> MCC, the > >> > >> > >>>>>>> Provider > >> > >> > >>>>>>> > >> > >> > >>>>>>>>> should also be aware that a Consumer may not be able to > >> > >> > >>>>>>>>> determine > >> > >> > >>>>>>> that > >> > >> > >>>>>>> > >> > >> > >>>>>>>>> the source captures have moved.>> ... > >> > >> > >>>>>>>>> Regards, Christian > >> > >> > >>>>>>>>> On 8/01/2014 12:18 AM, Duckworth, Mark wrote: > >> > >> > >>>>>>>>>> Hello Christian, > >> > >> > >>>>>>>>>> So there are only certain circumstances in which spatial > >> > >> > >>>>>>> information > >> > >> > >>>>>>> > >> > >> > >>>>>>>>>> for > >> > >> > >>>>>>>>> components of a composed capture is relevant. For the > >> > >>>>>>>>> case > >> > >> > >>>>>>>>> where you think it is important and relevant, can you > >> > >>>>>>>>> please > >> > >> > >>>>>>>>> propose text for the framework to describe this? I think > >> > >>>>>>>>> the > >> > >> > >>>>>>>>> framework should be more clear about when and how the > >> > >> > consumer > >> > >> > >>>>>>>>> can use > >> > >> > >>> this > >> > >> > >>>>>>>>> information for composed captures. > >> > >> > >>>>>>>>>> Mark > >> > >> > >>>>>>>>>>> -----Original Message----- > >> > >> > >>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > >> > >> > >>>>>>>>>>> Christian Groves > >> > >> > >>>>>>>>>>> Sent: Tuesday, January 07, 2014 12:08 AM > >> > >> > >>>>>>>>>>> To: clue@ietf.org > >> > >> > >>>>>>>>>>> Subject: Re: [clue] spatial information can't describe > >> video > >> > >> > >>>>>>>>>>> locations within composed MCC Hello Mark, I agree with > >> > >> > >>>>>>>>>>> respect to the fact that spatial information isn't > >> > >>>>>>>>>>> valid > >> > >> > >>>>>>>>>>> across Capture Scenes. i.e. If I have an MCC in one > >> > >> > >>>>>>> Cap.Scene > >> > >> > >>>>>>> > >> > >> > >>>>>>>>>>> referencing individual captures from other scenes. > >> However I > >> > >> > >>>>>>>>>>> think there is a valid case where an MCC can reference > >> > >> > >>>>>>>>>>> Individual captures from the same scene as it. In this > >> > >>>>>>>>>>> case > >> > >> > >>>>>>>>>>> I think the > >> > >> > >>>>>>> use of > >> > >> > >>>>>>> > >> > >> > >>>>>>>>>>> spatial > >> > >> > >>>>>>>>> information is valid, i.e. > >> > >> > >>>>>>>>>>> +-----------------------+-------------------------------= --+ > >> > >> > >>>>>>>>>>> | Capture Scene #1 | | > >> > >> > >>>>>>>>>>> +-----------------------|-------------------------------= --+ > >> > >> > >>>>>>>>>>> | VC1 | CapArea=3DLeft | > >> > >> > >>>>>>>>>>> | VC2 | CapArea=3DRight | > >> > >> > >>>>>>>>>>> | MCC1(VC1, VC2) | | > >> > >> > >>>>>>>>>>> +-------------------------------------------------------= --+ > >> > >> > >>>>>>>>>>> or > >> > >> > >>>>>>>>>>> +-----------------------+-------------------------------= --+ > >> > >> > >>>>>>>>>>> | Capture Scene #1 | | > >> > >> > >>>>>>>>>>> +-----------------------|-------------------------------= --+ > >> > >> > >>>>>>>>>>> | MCC1(VC1) | CapArea=3DLeft | > >> > >> > >>>>>>>>>>> | MCC2(VC2) | CapArea=3DRight | > >> > >> > >>>>>>>>>>> | MCC1(MCC1,MCC2) | | > >> > >> > >>>>>>>>>>> +-------------------------------------------------------= --+ > >> > >> > >>>>>>>>>>> where VC1 and VC2 are from different Capture Scenes. > >> > >> > >>>>>>>>>>> There are of course cases where the spatial information > >> > >> > >>>>>>> wouldn't be > >> > >> > >>>>>>> > >> > >> > >>>>>>>>>>> valid but in those cases the Provider wouldn't provide > >> them, > >> > >> > >>>>>>>>>>> i.e. > >> > >> > >>>>>>>>>>> where the individual captures move. However there will > >> > >>>>>>>>>>> be > >> > >> > >>>>>>>>>>> cases where the composition is static and the > >> > >>>>>>>>>>> information > >> > >> > >>>>>>>>>>> would be > >> > >> > >>>>>>> valid. > >> > >> > >>>>>>> > >> > >> > >>>>>>>>>>> I don't think we can make a general assumption that the > >> > >> > >>>>>>>>>>> spatial information is > >> > >> > >>>>>>>>> valid or invalid in all cases. > >> > >> > >>>>>>>>>>> Regards, Christian > >> > >> > >>>>>>>>>>> On 7/01/2014 7:54 AM, Duckworth, Mark wrote: > >> > >> > >>>>>>>>>>>> Framework version 13 says a provider can use spatial > >> > >> > >>>>>>>>>>>> information of source media captures to describe how > >> > >>>>>>>>>>>> those > >> > >> > >>>>>>>>>>>> sources are placed within a composed multiple content > >> > >> > >>>>>>>>>>>> capture (MCC). In general I think this won't work, and > >> > >>>>>>>>>>>> I'm > >> > >> > >>>>>>>>>>>> not even sure under what specific conditions it might > >> work. > >> > >> > >>>>>>>>>>>> So I propose removing that part, and instead add text > >> > >>>>>>>>>>>> to > >> > >> > >>>>>>>>>>>> say the spatial information of individual captures > >> > >>>>>>>>>>>> does > >> not > >> > >> > >>>>>>>>>>>> relate to its relative position within a > >> > >> > >>>>>>> composed > >> > >> > >>>>>>> > >> > >> > >>>>>>>> MCC. > >> > >> > >>>>>>>>>>>> From section 7.2.1: > >> > >> > >>>>>>>>>>>> For example: The spatial related attributes can be > >> > >>>>>>>>>>>> further > >> > >> > >>>>>>> used to > >> > >> > >>>>>>> > >> > >> > >>>>>>>>>>>> determine how the individual captures "appear" within > >> > >>>>>>>>>>>> a > >> > >> > >>>>>>>>>>>> stream. A virtual scene could be constructed for the > >> > >>>>>>>>>>>> MCC > >> > >> > >>>>>>>>>>>> capture with two Video Captures with a "MaxCaptures" > >> > >> > >>>>>>>>>>>> attribute set to 2 and an "Area of Capture" attribute > >> > >> > >>>>>>>>>>>> provided with an overall area. > >> > >> > >>>>>>> Each of > >> > >> > >>>>>>> > >> > >> > >>>>>>>>>>>> the individual Captures could then also include an > >> "Area of > >> > >> > >>>>>>> Capture" > >> > >> > >>>>>>> > >> > >> > >>>>>>>>>>>> attribute with a sub-set of the overall area. The > >> > >>>>>>>>>>>> Consumer > >> > >> > >>>>>>>>>>>> would then know the relative position of the content > >> > >>>>>>>>>>>> in > >> the > >> > >> > >>>>>>>>>>>> composed > >> > >> > >>>>>>>> stream. > >> > >> > >>>>>>>>>>>> Here are some reasons why I think this will generally > >> > >>>>>>>>>>>> not > >> > >> > work: > >> > >> > >>>>>>>>>>>> 1.The spatial information for captures is relevant > >> > >>>>>>>>>>>> only in > >> > >> > >>>>>>>>>>>> relation to the capture scene to which the captures > >> belong. > >> > >> > >>>>>>>>>>>> Spatial information from different scenes has no > >> > >>>>>>>>>>>> relation > >> > >> > >>>>>>>>>>>> to each other. So if the individual captures that are > >> > >>>>>>>>>>>> part > >> > >> > >>>>>>>>>>>> of a composed MCC come from different scenes > (source > >> > >> > >>>>>>>>>>>> captures > >> > >> > >>> from > >> > >> > >>>>>>>>>>>> multiple scenes, or source captures from different > >> > >>>>>>>>>>>> scenes > >> > >> > >>>>>>>>>>>> than the > >> > >> > >>>>>>>>>>>> MCC) > >> > >> > >>>>>>>>>>>> then the spatial information of one capture has no > >> relation > >> > >> > >>>>>>>>>>>> to > >> > >> > >>>>>>> the > >> > >> > >>>>>>> > >> > >> > >>>>>>>>>>>> spatial information of another capture. > >> > >> > >>>>>>>>>>>> 2.In the example with MaxCaptures =3D 2, that doesn't > >> > >>>>>>>>>>>> mean > >> > >> > >>>>>>>>>>>> there will always be 2 contributing captures in the > >> MCC. It > >> > >> > >>>>>>>>>>>> just means maximum of 2, but sometimes there could > be 1. > >> > >> > >>>>>>>>>>>> The contents of the MCC could actually be changing > >> > >>>>>>>>>>>> over > >> > >> > >>>>>>>>>>>> time between 1 and 2 > >> > >> > >>>>>>>> contributing captures. > >> > >> > >>>>>>>>>>>> If it changes between one full screen source image to > >> > >>>>>>>>>>>> two > >> > >> > >>>>>>>>>>>> source images side by side, then the spatial > >> > >>>>>>>>>>>> information > >> > >> > >>>>>>>>>>>> wouldn't always indicate the location of the source > >> > >>>>>>>>>>>> within > >> > >> > >>>>>>>>>>>> the MCC. We have no > >> > >> > >>>>>>> way > >> > >> > >>>>>>> > >> > >> > >>>>>>>>>>>> for the provider to advertise this level of detail, > >> > >>>>>>>>>>>> and I > >> > >> > >>>>>>>>>>>> don't think we want to get into this detail in > >> > >>>>>>>>>>>> provider > >> > >> > >>>>>>>>>>>> advertisements. > >> > >> > >>>>>>>>>>>> 3.Similarly, the MCC could always contain both > >> > >>>>>>>>>>>> individual > >> > >> > >>>>>>>>>>>> captures, but maybe it is a large image of the one > >> > >>>>>>>>>>>> that is > >> > >> > >>>>>>> talking > >> > >> > >>>>>>> > >> > >> > >>>>>>>>>>>> and a small image of the other. This would change over > >> > >> > >>>>>>>>>>>> time, so again the spatial information wouldn't always > >> > >> > >>>>>>>>>>>> indicate the location of the source within the MCC. > >> > >> > >>>>>>>>>>>> 4.Take a slightly different example, where the MCC > >> contains > >> > >> > >>>>>>>>>>>> 4 contributing individual captures, but still with > >> > >> > >>>>>>>>>>>> MaxCaptures =3D 2. > >> > >> > >>>>>>>>>>>> So the resulting MCC again will change over time, as > >> > >>>>>>>>>>>> the > >> > >> > >>>>>>>>>>>> provider is free to choose which 2 out of the 4 to > >> > >>>>>>>>>>>> include > >> > >> > >>>>>>>>>>>> at any time. So again the spatial information wouldn't > >> > >> > >>>>>>>>>>>> always indicate the location of the source within the > MCC. > >> > >> > >>>>>>>>>>>> Regards, > >> > >> > >>>>>>>>>>>> Mark > >> > >> > >>>>>>>>>>>> > >> > >> > _______________________________________________ > >> > >> > >>>>>>>>>>>> clue mailing list > >> > >> > >>>>>>>>>>>> clue@ietf.org > >> > >> > >> > >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue > >> > >> > >>>>>>>>>>> > _______________________________________________ > >> > >> > >>>>>>>>>>> clue mailing list > >> > >> > >>>>>>>>>>> clue@ietf.org > >> > >>>>>>>>>>> > >> > >> > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue > >> > >> > >>>>>>>> > _______________________________________________ > >> > >> > >>>>>>>> clue mailing list > >> > >> > >>>>>>>> clue@ietf.org > >> > >>>>>>>> > >> > >> > >>>>>>>> https://www.ietf.org/mailman/listinfo/clue > >> > >> > >>>>>>> > >> > >> > >>>>>>> _______________________________________________ > >> > >> > >>>>>>> clue mailing list > >> > >> > >>>>>>> clue@ietf.org > >> > >> > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >> > >> > >>>>>> _______________________________________________ > >> > >> > >>>>>> clue mailing list > >> > >> > >>>>>> clue@ietf.org > >> > >> > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >> > >> > >>>>>> > >> > >> > >>>>> _______________________________________________ > >> > >> > >>>>> clue mailing list > >> > >> > >>>>> clue@ietf.org > >> > >> > >>>>> https://www.ietf.org/mailman/listinfo/clue > >> > >> > >>>> _______________________________________________ > >> > >> > >>>> clue mailing list > >> > >> > >>>> clue@ietf.org > >> > >> > >>>> https://www.ietf.org/mailman/listinfo/clue > >> > >> > >>>> > >> > >> > >>> _______________________________________________ > >> > >> > >>> clue mailing list > >> > >> > >>> clue@ietf.org > >> > >> > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> > > > >> > >> > > _______________________________________________ > >> > >> > > 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 Christian.Groves@nteczone.com Wed Feb 5 15:10:29 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690581A029E for ; Wed, 5 Feb 2014 15:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0D9xsFu8ePl for ; Wed, 5 Feb 2014 15:10:28 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49281A015A for ; Wed, 5 Feb 2014 15:10:27 -0800 (PST) Received: from ppp118-209-130-44.lns20.mel6.internode.on.net ([118.209.130.44]:51636 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBBbm-0007H2-Ul for clue@ietf.org; Thu, 06 Feb 2014 10:10:19 +1100 Message-ID: <52F2C4CF.3080906@nteczone.com> Date: Thu, 06 Feb 2014 10:10:07 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15BCF1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15BCF1@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Correct PPID values X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 23:10:29 -0000 Hello Christer, Will these be valid in light of the discussions segmentation and reassembly on the RTCweb list? If we were to rely on SCTP NDATA would we then only need one PID? Regards, Christian On 5/02/2014 10:14 PM, Christer Holmberg wrote: > > Hi, > > I noticed that, in the CLUE data channel draft, and in the associated > e-mail discussions, I have been talking about usage of PPID values 50 > and 51 when transporting CLUE protocol messages. > > The *correct* values are *51* (DOMString Last )and *54* (DOMString > Partial). > > 50 is used for the rtcweb data channel protocol. > > Sorry for the confusion. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Feb 5 15:17:54 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B7B1A021F for ; Wed, 5 Feb 2014 15:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22xfhTBJ2VsI for ; Wed, 5 Feb 2014 15:17:53 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 7417C1A021A for ; Wed, 5 Feb 2014 15:17:53 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta12.westchester.pa.mail.comcast.net with comcast id NdDq1n0041wpRvQ5CnHsYe; Wed, 05 Feb 2014 23:17:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id NnHs1n00M3ZTu2S3enHsw7; Wed, 05 Feb 2014 23:17:52 +0000 Message-ID: <52F2C6A0.7060104@alum.mit.edu> Date: Wed, 05 Feb 2014 18:17:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15BCF1@ESESSMB209.ericsson.se> <52F2C4CF.3080906@nteczone.com> In-Reply-To: <52F2C4CF.3080906@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=1391642272; bh=LVw88nvDv+8Txc8TbAnCic90UR6uh2NjHtdJv0P/A5E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TtcYC9Wid5QSohxPII6Y5XgygFlY8vcoUO17bBIZYkR6g3T/rrPnqeCQIx2YuNcEM VqT/8G1Jpk7Z/LeTv21aAbcJiQx0leGwpIjCO0tCn25Tu6oNKTIP5MZBxJXm8wNV0r G230qScHYXluPOYDxznRqoQCR4eyI0X3ZEd030aku/OnIok63kuWbozsXoiX/hJ2xs PcQXatEVmEprWb+0WrrZ34Kfw9WepqwEpnAMizMvc7vHhzt/3A5vUlATSs+HMxunxU IYHVxFpD8PUUxB0PUWFJLPbBPttSeKRVaQmp/rUwth+u4yALNDCDZb6Kt0Hi0zQH7G jC/t8lIv+uAGA== Subject: Re: [clue] Correct PPID values X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 23:17:55 -0000 On 2/5/14 6:10 PM, Christian Groves wrote: > Hello Christer, > > Will these be valid in light of the discussions segmentation and > reassembly on the RTCweb list? If we were to rely on SCTP NDATA would we > then only need one PID? One one for *data*. There are still separate ones for OPEN and ACK. Thanks, Paul > Regards, Christian > > On 5/02/2014 10:14 PM, Christer Holmberg wrote: >> >> Hi, >> >> I noticed that, in the CLUE data channel draft, and in the associated >> e-mail discussions, I have been talking about usage of PPID values 50 >> and 51 when transporting CLUE protocol messages. >> >> The *correct* values are *51* (DOMString Last )and *54* (DOMString >> Partial). >> >> 50 is used for the rtcweb data channel protocol. >> >> Sorry for the confusion. >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Feb 5 15:21:10 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6FB1A02C8 for ; Wed, 5 Feb 2014 15:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpVk8BvqXBCf for ; Wed, 5 Feb 2014 15:21:08 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3B41A02C5 for ; Wed, 5 Feb 2014 15:21:08 -0800 (PST) Received: from ppp118-209-130-44.lns20.mel6.internode.on.net ([118.209.130.44]:51799 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBBm9-00009V-7S; Thu, 06 Feb 2014 10:21:01 +1100 Message-ID: <52F2C75F.4090009@nteczone.com> Date: Thu, 06 Feb 2014 10:21:03 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D1586CE@ESESSMB209.ericsson.se> <52F1985A.8070006@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15B6B5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15B6B5@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 23:21:11 -0000 Hello Christer, On 5/02/2014 6:40 PM, Christer Holmberg wrote: > Hi Christian, > >> Part of the reason I suggested to use those sections of rtcweb-data-channel is so that we can make an educated decision about what we want to support for CLUE. > I could add the text, and indicate that the CLUE usage is FFS. > >>> Christian earlier suggested that we could copy/paste section 6.1 from >>> the rtcweb-data-channel draft into our draft. >>> >>> I think we need to consider whether we really need the features listed >>> in that chapter (unless, of course, the usage of them is mandated in >>> order to be compatible with rtcweb). >>> >> [CNG] I agree. However if we say functions are not supported CLUE and RTCWEB says that they must be supported. What does >> that mean? e.g. We mandate the use of RTCweb data channel for CLUE. Therefore the rules of RTCweb data channel apply. Stream reset extension MUST be supported. >> However for CLUE we say it shouldn't be supported. The endpoint is not an RTCWEB endpoint it only supports CLUE over SCTP. So does it need to implement stream reset or not? > Those are things we need to clarify with RTCWEB. > >>> The features are listed below, with some initial comments ([CHH]). >>> >>> o The stream reset extension defined in [RFC6525] MUST be supported. >>> It is used for closing channels. >>> >>> [CHH] I may have misunderstood RFC6526, but I don't think this is for >>> CLOSING channels. It's for reseting the number sequence, which I think >>> is a different thing. >>> >>> In any case, I currently see no reason why we would need to mandate >>> support of this in CLUE. [/CHH] >>> >> [CNG] I think the "resetting" is part of closing a channel. The resetting is done so that you can use the channel for another protocol. >> I'd say this has more of a general applicability An endpoint may want to close a channel and reuse it for CLUE or vice-versa. > Sure. And, if someone wants to use it - fine. But, from a CLUE perspective we only have one protocol, so we don't need to mandate it. [CNG] CLUE may be initiated in a channel previously occupied by another application. 'Resetting' a closed CLUE channel may also be seen as a "clean/complete" closure of the CLUE channel. > > >>> o The dynamic address reconfiguration extension defined in [RFC5061] >>> >>> MUST be used to signal the support of the stream reset extension >>> defined in [RFC6525], other features of [RFC5061] MUST NOT be >>> used. >>> >>> [CHH] It seems like this is only used for the reset extension. The >>> other features are related to multi-homing, which is not supported by >>> SCTPoDTLS to begin with. [/CHH] >>> >> [CNG] I guess to be precise they only want the support of clause >> 4.2.7/RFC5061 "Supported Extensions Parameter"? Again this appears to be a generic function for SCTP. >> >>> o The partial reliability extension defined in [RFC3758] MUST be >>> supported. In addition to the timed reliability PR-SCTP policy >>> defined in [RFC3758], the limited retransmission policy defined in >>> [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported. >>> >>> [CHH] I see no reason for support of partial reliability - eventhough >>> I have to admit I am not sure what it really means. In any case, my >>> suggestion is that CLUE always use "full" reliability. [/CHH] >>> >> [CNG] For the current Advertise/Configure procedures I also would see no support of partial reliability. However is CLUE evolves to somehow signal speaker changes in real time then this could come in handy. i.e. >> Bullet 1 clause 1.3/RFC3758. Rather than retransmission what is more important is that the most recent speaker message is processed. It would prevent a momentary audio/video switch. >> >> As for limited retransmissions I'm not sure what the applicability would be to a CLUE channel? > Also, don't think that you can't "switch" between reliable and non-reliable. [CNG] I think the distinction is "reliable" and "less-reliable". Even in a "partial" mode the messages are delivered reliably expect when there's an indication "forget the previous messages" use this "one". So a sender could still deliver messages reliably in a "partial mode". > >>> Once support for message interleaving as currently being discussed in >>> >>> [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported. >>> >>> [CHH] Assuming we can rely on application-level fragmentation, I >>> assume we would not need it. But, again, I am not familiar with the >>> details of message interleaving. [/CHH] >>> >> [CNG] We currently don't have CLUE level fragmentation. Were you thinking of something else? > That is what PPID value 51 is used for. It basically indicates "More information is coming", so the receiver will have to buffer the received data. I don't think we need to add any extra to the CLUE protocol itself for this. [CNG] See other email about this PID based segmentation/reassembly. > > My understanding is that this was used in the demo shown at the virtual interim? > > Regards, > > Christer > From Christian.Groves@nteczone.com Wed Feb 5 15:40:38 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2999C1A0224 for ; Wed, 5 Feb 2014 15:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaRr2N_Dw2yJ for ; Wed, 5 Feb 2014 15:40:36 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F711A0141 for ; Wed, 5 Feb 2014 15:40:36 -0800 (PST) Received: from ppp118-209-130-44.lns20.mel6.internode.on.net ([118.209.130.44]:52034 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBC4q-00033r-9v for clue@ietf.org; Thu, 06 Feb 2014 10:40:20 +1100 Message-ID: <52F2CBD7.40309@nteczone.com> Date: Thu, 06 Feb 2014 10:40:07 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15BCF1@ESESSMB209.ericsson.se> <52F2C4CF.3080906@nteczone.com> <52F2C6A0.7060104@alum.mit.edu> In-Reply-To: <52F2C6A0.7060104@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Correct PPID values X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 23:40:38 -0000 Hello Paul, On 6/02/2014 10:17 AM, Paul Kyzivat wrote: > On 2/5/14 6:10 PM, Christian Groves wrote: >> Hello Christer, >> >> Will these be valid in light of the discussions segmentation and >> reassembly on the RTCweb list? If we were to rely on SCTP NDATA would we >> then only need one PID? > > One one for *data*. There are still separate ones for OPEN and ACK. [CNG] I agree one for data. > > Thanks, > Paul > >> Regards, Christian >> >> On 5/02/2014 10:14 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> I noticed that, in the CLUE data channel draft, and in the associated >>> e-mail discussions, I have been talking about usage of PPID values 50 >>> and 51 when transporting CLUE protocol messages. >>> >>> The *correct* values are *51* (DOMString Last )and *54* (DOMString >>> Partial). >>> >>> 50 is used for the rtcweb data channel protocol. >>> >>> Sorry for the confusion. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Wed Feb 5 15:42:01 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414711A016B for ; Wed, 5 Feb 2014 15:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrXkY-6D_qXN for ; Wed, 5 Feb 2014 15:42:00 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id C5C581A013B for ; Wed, 5 Feb 2014 15:41:59 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id Ne981n0051c6gX85DnhyHR; Wed, 05 Feb 2014 23:41:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id Nnhy1n00k3ZTu2S3jnhyYo; Wed, 05 Feb 2014 23:41:58 +0000 Message-ID: <52F2CC46.7060108@alum.mit.edu> Date: Wed, 05 Feb 2014 18:41:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D1586CE@ESESSMB209.ericsson.se> <52F1985A.8070006@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15B6B5@ESESSMB209.ericsson.se> <52F2C75F.4090009@nteczone.com> In-Reply-To: <52F2C75F.4090009@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=1391643718; bh=8lhpeOs9Xemzjhc/3a3IJv6HBPzPP4u6294S503xdco=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HuRd2zAHFNWJE1E0N4RhJWksMYTmoy8Hx/PbSc8x3ZDGC7n6WHAw+thJ4qhX6Gwj+ 8rmQYIO7njzvPEfN7lFmnOrz0MUOjIFcWMZCYKsS/DXru4tcqz/LHGtdH43dY2PZOL ciYIjdRPiu3W368YpMNRHAckC8cEXCUyG4qFWvAb/0c/P1Lj8hhHYWdqpJW831Bj3q v+cliC9oSK3oQogkiAVX7xzVjbqGLQEpMSzVs9IrLRGSS04lFvEvdMXDoVemFHof8L HCYUnkMTbRjpaQ0V51hfcN4g/H64Ouv0N628Hc1DTvo3phTWQiP/xQ772vku/XwtAv I2fcvsO1sjUiw== Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 23:42:01 -0000 On 2/5/14 6:21 PM, Christian Groves wrote: > Hello Christer, > > On 5/02/2014 6:40 PM, Christer Holmberg wrote: >> Hi Christian, >> >>> Part of the reason I suggested to use those sections of >>> rtcweb-data-channel is so that we can make an educated decision about >>> what we want to support for CLUE. >> I could add the text, and indicate that the CLUE usage is FFS. >> >>>> Christian earlier suggested that we could copy/paste section 6.1 from >>>> the rtcweb-data-channel draft into our draft. >>>> >>>> I think we need to consider whether we really need the features listed >>>> in that chapter (unless, of course, the usage of them is mandated in >>>> order to be compatible with rtcweb). >>>> >>> [CNG] I agree. However if we say functions are not supported CLUE and >>> RTCWEB says that they must be supported. What does >>> that mean? e.g. We mandate the use of RTCweb data channel for CLUE. >>> Therefore the rules of RTCweb data channel apply. Stream reset >>> extension MUST be supported. >>> However for CLUE we say it shouldn't be supported. The endpoint is >>> not an RTCWEB endpoint it only supports CLUE over SCTP. So does it >>> need to implement stream reset or not? >> Those are things we need to clarify with RTCWEB. >> >>>> The features are listed below, with some initial comments ([CHH]). >>>> >>>> o The stream reset extension defined in [RFC6525] MUST be supported. >>>> It is used for closing channels. >>>> >>>> [CHH] I may have misunderstood RFC6526, but I don't think this is for >>>> CLOSING channels. It's for reseting the number sequence, which I think >>>> is a different thing. >>>> >>>> In any case, I currently see no reason why we would need to mandate >>>> support of this in CLUE. [/CHH] >>>> >>> [CNG] I think the "resetting" is part of closing a channel. The >>> resetting is done so that you can use the channel for another protocol. >>> I'd say this has more of a general applicability An endpoint may want >>> to close a channel and reuse it for CLUE or vice-versa. >> Sure. And, if someone wants to use it - fine. But, from a CLUE >> perspective we only have one protocol, so we don't need to mandate it. > [CNG] CLUE may be initiated in a channel previously occupied by another > application. 'Resetting' a closed CLUE channel may also be seen as a > "clean/complete" closure of the CLUE channel. I think we have talked about the possibility of signaling "I don't want to do CLUE any more on this call". Given the possibility of using some data channels (sctp streams) for non-clue purposes, we can't require removing the SCTP association to indicate this. ISTM that closing the channel, by resetting the corresponding streams, could be part of that. Perhaps accompanied by a Configure that doesn't request any encodings. (We might want to use a channel close for error recovery too.) And once you have said "I don't want to do CLUE any more", then later you may change your mind and say "now I want to do CLUE again". That *could* be indicated by sending an OPEN for the CLUE protocol again. And this time it might be on a different channel. But (if we agree not to use one channel for both provider and consumer) I don't see any non-error cases where we would have two concurrent clue channels. Thanks, Paul From Christian.Groves@nteczone.com Wed Feb 5 16:05:11 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441801A0215 for ; Wed, 5 Feb 2014 16:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.6 X-Spam-Level: * X-Spam-Status: No, score=1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, MANGLED_SIDE=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbWSvHlWyEEd for ; Wed, 5 Feb 2014 16:05:09 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78D41A01BA for ; Wed, 5 Feb 2014 16:05:08 -0800 (PST) Received: from ppp118-209-130-44.lns20.mel6.internode.on.net ([118.209.130.44]:52461 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBCSk-0006rV-7Z for clue@ietf.org; Thu, 06 Feb 2014 11:05:02 +1100 Message-ID: <52F2D1B0.8000007@nteczone.com> Date: Thu, 06 Feb 2014 11:05:04 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> <52F2734C.7050000@alum.mit.edu> In-Reply-To: <52F2734C.7050000@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 00:05:11 -0000 Hello On 6/02/2014 4:22 AM, Paul Kyzivat wrote: > A lot inline > > On 2/5/14 10:45 AM, Christer Holmberg wrote: >> Hi, >> >>>>>>> It wouldn't hurt to state that for CLUE messages. Section 6.4 >>>>>>> could be altered slightly for CLUE. >>>>>> I think section 6.4 is more or less what I currently have in >>>>>> section 3.2.1. But, maybe it should be added to a "Channel >>>>>> Definition" section. >>>>> [CNG] Yes pretty much along the lines of section 3.2.1. Will an >>>>> endpoint only ever have two CLUE channels (one send/one receive) >>>>> per SCTP association? >>> >>> AFAIK we have not settled on that yet. >>> Two possibilities have been discussed: >>> >>> - one bidirectional channel (one outgoing and one incoming SCTP stream) >>> used for: sending clue requests and responses, receiving clue >>> requests >>> and responses. >>> >>> - two bidirectional channels: >>> . one for sending clue requests and receiving clue responses >>> (provider role) >>> . one for receiving clue requests and sending clue responses >>> (consumer role) >>> >>> Using two leverages sctp stream multiplexing to handle the >>> multiplexing of the provider role messages with the consumer role >>> messages. So it can simplify the implementation of the clue protocol. [CNG] How would this simplify things? When you talk about multiplexing the provider and consumer roles it sounds like two different protocols. I think we should consider one protocol and not talk about multiplexing roles. >>> >>> OTOH this means that it would be harder to map the clue protocol >>> onto a reliable transport that doesn't have multiple streams. >>> >>> My impression is that there has been a preference for using a single >>> channel, but I don't recall that we made a final decision on it. >> >> My suggestion is to use one bidirectional channel. [CNG] I would also lean to one bidirectional channel. >> >> I am not even sure how/if rtcweb supports multiple data channels. At >> least the current drafts seem to assume that only one will be used - >> at least per a single SCTP association :) > > Christer - how can you say that? Supporting multiple channels is a > major part of the data channel work in rtcweb and webrtc. > > In rtcweb you get multiple channels by sending multiple OPEN messages. > (I don't follow the api work much, but the api for creating a channel > can be called multiple times.) > > I am quite certain that there is no doubt about this. [CNG] Like Paul I thought that the rtcweb did support multiple channels. Where is this limitation? > >>>> Something like this: >>>> >>>> "3.2. CLUE Data Channel Definition >>>> >>>> The realization of a bidirectional CLUE Data Channel is a pair >>>> of one >>>> incoming SCTP stream and one outgoing SCTP stream. These >>>> streams are >>>> then used to transport CLUE messages in both directions. >>>> >>>> The SCTP streams MUST belong to the same SCTP association. >>>> >>>> The SCTP streams SHOULD have identical SCTP stream identifier >>>> values, >>>> unless a specific value is already used for some other purpose. [CNG] Can there be multiple CLUE data channels per SCTP association? >>> >>> If it is *possible* that the two stream ids might not be identical, >>> then we need a way to determine which ones are paired. >> Yes, and there is a discussion (initiated by yourself, with some >> extra fuel added by me :) on the RTCWEB list regarding that, so let's >> see what the outcome will be. >> >> (Of course, one could use the Data Channel Protocol, and then the >> receiver will see on which stream the messages are received, and >> assume that the stream will be used for whatever protocol is >> indicated. ) > > If you use the data channel protocol, then one end chooses an unused > stream id and sends the OPEN message. The other end will receive that, > necessarily on the *same* stream id. (That is how SCTP works.) > > Then the receiver of the OPEN must send an ACK. It must choose some > stream ID to send that ACK on. And it must choose it in such a way > that the other end will know that the ACK correlates to the correct OPEN. > > The Webrtc Data Channel Protocol says that one side always uses *even* > stream IDs to send OPENs, and the other side always uses *odd* stream > IDs to send OPENs. That already *implies* that the intent is that the > paired stream use the same ID, but doesn't really require it. > > Consider the following > > Alice Bob > | OPEN(id=1) | > |------------------->| > | | > | OPEN(id=4) | > |<-------------------| > | | > | OPEN(id=3) | > |------------------->| > | | > | ACK(id=3) | > |<-------------------| > | | > | DATA(id=3) | > |<-------------------| > | | > | DATA(id=3) | > |------------------->| > | | > | ACK(id=4) | > |------------------->| > | | > | DATA(id=4) | > |<-------------------| > | | > | ACK(id=1) | > |<-------------------| > | | > | OPEN(id=2) | > |<-------------------| > | | > | ACK(id=2) | > |------------------->| > > The above is assuming that stream ids in one direction are paired with > stream ids in the other direction to make a channel. So from a channel > perspective the above would look like: > > Alice Bob > | OPEN(id=1) | > |------------------->| > | | > | ACK(id=1) | > |<-------------------| > > Alice Bob > | | > | OPEN(id=2) | > |<-------------------| > | | > | ACK(id=2) | > |------------------->| > > Alice Bob > | | > | OPEN(id=3) | > |------------------->| > | | > | ACK(id=3) | > |<-------------------| > | | > | DATA(id=3) | > |<-------------------| > | | > | DATA(id=3) | > |------------------->| > > Alice Bob > | | > | OPEN(id=4) | > |<-------------------| > | | > | ACK(id=4) | > |------------------->| > | | > | DATA(id=4) | > |<-------------------| > > The even/odd rule ensures that the ids used by one side for open won't > be used by the other side for open, and so will remain free to be used > for ack. > > *in principle* if an OPEN is received on an even stream id the paired > return stream id could be some *different* even number. But then the > issue of how to match them remains a problem. > > There are a whole bunch of labels involved in the above. > > Alice: > - IP address (IP-A) > - UDP port number (UDP-A) > - SCTP port number (SCTP-A) > - SCTP outgoing stream id (SID-1, SID-3) > - SCTP incoming stream id (SID-2, SID-4) > > Bob: > - IP address (IP-B) > - UDP port number (UDP-B) > - SCTP port number (SCTP-B) > - SCTP outgoing stream id (SID-2, SID-4) > - SCTP incoming stream id (SID-1, SID-3) > > The pairing of IP address, UDP port, and SCTP port is defined by SDP O/A: > > Alice: > m=application UDP-A DTLS/SCTP SCTP-A > c=IN IP4 IP-A > a=sctpmap:SCTP-A webrtc-datachannel 16 > > Bob: > m=application UDP-B DTLS/SCTP SCTP-B > c=IN IP4 IP-B > a=sctpmap:SCTP-B webrtc-datachannel 16 > > But the matching outgoing and incoming SCTP stream ids is not defined > by SDP (at least not without something like the Ejzak draft). [CNG] If we only have a single bi-directional CLUE channel per STCP association is this matching a problem? Alice: m=application UDP-A DTLS/SCTP SCTP-A c=IN IP4 IP-A a=sctpmap:SCTP-A webrtc-datachannel 16 a=sctpmap:SCTP-A CLUE 17 Bob: m=application UDP-B DTLS/SCTP SCTP-B c=IN IP4 IP-B a=sctpmap:SCTP-B webrtc-datachannel 16 a=sctpmap:SCTP-B CLUE 18 By labeling the channel CLUE and the fact there is only one CLUE channel per association you are tying together the send and receive channels. > I wonder, are you getting the stream id issues mixed up with port > number issues? > > Thanks, > Paul > >> Regards, >> >> Christer >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Feb 5 16:19:45 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EA01A02A4 for ; Wed, 5 Feb 2014 16:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OA2kBEbxKO8C for ; Wed, 5 Feb 2014 16:19:41 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF281A02A5 for ; Wed, 5 Feb 2014 16:19:40 -0800 (PST) Received: from ppp118-209-130-44.lns20.mel6.internode.on.net ([118.209.130.44]:52683 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBCgo-0000FH-73 for clue@ietf.org; Thu, 06 Feb 2014 11:19:34 +1100 Message-ID: <52F2D518.4070801@nteczone.com> Date: Thu, 06 Feb 2014 11:19:36 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> <52CB8BB9.70503@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E3E6@CRPMBOXPRD07.polycom.com> <52CF5885.2090002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4FF@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF15FFC@CRPMBOXPRD07.polycom.com> <52DC8BC8.7000204@nteczone.com> <52DD6047.4030101@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16388@CRPMBOXPRD07.polycom.com> <52DDAAF7.9020506@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF1646F@CRPMBOXPRD07.polycom.com> <52DF051B.5040809@nteczone.com> <52E00EE7.3020205@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D01E6DF@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D0F8123@CRPMBOXPRD07.polycom.com> <52E837F9.2090201@nteczone.com> <52F293FC.5080502@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FAF30@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FAF30@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't describe video locations within composed MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 00:19:45 -0000 Hello Paul and Mark, The Max-captures attributes currently indicates the maximum number of captures that appears in a MCC at any particular point in time. i.e. MCC(VC1,VC2,VC3),MaxCaptures=3 So a Consumer has to assume because this is a maximum that VC1, VC2, VC3, (VC1,VC2), (VC1,VC3), (VC2,VC3) or (VC1,VC2,VC3) can appear at any point in time. However the Consumer only ever sends a composition of (VC1,VC2,VC3). It is never going to change that combination. It seems to me that in this case using MaxCaptures as it is currently defined is semantically incorrect. So what I am suggesting is simply to add a way to correctly indicate this "constant number of captures" case, i.e. (VC1,VC2,VC3). I think Paul is questioning the attribute in general. I do believe that knowing the number of sources may be beneficial for a consumer in deciding which MCC/Captures to select. There may be tradeoffs vs a MCC only showing a limited number (i.e. one source) at a time vs another MCC showing multiple sources at a time. Regards, Christian On 6/02/2014 9:21 AM, Duckworth, Mark wrote: > I too am confused about Christian's suggestion for changing or clarifying the maxcaptures attribute. > Christian, can you explain again please? > For now, I think I agree with Paul that there is no reason to change the current description of maxcaptures. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Wednesday, February 05, 2014 2:42 PM >> To: clue@ietf.org >> Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't describe >> video locations within composed MCC >> >> On 1/28/14 6:06 PM, Christian Groves wrote: >>> Hello Mark, >>> >>> I was simply replying to Paul. I wasn't seeking to over turn any >>> decision on spatial parameters (not that I was aware of the outcome of >>> the meeting). >>> >>> An issue was brought up several times about the maxcaptures parameter >>> meaning any number of sources up to a value and that this caused >>> uncertainty to the consumer. This parameter is independent of any >>> spatial parameters thus my reply to Paul. I was suggesting a >>> modification by apply this parameter to say "=" in addition to "<=" to >>> this to solve that problem. If the Advertiser is only going to send a >>> MCC with a fixed number of captures then it seems to me that its >>> semantically incorrect t =o imply less may be sent. >> I'm still not entirely clear what this means. >> >> IIUC, the intent is that if the MCC has N sources, and maxcaptures (or >> number-of-captures) is M, then: >> - if N>1 and M=1 then this is a "switched" capture >> - if N>1 and M=N then this is a "composed" capture >> >> But - that doesn't say anything about 1> cases where there are combinations of switching and composition. And of >> course it also doesn't deal with composition where some images are smaller >> than others, and overlapping that hides parts of some captures. >> It also doesn't deal with what will happen if the Configure selects a subset of >> the sources in the MCC. >> >> I see no way to deal with that with a single number. And I don't see any >> compelling reason to do so. >> >> The "switched" and "composed" attributes cover the two extremes, and also >> indicate (when both or neither are specified) that the situation is something >> other than one of the extremes. Does having a number improve on that? >> >> Thanks, >> Paul >> >>> Regards, Christian >>> >>> On 29/01/2014 4:20 AM, Duckworth, Mark wrote: >>>> Mary and Paul, could you please let us know if consensus is reached >>>> on this topic? >>>> >>>> At the interim meeting Jan 27, we reaffirmed the decision noted in >>>> Ticket #5 , meaning the >>>> group does not want to attempt to use CLUE to describe composed >>>> captures, particularly the layout of individual video images within a >>>> composed image. >>>> >>>> I think Christian is still opposed to this outcome from the interim >>>> meeting. >>>> >>>> Regards, >>>> >>>> Mark >>>> >>>> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, >>>> Mark >>>> *Sent:* Wednesday, January 22, 2014 7:16 PM >>>> *To:* Paul Kyzivat; clue@ietf.org >>>> *Subject:* Re: [clue] spatial information can't describe video >>>> locations within composed MCC >>>> >>>> Hi Paul, >>>> >>>> Paul wrote: "Lets first discuss if having this information would >>>> provide significant value. If so then we can discuss how to provide it." >>>> >>>> Yes, but we already did that, and decided it isn't valuable enough to >>>> work on as part of CLUE. This was Ticket #5 >>>> . I think we should >>>> stick with that decision. >>>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>> Sent: Wednesday, January 22, 2014 1:33 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] spatial information can't describe video >>>> locations within >>>> >>>>> composed MCC >>>>> On 1/21/14 6:39 PM, Christian Groves wrote: >>>>>> Hello Mark, >>>>>> I think I know where the disconnect is between us. Its to do with >>>>>> the >>>>>> encodings. In my examples I've been assumed that Provider only >>>>>> provides the encoding for MCC1 not the constituent captures. >>>>>> Whereas >>>>>> you've been assuming that encodings are being provided for the >>>>>> individual and MCC captures. >>>>>> In the case of the encoding only being on the MCC the consumer >>>>>> knows >>>>>> because the VCs and MCC belong to the same Capture Scene. The >>>>>> Advertiser has provided the spatial positions of VC1 being left. >>>>>> VC2 >>>>>> being centre and VC3 being right. That is their position in the >>>> composition. >>>> >>>>> That at best seems like a hack. It is repurposing the spatial info >>>> of the >>>> >>>>> captures without encodings for an entirely different purpose. >>>>> And it doesn't work right if you want to have multiple MCCs that >>>> compose >>>> >>>>> the same sources differently. (Unless you introduce another layer >>>>> of >>>>> indirection, such as you do in example below. Yet another hack.) >>>>>> In the case of multiple encodings the spatial information >>>>>> associated >>>>>> with an individual capture is likely to be a difference between >>>>>> the >>>>>> individual encodings and the MCC encoding. >>>>>> So perhaps the way to address this is to allow spatial >>>>>> information in >>>>>> individual encodings in MCCs only when those individual encodings >>>>>> are >>>>> MCCs? >>>>>> E.g. taking your example below. >>>>>> Scene 1 >>>>>> VC1 - left >>>>>> VC2 - center >>>>>> VC3 - right >>>>>> MCC2(VC1) - left-composed >>>>>> MCC3(VC2) - center-composed >>>>>> MCC4(VC3) - right-composed >>>>>> MCC1 (MCC2,MCC3,MCC4) - whole scene, maxCaptures=3 >>>>>> CSE1 (VC1, VC2, VC3) >>>>>> CSE2 (MCC1) >>>>> In effect what you have now done is introduce an explicit encoding >>>> for the >>>> >>>>> positions of the sources of a composition. (But used an obscure and >>>>> confusing notation.) >>>>> If we really want that, then I suggest we just add syntax to the >>>> declaration of >>>> >>>>> the MCC to explicitly do it. >>>>> But I don't really see the point of doing so. What can the consumer >>>> do when >>>> >>>>> it has this info that it wouldn't be able to do without it? >>>>>> In order to address the maxCaptures issue perhaps we need to >>>>>> modify >>>>>> "MaxCaptures" slightly so that it becomes "NumberofCaptures" >>>>>> where we >>>>>> could say NumberofCaptures=3 or NumberofCaptures<=3. This would >>>>>> give >>>>>> more certainty to the Consumer about what will actually be sent. >>>>> That is just another step towards describing the complete layout of >>>>> the >>>>> composition. >>>>> Lets first discuss if having this information would provide >>>> significant value. If >>>> >>>>> so then we can discuss how to provide it. >>>>> Thanks, >>>>> Paul >>>>>> Regards, Christian >>>>>> On 21/01/2014 11:54 PM, Duckworth, Mark wrote: >>>>>>> Hello Christian, >>>>>>> I still don't see how the consumer can tell anything about how >>>>>>> an >>>> MCC >>>> >>>>>>> is composed. Take this example, >>>>>>> Scene 1 >>>>>>> VC1 - left >>>>>>> VC2 - center >>>>>>> VC3 - right >>>>>>> MCC1 (VC1, VC2, VC3) - whole scene, maxCaptures=3 >>>>>>> CSE1 (VC1, VC2, VC3) >>>>>>> CSE2 (MCC1) >>>>>>> Here it is useful to give spatial information for all the >>>>>>> captures, >>>>>>> so the consumer that chooses the individual captures knows they >>>>>>> are >>>>>>> spatially related. But how is the consumer supposed to know how >>>>>>> the >>>>>>> provider is composing them inside MCC1? It could be any number >>>>>>> of >>>>>>> ways, and it could be changing over time. So my cases 2 and 3 >>>>>>> below >>>>>>> apply to why the consumer can't tell how the MCC is composed. >>>>>>> Yet it >>>>>>> still makes sense for the provider to give spatial information >>>>>>> for >>>>>>> the captures themselves. >>>>>>> Mark >>>>>>>> -----Original Message----- >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>> Christian >>>>>>>> Groves >>>>>>>> Sent: Monday, January 20, 2014 6:02 PM >>>>>>>> To: clue@ietf.org >>>>>>>> Subject: Re: [clue] spatial information can't describe video >>>>>>>> locations within composed MCC >>>>>>>> Hello Mark and Paul, >>>>>>>> Please see my responses below. >>>>>>>> Regards, Christian >>>>>>>> On 21/01/2014 8:29 AM, Duckworth, Mark wrote: >>>>>>>>> Christian, >>>>>>>>> I agree with Paul. >>>>>>>>> Christian wrote: "I cannot see why in the static case spatial >>>>>>>>> information isn't >>>>>>>> valid? In the static case the concerns of 2, 3 and 4 don't apply." >>>>>>>>> That might be true, but how is the consumer going to know if >>>>>>>>> it is >>>>>>>>> the "static >>>>>>>> case" or not? I don't see any way for the consumer to know this. >>>>>>>> [CNG] The consumer knows this because the Provider only >>>>>>>> provides >>>> the >>>> >>>>>>>> spatial information when it makes sense to do so. >>>>>>>>> Mark >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>>>>>>> Kyzivat >>>>>>>>>> Sent: Monday, January 20, 2014 12:44 PM >>>>>>>>>> To: clue@ietf.org >>>>>>>>>> Subject: Re: [clue] spatial information can't describe video >>>>>>>>>> locations within composed MCC >>>>>>>>>> On 1/19/14 9:36 PM, Christian Groves wrote: >>>>>>>>>>> Hello Mark, >>>>>>>>>>> Sorry for the delayed response. I was on vacation last week. >>>>>>>>>>> I >>>>>>>>>>> see there's been quite a lot of activity over the last week >>>>>>>>>>> with >>>>>>>>>>> respect to MCCs and the framework. >>>>>>>>>>> I saw the minutes of the meeting and saw there was a mention >>>> that >>>> >>>>>>>>>>> I should argue :-). >>>>>>>>>>> I don't agree with the outcome of the meeting. I think its >>>>>>>>>>> important to note that MCC doesn't equal switching. A MCC >>>>>>>>>>> may >>>>>>>>>>> represent a dynamic switching case OR a static case. A >>>>>>>>>>> static >>>>>>>>>>> case may be that a MCU offers a single stream where three >>>>>>>>>>> captures from an endpoint on separate streams are composed >>>>>>>>>>> into >>>>> one video stream. >>>>>>>>>> Yes, we had that in mind when discussing this. >>>>>>>>>>> I cannot see why in the >>>>>>>>>>> static case spatial information isn't valid? In the static >>>>>>>>>>> case >>>>>>>>>>> the concerns of 2, 3 and 4 don't apply. >>>>>>>>>> We may not have understood you. We were guessing what you >>>>> meant. >>>>>>>>>> Suppose there is an MCC that has three input captures, and >>>>>>>>>> composes >>>>>>>> them. >>>>>>>>>> It could compose them in many ways. It could put the three >>>> side by >>>> >>>>>>>>>> side, or one big one and two as picture-in-picture overlays, >>>> or ... >>>> >>>>>>>>>> And even with three side by side, they could be in any order. >>>>>>>> [CNG] Yes >>>>>>>>>> And the source captures could all be from multiple scenes or >>>>>>>>>> one, >>>>>>>>>> and if one, it could be the same one as the MCC or not. The >>>>>>>>>> simplest case is that they are all from the same scene as the >>>> MCC. >>>> >>>>>>>>>> But even then, the coordinates of the source captures are >>>>>>>>>> presumably meaningful if they are individually configured. We >>>>>>>>>> could see no reason to presume that their arrangement in the >>>> scene >>>> >>>>>>>>>> has anything to do with their >>>>>>>> arrangement in the MCC. >>>>>>>> [CNG] Paul you mentioned the idea of a virtual scene before. >>>>>>>> What I >>>>>>>> see an MCU doing is creating a virtual scene using these source >>>>>>>> captures. >>>>>>>> Giving Captures spatial co-ordinates within a virtual scene is >>>>>>>> a >>>>>>>> valid thing to do irrespective of the use of a MCC. The MCU may >>>>>>>> apply any transformation it wants based on the source capture >>>>>>>> information. I think this equally applies to the MCC itself. >>>>>>>> Now if the MCU constructs a composed image from several sources >>>>>>>> using a MCC I can't see why it cannot indicate the spatial >>>>>>>> position >>>>>>>> of the sources in the MCC as they also reside in the virtual space. >>>>>>>>>> So we need more info to understand your perspective on this. >>>>>>>>>>> From the minutes I didn't see an explanation of other >>>>>>>>>>> people's >>>>>>>> concerns. >>>>>>>>>>> So rather than a complete prohibition of the spatial >>>>>>>>>>> information >>>>>>>>>>> regarding individual captures I think it would be better to >>>>>>>>>>> explain that the Advertiser has a choice to include the >>>>>>>>>>> information and that the spatial information is only >>>>>>>>>>> meaningful >>>>>>>>>>> if the individual capture's spatial information is static. >>>> That's >>>> >>>>>>>>>>> what I tried to capture in the text below. >>>>>>>>>> I already commented on this earlier. >>>>>>>>>> IMO the advertiser MAY provide spatial information on an MCC. >>>> That >>>> >>>>>>>>>> would describe a place within the scene of the MCC. IMO that >>>>>>>>>> is a >>>>>>>>>> suggestion by the advertiser, but doesn't have the same >>>>>>>>>> physical >>>>>>>>>> significance as will a non-MCC capture. >>>>>>>> [CNG] I don't understand why the spatial information of the MCC >>>>>>>> has >>>>>>>> less significance than a non-MCC capture? An Advertiser >>>>>>>> constructs >>>>>>>> the scene, it give the spatial positioning. If the MCC and >>>>>>>> non-MCC >>>>>>>> captures are part of the same CSE then equal weight should be >>>> given. >>>> >>>>>>>>>> The consumer could just use this, treating the MCC like any >>>>>>>>>> other >>>>>>>>>> capture. Or, if it is smarter, and the MCC is *switched*, it >>>> could >>>> >>>>>>>>>> ignore this and look into the spatial info for the source >>>> captures. >>>> >>>>>>>> [CNG] If the MCC is "switched" AND the spatial information >>>>>>>> changes >>>>>>>> between source captures then this would be the dynamic case. I >>>> think >>>> >>>>>>>> the advice is that a Advertiser shouldn't provide this >>>>>>>> information >>>>>>>> unless it also provides a means for the Consumer to determine >>>>>>>> when >>>>>>>> the switch takes place. If the MCC is "switched" and the source >>>>>>>> spatial information is the same then the Advertiser can simply >>>>>>>> supply the spatial information at the MCC level without the >>>>>>>> need to >>>>>>>> set it on the sources. >>>>>>>>>> But none of that has anything to do with the the arrangement >>>>>>>>>> of >>>>>>>>>> composed captures within an MCC. >>>>>>>> [CNG] I don't understand the point. You only focused on the >>>> switched >>>> >>>>>>>> case. >>>>>>>> MCC is for switching and composition. >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>>> Regards, Christian >>>>>>>>>>> On 18/01/2014 9:50 AM, Duckworth, Mark wrote: >>>>>>>>>>>> We discussed this topic in the design team meeting Jan 14 >>>> >>> >>>>>>>>>> Team/minutes_140114.txt>. >>>>>>>>>>>> From the minutes: >>>>>>>>>>>> "Conclusion 1: Spatial information of the individual >>>>>>>>>>>> captures >>>>>>>>>>>> does not apply inside a composed MCC." >>>>>>>>>>>> We wanted to bring this topic back to the list to make sure >>>>>>>>>>>> we >>>>>>>>>>>> have consensus before clarifying the framework about this. >>>>>>>>>>>> Christian, or anybody else, do you still want more discussion? >>>>>>>>>>>> Regards, >>>>>>>>>>>> Mark >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>>>> Duckworth, Mark >>>>>>>>>>>>> Sent: Friday, January 10, 2014 4:04 PM >>>>>>>>>>>>> To: Christian Groves; clue@ietf.org >>>>>>>>>>>>> Subject: Re: [clue] spatial information can't describe >>>>>>>>>>>>> video >>>>>>>>>>>> locations within >>>>>>>>>>>>> composed MCC >>>>>>>>>>>>> Thanks Christian, that is an improvement. But I'm still >>>>>>>>>>>>> not >>>>>>>>>>>> convinced the >>>>>>>>>>>>> consumer can always tell when the spatial attributes are >>>>>>>>>>>>> meaningful >>>>>>>>>>>> (even >>>>>>>>>>>>> within a scene) for discerning how contributors to a >>>>>>>>>>>>> composed >>>>>>>>>>>>> MCC are arranged within the MCC. My concerns 2, 3, and 4 >>>>>>>>>>>>> below >>>>>>>>>>>>> still apply. >>>>>>>>>>>>> Does anybody else have input to this topic? >>>>>>>>>>>>> Mark >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Christian Groves >>>>>>>>>>>>>> [mailto:Christian.Groves@nteczone.com] >>>>>>>>>>>>>> Sent: Thursday, January 09, 2014 9:19 PM >>>>>>>>>>>>>> To: Duckworth, Mark; clue@ietf.org >>>>>>>>>>>>>> Subject: Re: [clue] spatial information can't describe >>>>>>>>>>>>>> video >>>>>>>>>>>> locations >>>>>>>>>>>>>> within composed MCC >>>>>>>>>>>>>> Hello Mark, >>>>>>>>>>>>>> How about something like the following? >>>>>>>>>>>>>> 7.2.1. MCC Attributes >>>>>>>>>>>>>> Attributes may be associated with the MCC instance and >>>>>>>>>>>>>> the >>>>>>>>>>>>>> Single Media Captures that the MCC references. A provider >>>>>>>>>>>>>> should avoid providing conflicting attribute values >>>>>>>>>>>>>> between >>>>>>>>>>>>>> the MCC and Single Media Captures. Where there is >>>>>>>>>>>>>> conflict >>>> the >>>> >>>>>>>>>>>>>> attributes of the MCC override any that may be present in >>>>>>>>>>>>>> the >>>>> individual captures. >>>>>>>>>>>>>> <>>>>>>>>>>>>> captures >>>>>>>>>>>>>> within a MCC and/or to the MCC itself the Provider should >>>>>>>>>>>>>> be >>>>>>>>>>>>>> aware that spatial attributes have no relation across >>>>>>>>>>>>>> Capture >>>>> Scenes. >>>>>>>>>>>>>> Therefore >>>>>>>>>>>>>> if the Provider intends to provide a spatial relation >>>>>>>>>>>>>> between >>>>>>>>>>>>>> the source Captures and the MCC then these MUST be part >>>>>>>>>>>>>> of >>>>> the >>>>>>>>>>>>>> same >>>>>>>>>>>>> Capture Scene. >>>>>>>>>>>>>> When assigning spatial information that would cause the >>>>>>>>>>>>>> spatial positioning of the source Capture to move within >>>>>>>>>>>>>> the >>>>>>>>>>>>>> MCC, the >>>>>>>>>>>> Provider >>>>>>>>>>>>>> should also be aware that a Consumer may not be able to >>>>>>>>>>>>>> determine >>>>>>>>>>>> that >>>>>>>>>>>>>> the source captures have moved.>> ... >>>>>>>>>>>>>> Regards, Christian >>>>>>>>>>>>>> On 8/01/2014 12:18 AM, Duckworth, Mark wrote: >>>>>>>>>>>>>>> Hello Christian, >>>>>>>>>>>>>>> So there are only certain circumstances in which spatial >>>>>>>>>>>> information >>>>>>>>>>>>>>> for >>>>>>>>>>>>>> components of a composed capture is relevant. For the >>>>>>>>>>>>>> case >>>>>>>>>>>>>> where you think it is important and relevant, can you >>>>>>>>>>>>>> please >>>>>>>>>>>>>> propose text for the framework to describe this? I think >>>>>>>>>>>>>> the >>>>>>>>>>>>>> framework should be more clear about when and how the >>>>> consumer >>>>>>>>>>>>>> can use >>>>>>>> this >>>>>>>>>>>>>> information for composed captures. >>>>>>>>>>>>>>> Mark >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>>>>>>> Christian Groves >>>>>>>>>>>>>>>> Sent: Tuesday, January 07, 2014 12:08 AM >>>>>>>>>>>>>>>> To: clue@ietf.org >>>>>>>>>>>>>>>> Subject: Re: [clue] spatial information can't describe >>>> video >>>> >>>>>>>>>>>>>>>> locations within composed MCC Hello Mark, I agree with >>>>>>>>>>>>>>>> respect to the fact that spatial information isn't >>>>>>>>>>>>>>>> valid >>>>>>>>>>>>>>>> across Capture Scenes. i.e. If I have an MCC in one >>>>>>>>>>>> Cap.Scene >>>>>>>>>>>>>>>> referencing individual captures from other scenes. >>>> However I >>>> >>>>>>>>>>>>>>>> think there is a valid case where an MCC can reference >>>>>>>>>>>>>>>> Individual captures from the same scene as it. In this >>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>>> I think the >>>>>>>>>>>> use of >>>>>>>>>>>>>>>> spatial >>>>>>>>>>>>>> information is valid, i.e. >>>>>>>>>>>>>>>> +-----------------------+---------------------------------+ >>>>>>>>>>>>>>>> | Capture Scene #1 | | >>>>>>>>>>>>>>>> +-----------------------|---------------------------------+ >>>>>>>>>>>>>>>> | VC1 | CapArea=Left | >>>>>>>>>>>>>>>> | VC2 | CapArea=Right | >>>>>>>>>>>>>>>> | MCC1(VC1, VC2) | | >>>>>>>>>>>>>>>> +---------------------------------------------------------+ >>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>> +-----------------------+---------------------------------+ >>>>>>>>>>>>>>>> | Capture Scene #1 | | >>>>>>>>>>>>>>>> +-----------------------|---------------------------------+ >>>>>>>>>>>>>>>> | MCC1(VC1) | CapArea=Left | >>>>>>>>>>>>>>>> | MCC2(VC2) | CapArea=Right | >>>>>>>>>>>>>>>> | MCC1(MCC1,MCC2) | | >>>>>>>>>>>>>>>> +---------------------------------------------------------+ >>>>>>>>>>>>>>>> where VC1 and VC2 are from different Capture Scenes. >>>>>>>>>>>>>>>> There are of course cases where the spatial information >>>>>>>>>>>> wouldn't be >>>>>>>>>>>>>>>> valid but in those cases the Provider wouldn't provide >>>> them, >>>> >>>>>>>>>>>>>>>> i.e. >>>>>>>>>>>>>>>> where the individual captures move. However there will >>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>> cases where the composition is static and the >>>>>>>>>>>>>>>> information >>>>>>>>>>>>>>>> would be >>>>>>>>>>>> valid. >>>>>>>>>>>>>>>> I don't think we can make a general assumption that the >>>>>>>>>>>>>>>> spatial information is >>>>>>>>>>>>>> valid or invalid in all cases. >>>>>>>>>>>>>>>> Regards, Christian >>>>>>>>>>>>>>>> On 7/01/2014 7:54 AM, Duckworth, Mark wrote: >>>>>>>>>>>>>>>>> Framework version 13 says a provider can use spatial >>>>>>>>>>>>>>>>> information of source media captures to describe how >>>>>>>>>>>>>>>>> those >>>>>>>>>>>>>>>>> sources are placed within a composed multiple content >>>>>>>>>>>>>>>>> capture (MCC). In general I think this won't work, and >>>>>>>>>>>>>>>>> I'm >>>>>>>>>>>>>>>>> not even sure under what specific conditions it might >>>> work. >>>> >>>>>>>>>>>>>>>>> So I propose removing that part, and instead add text >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> say the spatial information of individual captures >>>>>>>>>>>>>>>>> does >>>> not >>>> >>>>>>>>>>>>>>>>> relate to its relative position within a >>>>>>>>>>>> composed >>>>>>>>>>>>> MCC. >>>>>>>>>>>>>>>>> From section 7.2.1: >>>>>>>>>>>>>>>>> For example: The spatial related attributes can be >>>>>>>>>>>>>>>>> further >>>>>>>>>>>> used to >>>>>>>>>>>>>>>>> determine how the individual captures "appear" within >>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>> stream. A virtual scene could be constructed for the >>>>>>>>>>>>>>>>> MCC >>>>>>>>>>>>>>>>> capture with two Video Captures with a "MaxCaptures" >>>>>>>>>>>>>>>>> attribute set to 2 and an "Area of Capture" attribute >>>>>>>>>>>>>>>>> provided with an overall area. >>>>>>>>>>>> Each of >>>>>>>>>>>>>>>>> the individual Captures could then also include an >>>> "Area of >>>> >>>>>>>>>>>> Capture" >>>>>>>>>>>>>>>>> attribute with a sub-set of the overall area. The >>>>>>>>>>>>>>>>> Consumer >>>>>>>>>>>>>>>>> would then know the relative position of the content >>>>>>>>>>>>>>>>> in >>>> the >>>> >>>>>>>>>>>>>>>>> composed >>>>>>>>>>>>> stream. >>>>>>>>>>>>>>>>> Here are some reasons why I think this will generally >>>>>>>>>>>>>>>>> not >>>>> work: >>>>>>>>>>>>>>>>> 1.The spatial information for captures is relevant >>>>>>>>>>>>>>>>> only in >>>>>>>>>>>>>>>>> relation to the capture scene to which the captures >>>> belong. >>>> >>>>>>>>>>>>>>>>> Spatial information from different scenes has no >>>>>>>>>>>>>>>>> relation >>>>>>>>>>>>>>>>> to each other. So if the individual captures that are >>>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>> of a composed MCC come from different scenes >> (source >>>>>>>>>>>>>>>>> captures >>>>>>>> from >>>>>>>>>>>>>>>>> multiple scenes, or source captures from different >>>>>>>>>>>>>>>>> scenes >>>>>>>>>>>>>>>>> than the >>>>>>>>>>>>>>>>> MCC) >>>>>>>>>>>>>>>>> then the spatial information of one capture has no >>>> relation >>>> >>>>>>>>>>>>>>>>> to >>>>>>>>>>>> the >>>>>>>>>>>>>>>>> spatial information of another capture. >>>>>>>>>>>>>>>>> 2.In the example with MaxCaptures = 2, that doesn't >>>>>>>>>>>>>>>>> mean >>>>>>>>>>>>>>>>> there will always be 2 contributing captures in the >>>> MCC. It >>>> >>>>>>>>>>>>>>>>> just means maximum of 2, but sometimes there could >> be 1. >>>>>>>>>>>>>>>>> The contents of the MCC could actually be changing >>>>>>>>>>>>>>>>> over >>>>>>>>>>>>>>>>> time between 1 and 2 >>>>>>>>>>>>> contributing captures. >>>>>>>>>>>>>>>>> If it changes between one full screen source image to >>>>>>>>>>>>>>>>> two >>>>>>>>>>>>>>>>> source images side by side, then the spatial >>>>>>>>>>>>>>>>> information >>>>>>>>>>>>>>>>> wouldn't always indicate the location of the source >>>>>>>>>>>>>>>>> within >>>>>>>>>>>>>>>>> the MCC. We have no >>>>>>>>>>>> way >>>>>>>>>>>>>>>>> for the provider to advertise this level of detail, >>>>>>>>>>>>>>>>> and I >>>>>>>>>>>>>>>>> don't think we want to get into this detail in >>>>>>>>>>>>>>>>> provider >>>>>>>>>>>>>>>>> advertisements. >>>>>>>>>>>>>>>>> 3.Similarly, the MCC could always contain both >>>>>>>>>>>>>>>>> individual >>>>>>>>>>>>>>>>> captures, but maybe it is a large image of the one >>>>>>>>>>>>>>>>> that is >>>>>>>>>>>> talking >>>>>>>>>>>>>>>>> and a small image of the other. This would change over >>>>>>>>>>>>>>>>> time, so again the spatial information wouldn't always >>>>>>>>>>>>>>>>> indicate the location of the source within the MCC. >>>>>>>>>>>>>>>>> 4.Take a slightly different example, where the MCC >>>> contains >>>> >>>>>>>>>>>>>>>>> 4 contributing individual captures, but still with >>>>>>>>>>>>>>>>> MaxCaptures = 2. >>>>>>>>>>>>>>>>> So the resulting MCC again will change over time, as >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> provider is free to choose which 2 out of the 4 to >>>>>>>>>>>>>>>>> include >>>>>>>>>>>>>>>>> at any time. So again the spatial information wouldn't >>>>>>>>>>>>>>>>> always indicate the location of the source within the >> MCC. >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> Mark >>>>> _______________________________________________ >>>>>>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>>>>>> clue@ietf.org >>>> >>>> >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >>>>>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> clue mailing list >>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> clue mailing list >>>>>>>>>>> clue@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>> _______________________________________________ >>>>>>>>>> clue mailing list >>>>>>>>>> clue@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>> _______________________________________________ >>>>>>>>> clue mailing list >>>>>>>>> clue@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>> _______________________________________________ >>>>>>>> clue mailing list >>>>>>>> clue@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> _______________________________________________ >>>>>> 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 Christian.Groves@nteczone.com Wed Feb 5 17:23:45 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FA91A01D6 for ; Wed, 5 Feb 2014 17:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP5HLgGc2BBo for ; Wed, 5 Feb 2014 17:23:43 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id F391E1A019B for ; Wed, 5 Feb 2014 17:23:42 -0800 (PST) Received: from ppp118-209-130-44.lns20.mel6.internode.on.net ([118.209.130.44]:54678 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBDgl-0002jn-OJ for clue@ietf.org; Thu, 06 Feb 2014 12:23:35 +1100 Message-ID: <52F2E41A.7060402@nteczone.com> Date: Thu, 06 Feb 2014 12:23:38 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <52E63880.1010504@nteczone.com> In-Reply-To: <52E63880.1010504@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Text on participant type / participant information / scene information (ex.roles) for framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 01:23:46 -0000 Any comments regarding the participation information attribute text? Christian On 27/01/2014 9:44 PM, Christian Groves wrote: > Hello all, > > There's an open ticket for me to provide some text regarding "roles" > for the framework. Here's an initial attempt. > > 7.1.1.x Participant Information > > The participant information attribute allows a Provider to provide > specific information regarding the conference participants in a Capture. > The Provider may gather the information automatically or manually from a > variety of sources however the xCard [RFC6351] format is used to convey > the information. This allows various information such as Identification > information (section 6.2/[RFC6350]), Communication Information (section > 6.4/[RFC6350]) and Organisational information (section 6.6/[RFC6350]) to > be communicated. A Consumer may then automatically (i.e. via a policy) > or manually select Captures based on information about who is in a > Capture. It also allows a Consumer to render information regarding the > participants or to use it for further processing. > > The Provider may supply a minimal set of information or a larger set of > information. However it MUST be compliant to [RFC6350] and supply a > "VERSION" and "FN" property. A Provider may supply multiple xCards per > Capture of any KIND (section 6.1.4/[RFC6350]). > > In order to keep CLUE messages compact the Provider SHOULD use a URI to > point to any LOGO, PHOTO or SOUND contained in the xCARD rather than > transmitting the LOGO, PHOTO or SOUND data in a CLUE message. > > 7.1.1.y Participant Type > The participant type attribute indicates the type of participant/s > contained in the capture in the conference with respect to the meeting > agenda. As a capture may include multiple participants the attribute may > contain multiple value. However values shall not be repeated within the > attribute. > > An Advertiser associates the participant type with an individual > capture when it knows that a particular type is in the capture. If an > Advertiser cannot link a particular type with some certainty to a > capture then it is not included. A Consumer on reception of a capture > with a participant type attribute knows with some certainly that the > capture contains that participant type. The capture may contain other > participant types but the Advertiser has not been able to determine > that this is the case. > > The types of Captured participants include: > 1. Chairman - the participant responsible for running the conference > according to the agenda. > 2. Vice-Chairman - the participant responsible for assisting the > chairman in running the meeting. > 3. Minute Taker - the participant responsible for recording the minutes > of the conference > 4. Member - the participant has no particular responsibilities with > respect to running the meeting. > 5. Presenter - the participant is scheduled on the agenda to make a > presentation in the meeting. Note: This is not related to any "active > speaker" functionality. > 6. Translator - the participant is providing some form of translation or > commentary in the meeting. > 7. Timekeeper - the participant is responsible for maintaining the > meeting schedule. > > Furthermore the participant type attribute may contain one or more > strings allowing the Provider to indicate custom meeting specific roles. > > 7.3.1.x Scene Information > > The Scene information attribute provides information regarding the > Capture Scene rather than individual participants. The Provider may > gather the information automatically or manually from a variety of > sources. The scene information attribute allows a Provider to indicate > information such as: organizational or geographic information allowing a > Consumer to determine which Capture Scenes are of interest in order to > then perform Capture selection. It also allows a Consumer to render > information regarding the Scene or to use it for further processing. > > As per 7.1.1.x the xCard format is used to convey this information and > the Provider may supply a minimal set of information or a larger set of > information. > > In order to keep CLUE messages compact the Provider SHOULD use a URI to > point to any LOGO, PHOTO or SOUND contained in the xCARD rather than > transmitting the LOGO, PHOTO or SOUND data in a CLUE message. > > Comments? > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Wed Feb 5 21:21:41 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E4D1A0367 for ; Wed, 5 Feb 2014 21:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.865 X-Spam-Level: ** X-Spam-Status: No, score=2.865 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, MANGLED_SIDE=2.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si5VJgLOVADY for ; Wed, 5 Feb 2014 21:21:39 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id A12421A0365 for ; Wed, 5 Feb 2014 21:21:38 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id NtHh1n0011ap0As5DtMd1F; Thu, 06 Feb 2014 05:21:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id NtMc1n00C3ZTu2S3itMd8U; Thu, 06 Feb 2014 05:21:37 +0000 Message-ID: <52F31BE0.2070201@alum.mit.edu> Date: Thu, 06 Feb 2014 00:21:36 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> <52F2734C.7050000@alum.mit.edu> <52F2D1B0.8000007@nteczone.com> In-Reply-To: <52F2D1B0.8000007@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=1391664097; bh=VRIsjs0JrkrVk99lEi15vihTQC361/H6NTvt0NUI/t4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YYW2EJuctx6B1aWXcbz5XFokBuainFbe+CPYMz9BmMxU44GLY4NvbfKsZB4M2GGNS eJkraqFWIurbOnKxI+/7096cqO2tb1om63d8kH+7PnorSWbomn0aPliYs+ZxrmjI8R tcFhUjnQBcG0Gajmg9YcoiV+Y6F2mwdsYd3/dxG2f50kVjqzoNQfpVZmgNrNfCHjYs hAW47BgOpWz3cvsW4GeLi9Ll5Z5cpX1e9MhyqUjyt/loOKdkjP865fQM5rPgNxO6/9 dCEyjikHG3rZih0zguoq49MwPfM6zSKXDeYwFOXHIfoehkXUvPWYK8luqFvaH4L4kU OOVSNdpJ7eSjw== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 05:21:41 -0000 On 2/5/14 7:05 PM, Christian Groves wrote: > Hello > > On 6/02/2014 4:22 AM, Paul Kyzivat wrote: >> A lot inline >> >> On 2/5/14 10:45 AM, Christer Holmberg wrote: >>> Hi, >>> >>>>>>>> It wouldn't hurt to state that for CLUE messages. Section 6.4 >>>>>>>> could be altered slightly for CLUE. >>>>>>> I think section 6.4 is more or less what I currently have in >>>>>>> section 3.2.1. But, maybe it should be added to a "Channel >>>>>>> Definition" section. >>>>>> [CNG] Yes pretty much along the lines of section 3.2.1. Will an >>>>>> endpoint only ever have two CLUE channels (one send/one receive) >>>>>> per SCTP association? >>>> >>>> AFAIK we have not settled on that yet. >>>> Two possibilities have been discussed: >>>> >>>> - one bidirectional channel (one outgoing and one incoming SCTP stream) >>>> used for: sending clue requests and responses, receiving clue >>>> requests >>>> and responses. >>>> >>>> - two bidirectional channels: >>>> . one for sending clue requests and receiving clue responses >>>> (provider role) >>>> . one for receiving clue requests and sending clue responses >>>> (consumer role) >>>> >>>> Using two leverages sctp stream multiplexing to handle the >>>> multiplexing of the provider role messages with the consumer role >>>> messages. So it can simplify the implementation of the clue protocol. > [CNG] How would this simplify things? When you talk about multiplexing > the provider and consumer roles it sounds like two different protocols. > I think we should consider one protocol and not talk about multiplexing > roles. It simplifies things because we conceptually have one state machine for the provider role and one for the consumer role. If each is mapped onto a separate channel then each can operate independently. (E.g., after sending an advertisement, you can hang in a state awaiting a response to it.) When you merge the provider and consumer roles it is messier to describe. We can still do it, in a similar way to channels, by putting a role attribute into each message. But it is one more thing to do that isn't needed if you use two channels. >>>> >>>> OTOH this means that it would be harder to map the clue protocol >>>> onto a reliable transport that doesn't have multiple streams. >>>> >>>> My impression is that there has been a preference for using a single >>>> channel, but I don't recall that we made a final decision on it. >>> >>> My suggestion is to use one bidirectional channel. > [CNG] I would also lean to one bidirectional channel. > >>> >>> I am not even sure how/if rtcweb supports multiple data channels. At >>> least the current drafts seem to assume that only one will be used - >>> at least per a single SCTP association :) >> >> Christer - how can you say that? Supporting multiple channels is a >> major part of the data channel work in rtcweb and webrtc. >> >> In rtcweb you get multiple channels by sending multiple OPEN messages. >> (I don't follow the api work much, but the api for creating a channel >> can be called multiple times.) >> >> I am quite certain that there is no doubt about this. > [CNG] Like Paul I thought that the rtcweb did support multiple channels. > Where is this limitation? > >> >>>>> Something like this: >>>>> >>>>> "3.2. CLUE Data Channel Definition >>>>> >>>>> The realization of a bidirectional CLUE Data Channel is a pair >>>>> of one >>>>> incoming SCTP stream and one outgoing SCTP stream. These >>>>> streams are >>>>> then used to transport CLUE messages in both directions. >>>>> >>>>> The SCTP streams MUST belong to the same SCTP association. >>>>> >>>>> The SCTP streams SHOULD have identical SCTP stream identifier >>>>> values, >>>>> unless a specific value is already used for some other purpose. > [CNG] Can there be multiple CLUE data channels per SCTP association? >>>> >>>> If it is *possible* that the two stream ids might not be identical, >>>> then we need a way to determine which ones are paired. > >>> Yes, and there is a discussion (initiated by yourself, with some >>> extra fuel added by me :) on the RTCWEB list regarding that, so let's >>> see what the outcome will be. >>> >>> (Of course, one could use the Data Channel Protocol, and then the >>> receiver will see on which stream the messages are received, and >>> assume that the stream will be used for whatever protocol is >>> indicated. ) >> >> If you use the data channel protocol, then one end chooses an unused >> stream id and sends the OPEN message. The other end will receive that, >> necessarily on the *same* stream id. (That is how SCTP works.) >> >> Then the receiver of the OPEN must send an ACK. It must choose some >> stream ID to send that ACK on. And it must choose it in such a way >> that the other end will know that the ACK correlates to the correct OPEN. >> >> The Webrtc Data Channel Protocol says that one side always uses *even* >> stream IDs to send OPENs, and the other side always uses *odd* stream >> IDs to send OPENs. That already *implies* that the intent is that the >> paired stream use the same ID, but doesn't really require it. >> >> Consider the following >> >> Alice Bob >> | OPEN(id=1) | >> |------------------->| >> | | >> | OPEN(id=4) | >> |<-------------------| >> | | >> | OPEN(id=3) | >> |------------------->| >> | | >> | ACK(id=3) | >> |<-------------------| >> | | >> | DATA(id=3) | >> |<-------------------| >> | | >> | DATA(id=3) | >> |------------------->| >> | | >> | ACK(id=4) | >> |------------------->| >> | | >> | DATA(id=4) | >> |<-------------------| >> | | >> | ACK(id=1) | >> |<-------------------| >> | | >> | OPEN(id=2) | >> |<-------------------| >> | | >> | ACK(id=2) | >> |------------------->| >> >> The above is assuming that stream ids in one direction are paired with >> stream ids in the other direction to make a channel. So from a channel >> perspective the above would look like: >> >> Alice Bob >> | OPEN(id=1) | >> |------------------->| >> | | >> | ACK(id=1) | >> |<-------------------| >> >> Alice Bob >> | | >> | OPEN(id=2) | >> |<-------------------| >> | | >> | ACK(id=2) | >> |------------------->| >> >> Alice Bob >> | | >> | OPEN(id=3) | >> |------------------->| >> | | >> | ACK(id=3) | >> |<-------------------| >> | | >> | DATA(id=3) | >> |<-------------------| >> | | >> | DATA(id=3) | >> |------------------->| >> >> Alice Bob >> | | >> | OPEN(id=4) | >> |<-------------------| >> | | >> | ACK(id=4) | >> |------------------->| >> | | >> | DATA(id=4) | >> |<-------------------| >> >> The even/odd rule ensures that the ids used by one side for open won't >> be used by the other side for open, and so will remain free to be used >> for ack. >> >> *in principle* if an OPEN is received on an even stream id the paired >> return stream id could be some *different* even number. But then the >> issue of how to match them remains a problem. >> >> There are a whole bunch of labels involved in the above. >> >> Alice: >> - IP address (IP-A) >> - UDP port number (UDP-A) >> - SCTP port number (SCTP-A) >> - SCTP outgoing stream id (SID-1, SID-3) >> - SCTP incoming stream id (SID-2, SID-4) >> >> Bob: >> - IP address (IP-B) >> - UDP port number (UDP-B) >> - SCTP port number (SCTP-B) >> - SCTP outgoing stream id (SID-2, SID-4) >> - SCTP incoming stream id (SID-1, SID-3) >> >> The pairing of IP address, UDP port, and SCTP port is defined by SDP O/A: >> >> Alice: >> m=application UDP-A DTLS/SCTP SCTP-A >> c=IN IP4 IP-A >> a=sctpmap:SCTP-A webrtc-datachannel 16 >> >> Bob: >> m=application UDP-B DTLS/SCTP SCTP-B >> c=IN IP4 IP-B >> a=sctpmap:SCTP-B webrtc-datachannel 16 >> >> But the matching outgoing and incoming SCTP stream ids is not defined >> by SDP (at least not without something like the Ejzak draft). > [CNG] If we only have a single bi-directional CLUE channel per STCP > association is this matching a problem? Yes, if any streams may be used for any other purpose. If the entire sctp association was devoted to clue, then no. > Alice: > m=application UDP-A DTLS/SCTP SCTP-A > c=IN IP4 IP-A > a=sctpmap:SCTP-A webrtc-datachannel 16 > a=sctpmap:SCTP-A CLUE 17 > > Bob: > m=application UDP-B DTLS/SCTP SCTP-B > c=IN IP4 IP-B > a=sctpmap:SCTP-B webrtc-datachannel 16 > a=sctpmap:SCTP-B CLUE 18 > > By labeling the channel CLUE and the fact there is only one CLUE channel > per association you are tying together the send and receive channels. You have just redefined what the last parameter on a=sctpmap is for. It is defined as specifying the maximum number of channels for the association. It is not used for negotiating individual stream/channel IDs. Nor is it used for negotiating the protocol used on individual streams/channels. What you are trying to do is what the Ejzak draft does. Thanks, Paul >> I wonder, are you getting the stream id issues mixed up with port >> number issues? >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Feb 5 22:24:28 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BED51A0384 for ; Wed, 5 Feb 2014 22:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TMaSVGN2WBU for ; Wed, 5 Feb 2014 22:24:26 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA791A0382 for ; Wed, 5 Feb 2014 22:24:26 -0800 (PST) Received: from ppp118-209-130-44.lns20.mel6.internode.on.net ([118.209.130.44]:61580 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBINk-0002uf-87 for clue@ietf.org; Thu, 06 Feb 2014 17:24:16 +1100 Message-ID: <52F32A95.6060905@nteczone.com> Date: Thu, 06 Feb 2014 17:24:21 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> <52F2734C.7050000@alum.mit.edu> <52F2D1B0.8000007@nteczone.com> <52F31BE0.2070201@alum.mit.edu> In-Reply-To: <52F31BE0.2070201@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 06:24:28 -0000 Hello Paul, > Yes, if any streams may be used for any other purpose. > If the entire sctp association was devoted to clue, then no. > >> Alice: >> m=application UDP-A DTLS/SCTP SCTP-A >> c=IN IP4 IP-A >> a=sctpmap:SCTP-A webrtc-datachannel 16 >> a=sctpmap:SCTP-A CLUE 17 >> >> Bob: >> m=application UDP-B DTLS/SCTP SCTP-B >> c=IN IP4 IP-B >> a=sctpmap:SCTP-B webrtc-datachannel 16 >> a=sctpmap:SCTP-B CLUE 18 >> >> By labeling the channel CLUE and the fact there is only one CLUE channel >> per association you are tying together the send and receive channels. > > You have just redefined what the last parameter on a=sctpmap is for. > It is defined as specifying the maximum number of channels for the > association. It is not used for negotiating individual stream/channel > IDs. Nor is it used for negotiating the protocol used on individual > streams/channels. [CNG] Doh, you're right.... serves me for not reading that parameter properly. Christian > > What you are trying to do is what the Ejzak draft does. > > Thanks, > Paul > >>> I wonder, are you getting the stream id issues mixed up with port >>> number issues? >>> >>> Thanks, >>> Paul >>> >>>> 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 Wed Feb 5 23:30:36 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001DC1A037A for ; Wed, 5 Feb 2014 23:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVm5FAkEo0KP for ; Wed, 5 Feb 2014 23:30:34 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C1BD31A004C for ; Wed, 5 Feb 2014 23:30:33 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-db-52f33a17f79e Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 67.29.04249.71A33F25; Thu, 6 Feb 2014 08:30:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 08:30:31 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Correct PPID values Thread-Index: Ac8iYw+fQNbHDJueSNqYzo9vUje5OQAW/d2AAABFSwAAAMbugAASgdNw Date: Thu, 6 Feb 2014 07:30:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15E755@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15BCF1@ESESSMB209.ericsson.se> <52F2C4CF.3080906@nteczone.com> <52F2C6A0.7060104@alum.mit.edu> <52F2CBD7.40309@nteczone.com> In-Reply-To: <52F2CBD7.40309@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvja6E1ecgg13LWC2+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJXxf85epoI9fBWzVtxla2B8wd3FyMEhIWAi 0ffHuYuRE8gUk7hwbz1bFyMXh5DAEUaJ2W/vMUE4ixgl+nbsZwRpYBOwkOj+pw3SICIQLtGx 7QojiC0soC5x4uJCRoi4hsTZhjUsELabxP2md0wgNouAisTXK/fAangFfCW+n9vODjF/PaPE 6en9zCAJTgEtiT3LP7KB2IxAF30/tQasmVlAXOLWk/lMEJcKSCzZc54ZwhaVePn4HyuErSjR /rSBEaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxg5ilOL k3LTjQw2MQKj4eCW3xY7GC//tTnEKM3BoiTO+/Gtc5CQQHpiSWp2ampBalF8UWlOavEhRiYO TqkGxrt3TS6u6fP50T8xLLczcHY4R7jZNF3OL491foulnqybdF075bh+redrZh4j8/or9noS h56mOAt9MVoetliqyWCaxPGd2/M4FtWWNYv8Lig75NPvUsbkWPCtnPfjB5uOE3GmBx3dlt5u WxjWa/HSjIH7NGvovVcqmjOqU0SSqpsMdpvH2pYpsRRnJBpqMRcVJwIA7+/ma1QCAAA= Subject: Re: [clue] Correct PPID values X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 07:30:36 -0000 Hi, Value 50 is used for the Data Channel Protocol messages (OPEN, ACK). Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves Sent: 6. helmikuuta 2014 1:40 To: clue@ietf.org Subject: Re: [clue] Correct PPID values Hello Paul, On 6/02/2014 10:17 AM, Paul Kyzivat wrote: > On 2/5/14 6:10 PM, Christian Groves wrote: >> Hello Christer, >> >> Will these be valid in light of the discussions segmentation and=20 >> reassembly on the RTCweb list? If we were to rely on SCTP NDATA would=20 >> we then only need one PID? > > One one for *data*. There are still separate ones for OPEN and ACK. [CNG] I agree one for data. > > Thanks, > Paul > >> Regards, Christian >> >> On 5/02/2014 10:14 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> I noticed that, in the CLUE data channel draft, and in the=20 >>> associated e-mail discussions, I have been talking about usage of=20 >>> PPID values 50 and 51 when transporting CLUE protocol messages. >>> >>> The *correct* values are *51* (DOMString Last )and *54* (DOMString=20 >>> Partial). >>> >>> 50 is used for the rtcweb data channel protocol. >>> >>> Sorry for the confusion. >>> >>> 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 christer.holmberg@ericsson.com Thu Feb 6 00:48:12 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2322E1A018E for ; Thu, 6 Feb 2014 00:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4dVexCwDI3Q for ; Thu, 6 Feb 2014 00:48:10 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 085B91A01FB for ; Thu, 6 Feb 2014 00:48:09 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-24-52f34c484afe Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8B.4E.23809.84C43F25; Thu, 6 Feb 2014 09:48:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 09:48:07 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 Thread-Index: AQHPIs8cI2cElEKsU06ZC1P7l2XpTpqnoDoAgAARiICAADdvoA== Date: Thu, 6 Feb 2014 08:48:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15EDEF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> <52F2734C.7050000@alum.mit.edu> <52F2D1B0.8000007@nteczone.com> <52F31BE0.2070201@alum.mit.edu> <52F32A95.6060905@nteczone.com> In-Reply-To: <52F32A95.6060905@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvja6Hz+cgg29bVCy+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJXxfmUje8FRroqNy+8wNjAu5ehi5OSQEDCR eHW8jxHCFpO4cG89WxcjF4eQwCFGiZOXO5khnEWMEkv+t7F0MXJwsAlYSHT/0wZpEBEIl+jY dgWsWVggSOL2/bssEPFgiUX7t7JD2E4SWw+vYQKxWQRUJLb//skMYvMK+Eosez2ZEWJ+I4vE 0/PfwBKcAjoSl7Y/YwWxGYEu+n4KoplZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B8rhK0ocXX6 cqh6HYkFuz+xQdjaEssWvoZaLChxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYmTPTczMSS83 2sQIjIaDW36r7mC8c07kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhg5 1G+VqVRudNc//PSF0Em/jc7/1j94lBZ3Q0RthmjQryNVpsmTUsvTFNsFPrhN3DN9hlLgHX8T w+h2j6dFXKZmfl88371o5OvaZTVRnik6unNuq4Dto6mTpq17tfhWcfKl82smMbq3ut/Zcqlt iqHRyyZ7k4I7a5Lf+gXMl/Lu3Mf77cU+19tKLMUZiYZazEXFiQC+IfJLVAIAAA== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 08:48:12 -0000 Hi, >>> Alice: >>> m=3Dapplication UDP-A DTLS/SCTP SCTP-A >>> c=3DIN IP4 IP-A >>> a=3Dsctpmap:SCTP-A webrtc-datachannel 16 >>> a=3Dsctpmap:SCTP-A CLUE 17 >>> >>> Bob: >>> m=3Dapplication UDP-B DTLS/SCTP SCTP-B >>> c=3DIN IP4 IP-B >>> a=3Dsctpmap:SCTP-B webrtc-datachannel 16 >>> a=3Dsctpmap:SCTP-B CLUE 18 >>> >>> By labeling the channel CLUE and the fact there is only one CLUE=20 >>> channel per association you are tying together the send and receive cha= nnels. >> >> You have just redefined what the last parameter on a=3Dsctpmap is for. >> It is defined as specifying the maximum number of channels for the=20 >> association. It is not used for negotiating individual stream/channel=20 >> IDs. Nor is it used for negotiating the protocol used on individual=20 >> streams/channels. > [CNG] Doh, you're right.... serves me for not reading that parameter prop= erly. This probably belongs to MMUSIC, but I wonder how "specifying the number of= channels" really will work. There is no general channel concept in SCTP. R= TCWEB have their specific definition of a channel, and in CLUE we have our = (which is identical to the RTCWEB one). But, maybe I want to use DTLS/SCTP = for a protocol X, which doesn't define a channel concept to begin with. Regards, Christer From Christian.Groves@nteczone.com Thu Feb 6 01:58:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052531A00B0 for ; Thu, 6 Feb 2014 01:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XiXlAOiVIGl for ; Thu, 6 Feb 2014 01:58:05 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA0C1A00A9 for ; Thu, 6 Feb 2014 01:58:04 -0800 (PST) Received: from ppp118-209-130-44.lns20.mel6.internode.on.net ([118.209.130.44]:64856 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBLiS-0004gb-EP; Thu, 06 Feb 2014 20:57:52 +1100 Message-ID: <52F35CA7.8090007@nteczone.com> Date: Thu, 06 Feb 2014 20:57:59 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> <52F2734C.7050000@alum.mit.edu> <52F2D1B0.8000007@nteczone.com> <52F31BE0.2070201@alum.mit.edu> <52F32A95.6060905@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15EDEF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15EDEF@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 09:58:06 -0000 On 6/02/2014 7:48 PM, Christer Holmberg wrote: > Hi, > >>>> Alice: >>>> m=application UDP-A DTLS/SCTP SCTP-A >>>> c=IN IP4 IP-A >>>> a=sctpmap:SCTP-A webrtc-datachannel 16 >>>> a=sctpmap:SCTP-A CLUE 17 >>>> >>>> Bob: >>>> m=application UDP-B DTLS/SCTP SCTP-B >>>> c=IN IP4 IP-B >>>> a=sctpmap:SCTP-B webrtc-datachannel 16 >>>> a=sctpmap:SCTP-B CLUE 18 >>>> >>>> By labeling the channel CLUE and the fact there is only one CLUE >>>> channel per association you are tying together the send and receive channels. >>> You have just redefined what the last parameter on a=sctpmap is for. >>> It is defined as specifying the maximum number of channels for the >>> association. It is not used for negotiating individual stream/channel >>> IDs. Nor is it used for negotiating the protocol used on individual >>> streams/channels. >> [CNG] Doh, you're right.... serves me for not reading that parameter properly. > This probably belongs to MMUSIC, but I wonder how "specifying the number of channels" really will work. There is no general channel concept in SCTP. RTCWEB have their specific definition of a channel, and in CLUE we have our (which is identical to the RTCWEB one). But, maybe I want to use DTLS/SCTP for a protocol X, which doesn't define a channel concept to begin with. I don't know. This becomes a real problem at a gateway especially decomposed one. How do I map SCTP streams (particularly if they relate to multiple application protocols) received at one side of the gateway to the other? Christian > > Regards, > > Christer > > From christer.holmberg@ericsson.com Thu Feb 6 02:49:04 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C731A0358 for ; Thu, 6 Feb 2014 02:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.56 X-Spam-Level: X-Spam-Status: No, score=0.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 564PC3y4qE8T for ; Thu, 6 Feb 2014 02:49:03 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 898281A02F6 for ; Thu, 6 Feb 2014 02:49:02 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-6a-52f3689c09c4 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 17.E5.04853.C9863F25; Thu, 6 Feb 2014 11:49:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 11:49:00 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 Thread-Index: AQHPIyHv6bHKVuvRz0+OTaskWEBd3pqoCzPQ Date: Thu, 6 Feb 2014 10:48:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15F0DA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> <52F2734C.7050000@alum.mit.edu> <52F2D1B0.8000007@nteczone.com> <52F31BE0.2070201@alum.mit.edu> <52F32A95.6060905@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15EDEF@ESESSMB209.ericsson.se> <52F35CA7.8090007@nteczone.com> In-Reply-To: <52F35CA7.8090007@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje6cjM9BBr0dVhZf3jeyWOw/dZnZ gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mr4dHw1U8EPvord/6cwNzC+4O5i5OSQEDCR WHd4LxuELSZx4d56IJuLQ0jgBKPE5aavzBDOIkaJ67sOsnQxcnCwCVhIdP/TBmkQEQiX6Nh2 hRHEFhYIkpi27ywrRDxY4t6BnYwg5SICRhJntuqChFkEVCQuXOsC28Ur4CuxcMVyqPHPWSQ+ 7W5gAklwCuhILJnwDcxmBDro+6k1YDazgLjErSfzmSAOFZBYsuc8M4QtKvHy8T9WCFtJ4seG SywQ9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFmcWlyc m25koJebnluil1qUmVxcnJ+nV5y6iREYLwe3/DbawXhyj/0hRmkOFiVx3uusNUFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGCcuui7yM/S1bfua1sglDbMYOiPcvrP2Np90u/gous2s0OBR w3fxyYacdxu1Dz5Yb89Z/8ZIIP+kbJ7lq89cYiuK+Q5JHeNmPM35VMei+mfX1iUzl98/Fbt8 21yJfFdF75zs/YvP6IQ6TzxvUPP3EcPar/sqZ3PEeW9V/HlOmE1/c6TNz2hxNSWW4oxEQy3m ouJEAD1IGC1lAgAA Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 10:49:04 -0000 Hi, >>>>> Alice: >>>>> m=3Dapplication UDP-A DTLS/SCTP SCTP-A >>>>> c=3DIN IP4 IP-A >>>>> a=3Dsctpmap:SCTP-A webrtc-datachannel 16 >>>>> a=3Dsctpmap:SCTP-A CLUE 17 >>>>> >>>>> Bob: >>>>> m=3Dapplication UDP-B DTLS/SCTP SCTP-B >>>>> c=3DIN IP4 IP-B >>>>> a=3Dsctpmap:SCTP-B webrtc-datachannel 16 >>>>> a=3Dsctpmap:SCTP-B CLUE 18 >>>>> >>>>> By labeling the channel CLUE and the fact there is only one CLUE=20 >>>>> channel per association you are tying together the send and receive c= hannels. >>>> You have just redefined what the last parameter on a=3Dsctpmap is for. >>>> It is defined as specifying the maximum number of channels for the=20 >>>> association. It is not used for negotiating individual=20 >>>> stream/channel IDs. Nor is it used for negotiating the protocol used=20 >>>> on individual streams/channels. >>> [CNG] Doh, you're right.... serves me for not reading that parameter pr= operly. >> This probably belongs to MMUSIC, but I wonder how "specifying the number= of channels" really will work. There is no general channel concept in SCTP= . RTCWEB have their specific definition of a channel, and in CLUE we have o= ur >> (which is identical to the RTCWEB one). But, maybe I want to use DTLS/SC= TP for a protocol X, which doesn't define a channel concept to begin with. > I don't know. This becomes a real problem at a gateway especially decompo= sed one. How do I map SCTP streams (particularly if they relate to multiple= application protocols) received at one side of the gateway to the other? Actually, I think all 3 of us are partly wrong. The number value at the end= of the sctpmap attribute is NOT the number of channels - it's the number o= f incoming streams (which, of course, can be the same). But, never the less, it still doesn't solve the mapping problem. Regards, Christer From christer.holmberg@ericsson.com Thu Feb 6 03:56:16 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D801A00E6 for ; Thu, 6 Feb 2014 03:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq75xgdBkLq8 for ; Thu, 6 Feb 2014 03:56:16 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 81EB51A00E0 for ; Thu, 6 Feb 2014 03:56:15 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-0d-52f3785d14e4 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id E9.1F.04853.D5873F25; Thu, 6 Feb 2014 12:56:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 12:56:13 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 Thread-Index: AQHPIpbUUgnMkzLrwEGl3bw6meJJYZqn69SQ Date: Thu, 6 Feb 2014 11:56:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15F2F1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> <52F2734C.7050000@alum.mit.edu> In-Reply-To: <52F2734C.7050000@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+JvjW5sxecgg1VfTSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjcd8E1oLfIhXbfzxnbmDcINDFyMkhIWAi sX/3VEYIW0ziwr31bF2MXBxCAicYJf5eW8IM4SxilNj8tIOli5GDg03AQqL7nzZIg4iAp8SO j1OYQWxhgSCJafvOskLEgyXuHdjJCGEbSXSe3wQWZxFQkXj+7D6YzSvgK7Hrzj92EFtIYD6z xNb2KhCbU0BH4uaPG2A1jEAHfT+1hgnEZhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwphK0q0 P21ghKjXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbJ4tTi 4tx0IwO93PTcEr3Uoszk4uL8PL3i1E2MwHg5uOW30Q7Gk3vsDzFKc7AoifNeZ60JEhJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cA4zWBbwcNtP29JRL279jJETMNw0rzqV58OpmTJn3c45Pad 5YpeafOVbzea1qUdmb5z34Vgj7Zuvv1/ssys36fKbFJ+3TzlR9VP/kCeIg1RBs1tLhfY5MK/ PV2a+1BcssC/1lTh9GpB9mKhhTOUt/n2lZh1JKyduGLfwljf4xfmGR6/3qaxWmidEktxRqKh FnNRcSIAEwHgkWUCAAA= Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 11:56:16 -0000 Hi, >> My suggestion is to use one bidirectional channel. >> >> I am not even sure how/if rtcweb supports multiple data channels. At=20 >> least the current drafts seem to assume that only one will be used -=20 >> at least per a single SCTP association :) > > Christer - how can you say that? Supporting multiple channels is a major = part of the data channel work in rtcweb and webrtc. I'll correct myself: The sctp-sdp draft currently seems to assume there wil= l be a single channel per SCTP association. > In rtcweb you get multiple channels by sending multiple OPEN messages.=20 > (I don't follow the api work much, but the api for creating a channel can= be called multiple times.) Correct. >>>> "3.2. CLUE Data Channel Definition >>>> >>>> The realization of a bidirectional CLUE Data Channel is a pair of= one >>>> incoming SCTP stream and one outgoing SCTP stream. These streams= are >>>> then used to transport CLUE messages in both directions. >>>> >>>> The SCTP streams MUST belong to the same SCTP association. >>>> >>>> The SCTP streams SHOULD have identical SCTP stream identifier val= ues, >>>> unless a specific value is already used for some other purpose. >>> >>> If it is *possible* that the two stream ids might not be identical, the= n we need a way to determine which ones are paired. >> >> Yes, and there is a discussion (initiated by yourself, with some extra f= uel added by me :) on the RTCWEB list regarding that, so let's see what the= outcome will be. >> >> (Of course, one could use the Data Channel Protocol, and then the=20 >> receiver will see on which stream the messages are received, and=20 >> assume that the stream will be used for whatever protocol is=20 >> indicated. ) > > If you use the data channel protocol, then one end chooses an unused stre= am id and sends the OPEN message. The other end will receive that, necessar= ily on the *same* stream id. (That is how SCTP works.) > > Then the receiver of the OPEN must send an ACK. It must choose some strea= m ID to send that ACK on. And it must choose it in such a way that the othe= r end will know that the ACK correlates to the correct OPEN. Correct. And, there is currently nothing explicit (e.g. a transaction ident= ifier) in the protocol itself for that. > The Webrtc Data Channel Protocol says that one side always uses *even* st= ream IDs to send OPENs, and the other side always uses *odd* stream IDs to = send=20 > OPENs. That already *implies* that the intent is that the paired stream u= se the same ID, but doesn't really require it. Correct. Regards, Christer From christer.holmberg@ericsson.com Thu Feb 6 05:30:38 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E5D1A00F6 for ; Thu, 6 Feb 2014 05:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27oRjPgBgFtf for ; Thu, 6 Feb 2014 05:30:37 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA0B1A00F2 for ; Thu, 6 Feb 2014 05:30:36 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-29-52f38e7b85c3 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 90.97.23809.B7E83F25; Thu, 6 Feb 2014 14:30:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 14:30:35 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: Data Channel: Same stream id value in both directions? Thread-Index: Ac8jPelIPTPiqebLQ5C/rm0nQ3ORAA== Date: Thu, 6 Feb 2014 13:30:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15FECE@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+JvjW513+cgg58fFS32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj5dlC1oJ1zBXX739kbmA8xtTFyMkhIWAi MWH6LmYIW0ziwr31bF2MXBxCAocYJeZNmsUC4SxilHjf+Jaxi5GDg03AQqL7nzZIg4iAp8SO j1PAmoUF7CWO991mgYi7SOztfsMEYetJbGxeCBZnEVCRuPJjDxuIzSvgK/HzSy+YzQi0+Pup NWD1zALiEreezIc6TkBiyZ7zUMeJSrx8/I8VwlaUaH/awAhRryOxYPcnNghbW2LZwtfMEPMF JU7OfMIygVF4FpKxs5C0zELSMgtJywJGllWM7LmJmTnp5UabGIGhfXDLb9UdjHfOiRxilOZg URLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo1v1thydn/9lXmZd4Ff69rL6yjqX 2B/nT+3daVX95MWDvAOW6cumPLuy3zfJ4Nm85pO+n+Q+nhMxYuZli7iaKLySifNTpqTaDqNu lmfMGz8YZfJsUjWxqsv58EJA5WcmzyIrmbZt7R+f+Iud33N8UlqQKevkXWnLtytI33q7Nz0o 8qnZjMIfOkosxRmJhlrMRcWJAErvWJY7AgAA Subject: [clue] Data Channel: Same stream id value in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 13:30:38 -0000 Hi, As you may have seen on the rtcweb list, when the DCP is used, one MUST use= the same stream id values in both directions. That way one can associate t= he ACK with the OPEN. So, if we mandate the same for CLUE (no matter if we use DCP or not), we do= n't need to worry about that. I have also asked whether the data channel core could mandate the same valu= es. Currently it doesn't. Regards, Christer From christer.holmberg@ericsson.com Thu Feb 6 06:28:03 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2E01A012E for ; Thu, 6 Feb 2014 06:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRPGpIs--2uB for ; Thu, 6 Feb 2014 06:28:00 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A910F1A0112 for ; Thu, 6 Feb 2014 06:27:59 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-45-52f39bedb457 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8F.7F.23809.DEB93F25; Thu, 6 Feb 2014 15:27:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 15:27:57 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Data Channel: Does the WebRTC require usage of DCP? Thread-Index: Ac8jR4STmaBDjfXWSJCa9u0XmUzMOA== Date: Thu, 6 Feb 2014 14:27:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D160183@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D160183ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+Jvje672Z+DDH78YbPYf+oyswOjx5Il P5kCGKO4bFJSczLLUov07RK4Mu625xXsla549+oEewPjX/EuRk4OCQETieev/7JD2GISF+6t Z+ti5OIQEjjEKHFgyT1WCGcRo8TNK0cYuxg5ONgELCS6/2mDNIgIKEsc3dzPBmILC9hInFn+ iBWkRETAUeJ9jzVEiZ7E220LwDpZBFQk/s8JBjF5BXwlDr5gAalgBNr6/dQaJhCbWUBc4taT +UwQ1whILNlznhnCFpV4+fgfK4StKNH+tIERoj5fYsqqz2A2r4CgxMmZT1gmMArNQjJqFpKy WUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG9tzEzJz0cqNNjMBwP7jlt+oOxjvn RA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBceKfLV6Ka00/K2+Y4n/E 9WKhP8vDl64r739ruJ6ds5p7pc4kVVPBorVb/kq/tI1f1VPnszS5RidJa3+vxQvGGNO7bppb 7RWCNood4Yl2KhEv6BX9EvXKsifoy4nDk95fe8b9qPb2n1mftRNi14t+ClzquNxkr4TCvd9/ M4WUVRd26W4TiN89WYmlOCPRUIu5qDgRADajibtFAgAA Subject: [clue] Data Channel: Does the WebRTC require usage of DCP? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 14:28:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D160183ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As has been clarified, the usage of the DCP is optional when using the RTCW= EB data channel. Now, based on some discussions with my WebRTC API expert, it seems like the= only thing that can trigger a JavaScript "open" event is the DCP OPEN- and= ACK messages. However, my understanding is that the demo we saw during the virtual interi= m did NOT use DCP, which would mean that it IS possible for a JS App to use= the data channel without DCP? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D160183ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As has been clarified, the usage of the DCP is optio= nal when using the RTCWEB data channel.

 

Now, based on some discussions with my WebRTC API ex= pert, it seems like the only thing that can trigger a JavaScript “ope= n” event is the DCP OPEN- and ACK messages.

 

However, my understanding is that the demo we saw du= ring the virtual interim did NOT use DCP, which would mean that it IS possi= ble for a JS App to use the data channel without DCP?

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D160183ESESSMB209erics_-- From pkyzivat@alum.mit.edu Thu Feb 6 07:19:54 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7118F1A01F0 for ; Thu, 6 Feb 2014 07:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_17=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO8rPgvB3s-C for ; Thu, 6 Feb 2014 07:19:51 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 5D64C1A0143 for ; Thu, 6 Feb 2014 07:19:51 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA11.westchester.pa.mail.comcast.net with comcast id P0Fe1n0011uE5Es5B3Kq8m; Thu, 06 Feb 2014 15:19:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id P3Kq1n0043ZTu2S3c3KqRB; Thu, 06 Feb 2014 15:19:50 +0000 Message-ID: <52F3A815.3080104@alum.mit.edu> Date: Thu, 06 Feb 2014 10:19:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> <52F2734C.7050000@alum.mit.edu> <52F2D1B0.8000007@nteczone.com> <52F31BE0.2070201@alum.mit.edu> <52F32A95.6060905@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15EDEF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15EDEF@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=1391699990; bh=mFmmX0bu34Ju+hqn1GQcm32p4oO+LSvj6A8kUk6DJUc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HSE5cqcF++bDIuypcu67AMmV9Zf0AEWue5WulJ0Lqp9luFr03b1THvlOT3AYN3W53 DIPjNFw+j4ac9RpD0/xi2FKsGc7mO/oIgYMtwfFgAXTlheZ0n+N+N3odkAm7Yl+aXa duPZaPO3+usJCYHS4qpgfp30bsZtsG3d9IsqUqQKJWDO4En6tjLGatSMnfXKAKd72B l3/ZF/Ea7e+VKsS7nXpd4YKEvecSGdd9SatuZyAwv4poS6n0S30wb9f/lMmqW5dQAR 2XzuTjSKMbyvvSjpBPooF6LBCfbClqt/JiQrX3WRwQOgass7l15wBIZlfCVb0LqW3Q /xz757pAAHMIg== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 15:19:54 -0000 On 2/6/14 3:48 AM, Christer Holmberg wrote: > Hi, > >>>> Alice: >>>> m=application UDP-A DTLS/SCTP SCTP-A >>>> c=IN IP4 IP-A >>>> a=sctpmap:SCTP-A webrtc-datachannel 16 >>>> a=sctpmap:SCTP-A CLUE 17 >>>> >>>> Bob: >>>> m=application UDP-B DTLS/SCTP SCTP-B >>>> c=IN IP4 IP-B >>>> a=sctpmap:SCTP-B webrtc-datachannel 16 >>>> a=sctpmap:SCTP-B CLUE 18 >>>> >>>> By labeling the channel CLUE and the fact there is only one CLUE >>>> channel per association you are tying together the send and receive channels. >>> >>> You have just redefined what the last parameter on a=sctpmap is for. >>> It is defined as specifying the maximum number of channels for the >>> association. It is not used for negotiating individual stream/channel >>> IDs. Nor is it used for negotiating the protocol used on individual >>> streams/channels. >> [CNG] Doh, you're right.... serves me for not reading that parameter properly. > > This probably belongs to MMUSIC, but I wonder how "specifying the number of channels" really will work. There is no general channel concept in SCTP. RTCWEB have their specific definition of a channel, and in CLUE we have our (which is identical to the RTCWEB one). But, maybe I want to use DTLS/SCTP for a protocol X, which doesn't define a channel concept to begin with. I think it is really the max number of stream ids. I don't know how it relates to incoming streams vs outgoing streams, but since a channel requires one of each, it probably works out. Thanks, Paul From christer.holmberg@ericsson.com Thu Feb 6 07:30:53 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B991A01B6 for ; Thu, 6 Feb 2014 07:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfMi6hLtUKRi for ; Thu, 6 Feb 2014 07:30:52 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CC1981A0186 for ; Thu, 6 Feb 2014 07:30:51 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-86-52f3aaaa6796 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 87.47.23809.AAAA3F25; Thu, 6 Feb 2014 16:30:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 16:30:49 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 Thread-Index: AQHPI07lpfmhfQ5ukUKIoElLt4MuLpqoWflR Date: Thu, 6 Feb 2014 15:30:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D160382@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> <52F2734C.7050000@alum.mit.edu> <52F2D1B0.8000007@nteczone.com> <52F31BE0.2070201@alum.mit.edu> <52F32A95.6060905@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15EDEF@ESESSMB209.ericsson.se>, <52F3A815.3080104@alum.mit.edu> In-Reply-To: <52F3A815.3080104@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje6qVZ+DDA71CVnsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldG98TZrAVzWCre75rL3MC4hLmLkYNDQsBE 4s0D5S5GTiBTTOLCvfVsXYxcHEIChxglzu59zQThLGKUuPNsGiNIA5uAhUT3P22QBhEBT4kd H6cwg9jCAkES876uYoKIB0s8bPrCBmEbSbx62wlWwyKgIrF91w0WEJtXwFfi+fTPrBDzn7JI PO9qACviFNCRmP1iD1gRI9BF30+tARvKLCAucevJfCaISwUkluw5zwxhi0q8fPyPFeIZRYnl /XIQ5ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExhFZyGZOgtJyywkLbOQtCxgZFnFyJ6bmJmT Xm60iREYCQe3/FbdwXjnnMghRmkOFiVx3g9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MPIzzYq/4/K3o7Xn3qpH0uxSE85OYzNdcXn+yx1rvinc/6tsHPDZKpcxjLfaL6ZoQ+YpYUO/ muMis679/r1wc6VDZNOi13Lyrz6aq+1frD7nVPLSj0dPPS2VLewSOH68/MPOireN3HvLp258 qWxgY1/cvn332Q9i09br/eI6KXfg/qk3F2Ryt3kpsRRnJBpqMRcVJwIAEh07l1ICAAA= Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 15:30:53 -0000 Hi, >> This probably belongs to MMUSIC, but I wonder how "specifying the number= of channels" really will work. There is no general >> channel concept in SCTP. RTCWEB have their specific definition of a chan= nel, and in CLUE we have our (which is identical to the RTCWEB one).=20 >> But, maybe I want to use DTLS/SCTP for a protocol X, which doesn't defin= e a channel concept to begin with. > > I think it is really the max number of stream ids. Yes, it is (I think I sent another e-mail on that :) Regards, Christer From pkyzivat@alum.mit.edu Thu Feb 6 07:36:23 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5379B1A018E for ; Thu, 6 Feb 2014 07:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luoxUkzIzh9q for ; Thu, 6 Feb 2014 07:36:22 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 00EA21A013D for ; Thu, 6 Feb 2014 07:36:21 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA11.westchester.pa.mail.comcast.net with comcast id P0Wk1n0021swQuc5B3cL18; Thu, 06 Feb 2014 15:36:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id P3cL1n00f3ZTu2S3b3cLwX; Thu, 06 Feb 2014 15:36:20 +0000 Message-ID: <52F3ABF4.7040601@alum.mit.edu> Date: Thu, 06 Feb 2014 10:36:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D153633@ESESSMB209.ericsson.se> <52F0362C.1070500@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1580ED@ESESSMB209.ericsson.se> <52F19B94.5040306@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15BB42@ESESSMB209.ericsson.se> <52F25928.40404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D15C665@ESESSMB209.ericsson.se> <52F2734C.7050000@alum.mit.edu> <52F2D1B0.8000007@nteczone.com> <52F31BE0.2070201@alum.mit.edu> <52F32A95.6060905@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15EDEF@ESESSMB209.ericsson.se> <52F35CA7.8090007@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D15F0DA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15F0DA@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=1391700980; bh=6QdmFWbGgAYx5bKDxNiIAIOHw1nRn5LoMgVWiLMjXi0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DJVVCF7+cU4t3bljZNTC8gE7Cw82V2WWVzdvJSrXpXpHjxAZjqGAU/EZ0GqJmhgSP qeUCDCsMIcoetBnp6zYskcb3HwdZMieUds7ZcXrfnK8ptCyix7ytx5G7Kq63sYTUXq eIJFD5HtZvkJ5Oih2L6fHw/Lr70mR+1Ps5YuFO19Y4W8xE3d3fO+jW9KChP03XOffX ujtKd8MKKWLRfsULE44mDWcR5e2Bcqoi/gYvFN9MHoAvvs7wfHdwUICk3bbwhvLRpE i9NEPdk7JKv6sR/Wi3Skbxr8SSoD5llXH82GUIDFP7Wpjo8xEVJMFmeiwIHn+vi+O8 U/JLOwF1nUpDA== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 15:36:23 -0000 On 2/6/14 5:48 AM, Christer Holmberg wrote: > Actually, I think all 3 of us are partly wrong. The number value at the end of the sctpmap attribute is NOT the number of channels - it's the number of incoming streams (which, of course, can be the same). > > But, never the less, it still doesn't solve the mapping problem. Did you see my reply to myself on rtcweb? There really is text in the rtcweb-protocol draft that says the ACK goes on the same stream ID as the OPEN. (I finally found it.) Thanks, Paul From christer.holmberg@ericsson.com Thu Feb 6 07:57:58 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B891A015B for ; Thu, 6 Feb 2014 07:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkQGWwUSafUT for ; Thu, 6 Feb 2014 07:57:57 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5F51A0143 for ; Thu, 6 Feb 2014 07:57:57 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-e7-52f3b103f9ff Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 38.FD.04853.301B3F25; Thu, 6 Feb 2014 16:57:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 16:57:51 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 Thread-Index: AQHPI1QvMnYZa+eGYE+FYKi5AW7ZSQ== Date: Thu, 6 Feb 2014 15:57:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D160407@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+JvjS7zxs9BBt8m6ljsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGo2V72As6WCuuv1zO2sD4lbmLkZNDQsBE Ylv3cSYIW0ziwr31bF2MXBxCAicYJa4/6mOEcBYxShydfBKog4ODTcBCovufNkiDiICnxI6P U8AGCQsESUzbd5YVIh4sce/ATkYIW09iwv8OMJtFQEVi2em77CA2r4CvxO4J91lAbEagxd9P rQE7gllAXOLWk/lQBwlILNlzHupQUYmXj/+xgpwgIaAosbxfDqJcR2LB7k9sELa2xLKFr5kh xgtKnJz5hGUCo/AsJFNnIWmZhaRlFpKWBYwsqxgli1OLi3PTjQz0ctNzS/RSizKTi4vz8/SK UzcxAoP/4JbfRjsYT+6xP8QozcGiJM57nbUmSEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMj Y1xmhkuQ8LKjco8dv29cUBJ411r1iLd8zazrL8KA8WDfaFJjF71LaM0bL5ZHoZfPP5JQc7l4 YNLL2kd6LvIHnD16jizxSPZQUqxbNKWU0fruCdezDLknT9h/OfJzt1C95COX46LTjy0VZDka YP+BaXXa9md6oTaT1KzKsiaov5g8Ly9JyEyJpTgj0VCLuag4EQA4J+ArTAIAAA== Subject: Re: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 15:57:59 -0000 Hi, >> Actually, I think all 3 of us are partly wrong. The number value at the = end of the sctpmap attribute is NOT the number of channels - it's the numbe= r of incoming streams (which, of course, can be the same). >> >> But, never the less, it still doesn't solve the mapping problem. > > Did you see my reply to myself on rtcweb? There really is text in the > rtcweb-protocol draft that says the ACK goes on the same stream ID as > the OPEN. (I finally found it.) Yes - and I also indicated that in an e-mail to the CLUE list :) However, the data channel spec still allows different stream id values. Regards, Christer= From pkyzivat@alum.mit.edu Thu Feb 6 08:04:08 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657A91A01B7 for ; Thu, 6 Feb 2014 08:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17CaSVl0KuMQ for ; Thu, 6 Feb 2014 08:04:07 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF911A0143 for ; Thu, 6 Feb 2014 08:04:07 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta05.westchester.pa.mail.comcast.net with comcast id P1it1n0060Fqzac55446CG; Thu, 06 Feb 2014 16:04:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id P4461n0023ZTu2S3U4460T; Thu, 06 Feb 2014 16:04:06 +0000 Message-ID: <52F3B275.4020508@alum.mit.edu> Date: Thu, 06 Feb 2014 11:04:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D15FECE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15FECE@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=1391702646; bh=7NeYymMhu5qgpgDOAwvBoqomz7Op790MIzmGqlYlJI8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=M0tvgUe1pKY4YBTVifu9EGdz2zgbrtJgheAvOeUcNoASTYH7sFNQ5nVhTZtt+cNnU dbJEN4PS6SdHzOyFyGRTlOmPs0ODF/KbcNCxAuxVFvgY7jxHLqKXAV3tHfCmFf4CHc XbJ+zh5lOY+rvxS5RkGw8Uin+K/bRMASU4U1SYwnUm08+ToQXTvdckdDzwUwKTvY7B 0Pe78hlmg0Rp8sqxTR2j/tEc7WMqVXLS6yabYCfVxGJXi36Gxhnza3dXN+D69fATAm xySIL7ohCkVZLVS5bffWlMe4v03KRvrvvTFanbw30KgdkTmHvdnWyLxCaZPSNslBS8 fCAIOSjau8ydg== Subject: Re: [clue] Data Channel: Same stream id value in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 16:04:08 -0000 On 2/6/14 8:30 AM, Christer Holmberg wrote: > Hi, > > As you may have seen on the rtcweb list, when the DCP is used, one MUST use the same stream id values in both directions. That way one can associate the ACK with the OPEN. > > So, if we mandate the same for CLUE (no matter if we use DCP or not), we don't need to worry about that. > > I have also asked whether the data channel core could mandate the same values. Currently it doesn't. Yes, it *could*. I don't know why it doesn't now. In principle we could define an SDP O/A procedure that negotiates pairs of stream ids for channels the same way you negotiate pairs of addr/port for RTP sessions. If one did that, then there could be independent stream IDs for the two directions of the channel. But what is currently proposed is draft-ejzak-dispatch-webrtc-data-channel-sdpneg which requires the same stream ID for both directions. Thanks, Paul From pkyzivat@alum.mit.edu Thu Feb 6 08:09:44 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC091A0193 for ; Thu, 6 Feb 2014 08:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3VsSM2P7kMG for ; Thu, 6 Feb 2014 08:09:43 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 46CE21A01FA for ; Thu, 6 Feb 2014 08:09:43 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA11.westchester.pa.mail.comcast.net with comcast id P1u11n0040EZKEL5B49ire; Thu, 06 Feb 2014 16:09:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id P49h1n00n3ZTu2S3M49iKr; Thu, 06 Feb 2014 16:09:42 +0000 Message-ID: <52F3B3C5.4040407@alum.mit.edu> Date: Thu, 06 Feb 2014 11:09:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D160183@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D160183@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391702982; bh=XWiX2TqEtFPDO51oBc6thriXQgiHdSoAmwOQP7tV7TA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fsQJyfkFV4RQ4ymP9krMe2vPaiM/3A+qCvfkAzdbgbI9gPAd0n0YYIrtZjOjtote8 CE08yc1CbJZOH+wVq5UXACthc6jPUKKHx1qFxqtDXkVQhfqHdOGDDNrzRbZtP7XRxw TeE44sV2ymQ7g2Akv2IP2TXYHVSU+wmSV/xllQPiLD0vh3S7MzkNF98WwnGzZgh5Vg KvFPqM4XtxU+2aSHCmn9ksBSJltI9302RxM41/GEKWfAMgOPFYDljF3+XZJs5pTxTt ukboOdYwlzMEMkWEAoBvbY1LHlXnvvtW6uO5mJMGuL+tQbmE0PAGwN82/S5K2IvxMD S0DXXwQKSv58Q== Subject: Re: [clue] Data Channel: Does the WebRTC require usage of DCP? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 16:09:44 -0000 On 2/6/14 9:27 AM, Christer Holmberg wrote: > Hi, > > As has been clarified, the usage of the DCP is optional when using the > RTCWEB data channel. > > Now, based on some discussions with my WebRTC API expert, it seems like > the only thing that can trigger a JavaScript “open” event is the DCP > OPEN- and ACK messages. > > However, my understanding is that the demo we saw during the virtual > interim did NOT use DCP, which would mean that it IS possible for a JS > App to use the data channel without DCP? I don't know a lot about this, but it is my understanding that this is possible. I think it is a matter of "creating" the channel, with a specific stream ID, without doing an OPEN. I think this must be done on both ends before messages are sent. If one were to use the ejzak draft's sdp to negotiate the channel then this is what you would do. Thanks, Paul From christer.holmberg@ericsson.com Thu Feb 6 08:27:44 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD071A03CB for ; Thu, 6 Feb 2014 08:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqkrYXQcI9Gl for ; Thu, 6 Feb 2014 08:27:43 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id E81D81A03C5 for ; Thu, 6 Feb 2014 08:27:42 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-d3-52f3b7fd40d4 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id AC.D0.04853.DF7B3F25; Thu, 6 Feb 2014 17:27:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 17:27:40 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: Data Channel: Same stream id value in both directions? Thread-Index: Ac8jPelIPTPiqebLQ5C/rm0nQ3ORAAADsQSAAALMS00= Date: Thu, 6 Feb 2014 16:27:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1604BE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15FECE@ESESSMB209.ericsson.se>, <52F3B275.4020508@alum.mit.edu> In-Reply-To: <52F3B275.4020508@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvje7f7Z+DDC7PkbTYf+oys8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6MKa2b2Qrus1bcmH2FrYFxE0sXIyeHhICJ xPaPHVC2mMSFe+vZuhi5OIQETjBKvJjYxA7hLGKUuLxsBWsXIwcHm4CFRPc/bZAGEQFPiR0f pzCD2MICzhI/7vcyQ8RdJPZ2v2GCsK0kzj5exAhiswioSKya2MwOYvMK+Ep8vb8JzBYSyJWY /LAfrJ5TQEdi27QdYDYj0EHfT60Bs5kFxCVuPZnPBHGogMSSPeeZIWxRiZeP/4GdJiGgKLG8 Xw6iXEdiwe5PbBC2tsSyha+ZIdYKSpyc+YRlAqPoLCRTZyFpmYWkZRaSlgWMLKsYJYtTi4tz 040M9HLTc0v0Uosyk4uL8/P0ilM3MQKj5eCW30Y7GE/usT/EKM3BoiTOe521JkhIID2xJDU7 NbUgtSi+qDQntfgQIxMHpxQwDor2RfGf33FW+Z5qwOmEBb3n2RTt3CSs736/kiVwet2dSbMC pzyJOiKx3G1Jr/GTqr9eEVfMf32O3aCj+stSmfVqftyMZPezvnrbe7Q9Yjtba589YGo0LnBh LWV8xNqx9UNpK0uG/o6y7HZFlnw31z2rzaauis2Ua/K8qr47xCGhn6npaYYSS3FGoqEWc1Fx IgAAhozBZAIAAA== Subject: Re: [clue] Data Channel: Same stream id value in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 16:27:44 -0000 Hi, >> As you may have seen on the rtcweb list, when the DCP is used, one MUST = use the same stream id values in both directions. That way one can associat= e the ACK with the OPEN. >> >> So, if we mandate the same for CLUE (no matter if we use DCP or not), we= don't need to worry about that. >> >> I have also asked whether the data channel core could mandate the same v= alues. Currently it doesn't. > > Yes, it *could*. I don't know why it doesn't now. I really think it should. Then people would not have to depend on other pro= tocols (DCP, O/A, whatever). The only reason why someone would want to use different values is because a= given value is already taken on one side. Regards, Christer From Mark.Duckworth@polycom.com Thu Feb 6 08:55:58 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1D1A03DC for ; Thu, 6 Feb 2014 08:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0GyHRzb16wv for ; Thu, 6 Feb 2014 08:55:54 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id E718E1A03CF for ; Thu, 6 Feb 2014 08:55:53 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 6 Feb 2014 08:55:52 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Thu, 6 Feb 2014 08:55:50 -0800 Thread-Topic: [clue] Maxcaptures in MCC Thread-Index: Ac8jXEpaG1Tvk1z8S1y3whZ+M3icKg== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB14E@CRPMBOXPRD07.polycom.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] Maxcaptures in MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 16:55:58 -0000 Hi Christian, I think I understand the general idea you are getting at, but I don't under= stand specifically what you are proposing as an improvement. More comments inline. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Wednesday, February 05, 2014 7:20 PM > To: clue@ietf.org > Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't descr= ibe > video locations within composed MCC >=20 > Hello Paul and Mark, >=20 > The Max-captures attributes currently indicates the maximum number of > captures that appears in a MCC at any particular point in time. >=20 > i.e. MCC(VC1,VC2,VC3),MaxCaptures=3D3 > So a Consumer has to assume because this is a maximum that VC1, VC2, VC3, > (VC1,VC2), (VC1,VC3), (VC2,VC3) or (VC1,VC2,VC3) can appear at any point = in > time. [Duckworth, Mark] I agree, that is consistent with framework-13. > However the Consumer only ever sends a composition of (VC1,VC2,VC3). It i= s > never going to change that combination.=20 [Duckworth, Mark] Do you mean the Provider will always send a composition o= f (VC1,VC2,VC3)? And the provider would like to be more explicit about thi= s in the advertisement? > It seems to me that in this case > using MaxCaptures as it is currently defined is semantically incorrect. [Duckworth, Mark] I think it is correct, but maybe not giving as much infor= mation as the provider wants to express. > So what I am suggesting is simply to add a way to correctly indicate this > "constant number of captures" case, i.e. (VC1,VC2,VC3). [Duckworth, Mark] If I understand your suggestion correctly, then one way t= o do that would be to add a new optional MinCaptures attribute to an MCC. = MinCaptures is the minimum number of constituent captures that may appear i= n the MCC at a time. If this attribute is not set, then it is assumed to h= ave the default value of 1. For this scenario, the value of both MinCaptur= es and MaxCaptures would be 3. Is this what you are suggesting, or do you = have something else in mind? =20 > I think Paul is questioning the attribute in general. I do believe that k= nowing > the number of sources may be beneficial for a consumer in deciding which > MCC/Captures to select. There may be tradeoffs vs a MCC only showing a > limited number (i.e. one source) at a time vs another MCC showing multipl= e > sources at a time. >=20 > Regards, Christian From pkyzivat@alum.mit.edu Thu Feb 6 08:59:17 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A401A013C for ; Thu, 6 Feb 2014 08:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsqHzSxBIKhu for ; Thu, 6 Feb 2014 08:59:13 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id F21FD1A00F4 for ; Thu, 6 Feb 2014 08:59:12 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta15.westchester.pa.mail.comcast.net with comcast id P2J41n00316LCl05F4zB47; Thu, 06 Feb 2014 16:59:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id P4zB1n00V3ZTu2S3S4zBeZ; Thu, 06 Feb 2014 16:59:11 +0000 Message-ID: <52F3BF5F.1050509@alum.mit.edu> Date: Thu, 06 Feb 2014 11:59:11 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> <52CB8BB9.70503@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E3E6@CRPMBOXPRD07.polycom.com> <52CF5885.2090002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4FF@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF15FFC@CRPMBOXPRD07.polycom.com> <52DC8BC8.7000204@nteczone.com> <52DD6047.4030101@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16388@CRPMBOXPRD07.polycom.com> <52DDAAF7.9020506@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF1646F@CRPMBOXPRD07.polycom.com> <52DF051B.5040809@nteczone.com> <52E00EE7.3020205@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D01E6DF@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D0F8123@CRPMBOXPRD07.polycom.com> <52E837F9.2090201@nteczone.com> <52F293FC.5080502@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FAF30@CRPMBOXPRD07.polycom.com> <52F2D518.4070801@nteczone.com> In-Reply-To: <52F2D518.4070801@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=1391705951; bh=nwia+rLl1PyrkdaGWzD7dRk64gx7PDPOk64bKDRIZr4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NkeMVuGTGJyz+I/5VDaAgbO/aH9x/lmlDXI5qNVu1FrG7v02JZHJBhNFhp1P3kTVM rT/ytsXn5zBku3eA9c9oQCIa3+CFelNgP3DB656Y5/+oY/4JdkQ5AksGbrUfOpDDzr rzUr0lkmHCpemF+NNJko1n4HL2H8OWYeTyqLhpjX9l8eHo3WVQ+2+cTRMkOTkRhx53 VNNB4jC71Z7JPtsdSQmw+1uL9uTs/sM/3506W3eqM0L7CCo0Bd+8W+bHcf6O+4LMQI XB+cnqEULZuF+sLubGC8owI4QCMzA0On3qbXob19ho+JvNLBR0g5f+0ow1PkPNtub3 9bycs676oRwlA== Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't describe video locations within composed MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 16:59:17 -0000 On 2/5/14 7:19 PM, Christian Groves wrote: > Hello Paul and Mark, > > The Max-captures attributes currently indicates the maximum number of > captures that appears in a MCC at any particular point in time. > > i.e. MCC(VC1,VC2,VC3),MaxCaptures=3 > So a Consumer has to assume because this is a maximum that VC1, VC2, > VC3, (VC1,VC2), (VC1,VC3), (VC2,VC3) > or (VC1,VC2,VC3) can appear at any point in time. > > However the Consumer only ever sends a composition of (VC1,VC2,VC3). It > is never going to change that combination. It seems to me that in this > case using MaxCaptures as it is currently defined is semantically > incorrect. > > So what I am suggesting is simply to add a way to correctly indicate > this "constant number of captures" case, i.e. (VC1,VC2,VC3). So what would happen if the advertisement was: MCC(VC1,VC2,VC3),NumCaptures=3 but the Configure requested MCC(V1,V2)? Since there are now only two captures to send, the NumCaptures is violated. Also, what if the intent is to compose three captures from the currently most active site, but not all the sites have three sources. Then again, sometimes there will less than three captures composed. I was thinking that the point of MaxCaptures vs. NumCaptures was to cover those sorts of cases. > I think Paul is questioning the attribute in general. I do believe that > knowing the number of sources may be beneficial for a consumer in > deciding which MCC/Captures to select. There may be tradeoffs vs a MCC > only showing a limited number (i.e. one source) at a time vs another MCC > showing multiple sources at a time. Originally I thought the intent was that MaxCaptures would replace the "switched" and "composed" attributes. It could approximate those: - if maxcaptures = 1 and #sources > 1 then "switched" - if maxcaptures = #sources and #sources > 1 then "composed". In other cases, comparing MaxCaptures to the #sources can make it clear that something else is going on. But I think it is insufficient to understand *what* is going on in sufficient detail to make much of a judgement about which to choose. I suspect that either this wouldn't be used, or it would be used together with some extra "knowledge" about how the advertiser does things. That would be bad for interoperability. ISTM that the "switched" and "composed" attributes will provide as much as we can reasonably promise in an interoperable way. If we want to do more in the future, we could consider doing detailed layouts. But I don't want to do that now. Thanks, Paul > Regards, Christian > > > > On 6/02/2014 9:21 AM, Duckworth, Mark wrote: >> I too am confused about Christian's suggestion for changing or >> clarifying the maxcaptures attribute. >> Christian, can you explain again please? >> For now, I think I agree with Paul that there is no reason to change >> the current description of maxcaptures. >> >> Mark >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: Wednesday, February 05, 2014 2:42 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't >>> describe >>> video locations within composed MCC >>> >>> On 1/28/14 6:06 PM, Christian Groves wrote: >>>> Hello Mark, >>>> >>>> I was simply replying to Paul. I wasn't seeking to over turn any >>>> decision on spatial parameters (not that I was aware of the outcome of >>>> the meeting). >>>> >>>> An issue was brought up several times about the maxcaptures parameter >>>> meaning any number of sources up to a value and that this caused >>>> uncertainty to the consumer. This parameter is independent of any >>>> spatial parameters thus my reply to Paul. I was suggesting a >>>> modification by apply this parameter to say "=" in addition to "<=" to >>>> this to solve that problem. If the Advertiser is only going to send a >>>> MCC with a fixed number of captures then it seems to me that its >>>> semantically incorrect t =o imply less may be sent. >>> I'm still not entirely clear what this means. >>> >>> IIUC, the intent is that if the MCC has N sources, and maxcaptures (or >>> number-of-captures) is M, then: >>> - if N>1 and M=1 then this is a "switched" capture >>> - if N>1 and M=N then this is a "composed" capture >>> >>> But - that doesn't say anything about 1>> the >>> cases where there are combinations of switching and composition. And of >>> course it also doesn't deal with composition where some images are >>> smaller >>> than others, and overlapping that hides parts of some captures. >>> It also doesn't deal with what will happen if the Configure selects a >>> subset of >>> the sources in the MCC. >>> >>> I see no way to deal with that with a single number. And I don't see any >>> compelling reason to do so. >>> >>> The "switched" and "composed" attributes cover the two extremes, and >>> also >>> indicate (when both or neither are specified) that the situation is >>> something >>> other than one of the extremes. Does having a number improve on that? >>> >>> Thanks, >>> Paul >>> >>>> Regards, Christian >>>> >>>> On 29/01/2014 4:20 AM, Duckworth, Mark wrote: >>>>> Mary and Paul, could you please let us know if consensus is reached >>>>> on this topic? >>>>> >>>>> At the interim meeting Jan 27, we reaffirmed the decision noted in >>>>> Ticket #5 , meaning the >>>>> group does not want to attempt to use CLUE to describe composed >>>>> captures, particularly the layout of individual video images within a >>>>> composed image. >>>>> >>>>> I think Christian is still opposed to this outcome from the interim >>>>> meeting. >>>>> >>>>> Regards, >>>>> >>>>> Mark >>>>> >>>>> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, >>>>> Mark >>>>> *Sent:* Wednesday, January 22, 2014 7:16 PM >>>>> *To:* Paul Kyzivat; clue@ietf.org >>>>> *Subject:* Re: [clue] spatial information can't describe video >>>>> locations within composed MCC >>>>> >>>>> Hi Paul, >>>>> >>>>> Paul wrote: "Lets first discuss if having this information would >>>>> provide significant value. If so then we can discuss how to provide >>>>> it." >>>>> >>>>> Yes, but we already did that, and decided it isn't valuable enough to >>>>> work on as part of CLUE. This was Ticket #5 >>>>> . I think we should >>>>> stick with that decision. >>>>> >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>> Sent: Wednesday, January 22, 2014 1:33 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] spatial information can't describe video >>>>> locations within >>>>> >>>>>> composed MCC >>>>>> On 1/21/14 6:39 PM, Christian Groves wrote: >>>>>>> Hello Mark, >>>>>>> I think I know where the disconnect is between us. Its to do with >>>>>>> the >>>>>>> encodings. In my examples I've been assumed that Provider only >>>>>>> provides the encoding for MCC1 not the constituent captures. >>>>>>> Whereas >>>>>>> you've been assuming that encodings are being provided for the >>>>>>> individual and MCC captures. >>>>>>> In the case of the encoding only being on the MCC the consumer >>>>>>> knows >>>>>>> because the VCs and MCC belong to the same Capture Scene. The >>>>>>> Advertiser has provided the spatial positions of VC1 being left. >>>>>>> VC2 >>>>>>> being centre and VC3 being right. That is their position in the >>>>> composition. >>>>> >>>>>> That at best seems like a hack. It is repurposing the spatial info >>>>> of the >>>>> >>>>>> captures without encodings for an entirely different purpose. >>>>>> And it doesn't work right if you want to have multiple MCCs that >>>>> compose >>>>> >>>>>> the same sources differently. (Unless you introduce another layer >>>>>> of >>>>>> indirection, such as you do in example below. Yet another hack.) >>>>>>> In the case of multiple encodings the spatial information >>>>>>> associated >>>>>>> with an individual capture is likely to be a difference between >>>>>>> the >>>>>>> individual encodings and the MCC encoding. >>>>>>> So perhaps the way to address this is to allow spatial >>>>>>> information in >>>>>>> individual encodings in MCCs only when those individual encodings >>>>>>> are >>>>>> MCCs? >>>>>>> E.g. taking your example below. >>>>>>> Scene 1 >>>>>>> VC1 - left >>>>>>> VC2 - center >>>>>>> VC3 - right >>>>>>> MCC2(VC1) - left-composed >>>>>>> MCC3(VC2) - center-composed >>>>>>> MCC4(VC3) - right-composed >>>>>>> MCC1 (MCC2,MCC3,MCC4) - whole scene, maxCaptures=3 >>>>>>> CSE1 (VC1, VC2, VC3) >>>>>>> CSE2 (MCC1) >>>>>> In effect what you have now done is introduce an explicit encoding >>>>> for the >>>>> >>>>>> positions of the sources of a composition. (But used an obscure and >>>>>> confusing notation.) >>>>>> If we really want that, then I suggest we just add syntax to the >>>>> declaration of >>>>> >>>>>> the MCC to explicitly do it. >>>>>> But I don't really see the point of doing so. What can the consumer >>>>> do when >>>>> >>>>>> it has this info that it wouldn't be able to do without it? >>>>>>> In order to address the maxCaptures issue perhaps we need to >>>>>>> modify >>>>>>> "MaxCaptures" slightly so that it becomes "NumberofCaptures" >>>>>>> where we >>>>>>> could say NumberofCaptures=3 or NumberofCaptures<=3. This would >>>>>>> give >>>>>>> more certainty to the Consumer about what will actually be sent. >>>>>> That is just another step towards describing the complete layout of >>>>>> the >>>>>> composition. >>>>>> Lets first discuss if having this information would provide >>>>> significant value. If >>>>> >>>>>> so then we can discuss how to provide it. >>>>>> Thanks, >>>>>> Paul >>>>>>> Regards, Christian >>>>>>> On 21/01/2014 11:54 PM, Duckworth, Mark wrote: >>>>>>>> Hello Christian, >>>>>>>> I still don't see how the consumer can tell anything about how >>>>>>>> an >>>>> MCC >>>>> >>>>>>>> is composed. Take this example, >>>>>>>> Scene 1 >>>>>>>> VC1 - left >>>>>>>> VC2 - center >>>>>>>> VC3 - right >>>>>>>> MCC1 (VC1, VC2, VC3) - whole scene, maxCaptures=3 >>>>>>>> CSE1 (VC1, VC2, VC3) >>>>>>>> CSE2 (MCC1) >>>>>>>> Here it is useful to give spatial information for all the >>>>>>>> captures, >>>>>>>> so the consumer that chooses the individual captures knows they >>>>>>>> are >>>>>>>> spatially related. But how is the consumer supposed to know how >>>>>>>> the >>>>>>>> provider is composing them inside MCC1? It could be any number >>>>>>>> of >>>>>>>> ways, and it could be changing over time. So my cases 2 and 3 >>>>>>>> below >>>>>>>> apply to why the consumer can't tell how the MCC is composed. >>>>>>>> Yet it >>>>>>>> still makes sense for the provider to give spatial information >>>>>>>> for >>>>>>>> the captures themselves. >>>>>>>> Mark >>>>>>>>> -----Original Message----- >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>> Christian >>>>>>>>> Groves >>>>>>>>> Sent: Monday, January 20, 2014 6:02 PM >>>>>>>>> To: clue@ietf.org >>>>>>>>> Subject: Re: [clue] spatial information can't describe video >>>>>>>>> locations within composed MCC >>>>>>>>> Hello Mark and Paul, >>>>>>>>> Please see my responses below. >>>>>>>>> Regards, Christian >>>>>>>>> On 21/01/2014 8:29 AM, Duckworth, Mark wrote: >>>>>>>>>> Christian, >>>>>>>>>> I agree with Paul. >>>>>>>>>> Christian wrote: "I cannot see why in the static case spatial >>>>>>>>>> information isn't >>>>>>>>> valid? In the static case the concerns of 2, 3 and 4 don't apply." >>>>>>>>>> That might be true, but how is the consumer going to know if >>>>>>>>>> it is >>>>>>>>>> the "static >>>>>>>>> case" or not? I don't see any way for the consumer to know this. >>>>>>>>> [CNG] The consumer knows this because the Provider only >>>>>>>>> provides >>>>> the >>>>> >>>>>>>>> spatial information when it makes sense to do so. >>>>>>>>>> Mark >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>>>>>>>> Kyzivat >>>>>>>>>>> Sent: Monday, January 20, 2014 12:44 PM >>>>>>>>>>> To: clue@ietf.org >>>>>>>>>>> Subject: Re: [clue] spatial information can't describe video >>>>>>>>>>> locations within composed MCC >>>>>>>>>>> On 1/19/14 9:36 PM, Christian Groves wrote: >>>>>>>>>>>> Hello Mark, >>>>>>>>>>>> Sorry for the delayed response. I was on vacation last week. >>>>>>>>>>>> I >>>>>>>>>>>> see there's been quite a lot of activity over the last week >>>>>>>>>>>> with >>>>>>>>>>>> respect to MCCs and the framework. >>>>>>>>>>>> I saw the minutes of the meeting and saw there was a mention >>>>> that >>>>> >>>>>>>>>>>> I should argue :-). >>>>>>>>>>>> I don't agree with the outcome of the meeting. I think its >>>>>>>>>>>> important to note that MCC doesn't equal switching. A MCC >>>>>>>>>>>> may >>>>>>>>>>>> represent a dynamic switching case OR a static case. A >>>>>>>>>>>> static >>>>>>>>>>>> case may be that a MCU offers a single stream where three >>>>>>>>>>>> captures from an endpoint on separate streams are composed >>>>>>>>>>>> into >>>>>> one video stream. >>>>>>>>>>> Yes, we had that in mind when discussing this. >>>>>>>>>>>> I cannot see why in the >>>>>>>>>>>> static case spatial information isn't valid? In the static >>>>>>>>>>>> case >>>>>>>>>>>> the concerns of 2, 3 and 4 don't apply. >>>>>>>>>>> We may not have understood you. We were guessing what you >>>>>> meant. >>>>>>>>>>> Suppose there is an MCC that has three input captures, and >>>>>>>>>>> composes >>>>>>>>> them. >>>>>>>>>>> It could compose them in many ways. It could put the three >>>>> side by >>>>> >>>>>>>>>>> side, or one big one and two as picture-in-picture overlays, >>>>> or ... >>>>> >>>>>>>>>>> And even with three side by side, they could be in any order. >>>>>>>>> [CNG] Yes >>>>>>>>>>> And the source captures could all be from multiple scenes or >>>>>>>>>>> one, >>>>>>>>>>> and if one, it could be the same one as the MCC or not. The >>>>>>>>>>> simplest case is that they are all from the same scene as the >>>>> MCC. >>>>> >>>>>>>>>>> But even then, the coordinates of the source captures are >>>>>>>>>>> presumably meaningful if they are individually configured. We >>>>>>>>>>> could see no reason to presume that their arrangement in the >>>>> scene >>>>> >>>>>>>>>>> has anything to do with their >>>>>>>>> arrangement in the MCC. >>>>>>>>> [CNG] Paul you mentioned the idea of a virtual scene before. >>>>>>>>> What I >>>>>>>>> see an MCU doing is creating a virtual scene using these source >>>>>>>>> captures. >>>>>>>>> Giving Captures spatial co-ordinates within a virtual scene is >>>>>>>>> a >>>>>>>>> valid thing to do irrespective of the use of a MCC. The MCU may >>>>>>>>> apply any transformation it wants based on the source capture >>>>>>>>> information. I think this equally applies to the MCC itself. >>>>>>>>> Now if the MCU constructs a composed image from several sources >>>>>>>>> using a MCC I can't see why it cannot indicate the spatial >>>>>>>>> position >>>>>>>>> of the sources in the MCC as they also reside in the virtual >>>>>>>>> space. >>>>>>>>>>> So we need more info to understand your perspective on this. >>>>>>>>>>>> From the minutes I didn't see an explanation of other >>>>>>>>>>>> people's >>>>>>>>> concerns. >>>>>>>>>>>> So rather than a complete prohibition of the spatial >>>>>>>>>>>> information >>>>>>>>>>>> regarding individual captures I think it would be better to >>>>>>>>>>>> explain that the Advertiser has a choice to include the >>>>>>>>>>>> information and that the spatial information is only >>>>>>>>>>>> meaningful >>>>>>>>>>>> if the individual capture's spatial information is static. >>>>> That's >>>>> >>>>>>>>>>>> what I tried to capture in the text below. >>>>>>>>>>> I already commented on this earlier. >>>>>>>>>>> IMO the advertiser MAY provide spatial information on an MCC. >>>>> That >>>>> >>>>>>>>>>> would describe a place within the scene of the MCC. IMO that >>>>>>>>>>> is a >>>>>>>>>>> suggestion by the advertiser, but doesn't have the same >>>>>>>>>>> physical >>>>>>>>>>> significance as will a non-MCC capture. >>>>>>>>> [CNG] I don't understand why the spatial information of the MCC >>>>>>>>> has >>>>>>>>> less significance than a non-MCC capture? An Advertiser >>>>>>>>> constructs >>>>>>>>> the scene, it give the spatial positioning. If the MCC and >>>>>>>>> non-MCC >>>>>>>>> captures are part of the same CSE then equal weight should be >>>>> given. >>>>> >>>>>>>>>>> The consumer could just use this, treating the MCC like any >>>>>>>>>>> other >>>>>>>>>>> capture. Or, if it is smarter, and the MCC is *switched*, it >>>>> could >>>>> >>>>>>>>>>> ignore this and look into the spatial info for the source >>>>> captures. >>>>> >>>>>>>>> [CNG] If the MCC is "switched" AND the spatial information >>>>>>>>> changes >>>>>>>>> between source captures then this would be the dynamic case. I >>>>> think >>>>> >>>>>>>>> the advice is that a Advertiser shouldn't provide this >>>>>>>>> information >>>>>>>>> unless it also provides a means for the Consumer to determine >>>>>>>>> when >>>>>>>>> the switch takes place. If the MCC is "switched" and the source >>>>>>>>> spatial information is the same then the Advertiser can simply >>>>>>>>> supply the spatial information at the MCC level without the >>>>>>>>> need to >>>>>>>>> set it on the sources. >>>>>>>>>>> But none of that has anything to do with the the arrangement >>>>>>>>>>> of >>>>>>>>>>> composed captures within an MCC. >>>>>>>>> [CNG] I don't understand the point. You only focused on the >>>>> switched >>>>> >>>>>>>>> case. >>>>>>>>> MCC is for switching and composition. >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>>> Regards, Christian >>>>>>>>>>>> On 18/01/2014 9:50 AM, Duckworth, Mark wrote: >>>>>>>>>>>>> We discussed this topic in the design team meeting Jan 14 >>>>> >>>> >>>>>>>>>>> Team/minutes_140114.txt>. >>>>>>>>>>>>> From the minutes: >>>>>>>>>>>>> "Conclusion 1: Spatial information of the individual >>>>>>>>>>>>> captures >>>>>>>>>>>>> does not apply inside a composed MCC." >>>>>>>>>>>>> We wanted to bring this topic back to the list to make sure >>>>>>>>>>>>> we >>>>>>>>>>>>> have consensus before clarifying the framework about this. >>>>>>>>>>>>> Christian, or anybody else, do you still want more discussion? >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Mark >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>>>>> Duckworth, Mark >>>>>>>>>>>>>> Sent: Friday, January 10, 2014 4:04 PM >>>>>>>>>>>>>> To: Christian Groves; clue@ietf.org >>>>>>>>>>>>>> Subject: Re: [clue] spatial information can't describe >>>>>>>>>>>>>> video >>>>>>>>>>>>> locations within >>>>>>>>>>>>>> composed MCC >>>>>>>>>>>>>> Thanks Christian, that is an improvement. But I'm still >>>>>>>>>>>>>> not >>>>>>>>>>>>> convinced the >>>>>>>>>>>>>> consumer can always tell when the spatial attributes are >>>>>>>>>>>>>> meaningful >>>>>>>>>>>>> (even >>>>>>>>>>>>>> within a scene) for discerning how contributors to a >>>>>>>>>>>>>> composed >>>>>>>>>>>>>> MCC are arranged within the MCC. My concerns 2, 3, and 4 >>>>>>>>>>>>>> below >>>>>>>>>>>>>> still apply. >>>>>>>>>>>>>> Does anybody else have input to this topic? >>>>>>>>>>>>>> Mark >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Christian Groves >>>>>>>>>>>>>>> [mailto:Christian.Groves@nteczone.com] >>>>>>>>>>>>>>> Sent: Thursday, January 09, 2014 9:19 PM >>>>>>>>>>>>>>> To: Duckworth, Mark; clue@ietf.org >>>>>>>>>>>>>>> Subject: Re: [clue] spatial information can't describe >>>>>>>>>>>>>>> video >>>>>>>>>>>>> locations >>>>>>>>>>>>>>> within composed MCC >>>>>>>>>>>>>>> Hello Mark, >>>>>>>>>>>>>>> How about something like the following? >>>>>>>>>>>>>>> 7.2.1. MCC Attributes >>>>>>>>>>>>>>> Attributes may be associated with the MCC instance and >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> Single Media Captures that the MCC references. A provider >>>>>>>>>>>>>>> should avoid providing conflicting attribute values >>>>>>>>>>>>>>> between >>>>>>>>>>>>>>> the MCC and Single Media Captures. Where there is >>>>>>>>>>>>>>> conflict >>>>> the >>>>> >>>>>>>>>>>>>>> attributes of the MCC override any that may be present in >>>>>>>>>>>>>>> the >>>>>> individual captures. >>>>>>>>>>>>>>> <>>>>>>>>>>>>>> captures >>>>>>>>>>>>>>> within a MCC and/or to the MCC itself the Provider should >>>>>>>>>>>>>>> be >>>>>>>>>>>>>>> aware that spatial attributes have no relation across >>>>>>>>>>>>>>> Capture >>>>>> Scenes. >>>>>>>>>>>>>>> Therefore >>>>>>>>>>>>>>> if the Provider intends to provide a spatial relation >>>>>>>>>>>>>>> between >>>>>>>>>>>>>>> the source Captures and the MCC then these MUST be part >>>>>>>>>>>>>>> of >>>>>> the >>>>>>>>>>>>>>> same >>>>>>>>>>>>>> Capture Scene. >>>>>>>>>>>>>>> When assigning spatial information that would cause the >>>>>>>>>>>>>>> spatial positioning of the source Capture to move within >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> MCC, the >>>>>>>>>>>>> Provider >>>>>>>>>>>>>>> should also be aware that a Consumer may not be able to >>>>>>>>>>>>>>> determine >>>>>>>>>>>>> that >>>>>>>>>>>>>>> the source captures have moved.>> ... >>>>>>>>>>>>>>> Regards, Christian >>>>>>>>>>>>>>> On 8/01/2014 12:18 AM, Duckworth, Mark wrote: >>>>>>>>>>>>>>>> Hello Christian, >>>>>>>>>>>>>>>> So there are only certain circumstances in which spatial >>>>>>>>>>>>> information >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> components of a composed capture is relevant. For the >>>>>>>>>>>>>>> case >>>>>>>>>>>>>>> where you think it is important and relevant, can you >>>>>>>>>>>>>>> please >>>>>>>>>>>>>>> propose text for the framework to describe this? I think >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> framework should be more clear about when and how the >>>>>> consumer >>>>>>>>>>>>>>> can use >>>>>>>>> this >>>>>>>>>>>>>>> information for composed captures. >>>>>>>>>>>>>>>> Mark >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>>>>>>>> Christian Groves >>>>>>>>>>>>>>>>> Sent: Tuesday, January 07, 2014 12:08 AM >>>>>>>>>>>>>>>>> To: clue@ietf.org >>>>>>>>>>>>>>>>> Subject: Re: [clue] spatial information can't describe >>>>> video >>>>> >>>>>>>>>>>>>>>>> locations within composed MCC Hello Mark, I agree with >>>>>>>>>>>>>>>>> respect to the fact that spatial information isn't >>>>>>>>>>>>>>>>> valid >>>>>>>>>>>>>>>>> across Capture Scenes. i.e. If I have an MCC in one >>>>>>>>>>>>> Cap.Scene >>>>>>>>>>>>>>>>> referencing individual captures from other scenes. >>>>> However I >>>>> >>>>>>>>>>>>>>>>> think there is a valid case where an MCC can reference >>>>>>>>>>>>>>>>> Individual captures from the same scene as it. In this >>>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>>>> I think the >>>>>>>>>>>>> use of >>>>>>>>>>>>>>>>> spatial >>>>>>>>>>>>>>> information is valid, i.e. >>>>>>>>>>>>>>>>> +-----------------------+---------------------------------+ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> | Capture Scene #1 | | >>>>>>>>>>>>>>>>> +-----------------------|---------------------------------+ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> | VC1 | CapArea=Left | >>>>>>>>>>>>>>>>> | VC2 | CapArea=Right | >>>>>>>>>>>>>>>>> | MCC1(VC1, VC2) | | >>>>>>>>>>>>>>>>> +---------------------------------------------------------+ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>> +-----------------------+---------------------------------+ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> | Capture Scene #1 | | >>>>>>>>>>>>>>>>> +-----------------------|---------------------------------+ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> | MCC1(VC1) | CapArea=Left | >>>>>>>>>>>>>>>>> | MCC2(VC2) | CapArea=Right | >>>>>>>>>>>>>>>>> | MCC1(MCC1,MCC2) | | >>>>>>>>>>>>>>>>> +---------------------------------------------------------+ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> where VC1 and VC2 are from different Capture Scenes. >>>>>>>>>>>>>>>>> There are of course cases where the spatial information >>>>>>>>>>>>> wouldn't be >>>>>>>>>>>>>>>>> valid but in those cases the Provider wouldn't provide >>>>> them, >>>>> >>>>>>>>>>>>>>>>> i.e. >>>>>>>>>>>>>>>>> where the individual captures move. However there will >>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>> cases where the composition is static and the >>>>>>>>>>>>>>>>> information >>>>>>>>>>>>>>>>> would be >>>>>>>>>>>>> valid. >>>>>>>>>>>>>>>>> I don't think we can make a general assumption that the >>>>>>>>>>>>>>>>> spatial information is >>>>>>>>>>>>>>> valid or invalid in all cases. >>>>>>>>>>>>>>>>> Regards, Christian >>>>>>>>>>>>>>>>> On 7/01/2014 7:54 AM, Duckworth, Mark wrote: >>>>>>>>>>>>>>>>>> Framework version 13 says a provider can use spatial >>>>>>>>>>>>>>>>>> information of source media captures to describe how >>>>>>>>>>>>>>>>>> those >>>>>>>>>>>>>>>>>> sources are placed within a composed multiple content >>>>>>>>>>>>>>>>>> capture (MCC). In general I think this won't work, and >>>>>>>>>>>>>>>>>> I'm >>>>>>>>>>>>>>>>>> not even sure under what specific conditions it might >>>>> work. >>>>> >>>>>>>>>>>>>>>>>> So I propose removing that part, and instead add text >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> say the spatial information of individual captures >>>>>>>>>>>>>>>>>> does >>>>> not >>>>> >>>>>>>>>>>>>>>>>> relate to its relative position within a >>>>>>>>>>>>> composed >>>>>>>>>>>>>> MCC. >>>>>>>>>>>>>>>>>> From section 7.2.1: >>>>>>>>>>>>>>>>>> For example: The spatial related attributes can be >>>>>>>>>>>>>>>>>> further >>>>>>>>>>>>> used to >>>>>>>>>>>>>>>>>> determine how the individual captures "appear" within >>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>> stream. A virtual scene could be constructed for the >>>>>>>>>>>>>>>>>> MCC >>>>>>>>>>>>>>>>>> capture with two Video Captures with a "MaxCaptures" >>>>>>>>>>>>>>>>>> attribute set to 2 and an "Area of Capture" attribute >>>>>>>>>>>>>>>>>> provided with an overall area. >>>>>>>>>>>>> Each of >>>>>>>>>>>>>>>>>> the individual Captures could then also include an >>>>> "Area of >>>>> >>>>>>>>>>>>> Capture" >>>>>>>>>>>>>>>>>> attribute with a sub-set of the overall area. The >>>>>>>>>>>>>>>>>> Consumer >>>>>>>>>>>>>>>>>> would then know the relative position of the content >>>>>>>>>>>>>>>>>> in >>>>> the >>>>> >>>>>>>>>>>>>>>>>> composed >>>>>>>>>>>>>> stream. >>>>>>>>>>>>>>>>>> Here are some reasons why I think this will generally >>>>>>>>>>>>>>>>>> not >>>>>> work: >>>>>>>>>>>>>>>>>> 1.The spatial information for captures is relevant >>>>>>>>>>>>>>>>>> only in >>>>>>>>>>>>>>>>>> relation to the capture scene to which the captures >>>>> belong. >>>>> >>>>>>>>>>>>>>>>>> Spatial information from different scenes has no >>>>>>>>>>>>>>>>>> relation >>>>>>>>>>>>>>>>>> to each other. So if the individual captures that are >>>>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>>> of a composed MCC come from different scenes >>> (source >>>>>>>>>>>>>>>>>> captures >>>>>>>>> from >>>>>>>>>>>>>>>>>> multiple scenes, or source captures from different >>>>>>>>>>>>>>>>>> scenes >>>>>>>>>>>>>>>>>> than the >>>>>>>>>>>>>>>>>> MCC) >>>>>>>>>>>>>>>>>> then the spatial information of one capture has no >>>>> relation >>>>> >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> spatial information of another capture. >>>>>>>>>>>>>>>>>> 2.In the example with MaxCaptures = 2, that doesn't >>>>>>>>>>>>>>>>>> mean >>>>>>>>>>>>>>>>>> there will always be 2 contributing captures in the >>>>> MCC. It >>>>> >>>>>>>>>>>>>>>>>> just means maximum of 2, but sometimes there could >>> be 1. >>>>>>>>>>>>>>>>>> The contents of the MCC could actually be changing >>>>>>>>>>>>>>>>>> over >>>>>>>>>>>>>>>>>> time between 1 and 2 >>>>>>>>>>>>>> contributing captures. >>>>>>>>>>>>>>>>>> If it changes between one full screen source image to >>>>>>>>>>>>>>>>>> two >>>>>>>>>>>>>>>>>> source images side by side, then the spatial >>>>>>>>>>>>>>>>>> information >>>>>>>>>>>>>>>>>> wouldn't always indicate the location of the source >>>>>>>>>>>>>>>>>> within >>>>>>>>>>>>>>>>>> the MCC. We have no >>>>>>>>>>>>> way >>>>>>>>>>>>>>>>>> for the provider to advertise this level of detail, >>>>>>>>>>>>>>>>>> and I >>>>>>>>>>>>>>>>>> don't think we want to get into this detail in >>>>>>>>>>>>>>>>>> provider >>>>>>>>>>>>>>>>>> advertisements. >>>>>>>>>>>>>>>>>> 3.Similarly, the MCC could always contain both >>>>>>>>>>>>>>>>>> individual >>>>>>>>>>>>>>>>>> captures, but maybe it is a large image of the one >>>>>>>>>>>>>>>>>> that is >>>>>>>>>>>>> talking >>>>>>>>>>>>>>>>>> and a small image of the other. This would change over >>>>>>>>>>>>>>>>>> time, so again the spatial information wouldn't always >>>>>>>>>>>>>>>>>> indicate the location of the source within the MCC. >>>>>>>>>>>>>>>>>> 4.Take a slightly different example, where the MCC >>>>> contains >>>>> >>>>>>>>>>>>>>>>>> 4 contributing individual captures, but still with >>>>>>>>>>>>>>>>>> MaxCaptures = 2. >>>>>>>>>>>>>>>>>> So the resulting MCC again will change over time, as >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> provider is free to choose which 2 out of the 4 to >>>>>>>>>>>>>>>>>> include >>>>>>>>>>>>>>>>>> at any time. So again the spatial information wouldn't >>>>>>>>>>>>>>>>>> always indicate the location of the source within the >>> MCC. >>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>> Mark >>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>>>>>>> clue@ietf.org >>>>> >>>>> >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>>>>>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> clue mailing list >>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> clue mailing list >>>>>>>>>>> clue@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>> _______________________________________________ >>>>>>>>>> clue mailing list >>>>>>>>>> clue@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>> _______________________________________________ >>>>>>>>> clue mailing list >>>>>>>>> clue@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Feb 6 09:03:29 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3996B1A017B for ; Thu, 6 Feb 2014 09:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEjh_dcd74lj for ; Thu, 6 Feb 2014 09:03:27 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 8703C1A0149 for ; Thu, 6 Feb 2014 09:03:27 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta01.westchester.pa.mail.comcast.net with comcast id P1eJ1n0060xGWP85153SYw; Thu, 06 Feb 2014 17:03:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id P53S1n0043ZTu2S3Y53Szh; Thu, 06 Feb 2014 17:03:26 +0000 Message-ID: <52F3C05D.4080609@alum.mit.edu> Date: Thu, 06 Feb 2014 12:03:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <52E63880.1010504@nteczone.com> <52F2E41A.7060402@nteczone.com> In-Reply-To: <52F2E41A.7060402@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=1391706206; bh=GW0XOFc7bOU2VLy/YvCLPbSJCiI818TBFsVAzfb35s0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kTo3mg1ns0LsZ3Ypb6q95RZW6fRi9/J1xH1R3Uf6T9PUDHKJsBa9n2V9Q8/WDXG4n 80neABYqCTMVTVNdW9Fz5EBGytnChhFUKNKGdD9UK5kuWiPywffqR+G2cwrPrV3bWS xNUnU2TsXESN+H3PR4vsNBWSfqGKYBkGt0zF7qR+57Ov0VKsyYPSGkuoiWDufyevZT BqoaVVePZwcC5fpFCvGgfKMkkEtbyoKATTbFOtKrujtw0UZLlu/NAwLeMdcHPeBHd/ ogGQrYHujj0nHAxnOU2l6dTFnvqd4VwTuJiplm6jlMmSHeLzYh/m2wAKpvz09fNrB9 obs0/OBlOmt9A== Subject: Re: [clue] Text on participant type / participant information / scene information (ex.roles) for framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 17:03:29 -0000 This seems reasonable to me. (as an individual) Thanks, Paul On 2/5/14 8:23 PM, Christian Groves wrote: > Any comments regarding the participation information attribute text? > > Christian > > On 27/01/2014 9:44 PM, Christian Groves wrote: >> Hello all, >> >> There's an open ticket for me to provide some text regarding "roles" >> for the framework. Here's an initial attempt. >> >> 7.1.1.x Participant Information >> >> The participant information attribute allows a Provider to provide >> specific information regarding the conference participants in a Capture. >> The Provider may gather the information automatically or manually from a >> variety of sources however the xCard [RFC6351] format is used to convey >> the information. This allows various information such as Identification >> information (section 6.2/[RFC6350]), Communication Information (section >> 6.4/[RFC6350]) and Organisational information (section 6.6/[RFC6350]) to >> be communicated. A Consumer may then automatically (i.e. via a policy) >> or manually select Captures based on information about who is in a >> Capture. It also allows a Consumer to render information regarding the >> participants or to use it for further processing. >> >> The Provider may supply a minimal set of information or a larger set of >> information. However it MUST be compliant to [RFC6350] and supply a >> "VERSION" and "FN" property. A Provider may supply multiple xCards per >> Capture of any KIND (section 6.1.4/[RFC6350]). >> >> In order to keep CLUE messages compact the Provider SHOULD use a URI to >> point to any LOGO, PHOTO or SOUND contained in the xCARD rather than >> transmitting the LOGO, PHOTO or SOUND data in a CLUE message. >> >> 7.1.1.y Participant Type >> The participant type attribute indicates the type of participant/s >> contained in the capture in the conference with respect to the meeting >> agenda. As a capture may include multiple participants the attribute may >> contain multiple value. However values shall not be repeated within the >> attribute. >> >> An Advertiser associates the participant type with an individual >> capture when it knows that a particular type is in the capture. If an >> Advertiser cannot link a particular type with some certainty to a >> capture then it is not included. A Consumer on reception of a capture >> with a participant type attribute knows with some certainly that the >> capture contains that participant type. The capture may contain other >> participant types but the Advertiser has not been able to determine >> that this is the case. >> >> The types of Captured participants include: >> 1. Chairman - the participant responsible for running the conference >> according to the agenda. >> 2. Vice-Chairman - the participant responsible for assisting the >> chairman in running the meeting. >> 3. Minute Taker - the participant responsible for recording the minutes >> of the conference >> 4. Member - the participant has no particular responsibilities with >> respect to running the meeting. >> 5. Presenter - the participant is scheduled on the agenda to make a >> presentation in the meeting. Note: This is not related to any "active >> speaker" functionality. >> 6. Translator - the participant is providing some form of translation or >> commentary in the meeting. >> 7. Timekeeper - the participant is responsible for maintaining the >> meeting schedule. >> >> Furthermore the participant type attribute may contain one or more >> strings allowing the Provider to indicate custom meeting specific roles. >> >> 7.3.1.x Scene Information >> >> The Scene information attribute provides information regarding the >> Capture Scene rather than individual participants. The Provider may >> gather the information automatically or manually from a variety of >> sources. The scene information attribute allows a Provider to indicate >> information such as: organizational or geographic information allowing a >> Consumer to determine which Capture Scenes are of interest in order to >> then perform Capture selection. It also allows a Consumer to render >> information regarding the Scene or to use it for further processing. >> >> As per 7.1.1.x the xCard format is used to convey this information and >> the Provider may supply a minimal set of information or a larger set of >> information. >> >> In order to keep CLUE messages compact the Provider SHOULD use a URI to >> point to any LOGO, PHOTO or SOUND contained in the xCARD rather than >> transmitting the LOGO, PHOTO or SOUND data in a CLUE message. >> >> 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 pkyzivat@alum.mit.edu Thu Feb 6 09:08:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B231A01F4 for ; Thu, 6 Feb 2014 09:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xqwGOoRXxyo for ; Thu, 6 Feb 2014 09:08:26 -0800 (PST) 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 C055D1A017B for ; Thu, 6 Feb 2014 09:08:25 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id P30Z1n00A27AodY5A58QwE; Thu, 06 Feb 2014 17:08:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id P58Q1n00U3ZTu2S3f58QWP; Thu, 06 Feb 2014 17:08:24 +0000 Message-ID: <52F3C188.9040904@alum.mit.edu> Date: Thu, 06 Feb 2014 12:08:24 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <52E6E683.8090905@alum.mit.edu> In-Reply-To: <52E6E683.8090905@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=1391706504; bh=a+ugV5o4iCEX+NBvWrxaH3l7uXynQ6sygNjKfGRsp/I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iD9SaRVquKV0d2vmsMzB1qk71vA3QpWSMcmfVi2q7LmDvYiVDk6/4gyM1Xc+OawSD fNyfg2kPfvgie9IPSOoATyBgYqCMbDmXdY9h5z7TyAtB2ExfYyJXfXYxRaYaE/fxB9 S8b7NWjDjgFL6ehDJ5YdfQVbD+YrtaG57JED7xkOzWW2XgYmrIme18zCeOk8ESM8vM o92f4GSCKO/rdaoeRqbMFx/YNKU4ZmAnwl57S/Cygm5M7U2f7kM7Db3NBgCjngYqBl j/87e5/xUGKRYp7+s6GodgOzq9ynfJdAbFjSO1ooihHOAeY67cbWlJlf8Z83lu8QBV ZxnfqLmNAy1+w== Subject: Re: [clue] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 17:08:27 -0000 Any comments on this? On 1/27/14 6:06 PM, Paul Kyzivat wrote: > * The problem: > > As we discussed in the interim today, it seems unclear what a consumer > should do when receiving an advertisement with multiple scenes in order > to get a sufficient representation of the advertised content. > > Our simple cases have been where there is one scene for the cameras in > the room, and another scene for a presentation. In that case, one should > take something from each scene (typically one CSE from each) to get > "enough". > > That is also true if an MCU acted in "pass through" mode and simply > included "copies" of all the scenes it receives in advertisements, with > encodings for them all. > > In a "simple" case with an MCU use MCC, it might "pass through" all the > advertisements it receives, for their spatial info, but not provide any > encodings for them. Rather, it would provide one or more new scenes > using MCC to aggregate those sources. Then one would not want to > configure from the "pass through" scenes, but that isn't an option > anyway if there are no encodings for them. > > Mark has proposed using multiple scenes with MCC to illustrate switched > cases where some groupings don't have any spatial relationship to one > another. Some of those examples end up with multiple scenes that do have > encodings, where it doesn't make sense to configure something from each > scene. > > Today we discussed using priority to solve this, but this isn't really a > priority problem, it is a problem of *alternatives* that may be equally > desirable, depending on the resources or desires of the consumer. > > IMO the problem is that our CSE mechanism is a way for the advertiser to > suggest alternatives, but this only works on a per-scene basis. The > advertiser has no comparable mechanism to suggest alternatives from > different scenes. > > * My proposed solution: > > I want to restate a proposal I made a long time ago: > > Instead of one CSE list per scene, have one CSE list per-advertisement, > referencing captures from any scene. > > This makes it possible for the advertiser to recommend combinations that > cross scene boundaries. > > * An alternate solution: > > Another possibility would be to leave CSEs as they are, but add > something analogous to a CSE list, but that lists recommended > combinations of scenes. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Thu Feb 6 09:19:09 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D5B1A017C for ; Thu, 6 Feb 2014 09:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qieu5kFHNb3f for ; Thu, 6 Feb 2014 09:19:07 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 32A341A013C for ; Thu, 6 Feb 2014 09:19:07 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 6 Feb 2014 09:19:06 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 6 Feb 2014 09:19:04 -0800 Thread-Topic: [clue] Text on participant type / participant information / scene information (ex.roles) for framework Thread-Index: Ac8jXWF3rpkXnNSTS7ymdOhHMgrfMQAAfhDQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB170@CRPMBOXPRD07.polycom.com> References: <52E63880.1010504@nteczone.com> <52F2E41A.7060402@nteczone.com> <52F3C05D.4080609@alum.mit.edu> In-Reply-To: <52F3C05D.4080609@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] Text on participant type / participant information / scene information (ex.roles) for framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 17:19:09 -0000 I agree. Thanks Christian, for writing it as specific text for the framewo= rk document. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, February 06, 2014 12:03 PM > To: clue@ietf.org > Subject: Re: [clue] Text on participant type / participant information / = scene > information (ex.roles) for framework >=20 > This seems reasonable to me. (as an individual) >=20 > Thanks, > Paul >=20 > On 2/5/14 8:23 PM, Christian Groves wrote: > > Any comments regarding the participation information attribute text? > > > > Christian > > > > On 27/01/2014 9:44 PM, Christian Groves wrote: > >> Hello all, > >> > >> There's an open ticket for me to provide some text regarding "roles" > >> for the framework. Here's an initial attempt. > >> > >> 7.1.1.x Participant Information > >> > >> The participant information attribute allows a Provider to provide > >> specific information regarding the conference participants in a Captur= e. > >> The Provider may gather the information automatically or manually > >> from a variety of sources however the xCard [RFC6351] format is used > >> to convey the information. This allows various information such as > >> Identification information (section 6.2/[RFC6350]), Communication > >> Information (section > >> 6.4/[RFC6350]) and Organisational information (section 6.6/[RFC6350]) > >> to be communicated. A Consumer may then automatically (i.e. via a > >> policy) or manually select Captures based on information about who is > >> in a Capture. It also allows a Consumer to render information > >> regarding the participants or to use it for further processing. > >> > >> The Provider may supply a minimal set of information or a larger set > >> of information. However it MUST be compliant to [RFC6350] and supply > >> a "VERSION" and "FN" property. A Provider may supply multiple xCards > >> per Capture of any KIND (section 6.1.4/[RFC6350]). > >> > >> In order to keep CLUE messages compact the Provider SHOULD use a URI > >> to point to any LOGO, PHOTO or SOUND contained in the xCARD rather > >> than transmitting the LOGO, PHOTO or SOUND data in a CLUE message. > >> > >> 7.1.1.y Participant Type > >> The participant type attribute indicates the type of participant/s > >> contained in the capture in the conference with respect to the > >> meeting agenda. As a capture may include multiple participants the > >> attribute may contain multiple value. However values shall not be > >> repeated within the attribute. > >> > >> An Advertiser associates the participant type with an individual > >> capture when it knows that a particular type is in the capture. If an > >> Advertiser cannot link a particular type with some certainty to a > >> capture then it is not included. A Consumer on reception of a capture > >> with a participant type attribute knows with some certainly that the > >> capture contains that participant type. The capture may contain other > >> participant types but the Advertiser has not been able to determine > >> that this is the case. > >> > >> The types of Captured participants include: > >> 1. Chairman - the participant responsible for running the conference > >> according to the agenda. > >> 2. Vice-Chairman - the participant responsible for assisting the > >> chairman in running the meeting. > >> 3. Minute Taker - the participant responsible for recording the > >> minutes of the conference 4. Member - the participant has no > >> particular responsibilities with respect to running the meeting. > >> 5. Presenter - the participant is scheduled on the agenda to make a > >> presentation in the meeting. Note: This is not related to any "active > >> speaker" functionality. > >> 6. Translator - the participant is providing some form of translation > >> or commentary in the meeting. > >> 7. Timekeeper - the participant is responsible for maintaining the > >> meeting schedule. > >> > >> Furthermore the participant type attribute may contain one or more > >> strings allowing the Provider to indicate custom meeting specific role= s. > >> > >> 7.3.1.x Scene Information > >> > >> The Scene information attribute provides information regarding the > >> Capture Scene rather than individual participants. The Provider may > >> gather the information automatically or manually from a variety of > >> sources. The scene information attribute allows a Provider to > >> indicate information such as: organizational or geographic > >> information allowing a Consumer to determine which Capture Scenes are > >> of interest in order to then perform Capture selection. It also > >> allows a Consumer to render information regarding the Scene or to use = it > for further processing. > >> > >> As per 7.1.1.x the xCard format is used to convey this information > >> and the Provider may supply a minimal set of information or a larger > >> set of information. > >> > >> In order to keep CLUE messages compact the Provider SHOULD use a URI > >> to point to any LOGO, PHOTO or SOUND contained in the xCARD rather > >> than transmitting the LOGO, PHOTO or SOUND data in a CLUE message. > >> > >> 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 > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Feb 6 09:34:26 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AF31A03F2 for ; Thu, 6 Feb 2014 09:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97t8a8dc4f5Y for ; Thu, 6 Feb 2014 09:34:24 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDEF1A03EA for ; Thu, 6 Feb 2014 09:34:24 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta03.westchester.pa.mail.comcast.net with comcast id P2RR1n0040SCNGk535aNLD; Thu, 06 Feb 2014 17:34:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id P5aN1n00p3ZTu2S3V5aNkV; Thu, 06 Feb 2014 17:34:22 +0000 Message-ID: <52F3C79E.7010903@alum.mit.edu> Date: Thu, 06 Feb 2014 12:34:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> In-Reply-To: <52E72506.3080800@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=1391708063; bh=wuVVUaigkSuXmBXeWnm/Tugyx40/CqzwxfzfzSHFVvE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=j80RIbAlX3vPXPKJtEi3ZWwjp/NlSDqTjU/UbjRKF066e7bLrUpxXHk40XhZuEnqL KD1VlAAVlsket2xuQK2C2A3cvJhFvD4RcI7fY/mbOrWos5K/+fsq/gt6n8p5pcwIdy tudElAZsX8TQLEGy8qzyDeSTX6qfhgiyGnBMhrSdq8rqVlMzfbM3KEINHF0DdRPZxy ietwdV0oXVmfnUeEvNRLHMq4oI5GtlFvkC6kk68mop75FV0l20Xd7yl24t/QX9d938 LUfWAtkKKtNHIqAQQgJw0filTxh5dnz0xF/eV/hmC37dxtRx06ko/Ob5m3mK9asgE0 H/qUA8yVriPjg== Subject: Re: [clue] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 17:34:26 -0000 I just realized I had missed this reply. See inline. On 1/27/14 10:33 PM, Christian Groves wrote: > Hello Paul, > > Please see below. > > Regards, Christian > > On 28/01/2014 10:06 AM, Paul Kyzivat wrote: >> * The problem: >> >> As we discussed in the interim today, it seems unclear what a consumer >> should do when receiving an advertisement with multiple scenes in >> order to get a sufficient representation of the advertised content. >> >> Our simple cases have been where there is one scene for the cameras in >> the room, and another scene for a presentation. In that case, one >> should take something from each scene (typically one CSE from each) to >> get "enough". >> >> That is also true if an MCU acted in "pass through" mode and simply >> included "copies" of all the scenes it receives in advertisements, >> with encodings for them all. >> >> In a "simple" case with an MCU use MCC, it might "pass through" all >> the advertisements it receives, for their spatial info, but not >> provide any encodings for them. Rather, it would provide one or more >> new scenes using MCC to aggregate those sources. Then one would not >> want to configure from the "pass through" scenes, but that isn't an >> option anyway if there are no encodings for them. > [CNG] The idea of the pass through information was that the consumer > could use any capture attribute (not just spatial ones) to determine > what media it wanted. Clearly if there are no encodings, then the captures are there only for information and can't be configured. That is why I called this the "simple" case. >> Mark has proposed using multiple scenes with MCC to illustrate >> switched cases where some groupings don't have any spatial >> relationship to one another. Some of those examples end up with >> multiple scenes that do have encodings, where it doesn't make sense to >> configure something from each scene. > [CNG] I don't think there's anything in the framework that says a > consumer must choose a capture from a scene. Of course there is no MUST. The consumer isn't required take *anything*. The question is how the consumer knows what is required to have a "complete" representation of what is in the advertisement. It may not want all that, but it is hard to make a good choice without knowing. That is the point of CSEs - for the advertiser to indicate what it considers to be good alternative choices. But CSEs only work within a scene. Once there are multiple scenes, the consumer has less guidance on what would be good (or sufficient) choices. The consumer has *some* information: - if none of the captures in a scene have encodings, then there is no need (or way) to select them directly - if MCC M in scene X references capture C in scene Y, then it would be redundant to configure both M and C ISTM that one should start out assuming that you need all captures (that have encodings) in *some* CSE from *each* scene. You can then prune that based on the logic above. But is that *enough* to make good decisions? At best, the logic to figure that out is complex. >> Today we discussed using priority to solve this, but this isn't really >> a priority problem, it is a problem of *alternatives* that may be >> equally desirable, depending on the resources or desires of the consumer. > [CNG] I agree I don't think priority is the right solution for this. >> >> IMO the problem is that our CSE mechanism is a way for the advertiser >> to suggest alternatives, but this only works on a per-scene basis. The >> advertiser has no comparable mechanism to suggest alternatives from >> different scenes. >> >> * My proposed solution: >> >> I want to restate a proposal I made a long time ago: >> >> Instead of one CSE list per scene, have one CSE list >> per-advertisement, referencing captures from any scene. >> >> This makes it possible for the advertiser to recommend combinations >> that cross scene boundaries. > [CNG] Perhaps you could give some examples? Does the list need to be > exhaustive? Does the CSE list in a scene have to be exhaustive? I think each entry should be "sufficient" for somebody that can't handle a bigger one. The definition of "sufficient" is subjective. > e.g. the simple case today > Scene1 CSE1(VC1,VC2,VC3) > CSE2(VC4) > Scene2 CSE3(VC5,presentation1) > > Does it mean now the Advertisement would now have to advertise? > CSE1(VC1,VC2,VC3,VC5) > CSE2(VC4,VC5) > CSE3(VC1,VC2,VC3) > CSE4(VC4) > CSE5(VC5) As I said, the definition of "sufficient" is subjective. IMO the advertisement ought to include at least CSE1,CSE2. Rather than include the others, I think I would adjust the priorities of the individual captures based on my judgement of which I think should be kept if they all can't be. Thanks, Paul >> * An alternate solution: >> >> Another possibility would be to leave CSEs as they are, but add >> something analogous to a CSE list, but that lists recommended >> combinations of scenes. >> >> Thanks, >> Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Thu Feb 6 09:38:34 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6681A019E for ; Thu, 6 Feb 2014 09:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPQggHeSFsrK for ; Thu, 6 Feb 2014 09:38:32 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD71A0079 for ; Thu, 6 Feb 2014 09:38:32 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 6 Feb 2014 09:38:31 -0800 From: "Duckworth, Mark" To: "mary.ietf.barnes@gmail.com" Date: Thu, 6 Feb 2014 09:38:28 -0800 Thread-Topic: [clue] Ticket #33: Security for Framework document Thread-Index: Ac8VgFjOGTfhdaePTKKVi6uOgL84UQN4TgFQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB192@CRPMBOXPRD07.polycom.com> References: <52D44B95.7080906@alum.mit.edu> <52DC7E14.9080603@nteczone.com> In-Reply-To: <52DC7E14.9080603@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] Ticket #33: Security for Framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 17:38:35 -0000 Hello Mary, At the interim meeting I think you said you want to make some edits to your= initial security section text, before including it in the framework. Shou= ld I wait for that, before adding this into the Security Considerations in = the framework? Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Sunday, January 19, 2014 8:38 PM > To: clue@ietf.org > Subject: Re: [clue] Ticket #33: Security for Framework document >=20 > Hello Mary, >=20 > This looks pretty good. Maybe one thing to note is the user is authentica= ted > (i.e. the UA) any information provided about the participants in the > conference described by CLUE may not be. For > example: as a participant I may provide my xCard information which is car= ried > by CLUE and assert that I'm the president. There may not be any sanity ch= eck > of such information. >=20 > In the case of an MCU it may pass on CLUE information regarding the > contents of the media in good faith. It has no knowledge of what is actua= lly > depicted by the media. >=20 > Regards, Christian >=20 > On 14/01/2014 7:24 AM, Paul Kyzivat wrote: > > This seems pretty good. I expect there will be questions (somewhere) > > on the choice of SHOULD vs. MUST, so we should be very careful to have > > justification for such choices. > > > > Also, requiring the value of attacking the clue channel, while the > > things you describe are obvious points of high interest, even the more > > basic information could provide useful information to some attackers. > > If nothing else, that information provides a very detailed "footprint" > > that can be used to narrow down the identity of the endpoint. For > > instance, it will probably be very easy to look at an advertisement > > and discern the manufacturer and particular configuration of equipment > > at that endpoint. That could be helpful to narrow down the identity of > > the participants. > > > > Of course the same precautions that protect the vcards protect all > > this other stuff too. > > > > Thanks, > > Paul > > > > On 1/13/14 12:53 PM, Mary Barnes wrote: > >> HI all, > >> > >> I've had the longstanding action item to write some security text for > >> the framework. Below is what i have concocted. Please review and > >> post any comments/concerns to the list, along with suggested text to > >> address your comments/concerns. > >> > >> Mark will fold this into the next version of the framework document. > >> > >> Thanks, > >> Mary. > >> > >> > >> There are several potential attacks related to > >> telepresence, and specifically the protocols used by CLUE, > >> in the case of conferencing sessions, > >> due to the natural involvement of multiple endpoints > >> and the many, often user-invoked, capabilities provided by the > >> systems. > >> > >> A middle box involved in a CLUE session can experience > >> many of the same attacks as that of a conferencing system such > >> as that enabled by the XCON framework [RFC 6503]. > >> Examples of attacks include the following: an > >> endpoint attempting to listen to sessions in which it is not > >> authorized to participate, an endpoint attempting to disconnect or > >> mute other users, and theft of service by an endpoint in attemptin= g > >> to create telepresence sessions it is not allowed to create. > >> Thus, it is RECOMMENDED that a middle box implementing the > protocols > >> necessary to support CLUE, follow the security recommendations > >> specified in the > >> conference control protocol documents. In the case of CLUE, SIP > >> is the > >> default conferencing protocol, thus the security considerations > >> in RFC 4579 SHOULD be > >> followed. > >> > >> One primary security concern, surrounding the CLUE framework > >> introduced in this document, involves securing the actual protocol= s > >> and the associated authorization mechanisms. These concerns > >> apply to endpoint to endpoint sessions, as well as sessions > >> involving multiple > >> endpoints and middle boxes. > >> Figure 2 in section 5 provides a basic flow of information > >> exchange for CLUE > >> and the protocols involved. > >> > >> As described in section 5, CLUE uses SIP/SDP to establish the > >> session prior to > >> exchanging any CLUE specific information. Thus the security > >> mechanisms > >> recommended for SIP [RFC 3261], including user authentication and > >> authorization, > >> SHOULD be followed. In addition, the media is based on RTP and thu= s > >> existing RTP security mechanisms, such as DTLS/SRTP, MUST be > >> supported. > >> A separate data channel is established to transport the CLUE > >> protocol messages. > >> The contents of the CLUE protocol messages are based on > >> information introduced in > >> this document, which is represented by an XML schema for this > >> information > >> defined in the CLUE data model [ref]. Some of the information > >> which could possibly > >> introduce privacy concerns is the xCard information as described > >> in section x. > >> In addition, the (text) description field in the Media Capture > >> attribute > >> (section 7.1.1.7) could possibly reveal sensitive information or > >> specific identities. > >> The same would be true for the descriptions in the Capture Scene > >> (section 7.3.1) > >> and Capture Scene Entry (7.3.2) attributes. > >> It might also be possible for an attacker to manipulate the > >> information and disrupt > >> the CLUE sessions. It would also be possible to mount a DoS attac= k > >> on the CLUE endpoints if a malicious agent has access to the data > >> channel. > >> Thus, It MUST be possible for the endpoints to establish a > >> channel which is > >> secure against both message recovery and message modification. > >> Further details > >> on this are provided in the CLUE data channel solution document. > >> > >> There are also security issues associated with the authorization t= o > >> perform actions at the CLUE endpoints to invoke specific > >> capabilities (e.g., re-arranging screens, sharing content, etc.). > >> However, the policies and security > >> associated with these actions are outside the scope > >> of this document and the overall CLUE solution. > >> > >> > >> > >> _______________________________________________ > >> 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 Feb 6 09:55:29 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11541A044B for ; Thu, 6 Feb 2014 09:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZrZZzbN_VTd for ; Thu, 6 Feb 2014 09:55:28 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id CC8AA1A0449 for ; Thu, 6 Feb 2014 09:55:27 -0800 (PST) Received: from PWEHUB01.polycom.com (10.236.2.221) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 6 Feb 2014 09:55:26 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Thu, 6 Feb 2014 09:55:26 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 6 Feb 2014 09:55:24 -0800 Thread-Topic: MCC attributes composed and switching Thread-Index: Ac8jY+rMWBGBEnknSea0rkQCnufdSQ== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1B7@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_49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1B7CRPMBOXPRD07p_" MIME-Version: 1.0 Subject: [clue] MCC attributes composed and switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 17:55:29 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1B7CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In draft-ietf-clue-data-model-schema-03, and at the design team meeting Feb= 4, Roberta and Simon suggested adding the and eleme= nts in the data model, for MCCs. This is practically the same as the previ= ous composed and switched attributes we had for any media capture, but now = restricted to use with MCCs rather than any individual capture. Based on other recent discussions on the list, it seems to me it is useful = to support these optional attributes so the provider can more accurately in= dicate what it is doing. If the group agrees, I will add these attributes = back into the framework for MCCs. Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1B7CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In draft-ietf-cl= ue-data-model-schema-03, and at the design team meeting Feb 4, Roberta and = Simon suggested adding the <composed> and <switching> elements = in the data model, for MCCs.  This is practically the same as the prev= ious composed and switched attributes we had for any media capture, but now= restricted to use with MCCs rather than any individual capture.=

 

Based on= other recent discussions on the list, it seems to me it is useful to suppo= rt these optional attributes so the provider can more accurately indicate w= hat it is doing.  If the group agrees, I will add these attributes bac= k into the framework for MCCs.

&nbs= p;

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1B7CRPMBOXPRD07p_-- From Mark.Duckworth@polycom.com Thu Feb 6 10:00:49 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294911A0213 for ; Thu, 6 Feb 2014 10:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhqPm4b8MJOX for ; Thu, 6 Feb 2014 10:00:48 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id D72C81A01FD for ; Thu, 6 Feb 2014 10:00:47 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 6 Feb 2014 10:00:46 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 6 Feb 2014 10:00:45 -0800 Thread-Topic: [clue] should be optional Thread-Index: Ac8ViKBEpgd5qsK6T7e+khfQNjFP2gN3HSfQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1BE@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16009@CRPMBOXPRD07.polycom.com> <52DC8BFC.6050705@nteczone.com> In-Reply-To: <52DC8BFC.6050705@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] should be optional X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 18:00:49 -0000 I see is still mandatory in data-model-schema-03. Does the = rest of the group agree we should change this to optional? Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Sunday, January 19, 2014 9:38 PM > To: clue@ietf.org > Subject: Re: [clue] should be optional >=20 > Hello Mark, >=20 > I agree. >=20 > Regards, > Christian >=20 > On 18/01/2014 9:57 AM, Duckworth, Mark wrote: > > > > In the data model section 10.4, in "spatialInformationType", the > > "capturePoint" element is mandatory. It really should be optional. In > > earlier versions of the framework it was optional. This is described > > in section 10.4.1: "If the point of capture is not specified, it means > > the consumer should not assume anything about the spatial location of > > the capturing device." > > > > So I think the schema should have minOccurs=3D"0" for "capturePoint" > > element. And the text right below the schema part should say optional > > instead of mandatory. > > > > Mark > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Feb 6 10:09:52 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192891A01DE for ; Thu, 6 Feb 2014 10:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmVI727zuZrW for ; Thu, 6 Feb 2014 10:09:51 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 21CB71A01B1 for ; Thu, 6 Feb 2014 10:09:51 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta14.westchester.pa.mail.comcast.net with comcast id P1yY1n0031HzFnQ5E69pcr; Thu, 06 Feb 2014 18:09:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id P69p1n00k3ZTu2S3a69p30; Thu, 06 Feb 2014 18:09:49 +0000 Message-ID: <52F3CFED.7030500@alum.mit.edu> Date: Thu, 06 Feb 2014 13:09:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1B7@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1B7@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391710189; bh=9PnR6J2iR3lJwz5Dy2btBozEoIy81/BVTLyLh6CDd3s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VvWRDEGg8miBHFLcUmAhqyiXLaGM+th/NHZrMksA7Pygjw7HBe8ldl7Ef2x/r0GeI y7nU3JsXM6OtcjJ3DLXAUddByBJxFxcu4i+ABqQSOTR5fLYeBrcQEksJLmlo7XU2g3 8WAssjfsd9mbTIRIXeUIrGQzM4Lzge0qeGQa192PS89ga68IebgTG7YO8UQceMSt4l BoVvbGxw+dBGRiAIJ3fUi17F01gR9hsZpMC1DPYYbFSrTY8fNpcsUKEDYbl3UwyIKo PeBKg+pxqP1VZ8b5Q1lf8B0k2CoBsKXIJ7mU8UD4hwrYqWI/ar5nhGdgsBF/KLjBo2 YFEaEeDQA9q1A== Subject: Re: [clue] MCC attributes composed and switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 18:09:52 -0000 On 2/6/14 12:55 PM, Duckworth, Mark wrote: > In draft-ietf-clue-data-model-schema-03, and at the design team meeting > Feb 4, Roberta and Simon suggested adding the and > elements in the data model, for MCCs. This is practically the same as > the previous composed and switched attributes we had for any media > capture, but now restricted to use with MCCs rather than any individual > capture. > > Based on other recent discussions on the list, it seems to me it is > useful to support these optional attributes so the provider can more > accurately indicate what it is doing. If the group agrees, I will add > these attributes back into the framework for MCCs. See my earlier comment today regarding MaxCaptures. I *think* if we have MaxCaptures (or maybe NumCaptures) then that effectively serves the same purpose as and . I think we should probably have one or the other, while having both seems like overkill. I'm tending toward preferring the flags rather than the number. Stylistically, I would prefer over , for consistency with . Thanks, Paul From Mark.Duckworth@polycom.com Thu Feb 6 10:27:20 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947AA1A0172 for ; Thu, 6 Feb 2014 10:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mdu_TZ90X2UO for ; Thu, 6 Feb 2014 10:27:19 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 021D41A00F9 for ; Thu, 6 Feb 2014 10:27:18 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 6 Feb 2014 10:27:18 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Thu, 6 Feb 2014 10:27:16 -0800 Thread-Topic: [clue] MCC attributes composed and switching Thread-Index: Ac8jZqjUlYgUVta8QjiLa+Al0PAE5AAAgkuw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1EB@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1B7@CRPMBOXPRD07.polycom.com> <52F3CFED.7030500@alum.mit.edu> In-Reply-To: <52F3CFED.7030500@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] MCC attributes composed and switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 18:27:20 -0000 Paul, So are you suggesting we should remove the maxCaptures attribute, and add t= he composed and switched attributes? And not add numCaptures or minCapture= s? That would be okay with me. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, February 06, 2014 1:10 PM > To: clue@ietf.org > Subject: Re: [clue] MCC attributes composed and switching >=20 > On 2/6/14 12:55 PM, Duckworth, Mark wrote: > > In draft-ietf-clue-data-model-schema-03, and at the design team > > meeting Feb 4, Roberta and Simon suggested adding the and > > elements in the data model, for MCCs. This is practically > > the same as the previous composed and switched attributes we had for > > any media capture, but now restricted to use with MCCs rather than any > > individual capture. > > > > Based on other recent discussions on the list, it seems to me it is > > useful to support these optional attributes so the provider can more > > accurately indicate what it is doing. If the group agrees, I will add > > these attributes back into the framework for MCCs. >=20 > See my earlier comment today regarding MaxCaptures. >=20 > I *think* if we have MaxCaptures (or maybe NumCaptures) then that > effectively serves the same purpose as and . I thin= k > we should probably have one or the other, while having both seems like > overkill. >=20 > I'm tending toward preferring the flags rather than the number. >=20 > Stylistically, I would prefer over , for consistenc= y with > . >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Feb 6 13:01:52 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FA71A01C0 for ; Thu, 6 Feb 2014 13:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgzt-4PKs3Vc for ; Thu, 6 Feb 2014 13:01:51 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id EE8341A0133 for ; Thu, 6 Feb 2014 13:01:50 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta12.westchester.pa.mail.comcast.net with comcast id P64d1n0061HzFnQ5C91pQz; Thu, 06 Feb 2014 21:01:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id P91p1n00N3ZTu2S3a91p2M; Thu, 06 Feb 2014 21:01:49 +0000 Message-ID: <52F3F83D.9040809@alum.mit.edu> Date: Thu, 06 Feb 2014 16:01:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1B7@CRPMBOXPRD07.polycom.com> <52F3CFED.7030500@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1EB@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1EB@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391720509; bh=apmnH32IJ9kHCE39OUlgvUJRE/1jPlbNaWrhZ84uGyI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GqrrdOyUCnmTqtGOjVcMRmAHliYULquvUmNxaTZ3E3izg/BJBaPXvjfYT1aKxSk7Z R8xkp2Oa5dfSiLgV3CgUSO39lVGztzKw7m+q6mGLDduslfzRY+IDo8d/WmnIWvTaup q5YqnPFLHNJjEtHmpNJSxu9u/ybVHirDqowMPRXaeq/MvmurjFujSO3UbW7hb+89f1 MNHOnYgh4qzNbtCOavN7EBoZGtAu6yxhk7dgPW4+SBQbWYxw2JU0XdCwyUehml7+WG yDVfPDzhFbZYu1Zjtl8FXrK7Mqryn9HTfo/gIUmszcSocWCyasF5b0RRTFqkSg4wrC wKryape97fapQ== Subject: Re: [clue] MCC attributes composed and switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 21:01:52 -0000 On 2/6/14 1:27 PM, Duckworth, Mark wrote: > Paul, > > So are you suggesting we should remove the maxCaptures attribute, and add the composed and switched attributes? And not add numCaptures or minCaptures? That would be okay with me. I am *suggesting* we consider that, unless we can figure out how the number is better. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Thursday, February 06, 2014 1:10 PM >> To: clue@ietf.org >> Subject: Re: [clue] MCC attributes composed and switching >> >> On 2/6/14 12:55 PM, Duckworth, Mark wrote: >>> In draft-ietf-clue-data-model-schema-03, and at the design team >>> meeting Feb 4, Roberta and Simon suggested adding the and >>> elements in the data model, for MCCs. This is practically >>> the same as the previous composed and switched attributes we had for >>> any media capture, but now restricted to use with MCCs rather than any >>> individual capture. >>> >>> Based on other recent discussions on the list, it seems to me it is >>> useful to support these optional attributes so the provider can more >>> accurately indicate what it is doing. If the group agrees, I will add >>> these attributes back into the framework for MCCs. >> >> See my earlier comment today regarding MaxCaptures. >> >> I *think* if we have MaxCaptures (or maybe NumCaptures) then that >> effectively serves the same purpose as and . I think >> we should probably have one or the other, while having both seems like >> overkill. >> >> I'm tending toward preferring the flags rather than the number. >> >> Stylistically, I would prefer over , for consistency with >> . >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Thu Feb 6 16:45:36 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CF71A057F for ; Thu, 6 Feb 2014 16:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLpCJmeXDkmE for ; Thu, 6 Feb 2014 16:45:34 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6041A057D for ; Thu, 6 Feb 2014 16:45:33 -0800 (PST) Received: from ppp118-209-227-231.lns20.mel6.internode.on.net ([118.209.227.231]:53134 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBZZ9-000484-R2; Fri, 07 Feb 2014 11:45:11 +1100 Message-ID: <52F42CA5.2000001@nteczone.com> Date: Fri, 07 Feb 2014 11:45:25 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB14E@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB14E@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Maxcaptures in MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 00:45:36 -0000 Hello Mark, My proposed improvement is to update the MaxCaptures parameter add the possibility to indicate indicate that the value is "equal to" as well as allowing the specification as per today "less than or equal to". Regards, Christian On 7/02/2014 3:55 AM, Duckworth, Mark wrote: > Hi Christian, > > I think I understand the general idea you are getting at, but I don't understand specifically what you are proposing as an improvement. > More comments inline. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Wednesday, February 05, 2014 7:20 PM >> To: clue@ietf.org >> Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't describe >> video locations within composed MCC >> >> Hello Paul and Mark, >> >> The Max-captures attributes currently indicates the maximum number of >> captures that appears in a MCC at any particular point in time. >> >> i.e. MCC(VC1,VC2,VC3),MaxCaptures=3 >> So a Consumer has to assume because this is a maximum that VC1, VC2, VC3, >> (VC1,VC2), (VC1,VC3), (VC2,VC3) or (VC1,VC2,VC3) can appear at any point in >> time. > [Duckworth, Mark] I agree, that is consistent with framework-13. > >> However the Consumer only ever sends a composition of (VC1,VC2,VC3). It is >> never going to change that combination. > [Duckworth, Mark] Do you mean the Provider will always send a composition of (VC1,VC2,VC3)? And the provider would like to be more explicit about this in the advertisement? > >> It seems to me that in this case >> using MaxCaptures as it is currently defined is semantically incorrect. > [Duckworth, Mark] I think it is correct, but maybe not giving as much information as the provider wants to express. [CNG] I can't see its correct. If I tell you that I can do a set of behaviour but I only intend to do one then I don't think that's truthful. Sort of like telling you I'm coming to your house one day next week when in fact I only intend on coming on Friday. > >> So what I am suggesting is simply to add a way to correctly indicate this >> "constant number of captures" case, i.e. (VC1,VC2,VC3). > [Duckworth, Mark] If I understand your suggestion correctly, then one way to do that would be to add a new optional MinCaptures attribute to an MCC. MinCaptures is the minimum number of constituent captures that may appear in the MCC at a time. If this attribute is not set, then it is assumed to have the default value of 1. For this scenario, the value of both MinCaptures and MaxCaptures would be 3. Is this what you are suggesting, or do you have something else in mind? [CNG] No all I had in mind was something like: MaxCaptures "="/"<=" value The Advertiser would chose to indicate "equal" or "equal to or less than". > >> I think Paul is questioning the attribute in general. I do believe that knowing >> the number of sources may be beneficial for a consumer in deciding which >> MCC/Captures to select. There may be tradeoffs vs a MCC only showing a >> limited number (i.e. one source) at a time vs another MCC showing multiple >> sources at a time. [CNG] I agree I think its beneficial. >> >> Regards, Christian From Christian.Groves@nteczone.com Thu Feb 6 16:57:33 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721D41A0588 for ; Thu, 6 Feb 2014 16:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhRSO7QS0vpf for ; Thu, 6 Feb 2014 16:57:30 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29C51A022C for ; Thu, 6 Feb 2014 16:57:29 -0800 (PST) Received: from ppp118-209-227-231.lns20.mel6.internode.on.net ([118.209.227.231]:53245 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBZki-00060f-Sk for clue@ietf.org; Fri, 07 Feb 2014 11:57:09 +1100 Message-ID: <52F42F73.4030205@nteczone.com> Date: Fri, 07 Feb 2014 11:57:23 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> <52CB8BB9.70503@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E3E6@CRPMBOXPRD07.polycom.com> <52CF5885.2090002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4FF@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF15FFC@CRPMBOXPRD07.polycom.com> <52DC8BC8.7000204@nteczone.com> <52DD6047.4030101@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16388@CRPMBOXPRD07.polycom.com> <52DDAAF7.9020506@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF1646F@CRPMBOXPRD07.polycom.com> <52DF051B.5040809@nteczone.com> <52E00EE7.3020205@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D01E6DF@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D0F8123@CRPMBOXPRD07.polycom.com> <52E837F9.2090201@nteczone.com> <52F293FC.5080502@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FAF30@CRPMBOXPRD07.polycom.com> <52F2D518.4070801@nteczone.com> <52F3BF5F.1050509@alum.mit.edu> In-Reply-To: <52F3BF5F.1050509@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't describe video locations within composed MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 00:57:33 -0000 Hello Paul, Please see below. Regards, Christian On 7/02/2014 3:59 AM, Paul Kyzivat wrote: > On 2/5/14 7:19 PM, Christian Groves wrote: >> Hello Paul and Mark, >> >> The Max-captures attributes currently indicates the maximum number of >> captures that appears in a MCC at any particular point in time. >> >> i.e. MCC(VC1,VC2,VC3),MaxCaptures=3 >> So a Consumer has to assume because this is a maximum that VC1, VC2, >> VC3, (VC1,VC2), (VC1,VC3), (VC2,VC3) >> or (VC1,VC2,VC3) can appear at any point in time. >> >> However the Consumer only ever sends a composition of (VC1,VC2,VC3). It >> is never going to change that combination. It seems to me that in this >> case using MaxCaptures as it is currently defined is semantically >> incorrect. >> >> So what I am suggesting is simply to add a way to correctly indicate >> this "constant number of captures" case, i.e. (VC1,VC2,VC3). > > So what would happen if the advertisement was: > MCC(VC1,VC2,VC3),NumCaptures=3 > but the Configure requested MCC(V1,V2)? > > Since there are now only two captures to send, the NumCaptures is > violated. Also, what if the intent is to compose three captures from > the currently most active site, but not all the sites have three > sources. Then again, sometimes there will less than three captures > composed. > > I was thinking that the point of MaxCaptures vs. NumCaptures was to > cover those sorts of cases. [CNG] I wasn't planning a new attribute for this. Simply to update the syntax of MaxCaptures to indicate "equal to" or "equal to and less than". So this would avoid any conflict between two attributes. With regards to a configure requesting a sub-set I think we have some flexibility in what procedure we implement here. We could have the rule that if MaxCapture uses "equal to" that it means that a Consumer can't choose a sub-set. Or we could leave the rule as it is today. I think the former is probably better as it would give a means to the Advertiser to indicate "don't choose a subset". > >> I think Paul is questioning the attribute in general. I do believe that >> knowing the number of sources may be beneficial for a consumer in >> deciding which MCC/Captures to select. There may be tradeoffs vs a MCC >> only showing a limited number (i.e. one source) at a time vs another MCC >> showing multiple sources at a time. > > Originally I thought the intent was that MaxCaptures would replace the > "switched" and "composed" attributes. It could approximate those: > - if maxcaptures = 1 and #sources > 1 then "switched" > - if maxcaptures = #sources and #sources > 1 then "composed". [CNG] Yes the idea was to replace these two tags with something that could be simply or as powerful as you want it. > > In other cases, comparing MaxCaptures to the #sources can make it > clear that something else is going on. But I think it is insufficient > to understand *what* is going on in sufficient detail to make much of > a judgement about which to choose. I suspect that either this wouldn't > be used, or it would be used together with some extra "knowledge" > about how the advertiser does things. That would be bad for > interoperability. > ISTM that the "switched" and "composed" attributes will provide as > much as we can reasonably promise in an interoperable way. If we want > to do more in the future, we could consider doing detailed layouts. > But I don't want to do that now. [CNG] I don't agree. Having MaxCaptures is a part of the MCC mechanism. I see there is benefit in giving the Advertiser and the Consumer the means of knowing how many captures will appear in the stream at a time. It gives the ability for the Consumer to distinguish between MCCs. e.g. MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=2 MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=4 MCC3(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=8 If I say: MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Composed MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Composed MCC3(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Composed How do I distinguish between MCC1, MCC2 or MCC3 in this case? I can't use the spatial information because we've disallowed that. > > Thanks, > Paul > >> Regards, Christian >> >> >> >> On 6/02/2014 9:21 AM, Duckworth, Mark wrote: >>> I too am confused about Christian's suggestion for changing or >>> clarifying the maxcaptures attribute. >>> Christian, can you explain again please? >>> For now, I think I agree with Paul that there is no reason to change >>> the current description of maxcaptures. >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Wednesday, February 05, 2014 2:42 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't >>>> describe >>>> video locations within composed MCC >>>> >>>> On 1/28/14 6:06 PM, Christian Groves wrote: >>>>> Hello Mark, >>>>> >>>>> I was simply replying to Paul. I wasn't seeking to over turn any >>>>> decision on spatial parameters (not that I was aware of the >>>>> outcome of >>>>> the meeting). >>>>> >>>>> An issue was brought up several times about the maxcaptures parameter >>>>> meaning any number of sources up to a value and that this caused >>>>> uncertainty to the consumer. This parameter is independent of any >>>>> spatial parameters thus my reply to Paul. I was suggesting a >>>>> modification by apply this parameter to say "=" in addition to >>>>> "<=" to >>>>> this to solve that problem. If the Advertiser is only going to send a >>>>> MCC with a fixed number of captures then it seems to me that its >>>>> semantically incorrect t =o imply less may be sent. >>>> I'm still not entirely clear what this means. >>>> >>>> IIUC, the intent is that if the MCC has N sources, and maxcaptures (or >>>> number-of-captures) is M, then: >>>> - if N>1 and M=1 then this is a "switched" capture >>>> - if N>1 and M=N then this is a "composed" capture >>>> >>>> But - that doesn't say anything about 1>>> the >>>> cases where there are combinations of switching and composition. >>>> And of >>>> course it also doesn't deal with composition where some images are >>>> smaller >>>> than others, and overlapping that hides parts of some captures. >>>> It also doesn't deal with what will happen if the Configure selects a >>>> subset of >>>> the sources in the MCC. >>>> >>>> I see no way to deal with that with a single number. And I don't >>>> see any >>>> compelling reason to do so. >>>> >>>> The "switched" and "composed" attributes cover the two extremes, and >>>> also >>>> indicate (when both or neither are specified) that the situation is >>>> something >>>> other than one of the extremes. Does having a number improve on that? >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, Christian >>>>> >>>>> On 29/01/2014 4:20 AM, Duckworth, Mark wrote: >>>>>> Mary and Paul, could you please let us know if consensus is reached >>>>>> on this topic? >>>>>> >>>>>> At the interim meeting Jan 27, we reaffirmed the decision noted in >>>>>> Ticket #5 , meaning the >>>>>> group does not want to attempt to use CLUE to describe composed >>>>>> captures, particularly the layout of individual video images >>>>>> within a >>>>>> composed image. >>>>>> >>>>>> I think Christian is still opposed to this outcome from the interim >>>>>> meeting. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Mark >>>>>> >>>>>> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, >>>>>> Mark >>>>>> *Sent:* Wednesday, January 22, 2014 7:16 PM >>>>>> *To:* Paul Kyzivat; clue@ietf.org >>>>>> *Subject:* Re: [clue] spatial information can't describe video >>>>>> locations within composed MCC >>>>>> >>>>>> Hi Paul, >>>>>> >>>>>> Paul wrote: "Lets first discuss if having this information would >>>>>> provide significant value. If so then we can discuss how to provide >>>>>> it." >>>>>> >>>>>> Yes, but we already did that, and decided it isn't valuable >>>>>> enough to >>>>>> work on as part of CLUE. This was Ticket #5 >>>>>> . I think we should >>>>>> stick with that decision. >>>>>> >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>> Sent: Wednesday, January 22, 2014 1:33 PM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] spatial information can't describe video >>>>>> locations within >>>>>> >>>>>>> composed MCC >>>>>>> On 1/21/14 6:39 PM, Christian Groves wrote: >>>>>>>> Hello Mark, >>>>>>>> I think I know where the disconnect is between us. Its to do with >>>>>>>> the >>>>>>>> encodings. In my examples I've been assumed that Provider only >>>>>>>> provides the encoding for MCC1 not the constituent captures. >>>>>>>> Whereas >>>>>>>> you've been assuming that encodings are being provided for the >>>>>>>> individual and MCC captures. >>>>>>>> In the case of the encoding only being on the MCC the consumer >>>>>>>> knows >>>>>>>> because the VCs and MCC belong to the same Capture Scene. The >>>>>>>> Advertiser has provided the spatial positions of VC1 being left. >>>>>>>> VC2 >>>>>>>> being centre and VC3 being right. That is their position in the >>>>>> composition. >>>>>> >>>>>>> That at best seems like a hack. It is repurposing the spatial info >>>>>> of the >>>>>> >>>>>>> captures without encodings for an entirely different purpose. >>>>>>> And it doesn't work right if you want to have multiple MCCs that >>>>>> compose >>>>>> >>>>>>> the same sources differently. (Unless you introduce another layer >>>>>>> of >>>>>>> indirection, such as you do in example below. Yet another hack.) >>>>>>>> In the case of multiple encodings the spatial information >>>>>>>> associated >>>>>>>> with an individual capture is likely to be a difference between >>>>>>>> the >>>>>>>> individual encodings and the MCC encoding. >>>>>>>> So perhaps the way to address this is to allow spatial >>>>>>>> information in >>>>>>>> individual encodings in MCCs only when those individual encodings >>>>>>>> are >>>>>>> MCCs? >>>>>>>> E.g. taking your example below. >>>>>>>> Scene 1 >>>>>>>> VC1 - left >>>>>>>> VC2 - center >>>>>>>> VC3 - right >>>>>>>> MCC2(VC1) - left-composed >>>>>>>> MCC3(VC2) - center-composed >>>>>>>> MCC4(VC3) - right-composed >>>>>>>> MCC1 (MCC2,MCC3,MCC4) - whole scene, maxCaptures=3 >>>>>>>> CSE1 (VC1, VC2, VC3) >>>>>>>> CSE2 (MCC1) >>>>>>> In effect what you have now done is introduce an explicit encoding >>>>>> for the >>>>>> >>>>>>> positions of the sources of a composition. (But used an obscure and >>>>>>> confusing notation.) >>>>>>> If we really want that, then I suggest we just add syntax to the >>>>>> declaration of >>>>>> >>>>>>> the MCC to explicitly do it. >>>>>>> But I don't really see the point of doing so. What can the consumer >>>>>> do when >>>>>> >>>>>>> it has this info that it wouldn't be able to do without it? >>>>>>>> In order to address the maxCaptures issue perhaps we need to >>>>>>>> modify >>>>>>>> "MaxCaptures" slightly so that it becomes "NumberofCaptures" >>>>>>>> where we >>>>>>>> could say NumberofCaptures=3 or NumberofCaptures<=3. This would >>>>>>>> give >>>>>>>> more certainty to the Consumer about what will actually be sent. >>>>>>> That is just another step towards describing the complete layout of >>>>>>> the >>>>>>> composition. >>>>>>> Lets first discuss if having this information would provide >>>>>> significant value. If >>>>>> >>>>>>> so then we can discuss how to provide it. >>>>>>> Thanks, >>>>>>> Paul >>>>>>>> Regards, Christian >>>>>>>> On 21/01/2014 11:54 PM, Duckworth, Mark wrote: >>>>>>>>> Hello Christian, >>>>>>>>> I still don't see how the consumer can tell anything about how >>>>>>>>> an >>>>>> MCC >>>>>> >>>>>>>>> is composed. Take this example, >>>>>>>>> Scene 1 >>>>>>>>> VC1 - left >>>>>>>>> VC2 - center >>>>>>>>> VC3 - right >>>>>>>>> MCC1 (VC1, VC2, VC3) - whole scene, maxCaptures=3 >>>>>>>>> CSE1 (VC1, VC2, VC3) >>>>>>>>> CSE2 (MCC1) >>>>>>>>> Here it is useful to give spatial information for all the >>>>>>>>> captures, >>>>>>>>> so the consumer that chooses the individual captures knows they >>>>>>>>> are >>>>>>>>> spatially related. But how is the consumer supposed to know how >>>>>>>>> the >>>>>>>>> provider is composing them inside MCC1? It could be any number >>>>>>>>> of >>>>>>>>> ways, and it could be changing over time. So my cases 2 and 3 >>>>>>>>> below >>>>>>>>> apply to why the consumer can't tell how the MCC is composed. >>>>>>>>> Yet it >>>>>>>>> still makes sense for the provider to give spatial information >>>>>>>>> for >>>>>>>>> the captures themselves. >>>>>>>>> Mark >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>> Christian >>>>>>>>>> Groves >>>>>>>>>> Sent: Monday, January 20, 2014 6:02 PM >>>>>>>>>> To: clue@ietf.org >>>>>>>>>> Subject: Re: [clue] spatial information can't describe video >>>>>>>>>> locations within composed MCC >>>>>>>>>> Hello Mark and Paul, >>>>>>>>>> Please see my responses below. >>>>>>>>>> Regards, Christian >>>>>>>>>> On 21/01/2014 8:29 AM, Duckworth, Mark wrote: >>>>>>>>>>> Christian, >>>>>>>>>>> I agree with Paul. >>>>>>>>>>> Christian wrote: "I cannot see why in the static case spatial >>>>>>>>>>> information isn't >>>>>>>>>> valid? In the static case the concerns of 2, 3 and 4 don't >>>>>>>>>> apply." >>>>>>>>>>> That might be true, but how is the consumer going to know if >>>>>>>>>>> it is >>>>>>>>>>> the "static >>>>>>>>>> case" or not? I don't see any way for the consumer to know this. >>>>>>>>>> [CNG] The consumer knows this because the Provider only >>>>>>>>>> provides >>>>>> the >>>>>> >>>>>>>>>> spatial information when it makes sense to do so. >>>>>>>>>>> Mark >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>>>>>>>>> Kyzivat >>>>>>>>>>>> Sent: Monday, January 20, 2014 12:44 PM >>>>>>>>>>>> To: clue@ietf.org >>>>>>>>>>>> Subject: Re: [clue] spatial information can't describe video >>>>>>>>>>>> locations within composed MCC >>>>>>>>>>>> On 1/19/14 9:36 PM, Christian Groves wrote: >>>>>>>>>>>>> Hello Mark, >>>>>>>>>>>>> Sorry for the delayed response. I was on vacation last week. >>>>>>>>>>>>> I >>>>>>>>>>>>> see there's been quite a lot of activity over the last week >>>>>>>>>>>>> with >>>>>>>>>>>>> respect to MCCs and the framework. >>>>>>>>>>>>> I saw the minutes of the meeting and saw there was a mention >>>>>> that >>>>>> >>>>>>>>>>>>> I should argue :-). >>>>>>>>>>>>> I don't agree with the outcome of the meeting. I think its >>>>>>>>>>>>> important to note that MCC doesn't equal switching. A MCC >>>>>>>>>>>>> may >>>>>>>>>>>>> represent a dynamic switching case OR a static case. A >>>>>>>>>>>>> static >>>>>>>>>>>>> case may be that a MCU offers a single stream where three >>>>>>>>>>>>> captures from an endpoint on separate streams are composed >>>>>>>>>>>>> into >>>>>>> one video stream. >>>>>>>>>>>> Yes, we had that in mind when discussing this. >>>>>>>>>>>>> I cannot see why in the >>>>>>>>>>>>> static case spatial information isn't valid? In the static >>>>>>>>>>>>> case >>>>>>>>>>>>> the concerns of 2, 3 and 4 don't apply. >>>>>>>>>>>> We may not have understood you. We were guessing what you >>>>>>> meant. >>>>>>>>>>>> Suppose there is an MCC that has three input captures, and >>>>>>>>>>>> composes >>>>>>>>>> them. >>>>>>>>>>>> It could compose them in many ways. It could put the three >>>>>> side by >>>>>> >>>>>>>>>>>> side, or one big one and two as picture-in-picture overlays, >>>>>> or ... >>>>>> >>>>>>>>>>>> And even with three side by side, they could be in any order. >>>>>>>>>> [CNG] Yes >>>>>>>>>>>> And the source captures could all be from multiple scenes or >>>>>>>>>>>> one, >>>>>>>>>>>> and if one, it could be the same one as the MCC or not. The >>>>>>>>>>>> simplest case is that they are all from the same scene as the >>>>>> MCC. >>>>>> >>>>>>>>>>>> But even then, the coordinates of the source captures are >>>>>>>>>>>> presumably meaningful if they are individually configured. We >>>>>>>>>>>> could see no reason to presume that their arrangement in the >>>>>> scene >>>>>> >>>>>>>>>>>> has anything to do with their >>>>>>>>>> arrangement in the MCC. >>>>>>>>>> [CNG] Paul you mentioned the idea of a virtual scene before. >>>>>>>>>> What I >>>>>>>>>> see an MCU doing is creating a virtual scene using these source >>>>>>>>>> captures. >>>>>>>>>> Giving Captures spatial co-ordinates within a virtual scene is >>>>>>>>>> a >>>>>>>>>> valid thing to do irrespective of the use of a MCC. The MCU may >>>>>>>>>> apply any transformation it wants based on the source capture >>>>>>>>>> information. I think this equally applies to the MCC itself. >>>>>>>>>> Now if the MCU constructs a composed image from several sources >>>>>>>>>> using a MCC I can't see why it cannot indicate the spatial >>>>>>>>>> position >>>>>>>>>> of the sources in the MCC as they also reside in the virtual >>>>>>>>>> space. >>>>>>>>>>>> So we need more info to understand your perspective on this. >>>>>>>>>>>>> From the minutes I didn't see an explanation of other >>>>>>>>>>>>> people's >>>>>>>>>> concerns. >>>>>>>>>>>>> So rather than a complete prohibition of the spatial >>>>>>>>>>>>> information >>>>>>>>>>>>> regarding individual captures I think it would be better to >>>>>>>>>>>>> explain that the Advertiser has a choice to include the >>>>>>>>>>>>> information and that the spatial information is only >>>>>>>>>>>>> meaningful >>>>>>>>>>>>> if the individual capture's spatial information is static. >>>>>> That's >>>>>> >>>>>>>>>>>>> what I tried to capture in the text below. >>>>>>>>>>>> I already commented on this earlier. >>>>>>>>>>>> IMO the advertiser MAY provide spatial information on an MCC. >>>>>> That >>>>>> >>>>>>>>>>>> would describe a place within the scene of the MCC. IMO that >>>>>>>>>>>> is a >>>>>>>>>>>> suggestion by the advertiser, but doesn't have the same >>>>>>>>>>>> physical >>>>>>>>>>>> significance as will a non-MCC capture. >>>>>>>>>> [CNG] I don't understand why the spatial information of the MCC >>>>>>>>>> has >>>>>>>>>> less significance than a non-MCC capture? An Advertiser >>>>>>>>>> constructs >>>>>>>>>> the scene, it give the spatial positioning. If the MCC and >>>>>>>>>> non-MCC >>>>>>>>>> captures are part of the same CSE then equal weight should be >>>>>> given. >>>>>> >>>>>>>>>>>> The consumer could just use this, treating the MCC like any >>>>>>>>>>>> other >>>>>>>>>>>> capture. Or, if it is smarter, and the MCC is *switched*, it >>>>>> could >>>>>> >>>>>>>>>>>> ignore this and look into the spatial info for the source >>>>>> captures. >>>>>> >>>>>>>>>> [CNG] If the MCC is "switched" AND the spatial information >>>>>>>>>> changes >>>>>>>>>> between source captures then this would be the dynamic case. I >>>>>> think >>>>>> >>>>>>>>>> the advice is that a Advertiser shouldn't provide this >>>>>>>>>> information >>>>>>>>>> unless it also provides a means for the Consumer to determine >>>>>>>>>> when >>>>>>>>>> the switch takes place. If the MCC is "switched" and the source >>>>>>>>>> spatial information is the same then the Advertiser can simply >>>>>>>>>> supply the spatial information at the MCC level without the >>>>>>>>>> need to >>>>>>>>>> set it on the sources. >>>>>>>>>>>> But none of that has anything to do with the the arrangement >>>>>>>>>>>> of >>>>>>>>>>>> composed captures within an MCC. >>>>>>>>>> [CNG] I don't understand the point. You only focused on the >>>>>> switched >>>>>> >>>>>>>>>> case. >>>>>>>>>> MCC is for switching and composition. >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Paul >>>>>>>>>>>>> Regards, Christian >>>>>>>>>>>>> On 18/01/2014 9:50 AM, Duckworth, Mark wrote: >>>>>>>>>>>>>> We discussed this topic in the design team meeting Jan 14 >>>>>> >>>>> >>>>>>>>>>>> Team/minutes_140114.txt>. >>>>>>>>>>>>>> From the minutes: >>>>>>>>>>>>>> "Conclusion 1: Spatial information of the individual >>>>>>>>>>>>>> captures >>>>>>>>>>>>>> does not apply inside a composed MCC." >>>>>>>>>>>>>> We wanted to bring this topic back to the list to make sure >>>>>>>>>>>>>> we >>>>>>>>>>>>>> have consensus before clarifying the framework about this. >>>>>>>>>>>>>> Christian, or anybody else, do you still want more >>>>>>>>>>>>>> discussion? >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Mark >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>>>>>> Duckworth, Mark >>>>>>>>>>>>>>> Sent: Friday, January 10, 2014 4:04 PM >>>>>>>>>>>>>>> To: Christian Groves; clue@ietf.org >>>>>>>>>>>>>>> Subject: Re: [clue] spatial information can't describe >>>>>>>>>>>>>>> video >>>>>>>>>>>>>> locations within >>>>>>>>>>>>>>> composed MCC >>>>>>>>>>>>>>> Thanks Christian, that is an improvement. But I'm still >>>>>>>>>>>>>>> not >>>>>>>>>>>>>> convinced the >>>>>>>>>>>>>>> consumer can always tell when the spatial attributes are >>>>>>>>>>>>>>> meaningful >>>>>>>>>>>>>> (even >>>>>>>>>>>>>>> within a scene) for discerning how contributors to a >>>>>>>>>>>>>>> composed >>>>>>>>>>>>>>> MCC are arranged within the MCC. My concerns 2, 3, and 4 >>>>>>>>>>>>>>> below >>>>>>>>>>>>>>> still apply. >>>>>>>>>>>>>>> Does anybody else have input to this topic? >>>>>>>>>>>>>>> Mark >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: Christian Groves >>>>>>>>>>>>>>>> [mailto:Christian.Groves@nteczone.com] >>>>>>>>>>>>>>>> Sent: Thursday, January 09, 2014 9:19 PM >>>>>>>>>>>>>>>> To: Duckworth, Mark; clue@ietf.org >>>>>>>>>>>>>>>> Subject: Re: [clue] spatial information can't describe >>>>>>>>>>>>>>>> video >>>>>>>>>>>>>> locations >>>>>>>>>>>>>>>> within composed MCC >>>>>>>>>>>>>>>> Hello Mark, >>>>>>>>>>>>>>>> How about something like the following? >>>>>>>>>>>>>>>> 7.2.1. MCC Attributes >>>>>>>>>>>>>>>> Attributes may be associated with the MCC instance and >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> Single Media Captures that the MCC references. A provider >>>>>>>>>>>>>>>> should avoid providing conflicting attribute values >>>>>>>>>>>>>>>> between >>>>>>>>>>>>>>>> the MCC and Single Media Captures. Where there is >>>>>>>>>>>>>>>> conflict >>>>>> the >>>>>> >>>>>>>>>>>>>>>> attributes of the MCC override any that may be present in >>>>>>>>>>>>>>>> the >>>>>>> individual captures. >>>>>>>>>>>>>>>> <>>>>>>>>>>>>>>> captures >>>>>>>>>>>>>>>> within a MCC and/or to the MCC itself the Provider should >>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>> aware that spatial attributes have no relation across >>>>>>>>>>>>>>>> Capture >>>>>>> Scenes. >>>>>>>>>>>>>>>> Therefore >>>>>>>>>>>>>>>> if the Provider intends to provide a spatial relation >>>>>>>>>>>>>>>> between >>>>>>>>>>>>>>>> the source Captures and the MCC then these MUST be part >>>>>>>>>>>>>>>> of >>>>>>> the >>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>> Capture Scene. >>>>>>>>>>>>>>>> When assigning spatial information that would cause the >>>>>>>>>>>>>>>> spatial positioning of the source Capture to move within >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> MCC, the >>>>>>>>>>>>>> Provider >>>>>>>>>>>>>>>> should also be aware that a Consumer may not be able to >>>>>>>>>>>>>>>> determine >>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> the source captures have moved.>> ... >>>>>>>>>>>>>>>> Regards, Christian >>>>>>>>>>>>>>>> On 8/01/2014 12:18 AM, Duckworth, Mark wrote: >>>>>>>>>>>>>>>>> Hello Christian, >>>>>>>>>>>>>>>>> So there are only certain circumstances in which spatial >>>>>>>>>>>>>> information >>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> components of a composed capture is relevant. For the >>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>>> where you think it is important and relevant, can you >>>>>>>>>>>>>>>> please >>>>>>>>>>>>>>>> propose text for the framework to describe this? I think >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> framework should be more clear about when and how the >>>>>>> consumer >>>>>>>>>>>>>>>> can use >>>>>>>>>> this >>>>>>>>>>>>>>>> information for composed captures. >>>>>>>>>>>>>>>>> Mark >>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>>>>>>>>> Christian Groves >>>>>>>>>>>>>>>>>> Sent: Tuesday, January 07, 2014 12:08 AM >>>>>>>>>>>>>>>>>> To: clue@ietf.org >>>>>>>>>>>>>>>>>> Subject: Re: [clue] spatial information can't describe >>>>>> video >>>>>> >>>>>>>>>>>>>>>>>> locations within composed MCC Hello Mark, I agree with >>>>>>>>>>>>>>>>>> respect to the fact that spatial information isn't >>>>>>>>>>>>>>>>>> valid >>>>>>>>>>>>>>>>>> across Capture Scenes. i.e. If I have an MCC in one >>>>>>>>>>>>>> Cap.Scene >>>>>>>>>>>>>>>>>> referencing individual captures from other scenes. >>>>>> However I >>>>>> >>>>>>>>>>>>>>>>>> think there is a valid case where an MCC can reference >>>>>>>>>>>>>>>>>> Individual captures from the same scene as it. In this >>>>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>>>>> I think the >>>>>>>>>>>>>> use of >>>>>>>>>>>>>>>>>> spatial >>>>>>>>>>>>>>>> information is valid, i.e. >>>>>>>>>>>>>>>>>> +-----------------------+---------------------------------+ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> | Capture Scene #1 | | >>>>>>>>>>>>>>>>>> +-----------------------|---------------------------------+ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> | VC1 | CapArea=Left | >>>>>>>>>>>>>>>>>> | VC2 | CapArea=Right | >>>>>>>>>>>>>>>>>> | MCC1(VC1, VC2) | | >>>>>>>>>>>>>>>>>> +---------------------------------------------------------+ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>>> +-----------------------+---------------------------------+ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> | Capture Scene #1 | | >>>>>>>>>>>>>>>>>> +-----------------------|---------------------------------+ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> | MCC1(VC1) | CapArea=Left | >>>>>>>>>>>>>>>>>> | MCC2(VC2) | CapArea=Right | >>>>>>>>>>>>>>>>>> | MCC1(MCC1,MCC2) | | >>>>>>>>>>>>>>>>>> +---------------------------------------------------------+ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> where VC1 and VC2 are from different Capture Scenes. >>>>>>>>>>>>>>>>>> There are of course cases where the spatial information >>>>>>>>>>>>>> wouldn't be >>>>>>>>>>>>>>>>>> valid but in those cases the Provider wouldn't provide >>>>>> them, >>>>>> >>>>>>>>>>>>>>>>>> i.e. >>>>>>>>>>>>>>>>>> where the individual captures move. However there will >>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>> cases where the composition is static and the >>>>>>>>>>>>>>>>>> information >>>>>>>>>>>>>>>>>> would be >>>>>>>>>>>>>> valid. >>>>>>>>>>>>>>>>>> I don't think we can make a general assumption that the >>>>>>>>>>>>>>>>>> spatial information is >>>>>>>>>>>>>>>> valid or invalid in all cases. >>>>>>>>>>>>>>>>>> Regards, Christian >>>>>>>>>>>>>>>>>> On 7/01/2014 7:54 AM, Duckworth, Mark wrote: >>>>>>>>>>>>>>>>>>> Framework version 13 says a provider can use spatial >>>>>>>>>>>>>>>>>>> information of source media captures to describe how >>>>>>>>>>>>>>>>>>> those >>>>>>>>>>>>>>>>>>> sources are placed within a composed multiple content >>>>>>>>>>>>>>>>>>> capture (MCC). In general I think this won't work, and >>>>>>>>>>>>>>>>>>> I'm >>>>>>>>>>>>>>>>>>> not even sure under what specific conditions it might >>>>>> work. >>>>>> >>>>>>>>>>>>>>>>>>> So I propose removing that part, and instead add text >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> say the spatial information of individual captures >>>>>>>>>>>>>>>>>>> does >>>>>> not >>>>>> >>>>>>>>>>>>>>>>>>> relate to its relative position within a >>>>>>>>>>>>>> composed >>>>>>>>>>>>>>> MCC. >>>>>>>>>>>>>>>>>>> From section 7.2.1: >>>>>>>>>>>>>>>>>>> For example: The spatial related attributes can be >>>>>>>>>>>>>>>>>>> further >>>>>>>>>>>>>> used to >>>>>>>>>>>>>>>>>>> determine how the individual captures "appear" within >>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>> stream. A virtual scene could be constructed for the >>>>>>>>>>>>>>>>>>> MCC >>>>>>>>>>>>>>>>>>> capture with two Video Captures with a "MaxCaptures" >>>>>>>>>>>>>>>>>>> attribute set to 2 and an "Area of Capture" attribute >>>>>>>>>>>>>>>>>>> provided with an overall area. >>>>>>>>>>>>>> Each of >>>>>>>>>>>>>>>>>>> the individual Captures could then also include an >>>>>> "Area of >>>>>> >>>>>>>>>>>>>> Capture" >>>>>>>>>>>>>>>>>>> attribute with a sub-set of the overall area. The >>>>>>>>>>>>>>>>>>> Consumer >>>>>>>>>>>>>>>>>>> would then know the relative position of the content >>>>>>>>>>>>>>>>>>> in >>>>>> the >>>>>> >>>>>>>>>>>>>>>>>>> composed >>>>>>>>>>>>>>> stream. >>>>>>>>>>>>>>>>>>> Here are some reasons why I think this will generally >>>>>>>>>>>>>>>>>>> not >>>>>>> work: >>>>>>>>>>>>>>>>>>> 1.The spatial information for captures is relevant >>>>>>>>>>>>>>>>>>> only in >>>>>>>>>>>>>>>>>>> relation to the capture scene to which the captures >>>>>> belong. >>>>>> >>>>>>>>>>>>>>>>>>> Spatial information from different scenes has no >>>>>>>>>>>>>>>>>>> relation >>>>>>>>>>>>>>>>>>> to each other. So if the individual captures that are >>>>>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>>>> of a composed MCC come from different scenes >>>> (source >>>>>>>>>>>>>>>>>>> captures >>>>>>>>>> from >>>>>>>>>>>>>>>>>>> multiple scenes, or source captures from different >>>>>>>>>>>>>>>>>>> scenes >>>>>>>>>>>>>>>>>>> than the >>>>>>>>>>>>>>>>>>> MCC) >>>>>>>>>>>>>>>>>>> then the spatial information of one capture has no >>>>>> relation >>>>>> >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> spatial information of another capture. >>>>>>>>>>>>>>>>>>> 2.In the example with MaxCaptures = 2, that doesn't >>>>>>>>>>>>>>>>>>> mean >>>>>>>>>>>>>>>>>>> there will always be 2 contributing captures in the >>>>>> MCC. It >>>>>> >>>>>>>>>>>>>>>>>>> just means maximum of 2, but sometimes there could >>>> be 1. >>>>>>>>>>>>>>>>>>> The contents of the MCC could actually be changing >>>>>>>>>>>>>>>>>>> over >>>>>>>>>>>>>>>>>>> time between 1 and 2 >>>>>>>>>>>>>>> contributing captures. >>>>>>>>>>>>>>>>>>> If it changes between one full screen source image to >>>>>>>>>>>>>>>>>>> two >>>>>>>>>>>>>>>>>>> source images side by side, then the spatial >>>>>>>>>>>>>>>>>>> information >>>>>>>>>>>>>>>>>>> wouldn't always indicate the location of the source >>>>>>>>>>>>>>>>>>> within >>>>>>>>>>>>>>>>>>> the MCC. We have no >>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>>>> for the provider to advertise this level of detail, >>>>>>>>>>>>>>>>>>> and I >>>>>>>>>>>>>>>>>>> don't think we want to get into this detail in >>>>>>>>>>>>>>>>>>> provider >>>>>>>>>>>>>>>>>>> advertisements. >>>>>>>>>>>>>>>>>>> 3.Similarly, the MCC could always contain both >>>>>>>>>>>>>>>>>>> individual >>>>>>>>>>>>>>>>>>> captures, but maybe it is a large image of the one >>>>>>>>>>>>>>>>>>> that is >>>>>>>>>>>>>> talking >>>>>>>>>>>>>>>>>>> and a small image of the other. This would change over >>>>>>>>>>>>>>>>>>> time, so again the spatial information wouldn't always >>>>>>>>>>>>>>>>>>> indicate the location of the source within the MCC. >>>>>>>>>>>>>>>>>>> 4.Take a slightly different example, where the MCC >>>>>> contains >>>>>> >>>>>>>>>>>>>>>>>>> 4 contributing individual captures, but still with >>>>>>>>>>>>>>>>>>> MaxCaptures = 2. >>>>>>>>>>>>>>>>>>> So the resulting MCC again will change over time, as >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> provider is free to choose which 2 out of the 4 to >>>>>>>>>>>>>>>>>>> include >>>>>>>>>>>>>>>>>>> at any time. So again the spatial information wouldn't >>>>>>>>>>>>>>>>>>> always indicate the location of the source within the >>>> MCC. >>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>> Mark >>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>>>>>>>> clue@ietf.org >>>>>> >>>>>> >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>>>>>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> clue mailing list >>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> clue mailing list >>>>>>>>>>> clue@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>> _______________________________________________ >>>>>>>>>> clue mailing list >>>>>>>>>> clue@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>> _______________________________________________ >>>>>>>> clue mailing list >>>>>>>> clue@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Thu Feb 6 16:58:51 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8E41A058B for ; Thu, 6 Feb 2014 16:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bROWrxPS7iPd for ; Thu, 6 Feb 2014 16:58:50 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CA81A022C for ; Thu, 6 Feb 2014 16:58:50 -0800 (PST) Received: from ppp118-209-227-231.lns20.mel6.internode.on.net ([118.209.227.231]:53249 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBZm1-0006C9-IS for clue@ietf.org; Fri, 07 Feb 2014 11:58:29 +1100 Message-ID: <52F42FC4.5070104@nteczone.com> Date: Fri, 07 Feb 2014 11:58:44 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16009@CRPMBOXPRD07.polycom.com> <52DC8BFC.6050705@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1BE@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1BE@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] should be optional X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 00:58:51 -0000 Yes, Christian On 7/02/2014 5:00 AM, Duckworth, Mark wrote: > I see is still mandatory in data-model-schema-03. Does the rest of the group agree we should change this to optional? > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Sunday, January 19, 2014 9:38 PM >> To: clue@ietf.org >> Subject: Re: [clue] should be optional >> >> Hello Mark, >> >> I agree. >> >> Regards, >> Christian >> >> On 18/01/2014 9:57 AM, Duckworth, Mark wrote: >>> In the data model section 10.4, in "spatialInformationType", the >>> "capturePoint" element is mandatory. It really should be optional. In >>> earlier versions of the framework it was optional. This is described >>> in section 10.4.1: "If the point of capture is not specified, it means >>> the consumer should not assume anything about the spatial location of >>> the capturing device." >>> >>> So I think the schema should have minOccurs="0" for "capturePoint" >>> element. And the text right below the schema part should say optional >>> instead of mandatory. >>> >>> Mark >>> >>> >>> >>> _______________________________________________ >>> 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 Thu Feb 6 17:01:35 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EF61A0586 for ; Thu, 6 Feb 2014 17:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaqbLhcPJSr7 for ; Thu, 6 Feb 2014 17:01:34 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE9A1A022C for ; Thu, 6 Feb 2014 17:01:34 -0800 (PST) Received: from ppp118-209-227-231.lns20.mel6.internode.on.net ([118.209.227.231]:53259 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBZof-0006a8-TW for clue@ietf.org; Fri, 07 Feb 2014 12:01:14 +1100 Message-ID: <52F43068.7020700@nteczone.com> Date: Fri, 07 Feb 2014 12:01:28 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1B7@CRPMBOXPRD07.polycom.com> <52F3CFED.7030500@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB1EB@CRPMBOXPRD07.polycom.com> <52F3F83D.9040809@alum.mit.edu> In-Reply-To: <52F3F83D.9040809@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] MCC attributes composed and switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 01:01:36 -0000 I agree that having both is overkill. I believe that MaxCaptures is a better approach as it better allows an Advertiser and Consumer to distinguish between offered MCCs. Regards, Christian On 7/02/2014 8:01 AM, Paul Kyzivat wrote: > On 2/6/14 1:27 PM, Duckworth, Mark wrote: >> Paul, >> >> So are you suggesting we should remove the maxCaptures attribute, and >> add the composed and switched attributes? And not add numCaptures or >> minCaptures? That would be okay with me. > > I am *suggesting* we consider that, unless we can figure out how the > number is better. > > Thanks, > Paul > >> Mark >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: Thursday, February 06, 2014 1:10 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] MCC attributes composed and switching >>> >>> On 2/6/14 12:55 PM, Duckworth, Mark wrote: >>>> In draft-ietf-clue-data-model-schema-03, and at the design team >>>> meeting Feb 4, Roberta and Simon suggested adding the and >>>> elements in the data model, for MCCs. This is practically >>>> the same as the previous composed and switched attributes we had for >>>> any media capture, but now restricted to use with MCCs rather than any >>>> individual capture. >>>> >>>> Based on other recent discussions on the list, it seems to me it is >>>> useful to support these optional attributes so the provider can more >>>> accurately indicate what it is doing. If the group agrees, I will add >>>> these attributes back into the framework for MCCs. >>> >>> See my earlier comment today regarding MaxCaptures. >>> >>> I *think* if we have MaxCaptures (or maybe NumCaptures) then that >>> effectively serves the same purpose as and . I >>> think >>> we should probably have one or the other, while having both seems like >>> overkill. >>> >>> I'm tending toward preferring the flags rather than the number. >>> >>> Stylistically, I would prefer over , for >>> consistency with >>> . >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Thu Feb 6 17:24:18 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA6B1A059F for ; Thu, 6 Feb 2014 17:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdD9lERLV-wS for ; Thu, 6 Feb 2014 17:24:16 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D51E1A059D for ; Thu, 6 Feb 2014 17:24:16 -0800 (PST) Received: from ppp118-209-227-231.lns20.mel6.internode.on.net ([118.209.227.231]:53369 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBaAd-0001OA-D5 for clue@ietf.org; Fri, 07 Feb 2014 12:23:55 +1100 Message-ID: <52F435BA.3030607@nteczone.com> Date: Fri, 07 Feb 2014 12:24:10 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> In-Reply-To: <52F3C79E.7010903@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 01:24:18 -0000 Hello Paul, Please see below. Regards, Christian On 7/02/2014 4:34 AM, Paul Kyzivat wrote: > I just realized I had missed this reply. See inline. > > On 1/27/14 10:33 PM, Christian Groves wrote: >> Hello Paul, >> >> Please see below. >> >> Regards, Christian >> >> On 28/01/2014 10:06 AM, Paul Kyzivat wrote: >>> * The problem: >>> >>> As we discussed in the interim today, it seems unclear what a consumer >>> should do when receiving an advertisement with multiple scenes in >>> order to get a sufficient representation of the advertised content. >>> >>> Our simple cases have been where there is one scene for the cameras in >>> the room, and another scene for a presentation. In that case, one >>> should take something from each scene (typically one CSE from each) to >>> get "enough". >>> >>> That is also true if an MCU acted in "pass through" mode and simply >>> included "copies" of all the scenes it receives in advertisements, >>> with encodings for them all. >>> >>> In a "simple" case with an MCU use MCC, it might "pass through" all >>> the advertisements it receives, for their spatial info, but not >>> provide any encodings for them. Rather, it would provide one or more >>> new scenes using MCC to aggregate those sources. Then one would not >>> want to configure from the "pass through" scenes, but that isn't an >>> option anyway if there are no encodings for them. >> [CNG] The idea of the pass through information was that the consumer >> could use any capture attribute (not just spatial ones) to determine >> what media it wanted. > > Clearly if there are no encodings, then the captures are there only > for information and can't be configured. > > That is why I called this the "simple" case. > >>> Mark has proposed using multiple scenes with MCC to illustrate >>> switched cases where some groupings don't have any spatial >>> relationship to one another. Some of those examples end up with >>> multiple scenes that do have encodings, where it doesn't make sense to >>> configure something from each scene. >> [CNG] I don't think there's anything in the framework that says a >> consumer must choose a capture from a scene. > > Of course there is no MUST. The consumer isn't required take *anything*. > > The question is how the consumer knows what is required to have a > "complete" representation of what is in the advertisement. It may not > want all that, but it is hard to make a good choice without knowing. > > That is the point of CSEs - for the advertiser to indicate what it > considers to be good alternative choices. But CSEs only work within a > scene. Once there are multiple scenes, the consumer has less guidance > on what would be good (or sufficient) choices. > > The consumer has *some* information: > - if none of the captures in a scene have encodings, then there is > no need (or way) to select them directly > > - if MCC M in scene X references capture C in scene Y, then it > would be redundant to configure both M and C > > ISTM that one should start out assuming that you need all captures > (that have encodings) in *some* CSE from *each* scene. You can then > prune that based on the logic above. But is that *enough* to make good > decisions? At best, the logic to figure that out is complex. [CNG] The above is probably a valid assumption. I think ultimately a Consumer chooses the scene because of the content. > >>> Today we discussed using priority to solve this, but this isn't really >>> a priority problem, it is a problem of *alternatives* that may be >>> equally desirable, depending on the resources or desires of the >>> consumer. >> [CNG] I agree I don't think priority is the right solution for this. >>> >>> IMO the problem is that our CSE mechanism is a way for the advertiser >>> to suggest alternatives, but this only works on a per-scene basis. The >>> advertiser has no comparable mechanism to suggest alternatives from >>> different scenes. >>> >>> * My proposed solution: >>> >>> I want to restate a proposal I made a long time ago: >>> >>> Instead of one CSE list per scene, have one CSE list >>> per-advertisement, referencing captures from any scene. >>> >>> This makes it possible for the advertiser to recommend combinations >>> that cross scene boundaries. >> [CNG] Perhaps you could give some examples? Does the list need to be >> exhaustive? > > Does the CSE list in a scene have to be exhaustive? > > I think each entry should be "sufficient" for somebody that can't > handle a bigger one. The definition of "sufficient" is subjective. [CNG] A Scene Level CSE only specifies the alternate representations for that scene. No sufficient or exhaustive just what it can support. > >> e.g. the simple case today >> Scene1 CSE1(VC1,VC2,VC3) >> CSE2(VC4) >> Scene2 CSE3(VC5,presentation1) [CNG] Is in fact exhaustive because it basically implies the combinations I listed below. >> >> Does it mean now the Advertisement would now have to advertise? >> CSE1(VC1,VC2,VC3,VC5) >> CSE2(VC4,VC5) >> CSE3(VC1,VC2,VC3) >> CSE4(VC4) >> CSE5(VC5) > > As I said, the definition of "sufficient" is subjective. > IMO the advertisement ought to include at least CSE1,CSE2. [CNG] My point wasn't about "sufficient" it was about matching the expressive power that we have today. The combinatorial issue becomes worse with the more Scenes that you have. If we go down this track it may be better to indicate which scenes go together rather than CSEs. > > Rather than include the others, I think I would adjust the priorities > of the individual captures based on my judgement of which I think > should be kept if they all can't be. > > Thanks, > Paul > >>> * An alternate solution: >>> >>> Another possibility would be to leave CSEs as they are, but add >>> something analogous to a CSE list, but that lists recommended >>> combinations of scenes. >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Thu Feb 6 20:49:45 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9001A05A1 for ; Thu, 6 Feb 2014 20:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmw3lXuI9BcT for ; Thu, 6 Feb 2014 20:49:43 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04DB1A0357 for ; Thu, 6 Feb 2014 20:49:42 -0800 (PST) Received: from ppp118-209-227-231.lns20.mel6.internode.on.net ([118.209.227.231]:56117 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WBdNO-0007iO-Q4 for clue@ietf.org; Fri, 07 Feb 2014 15:49:18 +1100 Message-ID: <52F465DF.10702@nteczone.com> Date: Fri, 07 Feb 2014 15:49:35 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB14E@CRPMBOXPRD07.polycom.com> <52F42CA5.2000001@nteczone.com> In-Reply-To: <52F42CA5.2000001@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Maxcaptures in MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 04:49:45 -0000 Hello Mark, To be more concrete here's the text I would propose for the framework: 7.2.1.1. Maximum Number of Captures within a MCC The Maximum Number of Captures MCC attribute indicates the maximum number of individual captures that may appear in a Capture Encoding at a time. <>> the actual number at any given time can be less than this maximum. It may be used to derive how the Single Media Captures within the MCC are composed / switched with regards to space and time. <> Max Captures MAY be set to one so that only content related to one of the sources are shown in the MCC Capture Encoding at a time or it may be set to any value up to the total number of Source Media Captures in the MCC. If this attribute is not set then as default it is assumed that <> can appear concurrently in the Capture Encoding associated with the MCC. For example: The use of MaxCaptures equal to 1 on a MCC with three Video Captures VC1, VC2 and VC3 would indicate that the Advertiser in the capture encoding would switch between VC1, VC2 or VC3 as there may be only a maximum of one capture at a time. Regards, Christian On 7/02/2014 11:45 AM, Christian Groves wrote: > Hello Mark, > > My proposed improvement is to update the MaxCaptures parameter add the > possibility to indicate indicate that the value is "equal to" as well > as allowing the specification as per today "less than or equal to". > > Regards, Christian > > On 7/02/2014 3:55 AM, Duckworth, Mark wrote: >> Hi Christian, >> >> I think I understand the general idea you are getting at, but I don't >> understand specifically what you are proposing as an improvement. >> More comments inline. >> >> Mark >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >>> Sent: Wednesday, February 05, 2014 7:20 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't >>> describe >>> video locations within composed MCC >>> >>> Hello Paul and Mark, >>> >>> The Max-captures attributes currently indicates the maximum number of >>> captures that appears in a MCC at any particular point in time. >>> >>> i.e. MCC(VC1,VC2,VC3),MaxCaptures=3 >>> So a Consumer has to assume because this is a maximum that VC1, VC2, >>> VC3, >>> (VC1,VC2), (VC1,VC3), (VC2,VC3) or (VC1,VC2,VC3) can appear at any >>> point in >>> time. >> [Duckworth, Mark] I agree, that is consistent with framework-13. >> >>> However the Consumer only ever sends a composition of (VC1,VC2,VC3). >>> It is >>> never going to change that combination. >> [Duckworth, Mark] Do you mean the Provider will always send a >> composition of (VC1,VC2,VC3)? And the provider would like to be more >> explicit about this in the advertisement? >> >>> It seems to me that in this case >>> using MaxCaptures as it is currently defined is semantically incorrect. >> [Duckworth, Mark] I think it is correct, but maybe not giving as much >> information as the provider wants to express. > [CNG] I can't see its correct. If I tell you that I can do a set of > behaviour but I only intend to do one then I don't think that's > truthful. Sort of like telling you I'm coming to your house one day > next week when in fact I only intend on coming on Friday. >> >>> So what I am suggesting is simply to add a way to correctly indicate >>> this >>> "constant number of captures" case, i.e. (VC1,VC2,VC3). >> [Duckworth, Mark] If I understand your suggestion correctly, then one >> way to do that would be to add a new optional MinCaptures attribute >> to an MCC. MinCaptures is the minimum number of constituent captures >> that may appear in the MCC at a time. If this attribute is not set, >> then it is assumed to have the default value of 1. For this >> scenario, the value of both MinCaptures and MaxCaptures would be 3. >> Is this what you are suggesting, or do you have something else in mind? > [CNG] No all I had in mind was something like: > MaxCaptures "="/"<=" value > The Advertiser would chose to indicate "equal" or "equal to or > less than". >>> I think Paul is questioning the attribute in general. I do believe >>> that knowing >>> the number of sources may be beneficial for a consumer in deciding >>> which >>> MCC/Captures to select. There may be tradeoffs vs a MCC only showing a >>> limited number (i.e. one source) at a time vs another MCC showing >>> multiple >>> sources at a time. > [CNG] I agree I think its beneficial. >>> >>> Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Fri Feb 7 04:13:00 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C76B1A0605 for ; Fri, 7 Feb 2014 04:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1ogW98zmhKJ for ; Fri, 7 Feb 2014 04:12:58 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id EB4571A0398 for ; Fri, 7 Feb 2014 04:12:57 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-94-52f4cdc9a0c7 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id FE.40.04249.9CDC4F25; Fri, 7 Feb 2014 13:12:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Fri, 7 Feb 2014 13:12:56 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft new version: draft-holmberg-clue-datachannel-01 Thread-Index: Ac8j/b3fWVgMoVOPRmi4Z2O6oFTWFA== Date: Fri, 7 Feb 2014 12:12:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D161D2C@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_7594FB04B1934943A5C02806D1A2204B1D161D2CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvje7Js1+CDO6uF7HYf+oyswOjx5Il P5kCGKO4bFJSczLLUov07RK4Mq7d2MtU8EC84vG2zSwNjH9Euhg5OSQETCRWXfnLDmGLSVy4 t56ti5GLQ0jgCKPElIcL2CGcRYwSN88fZOxi5OBgE7CQ6P6nDdIgIqAscXRzPxuILSxgJ3F8 6jUmiLizRH/7R0YIW09i4u5LYAtYBFQkFv/byAJi8wr4SqzpnAtmMwIt/n5qDVgvs4C4xK0n 85kgDhKQWLLnPDOELSrx8vE/VghbUWLn2XZmiPp8iXOz70LNFJQ4OfMJywRGoVlIRs1CUjYL SRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxchRnFqclJtuZLCJERj4B7f8ttjBePmv zSFGaQ4WJXHej2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwyjOc+RRQEzVVKPvc++Nn 93M+keM9urtM9+YWoTvn3njM3Bw0J+Sl02vej8xrj3/8NPVvTnmS2cPFjdo977gO7Tkau9Tn 7rR7/78+u9X/1XHp7uCOgP3rU0/knbFQWvbXj/ey5Y22d2qZs9htTudfcdzkuvj8E17jjksi d204ngh90JvNqDX3+z4lluKMREMt5qLiRADSV/D5SgIAAA== Subject: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 12:13:00 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D161D2CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the discussions on the CLUE- and RTCWEB lists, I've submitted a ne= w version of the CLUE data channel draft. There are still open issue, and I have probably not implemented everyone's = change wishes. It is more to add some more meat, and continue the discussio= ns. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D161D2CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the discussions on the CLUE- and RTCWEB lis= ts, I’ve submitted a new version of the CLUE data channel draft.=

 

There are still open issue, and I have probably not = implemented everyone’s change wishes. It is more to add some more mea= t, and continue the discussions.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D161D2CESESSMB209erics_-- From Mark.Duckworth@polycom.com Fri Feb 7 08:27:00 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF921A04F5 for ; Fri, 7 Feb 2014 08:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auS4-_6n9jzt for ; Fri, 7 Feb 2014 08:26:56 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 346351AC82A for ; Fri, 7 Feb 2014 08:26:56 -0800 (PST) Received: from PWEHUB01.polycom.com (10.236.2.221) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 7 Feb 2014 08:26:56 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 7 Feb 2014 08:26:55 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 7 Feb 2014 08:26:53 -0800 Thread-Topic: [clue] Maxcaptures in MCC, vs. switched and composed attributes Thread-Index: Ac8kIPR9rZY7JBRNTY+C//YyX/pNeQ== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB54F@CRPMBOXPRD07.polycom.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] Maxcaptures in MCC, vs. switched and composed attributes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 16:27:00 -0000 I'm trying to summarize a couple of related proposals here. 1. Add ability for advertiser to indicate if the number of captures in an M= CC at any given time will always be equal to MaxCaptures, or if it can be l= ess. Details below from Christian. 2. Add Switched and Composed attributes to MCC, just like we used to have f= or all captures. This is proposed in draft-ietf-clue-data-model-schema-03.= Maybe remove the MaxCaptures attribute if we add switched and composed. We can do one or the other, or both, or neither. Any of those choices is o= kay with me, I personally have no strong argument either way. I think other= s in the group have stronger preferences. I think the default is to do nei= ther, unless there is consensus to change. Please continue the discussion = so we can figure out if any change is needed in the framework and data mode= l. Regards, Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Thursday, February 06, 2014 11:50 PM > To: clue@ietf.org > Subject: Re: [clue] Maxcaptures in MCC >=20 > Hello Mark, >=20 > To be more concrete here's the text I would propose for the framework: >=20 > 7.2.1.1. Maximum Number of Captures within a MCC >=20 > The Maximum Number of Captures MCC attribute indicates the maximum > number of individual captures that may appear in a Capture Encoding > at a time. <>> the actual > number at any given time can be less than > this maximum. It may be used to derive how the Single Media > Captures within the MCC are composed / switched with regards to > space and time. < is equal > to the maximum the Consumer MUST not choose a subset of captures > from the MCC in a > Configure message.>> >=20 > Max Captures MAY be set to one so that only content related to one > of the sources are shown in the MCC Capture Encoding at a time or > it may be set to any value up to the total number of Source Media > Captures in the MCC. >=20 > If this attribute is not set then as default it is assumed that < of sources>> > can appear concurrently in the Capture Encoding associated with the M= CC. >=20 > For example: The use of MaxCaptures equal to 1 on a MCC with three > Video Captures VC1, VC2 and VC3 would indicate that the Advertiser > in the capture encoding would switch between VC1, VC2 or VC3 as > there may be only a maximum of one capture at a time. >=20 > Regards, Christian >=20 > On 7/02/2014 11:45 AM, Christian Groves wrote: > > Hello Mark, > > > > My proposed improvement is to update the MaxCaptures parameter add > the > > possibility to indicate indicate that the value is "equal to" as well > > as allowing the specification as per today "less than or equal to". > > > > Regards, Christian > > > > On 7/02/2014 3:55 AM, Duckworth, Mark wrote: > >> Hi Christian, > >> > >> I think I understand the general idea you are getting at, but I don't > >> understand specifically what you are proposing as an improvement. > >> More comments inline. > >> > >> Mark > >> > >>> -----Original Message----- > >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >>> Groves > >>> Sent: Wednesday, February 05, 2014 7:20 PM > >>> To: clue@ietf.org > >>> Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't > >>> describe video locations within composed MCC > >>> > >>> Hello Paul and Mark, > >>> > >>> The Max-captures attributes currently indicates the maximum number > >>> of captures that appears in a MCC at any particular point in time. > >>> > >>> i.e. MCC(VC1,VC2,VC3),MaxCaptures=3D3 > >>> So a Consumer has to assume because this is a maximum that VC1, VC2, > >>> VC3, (VC1,VC2), (VC1,VC3), (VC2,VC3) or (VC1,VC2,VC3) can appear at > >>> any point in time. > >> [Duckworth, Mark] I agree, that is consistent with framework-13. > >> > >>> However the Consumer only ever sends a composition of > (VC1,VC2,VC3). > >>> It is > >>> never going to change that combination. > >> [Duckworth, Mark] Do you mean the Provider will always send a > >> composition of (VC1,VC2,VC3)? And the provider would like to be more > >> explicit about this in the advertisement? > >> > >>> It seems to me that in this case > >>> using MaxCaptures as it is currently defined is semantically incorrec= t. > >> [Duckworth, Mark] I think it is correct, but maybe not giving as much > >> information as the provider wants to express. > > [CNG] I can't see its correct. If I tell you that I can do a set of > > behaviour but I only intend to do one then I don't think that's > > truthful. Sort of like telling you I'm coming to your house one day > > next week when in fact I only intend on coming on Friday. > >> > >>> So what I am suggesting is simply to add a way to correctly indicate > >>> this "constant number of captures" case, i.e. (VC1,VC2,VC3). > >> [Duckworth, Mark] If I understand your suggestion correctly, then one > >> way to do that would be to add a new optional MinCaptures attribute > >> to an MCC. MinCaptures is the minimum number of constituent captures > >> that may appear in the MCC at a time. If this attribute is not set, > >> then it is assumed to have the default value of 1. For this > >> scenario, the value of both MinCaptures and MaxCaptures would be 3. > >> Is this what you are suggesting, or do you have something else in mind= ? > > [CNG] No all I had in mind was something like: > > MaxCaptures "=3D"/"<=3D" value > > The Advertiser would chose to indicate "equal" or "equal to or > > less than". > >>> I think Paul is questioning the attribute in general. I do believe > >>> that knowing the number of sources may be beneficial for a consumer > >>> in deciding which MCC/Captures to select. There may be tradeoffs vs > >>> a MCC only showing a limited number (i.e. one source) at a time vs > >>> another MCC showing multiple sources at a time. > > [CNG] I agree I think its beneficial. > >>> > >>> Regards, Christian > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Fri Feb 7 09:20:23 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38531ACCEA for ; Fri, 7 Feb 2014 09:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CfEq2pTT_W0 for ; Fri, 7 Feb 2014 09:20:22 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id A751E1ACCE8 for ; Fri, 7 Feb 2014 09:20:22 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta06.westchester.pa.mail.comcast.net with comcast id PTQE1n0050xGWP856VLNGB; Fri, 07 Feb 2014 17:20:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id PVLN1n0073ZTu2S3YVLN0Y; Fri, 07 Feb 2014 17:20:22 +0000 Message-ID: <52F515D6.9050901@alum.mit.edu> Date: Fri, 07 Feb 2014 12:20:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391793622; bh=yyMme69stRwSh1qggBcTSmcWdG65LK4KFkxgUkqCYv8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E/69C6FSLGrVMW6eqglbWww7yMZW5cZnBWlgtO9pV1xqpl8Q9HlBRJ4Kz8crwztGU xJfjtXdC1URj6lRb/BewNd1UJecJid+d4P4tHPXeZrtpbeBu9oL2s/+1CnqttkhA8Z wBk24FJersKycH4PwDiBOJwdAKbZz5suv5lYEZFdlXnC+NIetWnlw485e0hlzz/Mj0 yNftEilc+BB8oxH8rFAg1/TxOfIjcjsOOIvgrtHuF4TG+G0mYMy+manYi9O2gJnElG Oi0MCxh08fNhecxZ2NNTObuILX0aSRKESXf/jCVUaBtULML8wsmJY8aVaLq7xBg1BN cJqyljegERZNQ== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 17:20:23 -0000 On 2/7/14 7:12 AM, Christer Holmberg wrote: > Hi, > > Based on the discussions on the CLUE- and RTCWEB lists, I’ve submitted a > new version of the CLUE data channel draft. > > There are still open issue, and I have probably not implemented > everyone’s change wishes. It is more to add some more meat, and continue > the discussions. Thanks. Much of the confusing points are getting clarified! A few comments: Actually there are two open issues, one in 3.2, one in 3.3. I think you can resolve the one in 3.2, and just say the the SCTP streams IDs must be identical. If we use the rtcweb channel protocol then that will be true. If we use the ejzak draft it will also be true. And if we define our own negotiation mechanism then we can make it be true. Section 3.4.1: Must use 51 or 54 for CLUE protocol messages. If we end up using the RTCWEB Data Channel Protocol then we will also be using 50. Thanks, Paul From mary.ietf.barnes@gmail.com Fri Feb 7 11:20:05 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76441ACCFA for ; Fri, 7 Feb 2014 11:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F57QvjJV1njy for ; Fri, 7 Feb 2014 11:20:01 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B05A41ACCEF for ; Fri, 7 Feb 2014 11:20:01 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id e14so1934470iej.18 for ; Fri, 07 Feb 2014 11:20:01 -0800 (PST) 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=PWahzvdvIH6SGQd6ACSqbhZcifBCTuVhbBYAZ42cfAA=; b=GFwSDQyIwW3HXzvDhIKYdqBXc/mdJ4uSCICrjiTyDDyXCgqxZSEcT8X8MDOL1rtFbs i4BL9FYgFb3t9xPs/8YmANYbWFuwCU3wCLLDLQBo5haCF2Et56HmMn/hSqBLS6Fv5mev 67h+VagZYlSteAhpFd7p91IGuMKlFsTolgNLS9Vv1sx99Yt4cYamuIGktayIj6uqM3CW E6ksYxvjzsg8il8pfOhra5dKPVlqv/RojtUemnEhIKzrzL1Fm1aB81kWIM956w0/09AF 9e+aD6ml69HmzToayqwNCbEyvPqqdSJzUvFjk79IyWvqEoBvHO5YZZ5n21+2RrlH4sZY tavA== MIME-Version: 1.0 X-Received: by 10.42.227.195 with SMTP id jb3mr5214829icb.27.1391800801543; Fri, 07 Feb 2014 11:20:01 -0800 (PST) Received: by 10.43.58.137 with HTTP; Fri, 7 Feb 2014 11:20:01 -0800 (PST) In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB192@CRPMBOXPRD07.polycom.com> References: <52D44B95.7080906@alum.mit.edu> <52DC7E14.9080603@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB192@CRPMBOXPRD07.polycom.com> Date: Fri, 7 Feb 2014 13:20:01 -0600 Message-ID: From: Mary Barnes To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=001a1133df8e5fcd6d04f1d5e0eb Cc: "clue@ietf.org" Subject: Re: [clue] Ticket #33: Security for Framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 19:20:05 -0000 --001a1133df8e5fcd6d04f1d5e0eb Content-Type: text/plain; charset=ISO-8859-1 Below please find, the updated text for the security considerations that incorporates the comments made by Paul and Christian. I did not add anything new with regards to Christian's point about MCUs passing media with no knowledge of content. That's not unique to CLUE - it's the same for any middle box that forwards media in the form of video. I think it's in good enough shape to add the framework now. We can of course make additional changes later. Thanks, Mary. There are several potential attacks related to telepresence, and specifically the protocols used by CLUE, in the case of conferencing sessions, due to the natural involvement of multiple endpoints and the many, often user-invoked, capabilities provided by the systems. A middle box involved in a CLUE session can experience many of the same attacks as that of a conferencing system such as that enabled by the XCON framework [RFC 6503]. Examples of attacks include the following: an endpoint attempting to listen to sessions in which it is not authorized to participate, an endpoint attempting to disconnect or mute other users, and theft of service by an endpoint in attempting to create telepresence sessions it is not allowed to create. Thus, it is RECOMMENDED that a middle box implementing the protocols necessary to support CLUE, follow the security recommendations specified in the conference control protocol documents. In the case of CLUE, SIP is the default conferencing protocol, thus the security considerations in RFC 4579 MUST be followed. One primary security concern, surrounding the CLUE framework introduced in this document, involves securing the actual protocols and the associated authorization mechanisms. These concerns apply to endpoint to endpoint sessions, as well as sessions involving multiple endpoints and middle boxes. Figure 2 in section 5 provides a basic flow of information exchange for CLUE and the protocols involved. As described in section 5, CLUE uses SIP/SDP to establish the session prior to exchanging any CLUE specific information. Thus the security mechanisms recommended for SIP [RFC 3261], including user authentication and authorization, SHOULD be followed. In addition, the media is based on RTP and thus existing RTP security mechanisms, such as DTLS/SRTP, MUST be supported. A separate data channel is established to transport the CLUE protocol messages. The contents of the CLUE protocol messages are based on information introduced in this document, which is represented by an XML schema for this information defined in the CLUE data model [ref]. Some of the information which could possibly introduce privacy concerns is the xCard information as described in section x. In addition, the (text) description field in the Media Capture attribute (section 7.1.1.7) could possibly reveal sensitive information or specific identities. The same would be true for the descriptions in the Capture Scene (section 7.3.1) and Capture Scene Entry (7.3.2) attributes. One other important consideration for the information in the xCard as well as the description field in the Media Capture and Capture Scene Entry attributes is that while the endpoints involved in the session have been authenticated, there is no assurance that the information in the xCard or description fields is authentic. Thus, this information SHOULD not be used to make any authorization decisions and the participants in the sessions SHOULD be made aware of this. While other information in the CLUE protocol messages does not reveal specific identities, it can reveal characteristics and capabilities of the endpoints. That information could possibly uniquely identify specific endpoints. It might also be possible for an attacker to manipulate the information and disrupt the CLUE sessions. It would also be possible to mount a DoS attack on the CLUE endpoints if a malicious agent has access to the data channel. Thus, It MUST be possible for the endpoints to establish a channel which is secure against both message recovery and message modification. Further details on this are provided in the CLUE data channel solution document. There are also security issues associated with the authorization to perform actions at the CLUE endpoints to invoke specific capabilities (e.g., re-arranging screens, sharing content, etc.). However, the policies and security associated with these actions are outside the scope of this document and the overall CLUE solution. --001a1133df8e5fcd6d04f1d5e0eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Below please find, the updated text for the security consi= derations that incorporates the comments made by Paul and Christian. =A0 I = did not add anything new with regards to Christian's point about MCUs p= assing media with no knowledge of content. That's not unique to CLUE - = it's the same for any middle box that forwards media in the form of vid= eo.=A0

I think it's in good enough shape to add the framework n= ow. =A0We can of course make additional changes later.=A0

Thanks,
Mary.
=A0 =A0There are several potentia= l attacks related to
=A0 =A0telepresence, and specifically the pr= otocols used by CLUE,=A0
=A0 =A0in the case of conferencing sessions,=A0
=A0 =A0due t= o the natural involvement of multiple endpoints
=A0 =A0and the ma= ny, often user-invoked, capabilities provided by the
=A0 =A0syste= ms.=A0

=A0 =A0A middle box involved in a CLUE session can experienc= e=A0
=A0 =A0many of the same attacks as that of a conferencing sy= stem such=A0
=A0 =A0as that enabled by the XCON framework [RFC 65= 03].=A0
=A0 =A0Examples of attacks include the following: an
=A0 =A0endpo= int attempting to listen to sessions in which it is not
=A0 =A0au= thorized to participate, an endpoint attempting to disconnect or
= =A0 =A0mute other users, and theft of service by an endpoint in attempting<= /div>
=A0 =A0to create telepresence sessions it is not allowed to create.=A0=
=A0 =A0Thus, it is RECOMMENDED that a middle box implementing th= e protocols
=A0 =A0necessary to support CLUE, follow the security= recommendations specified in the
=A0 =A0conference control protocol documents. =A0In the case of CLUE, = SIP is the=A0
=A0 =A0default conferencing protocol, thus the secu= rity considerations in RFC 4579=A0
=A0 =A0MUST be followed.=A0

=A0 =A0One primary security concern, surrounding the CLUE fr= amework=A0
=A0 =A0introduced in this document, involves securing = the actual protocols
=A0 =A0and the associated authorization mech= anisms. =A0These concerns
=A0 =A0apply to endpoint to endpoint sessions, as well as sessions inv= olving multiple
=A0 =A0endpoints and middle boxes.
=A0 = =A0Figure 2 in section 5 provides a basic flow of information exchange for = CLUE
=A0 =A0and the protocols involved.=A0

=A0 =A0= As described in section 5, CLUE uses SIP/SDP to establish the session prior= to =A0
=A0 =A0exchanging any CLUE specific information. Thus the= security mechanisms=A0
=A0 =A0recommended for SIP [RFC 3261], including user authentication a= nd authorization,
=A0 =A0SHOULD be followed. In addition, the med= ia is based on RTP and thus=A0
=A0 =A0existing RTP security mecha= nisms, such as DTLS/SRTP, MUST be supported.
=A0 =A0
=A0 =A0A separate data channel is established to tra= nsport the CLUE protocol messages.
=A0 =A0The contents of the CLU= E protocol messages are based on information introduced in=A0
=A0= =A0this document, which is represented by an XML schema for this informati= on=A0
=A0 =A0defined in the CLUE data model [ref]. Some of the information w= hich could possibly=A0
=A0 =A0introduce privacy concerns is the x= Card information as described in section x. =A0
=A0 =A0In additio= n, the (text) description field in the Media Capture attribute=A0
=A0 =A0(section 7.1.1.7) could possibly reveal sensitive information o= r specific identities.
=A0 =A0The same would be true for the desc= riptions in the Capture Scene (section 7.3.1)
=A0 =A0and Capture = Scene Entry (7.3.2) attributes. =A0 One other important consideration for= =A0
=A0 =A0the information in the xCard as well as the description field i= n the Media Capture=A0
=A0 =A0and Capture Scene Entry attributes = is that while the endpoints involved in the session
=A0 =A0have b= een authenticated, there is no assurance that the information in the xCard<= /div> =A0 =A0or description fields is= authentic. =A0
=A0 =A0Thus, this information SHOULD not be used to make=A0any authorization decisions=A0=
=A0 =A0and = the participants in the sessions SHOULD be made aware of this.=A0

=A0 =A0While other information i= n the CLUE protocol messages does not reveal specific=A0
=A0 =A0iden= tities, it can reveal characteristics and capabilities of the endpoints. = =A0That=A0
=A0 =A0info= rmation could possibly uniquely identify specific endpoints. =A0=A0<= span class=3D"Apple-style-span" style=3D"border-collapse:collapse;font-fami= ly:arial,sans-serif;font-size:13px">It might also be
=A0 =A0poss= ible for an attacker to manipulate the information and disrupt =A0=A0
=A0 =A0the CLUE sessions. =A0It would also be possible to mount a DoS= attack=A0
=A0 =A0on the CLUE endpoints if a maliciou= s agent has access to the data channel. =A0
=A0 =A0Thus, It MUST be possible for the e= ndpoints to establish a channel which is=A0
=A0 =A0secure against both message recover= y and message modification. Further details
=A0 =A0on this are provided in the CLUE da= ta channel solution document. =A0

=A0 =A0There = are also security issues associated with the authorization to
=A0 =A0perform actions at the CLUE endpoin= ts to invoke specific
=A0 =A0capabilities (e.g., re-arranging sc= reens, sharing content, etc.).
=A0 =A0However, the policies and security = associated with these actions a= re outside the=A0
=A0 =A0scop= e=A0of this document and the overall CLUE solution. =A0=
=A0 =A0
=A0 =A0
=A0 =A0 =A0

--001a1133df8e5fcd6d04f1d5e0eb-- From pkyzivat@alum.mit.edu Fri Feb 7 12:14:33 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B481A0454 for ; Fri, 7 Feb 2014 12:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9MNQ8PcqAlp for ; Fri, 7 Feb 2014 12:14:32 -0800 (PST) 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 043471A0447 for ; Fri, 7 Feb 2014 12:14:31 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta07.westchester.pa.mail.comcast.net with comcast id PRlb1n0040SCNGk57YEXnt; Fri, 07 Feb 2014 20:14:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id PYEX1n00a3ZTu2S3VYEXQK; Fri, 07 Feb 2014 20:14:31 +0000 Message-ID: <52F53EA7.30609@alum.mit.edu> Date: Fri, 07 Feb 2014 15:14:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <52D44B95.7080906@alum.mit.edu> <52DC7E14.9080603@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB192@CRPMBOXPRD07.polycom.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=1391804071; bh=PP/JWwd5O9pT51Ymg69+cTyxVsUtiz9b61e9EY7nDOw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=R198SGuFzgcxCKIpDfKQeHM5Y944NxcXFloGKQDULOb3MUGSclABGPTKSMwgvcyJD N1oQbnX3csAzff8mqL069lERtCWpIKW+hki1D9OcErdXgyqkpIrsnYdIk+NQiFAgVD YJ0cslxAyVHCca0JdYa3QhU+xHgzSk+tknsJ9GlQ1pzzLPDwFp6gTVtz1h/2N6upxu eVvsJmAVEqf5mpwSdSMA3jV+q3uO51zTrp4Tt88m5TjEaqxIvNQuErhOFH+0km7Dc6 qMSwq6aFWfP9jzyJaJ3c0iYQ5sXlUQpNT0sYgQffFSGr8TeSvbriB7v4hVq8ZQ4Qiz GHOfwvMKkq1kQ== Subject: Re: [clue] Ticket #33: Security for Framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 20:14:34 -0000 This sounds good to me. Thanks, Paul On 2/7/14 2:20 PM, Mary Barnes wrote: > Below please find, the updated text for the security considerations that > incorporates the comments made by Paul and Christian. I did not add > anything new with regards to Christian's point about MCUs passing media > with no knowledge of content. That's not unique to CLUE - it's the same > for any middle box that forwards media in the form of video. > > I think it's in good enough shape to add the framework now. We can of > course make additional changes later. > > Thanks, > Mary. > > There are several potential attacks related to > telepresence, and specifically the protocols used by CLUE, > in the case of conferencing sessions, > due to the natural involvement of multiple endpoints > and the many, often user-invoked, capabilities provided by the > systems. > > A middle box involved in a CLUE session can experience > many of the same attacks as that of a conferencing system such > as that enabled by the XCON framework [RFC 6503]. > Examples of attacks include the following: an > endpoint attempting to listen to sessions in which it is not > authorized to participate, an endpoint attempting to disconnect or > mute other users, and theft of service by an endpoint in attempting > to create telepresence sessions it is not allowed to create. > Thus, it is RECOMMENDED that a middle box implementing the protocols > necessary to support CLUE, follow the security recommendations > specified in the > conference control protocol documents. In the case of CLUE, SIP is the > default conferencing protocol, thus the security considerations in > RFC 4579 > MUST be followed. > > One primary security concern, surrounding the CLUE framework > introduced in this document, involves securing the actual protocols > and the associated authorization mechanisms. These concerns > apply to endpoint to endpoint sessions, as well as sessions > involving multiple > endpoints and middle boxes. > Figure 2 in section 5 provides a basic flow of information exchange > for CLUE > and the protocols involved. > > As described in section 5, CLUE uses SIP/SDP to establish the > session prior to > exchanging any CLUE specific information. Thus the security mechanisms > recommended for SIP [RFC 3261], including user authentication and > authorization, > SHOULD be followed. In addition, the media is based on RTP and thus > existing RTP security mechanisms, such as DTLS/SRTP, MUST be supported. > A separate data channel is established to transport the CLUE > protocol messages. > The contents of the CLUE protocol messages are based on information > introduced in > this document, which is represented by an XML schema for this > information > defined in the CLUE data model [ref]. Some of the information which > could possibly > introduce privacy concerns is the xCard information as described in > section x. > In addition, the (text) description field in the Media Capture > attribute > (section 7.1.1.7) could possibly reveal sensitive information or > specific identities. > The same would be true for the descriptions in the Capture Scene > (section 7.3.1) > and Capture Scene Entry (7.3.2) attributes. One other important > consideration for > the information in the xCard as well as the description field in the > Media Capture > and Capture Scene Entry attributes is that while the endpoints > involved in the session > have been authenticated, there is no assurance that the information > in the xCard > or description fields is authentic. > Thus, this information SHOULD not be used to make any authorization > decisions > and the participants in the sessions SHOULD be made aware of this. > > While other information in the CLUE protocol messages does not > reveal specific > identities, it can reveal characteristics and capabilities of the > endpoints. That > information could possibly uniquely identify specific endpoints. It > might also be > possible for an attacker to manipulate the information and disrupt > the CLUE sessions. It would also be possible to mount a DoS attack > on the CLUE endpoints if a malicious agent has access to the data > channel. > Thus, It MUST be possible for the endpoints to establish a channel > which is > secure against both message recovery and message modification. > Further details > on this are provided in the CLUE data channel solution document. > > There are also security issues associated with the authorization to > perform actions at the CLUE endpoints to invoke specific > capabilities (e.g., re-arranging screens, sharing content, etc.). > However, the policies and security associated with these actions are > outside the > scope of this document and the overall CLUE solution. > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Fri Feb 7 12:26:29 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBB41AD2EC for ; Fri, 7 Feb 2014 12:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh16qrSkZ61C for ; Fri, 7 Feb 2014 12:26:27 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 958F41A0464 for ; Fri, 7 Feb 2014 12:26:25 -0800 (PST) Received: from PWEHUB01.polycom.com (10.236.2.221) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 7 Feb 2014 12:26:25 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 7 Feb 2014 12:26:25 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 7 Feb 2014 12:26:22 -0800 Thread-Topic: [clue] How to choose from multiple scenes Thread-Index: Ac8jYbJhK34icWruSnebjaPVN54EuAAHhYtw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> In-Reply-To: <52F3C79E.7010903@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] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 20:26:29 -0000 Hi Paul, You describe the issue very well, but I don't agree with a couple things. = You wrote: > ISTM that one should start out assuming that you need all captures (that > have encodings) in *some* CSE from *each* scene. I don't think that is an appropriate thing to assume. The case I was think= ing of, and we have been talking about at design team meetings, is like thi= s: Scene 1 - current active speaker Scene 2 - previous active speaker Scene 3 - previous previous active speaker and so on... Where each scene could have multiple switched MCCs representing the scene, = and the provider has some flexibility to group together different individua= l captures to include in the MCCs of a scene, depending on synchID and who = is talking. In this case, because of the policy attributes describing the MCCs, I think= it makes perfect sense for a consumer to ask for all the video MCCs from S= cene 1, and none of them from Scene 2 or Scene 3. The consumer has enough = information to know this is a good choice if it wants to show video from th= e current active speaker, including multiple video captures with spatial re= lationship when the current speaker is in a multi-camera room. So in this = case the consumer already has enough information to make a choice. I agree there could be other situations where the MCC policy attributes are= n't enough information for the consumer to make a good choice. This is whe= re I thought the media capture priority attribute should be used. I though= t this was the purpose of adding the priority attribute in the first place.= From the framework: 7.1.1.12. Priority The priority attribute indicates a relative priority between different Medi= a Captures. The Provider sets this priority, and the Consumer MAY use the = priority to help decide which captures it wishes to receive. The "priority" attribute is an integer which indicates a relative priority = between Captures. For example it is possible to assign a priority between t= wo presentation Captures that would allow a remote endpoint to determine wh= ich presentation is more important. Priority is assigned at the individual = capture level. It represents the Provider's view of the relative priority b= etween Captures with a priority.=20 I don't understand why you say this isn't a priority issue, but rather an a= lternative issue. It seems to me your proposal of advertising different co= mbinations of captures or CSEs across scene boundaries is just another way = for the provider to express priorities. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, February 06, 2014 12:34 PM > To: clue@ietf.org > Subject: Re: [clue] How to choose from multiple scenes >=20 > I just realized I had missed this reply. See inline. >=20 > On 1/27/14 10:33 PM, Christian Groves wrote: > > Hello Paul, > > > > Please see below. > > > > Regards, Christian > > > > On 28/01/2014 10:06 AM, Paul Kyzivat wrote: > >> * The problem: > >> > >> As we discussed in the interim today, it seems unclear what a > >> consumer should do when receiving an advertisement with multiple > >> scenes in order to get a sufficient representation of the advertised > content. > >> > >> Our simple cases have been where there is one scene for the cameras > >> in the room, and another scene for a presentation. In that case, one > >> should take something from each scene (typically one CSE from each) > >> to get "enough". > >> > >> That is also true if an MCU acted in "pass through" mode and simply > >> included "copies" of all the scenes it receives in advertisements, > >> with encodings for them all. > >> > >> In a "simple" case with an MCU use MCC, it might "pass through" all > >> the advertisements it receives, for their spatial info, but not > >> provide any encodings for them. Rather, it would provide one or more > >> new scenes using MCC to aggregate those sources. Then one would not > >> want to configure from the "pass through" scenes, but that isn't an > >> option anyway if there are no encodings for them. > > [CNG] The idea of the pass through information was that the consumer > > could use any capture attribute (not just spatial ones) to determine > > what media it wanted. >=20 > Clearly if there are no encodings, then the captures are there only for > information and can't be configured. >=20 > That is why I called this the "simple" case. >=20 > >> Mark has proposed using multiple scenes with MCC to illustrate > >> switched cases where some groupings don't have any spatial > >> relationship to one another. Some of those examples end up with > >> multiple scenes that do have encodings, where it doesn't make sense > >> to configure something from each scene. > > [CNG] I don't think there's anything in the framework that says a > > consumer must choose a capture from a scene. >=20 > Of course there is no MUST. The consumer isn't required take *anything*. >=20 > The question is how the consumer knows what is required to have a > "complete" representation of what is in the advertisement. It may not wan= t > all that, but it is hard to make a good choice without knowing. >=20 > That is the point of CSEs - for the advertiser to indicate what it consid= ers to > be good alternative choices. But CSEs only work within a scene. Once ther= e > are multiple scenes, the consumer has less guidance on what would be good > (or sufficient) choices. >=20 > The consumer has *some* information: > - if none of the captures in a scene have encodings, then there is > no need (or way) to select them directly >=20 > - if MCC M in scene X references capture C in scene Y, then it > would be redundant to configure both M and C >=20 > ISTM that one should start out assuming that you need all captures (that > have encodings) in *some* CSE from *each* scene. You can then prune that > based on the logic above. But is that *enough* to make good decisions? > At best, the logic to figure that out is complex. >=20 > >> Today we discussed using priority to solve this, but this isn't > >> really a priority problem, it is a problem of *alternatives* that may > >> be equally desirable, depending on the resources or desires of the > consumer. > > [CNG] I agree I don't think priority is the right solution for this. > >> > >> IMO the problem is that our CSE mechanism is a way for the advertiser > >> to suggest alternatives, but this only works on a per-scene basis. > >> The advertiser has no comparable mechanism to suggest alternatives > >> from different scenes. > >> > >> * My proposed solution: > >> > >> I want to restate a proposal I made a long time ago: > >> > >> Instead of one CSE list per scene, have one CSE list > >> per-advertisement, referencing captures from any scene. > >> > >> This makes it possible for the advertiser to recommend combinations > >> that cross scene boundaries. > > [CNG] Perhaps you could give some examples? Does the list need to be > > exhaustive? >=20 > Does the CSE list in a scene have to be exhaustive? >=20 > I think each entry should be "sufficient" for somebody that can't handle = a > bigger one. The definition of "sufficient" is subjective. >=20 > > e.g. the simple case today > > Scene1 CSE1(VC1,VC2,VC3) > > CSE2(VC4) > > Scene2 CSE3(VC5,presentation1) > > > > Does it mean now the Advertisement would now have to advertise? > > CSE1(VC1,VC2,VC3,VC5) > > CSE2(VC4,VC5) > > CSE3(VC1,VC2,VC3) > > CSE4(VC4) > > CSE5(VC5) >=20 > As I said, the definition of "sufficient" is subjective. > IMO the advertisement ought to include at least CSE1,CSE2. >=20 > Rather than include the others, I think I would adjust the priorities of = the > individual captures based on my judgement of which I think should be kept= if > they all can't be. >=20 > Thanks, > Paul >=20 > >> * An alternate solution: > >> > >> Another possibility would be to leave CSEs as they are, but add > >> something analogous to a CSE list, but that lists recommended > >> combinations of scenes. > >> > >> Thanks, > >> Paul From pkyzivat@alum.mit.edu Fri Feb 7 13:44:23 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914BF1A047A for ; Fri, 7 Feb 2014 13:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2ukoBK_wi9E for ; Fri, 7 Feb 2014 13:44:21 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2F41A0420 for ; Fri, 7 Feb 2014 13:44:21 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta09.westchester.pa.mail.comcast.net with comcast id PXqq1n0020ldTLk59ZkMDJ; Fri, 07 Feb 2014 21:44:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id PZkL1n00y3ZTu2S01ZkMKN; Fri, 07 Feb 2014 21:44:21 +0000 Message-ID: <52F553B4.8070206@alum.mit.edu> Date: Fri, 07 Feb 2014 16:44:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391809461; bh=jlD9r02t3tUan6kS7lPR6/OqUMIheiSkVXE8xOIhoUM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hMwczvnHbkQnI8zUJ8EqjGRfgHew1OWT/505vC06uridzt9yhPWiLtF5oOMILjj9J KNsdovm5EPM4RS8vpCbjcj9PmMIEBkcByJsSlR2VpWMDjV3MiIxj5VaUjfZ7RWde4v 7uQvQQyRXW7qgrqHaH+OQ+yZ9RttihSbDmVT1fpblUzaWJ4K6gA7h5YBkbqakqEpOV h7DbioNfdrQozCQk3wm2UAcGbkI+2Pzbimkw60it2aVVSsFCAEass6ZI/v4hyyOxYH bIbKdIhAg/2BWANv8q3T8GzfY87Ptv/zPZttG0tH2olAQQ2B294pT9mDTH9bi4oCCg mfdmoqqw0eJCA== Subject: Re: [clue] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 21:44:23 -0000 On 2/7/14 3:26 PM, Duckworth, Mark wrote: > Hi Paul, > > You describe the issue very well, but I don't agree with a couple things. You wrote: >> ISTM that one should start out assuming that you need all captures (that >> have encodings) in *some* CSE from *each* scene. > I don't think that is an appropriate thing to assume. The case I was thinking of, and we have been talking about at design team meetings, is like this: > Scene 1 - current active speaker > Scene 2 - previous active speaker > Scene 3 - previous previous active speaker > and so on... I understand your *intent* here. But I don't know how the consumer acts on that. It is really part of the point I am trying to make. How does the consumer *know* the above, and take it into account? Are the *scenes* tagged to indicate that? (I don't think so.) > Where each scene could have multiple switched MCCs representing the scene, and the provider has some flexibility to group together different individual captures to include in the MCCs of a scene, depending on synchID and who is talking. > In this case, because of the policy attributes describing the MCCs, I think it makes perfect sense for a consumer to ask for all the video MCCs from Scene 1, and none of them from Scene 2 or Scene 3. The consumer has enough information to know this is a good choice if it wants to show video from the current active speaker, including multiple video captures with spatial relationship when the current speaker is in a multi-camera room. So in this case the consumer already has enough information to make a choice. I'm having difficulty imagining how to construct an algorithm for that. ISTM in this case that taking a cse from every scene will give the best user experience *if* the consumer has enough display resources to show all these. If not, then it gets complex to sort out the tradeoffs. In this case, considering that a capture with "current active speaker" policy is more important than one with "previous active speaker". So I would suggest that the advertisement mark all the "current active speaker" captures with highest priority, and the others with descending priorities. Then, the consumer could start out assuming it should *try* for one CSE from each scene. It can look at different combinations, taking one from each scene, and evaluate what it can do with that combination. For each one: If it can't handle all the captures from the selected cses, it can start casting out lower priority ones until it can handle it. Then it can assign a score, depending on the priorities of those it took, the priorities of those it had to abandon, and how much it had to "adjust" the ones it took to fit on its displays. And it can repeat that for all the combinations of one cse from each scene. And then pick out the combination with the best score. This is all very heuristic. Will take a lot of thought and testing to come up with something that does well. (It would be interesting to work this out in detail for some specific consumer configurations and see if it can actually find good renderings.) Having the advertisement provide a single set of CSEs across all the scenes would "help" in that it would reduce the number of combinations the consumer had to evaluate. > I agree there could be other situations where the MCC policy attributes aren't enough information for the consumer to make a good choice. This is where I thought the media capture priority attribute should be used. I thought this was the purpose of adding the priority attribute in the first place. From the framework: > > 7.1.1.12. Priority > The priority attribute indicates a relative priority between different Media Captures. The Provider sets this priority, and the Consumer MAY use the priority to help decide which captures it wishes to receive. > The "priority" attribute is an integer which indicates a relative priority between Captures. For example it is possible to assign a priority between two presentation Captures that would allow a remote endpoint to determine which presentation is more important. Priority is assigned at the individual capture level. It represents the Provider's view of the relative priority between Captures with a priority. > > I don't understand why you say this isn't a priority issue, but rather an alternative issue. It seems to me your proposal of advertising different combinations of captures or CSEs across scene boundaries is just another way for the provider to express priorities. Surely it is a form of prioritization. But it can be more sophisticated than simply assigning a priority value to each individual capture. But consider, if prioritization were sufficient, we wouldn't need to have CSEs at all. We could simply have prioritized captures. ISTM that the reasons that CSEs are more powerful than priorities within a scene should still apply outside a scene. As I described above, I *think* priorities plus per-scene cse lists can solve your use case. But the processing to use it that way is complex. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Thursday, February 06, 2014 12:34 PM >> To: clue@ietf.org >> Subject: Re: [clue] How to choose from multiple scenes >> >> I just realized I had missed this reply. See inline. >> >> On 1/27/14 10:33 PM, Christian Groves wrote: >>> Hello Paul, >>> >>> Please see below. >>> >>> Regards, Christian >>> >>> On 28/01/2014 10:06 AM, Paul Kyzivat wrote: >>>> * The problem: >>>> >>>> As we discussed in the interim today, it seems unclear what a >>>> consumer should do when receiving an advertisement with multiple >>>> scenes in order to get a sufficient representation of the advertised >> content. >>>> >>>> Our simple cases have been where there is one scene for the cameras >>>> in the room, and another scene for a presentation. In that case, one >>>> should take something from each scene (typically one CSE from each) >>>> to get "enough". >>>> >>>> That is also true if an MCU acted in "pass through" mode and simply >>>> included "copies" of all the scenes it receives in advertisements, >>>> with encodings for them all. >>>> >>>> In a "simple" case with an MCU use MCC, it might "pass through" all >>>> the advertisements it receives, for their spatial info, but not >>>> provide any encodings for them. Rather, it would provide one or more >>>> new scenes using MCC to aggregate those sources. Then one would not >>>> want to configure from the "pass through" scenes, but that isn't an >>>> option anyway if there are no encodings for them. >>> [CNG] The idea of the pass through information was that the consumer >>> could use any capture attribute (not just spatial ones) to determine >>> what media it wanted. >> >> Clearly if there are no encodings, then the captures are there only for >> information and can't be configured. >> >> That is why I called this the "simple" case. >> >>>> Mark has proposed using multiple scenes with MCC to illustrate >>>> switched cases where some groupings don't have any spatial >>>> relationship to one another. Some of those examples end up with >>>> multiple scenes that do have encodings, where it doesn't make sense >>>> to configure something from each scene. >>> [CNG] I don't think there's anything in the framework that says a >>> consumer must choose a capture from a scene. >> >> Of course there is no MUST. The consumer isn't required take *anything*. >> >> The question is how the consumer knows what is required to have a >> "complete" representation of what is in the advertisement. It may not want >> all that, but it is hard to make a good choice without knowing. >> >> That is the point of CSEs - for the advertiser to indicate what it considers to >> be good alternative choices. But CSEs only work within a scene. Once there >> are multiple scenes, the consumer has less guidance on what would be good >> (or sufficient) choices. >> >> The consumer has *some* information: >> - if none of the captures in a scene have encodings, then there is >> no need (or way) to select them directly >> >> - if MCC M in scene X references capture C in scene Y, then it >> would be redundant to configure both M and C >> >> ISTM that one should start out assuming that you need all captures (that >> have encodings) in *some* CSE from *each* scene. You can then prune that >> based on the logic above. But is that *enough* to make good decisions? >> At best, the logic to figure that out is complex. >> >>>> Today we discussed using priority to solve this, but this isn't >>>> really a priority problem, it is a problem of *alternatives* that may >>>> be equally desirable, depending on the resources or desires of the >> consumer. >>> [CNG] I agree I don't think priority is the right solution for this. >>>> >>>> IMO the problem is that our CSE mechanism is a way for the advertiser >>>> to suggest alternatives, but this only works on a per-scene basis. >>>> The advertiser has no comparable mechanism to suggest alternatives >>>> from different scenes. >>>> >>>> * My proposed solution: >>>> >>>> I want to restate a proposal I made a long time ago: >>>> >>>> Instead of one CSE list per scene, have one CSE list >>>> per-advertisement, referencing captures from any scene. >>>> >>>> This makes it possible for the advertiser to recommend combinations >>>> that cross scene boundaries. >>> [CNG] Perhaps you could give some examples? Does the list need to be >>> exhaustive? >> >> Does the CSE list in a scene have to be exhaustive? >> >> I think each entry should be "sufficient" for somebody that can't handle a >> bigger one. The definition of "sufficient" is subjective. >> >>> e.g. the simple case today >>> Scene1 CSE1(VC1,VC2,VC3) >>> CSE2(VC4) >>> Scene2 CSE3(VC5,presentation1) >>> >>> Does it mean now the Advertisement would now have to advertise? >>> CSE1(VC1,VC2,VC3,VC5) >>> CSE2(VC4,VC5) >>> CSE3(VC1,VC2,VC3) >>> CSE4(VC4) >>> CSE5(VC5) >> >> As I said, the definition of "sufficient" is subjective. >> IMO the advertisement ought to include at least CSE1,CSE2. >> >> Rather than include the others, I think I would adjust the priorities of the >> individual captures based on my judgement of which I think should be kept if >> they all can't be. >> >> Thanks, >> Paul >> >>>> * An alternate solution: >>>> >>>> Another possibility would be to leave CSEs as they are, but add >>>> something analogous to a CSE list, but that lists recommended >>>> combinations of scenes. >>>> >>>> Thanks, >>>> Paul > From christer.holmberg@ericsson.com Fri Feb 7 14:21:48 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E681AD623 for ; Fri, 7 Feb 2014 14:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_uTDNFcGCdh for ; Fri, 7 Feb 2014 14:21:47 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id E1A121A021E for ; Fri, 7 Feb 2014 14:21:46 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-d3-52f55c79fc13 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 7D.7C.04853.97C55F25; Fri, 7 Feb 2014 23:21:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Fri, 7 Feb 2014 23:21:45 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft new version: draft-holmberg-clue-datachannel-01 Thread-Index: Ac8j/b3fWVgMoVOPRmi4Z2O6oFTWFAAIsIAAAAxozp8= Date: Fri, 7 Feb 2014 22:21:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D163756@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se>, <52F515D6.9050901@alum.mit.edu> In-Reply-To: <52F515D6.9050901@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+JvjW5lzNcgg9kPzSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj7d8pTAUPuCral05mbGCcz9HFyMkhIWAi 8e7tQSYIW0ziwr31bF2MXBxCAicYJd63/WCGcBYxSpxpecLYxcjBwSZgIdH9TxukQUTAU2LH xynMILYwkN398AwzRNxL4sqEw1C2lUTT3WnMIK0sAioSy28pg4R5BXwl2pr+MILYQgK5Eptb 54DdwCmgI7Hw1VIWEJsR6J7vp9aAxZkFxCVuPZkPdaeAxJI955khbFGJl4//sULYihIfX+1j hKg3kHh/bj4zhK0tsWzha2aIvYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbJ4tTi4tx0 IwO93PTcEr3Uoszk4uL8PL3i1E2MwGg5uOW30Q7Gk3vsDzFKc7AoifNeZ60JEhJITyxJzU5N LUgtii8qzUktPsTIxMEp1cA49YDd1Y1yl45Vx2VcXyIbtq/88ubrCyVtbeonLqwXPbkv17n4 tnmLfy+rVe9+r4cP0zLCzE5eOn9W+cRsheuXpS9JlrgvvV4RddX1Vr/IKwkxu7M7zXdWi+cE vnu8JNBDMPzeSpYlt+/av/d7lu8664JyiLRBhztX9J4/n7POWcw9nm2k6p6hxFKckWioxVxU nAgA3g1Rn2QCAAA= Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 22:21:49 -0000 Hi Paul, Again, thanks for your quick comments! >> Based on the discussions on the CLUE- and RTCWEB lists, I=92ve submitted= a >> new version of the CLUE data channel draft. >> >> There are still open issue, and I have probably not implemented >> everyone=92s change wishes. It is more to add some more meat, and contin= ue >> the discussions. > > Thanks. Much of the confusing points are getting clarified! > > A few comments: > > Actually there are two open issues, one in 3.2, one in 3.3. Yes - I meant to say open issueS :) > I think you can resolve the one in 3.2, and just say the the SCTP > streams IDs must be identical. If we use the rtcweb channel protocol > then that will be true. If we use the ejzak draft it will also be true. > And if we define our own negotiation mechanism then we can make it be tru= e. True. BUT, we need to be sure that a CLUE JavaScript application can actual= ly control the stream id values being used. If the DCP is used, it is taken care of by the browser. > Section 3.4.1: > > Must use 51 or 54 for CLUE protocol messages. > If we end up using the RTCWEB Data Channel Protocol then we will also be > using 50. Correct. And, as has been indicated on the RTCWEB list, value 54 will be deprecated = (as fragmentation will not be done on application level). Regards, Christer From pkyzivat@alum.mit.edu Fri Feb 7 14:53:09 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8E41AD66B for ; Fri, 7 Feb 2014 14:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khV5FIRYtcJ7 for ; Fri, 7 Feb 2014 14:53:08 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9CC1AD669 for ; Fri, 7 Feb 2014 14:53:08 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA11.westchester.pa.mail.comcast.net with comcast id PQ0Q1n0020SCNGk5Bat7EP; Fri, 07 Feb 2014 22:53:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id Pat71n00U3ZTu2S3Vat74d; Fri, 07 Feb 2014 22:53:07 +0000 Message-ID: <52F563D3.2020302@alum.mit.edu> Date: Fri, 07 Feb 2014 17:53:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se>, <52F515D6.9050901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D163756@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D163756@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391813587; bh=sZznjYi2fFyUAF4Wqryek0JBalXBHHzGieTqbib8MG0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=H30MOnuVUp1/fPSJEo3UdsXI0H3npfRnDRabNFrH6OgZEtU7KTcZOUjzFqJCUb5Ad nFX7MCk/GIeoxc+LZw8PlaFWieduDtR6lMUZruu1ogHZ9EXrJXCpjGJBBEIDVpUijJ Ot6gWPa6N+0MAKWLQibVmDfwIbAx8WHoYHINm9oiw6oeSBDh5lj+S7royDJwuqRBYZ uUOXXMrSThLvniAiutLm4p/dLzNC/Zp6bBRJvaqRiIdxrbAlVjTqw3GzD83xCO6ZQs HCUwkuR1lelI7+hVDsV+Mq7NWgAdfHggecE2UNXe8ig7WvCAiI0shmXryY0Yjq5PLQ 5Y4hW5+eqoOsQ== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 22:53:09 -0000 On 2/7/14 5:21 PM, Christer Holmberg wrote: > > Hi Paul, > > Again, thanks for your quick comments! > >>> Based on the discussions on the CLUE- and RTCWEB lists, I’ve submitted a >>> new version of the CLUE data channel draft. >>> >>> There are still open issue, and I have probably not implemented >>> everyone’s change wishes. It is more to add some more meat, and continue >>> the discussions. >> >> Thanks. Much of the confusing points are getting clarified! >> >> A few comments: >> >> Actually there are two open issues, one in 3.2, one in 3.3. > > Yes - I meant to say open issueS :) > >> I think you can resolve the one in 3.2, and just say the the SCTP >> streams IDs must be identical. If we use the rtcweb channel protocol >> then that will be true. If we use the ejzak draft it will also be true. >> And if we define our own negotiation mechanism then we can make it be true. > > True. BUT, we need to be sure that a CLUE JavaScript application can actually control the stream id values being used. I think you already got a response to your question about that on the rtcweb list, explaining how to do it. > If the DCP is used, it is taken care of by the browser. > > >> Section 3.4.1: >> >> Must use 51 or 54 for CLUE protocol messages. >> If we end up using the RTCWEB Data Channel Protocol then we will also be >> using 50. > > Correct. > > And, as has been indicated on the RTCWEB list, value 54 will be deprecated (as fragmentation will not be done on application level). > > Regards, > > Christer > > From christer.holmberg@ericsson.com Fri Feb 7 14:57:12 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E931AD66B for ; Fri, 7 Feb 2014 14:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J17GLzZ1dd7n for ; Fri, 7 Feb 2014 14:57:10 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD7D1AD669 for ; Fri, 7 Feb 2014 14:57:09 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-69-52f564c44658 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B3.82.10875.4C465F25; Fri, 7 Feb 2014 23:57:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Fri, 7 Feb 2014 23:57:08 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft new version: draft-holmberg-clue-datachannel-01 Thread-Index: Ac8j/b3fWVgMoVOPRmi4Z2O6oFTWFAAIsIAAAAxozp////mxgIAAEaMS Date: Fri, 7 Feb 2014 22:57:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D163A08@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se>, <52F515D6.9050901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D163756@ESESSMB209.ericsson.se>, <52F563D3.2020302@alum.mit.edu> In-Reply-To: <52F563D3.2020302@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje7RlK9BBjem81vsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGjc/3WQoWMVd0PqtoYNzL1MXIySEhYCLx puEVG4QtJnHh3nogm4tDSOAQo8TVp9tYIJxFjBJHnj0H6uDgYBOwkOj+pw3SICLgKbHj4xRm EFsYyO5+eIYZIu4lcWXCYSjbTWLz2issIDaLgIrEk8Zb7CA2r4CvRMuhb8wQ8y8ySjx6M48R JMEpoCMx6fBrVhCbEeii76fWgF3KLCAucevJfKirBSSW7DnPDGGLSrx8/I8VwlaU+PhqHyNE vY7Egt2f2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxsucmZuaklxtu YgTGwsEtv3V3MJ46J3KIUZqDRUmc98Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjNI8 i66ckNyY+nHLw4ijOcvZMipS6w5GbvzavebypCOV4dd+SaaHOxT6WTBZ/r6j4RbAriFddGf6 gVOvLwU7sPbPN7MtDLQNtTCSD92WetqG42hv7BWrPzNu3v14Yc8ib7OVqsmHF/9gZXjd6GTY abW+r/myYWuOOXczi+K99WsWXl7xfrHNKSWW4oxEQy3mouJEAOhUpVlTAgAA Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 22:57:12 -0000 Hi, >> True. BUT, we need to be sure that a CLUE JavaScript application can act= ually control the stream id values being used. > >I think you already got a response to your question about that on the rtcw= eb list, explaining how to do it. Can you provide a link to that e-mail? I am at home, using a web mail client, which is awful for scanning through = e-mail threads :) Regards, Christer From Mark.Duckworth@polycom.com Fri Feb 7 14:58:16 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040591AD669 for ; Fri, 7 Feb 2014 14:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDbJuePDRDjO for ; Fri, 7 Feb 2014 14:58:13 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B4B091A0444 for ; Fri, 7 Feb 2014 14:58:12 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Fri, 7 Feb 2014 14:58:12 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 7 Feb 2014 14:58:10 -0800 Thread-Topic: [clue] How to choose from multiple scenes Thread-Index: Ac8kTcYxuXEAyr9mQQ6cwV6R6Zce0wABs/nw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB7FC@CRPMBOXPRD07.polycom.com> References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> <52F553B4.8070206@alum.mit.edu> In-Reply-To: <52F553B4.8070206@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] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 22:58:16 -0000 Hi Paul, Comments inline. I'm open to your idea of a single set of CSEs across all scenes, but I'm tr= ying to understand if it will really be a scalable and less complex way to = solve these issues. Do you think it would help if you presented this idea at the design team me= eting next week? Mark > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, February 07, 2014 4:44 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] How to choose from multiple scenes >=20 > On 2/7/14 3:26 PM, Duckworth, Mark wrote: > > Hi Paul, > > > > You describe the issue very well, but I don't agree with a couple thing= s. You > wrote: > >> ISTM that one should start out assuming that you need all captures > >> (that have encodings) in *some* CSE from *each* scene. > > I don't think that is an appropriate thing to assume. The case I was t= hinking > of, and we have been talking about at design team meetings, is like this: > > Scene 1 - current active speaker > > Scene 2 - previous active speaker > > Scene 3 - previous previous active speaker and so on... >=20 > I understand your *intent* here. But I don't know how the consumer acts o= n > that. It is really part of the point I am trying to make. > How does the consumer *know* the above, and take it into account? > Are the *scenes* tagged to indicate that? (I don't think so.) [Duckworth, Mark] From the MCC policy attribute values. =20 > > Where each scene could have multiple switched MCCs representing the > scene, and the provider has some flexibility to group together different > individual captures to include in the MCCs of a scene, depending on synch= ID > and who is talking. > > In this case, because of the policy attributes describing the MCCs, I t= hink it > makes perfect sense for a consumer to ask for all the video MCCs from Sce= ne > 1, and none of them from Scene 2 or Scene 3. The consumer has enough > information to know this is a good choice if it wants to show video from = the > current active speaker, including multiple video captures with spatial > relationship when the current speaker is in a multi-camera room. So in t= his > case the consumer already has enough information to make a choice. >=20 > I'm having difficulty imagining how to construct an algorithm for that. [Duckworth, Mark] Yeah, it can get complicated. But is it good enough for = equipment from different vendors to interoperate in a reasonable way, even = if it isn't the "best" way? I think so. I still think my proposed "consum= er makes all the switching decisions" approach can solve a lot of these pro= blems. > ISTM in this case that taking a cse from every scene will give the best u= ser > experience *if* the consumer has enough display resources to show all > these. [Duckworth, Mark] I think "best experience" is subjective here. I think th= e consumer has enough information to make a good choice for a variety of di= fferent consumer capability levels in terms of number of decoders and displ= ays it has. Suppose the consumer can receive no more than 3 video encoding= s. It could ask for the 3 MCCs from Scene 1, or it could ask for 1 MCC fro= m each scene. But I would think it would do that only if each scene had a = CSE with one MCC in it. Each choice could give the "best" experience, depe= nding on what the consumer is trying to present to the human users. > If not, then it gets complex to sort out the tradeoffs. >=20 > In this case, considering that a capture with "current active speaker" > policy is more important than one with "previous active speaker". >=20 > So I would suggest that the advertisement mark all the "current active > speaker" captures with highest priority, and the others with descending > priorities. [Duckworth, Mark] that's what I was thinking, but even that shouldn't be ne= cessary because the consumer can make its own priority decision based on th= e policy attribute. > Then, the consumer could start out assuming it should *try* for one CSE > from each scene. It can look at different combinations, taking one from e= ach > scene, and evaluate what it can do with that combination. For each one: >=20 > If it can't handle all the captures from the selected cses, it can start = casting > out lower priority ones until it can handle it. Then it can assign a scor= e, > depending on the priorities of those it took, the priorities of those it = had to > abandon, and how much it had to "adjust" > the ones it took to fit on its displays. >=20 > And it can repeat that for all the combinations of one cse from each scen= e. > And then pick out the combination with the best score. >=20 > This is all very heuristic. Will take a lot of thought and testing to com= e up with > something that does well. (It would be interesting to work this out in de= tail > for some specific consumer configurations and see if it can actually find= good > renderings.) >=20 > Having the advertisement provide a single set of CSEs across all the scen= es > would "help" in that it would reduce the number of combinations the > consumer had to evaluate. [Duckworth, Mark] I'm not sure it would reduce anything. As Christian said= , "The combinatorial issue becomes worse with the more Scenes that you have= ". I'm concerned that trying to add another layer of alternatives in the a= dvertisement, that crosses scene boundaries, won't scale well. Or do you t= hink it is really simpler than that? Are you envisioning the single set of= CSEs could be kept small, even with many scenes? > > I agree there could be other situations where the MCC policy attributes > aren't enough information for the consumer to make a good choice. This i= s > where I thought the media capture priority attribute should be used. I > thought this was the purpose of adding the priority attribute in the firs= t > place. From the framework: > > > > 7.1.1.12. Priority > > The priority attribute indicates a relative priority between different = Media > Captures. The Provider sets this priority, and the Consumer MAY use the > priority to help decide which captures it wishes to receive. > > The "priority" attribute is an integer which indicates a relative prior= ity > between Captures. For example it is possible to assign a priority between > two presentation Captures that would allow a remote endpoint to determine > which presentation is more important. Priority is assigned at the individ= ual > capture level. It represents the Provider's view of the relative priority > between Captures with a priority. > > > > I don't understand why you say this isn't a priority issue, but rather = an > alternative issue. It seems to me your proposal of advertising different > combinations of captures or CSEs across scene boundaries is just another > way for the provider to express priorities. >=20 > Surely it is a form of prioritization. But it can be more sophisticated t= han > simply assigning a priority value to each individual capture. >=20 > But consider, if prioritization were sufficient, we wouldn't need to have= CSEs > at all. We could simply have prioritized captures. ISTM that the reasons = that > CSEs are more powerful than priorities within a scene should still apply > outside a scene. [Duckworth, Mark] That makes sense too, at a high level, but I'm having tro= uble understanding how to put it in practice. =20 > As I described above, I *think* priorities plus per-scene cse lists can s= olve > your use case. But the processing to use it that way is complex. [Duckworth, Mark] So are you saying your idea of using a single set of CSEs= across all scenes can solve the same problems in a less complex way? I'm = open to that, but still not sure it would be any less complex. =20 > Thanks, > Paul >=20 > > Mark > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Thursday, February 06, 2014 12:34 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] How to choose from multiple scenes > >> > >> I just realized I had missed this reply. See inline. > >> > >> On 1/27/14 10:33 PM, Christian Groves wrote: > >>> Hello Paul, > >>> > >>> Please see below. > >>> > >>> Regards, Christian > >>> > >>> On 28/01/2014 10:06 AM, Paul Kyzivat wrote: > >>>> * The problem: > >>>> > >>>> As we discussed in the interim today, it seems unclear what a > >>>> consumer should do when receiving an advertisement with multiple > >>>> scenes in order to get a sufficient representation of the > >>>> advertised > >> content. > >>>> > >>>> Our simple cases have been where there is one scene for the cameras > >>>> in the room, and another scene for a presentation. In that case, > >>>> one should take something from each scene (typically one CSE from > >>>> each) to get "enough". > >>>> > >>>> That is also true if an MCU acted in "pass through" mode and simply > >>>> included "copies" of all the scenes it receives in advertisements, > >>>> with encodings for them all. > >>>> > >>>> In a "simple" case with an MCU use MCC, it might "pass through" all > >>>> the advertisements it receives, for their spatial info, but not > >>>> provide any encodings for them. Rather, it would provide one or > >>>> more new scenes using MCC to aggregate those sources. Then one > >>>> would not want to configure from the "pass through" scenes, but > >>>> that isn't an option anyway if there are no encodings for them. > >>> [CNG] The idea of the pass through information was that the consumer > >>> could use any capture attribute (not just spatial ones) to determine > >>> what media it wanted. > >> > >> Clearly if there are no encodings, then the captures are there only > >> for information and can't be configured. > >> > >> That is why I called this the "simple" case. > >> > >>>> Mark has proposed using multiple scenes with MCC to illustrate > >>>> switched cases where some groupings don't have any spatial > >>>> relationship to one another. Some of those examples end up with > >>>> multiple scenes that do have encodings, where it doesn't make sense > >>>> to configure something from each scene. > >>> [CNG] I don't think there's anything in the framework that says a > >>> consumer must choose a capture from a scene. > >> > >> Of course there is no MUST. The consumer isn't required take *anything= *. > >> > >> The question is how the consumer knows what is required to have a > >> "complete" representation of what is in the advertisement. It may not > >> want all that, but it is hard to make a good choice without knowing. > >> > >> That is the point of CSEs - for the advertiser to indicate what it > >> considers to be good alternative choices. But CSEs only work within a > >> scene. Once there are multiple scenes, the consumer has less guidance > >> on what would be good (or sufficient) choices. > >> > >> The consumer has *some* information: > >> - if none of the captures in a scene have encodings, then there is > >> no need (or way) to select them directly > >> > >> - if MCC M in scene X references capture C in scene Y, then it > >> would be redundant to configure both M and C > >> > >> ISTM that one should start out assuming that you need all captures > >> (that have encodings) in *some* CSE from *each* scene. You can then > >> prune that based on the logic above. But is that *enough* to make good > decisions? > >> At best, the logic to figure that out is complex. > >> > >>>> Today we discussed using priority to solve this, but this isn't > >>>> really a priority problem, it is a problem of *alternatives* that > >>>> may be equally desirable, depending on the resources or desires of > >>>> the > >> consumer. > >>> [CNG] I agree I don't think priority is the right solution for this. > >>>> > >>>> IMO the problem is that our CSE mechanism is a way for the > >>>> advertiser to suggest alternatives, but this only works on a per-sce= ne > basis. > >>>> The advertiser has no comparable mechanism to suggest alternatives > >>>> from different scenes. > >>>> > >>>> * My proposed solution: > >>>> > >>>> I want to restate a proposal I made a long time ago: > >>>> > >>>> Instead of one CSE list per scene, have one CSE list > >>>> per-advertisement, referencing captures from any scene. > >>>> > >>>> This makes it possible for the advertiser to recommend combinations > >>>> that cross scene boundaries. > >>> [CNG] Perhaps you could give some examples? Does the list need to be > >>> exhaustive? > >> > >> Does the CSE list in a scene have to be exhaustive? > >> > >> I think each entry should be "sufficient" for somebody that can't > >> handle a bigger one. The definition of "sufficient" is subjective. > >> > >>> e.g. the simple case today > >>> Scene1 CSE1(VC1,VC2,VC3) > >>> CSE2(VC4) > >>> Scene2 CSE3(VC5,presentation1) > >>> > >>> Does it mean now the Advertisement would now have to advertise? > >>> CSE1(VC1,VC2,VC3,VC5) > >>> CSE2(VC4,VC5) > >>> CSE3(VC1,VC2,VC3) > >>> CSE4(VC4) > >>> CSE5(VC5) > >> > >> As I said, the definition of "sufficient" is subjective. > >> IMO the advertisement ought to include at least CSE1,CSE2. > >> > >> Rather than include the others, I think I would adjust the priorities > >> of the individual captures based on my judgement of which I think > >> should be kept if they all can't be. > >> > >> Thanks, > >> Paul > >> > >>>> * An alternate solution: > >>>> > >>>> Another possibility would be to leave CSEs as they are, but add > >>>> something analogous to a CSE list, but that lists recommended > >>>> combinations of scenes. > >>>> > >>>> Thanks, > >>>> Paul > > From pkyzivat@alum.mit.edu Fri Feb 7 15:16:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A18B1A0444 for ; Fri, 7 Feb 2014 15:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9VcjeycpRqz for ; Fri, 7 Feb 2014 15:16:05 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 523281A042B for ; Fri, 7 Feb 2014 15:16:05 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id PbD81n0021swQuc5FbG4WN; Fri, 07 Feb 2014 23:16:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id PbG41n00M3ZTu2S3bbG4My; Fri, 07 Feb 2014 23:16:04 +0000 Message-ID: <52F56934.907@alum.mit.edu> Date: Fri, 07 Feb 2014 18:16:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se>, <52F515D6.9050901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D163756@ESESSMB209.ericsson.se>, <52F563D3.2020302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D163A08@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D163A08@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=1391814964; bh=01EOjhXAhOukm3Os9OfDlwUv0dSdL6xnEhDjEVnD2No=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mr292HmYdPPK9cG1kmj/hE9j2SZJ6SalQZfAy79d/0ScjUbCkzn78hWqvW8v4n1uO 32o7Cyj/VOi31eg8SEM6TXy8CKt4Eyl9xn7g1j4tvEWTbYRAvjvix7FT5daAQC6Qps QmAEPB3/WUwkAKUypQ/Ba6CPJcPxtxOTNEkWACVhkVyO4O0Ig3B+5rIQSKsJIs2EpU 2n1nXe/lIPhfXNPlfQu6MTjQgPIT5TbXXzqbtuWk9kITlCUK54A1wDuj3q6lKF9J0q /68vAuiRZ8pjpCcJyCR5rKS0QWSDnB4VlFq6v3Ty+Nk1BCWdsgl5mLtdv92vK9Hcao 68eya7asY8GvA== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 23:16:06 -0000 On 2/7/14 5:57 PM, Christer Holmberg wrote: > > Hi, > >>> True. BUT, we need to be sure that a CLUE JavaScript application can actually control the stream id values being used. >> >> I think you already got a response to your question about that on the rtcweb list, explaining how to do it. > > Can you provide a link to that e-mail? http://www.ietf.org/mail-archive/web/rtcweb/current/msg11299.html From christer.holmberg@ericsson.com Fri Feb 7 15:36:29 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984CC1A0507 for ; Fri, 7 Feb 2014 15:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9fWGFy1Gexr for ; Fri, 7 Feb 2014 15:36:25 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 859061A0444 for ; Fri, 7 Feb 2014 15:36:25 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-40-52f56df8d4a6 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 01.40.04249.8FD65F25; Sat, 8 Feb 2014 00:36:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Sat, 8 Feb 2014 00:36:24 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft new version: draft-holmberg-clue-datachannel-01 Thread-Index: Ac8j/b3fWVgMoVOPRmi4Z2O6oFTWFAAIsIAAAAxozp////mxgIAAEaMS///0xwCAABXCcg== Date: Fri, 7 Feb 2014 23:36:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D163AA5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se>, <52F515D6.9050901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D163756@ESESSMB209.ericsson.se>, <52F563D3.2020302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D163A08@ESESSMB209.ericsson.se>, <52F56934.907@alum.mit.edu> In-Reply-To: <52F56934.907@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje6P3K9BBpP+6FvsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGo+XeBVNYKmYf+8bWwLiQuYuRk0NCwETi 5ocOVghbTOLCvfVsXYxcHEICRxglDn95wQrhLGKU+LDjAUsXIwcHm4CFRPc/bZAGEQFPiR0f p4ANEgayux+eYYaIe0lcmXAYyg6T2Ld4PZjNIqAi8aTtHguIzSvgK3H1/EYwW0hgI5PE7QcJ IDangIZE57YXbCA2I9BB30+tYQKxmQXEJW49mc8EcaiAxJI956EeEJV4+fgf1AOKEh9f7WOE qNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRo7i1OKk3HQj g02MwFg4uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHx DEeKDNOev8Ylz3+VH/a0uHVHqfBS8x0THuEskQeRzrEBoVe3zon4EL/Y8MwipcXictezHUMn vdlwrX9O6Ly+ljPfHNfkvBLnzJM8u2f2Sv9zcul9ERd+s3ewRHLLMkgIv1DJ3Bzzf62kWeXD zsfzvtSssFjEnmAeuvpoNx+3bGnsDTWlzy+VWIozEg21mIuKEwHR5snyUwIAAA== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 23:36:30 -0000 Hi, >>>> True. BUT, we need to be sure that a CLUE JavaScript application can a= ctually control the stream id values being used. >>> >>> I think you already got a response to your question about that on the r= tcweb list, explaining how to do it. >> >> Can you provide a link to that e-mail? > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg11299.html Thanks for the link! Ok, I remember that e-mail. It seems like he wasn't 100% sure, though, so i= t needs to be verified :) Regards, Christer From pkyzivat@alum.mit.edu Sat Feb 8 10:19:58 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BE41A01A8 for ; Sat, 8 Feb 2014 10:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAWLJk9L3VVO for ; Sat, 8 Feb 2014 10:19:55 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id C752D1A0025 for ; Sat, 8 Feb 2014 10:19:54 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta02.westchester.pa.mail.comcast.net with comcast id PtKV1n0071YDfWL51uKulQ; Sat, 08 Feb 2014 18:19:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id PuKu1n00a3ZTu2S3guKuss; Sat, 08 Feb 2014 18:19:54 +0000 Message-ID: <52F6754A.3050501@alum.mit.edu> Date: Sat, 08 Feb 2014 13:19:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> <52F553B4.8070206@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB7FC@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB7FC@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391883594; bh=vdufdbX9JxN/GlmB+ezRAVEmEh/2pdeFADEWex9q5Wc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CGFnIMQG7chCKDsL5jJNAsDfeOHGgufvQhtgStAC84GLCTrpNdy8Kws6I1628gKY3 2WlCHoW0O4UdR3yAgkoZo8ggZyhbsML++SZmPtPTix0Z32pynQgOye6UbYdi+GeINC xWkgk9sRBI8oXDjfagdhUL9ElbbkcWDMKIf+2i8iy00J53zpie0MYPhknkYDWkEs61 h5aLnN45dCHCfqBek6j0EzDoQ08iQ4aopeaueQh3joND2VaEG2OBaO5JaArmXHHlEg yaHD9jexs4yG6fs89MUd+B8hmwPM9HSiPvbBcykQbK1iD+gzm2R4m7cRRErHuXZFM6 tfotGNBk0R8rQ== Subject: Re: [clue] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 08 Feb 2014 18:19:58 -0000 On 2/7/14 5:58 PM, Duckworth, Mark wrote: > Hi Paul, > Comments inline. > I'm open to your idea of a single set of CSEs across all scenes, but I'm trying to understand if it will really be a scalable and less complex way to solve these issues. Me too. I'm not certain that it will, but my gut says so. It just seems to me that the idea of enumerating useful combinations of captures in the advertisement is conceptually unrelated to what scene they are in, and that for the consumer the process then by default devolves to just choosing the one best cse that works for it, rather than having to choose from among combinations in different scenes. > Do you think it would help if you presented this idea at the design team meeting next week? I'm not convinced that call time is very helpful for this. To be useful I would probably need to create several use cases, and show them both ways, and then for people to try to shoot them down. I think that kind of thing is better done by email. (And I don't have time to put together sufficient use cases before Tuesday.) More below. > Mark > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Friday, February 07, 2014 4:44 PM >> To: Duckworth, Mark; clue@ietf.org >> Subject: Re: [clue] How to choose from multiple scenes >> >> On 2/7/14 3:26 PM, Duckworth, Mark wrote: >>> Hi Paul, >>> >>> You describe the issue very well, but I don't agree with a couple things. You >> wrote: >>>> ISTM that one should start out assuming that you need all captures >>>> (that have encodings) in *some* CSE from *each* scene. >>> I don't think that is an appropriate thing to assume. The case I was thinking >> of, and we have been talking about at design team meetings, is like this: >>> Scene 1 - current active speaker >>> Scene 2 - previous active speaker >>> Scene 3 - previous previous active speaker and so on... >> >> I understand your *intent* here. But I don't know how the consumer acts on >> that. It is really part of the point I am trying to make. >> How does the consumer *know* the above, and take it into account? >> Are the *scenes* tagged to indicate that? (I don't think so.) > > [Duckworth, Mark] From the MCC policy attribute values. > >>> Where each scene could have multiple switched MCCs representing the >> scene, and the provider has some flexibility to group together different >> individual captures to include in the MCCs of a scene, depending on synchID >> and who is talking. >>> In this case, because of the policy attributes describing the MCCs, I think it >> makes perfect sense for a consumer to ask for all the video MCCs from Scene >> 1, and none of them from Scene 2 or Scene 3. The consumer has enough >> information to know this is a good choice if it wants to show video from the >> current active speaker, including multiple video captures with spatial >> relationship when the current speaker is in a multi-camera room. So in this >> case the consumer already has enough information to make a choice. >> >> I'm having difficulty imagining how to construct an algorithm for that. > > [Duckworth, Mark] Yeah, it can get complicated. But is it good enough for equipment from different vendors to interoperate in a reasonable way, even if it isn't the "best" way? I think so. I still think my proposed "consumer makes all the switching decisions" approach can solve a lot of these problems. I know Cisco used to have a goal to make its equipment work "better together". But in a sense that is exactly the thing that standards are working against. With CLUE, *how* would a vendor's equipment do better with other of its own, and just be "good enough" with others? Ultimately you can only do as good as the provided information allows you to do. I can see a few things: - a vendor is likely to make its equipment in configurations that are designed to be easily compatible with one another. E.g., just a small set of configurations, like 1,2, or 3 screens, all same size, all side by side with consistent spacing. - a vendor could use a consistent style to structure its advertisements. E.g., Always have one scene for room cameras and one more for presentations. - a vendor could build an algorithm for constructing configurations that special cases advertisements structured the way it does them. Then it could have very crude algorithms for anything else, or just fail for anything else. - a vendor could build an algorithm for constructing configurations that makes "leaps of faith" that aren't justified solely by what is in an advertisement, about how the captures in the advertisement work. (E.g., about the algorithm for switching, or how things are laid out in a composition.) - a vendor could add proprietary information to advertisements, or to the sip signaling, to convey extra information that allows one of its own consuming endpoints to do a better job of constructing a config than would be possible with just the standard information. Odds are that we will see all of the above. Certainly there are inherent advantages when the advertisement happens to contain an alternative that exactly matches the equipment in the consuming end. And that is more likely to happen with equipment from one vendor. But beyond that, IMO, if we do our job well, then it should be possible to construct a general purpose algorithm that will do as well as algorithms that are special cased or that make "leaps of faith" or use proprietary information. >> ISTM in this case that taking a cse from every scene will give the best user >> experience *if* the consumer has enough display resources to show all >> these. > > [Duckworth, Mark] I think "best experience" is subjective here. I think the consumer has enough information to make a good choice for a variety of different consumer capability levels in terms of number of decoders and displays it has. Suppose the consumer can receive no more than 3 video encodings. It could ask for the 3 MCCs from Scene 1, or it could ask for 1 MCC from each scene. But I would think it would do that only if each scene had a CSE with one MCC in it. Each choice could give the "best" experience, depending on what the consumer is trying to present to the human users. I agree that "best experience" is subjective. But I suspect if we worked out a lot of use cases, we could come close to agreeing to what the "best experience" would be, in the absence of explicit input from the end users in the room. I think what you are talking about is that there are a *set* of "plausible" configurations, that it might make sense to offer as a menu to the end user. >> If not, then it gets complex to sort out the tradeoffs. >> >> In this case, considering that a capture with "current active speaker" >> policy is more important than one with "previous active speaker". >> >> So I would suggest that the advertisement mark all the "current active >> speaker" captures with highest priority, and the others with descending >> priorities. > > [Duckworth, Mark] that's what I was thinking, but even that shouldn't be necessary because the consumer can make its own priority decision based on the policy attribute. Certainly it *can*. But then it must make a tradeoff between the importance of the policy and the importance of the priority in the decision. Lacking any understanding of the motivation for the priority assignments, it is hard to trade those off against one another. >> Then, the consumer could start out assuming it should *try* for one CSE >> from each scene. It can look at different combinations, taking one from each >> scene, and evaluate what it can do with that combination. For each one: >> >> If it can't handle all the captures from the selected cses, it can start casting >> out lower priority ones until it can handle it. Then it can assign a score, >> depending on the priorities of those it took, the priorities of those it had to >> abandon, and how much it had to "adjust" >> the ones it took to fit on its displays. >> >> And it can repeat that for all the combinations of one cse from each scene. >> And then pick out the combination with the best score. >> >> This is all very heuristic. Will take a lot of thought and testing to come up with >> something that does well. (It would be interesting to work this out in detail >> for some specific consumer configurations and see if it can actually find good >> renderings.) >> >> Having the advertisement provide a single set of CSEs across all the scenes >> would "help" in that it would reduce the number of combinations the >> consumer had to evaluate. > > [Duckworth, Mark] I'm not sure it would reduce anything. As Christian said, "The combinatorial issue becomes worse with the more Scenes that you have". I'm concerned that trying to add another layer of alternatives in the advertisement, that crosses scene boundaries, won't scale well. Or do you think it is really simpler than that? Are you envisioning the single set of CSEs could be kept small, even with many scenes? With separate CSE lists in each scene, the *consumer* has to evaluate all the combinations of one CSE from each scene. With a single CSE list, the *advertiser* has to consider all of those when constructing the advertisement. But it doesn't have to *include* them all in the advertisement. My gut tells me that when there are only a few then perhaps they are all interesting, but when they are many, that only a few will be interesting enough to include. The advertiser is pruning the choices, using information that it has that isn't necessarily available to the consumer. If the advertiser is typically going to include all the combinations, then going this way is a bad choice. And if the advertiser is going to limit what it includes because it is too much work, or makes the advertisement too big, even though it thinks the ones it is omitting would be useful, then this is also a bad idea. >>> I agree there could be other situations where the MCC policy attributes >> aren't enough information for the consumer to make a good choice. This is >> where I thought the media capture priority attribute should be used. I >> thought this was the purpose of adding the priority attribute in the first >> place. From the framework: >>> >>> 7.1.1.12. Priority >>> The priority attribute indicates a relative priority between different Media >> Captures. The Provider sets this priority, and the Consumer MAY use the >> priority to help decide which captures it wishes to receive. >>> The "priority" attribute is an integer which indicates a relative priority >> between Captures. For example it is possible to assign a priority between >> two presentation Captures that would allow a remote endpoint to determine >> which presentation is more important. Priority is assigned at the individual >> capture level. It represents the Provider's view of the relative priority >> between Captures with a priority. >>> >>> I don't understand why you say this isn't a priority issue, but rather an >> alternative issue. It seems to me your proposal of advertising different >> combinations of captures or CSEs across scene boundaries is just another >> way for the provider to express priorities. >> >> Surely it is a form of prioritization. But it can be more sophisticated than >> simply assigning a priority value to each individual capture. >> >> But consider, if prioritization were sufficient, we wouldn't need to have CSEs >> at all. We could simply have prioritized captures. ISTM that the reasons that >> CSEs are more powerful than priorities within a scene should still apply >> outside a scene. > > [Duckworth, Mark] That makes sense too, at a high level, but I'm having trouble understanding how to put it in practice. > >> As I described above, I *think* priorities plus per-scene cse lists can solve >> your use case. But the processing to use it that way is complex. > > [Duckworth, Mark] So are you saying your idea of using a single set of CSEs across all scenes can solve the same problems in a less complex way? I'm open to that, but still not sure it would be any less complex. I think it is less complex for the consumer to evaluate a single list than to evaluate combinations of choices from multiple lists. (Enumerating all the combinations and generating an equivalent single list to evaluate is of course a straightforward programming job. But I wonder if some implementers might instead go for "special casing".) When constructing a single list, rather than several, and choosing which combinations to include, the advertiser can use knowledge that can't otherwise be described in the advertisement and used by the consumer to choose. Thanks, Paul >> Thanks, >> Paul >> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Thursday, February 06, 2014 12:34 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] How to choose from multiple scenes >>>> >>>> I just realized I had missed this reply. See inline. >>>> >>>> On 1/27/14 10:33 PM, Christian Groves wrote: >>>>> Hello Paul, >>>>> >>>>> Please see below. >>>>> >>>>> Regards, Christian >>>>> >>>>> On 28/01/2014 10:06 AM, Paul Kyzivat wrote: >>>>>> * The problem: >>>>>> >>>>>> As we discussed in the interim today, it seems unclear what a >>>>>> consumer should do when receiving an advertisement with multiple >>>>>> scenes in order to get a sufficient representation of the >>>>>> advertised >>>> content. >>>>>> >>>>>> Our simple cases have been where there is one scene for the cameras >>>>>> in the room, and another scene for a presentation. In that case, >>>>>> one should take something from each scene (typically one CSE from >>>>>> each) to get "enough". >>>>>> >>>>>> That is also true if an MCU acted in "pass through" mode and simply >>>>>> included "copies" of all the scenes it receives in advertisements, >>>>>> with encodings for them all. >>>>>> >>>>>> In a "simple" case with an MCU use MCC, it might "pass through" all >>>>>> the advertisements it receives, for their spatial info, but not >>>>>> provide any encodings for them. Rather, it would provide one or >>>>>> more new scenes using MCC to aggregate those sources. Then one >>>>>> would not want to configure from the "pass through" scenes, but >>>>>> that isn't an option anyway if there are no encodings for them. >>>>> [CNG] The idea of the pass through information was that the consumer >>>>> could use any capture attribute (not just spatial ones) to determine >>>>> what media it wanted. >>>> >>>> Clearly if there are no encodings, then the captures are there only >>>> for information and can't be configured. >>>> >>>> That is why I called this the "simple" case. >>>> >>>>>> Mark has proposed using multiple scenes with MCC to illustrate >>>>>> switched cases where some groupings don't have any spatial >>>>>> relationship to one another. Some of those examples end up with >>>>>> multiple scenes that do have encodings, where it doesn't make sense >>>>>> to configure something from each scene. >>>>> [CNG] I don't think there's anything in the framework that says a >>>>> consumer must choose a capture from a scene. >>>> >>>> Of course there is no MUST. The consumer isn't required take *anything*. >>>> >>>> The question is how the consumer knows what is required to have a >>>> "complete" representation of what is in the advertisement. It may not >>>> want all that, but it is hard to make a good choice without knowing. >>>> >>>> That is the point of CSEs - for the advertiser to indicate what it >>>> considers to be good alternative choices. But CSEs only work within a >>>> scene. Once there are multiple scenes, the consumer has less guidance >>>> on what would be good (or sufficient) choices. >>>> >>>> The consumer has *some* information: >>>> - if none of the captures in a scene have encodings, then there is >>>> no need (or way) to select them directly >>>> >>>> - if MCC M in scene X references capture C in scene Y, then it >>>> would be redundant to configure both M and C >>>> >>>> ISTM that one should start out assuming that you need all captures >>>> (that have encodings) in *some* CSE from *each* scene. You can then >>>> prune that based on the logic above. But is that *enough* to make good >> decisions? >>>> At best, the logic to figure that out is complex. >>>> >>>>>> Today we discussed using priority to solve this, but this isn't >>>>>> really a priority problem, it is a problem of *alternatives* that >>>>>> may be equally desirable, depending on the resources or desires of >>>>>> the >>>> consumer. >>>>> [CNG] I agree I don't think priority is the right solution for this. >>>>>> >>>>>> IMO the problem is that our CSE mechanism is a way for the >>>>>> advertiser to suggest alternatives, but this only works on a per-scene >> basis. >>>>>> The advertiser has no comparable mechanism to suggest alternatives >>>>>> from different scenes. >>>>>> >>>>>> * My proposed solution: >>>>>> >>>>>> I want to restate a proposal I made a long time ago: >>>>>> >>>>>> Instead of one CSE list per scene, have one CSE list >>>>>> per-advertisement, referencing captures from any scene. >>>>>> >>>>>> This makes it possible for the advertiser to recommend combinations >>>>>> that cross scene boundaries. >>>>> [CNG] Perhaps you could give some examples? Does the list need to be >>>>> exhaustive? >>>> >>>> Does the CSE list in a scene have to be exhaustive? >>>> >>>> I think each entry should be "sufficient" for somebody that can't >>>> handle a bigger one. The definition of "sufficient" is subjective. >>>> >>>>> e.g. the simple case today >>>>> Scene1 CSE1(VC1,VC2,VC3) >>>>> CSE2(VC4) >>>>> Scene2 CSE3(VC5,presentation1) >>>>> >>>>> Does it mean now the Advertisement would now have to advertise? >>>>> CSE1(VC1,VC2,VC3,VC5) >>>>> CSE2(VC4,VC5) >>>>> CSE3(VC1,VC2,VC3) >>>>> CSE4(VC4) >>>>> CSE5(VC5) >>>> >>>> As I said, the definition of "sufficient" is subjective. >>>> IMO the advertisement ought to include at least CSE1,CSE2. >>>> >>>> Rather than include the others, I think I would adjust the priorities >>>> of the individual captures based on my judgement of which I think >>>> should be kept if they all can't be. >>>> >>>> Thanks, >>>> Paul >>>> >>>>>> * An alternate solution: >>>>>> >>>>>> Another possibility would be to leave CSEs as they are, but add >>>>>> something analogous to a CSE list, but that lists recommended >>>>>> combinations of scenes. >>>>>> >>>>>> Thanks, >>>>>> Paul >>> > > From Christian.Groves@nteczone.com Sun Feb 9 15:39:17 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937811A0624 for ; Sun, 9 Feb 2014 15:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PesWFJcXwYtj for ; Sun, 9 Feb 2014 15:39:14 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9265C1A042A for ; Sun, 9 Feb 2014 15:39:13 -0800 (PST) Received: from ppp118-209-243-72.lns20.mel6.internode.on.net ([118.209.243.72]:51145 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCdwz-0004Xu-TD for clue@ietf.org; Mon, 10 Feb 2014 10:38:14 +1100 Message-ID: <52F811A0.6060405@nteczone.com> Date: Mon, 10 Feb 2014 10:39:12 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <52D44B95.7080906@alum.mit.edu> <52DC7E14.9080603@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB192@CRPMBOXPRD07.polycom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Ticket #33: Security for Framework document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 09 Feb 2014 23:39:17 -0000 Hello Mary, With regards to passing media with no knowledge of the content there is an aspect that IS unique to CLUE. CLUE actually indicates metadata about the content of the media. Traditional MCUs establish the media without asserting any knowledge of the media content. A CLUE MCU establishes the media and asserts to know something about the content of the media (i.e. through CLUE attributes). In the case of an MCC this will be information from the sources. As a consumer of traditional media about all I expect is that the media comes from where I think it does. However in a CLUE session i'll know the size, language, description, participants etc. This data could be manipulated to case "issues" with capture selection and rendering etc. An MCU would have to make a decision on whether the sources are trusted before passing the content information forward. This is probably covered in paragraph 6 below where it says " /It might also be// // possible for an attacker to manipulate the information and disrupt // // the CLUE sessions"./ I think that applies to almost any protocol. Although I don't think it really highlights the MCU's role as an aggregation point for CLUE information in a session. Regards, Christian On 8/02/2014 6:20 AM, Mary Barnes wrote: > Below please find, the updated text for the security considerations > that incorporates the comments made by Paul and Christian. I did not > add anything new with regards to Christian's point about MCUs passing > media with no knowledge of content. That's not unique to CLUE - it's > the same for any middle box that forwards media in the form of video. > > I think it's in good enough shape to add the framework now. We can of > course make additional changes later. > > Thanks, > Mary. > > There are several potential attacks related to > telepresence, and specifically the protocols used by CLUE, > in the case of conferencing sessions, > due to the natural involvement of multiple endpoints > and the many, often user-invoked, capabilities provided by the > systems. > > A middle box involved in a CLUE session can experience > many of the same attacks as that of a conferencing system such > as that enabled by the XCON framework [RFC 6503]. > Examples of attacks include the following: an > endpoint attempting to listen to sessions in which it is not > authorized to participate, an endpoint attempting to disconnect or > mute other users, and theft of service by an endpoint in attempting > to create telepresence sessions it is not allowed to create. > Thus, it is RECOMMENDED that a middle box implementing the protocols > necessary to support CLUE, follow the security recommendations > specified in the > conference control protocol documents. In the case of CLUE, SIP is > the > default conferencing protocol, thus the security considerations in > RFC 4579 > MUST be followed. > > One primary security concern, surrounding the CLUE framework > introduced in this document, involves securing the actual protocols > and the associated authorization mechanisms. These concerns > apply to endpoint to endpoint sessions, as well as sessions > involving multiple > endpoints and middle boxes. > Figure 2 in section 5 provides a basic flow of information exchange > for CLUE > and the protocols involved. > > As described in section 5, CLUE uses SIP/SDP to establish the > session prior to > exchanging any CLUE specific information. Thus the security mechanisms > recommended for SIP [RFC 3261], including user authentication and > authorization, > SHOULD be followed. In addition, the media is based on RTP and thus > existing RTP security mechanisms, such as DTLS/SRTP, MUST be supported. > A separate data channel is established to transport the CLUE > protocol messages. > The contents of the CLUE protocol messages are based on information > introduced in > this document, which is represented by an XML schema for this > information > defined in the CLUE data model [ref]. Some of the information which > could possibly > introduce privacy concerns is the xCard information as described in > section x. > In addition, the (text) description field in the Media Capture > attribute > (section 7.1.1.7) could possibly reveal sensitive information or > specific identities. > The same would be true for the descriptions in the Capture Scene > (section 7.3.1) > and Capture Scene Entry (7.3.2) attributes. One other important > consideration for > the information in the xCard as well as the description field in > the Media Capture > and Capture Scene Entry attributes is that while the endpoints > involved in the session > have been authenticated, there is no assurance that the information > in the xCard > or description fields is authentic. > Thus, this information SHOULD not be used to make any authorization > decisions > and the participants in the sessions SHOULD be made aware of this. > > While other information in the CLUE protocol messages does not reveal > specific > identities, it can reveal characteristics and capabilities of the > endpoints. That > information could possibly uniquely identify specific endpoints. It > might also be > possible for an attacker to manipulate the information and disrupt > the CLUE sessions. It would also be possible to mount a DoS attack > on the CLUE endpoints if a malicious agent has access to the data > channel. > Thus, It MUST be possible for the endpoints to establish a channel > which is > secure against both message recovery and message modification. > Further details > on this are provided in the CLUE data channel solution document. > > There are also security issues associated with the authorization to > perform actions at the CLUE endpoints to invoke specific > capabilities (e.g., re-arranging screens, sharing content, etc.). > However, the policies and security associated with these actions are > outside the > scope of this document and the overall CLUE solution. > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Sun Feb 9 16:42:47 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C871A063D for ; Sun, 9 Feb 2014 16:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQS8f-QKljEh for ; Sun, 9 Feb 2014 16:42:44 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910361A0637 for ; Sun, 9 Feb 2014 16:42:44 -0800 (PST) Received: from ppp118-209-243-72.lns20.mel6.internode.on.net ([118.209.243.72]:52256 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCewR-000665-CC; Mon, 10 Feb 2014 11:41:43 +1100 Message-ID: <52F82082.3050106@nteczone.com> Date: Mon, 10 Feb 2014 11:42:42 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 00:42:47 -0000 Hello Christer, Thanks for updating the draft. It looks better with more meat on it. Some comments/questions: 3.2 Para.2 - I've raised this before "is it possible to have multiple CLUE bi-directional CLUE Data Channels per SCTP association"? I can't think of a case where this would be needed??? If its not needed then I would suggest a slight update to make this clear, i.e. " The realization of a bidirectional CLUE Data Channel is a pair of one incoming SCTP stream and one outgoing SCTP stream <>. These streams are then used to transport CLUE messages in both directions." 3.2 Para.4 - Is this a MUST or a SHOULD? To me there are no exceptions to a MUST, in the sentence we list an exception that allows the use of another id. 3.4.1 - I guess now we'll only specify the new PID value indicating UTF-8 (and 50 for WebRTC if used) based on recent discussions on the RTCWeb list? 3.4.2 - "CLUE entities MUST use the reliable transport SCTP feature." This sounds like there is a special service or function for this? I thought reliability is inherent to SCTP? May we could reword to something like "CLUE entities must support the SCTP which ensures reliable transport of CLUE messages." If you wanted to be more specific with regards to RTCweb data protocol you could add something like: "In the context of [ID.ietf-rtcweb-data-protocol] the use of a "DATA_CHANNEL_RELIABLE" channel." 3.4.3 - I propose to be a bit more concrete: "CLUE entities MUST use the ordered delivery SCTP <>. 3.4.5 - I think there are dodgy reference, interleaving is described in . 6 - I mentioned earlier that if we use RTCWEB data channel we need to define CLUE as a protocol. So I propose adding something like: [ID.ietf-rtcweb-data-protocol] defines a new "Protocol Registry" for the data channel protocol to manage the "Protocol" field of type string in DATA_CHANNEL_OPEN messages. If CLUE is [ID.ietf-rtcweb-data-protocol] is used a new protocol value for CLUE is required. The following values need to be registered: +--------------+-----------+ | Name | Reference | +--------------+-----------+ | CLUE | [RFCXXXX] | +--------------+-----------+ [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.] Note: [ID.ejzak-dispatch-webrtc-data-channel-sdpneg] also contains a "sub-protocol" parameter. The IANA registry that will be used for recording the protocols is still under discussion. "CLUE" should also be registered in this registry. Regards, Christian On 7/02/2014 11:12 PM, Christer Holmberg wrote: > > Hi, > > Based on the discussions on the CLUE- and RTCWEB lists, I’ve submitted > a new version of the CLUE data channel draft. > > There are still open issue, and I have probably not implemented > everyone’s change wishes. It is more to add some more meat, and > continue the discussions. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Sun Feb 9 16:56:08 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B6F1A0654 for ; Sun, 9 Feb 2014 16:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8gKEfT07Pib for ; Sun, 9 Feb 2014 16:56:03 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D6C1A0649 for ; Sun, 9 Feb 2014 16:56:02 -0800 (PST) Received: from ppp118-209-243-72.lns20.mel6.internode.on.net ([118.209.243.72]:52398 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCf9K-0008Oi-Mx for clue@ietf.org; Mon, 10 Feb 2014 11:55:03 +1100 Message-ID: <52F823A1.3080308@nteczone.com> Date: Mon, 10 Feb 2014 11:56:01 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> <52F553B4.8070206@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB7FC@CRPMBOXPRD07.polycom.com> <52F6754A.3050501@alum.mit.edu> In-Reply-To: <52F6754A.3050501@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 00:56:08 -0000 Hello Paul, I think some uses cases would be good. I'd like to see a third case where we'd have something like a "Scene Set Entry" (SSE). This would indicate what scenes would make up a "full' description of an endpoint. i.e. Scene1 (CSE1) Scene2 (CSE2) Scene3 (CSE3) SSE [(Scene1,Scene2),(Scene1)] A consumer would know it should pick CSE1 and CSE2 for a complete description or CSE3. I think this is along the lines of your single CSE. Regards, Christian On 9/02/2014 5:19 AM, Paul Kyzivat wrote: > On 2/7/14 5:58 PM, Duckworth, Mark wrote: >> Hi Paul, >> Comments inline. >> I'm open to your idea of a single set of CSEs across all scenes, but >> I'm trying to understand if it will really be a scalable and less >> complex way to solve these issues. > > Me too. I'm not certain that it will, but my gut says so. > It just seems to me that the idea of enumerating useful combinations > of captures in the advertisement is conceptually unrelated to what > scene they are in, and that for the consumer the process then by > default devolves to just choosing the one best cse that works for it, > rather than having to choose from among combinations in different scenes. > >> Do you think it would help if you presented this idea at the design >> team meeting next week? > > I'm not convinced that call time is very helpful for this. > To be useful I would probably need to create several use cases, and > show them both ways, and then for people to try to shoot them down. > I think that kind of thing is better done by email. (And I don't have > time to put together sufficient use cases before Tuesday.) > > More below. > >> Mark >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Friday, February 07, 2014 4:44 PM >>> To: Duckworth, Mark; clue@ietf.org >>> Subject: Re: [clue] How to choose from multiple scenes >>> >>> On 2/7/14 3:26 PM, Duckworth, Mark wrote: >>>> Hi Paul, >>>> >>>> You describe the issue very well, but I don't agree with a couple >>>> things. You >>> wrote: >>>>> ISTM that one should start out assuming that you need all captures >>>>> (that have encodings) in *some* CSE from *each* scene. >>>> I don't think that is an appropriate thing to assume. The case I >>>> was thinking >>> of, and we have been talking about at design team meetings, is like >>> this: >>>> Scene 1 - current active speaker >>>> Scene 2 - previous active speaker >>>> Scene 3 - previous previous active speaker and so on... >>> >>> I understand your *intent* here. But I don't know how the consumer >>> acts on >>> that. It is really part of the point I am trying to make. >>> How does the consumer *know* the above, and take it into account? >>> Are the *scenes* tagged to indicate that? (I don't think so.) >> >> [Duckworth, Mark] From the MCC policy attribute values. >> >>>> Where each scene could have multiple switched MCCs representing the >>> scene, and the provider has some flexibility to group together >>> different >>> individual captures to include in the MCCs of a scene, depending on >>> synchID >>> and who is talking. >>>> In this case, because of the policy attributes describing the MCCs, >>>> I think it >>> makes perfect sense for a consumer to ask for all the video MCCs >>> from Scene >>> 1, and none of them from Scene 2 or Scene 3. The consumer has enough >>> information to know this is a good choice if it wants to show video >>> from the >>> current active speaker, including multiple video captures with spatial >>> relationship when the current speaker is in a multi-camera room. So >>> in this >>> case the consumer already has enough information to make a choice. >>> >>> I'm having difficulty imagining how to construct an algorithm for that. >> >> [Duckworth, Mark] Yeah, it can get complicated. But is it good >> enough for equipment from different vendors to interoperate in a >> reasonable way, even if it isn't the "best" way? I think so. I >> still think my proposed "consumer makes all the switching decisions" >> approach can solve a lot of these problems. > > I know Cisco used to have a goal to make its equipment work "better > together". But in a sense that is exactly the thing that standards are > working against. > > With CLUE, *how* would a vendor's equipment do better with other of > its own, and just be "good enough" with others? Ultimately you can > only do as good as the provided information allows you to do. I can > see a few things: > > - a vendor is likely to make its equipment in configurations that > are designed to be easily compatible with one another. E.g., just > a small set of configurations, like 1,2, or 3 screens, all same > size, all side by side with consistent spacing. > > - a vendor could use a consistent style to structure its advertisements. > E.g., Always have one scene for room cameras and one more for > presentations. > > - a vendor could build an algorithm for constructing configurations > that special cases advertisements structured the way it does them. > Then it could have very crude algorithms for anything else, or > just fail for anything else. > > - a vendor could build an algorithm for constructing configurations > that makes "leaps of faith" that aren't justified solely by what > is in an advertisement, about how the captures in the advertisement > work. (E.g., about the algorithm for switching, or how things are > laid out in a composition.) > > - a vendor could add proprietary information to advertisements, or to > the sip signaling, to convey extra information that allows one of > its own consuming endpoints to do a better job of constructing a > config than would be possible with just the standard information. > > Odds are that we will see all of the above. Certainly there are > inherent advantages when the advertisement happens to contain an > alternative that exactly matches the equipment in the consuming end. > And that is more likely to happen with equipment from one vendor. > > But beyond that, IMO, if we do our job well, then it should be > possible to construct a general purpose algorithm that will do as well > as algorithms that are special cased or that make "leaps of faith" or > use proprietary information. > >>> ISTM in this case that taking a cse from every scene will give the >>> best user >>> experience *if* the consumer has enough display resources to show all >>> these. >> >> [Duckworth, Mark] I think "best experience" is subjective here. I >> think the consumer has enough information to make a good choice for a >> variety of different consumer capability levels in terms of number of >> decoders and displays it has. Suppose the consumer can receive no >> more than 3 video encodings. It could ask for the 3 MCCs from Scene >> 1, or it could ask for 1 MCC from each scene. But I would think it >> would do that only if each scene had a CSE with one MCC in it. Each >> choice could give the "best" experience, depending on what the >> consumer is trying to present to the human users. > > I agree that "best experience" is subjective. But I suspect if we > worked out a lot of use cases, we could come close to agreeing to what > the "best experience" would be, in the absence of explicit input from > the end users in the room. > > I think what you are talking about is that there are a *set* of > "plausible" configurations, that it might make sense to offer as a > menu to the end user. > >>> If not, then it gets complex to sort out the tradeoffs. >>> >>> In this case, considering that a capture with "current active speaker" >>> policy is more important than one with "previous active speaker". >>> >>> So I would suggest that the advertisement mark all the "current active >>> speaker" captures with highest priority, and the others with descending >>> priorities. >> >> [Duckworth, Mark] that's what I was thinking, but even that shouldn't >> be necessary because the consumer can make its own priority decision >> based on the policy attribute. > > Certainly it *can*. But then it must make a tradeoff between the > importance of the policy and the importance of the priority in the > decision. Lacking any understanding of the motivation for the priority > assignments, it is hard to trade those off against one another. > >>> Then, the consumer could start out assuming it should *try* for one CSE >>> from each scene. It can look at different combinations, taking one >>> from each >>> scene, and evaluate what it can do with that combination. For each one: >>> >>> If it can't handle all the captures from the selected cses, it can >>> start casting >>> out lower priority ones until it can handle it. Then it can assign a >>> score, >>> depending on the priorities of those it took, the priorities of >>> those it had to >>> abandon, and how much it had to "adjust" >>> the ones it took to fit on its displays. >>> >>> And it can repeat that for all the combinations of one cse from each >>> scene. >>> And then pick out the combination with the best score. >>> >>> This is all very heuristic. Will take a lot of thought and testing >>> to come up with >>> something that does well. (It would be interesting to work this out >>> in detail >>> for some specific consumer configurations and see if it can actually >>> find good >>> renderings.) >>> >>> Having the advertisement provide a single set of CSEs across all the >>> scenes >>> would "help" in that it would reduce the number of combinations the >>> consumer had to evaluate. >> >> [Duckworth, Mark] I'm not sure it would reduce anything. As >> Christian said, "The combinatorial issue becomes worse with the more >> Scenes that you have". I'm concerned that trying to add another >> layer of alternatives in the advertisement, that crosses scene >> boundaries, won't scale well. Or do you think it is really simpler >> than that? Are you envisioning the single set of CSEs could be kept >> small, even with many scenes? > > With separate CSE lists in each scene, the *consumer* has to evaluate > all the combinations of one CSE from each scene. > > With a single CSE list, the *advertiser* has to consider all of those > when constructing the advertisement. But it doesn't have to *include* > them all in the advertisement. My gut tells me that when there are > only a few then perhaps they are all interesting, but when they are > many, that only a few will be interesting enough to include. The > advertiser is pruning the choices, using information that it has that > isn't necessarily available to the consumer. > > If the advertiser is typically going to include all the combinations, > then going this way is a bad choice. And if the advertiser is going to > limit what it includes because it is too much work, or makes the > advertisement too big, even though it thinks the ones it is omitting > would be useful, then this is also a bad idea. > >>>> I agree there could be other situations where the MCC policy >>>> attributes >>> aren't enough information for the consumer to make a good choice. >>> This is >>> where I thought the media capture priority attribute should be used. I >>> thought this was the purpose of adding the priority attribute in the >>> first >>> place. From the framework: >>>> >>>> 7.1.1.12. Priority >>>> The priority attribute indicates a relative priority between >>>> different Media >>> Captures. The Provider sets this priority, and the Consumer MAY use >>> the >>> priority to help decide which captures it wishes to receive. >>>> The "priority" attribute is an integer which indicates a relative >>>> priority >>> between Captures. For example it is possible to assign a priority >>> between >>> two presentation Captures that would allow a remote endpoint to >>> determine >>> which presentation is more important. Priority is assigned at the >>> individual >>> capture level. It represents the Provider's view of the relative >>> priority >>> between Captures with a priority. >>>> >>>> I don't understand why you say this isn't a priority issue, but >>>> rather an >>> alternative issue. It seems to me your proposal of advertising >>> different >>> combinations of captures or CSEs across scene boundaries is just >>> another >>> way for the provider to express priorities. >>> >>> Surely it is a form of prioritization. But it can be more >>> sophisticated than >>> simply assigning a priority value to each individual capture. >>> >>> But consider, if prioritization were sufficient, we wouldn't need to >>> have CSEs >>> at all. We could simply have prioritized captures. ISTM that the >>> reasons that >>> CSEs are more powerful than priorities within a scene should still >>> apply >>> outside a scene. >> >> [Duckworth, Mark] That makes sense too, at a high level, but I'm >> having trouble understanding how to put it in practice. >> >>> As I described above, I *think* priorities plus per-scene cse lists >>> can solve >>> your use case. But the processing to use it that way is complex. >> >> [Duckworth, Mark] So are you saying your idea of using a single set >> of CSEs across all scenes can solve the same problems in a less >> complex way? I'm open to that, but still not sure it would be any >> less complex. > > I think it is less complex for the consumer to evaluate a single list > than to evaluate combinations of choices from multiple lists. > (Enumerating all the combinations and generating an equivalent single > list to evaluate is of course a straightforward programming job. But I > wonder if some implementers might instead go for "special casing".) > > When constructing a single list, rather than several, and choosing > which combinations to include, the advertiser can use knowledge that > can't otherwise be described in the advertisement and used by the > consumer to choose. > > Thanks, > Paul > >>> Thanks, >>> Paul >>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>> Sent: Thursday, February 06, 2014 12:34 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] How to choose from multiple scenes >>>>> >>>>> I just realized I had missed this reply. See inline. >>>>> >>>>> On 1/27/14 10:33 PM, Christian Groves wrote: >>>>>> Hello Paul, >>>>>> >>>>>> Please see below. >>>>>> >>>>>> Regards, Christian >>>>>> >>>>>> On 28/01/2014 10:06 AM, Paul Kyzivat wrote: >>>>>>> * The problem: >>>>>>> >>>>>>> As we discussed in the interim today, it seems unclear what a >>>>>>> consumer should do when receiving an advertisement with multiple >>>>>>> scenes in order to get a sufficient representation of the >>>>>>> advertised >>>>> content. >>>>>>> >>>>>>> Our simple cases have been where there is one scene for the cameras >>>>>>> in the room, and another scene for a presentation. In that case, >>>>>>> one should take something from each scene (typically one CSE from >>>>>>> each) to get "enough". >>>>>>> >>>>>>> That is also true if an MCU acted in "pass through" mode and simply >>>>>>> included "copies" of all the scenes it receives in advertisements, >>>>>>> with encodings for them all. >>>>>>> >>>>>>> In a "simple" case with an MCU use MCC, it might "pass through" all >>>>>>> the advertisements it receives, for their spatial info, but not >>>>>>> provide any encodings for them. Rather, it would provide one or >>>>>>> more new scenes using MCC to aggregate those sources. Then one >>>>>>> would not want to configure from the "pass through" scenes, but >>>>>>> that isn't an option anyway if there are no encodings for them. >>>>>> [CNG] The idea of the pass through information was that the consumer >>>>>> could use any capture attribute (not just spatial ones) to determine >>>>>> what media it wanted. >>>>> >>>>> Clearly if there are no encodings, then the captures are there only >>>>> for information and can't be configured. >>>>> >>>>> That is why I called this the "simple" case. >>>>> >>>>>>> Mark has proposed using multiple scenes with MCC to illustrate >>>>>>> switched cases where some groupings don't have any spatial >>>>>>> relationship to one another. Some of those examples end up with >>>>>>> multiple scenes that do have encodings, where it doesn't make sense >>>>>>> to configure something from each scene. >>>>>> [CNG] I don't think there's anything in the framework that says a >>>>>> consumer must choose a capture from a scene. >>>>> >>>>> Of course there is no MUST. The consumer isn't required take >>>>> *anything*. >>>>> >>>>> The question is how the consumer knows what is required to have a >>>>> "complete" representation of what is in the advertisement. It may not >>>>> want all that, but it is hard to make a good choice without knowing. >>>>> >>>>> That is the point of CSEs - for the advertiser to indicate what it >>>>> considers to be good alternative choices. But CSEs only work within a >>>>> scene. Once there are multiple scenes, the consumer has less guidance >>>>> on what would be good (or sufficient) choices. >>>>> >>>>> The consumer has *some* information: >>>>> - if none of the captures in a scene have encodings, then there is >>>>> no need (or way) to select them directly >>>>> >>>>> - if MCC M in scene X references capture C in scene Y, then it >>>>> would be redundant to configure both M and C >>>>> >>>>> ISTM that one should start out assuming that you need all captures >>>>> (that have encodings) in *some* CSE from *each* scene. You can then >>>>> prune that based on the logic above. But is that *enough* to make >>>>> good >>> decisions? >>>>> At best, the logic to figure that out is complex. >>>>> >>>>>>> Today we discussed using priority to solve this, but this isn't >>>>>>> really a priority problem, it is a problem of *alternatives* that >>>>>>> may be equally desirable, depending on the resources or desires of >>>>>>> the >>>>> consumer. >>>>>> [CNG] I agree I don't think priority is the right solution for this. >>>>>>> >>>>>>> IMO the problem is that our CSE mechanism is a way for the >>>>>>> advertiser to suggest alternatives, but this only works on a >>>>>>> per-scene >>> basis. >>>>>>> The advertiser has no comparable mechanism to suggest alternatives >>>>>>> from different scenes. >>>>>>> >>>>>>> * My proposed solution: >>>>>>> >>>>>>> I want to restate a proposal I made a long time ago: >>>>>>> >>>>>>> Instead of one CSE list per scene, have one CSE list >>>>>>> per-advertisement, referencing captures from any scene. >>>>>>> >>>>>>> This makes it possible for the advertiser to recommend combinations >>>>>>> that cross scene boundaries. >>>>>> [CNG] Perhaps you could give some examples? Does the list need to be >>>>>> exhaustive? >>>>> >>>>> Does the CSE list in a scene have to be exhaustive? >>>>> >>>>> I think each entry should be "sufficient" for somebody that can't >>>>> handle a bigger one. The definition of "sufficient" is subjective. >>>>> >>>>>> e.g. the simple case today >>>>>> Scene1 CSE1(VC1,VC2,VC3) >>>>>> CSE2(VC4) >>>>>> Scene2 CSE3(VC5,presentation1) >>>>>> >>>>>> Does it mean now the Advertisement would now have to advertise? >>>>>> CSE1(VC1,VC2,VC3,VC5) >>>>>> CSE2(VC4,VC5) >>>>>> CSE3(VC1,VC2,VC3) >>>>>> CSE4(VC4) >>>>>> CSE5(VC5) >>>>> >>>>> As I said, the definition of "sufficient" is subjective. >>>>> IMO the advertisement ought to include at least CSE1,CSE2. >>>>> >>>>> Rather than include the others, I think I would adjust the priorities >>>>> of the individual captures based on my judgement of which I think >>>>> should be kept if they all can't be. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>>> * An alternate solution: >>>>>>> >>>>>>> Another possibility would be to leave CSEs as they are, but add >>>>>>> something analogous to a CSE list, but that lists recommended >>>>>>> combinations of scenes. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>> >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Sun Feb 9 17:15:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF091A0649 for ; Sun, 9 Feb 2014 17:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpfimcXQ05Wo for ; Sun, 9 Feb 2014 17:15:47 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0795C1A051B for ; Sun, 9 Feb 2014 17:15:47 -0800 (PST) Received: from ppp118-209-243-72.lns20.mel6.internode.on.net ([118.209.243.72]:52722 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCfSQ-0003Xn-Iq for clue@ietf.org; Mon, 10 Feb 2014 12:14:46 +1100 Message-ID: <52F82841.5010001@nteczone.com> Date: Mon, 10 Feb 2014 12:15:45 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB54F@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB54F@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Maxcaptures in MCC, vs. switched and composed attributes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 01:15:50 -0000 Hello I don't think removal of MaxCaptures is an option. I gave an example to Paul why its needed. It was buried deep in an email thread so i'll repeat it here: I see there is benefit in giving the Advertiser and the Consumer the means of knowing how many captures will appear in the stream at a time. It gives the ability for the Consumer to distinguish between MCCs. For example: What if the Advertiser combines two sources set but switches the sources? i.e. MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=2 Are both the "switched" and "composed" attributes valid? MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Switched,Composed How about the case where the Advertiser composes 4 sources into a media stream switches those sources? MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=4 Using the composed and switched attributes: MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Switched,Composed Now how does a consumer distinguish between MCC1, MCC2 in this case? I think its a valid decision for a Consumer to make it determine how many sources it wants to see at a particular time. It can't use the spatial information because we've disallowed that. I don't think the "switched" and "composed" attributes can model that. Regards, Christian On 8/02/2014 3:26 AM, Duckworth, Mark wrote: > I'm trying to summarize a couple of related proposals here. > 1. Add ability for advertiser to indicate if the number of captures in an MCC at any given time will always be equal to MaxCaptures, or if it can be less. Details below from Christian. > 2. Add Switched and Composed attributes to MCC, just like we used to have for all captures. This is proposed in draft-ietf-clue-data-model-schema-03. Maybe remove the MaxCaptures attribute if we add switched and composed. > > We can do one or the other, or both, or neither. Any of those choices is okay with me, I personally have no strong argument either way. I think others in the group have stronger preferences. I think the default is to do neither, unless there is consensus to change. Please continue the discussion so we can figure out if any change is needed in the framework and data model. > > Regards, > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Thursday, February 06, 2014 11:50 PM >> To: clue@ietf.org >> Subject: Re: [clue] Maxcaptures in MCC >> >> Hello Mark, >> >> To be more concrete here's the text I would propose for the framework: >> >> 7.2.1.1. Maximum Number of Captures within a MCC >> >> The Maximum Number of Captures MCC attribute indicates the maximum >> number of individual captures that may appear in a Capture Encoding >> at a time. <>> the actual >> number at any given time can be less than >> this maximum. It may be used to derive how the Single Media >> Captures within the MCC are composed / switched with regards to >> space and time. <> is equal >> to the maximum the Consumer MUST not choose a subset of captures >> from the MCC in a >> Configure message.>> >> >> Max Captures MAY be set to one so that only content related to one >> of the sources are shown in the MCC Capture Encoding at a time or >> it may be set to any value up to the total number of Source Media >> Captures in the MCC. >> >> If this attribute is not set then as default it is assumed that <> of sources>> >> can appear concurrently in the Capture Encoding associated with the MCC. >> >> For example: The use of MaxCaptures equal to 1 on a MCC with three >> Video Captures VC1, VC2 and VC3 would indicate that the Advertiser >> in the capture encoding would switch between VC1, VC2 or VC3 as >> there may be only a maximum of one capture at a time. >> >> Regards, Christian >> >> On 7/02/2014 11:45 AM, Christian Groves wrote: >>> Hello Mark, >>> >>> My proposed improvement is to update the MaxCaptures parameter add >> the >>> possibility to indicate indicate that the value is "equal to" as well >>> as allowing the specification as per today "less than or equal to". >>> >>> Regards, Christian >>> >>> On 7/02/2014 3:55 AM, Duckworth, Mark wrote: >>>> Hi Christian, >>>> >>>> I think I understand the general idea you are getting at, but I don't >>>> understand specifically what you are proposing as an improvement. >>>> More comments inline. >>>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>> Groves >>>>> Sent: Wednesday, February 05, 2014 7:20 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't >>>>> describe video locations within composed MCC >>>>> >>>>> Hello Paul and Mark, >>>>> >>>>> The Max-captures attributes currently indicates the maximum number >>>>> of captures that appears in a MCC at any particular point in time. >>>>> >>>>> i.e. MCC(VC1,VC2,VC3),MaxCaptures=3 >>>>> So a Consumer has to assume because this is a maximum that VC1, VC2, >>>>> VC3, (VC1,VC2), (VC1,VC3), (VC2,VC3) or (VC1,VC2,VC3) can appear at >>>>> any point in time. >>>> [Duckworth, Mark] I agree, that is consistent with framework-13. >>>> >>>>> However the Consumer only ever sends a composition of >> (VC1,VC2,VC3). >>>>> It is >>>>> never going to change that combination. >>>> [Duckworth, Mark] Do you mean the Provider will always send a >>>> composition of (VC1,VC2,VC3)? And the provider would like to be more >>>> explicit about this in the advertisement? >>>> >>>>> It seems to me that in this case >>>>> using MaxCaptures as it is currently defined is semantically incorrect. >>>> [Duckworth, Mark] I think it is correct, but maybe not giving as much >>>> information as the provider wants to express. >>> [CNG] I can't see its correct. If I tell you that I can do a set of >>> behaviour but I only intend to do one then I don't think that's >>> truthful. Sort of like telling you I'm coming to your house one day >>> next week when in fact I only intend on coming on Friday. >>>>> So what I am suggesting is simply to add a way to correctly indicate >>>>> this "constant number of captures" case, i.e. (VC1,VC2,VC3). >>>> [Duckworth, Mark] If I understand your suggestion correctly, then one >>>> way to do that would be to add a new optional MinCaptures attribute >>>> to an MCC. MinCaptures is the minimum number of constituent captures >>>> that may appear in the MCC at a time. If this attribute is not set, >>>> then it is assumed to have the default value of 1. For this >>>> scenario, the value of both MinCaptures and MaxCaptures would be 3. >>>> Is this what you are suggesting, or do you have something else in mind? >>> [CNG] No all I had in mind was something like: >>> MaxCaptures "="/"<=" value >>> The Advertiser would chose to indicate "equal" or "equal to or >>> less than". >>>>> I think Paul is questioning the attribute in general. I do believe >>>>> that knowing the number of sources may be beneficial for a consumer >>>>> in deciding which MCC/Captures to select. There may be tradeoffs vs >>>>> a MCC only showing a limited number (i.e. one source) at a time vs >>>>> another MCC showing multiple sources at a time. >>> [CNG] I agree I think its beneficial. >>>>> 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 christer.holmberg@ericsson.com Sun Feb 9 23:19:04 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F5C1A07B3 for ; Sun, 9 Feb 2014 23:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNpfO5vH5v7H for ; Sun, 9 Feb 2014 23:19:01 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 688681A0214 for ; Sun, 9 Feb 2014 23:19:01 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-cb-52f87d642d6f Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 06.F2.23809.46D78F25; Mon, 10 Feb 2014 08:19:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 08:19:00 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Draft new version: draft-holmberg-clue-datachannel-01 Thread-Index: Ac8j/b3fWVgMoVOPRmi4Z2O6oFTWFAB8uHkAAA91YTA= Date: Mon, 10 Feb 2014 07:18:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> <52F82082.3050106@nteczone.com> In-Reply-To: <52F82082.3050106@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+JvjW5K7Y8gg7eP1S2+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJUx5cpJpoJ/8hXrH+xmaWA8JNnFyMkhIWAi sefTORYIW0ziwr31bF2MXBxCAocYJS7svwvlLGaUWLh4I3MXIwcHm4CFRPc/bZAGEYFwiY5t VxhBbGEBT4nuh2eYIeJeElcmHIayrSSWLbkMVsMioCrxtuUxE4jNK+ArcfPwG7AaIYF8ifYp K8FqOAV0JJqPLACLMwId9P3UGrB6ZgFxiVtP5jNBHCogsWTPeWYIW1Ti5eN/rBC2osTOs+3M EPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxciem5iZk15u tIkRGAsHt/xW3cF455zIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBy xC1ifnYgb72r7eVH+7l5PxZ2fZQTUD/Y8fjkgWnVfzYftjU+Z/I+W7ogJGnxUm6Rx4rq31Ok WSIio4sfXzy1UPuSB9ePQ7OVgqbH/dfSeh2eO+O10aLpWvLdW18xfd25O1/y7tKnb3YKc2h9 C9n5+uasi2xHDhw9JLpIdM/mAy+lVlS2tvS/UmIpzkg01GIuKk4EAGQ5UfxTAgAA Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 07:19:04 -0000 Hi Christian, > Some comments/questions: > > 3.2 Para.2 - I've raised this before "is it possible to have multiple CLU= E bi-directional CLUE Data Channels per SCTP association"? I can't think of= a > case where this would be needed??? If its not needed then I would suggest= a slight update to make this clear, i.e. > "The realization of a bidirectional CLUE Data Channel is a pair of one in= coming SCTP stream and one outgoing SCTP stream < association>>. These streams are then used to transport CLUE messages in = both directions." Eventhough I can't think of a case either, I am not sure whether we need to= forbid having multiple CLUE channels per SCTP association. But, I think we= should NOT allow using multiple CLUE channels in a single CLUE session. > 3.2 Para.4 - Is this a MUST or a SHOULD? To me there are no exceptions to= a MUST, in the sentence we list an exception that allows the use of anothe= r id. It is currently a MUST. But, we need to verify that e.g. JavaScript applications do have full contr= ol of setting the stream id value. > 3.4.1 - I guess now we'll only specify the new PID value indicating > UTF-8 (and 50 for WebRTC if used) based on recent discussions on the RTCW= eb list? Correct.=20 In the next version of the draft I will use a "XX" value, which will be rep= laced with whatever value RTCWEB registers for UTF-8 strings. > 3.4.2 - "CLUE entities MUST use the reliable transport SCTP feature."=20 >This sounds like there is a special service or function for this? I though= t reliability is inherent to SCTP? May we could reword to something like "C= LUE entities must support the SCTP which ensures reliable transport of CLUE= messages." Ok. > If you wanted to be more specific with regards to RTCweb data protocol yo= u could add something like: "In the context of [ID.ietf-rtcweb-data-protoco= l] the use of a "DATA_CHANNEL_RELIABLE"=20 > channel." I'd suggest we leave that until we have determined whether we will use the = rtcweb data protocol. > 3.4.3 - I propose to be a bit more concrete: > "CLUE entities MUST use the ordered delivery SCTP <>. Ok. > 3.4.5 - I think there are dodgy reference, interleaving is described in <= I-D.stewart-tsvwg-sctp-ndata>. Will be fixed. > 6 - I mentioned earlier that if we use RTCWEB data channel we need to def= ine CLUE as a protocol. So I propose adding something like: > > [ID.ietf-rtcweb-data-protocol] defines a new "Protocol Registry" for the = data channel protocol to manage the "Protocol" field of type string in=20 > DATA_CHANNEL_OPEN messages. If CLUE is [ID.ietf-rtcweb-data-protocol] is = used a new protocol value for CLUE is required. > The following values need to be registered: > > +--------------+-----------+ > | Name | Reference | > +--------------+-----------+ > | CLUE | [RFCXXXX] | > +--------------+-----------+ > > [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this doc= ument.] I can mention in in section 3.3. But, again, until we have decided whether = we will use the protocol or not, we don't need to specify too much. > Note: [ID.ejzak-dispatch-webrtc-data-channel-sdpneg] also contains a "sub= -protocol" parameter. The IANA registry that will be used for recording the= protocols is still under discussion. "CLUE" should also be registered in t= his registry. Assuming we'll use the draft, yes. Thanks! Regards, Christer On 7/02/2014 11:12 PM, Christer Holmberg wrote: > > Hi, > > Based on the discussions on the CLUE- and RTCWEB lists, I've submitted=20 > a new version of the CLUE data channel draft. > > There are still open issue, and I have probably not implemented=20 > everyone's change wishes. It is more to add some more meat, and=20 > continue the discussions. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Mon Feb 10 01:01:37 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010C71A07C0 for ; Mon, 10 Feb 2014 01:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53jZ2UWvdotV for ; Mon, 10 Feb 2014 01:01:35 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id A0E1D1A07BB for ; Mon, 10 Feb 2014 01:01:33 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-7e-52f8956ce773 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 93.CD.04853.C6598F25; Mon, 10 Feb 2014 10:01:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 10:01:31 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft new version: draft-holmberg-clue-datachannel-02 Thread-Index: Ac8mPpRWKCiJN7yhRMaythspM1EuFw== Date: Mon, 10 Feb 2014 09:01:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D166A34@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_7594FB04B1934943A5C02806D1A2204B1D166A34ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+JvjW7O1B9BBlN+K1rsP3WZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGc2v+9gLFotWLN28lqWB8bNQFyMnh4SAicS9a22MELaYxIV7 69lAbCGBE4wSKyfFdTFyAdmLGSXe/V7E1MXIwcEmYCHR/U8bpEZEQFni6OZ+sHphATuJpzff MEHEnSXmPFoFZetJ3L37B8xmEVCVePl+EwuIzSvgK7Fz3RdmEJsRaO/3U2vAapgFxCVuPZnP BHGPgMSSPeeZIWxRiZeP/7FC2IoSO8+2M4OcwyyQL/FmUhbESEGJkzOfsExgFJqFZNIshKpZ SKogSnQkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYySxanFxbnpRgZ6uem5JXqpRZnJxcX5 eXrFqZsYgVFxcMtvox2MJ/fYH2KU5mBREue9zloTJCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoGxZ9leadevNXYvP9sUly2ZVHF0Q5Pt+b2HzyYY5ys1Z3CcyWzdHlRxIfTzSZtfnmqyM1hC u3W+zjph9VBtRV5c6td5Dpyvpn7SbVY54Zlt+Sp2X6kI78LMtXriKzR1i6ueqepVs+zevORk eMFWmRc5ptNYJLgFcoPTPhs7/zPhvH9Iai8j134lluKMREMt5qLiRAA7m1GqWAIAAA== Subject: [clue] Draft new version: draft-holmberg-clue-datachannel-02 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 09:01:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D166A34ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on more feedback and comments from Paul and Christian, and discussion= s on the RTCWEB list, I've again submitted a new version of the CLUE data c= hannel draft. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D166A34ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on more feedback and comments from Paul and Ch= ristian, and discussions on the RTCWEB list, I’ve again submitted a n= ew version of the CLUE data channel draft.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D166A34ESESSMB209erics_-- From Christian.Groves@nteczone.com Mon Feb 10 03:26:44 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDD71A0809 for ; Mon, 10 Feb 2014 03:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrE07_5ODnvM for ; Mon, 10 Feb 2014 03:26:43 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0CB1A0808 for ; Mon, 10 Feb 2014 03:26:42 -0800 (PST) Received: from ppp118-209-243-72.lns20.mel6.internode.on.net ([118.209.243.72]:51570 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WCozY-0002BW-8c; Mon, 10 Feb 2014 22:25:36 +1100 Message-ID: <52F8B770.2010906@nteczone.com> Date: Mon, 10 Feb 2014 22:26:40 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> <52F82082.3050106@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:26:45 -0000 Hello Christer, Please see below. Regards, Christian On 10/02/2014 6:18 PM, Christer Holmberg wrote: > Hi Christian, > >> Some comments/questions: >> >> 3.2 Para.2 - I've raised this before "is it possible to have multiple CLUE bi-directional CLUE Data Channels per SCTP association"? I can't think of a >> case where this would be needed??? If its not needed then I would suggest a slight update to make this clear, i.e. >> "The realization of a bidirectional CLUE Data Channel is a pair of one incoming SCTP stream and one outgoing SCTP stream <> association>>. These streams are then used to transport CLUE messages in both directions." > Eventhough I can't think of a case either, I am not sure whether we need to forbid having multiple CLUE channels per SCTP association. But, I think we should NOT allow using multiple CLUE channels in a single CLUE session. [CNG] A single CLUE session is signified by a single CLUE data channel which is a pair of SCTP streams, correct? Having a single CLUE session (or any other bearer level application protocol) per SCTP association would certainly simplify things in gateways. If there are going to be multiple instances there's going to need to be more co-ordination of SCTP stream numbers vs protocol instances. ..snip.. From christer.holmberg@ericsson.com Mon Feb 10 03:44:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8501A0828 for ; Mon, 10 Feb 2014 03:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7Rei5-xQD5Y for ; Mon, 10 Feb 2014 03:44:26 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 446CD1A0821 for ; Mon, 10 Feb 2014 03:44:25 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-11-52f8bb993977 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 19.29.04853.99BB8F25; Mon, 10 Feb 2014 12:44:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 12:44:25 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Draft new version: draft-holmberg-clue-datachannel-01 Thread-Index: Ac8j/b3fWVgMoVOPRmi4Z2O6oFTWFAB8uHkAAA91YTAABwgiAAACjT6A Date: Mon, 10 Feb 2014 11:44:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D166FE7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> <52F82082.3050106@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se> <52F8B770.2010906@nteczone.com> In-Reply-To: <52F8B770.2010906@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+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvje7M3T+CDFr+qFp8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugStjxsMPbAVP+Sp29Ig3MD7j7mLk5JAQMJE4 eLqBHcIWk7hwbz0biC0kcIJR4lJTbhcjF5C9mFHi8/X5TF2MHBxsAhYS3f+0QWpEBMIlOrZd YQSxhQU8JbofnmGGiHtJXJlwmBmkXETATWLvP3eQMIuAqsSy9h2sIDavgK9EV/MpZojxVxkl mqfuZQFJcAroSNxo6gWbwwh0z/dTa5hAbGYBcYlbT+YzQdwpILFkz3lmCFtU4uXjf6wQtqLE zrPtzBD1OhILdn9ig7C1JZYtfM0MsVhQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUoWZxa XJybbmSgl5ueW6KXWpSZXFycn6dXnLqJERgrB7f8NtrBeHKP/SFGaQ4WJXHe66w1QUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYJ7N9ETrqw+ihqZPc8bNN6fwft/f199YZrmBck/be4dGS iTP3s5//lulmaizW8Yz73dyoa5e4ZGZvL4+I0t2xSbftLGs5m4HnonwdFX9vlX3PX6+uS7pb m/jqisDKD0/sZ8Rsnc8vNmeefWD3i2P3pZ+cNI694Nlbe/7ZRNfFZX93pPqtU1nPp8RSnJFo qMVcVJwIAPua021jAgAA Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 11:44:28 -0000 Hi, >>> Some comments/questions: >>> >>> 3.2 Para.2 - I've raised this before "is it possible to have multiple=20 >>> CLUE bi-directional CLUE Data Channels per SCTP association"? I can't t= hink of a case where this would be needed??? If its not needed then I would= suggest a slight update to make this clear, i.e. >>> "The realization of a bidirectional CLUE Data Channel is a pair of=20 >>> one incoming SCTP stream and one outgoing SCTP stream <>> association >>>. These streams are then used to transport CLUE messages in both directi= ons." >> Eventhough I can't think of a case either, I am not sure whether we need= to forbid having multiple CLUE channels per SCTP association. But, I think= we should NOT allow using multiple CLUE channels in a single CLUE session. >[CNG] A single CLUE session is signified by a single CLUE data channel whi= ch is a pair of SCTP streams, correct? Correct. >Having a single CLUE session (or any other bearer level application protoc= ol) per SCTP association would certainly simplify things in gateways. If th= ere are going to be multiple instances there's going to need to be more co-= ordination of >SCTP stream numbers vs protocol instances. Well, it IS allowed to have multiple instances per SCTP association, so in = general you can't avoid that. But, in CLUE we can for sure restrict the num= ber of CLUE data channels to one per SCTP association. However, as you may have seen on the RTCWEB list, at least when using the D= CP there is no way to prevent the establishment of TWO data channels, if bo= th endpoints create one at the same time. That may not be an issue for CLUE= , though, if we don't use the DCP, AND/OR we specify which endpoint is resp= onsible for opening the data channel. It could e.g. be based on offerer/ans= wer role, DTLS role, etc. Regards, Christer From pkyzivat@alum.mit.edu Mon Feb 10 06:47:22 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C784E1A084A for ; Mon, 10 Feb 2014 06:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJZrt6UadXD6 for ; Mon, 10 Feb 2014 06:47:21 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 48B651A02E1 for ; Mon, 10 Feb 2014 06:47:21 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta12.westchester.pa.mail.comcast.net with comcast id Qde51n0061HzFnQ5CenM0H; Mon, 10 Feb 2014 14:47:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id QenL1n00h3ZTu2S3aenLCV; Mon, 10 Feb 2014 14:47:21 +0000 Message-ID: <52F8E678.1010306@alum.mit.edu> Date: Mon, 10 Feb 2014 09:47:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D166A34@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D166A34@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392043641; bh=sZjwQLTfTVZEjPlUh4evmMk3h8413rK0roNVsm1vDOo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NPLCUDnOLN7rWHyjxLZ2rsqHKX3sLvuW4dCcmeMikTAKtMzYMAJQoslSxzqow7Z/l jU4NdFIQmytStPkAbMhCi4yxWIq4c3pRAyzV76gDVNkCZzaiQr9uGNFtW8w3ZUNy4L A035Yj80TjA5cjRSEVGA8A7tAngCzIGebuvKXgyAq9KYyC5YWlUni9OF6oRl1NgbDQ n7zCxltm15EcGVsPwSrrsZQ0wZvFd8qUhI+iPmiA13wDxY4k5VOer7r2m9+J1n4OOn 8BBFNeep1+fLNrWOON+Q3DtY5VS9LmiMH0+/KsQmWr4beSNAgZluwG5voy9KuBZLZZ 9o5pLxkQ5grQw== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-02 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 14:47:23 -0000 Christer, This is looking good. I think a next step should be to align draft-kyzivat-clue-signaling draft-presta-clue-protocol draft-holmberg-clue-datachannel This is likely to require small changes to all of them. For instance, sequencing of events across the three - the normal ones for session startup, error recovery, and termination of the clue channel. (And it will require decisions about some of your open issues.) Rob & Roberta, what do you think about that? What do you think you need before we can get these all aligned? Thanks, Paul On 2/10/14 4:01 AM, Christer Holmberg wrote: > Hi, > > Based on more feedback and comments from Paul and Christian, and > discussions on the RTCWEB list, I’ve again submitted a new version of > the CLUE data channel draft. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Feb 10 06:56:45 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002CE1A02FA for ; Mon, 10 Feb 2014 06:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjiZ3rONO0B5 for ; Mon, 10 Feb 2014 06:56:43 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3671A02E1 for ; Mon, 10 Feb 2014 06:56:43 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id QdaW1n0031swQuc51ewj8g; Mon, 10 Feb 2014 14:56:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id Qewi1n00d3ZTu2S3bewinN; Mon, 10 Feb 2014 14:56:43 +0000 Message-ID: <52F8E8AA.9060903@alum.mit.edu> Date: Mon, 10 Feb 2014 09:56:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> <52F82082.3050106@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D166757@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=1392044203; bh=gEC6PTMOjsv995cLKw7wG8yNDdEGrfsUfUebErXVppg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VNon53L9HCalirOK44+KvhP9jYwm2QuejQofR3OuI217UIgaSG+TUf227yZ6Fdttu lVmBMjKNS88c0Nai6HQnWc9YrXxermuYyfvcoeTS8BXVMAz4FpKlC+uYqO4v6OtzXV YW7NsqyDVw8oAaUafdsTNRlx+aEG3VRcr13E3Xy61/JP1p22se7kLQqCeZtYQG46H/ SVasmuSVCCe5pY4oaM/rfS9i+35hYFMAP1wms3UvXSHWvvwJ67WM3pQaewGoIP2Xri uLC7ueMyjS/Tedp4Lt4I/OSS5+gO323j9TAozb55PuRknJLqvD4bx6++sh69Ymm0RL YAwGvugPlOALg== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 14:56:45 -0000 Regarding use of data channel protocol vs. ejzak draft: I think there is a tradeoff: - using data channel protocol will probably be substantially easier for an rtcweb client. And I think we are more confident that the data channel protocol will become an RFC. (RTCWEB doesn't *need* the ejzak draft. It could just fade away.) - but using the ejzak draft allows negotiating the use of CLUE in the SDP O/A. With data channel protocol, there is no indication of that until after the SCTP association has been established. (You might get that far, and then discover the other end intended to use the SCTP for something else, and doesn't do clue.) Thanks, Paul On 2/10/14 2:18 AM, Christer Holmberg wrote: > Hi Christian, > >> Some comments/questions: >> >> 3.2 Para.2 - I've raised this before "is it possible to have multiple CLUE bi-directional CLUE Data Channels per SCTP association"? I can't think of a >> case where this would be needed??? If its not needed then I would suggest a slight update to make this clear, i.e. >> "The realization of a bidirectional CLUE Data Channel is a pair of one incoming SCTP stream and one outgoing SCTP stream <> association>>. These streams are then used to transport CLUE messages in both directions." > > Eventhough I can't think of a case either, I am not sure whether we need to forbid having multiple CLUE channels per SCTP association. But, I think we should NOT allow using multiple CLUE channels in a single CLUE session. > >> 3.2 Para.4 - Is this a MUST or a SHOULD? To me there are no exceptions to a MUST, in the sentence we list an exception that allows the use of another id. > > It is currently a MUST. > > But, we need to verify that e.g. JavaScript applications do have full control of setting the stream id value. > >> 3.4.1 - I guess now we'll only specify the new PID value indicating >> UTF-8 (and 50 for WebRTC if used) based on recent discussions on the RTCWeb list? > > Correct. > > In the next version of the draft I will use a "XX" value, which will be replaced with whatever value RTCWEB registers for UTF-8 strings. > >> 3.4.2 - "CLUE entities MUST use the reliable transport SCTP feature." >> This sounds like there is a special service or function for this? I thought reliability is inherent to SCTP? May we could reword to something like "CLUE entities must support the SCTP which ensures reliable transport of CLUE messages." > > Ok. > >> If you wanted to be more specific with regards to RTCweb data protocol you could add something like: "In the context of [ID.ietf-rtcweb-data-protocol] the use of a "DATA_CHANNEL_RELIABLE" >> channel." > > I'd suggest we leave that until we have determined whether we will use the rtcweb data protocol. > > >> 3.4.3 - I propose to be a bit more concrete: >> "CLUE entities MUST use the ordered delivery SCTP <>. > > Ok. > >> 3.4.5 - I think there are dodgy reference, interleaving is described in . > > Will be fixed. > >> 6 - I mentioned earlier that if we use RTCWEB data channel we need to define CLUE as a protocol. So I propose adding something like: >> >> [ID.ietf-rtcweb-data-protocol] defines a new "Protocol Registry" for the data channel protocol to manage the "Protocol" field of type string in >> DATA_CHANNEL_OPEN messages. If CLUE is [ID.ietf-rtcweb-data-protocol] is used a new protocol value for CLUE is required. >> The following values need to be registered: >> >> +--------------+-----------+ >> | Name | Reference | >> +--------------+-----------+ >> | CLUE | [RFCXXXX] | >> +--------------+-----------+ >> >> [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.] > > I can mention in in section 3.3. But, again, until we have decided whether we will use the protocol or not, we don't need to specify too much. > >> Note: [ID.ejzak-dispatch-webrtc-data-channel-sdpneg] also contains a "sub-protocol" parameter. The IANA registry that will be used for recording the protocols is still under discussion. "CLUE" should also be registered in this registry. > > Assuming we'll use the draft, yes. > > Thanks! > > Regards, > > Christer > > > On 7/02/2014 11:12 PM, Christer Holmberg wrote: >> >> Hi, >> >> Based on the discussions on the CLUE- and RTCWEB lists, I've submitted >> a new version of the CLUE data channel draft. >> >> There are still open issue, and I have probably not implemented >> everyone's change wishes. It is more to add some more meat, and >> continue the discussions. >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Feb 10 07:36:36 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5A81A0320 for ; Mon, 10 Feb 2014 07:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uASvfEQK0bjw for ; Mon, 10 Feb 2014 07:36:35 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 292021A030F for ; Mon, 10 Feb 2014 07:36:35 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id QdhV1n0021swQuc51fcb2k; Mon, 10 Feb 2014 15:36:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id Qfca1n01C3ZTu2S3bfcasd; Mon, 10 Feb 2014 15:36:34 +0000 Message-ID: <52F8F202.2010603@alum.mit.edu> Date: Mon, 10 Feb 2014 10:36:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> <52F82082.3050106@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se> <52F8B770.2010906@nteczone.com> In-Reply-To: <52F8B770.2010906@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=1392046595; bh=UNZcvZ0NNdC/7Dsv1wGc6z2IqB9aybzwiUHuXXiNS3g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XMncVEqSLTBAzsF2wcs1e4EqosfahQJVVwrfEobwHaKWyax54boDZfyDOiBybpn4g LmZ3ccJMj85ot9dSfjxAZAs3t8ovXQIWyA50WzkbkEFaon55pGA6Ez5b+kB6oT+9Wq yakAwnDauJxoDoYZ285oQAtItt11e77uMf8ULdQSTN+jJR30NVKxePXg5bzkBz4iNv kH1J4vogRf2MqCCWxSdBrzofxHbRBqG/74zymP0WHp7Q0RbYNfD2jGkmTf/nlQT4d5 LbV/NPSJa16Q0CihjFSwmwaGWwZA4ty5fJ9NYLz2etSKiuCdFGQpO1CfW4iVQrm4Vo mFWR6LYpUINmw== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 15:36:37 -0000 Christian, I hate to get over-prescriptive about what an application can do with other channels on the sctp association. We have yet to stitch all the pieces together. Clearly it is necessary for the application to have a way to identify the particular channel that will be used to control the clue session. This is a general problem for rtcweb. In the data channel protocol each channel has a protocol and a label. In the Ejzak draft each channel has a subprotocol and a label. (AFAIK 'protocol' and 'subprotocol' above are the same thing.) I believe the expectation is in general that there can be several channels with the same (sub)protocol, and that they are intended to be referenced individually by 'label'. One possibility is that we standardize a particular label value that identifies the channel used in a clue session. Another is that we use some new clue-specific SDP syntax to negotiate the which channel is used for CLUE. Thanks, Paul On 2/10/14 6:26 AM, Christian Groves wrote: > Hello Christer, > > Please see below. > > Regards, Christian > > On 10/02/2014 6:18 PM, Christer Holmberg wrote: >> Hi Christian, >> >>> Some comments/questions: >>> >>> 3.2 Para.2 - I've raised this before "is it possible to have multiple >>> CLUE bi-directional CLUE Data Channels per SCTP association"? I can't >>> think of a >>> case where this would be needed??? If its not needed then I would >>> suggest a slight update to make this clear, i.e. >>> "The realization of a bidirectional CLUE Data Channel is a pair of >>> one incoming SCTP stream and one outgoing SCTP stream <>> association>>. These streams are then used to transport CLUE messages >>> in both directions." >> Eventhough I can't think of a case either, I am not sure whether we >> need to forbid having multiple CLUE channels per SCTP association. >> But, I think we should NOT allow using multiple CLUE channels in a >> single CLUE session. > [CNG] A single CLUE session is signified by a single CLUE data channel > which is a pair of SCTP streams, correct? > > Having a single CLUE session (or any other bearer level application > protocol) per SCTP association would certainly simplify things in > gateways. If there are going to be multiple instances there's going to > need to be more co-ordination of SCTP stream numbers vs protocol instances. > > ..snip.. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Feb 10 07:38:30 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573B11A0320 for ; Mon, 10 Feb 2014 07:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWvrEf0OLEMA for ; Mon, 10 Feb 2014 07:38:29 -0800 (PST) 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 D5B4A1A030F for ; Mon, 10 Feb 2014 07:38:28 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta08.westchester.pa.mail.comcast.net with comcast id Qd171n00327AodY58feUab; Mon, 10 Feb 2014 15:38:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id QfeU1n00U3ZTu2S3ffeUWT; Mon, 10 Feb 2014 15:38:28 +0000 Message-ID: <52F8F274.2000607@alum.mit.edu> Date: Mon, 10 Feb 2014 10:38:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> <52F82082.3050106@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se> <52F8B770.2010906@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D166FE7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D166FE7@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=1392046708; bh=2jp+pF+NFpCoKJiTtDlhyZd7ev4AmXGAc/MTTL5CYnQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iapBFwaJtBtkOCz40mrZeL9Zox83AqI7X3nEgdMYeRyAS48kLDrehvPCo3oObWA2J YwdV6TDw4x3ONmVZLM3xIbVHEGeiRScEVGvh7jH7213r3PgRIzKACJiJElr9SKZrjK BpNeDy91g7KyH1Y+kSgBIOwHhSbVuUnt56NqdSUwkKzFO75ms4n3g6tqrRrSf1dMj2 it3wxOb14/FqRXmB4TEf83JpRE7qyhcdboljPm8K7wg1+tTTKRpKZ92kRKUIko+NLw enwmoyyy/tQAXfIyjC4mF3Jvrb+unWw/YZtSi8NGK4nK2+UATdQqmMZwP/S9Kp5jNA XAtItrBd+1imw== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 15:38:30 -0000 On 2/10/14 6:44 AM, Christer Holmberg wrote: > Hi, > >>>> Some comments/questions: >>>> >>>> 3.2 Para.2 - I've raised this before "is it possible to have multiple >>>> CLUE bi-directional CLUE Data Channels per SCTP association"? I can't think of a case where this would be needed??? If its not needed then I would suggest a slight update to make this clear, i.e. >>>> "The realization of a bidirectional CLUE Data Channel is a pair of >>>> one incoming SCTP stream and one outgoing SCTP stream <>>> association >>>> . These streams are then used to transport CLUE messages in both directions." >>> Eventhough I can't think of a case either, I am not sure whether we need to forbid having multiple CLUE channels per SCTP association. But, I think we should NOT allow using multiple CLUE channels in a single CLUE session. >> [CNG] A single CLUE session is signified by a single CLUE data channel which is a pair of SCTP streams, correct? > > Correct. > >> Having a single CLUE session (or any other bearer level application protocol) per SCTP association would certainly simplify things in gateways. If there are going to be multiple instances there's going to need to be more co-ordination of >SCTP stream numbers vs protocol instances. > > Well, it IS allowed to have multiple instances per SCTP association, so in general you can't avoid that. But, in CLUE we can for sure restrict the number of CLUE data channels to one per SCTP association. > > However, as you may have seen on the RTCWEB list, at least when using the DCP there is no way to prevent the establishment of TWO data channels, if both endpoints create one at the same time. That may not be an issue for CLUE, though, if we don't use the DCP, AND/OR we specify which endpoint is responsible for opening the data channel. It could e.g. be based on offerer/answer role, DTLS role, etc. If we use DCP, then we should address how to avoid that, or what to do if it occurs. Thanks, Paul From Mark.Duckworth@polycom.com Mon Feb 10 07:49:09 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FFF1A0846 for ; Mon, 10 Feb 2014 07:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhCzkxNa0Org for ; Mon, 10 Feb 2014 07:49:05 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE991A0320 for ; Mon, 10 Feb 2014 07:49:05 -0800 (PST) Received: from PWEHUB01.polycom.com (10.236.2.221) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 10 Feb 2014 07:49:05 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Mon, 10 Feb 2014 07:49:04 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Mon, 10 Feb 2014 07:49:00 -0800 Thread-Topic: [clue] How to choose from multiple scenes Thread-Index: Ac8l+uaQl7uJMsHwSM6d7JHcDj0/5AAfI1mQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB971@CRPMBOXPRD07.polycom.com> References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> <52F553B4.8070206@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB7FC@CRPMBOXPRD07.polycom.com> <52F6754A.3050501@alum.mit.edu> <52F823A1.3080308@nteczone.com> In-Reply-To: <52F823A1.3080308@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] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 15:49:09 -0000 Hello Christian, I don't understand your proposal for "Scene Set Entry". Can you try explai= ning again? > SSE [(Scene1,Scene2),(Scene1)] What does this mean? Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Sunday, February 09, 2014 7:56 PM > To: clue@ietf.org > Subject: Re: [clue] How to choose from multiple scenes > > Hello Paul, > > I think some uses cases would be good. > > I'd like to see a third case where we'd have something like a "Scene Set > Entry" (SSE). This would indicate what scenes would make up a "full' > description of an endpoint. > > i.e. Scene1 (CSE1) > Scene2 (CSE2) > Scene3 (CSE3) > SSE [(Scene1,Scene2),(Scene1)] > A consumer would know it should pick CSE1 and CSE2 for a complete > description or CSE3. > > I think this is along the lines of your single CSE. > > Regards, Christian > > On 9/02/2014 5:19 AM, Paul Kyzivat wrote: > > On 2/7/14 5:58 PM, Duckworth, Mark wrote: > >> Hi Paul, > >> Comments inline. > >> I'm open to your idea of a single set of CSEs across all scenes, but > >> I'm trying to understand if it will really be a scalable and less > >> complex way to solve these issues. > > > > Me too. I'm not certain that it will, but my gut says so. > > It just seems to me that the idea of enumerating useful combinations > > of captures in the advertisement is conceptually unrelated to what > > scene they are in, and that for the consumer the process then by > > default devolves to just choosing the one best cse that works for it, > > rather than having to choose from among combinations in different scene= s. > > > >> Do you think it would help if you presented this idea at the design > >> team meeting next week? > > > > I'm not convinced that call time is very helpful for this. > > To be useful I would probably need to create several use cases, and > > show them both ways, and then for people to try to shoot them down. > > I think that kind of thing is better done by email. (And I don't have > > time to put together sufficient use cases before Tuesday.) > > > > More below. > > > >> Mark > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>> Sent: Friday, February 07, 2014 4:44 PM > >>> To: Duckworth, Mark; clue@ietf.org > >>> Subject: Re: [clue] How to choose from multiple scenes > >>> > >>> On 2/7/14 3:26 PM, Duckworth, Mark wrote: > >>>> Hi Paul, > >>>> > >>>> You describe the issue very well, but I don't agree with a couple > >>>> things. You > >>> wrote: > >>>>> ISTM that one should start out assuming that you need all captures > >>>>> (that have encodings) in *some* CSE from *each* scene. > >>>> I don't think that is an appropriate thing to assume. The case I > >>>> was thinking > >>> of, and we have been talking about at design team meetings, is like > >>> this: > >>>> Scene 1 - current active speaker > >>>> Scene 2 - previous active speaker > >>>> Scene 3 - previous previous active speaker and so on... > >>> > >>> I understand your *intent* here. But I don't know how the consumer > >>> acts on that. It is really part of the point I am trying to make. > >>> How does the consumer *know* the above, and take it into account? > >>> Are the *scenes* tagged to indicate that? (I don't think so.) > >> > >> [Duckworth, Mark] From the MCC policy attribute values. > >> > >>>> Where each scene could have multiple switched MCCs representing > the > >>> scene, and the provider has some flexibility to group together > >>> different individual captures to include in the MCCs of a scene, > >>> depending on synchID and who is talking. > >>>> In this case, because of the policy attributes describing the MCCs, > >>>> I think it > >>> makes perfect sense for a consumer to ask for all the video MCCs > >>> from Scene 1, and none of them from Scene 2 or Scene 3. The > >>> consumer has enough information to know this is a good choice if it > >>> wants to show video from the current active speaker, including > >>> multiple video captures with spatial relationship when the current > >>> speaker is in a multi-camera room. So in this case the consumer > >>> already has enough information to make a choice. > >>> > >>> I'm having difficulty imagining how to construct an algorithm for tha= t. > >> > >> [Duckworth, Mark] Yeah, it can get complicated. But is it good > >> enough for equipment from different vendors to interoperate in a > >> reasonable way, even if it isn't the "best" way? I think so. I > >> still think my proposed "consumer makes all the switching decisions" > >> approach can solve a lot of these problems. > > > > I know Cisco used to have a goal to make its equipment work "better > > together". But in a sense that is exactly the thing that standards are > > working against. > > > > With CLUE, *how* would a vendor's equipment do better with other of > > its own, and just be "good enough" with others? Ultimately you can > > only do as good as the provided information allows you to do. I can > > see a few things: > > > > - a vendor is likely to make its equipment in configurations that > > are designed to be easily compatible with one another. E.g., just > > a small set of configurations, like 1,2, or 3 screens, all same > > size, all side by side with consistent spacing. > > > > - a vendor could use a consistent style to structure its advertisements= . > > E.g., Always have one scene for room cameras and one more for > > presentations. > > > > - a vendor could build an algorithm for constructing configurations > > that special cases advertisements structured the way it does them. > > Then it could have very crude algorithms for anything else, or > > just fail for anything else. > > > > - a vendor could build an algorithm for constructing configurations > > that makes "leaps of faith" that aren't justified solely by what > > is in an advertisement, about how the captures in the advertisement > > work. (E.g., about the algorithm for switching, or how things are > > laid out in a composition.) > > > > - a vendor could add proprietary information to advertisements, or to > > the sip signaling, to convey extra information that allows one of > > its own consuming endpoints to do a better job of constructing a > > config than would be possible with just the standard information. > > > > Odds are that we will see all of the above. Certainly there are > > inherent advantages when the advertisement happens to contain an > > alternative that exactly matches the equipment in the consuming end. > > And that is more likely to happen with equipment from one vendor. > > > > But beyond that, IMO, if we do our job well, then it should be > > possible to construct a general purpose algorithm that will do as well > > as algorithms that are special cased or that make "leaps of faith" or > > use proprietary information. > > > >>> ISTM in this case that taking a cse from every scene will give the > >>> best user experience *if* the consumer has enough display resources > >>> to show all these. > >> > >> [Duckworth, Mark] I think "best experience" is subjective here. I > >> think the consumer has enough information to make a good choice for a > >> variety of different consumer capability levels in terms of number of > >> decoders and displays it has. Suppose the consumer can receive no > >> more than 3 video encodings. It could ask for the 3 MCCs from Scene > >> 1, or it could ask for 1 MCC from each scene. But I would think it > >> would do that only if each scene had a CSE with one MCC in it. Each > >> choice could give the "best" experience, depending on what the > >> consumer is trying to present to the human users. > > > > I agree that "best experience" is subjective. But I suspect if we > > worked out a lot of use cases, we could come close to agreeing to what > > the "best experience" would be, in the absence of explicit input from > > the end users in the room. > > > > I think what you are talking about is that there are a *set* of > > "plausible" configurations, that it might make sense to offer as a > > menu to the end user. > > > >>> If not, then it gets complex to sort out the tradeoffs. > >>> > >>> In this case, considering that a capture with "current active speaker= " > >>> policy is more important than one with "previous active speaker". > >>> > >>> So I would suggest that the advertisement mark all the "current > >>> active speaker" captures with highest priority, and the others with > >>> descending priorities. > >> > >> [Duckworth, Mark] that's what I was thinking, but even that shouldn't > >> be necessary because the consumer can make its own priority decision > >> based on the policy attribute. > > > > Certainly it *can*. But then it must make a tradeoff between the > > importance of the policy and the importance of the priority in the > > decision. Lacking any understanding of the motivation for the priority > > assignments, it is hard to trade those off against one another. > > > >>> Then, the consumer could start out assuming it should *try* for one > >>> CSE from each scene. It can look at different combinations, taking > >>> one from each scene, and evaluate what it can do with that > >>> combination. For each one: > >>> > >>> If it can't handle all the captures from the selected cses, it can > >>> start casting out lower priority ones until it can handle it. Then > >>> it can assign a score, depending on the priorities of those it took, > >>> the priorities of those it had to abandon, and how much it had to > >>> "adjust" > >>> the ones it took to fit on its displays. > >>> > >>> And it can repeat that for all the combinations of one cse from each > >>> scene. > >>> And then pick out the combination with the best score. > >>> > >>> This is all very heuristic. Will take a lot of thought and testing > >>> to come up with something that does well. (It would be interesting > >>> to work this out in detail for some specific consumer configurations > >>> and see if it can actually find good > >>> renderings.) > >>> > >>> Having the advertisement provide a single set of CSEs across all the > >>> scenes would "help" in that it would reduce the number of > >>> combinations the consumer had to evaluate. > >> > >> [Duckworth, Mark] I'm not sure it would reduce anything. As > >> Christian said, "The combinatorial issue becomes worse with the more > >> Scenes that you have". I'm concerned that trying to add another > >> layer of alternatives in the advertisement, that crosses scene > >> boundaries, won't scale well. Or do you think it is really simpler > >> than that? Are you envisioning the single set of CSEs could be kept > >> small, even with many scenes? > > > > With separate CSE lists in each scene, the *consumer* has to evaluate > > all the combinations of one CSE from each scene. > > > > With a single CSE list, the *advertiser* has to consider all of those > > when constructing the advertisement. But it doesn't have to *include* > > them all in the advertisement. My gut tells me that when there are > > only a few then perhaps they are all interesting, but when they are > > many, that only a few will be interesting enough to include. The > > advertiser is pruning the choices, using information that it has that > > isn't necessarily available to the consumer. > > > > If the advertiser is typically going to include all the combinations, > > then going this way is a bad choice. And if the advertiser is going to > > limit what it includes because it is too much work, or makes the > > advertisement too big, even though it thinks the ones it is omitting > > would be useful, then this is also a bad idea. > > > >>>> I agree there could be other situations where the MCC policy > >>>> attributes > >>> aren't enough information for the consumer to make a good choice. > >>> This is > >>> where I thought the media capture priority attribute should be used. > >>> I thought this was the purpose of adding the priority attribute in > >>> the first place. From the framework: > >>>> > >>>> 7.1.1.12. Priority > >>>> The priority attribute indicates a relative priority between > >>>> different Media > >>> Captures. The Provider sets this priority, and the Consumer MAY use > >>> the priority to help decide which captures it wishes to receive. > >>>> The "priority" attribute is an integer which indicates a relative > >>>> priority > >>> between Captures. For example it is possible to assign a priority > >>> between two presentation Captures that would allow a remote > endpoint > >>> to determine which presentation is more important. Priority is > >>> assigned at the individual capture level. It represents the > >>> Provider's view of the relative priority between Captures with a > >>> priority. > >>>> > >>>> I don't understand why you say this isn't a priority issue, but > >>>> rather an > >>> alternative issue. It seems to me your proposal of advertising > >>> different combinations of captures or CSEs across scene boundaries > >>> is just another way for the provider to express priorities. > >>> > >>> Surely it is a form of prioritization. But it can be more > >>> sophisticated than simply assigning a priority value to each > >>> individual capture. > >>> > >>> But consider, if prioritization were sufficient, we wouldn't need to > >>> have CSEs at all. We could simply have prioritized captures. ISTM > >>> that the reasons that CSEs are more powerful than priorities within > >>> a scene should still apply outside a scene. > >> > >> [Duckworth, Mark] That makes sense too, at a high level, but I'm > >> having trouble understanding how to put it in practice. > >> > >>> As I described above, I *think* priorities plus per-scene cse lists > >>> can solve your use case. But the processing to use it that way is > >>> complex. > >> > >> [Duckworth, Mark] So are you saying your idea of using a single set > >> of CSEs across all scenes can solve the same problems in a less > >> complex way? I'm open to that, but still not sure it would be any > >> less complex. > > > > I think it is less complex for the consumer to evaluate a single list > > than to evaluate combinations of choices from multiple lists. > > (Enumerating all the combinations and generating an equivalent single > > list to evaluate is of course a straightforward programming job. But I > > wonder if some implementers might instead go for "special casing".) > > > > When constructing a single list, rather than several, and choosing > > which combinations to include, the advertiser can use knowledge that > > can't otherwise be described in the advertisement and used by the > > consumer to choose. > > > > Thanks, > > Paul > > > >>> Thanks, > >>> Paul > >>> > >>>> Mark > >>>> > >>>>> -----Original Message----- > >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul > >>>>> Kyzivat > >>>>> Sent: Thursday, February 06, 2014 12:34 PM > >>>>> To: clue@ietf.org > >>>>> Subject: Re: [clue] How to choose from multiple scenes > >>>>> > >>>>> I just realized I had missed this reply. See inline. > >>>>> > >>>>> On 1/27/14 10:33 PM, Christian Groves wrote: > >>>>>> Hello Paul, > >>>>>> > >>>>>> Please see below. > >>>>>> > >>>>>> Regards, Christian > >>>>>> > >>>>>> On 28/01/2014 10:06 AM, Paul Kyzivat wrote: > >>>>>>> * The problem: > >>>>>>> > >>>>>>> As we discussed in the interim today, it seems unclear what a > >>>>>>> consumer should do when receiving an advertisement with > multiple > >>>>>>> scenes in order to get a sufficient representation of the > >>>>>>> advertised > >>>>> content. > >>>>>>> > >>>>>>> Our simple cases have been where there is one scene for the > >>>>>>> cameras in the room, and another scene for a presentation. In > >>>>>>> that case, one should take something from each scene (typically > >>>>>>> one CSE from > >>>>>>> each) to get "enough". > >>>>>>> > >>>>>>> That is also true if an MCU acted in "pass through" mode and > >>>>>>> simply included "copies" of all the scenes it receives in > >>>>>>> advertisements, with encodings for them all. > >>>>>>> > >>>>>>> In a "simple" case with an MCU use MCC, it might "pass through" > >>>>>>> all the advertisements it receives, for their spatial info, but > >>>>>>> not provide any encodings for them. Rather, it would provide one > >>>>>>> or more new scenes using MCC to aggregate those sources. Then > >>>>>>> one would not want to configure from the "pass through" scenes, > >>>>>>> but that isn't an option anyway if there are no encodings for the= m. > >>>>>> [CNG] The idea of the pass through information was that the > >>>>>> consumer could use any capture attribute (not just spatial ones) > >>>>>> to determine what media it wanted. > >>>>> > >>>>> Clearly if there are no encodings, then the captures are there > >>>>> only for information and can't be configured. > >>>>> > >>>>> That is why I called this the "simple" case. > >>>>> > >>>>>>> Mark has proposed using multiple scenes with MCC to illustrate > >>>>>>> switched cases where some groupings don't have any spatial > >>>>>>> relationship to one another. Some of those examples end up with > >>>>>>> multiple scenes that do have encodings, where it doesn't make > >>>>>>> sense to configure something from each scene. > >>>>>> [CNG] I don't think there's anything in the framework that says a > >>>>>> consumer must choose a capture from a scene. > >>>>> > >>>>> Of course there is no MUST. The consumer isn't required take > >>>>> *anything*. > >>>>> > >>>>> The question is how the consumer knows what is required to have a > >>>>> "complete" representation of what is in the advertisement. It may > >>>>> not want all that, but it is hard to make a good choice without > knowing. > >>>>> > >>>>> That is the point of CSEs - for the advertiser to indicate what it > >>>>> considers to be good alternative choices. But CSEs only work > >>>>> within a scene. Once there are multiple scenes, the consumer has > >>>>> less guidance on what would be good (or sufficient) choices. > >>>>> > >>>>> The consumer has *some* information: > >>>>> - if none of the captures in a scene have encodings, then there is > >>>>> no need (or way) to select them directly > >>>>> > >>>>> - if MCC M in scene X references capture C in scene Y, then it > >>>>> would be redundant to configure both M and C > >>>>> > >>>>> ISTM that one should start out assuming that you need all captures > >>>>> (that have encodings) in *some* CSE from *each* scene. You can > >>>>> then prune that based on the logic above. But is that *enough* to > >>>>> make good > >>> decisions? > >>>>> At best, the logic to figure that out is complex. > >>>>> > >>>>>>> Today we discussed using priority to solve this, but this isn't > >>>>>>> really a priority problem, it is a problem of *alternatives* > >>>>>>> that may be equally desirable, depending on the resources or > >>>>>>> desires of the > >>>>> consumer. > >>>>>> [CNG] I agree I don't think priority is the right solution for thi= s. > >>>>>>> > >>>>>>> IMO the problem is that our CSE mechanism is a way for the > >>>>>>> advertiser to suggest alternatives, but this only works on a > >>>>>>> per-scene > >>> basis. > >>>>>>> The advertiser has no comparable mechanism to suggest > >>>>>>> alternatives from different scenes. > >>>>>>> > >>>>>>> * My proposed solution: > >>>>>>> > >>>>>>> I want to restate a proposal I made a long time ago: > >>>>>>> > >>>>>>> Instead of one CSE list per scene, have one CSE list > >>>>>>> per-advertisement, referencing captures from any scene. > >>>>>>> > >>>>>>> This makes it possible for the advertiser to recommend > >>>>>>> combinations that cross scene boundaries. > >>>>>> [CNG] Perhaps you could give some examples? Does the list need to > >>>>>> be exhaustive? > >>>>> > >>>>> Does the CSE list in a scene have to be exhaustive? > >>>>> > >>>>> I think each entry should be "sufficient" for somebody that can't > >>>>> handle a bigger one. The definition of "sufficient" is subjective. > >>>>> > >>>>>> e.g. the simple case today > >>>>>> Scene1 CSE1(VC1,VC2,VC3) > >>>>>> CSE2(VC4) > >>>>>> Scene2 CSE3(VC5,presentation1) > >>>>>> > >>>>>> Does it mean now the Advertisement would now have to advertise? > >>>>>> CSE1(VC1,VC2,VC3,VC5) > >>>>>> CSE2(VC4,VC5) > >>>>>> CSE3(VC1,VC2,VC3) > >>>>>> CSE4(VC4) > >>>>>> CSE5(VC5) > >>>>> > >>>>> As I said, the definition of "sufficient" is subjective. > >>>>> IMO the advertisement ought to include at least CSE1,CSE2. > >>>>> > >>>>> Rather than include the others, I think I would adjust the > >>>>> priorities of the individual captures based on my judgement of > >>>>> which I think should be kept if they all can't be. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>>>> * An alternate solution: > >>>>>>> > >>>>>>> Another possibility would be to leave CSEs as they are, but add > >>>>>>> something analogous to a CSE list, but that lists recommended > >>>>>>> combinations of scenes. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>> > >> > >> > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Feb 10 08:45:18 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9151A0335 for ; Mon, 10 Feb 2014 08:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_4YKBB2uPRw for ; Mon, 10 Feb 2014 08:45:14 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id CEDD61A0320 for ; Mon, 10 Feb 2014 08:45:13 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta04.westchester.pa.mail.comcast.net with comcast id QcTR1n0061swQuc54glDFq; Mon, 10 Feb 2014 16:45:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id QglD1n0043ZTu2S3bglDCK; Mon, 10 Feb 2014 16:45:13 +0000 Message-ID: <52F90219.4070504@alum.mit.edu> Date: Mon, 10 Feb 2014 11:45:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> <52F553B4.8070206@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB7FC@CRPMBOXPRD07.polycom.com> <52F6754A.3050501@alum.mit.edu> <52F823A1.3080308@nteczone.com> In-Reply-To: <52F823A1.3080308@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=1392050713; bh=j5gZWeGoM8WhY8uDEsq/o6gFV4D9DHKBB8MiA2tYgUE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SmbtdqZqNT8XMzY03hCfEXDjMkgmO8Tpbze/dQRqpErSYaGESomDWlzle/g8N9IFI TqOW07IkOC8HVou41k8+J/cPiT3RueyrP97dblt549BKTcA6oE11CE8CXm/v1ZBtpg yDVNilbiPpKjZ1ki9A6TSkg4jqG+wKOahAEzzCV9UBxUgesriJWu2o9J/xAzeig5i7 4Mv/BSuYZxgyiqhTc8xsAPHAPUEers9cQb4U0SE/ttD4tlZkpTlI2ujOxkGJ+kubKf pGnkMJF2QUy49lyp+R9oPaJp71mDOmPfTuHYeGKKkm0JofC6ThBE39F+Q0+zdN0CIv Ts5BI7rcOjeWg== Subject: Re: [clue] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 16:45:18 -0000 On 2/9/14 7:56 PM, Christian Groves wrote: > Hello Paul, > > I think some uses cases would be good. > > I'd like to see a third case where we'd have something like a "Scene Set > Entry" (SSE). This would indicate what scenes would make up a "full' > description of an endpoint. > > i.e. Scene1 (CSE1) > Scene2 (CSE2) > Scene3 (CSE3) > SSE [(Scene1,Scene2),(Scene1)] > A consumer would know it should pick CSE1 and CSE2 for a complete > description or CSE3. > > I think this is along the lines of your single CSE. IIUC, that is a way to distinguish which scenes need to be considered. Mentioned that as a possibility in passing in one of my messages. It still leaves the consumer with a combinatorial analysis. Another possibility is: - Leave existing per-scene CSE lists as-is. - Add another advertisement-wide CSE list. The entries in it could use shorthand, by referencing CSEs from the individual scenes. E.g., Scene1 (CSE11, CSE12, CSE13) Scene2 (CSE21, CSE22) Scene3 (CSE31) Scene4 (CSE41) Global-CSE-List ( CSEg1(CSE11, CSE21, CSE31) CSEg2(CSE12, CSE22, CSE31) CSEg3(CSE13, CSE22, CSE31) ) Here the global CSE list has recommended a subset of the possible combinations of CSEs from the different scenes, and has omitted Scene4 altogether. This is a value judgement of what combinations make sense. Note that I would still allow the CSEs in the global list to reference individual captures if desired. But referencing other CSEs is a convenient shorthand. Thanks, Paul > Regards, Christian > > On 9/02/2014 5:19 AM, Paul Kyzivat wrote: >> On 2/7/14 5:58 PM, Duckworth, Mark wrote: >>> Hi Paul, >>> Comments inline. >>> I'm open to your idea of a single set of CSEs across all scenes, but >>> I'm trying to understand if it will really be a scalable and less >>> complex way to solve these issues. >> >> Me too. I'm not certain that it will, but my gut says so. >> It just seems to me that the idea of enumerating useful combinations >> of captures in the advertisement is conceptually unrelated to what >> scene they are in, and that for the consumer the process then by >> default devolves to just choosing the one best cse that works for it, >> rather than having to choose from among combinations in different scenes. >> >>> Do you think it would help if you presented this idea at the design >>> team meeting next week? >> >> I'm not convinced that call time is very helpful for this. >> To be useful I would probably need to create several use cases, and >> show them both ways, and then for people to try to shoot them down. >> I think that kind of thing is better done by email. (And I don't have >> time to put together sufficient use cases before Tuesday.) >> >> More below. >> >>> Mark >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Friday, February 07, 2014 4:44 PM >>>> To: Duckworth, Mark; clue@ietf.org >>>> Subject: Re: [clue] How to choose from multiple scenes >>>> >>>> On 2/7/14 3:26 PM, Duckworth, Mark wrote: >>>>> Hi Paul, >>>>> >>>>> You describe the issue very well, but I don't agree with a couple >>>>> things. You >>>> wrote: >>>>>> ISTM that one should start out assuming that you need all captures >>>>>> (that have encodings) in *some* CSE from *each* scene. >>>>> I don't think that is an appropriate thing to assume. The case I >>>>> was thinking >>>> of, and we have been talking about at design team meetings, is like >>>> this: >>>>> Scene 1 - current active speaker >>>>> Scene 2 - previous active speaker >>>>> Scene 3 - previous previous active speaker and so on... >>>> >>>> I understand your *intent* here. But I don't know how the consumer >>>> acts on >>>> that. It is really part of the point I am trying to make. >>>> How does the consumer *know* the above, and take it into account? >>>> Are the *scenes* tagged to indicate that? (I don't think so.) >>> >>> [Duckworth, Mark] From the MCC policy attribute values. >>> >>>>> Where each scene could have multiple switched MCCs representing the >>>> scene, and the provider has some flexibility to group together >>>> different >>>> individual captures to include in the MCCs of a scene, depending on >>>> synchID >>>> and who is talking. >>>>> In this case, because of the policy attributes describing the MCCs, >>>>> I think it >>>> makes perfect sense for a consumer to ask for all the video MCCs >>>> from Scene >>>> 1, and none of them from Scene 2 or Scene 3. The consumer has enough >>>> information to know this is a good choice if it wants to show video >>>> from the >>>> current active speaker, including multiple video captures with spatial >>>> relationship when the current speaker is in a multi-camera room. So >>>> in this >>>> case the consumer already has enough information to make a choice. >>>> >>>> I'm having difficulty imagining how to construct an algorithm for that. >>> >>> [Duckworth, Mark] Yeah, it can get complicated. But is it good >>> enough for equipment from different vendors to interoperate in a >>> reasonable way, even if it isn't the "best" way? I think so. I >>> still think my proposed "consumer makes all the switching decisions" >>> approach can solve a lot of these problems. >> >> I know Cisco used to have a goal to make its equipment work "better >> together". But in a sense that is exactly the thing that standards are >> working against. >> >> With CLUE, *how* would a vendor's equipment do better with other of >> its own, and just be "good enough" with others? Ultimately you can >> only do as good as the provided information allows you to do. I can >> see a few things: >> >> - a vendor is likely to make its equipment in configurations that >> are designed to be easily compatible with one another. E.g., just >> a small set of configurations, like 1,2, or 3 screens, all same >> size, all side by side with consistent spacing. >> >> - a vendor could use a consistent style to structure its advertisements. >> E.g., Always have one scene for room cameras and one more for >> presentations. >> >> - a vendor could build an algorithm for constructing configurations >> that special cases advertisements structured the way it does them. >> Then it could have very crude algorithms for anything else, or >> just fail for anything else. >> >> - a vendor could build an algorithm for constructing configurations >> that makes "leaps of faith" that aren't justified solely by what >> is in an advertisement, about how the captures in the advertisement >> work. (E.g., about the algorithm for switching, or how things are >> laid out in a composition.) >> >> - a vendor could add proprietary information to advertisements, or to >> the sip signaling, to convey extra information that allows one of >> its own consuming endpoints to do a better job of constructing a >> config than would be possible with just the standard information. >> >> Odds are that we will see all of the above. Certainly there are >> inherent advantages when the advertisement happens to contain an >> alternative that exactly matches the equipment in the consuming end. >> And that is more likely to happen with equipment from one vendor. >> >> But beyond that, IMO, if we do our job well, then it should be >> possible to construct a general purpose algorithm that will do as well >> as algorithms that are special cased or that make "leaps of faith" or >> use proprietary information. >> >>>> ISTM in this case that taking a cse from every scene will give the >>>> best user >>>> experience *if* the consumer has enough display resources to show all >>>> these. >>> >>> [Duckworth, Mark] I think "best experience" is subjective here. I >>> think the consumer has enough information to make a good choice for a >>> variety of different consumer capability levels in terms of number of >>> decoders and displays it has. Suppose the consumer can receive no >>> more than 3 video encodings. It could ask for the 3 MCCs from Scene >>> 1, or it could ask for 1 MCC from each scene. But I would think it >>> would do that only if each scene had a CSE with one MCC in it. Each >>> choice could give the "best" experience, depending on what the >>> consumer is trying to present to the human users. >> >> I agree that "best experience" is subjective. But I suspect if we >> worked out a lot of use cases, we could come close to agreeing to what >> the "best experience" would be, in the absence of explicit input from >> the end users in the room. >> >> I think what you are talking about is that there are a *set* of >> "plausible" configurations, that it might make sense to offer as a >> menu to the end user. >> >>>> If not, then it gets complex to sort out the tradeoffs. >>>> >>>> In this case, considering that a capture with "current active speaker" >>>> policy is more important than one with "previous active speaker". >>>> >>>> So I would suggest that the advertisement mark all the "current active >>>> speaker" captures with highest priority, and the others with descending >>>> priorities. >>> >>> [Duckworth, Mark] that's what I was thinking, but even that shouldn't >>> be necessary because the consumer can make its own priority decision >>> based on the policy attribute. >> >> Certainly it *can*. But then it must make a tradeoff between the >> importance of the policy and the importance of the priority in the >> decision. Lacking any understanding of the motivation for the priority >> assignments, it is hard to trade those off against one another. >> >>>> Then, the consumer could start out assuming it should *try* for one CSE >>>> from each scene. It can look at different combinations, taking one >>>> from each >>>> scene, and evaluate what it can do with that combination. For each one: >>>> >>>> If it can't handle all the captures from the selected cses, it can >>>> start casting >>>> out lower priority ones until it can handle it. Then it can assign a >>>> score, >>>> depending on the priorities of those it took, the priorities of >>>> those it had to >>>> abandon, and how much it had to "adjust" >>>> the ones it took to fit on its displays. >>>> >>>> And it can repeat that for all the combinations of one cse from each >>>> scene. >>>> And then pick out the combination with the best score. >>>> >>>> This is all very heuristic. Will take a lot of thought and testing >>>> to come up with >>>> something that does well. (It would be interesting to work this out >>>> in detail >>>> for some specific consumer configurations and see if it can actually >>>> find good >>>> renderings.) >>>> >>>> Having the advertisement provide a single set of CSEs across all the >>>> scenes >>>> would "help" in that it would reduce the number of combinations the >>>> consumer had to evaluate. >>> >>> [Duckworth, Mark] I'm not sure it would reduce anything. As >>> Christian said, "The combinatorial issue becomes worse with the more >>> Scenes that you have". I'm concerned that trying to add another >>> layer of alternatives in the advertisement, that crosses scene >>> boundaries, won't scale well. Or do you think it is really simpler >>> than that? Are you envisioning the single set of CSEs could be kept >>> small, even with many scenes? >> >> With separate CSE lists in each scene, the *consumer* has to evaluate >> all the combinations of one CSE from each scene. >> >> With a single CSE list, the *advertiser* has to consider all of those >> when constructing the advertisement. But it doesn't have to *include* >> them all in the advertisement. My gut tells me that when there are >> only a few then perhaps they are all interesting, but when they are >> many, that only a few will be interesting enough to include. The >> advertiser is pruning the choices, using information that it has that >> isn't necessarily available to the consumer. >> >> If the advertiser is typically going to include all the combinations, >> then going this way is a bad choice. And if the advertiser is going to >> limit what it includes because it is too much work, or makes the >> advertisement too big, even though it thinks the ones it is omitting >> would be useful, then this is also a bad idea. >> >>>>> I agree there could be other situations where the MCC policy >>>>> attributes >>>> aren't enough information for the consumer to make a good choice. >>>> This is >>>> where I thought the media capture priority attribute should be used. I >>>> thought this was the purpose of adding the priority attribute in the >>>> first >>>> place. From the framework: >>>>> >>>>> 7.1.1.12. Priority >>>>> The priority attribute indicates a relative priority between >>>>> different Media >>>> Captures. The Provider sets this priority, and the Consumer MAY use >>>> the >>>> priority to help decide which captures it wishes to receive. >>>>> The "priority" attribute is an integer which indicates a relative >>>>> priority >>>> between Captures. For example it is possible to assign a priority >>>> between >>>> two presentation Captures that would allow a remote endpoint to >>>> determine >>>> which presentation is more important. Priority is assigned at the >>>> individual >>>> capture level. It represents the Provider's view of the relative >>>> priority >>>> between Captures with a priority. >>>>> >>>>> I don't understand why you say this isn't a priority issue, but >>>>> rather an >>>> alternative issue. It seems to me your proposal of advertising >>>> different >>>> combinations of captures or CSEs across scene boundaries is just >>>> another >>>> way for the provider to express priorities. >>>> >>>> Surely it is a form of prioritization. But it can be more >>>> sophisticated than >>>> simply assigning a priority value to each individual capture. >>>> >>>> But consider, if prioritization were sufficient, we wouldn't need to >>>> have CSEs >>>> at all. We could simply have prioritized captures. ISTM that the >>>> reasons that >>>> CSEs are more powerful than priorities within a scene should still >>>> apply >>>> outside a scene. >>> >>> [Duckworth, Mark] That makes sense too, at a high level, but I'm >>> having trouble understanding how to put it in practice. >>> >>>> As I described above, I *think* priorities plus per-scene cse lists >>>> can solve >>>> your use case. But the processing to use it that way is complex. >>> >>> [Duckworth, Mark] So are you saying your idea of using a single set >>> of CSEs across all scenes can solve the same problems in a less >>> complex way? I'm open to that, but still not sure it would be any >>> less complex. >> >> I think it is less complex for the consumer to evaluate a single list >> than to evaluate combinations of choices from multiple lists. >> (Enumerating all the combinations and generating an equivalent single >> list to evaluate is of course a straightforward programming job. But I >> wonder if some implementers might instead go for "special casing".) >> >> When constructing a single list, rather than several, and choosing >> which combinations to include, the advertiser can use knowledge that >> can't otherwise be described in the advertisement and used by the >> consumer to choose. >> >> Thanks, >> Paul >> >>>> Thanks, >>>> Paul >>>> >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>> Sent: Thursday, February 06, 2014 12:34 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] How to choose from multiple scenes >>>>>> >>>>>> I just realized I had missed this reply. See inline. >>>>>> >>>>>> On 1/27/14 10:33 PM, Christian Groves wrote: >>>>>>> Hello Paul, >>>>>>> >>>>>>> Please see below. >>>>>>> >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 28/01/2014 10:06 AM, Paul Kyzivat wrote: >>>>>>>> * The problem: >>>>>>>> >>>>>>>> As we discussed in the interim today, it seems unclear what a >>>>>>>> consumer should do when receiving an advertisement with multiple >>>>>>>> scenes in order to get a sufficient representation of the >>>>>>>> advertised >>>>>> content. >>>>>>>> >>>>>>>> Our simple cases have been where there is one scene for the cameras >>>>>>>> in the room, and another scene for a presentation. In that case, >>>>>>>> one should take something from each scene (typically one CSE from >>>>>>>> each) to get "enough". >>>>>>>> >>>>>>>> That is also true if an MCU acted in "pass through" mode and simply >>>>>>>> included "copies" of all the scenes it receives in advertisements, >>>>>>>> with encodings for them all. >>>>>>>> >>>>>>>> In a "simple" case with an MCU use MCC, it might "pass through" all >>>>>>>> the advertisements it receives, for their spatial info, but not >>>>>>>> provide any encodings for them. Rather, it would provide one or >>>>>>>> more new scenes using MCC to aggregate those sources. Then one >>>>>>>> would not want to configure from the "pass through" scenes, but >>>>>>>> that isn't an option anyway if there are no encodings for them. >>>>>>> [CNG] The idea of the pass through information was that the consumer >>>>>>> could use any capture attribute (not just spatial ones) to determine >>>>>>> what media it wanted. >>>>>> >>>>>> Clearly if there are no encodings, then the captures are there only >>>>>> for information and can't be configured. >>>>>> >>>>>> That is why I called this the "simple" case. >>>>>> >>>>>>>> Mark has proposed using multiple scenes with MCC to illustrate >>>>>>>> switched cases where some groupings don't have any spatial >>>>>>>> relationship to one another. Some of those examples end up with >>>>>>>> multiple scenes that do have encodings, where it doesn't make sense >>>>>>>> to configure something from each scene. >>>>>>> [CNG] I don't think there's anything in the framework that says a >>>>>>> consumer must choose a capture from a scene. >>>>>> >>>>>> Of course there is no MUST. The consumer isn't required take >>>>>> *anything*. >>>>>> >>>>>> The question is how the consumer knows what is required to have a >>>>>> "complete" representation of what is in the advertisement. It may not >>>>>> want all that, but it is hard to make a good choice without knowing. >>>>>> >>>>>> That is the point of CSEs - for the advertiser to indicate what it >>>>>> considers to be good alternative choices. But CSEs only work within a >>>>>> scene. Once there are multiple scenes, the consumer has less guidance >>>>>> on what would be good (or sufficient) choices. >>>>>> >>>>>> The consumer has *some* information: >>>>>> - if none of the captures in a scene have encodings, then there is >>>>>> no need (or way) to select them directly >>>>>> >>>>>> - if MCC M in scene X references capture C in scene Y, then it >>>>>> would be redundant to configure both M and C >>>>>> >>>>>> ISTM that one should start out assuming that you need all captures >>>>>> (that have encodings) in *some* CSE from *each* scene. You can then >>>>>> prune that based on the logic above. But is that *enough* to make >>>>>> good >>>> decisions? >>>>>> At best, the logic to figure that out is complex. >>>>>> >>>>>>>> Today we discussed using priority to solve this, but this isn't >>>>>>>> really a priority problem, it is a problem of *alternatives* that >>>>>>>> may be equally desirable, depending on the resources or desires of >>>>>>>> the >>>>>> consumer. >>>>>>> [CNG] I agree I don't think priority is the right solution for this. >>>>>>>> >>>>>>>> IMO the problem is that our CSE mechanism is a way for the >>>>>>>> advertiser to suggest alternatives, but this only works on a >>>>>>>> per-scene >>>> basis. >>>>>>>> The advertiser has no comparable mechanism to suggest alternatives >>>>>>>> from different scenes. >>>>>>>> >>>>>>>> * My proposed solution: >>>>>>>> >>>>>>>> I want to restate a proposal I made a long time ago: >>>>>>>> >>>>>>>> Instead of one CSE list per scene, have one CSE list >>>>>>>> per-advertisement, referencing captures from any scene. >>>>>>>> >>>>>>>> This makes it possible for the advertiser to recommend combinations >>>>>>>> that cross scene boundaries. >>>>>>> [CNG] Perhaps you could give some examples? Does the list need to be >>>>>>> exhaustive? >>>>>> >>>>>> Does the CSE list in a scene have to be exhaustive? >>>>>> >>>>>> I think each entry should be "sufficient" for somebody that can't >>>>>> handle a bigger one. The definition of "sufficient" is subjective. >>>>>> >>>>>>> e.g. the simple case today >>>>>>> Scene1 CSE1(VC1,VC2,VC3) >>>>>>> CSE2(VC4) >>>>>>> Scene2 CSE3(VC5,presentation1) >>>>>>> >>>>>>> Does it mean now the Advertisement would now have to advertise? >>>>>>> CSE1(VC1,VC2,VC3,VC5) >>>>>>> CSE2(VC4,VC5) >>>>>>> CSE3(VC1,VC2,VC3) >>>>>>> CSE4(VC4) >>>>>>> CSE5(VC5) >>>>>> >>>>>> As I said, the definition of "sufficient" is subjective. >>>>>> IMO the advertisement ought to include at least CSE1,CSE2. >>>>>> >>>>>> Rather than include the others, I think I would adjust the priorities >>>>>> of the individual captures based on my judgement of which I think >>>>>> should be kept if they all can't be. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>>> * An alternate solution: >>>>>>>> >>>>>>>> Another possibility would be to leave CSEs as they are, but add >>>>>>>> something analogous to a CSE list, but that lists recommended >>>>>>>> combinations of scenes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>> >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Mon Feb 10 08:46:19 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AB51A06DC for ; Mon, 10 Feb 2014 08:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BP45MutinG1b for ; Mon, 10 Feb 2014 08:46:16 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A91DE1A031B for ; Mon, 10 Feb 2014 08:46:15 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-86-52f90256ac7b Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 27.DD.23809.65209F25; Mon, 10 Feb 2014 17:46:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 17:46:14 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft new version: draft-holmberg-clue-datachannel-01 Thread-Index: Ac8j/b3fWVgMoVOPRmi4Z2O6oFTWFAB8uHkAAA91YTAADl36AAAFxX+e Date: Mon, 10 Feb 2014 16:46:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1678B8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> <52F82082.3050106@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se>, <52F8E8AA.9060903@alum.mit.edu> In-Reply-To: <52F8E8AA.9060903@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.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjW4Y088gg/P7LC32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjyMH1zAVTtSperzzE1MB4R7GLkZNDQsBE 4svS0+wQtpjEhXvr2boYuTiEBA4xSpzc1cUCkhASWMwoMf+eYRcjBwebgIVE9z9tkLCIgKfE jo9TmEFsYSC7++EZZoi4l8SVCYehbDeJg9NmMIHYLAKqEouWHAEbySvgK/F86mQ2iPGXGSU2 v/MCsTkFdCR+z3nKCmIzAt3z/dQasF5mAXGJW0/mM0HcKSCxZM95ZghbVOLl43+sIKdJCChJ TNuaBlGuI7Fg9yc2CFtbYtnC18wQawUlTs58wjKBUXQWkqmzkLTMQtIyC0nLAkaWVYzsuYmZ OenlRpsYgXFwcMtv1R2Md86JHGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAMjv8WvNS/1a9kDNpzznmnOIHD1YHb5UfN9FzR4/++6OF19lea8hnD3IN4txdUqs2XuNP1i VL//4HhDjYN9r3yh/4UwuSs3vK69+7Rv7cL+fbf9/1iahelKn1NP2P0jMSf6tNjKCzdeHbGy sJ913aGkeur7Q245tjwzzmcurN+36n+Jhs427u6tSizFGYmGWsxFxYkAfso9vlECAAA= Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 16:46:19 -0000 Hi, >Regarding use of data channel protocol vs. ejzak draft: > >I think there is a tradeoff: > >- using data channel protocol will probably be substantially easier > for an rtcweb client. And I think we are more confident that > the data channel protocol will become an RFC. (RTCWEB doesn't > *need* the ejzak draft. It could just fade away.) > >- but using the ejzak draft allows negotiating the use of CLUE > in the SDP O/A. With data channel protocol, there is no indication > of that until after the SCTP association has been established. > (You might get that far, and then discover the other end intended > to use the SCTP for something else, and doesn't do clue.) Without using ANY of the above, the sctp-sdp mechanism allows you to negoti= ate a "webrtc-datachannel", but obviusly not the application(s) using the d= ata channel. Regards, Christer On 2/10/14 2:18 AM, Christer Holmberg wrote: > Hi Christian, > >> Some comments/questions: >> >> 3.2 Para.2 - I've raised this before "is it possible to have multiple CL= UE bi-directional CLUE Data Channels per SCTP association"? I can't think o= f a >> case where this would be needed??? If its not needed then I would sugges= t a slight update to make this clear, i.e. >> "The realization of a bidirectional CLUE Data Channel is a pair of one i= ncoming SCTP stream and one outgoing SCTP stream <> association>>. These streams are then used to transport CLUE messages in= both directions." > > Eventhough I can't think of a case either, I am not sure whether we need = to forbid having multiple CLUE channels per SCTP association. But, I think = we should NOT allow using multiple CLUE channels in a single CLUE session. > >> 3.2 Para.4 - Is this a MUST or a SHOULD? To me there are no exceptions t= o a MUST, in the sentence we list an exception that allows the use of anoth= er id. > > It is currently a MUST. > > But, we need to verify that e.g. JavaScript applications do have full con= trol of setting the stream id value. > >> 3.4.1 - I guess now we'll only specify the new PID value indicating >> UTF-8 (and 50 for WebRTC if used) based on recent discussions on the RTC= Web list? > > Correct. > > In the next version of the draft I will use a "XX" value, which will be r= eplaced with whatever value RTCWEB registers for UTF-8 strings. > >> 3.4.2 - "CLUE entities MUST use the reliable transport SCTP feature." >> This sounds like there is a special service or function for this? I thou= ght reliability is inherent to SCTP? May we could reword to something like = "CLUE entities must support the SCTP which ensures reliable transport of CL= UE messages." > > Ok. > >> If you wanted to be more specific with regards to RTCweb data protocol y= ou could add something like: "In the context of [ID.ietf-rtcweb-data-protoc= ol] the use of a "DATA_CHANNEL_RELIABLE" >> channel." > > I'd suggest we leave that until we have determined whether we will use th= e rtcweb data protocol. > > >> 3.4.3 - I propose to be a bit more concrete: >> "CLUE entities MUST use the ordered delivery SCTP <>. > > Ok. > >> 3.4.5 - I think there are dodgy reference, interleaving is described in = . > > Will be fixed. > >> 6 - I mentioned earlier that if we use RTCWEB data channel we need to de= fine CLUE as a protocol. So I propose adding something like: >> >> [ID.ietf-rtcweb-data-protocol] defines a new "Protocol Registry" for the= data channel protocol to manage the "Protocol" field of type string in >> DATA_CHANNEL_OPEN messages. If CLUE is [ID.ietf-rtcweb-data-protocol] is= used a new protocol value for CLUE is required. >> The following values need to be registered: >> >> +--------------+-----------+ >> | Name | Reference | >> +--------------+-----------+ >> | CLUE | [RFCXXXX] | >> +--------------+-----------+ >> >> [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this do= cument.] > > I can mention in in section 3.3. But, again, until we have decided whethe= r we will use the protocol or not, we don't need to specify too much. > >> Note: [ID.ejzak-dispatch-webrtc-data-channel-sdpneg] also contains a "su= b-protocol" parameter. The IANA registry that will be used for recording th= e protocols is still under discussion. "CLUE" should also be registered in = this registry. > > Assuming we'll use the draft, yes. > > Thanks! > > Regards, > > Christer > > > On 7/02/2014 11:12 PM, Christer Holmberg wrote: >> >> Hi, >> >> Based on the discussions on the CLUE- and RTCWEB lists, I've submitted >> a new version of the CLUE data channel draft. >> >> There are still open issue, and I have probably not implemented >> everyone's change wishes. It is more to add some more meat, and >> continue the discussions. >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Feb 10 09:03:09 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A92A1A06F2 for ; Mon, 10 Feb 2014 09:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e77vti97X0b for ; Mon, 10 Feb 2014 09:03:07 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id F18A11A06EA for ; Mon, 10 Feb 2014 09:03:06 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta05.westchester.pa.mail.comcast.net with comcast id QcdZ1n0030bG4ec55h36Pb; Mon, 10 Feb 2014 17:03:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id Qh361n00W3ZTu2S3Ph36jq; Mon, 10 Feb 2014 17:03:06 +0000 Message-ID: <52F9064A.3050600@alum.mit.edu> Date: Mon, 10 Feb 2014 12:03:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> <52F82082.3050106@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se>, <52F8E8AA.9060903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1678B8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1678B8@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=1392051786; bh=pVr8ar3xYTtZ/0L9xPPJI0HuisF/Eqq61kIM4Kw5ymo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QlZAPctlH3UAkOkewSAKbnppGs3OOfIqrzrHAy832AAUmeb5Zjq9Ar0anI77oG15o fxd1oxeUUFnOqy0M41IsivKIzZUJWf+owinfGTq6JUYYXe+AlYd4fuItX57l/eFTxP nw5rgCRVRCDum7JtMOjQu7MJrcT7sLAT1wGWdUxaKf9axfFd2h2vIqwsmoRWdtk2Mg 2qVKzzx7nhXDyExVCGk/h50nz3oMO4ERMRXS4szcl4j+QbDvd6iR4WPMh05hSUF4tz GOveBftoDj7JLsZKF0keEiv5jdQMkh3OyM1ih/J9gyis1gCX8n1bXXjF6B5kMVTPWB MiioguUo8ULYg== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 17:03:09 -0000 On 2/10/14 11:46 AM, Christer Holmberg wrote: > > Hi, > >> Regarding use of data channel protocol vs. ejzak draft: >> >> I think there is a tradeoff: >> >> - using data channel protocol will probably be substantially easier >> for an rtcweb client. And I think we are more confident that >> the data channel protocol will become an RFC. (RTCWEB doesn't >> *need* the ejzak draft. It could just fade away.) >> >> - but using the ejzak draft allows negotiating the use of CLUE >> in the SDP O/A. With data channel protocol, there is no indication >> of that until after the SCTP association has been established. >> (You might get that far, and then discover the other end intended >> to use the SCTP for something else, and doesn't do clue.) > > Without using ANY of the above, the sctp-sdp mechanism allows you to negotiate a "webrtc-datachannel", but obviusly not the application(s) using the data channel. And if we choose to use DCP to negotiate the clue channel then we will need to use that SDP. And with that we won't know if the app supports CLUE. (I hope that "webrtc-datachannel" gets renamed, removing the "webrtc". It is inappropriate for us.) Thanks, Paul > Regards, > > Christer > > > > On 2/10/14 2:18 AM, Christer Holmberg wrote: >> Hi Christian, >> >>> Some comments/questions: >>> >>> 3.2 Para.2 - I've raised this before "is it possible to have multiple CLUE bi-directional CLUE Data Channels per SCTP association"? I can't think of a >>> case where this would be needed??? If its not needed then I would suggest a slight update to make this clear, i.e. >>> "The realization of a bidirectional CLUE Data Channel is a pair of one incoming SCTP stream and one outgoing SCTP stream <>> association>>. These streams are then used to transport CLUE messages in both directions." >> >> Eventhough I can't think of a case either, I am not sure whether we need to forbid having multiple CLUE channels per SCTP association. But, I think we should NOT allow using multiple CLUE channels in a single CLUE session. >> >>> 3.2 Para.4 - Is this a MUST or a SHOULD? To me there are no exceptions to a MUST, in the sentence we list an exception that allows the use of another id. >> >> It is currently a MUST. >> >> But, we need to verify that e.g. JavaScript applications do have full control of setting the stream id value. >> >>> 3.4.1 - I guess now we'll only specify the new PID value indicating >>> UTF-8 (and 50 for WebRTC if used) based on recent discussions on the RTCWeb list? >> >> Correct. >> >> In the next version of the draft I will use a "XX" value, which will be replaced with whatever value RTCWEB registers for UTF-8 strings. >> >>> 3.4.2 - "CLUE entities MUST use the reliable transport SCTP feature." >>> This sounds like there is a special service or function for this? I thought reliability is inherent to SCTP? May we could reword to something like "CLUE entities must support the SCTP which ensures reliable transport of CLUE messages." >> >> Ok. >> >>> If you wanted to be more specific with regards to RTCweb data protocol you could add something like: "In the context of [ID.ietf-rtcweb-data-protocol] the use of a "DATA_CHANNEL_RELIABLE" >>> channel." >> >> I'd suggest we leave that until we have determined whether we will use the rtcweb data protocol. >> >> >>> 3.4.3 - I propose to be a bit more concrete: >>> "CLUE entities MUST use the ordered delivery SCTP <>. >> >> Ok. >> >>> 3.4.5 - I think there are dodgy reference, interleaving is described in . >> >> Will be fixed. >> >>> 6 - I mentioned earlier that if we use RTCWEB data channel we need to define CLUE as a protocol. So I propose adding something like: >>> >>> [ID.ietf-rtcweb-data-protocol] defines a new "Protocol Registry" for the data channel protocol to manage the "Protocol" field of type string in >>> DATA_CHANNEL_OPEN messages. If CLUE is [ID.ietf-rtcweb-data-protocol] is used a new protocol value for CLUE is required. >>> The following values need to be registered: >>> >>> +--------------+-----------+ >>> | Name | Reference | >>> +--------------+-----------+ >>> | CLUE | [RFCXXXX] | >>> +--------------+-----------+ >>> >>> [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.] >> >> I can mention in in section 3.3. But, again, until we have decided whether we will use the protocol or not, we don't need to specify too much. >> >>> Note: [ID.ejzak-dispatch-webrtc-data-channel-sdpneg] also contains a "sub-protocol" parameter. The IANA registry that will be used for recording the protocols is still under discussion. "CLUE" should also be registered in this registry. >> >> Assuming we'll use the draft, yes. >> >> Thanks! >> >> Regards, >> >> Christer >> >> >> On 7/02/2014 11:12 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> Based on the discussions on the CLUE- and RTCWEB lists, I've submitted >>> a new version of the CLUE data channel draft. >>> >>> There are still open issue, and I have probably not implemented >>> everyone's change wishes. It is more to add some more meat, and >>> continue the discussions. >>> >>> 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 Mark.Duckworth@polycom.com Mon Feb 10 09:23:24 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDD31A0406 for ; Mon, 10 Feb 2014 09:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUAcUAm4-wRN for ; Mon, 10 Feb 2014 09:23:18 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC3A1A01DA for ; Mon, 10 Feb 2014 09:23:15 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 10 Feb 2014 09:23:09 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Mon, 10 Feb 2014 09:23:07 -0800 Thread-Topic: [clue] How to choose from multiple scenes Thread-Index: Ac8mf4BsTiDBldBjToeq4OiHG1y7lgABICQQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF0D7@CRPMBOXPRD07.polycom.com> References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> <52F553B4.8070206@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB7FC@CRPMBOXPRD07.polycom.com> <52F6754A.3050501@alum.mit.edu> <52F823A1.3080308@nteczone.com> <52F90219.4070504@alum.mit.edu> In-Reply-To: <52F90219.4070504@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] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 17:23:24 -0000 Hi Paul, Your proposal here is what I was thinking of when you first suggested somet= hing like this last week. I think this could be useful, even in advertisem= ents with many scenes, without a scalability problem. I'd like to discuss = this more, after the design team meeting this week. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, February 10, 2014 11:45 AM > To: clue@ietf.org > Subject: Re: [clue] How to choose from multiple scenes >=20 ... snip ... > Another possibility is: >=20 > - Leave existing per-scene CSE lists as-is. >=20 > - Add another advertisement-wide CSE list. > The entries in it could use shorthand, by referencing CSEs from > the individual scenes. >=20 > E.g., >=20 > Scene1 (CSE11, CSE12, CSE13) > Scene2 (CSE21, CSE22) > Scene3 (CSE31) > Scene4 (CSE41) >=20 > Global-CSE-List ( > CSEg1(CSE11, CSE21, CSE31) > CSEg2(CSE12, CSE22, CSE31) > CSEg3(CSE13, CSE22, CSE31) > ) >=20 > Here the global CSE list has recommended a subset of the possible > combinations of CSEs from the different scenes, and has omitted Scene4 > altogether. This is a value judgement of what combinations make sense. >=20 > Note that I would still allow the CSEs in the global list to reference in= dividual > captures if desired. But referencing other CSEs is a convenient shorthand= . >=20 > Thanks, > Paul From pkyzivat@alum.mit.edu Mon Feb 10 09:54:30 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748F61A0889 for ; Mon, 10 Feb 2014 09:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeB8uB5ZviSj for ; Mon, 10 Feb 2014 09:54:28 -0800 (PST) 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 E30601A07EC for ; Mon, 10 Feb 2014 09:54:25 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta10.westchester.pa.mail.comcast.net with comcast id QdKe1n0070cZkys5AhuRxQ; Mon, 10 Feb 2014 17:54:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id QhuR1n00M3ZTu2S3WhuRBc; Mon, 10 Feb 2014 17:54:25 +0000 Message-ID: <52F91251.6050802@alum.mit.edu> Date: Mon, 10 Feb 2014 12:54:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> <52F553B4.8070206@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB7FC@CRPMBOXPRD07.polycom.com> <52F6754A.3050501@alum.mit.edu> <52F823A1.3080308@nteczone.com> <52F90219.4070504@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF0D7@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF0D7@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392054865; bh=sREv633vM9mCqbTA0BOEtIqw0gOMjqOFVBW+zDDZCf4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CPz68I/S45lp2FdTicwABR9UNkj8Xfyqs30s2FYroedpDWYxwm5p5fNtYTeeveqyQ 5EqA7CXJQcQ+wQIN3vGqaBIrSgY6vwuy1Ya1fn63SeRu+7zMQ9DX4voG9XLzznVk+i c6pKyMmkCyOgzzXl29VkfhrYQEHp5viTifclKDy5lBYTPmAKCA81Pru52q+DcaI/rF MDr4+ovXPHlE4oLyWAivkH50nIVPDw1aAk+C0y1heNRzgaEFY3pfi5JUgQHMSCk6FO xmwyUCQV+Z8zQL16iFdOVJV27X6NbpYD8EMoGxKjz5yzKNxMTkU+zBBE3N8AK9Jb6z RgR36vpeAlCrA== Subject: Re: [clue] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 17:54:30 -0000 On 2/10/14 12:23 PM, Duckworth, Mark wrote: > Hi Paul, > Your proposal here is what I was thinking of when you first suggested something like this last week. I think this could be useful, even in advertisements with many scenes, without a scalability problem. I'd like to discuss this more, after the design team meeting this week. Sure. Note there are variations on how this could be used: - As I showed, with CSEs in the scenes, referenced from a global CSE list - No CSEs in scenes. The global CSE list directly references captures in the various scenes - No global CSEs, just CSEs in scenes (what have had till now) - No CSEs anywhere, just captures in scenes. The consumer is on his own. We could allow as few or as many of those as we wish. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, February 10, 2014 11:45 AM >> To: clue@ietf.org >> Subject: Re: [clue] How to choose from multiple scenes >> > > ... snip ... > >> Another possibility is: >> >> - Leave existing per-scene CSE lists as-is. >> >> - Add another advertisement-wide CSE list. >> The entries in it could use shorthand, by referencing CSEs from >> the individual scenes. >> >> E.g., >> >> Scene1 (CSE11, CSE12, CSE13) >> Scene2 (CSE21, CSE22) >> Scene3 (CSE31) >> Scene4 (CSE41) >> >> Global-CSE-List ( >> CSEg1(CSE11, CSE21, CSE31) >> CSEg2(CSE12, CSE22, CSE31) >> CSEg3(CSE13, CSE22, CSE31) >> ) >> >> Here the global CSE list has recommended a subset of the possible >> combinations of CSEs from the different scenes, and has omitted Scene4 >> altogether. This is a value judgement of what combinations make sense. >> >> Note that I would still allow the CSEs in the global list to reference individual >> captures if desired. But referencing other CSEs is a convenient shorthand. >> >> Thanks, >> Paul > From christer.holmberg@ericsson.com Mon Feb 10 12:08:09 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A011A08AC for ; Mon, 10 Feb 2014 12:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgUIsBH51Ljy for ; Mon, 10 Feb 2014 12:08:07 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id E5FFB1A088B for ; Mon, 10 Feb 2014 12:08:03 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-24-52f931a2adb1 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 11.29.04853.2A139F25; Mon, 10 Feb 2014 21:08:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 21:08:02 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft new version: draft-holmberg-clue-datachannel-01 Thread-Index: Ac8j/b3fWVgMoVOPRmi4Z2O6oFTWFAB8uHkAAA91YTAADl36AAAFxX+e///1JAD//7xlAA== Date: Mon, 10 Feb 2014 20:08:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D167D5A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> <52F82082.3050106@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se>, <52F8E8AA.9060903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1678B8@ESESSMB209.ericsson.se> <52F9064A.3050600@alum.mit.edu> In-Reply-To: <52F9064A.3050600@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvje5iw59BBt9+8FnsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldG59NGpoLP+hW7Dr5jaWBcq9bFyMEhIWAi sfCBUhcjJ5ApJnHh3nq2LkYuDiGBE4wSVxZfgnIWM0qcff6TCaSBTcBCovufNkiDiICnxI6P U5hBbGEg++uxtYwQcS+JKxMOM0PYYRKXln5iA7FZBFQl7lzoYwQZwyvgK3GjOQFi/E4miWW9 c1hAajgFdCS2rd7ECmIzAh30/dQaJhCbWUBc4sPB68wQhwpILNlzHsoWlXj5+B8rhK0ksfbw dhaIeh2JBbsh9jILaEssW/garJ5XQFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShZnFpc nJtuZKCXm55bopdalJlcXJyfp1ecuokRGC0Ht/w22sF4co/9IUZpDhYlcd7rrDVBQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhh5G25aBU5Lu/5iJ0/oUSGFLZUnGU5K+xprTegoqxFdqPFu 7a7FC7eEGG8VN3NJZ2kLO+exM3+dRkDlUekkP7XDPUt5W74dvXZ12e3jihsy1RWC246mp3d8 nOxy9PG2jZH3dcX3XMxbn7Z+vr25176e5u3fNeKj624s9t3ye7dmkJPrti894sJKLMUZiYZa zEXFiQDxzb5eZAIAAA== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 20:08:09 -0000 Hi, >>> Regarding use of data channel protocol vs. ejzak draft: >>> >>> I think there is a tradeoff: >>> >>> - using data channel protocol will probably be substantially easier >>> for an rtcweb client. And I think we are more confident that >>> the data channel protocol will become an RFC. (RTCWEB doesn't >>> *need* the ejzak draft. It could just fade away.) >>> >>> - but using the ejzak draft allows negotiating the use of CLUE >>> in the SDP O/A. With data channel protocol, there is no indication >>> of that until after the SCTP association has been established. >>> (You might get that far, and then discover the other end intended >>> to use the SCTP for something else, and doesn't do clue.) >> >> Without using ANY of the above, the sctp-sdp mechanism allows you to neg= otiate a "webrtc-datachannel", but obviusly not the application(s) using th= e data channel. > > And if we choose to use DCP to negotiate the clue channel then we will ne= ed to use that SDP. And with that we won't know if the app supports CLUE. There are other mechanisms to indicate support of a feature. Media feature = tags, etc. And, if we say that all CLUE entities MUST support the data chan= nel, you don't need to explicitly indicate it on SDP level. > (I hope that "webrtc-datachannel" gets renamed, removing the "webrtc". It= is inappropriate for us.) Well, it's just a value - but I agree it could be more generic. Regards, Christer > On 2/10/14 2:18 AM, Christer Holmberg wrote: >> Hi Christian, >> >>> Some comments/questions: >>> >>> 3.2 Para.2 - I've raised this before "is it possible to have=20 >>> multiple CLUE bi-directional CLUE Data Channels per SCTP association"? = I can't think of a case where this would be needed??? If its not needed the= n I would suggest a slight update to make this clear, i.e. >>> "The realization of a bidirectional CLUE Data Channel is a pair of=20 >>> one incoming SCTP stream and one outgoing SCTP stream <>> association>>. These streams are then used to transport CLUE messages i= n both directions." >> >> Eventhough I can't think of a case either, I am not sure whether we need= to forbid having multiple CLUE channels per SCTP association. But, I think= we should NOT allow using multiple CLUE channels in a single CLUE session. >> >>> 3.2 Para.4 - Is this a MUST or a SHOULD? To me there are no exceptions = to a MUST, in the sentence we list an exception that allows the use of anot= her id. >> >> It is currently a MUST. >> >> But, we need to verify that e.g. JavaScript applications do have full co= ntrol of setting the stream id value. >> >>> 3.4.1 - I guess now we'll only specify the new PID value indicating >>> UTF-8 (and 50 for WebRTC if used) based on recent discussions on the RT= CWeb list? >> >> Correct. >> >> In the next version of the draft I will use a "XX" value, which will be = replaced with whatever value RTCWEB registers for UTF-8 strings. >> >>> 3.4.2 - "CLUE entities MUST use the reliable transport SCTP feature." >>> This sounds like there is a special service or function for this? I tho= ught reliability is inherent to SCTP? May we could reword to something like= "CLUE entities must support the SCTP which ensures reliable transport of C= LUE messages." >> >> Ok. >> >>> If you wanted to be more specific with regards to RTCweb data protocol = you could add something like: "In the context of [ID.ietf-rtcweb-data-proto= col] the use of a "DATA_CHANNEL_RELIABLE" >>> channel." >> >> I'd suggest we leave that until we have determined whether we will use t= he rtcweb data protocol. >> >> >>> 3.4.3 - I propose to be a bit more concrete: >>> "CLUE entities MUST use the ordered delivery SCTP <>. >> >> Ok. >> >>> 3.4.5 - I think there are dodgy reference, interleaving is described in= . >> >> Will be fixed. >> >>> 6 - I mentioned earlier that if we use RTCWEB data channel we need to d= efine CLUE as a protocol. So I propose adding something like: >>> >>> [ID.ietf-rtcweb-data-protocol] defines a new "Protocol Registry" for=20 >>> the data channel protocol to manage the "Protocol" field of type string= in DATA_CHANNEL_OPEN messages. If CLUE is [ID.ietf-rtcweb-data-protocol] i= s used a new protocol value for CLUE is required. >>> The following values need to be registered: >>> >>> +--------------+-----------+ >>> | Name | Reference | >>> +--------------+-----------+ >>> | CLUE | [RFCXXXX] | >>> +--------------+-----------+ >>> >>> [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of=20 >>> this document.] >> >> I can mention in in section 3.3. But, again, until we have decided wheth= er we will use the protocol or not, we don't need to specify too much. >> >>> Note: [ID.ejzak-dispatch-webrtc-data-channel-sdpneg] also contains a "s= ub-protocol" parameter. The IANA registry that will be used for recording t= he protocols is still under discussion. "CLUE" should also be registered in= this registry. >> >> Assuming we'll use the draft, yes. >> >> Thanks! >> >> Regards, >> >> Christer >> >> >> On 7/02/2014 11:12 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> Based on the discussions on the CLUE- and RTCWEB lists, I've=20 >>> submitted a new version of the CLUE data channel draft. >>> >>> There are still open issue, and I have probably not implemented=20 >>> everyone's change wishes. It is more to add some more meat, and=20 >>> continue the discussions. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Feb 10 12:29:08 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B0C1A085F for ; Mon, 10 Feb 2014 12:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_17=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p6gUXg64XbV for ; Mon, 10 Feb 2014 12:29:06 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5F71A0450 for ; Mon, 10 Feb 2014 12:29:05 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id Qcpc1n0020mv7h053kV5AU; Mon, 10 Feb 2014 20:29:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id QkV51n0023ZTu2S3XkV5b9; Mon, 10 Feb 2014 20:29:05 +0000 Message-ID: <52F93691.9050408@alum.mit.edu> Date: Mon, 10 Feb 2014 15:29:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> <52F82082.3050106@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se>, <52F8E8AA.9060903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1678B8@ESESSMB209.ericsson.se> <52F9064A.3050600@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D167D5A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D167D5A@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=1392064145; bh=MQUATE/9SAWOa5aN4sI6gn48n+wGeu7uM0Gi6dI3+b0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=F1C+s9wQFk+UPHh0yELV/WWHfRE1fmJoZndE9+lhD1pxUu6Q2i82IbClFWxo6UUg1 vKvDvPoIFdHDB9ovXNYr+ZLND5OFOwZWEPPh2zDOv/KDASYgoTeIMngJzbEtt2Bt9r l8w2BEPwWJ9Oh6wG6VAkSx57jUXaRWdNBxxpi/ao0L+39LLJgzCEjoBf7dNXLMox0D cjserSYfBt9ccWVra4kM4b25bw4UxL8d06NA9eCHxgjTEvFfm2etlElF0bsvoxUMab YrdKT5jZ68yexQUnyJuDGxp257uDUsBYyUoym29YpSOHYy52csBwGBp/dQ2hda1Tct hKyCNSW+cMa/Q== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 20:29:08 -0000 On 2/10/14 3:08 PM, Christer Holmberg wrote: > Hi, > >>>> Regarding use of data channel protocol vs. ejzak draft: >>>> >>>> I think there is a tradeoff: >>>> >>>> - using data channel protocol will probably be substantially easier >>>> for an rtcweb client. And I think we are more confident that >>>> the data channel protocol will become an RFC. (RTCWEB doesn't >>>> *need* the ejzak draft. It could just fade away.) >>>> >>>> - but using the ejzak draft allows negotiating the use of CLUE >>>> in the SDP O/A. With data channel protocol, there is no indication >>>> of that until after the SCTP association has been established. >>>> (You might get that far, and then discover the other end intended >>>> to use the SCTP for something else, and doesn't do clue.) >>> >>> Without using ANY of the above, the sctp-sdp mechanism allows you to negotiate a "webrtc-datachannel", but obviusly not the application(s) using the data channel. >> >> And if we choose to use DCP to negotiate the clue channel then we will need to use that SDP. And with that we won't know if the app supports CLUE. > > There are other mechanisms to indicate support of a feature. Media feature tags, etc. Yes, we could adopt one of those techniques to indicate desire for a clue session. > And, if we say that all CLUE entities MUST support the data channel, you don't need to explicitly indicate it on SDP level. You need to establish the SCTP association, so you have at least that SDP - an m-line and an a=sctpmap attribute. the sctp-sdp draft isn't clear whether the a=sctpmap is required, but I think it probably is if you are going to use the data channel protocol. In any case, we must figure out definitively how to choose *which* sctp association is to be used. >> (I hope that "webrtc-datachannel" gets renamed, removing the "webrtc". It is inappropriate for us.) > > Well, it's just a value - but I agree it could be more generic. It's just esthetic, but it is annoying. Thanks, Paul > Regards, > > Christer > > > > > >> On 2/10/14 2:18 AM, Christer Holmberg wrote: >>> Hi Christian, >>> >>>> Some comments/questions: >>>> >>>> 3.2 Para.2 - I've raised this before "is it possible to have >>>> multiple CLUE bi-directional CLUE Data Channels per SCTP association"? I can't think of a case where this would be needed??? If its not needed then I would suggest a slight update to make this clear, i.e. >>>> "The realization of a bidirectional CLUE Data Channel is a pair of >>>> one incoming SCTP stream and one outgoing SCTP stream <>>> association>>. These streams are then used to transport CLUE messages in both directions." >>> >>> Eventhough I can't think of a case either, I am not sure whether we need to forbid having multiple CLUE channels per SCTP association. But, I think we should NOT allow using multiple CLUE channels in a single CLUE session. >>> >>>> 3.2 Para.4 - Is this a MUST or a SHOULD? To me there are no exceptions to a MUST, in the sentence we list an exception that allows the use of another id. >>> >>> It is currently a MUST. >>> >>> But, we need to verify that e.g. JavaScript applications do have full control of setting the stream id value. >>> >>>> 3.4.1 - I guess now we'll only specify the new PID value indicating >>>> UTF-8 (and 50 for WebRTC if used) based on recent discussions on the RTCWeb list? >>> >>> Correct. >>> >>> In the next version of the draft I will use a "XX" value, which will be replaced with whatever value RTCWEB registers for UTF-8 strings. >>> >>>> 3.4.2 - "CLUE entities MUST use the reliable transport SCTP feature." >>>> This sounds like there is a special service or function for this? I thought reliability is inherent to SCTP? May we could reword to something like "CLUE entities must support the SCTP which ensures reliable transport of CLUE messages." >>> >>> Ok. >>> >>>> If you wanted to be more specific with regards to RTCweb data protocol you could add something like: "In the context of [ID.ietf-rtcweb-data-protocol] the use of a "DATA_CHANNEL_RELIABLE" >>>> channel." >>> >>> I'd suggest we leave that until we have determined whether we will use the rtcweb data protocol. >>> >>> >>>> 3.4.3 - I propose to be a bit more concrete: >>>> "CLUE entities MUST use the ordered delivery SCTP <>. >>> >>> Ok. >>> >>>> 3.4.5 - I think there are dodgy reference, interleaving is described in . >>> >>> Will be fixed. >>> >>>> 6 - I mentioned earlier that if we use RTCWEB data channel we need to define CLUE as a protocol. So I propose adding something like: >>>> >>>> [ID.ietf-rtcweb-data-protocol] defines a new "Protocol Registry" for >>>> the data channel protocol to manage the "Protocol" field of type string in DATA_CHANNEL_OPEN messages. If CLUE is [ID.ietf-rtcweb-data-protocol] is used a new protocol value for CLUE is required. >>>> The following values need to be registered: >>>> >>>> +--------------+-----------+ >>>> | Name | Reference | >>>> +--------------+-----------+ >>>> | CLUE | [RFCXXXX] | >>>> +--------------+-----------+ >>>> >>>> [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of >>>> this document.] >>> >>> I can mention in in section 3.3. But, again, until we have decided whether we will use the protocol or not, we don't need to specify too much. >>> >>>> Note: [ID.ejzak-dispatch-webrtc-data-channel-sdpneg] also contains a "sub-protocol" parameter. The IANA registry that will be used for recording the protocols is still under discussion. "CLUE" should also be registered in this registry. >>> >>> Assuming we'll use the draft, yes. >>> >>> Thanks! >>> >>> Regards, >>> >>> Christer >>> >>> >>> On 7/02/2014 11:12 PM, Christer Holmberg wrote: >>>> >>>> Hi, >>>> >>>> Based on the discussions on the CLUE- and RTCWEB lists, I've >>>> submitted a new version of the CLUE data channel draft. >>>> >>>> There are still open issue, and I have probably not implemented >>>> everyone's change wishes. It is more to add some more meat, and >>>> continue the discussions. >>>> >>>> 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 Mon Feb 10 12:38:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F7F1A046A for ; Mon, 10 Feb 2014 12:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgrFF_uBALz9 for ; Mon, 10 Feb 2014 12:38:04 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D57821A0509 for ; Mon, 10 Feb 2014 12:38:03 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-37-52f938aaaac8 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C2.AC.10875.AA839F25; Mon, 10 Feb 2014 21:38:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Mon, 10 Feb 2014 21:38:02 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: VS: [clue] Draft new version: draft-holmberg-clue-datachannel-01 Thread-Index: Ac8j/b3fWVgMoVOPRmi4Z2O6oFTWFAB8uHkAAA91YTAADl36AAAFxX+e///1JAD//7xlAIAAfSiA///ueXA= Date: Mon, 10 Feb 2014 20:38:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D167EDB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D161D2C@ESESSMB209.ericsson.se> <52F82082.3050106@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D166757@ESESSMB209.ericsson.se>, <52F8E8AA.9060903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1678B8@ESESSMB209.ericsson.se> <52F9064A.3050600@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D167D5A@ESESSMB209.ericsson.se> <52F93691.9050408@alum.mit.edu> In-Reply-To: <52F93691.9050408@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje5qi59BBgv/sVvsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldGw+FnrAUfBCtaLjexNTA28nUxcnJICJhI rHu0nxnCFpO4cG89G4gtJHCIUWL6ercuRi4gezGjxPMV29m7GDk42AQsJLr/aYPUiAh4Suz4 OAWsV1jAV2LWxUXsEPEAieV7H7BC2EkSe15PB5vJIqAqsebsWrAaXqD6GavWsEHMn88s0bjk N1iCU0BHYkffUjCbEeig76fWMIHYzALiEh8OXoc6VEBiyZ7zULaoxMvH/1ghbCWJtYe3s0DU 60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUje25iZk56ueEm RmAsHNzyW3cH46lzIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAmHuI W1wya0KSSP5i+92JGz8nfNnCk134Yu6sR0e4fn+tjVxlUGLm3TN7+hOm4/bz7Wyvz9uleeBM 9PmijXp3ilfuf7j+Psf1h3d5b+48a7F2XpKn02vW6+udX9wKafnvouammeu/7LKR+I66PWbF Hn7zTjtk8VsvlD/o0MDyZfKedm2PH4+E/ymxFGckGmoxFxUnAgAVxOjcUwIAAA== Subject: Re: [clue] Draft new version: draft-holmberg-clue-datachannel-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 20:38:06 -0000 Hi, >>>>> Regarding use of data channel protocol vs. ejzak draft: >>>>> >>>>> I think there is a tradeoff: >>>>> >>>>> - using data channel protocol will probably be substantially easier >>>>> for an rtcweb client. And I think we are more confident that >>>>> the data channel protocol will become an RFC. (RTCWEB doesn't >>>>> *need* the ejzak draft. It could just fade away.) >>>>> >>>>> - but using the ejzak draft allows negotiating the use of CLUE >>>>> in the SDP O/A. With data channel protocol, there is no indicatio= n >>>>> of that until after the SCTP association has been established. >>>>> (You might get that far, and then discover the other end intended >>>>> to use the SCTP for something else, and doesn't do clue.) >>>> >>>> Without using ANY of the above, the sctp-sdp mechanism allows you to n= egotiate a "webrtc-datachannel", but obviusly not the application(s) using = the data channel. >>> >>> And if we choose to use DCP to negotiate the clue channel then we will = need to use that SDP. And with that we won't know if the app supports CLUE. >> >> There are other mechanisms to indicate support of a feature. Media featu= re tags, etc. > > Yes, we could adopt one of those techniques to indicate desire for a clue= session. > >> And, if we say that all CLUE entities MUST support the data channel, you= don't need to explicitly indicate it on SDP level. > > You need to establish the SCTP association, so you have at least that SDP= - an m-line and an a=3Dsctpmap attribute. the sctp-sdp draft isn't clear w= hether the a=3Dsctpmap is required, but I think it probably is if you are g= oing to use the data channel protocol. My understanding is that the sctpmap is required (the value indicating the = number of streams is optional). If not, we can always specify that CLUE ent= ities MUST use it. > In any case, we must figure out definitively how to choose *which* sctp a= ssociation is to be used. Actually, from what I've heard, there is going to be a change to the sctp-s= dp draft, so that only one SCTP association is allowed.=20 If that is true, unless we create multiple m- lines with data channels, we = will know which association to use. Regards, Christer From internet-drafts@ietf.org Mon Feb 10 16:48:26 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A7C1A066B; Mon, 10 Feb 2014 16:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtiY8eOviQZm; Mon, 10 Feb 2014 16:48:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BD61A0717; Mon, 10 Feb 2014 16:48:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140211004824.9196.51994.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 16:48:24 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-14.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 00:48:26 -0000 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 : Framework for Telepresence Multi-Streams Authors : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-14.txt Pages : 71 Date : 2014-02-10 Abstract: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling for setting up a telepresence session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-14 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 Mark.Duckworth@polycom.com Mon Feb 10 16:54:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1BF1A066B for ; Mon, 10 Feb 2014 16:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGHgnYm6xFqv for ; Mon, 10 Feb 2014 16:54:54 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 834A11A071D for ; Mon, 10 Feb 2014 16:54:54 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 10 Feb 2014 16:54:54 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 10 Feb 2014 16:54:52 -0800 Thread-Topic: Changes in framework-14 Thread-Index: Ac8mw00ZU24gbXe4QKGQfZ2VnjjjSQ== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF3C7@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_49E45C59CA48264997FEBFB29B6BC2D60C9D3FF3C7CRPMBOXPRD07p_" MIME-Version: 1.0 Subject: [clue] Changes in framework-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 00:54:56 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D3FF3C7CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I implemented the changes we've been talking about. There are still a few = open issues we can continue to discuss, I'll go over those at the design te= am meeting Feb 11. Please review the MCC example in section 12.3.3. I think it is okay now as= a complete example, but we might want to add another example, or change th= is one, pending results of the discussion "How to choose from multiple scen= es". draft-ietf-clue-framework-14 has these changes: Changes from 13 to 14: 1. Fill in section for Security Considerations. 2. Replace Role placeholder with Participant Information, Participant Type, and Scene Information attributes. 3. Spatial information implies nothing about how constituent media captures are combined into a composed MCC. 4. Clean up MCC example in Section 12.3.3. Clarify behavior of tiled and PIP display windows. Add audio. Add new open issue about associating incoming packets to original source capture. 5. Remove editor's note and associated statement about RTP multiplexing at end of section 5. 6. Remove editor's note and associated paragraph about overloading media channel with both CLUE and non-CLUE usage, in section 5. 7. In section 10, clarify intent of media encodings conforming to SDP, even with multiple CLUE message exchanges. Remove associated editor's note. Regards, Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D3FF3C7CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I imple= mented the changes we’ve been talking about.  There are still a = few open issues we can continue to discuss, I’ll go over those at the= design team meeting Feb 11.

 =

Please review the MCC example in section 12.= 3.3.  I think it is okay now as a complete example, but we might want = to add another example, or change this one, pending results of the discussi= on “How to choose from multiple scenes”.

 

draft-ietf-clue-fram= ework-14 has these changes:

 <= /o:p>

   Changes from 13 to 14:

 

 &= nbsp;   1. Fill in section for Security Considerations.

 

 &= nbsp;   2. Replace Role placeholder with Participant Information,=

      &nb= sp; Participant Type, and Scene Information attributes.

 

   = ;  3. Spatial information implies nothing about how constituent

        med= ia captures are combined into a composed MCC.

 

     4.= Clean up MCC example in Section 12.3.3.  Clarify behavior of

        tiled= and PIP display windows.  Add audio.  Add new open

        issue abou= t associating incoming packets to original source

        capture.

 

  = ;   5. Remove editor's note and associated statement about RTP

       = multiplexing at end of section 5.

=  

     6. Remove edi= tor's note and associated paragraph about

        overloading media channel with= both CLUE and non-CLUE usage,

 &nb= sp;      in section 5.

 

     = 7. In section 10, clarify intent of media encodings conforming

        to SDP, e= ven with multiple CLUE message exchanges.  Remove

        associated editor= 's note.

 

Regards,

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D3FF3C7CRPMBOXPRD07p_-- From Christian.Groves@nteczone.com Tue Feb 11 01:51:13 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D789C1A091F for ; Tue, 11 Feb 2014 01:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2CZyDZDdIk6 for ; Tue, 11 Feb 2014 01:51:10 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9122D1A091E for ; Tue, 11 Feb 2014 01:51:10 -0800 (PST) Received: from ppp118-209-52-2.lns20.mel4.internode.on.net ([118.209.52.2]:53808 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WD9yQ-0003Zg-Kz for clue@ietf.org; Tue, 11 Feb 2014 20:49:50 +1100 Message-ID: <52F9F28A.802@nteczone.com> Date: Tue, 11 Feb 2014 20:51:06 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF3C7@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF3C7@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Changes in framework-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 09:51:14 -0000 Hello Mark, I've just had a quick look and it looks pretty good. A nit in Table 19 and 20, CSEs don't have IDs. The CSEs should just be CSE, CSE not CSE1 and CSE2. In Table 22 I'm not sure why the MCCs for the audio don't reference the source? Wouldn't they list AC1 to AC5? Regards, Christian On 11/02/2014 11:54 AM, Duckworth, Mark wrote: > > Hello, > > I implemented the changes we’ve been talking about. There are still a > few open issues we can continue to discuss, I’ll go over those at the > design team meeting Feb 11. > > Please review the MCC example in section 12.3.3. I think it is okay > now as a complete example, but we might want to add another example, > or change this one, pending results of the discussion “How to choose > from multiple scenes”. > > draft-ietf-clue-framework-14 has these changes: > > Changes from 13 to 14: > > 1. Fill in section for Security Considerations. > > 2. Replace Role placeholder with Participant Information, > > Participant Type, and Scene Information attributes. > > 3. Spatial information implies nothing about how constituent > > media captures are combined into a composed MCC. > > 4. Clean up MCC example in Section 12.3.3. Clarify behavior of > > tiled and PIP display windows. Add audio. Add new open > > issue about associating incoming packets to original source > > capture. > > 5. Remove editor's note and associated statement about RTP > > multiplexing at end of section 5. > > 6. Remove editor's note and associated paragraph about > > overloading media channel with both CLUE and non-CLUE usage, > > in section 5. > > 7. In section 10, clarify intent of media encodings conforming > > to SDP, even with multiple CLUE message exchanges. Remove > > associated editor's note. > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Feb 11 02:02:32 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F511A0929 for ; Tue, 11 Feb 2014 02:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-Qtj7EYUU-r for ; Tue, 11 Feb 2014 02:02:27 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DCA1A0921 for ; Tue, 11 Feb 2014 02:02:26 -0800 (PST) Received: from ppp118-209-52-2.lns20.mel4.internode.on.net ([118.209.52.2]:54077 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDA9L-0004vN-81 for clue@ietf.org; Tue, 11 Feb 2014 21:01:07 +1100 Message-ID: <52F9F52F.9090705@nteczone.com> Date: Tue, 11 Feb 2014 21:02:23 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> <52F553B4.8070206@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB7FC@CRPMBOXPRD07.polycom.com> <52F6754A.3050501@alum.mit.edu> <52F823A1.3080308@nteczone.com> <52F90219.4070504@alum.mit.edu> In-Reply-To: <52F90219.4070504@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 10:02:32 -0000 Hello Paul and Mark, Please see my comments below. Regards, Christian On 11/02/2014 3:45 AM, Paul Kyzivat wrote: > On 2/9/14 7:56 PM, Christian Groves wrote: >> Hello Paul, >> >> I think some uses cases would be good. >> >> I'd like to see a third case where we'd have something like a "Scene Set >> Entry" (SSE). This would indicate what scenes would make up a "full' >> description of an endpoint. >> >> i.e. Scene1 (CSE1) >> Scene2 (CSE2) >> Scene3 (CSE3) >> SSE [(Scene1,Scene2),(Scene1)] >> A consumer would know it should pick CSE1 and CSE2 for a complete >> description or CSE3. >> >> I think this is along the lines of your single CSE. > > IIUC, that is a way to distinguish which scenes need to be considered. > Mentioned that as a possibility in passing in one of my messages. [CNG] I thought that knowing which scenes go together was the core of the issue. An Advertiser says here's the set of scenes that go together. The Advertiser uses the CSEs to indicate the different rendering options for each scene. > > It still leaves the consumer with a combinatorial analysis. > > Another possibility is: > > - Leave existing per-scene CSE lists as-is. > > - Add another advertisement-wide CSE list. > The entries in it could use shorthand, by referencing CSEs from > the individual scenes. > > E.g., > > Scene1 (CSE11, CSE12, CSE13) > Scene2 (CSE21, CSE22) > Scene3 (CSE31) > Scene4 (CSE41) > > Global-CSE-List ( > CSEg1(CSE11, CSE21, CSE31) > CSEg2(CSE12, CSE22, CSE31) > CSEg3(CSE13, CSE22, CSE31) > ) [CNG] The issue is that currently we do not assign any sort of ID to CSEs. There hasn't been a reason to as the consumer selects the captures it wants. I think the above complicates things. With this we are now saying that which scenes are chosen depend on the rendering of each of the scenes. Our current assumption is that a CSE represents the "whole scene". Each CSE is effectively a different rendering of this whole. With the above we are now changing that to imply that a CSE may be a part of a scene because which other Scenes/CSEs you chose is based on that rendering. Its not a syntax issue only we're playing with the semantics of what we have also. > > Here the global CSE list has recommended a subset of the possible > combinations of CSEs from the different scenes, and has omitted Scene4 > altogether. This is a value judgement of what combinations make sense. > > Note that I would still allow the CSEs in the global list to reference > individual captures if desired. But referencing other CSEs is a > convenient shorthand. > > Thanks, > Paul > >> Regards, Christian >> >> On 9/02/2014 5:19 AM, Paul Kyzivat wrote: >>> On 2/7/14 5:58 PM, Duckworth, Mark wrote: >>>> Hi Paul, >>>> Comments inline. >>>> I'm open to your idea of a single set of CSEs across all scenes, but >>>> I'm trying to understand if it will really be a scalable and less >>>> complex way to solve these issues. >>> >>> Me too. I'm not certain that it will, but my gut says so. >>> It just seems to me that the idea of enumerating useful combinations >>> of captures in the advertisement is conceptually unrelated to what >>> scene they are in, and that for the consumer the process then by >>> default devolves to just choosing the one best cse that works for it, >>> rather than having to choose from among combinations in different >>> scenes. >>> >>>> Do you think it would help if you presented this idea at the design >>>> team meeting next week? >>> >>> I'm not convinced that call time is very helpful for this. >>> To be useful I would probably need to create several use cases, and >>> show them both ways, and then for people to try to shoot them down. >>> I think that kind of thing is better done by email. (And I don't have >>> time to put together sufficient use cases before Tuesday.) >>> >>> More below. >>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: Friday, February 07, 2014 4:44 PM >>>>> To: Duckworth, Mark; clue@ietf.org >>>>> Subject: Re: [clue] How to choose from multiple scenes >>>>> >>>>> On 2/7/14 3:26 PM, Duckworth, Mark wrote: >>>>>> Hi Paul, >>>>>> >>>>>> You describe the issue very well, but I don't agree with a couple >>>>>> things. You >>>>> wrote: >>>>>>> ISTM that one should start out assuming that you need all captures >>>>>>> (that have encodings) in *some* CSE from *each* scene. >>>>>> I don't think that is an appropriate thing to assume. The case I >>>>>> was thinking >>>>> of, and we have been talking about at design team meetings, is like >>>>> this: >>>>>> Scene 1 - current active speaker >>>>>> Scene 2 - previous active speaker >>>>>> Scene 3 - previous previous active speaker and so on... >>>>> >>>>> I understand your *intent* here. But I don't know how the consumer >>>>> acts on >>>>> that. It is really part of the point I am trying to make. >>>>> How does the consumer *know* the above, and take it into account? >>>>> Are the *scenes* tagged to indicate that? (I don't think so.) >>>> >>>> [Duckworth, Mark] From the MCC policy attribute values. >>>> >>>>>> Where each scene could have multiple switched MCCs representing the >>>>> scene, and the provider has some flexibility to group together >>>>> different >>>>> individual captures to include in the MCCs of a scene, depending on >>>>> synchID >>>>> and who is talking. >>>>>> In this case, because of the policy attributes describing the MCCs, >>>>>> I think it >>>>> makes perfect sense for a consumer to ask for all the video MCCs >>>>> from Scene >>>>> 1, and none of them from Scene 2 or Scene 3. The consumer has enough >>>>> information to know this is a good choice if it wants to show video >>>>> from the >>>>> current active speaker, including multiple video captures with >>>>> spatial >>>>> relationship when the current speaker is in a multi-camera room. So >>>>> in this >>>>> case the consumer already has enough information to make a choice. >>>>> >>>>> I'm having difficulty imagining how to construct an algorithm for >>>>> that. >>>> >>>> [Duckworth, Mark] Yeah, it can get complicated. But is it good >>>> enough for equipment from different vendors to interoperate in a >>>> reasonable way, even if it isn't the "best" way? I think so. I >>>> still think my proposed "consumer makes all the switching decisions" >>>> approach can solve a lot of these problems. >>> >>> I know Cisco used to have a goal to make its equipment work "better >>> together". But in a sense that is exactly the thing that standards are >>> working against. >>> >>> With CLUE, *how* would a vendor's equipment do better with other of >>> its own, and just be "good enough" with others? Ultimately you can >>> only do as good as the provided information allows you to do. I can >>> see a few things: >>> >>> - a vendor is likely to make its equipment in configurations that >>> are designed to be easily compatible with one another. E.g., just >>> a small set of configurations, like 1,2, or 3 screens, all same >>> size, all side by side with consistent spacing. >>> >>> - a vendor could use a consistent style to structure its >>> advertisements. >>> E.g., Always have one scene for room cameras and one more for >>> presentations. >>> >>> - a vendor could build an algorithm for constructing configurations >>> that special cases advertisements structured the way it does them. >>> Then it could have very crude algorithms for anything else, or >>> just fail for anything else. >>> >>> - a vendor could build an algorithm for constructing configurations >>> that makes "leaps of faith" that aren't justified solely by what >>> is in an advertisement, about how the captures in the advertisement >>> work. (E.g., about the algorithm for switching, or how things are >>> laid out in a composition.) >>> >>> - a vendor could add proprietary information to advertisements, or to >>> the sip signaling, to convey extra information that allows one of >>> its own consuming endpoints to do a better job of constructing a >>> config than would be possible with just the standard information. >>> >>> Odds are that we will see all of the above. Certainly there are >>> inherent advantages when the advertisement happens to contain an >>> alternative that exactly matches the equipment in the consuming end. >>> And that is more likely to happen with equipment from one vendor. >>> >>> But beyond that, IMO, if we do our job well, then it should be >>> possible to construct a general purpose algorithm that will do as well >>> as algorithms that are special cased or that make "leaps of faith" or >>> use proprietary information. >>> >>>>> ISTM in this case that taking a cse from every scene will give the >>>>> best user >>>>> experience *if* the consumer has enough display resources to show all >>>>> these. >>>> >>>> [Duckworth, Mark] I think "best experience" is subjective here. I >>>> think the consumer has enough information to make a good choice for a >>>> variety of different consumer capability levels in terms of number of >>>> decoders and displays it has. Suppose the consumer can receive no >>>> more than 3 video encodings. It could ask for the 3 MCCs from Scene >>>> 1, or it could ask for 1 MCC from each scene. But I would think it >>>> would do that only if each scene had a CSE with one MCC in it. Each >>>> choice could give the "best" experience, depending on what the >>>> consumer is trying to present to the human users. >>> >>> I agree that "best experience" is subjective. But I suspect if we >>> worked out a lot of use cases, we could come close to agreeing to what >>> the "best experience" would be, in the absence of explicit input from >>> the end users in the room. >>> >>> I think what you are talking about is that there are a *set* of >>> "plausible" configurations, that it might make sense to offer as a >>> menu to the end user. >>> >>>>> If not, then it gets complex to sort out the tradeoffs. >>>>> >>>>> In this case, considering that a capture with "current active >>>>> speaker" >>>>> policy is more important than one with "previous active speaker". >>>>> >>>>> So I would suggest that the advertisement mark all the "current >>>>> active >>>>> speaker" captures with highest priority, and the others with >>>>> descending >>>>> priorities. >>>> >>>> [Duckworth, Mark] that's what I was thinking, but even that shouldn't >>>> be necessary because the consumer can make its own priority decision >>>> based on the policy attribute. >>> >>> Certainly it *can*. But then it must make a tradeoff between the >>> importance of the policy and the importance of the priority in the >>> decision. Lacking any understanding of the motivation for the priority >>> assignments, it is hard to trade those off against one another. >>> >>>>> Then, the consumer could start out assuming it should *try* for >>>>> one CSE >>>>> from each scene. It can look at different combinations, taking one >>>>> from each >>>>> scene, and evaluate what it can do with that combination. For each >>>>> one: >>>>> >>>>> If it can't handle all the captures from the selected cses, it can >>>>> start casting >>>>> out lower priority ones until it can handle it. Then it can assign a >>>>> score, >>>>> depending on the priorities of those it took, the priorities of >>>>> those it had to >>>>> abandon, and how much it had to "adjust" >>>>> the ones it took to fit on its displays. >>>>> >>>>> And it can repeat that for all the combinations of one cse from each >>>>> scene. >>>>> And then pick out the combination with the best score. >>>>> >>>>> This is all very heuristic. Will take a lot of thought and testing >>>>> to come up with >>>>> something that does well. (It would be interesting to work this out >>>>> in detail >>>>> for some specific consumer configurations and see if it can actually >>>>> find good >>>>> renderings.) >>>>> >>>>> Having the advertisement provide a single set of CSEs across all the >>>>> scenes >>>>> would "help" in that it would reduce the number of combinations the >>>>> consumer had to evaluate. >>>> >>>> [Duckworth, Mark] I'm not sure it would reduce anything. As >>>> Christian said, "The combinatorial issue becomes worse with the more >>>> Scenes that you have". I'm concerned that trying to add another >>>> layer of alternatives in the advertisement, that crosses scene >>>> boundaries, won't scale well. Or do you think it is really simpler >>>> than that? Are you envisioning the single set of CSEs could be kept >>>> small, even with many scenes? >>> >>> With separate CSE lists in each scene, the *consumer* has to evaluate >>> all the combinations of one CSE from each scene. >>> >>> With a single CSE list, the *advertiser* has to consider all of those >>> when constructing the advertisement. But it doesn't have to *include* >>> them all in the advertisement. My gut tells me that when there are >>> only a few then perhaps they are all interesting, but when they are >>> many, that only a few will be interesting enough to include. The >>> advertiser is pruning the choices, using information that it has that >>> isn't necessarily available to the consumer. >>> >>> If the advertiser is typically going to include all the combinations, >>> then going this way is a bad choice. And if the advertiser is going to >>> limit what it includes because it is too much work, or makes the >>> advertisement too big, even though it thinks the ones it is omitting >>> would be useful, then this is also a bad idea. >>> >>>>>> I agree there could be other situations where the MCC policy >>>>>> attributes >>>>> aren't enough information for the consumer to make a good choice. >>>>> This is >>>>> where I thought the media capture priority attribute should be >>>>> used. I >>>>> thought this was the purpose of adding the priority attribute in the >>>>> first >>>>> place. From the framework: >>>>>> >>>>>> 7.1.1.12. Priority >>>>>> The priority attribute indicates a relative priority between >>>>>> different Media >>>>> Captures. The Provider sets this priority, and the Consumer MAY use >>>>> the >>>>> priority to help decide which captures it wishes to receive. >>>>>> The "priority" attribute is an integer which indicates a relative >>>>>> priority >>>>> between Captures. For example it is possible to assign a priority >>>>> between >>>>> two presentation Captures that would allow a remote endpoint to >>>>> determine >>>>> which presentation is more important. Priority is assigned at the >>>>> individual >>>>> capture level. It represents the Provider's view of the relative >>>>> priority >>>>> between Captures with a priority. >>>>>> >>>>>> I don't understand why you say this isn't a priority issue, but >>>>>> rather an >>>>> alternative issue. It seems to me your proposal of advertising >>>>> different >>>>> combinations of captures or CSEs across scene boundaries is just >>>>> another >>>>> way for the provider to express priorities. >>>>> >>>>> Surely it is a form of prioritization. But it can be more >>>>> sophisticated than >>>>> simply assigning a priority value to each individual capture. >>>>> >>>>> But consider, if prioritization were sufficient, we wouldn't need to >>>>> have CSEs >>>>> at all. We could simply have prioritized captures. ISTM that the >>>>> reasons that >>>>> CSEs are more powerful than priorities within a scene should still >>>>> apply >>>>> outside a scene. >>>> >>>> [Duckworth, Mark] That makes sense too, at a high level, but I'm >>>> having trouble understanding how to put it in practice. >>>> >>>>> As I described above, I *think* priorities plus per-scene cse lists >>>>> can solve >>>>> your use case. But the processing to use it that way is complex. >>>> >>>> [Duckworth, Mark] So are you saying your idea of using a single set >>>> of CSEs across all scenes can solve the same problems in a less >>>> complex way? I'm open to that, but still not sure it would be any >>>> less complex. >>> >>> I think it is less complex for the consumer to evaluate a single list >>> than to evaluate combinations of choices from multiple lists. >>> (Enumerating all the combinations and generating an equivalent single >>> list to evaluate is of course a straightforward programming job. But I >>> wonder if some implementers might instead go for "special casing".) >>> >>> When constructing a single list, rather than several, and choosing >>> which combinations to include, the advertiser can use knowledge that >>> can't otherwise be described in the advertisement and used by the >>> consumer to choose. >>> >>> Thanks, >>> Paul >>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>> Sent: Thursday, February 06, 2014 12:34 PM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] How to choose from multiple scenes >>>>>>> >>>>>>> I just realized I had missed this reply. See inline. >>>>>>> >>>>>>> On 1/27/14 10:33 PM, Christian Groves wrote: >>>>>>>> Hello Paul, >>>>>>>> >>>>>>>> Please see below. >>>>>>>> >>>>>>>> Regards, Christian >>>>>>>> >>>>>>>> On 28/01/2014 10:06 AM, Paul Kyzivat wrote: >>>>>>>>> * The problem: >>>>>>>>> >>>>>>>>> As we discussed in the interim today, it seems unclear what a >>>>>>>>> consumer should do when receiving an advertisement with multiple >>>>>>>>> scenes in order to get a sufficient representation of the >>>>>>>>> advertised >>>>>>> content. >>>>>>>>> >>>>>>>>> Our simple cases have been where there is one scene for the >>>>>>>>> cameras >>>>>>>>> in the room, and another scene for a presentation. In that case, >>>>>>>>> one should take something from each scene (typically one CSE from >>>>>>>>> each) to get "enough". >>>>>>>>> >>>>>>>>> That is also true if an MCU acted in "pass through" mode and >>>>>>>>> simply >>>>>>>>> included "copies" of all the scenes it receives in >>>>>>>>> advertisements, >>>>>>>>> with encodings for them all. >>>>>>>>> >>>>>>>>> In a "simple" case with an MCU use MCC, it might "pass >>>>>>>>> through" all >>>>>>>>> the advertisements it receives, for their spatial info, but not >>>>>>>>> provide any encodings for them. Rather, it would provide one or >>>>>>>>> more new scenes using MCC to aggregate those sources. Then one >>>>>>>>> would not want to configure from the "pass through" scenes, but >>>>>>>>> that isn't an option anyway if there are no encodings for them. >>>>>>>> [CNG] The idea of the pass through information was that the >>>>>>>> consumer >>>>>>>> could use any capture attribute (not just spatial ones) to >>>>>>>> determine >>>>>>>> what media it wanted. >>>>>>> >>>>>>> Clearly if there are no encodings, then the captures are there only >>>>>>> for information and can't be configured. >>>>>>> >>>>>>> That is why I called this the "simple" case. >>>>>>> >>>>>>>>> Mark has proposed using multiple scenes with MCC to illustrate >>>>>>>>> switched cases where some groupings don't have any spatial >>>>>>>>> relationship to one another. Some of those examples end up with >>>>>>>>> multiple scenes that do have encodings, where it doesn't make >>>>>>>>> sense >>>>>>>>> to configure something from each scene. >>>>>>>> [CNG] I don't think there's anything in the framework that says a >>>>>>>> consumer must choose a capture from a scene. >>>>>>> >>>>>>> Of course there is no MUST. The consumer isn't required take >>>>>>> *anything*. >>>>>>> >>>>>>> The question is how the consumer knows what is required to have a >>>>>>> "complete" representation of what is in the advertisement. It >>>>>>> may not >>>>>>> want all that, but it is hard to make a good choice without >>>>>>> knowing. >>>>>>> >>>>>>> That is the point of CSEs - for the advertiser to indicate what it >>>>>>> considers to be good alternative choices. But CSEs only work >>>>>>> within a >>>>>>> scene. Once there are multiple scenes, the consumer has less >>>>>>> guidance >>>>>>> on what would be good (or sufficient) choices. >>>>>>> >>>>>>> The consumer has *some* information: >>>>>>> - if none of the captures in a scene have encodings, then there is >>>>>>> no need (or way) to select them directly >>>>>>> >>>>>>> - if MCC M in scene X references capture C in scene Y, then it >>>>>>> would be redundant to configure both M and C >>>>>>> >>>>>>> ISTM that one should start out assuming that you need all captures >>>>>>> (that have encodings) in *some* CSE from *each* scene. You can then >>>>>>> prune that based on the logic above. But is that *enough* to make >>>>>>> good >>>>> decisions? >>>>>>> At best, the logic to figure that out is complex. >>>>>>> >>>>>>>>> Today we discussed using priority to solve this, but this isn't >>>>>>>>> really a priority problem, it is a problem of *alternatives* that >>>>>>>>> may be equally desirable, depending on the resources or >>>>>>>>> desires of >>>>>>>>> the >>>>>>> consumer. >>>>>>>> [CNG] I agree I don't think priority is the right solution for >>>>>>>> this. >>>>>>>>> >>>>>>>>> IMO the problem is that our CSE mechanism is a way for the >>>>>>>>> advertiser to suggest alternatives, but this only works on a >>>>>>>>> per-scene >>>>> basis. >>>>>>>>> The advertiser has no comparable mechanism to suggest >>>>>>>>> alternatives >>>>>>>>> from different scenes. >>>>>>>>> >>>>>>>>> * My proposed solution: >>>>>>>>> >>>>>>>>> I want to restate a proposal I made a long time ago: >>>>>>>>> >>>>>>>>> Instead of one CSE list per scene, have one CSE list >>>>>>>>> per-advertisement, referencing captures from any scene. >>>>>>>>> >>>>>>>>> This makes it possible for the advertiser to recommend >>>>>>>>> combinations >>>>>>>>> that cross scene boundaries. >>>>>>>> [CNG] Perhaps you could give some examples? Does the list need >>>>>>>> to be >>>>>>>> exhaustive? >>>>>>> >>>>>>> Does the CSE list in a scene have to be exhaustive? >>>>>>> >>>>>>> I think each entry should be "sufficient" for somebody that can't >>>>>>> handle a bigger one. The definition of "sufficient" is subjective. >>>>>>> >>>>>>>> e.g. the simple case today >>>>>>>> Scene1 CSE1(VC1,VC2,VC3) >>>>>>>> CSE2(VC4) >>>>>>>> Scene2 CSE3(VC5,presentation1) >>>>>>>> >>>>>>>> Does it mean now the Advertisement would now have to advertise? >>>>>>>> CSE1(VC1,VC2,VC3,VC5) >>>>>>>> CSE2(VC4,VC5) >>>>>>>> CSE3(VC1,VC2,VC3) >>>>>>>> CSE4(VC4) >>>>>>>> CSE5(VC5) >>>>>>> >>>>>>> As I said, the definition of "sufficient" is subjective. >>>>>>> IMO the advertisement ought to include at least CSE1,CSE2. >>>>>>> >>>>>>> Rather than include the others, I think I would adjust the >>>>>>> priorities >>>>>>> of the individual captures based on my judgement of which I think >>>>>>> should be kept if they all can't be. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>>> * An alternate solution: >>>>>>>>> >>>>>>>>> Another possibility would be to leave CSEs as they are, but add >>>>>>>>> something analogous to a CSE list, but that lists recommended >>>>>>>>> combinations of scenes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Tue Feb 11 05:29:19 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAB41A02C6 for ; Tue, 11 Feb 2014 05:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccjipHLQnI7e for ; Tue, 11 Feb 2014 05:29:17 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 671061A008E for ; Tue, 11 Feb 2014 05:29:17 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 11 Feb 2014 05:29:17 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Tue, 11 Feb 2014 05:29:14 -0800 Thread-Topic: [clue] Changes in framework-14 Thread-Index: Ac8nDtD+HuFzOxJNSb2ordXk2V5xgAAHgUbQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF419@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF3C7@CRPMBOXPRD07.polycom.com> <52F9F28A.802@nteczone.com> In-Reply-To: <52F9F28A.802@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] Changes in framework-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 13:29:19 -0000 inline Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Tuesday, February 11, 2014 4:51 AM > To: clue@ietf.org > Subject: Re: [clue] Changes in framework-14 >=20 > Hello Mark, >=20 > I've just had a quick look and it looks pretty good. >=20 > A nit in Table 19 and 20, CSEs don't have IDs. The CSEs should just be CS= E, CSE > not CSE1 and CSE2. [Duckworth, Mark] I think it doesn't really matter if they have IDs or not = for this example. But in fact they do have IDs. From the data model: 15.2. sceneEntryID attribute The sceneEntryID attribute is a mandatory attribute containing the identifier of the capture scene entry represented by the element. > In Table 22 I'm not sure why the MCCs for the audio don't reference the > source? Wouldn't they list AC1 to AC5? [Duckworth, Mark] They could, but they don't have to. I think the example = works either way. >=20 > Regards, Christian >=20 > On 11/02/2014 11:54 AM, Duckworth, Mark wrote: > > > > Hello, > > > > I implemented the changes we've been talking about. There are still a > > few open issues we can continue to discuss, I'll go over those at the > > design team meeting Feb 11. > > > > Please review the MCC example in section 12.3.3. I think it is okay > > now as a complete example, but we might want to add another example, > > or change this one, pending results of the discussion "How to choose > > from multiple scenes". > > > > draft-ietf-clue-framework-14 has these changes: > > > > Changes from 13 to 14: > > > > 1. Fill in section for Security Considerations. > > > > 2. Replace Role placeholder with Participant Information, > > > > Participant Type, and Scene Information attributes. > > > > 3. Spatial information implies nothing about how constituent > > > > media captures are combined into a composed MCC. > > > > 4. Clean up MCC example in Section 12.3.3. Clarify behavior of > > > > tiled and PIP display windows. Add audio. Add new open > > > > issue about associating incoming packets to original source > > > > capture. > > > > 5. Remove editor's note and associated statement about RTP > > > > multiplexing at end of section 5. > > > > 6. Remove editor's note and associated paragraph about > > > > overloading media channel with both CLUE and non-CLUE usage, > > > > in section 5. > > > > 7. In section 10, clarify intent of media encodings conforming > > > > to SDP, even with multiple CLUE message exchanges. Remove > > > > associated editor's note. > > > > Regards, > > > > Mark > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Tue Feb 11 07:50:35 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5051A050E for ; Tue, 11 Feb 2014 07:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkc1Uku9CS0S for ; Tue, 11 Feb 2014 07:50:30 -0800 (PST) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id AE2731A0502 for ; Tue, 11 Feb 2014 07:50:28 -0800 (PST) Received: by mail-yh0-f49.google.com with SMTP id t59so6869555yho.8 for ; Tue, 11 Feb 2014 07:50:28 -0800 (PST) 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=R9ofYx20ybb1tcp6ICCf4+w5qbzj/tPFOKi3sexeXUc=; b=WFGeb3YjG7v/pKwizYHrUhLu7i7VhlGG6xBPsjSI7LtT/wys1yNvH1tFxJemjZb+b6 x6Vfth3rDhgM+7fRFiNTyrCFoHFDLvrenm5FmWr02CpDuu83oafENBucBboIefrzX/Sr KDbVBWL6FV/cFBn8+i8PsF1AFxSRlWL05RW5ipPCmPyVsspIvkDIkb5RBsiEr5zxk2Jj uRuZB0cLFqx/NgmPxWnzToMK3rf8zGFcwcFPP+ph0aUTv+ZztV7/BgXtp55HDIjOxta9 kGibP/DoV8mIMe7t6gBijo0Z6Uoi1cVo6mLjURXJ/n7lUvRkyIoohXS5HAovb2e1jDp/ hHQQ== MIME-Version: 1.0 X-Received: by 10.236.163.137 with SMTP id a9mr1048520yhl.150.1392133386468; Tue, 11 Feb 2014 07:43:06 -0800 (PST) Received: by 10.170.150.2 with HTTP; Tue, 11 Feb 2014 07:43:06 -0800 (PST) Date: Tue, 11 Feb 2014 09:43:06 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf301d406cfb059c04f2234ff9 Subject: [clue] Reminder: draft deadline for IETF-89 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 15:50:36 -0000 --20cf301d406cfb059c04f2234ff9 Content-Type: text/plain; charset=ISO-8859-1 As a reminder, the draft deadline for the London meeting is this Friday (Feb. 14th), so you don't get the usual weekend to work up to a Monday deadline: http://www.ietf.org/meeting/important-dates-2014.html#IETF89 Note also that a draft agenda is due on Monday, Feb. 17th, so the chairs will put one together based on the current set of work items. If you have something beyond that, please let us know ASAP. Thanks, Mary. --20cf301d406cfb059c04f2234ff9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As a reminder, the draft deadline for the London meeting i= s this Friday (Feb. 14th), so you don't get the usual weekend to work u= p to a Monday deadline:=A0

Note also that a draft agenda is due on Monday, F= eb. 17th, so the chairs will put one together based on the current set of w= ork items. =A0If you have something beyond that, please let us know ASAP.= =A0

Thanks,
Mary.=A0
--20cf301d406cfb059c04f2234ff9-- From Christian.Groves@nteczone.com Tue Feb 11 14:34:45 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED78D1A0738 for ; Tue, 11 Feb 2014 14:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U81DiJkdQstF for ; Tue, 11 Feb 2014 14:34:43 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEAC1A078F for ; Tue, 11 Feb 2014 14:34:43 -0800 (PST) Received: from ppp118-209-48-139.lns20.mel4.internode.on.net ([118.209.48.139]:54090 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDLtE-0001ac-9I; Wed, 12 Feb 2014 09:33:16 +1100 Message-ID: <52FAA57F.8010700@nteczone.com> Date: Wed, 12 Feb 2014 09:34:39 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF3C7@CRPMBOXPRD07.polycom.com> <52F9F28A.802@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF419@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF419@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Changes in framework-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 22:34:46 -0000 Hello Mark, Please see below. Regards, Christian On 12/02/2014 12:29 AM, Duckworth, Mark wrote: > inline > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Tuesday, February 11, 2014 4:51 AM >> To: clue@ietf.org >> Subject: Re: [clue] Changes in framework-14 >> >> Hello Mark, >> >> I've just had a quick look and it looks pretty good. >> >> A nit in Table 19 and 20, CSEs don't have IDs. The CSEs should just be CSE, CSE >> not CSE1 and CSE2. > [Duckworth, Mark] I think it doesn't really matter if they have IDs or not for this example. But in fact they do have IDs. From the data model: > 15.2. sceneEntryID attribute > The sceneEntryID attribute is a mandatory attribute containing the > identifier of the capture scene entry represented by the > element. >> In Table 22 I'm not sure why the MCCs for the audio don't reference the >> source? Wouldn't they list AC1 to AC5? > [Duckworth, Mark] They could, but they don't have to. I think the example works either way. [CNG] I think we need to clarify this in the framework. We first didn't need to provide an ID for CSEs. Then it seems we added the ability for CSEs to be included in STSs. This then means that CSEs do need IDs. There is text in the framework about Captures needing a Advertisement unique Identity but there is no text regarding CSEs (and Scenes due to them being added to STSs) needing unique identities. This would also mean that all the examples need to be updated to have unique CSE ids. i.e. in section 7.1 key points are given for media Captures including information about identity. We should do something similar for Scenes and CSEs. > >> Regards, Christian >> >> On 11/02/2014 11:54 AM, Duckworth, Mark wrote: >>> Hello, >>> >>> I implemented the changes we've been talking about. There are still a >>> few open issues we can continue to discuss, I'll go over those at the >>> design team meeting Feb 11. >>> >>> Please review the MCC example in section 12.3.3. I think it is okay >>> now as a complete example, but we might want to add another example, >>> or change this one, pending results of the discussion "How to choose >>> from multiple scenes". >>> >>> draft-ietf-clue-framework-14 has these changes: >>> >>> Changes from 13 to 14: >>> >>> 1. Fill in section for Security Considerations. >>> >>> 2. Replace Role placeholder with Participant Information, >>> >>> Participant Type, and Scene Information attributes. >>> >>> 3. Spatial information implies nothing about how constituent >>> >>> media captures are combined into a composed MCC. >>> >>> 4. Clean up MCC example in Section 12.3.3. Clarify behavior of >>> >>> tiled and PIP display windows. Add audio. Add new open >>> >>> issue about associating incoming packets to original source >>> >>> capture. >>> >>> 5. Remove editor's note and associated statement about RTP >>> >>> multiplexing at end of section 5. >>> >>> 6. Remove editor's note and associated paragraph about >>> >>> overloading media channel with both CLUE and non-CLUE usage, >>> >>> in section 5. >>> >>> 7. In section 10, clarify intent of media encodings conforming >>> >>> to SDP, even with multiple CLUE message exchanges. Remove >>> >>> associated editor's note. >>> >>> Regards, >>> >>> Mark >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Feb 11 14:36:46 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4547C1A078F for ; Tue, 11 Feb 2014 14:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQFUOJEEqxcV for ; Tue, 11 Feb 2014 14:36:42 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3625C1A0798 for ; Tue, 11 Feb 2014 14:36:41 -0800 (PST) Received: from ppp118-209-48-139.lns20.mel4.internode.on.net ([118.209.48.139]:54105 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WDLv8-0001rp-F9 for clue@ietf.org; Wed, 12 Feb 2014 09:35:14 +1100 Message-ID: <52FAA5F6.8090608@nteczone.com> Date: Wed, 12 Feb 2014 09:36:38 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> <52F553B4.8070206@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB7FC@CRPMBOXPRD07.polycom.com> <52F6754A.3050501@alum.mit.edu> <52F823A1.3080308@nteczone.com> <52F90219.4070504@alum.mit.edu> <52F9F52F.9090705@nteczone.com> In-Reply-To: <52F9F52F.9090705@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 22:36:46 -0000 I stand corrected on my point re: CSE not having IDs. However given that we have the STS which may list CSEs that can be provided together do we another thing? Christian On 11/02/2014 9:02 PM, Christian Groves wrote: > Hello Paul and Mark, > > Please see my comments below. > > Regards, Christian > > On 11/02/2014 3:45 AM, Paul Kyzivat wrote: >> On 2/9/14 7:56 PM, Christian Groves wrote: >>> Hello Paul, >>> >>> I think some uses cases would be good. >>> >>> I'd like to see a third case where we'd have something like a "Scene >>> Set >>> Entry" (SSE). This would indicate what scenes would make up a "full' >>> description of an endpoint. >>> >>> i.e. Scene1 (CSE1) >>> Scene2 (CSE2) >>> Scene3 (CSE3) >>> SSE [(Scene1,Scene2),(Scene1)] >>> A consumer would know it should pick CSE1 and CSE2 for a complete >>> description or CSE3. >>> >>> I think this is along the lines of your single CSE. >> >> IIUC, that is a way to distinguish which scenes need to be >> considered. Mentioned that as a possibility in passing in one of my >> messages. > [CNG] I thought that knowing which scenes go together was the core of > the issue. An Advertiser says here's the set of scenes that go > together. The Advertiser uses the CSEs to indicate the different > rendering options for each scene. >> >> It still leaves the consumer with a combinatorial analysis. >> >> Another possibility is: >> >> - Leave existing per-scene CSE lists as-is. >> >> - Add another advertisement-wide CSE list. >> The entries in it could use shorthand, by referencing CSEs from >> the individual scenes. >> >> E.g., >> >> Scene1 (CSE11, CSE12, CSE13) >> Scene2 (CSE21, CSE22) >> Scene3 (CSE31) >> Scene4 (CSE41) >> >> Global-CSE-List ( >> CSEg1(CSE11, CSE21, CSE31) >> CSEg2(CSE12, CSE22, CSE31) >> CSEg3(CSE13, CSE22, CSE31) >> ) > [CNG] The issue is that currently we do not assign any sort of ID to > CSEs. There hasn't been a reason to as the consumer selects the > captures it wants. > > I think the above complicates things. With this we are now saying that > which scenes are chosen depend on the rendering of each of the scenes. > Our current assumption is that a CSE represents the "whole scene". > Each CSE is effectively a different rendering of this whole. With the > above we are now changing that to imply that a CSE may be a part of a > scene because which other Scenes/CSEs you chose is based on that > rendering. Its not a syntax issue only we're playing with the > semantics of what we have also. > > >> >> Here the global CSE list has recommended a subset of the possible >> combinations of CSEs from the different scenes, and has omitted >> Scene4 altogether. This is a value judgement of what combinations >> make sense. >> >> Note that I would still allow the CSEs in the global list to >> reference individual captures if desired. But referencing other CSEs >> is a convenient shorthand. >> >> Thanks, >> Paul >> >>> Regards, Christian >>> >>> On 9/02/2014 5:19 AM, Paul Kyzivat wrote: >>>> On 2/7/14 5:58 PM, Duckworth, Mark wrote: >>>>> Hi Paul, >>>>> Comments inline. >>>>> I'm open to your idea of a single set of CSEs across all scenes, but >>>>> I'm trying to understand if it will really be a scalable and less >>>>> complex way to solve these issues. >>>> >>>> Me too. I'm not certain that it will, but my gut says so. >>>> It just seems to me that the idea of enumerating useful combinations >>>> of captures in the advertisement is conceptually unrelated to what >>>> scene they are in, and that for the consumer the process then by >>>> default devolves to just choosing the one best cse that works for it, >>>> rather than having to choose from among combinations in different >>>> scenes. >>>> >>>>> Do you think it would help if you presented this idea at the design >>>>> team meeting next week? >>>> >>>> I'm not convinced that call time is very helpful for this. >>>> To be useful I would probably need to create several use cases, and >>>> show them both ways, and then for people to try to shoot them down. >>>> I think that kind of thing is better done by email. (And I don't have >>>> time to put together sufficient use cases before Tuesday.) >>>> >>>> More below. >>>> >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>> Sent: Friday, February 07, 2014 4:44 PM >>>>>> To: Duckworth, Mark; clue@ietf.org >>>>>> Subject: Re: [clue] How to choose from multiple scenes >>>>>> >>>>>> On 2/7/14 3:26 PM, Duckworth, Mark wrote: >>>>>>> Hi Paul, >>>>>>> >>>>>>> You describe the issue very well, but I don't agree with a couple >>>>>>> things. You >>>>>> wrote: >>>>>>>> ISTM that one should start out assuming that you need all captures >>>>>>>> (that have encodings) in *some* CSE from *each* scene. >>>>>>> I don't think that is an appropriate thing to assume. The case I >>>>>>> was thinking >>>>>> of, and we have been talking about at design team meetings, is like >>>>>> this: >>>>>>> Scene 1 - current active speaker >>>>>>> Scene 2 - previous active speaker >>>>>>> Scene 3 - previous previous active speaker and so on... >>>>>> >>>>>> I understand your *intent* here. But I don't know how the consumer >>>>>> acts on >>>>>> that. It is really part of the point I am trying to make. >>>>>> How does the consumer *know* the above, and take it into account? >>>>>> Are the *scenes* tagged to indicate that? (I don't think so.) >>>>> >>>>> [Duckworth, Mark] From the MCC policy attribute values. >>>>> >>>>>>> Where each scene could have multiple switched MCCs representing the >>>>>> scene, and the provider has some flexibility to group together >>>>>> different >>>>>> individual captures to include in the MCCs of a scene, depending on >>>>>> synchID >>>>>> and who is talking. >>>>>>> In this case, because of the policy attributes describing the MCCs, >>>>>>> I think it >>>>>> makes perfect sense for a consumer to ask for all the video MCCs >>>>>> from Scene >>>>>> 1, and none of them from Scene 2 or Scene 3. The consumer has >>>>>> enough >>>>>> information to know this is a good choice if it wants to show video >>>>>> from the >>>>>> current active speaker, including multiple video captures with >>>>>> spatial >>>>>> relationship when the current speaker is in a multi-camera room. So >>>>>> in this >>>>>> case the consumer already has enough information to make a choice. >>>>>> >>>>>> I'm having difficulty imagining how to construct an algorithm for >>>>>> that. >>>>> >>>>> [Duckworth, Mark] Yeah, it can get complicated. But is it good >>>>> enough for equipment from different vendors to interoperate in a >>>>> reasonable way, even if it isn't the "best" way? I think so. I >>>>> still think my proposed "consumer makes all the switching decisions" >>>>> approach can solve a lot of these problems. >>>> >>>> I know Cisco used to have a goal to make its equipment work "better >>>> together". But in a sense that is exactly the thing that standards are >>>> working against. >>>> >>>> With CLUE, *how* would a vendor's equipment do better with other of >>>> its own, and just be "good enough" with others? Ultimately you can >>>> only do as good as the provided information allows you to do. I can >>>> see a few things: >>>> >>>> - a vendor is likely to make its equipment in configurations that >>>> are designed to be easily compatible with one another. E.g., just >>>> a small set of configurations, like 1,2, or 3 screens, all same >>>> size, all side by side with consistent spacing. >>>> >>>> - a vendor could use a consistent style to structure its >>>> advertisements. >>>> E.g., Always have one scene for room cameras and one more for >>>> presentations. >>>> >>>> - a vendor could build an algorithm for constructing configurations >>>> that special cases advertisements structured the way it does them. >>>> Then it could have very crude algorithms for anything else, or >>>> just fail for anything else. >>>> >>>> - a vendor could build an algorithm for constructing configurations >>>> that makes "leaps of faith" that aren't justified solely by what >>>> is in an advertisement, about how the captures in the advertisement >>>> work. (E.g., about the algorithm for switching, or how things are >>>> laid out in a composition.) >>>> >>>> - a vendor could add proprietary information to advertisements, or to >>>> the sip signaling, to convey extra information that allows one of >>>> its own consuming endpoints to do a better job of constructing a >>>> config than would be possible with just the standard information. >>>> >>>> Odds are that we will see all of the above. Certainly there are >>>> inherent advantages when the advertisement happens to contain an >>>> alternative that exactly matches the equipment in the consuming end. >>>> And that is more likely to happen with equipment from one vendor. >>>> >>>> But beyond that, IMO, if we do our job well, then it should be >>>> possible to construct a general purpose algorithm that will do as well >>>> as algorithms that are special cased or that make "leaps of faith" or >>>> use proprietary information. >>>> >>>>>> ISTM in this case that taking a cse from every scene will give the >>>>>> best user >>>>>> experience *if* the consumer has enough display resources to show >>>>>> all >>>>>> these. >>>>> >>>>> [Duckworth, Mark] I think "best experience" is subjective here. I >>>>> think the consumer has enough information to make a good choice for a >>>>> variety of different consumer capability levels in terms of number of >>>>> decoders and displays it has. Suppose the consumer can receive no >>>>> more than 3 video encodings. It could ask for the 3 MCCs from Scene >>>>> 1, or it could ask for 1 MCC from each scene. But I would think it >>>>> would do that only if each scene had a CSE with one MCC in it. Each >>>>> choice could give the "best" experience, depending on what the >>>>> consumer is trying to present to the human users. >>>> >>>> I agree that "best experience" is subjective. But I suspect if we >>>> worked out a lot of use cases, we could come close to agreeing to what >>>> the "best experience" would be, in the absence of explicit input from >>>> the end users in the room. >>>> >>>> I think what you are talking about is that there are a *set* of >>>> "plausible" configurations, that it might make sense to offer as a >>>> menu to the end user. >>>> >>>>>> If not, then it gets complex to sort out the tradeoffs. >>>>>> >>>>>> In this case, considering that a capture with "current active >>>>>> speaker" >>>>>> policy is more important than one with "previous active speaker". >>>>>> >>>>>> So I would suggest that the advertisement mark all the "current >>>>>> active >>>>>> speaker" captures with highest priority, and the others with >>>>>> descending >>>>>> priorities. >>>>> >>>>> [Duckworth, Mark] that's what I was thinking, but even that shouldn't >>>>> be necessary because the consumer can make its own priority decision >>>>> based on the policy attribute. >>>> >>>> Certainly it *can*. But then it must make a tradeoff between the >>>> importance of the policy and the importance of the priority in the >>>> decision. Lacking any understanding of the motivation for the priority >>>> assignments, it is hard to trade those off against one another. >>>> >>>>>> Then, the consumer could start out assuming it should *try* for >>>>>> one CSE >>>>>> from each scene. It can look at different combinations, taking one >>>>>> from each >>>>>> scene, and evaluate what it can do with that combination. For >>>>>> each one: >>>>>> >>>>>> If it can't handle all the captures from the selected cses, it can >>>>>> start casting >>>>>> out lower priority ones until it can handle it. Then it can assign a >>>>>> score, >>>>>> depending on the priorities of those it took, the priorities of >>>>>> those it had to >>>>>> abandon, and how much it had to "adjust" >>>>>> the ones it took to fit on its displays. >>>>>> >>>>>> And it can repeat that for all the combinations of one cse from each >>>>>> scene. >>>>>> And then pick out the combination with the best score. >>>>>> >>>>>> This is all very heuristic. Will take a lot of thought and testing >>>>>> to come up with >>>>>> something that does well. (It would be interesting to work this out >>>>>> in detail >>>>>> for some specific consumer configurations and see if it can actually >>>>>> find good >>>>>> renderings.) >>>>>> >>>>>> Having the advertisement provide a single set of CSEs across all the >>>>>> scenes >>>>>> would "help" in that it would reduce the number of combinations the >>>>>> consumer had to evaluate. >>>>> >>>>> [Duckworth, Mark] I'm not sure it would reduce anything. As >>>>> Christian said, "The combinatorial issue becomes worse with the more >>>>> Scenes that you have". I'm concerned that trying to add another >>>>> layer of alternatives in the advertisement, that crosses scene >>>>> boundaries, won't scale well. Or do you think it is really simpler >>>>> than that? Are you envisioning the single set of CSEs could be kept >>>>> small, even with many scenes? >>>> >>>> With separate CSE lists in each scene, the *consumer* has to evaluate >>>> all the combinations of one CSE from each scene. >>>> >>>> With a single CSE list, the *advertiser* has to consider all of those >>>> when constructing the advertisement. But it doesn't have to *include* >>>> them all in the advertisement. My gut tells me that when there are >>>> only a few then perhaps they are all interesting, but when they are >>>> many, that only a few will be interesting enough to include. The >>>> advertiser is pruning the choices, using information that it has that >>>> isn't necessarily available to the consumer. >>>> >>>> If the advertiser is typically going to include all the combinations, >>>> then going this way is a bad choice. And if the advertiser is going to >>>> limit what it includes because it is too much work, or makes the >>>> advertisement too big, even though it thinks the ones it is omitting >>>> would be useful, then this is also a bad idea. >>>> >>>>>>> I agree there could be other situations where the MCC policy >>>>>>> attributes >>>>>> aren't enough information for the consumer to make a good choice. >>>>>> This is >>>>>> where I thought the media capture priority attribute should be >>>>>> used. I >>>>>> thought this was the purpose of adding the priority attribute in the >>>>>> first >>>>>> place. From the framework: >>>>>>> >>>>>>> 7.1.1.12. Priority >>>>>>> The priority attribute indicates a relative priority between >>>>>>> different Media >>>>>> Captures. The Provider sets this priority, and the Consumer MAY use >>>>>> the >>>>>> priority to help decide which captures it wishes to receive. >>>>>>> The "priority" attribute is an integer which indicates a relative >>>>>>> priority >>>>>> between Captures. For example it is possible to assign a priority >>>>>> between >>>>>> two presentation Captures that would allow a remote endpoint to >>>>>> determine >>>>>> which presentation is more important. Priority is assigned at the >>>>>> individual >>>>>> capture level. It represents the Provider's view of the relative >>>>>> priority >>>>>> between Captures with a priority. >>>>>>> >>>>>>> I don't understand why you say this isn't a priority issue, but >>>>>>> rather an >>>>>> alternative issue. It seems to me your proposal of advertising >>>>>> different >>>>>> combinations of captures or CSEs across scene boundaries is just >>>>>> another >>>>>> way for the provider to express priorities. >>>>>> >>>>>> Surely it is a form of prioritization. But it can be more >>>>>> sophisticated than >>>>>> simply assigning a priority value to each individual capture. >>>>>> >>>>>> But consider, if prioritization were sufficient, we wouldn't need to >>>>>> have CSEs >>>>>> at all. We could simply have prioritized captures. ISTM that the >>>>>> reasons that >>>>>> CSEs are more powerful than priorities within a scene should still >>>>>> apply >>>>>> outside a scene. >>>>> >>>>> [Duckworth, Mark] That makes sense too, at a high level, but I'm >>>>> having trouble understanding how to put it in practice. >>>>> >>>>>> As I described above, I *think* priorities plus per-scene cse lists >>>>>> can solve >>>>>> your use case. But the processing to use it that way is complex. >>>>> >>>>> [Duckworth, Mark] So are you saying your idea of using a single set >>>>> of CSEs across all scenes can solve the same problems in a less >>>>> complex way? I'm open to that, but still not sure it would be any >>>>> less complex. >>>> >>>> I think it is less complex for the consumer to evaluate a single list >>>> than to evaluate combinations of choices from multiple lists. >>>> (Enumerating all the combinations and generating an equivalent single >>>> list to evaluate is of course a straightforward programming job. But I >>>> wonder if some implementers might instead go for "special casing".) >>>> >>>> When constructing a single list, rather than several, and choosing >>>> which combinations to include, the advertiser can use knowledge that >>>> can't otherwise be described in the advertisement and used by the >>>> consumer to choose. >>>> >>>> Thanks, >>>> Paul >>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Mark >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>>>>> Kyzivat >>>>>>>> Sent: Thursday, February 06, 2014 12:34 PM >>>>>>>> To: clue@ietf.org >>>>>>>> Subject: Re: [clue] How to choose from multiple scenes >>>>>>>> >>>>>>>> I just realized I had missed this reply. See inline. >>>>>>>> >>>>>>>> On 1/27/14 10:33 PM, Christian Groves wrote: >>>>>>>>> Hello Paul, >>>>>>>>> >>>>>>>>> Please see below. >>>>>>>>> >>>>>>>>> Regards, Christian >>>>>>>>> >>>>>>>>> On 28/01/2014 10:06 AM, Paul Kyzivat wrote: >>>>>>>>>> * The problem: >>>>>>>>>> >>>>>>>>>> As we discussed in the interim today, it seems unclear what a >>>>>>>>>> consumer should do when receiving an advertisement with multiple >>>>>>>>>> scenes in order to get a sufficient representation of the >>>>>>>>>> advertised >>>>>>>> content. >>>>>>>>>> >>>>>>>>>> Our simple cases have been where there is one scene for the >>>>>>>>>> cameras >>>>>>>>>> in the room, and another scene for a presentation. In that case, >>>>>>>>>> one should take something from each scene (typically one CSE >>>>>>>>>> from >>>>>>>>>> each) to get "enough". >>>>>>>>>> >>>>>>>>>> That is also true if an MCU acted in "pass through" mode and >>>>>>>>>> simply >>>>>>>>>> included "copies" of all the scenes it receives in >>>>>>>>>> advertisements, >>>>>>>>>> with encodings for them all. >>>>>>>>>> >>>>>>>>>> In a "simple" case with an MCU use MCC, it might "pass >>>>>>>>>> through" all >>>>>>>>>> the advertisements it receives, for their spatial info, but not >>>>>>>>>> provide any encodings for them. Rather, it would provide one or >>>>>>>>>> more new scenes using MCC to aggregate those sources. Then one >>>>>>>>>> would not want to configure from the "pass through" scenes, but >>>>>>>>>> that isn't an option anyway if there are no encodings for them. >>>>>>>>> [CNG] The idea of the pass through information was that the >>>>>>>>> consumer >>>>>>>>> could use any capture attribute (not just spatial ones) to >>>>>>>>> determine >>>>>>>>> what media it wanted. >>>>>>>> >>>>>>>> Clearly if there are no encodings, then the captures are there >>>>>>>> only >>>>>>>> for information and can't be configured. >>>>>>>> >>>>>>>> That is why I called this the "simple" case. >>>>>>>> >>>>>>>>>> Mark has proposed using multiple scenes with MCC to illustrate >>>>>>>>>> switched cases where some groupings don't have any spatial >>>>>>>>>> relationship to one another. Some of those examples end up with >>>>>>>>>> multiple scenes that do have encodings, where it doesn't make >>>>>>>>>> sense >>>>>>>>>> to configure something from each scene. >>>>>>>>> [CNG] I don't think there's anything in the framework that says a >>>>>>>>> consumer must choose a capture from a scene. >>>>>>>> >>>>>>>> Of course there is no MUST. The consumer isn't required take >>>>>>>> *anything*. >>>>>>>> >>>>>>>> The question is how the consumer knows what is required to have a >>>>>>>> "complete" representation of what is in the advertisement. It >>>>>>>> may not >>>>>>>> want all that, but it is hard to make a good choice without >>>>>>>> knowing. >>>>>>>> >>>>>>>> That is the point of CSEs - for the advertiser to indicate what it >>>>>>>> considers to be good alternative choices. But CSEs only work >>>>>>>> within a >>>>>>>> scene. Once there are multiple scenes, the consumer has less >>>>>>>> guidance >>>>>>>> on what would be good (or sufficient) choices. >>>>>>>> >>>>>>>> The consumer has *some* information: >>>>>>>> - if none of the captures in a scene have encodings, then there is >>>>>>>> no need (or way) to select them directly >>>>>>>> >>>>>>>> - if MCC M in scene X references capture C in scene Y, then it >>>>>>>> would be redundant to configure both M and C >>>>>>>> >>>>>>>> ISTM that one should start out assuming that you need all captures >>>>>>>> (that have encodings) in *some* CSE from *each* scene. You can >>>>>>>> then >>>>>>>> prune that based on the logic above. But is that *enough* to make >>>>>>>> good >>>>>> decisions? >>>>>>>> At best, the logic to figure that out is complex. >>>>>>>> >>>>>>>>>> Today we discussed using priority to solve this, but this isn't >>>>>>>>>> really a priority problem, it is a problem of *alternatives* >>>>>>>>>> that >>>>>>>>>> may be equally desirable, depending on the resources or >>>>>>>>>> desires of >>>>>>>>>> the >>>>>>>> consumer. >>>>>>>>> [CNG] I agree I don't think priority is the right solution for >>>>>>>>> this. >>>>>>>>>> >>>>>>>>>> IMO the problem is that our CSE mechanism is a way for the >>>>>>>>>> advertiser to suggest alternatives, but this only works on a >>>>>>>>>> per-scene >>>>>> basis. >>>>>>>>>> The advertiser has no comparable mechanism to suggest >>>>>>>>>> alternatives >>>>>>>>>> from different scenes. >>>>>>>>>> >>>>>>>>>> * My proposed solution: >>>>>>>>>> >>>>>>>>>> I want to restate a proposal I made a long time ago: >>>>>>>>>> >>>>>>>>>> Instead of one CSE list per scene, have one CSE list >>>>>>>>>> per-advertisement, referencing captures from any scene. >>>>>>>>>> >>>>>>>>>> This makes it possible for the advertiser to recommend >>>>>>>>>> combinations >>>>>>>>>> that cross scene boundaries. >>>>>>>>> [CNG] Perhaps you could give some examples? Does the list need >>>>>>>>> to be >>>>>>>>> exhaustive? >>>>>>>> >>>>>>>> Does the CSE list in a scene have to be exhaustive? >>>>>>>> >>>>>>>> I think each entry should be "sufficient" for somebody that can't >>>>>>>> handle a bigger one. The definition of "sufficient" is subjective. >>>>>>>> >>>>>>>>> e.g. the simple case today >>>>>>>>> Scene1 CSE1(VC1,VC2,VC3) >>>>>>>>> CSE2(VC4) >>>>>>>>> Scene2 CSE3(VC5,presentation1) >>>>>>>>> >>>>>>>>> Does it mean now the Advertisement would now have to advertise? >>>>>>>>> CSE1(VC1,VC2,VC3,VC5) >>>>>>>>> CSE2(VC4,VC5) >>>>>>>>> CSE3(VC1,VC2,VC3) >>>>>>>>> CSE4(VC4) >>>>>>>>> CSE5(VC5) >>>>>>>> >>>>>>>> As I said, the definition of "sufficient" is subjective. >>>>>>>> IMO the advertisement ought to include at least CSE1,CSE2. >>>>>>>> >>>>>>>> Rather than include the others, I think I would adjust the >>>>>>>> priorities >>>>>>>> of the individual captures based on my judgement of which I think >>>>>>>> should be kept if they all can't be. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>>> * An alternate solution: >>>>>>>>>> >>>>>>>>>> Another possibility would be to leave CSEs as they are, but add >>>>>>>>>> something analogous to a CSE list, but that lists recommended >>>>>>>>>> combinations of scenes. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> 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 scarlett.liuyan@huawei.com Tue Feb 11 19:53:49 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86661A033A for ; Tue, 11 Feb 2014 19:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlMTEch8vdFx for ; Tue, 11 Feb 2014 19:53:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 802171A07A9 for ; Tue, 11 Feb 2014 19:53:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBA39222; Wed, 12 Feb 2014 03:53:45 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 03:52:47 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 03:53:44 +0000 Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.104]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 11:53:34 +0800 From: "Liuyan (Scarlett)" To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: Identical stream ID values in both directions? Thread-Index: AQHPIbVP3ZnGtuZ6YkmTiKnVfw/W5pqknpCAgACZxYCAC8t58A== Date: Wed, 12 Feb 2014 03:53:34 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> <52F177D1.5090700@nteczone.com> In-Reply-To: <52F177D1.5090700@nteczone.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.137.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Lijing \(Jessie\)" Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 03:53:49 -0000 Hello Christian, Paul and Christer, Although, the rtcweb data channel draft does NOT say identical stream I= D values in both directions. The rtcweb data protocol draft does says it as below: 3. Terminology This document uses the following terms: Association: An SCTP association. Stream: A unidirectional stream of an SCTP association. It is uniquely identified by an SCTP stream identifier (0-6553= 4). Note: the SCTP stream identifier 65535 is reserved due to SCTP= INIT and INIT-ACK chunks only allowing a maximum of 65535 streams= to be negotiated (0-65534). Channel: Two Streams with the same SCTP stream identifier, one = in each direction, which are managed together. In addition, I have a question to ask for you as below.=20 =20 Best Regards, Scarlett -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves Sent: Wednesday, February 05, 2014 7:29 AM To: clue@ietf.org Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both d= irections? Hello, On 5/02/2014 1:18 AM, Christer Holmberg wrote: > Hi, > >>> Paul earlier suggested that we, for the SCTP streams that form the=20 >>> CLUE Data Channel, shall mandate the usage of identical stream ID=20 >>> values in each direction. >>> >>> Perhaps I missed it, but what was the reason for that? To use the=20 >>> stream ID in order know on which stream CLUE messages are received? >>> >>> I do agree that we need a way to know on which stream CLUE messages=20 >>> are received, and we can for sure recommend using the same values,=20 >>> but until we know what will be negotiated in SDP I'd like to keep=20 >>> the MUST as an open issue. >>> >>> Also, the rtcweb data channel draft says: >>> >>> "Note that there's no requirement for the SCTP streams used to=20 >>> create >>> >>> a bidirectional channel have the same number in=20 >>> each direction. How >>> >>> stream values are selected is protocol and=20 >>> implementation dependent." >> I was thinking they had to match in rtcweb. If they *don't* have to matc= h, then how are they correlated? > As we discussed before, at the moment it seems like they assume a single = usage per association. > > ...which is perhaps the only thing rtcweb requires, but the mechanism hav= e to be general. > >> I just looked, and found the text you quote. I *guess* if the negotiatio= n is done externally they can just wave their hands like this. >> But for channels opened using the rtcweb data channel protocol I don't s= ee how they can avoid specifying how the correlation is done. But I looked = there too, and they don't seem to say. I think it is a hole in their spec. > Yes - among the others :) [CNG] I agree. I've been looking at this also in terms of gateway support f= or SCTP and CLUE, BFCP, T.38 etc. The differences between the SCTP SDP draf= t and RTCWEB transport ones and holes with regards to STCP channel -> proto= col assignment makes it hard to specify any generic behaviour. [Scarlett] If there are more than one usage per association, the usages can= be identified by different PPID. I am not sure about the discussion as abo= ve. Regards, Christian > > Regards, > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Wed Feb 12 02:44:04 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8991A091A for ; Wed, 12 Feb 2014 02:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0X9uYi1kGSs for ; Wed, 12 Feb 2014 02:44:03 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 84FF31A093A for ; Wed, 12 Feb 2014 02:44:02 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-2d-52fb5070941d Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 07.34.04853.0705BF25; Wed, 12 Feb 2014 11:44:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 11:44:00 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft new version: draft-holmberg-clue-datachannel-03 Thread-Index: Ac8n3ve+3AJvuKTYQOORkkbQi93iRw== Date: Wed, 12 Feb 2014 10:43:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16E7C5@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_7594FB04B1934943A5C02806D1A2204B1D16E7C5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+JvjW5hwO8gg4bfXBb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsxT19gKdhhVdJ7sZmpgXK3TxcjJISFgIvF07ywmCFtM4sK9 9WwgtpDACUaJo6cruxi5gOzFjBK7mmawdzFycLAJWEh0/9MGqRERUJY4urkfrF5YwE6iZd0/ doi4s8S3j30sELaexL+b28BsFgFVibd37oHt4hXwlViz7hsjiM0ItPf7qTVgcWYBcYlbT+ZD 3SMgsWTPeWYIW1Ti5eN/rCAnSAgoSizvl4Moz5dYfbCJHWKkoMTJmU9YJjAKzUIyaRaSsllI yiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRsni1OLi3HQjA73c9NwSvdSizOTi4vw8 veLUTYzAuDi45bfRDsaTe+wPMUpzsCiJ815nrQkSEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wNgbdH5dzSTlt1mGb1o3i5dO4av0iDj0JGiLvfW52jsq1zpNWu9zCUofm6S+Yu/NlUfYr63c KXTK+WJM0F+mhw4TQ9QO7Pt9uWGWUnr3l92TX2v/1m9axCe/7tlENVfjgpsXdafIyP4rY89Z 3m5TfaWbvfrtDpHbmzemny9Y3xyumJ8RtCXcv06JpTgj0VCLuag4EQA3xE6/WQIAAA== Subject: [clue] Draft new version: draft-holmberg-clue-datachannel-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 10:44:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D16E7C5ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-03) of the CLUE data channel draft. The only changes from the previous versions are: - Reference update for the WebRTC data channel WebRTC data channel= establishment protocol drafts (note that the names have changed slightly). - Added the PPID value (51) to be used for CLUE messages. I do not intend to submit further "official" versions before London, but fe= el free to comment on the list :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D16E7C5ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version (-03) of the CLUE= data channel draft.

 

The only changes from the previous versions are:

 

-     &= nbsp;    Reference update for the WebRTC data channel WebRTC= data channel establishment protocol drafts (note that the names have chang= ed slightly).

-     &= nbsp;    Added the PPID value (51) to be used for CLUE messa= ges.

 

I do not intend to submit further “official= 221; versions before London, but feel free to comment on the list :)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D16E7C5ESESSMB209erics_-- From christer.holmberg@ericsson.com Wed Feb 12 03:03:12 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A71A0943 for ; Wed, 12 Feb 2014 03:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVfEM11lPczw for ; Wed, 12 Feb 2014 03:03:10 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 327941A093B for ; Wed, 12 Feb 2014 03:03:08 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-a6-52fb54ebd7f1 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 98.93.23809.BE45BF25; Wed, 12 Feb 2014 12:03:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 12:03:06 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: CLUE Data Channel: Things to think about for London Thread-Index: Ac8n32GdAD7a1LeIRTmD8ZSnjLDndg== Date: Wed, 12 Feb 2014 11:03:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16E850@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_7594FB04B1934943A5C02806D1A2204B1D16E850ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+Jvje7rkN9BBod+61nsP3WZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGRO3bGYueBhe8eX7GtYGxlU+XYycHBICJhIXD+1ihrDFJC7c W88GYgsJHGKUuH6zuouRC8hezCgxbeItoAQHB5uAhUT3P22QGhEBZYmjm/vB6oUFbCRO/vzK BBF3lPi19BhYuYiAnsTS6WIgYRYBVYmzS+azg4R5BXwlblwQAAkzAm39fmoNWCezgLjErSfz mSCuEZBYsuc81GWiEi8f/2MFaZUQUJRY3i8HUZ4v0X/hPyuIzSsgKHFy5hOWCYxCs5BMmoWk bBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkT03MTMnvdxoEyMw3A9u+a26g/HO OZFDjNIcLErivB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYIz5tvXYtncn1h60OKz8 97L6trI5mqf2rLu39nvIq+pjJ+9aMVaaPD1xg8smVanMUERG8yrzuRuSap8PykfvP7SzqXSB YJR1C1ttTXogv5O6T9aH6s1O7L9dD8YvP/nE9OoLRRuLNfo5ASKfYvdPyPw9RT7XebqUxsSX 9w/1TNh1Q/39046Zv3cqsRRnJBpqMRcVJwIAAF6+lEUCAAA= Subject: [clue] CLUE Data Channel: Things to think about for London X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 11:03:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D16E850ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, London is coming up, and there are some things I'd like us to focus on when= it comes to the CLUE data channel. First, as I have not seen any suggestions to do otherwise, for the moment I= am making the following working assumptions: - We will use the WebRTC data channel as base for the CLUE data ch= annel (how much we will eventually document in CLUE, or whether we can simp= ly reference the RTCWEB specs, is to be seen). - We will AT LEAST use the mechanism defined in the SCTP-SDP draft= to negotiate the SCTP/DTLS association used for the data channel. We can always change these assumptions later. But, if someone thinks we sho= uld not even make those working assumptions at this point: please speak up = now :) Now, what I would like to get consensus on (or, at least focus the discussi= ons on) in London, and what I therefor ask people to focus on for now, is: - Whether we are going to use the DCP. There has been good discuss= ions on the RTCWEB list, addressing many of the concerns that at least I ha= d raised; - IF we will use the DCP, what (if any) CLUE specific procedures d= o we need to specify in order to avoid glare (read: both endpoints establis= hing separate channels). - Whether we are going to use Richard's draft. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D16E850ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

London is coming up, and there are some things IR= 17;d like us to focus on when it comes to the CLUE data channel.=

 

First, as I have not seen any suggestions to do othe= rwise, for the moment I am making the following working assumptions:

 

-     &= nbsp;    We will use the WebRTC data channel as base for the= CLUE data channel (how much we will eventually document in CLUE, or whethe= r we can simply reference the RTCWEB specs, is to be seen).

-     &= nbsp;    We will AT LEAST use the mechanism defined in the S= CTP-SDP draft to negotiate the SCTP/DTLS association used for the data chan= nel.

 

We can always change these assumptions later. But, i= f someone thinks we should not even make those working assumptions at this = point: please speak up now J

 

 

Now, what I would like to get consensus on (or, at l= east focus the discussions on) in London, and what I therefor ask people to= focus on for now, is:

 

-     &= nbsp;    Whether we are going to use the DCP. There has been= good discussions on the RTCWEB list, addressing many of the concerns that = at least I had raised;

-     &= nbsp;    IF we will use the DCP, what (if any) CLUE specific= procedures do we need to specify in order to avoid glare (read: both endpo= ints establishing separate channels).

-     &= nbsp;    Whether we are going to use Richard’s draft. =

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D16E850ESESSMB209erics_-- From Mark.Duckworth@polycom.com Wed Feb 12 06:25:21 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC2B1A031B for ; Wed, 12 Feb 2014 06:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKSBqbZ2tQAr for ; Wed, 12 Feb 2014 06:25:16 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A0E641A02F4 for ; Wed, 12 Feb 2014 06:25:16 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Wed, 12 Feb 2014 06:25:15 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Wed, 12 Feb 2014 06:25:12 -0800 Thread-Topic: [clue] Changes in framework-14 Thread-Index: Ac8neXlap58Xh/A6S3SNQzsPAS8klQAhIScw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF8A7@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF3C7@CRPMBOXPRD07.polycom.com> <52F9F28A.802@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D3FF419@CRPMBOXPRD07.polycom.com> <52FAA57F.8010700@nteczone.com> In-Reply-To: <52FAA57F.8010700@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] Changes in framework-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 14:25:22 -0000 Hi Christian, I don't think the framework needs to have any more detail about specific id= entifiers for CSEs. It is covered in the data model. Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Tuesday, February 11, 2014 5:35 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] Changes in framework-14 >=20 > Hello Mark, >=20 > Please see below. >=20 > Regards, Christian >=20 > On 12/02/2014 12:29 AM, Duckworth, Mark wrote: > > inline > > Mark > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >> Groves > >> Sent: Tuesday, February 11, 2014 4:51 AM > >> To: clue@ietf.org > >> Subject: Re: [clue] Changes in framework-14 > >> > >> Hello Mark, > >> > >> I've just had a quick look and it looks pretty good. > >> > >> A nit in Table 19 and 20, CSEs don't have IDs. The CSEs should just > >> be CSE, CSE not CSE1 and CSE2. > > [Duckworth, Mark] I think it doesn't really matter if they have IDs or = not for > this example. But in fact they do have IDs. From the data model: > > 15.2. sceneEntryID attribute > > The sceneEntryID attribute is a mandatory attribute containing the > > identifier of the capture scene entry represented by the > > element. >=20 > >> In Table 22 I'm not sure why the MCCs for the audio don't reference > >> the source? Wouldn't they list AC1 to AC5? > > [Duckworth, Mark] They could, but they don't have to. I think the exam= ple > works either way. > [CNG] I think we need to clarify this in the framework. We first didn't n= eed to > provide an ID for CSEs. Then it seems we added the ability for CSEs to be > included in STSs. This then means that CSEs do need IDs. > There is text in the framework about Captures needing a Advertisement > unique Identity but there is no text regarding CSEs (and Scenes due to th= em > being added to STSs) needing unique identities. This would also mean that= all > the examples need to be updated to have unique CSE ids. > i.e. in section 7.1 key points are given for media Captures including > information about identity. We should do something similar for Scenes and > CSEs. >=20 >=20 >=20 > > > >> Regards, Christian > >> > >> On 11/02/2014 11:54 AM, Duckworth, Mark wrote: > >>> Hello, > >>> > >>> I implemented the changes we've been talking about. There are still > >>> a few open issues we can continue to discuss, I'll go over those at > >>> the design team meeting Feb 11. > >>> > >>> Please review the MCC example in section 12.3.3. I think it is okay > >>> now as a complete example, but we might want to add another > example, > >>> or change this one, pending results of the discussion "How to choose > >>> from multiple scenes". > >>> > >>> draft-ietf-clue-framework-14 has these changes: > >>> > >>> Changes from 13 to 14: > >>> > >>> 1. Fill in section for Security Considerations. > >>> > >>> 2. Replace Role placeholder with Participant Information, > >>> > >>> Participant Type, and Scene Information attributes. > >>> > >>> 3. Spatial information implies nothing about how constituent > >>> > >>> media captures are combined into a composed MCC. > >>> > >>> 4. Clean up MCC example in Section 12.3.3. Clarify behavior of > >>> > >>> tiled and PIP display windows. Add audio. Add new open > >>> > >>> issue about associating incoming packets to original source > >>> > >>> capture. > >>> > >>> 5. Remove editor's note and associated statement about RTP > >>> > >>> multiplexing at end of section 5. > >>> > >>> 6. Remove editor's note and associated paragraph about > >>> > >>> overloading media channel with both CLUE and non-CLUE usage, > >>> > >>> in section 5. > >>> > >>> 7. In section 10, clarify intent of media encodings conforming > >>> > >>> to SDP, even with multiple CLUE message exchanges. Remove > >>> > >>> associated editor's note. > >>> > >>> Regards, > >>> > >>> Mark > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 Raju.Makaraju@alcatel-lucent.com Wed Feb 12 11:33:40 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5411A0631 for ; Wed, 12 Feb 2014 11:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-rgw8EPckaG for ; Wed, 12 Feb 2014 11:33:36 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B24C11A062C for ; Wed, 12 Feb 2014 11:33:36 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1CJXWrs003407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 13:33:32 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s1CJXVLC030031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 14:33:32 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 12 Feb 2014 14:33:32 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , "clue@ietf.org" Thread-Topic: CLUE Data Channel: Things to think about for London Thread-Index: Ac8n32GdAD7a1LeIRTmD8ZSnjLDndgARm7Yw Date: Wed, 12 Feb 2014 19:33:31 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D16E850@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D16E850@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826DFDC8C1US70UWXCHMBA02z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [clue] CLUE Data Channel: Things to think about for London X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 19:33:40 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17826DFDC8C1US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, Now, what I would like to get consensus on (or, at least focus the discussi= ons on) in London, and what I therefor ask people to focus on for now, is: - Whether we are going to use the DCP. There has been good discuss= ions on the RTCWEB list, addressing many of the concerns that at least I ha= d raised; - IF we will use the DCP, what (if any) CLUE specific procedures d= o we need to specify in order to avoid glare (read: both endpoints establis= hing separate channels). - Whether we are going to use Richard's draft. [Raju] DCP allows user to send data over data channel immediately after "da= ta channel open" request is sent without waiting for "ack". Do we need such= capability for CLUE? Per my understanding we don't need it. Per "6. Examp= le: A call between two CLUE-capable endpoints" of http://www.ietf.org/id/dr= aft-kyzivat-clue-signaling-06.txt the CLUE control messages can only be sen= t after SDP offer/answer is complete. So, using DCP may actually cause issu= es wrt user trying to send CLU control msgs before SDP offer/answer is comp= leted. In fact, using external negotiation avoids one RTT delay (which happens aft= er SDP O/A is complete) associated to DCP and avoids "glare" situations. Also, SCTP/DTLS media info for CLUE is signalled via SDP O/A anyway along w= ith other audio, video media. So, using the same SDP O/A sequence for exter= nal negotiation makes sense and fits well within this framework. Therefore, I suggest using external data channel negotiation (Richard's dra= ft) for CLUE data channel. Btw, we will be adding more clear procedure to Richard's draft about when a= n application can use externally negotiated data channel. This will be in t= he draft that will be proposed to MMUSIC at London. -Raju --_000_E1FE4C082A89A246A11D7F32A95A17826DFDC8C1US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

Now, what I would like to get consensus on (or, at l= east focus the discussions on) in London, and what I therefor ask people to= focus on for now, is:

 

-     &= nbsp;    Whether we are going to use the DCP. There has been= good discussions on the RTCWEB list, addressing many of the concerns that = at least I had raised;

-     &= nbsp;    IF we will use the DCP, what (if any) CLUE specific= procedures do we need to specify in order to avoid glare (read: both endpo= ints establishing separate channels).

-     &= nbsp;    Whether we are going to use Richard’s draft. =

[Raju] DCP allows user to send data over data = channel immediately after “data channel open” request is sent w= ithout waiting for “ack”. Do we need such capability for CLUE? Per my understanding we don’t need it. Per “6. = Example: A call between two CLUE-capable endpoints” of http= ://www.ietf.org/id/draft-kyzivat-clue-signaling-06.txt the CLUE control= messages can only be sent after SDP offer/answer is complete. So, using DC= P may actually cause issues wrt user trying to send CLU control msgs before SDP offer/answer is completed.=

In fact, using externa= l negotiation avoids one RTT delay (which happens after SDP O/A is complete= ) associated to DCP and avoids “glare” situations.

 

Also, SCTP/DTLS media = info for CLUE is signalled via SDP O/A anyway along with other audio, video= media. So, using the same SDP O/A sequence for external negotiation makes = sense and fits well within this framework.

 

Therefore, I suggest u= sing external data channel negotiation (Richard’s draft) for CLUE dat= a channel.

Btw, we will be adding= more clear procedure to Richard’s draft about when an application ca= n use externally negotiated data channel. This will be in the draft that wi= ll be proposed to MMUSIC at London.

 

-Raju

 

--_000_E1FE4C082A89A246A11D7F32A95A17826DFDC8C1US70UWXCHMBA02z_-- From pkyzivat@alum.mit.edu Wed Feb 12 12:09:07 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EE51A0687 for ; Wed, 12 Feb 2014 12:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wg_XurMfQIq0 for ; Wed, 12 Feb 2014 12:09:05 -0800 (PST) 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 622761A0631 for ; Wed, 12 Feb 2014 12:09:05 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id RQLf1n0041swQuc5AY945t; Wed, 12 Feb 2014 20:09:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id RY941n0053ZTu2S3bY94Ak; Wed, 12 Feb 2014 20:09:04 +0000 Message-ID: <52FBD4E0.1020409@alum.mit.edu> Date: Wed, 12 Feb 2014 15:09:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D16E850@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392235744; bh=970A7yylpyT02QtCw27HWjnmSq8W6h2SGc8+VJtLoKk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oTLA2nH5J8T6DH43Lxe5PqDvpOJsX86+TlkT24KchWWndNLxFW1iX9yx/FzXZaTNc x+5fH/WiPe4UOWz/f3ezj8LJ3AqgZ1O4DOwJ2TGTrTMJi3EfVfYB2FIJpPMP6d/a89 FTq/cXrdTgk51ne7PiqjlssIqX9ehZpIsx7VTkYStBFmEmi/yMmc2d1QL4nSt/qmon jOvPV0FgX3OkvF2usEf0QzTRb7/voXBc38rbw3esAu8cP+dmt/9QWrHSqKt+b2WcZn JrkCodbHEwqhUdNk26VhYyOIKLemkpjcId0e3nJz7rJ+dEViyyZwa1sETijlWQ3Ouz EHerBg3SF7Vqw== Subject: Re: [clue] CLUE Data Channel: Things to think about for London X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 20:09:07 -0000 On 2/12/14 2:33 PM, Makaraju, Maridi Raju (Raju) wrote: > Hi Christer, > > Now, what I would like to get consensus on (or, at least focus the > discussions on) in London, and what I therefor ask people to focus on > for now, is: > > -Whether we are going to use the DCP. There has been good discussions on > the RTCWEB list, addressing many of the concerns that at least I had raised; > > -IF we will use the DCP, what (if any) CLUE specific procedures do we > need to specify in order to avoid glare (read: both endpoints > establishing separate channels). > > -Whether we are going to use Richard’s draft. > > */[Raju] /*DCP allows user to send data over data channel immediately > after “data channel open” request is sent without waiting for “ack”. Do > we need such capability for CLUE? Per my understanding we don’t need it. > Per “6. Example: A call between two CLUE-capable endpoints” of > http://www.ietf.org/id/draft-kyzivat-clue-signaling-06.txt the CLUE > control messages can only be sent after SDP offer/answer is complete. > So, using DCP may actually cause issues wrt user trying to send CLU > control msgs before SDP offer/answer is completed. I believe the O/A must be completed before it is possible to establish the DTLS foundation for the SCTP association. And you can't send data until that happens. (With webrtc, it think you may be able to request that the channel be opened and send data, but it will be buffered until the SCTP association is up.) > In fact, using external negotiation avoids one RTT delay (which happens > after SDP O/A is complete) associated to DCP and avoids “glare” situations. > > Also, SCTP/DTLS media info for CLUE is signalled via SDP O/A anyway > along with other audio, video media. So, using the same SDP O/A sequence > for external negotiation makes sense and fits well within this framework. Yes, it "fits". OTOH, it will be more complex for an RTCWEB client to deal with. DCP would be more natural for that. > Therefore, I suggest using external data channel negotiation (Richard’s > draft) for CLUE data channel. > Btw, we will be adding more clear procedure to Richard’s draft about > when an application can use externally negotiated data channel. This > will be in the draft that will be proposed to MMUSIC at London. Raju - I understand Richard has left A-L. I heard that Keith would be taking over the authoring of Richard's draft. Are you also involved with that? Thanks, Paul From pkyzivat@alum.mit.edu Wed Feb 12 12:17:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191AE1A0671 for ; Wed, 12 Feb 2014 12:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enQaZ2H88bQs for ; Wed, 12 Feb 2014 12:17:05 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4D53F1A06B2 for ; Wed, 12 Feb 2014 12:16:10 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id RWW31n0021ap0As51YG9lQ; Wed, 12 Feb 2014 20:16:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id RYG91n0043ZTu2S3iYG9aQ; Wed, 12 Feb 2014 20:16:09 +0000 Message-ID: <52FBD689.7080809@alum.mit.edu> Date: Wed, 12 Feb 2014 15:16:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D16E850@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D16E850@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392236169; bh=l0T6AJXiGj9yDhZ+JGRiReFAaYVqonZqo0FjPMhGcE4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nFKurXxa2PJpDFfDmGkX6yikLi+PvcO8SnnrC8WBh8jfy2YiTYhbMNGv6NQ66hMe7 dyeI/6IuBBUaswAEcApKSbBaIqol20/Yuc5Lg6KUHcEpW5CKXxU8EGbwETUwP2rXiq ciGKAa/BEf3rwGakzeaoDYWFW/hjgsEalHxIVs8zPosVhjoNIbmlUo6AmSJdyHPgxU hUuU8WvTXqFiZX2jAVkt2fu7rJrNLooavJ73SL9duOhQhnCejc49v68KESaOaJ9GT+ qFxh+K9oaya85u5aUjF58CiaU2HaMFnclbhr5T2RJIETKockZp/e0av8sKw4e10fCH OiA3gZmr2lXWQ== Subject: Re: [clue] CLUE Data Channel: Things to think about for London X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 20:17:06 -0000 On 2/12/14 6:03 AM, Christer Holmberg wrote: > Hi, > > London is coming up, and there are some things I’d like us to focus on > when it comes to the CLUE data channel. > > First, as I have not seen any suggestions to do otherwise, for the > moment I am making the following working assumptions: > > -We will use the WebRTC data channel as base for the CLUE data channel > (how much we will eventually document in CLUE, or whether we can simply > reference the RTCWEB specs, is to be seen). > > -We will AT LEAST use the mechanism defined in the SCTP-SDP draft to > negotiate the SCTP/DTLS association used for the data channel. > > We can always change these assumptions later. But, if someone thinks we > should not even make those working assumptions at this point: please > speak up now J > > Now, what I would like to get consensus on (or, at least focus the > discussions on) in London, and what I therefor ask people to focus on > for now, is: > > -Whether we are going to use the DCP. There has been good discussions on > the RTCWEB list, addressing many of the concerns that at least I had raised; > > -IF we will use the DCP, what (if any) CLUE specific procedures do we > need to specify in order to avoid glare (read: both endpoints > establishing separate channels). You already had a suggestion for how to handle that over on the rtcweb list. Another possibility - Once again consider using two channels. E.g., Each endpoint that wants to be an advertiser opens a channel and then sends the first advertisement. The other end (as consumer) sends Configure on this channel. Assuming both ends want to be advertisers we end up with two channels. If one end doesn't want to be an advertiser it just doesn't open a channel. If the consumer doesn't want to configure anything, it immediately closes the channel the other end opened. This has a certain elegant simplicity to it. Thanks, Paul From pkyzivat@alum.mit.edu Wed Feb 12 13:29:24 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A721A06ED for ; Wed, 12 Feb 2014 13:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e86GllEZ1hYl for ; Wed, 12 Feb 2014 13:29:22 -0800 (PST) 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 F2E3A1A06E5 for ; Wed, 12 Feb 2014 13:29:21 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id RY9Z1n0031ei1Bg57ZVMsS; Wed, 12 Feb 2014 21:29:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id RZVL1n00U3ZTu2S3kZVLF9; Wed, 12 Feb 2014 21:29:21 +0000 Message-ID: <52FBE7B0.2090301@alum.mit.edu> Date: Wed, 12 Feb 2014 16:29:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> <52F177D1.5090700@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=1392240561; bh=7N13ZWiDEIFd82ziuym+nOZZaXzYlHBCWkL5YZBDIQU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VHu6L5tVlmHsZFhuWu6yeXUW67dKtf9rWANx6bYVLAFZNZUT+EZI7RsDaoVOFOE89 8qXO9cggZt3A88bspiUSGdZJI7KZAaGlb7nLYYPD3IT4RHphzzT5v+c6f5z4okj2Xz UMqmgh8xjltAX7fZv7XDwshPDMBJu4kx0A1jL03Pgo8XMqzxRPsoxvgHYJH49gFZ0p RgniGBReberkYaearvlc5NSmKU4a4h1h1g3D9y4qzLi1G8ymE/NctsVt3c80l7lRiT MY3ciUoScy7rb2Zlqe7Hvko+X5w4t0+kMvX8H+1j9zevnS2caqhaOQTK27KstRNwQP I/GVhb7bAe3Kw== Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 21:29:24 -0000 Hi Scarlett, (welcome back from your holiday) On 2/11/14 10:53 PM, Liuyan (Scarlett) wrote: > Hello Christian, Paul and Christer, > > Although, the rtcweb data channel draft does NOT say identical stream ID values in both directions. > > The rtcweb data protocol draft does says it as below: > > 3. Terminology > > This document uses the following terms: > > Association: An SCTP association. > > Stream: A unidirectional stream of an SCTP association. It is > uniquely identified by an SCTP stream identifier (0-65534). Note: > the SCTP stream identifier 65535 is reserved due to SCTP INIT and > INIT-ACK chunks only allowing a maximum of 65535 streams to be > negotiated (0-65534). > > Channel: Two Streams with the same SCTP stream identifier, one in > each direction, which are managed together. Yes, we did find that the *protocol* document does specify this. (Also in section 6.) But that is only when the data channel protocol is used - not when channels are used without the data channel protocol. > In addition, I have a question to ask for you as below. > > > Best Regards, > Scarlett > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Wednesday, February 05, 2014 7:29 AM > To: clue@ietf.org > Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? > > Hello, > On 5/02/2014 1:18 AM, Christer Holmberg wrote: >> Hi, >> >>>> Paul earlier suggested that we, for the SCTP streams that form the >>>> CLUE Data Channel, shall mandate the usage of identical stream ID >>>> values in each direction. >>>> >>>> Perhaps I missed it, but what was the reason for that? To use the >>>> stream ID in order know on which stream CLUE messages are received? >>>> >>>> I do agree that we need a way to know on which stream CLUE messages >>>> are received, and we can for sure recommend using the same values, >>>> but until we know what will be negotiated in SDP I'd like to keep >>>> the MUST as an open issue. >>>> >>>> Also, the rtcweb data channel draft says: >>>> >>>> "Note that there's no requirement for the SCTP streams used to >>>> create >>>> >>>> a bidirectional channel have the same number in >>>> each direction. How >>>> >>>> stream values are selected is protocol and >>>> implementation dependent." >>> I was thinking they had to match in rtcweb. If they *don't* have to match, then how are they correlated? >> As we discussed before, at the moment it seems like they assume a single usage per association. >> >> ...which is perhaps the only thing rtcweb requires, but the mechanism have to be general. >> >>> I just looked, and found the text you quote. I *guess* if the negotiation is done externally they can just wave their hands like this. >>> But for channels opened using the rtcweb data channel protocol I don't see how they can avoid specifying how the correlation is done. But I looked there too, and they don't seem to say. I think it is a hole in their spec. >> Yes - among the others :) > [CNG] I agree. I've been looking at this also in terms of gateway support for SCTP and CLUE, BFCP, T.38 etc. The differences between the SCTP SDP draft and RTCWEB transport ones and holes with regards to STCP channel -> protocol assignment makes it hard to specify any generic behaviour. > [Scarlett] If there are more than one usage per association, the usages can be identified by different PPID. I am not sure about the discussion as above. > Regards, Christian PPID is used for a different purpose. (It is used to distinguish OPEN and ACK messages from data messages, and to indicate the encoding of data messages.) And we need to follow rtcweb on that to maintain compatibility. Thanks, Paul From Raju.Makaraju@alcatel-lucent.com Wed Feb 12 13:36:19 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4815F1A0002 for ; Wed, 12 Feb 2014 13:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj76OVTWkQc5 for ; Wed, 12 Feb 2014 13:36:16 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B396A1A0005 for ; Wed, 12 Feb 2014 13:36:16 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1CLaEhX002982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2014 15:36:14 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s1CLaDih000948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 16:36:14 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 12 Feb 2014 16:36:13 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: Things to think about for London Thread-Index: Ac8n32GdAD7a1LeIRTmD8ZSnjLDndgARm7YwAAyX0QAAB9kGIA== Date: Wed, 12 Feb 2014 21:36:13 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D16E850@ESESSMB209.ericsson.se> <52FBD4E0.1020409@alum.mit.edu> In-Reply-To: <52FBD4E0.1020409@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] 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 Subject: Re: [clue] CLUE Data Channel: Things to think about for London X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 21:36:19 -0000 Hi Paul, >I believe the O/A must be completed before it is possible to establish=20 >the DTLS foundation for the SCTP association. And you can't send data=20 >until that happens. (With webrtc, it think you may be able to request=20 >that the channel be opened and send data, but it will be buffered until=20 >the SCTP association is up.) [Raju] Yes. But that's the case with initial SDP offer/answer. But a=20 sub-sequent offer/answer can use an already established SCTP/DTLS=20 association to open a new data channel even before the offer/answer=20 completes. With external negotiation, to send data, the offerer has to wait= =20 until answer arrives; while answerer can send data soon after sending SDP answer. That means, the offerer should be prepared to receive data before SDP answer arrives (early media). > > In fact, using external negotiation avoids one RTT delay (which happens > > after SDP O/A is complete) associated to DCP and avoids "glare" > situations. > > > > Also, SCTP/DTLS media info for CLUE is signalled via SDP O/A anyway > > along with other audio, video media. So, using the same SDP O/A sequenc= e > > for external negotiation makes sense and fits well within this framewor= k. >=20 > Yes, it "fits". >=20 > OTOH, it will be more complex for an RTCWEB client to deal with. > DCP would be more natural for that. [Raju] Agree. =20 > Raju - I understand Richard has left A-L. I heard that Keith would be > taking over the authoring of Richard's draft. Are you also involved with > that? [Raju] Yes. Keith and I will be taking over. Keith will be present at the L= ondon's meeting. Thanks raju From scarlett.liuyan@huawei.com Wed Feb 12 19:49:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317C51A00D4 for ; Wed, 12 Feb 2014 19:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BdjE_FCfR6L for ; Wed, 12 Feb 2014 19:49:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 328291A00D3 for ; Wed, 12 Feb 2014 19:49:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDN59075; Thu, 13 Feb 2014 03:49:53 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 03:49:36 +0000 Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 03:49:51 +0000 Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.104]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 11:49:41 +0800 From: "Liuyan (Scarlett)" To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: Identical stream ID values in both directions? Thread-Index: AQHPIbVP3ZnGtuZ6YkmTiKnVfw/W5pqknpCAgACZxYCAC8t58IAApaYAgADmfkA= Date: Thu, 13 Feb 2014 03:49:40 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> <52F177D1.5090700@nteczone.com> <52FBE7B0.2090301@alum.mit.edu> In-Reply-To: <52FBE7B0.2090301@alum.mit.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.137.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Lijing \(Jessie\)" Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 03:49:59 -0000 Hello Paul, Thanks. :-) I have a different understanding about PPID, and please check my reply = at the bottom of this e-mail. Best Regards, Scarlett -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, February 13, 2014 5:29 AM To: clue@ietf.org Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both d= irections? Hi Scarlett, (welcome back from your holiday) On 2/11/14 10:53 PM, Liuyan (Scarlett) wrote: > Hello Christian, Paul and Christer, > > Although, the rtcweb data channel draft does NOT say identical strea= m ID values in both directions. > > The rtcweb data protocol draft does says it as below: > > 3. Terminology > > This document uses the following terms: > > Association: An SCTP association. > > Stream: A unidirectional stream of an SCTP association. It = is > uniquely identified by an SCTP stream identifier (0-6= 5534). Note: > the SCTP stream identifier 65535 is reserved due to S= CTP INIT and > INIT-ACK chunks only allowing a maximum of 65535 stre= ams to be > negotiated (0-65534). > > Channel: Two Streams with the same SCTP stream identifier, o= ne in > each direction, which are managed together. Yes, we did find that the *protocol* document does specify this. (Also in s= ection 6.) But that is only when the data channel protocol is used - not when channels= are used without the data channel protocol. > In addition, I have a question to ask for you as below. > > > Best Regards, > Scarlett > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Wednesday, February 05, 2014 7:29 AM > To: clue@ietf.org > Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both= directions? > > Hello, > On 5/02/2014 1:18 AM, Christer Holmberg wrote: >> Hi, >> >>>> Paul earlier suggested that we, for the SCTP streams that form the >>>> CLUE Data Channel, shall mandate the usage of identical stream ID >>>> values in each direction. >>>> >>>> Perhaps I missed it, but what was the reason for that? To use the >>>> stream ID in order know on which stream CLUE messages are received? >>>> >>>> I do agree that we need a way to know on which stream CLUE messages >>>> are received, and we can for sure recommend using the same values, >>>> but until we know what will be negotiated in SDP I'd like to keep >>>> the MUST as an open issue. >>>> >>>> Also, the rtcweb data channel draft says: >>>> >>>> "Note that there's no requirement for the SCTP streams used to >>>> create >>>> >>>> a bidirectional channel have the same number in >>>> each direction. How >>>> >>>> stream values are selected is protocol and >>>> implementation dependent." >>> I was thinking they had to match in rtcweb. If they *don't* have to mat= ch, then how are they correlated? >> As we discussed before, at the moment it seems like they assume a single= usage per association. >> >> ...which is perhaps the only thing rtcweb requires, but the mechanism ha= ve to be general. >> >>> I just looked, and found the text you quote. I *guess* if the negotiati= on is done externally they can just wave their hands like this. >>> But for channels opened using the rtcweb data channel protocol I don't = see how they can avoid specifying how the correlation is done. But I looked= there too, and they don't seem to say. I think it is a hole in their spec. >> Yes - among the others :) > [CNG] I agree. I've been looking at this also in terms of gateway support= for SCTP and CLUE, BFCP, T.38 etc. The differences between the SCTP SDP dr= aft and RTCWEB transport ones and holes with regards to STCP channel -> pro= tocol assignment makes it hard to specify any generic behaviour. > [Scarlett] If there are more than one usage per association, the usages c= an be identified by different PPID. I am not sure about the discussion as a= bove. > Regards, Christian PPID is used for a different purpose. (It is used to distinguish OPEN=20 and ACK messages from data messages, and to indicate the encoding of=20 data messages.) And we need to follow rtcweb on that to maintain=20 compatibility. [Scarlett] I see the PPID's usage in section 5 of draft data-channel as bel= ow: Each SCTP user message contains a so called Payload Protocol Identifier (PPID) that is passed to SCTP by its upper layer a= nd sent to its peer. This value can be used to multiplex multiple pr= otocols over a single SCTP association. The sender provides for each protocol a specific PPID and the receiver can demultiplex the messages based on the received PPID. =20 I think that the PPID of OPEN messages is the same as the PPID of ACK m= essages as described in data-protocol. This draft data-protocol says in section 8.1 as below: | Value | SCTP PPID | Reference | +-------------+-----------+-----------+ | WebRTC DCEP | 50 | [RFCXXXX] | +-------------+-----------+-----------+ And it says in section 8.2 as below: +-------------------+-----------+-----------+ | Name | Type | Reference | +-------------------+-----------+-----------+ | Reserved | 0x00 | [RFCXXXX] | | Reserved | 0x01 | [RFCXXXX] | | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | | Unassigned | 0x04-0xfe | | | Reserved | 0xff | [RFCXXXX] | +-------------------+-----------+-----------+ So, if a data channel for CLUE and another data channel for WebRTC are s= imultaneously used per association, they PPIDs is different.=20 Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Thu Feb 13 00:13:33 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB111A0170 for ; Thu, 13 Feb 2014 00:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0qfYnEGmAgC for ; Thu, 13 Feb 2014 00:13:30 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3B75A1A0169 for ; Thu, 13 Feb 2014 00:13:30 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-3e-52fc7ea82146 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 5C.A4.04249.8AE7CF25; Thu, 13 Feb 2014 09:13:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 09:13:27 +0100 From: Christer Holmberg To: "Liuyan (Scarlett)" , Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: Identical stream ID values in both directions? Thread-Index: Ac8hnlNVKx/zx1mwSsaGQD1SBC5QUgADHU6AAAIuGcAAEULkgAFpRIEAACTfSgAADUhyAAALEh8A Date: Thu, 13 Feb 2014 08:13:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16FFAE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> <52F177D1.5090700@nteczone.com> <52FBE7B0.2090301@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvje6Kuj9BBnd+SlnsP3WZ2WJ581JG ixUbDrBaHHzRwuTA4vH3/Qcmj5Yjb1k9liz5yRTAHMVlk5Kak1mWWqRvl8CVMWPeXcaCe7IV i9dNZW1gbBbpYuTkkBAwkfjbdo8JwhaTuHBvPVsXIxeHkMARRom1Dd+YIZzFjBJz/28HynBw sAlYSHT/0wZpEBGolVh9rAusmVlAW2LZoUY2EFtYIFyi4f48VoiaCImfTfuh7CiJ8z/aGEFs FgFViQtXf7GD2LwCvhITPjxgh9jVzyxx4dhfsEGcAmESF28vAmtmBLru+6k1UMvEJW49mQ91 tYDEkj3nmSFsUYmXj/+xgtwpIaAkMW1rGkS5jsSC3Z/Y4O5c+JoZYq+gxMmZT1gmMIrNQjJ1 FpKWWUhaZiFpWcDIsoqRozi1OCk33chgEyMwhg5u+W2xg/HyX5tDjNIcLErivB/fOgcJCaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYFx0rs3s1955715MlKu+/YIz1YFzU1pnbr7K4U8nLM8s NLy76oaQUXGPcIXbhG4efqmNzxZHeEwTOb/JImxdI7eVms0LFq4jl6LnvuyLXxlZsCPh0uo6 Bf33822vaMhvl9unkccRcVz9BquWf8vhgl8JiuHrDx4sr5F+dP/nuTslztNCCn1CfJVYijMS DbWYi4oTASeKSMVvAgAA Cc: "Lijing \(Jessie\)" Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 08:13:33 -0000 Hi, >> Although, the rtcweb data channel draft does NOT say identical stre= am ID values in both directions. >> >> The rtcweb data protocol draft does says it as below: >> >> 3. Terminology >> >> This document uses the following terms: >> >> Association: An SCTP association. >> >> Stream: A unidirectional stream of an SCTP association. It= is >> uniquely identified by an SCTP stream identifier (0-= 65534). Note: >> the SCTP stream identifier 65535 is reserved due to = SCTP INIT and >> INIT-ACK chunks only allowing a maximum of 65535 str= eams to be >> negotiated (0-65534). >> >> Channel: Two Streams with the same SCTP stream identifier, = one in >> each direction, which are managed together. > > Yes, we did find that the *protocol* document does specify this. (Also in= section 6.) > > But that is only when the data channel protocol is used - not when channe= ls are used without the data channel protocol. The definition of the data channel is in section 6.4 of draft-ietf-rtcweb-d= ata-channel-07: "The realization of a bidirectional Data Channel is a pair of one incoming stream and one outgoing SCTP stream having the same stream SCTP identifier." I.e. it is not dependent on whether you use DCP or not. .... >> PPID is used for a different purpose. (It is used to distinguish OPEN an= d ACK messages from data messages, and to >> indicate the encoding of data messages.) And we need to follow rtcweb on= that to maintain compatibility. >> > [Scarlett] I see the PPID's usage in section 5 of draft data-channel as b= elow: > Each SCTP user message contains a so called Payload Protocol > Identifier (PPID) that is passed to SCTP by its upper layer = and sent > to its peer. This value can be used to multiplex multiple p= rotocols > over a single SCTP association. The sender provides for eac= h > protocol a specific PPID and the receiver can demultiplex th= e > messages based on the received PPID. =20 > I think that the PPID of OPEN messages is the same as the PPID of ACK = messages as described in data-protocol. > This draft data-protocol says in section 8.1 as below: > | Value | SCTP PPID | Reference | > +-------------+-----------+-----------+ > | WebRTC DCEP | 50 | [RFCXXXX] | > +-------------+-----------+-----------+ > And it says in section 8.2 as below: > +-------------------+-----------+-----------+ > | Name | Type | Reference | > +-------------------+-----------+-----------+ > | Reserved | 0x00 | [RFCXXXX] | > | Reserved | 0x01 | [RFCXXXX] | > | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | > | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | > | Unassigned | 0x04-0xfe | | > | Reserved | 0xff | [RFCXXXX] | > +-------------------+-----------+-----------+ > So, if a data channel for CLUE and another data channel for WebRTC are = simultaneously used per association, they PPIDs is different.=20 That is not true - at least not if we want to be compatible with the WebRTC= data channel. In such case the PPIDs will be the same, and another mechani= sm (e.g. DCP or Richard's draft) is needed to indicate what application pro= tocol (e.g. CLUE) the data channel is used for. Regards, Christer From scarlett.liuyan@huawei.com Thu Feb 13 03:06:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C733E1A01E5 for ; Thu, 13 Feb 2014 03:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGEl-0L0CzrM for ; Thu, 13 Feb 2014 03:06:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 232F71A01E4 for ; Thu, 13 Feb 2014 03:06:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBB76108; Thu, 13 Feb 2014 11:06:43 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 11:05:41 +0000 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 11:06:42 +0000 Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.104]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 19:06:31 +0800 From: "Liuyan (Scarlett)" To: Christer Holmberg , Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: Identical stream ID values in both directions? Thread-Index: AQHPIbVP3ZnGtuZ6YkmTiKnVfw/W5pqknpCAgACZxYCAC8t58IAApaYAgADmfkD//814gIAAsvJQ Date: Thu, 13 Feb 2014 11:06:30 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> <52F177D1.5090700@nteczone.com> <52FBE7B0.2090301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D16FFAE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D16FFAE@ESESSMB209.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.137.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Lijing \(Jessie\)" Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 11:06:51 -0000 Hello Christer, I still have a question, and please see as below. Thanks. Best Regards, Scarlett=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, February 13, 2014 4:13 PM To: Liuyan (Scarlett); Paul Kyzivat; clue@ietf.org Cc: Lijing (Jessie) Subject: RE: [clue] CLUE Data Channel: Identical stream ID values in both d= irections? Hi, >> Although, the rtcweb data channel draft does NOT say identical stre= am ID values in both directions. >> >> The rtcweb data protocol draft does says it as below: >> >> 3. Terminology >> >> This document uses the following terms: >> >> Association: An SCTP association. >> >> Stream: A unidirectional stream of an SCTP association. It= is >> uniquely identified by an SCTP stream identifier (0-= 65534). Note: >> the SCTP stream identifier 65535 is reserved due to = SCTP INIT and >> INIT-ACK chunks only allowing a maximum of 65535 str= eams to be >> negotiated (0-65534). >> >> Channel: Two Streams with the same SCTP stream identifier, = one in >> each direction, which are managed together. > > Yes, we did find that the *protocol* document does specify this. (Also=20 > in section 6.) > > But that is only when the data channel protocol is used - not when channe= ls are used without the data channel protocol. The definition of the data channel is in section 6.4 of draft-ietf-rtcweb-d= ata-channel-07: "The realization of a bidirectional Data Channel is a pair of one incoming stream and one outgoing SCTP stream having the same stream SCTP identifier." I.e. it is not dependent on whether you use DCP or not. [Scarlett] Yes, I also find it in data-channel draft. :-) .... >> PPID is used for a different purpose. (It is used to distinguish OPEN=20 >> and ACK messages from data messages, and to indicate the encoding of dat= a messages.) And we need to follow rtcweb on that to maintain compatibility= . >> > [Scarlett] I see the PPID's usage in section 5 of draft data-channel as b= elow: > Each SCTP user message contains a so called Payload Protocol > Identifier (PPID) that is passed to SCTP by its upper layer = and sent > to its peer. This value can be used to multiplex multiple p= rotocols > over a single SCTP association. The sender provides for eac= h > protocol a specific PPID and the receiver can demultiplex th= e > messages based on the received PPID. =20 > I think that the PPID of OPEN messages is the same as the PPID of ACK = messages as described in data-protocol. > This draft data-protocol says in section 8.1 as below: > | Value | SCTP PPID | Reference | > +-------------+-----------+-----------+ > | WebRTC DCEP | 50 | [RFCXXXX] | > +-------------+-----------+-----------+ > And it says in section 8.2 as below: > +-------------------+-----------+-----------+ > | Name | Type | Reference | > +-------------------+-----------+-----------+ > | Reserved | 0x00 | [RFCXXXX] | > | Reserved | 0x01 | [RFCXXXX] | > | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | > | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | > | Unassigned | 0x04-0xfe | | > | Reserved | 0xff | [RFCXXXX] | > +-------------------+-----------+-----------+ > So, if a data channel for CLUE and another data channel for WebRTC are = simultaneously used per association, they PPIDs is different.=20 That is not true - at least not if we want to be compatible with the WebRTC= data channel. In such case the PPIDs will be the same, and another mechani= sm (e.g. DCP or Richard's draft) is needed to indicate what application pro= tocol (e.g. CLUE) the data channel is used for. [Scarlett] You said " In such case the PPIDs will be the same ". I am confu= sed what cases you said. If CLUE is compatible with the WebRTC data channel, WebRTC client using CLU= E protocol uses the same data channel for WebRTC and CLUE ??=20 Regards, Christer From christer.holmberg@ericsson.com Thu Feb 13 03:39:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D851A01F2 for ; Thu, 13 Feb 2014 03:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0wnm8xssbwv for ; Thu, 13 Feb 2014 03:39:00 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFFC1A01FC for ; Thu, 13 Feb 2014 03:39:00 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-33-52fcaed2170a Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A0.2E.10875.2DEACF25; Thu, 13 Feb 2014 12:38:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 12:38:58 +0100 From: Christer Holmberg To: "Liuyan (Scarlett)" , Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: Identical stream ID values in both directions? Thread-Index: Ac8hnlNVKx/zx1mwSsaGQD1SBC5QUgADHU6AAAIuGcAAEULkgAFpRIEAACTfSgAADUhyAAALEh8AAAQveQAAAwhh4A== Date: Thu, 13 Feb 2014 11:38:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1706C3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> <52F177D1.5090700@nteczone.com> <52FBE7B0.2090301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D16FFAE@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvje6ldX+CDP5s17fYf+oys8Xy5qWM Fis2HGC1OPiihcmBxePv+w9MHi1H3rJ6LFnykymAOYrLJiU1J7MstUjfLoEr49vnhIKtohXL 1u9maWC8wdfFyMkhIWAicbThLhOELSZx4d56NhBbSOAQo8TszuouRi4gezGjxJ2zh4ASHBxs AhYS3f+0QWpEBGolVh/rAutlFtCWWHaoEaxXWCBcouH+PFaImgiJn037oewsiU/NJ5lBbBYB VYnNW5rB4rwCvhJrG5+zQeyazyJxeM86sEGcAmESt7d0MYLYjEDHfT+1BmqZuMStJ/OhjhaQ WLLnPDOELSrx8vE/VpA7JQSUJKZtTYMo15FYsPsTG9ydC18zQ+wVlDg58wnLBEaxWUimzkLS MgtJyywkLQsYWVYxsucmZuaklxtuYgRGz8Etv3V3MJ46J3KIUZqDRUmc98Nb5yAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjG0X5yzT3O71MPSYy6WFSY3/1yxIjBdynLRh6TrfyiVHF1Wd jEuaJ/7qfGrM0urj3v/mGeyNWXEm5HzCmjeGx5bPZ3r68uPjbbsLpT3VX028Yfj+jmf7n9SV Vjp870Sn2rXuPyjX8JOpjWX+9g1t3Qn7jTqf5uq7Khudsfs9a9ohIfOfJknFVgVKLMUZiYZa zEXFiQAKViDnbAIAAA== Cc: "Lijing \(Jessie\)" Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 11:39:06 -0000 Hi Scarlett, >>>> PPID is used for a different purpose. (It is used to distinguish OPEN= =20 >>>> and ACK messages from data messages, and to indicate the encoding of d= ata messages.) And we need to follow rtcweb on that to maintain compatibili= ty. >>>> >>> [Scarlett] I see the PPID's usage in section 5 of draft data-channel as= below: >>> Each SCTP user message contains a so called Payload Protoc= ol >>> Identifier (PPID) that is passed to SCTP by its upper laye= r and sent >>> to its peer. This value can be used to multiplex multiple= protocols >>> over a single SCTP association. The sender provides for e= ach >>> protocol a specific PPID and the receiver can demultiplex = the >>> messages based on the received PPID. =20 >>> I think that the PPID of OPEN messages is the same as the PPID of AC= K messages as described in data-protocol. >>> This draft data-protocol says in section 8.1 as below: >>> | Value | SCTP PPID | Reference | >>> +-------------+-----------+-----------+ >>> | WebRTC DCEP | 50 | [RFCXXXX] | >>> +-------------+-----------+-----------+ >>> And it says in section 8.2 as below: >>> +-------------------+-----------+-----------+ >>> | Name | Type | Reference | >>> +-------------------+-----------+-----------+ >>> | Reserved | 0x00 | [RFCXXXX] | >>> | Reserved | 0x01 | [RFCXXXX] | >>> | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | >>> | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | >>> | Unassigned | 0x04-0xfe | | >>> | Reserved | 0xff | [RFCXXXX] | >>> +-------------------+-----------+-----------+ >>> So, if a data channel for CLUE and another data channel for WebRTC ar= e simultaneously used per association, they PPIDs is different.=20 >>> >> That is not true - at least not if we want to be compatible with the Web= RTC data channel. In such case the PPIDs will be the=20 >> same, and another mechanism (e.g. DCP or Richard's draft) is needed to i= ndicate what application protocol (e.g. CLUE) the data channel is used for. > [Scarlett] You said " In such case the PPIDs will be the same ". I am con= fused what cases you said. > If CLUE is compatible with the WebRTC data channel, WebRTC client using C= LUE protocol uses the same data channel for WebRTC and CLUE ??=20 Yes. A browser only understands WebRTC data channels. Regards, Christer From nobody Thu Feb 13 10:15:21 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2683A1A03B8 for ; Thu, 13 Feb 2014 10:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR7OYsqxA355 for ; Thu, 13 Feb 2014 10:15:17 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 576EE1A01A8 for ; Thu, 13 Feb 2014 10:15:17 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id RoR91n0011ap0As5CuFGqu; Thu, 13 Feb 2014 18:15:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id RuFD1n00l3ZTu2S3iuFFQC; Thu, 13 Feb 2014 18:15:16 +0000 Message-ID: <52FD0BB1.4020206@alum.mit.edu> Date: Thu, 13 Feb 2014 13:15:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "Liuyan (Scarlett)" , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> <52F177D1.5090700@nteczone.com> <52FBE7B0.2090301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D16FFAE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1706C3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1706C3@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=1392315316; bh=5qS/1D/D5BhAiUzQNW3WXqMVkXNs3nZZqlYiWqr5+gc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dwGAwnH2Od+9hSRgnR3H9woHIIghkBDwsgJxgFzSe7iIvMs+26uU85Tu8WCmdOlSB 4oKB0hMxLN8zFaJFYbZIQcHMu7gEL3idMkkOrQ19HaaAoMDw6eZG3x8rAKCbfIbGAm u7z2Y70Ay6XRFSpq2L9ekWBMMC8jnVgBRQ3tS86Gifo6L4CxmetHg71VF/Hk3rjcmo T3dIvMXplQ2Usca0nLkV0VdTssd/9vvVfpBglimnBfiVDDwhprq1TB2HTo9TINPuBs F5t+D5wu5BBNnXnwJqCd93L63RfI3/2YLLt1pENB8uMXa+0pYLtBq3iemAWQvjdXOM kk1vibk9cexoA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5x0ih-j8U0xWkyrYBT5DuqgfYYs Cc: "Lijing \(Jessie\)" Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 18:15:19 -0000 Scarlett, To elaborate on what Christer said: WebRTC is defining a way for browsers to do real-time communication. It isn't an application, it is a platform for applications. The key is that a this allows browser applications to do so without plugins like Flash. We have a few possible situations for clue and data channels: 1) two native sip clue endpoints. They use the data channel, but no browser is involved. 2) one native sip clue endpoint talking to an a clue endpoint implemented in a browser using WebRTC. They have a data channel between them. For use by the browser it must meet all the requirements of a WebRTC Data Channel. And it also must meet all the requirements of a CLUE channel. 3) two browsers talking to each other using CLUE over WebRTC. With WebRTC, there are only a few PPIDs that can be used. They are being used to distinguish DCP messages from user messages, and to distinguish the encoding of data messages as strings or binary. If we were to use a different PPID for CLUE then a browser app wouldn't be able to deal with it. Thanks, Paul On 2/13/14 6:38 AM, Christer Holmberg wrote: > Hi Scarlett, > >>>>> PPID is used for a different purpose. (It is used to distinguish OPEN >>>>> and ACK messages from data messages, and to indicate the encoding of data messages.) And we need to follow rtcweb on that to maintain compatibility. >>>>> >>>> [Scarlett] I see the PPID's usage in section 5 of draft data-channel as below: >>>> Each SCTP user message contains a so called Payload Protocol >>>> Identifier (PPID) that is passed to SCTP by its upper layer and sent >>>> to its peer. This value can be used to multiplex multiple protocols >>>> over a single SCTP association. The sender provides for each >>>> protocol a specific PPID and the receiver can demultiplex the >>>> messages based on the received PPID. >>>> I think that the PPID of OPEN messages is the same as the PPID of ACK messages as described in data-protocol. >>>> This draft data-protocol says in section 8.1 as below: >>>> | Value | SCTP PPID | Reference | >>>> +-------------+-----------+-----------+ >>>> | WebRTC DCEP | 50 | [RFCXXXX] | >>>> +-------------+-----------+-----------+ >>>> And it says in section 8.2 as below: >>>> +-------------------+-----------+-----------+ >>>> | Name | Type | Reference | >>>> +-------------------+-----------+-----------+ >>>> | Reserved | 0x00 | [RFCXXXX] | >>>> | Reserved | 0x01 | [RFCXXXX] | >>>> | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | >>>> | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | >>>> | Unassigned | 0x04-0xfe | | >>>> | Reserved | 0xff | [RFCXXXX] | >>>> +-------------------+-----------+-----------+ >>>> So, if a data channel for CLUE and another data channel for WebRTC are simultaneously used per association, they PPIDs is different. >>>> >>> That is not true - at least not if we want to be compatible with the WebRTC data channel. In such case the PPIDs will be the >>> same, and another mechanism (e.g. DCP or Richard's draft) is needed to indicate what application protocol (e.g. CLUE) the data channel is used for. >> [Scarlett] You said " In such case the PPIDs will be the same ". I am confused what cases you said. >> If CLUE is compatible with the WebRTC data channel, WebRTC client using CLUE protocol uses the same data channel for WebRTC and CLUE ?? > > Yes. A browser only understands WebRTC data channels. > > Regards, > > Christer > > From nobody Thu Feb 13 11:17:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E90B1A03C3 for ; Thu, 13 Feb 2014 11:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9mTmAsK5v3q for ; Thu, 13 Feb 2014 11:17:46 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EBA741A0350 for ; Thu, 13 Feb 2014 11:17:45 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-42-52fd1a578826 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1E.23.10875.75A1DF25; Thu, 13 Feb 2014 20:17:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 20:17:43 +0100 From: Christer Holmberg To: Paul Kyzivat , "Liuyan (Scarlett)" , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: Identical stream ID values in both directions? Thread-Index: Ac8hnlNVKx/zx1mwSsaGQD1SBC5QUgADHU6AAAIuGcAAEULkgAFpRIEAACTfSgAADUhyAAALEh8AAAQveQAAAwhh4AAL8KaAAARFkOA= Date: Thu, 13 Feb 2014 19:17:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1713A8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> <52F177D1.5090700@nteczone.com> <52FBE7B0.2090301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D16FFAE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1706C3@ESESSMB209.ericsson.se> <52FD0BB1.4020206@alum.mit.edu> In-Reply-To: <52FD0BB1.4020206@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+JvjW6E1N8gg4blzBb7T11mtljevJTR YsWGA6wWB1+0MDmwePx9/4HJo+XIW1aPJUt+MgUwR3HZpKTmZJalFunbJXBlvLjxn72gSali +YEVLA2M5yW6GDk5JARMJNbtnckGYYtJXLi3Hsjm4hASOMQoceRTH5SzmFHixvLpLF2MHBxs AhYS3f+0QRpEBGoldp3YDdbMLKAtsexQI5gtLBAucXLLKVaImgiJn037oewyidNffoCNYRFQ ldh8nRfE5BXwlTj6QR5iUyurxImbTUwg5ZwCOhKvp+0DG8kIdNv3U2uYIFaJS3w4eJ0Z4mYB iSV7zkPZohIvH/9jhbCVJBqXPGGFqNeTuDF1CsKZC1+D1fMKCEqcnPmEZQKj2CwkY2chaZmF pGUWkpYFjCyrGNlzEzNz0ssNNzEC4+fglt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBkbRiBuWU801XqVsPdkQeahzp/VbS5Vjq4WZf10X1zJJPPzp/eKO NVs+uUt5GnZHzfExZHyXq3392c6m5WdXaka/aheQtz8/qV56d6jytpomNR45Vxa+pFKfoIAX ztqa985IfcgQ3X2s+NvzO/ddWVW5k64++XNn7+seD5+YiUEVG5x+VjlJNCuxFGckGmoxFxUn AgBHomqdbQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xkY_Ku99jEOWlB1Z0gimpVdbaIA Cc: "Lijing \(Jessie\)" Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 19:17:48 -0000 Paul just said what I meant :) Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 L=E4hetetty: 13. helmikuuta 2014 20:15 Vastaanottaja: Christer Holmberg; Liuyan (Scarlett); clue@ietf.org Kopio: Lijing (Jessie) Aihe: Re: [clue] CLUE Data Channel: Identical stream ID values in both dire= ctions? Scarlett, To elaborate on what Christer said: WebRTC is defining a way for browsers to do real-time communication. It isn= 't an application, it is a platform for applications. The key is that a this allows browser applications to do so without plugins= like Flash. We have a few possible situations for clue and data channels: 1) two native sip clue endpoints. They use the data channel, but no browser= is involved. 2) one native sip clue endpoint talking to an a clue endpoint implemented i= n a browser using WebRTC. They have a data channel between them. For use by= the browser it must meet all the requirements of a WebRTC Data Channel. An= d it also must meet all the requirements of a CLUE channel. 3) two browsers talking to each other using CLUE over WebRTC. With WebRTC, there are only a few PPIDs that can be used. They are being us= ed to distinguish DCP messages from user messages, and to distinguish the e= ncoding of data messages as strings or binary. If we were to use a differen= t PPID for CLUE then a browser app wouldn't be able to deal with it. Thanks, Paul On 2/13/14 6:38 AM, Christer Holmberg wrote: > Hi Scarlett, > >>>>> PPID is used for a different purpose. (It is used to distinguish=20 >>>>> OPEN and ACK messages from data messages, and to indicate the encodin= g of data messages.) And we need to follow rtcweb on that to maintain compa= tibility. >>>>> >>>> [Scarlett] I see the PPID's usage in section 5 of draft data-channel a= s below: >>>> Each SCTP user message contains a so called Payload Prot= ocol >>>> Identifier (PPID) that is passed to SCTP by its upper la= yer and sent >>>> to its peer. This value can be used to multiplex multip= le protocols >>>> over a single SCTP association. The sender provides for= each >>>> protocol a specific PPID and the receiver can demultiple= x the >>>> messages based on the received PPID. >>>> I think that the PPID of OPEN messages is the same as the PPID of = ACK messages as described in data-protocol. >>>> This draft data-protocol says in section 8.1 as below: >>>> | Value | SCTP PPID | Reference | >>>> +-------------+-----------+-----------+ >>>> | WebRTC DCEP | 50 | [RFCXXXX] | >>>> +-------------+-----------+-----------+ >>>> And it says in section 8.2 as below: >>>> +-------------------+-----------+-----------+ >>>> | Name | Type | Reference | >>>> +-------------------+-----------+-----------+ >>>> | Reserved | 0x00 | [RFCXXXX] | >>>> | Reserved | 0x01 | [RFCXXXX] | >>>> | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | >>>> | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | >>>> | Unassigned | 0x04-0xfe | | >>>> | Reserved | 0xff | [RFCXXXX] | >>>> +-------------------+-----------+-----------+ >>>> So, if a data channel for CLUE and another data channel for WebRTC = are simultaneously used per association, they PPIDs is different. >>>> >>> That is not true - at least not if we want to be compatible with the=20 >>> WebRTC data channel. In such case the PPIDs will be the same, and anoth= er mechanism (e.g. DCP or Richard's draft) is needed to indicate what appli= cation protocol (e.g. CLUE) the data channel is used for. >> [Scarlett] You said " In such case the PPIDs will be the same ". I am co= nfused what cases you said. >> If CLUE is compatible with the WebRTC data channel, WebRTC client using = CLUE protocol uses the same data channel for WebRTC and CLUE ?? > > Yes. A browser only understands WebRTC data channels. > > Regards, > > Christer > > From nobody Sat Feb 15 00:31:03 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10391A0118 for ; Sat, 15 Feb 2014 00:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsKKL4INDQpM for ; Sat, 15 Feb 2014 00:30:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD5B1A00F4 for ; Sat, 15 Feb 2014 00:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2558; q=dns/txt; s=iport; t=1392453058; x=1393662658; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XONMFfLqzMmIH9LrgRlKmYzRKtg5seYlmpTg+J9Obvw=; b=baXXjkjL5Vy0h3Sg/frISU1So146I8jWwdDwv2fHLpZIWe0uANs7eZ3O Hj0s/pewIaZtkms/oh7QtqcQet+KAq6DVyDWLKFwMfmnAMdjnbHmaWCRX 4OFTHgQlKByqxODh8nQtVtWjEZ7RX775vE1frlz+RVH13Ne3pUBForgWk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAKUk/1KtJV2a/2dsb2JhbABZgwY4UQaDArwzGHoWdIIlAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBBMIAYd8CAWnB6FMF4EpjSE4BoJpNYEUBJlekHGDLYIq X-IronPort-AV: E=Sophos;i="4.95,849,1384300800"; d="scan'208";a="304102173" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 15 Feb 2014 08:30:57 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1F8UvWU008618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 15 Feb 2014 08:30:57 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.87]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Sat, 15 Feb 2014 02:30:57 -0600 From: "Robert Hansen (rohanse2)" To: "clue@ietf.org" Thread-Topic: New Version Notification for draft-kyzivat-clue-signaling-07.txt Thread-Index: AQHPKdh7zYPhZvaW+kunX6lfdhgW2pq1/CGA Date: Sat, 15 Feb 2014 08:30:56 +0000 Message-ID: References: <20140214225946.25105.54093.idtracker@ietfa.amsl.com> In-Reply-To: <20140214225946.25105.54093.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.87.223] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6IMNKMpHaBWeJQczK6f3_SrkTxM Subject: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 15 Feb 2014 08:31:02 -0000 VGhpcyB1cGRhdGUgZG9lc24ndCBwcm9wb3NlIG1hc3NlcyBvZiBuZXcgY29udGVudCwgaW5zdGVh ZCBpdCBpcyBtb3N0bHkgcmVtb3ZpbmcgZGlzY3Vzc2lvbiBvZiBpc3N1ZXMgbGlrZSBlbmNvZGlu ZyBsaW1pdHMgaW4gZmF2b3VyIG9mIG1vcmUgbm9ybWF0aXZlIGxhbmd1YWdlLCBleHBhbmRpbmcg dGhlIHNlY3Rpb24gb24gY2hhbmdpbmcgY2x1ZSBzdGF0dXMgbWlkLWNhbGwgYW5kIGludGVyb3Ag d2l0aCBub24tQ0xVRSBkZXZpY2VzLCBhbmQgcmVhcnJhbmdpbmcgdGhlIGRyYWZ0IHRvIGZvY3Vz IG1vcmUgb24gdGhlIGRlY2lzaW9ucyBtYWRlLg0KDQpSb2INCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiAxNCBGZWJydWFyeSAyMDE0IDIzOjAwDQpUbzogTGVu bmFyZCBYaWFvOyBQYXVsIEt5eml2YXQ7IExlbm5hcmQgWGlhbzsgUm9iZXJ0IEhhbnNlbiAocm9o YW5zZTIpOyBSb2JlcnQgSGFuc2VuIChyb2hhbnNlMik7IENocmlzdGlhbiBHcm92ZXM7IENocmlz dGlhbiBHcm92ZXM7IFBhdWwgS3l6aXZhdA0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1reXppdmF0LWNsdWUtc2lnbmFsaW5nLTA3LnR4dA0KDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1reXppdmF0LWNsdWUtc2lnbmFsaW5nLTA3LnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb2JlcnQgSGFuc2VuIGFuZCBwb3N0ZWQgdG8g dGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWt5eml2YXQtY2x1ZS1zaWduYWxp bmcNClJldmlzaW9uOgkwNw0KVGl0bGU6CQlDTFVFIFNpZ25hbGluZw0KRG9jdW1lbnQgZGF0ZToJ MjAxNC0wMi0xNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMzcNClVS TDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1r eXppdmF0LWNsdWUtc2lnbmFsaW5nLTA3LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt5eml2YXQtY2x1ZS1zaWduYWxpbmcvDQpIdG1s aXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta3l6aXZhdC1jbHVl LXNpZ25hbGluZy0wNw0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWt5eml2YXQtY2x1ZS1zaWduYWxpbmctMDcNCg0KQWJzdHJhY3Q6DQogICBU aGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgQ0xVRS1zcGVjaWZpYyBzaWduYWxpbmcgc3VjaCBh cyB0aGUgQ0xVRQ0KICAgcHJvdG9jb2wgW0ktRC5wcmVzdGEtY2x1ZS1wcm90b2NvbF0gYW5kIHRo ZSBDTFVFIGRhdGEgY2hhbm5lbA0KICAgW0ktRC5ob2xtYmVyZy1jbHVlLWRhdGFjaGFubmVsXSBh cmUgdXNlZCB3aXRoIGVhY2ggb3RoZXIgYW5kIHdpdGgNCiAgIGV4aXN0aW5nIHNpZ25hbGluZyBt ZWNoYW5pc21zIHN1Y2ggYXMgU0lQIGFuZCBTRFAgdG8gcHJvZHVjZSBhDQogICB0ZWxlcHJlc2Vu Y2UgY2FsbC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sat Feb 15 01:46:03 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49D01A0193 for ; Sat, 15 Feb 2014 01:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJgnzsMIE7vu for ; Sat, 15 Feb 2014 01:46:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB801A014A for ; Sat, 15 Feb 2014 01:46:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD79129; Sat, 15 Feb 2014 09:45:56 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 09:45:10 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 09:45:10 +0000 Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.104]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 17:44:59 +0800 From: "Liuyan (Scarlett)" To: Paul Kyzivat , Christer Holmberg , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: Identical stream ID values in both directions? Thread-Index: AQHPIbVP3ZnGtuZ6YkmTiKnVfw/W5pqknpCAgACZxYCAC8t58IAApaYAgADmfkD//814gIAAsvJQ//+GeYCAAG63gIADGNEg Date: Sat, 15 Feb 2014 09:44:58 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> <52F177D1.5090700@nteczone.com> <52FBE7B0.2090301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D16FFAE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1706C3@ESESSMB209.ericsson.se> <52FD0BB1.4020206@alum.mit.edu> In-Reply-To: <52FD0BB1.4020206@alum.mit.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.137.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/clue/kpW3bdWRU2CUQc-cduFQ7NxHP74 Cc: "Lijing \(Jessie\)" Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 15 Feb 2014 09:46:03 -0000 Hello Paul and Christer, Thanks your patiently reply. I seem to understand the possible situations you mentioned. There is in= deed a hole in some drafts. Maybe I need to fill some knowledge about RTCWEB.:-) =20 Best Regards, Scarlett -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Friday, February 14, 2014 2:15 AM To: Christer Holmberg; Liuyan (Scarlett); clue@ietf.org Cc: Lijing (Jessie) Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both d= irections? Scarlett, To elaborate on what Christer said: WebRTC is defining a way for browsers to do real-time communication. It isn= 't an application, it is a platform for applications. The key is that a this allows browser applications to do so without plugins= like Flash. We have a few possible situations for clue and data channels: 1) two native sip clue endpoints. They use the data channel, but no browser= is involved. 2) one native sip clue endpoint talking to an a clue endpoint implemented i= n a browser using WebRTC. They have a data channel between them. For use by= the browser it must meet all the requirements of a WebRTC Data Channel. An= d it also must meet all the requirements of a CLUE channel. 3) two browsers talking to each other using CLUE over WebRTC. With WebRTC, there are only a few PPIDs that can be used. They are being us= ed to distinguish DCP messages from user messages, and to distinguish the e= ncoding of data messages as strings or binary. If we were to use a differen= t PPID for CLUE then a browser app wouldn't be able to deal with it. Thanks, Paul On 2/13/14 6:38 AM, Christer Holmberg wrote: > Hi Scarlett, > >>>>> PPID is used for a different purpose. (It is used to distinguish=20 >>>>> OPEN and ACK messages from data messages, and to indicate the encodin= g of data messages.) And we need to follow rtcweb on that to maintain compa= tibility. >>>>> >>>> [Scarlett] I see the PPID's usage in section 5 of draft data-channel a= s below: >>>> Each SCTP user message contains a so called Payload Prot= ocol >>>> Identifier (PPID) that is passed to SCTP by its upper la= yer and sent >>>> to its peer. This value can be used to multiplex multip= le protocols >>>> over a single SCTP association. The sender provides for= each >>>> protocol a specific PPID and the receiver can demultiple= x the >>>> messages based on the received PPID. >>>> I think that the PPID of OPEN messages is the same as the PPID of = ACK messages as described in data-protocol. >>>> This draft data-protocol says in section 8.1 as below: >>>> | Value | SCTP PPID | Reference | >>>> +-------------+-----------+-----------+ >>>> | WebRTC DCEP | 50 | [RFCXXXX] | >>>> +-------------+-----------+-----------+ >>>> And it says in section 8.2 as below: >>>> +-------------------+-----------+-----------+ >>>> | Name | Type | Reference | >>>> +-------------------+-----------+-----------+ >>>> | Reserved | 0x00 | [RFCXXXX] | >>>> | Reserved | 0x01 | [RFCXXXX] | >>>> | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | >>>> | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | >>>> | Unassigned | 0x04-0xfe | | >>>> | Reserved | 0xff | [RFCXXXX] | >>>> +-------------------+-----------+-----------+ >>>> So, if a data channel for CLUE and another data channel for WebRTC = are simultaneously used per association, they PPIDs is different. >>>> >>> That is not true - at least not if we want to be compatible with the=20 >>> WebRTC data channel. In such case the PPIDs will be the same, and anoth= er mechanism (e.g. DCP or Richard's draft) is needed to indicate what appli= cation protocol (e.g. CLUE) the data channel is used for. >> [Scarlett] You said " In such case the PPIDs will be the same ". I am co= nfused what cases you said. >> If CLUE is compatible with the WebRTC data channel, WebRTC client using = CLUE protocol uses the same data channel for WebRTC and CLUE ?? > > Yes. A browser only understands WebRTC data channels. > > Regards, > > Christer > > From nobody Sat Feb 15 01:56:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D171A0107 for ; Sat, 15 Feb 2014 01:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bdkmQE2SqOI for ; Sat, 15 Feb 2014 01:56:02 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id D4D1F1A00A8 for ; Sat, 15 Feb 2014 01:56:01 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-97-52ff39af015e Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id DB.91.04249.FA93FF25; Sat, 15 Feb 2014 10:55:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Sat, 15 Feb 2014 10:55:59 +0100 From: Christer Holmberg To: "Liuyan (Scarlett)" , Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: Identical stream ID values in both directions? Thread-Index: Ac8hnlNVKx/zx1mwSsaGQD1SBC5QUgADHU6AAAIuGcAAEULkgAFpRIEAACTfSgAADUhyAAALEh8AAAQveQAAAwhh4AAL8KaAAFLDNwAAAnDPeA== Date: Sat, 15 Feb 2014 09:55:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D18C37C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D15838D@ESESSMB209.ericsson.se> <52F0F559.7070803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1586A4@ESESSMB209.ericsson.se> <52F177D1.5090700@nteczone.com> <52FBE7B0.2090301@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D16FFAE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D1706C3@ESESSMB209.ericsson.se> <52FD0BB1.4020206@alum.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvje56y/9BBhOvS1rsP3WZ2WJ581JG ixUbDrBaHHzRwuTA4vH3/Qcmj5Yjb1k9liz5yRTAHMVlk5Kak1mWWqRvl8CV8X3RCsaCXvWK zrePGBsYj8t0MXJwSAiYSBy9m9vFyAlkiklcuLeerYuRi0NI4AijxOzFTYwQzhJGiZ73P1hA GtgELCS6/2mDNIgI1EqsPtbFBGIzC2hLLDvUyAZiCwuESzTcn8cKURMh8bNpP5RdJ3Hz4UIw m0VAVaLx7RVGEJtXwFei4eN1Fohd51klGmafZAZJcAqESZxvOAm2gBHouu+n1kAtE5e49WQ+ E8TVAhJL9pxnhrBFJV4+/scK8ZiSxLStaRDlOhILdn9ig7tz4WtmiL2CEidnPmGZwCg2C8nU WUhaZiFpmYWkZQEjyypGjuLU4qTcdCODTYzACDq45bfFDsbLf20OMUpzsCiJ83586xwkJJCe WJKanZpakFoUX1Sak1p8iJGJg1OqgXHSep8zGjfW5AkvTJz41nWzCmfU9w9+bWf4Tl6qklv3 z/HVk5NPvTSV+9cvFz+rY9iSq+W9ZsVRg567U4/3Bs1lY+Z7KLq2+OFp+yjZHMtVPy14OSZd n3TkwxvZCZc+Lf27wv7ZMYufesvXH2HpPOUkxfarZ/Y3qQo3pR/bf38MuVdxe59K3bTvSizF GYmGWsxFxYkAp8UnyG4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VZNCCH8S6_xOqY0BLQPQlXvCyjk Cc: "Lijing \(Jessie\)" Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 15 Feb 2014 09:56:05 -0000 Hi Scarlett, If you are interested in the CLUE Data Channel, you should definately take = a look at the RTCWEB drafts and discussions :) Regards, Christer ________________________________________ From: Liuyan (Scarlett) [scarlett.liuyan@huawei.com] Sent: Saturday, 15 February 2014 11:44 AM To: Paul Kyzivat; Christer Holmberg; clue@ietf.org Cc: Lijing (Jessie) Subject: RE: [clue] CLUE Data Channel: Identical stream ID values in both d= irections? Hello Paul and Christer, Thanks your patiently reply. I seem to understand the possible situations you mentioned. There is in= deed a hole in some drafts. Maybe I need to fill some knowledge about RTCWEB.:-) Best Regards, Scarlett -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Friday, February 14, 2014 2:15 AM To: Christer Holmberg; Liuyan (Scarlett); clue@ietf.org Cc: Lijing (Jessie) Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both d= irections? Scarlett, To elaborate on what Christer said: WebRTC is defining a way for browsers to do real-time communication. It isn= 't an application, it is a platform for applications. The key is that a this allows browser applications to do so without plugins= like Flash. We have a few possible situations for clue and data channels: 1) two native sip clue endpoints. They use the data channel, but no browser= is involved. 2) one native sip clue endpoint talking to an a clue endpoint implemented i= n a browser using WebRTC. They have a data channel between them. For use by= the browser it must meet all the requirements of a WebRTC Data Channel. An= d it also must meet all the requirements of a CLUE channel. 3) two browsers talking to each other using CLUE over WebRTC. With WebRTC, there are only a few PPIDs that can be used. They are being us= ed to distinguish DCP messages from user messages, and to distinguish the e= ncoding of data messages as strings or binary. If we were to use a differen= t PPID for CLUE then a browser app wouldn't be able to deal with it. Thanks, Paul On 2/13/14 6:38 AM, Christer Holmberg wrote: > Hi Scarlett, > >>>>> PPID is used for a different purpose. (It is used to distinguish >>>>> OPEN and ACK messages from data messages, and to indicate the encodin= g of data messages.) And we need to follow rtcweb on that to maintain compa= tibility. >>>>> >>>> [Scarlett] I see the PPID's usage in section 5 of draft data-channel a= s below: >>>> Each SCTP user message contains a so called Payload Prot= ocol >>>> Identifier (PPID) that is passed to SCTP by its upper la= yer and sent >>>> to its peer. This value can be used to multiplex multip= le protocols >>>> over a single SCTP association. The sender provides for= each >>>> protocol a specific PPID and the receiver can demultiple= x the >>>> messages based on the received PPID. >>>> I think that the PPID of OPEN messages is the same as the PPID of = ACK messages as described in data-protocol. >>>> This draft data-protocol says in section 8.1 as below: >>>> | Value | SCTP PPID | Reference | >>>> +-------------+-----------+-----------+ >>>> | WebRTC DCEP | 50 | [RFCXXXX] | >>>> +-------------+-----------+-----------+ >>>> And it says in section 8.2 as below: >>>> +-------------------+-----------+-----------+ >>>> | Name | Type | Reference | >>>> +-------------------+-----------+-----------+ >>>> | Reserved | 0x00 | [RFCXXXX] | >>>> | Reserved | 0x01 | [RFCXXXX] | >>>> | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | >>>> | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | >>>> | Unassigned | 0x04-0xfe | | >>>> | Reserved | 0xff | [RFCXXXX] | >>>> +-------------------+-----------+-----------+ >>>> So, if a data channel for CLUE and another data channel for WebRTC = are simultaneously used per association, they PPIDs is different. >>>> >>> That is not true - at least not if we want to be compatible with the >>> WebRTC data channel. In such case the PPIDs will be the same, and anoth= er mechanism (e.g. DCP or Richard's draft) is needed to indicate what appli= cation protocol (e.g. CLUE) the data channel is used for. >> [Scarlett] You said " In such case the PPIDs will be the same ". I am co= nfused what cases you said. >> If CLUE is compatible with the WebRTC data channel, WebRTC client using = CLUE protocol uses the same data channel for WebRTC and CLUE ?? > > Yes. A browser only understands WebRTC data channels. > > Regards, > > Christer > > From nobody Sat Feb 15 06:03:22 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628841A0258 for ; Sat, 15 Feb 2014 06:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHx26o8SFf_5 for ; Sat, 15 Feb 2014 06:03:17 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EA4251A024C for ; Sat, 15 Feb 2014 06:03:16 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-fd-52ff73a28a76 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 88.4F.23809.2A37FF25; Sat, 15 Feb 2014 15:03:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Sat, 15 Feb 2014 15:03:13 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: CLUE Data Channel: SDP Offer/Answer Proceudres Thread-Index: Ac8qVqpg/4DOh4ZTSGSaavDifVp2Wg== Date: Sat, 15 Feb 2014 14:03:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D18D51B@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvje6i4v9BBitnKFjsP3WZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGdum/Gcp+KxSsfKTUANjl3QXIyeHhICJxOflW9ghbDGJC/fW s3UxcnEICRxilLg+YwkzhLOEUeJ3xw+mLkYODjYBC4nuf9ogDSICyhJHN/ezgdjCAuYSr5dt ZoGI20j8v/GLGaRcREBPYsO1NJAwi4CqxL95HWDlvAK+EgvuTWUGsRmB9n4/tYYJxGYWEJe4 9WQ+E8Q9AhJL9pxnhrBFJV4+/scKYStKtD8F+gCsXkdiwe5PbBC2tsSyha+ZIeYLSpyc+YRl AqPwLCRjZyFpmYWkZRaSlgWMLKsY2XMTM3PSy402MQJD+OCW36o7GO+cEznEKM3BoiTO++Gt c5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRiaHhVsDrrj9TbEu3Nv00KVyPkvfl53PwhP5 fyT+tv1uJXHdbemd+qczFxpfPVRVe0l+qvkELvbjmocuH+rcPynfQbhVYaERd2/UTPE9d07e WP/5amj+36d/QpwXXrzXJHY64sdlydppapIrWQTeTrOp21jA5+uyag0/t9/yZdxHlt9iq2I3 VVRiKc5INNRiLipOBADvDkGNLwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/or1mWtnbwTLb1zxj44Cv0al9vV4 Subject: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 15 Feb 2014 14:03:20 -0000 Hi, The draft submission deadline has passed, but I still wrote some more text,= shown below, for the SDP Offer/Answer Procedures section. Regards, Christer PS. Note that I will be on vacation next week, so I will once again do my b= est trying to stay away from e-mails :) ----------------------- 4. SDP Offer/Answer Procedures 4.1. General This section describes how the SDP media description ("m=3D") line for a CLUE data channel is created, and how it is used in SDP offers and answers. NOTE: The proceudres associated with "m=3D" lines for other media types (e.g. audio and video) used in a CLUE session are outside the scope of this document. OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be used with the CLUE data channel. NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be used with the CLUE data channel, a new associated 'sub-protocol' value needs to be registered with IANA. 4.2. SDP Media Description Fields The field values of the "m=3D" line for the CLUE data channel are set as following: +----------------+----------------+------------------------+------------= ----+ | media | port | proto | f= mt | +----------------+----------------+------------------------+------------= ----+ | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP port | | | value | | = value | +----------------+----------------+------------------------+------------= ---+ Table 1: SDP "proto" field values 4.3. SDP sctpmap Attribute The field values of the SDP sctpmap attribute associated with the CLUE data channel "m=3D" are set as following: +---------------------+---------------------------+---------------------= --+---------+ | sctpmap-number | app | max-message-size | str= eam | +---------------------+---------------------------+---------------------= --+---------+ | fmt value of | "webrtc-datachannel" | Implemenation | "1"= | | the "m=3D" line | | specific = | | +---------------------+---------------------------+---------------------= --+---------+ Table 2: SDP "proto" field values 4.4. SDP Offerer Procedures The procedures for the offerer follow the normal proceures defined in [ref-to-3264]. When the offerer creates an offer, which contains an "m=3D" line for a CLUE data channel, it assigns the field values to the "m=3D" line according to the procedures in Section 4.2. In addition, the offerer MUST insert an SDP sctpmap attribute associated with the "m=3D" line. In an offer, the offerer MUST NOT insert more than one "m=3D" line for a CLUE data channel. NOTE: CLUE does not support the usage of multiple CLUE data channels. The offerer MUST NOT insert more than one SDP sctpmap attributes in an "m=3D" line for a CLUE data channel. If an offerer, in a subsequent offer, wants to disable the CLUE data channel, it assigns a zero port value to the "m=3D" line associated with the CLUE data channel. The answerer MUST NOT insert an SDP sctpmap attribute associated with the "m=3D" line. 4.5. SDP Answerer Procedures The procedures for the answerer follow the normal proceures defined in [ref-to-3264]. If the answerer receives an offer, which contains an "m=3D" line for a CLUE data channel, and the answerer accepts the "m=3D" line, it creates and inserts an "m=3D" line in the associated answer. The answerer assigns the field values to the "m=3D" line according to the procedures in Section 4.2. If, in the offer, a zero port value has been assigned to the "m=3D" line for the CLUE channel, or it the answerer does not accept the "m=3D" line, but accepts other "m=3D" lines in the offer (i.e. the answerer will not reject the whole offer), it still inserts an "m=3D" line for a CLUE data channel in the associated answer. The answerer then assigns a zero port value to the "m=3D" line. The answerer MUST NOT insert an SDP sctpmap attribute associated with the "m=3D" line. 4.6. Example m=3Dapplication 54111 SCTP/DTLS 54111 a=3Dsctpmap:54111 webrtc-datachannel max-message-size=3D100000 stre= ams=3D1 Figure 1: SDP Media Description for a CLUE data channel From nobody Sun Feb 16 15:35:40 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1223D1A0168 for ; Sun, 16 Feb 2014 15:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_44=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu26-Ew5Cab4 for ; Sun, 16 Feb 2014 15:35:37 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E251A00BB for ; Sun, 16 Feb 2014 15:35:36 -0800 (PST) Received: from ppp118-209-188-133.lns20.mel6.internode.on.net ([118.209.188.133]:50565 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFBCl-0000kl-Ab for clue@ietf.org; Mon, 17 Feb 2014 10:32:59 +1100 Message-ID: <53014B44.60600@nteczone.com> Date: Mon, 17 Feb 2014 10:35:32 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/i1EWGrf4yTCo1IyQMSCd_e8IbMg Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2014 23:35:39 -0000 Hello Christer, With the use of webrtc-datachannel how do I negotiate via SDP whether I want to use clue or not? A SCTP association (and thus webrtc-datachannel) for example could be used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP association to figure out that the endpoints support webrtc-datachannel put don't support the application that you want. In the example in section 4.6 there's no way of distinguishing that description for CLUE vs BFCP vs anything else. Its not a CLUE data channel is a generic data channel. Regards, Christian On 16/02/2014 1:03 AM, Christer Holmberg wrote: > Hi, > > The draft submission deadline has passed, but I still wrote some more text, shown below, for the SDP Offer/Answer Procedures section. > > Regards, > > Christer > > PS. Note that I will be on vacation next week, so I will once again do my best trying to stay away from e-mails :) > > ----------------------- > > 4. SDP Offer/Answer Procedures > > 4.1. General > > This section describes how the SDP media description ("m=") line for > a CLUE data channel is created, and how it is used in SDP offers and > answers. > > NOTE: The proceudres associated with "m=" lines for other media types > (e.g. audio and video) used in a CLUE session are outside the scope > of this document. > > OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel > Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] > will be used with the CLUE data channel. > > NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be used > with the CLUE data channel, a new associated 'sub-protocol' value > needs to be registered with IANA. > > 4.2. SDP Media Description Fields > > The field values of the "m=" line for the CLUE data channel are set > as following: > > +----------------+----------------+------------------------+----------------+ > | media | port | proto | fmt | > +----------------+----------------+------------------------+----------------+ > | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP port | > | | value | | value | > +----------------+----------------+------------------------+---------------+ > > Table 1: SDP "proto" field values > > 4.3. SDP sctpmap Attribute > > The field values of the SDP sctpmap attribute associated with the > CLUE data channel "m=" are set as following: > > +---------------------+---------------------------+-----------------------+---------+ > | sctpmap-number | app | max-message-size | stream | > +---------------------+---------------------------+-----------------------+---------+ > | fmt value of | "webrtc-datachannel" | Implemenation | "1" | > | the "m=" line | | specific | | > +---------------------+---------------------------+-----------------------+---------+ > > Table 2: SDP "proto" field values > > 4.4. SDP Offerer Procedures > > The procedures for the offerer follow the normal proceures defined in > [ref-to-3264]. > > When the offerer creates an offer, which contains an "m=" line for a > CLUE data channel, it assigns the field values to the "m=" line > according to the procedures in Section 4.2. In addition, the offerer > MUST insert an SDP sctpmap attribute associated with the "m=" line. > > In an offer, the offerer MUST NOT insert more than one "m=" line for > a CLUE data channel. > > NOTE: CLUE does not support the usage of multiple CLUE data channels. > > The offerer MUST NOT insert more than one SDP sctpmap attributes in > an "m=" line for a CLUE data channel. > > If an offerer, in a subsequent offer, wants to disable the CLUE data > channel, it assigns a zero port value to the "m=" line associated > with the CLUE data channel. The answerer MUST NOT insert an SDP > sctpmap attribute associated with the "m=" line. > > 4.5. SDP Answerer Procedures > > The procedures for the answerer follow the normal proceures defined > in [ref-to-3264]. > > If the answerer receives an offer, which contains an "m=" line for a > CLUE data channel, and the answerer accepts the "m=" line, it creates > and inserts an "m=" line in the associated answer. The answerer > assigns the field values to the "m=" line according to the procedures > in Section 4.2. > > If, in the offer, a zero port value has been assigned to the "m=" > line for the CLUE channel, or it the answerer does not accept the > "m=" line, but accepts other "m=" lines in the offer (i.e. the > answerer will not reject the whole offer), it still inserts an "m=" > line for a CLUE data channel in the associated answer. The answerer > then assigns a zero port value to the "m=" line. The answerer MUST > NOT insert an SDP sctpmap attribute associated with the "m=" line. > > 4.6. Example > > m=application 54111 SCTP/DTLS 54111 > a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 > > Figure 1: SDP Media Description for a CLUE data channel > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Feb 16 15:40:21 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147411A042B for ; Sun, 16 Feb 2014 15:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKo9vt-W7kwA for ; Sun, 16 Feb 2014 15:40:19 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AD51A02AC for ; Sun, 16 Feb 2014 15:40:19 -0800 (PST) Received: from ppp118-209-188-133.lns20.mel6.internode.on.net ([118.209.188.133]:50638 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFBHK-0001r7-Di for clue@ietf.org; Mon, 17 Feb 2014 10:37:42 +1100 Message-ID: <53014C5F.3060405@nteczone.com> Date: Mon, 17 Feb 2014 10:40:15 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/n80EPaAdqd3iDB-CppLJINToVCo Subject: Re: [clue] Reminder: draft deadline for IETF-89 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2014 23:40:21 -0000 Hello Mary and Paul, Will draft-groves-clue-latent-config-00 be covered under the signalling discussions? Regards, Christian On 12/02/2014 2:43 AM, Mary Barnes wrote: > As a reminder, the draft deadline for the London meeting is this > Friday (Feb. 14th), so you don't get the usual weekend to work up to a > Monday deadline: > http://www.ietf.org/meeting/important-dates-2014.html#IETF89 > > Note also that a draft agenda is due on Monday, Feb. 17th, so the > chairs will put one together based on the current set of work items. > If you have something beyond that, please let us know ASAP. > > Thanks, > Mary. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Sun Feb 16 16:16:31 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F45B1A0024 for ; Sun, 16 Feb 2014 16:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_111=0.6, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfUbaWbfFNIb for ; Sun, 16 Feb 2014 16:16:28 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 26CC51A01E9 for ; Sun, 16 Feb 2014 16:16:26 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-5c-530154d7c4e2 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 9B.F4.04853.7D451035; Mon, 17 Feb 2014 01:16:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Mon, 17 Feb 2014 01:16:23 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres Thread-Index: Ac8qVqpg/4DOh4ZTSGSaavDifVp2WgBELw4AAAOFnDE= Date: Mon, 17 Feb 2014 00:16:22 +0000 Message-ID: <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com> References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> In-Reply-To: <53014B44.60600@nteczone.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-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvje71EMZgg2cd5hZf3jeyWOw/dZnZ gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mo4/mUGY8Fjw4pV7+4wNTA+U+li5OSQEDCR 2DdjMhuELSZx4d56IJuLQ0jgBKNE99bt7BDOEkaJk9NPs3YxcnCwCVhIdP/TBmkQEQiX6Nh2 hRHEFhZwktiy+C8jRNxZYm3DDHYI20riVNsnFhCbRUBV4uuZV0wgNq+Am8TzVb/A4kIC2RI7 5jawgticAloSJ2e0g81hBDro+6k1YPXMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWp0JBbs /sQGYWtLLFv4mhlil6DEyZlPWCYwisxCMmoWkpZZSFpmIWlZwMiyilGyOLW4ODfdyEAvNz23 RC+1KDO5uDg/T684dRMjMC4ObvlttIPx5B77Q4zSHCxK4rzXWWuChATSE0tSs1NTC1KL4otK c1KLDzEycXBKNTCWlK+0FJq4UragKTCmVOry/hdSL8rmL0pw+bK0czLPHL56GV+rg0ezb6jk fTuS+SX/wJE9kem2fts7lWy32dx/ynUr6xpzvCnfypBrqy7zZKssSX8s0PKkVmZbU+HTbRqT trmJSx54OdHYNuZX1hmVSb9fTmV5xyO9LaOhzvOesf9ZQVmlBjslluKMREMt5qLiRABn9JMO WQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qBNStHKbjR2xZhBi_GRlcOO1-Ro Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 00:16:30 -0000 Hi Christian, If you want to negotiate usage of CLUE (or, any other specific usage of a w= ebrtc-datachannel) in SDP, one option is to use Richard's draft. The usage = of that draft is listed as an open issue in the CLUE data channel draft. SIP also provides other mechanisms, e.g. media feature tags, for indicating= support of features. Regards, Christer Sent from my Sony Ericsson Xperia arc S Christian Groves wrote: Hello Christer, With the use of webrtc-datachannel how do I negotiate via SDP whether I want to use clue or not? A SCTP association (and thus webrtc-datachannel) for example could be used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP association to figure out that the endpoints support webrtc-datachannel put don't support the application that you want. In the example in section 4.6 there's no way of distinguishing that description for CLUE vs BFCP vs anything else. Its not a CLUE data channel is a generic data channel. Regards, Christian On 16/02/2014 1:03 AM, Christer Holmberg wrote: > Hi, > > The draft submission deadline has passed, but I still wrote some more tex= t, shown below, for the SDP Offer/Answer Procedures section. > > Regards, > > Christer > > PS. Note that I will be on vacation next week, so I will once again do my= best trying to stay away from e-mails :) > > ----------------------- > > 4. SDP Offer/Answer Procedures > > 4.1. General > > This section describes how the SDP media description ("m=3D") line fo= r > a CLUE data channel is created, and how it is used in SDP offers and > answers. > > NOTE: The proceudres associated with "m=3D" lines for other media typ= es > (e.g. audio and video) used in a CLUE session are outside the scope > of this document. > > OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel > Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] > will be used with the CLUE data channel. > > NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be used > with the CLUE data channel, a new associated 'sub-protocol' value > needs to be registered with IANA. > > 4.2. SDP Media Description Fields > > The field values of the "m=3D" line for the CLUE data channel are set > as following: > > +----------------+----------------+------------------------+---------= -------+ > | media | port | proto | = fmt | > +----------------+----------------+------------------------+---------= -------+ > | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP port | > | | value | = | value | > +----------------+----------------+------------------------+---------= ------+ > > Table 1: SDP "proto" field values > > 4.3. SDP sctpmap Attribute > > The field values of the SDP sctpmap attribute associated with the > CLUE data channel "m=3D" are set as following: > > +---------------------+---------------------------+------------------= -----+---------+ > | sctpmap-number | app | max-message-size | = stream | > +---------------------+---------------------------+------------------= -----+---------+ > | fmt value of | "webrtc-datachannel" | Implemenation | = "1" | > | the "m=3D" line | | specifi= c | | > +---------------------+---------------------------+------------------= -----+---------+ > > Table 2: SDP "proto" field values > > 4.4. SDP Offerer Procedures > > The procedures for the offerer follow the normal proceures defined in > [ref-to-3264]. > > When the offerer creates an offer, which contains an "m=3D" line for = a > CLUE data channel, it assigns the field values to the "m=3D" line > according to the procedures in Section 4.2. In addition, the offerer > MUST insert an SDP sctpmap attribute associated with the "m=3D" line. > > In an offer, the offerer MUST NOT insert more than one "m=3D" line fo= r > a CLUE data channel. > > NOTE: CLUE does not support the usage of multiple CLUE data channels. > > The offerer MUST NOT insert more than one SDP sctpmap attributes in > an "m=3D" line for a CLUE data channel. > > If an offerer, in a subsequent offer, wants to disable the CLUE data > channel, it assigns a zero port value to the "m=3D" line associated > with the CLUE data channel. The answerer MUST NOT insert an SDP > sctpmap attribute associated with the "m=3D" line. > > 4.5. SDP Answerer Procedures > > The procedures for the answerer follow the normal proceures defined > in [ref-to-3264]. > > If the answerer receives an offer, which contains an "m=3D" line for = a > CLUE data channel, and the answerer accepts the "m=3D" line, it creat= es > and inserts an "m=3D" line in the associated answer. The answerer > assigns the field values to the "m=3D" line according to the procedur= es > in Section 4.2. > > If, in the offer, a zero port value has been assigned to the "m=3D" > line for the CLUE channel, or it the answerer does not accept the > "m=3D" line, but accepts other "m=3D" lines in the offer (i.e. the > answerer will not reject the whole offer), it still inserts an "m=3D" > line for a CLUE data channel in the associated answer. The answerer > then assigns a zero port value to the "m=3D" line. The answerer MUST > NOT insert an SDP sctpmap attribute associated with the "m=3D" line. > > 4.6. Example > > m=3Dapplication 54111 SCTP/DTLS 54111 > a=3Dsctpmap:54111 webrtc-datachannel max-message-size=3D100000 s= treams=3D1 > > Figure 1: SDP Media Description for a CLUE data channel > > _______________________________________________ > 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 nobody Sun Feb 16 16:56:18 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839891A00EA for ; Sun, 16 Feb 2014 16:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_44=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj-N8k9hXJNj for ; Sun, 16 Feb 2014 16:56:14 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1AD1A00E0 for ; Sun, 16 Feb 2014 16:56:14 -0800 (PST) Received: from ppp118-209-188-133.lns20.mel6.internode.on.net ([118.209.188.133]:52023 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFCSm-0005rR-2H; Mon, 17 Feb 2014 11:53:36 +1100 Message-ID: <53015E29.2000102@nteczone.com> Date: Mon, 17 Feb 2014 11:56:09 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com> In-Reply-To: <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/X6w2_L1x9w0py0SeSLGPj7G0s5k Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 00:56:16 -0000 Hello Christer, I think that for the signaling we must specify a way of negotiating at the SDP level whether CLUE is supported. I agree there's lots of ways it could be done but we need to indicate which one/s CLUE should use. So for the SDP O/A procedures and example I think you have to assume the use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say its a CLUE data channel according to the SDP given. You're just opening a generic channel, which may or may not be clue. Particularly in the Answerer's case, it doesn't know that the Offer is going to use the channel for CLUE. However: m=application 54111 SCTP/DTLS 54111 a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 a=dcmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3 would unambiguously define it as a CLUE data channel. Regards, Christian On 17/02/2014 11:16 AM, Christer Holmberg wrote: > Hi Christian, > > If you want to negotiate usage of CLUE (or, any other specific usage of a webrtc-datachannel) in SDP, one option is to use Richard's draft. The usage of that draft is listed as an open issue in the CLUE data channel draft. > > SIP also provides other mechanisms, e.g. media feature tags, for indicating support of features. > > Regards, > > Christer > > Sent from my Sony Ericsson Xperia arc S > > Christian Groves wrote: > > > Hello Christer, > > With the use of webrtc-datachannel how do I negotiate via SDP whether I > want to use clue or not? > > A SCTP association (and thus webrtc-datachannel) for example could be > used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP > association to figure out that the endpoints support webrtc-datachannel > put don't support the application that you want. > > In the example in section 4.6 there's no way of distinguishing that > description for CLUE vs BFCP vs anything else. Its not a CLUE data > channel is a generic data channel. > > Regards, Christian > > On 16/02/2014 1:03 AM, Christer Holmberg wrote: >> Hi, >> >> The draft submission deadline has passed, but I still wrote some more text, shown below, for the SDP Offer/Answer Procedures section. >> >> Regards, >> >> Christer >> >> PS. Note that I will be on vacation next week, so I will once again do my best trying to stay away from e-mails :) >> >> ----------------------- >> >> 4. SDP Offer/Answer Procedures >> >> 4.1. General >> >> This section describes how the SDP media description ("m=") line for >> a CLUE data channel is created, and how it is used in SDP offers and >> answers. >> >> NOTE: The proceudres associated with "m=" lines for other media types >> (e.g. audio and video) used in a CLUE session are outside the scope >> of this document. >> >> OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel >> Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] >> will be used with the CLUE data channel. >> >> NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be used >> with the CLUE data channel, a new associated 'sub-protocol' value >> needs to be registered with IANA. >> >> 4.2. SDP Media Description Fields >> >> The field values of the "m=" line for the CLUE data channel are set >> as following: >> >> +----------------+----------------+------------------------+----------------+ >> | media | port | proto | fmt | >> +----------------+----------------+------------------------+----------------+ >> | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP port | >> | | value | | value | >> +----------------+----------------+------------------------+---------------+ >> >> Table 1: SDP "proto" field values >> >> 4.3. SDP sctpmap Attribute >> >> The field values of the SDP sctpmap attribute associated with the >> CLUE data channel "m=" are set as following: >> >> +---------------------+---------------------------+-----------------------+---------+ >> | sctpmap-number | app | max-message-size | stream | >> +---------------------+---------------------------+-----------------------+---------+ >> | fmt value of | "webrtc-datachannel" | Implemenation | "1" | >> | the "m=" line | | specific | | >> +---------------------+---------------------------+-----------------------+---------+ >> >> Table 2: SDP "proto" field values >> >> 4.4. SDP Offerer Procedures >> >> The procedures for the offerer follow the normal proceures defined in >> [ref-to-3264]. >> >> When the offerer creates an offer, which contains an "m=" line for a >> CLUE data channel, it assigns the field values to the "m=" line >> according to the procedures in Section 4.2. In addition, the offerer >> MUST insert an SDP sctpmap attribute associated with the "m=" line. >> >> In an offer, the offerer MUST NOT insert more than one "m=" line for >> a CLUE data channel. >> >> NOTE: CLUE does not support the usage of multiple CLUE data channels. >> >> The offerer MUST NOT insert more than one SDP sctpmap attributes in >> an "m=" line for a CLUE data channel. >> >> If an offerer, in a subsequent offer, wants to disable the CLUE data >> channel, it assigns a zero port value to the "m=" line associated >> with the CLUE data channel. The answerer MUST NOT insert an SDP >> sctpmap attribute associated with the "m=" line. >> >> 4.5. SDP Answerer Procedures >> >> The procedures for the answerer follow the normal proceures defined >> in [ref-to-3264]. >> >> If the answerer receives an offer, which contains an "m=" line for a >> CLUE data channel, and the answerer accepts the "m=" line, it creates >> and inserts an "m=" line in the associated answer. The answerer >> assigns the field values to the "m=" line according to the procedures >> in Section 4.2. >> >> If, in the offer, a zero port value has been assigned to the "m=" >> line for the CLUE channel, or it the answerer does not accept the >> "m=" line, but accepts other "m=" lines in the offer (i.e. the >> answerer will not reject the whole offer), it still inserts an "m=" >> line for a CLUE data channel in the associated answer. The answerer >> then assigns a zero port value to the "m=" line. The answerer MUST >> NOT insert an SDP sctpmap attribute associated with the "m=" line. >> >> 4.6. Example >> >> m=application 54111 SCTP/DTLS 54111 >> a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 >> >> Figure 1: SDP Media Description for a CLUE data channel >> >> _______________________________________________ >> 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 nobody Sun Feb 16 17:11:39 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4CC1A0204 for ; Sun, 16 Feb 2014 17:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBZ2s1zvUk2U for ; Sun, 16 Feb 2014 17:11:34 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C6CFA1A00E0 for ; Sun, 16 Feb 2014 17:11:33 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-d9-530161c22650 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 95.7F.23809.2C161035; Mon, 17 Feb 2014 02:11:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Mon, 17 Feb 2014 02:11:30 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres Thread-Index: Ac8qVqpg/4DOh4ZTSGSaavDifVp2WgBELw4AAAOFnDH///pZgIAAFQ0D Date: Mon, 17 Feb 2014 01:11:29 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> In-Reply-To: <53015E29.2000102@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvje6hRMZgg9MLVCy+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJVxfvkf5oIeh4pd2/awNzB+0O9i5OSQEDCR +D9lNhuELSZx4d56IJuLQ0jgEKPEvKa7UM4SRokNx7qBHA4ONgELie5/2iANIgLhEh3brjCC 2MICThJbFv9lhIg7S6xtmMEOYbtJbDnUzwTSyiKgKnFjqjmIyQsUPnHcEGL6CUaJh70TwW7g FNCR2DSpE8xmBLrn+6k1TCA2s4C4xK0n85kg7hSQWLLnPDOELSrx8vE/VogaPaDxU9ggbG2J ZQtfg9XwCghKnJz5hGUCo8gsJKNmIWmZhaRlFpKWBYwsqxjZcxMzc9LLjTYxAgP+4JbfqjsY 75wTOcQozcGiJM774a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGf76OI3wnF8SmfOy3 Yz19V1nAUrVo57vIn58MHF7pn1F5xV7S/jdlUhfD1gMfTU95Mt7JXZrbP31bzD0Dl89ntBb3 7ZZ4/vT0DqFfu8tZA5ya1VkPf3CsmS516uKfyS8u7HolZT1vmc+2XL+05b7Spl4TtO6X/jea O2XpE+0qN9l8P7k3l5JPKLEUZyQaajEXFScCAK/MnYFGAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/u0WW3sBvZxViYwhcl9rOYcQS1DQ Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 01:11:38 -0000 Hi, If the offerer offers a data channel, AND also some way indicates support o= f CLUE, we can always specify that the offerer MUST be able to use the data= channel for CLUE. The WebRTC data channel protocol can then be used to ope= n the channel for CLUE. But, never the less, it would probably be good to have an example showing h= ow things would look like using Richard's draft, until we've decided whethe= r we are going to use it or not. I'll add that. Regards, Christer Sent from my Sony Ericsson Xperia arc S Christian Groves wrote: Hello Christer, I think that for the signaling we must specify a way of negotiating at the SDP level whether CLUE is supported. I agree there's lots of ways it could be done but we need to indicate which one/s CLUE should use. So for the SDP O/A procedures and example I think you have to assume the use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say its a CLUE data channel according to the SDP given. You're just opening a generic channel, which may or may not be clue. Particularly in the Answerer's case, it doesn't know that the Offer is going to use the channel for CLUE. However: m=3Dapplication 54111 SCTP/DTLS 54111 a=3Dsctpmap:54111 webrtc-datachannel max-message-size=3D100000 streams=3D1 a=3Ddcmap:54111 stream=3D2;label=3D"CLUE 1"; subprotocol=3D"CLUE"; max_retr= =3D3 would unambiguously define it as a CLUE data channel. Regards, Christian On 17/02/2014 11:16 AM, Christer Holmberg wrote: > Hi Christian, > > If you want to negotiate usage of CLUE (or, any other specific usage of a= webrtc-datachannel) in SDP, one option is to use Richard's draft. The usag= e of that draft is listed as an open issue in the CLUE data channel draft. > > SIP also provides other mechanisms, e.g. media feature tags, for indicati= ng support of features. > > Regards, > > Christer > > Sent from my Sony Ericsson Xperia arc S > > Christian Groves wrote: > > > Hello Christer, > > With the use of webrtc-datachannel how do I negotiate via SDP whether I > want to use clue or not? > > A SCTP association (and thus webrtc-datachannel) for example could be > used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP > association to figure out that the endpoints support webrtc-datachannel > put don't support the application that you want. > > In the example in section 4.6 there's no way of distinguishing that > description for CLUE vs BFCP vs anything else. Its not a CLUE data > channel is a generic data channel. > > Regards, Christian > > On 16/02/2014 1:03 AM, Christer Holmberg wrote: >> Hi, >> >> The draft submission deadline has passed, but I still wrote some more te= xt, shown below, for the SDP Offer/Answer Procedures section. >> >> Regards, >> >> Christer >> >> PS. Note that I will be on vacation next week, so I will once again do m= y best trying to stay away from e-mails :) >> >> ----------------------- >> >> 4. SDP Offer/Answer Procedures >> >> 4.1. General >> >> This section describes how the SDP media description ("m=3D") line = for >> a CLUE data channel is created, and how it is used in SDP offers an= d >> answers. >> >> NOTE: The proceudres associated with "m=3D" lines for other media t= ypes >> (e.g. audio and video) used in a CLUE session are outside the scope >> of this document. >> >> OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel >> Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpne= g] >> will be used with the CLUE data channel. >> >> NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be us= ed >> with the CLUE data channel, a new associated 'sub-protocol' value >> needs to be registered with IANA. >> >> 4.2. SDP Media Description Fields >> >> The field values of the "m=3D" line for the CLUE data channel are s= et >> as following: >> >> +----------------+----------------+------------------------+-------= ---------+ >> | media | port | proto | = fmt | >> +----------------+----------------+------------------------+-------= ---------+ >> | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP port | >> | | value | = | value | >> +----------------+----------------+------------------------+-------= --------+ >> >> Table 1: SDP "proto" field values >> >> 4.3. SDP sctpmap Attribute >> >> The field values of the SDP sctpmap attribute associated with the >> CLUE data channel "m=3D" are set as following: >> >> +---------------------+---------------------------+----------------= -------+---------+ >> | sctpmap-number | app | max-message-size = | stream | >> +---------------------+---------------------------+----------------= -------+---------+ >> | fmt value of | "webrtc-datachannel" | Implemenation |= "1" | >> | the "m=3D" line | | speci= fic | | >> +---------------------+---------------------------+----------------= -------+---------+ >> >> Table 2: SDP "proto" field values >> >> 4.4. SDP Offerer Procedures >> >> The procedures for the offerer follow the normal proceures defined = in >> [ref-to-3264]. >> >> When the offerer creates an offer, which contains an "m=3D" line fo= r a >> CLUE data channel, it assigns the field values to the "m=3D" line >> according to the procedures in Section 4.2. In addition, the offer= er >> MUST insert an SDP sctpmap attribute associated with the "m=3D" lin= e. >> >> In an offer, the offerer MUST NOT insert more than one "m=3D" line = for >> a CLUE data channel. >> >> NOTE: CLUE does not support the usage of multiple CLUE data channel= s. >> >> The offerer MUST NOT insert more than one SDP sctpmap attributes in >> an "m=3D" line for a CLUE data channel. >> >> If an offerer, in a subsequent offer, wants to disable the CLUE dat= a >> channel, it assigns a zero port value to the "m=3D" line associated >> with the CLUE data channel. The answerer MUST NOT insert an SDP >> sctpmap attribute associated with the "m=3D" line. >> >> 4.5. SDP Answerer Procedures >> >> The procedures for the answerer follow the normal proceures defined >> in [ref-to-3264]. >> >> If the answerer receives an offer, which contains an "m=3D" line fo= r a >> CLUE data channel, and the answerer accepts the "m=3D" line, it cre= ates >> and inserts an "m=3D" line in the associated answer. The answerer >> assigns the field values to the "m=3D" line according to the proced= ures >> in Section 4.2. >> >> If, in the offer, a zero port value has been assigned to the "m=3D" >> line for the CLUE channel, or it the answerer does not accept the >> "m=3D" line, but accepts other "m=3D" lines in the offer (i.e. the >> answerer will not reject the whole offer), it still inserts an "m= =3D" >> line for a CLUE data channel in the associated answer. The answere= r >> then assigns a zero port value to the "m=3D" line. The answerer MU= ST >> NOT insert an SDP sctpmap attribute associated with the "m=3D" line= . >> >> 4.6. Example >> >> m=3Dapplication 54111 SCTP/DTLS 54111 >> a=3Dsctpmap:54111 webrtc-datachannel max-message-size=3D100000= streams=3D1 >> >> Figure 1: SDP Media Description for a CLUE data channel >> >> _______________________________________________ >> 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 nobody Sun Feb 16 17:35:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147CD1A0294 for ; Sun, 16 Feb 2014 17:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_44=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4b5lENvV0kr for ; Sun, 16 Feb 2014 17:35:45 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA161A02C3 for ; Sun, 16 Feb 2014 17:35:44 -0800 (PST) Received: from ppp118-209-188-133.lns20.mel6.internode.on.net ([118.209.188.133]:53008 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFD4z-0003ct-Uy; Mon, 17 Feb 2014 12:33:06 +1100 Message-ID: <53016764.9050201@nteczone.com> Date: Mon, 17 Feb 2014 12:35:32 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/__d95CoBHy5smmt7A5u6GqPcOHs Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 01:35:48 -0000 Hello Christer, Please see below. Regards, Christian On 17/02/2014 12:11 PM, Christer Holmberg wrote: > Hi, > > If the offerer offers a data channel, AND also some way indicates support of CLUE, we can always specify that the offerer MUST be able to use the data channel for CLUE. The WebRTC data channel protocol can then be used to open the channel for CLUE. [CNG] I agree. I'm still uncomfortable with the way these drafts are layered. The SCTP draft allows the specification of "app"s that relate to the SCTP association as a means of negotiating what goes in the SCTP association. One of those "app"s may be the webrtc data channel. It has its own means of negotiating of what is in the SCTP association (i.e. Richard's draft). Both these methods are basically just indicating what will be in the SCTP streams. Rather than have two methods for negotiating what is in the SCTP association it almost seems better to have one method for negotiation of what apps there are and then to tag whether or not the webrtc data channel will be used to open it. e.g. m=application 54111 SCTP/DTLS 54111 a=sctpmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3; webrtc-datachannel-tag a=webrtc-datachannel:max-message-size=100000 streams=1 webrtc-datachannel-tag would take whether an "app" uses the webrtc data channel open protocol. a=webrtc-datachannel attribute would give the attributes of the protocol. > > But, never the less, it would probably be good to have an example showing how things would look like using Richard's draft, until we've decided whether we are going to use it or not. I'll add that. > > Regards, > > Christer > > Sent from my Sony Ericsson Xperia arc S > > Christian Groves wrote: > > > Hello Christer, > > I think that for the signaling we must specify a way of negotiating at > the SDP level whether CLUE is supported. I agree there's lots of ways it > could be done but we need to indicate which one/s CLUE should use. > > So for the SDP O/A procedures and example I think you have to assume the > use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say > its a CLUE data channel according to the SDP given. You're just opening > a generic channel, which may or may not be clue. Particularly in the > Answerer's case, it doesn't know that the Offer is going to use the > channel for CLUE. > > However: > m=application 54111 SCTP/DTLS 54111 > a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 > a=dcmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3 > > would unambiguously define it as a CLUE data channel. > > Regards, Christian > > On 17/02/2014 11:16 AM, Christer Holmberg wrote: >> Hi Christian, >> >> If you want to negotiate usage of CLUE (or, any other specific usage of a webrtc-datachannel) in SDP, one option is to use Richard's draft. The usage of that draft is listed as an open issue in the CLUE data channel draft. >> >> SIP also provides other mechanisms, e.g. media feature tags, for indicating support of features. >> >> Regards, >> >> Christer >> >> Sent from my Sony Ericsson Xperia arc S >> >> Christian Groves wrote: >> >> >> Hello Christer, >> >> With the use of webrtc-datachannel how do I negotiate via SDP whether I >> want to use clue or not? >> >> A SCTP association (and thus webrtc-datachannel) for example could be >> used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP >> association to figure out that the endpoints support webrtc-datachannel >> put don't support the application that you want. >> >> In the example in section 4.6 there's no way of distinguishing that >> description for CLUE vs BFCP vs anything else. Its not a CLUE data >> channel is a generic data channel. >> >> Regards, Christian >> >> On 16/02/2014 1:03 AM, Christer Holmberg wrote: >>> Hi, >>> >>> The draft submission deadline has passed, but I still wrote some more text, shown below, for the SDP Offer/Answer Procedures section. >>> >>> Regards, >>> >>> Christer >>> >>> PS. Note that I will be on vacation next week, so I will once again do my best trying to stay away from e-mails :) >>> >>> ----------------------- >>> >>> 4. SDP Offer/Answer Procedures >>> >>> 4.1. General >>> >>> This section describes how the SDP media description ("m=") line for >>> a CLUE data channel is created, and how it is used in SDP offers and >>> answers. >>> >>> NOTE: The proceudres associated with "m=" lines for other media types >>> (e.g. audio and video) used in a CLUE session are outside the scope >>> of this document. >>> >>> OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel >>> Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] >>> will be used with the CLUE data channel. >>> >>> NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be used >>> with the CLUE data channel, a new associated 'sub-protocol' value >>> needs to be registered with IANA. >>> >>> 4.2. SDP Media Description Fields >>> >>> The field values of the "m=" line for the CLUE data channel are set >>> as following: >>> >>> +----------------+----------------+------------------------+----------------+ >>> | media | port | proto | fmt | >>> +----------------+----------------+------------------------+----------------+ >>> | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP port | >>> | | value | | value | >>> +----------------+----------------+------------------------+---------------+ >>> >>> Table 1: SDP "proto" field values >>> >>> 4.3. SDP sctpmap Attribute >>> >>> The field values of the SDP sctpmap attribute associated with the >>> CLUE data channel "m=" are set as following: >>> >>> +---------------------+---------------------------+-----------------------+---------+ >>> | sctpmap-number | app | max-message-size | stream | >>> +---------------------+---------------------------+-----------------------+---------+ >>> | fmt value of | "webrtc-datachannel" | Implemenation | "1" | >>> | the "m=" line | | specific | | >>> +---------------------+---------------------------+-----------------------+---------+ >>> >>> Table 2: SDP "proto" field values >>> >>> 4.4. SDP Offerer Procedures >>> >>> The procedures for the offerer follow the normal proceures defined in >>> [ref-to-3264]. >>> >>> When the offerer creates an offer, which contains an "m=" line for a >>> CLUE data channel, it assigns the field values to the "m=" line >>> according to the procedures in Section 4.2. In addition, the offerer >>> MUST insert an SDP sctpmap attribute associated with the "m=" line. >>> >>> In an offer, the offerer MUST NOT insert more than one "m=" line for >>> a CLUE data channel. >>> >>> NOTE: CLUE does not support the usage of multiple CLUE data channels. >>> >>> The offerer MUST NOT insert more than one SDP sctpmap attributes in >>> an "m=" line for a CLUE data channel. >>> >>> If an offerer, in a subsequent offer, wants to disable the CLUE data >>> channel, it assigns a zero port value to the "m=" line associated >>> with the CLUE data channel. The answerer MUST NOT insert an SDP >>> sctpmap attribute associated with the "m=" line. >>> >>> 4.5. SDP Answerer Procedures >>> >>> The procedures for the answerer follow the normal proceures defined >>> in [ref-to-3264]. >>> >>> If the answerer receives an offer, which contains an "m=" line for a >>> CLUE data channel, and the answerer accepts the "m=" line, it creates >>> and inserts an "m=" line in the associated answer. The answerer >>> assigns the field values to the "m=" line according to the procedures >>> in Section 4.2. >>> >>> If, in the offer, a zero port value has been assigned to the "m=" >>> line for the CLUE channel, or it the answerer does not accept the >>> "m=" line, but accepts other "m=" lines in the offer (i.e. the >>> answerer will not reject the whole offer), it still inserts an "m=" >>> line for a CLUE data channel in the associated answer. The answerer >>> then assigns a zero port value to the "m=" line. The answerer MUST >>> NOT insert an SDP sctpmap attribute associated with the "m=" line. >>> >>> 4.6. Example >>> >>> m=application 54111 SCTP/DTLS 54111 >>> a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 >>> >>> Figure 1: SDP Media Description for a CLUE data channel >>> >>> _______________________________________________ >>> 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 nobody Sun Feb 16 19:36:07 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F8D1A032C for ; Sun, 16 Feb 2014 19:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4m4HxUYJcrH for ; Sun, 16 Feb 2014 19:36:05 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 08DEA1A0432 for ; Sun, 16 Feb 2014 19:36:04 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id TEth1n0031GhbT851Fc2u8; Mon, 17 Feb 2014 03:36:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id TFc11n00s3ZTu2S3TFc29E; Mon, 17 Feb 2014 03:36:02 +0000 Message-ID: <530183A1.5060604@alum.mit.edu> Date: Sun, 16 Feb 2014 22:36:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: CLUE References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D18D51B@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=1392608162; bh=pZwctrWck9ey8QVTYWqKLnzgCD6SzdtR7NYOnRIsHco=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MQ6zB4FKahfHrkyKkUL8NqkACi2bbGfnB79ZZiQRIsVNObbHEtc5cV+KXcxw1Nb7o TD395lYQxCwJ+EQ8Jp6HXAbvEkRhJE3xuvkdC67QxIW0t69v94lYX2ve/p6/G7gm4Q hCNr2UYJD1aFM1q8XDDdkto9SqkQ+q0Pnjz8R86chQO4cL/Qd0nAmMHJHSjMFhQq+R rMuHh7ZeIBt9SrEad6u65U8R6IIh9b1WSv+KEjxk3RLQ56fFcSQpfjynqFD1a8VJ1v /WlizYfHV3GmYRt8fEBJrIbG3PDkfI/Ju7JVZBs50akY/NJjCTknkJJviQZfk+KmUa 6DcHCUbW3Q5Mw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/hJc8XYUYvLXWCUq7l37s_NYP5Yk Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 03:36:07 -0000 Christer, inline On 2/15/14 9:03 AM, Christer Holmberg wrote: > > Hi, > > The draft submission deadline has passed, but I still wrote some more text, shown below, for the SDP Offer/Answer Procedures section. > > Regards, > > Christer > > PS. Note that I will be on vacation next week, so I will once again do my best trying to stay away from e-mails :) > > ----------------------- > > 4. SDP Offer/Answer Procedures > > 4.1. General > > This section describes how the SDP media description ("m=") line for > a CLUE data channel is created, and how it is used in SDP offers and > answers. > > NOTE: The proceudres associated with "m=" lines for other media types > (e.g. audio and video) used in a CLUE session are outside the scope > of this document. > > OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel > Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] > will be used with the CLUE data channel. > > NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be used > with the CLUE data channel, a new associated 'sub-protocol' value > needs to be registered with IANA. > > 4.2. SDP Media Description Fields > > The field values of the "m=" line for the CLUE data channel are set > as following: > > +----------------+----------------+------------------------+----------------+ > | media | port| proto | fmt | > +----------------+----------------+------------------------+----------------+ > | "application" | DTLS port | "UDP/TLS/UDPTL" | SCTP port | > | | value | | value | > +----------------+----------------+------------------------+----------------+ > > Table 1: SDP "proto" field values Note: AFAIK it doesn't matter what value is used for SCTP port number. (Or does rtcweb require a particular value?) *In principle* there should be no reason why there couldn't be more than one SCTP Port Value, though only one would be used for CLUE. IMO we should follow rtcweb on this. > 4.3. SDP sctpmap Attribute > > The field values of the SDP sctpmap attribute associated with the > CLUE data channel "m=" are set as following: > > +---------------------+---------------------------+-----------------------+---------+ > | sctpmap-number | app | max-message-size | stream | > +---------------------+---------------------------+-----------------------+---------+ > | fmt value of | "webrtc-datachannel" | Implemenation | "1" | > | the "m=" line | | specific | | > +---------------------+---------------------------+-----------------------+---------+ I don't think we should specify "1" be used for stream. That means that the CLUE stream would be the *only* stream - preventing use of the association for anything else. > Table 2: SDP "proto" field values > > 4.4. SDP Offerer Procedures > > The procedures for the offerer follow the normal proceures defined in > [ref-to-3264]. > > When the offerer creates an offer, which contains an "m=" line for a > CLUE data channel, it assigns the field values to the "m=" line > according to the procedures in Section 4.2. In addition, the offerer > MUST insert an SDP sctpmap attribute associated with the "m=" line. > > In an offer, the offerer MUST NOT insert more than one "m=" line for > a CLUE data channel. The m-line isn't solely for a CLUE data channel. I see no reason to forbid more than one SCTP m-line. All we need to do is specify which one is used for the CLUE channel if there is more than one. Again I think we can follow rtcweb on this. (I don't know if it forbids more than one.) > NOTE: CLUE does not support the usage of multiple CLUE data channels. Agreed. But we didn't get to the part that actually specifies the clue channel. > The offerer MUST NOT insert more than one SDP sctpmap attributes in > an "m=" line for a CLUE data channel. Same comment as above. If there were multiple SCTP ports then there would be multiple sctmap attributes. > If an offerer, in a subsequent offer, wants to disable the CLUE data > channel, it assigns a zero port value to the "m=" line associated > with the CLUE data channel. The answerer MUST NOT insert an SDP > sctpmap attribute associated with the "m=" line. The mechanics specified here are ok, but the reason for them is not. While this would *work*, by preventing the association that is needed for the clue channel, it is too extreme to require as the only way to indicate lack of desire for CLUE. (Might just want to use the SCTP for something else.) Thanks, Paul > 4.5. SDP Answerer Procedures > > The procedures for the answerer follow the normal proceures defined > in [ref-to-3264]. > > If the answerer receives an offer, which contains an "m=" line for a > CLUE data channel, and the answerer accepts the "m=" line, it creates > and inserts an "m=" line in the associated answer. The answerer > assigns the field values to the "m=" line according to the procedures > in Section 4.2. > > If, in the offer, a zero port value has been assigned to the "m=" > line for the CLUE channel, or it the answerer does not accept the > "m=" line, but accepts other "m=" lines in the offer (i.e. the > answerer will not reject the whole offer), it still inserts an "m=" > line for a CLUE data channel in the associated answer. The answerer > then assigns a zero port value to the "m=" line. The answerer MUST > NOT insert an SDP sctpmap attribute associated with the "m=" line. > > 4.6. Example > > m=application 54111 SCTP/DTLS 54111 > a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 > > Figure 1: SDP Media Description for a CLUE data channel > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Feb 16 19:39:24 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E131A0432 for ; Sun, 16 Feb 2014 19:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_44=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6970KCPN_vJ for ; Sun, 16 Feb 2014 19:39:20 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2BA1A042E for ; Sun, 16 Feb 2014 19:39:20 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id TErX1n00317dt5G5DFfH2y; Mon, 17 Feb 2014 03:39:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id TFfH1n00H3ZTu2S3ZFfHQA; Mon, 17 Feb 2014 03:39:17 +0000 Message-ID: <53018465.8090108@alum.mit.edu> Date: Sun, 16 Feb 2014 22:39:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com> <53015E29.2000102@nteczone.com> In-Reply-To: <53015E29.2000102@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=1392608357; bh=enNqmkDTmNiPl+I8sY/qzwbx6yVaLbXcbUOCH0Sf1wI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YfjLoR7DU8fFIoxPLq/LFZPIBIZ+C1TfYfXBpRucuxytDy7B9aUE4llHe8E9pcg/O Ro3uhTZpYYcSgSvO0LYEECKpLRoBpQqg3hnKDaWlKtr5qldIYGqieGr5UH0YrFjTDD TUtvO931jCkHfrGBNSTWZH1EGKlLnD5thY5eSNY9lPGq91paMMK7SAAULTn/ovQWSl dr9NAB9zBh0/IMZWUa5LiyFMjarzCI1hSARZcXdz1qig99es6Bc/OQcY/rM+zKicij bH/9teoYNRagSOYM9ivg+TROZnPUO16/jZwMyLkF8eKJU+Vj4F7vEO2WBSERBXEqi4 QrcFTH3Wo+wUg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/by2yRmBjyzXW9pwaBg7Hso6pJHs Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 03:39:23 -0000 Inline On 2/16/14 7:56 PM, Christian Groves wrote: > Hello Christer, > > I think that for the signaling we must specify a way of negotiating at > the SDP level or SIP level!!! > whether CLUE is supported. I agree there's lots of ways it > could be done but we need to indicate which one/s CLUE should use. > > So for the SDP O/A procedures and example I think you have to assume the > use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say > its a CLUE data channel according to the SDP given. You're just opening > a generic channel, which may or may not be clue. Particularly in the > Answerer's case, it doesn't know that the Offer is going to use the > channel for CLUE. > > However: > m=application 54111 SCTP/DTLS 54111 > a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 > a=dcmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3 > > would unambiguously define it as a CLUE data channel. Yes. That is one way. Another way is to signal CLUE support in SIP (e.g., feature tag), and then open the actual channel dynamically using the rtcweb data channel protocol. Thanks, Paul > Regards, Christian > > On 17/02/2014 11:16 AM, Christer Holmberg wrote: >> Hi Christian, >> >> If you want to negotiate usage of CLUE (or, any other specific usage >> of a webrtc-datachannel) in SDP, one option is to use Richard's draft. >> The usage of that draft is listed as an open issue in the CLUE data >> channel draft. >> >> SIP also provides other mechanisms, e.g. media feature tags, for >> indicating support of features. >> >> Regards, >> >> Christer >> >> Sent from my Sony Ericsson Xperia arc S >> >> Christian Groves wrote: >> >> >> Hello Christer, >> >> With the use of webrtc-datachannel how do I negotiate via SDP whether I >> want to use clue or not? >> >> A SCTP association (and thus webrtc-datachannel) for example could be >> used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP >> association to figure out that the endpoints support webrtc-datachannel >> put don't support the application that you want. >> >> In the example in section 4.6 there's no way of distinguishing that >> description for CLUE vs BFCP vs anything else. Its not a CLUE data >> channel is a generic data channel. >> >> Regards, Christian >> >> On 16/02/2014 1:03 AM, Christer Holmberg wrote: >>> Hi, >>> >>> The draft submission deadline has passed, but I still wrote some more >>> text, shown below, for the SDP Offer/Answer Procedures section. >>> >>> Regards, >>> >>> Christer >>> >>> PS. Note that I will be on vacation next week, so I will once again >>> do my best trying to stay away from e-mails :) >>> >>> ----------------------- >>> >>> 4. SDP Offer/Answer Procedures >>> >>> 4.1. General >>> >>> This section describes how the SDP media description ("m=") line >>> for >>> a CLUE data channel is created, and how it is used in SDP offers >>> and >>> answers. >>> >>> NOTE: The proceudres associated with "m=" lines for other media >>> types >>> (e.g. audio and video) used in a CLUE session are outside the scope >>> of this document. >>> >>> OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel >>> Negotiation mechanism >>> [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] >>> will be used with the CLUE data channel. >>> >>> NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be >>> used >>> with the CLUE data channel, a new associated 'sub-protocol' value >>> needs to be registered with IANA. >>> >>> 4.2. SDP Media Description Fields >>> >>> The field values of the "m=" line for the CLUE data channel are set >>> as following: >>> >>> >>> +----------------+----------------+------------------------+----------------+ >>> >>> | media | port | proto >>> | fmt | >>> >>> +----------------+----------------+------------------------+----------------+ >>> >>> | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP port | >>> | | value >>> | | value | >>> >>> +----------------+----------------+------------------------+---------------+ >>> >>> >>> Table 1: SDP "proto" field values >>> >>> 4.3. SDP sctpmap Attribute >>> >>> The field values of the SDP sctpmap attribute associated with the >>> CLUE data channel "m=" are set as following: >>> >>> >>> +---------------------+---------------------------+-----------------------+---------+ >>> >>> | sctpmap-number | app | >>> max-message-size | stream | >>> >>> +---------------------+---------------------------+-----------------------+---------+ >>> >>> | fmt value of | "webrtc-datachannel" | >>> Implemenation | "1" | >>> | the "m=" line | | >>> specific | | >>> >>> +---------------------+---------------------------+-----------------------+---------+ >>> >>> >>> Table 2: SDP "proto" field values >>> >>> 4.4. SDP Offerer Procedures >>> >>> The procedures for the offerer follow the normal proceures >>> defined in >>> [ref-to-3264]. >>> >>> When the offerer creates an offer, which contains an "m=" line >>> for a >>> CLUE data channel, it assigns the field values to the "m=" line >>> according to the procedures in Section 4.2. In addition, the >>> offerer >>> MUST insert an SDP sctpmap attribute associated with the "m=" line. >>> >>> In an offer, the offerer MUST NOT insert more than one "m=" line >>> for >>> a CLUE data channel. >>> >>> NOTE: CLUE does not support the usage of multiple CLUE data >>> channels. >>> >>> The offerer MUST NOT insert more than one SDP sctpmap attributes in >>> an "m=" line for a CLUE data channel. >>> >>> If an offerer, in a subsequent offer, wants to disable the CLUE >>> data >>> channel, it assigns a zero port value to the "m=" line associated >>> with the CLUE data channel. The answerer MUST NOT insert an SDP >>> sctpmap attribute associated with the "m=" line. >>> >>> 4.5. SDP Answerer Procedures >>> >>> The procedures for the answerer follow the normal proceures defined >>> in [ref-to-3264]. >>> >>> If the answerer receives an offer, which contains an "m=" line >>> for a >>> CLUE data channel, and the answerer accepts the "m=" line, it >>> creates >>> and inserts an "m=" line in the associated answer. The answerer >>> assigns the field values to the "m=" line according to the >>> procedures >>> in Section 4.2. >>> >>> If, in the offer, a zero port value has been assigned to the "m=" >>> line for the CLUE channel, or it the answerer does not accept the >>> "m=" line, but accepts other "m=" lines in the offer (i.e. the >>> answerer will not reject the whole offer), it still inserts an "m=" >>> line for a CLUE data channel in the associated answer. The >>> answerer >>> then assigns a zero port value to the "m=" line. The answerer MUST >>> NOT insert an SDP sctpmap attribute associated with the "m=" line. >>> >>> 4.6. Example >>> >>> m=application 54111 SCTP/DTLS 54111 >>> a=sctpmap:54111 webrtc-datachannel max-message-size=100000 >>> streams=1 >>> >>> Figure 1: SDP Media Description for a CLUE data channel >>> >>> _______________________________________________ >>> 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 nobody Sun Feb 16 20:09:19 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA421A031F for ; Sun, 16 Feb 2014 20:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_44=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcC_m8BLJjJQ for ; Sun, 16 Feb 2014 20:09:15 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 66CE41A0031 for ; Sun, 16 Feb 2014 20:09:15 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta14.westchester.pa.mail.comcast.net with comcast id TG4M1n0010vyq2s5EG9CGw; Mon, 17 Feb 2014 04:09:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id TG9C1n0093ZTu2S3RG9CaM; Mon, 17 Feb 2014 04:09:12 +0000 Message-ID: <53018B68.2080209@alum.mit.edu> Date: Sun, 16 Feb 2014 23:09:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> <53016764.9050201@nteczone.com> In-Reply-To: <53016764.9050201@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=1392610152; bh=QaLdF2U3csyc+99qGNWz7iwTgDK93dNFZDG+KVZCuA8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AxxAi7KdeVQKSDycv4gFzAu7y6oSPlJPTfo7bBN4hjK7b5X3rdiiqOMbI5MzBXEdW i/2cXhuDppbmOqBzGP/EaiYOKFg3944cbfZZFTEaAL9wcJ2pYQQ0P0QUjTVoc2DlYb oQEq7joJdGyJ9yNyqKyxiNq4hepbrKk+cSydlwPP5B/aLhTz3Nknc1MMbTHutYLcQ6 jcSCXs+M9wHUK4hjKXbfY1hjRWWv4fJNUnyC0t9B+toD0LH5086iT7DYkC3IP3LDK0 08EQqMvnJusk3cER2NYbTc2bfSQLgX4iKSfljYR3cym9DGWRU3aG3DZx6o+u3MIRwH Fy/SCn2RrczQA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6HKu9EwWWUu1uV44ZenA_AQhUY0 Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 04:09:18 -0000 On 2/16/14 8:35 PM, Christian Groves wrote: > Hello Christer, > > Please see below. > > Regards, Christian > > On 17/02/2014 12:11 PM, Christer Holmberg wrote: >> Hi, >> >> If the offerer offers a data channel, AND also some way indicates >> support of CLUE, we can always specify that the offerer MUST be able >> to use the data channel for CLUE. The WebRTC data channel protocol can >> then be used to open the channel for CLUE. > [CNG] I agree. > > I'm still uncomfortable with the way these drafts are layered. I'm troubled too, but maybe not exactly the same way you are. IMO it isn't that the layering is so wrong. Rather it is that the terminology used is confusing. > The SCTP > draft allows the specification of "app"s that relate to the SCTP > association as a means of negotiating what goes in the SCTP association. > One of those "app"s may be the webrtc data channel. It has its own means > of negotiating of what is in the SCTP association (i.e. Richard's > draft). I agree with your interpretation here. That doesn't mean the layering is wrong - just the terminology. The use of a=sctpmap is clearly intended as an analog to a=rtpmap. But in reality its purpose is not at all analogous to a=rtpmap. So the name confuses. And that mis-analogy is continued, by language that says sctpmap is defining a mapping from a port number to a payload format. Again, that is not what it is doing. (If it were, then you would be restricted to one payload format for all the streams on the association.) AFAICT, the name you are giving in sctpmap describes some sort of "convention" for how all the streams in the association are to be managed and used. E.g., "webrtc-datachannel" says that the streams will be managed in pairs, as channels, and that webrtc data channel protocol may be used to dynamically assign channels. (That is the same conclusion you have reached.) IMO a lot of the language should be changed to be less confusing. > Both these methods are basically just indicating what will be in > the SCTP streams. Both? Which? The only thing that actually says, in SDP, what will be in the individual SCTP streams is Richard's draft. > Rather than have two methods for negotiating what is > in the SCTP association it almost seems better to have one method for > negotiation of what apps there are and then to tag whether or not the > webrtc data channel will be used to open it. > > e.g. > > m=application 54111 SCTP/DTLS 54111 > a=sctpmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3; > webrtc-datachannel-tag > a=webrtc-datachannel:max-message-size=100000 streams=1 > > webrtc-datachannel-tag would take whether an "app" uses the webrtc data > channel open protocol. > a=webrtc-datachannel attribute would give the attributes of the protocol. There are problems with this - not for CLUE, but for webrtc, or anything that doesn't want to use O/A to define every channel. The webrtc data channel open protocol does not take a stream ID as an argument. It internally assigns stream IDs. Rtcweb has specified how you can use preassigned channels without the open, but then it isn't using the data channel protocol. IMO, from an mmusic perspective, we need to support both the static and dynamic assignment of channels. We just want it to be done more clearly. From a CLUE perspective, we need to decide if we want to use the static or dynamic assignment. IMO the preferred choice is not obvious - both have their attractions. At the moment I am *slightly* preferring the dynamic. Thanks, Paul >> >> But, never the less, it would probably be good to have an example >> showing how things would look like using Richard's draft, until we've >> decided whether we are going to use it or not. I'll add that. >> >> Regards, >> >> Christer >> >> Sent from my Sony Ericsson Xperia arc S >> >> Christian Groves wrote: >> >> >> Hello Christer, >> >> I think that for the signaling we must specify a way of negotiating at >> the SDP level whether CLUE is supported. I agree there's lots of ways it >> could be done but we need to indicate which one/s CLUE should use. >> >> So for the SDP O/A procedures and example I think you have to assume the >> use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say >> its a CLUE data channel according to the SDP given. You're just opening >> a generic channel, which may or may not be clue. Particularly in the >> Answerer's case, it doesn't know that the Offer is going to use the >> channel for CLUE. >> >> However: >> m=application 54111 SCTP/DTLS 54111 >> a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 >> a=dcmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3 >> >> would unambiguously define it as a CLUE data channel. >> >> Regards, Christian >> >> On 17/02/2014 11:16 AM, Christer Holmberg wrote: >>> Hi Christian, >>> >>> If you want to negotiate usage of CLUE (or, any other specific usage >>> of a webrtc-datachannel) in SDP, one option is to use Richard's >>> draft. The usage of that draft is listed as an open issue in the CLUE >>> data channel draft. >>> >>> SIP also provides other mechanisms, e.g. media feature tags, for >>> indicating support of features. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Sony Ericsson Xperia arc S >>> >>> Christian Groves wrote: >>> >>> >>> Hello Christer, >>> >>> With the use of webrtc-datachannel how do I negotiate via SDP whether I >>> want to use clue or not? >>> >>> A SCTP association (and thus webrtc-datachannel) for example could be >>> used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP >>> association to figure out that the endpoints support webrtc-datachannel >>> put don't support the application that you want. >>> >>> In the example in section 4.6 there's no way of distinguishing that >>> description for CLUE vs BFCP vs anything else. Its not a CLUE data >>> channel is a generic data channel. >>> >>> Regards, Christian >>> >>> On 16/02/2014 1:03 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> The draft submission deadline has passed, but I still wrote some >>>> more text, shown below, for the SDP Offer/Answer Procedures section. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> PS. Note that I will be on vacation next week, so I will once again >>>> do my best trying to stay away from e-mails :) >>>> >>>> ----------------------- >>>> >>>> 4. SDP Offer/Answer Procedures >>>> >>>> 4.1. General >>>> >>>> This section describes how the SDP media description ("m=") >>>> line for >>>> a CLUE data channel is created, and how it is used in SDP >>>> offers and >>>> answers. >>>> >>>> NOTE: The proceudres associated with "m=" lines for other >>>> media types >>>> (e.g. audio and video) used in a CLUE session are outside the >>>> scope >>>> of this document. >>>> >>>> OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data >>>> Channel >>>> Negotiation mechanism >>>> [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] >>>> will be used with the CLUE data channel. >>>> >>>> NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will >>>> be used >>>> with the CLUE data channel, a new associated 'sub-protocol' value >>>> needs to be registered with IANA. >>>> >>>> 4.2. SDP Media Description Fields >>>> >>>> The field values of the "m=" line for the CLUE data channel >>>> are set >>>> as following: >>>> >>>> >>>> +----------------+----------------+------------------------+----------------+ >>>> >>>> | media | port | >>>> proto | fmt | >>>> >>>> +----------------+----------------+------------------------+----------------+ >>>> >>>> | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP >>>> port | >>>> | | value >>>> | | value | >>>> >>>> +----------------+----------------+------------------------+---------------+ >>>> >>>> >>>> Table 1: SDP "proto" field values >>>> >>>> 4.3. SDP sctpmap Attribute >>>> >>>> The field values of the SDP sctpmap attribute associated with the >>>> CLUE data channel "m=" are set as following: >>>> >>>> >>>> +---------------------+---------------------------+-----------------------+---------+ >>>> >>>> | sctpmap-number | app | >>>> max-message-size | stream | >>>> >>>> +---------------------+---------------------------+-----------------------+---------+ >>>> >>>> | fmt value of | "webrtc-datachannel" | >>>> Implemenation | "1" | >>>> | the "m=" line | | >>>> specific | | >>>> >>>> +---------------------+---------------------------+-----------------------+---------+ >>>> >>>> >>>> Table 2: SDP "proto" field values >>>> >>>> 4.4. SDP Offerer Procedures >>>> >>>> The procedures for the offerer follow the normal proceures >>>> defined in >>>> [ref-to-3264]. >>>> >>>> When the offerer creates an offer, which contains an "m=" line >>>> for a >>>> CLUE data channel, it assigns the field values to the "m=" line >>>> according to the procedures in Section 4.2. In addition, the >>>> offerer >>>> MUST insert an SDP sctpmap attribute associated with the "m=" >>>> line. >>>> >>>> In an offer, the offerer MUST NOT insert more than one "m=" >>>> line for >>>> a CLUE data channel. >>>> >>>> NOTE: CLUE does not support the usage of multiple CLUE data >>>> channels. >>>> >>>> The offerer MUST NOT insert more than one SDP sctpmap >>>> attributes in >>>> an "m=" line for a CLUE data channel. >>>> >>>> If an offerer, in a subsequent offer, wants to disable the >>>> CLUE data >>>> channel, it assigns a zero port value to the "m=" line associated >>>> with the CLUE data channel. The answerer MUST NOT insert an SDP >>>> sctpmap attribute associated with the "m=" line. >>>> >>>> 4.5. SDP Answerer Procedures >>>> >>>> The procedures for the answerer follow the normal proceures >>>> defined >>>> in [ref-to-3264]. >>>> >>>> If the answerer receives an offer, which contains an "m=" line >>>> for a >>>> CLUE data channel, and the answerer accepts the "m=" line, it >>>> creates >>>> and inserts an "m=" line in the associated answer. The answerer >>>> assigns the field values to the "m=" line according to the >>>> procedures >>>> in Section 4.2. >>>> >>>> If, in the offer, a zero port value has been assigned to the "m=" >>>> line for the CLUE channel, or it the answerer does not accept the >>>> "m=" line, but accepts other "m=" lines in the offer (i.e. the >>>> answerer will not reject the whole offer), it still inserts an >>>> "m=" >>>> line for a CLUE data channel in the associated answer. The >>>> answerer >>>> then assigns a zero port value to the "m=" line. The answerer >>>> MUST >>>> NOT insert an SDP sctpmap attribute associated with the "m=" >>>> line. >>>> >>>> 4.6. Example >>>> >>>> m=application 54111 SCTP/DTLS 54111 >>>> a=sctpmap:54111 webrtc-datachannel >>>> max-message-size=100000 streams=1 >>>> >>>> Figure 1: SDP Media Description for a CLUE data channel >>>> >>>> _______________________________________________ >>>> 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 nobody Sun Feb 16 21:07:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7108B1A0358 for ; Sun, 16 Feb 2014 21:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_44=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhPV5EGT4IYf for ; Sun, 16 Feb 2014 21:07:13 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230C91A0353 for ; Sun, 16 Feb 2014 21:07:12 -0800 (PST) Received: from ppp118-209-188-133.lns20.mel6.internode.on.net ([118.209.188.133]:56532 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFGNb-00050x-JX for clue@ietf.org; Mon, 17 Feb 2014 16:04:31 +1100 Message-ID: <530198FB.9000905@nteczone.com> Date: Mon, 17 Feb 2014 16:07:07 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> <53016764.9050201@nteczone.com> <53018B68.2080209@alum.mit.edu> In-Reply-To: <53018B68.2080209@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/oHPS7GNkNpcA0xUXLehxp57AhLE Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 05:07:38 -0000 Hello Paul, On 17/02/2014 3:09 PM, Paul Kyzivat wrote: > On 2/16/14 8:35 PM, Christian Groves wrote: >> Hello Christer, >> >> Please see below. >> >> Regards, Christian >> >> On 17/02/2014 12:11 PM, Christer Holmberg wrote: >>> Hi, >>> >>> If the offerer offers a data channel, AND also some way indicates >>> support of CLUE, we can always specify that the offerer MUST be able >>> to use the data channel for CLUE. The WebRTC data channel protocol can >>> then be used to open the channel for CLUE. >> [CNG] I agree. >> >> I'm still uncomfortable with the way these drafts are layered. > > I'm troubled too, but maybe not exactly the same way you are. > IMO it isn't that the layering is so wrong. Rather it is that the > terminology used is confusing. [CNG] Yes the terminology isn't helping either. > >> The SCTP >> draft allows the specification of "app"s that relate to the SCTP >> association as a means of negotiating what goes in the SCTP association. >> One of those "app"s may be the webrtc data channel. It has its own means >> of negotiating of what is in the SCTP association (i.e. Richard's >> draft). > > I agree with your interpretation here. That doesn't mean the layering > is wrong - just the terminology. > > The use of a=sctpmap is clearly intended as an analog to a=rtpmap. But > in reality its purpose is not at all analogous to a=rtpmap. So the > name confuses. > > And that mis-analogy is continued, by language that says sctpmap is > defining a mapping from a port number to a payload format. Again, that > is not what it is doing. (If it were, then you would be restricted to > one payload format for all the streams on the association.) AFAICT, > the name you are giving in sctpmap describes some sort of "convention" > for how all the streams in the association are to be managed and used. > E.g., "webrtc-datachannel" says that the streams will be managed in > pairs, as channels, and that webrtc data channel protocol may be used > to dynamically assign channels. (That is the same conclusion you have > reached.) > > IMO a lot of the language should be changed to be less confusing. > >> Both these methods are basically just indicating what will be in >> the SCTP streams. > > Both? Which? The only thing that actually says, in SDP, what will be > in the individual SCTP streams is Richard's draft. [CNG] The SCTP draft does say which "apps" will be in the association. That what I mean by "what's in the streams" in the general sense. > >> Rather than have two methods for negotiating what is >> in the SCTP association it almost seems better to have one method for >> negotiation of what apps there are and then to tag whether or not the >> webrtc data channel will be used to open it. >> >> e.g. >> >> m=application 54111 SCTP/DTLS 54111 >> a=sctpmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3; >> webrtc-datachannel-tag >> a=webrtc-datachannel:max-message-size=100000 streams=1 >> >> webrtc-datachannel-tag would take whether an "app" uses the webrtc data >> channel open protocol. >> a=webrtc-datachannel attribute would give the attributes of the >> protocol. > > There are problems with this - not for CLUE, but for webrtc, or > anything that doesn't want to use O/A to define every channel. > > The webrtc data channel open protocol does not take a stream ID as an > argument. It internally assigns stream IDs. Rtcweb has specified how > you can use preassigned channels without the open, but then it isn't > using the data channel protocol. [CNG] I just threw something together here without much thought. So for the case where the streamID isn't specified "data channel protocol" could be the value to indicate that it is used? > > IMO, from an mmusic perspective, we need to support both the static > and dynamic assignment of channels. We just want it to be done more > clearly. [CNG] Perhaps this is key, for a particular app in a SCTP association we need to say whether or not the streamID assignment is static or dynamic via the data channel protocol". > > From a CLUE perspective, we need to decide if we want to use the > static or dynamic assignment. IMO the preferred choice is not obvious > - both have their attractions. At the moment I am *slightly* > preferring the dynamic. [CNG] Dynamic is probably OK so long as we have some sort of label mechanism to help sort out mapping when you have multiple instances of the same app. > > Thanks, > Paul > >>> >>> But, never the less, it would probably be good to have an example >>> showing how things would look like using Richard's draft, until we've >>> decided whether we are going to use it or not. I'll add that. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Sony Ericsson Xperia arc S >>> >>> Christian Groves wrote: >>> >>> >>> Hello Christer, >>> >>> I think that for the signaling we must specify a way of negotiating at >>> the SDP level whether CLUE is supported. I agree there's lots of >>> ways it >>> could be done but we need to indicate which one/s CLUE should use. >>> >>> So for the SDP O/A procedures and example I think you have to assume >>> the >>> use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say >>> its a CLUE data channel according to the SDP given. You're just opening >>> a generic channel, which may or may not be clue. Particularly in the >>> Answerer's case, it doesn't know that the Offer is going to use the >>> channel for CLUE. >>> >>> However: >>> m=application 54111 SCTP/DTLS 54111 >>> a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 >>> a=dcmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3 >>> >>> would unambiguously define it as a CLUE data channel. >>> >>> Regards, Christian >>> >>> On 17/02/2014 11:16 AM, Christer Holmberg wrote: >>>> Hi Christian, >>>> >>>> If you want to negotiate usage of CLUE (or, any other specific usage >>>> of a webrtc-datachannel) in SDP, one option is to use Richard's >>>> draft. The usage of that draft is listed as an open issue in the CLUE >>>> data channel draft. >>>> >>>> SIP also provides other mechanisms, e.g. media feature tags, for >>>> indicating support of features. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> Sent from my Sony Ericsson Xperia arc S >>>> >>>> Christian Groves wrote: >>>> >>>> >>>> Hello Christer, >>>> >>>> With the use of webrtc-datachannel how do I negotiate via SDP >>>> whether I >>>> want to use clue or not? >>>> >>>> A SCTP association (and thus webrtc-datachannel) for example could be >>>> used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP >>>> association to figure out that the endpoints support >>>> webrtc-datachannel >>>> put don't support the application that you want. >>>> >>>> In the example in section 4.6 there's no way of distinguishing that >>>> description for CLUE vs BFCP vs anything else. Its not a CLUE data >>>> channel is a generic data channel. >>>> >>>> Regards, Christian >>>> >>>> On 16/02/2014 1:03 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> The draft submission deadline has passed, but I still wrote some >>>>> more text, shown below, for the SDP Offer/Answer Procedures section. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> PS. Note that I will be on vacation next week, so I will once again >>>>> do my best trying to stay away from e-mails :) >>>>> >>>>> ----------------------- >>>>> >>>>> 4. SDP Offer/Answer Procedures >>>>> >>>>> 4.1. General >>>>> >>>>> This section describes how the SDP media description ("m=") >>>>> line for >>>>> a CLUE data channel is created, and how it is used in SDP >>>>> offers and >>>>> answers. >>>>> >>>>> NOTE: The proceudres associated with "m=" lines for other >>>>> media types >>>>> (e.g. audio and video) used in a CLUE session are outside the >>>>> scope >>>>> of this document. >>>>> >>>>> OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data >>>>> Channel >>>>> Negotiation mechanism >>>>> [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] >>>>> will be used with the CLUE data channel. >>>>> >>>>> NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will >>>>> be used >>>>> with the CLUE data channel, a new associated 'sub-protocol' >>>>> value >>>>> needs to be registered with IANA. >>>>> >>>>> 4.2. SDP Media Description Fields >>>>> >>>>> The field values of the "m=" line for the CLUE data channel >>>>> are set >>>>> as following: >>>>> >>>>> >>>>> +----------------+----------------+------------------------+----------------+ >>>>> >>>>> >>>>> | media | port | >>>>> proto | fmt | >>>>> >>>>> +----------------+----------------+------------------------+----------------+ >>>>> >>>>> >>>>> | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP >>>>> port | >>>>> | | value >>>>> | | value | >>>>> >>>>> +----------------+----------------+------------------------+---------------+ >>>>> >>>>> >>>>> >>>>> Table 1: SDP "proto" field values >>>>> >>>>> 4.3. SDP sctpmap Attribute >>>>> >>>>> The field values of the SDP sctpmap attribute associated >>>>> with the >>>>> CLUE data channel "m=" are set as following: >>>>> >>>>> >>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>> >>>>> >>>>> | sctpmap-number | app | >>>>> max-message-size | stream | >>>>> >>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>> >>>>> >>>>> | fmt value of | "webrtc-datachannel" | >>>>> Implemenation | "1" | >>>>> | the "m=" line | | >>>>> specific | | >>>>> >>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>> >>>>> >>>>> >>>>> Table 2: SDP "proto" field values >>>>> >>>>> 4.4. SDP Offerer Procedures >>>>> >>>>> The procedures for the offerer follow the normal proceures >>>>> defined in >>>>> [ref-to-3264]. >>>>> >>>>> When the offerer creates an offer, which contains an "m=" line >>>>> for a >>>>> CLUE data channel, it assigns the field values to the "m=" line >>>>> according to the procedures in Section 4.2. In addition, the >>>>> offerer >>>>> MUST insert an SDP sctpmap attribute associated with the "m=" >>>>> line. >>>>> >>>>> In an offer, the offerer MUST NOT insert more than one "m=" >>>>> line for >>>>> a CLUE data channel. >>>>> >>>>> NOTE: CLUE does not support the usage of multiple CLUE data >>>>> channels. >>>>> >>>>> The offerer MUST NOT insert more than one SDP sctpmap >>>>> attributes in >>>>> an "m=" line for a CLUE data channel. >>>>> >>>>> If an offerer, in a subsequent offer, wants to disable the >>>>> CLUE data >>>>> channel, it assigns a zero port value to the "m=" line >>>>> associated >>>>> with the CLUE data channel. The answerer MUST NOT insert an >>>>> SDP >>>>> sctpmap attribute associated with the "m=" line. >>>>> >>>>> 4.5. SDP Answerer Procedures >>>>> >>>>> The procedures for the answerer follow the normal proceures >>>>> defined >>>>> in [ref-to-3264]. >>>>> >>>>> If the answerer receives an offer, which contains an "m=" line >>>>> for a >>>>> CLUE data channel, and the answerer accepts the "m=" line, it >>>>> creates >>>>> and inserts an "m=" line in the associated answer. The answerer >>>>> assigns the field values to the "m=" line according to the >>>>> procedures >>>>> in Section 4.2. >>>>> >>>>> If, in the offer, a zero port value has been assigned to the >>>>> "m=" >>>>> line for the CLUE channel, or it the answerer does not >>>>> accept the >>>>> "m=" line, but accepts other "m=" lines in the offer (i.e. the >>>>> answerer will not reject the whole offer), it still inserts an >>>>> "m=" >>>>> line for a CLUE data channel in the associated answer. The >>>>> answerer >>>>> then assigns a zero port value to the "m=" line. The answerer >>>>> MUST >>>>> NOT insert an SDP sctpmap attribute associated with the "m=" >>>>> line. >>>>> >>>>> 4.6. Example >>>>> >>>>> m=application 54111 SCTP/DTLS 54111 >>>>> a=sctpmap:54111 webrtc-datachannel >>>>> max-message-size=100000 streams=1 >>>>> >>>>> Figure 1: SDP Media Description for a CLUE data channel >>>>> >>>>> _______________________________________________ >>>>> 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 nobody Mon Feb 17 01:41:42 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937B31A0392 for ; Mon, 17 Feb 2014 01:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYrDtdcKDBIA for ; Mon, 17 Feb 2014 01:41:32 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B96D01A047B for ; Mon, 17 Feb 2014 01:41:31 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-4d-5301d9474d1b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 77.15.23809.749D1035; Mon, 17 Feb 2014 10:41:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0387.000; Mon, 17 Feb 2014 10:40:19 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres Thread-Index: Ac8qVqpg/4DOh4ZTSGSaavDifVp2WgBELw4AAAOFnDH///pZgIAAFQ0D///19ACAACrvAIAAEC6AgABc7XQ= Date: Mon, 17 Feb 2014 09:40:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D19C661@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> <53016764.9050201@nteczone.com> <53018B68.2080209@alum.mit.edu>,<530198FB.9000905@nteczone.com> In-Reply-To: <530198FB.9000905@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvja7HTcZggy/NrBZf3jeyWOw/dZnZ gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4MqY+OMhU0FLQcX0s8+YGxinh3cxcnJICJhI NL3/xw5hi0lcuLeerYuRi0NI4BCjxIu+RewQzhJGiae9S4EcDg42AQuJ7n/aIA0iAuESHduu MILYwgJOEjfbDrBBxJ0l1jbMYIewkyQONDcwg9gsAqoSV2d/A7N5BXwlnrV8YIaY/4FJYtvk K2AJTgEdiSnH34MNZQS66PupNUwgNrOAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP1YIW1Hi6vTl UPU6Egt2f2KDsLUlli18DbVYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmTXm60 iREYDQe3/FbdwXjnnMghRmkOFiVx3g9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MJoe WKr6IVEp06T7XvLPvpN2Bw9x2yqwzYmfHVeeu65x+xzJDVMOXJhr8eDzcos4R9ePZ9cVTk74 PYOh5vNzmapTd1Z9uji1T8+ibetP7UU3dqlmK8xwvbUniYNrb/+vuP151y9obZly8AqH7IwL PzQ97x08c/ik8bzXqzsPzeMPbHoo3vjJw6lIiaU4I9FQi7moOBEAourcPFQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/SJMJkiAco4Z3V4gCogTUbjn-ckw Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 09:41:36 -0000 Hi, I will read and comment on this at another moment, but to me it seems like = this discussion belongs to the MMUSIC (and perhaps RTCWEB) list. Regards, Christer ________________________________________ From: clue [clue-bounces@ietf.org] on behalf of Christian Groves [Christian= .Groves@nteczone.com] Sent: Monday, 17 February 2014 7:07 AM To: clue@ietf.org Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres Hello Paul, On 17/02/2014 3:09 PM, Paul Kyzivat wrote: > On 2/16/14 8:35 PM, Christian Groves wrote: >> Hello Christer, >> >> Please see below. >> >> Regards, Christian >> >> On 17/02/2014 12:11 PM, Christer Holmberg wrote: >>> Hi, >>> >>> If the offerer offers a data channel, AND also some way indicates >>> support of CLUE, we can always specify that the offerer MUST be able >>> to use the data channel for CLUE. The WebRTC data channel protocol can >>> then be used to open the channel for CLUE. >> [CNG] I agree. >> >> I'm still uncomfortable with the way these drafts are layered. > > I'm troubled too, but maybe not exactly the same way you are. > IMO it isn't that the layering is so wrong. Rather it is that the > terminology used is confusing. [CNG] Yes the terminology isn't helping either. > >> The SCTP >> draft allows the specification of "app"s that relate to the SCTP >> association as a means of negotiating what goes in the SCTP association. >> One of those "app"s may be the webrtc data channel. It has its own means >> of negotiating of what is in the SCTP association (i.e. Richard's >> draft). > > I agree with your interpretation here. That doesn't mean the layering > is wrong - just the terminology. > > The use of a=3Dsctpmap is clearly intended as an analog to a=3Drtpmap. Bu= t > in reality its purpose is not at all analogous to a=3Drtpmap. So the > name confuses. > > And that mis-analogy is continued, by language that says sctpmap is > defining a mapping from a port number to a payload format. Again, that > is not what it is doing. (If it were, then you would be restricted to > one payload format for all the streams on the association.) AFAICT, > the name you are giving in sctpmap describes some sort of "convention" > for how all the streams in the association are to be managed and used. > E.g., "webrtc-datachannel" says that the streams will be managed in > pairs, as channels, and that webrtc data channel protocol may be used > to dynamically assign channels. (That is the same conclusion you have > reached.) > > IMO a lot of the language should be changed to be less confusing. > >> Both these methods are basically just indicating what will be in >> the SCTP streams. > > Both? Which? The only thing that actually says, in SDP, what will be > in the individual SCTP streams is Richard's draft. [CNG] The SCTP draft does say which "apps" will be in the association. That what I mean by "what's in the streams" in the general sense. > >> Rather than have two methods for negotiating what is >> in the SCTP association it almost seems better to have one method for >> negotiation of what apps there are and then to tag whether or not the >> webrtc data channel will be used to open it. >> >> e.g. >> >> m=3Dapplication 54111 SCTP/DTLS 54111 >> a=3Dsctpmap:54111 stream=3D2;label=3D"CLUE 1"; subprotocol=3D"CLUE"; max= _retr=3D3; >> webrtc-datachannel-tag >> a=3Dwebrtc-datachannel:max-message-size=3D100000 streams=3D1 >> >> webrtc-datachannel-tag would take whether an "app" uses the webrtc data >> channel open protocol. >> a=3Dwebrtc-datachannel attribute would give the attributes of the >> protocol. > > There are problems with this - not for CLUE, but for webrtc, or > anything that doesn't want to use O/A to define every channel. > > The webrtc data channel open protocol does not take a stream ID as an > argument. It internally assigns stream IDs. Rtcweb has specified how > you can use preassigned channels without the open, but then it isn't > using the data channel protocol. [CNG] I just threw something together here without much thought. So for the case where the streamID isn't specified "data channel protocol" could be the value to indicate that it is used? > > IMO, from an mmusic perspective, we need to support both the static > and dynamic assignment of channels. We just want it to be done more > clearly. [CNG] Perhaps this is key, for a particular app in a SCTP association we need to say whether or not the streamID assignment is static or dynamic via the data channel protocol". > > From a CLUE perspective, we need to decide if we want to use the > static or dynamic assignment. IMO the preferred choice is not obvious > - both have their attractions. At the moment I am *slightly* > preferring the dynamic. [CNG] Dynamic is probably OK so long as we have some sort of label mechanism to help sort out mapping when you have multiple instances of the same app. > > Thanks, > Paul > >>> >>> But, never the less, it would probably be good to have an example >>> showing how things would look like using Richard's draft, until we've >>> decided whether we are going to use it or not. I'll add that. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Sony Ericsson Xperia arc S >>> >>> Christian Groves wrote: >>> >>> >>> Hello Christer, >>> >>> I think that for the signaling we must specify a way of negotiating at >>> the SDP level whether CLUE is supported. I agree there's lots of >>> ways it >>> could be done but we need to indicate which one/s CLUE should use. >>> >>> So for the SDP O/A procedures and example I think you have to assume >>> the >>> use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say >>> its a CLUE data channel according to the SDP given. You're just opening >>> a generic channel, which may or may not be clue. Particularly in the >>> Answerer's case, it doesn't know that the Offer is going to use the >>> channel for CLUE. >>> >>> However: >>> m=3Dapplication 54111 SCTP/DTLS 54111 >>> a=3Dsctpmap:54111 webrtc-datachannel max-message-size=3D100000 streams= =3D1 >>> a=3Ddcmap:54111 stream=3D2;label=3D"CLUE 1"; subprotocol=3D"CLUE"; max_= retr=3D3 >>> >>> would unambiguously define it as a CLUE data channel. >>> >>> Regards, Christian >>> >>> On 17/02/2014 11:16 AM, Christer Holmberg wrote: >>>> Hi Christian, >>>> >>>> If you want to negotiate usage of CLUE (or, any other specific usage >>>> of a webrtc-datachannel) in SDP, one option is to use Richard's >>>> draft. The usage of that draft is listed as an open issue in the CLUE >>>> data channel draft. >>>> >>>> SIP also provides other mechanisms, e.g. media feature tags, for >>>> indicating support of features. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> Sent from my Sony Ericsson Xperia arc S >>>> >>>> Christian Groves wrote: >>>> >>>> >>>> Hello Christer, >>>> >>>> With the use of webrtc-datachannel how do I negotiate via SDP >>>> whether I >>>> want to use clue or not? >>>> >>>> A SCTP association (and thus webrtc-datachannel) for example could be >>>> used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP >>>> association to figure out that the endpoints support >>>> webrtc-datachannel >>>> put don't support the application that you want. >>>> >>>> In the example in section 4.6 there's no way of distinguishing that >>>> description for CLUE vs BFCP vs anything else. Its not a CLUE data >>>> channel is a generic data channel. >>>> >>>> Regards, Christian >>>> >>>> On 16/02/2014 1:03 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> The draft submission deadline has passed, but I still wrote some >>>>> more text, shown below, for the SDP Offer/Answer Procedures section. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> PS. Note that I will be on vacation next week, so I will once again >>>>> do my best trying to stay away from e-mails :) >>>>> >>>>> ----------------------- >>>>> >>>>> 4. SDP Offer/Answer Procedures >>>>> >>>>> 4.1. General >>>>> >>>>> This section describes how the SDP media description ("m=3D") >>>>> line for >>>>> a CLUE data channel is created, and how it is used in SDP >>>>> offers and >>>>> answers. >>>>> >>>>> NOTE: The proceudres associated with "m=3D" lines for other >>>>> media types >>>>> (e.g. audio and video) used in a CLUE session are outside the >>>>> scope >>>>> of this document. >>>>> >>>>> OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data >>>>> Channel >>>>> Negotiation mechanism >>>>> [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] >>>>> will be used with the CLUE data channel. >>>>> >>>>> NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will >>>>> be used >>>>> with the CLUE data channel, a new associated 'sub-protocol' >>>>> value >>>>> needs to be registered with IANA. >>>>> >>>>> 4.2. SDP Media Description Fields >>>>> >>>>> The field values of the "m=3D" line for the CLUE data channel >>>>> are set >>>>> as following: >>>>> >>>>> >>>>> +----------------+----------------+------------------------+---------= -------+ >>>>> >>>>> >>>>> | media | port | >>>>> proto | fmt | >>>>> >>>>> +----------------+----------------+------------------------+---------= -------+ >>>>> >>>>> >>>>> | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP >>>>> port | >>>>> | | value >>>>> | | value | >>>>> >>>>> +----------------+----------------+------------------------+---------= ------+ >>>>> >>>>> >>>>> >>>>> Table 1: SDP "proto" field values >>>>> >>>>> 4.3. SDP sctpmap Attribute >>>>> >>>>> The field values of the SDP sctpmap attribute associated >>>>> with the >>>>> CLUE data channel "m=3D" are set as following: >>>>> >>>>> >>>>> +---------------------+---------------------------+------------------= -----+---------+ >>>>> >>>>> >>>>> | sctpmap-number | app | >>>>> max-message-size | stream | >>>>> >>>>> +---------------------+---------------------------+------------------= -----+---------+ >>>>> >>>>> >>>>> | fmt value of | "webrtc-datachannel" | >>>>> Implemenation | "1" | >>>>> | the "m=3D" line | | >>>>> specific | | >>>>> >>>>> +---------------------+---------------------------+------------------= -----+---------+ >>>>> >>>>> >>>>> >>>>> Table 2: SDP "proto" field values >>>>> >>>>> 4.4. SDP Offerer Procedures >>>>> >>>>> The procedures for the offerer follow the normal proceures >>>>> defined in >>>>> [ref-to-3264]. >>>>> >>>>> When the offerer creates an offer, which contains an "m=3D" lin= e >>>>> for a >>>>> CLUE data channel, it assigns the field values to the "m=3D" li= ne >>>>> according to the procedures in Section 4.2. In addition, the >>>>> offerer >>>>> MUST insert an SDP sctpmap attribute associated with the "m=3D" >>>>> line. >>>>> >>>>> In an offer, the offerer MUST NOT insert more than one "m=3D" >>>>> line for >>>>> a CLUE data channel. >>>>> >>>>> NOTE: CLUE does not support the usage of multiple CLUE data >>>>> channels. >>>>> >>>>> The offerer MUST NOT insert more than one SDP sctpmap >>>>> attributes in >>>>> an "m=3D" line for a CLUE data channel. >>>>> >>>>> If an offerer, in a subsequent offer, wants to disable the >>>>> CLUE data >>>>> channel, it assigns a zero port value to the "m=3D" line >>>>> associated >>>>> with the CLUE data channel. The answerer MUST NOT insert an >>>>> SDP >>>>> sctpmap attribute associated with the "m=3D" line. >>>>> >>>>> 4.5. SDP Answerer Procedures >>>>> >>>>> The procedures for the answerer follow the normal proceures >>>>> defined >>>>> in [ref-to-3264]. >>>>> >>>>> If the answerer receives an offer, which contains an "m=3D" lin= e >>>>> for a >>>>> CLUE data channel, and the answerer accepts the "m=3D" line, it >>>>> creates >>>>> and inserts an "m=3D" line in the associated answer. The answer= er >>>>> assigns the field values to the "m=3D" line according to the >>>>> procedures >>>>> in Section 4.2. >>>>> >>>>> If, in the offer, a zero port value has been assigned to the >>>>> "m=3D" >>>>> line for the CLUE channel, or it the answerer does not >>>>> accept the >>>>> "m=3D" line, but accepts other "m=3D" lines in the offer (i.e. = the >>>>> answerer will not reject the whole offer), it still inserts an >>>>> "m=3D" >>>>> line for a CLUE data channel in the associated answer. The >>>>> answerer >>>>> then assigns a zero port value to the "m=3D" line. The answerer >>>>> MUST >>>>> NOT insert an SDP sctpmap attribute associated with the "m=3D" >>>>> line. >>>>> >>>>> 4.6. Example >>>>> >>>>> m=3Dapplication 54111 SCTP/DTLS 54111 >>>>> a=3Dsctpmap:54111 webrtc-datachannel >>>>> max-message-size=3D100000 streams=3D1 >>>>> >>>>> Figure 1: SDP Media Description for a CLUE data channel >>>>> >>>>> _______________________________________________ >>>>> 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 nobody Mon Feb 17 03:00:42 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455A41A0482 for ; Mon, 17 Feb 2014 03:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7ifIzKVhI09 for ; Mon, 17 Feb 2014 03:00:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 343871A0481 for ; Mon, 17 Feb 2014 03:00:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBF18096; Mon, 17 Feb 2014 11:00:33 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 11:00:25 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 11:00:29 +0000 Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.104]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 19:00:19 +0800 From: "Liuyan (Scarlett)" To: "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres Thread-Index: Ac8qVqpg/4DOh4ZTSGSaavDifVp2WgA1g/YAAAFtFAAAAWOxgAAAiReAAADXBgAABV3jAAAdz/vg Date: Mon, 17 Feb 2014 11:00:19 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> <53016764.9050201@nteczone.com> <53018B68.2080209@alum.mit.edu> In-Reply-To: <53018B68.2080209@alum.mit.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.137.62] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/clue/rsLVi7PbzDuI14jwRKXAPFh_g-I Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 11:00:41 -0000 SGkgUGF1bCwNCg0KICAgUGxlYXNlIHNlZSBhYm91dCB0aGUgc3RhdGljIGFuZCBkeW5hbWljIGFz c2lnbm1lbnQgb2YgY2hhbm5lbHMgYXMgYmVsb3cuIFRoYW5rcy4NCg0KQmVzdCBSZWdhcmRzLA0K U2NhcmxldHQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNsdWUgW21haWx0 bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNClNlbnQ6 IE1vbmRheSwgRmVicnVhcnkgMTcsIDIwMTQgMTI6MDkgUE0NClRvOiBjbHVlQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW2NsdWVdIENMVUUgRGF0YSBDaGFubmVsOiBTRFAgT2ZmZXIvQW5zd2VyIFBy b2NldWRyZXMNCg0KT24gMi8xNi8xNCA4OjM1IFBNLCBDaHJpc3RpYW4gR3JvdmVzIHdyb3RlOg0K PiBIZWxsbyBDaHJpc3RlciwNCj4NCj4gUGxlYXNlIHNlZSBiZWxvdy4NCj4NCj4gUmVnYXJkcywg Q2hyaXN0aWFuDQo+DQo+IE9uIDE3LzAyLzIwMTQgMTI6MTEgUE0sIENocmlzdGVyIEhvbG1iZXJn IHdyb3RlOg0KPj4gSGksDQo+Pg0KPj4gSWYgdGhlIG9mZmVyZXIgb2ZmZXJzIGEgZGF0YSBjaGFu bmVsLCBBTkQgYWxzbyBzb21lIHdheSBpbmRpY2F0ZXMgDQo+PiBzdXBwb3J0IG9mIENMVUUsIHdl IGNhbiBhbHdheXMgc3BlY2lmeSB0aGF0IHRoZSBvZmZlcmVyIE1VU1QgYmUgYWJsZSANCj4+IHRv IHVzZSB0aGUgZGF0YSBjaGFubmVsIGZvciBDTFVFLiBUaGUgV2ViUlRDIGRhdGEgY2hhbm5lbCBw cm90b2NvbCANCj4+IGNhbiB0aGVuIGJlIHVzZWQgdG8gb3BlbiB0aGUgY2hhbm5lbCBmb3IgQ0xV RS4NCj4gW0NOR10gSSBhZ3JlZS4NCj4NCj4gSSdtIHN0aWxsIHVuY29tZm9ydGFibGUgd2l0aCB0 aGUgd2F5IHRoZXNlIGRyYWZ0cyBhcmUgbGF5ZXJlZC4NCg0KSSdtIHRyb3VibGVkIHRvbywgYnV0 IG1heWJlIG5vdCBleGFjdGx5IHRoZSBzYW1lIHdheSB5b3UgYXJlLg0KSU1PIGl0IGlzbid0IHRo YXQgdGhlIGxheWVyaW5nIGlzIHNvIHdyb25nLiBSYXRoZXIgaXQgaXMgdGhhdCB0aGUgdGVybWlu b2xvZ3kgdXNlZCBpcyBjb25mdXNpbmcuDQoNCj4gVGhlIFNDVFANCj4gZHJhZnQgYWxsb3dzIHRo ZSBzcGVjaWZpY2F0aW9uIG9mICJhcHAicyB0aGF0IHJlbGF0ZSB0byB0aGUgU0NUUCANCj4gYXNz b2NpYXRpb24gYXMgYSBtZWFucyBvZiBuZWdvdGlhdGluZyB3aGF0IGdvZXMgaW4gdGhlIFNDVFAg YXNzb2NpYXRpb24uDQo+IE9uZSBvZiB0aG9zZSAiYXBwInMgbWF5IGJlIHRoZSB3ZWJydGMgZGF0 YSBjaGFubmVsLiBJdCBoYXMgaXRzIG93biANCj4gbWVhbnMgb2YgbmVnb3RpYXRpbmcgb2Ygd2hh dCBpcyBpbiB0aGUgU0NUUCBhc3NvY2lhdGlvbiAoaS5lLiANCj4gUmljaGFyZCdzIGRyYWZ0KS4N Cg0KSSBhZ3JlZSB3aXRoIHlvdXIgaW50ZXJwcmV0YXRpb24gaGVyZS4gVGhhdCBkb2Vzbid0IG1l YW4gdGhlIGxheWVyaW5nIGlzIHdyb25nIC0ganVzdCB0aGUgdGVybWlub2xvZ3kuDQoNClRoZSB1 c2Ugb2YgYT1zY3RwbWFwIGlzIGNsZWFybHkgaW50ZW5kZWQgYXMgYW4gYW5hbG9nIHRvIGE9cnRw bWFwLiBCdXQgaW4gcmVhbGl0eSBpdHMgcHVycG9zZSBpcyBub3QgYXQgYWxsIGFuYWxvZ291cyB0 byBhPXJ0cG1hcC4gU28gdGhlIG5hbWUgY29uZnVzZXMuDQoNCkFuZCB0aGF0IG1pcy1hbmFsb2d5 IGlzIGNvbnRpbnVlZCwgYnkgbGFuZ3VhZ2UgdGhhdCBzYXlzIHNjdHBtYXAgaXMgZGVmaW5pbmcg YSBtYXBwaW5nIGZyb20gYSBwb3J0IG51bWJlciB0byBhIHBheWxvYWQgZm9ybWF0LiBBZ2Fpbiwg dGhhdCBpcyBub3Qgd2hhdCBpdCBpcyBkb2luZy4gKElmIGl0IHdlcmUsIHRoZW4geW91IHdvdWxk IGJlIHJlc3RyaWN0ZWQgdG8gb25lIHBheWxvYWQgZm9ybWF0IGZvciBhbGwgdGhlIHN0cmVhbXMg b24gdGhlIGFzc29jaWF0aW9uLikgQUZBSUNULCB0aGUgbmFtZSB5b3UgYXJlIGdpdmluZyBpbiBz Y3RwbWFwIGRlc2NyaWJlcyBzb21lIHNvcnQgb2YgImNvbnZlbnRpb24iIGZvciBob3cgYWxsIHRo ZSBzdHJlYW1zIGluIHRoZSBhc3NvY2lhdGlvbiBhcmUgdG8gYmUgbWFuYWdlZCBhbmQgdXNlZC4g RS5nLiwgIndlYnJ0Yy1kYXRhY2hhbm5lbCIgc2F5cyB0aGF0IHRoZSBzdHJlYW1zIHdpbGwgYmUg bWFuYWdlZCBpbiBwYWlycywgYXMgY2hhbm5lbHMsIGFuZCB0aGF0IHdlYnJ0YyBkYXRhIGNoYW5u ZWwgcHJvdG9jb2wgbWF5IGJlIHVzZWQgdG8gZHluYW1pY2FsbHkgYXNzaWduIGNoYW5uZWxzLiAo VGhhdCBpcyB0aGUgc2FtZSBjb25jbHVzaW9uIHlvdSBoYXZlIHJlYWNoZWQuKQ0KDQpJTU8gYSBs b3Qgb2YgdGhlIGxhbmd1YWdlIHNob3VsZCBiZSBjaGFuZ2VkIHRvIGJlIGxlc3MgY29uZnVzaW5n Lg0KDQo+IEJvdGggdGhlc2UgbWV0aG9kcyBhcmUgYmFzaWNhbGx5IGp1c3QgaW5kaWNhdGluZyB3 aGF0IHdpbGwgYmUgaW4gdGhlIA0KPiBTQ1RQIHN0cmVhbXMuDQoNCkJvdGg/IFdoaWNoPyBUaGUg b25seSB0aGluZyB0aGF0IGFjdHVhbGx5IHNheXMsIGluIFNEUCwgd2hhdCB3aWxsIGJlIGluIHRo ZSBpbmRpdmlkdWFsIFNDVFAgc3RyZWFtcyBpcyBSaWNoYXJkJ3MgZHJhZnQuDQoNCj4gUmF0aGVy IHRoYW4gaGF2ZSB0d28gbWV0aG9kcyBmb3IgbmVnb3RpYXRpbmcgd2hhdCBpcyBpbiB0aGUgU0NU UCANCj4gYXNzb2NpYXRpb24gaXQgYWxtb3N0IHNlZW1zIGJldHRlciB0byBoYXZlIG9uZSBtZXRo b2QgZm9yIG5lZ290aWF0aW9uIA0KPiBvZiB3aGF0IGFwcHMgdGhlcmUgYXJlIGFuZCB0aGVuIHRv IHRhZyB3aGV0aGVyIG9yIG5vdCB0aGUgd2VicnRjIGRhdGEgDQo+IGNoYW5uZWwgd2lsbCBiZSB1 c2VkIHRvIG9wZW4gaXQuDQo+DQo+IGUuZy4NCj4NCj4gbT1hcHBsaWNhdGlvbiA1NDExMSBTQ1RQ L0RUTFMgNTQxMTENCj4gYT1zY3RwbWFwOjU0MTExIHN0cmVhbT0yO2xhYmVsPSJDTFVFIDEiOyBz dWJwcm90b2NvbD0iQ0xVRSI7IA0KPiBtYXhfcmV0cj0zOyB3ZWJydGMtZGF0YWNoYW5uZWwtdGFn DQo+IGE9d2VicnRjLWRhdGFjaGFubmVsOm1heC1tZXNzYWdlLXNpemU9MTAwMDAwIHN0cmVhbXM9 MQ0KPg0KPiB3ZWJydGMtZGF0YWNoYW5uZWwtdGFnIHdvdWxkIHRha2Ugd2hldGhlciBhbiAiYXBw IiB1c2VzIHRoZSB3ZWJydGMgDQo+IGRhdGEgY2hhbm5lbCBvcGVuIHByb3RvY29sLg0KPiBhPXdl YnJ0Yy1kYXRhY2hhbm5lbCBhdHRyaWJ1dGUgd291bGQgZ2l2ZSB0aGUgYXR0cmlidXRlcyBvZiB0 aGUgcHJvdG9jb2wuDQoNClRoZXJlIGFyZSBwcm9ibGVtcyB3aXRoIHRoaXMgLSBub3QgZm9yIENM VUUsIGJ1dCBmb3Igd2VicnRjLCBvciBhbnl0aGluZyB0aGF0IGRvZXNuJ3Qgd2FudCB0byB1c2Ug Ty9BIHRvIGRlZmluZSBldmVyeSBjaGFubmVsLg0KDQpUaGUgd2VicnRjIGRhdGEgY2hhbm5lbCBv cGVuIHByb3RvY29sIGRvZXMgbm90IHRha2UgYSBzdHJlYW0gSUQgYXMgYW4gYXJndW1lbnQuIEl0 IGludGVybmFsbHkgYXNzaWducyBzdHJlYW0gSURzLiBSdGN3ZWIgaGFzIHNwZWNpZmllZCBob3cg eW91IGNhbiB1c2UgcHJlYXNzaWduZWQgY2hhbm5lbHMgd2l0aG91dCB0aGUgb3BlbiwgYnV0IHRo ZW4gaXQgaXNuJ3QgdXNpbmcgdGhlIGRhdGEgY2hhbm5lbCBwcm90b2NvbC4NCg0KSU1PLCBmcm9t IGFuIG1tdXNpYyBwZXJzcGVjdGl2ZSwgd2UgbmVlZCB0byBzdXBwb3J0IGJvdGggdGhlIHN0YXRp YyBhbmQgZHluYW1pYyBhc3NpZ25tZW50IG9mIGNoYW5uZWxzLiBXZSBqdXN0IHdhbnQgaXQgdG8g YmUgZG9uZSBtb3JlIGNsZWFybHkuDQoNCiBGcm9tIGEgQ0xVRSBwZXJzcGVjdGl2ZSwgd2UgbmVl ZCB0byBkZWNpZGUgaWYgd2Ugd2FudCB0byB1c2UgdGhlIHN0YXRpYyBvciBkeW5hbWljIGFzc2ln bm1lbnQuIElNTyB0aGUgcHJlZmVycmVkIGNob2ljZSBpcyBub3Qgb2J2aW91cyAtIGJvdGggaGF2 ZSB0aGVpciBhdHRyYWN0aW9ucy4gQXQgdGhlIG1vbWVudCBJIGFtICpzbGlnaHRseSogcHJlZmVy cmluZyB0aGUgZHluYW1pYy4NCltTY2FybGV0dF0gSSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgc3Rh dGljIG9yIGR5bmFtaWMgYXNzaWdubWVudCBvZiBkYXRhIGNoYW5uZWxzLg0KTWF5YmUgdGhlIHN0 YXRpYyBhc3NpZ25tZW50IG9mIGRhdGEgY2hhbm5lbCBpcyBhcyBiZWxvd6O6DQoxKSBBY2NvcmRp bmcgdG8gdGhlIGRyYWZ0LWVqemFrLWRpc3BhdGNoLXdlYnJ0Yy1kYXRhLWNoYW5uZWwtc2RwbmVn LTAwIGRyYWZ0LCB0aGUgc3RyZWFtIGlkIGZvciB3ZWJydGMgZGF0YSBjaGFubmVsIGlzIGdpdmVu IGluIFNEUCBvZmZlciBpbiBzcGl0ZSBvZiB0aGUgU0NUUCBhc3NvY2lhdGlvbiBoYXMgbm90IGJl ZW4gZXN0YWJsaXNoZWQuIDIpIEFmdGVyIHRoZSB3ZWJydGMgY2xpZW50cyBoYXZlIGZpbmlzaGVk IFNEUCBvZmZlci9hbnN3ZXIsIHRoZSBTQ1RQIGFzc29jaWF0aW9uIHdpbGwgYmUgZXN0YWJsaXNo ZWQuIEFuZCB0aGVuIHRoZSBkYXRhIGNoYW5uZWwncyBzdGF0ZSB3aWxsIGJlIHNldCBvcGVuLg0K DQpUaGUgZHluYW1pYyBhc3NpZ25tZW50IG9mIGRhdGEgY2hhbm5lbCBpcyBhcyBiZWxvd6O7DQox KSBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwLTA1IGRyYWZ0LCBp ZiBhbiBTRFAgb2ZmZXIgd2l0aCBhIERUTFMvU0NUUCByZXF1ZXN0IGlzIGFuc3dlcmVkIHN1Y2Nl c3NmdWxseSB0aGUgY29ycmVzcG9uZGluZyBTQ1RQIGFzc29jaWF0aW9uIHdpbGwgYmUgZXN0YWJs aXNoZWQuDQoyKSBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LWlldGYtcnRjd2ViLWRhdGEtcHJvdG9j b2wtMDEgZHJhZnQsIHRoZSB3ZWJydGMgY2xpZW50IHdpbGwgb3BlbiBhIGRhdGEgY2hhbm5lbCB1 c2luZyBhbiB1bnVzZWQgc3RyZWFtIGlkIGZyb20gdGhlIHN0cmVhbSBpZHMgb2YgdGhlIFNDVFAg YXNzb2NpYXRpb24uIA0KDQoNCglUaGFua3MsDQoJUGF1bA0KDQo+Pg0KPj4gQnV0LCBuZXZlciB0 aGUgbGVzcywgaXQgd291bGQgcHJvYmFibHkgYmUgZ29vZCB0byBoYXZlIGFuIGV4YW1wbGUgDQo+ PiBzaG93aW5nIGhvdyB0aGluZ3Mgd291bGQgbG9vayBsaWtlIHVzaW5nIFJpY2hhcmQncyBkcmFm dCwgdW50aWwgd2UndmUgDQo+PiBkZWNpZGVkIHdoZXRoZXIgd2UgYXJlIGdvaW5nIHRvIHVzZSBp dCBvciBub3QuIEknbGwgYWRkIHRoYXQuDQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rl cg0KPj4NCj4+IFNlbnQgZnJvbSBteSBTb255IEVyaWNzc29uIFhwZXJpYSBhcmMgUw0KPj4NCj4+ IENocmlzdGlhbiBHcm92ZXMgPENocmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29tPiB3cm90ZToN Cj4+DQo+Pg0KPj4gSGVsbG8gQ2hyaXN0ZXIsDQo+Pg0KPj4gSSB0aGluayB0aGF0IGZvciB0aGUg c2lnbmFsaW5nIHdlIG11c3Qgc3BlY2lmeSBhIHdheSBvZiBuZWdvdGlhdGluZyANCj4+IGF0IHRo ZSBTRFAgbGV2ZWwgd2hldGhlciBDTFVFIGlzIHN1cHBvcnRlZC4gSSBhZ3JlZSB0aGVyZSdzIGxv dHMgb2YgDQo+PiB3YXlzIGl0IGNvdWxkIGJlIGRvbmUgYnV0IHdlIG5lZWQgdG8gaW5kaWNhdGUg d2hpY2ggb25lL3MgQ0xVRSBzaG91bGQgdXNlLg0KPj4NCj4+IFNvIGZvciB0aGUgU0RQIE8vQSBw cm9jZWR1cmVzIGFuZCBleGFtcGxlIEkgdGhpbmsgeW91IGhhdmUgdG8gYXNzdW1lIA0KPj4gdGhl IHVzZSBvZiBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBvdGhlcndpc2Ug eW91IGNhbid0IA0KPj4gc2F5IGl0cyBhIENMVUUgZGF0YSBjaGFubmVsIGFjY29yZGluZyB0byB0 aGUgU0RQIGdpdmVuLiBZb3UncmUganVzdCANCj4+IG9wZW5pbmcgYSBnZW5lcmljIGNoYW5uZWws IHdoaWNoIG1heSBvciBtYXkgbm90IGJlIGNsdWUuIFBhcnRpY3VsYXJseSANCj4+IGluIHRoZSBB bnN3ZXJlcidzIGNhc2UsIGl0IGRvZXNuJ3Qga25vdyB0aGF0IHRoZSBPZmZlciBpcyBnb2luZyB0 byANCj4+IHVzZSB0aGUgY2hhbm5lbCBmb3IgQ0xVRS4NCj4+DQo+PiBIb3dldmVyOg0KPj4gbT1h cHBsaWNhdGlvbiA1NDExMSBTQ1RQL0RUTFMgNTQxMTENCj4+IGE9c2N0cG1hcDo1NDExMSB3ZWJy dGMtZGF0YWNoYW5uZWwgbWF4LW1lc3NhZ2Utc2l6ZT0xMDAwMDAgc3RyZWFtcz0xDQo+PiBhPWRj bWFwOjU0MTExIHN0cmVhbT0yO2xhYmVsPSJDTFVFIDEiOyBzdWJwcm90b2NvbD0iQ0xVRSI7IG1h eF9yZXRyPTMNCj4+DQo+PiB3b3VsZCB1bmFtYmlndW91c2x5IGRlZmluZSBpdCBhcyBhIENMVUUg ZGF0YSBjaGFubmVsLg0KPj4NCj4+IFJlZ2FyZHMsIENocmlzdGlhbg0KPj4NCj4+IE9uIDE3LzAy LzIwMTQgMTE6MTYgQU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPj4+IEhpIENocmlzdGlh biwNCj4+Pg0KPj4+IElmIHlvdSB3YW50IHRvIG5lZ290aWF0ZSB1c2FnZSBvZiBDTFVFIChvciwg YW55IG90aGVyIHNwZWNpZmljIHVzYWdlIA0KPj4+IG9mIGEgd2VicnRjLWRhdGFjaGFubmVsKSBp biBTRFAsIG9uZSBvcHRpb24gaXMgdG8gdXNlIFJpY2hhcmQncyANCj4+PiBkcmFmdC4gVGhlIHVz YWdlIG9mIHRoYXQgZHJhZnQgaXMgbGlzdGVkIGFzIGFuIG9wZW4gaXNzdWUgaW4gdGhlIA0KPj4+ IENMVUUgZGF0YSBjaGFubmVsIGRyYWZ0Lg0KPj4+DQo+Pj4gU0lQIGFsc28gcHJvdmlkZXMgb3Ro ZXIgbWVjaGFuaXNtcywgZS5nLiBtZWRpYSBmZWF0dXJlIHRhZ3MsIGZvciANCj4+PiBpbmRpY2F0 aW5nIHN1cHBvcnQgb2YgZmVhdHVyZXMuDQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+DQo+Pj4gQ2hy aXN0ZXINCj4+Pg0KPj4+IFNlbnQgZnJvbSBteSBTb255IEVyaWNzc29uIFhwZXJpYSBhcmMgUw0K Pj4+DQo+Pj4gQ2hyaXN0aWFuIEdyb3ZlcyA8Q2hyaXN0aWFuLkdyb3Zlc0BudGVjem9uZS5jb20+ IHdyb3RlOg0KPj4+DQo+Pj4NCj4+PiBIZWxsbyBDaHJpc3RlciwNCj4+Pg0KPj4+IFdpdGggdGhl IHVzZSBvZiB3ZWJydGMtZGF0YWNoYW5uZWwgaG93IGRvIEkgbmVnb3RpYXRlIHZpYSBTRFAgDQo+ Pj4gd2hldGhlciBJIHdhbnQgdG8gdXNlIGNsdWUgb3Igbm90Pw0KPj4+DQo+Pj4gQSBTQ1RQIGFz c29jaWF0aW9uIChhbmQgdGh1cyB3ZWJydGMtZGF0YWNoYW5uZWwpIGZvciBleGFtcGxlIGNvdWxk IA0KPj4+IGJlIHVzZWQgZm9yIEJGQ1AsQ0xVRSBhbmQgVC4zOC4gSXQgc2VlbXMgd2FzdGVmdWwg dG8gZXN0YWJsaXNoIHRoZSANCj4+PiBTQ1RQIGFzc29jaWF0aW9uIHRvIGZpZ3VyZSBvdXQgdGhh dCB0aGUgZW5kcG9pbnRzIHN1cHBvcnQgDQo+Pj4gd2VicnRjLWRhdGFjaGFubmVsIHB1dCBkb24n dCBzdXBwb3J0IHRoZSBhcHBsaWNhdGlvbiB0aGF0IHlvdSB3YW50Lg0KPj4+DQo+Pj4gSW4gdGhl IGV4YW1wbGUgaW4gc2VjdGlvbiA0LjYgdGhlcmUncyBubyB3YXkgb2YgZGlzdGluZ3Vpc2hpbmcg dGhhdCANCj4+PiBkZXNjcmlwdGlvbiBmb3IgQ0xVRSB2cyBCRkNQIHZzIGFueXRoaW5nIGVsc2Uu IEl0cyBub3QgYSBDTFVFIGRhdGEgDQo+Pj4gY2hhbm5lbCBpcyBhIGdlbmVyaWMgZGF0YSBjaGFu bmVsLg0KPj4+DQo+Pj4gUmVnYXJkcywgQ2hyaXN0aWFuDQo+Pj4NCj4+PiBPbiAxNi8wMi8yMDE0 IDE6MDMgQU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPj4+PiBIaSwNCj4+Pj4NCj4+Pj4g VGhlIGRyYWZ0IHN1Ym1pc3Npb24gZGVhZGxpbmUgaGFzIHBhc3NlZCwgYnV0IEkgc3RpbGwgd3Jv dGUgc29tZSANCj4+Pj4gbW9yZSB0ZXh0LCBzaG93biBiZWxvdywgZm9yIHRoZSBTRFAgT2ZmZXIv QW5zd2VyIFByb2NlZHVyZXMgc2VjdGlvbi4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4NCj4+ Pj4gQ2hyaXN0ZXINCj4+Pj4NCj4+Pj4gUFMuIE5vdGUgdGhhdCBJIHdpbGwgYmUgb24gdmFjYXRp b24gbmV4dCB3ZWVrLCBzbyBJIHdpbGwgb25jZSBhZ2FpbiANCj4+Pj4gZG8gbXkgYmVzdCB0cnlp bmcgdG8gc3RheSBhd2F5IGZyb20gZS1tYWlscyA6KQ0KPj4+Pg0KPj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4+Pg0KPj4+PiA0LiAgU0RQIE9mZmVyL0Fuc3dlciBQcm9jZWR1cmVzDQo+ Pj4+DQo+Pj4+IDQuMS4gIEdlbmVyYWwNCj4+Pj4NCj4+Pj4gICAgICAgVGhpcyBzZWN0aW9uIGRl c2NyaWJlcyBob3cgdGhlIFNEUCBtZWRpYSBkZXNjcmlwdGlvbiAoIm09IikgDQo+Pj4+IGxpbmUg Zm9yDQo+Pj4+ICAgICAgIGEgQ0xVRSBkYXRhIGNoYW5uZWwgaXMgY3JlYXRlZCwgYW5kIGhvdyBp dCBpcyB1c2VkIGluIFNEUCANCj4+Pj4gb2ZmZXJzIGFuZA0KPj4+PiAgICAgICBhbnN3ZXJzLg0K Pj4+Pg0KPj4+PiAgICAgICBOT1RFOiBUaGUgcHJvY2V1ZHJlcyBhc3NvY2lhdGVkIHdpdGggIm09 IiBsaW5lcyBmb3Igb3RoZXIgDQo+Pj4+IG1lZGlhIHR5cGVzDQo+Pj4+ICAgICAgIChlLmcuIGF1 ZGlvIGFuZCB2aWRlbykgdXNlZCBpbiBhIENMVUUgc2Vzc2lvbiBhcmUgb3V0c2lkZSB0aGUgDQo+ Pj4+IHNjb3BlDQo+Pj4+ICAgICAgIG9mIHRoaXMgZG9jdW1lbnQuDQo+Pj4+DQo+Pj4+ICAgICAg IE9QRU4gSVNTVUUgIzM6IEl0IGlzIEZGUyB3aGV0aGVyIHRoZSBTRFAtYmFzZWQgV2ViUlRDIERh dGEgDQo+Pj4+IENoYW5uZWwNCj4+Pj4gICAgICAgTmVnb3RpYXRpb24gbWVjaGFuaXNtDQo+Pj4+ IFtJLUQuZWp6YWstZGlzcGF0Y2gtd2VicnRjLWRhdGEtY2hhbm5lbC1zZHBuZWddDQo+Pj4+ICAg ICAgIHdpbGwgYmUgdXNlZCB3aXRoIHRoZSBDTFVFIGRhdGEgY2hhbm5lbC4NCj4+Pj4NCj4+Pj4g ICAgICAgTk9URTogSWYgW0ktRC5lanphay1kaXNwYXRjaC13ZWJydGMtZGF0YS1jaGFubmVsLXNk cG5lZ10gd2lsbCANCj4+Pj4gYmUgdXNlZA0KPj4+PiAgICAgICB3aXRoIHRoZSBDTFVFIGRhdGEg Y2hhbm5lbCwgYSBuZXcgYXNzb2NpYXRlZCAnc3ViLXByb3RvY29sJyB2YWx1ZQ0KPj4+PiAgICAg ICBuZWVkcyB0byBiZSByZWdpc3RlcmVkIHdpdGggSUFOQS4NCj4+Pj4NCj4+Pj4gNC4yLiAgU0RQ IE1lZGlhIERlc2NyaXB0aW9uIEZpZWxkcw0KPj4+Pg0KPj4+PiAgICAgICBUaGUgZmllbGQgdmFs dWVzIG9mIHRoZSAibT0iIGxpbmUgZm9yIHRoZSBDTFVFIGRhdGEgY2hhbm5lbCANCj4+Pj4gYXJl IHNldA0KPj4+PiAgICAgICBhcyBmb2xsb3dpbmc6DQo+Pj4+DQo+Pj4+DQo+Pj4+ICstLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0rDQo+Pj4+DQo+Pj4+ICAgICAgIHwgICAgIG1lZGlhICAgICAgfCAgICAgIHBv cnQgICAgICAgICB8DQo+Pj4+IHByb3RvICAgICAgICAgICAgICAgfCAgICAgIGZtdCAgICAgICAg IHwNCj4+Pj4NCj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4NCj4+Pj4gICAgICAgfCAi YXBwbGljYXRpb25TIHwgICBEVExTIHBvcnQgICB8ICJVRFAvVExTL1VEUFRMIiB8ICAgU0NUUA0K Pj4+PiBwb3J0ICAgfA0KPj4+PiAgICAgICB8ICAgICAgICAgICAgICAgICAgICB8ICAgICB2YWx1 ZQ0KPj4+PiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICB2YWx1ZSAgICAgICB8 DQo+Pj4+DQo+Pj4+ICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4NCj4+Pj4NCj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgVGFibGUgMTogU0RQICJwcm90byIgZmllbGQgdmFsdWVzDQo+Pj4+ DQo+Pj4+IDQuMy4gIFNEUCBzY3RwbWFwIEF0dHJpYnV0ZQ0KPj4+Pg0KPj4+PiAgICAgICBUaGUg ZmllbGQgdmFsdWVzIG9mIHRoZSBTRFAgc2N0cG1hcCBhdHRyaWJ1dGUgYXNzb2NpYXRlZCB3aXRo IHRoZQ0KPj4+PiAgICAgICBDTFVFIGRhdGEgY2hhbm5lbCAibT0iIGFyZSBzZXQgYXMgZm9sbG93 aW5nOg0KPj4+Pg0KPj4+Pg0KPj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rDQo+Pj4+ DQo+Pj4+ICAgICAgIHwgc2N0cG1hcC1udW1iZXIgfCAgICAgICAgIGFwcCAgICAgICAgICAgICAg ICAgIHwNCj4+Pj4gbWF4LW1lc3NhZ2Utc2l6ZSB8IHN0cmVhbSB8DQo+Pj4+DQo+Pj4+ICstLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLSsNCj4+Pj4NCj4+Pj4gICAgICAgfCAgZm10IHZhbHVlIG9m ICAgICAgIHwgIndlYnJ0Yy1kYXRhY2hhbm5lbCIgfA0KPj4+PiBJbXBsZW1lbmF0aW9uICAgICB8 ICAiMSIgICAgIHwNCj4+Pj4gICAgICAgfCB0aGUgIm09IiBsaW5lICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KPj4+PiBzcGVjaWZpYyAgICAgICAgICAgICB8ICAgICAg ICAgICB8DQo+Pj4+DQo+Pj4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSsNCj4+Pj4NCj4+ Pj4NCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgVGFibGUgMjogU0RQICJwcm90byIgZmll bGQgdmFsdWVzDQo+Pj4+DQo+Pj4+IDQuNC4gIFNEUCBPZmZlcmVyIFByb2NlZHVyZXMNCj4+Pj4N Cj4+Pj4gICAgICAgVGhlIHByb2NlZHVyZXMgZm9yIHRoZSBvZmZlcmVyIGZvbGxvdyB0aGUgbm9y bWFsIHByb2NldXJlcyANCj4+Pj4gZGVmaW5lZCBpbg0KPj4+PiAgICAgICBbcmVmLXRvLTMyNjRd Lg0KPj4+Pg0KPj4+PiAgICAgICBXaGVuIHRoZSBvZmZlcmVyIGNyZWF0ZXMgYW4gb2ZmZXIsIHdo aWNoIGNvbnRhaW5zIGFuICJtPSIgDQo+Pj4+IGxpbmUgZm9yIGENCj4+Pj4gICAgICAgQ0xVRSBk YXRhIGNoYW5uZWwsIGl0IGFzc2lnbnMgdGhlIGZpZWxkIHZhbHVlcyB0byB0aGUgIm09IiBsaW5l DQo+Pj4+ICAgICAgIGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJlcyBpbiBTZWN0aW9uIDQuMi4g IEluIGFkZGl0aW9uLCB0aGUgDQo+Pj4+IG9mZmVyZXINCj4+Pj4gICAgICAgTVVTVCBpbnNlcnQg YW4gU0RQIHNjdHBtYXAgYXR0cmlidXRlIGFzc29jaWF0ZWQgd2l0aCB0aGUgIm09Ig0KPj4+PiBs aW5lLg0KPj4+Pg0KPj4+PiAgICAgICBJbiBhbiBvZmZlciwgdGhlIG9mZmVyZXIgTVVTVCBOT1Qg aW5zZXJ0IG1vcmUgdGhhbiBvbmUgIm09Ig0KPj4+PiBsaW5lIGZvcg0KPj4+PiAgICAgICBhIENM VUUgZGF0YSBjaGFubmVsLg0KPj4+Pg0KPj4+PiAgICAgICBOT1RFOiBDTFVFIGRvZXMgbm90IHN1 cHBvcnQgdGhlIHVzYWdlIG9mIG11bHRpcGxlIENMVUUgZGF0YSANCj4+Pj4gY2hhbm5lbHMuDQo+ Pj4+DQo+Pj4+ICAgICAgIFRoZSBvZmZlcmVyIE1VU1QgTk9UIGluc2VydCBtb3JlIHRoYW4gb25l IFNEUCBzY3RwbWFwIA0KPj4+PiBhdHRyaWJ1dGVzIGluDQo+Pj4+ICAgICAgIGFuICJtPSIgbGlu ZSBmb3IgYSBDTFVFIGRhdGEgY2hhbm5lbC4NCj4+Pj4NCj4+Pj4gICAgICAgSWYgYW4gb2ZmZXJl ciwgaW4gYSBzdWJzZXF1ZW50IG9mZmVyLCB3YW50cyB0byBkaXNhYmxlIHRoZSANCj4+Pj4gQ0xV RSBkYXRhDQo+Pj4+ICAgICAgIGNoYW5uZWwsIGl0IGFzc2lnbnMgYSB6ZXJvIHBvcnQgdmFsdWUg dG8gdGhlICJtPSIgbGluZSBhc3NvY2lhdGVkDQo+Pj4+ICAgICAgIHdpdGggdGhlIENMVUUgZGF0 YSBjaGFubmVsLiAgVGhlIGFuc3dlcmVyIE1VU1QgTk9UIGluc2VydCBhbiBTRFANCj4+Pj4gICAg ICAgc2N0cG1hcCBhdHRyaWJ1dGUgYXNzb2NpYXRlZCB3aXRoIHRoZSAibT0iIGxpbmUuDQo+Pj4+ DQo+Pj4+IDQuNS4gIFNEUCBBbnN3ZXJlciBQcm9jZWR1cmVzDQo+Pj4+DQo+Pj4+ICAgICAgIFRo ZSBwcm9jZWR1cmVzIGZvciB0aGUgYW5zd2VyZXIgZm9sbG93IHRoZSBub3JtYWwgcHJvY2V1cmVz IA0KPj4+PiBkZWZpbmVkDQo+Pj4+ICAgICAgIGluIFtyZWYtdG8tMzI2NF0uDQo+Pj4+DQo+Pj4+ ICAgICAgIElmIHRoZSBhbnN3ZXJlciByZWNlaXZlcyBhbiBvZmZlciwgd2hpY2ggY29udGFpbnMg YW4gIm09IiANCj4+Pj4gbGluZSBmb3IgYQ0KPj4+PiAgICAgICBDTFVFIGRhdGEgY2hhbm5lbCwg YW5kIHRoZSBhbnN3ZXJlciBhY2NlcHRzIHRoZSAibT0iIGxpbmUsIGl0IA0KPj4+PiBjcmVhdGVz DQo+Pj4+ICAgICAgIGFuZCBpbnNlcnRzIGFuICJtPSIgbGluZSBpbiB0aGUgYXNzb2NpYXRlZCBh bnN3ZXIuICBUaGUgYW5zd2VyZXINCj4+Pj4gICAgICAgYXNzaWducyB0aGUgZmllbGQgdmFsdWVz IHRvIHRoZSAibT0iIGxpbmUgYWNjb3JkaW5nIHRvIHRoZSANCj4+Pj4gcHJvY2VkdXJlcw0KPj4+ PiAgICAgICBpbiBTZWN0aW9uIDQuMi4NCj4+Pj4NCj4+Pj4gICAgICAgSWYsIGluIHRoZSBvZmZl ciwgYSB6ZXJvIHBvcnQgdmFsdWUgaGFzIGJlZW4gYXNzaWduZWQgdG8gdGhlICJtPSINCj4+Pj4g ICAgICAgbGluZSBmb3IgdGhlIENMVUUgY2hhbm5lbCwgb3IgaXQgdGhlIGFuc3dlcmVyIGRvZXMg bm90IGFjY2VwdCB0aGUNCj4+Pj4gICAgICAgIm09IiBsaW5lLCBidXQgYWNjZXB0cyBvdGhlciAi bT0iIGxpbmVzIGluIHRoZSBvZmZlciAoaS5lLiB0aGUNCj4+Pj4gICAgICAgYW5zd2VyZXIgd2ls bCBub3QgcmVqZWN0IHRoZSB3aG9sZSBvZmZlciksIGl0IHN0aWxsIGluc2VydHMgDQo+Pj4+IGFu ICJtPSINCj4+Pj4gICAgICAgbGluZSBmb3IgYSBDTFVFIGRhdGEgY2hhbm5lbCBpbiB0aGUgYXNz b2NpYXRlZCBhbnN3ZXIuICBUaGUgDQo+Pj4+IGFuc3dlcmVyDQo+Pj4+ICAgICAgIHRoZW4gYXNz aWducyBhIHplcm8gcG9ydCB2YWx1ZSB0byB0aGUgIm09IiBsaW5lLiAgVGhlIA0KPj4+PiBhbnN3 ZXJlciBNVVNUDQo+Pj4+ICAgICAgIE5PVCBpbnNlcnQgYW4gU0RQIHNjdHBtYXAgYXR0cmlidXRl IGFzc29jaWF0ZWQgd2l0aCB0aGUgIm09Ig0KPj4+PiBsaW5lLg0KPj4+Pg0KPj4+PiA0LjYuICBF eGFtcGxlDQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgbT1hcHBsaWNhdGlvbiA1NDExMSBTQ1RQL0RU TFMgNTQxMTENCj4+Pj4gICAgICAgICAgICBhPXNjdHBtYXA6NTQxMTEgd2VicnRjLWRhdGFjaGFu bmVsDQo+Pj4+IG1heC1tZXNzYWdlLXNpemU9MTAwMDAwIHN0cmVhbXM9MQ0KPj4+Pg0KPj4+PiAg ICAgICAgICAgICAgRmlndXJlIDE6IFNEUCBNZWRpYSBEZXNjcmlwdGlvbiBmb3IgYSBDTFVFIGRh dGEgDQo+Pj4+IGNoYW5uZWwNCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4+Pj4gY2x1ZUBp ZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUN Cj4+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+IGNsdWUgbWFpbGluZyBsaXN0DQo+Pj4gY2x1ZUBpZXRmLm9yZw0KPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPj4+DQo+Pg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcg bGlzdA0KPiBjbHVlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2x1ZQ0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KY2x1ZSBtYWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K From nobody Mon Feb 17 09:18:41 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF5A1A04D2 for ; Mon, 17 Feb 2014 09:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_18=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEBaPP3zcnYT for ; Mon, 17 Feb 2014 09:18:36 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 675CD1A03F6 for ; Mon, 17 Feb 2014 09:18:36 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id TSGA1n0050xGWP854VJZ7W; Mon, 17 Feb 2014 17:18:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id TVJZ1n00N3ZTu2S3YVJZDl; Mon, 17 Feb 2014 17:18:33 +0000 Message-ID: <53024469.5000903@alum.mit.edu> Date: Mon, 17 Feb 2014 12:18:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140214225946.25105.54093.idtracker@ietfa.amsl.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=1392657513; bh=HvvXMysBQ3sNnsQlZKu3L0Yodon9opaAVofpoKZMpZ0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CW/9T7yfxnM2FzuaHaRYDgtYEPALHixCybNbHOZSSNA6f/4DHzb/7PxlYdGMVXToL +I+BWvy/a6dFwl9CcQZcKdFkbQPHYNMXfHRsYEs+64ab4PiKyldt8YH4UtP2y7bWRU c9LgZvAxY0moKRO/DbP35x/wtpudKcoYcgrjqJQ0OoqSYYVx3UIGSDDa6f7f7B81SW 0ngZ4bVc7rSnxFhTaOgsm7q4eDdJOcUcQmSbJoDOwtsXyrFMG8CkqyoudoNVo9mbw6 DVW54wbhLEUEnw3/ErmfOr2dRp0DgjzLuV6+qFCRsQoZUlWdyr8FwcfdE9q6XNamlQ 07J+WgsX7O9qA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/KkkJr3WR2StUjubXgaAveKedOCA Subject: Re: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 17:18:38 -0000 Rob, Thanks for the update. A few comments: Section 3.2: In the event that the CLUE data channel is successfully negotiated, a CLUE-enabled device MAY choose not to send media on the non-CLUE- controlled channels during the period in which control of the CLUE- controlled media lines is negotiated. However, a CLUE-enabled device MUST still be prepared to receive media on non-CLUE-controlled media lines as defined in [RFC3264]. I think we need more words about this somewhere. If the non-clue m-lines remain enabled but nothing is sent, we will probably start to get errors, and those sessions will fail. And if media continues to be sent, even though the recipient doesn't want it, then that adds cost. ISTM that either these should be dropped (port=0) or set to a=inactive if they are not to be used. Both sides have some responsibility in this - to make their intent known. And if we don't specify what purpose these streams have once clue use begins, then it is hard to use these in an interoperable way. Section 4.1: The CLUE Framework [I-D.ietf-clue-framework] defines the concept of "encodings", which represent the sender's encode ability. Each encoding the media provider wishes to signal is signalled via an "m" line of the appropriate media type, which MUST be marked as sendonly with the "a=sendonly" attribute or as inactive with the "a=inactive" attribute. I'm uncomfortable with requiring an m-line with port for every encoding. This requires assigning a pair of ports, maybe running ice on those ports, and sending RTCP. Some possible ways to improve on this: - allow encodings to be offered with a zero port - use BUNDLE - use capneg, as Christian discusses in draft-groves-clue-latent-config Also in that section: Every "m" line representing a CLUE encoding SHOULD contain a "label" attribute as defined in [RFC4574]. This label is used to identify the encoding by the sender in CLUE ADVERTISEMENT messages and by the receiver in CLUE CONFIGURE messages. I think SHOULD must be MUST. Without the label the m-line doesn't represent an encoding. Thanks, Paul On 2/15/14 3:30 AM, Robert Hansen (rohanse2) wrote: > This update doesn't propose masses of new content, instead it is mostly removing discussion of issues like encoding limits in favour of more normative language, expanding the section on changing clue status mid-call and interop with non-CLUE devices, and rearranging the draft to focus more on the decisions made. > > Rob > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 14 February 2014 23:00 > To: Lennard Xiao; Paul Kyzivat; Lennard Xiao; Robert Hansen (rohanse2); Robert Hansen (rohanse2); Christian Groves; Christian Groves; Paul Kyzivat > Subject: New Version Notification for draft-kyzivat-clue-signaling-07.txt > > > A new version of I-D, draft-kyzivat-clue-signaling-07.txt > has been successfully submitted by Robert Hansen and posted to the IETF repository. > > Name: draft-kyzivat-clue-signaling > Revision: 07 > Title: CLUE Signaling > Document date: 2014-02-14 > Group: Individual Submission > Pages: 37 > URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-07.txt > Status: https://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling/ > Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-07 > Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-07 > > Abstract: > This document specifies how CLUE-specific signaling such as the CLUE > protocol [I-D.presta-clue-protocol] and the CLUE data channel > [I-D.holmberg-clue-datachannel] are used with each other and with > existing signaling mechanisms such as SIP and SDP to produce a > telepresence call. > > > > > 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 nobody Mon Feb 17 10:58:09 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466C41A0167 for ; Mon, 17 Feb 2014 10:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5ynfOteeIEf for ; Mon, 17 Feb 2014 10:58:05 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 879561A012E for ; Mon, 17 Feb 2014 10:58:05 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s1HIw017020620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Feb 2014 12:58:00 -0600 (CST) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s1HIvtEb015472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 13:57:57 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 17 Feb 2014 13:57:50 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Christian Groves , "clue@ietf.org" Thread-Topic: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres Thread-Index: AQHPK2/OLI+UBr20MUSNhpriV+Wvqpq45+sAgAALHYCAAARJgIAAwHFA Date: Mon, 17 Feb 2014 18:57:49 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] 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 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/J-Cx10pOHd7AjTUkt8RmabhF3bc Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 18:58:07 -0000 > Hi, >=20 > If the offerer offers a data channel, AND also some way indicates support= of > CLUE, we can always specify that the offerer MUST be able to use the data > channel for CLUE. The WebRTC data channel protocol can then be used to op= en > the channel for CLUE. >=20 > But, never the less, it would probably be good to have an example showing > how things would look like using Richard's draft, until we've decided > whether we are going to use it or not. I'll add that. [Raju] We will add CLUE example SDP in Richard's draft as well. -Raju From nobody Mon Feb 17 13:24:57 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A221A0295 for ; Mon, 17 Feb 2014 13:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_44=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmFxUyKvFF92 for ; Mon, 17 Feb 2014 13:24:53 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDC31A0289 for ; Mon, 17 Feb 2014 13:24:52 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta14.westchester.pa.mail.comcast.net with comcast id TZ5A1n0051wpRvQ5EZQpJA; Mon, 17 Feb 2014 21:24:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id TZQp1n00M3ZTu2S3eZQpyU; Mon, 17 Feb 2014 21:24:49 +0000 Message-ID: <53027E21.2040008@alum.mit.edu> Date: Mon, 17 Feb 2014 16:24:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> <53016764.9050201@nteczone.com> <53018B68.2080209@alum.mit.edu> <530198FB.9000905@nteczone.com> In-Reply-To: <530198FB.9000905@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=1392672289; bh=WL0eaX7Lq+IdlgA/wxyhE1oRIf6LpH7cWIGbAfNhm9w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nY3/Xkj9liN4/cmo9furONU/DB+wSdJP4YS7DfuJlPwcn3qQJ2Yf1/RYmKcr/vSQU 7LX6GsZcRzAP8omcJLJpVZRr1noqpRbjZjKbALaNQniiUOoTL9OgZhZ20sjiefM0An CNlolxAZ2s79pa6B8meZExabtQ85lil/SKa7qvr4r+YSkxPRB/PCGmAYVCVhWH0ymR yTRkZiukS1ptFmCRjO9XX1hPESIWNkELI2IcojtmCfIQByzXDsBNNfmYxB9QezK59e g4f6sr0vN2EsxTGc+HLgMHseaWb6Hz2fAoqt2aLfCZdmYgc4rzb6qcaNzSDgkXAoy8 IVECyesLZSRKw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/oaE5iGMoSSi9WKAk_bxURuc4V0c Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 21:24:56 -0000 On 2/17/14 12:07 AM, Christian Groves wrote: > Hello Paul, [snip] >>> The SCTP >>> draft allows the specification of "app"s that relate to the SCTP >>> association as a means of negotiating what goes in the SCTP association. >>> One of those "app"s may be the webrtc data channel. It has its own means >>> of negotiating of what is in the SCTP association (i.e. Richard's >>> draft). >> >> I agree with your interpretation here. That doesn't mean the layering >> is wrong - just the terminology. >> >> The use of a=sctpmap is clearly intended as an analog to a=rtpmap. But >> in reality its purpose is not at all analogous to a=rtpmap. So the >> name confuses. >> >> And that mis-analogy is continued, by language that says sctpmap is >> defining a mapping from a port number to a payload format. Again, that >> is not what it is doing. (If it were, then you would be restricted to >> one payload format for all the streams on the association.) AFAICT, >> the name you are giving in sctpmap describes some sort of "convention" >> for how all the streams in the association are to be managed and used. >> E.g., "webrtc-datachannel" says that the streams will be managed in >> pairs, as channels, and that webrtc data channel protocol may be used >> to dynamically assign channels. (That is the same conclusion you have >> reached.) >> >> IMO a lot of the language should be changed to be less confusing. >> >>> Both these methods are basically just indicating what will be in >>> the SCTP streams. >> >> Both? Which? The only thing that actually says, in SDP, what will be >> in the individual SCTP streams is Richard's draft. > [CNG] The SCTP draft does say which "apps" will be in the association. > That what I mean by "what's in the streams" in the general sense. "apps" is a cop out - it is a meaningless term. "Loosely" I am inclined to think there is only one "app" at each end of the association, or maybe just one distributed app at both ends of the association. I find it hard to consider "webrtc-datachannel" an "application". It is just another layer in a stack. What we are more likely to recognize as the "application" is above that. (We are working our way up, from layer 7. But I've lost count.) But then there is some piece of application behavior associated with each channel. *That* is where it gets clue-specific. This is one of the things that deserves better terminology. >>> Rather than have two methods for negotiating what is >>> in the SCTP association it almost seems better to have one method for >>> negotiation of what apps there are and then to tag whether or not the >>> webrtc data channel will be used to open it. >>> >>> e.g. >>> >>> m=application 54111 SCTP/DTLS 54111 >>> a=sctpmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3; >>> webrtc-datachannel-tag >>> a=webrtc-datachannel:max-message-size=100000 streams=1 >>> >>> webrtc-datachannel-tag would take whether an "app" uses the webrtc data >>> channel open protocol. >>> a=webrtc-datachannel attribute would give the attributes of the >>> protocol. >> >> There are problems with this - not for CLUE, but for webrtc, or >> anything that doesn't want to use O/A to define every channel. >> >> The webrtc data channel open protocol does not take a stream ID as an >> argument. It internally assigns stream IDs. Rtcweb has specified how >> you can use preassigned channels without the open, but then it isn't >> using the data channel protocol. > [CNG] I just threw something together here without much thought. So for > the case where the streamID isn't specified "data channel protocol" > could be the value to indicate that it is used? That still requires declaring every channel in SDP doesn't it? (Maybe that is your goal. But it is a non-goal for webrtc.) My thinking is that the sctpmap attribute identifies the a discipline (convention) used to assign meaning to streams. Then the specification of that discipline provides the details of how streams are assigned/used. Then, when the discipline is webrtc-datachannel (preferably changed to a better name) draft-ietf-rtcweb-data-channel spells that out. So it defines how streams are grouped into channels, and defines both external and internal negotiation. It *ought* to reference (or be merged with) the Ejzak draft for external negotiation. >> IMO, from an mmusic perspective, we need to support both the static >> and dynamic assignment of channels. We just want it to be done more >> clearly. > [CNG] Perhaps this is key, for a particular app in a SCTP association we > need to say whether or not the streamID assignment is static or dynamic > via the data channel protocol". Again, for interop with rtcweb we are stuck with "webrtc-datachannel" as the "app". >> From a CLUE perspective, we need to decide if we want to use the >> static or dynamic assignment. IMO the preferred choice is not obvious >> - both have their attractions. At the moment I am *slightly* >> preferring the dynamic. > [CNG] Dynamic is probably OK so long as we have some sort of label > mechanism to help sort out mapping when you have multiple instances of > the same app. I think we would just specify an explicit "label" that CLUE uses to identify its channel. Thanks, Paul >> Thanks, >> Paul >> >>>> >>>> But, never the less, it would probably be good to have an example >>>> showing how things would look like using Richard's draft, until we've >>>> decided whether we are going to use it or not. I'll add that. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> Sent from my Sony Ericsson Xperia arc S >>>> >>>> Christian Groves wrote: >>>> >>>> >>>> Hello Christer, >>>> >>>> I think that for the signaling we must specify a way of negotiating at >>>> the SDP level whether CLUE is supported. I agree there's lots of >>>> ways it >>>> could be done but we need to indicate which one/s CLUE should use. >>>> >>>> So for the SDP O/A procedures and example I think you have to assume >>>> the >>>> use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say >>>> its a CLUE data channel according to the SDP given. You're just opening >>>> a generic channel, which may or may not be clue. Particularly in the >>>> Answerer's case, it doesn't know that the Offer is going to use the >>>> channel for CLUE. >>>> >>>> However: >>>> m=application 54111 SCTP/DTLS 54111 >>>> a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 >>>> a=dcmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3 >>>> >>>> would unambiguously define it as a CLUE data channel. >>>> >>>> Regards, Christian >>>> >>>> On 17/02/2014 11:16 AM, Christer Holmberg wrote: >>>>> Hi Christian, >>>>> >>>>> If you want to negotiate usage of CLUE (or, any other specific usage >>>>> of a webrtc-datachannel) in SDP, one option is to use Richard's >>>>> draft. The usage of that draft is listed as an open issue in the CLUE >>>>> data channel draft. >>>>> >>>>> SIP also provides other mechanisms, e.g. media feature tags, for >>>>> indicating support of features. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> Sent from my Sony Ericsson Xperia arc S >>>>> >>>>> Christian Groves wrote: >>>>> >>>>> >>>>> Hello Christer, >>>>> >>>>> With the use of webrtc-datachannel how do I negotiate via SDP >>>>> whether I >>>>> want to use clue or not? >>>>> >>>>> A SCTP association (and thus webrtc-datachannel) for example could be >>>>> used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP >>>>> association to figure out that the endpoints support >>>>> webrtc-datachannel >>>>> put don't support the application that you want. >>>>> >>>>> In the example in section 4.6 there's no way of distinguishing that >>>>> description for CLUE vs BFCP vs anything else. Its not a CLUE data >>>>> channel is a generic data channel. >>>>> >>>>> Regards, Christian >>>>> >>>>> On 16/02/2014 1:03 AM, Christer Holmberg wrote: >>>>>> Hi, >>>>>> >>>>>> The draft submission deadline has passed, but I still wrote some >>>>>> more text, shown below, for the SDP Offer/Answer Procedures section. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> PS. Note that I will be on vacation next week, so I will once again >>>>>> do my best trying to stay away from e-mails :) >>>>>> >>>>>> ----------------------- >>>>>> >>>>>> 4. SDP Offer/Answer Procedures >>>>>> >>>>>> 4.1. General >>>>>> >>>>>> This section describes how the SDP media description ("m=") >>>>>> line for >>>>>> a CLUE data channel is created, and how it is used in SDP >>>>>> offers and >>>>>> answers. >>>>>> >>>>>> NOTE: The proceudres associated with "m=" lines for other >>>>>> media types >>>>>> (e.g. audio and video) used in a CLUE session are outside the >>>>>> scope >>>>>> of this document. >>>>>> >>>>>> OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data >>>>>> Channel >>>>>> Negotiation mechanism >>>>>> [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] >>>>>> will be used with the CLUE data channel. >>>>>> >>>>>> NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will >>>>>> be used >>>>>> with the CLUE data channel, a new associated 'sub-protocol' >>>>>> value >>>>>> needs to be registered with IANA. >>>>>> >>>>>> 4.2. SDP Media Description Fields >>>>>> >>>>>> The field values of the "m=" line for the CLUE data channel >>>>>> are set >>>>>> as following: >>>>>> >>>>>> >>>>>> +----------------+----------------+------------------------+----------------+ >>>>>> >>>>>> >>>>>> | media | port | >>>>>> proto | fmt | >>>>>> >>>>>> +----------------+----------------+------------------------+----------------+ >>>>>> >>>>>> >>>>>> | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP >>>>>> port | >>>>>> | | value >>>>>> | | value | >>>>>> >>>>>> +----------------+----------------+------------------------+---------------+ >>>>>> >>>>>> >>>>>> >>>>>> Table 1: SDP "proto" field values >>>>>> >>>>>> 4.3. SDP sctpmap Attribute >>>>>> >>>>>> The field values of the SDP sctpmap attribute associated >>>>>> with the >>>>>> CLUE data channel "m=" are set as following: >>>>>> >>>>>> >>>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>>> >>>>>> >>>>>> | sctpmap-number | app | >>>>>> max-message-size | stream | >>>>>> >>>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>>> >>>>>> >>>>>> | fmt value of | "webrtc-datachannel" | >>>>>> Implemenation | "1" | >>>>>> | the "m=" line | | >>>>>> specific | | >>>>>> >>>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>>> >>>>>> >>>>>> >>>>>> Table 2: SDP "proto" field values >>>>>> >>>>>> 4.4. SDP Offerer Procedures >>>>>> >>>>>> The procedures for the offerer follow the normal proceures >>>>>> defined in >>>>>> [ref-to-3264]. >>>>>> >>>>>> When the offerer creates an offer, which contains an "m=" line >>>>>> for a >>>>>> CLUE data channel, it assigns the field values to the "m=" line >>>>>> according to the procedures in Section 4.2. In addition, the >>>>>> offerer >>>>>> MUST insert an SDP sctpmap attribute associated with the "m=" >>>>>> line. >>>>>> >>>>>> In an offer, the offerer MUST NOT insert more than one "m=" >>>>>> line for >>>>>> a CLUE data channel. >>>>>> >>>>>> NOTE: CLUE does not support the usage of multiple CLUE data >>>>>> channels. >>>>>> >>>>>> The offerer MUST NOT insert more than one SDP sctpmap >>>>>> attributes in >>>>>> an "m=" line for a CLUE data channel. >>>>>> >>>>>> If an offerer, in a subsequent offer, wants to disable the >>>>>> CLUE data >>>>>> channel, it assigns a zero port value to the "m=" line >>>>>> associated >>>>>> with the CLUE data channel. The answerer MUST NOT insert an >>>>>> SDP >>>>>> sctpmap attribute associated with the "m=" line. >>>>>> >>>>>> 4.5. SDP Answerer Procedures >>>>>> >>>>>> The procedures for the answerer follow the normal proceures >>>>>> defined >>>>>> in [ref-to-3264]. >>>>>> >>>>>> If the answerer receives an offer, which contains an "m=" line >>>>>> for a >>>>>> CLUE data channel, and the answerer accepts the "m=" line, it >>>>>> creates >>>>>> and inserts an "m=" line in the associated answer. The answerer >>>>>> assigns the field values to the "m=" line according to the >>>>>> procedures >>>>>> in Section 4.2. >>>>>> >>>>>> If, in the offer, a zero port value has been assigned to the >>>>>> "m=" >>>>>> line for the CLUE channel, or it the answerer does not >>>>>> accept the >>>>>> "m=" line, but accepts other "m=" lines in the offer (i.e. the >>>>>> answerer will not reject the whole offer), it still inserts an >>>>>> "m=" >>>>>> line for a CLUE data channel in the associated answer. The >>>>>> answerer >>>>>> then assigns a zero port value to the "m=" line. The answerer >>>>>> MUST >>>>>> NOT insert an SDP sctpmap attribute associated with the "m=" >>>>>> line. >>>>>> >>>>>> 4.6. Example >>>>>> >>>>>> m=application 54111 SCTP/DTLS 54111 >>>>>> a=sctpmap:54111 webrtc-datachannel >>>>>> max-message-size=100000 streams=1 >>>>>> >>>>>> Figure 1: SDP Media Description for a CLUE data channel >>>>>> >>>>>> _______________________________________________ >>>>>> 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 nobody Mon Feb 17 13:28:14 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABB51A0295 for ; Mon, 17 Feb 2014 13:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUVFXy-gTmbS for ; Mon, 17 Feb 2014 13:28:11 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 006C91A028A for ; Mon, 17 Feb 2014 13:28:10 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta15.westchester.pa.mail.comcast.net with comcast id TZ0c1n0011wpRvQ5FZU8YA; Mon, 17 Feb 2014 21:28:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id TZU71n02E3ZTu2S3eZU7jD; Mon, 17 Feb 2014 21:28:08 +0000 Message-ID: <53027EE7.1000908@alum.mit.edu> Date: Mon, 17 Feb 2014 16:28:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> <53016764.9050201@nteczone.com> <53018B68.2080209@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392672488; bh=O3hJj57CdlZbKvKI2xeSIBhHqpgX2WQOW8ZT5CrO7eo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qz3lGkHLURe26hz45gy0QDFY5pp+r/VmIDLEUYgEdxzc++HI7Bt9ZOY7ZCAmUfULn zrAaNJJTDfQsXYFrwp24BzT63Ib5XlmoGJJOQloopVPHnMn54JYxZav1UszwjjwDs4 z2yrY3Fi4MhHh8ek41eDVR+V7xmrjbRg559fmH5iSQivohoKvD0Uodm3PmYNC1DYcm 6CORvPBNoI9UDBnHZL8KCQ7L02FOxUcVzAe0xiHgtR86Ucg87FYc3X2fJTvumNtiNn 0KvNpjmsAExDWka116cbG+zP6mtEyOY3Bf2lMOTe8ZYHbp4NYeTOkHKPWRsQ8h4sWL TuBxoA1q2WClQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/hHqngNJUzo8o2vULmvM030UTotY Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 21:28:12 -0000 On 2/17/14 6:00 AM, Liuyan (Scarlett) wrote: > From a CLUE perspective, we need to decide if we want to use the static or dynamic assignment. IMO the preferred choice is not obvious - both have their attractions. At the moment I am *slightly* preferring the dynamic. > [Scarlett] I am not sure about the static or dynamic assignment of data channels. > Maybe the static assignment of data channel is as belowŁş > 1) According to the draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 draft, the stream id for webrtc data channel is given in SDP offer in spite of the SCTP association has not been established. 2) After the webrtc clients have finished SDP offer/answer, the SCTP association will be established. And then the data channel's state will be set open. > > The dynamic assignment of data channel is as belowŁ» > 1) According to the draft-ietf-mmusic-sctp-sdp-05 draft, if an SDP offer with a DTLS/SCTP request is answered successfully the corresponding SCTP association will be established. > 2) According to the draft-ietf-rtcweb-data-protocol-01 draft, the webrtc client will open a data channel using an unused stream id from the stream ids of the SCTP association. Yes. Thanks, Paul From nobody Mon Feb 17 15:17:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204A11A05B2; Mon, 17 Feb 2014 15:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7opundJWpGtU; Mon, 17 Feb 2014 15:17:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0771A05B8; Mon, 17 Feb 2014 15:16:35 -0800 (PST) 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: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140217231635.27113.96095.idtracker@ietfa.amsl.com> Date: Mon, 17 Feb 2014 15:16:35 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/dXDq3i44pfVq4rp5VTL94FhX4S0 Cc: clue mailing list , clue chair , RFC Editor Subject: [clue] Document Action: 'Use Cases for Telepresence Multi-streams' to Informational RFC (draft-ietf-clue-telepresence-use-cases-09.txt) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:17:24 -0000 The IESG has approved the following document: - 'Use Cases for Telepresence Multi-streams' (draft-ietf-clue-telepresence-use-cases-09.txt) as Informational RFC This document is the product of the ControLling mUltiple streams for tElepresence Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases/ Technical Summary: This document describes the most typical and important use cases for sending multiple streams in a telepresence conference. 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. Working Group Summary: Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document? This document is a product of the CLUE WG. There was no controversy with regards to adopting this document as a WG document. The document has been thoroughly reviewed by the CLUE WG participants and is deemed ready for publication. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The intent of this document is to highlight key uses cases that are supported in current telepresence systems. The objective within the CLUE WG is to develop protocols that will support those use cases to enable more widespread interoperability of telepresence systems. It should also be noted that a number of these use cases were originally documented in the IMTC Telepresence Activity Group, that is awaiting the completion of the CLUE protocol development to progress the interoperability of telepresence systems. The IMTC chose to bring their original requirements and use cases as input to the work in the IETF, recognizing IETF as the SDO that should be doing the standards development. There are a number of key vendors in the telepresence industry that plan to implement the CLUE WG series of specifications. Lennard Xiao reviewed the document and suggested (and provided some text) for the telemedicine use case, which is an important use case for current telepresence systems. Christian Groves has carefully reviewed several versions of this WG document. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Mary Barnes (CLUE WG co-chair) is the Document Shepherd. Gonzalo Camarillo is the Responsible AD. From nobody Mon Feb 17 15:47:20 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7221A0423 for ; Mon, 17 Feb 2014 15:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyQnEzzC5BXR for ; Mon, 17 Feb 2014 15:47:13 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8D51A041C for ; Mon, 17 Feb 2014 15:47:13 -0800 (PST) Received: by mail-yk0-f178.google.com with SMTP id 79so31475350ykr.9 for ; Mon, 17 Feb 2014 15:47:10 -0800 (PST) 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=1mNjeX1ANQOU96oYtUjM3B541oRHInWNm8dVmd69fGo=; b=xjkYTHk4PgYiJ6y6SyBjXQD2+1h/dlYhoNqHAjCipJL3aLeU7To1gT1X3kjzechasB PSnJqG6FgMwzFYn1n1FyHoBFhTlUPydcAMoXNguvaxktx7XwoA6fTayaIm/zyuYuo+fM GEiY8IWp0SgqfnKDI0hPwdr3YXElhBgkIGZxIuTkWGFSe1Ws6YTdP/N0EV8I89kWkdi0 kvPapjZwCZ2arWjLkBJDJ6O5HZ4dExorHB5qOWpkqVc7pQfUwgxWYDnZrXUgL8QDTcx1 gFTYOlPEUVHpwWcUtrci/bFtbfAbz3pykv9tSLnbYxg0IZxjbXVHovHqlJEERnieuxon g7wQ== MIME-Version: 1.0 X-Received: by 10.236.150.164 with SMTP id z24mr20462951yhj.75.1392680830773; Mon, 17 Feb 2014 15:47:10 -0800 (PST) Received: by 10.170.213.85 with HTTP; Mon, 17 Feb 2014 15:47:10 -0800 (PST) In-Reply-To: <53014C5F.3060405@nteczone.com> References: <53014C5F.3060405@nteczone.com> Date: Mon, 17 Feb 2014 17:47:10 -0600 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=20cf303b3c93342d7d04f2a2c61e Archived-At: http://mailarchive.ietf.org/arch/msg/clue/dlYa9aj0dHLXHINvEyyUKRK8m5Q Cc: CLUE Subject: Re: [clue] Reminder: draft deadline for IETF-89 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 23:47:17 -0000 --20cf303b3c93342d7d04f2a2c61e Content-Type: text/plain; charset=ISO-8859-1 Are you going to be at the meeting to lead the discussion? There has been very little discussion of this document on the mailing so it's not clear how much we gain from using face to face time to discuss this document. Mary. On Sun, Feb 16, 2014 at 5:40 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mary and Paul, > > Will draft-groves-clue-latent-config-00 doc/draft-groves-clue-latent-config/> be covered under the signalling > discussions? > > Regards, Christian > > > On 12/02/2014 2:43 AM, Mary Barnes wrote: > >> As a reminder, the draft deadline for the London meeting is this Friday >> (Feb. 14th), so you don't get the usual weekend to work up to a Monday >> deadline: >> http://www.ietf.org/meeting/important-dates-2014.html#IETF89 >> >> Note also that a draft agenda is due on Monday, Feb. 17th, so the chairs >> will put one together based on the current set of work items. If you have >> something beyond that, please let us know ASAP. >> >> Thanks, >> Mary. >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf303b3c93342d7d04f2a2c61e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Are you going to be at the meeting to lead the discussion?= =A0There has been very little discussion of this document on the mailing s= o it's not clear how much we gain from using face to face time to discu= ss this document.

Mary.


On Sun, Feb 16, 2014 at 5:40 PM, Christian Groves <Christian.Groves@nteczone.com> wrote:
Hello Mary and Paul,

Will draft-groves-clue-latent-config-00 <htt= ps://datatracker.ietf.org/doc/draft-groves-clue-latent-config= /> be covered under the signalling discussions?

Regards, Christian


On 12/02/2014 2:43 AM, Mary Barnes wrote:
As a reminder, the draft deadline for the London meeting is this Friday (Fe= b. 14th), so you don't get the usual weekend to work up to a Monday dea= dline:
http://www.ietf.org/meeting/important-dates-2014.htm= l#IETF89

Note also that a draft agenda is due on Monday, Feb. 17th, so the chairs wi= ll put one together based on the current set of work items. =A0If you have = something beyond that, please let us know ASAP.

Thanks,
Mary.


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

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

--20cf303b3c93342d7d04f2a2c61e-- From nobody Mon Feb 17 16:07:03 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E091A0013 for ; Mon, 17 Feb 2014 16:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HYaK0Wfkb2e for ; Mon, 17 Feb 2014 16:06:59 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4161A0553 for ; Mon, 17 Feb 2014 16:06:58 -0800 (PST) Received: from ppp118-209-239-233.lns20.mel6.internode.on.net ([118.209.239.233]:50903 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFYAQ-0006z3-Vd; Tue, 18 Feb 2014 11:04:07 +1100 Message-ID: <5302A41D.4090202@nteczone.com> Date: Tue, 18 Feb 2014 11:06:53 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mary Barnes References: <53014C5F.3060405@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/nDdqXyR-gHin99qbnTkDVPZvHHE Cc: CLUE Subject: Re: [clue] Reminder: draft deadline for IETF-89 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 00:07:01 -0000 Hello Mary, Yes I will be at the meeting. There's been very little discussion about signalling in general (apart from the SCTP transport issue). I'd encourage people to read the draft before hand and send any comments to the list. Regards, Christian On 18/02/2014 10:47 AM, Mary Barnes wrote: > Are you going to be at the meeting to lead the discussion? There has > been very little discussion of this document on the mailing so it's > not clear how much we gain from using face to face time to discuss > this document. > > Mary. > > > On Sun, Feb 16, 2014 at 5:40 PM, Christian Groves > > > wrote: > > Hello Mary and Paul, > > Will draft-groves-clue-latent-config-00 > be > covered under the signalling discussions? > > Regards, Christian > > > On 12/02/2014 2:43 AM, Mary Barnes wrote: > > As a reminder, the draft deadline for the London meeting is > this Friday (Feb. 14th), so you don't get the usual weekend to > work up to a Monday deadline: > http://www.ietf.org/meeting/important-dates-2014.html#IETF89 > > Note also that a draft agenda is due on Monday, Feb. 17th, so > the chairs will put one together based on the current set of > work items. If you have something beyond that, please let us > know ASAP. > > Thanks, > Mary. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From nobody Mon Feb 17 18:44:30 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BC71A02E3 for ; Mon, 17 Feb 2014 18:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3-LS7QCrF-d for ; Mon, 17 Feb 2014 18:44:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ED34B1A02DA for ; Mon, 17 Feb 2014 18:44:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBF76456; Tue, 18 Feb 2014 02:44:22 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 02:44:12 +0000 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 02:44:19 +0000 Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.104]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 10:44:15 +0800 From: "Liuyan (Scarlett)" To: "Robert Hansen (rohanse2)" , "clue@ietf.org" Thread-Topic: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt Thread-Index: AQHPLFNPtjizIRivSk+9LydHq71N5A== Date: Tue, 18 Feb 2014 02:44:14 +0000 Message-ID: References: <20140214225946.25105.54093.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.137.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ONwUy0mSGIesoKE99wi_r4m4bpw Subject: Re: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 02:44:28 -0000 Hello Rob, Thanks for the update.=20 Section 3.2: In the event that the CLUE data channel is successfully negotiated,= a CLUE-enabled device MAY choose not to send media on the non-CLUE- controlled channels during the period in which control of the CLUE- controlled media lines is negotiated. However, a CLUE-enabled devi= ce MUST still be prepared to receive media on non-CLUE-controlled medi= a lines as defined in [RFC3264]. I am a little confused about the first sentence. What do you mean about= non-CLUE-controlled channels? If you mean the data channels such as webrtc data channel, the webrtc d= ata channel is for non-media transport and not for media. The draft-ietf-rtcweb-data-channel-06 draft does say in abstract: This document specifies the non-media data transport aspects of th= e RTCWeb framework. =20 Best Regards, Scarlett -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Robert Hansen (rohan= se2) Sent: Saturday, February 15, 2014 4:31 PM To: clue@ietf.org Subject: [clue] FW: New Version Notification for draft-kyzivat-clue-signali= ng-07.txt This update doesn't propose masses of new content, instead it is mostly rem= oving discussion of issues like encoding limits in favour of more normative= language, expanding the section on changing clue status mid-call and inter= op with non-CLUE devices, and rearranging the draft to focus more on the de= cisions made. Rob -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: 14 February 2014 23:00 To: Lennard Xiao; Paul Kyzivat; Lennard Xiao; Robert Hansen (rohanse2); Rob= ert Hansen (rohanse2); Christian Groves; Christian Groves; Paul Kyzivat Subject: New Version Notification for draft-kyzivat-clue-signaling-07.txt A new version of I-D, draft-kyzivat-clue-signaling-07.txt has been successfully submitted by Robert Hansen and posted to the IETF rep= ository. Name: draft-kyzivat-clue-signaling Revision: 07 Title: CLUE Signaling Document date: 2014-02-14 Group: Individual Submission Pages: 37 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-sign= aling-07.txt Status: https://datatracker.ietf.org/doc/draft-kyzivat-clue-signali= ng/ Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-07 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-kyzivat-clue-signa= ling-07 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.presta-clue-protocol] and the CLUE data channel [I-D.holmberg-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. = =20 Please note that it may take a couple of minutes from the time of submissio= n 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 nobody Mon Feb 17 19:17:45 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448E01A031C for ; Mon, 17 Feb 2014 19:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNwS2fMbDRhc for ; Mon, 17 Feb 2014 19:17:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DBDF91A0422 for ; Mon, 17 Feb 2014 19:17:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDR66955; Tue, 18 Feb 2014 03:17:36 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 03:17:28 +0000 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 03:17:35 +0000 Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.104]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 11:17:28 +0800 From: "Liuyan (Scarlett)" To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt Thread-Index: AQHPLARbkYkJTEV26kCqjPgvxddnbpq6UbJg Date: Tue, 18 Feb 2014 03:17:27 +0000 Message-ID: References: <20140214225946.25105.54093.idtracker@ietfa.amsl.com> <53024469.5000903@alum.mit.edu> In-Reply-To: <53024469.5000903@alum.mit.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.137.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/clue/pPT0rDIxPEpr2vG_EeoNrVaF3dI Subject: Re: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 03:17:43 -0000 Hi Paul, Please see as below. Thanks. Best Regards Scarlett -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, February 18, 2014 1:19 AM To: clue@ietf.org Subject: Re: [clue] FW: New Version Notification for draft-kyzivat-clue-sig= naling-07.txt Rob, Thanks for the update. A few comments: Section 3.2: In the event that the CLUE data channel is successfully negotiated, a CLUE-enabled device MAY choose not to send media on the non-CLUE- controlled channels during the period in which control of the CLUE- controlled media lines is negotiated. However, a CLUE-enabled device MUST still be prepared to receive media on non-CLUE-controlled media lines as defined in [RFC3264]. I think we need more words about this somewhere. If the non-clue m-lines re= main enabled but nothing is sent, we will probably start to get errors, and= those sessions will fail. And if media continues to be sent, even though t= he recipient doesn't want it, then that adds cost. ISTM that either these should be dropped (port=3D0) or set to a=3Dinactive = if they are not to be used. Both sides have some responsibility in this - to make their intent known. And if we don't specify what purpose these streams have once clue use begin= s, then it is hard to use these in an interoperable way. [Scarlett] Maybe the purpose for these streams before the negotiation for C= LUE are divided into two sets: meaningless or useful. Of course, which purpose will depend on the endpoints' behavior and policy.= If they are meaningless, they should be dropped (port=3D0) or set to a=3Di= nactive. If they are useful, they should continue and will not be controlled by CLUE= . Section 4.1: The CLUE Framework [I-D.ietf-clue-framework] defines the concept of "encodings", which represent the sender's encode ability. Each encoding the media provider wishes to signal is signalled via an "m" line of the appropriate media type, which MUST be marked as sendonly with the "a=3Dsendonly" attribute or as inactive with the "a=3Dinactive= " attribute. I'm uncomfortable with requiring an m-line with port for every encoding.=20 This requires assigning a pair of ports, maybe running ice on those ports, = and sending RTCP. Some possible ways to improve on this: - allow encodings to be offered with a zero port - use BUNDLE - use capneg, as Christian discusses in draft-groves-clue-latent-config Also in that section: Every "m" line representing a CLUE encoding SHOULD contain a "label" attribute as defined in [RFC4574]. This label is used to identify the encoding by the sender in CLUE ADVERTISEMENT messages and by the receiver in CLUE CONFIGURE messages. I think SHOULD must be MUST. Without the label the m-line doesn't represent= an encoding. Thanks, Paul On 2/15/14 3:30 AM, Robert Hansen (rohanse2) wrote: > This update doesn't propose masses of new content, instead it is mostly r= emoving discussion of issues like encoding limits in favour of more normati= ve language, expanding the section on changing clue status mid-call and int= erop with non-CLUE devices, and rearranging the draft to focus more on the = decisions made. > > Rob > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 14 February 2014 23:00 > To: Lennard Xiao; Paul Kyzivat; Lennard Xiao; Robert Hansen=20 > (rohanse2); Robert Hansen (rohanse2); Christian Groves; Christian=20 > Groves; Paul Kyzivat > Subject: New Version Notification for=20 > draft-kyzivat-clue-signaling-07.txt > > > A new version of I-D, draft-kyzivat-clue-signaling-07.txt > has been successfully submitted by Robert Hansen and posted to the IETF r= epository. > > Name: draft-kyzivat-clue-signaling > Revision: 07 > Title: CLUE Signaling > Document date: 2014-02-14 > Group: Individual Submission > Pages: 37 > URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-si= gnaling-07.txt > Status: https://datatracker.ietf.org/doc/draft-kyzivat-clue-signa= ling/ > Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-0= 7 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-kyzivat-clue-sig= naling-07 > > Abstract: > This document specifies how CLUE-specific signaling such as the CLUE > protocol [I-D.presta-clue-protocol] and the CLUE data channel > [I-D.holmberg-clue-datachannel] are used with each other and with > existing signaling mechanisms such as SIP and SDP to produce a > telepresence call. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Tue Feb 18 04:40:15 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9761A0319 for ; Tue, 18 Feb 2014 04:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.704 X-Spam-Level: X-Spam-Status: No, score=-6.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edi86K5jtCpA for ; Tue, 18 Feb 2014 04:40:11 -0800 (PST) Received: from aer-iport-4.cisco.com (unknown [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0731A01B5 for ; Tue, 18 Feb 2014 04:40:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4305; q=dns/txt; s=iport; t=1392727208; x=1393936808; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=fp8C+X80dkbWTt7ugr+zw9fZd0IwA7QNGzey2kURRGk=; b=QLmsuf5iVx9CpiikkB6hEnoTp4hzXyc7DphHQwxw5elc+J5BQ3wg7opq YP7I04ihM84UU/lUngKCWZP++RqUoX3T+sn59FTvfjRR5Kw9xfyZiSpiP ZfUNV2qtbgJYFgME7hzlPe5RgcQa8aAZo4GUH9ByNOv5D9YelL3lQ1UZn k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFALBTA1OQ/khM/2dsb2JhbABZgwY4Ub9WgRUWdIIlAQEBBAEBATU2CQENBAsRBAEBAQkWCAcJAwIBAgEVHwgBCAYBDAYCAQEFh3wIBctJF44/SQaEMgEDmCyBMoUVi1yDLTyBLg X-IronPort-AV: E=Sophos;i="4.97,501,1389744000"; d="scan'208";a="635768" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-4.cisco.com with ESMTP; 18 Feb 2014 12:40:06 +0000 Received: from [10.47.197.27] ([10.47.197.27]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1ICe3SZ009603; Tue, 18 Feb 2014 12:40:06 GMT Message-ID: <530354AA.6010403@cisco.com> Date: Tue, 18 Feb 2014 12:40:10 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Liuyan (Scarlett)" , "clue@ietf.org" References: <20140214225946.25105.54093.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/clue/KOgboljEH-Yhl6dzZ_u9wrQoqzM Subject: Re: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 12:40:14 -0000 Hi Scarlett, There's a 'CLUE-controlled media' term in the terminology section, defining it as being a media line under the control of CLUE as defined in section 4 of the document (contains an mid value that is part of a CLUE group). The terminonology also mentions that: 'There is a corresponding "non-CLUE-controlled" media term' Which I confess I didn't really define, but intended to be the opposite: any media stream that isn't defined by the grouping framework as being under CLUE control. The intent of the sentence was that if two CLUE-enabled devices are in a call and have successfully negotiated the CLUE data channel, they may wish to send no media while the CLUE signalling negotiation is ongoing and only start sending audio and video once they have negotiated how many streams are wanted and what they should contain (as opposed to sending one audio and one video stream as cut-through media, and then upgrading the call to multiple audio/video streams). Rob On 18/02/2014 02:44, Liuyan (Scarlett) wrote: > Hello Rob, > > Thanks for the update. > > Section 3.2: > > In the event that the CLUE data channel is successfully negotiated, a > CLUE-enabled device MAY choose not to send media on the non-CLUE- > controlled channels during the period in which control of the CLUE- > controlled media lines is negotiated. However, a CLUE-enabled device > MUST still be prepared to receive media on non-CLUE-controlled media > lines as defined in [RFC3264]. > > I am a little confused about the first sentence. What do you mean about non-CLUE-controlled channels? > If you mean the data channels such as webrtc data channel, the webrtc data channel is for non-media transport and not for media. > The draft-ietf-rtcweb-data-channel-06 draft does say in abstract: > This document specifies the non-media data transport aspects of the RTCWeb framework. > > Best Regards, > Scarlett > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Robert Hansen (rohanse2) > Sent: Saturday, February 15, 2014 4:31 PM > To: clue@ietf.org > Subject: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt > > This update doesn't propose masses of new content, instead it is mostly removing discussion of issues like encoding limits in favour of more normative language, expanding the section on changing clue status mid-call and interop with non-CLUE devices, and rearranging the draft to focus more on the decisions made. > > Rob > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 14 February 2014 23:00 > To: Lennard Xiao; Paul Kyzivat; Lennard Xiao; Robert Hansen (rohanse2); Robert Hansen (rohanse2); Christian Groves; Christian Groves; Paul Kyzivat > Subject: New Version Notification for draft-kyzivat-clue-signaling-07.txt > > > A new version of I-D, draft-kyzivat-clue-signaling-07.txt > has been successfully submitted by Robert Hansen and posted to the IETF repository. > > Name: draft-kyzivat-clue-signaling > Revision: 07 > Title: CLUE Signaling > Document date: 2014-02-14 > Group: Individual Submission > Pages: 37 > URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-07.txt > Status: https://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling/ > Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-07 > Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-07 > > Abstract: > This document specifies how CLUE-specific signaling such as the CLUE > protocol [I-D.presta-clue-protocol] and the CLUE data channel > [I-D.holmberg-clue-datachannel] are used with each other and with > existing signaling mechanisms such as SIP and SDP to produce a > telepresence call. > > > > > 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 nobody Tue Feb 18 04:55:24 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CCB1A03E4 for ; Tue, 18 Feb 2014 04:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJYhclFfJeEu for ; Tue, 18 Feb 2014 04:55:19 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1941A04BE for ; Tue, 18 Feb 2014 04:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6986; q=dns/txt; s=iport; t=1392728116; x=1393937716; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=j06WXvu7aFOXjV/xWeRgQjqbaTHMIM/OIKxp6xcBS98=; b=RyUy9RTqm1/9RUoVkMUoCPEBqrdHJW2Y1/HqnbzT38u+CdJxK/sBEKw3 Xf7JqPHCqcZ9Xa2RAl2UxoR9x65eymOChUb2FlNI+yqiLdYV78o/BneF/ ogV4UOHdN88IdaaQm7jrWlSoHrGrWoWnrWt1I9P7JHqr7IZqjaXJBzsvn U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFAKVXA1OQ/khM/2dsb2JhbABPCoMGOFG/VoEVFnSCJQEBAQMBAQEBNTYJAQYHBAsRBAEBAQkWCAcJAwIBAgEVHwgBCBMGAgEBBYd0CAgFy1AXjiVjBoQyAQOYLIEyhRWLXIMtPA X-IronPort-AV: E=Sophos;i="4.97,501,1389744000"; d="scan'208";a="4725033" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 18 Feb 2014 12:55:15 +0000 Received: from [10.47.197.27] ([10.47.197.27]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1ICtF4V016718 for ; Tue, 18 Feb 2014 12:55:15 GMT Message-ID: <5303583A.8070609@cisco.com> Date: Tue, 18 Feb 2014 12:55:22 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140214225946.25105.54093.idtracker@ietfa.amsl.com> <53024469.5000903@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/clue/WYYOPdXj2CKNAYYfD5LsC2-BfBA Subject: Re: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 12:55:22 -0000 Hi Paul, Scarlett, Comments inline. On 18/02/2014 03:17, Liuyan (Scarlett) wrote: > Hi Paul, > > Please see as below. Thanks. > > Best Regards > Scarlett > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, February 18, 2014 1:19 AM > To: clue@ietf.org > Subject: Re: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt > > Rob, > > Thanks for the update. A few comments: > > Section 3.2: > > In the event that the CLUE data channel is successfully negotiated, a > CLUE-enabled device MAY choose not to send media on the non-CLUE- > controlled channels during the period in which control of the CLUE- > controlled media lines is negotiated. However, a CLUE-enabled device > MUST still be prepared to receive media on non-CLUE-controlled media > lines as defined in [RFC3264]. > > I think we need more words about this somewhere. If the non-clue m-lines remain enabled but nothing is sent, we will probably start to get errors, and those sessions will fail. And if media continues to be sent, even though the recipient doesn't want it, then that adds cost. > > ISTM that either these should be dropped (port=0) or set to a=inactive if they are not to be used. Both sides have some responsibility in this > - to make their intent known. > > And if we don't specify what purpose these streams have once clue use begins, then it is hard to use these in an interoperable way. > [Scarlett] Maybe the purpose for these streams before the negotiation for CLUE are divided into two sets: meaningless or useful. > Of course, which purpose will depend on the endpoints' behavior and policy. If they are meaningless, they should be dropped (port=0) or set to a=inactive. > If they are useful, they should continue and will not be controlled by CLUE. [Rob] Paul, I think you're right that we need explicit language recommending what to do with the nonCLUE audio/video streams once CLUE is brought up (currently all there is is that section on what happens with those streams *before* CLUE comes up). However, I don't think it should be mandatory; as Scarlett intimates there may be specific use cases where the system might still want to receive both CLUE and non-CLUE media. However, I do think that the majority of systems will want to disable their non-CLUE streams once CLUE comes up, and there should be text to that effect in the document. > Section 4.1: > > The CLUE Framework [I-D.ietf-clue-framework] defines the concept of > "encodings", which represent the sender's encode ability. Each > encoding the media provider wishes to signal is signalled via an "m" > line of the appropriate media type, which MUST be marked as sendonly > with the "a=sendonly" attribute or as inactive with the "a=inactive" > attribute. > > I'm uncomfortable with requiring an m-line with port for every encoding. > This requires assigning a pair of ports, maybe running ice on those ports, and sending RTCP. Some possible ways to improve on this: > - allow encodings to be offered with a zero port > - use BUNDLE > - use capneg, as Christian discusses in draft-groves-clue-latent-config [Rob] I agree with you on the costs if you have to have a unique port for each encoding, though it would be necessary if one side did not want to multiplex their media. Ultimately though we do want a way of multiplexing the media, but I think we'll probably still have an m-line per encoding (just not with a unique port each). > Also in that section: > > Every "m" line representing a CLUE encoding SHOULD contain a "label" > attribute as defined in [RFC4574]. This label is used to identify > the encoding by the sender in CLUE ADVERTISEMENT messages and by the > receiver in CLUE CONFIGURE messages. > > I think SHOULD must be MUST. Without the label the m-line doesn't represent an encoding. [Rob] I put this as a SHOULD rather than a MUST as I felt there might be systems that wanted to define their encoding capabilities in a static fashion, even in cases where they didn't have capture devices connected that could use some of those encodings. As such, it was either a case of not having a label for some encodings, or having a label but not referring to it in the CLUE ADVERTISEMENT. The latter, making label mandatory for CLUE-controlled "m" lines, is probably a better way of illustrating this, though. > Thanks, > Paul > > > On 2/15/14 3:30 AM, Robert Hansen (rohanse2) wrote: >> This update doesn't propose masses of new content, instead it is mostly removing discussion of issues like encoding limits in favour of more normative language, expanding the section on changing clue status mid-call and interop with non-CLUE devices, and rearranging the draft to focus more on the decisions made. >> >> Rob >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: 14 February 2014 23:00 >> To: Lennard Xiao; Paul Kyzivat; Lennard Xiao; Robert Hansen >> (rohanse2); Robert Hansen (rohanse2); Christian Groves; Christian >> Groves; Paul Kyzivat >> Subject: New Version Notification for >> draft-kyzivat-clue-signaling-07.txt >> >> >> A new version of I-D, draft-kyzivat-clue-signaling-07.txt >> has been successfully submitted by Robert Hansen and posted to the IETF repository. >> >> Name: draft-kyzivat-clue-signaling >> Revision: 07 >> Title: CLUE Signaling >> Document date: 2014-02-14 >> Group: Individual Submission >> Pages: 37 >> URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-07.txt >> Status: https://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling/ >> Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-07 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-07 >> >> Abstract: >> This document specifies how CLUE-specific signaling such as the CLUE >> protocol [I-D.presta-clue-protocol] and the CLUE data channel >> [I-D.holmberg-clue-datachannel] are used with each other and with >> existing signaling mechanisms such as SIP and SDP to produce a >> telepresence call. >> >> >> >> >> 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 >> > > _______________________________________________ > 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 nobody Tue Feb 18 05:38:35 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0F61A0661 for ; Tue, 18 Feb 2014 05:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNNsq2prdVHK for ; Tue, 18 Feb 2014 05:38:31 -0800 (PST) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBA41A064A for ; Tue, 18 Feb 2014 05:38:31 -0800 (PST) Received: by mail-yh0-f50.google.com with SMTP id 29so15445036yhl.37 for ; Tue, 18 Feb 2014 05:38:28 -0800 (PST) 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=QetQ7CDWau8pKzQU9qVf/c+PEJwKLSDZfe2B1OVllAU=; b=Nb6bbCDPUoqyVAtYyYG4tyD2bM8jbjlAPsCm0rqbIvBKVVEAzl1O6sljAw/IGm6Crg 7DJ11ICsoZJPRm7vUzJ5smpZsnwaw/1bxcmme0heeIf1koQrklmhYbvXq1Gy1YDDSS9x iQvrfcLlDbdfa0LOOT/FV0ikFUVzRsoJPvnRJfrTFd6pGAKaAQAMOPlsOSCH+5sDUqTm 3WJXLT6cEIdoqM/GjsyPF4MxnWZmey13wDYZM5lRN/ucJcktXbPzwSYhVk9pt+wRMCR6 19ljY4fPB5/OZ4yB/232JOXynzvMjqffDbgvpo8Rnve2V17zuzrAIQCeOfX1G18Fdx/p yVyQ== MIME-Version: 1.0 X-Received: by 10.236.21.202 with SMTP id r50mr3152312yhr.140.1392730708217; Tue, 18 Feb 2014 05:38:28 -0800 (PST) Received: by 10.170.213.85 with HTTP; Tue, 18 Feb 2014 05:38:28 -0800 (PST) In-Reply-To: <5302A41D.4090202@nteczone.com> References: <53014C5F.3060405@nteczone.com> <5302A41D.4090202@nteczone.com> Date: Tue, 18 Feb 2014 07:38:28 -0600 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=089e015385fc2199b304f2ae63e4 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/58WHpaFIrpHDt56FD1LbdG-uE1A Cc: CLUE Subject: Re: [clue] Reminder: draft deadline for IETF-89 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 13:38:34 -0000 --089e015385fc2199b304f2ae63e4 Content-Type: text/plain; charset=ISO-8859-1 Okay. We'll try to work this into the agenda - right after Rob discusses the signaling. Thanks, Mary. On Mon, Feb 17, 2014 at 6:06 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mary, > > Yes I will be at the meeting. There's been very little discussion about > signalling in general (apart from the SCTP transport issue). I'd encourage > people to read the draft before hand and send any comments to the list. > > Regards, Christian > > > On 18/02/2014 10:47 AM, Mary Barnes wrote: > >> Are you going to be at the meeting to lead the discussion? There has >> been very little discussion of this document on the mailing so it's not >> clear how much we gain from using face to face time to discuss this >> document. >> >> Mary. >> >> >> On Sun, Feb 16, 2014 at 5:40 PM, Christian Groves < >> Christian.Groves@nteczone.com > >> wrote: >> >> Hello Mary and Paul, >> >> Will draft-groves-clue-latent-config-00 >> >> be >> covered under the signalling discussions? >> >> Regards, Christian >> >> >> On 12/02/2014 2:43 AM, Mary Barnes wrote: >> >> As a reminder, the draft deadline for the London meeting is >> this Friday (Feb. 14th), so you don't get the usual weekend to >> work up to a Monday deadline: >> http://www.ietf.org/meeting/important-dates-2014.html#IETF89 >> >> Note also that a draft agenda is due on Monday, Feb. 17th, so >> the chairs will put one together based on the current set of >> work items. If you have something beyond that, please let us >> know ASAP. >> >> Thanks, >> Mary. >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> >> https://www.ietf.org/mailman/listinfo/clue >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> > --089e015385fc2199b304f2ae63e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Okay. We'll try to work this into the agenda - right a= fter Rob discusses the signaling.=A0

Thanks,
M= ary.


On Mon, Feb 17, 2014 at 6:06 PM, Christian Groves <= Christia= n.Groves@nteczone.com> wrote:
Hello Mary,

Yes I will be at the meeting. There's been very little discussion about= signalling in general (apart from the SCTP transport issue). I'd encou= rage people to read the draft before hand and send any comments to the list= .

Regards, Christian


On 18/02/2014 10:47 AM, Mary Barnes wrote:
Are you going to be at the meeting to lead the discussion? =A0There has bee= n very little discussion of this document on the mailing so it's not cl= ear how much we gain from using face to face time to discuss this document.=

Mary.


On Sun, Feb 16, 2014 at 5:40 PM, Christian Groves <Christian.Groves@nteczone.com= <mailto:Christian.Groves@nteczone.com>> wrote:

=A0 =A0 Hello Mary and Paul,

=A0 =A0 Will draft-groves-clue-latent-config-00
=A0 =A0 <https://datatracker.ietf.org/doc/dr= aft-groves-clue-latent-config/> be
=A0 =A0 covered under the signalling discussions?

=A0 =A0 Regards, Christian


=A0 =A0 On 12/02/2014 2:43 AM, Mary Barnes wrote:

=A0 =A0 =A0 =A0 As a reminder, the draft deadline for the London meeting is=
=A0 =A0 =A0 =A0 this Friday (Feb. 14th), so you don't get the usual wee= kend to
=A0 =A0 =A0 =A0 work up to a Monday deadline:
=A0 =A0 =A0 =A0 http://www.ietf.org/meeting/importan= t-dates-2014.html#IETF89

=A0 =A0 =A0 =A0 Note also that a draft agenda is due on Monday, Feb. 17th, = so
=A0 =A0 =A0 =A0 the chairs will put one together based on the current set o= f
=A0 =A0 =A0 =A0 work items. =A0If you have something beyond that, please le= t us
=A0 =A0 =A0 =A0 know ASAP.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Mary.


=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 clue mailing list
=A0 =A0 clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/listinfo/clue




--089e015385fc2199b304f2ae63e4-- From nobody Tue Feb 18 14:32:16 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726D21A0296 for ; Tue, 18 Feb 2014 14:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doXspSZ5azed for ; Tue, 18 Feb 2014 14:32:13 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id F40411A0298 for ; Tue, 18 Feb 2014 14:32:12 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id ToSp1n0021ap0As5DyY9ta; Tue, 18 Feb 2014 22:32:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id TyY91n00R3ZTu2S3iyY9KT; Tue, 18 Feb 2014 22:32:09 +0000 Message-ID: <5303DF69.5060001@alum.mit.edu> Date: Tue, 18 Feb 2014 17:32:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140214225946.25105.54093.idtracker@ietfa.amsl.com> <53024469.5000903@alum.mit.edu> <5303583A.8070609@cisco.com> In-Reply-To: <5303583A.8070609@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392762729; bh=MUpAc98LupPWd+SdMjE+Y0uwZtxjTmIWUYtnHzlbX0A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RFa6907U2Emd/jTZe2CIFQOV+x+fW38t0NVDHdoVxhP1DMh6SJVpR7/oVXKQKQrwM d3Ma436okg6fPo5fe6CwtsLYvXdzcGNvkSEK3gC9HUYvnapPurRKGcEbfkV2RfKniU noJIyBFHoMea/d/i24Bn2nOejZMz+R5mtAioB6gkDM+0KYtoz7ne5s7S86y5B1ap/g nn9huDKakLK15EX1ZcPj5pW4bAhoxpGyH4yyRDtrKJxh27E/MYvUADK2kDny2wYS1l gzebRi49BmMeMaNQdBr9Hzhotr87eywX3Z5gnpfEkaVYy6ZM032n4W2v2LboVateEx hRqBJ54YMqSWQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/DlC2RtbvwpUKT5uBej0aO_S7VGM Subject: Re: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 22:32:15 -0000 On 2/18/14 7:55 AM, Robert Hansen wrote: > [Rob] Paul, I think you're right that we need explicit language > recommending what to do with the nonCLUE audio/video streams once CLUE > is brought up (currently all there is is that section on what happens > with those streams *before* CLUE comes up). However, I don't think it > should be mandatory; as Scarlett intimates there may be specific use > cases where the system might still want to receive both CLUE and > non-CLUE media. However, I do think that the majority of systems will > want to disable their non-CLUE streams once CLUE comes up, and there > should be text to that effect in the document. I agree that we should not be normative about what is done with the non-clue media, but we should give some guidelines. (E.g., either set the port to zero or add a=inactive.) IMO it should be *permissible* to repurpose them as clue-m-lines, after clue has been negotiated. We don't really have to say anything about that. They will just be additional m-lines added to the clue group in a subsequent O/A. >> Section 4.1: >> >> The CLUE Framework [I-D.ietf-clue-framework] defines the concept of >> "encodings", which represent the sender's encode ability. Each >> encoding the media provider wishes to signal is signalled via an "m" >> line of the appropriate media type, which MUST be marked as sendonly >> with the "a=sendonly" attribute or as inactive with the "a=inactive" >> attribute. >> >> I'm uncomfortable with requiring an m-line with port for every encoding. >> This requires assigning a pair of ports, maybe running ice on those >> ports, and sending RTCP. Some possible ways to improve on this: >> - allow encodings to be offered with a zero port >> - use BUNDLE >> - use capneg, as Christian discusses in draft-groves-clue-latent-config > > [Rob] I agree with you on the costs if you have to have a unique port > for each encoding, though it would be necessary if one side did not want > to multiplex their media. Ultimately though we do want a way of > multiplexing the media, but I think we'll probably still have an m-line > per encoding (just not with a unique port each). Yes. My point here is that I think it would be good to allow encodings that can be referenced from advertisements but aren't ready to be used. This can be by having them in the SDP with a zero port, or by use of latent-configs. >> Also in that section: >> >> Every "m" line representing a CLUE encoding SHOULD contain a "label" >> attribute as defined in [RFC4574]. This label is used to identify >> the encoding by the sender in CLUE ADVERTISEMENT messages and by the >> receiver in CLUE CONFIGURE messages. >> >> I think SHOULD must be MUST. Without the label the m-line doesn't >> represent an encoding. > > [Rob] I put this as a SHOULD rather than a MUST as I felt there might be > systems that wanted to define their encoding capabilities in a static > fashion, even in cases where they didn't have capture devices connected > that could use some of those encodings. As such, it was either a case of > not having a label for some encodings, or having a label but not > referring to it in the CLUE ADVERTISEMENT. The latter, making label > mandatory for CLUE-controlled "m" lines, is probably a better way of > illustrating this, though. So you are talking about m-lines that are in the clue group, but don't have labels. I guess that would work. Or they could also be in the clue group, *with* labels, but without any references to those labels in the advertisement. But I still take issue with your wording. Even if the m-line is in the clue group, it doesn't represent an encoding unless it has a label that is referenced from an Advertisement. If it has a label that isn't referenced from an advertisement then it *could* represent an encoding in the future. If it has no label, then it cannot represent an encoding until it is updated to contain a label. So I still think that "SHOULD" should be a "MUST. Then you *could* add: Every CLUE-controlled "m" line SHOULD contain a "label" attribute as defined in [RFC4574]. But I don't really think that adds anything. Thanks, Paul >> Thanks, >> Paul >> >> >> On 2/15/14 3:30 AM, Robert Hansen (rohanse2) wrote: >>> This update doesn't propose masses of new content, instead it is >>> mostly removing discussion of issues like encoding limits in favour >>> of more normative language, expanding the section on changing clue >>> status mid-call and interop with non-CLUE devices, and rearranging >>> the draft to focus more on the decisions made. >>> >>> Rob >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: 14 February 2014 23:00 >>> To: Lennard Xiao; Paul Kyzivat; Lennard Xiao; Robert Hansen >>> (rohanse2); Robert Hansen (rohanse2); Christian Groves; Christian >>> Groves; Paul Kyzivat >>> Subject: New Version Notification for >>> draft-kyzivat-clue-signaling-07.txt >>> >>> >>> A new version of I-D, draft-kyzivat-clue-signaling-07.txt >>> has been successfully submitted by Robert Hansen and posted to the >>> IETF repository. >>> >>> Name: draft-kyzivat-clue-signaling >>> Revision: 07 >>> Title: CLUE Signaling >>> Document date: 2014-02-14 >>> Group: Individual Submission >>> Pages: 37 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-07.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-kyzivat-clue-signaling-07 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-07 >>> >>> Abstract: >>> This document specifies how CLUE-specific signaling such as the >>> CLUE >>> protocol [I-D.presta-clue-protocol] and the CLUE data channel >>> [I-D.holmberg-clue-datachannel] are used with each other and with >>> existing signaling mechanisms such as SIP and SDP to produce a >>> telepresence call. >>> >>> >>> >>> >>> 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 >>> >> >> _______________________________________________ >> 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 nobody Tue Feb 18 15:23:45 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0A51A02D9 for ; Tue, 18 Feb 2014 15:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8TRuYdd4tOY for ; Tue, 18 Feb 2014 15:23:43 -0800 (PST) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 525C61A0282 for ; Tue, 18 Feb 2014 15:23:43 -0800 (PST) Received: by mail-yh0-f49.google.com with SMTP id t59so16024427yho.22 for ; Tue, 18 Feb 2014 15:23:40 -0800 (PST) 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=nlfZn25mn3wHIm1TloURsDMjSWMQjSdUei0t3qxz7SQ=; b=Yyfd7Q4oXVQPF/+hkoFDXR7j06l7wS6qG1cCunSCPV5FBI6DEPWfQmSJZKgUXfogNc qPX1EOeU9cxmZWqe1C5VTqqKexFcLOf95IXqzcHHznQSrHpCKDgrGfIAhp7HhiEif3My O/FrZQLIyQM/sh6udgZz088tLfOpvZOB2pHeQNNTzWduy/SsbZY6C5J3mO0A4XgDT/sW ezRzACOtwLLW6dudS9PjDRLymsgNlp8nVInfq7F+IZUuWxVy2G7I4MO1mq2prXpZzDmz eAosPLrgxpvi6G2/hYCOjeTt5c23iSpq/R2QnFlgJRHvz+XfNs466nrcKm65lr9RuRKx F06Q== MIME-Version: 1.0 X-Received: by 10.236.21.202 with SMTP id r50mr203972yhr.140.1392765820178; Tue, 18 Feb 2014 15:23:40 -0800 (PST) Received: by 10.170.213.85 with HTTP; Tue, 18 Feb 2014 15:23:40 -0800 (PST) Date: Tue, 18 Feb 2014 17:23:40 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e015385fcf795dc04f2b68fa6 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/pmI1eY_hCBOh0De_9ASPyfalHEI Subject: [clue] Agenda for IETF-89 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 23:23:45 -0000 --089e015385fcf795dc04f2b68fa6 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Paul and I have worked out agendas for our two meeting slots. We have one on Wednesday afternoon and another on Friday morning. http://www.ietf.org/proceedings/89/agenda/agenda-89-clue Along with the usual expectation that anyone participating in the discussions has read the relevant WG related drafts and mailing list, there are a couple of documents that have dependency on details in other documents. Links to those documents are included in the agenda. For example, if one has not read RFC 6871, then likely it's difficult to form an opinion on the proposal in draft-groves-clue-latent-config. Also, as seen by the mailing list discussion around the CLUE data channel there are several documents in other WGs that are important reading to prepare for participating in the discussion. As usual, mailing list discussion leading up to the meeting is always valuable. Regards, Mary. --089e015385fcf795dc04f2b68fa6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Paul and I have worked out agen= das for our two meeting slots. =A0We have one on Wednesday afternoon and an= other on Friday morning. =A0

Along with the usual expectation that anyone participat= ing in the discussions has read the relevant WG related drafts and mailing = list, there are a couple of documents that have dependency on details in ot= her documents. =A0Links to those documents are included in the agenda. For = example, if one has not read RFC 6871, then likely it's difficult to fo= rm an opinion on the proposal in draft-groves-clue-latent-config. =A0Also, = as seen by the mailing list discussion around the CLUE data channel there a= re several documents in other WGs that are important reading to prepare for= participating in the discussion.=A0

As usual, mailing list discussion leading up to t= he meeting is always valuable.

Regards,
= Mary.=A0

--089e015385fcf795dc04f2b68fa6-- From nobody Wed Feb 19 13:12:30 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AB81A0226 for ; Wed, 19 Feb 2014 13:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGxnYJH8Ak02 for ; Wed, 19 Feb 2014 13:12:19 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8A71A0605 for ; Wed, 19 Feb 2014 13:12:19 -0800 (PST) Received: from PWEHUB01.polycom.com (10.236.2.221) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 19 Feb 2014 13:12:06 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Wed, 19 Feb 2014 13:12:05 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 19 Feb 2014 13:12:01 -0800 Thread-Topic: [clue] Maxcaptures in MCC, vs. switched and composed attributes Thread-Index: Ac8l/aYowSrtr9wdS4Ce9jwlQLgdRgHt0Hlg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D4E9F7F@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB54F@CRPMBOXPRD07.polycom.com> <52F82841.5010001@nteczone.com> In-Reply-To: <52F82841.5010001@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 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/7UvM18hzRI64uAXkH5rymPpf4wA Subject: Re: [clue] Maxcaptures in MCC, vs. switched and composed attributes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 21:12:24 -0000 We discussed this at the Feb 11 design team meeting but didn't come to any = conclusion, either about the switched and composed attributes, or about the= "=3D" and "<=3D" qualifier for maxCaptures. I can't find minutes of the m= eeting, so I'm going by my memory here. I still think the default is to make no changes unless there is stronger su= pport from the group for a change. Jonathan said he wanted to know more about how/why Christian's proposed "<= =3D" qualifier for the maxCaptures attribute would be used. In comparing the maxCaptures attribute to the composed and switched attribu= tes, we thought the usefulness of composed and switched was for the case wh= en both are true. It doesn't have to be just one or the other. There coul= d be switching within a composition. If the advertisement has an MCC witho= ut specifying constituent captures, and maxCaptures > 1, there is no way to= tell if the provider will do switching (if we don't add the switched attri= bute). We could add the switched attribute to allow the provider to expres= s this. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Sunday, February 09, 2014 8:16 PM > To: clue@ietf.org > Subject: Re: [clue] Maxcaptures in MCC, vs. switched and composed > attributes >=20 > Hello >=20 > I don't think removal of MaxCaptures is an option. I gave an example to P= aul > why its needed. It was buried deep in an email thread so i'll repeat it h= ere: >=20 > I see there is benefit in giving the Advertiser and the Consumer the mean= s of > knowing how many captures will appear in the stream at a time. > It gives the ability for the Consumer to distinguish between MCCs. >=20 > For example: > What if the Advertiser combines two sources set but switches the sources? > i.e. > MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=3D2 Are bot= h > the "switched" and "composed" attributes valid? > MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Switched,Composed >=20 > How about the case where the Advertiser composes 4 sources into a media > stream switches those sources? > MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=3D4 Using t= he > composed and switched attributes: > MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Switched,Composed >=20 > Now how does a consumer distinguish between MCC1, MCC2 in this case? I > think its a valid decision for a Consumer to make it determine how many > sources it wants to see at a particular time. It can't use the spatial in= formation > because we've disallowed that. I don't think the "switched" > and "composed" attributes can model that. >=20 >=20 >=20 > Regards, Christian >=20 >=20 > On 8/02/2014 3:26 AM, Duckworth, Mark wrote: > > I'm trying to summarize a couple of related proposals here. > > 1. Add ability for advertiser to indicate if the number of captures in = an MCC > at any given time will always be equal to MaxCaptures, or if it can be le= ss. > Details below from Christian. > > 2. Add Switched and Composed attributes to MCC, just like we used to > have for all captures. This is proposed in draft-ietf-clue-data-model-sc= hema- > 03. Maybe remove the MaxCaptures attribute if we add switched and > composed. > > > > We can do one or the other, or both, or neither. Any of those choices = is > okay with me, I personally have no strong argument either way. I think > others in the group have stronger preferences. I think the default is to= do > neither, unless there is consensus to change. Please continue the discus= sion > so we can figure out if any change is needed in the framework and data > model. > > > > Regards, > > Mark > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >> Groves > >> Sent: Thursday, February 06, 2014 11:50 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] Maxcaptures in MCC > >> > >> Hello Mark, > >> > >> To be more concrete here's the text I would propose for the framework: > >> > >> 7.2.1.1. Maximum Number of Captures within a MCC > >> > >> The Maximum Number of Captures MCC attribute indicates the > maximum > >> number of individual captures that may appear in a Capture Encodi= ng > >> at a time. <>> the > >> actual number at any given time can be less than > >> this maximum. It may be used to derive how the Single Media > >> Captures within the MCC are composed / switched with regards to > >> space and time. < >> captures is equal > >> to the maximum the Consumer MUST not choose a subset of captures > >> from the MCC in a > >> Configure message.>> > >> > >> Max Captures MAY be set to one so that only content related to on= e > >> of the sources are shown in the MCC Capture Encoding at a time or > >> it may be set to any value up to the total number of Source Media > >> Captures in the MCC. > >> > >> If this attribute is not set then as default it is assumed that > >> <> > >> can appear concurrently in the Capture Encoding associated with t= he > MCC. > >> > >> For example: The use of MaxCaptures equal to 1 on a MCC with thre= e > >> Video Captures VC1, VC2 and VC3 would indicate that the Advertise= r > >> in the capture encoding would switch between VC1, VC2 or VC3 as > >> there may be only a maximum of one capture at a time. > >> > >> Regards, Christian > >> > >> On 7/02/2014 11:45 AM, Christian Groves wrote: > >>> Hello Mark, > >>> > >>> My proposed improvement is to update the MaxCaptures parameter > add > >> the > >>> possibility to indicate indicate that the value is "equal to" as > >>> well as allowing the specification as per today "less than or equal t= o". > >>> > >>> Regards, Christian > >>> > >>> On 7/02/2014 3:55 AM, Duckworth, Mark wrote: > >>>> Hi Christian, > >>>> > >>>> I think I understand the general idea you are getting at, but I > >>>> don't understand specifically what you are proposing as an > improvement. > >>>> More comments inline. > >>>> > >>>> Mark > >>>> > >>>>> -----Original Message----- > >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >>>>> Groves > >>>>> Sent: Wednesday, February 05, 2014 7:20 PM > >>>>> To: clue@ietf.org > >>>>> Subject: Re: [clue] Now Maxcaptures - Re: spatial information > >>>>> can't describe video locations within composed MCC > >>>>> > >>>>> Hello Paul and Mark, > >>>>> > >>>>> The Max-captures attributes currently indicates the maximum > number > >>>>> of captures that appears in a MCC at any particular point in time. > >>>>> > >>>>> i.e. MCC(VC1,VC2,VC3),MaxCaptures=3D3 So a Consumer has to assume > >>>>> because this is a maximum that VC1, VC2, VC3, (VC1,VC2), > >>>>> (VC1,VC3), (VC2,VC3) or (VC1,VC2,VC3) can appear at any point in > >>>>> time. > >>>> [Duckworth, Mark] I agree, that is consistent with framework-13. > >>>> > >>>>> However the Consumer only ever sends a composition of > >> (VC1,VC2,VC3). > >>>>> It is > >>>>> never going to change that combination. > >>>> [Duckworth, Mark] Do you mean the Provider will always send a > >>>> composition of (VC1,VC2,VC3)? And the provider would like to be > >>>> more explicit about this in the advertisement? > >>>> > >>>>> It seems to me that in this case > >>>>> using MaxCaptures as it is currently defined is semantically incorr= ect. > >>>> [Duckworth, Mark] I think it is correct, but maybe not giving as > >>>> much information as the provider wants to express. > >>> [CNG] I can't see its correct. If I tell you that I can do a set of > >>> behaviour but I only intend to do one then I don't think that's > >>> truthful. Sort of like telling you I'm coming to your house one day > >>> next week when in fact I only intend on coming on Friday. > >>>>> So what I am suggesting is simply to add a way to correctly > >>>>> indicate this "constant number of captures" case, i.e. (VC1,VC2,VC3= ). > >>>> [Duckworth, Mark] If I understand your suggestion correctly, then > >>>> one way to do that would be to add a new optional MinCaptures > >>>> attribute to an MCC. MinCaptures is the minimum number of > >>>> constituent captures that may appear in the MCC at a time. If this > >>>> attribute is not set, then it is assumed to have the default value > >>>> of 1. For this scenario, the value of both MinCaptures and > MaxCaptures would be 3. > >>>> Is this what you are suggesting, or do you have something else in mi= nd? > >>> [CNG] No all I had in mind was something like: > >>> MaxCaptures "=3D"/"<=3D" value > >>> The Advertiser would chose to indicate "equal" or "equal to > >>> or less than". > >>>>> I think Paul is questioning the attribute in general. I do believe > >>>>> that knowing the number of sources may be beneficial for a > >>>>> consumer in deciding which MCC/Captures to select. There may be > >>>>> tradeoffs vs a MCC only showing a limited number (i.e. one source) > >>>>> at a time vs another MCC showing multiple sources at a time. > >>> [CNG] I agree I think its beneficial. > >>>>> 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 > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Feb 19 13:36:30 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FA91A0226 for ; Wed, 19 Feb 2014 13:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXIQk1HuESEK for ; Wed, 19 Feb 2014 13:36:22 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 469C21A01C1 for ; Wed, 19 Feb 2014 13:36:22 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Wed, 19 Feb 2014 13:36:19 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Wed, 19 Feb 2014 13:36:15 -0800 Thread-Topic: [clue] How to choose from multiple scenes Thread-Index: Ac8nEGWWHzKHU/mJSnymAJGOYYZx0wGqPmVQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D4E9FAE@CRPMBOXPRD07.polycom.com> References: <52E6E683.8090905@alum.mit.edu> <52E72506.3080800@nteczone.com> <52F3C79E.7010903@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB703@CRPMBOXPRD07.polycom.com> <52F553B4.8070206@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB7FC@CRPMBOXPRD07.polycom.com> <52F6754A.3050501@alum.mit.edu> <52F823A1.3080308@nteczone.com> <52F90219.4070504@alum.mit.edu> <52F9F52F.9090705@nteczone.com> In-Reply-To: <52F9F52F.9090705@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 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/-6JL5PDD9uoluP10g6AVSwFzr5o Subject: Re: [clue] How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 21:36:28 -0000 Responses to Christian's comments below. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Tuesday, February 11, 2014 5:02 AM > To: clue@ietf.org > Subject: Re: [clue] How to choose from multiple scenes > > Hello Paul and Mark, > > Please see my comments below. > > Regards, Christian > > On 11/02/2014 3:45 AM, Paul Kyzivat wrote: > > On 2/9/14 7:56 PM, Christian Groves wrote: > >> Hello Paul, > >> > >> I think some uses cases would be good. > >> > >> I'd like to see a third case where we'd have something like a "Scene > >> Set Entry" (SSE). This would indicate what scenes would make up a "ful= l' > >> description of an endpoint. > >> > >> i.e. Scene1 (CSE1) > >> Scene2 (CSE2) > >> Scene3 (CSE3) > >> SSE [(Scene1,Scene2),(Scene1)] > >> A consumer would know it should pick CSE1 and CSE2 for a complete > >> description or CSE3. > >> > >> I think this is along the lines of your single CSE. > > > > IIUC, that is a way to distinguish which scenes need to be considered. > > Mentioned that as a possibility in passing in one of my messages. > [CNG] I thought that knowing which scenes go together was the core of the > issue. An Advertiser says here's the set of scenes that go together. [Duckworth, Mark] That's not what I was thinking. I thought the issue was = how the consumer could choose captures from multiple scenes when it is not = capable of choosing the "biggest" CSE from each scene. I don't think it is= about "which scenes go together". > The Advertiser uses the CSEs to indicate the different rendering options = for > each scene. [Duckworth, Mark] Yes. > > > > It still leaves the consumer with a combinatorial analysis. > > > > Another possibility is: > > > > - Leave existing per-scene CSE lists as-is. > > > > - Add another advertisement-wide CSE list. > > The entries in it could use shorthand, by referencing CSEs from > > the individual scenes. > > > > E.g., > > > > Scene1 (CSE11, CSE12, CSE13) > > Scene2 (CSE21, CSE22) > > Scene3 (CSE31) > > Scene4 (CSE41) > > > > Global-CSE-List ( > > CSEg1(CSE11, CSE21, CSE31) > > CSEg2(CSE12, CSE22, CSE31) > > CSEg3(CSE13, CSE22, CSE31) > > ) > [CNG] The issue is that currently we do not assign any sort of ID to CSEs= . > There hasn't been a reason to as the consumer selects the captures it wan= ts. > > I think the above complicates things. With this we are now saying that wh= ich > scenes are chosen depend on the rendering of each of the scenes. [Duckworth, Mark] I guess so, because if the consumer is limited in how man= y captures it can receive, then there is a tradeoff between receiving more = scenes with few captures per scene vs. fewer scenes with more captures per = scene. But I think Paul's proposal is simplifying this, not making it more= complicated. > Our current assumption is that a CSE represents the "whole scene". Each C= SE > is effectively a different rendering of this whole. [Duckworth, Mark] Yes > With the above we are now > changing that to imply that a CSE may be a part of a scene because which > other Scenes/CSEs you chose is based on that rendering. [Duckworth, Mark] No, a CSE is still representing a whole scene. > Its not a syntax issue only we're playing with the semantics of what we h= ave > also. [Duckworth, Mark] We are suggesting adding syntax and semantics so a provid= er can give more suggestions to a consumer, trying to make the consumer's c= hoice easier to make. Not changing any existing semantics. > > Here the global CSE list has recommended a subset of the possible > > combinations of CSEs from the different scenes, and has omitted Scene4 > > altogether. This is a value judgement of what combinations make sense. > > > > Note that I would still allow the CSEs in the global list to reference > > individual captures if desired. But referencing other CSEs is a > > convenient shorthand. > > > > Thanks, > > Paul > > > >> Regards, Christian > >> > >> On 9/02/2014 5:19 AM, Paul Kyzivat wrote: > >>> On 2/7/14 5:58 PM, Duckworth, Mark wrote: > >>>> Hi Paul, > >>>> Comments inline. > >>>> I'm open to your idea of a single set of CSEs across all scenes, > >>>> but I'm trying to understand if it will really be a scalable and > >>>> less complex way to solve these issues. > >>> > >>> Me too. I'm not certain that it will, but my gut says so. > >>> It just seems to me that the idea of enumerating useful combinations > >>> of captures in the advertisement is conceptually unrelated to what > >>> scene they are in, and that for the consumer the process then by > >>> default devolves to just choosing the one best cse that works for > >>> it, rather than having to choose from among combinations in > >>> different scenes. > >>> > >>>> Do you think it would help if you presented this idea at the design > >>>> team meeting next week? > >>> > >>> I'm not convinced that call time is very helpful for this. > >>> To be useful I would probably need to create several use cases, and > >>> show them both ways, and then for people to try to shoot them down. > >>> I think that kind of thing is better done by email. (And I don't > >>> have time to put together sufficient use cases before Tuesday.) > >>> > >>> More below. > >>> > >>>> Mark > >>>> > >>>>> -----Original Message----- > >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>>>> Sent: Friday, February 07, 2014 4:44 PM > >>>>> To: Duckworth, Mark; clue@ietf.org > >>>>> Subject: Re: [clue] How to choose from multiple scenes > >>>>> > >>>>> On 2/7/14 3:26 PM, Duckworth, Mark wrote: > >>>>>> Hi Paul, > >>>>>> > >>>>>> You describe the issue very well, but I don't agree with a couple > >>>>>> things. You > >>>>> wrote: > >>>>>>> ISTM that one should start out assuming that you need all > >>>>>>> captures (that have encodings) in *some* CSE from *each* scene. > >>>>>> I don't think that is an appropriate thing to assume. The case I > >>>>>> was thinking > >>>>> of, and we have been talking about at design team meetings, is > >>>>> like > >>>>> this: > >>>>>> Scene 1 - current active speaker > >>>>>> Scene 2 - previous active speaker Scene 3 - previous previous > >>>>>> active speaker and so on... > >>>>> > >>>>> I understand your *intent* here. But I don't know how the consumer > >>>>> acts on that. It is really part of the point I am trying to make. > >>>>> How does the consumer *know* the above, and take it into account? > >>>>> Are the *scenes* tagged to indicate that? (I don't think so.) > >>>> > >>>> [Duckworth, Mark] From the MCC policy attribute values. > >>>> > >>>>>> Where each scene could have multiple switched MCCs representing > >>>>>> the > >>>>> scene, and the provider has some flexibility to group together > >>>>> different individual captures to include in the MCCs of a scene, > >>>>> depending on synchID and who is talking. > >>>>>> In this case, because of the policy attributes describing the > >>>>>> MCCs, I think it > >>>>> makes perfect sense for a consumer to ask for all the video MCCs > >>>>> from Scene 1, and none of them from Scene 2 or Scene 3. The > >>>>> consumer has enough information to know this is a good choice if > >>>>> it wants to show video from the current active speaker, including > >>>>> multiple video captures with spatial relationship when the current > >>>>> speaker is in a multi-camera room. So in this case the consumer > >>>>> already has enough information to make a choice. > >>>>> > >>>>> I'm having difficulty imagining how to construct an algorithm for > >>>>> that. > >>>> > >>>> [Duckworth, Mark] Yeah, it can get complicated. But is it good > >>>> enough for equipment from different vendors to interoperate in a > >>>> reasonable way, even if it isn't the "best" way? I think so. I > >>>> still think my proposed "consumer makes all the switching decisions" > >>>> approach can solve a lot of these problems. > >>> > >>> I know Cisco used to have a goal to make its equipment work "better > >>> together". But in a sense that is exactly the thing that standards > >>> are working against. > >>> > >>> With CLUE, *how* would a vendor's equipment do better with other of > >>> its own, and just be "good enough" with others? Ultimately you can > >>> only do as good as the provided information allows you to do. I can > >>> see a few things: > >>> > >>> - a vendor is likely to make its equipment in configurations that > >>> are designed to be easily compatible with one another. E.g., just > >>> a small set of configurations, like 1,2, or 3 screens, all same > >>> size, all side by side with consistent spacing. > >>> > >>> - a vendor could use a consistent style to structure its > >>> advertisements. > >>> E.g., Always have one scene for room cameras and one more for > >>> presentations. > >>> > >>> - a vendor could build an algorithm for constructing configurations > >>> that special cases advertisements structured the way it does them. > >>> Then it could have very crude algorithms for anything else, or > >>> just fail for anything else. > >>> > >>> - a vendor could build an algorithm for constructing configurations > >>> that makes "leaps of faith" that aren't justified solely by what > >>> is in an advertisement, about how the captures in the advertisement > >>> work. (E.g., about the algorithm for switching, or how things are > >>> laid out in a composition.) > >>> > >>> - a vendor could add proprietary information to advertisements, or to > >>> the sip signaling, to convey extra information that allows one of > >>> its own consuming endpoints to do a better job of constructing a > >>> config than would be possible with just the standard information. > >>> > >>> Odds are that we will see all of the above. Certainly there are > >>> inherent advantages when the advertisement happens to contain an > >>> alternative that exactly matches the equipment in the consuming end. > >>> And that is more likely to happen with equipment from one vendor. > >>> > >>> But beyond that, IMO, if we do our job well, then it should be > >>> possible to construct a general purpose algorithm that will do as > >>> well as algorithms that are special cased or that make "leaps of > >>> faith" or use proprietary information. > >>> > >>>>> ISTM in this case that taking a cse from every scene will give the > >>>>> best user experience *if* the consumer has enough display > >>>>> resources to show all these. > >>>> > >>>> [Duckworth, Mark] I think "best experience" is subjective here. I > >>>> think the consumer has enough information to make a good choice for > >>>> a variety of different consumer capability levels in terms of > >>>> number of decoders and displays it has. Suppose the consumer can > >>>> receive no more than 3 video encodings. It could ask for the 3 > >>>> MCCs from Scene 1, or it could ask for 1 MCC from each scene. But > >>>> I would think it would do that only if each scene had a CSE with > >>>> one MCC in it. Each choice could give the "best" experience, > >>>> depending on what the consumer is trying to present to the human > users. > >>> > >>> I agree that "best experience" is subjective. But I suspect if we > >>> worked out a lot of use cases, we could come close to agreeing to > >>> what the "best experience" would be, in the absence of explicit > >>> input from the end users in the room. > >>> > >>> I think what you are talking about is that there are a *set* of > >>> "plausible" configurations, that it might make sense to offer as a > >>> menu to the end user. > >>> > >>>>> If not, then it gets complex to sort out the tradeoffs. > >>>>> > >>>>> In this case, considering that a capture with "current active > >>>>> speaker" > >>>>> policy is more important than one with "previous active speaker". > >>>>> > >>>>> So I would suggest that the advertisement mark all the "current > >>>>> active speaker" captures with highest priority, and the others > >>>>> with descending priorities. > >>>> > >>>> [Duckworth, Mark] that's what I was thinking, but even that > >>>> shouldn't be necessary because the consumer can make its own > >>>> priority decision based on the policy attribute. > >>> > >>> Certainly it *can*. But then it must make a tradeoff between the > >>> importance of the policy and the importance of the priority in the > >>> decision. Lacking any understanding of the motivation for the > >>> priority assignments, it is hard to trade those off against one anoth= er. > >>> > >>>>> Then, the consumer could start out assuming it should *try* for > >>>>> one CSE from each scene. It can look at different combinations, > >>>>> taking one from each scene, and evaluate what it can do with that > >>>>> combination. For each > >>>>> one: > >>>>> > >>>>> If it can't handle all the captures from the selected cses, it can > >>>>> start casting out lower priority ones until it can handle it. Then > >>>>> it can assign a score, depending on the priorities of those it > >>>>> took, the priorities of those it had to abandon, and how much it > >>>>> had to "adjust" > >>>>> the ones it took to fit on its displays. > >>>>> > >>>>> And it can repeat that for all the combinations of one cse from > >>>>> each scene. > >>>>> And then pick out the combination with the best score. > >>>>> > >>>>> This is all very heuristic. Will take a lot of thought and testing > >>>>> to come up with something that does well. (It would be interesting > >>>>> to work this out in detail for some specific consumer > >>>>> configurations and see if it can actually find good > >>>>> renderings.) > >>>>> > >>>>> Having the advertisement provide a single set of CSEs across all > >>>>> the scenes would "help" in that it would reduce the number of > >>>>> combinations the consumer had to evaluate. > >>>> > >>>> [Duckworth, Mark] I'm not sure it would reduce anything. As > >>>> Christian said, "The combinatorial issue becomes worse with the > >>>> more Scenes that you have". I'm concerned that trying to add > >>>> another layer of alternatives in the advertisement, that crosses > >>>> scene boundaries, won't scale well. Or do you think it is really > >>>> simpler than that? Are you envisioning the single set of CSEs > >>>> could be kept small, even with many scenes? > >>> > >>> With separate CSE lists in each scene, the *consumer* has to > >>> evaluate all the combinations of one CSE from each scene. > >>> > >>> With a single CSE list, the *advertiser* has to consider all of > >>> those when constructing the advertisement. But it doesn't have to > >>> *include* them all in the advertisement. My gut tells me that when > >>> there are only a few then perhaps they are all interesting, but when > >>> they are many, that only a few will be interesting enough to > >>> include. The advertiser is pruning the choices, using information > >>> that it has that isn't necessarily available to the consumer. > >>> > >>> If the advertiser is typically going to include all the > >>> combinations, then going this way is a bad choice. And if the > >>> advertiser is going to limit what it includes because it is too much > >>> work, or makes the advertisement too big, even though it thinks the > >>> ones it is omitting would be useful, then this is also a bad idea. > >>> > >>>>>> I agree there could be other situations where the MCC policy > >>>>>> attributes > >>>>> aren't enough information for the consumer to make a good choice. > >>>>> This is > >>>>> where I thought the media capture priority attribute should be > >>>>> used. I thought this was the purpose of adding the priority > >>>>> attribute in the first place. From the framework: > >>>>>> > >>>>>> 7.1.1.12. Priority > >>>>>> The priority attribute indicates a relative priority between > >>>>>> different Media > >>>>> Captures. The Provider sets this priority, and the Consumer MAY > >>>>> use the priority to help decide which captures it wishes to > >>>>> receive. > >>>>>> The "priority" attribute is an integer which indicates a relative > >>>>>> priority > >>>>> between Captures. For example it is possible to assign a priority > >>>>> between two presentation Captures that would allow a remote > >>>>> endpoint to determine which presentation is more important. > >>>>> Priority is assigned at the individual capture level. It > >>>>> represents the Provider's view of the relative priority between > >>>>> Captures with a priority. > >>>>>> > >>>>>> I don't understand why you say this isn't a priority issue, but > >>>>>> rather an > >>>>> alternative issue. It seems to me your proposal of advertising > >>>>> different combinations of captures or CSEs across scene boundaries > >>>>> is just another way for the provider to express priorities. > >>>>> > >>>>> Surely it is a form of prioritization. But it can be more > >>>>> sophisticated than simply assigning a priority value to each > >>>>> individual capture. > >>>>> > >>>>> But consider, if prioritization were sufficient, we wouldn't need > >>>>> to have CSEs at all. We could simply have prioritized captures. > >>>>> ISTM that the reasons that CSEs are more powerful than priorities > >>>>> within a scene should still apply outside a scene. > >>>> > >>>> [Duckworth, Mark] That makes sense too, at a high level, but I'm > >>>> having trouble understanding how to put it in practice. > >>>> > >>>>> As I described above, I *think* priorities plus per-scene cse > >>>>> lists can solve your use case. But the processing to use it that > >>>>> way is complex. > >>>> > >>>> [Duckworth, Mark] So are you saying your idea of using a single set > >>>> of CSEs across all scenes can solve the same problems in a less > >>>> complex way? I'm open to that, but still not sure it would be any > >>>> less complex. > >>> > >>> I think it is less complex for the consumer to evaluate a single > >>> list than to evaluate combinations of choices from multiple lists. > >>> (Enumerating all the combinations and generating an equivalent > >>> single list to evaluate is of course a straightforward programming > >>> job. But I wonder if some implementers might instead go for "special > >>> casing".) > >>> > >>> When constructing a single list, rather than several, and choosing > >>> which combinations to include, the advertiser can use knowledge that > >>> can't otherwise be described in the advertisement and used by the > >>> consumer to choose. > >>> > >>> Thanks, > >>> Paul > >>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>>> Mark > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul > >>>>>>> Kyzivat > >>>>>>> Sent: Thursday, February 06, 2014 12:34 PM > >>>>>>> To: clue@ietf.org > >>>>>>> Subject: Re: [clue] How to choose from multiple scenes > >>>>>>> > >>>>>>> I just realized I had missed this reply. See inline. > >>>>>>> > >>>>>>> On 1/27/14 10:33 PM, Christian Groves wrote: > >>>>>>>> Hello Paul, > >>>>>>>> > >>>>>>>> Please see below. > >>>>>>>> > >>>>>>>> Regards, Christian > >>>>>>>> > >>>>>>>> On 28/01/2014 10:06 AM, Paul Kyzivat wrote: > >>>>>>>>> * The problem: > >>>>>>>>> > >>>>>>>>> As we discussed in the interim today, it seems unclear what a > >>>>>>>>> consumer should do when receiving an advertisement with > >>>>>>>>> multiple scenes in order to get a sufficient representation of > >>>>>>>>> the advertised > >>>>>>> content. > >>>>>>>>> > >>>>>>>>> Our simple cases have been where there is one scene for the > >>>>>>>>> cameras in the room, and another scene for a presentation. In > >>>>>>>>> that case, one should take something from each scene > >>>>>>>>> (typically one CSE from > >>>>>>>>> each) to get "enough". > >>>>>>>>> > >>>>>>>>> That is also true if an MCU acted in "pass through" mode and > >>>>>>>>> simply included "copies" of all the scenes it receives in > >>>>>>>>> advertisements, with encodings for them all. > >>>>>>>>> > >>>>>>>>> In a "simple" case with an MCU use MCC, it might "pass > >>>>>>>>> through" all the advertisements it receives, for their spatial > >>>>>>>>> info, but not provide any encodings for them. Rather, it would > >>>>>>>>> provide one or more new scenes using MCC to aggregate those > >>>>>>>>> sources. Then one would not want to configure from the "pass > >>>>>>>>> through" scenes, but that isn't an option anyway if there are > >>>>>>>>> no encodings for them. > >>>>>>>> [CNG] The idea of the pass through information was that the > >>>>>>>> consumer could use any capture attribute (not just spatial > >>>>>>>> ones) to determine what media it wanted. > >>>>>>> > >>>>>>> Clearly if there are no encodings, then the captures are there > >>>>>>> only for information and can't be configured. > >>>>>>> > >>>>>>> That is why I called this the "simple" case. > >>>>>>> > >>>>>>>>> Mark has proposed using multiple scenes with MCC to illustrate > >>>>>>>>> switched cases where some groupings don't have any spatial > >>>>>>>>> relationship to one another. Some of those examples end up > >>>>>>>>> with multiple scenes that do have encodings, where it doesn't > >>>>>>>>> make sense to configure something from each scene. > >>>>>>>> [CNG] I don't think there's anything in the framework that says > >>>>>>>> a consumer must choose a capture from a scene. > >>>>>>> > >>>>>>> Of course there is no MUST. The consumer isn't required take > >>>>>>> *anything*. > >>>>>>> > >>>>>>> The question is how the consumer knows what is required to have > >>>>>>> a "complete" representation of what is in the advertisement. It > >>>>>>> may not want all that, but it is hard to make a good choice > >>>>>>> without knowing. > >>>>>>> > >>>>>>> That is the point of CSEs - for the advertiser to indicate what > >>>>>>> it considers to be good alternative choices. But CSEs only work > >>>>>>> within a scene. Once there are multiple scenes, the consumer has > >>>>>>> less guidance on what would be good (or sufficient) choices. > >>>>>>> > >>>>>>> The consumer has *some* information: > >>>>>>> - if none of the captures in a scene have encodings, then there i= s > >>>>>>> no need (or way) to select them directly > >>>>>>> > >>>>>>> - if MCC M in scene X references capture C in scene Y, then it > >>>>>>> would be redundant to configure both M and C > >>>>>>> > >>>>>>> ISTM that one should start out assuming that you need all > >>>>>>> captures (that have encodings) in *some* CSE from *each* scene. > >>>>>>> You can then prune that based on the logic above. But is that > >>>>>>> *enough* to make good > >>>>> decisions? > >>>>>>> At best, the logic to figure that out is complex. > >>>>>>> > >>>>>>>>> Today we discussed using priority to solve this, but this > >>>>>>>>> isn't really a priority problem, it is a problem of > >>>>>>>>> *alternatives* that may be equally desirable, depending on the > >>>>>>>>> resources or desires of the > >>>>>>> consumer. > >>>>>>>> [CNG] I agree I don't think priority is the right solution for > >>>>>>>> this. > >>>>>>>>> > >>>>>>>>> IMO the problem is that our CSE mechanism is a way for the > >>>>>>>>> advertiser to suggest alternatives, but this only works on a > >>>>>>>>> per-scene > >>>>> basis. > >>>>>>>>> The advertiser has no comparable mechanism to suggest > >>>>>>>>> alternatives from different scenes. > >>>>>>>>> > >>>>>>>>> * My proposed solution: > >>>>>>>>> > >>>>>>>>> I want to restate a proposal I made a long time ago: > >>>>>>>>> > >>>>>>>>> Instead of one CSE list per scene, have one CSE list > >>>>>>>>> per-advertisement, referencing captures from any scene. > >>>>>>>>> > >>>>>>>>> This makes it possible for the advertiser to recommend > >>>>>>>>> combinations that cross scene boundaries. > >>>>>>>> [CNG] Perhaps you could give some examples? Does the list need > >>>>>>>> to be exhaustive? > >>>>>>> > >>>>>>> Does the CSE list in a scene have to be exhaustive? > >>>>>>> > >>>>>>> I think each entry should be "sufficient" for somebody that > >>>>>>> can't handle a bigger one. The definition of "sufficient" is > subjective. > >>>>>>> > >>>>>>>> e.g. the simple case today > >>>>>>>> Scene1 CSE1(VC1,VC2,VC3) > >>>>>>>> CSE2(VC4) > >>>>>>>> Scene2 CSE3(VC5,presentation1) > >>>>>>>> > >>>>>>>> Does it mean now the Advertisement would now have to > advertise? > >>>>>>>> CSE1(VC1,VC2,VC3,VC5) > >>>>>>>> CSE2(VC4,VC5) > >>>>>>>> CSE3(VC1,VC2,VC3) > >>>>>>>> CSE4(VC4) > >>>>>>>> CSE5(VC5) > >>>>>>> > >>>>>>> As I said, the definition of "sufficient" is subjective. > >>>>>>> IMO the advertisement ought to include at least CSE1,CSE2. > >>>>>>> > >>>>>>> Rather than include the others, I think I would adjust the > >>>>>>> priorities of the individual captures based on my judgement of > >>>>>>> which I think should be kept if they all can't be. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> > >>>>>>>>> * An alternate solution: > >>>>>>>>> > >>>>>>>>> Another possibility would be to leave CSEs as they are, but > >>>>>>>>> add something analogous to a CSE list, but that lists > >>>>>>>>> recommended combinations of scenes. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Paul > >>>>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > _______________________________________________ > > 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 nobody Wed Feb 19 14:28:55 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3B11A0412 for ; Wed, 19 Feb 2014 14:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2EqvPM0qf5n for ; Wed, 19 Feb 2014 14:28:50 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 166AB1A0405 for ; Wed, 19 Feb 2014 14:28:50 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 19 Feb 2014 14:28:46 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 19 Feb 2014 14:28:44 -0800 Thread-Topic: Global Alternative Captures List - How to choose from multiple scenes Thread-Index: Ac8tu3amBLIxDaMfQuWEUWawnyCTUw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010@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_49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010CRPMBOXPRD07p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/gEQocM71cWee0d2Ec4L8EihikA8 Subject: [clue] Global Alternative Captures List - How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:28:53 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the Feb 11 design team meeting we thought this idea from Paul was worth = considering. Paul wrote (Feb 10): =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=3D=3D=3D=3D=3D=3D=3D=3D - Leave existing per-scene CSE lists as-is. - Add another advertisement-wide CSE list. The entries in it could use sho= rthand, by referencing CSEs from the individual scenes. E.g., Scene1 (CSE11, CSE12, CSE13) Scene2 (CSE21, CSE22) Scene3 (CSE31) Scene4 (CSE41) Global-CSE-List ( CSEg1(CSE11, CSE21, CSE31) CSEg2(CSE12, CSE22, CSE31) CSEg3(CSE13, CSE22, CSE31) ) Here the global CSE list has recommended a subset of the possible combinati= ons of CSEs from the different scenes, and has omitted Scene4 altogether. T= his is a value judgement of what combinations make sense. Note that I would still allow the CSEs in the global list to reference indi= vidual captures if desired. But referencing other CSEs is a convenient shor= thand. =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=3D=3D=3D=3D=3D=3D=3D=3D I included a slide showing a slightly more detailed example for the case we= have been discussing at previous meetings. Slide 9 of http://trac.tools.i= etf.org/wg/clue/trac/raw-attachment/wiki/Design-Team/Framework_Issues_14021= 1.pptx This example gives alternatives for a consumer that wants to receiv= e only one capture, all the way up to a consumer that wants nine captures, = with all possibilities in between. I think this new proposed list could be called "global alternative captures= list" rather than a "global CSE list". Maybe somebody has a better sugges= tion for what to call it? The purpose of the list is for the provider to g= ive suggestions to the consumer about which captures to choose, considering= the entire advertisement. Each entry in the list is an alternative. Each= entry consists of a set of captures (for shorthand, could reference multip= le captures at once by referencing a CSE instead of individual capture). For an advertisement with multiple scenes, where each scene can have multip= le CSEs with different number of captures in each, we have been discussing = how a consumer can make a good choice between requesting captures from fewe= r scenes with more captures per scene, vs. requesting captures from more sc= enes with fewer captures per scene. The "global alternative captures list"= gives the provider a way to suggest which makes more sense from the provid= er's viewpoint. Of course the consumer can still take into account all the= other information such as priority, description, participant information a= nd view attributes. Does the group support adding this additional list to an advertisement? Sh= ould I make a specific proposal for text to add to the framework? Or do we= need more discussion or examples? Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the Feb 11 de= sign team meeting we thought this idea from Paul was worth considering.&nbs= p; Paul wrote (Feb 10):

=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=3D=3D=3D=3D=3D= =3D=3D=3D

= - Leave existing per-scene CSE lists as-is.

- Add another advertisement-wide CSE list= .  The entries in it could use shorthand, by referencing CSEs from the= individual scenes.

 

E.g.,

            =     Scene1 (CSE11, CSE12, CSE13)

      &= nbsp;         Scene2 (CSE21, CSE22)=

 &nb= sp;            =   Scene3 (CSE31)

          &nb= sp;     Scene4 (CSE41)

 

       &nb= sp;        Global-CSE-List (<= /p>

   &nb= sp;             = ; CSEg1(CSE11, CSE21, CSE31)

         &n= bsp;        CSEg2(CSE12, CSE22, CSE31)

  &nbs= p;             =   CSEg3(CSE13, CSE22, CSE31)

        &nb= sp;       )

 

Here the global CSE list has recommended a sub= set of the possible combinations of CSEs from the different scenes, and has= omitted Scene4 altogether. This is a value judgement of what combinations = make sense.

 

N= ote that I would still allow the CSEs in the global list to reference indiv= idual captures if desired. But referencing other CSEs is a convenient short= hand.

=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=3D=3D=3D=3D=3D=3D=3D=3D

 

I incl= uded a slide showing a slightly more detailed example for the case we have = been discussing at previous meetings.  Slide 9 of http://trac.tools.ie= tf.org/wg/clue/trac/raw-attachment/wiki/Design-Team/Framework_Issues_140211= .pptx  This example gives alternatives for a consumer that wants to re= ceive only one capture, all the way up to a consumer that wants nine captur= es, with all possibilities in between.

<= o:p> 

I think this new proposed list cou= ld be called “global alternative captures list” rather than a &= #8220;global CSE list”.  Maybe somebody has a better suggestion = for what to call it?  The purpose of the list is for the provider to g= ive suggestions to the consumer about which captures to choose, considering= the entire advertisement.  Each entry in the list is an alternative.&= nbsp; Each entry consists of a set of captures (for shorthand, could refere= nce multiple captures at once by referencing a CSE instead of individual ca= pture).

 

For an advertisement with multiple scenes, where each scene can h= ave multiple CSEs with different number of captures in each, we have been d= iscussing how a consumer can make a good choice between requesting captures= from fewer scenes with more captures per scene, vs. requesting captures fr= om more scenes with fewer captures per scene.  The “global alter= native captures list” gives the provider a way to suggest which makes= more sense from the provider’s viewpoint.  Of course the consum= er can still take into account all the other information such as priority, = description, participant information and view attributes.

 

Does the group = support adding this additional list to an advertisement?  Should I mak= e a specific proposal for text to add to the framework?  Or do we need= more discussion or examples?

 = ;

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010CRPMBOXPRD07p_-- From nobody Wed Feb 19 14:44:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E03C1A04D2 for ; Wed, 19 Feb 2014 14:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KsnKp_Jsfaa for ; Wed, 19 Feb 2014 14:44:24 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id C37D11A02A1 for ; Wed, 19 Feb 2014 14:44:23 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Wed, 19 Feb 2014 14:44:20 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 19 Feb 2014 14:44:16 -0800 Thread-Topic: Need to signal "active video capture" information? Thread-Index: Ac8twr2fgs0y1pw7R+GGWkmSU+9IyA== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA027@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_49E45C59CA48264997FEBFB29B6BC2D60C9D4EA027CRPMBOXPRD07p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/fxrbRWq8rxQLmUjMV_o7VcIDyMo Subject: [clue] Need to signal "active video capture" information? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:44:26 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D4EA027CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I had this in a slide from Feb 11 design team, but we didn't get to it. This is an old issue we previously said was important, but haven't followed= up on it. I think it is still important. Old slides from October 2011 interim - http://trac.tools.ietf.org/wg/clue/t= rac/raw-attachment/wiki/WikiStart/5-VAD-in-CLUE.ppt Summary: * Signaling the "active video capture", not using just audio energy i= n the audio stream(s). Discussed at October 2011 interim meeting, we never= followed up on it. "VAD in CLUE" * Example: endpoint provider sends 3 video captures, and 1 mono audio - Consumer (MCU topo-mixer) wants to know which video has the loudest = talker, so it can send that one to a simple endpoint that just receives one= video stream - How does this MCU consumer know which one it is? * Provider can signal this somehow, if it knows locally which video i= s associated with the talker - in RTP? - in CLUE channel? - provider sends a switched MCC for this, plus the individual captures= ? * This gets back to issue of sending one packet stream that fulfills = multiple encodings at the same time? - other way? Does the group want to address this issue? Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D4EA027CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I had this in a = slide from Feb 11 design team, but we didn’t get to it.

This is an old issue we previously said was important= , but haven’t followed up on it.  I think it is still important.=

 

Old slides from October 2011 interim - http://trac.tools.ietf.org/wg/clu= e/trac/raw-attachment/wiki/WikiStart/5-VAD-in-CLUE.ppt

 

Summary:

•       Signaling the “active video capture”, not usi= ng just audio energy in the audio stream(s).  Discussed at October 201= 1 interim meeting, we never followed up on it. “VAD in CLUE”

•       Example: endpoint provider sends 3 video capture= s, and 1 mono audio

–   &n= bsp;  Consumer (MCU topo-mixer) wants t= o know which video has the loudest talker, so it can send that one to a sim= ple endpoint that just receives one video stream

= –      How = does this MCU consumer know which one it is?

= •       Pro= vider can signal this somehow, if it knows locally which video is associate= d with the talker

–   &nbs= p;  in RTP?

<= span style=3D'mso-list:Ignore'>–      in CL= UE channel?

̵= 1;    &nbs= p; provider sends a switched MCC for this, p= lus the individual captures?

•  = ;     This gets back to = issue of sending one packet stream that fulfills multiple encodings at the = same time?

̵= 1;    &nbs= p; other way?

 

Does the group want to addre= ss this issue?

 

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D4EA027CRPMBOXPRD07p_-- From nobody Wed Feb 19 15:37:28 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E6E1A0529 for ; Wed, 19 Feb 2014 15:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FY2pLF5bYepl for ; Wed, 19 Feb 2014 15:37:19 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 558BD1A02B5 for ; Wed, 19 Feb 2014 15:37:19 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id a108so2268815qge.7 for ; Wed, 19 Feb 2014 15:37:15 -0800 (PST) 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=X1jmjTWx+jsJ17JGEJ9mLhLzy+SqtQIhLeroNgp3GaY=; b=bw8dy9tMVYmIPXG4zcjFrP3P8DJkT2A/eXdqeLiONXBZ1LpYdM7NU2sjI9lxWNZMg0 w8xuBM9RO7hl44FrsReU1PTIWyYMHZ4IFNedRlWIequyiQlWmIkHkFXL/wocz6gftjtr FhDjekMPxPAMoV3Z1SrIpXWD427nNixjytnzXjOKyOnxd1NFkf1scPu1PVon9cvdPOdl JzyoSVd0BIdD8L4VbrQLhNAyvUIMvPzQTODViZAH71icIodfeC73OOOAmk/ohJInj88i gmgIhYUYZ72qZ2ikxGuf5jJ0TLLdZ9qK779zI9uhH8gtUYNT8WpCu+dCkzdfvRst3Urb y3PQ== MIME-Version: 1.0 X-Received: by 10.236.38.74 with SMTP id z50mr7499047yha.134.1392853035792; Wed, 19 Feb 2014 15:37:15 -0800 (PST) Received: by 10.170.213.85 with HTTP; Wed, 19 Feb 2014 15:37:15 -0800 (PST) Date: Wed, 19 Feb 2014 17:37:15 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7bea41a46c3eb104f2cadec7 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xxQKPjgEUqM5Iwtzb5UiD8fmUKw Cc: "Alissa Cooper \(alcoop\)" Subject: [clue] Clue dinner in London Doodle X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 23:37:25 -0000 --047d7bea41a46c3eb104f2cadec7 Content-Type: text/plain; charset=ISO-8859-1 I think it would be good for us to get together informally for dinner on Monday, March 3rd (that's pretty much the only open night I have). The plenary runs until 19:50. The restaurant I've selected takes no reservations, but I'm thinking it won't be too long of a wait by the time we get there: http://www.relaisdevenise.com/marylebone/ It's about a 20 minute walk from the hotel. The plan would be to meet in the hotel lobby near the hotel registration (not IETF registration) at 8:15 pm and walk together from there. Note, if the restaurant is really busy and we have a larger group, we may have to split into multiple tables. It's very easy as the only choices you make are how you want your steak cooked and what you want to drink. The price is extremely reasonable for London - salad, steak and frites for 23 GBP. Please fill out the doodle no later than 8am on Monday, so I know who all will be coming, so we don't leave without anyone. http://doodle.com/zzg6nahhuypfzni7 And, if you don't fill out the poll and you arrive on your own, you may not get a seat - it will be impossible to squeeze an extra person into any of these tables as it is very, very, very tightly packed. You have just a tad more elbow room than you'll have on your flight to the meeting, so please do not bring your computer bags - there really won't be anywhere to stow them. Mary. ---------- Forwarded message ---------- From: Doodle Date: Wed, Feb 19, 2014 at 5:25 PM Subject: Doodle: Link for poll "CLUE Dinner" To: Mary Barnes You have initiated a poll "CLUE Dinner" at Doodle. The link to your poll is: http://doodle.com/zzg6nahhuypfzni7 Share this link with all those who should cast their votes. Do not forget to cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used your e-mail address; simply ignore this e-mail, please.) --047d7bea41a46c3eb104f2cadec7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think it would be good for us to get together informally= for dinner on Monday, March 3rd (that's pretty much the only open nigh= t I have). =A0The plenary runs until 19:50. =A0The restaurant I've sele= cted takes no reservations, but I'm thinking it won't be too long o= f a wait by the time we get there:=A0http://www.relaisdevenise.com/marylebone/
It's about a 20 minute walk from the hotel.

The plan= would be to meet in the hotel lobby near the hotel registration (not IETF = registration) at 8:15 pm and walk together from there. =A0Note, if the rest= aurant is really busy and we have a larger group, we may have to split into= multiple tables. =A0

It's very easy as the only choices you make are how= you want your steak cooked and what you want to drink. =A0The price is ext= remely reasonable for London - salad, steak and frites for 23 GBP. =A0
<= /div>

Please fill out the doodle no later than 8am on Monday,= so I know who all will be coming, so we don't leave without anyone.=A0=

And, if you don't fill out the poll and you a= rrive on your own, you may not get a seat - it will be impossible to squeez= e an extra person into any of these tables as it is very, very, very tightl= y packed. =A0You have just a tad more elbow room than you'll have on yo= ur flight to the meeting, so please do not bring your computer bags - there= really won't be anywhere to stow them.

Mary.=A0

-----= ----- Forwarded message ----------
From: D= oodle <mailer= @doodle.com>
Date: Wed, Feb 19, 2014 at 5:25 PM
Subject: Doodle: Link for poll "= CLUE Dinner"
To: Mary Barnes <mary.ietf.barnes@gmail.com>


You have initiate= d a poll "CLUE Dinner" at Doodle. The link to your poll is:

http://doo= dle.com/zzg6nahhuypfzni7

Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too.
(If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.)

--047d7bea41a46c3eb104f2cadec7-- From nobody Wed Feb 19 16:03:23 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7871A052E for ; Wed, 19 Feb 2014 16:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFLUfnFSONcI for ; Wed, 19 Feb 2014 16:03:18 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5392A1A040A for ; Wed, 19 Feb 2014 16:03:18 -0800 (PST) Received: from ppp118-209-254-53.lns20.mel6.internode.on.net ([118.209.254.53]:51925 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGH3W-0000ot-Jy for clue@ietf.org; Thu, 20 Feb 2014 10:59:58 +1100 Message-ID: <5305463D.6070807@nteczone.com> Date: Thu, 20 Feb 2014 11:03:09 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB54F@CRPMBOXPRD07.polycom.com> <52F82841.5010001@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D4E9F7F@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D4E9F7F@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/RZ8pPbo8AwtNvitx8vfIlKCtYRY Subject: Re: [clue] Maxcaptures in MCC, vs. switched and composed attributes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 00:03:22 -0000 Hello Mark, Just to clarify for maxCaptures the "<=" qualifier is essentially what is already in the draft today. Its the "=" that I'm proposing to add. Did Jonathon what the clarification on the existing qualifier or the additional one? Here's the cases: 1) MCC1(VC1,VC2,VC3,VC4),MaxCaptures<=1 This is the switched case. Zero or 1 capture may be switched into the media stream. Note: zero is allowed because of the "<=". 2) MCC1(VC1,VC2,VC3,VC4),MaxCaptures=1 This is the switched case. Only 1 capture may be switched into the media stream. 3) MCC1(VC1,VC2,VC3,VC4),MaxCaptures<=2 This is a switched and composition case. The sources may be purely switched (i.e. <=2 allows for 1 source on its own), or they may be composed and switched (i.e. a composition of 2 sources switched between the 4 sources. 4) MCC1(VC1,VC2,VC3,VC4),MaxCaptures=2 This is a switched and composition case. The sources are composed and switched (i.e. a composition of 2 sources switched between the 4 sources. Its not possible to have a single source. 5) MCC1(VC1,VC2,VC3,VC4),MaxCaptures<=4 This is a switched and composition case. As per 3 above, however there may be additional compositions of 3 and 4 sources. 6) MCC1(VC1,VC2,VC3,VC4),MaxCaptures=4 This is a composition case. All 4 sources are contained in the media stream. No switching. As I mentioned below having MaxCapture is essential for choosing MCCs when different "compositions" or "switches" are on offer. With respect to "switched" and "composed" I think there's interaction issues that would need to be considered if both MaxCaptures and "switched"/"composed" were both used. i.e. what would MCC1(VC1,VC2,VC3,VC4),MaxCaptures=4,switched mean? With regards to the empty MCC case the use of an "MCC" was to indicate that switching and/or composition was taking place for the capture? I would think if no information was being offered about the sources that this would be sufficient? The very use of MCC indicates the number of sources captures > 1. So if you used MaxCaptures=1 for MCC() it would indicate the switched case. If people do see a need to indicate "composed" for an empty MCC perhaps we could look at another solution and reserve a MaxCaptures value to indicate this cases? or allow the MCC to contain a "number of sources" attribute which could be used when it doesn't want to specify the actual sources. This would avoid interaction problems between attributes. Regards, Christian On 20/02/2014 8:12 AM, Duckworth, Mark wrote: > We discussed this at the Feb 11 design team meeting but didn't come to any conclusion, either about the switched and composed attributes, or about the "=" and "<=" qualifier for maxCaptures. I can't find minutes of the meeting, so I'm going by my memory here. > > I still think the default is to make no changes unless there is stronger support from the group for a change. > > Jonathan said he wanted to know more about how/why Christian's proposed "<=" qualifier for the maxCaptures attribute would be used. > > In comparing the maxCaptures attribute to the composed and switched attributes, we thought the usefulness of composed and switched was for the case when both are true. It doesn't have to be just one or the other. There could be switching within a composition. If the advertisement has an MCC without specifying constituent captures, and maxCaptures > 1, there is no way to tell if the provider will do switching (if we don't add the switched attribute). We could add the switched attribute to allow the provider to express this. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Sunday, February 09, 2014 8:16 PM >> To: clue@ietf.org >> Subject: Re: [clue] Maxcaptures in MCC, vs. switched and composed >> attributes >> >> Hello >> >> I don't think removal of MaxCaptures is an option. I gave an example to Paul >> why its needed. It was buried deep in an email thread so i'll repeat it here: >> >> I see there is benefit in giving the Advertiser and the Consumer the means of >> knowing how many captures will appear in the stream at a time. >> It gives the ability for the Consumer to distinguish between MCCs. >> >> For example: >> What if the Advertiser combines two sources set but switches the sources? >> i.e. >> MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=2 Are both >> the "switched" and "composed" attributes valid? >> MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Switched,Composed >> >> How about the case where the Advertiser composes 4 sources into a media >> stream switches those sources? >> MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=4 Using the >> composed and switched attributes: >> MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Switched,Composed >> >> Now how does a consumer distinguish between MCC1, MCC2 in this case? I >> think its a valid decision for a Consumer to make it determine how many >> sources it wants to see at a particular time. It can't use the spatial information >> because we've disallowed that. I don't think the "switched" >> and "composed" attributes can model that. >> >> >> >> Regards, Christian >> >> >> On 8/02/2014 3:26 AM, Duckworth, Mark wrote: >>> I'm trying to summarize a couple of related proposals here. >>> 1. Add ability for advertiser to indicate if the number of captures in an MCC >> at any given time will always be equal to MaxCaptures, or if it can be less. >> Details below from Christian. >>> 2. Add Switched and Composed attributes to MCC, just like we used to >> have for all captures. This is proposed in draft-ietf-clue-data-model-schema- >> 03. Maybe remove the MaxCaptures attribute if we add switched and >> composed. >>> We can do one or the other, or both, or neither. Any of those choices is >> okay with me, I personally have no strong argument either way. I think >> others in the group have stronger preferences. I think the default is to do >> neither, unless there is consensus to change. Please continue the discussion >> so we can figure out if any change is needed in the framework and data >> model. >>> Regards, >>> Mark >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>> Groves >>>> Sent: Thursday, February 06, 2014 11:50 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Maxcaptures in MCC >>>> >>>> Hello Mark, >>>> >>>> To be more concrete here's the text I would propose for the framework: >>>> >>>> 7.2.1.1. Maximum Number of Captures within a MCC >>>> >>>> The Maximum Number of Captures MCC attribute indicates the >> maximum >>>> number of individual captures that may appear in a Capture Encoding >>>> at a time. <>> the >>>> actual number at any given time can be less than >>>> this maximum. It may be used to derive how the Single Media >>>> Captures within the MCC are composed / switched with regards to >>>> space and time. <>>> captures is equal >>>> to the maximum the Consumer MUST not choose a subset of captures >>>> from the MCC in a >>>> Configure message.>> >>>> >>>> Max Captures MAY be set to one so that only content related to one >>>> of the sources are shown in the MCC Capture Encoding at a time or >>>> it may be set to any value up to the total number of Source Media >>>> Captures in the MCC. >>>> >>>> If this attribute is not set then as default it is assumed that >>>> <> >>>> can appear concurrently in the Capture Encoding associated with the >> MCC. >>>> For example: The use of MaxCaptures equal to 1 on a MCC with three >>>> Video Captures VC1, VC2 and VC3 would indicate that the Advertiser >>>> in the capture encoding would switch between VC1, VC2 or VC3 as >>>> there may be only a maximum of one capture at a time. >>>> >>>> Regards, Christian >>>> >>>> On 7/02/2014 11:45 AM, Christian Groves wrote: >>>>> Hello Mark, >>>>> >>>>> My proposed improvement is to update the MaxCaptures parameter >> add >>>> the >>>>> possibility to indicate indicate that the value is "equal to" as >>>>> well as allowing the specification as per today "less than or equal to". >>>>> >>>>> Regards, Christian >>>>> >>>>> On 7/02/2014 3:55 AM, Duckworth, Mark wrote: >>>>>> Hi Christian, >>>>>> >>>>>> I think I understand the general idea you are getting at, but I >>>>>> don't understand specifically what you are proposing as an >> improvement. >>>>>> More comments inline. >>>>>> >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>>>> Groves >>>>>>> Sent: Wednesday, February 05, 2014 7:20 PM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] Now Maxcaptures - Re: spatial information >>>>>>> can't describe video locations within composed MCC >>>>>>> >>>>>>> Hello Paul and Mark, >>>>>>> >>>>>>> The Max-captures attributes currently indicates the maximum >> number >>>>>>> of captures that appears in a MCC at any particular point in time. >>>>>>> >>>>>>> i.e. MCC(VC1,VC2,VC3),MaxCaptures=3 So a Consumer has to assume >>>>>>> because this is a maximum that VC1, VC2, VC3, (VC1,VC2), >>>>>>> (VC1,VC3), (VC2,VC3) or (VC1,VC2,VC3) can appear at any point in >>>>>>> time. >>>>>> [Duckworth, Mark] I agree, that is consistent with framework-13. >>>>>> >>>>>>> However the Consumer only ever sends a composition of >>>> (VC1,VC2,VC3). >>>>>>> It is >>>>>>> never going to change that combination. >>>>>> [Duckworth, Mark] Do you mean the Provider will always send a >>>>>> composition of (VC1,VC2,VC3)? And the provider would like to be >>>>>> more explicit about this in the advertisement? >>>>>> >>>>>>> It seems to me that in this case >>>>>>> using MaxCaptures as it is currently defined is semantically incorrect. >>>>>> [Duckworth, Mark] I think it is correct, but maybe not giving as >>>>>> much information as the provider wants to express. >>>>> [CNG] I can't see its correct. If I tell you that I can do a set of >>>>> behaviour but I only intend to do one then I don't think that's >>>>> truthful. Sort of like telling you I'm coming to your house one day >>>>> next week when in fact I only intend on coming on Friday. >>>>>>> So what I am suggesting is simply to add a way to correctly >>>>>>> indicate this "constant number of captures" case, i.e. (VC1,VC2,VC3). >>>>>> [Duckworth, Mark] If I understand your suggestion correctly, then >>>>>> one way to do that would be to add a new optional MinCaptures >>>>>> attribute to an MCC. MinCaptures is the minimum number of >>>>>> constituent captures that may appear in the MCC at a time. If this >>>>>> attribute is not set, then it is assumed to have the default value >>>>>> of 1. For this scenario, the value of both MinCaptures and >> MaxCaptures would be 3. >>>>>> Is this what you are suggesting, or do you have something else in mind? >>>>> [CNG] No all I had in mind was something like: >>>>> MaxCaptures "="/"<=" value >>>>> The Advertiser would chose to indicate "equal" or "equal to >>>>> or less than". >>>>>>> I think Paul is questioning the attribute in general. I do believe >>>>>>> that knowing the number of sources may be beneficial for a >>>>>>> consumer in deciding which MCC/Captures to select. There may be >>>>>>> tradeoffs vs a MCC only showing a limited number (i.e. one source) >>>>>>> at a time vs another MCC showing multiple sources at a time. >>>>> [CNG] I agree I think its beneficial. >>>>>>> Regards, Christian >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Feb 19 16:37:18 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E401A02D8 for ; Wed, 19 Feb 2014 16:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_44=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9ytEaiARnXB for ; Wed, 19 Feb 2014 16:37:12 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6061A052F for ; Wed, 19 Feb 2014 16:37:12 -0800 (PST) Received: from ppp118-209-254-53.lns20.mel6.internode.on.net ([118.209.254.53]:52247 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGHaK-0005w3-Ku for clue@ietf.org; Thu, 20 Feb 2014 11:33:52 +1100 Message-ID: <53054E30.4090708@nteczone.com> Date: Thu, 20 Feb 2014 11:37:04 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> <53016764.9050201@nteczone.com> <53018B68.2080209@alum.mit.edu> <530198FB.9000905@nteczone.com> <53027E21.2040008@alum.mit.edu> In-Reply-To: <53027E21.2040008@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/yXMnYC_jB07VB4jE9LaZXqQlFAQ Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 00:37:15 -0000 Hello Paul, Please see below. Regards, Christian On 18/02/2014 8:24 AM, Paul Kyzivat wrote: > On 2/17/14 12:07 AM, Christian Groves wrote: >> Hello Paul, > > [snip] > >>>> The SCTP >>>> draft allows the specification of "app"s that relate to the SCTP >>>> association as a means of negotiating what goes in the SCTP >>>> association. >>>> One of those "app"s may be the webrtc data channel. It has its own >>>> means >>>> of negotiating of what is in the SCTP association (i.e. Richard's >>>> draft). >>> >>> I agree with your interpretation here. That doesn't mean the layering >>> is wrong - just the terminology. >>> >>> The use of a=sctpmap is clearly intended as an analog to a=rtpmap. But >>> in reality its purpose is not at all analogous to a=rtpmap. So the >>> name confuses. >>> >>> And that mis-analogy is continued, by language that says sctpmap is >>> defining a mapping from a port number to a payload format. Again, that >>> is not what it is doing. (If it were, then you would be restricted to >>> one payload format for all the streams on the association.) AFAICT, >>> the name you are giving in sctpmap describes some sort of "convention" >>> for how all the streams in the association are to be managed and used. >>> E.g., "webrtc-datachannel" says that the streams will be managed in >>> pairs, as channels, and that webrtc data channel protocol may be used >>> to dynamically assign channels. (That is the same conclusion you have >>> reached.) >>> >>> IMO a lot of the language should be changed to be less confusing. >>> >>>> Both these methods are basically just indicating what will be in >>>> the SCTP streams. >>> >>> Both? Which? The only thing that actually says, in SDP, what will be >>> in the individual SCTP streams is Richard's draft. >> [CNG] The SCTP draft does say which "apps" will be in the association. >> That what I mean by "what's in the streams" in the general sense. > > "apps" is a cop out - it is a meaningless term. [CNG] I agree, I'm just reusing the existing term. Different protocols will be signaled across different SCTP streams. > > "Loosely" I am inclined to think there is only one "app" at each end > of the association, or maybe just one distributed app at both ends of > the association. I find it hard to consider "webrtc-datachannel" an > "application". It is just another layer in a stack. What we are more > likely to recognize as the "application" is above that. (We are > working our way up, from layer 7. But I've lost count.) [CNG] I don't think we need to make any assumptions about the number of apps. A endpoint could have one or more SCTP associations. In those associations they could have 1 or more SCTP streams carrying one or more protocols. > > But then there is some piece of application behavior associated with > each channel. *That* is where it gets clue-specific. > > This is one of the things that deserves better terminology. [CNG] I agree. > >>>> Rather than have two methods for negotiating what is >>>> in the SCTP association it almost seems better to have one method for >>>> negotiation of what apps there are and then to tag whether or not the >>>> webrtc data channel will be used to open it. >>>> >>>> e.g. >>>> >>>> m=application 54111 SCTP/DTLS 54111 >>>> a=sctpmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; >>>> max_retr=3; >>>> webrtc-datachannel-tag >>>> a=webrtc-datachannel:max-message-size=100000 streams=1 >>>> >>>> webrtc-datachannel-tag would take whether an "app" uses the webrtc >>>> data >>>> channel open protocol. >>>> a=webrtc-datachannel attribute would give the attributes of the >>>> protocol. >>> >>> There are problems with this - not for CLUE, but for webrtc, or >>> anything that doesn't want to use O/A to define every channel. >>> >>> The webrtc data channel open protocol does not take a stream ID as an >>> argument. It internally assigns stream IDs. Rtcweb has specified how >>> you can use preassigned channels without the open, but then it isn't >>> using the data channel protocol. >> [CNG] I just threw something together here without much thought. So for >> the case where the streamID isn't specified "data channel protocol" >> could be the value to indicate that it is used? > > That still requires declaring every channel in SDP doesn't it? > (Maybe that is your goal. But it is a non-goal for webrtc.) [CNG] Is it a non-goal for webrtc? Isn't draft-ejzak-mmusic-data-channel-sdpneg declaring channels? > > My thinking is that the sctpmap attribute identifies the a discipline > (convention) used to assign meaning to streams. Then the specification > of that discipline provides the details of how streams are assigned/used. [CNG] I understand this but there seems to be a LOT of overlap between the SCTP SDP and the Ejzak SDP. The goal of both is out-of-band negotiation of what is running on the STCP streams. > > Then, when the discipline is webrtc-datachannel (preferably changed to > a better name) draft-ietf-rtcweb-data-channel spells that out. So it > defines how streams are grouped into channels, and defines both > external and internal negotiation. It *ought* to reference (or be > merged with) the Ejzak draft for external negotiation. [CNG] Yes it certainly could do with being merged. > >>> IMO, from an mmusic perspective, we need to support both the static >>> and dynamic assignment of channels. We just want it to be done more >>> clearly. >> [CNG] Perhaps this is key, for a particular app in a SCTP association we >> need to say whether or not the streamID assignment is static or dynamic >> via the data channel protocol". > > Again, for interop with rtcweb we are stuck with "webrtc-datachannel" > as the "app". [CNG] I don't think that's a problem so long as its declared that it will be used. > >>> From a CLUE perspective, we need to decide if we want to use the >>> static or dynamic assignment. IMO the preferred choice is not obvious >>> - both have their attractions. At the moment I am *slightly* >>> preferring the dynamic. >> [CNG] Dynamic is probably OK so long as we have some sort of label >> mechanism to help sort out mapping when you have multiple instances of >> the same app. > > I think we would just specify an explicit "label" that CLUE uses to > identify its channel. [CNG] Is that an "app" label? :-). I don't think the problem is unique to CLUE so I think what ever is used here should be generic mechanism for indicating labels. > > Thanks, > Paul > >>> Thanks, >>> Paul >>> >>>>> >>>>> But, never the less, it would probably be good to have an example >>>>> showing how things would look like using Richard's draft, until we've >>>>> decided whether we are going to use it or not. I'll add that. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> Sent from my Sony Ericsson Xperia arc S >>>>> >>>>> Christian Groves wrote: >>>>> >>>>> >>>>> Hello Christer, >>>>> >>>>> I think that for the signaling we must specify a way of >>>>> negotiating at >>>>> the SDP level whether CLUE is supported. I agree there's lots of >>>>> ways it >>>>> could be done but we need to indicate which one/s CLUE should use. >>>>> >>>>> So for the SDP O/A procedures and example I think you have to assume >>>>> the >>>>> use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say >>>>> its a CLUE data channel according to the SDP given. You're just >>>>> opening >>>>> a generic channel, which may or may not be clue. Particularly in the >>>>> Answerer's case, it doesn't know that the Offer is going to use the >>>>> channel for CLUE. >>>>> >>>>> However: >>>>> m=application 54111 SCTP/DTLS 54111 >>>>> a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 >>>>> a=dcmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3 >>>>> >>>>> would unambiguously define it as a CLUE data channel. >>>>> >>>>> Regards, Christian >>>>> >>>>> On 17/02/2014 11:16 AM, Christer Holmberg wrote: >>>>>> Hi Christian, >>>>>> >>>>>> If you want to negotiate usage of CLUE (or, any other specific usage >>>>>> of a webrtc-datachannel) in SDP, one option is to use Richard's >>>>>> draft. The usage of that draft is listed as an open issue in the >>>>>> CLUE >>>>>> data channel draft. >>>>>> >>>>>> SIP also provides other mechanisms, e.g. media feature tags, for >>>>>> indicating support of features. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> Sent from my Sony Ericsson Xperia arc S >>>>>> >>>>>> Christian Groves wrote: >>>>>> >>>>>> >>>>>> Hello Christer, >>>>>> >>>>>> With the use of webrtc-datachannel how do I negotiate via SDP >>>>>> whether I >>>>>> want to use clue or not? >>>>>> >>>>>> A SCTP association (and thus webrtc-datachannel) for example >>>>>> could be >>>>>> used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP >>>>>> association to figure out that the endpoints support >>>>>> webrtc-datachannel >>>>>> put don't support the application that you want. >>>>>> >>>>>> In the example in section 4.6 there's no way of distinguishing that >>>>>> description for CLUE vs BFCP vs anything else. Its not a CLUE data >>>>>> channel is a generic data channel. >>>>>> >>>>>> Regards, Christian >>>>>> >>>>>> On 16/02/2014 1:03 AM, Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The draft submission deadline has passed, but I still wrote some >>>>>>> more text, shown below, for the SDP Offer/Answer Procedures >>>>>>> section. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> PS. Note that I will be on vacation next week, so I will once again >>>>>>> do my best trying to stay away from e-mails :) >>>>>>> >>>>>>> ----------------------- >>>>>>> >>>>>>> 4. SDP Offer/Answer Procedures >>>>>>> >>>>>>> 4.1. General >>>>>>> >>>>>>> This section describes how the SDP media description ("m=") >>>>>>> line for >>>>>>> a CLUE data channel is created, and how it is used in SDP >>>>>>> offers and >>>>>>> answers. >>>>>>> >>>>>>> NOTE: The proceudres associated with "m=" lines for other >>>>>>> media types >>>>>>> (e.g. audio and video) used in a CLUE session are outside the >>>>>>> scope >>>>>>> of this document. >>>>>>> >>>>>>> OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data >>>>>>> Channel >>>>>>> Negotiation mechanism >>>>>>> [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] >>>>>>> will be used with the CLUE data channel. >>>>>>> >>>>>>> NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will >>>>>>> be used >>>>>>> with the CLUE data channel, a new associated 'sub-protocol' >>>>>>> value >>>>>>> needs to be registered with IANA. >>>>>>> >>>>>>> 4.2. SDP Media Description Fields >>>>>>> >>>>>>> The field values of the "m=" line for the CLUE data channel >>>>>>> are set >>>>>>> as following: >>>>>>> >>>>>>> >>>>>>> +----------------+----------------+------------------------+----------------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> | media | port | >>>>>>> proto | fmt | >>>>>>> >>>>>>> +----------------+----------------+------------------------+----------------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP >>>>>>> port | >>>>>>> | | value >>>>>>> | | value | >>>>>>> >>>>>>> +----------------+----------------+------------------------+---------------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Table 1: SDP "proto" field values >>>>>>> >>>>>>> 4.3. SDP sctpmap Attribute >>>>>>> >>>>>>> The field values of the SDP sctpmap attribute associated >>>>>>> with the >>>>>>> CLUE data channel "m=" are set as following: >>>>>>> >>>>>>> >>>>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> | sctpmap-number | app | >>>>>>> max-message-size | stream | >>>>>>> >>>>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> | fmt value of | "webrtc-datachannel" | >>>>>>> Implemenation | "1" | >>>>>>> | the "m=" line | | >>>>>>> specific | | >>>>>>> >>>>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Table 2: SDP "proto" field values >>>>>>> >>>>>>> 4.4. SDP Offerer Procedures >>>>>>> >>>>>>> The procedures for the offerer follow the normal proceures >>>>>>> defined in >>>>>>> [ref-to-3264]. >>>>>>> >>>>>>> When the offerer creates an offer, which contains an "m=" >>>>>>> line >>>>>>> for a >>>>>>> CLUE data channel, it assigns the field values to the "m=" >>>>>>> line >>>>>>> according to the procedures in Section 4.2. In addition, the >>>>>>> offerer >>>>>>> MUST insert an SDP sctpmap attribute associated with the "m=" >>>>>>> line. >>>>>>> >>>>>>> In an offer, the offerer MUST NOT insert more than one "m=" >>>>>>> line for >>>>>>> a CLUE data channel. >>>>>>> >>>>>>> NOTE: CLUE does not support the usage of multiple CLUE data >>>>>>> channels. >>>>>>> >>>>>>> The offerer MUST NOT insert more than one SDP sctpmap >>>>>>> attributes in >>>>>>> an "m=" line for a CLUE data channel. >>>>>>> >>>>>>> If an offerer, in a subsequent offer, wants to disable the >>>>>>> CLUE data >>>>>>> channel, it assigns a zero port value to the "m=" line >>>>>>> associated >>>>>>> with the CLUE data channel. The answerer MUST NOT insert an >>>>>>> SDP >>>>>>> sctpmap attribute associated with the "m=" line. >>>>>>> >>>>>>> 4.5. SDP Answerer Procedures >>>>>>> >>>>>>> The procedures for the answerer follow the normal proceures >>>>>>> defined >>>>>>> in [ref-to-3264]. >>>>>>> >>>>>>> If the answerer receives an offer, which contains an "m=" >>>>>>> line >>>>>>> for a >>>>>>> CLUE data channel, and the answerer accepts the "m=" line, it >>>>>>> creates >>>>>>> and inserts an "m=" line in the associated answer. The >>>>>>> answerer >>>>>>> assigns the field values to the "m=" line according to the >>>>>>> procedures >>>>>>> in Section 4.2. >>>>>>> >>>>>>> If, in the offer, a zero port value has been assigned to the >>>>>>> "m=" >>>>>>> line for the CLUE channel, or it the answerer does not >>>>>>> accept the >>>>>>> "m=" line, but accepts other "m=" lines in the offer (i.e. >>>>>>> the >>>>>>> answerer will not reject the whole offer), it still >>>>>>> inserts an >>>>>>> "m=" >>>>>>> line for a CLUE data channel in the associated answer. The >>>>>>> answerer >>>>>>> then assigns a zero port value to the "m=" line. The answerer >>>>>>> MUST >>>>>>> NOT insert an SDP sctpmap attribute associated with the "m=" >>>>>>> line. >>>>>>> >>>>>>> 4.6. Example >>>>>>> >>>>>>> m=application 54111 SCTP/DTLS 54111 >>>>>>> a=sctpmap:54111 webrtc-datachannel >>>>>>> max-message-size=100000 streams=1 >>>>>>> >>>>>>> Figure 1: SDP Media Description for a CLUE data >>>>>>> channel >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 nobody Wed Feb 19 21:01:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB481A0312 for ; Wed, 19 Feb 2014 21:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ns3XZpCTg33 for ; Wed, 19 Feb 2014 21:01:55 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 517551A0554 for ; Wed, 19 Feb 2014 21:01:53 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta12.westchester.pa.mail.comcast.net with comcast id UV1U1n00217dt5G5CV1p9H; Thu, 20 Feb 2014 05:01:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id UV1p1n0093ZTu2S3ZV1piV; Thu, 20 Feb 2014 05:01:49 +0000 Message-ID: <53058C3D.1050107@alum.mit.edu> Date: Thu, 20 Feb 2014 00:01:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392872509; bh=wDNcCs5ul0x3X1tgYFMG0UgbAM0RHXeapGQmsMaWKrM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dZDu8Y/QEry4xQa9pvTY2b+2wgkkakAlLh6qbZJstcyeQALhPUQm/lzUD/zKxXb0p ONIK9RPgXd5r9vQsv4TevT9LY2E39WVVPb2BGE9bTmZZEav0+weeAl9cDF4qp+0+tc l9eBuT/kV4dbCPsLN2oUBCkAE1WxTsDO+OMOVhIIh8cuAViupyxjRWTrBnxmd0kar9 ftMHIJIxusB2j9zEdWz9l9IFD/1UEhMuUf80MG3qXjqkF7FajJF+Dyajc453fRJiOz aQcRjUVcketYMt6FL/QcMLJ45hGVU8onVq1eH7/DFFBBMvcEUdV9TZ2Rho+dH/Ebya v4k9+V8iEP5uw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ALik_5jLBqfu6yo3FtjoPWWMGlQ Subject: Re: [clue] Global Alternative Captures List - How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 05:01:57 -0000 Mark, Unsurprisingly, I think this is a good idea. :-) Thanks, Paul On 2/19/14 5:28 PM, Duckworth, Mark wrote: > At the Feb 11 design team meeting we thought this idea from Paul was > worth considering. Paul wrote (Feb 10): > > ================================================ > > - Leave existing per-scene CSE lists as-is. > > - Add another advertisement-wide CSE list. The entries in it could use > shorthand, by referencing CSEs from the individual scenes. > > E.g., > > Scene1 (CSE11, CSE12, CSE13) > > Scene2 (CSE21, CSE22) > > Scene3 (CSE31) > > Scene4 (CSE41) > > Global-CSE-List ( > > CSEg1(CSE11, CSE21, CSE31) > > CSEg2(CSE12, CSE22, CSE31) > > CSEg3(CSE13, CSE22, CSE31) > > ) > > Here the global CSE list has recommended a subset of the possible > combinations of CSEs from the different scenes, and has omitted Scene4 > altogether. This is a value judgement of what combinations make sense. > > Note that I would still allow the CSEs in the global list to reference > individual captures if desired. But referencing other CSEs is a > convenient shorthand. > > ================================================ > > I included a slide showing a slightly more detailed example for the case > we have been discussing at previous meetings. Slide 9 of > http://trac.tools.ietf.org/wg/clue/trac/raw-attachment/wiki/Design-Team/Framework_Issues_140211.pptx > This example gives alternatives for a consumer that wants to receive > only one capture, all the way up to a consumer that wants nine captures, > with all possibilities in between. > > I think this new proposed list could be called “global alternative > captures list” rather than a “global CSE list”. Maybe somebody has a > better suggestion for what to call it? The purpose of the list is for > the provider to give suggestions to the consumer about which captures to > choose, considering the entire advertisement. Each entry in the list is > an alternative. Each entry consists of a set of captures (for > shorthand, could reference multiple captures at once by referencing a > CSE instead of individual capture). > > For an advertisement with multiple scenes, where each scene can have > multiple CSEs with different number of captures in each, we have been > discussing how a consumer can make a good choice between requesting > captures from fewer scenes with more captures per scene, vs. requesting > captures from more scenes with fewer captures per scene. The “global > alternative captures list” gives the provider a way to suggest which > makes more sense from the provider’s viewpoint. Of course the consumer > can still take into account all the other information such as priority, > description, participant information and view attributes. > > Does the group support adding this additional list to an advertisement? > Should I make a specific proposal for text to add to the framework? Or > do we need more discussion or examples? > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Feb 19 21:18:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41431A0320 for ; Wed, 19 Feb 2014 21:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_44=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VwYoyRd66TV for ; Wed, 19 Feb 2014 21:18:47 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id E50A91A02D8 for ; Wed, 19 Feb 2014 21:18:46 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA11.westchester.pa.mail.comcast.net with comcast id UVHw1n0030xGWP85BVJjtR; Thu, 20 Feb 2014 05:18:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id UVJi1n00g3ZTu2S3YVJijC; Thu, 20 Feb 2014 05:18:43 +0000 Message-ID: <53059032.40908@alum.mit.edu> Date: Thu, 20 Feb 2014 00:18:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D18D51B@ESESSMB209.ericsson.se>, <53014B44.60600@nteczone.com> <2sen2h648ta6sevyeyw1y44k.1392596179208@email.android.com>, <53015E29.2000102@nteczone.com> <53016764.9050201@nteczone.com> <53018B68.2080209@alum.mit.edu> <530198FB.9000905@nteczone.com> <53027E21.2040008@alum.mit.edu> <53054E30.4090708@nteczone.com> In-Reply-To: <53054E30.4090708@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=1392873523; bh=SeGkNmSDI8DtdDDTjbbPPKWoEpGVaeAly33e6uadB/E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XJTb3iQhiTc0o3W9TUrzFVorphEDDkC488oS+/YPGW8rhJ164xtMm9Gkx5G1KKT2k zwLcIGB55IZR+EdZBT+KiyOlKL2deNuzGRgSHh3CsbX+SHWeSYr8QSBaJsd6z40dRr 3uQuiQ3q9p9tHSEJ313HVmvzEf5APdphs6O4CM0XeZAYgN+XQBTr+SG5onatGw5T1M f/DeV9e1Ei6v+7FKnkypwuQL+67QES4pH8z2TsEEZWE+5MmVKzAAehdlOClhdTJv0J ppm1O3vkzEdOYo2MH4W2YBtaqCc3vstlmBAP4VUtkbVGAH3ZOlcegV5M5Qs8ZpVHPR NWGm0i3vTRWxg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/jGEWjResE0aQVcTcLcvsd6gpNQ4 Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 05:18:49 -0000 On 2/19/14 7:37 PM, Christian Groves wrote: >>>> The webrtc data channel open protocol does not take a stream ID as an >>>> argument. It internally assigns stream IDs. Rtcweb has specified how >>>> you can use preassigned channels without the open, but then it isn't >>>> using the data channel protocol. >>> [CNG] I just threw something together here without much thought. So for >>> the case where the streamID isn't specified "data channel protocol" >>> could be the value to indicate that it is used? >> >> That still requires declaring every channel in SDP doesn't it? >> (Maybe that is your goal. But it is a non-goal for webrtc.) > [CNG] Is it a non-goal for webrtc? Isn't > draft-ejzak-mmusic-data-channel-sdpneg declaring channels? The ejzak draft isn't really a mainstream rtcweb-sponsored draft. Richard and I and some other people had a discussion about the concepts in this once. (I forget which meeting.) I think the draft came from that. The main rtcweb people don't want to declare channels in SDP. We have just managed to get to a point where they can tolerate it as an option. >> My thinking is that the sctpmap attribute identifies the a discipline >> (convention) used to assign meaning to streams. Then the specification >> of that discipline provides the details of how streams are assigned/used. > [CNG] I understand this but there seems to be a LOT of overlap between > the SCTP SDP and the Ejzak SDP. The goal of both is out-of-band > negotiation of what is running on the STCP streams. There is overlap because Richard is trying to improve on what the sctp-sdp draft proposes. But the sctp-sdp draft only intends to define the association itself, and some attributes of it, such as the max number of streams. It does nothing on a per-channel basis. >> Then, when the discipline is webrtc-datachannel (preferably changed to >> a better name) draft-ietf-rtcweb-data-channel spells that out. So it >> defines how streams are grouped into channels, and defines both >> external and internal negotiation. It *ought* to reference (or be >> merged with) the Ejzak draft for external negotiation. > [CNG] Yes it certainly could do with being merged. >> >>>> IMO, from an mmusic perspective, we need to support both the static >>>> and dynamic assignment of channels. We just want it to be done more >>>> clearly. >>> [CNG] Perhaps this is key, for a particular app in a SCTP association we >>> need to say whether or not the streamID assignment is static or dynamic >>> via the data channel protocol". >> >> Again, for interop with rtcweb we are stuck with "webrtc-datachannel" >> as the "app". > [CNG] I don't think that's a problem so long as its declared that it > will be used. >> >>>> From a CLUE perspective, we need to decide if we want to use the >>>> static or dynamic assignment. IMO the preferred choice is not obvious >>>> - both have their attractions. At the moment I am *slightly* >>>> preferring the dynamic. >>> [CNG] Dynamic is probably OK so long as we have some sort of label >>> mechanism to help sort out mapping when you have multiple instances of >>> the same app. >> >> I think we would just specify an explicit "label" that CLUE uses to >> identify its channel. > [CNG] Is that an "app" label? :-). No. It is an arbitrary label. For channels opened with the channel protocol it shows up in the API. > I don't think the problem is unique > to CLUE so I think what ever is used here should be generic mechanism > for indicating labels. That is what it is in JSEP. Thanks, Paul >> Thanks, >> Paul >> >>>> Thanks, >>>> Paul >>>> >>>>>> >>>>>> But, never the less, it would probably be good to have an example >>>>>> showing how things would look like using Richard's draft, until we've >>>>>> decided whether we are going to use it or not. I'll add that. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> Sent from my Sony Ericsson Xperia arc S >>>>>> >>>>>> Christian Groves wrote: >>>>>> >>>>>> >>>>>> Hello Christer, >>>>>> >>>>>> I think that for the signaling we must specify a way of >>>>>> negotiating at >>>>>> the SDP level whether CLUE is supported. I agree there's lots of >>>>>> ways it >>>>>> could be done but we need to indicate which one/s CLUE should use. >>>>>> >>>>>> So for the SDP O/A procedures and example I think you have to assume >>>>>> the >>>>>> use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say >>>>>> its a CLUE data channel according to the SDP given. You're just >>>>>> opening >>>>>> a generic channel, which may or may not be clue. Particularly in the >>>>>> Answerer's case, it doesn't know that the Offer is going to use the >>>>>> channel for CLUE. >>>>>> >>>>>> However: >>>>>> m=application 54111 SCTP/DTLS 54111 >>>>>> a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1 >>>>>> a=dcmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3 >>>>>> >>>>>> would unambiguously define it as a CLUE data channel. >>>>>> >>>>>> Regards, Christian >>>>>> >>>>>> On 17/02/2014 11:16 AM, Christer Holmberg wrote: >>>>>>> Hi Christian, >>>>>>> >>>>>>> If you want to negotiate usage of CLUE (or, any other specific usage >>>>>>> of a webrtc-datachannel) in SDP, one option is to use Richard's >>>>>>> draft. The usage of that draft is listed as an open issue in the >>>>>>> CLUE >>>>>>> data channel draft. >>>>>>> >>>>>>> SIP also provides other mechanisms, e.g. media feature tags, for >>>>>>> indicating support of features. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> Sent from my Sony Ericsson Xperia arc S >>>>>>> >>>>>>> Christian Groves wrote: >>>>>>> >>>>>>> >>>>>>> Hello Christer, >>>>>>> >>>>>>> With the use of webrtc-datachannel how do I negotiate via SDP >>>>>>> whether I >>>>>>> want to use clue or not? >>>>>>> >>>>>>> A SCTP association (and thus webrtc-datachannel) for example >>>>>>> could be >>>>>>> used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP >>>>>>> association to figure out that the endpoints support >>>>>>> webrtc-datachannel >>>>>>> put don't support the application that you want. >>>>>>> >>>>>>> In the example in section 4.6 there's no way of distinguishing that >>>>>>> description for CLUE vs BFCP vs anything else. Its not a CLUE data >>>>>>> channel is a generic data channel. >>>>>>> >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 16/02/2014 1:03 AM, Christer Holmberg wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The draft submission deadline has passed, but I still wrote some >>>>>>>> more text, shown below, for the SDP Offer/Answer Procedures >>>>>>>> section. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> PS. Note that I will be on vacation next week, so I will once again >>>>>>>> do my best trying to stay away from e-mails :) >>>>>>>> >>>>>>>> ----------------------- >>>>>>>> >>>>>>>> 4. SDP Offer/Answer Procedures >>>>>>>> >>>>>>>> 4.1. General >>>>>>>> >>>>>>>> This section describes how the SDP media description ("m=") >>>>>>>> line for >>>>>>>> a CLUE data channel is created, and how it is used in SDP >>>>>>>> offers and >>>>>>>> answers. >>>>>>>> >>>>>>>> NOTE: The proceudres associated with "m=" lines for other >>>>>>>> media types >>>>>>>> (e.g. audio and video) used in a CLUE session are outside the >>>>>>>> scope >>>>>>>> of this document. >>>>>>>> >>>>>>>> OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data >>>>>>>> Channel >>>>>>>> Negotiation mechanism >>>>>>>> [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] >>>>>>>> will be used with the CLUE data channel. >>>>>>>> >>>>>>>> NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will >>>>>>>> be used >>>>>>>> with the CLUE data channel, a new associated 'sub-protocol' >>>>>>>> value >>>>>>>> needs to be registered with IANA. >>>>>>>> >>>>>>>> 4.2. SDP Media Description Fields >>>>>>>> >>>>>>>> The field values of the "m=" line for the CLUE data channel >>>>>>>> are set >>>>>>>> as following: >>>>>>>> >>>>>>>> >>>>>>>> +----------------+----------------+------------------------+----------------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | media | port | >>>>>>>> proto | fmt | >>>>>>>> >>>>>>>> +----------------+----------------+------------------------+----------------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP >>>>>>>> port | >>>>>>>> | | value >>>>>>>> | | value | >>>>>>>> >>>>>>>> +----------------+----------------+------------------------+---------------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Table 1: SDP "proto" field values >>>>>>>> >>>>>>>> 4.3. SDP sctpmap Attribute >>>>>>>> >>>>>>>> The field values of the SDP sctpmap attribute associated >>>>>>>> with the >>>>>>>> CLUE data channel "m=" are set as following: >>>>>>>> >>>>>>>> >>>>>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | sctpmap-number | app | >>>>>>>> max-message-size | stream | >>>>>>>> >>>>>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | fmt value of | "webrtc-datachannel" | >>>>>>>> Implemenation | "1" | >>>>>>>> | the "m=" line | | >>>>>>>> specific | | >>>>>>>> >>>>>>>> +---------------------+---------------------------+-----------------------+---------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Table 2: SDP "proto" field values >>>>>>>> >>>>>>>> 4.4. SDP Offerer Procedures >>>>>>>> >>>>>>>> The procedures for the offerer follow the normal proceures >>>>>>>> defined in >>>>>>>> [ref-to-3264]. >>>>>>>> >>>>>>>> When the offerer creates an offer, which contains an "m=" >>>>>>>> line >>>>>>>> for a >>>>>>>> CLUE data channel, it assigns the field values to the "m=" >>>>>>>> line >>>>>>>> according to the procedures in Section 4.2. In addition, the >>>>>>>> offerer >>>>>>>> MUST insert an SDP sctpmap attribute associated with the "m=" >>>>>>>> line. >>>>>>>> >>>>>>>> In an offer, the offerer MUST NOT insert more than one "m=" >>>>>>>> line for >>>>>>>> a CLUE data channel. >>>>>>>> >>>>>>>> NOTE: CLUE does not support the usage of multiple CLUE data >>>>>>>> channels. >>>>>>>> >>>>>>>> The offerer MUST NOT insert more than one SDP sctpmap >>>>>>>> attributes in >>>>>>>> an "m=" line for a CLUE data channel. >>>>>>>> >>>>>>>> If an offerer, in a subsequent offer, wants to disable the >>>>>>>> CLUE data >>>>>>>> channel, it assigns a zero port value to the "m=" line >>>>>>>> associated >>>>>>>> with the CLUE data channel. The answerer MUST NOT insert an >>>>>>>> SDP >>>>>>>> sctpmap attribute associated with the "m=" line. >>>>>>>> >>>>>>>> 4.5. SDP Answerer Procedures >>>>>>>> >>>>>>>> The procedures for the answerer follow the normal proceures >>>>>>>> defined >>>>>>>> in [ref-to-3264]. >>>>>>>> >>>>>>>> If the answerer receives an offer, which contains an "m=" >>>>>>>> line >>>>>>>> for a >>>>>>>> CLUE data channel, and the answerer accepts the "m=" line, it >>>>>>>> creates >>>>>>>> and inserts an "m=" line in the associated answer. The >>>>>>>> answerer >>>>>>>> assigns the field values to the "m=" line according to the >>>>>>>> procedures >>>>>>>> in Section 4.2. >>>>>>>> >>>>>>>> If, in the offer, a zero port value has been assigned to the >>>>>>>> "m=" >>>>>>>> line for the CLUE channel, or it the answerer does not >>>>>>>> accept the >>>>>>>> "m=" line, but accepts other "m=" lines in the offer (i.e. >>>>>>>> the >>>>>>>> answerer will not reject the whole offer), it still >>>>>>>> inserts an >>>>>>>> "m=" >>>>>>>> line for a CLUE data channel in the associated answer. The >>>>>>>> answerer >>>>>>>> then assigns a zero port value to the "m=" line. The answerer >>>>>>>> MUST >>>>>>>> NOT insert an SDP sctpmap attribute associated with the "m=" >>>>>>>> line. >>>>>>>> >>>>>>>> 4.6. Example >>>>>>>> >>>>>>>> m=application 54111 SCTP/DTLS 54111 >>>>>>>> a=sctpmap:54111 webrtc-datachannel >>>>>>>> max-message-size=100000 streams=1 >>>>>>>> >>>>>>>> Figure 1: SDP Media Description for a CLUE data >>>>>>>> channel >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 nobody Thu Feb 20 01:44:43 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146E31A0074 for ; Thu, 20 Feb 2014 01:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROiSsecbLW13 for ; Thu, 20 Feb 2014 01:44:34 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 51CA71A0073 for ; Thu, 20 Feb 2014 01:44:33 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-2f-5305ce7cb7f8 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id AF.F4.04249.C7EC5035; Thu, 20 Feb 2014 10:44:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Thu, 20 Feb 2014 10:44:28 +0100 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] Clue dinner in London Doodle Thread-Index: AQHPLcuMxcKwxpsJUU2YalRlR5/N9pq95Rn/ Date: Thu, 20 Feb 2014 09:44:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_s9jwl6b47aqk5hkhkan3shya1392889461289emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW7tOdZggw0TmCzajx9jtNh/6jKz xef9+5kdmD2m/N7I6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZWzdmFOwwLCie7ZTA+NV jS5GTg4JAROJnvunmCBsMYkL99azdTFycQgJHGGU+NFzA8pZwigxc+YWoCoODjYBC4nuf9og DSICThIXXr5nAbGZBfQlfhxbxAZiCwsYSGxZd4cZpFxEwFBiwmRJiHIjiZmNs8DKWQRUJdZd eglm8wq4SWzdeJ0dxBYSCJA4u/gKM4jNKRAo8fDXa1YQmxHotu+n1jBBrBKXuPVkPtTNAhJL 9pxnhrBFJV4+/scKUZMjcWr9REaI+YISJ2c+YZnAKDILSfssJGWzkJRBxPUkbkydwgZha0ss W/iaGcLWlZjx7xALsvgCRvZVjBzFqcVJuelGBpsYgbF0cMtvix2Ml//aHGKU5mBREuf9+NY5 SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjTIYP8xz4Mje+6Hl2SOL6TwmO4G8Tqm5s5Fqm fMe9Y/9DbYv4vz77X6zOYP+wb+H0jU8vNE2p75J67SibvvJX70HvIKPPDjUTOlct+XKQSVS8 s/ThdZPfy7fJh0WavPfg+p25gdkrc8feEku2+ctlnmZOjgo+mZfPUVRzomSjcMimiPb70xTd lViKMxINtZiLihMB5IZF/3MCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/sPTrPWigHh5PCx3DHQ4Cm5cFHAs Cc: "Alissa Cooper \(alcoop\)" Subject: Re: [clue] Clue dinner in London Doodle X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 09:44:38 -0000 --_000_s9jwl6b47aqk5hkhkan3shya1392889461289emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am currently staying at the hotel. It is located in an area with a huge m= iddle-eastern/muslim community, and there are tons of such restaurants in t= he area. Most of them are pretty small, though, so I understand they may no= t take reservations. Regards, Christer Sent from my Sony Ericsson Xperia arc S Mary Barnes wrote: I think it would be good for us to get together informally for dinner on Mo= nday, March 3rd (that's pretty much the only open night I have). The plena= ry runs until 19:50. The restaurant I've selected takes no reservations, b= ut I'm thinking it won't be too long of a wait by the time we get there: ht= tp://www.relaisdevenise.com/marylebone/ It's about a 20 minute walk from the hotel. The plan would be to meet in the hotel lobby near the hotel registration (n= ot IETF registration) at 8:15 pm and walk together from there. Note, if th= e restaurant is really busy and we have a larger group, we may have to spli= t into multiple tables. It's very easy as the only choices you make are how you want your steak coo= ked and what you want to drink. The price is extremely reasonable for Lond= on - salad, steak and frites for 23 GBP. Please fill out the doodle no later than 8am on Monday, so I know who all w= ill be coming, so we don't leave without anyone. http://doodle.com/zzg6nahhuypfzni7 And, if you don't fill out the poll and you arrive on your own, you may not= get a seat - it will be impossible to squeeze an extra person into any of = these tables as it is very, very, very tightly packed. You have just a tad= more elbow room than you'll have on your flight to the meeting, so please = do not bring your computer bags - there really won't be anywhere to stow th= em. Mary. ---------- Forwarded message ---------- From: Doodle > Date: Wed, Feb 19, 2014 at 5:25 PM Subject: Doodle: Link for poll "CLUE Dinner" To: Mary Barnes > You have initiated a poll "CLUE Dinner" at Doodle. The link to your poll is= : http://doodle.com/zzg6nahhuypfzni7 Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.) --_000_s9jwl6b47aqk5hkhkan3shya1392889461289emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Hi,=0A=
=0A=
I am currently staying at the hotel. It is located in an area with a huge m=
iddle-eastern/muslim community, and there are tons of such restaurants in t=
he area. Most of them are pretty small, though, so I understand they may no=
t take reservations.=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Mary Barnes <mary.ietf.barnes@gmail.com> wrote:=0A=
=0A=
I think it would be good for us to get together informally= for dinner on Monday, March 3rd (that's pretty much the only open night I = have).  The plenary runs until 19:50.  The restaurant I've select= ed takes no reservations, but I'm thinking it won't be too long of a wait by the time we get there: http://www.relaisdevenise.com/maryle= bone/
It's about a 20 minute walk from the hotel.

The plan would be to meet in the hotel lobby near the hotel registrati= on (not IETF registration) at 8:15 pm and walk together from there.  N= ote, if the restaurant is really busy and we have a larger group, we may ha= ve to split into multiple tables.  

It's very easy as the only choices you make are how you want your stea= k cooked and what you want to drink.  The price is extremely reasonabl= e for London - salad, steak and frites for 23 GBP.  

Please fill out the doodle no later than 8am on Monday, so I know who = all will be coming, so we don't leave without anyone. 

And, if you don't fill out the poll and you arrive on your own, you ma= y not get a seat - it will be impossible to squeeze an extra person into an= y of these tables as it is very, very, very tightly packed.  You have = just a tad more elbow room than you'll have on your flight to the meeting, so please do not bring your computer b= ags - there really won't be anywhere to stow them.

Mary. 

---------- Forwarded message ----------
From: Doodle <mailer@doodle.com>
Date: Wed, Feb 19, 2014 at 5:25 PM
Subject: Doodle: Link for poll "CLUE Dinner"
To: Mary Barnes <mary.ietf= .barnes@gmail.com>


You have initiated a poll "CLUE Dinner" at Doodle. The link to yo= ur poll is:

http://doo= dle.com/zzg6nahhuypfzni7

Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too.
(If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.)

--_000_s9jwl6b47aqk5hkhkan3shya1392889461289emailandroidcom_-- From nobody Thu Feb 20 07:10:52 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95301A0170 for ; Thu, 20 Feb 2014 07:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nZLroOIcmar for ; Thu, 20 Feb 2014 07:10:46 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 096A11A01B4 for ; Thu, 20 Feb 2014 07:10:40 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id v1so768080yhn.26 for ; Thu, 20 Feb 2014 07:10:37 -0800 (PST) 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=lu82fOeblqQx3cpEl2E0gG7ahqCjrrC6C6uycII+1tA=; b=Ijr83xSlR5aRImoSoo1pVzlIqt00jP1BDkwFW3Gn/buuVDY0SoOFypXmM331qfn33n Y9iC13NhgHblvSDY2Xeko3jzPpuNLuTE9aYJaeJuFxLDNSui3OhLZPF7dUDTLI0aXCuD ELCve3OFe4N8TPiEcP2e0v2PRDkT9id3VoZsolft6j083/I1t6gDBtKVQWjXU3AeRH0s fMHG0lq8H8GFsXaJd/EQ0aQf7q6JCP1q+UXiJ4BjgKRvQfasXpwr0tjOi51Ri5eR80C8 rWb2dgrvoRmp/klHIl0UmoVy8kd1qzWUY319EbQofT/1MDFZ9IbsKqNQfzodWWeOr+rl jWPg== MIME-Version: 1.0 X-Received: by 10.236.150.164 with SMTP id z24mr3814534yhj.75.1392909037197; Thu, 20 Feb 2014 07:10:37 -0800 (PST) Received: by 10.170.213.85 with HTTP; Thu, 20 Feb 2014 07:10:37 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 09:10:37 -0600 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf303b3c935ddf2d04f2d7e81b Archived-At: http://mailarchive.ietf.org/arch/msg/clue/31AUF5NXgis5DR-c-JvHv7xCsGg Cc: "Alissa Cooper \(alcoop\)" , CLUE Subject: Re: [clue] Clue dinner in London Doodle X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 15:10:50 -0000 --20cf303b3c935ddf2d04f2d7e81b Content-Type: text/plain; charset=ISO-8859-1 I am very familiar with the area. The problem I have is with regards to my dietary restrictions. Unless someone gets their bread crumbs in my food there is no potential for cross contamination at Relais de Venise. I also wouldn't have time to go to any of those restaurants before Monday and check out whether or not they can ensure that I would get gluten free food - again, the problem isn't just the ingredients - it's how it's prepared that also impacts me (small kitchens won't have a dedicated GF prep area or cooking utensils). And, the information online is not encouraging: http://www.toptable.co.uk/s/london/middle-eastern-restaurants/m72/ Of the 98 middle eastern restaurants in London area, only one is noted to be able to accommodate gluten-free and that's in Wimbledon. Basically, I'm not willing to take the risk of getting sick that early in the week, so I have selected a place that I know will work for me. Mary. On Thu, Feb 20, 2014 at 3:44 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I am currently staying at the hotel. It is located in an area with a huge middle-eastern/muslim community, and there are tons of such restaurants in the area. Most of them are pretty small, though, so I understand they may not take reservations. > > Regards, > > Christer > > Sent from my Sony Ericsson Xperia arc S > > Mary Barnes wrote: > > > I think it would be good for us to get together informally for dinner on > Monday, March 3rd (that's pretty much the only open night I have). The > plenary runs until 19:50. The restaurant I've selected takes no > reservations, but I'm thinking it won't be too long of a wait by the time > we get there: http://www.relaisdevenise.com/marylebone/ > It's about a 20 minute walk from the hotel. > > The plan would be to meet in the hotel lobby near the hotel registration > (not IETF registration) at 8:15 pm and walk together from there. Note, if > the restaurant is really busy and we have a larger group, we may have to > split into multiple tables. > > It's very easy as the only choices you make are how you want your steak > cooked and what you want to drink. The price is extremely reasonable for > London - salad, steak and frites for 23 GBP. > > Please fill out the doodle no later than 8am on Monday, so I know who > all will be coming, so we don't leave without anyone. > http://doodle.com/zzg6nahhuypfzni7 > > And, if you don't fill out the poll and you arrive on your own, you may > not get a seat - it will be impossible to squeeze an extra person into any > of these tables as it is very, very, very tightly packed. You have just a > tad more elbow room than you'll have on your flight to the meeting, so > please do not bring your computer bags - there really won't be anywhere to > stow them. > > Mary. > > ---------- Forwarded message ---------- > From: Doodle > Date: Wed, Feb 19, 2014 at 5:25 PM > Subject: Doodle: Link for poll "CLUE Dinner" > To: Mary Barnes > > > You have initiated a poll "CLUE Dinner" at Doodle. The link to your poll > is: > > http://doodle.com/zzg6nahhuypfzni7 > > Share this link with all those who should cast their votes. Do not forget > to cast your vote, too. > (If you did not initiate this poll, somebody must accidentally have used > your e-mail address; simply ignore this e-mail, please.) > > --20cf303b3c935ddf2d04f2d7e81b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am very familiar with the area. =A0The problem I have is= with regards to my dietary restrictions. =A0Unless someone gets their brea= d crumbs in my food there is no potential for cross contamination at Relais= de Venise. =A0I also wouldn't have time to go to any of those restaura= nts before Monday and check out whether or not they can ensure that I would= get gluten free food - again, the problem isn't just the ingredients -= it's how it's prepared that also impacts me (small kitchens won= 9;t have a dedicated GF prep area or cooking utensils). =A0 And, the inform= ation online is not encouraging:
http://www.toptable.co.uk/s/london/middle-eastern-restaurants/m72/<= /div>
Of the 98 middle eastern restaurants in London area, only one is = noted to be able to accommodate gluten-free and that's in Wimbledon. = =A0

Basically, I'm not willing to take the risk of gett= ing sick that early in the week, so I have selected a place that I know wil= l work for me.=A0=A0=A0

Mary.=A0


On Thu, Feb 20, 2014 at 3:44 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wro= te:
Hi,

I am currently staying at the hotel. It is located in an area with a huge m=
iddle-eastern/muslim community, and there are tons of such restaurants in t=
he area. Most of them are pretty small, though, so I understand they may no=
t take reservations.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
I think it would be good for us to get together informally= for dinner on Monday, March 3rd (that's pretty much the only open nigh= t I have). =A0The plenary runs until 19:50. =A0The restaurant I've sele= cted takes no reservations, but I'm thinking it won't be too long of a wait by the time we get there:=A0http://www.relais= devenise.com/marylebone/
It's about a 20 minute walk from the hotel.

The plan would be to meet in the hotel lobby near the hotel registrati= on (not IETF registration) at 8:15 pm and walk together from there. =A0Note= , if the restaurant is really busy and we have a larger group, we may have = to split into multiple tables. =A0

It's very easy as the only choices you make are how you want your = steak cooked and what you want to drink. =A0The price is extremely reasonab= le for London - salad, steak and frites for 23 GBP. =A0

Please fill out the doodle no later than 8am on Monday, so I know who = all will be coming, so we don't leave without anyone.=A0

And, if you don't fill out the poll and you arrive on your own, yo= u may not get a seat - it will be impossible to squeeze an extra person int= o any of these tables as it is very, very, very tightly packed. =A0You have= just a tad more elbow room than you'll have on your flight to the meeting, so please do not bring your computer b= ags - there really won't be anywhere to stow them.

Mary.=A0

---------- Forwarded message ----------
From: Doodle <mailer@doodle.com><= /span>
Date: Wed, Feb 19, 2014 at 5:25 PM
Subject: Doodle: Link for poll "CLUE Dinner"
To: Mary Barnes <mary.ietf.barnes@gmail.com>


You have initiated a poll "CLUE Dinner" at Doodle. The link to yo= ur poll is:

http://doo= dle.com/zzg6nahhuypfzni7

Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too.
(If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.)


--20cf303b3c935ddf2d04f2d7e81b-- From nobody Thu Feb 20 08:35:24 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B091A0222 for ; Thu, 20 Feb 2014 08:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsTmeLLZmT_4 for ; Thu, 20 Feb 2014 08:35:19 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C6D7A1A01EE for ; Thu, 20 Feb 2014 08:35:18 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-42-53062ec27232 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 02.AC.10875.2CE26035; Thu, 20 Feb 2014 17:35:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Thu, 20 Feb 2014 17:35:13 +0100 From: Christer Holmberg To: Mary Barnes Thread-Topic: [clue] Clue dinner in London Doodle Thread-Index: AQHPLcuMxcKwxpsJUU2YalRlR5/N9pq95Rn/gABKXYCAAChnkw== Date: Thu, 20 Feb 2014 16:35:13 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_cwbx0dmb3cjo4eeov991npip1392914111094emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje4hPbZgg/Uv1Szajx9jtNh/6jKz xef9+5kdmD2m/N7I6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZVw4sZat4JJPxdVbJ5ga GNfadzFyckgImEj82t7BDGGLSVy4t56ti5GLQ0jgEKNE159rjBDOEkaJHUu7WLsYOTjYBCwk uv9pgzSICOhIfPv8lg0kzCzgKvH+Ri1IWFjAQGLLujvMIGERAUOJCZMlIaqdJJbu2AsWZhFQ lTjczAQS5hVwk1h6YR4TxKJLjBJH51xhA0lwCgRKTJq1DOw0RqDTvp9aA9bALCAucevJfCaI kwUkluw5D3W+qMTLx/9YIWpyJJ6taGWHWCAocXLmE5YJjCKzkLTPQlI2C0kZRFxP4sbUKWwQ trbEsoWvmSFsXYkZ/w6xIIsvYGRfxciem5iZk15uuIkRGEsHt/zW3cF46pzIIUZpDhYlcd4P b52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTD2Z5xLb6+TLVP71pST9Pz5UbGvsSHPlivd PxuTzahlbH79VnXkclYF8c6N/op1OoKLf1zsvM6zMDBWvDDDa97fraV+fkuYzzj+5OBkn+38 WmGXXkBaf/R+v+9Hpq54FjLxaoG08TXxF6p/N20802c70f3lAYcUtvsJnYVMtTNTb3Vnt4v2 9iuxFGckGmoxFxUnAgBW3Ba+cwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/LY_x2sHcMTmyAPvonAxzRHTiULk Cc: "Alissa Cooper \(alcoop\)" , CLUE Subject: Re: [clue] Clue dinner in London Doodle X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 16:35:23 -0000 --_000_cwbx0dmb3cjo4eeov991npip1392914111094emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Instead of having dinner, this time we could simply sit down and smoke wate= r pipe :) Regards, Christer Sent from my Sony Ericsson Xperia arc S Mary Barnes wrote: I am very familiar with the area. The problem I have is with regards to my= dietary restrictions. Unless someone gets their bread crumbs in my food t= here is no potential for cross contamination at Relais de Venise. I also w= ouldn't have time to go to any of those restaurants before Monday and check= out whether or not they can ensure that I would get gluten free food - aga= in, the problem isn't just the ingredients - it's how it's prepared that al= so impacts me (small kitchens won't have a dedicated GF prep area or cookin= g utensils). And, the information online is not encouraging: http://www.toptable.co.uk/s/london/middle-eastern-restaurants/m72/ Of the 98 middle eastern restaurants in London area, only one is noted to b= e able to accommodate gluten-free and that's in Wimbledon. Basically, I'm not willing to take the risk of getting sick that early in t= he week, so I have selected a place that I know will work for me. Mary. On Thu, Feb 20, 2014 at 3:44 AM, Christer Holmberg > wrote: Hi, I am currently staying at the hotel. It is located in an area with a huge m= iddle-eastern/muslim community, and there are tons of such restaurants in t= he area. Most of them are pretty small, though, so I understand they may no= t take reservations. Regards, Christer Sent from my Sony Ericsson Xperia arc S Mary Barnes >= wrote: I think it would be good for us to get together informally for dinner on Mo= nday, March 3rd (that's pretty much the only open night I have). The plena= ry runs until 19:50. The restaurant I've selected takes no reservations, b= ut I'm thinking it won't be too long of a wait by the time we get there: ht= tp://www.relaisdevenise.com/marylebone/ It's about a 20 minute walk from the hotel. The plan would be to meet in the hotel lobby near the hotel registration (n= ot IETF registration) at 8:15 pm and walk together from there. Note, if th= e restaurant is really busy and we have a larger group, we may have to spli= t into multiple tables. It's very easy as the only choices you make are how you want your steak coo= ked and what you want to drink. The price is extremely reasonable for Lond= on - salad, steak and frites for 23 GBP. Please fill out the doodle no later than 8am on Monday, so I know who all w= ill be coming, so we don't leave without anyone. http://doodle.com/zzg6nahhuypfzni7 And, if you don't fill out the poll and you arrive on your own, you may not= get a seat - it will be impossible to squeeze an extra person into any of = these tables as it is very, very, very tightly packed. You have just a tad= more elbow room than you'll have on your flight to the meeting, so please = do not bring your computer bags - there really won't be anywhere to stow th= em. Mary. ---------- Forwarded message ---------- From: Doodle > Date: Wed, Feb 19, 2014 at 5:25 PM Subject: Doodle: Link for poll "CLUE Dinner" To: Mary Barnes > You have initiated a poll "CLUE Dinner" at Doodle. The link to your poll is= : http://doodle.com/zzg6nahhuypfzni7 Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.) --_000_cwbx0dmb3cjo4eeov991npip1392914111094emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Instead of having dinner, this time we could simply sit down an=
d smoke water pipe :)=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Mary Barnes <mary.ietf.barnes@gmail.com> wrote:=0A=
=0A=
I am very familiar with the area.  The problem I have= is with regards to my dietary restrictions.  Unless someone gets thei= r bread crumbs in my food there is no potential for cross contamination at = Relais de Venise.  I also wouldn't have time to go to any of those restaurants before Monday and check out whether or n= ot they can ensure that I would get gluten free food - again, the problem i= sn't just the ingredients - it's how it's prepared that also impacts me (sm= all kitchens won't have a dedicated GF prep area or cooking utensils).   And, the information online is n= ot encouraging:
Of the 98 middle eastern restaurants in London area, only one is noted= to be able to accommodate gluten-free and that's in Wimbledon.  

Basically, I'm not willing to take the risk of getting sick that early= in the week, so I have selected a place that I know will work for me. = ;  

Mary. 


On Thu, Feb 20, 2014 at 3:44 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
H=
i,

I am currently staying at the hotel. It is located in an area with a huge m=
iddle-eastern/muslim community, and there are tons of such restaurants in t=
he area. Most of them are pretty small, though, so I understand they may no=
t take reservations.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
I think it would be good for us to get together informally= for dinner on Monday, March 3rd (that's pretty much the only open night I = have).  The plenary runs until 19:50.  The restaurant I've select= ed takes no reservations, but I'm thinking it won't be too long of a wait by the time we get there: http://www.relaisd= evenise.com/marylebone/
It's about a 20 minute walk from the hotel.

The plan would be to meet in the hotel lobby near the hotel registrati= on (not IETF registration) at 8:15 pm and walk together from there.  N= ote, if the restaurant is really busy and we have a larger group, we may ha= ve to split into multiple tables.  

It's very easy as the only choices you make are how you want your stea= k cooked and what you want to drink.  The price is extremely reasonabl= e for London - salad, steak and frites for 23 GBP.  

Please fill out the doodle no later than 8am on Monday, so I know who = all will be coming, so we don't leave without anyone. 

And, if you don't fill out the poll and you arrive on your own, you ma= y not get a seat - it will be impossible to squeeze an extra person into an= y of these tables as it is very, very, very tightly packed.  You have = just a tad more elbow room than you'll have on your flight to the meeting, so please do not bring your computer b= ags - there really won't be anywhere to stow them.

Mary. 

---------- Forwarded message ----------
From: Doodle <mailer@doodle.com><= /span>
Date: Wed, Feb 19, 2014 at 5:25 PM
Subject: Doodle: Link for poll "CLUE Dinner"
To: Mary Barnes <mary.ietf.barnes@gmail.com>


You have initiated a poll "CLUE Dinner" at Doodle. The link to yo= ur poll is:

http://doo= dle.com/zzg6nahhuypfzni7

Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too.
(If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.)


--_000_cwbx0dmb3cjo4eeov991npip1392914111094emailandroidcom_-- From nobody Thu Feb 20 11:15:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FFB1A0235 for ; Thu, 20 Feb 2014 11:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCzUChoDgNHQ for ; Thu, 20 Feb 2014 11:15:52 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 78A201A014C for ; Thu, 20 Feb 2014 11:15:52 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta06.westchester.pa.mail.comcast.net with comcast id Uj541n0040vyq2s56jFokH; Thu, 20 Feb 2014 19:15:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id UjFo1n00C3ZTu2S3RjFoyu; Thu, 20 Feb 2014 19:15:48 +0000 Message-ID: <53065464.9060003@alum.mit.edu> Date: Thu, 20 Feb 2014 14:15:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB54F@CRPMBOXPRD07.polycom.com> <52F82841.5010001@nteczone.com> In-Reply-To: <52F82841.5010001@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=1392923748; bh=KHee1NJBC9NLB2rL/9ajmTUQ6uXngCGHciC6cRf3Bzo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jo4OCXgvl/BQ7BJOXF5DXYT6zlEa2qDgmxAsIXGSpCVmxZntk74ApehhMuaQL3YxG JXW0gkpSvaN8RmJU5SXXTxEArQ2/5IYGdnk9VXef9dBcBPAqCYwubmUyXakw/TvdHz rM9iFvgJLlpR5okk3WebwmxT4ovw+kYj6OXO1E1K1gEG9szI760RK3qM+U+hKnmldE 0g269tXpWdooaeWPww7zP1LTuA4ZTc89BAvVgeFwpIi69GOxpXsBtyYn1VAiEB0LfJ Dd/hr1ImNBI2t+sHSvXNM0Oaj/gTOVzjMrXu7rceWegxd56Ei+5B69nRv9r1Pll1xf T/x8CqCFGZKYA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/SHZgr_SoKhuS4zeiZqNvmFb9S00 Subject: Re: [clue] Maxcaptures in MCC, vs. switched and composed attributes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 19:15:55 -0000 On 2/9/14 8:15 PM, Christian Groves wrote: > Hello > > I don't think removal of MaxCaptures is an option. I gave an example to > Paul why its needed. It was buried deep in an email thread so i'll > repeat it here: We are all still trying to figure this out. Maybe it will be easier when we are all in one place. > I see there is benefit in giving the Advertiser and the Consumer the > means of knowing how many captures will appear in the stream at a time. > It gives the ability for the Consumer to distinguish between MCCs. An admirable goal. > For example: > What if the Advertiser combines two sources set but switches the > sources? i.e. > MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=2 > Are both the "switched" and "composed" attributes valid? > MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Switched,Composed I think so. > How about the case where the Advertiser composes 4 sources into a media > stream switches those sources? > MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=4 > Using the composed and switched attributes: > MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Switched,Composed > > Now how does a consumer distinguish between MCC1, MCC2 in this case? I > think its a valid decision for a Consumer to make it determine how many > sources it wants to see at a particular time. It can't use the spatial > information because we've disallowed that. I don't think the "switched" > and "composed" attributes can model that. When you use "maxcaptures=" this makes sense to me. When you use "maxcaptures<=" then it gets harder. Certainly it is *possible* that the advertisement would use "maxcaptures<=4" but in reality never compose more than two. (It seems silly to do that, but how do we write a definition that calls for sensible behavior?) A problem with "maxcaptures=" is that it can be rendered invalid by the consumer based on what it configures. E.g., for an advertisement containing: MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=4 The configure might have: MCC2(VC1, VC2, VC3) Then it is impossible for the advertiser to include 4 captures. At least *this* can probably be addressed using careful wording - that the "maxcaptures=" will be honored if the number of sources configured allows it to be. Thanks, Paul > Regards, Christian > > > On 8/02/2014 3:26 AM, Duckworth, Mark wrote: >> I'm trying to summarize a couple of related proposals here. >> 1. Add ability for advertiser to indicate if the number of captures in >> an MCC at any given time will always be equal to MaxCaptures, or if it >> can be less. Details below from Christian. >> 2. Add Switched and Composed attributes to MCC, just like we used to >> have for all captures. This is proposed in >> draft-ietf-clue-data-model-schema-03. Maybe remove the MaxCaptures >> attribute if we add switched and composed. >> >> We can do one or the other, or both, or neither. Any of those choices >> is okay with me, I personally have no strong argument either way. I >> think others in the group have stronger preferences. I think the >> default is to do neither, unless there is consensus to change. Please >> continue the discussion so we can figure out if any change is needed >> in the framework and data model. >> >> Regards, >> Mark >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >>> Sent: Thursday, February 06, 2014 11:50 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] Maxcaptures in MCC >>> >>> Hello Mark, >>> >>> To be more concrete here's the text I would propose for the framework: >>> >>> 7.2.1.1. Maximum Number of Captures within a MCC >>> >>> The Maximum Number of Captures MCC attribute indicates the maximum >>> number of individual captures that may appear in a Capture Encoding >>> at a time. <>> the >>> actual >>> number at any given time can be less than >>> this maximum. It may be used to derive how the Single Media >>> Captures within the MCC are composed / switched with regards to >>> space and time. <>> captures >>> is equal >>> to the maximum the Consumer MUST not choose a subset of captures >>> from the MCC in a >>> Configure message.>> >>> >>> Max Captures MAY be set to one so that only content related to one >>> of the sources are shown in the MCC Capture Encoding at a time or >>> it may be set to any value up to the total number of Source Media >>> Captures in the MCC. >>> >>> If this attribute is not set then as default it is assumed that >>> <>> of sources>> >>> can appear concurrently in the Capture Encoding associated with >>> the MCC. >>> >>> For example: The use of MaxCaptures equal to 1 on a MCC with three >>> Video Captures VC1, VC2 and VC3 would indicate that the Advertiser >>> in the capture encoding would switch between VC1, VC2 or VC3 as >>> there may be only a maximum of one capture at a time. >>> >>> Regards, Christian >>> >>> On 7/02/2014 11:45 AM, Christian Groves wrote: >>>> Hello Mark, >>>> >>>> My proposed improvement is to update the MaxCaptures parameter add >>> the >>>> possibility to indicate indicate that the value is "equal to" as well >>>> as allowing the specification as per today "less than or equal to". >>>> >>>> Regards, Christian >>>> >>>> On 7/02/2014 3:55 AM, Duckworth, Mark wrote: >>>>> Hi Christian, >>>>> >>>>> I think I understand the general idea you are getting at, but I don't >>>>> understand specifically what you are proposing as an improvement. >>>>> More comments inline. >>>>> >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>>> Groves >>>>>> Sent: Wednesday, February 05, 2014 7:20 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't >>>>>> describe video locations within composed MCC >>>>>> >>>>>> Hello Paul and Mark, >>>>>> >>>>>> The Max-captures attributes currently indicates the maximum number >>>>>> of captures that appears in a MCC at any particular point in time. >>>>>> >>>>>> i.e. MCC(VC1,VC2,VC3),MaxCaptures=3 >>>>>> So a Consumer has to assume because this is a maximum that VC1, VC2, >>>>>> VC3, (VC1,VC2), (VC1,VC3), (VC2,VC3) or (VC1,VC2,VC3) can appear at >>>>>> any point in time. >>>>> [Duckworth, Mark] I agree, that is consistent with framework-13. >>>>> >>>>>> However the Consumer only ever sends a composition of >>> (VC1,VC2,VC3). >>>>>> It is >>>>>> never going to change that combination. >>>>> [Duckworth, Mark] Do you mean the Provider will always send a >>>>> composition of (VC1,VC2,VC3)? And the provider would like to be more >>>>> explicit about this in the advertisement? >>>>> >>>>>> It seems to me that in this case >>>>>> using MaxCaptures as it is currently defined is semantically >>>>>> incorrect. >>>>> [Duckworth, Mark] I think it is correct, but maybe not giving as much >>>>> information as the provider wants to express. >>>> [CNG] I can't see its correct. If I tell you that I can do a set of >>>> behaviour but I only intend to do one then I don't think that's >>>> truthful. Sort of like telling you I'm coming to your house one day >>>> next week when in fact I only intend on coming on Friday. >>>>>> So what I am suggesting is simply to add a way to correctly indicate >>>>>> this "constant number of captures" case, i.e. (VC1,VC2,VC3). >>>>> [Duckworth, Mark] If I understand your suggestion correctly, then one >>>>> way to do that would be to add a new optional MinCaptures attribute >>>>> to an MCC. MinCaptures is the minimum number of constituent captures >>>>> that may appear in the MCC at a time. If this attribute is not set, >>>>> then it is assumed to have the default value of 1. For this >>>>> scenario, the value of both MinCaptures and MaxCaptures would be 3. >>>>> Is this what you are suggesting, or do you have something else in >>>>> mind? >>>> [CNG] No all I had in mind was something like: >>>> MaxCaptures "="/"<=" value >>>> The Advertiser would chose to indicate "equal" or "equal to or >>>> less than". >>>>>> I think Paul is questioning the attribute in general. I do believe >>>>>> that knowing the number of sources may be beneficial for a consumer >>>>>> in deciding which MCC/Captures to select. There may be tradeoffs vs >>>>>> a MCC only showing a limited number (i.e. one source) at a time vs >>>>>> another MCC showing multiple sources at a time. >>>> [CNG] I agree I think its beneficial. >>>>>> Regards, Christian >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Feb 20 11:28:33 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73A11A0279 for ; Thu, 20 Feb 2014 11:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBnenfXoZNBK for ; Thu, 20 Feb 2014 11:28:29 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 2292F1A0278 for ; Thu, 20 Feb 2014 11:28:29 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta04.westchester.pa.mail.comcast.net with comcast id UgCz1n0041ZXKqc54jURuk; Thu, 20 Feb 2014 19:28:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id UjUR1n0083ZTu2S3hjURH0; Thu, 20 Feb 2014 19:28:25 +0000 Message-ID: <53065759.3000901@alum.mit.edu> Date: Thu, 20 Feb 2014 14:28:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA027@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA027@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392924505; bh=8WFnkFqhH/BJUjLTX2XCk7oxogHTte/5FLL8rcSFVCw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=imgxDxYeMh9CzRRdLU+ZxTZos79DHXv4GPySVHK8aBnNZcJpTb/R9J3dUr1+g/7JN 1OZeWTHBVKRUtvTaTPj0aCw501NOQiOCBvQrtXLM1SgOuW9dufEi5Gci7viYqOx/iy AMvvOpxBrLdABys/U9wZ0HYxKfT5aIG92vJ2z720gk3WOmqX9v2/tw5tWTkSznypk6 uASpSDH9RLaSqL0JS6h2R0id8npQRwk35/SlJ2j1078YmzAtRqjDIksybNi6UzrhUg v+Cn5sR6yK0wqTCRKtssq//gvA619WU8NoaD0nrVxFWWiTGsKn6g2JlqlgfBW+3R8h Mv5WAidQEyJMA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/1akisletJXgmMm8z7Bnr7OiEu3w Subject: Re: [clue] Need to signal "active video capture" information? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 19:28:31 -0000 Speaking as an individual, I would like to see a way to address this. But I'm not (yet anyway) confident that there is a mechanism that would be sufficiently useful and also practical for us to specify. And if not, then I don't want to spend a lot of time flogging it. I would be happy if *somebody* came back with a concrete proposal, with explanation of utility and feasibility. Or with several alternatives and the pros/cons of each. This in enough detail that we could quickly choose, or not. Thanks, Paul On 2/19/14 5:44 PM, Duckworth, Mark wrote: > I had this in a slide from Feb 11 design team, but we didn’t get to it. > > This is an old issue we previously said was important, but haven’t > followed up on it. I think it is still important. > > Old slides from October 2011 interim - > http://trac.tools.ietf.org/wg/clue/trac/raw-attachment/wiki/WikiStart/5-VAD-in-CLUE.ppt > > Summary: > > •Signaling the “active video capture”, not using just audio energy in > the audio stream(s). Discussed at October 2011 interim meeting, we > never followed up on it. “VAD in CLUE” > > •Example: endpoint provider sends 3 video captures, and 1 mono audio > > –Consumer (MCU topo-mixer) wants to know which video has the loudest > talker, so it can send that one to a simple endpoint that just receives > one video stream > > –How does this MCU consumer know which one it is? > > •Provider can signal this somehow, if it knows locally which video is > associated with the talker > > –in RTP? > > –in CLUE channel? > > –provider sends a switched MCC for this, plus the individual captures? > > •This gets back to issue of sending one packet stream that fulfills > multiple encodings at the same time? > > –other way? > > Does the group want to address this issue? > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Feb 20 21:33:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1FE1A0414 for ; Thu, 20 Feb 2014 21:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGPODslYvFDn for ; Thu, 20 Feb 2014 21:33:44 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D191A041C for ; Thu, 20 Feb 2014 21:33:43 -0800 (PST) Received: from ppp118-209-167-95.lns20.mel6.internode.on.net ([118.209.167.95]:55843 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGigZ-0000Ei-2W for clue@ietf.org; Fri, 21 Feb 2014 16:30:07 +1100 Message-ID: <5306E52D.2070406@nteczone.com> Date: Fri, 21 Feb 2014 16:33:33 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D2FB54F@CRPMBOXPRD07.polycom.com> <52F82841.5010001@nteczone.com> <53065464.9060003@alum.mit.edu> In-Reply-To: <53065464.9060003@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/M7n_6rsmt8qsMDKBIff1RvCJF2I Subject: Re: [clue] Maxcaptures in MCC, vs. switched and composed attributes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 05:33:48 -0000 Hello Paul, Please see below. Regards, Christian On 21/02/2014 6:15 AM, Paul Kyzivat wrote: > On 2/9/14 8:15 PM, Christian Groves wrote: >> Hello >> >> I don't think removal of MaxCaptures is an option. I gave an example to >> Paul why its needed. It was buried deep in an email thread so i'll >> repeat it here: > > We are all still trying to figure this out. > Maybe it will be easier when we are all in one place. > >> I see there is benefit in giving the Advertiser and the Consumer the >> means of knowing how many captures will appear in the stream at a time. >> It gives the ability for the Consumer to distinguish between MCCs. > > An admirable goal. > >> For example: >> What if the Advertiser combines two sources set but switches the >> sources? i.e. >> MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=2 >> Are both the "switched" and "composed" attributes valid? >> MCC1(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Switched,Composed > > I think so. > >> How about the case where the Advertiser composes 4 sources into a media >> stream switches those sources? >> MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=4 >> Using the composed and switched attributes: >> MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),Switched,Composed >> >> Now how does a consumer distinguish between MCC1, MCC2 in this case? I >> think its a valid decision for a Consumer to make it determine how many >> sources it wants to see at a particular time. It can't use the spatial >> information because we've disallowed that. I don't think the "switched" >> and "composed" attributes can model that. > > When you use "maxcaptures=" this makes sense to me. > > When you use "maxcaptures<=" then it gets harder. [CNG] I think its applicable even for "MaxCaptures<=" because the maximum number of composed sources changes. > Certainly it is *possible* that the advertisement would use > "maxcaptures<=4" but in reality never compose more than two. (It seems > silly to do that, but how do we write a definition that calls for > sensible behavior?) [CNG] Yes this is the problem. It could advertise "maxcaptures<=4" and never compose more than two but that's not what the consumer would expect. > > A problem with "maxcaptures=" is that it can be rendered invalid by > the consumer based on what it configures. E.g., for an advertisement > containing: > > MCC2(VC1, VC2, VC3, VC4, VC5, VC6, VC7, VC8),MaxCaptures=4 > > The configure might have: > > MCC2(VC1, VC2, VC3) > > Then it is impossible for the advertiser to include 4 captures. > > At least *this* can probably be addressed using careful wording - that > the "maxcaptures=" will be honored if the number of sources configured > allows it to be. [CNG] I agree we need to provide some guidance around this so that a consumer doesn't violate the maxcaptures when it chooses source captures. > > Thanks, > Paul > >> Regards, Christian >> >> >> On 8/02/2014 3:26 AM, Duckworth, Mark wrote: >>> I'm trying to summarize a couple of related proposals here. >>> 1. Add ability for advertiser to indicate if the number of captures in >>> an MCC at any given time will always be equal to MaxCaptures, or if it >>> can be less. Details below from Christian. >>> 2. Add Switched and Composed attributes to MCC, just like we used to >>> have for all captures. This is proposed in >>> draft-ietf-clue-data-model-schema-03. Maybe remove the MaxCaptures >>> attribute if we add switched and composed. >>> >>> We can do one or the other, or both, or neither. Any of those choices >>> is okay with me, I personally have no strong argument either way. I >>> think others in the group have stronger preferences. I think the >>> default is to do neither, unless there is consensus to change. Please >>> continue the discussion so we can figure out if any change is needed >>> in the framework and data model. >>> >>> Regards, >>> Mark >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>> Groves >>>> Sent: Thursday, February 06, 2014 11:50 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Maxcaptures in MCC >>>> >>>> Hello Mark, >>>> >>>> To be more concrete here's the text I would propose for the framework: >>>> >>>> 7.2.1.1. Maximum Number of Captures within a MCC >>>> >>>> The Maximum Number of Captures MCC attribute indicates the >>>> maximum >>>> number of individual captures that may appear in a Capture >>>> Encoding >>>> at a time. <>> the >>>> actual >>>> number at any given time can be less than >>>> this maximum. It may be used to derive how the Single Media >>>> Captures within the MCC are composed / switched with regards to >>>> space and time. <>>> captures >>>> is equal >>>> to the maximum the Consumer MUST not choose a subset of captures >>>> from the MCC in a >>>> Configure message.>> >>>> >>>> Max Captures MAY be set to one so that only content related to >>>> one >>>> of the sources are shown in the MCC Capture Encoding at a time or >>>> it may be set to any value up to the total number of Source Media >>>> Captures in the MCC. >>>> >>>> If this attribute is not set then as default it is assumed that >>>> <>>> of sources>> >>>> can appear concurrently in the Capture Encoding associated with >>>> the MCC. >>>> >>>> For example: The use of MaxCaptures equal to 1 on a MCC with >>>> three >>>> Video Captures VC1, VC2 and VC3 would indicate that the >>>> Advertiser >>>> in the capture encoding would switch between VC1, VC2 or VC3 as >>>> there may be only a maximum of one capture at a time. >>>> >>>> Regards, Christian >>>> >>>> On 7/02/2014 11:45 AM, Christian Groves wrote: >>>>> Hello Mark, >>>>> >>>>> My proposed improvement is to update the MaxCaptures parameter add >>>> the >>>>> possibility to indicate indicate that the value is "equal to" as well >>>>> as allowing the specification as per today "less than or equal to". >>>>> >>>>> Regards, Christian >>>>> >>>>> On 7/02/2014 3:55 AM, Duckworth, Mark wrote: >>>>>> Hi Christian, >>>>>> >>>>>> I think I understand the general idea you are getting at, but I >>>>>> don't >>>>>> understand specifically what you are proposing as an improvement. >>>>>> More comments inline. >>>>>> >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>>>> Groves >>>>>>> Sent: Wednesday, February 05, 2014 7:20 PM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] Now Maxcaptures - Re: spatial information can't >>>>>>> describe video locations within composed MCC >>>>>>> >>>>>>> Hello Paul and Mark, >>>>>>> >>>>>>> The Max-captures attributes currently indicates the maximum number >>>>>>> of captures that appears in a MCC at any particular point in time. >>>>>>> >>>>>>> i.e. MCC(VC1,VC2,VC3),MaxCaptures=3 >>>>>>> So a Consumer has to assume because this is a maximum that VC1, >>>>>>> VC2, >>>>>>> VC3, (VC1,VC2), (VC1,VC3), (VC2,VC3) or (VC1,VC2,VC3) can appear at >>>>>>> any point in time. >>>>>> [Duckworth, Mark] I agree, that is consistent with framework-13. >>>>>> >>>>>>> However the Consumer only ever sends a composition of >>>> (VC1,VC2,VC3). >>>>>>> It is >>>>>>> never going to change that combination. >>>>>> [Duckworth, Mark] Do you mean the Provider will always send a >>>>>> composition of (VC1,VC2,VC3)? And the provider would like to be >>>>>> more >>>>>> explicit about this in the advertisement? >>>>>> >>>>>>> It seems to me that in this case >>>>>>> using MaxCaptures as it is currently defined is semantically >>>>>>> incorrect. >>>>>> [Duckworth, Mark] I think it is correct, but maybe not giving as >>>>>> much >>>>>> information as the provider wants to express. >>>>> [CNG] I can't see its correct. If I tell you that I can do a set of >>>>> behaviour but I only intend to do one then I don't think that's >>>>> truthful. Sort of like telling you I'm coming to your house one day >>>>> next week when in fact I only intend on coming on Friday. >>>>>>> So what I am suggesting is simply to add a way to correctly >>>>>>> indicate >>>>>>> this "constant number of captures" case, i.e. (VC1,VC2,VC3). >>>>>> [Duckworth, Mark] If I understand your suggestion correctly, then >>>>>> one >>>>>> way to do that would be to add a new optional MinCaptures attribute >>>>>> to an MCC. MinCaptures is the minimum number of constituent >>>>>> captures >>>>>> that may appear in the MCC at a time. If this attribute is not set, >>>>>> then it is assumed to have the default value of 1. For this >>>>>> scenario, the value of both MinCaptures and MaxCaptures would be 3. >>>>>> Is this what you are suggesting, or do you have something else in >>>>>> mind? >>>>> [CNG] No all I had in mind was something like: >>>>> MaxCaptures "="/"<=" value >>>>> The Advertiser would chose to indicate "equal" or "equal to or >>>>> less than". >>>>>>> I think Paul is questioning the attribute in general. I do believe >>>>>>> that knowing the number of sources may be beneficial for a consumer >>>>>>> in deciding which MCC/Captures to select. There may be tradeoffs vs >>>>>>> a MCC only showing a limited number (i.e. one source) at a time vs >>>>>>> another MCC showing multiple sources at a time. >>>>> [CNG] I agree I think its beneficial. >>>>>>> Regards, Christian >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Feb 20 21:36:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5491A0413 for ; Thu, 20 Feb 2014 21:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfuQb_iELqfQ for ; Thu, 20 Feb 2014 21:36:52 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991751A041D for ; Thu, 20 Feb 2014 21:36:51 -0800 (PST) Received: from ppp118-209-167-95.lns20.mel6.internode.on.net ([118.209.167.95]:55862 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGijb-0000vI-GE for clue@ietf.org; Fri, 21 Feb 2014 16:33:15 +1100 Message-ID: <5306E5E9.7000400@nteczone.com> Date: Fri, 21 Feb 2014 16:36:41 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA027@CRPMBOXPRD07.polycom.com> <53065759.3000901@alum.mit.edu> In-Reply-To: <53065759.3000901@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/SqfBjNutmS0ZT8m7UXf2Sgck2BM Subject: Re: [clue] Need to signal "active video capture" information? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 05:36:54 -0000 Hello, +1 to Paul's comments. Regards, Christian On 21/02/2014 6:28 AM, Paul Kyzivat wrote: > Speaking as an individual, I would like to see a way to address this. > > But I'm not (yet anyway) confident that there is a mechanism that > would be sufficiently useful and also practical for us to specify. And > if not, then I don't want to spend a lot of time flogging it. > > I would be happy if *somebody* came back with a concrete proposal, > with explanation of utility and feasibility. Or with several > alternatives and the pros/cons of each. This in enough detail that we > could quickly choose, or not. > > Thanks, > Paul > > On 2/19/14 5:44 PM, Duckworth, Mark wrote: >> I had this in a slide from Feb 11 design team, but we didn’t get to it. >> >> This is an old issue we previously said was important, but haven’t >> followed up on it. I think it is still important. >> >> Old slides from October 2011 interim - >> http://trac.tools.ietf.org/wg/clue/trac/raw-attachment/wiki/WikiStart/5-VAD-in-CLUE.ppt >> >> >> Summary: >> >> •Signaling the “active video capture”, not using just audio energy in >> the audio stream(s). Discussed at October 2011 interim meeting, we >> never followed up on it. “VAD in CLUE” >> >> •Example: endpoint provider sends 3 video captures, and 1 mono audio >> >> –Consumer (MCU topo-mixer) wants to know which video has the loudest >> talker, so it can send that one to a simple endpoint that just receives >> one video stream >> >> –How does this MCU consumer know which one it is? >> >> •Provider can signal this somehow, if it knows locally which video is >> associated with the talker >> >> –in RTP? >> >> –in CLUE channel? >> >> –provider sends a switched MCC for this, plus the individual captures? >> >> •This gets back to issue of sending one packet stream that fulfills >> multiple encodings at the same time? >> >> –other way? >> >> Does the group want to address this issue? >> >> Mark >> >> >> >> _______________________________________________ >> 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 nobody Thu Feb 20 22:05:39 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9661A0432 for ; Thu, 20 Feb 2014 22:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeHlP3M9Gfgh for ; Thu, 20 Feb 2014 22:05:36 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12E51A042F for ; Thu, 20 Feb 2014 22:05:35 -0800 (PST) Received: from ppp118-209-167-95.lns20.mel6.internode.on.net ([118.209.167.95]:55983 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WGjBK-0004Ll-UG for clue@ietf.org; Fri, 21 Feb 2014 17:01:55 +1100 Message-ID: <5306EC9E.3030408@nteczone.com> Date: Fri, 21 Feb 2014 17:05:18 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010@CRPMBOXPRD07.polycom.com> <53058C3D.1050107@alum.mit.edu> In-Reply-To: <53058C3D.1050107@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/EAi8qydt7Bf0KisyNpD6Dj2VwFM Subject: Re: [clue] Global Alternative Captures List - How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 06:05:38 -0000 I'd like to see more detail for this, i.e. is it optional/mandatory, can a consumer choose another combination?, at most one CSE from a Scene in a CSEg? As such I'd like to see a complete example Advertisement/Configure and proposed text for the framework. Also if we do add this then I think the CSEid should be explained more in the framework like we do for the CaptureID. Regards, Christian On 20/02/2014 4:01 PM, Paul Kyzivat wrote: > Mark, > > Unsurprisingly, I think this is a good idea. :-) > > Thanks, > Paul > > On 2/19/14 5:28 PM, Duckworth, Mark wrote: >> At the Feb 11 design team meeting we thought this idea from Paul was >> worth considering. Paul wrote (Feb 10): >> >> ================================================ >> >> - Leave existing per-scene CSE lists as-is. >> >> - Add another advertisement-wide CSE list. The entries in it could use >> shorthand, by referencing CSEs from the individual scenes. >> >> E.g., >> >> Scene1 (CSE11, CSE12, CSE13) >> >> Scene2 (CSE21, CSE22) >> >> Scene3 (CSE31) >> >> Scene4 (CSE41) >> >> Global-CSE-List ( >> >> CSEg1(CSE11, CSE21, CSE31) >> >> CSEg2(CSE12, CSE22, CSE31) >> >> CSEg3(CSE13, CSE22, CSE31) >> >> ) >> >> Here the global CSE list has recommended a subset of the possible >> combinations of CSEs from the different scenes, and has omitted Scene4 >> altogether. This is a value judgement of what combinations make sense. >> >> Note that I would still allow the CSEs in the global list to reference >> individual captures if desired. But referencing other CSEs is a >> convenient shorthand. >> >> ================================================ >> >> I included a slide showing a slightly more detailed example for the case >> we have been discussing at previous meetings. Slide 9 of >> http://trac.tools.ietf.org/wg/clue/trac/raw-attachment/wiki/Design-Team/Framework_Issues_140211.pptx >> >> This example gives alternatives for a consumer that wants to receive >> only one capture, all the way up to a consumer that wants nine captures, >> with all possibilities in between. >> >> I think this new proposed list could be called “global alternative >> captures list” rather than a “global CSE list”. Maybe somebody has a >> better suggestion for what to call it? The purpose of the list is for >> the provider to give suggestions to the consumer about which captures to >> choose, considering the entire advertisement. Each entry in the list is >> an alternative. Each entry consists of a set of captures (for >> shorthand, could reference multiple captures at once by referencing a >> CSE instead of individual capture). >> >> For an advertisement with multiple scenes, where each scene can have >> multiple CSEs with different number of captures in each, we have been >> discussing how a consumer can make a good choice between requesting >> captures from fewer scenes with more captures per scene, vs. requesting >> captures from more scenes with fewer captures per scene. The “global >> alternative captures list” gives the provider a way to suggest which >> makes more sense from the provider’s viewpoint. Of course the consumer >> can still take into account all the other information such as priority, >> description, participant information and view attributes. >> >> Does the group support adding this additional list to an advertisement? >> Should I make a specific proposal for text to add to the framework? Or >> do we need more discussion or examples? >> >> Mark >> >> >> >> _______________________________________________ >> 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 nobody Fri Feb 21 07:06:16 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAEF1A01AB for ; Fri, 21 Feb 2014 07:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z2N_MHwCvcd for ; Fri, 21 Feb 2014 07:06:12 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6753D1A0179 for ; Fri, 21 Feb 2014 07:06:12 -0800 (PST) Received: from PWEHUB01.polycom.com (10.236.2.221) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 21 Feb 2014 07:06:08 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 21 Feb 2014 07:06:08 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 21 Feb 2014 07:06:06 -0800 Thread-Topic: contradiction in framework about simultaneous captures in a CSE Thread-Index: Ac8vFMGi8JJGRFoOQI6hSlOO7KhH+Q== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32@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_49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32CRPMBOXPRD07p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/C-xmMB_gvNsuNO5eOVpHMRglrm8 Subject: [clue] contradiction in framework about simultaneous captures in a CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 15:06:14 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When we added MCC to the framework, we introduced a contradiction about the= provider's ability to encode and send all captures in a CSE simultaneously= . >From section 7.3 "The Provider MUST be capable of encoding and sending all Captures in a sin= gle Capture Scene Entry simultaneously." >From section 9.3 "Each Media Capture MAY be associated with at least one Encoding Group" The statement from 7.3 is not correct anymore. Our intent is to allow the = advertisement to include captures without an encoding group, but still incl= ude those captures in a CSE, as in example 12.3.1 Table 13. So having a se= t of captures in a CSE doesn't necessarily mean the provider can encode and= send them. The point of the 7.3 statement is to ensure that encoding limitations and s= imultaneous set limitations do not prevent a provider from sending all capt= ures in a CSE simultaneously, because that would defeat the purpose of a CS= E. But since we now allow captures without encoding groups, it makes sense= to allow CSEs for scenes which the provider has no intention of sending di= rectly at all. Here is a proposal for changing the sentence in 7.3: "If all the Captures in a single Capture Scene Entry have an Encoding Group= , then the Provider MUST be capable of encoding and sending all those Captu= res simultaneously." Is that a good change? Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When we added MC= C to the framework, we introduced a contradiction about the provider’= s ability to encode and send all captures in a CSE simultaneously.

 

From s= ection 7.3

“The Provider MUST be c= apable of encoding and sending all Captures in a single Capture Scene Entry= simultaneously.”

 

From section 9.3

“Each Media Capture MAY be associated with at least one Encoding G= roup”

 

The statement from 7.3 is not correct anymore.  Our inte= nt is to allow the advertisement to include captures without an encoding gr= oup, but still include those captures in a CSE, as in example 12.3.1 Table = 13.  So having a set of captures in a CSE doesn’t necessarily me= an the provider can encode and send them.

 

The point of the 7.3 statement = is to ensure that encoding limitations and simultaneous set limitations do = not prevent a provider from sending all captures in a CSE simultaneously, b= ecause that would defeat the purpose of a CSE.  But since we now allow= captures without encoding groups, it makes sense to allow CSEs for scenes = which the provider has no intention of sending directly at all.<= /p>

 

Here is a= proposal for changing the sentence in 7.3:

“If all the Captures in a single Capture Scene Entry have an Enco= ding Group, then the Provider MUST be capable of encoding and sending all t= hose Captures simultaneously.”

 

Is that a good change?

 

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32CRPMBOXPRD07p_-- From nobody Fri Feb 21 07:47:34 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2591A0421 for ; Fri, 21 Feb 2014 07:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyQEQuNRH_5r for ; Fri, 21 Feb 2014 07:47:29 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 705851A031C for ; Fri, 21 Feb 2014 07:47:29 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta04.westchester.pa.mail.comcast.net with comcast id V0mW1n0031ap0As543nRst; Fri, 21 Feb 2014 15:47:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id V3nR1n0013ZTu2S3i3nRBZ; Fri, 21 Feb 2014 15:47:25 +0000 Message-ID: <5307750C.3070207@alum.mit.edu> Date: Fri, 21 Feb 2014 10:47:24 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010@CRPMBOXPRD07.polycom.com> <53058C3D.1050107@alum.mit.edu> <5306EC9E.3030408@nteczone.com> In-Reply-To: <5306EC9E.3030408@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392997645; bh=6tqlpsBIrKvheq+nqZSTaBQY9fhor1yciUGoL+MhbqE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=a56nyVWn6KhSeou5+JmEjGMCJBY8qUo1BMebEwXmAJ/e3/TJ57BBRa3YND2yrX7Us eXEE0IwivUSzbi6hWGgDt2W/Li5oI3wV3Gi04thuSLWE+pq9qw4b/TIqDI05Poo7Cs mNqkMm/1RFB0do2p8QJ4SNO3LR2QndE77BLVSs2C69ikkSDs6IFbCkm07CuHk6sUv+ LzIoSsu5kRj5TnDAACCgvQGR+Ab+feRszplmWQSviVgPetF7yG3tMe7yFZdaqNw1dO NUoKVrGzJCQJWOUtDZB9dyoAbrnx0dxgi6maREJcU6wJIZ/f1aAjEgPdTQwWqBD7W5 VtI2iO9ia8lHw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/KYEXoRKyFQkgjFI40If7IohNp1Q Subject: Re: [clue] Global Alternative Captures List - How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 15:47:32 -0000 On 2/21/14 1:05 AM, Christian Groves wrote: > I'd like to see more detail for this, i.e. is it optional/mandatory, can > a consumer choose another combination?, at most one CSE from a Scene in > a CSEg? This is all subject to debate. *My* thinking is: - the entire global CSE list is optional. (And the per-scene CSE lists should also be optional.) - each entry in the global CSE list identifies a set of captures in the advertisement that is intended to provide a recommended valid rendition of the entire advertisement. It can reference each of the individual captures it it wishes. Or it can use "shorthand", by referencing other CSEs defined in the advertisement. Or a mixture of individual captures and CSEs. - (Note that the shorthand here is probably the same as the shorthand that can be used to define the components of an MCC. But the restrictions on what can be referenced are different.) - We would have to specify what to do if a global CSE references the same capture more than once. (As might happen if it referenced multiple CSEs that contain the same capture.) The obvious answer is to just take each one once. (I think we have discussed this before.) - It now occurs to me that we might also want to allow the definition of global MCCs. (I haven't thought through the implications of this.) > As such I'd like to see a complete example > Advertisement/Configure and proposed text for the framework. Mark already made one. > Also if we > do add this then I think the CSEid should be explained more in the > framework like we do for the CaptureID. Maybe. But perhaps we don't need to discuss referencing CSEs in the framework at all. We could just define it in the fw in terms of individual captures. The shorthand of referencing whole CSEs could then be limited to the data model. It is just another alternative, like using REs, to reference groups of captures. (We might simply have the fw mention that the syntax of advertisement messages may include a variety of ways to simply referencing of multiple captures.) Thanks, Paul > Regards, Christian > > On 20/02/2014 4:01 PM, Paul Kyzivat wrote: >> Mark, >> >> Unsurprisingly, I think this is a good idea. :-) >> >> Thanks, >> Paul >> >> On 2/19/14 5:28 PM, Duckworth, Mark wrote: >>> At the Feb 11 design team meeting we thought this idea from Paul was >>> worth considering. Paul wrote (Feb 10): >>> >>> ================================================ >>> >>> - Leave existing per-scene CSE lists as-is. >>> >>> - Add another advertisement-wide CSE list. The entries in it could use >>> shorthand, by referencing CSEs from the individual scenes. >>> >>> E.g., >>> >>> Scene1 (CSE11, CSE12, CSE13) >>> >>> Scene2 (CSE21, CSE22) >>> >>> Scene3 (CSE31) >>> >>> Scene4 (CSE41) >>> >>> Global-CSE-List ( >>> >>> CSEg1(CSE11, CSE21, CSE31) >>> >>> CSEg2(CSE12, CSE22, CSE31) >>> >>> CSEg3(CSE13, CSE22, CSE31) >>> >>> ) >>> >>> Here the global CSE list has recommended a subset of the possible >>> combinations of CSEs from the different scenes, and has omitted Scene4 >>> altogether. This is a value judgement of what combinations make sense. >>> >>> Note that I would still allow the CSEs in the global list to reference >>> individual captures if desired. But referencing other CSEs is a >>> convenient shorthand. >>> >>> ================================================ >>> >>> I included a slide showing a slightly more detailed example for the case >>> we have been discussing at previous meetings. Slide 9 of >>> http://trac.tools.ietf.org/wg/clue/trac/raw-attachment/wiki/Design-Team/Framework_Issues_140211.pptx >>> >>> This example gives alternatives for a consumer that wants to receive >>> only one capture, all the way up to a consumer that wants nine captures, >>> with all possibilities in between. >>> >>> I think this new proposed list could be called “global alternative >>> captures list” rather than a “global CSE list”. Maybe somebody has a >>> better suggestion for what to call it? The purpose of the list is for >>> the provider to give suggestions to the consumer about which captures to >>> choose, considering the entire advertisement. Each entry in the list is >>> an alternative. Each entry consists of a set of captures (for >>> shorthand, could reference multiple captures at once by referencing a >>> CSE instead of individual capture). >>> >>> For an advertisement with multiple scenes, where each scene can have >>> multiple CSEs with different number of captures in each, we have been >>> discussing how a consumer can make a good choice between requesting >>> captures from fewer scenes with more captures per scene, vs. requesting >>> captures from more scenes with fewer captures per scene. The “global >>> alternative captures list” gives the provider a way to suggest which >>> makes more sense from the provider’s viewpoint. Of course the consumer >>> can still take into account all the other information such as priority, >>> description, participant information and view attributes. >>> >>> Does the group support adding this additional list to an advertisement? >>> Should I make a specific proposal for text to add to the framework? Or >>> do we need more discussion or examples? >>> >>> Mark >>> >>> >>> >>> _______________________________________________ >>> 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 nobody Fri Feb 21 07:59:21 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9A11A03C8 for ; Fri, 21 Feb 2014 07:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjL12Y6jwPNK for ; Fri, 21 Feb 2014 07:59:17 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6439F1A01B9 for ; Fri, 21 Feb 2014 07:59:17 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 21 Feb 2014 07:59:13 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 21 Feb 2014 07:59:11 -0800 Thread-Topic: [clue] Global Alternative Captures List - How to choose from multiple scenes Thread-Index: Ac8uyvD/Db0vrUTCQBGcaH2kOU9mhwAQ0odQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA89@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010@CRPMBOXPRD07.polycom.com> <53058C3D.1050107@alum.mit.edu> <5306EC9E.3030408@nteczone.com> In-Reply-To: <5306EC9E.3030408@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 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ECA-dNP-JeYGYUr9H-ZlIpXjetc Subject: Re: [clue] Global Alternative Captures List - How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 15:59:20 -0000 Here is a bit more detail for a proposal: - Call it a list of "Global Capture Entries" (GCE) - An advertisement may include an optional list of GCEs - A GCE references a set of media captures of a particular media type. The= referenced captures can be from any capture scene in the advertisement. - The set of captures included in a GCE are a suggestion from the provider = as to which captures would be a good choice for the consumer to request, to= represent a good view of the entire advertisement - The list of GCEs may include any number of GCEs - the order of GCEs within the list has no importance - each GCE may include any number of captures - the order of captures within a GCE has no importance - The Provider MUST be capable of encoding and sending all Captures in a si= ngle Global Capture Entry simultaneously - a GCE is similar to a CSE, but a GCE is not associated with a particular = capture scene - The Media Consumer can choose to receive all Media Captures from one Glob= al Capture Entry for each media type (e.g. audio and video), or it can pick= and choose Media Captures regardless of how the Provider arranges them in = Global Capture Entries. In other words, the CSE lists and GCE list are sug= gestions from the provider to consumer. A consumer may choose, in a config= ure message, to request any media captures regardless of how the captures a= re listed in CSEs and GCEs. I think this is all consistent with what Paul just wrote. I am in favor of keeping the syntax related detail in the data model, such = as exactly how to reference captures from a GCE or MCC. I will add a more complete example to the framework presentation for IETF89= , adding to what we had already from the Feb 11 design team meeting. I'll = ask Paul and Mary to post it so you can review it before the meeting. I wi= ll be on vacation all next week and will not be active on this email list n= ext week. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Friday, February 21, 2014 1:05 AM > To: clue@ietf.org > Subject: Re: [clue] Global Alternative Captures List - How to choose from > multiple scenes >=20 > I'd like to see more detail for this, i.e. is it optional/mandatory, can = a > consumer choose another combination?, at most one CSE from a Scene in a > CSEg? As such I'd like to see a complete example Advertisement/Configure > and proposed text for the framework. Also if we do add this then I think = the > CSEid should be explained more in the framework like we do for the > CaptureID. >=20 > Regards, Christian >=20 > On 20/02/2014 4:01 PM, Paul Kyzivat wrote: > > Mark, > > > > Unsurprisingly, I think this is a good idea. :-) > > > > Thanks, > > Paul > > > > On 2/19/14 5:28 PM, Duckworth, Mark wrote: > >> At the Feb 11 design team meeting we thought this idea from Paul was > >> worth considering. Paul wrote (Feb 10): > >> > >> =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=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> - Leave existing per-scene CSE lists as-is. > >> > >> - Add another advertisement-wide CSE list. The entries in it could > >> use shorthand, by referencing CSEs from the individual scenes. > >> > >> E.g., > >> > >> Scene1 (CSE11, CSE12, CSE13) > >> > >> Scene2 (CSE21, CSE22) > >> > >> Scene3 (CSE31) > >> > >> Scene4 (CSE41) > >> > >> Global-CSE-List ( > >> > >> CSEg1(CSE11, CSE21, CSE31) > >> > >> CSEg2(CSE12, CSE22, CSE31) > >> > >> CSEg3(CSE13, CSE22, CSE31) > >> > >> ) > >> > >> Here the global CSE list has recommended a subset of the possible > >> combinations of CSEs from the different scenes, and has omitted > >> Scene4 altogether. This is a value judgement of what combinations make > sense. > >> > >> Note that I would still allow the CSEs in the global list to > >> reference individual captures if desired. But referencing other CSEs > >> is a convenient shorthand. > >> > >> =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=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> I included a slide showing a slightly more detailed example for the > >> case we have been discussing at previous meetings. Slide 9 of > >> http://trac.tools.ietf.org/wg/clue/trac/raw-attachment/wiki/Design-Te > >> am/Framework_Issues_140211.pptx > >> > >> This example gives alternatives for a consumer that wants to receive > >> only one capture, all the way up to a consumer that wants nine > >> captures, with all possibilities in between. > >> > >> I think this new proposed list could be called "global alternative > >> captures list" rather than a "global CSE list". Maybe somebody has a > >> better suggestion for what to call it? The purpose of the list is > >> for the provider to give suggestions to the consumer about which > >> captures to choose, considering the entire advertisement. Each entry > >> in the list is an alternative. Each entry consists of a set of > >> captures (for shorthand, could reference multiple captures at once by > >> referencing a CSE instead of individual capture). > >> > >> For an advertisement with multiple scenes, where each scene can have > >> multiple CSEs with different number of captures in each, we have been > >> discussing how a consumer can make a good choice between requesting > >> captures from fewer scenes with more captures per scene, vs. > >> requesting captures from more scenes with fewer captures per scene. > >> The "global alternative captures list" gives the provider a way to > >> suggest which makes more sense from the provider's viewpoint. Of > >> course the consumer can still take into account all the other > >> information such as priority, description, participant information and= view > attributes. > >> > >> Does the group support adding this additional list to an advertisement= ? > >> Should I make a specific proposal for text to add to the framework? > >> Or do we need more discussion or examples? > >> > >> Mark > >> > >> > >> > >> _______________________________________________ > >> 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 nobody Fri Feb 21 08:55:04 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F531A01F4 for ; Fri, 21 Feb 2014 08:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZi8h98-_l3D for ; Fri, 21 Feb 2014 08:55:02 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id EEB9D1A0208 for ; Fri, 21 Feb 2014 08:55:01 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta06.westchester.pa.mail.comcast.net with comcast id V3Ks1n0060EZKEL564ux21; Fri, 21 Feb 2014 16:54:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id V4ux1n00A3ZTu2S3M4uxl0; Fri, 21 Feb 2014 16:54:57 +0000 Message-ID: <530784E1.7020100@alum.mit.edu> Date: Fri, 21 Feb 2014 11:54:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393001697; bh=r4WgsUEzfpxNgExr9stv1jE58rrDI8A9NiST7YkGZuY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YICS+hv3bbxFSKCej4rPVkGfFPzbM+of3bJAsQjRQkxdErKwDgS6ZcmzzV1cc2YW4 VC2bfQ7GuLqRGUUEzyxWAuw0GtLKd5TYv+1r/Q7CwihEgK1iOE9QirNyNlhX1Zm7vf n9RaOFkyRHW7PKsgz1fzlXBjJu0jp6QWOBQHKcDeZDhyvgKHt9BK4MEkfqVmtA+0PP 3djxfjNzV7yE56Ipvq1bNJQZptv/0JpZKAyjVv2EjfFxT7bvyJqpe7ptNjIlpfWz+7 B/rN3ikzMAeyvHMwm5MyB7R/hJpxbBt+6M/VntBYsPnuJCZVu9HqFgWXVOBURbVfHZ jL172C0Mqt/Uw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Fiml73NHTPbrUWFQ-S0qjQ8kaqg Subject: Re: [clue] contradiction in framework about simultaneous captures in a CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 16:55:03 -0000 On 2/21/14 10:06 AM, Duckworth, Mark wrote: > Here is a proposal for changing the sentence in 7.3: > > “If all the Captures in a single Capture Scene Entry have an Encoding > Group, then the Provider MUST be capable of encoding and sending all > those Captures simultaneously.” > > Is that a good change? The above implies that if some but not all captures in a CSE have encoding groups, then there is no requirement for the provider to be able to send them simultaneously. Does it make sense to define a CSE containing captures without encoding groups? Is there any reason to do so? ISTM that we could instead say that a CSE MUST NOT reference a capture that has no encoding group. Then 7.3 would be ok as it is. Thanks, Paul From nobody Fri Feb 21 09:03:14 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA671A0443 for ; Fri, 21 Feb 2014 09:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmFqnmasbg47 for ; Fri, 21 Feb 2014 09:03:09 -0800 (PST) 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 86B211A021F for ; Fri, 21 Feb 2014 09:03:09 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta10.westchester.pa.mail.comcast.net with comcast id V1LJ1n0060QuhwU5A5357F; Fri, 21 Feb 2014 17:03:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id V5351n00M3ZTu2S3N535B7; Fri, 21 Feb 2014 17:03:05 +0000 Message-ID: <530786C9.70202@alum.mit.edu> Date: Fri, 21 Feb 2014 12:03:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010@CRPMBOXPRD07.polycom.com> <53058C3D.1050107@alum.mit.edu> <5306EC9E.3030408@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA89@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA89@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393002185; bh=IZlVfE+oXAglMgKms2lWg6jAqPpWhkcX0mPBI3oYDuU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Cv6O4cUWCblTZMhJqAIKtY22/snTb8dctFltj7gpSWvs94+qRHJahk4R8Cuv6xDMO vlyduB3D/6Q9fc+TOg8qgtwm/9x3hGNinnnf7olTeeGid33tJqyIIkAedshX4aR7PY QvDEaQtsYKoUsHF3TgQlE/P3dXeviLHHjJuu4e7rLgFTW25Edvhv1kBBVjUQZvKjZ5 DR06+ypYAUchw9PXz2UeILWXC7JAHYjsNQSMdDnDMyAtujvHTv8nWpLiwR09UFkaj2 qPts9WnxQSrhCPdrsAhNq9RcoYFHzI2y64ewq7q4sYMvkFszhav+8Q/WG1DYpB/Bin KFj6AC2FyegDA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ATZf7zgM0SzU0W1jZzlMg7NZ0_4 Subject: Re: [clue] Global Alternative Captures List - How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 17:03:11 -0000 On 2/21/14 10:59 AM, Duckworth, Mark wrote: > Here is a bit more detail for a proposal: > - Call it a list of "Global Capture Entries" (GCE) How about GCSE (Global Capture Set Entry), so the relationship to CSE is clear? > - An advertisement may include an optional list of GCEs > - A GCE references a set of media captures of a particular media type. The referenced captures can be from any capture scene in the advertisement. > - The set of captures included in a GCE are a suggestion from the provider as to which captures would be a good choice for the consumer to request, to represent a good view of the entire advertisement > - The list of GCEs may include any number of GCEs > - the order of GCEs within the list has no importance > - each GCE may include any number of captures > - the order of captures within a GCE has no importance > - The Provider MUST be capable of encoding and sending all Captures in a single Global Capture Entry simultaneously > - a GCE is similar to a CSE, but a GCE is not associated with a particular capture scene > - The Media Consumer can choose to receive all Media Captures from one Global Capture Entry for each media type (e.g. audio and video), or it can pick and choose Media Captures regardless of how the Provider arranges them in Global Capture Entries. In other words, the CSE lists and GCE list are suggestions from the provider to consumer. A consumer may choose, in a configure message, to request any media captures regardless of how the captures are listed in CSEs and GCEs. > > I think this is all consistent with what Paul just wrote. > I am in favor of keeping the syntax related detail in the data model, such as exactly how to reference captures from a GCE or MCC. > > I will add a more complete example to the framework presentation for IETF89, adding to what we had already from the Feb 11 design team meeting. I'll ask Paul and Mary to post it so you can review it before the meeting. I will be on vacation all next week and will not be active on this email list next week. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Friday, February 21, 2014 1:05 AM >> To: clue@ietf.org >> Subject: Re: [clue] Global Alternative Captures List - How to choose from >> multiple scenes >> >> I'd like to see more detail for this, i.e. is it optional/mandatory, can a >> consumer choose another combination?, at most one CSE from a Scene in a >> CSEg? As such I'd like to see a complete example Advertisement/Configure >> and proposed text for the framework. Also if we do add this then I think the >> CSEid should be explained more in the framework like we do for the >> CaptureID. >> >> Regards, Christian >> >> On 20/02/2014 4:01 PM, Paul Kyzivat wrote: >>> Mark, >>> >>> Unsurprisingly, I think this is a good idea. :-) >>> >>> Thanks, >>> Paul >>> >>> On 2/19/14 5:28 PM, Duckworth, Mark wrote: >>>> At the Feb 11 design team meeting we thought this idea from Paul was >>>> worth considering. Paul wrote (Feb 10): >>>> >>>> ================================================ >>>> >>>> - Leave existing per-scene CSE lists as-is. >>>> >>>> - Add another advertisement-wide CSE list. The entries in it could >>>> use shorthand, by referencing CSEs from the individual scenes. >>>> >>>> E.g., >>>> >>>> Scene1 (CSE11, CSE12, CSE13) >>>> >>>> Scene2 (CSE21, CSE22) >>>> >>>> Scene3 (CSE31) >>>> >>>> Scene4 (CSE41) >>>> >>>> Global-CSE-List ( >>>> >>>> CSEg1(CSE11, CSE21, CSE31) >>>> >>>> CSEg2(CSE12, CSE22, CSE31) >>>> >>>> CSEg3(CSE13, CSE22, CSE31) >>>> >>>> ) >>>> >>>> Here the global CSE list has recommended a subset of the possible >>>> combinations of CSEs from the different scenes, and has omitted >>>> Scene4 altogether. This is a value judgement of what combinations make >> sense. >>>> >>>> Note that I would still allow the CSEs in the global list to >>>> reference individual captures if desired. But referencing other CSEs >>>> is a convenient shorthand. >>>> >>>> ================================================ >>>> >>>> I included a slide showing a slightly more detailed example for the >>>> case we have been discussing at previous meetings. Slide 9 of >>>> http://trac.tools.ietf.org/wg/clue/trac/raw-attachment/wiki/Design-Te >>>> am/Framework_Issues_140211.pptx >>>> >>>> This example gives alternatives for a consumer that wants to receive >>>> only one capture, all the way up to a consumer that wants nine >>>> captures, with all possibilities in between. >>>> >>>> I think this new proposed list could be called "global alternative >>>> captures list" rather than a "global CSE list". Maybe somebody has a >>>> better suggestion for what to call it? The purpose of the list is >>>> for the provider to give suggestions to the consumer about which >>>> captures to choose, considering the entire advertisement. Each entry >>>> in the list is an alternative. Each entry consists of a set of >>>> captures (for shorthand, could reference multiple captures at once by >>>> referencing a CSE instead of individual capture). >>>> >>>> For an advertisement with multiple scenes, where each scene can have >>>> multiple CSEs with different number of captures in each, we have been >>>> discussing how a consumer can make a good choice between requesting >>>> captures from fewer scenes with more captures per scene, vs. >>>> requesting captures from more scenes with fewer captures per scene. >>>> The "global alternative captures list" gives the provider a way to >>>> suggest which makes more sense from the provider's viewpoint. Of >>>> course the consumer can still take into account all the other >>>> information such as priority, description, participant information and view >> attributes. >>>> >>>> Does the group support adding this additional list to an advertisement? >>>> Should I make a specific proposal for text to add to the framework? >>>> Or do we need more discussion or examples? >>>> >>>> Mark >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 nobody Fri Feb 21 09:11:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3BD1A047E for ; Fri, 21 Feb 2014 09:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VXOhY88H2rv for ; Fri, 21 Feb 2014 09:11:52 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 251661A02D0 for ; Fri, 21 Feb 2014 09:11:52 -0800 (PST) Received: from PWEHUB01.polycom.com (10.236.2.221) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 21 Feb 2014 09:11:48 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 21 Feb 2014 09:11:47 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 21 Feb 2014 09:11:46 -0800 Thread-Topic: [clue] Need to signal "active video capture" information? Thread-Index: Ac8uxu9VRQ9v4iAVTUewvlWBSluxewAXNJZA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB21@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA027@CRPMBOXPRD07.polycom.com> <53065759.3000901@alum.mit.edu> <5306E5E9.7000400@nteczone.com> In-Reply-To: <5306E5E9.7000400@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 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/lLP0XRmZPTgQw2-ZxbPUroa2UeI Subject: Re: [clue] Need to signal "active video capture" information? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 17:11:54 -0000 Here is a high level suggestion for how this could be done, using (mostly) = existing CLUE mechanisms. I think if we eventually have a solution for the= Media-9 requirement from draft-ietf-clue-rtp-mapping, then it would work w= ell. It could even work without Media-9, but with extra overhead of sendin= g duplicate packet streams. Scenario - multipoint conference, with middlebox MCU, including some endpoi= nts with multiple cameras, some endpoints receiving multiple video streams,= some endpoints receiving only single video stream. When a multi-camera en= dpoint is the active talker, the multi stream receivers want to receive vid= eo from all the talker's cameras, but the single stream receiver wants to r= eceive video from only the camera with the active talker. - The multi camera endpoint provider can offer multiple video CSEs, one wit= h all the camera captures, and one with a single switched MCC representing = the active talker. - The MCU consumer receives all these captures. - The MCU consumer now has all the information it needs, in order to provid= e captures to other multi-stream receivers, and to the single stream receiv= ers Example advertisement from multi camera endpoint: VC1 left VC2 center VC3 right AC1 mono audio MCC1(VC1,VC2,VC3) maxCaptures=3D1; policy=3Dsoundlevel:0 CSE1(VC1,VC2,VC3) CSE2(AC1) CSE3(MCC1) >From draft-ietf-clue-rtp-mapping-01: Media-9: If a given source is being sent on the same transport flow for more than one reason (e.g. if it corresponds to more than one switched capture at once, or to a static capture), it should be possible for a sender to send only one copy of the source. This seems like a clear case where we would want to use this Media-9 requir= ement so the provider can send just one copy of an encoding for each of VC1= , VC2, and VC3 and somehow indicate which one of those is fulfilling MCC1 a= t any point in time. This also seems to imply there should be a way for th= e provider to advertise only three possible encodings, yet still allow the = consumer to request all four captures. I don't think we have a way to do t= hat yet. Another possibility is the provider could offer enough encodings so the MCU= could request a separate distinct encoding for MCC1, for example requestin= g VC1, VC2, and VC3 at 1080p while requesting MCC1 at 720p. This case woul= d not require a solution to Media-9. Any comments? Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Friday, February 21, 2014 12:37 AM > To: clue@ietf.org > Subject: Re: [clue] Need to signal "active video capture" information? >=20 > Hello, >=20 > +1 to Paul's comments. >=20 > Regards, > Christian >=20 > On 21/02/2014 6:28 AM, Paul Kyzivat wrote: > > Speaking as an individual, I would like to see a way to address this. > > > > But I'm not (yet anyway) confident that there is a mechanism that > > would be sufficiently useful and also practical for us to specify. And > > if not, then I don't want to spend a lot of time flogging it. > > > > I would be happy if *somebody* came back with a concrete proposal, > > with explanation of utility and feasibility. Or with several > > alternatives and the pros/cons of each. This in enough detail that we > > could quickly choose, or not. > > > > Thanks, > > Paul > > > > On 2/19/14 5:44 PM, Duckworth, Mark wrote: > >> I had this in a slide from Feb 11 design team, but we didn't get to it= . > >> > >> This is an old issue we previously said was important, but haven't > >> followed up on it. I think it is still important. > >> > >> Old slides from October 2011 interim - > >> http://trac.tools.ietf.org/wg/clue/trac/raw-attachment/wiki/WikiStart > >> /5-VAD-in-CLUE.ppt > >> > >> > >> Summary: > >> > >> *Signaling the "active video capture", not using just audio energy in > >> the audio stream(s). Discussed at October 2011 interim meeting, we > >> never followed up on it. "VAD in CLUE" > >> > >> *Example: endpoint provider sends 3 video captures, and 1 mono audio > >> > >> -Consumer (MCU topo-mixer) wants to know which video has the > loudest > >> talker, so it can send that one to a simple endpoint that just > >> receives one video stream > >> > >> -How does this MCU consumer know which one it is? > >> > >> *Provider can signal this somehow, if it knows locally which video is > >> associated with the talker > >> > >> -in RTP? > >> > >> -in CLUE channel? > >> > >> -provider sends a switched MCC for this, plus the individual captures? > >> > >> *This gets back to issue of sending one packet stream that fulfills > >> multiple encodings at the same time? > >> > >> -other way? > >> > >> Does the group want to address this issue? > >> > >> Mark > >> > >> > >> > >> _______________________________________________ > >> 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 nobody Fri Feb 21 09:20:45 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDB51A0217 for ; Fri, 21 Feb 2014 09:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r37kzyev6QDZ for ; Fri, 21 Feb 2014 09:20:41 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id F08541A01ED for ; Fri, 21 Feb 2014 09:20:40 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Fri, 21 Feb 2014 09:20:37 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 21 Feb 2014 09:20:36 -0800 Thread-Topic: [clue] contradiction in framework about simultaneous captures in a CSE Thread-Index: Ac8vJaoO4m8uYs2NSJ27cD1HHTMi2QAAt92g Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB2A@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32@CRPMBOXPRD07.polycom.com> <530784E1.7020100@alum.mit.edu> In-Reply-To: <530784E1.7020100@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 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/DvfhXB0CfbCM2xs3pQD3JsBGGPc Subject: Re: [clue] contradiction in framework about simultaneous captures in a CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 17:20:43 -0000 Hi Paul, I thought of that possibility also. But I think our intent was for the pro= vider to be able to advertise the complete scene information for original s= ources, including CSEs, even if the provider didn't include encoding groups= for those captures. I think it is useful to include the CSEs for captures= without encoding groups, because the consumer can use this information for= choosing captures, or choosing subsets within MCCs. Another possibility is to say either all captures in a CSE must include an = encoding group, or none of the captures in a CSE can include an encoding gr= oup. I can't think of a case that makes sense to include a mixture. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, February 21, 2014 11:55 AM > To: clue@ietf.org > Subject: Re: [clue] contradiction in framework about simultaneous capture= s > in a CSE >=20 > On 2/21/14 10:06 AM, Duckworth, Mark wrote: >=20 > > Here is a proposal for changing the sentence in 7.3: > > > > "If all the Captures in a single Capture Scene Entry have an Encoding > > Group, then the Provider MUST be capable of encoding and sending all > > those Captures simultaneously." > > > > Is that a good change? >=20 > The above implies that if some but not all captures in a CSE have encodin= g > groups, then there is no requirement for the provider to be able to send > them simultaneously. >=20 > Does it make sense to define a CSE containing captures without encoding > groups? >=20 > Is there any reason to do so? >=20 > ISTM that we could instead say that a CSE MUST NOT reference a capture > that has no encoding group. Then 7.3 would be ok as it is. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Feb 21 09:39:42 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27C61A01E4 for ; Fri, 21 Feb 2014 09:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKGau-tYZgJg for ; Fri, 21 Feb 2014 09:39:39 -0800 (PST) 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 09A011A021C for ; Fri, 21 Feb 2014 09:39:38 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta10.westchester.pa.mail.comcast.net with comcast id V2J11n0070vyq2s5A5fbeF; Fri, 21 Feb 2014 17:39:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id V5fa1n00o3ZTu2S3R5faab; Fri, 21 Feb 2014 17:39:35 +0000 Message-ID: <53078F56.20804@alum.mit.edu> Date: Fri, 21 Feb 2014 12:39:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32@CRPMBOXPRD07.polycom.com> <530784E1.7020100@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB2A@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB2A@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393004375; bh=iKz2DqJak9oRVxLenMb9LxYu9rVEoQhp2eVsXGMdQXw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=K3sfEMzj5gCcYbURJMeODWTITcK+XygLtG4ZRP0SYjghyZmGN3nNmYGh6mglArWFa zrGq45ECUVq4xREiGjXSUBucplFgLOYh1oKNMonMD44fDDJIex6UxmLMEmwrqq2OA0 2Yu5rqFnXaE/ltRw6AJlAkmowZ7w0U60V0Jb0T71ir0gY0wPSR+itjTh5/A3gih+Uk eRyGvlX6A3MnwFa2bzrJm8mg4vRvemi+CtHQdN1kgO35dhwgNEG1JYhXPb+uiKvLir cfCeJ7UHd0DdPpxF4P/hM4UQX7YMXw16J2NVtcKlL8KCxIL9LAmFz+kiS62suXoz3S Sw0tdG/07+79Q== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/as8s6MF-tAVLPGhw4hN6V8vuw6Q Subject: Re: [clue] contradiction in framework about simultaneous captures in a CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 17:39:41 -0000 On 2/21/14 12:20 PM, Duckworth, Mark wrote: > Hi Paul, > > I thought of that possibility also. But I think our intent was for the provider to be able to advertise the complete scene information for original sources, including CSEs, even if the provider didn't include encoding groups for those captures. I think it is useful to include the CSEs for captures without encoding groups, because the consumer can use this information for choosing captures, or choosing subsets within MCCs. > > Another possibility is to say either all captures in a CSE must include an encoding group, or none of the captures in a CSE can include an encoding group. I can't think of a case that makes sense to include a mixture. We can just say that the provider must be capable of simultaneously delivering all those captures in a CSE *that have an encoding group*. That would allow an CSE that has some captures with encoding groups and some without. I can't think of any reason to do that, but it seems easier than adding more arbitrary rules. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Friday, February 21, 2014 11:55 AM >> To: clue@ietf.org >> Subject: Re: [clue] contradiction in framework about simultaneous captures >> in a CSE >> >> On 2/21/14 10:06 AM, Duckworth, Mark wrote: >> >>> Here is a proposal for changing the sentence in 7.3: >>> >>> "If all the Captures in a single Capture Scene Entry have an Encoding >>> Group, then the Provider MUST be capable of encoding and sending all >>> those Captures simultaneously." >>> >>> Is that a good change? >> >> The above implies that if some but not all captures in a CSE have encoding >> groups, then there is no requirement for the provider to be able to send >> them simultaneously. >> >> Does it make sense to define a CSE containing captures without encoding >> groups? >> >> Is there any reason to do so? >> >> ISTM that we could instead say that a CSE MUST NOT reference a capture >> that has no encoding group. Then 7.3 would be ok as it is. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From nobody Fri Feb 21 09:41:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4951A02D0 for ; Fri, 21 Feb 2014 09:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wseLIW0Fy-R6 for ; Fri, 21 Feb 2014 09:41:52 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2483F1A021C for ; Fri, 21 Feb 2014 09:41:52 -0800 (PST) Received: from PWEHUB01.polycom.com (10.236.2.221) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 21 Feb 2014 09:41:48 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 21 Feb 2014 09:41:47 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 21 Feb 2014 09:41:47 -0800 Thread-Topic: [clue] contradiction in framework about simultaneous captures in a CSE Thread-Index: Ac8vK+P2U5FN4mrCSG6qjXBB7W/BnwAAD36g Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB47@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32@CRPMBOXPRD07.polycom.com> <530784E1.7020100@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB2A@CRPMBOXPRD07.polycom.com> <53078F56.20804@alum.mit.edu> In-Reply-To: <53078F56.20804@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 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/4T0WlU4YBnvQa1pYdJRAtBsj4h8 Subject: Re: [clue] contradiction in framework about simultaneous captures in a CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 17:41:54 -0000 That works for me. Mark > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, February 21, 2014 12:40 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] contradiction in framework about simultaneous capture= s > in a CSE >=20 > On 2/21/14 12:20 PM, Duckworth, Mark wrote: > > Hi Paul, > > > > I thought of that possibility also. But I think our intent was for the= provider > to be able to advertise the complete scene information for original sourc= es, > including CSEs, even if the provider didn't include encoding groups for t= hose > captures. I think it is useful to include the CSEs for captures without = encoding > groups, because the consumer can use this information for choosing > captures, or choosing subsets within MCCs. > > > > Another possibility is to say either all captures in a CSE must include= an > encoding group, or none of the captures in a CSE can include an encoding > group. I can't think of a case that makes sense to include a mixture. >=20 > We can just say that the provider must be capable of simultaneously > delivering all those captures in a CSE *that have an encoding group*. >=20 > That would allow an CSE that has some captures with encoding groups and > some without. I can't think of any reason to do that, but it seems easier= than > adding more arbitrary rules. >=20 > Thanks, > Paul >=20 > > Mark > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Friday, February 21, 2014 11:55 AM > >> To: clue@ietf.org > >> Subject: Re: [clue] contradiction in framework about simultaneous > >> captures in a CSE > >> > >> On 2/21/14 10:06 AM, Duckworth, Mark wrote: > >> > >>> Here is a proposal for changing the sentence in 7.3: > >>> > >>> "If all the Captures in a single Capture Scene Entry have an > >>> Encoding Group, then the Provider MUST be capable of encoding and > >>> sending all those Captures simultaneously." > >>> > >>> Is that a good change? > >> > >> The above implies that if some but not all captures in a CSE have > >> encoding groups, then there is no requirement for the provider to be > >> able to send them simultaneously. > >> > >> Does it make sense to define a CSE containing captures without > >> encoding groups? > >> > >> Is there any reason to do so? > >> > >> ISTM that we could instead say that a CSE MUST NOT reference a > >> capture that has no encoding group. Then 7.3 would be ok as it is. > >> > >> Thanks, > >> Paul > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > From nobody Sun Feb 23 17:39:09 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B381A078F for ; Sun, 23 Feb 2014 17:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2 X-Spam-Level: ** X-Spam-Status: No, score=2 tagged_above=-999 required=5 tests=[BAYES_80=2] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpoBSl7ck2dn for ; Sun, 23 Feb 2014 17:39:06 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE09E1A078C for ; Sun, 23 Feb 2014 17:39:05 -0800 (PST) Received: from ppp118-209-108-194.lns20.mel4.internode.on.net ([118.209.108.194]:56394 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WHkRZ-0001KT-Vb for clue@ietf.org; Mon, 24 Feb 2014 12:34:54 +1100 Message-ID: <530AA2B7.5090105@nteczone.com> Date: Mon, 24 Feb 2014 12:39:03 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32@CRPMBOXPRD07.polycom.com> <530784E1.7020100@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB2A@CRPMBOXPRD07.polycom.com> <53078F56.20804@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB47@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB47@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/IROA9PcvbeWD26-Jtbn5fwK2Wzk Subject: Re: [clue] contradiction in framework about simultaneous captures in a CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2014 01:39:08 -0000 WFM. Christian On 22/02/2014 4:41 AM, Duckworth, Mark wrote: > That works for me. > Mark > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Friday, February 21, 2014 12:40 PM >> To: Duckworth, Mark; clue@ietf.org >> Subject: Re: [clue] contradiction in framework about simultaneous captures >> in a CSE >> >> On 2/21/14 12:20 PM, Duckworth, Mark wrote: >>> Hi Paul, >>> >>> I thought of that possibility also. But I think our intent was for the provider >> to be able to advertise the complete scene information for original sources, >> including CSEs, even if the provider didn't include encoding groups for those >> captures. I think it is useful to include the CSEs for captures without encoding >> groups, because the consumer can use this information for choosing >> captures, or choosing subsets within MCCs. >>> Another possibility is to say either all captures in a CSE must include an >> encoding group, or none of the captures in a CSE can include an encoding >> group. I can't think of a case that makes sense to include a mixture. >> >> We can just say that the provider must be capable of simultaneously >> delivering all those captures in a CSE *that have an encoding group*. >> >> That would allow an CSE that has some captures with encoding groups and >> some without. I can't think of any reason to do that, but it seems easier than >> adding more arbitrary rules. >> >> Thanks, >> Paul >> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Friday, February 21, 2014 11:55 AM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] contradiction in framework about simultaneous >>>> captures in a CSE >>>> >>>> On 2/21/14 10:06 AM, Duckworth, Mark wrote: >>>> >>>>> Here is a proposal for changing the sentence in 7.3: >>>>> >>>>> "If all the Captures in a single Capture Scene Entry have an >>>>> Encoding Group, then the Provider MUST be capable of encoding and >>>>> sending all those Captures simultaneously." >>>>> >>>>> Is that a good change? >>>> The above implies that if some but not all captures in a CSE have >>>> encoding groups, then there is no requirement for the provider to be >>>> able to send them simultaneously. >>>> >>>> Does it make sense to define a CSE containing captures without >>>> encoding groups? >>>> >>>> Is there any reason to do so? >>>> >>>> ISTM that we could instead say that a CSE MUST NOT reference a >>>> capture that has no encoding group. Then 7.3 would be ok as it is. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Feb 23 18:02:07 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1CC1A022A for ; Sun, 23 Feb 2014 18:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.5 X-Spam-Level: *** X-Spam-Status: No, score=3.5 tagged_above=-999 required=5 tests=[BAYES_99=3.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNGNkxnL_Yw9 for ; Sun, 23 Feb 2014 18:02:05 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7996C1A07A5 for ; Sun, 23 Feb 2014 18:02:04 -0800 (PST) Received: from ppp118-209-108-194.lns20.mel4.internode.on.net ([118.209.108.194]:56706 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WHknm-0005KJ-Gk for clue@ietf.org; Mon, 24 Feb 2014 12:57:50 +1100 Message-ID: <530AA818.7010804@nteczone.com> Date: Mon, 24 Feb 2014 13:02:00 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9D4EA010@CRPMBOXPRD07.polycom.com> <53058C3D.1050107@alum.mit.edu> <5306EC9E.3030408@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA89@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA89@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/43_VuAjZcVH5DP7e03uSXLwfwn4 Subject: Re: [clue] Global Alternative Captures List - How to choose from multiple scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2014 02:02:06 -0000 Hello Mark, Please see my comments below. Regards, Christian On 22/02/2014 2:59 AM, Duckworth, Mark wrote: > Here is a bit more detail for a proposal: > - Call it a list of "Global Capture Entries" (GCE) > - An advertisement may include an optional list of GCEs > - A GCE references a set of media captures of a particular media type. The referenced captures can be from any capture scene in the advertisement. [CNG] Does a GCE need to reference multiple capture types? i.e. the Provider indicates a list of video GCEs and a list of audio GCEs, do we need to be able to tie them together? > - The set of captures included in a GCE are a suggestion from the provider as to which captures would be a good choice for the consumer to request, to represent a good view of the entire advertisement > - The list of GCEs may include any number of GCEs > - the order of GCEs within the list has no importance > - each GCE may include any number of captures > - the order of captures within a GCE has no importance > - The Provider MUST be capable of encoding and sending all Captures in a single Global Capture Entry simultaneously > - a GCE is similar to a CSE, but a GCE is not associated with a particular capture scene > - The Media Consumer can choose to receive all Media Captures from one Global Capture Entry for each media type (e.g. audio and video), or it can pick and choose Media Captures regardless of how the Provider arranges them in Global Capture Entries. In other words, the CSE lists and GCE list are suggestions from the provider to consumer. A consumer may choose, in a configure message, to request any media captures regardless of how the captures are listed in CSEs and GCEs. [CNG] I assume a GCE must only have at most one CSE from each scene in the Advertisement? I'm also not too sure about GCEs listing individual captures. What does an individual capture mean at that level? The CSEs indicate what captures represent a scene. Why would a provider indicate that you need a set of captures and then contradict itself by suggesting another set of captures. > > I think this is all consistent with what Paul just wrote. > I am in favor of keeping the syntax related detail in the data model, such as exactly how to reference captures from a GCE or MCC. [CNG] With the above description you've avoided mentioning CSEs. I see CSEs beyond a syntax detail. We've mentioned text in the framework regarding CaptureID and their nature of being advertisement wide. Given that we have CSEs is the STS and now potentially in the GCEs, I don't think it hurts to say each CSE has an Adverisement wide unique identifier that facilitates it being referenced in STSs and GCEs. > > I will add a more complete example to the framework presentation for IETF89, adding to what we had already from the Feb 11 design team meeting. I'll ask Paul and Mary to post it so you can review it before the meeting. I will be on vacation all next week and will not be active on this email list next week. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Friday, February 21, 2014 1:05 AM >> To: clue@ietf.org >> Subject: Re: [clue] Global Alternative Captures List - How to choose from >> multiple scenes >> >> I'd like to see more detail for this, i.e. is it optional/mandatory, can a >> consumer choose another combination?, at most one CSE from a Scene in a >> CSEg? As such I'd like to see a complete example Advertisement/Configure >> and proposed text for the framework. Also if we do add this then I think the >> CSEid should be explained more in the framework like we do for the >> CaptureID. >> >> Regards, Christian >> >> On 20/02/2014 4:01 PM, Paul Kyzivat wrote: >>> Mark, >>> >>> Unsurprisingly, I think this is a good idea. :-) >>> >>> Thanks, >>> Paul >>> >>> On 2/19/14 5:28 PM, Duckworth, Mark wrote: >>>> At the Feb 11 design team meeting we thought this idea from Paul was >>>> worth considering. Paul wrote (Feb 10): >>>> >>>> ================================================ >>>> >>>> - Leave existing per-scene CSE lists as-is. >>>> >>>> - Add another advertisement-wide CSE list. The entries in it could >>>> use shorthand, by referencing CSEs from the individual scenes. >>>> >>>> E.g., >>>> >>>> Scene1 (CSE11, CSE12, CSE13) >>>> >>>> Scene2 (CSE21, CSE22) >>>> >>>> Scene3 (CSE31) >>>> >>>> Scene4 (CSE41) >>>> >>>> Global-CSE-List ( >>>> >>>> CSEg1(CSE11, CSE21, CSE31) >>>> >>>> CSEg2(CSE12, CSE22, CSE31) >>>> >>>> CSEg3(CSE13, CSE22, CSE31) >>>> >>>> ) >>>> >>>> Here the global CSE list has recommended a subset of the possible >>>> combinations of CSEs from the different scenes, and has omitted >>>> Scene4 altogether. This is a value judgement of what combinations make >> sense. >>>> Note that I would still allow the CSEs in the global list to >>>> reference individual captures if desired. But referencing other CSEs >>>> is a convenient shorthand. >>>> >>>> ================================================ >>>> >>>> I included a slide showing a slightly more detailed example for the >>>> case we have been discussing at previous meetings. Slide 9 of >>>> http://trac.tools.ietf.org/wg/clue/trac/raw-attachment/wiki/Design-Te >>>> am/Framework_Issues_140211.pptx >>>> >>>> This example gives alternatives for a consumer that wants to receive >>>> only one capture, all the way up to a consumer that wants nine >>>> captures, with all possibilities in between. >>>> >>>> I think this new proposed list could be called "global alternative >>>> captures list" rather than a "global CSE list". Maybe somebody has a >>>> better suggestion for what to call it? The purpose of the list is >>>> for the provider to give suggestions to the consumer about which >>>> captures to choose, considering the entire advertisement. Each entry >>>> in the list is an alternative. Each entry consists of a set of >>>> captures (for shorthand, could reference multiple captures at once by >>>> referencing a CSE instead of individual capture). >>>> >>>> For an advertisement with multiple scenes, where each scene can have >>>> multiple CSEs with different number of captures in each, we have been >>>> discussing how a consumer can make a good choice between requesting >>>> captures from fewer scenes with more captures per scene, vs. >>>> requesting captures from more scenes with fewer captures per scene. >>>> The "global alternative captures list" gives the provider a way to >>>> suggest which makes more sense from the provider's viewpoint. Of >>>> course the consumer can still take into account all the other >>>> information such as priority, description, participant information and view >> attributes. >>>> Does the group support adding this additional list to an advertisement? >>>> Should I make a specific proposal for text to add to the framework? >>>> Or do we need more discussion or examples? >>>> >>>> Mark >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 nobody Thu Feb 27 08:37:39 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449751A03AF; Thu, 27 Feb 2014 08:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZLHeIDH7ZgP; Thu, 27 Feb 2014 08:37:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB341A03BB; Thu, 27 Feb 2014 08:37:32 -0800 (PST) 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: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140227163732.25856.88904.idtracker@ietfa.amsl.com> Date: Thu, 27 Feb 2014 08:37:32 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/OLqNIcOUBqRZtRAvNc4taShmqM8 Cc: clue mailing list , clue chair , RFC Editor Subject: [clue] Document Action: 'Requirements for Telepresence Multi-Streams' to Informational RFC (draft-ietf-clue-telepresence-requirements-07.txt) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 16:37:37 -0000 The IESG has approved the following document: - 'Requirements for Telepresence Multi-Streams' (draft-ietf-clue-telepresence-requirements-07.txt) as Informational RFC This document is the product of the ControLling mUltiple streams for tElepresence Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements/ Technical Summary This document identifies requirements for a future specification(s) that, when fulfilled by an implementation of the specification(s), provide for interoperability between IETF protocol based telepresence systems. It is anticipated that a solution for the requirements set out in this memo likely involves the exchange of adequate information about participating sites; information that is currently not standardized by the IETF. Working Group Summary There was nothing of particular note. Just the usual give and take. This document has been in progress for a long time (since August 2011), but that is just a reflection of WG style. We have kept the document open and tweaked it while working on the other documents. Document Quality Since this is just a precursor to other documents for the WG, there are not , and will not be, multiple implementations. (The other documents in progress in the WG constitute the one intended "implementation" of these requirements. Personnel Who is the Document Shepherd? Paul Kyzivat Who is the Responsible Area Director? Gonzalo Camarillo RFC Editor's Note Please, perform the following change on the document: OLD: REQMT-1c: The solution MUST support a means to identify the point of capture of individual video captures in three dimensions. REQMT-1d: The solution MUST support a means to identify the area of coverage of individual video captures in three dimensions. NEW: REQMT-1c: The solution MUST support a means to identify the relative location, within a scene, of the point of capture of individual video captures in three dimensions. REQMT-1d: The solution MUST support a means to identify the area of coverage, within a scene, of individual video captures in three dimensions.