From iesg-secretary@ietf.org Thu Jan 2 13:14: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 189571A1F5F; Thu, 2 Jan 2014 13:14:12 -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 BbnrCpW3CORl; Thu, 2 Jan 2014 13:14:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB751A1F3E; Thu, 2 Jan 2014 13:14:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140102211409.4365.65356.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2014 13:14:09 -0800 Cc: clue@ietf.org Subject: [clue] CLUE WG Virtual Interim Meeting, January 27, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Reply-To: clue@ietf.org List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 21:14:12 -0000 The CLUE WG will hold an Interim meeting on: Monday, January 27, 2014 15:00-17:00 GMT (starting at 7.00 Pacific, 9.00 Central, 10.00 Eastern) Webex details and the preliminary agenda are available on the CLUE WG wiki: *http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140127 * From Mark.Duckworth@polycom.com Mon Jan 6 12:15: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 9C62D1AE1E0 for ; Mon, 6 Jan 2014 12:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 0t3G6NIBNBbu for ; Mon, 6 Jan 2014 12:15:53 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0582E1AE1DE for ; Mon, 6 Jan 2014 12:15:52 -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; Mon, 6 Jan 2014 12:15:44 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Mon, 6 Jan 2014 12:15:42 -0800 Thread-Topic: [clue] Design team meeting on roles followup Thread-Index: Ac7/l/qqXWlTieDuT9aXj+8ZEFPlPQLg+wvg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E22F@CRPMBOXPRD07.polycom.com> References: <52B7BCCE.1040409@nteczone.com> In-Reply-To: <52B7BCCE.1040409@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] Design team meeting on roles followup 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, 06 Jan 2014 20:15:54 -0000 Hi Christian, These terms you propose are okay with me. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Sunday, December 22, 2013 11:32 PM > To: clue@ietf.org > Subject: [clue] Design team meeting on roles followup >=20 > Hello >=20 > One of the items that came up at the design team meeting on roles was to > avoid the use of the term "role" and the confusion that it brings with re= spect > to conference control. >=20 > In order to address this I propose the following terms: >=20 > Participant Information: this is equivalent to vCard(xCard) information t= hat > would be set against an individual Capture. >=20 > Scene Information: This is equivalent to vCard(xCard) information that wo= uld > be set against a Capture Scene. >=20 > Participant Type: This is equivalent to what was proposed as "meeting rol= e" > in the role draft. i.e. Chairman, Vice-Chairman, Secretary, Participant, > Presenter, Translator, Timekeeper and a possibility for further provider > defined types. >=20 > Any issues with the above terms? >=20 > Note: I'm only discussing the terms. I'll provide some proposals to add t= hese > to the framework once we can find terms people are happy with. >=20 > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Mon Jan 6 12:54: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 360D41AE1CC for ; Mon, 6 Jan 2014 12:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 2xDEsAFGv5Cw for ; Mon, 6 Jan 2014 12:54:38 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A81A61AE17F for ; Mon, 6 Jan 2014 12:54:37 -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, 6 Jan 2014 12:54:29 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Mon, 6 Jan 2014 12:54:28 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 6 Jan 2014 12:54:27 -0800 Thread-Topic: spatial information can't describe video locations within composed MCC Thread-Index: Ac8LIWZHivJQaqYCRv2pgpRyhMtqYw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@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_49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278CRPMBOXPRD07p_" MIME-Version: 1.0 Subject: [clue] 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: Mon, 06 Jan 2014 20:54:40 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Framework version 13 says a provider can use spatial information of source = media captures to describe how those sources are placed within a composed m= ultiple 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 compo= sed MCC. >From section 7.2.1: For example: The spatial related attributes can be further used to determin= e how the individual captures "appear" within a stream. A virtual scene co= uld be constructed for the MCC capture with two Video Captures with a "MaxC= aptures" attribute set to 2 and an "Area of Capture" attribute provided wit= h 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 Co= nsumer 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 fro= m different scenes has no relation to each other. So if the individual cap= tures that are part of a composed MCC come from different scenes (source ca= ptures 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 wil= l 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 b= e 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, the= n the spatial information wouldn't always indicate the location of the sour= ce 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 ad= vertisements. 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 informatio= n wouldn't always indicate the location of the source within the MCC. 4. Take a slightly different example, where the MCC contains 4 contri= buting individual captures, but still with MaxCaptures =3D 2. So the resul= ting MCC again will change over time, as the provider is free to choose whi= ch 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 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Framework versio= n 13 says a provider can use spatial information of source media captures t= o 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 pr= opose removing that part, and instead add text to say the spatial informati= on of individual captures does not relate to its relative position within a= composed MCC.

 

From section 7.2.1:

For example: The spati= al related attributes can be further used to determine how the individual c= aptures "appear" within a stream.  A virtual scene could be = constructed for the MCC capture with two Video Captures with a "MaxCap= tures" 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 positi= on of the content in the composed stream.

 

Here are some reasons wh= y I think this will generally not work:

1.       The = spatial information for captures is relevant only in relation to the captur= e scene to which the captures belong.  Spatial information from differ= ent scenes has no relation to each other.  So if the individual captur= es that are part of a composed MCC come from different scenes (source captu= res from multiple scenes, or source captures from different scenes than the= MCC) then the spatial information of one capture has no relation to the sp= atial 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, bu= t sometimes there could be 1.  The contents of the MCC could actually = be changing over time between 1 and 2 contributing captures.  If it ch= anges between one full screen source image to two source images side by sid= e, 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 det= ail in provider advertisements.

3.4.       <= /span>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 t= o choose which 2 out of the 4 to include at any time.  So again the sp= atial information wouldn’t always indicate the location of the source= within the MCC.

 

Regards,

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278CRPMBOXPRD07p_-- From Christian.Groves@nteczone.com Mon Jan 6 21:08: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 6175A1AE434 for ; Mon, 6 Jan 2014 21:08:24 -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_50=0.8, 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 L6QLd86yDE42 for ; Mon, 6 Jan 2014 21:08:21 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760921ADF8A for ; Mon, 6 Jan 2014 21:08:21 -0800 (PST) Received: from ppp118-209-137-14.lns20.mel6.internode.on.net ([118.209.137.14]:59903 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W0Oqg-00057u-LQ for clue@ietf.org; Tue, 07 Jan 2014 16:05:06 +1100 Message-ID: <52CB8BB9.70503@nteczone.com> Date: Tue, 07 Jan 2014 16:08:09 +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: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@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] 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: Tue, 07 Jan 2014 05:08:24 -0000 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 > wont work, and Im 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 doesnt 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 wouldnt 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 dont 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 wouldnt 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 wouldnt 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 From Mark.Duckworth@polycom.com Tue Jan 7 05:18: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 DD8F61AE01A for ; Tue, 7 Jan 2014 05:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 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.538, 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 ilVOgAhDu_0j for ; Tue, 7 Jan 2014 05:18:22 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 776A61AE00F for ; Tue, 7 Jan 2014 05:18:22 -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; Tue, 7 Jan 2014 05:18:13 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Tue, 7 Jan 2014 05:18:11 -0800 Thread-Topic: [clue] spatial information can't describe video locations within composed MCC Thread-Index: Ac8LZn075jM4wi2xTSe42WohD+3G1AARATLQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E3E6@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> <52CB8BB9.70503@nteczone.com> In-Reply-To: <52CB8BB9.70503@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] 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: Tue, 07 Jan 2014 13:18:25 -0000 Hello Christian, So there are only certain circumstances in which spatial information for co= mponents of a composed capture is relevant. For the case where you think i= t 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 an= d 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 wi= thin > composed MCC >=20 > Hello Mark, >=20 > I agree with respect to the fact that spatial information isn't valid acr= oss > Capture Scenes. i.e. If I have an MCC in one Cap.Scene referencing indivi= dual > captures from other scenes. However I think there is a valid case where a= n > 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. >=20 > 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 individ= ual > captures move. However there will be cases where the composition is stati= c > 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. >=20 > Regards, Christian >=20 > 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 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Jan 7 06:20: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 AC5E31AE013 for ; Tue, 7 Jan 2014 06:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 Hhd_txnPTbnE for ; Tue, 7 Jan 2014 06:20:20 -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 5EC851ADF66 for ; Tue, 7 Jan 2014 06:20:19 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta07.westchester.pa.mail.comcast.net with comcast id B0y51n0040ldTLk572LBaZ; Tue, 07 Jan 2014 14:20:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id B2LA1n0103ZTu2S012LBzR; Tue, 07 Jan 2014 14:20:11 +0000 Message-ID: <52CC0D1A.50207@alum.mit.edu> Date: Tue, 07 Jan 2014 09:20:10 -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 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=1389104411; bh=jar5PNvwSxbVqamSGP4prA5j7gShLgsaltG5QMfaf3c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aCQ8fuSmIL2S5vPUmJMyfZpcl6/DdNBYO2qpPXPMhdR5oqOm/DfTJRtTnMyVXWoLq fyJKW82txKR/w4T/i1FVN4YwDsPQrMBbx47yqsRx3DXTPYKyxek4vGPYHa9WNeMZIj nBPnobC0h3POz3P06kQzlv0nJ+8e+TSXNFLex87uAORekiUgRSFgwfGwL9qXkaG887 ei8RKSYkgmGbuEQ3ocThqbxT7pK3FkRVx/SsqTvakJ3DOukGEl6knyhhBh6AKDUNOO ElJzEBJBzENs/+Ls7w9r2p7cllL7HRxAZMfMWTVcLKwj/SyhEhcIUxtLUpgIE8dINf LmSaWI5PBd7Jw== Subject: [clue] Today's design team meeting cancelled 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, 07 Jan 2014 14:20:30 -0000 The plan for today was for Christer to lead a discussion of the Data Channel. But due to a last minute logistic issue Christer won't be able to attend. We will still have a meeting next week per the prior plan. Mary and I will sort out whether to reschedule the data channel discussion or shift the schedule for all the meetings out a week. Sorry, Paul From pkyzivat@alum.mit.edu Tue Jan 7 08:06: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 474D31ADFF8 for ; Tue, 7 Jan 2014 08:06:34 -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 Xy0fGM72OVMU for ; Tue, 7 Jan 2014 08:06:32 -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 A7C921ADFD7 for ; Tue, 7 Jan 2014 08:06:32 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta01.westchester.pa.mail.comcast.net with comcast id B1A91n0040xGWP85146P22; Tue, 07 Jan 2014 16:06:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id B46P1n00M3ZTu2S3Y46PTC; Tue, 07 Jan 2014 16:06:23 +0000 Message-ID: <52CC25FF.2080402@alum.mit.edu> Date: Tue, 07 Jan 2014 11:06:23 -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: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@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=1389110783; bh=Y7LBTjlY+8ZDd1HLwH8Se583jl0NDl8UHVOMU4L5KqE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WeM8JbxuGnp5T3UvQ3Psz+lnHMofHYst7c1lkq2uM1EGqxrB6ybnF1D5UPRXsZsRV t+DaUdy9sgPciUJRwdRBw8ELvoSOUHapMJ8wAtWx0iY2O2IgRBn0ew4SRY/xY7gBSt yoXH76YjdsP6uHbvXlzXUjNBVp4Cp/8A33dhmjzxLew7cJEfLKqlU9A0ogNp2FP2q6 cMBIXhwDGUK9ThY9AtMwg8OZ4NyZtrZL9GYvvwnyqW9wr4U7mkTCFQNH7LktmT9MlG WJX+ltIj8iZdYktNR8EbE7I3QPgpShe646p60GBEx9LHzp+wDYwESuvkKv2A7gX0R/ sWuXIVklgMdkg== Subject: Re: [clue] 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: Tue, 07 Jan 2014 16:06:34 -0000 Mark, As long as the spatial information for source captures is present in the advertisement, the client can always attempt to use it to help decide how to map the captures it configures to the devices it has available. In some cases that information may be more helpful than others. It might be useful to give an example where it is useful, but I don't think we should try to be exhaustive about this. If an MCU advertiser assigns spatial coordinates to the MCC captures within the (virtual) scene where those captures are declared, the only information *it* has to do so are the coordinates of those captures within the scenes in which they are received. So a client of that MCU, given source capture spatial info, can do as well as the MCU did. And it might do better, especially if the MCU doesn't bother to assign coordinates within the virtual scene. Also, the client can take advantage of specifics of its situation. For instance, if it is only configuring a subset of the MCC captures. AFAIK the key cases where any of this matters are with site switching, because then it may be possible to preserve the relationships between the captures regardless of what site happens to be switched in. Thanks, Paul On 1/6/14 3:54 PM, 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 wont > work, and Im 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 doesnt 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 wouldnt 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 dont 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 wouldnt 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 wouldnt 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 > From pkyzivat@alum.mit.edu Tue Jan 7 08:10: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 4EBB11AE013 for ; Tue, 7 Jan 2014 08:10: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 q8fkjiU-giE3 for ; Tue, 7 Jan 2014 08:10:17 -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 1B9441ADF33 for ; Tue, 7 Jan 2014 08:10:17 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta13.westchester.pa.mail.comcast.net with comcast id B3vT1n0060cZkys5D4A8Lk; Tue, 07 Jan 2014 16:10:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id B4A81n0043ZTu2S3W4A8lq; Tue, 07 Jan 2014 16:10:08 +0000 Message-ID: <52CC26DF.7070905@alum.mit.edu> Date: Tue, 07 Jan 2014 11:10:07 -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: <52B7BCCE.1040409@nteczone.com> In-Reply-To: <52B7BCCE.1040409@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=1389111008; bh=OlFhqQDIHBhuZumv1C0dFQ73kKg5g4M3M6oOBcas1N4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DxXW92v7NqqdWAxd/hJ6ijEsqjFP7kYI4skjGNAW1eXTiYgV4fSGOhQ50ctSzNYWB +ykfGkmKxsufDEUgfJNMlxZP26KooWpNubLEuWH8IvT3DOvUTeJGdsGX7MkRPtuk+m EFfSoAEO3T8idI53I23ZTqJzehOTKNmTXXDI0JaCxC6jDz3THNxXsogqxRUAzdMysn jUFH2/3UfioPnKSXpD6drZzsy9L5PEpEc+4HHzpGettVQ3SwPXO2wL/cTMmeWRdkJ8 pbrvHJQv5Jljt4xZg/d86kRodZAjgTidXtdXoMr+eLVloCpmSW1RwnkD6Pe7GMEtKv zlFqZ5VyweCmA== Subject: Re: [clue] Design team meeting on roles followup 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, 07 Jan 2014 16:10:18 -0000 WFM On 12/22/13 11:32 PM, Christian Groves wrote: > Hello > > One of the items that came up at the design team meeting on roles was to > avoid the use of the term "role" and the confusion that it brings with > respect to conference control. > > In order to address this I propose the following terms: > > Participant Information: this is equivalent to vCard(xCard) information > that would be set against an individual Capture. > > Scene Information: This is equivalent to vCard(xCard) information that > would be set against a Capture Scene. > > Participant Type: This is equivalent to what was proposed as "meeting > role" in the role draft. i.e. Chairman, Vice-Chairman, Secretary, > Participant, Presenter, Translator, Timekeeper and a possibility for > further provider defined types. > > Any issues with the above terms? > > Note: I'm only discussing the terms. I'll provide some proposals to add > these to the framework once we can find terms people are happy with. > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Tue Jan 7 10:36: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 8E40D1AE116 for ; Tue, 7 Jan 2014 10:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 jpEYIjHraskN for ; Tue, 7 Jan 2014 10:36:47 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8966E1ADEB1 for ; Tue, 7 Jan 2014 10:36: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; Tue, 7 Jan 2014 10:36:38 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Tue, 7 Jan 2014 10:36:37 -0800 Thread-Topic: [clue] spatial information can't describe video locations within composed MCC Thread-Index: Ac8LwnInBdhB+eCTSvGNZ2spXCMsqgAE9eKw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E5C5@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> <52CC25FF.2080402@alum.mit.edu> In-Reply-To: <52CC25FF.2080402@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] 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: Tue, 07 Jan 2014 18:36:50 -0000 Hello Paul, I agree with you, but I think you are talking about something a little diff= erent than the point I was trying to make. I'll try to be more clear. They key thing is this statement from the frame= work (which originally came from Christian): " The Consumer would then know the relative position of the content in the = composed stream " This is saying the MCU is advertising a composed video stream, and the cons= umer can tell from the advertisement how those individual source video capt= ures are laid out within the composed stream the MCU creates. Christian sa= ys this is possible and useful, and I'm saying there are fairly strict cons= traints on when this is possible. I think Christian agrees there are const= raints, so we're trying to articulate the constraints. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, January 07, 2014 11:06 AM > To: clue@ietf.org > Subject: Re: [clue] spatial information can't describe video locations wi= thin > composed MCC >=20 > Mark, >=20 > As long as the spatial information for source captures is present in the > advertisement, the client can always attempt to use it to help decide how= to > map the captures it configures to the devices it has available. > In some cases that information may be more helpful than others. It might = be > useful to give an example where it is useful, but I don't think we should= try to > be exhaustive about this. >=20 > If an MCU advertiser assigns spatial coordinates to the MCC captures with= in > the (virtual) scene where those captures are declared, the only informati= on > *it* has to do so are the coordinates of those captures within the scenes= in > which they are received. >=20 > So a client of that MCU, given source capture spatial info, can do as wel= l as > the MCU did. And it might do better, especially if the MCU doesn't bother= to > assign coordinates within the virtual scene. Also, the client can take > advantage of specifics of its situation. For instance, if it is only conf= iguring a > subset of the MCC captures. >=20 > AFAIK the key cases where any of this matters are with site switching, > because then it may be possible to preserve the relationships between the > captures regardless of what site happens to be switched in. >=20 > Thanks, > Paul >=20 >=20 >=20 > On 1/6/14 3:54 PM, 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 o= f > 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 > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Jan 7 12:11: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 5AAD91AE15D for ; Tue, 7 Jan 2014 12:11:41 -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 wVPc3-ghoxsB for ; Tue, 7 Jan 2014 12:11:39 -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 6780C1AE11F for ; Tue, 7 Jan 2014 12:11:39 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta06.westchester.pa.mail.comcast.net with comcast id B5nQ1n0020mv7h0568BW1W; Tue, 07 Jan 2014 20:11:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id B8BW1n00A3ZTu2S3X8BWBk; Tue, 07 Jan 2014 20:11:30 +0000 Message-ID: <52CC5F72.3060008@alum.mit.edu> Date: Tue, 07 Jan 2014 15:11:30 -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: "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> <52CC25FF.2080402@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E5C5@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E5C5@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=1389125490; bh=56UZwWiNtaz+tFSYN4YfcZdzsvOYC+B8dO06OgX/LPI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dgmIwUmXXbufF6NQHKaCuqUJ/7nVARSNBAIrenJ5Hs/r6oct2V+hSBSZJSmvFCRSx 3yqDioOcHieYNu5FI7oTzukJ9fo3PaflZjDUQtChQ/wFxo7A+QyKQXnnEuh86AbNpG zKVa8oz12zHE1qmstyS2beDGUN3y3MxrCcM2+HIYsvOclbzC8XI21ySjlf6IlAq2Oj XCq0SClq4qTPyyRgt2EJ4yMnK610sHRuNSZ8OXiMgH/wNmIEWsctyHes1RK9q0W5Ek Z8Lfhqy19DQMJ9q1eGnM3J053kuP7VuWLY8Y5nZSHB2HqdvdEvchB2vbkSOlzdY0cD eQA61Ia+59B1g== Subject: Re: [clue] 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: Tue, 07 Jan 2014 20:11:41 -0000 On 1/7/14 1:36 PM, Duckworth, Mark wrote: > Hello Paul, > > I agree with you, but I think you are talking about something a little different than the point I was trying to make. > > I'll try to be more clear. They key thing is this statement from the framework (which originally came from Christian): > " The Consumer would then know the relative position of the content in the composed stream" > This is saying the MCU is advertising a composed video stream, and the consumer can tell from the advertisement how those individual source video captures are laid out within the composed stream the MCU creates. Christian says this is possible and useful, and I'm saying there are fairly strict constraints on when this is possible. I think Christian agrees there are constraints, so we're trying to articulate the constraints. Oh, sorry! I agree that is something different from what I was talking about. And I don't really understand how that would work without some sort of leap of faith about how composition is done. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Tuesday, January 07, 2014 11:06 AM >> To: clue@ietf.org >> Subject: Re: [clue] spatial information can't describe video locations within >> composed MCC >> >> Mark, >> >> As long as the spatial information for source captures is present in the >> advertisement, the client can always attempt to use it to help decide how to >> map the captures it configures to the devices it has available. >> In some cases that information may be more helpful than others. It might be >> useful to give an example where it is useful, but I don't think we should try to >> be exhaustive about this. >> >> If an MCU advertiser assigns spatial coordinates to the MCC captures within >> the (virtual) scene where those captures are declared, the only information >> *it* has to do so are the coordinates of those captures within the scenes in >> which they are received. >> >> So a client of that MCU, given source capture spatial info, can do as well as >> the MCU did. And it might do better, especially if the MCU doesn't bother to >> assign coordinates within the virtual scene. Also, the client can take >> advantage of specifics of its situation. For instance, if it is only configuring a >> subset of the MCC captures. >> >> AFAIK the key cases where any of this matters are with site switching, >> because then it may be possible to preserve the relationships between the >> captures regardless of what site happens to be switched in. >> >> Thanks, >> Paul >> >> >> >> On 1/6/14 3:54 PM, 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 > From Mark.Duckworth@polycom.com Thu Jan 9 11:23: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 5AB271AE41B for ; Thu, 9 Jan 2014 11:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 D2Hpwq8lSVtF for ; Thu, 9 Jan 2014 11:23:12 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A770B1AE0EB for ; Thu, 9 Jan 2014 11:23:12 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Thu, 9 Jan 2014 11:23:03 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 9 Jan 2014 11:23:01 -0800 Thread-Topic: MCC switching example Thread-Index: Ac8Nb/qDllbjeT73TDSssQjZD0RtdQ== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8EF07@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_49E45C59CA48264997FEBFB29B6BC2D60C9CC8EF07CRPMBOXPRD07p_" MIME-Version: 1.0 Subject: [clue] MCC switching example 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, 09 Jan 2014 19:23:15 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CC8EF07CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In framework-13, there is a new example for MCC usage in section 12.3.3. I= think the part about Capture Scene #8 is either incorrect or incomplete. = This is supposed to describe how the MCU can advertise captures representin= g the non-current-talker endpoints, and allow the receiving endpoint to ren= der them with proper spatial relationships. For example, I don't see any w= ay for endpoint A (the receiving consumer endpoint) to be able to render ca= ptures from scene #8 that come from endpoint B (3 cameras) next to each oth= er. There is no way for A to know at any point in time which MCCs contain = VC4, VC5, and VC6 from endpoint B, so there is no way for A to render them = next to each other. We discussed this general topic at IETF88, but didn't have much time on it.= We can discuss again at the design team meeting on January 14 and the int= erim meeting. See presentation http://tools.ietf.org/agenda/88/slides/slides-88-clue-5.pd= f. Some possible approaches are (corresponding to 1-3 on page 15 from the pres= entation): 1. Use an advertisement like in the framework example, but also need to add= ability for receiver to relate the original source of incoming capture enc= odings at the RTP level to the captures in the CLUE advertisement. 2. Use an advertisement like in the framework example, but the consumer sel= ects the specific sources at any point in time by sending a configure messa= ge whenever it wants to change its selection. Need to add ability for the = consumer to know about audio activity so it can use that to inform switchin= g decisions. Maybe it can just come from audio streams sent from MCU to th= e consumer. Probably also want same ability to relate the incoming encoding= s to original captures as in item 1 above. 3. Use a different advertisement, breaking apart Capture Scene #8 into thre= e separate scenes, where each scene has three MCCs with spatial information= on the MCCs themselves. This would be three separate scenes practically th= e same as Scene #7, but with different policy values to indicate they are f= urther down in the MCU's recent speaker list. The MCU is responsible for m= aintaining the advertised spatial relation between MCCs when it switches to= different sources. I am most interested in option 2. But I think we can make all of them work= in CLUE with some additions about relating incoming encodings to advertise= d captures. I'd like to discuss this more before deciding if/how to update this example= in the framework. Regards, Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CC8EF07CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In framework-13,= there is a new example for MCC usage in section 12.3.3.  I think the = part about Capture Scene #8 is either incorrect or incomplete.  This i= s supposed to describe how the MCU can advertise captures representing the = non-current-talker endpoints, and allow the receiving endpoint to render th= em with proper spatial relationships.  For example, I don't see any wa= y for endpoint A (the receiving consumer endpoint) to be able to render cap= tures from scene #8 that come from endpoint B (3 cameras) next to each othe= r.  There is no way for A to know at any point in time which MCCs cont= ain VC4, VC5, and VC6 from endpoint B, so there is no way for A to render t= hem next to each other.

 

We discussed this general topic at IETF88, but di= dn't have much time on it.  We can discuss again at the design team me= eting on January 14 and the interim meeting.

See presentation http://tools.ietf.org/agenda/88/slides/slides-88-clue= -5.pdf.

 

Some possible approaches are (corresponding to 1-3 on page 15 fro= m the presentation):

 

1. Use an advertisement like in the framework exampl= e, but also need to add ability for receiver to relate the original source = of incoming capture encodings at the RTP level to the captures in the CLUE = advertisement.

 

2. Use an advertisement like in the framework example, but= the consumer selects the specific sources at any point in time by sending = a configure message whenever it wants to change its selection.  Need t= o add ability for the consumer to know about audio activity so it can use t= hat to inform switching decisions.  Maybe it can just come from audio = streams sent from MCU to the consumer. Probably also want same ability to r= elate the incoming encodings to original captures as in item 1 above.<= /o:p>

 

3. = Use a different advertisement, breaking apart Capture Scene #8 into three s= eparate scenes, where each scene has three MCCs with spatial information on= the MCCs themselves. This would be three separate scenes practically the s= ame as Scene #7, but with different policy values to indicate they are furt= her down in the MCU's recent speaker list.  The MCU is responsible for= maintaining the advertised spatial relation between MCCs when it switches = to different sources.

 <= /p>

I am most interested in option 2.  But I think= we can make all of them work in CLUE with some additions about relating in= coming encodings to advertised captures.

 

I'd like to discuss this more be= fore deciding if/how to update this example in the framework.

 

Regards,

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CC8EF07CRPMBOXPRD07p_-- From Mark.Duckworth@polycom.com Thu Jan 9 14: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 8BEE11AE1C0 for ; Thu, 9 Jan 2014 14:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 6yjhNGWvDnI5 for ; Thu, 9 Jan 2014 14:11:53 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id E06431AC404 for ; Thu, 9 Jan 2014 14:11:52 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Thu, 9 Jan 2014 14:11:43 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 9 Jan 2014 14:11:42 -0800 Thread-Topic: Advertising what is in an MCC - allow wildcard? Thread-Index: Ac8NgeDi4Pq0j/LORl2FMn89j9cUfw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@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_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17CCRPMBOXPRD07p_" MIME-Version: 1.0 Subject: [clue] Advertising what is in an MCC - allow wildcard? 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, 09 Jan 2014 22:11:56 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17CCRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In an advertisement, the provider can indicate which other captures are ref= erenced by an MCC, for example: Individual captures advertised: VC1, VC2, VC3, VC4, VC5 MCC1(VC1, VC2) This means MCC1 can include VC1 and/or VC2, but not the others. MCC2() Without any specific references, this means the provider is not saying whic= h other captures can be included in MCC2, and the consumer cannot choose. I propose adding a wildcard: MCC3(*) This means MCC3 can include any of the other captures VC1 through VC5, and = the consumer can choose. For some types of MCUs, that want to give consumers the choice of which spe= cific captures to receive in an MCC, this is useful for large advertisement= s with many media captures. When endpoints join or leave a conference, cau= sing the advertisement to change to add or remove scenes and captures, the = part of the advertisement with MCCs wouldn't have to change at all. Related text from framework-13: >From 7.2: "The MCC may contain a reference to the Single Media Captures... = (or) A MCC MAY contain no references to other Captures to indicate that the= MCC contains content from multiple sources but no information regarding th= ose sources is given." And in section 10 "If the MCC in the advertisement = does not reference any individual captures, then the Consumer cannot choose= what is included in the MCC" I propose adding text: The MCC may contain a wildcard reference, meaning it can refer to any of th= e other captures in the advertisement. The consumer, in a configure messag= e, may choose which of the other media captures it wishes to receive in the= MCC. What do you think? Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17CCRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In an advertisem= ent, the provider can indicate which other captures are referenced by an MC= C, for example:

 

Individual captures advertised: VC1, VC2, VC3, VC4, VC5

MCC1(VC1, VC2)

This means MCC1 can include VC1 and/or VC2, but not the others.

 

= MCC2()

Without any specific references, = this means the provider is not saying which other captures can be included = in MCC2, and the consumer cannot choose.

 

I propose adding a wildcard:

MCC3(*)

= This means MCC3 can include any of the other captures VC1 through VC5, and = the consumer can choose.

 

For some types of MCUs, that want to give consum= ers the choice of which specific captures to receive in an MCC, this is use= ful for large advertisements with many media captures.  When endpoints= join or leave a conference, causing the advertisement to change to add or = remove scenes and captures, the part of the advertisement with MCCs wouldn&= #8217;t have to change at all.

&nbs= p;

Related text from framework-13:=

From 7.2: “The MCC may contain a reference to the Single Media = Captures… (or) A MCC MAY contain no references to other Captures to i= ndicate that the MCC contains content from multiple sources but no informat= ion regarding those sources is given.”  And in section 10= “If the MCC = in the advertisement does not reference any individual captures, then the C= onsumer cannot choose what is included in the MCC”<= /p>

 

I propose= adding text:

The MCC may contain a wild= card reference, meaning it can refer to any of the other captures in the ad= vertisement.  The consumer, in a configure message, may choose which o= f the other media captures it wishes to receive in the MCC.

<= p class=3DMsoNormal> 

What do you t= hink?

 

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17CCRPMBOXPRD07p_-- From Mark.Duckworth@polycom.com Thu Jan 9 15:01: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 7EE211AD190 for ; Thu, 9 Jan 2014 15:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 zaNl8VrpOhwc for ; Thu, 9 Jan 2014 15:01:16 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 186111ACD00 for ; Thu, 9 Jan 2014 15:01:16 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Thu, 9 Jan 2014 15:01:06 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 9 Jan 2014 15:01:04 -0800 Thread-Topic: Should framework refer to RTP multiplexing and RTP mapping document? Thread-Index: Ac8NjmUAk1xMMxi5Qvi/iCY7LuuxKQ== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC1BD@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_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC1BDCRPMBOXPRD07p_" MIME-Version: 1.0 Subject: [clue] Should framework refer to RTP multiplexing and RTP mapping 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, 09 Jan 2014 23:01:17 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC1BDCRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm looking through all the open issues in the framework document. This is= one issue at the end of section 5: "Edt. note (StW): what's written below is likely correct, but is not the re= sult of the introduction of CLUE, but rather the result of a generational o= verhaul of RTP usage that would have happened with or without CLUE. Sugges= t to delete the sentences below until begin of section 6. Is having a CLUE= RTP Mapping document still the plan? If yes, we should have a real draft = and a real reference." "However, some form of RTP multiplexing is likely to be used by CLUE device= s. More information about relating RTP flows to CLUE entities is in the CL= UE RTP Mapping document." Does anybody have a suggestion about this? Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC1BDCRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m lookin= g through all the open issues in the framework document.  This is one = issue at the end of section 5:

&nbs= p;

“Edt. note (StW): what's written bel= ow is likely correct, but is not the result of the introduction of CLUE, bu= t rather the result of a generational overhaul of RTP usage that would have= happened with or without CLUE.  Suggest to delete the sentences below= until begin of section 6.  Is having a CLUE RTP Mapping document stil= l the plan?  If yes, we should have a real draft and a real reference.= ”

“However, some form of RTP= multiplexing is likely to be used by CLUE devices.  More information = about relating RTP flows to CLUE entities is in the CLUE RTP Mapping docume= nt.”

 

Does anybody have a suggestion about this?

 

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC1BDCRPMBOXPRD07p_-- From Christian.Groves@nteczone.com Thu Jan 9 17:35: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 E52841ADF56 for ; Thu, 9 Jan 2014 17:35:09 -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 3NhJZ4egBx0c for ; Thu, 9 Jan 2014 17:35:07 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9851AE15C for ; Thu, 9 Jan 2014 17:35:06 -0800 (PST) Received: from ppp118-209-75-105.lns20.mel4.internode.on.net ([118.209.75.105]:57621 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W1QzN-0005ZW-L0 for clue@ietf.org; Fri, 10 Jan 2014 12:34:21 +1100 Message-ID: <52CF4E39.3040908@nteczone.com> Date: Fri, 10 Jan 2014 12:34:49 +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: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8EF07@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8EF07@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] MCC switching example 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, 10 Jan 2014 01:35:10 -0000 Hello Mark, Please see my comments below. Regards, Christian On 10/01/2014 6:23 AM, Duckworth, Mark wrote: > > In framework-13, there is a new example for MCC usage in section > 12.3.3. I think the part about Capture Scene #8 is either incorrect > or incomplete. This is supposed to describe how the MCU can advertise > captures representing the non-current-talker endpoints, and allow the > receiving endpoint to render them with proper spatial relationships. > For example, I don't see any way for endpoint A (the receiving > consumer endpoint) to be able to render captures from scene #8 that > come from endpoint B (3 cameras) next to each other. There is no way > for A to know at any point in time which MCCs contain VC4, VC5, and > VC6 from endpoint B, so there is no way for A to render them next to > each other. > [CNG] I agree that capture scene 8 doesn't describe what you want above. However I believe that it is valid for describing what is intended i.e. The MCU can also supply nine media streams showing the active and previous eight speakers. Its displaying the captures of the active speaker not the whole speaker site. The site switching aspect is described in Capture Scene #7. I also agree that knowing exactly what capture is in the MCC capture encoding at a particular point of time is an issue. > We discussed this general topic at IETF88, but didn't have much time > on it. We can discuss again at the design team meeting on January 14 > and the interim meeting. > [CNG] Unfortunately i'll be away for the Jan14 meeting. > See presentation > http://tools.ietf.org/agenda/88/slides/slides-88-clue-5.pdf. > > Some possible approaches are (corresponding to 1-3 on page 15 from the > presentation): > > 1. Use an advertisement like in the framework example, but also need > to add ability for receiver to relate the original source of incoming > capture encodings at the RTP level to the captures in the CLUE > advertisement. > > 2. Use an advertisement like in the framework example, but the > consumer selects the specific sources at any point in time by sending > a configure message whenever it wants to change its selection. Need > to add ability for the consumer to know about audio activity so it can > use that to inform switching decisions. Maybe it can just come from > audio streams sent from MCU to the consumer. Probably also want same > ability to relate the incoming encodings to original captures as in > item 1 above. > > 3. Use a different advertisement, breaking apart Capture Scene #8 into > three separate scenes, where each scene has three MCCs with spatial > information on the MCCs themselves. This would be three separate > scenes practically the same as Scene #7, but with different policy > values to indicate they are further down in the MCU's recent speaker > list. The MCU is responsible for maintaining the advertised spatial > relation between MCCs when it switches to different sources. > > I am most interested in option 2. But I think we can make all of them > work in CLUE with some additions about relating incoming encodings to > advertised captures. > [CNG] My feeling is that 1) would be the most robust general approach. Knowing the source capture at the RTP would be faster and minimise any sync issues between CLUE and RTP and the provider/consumer. I think a pragmatic approach to the use case would be 3. > > I'd like to discuss this more before deciding if/how to update this > example in the framework. > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Thu Jan 9 17:42: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 99BF61ADEA0 for ; Thu, 9 Jan 2014 17:42: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 cUNHAkL5YBaQ for ; Thu, 9 Jan 2014 17:42:43 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EBB1ADBD3 for ; Thu, 9 Jan 2014 17:42:42 -0800 (PST) Received: from ppp118-209-75-105.lns20.mel4.internode.on.net ([118.209.75.105]:57696 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W1R6m-0006qA-HB for clue@ietf.org; Fri, 10 Jan 2014 12:42:00 +1100 Message-ID: <52CF5004.7040309@nteczone.com> Date: Fri, 10 Jan 2014 12:42:28 +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: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@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] Advertising what is in an MCC - allow wildcard? 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, 10 Jan 2014 01:42:44 -0000 Hello Mark, Please see my comments below. Regards, Christian On 10/01/2014 9:11 AM, Duckworth, Mark wrote: > > In an advertisement, the provider can indicate which other captures > are referenced by an MCC, for example: > > Individual captures advertised: VC1, VC2, VC3, VC4, VC5 > > MCC1(VC1, VC2) > > This means MCC1 can include VC1 and/or VC2, but not the others. > > MCC2() > > Without any specific references, this means the provider is not saying > which other captures can be included in MCC2, and the consumer cannot > choose. > > I propose adding a wildcard: > > MCC3(*) > > This means MCC3 can include any of the other captures VC1 through VC5, > and the consumer can choose. > > For some types of MCUs, that want to give consumers the choice of > which specific captures to receive in an MCC, this is useful for large > advertisements with many media captures. When endpoints join or leave > a conference, causing the advertisement to change to add or remove > scenes and captures, the part of the advertisement with MCCs wouldnt > have to change at all. > > Related text from framework-13: > > From 7.2: The MCC may contain a reference to the Single Media > Captures (or) A MCC MAY contain no references to other Captures to > indicate that the MCC contains content from multiple sources but no > information regarding those sources is given. And in section 10 If > the MCC in the advertisement does not reference any individual > captures, then the Consumer cannot choose what is included in the MCC > > I propose adding text: > > The MCC may contain a wildcard reference, meaning it can refer to any > of the other captures in the advertisement. The consumer, in a > configure message, may choose which of the other media captures it > wishes to receive in the MCC. > > What do you think? > [CNG] I'm supportive of adding a wildcard mechanism. It could help shorten messages. I think we should be clear about what the scope of the wildcard is. i.e. is it the captures in the same scene as the MCC or across all scenes in the Advertisement. I think what may perhaps be additionally useful is to be able to provide a range, i.e. MCC4(VC2-VC4). However this would imply that captureIDs would have to have a numeric aspect. > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Thu Jan 9 17:46: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 221E31ADF5D for ; Thu, 9 Jan 2014 17:46: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 H81Bd086RF4N for ; Thu, 9 Jan 2014 17:46:42 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id B051D1ADF46 for ; Thu, 9 Jan 2014 17:46:42 -0800 (PST) Received: from ppp118-209-75-105.lns20.mel4.internode.on.net ([118.209.75.105]:57858 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W1RAe-0007cA-Fc for clue@ietf.org; Fri, 10 Jan 2014 12:46:00 +1100 Message-ID: <52CF50F4.9020001@nteczone.com> Date: Fri, 10 Jan 2014 12:46:28 +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: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC1BD@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC1BD@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] Should framework refer to RTP multiplexing and RTP mapping 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, 10 Jan 2014 01:46:44 -0000 Hello Mark, I think we could delete it. Multiplexing is a separate issue. What may be useful is to provide a reference/discussion to any work that would be done to link RTP to a particular capture (as mentioned in your other email). Regards, Christian On 10/01/2014 10:01 AM, Duckworth, Mark wrote: > > Im looking through all the open issues in the framework document. > This is one issue at the end of section 5: > > Edt. note (StW): what's written below is likely correct, but is not > the result of the introduction of CLUE, but rather the result of a > generational overhaul of RTP usage that would have happened with or > without CLUE. Suggest to delete the sentences below until begin of > section 6. Is having a CLUE RTP Mapping document still the plan? If > yes, we should have a real draft and a real reference. > > However, some form of RTP multiplexing is likely to be used by CLUE > devices. More information about relating RTP flows to CLUE entities is > in the CLUE RTP Mapping document. > > Does anybody have a suggestion about this? > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Thu Jan 9 18:19: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 31FDB1ADF73 for ; Thu, 9 Jan 2014 18:19:03 -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 7qExvePuf3uW for ; Thu, 9 Jan 2014 18:19:01 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864B01ADF65 for ; Thu, 9 Jan 2014 18:19:00 -0800 (PST) Received: from ppp118-209-75-105.lns20.mel4.internode.on.net ([118.209.75.105]:58379 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W1Rft-0003u5-Jc; Fri, 10 Jan 2014 13:18:17 +1100 Message-ID: <52CF5885.2090002@nteczone.com> Date: Fri, 10 Jan 2014 13:18:45 +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: "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> <52CB8BB9.70503@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E3E6@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E3E6@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] 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, 10 Jan 2014 02:19:03 -0000 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. <> ... 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 From pkyzivat@alum.mit.edu Fri Jan 10 10:24: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 423D41AE067 for ; Fri, 10 Jan 2014 10:24:39 -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 t3a1FcL4_CnR for ; Fri, 10 Jan 2014 10:24:37 -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 209661AE103 for ; Fri, 10 Jan 2014 10:24:36 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta14.westchester.pa.mail.comcast.net with comcast id CDhG1n0030mv7h05EJQSCA; Fri, 10 Jan 2014 18:24:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id CJQR1n00y3ZTu2S3XJQRF8; Fri, 10 Jan 2014 18:24:26 +0000 Message-ID: <52D03AD9.1070507@alum.mit.edu> Date: Fri, 10 Jan 2014 13:24:25 -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: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@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=1389378266; bh=g8I1w77IKFUHqdfl3CoaurwlsIea4L2rgkZZrBPJ90Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sUzV0npLerdur3YFRQI4d2Efg5/Z316pRLbIp1ZswOdKj3bSPrW52VD2bvOB7Ri1d 6rYymn/QqD5DytsnyTGZCElNouVnjRDNgequzCrkxFRV9hTYQXNnK5iDrPpXDx058h IBnq7og4x5nGb5AAqCE98H2zPJoqaFKE7/RfMXC8Wyg4whQHo92lzuqwjJRHp6Q0Pt rEFud3tPKDPTE/Ie9HTukaMbQw+MGcUqn4F0orGGmjWIUvVxRULdtCGjwAvmmnwB9l 6kQOWBFENdmzjWLkeZHY2uzXGZS+B7h0vDVVe4qqaVVOXGdB9cpE61/0O7X83BzTB1 cxI2Sci+wHTWA== Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? 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, 10 Jan 2014 18:24:39 -0000 On 1/9/14 5:11 PM, Duckworth, Mark wrote: > In an advertisement, the provider can indicate which other captures are > referenced by an MCC, for example: > > Individual captures advertised: VC1, VC2, VC3, VC4, VC5 > > MCC1(VC1, VC2) > > This means MCC1 can include VC1 and/or VC2, but not the others. > > MCC2() > > Without any specific references, this means the provider is not saying > which other captures can be included in MCC2, and the consumer cannot > choose. > > I propose adding a wildcard: > > MCC3(*) IIUC you mean this to be strictly a syntactic shortcut, not adding any functionality that isn't present without it. > This means MCC3 can include any of the other captures VC1 through VC5, > and the consumer can choose. Do you intent this to mean all the captures in the advertisement, or all the captures in the same scene? > For some types of MCUs, that want to give consumers the choice of which > specific captures to receive in an MCC, this is useful for large > advertisements with many media captures. Perhaps. But I have my doubts that this would be of common use in practice. So it becomes a question of whether the added implementation burden of supporting this optimization is justified for the number of cases when it would be of use. Thanks, Paul > When endpoints join or leave a > conference, causing the advertisement to change to add or remove scenes > and captures, the part of the advertisement with MCCs wouldnt have to > change at all. > > Related text from framework-13: > > From 7.2: The MCC may contain a reference to the Single Media > Captures (or) A MCC MAY contain no references to other Captures to > indicate that the MCC contains content from multiple sources but no > information regarding those sources is given. And in section 10 If > the MCC in the advertisement does not reference any individual captures, > then the Consumer cannot choose what is included in the MCC > > I propose adding text: > > The MCC may contain a wildcard reference, meaning it can refer to any of > the other captures in the advertisement. The consumer, in a configure > message, may choose which of the other media captures it wishes to > receive in the MCC. > > What do you think? > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Fri Jan 10 10:29: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 946F61AE037 for ; Fri, 10 Jan 2014 10:29:07 -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 fPuSCrxTayCF for ; Fri, 10 Jan 2014 10:29:03 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 873F41AE103 for ; Fri, 10 Jan 2014 10:29:03 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id l18so3545505wgh.35 for ; Fri, 10 Jan 2014 10:28:53 -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=f6IUhW7JAwGObqHATDoOpZh+8inHGFUOr3hdS/oJj6I=; b=0/bqQJkrKTyOF8CTeVxfpn6WvEJi0RkuKSEMG/AofFGZVTkY07BgBGXP0OZf/XRvpa DOxnO6cDssIrdy8O/Qre/xoR3vMKHHs2VckYTiA63HRgyY8hN7Nk8BzckjsV+ubFACe1 Gdu3z7DKIx0LF/SxBhXRZokmnYMyUhyI0siOYWeAsMRdpC60rRKI+YECRBOg218ypGJT Kz7fj15NimL3H5XQ/htIGfnfNsruiqJAUBeiY+QCRfrAeDLgZ6qar0jy+UwFFOISSh9a 9K5xOTDOn8ufZeOsiMfylWYL7bexX3nGXKX+etiIG9warUX99k9Yz+F1qJENYANJgOSu r4GA== MIME-Version: 1.0 X-Received: by 10.194.170.133 with SMTP id am5mr9964823wjc.42.1389378533208; Fri, 10 Jan 2014 10:28:53 -0800 (PST) Received: by 10.216.172.9 with HTTP; Fri, 10 Jan 2014 10:28:53 -0800 (PST) In-Reply-To: References: Date: Fri, 10 Jan 2014 12:28:53 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e0122e92eee379404efa1e535 Subject: Re: [clue] Doodle: Link for poll "CLUE WG f2f Interim meeting" May 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: Fri, 10 Jan 2014 18:29:07 -0000 --089e0122e92eee379404efa1e535 Content-Type: text/plain; charset=ISO-8859-1 HI all, Other RAI area WGs (e.g., RTCWEB) are considering interim meetings in a similar timeframe so the sooner we get the CLUE meeting date fixed, the easier it will be for them to arrange their meetings to not conflict with CLUE. Right now, it looks like May 28th and 29th are optima for our two day meeting. Although, it's possible that in order to accommodate other interims we might need to shift a day. And, perhaps, more importantly, there are several document authors/key contributors that have not yet responded. Thus, I would like to ask folks to respond to this poll no later than Friday, January 17th. The chairs will propose a draft agenda once we confirm the dates. Thanks, Mary. On Mon, Dec 23, 2013 at 4:16 PM, Mary Barnes wrote: > Hi all, > > As mentioned at IETF-88 and on the mailing list, we are considering a > face-to-face interim meeting in the mid-late May timeframe. The University > of Naples has graciously volunteered to host the meeting. > > I have setup a doodle to find an optimal time for CLUE WG contributors and > participants. There are some potential conflicts and there likely is no > perfect date for everyone. The poll is Yes-No-maybe, so please put 'No' > only if it's absolutely impossible for you to attend on that day. There is > a US holiday the Monday (May 26) of the last week of May and there is a > 3GPP meeting (May 19-23) and IMTC SuperOp (May 16-24) the week prior. > There is also a rumor of a potential RTCWEB (and MMUSIC) interims around > that same timeframe. In the past it hasn't been particularly valuable to > CLUE to try to co-locate as all the meetings don't fit in a single week AND > we have not gotten additional RTCWEB folks to attend the CLUE meeting when > they have been co-located. > > http://doodle.com/5c7rb9ac6e2tnwfk > > In order to allow folks to plan for the meeting, I suggest we close the > doodle on January 31st, 2014. > > Thanks, > Mary. > > --089e0122e92eee379404efa1e535 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI all,

Other RAI area WGs (e.g., RTCWE= B) are considering interim meetings in a similar timeframe so the sooner we= get the CLUE meeting date fixed, the easier it will be for them to arrange= their meetings to not conflict with CLUE. =A0Right now, it looks like May = 28th and 29th are optima for our two day meeting. =A0 Although, it's po= ssible that in order to accommodate other interims we might need to shift a= day. =A0 And, perhaps, more importantly, there are several document author= s/key contributors that have not yet responded. Thus, I would like to ask f= olks to respond to this poll no later than Friday, January 17th.

The chairs will propose a draft agenda once we confirm = the dates.

Thanks,
Mary.

On Mon, Dec 23, 2013 at 4:1= 6 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrot= e:
Hi all,
<= div class=3D"gmail_quote">
As mentioned at IETF-88 and on the mai= ling list, we are considering a face-to-face interim meeting in the mid-lat= e May timeframe. The University of Naples has graciously volunteered to hos= t the meeting.=A0

I have setu= p a doodle to find an optimal time for CLUE WG contributors and participant= s. =A0There are some potential conflicts and there likely is no perfect dat= e for everyone. =A0The poll is Yes-No-maybe, so please put 'No' onl= y if it's absolutely impossible for you to attend on that day. =A0There= is a US holiday the Monday (May 26) of the last week of May and there is a= 3GPP meeting =A0(May 19-23) =A0and=A0IMTC SuperOp (May 16-24) the week pri= or. =A0 There is also a rumor of a potential RTCWEB (and MMUSIC) interims a= round that same timeframe. =A0In the past it hasn't been particularly v= aluable to CLUE to try to co-locate as all the meetings don't fit in a = single week AND we have not gotten additional RTCWEB folks to attend the CL= UE meeting when they have been co-located. =A0 =A0

http:/= /doodle.com/5c7rb9ac6e2tnwfk

In order to allow folks to plan for th= e meeting, I suggest we close the doodle on January 31st, 2014. =A0=A0

Thanks,
Mary.=A0


--089e0122e92eee379404efa1e535-- From pkyzivat@alum.mit.edu Fri Jan 10 10:32: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 8543F1AE04C for ; Fri, 10 Jan 2014 10:32: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 LJrYReIs1rTc for ; Fri, 10 Jan 2014 10:32:54 -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 576D31AE037 for ; Fri, 10 Jan 2014 10:32:54 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id CEPa1n00327AodY53JYkAt; Fri, 10 Jan 2014 18:32:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id CJYk1n0023ZTu2S3fJYkbS; Fri, 10 Jan 2014 18:32:44 +0000 Message-ID: <52D03CCC.9050501@alum.mit.edu> Date: Fri, 10 Jan 2014 13:32:44 -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: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8EF07@CRPMBOXPRD07.polycom.com> <52CF4E39.3040908@nteczone.com> In-Reply-To: <52CF4E39.3040908@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=1389378764; bh=p1k/rOZDcEhXx9bIWjpAWvl4l11bd/ETq/egRhbcTyc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pwIPC4zpAvk2Z9FSdB0ebiiV0aOMVD7O51/b+2p1qtLaLpYOo9Zyd3gQ1pa7r61Ye O+TE5u4268Mss7DiU1nGj68tVAmlfgCsTiAqSJ6gDv15I3AE4FoZy73MP3hnNm9fe5 kaBjJlJdvt/yhx+jR0uxpD6fTVEPxQvewsuIwseFaZnCqxvcpwH7Hsjst/st/KnXR/ rkBbwDdLG+7vZNrKynyhiNzLEg1m648PUljZgH4cfrwckLZ8K5LLfyyhy8b5siv7v9 zi0PwgWtHbdFtA5cGyuTiyDb/N3PVQ2pCl+QDlpDrEQ/G0nD2Fs9LVL1lHDPDl6NyB 4PC1577DVOQgg== Subject: Re: [clue] MCC switching example 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, 10 Jan 2014 18:32:56 -0000 I pretty much agree with Christian on this. Specifically I think (1) is the preferred approach. Jonathan has frequently commented on the issues around dynamically arranging streams - that it may be more important to keep specific sources in a fixed location as long as they are displayed, rather than moving them around to get them into optimal relationships every time the speaker changes. Ultimately that is up to the client to decide, if it has the information to do so. The advertiser can't do as good a job because it lacks sufficient knowledge of the client's situation. I'm somewhat dubious that (3) will be very successful. But if an advertiser wants to do that it can. Thanks, Paul On 1/9/14 8:34 PM, Christian Groves wrote: > Hello Mark, > > Please see my comments below. > > Regards, Christian > > On 10/01/2014 6:23 AM, Duckworth, Mark wrote: >> >> In framework-13, there is a new example for MCC usage in section >> 12.3.3. I think the part about Capture Scene #8 is either incorrect >> or incomplete. This is supposed to describe how the MCU can advertise >> captures representing the non-current-talker endpoints, and allow the >> receiving endpoint to render them with proper spatial relationships. >> For example, I don't see any way for endpoint A (the receiving >> consumer endpoint) to be able to render captures from scene #8 that >> come from endpoint B (3 cameras) next to each other. There is no way >> for A to know at any point in time which MCCs contain VC4, VC5, and >> VC6 from endpoint B, so there is no way for A to render them next to >> each other. >> > [CNG] I agree that capture scene 8 doesn't describe what you want above. > However I believe that it is valid for describing what is intended i.e. > The MCU can also supply nine media streams showing the active and > previous eight speakers. Its displaying the captures of the active > speaker not the whole speaker site. The site switching aspect is > described in Capture Scene #7. > > I also agree that knowing exactly what capture is in the MCC capture > encoding at a particular point of time is an issue. > >> We discussed this general topic at IETF88, but didn't have much time >> on it. We can discuss again at the design team meeting on January 14 >> and the interim meeting. >> > [CNG] Unfortunately i'll be away for the Jan14 meeting. > >> See presentation >> http://tools.ietf.org/agenda/88/slides/slides-88-clue-5.pdf. >> >> Some possible approaches are (corresponding to 1-3 on page 15 from the >> presentation): >> >> 1. Use an advertisement like in the framework example, but also need >> to add ability for receiver to relate the original source of incoming >> capture encodings at the RTP level to the captures in the CLUE >> advertisement. >> >> 2. Use an advertisement like in the framework example, but the >> consumer selects the specific sources at any point in time by sending >> a configure message whenever it wants to change its selection. Need >> to add ability for the consumer to know about audio activity so it can >> use that to inform switching decisions. Maybe it can just come from >> audio streams sent from MCU to the consumer. Probably also want same >> ability to relate the incoming encodings to original captures as in >> item 1 above. >> >> 3. Use a different advertisement, breaking apart Capture Scene #8 into >> three separate scenes, where each scene has three MCCs with spatial >> information on the MCCs themselves. This would be three separate >> scenes practically the same as Scene #7, but with different policy >> values to indicate they are further down in the MCU's recent speaker >> list. The MCU is responsible for maintaining the advertised spatial >> relation between MCCs when it switches to different sources. >> >> I am most interested in option 2. But I think we can make all of them >> work in CLUE with some additions about relating incoming encodings to >> advertised captures. >> > [CNG] My feeling is that 1) would be the most robust general approach. > Knowing the source capture at the RTP would be faster and minimise any > sync issues between CLUE and RTP and the provider/consumer. I think a > pragmatic approach to the use case would be 3. >> >> I'd like to discuss this more before deciding if/how to update this >> example in the framework. >> >> 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 Mark.Duckworth@polycom.com Fri Jan 10 12:35: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 33C6E1AE134 for ; Fri, 10 Jan 2014 12:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 UGnGGY0Ui3mp for ; Fri, 10 Jan 2014 12:35:39 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4803F1AE02E for ; Fri, 10 Jan 2014 12:35:39 -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, 10 Jan 2014 12:35:29 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" , "Christian Groves (Christian.Groves@nteczone.com)" Date: Fri, 10 Jan 2014 12:35:27 -0800 Thread-Topic: [clue] MCC switching example Thread-Index: Ac8OMl7qFmKy01LsTeiN7WDihB7e4wADQpOg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4E1@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8EF07@CRPMBOXPRD07.polycom.com> <52CF4E39.3040908@nteczone.com> <52D03CCC.9050501@alum.mit.edu> In-Reply-To: <52D03CCC.9050501@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 switching example 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, 10 Jan 2014 20:35:42 -0000 I'm responding to both Paul and Christian, inline. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, January 10, 2014 1:33 PM > To: clue@ietf.org > Subject: Re: [clue] MCC switching example >=20 > I pretty much agree with Christian on this. > Specifically I think (1) is the preferred approach. >=20 > Jonathan has frequently commented on the issues around dynamically > arranging streams - that it may be more important to keep specific source= s in > a fixed location as long as they are displayed, rather than moving them > around to get them into optimal relationships every time the speaker > changes. Ultimately that is up to the client to decide, if it has the inf= ormation > to do so. The advertiser can't do as good a job because it lacks sufficie= nt > knowledge of the client's situation. [Duckworth, Mark] I agree, and that's why I prefer option (2). I'm concern= ed about option (1) because the consumer has to be prepared to handle strea= m switches (completely controlled by the provider) at any time. So the con= sumer can be receiving several MCCs, but the original capture contained in = the MCC can switch at any time. So at one moment VC4, VC5, VC6 can be in M= CC5, MCC6, MCC7. Then the next moment they can appear in MCC8, MCC9, MCC10= (just as an example). If the consumer wants to render them in the same sp= ot, it has to either re-map the incoming encodings to different decoders, o= r re-map decoder outputs to different locations in its local composition. = It seems to me this would be hard to do in practice, considering all the po= ssible permutations of how source captures can appear in the MCCs, and tryi= ng to do it in a nice clean way as it appears to the human user, without pa= uses or other disruptions in the rendering. [Duckworth, Mark] In general, with option (1), I think the consumer has eno= ugh information to know all the spatial relations of all the captures it is= receiving, but I'm concerned about trying to implement changing rendering = decisions quickly enough for a good user experience. [Duckworth, Mark] With option (2), the consumer is in control so it knows w= hat to expect in each MCC as switches occur, and it tailors it to its own n= eeds. > I'm somewhat dubious that (3) will be very successful. But if an advertis= er > wants to do that it can. >=20 > Thanks, > Paul >=20 >=20 >=20 > On 1/9/14 8:34 PM, Christian Groves wrote: > > Hello Mark, > > > > Please see my comments below. > > > > Regards, Christian > > > > On 10/01/2014 6:23 AM, Duckworth, Mark wrote: > >> > >> In framework-13, there is a new example for MCC usage in section > >> 12.3.3. I think the part about Capture Scene #8 is either incorrect > >> or incomplete. This is supposed to describe how the MCU can > >> advertise captures representing the non-current-talker endpoints, and > >> allow the receiving endpoint to render them with proper spatial > relationships. > >> For example, I don't see any way for endpoint A (the receiving > >> consumer endpoint) to be able to render captures from scene #8 that > >> come from endpoint B (3 cameras) next to each other. There is no way > >> for A to know at any point in time which MCCs contain VC4, VC5, and > >> VC6 from endpoint B, so there is no way for A to render them next to > >> each other. > >> > > [CNG] I agree that capture scene 8 doesn't describe what you want above= . > > However I believe that it is valid for describing what is intended i.e. > > The MCU can also supply nine media streams showing the active and > > previous eight speakers. Its displaying the captures of the active > > speaker not the whole speaker site. The site switching aspect is > > described in Capture Scene #7. [Duckworth, Mark] The framework example isn't clear enough in describing th= e use case for these 9 streams, so we have different assumptions about the = desired behavior. I'll propose something to make this more clear. > > I also agree that knowing exactly what capture is in the MCC capture > > encoding at a particular point of time is an issue. > > > >> We discussed this general topic at IETF88, but didn't have much time > >> on it. We can discuss again at the design team meeting on January 14 > >> and the interim meeting. > >> > > [CNG] Unfortunately i'll be away for the Jan14 meeting. > > > >> See presentation > >> http://tools.ietf.org/agenda/88/slides/slides-88-clue-5.pdf. > >> > >> Some possible approaches are (corresponding to 1-3 on page 15 from > >> the > >> presentation): > >> > >> 1. Use an advertisement like in the framework example, but also need > >> to add ability for receiver to relate the original source of incoming > >> capture encodings at the RTP level to the captures in the CLUE > >> advertisement. > >> > >> 2. Use an advertisement like in the framework example, but the > >> consumer selects the specific sources at any point in time by sending > >> a configure message whenever it wants to change its selection. Need > >> to add ability for the consumer to know about audio activity so it > >> can use that to inform switching decisions. Maybe it can just come > >> from audio streams sent from MCU to the consumer. Probably also want > >> same ability to relate the incoming encodings to original captures as > >> in item 1 above. > >> > >> 3. Use a different advertisement, breaking apart Capture Scene #8 > >> into three separate scenes, where each scene has three MCCs with > >> spatial information on the MCCs themselves. This would be three > >> separate scenes practically the same as Scene #7, but with different > >> policy values to indicate they are further down in the MCU's recent > >> speaker list. The MCU is responsible for maintaining the advertised > >> spatial relation between MCCs when it switches to different sources. > >> > >> I am most interested in option 2. But I think we can make all of > >> them work in CLUE with some additions about relating incoming > >> encodings to advertised captures. > >> > > [CNG] My feeling is that 1) would be the most robust general approach. > > Knowing the source capture at the RTP would be faster and minimise any > > sync issues between CLUE and RTP and the provider/consumer. I think a > > pragmatic approach to the use case would be 3. > >> > >> I'd like to discuss this more before deciding if/how to update this > >> example in the framework. > >> > >> 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 > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Fri Jan 10 12:38: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 97AA61AE145 for ; Fri, 10 Jan 2014 12:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 f3F7YcBEIA5V for ; Fri, 10 Jan 2014 12:38:41 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id AECE81AE124 for ; Fri, 10 Jan 2014 12:38:41 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 10 Jan 2014 12:38:32 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Fri, 10 Jan 2014 12:38:30 -0800 Thread-Topic: [clue] Advertising what is in an MCC - allow wildcard? Thread-Index: Ac8NpT/0TqtOoIINSVKcAna1nTRWMgAnlC9A Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4E5@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@CRPMBOXPRD07.polycom.com> <52CF5004.7040309@nteczone.com> In-Reply-To: <52CF5004.7040309@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] Advertising what is in an MCC - allow wildcard? 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, 10 Jan 2014 20:38:43 -0000 Christian, I intended the scope of the wildcard to refer to all other captures, not ju= st within the same scene. I'm against the range idea (MCC4(VC2-VC4)) because I think capture IDs shou= ld be just an identifier, without implying some ordered list. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Thursday, January 09, 2014 8:42 PM > To: clue@ietf.org > Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >=20 > Hello Mark, >=20 > Please see my comments below. >=20 > Regards, Christian >=20 > On 10/01/2014 9:11 AM, Duckworth, Mark wrote: > > > > In an advertisement, the provider can indicate which other captures > > are referenced by an MCC, for example: > > > > Individual captures advertised: VC1, VC2, VC3, VC4, VC5 > > > > MCC1(VC1, VC2) > > > > This means MCC1 can include VC1 and/or VC2, but not the others. > > > > MCC2() > > > > Without any specific references, this means the provider is not saying > > which other captures can be included in MCC2, and the consumer cannot > > choose. > > > > I propose adding a wildcard: > > > > MCC3(*) > > > > This means MCC3 can include any of the other captures VC1 through VC5, > > and the consumer can choose. > > >=20 > > For some types of MCUs, that want to give consumers the choice of > > which specific captures to receive in an MCC, this is useful for large > > advertisements with many media captures. When endpoints join or leave > > a conference, causing the advertisement to change to add or remove > > scenes and captures, the part of the advertisement with MCCs wouldn't > > have to change at all. > > > > Related text from framework-13: > > > > From 7.2: "The MCC may contain a reference to the Single Media > > Captures... (or) A MCC MAY contain no references to other Captures to > > indicate that the MCC contains content from multiple sources but no > > information regarding those sources is given." And in section 10 "If > > the MCC in the advertisement does not reference any individual > > captures, then the Consumer cannot choose what is included in the MCC" > > > > I propose adding text: > > > > The MCC may contain a wildcard reference, meaning it can refer to any > > of the other captures in the advertisement. The consumer, in a > > configure message, may choose which of the other media captures it > > wishes to receive in the MCC. > > > > What do you think? > > > [CNG] I'm supportive of adding a wildcard mechanism. It could help shorte= n > messages. I think we should be clear about what the scope of the wildcard= is. > i.e. is it the captures in the same scene as the MCC or across all scenes= in the > Advertisement. > I think what may perhaps be additionally useful is to be able to provide = a > range, i.e. MCC4(VC2-VC4). However this would imply that captureIDs would > have to have a numeric aspect. > > > > 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 Mark.Duckworth@polycom.com Fri Jan 10 12:47: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 AC7011AE11B for ; Fri, 10 Jan 2014 12:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 oJ0eUHF2jTQJ for ; Fri, 10 Jan 2014 12:46:58 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A41301AE116 for ; Fri, 10 Jan 2014 12:46:58 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 10 Jan 2014 12:46:48 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 10 Jan 2014 12:46:46 -0800 Thread-Topic: [clue] Advertising what is in an MCC - allow wildcard? Thread-Index: Ac8OMT6/Y62EZ4BeScOGk8uGhZnhCAAEsA9Q Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4F3@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@CRPMBOXPRD07.polycom.com> <52D03AD9.1070507@alum.mit.edu> In-Reply-To: <52D03AD9.1070507@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] Advertising what is in an MCC - allow wildcard? 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, 10 Jan 2014 20:47:00 -0000 Paul, Yes, I think the wildcard is just a syntax shortcut. One other impact that I was thinking of is if we decide to have partial upd= ates of advertisements then it removes the need to re-advertise any MCC(*) = captures when other captures change. Without wildcard, any other addition = or removal of a contributing capture means also re-advertising every MCC wi= th a new list of contributors. I think the wildcard fits very nicely with the switching scenario option (2= ) from the other discussion thread. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, January 10, 2014 1:24 PM > To: clue@ietf.org > Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >=20 > On 1/9/14 5:11 PM, Duckworth, Mark wrote: > > In an advertisement, the provider can indicate which other captures > > are referenced by an MCC, for example: > > > > Individual captures advertised: VC1, VC2, VC3, VC4, VC5 > > > > MCC1(VC1, VC2) > > > > This means MCC1 can include VC1 and/or VC2, but not the others. > > > > MCC2() > > > > Without any specific references, this means the provider is not saying > > which other captures can be included in MCC2, and the consumer cannot > > choose. > > > > I propose adding a wildcard: > > > > MCC3(*) >=20 > IIUC you mean this to be strictly a syntactic shortcut, not adding any > functionality that isn't present without it. >=20 > > This means MCC3 can include any of the other captures VC1 through VC5, > > and the consumer can choose. >=20 > Do you intent this to mean all the captures in the advertisement, or all = the > captures in the same scene? >=20 > > For some types of MCUs, that want to give consumers the choice of > > which specific captures to receive in an MCC, this is useful for large > > advertisements with many media captures. >=20 > Perhaps. But I have my doubts that this would be of common use in practic= e. >=20 > So it becomes a question of whether the added implementation burden of > supporting this optimization is justified for the number of cases when it > would be of use. >=20 > Thanks, > Paul >=20 > > When endpoints join or leave a > > conference, causing the advertisement to change to add or remove > > scenes and captures, the part of the advertisement with MCCs wouldn't > > have to change at all. > > > > Related text from framework-13: > > > > From 7.2: "The MCC may contain a reference to the Single Media > > Captures... (or) A MCC MAY contain no references to other Captures to > > indicate that the MCC contains content from multiple sources but no > > information regarding those sources is given." And in section 10 "If > > the MCC in the advertisement does not reference any individual > > captures, then the Consumer cannot choose what is included in the MCC" > > > > I propose adding text: > > > > The MCC may contain a wildcard reference, meaning it can refer to any > > of the other captures in the advertisement. The consumer, in a > > configure message, may choose which of the other media captures it > > wishes to receive in the MCC. > > > > What do you think? > > > > 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 Mark.Duckworth@polycom.com Fri Jan 10 13:04: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 6E73A1AE12A for ; Fri, 10 Jan 2014 13:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 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.538, 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 rTEsq7K7B17q for ; Fri, 10 Jan 2014 13:04:21 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 17F7C1AE0EF for ; Fri, 10 Jan 2014 13:04:21 -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, 10 Jan 2014 13:04:11 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Fri, 10 Jan 2014 13:04:08 -0800 Thread-Topic: [clue] spatial information can't describe video locations within composed MCC Thread-Index: Ac8NqlAb//5P5nelRROmoyeo7zMbeAAnMMNg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4FF@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> <52CB8BB9.70503@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E3E6@CRPMBOXPRD07.polycom.com> <52CF5885.2090002@nteczone.com> In-Reply-To: <52CF5885.2090002@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] 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, 10 Jan 2014 21:04:23 -0000 Thanks Christian, that is an improvement. But I'm still not convinced the = consumer can always tell when the spatial attributes are meaningful (even w= ithin a scene) for discerning how contributors to a composed MCC are arrang= ed 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 wi= thin > composed MCC >=20 > Hello Mark, >=20 > How about something like the following? >=20 > 7.2.1. MCC Attributes >=20 > 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. >=20 > < and/or to the MCC itself the Provider should be aware that spatial attrib= utes > 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 positioni= ng > 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.>> >=20 > ... >=20 > Regards, Christian >=20 > On 8/01/2014 12:18 AM, Duckworth, Mark wrote: > > Hello Christian, > > > > So there are only certain circumstances in which spatial information fo= r > 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 M= CC. > >>> > >>> 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. S= o > >>> 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 From Mark.Duckworth@polycom.com Mon Jan 13 06:04: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 CF4881AE16B for ; Mon, 13 Jan 2014 06:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 6tIA6IYgCoAb for ; Mon, 13 Jan 2014 06:04:00 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8D89F1AE115 for ; Mon, 13 Jan 2014 06:04:00 -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; Mon, 13 Jan 2014 06:03:49 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 13 Jan 2014 06:03:48 -0800 Thread-Topic: framework editor notes about RTP and SDP need to be resolved Thread-Index: Ac8QaDacLvPpbW5/QkGXaPyEKRvU+g== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC6B6@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_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC6B6CRPMBOXPRD07p_" MIME-Version: 1.0 Subject: [clue] framework editor notes about RTP and SDP need to be resolved 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, 13 Jan 2014 14:04:03 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC6B6CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable framework-13 has a couple editor notes about managing RTP channels, which I= think we can resolve by removing the potentially complex optimization idea= . >From section 5: "Numerous optimizations are possible, and are the implementer's choice. Fo= r example, it can be sensible to establish one or more initial media channe= ls during the initial offer/answer exchange, which would allow, for example= , for a fast startup of audio. Depending on the system design, it can be p= ossible to re-use this established channel for more advanced media negotiat= ed only by CLUE mechanisms, thereby avoiding further offer/answer exchanges= . Edt. note: The editors are not sure whether the mentioned overloading of es= tablished RTP channels using only CLUE messages is possible, or desired by = the WG. If it were, certainly there is need for specification work. One p= ossible issue: a Provider which thinks that it can switch, say, a audio cod= ec algorithm by CLUE only, talks to a Consumer which thinks that it has to = faithfully answer the Providers Advertisement through a Configure, but does= not dare setting up its internal resource until such time it has received = its authoritative O/A exchange. Working group input is solicited." >From section 10: "Edt. Note (StW): is the sentence below still correct? Even more advanced devices MAY choose to establish media streams without an= offer-answer exchange, for example by overloading existing 5 tuple connect= ions with the negotiated media." I think we have a better way to describe how CLUE protocol interacts with S= DP, details of which are in the signaling document. Section 4.4 of draft-k= yzivat-clue-signaling-05 describes how SDP media lines are associated (or n= ot) with a CLUE control channel. I think this means it is not possible to = use the same m-line both with and without CLUE, contradicting what is propo= sed in framework section 5. For framework section 10, I think the intent is to say CLUE advertisements = and configure messages don't necessarily require a new SDP offer/answer for= every CLUE message exchange. But the resulting encodings sent via RTP mus= t conform to the most recent SDP. Is this correct? If the group agrees with my interpretation, I will change the text in the f= ramework to be consistent with the signaling document. Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC6B6CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

framework-13 has= a couple editor notes about managing RTP channels, which I think we can re= solve by removing the potentially complex optimization idea.

=

 

From section= 5:

“Numerous optimizations are po= ssible, and are the implementer's choice.  For example, it can be sens= ible to establish one or more initial media channels during the initial off= er/answer exchange, which would allow, for example, for a fast startup of a= udio.  Depending on the system design, it can be possible to re-use th= is established channel for more advanced media negotiated only by CLUE mech= anisms, thereby avoiding further offer/answer exchanges.  <= /p>

Edt. note: The editors are not sure whether the men= tioned overloading of established RTP channels using only CLUE messages is = possible, or desired by the WG.  If it were, certainly there is need f= or specification work.  One possible issue: a Provider which thinks th= at it can switch, say, a audio codec algorithm by CLUE only, talks to a Con= sumer which thinks that it has to faithfully answer the Providers Advertise= ment through a Configure, but does not dare setting up its internal resourc= e until such time it has received its authoritative O/A exchange.  Wor= king group input is solicited.”

 

From section 10:

“Edt. Note (StW): is the sentence below still correc= t?

Even more advanced devices MAY choose= to establish media streams without an offer-answer exchange, for example b= y overloading existing 5 tuple connections with the negotiated media.”= ;

 

I think we have a better way to describe how CLUE protocol interacts wi= th SDP, details of which are in the signaling document.  Section 4.4 o= f draft-kyzivat-clue-signaling-05 describes how SDP media lines are associa= ted (or not) with a CLUE control channel.  I think this means it is no= t possible to use the same m-line both with and without CLUE, contradicting= what is proposed in framework section 5.

 

For framework section 10, I thi= nk the intent is to say CLUE advertisements and configure messages don̵= 7;t necessarily require a new SDP offer/answer for every CLUE message excha= nge.  But the resulting encodings sent via RTP must conform to the mos= t recent SDP.  Is this correct?

 

If the group agrees with my interpre= tation, I will change the text in the framework to be consistent with the s= ignaling document.

 

=

Mark

 

 

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDC6B6CRPMBOXPRD07p_-- From pkyzivat@alum.mit.edu Mon Jan 13 06:40: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 671811AE193 for ; Mon, 13 Jan 2014 06:40: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 9Tqo9x_xauDn for ; Mon, 13 Jan 2014 06:40:02 -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 4404E1AE09C for ; Mon, 13 Jan 2014 06:40:01 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id DQfk1n0031vXlb858Sfq5x; Mon, 13 Jan 2014 14:39:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id DSfq1n0033ZTu2S3dSfqwd; Mon, 13 Jan 2014 14:39:50 +0000 Message-ID: <52D3FAB6.8060000@alum.mit.edu> Date: Mon, 13 Jan 2014 09:39:50 -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: "Duckworth, Mark" , "clue@ietf.org" , "Christian Groves (Christian.Groves@nteczone.com)" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8EF07@CRPMBOXPRD07.polycom.com> <52CF4E39.3040908@nteczone.com> <52D03CCC.9050501@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4E1@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4E1@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=1389623990; bh=FsSbT3nRI1WdbQOtzoOGPzlehruj7Mb9XG73xQS0LBo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bmjx1BD6p2nQNCU3sKgKbTtI8VWGkB6N0POUU3KwteXWt/SHboLATni6teEgQbI3z DK0YxM3gCFeVFZecTeY8s9trNtuYC7VEJVTn+AcRRjc6lL07M9W30BkW2LciCrxwsY gZ2LcWn+AVYHFz5UAqXpbz1RtUmYKCIyGW53ERdZK5s6yblUIUqi3T/jFNtG76+wwD lbw195Qbw/7C76rEXJFIkdbWVHsYvI05X76gsnSqjX05Zr4h2uAYT9nMGuqrGfpIlX azky+nOAZJ8aiCHiaHrdO24VUjWn4T61vWnqCCtG0ST0x4EBJqBml1wYbN9+YyqcYB hI3REmVeA/VYA== Subject: Re: [clue] MCC switching example 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, 13 Jan 2014 14:40:04 -0000 On 1/10/14 3:35 PM, Duckworth, Mark wrote: > I'm responding to both Paul and Christian, inline. > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Friday, January 10, 2014 1:33 PM >> To: clue@ietf.org >> Subject: Re: [clue] MCC switching example >> >> I pretty much agree with Christian on this. >> Specifically I think (1) is the preferred approach. >> >> Jonathan has frequently commented on the issues around dynamically >> arranging streams - that it may be more important to keep specific sources in >> a fixed location as long as they are displayed, rather than moving them >> around to get them into optimal relationships every time the speaker >> changes. Ultimately that is up to the client to decide, if it has the information >> to do so. The advertiser can't do as good a job because it lacks sufficient >> knowledge of the client's situation. > > [Duckworth, Mark] I agree, and that's why I prefer option (2). I'm concerned about option (1) because the consumer has to be prepared to handle stream switches (completely controlled by the provider) at any time. So the consumer can be receiving several MCCs, but the original capture contained in the MCC can switch at any time. So at one moment VC4, VC5, VC6 can be in MCC5, MCC6, MCC7. Then the next moment they can appear in MCC8, MCC9, MCC10 (just as an example). If the consumer wants to render them in the same spot, it has to either re-map the incoming encodings to different decoders, or re-map decoder outputs to different locations in its local composition. It seems to me this would be hard to do in practice, considering all the possible permutations of how source captures can appear in the MCCs, and trying to do it in a nice clean way as it appears to the human user, without pauses or other disruptions in the rendering. > > [Duckworth, Mark] In general, with option (1), I think the consumer has enough information to know all the spatial relations of all the captures it is receiving, but I'm concerned about trying to implement changing rendering decisions quickly enough for a good user experience. > > [Duckworth, Mark] With option (2), the consumer is in control so it knows what to expect in each MCC as switches occur, and it tailors it to its own needs. I'd like to hear from Jonathan on this, but since he hasn't yet commented I'll try to channel him: Approach (2) is likely to have sufficient delays that when trying to get the "current speaker" video you are likely to end up with "previous speaker" video. (Note that I personally have no information to support this - it's hearsay.) Thanks, Paul >> I'm somewhat dubious that (3) will be very successful. But if an advertiser >> wants to do that it can. >> >> Thanks, >> Paul >> >> >> >> On 1/9/14 8:34 PM, Christian Groves wrote: >>> Hello Mark, >>> >>> Please see my comments below. >>> >>> Regards, Christian >>> >>> On 10/01/2014 6:23 AM, Duckworth, Mark wrote: >>>> >>>> In framework-13, there is a new example for MCC usage in section >>>> 12.3.3. I think the part about Capture Scene #8 is either incorrect >>>> or incomplete. This is supposed to describe how the MCU can >>>> advertise captures representing the non-current-talker endpoints, and >>>> allow the receiving endpoint to render them with proper spatial >> relationships. >>>> For example, I don't see any way for endpoint A (the receiving >>>> consumer endpoint) to be able to render captures from scene #8 that >>>> come from endpoint B (3 cameras) next to each other. There is no way >>>> for A to know at any point in time which MCCs contain VC4, VC5, and >>>> VC6 from endpoint B, so there is no way for A to render them next to >>>> each other. >>>> >>> [CNG] I agree that capture scene 8 doesn't describe what you want above. >>> However I believe that it is valid for describing what is intended i.e. >>> The MCU can also supply nine media streams showing the active and >>> previous eight speakers. Its displaying the captures of the active >>> speaker not the whole speaker site. The site switching aspect is >>> described in Capture Scene #7. > > [Duckworth, Mark] The framework example isn't clear enough in describing the use case for these 9 streams, so we have different assumptions about the desired behavior. I'll propose something to make this more clear. > >>> I also agree that knowing exactly what capture is in the MCC capture >>> encoding at a particular point of time is an issue. >>> >>>> We discussed this general topic at IETF88, but didn't have much time >>>> on it. We can discuss again at the design team meeting on January 14 >>>> and the interim meeting. >>>> >>> [CNG] Unfortunately i'll be away for the Jan14 meeting. >>> >>>> See presentation >>>> http://tools.ietf.org/agenda/88/slides/slides-88-clue-5.pdf. >>>> >>>> Some possible approaches are (corresponding to 1-3 on page 15 from >>>> the >>>> presentation): >>>> >>>> 1. Use an advertisement like in the framework example, but also need >>>> to add ability for receiver to relate the original source of incoming >>>> capture encodings at the RTP level to the captures in the CLUE >>>> advertisement. >>>> >>>> 2. Use an advertisement like in the framework example, but the >>>> consumer selects the specific sources at any point in time by sending >>>> a configure message whenever it wants to change its selection. Need >>>> to add ability for the consumer to know about audio activity so it >>>> can use that to inform switching decisions. Maybe it can just come >>>> from audio streams sent from MCU to the consumer. Probably also want >>>> same ability to relate the incoming encodings to original captures as >>>> in item 1 above. >>>> >>>> 3. Use a different advertisement, breaking apart Capture Scene #8 >>>> into three separate scenes, where each scene has three MCCs with >>>> spatial information on the MCCs themselves. This would be three >>>> separate scenes practically the same as Scene #7, but with different >>>> policy values to indicate they are further down in the MCU's recent >>>> speaker list. The MCU is responsible for maintaining the advertised >>>> spatial relation between MCCs when it switches to different sources. >>>> >>>> I am most interested in option 2. But I think we can make all of >>>> them work in CLUE with some additions about relating incoming >>>> encodings to advertised captures. >>>> >>> [CNG] My feeling is that 1) would be the most robust general approach. >>> Knowing the source capture at the RTP would be faster and minimise any >>> sync issues between CLUE and RTP and the provider/consumer. I think a >>> pragmatic approach to the use case would be 3. >>>> >>>> I'd like to discuss this more before deciding if/how to update this >>>> example in the framework. >>>> >>>> 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 > From pkyzivat@alum.mit.edu Mon Jan 13 09:32: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 403421ADE84 for ; Mon, 13 Jan 2014 09:32: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 Gg9S4h4c0OCg for ; Mon, 13 Jan 2014 09:32:10 -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 347591AC4A7 for ; Mon, 13 Jan 2014 09:32:10 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id DTP91n00116LCl053VXzKQ; Mon, 13 Jan 2014 17:31:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id DVXy1n00m3ZTu2S3SVXyjR; Mon, 13 Jan 2014 17:31:59 +0000 Message-ID: <52D4230E.4080208@alum.mit.edu> Date: Mon, 13 Jan 2014 12:31:58 -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 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=1389634319; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bEZ/WdyEzRlxTAE8EnGXsNJa1SwvWpDcBOeAyjd74nF6BY+fBFpWf54Mt+RwJmHqd p+Tjp3YsARRYoa6jQyF4gAMz3oMiB9bLiLLPK/oetlxG8Hq2dk/+o9PSagaAFFa9EH xZ2u68NohM2YM61osuEai0jP5hzCgNfpwwo8FqIwxW3iTXpKLnNQIJfjTgu3TrhNVP nVy5moemLW+tkJQEZUagSprPgs0z4ABdljZMHclL3oXrt3E/TqY8QNPlpEsTwwmJb0 L09vK6CBvzZA10mq1ixPkmsQ5XnRHjKEwJJlMbvXNim6aWjMM03rUTlrL3n5rcaWG5 XSGFLX0xSisKg== Subject: [clue] Reminder: Design team meeting tomorrow, Tues Jan 14: Framework open issues 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, 13 Jan 2014 17:32:11 -0000 From mary.ietf.barnes@gmail.com Mon Jan 13 09:53: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 61E7D1ADF83 for ; Mon, 13 Jan 2014 09:53:42 -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 SdqNWoKCu0pj for ; Mon, 13 Jan 2014 09:53:40 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 36C981ADF7F for ; Mon, 13 Jan 2014 09:53:40 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id w62so1701080wes.38 for ; Mon, 13 Jan 2014 09:53: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:cc:content-type; bh=TkFeAegy0+w0pwp0CHQj+Iziw1weDlTDztuW8Er9wQU=; b=UDKiuEbNiRIhewptP5qt0zmVAcllmGGT0aynJORFi2h5SSXYKI6lAmnpD0o9/rKT78 T9FxTW1Ohvq0PpU2VlxwrSgTHQSwVosyCWm+UM3uacEqnzwASVGEoNjp0L8ZDdHHtmG2 J1A73bm+7kZKllA0uiuzBc8H4Lm5vjW1/pcVAFo1oMuCGhJOvvsVFvoQx0+iaj+8AQJk GtIOy0dORzUjX0HlRKeBH1OQEr8AJrOVqLgPVUZRpQxeapY4RTX3EhlhIBAR+t5WNF56 VaBOZ1FiKB8Abi3iB1B0VcS3QAhTt8A1cJ0jvZ5AN6Wd6411tXYybf/XBbOWUu5k/d4Q dBaQ== MIME-Version: 1.0 X-Received: by 10.194.82.68 with SMTP id g4mr2558870wjy.85.1389635608615; Mon, 13 Jan 2014 09:53:28 -0800 (PST) Received: by 10.216.172.9 with HTTP; Mon, 13 Jan 2014 09:53:28 -0800 (PST) Date: Mon, 13 Jan 2014 11:53:28 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7bea41fed1a26c04efddc00d Subject: [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: Mon, 13 Jan 2014 17:53:42 -0000 --047d7bea41fed1a26c04efddc00d Content-Type: text/plain; charset=ISO-8859-1 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 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 SHOULD 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. 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. --047d7bea41fed1a26c04efddc00d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI all,

I've had the longstanding a= ction item to write some security text for the framework. Below is what i h= ave concocted. =A0Please review and post any comments/concerns to the list,= along with suggested text to address your comments/concerns. =A0

Mark will fold this into the next version of the framew= ork document.

Thanks,
Mary.=A0


=A0 =A0There are several potential atta= cks related to
=A0 =A0telepresence, and specifically the protocols used by CLUE,=A0
=A0 =A0in the case of conferencing sessions,=A0
=A0 =A0d= ue to the natural involvement of multiple endpoints
=A0 =A0and th= e many, often user-invoked, capabilities provided by the
=A0 =A0systems.=A0

=A0 =A0A middle box involv= ed in a CLUE session can experience=A0
=A0 =A0many of the same at= tacks as that of a conferencing system such=A0
=A0 =A0as that ena= bled by the XCON framework [RFC 6503].=A0
=A0 =A0Examples of attacks include the following: an
=A0 =A0= endpoint attempting to listen to sessions in which it is not
=A0 = =A0authorized to participate, an endpoint attempting to disconnect or
=
=A0 =A0mute other users, and theft of service by an endpoint in attemp= ting
=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 SHOULD be=A0
=A0 =A0followed. =A0= =A0

=A0 =A0One primary security concern, surrounding the CLUE framew= ork=A0
=A0 =A0introduced in this document, involves securing the = actual protocols
=A0 =A0and the associated authorization mechanis= ms. =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 =A0 =A0
=A0 =A0It might also be possible for an attacker to manipulate the inf= ormation and disrupt=A0
=A0 =A0the CLUE sessions. =A0It would als= o be possible to mount a DoS attack=A0
=A0 =A0on the CLUE endpoin= ts if a malicious agent has access to the data channel. =A0
=A0 =A0Thus, It MUST be possible for the endpoints to establish a chan= nel which is=A0
=A0 =A0secure against both message recovery and m= essage modification. Further details
=A0 =A0on this are provided = in the CLUE data channel solution document. =A0

=A0 =A0There are also security issues associated with t= he authorization to
=A0 =A0perform actions at the CLUE endpoints = to invoke specific
=A0 =A0capabilities (e.g., re-arranging screen= s, sharing content, etc.).
=A0 =A0However, the policies and security=A0
=A0 =A0associat= ed with these actions are outside the scope
=A0 =A0of this docume= nt and the overall CLUE solution. =A0

--047d7bea41fed1a26c04efddc00d-- From pkyzivat@alum.mit.edu Mon Jan 13 12:25: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 29D841AE09F for ; Mon, 13 Jan 2014 12:25: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 AA8sCGT7dwCt for ; Mon, 13 Jan 2014 12:25:06 -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 5029D1AE15A for ; Mon, 13 Jan 2014 12:25:05 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id DS9p1n0061vXlb858YQu0B; Mon, 13 Jan 2014 20:24:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id DYQt1n0113ZTu2S3dYQul7; Mon, 13 Jan 2014 20:24:54 +0000 Message-ID: <52D44B95.7080906@alum.mit.edu> Date: Mon, 13 Jan 2014 15:24:53 -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: 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=1389644694; bh=0IGIjB4NzbLZqXmffT/eGIvjNOkfswSYCVf8Mz1wHBc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AyvB8hpmpDqHg5XDOs6ixeNfixAfAXgqe+so0w4BbgQ5pcGojAIhmvrh+imbu6k7d i5+F17+ELYrmuu7lOaGjQZtT1hDOpcIiQyUDh/TSNBamewbg3abCs0HhZDfy9XPNyM 0ok9RXKXXljptU+BF93uKqqzx/h83lb6VD1RwOgqfHL9u0Rb3MyNKxrWe9Rg2/JgE2 ZUWY50QEb96jgQQnZi0tuNz4nJvXzUD8nfV/xc1ha92cawz4VBvCHqUJFGSDWNPaHS +5Dh/1fgjhfADC0GM4+7EEk5uU4bDEebSupvmzTF8mzXcis6QVXZf472CqQ6sW2iMf dmtmqC31XWDJw== 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: Mon, 13 Jan 2014 20:25:08 -0000 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 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 SHOULD 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. > 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 Tue Jan 14 05:13: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 3912A1AE0CA for ; Tue, 14 Jan 2014 05:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 5KBCLYaMJ-UD for ; Tue, 14 Jan 2014 05:13:28 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id D78E41AE0CD for ; Tue, 14 Jan 2014 05:13:27 -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; Tue, 14 Jan 2014 05:13:16 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 14 Jan 2014 05:13:13 -0800 Thread-Topic: Framework presentation for design team discussion today Thread-Index: Ac8RKk9wu4uEcCBbT/yyWE1Nei0zSQ== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDCB49@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_49E45C59CA48264997FEBFB29B6BC2D60C9CDDCB49CRPMBOXPRD07p_" MIME-Version: 1.0 Subject: [clue] Framework presentation for design team discussion today 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, 14 Jan 2014 13:13:29 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDCB49CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If anybody wants the presentation about framework issues, it is here: http://trac.tools.ietf.org/wg/clue/trac/raw-attachment/wiki/Design-Team/Fra= mework_Issues_140113.pptx Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDCB49CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If anybody wants= the presentation about framework issues, it is here:

http://trac.tools.ietf.org/wg/clue/trac/raw-attachment/wiki/D= esign-Team/Framework_Issues_140113.pptx

=  

Mark

<= /html>= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDCB49CRPMBOXPRD07p_-- From ron.even.tlv@gmail.com Tue Jan 14 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 DFAA51AE0E4 for ; Tue, 14 Jan 2014 07:11:04 -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_20=-0.001, 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 7uyaIOfH-ypq for ; Tue, 14 Jan 2014 07:11:01 -0800 (PST) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id A5EC81A1F3F for ; Tue, 14 Jan 2014 07:11:00 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so280749eei.35 for ; Tue, 14 Jan 2014 07:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=qrmyXdycMbK5zr4mvBvxJ5PfZEO6+0SwvGPur3sSm+I=; b=ntc2otbACPYL0/GL/hyW/CPLKrrFciJsNZU5RcNmxHRxVfDwQzNFvQGPWottzxkJVU mrzzoFAnZRQUkn//uEDm1aAkNIxOEDdtb7HUvcvDc98lEvi4Vmhe1FnOmrNNBJCWoH1C l2JjnAyaB8bGOYyhaUEIZFPwkbl5+JG8PY2wAE0Gaccp/HDjrE3SifQVKjnivCECjo2w PaN++U4dbpC4SWr4Xcaq12yzUafYe1jOReTgbv7d2BcbBRcrNAJbguapTlgS3LXicipN m7hbeyThNWQ9hoO+dagI58SmtrxYcfgQIAyZiQwjX2Rm7ymxm/eCVnlHSQ8ixCt6OlS/ 6YRA== X-Received: by 10.14.99.66 with SMTP id w42mr2702971eef.63.1389712248886; Tue, 14 Jan 2014 07:10:48 -0800 (PST) Received: from RoniE (bzq-79-176-217-208.red.bezeqint.net. [79.176.217.208]) by mx.google.com with ESMTPSA id a51sm2379265eeh.8.2014.01.14.07.10.45 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Jan 2014 07:10:48 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@CRPMBOXPRD07.polycom.com> Date: Tue, 14 Jan 2014 17:06:57 +0200 Message-ID: <129701cf113a$4bc74680$e355d380$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1298_01CF114B.0F50D9D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhyxlSMl6KiqDdhQublfuKUFhlX5re3fTA Content-Language: en-us Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? 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, 14 Jan 2014 15:11:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1298_01CF114B.0F50D9D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, What does the consumer do if he does not want to choose the composition but the MCC is with a wild card? Roni From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 10 January, 2014 12:12 AM To: clue@ietf.org Subject: [clue] Advertising what is in an MCC - allow wildcard? In an advertisement, the provider can indicate which other captures are referenced by an MCC, for example: Individual captures advertised: VC1, VC2, VC3, VC4, VC5 MCC1(VC1, VC2) This means MCC1 can include VC1 and/or VC2, but not the others. MCC2() Without any specific references, this means the provider is not saying which other captures can be included in MCC2, and the consumer cannot choose. I propose adding a wildcard: MCC3(*) This means MCC3 can include any of the other captures VC1 through VC5, and the consumer can choose. For some types of MCUs, that want to give consumers the choice of which specific captures to receive in an MCC, this is useful for large advertisements with many media captures. When endpoints join or leave a conference, causing the advertisement to change to add or remove scenes and captures, the part of the advertisement with MCCs wouldn't have to change at all. Related text from framework-13: >From 7.2: "The MCC may contain a reference to the Single Media Captures. (or) A MCC MAY contain no references to other Captures to indicate that the MCC contains content from multiple sources but no information regarding those sources is given." And in section 10 "If the MCC in the advertisement does not reference any individual captures, then the Consumer cannot choose what is included in the MCC" I propose adding text: The MCC may contain a wildcard reference, meaning it can refer to any of the other captures in the advertisement. The consumer, in a configure message, may choose which of the other media captures it wishes to receive in the MCC. What do you think? Mark ------=_NextPart_000_1298_01CF114B.0F50D9D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

What does the consumer = do if he does not want to choose the composition but the MCC is with a = wild card?

Roni

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, = Mark
Sent: 10 January, 2014 12:12 AM
To: = clue@ietf.org
Subject: [clue] Advertising what is in an MCC - = allow wildcard?

 

In an = advertisement, the provider can indicate which other captures are = referenced by an MCC, for example:

 

Individual = captures advertised: VC1, VC2, VC3, VC4, VC5

MCC1(VC1, VC2)

This = means MCC1 can include VC1 and/or VC2, but not the = others.

 

MCC2()

Without any = specific references, this means the provider is not saying which other = captures can be included in MCC2, and the consumer cannot = choose.

 

I propose adding a wildcard:

MCC3(*)

This means = MCC3 can include any of the other captures VC1 through VC5, and the = consumer can choose.

 

For some = types of MCUs, that want to give consumers the choice of which specific = captures to receive in an MCC, this is useful for large advertisements = with many media captures.  When endpoints join or leave a = conference, causing the advertisement to change to add or remove scenes = and captures, the part of the advertisement with MCCs wouldn’t = have to change at all.

 

Related text = from framework-13:

From 7.2: = “The MCC = may contain a reference to the Single Media Captures… (or) A MCC = MAY contain no references to other Captures to indicate that the MCC = contains content from multiple sources but no information regarding = those sources is given.”  And in section 10 = “If the = MCC in the advertisement does not reference any individual captures, = then the Consumer cannot choose what is included in the = MCC”

 

I propose = adding text:

The MCC may contain a = wildcard reference, meaning it can refer to any of the other captures in = the advertisement.  The consumer, in a configure message, may = choose which of the other media captures it wishes to receive in the = MCC.

 

What do you think?

 

Mark

------=_NextPart_000_1298_01CF114B.0F50D9D0-- From Mark.Duckworth@polycom.com Tue Jan 14 07:50: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 0DF921AE10E for ; Tue, 14 Jan 2014 07:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 DN_2OvYcoq4o for ; Tue, 14 Jan 2014 07:50:10 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B240E1AE0DF for ; Tue, 14 Jan 2014 07:50:10 -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, 14 Jan 2014 07:49:59 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 14 Jan 2014 07:49:58 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Tue, 14 Jan 2014 07:49:57 -0800 Thread-Topic: [clue] Advertising what is in an MCC - allow wildcard? Thread-Index: AQGhyxlSMl6KiqDdhQublfuKUFhlX5re3fTAgAALZ0A= Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDCC09@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@CRPMBOXPRD07.polycom.com> <129701cf113a$4bc74680$e355d380$@gmail.com> In-Reply-To: <129701cf113a$4bc74680$e355d380$@gmail.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_49E45C59CA48264997FEBFB29B6BC2D60C9CDDCC09CRPMBOXPRD07p_" MIME-Version: 1.0 Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? 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, 14 Jan 2014 15:50:13 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDCC09CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, The consumer, in a configure message, would just specify it wants an encodi= ng of the MCC without giving any further restrictions on what could be in t= he MCC. From framework section 10: "If it wants all the individual Capture= s then it returns only the MCC identity (i.e. MCC1)." This means the consum= er is asking for the MCC encoding, and the provider decides how to switch o= r compose the contributing MCs into the MCC. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, January 14, 2014 10:07 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Advertising what is in an MCC - allow wildcard? Hi, What does the consumer do if he does not want to choose the composition but= the MCC is with a wild card? Roni From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 10 January, 2014 12:12 AM To: clue@ietf.org Subject: [clue] Advertising what is in an MCC - allow wildcard? In an advertisement, the provider can indicate which other captures are ref= erenced by an MCC, for example: Individual captures advertised: VC1, VC2, VC3, VC4, VC5 MCC1(VC1, VC2) This means MCC1 can include VC1 and/or VC2, but not the others. MCC2() Without any specific references, this means the provider is not saying whic= h other captures can be included in MCC2, and the consumer cannot choose. I propose adding a wildcard: MCC3(*) This means MCC3 can include any of the other captures VC1 through VC5, and = the consumer can choose. For some types of MCUs, that want to give consumers the choice of which spe= cific captures to receive in an MCC, this is useful for large advertisement= s with many media captures. When endpoints join or leave a conference, cau= sing the advertisement to change to add or remove scenes and captures, the = part of the advertisement with MCCs wouldn't have to change at all. Related text from framework-13: >From 7.2: "The MCC may contain a reference to the Single Media Captures... = (or) A MCC MAY contain no references to other Captures to indicate that the= MCC contains content from multiple sources but no information regarding th= ose sources is given." And in section 10 "If the MCC in the advertisement = does not reference any individual captures, then the Consumer cannot choose= what is included in the MCC" I propose adding text: The MCC may contain a wildcard reference, meaning it can refer to any of th= e other captures in the advertisement. The consumer, in a configure messag= e, may choose which of the other media captures it wishes to receive in the= MCC. What do you think? Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDCC09CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

The consumer, in a configure message, would just specif= y it wants an encoding of the MCC without giving any further restrictions o= n what could be in the MCC.  From framework section 10: “= If it wants all the= individual Captures then it returns only the MCC identity (i.e. MCC1).” This means the consumer is asking = for the MCC encoding, and the provider decides how to switch or compose the= contributing MCs into the MCC.

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

Mark

 

From: Roni Even [mailto:ron.even.tlv@gmail.co= m]
Sent: Tuesday, January 14, 2014 10:07 AM
To: Duckwo= rth, Mark; clue@ietf.org
Subject: RE: [clue] Advertising what is = in an MCC - allow wildcard?

 

Hi,

What does the consumer do if he does not want to choose the compositio= n but the MCC is with a wild card?

Roni

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in'>

From: clue [mailto:clue-bounces@ietf.org] On = Behalf Of Duckworth, Mark
Sent: 10 January, 2014 12:12 AM
= To: clue@ietf.org
Subject: [clue] Advertising what is in a= n MCC - allow wildcard?

 

In an advertisement, the provi= der can indicate which other captures are referenced by an MCC, for example= :

 

Individual captures advertised: VC1, VC2, VC3, VC4, VC5

<= p class=3DMsoNormal>MCC1(VC1, VC2)

This = means MCC1 can include VC1 and/or VC2, but not the others.

 

MCC2()

Without any specific references, this means the= provider is not saying which other captures can be included in MCC2, and t= he consumer cannot choose.

 

I propose adding a wildcard:

MCC3(*)

This means MCC= 3 can include any of the other captures VC1 through VC5, and the consumer c= an choose.

 

For some types of MCUs, that want to give consumers the choice= of which specific captures to receive in an MCC, this is useful for large = advertisements with many media captures.  When endpoints join or leave= a conference, causing the advertisement to change to add or remove scenes = and captures, the part of the advertisement with MCCs wouldn’t have t= o change at all.

 

Related text from framework-13:

From 7.2: “The MCC may contain a reference to the Single Media CapturesR= 30; (or) A MCC MAY contain no references to other Captures to indicate that= the MCC contains content from multiple sources but no information regardin= g those sources is given.”  And in section 10 “If the MCC in the adver= tisement does not reference any individual captures, then the Consumer cann= ot choose what is included in the MCC”

 

I propose adding tex= t:

The MCC may contain a wildcard refere= nce, meaning it can refer to any of the other captures in the advertisement= .  The consumer, in a configure message, may choose which of the other= media captures it wishes to receive in the MCC.

 

What do you think?<= /o:p>

 

Mar= k

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CDDCC09CRPMBOXPRD07p_-- From pkyzivat@alum.mit.edu Tue Jan 14 08:12: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 DB3751AE133 for ; Tue, 14 Jan 2014 08:12: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 zDLeYC158jvr for ; Tue, 14 Jan 2014 08:12:43 -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 669C91AE0E3 for ; Tue, 14 Jan 2014 08:12:43 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta03.westchester.pa.mail.comcast.net with comcast id DrMr1n0040SCNGk53sCXar; Tue, 14 Jan 2014 16:12:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id DsCX1n00m3ZTu2S3VsCXy5; Tue, 14 Jan 2014 16:12:31 +0000 Message-ID: <52D561EF.2060102@alum.mit.edu> Date: Tue, 14 Jan 2014 11:12:31 -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 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=1389715951; bh=d+7OvXM8Cxym9nobJwJrUeHu1B+lY5lsrdUfMl6LzJw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hPDruwB+XldYBzrHhO3SAQSlB1mKIUt3AzH8FdiibBdU+QRYH/EDImS5fUPRD/Ozw eRIUduE8R9pVfvaehNct9mbpdAoXj55NgDXa5ojZk6tazjPUfjI7YhBW/E85qpjffn JKxjS6RXfrLC3TP36BD3/J1NyVY01SZcISadrh+bU5GGKRtGOfOHjN62ZPQLR+oJpx xyXSFt4OAinNt31yvS8EPTGZyb5lLwruu4VUNF+dc1PMd28GumbUfvgp9aaywzL1fJ dLTAxlIgP/XjYm+5+RLnUY9hDmE0C+74VKUO/ZMMEyrN5KC+12F1RWOMBd74pi1A/5 66K53RbCNPqag== Subject: [clue] Notes from design team meeting today 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, 14 Jan 2014 16:12:45 -0000 I posted preliminary minutes from the design team meeting today to the wiki, based on my own notes. These will be updated when notes from Rob and Mary are available, so take what is there now with a grain of salt. Rob - please send what notes you have. Thanks, Paul From internet-drafts@ietf.org Wed Jan 15 03:38: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 E0E351AE359; Wed, 15 Jan 2014 03:38:27 -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 s_42WEEKzOJs; Wed, 15 Jan 2014 03:38:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D22381AE343; Wed, 15 Jan 2014 03:38:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140115113825.20985.74276.idtracker@ietfa.amsl.com> Date: Wed, 15 Jan 2014 03:38:25 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-01.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, 15 Jan 2014 11:38:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-01.txt Pages : 45 Date : 2014-01-15 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-data-model-schema-01 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 pkyzivat@alum.mit.edu Wed Jan 15 11:20: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 B8DED1AE378 for ; Wed, 15 Jan 2014 11:20:38 -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 2LDpiG_juE2o for ; Wed, 15 Jan 2014 11:20:37 -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 A20AC1AE3F4 for ; Wed, 15 Jan 2014 11:20:37 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta02.westchester.pa.mail.comcast.net with comcast id ECxz1n0011YDfWL51KLR6H; Wed, 15 Jan 2014 19:20:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id EKLR1n00f3ZTu2S3gKLRLk; Wed, 15 Jan 2014 19:20:25 +0000 Message-ID: <52D6DF79.3000607@alum.mit.edu> Date: Wed, 15 Jan 2014 14:20:25 -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 References: <52D561EF.2060102@alum.mit.edu> In-Reply-To: <52D561EF.2060102@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=1389813625; bh=g0xWhbV3nOqBA0G5R2Rrxn6zTERCwL/89CI+8gSgtHo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ooI9LDUAGEbGlKofDMQvA+UHvj+ND+CUoAT89imDlJM4dZCpJqWRYTu1zpRN9SAT3 XYl4qrNQXy70QbDQld753HIWa9gRFFbfZABqoo60Pk/Ot0hDnxdqlYt/AaxmANAjei WUiyeU7SaoxFtztlVVLUS7V1D+nnKcRi3UT9apPXD1VEtBwcvX/i3JjHj+nMIUnfoz kj97o5k1kiCEN1LmiU61OBATOiRDL6CM9Cvxqf0kLJBtTZWTmi92tqiO5Z9DtaJrkz 6EsNk56Eexh422GmtEeLy9JDbsKJlKTxh317qMeU/pDok8LpwSK4yzrjvUDd5Bl6c9 lAbGv2ecuvJFg== Subject: Re: [clue] Notes from design team meeting today (yesterday) 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, 15 Jan 2014 19:20:38 -0000 Minutes now updated with Rob's notes, and a link to the recording. Paul On 1/14/14 11:12 AM, Paul Kyzivat wrote: > I posted preliminary minutes from the design team meeting today to the > wiki, based on my own notes. These will be updated when notes from Rob > and Mary are available, so take what is there now with a grain of salt. > > Rob - please send what notes you have. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Fri Jan 17 14:50: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 CB72A1ACCF8 for ; Fri, 17 Jan 2014 14:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.838 X-Spam-Level: X-Spam-Status: No, score=-0.838 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 MwyExH3-Wnpz for ; Fri, 17 Jan 2014 14:50:55 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7751AD6B9 for ; Fri, 17 Jan 2014 14:50:55 -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, 17 Jan 2014 14:50:42 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 17 Jan 2014 14:50:42 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 17 Jan 2014 14:50:39 -0800 Thread-Topic: [clue] spatial information can't describe video locations within composed MCC Thread-Index: Ac8NqlAb//5P5nelRROmoyeo7zMbeAAnMMNgAWO9LpA= Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF15FFC@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E278@CRPMBOXPRD07.polycom.com> <52CB8BB9.70503@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CC8E3E6@CRPMBOXPRD07.polycom.com> <52CF5885.2090002@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4FF@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4FF@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_49E45C59CA48264997FEBFB29B6BC2D60C9CF15FFCCRPMBOXPRD07p_" MIME-Version: 1.0 Subject: Re: [clue] 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, 17 Jan 2014 22:50:59 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF15FFCCRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We discussed this topic in the design team meeting Jan 14. Fr= om the minutes: "Conclusion 1: Spatial information of the individual captures does not appl= y inside a composed MCC." We wanted to bring this topic back to the list to make sure we have consens= us 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 wi= thin > composed MCC > > Thanks Christian, that is an improvement. But I'm still not convinced th= e > 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. > > > > < > 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 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF15FFCCRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We discussed = this topic in the design team meeting Jan 14.&n= bsp; From the minutes:

“Conclus= ion 1: Spatial information of the individual captures does not apply inside= a composed MCC.”

 

We wanted to bring this topic back to the l= ist to make sure we have consensus before clarifying the framework about th= is.  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@iet= f.org

> Subject: Re: [clue] spatial informati= on can't describe video locations within

> co= mposed MCC

>

>= Thanks Christian, that is an improvement.  But I'm still not convince= d the

> consumer can always tell when the spa= tial 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-----

<= p class=3DMsoPlainText>> > From: Christian Groves [mailto:Christian.G= roves@nteczone.com]

> > Sent: Thursday, Ja= nuary 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,

&g= t; >

> > How about something like the f= ollowing?

> >

&= gt; > 7.2.1. MCC Attributes

> >

> >     Attributes may be ass= ociated with the MCC instance and the Single

>= ; >     Media Captures that the MCC references. = ; A provider should avoid

> >  &= nbsp;  providing conflicting attribute values between the MCC and Sing= le

> >     Media Captu= res. Where there is conflict the attributes of the MCC

> >     override any that may be present i= n the individual captures.

> >

> >     <<When assigning sp= atial attributes to individual captures within

&= gt; > a MCC and/or to the MCC itself the Provider should be aware that

> > spatial attributes have no relation acr= oss Capture Scenes. Therefore

> > if the P= rovider 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 s= patial

> > positioning of the source Captu= re 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.>><= /p>

> >

> >&n= bsp;  ...

> >

> > Regards, Christian

> >

> > On 8/01/2014 12:18 AM, Duckworth, Mark wrot= e:

> > > 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<= /p>

> > think it is important and relevant, ca= n you please propose text for

> > the fram= ework 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 Beh= alf Of Christian

> > >> Groves

> > >> Sent: Tuesday, January 07, 2014 12= :08 AM

> > >> To: clue@ietf.org

<= p class=3DMsoPlainText>> > >> Subject: Re: [clue] spatial infor= mation can't describe video

> > >> l= ocations within composed MCC

> > >><= /p>

> > >> Hello Mark,

> > >>

> > >> = I agree with respect to the fact that spatial information isn't

> > >> valid across Capture Scenes. i.e. If I h= ave an MCC in one Cap.Scene

> > >> r= eferencing individual captures from other scenes. However I think

> > >> there is a valid case where an MCC can= reference Individual

> > >> capture= s 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=3DL= eft |

> > >> | VC2 | CapArea=3DRight= |

> > >> | MCC1(VC1, VC2) | |

> > >> +---------------------------------= ------------------------+

> > >> or<= /p>

> > >> +-----------------------+----= -----------------------------+

> > >>= ; | Capture Scene #1 | |

> > >> +---= --------------------|---------------------------------+

> > >> | MCC1(VC1) | CapArea=3DLeft |

> > >> | MCC2(VC2) | CapArea=3DRight |

> > >> | MCC1(MCC1,MCC2) | |

> > >> +-------------------------------------------------= --------+

> > >> where VC1 and VC2 a= re from different Capture Scenes.

> > >= >

> > >> There are of course case= s where the spatial information wouldn't be

>= > >> valid but in those cases the Provider wouldn't provide them,= i.e.

> > >> where the individual ca= ptures move. However there will be cases

> &g= t; >> where the composition is static and the information would be va= lid.

> > >> I don't think we can mak= e a general assumption that the spatial

> >= ; >> information is

> > valid or inv= alid in all cases.

> > >>

> > >> Regards, Christian

> > >>

> > >> On = 7/01/2014 7:54 AM, Duckworth, Mark wrote:

> &= gt; >>> Framework version 13 says a provider can use spatial infor= mation

> > >>> of source media ca= ptures 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 t= hat 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:

> > >&g= t;>

> > >>> For example: The s= patial related attributes can be further used to

> > >>> determine how the individual captures "appear&= quot; within a stream. A

> > >>> = virtual scene could be constructed for the MCC capture with two

> > >>> Video Captures with a "MaxCaptu= res" attribute set to 2 and an

> > &g= t;>> "Area of Capture" attribute provided with an overall a= rea. Each of

> > >>> the individu= al Captures could then also include an "Area of Capture"

> > >>> attribute with a sub-set of the o= verall area. The Consumer would

> > >&g= t;> then know the relative position of the content in the composed

> stream.

> > >= ;>>

> > >>> Here are some r= easons 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

> > >>> M= CC come from different scenes (source captures from multiple

> > >>> scenes, or source captures from differe= nt scenes than the MCC)

> > >>> t= hen the spatial information of one capture has no relation to the

> > >>> spatial information of another cap= ture.

> > >>>

> > >>> 2.In the example with MaxCaptures =3D 2, tha= t 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 sou= rce

> > >>> 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 provi= der 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. T= his would change over time, so

> > >>= ;> again the spatial information wouldn't always indicate the

> > >>> location of the source within the M= CC.

> > >>>

> > >>> 4.Take a slightly different example, where the= MCC contains 4

> > >>> contribut= ing individual captures, but still with MaxCaptures =3D 2.

> > >>> So the resulting MCC again will change ov= er time, as the provider

> > >>> = is free to choose which 2 out of the 4 to include at any time. So

> > >>> again the spatial information woul= dn't always indicate the

> > >>> = location of the source within the MCC.

> >= >>>

> > >>> Regards,

> > >>>

= > > >>> Mark

> > >>&g= t;

> > >>>

> > >>>

> > >>&g= t; _______________________________________________

> > >>> clue mailing list

>= > >>> clue@ietf.org

> > >>> https://ww= w.ietf.org/mailman/listinfo/clue

>= > >> _______________________________________________

> > >> clue mailing list

> > >> clue@ietf.org

> > >> https://w= ww.ietf.org/mailman/listinfo/clue

>= ;

> ________________________________________= _______

> clue mailing list

> clue@ietf.org

> https://www.ietf.org/mailman/lis= tinfo/clue

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF15FFCCRPMBOXPRD07p_-- From Mark.Duckworth@polycom.com Fri Jan 17 14:57: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 CFCA61ACCF8 for ; Fri, 17 Jan 2014 14:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 cFRUuk9xHSEN for ; Fri, 17 Jan 2014 14:57:49 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 68CA91ACCEC for ; Fri, 17 Jan 2014 14:57:49 -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, 17 Jan 2014 14:57:37 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 17 Jan 2014 14:57:35 -0800 Thread-Topic: should be optional Thread-Index: Ac8T1x8cjiNNZ7tCSKCcHuNOSO9CRQ== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16009@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_49E45C59CA48264997FEBFB29B6BC2D60C9CF16009CRPMBOXPRD07p_" MIME-Version: 1.0 Subject: [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, 17 Jan 2014 22:57:51 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF16009CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the data model section 10.4, in "spatialInformationType", the "capturePo= int" element is mandatory. It really should be optional. In earlier versi= ons 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 no= t assume anything about the spatial location of the capturing device." So I think the schema should have minOccurs=3D"0" for "capturePoint" elemen= t. And the text right below the schema part should say optional instead of= mandatory. Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF16009CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the data mode= l section 10.4, in “spatialInformationType”, the “capture= Point” element is mandatory.  It really should be optional. = ; In earlier versions of the framework it was optional.  This is descr= ibed 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 o= f the capturing device.”

&nbs= p;

So I think the schema should have minOccur= s=3D”0” for “capturePoint” element.  And the t= ext right below the schema part should say optional instead of mandatory.

 

Mark

 

= = --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF16009CRPMBOXPRD07p_-- From Mark.Duckworth@polycom.com Fri Jan 17 15:02: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 355E61ACCF8 for ; Fri, 17 Jan 2014 15:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 X9FUkOY1BLHl for ; Fri, 17 Jan 2014 15:02:24 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 50F871ACCEC for ; Fri, 17 Jan 2014 15:02:24 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Fri, 17 Jan 2014 15:02:11 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 17 Jan 2014 15:02:10 -0800 Thread-Topic: Design team discussion Jan 21? Thread-Index: Ac8T1+R7z7syR9G8TJ6tkwhsTEv46Q== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF1600B@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_49E45C59CA48264997FEBFB29B6BC2D60C9CF1600BCRPMBOXPRD07p_" MIME-Version: 1.0 Subject: [clue] Design team discussion Jan 21? 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, 17 Jan 2014 23:02:26 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF1600BCRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The wiki says no meeting on Jan 21. I'd like to continue the framework issues discussion, p= articularly the media switching example with MCCs and spatial information, = if people are available on Jan 21. Can we schedule a meeting for next week= ? Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF1600BCRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The wiki says no meeti= ng on Jan 21.  I’d like to continue the framework issues dis= cussion, particularly the media switching example with MCCs and spatial inf= ormation, if people are available on Jan 21.  Can we schedule a meetin= g for next week?

 

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF1600BCRPMBOXPRD07p_-- From Mark.Duckworth@polycom.com Fri Jan 17 15:12: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 6D5311ACCEC for ; Fri, 17 Jan 2014 15:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 Uu5XZcJ8Jsca for ; Fri, 17 Jan 2014 15:12:35 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id E11611ACCE6 for ; Fri, 17 Jan 2014 15:12:34 -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, 17 Jan 2014 15:12:22 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 17 Jan 2014 15:12:22 -0800 From: "Duckworth, Mark" To: "Duckworth, Mark" , Paul Kyzivat , "clue@ietf.org" Date: Fri, 17 Jan 2014 15:12:19 -0800 Thread-Topic: MCC grouping label - RE: [clue] Advertising what is in an MCC - allow wildcard? Thread-Index: Ac8T2TOGt2GvD7azTYWVdbsBH/Ll5g== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@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: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 17 Jan 2014 23:12:37 -0000 We discussed this topic in the Jan 14 design team meeting. The group had i= nterest in the concept, but not my specific proposal. Jonathan had an inte= resting idea, which I think better serves the purpose. =20 Instead of the MCC referring specifically to other media captures that can = be contained within the MCC, the MCC can refer to zero or more "MCC groupin= g labels". Any other media capture can include an attribute (zero or more)= with a particular MCC grouping label. The meaning is that any MC that has= the same grouping label that is reference by an MCC can be included in tha= t MCC. I think this doesn't change at all the meaning of MCC, but it will affect t= he syntax of how we describe it in the data model for CLUE messages. If the group agrees with this concept, I can propose specific changes to th= e framework. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark > Sent: Friday, January 10, 2014 3:47 PM > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >=20 > Paul, >=20 > Yes, I think the wildcard is just a syntax shortcut. > One other impact that I was thinking of is if we decide to have partial u= pdates > of advertisements then it removes the need to re-advertise any MCC(*) > captures when other captures change. Without wildcard, any other additio= n > or removal of a contributing capture means also re-advertising every MCC > with a new list of contributors. > I think the wildcard fits very nicely with the switching scenario option = (2) from > the other discussion thread. >=20 > Mark >=20 > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Friday, January 10, 2014 1:24 PM > > To: clue@ietf.org > > Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? > > > > On 1/9/14 5:11 PM, Duckworth, Mark wrote: > > > In an advertisement, the provider can indicate which other captures > > > are referenced by an MCC, for example: > > > > > > Individual captures advertised: VC1, VC2, VC3, VC4, VC5 > > > > > > MCC1(VC1, VC2) > > > > > > This means MCC1 can include VC1 and/or VC2, but not the others. > > > > > > MCC2() > > > > > > Without any specific references, this means the provider is not > > > saying which other captures can be included in MCC2, and the > > > consumer cannot choose. > > > > > > I propose adding a wildcard: > > > > > > MCC3(*) > > > > IIUC you mean this to be strictly a syntactic shortcut, not adding any > > functionality that isn't present without it. > > > > > This means MCC3 can include any of the other captures VC1 through > > > VC5, and the consumer can choose. > > > > Do you intent this to mean all the captures in the advertisement, or > > all the captures in the same scene? > > > > > For some types of MCUs, that want to give consumers the choice of > > > which specific captures to receive in an MCC, this is useful for > > > large advertisements with many media captures. > > > > Perhaps. But I have my doubts that this would be of common use in > practice. > > > > So it becomes a question of whether the added implementation burden of > > supporting this optimization is justified for the number of cases when > > it would be of use. > > > > Thanks, > > Paul > > > > > When endpoints join or leave a > > > conference, causing the advertisement to change to add or remove > > > scenes and captures, the part of the advertisement with MCCs > > > wouldn't have to change at all. > > > > > > Related text from framework-13: > > > > > > From 7.2: "The MCC may contain a reference to the Single Media > > > Captures... (or) A MCC MAY contain no references to other Captures > > > to indicate that the MCC contains content from multiple sources but > > > no information regarding those sources is given." And in section 10 > > > "If the MCC in the advertisement does not reference any individual > > > captures, then the Consumer cannot choose what is included in the MCC= " > > > > > > I propose adding text: > > > > > > The MCC may contain a wildcard reference, meaning it can refer to > > > any of the other captures in the advertisement. The consumer, in a > > > configure message, may choose which of the other media captures it > > > wishes to receive in the MCC. > > > > > > What do you think? > > > > > > 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 mary.ietf.barnes@gmail.com Fri Jan 17 15:35: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 516F31ACCF8 for ; Fri, 17 Jan 2014 15:35:53 -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 N4fNXr4jwEHD for ; Fri, 17 Jan 2014 15:35:51 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBA41ACCEC for ; Fri, 17 Jan 2014 15:35:50 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id l18so5154350wgh.5 for ; Fri, 17 Jan 2014 15:35:38 -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=Ah2bBoPTc+c2zjYNx5pDsMRQSfn2IJjoBBMo42RSiJk=; b=YQAfIKZ7ZmoWyswPZQB5JfZuMeNyHUeGC/ifXMbRSf+nuHh6mYqHuoYbu9dELdl7cb begXinaCrnvloPfVMt19ahFLS+HaLs8+3r6MDOYsYWgBmIuWssYCsusfnotnRSwz3DPQ bnEs4EVx5M/4+ltc+cvn3f3AD7kCE6YxlMGfZiwPDS/v1LXpKMddrCgY4Z7bHTmmjOk2 hJgZtuCy4nj2b8KCgLpX7bf2ZdSjx9HrEB4BMYD0THCIevQgTMNqIbN9aiG8aaNkhSfT oJYJ4fRzo9/xundnGe6DwUVkubkFZ+eGmCn4UII/9+whjGsuJa+xVDSJ1w4z+sVwD2V8 sCcg== MIME-Version: 1.0 X-Received: by 10.180.184.105 with SMTP id et9mr645822wic.36.1390001738156; Fri, 17 Jan 2014 15:35:38 -0800 (PST) Received: by 10.216.172.9 with HTTP; Fri, 17 Jan 2014 15:35:38 -0800 (PST) In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF1600B@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF1600B@CRPMBOXPRD07.polycom.com> Date: Fri, 17 Jan 2014 17:35:38 -0600 Message-ID: From: Mary Barnes To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=001a11c228a2d7110404f032ff83 Cc: "clue@ietf.org" Subject: Re: [clue] Design team discussion Jan 21? 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, 17 Jan 2014 23:35:53 -0000 --001a11c228a2d7110404f032ff83 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, sorry, the chairs should have updated the wiki and sent a note. I've done the former and I guess I'm now doing the latter. Thanks, Mary. On Fri, Jan 17, 2014 at 5:02 PM, Duckworth, Mark wrote: > The wiki says no meeting on Jan 21. > I=92d like to continue the framework issues discussion, particularly the > media switching example with MCCs and spatial information, if people are > available on Jan 21. Can we schedule a meeting for next week? > > > > Mark > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --001a11c228a2d7110404f032ff83 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Yes, sorry, the chairs should have updated the wiki and se= nt a note. =A0I've done the former and I guess I'm now doing the la= tter.

Thanks,
Mary.


On Fri, Jan 17, 2014 at 5:02 PM, Duckwor= th, Mark <Mark.Duckworth@polycom.com> wrote:

The wiki says no meeting on Jan 21.=A0 I=92d like to co= ntinue the framework issues discussion, particularly the media switching ex= ample with MCCs and spatial information, if people are available on Jan 21.= =A0 Can we schedule a meeting for next week?

=A0

Mark

=

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


--001a11c228a2d7110404f032ff83-- From Mark.Duckworth@polycom.com Fri Jan 17 15:44: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 535111AD190 for ; Fri, 17 Jan 2014 15:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 IFss6exIvat8 for ; Fri, 17 Jan 2014 15:44:51 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2454B1ACCF8 for ; Fri, 17 Jan 2014 15:44:51 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Fri, 17 Jan 2014 15:44:24 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 17 Jan 2014 15:44:21 -0800 Thread-Topic: multipoint switching, MCC, and spatial information Thread-Index: Ac8T2t4BtFGDnaLPSz+s6O1s0/7kcw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@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_49E45C59CA48264997FEBFB29B6BC2D60C9CF16026CRPMBOXPRD07p_" MIME-Version: 1.0 Subject: [clue] multipoint switching, MCC, and spatial 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, 17 Jan 2014 23:44:54 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF16026CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is follow-up to the topic "[clue] MCC switching example", and to the d= esign team discussion Jan 14. I'm interested in what others have to say ab= out how approach #1 should work, regarding spatial information and the cons= umer's ability to render streams together that belong together. Referring to my framework issue slides, pages 8 = - 12. The group had interest mainly in approach #1, where the MCU makes al= l the switching decisions. But we didn't have a common understanding about= how spatial information was to be conveyed, so the consumer can render mul= tiple streams together when they are spatially related. On slide 9, for approach 1, it says "MCCs don't have spatial attributes". = But other people in the discussion thought the MCCs should have spatial att= ributes. Jonathan said the MCCs could have spatial information like this (= Jonathan, correct me if I don't remember right): MCC1, MCC2, MCC3: left, center, and right of the full scene, like the image= on page 6 for VC1-3. MCC4, MCC5, MCC6: spatial information that indicates they are located on bo= ttom part of MCC1, and much smaller than MCC1, like on page 6 for VC4-6. MCC7, MCC8, MCC9: spatial information that indicates they are located on bo= ttom part of MCC2, and much smaller than MCC2, like on page 6 for VC7-9. While this should work for that specific case, I don't think it works for t= he very similar case in framework section 12.3.3 which has these two altern= ative rendering layouts for the same streams (use mono-spaced font to see t= his): +---+---+---+ +-------------+ +-------------+ +-------------+ | | | | | | | | | | +---+---+---+ | | | | | | | | | | | | | | | | +---+---+---+ | | | | | | | | | | | | | | | | +---+---+---+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ | | | | | | | | | | | | | | | | | | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | +-------------+ +-------------+ +-------------+ If we generalize this approach to support alternatives like this, I think w= e end up with approach number 3 instead of approach 1. We also talked about the consumer should have the ability to associate inco= ming encoded packet streams with a particular individual MC from the advert= isement. This would give the consumer the spatial information of the parti= cular MC currently switched in to the MCC. My concern about this way of ge= tting spatial information is that it means the renderer has to re-map decod= er output to different display locations on the fly without any advance not= ice. Regards, Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF16026CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is follow-up to the topic “[clue] MCC = switching example”, and to the design team discussion Jan 14.  I= ’m interested in what others have to say about how approach #1 should= work, regarding spatial information and the consumer’s ability to re= nder streams together that belong together.

 

Refe= rring to my framework issue slides, pages 8 – 12.  The group had interest mainly in approach #1, = where the MCU makes all the switching decisions.  But we didn’t = have a common understanding about how spatial information was to be conveye= d, so the consumer can render multiple streams together when they are spati= ally related.

 

On slide 9, for approach 1, it says = “MCCs don’t have spatial attributes”.  But other peo= ple in the discussion thought the MCCs should have spatial attributes. = ; Jonathan said the MCCs could have spatial information like this (Jonathan= , correct me if I don’t remember right):

MCC1, MCC2, MCC3: l= eft, center, and right of the full scene, like the image on page 6 for VC1-= 3.

MCC4, MCC5, MCC6: spatial information that indicates they are l= ocated on bottom part of MCC1, and much smaller than MCC1, like on page 6 f= or VC4-6.

MCC7, MCC8, MCC9: spatial information that indicates the= y are located on bottom part of MCC2, and much smaller than MCC2, like on p= age 6 for VC7-9.

 

= While this should work for that s= pecific case, I don’t think it works for the very similar case in fra= mework section 12.3.3 which has these two alternative rendering layouts for= the same streams (use mono-spaced font to see this):

=

 <= /o:p>

   +---+---+---+ +---= ----------+ +-------------+ +-------------+

   |   |   |   = | |            = | |            = ; | |           &nbs= p; |

   +---+---= +---+ |           &n= bsp; | |           &= nbsp; | |           =   |

   |&nb= sp;  |   |   | |     &nbs= p;       | |     &nb= sp;       | |     &n= bsp;       |

   +---+---+---+ |     =         | |     = ;        | |    &nbs= p;        |

   |   |   |  = | |            = ; | |           &nbs= p; | |           &nb= sp; |

   +---+--= -+---+ +-------------+ +-------------+ +-------------+

 =

  +----------= ---+ +-------------+ +-------------+

  |       = ;      | |      &nbs= p;      | |      &nb= sp;      |

  |        &nb= sp;    | |        &n= bsp;    | |        &= nbsp;    |

=   |          &= nbsp;  | |          =    | |          = ;   |

 &nb= sp;| +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ |

  | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+= +-+ +-+ |

  +-= ------------+ +-------------+ +-------------+

 

If w= e generalize this approach to support alternatives like this, I think we en= d up with approach number 3 instead of approach 1.

 

We also talked about the consumer should have the ability to associate inc= oming encoded packet streams with a particular individual MC from the adver= tisement.  This would give the consumer the spatial information of the= particular MC currently switched in to the MCC.  My concern about thi= s way of getting spatial information is that it means the renderer has to r= e-map decoder output to different display locations on the fly without any = advance notice.

 

<= span style=3D'font-family:"Courier New"'>Regards,

Mark<= /span>

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF16026CRPMBOXPRD07p_-- From christer.holmberg@ericsson.com Fri Jan 17 23:36: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 91C251A1F62 for ; Fri, 17 Jan 2014 23:36:01 -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 thgkeBWHFLMx for ; Fri, 17 Jan 2014 23:35:59 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3271A1F56 for ; Fri, 17 Jan 2014 23:35:58 -0800 (PST) X-AuditID: c1b4fb32-b7f2b8e0000073bf-74-52da2ed0a67f Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 46.1E.29631.0DE2AD25; Sat, 18 Jan 2014 08:35:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Sat, 18 Jan 2014 08:35:44 +0100 From: Christer Holmberg To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: multipoint switching, MCC, and spatial information Thread-Index: Ac8T2t4BtFGDnaLPSz+s6O1s0/7kcwARPLuA Date: Sat, 18 Jan 2014 07:35:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D104C66@ESESSMB209.ericsson.se> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D104C66ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvje4FvVtBBkdfaFnsP3WZ2WLdkafM DkweS5b8ZPJ48UApgCmKyyYlNSezLLVI3y6BK2PlpYyC3Q2MFW2n1rA0MF7N72Lk5JAQMJH4 +OQhM4QtJnHh3nq2LkYuDiGBE4wSk7ZMYYFwljBK3H83GyjDwcEmYCHR/U8bpEFEIFRi9cxN LCC2sIC9xLxz85hASkQEHCS+PqmAKDGSWHdlKROIzSKgKnHp1yOwXbwCvhI/umYxgpQLCQRK 9PwKBglzCgRJ3Jt5hRHEZgQ65/upNWCtzALiEh8OXoc6U0BiyZ7zULaoxMvH/1ghbCWJFdsv MULU50usPLKACWKVoMTJmU9YJjCKzEIyahaSsllIyiDiehI3pk5hg7C1JZYtfA1Vrysx498h FmTxBYzsqxgli1OLi3PTjQz0ctNzS/RSizKTi4vz8/SKUzcxAiPr4JbfRjsYT+6xP8QozcGi JM57nbUmSEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjfKdfP6aIOPR/M9w/9f0DL/f475f6 6hjy5T8p8jWL7PLlDOF25Tinypuv38l8gsugY6f0wjP7TF04s58qntBZfmvVatszW++a/lev 3riMz6m+XCth3pJnPxm4l7Rf9TZYarfbXfsP18o3E/4eXxNVKZW55cfpiokZa1t+HeZ/4r71 fpQvU5iPEktxRqKhFnNRcSIAutZitXoCAAA= Subject: Re: [clue] multipoint switching, MCC, and spatial 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: Sat, 18 Jan 2014 07:36:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D104C66ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm in China, but I'd call in if my schedule permits. Regards, Christer L=E4hett=E4j=E4: clue [mailto:clue-bounces@ietf.org] Puolesta Duckworth, Ma= rk L=E4hetetty: 18. tammikuuta 2014 1:44 Vastaanottaja: clue@ietf.org Aihe: [clue] multipoint switching, MCC, and spatial information This is follow-up to the topic "[clue] MCC switching example", and to the d= esign team discussion Jan 14. I'm interested in what others have to say ab= out how approach #1 should work, regarding spatial information and the cons= umer's ability to render streams together that belong together. Referring to my framework issue slides, pages 8 = - 12. The group had interest mainly in approach #1, where the MCU makes al= l the switching decisions. But we didn't have a common understanding about= how spatial information was to be conveyed, so the consumer can render mul= tiple streams together when they are spatially related. On slide 9, for approach 1, it says "MCCs don't have spatial attributes". = But other people in the discussion thought the MCCs should have spatial att= ributes. Jonathan said the MCCs could have spatial information like this (= Jonathan, correct me if I don't remember right): MCC1, MCC2, MCC3: left, center, and right of the full scene, like the image= on page 6 for VC1-3. MCC4, MCC5, MCC6: spatial information that indicates they are located on bo= ttom part of MCC1, and much smaller than MCC1, like on page 6 for VC4-6. MCC7, MCC8, MCC9: spatial information that indicates they are located on bo= ttom part of MCC2, and much smaller than MCC2, like on page 6 for VC7-9. While this should work for that specific case, I don't think it works for t= he very similar case in framework section 12.3.3 which has these two altern= ative rendering layouts for the same streams (use mono-spaced font to see t= his): +---+---+---+ +-------------+ +-------------+ +-------------+ | | | | | | | | | | +---+---+---+ | | | | | | | | | | | | | | | | +---+---+---+ | | | | | | | | | | | | | | | | +---+---+---+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ | | | | | | | | | | | | | | | | | | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | +-------------+ +-------------+ +-------------+ If we generalize this approach to support alternatives like this, I think w= e end up with approach number 3 instead of approach 1. We also talked about the consumer should have the ability to associate inco= ming encoded packet streams with a particular individual MC from the advert= isement. This would give the consumer the spatial information of the parti= cular MC currently switched in to the MCC. My concern about this way of ge= tting spatial information is that it means the renderer has to re-map decod= er output to different display locations on the fly without any advance not= ice. Regards, Mark --_000_7594FB04B1934943A5C02806D1A2204B1D104C66ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

I’= ;m in China, but I’d call in if my schedule permits.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

L=E4hett=E4j=E4: clue [mailto:clue-bounces@ietf.org] Puolesta Duckworth, Mark
L=E4hetetty: 18. tammikuuta 2014 1:44
Vastaanottaja: clue@ietf.org
Aihe: [clue] multipoint switching, MCC, and spatial information=

 

This is follow-up to the topic “[clue] MCC switching e= xample”, and to the design team discussion Jan 14.  I’m in= terested in what others have to say about how approach #1 should work, regarding spatial information and the consumer’s ability to render s= treams together that belong together.

 

Referring to my framework issue slides, pages 8 – 12.  The group had inte= rest mainly in approach #1, where the MCU makes all the switching decisions= .  But we didn’t have a common understanding about how spatial i= nformation was to be conveyed, so the consumer can render multiple streams together when they are spatially related.

 

On slide 9, for approach 1, it says “MCCs don’t = have spatial attributes”.  But other people in the discussion th= ought the MCCs should have spatial attributes.  Jonathan said the MCCs could have spatial information like this (Jonathan, correct me if I don= 217;t remember right):

MCC1, MCC2, MCC3: left, center, and right of the full scene,= like the image on page 6 for VC1-3.

MCC4, MCC5, MCC6: spatial information that indicates they ar= e located on bottom part of MCC1, and much smaller than MCC1, like on page = 6 for VC4-6.

MCC7, MCC8, MCC9: spatial information that indicates they ar= e located on bottom part of MCC2, and much smaller than MCC2, like on page = 6 for VC7-9.

 

While this should work for that specific case, I don’t= think it works for the very similar case in framework section 12.3.3 which= has these two alternative rendering layouts for the same streams (use mono-spaced font to see this):

 

   +---+---+= ;---+ +-------------+ +-------------+ +------------= -+

   |   | = ;  |   | |        &n= bsp;    | |        &= nbsp;    | |        =      |

   +---+---+= ;---+ |          &nbs= p;  | |          &nb= sp;  | |          &n= bsp;  |

   |   | = ;  |   | |        &n= bsp;    | |        &= nbsp;    | |        =      |

   +---+---+= ;---+ |          &nbs= p;  | |           &n= bsp; | |          &n= bsp;  |

   |   | = ;  |   | |        &n= bsp;    | |        &= nbsp;    | |        =      |

   +---+---+= ;---+ +-------------+ +-------------+ +------------= -+

 

  +-------------= 3; +-------------+ +-------------+

  |   &n= bsp;         | |   &= nbsp;         | |   =           |<= /p>

  |   &n= bsp;         | |   &= nbsp;         | |   =           |<= /p>

  |   &n= bsp;         | |   &= nbsp;         | |   =           |<= /p>

  | +-+ +-&= #43; +-+ | | +-+ +-+ +-+ | | +-+ &#= 43;-+ +-+ |

  | +-+ +-&= #43; +-+ | | +-+ +-+ +-+ | | +-+ &#= 43;-+ +-+ |

  +-------------= 3; +-------------+ +-------------+

 

If we generalize this approach to support alternatives like = this, I think we end up with approach number 3 instead of approach 1.<= /o:p>

 

We also talked about the consumer should have the ability to= associate incoming encoded packet streams with a particular individual MC = from the advertisement.  This would give the consumer the spatial information of the particular MC currently switched in to the = MCC.  My concern about this way of getting spatial information is that= it means the renderer has to re-map decoder output to different display lo= cations on the fly without any advance notice.

 

Regards,

Mark

--_000_7594FB04B1934943A5C02806D1A2204B1D104C66ESESSMB209erics_-- From pkyzivat@alum.mit.edu Sat Jan 18 09:21: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 075CA1ADF8E for ; Sat, 18 Jan 2014 09:21: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 JvhcqwB3CFXz for ; Sat, 18 Jan 2014 09:21:01 -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 E269C1ADF31 for ; Sat, 18 Jan 2014 09:21:00 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta05.westchester.pa.mail.comcast.net with comcast id FTWn1n0021HzFnQ55VLnDL; Sat, 18 Jan 2014 17:20:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id FVLn1n00E3ZTu2S3aVLnxD; Sat, 18 Jan 2014 17:20:47 +0000 Message-ID: <52DAB7EF.4050808@alum.mit.edu> Date: Sat, 18 Jan 2014 12:20:47 -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: "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@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=1390065647; bh=rS0DJiROK+lXdfCoU00KPOkn4sydr663csmlqfhPrLM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JexZ9gGWFqubUzNC36eAiJxAjldHY+0SWoVyHSXuRAVVU6RjRF6O2PeLcSCHaKxHh 2puCUgzjeTkFt8R9VcZJf+EwpTe8e6a0zWyF7nL7oOdaG3+0meeL39gnXMygDGM7ab i4S5RiTaGQ9JT8GZW2fj9KfYMpruxkI6/FnAMrxDNtLhaRpZzHAL8hsoIkTFsM3feJ OW1/XRjVr0ie6n/GPXi6grT2kyRPmPxMkI6n5oy0RiRDHOdY5sORAttYfdRI3esE4v rBGICwmgw9BXcXrg9JvKyqBCxDitDK3KUm8v0LRvT747vc17kGu85EInF+Uz0itios qMHXIiZTybW/A== Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 18 Jan 2014 17:21:03 -0000 On 1/17/14 6:12 PM, Duckworth, Mark wrote: > We discussed this topic in the Jan 14 design team meeting. The group had interest in the concept, but not my specific proposal. Jonathan had an interesting idea, which I think better serves the purpose. > > Instead of the MCC referring specifically to other media captures that can be contained within the MCC, the MCC can refer to zero or more "MCC grouping labels". Any other media capture can include an attribute (zero or more) with a particular MCC grouping label. The meaning is that any MC that has the same grouping label that is reference by an MCC can be included in that MCC. > > I think this doesn't change at all the meaning of MCC, but it will affect the syntax of how we describe it in the data model for CLUE messages. > > If the group agrees with this concept, I can propose specific changes to the framework. This WFM, conceptually. There are details to be worked out for this to be practical and convenient. Those details will presumably be in the data model. Specifically, in the declaration of the MCC, there must be some syntax for the reference. Two approaches come to mind: 1) the new labels share a single namespace with capture ids in the advertisement. The MCC declaration has an element that is used to reference these IDs, of either kind. You can tell which kind by resolving the reference. 2) the new labels have a distinct namespace from capture ids. The MCC declaration allows two different kinds of elements, one to reference capture ids, and another to reference these new labels. I'm inclined to prefer (2) - it seems less kludgy, and is probably equally concise. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark >> Sent: Friday, January 10, 2014 3:47 PM >> To: Paul Kyzivat; clue@ietf.org >> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >> >> Paul, >> >> Yes, I think the wildcard is just a syntax shortcut. >> One other impact that I was thinking of is if we decide to have partial updates >> of advertisements then it removes the need to re-advertise any MCC(*) >> captures when other captures change. Without wildcard, any other addition >> or removal of a contributing capture means also re-advertising every MCC >> with a new list of contributors. >> I think the wildcard fits very nicely with the switching scenario option (2) from >> the other discussion thread. >> >> Mark >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: Friday, January 10, 2014 1:24 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >>> >>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: >>>> In an advertisement, the provider can indicate which other captures >>>> are referenced by an MCC, for example: >>>> >>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 >>>> >>>> MCC1(VC1, VC2) >>>> >>>> This means MCC1 can include VC1 and/or VC2, but not the others. >>>> >>>> MCC2() >>>> >>>> Without any specific references, this means the provider is not >>>> saying which other captures can be included in MCC2, and the >>>> consumer cannot choose. >>>> >>>> I propose adding a wildcard: >>>> >>>> MCC3(*) >>> >>> IIUC you mean this to be strictly a syntactic shortcut, not adding any >>> functionality that isn't present without it. >>> >>>> This means MCC3 can include any of the other captures VC1 through >>>> VC5, and the consumer can choose. >>> >>> Do you intent this to mean all the captures in the advertisement, or >>> all the captures in the same scene? >>> >>>> For some types of MCUs, that want to give consumers the choice of >>>> which specific captures to receive in an MCC, this is useful for >>>> large advertisements with many media captures. >>> >>> Perhaps. But I have my doubts that this would be of common use in >> practice. >>> >>> So it becomes a question of whether the added implementation burden of >>> supporting this optimization is justified for the number of cases when >>> it would be of use. >>> >>> Thanks, >>> Paul >>> >>>> When endpoints join or leave a >>>> conference, causing the advertisement to change to add or remove >>>> scenes and captures, the part of the advertisement with MCCs >>>> wouldn't have to change at all. >>>> >>>> Related text from framework-13: >>>> >>>> From 7.2: "The MCC may contain a reference to the Single Media >>>> Captures... (or) A MCC MAY contain no references to other Captures >>>> to indicate that the MCC contains content from multiple sources but >>>> no information regarding those sources is given." And in section 10 >>>> "If the MCC in the advertisement does not reference any individual >>>> captures, then the Consumer cannot choose what is included in the MCC" >>>> >>>> I propose adding text: >>>> >>>> The MCC may contain a wildcard reference, meaning it can refer to >>>> any of the other captures in the advertisement. The consumer, in a >>>> configure message, may choose which of the other media captures it >>>> wishes to receive in the MCC. >>>> >>>> What do you think? >>>> >>>> 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 pkyzivat@alum.mit.edu Sat Jan 18 11:41: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 CECD61AD939 for ; Sat, 18 Jan 2014 11:41:20 -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 lapYttcVwGWv for ; Sat, 18 Jan 2014 11:41:19 -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 4AD591A1F3D for ; Sat, 18 Jan 2014 11:41:19 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id FXB81n0081vXlb85DXh6eu; Sat, 18 Jan 2014 19:41:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id FXh51n00h3ZTu2S3dXh6Hp; Sat, 18 Jan 2014 19:41:06 +0000 Message-ID: <52DAD8D1.9030904@alum.mit.edu> Date: Sat, 18 Jan 2014 14:41:05 -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: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@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=1390074066; bh=sA5S14NLvxB4fdO2mxIcDtrKojNw8Do4upB2TE7yIXA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nFaMAlRyJv/wVcefnhJCfVjcdMdGZ8Py7pfKjBHd8XLQgL/p5wmXhR1J0LjabbQBX OECTUtKvmODit1MXjfknwC+kGsFirlukHW1S3xLNhmPUg2MaIoNDboD7vLGF4pXQ6N dtcG/IYZMDJ9TTx+EhO3uZnpFq1klgGp4KPwvTqY5TL11TlYg2imvaGb1WmiywkGGd 6f80pf1RSWSlXO4AxWhoN6s5kzPwJKgovyODC6edQ1TG6culK9VY0+zabg8kWgCsM8 48bgM1BihzZidcbEIjz5DnB9VUhIYE5uBIElxb+FtVPHoEbgZQ5RXimIBIorbMNt15 7IxdHDsaMToUw== Subject: Re: [clue] multipoint switching, MCC, and spatial 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: Sat, 18 Jan 2014 19:41:21 -0000 Mark, My thinking is that the advertiser MAY include spatial coordinates on the MCCs if it wishes. If so, then they are virtual coordinates for that capture in the context of the scene containing the MCC. How the advertiser arrives at these coordinates is its business. It might look at the spatial relationships of the source captures to do this, or not. A simple consumer can simply treat an MCC like any other capture, and make all of its decisions about how to render it based on the MCC coordinates. This might be sub-optimal, but its easy. A more sophisticated consumer can look at the sources of the MCC captures, and their coordinates in their scenes, and use that to make its decisions about how to render. It can do that statically (at the time of Configure) without regard to which of the alternatives is switched in at any one time. (This is somewhat sub-optimal.) Or the most sophisticated consumer can see what it is receiving in each RTP packet, map this back to a particular source capture in the advertisement, and then use the spatial coordinates from that to make rendering decisions. (We need to figure out how that mapping an be done.) The advertiser doesn't need to know which way the consumer is doing it. But the information provided in the advertisement constrains what the consumer is able to do. Thanks, Paul On 1/17/14 6:44 PM, Duckworth, Mark wrote: > This is follow-up to the topic [clue] MCC switching example, and to > the design team discussion Jan 14. Im interested in what others have > to say about how approach #1 should work, regarding spatial information > and the consumers ability to render streams together that belong together. > > Referring to my framework issue slides > , > pages 8 12. The group had interest mainly in approach #1, where the > MCU makes all the switching decisions. But we didnt have a common > understanding about how spatial information was to be conveyed, so the > consumer can render multiple streams together when they are spatially > related. > > On slide 9, for approach 1, it says MCCs dont have spatial > attributes. But other people in the discussion thought the MCCs should > have spatial attributes. Jonathan said the MCCs could have spatial > information like this (Jonathan, correct me if I dont remember right): > > MCC1, MCC2, MCC3: left, center, and right of the full scene, like the > image on page 6 for VC1-3. > > MCC4, MCC5, MCC6: spatial information that indicates they are located on > bottom part of MCC1, and much smaller than MCC1, like on page 6 for VC4-6. > > MCC7, MCC8, MCC9: spatial information that indicates they are located on > bottom part of MCC2, and much smaller than MCC2, like on page 6 for VC7-9. > > While this should work for that specific case, I dont think it works > for the very similar case in framework section 12.3.3 which has these > two alternative rendering layouts for the same streams (use mono-spaced > font to see this): > > +---+---+---+ +-------------+ +-------------+ +-------------+ > > | | | | | | | | | | > > +---+---+---+ | | | | | | > > | | | | | | | | | | > > +---+---+---+ | | | | | | > > | | | | | | | | | | > > +---+---+---+ +-------------+ +-------------+ +-------------+ > > +-------------+ +-------------+ +-------------+ > > | | | | | | > > | | | | | | > > | | | | | | > > | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | > > | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | > > +-------------+ +-------------+ +-------------+ > > If we generalize this approach to support alternatives like this, I > think we end up with approach number 3 instead of approach 1. > > We also talked about the consumer should have the ability to associate > incoming encoded packet streams with a particular individual MC from the > advertisement. This would give the consumer the spatial information of > the particular MC currently switched in to the MCC. My concern about > this way of getting spatial information is that it means the renderer > has to re-map decoder output to different display locations on the fly > without any advance notice. > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Sun Jan 19 17:38: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 0D9C01A0015 for ; Sun, 19 Jan 2014 17:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 ITYQVjLHnHbD for ; Sun, 19 Jan 2014 17:38:30 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237AF1A0010 for ; Sun, 19 Jan 2014 17:38:30 -0800 (PST) Received: from ppp118-209-132-229.lns20.mel6.internode.on.net ([118.209.132.229]:53688 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W53m7-00038J-OY for clue@ietf.org; Mon, 20 Jan 2014 12:35:39 +1100 Message-ID: <52DC7E14.9080603@nteczone.com> Date: Mon, 20 Jan 2014 12:38:28 +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: <52D44B95.7080906@alum.mit.edu> In-Reply-To: <52D44B95.7080906@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] 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: Mon, 20 Jan 2014 01:38:32 -0000 Hello Mary, This looks pretty good. Maybe one thing to note is the user is authenticated (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 carried by CLUE and assert that I'm the president. There may not be any sanity check of such information. 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 actually depicted by the media. Regards, Christian 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 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 SHOULD 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. >> 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 >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Sun Jan 19 17:58: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 074231A0015 for ; Sun, 19 Jan 2014 17:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 Oh-He6i7bneM for ; Sun, 19 Jan 2014 17:58:55 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC521A000C for ; Sun, 19 Jan 2014 17:58:55 -0800 (PST) Received: from ppp118-209-132-229.lns20.mel6.internode.on.net ([118.209.132.229]:53924 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W545t-0006xO-Vd; Mon, 20 Jan 2014 12:56:06 +1100 Message-ID: <52DC82DE.5010508@nteczone.com> Date: Mon, 20 Jan 2014 12:58:54 +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: "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@CRPMBOXPRD07.polycom.com> <52CF5004.7040309@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4E5@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4E5@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] Advertising what is in an MCC - allow wildcard? 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, 20 Jan 2014 01:58:57 -0000 Hello Mark, I'm not sure how useful an "all" would be if the scope is across all captures in the CLUE message rather than a particular scene. I would actually think that a range would be the more useful case. Is there a reason why you don't like an ordered list? Regards, Christian On 11/01/2014 7:38 AM, Duckworth, Mark wrote: > Christian, > > I intended the scope of the wildcard to refer to all other captures, not just within the same scene. > > I'm against the range idea (MCC4(VC2-VC4)) because I think capture IDs should be just an identifier, without implying some ordered list. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Thursday, January 09, 2014 8:42 PM >> To: clue@ietf.org >> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >> >> Hello Mark, >> >> Please see my comments below. >> >> Regards, Christian >> >> On 10/01/2014 9:11 AM, Duckworth, Mark wrote: >>> In an advertisement, the provider can indicate which other captures >>> are referenced by an MCC, for example: >>> >>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 >>> >>> MCC1(VC1, VC2) >>> >>> This means MCC1 can include VC1 and/or VC2, but not the others. >>> >>> MCC2() >>> >>> Without any specific references, this means the provider is not saying >>> which other captures can be included in MCC2, and the consumer cannot >>> choose. >>> >>> I propose adding a wildcard: >>> >>> MCC3(*) >>> >>> This means MCC3 can include any of the other captures VC1 through VC5, >>> and the consumer can choose. >>> >>> For some types of MCUs, that want to give consumers the choice of >>> which specific captures to receive in an MCC, this is useful for large >>> advertisements with many media captures. When endpoints join or leave >>> a conference, causing the advertisement to change to add or remove >>> scenes and captures, the part of the advertisement with MCCs wouldn't >>> have to change at all. >>> >>> Related text from framework-13: >>> >>> From 7.2: "The MCC may contain a reference to the Single Media >>> Captures... (or) A MCC MAY contain no references to other Captures to >>> indicate that the MCC contains content from multiple sources but no >>> information regarding those sources is given." And in section 10 "If >>> the MCC in the advertisement does not reference any individual >>> captures, then the Consumer cannot choose what is included in the MCC" >>> >>> I propose adding text: >>> >>> The MCC may contain a wildcard reference, meaning it can refer to any >>> of the other captures in the advertisement. The consumer, in a >>> configure message, may choose which of the other media captures it >>> wishes to receive in the MCC. >>> >>> What do you think? >>> >> [CNG] I'm supportive of adding a wildcard mechanism. It could help shorten >> messages. I think we should be clear about what the scope of the wildcard is. >> i.e. is it the captures in the same scene as the MCC or across all scenes in the >> Advertisement. >> I think what may perhaps be additionally useful is to be able to provide a >> range, i.e. MCC4(VC2-VC4). However this would imply that captureIDs would >> have to have a numeric aspect. >>> 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 Sun Jan 19 18:37: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 46C0D1A002A for ; Sun, 19 Jan 2014 18:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[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 WQqJSqBwXx8G for ; Sun, 19 Jan 2014 18:36:58 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E321A001F for ; Sun, 19 Jan 2014 18:36:57 -0800 (PST) Received: from ppp118-209-132-229.lns20.mel6.internode.on.net ([118.209.132.229]:54639 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W54gh-0004US-Gk for clue@ietf.org; Mon, 20 Jan 2014 13:34:07 +1100 Message-ID: <52DC8BC8.7000204@nteczone.com> Date: Mon, 20 Jan 2014 13:36: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: 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> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF15FFC@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] 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: Mon, 20 Jan 2014 02:37:00 -0000 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. 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. 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. Regards, Christian On 18/01/2014 9:50 AM, Duckworth, Mark wrote: > > We discussed this topic in the design team meeting Jan 14 > . > 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. > > > > > > > > < > > > 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 From Christian.Groves@nteczone.com Sun Jan 19 18:37: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 DF72C1A0026 for ; Sun, 19 Jan 2014 18:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 LicXOzLVXKGB for ; Sun, 19 Jan 2014 18:37:48 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2241A001F for ; Sun, 19 Jan 2014 18:37:48 -0800 (PST) Received: from ppp118-209-132-229.lns20.mel6.internode.on.net ([118.209.132.229]:54652 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W54hX-0004bs-A1 for clue@ietf.org; Mon, 20 Jan 2014 13:34:59 +1100 Message-ID: <52DC8BFC.6050705@nteczone.com> Date: Mon, 20 Jan 2014 13:37:48 +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: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16009@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16009@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] 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: Mon, 20 Jan 2014 02:37:50 -0000 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 From Christian.Groves@nteczone.com Sun Jan 19 18:55: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 38DF91A001F for ; Sun, 19 Jan 2014 18:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 hKf8_R5x1YkC for ; Sun, 19 Jan 2014 18:55:28 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1C01A001B for ; Sun, 19 Jan 2014 18:55:28 -0800 (PST) Received: from ppp118-209-132-229.lns20.mel6.internode.on.net ([118.209.132.229]:55027 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W54yc-0007Lc-84 for clue@ietf.org; Mon, 20 Jan 2014 13:52:38 +1100 Message-ID: <52DC901F.2090907@nteczone.com> Date: Mon, 20 Jan 2014 13:55:27 +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: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> In-Reply-To: <52DAB7EF.4050808@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 grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 20 Jan 2014 02:55:30 -0000 I'd like some more explanation of the concept before agreeing. The reason why I went with CaptureIDs for the MCC and the individual captures was to prevent yet another namespace in CLUE. It also worked in with the fact that the Consumer currently only returns CaptureIDs and EncodingIDs. Are we now saying that an Advertiser sends MCC1(label1) and if a Consumer wants a subset it returns MCC(Capture1, Capture2, Capture3, etc?). I particularly avoided the use of attributes for this because CLUE Configures don't reference attributes. Why couldn't CLUE simply have pattern matching based on regular expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.). Christian On 19/01/2014 4:20 AM, Paul Kyzivat wrote: > On 1/17/14 6:12 PM, Duckworth, Mark wrote: >> We discussed this topic in the Jan 14 design team meeting. The group >> had interest in the concept, but not my specific proposal. Jonathan >> had an interesting idea, which I think better serves the purpose. >> >> Instead of the MCC referring specifically to other media captures >> that can be contained within the MCC, the MCC can refer to zero or >> more "MCC grouping labels". Any other media capture can include an >> attribute (zero or more) with a particular MCC grouping label. The >> meaning is that any MC that has the same grouping label that is >> reference by an MCC can be included in that MCC. >> >> I think this doesn't change at all the meaning of MCC, but it will >> affect the syntax of how we describe it in the data model for CLUE >> messages. >> >> If the group agrees with this concept, I can propose specific changes >> to the framework. > > This WFM, conceptually. > There are details to be worked out for this to be practical and > convenient. Those details will presumably be in the data model. > > Specifically, in the declaration of the MCC, there must be some syntax > for the reference. Two approaches come to mind: > > 1) the new labels share a single namespace with capture ids in the > advertisement. The MCC declaration has an element that is used to > reference these IDs, of either kind. You can tell which kind by > resolving the reference. > > 2) the new labels have a distinct namespace from capture ids. The MCC > declaration allows two different kinds of elements, one to reference > capture ids, and another to reference these new labels. > > I'm inclined to prefer (2) - it seems less kludgy, and is probably > equally concise. > > Thanks, > Paul > > > >> Mark >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark >>> Sent: Friday, January 10, 2014 3:47 PM >>> To: Paul Kyzivat; clue@ietf.org >>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >>> >>> Paul, >>> >>> Yes, I think the wildcard is just a syntax shortcut. >>> One other impact that I was thinking of is if we decide to have >>> partial updates >>> of advertisements then it removes the need to re-advertise any MCC(*) >>> captures when other captures change. Without wildcard, any other >>> addition >>> or removal of a contributing capture means also re-advertising every >>> MCC >>> with a new list of contributors. >>> I think the wildcard fits very nicely with the switching scenario >>> option (2) from >>> the other discussion thread. >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Friday, January 10, 2014 1:24 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >>>> >>>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: >>>>> In an advertisement, the provider can indicate which other captures >>>>> are referenced by an MCC, for example: >>>>> >>>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 >>>>> >>>>> MCC1(VC1, VC2) >>>>> >>>>> This means MCC1 can include VC1 and/or VC2, but not the others. >>>>> >>>>> MCC2() >>>>> >>>>> Without any specific references, this means the provider is not >>>>> saying which other captures can be included in MCC2, and the >>>>> consumer cannot choose. >>>>> >>>>> I propose adding a wildcard: >>>>> >>>>> MCC3(*) >>>> >>>> IIUC you mean this to be strictly a syntactic shortcut, not adding any >>>> functionality that isn't present without it. >>>> >>>>> This means MCC3 can include any of the other captures VC1 through >>>>> VC5, and the consumer can choose. >>>> >>>> Do you intent this to mean all the captures in the advertisement, or >>>> all the captures in the same scene? >>>> >>>>> For some types of MCUs, that want to give consumers the choice of >>>>> which specific captures to receive in an MCC, this is useful for >>>>> large advertisements with many media captures. >>>> >>>> Perhaps. But I have my doubts that this would be of common use in >>> practice. >>>> >>>> So it becomes a question of whether the added implementation burden of >>>> supporting this optimization is justified for the number of cases when >>>> it would be of use. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> When endpoints join or leave a >>>>> conference, causing the advertisement to change to add or remove >>>>> scenes and captures, the part of the advertisement with MCCs >>>>> wouldn't have to change at all. >>>>> >>>>> Related text from framework-13: >>>>> >>>>> From 7.2: "The MCC may contain a reference to the Single Media >>>>> Captures... (or) A MCC MAY contain no references to other Captures >>>>> to indicate that the MCC contains content from multiple sources but >>>>> no information regarding those sources is given." And in section 10 >>>>> "If the MCC in the advertisement does not reference any individual >>>>> captures, then the Consumer cannot choose what is included in the >>>>> MCC" >>>>> >>>>> I propose adding text: >>>>> >>>>> The MCC may contain a wildcard reference, meaning it can refer to >>>>> any of the other captures in the advertisement. The consumer, in a >>>>> configure message, may choose which of the other media captures it >>>>> wishes to receive in the MCC. >>>>> >>>>> What do you think? >>>>> >>>>> 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 Christian.Groves@nteczone.com Sun Jan 19 18:59: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 F2B581A001F for ; Sun, 19 Jan 2014 18:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 AlkxR9rkguzj for ; Sun, 19 Jan 2014 18:59:27 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBC91A001B for ; Sun, 19 Jan 2014 18:59:27 -0800 (PST) Received: from ppp118-209-132-229.lns20.mel6.internode.on.net ([118.209.132.229]:55124 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W552T-0007rR-Mu for clue@ietf.org; Mon, 20 Jan 2014 13:56:37 +1100 Message-ID: <52DC910E.8090909@nteczone.com> Date: Mon, 20 Jan 2014 13:59:26 +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: <49E45C59CA48264997FEBFB29B6BC2D60C9CF1600B@CRPMBOXPRD07.polycom.com> In-Reply-To: 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] Design team discussion Jan 21? 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, 20 Jan 2014 02:59:29 -0000 Hello Mark, Could you summarize what issues you want to bring up? I'd like to be in the discussions but the time 1.30am - 3am isn't particularly conducive. Regards, Christian On 18/01/2014 10:35 AM, Mary Barnes wrote: > Yes, sorry, the chairs should have updated the wiki and sent a note. > I've done the former and I guess I'm now doing the latter. > > Thanks, > Mary. > > > On Fri, Jan 17, 2014 at 5:02 PM, Duckworth, Mark > > wrote: > > The wiki says no meeting on Jan 21 > . Id > like to continue the framework issues discussion, particularly the > media switching example with MCCs and spatial information, if > people are available on Jan 21. Can we schedule a meeting for next > week? > > 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 Sun Jan 19 19: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 77FA21A002E for ; Sun, 19 Jan 2014 19:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 gmfnJhTSRI0h for ; Sun, 19 Jan 2014 19:37:37 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E901A002A for ; Sun, 19 Jan 2014 19:37:36 -0800 (PST) Received: from ppp118-209-132-229.lns20.mel6.internode.on.net ([118.209.132.229]:55666 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W55dO-0005cv-Rn for clue@ietf.org; Mon, 20 Jan 2014 14:34:47 +1100 Message-ID: <52DC9A00.4010609@nteczone.com> Date: Mon, 20 Jan 2014 14:37:36 +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: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@CRPMBOXPRD07.polycom.com> <52DAD8D1.9030904@alum.mit.edu> In-Reply-To: <52DAD8D1.9030904@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: Subject: Re: [clue] multipoint switching, MCC, and spatial 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: Mon, 20 Jan 2014 03:37:39 -0000 Hello Mark, I agree with Paul's comments. Please see my additional comments below. Regards, Christian On 19/01/2014 6:41 AM, Paul Kyzivat wrote: > Mark, > > My thinking is that the advertiser MAY include spatial coordinates on > the MCCs if it wishes. If so, then they are virtual coordinates for > that capture in the context of the scene containing the MCC. How the > advertiser arrives at these coordinates is its business. It might look > at the spatial relationships of the source captures to do this, or not. > > A simple consumer can simply treat an MCC like any other capture, and > make all of its decisions about how to render it based on the MCC > coordinates. This might be sub-optimal, but its easy. > > A more sophisticated consumer can look at the sources of the MCC > captures, and their coordinates in their scenes, and use that to make > its decisions about how to render. It can do that statically (at the > time of Configure) without regard to which of the alternatives is > switched in at any one time. (This is somewhat sub-optimal.) > > Or the most sophisticated consumer can see what it is receiving in > each RTP packet, map this back to a particular source capture in the > advertisement, and then use the spatial coordinates from that to make > rendering decisions. (We need to figure out how that mapping an be done.) > > The advertiser doesn't need to know which way the consumer is doing > it. But the information provided in the advertisement constrains what > the consumer is able to do. > > Thanks, > Paul > > On 1/17/14 6:44 PM, Duckworth, Mark wrote: >> This is follow-up to the topic [clue] MCC switching example, and to >> the design team discussion Jan 14. Im interested in what others have >> to say about how approach #1 should work, regarding spatial information >> and the consumers ability to render streams together that belong >> together. >> >> Referring to my framework issue slides >> , >> >> pages 8 12. The group had interest mainly in approach #1, where the >> MCU makes all the switching decisions. But we didnt have a common >> understanding about how spatial information was to be conveyed, so the >> consumer can render multiple streams together when they are spatially >> related. >> >> On slide 9, for approach 1, it says MCCs dont have spatial >> attributes. But other people in the discussion thought the MCCs should >> have spatial attributes. Jonathan said the MCCs could have spatial >> information like this (Jonathan, correct me if I dont remember right): >> >> MCC1, MCC2, MCC3: left, center, and right of the full scene, like the >> image on page 6 for VC1-3. >> >> MCC4, MCC5, MCC6: spatial information that indicates they are located on >> bottom part of MCC1, and much smaller than MCC1, like on page 6 for >> VC4-6. >> >> MCC7, MCC8, MCC9: spatial information that indicates they are located on >> bottom part of MCC2, and much smaller than MCC2, like on page 6 for >> VC7-9. [CNG] Yes MCCs could have spatial information in this context. >> >> While this should work for that specific case, I dont think it works >> for the very similar case in framework section 12.3.3 which has these >> two alternative rendering layouts for the same streams (use mono-spaced >> font to see this): >> >> +---+---+---+ +-------------+ +-------------+ +-------------+ >> >> | | | | | | | | | | >> >> +---+---+---+ | | | | | | >> >> | | | | | | | | | | >> >> +---+---+---+ | | | | | | >> >> | | | | | | | | | | >> >> +---+---+---+ +-------------+ +-------------+ +-------------+ >> >> +-------------+ +-------------+ +-------------+ >> >> | | | | | | >> >> | | | | | | >> >> | | | | | | >> >> | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | >> >> | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | >> >> +-------------+ +-------------+ +-------------+ >> >> If we generalize this approach to support alternatives like this, I >> think we end up with approach number 3 instead of approach 1. [CNG] Table 22 in section 12.3.3 of the framework has spatial information for MCC1,MCC2,MCC3 (incorrectly labelled as left,left,left it should be left, centre, right). This would be related to the "large" boxes above. I don't think there's an issue with this. There are a number of ways that the "small" boxes could be advertised. The first is as per table 23 of the framework. Each of the MCCs (MMC4-MCC12) could be given a virtual spatial area. i.e. each MCC stream has its own space. i.e. MCC4(top left), MCC5(top centre), MCC6(top right, etc.) It's then up to the consumer to decide how to render it. The Consumer could do either of the above approaches. A second approach is a per table 24 of the framework. If MCC13 was in CaptureScene8 it could use spatial information of the constituent MCCs to determine the position in the composed single stream. Unless the Consumer had the smarts to "decompose" the media stream then it would only be able to the top approach. A third approach would be for the Provider to Advertise 3 streams for the 9 tiles (this isn't shown in the framework), e.g. +=======================+=================================+ | Capture Scene # | Description=Output3stream | +-----------------------|---------------------------------+ | MCC4(VC4,VC5,VC6,VC7, | MaxCaptures=1 | | VC8,VC9,VC10,VC11, | Policy=SoundLevel:0 | | VC12,VC13,VC14,VC15)| SpatialInfo=Top Left | | | | | MCC5(VC4,VC5,VC6,VC7, | MaxCaptures=1 | | VC8,VC9,VC10,VC11, | Policy=SoundLevel:1 | | VC12,VC13,VC14,VC15)| SpatialInfo=Top Middle | | | | to to | | | | | MCC12(VC4,VC5,VC6,VC7,| MaxCaptures=1 | | VC8,VC9,VC10,VC11, | Policy=SoundLevel:8 | | VC12,VC13,VC14,VC15)| SpatialInfo=Bottom Right | | | | | MCC13(MCC4,MCC5,MCC6 | MaxCaptures=3 | | | EncodingGroup=1 | | | SpatialInfo=Top | | MCC14(MCC7,MCC8,MCC9 | MaxCaptures=3 | | | EncodingGroup=1 | | | SpatialInfo=Middle | | MCC15(MCC10,MCC11, | MaxCaptures=3 | | MCC12) | EncodingGroup=1 | | | SpatialInfo=Bottom | | CSE(MCC13,MCC14,MCC15)| | +=======================+=================================+ In the above case the Provider Advertises 3 encodings MCC13 containing the three most active speakers, MCC14 containing the next three most active etc. Note that the MCC13-15 are static, always maintaining the spatial co-ordinates. Because the Consumer receives 3 streams it could display these 3 streams in either the 9 tiles approach or the PiP approach. As Paul said, the information received from the Advertiser constrains what the Consumer is able to do. >> >> We also talked about the consumer should have the ability to associate >> incoming encoded packet streams with a particular individual MC from the >> advertisement. This would give the consumer the spatial information of >> the particular MC currently switched in to the MCC. My concern about >> this way of getting spatial information is that it means the renderer >> has to re-map decoder output to different display locations on the fly >> without any advance notice. >> >> 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 Mark.Duckworth@polycom.com Mon Jan 20 06:51: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 A4DF11A0190 for ; Mon, 20 Jan 2014 06:51:10 -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 AbYruRHp0-9f for ; Mon, 20 Jan 2014 06:51:08 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 356781A0186 for ; Mon, 20 Jan 2014 06:51:08 -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; Mon, 20 Jan 2014 06:51:08 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" , "Christian Groves (Christian.Groves@nteczone.com)" Date: Mon, 20 Jan 2014 06:51:05 -0800 Thread-Topic: [clue] Design team discussion Jan 21? Thread-Index: Ac8Vi6dngrGZGAM+TR27HETdY/aVqwAYsvrw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF160EA@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF1600B@CRPMBOXPRD07.polycom.com> <52DC910E.8090909@nteczone.com> In-Reply-To: <52DC910E.8090909@nteczone.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_49E45C59CA48264997FEBFB29B6BC2D60C9CF160EACRPMBOXPRD07p_" MIME-Version: 1.0 Subject: Re: [clue] Design team discussion Jan 21? 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, 20 Jan 2014 14:51:10 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF160EACRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christian, It is a continuation of last week's discussion, so the topics are already i= n the presentation from last week. I think we should start with the topics also discussed in these email threa= ds: - "MCC grouping label" (improvement on my wildcard proposal) - "multipoint switching, MCC, and spatial information" Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Sunday, January 19, 2014 9:59 PM > To: clue@ietf.org > Subject: Re: [clue] Design team discussion Jan 21? > > Hello Mark, > > Could you summarize what issues you want to bring up? I'd like to be in t= he > discussions but the time 1.30am - 3am isn't particularly conducive. > > Regards, Christian > > > On 18/01/2014 10:35 AM, Mary Barnes wrote: > > Yes, sorry, the chairs should have updated the wiki and sent a note. > > I've done the former and I guess I'm now doing the latter. > > > > Thanks, > > Mary. > > > > > > On Fri, Jan 17, 2014 at 5:02 PM, Duckworth, Mark > > > >> wrote: > > > > The wiki says no meeting on Jan 21 > > . I'd > > like to continue the framework issues discussion, particularly the > > media switching example with MCCs and spatial information, if > > people are available on Jan 21. Can we schedule a meeting for next > > week? > > > > 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 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF160EACRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Christian,

It is a continuation of last week's dis= cussion, so the topics are already in the presentation from last week.

I think we should start with the topics also discussed in these email thre= ads:

-  &= nbsp;       “MC= C grouping label” (improvement on my wildcard proposal)

-<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;    “multipoint switching= , MCC, and spatial information”

 

Mark

 

> -----Orig= inal Message-----

> From: clue [mailto:clue-b= ounces@ietf.org] On Behalf Of Christian Groves

&= gt; Sent: Sunday, January 19, 2014 9:59 PM

> = To: clue@ietf.org

> Subject: Re: [clue] Desig= n team discussion Jan 21?

>

> Hello Mark,

>

> Could you summarize what issues you want to bring up? I'd= like to be in the

> discussions but the time= 1.30am - 3am isn't particularly conducive.

>=

> Regards, Christian

>

>

>= On 18/01/2014 10:35 AM, Mary Barnes wrote:

>= > Yes, sorry, the chairs should have updated the wiki and sent a note.<= /p>

> > I've done the former and I guess I'm n= ow doing the latter.

> >

> > Thanks,

> > Mary.

<= p class=3DMsoPlainText>> >

> >

> > On Fri, Jan 17, 2014 at 5:02 PM, Duckworth,= Mark

> > <Mark.Duckworth@polycom.com

> <mailto:Mark.Duckworth@polycom.com>>= ; wrote:

> >

&g= t; >     The wiki says no meeting on Jan 21

> >     <http://trac.tools.ietf.org/wg/clue/trac/wiki/= Design-Team>. I’d

> >&= nbsp;    like to continue the framework issues discussion, p= articularly the

> >    = ; media switching example with MCCs and spatial information, if

> >     people are available on J= an 21. Can we schedule a meeting for next

> &= gt;     week?

> >

<= p class=3DMsoPlainText>> >     Mark

> >

> >

> >     _________________________= ______________________

> >  &nbs= p;  clue mailing list

> >  =    clue@ietf.org <mailto:cl= ue@ietf.org>

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

> >

> >

> >

> >

> > ____________= ___________________________________

> > cl= ue mailing list

> > clue@ietf.= org

> > https://www.ietf.org/mailman/listinfo/clue

>

> ____________________= ___________________________

> clue mailing li= st

> clue@ietf.org

=

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

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9CF160EACRPMBOXPRD07p_-- From pkyzivat@alum.mit.edu Mon Jan 20 09:43: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 C99431A01DC for ; Mon, 20 Jan 2014 09:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.864 X-Spam-Level: * X-Spam-Status: No, score=1.864 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 PRJ6Z1Ypq-85 for ; Mon, 20 Jan 2014 09:43:36 -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 DDDBA1A015E for ; Mon, 20 Jan 2014 09:43:35 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta10.westchester.pa.mail.comcast.net with comcast id GGbu1n0030ldTLk5AHjbxP; Mon, 20 Jan 2014 17:43:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id GHjb1n00g3ZTu2S01Hjbsr; Mon, 20 Jan 2014 17:43:35 +0000 Message-ID: <52DD6047.4030101@alum.mit.edu> Date: Mon, 20 Jan 2014 12:43:35 -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: <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> In-Reply-To: <52DC8BC8.7000204@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=1390239815; bh=Ajsp6LFio+JTkCwQl4HKpwN1r1+RapfTU7rWNgUGjvw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hrvtesISUvIZZRQFL2Tds36D5p64Y4eGDdV39OkDTcwY22NPz5mU6UgC1NUY3r9VK UJtDFAlJgXZi4Lqdg2RwCFppN/vIFecAlpTvfFdlJ20qXB3spfMioryhnN/p0MQBHS jPqmK0XoBdAcC7j31bTW7mRtkVsiCiN0MHZepX7/1Kb4SMUbtlWae/9VLBDNPf2sKX +oW8eCaipIhhHYssHMIzRwA1bhF7vyFCurFe5c8CignbZW462XrutR1mhJf+45drXK Zdtjomdh7EfZXtFsvWfIx5/L971VdcvFT1Clf9dgrgiRbW+b+XjSz/TECMgasO6sZi FVPZLGFtQOUjw== Subject: Re: [clue] 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: Mon, 20 Jan 2014 17:43:39 -0000 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. 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. 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. 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. But none of that has anything to do with the the arrangement of composed captures within an MCC. 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 >> . >> 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. >> >> > > >> >> > > <> >> > > 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 > From pkyzivat@alum.mit.edu Mon Jan 20 10:04: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 6FCA01A0183 for ; Mon, 20 Jan 2014 10:04: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 ElATQzuSkI6d for ; Mon, 20 Jan 2014 10:04:51 -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 594711A0169 for ; Mon, 20 Jan 2014 10:04:51 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta09.westchester.pa.mail.comcast.net with comcast id GD7y1n0031c6gX859J4r02; Mon, 20 Jan 2014 18:04:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id GJ4r1n0083ZTu2S3jJ4rcq; Mon, 20 Jan 2014 18:04:51 +0000 Message-ID: <52DD6543.5060405@alum.mit.edu> Date: Mon, 20 Jan 2014 13:04:51 -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: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@CRPMBOXPRD07.polycom.com> <52DAD8D1.9030904@alum.mit.edu> <52DC9A00.4010609@nteczone.com> In-Reply-To: <52DC9A00.4010609@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=1390241091; bh=oI5yu5WA+PCzPx8Eunj/YyKSiWzqKWNJWqNdDHb3mCw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sc/WRQLAhSXJJ1SgsHYFAleTjjQs/Tf8pEFbWO5IzYKYmbRbzufov5scMp7zZ/ESH rpMbDVUH1ZOhLSZKZdXc24DFVHmi4ZE1mzdO5UUdw6q0CoO2L0eqYdmHGEMqTeD3H/ Ff3YpkIR9fAHBll8ZqvTrRjgyC5wRw9h3E42Oupb22rwC08uWucBQ8X3imnMAM9ZHK AZe6m8feBkOLIM0u8WDLSqkc2KUUoj9SjN0NhdXcIQE6S8XXulX8YOT0jlDjPKiinF /UERT83SpZWOVFu31k3QOgBjCzjENZoO2ZlfEciA1fXYmq7ReLbnS9X0y2+PdmUdTd 2zqWwutaS9SuA== Subject: Re: [clue] multipoint switching, MCC, and spatial 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: Mon, 20 Jan 2014 18:04:52 -0000 On 1/19/14 10:37 PM, Christian Groves wrote: >>> On slide 9, for approach 1, it says MCCs dont have spatial >>> attributes. But other people in the discussion thought the MCCs should >>> have spatial attributes. Jonathan said the MCCs could have spatial >>> information like this (Jonathan, correct me if I dont remember right): >>> >>> MCC1, MCC2, MCC3: left, center, and right of the full scene, like the >>> image on page 6 for VC1-3. >>> >>> MCC4, MCC5, MCC6: spatial information that indicates they are located on >>> bottom part of MCC1, and much smaller than MCC1, like on page 6 for >>> VC4-6. >>> >>> MCC7, MCC8, MCC9: spatial information that indicates they are located on >>> bottom part of MCC2, and much smaller than MCC2, like on page 6 for >>> VC7-9. > [CNG] Yes MCCs could have spatial information in this context. OK, is *this* what you have been talking about Christian? I agree this is *possible*. But it will take more specification for consumers to make sense of this in a consistent way. Specifically, our spatial info describes a quadrilateral in a plane in three-space. In the above there is no mention of the third dimension. Do you assume that MCC4 and MCC7 fall within the planar area of MCC1? If so, then what should the stacking order be when composing them? Or do you assume that they will be planar areas that are "nearer" to the capture point than MC1, providing a hint about the stacking order? Thanks, Paul From pkyzivat@alum.mit.edu Mon Jan 20 10: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 A73771A01C1 for ; Mon, 20 Jan 2014 10: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 9m-2darc0VBu for ; Mon, 20 Jan 2014 10:14:31 -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 A01401A0169 for ; Mon, 20 Jan 2014 10:14:31 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta14.westchester.pa.mail.comcast.net with comcast id GEqr1n0081wpRvQ5EJEXNT; Mon, 20 Jan 2014 18:14:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id GJEX1n00M3ZTu2S3eJEXE0; Mon, 20 Jan 2014 18:14:31 +0000 Message-ID: <52DD6787.6060009@alum.mit.edu> Date: Mon, 20 Jan 2014 13: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.2.0 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> In-Reply-To: <52DC901F.2090907@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=1390241671; bh=JtdhTjc+gW+YfIbadt6AkcoQGXXAnr/tmrbCXQUk5kE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=thm7fugeqbsly8YEmJjpr65JK/vPqSKmkrEUF5wKyEqR+ogaNMTaABsH81SYyFMck wK1s+l1qlxtCuU+WGdNJvVMV/7DojuNQFu/DzfeE5s5a0CWRwETKDV37Odieo8T74N CNTnaJQzN2V7NcjY9w0FkzmPxDtjP4KXc1MMnHzd3FqSLW7G1VaTPdpYQJoPD1A5Hh J9DKYxUQkGk98UVI3pjUAu6NlXuVRx8CUmEoF+NpRa4v0OmD5jf5h8jbx6R5gyLI9v sntYa8gQcysAnY98il6857BCI+5Ar1aVdCrbN1W4oOs6y7i3Ek8cxnCQnyiBZIMB+I tTv3ajEltDaEA== Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 20 Jan 2014 18:14:33 -0000 On 1/19/14 9:55 PM, Christian Groves wrote: > I'd like some more explanation of the concept before agreeing. > > The reason why I went with CaptureIDs for the MCC and the individual > captures was to prevent yet another namespace in CLUE. It also worked in > with the fact that the Consumer currently only returns CaptureIDs and > EncodingIDs. Are we now saying that an Advertiser sends MCC1(label1) and > if a Consumer wants a subset it returns MCC(Capture1, Capture2, > Capture3, etc?). I particularly avoided the use of attributes for this > because CLUE Configures don't reference attributes. My thought was that the the consumer could return: - MCC() - MCC(capture1, capture2, ...) - MCC(label1) - MCC(label1, label2, ...) - MCC(capture1, label1, ...) > Why couldn't CLUE simply have pattern matching based on regular > expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.). That is a possibility. I question whether it is simpler. I guess it does make advertisements smaller. Thanks, Paul > Christian > > > On 19/01/2014 4:20 AM, Paul Kyzivat wrote: >> On 1/17/14 6:12 PM, Duckworth, Mark wrote: >>> We discussed this topic in the Jan 14 design team meeting. The group >>> had interest in the concept, but not my specific proposal. Jonathan >>> had an interesting idea, which I think better serves the purpose. >>> >>> Instead of the MCC referring specifically to other media captures >>> that can be contained within the MCC, the MCC can refer to zero or >>> more "MCC grouping labels". Any other media capture can include an >>> attribute (zero or more) with a particular MCC grouping label. The >>> meaning is that any MC that has the same grouping label that is >>> reference by an MCC can be included in that MCC. >>> >>> I think this doesn't change at all the meaning of MCC, but it will >>> affect the syntax of how we describe it in the data model for CLUE >>> messages. >>> >>> If the group agrees with this concept, I can propose specific changes >>> to the framework. >> >> This WFM, conceptually. >> There are details to be worked out for this to be practical and >> convenient. Those details will presumably be in the data model. >> >> Specifically, in the declaration of the MCC, there must be some syntax >> for the reference. Two approaches come to mind: >> >> 1) the new labels share a single namespace with capture ids in the >> advertisement. The MCC declaration has an element that is used to >> reference these IDs, of either kind. You can tell which kind by >> resolving the reference. >> >> 2) the new labels have a distinct namespace from capture ids. The MCC >> declaration allows two different kinds of elements, one to reference >> capture ids, and another to reference these new labels. >> >> I'm inclined to prefer (2) - it seems less kludgy, and is probably >> equally concise. >> >> Thanks, >> Paul >> >> >> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark >>>> Sent: Friday, January 10, 2014 3:47 PM >>>> To: Paul Kyzivat; clue@ietf.org >>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >>>> >>>> Paul, >>>> >>>> Yes, I think the wildcard is just a syntax shortcut. >>>> One other impact that I was thinking of is if we decide to have >>>> partial updates >>>> of advertisements then it removes the need to re-advertise any MCC(*) >>>> captures when other captures change. Without wildcard, any other >>>> addition >>>> or removal of a contributing capture means also re-advertising every >>>> MCC >>>> with a new list of contributors. >>>> I think the wildcard fits very nicely with the switching scenario >>>> option (2) from >>>> the other discussion thread. >>>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>> Sent: Friday, January 10, 2014 1:24 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >>>>> >>>>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: >>>>>> In an advertisement, the provider can indicate which other captures >>>>>> are referenced by an MCC, for example: >>>>>> >>>>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 >>>>>> >>>>>> MCC1(VC1, VC2) >>>>>> >>>>>> This means MCC1 can include VC1 and/or VC2, but not the others. >>>>>> >>>>>> MCC2() >>>>>> >>>>>> Without any specific references, this means the provider is not >>>>>> saying which other captures can be included in MCC2, and the >>>>>> consumer cannot choose. >>>>>> >>>>>> I propose adding a wildcard: >>>>>> >>>>>> MCC3(*) >>>>> >>>>> IIUC you mean this to be strictly a syntactic shortcut, not adding any >>>>> functionality that isn't present without it. >>>>> >>>>>> This means MCC3 can include any of the other captures VC1 through >>>>>> VC5, and the consumer can choose. >>>>> >>>>> Do you intent this to mean all the captures in the advertisement, or >>>>> all the captures in the same scene? >>>>> >>>>>> For some types of MCUs, that want to give consumers the choice of >>>>>> which specific captures to receive in an MCC, this is useful for >>>>>> large advertisements with many media captures. >>>>> >>>>> Perhaps. But I have my doubts that this would be of common use in >>>> practice. >>>>> >>>>> So it becomes a question of whether the added implementation burden of >>>>> supporting this optimization is justified for the number of cases when >>>>> it would be of use. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> When endpoints join or leave a >>>>>> conference, causing the advertisement to change to add or remove >>>>>> scenes and captures, the part of the advertisement with MCCs >>>>>> wouldn't have to change at all. >>>>>> >>>>>> Related text from framework-13: >>>>>> >>>>>> From 7.2: "The MCC may contain a reference to the Single Media >>>>>> Captures... (or) A MCC MAY contain no references to other Captures >>>>>> to indicate that the MCC contains content from multiple sources but >>>>>> no information regarding those sources is given." And in section 10 >>>>>> "If the MCC in the advertisement does not reference any individual >>>>>> captures, then the Consumer cannot choose what is included in the >>>>>> MCC" >>>>>> >>>>>> I propose adding text: >>>>>> >>>>>> The MCC may contain a wildcard reference, meaning it can refer to >>>>>> any of the other captures in the advertisement. The consumer, in a >>>>>> configure message, may choose which of the other media captures it >>>>>> wishes to receive in the MCC. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> 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 > From Mark.Duckworth@polycom.com Mon Jan 20 13:29: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 A13721A01CA for ; Mon, 20 Jan 2014 13:29:46 -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 6UOBmhT9VlTj for ; Mon, 20 Jan 2014 13:29:42 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1159F1A00A3 for ; Mon, 20 Jan 2014 13:29:41 -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; Mon, 20 Jan 2014 13:29:42 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 20 Jan 2014 13:29:39 -0800 Thread-Topic: [clue] spatial information can't describe video locations within composed MCC Thread-Index: Ac8WByqVpvofNxdJRhCfHEZUgegqgwAHwgFg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16388@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> In-Reply-To: <52DD6047.4030101@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] 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: Mon, 20 Jan 2014 21:29:46 -0000 Christian, I agree with Paul. Christian wrote: "I cannot see why in the static case spatial information i= sn'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 "sta= tic case" or not? I don't see any way for the consumer to know this. 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 wi= thin > 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. > > 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 the= y 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. > > So we need more info to understand your perspective on this. > > > From the minutes I didn't see an explanation of other people's concern= s. > > > > 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. The consumer could just use this, treating the MCC like any othe= r > 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. > > But none of that has anything to do with the the arrangement of composed > captures within an MCC. > > 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. > >> > >> > > > >> > >> > > < >> > >> > > 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 advertisemen= ts. > >> > >> > > >>> > >> > >> > > >>> 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 From Mark.Duckworth@polycom.com Mon Jan 20 13:31: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 AE55C1A01E1 for ; Mon, 20 Jan 2014 13:31:50 -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 SBMSgdPEq8-q for ; Mon, 20 Jan 2014 13:31:48 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 723FA1A00A3 for ; Mon, 20 Jan 2014 13:31:48 -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; Mon, 20 Jan 2014 13:31:48 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Mon, 20 Jan 2014 13:31:46 -0800 Thread-Topic: [clue] Advertising what is in an MCC - allow wildcard? Thread-Index: Ac8VgzFrgmneDc4rQAO8H90S5P/nVQAo6U2A Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF1638A@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC17C@CRPMBOXPRD07.polycom.com> <52CF5004.7040309@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CDDC4E5@CRPMBOXPRD07.polycom.com> <52DC82DE.5010508@nteczone.com> In-Reply-To: <52DC82DE.5010508@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] Advertising what is in an MCC - allow wildcard? 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, 20 Jan 2014 21:31:50 -0000 I'd like to stop this thread of discussion, it is superseded by the "MCC gr= ouping label" thread. Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Sunday, January 19, 2014 8:59 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >=20 > Hello Mark, >=20 > I'm not sure how useful an "all" would be if the scope is across all capt= ures in > the CLUE message rather than a particular scene. I would actually think t= hat a > range would be the more useful case. > Is there a reason why you don't like an ordered list? >=20 > Regards, Christian >=20 > On 11/01/2014 7:38 AM, Duckworth, Mark wrote: > > Christian, > > > > I intended the scope of the wildcard to refer to all other captures, no= t just > within the same scene. > > > > I'm against the range idea (MCC4(VC2-VC4)) because I think capture IDs > should be just an identifier, without implying some ordered list. > > > > Mark > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >> Groves > >> Sent: Thursday, January 09, 2014 8:42 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? > >> > >> Hello Mark, > >> > >> Please see my comments below. > >> > >> Regards, Christian > >> > >> On 10/01/2014 9:11 AM, Duckworth, Mark wrote: > >>> In an advertisement, the provider can indicate which other captures > >>> are referenced by an MCC, for example: > >>> > >>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 > >>> > >>> MCC1(VC1, VC2) > >>> > >>> This means MCC1 can include VC1 and/or VC2, but not the others. > >>> > >>> MCC2() > >>> > >>> Without any specific references, this means the provider is not > >>> saying which other captures can be included in MCC2, and the > >>> consumer cannot choose. > >>> > >>> I propose adding a wildcard: > >>> > >>> MCC3(*) > >>> > >>> This means MCC3 can include any of the other captures VC1 through > >>> VC5, and the consumer can choose. > >>> > >>> For some types of MCUs, that want to give consumers the choice of > >>> which specific captures to receive in an MCC, this is useful for > >>> large advertisements with many media captures. When endpoints join > >>> or leave a conference, causing the advertisement to change to add or > >>> remove scenes and captures, the part of the advertisement with MCCs > >>> wouldn't have to change at all. > >>> > >>> Related text from framework-13: > >>> > >>> From 7.2: "The MCC may contain a reference to the Single Media > >>> Captures... (or) A MCC MAY contain no references to other Captures > >>> to indicate that the MCC contains content from multiple sources but > >>> no information regarding those sources is given." And in section 10 > >>> "If the MCC in the advertisement does not reference any individual > >>> captures, then the Consumer cannot choose what is included in the > MCC" > >>> > >>> I propose adding text: > >>> > >>> The MCC may contain a wildcard reference, meaning it can refer to > >>> any of the other captures in the advertisement. The consumer, in a > >>> configure message, may choose which of the other media captures it > >>> wishes to receive in the MCC. > >>> > >>> What do you think? > >>> > >> [CNG] I'm supportive of adding a wildcard mechanism. It could help > >> shorten messages. I think we should be clear about what the scope of t= he > wildcard is. > >> i.e. is it the captures in the same scene as the MCC or across all > >> scenes in the Advertisement. > >> I think what may perhaps be additionally useful is to be able to > >> provide a range, i.e. MCC4(VC2-VC4). However this would imply that > >> captureIDs would have to have a numeric aspect. > >>> 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 Mark.Duckworth@polycom.com Mon Jan 20 13:46: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 4529D1A01F2 for ; Mon, 20 Jan 2014 13:46:17 -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 LNJMyF6v-a9R for ; Mon, 20 Jan 2014 13:46:15 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id BC7171A01BB for ; Mon, 20 Jan 2014 13:46:14 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 20 Jan 2014 13:46:15 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" , "Christian Groves (Christian.Groves@nteczone.com)" Date: Mon, 20 Jan 2014 13:46:12 -0800 Thread-Topic: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? Thread-Index: Ac8WC3twtaHAjDDVSl6jHz0CqfukCQAHI/sw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> In-Reply-To: <52DD6787.6060009@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 grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 20 Jan 2014 21:46:17 -0000 Paul and Christian, I was thinking much the same as Paul's approach 2. But maybe the configure= message could be limited to something like this?: - MCC() - MCC(capture1, capture2,...) In the configure message, I'm not sure there is an advantage to specifying = MCC subsets by label rather than always using capture ID. I always thought of the capture IDs as just a unique identifier, with no in= trinsic meaning, like GUIDs. That's why specifying groups of them with ran= ges (VC1 through VC4) or regular expressions doesn't make sense to me. Put= ting more meaning into the identifiers seems like a big change to me. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, January 20, 2014 1:15 PM > To: clue@ietf.org > Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MC= C - > allow wildcard? >=20 > On 1/19/14 9:55 PM, Christian Groves wrote: > > I'd like some more explanation of the concept before agreeing. > > > > The reason why I went with CaptureIDs for the MCC and the individual > > captures was to prevent yet another namespace in CLUE. It also worked > > in with the fact that the Consumer currently only returns CaptureIDs > > and EncodingIDs. Are we now saying that an Advertiser sends > > MCC1(label1) and if a Consumer wants a subset it returns MCC(Capture1, > > Capture2, Capture3, etc?). I particularly avoided the use of > > attributes for this because CLUE Configures don't reference attributes. >=20 > My thought was that the the consumer could return: >=20 > - MCC() > - MCC(capture1, capture2, ...) > - MCC(label1) > - MCC(label1, label2, ...) > - MCC(capture1, label1, ...) >=20 > > Why couldn't CLUE simply have pattern matching based on regular > > expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.). >=20 > That is a possibility. I question whether it is simpler. I guess it does = make > advertisements smaller. >=20 > Thanks, > Paul >=20 > > Christian > > > > > > On 19/01/2014 4:20 AM, Paul Kyzivat wrote: > >> On 1/17/14 6:12 PM, Duckworth, Mark wrote: > >>> We discussed this topic in the Jan 14 design team meeting. The > >>> group had interest in the concept, but not my specific proposal. > >>> Jonathan had an interesting idea, which I think better serves the > purpose. > >>> > >>> Instead of the MCC referring specifically to other media captures > >>> that can be contained within the MCC, the MCC can refer to zero or > >>> more "MCC grouping labels". Any other media capture can include an > >>> attribute (zero or more) with a particular MCC grouping label. The > >>> meaning is that any MC that has the same grouping label that is > >>> reference by an MCC can be included in that MCC. > >>> > >>> I think this doesn't change at all the meaning of MCC, but it will > >>> affect the syntax of how we describe it in the data model for CLUE > >>> messages. > >>> > >>> If the group agrees with this concept, I can propose specific > >>> changes to the framework. > >> > >> This WFM, conceptually. > >> There are details to be worked out for this to be practical and > >> convenient. Those details will presumably be in the data model. > >> > >> Specifically, in the declaration of the MCC, there must be some > >> syntax for the reference. Two approaches come to mind: > >> > >> 1) the new labels share a single namespace with capture ids in the > >> advertisement. The MCC declaration has an element that is used to > >> reference these IDs, of either kind. You can tell which kind by > >> resolving the reference. > >> > >> 2) the new labels have a distinct namespace from capture ids. The MCC > >> declaration allows two different kinds of elements, one to reference > >> capture ids, and another to reference these new labels. > >> > >> I'm inclined to prefer (2) - it seems less kludgy, and is probably > >> equally concise. > >> > >> Thanks, > >> Paul > >> > >> > >> > >>> Mark > >>> > >>>> -----Original Message----- > >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, > >>>> Mark > >>>> Sent: Friday, January 10, 2014 3:47 PM > >>>> To: Paul Kyzivat; clue@ietf.org > >>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? > >>>> > >>>> Paul, > >>>> > >>>> Yes, I think the wildcard is just a syntax shortcut. > >>>> One other impact that I was thinking of is if we decide to have > >>>> partial updates of advertisements then it removes the need to > >>>> re-advertise any MCC(*) captures when other captures change. > >>>> Without wildcard, any other addition or removal of a contributing > >>>> capture means also re-advertising every MCC with a new list of > >>>> contributors. > >>>> I think the wildcard fits very nicely with the switching scenario > >>>> option (2) from the other discussion thread. > >>>> > >>>> Mark > >>>> > >>>>> -----Original Message----- > >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul > >>>>> Kyzivat > >>>>> Sent: Friday, January 10, 2014 1:24 PM > >>>>> To: clue@ietf.org > >>>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? > >>>>> > >>>>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: > >>>>>> In an advertisement, the provider can indicate which other > >>>>>> captures are referenced by an MCC, for example: > >>>>>> > >>>>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 > >>>>>> > >>>>>> MCC1(VC1, VC2) > >>>>>> > >>>>>> This means MCC1 can include VC1 and/or VC2, but not the others. > >>>>>> > >>>>>> MCC2() > >>>>>> > >>>>>> Without any specific references, this means the provider is not > >>>>>> saying which other captures can be included in MCC2, and the > >>>>>> consumer cannot choose. > >>>>>> > >>>>>> I propose adding a wildcard: > >>>>>> > >>>>>> MCC3(*) > >>>>> > >>>>> IIUC you mean this to be strictly a syntactic shortcut, not adding > >>>>> any functionality that isn't present without it. > >>>>> > >>>>>> This means MCC3 can include any of the other captures VC1 through > >>>>>> VC5, and the consumer can choose. > >>>>> > >>>>> Do you intent this to mean all the captures in the advertisement, > >>>>> or all the captures in the same scene? > >>>>> > >>>>>> For some types of MCUs, that want to give consumers the choice of > >>>>>> which specific captures to receive in an MCC, this is useful for > >>>>>> large advertisements with many media captures. > >>>>> > >>>>> Perhaps. But I have my doubts that this would be of common use in > >>>> practice. > >>>>> > >>>>> So it becomes a question of whether the added implementation > >>>>> burden of supporting this optimization is justified for the number > >>>>> of cases when it would be of use. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>>> When endpoints join or leave a > >>>>>> conference, causing the advertisement to change to add or remove > >>>>>> scenes and captures, the part of the advertisement with MCCs > >>>>>> wouldn't have to change at all. > >>>>>> > >>>>>> Related text from framework-13: > >>>>>> > >>>>>> From 7.2: "The MCC may contain a reference to the Single Media > >>>>>> Captures... (or) A MCC MAY contain no references to other > >>>>>> Captures to indicate that the MCC contains content from multiple > >>>>>> sources but no information regarding those sources is given." > >>>>>> And in section 10 "If the MCC in the advertisement does not > >>>>>> reference any individual captures, then the Consumer cannot > >>>>>> choose what is included in the MCC" > >>>>>> > >>>>>> I propose adding text: > >>>>>> > >>>>>> The MCC may contain a wildcard reference, meaning it can refer to > >>>>>> any of the other captures in the advertisement. The consumer, in > >>>>>> a configure message, may choose which of the other media captures > >>>>>> it wishes to receive in the MCC. > >>>>>> > >>>>>> What do you think? > >>>>>> > >>>>>> 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 > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Mon Jan 20 14:09: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 3F3591A021C for ; Mon, 20 Jan 2014 14:09: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 NdOpYnkN0hot for ; Mon, 20 Jan 2014 14:09:55 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 768DD1A01F2 for ; Mon, 20 Jan 2014 14:09:55 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 20 Jan 2014 14:09:55 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Mon, 20 Jan 2014 14:09:53 -0800 Thread-Topic: [clue] multipoint switching, MCC, and spatial information Thread-Index: Ac8UhUELEXkTVgIEQZa0EgF+j1TViABpnSDw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF163C9@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@CRPMBOXPRD07.polycom.com> <52DAD8D1.9030904@alum.mit.edu> In-Reply-To: <52DAD8D1.9030904@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] multipoint switching, MCC, and spatial 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: Mon, 20 Jan 2014 22:09:58 -0000 Paul, I agree with what you wrote. Now I'm trying to figure out which type of consumer (simple, more sophistic= ated, or most sophisticated) is necessary in order to implement the scenari= o in the section 12.3.3 example. I was thinking it was only the most sophi= sticated kind, but I was hoping you all had a better idea and could show me= how it works with a less sophisticated consumer. In the design team discu= ssion last week, I got the sense that some people thought the simple consum= er could do it, for both of the layout options in the diagram below, but I = still don't see how. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Saturday, January 18, 2014 2:41 PM > To: clue@ietf.org > Subject: Re: [clue] multipoint switching, MCC, and spatial information >=20 > Mark, >=20 > My thinking is that the advertiser MAY include spatial coordinates on the > MCCs if it wishes. If so, then they are virtual coordinates for that capt= ure in > the context of the scene containing the MCC. How the advertiser arrives a= t > these coordinates is its business. It might look at the spatial relations= hips of > the source captures to do this, or not. >=20 > A simple consumer can simply treat an MCC like any other capture, and mak= e > all of its decisions about how to render it based on the MCC coordinates.= This > might be sub-optimal, but its easy. >=20 > A more sophisticated consumer can look at the sources of the MCC captures= , > and their coordinates in their scenes, and use that to make its decisions > about how to render. It can do that statically (at the time of Configure) > without regard to which of the alternatives is switched in at any one tim= e. > (This is somewhat sub-optimal.) >=20 > Or the most sophisticated consumer can see what it is receiving in each R= TP > packet, map this back to a particular source capture in the advertisement= , > and then use the spatial coordinates from that to make rendering decision= s. > (We need to figure out how that mapping an be done.) >=20 > The advertiser doesn't need to know which way the consumer is doing it. > But the information provided in the advertisement constrains what the > consumer is able to do. >=20 > Thanks, > Paul >=20 > On 1/17/14 6:44 PM, Duckworth, Mark wrote: > > This is follow-up to the topic "[clue] MCC switching example", and to > > the design team discussion Jan 14. I'm interested in what others have > > to say about how approach #1 should work, regarding spatial > > information and the consumer's ability to render streams together that > belong together. > > > > Referring to my framework issue slides > > > am/Framework_Issues_140113.pptx>, pages 8 - 12. The group had > > interest mainly in approach #1, where the MCU makes all the switching > > decisions. But we didn't have a common understanding about how > > spatial information was to be conveyed, so the consumer can render > > multiple streams together when they are spatially related. > > > > On slide 9, for approach 1, it says "MCCs don't have spatial > > attributes". But other people in the discussion thought the MCCs > > should have spatial attributes. Jonathan said the MCCs could have > > spatial information like this (Jonathan, correct me if I don't remember > right): > > > > MCC1, MCC2, MCC3: left, center, and right of the full scene, like the > > image on page 6 for VC1-3. > > > > MCC4, MCC5, MCC6: spatial information that indicates they are located > > on bottom part of MCC1, and much smaller than MCC1, like on page 6 for > VC4-6. > > > > MCC7, MCC8, MCC9: spatial information that indicates they are located > > on bottom part of MCC2, and much smaller than MCC2, like on page 6 for > VC7-9. > > > > While this should work for that specific case, I don't think it works > > for the very similar case in framework section 12.3.3 which has these > > two alternative rendering layouts for the same streams (use > > mono-spaced font to see this): > > > > +---+---+---+ +-------------+ +-------------+ +-------------+ > > > > | | | | | | | | | | > > > > +---+---+---+ | | | | | | > > > > | | | | | | | | | | > > > > +---+---+---+ | | | | | | > > > > | | | | | | | | | | > > > > +---+---+---+ +-------------+ +-------------+ +-------------+ > > > > +-------------+ +-------------+ +-------------+ > > > > | | | | | | > > > > | | | | | | > > > > | | | | | | > > > > | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | > > > > | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | > > > > +-------------+ +-------------+ +-------------+ > > > > If we generalize this approach to support alternatives like this, I > > think we end up with approach number 3 instead of approach 1. > > > > We also talked about the consumer should have the ability to associate > > incoming encoded packet streams with a particular individual MC from > > the advertisement. This would give the consumer the spatial > > information of the particular MC currently switched in to the MCC. My > > concern about this way of getting spatial information is that it means > > the renderer has to re-map decoder output to different display > > locations on the fly without any advance notice. > > > > 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 pkyzivat@alum.mit.edu Mon Jan 20 14:15: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 D76D91A0240 for ; Mon, 20 Jan 2014 14:15:20 -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 nC0lfwX9E5it for ; Mon, 20 Jan 2014 14:15:19 -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 B31E81A0233 for ; Mon, 20 Jan 2014 14:15:18 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id GLqk1n00216LCl055NFJjp; Mon, 20 Jan 2014 22:15:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id GNFJ1n0043ZTu2S3SNFJrY; Mon, 20 Jan 2014 22:15:18 +0000 Message-ID: <52DD9FF5.2050602@alum.mit.edu> Date: Mon, 20 Jan 2014 17:15:17 -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: "Duckworth, Mark" , "clue@ietf.org" , "Christian Groves (Christian.Groves@nteczone.com)" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@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=1390256118; bh=gAacLmG0ZEKcDxPq1eiXyhqiyDXe4emBLoAZfEsCy2A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DZWyWiVqkjCKbAArRyW8f2D+UoDHtR5Dq9AlCgVBseitaQUo9tIuYdx4BixtOckWJ VaKKcoCOo8hK2tTmuArmehAh4lbzDtd8UrZ6dhHxHp32AQplGWLXN8mp56RkD0Nmkf p8+5jkq+pnN3ugJwWpJkcK7qPPGVipIVTcgsKsSgNWM5TNHoJ3bwM0HBASIqGsrdl2 x4nuxomzXXQesR8LLuwn+c3c4abTZnNatJwcmdUjaTO4TCT5TOXnJsFhP8B01rPHsr 70yE9z0yEAuBrjzsKk2XLfq8LA60pzpoLcAANuSSxhzXI5SGyhx69MONTpSPcWVzsQ nx5HOMuZejMQg== Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 20 Jan 2014 22:15:21 -0000 Hmm. I now realize I didn't say what I meant. What I meant was: My thought was that the the advertiser could specify *any* of: - MCC(capture1, capture2, ...) - MCC(label1) - MCC(label1, label2, ...) - MCC(capture1, label1, ...) While the consumer could return either of: - MCC() - MCC(capture1, capture2, ...) Sorry, Paul On 1/20/14 4:46 PM, Duckworth, Mark wrote: > Paul and Christian, > > I was thinking much the same as Paul's approach 2. But maybe the configure message could be limited to something like this?: > - MCC() > - MCC(capture1, capture2,...) > > In the configure message, I'm not sure there is an advantage to specifying MCC subsets by label rather than always using capture ID. > > I always thought of the capture IDs as just a unique identifier, with no intrinsic meaning, like GUIDs. That's why specifying groups of them with ranges (VC1 through VC4) or regular expressions doesn't make sense to me. Putting more meaning into the identifiers seems like a big change to me. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, January 20, 2014 1:15 PM >> To: clue@ietf.org >> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - >> allow wildcard? >> >> On 1/19/14 9:55 PM, Christian Groves wrote: >>> I'd like some more explanation of the concept before agreeing. >>> >>> The reason why I went with CaptureIDs for the MCC and the individual >>> captures was to prevent yet another namespace in CLUE. It also worked >>> in with the fact that the Consumer currently only returns CaptureIDs >>> and EncodingIDs. Are we now saying that an Advertiser sends >>> MCC1(label1) and if a Consumer wants a subset it returns MCC(Capture1, >>> Capture2, Capture3, etc?). I particularly avoided the use of >>> attributes for this because CLUE Configures don't reference attributes. >> >> My thought was that the the consumer could return: >> >> - MCC() >> - MCC(capture1, capture2, ...) >> - MCC(label1) >> - MCC(label1, label2, ...) >> - MCC(capture1, label1, ...) >> >>> Why couldn't CLUE simply have pattern matching based on regular >>> expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.). >> >> That is a possibility. I question whether it is simpler. I guess it does make >> advertisements smaller. >> >> Thanks, >> Paul >> >>> Christian >>> >>> >>> On 19/01/2014 4:20 AM, Paul Kyzivat wrote: >>>> On 1/17/14 6:12 PM, Duckworth, Mark wrote: >>>>> We discussed this topic in the Jan 14 design team meeting. The >>>>> group had interest in the concept, but not my specific proposal. >>>>> Jonathan had an interesting idea, which I think better serves the >> purpose. >>>>> >>>>> Instead of the MCC referring specifically to other media captures >>>>> that can be contained within the MCC, the MCC can refer to zero or >>>>> more "MCC grouping labels". Any other media capture can include an >>>>> attribute (zero or more) with a particular MCC grouping label. The >>>>> meaning is that any MC that has the same grouping label that is >>>>> reference by an MCC can be included in that MCC. >>>>> >>>>> I think this doesn't change at all the meaning of MCC, but it will >>>>> affect the syntax of how we describe it in the data model for CLUE >>>>> messages. >>>>> >>>>> If the group agrees with this concept, I can propose specific >>>>> changes to the framework. >>>> >>>> This WFM, conceptually. >>>> There are details to be worked out for this to be practical and >>>> convenient. Those details will presumably be in the data model. >>>> >>>> Specifically, in the declaration of the MCC, there must be some >>>> syntax for the reference. Two approaches come to mind: >>>> >>>> 1) the new labels share a single namespace with capture ids in the >>>> advertisement. The MCC declaration has an element that is used to >>>> reference these IDs, of either kind. You can tell which kind by >>>> resolving the reference. >>>> >>>> 2) the new labels have a distinct namespace from capture ids. The MCC >>>> declaration allows two different kinds of elements, one to reference >>>> capture ids, and another to reference these new labels. >>>> >>>> I'm inclined to prefer (2) - it seems less kludgy, and is probably >>>> equally concise. >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>> >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, >>>>>> Mark >>>>>> Sent: Friday, January 10, 2014 3:47 PM >>>>>> To: Paul Kyzivat; clue@ietf.org >>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >>>>>> >>>>>> Paul, >>>>>> >>>>>> Yes, I think the wildcard is just a syntax shortcut. >>>>>> One other impact that I was thinking of is if we decide to have >>>>>> partial updates of advertisements then it removes the need to >>>>>> re-advertise any MCC(*) captures when other captures change. >>>>>> Without wildcard, any other addition or removal of a contributing >>>>>> capture means also re-advertising every MCC with a new list of >>>>>> contributors. >>>>>> I think the wildcard fits very nicely with the switching scenario >>>>>> option (2) from the other discussion thread. >>>>>> >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>>>> Kyzivat >>>>>>> Sent: Friday, January 10, 2014 1:24 PM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >>>>>>> >>>>>>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: >>>>>>>> In an advertisement, the provider can indicate which other >>>>>>>> captures are referenced by an MCC, for example: >>>>>>>> >>>>>>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 >>>>>>>> >>>>>>>> MCC1(VC1, VC2) >>>>>>>> >>>>>>>> This means MCC1 can include VC1 and/or VC2, but not the others. >>>>>>>> >>>>>>>> MCC2() >>>>>>>> >>>>>>>> Without any specific references, this means the provider is not >>>>>>>> saying which other captures can be included in MCC2, and the >>>>>>>> consumer cannot choose. >>>>>>>> >>>>>>>> I propose adding a wildcard: >>>>>>>> >>>>>>>> MCC3(*) >>>>>>> >>>>>>> IIUC you mean this to be strictly a syntactic shortcut, not adding >>>>>>> any functionality that isn't present without it. >>>>>>> >>>>>>>> This means MCC3 can include any of the other captures VC1 through >>>>>>>> VC5, and the consumer can choose. >>>>>>> >>>>>>> Do you intent this to mean all the captures in the advertisement, >>>>>>> or all the captures in the same scene? >>>>>>> >>>>>>>> For some types of MCUs, that want to give consumers the choice of >>>>>>>> which specific captures to receive in an MCC, this is useful for >>>>>>>> large advertisements with many media captures. >>>>>>> >>>>>>> Perhaps. But I have my doubts that this would be of common use in >>>>>> practice. >>>>>>> >>>>>>> So it becomes a question of whether the added implementation >>>>>>> burden of supporting this optimization is justified for the number >>>>>>> of cases when it would be of use. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> When endpoints join or leave a >>>>>>>> conference, causing the advertisement to change to add or remove >>>>>>>> scenes and captures, the part of the advertisement with MCCs >>>>>>>> wouldn't have to change at all. >>>>>>>> >>>>>>>> Related text from framework-13: >>>>>>>> >>>>>>>> From 7.2: "The MCC may contain a reference to the Single Media >>>>>>>> Captures... (or) A MCC MAY contain no references to other >>>>>>>> Captures to indicate that the MCC contains content from multiple >>>>>>>> sources but no information regarding those sources is given." >>>>>>>> And in section 10 "If the MCC in the advertisement does not >>>>>>>> reference any individual captures, then the Consumer cannot >>>>>>>> choose what is included in the MCC" >>>>>>>> >>>>>>>> I propose adding text: >>>>>>>> >>>>>>>> The MCC may contain a wildcard reference, meaning it can refer to >>>>>>>> any of the other captures in the advertisement. The consumer, in >>>>>>>> a configure message, may choose which of the other media captures >>>>>>>> it wishes to receive in the MCC. >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> 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 > From Mark.Duckworth@polycom.com Mon Jan 20 14: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 43F1A1A0255 for ; Mon, 20 Jan 2014 14:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.136 X-Spam-Level: X-Spam-Status: No, score=-4.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=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 d79TbBMWRbKX for ; Mon, 20 Jan 2014 14:16:03 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5C11A0240 for ; Mon, 20 Jan 2014 14:16: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; Mon, 20 Jan 2014 14:16:03 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Mon, 20 Jan 2014 14:16:01 -0800 Thread-Topic: [clue] multipoint switching, MCC, and spatial information Thread-Index: Ac8VkPtjb5i7mVQgSMyGGVvR+1aN1wAm4LKQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF163D1@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@CRPMBOXPRD07.polycom.com> <52DAD8D1.9030904@alum.mit.edu> <52DC9A00.4010609@nteczone.com> In-Reply-To: <52DC9A00.4010609@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] multipoint switching, MCC, and spatial 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: Mon, 20 Jan 2014 22:16:06 -0000 Christian, Your first approach for the way the "small boxes" could be advertised sound= s to me like the advertiser is expecting the consumer to be able to separat= e the top, middle, and bottom rows within the 3x3 grid scene into three sep= arate areas for rendering. This would be better done by using three separa= te scenes in the first place, not just one scene. Three separate scenes is= an example of my approach #3 from the slides. I'm still focusing on the media-switching variety of MCU, so I am looking f= or solution that doesn't involve composition in the MCU. But I do agree yo= ur composition examples make sense if the MCU is capable of it. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Sunday, January 19, 2014 10:38 PM > To: clue@ietf.org > Subject: Re: [clue] multipoint switching, MCC, and spatial information >=20 > Hello Mark, >=20 > I agree with Paul's comments. >=20 > Please see my additional comments below. >=20 > Regards, Christian >=20 > On 19/01/2014 6:41 AM, Paul Kyzivat wrote: > > Mark, > > > > My thinking is that the advertiser MAY include spatial coordinates on > > the MCCs if it wishes. If so, then they are virtual coordinates for > > that capture in the context of the scene containing the MCC. How the > > advertiser arrives at these coordinates is its business. It might look > > at the spatial relationships of the source captures to do this, or not. > > > > A simple consumer can simply treat an MCC like any other capture, and > > make all of its decisions about how to render it based on the MCC > > coordinates. This might be sub-optimal, but its easy. > > > > A more sophisticated consumer can look at the sources of the MCC > > captures, and their coordinates in their scenes, and use that to make > > its decisions about how to render. It can do that statically (at the > > time of Configure) without regard to which of the alternatives is > > switched in at any one time. (This is somewhat sub-optimal.) > > > > Or the most sophisticated consumer can see what it is receiving in > > each RTP packet, map this back to a particular source capture in the > > advertisement, and then use the spatial coordinates from that to make > > rendering decisions. (We need to figure out how that mapping an be > > done.) > > > > The advertiser doesn't need to know which way the consumer is doing > > it. But the information provided in the advertisement constrains what > > the consumer is able to do. > > > > Thanks, > > Paul > > > > On 1/17/14 6:44 PM, Duckworth, Mark wrote: > >> This is follow-up to the topic "[clue] MCC switching example", and to > >> the design team discussion Jan 14. I'm interested in what others > >> have to say about how approach #1 should work, regarding spatial > >> information and the consumer's ability to render streams together > >> that belong together. > >> > >> Referring to my framework issue slides > >> >> eam/Framework_Issues_140113.pptx>, > >> > >> pages 8 - 12. The group had interest mainly in approach #1, where > >> the MCU makes all the switching decisions. But we didn't have a > >> common understanding about how spatial information was to be > >> conveyed, so the consumer can render multiple streams together when > >> they are spatially related. > >> > >> On slide 9, for approach 1, it says "MCCs don't have spatial > >> attributes". But other people in the discussion thought the MCCs > >> should have spatial attributes. Jonathan said the MCCs could have > >> spatial information like this (Jonathan, correct me if I don't remembe= r > right): > >> > >> MCC1, MCC2, MCC3: left, center, and right of the full scene, like the > >> image on page 6 for VC1-3. > >> > >> MCC4, MCC5, MCC6: spatial information that indicates they are located > >> on bottom part of MCC1, and much smaller than MCC1, like on page 6 > >> for VC4-6. > >> > >> MCC7, MCC8, MCC9: spatial information that indicates they are located > >> on bottom part of MCC2, and much smaller than MCC2, like on page 6 > >> for VC7-9. > [CNG] Yes MCCs could have spatial information in this context. > >> > >> While this should work for that specific case, I don't think it works > >> for the very similar case in framework section 12.3.3 which has these > >> two alternative rendering layouts for the same streams (use > >> mono-spaced font to see this): > >> > >> +---+---+---+ +-------------+ +-------------+ +-------------+ > >> > >> | | | | | | | | | | > >> > >> +---+---+---+ | | | | | | > >> > >> | | | | | | | | | | > >> > >> +---+---+---+ | | | | | | > >> > >> | | | | | | | | | | > >> > >> +---+---+---+ +-------------+ +-------------+ +-------------+ > >> > >> +-------------+ +-------------+ +-------------+ > >> > >> | | | | | | > >> > >> | | | | | | > >> > >> | | | | | | > >> > >> | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | > >> > >> | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | > >> > >> +-------------+ +-------------+ +-------------+ > >> > >> If we generalize this approach to support alternatives like this, I > >> think we end up with approach number 3 instead of approach 1. > [CNG] Table 22 in section 12.3.3 of the framework has spatial information= for > MCC1,MCC2,MCC3 (incorrectly labelled as left,left,left it should be left, > centre, right). This would be related to the "large" > boxes above. I don't think there's an issue with this. >=20 > There are a number of ways that the "small" boxes could be advertised. >=20 > The first is as per table 23 of the framework. Each of the MCCs > (MMC4-MCC12) could be given a virtual spatial area. i.e. each MCC stream > has its own space. i.e. MCC4(top left), MCC5(top centre), MCC6(top right, > etc.) It's then up to the consumer to decide how to render it. > The Consumer could do either of the above approaches. >=20 > A second approach is a per table 24 of the framework. If MCC13 was in > CaptureScene8 it could use spatial information of the constituent MCCs to > determine the position in the composed single stream. Unless the Consumer > had the smarts to "decompose" the media stream then it would only be able > to the top approach. >=20 > A third approach would be for the Provider to Advertise 3 streams for the= 9 > tiles (this isn't shown in the framework), e.g. >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > + > | Capture Scene # | Description=3DOutput3stream | > +-----------------------|---------------------------------+ > | MCC4(VC4,VC5,VC6,VC7, | MaxCaptures=3D1 | > | VC8,VC9,VC10,VC11, | Policy=3DSoundLevel:0 | > | VC12,VC13,VC14,VC15)| SpatialInfo=3DTop Left | > | | | > | MCC5(VC4,VC5,VC6,VC7, | MaxCaptures=3D1 | > | VC8,VC9,VC10,VC11, | Policy=3DSoundLevel:1 | > | VC12,VC13,VC14,VC15)| SpatialInfo=3DTop Middle | > | | | > to to | > | | | > | MCC12(VC4,VC5,VC6,VC7,| MaxCaptures=3D1 | > | VC8,VC9,VC10,VC11, | Policy=3DSoundLevel:8 | > | VC12,VC13,VC14,VC15)| SpatialInfo=3DBottom Right | > | | | > | MCC13(MCC4,MCC5,MCC6 | MaxCaptures=3D3 | > | | EncodingGroup=3D1 | > | | SpatialInfo=3DTop | > | MCC14(MCC7,MCC8,MCC9 | MaxCaptures=3D3 | > | | EncodingGroup=3D1 | > | | SpatialInfo=3DMiddle | > | MCC15(MCC10,MCC11, | MaxCaptures=3D3 | > | MCC12) | EncodingGroup=3D1 | > | | SpatialInfo=3DBottom | > | CSE(MCC13,MCC14,MCC15)| | >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > + >=20 > In the above case the Provider Advertises 3 encodings MCC13 containing th= e > three most active speakers, MCC14 containing the next three most active > etc. Note that the MCC13-15 are static, always maintaining the spatial co= - > ordinates. Because the Consumer receives 3 streams it could display these= 3 > streams in either the 9 tiles approach or the PiP approach. >=20 > As Paul said, the information received from the Advertiser constrains wha= t > the Consumer is able to do. >=20 >=20 > >> > >> We also talked about the consumer should have the ability to associate > >> incoming encoded packet streams with a particular individual MC from t= he > >> advertisement. This would give the consumer the spatial information o= f > >> the particular MC currently switched in to the MCC. My concern about > >> this way of getting spatial information is that it means the renderer > >> has to re-map decoder output to different display locations on the fly > >> without any advance notice. > >> > >> 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 > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Mon Jan 20 14:40: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 1CF9F1A0258 for ; Mon, 20 Jan 2014 14:40:52 -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 9cIkbvpgtvar for ; Mon, 20 Jan 2014 14:40:49 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869511A0259 for ; Mon, 20 Jan 2014 14:40:48 -0800 (PST) Received: from ppp118-209-127-72.lns20.mel4.internode.on.net ([118.209.127.72]:51077 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5NTW-0004CZ-9x; Tue, 21 Jan 2014 09:37:46 +1100 Message-ID: <52DDA5EE.9090403@nteczone.com> Date: Tue, 21 Jan 2014 09:40:46 +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: Paul Kyzivat , "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> In-Reply-To: <52DD9FF5.2050602@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 grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 20 Jan 2014 22:40:52 -0000 I think before going for the label approach I think it would be worth to go through some examples and compare the size of the messages, i.e. comparing using the CaptureIDs vs Labels. Actually I think we need some more examples in general to understand the savings for wildcarding. If you have to specify an attribute with possibly several labels on each Capture then we might not be saving much (if anything) for the complexity. Also if we mix captures and label then I assume that we have to define the name space for each to ensure they didn't overlap? Currently captureIDs could be anything. With respect to putting meaning into the CaptureIDs is it really a big change for captureIDs to have some meaning within the session? Our convention in the framework of ACx, VCx, etc seems to be working quite well. I'm not sure why you'd want the CaptureID to be globally unique like a GUID? That seems like overkill. If people are assuming that CaptureIDs are globally unique across a MCU or network then I think we need to discuss that because I not sure everyone has the same view. Regards, Christian On 21/01/2014 9:15 AM, Paul Kyzivat wrote: > Hmm. I now realize I didn't say what I meant. What I meant was: > > My thought was that the the advertiser could specify *any* of: > > - MCC(capture1, capture2, ...) > - MCC(label1) > - MCC(label1, label2, ...) > - MCC(capture1, label1, ...) > > While the consumer could return either of: > > - MCC() > - MCC(capture1, capture2, ...) > > Sorry, > Paul > > > On 1/20/14 4:46 PM, Duckworth, Mark wrote: >> Paul and Christian, >> >> I was thinking much the same as Paul's approach 2. But maybe the >> configure message could be limited to something like this?: >> - MCC() >> - MCC(capture1, capture2,...) >> >> In the configure message, I'm not sure there is an advantage to >> specifying MCC subsets by label rather than always using capture ID. >> >> I always thought of the capture IDs as just a unique identifier, with >> no intrinsic meaning, like GUIDs. That's why specifying groups of >> them with ranges (VC1 through VC4) or regular expressions doesn't >> make sense to me. Putting more meaning into the identifiers seems >> like a big change to me. >> >> Mark >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: Monday, January 20, 2014 1:15 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in >>> an MCC - >>> allow wildcard? >>> >>> On 1/19/14 9:55 PM, Christian Groves wrote: >>>> I'd like some more explanation of the concept before agreeing. >>>> >>>> The reason why I went with CaptureIDs for the MCC and the individual >>>> captures was to prevent yet another namespace in CLUE. It also worked >>>> in with the fact that the Consumer currently only returns CaptureIDs >>>> and EncodingIDs. Are we now saying that an Advertiser sends >>>> MCC1(label1) and if a Consumer wants a subset it returns MCC(Capture1, >>>> Capture2, Capture3, etc?). I particularly avoided the use of >>>> attributes for this because CLUE Configures don't reference >>>> attributes. >>> >>> My thought was that the the consumer could return: >>> >>> - MCC() >>> - MCC(capture1, capture2, ...) >>> - MCC(label1) >>> - MCC(label1, label2, ...) >>> - MCC(capture1, label1, ...) >>> >>>> Why couldn't CLUE simply have pattern matching based on regular >>>> expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.). >>> >>> That is a possibility. I question whether it is simpler. I guess it >>> does make >>> advertisements smaller. >>> >>> Thanks, >>> Paul >>> >>>> Christian >>>> >>>> >>>> On 19/01/2014 4:20 AM, Paul Kyzivat wrote: >>>>> On 1/17/14 6:12 PM, Duckworth, Mark wrote: >>>>>> We discussed this topic in the Jan 14 design team meeting. The >>>>>> group had interest in the concept, but not my specific proposal. >>>>>> Jonathan had an interesting idea, which I think better serves the >>> purpose. >>>>>> >>>>>> Instead of the MCC referring specifically to other media captures >>>>>> that can be contained within the MCC, the MCC can refer to zero or >>>>>> more "MCC grouping labels". Any other media capture can include an >>>>>> attribute (zero or more) with a particular MCC grouping label. The >>>>>> meaning is that any MC that has the same grouping label that is >>>>>> reference by an MCC can be included in that MCC. >>>>>> >>>>>> I think this doesn't change at all the meaning of MCC, but it will >>>>>> affect the syntax of how we describe it in the data model for CLUE >>>>>> messages. >>>>>> >>>>>> If the group agrees with this concept, I can propose specific >>>>>> changes to the framework. >>>>> >>>>> This WFM, conceptually. >>>>> There are details to be worked out for this to be practical and >>>>> convenient. Those details will presumably be in the data model. >>>>> >>>>> Specifically, in the declaration of the MCC, there must be some >>>>> syntax for the reference. Two approaches come to mind: >>>>> >>>>> 1) the new labels share a single namespace with capture ids in the >>>>> advertisement. The MCC declaration has an element that is used to >>>>> reference these IDs, of either kind. You can tell which kind by >>>>> resolving the reference. >>>>> >>>>> 2) the new labels have a distinct namespace from capture ids. The MCC >>>>> declaration allows two different kinds of elements, one to reference >>>>> capture ids, and another to reference these new labels. >>>>> >>>>> I'm inclined to prefer (2) - it seems less kludgy, and is probably >>>>> equally concise. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> >>>>> >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, >>>>>>> Mark >>>>>>> Sent: Friday, January 10, 2014 3:47 PM >>>>>>> To: Paul Kyzivat; clue@ietf.org >>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >>>>>>> >>>>>>> Paul, >>>>>>> >>>>>>> Yes, I think the wildcard is just a syntax shortcut. >>>>>>> One other impact that I was thinking of is if we decide to have >>>>>>> partial updates of advertisements then it removes the need to >>>>>>> re-advertise any MCC(*) captures when other captures change. >>>>>>> Without wildcard, any other addition or removal of a contributing >>>>>>> capture means also re-advertising every MCC with a new list of >>>>>>> contributors. >>>>>>> I think the wildcard fits very nicely with the switching scenario >>>>>>> option (2) from the other discussion thread. >>>>>>> >>>>>>> Mark >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>>>>> Kyzivat >>>>>>>> Sent: Friday, January 10, 2014 1:24 PM >>>>>>>> To: clue@ietf.org >>>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow >>>>>>>> wildcard? >>>>>>>> >>>>>>>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: >>>>>>>>> In an advertisement, the provider can indicate which other >>>>>>>>> captures are referenced by an MCC, for example: >>>>>>>>> >>>>>>>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 >>>>>>>>> >>>>>>>>> MCC1(VC1, VC2) >>>>>>>>> >>>>>>>>> This means MCC1 can include VC1 and/or VC2, but not the others. >>>>>>>>> >>>>>>>>> MCC2() >>>>>>>>> >>>>>>>>> Without any specific references, this means the provider is not >>>>>>>>> saying which other captures can be included in MCC2, and the >>>>>>>>> consumer cannot choose. >>>>>>>>> >>>>>>>>> I propose adding a wildcard: >>>>>>>>> >>>>>>>>> MCC3(*) >>>>>>>> >>>>>>>> IIUC you mean this to be strictly a syntactic shortcut, not adding >>>>>>>> any functionality that isn't present without it. >>>>>>>> >>>>>>>>> This means MCC3 can include any of the other captures VC1 through >>>>>>>>> VC5, and the consumer can choose. >>>>>>>> >>>>>>>> Do you intent this to mean all the captures in the advertisement, >>>>>>>> or all the captures in the same scene? >>>>>>>> >>>>>>>>> For some types of MCUs, that want to give consumers the choice of >>>>>>>>> which specific captures to receive in an MCC, this is useful for >>>>>>>>> large advertisements with many media captures. >>>>>>>> >>>>>>>> Perhaps. But I have my doubts that this would be of common use in >>>>>>> practice. >>>>>>>> >>>>>>>> So it becomes a question of whether the added implementation >>>>>>>> burden of supporting this optimization is justified for the number >>>>>>>> of cases when it would be of use. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> When endpoints join or leave a >>>>>>>>> conference, causing the advertisement to change to add or remove >>>>>>>>> scenes and captures, the part of the advertisement with MCCs >>>>>>>>> wouldn't have to change at all. >>>>>>>>> >>>>>>>>> Related text from framework-13: >>>>>>>>> >>>>>>>>> From 7.2: "The MCC may contain a reference to the Single Media >>>>>>>>> Captures... (or) A MCC MAY contain no references to other >>>>>>>>> Captures to indicate that the MCC contains content from multiple >>>>>>>>> sources but no information regarding those sources is given." >>>>>>>>> And in section 10 "If the MCC in the advertisement does not >>>>>>>>> reference any individual captures, then the Consumer cannot >>>>>>>>> choose what is included in the MCC" >>>>>>>>> >>>>>>>>> I propose adding text: >>>>>>>>> >>>>>>>>> The MCC may contain a wildcard reference, meaning it can refer to >>>>>>>>> any of the other captures in the advertisement. The consumer, in >>>>>>>>> a configure message, may choose which of the other media captures >>>>>>>>> it wishes to receive in the MCC. >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> 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 >> > > From Mark.Duckworth@polycom.com Mon Jan 20 14:49: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 C1B081A0271 for ; Mon, 20 Jan 2014 14:49:31 -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 9V304PlSd8Yh for ; Mon, 20 Jan 2014 14:49:29 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id F01B01A0262 for ; Mon, 20 Jan 2014 14:49:28 -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; Mon, 20 Jan 2014 14:49:28 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Mon, 20 Jan 2014 14:49:28 -0800 From: "Duckworth, Mark" To: Christian Groves , Paul Kyzivat , "clue@ietf.org" Date: Mon, 20 Jan 2014 14:49:26 -0800 Thread-Topic: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? Thread-Index: Ac8WMK603ivVlqsSTqSNpsl0a55/fwAAOMTg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF163F2@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> In-Reply-To: <52DDA5EE.9090403@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] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 20 Jan 2014 22:49:32 -0000 No, I wasn't thinking capture IDs are globally unique, I was just using tha= t as an example of something else where it doesn't make sense to specify ra= nges or use regular expressions. Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Monday, January 20, 2014 5:41 PM > To: Paul Kyzivat; Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MC= C - > allow wildcard? >=20 > I think before going for the label approach I think it would be worth to = go > through some examples and compare the size of the messages, i.e. > comparing using the CaptureIDs vs Labels. Actually I think we need some > more examples in general to understand the savings for wildcarding. If yo= u > have to specify an attribute with possibly several labels on each Capture= then > we might not be saving much (if anything) for the complexity. >=20 > Also if we mix captures and label then I assume that we have to define th= e > name space for each to ensure they didn't overlap? Currently captureIDs > could be anything. >=20 > With respect to putting meaning into the CaptureIDs is it really a big ch= ange > for captureIDs to have some meaning within the session? Our convention in > the framework of ACx, VCx, etc seems to be working quite well. I'm not su= re > why you'd want the CaptureID to be globally unique like a GUID? That seem= s > like overkill. If people are assuming that CaptureIDs are globally unique > across a MCU or network then I think we need to discuss that because I no= t > sure everyone has the same view. >=20 > Regards, Christian >=20 > On 21/01/2014 9:15 AM, Paul Kyzivat wrote: > > Hmm. I now realize I didn't say what I meant. What I meant was: > > > > My thought was that the the advertiser could specify *any* of: > > > > - MCC(capture1, capture2, ...) > > - MCC(label1) > > - MCC(label1, label2, ...) > > - MCC(capture1, label1, ...) > > > > While the consumer could return either of: > > > > - MCC() > > - MCC(capture1, capture2, ...) > > > > Sorry, > > Paul > > > > > > On 1/20/14 4:46 PM, Duckworth, Mark wrote: > >> Paul and Christian, > >> > >> I was thinking much the same as Paul's approach 2. But maybe the > >> configure message could be limited to something like this?: > >> - MCC() > >> - MCC(capture1, capture2,...) > >> > >> In the configure message, I'm not sure there is an advantage to > >> specifying MCC subsets by label rather than always using capture ID. > >> > >> I always thought of the capture IDs as just a unique identifier, with > >> no intrinsic meaning, like GUIDs. That's why specifying groups of > >> them with ranges (VC1 through VC4) or regular expressions doesn't > >> make sense to me. Putting more meaning into the identifiers seems > >> like a big change to me. > >> > >> Mark > >> > >>> -----Original Message----- > >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>> Sent: Monday, January 20, 2014 1:15 PM > >>> To: clue@ietf.org > >>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in > >>> an MCC - allow wildcard? > >>> > >>> On 1/19/14 9:55 PM, Christian Groves wrote: > >>>> I'd like some more explanation of the concept before agreeing. > >>>> > >>>> The reason why I went with CaptureIDs for the MCC and the > >>>> individual captures was to prevent yet another namespace in CLUE. > >>>> It also worked in with the fact that the Consumer currently only > >>>> returns CaptureIDs and EncodingIDs. Are we now saying that an > >>>> Advertiser sends > >>>> MCC1(label1) and if a Consumer wants a subset it returns > >>>> MCC(Capture1, Capture2, Capture3, etc?). I particularly avoided the > >>>> use of attributes for this because CLUE Configures don't reference > >>>> attributes. > >>> > >>> My thought was that the the consumer could return: > >>> > >>> - MCC() > >>> - MCC(capture1, capture2, ...) > >>> - MCC(label1) > >>> - MCC(label1, label2, ...) > >>> - MCC(capture1, label1, ...) > >>> > >>>> Why couldn't CLUE simply have pattern matching based on regular > >>>> expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.). > >>> > >>> That is a possibility. I question whether it is simpler. I guess it > >>> does make advertisements smaller. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Christian > >>>> > >>>> > >>>> On 19/01/2014 4:20 AM, Paul Kyzivat wrote: > >>>>> On 1/17/14 6:12 PM, Duckworth, Mark wrote: > >>>>>> We discussed this topic in the Jan 14 design team meeting. The > >>>>>> group had interest in the concept, but not my specific proposal. > >>>>>> Jonathan had an interesting idea, which I think better serves the > >>> purpose. > >>>>>> > >>>>>> Instead of the MCC referring specifically to other media captures > >>>>>> that can be contained within the MCC, the MCC can refer to zero > >>>>>> or more "MCC grouping labels". Any other media capture can > >>>>>> include an attribute (zero or more) with a particular MCC > >>>>>> grouping label. The meaning is that any MC that has the same > >>>>>> grouping label that is reference by an MCC can be included in that > MCC. > >>>>>> > >>>>>> I think this doesn't change at all the meaning of MCC, but it > >>>>>> will affect the syntax of how we describe it in the data model > >>>>>> for CLUE messages. > >>>>>> > >>>>>> If the group agrees with this concept, I can propose specific > >>>>>> changes to the framework. > >>>>> > >>>>> This WFM, conceptually. > >>>>> There are details to be worked out for this to be practical and > >>>>> convenient. Those details will presumably be in the data model. > >>>>> > >>>>> Specifically, in the declaration of the MCC, there must be some > >>>>> syntax for the reference. Two approaches come to mind: > >>>>> > >>>>> 1) the new labels share a single namespace with capture ids in the > >>>>> advertisement. The MCC declaration has an element that is used to > >>>>> reference these IDs, of either kind. You can tell which kind by > >>>>> resolving the reference. > >>>>> > >>>>> 2) the new labels have a distinct namespace from capture ids. The > >>>>> MCC declaration allows two different kinds of elements, one to > >>>>> reference capture ids, and another to reference these new labels. > >>>>> > >>>>> I'm inclined to prefer (2) - it seems less kludgy, and is probably > >>>>> equally concise. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>> > >>>>> > >>>>>> Mark > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > >>>>>>> Duckworth, Mark > >>>>>>> Sent: Friday, January 10, 2014 3:47 PM > >>>>>>> To: Paul Kyzivat; clue@ietf.org > >>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcar= d? > >>>>>>> > >>>>>>> Paul, > >>>>>>> > >>>>>>> Yes, I think the wildcard is just a syntax shortcut. > >>>>>>> One other impact that I was thinking of is if we decide to have > >>>>>>> partial updates of advertisements then it removes the need to > >>>>>>> re-advertise any MCC(*) captures when other captures change. > >>>>>>> Without wildcard, any other addition or removal of a > >>>>>>> contributing capture means also re-advertising every MCC with a > >>>>>>> new list of contributors. > >>>>>>> I think the wildcard fits very nicely with the switching > >>>>>>> scenario option (2) from the other discussion thread. > >>>>>>> > >>>>>>> Mark > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul > >>>>>>>> Kyzivat > >>>>>>>> Sent: Friday, January 10, 2014 1:24 PM > >>>>>>>> To: clue@ietf.org > >>>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow > >>>>>>>> wildcard? > >>>>>>>> > >>>>>>>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: > >>>>>>>>> In an advertisement, the provider can indicate which other > >>>>>>>>> captures are referenced by an MCC, for example: > >>>>>>>>> > >>>>>>>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 > >>>>>>>>> > >>>>>>>>> MCC1(VC1, VC2) > >>>>>>>>> > >>>>>>>>> This means MCC1 can include VC1 and/or VC2, but not the > others. > >>>>>>>>> > >>>>>>>>> MCC2() > >>>>>>>>> > >>>>>>>>> Without any specific references, this means the provider is > >>>>>>>>> not saying which other captures can be included in MCC2, and > >>>>>>>>> the consumer cannot choose. > >>>>>>>>> > >>>>>>>>> I propose adding a wildcard: > >>>>>>>>> > >>>>>>>>> MCC3(*) > >>>>>>>> > >>>>>>>> IIUC you mean this to be strictly a syntactic shortcut, not > >>>>>>>> adding any functionality that isn't present without it. > >>>>>>>> > >>>>>>>>> This means MCC3 can include any of the other captures VC1 > >>>>>>>>> through VC5, and the consumer can choose. > >>>>>>>> > >>>>>>>> Do you intent this to mean all the captures in the > >>>>>>>> advertisement, or all the captures in the same scene? > >>>>>>>> > >>>>>>>>> For some types of MCUs, that want to give consumers the > choice > >>>>>>>>> of which specific captures to receive in an MCC, this is > >>>>>>>>> useful for large advertisements with many media captures. > >>>>>>>> > >>>>>>>> Perhaps. But I have my doubts that this would be of common use > >>>>>>>> in > >>>>>>> practice. > >>>>>>>> > >>>>>>>> So it becomes a question of whether the added implementation > >>>>>>>> burden of supporting this optimization is justified for the > >>>>>>>> number of cases when it would be of use. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Paul > >>>>>>>> > >>>>>>>>> When endpoints join or leave a conference, causing the > >>>>>>>>> advertisement to change to add or remove scenes and captures, > >>>>>>>>> the part of the advertisement with MCCs wouldn't have to > >>>>>>>>> change at all. > >>>>>>>>> > >>>>>>>>> Related text from framework-13: > >>>>>>>>> > >>>>>>>>> From 7.2: "The MCC may contain a reference to the Single > >>>>>>>>> Media Captures... (or) A MCC MAY contain no references to > >>>>>>>>> other Captures to indicate that the MCC contains content from > >>>>>>>>> multiple sources but no information regarding those sources is > given." > >>>>>>>>> And in section 10 "If the MCC in the advertisement does not > >>>>>>>>> reference any individual captures, then the Consumer cannot > >>>>>>>>> choose what is included in the MCC" > >>>>>>>>> > >>>>>>>>> I propose adding text: > >>>>>>>>> > >>>>>>>>> The MCC may contain a wildcard reference, meaning it can refer > >>>>>>>>> to any of the other captures in the advertisement. The > >>>>>>>>> consumer, in a configure message, may choose which of the > >>>>>>>>> other media captures it wishes to receive in the MCC. > >>>>>>>>> > >>>>>>>>> What do you think? > >>>>>>>>> > >>>>>>>>> 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 > >> > > > > From Christian.Groves@nteczone.com Mon Jan 20 15:02: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 3F42C1A0259 for ; Mon, 20 Jan 2014 15:02:20 -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 nlBJBdBwcGr6 for ; Mon, 20 Jan 2014 15:02:17 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22101A026F for ; Mon, 20 Jan 2014 15:02:16 -0800 (PST) Received: from ppp118-209-127-72.lns20.mel4.internode.on.net ([118.209.127.72]:51353 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5NoJ-0007MM-6V for clue@ietf.org; Tue, 21 Jan 2014 09:59:15 +1100 Message-ID: <52DDAAF7.9020506@nteczone.com> Date: Tue, 21 Jan 2014 10:02:15 +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: <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> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16388@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] 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: Mon, 20 Jan 2014 23:02:20 -0000 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. >>>>>> <>>>>> 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 > From Christian.Groves@nteczone.com Mon Jan 20 15:08: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 AB2E91A0272 for ; Mon, 20 Jan 2014 15:08: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 f7Msa_nfXZGK for ; Mon, 20 Jan 2014 15:08:12 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05ED21A0259 for ; Mon, 20 Jan 2014 15:08:12 -0800 (PST) Received: from ppp118-209-127-72.lns20.mel4.internode.on.net ([118.209.127.72]:51420 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5Nu2-0008Dj-F5; Tue, 21 Jan 2014 10:05:10 +1100 Message-ID: <52DDAC5A.4050006@nteczone.com> Date: Tue, 21 Jan 2014 10:08: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: "Duckworth, Mark" , Paul Kyzivat , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163F2@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF163F2@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] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 20 Jan 2014 23:08:15 -0000 Hello Mark, I agree it doesn't make sense for specifying ranges etc for GUIDs but I think comparing GUIDs and CaptureIDs isn't fair because they are different beasts. As I mentioned below the scope of CaptureIDs is for a particular session. Would generating an ID according to a pattern be much of a burden compared to generating a random number for a limited set of IDs such as one would find in a session? It might have additional benefits when it comes to trouble shooting. Regards, Christian On 21/01/2014 9:49 AM, Duckworth, Mark wrote: > No, I wasn't thinking capture IDs are globally unique, I was just using that as an example of something else where it doesn't make sense to specify ranges or use regular expressions. > > Mark > >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Monday, January 20, 2014 5:41 PM >> To: Paul Kyzivat; Duckworth, Mark; clue@ietf.org >> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - >> allow wildcard? >> >> I think before going for the label approach I think it would be worth to go >> through some examples and compare the size of the messages, i.e. >> comparing using the CaptureIDs vs Labels. Actually I think we need some >> more examples in general to understand the savings for wildcarding. If you >> have to specify an attribute with possibly several labels on each Capture then >> we might not be saving much (if anything) for the complexity. >> >> Also if we mix captures and label then I assume that we have to define the >> name space for each to ensure they didn't overlap? Currently captureIDs >> could be anything. >> >> With respect to putting meaning into the CaptureIDs is it really a big change >> for captureIDs to have some meaning within the session? Our convention in >> the framework of ACx, VCx, etc seems to be working quite well. I'm not sure >> why you'd want the CaptureID to be globally unique like a GUID? That seems >> like overkill. If people are assuming that CaptureIDs are globally unique >> across a MCU or network then I think we need to discuss that because I not >> sure everyone has the same view. >> >> Regards, Christian >> >> On 21/01/2014 9:15 AM, Paul Kyzivat wrote: >>> Hmm. I now realize I didn't say what I meant. What I meant was: >>> >>> My thought was that the the advertiser could specify *any* of: >>> >>> - MCC(capture1, capture2, ...) >>> - MCC(label1) >>> - MCC(label1, label2, ...) >>> - MCC(capture1, label1, ...) >>> >>> While the consumer could return either of: >>> >>> - MCC() >>> - MCC(capture1, capture2, ...) >>> >>> Sorry, >>> Paul >>> >>> >>> On 1/20/14 4:46 PM, Duckworth, Mark wrote: >>>> Paul and Christian, >>>> >>>> I was thinking much the same as Paul's approach 2. But maybe the >>>> configure message could be limited to something like this?: >>>> - MCC() >>>> - MCC(capture1, capture2,...) >>>> >>>> In the configure message, I'm not sure there is an advantage to >>>> specifying MCC subsets by label rather than always using capture ID. >>>> >>>> I always thought of the capture IDs as just a unique identifier, with >>>> no intrinsic meaning, like GUIDs. That's why specifying groups of >>>> them with ranges (VC1 through VC4) or regular expressions doesn't >>>> make sense to me. Putting more meaning into the identifiers seems >>>> like a big change to me. >>>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>> Sent: Monday, January 20, 2014 1:15 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in >>>>> an MCC - allow wildcard? >>>>> >>>>> On 1/19/14 9:55 PM, Christian Groves wrote: >>>>>> I'd like some more explanation of the concept before agreeing. >>>>>> >>>>>> The reason why I went with CaptureIDs for the MCC and the >>>>>> individual captures was to prevent yet another namespace in CLUE. >>>>>> It also worked in with the fact that the Consumer currently only >>>>>> returns CaptureIDs and EncodingIDs. Are we now saying that an >>>>>> Advertiser sends >>>>>> MCC1(label1) and if a Consumer wants a subset it returns >>>>>> MCC(Capture1, Capture2, Capture3, etc?). I particularly avoided the >>>>>> use of attributes for this because CLUE Configures don't reference >>>>>> attributes. >>>>> My thought was that the the consumer could return: >>>>> >>>>> - MCC() >>>>> - MCC(capture1, capture2, ...) >>>>> - MCC(label1) >>>>> - MCC(label1, label2, ...) >>>>> - MCC(capture1, label1, ...) >>>>> >>>>>> Why couldn't CLUE simply have pattern matching based on regular >>>>>> expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.). >>>>> That is a possibility. I question whether it is simpler. I guess it >>>>> does make advertisements smaller. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Christian >>>>>> >>>>>> >>>>>> On 19/01/2014 4:20 AM, Paul Kyzivat wrote: >>>>>>> On 1/17/14 6:12 PM, Duckworth, Mark wrote: >>>>>>>> We discussed this topic in the Jan 14 design team meeting. The >>>>>>>> group had interest in the concept, but not my specific proposal. >>>>>>>> Jonathan had an interesting idea, which I think better serves the >>>>> purpose. >>>>>>>> Instead of the MCC referring specifically to other media captures >>>>>>>> that can be contained within the MCC, the MCC can refer to zero >>>>>>>> or more "MCC grouping labels". Any other media capture can >>>>>>>> include an attribute (zero or more) with a particular MCC >>>>>>>> grouping label. The meaning is that any MC that has the same >>>>>>>> grouping label that is reference by an MCC can be included in that >> MCC. >>>>>>>> I think this doesn't change at all the meaning of MCC, but it >>>>>>>> will affect the syntax of how we describe it in the data model >>>>>>>> for CLUE messages. >>>>>>>> >>>>>>>> If the group agrees with this concept, I can propose specific >>>>>>>> changes to the framework. >>>>>>> This WFM, conceptually. >>>>>>> There are details to be worked out for this to be practical and >>>>>>> convenient. Those details will presumably be in the data model. >>>>>>> >>>>>>> Specifically, in the declaration of the MCC, there must be some >>>>>>> syntax for the reference. Two approaches come to mind: >>>>>>> >>>>>>> 1) the new labels share a single namespace with capture ids in the >>>>>>> advertisement. The MCC declaration has an element that is used to >>>>>>> reference these IDs, of either kind. You can tell which kind by >>>>>>> resolving the reference. >>>>>>> >>>>>>> 2) the new labels have a distinct namespace from capture ids. The >>>>>>> MCC declaration allows two different kinds of elements, one to >>>>>>> reference capture ids, and another to reference these new labels. >>>>>>> >>>>>>> I'm inclined to prefer (2) - it seems less kludgy, and is probably >>>>>>> equally concise. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Mark >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>> Duckworth, Mark >>>>>>>>> Sent: Friday, January 10, 2014 3:47 PM >>>>>>>>> To: Paul Kyzivat; clue@ietf.org >>>>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >>>>>>>>> >>>>>>>>> Paul, >>>>>>>>> >>>>>>>>> Yes, I think the wildcard is just a syntax shortcut. >>>>>>>>> One other impact that I was thinking of is if we decide to have >>>>>>>>> partial updates of advertisements then it removes the need to >>>>>>>>> re-advertise any MCC(*) captures when other captures change. >>>>>>>>> Without wildcard, any other addition or removal of a >>>>>>>>> contributing capture means also re-advertising every MCC with a >>>>>>>>> new list of contributors. >>>>>>>>> I think the wildcard fits very nicely with the switching >>>>>>>>> scenario option (2) from the other discussion thread. >>>>>>>>> >>>>>>>>> Mark >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>>>>>>> Kyzivat >>>>>>>>>> Sent: Friday, January 10, 2014 1:24 PM >>>>>>>>>> To: clue@ietf.org >>>>>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow >>>>>>>>>> wildcard? >>>>>>>>>> >>>>>>>>>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: >>>>>>>>>>> In an advertisement, the provider can indicate which other >>>>>>>>>>> captures are referenced by an MCC, for example: >>>>>>>>>>> >>>>>>>>>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 >>>>>>>>>>> >>>>>>>>>>> MCC1(VC1, VC2) >>>>>>>>>>> >>>>>>>>>>> This means MCC1 can include VC1 and/or VC2, but not the >> others. >>>>>>>>>>> MCC2() >>>>>>>>>>> >>>>>>>>>>> Without any specific references, this means the provider is >>>>>>>>>>> not saying which other captures can be included in MCC2, and >>>>>>>>>>> the consumer cannot choose. >>>>>>>>>>> >>>>>>>>>>> I propose adding a wildcard: >>>>>>>>>>> >>>>>>>>>>> MCC3(*) >>>>>>>>>> IIUC you mean this to be strictly a syntactic shortcut, not >>>>>>>>>> adding any functionality that isn't present without it. >>>>>>>>>> >>>>>>>>>>> This means MCC3 can include any of the other captures VC1 >>>>>>>>>>> through VC5, and the consumer can choose. >>>>>>>>>> Do you intent this to mean all the captures in the >>>>>>>>>> advertisement, or all the captures in the same scene? >>>>>>>>>> >>>>>>>>>>> For some types of MCUs, that want to give consumers the >> choice >>>>>>>>>>> of which specific captures to receive in an MCC, this is >>>>>>>>>>> useful for large advertisements with many media captures. >>>>>>>>>> Perhaps. But I have my doubts that this would be of common use >>>>>>>>>> in >>>>>>>>> practice. >>>>>>>>>> So it becomes a question of whether the added implementation >>>>>>>>>> burden of supporting this optimization is justified for the >>>>>>>>>> number of cases when it would be of use. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>>> When endpoints join or leave a conference, causing the >>>>>>>>>>> advertisement to change to add or remove scenes and captures, >>>>>>>>>>> the part of the advertisement with MCCs wouldn't have to >>>>>>>>>>> change at all. >>>>>>>>>>> >>>>>>>>>>> Related text from framework-13: >>>>>>>>>>> >>>>>>>>>>> From 7.2: "The MCC may contain a reference to the Single >>>>>>>>>>> Media Captures... (or) A MCC MAY contain no references to >>>>>>>>>>> other Captures to indicate that the MCC contains content from >>>>>>>>>>> multiple sources but no information regarding those sources is >> given." >>>>>>>>>>> And in section 10 "If the MCC in the advertisement does not >>>>>>>>>>> reference any individual captures, then the Consumer cannot >>>>>>>>>>> choose what is included in the MCC" >>>>>>>>>>> >>>>>>>>>>> I propose adding text: >>>>>>>>>>> >>>>>>>>>>> The MCC may contain a wildcard reference, meaning it can refer >>>>>>>>>>> to any of the other captures in the advertisement. The >>>>>>>>>>> consumer, in a configure message, may choose which of the >>>>>>>>>>> other media captures it wishes to receive in the MCC. >>>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> 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 >>> > From Christian.Groves@nteczone.com Mon Jan 20 15:19: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 8E3D01A022B for ; Mon, 20 Jan 2014 15:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jdwOBJ1_c1oG for ; Mon, 20 Jan 2014 15:19:31 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817351A0218 for ; Mon, 20 Jan 2014 15:19:30 -0800 (PST) Received: from ppp118-209-127-72.lns20.mel4.internode.on.net ([118.209.127.72]:51542 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5O4y-00019U-9J; Tue, 21 Jan 2014 10:16:28 +1100 Message-ID: <52DDAF00.3090308@nteczone.com> Date: Tue, 21 Jan 2014 10:19:28 +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: "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@CRPMBOXPRD07.polycom.com> <52DAD8D1.9030904@alum.mit.edu> <52DC9A00.4010609@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163D1@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF163D1@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] multipoint switching, MCC, and spatial 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: Mon, 20 Jan 2014 23:19:33 -0000 Hello Mark, Please see below. Regards, Christian On 21/01/2014 9:16 AM, Duckworth, Mark wrote: > Christian, > > Your first approach for the way the "small boxes" could be advertised sounds to me like the advertiser is expecting the consumer to be able to separate the top, middle, and bottom rows within the 3x3 grid scene into three separate areas for rendering. This would be better done by using three separate scenes in the first place, not just one scene. Three separate scenes is an example of my approach #3 from the slides. [CNG] In my first case I don't think the Provider assumes that three separate areas are used. Its simply suggesting a 3x3 grid, 9 tile scene. How the Consumer uses the information is up to it. The consumer could equally take the left, middle, right columns Captures. By having these in the same Scene it indicates that there is a spatial relation between the Captures. If you had multiple scenes then any spatial relationship is lost. If the Provider didn't want to indicate any spatial relationship between the MCC (i.e. each tile) then they could also be in separate CaptureScenes. > > I'm still focusing on the media-switching variety of MCU, so I am looking for solution that doesn't involve composition in the MCU. But I do agree your composition examples make sense if the MCU is capable of it. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Sunday, January 19, 2014 10:38 PM >> To: clue@ietf.org >> Subject: Re: [clue] multipoint switching, MCC, and spatial information >> >> Hello Mark, >> >> I agree with Paul's comments. >> >> Please see my additional comments below. >> >> Regards, Christian >> >> On 19/01/2014 6:41 AM, Paul Kyzivat wrote: >>> Mark, >>> >>> My thinking is that the advertiser MAY include spatial coordinates on >>> the MCCs if it wishes. If so, then they are virtual coordinates for >>> that capture in the context of the scene containing the MCC. How the >>> advertiser arrives at these coordinates is its business. It might look >>> at the spatial relationships of the source captures to do this, or not. >>> >>> A simple consumer can simply treat an MCC like any other capture, and >>> make all of its decisions about how to render it based on the MCC >>> coordinates. This might be sub-optimal, but its easy. >>> >>> A more sophisticated consumer can look at the sources of the MCC >>> captures, and their coordinates in their scenes, and use that to make >>> its decisions about how to render. It can do that statically (at the >>> time of Configure) without regard to which of the alternatives is >>> switched in at any one time. (This is somewhat sub-optimal.) >>> >>> Or the most sophisticated consumer can see what it is receiving in >>> each RTP packet, map this back to a particular source capture in the >>> advertisement, and then use the spatial coordinates from that to make >>> rendering decisions. (We need to figure out how that mapping an be >>> done.) >>> >>> The advertiser doesn't need to know which way the consumer is doing >>> it. But the information provided in the advertisement constrains what >>> the consumer is able to do. >>> >>> Thanks, >>> Paul >>> >>> On 1/17/14 6:44 PM, Duckworth, Mark wrote: >>>> This is follow-up to the topic "[clue] MCC switching example", and to >>>> the design team discussion Jan 14. I'm interested in what others >>>> have to say about how approach #1 should work, regarding spatial >>>> information and the consumer's ability to render streams together >>>> that belong together. >>>> >>>> Referring to my framework issue slides >>>> >>> eam/Framework_Issues_140113.pptx>, >>>> >>>> pages 8 - 12. The group had interest mainly in approach #1, where >>>> the MCU makes all the switching decisions. But we didn't have a >>>> common understanding about how spatial information was to be >>>> conveyed, so the consumer can render multiple streams together when >>>> they are spatially related. >>>> >>>> On slide 9, for approach 1, it says "MCCs don't have spatial >>>> attributes". But other people in the discussion thought the MCCs >>>> should have spatial attributes. Jonathan said the MCCs could have >>>> spatial information like this (Jonathan, correct me if I don't remember >> right): >>>> MCC1, MCC2, MCC3: left, center, and right of the full scene, like the >>>> image on page 6 for VC1-3. >>>> >>>> MCC4, MCC5, MCC6: spatial information that indicates they are located >>>> on bottom part of MCC1, and much smaller than MCC1, like on page 6 >>>> for VC4-6. >>>> >>>> MCC7, MCC8, MCC9: spatial information that indicates they are located >>>> on bottom part of MCC2, and much smaller than MCC2, like on page 6 >>>> for VC7-9. >> [CNG] Yes MCCs could have spatial information in this context. >>>> While this should work for that specific case, I don't think it works >>>> for the very similar case in framework section 12.3.3 which has these >>>> two alternative rendering layouts for the same streams (use >>>> mono-spaced font to see this): >>>> >>>> +---+---+---+ +-------------+ +-------------+ +-------------+ >>>> >>>> | | | | | | | | | | >>>> >>>> +---+---+---+ | | | | | | >>>> >>>> | | | | | | | | | | >>>> >>>> +---+---+---+ | | | | | | >>>> >>>> | | | | | | | | | | >>>> >>>> +---+---+---+ +-------------+ +-------------+ +-------------+ >>>> >>>> +-------------+ +-------------+ +-------------+ >>>> >>>> | | | | | | >>>> >>>> | | | | | | >>>> >>>> | | | | | | >>>> >>>> | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | >>>> >>>> | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | >>>> >>>> +-------------+ +-------------+ +-------------+ >>>> >>>> If we generalize this approach to support alternatives like this, I >>>> think we end up with approach number 3 instead of approach 1. >> [CNG] Table 22 in section 12.3.3 of the framework has spatial information for >> MCC1,MCC2,MCC3 (incorrectly labelled as left,left,left it should be left, >> centre, right). This would be related to the "large" >> boxes above. I don't think there's an issue with this. >> >> There are a number of ways that the "small" boxes could be advertised. >> >> The first is as per table 23 of the framework. Each of the MCCs >> (MMC4-MCC12) could be given a virtual spatial area. i.e. each MCC stream >> has its own space. i.e. MCC4(top left), MCC5(top centre), MCC6(top right, >> etc.) It's then up to the consumer to decide how to render it. >> The Consumer could do either of the above approaches. >> >> A second approach is a per table 24 of the framework. If MCC13 was in >> CaptureScene8 it could use spatial information of the constituent MCCs to >> determine the position in the composed single stream. Unless the Consumer >> had the smarts to "decompose" the media stream then it would only be able >> to the top approach. >> >> A third approach would be for the Provider to Advertise 3 streams for the 9 >> tiles (this isn't shown in the framework), e.g. >> >> +=======================+================================= >> + >> | Capture Scene # | Description=Output3stream | >> +-----------------------|---------------------------------+ >> | MCC4(VC4,VC5,VC6,VC7, | MaxCaptures=1 | >> | VC8,VC9,VC10,VC11, | Policy=SoundLevel:0 | >> | VC12,VC13,VC14,VC15)| SpatialInfo=Top Left | >> | | | >> | MCC5(VC4,VC5,VC6,VC7, | MaxCaptures=1 | >> | VC8,VC9,VC10,VC11, | Policy=SoundLevel:1 | >> | VC12,VC13,VC14,VC15)| SpatialInfo=Top Middle | >> | | | >> to to | >> | | | >> | MCC12(VC4,VC5,VC6,VC7,| MaxCaptures=1 | >> | VC8,VC9,VC10,VC11, | Policy=SoundLevel:8 | >> | VC12,VC13,VC14,VC15)| SpatialInfo=Bottom Right | >> | | | >> | MCC13(MCC4,MCC5,MCC6 | MaxCaptures=3 | >> | | EncodingGroup=1 | >> | | SpatialInfo=Top | >> | MCC14(MCC7,MCC8,MCC9 | MaxCaptures=3 | >> | | EncodingGroup=1 | >> | | SpatialInfo=Middle | >> | MCC15(MCC10,MCC11, | MaxCaptures=3 | >> | MCC12) | EncodingGroup=1 | >> | | SpatialInfo=Bottom | >> | CSE(MCC13,MCC14,MCC15)| | >> >> +=======================+================================= >> + >> >> In the above case the Provider Advertises 3 encodings MCC13 containing the >> three most active speakers, MCC14 containing the next three most active >> etc. Note that the MCC13-15 are static, always maintaining the spatial co- >> ordinates. Because the Consumer receives 3 streams it could display these 3 >> streams in either the 9 tiles approach or the PiP approach. >> >> As Paul said, the information received from the Advertiser constrains what >> the Consumer is able to do. >> >> >>>> We also talked about the consumer should have the ability to associate >>>> incoming encoded packet streams with a particular individual MC from the >>>> advertisement. This would give the consumer the spatial information of >>>> the particular MC currently switched in to the MCC. My concern about >>>> this way of getting spatial information is that it means the renderer >>>> has to re-map decoder output to different display locations on the fly >>>> without any advance notice. >>>> >>>> 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 From Christian.Groves@nteczone.com Mon Jan 20 15:37: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 D5A041A022B for ; Mon, 20 Jan 2014 15:37:05 -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 lwJsZDzC7rKQ for ; Mon, 20 Jan 2014 15:37:04 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140291A0218 for ; Mon, 20 Jan 2014 15:37:04 -0800 (PST) Received: from ppp118-209-127-72.lns20.mel4.internode.on.net ([118.209.127.72]:51841 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5OLy-00043g-CZ for clue@ietf.org; Tue, 21 Jan 2014 10:34:02 +1100 Message-ID: <52DDB31F.3040908@nteczone.com> Date: Tue, 21 Jan 2014 10:37:03 +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: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@CRPMBOXPRD07.polycom.com> <52DAD8D1.9030904@alum.mit.edu> <52DC9A00.4010609@nteczone.com> <52DD6543.5060405@alum.mit.edu> In-Reply-To: <52DD6543.5060405@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: Subject: Re: [clue] multipoint switching, MCC, and spatial 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: Mon, 20 Jan 2014 23:37:06 -0000 Hello Paul, Please see below. Regards, Christian On 21/01/2014 5:04 AM, Paul Kyzivat wrote: > On 1/19/14 10:37 PM, Christian Groves wrote: > >>>> On slide 9, for approach 1, it says MCCs dont have spatial >>>> attributes. But other people in the discussion thought the MCCs >>>> should >>>> have spatial attributes. Jonathan said the MCCs could have spatial >>>> information like this (Jonathan, correct me if I dont remember >>>> right): >>>> >>>> MCC1, MCC2, MCC3: left, center, and right of the full scene, like the >>>> image on page 6 for VC1-3. >>>> >>>> MCC4, MCC5, MCC6: spatial information that indicates they are >>>> located on >>>> bottom part of MCC1, and much smaller than MCC1, like on page 6 for >>>> VC4-6. >>>> >>>> MCC7, MCC8, MCC9: spatial information that indicates they are >>>> located on >>>> bottom part of MCC2, and much smaller than MCC2, like on page 6 for >>>> VC7-9. >> [CNG] Yes MCCs could have spatial information in this context. > > OK, is *this* what you have been talking about Christian? [CNG] Partly, MCCs can be sources to other MCCs (like individual Captures) and thus could have spatial information associated with them. > > I agree this is *possible*. But it will take more specification for > consumers to make sense of this in a consistent way. [CNG] I'm happy to work on that. > > Specifically, our spatial info describes a quadrilateral in a plane in > three-space. In the above there is no mention of the third dimension. > Do you assume that MCC4 and MCC7 fall within the planar area of MCC1? > If so, then what should the stacking order be when composing them? [CNG] I'm taking the above case as a composition so I think its valid to assume that they are on the same plane. With regards to stacking order I hadn't really thought about it because I assumed the same plane. Being a composed image I didn't think order was important as the images would basically be merged, i.e. if you cut out the smaller area you'd be left with a hole. In a multiple encoding case if you wanted to imply stacking I guess an Advertiser could use a plane parallel to the "main scene". In this way it could indicate a parallel plane in front or behind. If it was the same plane then the Consumer could decide which way to display it. However this aspect seems to be a general issue with Spatial information in captures. Not just for MCCs. > > Or do you assume that they will be planar areas that are "nearer" to > the capture point than MC1, providing a hint about the stacking order? > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Tue Jan 21 04:54: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 2BABC1A00E9 for ; Tue, 21 Jan 2014 04:54:23 -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 LdeBH_HidP72 for ; Tue, 21 Jan 2014 04:54:20 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 50D811A00D8 for ; Tue, 21 Jan 2014 04:54:20 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 21 Jan 2014 04:54:20 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Tue, 21 Jan 2014 04:54:16 -0800 Thread-Topic: [clue] spatial information can't describe video locations within composed MCC Thread-Index: Ac8WM67Ucc0NbGioQYW0TgR9TTcP0AAc4RBw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF1646F@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> In-Reply-To: <52DDAAF7.9020506@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] 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: Tue, 21 Jan 2014 12:54:23 -0000 Hello Christian, I still don't see how the consumer can tell anything about how an MCC is co= mposed. 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 rela= ted. But how is the consumer supposed to know how the provider is composin= g them inside MCC1? It could be any number of ways, and it could be changi= ng over time. So my cases 2 and 3 below apply to why the consumer can't te= ll how the MCC is composed. Yet it still makes sense for the provider to g= ive 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 wi= thin > 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 informati= on 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 a= n > MCU doing is creating a virtual scene using these source captures. > Giving Captures spatial co-ordinates within a virtual scene is a valid th= ing 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 ap= plies > 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 source= s 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. > >>>>>> < >>>>>> 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 ther= e > >>>>>>>>> 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 From Mark.Duckworth@polycom.com Tue Jan 21 05:03: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 A039E1A00D6 for ; Tue, 21 Jan 2014 05:03:07 -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 If6axCo71Uog for ; Tue, 21 Jan 2014 05:03:04 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0E41A00CC for ; Tue, 21 Jan 2014 05:03:04 -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; Tue, 21 Jan 2014 05:03:04 -0800 From: "Duckworth, Mark" To: Christian Groves , Paul Kyzivat , "clue@ietf.org" Date: Tue, 21 Jan 2014 05:03:01 -0800 Thread-Topic: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? Thread-Index: Ac8WMK603ivVlqsSTqSNpsl0a55/fwAd3btQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> In-Reply-To: <52DDA5EE.9090403@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] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 21 Jan 2014 13:03:07 -0000 Hello Christian, Regarding the size of messages, I think in general the label idea will redu= ce the size. Take Capture Scene #8 from the framework section 12.3.3 as an= example. Let's count the number of "tags" (or elements, or attributes, or= whatever you want to call them) we need to indicate the associations betwe= en MCCs and other captures. MCC4 through MCC12, each referring to 12 individual captures. That is 9 x = 12 =3D 108 "tags". With the labeling mechanism, each of the 12 individual captures has just on= e MCC grouping label, and they can all be the same value. That is 12 "tags= ". Plus each MCC has just one grouping label, again the same value, so tha= t is 9 more tags. Total of just 21 "tags" vs. 108 "tags". So that is a bi= g savings using the labeling mechanism. Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Monday, January 20, 2014 5:41 PM > To: Paul Kyzivat; Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MC= C - > allow wildcard? >=20 > I think before going for the label approach I think it would be worth to = go > through some examples and compare the size of the messages, i.e. > comparing using the CaptureIDs vs Labels. Actually I think we need some > more examples in general to understand the savings for wildcarding. If yo= u > have to specify an attribute with possibly several labels on each Capture= then > we might not be saving much (if anything) for the complexity. >=20 > Also if we mix captures and label then I assume that we have to define th= e > name space for each to ensure they didn't overlap? Currently captureIDs > could be anything. >=20 > With respect to putting meaning into the CaptureIDs is it really a big ch= ange > for captureIDs to have some meaning within the session? Our convention in > the framework of ACx, VCx, etc seems to be working quite well. I'm not su= re > why you'd want the CaptureID to be globally unique like a GUID? That seem= s > like overkill. If people are assuming that CaptureIDs are globally unique > across a MCU or network then I think we need to discuss that because I no= t > sure everyone has the same view. >=20 > Regards, Christian >=20 > On 21/01/2014 9:15 AM, Paul Kyzivat wrote: > > Hmm. I now realize I didn't say what I meant. What I meant was: > > > > My thought was that the the advertiser could specify *any* of: > > > > - MCC(capture1, capture2, ...) > > - MCC(label1) > > - MCC(label1, label2, ...) > > - MCC(capture1, label1, ...) > > > > While the consumer could return either of: > > > > - MCC() > > - MCC(capture1, capture2, ...) > > > > Sorry, > > Paul > > > > > > On 1/20/14 4:46 PM, Duckworth, Mark wrote: > >> Paul and Christian, > >> > >> I was thinking much the same as Paul's approach 2. But maybe the > >> configure message could be limited to something like this?: > >> - MCC() > >> - MCC(capture1, capture2,...) > >> > >> In the configure message, I'm not sure there is an advantage to > >> specifying MCC subsets by label rather than always using capture ID. > >> > >> I always thought of the capture IDs as just a unique identifier, with > >> no intrinsic meaning, like GUIDs. That's why specifying groups of > >> them with ranges (VC1 through VC4) or regular expressions doesn't > >> make sense to me. Putting more meaning into the identifiers seems > >> like a big change to me. > >> > >> Mark > >> > >>> -----Original Message----- > >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>> Sent: Monday, January 20, 2014 1:15 PM > >>> To: clue@ietf.org > >>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in > >>> an MCC - allow wildcard? > >>> > >>> On 1/19/14 9:55 PM, Christian Groves wrote: > >>>> I'd like some more explanation of the concept before agreeing. > >>>> > >>>> The reason why I went with CaptureIDs for the MCC and the > >>>> individual captures was to prevent yet another namespace in CLUE. > >>>> It also worked in with the fact that the Consumer currently only > >>>> returns CaptureIDs and EncodingIDs. Are we now saying that an > >>>> Advertiser sends > >>>> MCC1(label1) and if a Consumer wants a subset it returns > >>>> MCC(Capture1, Capture2, Capture3, etc?). I particularly avoided the > >>>> use of attributes for this because CLUE Configures don't reference > >>>> attributes. > >>> > >>> My thought was that the the consumer could return: > >>> > >>> - MCC() > >>> - MCC(capture1, capture2, ...) > >>> - MCC(label1) > >>> - MCC(label1, label2, ...) > >>> - MCC(capture1, label1, ...) > >>> > >>>> Why couldn't CLUE simply have pattern matching based on regular > >>>> expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.). > >>> > >>> That is a possibility. I question whether it is simpler. I guess it > >>> does make advertisements smaller. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Christian > >>>> > >>>> > >>>> On 19/01/2014 4:20 AM, Paul Kyzivat wrote: > >>>>> On 1/17/14 6:12 PM, Duckworth, Mark wrote: > >>>>>> We discussed this topic in the Jan 14 design team meeting. The > >>>>>> group had interest in the concept, but not my specific proposal. > >>>>>> Jonathan had an interesting idea, which I think better serves the > >>> purpose. > >>>>>> > >>>>>> Instead of the MCC referring specifically to other media captures > >>>>>> that can be contained within the MCC, the MCC can refer to zero > >>>>>> or more "MCC grouping labels". Any other media capture can > >>>>>> include an attribute (zero or more) with a particular MCC > >>>>>> grouping label. The meaning is that any MC that has the same > >>>>>> grouping label that is reference by an MCC can be included in that > MCC. > >>>>>> > >>>>>> I think this doesn't change at all the meaning of MCC, but it > >>>>>> will affect the syntax of how we describe it in the data model > >>>>>> for CLUE messages. > >>>>>> > >>>>>> If the group agrees with this concept, I can propose specific > >>>>>> changes to the framework. > >>>>> > >>>>> This WFM, conceptually. > >>>>> There are details to be worked out for this to be practical and > >>>>> convenient. Those details will presumably be in the data model. > >>>>> > >>>>> Specifically, in the declaration of the MCC, there must be some > >>>>> syntax for the reference. Two approaches come to mind: > >>>>> > >>>>> 1) the new labels share a single namespace with capture ids in the > >>>>> advertisement. The MCC declaration has an element that is used to > >>>>> reference these IDs, of either kind. You can tell which kind by > >>>>> resolving the reference. > >>>>> > >>>>> 2) the new labels have a distinct namespace from capture ids. The > >>>>> MCC declaration allows two different kinds of elements, one to > >>>>> reference capture ids, and another to reference these new labels. > >>>>> > >>>>> I'm inclined to prefer (2) - it seems less kludgy, and is probably > >>>>> equally concise. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>> > >>>>> > >>>>>> Mark > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > >>>>>>> Duckworth, Mark > >>>>>>> Sent: Friday, January 10, 2014 3:47 PM > >>>>>>> To: Paul Kyzivat; clue@ietf.org > >>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcar= d? > >>>>>>> > >>>>>>> Paul, > >>>>>>> > >>>>>>> Yes, I think the wildcard is just a syntax shortcut. > >>>>>>> One other impact that I was thinking of is if we decide to have > >>>>>>> partial updates of advertisements then it removes the need to > >>>>>>> re-advertise any MCC(*) captures when other captures change. > >>>>>>> Without wildcard, any other addition or removal of a > >>>>>>> contributing capture means also re-advertising every MCC with a > >>>>>>> new list of contributors. > >>>>>>> I think the wildcard fits very nicely with the switching > >>>>>>> scenario option (2) from the other discussion thread. > >>>>>>> > >>>>>>> Mark > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul > >>>>>>>> Kyzivat > >>>>>>>> Sent: Friday, January 10, 2014 1:24 PM > >>>>>>>> To: clue@ietf.org > >>>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow > >>>>>>>> wildcard? > >>>>>>>> > >>>>>>>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: > >>>>>>>>> In an advertisement, the provider can indicate which other > >>>>>>>>> captures are referenced by an MCC, for example: > >>>>>>>>> > >>>>>>>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 > >>>>>>>>> > >>>>>>>>> MCC1(VC1, VC2) > >>>>>>>>> > >>>>>>>>> This means MCC1 can include VC1 and/or VC2, but not the > others. > >>>>>>>>> > >>>>>>>>> MCC2() > >>>>>>>>> > >>>>>>>>> Without any specific references, this means the provider is > >>>>>>>>> not saying which other captures can be included in MCC2, and > >>>>>>>>> the consumer cannot choose. > >>>>>>>>> > >>>>>>>>> I propose adding a wildcard: > >>>>>>>>> > >>>>>>>>> MCC3(*) > >>>>>>>> > >>>>>>>> IIUC you mean this to be strictly a syntactic shortcut, not > >>>>>>>> adding any functionality that isn't present without it. > >>>>>>>> > >>>>>>>>> This means MCC3 can include any of the other captures VC1 > >>>>>>>>> through VC5, and the consumer can choose. > >>>>>>>> > >>>>>>>> Do you intent this to mean all the captures in the > >>>>>>>> advertisement, or all the captures in the same scene? > >>>>>>>> > >>>>>>>>> For some types of MCUs, that want to give consumers the > choice > >>>>>>>>> of which specific captures to receive in an MCC, this is > >>>>>>>>> useful for large advertisements with many media captures. > >>>>>>>> > >>>>>>>> Perhaps. But I have my doubts that this would be of common use > >>>>>>>> in > >>>>>>> practice. > >>>>>>>> > >>>>>>>> So it becomes a question of whether the added implementation > >>>>>>>> burden of supporting this optimization is justified for the > >>>>>>>> number of cases when it would be of use. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Paul > >>>>>>>> > >>>>>>>>> When endpoints join or leave a conference, causing the > >>>>>>>>> advertisement to change to add or remove scenes and captures, > >>>>>>>>> the part of the advertisement with MCCs wouldn't have to > >>>>>>>>> change at all. > >>>>>>>>> > >>>>>>>>> Related text from framework-13: > >>>>>>>>> > >>>>>>>>> From 7.2: "The MCC may contain a reference to the Single > >>>>>>>>> Media Captures... (or) A MCC MAY contain no references to > >>>>>>>>> other Captures to indicate that the MCC contains content from > >>>>>>>>> multiple sources but no information regarding those sources is > given." > >>>>>>>>> And in section 10 "If the MCC in the advertisement does not > >>>>>>>>> reference any individual captures, then the Consumer cannot > >>>>>>>>> choose what is included in the MCC" > >>>>>>>>> > >>>>>>>>> I propose adding text: > >>>>>>>>> > >>>>>>>>> The MCC may contain a wildcard reference, meaning it can refer > >>>>>>>>> to any of the other captures in the advertisement. The > >>>>>>>>> consumer, in a configure message, may choose which of the > >>>>>>>>> other media captures it wishes to receive in the MCC. > >>>>>>>>> > >>>>>>>>> What do you think? > >>>>>>>>> > >>>>>>>>> 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 > >> > > > > From ron.even.tlv@gmail.com Tue Jan 21 06:32: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 D680A1A013A for ; Tue, 21 Jan 2014 06:32:22 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 wETtdPPNRGGe for ; Tue, 21 Jan 2014 06:32:21 -0800 (PST) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D5AFA1A0149 for ; Tue, 21 Jan 2014 06:32:20 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id c13so4101891eek.17 for ; Tue, 21 Jan 2014 06:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=VdI0TwL7pwRxGLUYJ5e3ELP15SgijXlblgqruYZWA+c=; b=Hdq938zzFKMhL87xq027vOJ045tG5HPwka+6bRDwkDULaZmBZpve0BjLimWgL8BiOm YMwDxbYuT+Kiew8raXLrOJefcKt09e1Bvi7D9QgEQISimAlMIsVUXXnxAhL6mkJToLFQ uacxJUz3A7E98Oz4vDN1SwsI972hbudwDI7pCYFd+ZUpZR71Ni8y7OdAv7MWBU3/T9xq Td4Ifd6e6W4pPqtmWMcmVR5BPwFTSGgew9Z0iH23HmngQAhBzoHCOjDT43nZLY4/KdjO IvS3IGmdelYf4+WKYVB66SFxQL42gqFq+a0rdmf3v3ZJW6Yq1mxh2EyWdjlYNH+NuvPG o2+A== X-Received: by 10.15.36.65 with SMTP id h41mr24274519eev.0.1390314740299; Tue, 21 Jan 2014 06:32:20 -0800 (PST) Received: from RoniE ([109.66.49.55]) by mx.google.com with ESMTPSA id n7sm15428371eef.5.2014.01.21.06.32.18 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Jan 2014 06:32:19 -0800 (PST) From: "Roni Even" To: "'Paul Kyzivat'" , References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16026@CRPMBOXPRD07.polycom.com> <52DAD8D1.9030904@alum.mit.edu> <52DC9A00.4010609@nteczone.com> <52DD6543.5060405@alum.mit.edu> In-Reply-To: <52DD6543.5060405@alum.mit.edu> Date: Tue, 21 Jan 2014 16:28:35 +0200 Message-ID: <002101cf16b5$13b45230$3b1cf690$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHcjFtgOs7joSxh9RVG2HZ4GHMxNAIJr0mvAXxiL+MA3Yim2ppRNHSQ Content-Language: en-us Subject: Re: [clue] multipoint switching, MCC, and spatial 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: Tue, 21 Jan 2014 14:32:23 -0000 Paul, I think that spatial information in 3 dimensional when y is back to front Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 20 January, 2014 8:05 PM > To: clue@ietf.org > Subject: Re: [clue] multipoint switching, MCC, and spatial information > > On 1/19/14 10:37 PM, Christian Groves wrote: > > >>> On slide 9, for approach 1, it says "MCCs don't have spatial > >>> attributes". But other people in the discussion thought the MCCs > >>> should have spatial attributes. Jonathan said the MCCs could have > >>> spatial information like this (Jonathan, correct me if I don't remember > right): > >>> > >>> MCC1, MCC2, MCC3: left, center, and right of the full scene, like > >>> the image on page 6 for VC1-3. > >>> > >>> MCC4, MCC5, MCC6: spatial information that indicates they are > >>> located on bottom part of MCC1, and much smaller than MCC1, like on > >>> page 6 for VC4-6. > >>> > >>> MCC7, MCC8, MCC9: spatial information that indicates they are > >>> located on bottom part of MCC2, and much smaller than MCC2, like on > >>> page 6 for VC7-9. > > [CNG] Yes MCCs could have spatial information in this context. > > OK, is *this* what you have been talking about Christian? > > I agree this is *possible*. But it will take more specification for consumers to > make sense of this in a consistent way. > > Specifically, our spatial info describes a quadrilateral in a plane in three-space. > In the above there is no mention of the third dimension. Do you assume that > MCC4 and MCC7 fall within the planar area of MCC1? If so, then what should > the stacking order be when composing them? > > Or do you assume that they will be planar areas that are "nearer" to the > capture point than MC1, providing a hint about the stacking order? > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Jan 21 15:39: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 0F2D31A0250 for ; Tue, 21 Jan 2014 15:39:14 -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 Wx4DDHohgLCW for ; Tue, 21 Jan 2014 15:39:10 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BBD1A0259 for ; Tue, 21 Jan 2014 15:39:10 -0800 (PST) Received: from ppp118-209-41-178.lns20.mel4.internode.on.net ([118.209.41.178]:52888 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5krJ-0007lV-FA; Wed, 22 Jan 2014 10:35:53 +1100 Message-ID: <52DF051B.5040809@nteczone.com> Date: Wed, 22 Jan 2014 10:39:07 +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: "Duckworth, Mark" , "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> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF1646F@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] 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: Tue, 21 Jan 2014 23:39:14 -0000 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. 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 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. 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. >>>>>>>> <>>>>>>> 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 From Christian.Groves@nteczone.com Tue Jan 21 16:03: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 363BE1A0266 for ; Tue, 21 Jan 2014 16:03:59 -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 zV15NzdTLvwY for ; Tue, 21 Jan 2014 16:03:56 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id C205B1A0225 for ; Tue, 21 Jan 2014 16:03:55 -0800 (PST) Received: from ppp118-209-41-178.lns20.mel4.internode.on.net ([118.209.41.178]:53309 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5lFH-0002th-Kn; Wed, 22 Jan 2014 11:00:39 +1100 Message-ID: <52DF0AE9.1040509@nteczone.com> Date: Wed, 22 Jan 2014 11:03:53 +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: "Duckworth, Mark" , Paul Kyzivat , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@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] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 22 Jan 2014 00:03:59 -0000 Hello Mark, That is a saving. If we used something like VC4-V15 in each MCC that would be a bigger saving again as there would be no label. I'm not against the label concept I think it just needs to be considered against some examples. I think the other thing to consider is the multiple use case. If you were to take 12.3.3 and wanted to use the labels for all the VCs in MCCs then you end up with: VC1 VC2 VC3 VC4(label=1,4) VC5(label=2,4) VC6(label=3,4) VC7(label=1,4) VC8(label=2,4) VC9(label=3,4) VC10(label=1,4) VC11(label=2,4) VC12(label=3,4) VC13(label=1,4) VC14(label=2,4) VC15(label=3,4) A further issue is would label also apply to MCCs and CSEs? i.e. in tables 23 and 24 of the framework we use the same IDs in the CSE and MCC13. There would be a saving also if we could use "label" for both these instances. Regards, Christian On 22/01/2014 12:03 AM, Duckworth, Mark wrote: > Hello Christian, > Regarding the size of messages, I think in general the label idea will reduce the size. Take Capture Scene #8 from the framework section 12.3.3 as an example. Let's count the number of "tags" (or elements, or attributes, or whatever you want to call them) we need to indicate the associations between MCCs and other captures. > > MCC4 through MCC12, each referring to 12 individual captures. That is 9 x 12 = 108 "tags". > > With the labeling mechanism, each of the 12 individual captures has just one MCC grouping label, and they can all be the same value. That is 12 "tags". Plus each MCC has just one grouping label, again the same value, so that is 9 more tags. Total of just 21 "tags" vs. 108 "tags". So that is a big savings using the labeling mechanism. > > Mark > >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Monday, January 20, 2014 5:41 PM >> To: Paul Kyzivat; Duckworth, Mark; clue@ietf.org >> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - >> allow wildcard? >> >> I think before going for the label approach I think it would be worth to go >> through some examples and compare the size of the messages, i.e. >> comparing using the CaptureIDs vs Labels. Actually I think we need some >> more examples in general to understand the savings for wildcarding. If you >> have to specify an attribute with possibly several labels on each Capture then >> we might not be saving much (if anything) for the complexity. >> >> Also if we mix captures and label then I assume that we have to define the >> name space for each to ensure they didn't overlap? Currently captureIDs >> could be anything. >> >> With respect to putting meaning into the CaptureIDs is it really a big change >> for captureIDs to have some meaning within the session? Our convention in >> the framework of ACx, VCx, etc seems to be working quite well. I'm not sure >> why you'd want the CaptureID to be globally unique like a GUID? That seems >> like overkill. If people are assuming that CaptureIDs are globally unique >> across a MCU or network then I think we need to discuss that because I not >> sure everyone has the same view. >> >> Regards, Christian >> >> On 21/01/2014 9:15 AM, Paul Kyzivat wrote: >>> Hmm. I now realize I didn't say what I meant. What I meant was: >>> >>> My thought was that the the advertiser could specify *any* of: >>> >>> - MCC(capture1, capture2, ...) >>> - MCC(label1) >>> - MCC(label1, label2, ...) >>> - MCC(capture1, label1, ...) >>> >>> While the consumer could return either of: >>> >>> - MCC() >>> - MCC(capture1, capture2, ...) >>> >>> Sorry, >>> Paul >>> >>> >>> On 1/20/14 4:46 PM, Duckworth, Mark wrote: >>>> Paul and Christian, >>>> >>>> I was thinking much the same as Paul's approach 2. But maybe the >>>> configure message could be limited to something like this?: >>>> - MCC() >>>> - MCC(capture1, capture2,...) >>>> >>>> In the configure message, I'm not sure there is an advantage to >>>> specifying MCC subsets by label rather than always using capture ID. >>>> >>>> I always thought of the capture IDs as just a unique identifier, with >>>> no intrinsic meaning, like GUIDs. That's why specifying groups of >>>> them with ranges (VC1 through VC4) or regular expressions doesn't >>>> make sense to me. Putting more meaning into the identifiers seems >>>> like a big change to me. >>>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>> Sent: Monday, January 20, 2014 1:15 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in >>>>> an MCC - allow wildcard? >>>>> >>>>> On 1/19/14 9:55 PM, Christian Groves wrote: >>>>>> I'd like some more explanation of the concept before agreeing. >>>>>> >>>>>> The reason why I went with CaptureIDs for the MCC and the >>>>>> individual captures was to prevent yet another namespace in CLUE. >>>>>> It also worked in with the fact that the Consumer currently only >>>>>> returns CaptureIDs and EncodingIDs. Are we now saying that an >>>>>> Advertiser sends >>>>>> MCC1(label1) and if a Consumer wants a subset it returns >>>>>> MCC(Capture1, Capture2, Capture3, etc?). I particularly avoided the >>>>>> use of attributes for this because CLUE Configures don't reference >>>>>> attributes. >>>>> My thought was that the the consumer could return: >>>>> >>>>> - MCC() >>>>> - MCC(capture1, capture2, ...) >>>>> - MCC(label1) >>>>> - MCC(label1, label2, ...) >>>>> - MCC(capture1, label1, ...) >>>>> >>>>>> Why couldn't CLUE simply have pattern matching based on regular >>>>>> expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.). >>>>> That is a possibility. I question whether it is simpler. I guess it >>>>> does make advertisements smaller. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Christian >>>>>> >>>>>> >>>>>> On 19/01/2014 4:20 AM, Paul Kyzivat wrote: >>>>>>> On 1/17/14 6:12 PM, Duckworth, Mark wrote: >>>>>>>> We discussed this topic in the Jan 14 design team meeting. The >>>>>>>> group had interest in the concept, but not my specific proposal. >>>>>>>> Jonathan had an interesting idea, which I think better serves the >>>>> purpose. >>>>>>>> Instead of the MCC referring specifically to other media captures >>>>>>>> that can be contained within the MCC, the MCC can refer to zero >>>>>>>> or more "MCC grouping labels". Any other media capture can >>>>>>>> include an attribute (zero or more) with a particular MCC >>>>>>>> grouping label. The meaning is that any MC that has the same >>>>>>>> grouping label that is reference by an MCC can be included in that >> MCC. >>>>>>>> I think this doesn't change at all the meaning of MCC, but it >>>>>>>> will affect the syntax of how we describe it in the data model >>>>>>>> for CLUE messages. >>>>>>>> >>>>>>>> If the group agrees with this concept, I can propose specific >>>>>>>> changes to the framework. >>>>>>> This WFM, conceptually. >>>>>>> There are details to be worked out for this to be practical and >>>>>>> convenient. Those details will presumably be in the data model. >>>>>>> >>>>>>> Specifically, in the declaration of the MCC, there must be some >>>>>>> syntax for the reference. Two approaches come to mind: >>>>>>> >>>>>>> 1) the new labels share a single namespace with capture ids in the >>>>>>> advertisement. The MCC declaration has an element that is used to >>>>>>> reference these IDs, of either kind. You can tell which kind by >>>>>>> resolving the reference. >>>>>>> >>>>>>> 2) the new labels have a distinct namespace from capture ids. The >>>>>>> MCC declaration allows two different kinds of elements, one to >>>>>>> reference capture ids, and another to reference these new labels. >>>>>>> >>>>>>> I'm inclined to prefer (2) - it seems less kludgy, and is probably >>>>>>> equally concise. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Mark >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>> Duckworth, Mark >>>>>>>>> Sent: Friday, January 10, 2014 3:47 PM >>>>>>>>> To: Paul Kyzivat; clue@ietf.org >>>>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard? >>>>>>>>> >>>>>>>>> Paul, >>>>>>>>> >>>>>>>>> Yes, I think the wildcard is just a syntax shortcut. >>>>>>>>> One other impact that I was thinking of is if we decide to have >>>>>>>>> partial updates of advertisements then it removes the need to >>>>>>>>> re-advertise any MCC(*) captures when other captures change. >>>>>>>>> Without wildcard, any other addition or removal of a >>>>>>>>> contributing capture means also re-advertising every MCC with a >>>>>>>>> new list of contributors. >>>>>>>>> I think the wildcard fits very nicely with the switching >>>>>>>>> scenario option (2) from the other discussion thread. >>>>>>>>> >>>>>>>>> Mark >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>>>>>>> Kyzivat >>>>>>>>>> Sent: Friday, January 10, 2014 1:24 PM >>>>>>>>>> To: clue@ietf.org >>>>>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow >>>>>>>>>> wildcard? >>>>>>>>>> >>>>>>>>>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: >>>>>>>>>>> In an advertisement, the provider can indicate which other >>>>>>>>>>> captures are referenced by an MCC, for example: >>>>>>>>>>> >>>>>>>>>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 >>>>>>>>>>> >>>>>>>>>>> MCC1(VC1, VC2) >>>>>>>>>>> >>>>>>>>>>> This means MCC1 can include VC1 and/or VC2, but not the >> others. >>>>>>>>>>> MCC2() >>>>>>>>>>> >>>>>>>>>>> Without any specific references, this means the provider is >>>>>>>>>>> not saying which other captures can be included in MCC2, and >>>>>>>>>>> the consumer cannot choose. >>>>>>>>>>> >>>>>>>>>>> I propose adding a wildcard: >>>>>>>>>>> >>>>>>>>>>> MCC3(*) >>>>>>>>>> IIUC you mean this to be strictly a syntactic shortcut, not >>>>>>>>>> adding any functionality that isn't present without it. >>>>>>>>>> >>>>>>>>>>> This means MCC3 can include any of the other captures VC1 >>>>>>>>>>> through VC5, and the consumer can choose. >>>>>>>>>> Do you intent this to mean all the captures in the >>>>>>>>>> advertisement, or all the captures in the same scene? >>>>>>>>>> >>>>>>>>>>> For some types of MCUs, that want to give consumers the >> choice >>>>>>>>>>> of which specific captures to receive in an MCC, this is >>>>>>>>>>> useful for large advertisements with many media captures. >>>>>>>>>> Perhaps. But I have my doubts that this would be of common use >>>>>>>>>> in >>>>>>>>> practice. >>>>>>>>>> So it becomes a question of whether the added implementation >>>>>>>>>> burden of supporting this optimization is justified for the >>>>>>>>>> number of cases when it would be of use. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>>> When endpoints join or leave a conference, causing the >>>>>>>>>>> advertisement to change to add or remove scenes and captures, >>>>>>>>>>> the part of the advertisement with MCCs wouldn't have to >>>>>>>>>>> change at all. >>>>>>>>>>> >>>>>>>>>>> Related text from framework-13: >>>>>>>>>>> >>>>>>>>>>> From 7.2: "The MCC may contain a reference to the Single >>>>>>>>>>> Media Captures... (or) A MCC MAY contain no references to >>>>>>>>>>> other Captures to indicate that the MCC contains content from >>>>>>>>>>> multiple sources but no information regarding those sources is >> given." >>>>>>>>>>> And in section 10 "If the MCC in the advertisement does not >>>>>>>>>>> reference any individual captures, then the Consumer cannot >>>>>>>>>>> choose what is included in the MCC" >>>>>>>>>>> >>>>>>>>>>> I propose adding text: >>>>>>>>>>> >>>>>>>>>>> The MCC may contain a wildcard reference, meaning it can refer >>>>>>>>>>> to any of the other captures in the advertisement. The >>>>>>>>>>> consumer, in a configure message, may choose which of the >>>>>>>>>>> other media captures it wishes to receive in the MCC. >>>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> 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 >>> > From christer.holmberg@ericsson.com Wed Jan 22 01:06: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 CE2011A0381 for ; Wed, 22 Jan 2014 01:06:48 -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 N4cmfq1E4aWt for ; Wed, 22 Jan 2014 01:06:45 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id A03B11A036D for ; Wed, 22 Jan 2014 01:06:44 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-d7-52df8a234c60 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 4E.78.04853.32A8FD25; Wed, 22 Jan 2014 10:06:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Wed, 22 Jan 2014 10:06:43 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Don't use CLUE data channel terminology Thread-Index: Ac8XUS8NTKb7QlBZQx6Z1V6CPy51+w== Date: Wed, 22 Jan 2014 09:06:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D114D5BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvja5y1/0gg3v3FSz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAWrZ7AU7JOpmNb9na2BcbVkFyMnh4SAicTZc4/YIGwxiQv3 1gPZXBxCAicYJbZ82MIE4SxhlJh47BFzFyMHB5uAhUT3P22QBhEBZYmjm/vBmoUFDCTu7HrN CBE3lfh45QYLhK0nceDQLVYQm0VAVeJt72KwGl4BX4mHq3awg9iMQIu/n1rDBGIzC4hLfDh4 nRniIAGJJXvOQ9miEi8f/2OFsJUk1h7ezgJyDrNAvkTPChOIkYISJ2c+YZnAKDQLyaRZCFWz kFRBlOhILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxgli1OLi3PTjQz0ctNzS/RSizKTi4vz 8/SKUzcxAuPi4JbfRjsYT+6xP8QozcGiJM57nbUmSEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAMj56prd5Ze9mOQ+Xiiju/2E8aVWl0vKp+VZPMp23r2HeNefeP71FO+L68EzDS2Kyu6dnPS zXVmqneeb7gRwWgc9eH8AnWbS5JucSKHA/dYrLJb3tju/Vli4Ztlmeaxaesf96tvENEvvZ3n X/GDQ7m4bZLp4urA61OqJS7PendZ8F1hDNN0fgMDJZbijERDLeai4kQApv4qt1kCAAA= Subject: [clue] Don't use CLUE data channel terminology 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, 22 Jan 2014 09:06:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D114D5BESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am currently working on my material for the "CLUE data channel" presentat= ion. The first thing I'd like to suggest already at this point: Please let us no= t use "CLUE data channel" terminology. It makes thing confusing. My suggestion is to talk about "rtcweb data channel for CLUE", "rtcweb data= channel for CLUE usage", or something similar... Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D114D5BESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am currently working on my ma= terial for the “CLUE data channel” presentation.

 

The first thing I’d like = to suggest already at this point: Please let us not use “CLUE data ch= annel” terminology. It makes thing confusing.

 

My suggestion is to talk about = “rtcweb data channel for CLUE”, “rtcweb data channel for = CLUE usage”, or something similar…

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D114D5BESESSMB209erics_-- From christer.holmberg@ericsson.com Wed Jan 22 01:09: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 DE9491A0381 for ; Wed, 22 Jan 2014 01:09:01 -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 CRFPEAP864fu for ; Wed, 22 Jan 2014 01:09:00 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 40B831A0150 for ; Wed, 22 Jan 2014 01:09:00 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-97-52df8aab0a11 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 3F.09.04853.BAA8FD25; Wed, 22 Jan 2014 10:08:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Wed, 22 Jan 2014 10:08:58 +0100 From: Christer Holmberg To: Christer Holmberg , "clue@ietf.org" Thread-Topic: Don't use CLUE data channel terminology Thread-Index: Ac8XUS8NTKb7QlBZQx6Z1V6CPy51+wAAFgmA Date: Wed, 22 Jan 2014 09:08:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D114D78@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D114D78ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje7qrvtBBveOS1jsP3WZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGR+nfWcpmKtW8fLtJNYGxoeKXYycHBICJhKzjs1ig7DFJC7c Ww9kc3EICZxglJj59RwThLOEUeLI/WuMXYwcHGwCFhLd/7RBGkQEIiUOr/vHCGILAw06OuEi O0TcVOLjlRssELaRxO2mVrAFLAKqEjvWTgeL8wr4StzY9IkFZKQQkP3khitImFPAT2Lbmk9g IxmB7vl+ag0TiM0sIC7x4eB1Zog7BSSW7DkPZYtKvHz8jxXCVpJYe3g7C0R9vsT3Q9+hVglK nJz5hGUCo8gsJKNmISmbhaQMIq4ncWPqFDYIW1ti2cLXUPW6EjP+HWJBFl/AyL6KUbI4tbg4 N93IQC83PbdEL7UoM7m4OD9Przh1EyMwkg5u+W20g/HkHvtDjNIcLErivNdZa4KEBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MLac6bN7s1wyZPpjlwabhqKWrO+fOI6V2i9euZWn90iSY9E/ 8d45b84Iram5vfnfXT23J4vbSvK7U4sXaCauTt8/QW3anF/cd0LiT/vq/Zdx7Ho1e25x68Tz Dsq5+8/HMbVLpLmU+0g+FVvUXCkfk8Z+Wylze7u0gti8u5knwufO3LDZsXtKqRJLcUaioRZz UXEiABqmL3FyAgAA Subject: Re: [clue] Don't use CLUE data channel terminology 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, 22 Jan 2014 09:09:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D114D78ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And, just to clarify: my statement below is based on the assumption that we= are going to re-use the rtcweb data channel in CLUE. L=E4hett=E4j=E4: clue [mailto:clue-bounces@ietf.org] Puolesta Christer Holm= berg L=E4hetetty: 22. tammikuuta 2014 11:07 Vastaanottaja: clue@ietf.org Aihe: [clue] Don't use CLUE data channel terminology Hi, I am currently working on my material for the "CLUE data channel" presentat= ion. The first thing I'd like to suggest already at this point: Please let us no= t use "CLUE data channel" terminology. It makes thing confusing. My suggestion is to talk about "rtcweb data channel for CLUE", "rtcweb data= channel for CLUE usage", or something similar... Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D114D78ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

And, ju= st to clarify: my statement below is based on the assumption that we are go= ing to re-use the rtcweb data channel in CLUE.

&n= bsp;

L=E4hett=E4j= =E4: clue [mailto:clue-bounc= es@ietf.org] Puolesta Christer Holmberg
L=E4hetetty: 22. tammikuuta 2014 11:07
Vastaanottaja: clue@ietf.org
Aihe: [clue] Don't use CLUE data channel terminology

 

Hi,

 

I am currently working on my ma= terial for the “CLUE data channel” presentation.

 

The first thing I’d like = to suggest already at this point: Please let us not use “CLUE data ch= annel” terminology. It makes thing confusing.

 

My suggestion is to talk about = “rtcweb data channel for CLUE”, “rtcweb data channel for = CLUE usage”, or something similar…

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D114D78ESESSMB209erics_-- From Christian.Groves@nteczone.com Wed Jan 22 02:19: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 BFCA61A02C2 for ; Wed, 22 Jan 2014 02:19: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 y5PAMS8PDIr9 for ; Wed, 22 Jan 2014 02:19:31 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0131A01EB for ; Wed, 22 Jan 2014 02:19:30 -0800 (PST) Received: from ppp118-209-41-178.lns20.mel4.internode.on.net ([118.209.41.178]:50005 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W5uqs-0006qE-3M for clue@ietf.org; Wed, 22 Jan 2014 21:16:06 +1100 Message-ID: <52DF9B2D.2050907@nteczone.com> Date: Wed, 22 Jan 2014 21:19:25 +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: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D114D78@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D114D78@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] Don't use CLUE data channel terminology 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, 22 Jan 2014 10:19:33 -0000 Hello Christer, I'm abit confused... Why can't we "CLUE channel"? RTCWEB isn't the only application for CLUE. Regards, Christian On 22/01/2014 8:08 PM, Christer Holmberg wrote: > > And, just to clarify: my statement below is based on the assumption > that we are going to re-use the rtcweb data channel in CLUE. > > *Lhettj:*clue [mailto:clue-bounces@ietf.org] *Puolesta *Christer > Holmberg > *Lhetetty:* 22. tammikuuta 2014 11:07 > *Vastaanottaja:* clue@ietf.org > *Aihe:* [clue] Don't use CLUE data channel terminology > > Hi, > > I am currently working on my material for the CLUE data channel > presentation. > > The first thing Id like to suggest already at this point: Please let > us not use CLUE data channel terminology. It makes thing confusing. > > My suggestion is to talk about rtcweb data channel for CLUE, rtcweb > data channel for CLUE usage, or something similar > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Wed Jan 22 07:34: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 F1B491A014B for ; Wed, 22 Jan 2014 07:34:53 -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 qMXJsiIJjI2n for ; Wed, 22 Jan 2014 07:34:50 -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 A1D271A013B for ; Wed, 22 Jan 2014 07:34:50 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id e14so11733628iej.18 for ; Wed, 22 Jan 2014 07:34:50 -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=sBVH3ztsZ7CJ7uniAE1uimISQhlh57SOQax0kk1Qenk=; b=WBlAXTpHdlc0CszzL7FvkJqVB5JewvnY9ziQe9eeAMb5Mu2DNEGSwr/ghSKbNuURdf XzAfd78mYmipFfVSsxIwFZ7ANAs8bJ4DktFbMCaS1VL/n6v0TCIanEPMNpsEzrcjUH+E Jsz3T5qvgtbM8AEDM13ALQO2Y0pvMP8TutKCf5ihqVhnmAyq5QPKVIekcT5gkr74ZhnT aSPvvLrjS9uqTjvf7LxPU5tqqKpQ4pg3sw7H7PizC9eLoAv70u31wmRPhUDsYfhxlTq7 j89hhGXT2XyC/tMG2rD8gwgTa5GdibnoZ6xbG4cptgz9JHT+naQs3BomYJWMXFFr7fuu itUg== MIME-Version: 1.0 X-Received: by 10.43.98.202 with SMTP id cp10mr1704037icc.28.1390404890044; Wed, 22 Jan 2014 07:34:50 -0800 (PST) Received: by 10.43.58.137 with HTTP; Wed, 22 Jan 2014 07:34:49 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D114D78@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D114D78@ESESSMB209.ericsson.se> Date: Wed, 22 Jan 2014 09:34:49 -0600 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec517191190b17f04f090dd14 Cc: "richard.ejzak@alcatel-lucent.com" , "clue@ietf.org" Subject: Re: [clue] Don't use CLUE data channel terminology 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, 22 Jan 2014 15:34:54 -0000 --bcaec517191190b17f04f090dd14 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I did not understand that we were reusing the RTCWEB data channel. I think we need to think more in terms of the work that Richard Ejzak proposed for defining a more generic model for setting up an "application" specific SCTP/DTLS/UDP channel that was dispatched to MMUSIC WG at IETF-88: http://www.ietf.org/proceedings/88/minutes/minutes-88-dispatch While the original draft was focused on WebRTC, the work that was agreed to move forward was the generic SDP procedures, which I think is what CLUE would want to use. I'm cc'ing Richard as I don't think he's on the list and it would be good if we could understand the status of that work. Mary. On Wed, Jan 22, 2014 at 3:08 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > And, just to clarify: my statement below is based on the assumption that > we are going to re-use the rtcweb data channel in CLUE. > > > > *L=E4hett=E4j=E4:* clue [mailto:clue-bounces@ietf.org] *Puolesta *Christe= r > Holmberg > *L=E4hetetty:* 22. tammikuuta 2014 11:07 > *Vastaanottaja:* clue@ietf.org > *Aihe:* [clue] Don't use CLUE data channel terminology > > > > Hi, > > > > I am currently working on my material for the =93CLUE data channel=94 > presentation. > > > > The first thing I=92d like to suggest already at this point: Please let u= s > not use =93CLUE data channel=94 terminology. It makes thing confusing. > > > > My suggestion is to talk about =93rtcweb data channel for CLUE=94, =93rtc= web > data channel for CLUE usage=94, or something similar=85 > > > > Regards, > > > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --bcaec517191190b17f04f090dd14 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I did not understand that we were reusing the RTCWEB data = channel. =A0I think we need to think more in terms of the work that Richard= Ejzak proposed for defining a more generic model for setting up an "a= pplication" specific SCTP/DTLS/UDP channel that was dispatched to MMUS= IC WG at IETF-88:
http://www.ietf.org/proceedings/88/minutes/minutes-88-dispatch

While the original draft was focused on WebRTC, the w= ork that was agreed to move forward was the generic SDP procedures, which I= think is what CLUE would want to use.

I'm cc'ing Richard as I don't think he= 's on the list and it would be good if we could understand the status o= f that work.=A0

Mary.=A0


On Wed, Jan 22, 2014 at 3:08 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wro= te:

And, ju= st to clarify: my statement below is based on the assumption that we are go= ing to re-use the rtcweb data channel in CLUE.

= =A0

L=E4hett=E4j=E4: clue [mailto:= clue-bounces@ietf.org] Puolesta Christer Holmberg
L=E4hetetty: 22. tammikuuta 2014 11:07
Vastaanottaja: cl= ue@ietf.org
Aihe: [clue] Don't use CLUE data channel terminology

=A0

Hi,

=A0

I am currently working on my ma= terial for the =93CLUE data channel=94 presentation.

=A0

The first thing I=92d like to s= uggest already at this point: Please let us not use =93CLUE data channel=94= terminology. It makes thing confusing.

=A0

My suggestion is to talk about = =93rtcweb data channel for CLUE=94, =93rtcweb data channel for CLUE usage= =94, or something similar=85

=A0

Regards,

=A0

Christer


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


--bcaec517191190b17f04f090dd14-- From christer.holmberg@ericsson.com Wed Jan 22 07:39: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 74AEC1A0118 for ; Wed, 22 Jan 2014 07:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.981, 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 b3ZFu32NgymA for ; Wed, 22 Jan 2014 07:39:39 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED9B1A010C for ; Wed, 22 Jan 2014 07:39:38 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-12-52dfe63939b3 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1C.2A.23809.936EFD25; Wed, 22 Jan 2014 16:39:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Wed, 22 Jan 2014 16:39:36 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Don't use CLUE data channel terminology Thread-Index: Ac8XUS8NTKb7QlBZQx6Z1V6CPy51+wAAFgmAAABg7oAADUc3wA== Date: Wed, 22 Jan 2014 15:39:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D11537B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D114D78@ESESSMB209.ericsson.se>, <52DF9B2D.2050907@nteczone.com> In-Reply-To: <52DF9B2D.2050907@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D11537BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvja7ls/tBBk/ahSy+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJXR+Sez4I1TxayNLWwNjH8cuhg5OSQETCSO bmtjgrDFJC7cW8/WxcjFISRwiFFiZvcVdghnCaPE9Ue/WbsYOTjYBCwkuv9pgzSICIRLdGy7 wghiCwtYS9zdtY0FIm4jsenIKVYI20liydJmdhCbRUBVovvxZLAaXgFfidV7DjJDzN/IKLFn 7l2wBk4BHYlHW96DFTECXfT91Bqw65gFxCVuPZkPdamAxJI955khbFGJl4//sULU5Esc+r2e HWKBoMTJmU9YJjAKz0LSPgtJ2SwkZbOAXmMW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzs qxjZcxMzc9LLjTYxAiPk4JbfqjsY75wTOcQozcGiJM774a1zkJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQZGdYsj3+9dXHyj0aLA72el/rppaQLu7bv+NG9aP2/XKdnp7nZf0h4v9bO5faFn 6ZG8Yt11C6e71r3stmzR5jsU+H3ir/arfydOdZZLD+1p+/A/NnevQNj2qF8MKzZ03ZOJEbHP mpUrPEup9fANF+OzV4OK8hyl74bvcBYpPmX3lZl3jkFpnKygEktxRqKhFnNRcSIAYrdrdF4C AAA= Subject: Re: [clue] Don't use CLUE data channel terminology 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, 22 Jan 2014 15:39:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D11537BESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXN0aWFuLA0KDQpUaGUgbmFtZSBvZiB0aGUgZGF0YSBjaGFubmVsIGlzIOKAnHJ0Y3dl YiBkYXRhIGNoYW5uZWzigJ0sIHdoaWNoIGluIHByYWN0aWNlIGlzIGEgc2V0IG9mIFNDVFAgc3Ry ZWFtcyBydW5uaW5nIG9uIHRvcCBvZiBEVExTLiBUaGUgaWRlYSBpcyB0aGF0IHdlIHdpbGwgcnVu IHRoZSBDTFVFIHByb3RvY29sIG9uIHRvcCBvZiB0aGF0IHJ0Y3dlYiBkYXRhIGNoYW5uZWwuDQoN ClllcywgaXQgSVMgY29uZnVzaW5nIPCfmIoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpT ZW50IGZyb20gV2luZG93cyBNYWlsDQoNCkZyb206IENocmlzdGlhbiBHcm92ZXM8bWFpbHRvOkNo cmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29tPg0KU2VudDog4oCOV2VkbmVzZGF54oCOLCDigI5K YW51YXJ54oCOIOKAjjIy4oCOLCDigI4yMDE0IOKAjjEy4oCOOuKAjjE54oCOIOKAjlBNDQpUbzog Y2x1ZUBpZXRmLm9yZzxtYWlsdG86Y2x1ZUBpZXRmLm9yZz4NCg0KSGVsbG8gQ2hyaXN0ZXIsDQoN CkknbSBhYml0IGNvbmZ1c2VkLi4uIFdoeSBjYW4ndCB3ZSAiQ0xVRSBjaGFubmVsIj8gUlRDV0VC IGlzbid0IHRoZSBvbmx5DQphcHBsaWNhdGlvbiBmb3IgQ0xVRS4NCg0KUmVnYXJkcywgQ2hyaXN0 aWFuDQoNCk9uIDIyLzAxLzIwMTQgODowOCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+ DQo+IEFuZCwganVzdCB0byBjbGFyaWZ5OiBteSBzdGF0ZW1lbnQgYmVsb3cgaXMgYmFzZWQgb24g dGhlIGFzc3VtcHRpb24NCj4gdGhhdCB3ZSBhcmUgZ29pbmcgdG8gcmUtdXNlIHRoZSBydGN3ZWIg ZGF0YSBjaGFubmVsIGluIENMVUUuDQo+DQo+ICpMw6RoZXR0w6Rqw6Q6KmNsdWUgW21haWx0bzpj bHVlLWJvdW5jZXNAaWV0Zi5vcmddICpQdW9sZXN0YSAqQ2hyaXN0ZXINCj4gSG9sbWJlcmcNCj4g KkzDpGhldGV0dHk6KiAyMi4gdGFtbWlrdXV0YSAyMDE0IDExOjA3DQo+ICpWYXN0YWFub3R0YWph OiogY2x1ZUBpZXRmLm9yZw0KPiAqQWloZToqIFtjbHVlXSBEb24ndCB1c2UgQ0xVRSBkYXRhIGNo YW5uZWwgdGVybWlub2xvZ3kNCj4NCj4gSGksDQo+DQo+IEkgYW0gY3VycmVudGx5IHdvcmtpbmcg b24gbXkgbWF0ZXJpYWwgZm9yIHRoZSDigJxDTFVFIGRhdGEgY2hhbm5lbOKAnQ0KPiBwcmVzZW50 YXRpb24uDQo+DQo+IFRoZSBmaXJzdCB0aGluZyBJ4oCZZCBsaWtlIHRvIHN1Z2dlc3QgYWxyZWFk eSBhdCB0aGlzIHBvaW50OiBQbGVhc2UgbGV0DQo+IHVzIG5vdCB1c2Ug4oCcQ0xVRSBkYXRhIGNo YW5uZWzigJ0gdGVybWlub2xvZ3kuIEl0IG1ha2VzIHRoaW5nIGNvbmZ1c2luZy4NCj4NCj4gTXkg c3VnZ2VzdGlvbiBpcyB0byB0YWxrIGFib3V0IOKAnHJ0Y3dlYiBkYXRhIGNoYW5uZWwgZm9yIENM VUXigJ0sIOKAnHJ0Y3dlYg0KPiBkYXRhIGNoYW5uZWwgZm9yIENMVUUgdXNhZ2XigJ0sIG9yIHNv bWV0aGluZyBzaW1pbGFy4oCmDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNs dWUgbWFpbGluZyBsaXN0DQo+IGNsdWVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jbHVlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpjbHVlIG1haWxpbmcgbGlzdA0KY2x1ZUBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D11537BESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVu dD0iV2luZG93cyBNYWlsIDE3LjUuOTYwMC4yMDMxNSI+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi PjwhLS1odG1sIHsgZm9udC1mYW1pbHk6ICJDb2xvciBFbW9qaSIsICJDYWxpYnJpIiwgIlNlZ29l IFVJIiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFIZWkgVUkiLCAiTWljcm9zb2Z0IEpoZW5nSGVp IFVJIiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1zZXJpZiI7IH0tLT48L3N0eWxlPjxzdHlsZSBk YXRhLWV4dGVybmFsc3R5bGU9InRydWUiPjwhLS0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaCB7Cm1hcmdpbi10b3A6MGluOwptYXJn aW4tcmlnaHQ6MGluOwptYXJnaW4tYm90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2lu LWJvdHRvbTouMDAwMXB0Owp9CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwgewptYXJnaW46MGluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29MaXN0UGFyYWdy YXBoQ3hTcEZpcnN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBh cmFncmFwaEN4U3BGaXJzdCwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGxpLk1zb0xp c3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIApw Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBk aXYuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0IHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdo dDowaW47Cm1hcmdpbi1ib3R0b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9t Oi4wMDAxcHQ7CmxpbmUtaGVpZ2h0OjExNSU7Cn0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGRpcj0ibHRyIj4NCjxkaXYgZGF0YS1leHRlcm5hbHN0eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0 eWxlPSJmb250LWZhbWlseTogJ0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jv c29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycs ICdzYW5zLXNlcmlmJztmb250LXNpemU6MTJwdDsiPg0KPGRpdj5IaSBDaHJpc3RpYW4sPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgbmFtZSBvZiB0aGUgZGF0YSBjaGFubmVsIGlz Jm5ic3A74oCccnRjd2ViIGRhdGEgY2hhbm5lbOKAnSwgd2hpY2ggaW4gcHJhY3RpY2UgaXMgYSBz ZXQgb2YgU0NUUCBzdHJlYW1zIHJ1bm5pbmcgb24gdG9wIG9mIERUTFMuIFRoZSBpZGVhIGlzIHRo YXQgd2Ugd2lsbCBydW4gdGhlIENMVUUgcHJvdG9jb2wgb24gdG9wIG9mIHRoYXQgcnRjd2ViIGRh dGEgY2hhbm5lbC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlllcywgaXQgSVMgY29u ZnVzaW5nIPCfmIo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaHJpc3RlcjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXYgZGF0YS1zaWduYXR1cmVibG9jaz0idHJ1ZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5TZW50IGZyb20gV2luZG93cyBNYWlsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLXRvcDogNXB4OyBib3JkZXItdG9wLWNvbG9yOiByZ2Io MjI5LCAyMjksIDIyOSk7IGJvcmRlci10b3Atd2lkdGg6IDFweDsgYm9yZGVyLXRvcC1zdHlsZTog c29saWQ7Ij4NCjxkaXY+PGZvbnQgZmFjZT0iICdDYWxpYnJpJywgJ1NlZ29lIFVJJywgJ01laXJ5 bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0IEpoZW5nSGVpIFVJJywgJ01hbGd1 biBHb3RoaWMnLCAnc2Fucy1zZXJpZiciIHN0eWxlPSJsaW5lLWhlaWdodDogMTVwdDsgbGV0dGVy LXNwYWNpbmc6IDAuMDJlbTsgZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssICZxdW90 O1NlZ29lIFVJJnF1b3Q7LCAmcXVvdDtNZWlyeW8mcXVvdDssICZxdW90O01pY3Jvc29mdCBZYUhl aSBVSSZxdW90OywgJnF1b3Q7TWljcm9zb2Z0IEpoZW5nSGVpIFVJJnF1b3Q7LCAmcXVvdDtNYWxn dW4gR290aGljJnF1b3Q7LCAmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEycHQ7 Ij48Yj5Gcm9tOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86Q2hyaXN0aWFuLkdyb3Zlc0BudGVj em9uZS5jb20iIHRhcmdldD0iX3BhcmVudCI+Q2hyaXN0aWFuDQogR3JvdmVzPC9hPjxicj4NCjxi PlNlbnQ6PC9iPiZuYnNwO+KAjldlZG5lc2RheeKAjiwg4oCOSmFudWFyeeKAjiDigI4yMuKAjiwg 4oCOMjAxNCDigI4xMuKAjjrigI4xOeKAjiDigI5QTTxicj4NCjxiPlRvOjwvYj4mbmJzcDs8YSBo cmVmPSJtYWlsdG86Y2x1ZUBpZXRmLm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij5jbHVlQGlldGYub3Jn PC9hPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSIi Pg0KPGRpdiBpZD0icmVhZGluZ1BhbmVCb2R5Q29udGVudCI+SGVsbG8gQ2hyaXN0ZXIsPGJyPg0K PGJyPg0KSSdtIGFiaXQgY29uZnVzZWQuLi4gV2h5IGNhbid0IHdlICZxdW90O0NMVUUgY2hhbm5l bCZxdW90Oz8gUlRDV0VCIGlzbid0IHRoZSBvbmx5IDxicj4NCmFwcGxpY2F0aW9uIGZvciBDTFVF Ljxicj4NCjxicj4NClJlZ2FyZHMsIENocmlzdGlhbjxicj4NCjxicj4NCk9uIDIyLzAxLzIwMTQg ODowOCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgQW5k LCBqdXN0IHRvIGNsYXJpZnk6IG15IHN0YXRlbWVudCBiZWxvdyBpcyBiYXNlZCBvbiB0aGUgYXNz dW1wdGlvbiA8YnI+DQomZ3Q7IHRoYXQgd2UgYXJlIGdvaW5nIHRvIHJlLXVzZSB0aGUgcnRjd2Vi IGRhdGEgY2hhbm5lbCBpbiBDTFVFLjxicj4NCiZndDs8YnI+DQomZ3Q7ICpMw6RoZXR0w6Rqw6Q6 KmNsdWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddICpQdW9sZXN0YSAqQ2hyaXN0ZXIg PGJyPg0KJmd0OyBIb2xtYmVyZzxicj4NCiZndDsgKkzDpGhldGV0dHk6KiAyMi4gdGFtbWlrdXV0 YSAyMDE0IDExOjA3PGJyPg0KJmd0OyAqVmFzdGFhbm90dGFqYToqIGNsdWVAaWV0Zi5vcmc8YnI+ DQomZ3Q7ICpBaWhlOiogW2NsdWVdIERvbid0IHVzZSBDTFVFIGRhdGEgY2hhbm5lbCB0ZXJtaW5v bG9neTxicj4NCiZndDs8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgYW0gY3Vy cmVudGx5IHdvcmtpbmcgb24gbXkgbWF0ZXJpYWwgZm9yIHRoZSDigJxDTFVFIGRhdGEgY2hhbm5l bOKAnSA8YnI+DQomZ3Q7IHByZXNlbnRhdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZmly c3QgdGhpbmcgSeKAmWQgbGlrZSB0byBzdWdnZXN0IGFscmVhZHkgYXQgdGhpcyBwb2ludDogUGxl YXNlIGxldCA8YnI+DQomZ3Q7IHVzIG5vdCB1c2Ug4oCcQ0xVRSBkYXRhIGNoYW5uZWzigJ0gdGVy bWlub2xvZ3kuIEl0IG1ha2VzIHRoaW5nIGNvbmZ1c2luZy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBN eSBzdWdnZXN0aW9uIGlzIHRvIHRhbGsgYWJvdXQg4oCccnRjd2ViIGRhdGEgY2hhbm5lbCBmb3Ig Q0xVReKAnSwg4oCccnRjd2ViIDxicj4NCiZndDsgZGF0YSBjaGFubmVsIGZvciBDTFVFIHVzYWdl 4oCdLCBvciBzb21ldGhpbmcgc2ltaWxhcuKApjxicj4NCiZndDs8YnI+DQomZ3Q7IFJlZ2FyZHMs PGJyPg0KJmd0Ozxicj4NCiZndDsgQ2hyaXN0ZXI8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyBjbHVlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgY2x1ZUBpZXRmLm9yZzxi cj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlPGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpjbHVlIG1haWxpbmcgbGlzdDxicj4NCmNsdWVAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWU8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D11537BESESSMB209erics_-- From christer.holmberg@ericsson.com Wed Jan 22 07:51: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 B10D01A012C for ; Wed, 22 Jan 2014 07:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.981, 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 qhQ4AHR4cRaS for ; Wed, 22 Jan 2014 07:51:49 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 80AE21A0121 for ; Wed, 22 Jan 2014 07:51:48 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-67-52dfe913dd84 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C1.8B.10875.319EFD25; Wed, 22 Jan 2014 16:51:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Wed, 22 Jan 2014 16:51:46 +0100 From: Christer Holmberg To: Mary Barnes Thread-Topic: [clue] Don't use CLUE data channel terminology Thread-Index: Ac8XUS8NTKb7QlBZQx6Z1V6CPy51+wAAFgmAAAtk1IAAArAIwA== Date: Wed, 22 Jan 2014 15:51:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D115483@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D114D78@ESESSMB209.ericsson.se>, 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_7594FB04B1934943A5C02806D1A2204B1D115483ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja7wy/tBBndei1jsP3WZ2eLz/v3M Fr0N4Q7MHq3P9rJ67Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZc6dzFnRlVbzddJSxgXFG ehcjJ4eEgInEphnfWSBsMYkL99azdTFycQgJHGKU6F8yGywhJLCEUeJHB28XIwcHm4CFRPc/ bZCwiICOxLfPb9lAbGaBHInta1+xgtjCAtYSd3dtY4GosZHYdOQUK4TtJDG35SeYzSKgKvF+ 4QdGEJtXwFfizZ2XUHuvMUo8ubSKHSTBKRAoceHtYbAiRqDjvp9awwSxTFzi1pP5TBBHC0gs 2XOeGcIWlXj5+B8rRE2+xKwJS6AWCEqcnPmEZQKjyCwk7bOQlM1CUjYL6E1mAU2J9bv0IUoU JaZ0P2SHsDUkWufMZUcWX8DIvoqRPTcxMye93HATIzCSDm75rbuD8dQ5kUOM0hwsSuK8H946 BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgTG46nSS08rtrhJDXmVeTFFmeieWvmGFqGMSz id0gZPXJuVETg1kKNy1XS9N7btqy8ePJE1+L5k5x2X3UeVn0lYOzShQrHsSWncxhfKP+6JOu 3rtGP/u5TqUPjy6PUa96y7Ag7W7sk39P6xSC247eex2R+CpbJ3Fvec/3nRaKLU95/GrlCn/6 KrEUZyQaajEXFScCAGtXQ2FyAgAA Cc: "richard.ejzak@alcatel-lucent.com" , "clue@ietf.org" Subject: Re: [clue] Don't use CLUE data channel terminology 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, 22 Jan 2014 15:51:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D115483ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBydGN3ZWIgZGF0YSBjaGFubmVsIGlzIG5vdCBydGN3ZWIgYXBwbGljYXRpb24g c3BlY2lmaWMgLSB0aGV5IGp1c3QgY2FsbCBpdCB0aGF0IHJ0Y3dlYiBkYXRhIGNoYW5uZWwgKHdl bGwsIHRoZXkgZG8gbWFrZSBzb21lIGFzc3VtcHRpb25zLCB3aGljaCBhcmUgcnRjd2ViOmlzaCwg YnV0IEkgaGF2ZSBjb21tZW50ZWQgb24gdGhhdCkuDQoNCldoZW4geW91IHVzZSB0aGUgZGF0YSBj aGFubmVsLCB5b3UgZG8gbmVlZCB0byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgcnVubmluZyBvbiB0 b3Agb2YgaXQgKGluIG91ciBjYXNlLCB0aGUgY2x1ZSBwcm90b2NvbCkuIFJpY2hhcmQncyBwcm9w b3NhbCBhbGxvd3MgeW91IHRvIGRvIGl0IGFscmVhZHkgaW4gU0RQLCB3aGlsZSB0aGV5IGRvIGl0 IGluc2lkZSB0aGUgZGF0YSBjaGFubmVsIChvbmNlIGVzdGFibGlzaGVkKS4gQnV0LCBJIGRvbid0 IHRoaW5rIHRoZXJlIGFyZSBhbnkgZGlmZmVyZW5jZXMgaW4gdGhlIGRhdGEgY2hhbm5lbCBpdHNl bGYsIGFuZCBob3cgaXQncyB1c2VkLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50IGZy b20gV2luZG93cyBNYWlsDQoNCkZyb206IE1hcnkgQmFybmVzPG1haWx0bzptYXJ5LmlldGYuYmFy bmVzQGdtYWlsLmNvbT4NClNlbnQ6IOKAjldlZG5lc2RheeKAjiwg4oCOSmFudWFyeeKAjiDigI4y MuKAjiwg4oCOMjAxNCDigI414oCOOuKAjjM04oCOIOKAjlBNDQpUbzogSGFucy1DaHJpc3RlciBI b2xtYmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IGNsdWVA aWV0Zi5vcmc8bWFpbHRvOmNsdWVAaWV0Zi5vcmc+LCByaWNoYXJkLmVqemFrQGFsY2F0ZWwtbHVj ZW50LmNvbTxtYWlsdG86cmljaGFyZC5lanpha0BhbGNhdGVsLWx1Y2VudC5jb20+DQoNCkkgZGlk IG5vdCB1bmRlcnN0YW5kIHRoYXQgd2Ugd2VyZSByZXVzaW5nIHRoZSBSVENXRUIgZGF0YSBjaGFu bmVsLiAgSSB0aGluayB3ZSBuZWVkIHRvIHRoaW5rIG1vcmUgaW4gdGVybXMgb2YgdGhlIHdvcmsg dGhhdCBSaWNoYXJkIEVqemFrIHByb3Bvc2VkIGZvciBkZWZpbmluZyBhIG1vcmUgZ2VuZXJpYyBt b2RlbCBmb3Igc2V0dGluZyB1cCBhbiAiYXBwbGljYXRpb24iIHNwZWNpZmljIFNDVFAvRFRMUy9V RFAgY2hhbm5lbCB0aGF0IHdhcyBkaXNwYXRjaGVkIHRvIE1NVVNJQyBXRyBhdCBJRVRGLTg4Og0K aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84OC9taW51dGVzL21pbnV0ZXMtODgtZGlz cGF0Y2gNCg0KV2hpbGUgdGhlIG9yaWdpbmFsIGRyYWZ0IHdhcyBmb2N1c2VkIG9uIFdlYlJUQywg dGhlIHdvcmsgdGhhdCB3YXMgYWdyZWVkIHRvIG1vdmUgZm9yd2FyZCB3YXMgdGhlIGdlbmVyaWMg U0RQIHByb2NlZHVyZXMsIHdoaWNoIEkgdGhpbmsgaXMgd2hhdCBDTFVFIHdvdWxkIHdhbnQgdG8g dXNlLg0KDQpJJ20gY2MnaW5nIFJpY2hhcmQgYXMgSSBkb24ndCB0aGluayBoZSdzIG9uIHRoZSBs aXN0IGFuZCBpdCB3b3VsZCBiZSBnb29kIGlmIHdlIGNvdWxkIHVuZGVyc3RhbmQgdGhlIHN0YXR1 cyBvZiB0aGF0IHdvcmsuDQoNCk1hcnkuDQoNCg0KT24gV2VkLCBKYW4gMjIsIDIwMTQgYXQgMzow OCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxt YWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpBbmQsIGp1c3Qg dG8gY2xhcmlmeTogbXkgc3RhdGVtZW50IGJlbG93IGlzIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9u IHRoYXQgd2UgYXJlIGdvaW5nIHRvIHJlLXVzZSB0aGUgcnRjd2ViIGRhdGEgY2hhbm5lbCBpbiBD TFVFLg0KDQpMw6RoZXR0w6Rqw6Q6IGNsdWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZz5dIFB1b2xlc3RhIENocmlzdGVyIEhvbG1iZXJn DQpMw6RoZXRldHR5OiAyMi4gdGFtbWlrdXV0YSAyMDE0IDExOjA3DQpWYXN0YWFub3R0YWphOiBj bHVlQGlldGYub3JnPG1haWx0bzpjbHVlQGlldGYub3JnPg0KQWloZTogW2NsdWVdIERvbid0IHVz ZSBDTFVFIGRhdGEgY2hhbm5lbCB0ZXJtaW5vbG9neQ0KDQpIaSwNCg0KSSBhbSBjdXJyZW50bHkg d29ya2luZyBvbiBteSBtYXRlcmlhbCBmb3IgdGhlIOKAnENMVUUgZGF0YSBjaGFubmVs4oCdIHBy ZXNlbnRhdGlvbi4NCg0KVGhlIGZpcnN0IHRoaW5nIEnigJlkIGxpa2UgdG8gc3VnZ2VzdCBhbHJl YWR5IGF0IHRoaXMgcG9pbnQ6IFBsZWFzZSBsZXQgdXMgbm90IHVzZSDigJxDTFVFIGRhdGEgY2hh bm5lbOKAnSB0ZXJtaW5vbG9neS4gSXQgbWFrZXMgdGhpbmcgY29uZnVzaW5nLg0KDQpNeSBzdWdn ZXN0aW9uIGlzIHRvIHRhbGsgYWJvdXQg4oCccnRjd2ViIGRhdGEgY2hhbm5lbCBmb3IgQ0xVReKA nSwg4oCccnRjd2ViIGRhdGEgY2hhbm5lbCBmb3IgQ0xVRSB1c2FnZeKAnSwgb3Igc29tZXRoaW5n IHNpbWlsYXLigKYNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNsdWUgbWFpbGluZyBsaXN0DQpjbHVlQGll dGYub3JnPG1haWx0bzpjbHVlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jbHVlDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D115483ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVu dD0iV2luZG93cyBNYWlsIDE3LjUuOTYwMC4yMDMxNSI+DQo8c3R5bGUgZGF0YS1leHRlcm5hbHN0 eWxlPSJ0cnVlIj48IS0tCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGggewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsK bWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFw dDsKfQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsIHsKbWFyZ2luOjBp bjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0Owp9CnAuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwg bGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmly c3QsIApwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hT cE1pZGRsZSwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCAKcC5Nc29MaXN0UGFyYWdy YXBoQ3hTcExhc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGhDeFNwTGFzdCB7Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwptYXJnaW4t Ym90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0OwpsaW5l LWhlaWdodDoxMTUlOwp9Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8 ZGl2IGRhdGEtZXh0ZXJuYWxzdHlsZT0iZmFsc2UiIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1p bHk6ICdDYWxpYnJpJywgJ1NlZ29lIFVJJywgJ01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUkn LCAnTWljcm9zb2Z0IEpoZW5nSGVpIFVJJywgJ01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZic7 Zm9udC1zaXplOjEycHQ7Ij4NCjxkaXY+SGksPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5UaGUgcnRjd2ViIGRhdGEgY2hhbm5lbCBpcyBub3QgcnRjd2ViIGFwcGxpY2F0aW9uIHNwZWNp ZmljIC0gdGhleSBqdXN0IGNhbGwgaXQgdGhhdCBydGN3ZWIgZGF0YSBjaGFubmVsICh3ZWxsLCB0 aGV5IGRvIG1ha2Ugc29tZSBhc3N1bXB0aW9ucywgd2hpY2ggYXJlIHJ0Y3dlYjppc2gsIGJ1dCBJ IGhhdmUgY29tbWVudGVkIG9uIHRoYXQpLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ V2hlbiB5b3UgdXNlIHRoZSBkYXRhIGNoYW5uZWwsIHlvdSBkbyBuZWVkIHRvIGluZGljYXRlIHRo ZSBwcm90b2NvbCBydW5uaW5nIG9uIHRvcCBvZiBpdCAoaW4gb3VyIGNhc2UsIHRoZSBjbHVlIHBy b3RvY29sKS4gUmljaGFyZCdzIHByb3Bvc2FsIGFsbG93cyB5b3UgdG8gZG8gaXQgYWxyZWFkeSBp biBTRFAsIHdoaWxlIHRoZXkgZG8gaXQgaW5zaWRlIHRoZSBkYXRhIGNoYW5uZWwgKG9uY2UgZXN0 YWJsaXNoZWQpLiBCdXQsIEkgZG9uJ3QNCiB0aGluayB0aGVyZSBhcmUgYW55IGRpZmZlcmVuY2Vz IGluIHRoZSBkYXRhIGNoYW5uZWwgaXRzZWxmLCBhbmQgaG93IGl0J3MgdXNlZC48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5DaHJpc3Rlcjxicj4NCjwvZGl2Pg0KPGRpdiBkYXRhLXNpZ25hdHVyZWJsb2NrPSJ0cnVl Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNlbnQgZnJvbSBXaW5kb3dzIE1haWw8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9InBhZGRpbmctdG9wOiA1cHg7 IGJvcmRlci10b3AtY29sb3I6IHJnYigyMjksIDIyOSwgMjI5KTsgYm9yZGVyLXRvcC13aWR0aDog MXB4OyBib3JkZXItdG9wLXN0eWxlOiBzb2xpZDsiPg0KPGRpdj48Zm9udCBmYWNlPSIgJ0NhbGli cmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jvc29mdCBZYUhlaSBVSScsICdNaWNyb3Nv ZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycsICdzYW5zLXNlcmlmJyIgc3R5bGU9Imxp bmUtaGVpZ2h0OiAxNXB0OyBsZXR0ZXItc3BhY2luZzogMC4wMmVtOyBmb250LWZhbWlseTogJnF1 b3Q7Q2FsaWJyaSZxdW90OywgJnF1b3Q7U2Vnb2UgVUkmcXVvdDssICZxdW90O01laXJ5byZxdW90 OywgJnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCAmcXVvdDtNaWNyb3NvZnQgSmhlbmdI ZWkgVUkmcXVvdDssICZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssICZxdW90O3NhbnMtc2VyaWYm cXVvdDs7IGZvbnQtc2l6ZTogMTJwdDsiPjxiPkZyb206PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0 bzptYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfcGFyZW50Ij5NYXJ5DQogQmFy bmVzPC9hPjxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwO+KAjldlZG5lc2RheeKAjiwg4oCOSmFudWFy eeKAjiDigI4yMuKAjiwg4oCOMjAxNCDigI414oCOOuKAjjM04oCOIOKAjlBNPGJyPg0KPGI+VG86 PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20i IHRhcmdldD0iX3BhcmVudCI+SGFucy1DaHJpc3RlciBIb2xtYmVyZzwvYT48YnI+DQo8Yj5DYzo8 L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmNsdWVAaWV0Zi5vcmciIHRhcmdldD0iX3BhcmVudCI+ Y2x1ZUBpZXRmLm9yZzwvYT4sIDxhIGhyZWY9Im1haWx0bzpyaWNoYXJkLmVqemFrQGFsY2F0ZWwt bHVjZW50LmNvbSIgdGFyZ2V0PSJfcGFyZW50Ij4NCnJpY2hhcmQuZWp6YWtAYWxjYXRlbC1sdWNl bnQuY29tPC9hPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYg ZGlyPSIiPg0KPGRpdiBkaXI9Imx0ciI+SSBkaWQgbm90IHVuZGVyc3RhbmQgdGhhdCB3ZSB3ZXJl IHJldXNpbmcgdGhlIFJUQ1dFQiBkYXRhIGNoYW5uZWwuICZuYnNwO0kgdGhpbmsgd2UgbmVlZCB0 byB0aGluayBtb3JlIGluIHRlcm1zIG9mIHRoZSB3b3JrIHRoYXQgUmljaGFyZCBFanphayBwcm9w b3NlZCBmb3IgZGVmaW5pbmcgYSBtb3JlIGdlbmVyaWMgbW9kZWwgZm9yIHNldHRpbmcgdXAgYW4g JnF1b3Q7YXBwbGljYXRpb24mcXVvdDsgc3BlY2lmaWMgU0NUUC9EVExTL1VEUCBjaGFubmVsDQog dGhhdCB3YXMgZGlzcGF0Y2hlZCB0byBNTVVTSUMgV0cgYXQgSUVURi04ODo8YnI+DQo8ZGl2Pjxh IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODgvbWludXRlcy9taW51dGVz LTg4LWRpc3BhdGNoIiB0YXJnZXQ9Il9wYXJlbnQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvODgvbWludXRlcy9taW51dGVzLTg4LWRpc3BhdGNoPC9hPjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+V2hpbGUgdGhlIG9yaWdpbmFsIGRyYWZ0IHdhcyBmb2N1c2VkIG9uIFdl YlJUQywgdGhlIHdvcmsgdGhhdCB3YXMgYWdyZWVkIHRvIG1vdmUgZm9yd2FyZCB3YXMgdGhlIGdl bmVyaWMgU0RQIHByb2NlZHVyZXMsIHdoaWNoIEkgdGhpbmsgaXMgd2hhdCBDTFVFIHdvdWxkIHdh bnQgdG8gdXNlLjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkknbSBjYydp bmcgUmljaGFyZCBhcyBJIGRvbid0IHRoaW5rIGhlJ3Mgb24gdGhlIGxpc3QgYW5kIGl0IHdvdWxk IGJlIGdvb2QgaWYgd2UgY291bGQgdW5kZXJzdGFuZCB0aGUgc3RhdHVzIG9mIHRoYXQgd29yay4m bmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk1hcnkuJm5ic3A7PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxicj4N CjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIEphbiAyMiwgMjAxNCBhdCAzOjA4IEFN LCBDaHJpc3RlciBIb2xtYmVyZyA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRv OmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfcGFyZW50Ij5jaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhl eDsgcGFkZGluZy1sZWZ0OiAxZXg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIw NCk7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsiPg0K PGRpdiBsYW5nPSJGSSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkFuZCwganVzdCB0byBjbGFy aWZ5OiBteSBzdGF0ZW1lbnQgYmVsb3cgaXMgYmFzZWQgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB3 ZSBhcmUgZ29pbmcgdG8gcmUtdXNlIHRoZSBydGN3ZWIgZGF0YSBjaGFubmVsIGluIENMVUUuPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjx1PjwvdT4mbmJzcDs8dT48 L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItd2lkdGg6IDFwdCBtZWRp dW0gbWVkaXVtOyBib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLWNvbG9yOiBy Z2IoMTgxLCAxOTYsIDIyMykgYmxhY2sgYmxhY2s7IHBhZGRpbmc6IDNwdCAwY20gMGNtOyBib3Jk ZXItaW1hZ2U6IG5vbmU7Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZv bnQtc2l6ZTogMTBwdDsiPkzDpGhldHTDpGrDpDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQt c2l6ZTogMTBwdDsiPiBjbHVlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmNsdWUtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij5jbHVlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ UHVvbGVzdGEgPC9iPkNocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+TMOkaGV0ZXR0eTo8L2I+IDIy LiB0YW1taWt1dXRhIDIwMTQgMTE6MDc8YnI+DQo8Yj5WYXN0YWFub3R0YWphOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOmNsdWVAaWV0Zi5vcmciIHRhcmdldD0iX3BhcmVudCI+Y2x1ZUBpZXRmLm9yZzwv YT48YnI+DQo8Yj5BaWhlOjwvYj4gW2NsdWVdIERvbid0IHVzZSBDTFVFIGRhdGEgY2hhbm5lbCB0 ZXJtaW5vbG9neTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBjbGFzcz0iaDUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIGN1cnJlbnRseSB3b3JraW5nIG9uIG15IG1hdGVy aWFsIGZvciB0aGUg4oCcQ0xVRSBkYXRhIGNoYW5uZWzigJ0gcHJlc2VudGF0aW9uLjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGZpcnN0IHRoaW5nIEnigJlkIGxpa2UgdG8gc3VnZ2VzdCBh bHJlYWR5IGF0IHRoaXMgcG9pbnQ6IFBsZWFzZSBsZXQgdXMgbm90IHVzZSDigJxDTFVFIGRhdGEg Y2hhbm5lbOKAnSB0ZXJtaW5vbG9neS4gSXQgbWFrZXMgdGhpbmcgY29uZnVzaW5nLjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+TXkgc3VnZ2VzdGlvbiBpcyB0byB0YWxrIGFib3V0IOKAnHJ0Y3dl YiBkYXRhIGNoYW5uZWwgZm9yIENMVUXigJ0sIOKAnHJ0Y3dlYiBkYXRhIGNoYW5uZWwgZm9yIENM VUUgdXNhZ2XigJ0sIG9yIHNvbWV0aGluZyBzaW1pbGFy4oCmPHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT4mbmJz cDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5SZWdhcmRzLDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hyaXN0ZXI8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KY2x1ZSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Y2x1ZUBpZXRmLm9yZyIgdGFyZ2V0PSJf cGFyZW50Ij5jbHVlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZSIgdGFyZ2V0PSJfcGFyZW50Ij5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWU8L2E+PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D115483ESESSMB209erics_-- From pkyzivat@alum.mit.edu Wed Jan 22 08:35: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 ED2011A0128 for ; Wed, 22 Jan 2014 08:35:59 -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_15=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 24AY3UWbTswm for ; Wed, 22 Jan 2014 08:35:58 -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 1AD7B1A0121 for ; Wed, 22 Jan 2014 08:35:58 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta13.westchester.pa.mail.comcast.net with comcast id H24K1n0030EZKEL5D4bxxa; Wed, 22 Jan 2014 16:35:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id H4bx1n0093ZTu2S3M4bxBY; Wed, 22 Jan 2014 16:35:57 +0000 Message-ID: <52DFF36D.1060508@alum.mit.edu> Date: Wed, 22 Jan 2014 11:35:57 -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: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D114D78@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D115483@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D115483@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390408557; bh=Krowq4K/rGLl0fKpfT77U/35JNX88xL0OXCY8aDgXoo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bvT2iIW9EmCoOXggPysBEXJGnw7jxYx+LWwlcH8KjH5/M7MIUg5OCqQlzg+CDlnij KiYR4koiIkjAWvHcTkI6geLW0j0z6druihNlhPJ0WyUh5Fs1M7FHKHSffsD0SBEf3+ l3zIeqmplytVf3qh3+0eNkZFPu2OrmYwov0kj0d5DkcFlFtXYjcaauo71hD5eXe0NH iOIz4wvP+xWU5RDOgu+Umml7SvYuCL5YGzJEbC6oyhYZvp1/1iYZSsPv/iYNva5X2I rmawJ2D1lk/TdzavWCP/tH9YhI68D2snBG0f16ggGmT1gQ0E9PpYjoMqUoHA0LtfEt MSS+pdYTWDm/Q== Subject: Re: [clue] Don't use CLUE data channel terminology 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, 22 Jan 2014 16:36:00 -0000 Christer, I don't see why we should be referencing rtcweb at all when talking about this. We are using a channel that is defined in transport, and described in SDP defined in mmusic. We do happen to be using a mechanism that has a lot in common with the rtcweb data channel. That is helpful both because they are doing a lot of the definition work for us, and because we hope this will facilitate making webrtc clients for clue. But much of the usage will be without webrtc. Note that xxx currently uses a=webrtc-DataChannel and a=wdcsa, but I already commented to Richard about that, and he agreed that those names should be changed. (To a=DataChannel and a=csa.) Thanks, Paul On 1/22/14 10:51 AM, Christer Holmberg wrote: > Hi, > > The rtcweb data channel is not rtcweb application specific - they just > call it that rtcweb data channel (well, they do make some assumptions, > which are rtcweb:ish, but I have commented on that). > > When you use the data channel, you do need to indicate the protocol > running on top of it (in our case, the clue protocol). Richard's > proposal allows you to do it already in SDP, while they do it inside the > data channel (once established). But, I don't think there are any > differences in the data channel itself, and how it's used. > > Regards, > > Christer > > Sent from Windows Mail > > *From:* Mary Barnes > *Sent:* ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎5‎:‎34‎ ‎PM > *To:* Hans-Christer Holmberg > *Cc:* clue@ietf.org , > richard.ejzak@alcatel-lucent.com > > I did not understand that we were reusing the RTCWEB data channel. I > think we need to think more in terms of the work that Richard Ejzak > proposed for defining a more generic model for setting up an > "application" specific SCTP/DTLS/UDP channel that was dispatched to > MMUSIC WG at IETF-88: > http://www.ietf.org/proceedings/88/minutes/minutes-88-dispatch > > While the original draft was focused on WebRTC, the work that was agreed > to move forward was the generic SDP procedures, which I think is what > CLUE would want to use. > > I'm cc'ing Richard as I don't think he's on the list and it would be > good if we could understand the status of that work. > > Mary. > > > On Wed, Jan 22, 2014 at 3:08 AM, Christer Holmberg > > > wrote: > > And, just to clarify: my statement below is based on the assumption > that we are going to re-use the rtcweb data channel in CLUE.____ > > __ __ > > *Lähettäjä:*clue [mailto:clue-bounces@ietf.org > ] *Puolesta *Christer Holmberg > *Lähetetty:* 22. tammikuuta 2014 11:07 > *Vastaanottaja:* clue@ietf.org > *Aihe:* [clue] Don't use CLUE data channel terminology____ > > __ __ > > Hi,____ > > __ __ > > I am currently working on my material for the “CLUE data channel” > presentation.____ > > __ __ > > The first thing I’d like to suggest already at this point: Please > let us not use “CLUE data channel” terminology. It makes thing > confusing.____ > > __ __ > > My suggestion is to talk about “rtcweb data channel for CLUE”, > “rtcweb data channel for CLUE usage”, or something similar…____ > > __ __ > > 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 Jan 22 10:17: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 A25441A037F for ; Wed, 22 Jan 2014 10:17: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 UgFXM1F4qrdx for ; Wed, 22 Jan 2014 10:17:40 -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 CAD711A02F1 for ; Wed, 22 Jan 2014 10:17:39 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta05.westchester.pa.mail.comcast.net with comcast id H0i31n00A17dt5G556HfBg; Wed, 22 Jan 2014 18:17:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id H6He1n00M3ZTu2S3Z6He2e; Wed, 22 Jan 2014 18:17:39 +0000 Message-ID: <52E00B42.5040409@alum.mit.edu> Date: Wed, 22 Jan 2014 13:17:38 -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: Christian Groves , "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@CRPMBOXPRD07.polycom.com> <52DF0AE9.1040509@nteczone.com> In-Reply-To: <52DF0AE9.1040509@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=1390414659; bh=YFetwdTmRFy3ujHtlvaIrWP1DBcDbpAUguEgFAMcCDs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cxLKxU5hCmdJVa7JcY9f2qy6mbAhaQ6gd9C2niYRF7Aqa5+Pvp8uVCuyysfb/gzof xjfmhSEvYh27TXfR4d+r+tsw5jCm0gRZHX3vyz060lrsBpterJHsIK6Es0e+QNEXUa GPhMJaUi5Js4k6A4FK3GQsR+8xCiTC5fjHoAyf2uFhMkARBXAyw4S5L8Y3hCS1p7pi SAkpkK2Y1gB9r2dBdeDb/HSxBjh8chNPnEa6El2EQ5xB9UNKZxaS+LHZU63tZL+Txh MrGW9kpismjr71dsnA1Hb7G9CrZ/XSLUDeWmeYXR6tBvCxe055YJATgX52Azdiw3du vJdicVR/fYrbA== Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 22 Jan 2014 18:17:43 -0000 On 1/21/14 7:03 PM, Christian Groves wrote: > Hello Mark, > > That is a saving. If we used something like VC4-V15 in each MCC that > would be a bigger saving again as there would be no label. I think I have finally understood what you are proposing. I agree that it could work to allow use of regular expressions applied to capture ids to select individual captures within the same advertisement, in the specification of MCCs, and possibly in CSEs too. That would be an alternative to using separate labels. And as long as it is used just within the advertisement, the same entity is assigning the capture ids and constructing the REs that reference them, so has full freedom to construct the capture ids in a way that makes it convenient to write REs that match what it wants to match. In principle the REs could also be used in Configure messages to select the subset of captures desired in an MCC. But I think it would have little value there, because it would be difficult to automate the construction of the REs for an arbitrary advertisement. (For that matter, its not clear to me how the consumer chooses a subset at all. The most likely things I can imagine are: - some algorithm chooses a complete CSE and displays it. Then user can request to have some portion of the display omitted. - some algorithm gives previews of possible layouts and lets users pick, with omissions. All if these involve identifying specific captures identified in the advertisement. The capture ids probably aren't interesting to the end user. So selection is based on picking particular captures, not REs.) So I see no reason to use REs in the Configure. The downside of REs, if there is one, is that they may be more complex to implement in some contexts. (Though there are RE libraries for most environments.) They might also be slightly more costly in computation, but probably not enough to matter. We would of course need to choose a precise definition of RE syntax. > I'm not against the label concept I think it just needs to be considered > against some examples. > I think the other thing to consider is the multiple use case. If you > were to take 12.3.3 and wanted to use the labels for all the VCs in MCCs > then you end up with: > > VC1 > VC2 > VC3 > VC4(label=1,4) > VC5(label=2,4) > VC6(label=3,4) > VC7(label=1,4) > VC8(label=2,4) > VC9(label=3,4) > VC10(label=1,4) > VC11(label=2,4) > VC12(label=3,4) > VC13(label=1,4) > VC14(label=2,4) > VC15(label=3,4) When using labels, it would be easier to follow if the labels had some significance. E.g. labels like "left", "center", "right". > A further issue is would label also apply to MCCs and CSEs? i.e. in > tables 23 and 24 of the framework we use the same IDs in the CSE and > MCC13. There would be a saving also if we could use "label" for both > these instances. With either labels or REs, it does seem to make sense to allow their use in both MCCs and CSEs. Thanks, Paul > Regards, Christian > > On 22/01/2014 12:03 AM, Duckworth, Mark wrote: >> Hello Christian, >> Regarding the size of messages, I think in general the label idea will >> reduce the size. Take Capture Scene #8 from the framework section >> 12.3.3 as an example. Let's count the number of "tags" (or elements, >> or attributes, or whatever you want to call them) we need to indicate >> the associations between MCCs and other captures. >> >> MCC4 through MCC12, each referring to 12 individual captures. That is >> 9 x 12 = 108 "tags". >> >> With the labeling mechanism, each of the 12 individual captures has >> just one MCC grouping label, and they can all be the same value. That >> is 12 "tags". Plus each MCC has just one grouping label, again the >> same value, so that is 9 more tags. Total of just 21 "tags" vs. 108 >> "tags". So that is a big savings using the labeling mechanism. >> >> Mark >> >>> -----Original Message----- >>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>> Sent: Monday, January 20, 2014 5:41 PM >>> To: Paul Kyzivat; Duckworth, Mark; clue@ietf.org >>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in >>> an MCC - >>> allow wildcard? >>> >>> I think before going for the label approach I think it would be worth >>> to go >>> through some examples and compare the size of the messages, i.e. >>> comparing using the CaptureIDs vs Labels. Actually I think we need some >>> more examples in general to understand the savings for wildcarding. >>> If you >>> have to specify an attribute with possibly several labels on each >>> Capture then >>> we might not be saving much (if anything) for the complexity. >>> >>> Also if we mix captures and label then I assume that we have to >>> define the >>> name space for each to ensure they didn't overlap? Currently captureIDs >>> could be anything. >>> >>> With respect to putting meaning into the CaptureIDs is it really a >>> big change >>> for captureIDs to have some meaning within the session? Our >>> convention in >>> the framework of ACx, VCx, etc seems to be working quite well. I'm >>> not sure >>> why you'd want the CaptureID to be globally unique like a GUID? That >>> seems >>> like overkill. If people are assuming that CaptureIDs are globally >>> unique >>> across a MCU or network then I think we need to discuss that because >>> I not >>> sure everyone has the same view. >>> >>> Regards, Christian >>> >>> On 21/01/2014 9:15 AM, Paul Kyzivat wrote: >>>> Hmm. I now realize I didn't say what I meant. What I meant was: >>>> >>>> My thought was that the the advertiser could specify *any* of: >>>> >>>> - MCC(capture1, capture2, ...) >>>> - MCC(label1) >>>> - MCC(label1, label2, ...) >>>> - MCC(capture1, label1, ...) >>>> >>>> While the consumer could return either of: >>>> >>>> - MCC() >>>> - MCC(capture1, capture2, ...) >>>> >>>> Sorry, >>>> Paul >>>> >>>> >>>> On 1/20/14 4:46 PM, Duckworth, Mark wrote: >>>>> Paul and Christian, >>>>> >>>>> I was thinking much the same as Paul's approach 2. But maybe the >>>>> configure message could be limited to something like this?: >>>>> - MCC() >>>>> - MCC(capture1, capture2,...) >>>>> >>>>> In the configure message, I'm not sure there is an advantage to >>>>> specifying MCC subsets by label rather than always using capture ID. >>>>> >>>>> I always thought of the capture IDs as just a unique identifier, with >>>>> no intrinsic meaning, like GUIDs. That's why specifying groups of >>>>> them with ranges (VC1 through VC4) or regular expressions doesn't >>>>> make sense to me. Putting more meaning into the identifiers seems >>>>> like a big change to me. >>>>> >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>> Sent: Monday, January 20, 2014 1:15 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in >>>>>> an MCC - allow wildcard? >>>>>> >>>>>> On 1/19/14 9:55 PM, Christian Groves wrote: >>>>>>> I'd like some more explanation of the concept before agreeing. >>>>>>> >>>>>>> The reason why I went with CaptureIDs for the MCC and the >>>>>>> individual captures was to prevent yet another namespace in CLUE. >>>>>>> It also worked in with the fact that the Consumer currently only >>>>>>> returns CaptureIDs and EncodingIDs. Are we now saying that an >>>>>>> Advertiser sends >>>>>>> MCC1(label1) and if a Consumer wants a subset it returns >>>>>>> MCC(Capture1, Capture2, Capture3, etc?). I particularly avoided the >>>>>>> use of attributes for this because CLUE Configures don't reference >>>>>>> attributes. >>>>>> My thought was that the the consumer could return: >>>>>> >>>>>> - MCC() >>>>>> - MCC(capture1, capture2, ...) >>>>>> - MCC(label1) >>>>>> - MCC(label1, label2, ...) >>>>>> - MCC(capture1, label1, ...) >>>>>> >>>>>>> Why couldn't CLUE simply have pattern matching based on regular >>>>>>> expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.). >>>>>> That is a possibility. I question whether it is simpler. I guess it >>>>>> does make advertisements smaller. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Christian >>>>>>> >>>>>>> >>>>>>> On 19/01/2014 4:20 AM, Paul Kyzivat wrote: >>>>>>>> On 1/17/14 6:12 PM, Duckworth, Mark wrote: >>>>>>>>> We discussed this topic in the Jan 14 design team meeting. The >>>>>>>>> group had interest in the concept, but not my specific proposal. >>>>>>>>> Jonathan had an interesting idea, which I think better serves the >>>>>> purpose. >>>>>>>>> Instead of the MCC referring specifically to other media captures >>>>>>>>> that can be contained within the MCC, the MCC can refer to zero >>>>>>>>> or more "MCC grouping labels". Any other media capture can >>>>>>>>> include an attribute (zero or more) with a particular MCC >>>>>>>>> grouping label. The meaning is that any MC that has the same >>>>>>>>> grouping label that is reference by an MCC can be included in that >>> MCC. >>>>>>>>> I think this doesn't change at all the meaning of MCC, but it >>>>>>>>> will affect the syntax of how we describe it in the data model >>>>>>>>> for CLUE messages. >>>>>>>>> >>>>>>>>> If the group agrees with this concept, I can propose specific >>>>>>>>> changes to the framework. >>>>>>>> This WFM, conceptually. >>>>>>>> There are details to be worked out for this to be practical and >>>>>>>> convenient. Those details will presumably be in the data model. >>>>>>>> >>>>>>>> Specifically, in the declaration of the MCC, there must be some >>>>>>>> syntax for the reference. Two approaches come to mind: >>>>>>>> >>>>>>>> 1) the new labels share a single namespace with capture ids in the >>>>>>>> advertisement. The MCC declaration has an element that is used to >>>>>>>> reference these IDs, of either kind. You can tell which kind by >>>>>>>> resolving the reference. >>>>>>>> >>>>>>>> 2) the new labels have a distinct namespace from capture ids. The >>>>>>>> MCC declaration allows two different kinds of elements, one to >>>>>>>> reference capture ids, and another to reference these new labels. >>>>>>>> >>>>>>>> I'm inclined to prefer (2) - it seems less kludgy, and is probably >>>>>>>> equally concise. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Mark >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>> Duckworth, Mark >>>>>>>>>> Sent: Friday, January 10, 2014 3:47 PM >>>>>>>>>> To: Paul Kyzivat; clue@ietf.org >>>>>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow >>>>>>>>>> wildcard? >>>>>>>>>> >>>>>>>>>> Paul, >>>>>>>>>> >>>>>>>>>> Yes, I think the wildcard is just a syntax shortcut. >>>>>>>>>> One other impact that I was thinking of is if we decide to have >>>>>>>>>> partial updates of advertisements then it removes the need to >>>>>>>>>> re-advertise any MCC(*) captures when other captures change. >>>>>>>>>> Without wildcard, any other addition or removal of a >>>>>>>>>> contributing capture means also re-advertising every MCC with a >>>>>>>>>> new list of contributors. >>>>>>>>>> I think the wildcard fits very nicely with the switching >>>>>>>>>> scenario option (2) from the other discussion thread. >>>>>>>>>> >>>>>>>>>> Mark >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>>>>>>>> Kyzivat >>>>>>>>>>> Sent: Friday, January 10, 2014 1:24 PM >>>>>>>>>>> To: clue@ietf.org >>>>>>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow >>>>>>>>>>> wildcard? >>>>>>>>>>> >>>>>>>>>>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: >>>>>>>>>>>> In an advertisement, the provider can indicate which other >>>>>>>>>>>> captures are referenced by an MCC, for example: >>>>>>>>>>>> >>>>>>>>>>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 >>>>>>>>>>>> >>>>>>>>>>>> MCC1(VC1, VC2) >>>>>>>>>>>> >>>>>>>>>>>> This means MCC1 can include VC1 and/or VC2, but not the >>> others. >>>>>>>>>>>> MCC2() >>>>>>>>>>>> >>>>>>>>>>>> Without any specific references, this means the provider is >>>>>>>>>>>> not saying which other captures can be included in MCC2, and >>>>>>>>>>>> the consumer cannot choose. >>>>>>>>>>>> >>>>>>>>>>>> I propose adding a wildcard: >>>>>>>>>>>> >>>>>>>>>>>> MCC3(*) >>>>>>>>>>> IIUC you mean this to be strictly a syntactic shortcut, not >>>>>>>>>>> adding any functionality that isn't present without it. >>>>>>>>>>> >>>>>>>>>>>> This means MCC3 can include any of the other captures VC1 >>>>>>>>>>>> through VC5, and the consumer can choose. >>>>>>>>>>> Do you intent this to mean all the captures in the >>>>>>>>>>> advertisement, or all the captures in the same scene? >>>>>>>>>>> >>>>>>>>>>>> For some types of MCUs, that want to give consumers the >>> choice >>>>>>>>>>>> of which specific captures to receive in an MCC, this is >>>>>>>>>>>> useful for large advertisements with many media captures. >>>>>>>>>>> Perhaps. But I have my doubts that this would be of common use >>>>>>>>>>> in >>>>>>>>>> practice. >>>>>>>>>>> So it becomes a question of whether the added implementation >>>>>>>>>>> burden of supporting this optimization is justified for the >>>>>>>>>>> number of cases when it would be of use. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>>> When endpoints join or leave a conference, causing the >>>>>>>>>>>> advertisement to change to add or remove scenes and captures, >>>>>>>>>>>> the part of the advertisement with MCCs wouldn't have to >>>>>>>>>>>> change at all. >>>>>>>>>>>> >>>>>>>>>>>> Related text from framework-13: >>>>>>>>>>>> >>>>>>>>>>>> From 7.2: "The MCC may contain a reference to the Single >>>>>>>>>>>> Media Captures... (or) A MCC MAY contain no references to >>>>>>>>>>>> other Captures to indicate that the MCC contains content from >>>>>>>>>>>> multiple sources but no information regarding those sources is >>> given." >>>>>>>>>>>> And in section 10 "If the MCC in the advertisement does not >>>>>>>>>>>> reference any individual captures, then the Consumer cannot >>>>>>>>>>>> choose what is included in the MCC" >>>>>>>>>>>> >>>>>>>>>>>> I propose adding text: >>>>>>>>>>>> >>>>>>>>>>>> The MCC may contain a wildcard reference, meaning it can refer >>>>>>>>>>>> to any of the other captures in the advertisement. The >>>>>>>>>>>> consumer, in a configure message, may choose which of the >>>>>>>>>>>> other media captures it wishes to receive in the MCC. >>>>>>>>>>>> >>>>>>>>>>>> What do you think? >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>> >> > > From pkyzivat@alum.mit.edu Wed Jan 22 10:33: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 610E61A0199 for ; Wed, 22 Jan 2014 10:33:25 -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 OqW-ERdGmCDC for ; Wed, 22 Jan 2014 10:33:21 -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 C28A41A011B for ; Wed, 22 Jan 2014 10:33:12 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta06.westchester.pa.mail.comcast.net with comcast id H0Pg1n00416LCl0566ZCEa; Wed, 22 Jan 2014 18:33:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id H6ZB1n01G3ZTu2S3S6ZBBu; Wed, 22 Jan 2014 18:33:12 +0000 Message-ID: <52E00EE7.3020205@alum.mit.edu> Date: Wed, 22 Jan 2014 13:33: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: 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> In-Reply-To: <52DF051B.5040809@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=1390415592; bh=RuAvJhxcy97Yg648cS4ATKjyGxw6mtzgGW+87ezBH0c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pTldKt1rQfIxMbs6f1z0vj2klIfhx/iM7PPsdP+IBVt2vCyNcr9QlVq2k+eric3NA omVEN495eHzdEBotYP6T2L68yTZbg/d5HXamiMpbmf1DxL/1DW6iA2ek7IRQhPM1pX CVLoejOCHSSRKrSoILj20NOPL8LKsMm/zYOWXM0a2krfQvb5z9xBxwfikph7zbqA7T rHDo14a8IiqT14p2Oi/Y+QSMl3zR0uk4guNpo89H/rR1/LVnSBIOJy74wuJXJgS7tL dzBz5LX7d2zkDT2pOj4JPihqZ00Wh849qMHsL/NJkYh+9wb+1aJ99u3njD51bRBOjm ITXvDIx9rkOUQ== Subject: Re: [clue] 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, 22 Jan 2014 18:33:25 -0000 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. >>>>>>>>> <>>>>>>>> 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 > From Mark.Duckworth@polycom.com Wed Jan 22 16: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 B00411A0116 for ; Wed, 22 Jan 2014 16:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 XoGR-5oWSFlP for ; Wed, 22 Jan 2014 16:16:18 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id E5A9F1A015F for ; Wed, 22 Jan 2014 16:16:16 -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, 22 Jan 2014 16:16:16 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Wed, 22 Jan 2014 16:16:16 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Wed, 22 Jan 2014 16:16:13 -0800 Thread-Topic: [clue] spatial information can't describe video locations within composed MCC Thread-Index: Ac8XoH/yY4MpDhX0Q0Kr7cwR8wt2qgALysLQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D01E6DF@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> In-Reply-To: <52E00EE7.3020205@alum.mit.edu> 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_49E45C59CA48264997FEBFB29B6BC2D60C9D01E6DFCRPMBOXPRD07p_" MIME-Version: 1.0 Subject: Re: [clue] 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, 23 Jan 2014 00:16:29 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D01E6DFCRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, Paul wrote: "Lets first discuss if having this information would provide si= gnificant 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 wi= thin > 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 composi= tion. > > 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 th= e > 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 declarat= ion of > the MCC to explicitly do it. > > But I don't really see the point of doing so. What can the consumer do wh= en > 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 would giv= e > > 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 v= alue. 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 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=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 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D01E6DFCRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,=

 

Paul wrote: "Lets first discuss if having this information would p= rovide 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 stic= k with that decision.

 

Mark

 

> -----Original Message-----<= /p>

> From: clue [mailto:clue-bounces@ietf.org] O= n Behalf Of Paul Kyzivat

> Sent: Wednesday, J= anuary 22, 2014 1:33 PM

> To: clue@ietf.org

> Subject: Re: [clue] spatial information can'= t describe video locations within

> composed = MCC

>

> On 1/2= 1/14 6:39 PM, Christian Groves wrote:

> > = Hello Mark,

> >

> > I think I know where the disconnect is between us. Its to do wit= h the

> > encodings. In my examples I've b= een assumed that Provider only

> > provide= s the encoding for MCC1 not the constituent captures. Whereas

> > you've been assuming that encodings are being pro= vided for the

> > individual and MCC captu= res.

> >

> &= gt; In the case of the encoding only being on the MCC the consumer knows

> > because the VCs and MCC belong to the sa= me Capture Scene. The

> > Advertiser has p= rovided 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 o= f the

> captures without encodings for an ent= irely 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

> indi= rection, such as you do in example below. Yet another hack.)

>

> > In the case of mult= iple encodings the spatial information associated

> > with an individual capture is likely to be a difference between= the

> > individual encodings and the MCC = encoding.

> >

&= gt; > 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

> > V= C1 - left

> > VC2 - center

> > VC3 - right

> > MCC2= (VC1) - left-composed

> > MCC3(VC2) - cent= er-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 i= ntroduce an explicit encoding for the

> posit= ions of the sources of a composition. (But used an obscure and

> confusing notation.)

> <= /p>

> If we really want that, then I suggest we j= ust add syntax to the declaration of

> the MC= C to explicitly do it.

>

> But I don't really see the point of doing so. What can the con= sumer do when

> it has this info that it woul= dn't be able to do without it?

>

> > In order to address the maxCaptures issue perhaps= we need to modify

> > "MaxCaptures&q= uot; slightly so that it becomes "NumberofCaptures" where we

<= p class=3DMsoPlainText>> > could say NumberofCaptures=3D3 or Numberof= Captures<=3D3. This would give

> > more= certainty to the Consumer about what will actually be sent.

>

> That is just another ste= p towards describing the complete layout of the

= > composition.

>

> Lets first discuss if having this information would provide signifi= cant value. If

> so then we can discuss how t= o provide it.

>

&= gt;             Than= ks,

>       &nb= sp;     Paul

>

> > Regards, Christian

&= gt; >

> >

&g= t; > On 21/01/2014 11:54 PM, Duckworth, Mark wrote:

> >> Hello Christian,

> >&= gt;

> >> I still don't see how the cons= umer 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, maxCa= ptures=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 a= ny 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 comp= osed.  Yet it

> >> still makes sen= se for the provider to give spatial information for

> >> the captures themselves.

> = >>

> >> Mark

> >>

> >>> -----Orig= inal 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

> >>> Sub= ject: Re: [clue] spatial information can't describe video

> >>> locations within composed MCC

> >>>

> >>> He= llo Mark and Paul,

> >>>

> >>> Please see my responses below.

> >>>

> >>= > Regards, Christian

> >>>

> >>> On 21/01/2014 8:29 AM, Duckworth, Ma= rk wrote:

> >>>> Christian,

> >>>>

>= >>>> I agree with Paul.

> >&g= t;>>

> >>>> 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 ap= ply."

> >>>> That might be t= rue, 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 consum= er knows this because the Provider only provides the

> >>> spatial information when it makes sense to do so.

> >>>

> = >>>> Mark

> >>>>

<= p class=3DMsoPlainText>> >>>>> -----Original Message-----=

> >>>>> From: clue [mailto:cl= ue-bounces@ietf.org] On Behalf Of Paul

> >= >>>> Kyzivat

> >>>>&g= t; Sent: Monday, January 20, 2014 12:44 PM

> = >>>>> To: clue@ietf.org

> >= >>>> Subject: Re: [clue] spatial information can't describe vid= eo

> >>>>> locations within co= mposed MCC

> >>>>>

> >>>>> On 1/19/14 9:36 PM, Christian Gro= ves wrote:

> >>>>>> Hello M= ark,

> >>>>>>

> >>>>>> Sorry for the delayed respons= e. I was on vacation last week. I

> >>&= gt;>>> see there's been quite a lot of activity over the last week= with

> >>>>>> respect to M= CCs and the framework.

> >>>>>= >

> >>>>>> I saw the min= utes of the meeting and saw there was a mention that

> >>>>>> I should argue :-).

> >>>>>>

> >&g= t;>>>> I don't agree with the outcome of the meeting. I think i= ts

> >>>>>> important to no= te that MCC doesn't equal switching. A MCC may

&= gt; >>>>>> represent a dynamic switching case OR a static= case. A static

> >>>>>> ca= se 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 app= ly.

> >>>>> We may not have un= derstood you. We were guessing what you

> mea= nt.

> >>>>>

> >>>>> Suppose there is an MCC that has three i= nput captures, and

> >>>>> com= poses

> >>> them.

> >>>>> It could compose them in many ways. It c= ould 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.

> >&= gt;> [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 coordi= nates of the source captures are

> >>&g= t;>> presumably meaningful if they are individually configured. We

> >>>>> could see no reason to p= resume 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 cr= eating a virtual scene using these source

> &= gt;>> captures.

> >>> Giving C= aptures spatial co-ordinates within a virtual scene is a

> >>> valid thing to do irrespective of the use of a M= CC. The MCU may

> >>> apply any tran= sformation it wants based on the source capture

= > >>> information. I think this equally applies to the MCC itse= lf.

> >>> Now if the MCU constructs = a composed image from several sources

> >&= gt;> 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 thi= s.

> >>>>>

> >>>>>>    From the minutes I = didn't see an explanation of other people's

>= >>> concerns.

> >>>>>= ;> So rather than a complete prohibition of the spatial information

<= p class=3DMsoPlainText>> >>>>>> regarding individual c= aptures I think it would be better to

> >&= gt;>>>> explain that the Advertiser has a choice to include the=

> >>>>>> information and t= hat the spatial information is only meaningful

&= gt; >>>>>> if the individual capture's spatial informatio= n is static. That's

> >>>>>>= ; what I tried to capture in the text below.

>= ; >>>>> I already commented on this earlier.

> >>>>> IMO the advertiser MAY provide spatia= l information on an MCC. That

> >>>&= gt;> would describe a place within the scene of the MCC. IMO that is a

> >>>>> suggestion by the adver= tiser, but doesn't have the same physical

> &= gt;>>>> significance as will a non-MCC capture.

> >>> [CNG] I don't understand why the spatial info= rmation of the MCC has

> >>> less si= gnificance than a non-MCC capture? An Advertiser constructs

> >>> the scene, it give the spatial positioning. I= f 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<= /p>

> >>>>> capture. Or, if it is = smarter, and the MCC is *switched*, it could

>= ; >>>>> ignore this and look into the spatial info for the s= ource captures.

> >>> [CNG] If the M= CC is "switched" AND the spatial information changes

> >>> between source captures then this would b= e the dynamic case. I think

> >>> th= e 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

<= p class=3DMsoPlainText>> >>> spatial information is the same th= en the Advertiser can simply

> >>> s= upply the spatial information at the MCC level without the need to

> >>> set it on the sources.

> >>>>> But none of that has anything to do w= ith the the arrangement of

> >>>>= > composed captures within an MCC.

> >&= gt;> [CNG] I don't understand the point. You only focused on the switche= d

> >>> case.

> >>> MCC is for switching and composition.

> >>>>>      &= nbsp;  Thanks,

> >>>>>&nb= sp;        Paul

> >>>>>

> >>>&g= t;>> Regards, Christian

> >>>&= gt;>>

> >>>>>> On 18/= 01/2014 9:50 AM, Duckworth, Mark wrote:

> >= ;>>>>>> We discussed this topic in the design team meetin= g Jan 14

> >>>>>>> <h= ttp://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-

> >>>>> Team/minutes_140114.txt>.

<= p class=3DMsoPlainText>> >>>>>>>   From t= he minutes:

> >>>>>>>

> >>>>>>> "Conclusion= 1: Spatial information of the individual captures

> >>>>>>> does not apply inside a composed MCC.&= quot;

> >>>>>>>

> >>>>>>> We wanted to bring thi= s topic back to the list to make sure we

> &g= t;>>>>>> have consensus before clarifying the framework a= bout this.

> >>>>>>> Chr= istian, or anybody else, do you still want more discussion?

> >>>>>>>

&g= t; >>>>>>> Regards,

> &g= t;>>>>>> Mark

> >>>= ;>>>>

> >>>>>>&= gt;> -----Original Message-----

> >>= >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behal= f Of

> >>>>>>>> Duckw= orth, Mark

> >>>>>>>>= Sent: Friday, January 10, 2014 4:04 PM

> >= ;>>>>>>> To: Christian Groves; clue@ietf.org

> >>>>>>>> Subject: Re: [clue]= spatial information can't describe video

> &= gt;>>>>>> locations within

>= ; >>>>>>>

> >>>= >>>>> composed MCC

> >>&= gt;>>>>> Thanks Christian, that is an improvement. But I'm s= till not

> >>>>>>> convi= nced the

> >>>>>>>

> >>>>>>>> consumer can al= ways tell when the spatial attributes are

> &= gt;>>>>>>> meaningful

> = >>>>>>> (even

> >>= >>>>>

> >>>>>&g= t;>> within a scene) for discerning how contributors to a composed

> >>>>>>>> MCC are arra= nged within the MCC. My concerns 2, 3, and 4 below

> >>>>>>>> still apply.

> >>>>>>>> Does anybody else have input to= this topic?

> >>>>>>>&g= t; Mark

> >>>>>>>>>= ; -----Original Message-----

> >>>&g= t;>>>>> From: Christian Groves [mailto:Christian.Groves@ntec= zone.com]

> >>>>>>>>&= gt; 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

> >>>>>>>>&g= t; Single Media Captures that the MCC references. A provider

> >>>>>>>>> should avoid providi= ng conflicting attribute values between

> >= ;>>>>>>>> the MCC and Single Media Captures. Where = there is conflict the

> >>>>>&= gt;>>> attributes of the MCC override any that may be present in t= he

> individual captures.

> >>>>>>>>> <<When assigning sp= atial attributes to 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.

> &g= t;>>>>>>>> Therefore

>= ; >>>>>>>>> if the Provider intends to provide a= spatial relation between

> >>>>&= gt;>>>> the source Captures and the MCC then these MUST be part= of

> the

> >= ;>>>>>>>> same

> >= >>>>>>> Capture Scene.

>= >>>>>>>>> When assigning spatial information th= at would cause the

> >>>>>>= >>> spatial positioning of the source Capture to move within the

> >>>>>>>>> MCC, th= e

> >>>>>>> Provider

=

> >>>>>>>

> >>>>>>>>> should also be aware th= at a Consumer may not be able to

> >>&g= t;>>>>>> determine

> >&g= t;>>>>> that

> >>>>= ;>>>

> >>>>>>>&= gt;> the source captures have moved.>> ...

> >>>>>>>>> Regards, Christian

> >>>>>>>>> On 8/01/2014 12:= 18 AM, Duckworth, Mark wrote:

> >>>&= gt;>>>>>> Hello Christian,

>= ; >>>>>>>>>> So there are only certain circum= stances in which spatial

> >>>>&g= t;>> information

> >>>>>= >>

> >>>>>>>>&g= t;> for

> >>>>>>>>= > components of a composed capture is relevant. For the case

> >>>>>>>>> where you think i= t is important and relevant, can you please

>= >>>>>>>>> propose text for the framework to des= cribe this? I think the

> >>>>>= ;>>>> framework should be more clear about when and how the

=

> consumer

> >&= gt;>>>>>>> can use

> >= ;>> this

> >>>>>>>= >> information for composed captures.

>= >>>>>>>>>> Mark

&= gt; >>>>>>>>>>> -----Original Message-----=

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

> >>>>>>>>>>> Christian Grove= s

> >>>>>>>>>>&= gt; Sent: Tuesday, January 07, 2014 12:08 AM

>= ; >>>>>>>>>>> To: clue@ietf.org

> >>>>>>>>>>> Subject:= Re: [clue] spatial information can't describe video

> >>>>>>>>>>> locations within com= posed MCC Hello Mark, I agree with

> >>= >>>>>>>>> respect to the fact that spatial infor= mation isn't valid

> >>>>>>= >>>>> across Capture Scenes. i.e. If I have an MCC in one

> >>>>>>> Cap.Scene

> >>>>>>>

> >>>>>>>>>>> referencing indivi= dual captures from other scenes. However I

> = >>>>>>>>>>> think there is a valid case wh= ere an MCC can reference

> >>>>&g= t;>>>>>> Individual captures from the same scene as it. I= n this case

> >>>>>>>>= ;>>> I think the

> >>>>&= gt;>> use of

> >>>>>>= >

> >>>>>>>>>&g= t;> spatial

> >>>>>>>= >> information is valid, i.e.

> >>= ;>>>>>>>>> +-----------------------+------------= ---------------------+

> >>>>>= >>>>>> | Capture Scene #1 | |

= > >>>>>>>>>>> +-----------------------|= ---------------------------------+

> >>= >>>>>>>>> | VC1 | CapArea=3DLeft |

> >>>>>>>>>>> | VC2 | C= apArea=3DRight |

> >>>>>>&g= t;>>>> | MCC1(VC1, VC2) | |

> >= ;>>>>>>>>>> +--------------------------------= -------------------------+

> >>>>= >>>>>>> or

> >>>= ;>>>>>>>> +-----------------------+----------------= -----------------+

> >>>>>>= >>>>> | Capture Scene #1 | |

>= >>>>>>>>>>> +-----------------------|----= -----------------------------+

> >>>= >>>>>>>> | MCC1(VC1) | CapArea=3DLeft |

> >>>>>>>>>>> | MCC2(VC= 2) | CapArea=3DRight |

> >>>>>= >>>>>> | MCC1(MCC1,MCC2) | |

&= gt; >>>>>>>>>>> +-------------------------= --------------------------------+

> >>&= gt;>>>>>>>> where VC1 and VC2 are from different Ca= pture Scenes.

> >>>>>>>&= gt;>>> There are of course cases where the spatial information

=

> >>>>>>> wouldn't be

> >>>>>>>

> >>>>>>>>>>> valid but in thos= e cases the Provider wouldn't provide them,

>= >>>>>>>>>>> i.e.

> >>>>>>>>>>> where the individual c= aptures move. However there will be

> >>= ;>>>>>>>>> cases where the composition is static= and the information

> >>>>>&g= t;>>>>> would be

> >>>= ;>>>> valid.

> >>>>&g= t;>>

> >>>>>>>>= >>> I don't think we can make a general assumption that the

> >>>>>>>>>>> spat= ial information is

> >>>>>>= >>> valid or invalid in all cases.

>= >>>>>>>>>>> Regards, Christian

> >>>>>>>>>>> On 7/01/= 2014 7:54 AM, Duckworth, Mark wrote:

> >&g= t;>>>>>>>>>> Framework version 13 says a prov= ider can use spatial

> >>>>>&g= t;>>>>>> information of source media captures to describe= how those

> >>>>>>>>= >>>> sources are placed within a composed multiple content

<= p class=3DMsoPlainText>> >>>>>>>>>>>>= ; 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 remo= ving that part, and instead add text to

> >= ;>>>>>>>>>>> say the spatial information o= f individual captures does not

> >>>= >>>>>>>>> relate to its relative position within= a

> >>>>>>> composed

> >>>>>>>

> >>>>>>>> MCC.

> >>>>>>>>>>>>   Fro= m section 7.2.1:

> >>>>>>&g= t;>>>>> For example: The spatial related attributes can be f= urther

> >>>>>>> used to=

> >>>>>>>

> >>>>>>>>>>>> deter= mine how the individual captures "appear" within a

> >>>>>>>>>>>> stream. = A virtual scene could be constructed for the MCC

> >>>>>>>>>>>> capture with two Vid= eo Captures with a "MaxCaptures"

> = >>>>>>>>>>>> attribute set to 2 and an = "Area of Capture" attribute

> >&= gt;>>>>>>>>>> provided with an overall area.<= /p>

> >>>>>>> Each of

> >>>>>>>

> >>>>>>>>>>>> the individual= Captures could then also include an "Area of

> >>>>>>> Capture"

> >>>>>>>

> >&g= t;>>>>>>>>>> attribute with a sub-set of the = overall area. The Consumer

> >>>>= >>>>>>>> would then know the relative position of t= he content in the

> >>>>>>&= gt;>>>>> composed

> >>&g= t;>>>>> stream.

> >>>= >>>>>>>>> Here are some reasons why I think this= will generally not

> work:

> >>>>>>>>>>>> 1.The spati= al information for captures is relevant only in

= > >>>>>>>>>>>> relation to the captu= re scene to which the captures belong.

> >= >>>>>>>>>>> Spatial information from diffe= rent scenes has no relation

> >>>>= ;>>>>>>>> to each other. So if the individual captu= res that are part

> >>>>>>&= gt;>>>>> of a composed MCC come from different scenes (sourc= e

> >>>>>>>>>>&= gt;> captures

> >>> from

> >>>>>>>>>>>> mu= ltiple scenes, or source captures from different scenes

> >>>>>>>>>>>> than the

<= p class=3DMsoPlainText>> >>>>>>>>>>>>= ; MCC)

> >>>>>>>>>= >>> then the spatial information of one capture has no relation

> >>>>>>>>>>>&= gt; to

> >>>>>>> the

=

> >>>>>>>

> >>>>>>>>>>>> spatial inf= ormation of another capture.

> >>>&g= t;>>>>>>>> 2.In the example with MaxCaptures =3D 2,= that doesn't mean

> >>>>>>= >>>>>> there will always be 2 contributing captures in th= e MCC. It

> >>>>>>>>&= gt;>>> just means maximum of 2, but sometimes there could be 1.

> >>>>>>>>>>>&= gt; The contents of the MCC could actually be changing over

> >>>>>>>>>>>> time betw= een 1 and 2

> >>>>>>>>= ; contributing captures.

> >>>>&g= t;>>>>>>> If it changes between one full screen source= image to two

> >>>>>>>&= gt;>>>> source images side by side, then the spatial informatio= n

> >>>>>>>>>>&= gt;> wouldn't always indicate the location of the source within

> >>>>>>>>>>>> th= e MCC. We have no

> >>>>>>&= gt; 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

&g= t; >>>>>>> talking

> >= ;>>>>>>

> >>>>&= gt;>>>>>>> and a small image of the other. This would = change over

> >>>>>>>>= ;>>>> time, so again the spatial information wouldn't always

> >>>>>>>>>>>&= gt; indicate the location of the source within the MCC.

> >>>>>>>>>>>> 4.Take a slig= htly different example, where the MCC contains

&= gt; >>>>>>>>>>>> 4 contributing individ= ual captures, but still with

> >>>&g= t;>>>>>>>> MaxCaptures =3D 2.

> >>>>>>>>>>>> So the resultin= g MCC again will change over time, as the

> &= gt;>>>>>>>>>>> provider is free to choose = which 2 out of the 4 to include

> >>>= ;>>>>>>>>> at any time. So again the spatial inf= ormation wouldn't

> >>>>>>&= gt;>>>>> always indicate the location of the source within t= he MCC.

> >>>>>>>>>= ;>>> Regards,

> >>>>>= >>>>>>> Mark

> >>&= gt;>>>>>>>>>

> ___= ____________________________________________

>= ; >>>>>>>>>>>> clue mailing list

> >>>>>>>>>>>> = clue@ietf.org <<= span style=3D'color:windowtext;text-decoration:none'>mailto:clue@ietf.org>

> >>>>>>>&= gt;>>>> = https://www.ietf.org/= mailman/listinfo/clue

> >>&g= t;>>>>>>>> ________________________________________= _______

> >>>>>>>>>= ;>> clue mailing list

> >>>>= ;>>>>>>> clue@ietf.org <mailto:clue@ietf.org>

>= ; >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue

> >>>>>>>> _________________________= ______________________

> >>>>>= >>> clue mailing list

> >>>= >>>>> clue@ietf.org <m= ailto:clue@ietf.org>

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

> >&= gt;>>>>>

> >>>>>= ;>> _______________________________________________

> >>>>>>> clue mailing list

> >>>>>>> clue@ietf.org=

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

> >>>>>> _______= ________________________________________

> &g= t;>>>>> clue mailing list

> &g= t;>>>>> clue@ietf.org

> >>>>>> https://www.ietf.org/mailman/listinfo/clue

> >>>>>>

> >&g= t;>>> _______________________________________________

> >>>>> clue mailing list

> >>>>> clue@ietf.org<= /p>

> >>>>> 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<= /p>

> > clue@ietf.org

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

> >

>

>= _______________________________________________

> clue mailing list

> clue@ie= tf.org

> https://www.ietf.org/mailman/listinfo/clue

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D01E6DFCRPMBOXPRD07p_-- From Christian.Groves@nteczone.com Wed Jan 22 17:44: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 AC2451A03A2 for ; Wed, 22 Jan 2014 17:44: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 FDyQRRDBQ6mY for ; Wed, 22 Jan 2014 17:44:07 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6051C1A0266 for ; Wed, 22 Jan 2014 17:44:06 -0800 (PST) Received: from ppp118-209-167-50.lns20.mel6.internode.on.net ([118.209.167.50]:55550 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W69HV-0006Wk-VU; Thu, 23 Jan 2014 12:40:34 +1100 Message-ID: <52E073E1.4010305@nteczone.com> Date: Thu, 23 Jan 2014 12:44:01 +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: Paul Kyzivat , "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@CRPMBOXPRD07.polycom.com> <52DF0AE9.1040509@nteczone.com> <52E00B42.5040409@alum.mit.edu> In-Reply-To: <52E00B42.5040409@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 grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 23 Jan 2014 01:44:10 -0000 Hello Paul, Please see my comments below. Regards, Christian On 23/01/2014 5:17 AM, Paul Kyzivat wrote: > On 1/21/14 7:03 PM, Christian Groves wrote: >> Hello Mark, >> >> That is a saving. If we used something like VC4-V15 in each MCC that >> would be a bigger saving again as there would be no label. > > I think I have finally understood what you are proposing. I agree that > it could work to allow use of regular expressions applied to capture > ids to select individual captures within the same advertisement, in > the specification of MCCs, and possibly in CSEs too. > > That would be an alternative to using separate labels. And as long as > it is used just within the advertisement, the same entity is assigning > the capture ids and constructing the REs that reference them, so has > full freedom to construct the capture ids in a way that makes it > convenient to write REs that match what it wants to match. [CNG] Yes I agree the intention would only to be to use it in the advertisement. > > In principle the REs could also be used in Configure messages to > select the subset of captures desired in an MCC. But I think it would > have little value there, because it would be difficult to automate the > construction of the REs for an arbitrary advertisement. (For that > matter, its not clear to me how the consumer chooses a subset at all. > The most likely things I can imagine are: > - some algorithm chooses a complete CSE and displays it. > Then user can request to have some portion of the display omitted. > - some algorithm gives previews of possible layouts and lets users > pick, with omissions. > All if these involve identifying specific captures identified in the > advertisement. The capture ids probably aren't interesting to the end > user. So selection is based on picking particular captures, not REs.) > > So I see no reason to use REs in the Configure. [CNG] I agree. I don't see the need for labels either. > > The downside of REs, if there is one, is that they may be more complex > to implement in some contexts. (Though there are RE libraries for most > environments.) They might also be slightly more costly in computation, > but probably not enough to matter. > > We would of course need to choose a precise definition of RE syntax. [CNG] Yes > >> I'm not against the label concept I think it just needs to be considered >> against some examples. >> I think the other thing to consider is the multiple use case. If you >> were to take 12.3.3 and wanted to use the labels for all the VCs in MCCs >> then you end up with: >> >> VC1 >> VC2 >> VC3 >> VC4(label=1,4) >> VC5(label=2,4) >> VC6(label=3,4) >> VC7(label=1,4) >> VC8(label=2,4) >> VC9(label=3,4) >> VC10(label=1,4) >> VC11(label=2,4) >> VC12(label=3,4) >> VC13(label=1,4) >> VC14(label=2,4) >> VC15(label=3,4) > > When using labels, it would be easier to follow if the labels had some > significance. E.g. labels like "left", "center", "right". [CNG] Easier to follow for who? In terms of a consumer the labels are really just related to the syntax so probably wouldn't be seen by a person. I think in this case any random label would be sufficient. If we want spatial significance better to use spatial parameters. > >> A further issue is would label also apply to MCCs and CSEs? i.e. in >> tables 23 and 24 of the framework we use the same IDs in the CSE and >> MCC13. There would be a saving also if we could use "label" for both >> these instances. > > With either labels or REs, it does seem to make sense to allow their > use in both MCCs and CSEs. > > Thanks, > Paul > >> Regards, Christian >> >> On 22/01/2014 12:03 AM, Duckworth, Mark wrote: >>> Hello Christian, >>> Regarding the size of messages, I think in general the label idea will >>> reduce the size. Take Capture Scene #8 from the framework section >>> 12.3.3 as an example. Let's count the number of "tags" (or elements, >>> or attributes, or whatever you want to call them) we need to indicate >>> the associations between MCCs and other captures. >>> >>> MCC4 through MCC12, each referring to 12 individual captures. That is >>> 9 x 12 = 108 "tags". >>> >>> With the labeling mechanism, each of the 12 individual captures has >>> just one MCC grouping label, and they can all be the same value. That >>> is 12 "tags". Plus each MCC has just one grouping label, again the >>> same value, so that is 9 more tags. Total of just 21 "tags" vs. 108 >>> "tags". So that is a big savings using the labeling mechanism. >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>>> Sent: Monday, January 20, 2014 5:41 PM >>>> To: Paul Kyzivat; Duckworth, Mark; clue@ietf.org >>>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in >>>> an MCC - >>>> allow wildcard? >>>> >>>> I think before going for the label approach I think it would be worth >>>> to go >>>> through some examples and compare the size of the messages, i.e. >>>> comparing using the CaptureIDs vs Labels. Actually I think we need >>>> some >>>> more examples in general to understand the savings for wildcarding. >>>> If you >>>> have to specify an attribute with possibly several labels on each >>>> Capture then >>>> we might not be saving much (if anything) for the complexity. >>>> >>>> Also if we mix captures and label then I assume that we have to >>>> define the >>>> name space for each to ensure they didn't overlap? Currently >>>> captureIDs >>>> could be anything. >>>> >>>> With respect to putting meaning into the CaptureIDs is it really a >>>> big change >>>> for captureIDs to have some meaning within the session? Our >>>> convention in >>>> the framework of ACx, VCx, etc seems to be working quite well. I'm >>>> not sure >>>> why you'd want the CaptureID to be globally unique like a GUID? That >>>> seems >>>> like overkill. If people are assuming that CaptureIDs are globally >>>> unique >>>> across a MCU or network then I think we need to discuss that because >>>> I not >>>> sure everyone has the same view. >>>> >>>> Regards, Christian >>>> >>>> On 21/01/2014 9:15 AM, Paul Kyzivat wrote: >>>>> Hmm. I now realize I didn't say what I meant. What I meant was: >>>>> >>>>> My thought was that the the advertiser could specify *any* of: >>>>> >>>>> - MCC(capture1, capture2, ...) >>>>> - MCC(label1) >>>>> - MCC(label1, label2, ...) >>>>> - MCC(capture1, label1, ...) >>>>> >>>>> While the consumer could return either of: >>>>> >>>>> - MCC() >>>>> - MCC(capture1, capture2, ...) >>>>> >>>>> Sorry, >>>>> Paul >>>>> >>>>> >>>>> On 1/20/14 4:46 PM, Duckworth, Mark wrote: >>>>>> Paul and Christian, >>>>>> >>>>>> I was thinking much the same as Paul's approach 2. But maybe the >>>>>> configure message could be limited to something like this?: >>>>>> - MCC() >>>>>> - MCC(capture1, capture2,...) >>>>>> >>>>>> In the configure message, I'm not sure there is an advantage to >>>>>> specifying MCC subsets by label rather than always using capture ID. >>>>>> >>>>>> I always thought of the capture IDs as just a unique identifier, >>>>>> with >>>>>> no intrinsic meaning, like GUIDs. That's why specifying groups of >>>>>> them with ranges (VC1 through VC4) or regular expressions doesn't >>>>>> make sense to me. Putting more meaning into the identifiers seems >>>>>> like a big change to me. >>>>>> >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>>> Sent: Monday, January 20, 2014 1:15 PM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in >>>>>>> an MCC - allow wildcard? >>>>>>> >>>>>>> On 1/19/14 9:55 PM, Christian Groves wrote: >>>>>>>> I'd like some more explanation of the concept before agreeing. >>>>>>>> >>>>>>>> The reason why I went with CaptureIDs for the MCC and the >>>>>>>> individual captures was to prevent yet another namespace in CLUE. >>>>>>>> It also worked in with the fact that the Consumer currently only >>>>>>>> returns CaptureIDs and EncodingIDs. Are we now saying that an >>>>>>>> Advertiser sends >>>>>>>> MCC1(label1) and if a Consumer wants a subset it returns >>>>>>>> MCC(Capture1, Capture2, Capture3, etc?). I particularly avoided >>>>>>>> the >>>>>>>> use of attributes for this because CLUE Configures don't reference >>>>>>>> attributes. >>>>>>> My thought was that the the consumer could return: >>>>>>> >>>>>>> - MCC() >>>>>>> - MCC(capture1, capture2, ...) >>>>>>> - MCC(label1) >>>>>>> - MCC(label1, label2, ...) >>>>>>> - MCC(capture1, label1, ...) >>>>>>> >>>>>>>> Why couldn't CLUE simply have pattern matching based on regular >>>>>>>> expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.). >>>>>>> That is a possibility. I question whether it is simpler. I guess it >>>>>>> does make advertisements smaller. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> Christian >>>>>>>> >>>>>>>> >>>>>>>> On 19/01/2014 4:20 AM, Paul Kyzivat wrote: >>>>>>>>> On 1/17/14 6:12 PM, Duckworth, Mark wrote: >>>>>>>>>> We discussed this topic in the Jan 14 design team meeting. The >>>>>>>>>> group had interest in the concept, but not my specific proposal. >>>>>>>>>> Jonathan had an interesting idea, which I think better serves >>>>>>>>>> the >>>>>>> purpose. >>>>>>>>>> Instead of the MCC referring specifically to other media >>>>>>>>>> captures >>>>>>>>>> that can be contained within the MCC, the MCC can refer to zero >>>>>>>>>> or more "MCC grouping labels". Any other media capture can >>>>>>>>>> include an attribute (zero or more) with a particular MCC >>>>>>>>>> grouping label. The meaning is that any MC that has the same >>>>>>>>>> grouping label that is reference by an MCC can be included in >>>>>>>>>> that >>>> MCC. >>>>>>>>>> I think this doesn't change at all the meaning of MCC, but it >>>>>>>>>> will affect the syntax of how we describe it in the data model >>>>>>>>>> for CLUE messages. >>>>>>>>>> >>>>>>>>>> If the group agrees with this concept, I can propose specific >>>>>>>>>> changes to the framework. >>>>>>>>> This WFM, conceptually. >>>>>>>>> There are details to be worked out for this to be practical and >>>>>>>>> convenient. Those details will presumably be in the data model. >>>>>>>>> >>>>>>>>> Specifically, in the declaration of the MCC, there must be some >>>>>>>>> syntax for the reference. Two approaches come to mind: >>>>>>>>> >>>>>>>>> 1) the new labels share a single namespace with capture ids in >>>>>>>>> the >>>>>>>>> advertisement. The MCC declaration has an element that is used to >>>>>>>>> reference these IDs, of either kind. You can tell which kind by >>>>>>>>> resolving the reference. >>>>>>>>> >>>>>>>>> 2) the new labels have a distinct namespace from capture ids. The >>>>>>>>> MCC declaration allows two different kinds of elements, one to >>>>>>>>> reference capture ids, and another to reference these new labels. >>>>>>>>> >>>>>>>>> I'm inclined to prefer (2) - it seems less kludgy, and is >>>>>>>>> probably >>>>>>>>> equally concise. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Mark >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>> Duckworth, Mark >>>>>>>>>>> Sent: Friday, January 10, 2014 3:47 PM >>>>>>>>>>> To: Paul Kyzivat; clue@ietf.org >>>>>>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow >>>>>>>>>>> wildcard? >>>>>>>>>>> >>>>>>>>>>> Paul, >>>>>>>>>>> >>>>>>>>>>> Yes, I think the wildcard is just a syntax shortcut. >>>>>>>>>>> One other impact that I was thinking of is if we decide to have >>>>>>>>>>> partial updates of advertisements then it removes the need to >>>>>>>>>>> re-advertise any MCC(*) captures when other captures change. >>>>>>>>>>> Without wildcard, any other addition or removal of a >>>>>>>>>>> contributing capture means also re-advertising every MCC with a >>>>>>>>>>> new list of contributors. >>>>>>>>>>> I think the wildcard fits very nicely with the switching >>>>>>>>>>> scenario option (2) from the other discussion thread. >>>>>>>>>>> >>>>>>>>>>> Mark >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>>>>>>>>> Kyzivat >>>>>>>>>>>> Sent: Friday, January 10, 2014 1:24 PM >>>>>>>>>>>> To: clue@ietf.org >>>>>>>>>>>> Subject: Re: [clue] Advertising what is in an MCC - allow >>>>>>>>>>>> wildcard? >>>>>>>>>>>> >>>>>>>>>>>> On 1/9/14 5:11 PM, Duckworth, Mark wrote: >>>>>>>>>>>>> In an advertisement, the provider can indicate which other >>>>>>>>>>>>> captures are referenced by an MCC, for example: >>>>>>>>>>>>> >>>>>>>>>>>>> Individual captures advertised: VC1, VC2, VC3, VC4, VC5 >>>>>>>>>>>>> >>>>>>>>>>>>> MCC1(VC1, VC2) >>>>>>>>>>>>> >>>>>>>>>>>>> This means MCC1 can include VC1 and/or VC2, but not the >>>> others. >>>>>>>>>>>>> MCC2() >>>>>>>>>>>>> >>>>>>>>>>>>> Without any specific references, this means the provider is >>>>>>>>>>>>> not saying which other captures can be included in MCC2, and >>>>>>>>>>>>> the consumer cannot choose. >>>>>>>>>>>>> >>>>>>>>>>>>> I propose adding a wildcard: >>>>>>>>>>>>> >>>>>>>>>>>>> MCC3(*) >>>>>>>>>>>> IIUC you mean this to be strictly a syntactic shortcut, not >>>>>>>>>>>> adding any functionality that isn't present without it. >>>>>>>>>>>> >>>>>>>>>>>>> This means MCC3 can include any of the other captures VC1 >>>>>>>>>>>>> through VC5, and the consumer can choose. >>>>>>>>>>>> Do you intent this to mean all the captures in the >>>>>>>>>>>> advertisement, or all the captures in the same scene? >>>>>>>>>>>> >>>>>>>>>>>>> For some types of MCUs, that want to give consumers the >>>> choice >>>>>>>>>>>>> of which specific captures to receive in an MCC, this is >>>>>>>>>>>>> useful for large advertisements with many media captures. >>>>>>>>>>>> Perhaps. But I have my doubts that this would be of common use >>>>>>>>>>>> in >>>>>>>>>>> practice. >>>>>>>>>>>> So it becomes a question of whether the added implementation >>>>>>>>>>>> burden of supporting this optimization is justified for the >>>>>>>>>>>> number of cases when it would be of use. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Paul >>>>>>>>>>>> >>>>>>>>>>>>> When endpoints join or leave a conference, causing the >>>>>>>>>>>>> advertisement to change to add or remove scenes and captures, >>>>>>>>>>>>> the part of the advertisement with MCCs wouldn't have to >>>>>>>>>>>>> change at all. >>>>>>>>>>>>> >>>>>>>>>>>>> Related text from framework-13: >>>>>>>>>>>>> >>>>>>>>>>>>> From 7.2: "The MCC may contain a reference to the Single >>>>>>>>>>>>> Media Captures... (or) A MCC MAY contain no references to >>>>>>>>>>>>> other Captures to indicate that the MCC contains content from >>>>>>>>>>>>> multiple sources but no information regarding those >>>>>>>>>>>>> sources is >>>> given." >>>>>>>>>>>>> And in section 10 "If the MCC in the advertisement does not >>>>>>>>>>>>> reference any individual captures, then the Consumer cannot >>>>>>>>>>>>> choose what is included in the MCC" >>>>>>>>>>>>> >>>>>>>>>>>>> I propose adding text: >>>>>>>>>>>>> >>>>>>>>>>>>> The MCC may contain a wildcard reference, meaning it can >>>>>>>>>>>>> refer >>>>>>>>>>>>> to any of the other captures in the advertisement. The >>>>>>>>>>>>> consumer, in a configure message, may choose which of the >>>>>>>>>>>>> other media captures it wishes to receive in the MCC. >>>>>>>>>>>>> >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>> >>> >> >> > > From pkyzivat@alum.mit.edu Thu Jan 23 07: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 7348E1A001B for ; Thu, 23 Jan 2014 07:26: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 wImruPyLmcoW for ; Thu, 23 Jan 2014 07:26:28 -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 755A01A0014 for ; Thu, 23 Jan 2014 07:26:28 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta06.westchester.pa.mail.comcast.net with comcast id HRLY1n0050QuhwU56TSTj3; Thu, 23 Jan 2014 15:26:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id HTST1n00B3ZTu2S3NTSTDX; Thu, 23 Jan 2014 15:26:27 +0000 Message-ID: <52E134A3.8010609@alum.mit.edu> Date: Thu, 23 Jan 2014 10:26:27 -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: Christian Groves , "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@CRPMBOXPRD07.polycom.com> <52DF0AE9.1040509@nteczone.com> <52E00B42.5040409@alum.mit.edu> <52E073E1.4010305@nteczone.com> In-Reply-To: <52E073E1.4010305@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=1390490787; bh=QGeVI3tLTxRIuKPihZRgZFniOUt+EZ4pkukn3XD2ukY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BVAOo/YyU943mP360jqjecrdzCuGYYSE0suGyTWbGnN9HLoFfhM26eqI6xm/99DzS RL2Y7bRIWVv2tvfkFzc9eobFXO7RPQCA7EDlmmRjCbVvm/AVmeu9NYNseayfgdEhOf pxqE50y7eHRkvqJX+MXqmH0CmLhEkfK2eBUu2qnAZ2xjYgf8oNoNqWtcDdHPHquBhH uK2XcfxjSgFI6A/QuZKl69MKW3NqFCQwP9gaElNkK3Os9nEXFpgCorMJMuZW5RqMNU aWbZ1KLN+1alUZjShD268gJ+yL9dcQ3E0HSC335xqGh/gkf/Gs3TOQWzgasK0boMoI fY0rvd8dbguHg== Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 23 Jan 2014 15:26:29 -0000 On 1/22/14 8:44 PM, Christian Groves wrote: >> When using labels, it would be easier to follow if the labels had some >> significance. E.g. labels like "left", "center", "right". > [CNG] Easier to follow for who? In terms of a consumer the labels are > really just related to the syntax so probably wouldn't be seen by a > person. I think in this case any random label would be sufficient. If we > want spatial significance better to use spatial parameters. In use I agree it doesn't matter. But in the *examples* it is easier if they have some significance. Thanks, Paul From christer.holmberg@ericsson.com Thu Jan 23 19:30: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 39A441A0043 for ; Thu, 23 Jan 2014 19:30: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 A9lPcvsWLQLo for ; Thu, 23 Jan 2014 19:30:20 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0884B1A0014 for ; Thu, 23 Jan 2014 19:30:19 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-db-52e1de4998a1 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 68.63.23809.94ED1E25; Fri, 24 Jan 2014 04:30:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Fri, 24 Jan 2014 04:30:17 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Data channel impact on CLUE state Thread-Index: Ac8YtI5EhvCM4PHvSeKOP+gdfYn4/A== Date: Fri, 24 Jan 2014 03:30:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D11B7D5@ESESSMB209.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D11B7D5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvja7XvYdBBj8f8lrsP3WZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGWcXXGMtWGdT0dO2i62B8YJJFyMnh4SAicSVL9tYIWwxiQv3 1rN1MXJxCAkcYpS4MnsfE4SzhFHiyf2DQFUcHGwCFhLd/7RBGkQElCWObu5nA7GFBbQk9i05 zAgR15f4fWkHG0i5iICexLzbYGEWAVWJSaf2sYPYvAK+Et1vP4PZjEB7v59awwRiMwuIS3w4 eJ0Z4h4BiSV7zkPZohIvH/+DulNJYu3h7SwQ9fkSfZd/MELMFJQ4OfMJywRGoVlIRs1CUjYL SRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxciem5iZk15utIkRGPQHt/xW3cF455zI IUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAudpo9Tbym8P7+LYXmvIfk /z3aa7PS5YXHJasEFuOYEv4sjoxD4s2nTKa+uXTJR1nT6kn4irU7wt4FOilknzN+zb+1yojB Lca6i9k9pig89MgBnmneUa5VSmmTF1475635Om6j4Wvxhfnbyj4nffr3fqlL+LQ6/d0FYlyt x8+GnNKauu3DBUElluKMREMt5qLiRABtGtYhSAIAAA== Subject: [clue] Data channel impact on CLUE state 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, 24 Jan 2014 03:30:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D11B7D5ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One of the things, related to the data channel used for the CLUE protocol, = is what impact the data channel has on the CLUE session (if there is such t= hing) itself. I have identified the following cases: CASE #1: Data channel removed without signaling: If the data channel for some reason disappears without signaling, it does N= OT impact the CLUE session. Everything goes on as before, based on previous CLUE- and SDP exchanges. Obviously, the data channel should re-est= ablished asap. CASE #2: Data channel removed by setting port to zero: If the data channel is explicitly removed, by setting the port value is set= to zero, but the media m- lines are still non-zero, media can still be exc= hanged, but my suggestion is that any previously negotiated CLUE information (capture info= rmation, spatial information) etc is removed at that point. So, obviously t= his should not happen unless one really wants to stop using CLUE. CASE #3: Data channel removed on SCTP level: Same as for CASE #2: If someone explicitly rem= oves the data channel (the SCTP connection MAY still be kept for other purp= ose), it is an indication that the CLUE protocol is no more used, and any a= ssociated CLUE state is removed. CASE #4: Data channel set inactive: Same as for CASE #1: This use-case is probably= going to be rare, but there MAY e.g. be some transfer cases where it could= occur. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D11B7D5ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One of the things, related to t= he data channel used for the CLUE protocol, is what impact the data channel= has on the CLUE session (if there is such thing) itself.

 

I have identified the following= cases:

 

CASE #1: Data channel remove= d without signaling:

 

If= the data channel for some reason disappears without signaling, it does NOT= impact the CLUE session. Everything goes on as before, based on

pr= evious CLUE- and SDP exchanges. Obviously, the data channel should re-estab= lished asap.

 

CASE #2: Data channel remove= d by setting port to zero:

 

If= the data channel is explicitly removed, by setting the port value is set t= o zero, but the media m- lines are still non-zero, media can still be excha= nged, but my

su= ggestion is that any previously negotiated CLUE information (capture inform= ation, spatial information) etc is removed at that point. So, obviously thi= s should not happen

un= less one really wants to stop using CLUE.

 

CASE #3: Data channel remove= d on SCTP level:

 

     &= nbsp;           &nbs= p;           Same as for = CASE #2: If someone explicitly removes the data channel (the SCTP connectio= n MAY still be kept for other purpose), it is an indication that the CLUE p= rotocol is no more used, and any associated CLUE state is removed.

 

 

CASE #4: Data channel set in= active:

 

     &= nbsp;           &nbs= p;           Same as for = CASE #1: This use-case is probably going to be rare, but there MAY e.g. be = some transfer cases where it could occur.

 

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D11B7D5ESESSMB209erics_-- From christer.holmberg@ericsson.com Thu Jan 23 19:52: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 E983E1A025B for ; Thu, 23 Jan 2014 19:52:40 -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_15=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 XOs8xuMrZ5uQ for ; Thu, 23 Jan 2014 19:52:39 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 455BA1A025A for ; Thu, 23 Jan 2014 19:52:38 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-e3-52e1e384b3a3 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 75.72.10875.483E1E25; Fri, 24 Jan 2014 04:52:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Fri, 24 Jan 2014 04:52:36 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Don't use CLUE data channel terminology Thread-Index: Ac8XUS8NTKb7QlBZQx6Z1V6CPy51+wAAFgmAAAtk1IAAArAIwP//+5SA//2jP+A= Date: Fri, 24 Jan 2014 03:52:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D11B872@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D114D78@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D115483@ESESSMB209.ericsson.se> <52DFF36D.1060508@alum.mit.edu> In-Reply-To: <52DFF36D.1060508@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvjW7L44dBBo1L9Sz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj3ItupoJtFhV3zl1hamD8Y9bFyMkhIWAi cXj7fyYIW0ziwr31bF2MXBxCAocYJfq+fmWFcJYwSry9+AqoioODTcBCovufNkiDiICnxI6P U5hBbGEBa4nNE2eyQsRtJDYdOQVl+0lMWbySHcRmEVCVWLnrFlicV8BXYnrfAhaI+fuZJLpX XGUESXAK6Eh09X9kA7EZgS76fmoN2HXMAuISHw5eZ4a4VEBiyZ7zULaoxMvH/1ghbCWJtYe3 s4DcySygKbF+lz5Eq6LElO6H7BB7BSVOznzCMoFRdBaSqbMQOmYh6ZiFpGMBI8sqRvbcxMyc 9HLDTYzASDi45bfuDsZT50QOMUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gTFW0npl9wnpUMPbk5Zbetz8GbTZRyPJ4+SNFUVL+I+H+vUcP6DEfNa5vNd0f7LpQkHO8wWv 29Ruzv7+oz7ibO7F0xl9sjs63IuOmf6+ePXEXB/96vNHH2le3fY7O9gm99h2H1dtB0fliUwy iq6Nj8/eX3FQ+03OpoK9Gz6U2n+zn73c881U7zYlluKMREMt5qLiRAAhAKLzUgIAAA== Subject: Re: [clue] Don't use CLUE data channel terminology 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, 24 Jan 2014 03:52:41 -0000 SGksDQoNCj4gSSBkb24ndCBzZWUgd2h5IHdlIHNob3VsZCBiZSByZWZlcmVuY2luZyBydGN3ZWIg YXQgYWxsIHdoZW4gdGFsa2luZyBhYm91dCB0aGlzLiBXZSBhcmUgdXNpbmcgYSBjaGFubmVsIHRo YXQgaXMgZGVmaW5lZCBpbiB0cmFuc3BvcnQsIGFuZCBkZXNjcmliZWQgaW4gU0RQIGRlZmluZWQg aW4gbW11c2ljLg0KDQpJIGRvbid0IHRoaW5rIGl0J3Mgbm90IHRoYXQgZWFzeS4NCg0KWWVzLCB0 aGUgU0NUUCBjb25uZWN0aW9uIGlzIG5lZ290aWF0ZWQgdXNpbmcgU0RQLCBhbmQgdGhlIG9wZW5p bmcgb2YgU0NUUCBzdHJlYW1zIGlzIGFsc28gZG9uZSB1c2luZyBnZW5lcmljIG1lY2hhbmlzbXMu IEJVVCwgdGhlcmUgYXJlIHByb2NlZHVyZXMgYW5kIHNlbWFudGljcyBhc3NvY2lhdGVkIHdpdGgg dGhlIGRhdGEgY2hhbm5lbCBpdHNlbGYgdGhhdCBuZWVkcyB0byBiZSBzcGVjaWZpZWQuIFNvLCBl aXRoZXIgd2UgcmUtdXNlIChpZiBwb3NzaWJsZSkgd2hhdCBSVENXRUIgaGFzIGRvbmUsIG9yIHdl IG5lZWQgdG8gc3BlY2lmeSBpdCBvdXJzZWx2ZXMuDQoNCk9mIGNvdXJzZSwgd2UgY2FuIGFzayBS VENXRUIgdG8gbm90IHVzZSAicnRjd2ViIGRhdGEgY2hhbm5lbCB0ZXJtaW5vbG9neSIsIGJ1dCBz b21ldGhpbmcgbW9yZSBnZW5lcmljLCBpZiBDTFVFIGFsc28gd2FudHMgdG8gdXNlIGl0LiANCg0K QnV0LCBsZXQncyBub3QgZm9jdXMgb24gdGhlIG5hbWUgZm9yIHRoZSBtb21lbnQgLSBsZXQncyBz ZWUgaWYgdGhlaXIgc29sdXRpb24gVEVDSE5JQ0FMTFkgZnVsZmlsbHMgdGhlIENMVUUgbmVlZHMu DQoNCj4gV2UgZG8gaGFwcGVuIHRvIGJlIHVzaW5nIGEgbWVjaGFuaXNtIHRoYXQgaGFzIGEgbG90 IGluIGNvbW1vbiB3aXRoIHRoZSBydGN3ZWIgZGF0YSBjaGFubmVsLiBUaGF0IGlzIGhlbHBmdWwg Ym90aCBiZWNhdXNlIHRoZXkgYXJlIGRvaW5nIGEgbG90IG9mIHRoZSBkZWZpbml0aW9uIHdvcmsg Zm9yIHVzLCBhbmQgYmVjYXVzZSB3ZSBob3BlIHRoaXMgd2lsbCBmYWNpbGl0YXRlIG1ha2luZyB3 ZWJydGMgY2xpZW50cyBmb3IgY2x1ZS4gQnV0IG11Y2ggb2YgdGhlIHVzYWdlIHdpbGwgYmUgd2l0 aG91dCB3ZWJydGMuDQoNCkNvcnJlY3QuIFNvLCBpZiB3ZSBkb24ndCB3YW50IHRvIHJlLXVzZSB3 aGF0IHRoZXkgaGF2ZSBkb25lLCB0aGVyZSBzaG91bGQgYmUgYSBnb29kIHRlY2huaWNhbCByZWFz b24gZm9yIHRoYXQuIA0KDQpJIEhBVkUgaWRlbnRpZmllZCBzb21lIGlzc3Vlcywgd2hpY2ggc2Vl bXMgdG8gbGltaXQgdGhlIHVzYWdlIHRvIHdlYnJ0YyAob3IsIGV2ZW4gdG8gSmF2YVNjcmlwdCB1 c2FnZSBvZiB3ZWJydGMpLCBidXQgSSBhbSBoYXZpbmcgc29tZSBvZmYtbGluZSBjbGFyaWZpY2F0 aW9uIGRpc2N1c3Npb25zIChpZiBteSBpc3N1ZXMgYXJlIHZhbGlkLCBJJ2xsIG5hdHVyYWxseSBi cmluZyB0aGVtIHVwIG9uIHRoZSBsaXN0KSB3aXRoIHRoZSBhdXRob3JzIHJlZ2FyZGluZyB0aGF0 LiANCg0KPk5vdGUgdGhhdCB4eHggY3VycmVudGx5IHVzZXMgYT13ZWJydGMtRGF0YUNoYW5uZWwg YW5kIGE9d2Rjc2EsIGJ1dCBJIGFscmVhZHkgY29tbWVudGVkIHRvIFJpY2hhcmQgYWJvdXQgdGhh dCwgYW5kIGhlIGFncmVlZCB0aGF0IHRob3NlIG5hbWVzIHNob3VsZCBiZSBjaGFuZ2VkLiAoVG8g YT1EYXRhQ2hhbm5lbCBhbmQgYT1jc2EuKQ0KDQpJIHRoaW5rIHdlIHNoYWxsIGRvIHRoaW5ncyBz dGVwLWJ5LXN0ZXAsIHdoaWNoIG1lYW5zIHdlIHNoYWxsIGZpcnN0IGRldGVybWluZSB3aGV0aGVy IHdlIGNhbiB1c2UgdGhlICJiYXNlIiBzdHVmZiwgb3Igd2hldGhlciBSaWNoYXJkJ3Mgc3VnZ2Vz dGVkIG1lY2hhbmlzbSBpcyBuZWVkZWQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoN Ck9uIDEvMjIvMTQgMTA6NTEgQU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPiBIaSwNCj4N Cj4gVGhlIHJ0Y3dlYiBkYXRhIGNoYW5uZWwgaXMgbm90IHJ0Y3dlYiBhcHBsaWNhdGlvbiBzcGVj aWZpYyAtIHRoZXkganVzdCANCj4gY2FsbCBpdCB0aGF0IHJ0Y3dlYiBkYXRhIGNoYW5uZWwgKHdl bGwsIHRoZXkgZG8gbWFrZSBzb21lIGFzc3VtcHRpb25zLCANCj4gd2hpY2ggYXJlIHJ0Y3dlYjpp c2gsIGJ1dCBJIGhhdmUgY29tbWVudGVkIG9uIHRoYXQpLg0KPg0KPiBXaGVuIHlvdSB1c2UgdGhl IGRhdGEgY2hhbm5lbCwgeW91IGRvIG5lZWQgdG8gaW5kaWNhdGUgdGhlIHByb3RvY29sIA0KPiBy dW5uaW5nIG9uIHRvcCBvZiBpdCAoaW4gb3VyIGNhc2UsIHRoZSBjbHVlIHByb3RvY29sKS4gUmlj aGFyZCdzIA0KPiBwcm9wb3NhbCBhbGxvd3MgeW91IHRvIGRvIGl0IGFscmVhZHkgaW4gU0RQLCB3 aGlsZSB0aGV5IGRvIGl0IGluc2lkZSANCj4gdGhlIGRhdGEgY2hhbm5lbCAob25jZSBlc3RhYmxp c2hlZCkuIEJ1dCwgSSBkb24ndCB0aGluayB0aGVyZSBhcmUgYW55IA0KPiBkaWZmZXJlbmNlcyBp biB0aGUgZGF0YSBjaGFubmVsIGl0c2VsZiwgYW5kIGhvdyBpdCdzIHVzZWQuDQo+DQo+IFJlZ2Fy ZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+IFNlbnQgZnJvbSBXaW5kb3dzIE1haWwNCj4NCj4gKkZy b206KiBNYXJ5IEJhcm5lcyA8bWFpbHRvOm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPg0KPiAq U2VudDoqIOKAjldlZG5lc2RheeKAjiwg4oCOSmFudWFyeeKAjiDigI4yMuKAjiwg4oCOMjAxNCDi gI414oCOOuKAjjM04oCOIOKAjlBNDQo+ICpUbzoqIEhhbnMtQ2hyaXN0ZXIgSG9sbWJlcmcgPG1h aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+ICpDYzoqIGNsdWVAaWV0Zi5v cmcgPG1haWx0bzpjbHVlQGlldGYub3JnPiwgDQo+IHJpY2hhcmQuZWp6YWtAYWxjYXRlbC1sdWNl bnQuY29tIA0KPiA8bWFpbHRvOnJpY2hhcmQuZWp6YWtAYWxjYXRlbC1sdWNlbnQuY29tPg0KPg0K PiBJIGRpZCBub3QgdW5kZXJzdGFuZCB0aGF0IHdlIHdlcmUgcmV1c2luZyB0aGUgUlRDV0VCIGRh dGEgY2hhbm5lbC4gIEkgDQo+IHRoaW5rIHdlIG5lZWQgdG8gdGhpbmsgbW9yZSBpbiB0ZXJtcyBv ZiB0aGUgd29yayB0aGF0IFJpY2hhcmQgRWp6YWsgDQo+IHByb3Bvc2VkIGZvciBkZWZpbmluZyBh IG1vcmUgZ2VuZXJpYyBtb2RlbCBmb3Igc2V0dGluZyB1cCBhbiANCj4gImFwcGxpY2F0aW9uIiBz cGVjaWZpYyBTQ1RQL0RUTFMvVURQIGNoYW5uZWwgdGhhdCB3YXMgZGlzcGF0Y2hlZCB0byANCj4g TU1VU0lDIFdHIGF0IElFVEYtODg6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv ODgvbWludXRlcy9taW51dGVzLTg4LWRpc3BhdGNoDQo+DQo+IFdoaWxlIHRoZSBvcmlnaW5hbCBk cmFmdCB3YXMgZm9jdXNlZCBvbiBXZWJSVEMsIHRoZSB3b3JrIHRoYXQgd2FzIA0KPiBhZ3JlZWQg dG8gbW92ZSBmb3J3YXJkIHdhcyB0aGUgZ2VuZXJpYyBTRFAgcHJvY2VkdXJlcywgd2hpY2ggSSB0 aGluayANCj4gaXMgd2hhdCBDTFVFIHdvdWxkIHdhbnQgdG8gdXNlLg0KPg0KPiBJJ20gY2MnaW5n IFJpY2hhcmQgYXMgSSBkb24ndCB0aGluayBoZSdzIG9uIHRoZSBsaXN0IGFuZCBpdCB3b3VsZCBi ZSANCj4gZ29vZCBpZiB3ZSBjb3VsZCB1bmRlcnN0YW5kIHRoZSBzdGF0dXMgb2YgdGhhdCB3b3Jr Lg0KPg0KPiBNYXJ5Lg0KPg0KPg0KPiBPbiBXZWQsIEphbiAyMiwgMjAxNCBhdCAzOjA4IEFNLCBD aHJpc3RlciBIb2xtYmVyZyANCj4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSANCj4g PG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pg0KPiB3cm90ZToNCj4NCj4g ICAgIEFuZCwganVzdCB0byBjbGFyaWZ5OiBteSBzdGF0ZW1lbnQgYmVsb3cgaXMgYmFzZWQgb24g dGhlIGFzc3VtcHRpb24NCj4gICAgIHRoYXQgd2UgYXJlIGdvaW5nIHRvIHJlLXVzZSB0aGUgcnRj d2ViIGRhdGEgY2hhbm5lbCBpbiBDTFVFLl9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICAq TMOkaGV0dMOkasOkOipjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnDQo+ICAgICA8 bWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZz5dICpQdW9sZXN0YSAqQ2hyaXN0ZXIgSG9sbWJl cmcNCj4gICAgICpMw6RoZXRldHR5OiogMjIuIHRhbW1pa3V1dGEgMjAxNCAxMTowNw0KPiAgICAg KlZhc3RhYW5vdHRhamE6KiBjbHVlQGlldGYub3JnIDxtYWlsdG86Y2x1ZUBpZXRmLm9yZz4NCj4g ICAgICpBaWhlOiogW2NsdWVdIERvbid0IHVzZSBDTFVFIGRhdGEgY2hhbm5lbCB0ZXJtaW5vbG9n eV9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICBIaSxfX19fDQo+DQo+ICAgICBfXyBfXw0K Pg0KPiAgICAgSSBhbSBjdXJyZW50bHkgd29ya2luZyBvbiBteSBtYXRlcmlhbCBmb3IgdGhlIOKA nENMVUUgZGF0YSBjaGFubmVs4oCdDQo+ICAgICBwcmVzZW50YXRpb24uX19fXw0KPg0KPiAgICAg X18gX18NCj4NCj4gICAgIFRoZSBmaXJzdCB0aGluZyBJ4oCZZCBsaWtlIHRvIHN1Z2dlc3QgYWxy ZWFkeSBhdCB0aGlzIHBvaW50OiBQbGVhc2UNCj4gICAgIGxldCB1cyBub3QgdXNlIOKAnENMVUUg ZGF0YSBjaGFubmVs4oCdIHRlcm1pbm9sb2d5LiBJdCBtYWtlcyB0aGluZw0KPiAgICAgY29uZnVz aW5nLl9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICBNeSBzdWdnZXN0aW9uIGlzIHRvIHRh bGsgYWJvdXQg4oCccnRjd2ViIGRhdGEgY2hhbm5lbCBmb3IgQ0xVReKAnSwNCj4gICAgIOKAnHJ0 Y3dlYiBkYXRhIGNoYW5uZWwgZm9yIENMVUUgdXNhZ2XigJ0sIG9yIHNvbWV0aGluZyBzaW1pbGFy 4oCmX19fXw0KPg0KPiAgICAgX18gX18NCj4NCj4gICAgIFJlZ2FyZHMsX19fXw0KPg0KPiAgICAg X18gX18NCj4NCj4gICAgIENocmlzdGVyX19fXw0KPg0KPg0KPiAgICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgIGNsdWUgbWFpbGluZyBsaXN0 DQo+ICAgICBjbHVlQGlldGYub3JnIDxtYWlsdG86Y2x1ZUBpZXRmLm9yZz4NCj4gICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPg0KPg0KPg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjbHVlIG1haWxp bmcgbGlzdA0KPiBjbHVlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2x1ZQ0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KY2x1ZSBtYWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K From christer.holmberg@ericsson.com Thu Jan 23 19:58: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 127891A02D4 for ; Thu, 23 Jan 2014 19:58:23 -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_15=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 jVvk3PA8H0qb for ; Thu, 23 Jan 2014 19:58:20 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 14F201A025B for ; Thu, 23 Jan 2014 19:58:19 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-11-52e1e4da347a Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 76.D2.10875.AD4E1E25; Fri, 24 Jan 2014 04:58:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Fri, 24 Jan 2014 04:58:17 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Don't use CLUE data channel terminology Thread-Index: Ac8XUS8NTKb7QlBZQx6Z1V6CPy51+wAAFgmAAAtk1IAAArAIwP//+5SA//2jP+D/+0GMgA== Date: Fri, 24 Jan 2014 03:58:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D11B88A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D114D78@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D115483@ESESSMB209.ericsson.se> <52DFF36D.1060508@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D11B872@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D11B872@ESESSMB209.ericsson.se> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje6tJw+DDKZdVbHYf+oys8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6Mjh8H2AuabCseNU1kbmDcYd3FyMkhIWAi sf3JfkYIW0ziwr31bF2MXBxCAocYJeZd2MEM4SxhlNi5cg1LFyMHB5uAhUT3P22QBhGBeon5 x26BNQsLWEtsnjiTFSJuI7HpyCkoO0xizvc57CA2i4CqRHNDNxOIzSvgK/FtYzfUsmZmiXUN d5hA5nMK+El09lSA1DACHfT91BqwemYBcYkPB68zQxwqILFkz3koW1Ti5eN/rBC2ksTaw9vB zmQW0JRYv0sfolVRYkr3Q3aItYISJ2c+YZnAKDoLydRZCB2zkHTMQtKxgJFlFSN7bmJmTnq5 4SZGYBwc3PJbdwfjqXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCY 0/uRe+f0Q99yO+z6vjk6zrS0mfnBcrdHVXunwfTD8lGOUgH8LE/WL6p3+JQacmRF9wOTvw+u F71KnDM7VDSzqLjxm8SUa422x37k7ZPKm1VfumhZbpXpNe0N0+Pzbgsandtw9btV8tl/BsyC Ya65M/W3nFhYdOsK59Uq+cM7772eYLn5qugfJZbijERDLeai4kQAqMhEflECAAA= Subject: Re: [clue] Don't use CLUE data channel terminology 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, 24 Jan 2014 03:58:23 -0000 SSBkb24ndCB0aGluayBpdCdzIHRoYXQgZWFzeSwgdGhhdCBpcyA6KQ0KDQotLS0tLUFsa3VwZXLD pGluZW4gdmllc3RpLS0tLS0NCkzDpGhldHTDpGrDpDogY2x1ZSBbbWFpbHRvOmNsdWUtYm91bmNl c0BpZXRmLm9yZ10gUHVvbGVzdGEgQ2hyaXN0ZXIgSG9sbWJlcmcNCkzDpGhldGV0dHk6IDI0LiB0 YW1taWt1dXRhIDIwMTQgNTo1Mw0KVmFzdGFhbm90dGFqYTogUGF1bCBLeXppdmF0OyBjbHVlQGll dGYub3JnDQpBaWhlOiBSZTogW2NsdWVdIERvbid0IHVzZSBDTFVFIGRhdGEgY2hhbm5lbCB0ZXJt aW5vbG9neQ0KDQpIaSwNCg0KPiBJIGRvbid0IHNlZSB3aHkgd2Ugc2hvdWxkIGJlIHJlZmVyZW5j aW5nIHJ0Y3dlYiBhdCBhbGwgd2hlbiB0YWxraW5nIGFib3V0IHRoaXMuIFdlIGFyZSB1c2luZyBh IGNoYW5uZWwgdGhhdCBpcyBkZWZpbmVkIGluIHRyYW5zcG9ydCwgYW5kIGRlc2NyaWJlZCBpbiBT RFAgZGVmaW5lZCBpbiBtbXVzaWMuDQoNCkkgZG9uJ3QgdGhpbmsgaXQncyBub3QgdGhhdCBlYXN5 Lg0KDQpZZXMsIHRoZSBTQ1RQIGNvbm5lY3Rpb24gaXMgbmVnb3RpYXRlZCB1c2luZyBTRFAsIGFu ZCB0aGUgb3BlbmluZyBvZiBTQ1RQIHN0cmVhbXMgaXMgYWxzbyBkb25lIHVzaW5nIGdlbmVyaWMg bWVjaGFuaXNtcy4gQlVULCB0aGVyZSBhcmUgcHJvY2VkdXJlcyBhbmQgc2VtYW50aWNzIGFzc29j aWF0ZWQgd2l0aCB0aGUgZGF0YSBjaGFubmVsIGl0c2VsZiB0aGF0IG5lZWRzIHRvIGJlIHNwZWNp ZmllZC4gU28sIGVpdGhlciB3ZSByZS11c2UgKGlmIHBvc3NpYmxlKSB3aGF0IFJUQ1dFQiBoYXMg ZG9uZSwgb3Igd2UgbmVlZCB0byBzcGVjaWZ5IGl0IG91cnNlbHZlcy4NCg0KT2YgY291cnNlLCB3 ZSBjYW4gYXNrIFJUQ1dFQiB0byBub3QgdXNlICJydGN3ZWIgZGF0YSBjaGFubmVsIHRlcm1pbm9s b2d5IiwgYnV0IHNvbWV0aGluZyBtb3JlIGdlbmVyaWMsIGlmIENMVUUgYWxzbyB3YW50cyB0byB1 c2UgaXQuIA0KDQpCdXQsIGxldCdzIG5vdCBmb2N1cyBvbiB0aGUgbmFtZSBmb3IgdGhlIG1vbWVu dCAtIGxldCdzIHNlZSBpZiB0aGVpciBzb2x1dGlvbiBURUNITklDQUxMWSBmdWxmaWxscyB0aGUg Q0xVRSBuZWVkcy4NCg0KPiBXZSBkbyBoYXBwZW4gdG8gYmUgdXNpbmcgYSBtZWNoYW5pc20gdGhh dCBoYXMgYSBsb3QgaW4gY29tbW9uIHdpdGggdGhlIHJ0Y3dlYiBkYXRhIGNoYW5uZWwuIFRoYXQg aXMgaGVscGZ1bCBib3RoIGJlY2F1c2UgdGhleSBhcmUgZG9pbmcgYSBsb3Qgb2YgdGhlIGRlZmlu aXRpb24gd29yayBmb3IgdXMsIGFuZCBiZWNhdXNlIHdlIGhvcGUgdGhpcyB3aWxsIGZhY2lsaXRh dGUgbWFraW5nIHdlYnJ0YyBjbGllbnRzIGZvciBjbHVlLiBCdXQgbXVjaCBvZiB0aGUgdXNhZ2Ug d2lsbCBiZSB3aXRob3V0IHdlYnJ0Yy4NCg0KQ29ycmVjdC4gU28sIGlmIHdlIGRvbid0IHdhbnQg dG8gcmUtdXNlIHdoYXQgdGhleSBoYXZlIGRvbmUsIHRoZXJlIHNob3VsZCBiZSBhIGdvb2QgdGVj aG5pY2FsIHJlYXNvbiBmb3IgdGhhdC4gDQoNCkkgSEFWRSBpZGVudGlmaWVkIHNvbWUgaXNzdWVz LCB3aGljaCBzZWVtcyB0byBsaW1pdCB0aGUgdXNhZ2UgdG8gd2VicnRjIChvciwgZXZlbiB0byBK YXZhU2NyaXB0IHVzYWdlIG9mIHdlYnJ0YyksIGJ1dCBJIGFtIGhhdmluZyBzb21lIG9mZi1saW5l IGNsYXJpZmljYXRpb24gZGlzY3Vzc2lvbnMgKGlmIG15IGlzc3VlcyBhcmUgdmFsaWQsIEknbGwg bmF0dXJhbGx5IGJyaW5nIHRoZW0gdXAgb24gdGhlIGxpc3QpIHdpdGggdGhlIGF1dGhvcnMgcmVn YXJkaW5nIHRoYXQuIA0KDQo+Tm90ZSB0aGF0IHh4eCBjdXJyZW50bHkgdXNlcyBhPXdlYnJ0Yy1E YXRhQ2hhbm5lbCBhbmQgYT13ZGNzYSwgYnV0IEkgDQo+YWxyZWFkeSBjb21tZW50ZWQgdG8gUmlj aGFyZCBhYm91dCB0aGF0LCBhbmQgaGUgYWdyZWVkIHRoYXQgdGhvc2UgbmFtZXMgDQo+c2hvdWxk IGJlIGNoYW5nZWQuIChUbyBhPURhdGFDaGFubmVsIGFuZCBhPWNzYS4pDQoNCkkgdGhpbmsgd2Ug c2hhbGwgZG8gdGhpbmdzIHN0ZXAtYnktc3RlcCwgd2hpY2ggbWVhbnMgd2Ugc2hhbGwgZmlyc3Qg ZGV0ZXJtaW5lIHdoZXRoZXIgd2UgY2FuIHVzZSB0aGUgImJhc2UiIHN0dWZmLCBvciB3aGV0aGVy IFJpY2hhcmQncyBzdWdnZXN0ZWQgbWVjaGFuaXNtIGlzIG5lZWRlZC4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQoNCg0KT24gMS8yMi8xNCAxMDo1MSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcg d3JvdGU6DQo+IEhpLA0KPg0KPiBUaGUgcnRjd2ViIGRhdGEgY2hhbm5lbCBpcyBub3QgcnRjd2Vi IGFwcGxpY2F0aW9uIHNwZWNpZmljIC0gdGhleSBqdXN0IA0KPiBjYWxsIGl0IHRoYXQgcnRjd2Vi IGRhdGEgY2hhbm5lbCAod2VsbCwgdGhleSBkbyBtYWtlIHNvbWUgYXNzdW1wdGlvbnMsIA0KPiB3 aGljaCBhcmUgcnRjd2ViOmlzaCwgYnV0IEkgaGF2ZSBjb21tZW50ZWQgb24gdGhhdCkuDQo+DQo+ IFdoZW4geW91IHVzZSB0aGUgZGF0YSBjaGFubmVsLCB5b3UgZG8gbmVlZCB0byBpbmRpY2F0ZSB0 aGUgcHJvdG9jb2wgDQo+IHJ1bm5pbmcgb24gdG9wIG9mIGl0IChpbiBvdXIgY2FzZSwgdGhlIGNs dWUgcHJvdG9jb2wpLiBSaWNoYXJkJ3MgDQo+IHByb3Bvc2FsIGFsbG93cyB5b3UgdG8gZG8gaXQg YWxyZWFkeSBpbiBTRFAsIHdoaWxlIHRoZXkgZG8gaXQgaW5zaWRlIA0KPiB0aGUgZGF0YSBjaGFu bmVsIChvbmNlIGVzdGFibGlzaGVkKS4gQnV0LCBJIGRvbid0IHRoaW5rIHRoZXJlIGFyZSBhbnkg DQo+IGRpZmZlcmVuY2VzIGluIHRoZSBkYXRhIGNoYW5uZWwgaXRzZWxmLCBhbmQgaG93IGl0J3Mg dXNlZC4NCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4gU2VudCBmcm9tIFdpbmRv d3MgTWFpbA0KPg0KPiAqRnJvbToqIE1hcnkgQmFybmVzIDxtYWlsdG86bWFyeS5pZXRmLmJhcm5l c0BnbWFpbC5jb20+DQo+ICpTZW50Oiog4oCOV2VkbmVzZGF54oCOLCDigI5KYW51YXJ54oCOIOKA jjIy4oCOLCDigI4yMDE0IOKAjjXigI464oCOMzTigI4g4oCOUE0NCj4gKlRvOiogSGFucy1DaHJp c3RlciBIb2xtYmVyZyA8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4g KkNjOiogY2x1ZUBpZXRmLm9yZyA8bWFpbHRvOmNsdWVAaWV0Zi5vcmc+LCANCj4gcmljaGFyZC5l anpha0BhbGNhdGVsLWx1Y2VudC5jb20gDQo+IDxtYWlsdG86cmljaGFyZC5lanpha0BhbGNhdGVs LWx1Y2VudC5jb20+DQo+DQo+IEkgZGlkIG5vdCB1bmRlcnN0YW5kIHRoYXQgd2Ugd2VyZSByZXVz aW5nIHRoZSBSVENXRUIgZGF0YSBjaGFubmVsLiAgSSANCj4gdGhpbmsgd2UgbmVlZCB0byB0aGlu ayBtb3JlIGluIHRlcm1zIG9mIHRoZSB3b3JrIHRoYXQgUmljaGFyZCBFanphayANCj4gcHJvcG9z ZWQgZm9yIGRlZmluaW5nIGEgbW9yZSBnZW5lcmljIG1vZGVsIGZvciBzZXR0aW5nIHVwIGFuIA0K PiAiYXBwbGljYXRpb24iIHNwZWNpZmljIFNDVFAvRFRMUy9VRFAgY2hhbm5lbCB0aGF0IHdhcyBk aXNwYXRjaGVkIHRvIA0KPiBNTVVTSUMgV0cgYXQgSUVURi04ODoNCj4gaHR0cDovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy84OC9taW51dGVzL21pbnV0ZXMtODgtZGlzcGF0Y2gNCj4NCj4gV2hp bGUgdGhlIG9yaWdpbmFsIGRyYWZ0IHdhcyBmb2N1c2VkIG9uIFdlYlJUQywgdGhlIHdvcmsgdGhh dCB3YXMgDQo+IGFncmVlZCB0byBtb3ZlIGZvcndhcmQgd2FzIHRoZSBnZW5lcmljIFNEUCBwcm9j ZWR1cmVzLCB3aGljaCBJIHRoaW5rIA0KPiBpcyB3aGF0IENMVUUgd291bGQgd2FudCB0byB1c2Uu DQo+DQo+IEknbSBjYydpbmcgUmljaGFyZCBhcyBJIGRvbid0IHRoaW5rIGhlJ3Mgb24gdGhlIGxp c3QgYW5kIGl0IHdvdWxkIGJlIA0KPiBnb29kIGlmIHdlIGNvdWxkIHVuZGVyc3RhbmQgdGhlIHN0 YXR1cyBvZiB0aGF0IHdvcmsuDQo+DQo+IE1hcnkuDQo+DQo+DQo+IE9uIFdlZCwgSmFuIDIyLCAy MDE0IGF0IDM6MDggQU0sIENocmlzdGVyIEhvbG1iZXJnIA0KPiA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tIA0KPiA8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+ DQo+IHdyb3RlOg0KPg0KPiAgICAgQW5kLCBqdXN0IHRvIGNsYXJpZnk6IG15IHN0YXRlbWVudCBi ZWxvdyBpcyBiYXNlZCBvbiB0aGUgYXNzdW1wdGlvbg0KPiAgICAgdGhhdCB3ZSBhcmUgZ29pbmcg dG8gcmUtdXNlIHRoZSBydGN3ZWIgZGF0YSBjaGFubmVsIGluIENMVUUuX19fXw0KPg0KPiAgICAg X18gX18NCj4NCj4gICAgICpMw6RoZXR0w6Rqw6Q6KmNsdWUgW21haWx0bzpjbHVlLWJvdW5jZXNA aWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnPl0gKlB1b2xlc3Rh ICpDaHJpc3RlciBIb2xtYmVyZw0KPiAgICAgKkzDpGhldGV0dHk6KiAyMi4gdGFtbWlrdXV0YSAy MDE0IDExOjA3DQo+ICAgICAqVmFzdGFhbm90dGFqYToqIGNsdWVAaWV0Zi5vcmcgPG1haWx0bzpj bHVlQGlldGYub3JnPg0KPiAgICAgKkFpaGU6KiBbY2x1ZV0gRG9uJ3QgdXNlIENMVUUgZGF0YSBj aGFubmVsIHRlcm1pbm9sb2d5X19fXw0KPg0KPiAgICAgX18gX18NCj4NCj4gICAgIEhpLF9fX18N Cj4NCj4gICAgIF9fIF9fDQo+DQo+ICAgICBJIGFtIGN1cnJlbnRseSB3b3JraW5nIG9uIG15IG1h dGVyaWFsIGZvciB0aGUg4oCcQ0xVRSBkYXRhIGNoYW5uZWzigJ0NCj4gICAgIHByZXNlbnRhdGlv bi5fX19fDQo+DQo+ICAgICBfXyBfXw0KPg0KPiAgICAgVGhlIGZpcnN0IHRoaW5nIEnigJlkIGxp a2UgdG8gc3VnZ2VzdCBhbHJlYWR5IGF0IHRoaXMgcG9pbnQ6IFBsZWFzZQ0KPiAgICAgbGV0IHVz IG5vdCB1c2Ug4oCcQ0xVRSBkYXRhIGNoYW5uZWzigJ0gdGVybWlub2xvZ3kuIEl0IG1ha2VzIHRo aW5nDQo+ICAgICBjb25mdXNpbmcuX19fXw0KPg0KPiAgICAgX18gX18NCj4NCj4gICAgIE15IHN1 Z2dlc3Rpb24gaXMgdG8gdGFsayBhYm91dCDigJxydGN3ZWIgZGF0YSBjaGFubmVsIGZvciBDTFVF 4oCdLA0KPiAgICAg4oCccnRjd2ViIGRhdGEgY2hhbm5lbCBmb3IgQ0xVRSB1c2FnZeKAnSwgb3Ig c29tZXRoaW5nIHNpbWlsYXLigKZfX19fDQo+DQo+ICAgICBfXyBfXw0KPg0KPiAgICAgUmVnYXJk cyxfX19fDQo+DQo+ICAgICBfXyBfXw0KPg0KPiAgICAgQ2hyaXN0ZXJfX19fDQo+DQo+DQo+ICAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAg Y2x1ZSBtYWlsaW5nIGxpc3QNCj4gICAgIGNsdWVAaWV0Zi5vcmcgPG1haWx0bzpjbHVlQGlldGYu b3JnPg0KPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo+ DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IGNsdWUgbWFpbGluZyBsaXN0DQo+IGNsdWVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo+DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjbHVlIG1haWxpbmcgbGlzdA0KY2x1ZUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY2x1ZSBtYWlsaW5nIGxp c3QNCmNsdWVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2x1ZQ0K From Christian.Groves@nteczone.com Thu Jan 23 21:33: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 D97081A0138 for ; Thu, 23 Jan 2014 21:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=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 IAT2GE8gm656 for ; Thu, 23 Jan 2014 21:33:34 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7051A00FB for ; Thu, 23 Jan 2014 21:33:34 -0800 (PST) Received: from ppp118-209-127-213.lns20.mel4.internode.on.net ([118.209.127.213]:56269 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W6ZKr-0006VX-Rc for clue@ietf.org; Fri, 24 Jan 2014 16:29:45 +1100 Message-ID: <52E1FB27.3050707@nteczone.com> Date: Fri, 24 Jan 2014 16:33:27 +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: <7594FB04B1934943A5C02806D1A2204B1D11B7D5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D11B7D5@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] Data channel impact on CLUE state 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, 24 Jan 2014 05:33:36 -0000 Hello Christer, Please see below. Regards, Christian On 24/01/2014 2:30 PM, Christer Holmberg wrote: > > Hi, > > One of the things, related to the data channel used for the CLUE > protocol, is what impact the data channel has on the CLUE session (if > there is such thing) itself. > > I have identified the following cases: > > *CASE #1: Data channel removed without signaling:* > > If the data channel for some reason disappears without signaling, it > does NOT impact the CLUE session. Everything goes on as before, based on > > previous CLUE- and SDP exchanges. Obviously, the data channel should > re-established asap. > [CNG] Can you be a little more precise than "everything goes on as before"? I assume the media continues to flow. However I guess the endpoints aren't going to try to update the CLUE session by issuing new Adverts / Configs? If it doesn't establish after a timeout should the CLUE session be removed formally by SDP signalling? etc. > > *CASE #2: Data channel removed by setting port to zero:* > > If the data channel is explicitly removed, by setting the port value > is set to zero, but the media m- lines are still non-zero, media can > still be exchanged, but my > > suggestion is that any previously negotiated CLUE information (capture > information, spatial information) etc is removed at that point. So, > obviously this should not happen > > unless one really wants to stop using CLUE. > > *CASE #3: Data channel removed on SCTP level:* > > Same as for CASE #2: If someone explicitly removes the data channel > (the SCTP connection MAY still be kept for other purpose), it is an > indication that the CLUE protocol is no more used, and any associated > CLUE state is removed. > > *CASE #4: Data channel set inactive:* > > Same as for CASE #1: This use-case is probably going to be rare, but > there MAY e.g. be some transfer cases where it could occur. > [CNG] Do you mean setting a=inactive? I assume this means that if the endpoint tries to send a Advert/Config it won't actually be transmitted across the channel. Even if the media stays up. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Thu Jan 23 21:44: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 1FAF91A00FB for ; Thu, 23 Jan 2014 21:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=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 Dwg5Tmm9pHsH for ; Thu, 23 Jan 2014 21:44:24 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 60B891A0094 for ; Thu, 23 Jan 2014 21:44:24 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-6e-52e1fdb6aa3e Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id A4.35.04249.6BDF1E25; Fri, 24 Jan 2014 06:44:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Fri, 24 Jan 2014 06:44:21 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Data channel impact on CLUE state Thread-Index: Ac8YtI5EhvCM4PHvSeKOP+gdfYn4/AACN6GAAAI2ymA= Date: Fri, 24 Jan 2014 05:44:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D11B9DE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D11B7D5@ESESSMB209.ericsson.se> <52E1FB27.3050707@nteczone.com> In-Reply-To: <52E1FB27.3050707@nteczone.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje62vw+DDA7eVrf48r6RxWL/qcvM DkweS5b8ZPJYcX4mSwBTFJdNSmpOZllqkb5dAlfG7MVb2AuaRSqOTpzA3sD4jL+LkZNDQsBE 4vD8/0wQtpjEhXvr2boYuTiEBI4wSjx/0MMC4SxhlDhy9gJzFyMHB5uAhUT3P22QBhGBcImO bVcYQWxhAVOJidves0PEzSS+dV5hgrCtJO69ugpWwyKgKnFxwwGwMbwCvhIHl1uChIUE8iVW r2wHK+EU0JG4uOcsmM0IdM/3U2vAxjALiEt8OHidGeJOAYkle85D2aISLx//Y4WwlSQalzxh hajXkViw+xMbhK0tsWzha7B6XgFBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUjR3FqcVJu upHBJkZgLBzc8ttiB+PlvzaHGKU5WJTEeT++dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wJjmasV/dPLKzZ4THbV4o46azuubwfO503DaCgUppm7zHp2Zt393zJ+VEFc8e8v8afEOB1dG dNR/7HoS/+V1j359xeUPZY5Hbqc+5593lLGucMtPcYuaFDO5l9srMnh25hy/K3vWujxrekvU F/M/C+J6zh2b4cB6WezPxE13ima9tDr7v+iuDaMSS3FGoqEWc1FxIgBpDf+PUwIAAA== Subject: Re: [clue] Data channel impact on CLUE state 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, 24 Jan 2014 05:44:26 -0000 Hi, >> One of the things, related to the data channel used for the CLUE=20 >> protocol, is what impact the data channel has on the CLUE session (if=20 >> there is such thing) itself. >> >> I have identified the following cases: >> >> *CASE #1: Data channel removed without signaling:* >> >> If the data channel for some reason disappears without signaling, it=20 >> does NOT impact the CLUE session. Everything goes on as before, based=20 >> on >> >> previous CLUE- and SDP exchanges. Obviously, the data channel should=20 >> re-established asap. >> > [CNG] Can you be a little more precise than "everything goes on as before= "? I assume the media continues to flow. Correct. > However I guess the endpoints aren't going to try to update the CLUE sess= ion by issuing new Adverts / Configs? Correct. > If it doesn't establish after a timeout should the CLUE session be remove= d formally by SDP signalling? etc. That was going to be my next question, but: Yes :) >> *CASE #2: Data channel removed by setting port to zero:* >> >> If the data channel is explicitly removed, by setting the port value=20 >> is set to zero, but the media m- lines are still non-zero, media can=20 >> still be exchanged, but my >> >> suggestion is that any previously negotiated CLUE information (capture=20 >> information, spatial information) etc is removed at that point. So,=20 >> obviously this should not happen >> >> unless one really wants to stop using CLUE. >> >> *CASE #3: Data channel removed on SCTP level:* >> >> Same as for CASE #2: If someone explicitly removes the data channel=20 >> (the SCTP connection MAY still be kept for other purpose), it is an=20 >> indication that the CLUE protocol is no more used, and any associated=20 >> CLUE state is removed. >> >> *CASE #4: Data channel set inactive:* >> >> Same as for CASE #1: This use-case is probably going to be rare, but=20 >> there MAY e.g. be some transfer cases where it could occur. >> > [CNG] Do you mean setting a=3Dinactive? Correct. > I assume this means that if the endpoint tries to send a Advert/Config it= won't actually be transmitted across the channel. Even if the media stays = up. Well, the message might be transmitted if sent, but an endpoint should not = try to send a message to begin with in such case. The same applies to the media channels, so it would not be a CLUE specific = handling of "inactive". The important thing is that it would not affect the= CLUE session as such. Regards, Christer From pkyzivat@alum.mit.edu Thu Jan 23 21:51: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 D347A1A00F1 for ; Thu, 23 Jan 2014 21:51:31 -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 ruNhgPQl-Lcu for ; Thu, 23 Jan 2014 21:51:30 -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 DE5BD1A0094 for ; Thu, 23 Jan 2014 21:51:29 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id HhpC1n0011uE5Es53hrUJq; Fri, 24 Jan 2014 05:51:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id HhrU1n0093ZTu2S3chrUVa; Fri, 24 Jan 2014 05:51:28 +0000 Message-ID: <52E1FF60.9090202@alum.mit.edu> Date: Fri, 24 Jan 2014 00:51: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: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D11B7D5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D11B7D5@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=1390542688; bh=dw2uPJBEWf89EiTSHYNDkk1UQwHWp9zqmtUJM+bmD0A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EYs956PiMzn+ipFMbpin/z39+n8r/bHY/YcsewEnPFsl9TqHEdGCIDirvln0eQWg/ 6+Azho7VxIjs0s7sMAsX1SG+/LLcYEJyicWW4G1ypAfUd/IECpsy8IvforelUALfcV E6O4QTHoNcZL2+DTmkxzMVbWbwJq90VV8zrCv8dmaevWY9nBwAvjquZJyPQEPCAyLt vnqseHi1nOyi41yD7F+6OC2Xz99HMh2BXbu7xsjNNvGMsVJ5LMMLD6GlinGdVNjyOV QwXnhDQXsEvZfOSpBnN6CEqtxw7ss5k3dHsXVmy9HVf+gbbFnYEQOhzqcL8t61SQNZ AbllLq+l26gNg== Subject: Re: [clue] Data channel impact on CLUE state 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, 24 Jan 2014 05:51:32 -0000 On 1/23/14 10:30 PM, Christer Holmberg wrote: > Hi, > > One of the things, related to the data channel used for the CLUE > protocol, is what impact the data channel has on the CLUE session (if > there is such thing) itself. > > I have identified the following cases: > > *CASE #1: Data channel removed without signaling:* > > If the data channel for some reason disappears without signaling, it > does NOT impact the CLUE session. Everything goes on as before, based on > > previous CLUE- and SDP exchanges. Obviously, the data channel should > re-established asap. Do you mean the channel, or the SCTP association? This is an error case, so the actions have to do with trying to fix the error and coping in the meantime. When digging into this, exactly what is meant by "*removed* without signaling"? Since you are distinguishing this from case #3, does this imply that the SCTP association is ok, but there has been some sort of *channel* level error? (E.g., loss of a packet on the channel.) Or do you mean some sort of SCTP error that can't be attributed to a particular channel? Then there are cases where the channel is ok at the packet level, but there are problems above that. For instance, a packet in the channel was sent with the SCTP packet attributes inconsistent with what the CLUE protocol calls for. (I'm not sure that can happen.) And then there are actual clue protocol errors (e.g. bad syntax of the packet content). But they probably don't belong in this section. > *CASE #2: Data channel removed by setting port to zero:* > > If the data channel is explicitly removed, by setting the port value is > set to zero, but the media m- lines are still non-zero, media can still > be exchanged, but my > > suggestion is that any previously negotiated CLUE information (capture > information, spatial information) etc is removed at that point. So, > obviously this should not happen > > unless one really wants to stop using CLUE. You mean that the SCTP association is removed. So of course the specific channel(s) used for CLUE also go away. ISTM we should treat this in a layered fashion. Deal with this at one level as the channel going away. Deal separately with the association going away. (If we are in a state where we don't want to reestablish the channel, then we don't mind that the association is down. But if we are in a state where we are supposed to be reestablishing the channel, then we must first reestablish the association.) IOW, I suspect we will need one state machine for the SCTP association, and then, for certain SCTP states, a sub-state-machine for each channel that is being used by CLUE. > *CASE #3: Data channel removed on SCTP level:* > > Same as for CASE #2: If someone explicitly > removes the data channel (the SCTP connection MAY still be kept for > other purpose), it is an indication that the CLUE protocol is no more > used, and any associated CLUE state is removed. Again I think this maybe should be deferred to the protocol state machines. Especially if we decide to have separate state machines for each direction, then one going away may simply mean that *direction* stops, while the other direction continues. > *CASE #4: Data channel set inactive:* > > Same as for CASE #1: This use-case is > probably going to be rare, but there MAY e.g. be some transfer cases > where it could occur. I don't know if this is even well defined for SCTP. We should probably bring this up in mmusic wrt the SDP for SCTP. (And what about sendonly and recvonly?) If it is well defined, then it has the effect of temporarily blocking the creation or destruction of channels, and the transmission of packets. Perhaps this should merely be reflected as events in the clue protocol state machine. (An error when attempting to send.) Thanks, Paul > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Thu Jan 23 22:08: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 F238C1A0226 for ; Thu, 23 Jan 2014 22:08:01 -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 8Ir4gP52Mwd7 for ; Thu, 23 Jan 2014 22:08:00 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id BAD541A01BB for ; Thu, 23 Jan 2014 22:07:59 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-fa-52e2033d2b3c Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 72.DC.04853.D3302E25; Fri, 24 Jan 2014 07:07:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Fri, 24 Jan 2014 07:07:57 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Data channel impact on CLUE state Thread-Index: Ac8YtI5EhvCM4PHvSeKOP+gdfYn4/AAC2LYAAAJBfTA= Date: Fri, 24 Jan 2014 06:07:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D11BA44@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D11B7D5@ESESSMB209.ericsson.se> <52E1FF60.9090202@alum.mit.edu> In-Reply-To: <52E1FF60.9090202@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM+Jvja4t86Mgg0N7zS32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjysrvjAVXNSp2/hBqYHwm38XIySEhYCJx 8N8WRghbTOLCvfVsXYxcHEICJxglnt/+zQzhLGGUOPHyEHsXIwcHm4CFRPc/bZAGEQFPiR0f pzCD2MICphITt71nh4ibSXzrvMIEUi4iYCXxY6ssiMkioCrxcIo7SAWvgK/EojMvwNYKCeRL 3F95lRWkhFNAR2LbJWuQMCPQNd9PrWECsZkFxCU+HLzODHGlgMSSPeehbFGJl4//sULYShKN S56wQtTrSCzY/YkNwtaWWLbwNTPEWkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNkcWpx cW66kYFebnpuiV5qUWZycXF+nl5x6iZGYJwc3PLbaAfjyT32hxilOViUxHmvs9YECQmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamDcuPPRym9q9gIBsSe7V9/2Epg7R+vp4vsr0xbq3NmsqZe6 /4Nkh7tm9F1md4HZPnfSzl7ul3q5riTkqdhj1vT3awW2vrp/5sH5Q1WN+ydUeSe0GxjWzBPy mfn7emDCvA/ZtyYofM+sO7rs9oqqGW9rZG5Mn/1afv+HKWn/+e+vWd72wcIkP1M8RImlOCPR UIu5qDgRAMFlwr1hAgAA Subject: Re: [clue] Data channel impact on CLUE state 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, 24 Jan 2014 06:08:02 -0000 Hi, >> One of the things, related to the data channel used for the CLUE=20 >> protocol, is what impact the data channel has on the CLUE session (if=20 >> there is such thing) itself. >> >> I have identified the following cases: >> >> *CASE #1: Data channel removed without signaling:* >> >> If the data channel for some reason disappears without signaling, it=20 >> does NOT impact the CLUE session. Everything goes on as before, based=20 >> on previous CLUE- and SDP exchanges. Obviously, the data channel should= =20 >> re-established asap. > > Do you mean the channel, or the SCTP association? I said the channel, but I should have said the SCTP association. See more b= elow. > This is an error case, so the actions have to do with trying to fix the e= rror and coping in the meantime. Correct. > When digging into this, exactly what is meant by "*removed* without signa= ling"? Since you are distinguishing this from case #3, does this imply that= the SCTP association is ok, but there has been some sort of > *channel* level error? (E.g., loss of a packet on the channel.) Or do you= mean some sort of SCTP error that can't be attributed to a particular chan= nel? IF there are SCTP errors that can affect a particular channel, then yes. But, I was thinking more about loss of e.g. network bearer or resources. > Then there are cases where the channel is ok at the packet level, but the= re are problems above that. For instance, a packet in the channel was sent = with the SCTP packet attributes inconsistent with what the CLUE protocol ca= lls for. (I'm not sure that can happen.) We for sure have to go into the details.=20 But, at the end of the day, what I am suggesting is that the termination of= a CLUE session requires signaling (e.g. Offer/Answer) which explicitly rem= oves the CLUE channel. > And then there are actual clue protocol errors (e.g. bad syntax of the pa= cket content). But they probably don't belong in this section. Correct.=20 Of course, we may specify that certain protocol errors (or non-errors) trig= ger an explicit removal of the CLUE channel, but that is more related to th= e CLUE protocol details. >> *CASE #2: Data channel removed by setting port to zero:* >> >> If the data channel is explicitly removed, by setting the port value=20 >> is set to zero, but the media m- lines are still non-zero, media can=20 >> still be exchanged, but my >> >> suggestion is that any previously negotiated CLUE information (capture=20 >> information, spatial information) etc is removed at that point. So,=20 >> obviously this should not happen >> >> unless one really wants to stop using CLUE. > > You mean that the SCTP association is removed. So of course the specific > channel(s) used for CLUE also go away. Correct.=20 > ISTM we should treat this in a layered fashion. Deal with this at one lev= el as the channel going away. Deal separately with the association going=20 > away. (If we are in a state where we don't want to reestablish the channe= l, then we don't mind that the association is down. But if we are in a stat= e=20 > where we are supposed to be reestablishing the channel, then we must firs= t reestablish the association.) > > IOW, I suspect we will need one state machine for the SCTP association, a= nd then, for certain SCTP states, a sub-state-machine for each channel that= is being used by CLUE. Perhaps. But, I hope we can manage to not complicate things too much. That = will only lead to different entities having different understanding of the = CLUE session. >> *CASE #3: Data channel removed on SCTP level:* >> >> Same as for CASE #2: If someone=20 >> explicitly removes the data channel (the SCTP connection MAY still be=20 >> kept for other purpose), it is an indication that the CLUE protocol is=20 >> no more used, and any associated CLUE state is removed. > > Again I think this maybe should be deferred to the protocol state machine= s. Especially if we decide to have separate state machines for each directi= on, then one going away may simply mean that *direction* stops, while the o= ther direction continues. > > *CASE #4: Data channel set inactive:* > > Same as for CASE #1: This use-case is=20 > probably going to be rare, but there MAY e.g. be some transfer cases=20 > where it could occur. > > I don't know if this is even well defined for SCTP. We should probably br= ing this up in mmusic wrt the SDP for SCTP. (And what about sendonly and re= cvonly?) > > If it is well defined, then it has the effect of temporarily blocking the= creation or destruction of channels, and the transmission of packets. Perh= aps this should merely be reflected as events in the clue protocol state ma= chine. (An error when attempting to send.) Yes. Note, that I do NOT intend to cover all this in my data channel presentatio= n. I want us to first focus on the basics (e.g. how the data channel is cre= ated, whether we re-use RTCWEB stuff etc), and once we agree on that we tak= e the next step :) Regards, Christer From pkyzivat@alum.mit.edu Fri Jan 24 08:13: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 56F871A04A7 for ; Fri, 24 Jan 2014 08:13:47 -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_15=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 VOy5O9-Ko_wr for ; Fri, 24 Jan 2014 08:13:45 -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 5A6E11A04B0 for ; Fri, 24 Jan 2014 08:13:45 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta02.westchester.pa.mail.comcast.net with comcast id Hosb1n0040SCNGk51sDk7B; Fri, 24 Jan 2014 16:13:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id HsDj1n00c3ZTu2S3VsDjh3; Fri, 24 Jan 2014 16:13:44 +0000 Message-ID: <52E29137.4060807@alum.mit.edu> Date: Fri, 24 Jan 2014 11:13:43 -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: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D114D78@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D115483@ESESSMB209.ericsson.se> <52DFF36D.1060508@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D11B872@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D11B872@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390580024; bh=jULNTtccH699gFn7IBEBxVjLSHu+my5gJY5h5Emhq0Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IqAgv/VBLkdkdqry4XxYsCvXxXNz/mUAIiI7YvE5yXcRRdeSqpMBs/IAX4os3I1pM WOCA9Ru5fXn8tBK5GVTrlvfVtOdhyJlr1DaxijvRzTkZGi741ZB+hyRDmTwK6qYEO9 Nd5ycbOvfMyq82x8pIlhYSzBsGaYKT46RUuVhl3GXXqUh7uS+2TnywHSCOMrJPOb7u KMCn+C08FfITVNL+0inLMSoBkT6CKdetcg9JymXNZ6Bvmzz/FqCh62aSu707HxnoPf uSfmuKc6e44sQGLXbxpeC7SObAHUp3Kdkmxj6+aj20x95fWlZdm1Jrr+yZx162d5cN AfY6cSTSt33hw== Subject: Re: [clue] Don't use CLUE data channel terminology 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, 24 Jan 2014 16:13:47 -0000 On 1/23/14 10:52 PM, Christer Holmberg wrote: > Hi, > >> I don't see why we should be referencing rtcweb at all when talking about this. We are using a channel that is defined in transport, and described in SDP defined in mmusic. > > I don't think it's not that easy. > > Yes, the SCTP connection is negotiated using SDP, and the opening of SCTP streams is also done using generic mechanisms. BUT, there are procedures and semantics associated with the data channel itself that needs to be specified. So, either we re-use (if possible) what RTCWEB has done, or we need to specify it ourselves. Can you identify them? I agree there may be such things, but IMO they are problems to be solved. Are you talking about the abstracting up from unidirectional SCTP streams to bidirectional datachannels? > Of course, we can ask RTCWEB to not use "rtcweb data channel terminology", but something more generic, if CLUE also wants to use it. Yes - it is a matter of factoring the generic from the RTCWEB specific. I've already been asking for that where I find the problem, such as with the SDP for data channels, and in MSID. > But, let's not focus on the name for the moment - let's see if their solution TECHNICALLY fulfills the CLUE needs. Agree. >> We do happen to be using a mechanism that has a lot in common with the rtcweb data channel. That is helpful both because they are doing a lot of the definition work for us, and because we hope this will facilitate making webrtc clients for clue. But much of the usage will be without webrtc. > > Correct. So, if we don't want to re-use what they have done, there should be a good technical reason for that. > > I HAVE identified some issues, which seems to limit the usage to webrtc (or, even to JavaScript usage of webrtc), but I am having some off-line clarification discussions (if my issues are valid, I'll naturally bring them up on the list) with the authors regarding that. I'd be interested in hearing more about this. >> Note that xxx currently uses a=webrtc-DataChannel and a=wdcsa, but I already commented to Richard about that, and he agreed that those names should be changed. (To a=DataChannel and a=csa.) > > I think we shall do things step-by-step, which means we shall first determine whether we can use the "base" stuff, or whether Richard's suggested mechanism is needed. I may be wrong, but I think the "base stuff" you are talking about (for creation of data channels without SDP signaling) is embedded in JSEP APIs. Those are only for Javascript. I don't see how we can or should be dependent on those. Thanks, Paul > Regards, > > Christer > > > > > On 1/22/14 10:51 AM, Christer Holmberg wrote: >> Hi, >> >> The rtcweb data channel is not rtcweb application specific - they just >> call it that rtcweb data channel (well, they do make some assumptions, >> which are rtcweb:ish, but I have commented on that). >> >> When you use the data channel, you do need to indicate the protocol >> running on top of it (in our case, the clue protocol). Richard's >> proposal allows you to do it already in SDP, while they do it inside >> the data channel (once established). But, I don't think there are any >> differences in the data channel itself, and how it's used. >> >> Regards, >> >> Christer >> >> Sent from Windows Mail >> >> *From:* Mary Barnes >> *Sent:* ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎5‎:‎34‎ ‎PM >> *To:* Hans-Christer Holmberg >> *Cc:* clue@ietf.org , >> richard.ejzak@alcatel-lucent.com >> >> >> I did not understand that we were reusing the RTCWEB data channel. I >> think we need to think more in terms of the work that Richard Ejzak >> proposed for defining a more generic model for setting up an >> "application" specific SCTP/DTLS/UDP channel that was dispatched to >> MMUSIC WG at IETF-88: >> http://www.ietf.org/proceedings/88/minutes/minutes-88-dispatch >> >> While the original draft was focused on WebRTC, the work that was >> agreed to move forward was the generic SDP procedures, which I think >> is what CLUE would want to use. >> >> I'm cc'ing Richard as I don't think he's on the list and it would be >> good if we could understand the status of that work. >> >> Mary. >> >> >> On Wed, Jan 22, 2014 at 3:08 AM, Christer Holmberg >> > > >> wrote: >> >> And, just to clarify: my statement below is based on the assumption >> that we are going to re-use the rtcweb data channel in CLUE.____ >> >> __ __ >> >> *Lähettäjä:*clue [mailto:clue-bounces@ietf.org >> ] *Puolesta *Christer Holmberg >> *Lähetetty:* 22. tammikuuta 2014 11:07 >> *Vastaanottaja:* clue@ietf.org >> *Aihe:* [clue] Don't use CLUE data channel terminology____ >> >> __ __ >> >> Hi,____ >> >> __ __ >> >> I am currently working on my material for the “CLUE data channel” >> presentation.____ >> >> __ __ >> >> The first thing I’d like to suggest already at this point: Please >> let us not use “CLUE data channel” terminology. It makes thing >> confusing.____ >> >> __ __ >> >> My suggestion is to talk about “rtcweb data channel for CLUE”, >> “rtcweb data channel for CLUE usage”, or something similar…____ >> >> __ __ >> >> 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 Fri Jan 24 08:15: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 1CE4F1A003F for ; Fri, 24 Jan 2014 08:15:47 -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 qAqCqDNMXPsP for ; Fri, 24 Jan 2014 08:15:45 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 79A9D1A0032 for ; Fri, 24 Jan 2014 08:15:45 -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, 24 Jan 2014 08:15:44 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 24 Jan 2014 08:15:44 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 24 Jan 2014 08:15:41 -0800 Thread-Topic: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? Thread-Index: Ac8YT3432HoY77BASFyXME+QjDXdxAAzsJgQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D01ECE4@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@CRPMBOXPRD07.polycom.com> <52DF0AE9.1040509@nteczone.com> <52E00B42.5040409@alum.mit.edu> <52E073E1.4010305@nteczone.com> <52E134A3.8010609@alum.mit.edu> In-Reply-To: <52E134A3.8010609@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 grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 24 Jan 2014 16:15:47 -0000 It sounds like a few of us are agreeing in principle that there could be be= tter ways of expressing in an advertisement which captures can be included = in an MCC rather than just giving a list of captures as part of the MCC des= cription. For the framework document, I think it already covers as much detail that i= s appropriate for that document, basically this: - in an advertisement, an MCC may contain a reference to the other media ca= ptures contained in the MCC - in a configure message, an MCC may contain a reference to the other media= captures the consumer wishes to receive as part of the MCC Details of the syntax for how to represent this should be in the data model= . I don't think there are any other issues about this that belong in the f= ramework. Our discussion about grouping labels and regular expressions sho= uld apply to the data model. Does this make sense? Mark > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Thursday, January 23, 2014 10:26 AM > To: Christian Groves; Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MC= C - > allow wildcard? >=20 > On 1/22/14 8:44 PM, Christian Groves wrote: >=20 > >> When using labels, it would be easier to follow if the labels had > >> some significance. E.g. labels like "left", "center", "right". > > [CNG] Easier to follow for who? In terms of a consumer the labels are > > really just related to the syntax so probably wouldn't be seen by a > > person. I think in this case any random label would be sufficient. If > > we want spatial significance better to use spatial parameters. >=20 > In use I agree it doesn't matter. > But in the *examples* it is easier if they have some significance. >=20 > Thanks, > Paul From pkyzivat@alum.mit.edu Fri Jan 24 08:27: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 A48031A0010 for ; Fri, 24 Jan 2014 08:27:34 -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 ybHRGPpUMVJe for ; Fri, 24 Jan 2014 08:27:33 -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 D98D01A0029 for ; Fri, 24 Jan 2014 08:27:32 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta01.westchester.pa.mail.comcast.net with comcast id HpKK1n0040Fqzac51sTX7u; Fri, 24 Jan 2014 16:27:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id HsTX1n00Y3ZTu2S3UsTXiQ; Fri, 24 Jan 2014 16:27:31 +0000 Message-ID: <52E29473.4010208@alum.mit.edu> Date: Fri, 24 Jan 2014 11:27:31 -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: <7594FB04B1934943A5C02806D1A2204B1D11B7D5@ESESSMB209.ericsson.se> <52E1FF60.9090202@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D11BA44@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D11BA44@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=1390580851; bh=kusiQknbjbzFeKxDuBOJdLVAu4ShJ1i+4n4ryxDxbOA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=l5dLL7Zkq9VJH26iUBWuitYIZZ2NsE40aqh8EAyE3pxMXxU05jQeTNMLoeSxMN02b 4mivrGo3vaZ7xBkJ6caLIeZYb28RNrWJ/NCQcqX3QZKnzbbcWDTq3fXAqJ6xWfwVYh dZXkL1Kh6SWnOaaxao/1UgEfm0Yfjn+eJuJnsXezZwTsRXSzeG3qjIVzCArBiksMxf 3RSg7hZIdf1SlMy7XViJEJka5mZsoGRrtIpmqIIXgYG7JXozldqqyjlFu6pQrnEFXu fRCxSJSxGTKRcfOf8hqh51djzvSmxvXsU4bTpa0yRpITo93agY3gXAb2pr9q6Wbv1P y3vXht5IKEcsA== Subject: Re: [clue] Data channel impact on CLUE state 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, 24 Jan 2014 16:27:34 -0000 On 1/24/14 1:07 AM, Christer Holmberg wrote: > Hi, > >>> One of the things, related to the data channel used for the CLUE >>> protocol, is what impact the data channel has on the CLUE session (if >>> there is such thing) itself. >>> >>> I have identified the following cases: >>> >>> *CASE #1: Data channel removed without signaling:* >>> >>> If the data channel for some reason disappears without signaling, it >>> does NOT impact the CLUE session. Everything goes on as before, based >>> on previous CLUE- and SDP exchanges. Obviously, the data channel should >>> re-established asap. >> >> Do you mean the channel, or the SCTP association? > > I said the channel, but I should have said the SCTP association. See more below. > >> This is an error case, so the actions have to do with trying to fix the error and coping in the meantime. > > Correct. > >> When digging into this, exactly what is meant by "*removed* without signaling"? Since you are distinguishing this from case #3, does this imply that the SCTP association is ok, but there has been some sort of >> *channel* level error? (E.g., loss of a packet on the channel.) Or do you mean some sort of SCTP error that can't be attributed to a particular channel? > > IF there are SCTP errors that can affect a particular channel, then yes. > > But, I was thinking more about loss of e.g. network bearer or resources. I guess somehow we may need to classify the different sorts of errors that can be recognized. What an implementation can do depends on what is exposed via the api to the stack. Its tricky because we don't want to get to the stack details, but we need to make some distinctions. I'm thinking there may be association-level errors, sctp stream level errors, perhaps datachannel errors, and clue protocol errors. These are layered. (And if we go deeper, there may be UDP errors and DTLS errors. But I don't think we need to concern ourselves with these because we can treat them as sctp association errors.) >> Then there are cases where the channel is ok at the packet level, but there are problems above that. For instance, a packet in the channel was sent with the SCTP packet attributes inconsistent with what the CLUE protocol calls for. (I'm not sure that can happen.) > > We for sure have to go into the details. > > But, at the end of the day, what I am suggesting is that the termination of a CLUE session requires signaling (e.g. Offer/Answer) which explicitly removes the CLUE channel. I think I agree: - it takes explicit signaling to establish the clue channel - after that, problems with the clue channel are treated as *errors* until there is explicit signaling that we don't want the clue channel any longer. >> And then there are actual clue protocol errors (e.g. bad syntax of the packet content). But they probably don't belong in this section. > > Correct. > > Of course, we may specify that certain protocol errors (or non-errors) trigger an explicit removal of the CLUE channel, but that is more related to the CLUE protocol details. > >>> *CASE #2: Data channel removed by setting port to zero:* >>> >>> If the data channel is explicitly removed, by setting the port value >>> is set to zero, but the media m- lines are still non-zero, media can >>> still be exchanged, but my >>> >>> suggestion is that any previously negotiated CLUE information (capture >>> information, spatial information) etc is removed at that point. So, >>> obviously this should not happen >>> >>> unless one really wants to stop using CLUE. >> >> You mean that the SCTP association is removed. So of course the specific >> channel(s) used for CLUE also go away. > > Correct. > >> ISTM we should treat this in a layered fashion. Deal with this at one level as the channel going away. Deal separately with the association going >> away. (If we are in a state where we don't want to reestablish the channel, then we don't mind that the association is down. But if we are in a state >> where we are supposed to be reestablishing the channel, then we must first reestablish the association.) >> >> IOW, I suspect we will need one state machine for the SCTP association, and then, for certain SCTP states, a sub-state-machine for each channel that is being used by CLUE. > > Perhaps. But, I hope we can manage to not complicate things too much. That will only lead to different entities having different understanding of the CLUE session. If things are simple enough, then we can just use some words without a state machine. But the advantage of state machines is that they are very precise, which is hard to accomplish with words. >>> *CASE #3: Data channel removed on SCTP level:* >>> >>> Same as for CASE #2: If someone >>> explicitly removes the data channel (the SCTP connection MAY still be >>> kept for other purpose), it is an indication that the CLUE protocol is >>> no more used, and any associated CLUE state is removed. >> >> Again I think this maybe should be deferred to the protocol state machines. Especially if we decide to have separate state machines for each direction, then one going away may simply mean that *direction* stops, while the other direction continues. >> >> *CASE #4: Data channel set inactive:* >> >> Same as for CASE #1: This use-case is >> probably going to be rare, but there MAY e.g. be some transfer cases >> where it could occur. >> >> I don't know if this is even well defined for SCTP. We should probably bring this up in mmusic wrt the SDP for SCTP. (And what about sendonly and recvonly?) >> >> If it is well defined, then it has the effect of temporarily blocking the creation or destruction of channels, and the transmission of packets. Perhaps this should merely be reflected as events in the clue protocol state machine. (An error when attempting to send.) > > Yes. > > Note, that I do NOT intend to cover all this in my data channel presentation. I want us to first focus on the basics (e.g. how the data channel is created, whether we re-use RTCWEB stuff etc), and once we agree on that we take the next step :) We need to start somewhere, and then elaborate until we have enough. Thanks, Paul > Regards, > > Christer > > > > > > From pkyzivat@alum.mit.edu Fri Jan 24 08:46: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 A87C71A0053 for ; Fri, 24 Jan 2014 08:46: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 bbfTXQ_DMCBE for ; Fri, 24 Jan 2014 08:46:32 -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 26CF91A0023 for ; Fri, 24 Jan 2014 08:46:32 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta10.westchester.pa.mail.comcast.net with comcast id HqdE1n0030EZKEL5AsmWpG; Fri, 24 Jan 2014 16:46:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id HsmW1n00b3ZTu2S3MsmWcQ; Fri, 24 Jan 2014 16:46:30 +0000 Message-ID: <52E298E6.9020801@alum.mit.edu> Date: Fri, 24 Jan 2014 11:46:30 -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: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@CRPMBOXPRD07.polycom.com> <52DF0AE9.1040509@nteczone.com> <52E00B42.5040409@alum.mit.edu> <52E073E1.4010305@nteczone.com> <52E134A3.8010609@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D01ECE4@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D01ECE4@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=1390581990; bh=E84f40zVOGsFY4jiD/IZc+5RjNyEnCbNgaiXqDelhIc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MDdX83sR5k+BO16E9KeonoyhQHj5ekCDsftw8QUWiN247Mz/4Fvddyc3ozGAPaybw l7qRlGERiWm4sk0EiEfLZNPlYP2f1AL0QZ1B73H7hfDT7/XMa6/MLPELvM05JcJ7dK 9i5IgIHlk6SJv6ffv+Sv386salA7yX0z7G6fz0ZcGmW39xADPtHazcCOVN1L2IItSt sLt//Aj2+8RGQ9a4UxJ55cvH5zsz1NP2Op96sZvK+szugV9vGFpkb/RlgU0Yys5756 bY5nw6CdbtptyvFP2eVcaCu4eUnZtDYMVdLc2dgF5Ni7Hpjx6OJOwNcge3aMExDbJK Z8aKjDQO7RTVw== Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 24 Jan 2014 16:46:33 -0000 On 1/24/14 11:15 AM, Duckworth, Mark wrote: > It sounds like a few of us are agreeing in principle that there could be better ways of expressing in an advertisement which captures can be included in an MCC rather than just giving a list of captures as part of the MCC description. > > For the framework document, I think it already covers as much detail that is appropriate for that document, basically this: > - in an advertisement, an MCC may contain a reference to the other media captures contained in the MCC > - in a configure message, an MCC may contain a reference to the other media captures the consumer wishes to receive as part of the MCC > > Details of the syntax for how to represent this should be in the data model. I don't think there are any other issues about this that belong in the framework. Our discussion about grouping labels and regular expressions should apply to the data model. Does this make sense? WFM > Mark > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, January 23, 2014 10:26 AM >> To: Christian Groves; Duckworth, Mark; clue@ietf.org >> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - >> allow wildcard? >> >> On 1/22/14 8:44 PM, Christian Groves wrote: >> >>>> When using labels, it would be easier to follow if the labels had >>>> some significance. E.g. labels like "left", "center", "right". >>> [CNG] Easier to follow for who? In terms of a consumer the labels are >>> really just related to the syntax so probably wouldn't be seen by a >>> person. I think in this case any random label would be sufficient. If >>> we want spatial significance better to use spatial parameters. >> >> In use I agree it doesn't matter. >> But in the *examples* it is easier if they have some significance. >> >> Thanks, >> Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Fri Jan 24 09:11: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 4A1371A04C9 for ; Fri, 24 Jan 2014 09:11:35 -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 n2iDtucFUYx5 for ; Fri, 24 Jan 2014 09:11:34 -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 22EA01A00BD for ; Fri, 24 Jan 2014 09:11:34 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta04.westchester.pa.mail.comcast.net with comcast id Hpnd1n0050Fqzac54tBY2k; Fri, 24 Jan 2014 17:11:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id HtBY1n00P3ZTu2S3UtBYWL; Fri, 24 Jan 2014 17:11:32 +0000 Message-ID: <52E29EC4.1040201@alum.mit.edu> Date: Fri, 24 Jan 2014 12:11:32 -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 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=1390583492; bh=xagGrpxnL888CnUpGTCzD/IXHy5IOA50a0NaPD8WahU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DwnJdH9LXFhfcEIj4DVKazk3fpiihQc6TlCKNwLW3+hTyhvgqtRRwY+KqDCwG7BeN LyNHN5IqiFNZ/L1TwC4qSgNvcTxxU6oGt8j8KIrva8Omh8GF7nBXQVTIEx/2oKyaLA 1SEndsY9nGZaBYZdIrzfN0GOA3g4W5vD6AJbapJrpf1B8/loY+IXkIXVpbDZg6hE5W HXMuudfRmOlW7w6odWj07zqi70rgLmx4gfPe0VscBP/4uR731Lg683MiT2nSFa2qpt imJPDiraHCtN101QIk/moHB4ObCY+gDu57JUBi0+U1YKtHFhx7z2tHwJ/XOAbM+UCy 6jqAdITrrVaoQ== Subject: [clue] Reminder: Interim Meeting: Monday, January 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: Fri, 24 Jan 2014 17:11:35 -0000 http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140127 From mary.ietf.barnes@gmail.com Fri Jan 24 13:36: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 B0F971A012F for ; Fri, 24 Jan 2014 13:36:21 -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 zHktzsEOnSRU for ; Fri, 24 Jan 2014 13:36:20 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id E69671A00DE for ; Fri, 24 Jan 2014 13:36:19 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id uy17so3677511igb.3 for ; Fri, 24 Jan 2014 13:36:18 -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=9fFFRn+VxdJnl4FghpehiDzvaqP3klKXhvgdgcNWgxU=; b=MyCRi0EFZU2FDWbpR5ihUjs9FWHAePyxtfDVUw6Pyxes/E7biK7a+tpgo+lIsFiGze YltgVfA/Nc0GfGmnh8Q8E6mtZHBBdkT9PhBVxs+65L/9Ug62TgnHuPkYlkmozyqWKSJt kPOAQRmH4nWp2H/E/AaibjRijPOsbF4pl0dBI11BQG9c9S4p3tW2xcAp68IcSfwA3+Gw kuZLuWmx8rFQCgDuXRRllGHgoqLSK/uJVeZggEafKWyc65xSLTaC8sVJiZuFfH2QYLRM dglZHv9FGWXvztNpwPlkKh5q/igP70xu8TUneT1YdsLBqbp+cbhW+VzIqel4HPprmSL3 i/2A== MIME-Version: 1.0 X-Received: by 10.50.114.4 with SMTP id jc4mr6737238igb.0.1390599378558; Fri, 24 Jan 2014 13:36:18 -0800 (PST) Received: by 10.43.58.137 with HTTP; Fri, 24 Jan 2014 13:36:18 -0800 (PST) Date: Fri, 24 Jan 2014 15:36:18 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b2e0983fc313504f0be25bf Subject: [clue] Minutes from Jan. 21, 2014 Design Team Meeting 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, 24 Jan 2014 21:36:21 -0000 --047d7b2e0983fc313504f0be25bf Content-Type: text/plain; charset=ISO-8859-1 HI all, The minutes (including link to .ppt and recording) are now available: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-140121.txt We will be touching on some of the framework issues again during the Jan 27 Virtual Interim. Mary. --047d7b2e0983fc313504f0be25bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI all,

The minutes (includi= ng link to .ppt and recording) are now available:

We will be touching on some of the framework issu= es again during the Jan 27 Virtual Interim.

Mary.<= /div>
--047d7b2e0983fc313504f0be25bf-- From christer.holmberg@ericsson.com Fri Jan 24 17:22: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 55DE41A02B5 for ; Fri, 24 Jan 2014 17:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=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 MB-tTHa2l6GN for ; Fri, 24 Jan 2014 17:22:30 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id BA50E1A0293 for ; Fri, 24 Jan 2014 17:22:29 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-3f-52e311d36bbe Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 0E.C1.04249.3D113E25; Sat, 25 Jan 2014 02:22:27 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.13]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Sat, 25 Jan 2014 02:22:27 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: VS: [clue] Don't use CLUE data channel terminology Thread-Index: Ac8XUS8NTKb7QlBZQx6Z1V6CPy51+wAAFgmAAAtk1IAAArAIwP//+5SA//2jP+CABXs0gP//W4sQ Date: Sat, 25 Jan 2014 01:22:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D121B1C@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D114D5B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D114D78@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D115483@ESESSMB209.ericsson.se> <52DFF36D.1060508@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D11B872@ESESSMB209.ericsson.se> <52E29137.4060807@alum.mit.edu> In-Reply-To: <52E29137.4060807@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.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvje5lwcdBBp0HzSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj24Pb7AU7Ait+3eFvYFzj38XIwSEhYCLR 9Jqpi5ETyBSTuHBvPRuILSRwhFFi0svsLkYuIHsxo8Tz9r3sIPVsAhYS3f+0QWpEBDwldnyc wgxiCwvYS+ya8YMVIu4g8efpXSg7SqLhzCoWEJtFQFVi0fdrYPW8Ar4SjUt2M0HMX8oscWLu PCaQ+ZwCOhIPL0SB1DAC3fP91Bqw25gFxCU+HLzODHGngMSSPeehbFGJl4//sULYShIrtl9i BBnDLKApsX6XPkSrosSU7ofsEGsFJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEjyypGjuLU4qTc dCODTYzAGDi45bfFDsbLf20OMUpzsCiJ83586xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gVF4a8PPK8rLhfkqMhYqsNQml4rFOx2yv33eJ332upnfwi0mrtm1MS3z0Xyrszm3+3odtDfc iJ+g8XWT7pvz+aeE6vblHGxYG8nFeYz3QmDRHR6lTmmWQO83wV8YDhdZ9tVd5Dp/WIK9rGlq gZpuRMzqixNCr8a+FV7u3Xpg0gL+gummXh32kkosxRmJhlrMRcWJAJduDeRPAgAA Subject: Re: [clue] Don't use CLUE data channel terminology 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, 25 Jan 2014 01:22:32 -0000 SGksDQoNCj4+PiBJIGRvbid0IHNlZSB3aHkgd2Ugc2hvdWxkIGJlIHJlZmVyZW5jaW5nIHJ0Y3dl YiBhdCBhbGwgd2hlbiB0YWxraW5nIGFib3V0IHRoaXMuIFdlIGFyZSB1c2luZyBhIGNoYW5uZWwg dGhhdCBpcyBkZWZpbmVkIGluIHRyYW5zcG9ydCwgYW5kIGRlc2NyaWJlZCBpbiBTRFAgZGVmaW5l ZCBpbiBtbXVzaWMuDQo+Pg0KPj4gSSBkb24ndCB0aGluayBpdCdzIG5vdCB0aGF0IGVhc3kuDQo+ Pg0KPj4gWWVzLCB0aGUgU0NUUCBjb25uZWN0aW9uIGlzIG5lZ290aWF0ZWQgdXNpbmcgU0RQLCBh bmQgdGhlIG9wZW5pbmcgb2YgU0NUUCBzdHJlYW1zIGlzIGFsc28gZG9uZSB1c2luZyBnZW5lcmlj IG1lY2hhbmlzbXMuIEJVVCwgdGhlcmUgDQo+PiBhcmUgcHJvY2VkdXJlcyBhbmQgc2VtYW50aWNz IGFzc29jaWF0ZWQgd2l0aCB0aGUgZGF0YSBjaGFubmVsIGl0c2VsZiB0aGF0IG5lZWRzIHRvIGJl IHNwZWNpZmllZC4gU28sIGVpdGhlciB3ZSByZS11c2UgKGlmIHBvc3NpYmxlKSB3aGF0IFJUQ1dF QiBoYXMgZG9uZSwgb3Igd2UgbmVlZCB0byBzcGVjaWZ5IGl0IG91cnNlbHZlcy4NCj4NCj4gQ2Fu IHlvdSBpZGVudGlmeSB0aGVtPw0KDQpJIHdpbGwgZG8gdGhhdCBpbiBteSBwcmVzZW50YXRpb24s IGJ1dCBiYXNpY2FsbHkgaXQgaXMgYWJvdXQgU0NUUCBvcHRpb25zIChpbmNsdWRpbmcgdGhlIHVz YWdlIG9mIHR3byBiaWRpcmVjdGlvbmFsIFNDVFAgc3RyZWFtcywgYXMgeW91IG1lbnRpb24gYmVs b3csIGFuZCB0aGUgcnRjd2ViIGRhdGEgY2hhbm5lbCBQUk9UT0NPTCB3aGljaCBpcyB1c2VkIHRv IG9wZW4gdGhlIGRhdGEgY2hhbm5lbCwgYW5kIGluZGljYXRlIHdoYXQgYXBwbGljYXRpb24gKGlu IG91ciBjYXNlOiBDTFVFKSB0aGUgZGF0YSBjaGFubmVsIHdpbGwgYmUgdXNlZCBmb3IuDQoNCkkg aGF2ZSBzbyBmYXIgZm91bmQgbm8gcmVhc29uIHdoeSB3ZSBjb3VsZG4ndCByZS11c2UgdGhlIHJ0 Y3dlYiBzdHVmZi4NCg0KPiBJIGFncmVlIHRoZXJlIG1heSBiZSBzdWNoIHRoaW5ncywgYnV0IElN TyB0aGV5IGFyZSBwcm9ibGVtcyB0byBiZSBzb2x2ZWQuDQo+DQo+IEFyZSB5b3UgdGFsa2luZyBh Ym91dCB0aGUgYWJzdHJhY3RpbmcgdXAgZnJvbSB1bmlkaXJlY3Rpb25hbCBTQ1RQIHN0cmVhbXMg dG8gYmlkaXJlY3Rpb25hbCBkYXRhY2hhbm5lbHM/DQoNCkZvciBleGFtcGxlLCB5ZXMuDQoNCj4+ IE9mIGNvdXJzZSwgd2UgY2FuIGFzayBSVENXRUIgdG8gbm90IHVzZSAicnRjd2ViIGRhdGEgY2hh bm5lbCB0ZXJtaW5vbG9neSIsIGJ1dCBzb21ldGhpbmcgbW9yZSBnZW5lcmljLCBpZiBDTFVFIGFs c28gd2FudHMgdG8gdXNlIGl0Lg0KPg0KPiBZZXMgLSBpdCBpcyBhIG1hdHRlciBvZiBmYWN0b3Jp bmcgdGhlIGdlbmVyaWMgZnJvbSB0aGUgUlRDV0VCIHNwZWNpZmljLg0KDQpUaGV5IGFsc28gdGFs ayBhYm91dCAiSmF2YVNjcmlwdCBzdHJpbmdzIiwgYnV0IGl0IGlzIGltcG9ydGFudCB0byBub3Rl IHRoYXQgaXQgZG9lcyBOT1QgbWFuZGF0ZSB0aGUgdXNhZ2Ugb2YgSmF2YVNjcmlwdCAodGhhdCB3 b3VsZCBub3Qgd29yayBmb3IgcnRjd2ViIGVpdGhlcikuIA0KDQpJJ3ZlIGFscmVhZHkgYmVlbiBh c2tpbmcgZm9yIHRoYXQgd2hlcmUgSSBmaW5kIHRoZSBwcm9ibGVtLCBzdWNoIGFzIHdpdGggdGhl IFNEUCBmb3IgZGF0YSBjaGFubmVscywgYW5kIGluIE1TSUQuDQoNCj4gQnV0LCBsZXQncyBub3Qg Zm9jdXMgb24gdGhlIG5hbWUgZm9yIHRoZSBtb21lbnQgLSBsZXQncyBzZWUgaWYgdGhlaXIgc29s dXRpb24gVEVDSE5JQ0FMTFkgZnVsZmlsbHMgdGhlIENMVUUgbmVlZHMuDQoNCkFncmVlLg0KDQo+ Pj4gV2UgZG8gaGFwcGVuIHRvIGJlIHVzaW5nIGEgbWVjaGFuaXNtIHRoYXQgaGFzIGEgbG90IGlu IGNvbW1vbiB3aXRoIHRoZSBydGN3ZWIgZGF0YSBjaGFubmVsLiBUaGF0IGlzIGhlbHBmdWwgYm90 aCBiZWNhdXNlIHRoZXkgYXJlIGRvaW5nIGEgbG90IG9mIHRoZSBkZWZpbml0aW9uIHdvcmsgZm9y IHVzLCBhbmQgYmVjYXVzZSB3ZSBob3BlIHRoaXMgd2lsbCBmYWNpbGl0YXRlIG1ha2luZyB3ZWJy dGMgY2xpZW50cyBmb3IgY2x1ZS4gQnV0IG11Y2ggb2YgdGhlIHVzYWdlIHdpbGwgYmUgd2l0aG91 dCB3ZWJydGMuDQo+Pg0KPj4gQ29ycmVjdC4gU28sIGlmIHdlIGRvbid0IHdhbnQgdG8gcmUtdXNl IHdoYXQgdGhleSBoYXZlIGRvbmUsIHRoZXJlIHNob3VsZCBiZSBhIGdvb2QgdGVjaG5pY2FsIHJl YXNvbiBmb3IgdGhhdC4NCj4+DQo+PiBJIEhBVkUgaWRlbnRpZmllZCBzb21lIGlzc3Vlcywgd2hp Y2ggc2VlbXMgdG8gbGltaXQgdGhlIHVzYWdlIHRvIHdlYnJ0YyAob3IsIGV2ZW4gdG8gSmF2YVNj cmlwdCB1c2FnZSBvZiB3ZWJydGMpLCBidXQgSSBhbSBoYXZpbmcgc29tZSBvZmYtbGluZSBjbGFy aWZpY2F0aW9uIGRpc2N1c3Npb25zIChpZiBteSBpc3N1ZXMgYXJlIHZhbGlkLCBJJ2xsIG5hdHVy YWxseSBicmluZyB0aGVtIHVwIG9uIHRoZSBsaXN0KSB3aXRoIHRoZSBhdXRob3JzIHJlZ2FyZGlu ZyB0aGF0Lg0KPg0KPiBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIG1vcmUgYWJvdXQgdGhp cy4NCg0KVGhlIGlzc3VlIHdoaWNoIGFmZmVjdHMgQ0xVRSB3YXMgcmVnYXJkaW5nIHRoZSBKYXZh U2NyaXB0IHN0cmluZyB1c2FnZS4gRnJvbSB0aGUgZHJhZnQgaXQgd2FzIGEgbGl0dGxlIHVuY2xl YXIgdG8gbWUgd2hldGhlciBpdCBjYW4gYmUgdXNlZCBieSBub24tSlMgYXBwbGljYXRpb25zLiBC dXQsIGFzIGRlc2NyaWJlZCBhYm92ZSwgaXQgb25seSByZWZlcnMgdG8gYSBzdHJpbmcgZm9ybWF0 LiANCg0KVGhlcmUgYXJlIGFsc28gb3RoZXIgaXNzdWVzIChvciwgbWlzc2luZyB0ZXh0KSwgd2hp Y2ggYXJlIG5vdCBDTFVFIHNwZWNpZmljLCB3aGljaCBJIGludGVuZCB0byBicmluZyB1cCBvbiB0 aGUgbGlzdC4gRm9yIGV4YW1wbGUsIGl0IGlzIG5vdCBkZXNjcmliZWQgaG93IHRoZSBUTFMgcm9s ZXMgYXJlIGRldGVybWluZWQuDQoNCj4+PiBOb3RlIHRoYXQgeHh4IGN1cnJlbnRseSB1c2VzIGE9 d2VicnRjLURhdGFDaGFubmVsIGFuZCBhPXdkY3NhLCBidXQgSSANCj4+PiBhbHJlYWR5IGNvbW1l bnRlZCB0byBSaWNoYXJkIGFib3V0IHRoYXQsIGFuZCBoZSBhZ3JlZWQgdGhhdCB0aG9zZSANCj4+ PiBuYW1lcyBzaG91bGQgYmUgY2hhbmdlZC4gKFRvIGE9RGF0YUNoYW5uZWwgYW5kIGE9Y3NhLikN Cj4+DQo+PiBJIHRoaW5rIHdlIHNoYWxsIGRvIHRoaW5ncyBzdGVwLWJ5LXN0ZXAsIHdoaWNoIG1l YW5zIHdlIHNoYWxsIGZpcnN0IGRldGVybWluZSB3aGV0aGVyIHdlIGNhbiB1c2UgdGhlICJiYXNl IiBzdHVmZiwgb3Igd2hldGhlciBSaWNoYXJkJ3Mgc3VnZ2VzdGVkIG1lY2hhbmlzbSBpcyBuZWVk ZWQuDQo+DQo+IEkgbWF5IGJlIHdyb25nLCBidXQgSSB0aGluayB0aGUgImJhc2Ugc3R1ZmYiIHlv dSBhcmUgdGFsa2luZyBhYm91dCAoZm9yIGNyZWF0aW9uIG9mIGRhdGEgY2hhbm5lbHMgd2l0aG91 dCBTRFAgc2lnbmFsaW5nKSBpcyBlbWJlZGRlZCBpbiBKU0VQIEFQSXMuIFRob3NlIGFyZSBvbmx5 IGZvciBKYXZhc2NyaXB0LiBJIGRvbid0IHNlZSBob3cgd2UgY2FuIG9yIHNob3VsZCBiZSBkZXBl bmRlbnQgb24gdGhvc2UuDQoNClRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IGZvciB0aGUgdXNhZ2Ug b2YgdGhlIEpTRVAgQVBJIGluIHRoZSBJRVRGIGRhdGEgY2hhbm5lbCBzcGVjcy4gVGhlIFNEUCBw YXJ0cyBhcmUgZ2VuZXJpYy4NCg0KQWxzbywgeW91IERPIGNyZWF0ZSB0aGUgZGF0YSBjaGFubmVs IHVzaW5nIFNEUC4gVGhlIFVTQUdFIChlLmcuIENMVUUpIG9mIHRoZSBkYXRhIGNoYW5uZWwgaXMg dGhlbiBuZWdvdGlhdGVkIGluLWJhbmQsIHVzaW5nIHRoZSBydGN3ZWIgZGF0YSBjaGFubmVsIHBy b3RvY29sLiBCdXQsIG5vdGhpbmcgcHJldmVudHMgdXMgZnJvbSwgaW4gQURESVRJT04sIGFsc28g dXNpbmcgUmljaGFyZCdzIGRyYWZ0IGlmIHdlIHdhbnQgdG8gaW5kaWNhdGUgdGhlIHVzYWdlIGlu IFNEUC4gDQoNCkJ1dCwgeW91J2xsIGhlYXIgbW9yZSBhYm91dCB0aGlzIG9uIE1vbmRheSA6KQ0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCj4NCj4gT24gMS8yMi8xNCAxMDo1MSBBTSwgQ2hy aXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+PiBIaSwNCj4+DQo+PiBUaGUgcnRjd2ViIGRhdGEgY2hh bm5lbCBpcyBub3QgcnRjd2ViIGFwcGxpY2F0aW9uIHNwZWNpZmljIC0gdGhleSANCj4+IGp1c3Qg Y2FsbCBpdCB0aGF0IHJ0Y3dlYiBkYXRhIGNoYW5uZWwgKHdlbGwsIHRoZXkgZG8gbWFrZSBzb21l IA0KPj4gYXNzdW1wdGlvbnMsIHdoaWNoIGFyZSBydGN3ZWI6aXNoLCBidXQgSSBoYXZlIGNvbW1l bnRlZCBvbiB0aGF0KS4NCj4+DQo+PiBXaGVuIHlvdSB1c2UgdGhlIGRhdGEgY2hhbm5lbCwgeW91 IGRvIG5lZWQgdG8gaW5kaWNhdGUgdGhlIHByb3RvY29sIA0KPj4gcnVubmluZyBvbiB0b3Agb2Yg aXQgKGluIG91ciBjYXNlLCB0aGUgY2x1ZSBwcm90b2NvbCkuIFJpY2hhcmQncyANCj4+IHByb3Bv c2FsIGFsbG93cyB5b3UgdG8gZG8gaXQgYWxyZWFkeSBpbiBTRFAsIHdoaWxlIHRoZXkgZG8gaXQg aW5zaWRlIA0KPj4gdGhlIGRhdGEgY2hhbm5lbCAob25jZSBlc3RhYmxpc2hlZCkuIEJ1dCwgSSBk b24ndCB0aGluayB0aGVyZSBhcmUgYW55IA0KPj4gZGlmZmVyZW5jZXMgaW4gdGhlIGRhdGEgY2hh bm5lbCBpdHNlbGYsIGFuZCBob3cgaXQncyB1c2VkLg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4g Q2hyaXN0ZXINCj4+DQo+PiBTZW50IGZyb20gV2luZG93cyBNYWlsDQo+Pg0KPj4gKkZyb206KiBN YXJ5IEJhcm5lcyA8bWFpbHRvOm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPg0KPj4gKlNlbnQ6 KiDigI5XZWRuZXNkYXnigI4sIOKAjkphbnVhcnnigI4g4oCOMjLigI4sIOKAjjIwMTQg4oCONeKA jjrigI4zNOKAjiDigI5QTQ0KPj4gKlRvOiogSGFucy1DaHJpc3RlciBIb2xtYmVyZyA8bWFpbHRv OmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+ICpDYzoqIGNsdWVAaWV0Zi5vcmcg PG1haWx0bzpjbHVlQGlldGYub3JnPiwgDQo+PiByaWNoYXJkLmVqemFrQGFsY2F0ZWwtbHVjZW50 LmNvbSANCj4+IDxtYWlsdG86cmljaGFyZC5lanpha0BhbGNhdGVsLWx1Y2VudC5jb20+DQo+Pg0K Pj4gSSBkaWQgbm90IHVuZGVyc3RhbmQgdGhhdCB3ZSB3ZXJlIHJldXNpbmcgdGhlIFJUQ1dFQiBk YXRhIGNoYW5uZWwuICBJIA0KPj4gdGhpbmsgd2UgbmVlZCB0byB0aGluayBtb3JlIGluIHRlcm1z IG9mIHRoZSB3b3JrIHRoYXQgUmljaGFyZCBFanphayANCj4+IHByb3Bvc2VkIGZvciBkZWZpbmlu ZyBhIG1vcmUgZ2VuZXJpYyBtb2RlbCBmb3Igc2V0dGluZyB1cCBhbiANCj4+ICJhcHBsaWNhdGlv biIgc3BlY2lmaWMgU0NUUC9EVExTL1VEUCBjaGFubmVsIHRoYXQgd2FzIGRpc3BhdGNoZWQgdG8g DQo+PiBNTVVTSUMgV0cgYXQgSUVURi04ODoNCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvODgvbWludXRlcy9taW51dGVzLTg4LWRpc3BhdGNoDQo+Pg0KPj4gV2hpbGUgdGhlIG9y aWdpbmFsIGRyYWZ0IHdhcyBmb2N1c2VkIG9uIFdlYlJUQywgdGhlIHdvcmsgdGhhdCB3YXMgDQo+ PiBhZ3JlZWQgdG8gbW92ZSBmb3J3YXJkIHdhcyB0aGUgZ2VuZXJpYyBTRFAgcHJvY2VkdXJlcywg d2hpY2ggSSB0aGluayANCj4+IGlzIHdoYXQgQ0xVRSB3b3VsZCB3YW50IHRvIHVzZS4NCj4+DQo+ PiBJJ20gY2MnaW5nIFJpY2hhcmQgYXMgSSBkb24ndCB0aGluayBoZSdzIG9uIHRoZSBsaXN0IGFu ZCBpdCB3b3VsZCBiZSANCj4+IGdvb2QgaWYgd2UgY291bGQgdW5kZXJzdGFuZCB0aGUgc3RhdHVz IG9mIHRoYXQgd29yay4NCj4+DQo+PiBNYXJ5Lg0KPj4NCj4+DQo+PiBPbiBXZWQsIEphbiAyMiwg MjAxNCBhdCAzOjA4IEFNLCBDaHJpc3RlciBIb2xtYmVyZyANCj4+IDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20gDQo+PiA8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4+DQo+PiB3cm90ZToNCj4+DQo+PiAgICAgIEFuZCwganVzdCB0byBjbGFyaWZ5OiBteSBzdGF0 ZW1lbnQgYmVsb3cgaXMgYmFzZWQgb24gdGhlIGFzc3VtcHRpb24NCj4+ICAgICAgdGhhdCB3ZSBh cmUgZ29pbmcgdG8gcmUtdXNlIHRoZSBydGN3ZWIgZGF0YSBjaGFubmVsIGluIENMVUUuX19fXw0K Pj4NCj4+ICAgICAgX18gX18NCj4+DQo+PiAgICAgICpMw6RoZXR0w6Rqw6Q6KmNsdWUgW21haWx0 bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmcNCj4+ICAgICAgPG1haWx0bzpjbHVlLWJvdW5jZXNAaWV0 Zi5vcmc+XSAqUHVvbGVzdGEgKkNocmlzdGVyIEhvbG1iZXJnDQo+PiAgICAgICpMw6RoZXRldHR5 OiogMjIuIHRhbW1pa3V1dGEgMjAxNCAxMTowNw0KPj4gICAgICAqVmFzdGFhbm90dGFqYToqIGNs dWVAaWV0Zi5vcmcgPG1haWx0bzpjbHVlQGlldGYub3JnPg0KPj4gICAgICAqQWloZToqIFtjbHVl XSBEb24ndCB1c2UgQ0xVRSBkYXRhIGNoYW5uZWwgdGVybWlub2xvZ3lfX19fDQo+Pg0KPj4gICAg ICBfXyBfXw0KPj4NCj4+ICAgICAgSGksX19fXw0KPj4NCj4+ICAgICAgX18gX18NCj4+DQo+PiAg ICAgIEkgYW0gY3VycmVudGx5IHdvcmtpbmcgb24gbXkgbWF0ZXJpYWwgZm9yIHRoZSDigJxDTFVF IGRhdGEgY2hhbm5lbOKAnQ0KPj4gICAgICBwcmVzZW50YXRpb24uX19fXw0KPj4NCj4+ICAgICAg X18gX18NCj4+DQo+PiAgICAgIFRoZSBmaXJzdCB0aGluZyBJ4oCZZCBsaWtlIHRvIHN1Z2dlc3Qg YWxyZWFkeSBhdCB0aGlzIHBvaW50OiBQbGVhc2UNCj4+ICAgICAgbGV0IHVzIG5vdCB1c2Ug4oCc Q0xVRSBkYXRhIGNoYW5uZWzigJ0gdGVybWlub2xvZ3kuIEl0IG1ha2VzIHRoaW5nDQo+PiAgICAg IGNvbmZ1c2luZy5fX19fDQo+Pg0KPj4gICAgICBfXyBfXw0KPj4NCj4+ICAgICAgTXkgc3VnZ2Vz dGlvbiBpcyB0byB0YWxrIGFib3V0IOKAnHJ0Y3dlYiBkYXRhIGNoYW5uZWwgZm9yIENMVUXigJ0s DQo+PiAgICAgIOKAnHJ0Y3dlYiBkYXRhIGNoYW5uZWwgZm9yIENMVUUgdXNhZ2XigJ0sIG9yIHNv bWV0aGluZyBzaW1pbGFy4oCmX19fXw0KPj4NCj4+ICAgICAgX18gX18NCj4+DQo+PiAgICAgIFJl Z2FyZHMsX19fXw0KPj4NCj4+ICAgICAgX18gX18NCj4+DQo+PiAgICAgIENocmlzdGVyX19fXw0K Pj4NCj4+DQo+PiAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiAgICAgIGNsdWUgbWFpbGluZyBsaXN0DQo+PiAgICAgIGNsdWVAaWV0Zi5vcmcg PG1haWx0bzpjbHVlQGlldGYub3JnPg0KPj4gICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NsdWUNCj4+DQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4+IGNs dWVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1 ZQ0KPj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4NCg0K From Christian.Groves@nteczone.com Sun Jan 26 03:08: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 77FBE1A0131 for ; Sun, 26 Jan 2014 03:08:29 -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 gJfo_x2IO6Gq for ; Sun, 26 Jan 2014 03:08:27 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345C51A0128 for ; Sun, 26 Jan 2014 03:08:27 -0800 (PST) Received: from ppp118-209-180-179.lns20.mel6.internode.on.net ([118.209.180.179]:61009 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W7NVY-0008DZ-Ek for clue@ietf.org; Sun, 26 Jan 2014 22:04:08 +1100 Message-ID: <52E4ECA7.7020601@nteczone.com> Date: Sun, 26 Jan 2014 22:08:23 +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: <20140126110537.25843.80724.idtracker@ietfa.amsl.com> In-Reply-To: <20140126110537.25843.80724.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140126110537.25843.80724.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; 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: [clue] Fwd: New Version Notification for draft-groves-clue-latent-config-00.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: Sun, 26 Jan 2014 11:08:29 -0000 Hello I've submitted a draft regarding the CLUE signalling proposing the use of SDP latent configurations to describe the encodings. I think there are some benefits over the use of a separate m-line for each encoding. Comments? Regards, Christian -------- Original Message -------- Subject: New Version Notification for draft-groves-clue-latent-config-00.txt Date: Sun, 26 Jan 2014 03:05:37 -0800 From: internet-drafts@ietf.org To: Weiwei Yang , "Weiwei Yang" , "Roni Even" , Roni Even , Christian Groves , "Christian Groves" A new version of I-D, draft-groves-clue-latent-config-00.txt has been successfully submitted by Christian Groves and posted to the IETF repository. Name: draft-groves-clue-latent-config Revision: 00 Title: CLUE and latent configurations Document date: 2014-01-26 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-groves-clue-latent-config-00.txt Status: https://datatracker.ietf.org/doc/draft-groves-clue-latent-config/ Htmlized: http://tools.ietf.org/html/draft-groves-clue-latent-config-00 Abstract: This document proposes to use Latent Configurations as described by the SDP media capability negotiation framework [RFC6871] for the description and negotiation of CLUE encodings. 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 From Christian.Groves@nteczone.com Mon Jan 27 02:44: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 C553D1A01E7 for ; Mon, 27 Jan 2014 02:44:22 -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 1qxqyWD3Fihp for ; Mon, 27 Jan 2014 02:44:20 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994FD1A01E1 for ; Mon, 27 Jan 2014 02:44:20 -0800 (PST) Received: from ppp118-209-235-11.lns20.mel6.internode.on.net ([118.209.235.11]:60604 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W7jbX-0003rz-8s for clue@ietf.org; Mon, 27 Jan 2014 21:39:47 +1100 Message-ID: <52E63880.1010504@nteczone.com> Date: Mon, 27 Jan 2014 21:44:16 +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" 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: [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: Mon, 27 Jan 2014 10:44:23 -0000 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 From internet-drafts@ietf.org Mon Jan 27 02:56: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 B1F941A01E1; Mon, 27 Jan 2014 02:56: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 bBVsDr06CkQS; Mon, 27 Jan 2014 02:56:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F851A017A; Mon, 27 Jan 2014 02:56:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140127105616.4446.46325.idtracker@ietfa.amsl.com> Date: Mon, 27 Jan 2014 02:56:16 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-02.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, 27 Jan 2014 10:56:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-02.txt Pages : 46 Date : 2014-01-27 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-data-model-schema-02 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 rohanse2@cisco.com Mon Jan 27 06:57: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 55D3C1A0239 for ; Mon, 27 Jan 2014 06:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.436 X-Spam-Level: X-Spam-Status: No, score=-9.436 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_15=0.6, RP_MATCHES_RCVD=-0.535, 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 3Il4HZ94X3h4 for ; Mon, 27 Jan 2014 06:57:41 -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 708CA1A0237 for ; Mon, 27 Jan 2014 06:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2734; q=dns/txt; s=iport; t=1390834659; x=1392044259; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Ks6qI0Wz3txTOkXdUaZhonKnkm75/XaZY8ik4duAoCc=; b=dRlUpEs1p/hVJvQfaiIsPsPEn8NE86mzlM1vxR5l2rOFYg8hPiZ8QHlc YCfDbe5vJFYKIQYWNun9MSrarRgGZgw5gNppQ5uTa0gm2Cwz0aO5lr2IE csxJwlnTOzL4u0SGlMzsMKK520ReKTd/XfgHhcjOv3eyGru6VTBt965nR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFABNz5lKQ/khL/2dsb2JhbABZgww4vS2BEBZ0giUBAQEEAQEBNTYJAQ0ECxABAwECAQkWDwkDAgECARUoCBMGAgEBBYd8DcZqF48UBhCEIgSYJ4EyhRWLV4FvgT48 X-IronPort-AV: E=Sophos;i="4.95,729,1384300800"; d="scan'208";a="3582455" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 27 Jan 2014 14:57:37 +0000 Received: from [10.47.197.27] ([10.47.197.27]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0REvbbF027837 for ; Mon, 27 Jan 2014 14:57:37 GMT Message-ID: <52E67423.7010806@cisco.com> Date: Mon, 27 Jan 2014 14:58:43 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140126110537.25843.80724.idtracker@ietfa.amsl.com> <52E4ECA7.7020601@nteczone.com> In-Reply-To: <52E4ECA7.7020601@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Fwd: New Version Notification for draft-groves-clue-latent-config-00.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, 27 Jan 2014 14:57:43 -0000 Hi Christian, I think it looks good, though my initial question would be whether the benefits outweight the added complexity of CapNeg. The 'how much of an issue are the extra m=lines of the current approach' question is much the same we had when we were weighing using SDP against putting the information in CLUE; at the time most people felt the issues with using SDP m=lines were not particularly onerous (particularly if BUNDLE is used to ameleorate ICE costs and the like). This provides an intriguing way of using SDP and still avoiding some of those issues though (at the cost of more complicated SDP syntax). I'll have more specific comments and questions when I have had time to properly work through it. Rob On 26/01/2014 11:08, Christian Groves wrote: > Hello > > I've submitted a draft regarding the CLUE signalling proposing the use > of SDP latent configurations to describe the encodings. I think there > are some benefits over the use of a separate m-line for each encoding. > > Comments? > > Regards, Christian > > > -------- Original Message -------- > Subject: New Version Notification for > draft-groves-clue-latent-config-00.txt > Date: Sun, 26 Jan 2014 03:05:37 -0800 > From: internet-drafts@ietf.org > To: Weiwei Yang , "Weiwei Yang" > , "Roni Even" , Roni Even > , Christian Groves > , "Christian Groves" > > > > > A new version of I-D, draft-groves-clue-latent-config-00.txt > has been successfully submitted by Christian Groves and posted to the > IETF repository. > > Name: draft-groves-clue-latent-config > Revision: 00 > Title: CLUE and latent configurations > Document date: 2014-01-26 > Group: Individual Submission > Pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-groves-clue-latent-config-00.txt > Status: > https://datatracker.ietf.org/doc/draft-groves-clue-latent-config/ > Htmlized: > http://tools.ietf.org/html/draft-groves-clue-latent-config-00 > > > Abstract: > This document proposes to use Latent Configurations as described by > the SDP media capability negotiation framework [RFC6871] for the > description and negotiation of CLUE encodings. > > > > 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 pkyzivat@alum.mit.edu Mon Jan 27 15:06: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 C29AC1A03F7 for ; Mon, 27 Jan 2014 15:06:47 -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 ODZtcn8Dy8qg for ; Mon, 27 Jan 2014 15:06:46 -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 7BD7D1A03ED for ; Mon, 27 Jan 2014 15:06:46 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta06.westchester.pa.mail.comcast.net with comcast id K4tY1n00217dt5G56B6kGA; Mon, 27 Jan 2014 23:06:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id KB6j1n0103ZTu2S3ZB6jWW; Mon, 27 Jan 2014 23:06:44 +0000 Message-ID: <52E6E683.8090905@alum.mit.edu> Date: Mon, 27 Jan 2014 18:06:43 -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 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=1390864004; bh=b9RK+FAMRl7uatLee2+2usFS7hcLxtlvZVJIzBetflQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=p5TlLrGrZs8ncROoup07wLZuuV98gS9+FAMNjO0y2JcJ89a0HgrBfPy1Q/OgZAI2P /Axs3gRELfVShKsiEEGm539Lb4xtkcXZ+g52MhXkbaCBxuSerAPTyndttURrzypWBT codcJyXyRNob4zWOP4CCqY5jB87n8CsolUUHvi+rjTXRUGZ/5LCa3VU54bEI2ThWy2 7P5pjIfHTEL7P1TnLQCQqncpUaUper87LA9Q1lyEUfVaz4tckwANylP59yPbxhellC j4ePv6EV9Jg/CO+I4c5IwsM92fdtk267yPxYU1Sh+tIhiI7iif2x+e1jJJYR6FIG7T gMV3EQH7SK2Mw== Subject: [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, 27 Jan 2014 23:06:48 -0000 * 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 From Christian.Groves@nteczone.com Mon Jan 27 19:05: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 9EABB1A017F for ; Mon, 27 Jan 2014 19:05: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 sKgdF6dsoz-P for ; Mon, 27 Jan 2014 19:05:00 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0A61A0176 for ; Mon, 27 Jan 2014 19:05:00 -0800 (PST) Received: from ppp118-209-206-24.lns20.mel6.internode.on.net ([118.209.206.24]:56799 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W7yuP-0001yv-Iq for clue@ietf.org; Tue, 28 Jan 2014 14:00:17 +1100 Message-ID: <52E71E56.5070705@nteczone.com> Date: Tue, 28 Jan 2014 14:04:54 +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: <20140127105616.4446.46325.idtracker@ietfa.amsl.com> In-Reply-To: <20140127105616.4446.46325.idtracker@ietfa.amsl.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] I-D Action: draft-ietf-clue-data-model-schema-02.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, 28 Jan 2014 03:05:02 -0000 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. 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? 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. 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: Clause 10.6: Editorial nit: ...can be alternative a single media... 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. 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. 7. Clause 10.14 Language: As per above comment. Its now part of the framework. 8. Clause 10.17 Related to: As per above. Its now part of the framework. 9. Clause 10.?? The CLUE framework clause 7.2.1.3 has the synchronisation identity. This appears to be missing from the data model? 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? 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. 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. 13. Clauses 16/17/18: With the decision to use SDP for encodings could these sections be removed? Regards, Christian On 27/01/2014 9:56 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. > > Title : An XML Schema for the CLUE data model > Authors : Roberta Presta > Simon Pietro Romano > Filename : draft-ietf-clue-data-model-schema-02.txt > Pages : 46 > Date : 2014-01-27 > > 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-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Jan 27 19:09: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 B002B1A0179 for ; Mon, 27 Jan 2014 19:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=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 oubbl501yrWv for ; Mon, 27 Jan 2014 19:09:21 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCD01A0176 for ; Mon, 27 Jan 2014 19:09:21 -0800 (PST) Received: from ppp118-209-206-24.lns20.mel6.internode.on.net ([118.209.206.24]:56848 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W7yyd-0002dm-6G for clue@ietf.org; Tue, 28 Jan 2014 14:04:39 +1100 Message-ID: <52E71F5C.1070500@nteczone.com> Date: Tue, 28 Jan 2014 14:09:16 +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: <20140126110537.25843.80724.idtracker@ietfa.amsl.com> <52E4ECA7.7020601@nteczone.com> <52E67423.7010806@cisco.com> In-Reply-To: <52E67423.7010806@cisco.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] Fwd: New Version Notification for draft-groves-clue-latent-config-00.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, 28 Jan 2014 03:09:22 -0000 Hello Rob, Thanks for the comment. I think the difference to the question about extra m=lines vs putting it in CLUE is that the latest configuration method already exists and utilizes SDP. It means we that don't have to come up with our own CLUE syntax for encoding. We can simply use what is existing. Regards, Christian On 28/01/2014 1:58 AM, Robert Hansen wrote: > Hi Christian, > > I think it looks good, though my initial question would be whether the > benefits outweight the added complexity of CapNeg. > > The 'how much of an issue are the extra m=lines of the current > approach' question is much the same we had when we were weighing using > SDP against putting the information in CLUE; at the time most people > felt the issues with using SDP m=lines were not particularly onerous > (particularly if BUNDLE is used to ameleorate ICE costs and the like). > This provides an intriguing way of using SDP and still avoiding some > of those issues though (at the cost of more complicated SDP syntax). > > I'll have more specific comments and questions when I have had time to > properly work through it. > > Rob > > On 26/01/2014 11:08, Christian Groves wrote: >> Hello >> >> I've submitted a draft regarding the CLUE signalling proposing the use >> of SDP latent configurations to describe the encodings. I think there >> are some benefits over the use of a separate m-line for each encoding. >> >> Comments? >> >> Regards, Christian >> >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-groves-clue-latent-config-00.txt >> Date: Sun, 26 Jan 2014 03:05:37 -0800 >> From: internet-drafts@ietf.org >> To: Weiwei Yang , "Weiwei Yang" >> , "Roni Even" , Roni Even >> , Christian Groves >> , "Christian Groves" >> >> >> >> >> A new version of I-D, draft-groves-clue-latent-config-00.txt >> has been successfully submitted by Christian Groves and posted to the >> IETF repository. >> >> Name: draft-groves-clue-latent-config >> Revision: 00 >> Title: CLUE and latent configurations >> Document date: 2014-01-26 >> Group: Individual Submission >> Pages: 13 >> URL: >> http://www.ietf.org/internet-drafts/draft-groves-clue-latent-config-00.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-groves-clue-latent-config/ >> Htmlized: >> http://tools.ietf.org/html/draft-groves-clue-latent-config-00 >> >> >> Abstract: >> This document proposes to use Latent Configurations as described by >> the SDP media capability negotiation framework [RFC6871] for the >> description and negotiation of CLUE encodings. >> >> >> >> 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 > From Christian.Groves@nteczone.com Mon Jan 27 19:33: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 73EFE1A017F for ; Mon, 27 Jan 2014 19:33: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] 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 Nlzc_pPSfMlS for ; Mon, 27 Jan 2014 19:33:32 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B831A03D4 for ; Mon, 27 Jan 2014 19:33:31 -0800 (PST) Received: from ppp118-209-206-24.lns20.mel6.internode.on.net ([118.209.206.24]:57333 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W7zM1-0006Od-3p for clue@ietf.org; Tue, 28 Jan 2014 14:28:49 +1100 Message-ID: <52E72506.3080800@nteczone.com> Date: Tue, 28 Jan 2014 14:33:26 +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: <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 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, 28 Jan 2014 03:33:34 -0000 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. > > 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. > > 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? 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) > > * 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 Mon Jan 27 19:37: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 1B7BF1A026F for ; Mon, 27 Jan 2014 19:37: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 6FD9MOdNEiLm for ; Mon, 27 Jan 2014 19:37:22 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF4D1A017F for ; Mon, 27 Jan 2014 19:37:22 -0800 (PST) Received: from ppp118-209-206-24.lns20.mel6.internode.on.net ([118.209.206.24]:57381 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W7zPi-00070N-2K for clue@ietf.org; Tue, 28 Jan 2014 14:32:38 +1100 Message-ID: <52E725EB.3080601@nteczone.com> Date: Tue, 28 Jan 2014 14:37:15 +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: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@CRPMBOXPRD07.polycom.com> <52DF0AE9.1040509@nteczone.com> <52E00B42.5040409@alum.mit.edu> <52E073E1.4010305@nteczone.com> <52E134A3.8010609@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D01ECE4@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D01ECE4@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] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 28 Jan 2014 03:37:25 -0000 Hello Mark, In general I agree that this could be part of the data model but I think if we were to use this in the examples in the framework then we would also need to talk briefly about the label concept in the framework. Regards, Christian On 25/01/2014 3:15 AM, Duckworth, Mark wrote: > It sounds like a few of us are agreeing in principle that there could be better ways of expressing in an advertisement which captures can be included in an MCC rather than just giving a list of captures as part of the MCC description. > > For the framework document, I think it already covers as much detail that is appropriate for that document, basically this: > - in an advertisement, an MCC may contain a reference to the other media captures contained in the MCC > - in a configure message, an MCC may contain a reference to the other media captures the consumer wishes to receive as part of the MCC > > Details of the syntax for how to represent this should be in the data model. I don't think there are any other issues about this that belong in the framework. Our discussion about grouping labels and regular expressions should apply to the data model. Does this make sense? > > Mark > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, January 23, 2014 10:26 AM >> To: Christian Groves; Duckworth, Mark; clue@ietf.org >> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - >> allow wildcard? >> >> On 1/22/14 8:44 PM, Christian Groves wrote: >> >>>> When using labels, it would be easier to follow if the labels had >>>> some significance. E.g. labels like "left", "center", "right". >>> [CNG] Easier to follow for who? In terms of a consumer the labels are >>> really just related to the syntax so probably wouldn't be seen by a >>> person. I think in this case any random label would be sufficient. If >>> we want spatial significance better to use spatial parameters. >> In use I agree it doesn't matter. >> But in the *examples* it is easier if they have some significance. >> >> Thanks, >> Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Jan 27 19:46: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 DC3E41A0180 for ; Mon, 27 Jan 2014 19:46:24 -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 BSIOTJM4cFOd for ; Mon, 27 Jan 2014 19:46:22 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5D41A017F for ; Mon, 27 Jan 2014 19:46:21 -0800 (PST) Received: from ppp118-209-206-24.lns20.mel6.internode.on.net ([118.209.206.24]:57512 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W7zYQ-0000EI-Nc for clue@ietf.org; Tue, 28 Jan 2014 14:41:39 +1100 Message-ID: <52E72808.4040606@nteczone.com> Date: Tue, 28 Jan 2014 14:46:16 +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: <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> In-Reply-To: <52E00EE7.3020205@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] 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: Tue, 28 Jan 2014 03:46:25 -0000 Hello Paul, Please see below. Regards, Christian On 23/01/2014 5:33 AM, Paul Kyzivat wrote: > 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. [CNG] Its still spatial information of the captures in the scene so I can't see how its a "hack". > > 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. [CNG] I don't agree with that. I think that independent of any spatial arrangement its worthwhile for a Consumer to know whether its always going to receive the same number of sources (e.g.=) or whether it could get a changing number (e.g.<=). > > 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 > From christer.holmberg@ericsson.com Tue Jan 28 00:18: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 AF4781A02D2 for ; Tue, 28 Jan 2014 00:18:53 -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 QhG40cNSad8v for ; Tue, 28 Jan 2014 00:18:51 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9B81A0271 for ; Tue, 28 Jan 2014 00:18:50 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-ef-52e767e74726 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D6.D5.23809.7E767E25; Tue, 28 Jan 2014 09:18:47 +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, 28 Jan 2014 09:18:47 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? Thread-Index: Ac8cATohOVAlbIwKQYO2t8QqB7DbKgAAA3qw Date: Tue, 28 Jan 2014 08:18:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D143F4E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/mixed; boundary="_004_7594FB04B1934943A5C02806D1A2204B1D143F4EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM+Jvje7z9OdBBt/2qVrsP3WZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGe+7TjAVfLSvOLJ6BXsD4zKLLkZODgkBE4mbN9pZIGwxiQv3 1rN1MXJxCAkcYpRYPfc2K4SzmFGi/8VxoAwHB5uAhUT3P22QBhEBZYmjm/vZQGxhgTiJtx+/ sULE4yVONrSyQdhGEl23T4AtYBFQlTj2vYEFZAyvgK/EsyVaIGEhILNx80ywVk4BP4n3q9aC lTMC3fP91BomEJtZQFzi1pP5TBB3ikg8vHiaDcIWlXj5+B8ryEgJAUWJ5f1yEOWZEivPz2IH sXkFBCVOznzCMoFRZBaSSbOQlM1CUgYRz5e493sbM4StI7Fg9yc2CFtbYtnC18ww9pkDj5kw xXUljpw/xg5hK0q0bW8G6uUCslcwSjx5vBRqgTVQ0UpWmKIp3Q/ZFzDyrmJkz03MzEkvN9rE CIzag1t+q+5gvHNO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYw1nX ZjcpPbjw+/7iF6e38fCy3pM1fHuamYeFQT7YJUjtOc/PSVkJ0rOWeTxUSZ+2+cDfWTPun/Vc 0eqwxcKj89i5Z9fCQjJZ7eJsIsPZbRa/E1P7rzLxkufcVVUSgiypmqHzgw/u4p+7qcYhMqhb 7zyvU5quyqKdnV8vMfHOC/PaUnAmizdRiaU4I9FQi7moOBEAdP9HqagCAAA= Subject: [clue] FW: RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? 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, 28 Jan 2014 08:18:53 -0000 --_004_7594FB04B1934943A5C02806D1A2204B1D143F4EESESSMB209erics_ Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D143F4EESESSMB209erics_" --_000_7594FB04B1934943A5C02806D1A2204B1D143F4EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, One of the questions that came up yesterday, regarding the RTCWEB data chan= nel protocol, was whether both endpoints are mandated to send DATA_CHANNEL_= OPEN. I sent the e-mail below to the RTCWEB list, asking for clarification. NOTE that the DATA_CHANNEL_ACK is actually sent on the same SCTP stream whe= re DATA_CHANNEL_OPEN is received - EVEN if the SCTP stream is unidirectiona= l. This email is just fyi. If you have any comments/input, please use the rtcw= eb list :) Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 28. tammikuuta 2014 10:16 To: rtcweb@ietf.org Subject: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to s= end DATA_CHANNEL_OPEN? Hi, As defined in draft-ietf-rtcweb-data-channel-06, a data channel consists of= two unidirectional SCTP streams. draft-ietf-rtcweb-data-protocol-01 says that, if one endpoint wants to open= a data channel, it sends a DATA_CHANNEL_OPEN (using a SCTP stream ID value= of its choice). Then, the other endpoints sends DATA_CHANNEL_ACK on the sa= me SCTP stream (eventhough it is a unidirectional stream). Q1: Assuming that both endpoints want to use the data channel, do both endp= oints need to send DATA_CHANNEL_OPEN (on separate SCTP streams)? Or, can on= e of the endpoints, if it has received DCO, start using the data channel (u= sing a SCTP stream of its choice)? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D143F4EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,=

 

One of the questions t= hat came up yesterday, regarding the RTCWEB data channel protocol, was whet= her both endpoints are mandated to send DATA_CHANNEL_OPEN. I sent the e-mai= l below to the RTCWEB list, asking for clarification.

 

NOTE that the DATA_CHA= NNEL_ACK is actually sent on the same SCTP stream where DATA_CHANNEL_OPEN i= s received – EVEN if the SCTP stream is unidirectional.

 

This email is just fyi= . If you have any comments/input, please use the rtcweb list :)<= /span>

 

Regards,

 

Christer

 

 

 

 

From: rtcweb [= mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 28. tammikuuta 2014 10:16
To: rtcweb@ietf.org
Subject: [rtcweb] RTCWEB data channel protocol: Do both endpoints ne= ed to send DATA_CHANNEL_OPEN?

 

Hi,

 

As defined in draft-ietf-rtcweb-data-channel-06, a d= ata channel consists of two unidirectional SCTP streams.

 

draft-ietf-rtcweb-data-protocol-01 says that, if one= endpoint wants to open a data channel, it sends a DATA_CHANNEL_OPEN (using= a SCTP stream ID value of its choice). Then, the other endpoints sends DAT= A_CHANNEL_ACK on the same SCTP stream (eventhough it is a unidirectional stream).

 

Q1: Assuming that both endpoints want to use = the data channel, do both endpoints need to send DATA_CHANNEL_OPEN (on sepa= rate SCTP streams)? Or, can one of the endpoints, if it has received DCO, start using th= e data channel (using a SCTP stream of its choice)?

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D143F4EESESSMB209erics_-- --_004_7594FB04B1934943A5C02806D1A2204B1D143F4EESESSMB209erics_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Tue, 28 Jan 2014 08:16:33 GMT"; modification-date="Tue, 28 Jan 2014 08:16:33 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBt YWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWINCg== --_004_7594FB04B1934943A5C02806D1A2204B1D143F4EESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Jan 28 00:31: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 BD8631A0018 for ; Tue, 28 Jan 2014 00:31:04 -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 4pBnNNtCD-X2 for ; Tue, 28 Jan 2014 00:30:57 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 863401A02B6 for ; Tue, 28 Jan 2014 00:30:56 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-b2-52e76abd0951 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 39.65.04249.DBA67E25; Tue, 28 Jan 2014 09:30:53 +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; Tue, 28 Jan 2014 09:30:53 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: RTCWEB data channel protocol: Mandated to use? Thread-Index: Ac8cAngQ5gMoLtdxSK+NK5iG67ycPgAAIXmw Date: Tue, 28 Jan 2014 08:30:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D143FCA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D143FB4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D143FB4@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.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D143FCAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje7erOdBBlO2q1jsP3WZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGdfbuhkLnmpX7Fg6h62B8ZhaFyMnh4SAicTdjgPsELaYxIV7 69m6GLk4hASOMEp8ePmAGSQhJLCYUWLjNuMuRg4ONgELie5/2iBhEQFliaOb+9lAbGEBa4kf vyYyQsRtJFbcXsQCYRtJLLr3CqyGRUBVoqtrPxOIzSvgKzFn8Reo8b4Suz++B7M5BfwkPjVt B7MZge75fmoNWD2zgLjErSfzmSDuFJBYsuc8M4QtKvHy8T9WkNMkBJQkpm1NgyjPl7j97hQj xCpBiZMzn7BMYBSZhWTSLCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMHMWp xUm56UYGmxiBUXJwy2+LHYyX/9ocYpTmYFES5/341jlISCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA6Or7+SFwel1WtevaKzueHmZK/L4gVMBCfkZNV7PnHbnMG28xJQv7+JlFv+YZ0H+XIGt jmWnhJUZEvK2lsYcPmHF6FG24+fePT+WHOBKy5kR+f32pft2Ww8w1j+f0rCucvbux3w8WjNW n7d0vjNx8a0nBSciz6y+37Yse9KNaj6VMI05L6cc7+NTYinOSDTUYi4qTgQANPgRNWACAAA= Subject: [clue] FW: RTCWEB data channel protocol: Mandated to use? 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, 28 Jan 2014 08:31:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D143FCAESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, Another question that came up yesterday was whether RTCWEB mandates the usa= ge of the data channel protocol. I sent the e-mail below to RTCWEB, asking for clarification. Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 28. tammikuuta 2014 10:28 To: rtcweb@ietf.org Subject: [rtcweb] RTCWEB data channel protocol: Mandated to use? Hi, At the CLUE virtual interim yesterday, we discussed the usage of the RTCWEB= data channel also for CLUE. It would allow us to re-use what RTCWEB has do= ne, and it would provide interoperability between CLUE entities and RTCWEB. Q1: One question that came up is whether RTCWEB MANDATES the usage of the R= TCWEB data channel protocol? OR, is it possible to simply establish two SCT= P streams (as defined in draft-ietf-rtcweb-data-channel-06), and start usin= g it? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D143FCAESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,=

 

Another question that = came up yesterday was whether RTCWEB mandates the usage of the data channel= protocol.

 

I sent the e-mail belo= w to RTCWEB, asking for clarification.

 

Regards,

 

Christer

 

From: rtcweb [= mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 28. tammikuuta 2014 10:28
To: rtcweb@ietf.org
Subject: [rtcweb] RTCWEB data channel protocol: Mandated to use?

 

Hi,

 

At the CLUE virtual interim yesterday, we discussed = the usage of the RTCWEB data channel also for CLUE. It would allow us to re= -use what RTCWEB has done, and it would provide interoperability between CL= UE entities and RTCWEB.

 

Q1: One question that came up is whether RTCW= EB MANDATES the usage of the RTCWEB data channel protocol? OR, is it= possible to simply establish two SCTP streams (as defined in draft-ietf-rt= cweb-data-channel-06), and start using it?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D143FCAESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Jan 28 00: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 A8D7E1A02D0 for ; Tue, 28 Jan 2014 00:56:06 -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 lRkQni_mqgVG for ; Tue, 28 Jan 2014 00:56:04 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF421A026A for ; Tue, 28 Jan 2014 00:56:04 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-ac-52e770a00b5c Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 05.59.04853.0A077E25; Tue, 28 Jan 2014 09:56:01 +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; Tue, 28 Jan 2014 09:55:59 +0100 From: Christer Holmberg To: Christer Holmberg , "clue@ietf.org" Thread-Topic: RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? Thread-Index: Ac8cATohOVAlbIwKQYO2t8QqB7DbKgAAA3qwAAFQOsA= Date: Tue, 28 Jan 2014 08:55:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D144111@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D143F4E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D143F4E@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.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D144111ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje7CgudBBiue81nsP3WZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGS9nr2MtOBdQMevADMYGxgduXYycHBICJhLLnl9hg7DFJC7c Ww9mCwmcYJR4/Uqvi5ELyF7MKNGz6yp7FyMHB5uAhUT3P22QGhGBSInD6/4xgtjCAnESSzd9 YoWIx0ucbGhlg7CtJF5dbmEBsVkEVCUeb9vKDGLzCvhKfDp0gwli/kRGiZ9PpjCBJDgF/CSe 9e0Ba2YEOuj7qTVgcWYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wgt0kIKElM25oGUZ4vsff1 PqhdghInZz5hmcAoMgvJpFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGCWL U4uLc9ONDPRy03NL9FKLMpOLi/Pz9IpTNzECI+nglt9GOxhP7rE/xCjNwaIkznudtSZISCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6PVskV7z60uSu/a9f3CvCeLL9edC/GeeGbdC71LHRs8 /HXZHyqusYj8UK3nHhsnyajEk812iOfSrs6NZmELtj98tOXAh90Lfzf1bK7M/HI/vDH/xGeT RX9i4pnXHZxg7d/28sQCjct2NddatqVN7xWU1f6Z+UY592uSUsDff//q1J6fbz53+YC+Ektx RqKhFnNRcSIARtdWe3ICAAA= Subject: Re: [clue] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? 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, 28 Jan 2014 08:56:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D144111ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Correction: the DATA_CHANNEL_ACK is NOT sent on the same SCTP stream, but t= he same stream ID is used. As you may have seen on the RTCWEB list, it has been clarified that both en= dpoints do NOT have to send DATA_CHANNEL_OPEN. So, that was a misunderstand= ing from my part yesterday. Sorry for the confusion. Regards, Christer From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 28. tammikuuta 2014 10:19 To: clue@ietf.org Subject: [clue] FW: RTCWEB data channel protocol: Do both endpoints need to= send DATA_CHANNEL_OPEN? FYI, One of the questions that came up yesterday, regarding the RTCWEB data chan= nel protocol, was whether both endpoints are mandated to send DATA_CHANNEL_= OPEN. I sent the e-mail below to the RTCWEB list, asking for clarification. NOTE that the DATA_CHANNEL_ACK is actually sent on the same SCTP stream whe= re DATA_CHANNEL_OPEN is received - EVEN if the SCTP stream is unidirectiona= l. This email is just fyi. If you have any comments/input, please use the rtcw= eb list :) Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 28. tammikuuta 2014 10:16 To: rtcweb@ietf.org Subject: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to s= end DATA_CHANNEL_OPEN? Hi, As defined in draft-ietf-rtcweb-data-channel-06, a data channel consists of= two unidirectional SCTP streams. draft-ietf-rtcweb-data-protocol-01 says that, if one endpoint wants to open= a data channel, it sends a DATA_CHANNEL_OPEN (using a SCTP stream ID value= of its choice). Then, the other endpoints sends DATA_CHANNEL_ACK on the sa= me SCTP stream (eventhough it is a unidirectional stream). Q1: Assuming that both endpoints want to use the data channel, do both endp= oints need to send DATA_CHANNEL_OPEN (on separate SCTP streams)? Or, can on= e of the endpoints, if it has received DCO, start using the data channel (u= sing a SCTP stream of its choice)? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D144111ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Correction: the DATA_C= HANNEL_ACK is NOT sent on the same SCTP stream, but the same stream ID is u= sed.

 

As you may have seen o= n the RTCWEB list, it has been clarified that both endpoints do NOT have to= send DATA_CHANNEL_OPEN. So, that was a misunderstanding from my part yeste= rday. Sorry for the confusion.

 

Regards,

 

Christer

 

From: clue [ma= ilto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 28. tammikuuta 2014 10:19
To: clue@ietf.org
Subject: [clue] FW: RTCWEB data channel protocol: Do both endpoints = need to send DATA_CHANNEL_OPEN?

 

FYI,=

 

One of the questions t= hat came up yesterday, regarding the RTCWEB data channel protocol, was whet= her both endpoints are mandated to send DATA_CHANNEL_OPEN. I sent the e-mai= l below to the RTCWEB list, asking for clarification.

 

NOTE that the DATA_CHA= NNEL_ACK is actually sent on the same SCTP stream where DATA_CHANNEL_OPEN i= s received – EVEN if the SCTP stream is unidirectional.

 

This email is just fyi= . If you have any comments/input, please use the rtcweb list :)<= /span>

 

Regards,

 

Christer

 

 

 

 

From: rtcweb [= mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 28. tammikuuta 2014 10:16
To: rtcweb@ietf.org
Subject: [rtcweb] RTCWEB data channel protocol: Do both endpoints ne= ed to send DATA_CHANNEL_OPEN?

 

Hi,

 

As defined in draft-ietf-rtcweb-data-channel-06, a d= ata channel consists of two unidirectional SCTP streams.

 

draft-ietf-rtcweb-data-protocol-01 says that, if one= endpoint wants to open a data channel, it sends a DATA_CHANNEL_OPEN (using= a SCTP stream ID value of its choice). Then, the other endpoints sends DAT= A_CHANNEL_ACK on the same SCTP stream (eventhough it is a unidirectional stream).

 

Q1: Assuming that both endpoints want to use = the data channel, do both endpoints need to send DATA_CHANNEL_OPEN (on sepa= rate SCTP streams)? Or, can one of the endpoints, if it has received DCO, start using th= e data channel (using a SCTP stream of its choice)?

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D144111ESESSMB209erics_-- From spromano@unina.it Tue Jan 28 01:54: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 A82361A0376 for ; Tue, 28 Jan 2014 01:54:27 -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 qirOaQa0BROb for ; Tue, 28 Jan 2014 01:54:26 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id E48991A0361 for ; Tue, 28 Jan 2014 01:54:25 -0800 (PST) Received: from 1-160-241-11.dynamic.hinet.net ([91.252.216.105]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s0S9sHw8005091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 28 Jan 2014 10:54:18 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D144111@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D142F0D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D143F4E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D144111@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----1CA7HJYGLAYFJ1UJ7M61NES8G591NG" From: Simon Pietro Romano Date: Tue, 28 Jan 2014 10:49:12 +0100 To: Christer Holmberg , "clue@ietf.org" Message-ID: Subject: Re: [clue] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN? 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, 28 Jan 2014 09:54:27 -0000 ------1CA7HJYGLAYFJ1UJ7M61NES8G591NG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This was indeed what I said yesterday during the interim... Simon Christer Holmberg ha scritto: >Hi, > >Correction: the DATA_CHANNEL_ACK is NOT sent on the same SCTP stream, >but the same stream ID is used. > >As you may have seen on the RTCWEB list, it has been clarified that >both endpoints do NOT have to send DATA_CHANNEL_OPEN. So, that was a >misunderstanding from my part yesterday. Sorry for the confusion. > >Regards, > >Christer > >From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer >Holmberg >Sent: 28. tammikuuta 2014 10:19 >To: clue@ietf.org >Subject: [clue] FW: RTCWEB data channel protocol: Do both endpoints >need to send DATA_CHANNEL_OPEN? > >FYI, > >One of the questions that came up yesterday, regarding the RTCWEB data >channel protocol, was whether both endpoints are mandated to send >DATA_CHANNEL_OPEN. I sent the e-mail below to the RTCWEB list, asking >for clarification. > >NOTE that the DATA_CHANNEL_ACK is actually sent on the same SCTP stream >where DATA_CHANNEL_OPEN is received - EVEN if the SCTP stream is >unidirectional. > >This email is just fyi. If you have any comments/input, please use the >rtcweb list :) > >Regards, > >Christer > > > > >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer >Holmberg >Sent: 28. tammikuuta 2014 10:16 >To: rtcweb@ietf.org >Subject: [rtcweb] RTCWEB data channel protocol: Do both endpoints need >to send DATA_CHANNEL_OPEN? > >Hi, > >As defined in draft-ietf-rtcweb-data-channel-06, a data channel >consists of two unidirectional SCTP streams. > >draft-ietf-rtcweb-data-protocol-01 says that, if one endpoint wants to >open a data channel, it sends a DATA_CHANNEL_OPEN (using a SCTP stream >ID value of its choice). Then, the other endpoints sends >DATA_CHANNEL_ACK on the same SCTP stream (eventhough it is a >unidirectional stream). > >Q1: Assuming that both endpoints want to use the data channel, do both >endpoints need to send DATA_CHANNEL_OPEN (on separate SCTP streams)? >Or, can one of the endpoints, if it has received DCO, start using the >data channel (using a SCTP stream of its choice)? > >Regards, > >Christer > > > > >------------------------------------------------------------------------ > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue ------1CA7HJYGLAYFJ1UJ7M61NES8G591NG Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit This was indeed what I said yesterday during the interim...

Simon

Christer Holmberg <christer.holmberg@ericsson.com> ha scritto:

Hi,

 

Correction: the DATA_CHANNEL_ACK is NOT sent on the same SCTP stream, but the same stream ID is used.

 

As you may have seen on the RTCWEB list, it has been clarified that both endpoints do NOT have to send DATA_CHANNEL_OPEN. So, that was a misunderstanding from my part yesterday. Sorry for the confusion.

 

Regards,

 

Christer

 

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 28. tammikuuta 2014 10:19
To: clue@ietf.org
Subject: [clue] FW: RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN?

 

FYI,

 

One of the questions that came up yesterday, regarding the RTCWEB data channel protocol, was whether both endpoints are mandated to send DATA_CHANNEL_OPEN. I sent the e-mail below to the RTCWEB list, asking for clarification.

 

NOTE that the DATA_CHANNEL_ACK is actually sent on the same SCTP stream where DATA_CHANNEL_OPEN is received – EVEN if the SCTP stream is unidirectional.

 

This email is just fyi. If you have any comments/input, please use the rtcweb list :)

 

Regards,

 

Christer

 

 

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 28. tammikuuta 2014 10:16
To: rtcweb@ietf.org
Subject: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN?

 

Hi,

 

As defined in draft-ietf-rtcweb-data-channel-06, a data channel consists of two unidirectional SCTP streams.

 

draft-ietf-rtcweb-data-protocol-01 says that, if one endpoint wants to open a data channel, it sends a DATA_CHANNEL_OPEN (using a SCTP stream ID value of its choice). Then, the other endpoints sends DATA_CHANNEL_ACK on the same SCTP stream (eventhough it is a unidirectional stream).

 

Q1: Assuming that both endpoints want to use the data channel, do both endpoints need to send DATA_CHANNEL_OPEN (on separate SCTP streams)? Or, can one of the endpoints, if it has received DCO, start using the data channel (using a SCTP stream of its choice)?

 

Regards,

 

Christer

 

 


clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue
------1CA7HJYGLAYFJ1UJ7M61NES8G591NG-- From christer.holmberg@ericsson.com Tue Jan 28 05:55: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 ADEDB1A03FE for ; Tue, 28 Jan 2014 05:55:59 -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 ByQglJ9hss2U for ; Tue, 28 Jan 2014 05:55:57 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8B1A03F5 for ; Tue, 28 Jan 2014 05:55:56 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-f1-52e7b6e80b23 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id DF.97.04853.8E6B7E25; Tue, 28 Jan 2014 14:55:53 +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; Tue, 28 Jan 2014 14:55:52 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5A== Date: Tue, 28 Jan 2014 13:55:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D145B94@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_7594FB04B1934943A5C02806D1A2204B1D145B94ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvje7Lbc+DDH5fZ7TYf+oyswOjx5Il P5kCGKO4bFJSczLLUov07RK4Mm49m8dY0KpVMf3ANsYGxtfKXYycHBICJhLP5/9igbDFJC7c W8/WxcjFISRwglHiVctOZghnMaPEz9sXmboYOTjYBCwkuv9pgzSICChLHN3czwZiCwuoSaxp OMICEdeWePz/PDOErSfRfPISWA2LgKrEjj132UFsXgFfie4Nr8BsRqDF30+tYQKxmQXEJW49 mc8EcZCAxJI9EHMkBEQlXj7+xwphK0pcnb4cqj5fon/JPDaImYISJ2c+YZnAKDQLyahZSMpm ISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxgli1OLi3PTjQz0ctNzS/RSizKTi4vz 8/SKUzcxAmPj4JbfRjsYT+6xP8QozcGiJM57nbUmSEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAOj/7Rrn0MbYoM3Rwll/36WrpT4+9r5zgfXDmgElmUt0m9lY5b+ss5nsXj+65B9l2uvn6p/ zHtqwfeqtdEtiS/u3s1WnDPD+OplC1m9k5/j7lv0CW7mffw54eqG79K6x1JPrVHfsPORfKLa 4q0qJo17nxfVSJ2UuPzE81Pxpa2b7yfG/Fosuq8wQYmlOCPRUIu5qDgRAC1h4wpbAgAA Subject: [clue] RTCWEB data channel for CLUE? 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, 28 Jan 2014 13:55:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D145B94ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As those of you who attended the virtual meeting yesterday know, I presente= d a suggestion for using the rtcweb data channel for transporting the CLUE = protocol messages. We recognized that there ARE a few things that need to be sorted out and cl= arified (you may have seen the e-mails I've sent to the rtcweb- and mmusic = lists), but in general I think we should decide (or, at least making a work= ing assumption) whether we'll use the rtcweb mechanism. Again, there are details that need to be sorted out, and we can always reve= rse any decision we make. But, I do NOT want to wait until London for makin= g a decision in the first place. I want us to sort out details and open iss= ues in London. Personally I think that having interoperability with rtcweb is extremely va= luable - unless, of course, it causes a great burden for CLUE, or unless th= e mechanism is technically unfeasible for CLUE. So far I have not heard any= indication of either, and we also saw a demo showing that it is possible t= o use the mechanism. I also don't think that, due to the dependency on rtcweb that such decision= would create, there is a big risk of CLUE being delayed. In my opinion, th= e data channel mechanism is probably the most stable thing of the things rt= cweb is currently working on. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D145B94ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As those of you who attended the virtual meeting yes= terday know, I presented a suggestion for using the rtcweb data channel for= transporting the CLUE protocol messages.

 

We recognized that there ARE a few things that need = to be sorted out and clarified (you may have seen the e-mails I’ve se= nt to the rtcweb- and mmusic lists), but in general I think we should decid= e (or, at least making a working assumption) whether we’ll use the rtcweb mechanism.

 

Again, there are details that need to be sorted out,= and we can always reverse any decision we make. But, I do NOT want to wait= until London for making a decision in the first place. I want us to sort o= ut details and open issues in London.

 

Personally I think that having interoperability with= rtcweb is extremely valuable – unless, of course, it causes a great = burden for CLUE, or unless the mechanism is technically unfeasible for CLUE= . So far I have not heard any indication of either, and we also saw a demo showing that it is possible to use the m= echanism.

 

I also don’t think that, due to the dependency= on rtcweb that such decision would create, there is a big risk of CLUE bei= ng delayed. In my opinion, the data channel mechanism is probably the most = stable thing of the things rtcweb is currently working on.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D145B94ESESSMB209erics_-- From Mark.Duckworth@polycom.com Tue Jan 28 09:21: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 753D81A0158 for ; Tue, 28 Jan 2014 09:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 GaY7OHEcGzMY for ; Tue, 28 Jan 2014 09:20:48 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id C5C651A026A for ; Tue, 28 Jan 2014 09:20:47 -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; Tue, 28 Jan 2014 09:20:45 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 28 Jan 2014 09:20:44 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 28 Jan 2014 09:20:42 -0800 Thread-Topic: [clue] spatial information can't describe video locations within composed MCC Thread-Index: Ac8XoH/yY4MpDhX0Q0Kr7cwR8wt2qgALysLQAR8xnNA= Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D0F8123@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> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D01E6DF@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_49E45C59CA48264997FEBFB29B6BC2D60C9D0F8123CRPMBOXPRD07p_" MIME-Version: 1.0 Subject: Re: [clue] 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: Tue, 28 Jan 2014 17:21:00 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D0F8123CRPMBOXPRD07p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 with= in composed MCC Hi Paul, Paul wrote: "Lets first discuss if having this information would provide si= gnificant 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 wi= thin > 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 composi= tion. > > 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 th= e > 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 declarat= ion of > the MCC to explicitly do it. > > But I don't really see the point of doing so. What can the consumer do wh= en > 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 would giv= e > > 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 v= alue. 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 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=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 --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D0F8123CRPMBOXPRD07p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mary and Paul, could you please let us know if consensus is r= eached on this topic?

 

At the interim meeting Jan 27, we reaffirmed the dec= ision noted in Tick= et #5, meaning the group does not want to attempt to use CLUE to descri= be composed captures, particularly the layout of individual video images wi= thin 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 Beha= lf 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,

&nb= sp;

Paul wrote: "Lets first discuss i= f having this information would provide significant value. If so then we ca= n discuss how to provide it."

 

Yes, but we already did that, an= d decided it isn’t valuable enough to work on as part of CLUE.  = This was Ticket #5<= /a>.  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 ca= n't describe video locations within

&= gt; composed MCC

>

=

> On 1/21/14 6:39 PM, Christian Groves wrote:

> > Hello Mark,

> >

> &= gt; 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

&g= t; > provides the encoding for MCC1 not the constituent captures. Wherea= s

> > 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 Capt= ure Scene. The

> > Advertiser h= as provided the spatial positions of VC1 being left. VC2

> > being centre and VC3 being right. That is the= ir 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 differe= ntly. (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 informati= on associated

> > with an indiv= idual 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 inf= ormation in

> > individual enco= dings in MCCs only when those individual encodings are

> MCCs?

> >= ;

> > E.g. taking your example = below.

> >

> > Scene 1

&= gt; > VC1 - left

> > VC2 - c= enter

> > 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 real= ly see the point of doing so. What can the consumer do when

<= p class=3DMsoPlainText>> it has this info that it wouldn't be able to do= without it?

>

> > In order to address the maxCaptures issue per= haps we need to modify

> > &quo= t;MaxCaptures" slightly so that it becomes "NumberofCaptures"= ; where we

> > could say Number= ofCaptures=3D3 or NumberofCaptures<=3D3. This would give

<= p class=3DMsoPlainText>> > more certainty to the Consumer about what = will actually be sent.

>

> That is just another step towards descri= bing the complete layout of the

> = composition.

>

> Lets first discuss if having this information woul= d provide significant value. If

> = so then we can discuss how to provide it.

>

>    &nb= sp;        Thanks,

>          = ;   Paul

>

> > Regards, Christian

> >

> >=

> > On 21/01/2014 11:54 PM, Du= ckworth, Mark wrote:

> >> He= llo Christian,

> >>

> >> I still don't see how the consu= mer can tell anything about how an MCC

> >> is composed.  Take this example,

> >>

> &= gt;> Scene 1

> >> VC1 - l= eft

> >> VC2 - center

> >> VC3 - right

> >> MCC1 (VC1, VC2, VC3) - whole scene, maxC= aptures=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 h= ow 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 i= nformation for

> >> the capt= ures themselves.

> >>

> >> Mark

> >>

> &g= t;>> -----Original Message-----

> >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of C= hristian

> >>> Groves

> >>> Sent: Monday, January = 20, 2014 6:02 PM

> >>> To= : clue@ietf.org

> >>> Sub= ject: Re: [clue] spatial information can't describe video

> >>> locations within composed MCC

> >>>

> >>> Hello Mark and Paul,

> >>>

>= ; >>> Please see my responses below.

> >>>

> >&= gt;> Regards, Christian

> >&= gt;>

> >>> On 21/01/20= 14 8:29 AM, Duckworth, Mark wrote:

&g= t; >>>> Christian,

> &= gt;>>>

> >>>>= I agree with Paul.

> >>>= >

> >>>> Christian = wrote: "I cannot see why in the static case spatial

> >>>> information isn't

<= p class=3DMsoPlainText>> >>> valid? In the static case the conc= erns 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

> >>> ca= se" or not?  I don't see any way for the consumer to know this.

> >>> [CNG] The consumer k= nows 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] spati= al information can't describe video

&= gt; >>>>> locations within composed MCC

> >>>>>

> >>>>> On 1/19/14 9:36 PM, Christian Groves wrote= :

> >>>>>> Hello= Mark,

> >>>>>><= o:p>

> >>>>>> Sorry f= or the delayed response. I was on vacation last week. I

> >>>>>> see there's been quite a l= ot of activity over the last week with

> >>>>>> respect to MCCs and the framework.

> >>>>>>

<= p class=3DMsoPlainText>> >>>>>> I saw the minutes of t= he meeting and saw there was a mention that

> >>>>>> I should argue :-).

> >>>>>>

> >>>>>> I don't agree with the outcome o= f the meeting. I think its

> >&= gt;>>>> important to note that MCC doesn't equal switching. A M= CC may

> >>>>>> = represent a dynamic switching case OR a static case. A static

> >>>>>> case may be that a M= CU offers a single stream where three

> >>>>>> captures from an endpoint on separate stream= s are composed into

> one video st= ream.

> >>>>> Yes, = we had that in mind when discussing this.

> >>>>>

> &= gt;>>>>> I cannot see why in the

> >>>>>> static case spatial information is= n't valid? In the static case

> &g= t;>>>>> the concerns of 2, 3 and 4 don't apply.

> >>>>> We may not have underst= ood you. We were guessing what you

&g= t; meant.

> >>>>>

> >>>>> Suppose ther= e is an MCC that has three input captures, and

> >>>>> composes

> >>> them.

> = >>>>> It could compose them in many ways. It could put the t= hree side by

> >>>>>= ; side, or one big one and two as picture-in-picture overlays, or ...<= /o:p>

> >>>>> And even with th= ree side by side, they could be in any order.

> >>> [CNG] Yes

= > >>>>> And the source captures could all be from multipl= e scenes or one,

> >>>>= ;> and if one, it could be the same one as the MCC or not. The

> >>>>> simplest case is tha= t they are all from the same scene as the MCC.

> >>>>> But even then, the coordinates of the s= ource captures are

> >>>&= gt;> presumably meaningful if they are individually configured. We<= /o:p>

> >>>>> could see no rea= son to presume that their arrangement in the scene

> >>>>> has anything to do with their

> >>> arrangement in the MCC= .

> >>> [CNG] Paul you me= ntioned the idea of a virtual scene before. What I

> >>> see an MCU doing is creating a virtual sc= ene using these source

> >>&= gt; captures.

> >>> Givin= g Captures spatial co-ordinates within a virtual scene is a

<= p class=3DMsoPlainText>> >>> valid thing to do irrespective of = the use of a MCC. The MCU may

> &g= t;>> 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 severa= l sources

> >>> using a M= CC I can't see why it cannot indicate the spatial position

> >>> of the sources in the MCC as they a= lso reside in the virtual space.

>= >>>>> So we need more info to understand your perspective o= n this.

> >>>>>

> >>>>>>  = ;  From the minutes I didn't see an explanation of other people's=

> >>> concerns.

> >>>>>> So rather than a com= plete prohibition of the spatial information

> >>>>>> regarding individual captures I think= it would be better to

> >>&= gt;>>> explain that the Advertiser has a choice to include the

> >>>>>> informatio= n 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 co= mmented 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 adverti= ser, 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 Advert= iser constructs

> >>> the= scene, it give the spatial positioning. If the MCC and non-MCC<= /p>

> >>> 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<= o:p>

> >>>>> 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 Ad= vertiser shouldn't provide this information

> >>> unless it also provides a means for the Consumer t= o determine when

> >>> th= e 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 witho= ut the need to

> >>> set = it on the sources.

> >>>&= gt;> But none of that has anything to do with the the arrangement of

> >>>>> composed captu= res within an MCC.

> >>> = [CNG] I don't understand the point. You only focused on the switched

> >>> case.

> >>> MCC is for switching and composition.<= o:p>

> >>>>>  =        Thanks,

> >>>>>       =   Paul

> >>>>>=

> >>>>>> Regard= s, Christian

> >>>>>= ;>

> >>>>>> O= n 18/01/2014 9:50 AM, Duckworth, Mark wrote:

> >>>>>>> We discussed this topic in the de= sign team meeting Jan 14

> >>= ;>>>>> <http://trac.tools.ietf.org/wg/clue/trac/attachmen= t/wiki/Design-

> >>>>&= gt; Team/minutes_140114.txt>.

>= >>>>>>>   From the minutes:

<= p class=3DMsoPlainText>> >>>>>>>

> >>>>>>> "Conclusion 1: S= patial 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 cons= ensus before clarifying the framework about this.

> >>>>>>> Christian, or anybody else, = do you still want more discussion?

&g= t; >>>>>>>

> = >>>>>>> Regards,

> >>>>>>> Mark

> >>>>>>>

= > >>>>>>>> -----Original Message-----=

> >>>>>>>> From: clu= e [mailto:clue-bounces@ietf.org] On Behalf Of

> >>>>>>>> Duckworth, Mark

> >>>>>>>> Sent: Frida= y, January 10, 2014 4:04 PM

> >= >>>>>>> To: Christian Groves; clue@ietf.org=

> >>>>>>>> Subject: = Re: [clue] spatial information can't describe video

> >>>>>>> locations within

> >>>>>>><= /p>

> >>>>>>>> composed M= CC

> >>>>>>>&= gt; Thanks Christian, that is an improvement. But I'm still not<= /p>

> >>>>>>> convinced the<= o:p>

> >>>>>>>

> >>>>>>>> co= nsumer can always tell when the spatial attributes are

> >>>>>>>> meaningful

> >>>>>>> (even<= /o:p>

> >>>>>>>

> >>>>>>>> within = a scene) for discerning how contributors to a composed

> >>>>>>>> MCC are arranged wi= thin the MCC. My concerns 2, 3, and 4 below

> >>>>>>>> still apply.

> >>>>>>>> Does anybody els= e have input to this topic?

> >= >>>>>>> Mark

>= ; >>>>>>>>> -----Original Message-----

> >>>>>>>>> From= : Christian Groves [mailto:Christian.Groves@nteczone.com]

> >>>>>>>>> Sent: Thursd= ay, January 09, 2014 9:19 PM

> >= ;>>>>>>>> To: Duckworth, Mark; clue@ietf.org

> >>>>>>>>> S= ubject: Re: [clue] spatial information can't describe video

<= p class=3DMsoPlainText>> >>>>>>> locations

> >>>>>>><= /p>

> >>>>>>>>> within= composed MCC

> >>>>&g= t;>>>> Hello Mark,

> &= gt;>>>>>>>> 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 prov= ider

> >>>>>>>= ;>> should avoid providing conflicting attribute values between<= /o:p>

> >>>>>>>>> = the MCC and Single Media Captures. Where there is conflict the

> >>>>>>>>> attribu= tes of the MCC override any that may be present in the

> individual captures.

> >>>>>>>>> <<When assigning spa= tial attributes to individual captures

> >>>>>>>>> within a MCC and/or to the MCC = itself the Provider should be

> &g= t;>>>>>>>> aware that spatial attributes have no re= lation across Capture

> Scenes.

> >>>>>>>>&g= t; Therefore

> >>>>>= ;>>>> if the Provider intends to provide a spatial relation bet= ween

> >>>>>>>= ;>> the source Captures and the MCC then these MUST be part of

> the

> >>>>>>>>> same

> >>>>>>>> Capture Scene.

> >>>>>>>>> W= hen assigning spatial information that would cause the

> >>>>>>>>> spatial positio= ning of the source Capture to move within the

> >>>>>>>>> MCC, the

<= p class=3DMsoPlainText>> >>>>>>> Provider

> >>>>>>>

> >>>>>>>>> should = also be aware that a Consumer may not be able to

> >>>>>>>>> determine<= /p>

> >>>>>>> that

> >>>>>>>

> >>>>>>>>> the sou= rce captures have moved.>> ...

= > >>>>>>>>> Regards, Christian

=

> >>>>>>>>> On 8/01/2= 014 12:18 AM, Duckworth, Mark wrote:

= > >>>>>>>>>> Hello Christian,

> >>>>>>>>>> So = there are only certain circumstances in which spatial

> >>>>>>> information

> >>>>>>>

<= p class=3DMsoPlainText>> >>>>>>>>>> for

> >>>>>>>>&g= t; components of a composed capture is relevant. For the case

> >>>>>>>>> where yo= u think it is important and relevant, can you please

> >>>>>>>>> propose text for = the framework to describe this? I think the

> >>>>>>>>> framework should be more c= lear about when and how the

> cons= umer

> >>>>>>>= ;>> can use

> >>> t= his

> >>>>>>>= >> information for composed captures.

> >>>>>>>>>> Mark

> >>>>>>>>>>> ----= -Original Message-----

> >>&= gt;>>>>>>>> From: clue [mailto:clue-bounces@ietf.or= g] On Behalf Of

> >>>>= >>>>>>> Christian Groves

> >>>>>>>>>>> Sent: Tuesday, J= anuary 07, 2014 12:08 AM

> >>= ;>>>>>>>>> To: clue@ietf.org

> >>>>>>>>>>> Subjec= t: Re: [clue] spatial information can't describe video

> >>>>>>>>>>> locatio= ns within composed MCC Hello Mark, I agree with

> >>>>>>>>>>> respect to the= fact that spatial information isn't valid

> >>>>>>>>>>> across Capture Scen= es. i.e. If I have an MCC in one

>= >>>>>>> Cap.Scene

> >>>>>>>

= > >>>>>>>>>>> referencing individual ca= ptures from other scenes. However I

&= gt; >>>>>>>>>>> think there is a valid cas= e where an MCC can reference

> >= ;>>>>>>>>>> Individual captures from the same= scene as it. In this case

> >&= gt;>>>>>>>>> I think the

> >>>>>>> use of

> >>>>>>>

> >>>>>>>>>>> spatial<= o:p>

> >>>>>>>>= > information is valid, i.e.

> = >>>>>>>>>>> +-----------------------+-----= ----------------------------+

> &g= t;>>>>>>>>>> | Capture Scene #1 | |

> >>>>>>>>>>&= gt; +-----------------------|---------------------------------+<= /p>

> >>>>>>>>>>>= ; | VC1 | CapArea=3DLeft |

> >&= gt;>>>>>>>>> | VC2 | CapArea=3DRight |

> >>>>>>>>>>&= gt; | MCC1(VC1, VC2) | |

> >>= ;>>>>>>>>> +------------------------------------= ---------------------+

> >>&= gt;>>>>>>>> or

> >>>>>>>>>>> +----------------------= -+---------------------------------+

= > >>>>>>>>>>> | Capture Scene #1 | |

> >>>>>>>>&g= t;>> +-----------------------|---------------------------------+=

> >>>>>>>>>= >> | MCC1(VC1) | CapArea=3DLeft |

> >>>>>>>>>>> | MCC2(VC2) | CapArea= =3DRight |

> >>>>>&= gt;>>>>> | MCC1(MCC1,MCC2) | |

> >>>>>>>>>>> +---------------= ------------------------------------------+

> >>>>>>>>>>> where VC1 and VC2 = are from different Capture Scenes.

&g= t; >>>>>>>>>>> There are of course cases w= here the spatial information

> >= ;>>>>>> wouldn't be

> >>>>>>>

&g= t; >>>>>>>>>>> valid but in those cases th= e Provider wouldn't provide them,

>= ; >>>>>>>>>>> i.e.

> >>>>>>>>>>> where the= individual captures move. However there will be

> >>>>>>>>>>> cases where t= he composition is static and the information

> >>>>>>>>>>> would be

> >>>>>>> valid.=

> >>>>>>>

> >>>>>>>>>>= ;> I don't think we can make a general assumption that the

> >>>>>>>>>>> = spatial information is

> >>&= gt;>>>>>> valid or invalid in all cases.

> >>>>>>>>>>> Reg= ards, Christian

> >>>>= >>>>>>> On 7/01/2014 7:54 AM, Duckworth, Mark wrote:

> >>>>>>>>&= gt;>>> Framework version 13 says a provider can use spatial

> >>>>>>>>>&g= t;>> information of source media captures to describe how those<= /o:p>

> >>>>>>>>>&= gt;>> sources are placed within a composed multiple content

> >>>>>>>>>>&= gt;> capture (MCC). In general I think this won't work, and I'm

> >>>>>>>>>>= >> not even sure under what specific conditions it might work.

> >>>>>>>>>&g= t;>> So I propose removing that part, and instead add text to

> >>>>>>>>>>= ;>> say the spatial information of individual captures does not<= /o:p>

> >>>>>>>>>&= gt;>> relate to its relative position within a

> >>>>>>> composed

> >>>>>>>

> >>>>>>>> MCC.

> >>>>>>>>>>>&= gt;   From section 7.2.1:

&= gt; >>>>>>>>>>>> For example: The spati= al related attributes can be further

= > >>>>>>> used to

> >>>>>>>

> >>>>>>>>>>>> determine how the i= ndividual captures "appear" within a

> >>>>>>>>>>>> stream. A v= irtual scene could be constructed for the MCC

> >>>>>>>>>>>> capture with= two Video Captures with a "MaxCaptures"

> >>>>>>>>>>>> attri= bute 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"

> >>>>>>>

> >>>>>>>>>>>> attribut= e with a sub-set of the overall area. The Consumer

> >>>>>>>>>>>> would= then know the relative position of the content in the

> >>>>>>>>>>>> com= posed

> >>>>>>&g= t;> stream.

> >>>>&= gt;>>>>>>> Here are some reasons why I think this will= generally not

> work:<= /p>

> >>>>>>>>>>>= ;> 1.The spatial information for captures is relevant only in=

> >>>>>>>>>>&g= t;> 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<= o:p>

> >>>>>>>>= >>>> multiple scenes, or source captures from different scenes<= o:p>

> >>>>>>>>= >>>> than the

> >&g= t;>>>>>>>>>> MCC)

> >>>>>>>>>>>> then the s= patial information of one capture has no relation

> >>>>>>>>>>>> to<= /o:p>

> >>>>>>> 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

> >>>>>>>>>>>> jus= t 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 betw= een one full screen source image to two

> >>>>>>>>>>>> source images side= by side, then the spatial information

> >>>>>>>>>>>> wouldn't always ind= icate the location of the source within

> >>>>>>>>>>>> the MCC. We have n= o

> >>>>>>> w= ay

> >>>>>>><= o:p>

> >>>>>>>>= >>>> for the provider to advertise this level of detail, and I<= o:p>

> >>>>>>>>= >>>> don't think we want to get into this detail in provider

> >>>>>>>>&g= t;>>> advertisements.

> &= gt;>>>>>>>>>>> 3.Similarly, the MCC could = always contain both individual

> &= gt;>>>>>>>>>>> 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

> &= gt;>>>>>>>>>>> time, so again the spatial = information wouldn't always

> >= >>>>>>>>>>> indicate the location of the s= ource within the MCC.

> >>&g= t;>>>>>>>>> 4.Take a slightly different example,= where the MCC contains

> >>= >>>>>>>>>> 4 contributing individual captures= , but still with

> >>>>= ;>>>>>>>> MaxCaptures =3D 2.

> >>>>>>>>>>>> So th= e resulting MCC again will change over time, as the

> >>>>>>>>>>>> provi= der is free to choose which 2 out of the 4 to include

> >>>>>>>>>>>> at a= ny time. So again the spatial information wouldn't

> >>>>>>>>>>>> alway= s indicate the location of the source within the MCC.

> >>>>>>>>>>>> Rega= rds,

> >>>>>>>= ;>>>>> Mark

> >&= gt;>>>>>>>>>>

> _______________________________________________

<= p class=3DMsoPlainText>> >>>>>>>>>>>>= ; clue mailing list

> >>>= >>>>>>>>> clue@ietf.org &= lt;mailto:clue@ietf.org>

> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue

> >>>>>>= >>>>> _______________________________________________

> >>>>>>>>>&g= t;> clue mailing list

> >>= ;>>>>>>>>> clue@ietf.org = <mailto:clue@ietf.org>

> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue

> >>>>>>&g= t;> _______________________________________________

> >>>>>>>> clue mailing list

> >>>>>>>> = clue@ietf.org <<= span style=3D'color:windowtext;text-decoration:none'>mailto:clue@ietf.org>

> >>>>&g= t;>>> https://www.ietf.org/mailm= an/listinfo/clue

> >= >>>>>>

> >>= ;>>>>> _______________________________________________<= /o:p>

> >>>>>>> clue mai= ling list

> >>>>>&g= t;> clue@ietf.org

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

> >>>>>> ____________________________= ___________________

> >>>= >>> clue mailing list

> &= gt;>>>>> clue@ietf.org

=

> >>>>>> https://www.ietf.org/mailman/listinfo/clue

> >>>>>>

<= p class=3DMsoPlainText>> >>>>> __________________________= _____________________

> >>&g= t;>> clue mailing list

> >= ;>>>> clue@ietf.org

> >>>>> https://www.ietf.org/mailman/listinfo/clue

> >>>> _________________________________= ______________

> >>>> = clue mailing list

> >>>&g= t; clue@ietf.org

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

> >>>>

> >>&= gt; _______________________________________________

> >>> clue mailing list

> >>> clue@ietf.org=

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

> >

> > _______________________________________________

> > clue mailing list

> > clue@ietf.org

<= p class=3DMsoPlainText>> > https://= www.ietf.org/mailman/listinfo/clue

> >

>

> ____________________________________________= ___

> clue mailing list=

> clue@ietf.org<= /o:p>

> htt= ps://www.ietf.org/mailman/listinfo/clue

= --_000_49E45C59CA48264997FEBFB29B6BC2D60C9D0F8123CRPMBOXPRD07p_-- From Mark.Duckworth@polycom.com Tue Jan 28 09:24: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 EA8691A0383 for ; Tue, 28 Jan 2014 09:24:11 -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 4g59u4SpMeYL for ; Tue, 28 Jan 2014 09:24:10 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 36E321A0368 for ; Tue, 28 Jan 2014 09:24:10 -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; Tue, 28 Jan 2014 09:24:07 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 28 Jan 2014 09:24:07 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Tue, 28 Jan 2014 09:24:05 -0800 Thread-Topic: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? Thread-Index: Ac8b2kWgd+2yrTk5QV6cs0DiO6JyKAAcw1ug Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D0F812A@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@CRPMBOXPRD07.polycom.com> <52DF0AE9.1040509@nteczone.com> <52E00B42.5040409@alum.mit.edu> <52E073E1.4010305@nteczone.com> <52E134A3.8010609@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D01ECE4@CRPMBOXPRD07.polycom.com> <52E725EB.3080601@nteczone.com> In-Reply-To: <52E725EB.3080601@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] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 28 Jan 2014 17:24:12 -0000 Christian, I think the framework does not need to say whether or not the associations = between MCC and constituent captures are made in XML by direct reference to= capture ID, regular expression describing capture ID, by using some other = label, or any other means. The framework should just say there is an assoc= iation, and the details are in the data model. The interim meeting Jan 27 agreed with this position. Regards, Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Monday, January 27, 2014 10:37 PM > To: clue@ietf.org > Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MC= C - > allow wildcard? >=20 > Hello Mark, >=20 > In general I agree that this could be part of the data model but I think = if we > were to use this in the examples in the framework then we would also need > to talk briefly about the label concept in the framework. >=20 > Regards, Christian >=20 > On 25/01/2014 3:15 AM, Duckworth, Mark wrote: > > It sounds like a few of us are agreeing in principle that there could b= e > better ways of expressing in an advertisement which captures can be > included in an MCC rather than just giving a list of captures as part of = the MCC > description. > > > > For the framework document, I think it already covers as much detail th= at is > appropriate for that document, basically this: > > - in an advertisement, an MCC may contain a reference to the other > > media captures contained in the MCC > > - in a configure message, an MCC may contain a reference to the other > > media captures the consumer wishes to receive as part of the MCC > > > > Details of the syntax for how to represent this should be in the data m= odel. > I don't think there are any other issues about this that belong in the > framework. Our discussion about grouping labels and regular expressions > should apply to the data model. Does this make sense? > > > > Mark > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Thursday, January 23, 2014 10:26 AM > >> To: Christian Groves; Duckworth, Mark; clue@ietf.org > >> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in > >> an MCC - allow wildcard? > >> > >> On 1/22/14 8:44 PM, Christian Groves wrote: > >> > >>>> When using labels, it would be easier to follow if the labels had > >>>> some significance. E.g. labels like "left", "center", "right". > >>> [CNG] Easier to follow for who? In terms of a consumer the labels > >>> are really just related to the syntax so probably wouldn't be seen > >>> by a person. I think in this case any random label would be > >>> sufficient. If we want spatial significance better to use spatial > parameters. > >> In use I agree it doesn't matter. > >> But in the *examples* it is easier if they have some significance. > >> > >> Thanks, > >> Paul > > _______________________________________________ > > 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 Christian.Groves@nteczone.com Tue Jan 28 14:52: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 D491E1A02F0 for ; Tue, 28 Jan 2014 14:52:11 -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 ZmhfLR2_kOE5 for ; Tue, 28 Jan 2014 14:52:09 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA421A026E for ; Tue, 28 Jan 2014 14:52:09 -0800 (PST) Received: from ppp118-209-181-8.lns20.mel6.internode.on.net ([118.209.181.8]:49970 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W8HR5-0003UO-6I; Wed, 29 Jan 2014 09:47:15 +1100 Message-ID: <52E83493.1070408@nteczone.com> Date: Wed, 29 Jan 2014 09:52:03 +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: "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@CRPMBOXPRD07.polycom.com> <52DF0AE9.1040509@nteczone.com> <52E00B42.5040409@alum.mit.edu> <52E073E1.4010305@nteczone.com> <52E134A3.8010609@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D01ECE4@CRPMBOXPRD07.polycom.com> <52E725EB.3080601@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D0F812A@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D0F812A@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] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 28 Jan 2014 22:52:12 -0000 Hello Mark, I think maybe you've misunderstood my email. I didn't ask for a treatise on labels to be added, I did use "briefly" and "concept" in my email below. If we want to show the labels being used in the examples in framework then we need to explain something about them. Otherwise people won't know how to interpret it. If we don't use labels in the examples in the framework then there is no issue. Regards, Christian On 29/01/2014 4:24 AM, Duckworth, Mark wrote: > Christian, > > I think the framework does not need to say whether or not the associations between MCC and constituent captures are made in XML by direct reference to capture ID, regular expression describing capture ID, by using some other label, or any other means. The framework should just say there is an association, and the details are in the data model. > > The interim meeting Jan 27 agreed with this position. > > Regards, > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Monday, January 27, 2014 10:37 PM >> To: clue@ietf.org >> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC - >> allow wildcard? >> >> Hello Mark, >> >> In general I agree that this could be part of the data model but I think if we >> were to use this in the examples in the framework then we would also need >> to talk briefly about the label concept in the framework. >> >> Regards, Christian >> >> On 25/01/2014 3:15 AM, Duckworth, Mark wrote: >>> It sounds like a few of us are agreeing in principle that there could be >> better ways of expressing in an advertisement which captures can be >> included in an MCC rather than just giving a list of captures as part of the MCC >> description. >>> For the framework document, I think it already covers as much detail that is >> appropriate for that document, basically this: >>> - in an advertisement, an MCC may contain a reference to the other >>> media captures contained in the MCC >>> - in a configure message, an MCC may contain a reference to the other >>> media captures the consumer wishes to receive as part of the MCC >>> >>> Details of the syntax for how to represent this should be in the data model. >> I don't think there are any other issues about this that belong in the >> framework. Our discussion about grouping labels and regular expressions >> should apply to the data model. Does this make sense? >>> Mark >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, January 23, 2014 10:26 AM >>>> To: Christian Groves; Duckworth, Mark; clue@ietf.org >>>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in >>>> an MCC - allow wildcard? >>>> >>>> On 1/22/14 8:44 PM, Christian Groves wrote: >>>> >>>>>> When using labels, it would be easier to follow if the labels had >>>>>> some significance. E.g. labels like "left", "center", "right". >>>>> [CNG] Easier to follow for who? In terms of a consumer the labels >>>>> are really just related to the syntax so probably wouldn't be seen >>>>> by a person. I think in this case any random label would be >>>>> sufficient. If we want spatial significance better to use spatial >> parameters. >>>> In use I agree it doesn't matter. >>>> But in the *examples* it is easier if they have some significance. >>>> >>>> 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 Tue Jan 28 14:57: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 49B241A02DC for ; Tue, 28 Jan 2014 14:57:03 -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 i0LFO7sQHuOp for ; Tue, 28 Jan 2014 14:57:00 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9D18C1A0093 for ; Tue, 28 Jan 2014 14:57:00 -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; Tue, 28 Jan 2014 14:56:58 -0800 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 28 Jan 2014 14:56:57 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Tue, 28 Jan 2014 14:56:55 -0800 Thread-Topic: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? Thread-Index: Ac8ce5UTpnj5Bo5ISriABIEYnlOkgQAAHPkA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60C9D0F83A9@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60C9CF16019@CRPMBOXPRD07.polycom.com> <52DAB7EF.4050808@alum.mit.edu> <52DC901F.2090907@nteczone.com> <52DD6787.6060009@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9CF163A4@CRPMBOXPRD07.polycom.com> <52DD9FF5.2050602@alum.mit.edu> <52DDA5EE.9090403@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9CF16472@CRPMBOXPRD07.polycom.com> <52DF0AE9.1040509@nteczone.com> <52E00B42.5040409@alum.mit.edu> <52E073E1.4010305@nteczone.com> <52E134A3.8010609@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D01ECE4@CRPMBOXPRD07.polycom.com> <52E725EB.3080601@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60C9D0F812A@CRPMBOXPRD07.polycom.com> <52E83493.1070408@nteczone.com> In-Reply-To: <52E83493.1070408@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] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard? 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, 28 Jan 2014 22:57:03 -0000 Hi Christian, I didn't expect framework examples to use labels or regular expressions for= this, so I agree there is no issue. Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Tuesday, January 28, 2014 5:52 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MC= C - > allow wildcard? >=20 > Hello Mark, >=20 > I think maybe you've misunderstood my email. I didn't ask for a treatise = on > labels to be added, I did use "briefly" and "concept" in my email below. = If we > want to show the labels being used in the examples in framework then we > need to explain something about them. Otherwise people won't know how > to interpret it. >=20 > If we don't use labels in the examples in the framework then there is no > issue. >=20 > Regards, > Christian >=20 >=20 > On 29/01/2014 4:24 AM, Duckworth, Mark wrote: > > Christian, > > > > I think the framework does not need to say whether or not the > associations between MCC and constituent captures are made in XML by > direct reference to capture ID, regular expression describing capture ID,= by > using some other label, or any other means. The framework should just sa= y > there is an association, and the details are in the data model. > > > > The interim meeting Jan 27 agreed with this position. > > > > Regards, > > Mark > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >> Groves > >> Sent: Monday, January 27, 2014 10:37 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in > >> an MCC - allow wildcard? > >> > >> Hello Mark, > >> > >> In general I agree that this could be part of the data model but I > >> think if we were to use this in the examples in the framework then we > >> would also need to talk briefly about the label concept in the framewo= rk. > >> > >> Regards, Christian > >> > >> On 25/01/2014 3:15 AM, Duckworth, Mark wrote: > >>> It sounds like a few of us are agreeing in principle that there > >>> could be > >> better ways of expressing in an advertisement which captures can be > >> included in an MCC rather than just giving a list of captures as part > >> of the MCC description. > >>> For the framework document, I think it already covers as much detail > >>> that is > >> appropriate for that document, basically this: > >>> - in an advertisement, an MCC may contain a reference to the other > >>> media captures contained in the MCC > >>> - in a configure message, an MCC may contain a reference to the > >>> other media captures the consumer wishes to receive as part of the > >>> MCC > >>> > >>> Details of the syntax for how to represent this should be in the data > model. > >> I don't think there are any other issues about this that belong in > >> the framework. Our discussion about grouping labels and regular > >> expressions should apply to the data model. Does this make sense? > >>> Mark > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>>> Sent: Thursday, January 23, 2014 10:26 AM > >>>> To: Christian Groves; Duckworth, Mark; clue@ietf.org > >>>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in > >>>> an MCC - allow wildcard? > >>>> > >>>> On 1/22/14 8:44 PM, Christian Groves wrote: > >>>> > >>>>>> When using labels, it would be easier to follow if the labels had > >>>>>> some significance. E.g. labels like "left", "center", "right". > >>>>> [CNG] Easier to follow for who? In terms of a consumer the labels > >>>>> are really just related to the syntax so probably wouldn't be seen > >>>>> by a person. I think in this case any random label would be > >>>>> sufficient. If we want spatial significance better to use spatial > >> parameters. > >>>> In use I agree it doesn't matter. > >>>> But in the *examples* it is easier if they have some significance. > >>>> > >>>> 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 Tue Jan 28 15:06: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 148601A02EC for ; Tue, 28 Jan 2014 15:06:44 -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 ft8SpOXbIF8v for ; Tue, 28 Jan 2014 15:06:39 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67DD1A033C for ; Tue, 28 Jan 2014 15:06:38 -0800 (PST) Received: from ppp118-209-181-8.lns20.mel6.internode.on.net ([118.209.181.8]:50190 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W8Hf6-0005Iq-SK for clue@ietf.org; Wed, 29 Jan 2014 10:01:45 +1100 Message-ID: <52E837F9.2090201@nteczone.com> Date: Wed, 29 Jan 2014 10:06:33 +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: <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> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D0F8123@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: [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: Tue, 28 Jan 2014 23:06:44 -0000 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. 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 isnt 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 From Christian.Groves@nteczone.com Tue Jan 28 15:28: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 7FCA61A029E for ; Tue, 28 Jan 2014 15:28:30 -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 QKjtO_TGcSqP for ; Tue, 28 Jan 2014 15:28:28 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619971A02F0 for ; Tue, 28 Jan 2014 15:28:28 -0800 (PST) Received: from ppp118-209-181-8.lns20.mel6.internode.on.net ([118.209.181.8]:50755 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W8I0E-0000SU-DK for clue@ietf.org; Wed, 29 Jan 2014 10:23:34 +1100 Message-ID: <52E83D16.30400@nteczone.com> Date: Wed, 29 Jan 2014 10:28:22 +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: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D145B94@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] RTCWEB data channel for CLUE? 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, 28 Jan 2014 23:28:30 -0000 Hello Christer, Are you asking that rtcweb data channel is the ONLY method for establishing a CLUE channel? or that it is one of the methods? If CLUE is being used in the rtcweb context then it would appear to make sense to use the web data channel. However if rtcweb isn't being used then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up the CLUE channels? I don't think there's anything in the CLUE protocol/data model that would prevent either being used. Regards, Christian On 29/01/2014 12:55 AM, Christer Holmberg wrote: > > Hi, > > As those of you who attended the virtual meeting yesterday know, I > presented a suggestion for using the rtcweb data channel for > transporting the CLUE protocol messages. > > We recognized that there ARE a few things that need to be sorted out > and clarified (you may have seen the e-mails Ive sent to the rtcweb- > and mmusic lists), but in general I think we should decide (or, at > least making a working assumption) whether well use the rtcweb mechanism. > > Again, there are details that need to be sorted out, and we can always > reverse any decision we make. But, I do NOT want to wait until London > for making a decision in the first place. I want us to sort out > details and open issues in London. > > Personally I think that having interoperability with rtcweb is > extremely valuable unless, of course, it causes a great burden for > CLUE, or unless the mechanism is technically unfeasible for CLUE. So > far I have not heard any indication of either, and we also saw a demo > showing that it is possible to use the mechanism. > > I also dont think that, due to the dependency on rtcweb that such > decision would create, there is a big risk of CLUE being delayed. In > my opinion, the data channel mechanism is probably the most stable > thing of the things rtcweb is currently working on. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Tue Jan 28 22:45: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 C5D911A0373 for ; Tue, 28 Jan 2014 22:45:38 -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 wWg3sYTNhIgL for ; Tue, 28 Jan 2014 22:45:37 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id C27661A0371 for ; Tue, 28 Jan 2014 22:45:36 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-4b-52e8a38c79d5 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 74.10.04853.C83A8E25; Wed, 29 Jan 2014 07:45:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Wed, 29 Jan 2014 07:45:32 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AASGoAAABEq/QA= Date: Wed, 29 Jan 2014 06:45:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> In-Reply-To: <52E83D16.30400@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+NgFrrALMWRmVeSWpSXmKPExsUyM+JvjW7v4hdBBvd+c1p8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugSvjy6JpTAV/xCr2nalqYDws1MXIwSEhYCJx fnNxFyMnkCkmceHeerYuRi4OIYETjBJzd65khnAWM0p0nb7BBNLAJmAh0f1PG6RBRCBcomPb FUYQW1jAUKK5ZzszRNxIYvfnVVC2lcT8S5fAbBYBVYmu5TPA6nkFfCUutK9gBbGFBHIler9t ALM5BbQkGr9OYwGxGYEO+n5qDROIzSwgLnHryXwmiEMFJJbsOc8MYYtKvHz8jxXCVpRof9rA CFGvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYySxanFxbnp RgZ6uem5JXqpRZnJxcX5eXrFqZsYgbFycMtvox2MJ/fYH2KU5mBREue9zloTJCSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoEx7Eq11Mbdff6tTbPFNvTfEQhIfP4gRXHhhEkvnhau0FobcsqQ e72ozpRtPYqbvJavL56w2dKVbwXztRyrdtPIdx/Tf7T2Far9OtYuJ9q6NpebX2qvvXDCvn1c TF9XSXL7q6+OilwbfkOz7oPz67is444Cl5a/fXDHiXeCktbK5wxHdGwPzjqpxFKckWioxVxU nAgAqM3VOWMCAAA= Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 29 Jan 2014 06:45:38 -0000 Hi Christian, Maybe I misunderstood what you said, but the idea is that we would always u= se draft-ietf-mmusic-sctp-sdp to negotiate and establish the DTLS/SCTP chan= nel, and use the rtcweb data channel mechanism. The rtcweb data channel mechanism then specifies the SCTP details, and the = rtcweb data channel protocol (still TBD whether it's mandated) is used to o= pen the channel, and indicate that it will be used for CLUE. Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves Sent: 29. tammikuuta 2014 1:28 To: clue@ietf.org Subject: Re: [clue] RTCWEB data channel for CLUE? Hello Christer, Are you asking that rtcweb data channel is the ONLY method for establishing= a CLUE channel? or that it is one of the methods? If CLUE is being used in the rtcweb context then it would appear to make se= nse to use the web data channel. However if rtcweb isn't being used then wh= y couldn't we use draft-ietf-mmusic-sctp-sdp to set up the CLUE channels? I don't think there's anything in the CLUE protocol/data model that would p= revent either being used. Regards, Christian On 29/01/2014 12:55 AM, Christer Holmberg wrote: > > Hi, > > As those of you who attended the virtual meeting yesterday know, I=20 > presented a suggestion for using the rtcweb data channel for=20 > transporting the CLUE protocol messages. > > We recognized that there ARE a few things that need to be sorted out=20 > and clarified (you may have seen the e-mails I've sent to the rtcweb-=20 > and mmusic lists), but in general I think we should decide (or, at=20 > least making a working assumption) whether we'll use the rtcweb mechanism= . > > Again, there are details that need to be sorted out, and we can always=20 > reverse any decision we make. But, I do NOT want to wait until London=20 > for making a decision in the first place. I want us to sort out=20 > details and open issues in London. > > Personally I think that having interoperability with rtcweb is=20 > extremely valuable - unless, of course, it causes a great burden for=20 > CLUE, or unless the mechanism is technically unfeasible for CLUE. So=20 > far I have not heard any indication of either, and we also saw a demo=20 > showing that it is possible to use the mechanism. > > I also don't think that, due to the dependency on rtcweb that such=20 > decision would create, there is a big risk of CLUE being delayed. In=20 > my opinion, the data channel mechanism is probably the most stable=20 > thing of the things rtcweb is currently working on. > > 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 Jan 29 00:20: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 DB0C71A0450 for ; Wed, 29 Jan 2014 00:20:41 -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 E8B0dNMIfib6 for ; Wed, 29 Jan 2014 00:20:39 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3D01A02E6 for ; Wed, 29 Jan 2014 00:20:38 -0800 (PST) Received: from ppp118-209-181-8.lns20.mel6.internode.on.net ([118.209.181.8]:63954 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W8QNf-0004SF-Gs; Wed, 29 Jan 2014 19:20:19 +1100 Message-ID: <52E8B9CF.4040100@nteczone.com> Date: Wed, 29 Jan 2014 19:20:31 +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: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D148953@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] RTCWEB data channel for CLUE? 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, 29 Jan 2014 08:20:42 -0000 Hello Christer, I guess CLUE has made the working assumption to use DTLS/SCTP transport. So I assume this means the use of ietf-mmusic-sctp-sdp. Could we use this for CLUE without using the rtcweb data channel mechanism? Regards, Christian On 29/01/2014 5:45 PM, Christer Holmberg wrote: > Hi Christian, > > Maybe I misunderstood what you said, but the idea is that we would always use draft-ietf-mmusic-sctp-sdp to negotiate and establish the DTLS/SCTP channel, and use the rtcweb data channel mechanism. > > The rtcweb data channel mechanism then specifies the SCTP details, and the rtcweb data channel protocol (still TBD whether it's mandated) is used to open the channel, and indicate that it will be used for CLUE. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 29. tammikuuta 2014 1:28 > To: clue@ietf.org > Subject: Re: [clue] RTCWEB data channel for CLUE? > > Hello Christer, > > Are you asking that rtcweb data channel is the ONLY method for establishing a CLUE channel? or that it is one of the methods? > > If CLUE is being used in the rtcweb context then it would appear to make sense to use the web data channel. However if rtcweb isn't being used then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up the CLUE channels? > > I don't think there's anything in the CLUE protocol/data model that would prevent either being used. > > Regards, Christian > > > On 29/01/2014 12:55 AM, Christer Holmberg wrote: >> Hi, >> >> As those of you who attended the virtual meeting yesterday know, I >> presented a suggestion for using the rtcweb data channel for >> transporting the CLUE protocol messages. >> >> We recognized that there ARE a few things that need to be sorted out >> and clarified (you may have seen the e-mails I've sent to the rtcweb- >> and mmusic lists), but in general I think we should decide (or, at >> least making a working assumption) whether we'll use the rtcweb mechanism. >> >> Again, there are details that need to be sorted out, and we can always >> reverse any decision we make. But, I do NOT want to wait until London >> for making a decision in the first place. I want us to sort out >> details and open issues in London. >> >> Personally I think that having interoperability with rtcweb is >> extremely valuable - unless, of course, it causes a great burden for >> CLUE, or unless the mechanism is technically unfeasible for CLUE. So >> far I have not heard any indication of either, and we also saw a demo >> showing that it is possible to use the mechanism. >> >> I also don't think that, due to the dependency on rtcweb that such >> decision would create, there is a big risk of CLUE being delayed. In >> my opinion, the data channel mechanism is probably the most stable >> thing of the things rtcweb is currently working on. >> >> 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 Jan 29 02:40: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 67C0D1A0235 for ; Wed, 29 Jan 2014 02:40: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 6liV1tOP-MHQ for ; Wed, 29 Jan 2014 02:40:04 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E69A61A014C for ; Wed, 29 Jan 2014 02:40:03 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-1c-52e8da80e0db Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DA.C3.23809.08AD8E25; Wed, 29 Jan 2014 11:40:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Wed, 29 Jan 2014 11:40:00 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" , "Simon Pietro Romano (spromano@unina.it)" Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AASGoAAABEq/QAAAWrOgAAGa6Tg Date: Wed, 29 Jan 2014 10:39:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> In-Reply-To: <52E8B9CF.4040100@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+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvjW7DrRdBBlPWKVt8ed/IYrH/1GVm i21tN5gdmD2WLPnJ5LHi/EwWjx9bnjIFMEdx2aSk5mSWpRbp2yVwZXyZW1DQJldx6/xp9gbG ZokuRk4OCQETiZ833jJD2GISF+6tZ+ti5OIQEjjEKPFo3S0WCGcxo8SaJ9sZuxg5ONgELCS6 /2mDxEUEZjBKfPq8A6xbWMBQorlnO5gtImAksfvzKijbTeJLxxMwm0VAVWLrj/8sIDavgK/E 5jXn2CEWXGaUeHFpFytIglNAR2Lqgl9gRYxAJ30/tYYJxGYWEJe49WQ+E8SpAhJL9pyHOltU 4uXjf6wgx0kIKElM25oGUa4jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSqbOQtMxC0jIL ScsCRpZVjOy5iZk56eVGmxiB8XFwy2/VHYx3zokcYpTmYFES5/3w1jlISCA9sSQ1OzW1ILUo vqg0J7X4ECMTB6dUA+MupjMyN5fvkRLZ9frA8VvsyjU6kTlPTsmeuK5z+VG9f0tn8INpptJ3 b4ooy5U8+CR04sy0wrerxC+ZrZ58/X7nQ/OY9evm3tx4a7OKcbDj2ZCqTRZHnpVX2nx9Peua m9VV86UiqS7qi2NSH/Zc5Lv/9msXq9Um8xQvG82A8oiESIeWig93DbWUWIozEg21mIuKEwED MD9OXQIAAA== Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 29 Jan 2014 10:40:06 -0000 Hi Christian, >I guess CLUE has made the working assumption to use DTLS/SCTP transport.=20 Well, at least I haven't seen any other suggestions :) >So I assume this means the use of ietf-mmusic-sctp-sdp. > >Could we use this for CLUE without using the rtcweb data channel mechanism= ? If we want to have interoperability with rtcweb, we need to use the SCTP pr= operties defined in the rtcweb data channel draft. I have not heard, or ide= ntified myself, any reason why that would be a problem for CLUE. Now, as was clarified on the rtcweb list today, the usage of the rtcweb dat= a channel PROTOCOL (DCP) is OPTIONAL, so we'd need to decide what to do for= CLUE. Simon, do you use the DCP in your demo? Regards, Christer On 29/01/2014 5:45 PM, Christer Holmberg wrote: > Hi Christian, > > Maybe I misunderstood what you said, but the idea is that we would always= use draft-ietf-mmusic-sctp-sdp to negotiate and establish the DTLS/SCTP ch= annel, and use the rtcweb data channel mechanism. > > The rtcweb data channel mechanism then specifies the SCTP details, and th= e rtcweb data channel protocol (still TBD whether it's mandated) is used to= open the channel, and indicate that it will be used for CLUE. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian=20 > Groves > Sent: 29. tammikuuta 2014 1:28 > To: clue@ietf.org > Subject: Re: [clue] RTCWEB data channel for CLUE? > > Hello Christer, > > Are you asking that rtcweb data channel is the ONLY method for establishi= ng a CLUE channel? or that it is one of the methods? > > If CLUE is being used in the rtcweb context then it would appear to make = sense to use the web data channel. However if rtcweb isn't being used then = why couldn't we use draft-ietf-mmusic-sctp-sdp to set up the CLUE channels? > > I don't think there's anything in the CLUE protocol/data model that would= prevent either being used. > > Regards, Christian > > > On 29/01/2014 12:55 AM, Christer Holmberg wrote: >> Hi, >> >> As those of you who attended the virtual meeting yesterday know, I=20 >> presented a suggestion for using the rtcweb data channel for=20 >> transporting the CLUE protocol messages. >> >> We recognized that there ARE a few things that need to be sorted out=20 >> and clarified (you may have seen the e-mails I've sent to the rtcweb-=20 >> and mmusic lists), but in general I think we should decide (or, at=20 >> least making a working assumption) whether we'll use the rtcweb mechanis= m. >> >> Again, there are details that need to be sorted out, and we can=20 >> always reverse any decision we make. But, I do NOT want to wait until=20 >> London for making a decision in the first place. I want us to sort=20 >> out details and open issues in London. >> >> Personally I think that having interoperability with rtcweb is=20 >> extremely valuable - unless, of course, it causes a great burden for=20 >> CLUE, or unless the mechanism is technically unfeasible for CLUE. So=20 >> far I have not heard any indication of either, and we also saw a demo=20 >> showing that it is possible to use the mechanism. >> >> I also don't think that, due to the dependency on rtcweb that such=20 >> decision would create, there is a big risk of CLUE being delayed. In=20 >> my opinion, the data channel mechanism is probably the most stable=20 >> thing of the things rtcweb is currently working on. >> >> 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 magnus.westerlund@ericsson.com Wed Jan 29 02:58: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 9CC0B1A0235 for ; Wed, 29 Jan 2014 02:58:59 -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 fDhDXLMM9h1t for ; Wed, 29 Jan 2014 02:58:57 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9241A0188 for ; Wed, 29 Jan 2014 02:58:56 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-71-52e8deed721c Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3D.E1.10875.DEED8E25; Wed, 29 Jan 2014 11:58:53 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.347.0; Wed, 29 Jan 2014 11:58:53 +0100 Message-ID: <52E8DEED.6060701@ericsson.com> Date: Wed, 29 Jan 2014 11:58:53 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: CLUE References: <52E8B4F8.4000900@ericsson.com> In-Reply-To: <52E8B4F8.4000900@ericsson.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <52E8B4F8.4000900@ericsson.com> Content-Type: multipart/mixed; boundary="------------000003080303000701040408" X-Brightmail-Tracker: H4sIAAAAAAAAA2WSfUhTYRTGfXe3u4+QrmvNk/0ROftOS5gpISYUUlEklhER1LKbLqfJZllk MFNLp9Gwae0ioaCEiUQqZKA0V1luMqfTQGFzfgwUnSgNU8Nqu+8kof9+5/A85z2c5xUQ4lFe hECZm0+rcxWqSFLENV5aK4z2uqbTDtd2RSd8tDiIZHSyoWGFk4ouixJv0CrlXVp9KOmaKKtr pJ6T9y3x3tigG2lR0REdEgqAkkPpMy0HsxTsrrekDokEYsqMwDM3GSxeI/hS+4MMqEKpA2Bb ZlgHl9oFLnM32yepBBhZLmJ5K3UeRmvcfKwPg17jFDfAEgrAYnGiAG+hUsDZb2E1Yv/Muc5X RICF1EEw2Sr8cwT+jcKhsigNLxcPhrpSVk5QqfDdPYvWrdpHZTw9CmM2vMZskGGOAcNwSZB3 wHtvLYE5AzrcM8T//VtQ7KzkMezTm+GJtc/fD5ziHYKW3/UkLj4gWJptJBl2kecIBozZDHsX HwFTbgl2R0GFtp3EfRn8aVwNmlsRPB538rFoL7xssvvXE7DPtZhlGCVQPC/GilCwGr6SmDUw VN7HxWMGEcz89PBw8RmBvdFBYLMcVpYf4H4PgkHPZNDhT3O1uY/PBNPUV9XymWCahsUx9nbr aTJsmulQtjTK3kJC7QHHuJ3P/EsnMBMomxAcEzpOHZK/QfwchVKVWRDbivz/s7v9V3QHstgk ZrRdwI0MD13wHk8TU5mKfDqbpvNo9VX1HRWtMSOOQBihRU+rj/HvG5M+lWTELZyKe2GaN6XL N1VlM7t9rsKczpKOCmui4bq1N+pmiMMzUBNPn52S9ie1J59uPhOjlI1Z2qTnbNXbWuaveHcy +xaaFLd7KttSvKhrTSErPzGhP/Ow4KJP6jsakl4OEn3nbEPZdLxucVpngpGhCyFkadRwJFeT pYjdT6g1ir+A26OcbQMAAA== Subject: [clue] Fwd: [rtcweb] Potential dates for WebRTC/RTCWEB joint Interim 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, 29 Jan 2014 10:58:59 -0000 --------------000003080303000701040408 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit For your information Magnus --------------000003080303000701040408 Content-Type: message/rfc822; name="[rtcweb] Potential dates for WebRTC/RTCWEB joint Interim.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="[rtcweb] Potential dates for WebRTC/RTCWEB joint Interim.eml" X-Mozilla-Keys: Received: from sessmg10.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.55) with Microsoft SMTP Server id 14.2.347.0; Wed, 29 Jan 2014 08:59:59 +0100 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by sessmg10.ericsson.net (Symantec Mail Security) with SMTP id EA.8F.05637.EF4B8E25; Wed, 29 Jan 2014 08:59:59 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C2C1A0340; Tue, 28 Jan 2014 23:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1390982400; bh=A5wdgBaTISoEjWb034wjFA54mcdT1c5h2GmAOQ35GZU=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=fapiSJHM+B9bzhAJ+yHaEJfS7rwgNhSfTefNbMDgmPClrfou6UsG2YHfj7Q5cN2EV 53QTRIOsGko2yJTPc8N0pLYdyL020kCpqmoOiSo6qsUgi7h7Me6NoK5IG2q+x80rgm cclWxAEGSrRQSbfjaUkzvNC3uqQGKC5FQ0g2oGuc= X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4991A00F5 for ; Tue, 28 Jan 2014 23:59:58 -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 y7g_11vI6Bkh for ; Tue, 28 Jan 2014 23:59:56 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id EA8331A007A for ; Tue, 28 Jan 2014 23:59:55 -0800 (PST) X-AuditID: c1b4fb3e-b7faf8e000001605-de-52e8b4fe12ac Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E7.58.04249.8F4B8E25; Wed, 29 Jan 2014 08:59:52 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.2.347.0; Wed, 29 Jan 2014 08:59:51 +0100 Message-ID: <52E8B4F8.4000900@ericsson.com> Date: Wed, 29 Jan 2014 08:59:52 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 X-Brightmail-Tracker: H4sIAAAAAAAAA1VTbUxbVRjm7b3ce9dw2aGU9V2dspU5F4YICYvnh6L+MNHERGRZlizbXHVX Wi1d01sUoj9gYjIqKlFQcI5N5WOwLLDSzX1kOLFimIh8CZsIa7XLCNvYnIKFZam9PWxz/573 PM/7PE9OzpE4w4xglpRSj+J2Wh0WQc/z6b1Zj0b904U5+6KracupbXTPpF+kgw3fA/VdcNFf Ar8DnR3/QaQDB6qBzlcu6OjowRMi/WRkP08PtV4DevSnOqDDHVM6+lFUpWPjN3X0dPMwRydv H+fot2fnBTq1MCfQwLlZ7mnjc4tzvwoFsFX/xC7FYX9TcT+Wv1Nv+7qxA1zNcukf178Sy+Ga 3guShCQPFyJve2FZDK7AwakOwQt6yUC+ATza6xPZUAc4VtHNaSqe/MNhOGhkG2vx/XK/wM4z MNq8uLTtA2wcC4pMtB7r2waBpS3HIz0ZDBrx3VkDUyTj0HREx7CKo1X9PLMZBZxoiSwNAcCa vmNLnnk4HI0uEb2Ai/7LiWxojQ2H++MqmWzAmo+/EFm9h7H2r4u8hgVC8UKkIl47jWzGvfO/ JTJ9CvY1hOMaI3kER0KDIqtqwuqKQs0fSWMitjb1xrumkmdwInAcWKNVONTOrgLJSuwf+Tl+ TgjBxqaTcX0S2YJdgT6e4bfQ39ANNbD+8/9Fa5gj2Xi+rlZgeAO2fHmFOwhcO6SpiqoWF+Xm ZCtu+6uqutuZ7VQ8Pog9sO/8t/JPwFgotwdWSjpLmuxtni40JL+ye1eZzaraXnaXOBS1Bx6Q eItJNvChQgMpsnqUNxTFpbjvsKskyYJyV1dsM8WtFCmlr9kdnnu0TlrWAyglWYzyGU0jqy5r sWovYvw5WGM2yZ0aQTTCVuK8u3vnCwzDg+ZUGRISEgxJsdxiu+d+fgZMElhS5SrNJcnu9Nx1 n4kF62LBbd1hLdhjvUeZy8GaMfnslnUv/Hv1vbO1+3ZseqrkwzV7U6rqpkt3dJeZmsAwsDkr UuD7seud2UuZ5x3p/sc/HQrb887cfDJ442qovG2Pq7o+/Zj3obWVJ700dVRd8fzEi8HwnFPc mXOKlF3aPvF31e3rwc5NiSnmWx+E6rMG5j57XUjO35h5cXXB+EuVBX9aeNVmzc3k3Kr1PwoF qWz9AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+Jvje6PLS+CDG7s0bJY+6+d3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGd/7H7EXzOGpeLp0G2MD4zvOLkZODgkBE4lL//+zQNhiEhfu rWfrYuTiEBI4wiix/MA8KGc5o8Sv1WfYQap4BbQlJkyaA2azCKhKTPl4H6ybTcBC4uaPRjYQ W1QgWOLWtAdQ9YISJ2c+AasREVCXuPzwAlhcGKj+1aZmIJsDaLO4RE9jEEiYWUBPYsrVFkYI W16ieetsZhBbCGhtQ1MH6wRG/llIps5C0jILScsCRuZVjBzFqcVJuelGBpsYgQF1cMtvix2M l//aHGKU5mBREuf9+NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjZJGUDdIRZk1ssy0/ 6zz2tn71+0f32kbV8DezFjHwO4u9ao6N//iP49vnsOqSoumXwq6YWNXr8WmoSPn3bQyo8lkx P3SL9BOW3VXuGveStc1/t+SdSclKP79XQ2mnG7tG71ado+m935pn+r5RfpaaGGhfkG60J3Gn 5O3fcy92/lIo0jq/4Z8SS3FGoqEWc1FxIgCyMgPX9gEAAA== Subject: [rtcweb] Potential dates for WebRTC/RTCWEB joint Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: rtcweb-bounces@ietf.org Sender: rtcweb Return-Path: rtcweb-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC012.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 WG, The chairs of this WG and the W3C are considering an joint interim meeting. The dates we chairs have arrived as feasible are May 20-22 (Tue-Thu). We are considering to split up the time between the two WGs across all three days. So please take note of these dates in your calendar now. The target region for this interim would be East Coast of North America, but we have at this stage no host or set location. If you are willing to host, please contact the chairs. We haven't decided on this interim yet, and appreciate your input into holding one. The goals of the interim would be to advanced the state of the core documents we need to finish up. We expect that we will have some document that may have WG last call issues needing face to face time to speed up resolving them. We expect to have documents that are under development, like JSEP that will have thorny issues to deal with. Especially issues that interact with the API where we can benefit from having the W3C WG also present to come to joint conclusions. Cheers Magnus Westerlund (For the RTCWEB Chairs) ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------000003080303000701040408-- From pkyzivat@alum.mit.edu Wed Jan 29 08: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 89AA41A0230 for ; Wed, 29 Jan 2014 08: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 oplf0fRfBN8h for ; Wed, 29 Jan 2014 08:01:51 -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 B47E51A0218 for ; Wed, 29 Jan 2014 08:01:50 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta01.westchester.pa.mail.comcast.net with comcast id Kq2P1n0010Fqzac51s1nrh; Wed, 29 Jan 2014 16:01:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id Ks1n1n00T3ZTu2S3Us1nNb; Wed, 29 Jan 2014 16:01:47 +0000 Message-ID: <52E925EB.6070801@alum.mit.edu> Date: Wed, 29 Jan 2014 11:01:47 -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: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D148953@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=1391011307; bh=T+kpJR4uJpBQN8CgFVwEZ1RnuNkqQMETCAKvnE/jcyM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WGMKuOUoByCbroiAqb7HNpLUcdykt1MkQZpfRWPb6NAtzZhD1roYUxw6j6lqkwgIX iOOy6MuczGRRk4l+NUrFTMhmqqIhyTQFU9UI/98Lu1HFRoECOF+pG/vLWQnoMnD6xU UsafDPHrP6dmq7au4qurFo76zoQWUdA+U7BglLrgJPM2DSesk38uCbr0tZWIbhUjL9 pWe8SpSF8539HSbs+SX5zvHKOnh8IOlT0J3khRQ4oQKMnrxtpc5Rur8ZHKmPRpXLPT Z8yOshbLZ120A0d2VPqoE8XmNfq2V7pB1JSj3uT5npUeSk4DQOWHkls1GiTsnN06BB bvCqIYGcTdv7A== Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 29 Jan 2014 16:01:52 -0000 On 1/29/14 1:45 AM, Christer Holmberg wrote: > Hi Christian, > > Maybe I misunderstood what you said, but the idea is that we would always use draft-ietf-mmusic-sctp-sdp to negotiate and establish the DTLS/SCTP channel, and use the rtcweb data channel mechanism. > > The rtcweb data channel mechanism then specifies the SCTP details, and the rtcweb data channel protocol (still TBD whether it's mandated) is used to open the channel, and indicate that it will be used for CLUE. What I have been thinking is that we would use draft-ietf-mmusic-sctp-sdp and draft-ejzak-dispatch-webrtc-data-channel-sdpneg to negotiate the data channel, thus avoiding the need to rely upon the rtcweb data channel protocol. I guess either mechanism will work. Which is preferable depends on what you think will happen in the future for use of other data channel in a sip O/A environment. For instance, if we wanted to also negotiate a hypothetical BFCP over data channel usage, either with or without clue. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 29. tammikuuta 2014 1:28 > To: clue@ietf.org > Subject: Re: [clue] RTCWEB data channel for CLUE? > > Hello Christer, > > Are you asking that rtcweb data channel is the ONLY method for establishing a CLUE channel? or that it is one of the methods? > > If CLUE is being used in the rtcweb context then it would appear to make sense to use the web data channel. However if rtcweb isn't being used then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up the CLUE channels? > > I don't think there's anything in the CLUE protocol/data model that would prevent either being used. > > Regards, Christian > > > On 29/01/2014 12:55 AM, Christer Holmberg wrote: >> >> Hi, >> >> As those of you who attended the virtual meeting yesterday know, I >> presented a suggestion for using the rtcweb data channel for >> transporting the CLUE protocol messages. >> >> We recognized that there ARE a few things that need to be sorted out >> and clarified (you may have seen the e-mails I've sent to the rtcweb- >> and mmusic lists), but in general I think we should decide (or, at >> least making a working assumption) whether we'll use the rtcweb mechanism. >> >> Again, there are details that need to be sorted out, and we can always >> reverse any decision we make. But, I do NOT want to wait until London >> for making a decision in the first place. I want us to sort out >> details and open issues in London. >> >> Personally I think that having interoperability with rtcweb is >> extremely valuable - unless, of course, it causes a great burden for >> CLUE, or unless the mechanism is technically unfeasible for CLUE. So >> far I have not heard any indication of either, and we also saw a demo >> showing that it is possible to use the mechanism. >> >> I also don't think that, due to the dependency on rtcweb that such >> decision would create, there is a big risk of CLUE being delayed. In >> my opinion, the data channel mechanism is probably the most stable >> thing of the things rtcweb is currently working on. >> >> 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 mary.ietf.barnes@gmail.com Wed Jan 29 08:03: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 E748F1A0218 for ; Wed, 29 Jan 2014 08:03:31 -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 o4Q7Suw4UqWi for ; Wed, 29 Jan 2014 08:03:29 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id EC63A1A0230 for ; Wed, 29 Jan 2014 08:03:28 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id uy17so4885824igb.3 for ; Wed, 29 Jan 2014 08:03:26 -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=5mtsLxBy3UX45grIWNKiaD27XIbyGyCaOghEHu4pYlE=; b=GahmOo2yU8dXVA68PCmIbYPqP9+gg27vsTXJ8yneyDrcpaRGTfAg60Cmb9Qn0dDMDP duZ7WMKOC+7p5n2H6uyFbxXq3kzaaB8FuXSEYdWdpjpEKbCBr54QCV7CYe0AlDHQ/Boc zSXOaqopPnaY3OAlvb+gb+3J/OCG5Cw0pOwkAH6InaOvgpVqyqWDEdRZwpiV4xjKNSiA 8RWBwyJfeYf+taUX2jnSEno1GVCXh0Ytef662COcm+fRYFv3u2Fb6ml3HN6oWpu6pJ7u AzbAiG+sC3TkgHN68rELiLSbqQTjGSnPQ8uYONweVVkHjWMvPqR/1OR49kFN1UM9cSdA jSNw== MIME-Version: 1.0 X-Received: by 10.50.114.4 with SMTP id jc4mr29286623igb.0.1391011405920; Wed, 29 Jan 2014 08:03:25 -0800 (PST) Received: by 10.43.58.137 with HTTP; Wed, 29 Jan 2014 08:03:25 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> Date: Wed, 29 Jan 2014 10:03:25 -0600 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b2e0983ba818904f11e145e Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 29 Jan 2014 16:03:32 -0000 --047d7b2e0983ba818904f11e145e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 29, 2014 at 4:39 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Christian, > > >I guess CLUE has made the working assumption to use DTLS/SCTP transport. > > Well, at least I haven't seen any other suggestions :) > [MB] This was taken as a decision by the WG for which we had consensus. So, we will not debate that decision unless someone else submits a more complete alternative to the WG. [/MB] > > >So I assume this means the use of ietf-mmusic-sctp-sdp. > > > >Could we use this for CLUE without using the rtcweb data channel > mechanism? > > If we want to have interoperability with rtcweb, we need to use the SCTP > properties defined in the rtcweb data channel draft. I have not heard, or > identified myself, any reason why that would be a problem for CLUE. > [MB] I think the decision to be made by CLUE needs to more importantly consider whether that approach works for CLUE without RTCWEB. We discussed on the call that the RTCWEB WG document (i.e., draft-ietf-rtcweb-data-channel/) could be viewed as providing a more generic mechanism that can be used for applications beyond RTCWEB. That all said, as an individual, I don't see it to be a tremendous amount of work to write a clue-data-channel document that uses identical mechanisms but has content specific to CLUE. For example, the generic aspects in the RTCWEB seem to be primarily limited to section 5 (just over 3 pages of text). Section 4 has some generic aspects, but also some of it is RTCWEB specific. And, section 3 is totally specific to RTCWEB. And, we need to decide how much of section 6 applies to CLUE.So, personally, I think CLUE could just write their own document (and perhaps mention that procedures in section blah are identical to those for RTCWEB OR write a general document that both CLUE and RTCWEB can reference (although the doc would have more boiler plate than content. Or perhaps, section 5 could be folded into the tsvwg document (although I haven't looked at that in detail to see if it would work). [/MB] > > Now, as was clarified on the rtcweb list today, the usage of the rtcweb > data channel PROTOCOL (DCP) is OPTIONAL, so we'd need to decide what to do > for CLUE. > > Simon, do you use the DCP in your demo? > > Regards, > > Christer > > > > > On 29/01/2014 5:45 PM, Christer Holmberg wrote: > > Hi Christian, > > > > Maybe I misunderstood what you said, but the idea is that we would > always use draft-ietf-mmusic-sctp-sdp to negotiate and establish the > DTLS/SCTP channel, and use the rtcweb data channel mechanism. > > > > The rtcweb data channel mechanism then specifies the SCTP details, and > the rtcweb data channel protocol (still TBD whether it's mandated) is used > to open the channel, and indicate that it will be used for CLUE. > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > > Groves > > Sent: 29. tammikuuta 2014 1:28 > > To: clue@ietf.org > > Subject: Re: [clue] RTCWEB data channel for CLUE? > > > > Hello Christer, > > > > Are you asking that rtcweb data channel is the ONLY method for > establishing a CLUE channel? or that it is one of the methods? > > > > If CLUE is being used in the rtcweb context then it would appear to make > sense to use the web data channel. However if rtcweb isn't being used then > why couldn't we use draft-ietf-mmusic-sctp-sdp to set up the CLUE channels? > > > > I don't think there's anything in the CLUE protocol/data model that > would prevent either being used. > > > > Regards, Christian > > > > > > On 29/01/2014 12:55 AM, Christer Holmberg wrote: > >> Hi, > >> > >> As those of you who attended the virtual meeting yesterday know, I > >> presented a suggestion for using the rtcweb data channel for > >> transporting the CLUE protocol messages. > >> > >> We recognized that there ARE a few things that need to be sorted out > >> and clarified (you may have seen the e-mails I've sent to the rtcweb- > >> and mmusic lists), but in general I think we should decide (or, at > >> least making a working assumption) whether we'll use the rtcweb > mechanism. > >> > >> Again, there are details that need to be sorted out, and we can > >> always reverse any decision we make. But, I do NOT want to wait until > >> London for making a decision in the first place. I want us to sort > >> out details and open issues in London. > >> > >> Personally I think that having interoperability with rtcweb is > >> extremely valuable - unless, of course, it causes a great burden for > >> CLUE, or unless the mechanism is technically unfeasible for CLUE. So > >> far I have not heard any indication of either, and we also saw a demo > >> showing that it is possible to use the mechanism. > >> > >> I also don't think that, due to the dependency on rtcweb that such > >> decision would create, there is a big risk of CLUE being delayed. In > >> my opinion, the data channel mechanism is probably the most stable > >> thing of the things rtcweb is currently working on. > >> > >> 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 > --047d7b2e0983ba818904f11e145e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jan 29, 2014 at 4:39 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:
Hi Christian,

>I guess CLUE has made the working assumption to use DTLS/SCTP transport= .

Well, at least I haven't seen any other suggestions :)

[MB] This was taken as a decision by the WG for w= hich we had consensus. So, we will not debate that decision unless someone = else submits a more complete alternative to the WG. [/MB]

>So I assume this means the use of ietf-mmusic-sctp-sdp.
>
>Could we use this for CLUE without using the rtcweb data channel mechan= ism?

If we want to have interoperability with rtcweb, we need to use the S= CTP properties defined in the rtcweb data channel draft. I have not heard, = or identified myself, any reason why that would be a problem for CLUE.

[MB] I think the decision to be made by CL= UE needs to more importantly consider whether that approach works for CLUE = without RTCWEB. =A0We discussed on the call that the RTCWEB WG document (i.= e., draft-ietf-rtcweb-data-channel/) could be viewed as providing a more ge= neric mechanism that can be used for applications beyond RTCWEB.

That all said, as an i= ndividual, I don't see it to be a tremendous amount of work to write a = =A0clue-data-channel document that uses identical mechanisms but has conten= t specific to CLUE. =A0For example, the generic aspects in the RTCWEB seem = to be primarily limited to section 5 (just over 3 pages of text). =A0Sectio= n 4 has some generic aspects, but also some of it is RTCWEB specific. And, = section 3 is totally specific to RTCWEB. =A0And, we need to decide h= ow much of section 6 applies to CLUE.So, p= ersonally, I think CLUE could just write their own document (and perhaps me= ntion that procedures in section blah are identical to those for RTCWEB OR = write a general document that both CLUE and RTCWEB can reference (although = the doc would have more boiler plate than content. =A0Or perhaps, section 5= could be folded into the tsvwg document (although I haven't looked at = that in detail to see if it would work). [/MB]=A0

Now, as was clarified on the rtcweb list today, the usage of the rtcweb dat= a channel PROTOCOL (DCP) is OPTIONAL, so we'd need to decide what to do= for CLUE.

Simon, do you use the DCP in your demo?

Regards,

Christer




On 29/01/2014 5:45 PM, Christer Holmberg wrote:
> Hi Christian,
>
> Maybe I misunderstood what you said, but the idea is that we would alw= ays use draft-ietf-mmusic-sctp-sdp to negotiate and establish the DTLS/SCTP= channel, and use the rtcweb data channel mechanism.
>
> The rtcweb data channel mechanism then specifies the SCTP details, and= the rtcweb data channel protocol (still TBD whether it's mandated) is = used to open the channel, and indicate that it will be used for CLUE.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: clue [mailto:clue-bounc= es@ietf.org] On Behalf Of Christian
> Groves
> Sent: 29. tammikuuta 2014 1:28
> To: clue@ietf.org
> Subject: Re: [clue] RTCWEB data channel for CLUE?
>
> Hello Christer,
>
> Are you asking that rtcweb data channel is the ONLY method for establi= shing a CLUE channel? or that it is one of the methods?
>
> If CLUE is being used in the rtcweb context then it would appear to ma= ke sense to use the web data channel. However if rtcweb isn't being use= d then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up the CLU= E channels?
>
> I don't think there's anything in the CLUE protocol/data model= that would prevent either being used.
>
> Regards, Christian
>
>
> On 29/01/2014 12:55 AM, Christer Holmberg wrote:
>> Hi,
>>
>> As those of you who attended the virtual meeting yesterday know, I=
>> presented a suggestion for using the rtcweb data channel for
>> transporting the CLUE protocol messages.
>>
>> We recognized that there ARE a few things that need to be sorted o= ut
>> and clarified (you may have seen the e-mails I've sent to the = rtcweb-
>> and mmusic lists), but in general I think we should decide (or, at=
>> least making a working assumption) whether we'll use the rtcwe= b mechanism.
>>
>> Again, there are details that need to be sorted out, and we can >> always reverse any decision we make. But, I do NOT want to wait un= til
>> London for making a decision in the first place. I want us to sort=
>> out details and open issues in London.
>>
>> Personally I think that having interoperability with rtcweb is
>> extremely valuable - unless, of course, it causes a great burden f= or
>> CLUE, or unless the mechanism is technically unfeasible for CLUE. = So
>> far I have not heard any indication of either, and we also saw a d= emo
>> showing that it is possible to use the mechanism.
>>
>> I also don't think that, due to the dependency on rtcweb that = such
>> decision would create, there is a big risk of CLUE being delayed. = In
>> my opinion, the data channel mechanism is probably the most stable=
>> thing of the things rtcweb is currently working on.
>>
>> 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
ht= tps://www.ietf.org/mailman/listinfo/clue

--047d7b2e0983ba818904f11e145e-- From mary.ietf.barnes@gmail.com Wed Jan 29 08:17: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 B97111A04D0 for ; Wed, 29 Jan 2014 08:17: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 kNRrfI1Zp1Qu for ; Wed, 29 Jan 2014 08:17:28 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDB31A04CC for ; Wed, 29 Jan 2014 08:17:27 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id k19so15379831igc.5 for ; Wed, 29 Jan 2014 08:17:24 -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=U2cZDwbX+0TYP+iTMWA3PPiPXnzaGticdSmH7EMtWHI=; b=RhmCIDhsoAy5Yn/ofxGRzu7QVEhiL28OxlNGpNlv2LY+9eDD+0VOpT8MWVsv6bwNC9 lIYPDEkBOFPk7VmyAPaQr30TCPKCFvUlCiP3Lb0ze1FiidedFzgsxre9VJ3ybdmXkojk wFMRLtMavr3fXbTnYi4O8/iyGbCVeje/McAXoCrQXLKmD4oerRaHDjS/pyG+v1UCmUgA 2IQeDL6cOtZy6UC7a+HfoLdnoXJqUgLXlfrv5767oTpX8cq/bjIzIaFfd+G2rE7asRzy OX36EGtdZhTDu3FZxUlSPTwBvj2esjzAFc/AsJvoI/rS//nI2BKFjoPQRKNW+5ofThyt o+cg== MIME-Version: 1.0 X-Received: by 10.42.53.10 with SMTP id l10mr6669955icg.33.1391012244549; Wed, 29 Jan 2014 08:17:24 -0800 (PST) Received: by 10.43.58.137 with HTTP; Wed, 29 Jan 2014 08:17:24 -0800 (PST) In-Reply-To: <52E8DEED.6060701@ericsson.com> References: <52E8B4F8.4000900@ericsson.com> <52E8DEED.6060701@ericsson.com> Date: Wed, 29 Jan 2014 10:17:24 -0600 Message-ID: From: Mary Barnes To: Magnus Westerlund Content-Type: multipart/alternative; boundary=90e6ba614278b6f58204f11e4644 Cc: CLUE Subject: Re: [clue] Fwd: [rtcweb] Potential dates for WebRTC/RTCWEB joint Interim 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, 29 Jan 2014 16:17:34 -0000 --90e6ba614278b6f58204f11e4644 Content-Type: text/plain; charset=ISO-8859-1 Just a note to the CLUE folks that our poll closed last Friday: http://doodle.com/5c7rb9ac6e2tnwfk Although, there's still a couple folks that I would anticipate would be attending that haven't responded. The optimal dates are Thursday May 29 and Friday May 30th. More details will follow. Mary. On Wed, Jan 29, 2014 at 4:58 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > For your information > > Magnus > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --90e6ba614278b6f58204f11e4644 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Just a note to the CLUE folks that our poll closed last Fr= iday:
Although, there's still a couple fol= ks that I would anticipate would be attending that haven't responded.

The optimal dates are Thursday May 29 and Friday May 30= th. =A0More details will follow.=A0

Mary.= =A0


On Wed, Jan 29, 2014 at 4:58 AM, Magnus Westerlund <magnus.we= sterlund@ericsson.com> wrote:
For your information

Magnus

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


--90e6ba614278b6f58204f11e4644-- From spromano@unina.it Wed Jan 29 08: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 94CD21A02C8 for ; Wed, 29 Jan 2014 08:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.245 X-Spam-Level: * X-Spam-Status: No, score=1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_18=0.6, 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 sMjtrI7Q7R4p for ; Wed, 29 Jan 2014 08:18:59 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 967CB1A04CD for ; Wed, 29 Jan 2014 08:18:58 -0800 (PST) Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s0TGIp2e024145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jan 2014 17:18:52 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_49D4E25E-1707-467C-80D8-2D5926232B3C" From: Simon Pietro Romano In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> Date: Wed, 29 Jan 2014 17:18:50 +0100 Message-Id: <1483778D-D5BC-4AA2-AB9F-3EE688E20CCF@unina.it> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 29 Jan 2014 16:19:02 -0000 --Apple-Mail=_49D4E25E-1707-467C-80D8-2D5926232B3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Christer, > Simon, do you use the DCP in your demo? In my demo I just make use of the 'plain' WebRTC API. Basically: - the channel initiator does this (Note: pc is the available = PeerConnection object): sendChannel =3D pc.createDataChannel("sendDataChannel" , {reliable: = true}); This results in the following SDP lines (note that "video" and "data = channel" data are bundled together): m=3Dapplication 1 RTP/SAVPF 101 c=3DIN IP4 0.0.0.0 a=3Drtcp:1 IN IP4 0.0.0.0 a=3Dice-ufrag:7Do/ydOMrH5lwzBn a=3Dice-pwd:b3D+HG9L+SzimBRJcWUqZgti a=3Dice-options:google-ice a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D a=3Dsetup:actpass a=3Dmid:data a=3Dsendrecv b=3DAS:30 a=3Drtcp-mux a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 = inline:1CFp/gR+88d3ig0EcgluA0yGumtiKI8gxOH2f/ug a=3Drtpmap:101 google-data/90000 a=3Dssrc:1049470780 cname:l6fp7zYgy3DkXQDN a=3Dssrc:1049470780 msid:sendDataChannel sendDataChannel a=3Dssrc:1049470780 mslabel:sendDataChannel a=3Dssrc:1049470780 label:sendDataChannel - the channel receiver in turn, does the following: pc.ondatachannel =3D gotReceiveChannel; function gotReceiveChannel(event) { trace('Receive Channel Callback'); receiveChannel =3D event.channel; receiveChannel.onmessage =3D handleMessage; receiveChannel.onopen =3D handleReceiveChannelStateChange; receiveChannel.onclose =3D handleReceiveChannelStateChange; } The following is an excerpt of the provided SDP answer: m=3Dapplication 1 RTP/SAVPF 101 c=3DIN IP4 0.0.0.0 a=3Drtcp:1 IN IP4 0.0.0.0 a=3Dice-ufrag:d0/jsCoioZ5wIqQ1 a=3Dice-pwd:pGoZXkLiO6HN5JZYsy3cSAhH a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D a=3Dsetup:active a=3Dmid:data a=3Dsendrecv b=3DAS:30 a=3Drtcp-mux a=3Drtpmap:101 google-data/90000 a=3Dssrc:1971010094 cname:icWWLWa/VsrZGHr3 a=3Dssrc:1971010094 msid:sendDataChannel sendDataChannel a=3Dssrc:1971010094 mslabel:sendDataChannel a=3Dssrc:1971010094 label:sendDataChannel Hope this helps, Simon >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > On 29/01/2014 5:45 PM, Christer Holmberg wrote: >> Hi Christian, >>=20 >> Maybe I misunderstood what you said, but the idea is that we would = always use draft-ietf-mmusic-sctp-sdp to negotiate and establish the = DTLS/SCTP channel, and use the rtcweb data channel mechanism. >>=20 >> The rtcweb data channel mechanism then specifies the SCTP details, = and the rtcweb data channel protocol (still TBD whether it's mandated) = is used to open the channel, and indicate that it will be used for CLUE. >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian=20 >> Groves >> Sent: 29. tammikuuta 2014 1:28 >> To: clue@ietf.org >> Subject: Re: [clue] RTCWEB data channel for CLUE? >>=20 >> Hello Christer, >>=20 >> Are you asking that rtcweb data channel is the ONLY method for = establishing a CLUE channel? or that it is one of the methods? >>=20 >> If CLUE is being used in the rtcweb context then it would appear to = make sense to use the web data channel. However if rtcweb isn't being = used then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up the = CLUE channels? >>=20 >> I don't think there's anything in the CLUE protocol/data model that = would prevent either being used. >>=20 >> Regards, Christian >>=20 >>=20 >> On 29/01/2014 12:55 AM, Christer Holmberg wrote: >>> Hi, >>>=20 >>> As those of you who attended the virtual meeting yesterday know, I=20= >>> presented a suggestion for using the rtcweb data channel for=20 >>> transporting the CLUE protocol messages. >>>=20 >>> We recognized that there ARE a few things that need to be sorted out=20= >>> and clarified (you may have seen the e-mails I've sent to the = rtcweb-=20 >>> and mmusic lists), but in general I think we should decide (or, at=20= >>> least making a working assumption) whether we'll use the rtcweb = mechanism. >>>=20 >>> Again, there are details that need to be sorted out, and we can=20 >>> always reverse any decision we make. But, I do NOT want to wait = until=20 >>> London for making a decision in the first place. I want us to sort=20= >>> out details and open issues in London. >>>=20 >>> Personally I think that having interoperability with rtcweb is=20 >>> extremely valuable - unless, of course, it causes a great burden for=20= >>> CLUE, or unless the mechanism is technically unfeasible for CLUE. So=20= >>> far I have not heard any indication of either, and we also saw a = demo=20 >>> showing that it is possible to use the mechanism. >>>=20 >>> I also don't think that, due to the dependency on rtcweb that such=20= >>> decision would create, there is a big risk of CLUE being delayed. In=20= >>> my opinion, the data channel mechanism is probably the most stable=20= >>> thing of the things rtcweb is currently working on. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> clue mailing 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 >=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_49D4E25E-1707-467C-80D8-2D5926232B3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi Christer,

Simon, do you = use the DCP in your demo?

In my demo I just make use of the 'plain' WebRTC API. = Basically:

- the channel initiator = does this (Note: pc is the available PeerConnection = object):

sendChannel =3D = pc.createDataChannel("sendDataChannel" , {reliable: true});

This results in the following SDP = lines (note that "video" and "data channel" data are bundled = together):

m=3Dapplication 1 =
RTP/SAVPF 101
c=3DIN IP4 0.0.0.0
a=3Drtcp:1 IN IP4 0.0.0.0
a=3Dice-ufrag:7Do/ydOMrH5lwzBn
a=3Dice-pwd:b3D+HG9L+SzimBRJcWUqZgti
a=3Dice-options:google-ice
a=3Dfingerprint:sha-256 =
DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A=
:D5:3A:7D:6C:A1:00:6D
a=3Dsetup:actpass
a=3Dmid:data
a=3Dsendrecv
b=3DAS:30
a=3Drtcp-mux
a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 =
inline:1CFp/gR+88d3ig0EcgluA0yGumtiKI8gxOH2f/ug
a=3Drtpmap:101 google-data/90000
a=3Dssrc:1049470780 cname:l6fp7zYgy3DkXQDN
a=3Dssrc:1049470780 msid:sendDataChannel sendDataChannel
a=3Dssrc:1049470780 mslabel:sendDataChannel
a=3Dssrc:1049470780 label:sendDataChannel


- the channel receiver in turn, does the following:

pc.ondatachannel =3D= gotReceiveChannel;

function gotReceiveChannel(event) {
= trace('Receive Channel Callback');
= receiveChannel =3D event.channel;
= receiveChannel.onmessage =3D handleMessage;
= receiveChannel.onopen =3D = handleReceiveChannelStateChange;
= receiveChannel.onclose =3D = handleReceiveChannelStateChange;
}

The following is an excerpt of the provided SDP = answer:
m=3Dapplication 1 RTP/SAVPF 101
c=3DIN IP4 0.0.0.0
a=3Drtcp:1 IN IP4 0.0.0.0
a=3Dice-ufrag:d0/jsCoioZ5wIqQ1
a=3Dice-pwd:pGoZXkLiO6HN5JZYsy3cSAhH
a=3Dfingerprint:sha-256 =
DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A=
:D5:3A:7D:6C:A1:00:6D
a=3Dsetup:active
a=3Dmid:data
a=3Dsendrecv
b=3DAS:30
a=3Drtcp-mux
a=3Drtpmap:101 google-data/90000
a=3Dssrc:1971010094 cname:icWWLWa/VsrZGHr3
a=3Dssrc:1971010094 msid:sendDataChannel sendDataChannel
a=3Dssrc:1971010094 mslabel:sendDataChannel
a=3Dssrc:1971010094 label:sendDataChannel

Hope this helps,
Simon



Regards,

Christer




On 29/01/2014 5:45 PM, Christer Holmberg = wrote:
Hi Christian,

Maybe I misunderstood = what you said, but the idea is that we would always use = draft-ietf-mmusic-sctp-sdp to negotiate and establish the DTLS/SCTP = channel, and use the rtcweb data channel mechanism.

The rtcweb data = channel mechanism then specifies the SCTP details, and the rtcweb data = channel protocol (still TBD whether it's mandated) is used to open the = channel, and indicate that it will be used for CLUE.

Regards,

Christer

-----Original = Message-----
From: = clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian
Groves
Sent: 29. tammikuuta = 2014 1:28
To: clue@ietf.org
Subject: Re: [clue] = RTCWEB data channel for CLUE?

Hello = Christer,

Are you asking that = rtcweb data channel is the ONLY method for establishing a CLUE channel? = or that it is one of the methods?

If = CLUE is being used in the rtcweb context then it would appear to make = sense to use the web data channel. However if rtcweb isn't being used = then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up the CLUE = channels?

I don't think there's = anything in the CLUE protocol/data model that would prevent either being = used.

Regards, Christian


On 29/01/2014 12:55 = AM, Christer Holmberg wrote:
Hi,

As those of you who attended the = virtual meeting yesterday know, I
presented a suggestion for using the rtcweb data channel = for
transporting the CLUE protocol = messages.

We recognized that there ARE a few things that need to be = sorted out
and clarified (you may have seen = the e-mails I've sent to the rtcweb-
and mmusic lists), but in general I think we should = decide (or, at
least making a working = assumption) whether we'll use the rtcweb mechanism.

Again, there are details that = need to be sorted out, and we can
always reverse any decision we make. But, I do NOT want = to wait until
London for making a decision in = the first place. I want us to sort
out details and open issues in London.

Personally I think that having = interoperability with rtcweb is
extremely valuable - unless, of course, it causes a great = burden for
CLUE, or unless the mechanism is = technically unfeasible for CLUE. So
far I have not heard any indication of either, and we = also saw a demo
showing that it is possible to = use the mechanism.

I also don't think that, due to the dependency on rtcweb = that such
decision would create, there is = a big risk of CLUE being delayed. In
my opinion, the data channel mechanism is probably the = most stable
thing of the things rtcweb is = currently working on.

Regards,

Christer



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




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

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






= --Apple-Mail=_49D4E25E-1707-467C-80D8-2D5926232B3C-- From pkyzivat@alum.mit.edu Wed Jan 29 08:29: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 1C0B51A03FB for ; Wed, 29 Jan 2014 08:29:40 -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_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 2Rr7mW1PrBQg for ; Wed, 29 Jan 2014 08:29:38 -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 14BC21A03D5 for ; Wed, 29 Jan 2014 08:29:37 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta01.westchester.pa.mail.comcast.net with comcast id KpJp1n0020Fqzac51sVbkP; Wed, 29 Jan 2014 16:29:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id KsVa1n00o3ZTu2S3UsVaww; Wed, 29 Jan 2014 16:29:35 +0000 Message-ID: <52E92C6E.2000000@alum.mit.edu> Date: Wed, 29 Jan 2014 11:29:34 -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: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <1483778D-D5BC-4AA2-AB9F-3EE688E20CCF@unina.it> In-Reply-To: <1483778D-D5BC-4AA2-AB9F-3EE688E20CCF@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391012975; bh=ynoB7ymfidZCdA/rK3ZN4umMtFPXbnucPg8SWGUy2Zk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nEtLOSKa5bP9SO8Z3rKOL+qFhidsSa23CC+W+6n3Dl7NKCBsXUI+7ynppl15jAMqy Ksl4USbgenFWYOzCkeP7eF4WfxEyZhuFGmT/L6GddKAud7e/M3eOsXuXovz6FcL7Xu qtZbK6akGbJpeqG6XbulFdS9l6tQrbvMfTNznMrfnIHvsNKedDFDNTBoWobhEBXWLo GbEnJCX/g+gSmmyQ+RR8UaRqkK6anE6JfKVU6E/rIDiqjjd1HjW+NzWwf/W9Rz5QUE N+gGNjWNbW6//HT4LJE9Eq3JN8vBbJFgVRWvj4nwbkJ0Mm7ugKVEPDT+D0zwZQTHgm ZH1J0D08eT7ZA== Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 29 Jan 2014 16:29:40 -0000 On 1/29/14 11:18 AM, Simon Pietro Romano wrote: > Hi Christer, > >> Simon, do you use the DCP in your demo? > > In my demo I just make use of the 'plain' WebRTC API. Basically: > > - the channel initiator does this (Note: pc is the available > PeerConnection object): > > sendChannel = pc.createDataChannel("sendDataChannel" , {reliable: true}); > > This results in the following SDP lines (note that "video" and "data > channel" data are bundled together): I don't see any bundle, or any video, just one m-line that makes no sense to me > m=application 1 RTP/SAVPF 101 What is the above? Its not sctp, or anything I understand as valid. Thanks, Paul > c=IN IP4 0.0.0.0 > a=rtcp:1 IN IP4 0.0.0.0 > a=ice-ufrag:7Do/ydOMrH5lwzBn > a=ice-pwd:b3D+HG9L+SzimBRJcWUqZgti > a=ice-options:google-ice > a=fingerprint:sha-256 DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D > a=setup:actpass > a=mid:data > a=sendrecv > b=AS:30 > a=rtcp-mux > a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:1CFp/gR+88d3ig0EcgluA0yGumtiKI8gxOH2f/ug > a=rtpmap:101 google-data/90000 > a=ssrc:1049470780 cname:l6fp7zYgy3DkXQDN > a=ssrc:1049470780 msid:sendDataChannel sendDataChannel > a=ssrc:1049470780 mslabel:sendDataChannel > a=ssrc:1049470780 label:sendDataChannel > > > > - the channel receiver in turn, does the following: > > pc.ondatachannel = gotReceiveChannel; > > function gotReceiveChannel(event) { > trace('Receive Channel Callback'); > receiveChannel = event.channel; > receiveChannel.onmessage = handleMessage; > receiveChannel.onopen = handleReceiveChannelStateChange; > receiveChannel.onclose = handleReceiveChannelStateChange; > } > > The following is an excerpt of the provided SDP answer: > > m=application 1 RTP/SAVPF 101 > c=IN IP4 0.0.0.0 > a=rtcp:1 IN IP4 0.0.0.0 > a=ice-ufrag:d0/jsCoioZ5wIqQ1 > a=ice-pwd:pGoZXkLiO6HN5JZYsy3cSAhH > a=fingerprint:sha-256 DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D > a=setup:active > a=mid:data > a=sendrecv > b=AS:30 > a=rtcp-mux > a=rtpmap:101 google-data/90000 > a=ssrc:1971010094 cname:icWWLWa/VsrZGHr3 > a=ssrc:1971010094 msid:sendDataChannel sendDataChannel > a=ssrc:1971010094 mslabel:sendDataChannel > a=ssrc:1971010094 label:sendDataChannel > > > Hope this helps, > > Simon > > > >> >> Regards, >> >> Christer >> >> >> >> >> On 29/01/2014 5:45 PM, Christer Holmberg wrote: >>> Hi Christian, >>> >>> Maybe I misunderstood what you said, but the idea is that we would >>> always use draft-ietf-mmusic-sctp-sdp to negotiate and establish the >>> DTLS/SCTP channel, and use the rtcweb data channel mechanism. >>> >>> The rtcweb data channel mechanism then specifies the SCTP details, >>> and the rtcweb data channel protocol (still TBD whether it's >>> mandated) is used to open the channel, and indicate that it will be >>> used for CLUE. >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: 29. tammikuuta 2014 1:28 >>> To: clue@ietf.org >>> Subject: Re: [clue] RTCWEB data channel for CLUE? >>> >>> Hello Christer, >>> >>> Are you asking that rtcweb data channel is the ONLY method for >>> establishing a CLUE channel? or that it is one of the methods? >>> >>> If CLUE is being used in the rtcweb context then it would appear to >>> make sense to use the web data channel. However if rtcweb isn't being >>> used then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up >>> the CLUE channels? >>> >>> I don't think there's anything in the CLUE protocol/data model that >>> would prevent either being used. >>> >>> Regards, Christian >>> >>> >>> On 29/01/2014 12:55 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> As those of you who attended the virtual meeting yesterday know, I >>>> presented a suggestion for using the rtcweb data channel for >>>> transporting the CLUE protocol messages. >>>> >>>> We recognized that there ARE a few things that need to be sorted out >>>> and clarified (you may have seen the e-mails I've sent to the rtcweb- >>>> and mmusic lists), but in general I think we should decide (or, at >>>> least making a working assumption) whether we'll use the rtcweb >>>> mechanism. >>>> >>>> Again, there are details that need to be sorted out, and we can >>>> always reverse any decision we make. But, I do NOT want to wait until >>>> London for making a decision in the first place. I want us to sort >>>> out details and open issues in London. >>>> >>>> Personally I think that having interoperability with rtcweb is >>>> extremely valuable - unless, of course, it causes a great burden for >>>> CLUE, or unless the mechanism is technically unfeasible for CLUE. So >>>> far I have not heard any indication of either, and we also saw a demo >>>> showing that it is possible to use the mechanism. >>>> >>>> I also don't think that, due to the dependency on rtcweb that such >>>> decision would create, there is a big risk of CLUE being delayed. In >>>> my opinion, the data channel mechanism is probably the most stable >>>> thing of the things rtcweb is currently working on. >>>> >>>> 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 >>> >> >> > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From spromano@unina.it Wed Jan 29 08:35: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 ACA6E1A02C8 for ; Wed, 29 Jan 2014 08:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.845 X-Spam-Level: * X-Spam-Status: No, score=1.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, 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 mHy8bH138Bqo for ; Wed, 29 Jan 2014 08:35:23 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id D0E5A1A0356 for ; Wed, 29 Jan 2014 08:35:22 -0800 (PST) Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s0TGZGqd009463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jan 2014 17:35:16 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1877C418-6BAD-4065-8658-1818C7BDC7C8" From: Simon Pietro Romano In-Reply-To: <52E92C6E.2000000@alum.mit.edu> Date: Wed, 29 Jan 2014 17:35:15 +0100 Message-Id: <2A7D2681-6AAE-4035-BD29-5D58A7A00F33@unina.it> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <1483778D-D5BC-4AA2-AB9F-3EE688E20CCF@unina.it> <52E92C6E.2000000@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: clue@ietf.org Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 29 Jan 2014 16:35:26 -0000 --Apple-Mail=_1877C418-6BAD-4065-8658-1818C7BDC7C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > I don't see any bundle, or any video, just one m-line that makes no = sense to me I copy-pasted just the relevant part, associated with the data channel = m-line... If you want a complete dump, here it is: type: offer, sdp: v=3D0 o=3D- 5103351260166074998 2 IN IP4 127.0.0.1 s=3D- t=3D0 0 a=3Dgroup:BUNDLE video data a=3Dmsid-semantic: WMS HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz m=3Dvideo 1 RTP/SAVPF 100 116 117 c=3DIN IP4 0.0.0.0 a=3Drtcp:1 IN IP4 0.0.0.0 a=3Dice-ufrag:Hokk+0T0UPC3dvNu a=3Dice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/ a=3Dice-options:google-ice a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D a=3Dsetup:actpass a=3Dmid:video a=3Dextmap:2 urn:ietf:params:rtp-hdrext:toffset a=3Dextmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=3Dsendrecv a=3Drtcp-mux a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 = inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA a=3Drtpmap:100 VP8/90000 a=3Drtcp-fb:100 ccm fir a=3Drtcp-fb:100 nack a=3Drtcp-fb:100 nack pli a=3Drtcp-fb:100 goog-remb a=3Drtpmap:116 red/90000 a=3Drtpmap:117 ulpfec/90000 a=3Dssrc:3100544884 cname:S+mwxWG9Y7xCa1i2 a=3Dssrc:3100544884 msid:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz = a35c161e-74ca-4ada-8b79-909e708b583b a=3Dssrc:3100544884 mslabel:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz a=3Dssrc:3100544884 label:a35c161e-74ca-4ada-8b79-909e708b583b m=3Dapplication 1 RTP/SAVPF 101 c=3DIN IP4 0.0.0.0 a=3Drtcp:1 IN IP4 0.0.0.0 a=3Dice-ufrag:Hokk+0T0UPC3dvNu a=3Dice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/ a=3Dice-options:google-ice a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D a=3Dsetup:actpass a=3Dmid:data a=3Dsendrecv b=3DAS:30 a=3Drtcp-mux a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 = inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA a=3Drtpmap:101 google-data/90000 a=3Dssrc:1569838440 cname:gG2TR57LvWPMBVd3 a=3Dssrc:1569838440 msid:sendDataChannel sendDataChannel a=3Dssrc:1569838440 mslabel:sendDataChannel a=3Dssrc:1569838440 label:sendDataChannel Simon >=20 >> m=3Dapplication 1 RTP/SAVPF 101 >=20 > What is the above? Its not sctp, or anything I understand as valid. >=20 > Thanks, > Paul >=20 >> c=3DIN IP4 0.0.0.0 >> a=3Drtcp:1 IN IP4 0.0.0.0 >> a=3Dice-ufrag:7Do/ydOMrH5lwzBn >> a=3Dice-pwd:b3D+HG9L+SzimBRJcWUqZgti >> a=3Dice-options:google-ice >> a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D >> a=3Dsetup:actpass >> a=3Dmid:data >> a=3Dsendrecv >> b=3DAS:30 >> a=3Drtcp-mux >> a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 = inline:1CFp/gR+88d3ig0EcgluA0yGumtiKI8gxOH2f/ug >> a=3Drtpmap:101 google-data/90000 >> a=3Dssrc:1049470780 cname:l6fp7zYgy3DkXQDN >> a=3Dssrc:1049470780 msid:sendDataChannel sendDataChannel >> a=3Dssrc:1049470780 mslabel:sendDataChannel >> a=3Dssrc:1049470780 label:sendDataChannel >>=20 >>=20 >>=20 >> - the channel receiver in turn, does the following: >>=20 >> pc.ondatachannel =3D gotReceiveChannel; >>=20 >> function gotReceiveChannel(event) { >> trace('Receive Channel Callback'); >> receiveChannel =3D event.channel; >> receiveChannel.onmessage =3D handleMessage; >> receiveChannel.onopen =3D handleReceiveChannelStateChange; >> receiveChannel.onclose =3D handleReceiveChannelStateChange; >> } >>=20 >> The following is an excerpt of the provided SDP answer: >>=20 >> m=3Dapplication 1 RTP/SAVPF 101 >> c=3DIN IP4 0.0.0.0 >> a=3Drtcp:1 IN IP4 0.0.0.0 >> a=3Dice-ufrag:d0/jsCoioZ5wIqQ1 >> a=3Dice-pwd:pGoZXkLiO6HN5JZYsy3cSAhH >> a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D >> a=3Dsetup:active >> a=3Dmid:data >> a=3Dsendrecv >> b=3DAS:30 >> a=3Drtcp-mux >> a=3Drtpmap:101 google-data/90000 >> a=3Dssrc:1971010094 cname:icWWLWa/VsrZGHr3 >> a=3Dssrc:1971010094 msid:sendDataChannel sendDataChannel >> a=3Dssrc:1971010094 mslabel:sendDataChannel >> a=3Dssrc:1971010094 label:sendDataChannel >>=20 >>=20 >> Hope this helps, >>=20 >> Simon >>=20 >>=20 >>=20 >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>>=20 >>> On 29/01/2014 5:45 PM, Christer Holmberg wrote: >>>> Hi Christian, >>>>=20 >>>> Maybe I misunderstood what you said, but the idea is that we would >>>> always use draft-ietf-mmusic-sctp-sdp to negotiate and establish = the >>>> DTLS/SCTP channel, and use the rtcweb data channel mechanism. >>>>=20 >>>> The rtcweb data channel mechanism then specifies the SCTP details, >>>> and the rtcweb data channel protocol (still TBD whether it's >>>> mandated) is used to open the channel, and indicate that it will be >>>> used for CLUE. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>> Groves >>>> Sent: 29. tammikuuta 2014 1:28 >>>> To: clue@ietf.org >>>> Subject: Re: [clue] RTCWEB data channel for CLUE? >>>>=20 >>>> Hello Christer, >>>>=20 >>>> Are you asking that rtcweb data channel is the ONLY method for >>>> establishing a CLUE channel? or that it is one of the methods? >>>>=20 >>>> If CLUE is being used in the rtcweb context then it would appear to >>>> make sense to use the web data channel. However if rtcweb isn't = being >>>> used then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up >>>> the CLUE channels? >>>>=20 >>>> I don't think there's anything in the CLUE protocol/data model that >>>> would prevent either being used. >>>>=20 >>>> Regards, Christian >>>>=20 >>>>=20 >>>> On 29/01/2014 12:55 AM, Christer Holmberg wrote: >>>>> Hi, >>>>>=20 >>>>> As those of you who attended the virtual meeting yesterday know, I >>>>> presented a suggestion for using the rtcweb data channel for >>>>> transporting the CLUE protocol messages. >>>>>=20 >>>>> We recognized that there ARE a few things that need to be sorted = out >>>>> and clarified (you may have seen the e-mails I've sent to the = rtcweb- >>>>> and mmusic lists), but in general I think we should decide (or, at >>>>> least making a working assumption) whether we'll use the rtcweb >>>>> mechanism. >>>>>=20 >>>>> Again, there are details that need to be sorted out, and we can >>>>> always reverse any decision we make. But, I do NOT want to wait = until >>>>> London for making a decision in the first place. I want us to sort >>>>> out details and open issues in London. >>>>>=20 >>>>> Personally I think that having interoperability with rtcweb is >>>>> extremely valuable - unless, of course, it causes a great burden = for >>>>> CLUE, or unless the mechanism is technically unfeasible for CLUE. = So >>>>> far I have not heard any indication of either, and we also saw a = demo >>>>> showing that it is possible to use the mechanism. >>>>>=20 >>>>> I also don't think that, due to the dependency on rtcweb that such >>>>> decision would create, there is a big risk of CLUE being delayed. = In >>>>> my opinion, the data channel mechanism is probably the most stable >>>>> thing of the things rtcweb is currently working on. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> clue mailing 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 >>>=20 >>>=20 >>=20 >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >>=20 >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> = (_/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_1877C418-6BAD-4065-8658-1818C7BDC7C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
I don't see any bundle, or any = video, just one m-line that makes no sense to = me

I copy-pasted just the relevant = part, associated with the data channel = m-line...

If you want a complete dump, here it = is:

type: offer, sdp: =
v=3D0
o=3D- 5103351260166074998 2 IN IP4 127.0.0.1
s=3D-
t=3D0 0
a=3Dgroup:BUNDLE video data
a=3Dmsid-semantic: WMS HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz
m=3Dvideo 1 RTP/SAVPF 100 116 117
c=3DIN IP4 0.0.0.0
a=3Drtcp:1 IN IP4 0.0.0.0
a=3Dice-ufrag:Hokk+0T0UPC3dvNu
a=3Dice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/
a=3Dice-options:google-ice
a=3Dfingerprint:sha-256 =
DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A=
:D5:3A:7D:6C:A1:00:6D
a=3Dsetup:actpass
a=3Dmid:video
a=3Dextmap:2 urn:ietf:params:rtp-hdrext:toffset
a=3Dextmap:3 http:/=
/www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=3Dsendrecv
a=3Drtcp-mux
a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 =
inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA
a=3Drtpmap:100 VP8/90000
a=3Drtcp-fb:100 ccm fir
a=3Drtcp-fb:100 nack
a=3Drtcp-fb:100 nack pli
a=3Drtcp-fb:100 goog-remb
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Dssrc:3100544884 cname:S+mwxWG9Y7xCa1i2
a=3Dssrc:3100544884 msid:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz =
a35c161e-74ca-4ada-8b79-909e708b583b
a=3Dssrc:3100544884 mslabel:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz
a=3Dssrc:3100544884 label:a35c161e-74ca-4ada-8b79-909e708b583b
m=3Dapplication 1 RTP/SAVPF 101
c=3DIN IP4 0.0.0.0
a=3Drtcp:1 IN IP4 0.0.0.0
a=3Dice-ufrag:Hokk+0T0UPC3dvNu
a=3Dice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/
a=3Dice-options:google-ice
a=3Dfingerprint:sha-256 =
DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A=
:D5:3A:7D:6C:A1:00:6D
a=3Dsetup:actpass
a=3Dmid:data
a=3Dsendrecv
b=3DAS:30
a=3Drtcp-mux
a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 =
inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA
a=3Drtpmap:101 google-data/90000
a=3Dssrc:1569838440 cname:gG2TR57LvWPMBVd3
a=3Dssrc:1569838440 msid:sendDataChannel sendDataChannel
a=3Dssrc:1569838440 mslabel:sendDataChannel
a=3Dssrc:1569838440 =
label:sendDataChannel

Simon

<= blockquote type=3D"cite">

m=3Dapplicatio= n 1 RTP/SAVPF 101

What is the above? Its not sctp, = or anything I understand as valid.

Thanks,
= Paul

c=3DIN IP4 = 0.0.0.0
a=3Drtcp:1 IN IP4 = 0.0.0.0
a=3Dice-ufrag:7Do/ydOMrH5lwzBn
a=3Dice-pwd:b3D+HG9L+SzimBRJcWUqZgti
a=3Dice-options:google-ice
a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D
a=3Dsetup:actpass
a=3Dmid:data
a=3Dsendrecv
b=3DAS:30
a=3Drtcp-mux
a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 = inline:1CFp/gR+88d3ig0EcgluA0yGumtiKI8gxOH2f/ug
a=3Drtpmap:101 = google-data/90000
a=3Dssrc:1049470780 = cname:l6fp7zYgy3DkXQDN
a=3Dssrc:1049470780 msid:sendDataChannel = sendDataChannel
a=3Dssrc:1049470780 = mslabel:sendDataChannel
a=3Dssrc:1049470780 = label:sendDataChannel



- the channel = receiver in turn, does the following:

pc.ondatachannel = =3D gotReceiveChannel;

function = gotReceiveChannel(event) {
trace('Receive Channel = Callback');
receiveChannel =3D = event.channel;
receiveChannel.onmessage =3D = handleMessage;
receiveChannel.onopen =3D = handleReceiveChannelStateChange;
receiveChannel.onclose =3D = handleReceiveChannelStateChange;
}

The following = is an excerpt of the provided SDP answer:

m=3Dapplication = 1 RTP/SAVPF 101
c=3DIN IP4 = 0.0.0.0
a=3Drtcp:1 IN IP4 = 0.0.0.0
a=3Dice-ufrag:d0/jsCoioZ5wIqQ1
a=3Dice-pwd:pGoZXkLiO6HN5JZYsy3cSAhH
a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D
a=3Dsetup:active
a=3Dmid:data
a=3Dsendrecv
b=3DAS:30
a=3Drtcp-mux
a=3Drtpmap:101 = google-data/90000
a=3Dssrc:1971010094 = cname:icWWLWa/VsrZGHr3
a=3Dssrc:1971010094 msid:sendDataChannel = sendDataChannel
a=3Dssrc:1971010094 = mslabel:sendDataChannel
a=3Dssrc:1971010094 = label:sendDataChannel


Hope this = helps,

Simon




Regards,

Christer




On 29/01/2014 5:45 PM, Christer = Holmberg wrote:
Hi = Christian,

Maybe = I misunderstood what you said, but the idea is that we = would
always = use draft-ietf-mmusic-sctp-sdp to negotiate and establish = the
DTLS/SCTP channel, and use the rtcweb data channel = mechanism.

The = rtcweb data channel mechanism then specifies the SCTP = details,
and = the rtcweb data channel protocol (still TBD whether = it's
mandated) is used to open the channel, and indicate that = it will be
used = for CLUE.

Regards,

Christer

-----Original = Message-----
From: = clue [mailto:clue-bounces@ietf.org] On Behalf Of = Christian
Groves
Sent: = 29. tammikuuta 2014 = 1:28
To: clue@ietf.org <mailto:clue@ietf.org>
Subject: Re: [clue] RTCWEB data = channel for CLUE?

Hello = Christer,

Are = you asking that rtcweb data channel is the ONLY method = for
establishing a CLUE channel? or that it is one of the = methods?

If = CLUE is being used in the rtcweb context then it would appear = to
make = sense to use the web data channel. However if rtcweb isn't = being
used = then why couldn't we use draft-ietf-mmusic-sctp-sdp to set = up
the = CLUE channels?

I = don't think there's anything in the CLUE protocol/data model = that
would = prevent either being = used.

Regards,= Christian


On = 29/01/2014 12:55 AM, Christer Holmberg = wrote:
Hi,
<= blockquote type=3D"cite">

As those of you who attended the = virtual meeting yesterday know, = I
presented a suggestion for using = the rtcweb data channel = for
transporting the CLUE protocol = messages.

We recognized that there ARE a = few things that need to be sorted = out
and clarified (you may have seen = the e-mails I've sent to the = rtcweb-
and mmusic lists), but in = general I think we should decide (or, = at
least making a working = assumption) whether we'll use the = rtcweb
mechanism.

Again, there are details that = need to be sorted out, and we = can
always reverse any decision we = make. But, I do NOT want to wait = until
London for making a decision in = the first place. I want us to = sort
out details and open issues in = London.

Personally I think that having = interoperability with rtcweb = is
extremely valuable - unless, of = course, it causes a great burden = for
CLUE, or unless the mechanism is = technically unfeasible for CLUE. = So
far I have not heard any = indication of either, and we also saw a = demo
showing that it is possible to = use the = mechanism.

I also don't think that, due to = the dependency on rtcweb that = such
decision would create, there is = a big risk of CLUE being delayed. = In
my opinion, the data channel = mechanism is probably the most = stable
thing of the things rtcweb is = currently working = on.

Regards,

Christer



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




=       _\\|//_
      ( O-O = )
=    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~= ~~~
Simon Pietro = Romano
Universita' di Napoli = Federico II
=      Computer Engineering = Department
=             &n= bsp;Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
=             &n= bsp;           &nbs= p;            =       e-mail: spromano@unina.it
<mailto:spromano@unina.it>

    <<Molti mi dicono che lo = scoraggiamento =E8 l'alibi degli
    idioti. Ci rifletto un istante; e = mi scoraggio>>. Magritte.
= =             &n= bsp;        oooO
<= blockquote type=3D"cite">   ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ = Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=             &n= bsp;    \ ( =            ( =   )
=             &n= bsp;           &nbs= p;         \_) =          ) = /
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;         (_/








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


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


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

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






= --Apple-Mail=_1877C418-6BAD-4065-8658-1818C7BDC7C8-- From pkyzivat@alum.mit.edu Wed Jan 29 08:52: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 91F321A03D5 for ; Wed, 29 Jan 2014 08:52:16 -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_12=0.6, J_CHICKENPOX_15=0.6, 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 1Ux2BXB9czkG for ; Wed, 29 Jan 2014 08:52:14 -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 BFCD61A03D4 for ; Wed, 29 Jan 2014 08:52:13 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta08.westchester.pa.mail.comcast.net with comcast id Kplk1n0040xGWP858ssAsz; Wed, 29 Jan 2014 16:52:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id KssA1n00B3ZTu2S3YssAX9; Wed, 29 Jan 2014 16:52:10 +0000 Message-ID: <52E931BA.6060804@alum.mit.edu> Date: Wed, 29 Jan 2014 11:52:10 -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: Simon Pietro Romano References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <1483778D-D5BC-4AA2-AB9F-3EE688E20CCF@unina.it> <52E92C6E.2000000@alum.mit.edu> <2A7D2681-6AAE-4035-BD29-5D58A7A00F33@unina.it> In-Reply-To: <2A7D2681-6AAE-4035-BD29-5D58A7A00F33@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391014330; bh=qB81dvqTgjh5Yk4XgAwTKNVEcnNzHEpXQZ61I43Jw7I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HkF8/H+gUz36ZwbOiakqY0K/rn0aTnvofyKNCqZzx4Afw0VzS5hPkSLzJmMY/a3Fc KGYfjFUsSiXZg0Y4RMACG2yz145t12Sf6vUtttIJLgn4c5kza60deJRJD/uFCrClF4 KtR6yE2RepBDWFahYx5uD8A25dhqaeIfCgFfmSjDnDD9tooDQIg7DUxnFtDcG2WD3r xiyMs+SalKUw9ZG7ar4wuTbqUubwFCFeGNOwNLf+AOyaJbGHq3OEDZ5UqnihFqlKXh OGaN8uxN1qT1lOE6NaEax8uvfpiK9MTAsxKekvi4kWhs1O+TsR3RmMgS3h3gBnwq1l ZVvONSnT3W7ow== Cc: clue@ietf.org Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 29 Jan 2014 16:52:16 -0000 On 1/29/14 11:35 AM, Simon Pietro Romano wrote: >> I don't see any bundle, or any video, just one m-line that makes no >> sense to me > > I copy-pasted just the relevant part, associated with the data channel > m-line... > > If you want a complete dump, here it is: Thanks. I see this is still a work in progress, and google-specific. It isn't following draft-ietf-mmusic-sctp-sdp. (And I don't find any iana registration for mime type application/google-data.) I trust this is just implementation getting ahead of the standards work. Thanks, Paul > type: offer, sdp: v=0 > o=- 5103351260166074998 2 IN IP4 127.0.0.1 > s=- > t=0 0 > a=group:BUNDLE video data > a=msid-semantic: WMS HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz > m=video 1 RTP/SAVPF 100 116 117 > c=IN IP4 0.0.0.0 > a=rtcp:1 IN IP4 0.0.0.0 > a=ice-ufrag:Hokk+0T0UPC3dvNu > a=ice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/ > a=ice-options:google-ice > a=fingerprint:sha-256 DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D > a=setup:actpass > a=mid:video > a=extmap:2 urn:ietf:params:rtp-hdrext:toffset > a=extmap:3http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time > a=sendrecv > a=rtcp-mux > a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA > a=rtpmap:100 VP8/90000 > a=rtcp-fb:100 ccm fir > a=rtcp-fb:100 nack > a=rtcp-fb:100 nack pli > a=rtcp-fb:100 goog-remb > a=rtpmap:116 red/90000 > a=rtpmap:117 ulpfec/90000 > a=ssrc:3100544884 cname:S+mwxWG9Y7xCa1i2 > a=ssrc:3100544884 msid:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz a35c161e-74ca-4ada-8b79-909e708b583b > a=ssrc:3100544884 mslabel:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz > a=ssrc:3100544884 label:a35c161e-74ca-4ada-8b79-909e708b583b > m=application 1 RTP/SAVPF 101 > c=IN IP4 0.0.0.0 > a=rtcp:1 IN IP4 0.0.0.0 > a=ice-ufrag:Hokk+0T0UPC3dvNu > a=ice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/ > a=ice-options:google-ice > a=fingerprint:sha-256 DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D > a=setup:actpass > a=mid:data > a=sendrecv > b=AS:30 > a=rtcp-mux > a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA > a=rtpmap:101 google-data/90000 > a=ssrc:1569838440 cname:gG2TR57LvWPMBVd3 > a=ssrc:1569838440 msid:sendDataChannel sendDataChannel > a=ssrc:1569838440 mslabel:sendDataChannel > a=ssrc:1569838440 label:sendDataChannel > > > Simon > >> >>> m=application 1 RTP/SAVPF 101 >> >> What is the above? Its not sctp, or anything I understand as valid. >> >> Thanks, >> Paul >> >>> c=IN IP4 0.0.0.0 >>> a=rtcp:1 IN IP4 0.0.0.0 >>> a=ice-ufrag:7Do/ydOMrH5lwzBn >>> a=ice-pwd:b3D+HG9L+SzimBRJcWUqZgti >>> a=ice-options:google-ice >>> a=fingerprint:sha-256 >>> DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D >>> a=setup:actpass >>> a=mid:data >>> a=sendrecv >>> b=AS:30 >>> a=rtcp-mux >>> a=crypto:0 AES_CM_128_HMAC_SHA1_80 >>> inline:1CFp/gR+88d3ig0EcgluA0yGumtiKI8gxOH2f/ug >>> a=rtpmap:101 google-data/90000 >>> a=ssrc:1049470780 cname:l6fp7zYgy3DkXQDN >>> a=ssrc:1049470780 msid:sendDataChannel sendDataChannel >>> a=ssrc:1049470780 mslabel:sendDataChannel >>> a=ssrc:1049470780 label:sendDataChannel >>> >>> >>> >>> - the channel receiver in turn, does the following: >>> >>> pc.ondatachannel = gotReceiveChannel; >>> >>> function gotReceiveChannel(event) { >>> trace('Receive Channel Callback'); >>> receiveChannel = event.channel; >>> receiveChannel.onmessage = handleMessage; >>> receiveChannel.onopen = handleReceiveChannelStateChange; >>> receiveChannel.onclose = handleReceiveChannelStateChange; >>> } >>> >>> The following is an excerpt of the provided SDP answer: >>> >>> m=application 1 RTP/SAVPF 101 >>> c=IN IP4 0.0.0.0 >>> a=rtcp:1 IN IP4 0.0.0.0 >>> a=ice-ufrag:d0/jsCoioZ5wIqQ1 >>> a=ice-pwd:pGoZXkLiO6HN5JZYsy3cSAhH >>> a=fingerprint:sha-256 >>> DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D >>> a=setup:active >>> a=mid:data >>> a=sendrecv >>> b=AS:30 >>> a=rtcp-mux >>> a=rtpmap:101 google-data/90000 >>> a=ssrc:1971010094 cname:icWWLWa/VsrZGHr3 >>> a=ssrc:1971010094 msid:sendDataChannel sendDataChannel >>> a=ssrc:1971010094 mslabel:sendDataChannel >>> a=ssrc:1971010094 label:sendDataChannel >>> >>> >>> Hope this helps, >>> >>> Simon >>> >>> >>> >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> On 29/01/2014 5:45 PM, Christer Holmberg wrote: >>>>> Hi Christian, >>>>> >>>>> Maybe I misunderstood what you said, but the idea is that we would >>>>> always use draft-ietf-mmusic-sctp-sdp to negotiate and establish the >>>>> DTLS/SCTP channel, and use the rtcweb data channel mechanism. >>>>> >>>>> The rtcweb data channel mechanism then specifies the SCTP details, >>>>> and the rtcweb data channel protocol (still TBD whether it's >>>>> mandated) is used to open the channel, and indicate that it will be >>>>> used for CLUE. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>> Groves >>>>> Sent: 29. tammikuuta 2014 1:28 >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] RTCWEB data channel for CLUE? >>>>> >>>>> Hello Christer, >>>>> >>>>> Are you asking that rtcweb data channel is the ONLY method for >>>>> establishing a CLUE channel? or that it is one of the methods? >>>>> >>>>> If CLUE is being used in the rtcweb context then it would appear to >>>>> make sense to use the web data channel. However if rtcweb isn't being >>>>> used then why couldn't we use draft-ietf-mmusic-sctp-sdp to set up >>>>> the CLUE channels? >>>>> >>>>> I don't think there's anything in the CLUE protocol/data model that >>>>> would prevent either being used. >>>>> >>>>> Regards, Christian >>>>> >>>>> >>>>> On 29/01/2014 12:55 AM, Christer Holmberg wrote: >>>>>> Hi, >>>>>> >>>>>> As those of you who attended the virtual meeting yesterday know, I >>>>>> presented a suggestion for using the rtcweb data channel for >>>>>> transporting the CLUE protocol messages. >>>>>> >>>>>> We recognized that there ARE a few things that need to be sorted out >>>>>> and clarified (you may have seen the e-mails I've sent to the rtcweb- >>>>>> and mmusic lists), but in general I think we should decide (or, at >>>>>> least making a working assumption) whether we'll use the rtcweb >>>>>> mechanism. >>>>>> >>>>>> Again, there are details that need to be sorted out, and we can >>>>>> always reverse any decision we make. But, I do NOT want to wait until >>>>>> London for making a decision in the first place. I want us to sort >>>>>> out details and open issues in London. >>>>>> >>>>>> Personally I think that having interoperability with rtcweb is >>>>>> extremely valuable - unless, of course, it causes a great burden for >>>>>> CLUE, or unless the mechanism is technically unfeasible for CLUE. So >>>>>> far I have not heard any indication of either, and we also saw a demo >>>>>> showing that it is possible to use the mechanism. >>>>>> >>>>>> I also don't think that, due to the dependency on rtcweb that such >>>>>> decision would create, there is a big risk of CLUE being delayed. In >>>>>> my opinion, the data channel mechanism is probably the most stable >>>>>> thing of the things rtcweb is currently working on. >>>>>> >>>>>> 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 >>>>> >>>> >>>> >>> >>> _\\|//_ >>> ( O-O ) >>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>> Simon Pietro Romano >>> Universita' di Napoli Federico II >>> Computer Engineering Department >>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>> e-mail: spromano@unina.it >>> >>> >>> >>> <>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>> oooO >>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>> \ ( ( ) >>> \_) ) / >>> (_/ >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > From spromano@unina.it Wed Jan 29 09:07: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 25E551A0471 for ; Wed, 29 Jan 2014 09:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.826 X-Spam-Level: ** X-Spam-Status: No, score=2.826 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, 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 uFE4dsiXBhZp for ; Wed, 29 Jan 2014 09:07:03 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 817561A046C for ; Wed, 29 Jan 2014 09:07:02 -0800 (PST) Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s0TH6t7v012484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jan 2014 18:06:56 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_5D91ACE1-EE48-4217-A816-71FF9148D67B" From: Simon Pietro Romano In-Reply-To: <52E931BA.6060804@alum.mit.edu> Date: Wed, 29 Jan 2014 18:06:55 +0100 Message-Id: <5E88D21E-84A3-4D29-B3D6-7D3BBD1EBB95@unina.it> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <1483778D-D5BC-4AA2-AB9F-3EE688E20CCF@unina.it> <52E92C6E.2000000@alum.mit.edu> <2A7D2681-6AAE-4035-BD29-5D58A7A00F33@unina.it> <52E931BA.6060804@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: clue@ietf.org Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 29 Jan 2014 17:07:07 -0000 --Apple-Mail=_5D91ACE1-EE48-4217-A816-71FF9148D67B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Paul, > Thanks. I see this is still a work in progress, and google-specific. > It isn't following draft-ietf-mmusic-sctp-sdp. (And I don't find any = iana registration for mime type application/google-data.) >=20 > I trust this is just implementation getting ahead of the standards = work. It actually is. I dumped the SDP on the following browser (Chrome = Canary):=20 Version 34.0.1811.0 canary If you want to have an idea of how this stuff looks like in Firefox = (Nightly build, release 29.0a1), here is a similar dump: *Note Well: here the data channel is negotiated like this (see end of = the dump): m=3Dapplication 58232 DTLS/SCTP 5000 sdp:"v=3D0 o=3DMozilla-SIPUA-29.0a1 27617 0 IN IP4 0.0.0.0 s=3DSIP Call t=3D0 0 a=3Dice-ufrag:e42fa2c1 a=3Dice-pwd:fb40d85ac9eb85690de66e4c58df2d55 a=3Dfingerprint:sha-256 = FE:AF:92:3D:29:3B:23:98:A2:24:3C:0B:35:A3:33:08:6A:FB:2F:59:F8:6D:82:AB:9F= :53:C8:2F:D0:9B:80:E5 m=3Daudio 56393 RTP/SAVPF 109 0 8 101 c=3DIN IP4 100.71.44.223 a=3Drtpmap:109 opus/48000/2 a=3Dptime:20 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:8 PCMA/8000 a=3Drtpmap:101 telephone-event/8000 a=3Dfmtp:101 0-15 a=3Drecvonly a=3Dsetup:actpass a=3Dcandidate:0 1 UDP 2130379007 143.225.28.167 53116 typ host a=3Dcandidate:2 1 UDP 2130444543 100.71.44.223 56393 typ host a=3Dcandidate:0 2 UDP 2130379006 143.225.28.167 57887 typ host a=3Dcandidate:2 2 UDP 2130444542 100.71.44.223 57653 typ host a=3Drtcp-mux m=3Dvideo 63084 RTP/SAVPF 120 c=3DIN IP4 100.71.44.223 a=3Drtpmap:120 VP8/90000 a=3Dsendrecv a=3Drtcp-fb:120 nack a=3Drtcp-fb:120 nack pli a=3Drtcp-fb:120 ccm fir a=3Dsetup:actpass a=3Dcandidate:0 1 UDP 2130379007 143.225.28.167 64657 typ host a=3Dcandidate:2 1 UDP 2130444543 100.71.44.223 63084 typ host a=3Dcandidate:0 2 UDP 2130379006 143.225.28.167 56287 typ host a=3Dcandidate:2 2 UDP 2130444542 100.71.44.223 53824 typ host a=3Drtcp-mux m=3Dapplication 58232 DTLS/SCTP 5000=20 c=3DIN IP4 100.71.44.223 a=3Dsctpmap:5000 webrtc-datachannel 16 a=3Dsetup:actpass Hope this helps, Simon >=20 > Thanks, > Paul >=20 >> type: offer, sdp: v=3D0 >> o=3D- 5103351260166074998 2 IN IP4 127.0.0.1 >> s=3D- >> t=3D0 0 >> a=3Dgroup:BUNDLE video data >> a=3Dmsid-semantic: WMS HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz >> m=3Dvideo 1 RTP/SAVPF 100 116 117 >> c=3DIN IP4 0.0.0.0 >> a=3Drtcp:1 IN IP4 0.0.0.0 >> a=3Dice-ufrag:Hokk+0T0UPC3dvNu >> a=3Dice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/ >> a=3Dice-options:google-ice >> a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D >> a=3Dsetup:actpass >> a=3Dmid:video >> a=3Dextmap:2 urn:ietf:params:rtp-hdrext:toffset >> a=3Dextmap:3http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time >> a=3Dsendrecv >> a=3Drtcp-mux >> a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 = inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA >> a=3Drtpmap:100 VP8/90000 >> a=3Drtcp-fb:100 ccm fir >> a=3Drtcp-fb:100 nack >> a=3Drtcp-fb:100 nack pli >> a=3Drtcp-fb:100 goog-remb >> a=3Drtpmap:116 red/90000 >> a=3Drtpmap:117 ulpfec/90000 >> a=3Dssrc:3100544884 cname:S+mwxWG9Y7xCa1i2 >> a=3Dssrc:3100544884 msid:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz = a35c161e-74ca-4ada-8b79-909e708b583b >> a=3Dssrc:3100544884 mslabel:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz >> a=3Dssrc:3100544884 label:a35c161e-74ca-4ada-8b79-909e708b583b >> m=3Dapplication 1 RTP/SAVPF 101 >> c=3DIN IP4 0.0.0.0 >> a=3Drtcp:1 IN IP4 0.0.0.0 >> a=3Dice-ufrag:Hokk+0T0UPC3dvNu >> a=3Dice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/ >> a=3Dice-options:google-ice >> a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D >> a=3Dsetup:actpass >> a=3Dmid:data >> a=3Dsendrecv >> b=3DAS:30 >> a=3Drtcp-mux >> a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 = inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA >> a=3Drtpmap:101 google-data/90000 >> a=3Dssrc:1569838440 cname:gG2TR57LvWPMBVd3 >> a=3Dssrc:1569838440 msid:sendDataChannel sendDataChannel >> a=3Dssrc:1569838440 mslabel:sendDataChannel >> a=3Dssrc:1569838440 label:sendDataChannel >>=20 >>=20 >> Simon >>=20 >>>=20 >>>> m=3Dapplication 1 RTP/SAVPF 101 >>>=20 >>> What is the above? Its not sctp, or anything I understand as valid. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> c=3DIN IP4 0.0.0.0 >>>> a=3Drtcp:1 IN IP4 0.0.0.0 >>>> a=3Dice-ufrag:7Do/ydOMrH5lwzBn >>>> a=3Dice-pwd:b3D+HG9L+SzimBRJcWUqZgti >>>> a=3Dice-options:google-ice >>>> a=3Dfingerprint:sha-256 >>>> = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D >>>> a=3Dsetup:actpass >>>> a=3Dmid:data >>>> a=3Dsendrecv >>>> b=3DAS:30 >>>> a=3Drtcp-mux >>>> a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 >>>> inline:1CFp/gR+88d3ig0EcgluA0yGumtiKI8gxOH2f/ug >>>> a=3Drtpmap:101 google-data/90000 >>>> a=3Dssrc:1049470780 cname:l6fp7zYgy3DkXQDN >>>> a=3Dssrc:1049470780 msid:sendDataChannel sendDataChannel >>>> a=3Dssrc:1049470780 mslabel:sendDataChannel >>>> a=3Dssrc:1049470780 label:sendDataChannel >>>>=20 >>>>=20 >>>>=20 >>>> - the channel receiver in turn, does the following: >>>>=20 >>>> pc.ondatachannel =3D gotReceiveChannel; >>>>=20 >>>> function gotReceiveChannel(event) { >>>> trace('Receive Channel Callback'); >>>> receiveChannel =3D event.channel; >>>> receiveChannel.onmessage =3D handleMessage; >>>> receiveChannel.onopen =3D handleReceiveChannelStateChange; >>>> receiveChannel.onclose =3D handleReceiveChannelStateChange; >>>> } >>>>=20 >>>> The following is an excerpt of the provided SDP answer: >>>>=20 >>>> m=3Dapplication 1 RTP/SAVPF 101 >>>> c=3DIN IP4 0.0.0.0 >>>> a=3Drtcp:1 IN IP4 0.0.0.0 >>>> a=3Dice-ufrag:d0/jsCoioZ5wIqQ1 >>>> a=3Dice-pwd:pGoZXkLiO6HN5JZYsy3cSAhH >>>> a=3Dfingerprint:sha-256 >>>> = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D >>>> a=3Dsetup:active >>>> a=3Dmid:data >>>> a=3Dsendrecv >>>> b=3DAS:30 >>>> a=3Drtcp-mux >>>> a=3Drtpmap:101 google-data/90000 >>>> a=3Dssrc:1971010094 cname:icWWLWa/VsrZGHr3 >>>> a=3Dssrc:1971010094 msid:sendDataChannel sendDataChannel >>>> a=3Dssrc:1971010094 mslabel:sendDataChannel >>>> a=3Dssrc:1971010094 label:sendDataChannel >>>>=20 >>>>=20 >>>> Hope this helps, >>>>=20 >>>> Simon >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 29/01/2014 5:45 PM, Christer Holmberg wrote: >>>>>> Hi Christian, >>>>>>=20 >>>>>> Maybe I misunderstood what you said, but the idea is that we = would >>>>>> always use draft-ietf-mmusic-sctp-sdp to negotiate and establish = the >>>>>> DTLS/SCTP channel, and use the rtcweb data channel mechanism. >>>>>>=20 >>>>>> The rtcweb data channel mechanism then specifies the SCTP = details, >>>>>> and the rtcweb data channel protocol (still TBD whether it's >>>>>> mandated) is used to open the channel, and indicate that it will = be >>>>>> used for CLUE. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>>> Groves >>>>>> Sent: 29. tammikuuta 2014 1:28 >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] RTCWEB data channel for CLUE? >>>>>>=20 >>>>>> Hello Christer, >>>>>>=20 >>>>>> Are you asking that rtcweb data channel is the ONLY method for >>>>>> establishing a CLUE channel? or that it is one of the methods? >>>>>>=20 >>>>>> If CLUE is being used in the rtcweb context then it would appear = to >>>>>> make sense to use the web data channel. However if rtcweb isn't = being >>>>>> used then why couldn't we use draft-ietf-mmusic-sctp-sdp to set = up >>>>>> the CLUE channels? >>>>>>=20 >>>>>> I don't think there's anything in the CLUE protocol/data model = that >>>>>> would prevent either being used. >>>>>>=20 >>>>>> Regards, Christian >>>>>>=20 >>>>>>=20 >>>>>> On 29/01/2014 12:55 AM, Christer Holmberg wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> As those of you who attended the virtual meeting yesterday know, = I >>>>>>> presented a suggestion for using the rtcweb data channel for >>>>>>> transporting the CLUE protocol messages. >>>>>>>=20 >>>>>>> We recognized that there ARE a few things that need to be sorted = out >>>>>>> and clarified (you may have seen the e-mails I've sent to the = rtcweb- >>>>>>> and mmusic lists), but in general I think we should decide (or, = at >>>>>>> least making a working assumption) whether we'll use the rtcweb >>>>>>> mechanism. >>>>>>>=20 >>>>>>> Again, there are details that need to be sorted out, and we can >>>>>>> always reverse any decision we make. But, I do NOT want to wait = until >>>>>>> London for making a decision in the first place. I want us to = sort >>>>>>> out details and open issues in London. >>>>>>>=20 >>>>>>> Personally I think that having interoperability with rtcweb is >>>>>>> extremely valuable - unless, of course, it causes a great burden = for >>>>>>> CLUE, or unless the mechanism is technically unfeasible for = CLUE. So >>>>>>> far I have not heard any indication of either, and we also saw a = demo >>>>>>> showing that it is possible to use the mechanism. >>>>>>>=20 >>>>>>> I also don't think that, due to the dependency on rtcweb that = such >>>>>>> decision would create, there is a big risk of CLUE being = delayed. In >>>>>>> my opinion, the data channel mechanism is probably the most = stable >>>>>>> thing of the things rtcweb is currently working on. >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Christer >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> clue mailing 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 >>>>>=20 >>>>>=20 >>>>=20 >>>> _\\|//_ >>>> ( O-O ) >>>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Simon Pietro Romano >>>> Universita' di Napoli Federico II >>>> Computer Engineering Department >>>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>>> e-mail: spromano@unina.it >>>> >>>> >>>>=20 >>>> <>>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>>> oooO >>>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> \ ( ( ) >>>> \_) ) / >>>> = (_/ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>>=20 >>>=20 >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>>=20 >>=20 >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >>=20 >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> = (_/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_5D91ACE1-EE48-4217-A816-71FF9148D67B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Paul,

Thanks. I see = this is still a work in progress, and google-specific.
It isn't = following draft-ietf-mmusic-sctp-sdp. (And I don't find any iana = registration for mime type application/google-data.)

I trust this = is just implementation getting ahead of the standards = work.

It actually is. I dumped =  the SDP on the following browser (Chrome = Canary): 

Version 34.0.1811.0 = canary

If you want to have an idea of = how this stuff looks like in Firefox (Nightly build, release 29.0a1), = here is a similar dump:

*Note Well: here the data channel is negotiated like this (see = end of the dump): m=3Dapplication = 58232 DTLS/SCTP 5000

o=3DMozilla-SIPUA-29.0a1 27617 0 IN IP4 = 0.0.0.0
s=3DSIP Call
t=3D0 0
m=3Daudio 56393 RTP/SAVPF 109 0 8 101
a=3Drtpmap:109 = opus/48000/2
a=3Dptime:20
a=3Drtpmap:0 = PCMU/8000
a=3Drtpmap:8 PCMA/8000
a=3Dfmtp:101 = 0-15
a=3Drecvonly
a=3Dsetup:actpass
a=3Dcandidate:2 1 UDP 2130444543 100.71.44.223 = 56393 typ host
a=3Dcandidate:0 2 UDP 2130379006 143.225.28.167 = 57887 typ host
a=3Dcandidate:2 2 UDP 2130444542 100.71.44.223 = 57653 typ host
a=3Drtcp-mux
m=3Dvideo 63084 RTP/SAVPF = 120
c=3DIN IP4 100.71.44.223
a=3Dsendrecv
a=3Drtcp-fb:120 nack pli
a=3Dsetup:actpass
a=3Dcandidate:2 1 UDP 2130444543 100.71.44.223 = 63084 typ host
a=3Dcandidate:0 2 UDP 2130379006 143.225.28.167 = 56287 typ host
a=3Dcandidate:2 2 UDP 2130444542 100.71.44.223 = 53824 typ host
a=3Drtcp-mux
m=3Dapplication 58232 = DTLS/SCTP 5000 
c=3DIN IP4 100.71.44.223
a=3Dsetup:actpass
Hope this = helps,

Simon


= Thanks,
Paul

type: offer, sdp: v=3D0
o=3D- 5103351260166074998 2 IN IP4 = 127.0.0.1
s=3D-
t=3D0 = 0
a=3Dgroup:BUNDLE video = data
a=3Dmsid-semantic: WMS = HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz
m=3Dvideo 1 RTP/SAVPF 100 116 = 117
c=3DIN IP4 = 0.0.0.0
a=3Drtcp:1 IN IP4 = 0.0.0.0
a=3Dice-ufrag:Hokk+0T0UPC3dvNu
a=3Dice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/
a=3Dice-options:google-ice
a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D
a=3Dsetup:actpass
a=3Dmid:video
a=3Dextmap:2 = urn:ietf:params:rtp-hdrext:toffset
a=3Dextmap:3http://www.webrtc.org/experiments/rtp-hdrext/abs= -send-time
a=3Dsendrecv
a=3Drtcp-mux
a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 = inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA
a=3Drtpmap:100 VP8/90000
a=3Drtcp-fb:100 ccm fir
a=3Drtcp-fb:100 nack
a=3Drtcp-fb:100 nack pli
a=3Drtcp-fb:100 goog-remb
a=3Drtpmap:116 red/90000
a=3Drtpmap:117 ulpfec/90000
a=3Dssrc:3100544884 = cname:S+mwxWG9Y7xCa1i2
a=3Dssrc:3100544884 = msid:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz = a35c161e-74ca-4ada-8b79-909e708b583b
a=3Dssrc:3100544884 = mslabel:HsD0L8kiVyn2ZELb4IEyzcgY6RhDBZAGctoz
a=3Dssrc:3100544884 = label:a35c161e-74ca-4ada-8b79-909e708b583b
m=3Dapplication 1 RTP/SAVPF = 101
c=3DIN IP4 = 0.0.0.0
a=3Drtcp:1 IN IP4 = 0.0.0.0
a=3Dice-ufrag:Hokk+0T0UPC3dvNu
a=3Dice-pwd:T2IvRmr2GXiN1vQ3T5T1mp1/
a=3Dice-options:google-ice
a=3Dfingerprint:sha-256 = DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:33:F3:27:06:0A= :D5:3A:7D:6C:A1:00:6D
a=3Dsetup:actpass
a=3Dmid:data
a=3Dsendrecv
b=3DAS:30
a=3Drtcp-mux
a=3Dcrypto:0 AES_CM_128_HMAC_SHA1_80 = inline:okRaCzerNHngBK7koanqye5QR+zP6pzE81yj7uFA
a=3Drtpmap:101 = google-data/90000
a=3Dssrc:1569838440 = cname:gG2TR57LvWPMBVd3
a=3Dssrc:1569838440 msid:sendDataChannel = sendDataChannel
a=3Dssrc:1569838440 = mslabel:sendDataChannel
a=3Dssrc:1569838440 = label:sendDataChannel


Simon


m=3Dapplication 1 RTP/SAVPF = 101

What is the above? Its not sctp, = or anything I understand as = valid.

Thanks,
Paul

c=3DIN = IP4 0.0.0.0
a=3Drtcp= :1 IN IP4 0.0.0.0
a=3Dice-ufrag:7Do/ydOMrH5lwzBn
=
a=3Dice-pwd:b3D+HG9L+SzimBRJcWUqZgti
a=3Dice-options:google-ice
a=3Dfingerprint:sha-256
DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:= 33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D
a=3Dsetup:actpass
=
a=3Dmid:data
a=3Dsendrecv
b=3DAS:30
a=3Drtcp-mux
a=3Dcrypto:0 = AES_CM_128_HMAC_SHA1_80
inline:1CFp/gR+88d3ig0EcgluA0yGumtiKI8gxOH2f/ug
a=3Drtpmap:101 = google-data/90000
a=3Dssrc:1049470780 = cname:l6fp7zYgy3DkXQDN
a=3Dssrc:1049470780 msid:sendDataChannel = sendDataChannel
a=3Dssrc:1049470780 = mslabel:sendDataChannel
a=3Dssrc:1049470780 = label:sendDataChannel



- the = channel receiver in turn, does the = following:

pc.ondatachannel =3D = gotReceiveChannel;

function= gotReceiveChannel(event) = {
trace('Receive Channel = Callback');
receiveChannel =3D = event.channel;
receiveChannel.onmessage =3D = handleMessage;
receiveChannel.onopen =3D = handleReceiveChannelStateChange;
receiveChannel.onclose =3D = handleReceiveChannelStateChange;
}

The = following is an excerpt of the provided SDP = answer:

m=3Dapplication 1 RTP/SAVPF = 101
c=3DIN = IP4 0.0.0.0
a=3Drtcp= :1 IN IP4 0.0.0.0
a=3Dice-ufrag:d0/jsCoioZ5wIqQ1
=
a=3Dice-pwd:pGoZXkLiO6HN5JZYsy3cSAhH
a=3Dfingerprint:sha-256
DB:D9:EC:02:33:F0:68:CC:0B:3B:28:3C:33:5B:C2:CE:75:78:9C:88:= 33:F3:27:06:0A:D5:3A:7D:6C:A1:00:6D
a=3Dsetup:active
<= blockquote type=3D"cite">
a=3Dmid:data
a=3Dsendrecv
b=3DAS:30
a=3Drtcp-mux
a=3Drtpmap:101 = google-data/90000
a=3Dssrc:1971010094 = cname:icWWLWa/VsrZGHr3
a=3Dssrc:1971010094 msid:sendDataChannel = sendDataChannel
a=3Dssrc:1971010094 = mslabel:sendDataChannel
a=3Dssrc:1971010094 = label:sendDataChannel


Hope = this helps,

Simon




Regards,

Christer




On 29/01/2014 5:45 PM, Christer = Holmberg = wrote:
Hi = Christian,

Maybe = I misunderstood what you said, but the idea is that we = would
=
always = use draft-ietf-mmusic-sctp-sdp to negotiate and establish = the
DTLS/SCTP channel, and use the rtcweb data channel = mechanism.

The = rtcweb data channel mechanism then specifies the SCTP = details,
and = the rtcweb data channel protocol (still TBD whether = it's
<= blockquote type=3D"cite">
mandated) is used to open the channel, and indicate that = it will = be
used = for = CLUE.
=

Regards,

Christer

-----Original = Message-----
From: = clue [mailto:clue-bounces@ietf.org] On Behalf Of = Christian
Groves
Sent: 29. tammikuuta 2014 = 1:28
<= blockquote type=3D"cite">
To: clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org>
Subject:= Re: [clue] RTCWEB data channel for = CLUE?
=

Hello = Christer,

Are = you asking that rtcweb data channel is the ONLY method = for
establishing a CLUE channel? or that it is one of the = methods?

If = CLUE is being used in the rtcweb context then it would appear = to
make = sense to use the web data channel. However if rtcweb isn't = being
=
used = then why couldn't we use draft-ietf-mmusic-sctp-sdp to set = up
the = CLUE = channels?

I = don't think there's anything in the CLUE protocol/data model = that
<= blockquote type=3D"cite">
would = prevent either being = used.
=

Regards,= = Christian


On = 29/01/2014 12:55 AM, Christer Holmberg = wrote:
Hi,
<= /blockquote>

As = those of you who attended the virtual meeting yesterday know, = I
presented a suggestion for using = the rtcweb data channel = for
transporting the CLUE protocol = messages.

We = recognized that there ARE a few things that need to be sorted = out
and clarified (you may have seen = the e-mails I've sent to the = rtcweb-
and = mmusic lists), but in general I think we should decide (or, = at
least making a working = assumption) whether we'll use the = rtcweb
mechanism.

Again, = there are details that need to be sorted out, and we = can
always reverse any decision we = make. But, I do NOT want to wait = until
=
London = for making a decision in the first place. I want us to = sort
<= /blockquote>
out = details and open issues in = London.

Personally I think that having interoperability with = rtcweb = is
extremely valuable - unless, of = course, it causes a great burden = for
CLUE, or unless the mechanism is = technically unfeasible for CLUE. = So
far I have not heard any = indication of either, and we also saw a = demo
<= /blockquote>
showing = that it is possible to use the = mechanism.

I also = don't think that, due to the dependency on rtcweb that = such
<= /blockquote>
decision= would create, there is a big risk of CLUE being delayed. = In
my opinion, the data channel = mechanism is probably the most = stable
thing = of the things rtcweb is currently working = on.

Regards,

Christer



_______________________________________________
clue mailing = list
<= /blockquote>
clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org>
https://www.ietf.org/m= ailman/listinfo/clue
_______________________________________________
clue = mailing = list
<= blockquote type=3D"cite">
clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org>
https://www.ietf.org/m= ailman/listinfo/clue




=      _\\|//_
     ( O-O = )
=   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
Simon = Pietro Romano
Universita' di Napoli Federico = II
=     Computer Engineering = Department
=             Ph= one: +39 081 7683823 -- Fax: +39 081 = 7683816
=             &n= bsp;           &nbs= p;            =      e-mail: spromano@unina.it
<mailto:spromano@unina.it>
<mailto:spromano@unina.it>

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








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


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


=       _\\|//_
      ( O-O = )
=    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~= ~~~
Simon Pietro = Romano
Universita' di Napoli = Federico II
=      Computer Engineering = Department
=             &n= bsp;Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
=             &n= bsp;           &nbs= p;            =       e-mail: spromano@unina.it
<mailto:spromano@unina.it>

    <<Molti mi dicono che lo = scoraggiamento =E8 l'alibi degli
    idioti. Ci rifletto un istante; e = mi scoraggio>>. Magritte.
= =             &n= bsp;        oooO
<= blockquote type=3D"cite">   ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ = Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=             &n= bsp;    \ ( =            ( =   )
=             &n= bsp;           &nbs= p;         \_) =          ) = /
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;         (_/









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

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






= --Apple-Mail=_5D91ACE1-EE48-4217-A816-71FF9148D67B-- From keith.drage@alcatel-lucent.com Wed Jan 29 09:53: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 E05451A03A2 for ; Wed, 29 Jan 2014 09:53:08 -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 4B2eLqGopGWZ for ; Wed, 29 Jan 2014 09:53:06 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 96E9F1A0276 for ; Wed, 29 Jan 2014 09:53:06 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s0THqxXc029838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Jan 2014 11:53:01 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s0THqxY2024234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 18:52:59 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 29 Jan 2014 18:52:59 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AA26ryXAAOBZGA= Date: Wed, 29 Jan 2014 17:52:58 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B12537C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E925EB.6070801@alum.mit.edu> In-Reply-To: <52E925EB.6070801@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 29 Jan 2014 17:53:09 -0000 One of the updates planned to draft-ejzak-dispatch-webrtc-data-channel-sdpn= eg before London is to generalise it so it can be used outside of rtcweb. Regards Keith=20 > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 29 January 2014 16:02 > To: clue@ietf.org > Subject: Re: [clue] RTCWEB data channel for CLUE? >=20 > On 1/29/14 1:45 AM, Christer Holmberg wrote: > > Hi Christian, > > > > Maybe I misunderstood what you said, but the idea is that=20 > we would always use draft-ietf-mmusic-sctp-sdp to negotiate=20 > and establish the DTLS/SCTP channel, and use the rtcweb data=20 > channel mechanism. > > > > The rtcweb data channel mechanism then specifies the SCTP=20 > details, and the rtcweb data channel protocol (still TBD=20 > whether it's mandated) is used to open the channel, and=20 > indicate that it will be used for CLUE. >=20 > What I have been thinking is that we would use=20 > draft-ietf-mmusic-sctp-sdp and=20 > draft-ejzak-dispatch-webrtc-data-channel-sdpneg to negotiate=20 > the data channel, thus avoiding the need to rely upon the=20 > rtcweb data channel protocol. >=20 > I guess either mechanism will work. Which is preferable=20 > depends on what you think will happen in the future for use=20 > of other data channel in a sip O/A environment. >=20 > For instance, if we wanted to also negotiate a hypothetical=20 > BFCP over data channel usage, either with or without clue. >=20 > Thanks, > Paul >=20 > > Regards, > > > > Christer > > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian=20 > > Groves > > Sent: 29. tammikuuta 2014 1:28 > > To: clue@ietf.org > > Subject: Re: [clue] RTCWEB data channel for CLUE? > > > > Hello Christer, > > > > Are you asking that rtcweb data channel is the ONLY method=20 > for establishing a CLUE channel? or that it is one of the methods? > > > > If CLUE is being used in the rtcweb context then it would=20 > appear to make sense to use the web data channel. However if=20 > rtcweb isn't being used then why couldn't we use=20 > draft-ietf-mmusic-sctp-sdp to set up the CLUE channels? > > > > I don't think there's anything in the CLUE protocol/data=20 > model that would prevent either being used. > > > > Regards, Christian > > > > > > On 29/01/2014 12:55 AM, Christer Holmberg wrote: > >> > >> Hi, > >> > >> As those of you who attended the virtual meeting yesterday know, I=20 > >> presented a suggestion for using the rtcweb data channel for=20 > >> transporting the CLUE protocol messages. > >> > >> We recognized that there ARE a few things that need to be=20 > sorted out=20 > >> and clarified (you may have seen the e-mails I've sent to=20 > the rtcweb-=20 > >> and mmusic lists), but in general I think we should decide (or, at=20 > >> least making a working assumption) whether we'll use the=20 > rtcweb mechanism. > >> > >> Again, there are details that need to be sorted out, and we can=20 > >> always reverse any decision we make. But, I do NOT want to=20 > wait until=20 > >> London for making a decision in the first place. I want us to sort=20 > >> out details and open issues in London. > >> > >> Personally I think that having interoperability with rtcweb is=20 > >> extremely valuable - unless, of course, it causes a great=20 > burden for=20 > >> CLUE, or unless the mechanism is technically unfeasible=20 > for CLUE. So=20 > >> far I have not heard any indication of either, and we also=20 > saw a demo=20 > >> showing that it is possible to use the mechanism. > >> > >> I also don't think that, due to the dependency on rtcweb that such=20 > >> decision would create, there is a big risk of CLUE being=20 > delayed. In=20 > >> my opinion, the data channel mechanism is probably the most stable=20 > >> thing of the things rtcweb is currently working on. > >> > >> 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 > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > = From pkyzivat@alum.mit.edu Wed Jan 29 11:11: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 4056D1A0240 for ; Wed, 29 Jan 2014 11:11:28 -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 tH-kUNzOZ4Mv for ; Wed, 29 Jan 2014 11:11:26 -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 85ED81A0363 for ; Wed, 29 Jan 2014 11:11:26 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta09.westchester.pa.mail.comcast.net with comcast id KuXV1n00516LCl059vBPb8; Wed, 29 Jan 2014 19:11:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id KvBP1n0053ZTu2S3SvBPmb; Wed, 29 Jan 2014 19:11:23 +0000 Message-ID: <52E9525B.8060502@alum.mit.edu> Date: Wed, 29 Jan 2014 14:11:23 -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: "DRAGE, Keith (Keith)" , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E925EB.6070801@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B12537C@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B12537C@FR712WXCHMBA11.zeu.alcatel-lucent.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=1391022683; bh=p5DhzA4XOvsnVtulr/sRtZPQE9zCJ+XbVctYMr7St9k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ca/8B6n2VTZg+snd2XIraXhPPEje8+TMTUYqvHkyY1E6vtn3yKSYklJdIvXUYFCCg 4fafdwGKDs9x6LHGqnOufSD8Sj2PZhuEcEIH4sCoDvOQWHkDLpllrL/zzw8kiNYoH3 4QFuri/5xlm4Jp6M0UAP67lBbrhJvtLhoHP1DBJFDebgdpaHL4+/sR9Fj7FodhxCGD OcYS0/DRkirjDe5IpW5lz9kHKD8+CXiz+/AeCnbFuz/A1kc++rACIayb9xSUYNemUa L9rt5ieKmVrVEvt4QM5Mxi6fGe1UUh8s+B92/0+8/pgcAneINyUhNLxp9jTgHJ8qhW IZ+SeY6fFVG9Q== Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 29 Jan 2014 19:11:28 -0000 On 1/29/14 12:52 PM, DRAGE, Keith (Keith) wrote: > One of the updates planned to draft-ejzak-dispatch-webrtc-data-channel-sdpneg before London is to generalise it so it can be used outside of rtcweb. Yeah. I asked Richard to do that. Thanks, Paul > Regards > > Keith > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 29 January 2014 16:02 >> To: clue@ietf.org >> Subject: Re: [clue] RTCWEB data channel for CLUE? >> >> On 1/29/14 1:45 AM, Christer Holmberg wrote: >>> Hi Christian, >>> >>> Maybe I misunderstood what you said, but the idea is that >> we would always use draft-ietf-mmusic-sctp-sdp to negotiate >> and establish the DTLS/SCTP channel, and use the rtcweb data >> channel mechanism. >>> >>> The rtcweb data channel mechanism then specifies the SCTP >> details, and the rtcweb data channel protocol (still TBD >> whether it's mandated) is used to open the channel, and >> indicate that it will be used for CLUE. >> >> What I have been thinking is that we would use >> draft-ietf-mmusic-sctp-sdp and >> draft-ejzak-dispatch-webrtc-data-channel-sdpneg to negotiate >> the data channel, thus avoiding the need to rely upon the >> rtcweb data channel protocol. >> >> I guess either mechanism will work. Which is preferable >> depends on what you think will happen in the future for use >> of other data channel in a sip O/A environment. >> >> For instance, if we wanted to also negotiate a hypothetical >> BFCP over data channel usage, either with or without clue. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: 29. tammikuuta 2014 1:28 >>> To: clue@ietf.org >>> Subject: Re: [clue] RTCWEB data channel for CLUE? >>> >>> Hello Christer, >>> >>> Are you asking that rtcweb data channel is the ONLY method >> for establishing a CLUE channel? or that it is one of the methods? >>> >>> If CLUE is being used in the rtcweb context then it would >> appear to make sense to use the web data channel. However if >> rtcweb isn't being used then why couldn't we use >> draft-ietf-mmusic-sctp-sdp to set up the CLUE channels? >>> >>> I don't think there's anything in the CLUE protocol/data >> model that would prevent either being used. >>> >>> Regards, Christian >>> >>> >>> On 29/01/2014 12:55 AM, Christer Holmberg wrote: >>>> >>>> Hi, >>>> >>>> As those of you who attended the virtual meeting yesterday know, I >>>> presented a suggestion for using the rtcweb data channel for >>>> transporting the CLUE protocol messages. >>>> >>>> We recognized that there ARE a few things that need to be >> sorted out >>>> and clarified (you may have seen the e-mails I've sent to >> the rtcweb- >>>> and mmusic lists), but in general I think we should decide (or, at >>>> least making a working assumption) whether we'll use the >> rtcweb mechanism. >>>> >>>> Again, there are details that need to be sorted out, and we can >>>> always reverse any decision we make. But, I do NOT want to >> wait until >>>> London for making a decision in the first place. I want us to sort >>>> out details and open issues in London. >>>> >>>> Personally I think that having interoperability with rtcweb is >>>> extremely valuable - unless, of course, it causes a great >> burden for >>>> CLUE, or unless the mechanism is technically unfeasible >> for CLUE. So >>>> far I have not heard any indication of either, and we also >> saw a demo >>>> showing that it is possible to use the mechanism. >>>> >>>> I also don't think that, due to the dependency on rtcweb that such >>>> decision would create, there is a big risk of CLUE being >> delayed. In >>>> my opinion, the data channel mechanism is probably the most stable >>>> thing of the things rtcweb is currently working on. >>>> >>>> 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 keith.drage@alcatel-lucent.com Wed Jan 29 16:39: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 91CAD1A0425; Wed, 29 Jan 2014 16:39:33 -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 vsfQUOC2sUaF; Wed, 29 Jan 2014 16:39:32 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEDF1A0424; Wed, 29 Jan 2014 16:39:32 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s0U0dRk3024724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Jan 2014 18:39:28 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s0U0dQ0K025060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 01:39:27 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 30 Jan 2014 01:39:27 +0100 From: "DRAGE, Keith (Keith)" To: "avtcore@ietf.org" , "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" Thread-Topic: draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: Ac8dU7miUI8F3eIfTMKku34324AzNA== Date: Thu, 30 Jan 2014 00:39:25 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B125741@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] draft-ietf-avtext-rtp-grouping-taxonomy-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, 30 Jan 2014 00:39:33 -0000 To all potential users of the taxonomy document in other working groups. We could do with a few people reading the above draft and identifying omiss= ions, open issues, or corrections, so the editors can get a new version out= prior to the AVTEXT meeting in London. https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ In particular, those of you who have drafts that might use some of this ter= minology. Please respond to the avtext list. Regards Keith AVTEXT WG cochair.= From christer.holmberg@ericsson.com Wed Jan 29 23:34: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 49CCC1A04F8 for ; Wed, 29 Jan 2014 23:34: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 NvEvxBD0EUhZ for ; Wed, 29 Jan 2014 23:34:43 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id CE3B11A0476 for ; Wed, 29 Jan 2014 23:34:42 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-30-52ea008e4258 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 0D.58.04853.E800AE25; Thu, 30 Jan 2014 08:34:39 +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, 30 Jan 2014 08:34:38 +0100 From: Christer Holmberg To: Mary Barnes Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AASGoAAABEq/QAAAWrOgAAGa6TgAAm/AoAAIlJjgA== Date: Thu, 30 Jan 2014 07:34:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@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.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+JvjW4/w6sgg3ctTBZf3jeyWOw/dZnZ 4vP+/cwW29puMDuweOycdZfdY8mSn0weK87PZPH4seUpUwBLFJdNSmpOZllqkb5dAlfGus/9 zAVPBSu6ny5ka2BcxtfFyMEhIWAiMX+lVxcjJ5ApJnHh3nq2LkYuDiGBE4wSexY8YYdwFjNK 3Jl/mQ2kgU3AQqL7nzZIg4iAjsS3z2/BGpgFZjBKnLrZxAySEBYwlGju2c4MUWQksfvzKig7 TOLYifPsIDaLgKrEof+zWEBm8gr4Skza5wqx6x6TxK1LXSwgNZwCgRIt3+6A1TMCXff91Bom EJtZQFzi1pP5TBBXC0gs2XOeGcIWlXj5+B8rhK0osfNsOzNEvZ7EjalT2CBsbYllC1+DxXkF BCVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZVjJLFqcXFuelGBnq56bkleqlFmcnFxfl5esWp mxiB8XZwy2+jHYwn99gfYpTmYFES573OWhMkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTFu SsKFF0oFs3q2T7zOE6Vopl2x4kJm3x9p3Y27v2xXdQxlCJm4bs2/S0Vd/tOTRdsz42afdhA4 8oF/VqOlZY9MjJ0tT9Jll4eHH7xLsjVq3v3e4/F8nWJNs5/VWcc2LNn5ZI7jHpNpdqoWrlsk Li8QEJVrFpZtUL6g3bJhxZu5XVP2nc6pMlJiKc5INNRiLipOBAA9sTuNhQIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 07:34:44 -0000 Hi, >>> Could we use this for CLUE without using the rtcweb data channel mechan= ism? >> If we want to have interoperability with rtcweb, we need to use the SCTP= properties defined in the rtcweb data channel draft.=20 >> I have not heard, or identified myself, any reason why that would be a p= roblem for CLUE. > > [MB] I think the decision to be made by CLUE needs to more importantly co= nsider whether that approach works for CLUE without RTCWEB. =A0We=20 > discussed on the call that the RTCWEB WG document (i.e., draft-ietf-rtcwe= b-data-channel/) could be viewed as providing a more generic mechanism=20 > that can be used for applications beyond RTCWEB. Yes. The rtcweb data channel is designed so that it works with JavaScript a= pplications. But, as I said on the call, there is nothing JavaScript specif= ic about. Not even all rtcweb applications will be JavaScript based. > That all said, as an individual, I don't see it to be a tremendous amount= of work to write a =A0clue-data-channel document that uses identical=20 > mechanisms but has content specific to CLUE. =A0For example, the generic = aspects in the RTCWEB seem to be primarily limited to=20 > section 5 (just over 3 pages of text). =A0Section 4 has some generic aspe= cts, but also some of it is RTCWEB specific. And, section 3 is totally spec= ific=20 > to RTCWEB. =A0And, we need to decide how much of section 6 applies to CLU= E.So, personally, I think CLUE could just write their own document=20 > (and perhaps mention that procedures in section blah are identical to tho= se for RTCWEB OR write a general document that both CLUE and=20 > RTCWEB can reference (although the doc would have more boiler plate than = content. =A0Or perhaps, section 5 could be folded into the=20 > tsvwg document (although I haven't looked at that in detail to see if it = would work). [/MB]=A0 We could for sure write our own document, eventhough much would be copy/pas= te from the rtcweb document.=20 However, even if we write our own document, assuming we want interoperabili= ty, we would STILL have a dependency on the rtcweb data channel, because th= at's where the SCTP PPID values are defined. I can try to put something together. Regards, Christer From spromano@unina.it Thu Jan 30 00:14: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 6336B1A04FC for ; Thu, 30 Jan 2014 00:14:19 -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 QleToxJgi9wN for ; Thu, 30 Jan 2014 00:14:16 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7001A03DC for ; Thu, 30 Jan 2014 00:14:15 -0800 (PST) Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s0U8E3oP006786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jan 2014 09:14:03 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_A96C455A-BEF9-495D-8906-01B0D17022B0" From: Simon Pietro Romano In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> Date: Thu, 30 Jan 2014 09:14:03 +0100 Message-Id: <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 08:14:19 -0000 --Apple-Mail=_A96C455A-BEF9-495D-8906-01B0D17022B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello folks, I might be perhaps too naif, but I have to admit I don't see the point = of discussion here. In my view, the CLUE protocol is independent from = the underlying transport means. One of the potential transports (the = best current option, IMHO) is the RtcWeb/WebRTC data channel. I think we = should keep on specifying CLUE protocol messages and state machines in = the CLUE protocol document. We might then write a document illustrating = how it is possible to seamlessly implement such a protocol on top of the = RtcWeb data channel. I am actually working on an individual contribution = which basically illustrates the above concepts, by also providing a = couple of call flows. I also believe that Christer's proposal perfectly = fits such an approach. Should the WG decide that this option is worth = exploring, I would be glad to contribute. Cheers, Simon Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha scritto: > Hi, >=20 >>>> Could we use this for CLUE without using the rtcweb data channel = mechanism? >>> If we want to have interoperability with rtcweb, we need to use the = SCTP properties defined in the rtcweb data channel draft.=20 >>> I have not heard, or identified myself, any reason why that would be = a problem for CLUE. >>=20 >> [MB] I think the decision to be made by CLUE needs to more = importantly consider whether that approach works for CLUE without = RTCWEB. We=20 >> discussed on the call that the RTCWEB WG document (i.e., = draft-ietf-rtcweb-data-channel/) could be viewed as providing a more = generic mechanism=20 >> that can be used for applications beyond RTCWEB. >=20 > Yes. The rtcweb data channel is designed so that it works with = JavaScript applications. But, as I said on the call, there is nothing = JavaScript specific about. Not even all rtcweb applications will be = JavaScript based. >=20 >> That all said, as an individual, I don't see it to be a tremendous = amount of work to write a clue-data-channel document that uses = identical=20 >> mechanisms but has content specific to CLUE. For example, the = generic aspects in the RTCWEB seem to be primarily limited to=20 >> section 5 (just over 3 pages of text). Section 4 has some generic = aspects, but also some of it is RTCWEB specific. And, section 3 is = totally specific=20 >> to RTCWEB. And, we need to decide how much of section 6 applies to = CLUE.So, personally, I think CLUE could just write their own document=20 >> (and perhaps mention that procedures in section blah are identical to = those for RTCWEB OR write a general document that both CLUE and=20 >> RTCWEB can reference (although the doc would have more boiler plate = than content. Or perhaps, section 5 could be folded into the=20 >> tsvwg document (although I haven't looked at that in detail to see if = it would work). [/MB]=20 >=20 > We could for sure write our own document, eventhough much would be = copy/paste from the rtcweb document.=20 >=20 > However, even if we write our own document, assuming we want = interoperability, we would STILL have a dependency on the rtcweb data = channel, because that's where the SCTP PPID values are defined. >=20 > I can try to put something together. >=20 > Regards, >=20 > Christer >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_A96C455A-BEF9-495D-8906-01B0D17022B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hello = folks,

I might be perhaps too naif, but I have to = admit I don't see the point of discussion here. In my view, the CLUE = protocol is independent from the underlying transport means. One of the = potential transports (the best current option, IMHO) is the = RtcWeb/WebRTC data channel. I think we should keep on specifying CLUE = protocol messages and state machines in the CLUE protocol document. We = might then write a document illustrating how it is possible to = seamlessly implement such a protocol on top of the RtcWeb data channel. = I am actually working on an individual contribution which basically = illustrates the above concepts, by also providing a couple of call = flows. I also believe that Christer's proposal perfectly fits such an = approach. Should the WG decide that this option is worth exploring, I = would be glad to = contribute.

Cheers,

Simo= n


Il giorno 30/gen/2014, alle ore = 08:34, Christer Holmberg ha scritto:

Hi,

Could we use this for CLUE = without using the rtcweb data channel = mechanism?
If we want to have = interoperability with rtcweb, we need to use the SCTP properties defined = in the rtcweb data channel draft. =
I have not heard, or identified myself, any reason why = that would be a problem for = CLUE.

[MB] I think = the decision to be made by CLUE needs to more importantly consider = whether that approach works for CLUE without RTCWEB.  We =
discussed on the call that = the RTCWEB WG document (i.e., draft-ietf-rtcweb-data-channel/) could be = viewed as providing a more generic mechanism =
that can be used for = applications beyond RTCWEB.

Yes. The rtcweb data = channel is designed so that it works with JavaScript applications. But, = as I said on the call, there is nothing JavaScript specific about. Not = even all rtcweb applications will be JavaScript = based.

That all said, as an individual, = I don't see it to be a tremendous amount of work to write a =  clue-data-channel document that uses identical =
mechanisms but has content = specific to CLUE.  For example, the generic aspects in the RTCWEB = seem to be primarily limited to
section 5 (just over 3 pages of text).  Section 4 has = some generic aspects, but also some of it is RTCWEB specific. And, = section 3 is totally specific
to RTCWEB.  And, we need to decide how much of = section 6 applies to CLUE.So, personally, I think CLUE could just write = their own document
(and = perhaps mention that procedures in section blah are identical to those = for RTCWEB OR write a general document that both CLUE and =
RTCWEB can reference = (although the doc would have more boiler plate than content.  Or = perhaps, section 5 could be folded into the
tsvwg document (although I haven't looked at that in = detail to see if it would work). [/MB] 

We = could for sure write our own document, eventhough much would be = copy/paste from the rtcweb document.

However, even if we write = our own document, assuming we want interoperability, we would STILL have = a dependency on the rtcweb data channel, because that's where the SCTP = PPID values are defined.

I can try to put something = together.

Regards,

Christer

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

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






= --Apple-Mail=_A96C455A-BEF9-495D-8906-01B0D17022B0-- From christer.holmberg@ericsson.com Thu Jan 30 00:30: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 55AF71A03C0 for ; Thu, 30 Jan 2014 00:30: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, 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 gDNnNugrlfWY for ; Thu, 30 Jan 2014 00:30:47 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 823CE1A02BF for ; Thu, 30 Jan 2014 00:30:46 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-fe-52ea0db26934 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 18.70.04249.2BD0AE25; Thu, 30 Jan 2014 09:30:42 +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; Thu, 30 Jan 2014 09:30:41 +0100 From: Christer Holmberg To: Simon Pietro Romano Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AASGoAAABEq/QAAAWrOgAAGa6TgAAm/AoAAIlJjgP///J6A///sArA= Date: Thu, 30 Jan 2014 08:30:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> In-Reply-To: <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> 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_7594FB04B1934943A5C02806D1A2204B1D14B9D5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM+Jvje4m3ldBBu1P9Cy+vG9ksdh/6jKz xef9+5kttrXdYHZg8dg56y67x5IlP5k8VpyfyeLxY8tTpgCWKC6blNSczLLUIn27BK6Mx7N+ shZsOsZYcbVxIlsD46JVjF2MnBwSAiYSi1dugLLFJC7cW8/WxcjFISRwhFHi4dpOJghnMaPE sxs9QA4HB5uAhUT3P22QBhEBbYnfT9+xgNQwCzQySixtvsAOkhAWMJRo7tnODFFkJLH78yoo O0mid/1aFhCbRUBVYvra+2BxXgFfid9XvjFCLLvCLHG14Q8TSIJTwEaie/8RNhCbEei876fW gMWZBcQlbj2ZzwRxtoDEkj3nmSFsUYmXj/+xQtiKEjvPtjND1OdL7LkM8TKvgKDEyZlPWCYw is5CMmoWkrJZSMog4noSN6ZOYYOwtSWWLXzNDGHrSsz4d4gFWXwBI/sqRo7i1OKk3HQjg02M wCg8uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFx2vyP 1/6fC6qUWV968Pq7qNlvOrjO3O9sZvNPW9HBsH4W9+TN36/I6P9cmHpR/M7jg+HrTRZpFivb b+WcbW57XC3sA2euublA9iMzddWYQC2lZimO3Vtvu0Y2rt92JbfBwPvns4seZdIzTuxnLnh4 +5xGaXDWrKXV6vIWvc+rZCZ6t+aFqhgrsRRnJBpqMRcVJwIAuMJ7DJACAAA= Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 08:30:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D14B9D5ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I agree that we shall try to keep the CLUE protocol and the CLUE protocol t= ransport independent, and I never suggested that we should stop the work on= the CLUE protocol while deciding on the transport :) However, when we define the CLUE protocol state machine, we DO need to make= some assumptions about the transport, e.g. whether it provides reliable tr= ansport, in-order transport etc. If not, such mechanisms need to be impleme= nted in the CLUE protocol itself (similar to what is done in SIP with messa= ge re-transmission, usage of CSeq etc). But, I strongly think that we shall decide on *A* transport mechanism for t= he CLUE protocol. Otherwise we won't even guarantee interoperability betwee= n CLUE entities. Regards, Christer From: Simon Pietro Romano [mailto:spromano@unina.it] Sent: 30. tammikuuta 2014 10:14 To: Christer Holmberg Cc: Mary Barnes; Christian Groves; clue@ietf.org Subject: Re: [clue] RTCWEB data channel for CLUE? Hello folks, I might be perhaps too naif, but I have to admit I don't see the point of d= iscussion here. In my view, the CLUE protocol is independent from the under= lying transport means. One of the potential transports (the best current op= tion, IMHO) is the RtcWeb/WebRTC data channel. I think we should keep on sp= ecifying CLUE protocol messages and state machines in the CLUE protocol doc= ument. We might then write a document illustrating how it is possible to se= amlessly implement such a protocol on top of the RtcWeb data channel. I am = actually working on an individual contribution which basically illustrates = the above concepts, by also providing a couple of call flows. I also believ= e that Christer's proposal perfectly fits such an approach. Should the WG d= ecide that this option is worth exploring, I would be glad to contribute. Cheers, Simon Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha scritto: Hi, Could we use this for CLUE without using the rtcweb data channel mechanism? If we want to have interoperability with rtcweb, we need to use the SCTP pr= operties defined in the rtcweb data channel draft. I have not heard, or identified myself, any reason why that would be a prob= lem for CLUE. [MB] I think the decision to be made by CLUE needs to more importantly cons= ider whether that approach works for CLUE without RTCWEB. We discussed on the call that the RTCWEB WG document (i.e., draft-ietf-rtcweb-= data-channel/) could be viewed as providing a more generic mechanism that can be used for applications beyond RTCWEB. Yes. The rtcweb data channel is designed so that it works with JavaScript a= pplications. But, as I said on the call, there is nothing JavaScript specif= ic about. Not even all rtcweb applications will be JavaScript based. That all said, as an individual, I don't see it to be a tremendous amount o= f work to write a clue-data-channel document that uses identical mechanisms but has content specific to CLUE. For example, the generic aspe= cts in the RTCWEB seem to be primarily limited to section 5 (just over 3 pages of text). Section 4 has some generic aspects,= but also some of it is RTCWEB specific. And, section 3 is totally specific to RTCWEB. And, we need to decide how much of section 6 applies to CLUE.So= , personally, I think CLUE could just write their own document (and perhaps mention that procedures in section blah are identical to those= for RTCWEB OR write a general document that both CLUE and RTCWEB can reference (although the doc would have more boiler plate than co= ntent. Or perhaps, section 5 could be folded into the tsvwg document (although I haven't looked at that in detail to see if it wo= uld work). [/MB] We could for sure write our own document, eventhough much would be copy/pas= te from the rtcweb document. However, even if we write our own document, assuming we want interoperabili= ty, we would STILL have a dependency on the rtcweb data channel, because th= at's where the SCTP PPID values are defined. I can try to put something together. Regards, Christer _= \\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Roma= no Universita' di Napoli Fede= rico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. Ma= gritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) = ) / (_/ --_000_7594FB04B1934943A5C02806D1A2204B1D14B9D5ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I agree that we shall try= to keep the CLUE protocol and the CLUE protocol transport independent, and= I never suggested that we should stop the work on the CLUE protocol while deciding on the transport :)

 <= /p>

However, when we define t= he CLUE protocol state machine, we DO need to make some assumptions about t= he transport, e.g. whether it provides reliable transport, in-order transport etc. If not, such mechanisms need to be implemented in = the CLUE protocol itself (similar to what is done in SIP with message re-tr= ansmission, usage of CSeq etc).

 <= /p>

But, I strongly think tha= t we shall decide on *A* transport mechanism for the CLUE protocol. = Otherwise we won’t even guarantee interoperability between CLUE entities.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Simon Pi= etro Romano [mailto:spromano@unina.it]
Sent: 30. tammikuuta 2014 10:14
To: Christer Holmberg
Cc: Mary Barnes; Christian Groves; clue@ietf.org
Subject: Re: [clue] RTCWEB data channel for CLUE?<= /p>

 

Hello folks,

 

I might be perhaps too naif, but I have to admit I d= on't see the point of discussion here. In my view, the CLUE protocol is ind= ependent from the underlying transport means. One of the potential transpor= ts (the best current option, IMHO) is the RtcWeb/WebRTC data channel. I think we should keep on specifying CL= UE protocol messages and state machines in the CLUE protocol document. We m= ight then write a document illustrating how it is possible to seamlessly im= plement such a protocol on top of the RtcWeb data channel. I am actually working on an individual contributi= on which basically illustrates the above concepts, by also providing a coup= le of call flows. I also believe that Christer's proposal perfectly fits su= ch an approach. Should the WG decide that this option is worth exploring, I would be glad to contribute.

 

Cheers,

 

Simon

 

 

Il giorno 30/gen/2014, alle ore 08:34, Christer Holm= berg ha scritto:



Hi,


Could we use this for CLUE without using the rtcweb = data channel mechanism?

If we want to have interoperability with rtcweb, we = need to use the SCTP properties defined in the rtcweb data channel draft.

I have not heard, or identified myself, any reason w= hy that would be a problem for CLUE.

 

[MB] I think the decision to be made by CLUE needs t= o more importantly consider whether that approach works for CLUE without RT= CWEB.  We

discussed on the call that the RTCWEB WG document (i= .e., draft-ietf-rtcweb-data-channel/) could be viewed as providing a more g= eneric mechanism

that can be used for applications beyond RTCWEB.


Yes. The rtcweb data channel is designed so that it works with JavaScript a= pplications. But, as I said on the call, there is nothing JavaScript specif= ic about. Not even all rtcweb applications will be JavaScript based.


That all said, as an individual, I don't see it to b= e a tremendous amount of work to write a  clue-data-channel document t= hat uses identical

mechanisms but has content specific to CLUE.  F= or example, the generic aspects in the RTCWEB seem to be primarily limited = to

section 5 (just over 3 pages of text).  Section= 4 has some generic aspects, but also some of it is RTCWEB specific. And, s= ection 3 is totally specific

to RTCWEB.  And, we need to decide how much of = section 6 applies to CLUE.So, personally, I think CLUE could just write the= ir own document

(and perhaps mention that procedures in section blah= are identical to those for RTCWEB OR write a general document that both CL= UE and

RTCWEB can reference (although the doc would have mo= re boiler plate than content.  Or perhaps, section 5 could be folded i= nto the

tsvwg document (although I haven't looked at that in= detail to see if it would work). [/MB] 


We could for sure write our own document, eventhough much would be copy/pas= te from the rtcweb document.

However, even if we write our own document, assuming we want interoperabili= ty, we would STILL have a dependency on the rtcweb data channel, because th= at's where the SCTP PPID values are defined.

I can try to put something together.

Regards,

Christer

 

      &nbs= p;                         &n= bsp;            = ;            &n= bsp;              &nb= sp; _\\|//_

      &nbs= p;                            = ;            &n= bsp;                ( O-O )

   ~~~~~~~~~~~~= ~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

      &nbs= p;                 =             &nb= sp;            =          Simon Pietro Romano

      &nbs= p;         &nb= sp;            =             &nb= sp;       Universita' di Na= poli Federico II

      &nbs= p;          &n= bsp;                Computer Engineering Department =

                   =     Phone: +39 081 7683823 -- Fax: +39 081 7683816

      &nbs= p;                     &n= bsp;              e-mail: spromano@unina.it

 <= /p>

           &nb= sp;           <<Molti mi dic= ono che lo scoraggiamento =E8 l'alibi degli 

           &nb= sp;           idioti. Ci rifl= etto un istante; e mi scoraggio>>. Magritte.

      &nbs= p;              &nb= sp;            =                        = ;  oooO

  ~~~~~~~~~~~~~~~~~~= ~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

           &nb= sp;            =             &nb= sp;                    =        \ (            ( =   )

           &nb= sp;            =               =                     &nbs= p;   \_)          ) /

      &nbs= p;                     &n= bsp;                     =                      = ;(_/

 <= /p>

 <= /p>

 <= /p>



 

--_000_7594FB04B1934943A5C02806D1A2204B1D14B9D5ESESSMB209erics_-- From spromano@unina.it Thu Jan 30 00:36: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 64A131A03C0 for ; Thu, 30 Jan 2014 00:36:21 -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 wA5en1clyPks for ; Thu, 30 Jan 2014 00:36:18 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 463011A02BF for ; Thu, 30 Jan 2014 00:36:18 -0800 (PST) Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s0U8aCtH009200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jan 2014 09:36:12 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2EBBA42C-7DBF-4955-9AC9-F6E229866CD4" From: Simon Pietro Romano In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> Date: Thu, 30 Jan 2014 09:36:12 +0100 Message-Id: <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 08:36:21 -0000 --Apple-Mail=_2EBBA42C-7DBF-4955-9AC9-F6E229866CD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Christer, > However, when we define the CLUE protocol state machine, we DO need to = make some assumptions about the transport, e.g. whether it provides = reliable transport, in-order transport etc. If not, such mechanisms need = to be implemented in the CLUE protocol itself (similar to what is done = in SIP with message re-transmission, usage of CSeq etc). The CLUE protocol draft currently states the following: CLUE Participants are connected by means of the CLUE signaling channel. Such channel has been conceived as a DTLS/SCTP/UDP channel in [I-D.kyzivat-clue-signaling] and it is established as depicted in the same document. CLUE protocol messages flow across such channel. We assume the DTLS/SCTP/UDP channel is established and define the behiavior of the CLUE Participants communicating on it. We discuss how the CLUE dialogue between them can be exploited to successfully setup the telepresence session according to the principles and concepts pointed out in in [I-D.ietf-clue-framework]. Isn't this already enough? If not, what other assumptions do you think = we should make? Thanks, Simon > =20 > But, I strongly think that we shall decide on *A* transport mechanism = for the CLUE protocol. Otherwise we won=92t even guarantee = interoperability between CLUE entities. > =20 > Regards, > =20 > Christer > =20 > From: Simon Pietro Romano [mailto:spromano@unina.it]=20 > Sent: 30. tammikuuta 2014 10:14 > To: Christer Holmberg > Cc: Mary Barnes; Christian Groves; clue@ietf.org > Subject: Re: [clue] RTCWEB data channel for CLUE? > =20 > Hello folks, > =20 > I might be perhaps too naif, but I have to admit I don't see the point = of discussion here. In my view, the CLUE protocol is independent from = the underlying transport means. One of the potential transports (the = best current option, IMHO) is the RtcWeb/WebRTC data channel. I think we = should keep on specifying CLUE protocol messages and state machines in = the CLUE protocol document. We might then write a document illustrating = how it is possible to seamlessly implement such a protocol on top of the = RtcWeb data channel. I am actually working on an individual contribution = which basically illustrates the above concepts, by also providing a = couple of call flows. I also believe that Christer's proposal perfectly = fits such an approach. Should the WG decide that this option is worth = exploring, I would be glad to contribute. > =20 > Cheers, > =20 > Simon > =20 > =20 > Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha scritto: >=20 >=20 > Hi, >=20 >=20 > Could we use this for CLUE without using the rtcweb data channel = mechanism? > If we want to have interoperability with rtcweb, we need to use the = SCTP properties defined in the rtcweb data channel draft. > I have not heard, or identified myself, any reason why that would be a = problem for CLUE. > =20 > [MB] I think the decision to be made by CLUE needs to more importantly = consider whether that approach works for CLUE without RTCWEB. We > discussed on the call that the RTCWEB WG document (i.e., = draft-ietf-rtcweb-data-channel/) could be viewed as providing a more = generic mechanism > that can be used for applications beyond RTCWEB. >=20 > Yes. The rtcweb data channel is designed so that it works with = JavaScript applications. But, as I said on the call, there is nothing = JavaScript specific about. Not even all rtcweb applications will be = JavaScript based. >=20 >=20 > That all said, as an individual, I don't see it to be a tremendous = amount of work to write a clue-data-channel document that uses = identical > mechanisms but has content specific to CLUE. For example, the generic = aspects in the RTCWEB seem to be primarily limited to > section 5 (just over 3 pages of text). Section 4 has some generic = aspects, but also some of it is RTCWEB specific. And, section 3 is = totally specific > to RTCWEB. And, we need to decide how much of section 6 applies to = CLUE.So, personally, I think CLUE could just write their own document > (and perhaps mention that procedures in section blah are identical to = those for RTCWEB OR write a general document that both CLUE and > RTCWEB can reference (although the doc would have more boiler plate = than content. Or perhaps, section 5 could be folded into the > tsvwg document (although I haven't looked at that in detail to see if = it would work). [/MB]=20 >=20 > We could for sure write our own document, eventhough much would be = copy/paste from the rtcweb document.=20 >=20 > However, even if we write our own document, assuming we want = interoperability, we would STILL have a dependency on the rtcweb data = channel, because that's where the SCTP PPID values are defined. >=20 > I can try to put something together. >=20 > Regards, >=20 > Christer >=20 > =20 > = _\\|//_ > ( O-O = ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro = Romano > Universita' di Napoli = Federico II > Computer Engineering Department=20 > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > =20 > < idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( = ( ) > \_) = ) / > = (_/ > =20 > =20 > =20 >=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_2EBBA42C-7DBF-4955-9AC9-F6E229866CD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Christer,

CLUE Participants are connected by = means of the CLUE signaling channel. Such channel has been conceived as a DTLS/SCTP/UDP channel in [I-D.kyzivat-clue-signaling] and it is established = as depicted in the same document. CLUE protocol messages flow across such = channel.

We assume the
   DTLS/SCTP/UDP channel is established and define the behiavior of the
   CLUE Participants communicating on it.  We discuss how the CLUE
   dialogue between them can be exploited to successfully setup the
   telepresence session according to the principles and concepts pointed
   out in in [I-D.ietf-clue-framework].

Isn't this already enough? If not, what other assumptions do you think = we should = make?

Thanks,

Simon


But, = I strongly think that we shall decide on *A* transport mechanism = for the CLUE protocol. Otherwise we won=92t even guarantee = interoperability between CLUE entities.
From: Simon Pietro Romano = [mailto:spromano@unina.it] 
Sent: 30. tammikuuta 2014 = 10:14
To: Christer = Holmberg
Cc: Mary Barnes; Christian = Groves; clue@ietf.org
Subject: Re: [clue] RTCWEB data = channel for CLUE?
 
Hello = folks,
I might be perhaps too = naif, but I have to admit I don't see the point of discussion here. In = my view, the CLUE protocol is independent from the underlying transport = means. One of the potential transports (the best current option, IMHO) = is the RtcWeb/WebRTC data channel. I think we should keep on specifying = CLUE protocol messages and state machines in the CLUE protocol document. = We might then write a document illustrating how it is possible to = seamlessly implement such a protocol on top of the RtcWeb data channel. = I am actually working on an individual contribution which basically = illustrates the above concepts, by also providing a couple of call = flows. I also believe that Christer's proposal perfectly fits such an = approach. Should the WG decide that this option is worth exploring, I = would be glad to contribute.
 
Cheers,
 
Simon
 
 
Il giorno 30/gen/2014, alle ore 08:34, Christer = Holmberg ha scritto:
Could we use this for CLUE without using the = rtcweb data channel = mechanism?
If we want to = have interoperability with rtcweb, we need to use the SCTP properties = defined in the rtcweb data channel = draft.
I have not = heard, or identified myself, any reason why that would be a problem for = CLUE.
[MB] I think the decision to be = made by CLUE needs to more importantly consider whether that approach = works for CLUE without RTCWEB. =  We
discussed on the call that the = RTCWEB WG document (i.e., draft-ietf-rtcweb-data-channel/) could be = viewed as providing a more generic = mechanism
that can be used for = applications beyond RTCWEB.

Yes. The rtcweb data channel is designed so that it = works with JavaScript applications. But, as I said on the call, there is = nothing JavaScript specific about. Not even all rtcweb applications will = be JavaScript based.


That all said, = as an individual, I don't see it to be a tremendous amount of work to = write a  clue-data-channel document that uses = identical
mechanisms but has content specific to CLUE. =  For example, the generic aspects in the RTCWEB seem to be = primarily limited to
section 5 = (just over 3 pages of text).  Section 4 has some generic aspects, = but also some of it is RTCWEB specific. And, section 3 is totally = specific
to RTCWEB.  And, we need = to decide how much of section 6 applies to CLUE.So, personally, I think = CLUE could just write their own = document
(and perhaps mention that = procedures in section blah are identical to those for RTCWEB OR write a = general document that both CLUE = and
RTCWEB can reference (although the doc would = have more boiler plate than content.  Or perhaps, section 5 could = be folded into the
tsvwg document = (although I haven't looked at that in detail to see if it would work). = [/MB] 


We could for sure write our own document, eventhough much = would be copy/paste from the rtcweb document. 

However, even if we = write our own document, assuming we want interoperability, we would = STILL have a dependency on the rtcweb data channel, because that's where = the SCTP PPID values are defined.

I can try to put something = together.

Regards,

Christer

        =                      &= nbsp;           &nb= sp;            = ;            <= span class=3D"Apple-converted-space">        = _\\|//_
  =                     =              &= nbsp;           &nb= sp;              =   ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
  =                           &= nbsp;           &nb= sp;            = ;     Simon Pietro = Romano
  =                    &= nbsp;           &nb= sp;            = ;   Universita' di Napoli = Federico II
              =           &= nbsp;        =  Computer Engineering = Department 
              Phone: +39 081 = 7683823 -- Fax: +39 081 7683816
        =                     =                e-mail: spromano@unina.it
     <<Molti mi dicono che lo scoraggiamento =E8 = l'alibi degli 
     idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.
         =               &= nbsp;           &nb= sp;    =                   =  oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=
                  \ = (            (   = )
                   =                 \_)   =        ) /
        =                     =                     =                     =    (_/
 
 



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

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






= --Apple-Mail=_2EBBA42C-7DBF-4955-9AC9-F6E229866CD4-- From christer.holmberg@ericsson.com Thu Jan 30 00:42: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 6C4C41A044E for ; Thu, 30 Jan 2014 00:42:16 -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 kQZFLLH1NOCZ for ; Thu, 30 Jan 2014 00:42:11 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 687D21A03C0 for ; Thu, 30 Jan 2014 00:42:10 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-63-52ea105e943f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 04.E1.04249.E501AE25; Thu, 30 Jan 2014 09:42:06 +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; Thu, 30 Jan 2014 09:42:06 +0100 From: Christer Holmberg To: Simon Pietro Romano Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AASGoAAABEq/QAAAWrOgAAGa6TgAAm/AoAAIlJjgP///J6A///sArCAABouAP//7jGw Date: Thu, 30 Jan 2014 08:42:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> In-Reply-To: <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> 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_7594FB04B1934943A5C02806D1A2204B1D14BA55ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+JvjW6cwKsggy03dSy+vG9ksdh/6jKz xef9+5kttrXdYHZg8dg56y67x5IlP5k8VpyfyeLxY8tTpgCWKC6blNSczLLUIn27BK6Mb4eW sxbsvMtUcWflQrYGxm9rmboYOTkkBEwkXt57yw5hi0lcuLeerYuRi0NI4AijxLr/CxghnMWM EnMvP2LpYuTgYBOwkOj+pw3SICKgLfH76TsWkBpmgUZGiaXNF8AmCQsYSjT3bGeGKDKS2P15 FTNIr4hAnsSRKfwgYRYBVYk/736xgti8Ar4SUw5/hlp8ikVi6uOpYHM4BWwkDizYwAZiMwJd 9/3UGrCrmQXEJW49mQ/1gYDEkj3nmSFsUYmXj/+xQtiKEjvPtjND1OdLLJ54lQVimaDEyZlP WCYwis5CMmoWkrJZSMog4noSN6ZOYYOwtSWWLXzNDGHrSsz4d4gFWXwBI/sqRo7i1OKk3HQj g02MwBg8uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFx +aw//5qMdBbfWyL9KaYy7vIp5j9e73Iqu875l+/exK4XXXtRsOmn7eq11V4RIX/17Z/+v3zu T9QvidX6MvN0Al+vNbB/sLqnYH/Npr2BXr/bDky0/H5HLHACE6/0vqfKdXnsLhNN2lw4FolY FifMeRqxYlZWzLbjRzkXvJZnT7jxoPbNcXVpJZbijERDLeai4kQAniPM3o8CAAA= Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 08:42:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D14BA55ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We need to make assumptions on whether the transport provides reliability a= nd in-order. When using "DTLS/SCTP/UDP", those features are optional, as fa= r as I know. Anyway, I am not saying that we haven't made such assumptions already - it = was more a general comment when talking about the separation between protoc= ol and transport. Regards, Christer From: Simon Pietro Romano [mailto:spromano@unina.it] Sent: 30. tammikuuta 2014 10:36 To: Christer Holmberg Cc: Mary Barnes; Christian Groves; clue@ietf.org Subject: Re: [clue] RTCWEB data channel for CLUE? Hi Christer, However, when we define the CLUE protocol state machine, we DO need to make= some assumptions about the transport, e.g. whether it provides reliable tr= ansport, in-order transport etc. If not, such mechanisms need to be impleme= nted in the CLUE protocol itself (similar to what is done in SIP with messa= ge re-transmission, usage of CSeq etc). The CLUE protocol draft currently states the following: CLUE Participants are connected by means of the CLUE signaling channel. Such channel has been conceived as a DTLS/SCTP/UDP channel in [I-D.kyzivat-clue-signaling] and it is established as d= epicted in the same document. CLUE protocol messages flow across such channel. We assume the DTLS/SCTP/UDP channel is established and define the behiavior of the CLUE Participants communicating on it. We discuss how the CLUE dialogue between them can be exploited to successfully setup the telepresence session according to the principles and concepts pointed out in in [I-D.ietf-clue-framework]. Isn't this already enough? If not, what other assumptions do you think we s= hould make? Thanks, Simon But, I strongly think that we shall decide on *A* transport mechanism for t= he CLUE protocol. Otherwise we won't even guarantee interoperability betwee= n CLUE entities. Regards, Christer From: Simon Pietro Romano [mailto:spromano@unina.it] Sent: 30. tammikuuta 2014 10:14 To: Christer Holmberg Cc: Mary Barnes; Christian Groves; clue@ietf.org Subject: Re: [clue] RTCWEB data channel for CLUE? Hello folks, I might be perhaps too naif, but I have to admit I don't see the point of d= iscussion here. In my view, the CLUE protocol is independent from the under= lying transport means. One of the potential transports (the best current op= tion, IMHO) is the RtcWeb/WebRTC data channel. I think we should keep on sp= ecifying CLUE protocol messages and state machines in the CLUE protocol doc= ument. We might then write a document illustrating how it is possible to se= amlessly implement such a protocol on top of the RtcWeb data channel. I am = actually working on an individual contribution which basically illustrates = the above concepts, by also providing a couple of call flows. I also believ= e that Christer's proposal perfectly fits such an approach. Should the WG d= ecide that this option is worth exploring, I would be glad to contribute. Cheers, Simon Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha scritto: Hi, Could we use this for CLUE without using the rtcweb data channel mechanism? If we want to have interoperability with rtcweb, we need to use the SCTP pr= operties defined in the rtcweb data channel draft. I have not heard, or identified myself, any reason why that would be a prob= lem for CLUE. [MB] I think the decision to be made by CLUE needs to more importantly cons= ider whether that approach works for CLUE without RTCWEB. We discussed on the call that the RTCWEB WG document (i.e., draft-ietf-rtcweb-= data-channel/) could be viewed as providing a more generic mechanism that can be used for applications beyond RTCWEB. Yes. The rtcweb data channel is designed so that it works with JavaScript a= pplications. But, as I said on the call, there is nothing JavaScript specif= ic about. Not even all rtcweb applications will be JavaScript based. That all said, as an individual, I don't see it to be a tremendous amount o= f work to write a clue-data-channel document that uses identical mechanisms but has content specific to CLUE. For example, the generic aspe= cts in the RTCWEB seem to be primarily limited to section 5 (just over 3 pages of text). Section 4 has some generic aspects,= but also some of it is RTCWEB specific. And, section 3 is totally specific to RTCWEB. And, we need to decide how much of section 6 applies to CLUE.So= , personally, I think CLUE could just write their own document (and perhaps mention that procedures in section blah are identical to those= for RTCWEB OR write a general document that both CLUE and RTCWEB can reference (although the doc would have more boiler plate than co= ntent. Or perhaps, section 5 could be folded into the tsvwg document (although I haven't looked at that in detail to see if it wo= uld work). [/MB] We could for sure write our own document, eventhough much would be copy/pas= te from the rtcweb document. However, even if we write our own document, assuming we want interoperabili= ty, we would STILL have a dependency on the rtcweb data channel, because th= at's where the SCTP PPID values are defined. I can try to put something together. Regards, Christer _= \\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Roma= no Universita' di Napoli Fede= rico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. Ma= gritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) = ) / (_/ _= \\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Roma= no Universita' di Napoli Fede= rico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. Ma= gritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) = ) / (_/ --_000_7594FB04B1934943A5C02806D1A2204B1D14BA55ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

We need to make assumptio= ns on whether the transport provides reliability and in-order. When using &= #8220;DTLS/SCTP/UDP”, those features are optional, as far as I know.

 <= /p>

Anyway, I am not saying t= hat we haven’t made such assumptions already – it was more a ge= neral comment when talking about the separation between protocol and transport.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Simon Pi= etro Romano [mailto:spromano@unina.it]
Sent: 30. tammikuuta 2014 10:36
To: Christer Holmberg
Cc: Mary Barnes; Christian Groves; clue@ietf.org
Subject: Re: [clue] RTCWEB data channel for CLUE?<= /p>

 

Hi Christer,

 

However, when we define t= he CLUE protocol state machine, we DO need to make some assumptions about t= he transport, e.g. whether it provides reliable transport, in-order transport etc. If not, such mechanisms need to be implemented in = the CLUE protocol itself (similar to what is done in SIP with message re-tr= ansmission, usage of CSeq etc).

 

The CLUE protocol draft currently states the followi= ng:

 

CLUE Participants are connected by means of the =
CLUE signaling
   channel.  Such channel has been conceived as a =
DTLS/SCTP/UDP channel
   in [I-D.kyzivat-clue-signaling] and it is established as depi=
cted in
   the same document.  CLUE protocol messages flow=
 across such channel.

 

We assume the
   DTLS/SCTP/UDP channel is established and define the =
behiavior of the
   CLUE Participants communicating on it.  We disc=
uss how the CLUE
   dialogue between them can be exploited to successful=
ly setup the
   telepresence session according to the principles and=
 concepts pointed
   out in in [I-D.ietf-clue-framework].<=
o:p>

 

Isn't this already enough? If not, what other assump= tions do you think we should make?

 

Thanks,

 

Simon

 

 

 <= /p>

But, I strongly think tha= t we shall decide on *A* transport mechanism for the CLUE protocol. = Otherwise we won’t even guarantee interoperability between CLUE entities.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Simon Pietro Romano [mailto:spromano@unina.= it] 
Sent: 30. tammikuu= ta 2014 10:14
To: Christer Holmb= erg
Cc: Mary Barnes; C= hristian Groves; clue@ietf.org
Subject: Re: [clue= ] RTCWEB data channel for CLUE?

 

Hello folks,

 

I might be perhaps too naif, but I have to admit I d= on't see the point of discussion here. In my view, the CLUE protocol is ind= ependent from the underlying transport means. One of the potential transpor= ts (the best current option, IMHO) is the RtcWeb/WebRTC data channel. I think we should keep on specifying CL= UE protocol messages and state machines in the CLUE protocol document. We m= ight then write a document illustrating how it is possible to seamlessly im= plement such a protocol on top of the RtcWeb data channel. I am actually working on an individual contributi= on which basically illustrates the above concepts, by also providing a coup= le of call flows. I also believe that Christer's proposal perfectly fits su= ch an approach. Should the WG decide that this option is worth exploring, I would be glad to contribute.

 

Cheers,

 

Simon

 

 

Il giorno 30/gen/2014, alle ore 08:34, Christer Holm= berg ha scritto:




Hi,



Could we use this for CLUE without using the rtcweb = data channel mechanism?

If we want to have interoperability with rtcweb, we = need to use the SCTP properties defined in the rtcweb data channel draft.

I have not heard, or identified myself, any reason w= hy that would be a problem for CLUE.

 

[MB] I think the decision to be made by CLUE needs t= o more importantly consider whether that approach works for CLUE without RT= CWEB.  We

discussed on the call that the RTCWEB WG document (i= .e., draft-ietf-rtcweb-data-channel/) could be viewed as providing a more g= eneric mechanism

that can be used for applications beyond RTCWEB.


Yes. The rtcweb data channel is designed so that it works with JavaScript a= pplications. But, as I said on the call, there is nothing JavaScript specif= ic about. Not even all rtcweb applications will be JavaScript based.



That all said, as an individual, I don't see it to b= e a tremendous amount of work to write a  clue-data-channel document t= hat uses identical

mechanisms but has content specific to CLUE.  F= or example, the generic aspects in the RTCWEB seem to be primarily limited = to

section 5 (just over 3 pages of text).  Section= 4 has some generic aspects, but also some of it is RTCWEB specific. And, s= ection 3 is totally specific

to RTCWEB.  And, we need to decide how much of = section 6 applies to CLUE.So, personally, I think CLUE could just write the= ir own document

(and perhaps mention that procedures in section blah= are identical to those for RTCWEB OR write a general document that both CL= UE and

RTCWEB can reference (although the doc would have mo= re boiler plate than content.  Or perhaps, section 5 could be folded i= nto the

tsvwg document (although I haven't looked at that in= detail to see if it would work). [/MB] 


We could for sure write our own document, eventhough much would be copy/pas= te from the rtcweb document. 

However, even if we write our own document, assuming we want interoperabili= ty, we would STILL have a dependency on the rtcweb data channel, because th= at's where the SCTP PPID values are defined.

I can try to put something together.

Regards,

Christer

 

      &nbs= p;                         &n= bsp;            = ;            &n= bsp;                _\\|//_

      &nbs= p;                            = ;            &n= bsp;                ( O-O )<= /span>

   ~~~~~~~~~~~~= ~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

      &nbs= p;                 =             &nb= sp;            =          Simon Pietro Romano

      &nbs= p;         &nb= sp;            =             &nb= sp;       Universita' di Napoli Federico II

      &nbs= p;          &n= bsp;                Computer= Engineering Department 

         <= span class=3D"apple-converted-space">              Phone: +39 081 7683823 -- Fax= : +39 081 7683816

      &nbs= p;                     &n= bsp;              e-mail: sp= romano@unina.it

 <= /p>

           &nb= sp;           <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli&nbs= p;

           &nb= sp;           idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.

      &nbs= p;              &nb= sp;            =                          oooO<= /span>

  ~~~~~~~~~~~~~~~~~~= ~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

           &nb= sp;            =             &nb= sp;                            \ (     &= nbsp;      (   )

           &nb= sp;            =      =                       &nbs= p;           \_)          = ;) /

      &nbs= p;                     &n= bsp;                     =                      = ;(_/

 <= /p>

 <= /p>

 <= /p>




 

      &nbs= p;                         &n= bsp;            = ;            &n= bsp;              &nb= sp; _\\|//_

      &nbs= p;                            = ;            &n= bsp;                ( O-O )

   ~~~~~~~~~~~~= ~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

      &nbs= p;                 =             &nb= sp;            =          Simon Pietro Romano

      &nbs= p;         &nb= sp;            =             &nb= sp;       Universita' di Na= poli Federico II

      &nbs= p;          &n= bsp;                Computer Engineering Department =

                   =     Phone: +39 081 7683823 -- Fax: +39 081 7683816

      &nbs= p;                     &n= bsp;              e-mail: spromano@unina.it

 <= /p>

           &nb= sp;           <<Molti mi dic= ono che lo scoraggiamento =E8 l'alibi degli 

           &nb= sp;           idioti. Ci rifl= etto un istante; e mi scoraggio>>. Magritte.

      &nbs= p;              &nb= sp;            =                        = ;  oooO

  ~~~~~~~~~~~~~~~~~~= ~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

           &nb= sp;            =             &nb= sp;                    =        \ (            ( =   )

           &nb= sp;            =               =                     &nbs= p;   \_)          ) /

      &nbs= p;                     &n= bsp;                     =                      = ;(_/

 <= /p>

 <= /p>

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D14BA55ESESSMB209erics_-- From Christian.Groves@nteczone.com Thu Jan 30 01:51: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 7A3D71A03C5 for ; Thu, 30 Jan 2014 01:51:23 -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 0lvDXMjU711C for ; Thu, 30 Jan 2014 01:51:21 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29ED1A0363 for ; Thu, 30 Jan 2014 01:51:20 -0800 (PST) Received: from ppp118-209-220-51.lns20.mel6.internode.on.net ([118.209.220.51]:65512 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1W8oGl-0008IZ-33; Thu, 30 Jan 2014 20:50:47 +1100 Message-ID: <52EA2090.6040105@nteczone.com> Date: Thu, 30 Jan 2014 20:51:12 +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 , Simon Pietro Romano References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14BA55@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: Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 09:51:23 -0000 Hello, I think we need something in CLUE which says how it works with SCTP. There will be things we still need to do like registering a media-subtype "CLUE" (if that is still part of the SCTP SDP draft) etc. I assume that wouldn't be done in RTCWEB. Regards, Christian On 30/01/2014 7:42 PM, Christer Holmberg wrote: > > Hi, > > We need to make assumptions on whether the transport provides > reliability and in-order. When using DTLS/SCTP/UDP, those features > are optional, as far as I know. > > Anyway, I am not saying that we havent made such assumptions already > it was more a general comment when talking about the separation > between protocol and transport. > > Regards, > > Christer > > *From:*Simon Pietro Romano [mailto:spromano@unina.it] > *Sent:* 30. tammikuuta 2014 10:36 > *To:* Christer Holmberg > *Cc:* Mary Barnes; Christian Groves; clue@ietf.org > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > Hi Christer, > > However, when we define the CLUE protocol state machine, we DO > need to make some assumptions about the transport, e.g. whether it > provides reliable transport, in-order transport etc. If not, such > mechanisms need to be implemented in the CLUE protocol itself > (similar to what is done in SIP with message re-transmission, > usage of CSeq etc). > > The CLUE protocol draft currently states the following: > > CLUE Participants are connected by means of the CLUE signaling > channel. Such channel has been conceived as a DTLS/SCTP/UDP channel > in [I-D.kyzivat-clue-signaling ] and it is established as depicted in > the same document. CLUE protocol messages flow across such channel. > > We assume the > DTLS/SCTP/UDP channel is established and define the behiavior of the > CLUE Participants communicating on it. We discuss how the CLUE > dialogue between them can be exploited to successfully setup the > telepresence session according to the principles and concepts pointed > out in in [I-D.ietf-clue-framework ]. > > Isn't this already enough? If not, what other assumptions do you think > we should make? > > Thanks, > > Simon > > But, I strongly think that we shall decide on **A** transport > mechanism for the CLUE protocol. Otherwise we wont even guarantee > interoperability between CLUE entities. > > Regards, > > Christer > > *From:*Simon Pietro Romano [mailto:spromano@unina.it] > *Sent:*30. tammikuuta 2014 10:14 > *To:*Christer Holmberg > *Cc:*Mary Barnes; Christian Groves; clue@ietf.org > > *Subject:*Re: [clue] RTCWEB data channel for CLUE? > > Hello folks, > > I might be perhaps too naif, but I have to admit I don't see the > point of discussion here. In my view, the CLUE protocol is > independent from the underlying transport means. One of the > potential transports (the best current option, IMHO) is the > RtcWeb/WebRTC data channel. I think we should keep on specifying > CLUE protocol messages and state machines in the CLUE protocol > document. We might then write a document illustrating how it is > possible to seamlessly implement such a protocol on top of the > RtcWeb data channel. I am actually working on an individual > contribution which basically illustrates the above concepts, by > also providing a couple of call flows. I also believe that > Christer's proposal perfectly fits such an approach. Should the WG > decide that this option is worth exploring, I would be glad to > contribute. > > Cheers, > > Simon > > Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha scritto: > > > > > Hi, > > > > Could we use this for CLUE without using the rtcweb data > channel mechanism? > > If we want to have interoperability with rtcweb, we need > to use the SCTP properties defined in the rtcweb data > channel draft. > > I have not heard, or identified myself, any reason why > that would be a problem for CLUE. > > [MB] I think the decision to be made by CLUE needs to more > importantly consider whether that approach works for CLUE > without RTCWEB. We > > discussed on the call that the RTCWEB WG document (i.e., > draft-ietf-rtcweb-data-channel/) could be viewed as providing > a more generic mechanism > > that can be used for applications beyond RTCWEB. > > > Yes. The rtcweb data channel is designed so that it works with > JavaScript applications. But, as I said on the call, there is > nothing JavaScript specific about. Not even all rtcweb > applications will be JavaScript based. > > > > That all said, as an individual, I don't see it to be a tremendous > amount of work to write a clue-data-channel document that uses > identical > > mechanisms but has content specific to CLUE. For example, the > generic aspects in the RTCWEB seem to be primarily limited to > > section 5 (just over 3 pages of text). Section 4 has some > generic aspects, but also some of it is RTCWEB specific. And, > section 3 is totally specific > > to RTCWEB. And, we need to decide how much of section 6 > applies to CLUE.So, personally, I think CLUE could just write > their own document > > (and perhaps mention that procedures in section blah are > identical to those for RTCWEB OR write a general document that > both CLUE and > > RTCWEB can reference (although the doc would have more boiler > plate than content. Or perhaps, section 5 could be folded into the > > tsvwg document (although I haven't looked at that in detail to > see if it would work). [/MB] > > > We could for sure write our own document, eventhough much would be > copy/paste from the rtcweb document. > > However, even if we write our own document, assuming we want > interoperability, we would STILL have a dependency on the rtcweb > data channel, because that's where the SCTP PPID values are defined. > > I can try to put something together. > > Regards, > > Christer > > _\\|//_ > > ( O-O ) > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > Simon Pietro Romano > > Universita' di Napoli Federico II > > Computer Engineering Department > > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > > e-mail:spromano@unina.it > > < > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > oooO > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > > \_) ) / > > (_/ > > > > > _\\|//_ > > ( O-O ) > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > Simon Pietro Romano > > Universita' di Napoli Federico II > > Computer Engineering Department > > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > > e-mail: spromano@unina.it > > < > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > oooO > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > > \_) ) / > > (_/ > From mary.ietf.barnes@gmail.com Thu Jan 30 06:13: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 F3F3E1A0364 for ; Thu, 30 Jan 2014 06:13:29 -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 J6DRm2b0PMqx for ; Thu, 30 Jan 2014 06:13:25 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 748CD1A0362 for ; Thu, 30 Jan 2014 06:13:25 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id tp5so3358001ieb.19 for ; Thu, 30 Jan 2014 06:13:22 -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=tv956maSIGGkGjMeIS3xPOEjlNo82F6g5d5mm9uuTFw=; b=BtE1232iEXVRd5UWpsNBjoWYyitWi+qrmiMBzui2hdb2hKUW1WFXQ67IZnOeB0QcPx pk30An8UoPqEvJytk/2zJ2N2rCCtbS1Md7U/VdJXfIj8hpCyxO0YdS8hOLUXdObUXbux G//1Yb34KXp0Z3eM+oJ0+SV3+lHRdntgeoBrHXCtW+dKTDLlhkcgnRzEaXohF9gVg0gP gyg4oB0pVspVgATk5tViZQn82iYZb7C25g0wxPhZmV9OhcqmnEqe4uJXIT3ZP/LgEJMI iWK/Oqgg/WNrBSu/pUOz6JFqxuLQiKO18oM2pFPXSdTvd3Y5ymapSEZchWjvRS9IEzsG 5hkQ== MIME-Version: 1.0 X-Received: by 10.43.138.143 with SMTP id is15mr10747169icc.23.1391091202132; Thu, 30 Jan 2014 06:13:22 -0800 (PST) Received: by 10.43.58.137 with HTTP; Thu, 30 Jan 2014 06:13:21 -0800 (PST) In-Reply-To: <52EA2090.6040105@nteczone.com> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> Date: Thu, 30 Jan 2014 08:13:21 -0600 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=001a11c1ca12f4125d04f130a861 Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 14:13:30 -0000 --001a11c1ca12f4125d04f130a861 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think part of the debate here is whether any of the SCTP related stuff beyond what Simon has already noted is in the CLUE protocol document would be in the CLUE protocol document. I had envisioned that as Simon noted, the CLUE protocol itself is designed to be independent of the transport. We could add a reference to a separate CLUE document that discusses the specifics of how CLUE uses SCTP (and a note that other transports could also be used). That latter document could reference the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide). And, we already have that as a separate milestone. I think it's very important to decouple the protocol from the transport. Mary. On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello, > > I think we need something in CLUE which says how it works with SCTP. Ther= e > will be things we still need to do like registering a media-subtype "CLUE= " > (if that is still part of the SCTP SDP draft) etc. I assume that wouldn't > be done in RTCWEB. > > Regards, > Christian > > > On 30/01/2014 7:42 PM, Christer Holmberg wrote: > >> >> Hi, >> >> We need to make assumptions on whether the transport provides reliabilit= y >> and in-order. When using "DTLS/SCTP/UDP", those features are optional, a= s >> far as I know. >> >> Anyway, I am not saying that we haven't made such assumptions already - >> it was more a general comment when talking about the separation between >> protocol and transport. >> >> Regards, >> >> Christer >> >> *From:*Simon Pietro Romano [mailto:spromano@unina.it] >> *Sent:* 30. tammikuuta 2014 10:36 >> *To:* Christer Holmberg >> *Cc:* Mary Barnes; Christian Groves; clue@ietf.org >> *Subject:* Re: [clue] RTCWEB data channel for CLUE? >> >> >> Hi Christer, >> >> However, when we define the CLUE protocol state machine, we DO >> need to make some assumptions about the transport, e.g. whether it >> provides reliable transport, in-order transport etc. If not, such >> mechanisms need to be implemented in the CLUE protocol itself >> (similar to what is done in SIP with message re-transmission, >> usage of CSeq etc). >> >> The CLUE protocol draft currently states the following: >> >> CLUE Participants are connected by means of the CLUE signaling >> channel. Such channel has been conceived as a DTLS/SCTP/UDP channel >> in [I-D.kyzivat-clue-signaling > draft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is >> established as depicted in >> >> the same document. CLUE protocol messages flow across such channel. >> >> We assume the >> DTLS/SCTP/UDP channel is established and define the behiavior of the >> CLUE Participants communicating on it. We discuss how the CLUE >> dialogue between them can be exploited to successfully setup the >> telepresence session according to the principles and concepts pointe= d >> out in in [I-D.ietf-clue-framework > draft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>]. >> >> >> Isn't this already enough? If not, what other assumptions do you think w= e >> should make? >> >> Thanks, >> >> Simon >> >> But, I strongly think that we shall decide on **A** transport >> >> mechanism for the CLUE protocol. Otherwise we won't even guarantee >> interoperability between CLUE entities. >> >> Regards, >> >> Christer >> >> *From:*Simon Pietro Romano [mailto:spromano@unina.it] >> *Sent:*30. tammikuuta 2014 10:14 >> *To:*Christer Holmberg >> *Cc:*Mary Barnes; Christian Groves; clue@ietf.org >> >> *Subject:*Re: [clue] RTCWEB data channel for CLUE? >> >> >> Hello folks, >> >> I might be perhaps too naif, but I have to admit I don't see the >> point of discussion here. In my view, the CLUE protocol is >> independent from the underlying transport means. One of the >> potential transports (the best current option, IMHO) is the >> RtcWeb/WebRTC data channel. I think we should keep on specifying >> CLUE protocol messages and state machines in the CLUE protocol >> document. We might then write a document illustrating how it is >> possible to seamlessly implement such a protocol on top of the >> RtcWeb data channel. I am actually working on an individual >> contribution which basically illustrates the above concepts, by >> also providing a couple of call flows. I also believe that >> Christer's proposal perfectly fits such an approach. Should the WG >> decide that this option is worth exploring, I would be glad to >> contribute. >> >> Cheers, >> >> Simon >> >> Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha scritto: >> >> >> >> >> Hi, >> >> >> >> Could we use this for CLUE without using the rtcweb data >> channel mechanism? >> >> If we want to have interoperability with rtcweb, we need >> to use the SCTP properties defined in the rtcweb data >> channel draft. >> >> I have not heard, or identified myself, any reason why >> that would be a problem for CLUE. >> >> [MB] I think the decision to be made by CLUE needs to more >> importantly consider whether that approach works for CLUE >> without RTCWEB. We >> >> discussed on the call that the RTCWEB WG document (i.e., >> draft-ietf-rtcweb-data-channel/) could be viewed as providing >> a more generic mechanism >> >> that can be used for applications beyond RTCWEB. >> >> >> Yes. The rtcweb data channel is designed so that it works with >> JavaScript applications. But, as I said on the call, there is >> nothing JavaScript specific about. Not even all rtcweb >> applications will be JavaScript based. >> >> >> >> That all said, as an individual, I don't see it to be a tremendous >> amount of work to write a clue-data-channel document that uses >> identical >> >> mechanisms but has content specific to CLUE. For example, the >> generic aspects in the RTCWEB seem to be primarily limited to >> >> section 5 (just over 3 pages of text). Section 4 has some >> generic aspects, but also some of it is RTCWEB specific. And, >> section 3 is totally specific >> >> to RTCWEB. And, we need to decide how much of section 6 >> applies to CLUE.So, personally, I think CLUE could just write >> their own document >> >> (and perhaps mention that procedures in section blah are >> identical to those for RTCWEB OR write a general document that >> both CLUE and >> >> RTCWEB can reference (although the doc would have more boiler >> plate than content. Or perhaps, section 5 could be folded into t= he >> >> tsvwg document (although I haven't looked at that in detail to >> see if it would work). [/MB] >> >> >> We could for sure write our own document, eventhough much would be >> copy/paste from the rtcweb document. >> >> However, even if we write our own document, assuming we want >> interoperability, we would STILL have a dependency on the rtcweb >> data channel, because that's where the SCTP PPID values are defined. >> >> I can try to put something together. >> >> Regards, >> >> Christer >> >> _\\|//_ >> >> ( O-O ) >> >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Simon Pietro Romano >> >> Universita' di Napoli Federico II >> >> Computer Engineering Department >> >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> >> e-mail:spromano@unina.it >> >> >> <> >> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> >> oooO >> >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> \ ( ( ) >> >> \_) ) / >> >> (_/ >> >> >> >> >> _\\|//_ >> >> ( O-O ) >> >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Simon Pietro Romano >> >> Universita' di Napoli Federico II >> >> Computer Engineering Department >> >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> >> e-mail: spromano@unina.it >> >> >> <> >> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> >> oooO >> >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> \ ( ( ) >> >> \_) ) / >> >> (_/ >> >> > --001a11c1ca12f4125d04f130a861 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think part of the debate here is whether any of the SCTP= related stuff beyond what Simon has already noted is in the CLUE protocol = document would be in the CLUE protocol document.  I had envisioned tha= t as Simon noted, the CLUE protocol itself is designed to be independent of= the transport.  We could add a reference to a separate CLUE document = that discusses the specifics of how CLUE uses SCTP (and a note that other t= ransports could also be used).  That latter document could reference t= he RTCWEB and TSVWG documents (or MMUSIC if that's what we decide). &nb= sp;  And, we already have that as a separate milestone. 

I think it's very important to decouple the protocol fro= m the transport.

Mary. 




On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves <Christian.G= roves@nteczone.com> wrote:
Hello,

I think we need something in CLUE which says how it works with SCTP. There = will be things we still need to do like registering a media-subtype "C= LUE" (if that is still part of the SCTP SDP draft) etc. I assume that = wouldn't be done in RTCWEB.

Regards,
Christian


On 30/01/2014 7:42 PM, Christer Holmberg wrote:

Hi,

We need to make assumptions on whether the transport provides reliability a= nd in-order. When using “DTLS/SCTP/UDP”, those features are opt= ional, as far as I know.

Anyway, I am not saying that we haven’t made such assumptions already= – it was more a general comment when talking about the separation be= tween protocol and transport.

Regards,

Christer

*From:*Simon Pietro Romano [mailto:spromano@unina.it]
*Sent:* 30. tammikuuta 2014 10:36
*To:* Christer Holmberg
*Cc:* Mary Barnes; Christian Groves; clue@ietf.org
*Subject:* Re: [clue] RTCWEB data channel for CLUE?


Hi Christer,

    However, when we define the CLUE protocol state machine, we D= O
    need to make some assumptions about the transport, e.g. wheth= er it
    provides reliable transport, in-order transport etc. If not, = such
    mechanisms need to be implemented in the CLUE protocol itself=
    (similar to what is done in SIP with message re-transmission,=
    usage of CSeq etc).

The CLUE protocol draft currently states the following:

CLUE Participants are connected by means of the CLUE signaling
    channel.  Such channel has been conceived as a DTLS/SCTP= /UDP channel
    in [I-D.kyzivat-clue-signaling  <http://tools.ietf.org/html/draft-presta-clue-= protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is= established as depicted in

    the same document.  CLUE protocol messages flow across s= uch channel.

We assume the
    DTLS/SCTP/UDP channel is established and define the behiavior= of the
    CLUE Participants communicating on it.  We discuss how t= he CLUE
    dialogue between them can be exploited to successfully setup = the
    telepresence session according to the principles and concepts= pointed
    out in in [I-D.ietf-clue-framework  <http://tools.ietf.org/html/draft-presta-clue= -protocol-03#ref-I-D.ietf-clue-framework>].


Isn't this already enough? If not, what other assumptions do you think = we should make?

Thanks,

Simon

    But, I strongly think that we shall decide on **A** transport=

    mechanism for the CLUE protocol. Otherwise we won’t eve= n guarantee
    interoperability between CLUE entities.

    Regards,

    Christer

    *From:*Simon Pietro Romano [mailto:spromano@unina.it]
    *Sent:*30. tammikuuta 2014 10:14
    *To:*Christer Holmberg
    *Cc:*Mary Barnes; Christian Groves; clue@ietf.org
    <mailto:clue@ietf.org>
    *Subject:*Re: [clue] RTCWEB data channel for CLUE?


    Hello folks,

    I might be perhaps too naif, but I have to admit I don't = see the
    point of discussion here. In my view, the CLUE protocol is     independent from the underlying transport means. One of the     potential transports (the best current option, IMHO) is the     RtcWeb/WebRTC data channel. I think we should keep on specify= ing
    CLUE protocol messages and state machines in the CLUE protoco= l
    document. We might then write a document illustrating how it = is
    possible to seamlessly implement such a protocol on top of th= e
    RtcWeb data channel. I am actually working on an individual     contribution which basically illustrates the above concepts, = by
    also providing a couple of call flows. I also believe that     Christer's proposal perfectly fits such an approach. Shou= ld the WG
    decide that this option is worth exploring, I would be glad t= o
    contribute.

    Cheers,

    Simon

    Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha s= critto:




    Hi,



            Could we use this for CLUE withou= t using the rtcweb data
            channel mechanism?

            If we want to have interoperabili= ty with rtcweb, we need
            to use the SCTP properties define= d in the rtcweb data
            channel draft.

            I have not heard, or identified m= yself, any reason why
            that would be a problem for CLUE.=

        [MB] I think the decision to be made by CLUE ne= eds to more
        importantly consider whether that approach work= s for CLUE
        without RTCWEB. We

        discussed on the call that the RTCWEB WG docume= nt (i.e.,
        draft-ietf-rtcweb-data-channel/) could b= e viewed as providing
        a more generic mechanism

        that can be used for applications beyond RTCWEB= .


    Yes. The rtcweb data channel is designed so that it works wit= h
    JavaScript applications. But, as I said on the call, there is=
    nothing JavaScript specific about. Not even all rtcweb
    applications will be JavaScript based.



    That all said, as an individual, I don't see it to be a t= remendous
    amount of work to write a clue-data-channel document that use= s
    identical

        mechanisms but has content specific to CLUE. Fo= r example, the
        generic aspects in the RTCWEB seem to be primar= ily limited to

        section 5 (just over 3 pages of text). Section = 4 has some
        generic aspects, but also some of it is RTCWEB = specific. And,
        section 3 is totally specific

        to RTCWEB. And, we need to decide how much of s= ection 6
        applies to CLUE.So, personally, I think CLUE co= uld just write
        their own document

        (and perhaps mention that procedures in section= blah are
        identical to those for RTCWEB OR write a genera= l document that
        both CLUE and

        RTCWEB can reference (although the doc would ha= ve more boiler
        plate than content. Or perhaps, section 5 could= be folded into the

        tsvwg document (although I haven't looked a= t that in detail to
        see if it would work). [/MB]


    We could for sure write our own document, eventhough much wou= ld be
    copy/paste from the rtcweb document.

    However, even if we write our own document, assuming we want<= br>     interoperability, we would STILL have a dependency on the rtc= web
    data channel, because that's where the SCTP PPID values a= re defined.

    I can try to put something together.

    Regards,

    Christer

    _\\|//_

    ( O-O )

    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~= ~~~~~

    Simon Pietro Romano

    Universita' di Napoli Federico II

    Computer Engineering Department

    Phone: +39 081 7683823 -- Fax: +39 081 7683816<= /a>

    e-mail:spromano@unina.it <mailto:spromano@unina.it>


    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi= degli

    idioti. Ci rifletto un istante; e mi scoraggio>>. Magri= tte.

    oooO

    ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
    \ ( ( )

    \_) ) /

    (_/




_\\|//_

( O-O )

~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

Simon Pietro Romano

Universita' di Napoli Federico II

Computer Engineering Department

Phone: +39 081 7683823 -- Fax: +39 081 7683816

e-mail: spromano@uni= na.it <mailto:spromano@unina.it>


<<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli

idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.

oooO

~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

\ ( ( )

\_) ) /

(_/



--001a11c1ca12f4125d04f130a861-- From christer.holmberg@ericsson.com Thu Jan 30 06:18: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 B80BE1A038C for ; Thu, 30 Jan 2014 06:18: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, 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 iI7pFCFaYW-f for ; Thu, 30 Jan 2014 06:18:41 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id B8A551A036A for ; Thu, 30 Jan 2014 06:18:40 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-66-52ea5f3c1764 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6B.52.04249.C3F5AE25; Thu, 30 Jan 2014 15:18:36 +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; Thu, 30 Jan 2014 15:18:36 +0100 From: Christer Holmberg To: Mary Barnes , Christian Groves Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AASGoAAABEq/QAAAWrOgAAGa6TgAAm/AoAAIlJjgP///J6A///sArCAABouAP//7jGwgAAmwwCAAEk/gP//7g9w Date: Thu, 30 Jan 2014 14:18:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> 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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D14D5F3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvja5N/Ksgg5bb5hZf3jeyWOw/dZnZ 4vP+/cwW29puMDuweOycdZfdY8mSn0weK87PZPH4seUpUwBLFJdNSmpOZllqkb5dAlfGy3lH WQraLzBWnHiynamB8f9qxi5GTg4JAROJO1132CBsMYkL99YD2VwcQgJHGCUOvPjAApIQEljM KHF7o1YXIwcHm4CFRPc/bZCwiECCxK0j25lAbGYBH4nHr2eBzRQWMJRo7tnODFFjJLH78ypm kJkiAk2MEl86TrOCzGERUJW48l0MpIZXwFei6dAURoi931kl3reuBWvmFAiUWPSmgRXEZgQ6 7vupNVDLxCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC2IoSO8+2M0PU50ssn3uAFWKZoMTJmU9Y JjCKzkIyahaSsllIyiDiehI3pk5hg7C1JZYtfM0MYetKzPh3iAVZfAEj+ypGjuLU4qTcdCOD TYzACDy45bfFDsbLf20OMUpzsCiJ83586xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVHA bcO6Y9c3V6/6NSEwqvVYdEluU2e0bCfv84WXvIze/P6kwyKb37TBUOTuGf5Ihd2+W/kXd/Mr 3t8h41l6PkD/9ZOXjsxbTmwN0rFOX6Sk5H/K4e0th39zptt4Wp/skdpQz5kiGLB2tfueBF5v 3XbpeE+B/fLngg4+4Pc239S71Mh4l+eqciWW4oxEQy3mouJEADpipHqOAgAA Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 14:18:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D14D5F3ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am sure we'll find a home for the text - the important thing now is to ag= ree on the mechanism, and to get the text written. Regards, Christer From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 30. tammikuuta 2014 16:13 To: Christian Groves Cc: Christer Holmberg; Simon Pietro Romano; clue@ietf.org Subject: Re: [clue] RTCWEB data channel for CLUE? I think part of the debate here is whether any of the SCTP related stuff be= yond what Simon has already noted is in the CLUE protocol document would be= in the CLUE protocol document. I had envisioned that as Simon noted, the = CLUE protocol itself is designed to be independent of the transport. We co= uld add a reference to a separate CLUE document that discusses the specific= s of how CLUE uses SCTP (and a note that other transports could also be use= d). That latter document could reference the RTCWEB and TSVWG documents (o= r MMUSIC if that's what we decide). And, we already have that as a separ= ate milestone. I think it's very important to decouple the protocol from the transport. Mary. On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves > wrote: Hello, I think we need something in CLUE which says how it works with SCTP. There = will be things we still need to do like registering a media-subtype "CLUE" = (if that is still part of the SCTP SDP draft) etc. I assume that wouldn't b= e done in RTCWEB. Regards, Christian On 30/01/2014 7:42 PM, Christer Holmberg wrote: Hi, We need to make assumptions on whether the transport provides reliability a= nd in-order. When using "DTLS/SCTP/UDP", those features are optional, as fa= r as I know. Anyway, I am not saying that we haven't made such assumptions already - it = was more a general comment when talking about the separation between protoc= ol and transport. Regards, Christer *From:*Simon Pietro Romano [mailto:spromano@unina.it] *Sent:* 30. tammikuuta 2014 10:36 *To:* Christer Holmberg *Cc:* Mary Barnes; Christian Groves; clue@ietf.org *Subject:* Re: [clue] RTCWEB data channel for CLUE? Hi Christer, However, when we define the CLUE protocol state machine, we DO need to make some assumptions about the transport, e.g. whether it provides reliable transport, in-order transport etc. If not, such mechanisms need to be implemented in the CLUE protocol itself (similar to what is done in SIP with message re-transmission, usage of CSeq etc). The CLUE protocol draft currently states the following: CLUE Participants are connected by means of the CLUE signaling channel. Such channel has been conceived as a DTLS/SCTP/UDP channel in [I-D.kyzivat-clue-signaling ] and it is established a= s depicted in the same document. CLUE protocol messages flow across such channel. We assume the DTLS/SCTP/UDP channel is established and define the behiavior of the CLUE Participants communicating on it. We discuss how the CLUE dialogue between them can be exploited to successfully setup the telepresence session according to the principles and concepts pointed out in in [I-D.ietf-clue-framework ]. Isn't this already enough? If not, what other assumptions do you think we s= hould make? Thanks, Simon But, I strongly think that we shall decide on **A** transport mechanism for the CLUE protocol. Otherwise we won't even guarantee interoperability between CLUE entities. Regards, Christer *From:*Simon Pietro Romano [mailto:spromano@unina.it] *Sent:*30. tammikuuta 2014 10:14 *To:*Christer Holmberg *Cc:*Mary Barnes; Christian Groves; clue@ietf.org > *Subject:*Re: [clue] RTCWEB data channel for CLUE? Hello folks, I might be perhaps too naif, but I have to admit I don't see the point of discussion here. In my view, the CLUE protocol is independent from the underlying transport means. One of the potential transports (the best current option, IMHO) is the RtcWeb/WebRTC data channel. I think we should keep on specifying CLUE protocol messages and state machines in the CLUE protocol document. We might then write a document illustrating how it is possible to seamlessly implement such a protocol on top of the RtcWeb data channel. I am actually working on an individual contribution which basically illustrates the above concepts, by also providing a couple of call flows. I also believe that Christer's proposal perfectly fits such an approach. Should the WG decide that this option is worth exploring, I would be glad to contribute. Cheers, Simon Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha scritto: Hi, Could we use this for CLUE without using the rtcweb data channel mechanism? If we want to have interoperability with rtcweb, we need to use the SCTP properties defined in the rtcweb data channel draft. I have not heard, or identified myself, any reason why that would be a problem for CLUE. [MB] I think the decision to be made by CLUE needs to more importantly consider whether that approach works for CLUE without RTCWEB. We discussed on the call that the RTCWEB WG document (i.e., draft-ietf-rtcweb-data-channel/) could be viewed as providing a more generic mechanism that can be used for applications beyond RTCWEB. Yes. The rtcweb data channel is designed so that it works with JavaScript applications. But, as I said on the call, there is nothing JavaScript specific about. Not even all rtcweb applications will be JavaScript based. That all said, as an individual, I don't see it to be a tremendous amount of work to write a clue-data-channel document that uses identical mechanisms but has content specific to CLUE. For example, the generic aspects in the RTCWEB seem to be primarily limited to section 5 (just over 3 pages of text). Section 4 has some generic aspects, but also some of it is RTCWEB specific. And, section 3 is totally specific to RTCWEB. And, we need to decide how much of section 6 applies to CLUE.So, personally, I think CLUE could just write their own document (and perhaps mention that procedures in section blah are identical to those for RTCWEB OR write a general document that both CLUE and RTCWEB can reference (although the doc would have more boiler plate than content. Or perhaps, section 5 could be folded into the tsvwg document (although I haven't looked at that in detail to see if it would work). [/MB] We could for sure write our own document, eventhough much would be copy/paste from the rtcweb document. However, even if we write our own document, assuming we want interoperability, we would STILL have a dependency on the rtcweb data channel, because that's where the SCTP PPID values are defined. I can try to put something together. Regards, Christer _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 76838= 16 e-mail:spromano@unina.it > <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it > <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --_000_7594FB04B1934943A5C02806D1A2204B1D14D5F3ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I am sure we’ll fin= d a home for the text – the important thing now is to agree on the me= chanism, and to get the text written.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Mary Bar= nes [mailto:mary.ietf.barnes@gmail.com]
Sent: 30. tammikuuta 2014 16:13
To: Christian Groves
Cc: Christer Holmberg; Simon Pietro Romano; clue@ietf.org
Subject: Re: [clue] RTCWEB data channel for CLUE?<= /p>

 

I think part of the debate here is whether any of th= e SCTP related stuff beyond what Simon has already noted is in the CLUE pro= tocol document would be in the CLUE protocol document.  I had envision= ed that as Simon noted, the CLUE protocol itself is designed to be independent of the transport.  We could add = a reference to a separate CLUE document that discusses the specifics of how= CLUE uses SCTP (and a note that other transports could also be used). &nbs= p;That latter document could reference the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide).   &n= bsp;And, we already have that as a separate milestone. 

 

I think it's very important to decouple the protocol= from the transport.

 

Mary. 

 

 

 

On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves &l= t;Christ= ian.Groves@nteczone.com> wrote:

Hello,

I think we need something in CLUE which says how it works with SCTP. There = will be things we still need to do like registering a media-subtype "C= LUE" (if that is still part of the SCTP SDP draft) etc. I assume that = wouldn't be done in RTCWEB.

Regards,
Christian



On 30/01/2014 7:42 PM, Christer Holmberg wrote:


Hi,

We need to make assumptions on whether the transport provides reliability a= nd in-order. When using “DTLS/SCTP/UDP”, those features are opt= ional, as far as I know.

Anyway, I am not saying that we haven’t made such assumptions already= – it was more a general comment when talking about the separation be= tween protocol and transport.

Regards,

Christer

*From:*Simon Pietro Romano [mailto:spromano@unina.it]
*Sent:* 30. tammikuuta 2014 10:36
*To:* Christer Holmberg
*Cc:* Mary Barnes; Christian Groves; clue@ietf.org
*Subject:* Re: [clue] RTCWEB data channel for CLUE?



Hi Christer,

    However, when we define the CLUE protocol state machine, we D= O
    need to make some assumptions about the transport, e.g. wheth= er it
    provides reliable transport, in-order transport etc. If not, = such
    mechanisms need to be implemented in the CLUE protocol itself=
    (similar to what is done in SIP with message re-transmission,=
    usage of CSeq etc).

The CLUE protocol draft currently states the following:

CLUE Participants are connected by means of the CLUE signaling
    channel.  Such channel has been conceived as a DTLS/SCTP= /UDP channel

    in [I-D.kyzivat-clue-signaling  &= lt;http://tools.ietf.org/html/dr= aft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is established as depicted in


    the same document.  CLUE protocol messages flow across s= uch channel.

We assume the
    DTLS/SCTP/UDP channel is established and define the behiavior= of the
    CLUE Participants communicating on it.  We discuss how t= he CLUE
    dialogue between them can be exploited to successfully setup = the
    telepresence session according to the principles and concepts= pointed

    out in in [I-D.ietf-clue-framework &nb= sp;<http://tools.ietf.org/html/d= raft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>].



Isn't this already enough? If not, what other assumptions do you think we s= hould make?

Thanks,

Simon

    But, I strongly think that we shall de= cide on **A** transport


    mechanism for the CLUE protocol. Otherwise we won’t eve= n guarantee
    interoperability between CLUE entities.

    Regards,

    Christer

    *From:*Simon Pietro Romano [mailto:spromano@unina.it]<= br>     *Sent:*30. tammikuuta 2014 10:14
    *To:*Christer Holmberg
    *Cc:*Mary Barnes; Christian Groves; clue@ietf.org
    <mailto:clue@ietf.org>
    *Subject:*Re: [clue] RTCWEB data channel for CLUE?=



    Hello folks,

    I might be perhaps too naif, but I have to admit I don't see = the
    point of discussion here. In my view, the CLUE protocol is     independent from the underlying transport means. One of the     potential transports (the best current option, IMHO) is the     RtcWeb/WebRTC data channel. I think we should keep on specify= ing
    CLUE protocol messages and state machines in the CLUE protoco= l
    document. We might then write a document illustrating how it = is
    possible to seamlessly implement such a protocol on top of th= e
    RtcWeb data channel. I am actually working on an individual     contribution which basically illustrates the above concepts, = by
    also providing a couple of call flows. I also believe that     Christer's proposal perfectly fits such an approach. Should t= he WG
    decide that this option is worth exploring, I would be glad t= o
    contribute.

    Cheers,

    Simon

    Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha s= critto:




    Hi,



            Could we use this for CLUE withou= t using the rtcweb data
            channel mechanism?

            If we want to have interoperabili= ty with rtcweb, we need
            to use the SCTP properties define= d in the rtcweb data
            channel draft.

            I have not heard, or identified m= yself, any reason why
            that would be a problem for CLUE.=

        [MB] I think the decision to be made by CLUE ne= eds to more
        importantly consider whether that approach work= s for CLUE
        without RTCWEB. We

        discussed on the call that the RTCWEB WG docume= nt (i.e.,
        draft-ietf-rtcweb-data-channel/) could be viewe= d as providing
        a more generic mechanism

        that can be used for applications beyond RTCWEB= .


    Yes. The rtcweb data channel is designed so that it works wit= h
    JavaScript applications. But, as I said on the call, there is=
    nothing JavaScript specific about. Not even all rtcweb
    applications will be JavaScript based.



    That all said, as an individual, I don't see it to be a treme= ndous
    amount of work to write a clue-data-channel document that use= s
    identical

        mechanisms but has content specific to CLUE. Fo= r example, the
        generic aspects in the RTCWEB seem to be primar= ily limited to

        section 5 (just over 3 pages of text). Section = 4 has some
        generic aspects, but also some of it is RTCWEB = specific. And,
        section 3 is totally specific

        to RTCWEB. And, we need to decide how much of s= ection 6
        applies to CLUE.So, personally, I think CLUE co= uld just write
        their own document

        (and perhaps mention that procedures in section= blah are
        identical to those for RTCWEB OR write a genera= l document that
        both CLUE and

        RTCWEB can reference (although the doc would ha= ve more boiler
        plate than content. Or perhaps, section 5 could= be folded into the

        tsvwg document (although I haven't looked at th= at in detail to
        see if it would work). [/MB]


    We could for sure write our own document, eventhough much wou= ld be
    copy/paste from the rtcweb document.

    However, even if we write our own document, assuming we want<= br>     interoperability, we would STILL have a dependency on the rtc= web
    data channel, because that's where the SCTP PPID values are d= efined.

    I can try to put something together.

    Regards,

    Christer

    _\\|//_

    ( O-O )

    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
    Simon Pietro Romano

    Universita' di Napoli Federico II

    Computer Engineering Department

    Phone: +39 081 7683823 -- Fax: +39 081 7683816=

    e-mail:spromano@unina.it <mailto:spromano@unina.it>



    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi deg= li

    idioti. Ci rifletto un istante; e mi scoraggio>>. Magri= tte.

    oooO

    ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
    \ ( ( )

    \_) ) /

    (_/




_\\|//_

( O-O )

~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

Simon Pietro Romano

Universita' di Napoli Federico II

Computer Engineering Department

Phone: +39 081 = 7683823 -- Fax: +39 081 7683816=

e-mail: spromano@unina.it <mailto:spromano@unina.it>



<<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli

idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.

oooO

~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

\ ( ( )

\_) ) /

(_/

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D14D5F3ESESSMB209erics_-- From mary.ietf.barnes@gmail.com Thu Jan 30 08:12: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 76E781A03E7 for ; Thu, 30 Jan 2014 08:12:41 -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 HX8VCWXQ7Dye for ; Thu, 30 Jan 2014 08:12:35 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 765321A039C for ; Thu, 30 Jan 2014 08:12:35 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id to1so3522254ieb.28 for ; Thu, 30 Jan 2014 08:12:32 -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=fPVshBsGMfcY/qlbS4uGHCCaQrv6m5h7Q3rG2efzZ8U=; b=mV2vmfPMfBYvzYxpScTtQMMKD6qOXA92/RMy0dkXzmWsGLyGKRfUPq04eIBbrSDue+ 19RxEcotS979jdg3E16NBVr6KQsn3DXiLD57FzC83GEJw9LBU4gNHX8fYMJIHAPjroF2 mRPdXF5bT+iCTI3wXYKzMSTEZn+ihwZQ3E7k7bQ7QYTOxPMeutsXNoJ8rcNYEYPxqBOB sMowhyAqB7PaTMo9wmBeicAypIGmiLzNtCMFg954X/m6KwXNITgDmbQ9HXUGcaacyie3 y7v61AcxhAalZpCSS+QFc+7mBtWzUvtF/+8jy78RF+aqD9AGMc9XUG22m5VLOAPi54Ek +vEQ== MIME-Version: 1.0 X-Received: by 10.50.4.97 with SMTP id j1mr31064324igj.19.1391098351883; Thu, 30 Jan 2014 08:12:31 -0800 (PST) Received: by 10.43.58.137 with HTTP; Thu, 30 Jan 2014 08:12:31 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se> Date: Thu, 30 Jan 2014 10:12:31 -0600 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c2cd4e1c9a9904f13253c1 Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 16:12:41 -0000 --001a11c2cd4e1c9a9904f13253c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sure. But, it's very important to keep in mind what we are talking about when referring to other documents. I'm thinking the best way forward would be to put together a document that list and evaluates all the alternatives versus diving in with the assumption that we'll use the RTCWEB mechanism. Just to be clear, I'm not suggesting that's a document we progress, but I think it is important to ensure that the WG considers all the options, pros/cons and applicability of each before we start working out the details. Mary. On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I am sure we'll find a home for the text - the important thing now is to > agree on the mechanism, and to get the text written. > > > > Regards, > > > > Christer > > > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* 30. tammikuuta 2014 16:13 > *To:* Christian Groves > *Cc:* Christer Holmberg; Simon Pietro Romano; clue@ietf.org > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > > > I think part of the debate here is whether any of the SCTP related stuff > beyond what Simon has already noted is in the CLUE protocol document woul= d > be in the CLUE protocol document. I had envisioned that as Simon noted, > the CLUE protocol itself is designed to be independent of the transport. > We could add a reference to a separate CLUE document that discusses the > specifics of how CLUE uses SCTP (and a note that other transports could > also be used). That latter document could reference the RTCWEB and TSVWG > documents (or MMUSIC if that's what we decide). And, we already have > that as a separate milestone. > > > > I think it's very important to decouple the protocol from the transport. > > > > Mary. > > > > > > > > On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves < > Christian.Groves@nteczone.com> wrote: > > Hello, > > I think we need something in CLUE which says how it works with SCTP. Ther= e > will be things we still need to do like registering a media-subtype "CLUE= " > (if that is still part of the SCTP SDP draft) etc. I assume that wouldn't > be done in RTCWEB. > > Regards, > Christian > > > > On 30/01/2014 7:42 PM, Christer Holmberg wrote: > > > Hi, > > We need to make assumptions on whether the transport provides reliability > and in-order. When using "DTLS/SCTP/UDP", those features are optional, as > far as I know. > > Anyway, I am not saying that we haven't made such assumptions already - i= t > was more a general comment when talking about the separation between > protocol and transport. > > Regards, > > Christer > > *From:*Simon Pietro Romano [mailto:spromano@unina.it] > *Sent:* 30. tammikuuta 2014 10:36 > *To:* Christer Holmberg > *Cc:* Mary Barnes; Christian Groves; clue@ietf.org > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > > > Hi Christer, > > However, when we define the CLUE protocol state machine, we DO > need to make some assumptions about the transport, e.g. whether it > provides reliable transport, in-order transport etc. If not, such > mechanisms need to be implemented in the CLUE protocol itself > (similar to what is done in SIP with message re-transmission, > usage of CSeq etc). > > The CLUE protocol draft currently states the following: > > CLUE Participants are connected by means of the CLUE signaling > channel. Such channel has been conceived as a DTLS/SCTP/UDP channel > > in [I-D.kyzivat-clue-signaling < > http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.kyzivat-= clue-signaling>] > and it is established as depicted in > > > the same document. CLUE protocol messages flow across such channel. > > We assume the > DTLS/SCTP/UDP channel is established and define the behiavior of the > CLUE Participants communicating on it. We discuss how the CLUE > dialogue between them can be exploited to successfully setup the > telepresence session according to the principles and concepts pointed > > out in in [I-D.ietf-clue-framework < > http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.ietf-clu= e-framework > >]. > > > > Isn't this already enough? If not, what other assumptions do you think we > should make? > > Thanks, > > Simon > > But, I strongly think that we shall decide on **A** transport > > > mechanism for the CLUE protocol. Otherwise we won't even guarantee > interoperability between CLUE entities. > > Regards, > > Christer > > *From:*Simon Pietro Romano [mailto:spromano@unina.it] > *Sent:*30. tammikuuta 2014 10:14 > *To:*Christer Holmberg > *Cc:*Mary Barnes; Christian Groves; clue@ietf.org > > *Subject:*Re: [clue] RTCWEB data channel for CLUE? > > > > Hello folks, > > I might be perhaps too naif, but I have to admit I don't see the > point of discussion here. In my view, the CLUE protocol is > independent from the underlying transport means. One of the > potential transports (the best current option, IMHO) is the > RtcWeb/WebRTC data channel. I think we should keep on specifying > CLUE protocol messages and state machines in the CLUE protocol > document. We might then write a document illustrating how it is > possible to seamlessly implement such a protocol on top of the > RtcWeb data channel. I am actually working on an individual > contribution which basically illustrates the above concepts, by > also providing a couple of call flows. I also believe that > Christer's proposal perfectly fits such an approach. Should the WG > decide that this option is worth exploring, I would be glad to > contribute. > > Cheers, > > Simon > > Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha scritto: > > > > > Hi, > > > > Could we use this for CLUE without using the rtcweb data > channel mechanism? > > If we want to have interoperability with rtcweb, we need > to use the SCTP properties defined in the rtcweb data > channel draft. > > I have not heard, or identified myself, any reason why > that would be a problem for CLUE. > > [MB] I think the decision to be made by CLUE needs to more > importantly consider whether that approach works for CLUE > without RTCWEB. We > > discussed on the call that the RTCWEB WG document (i.e., > draft-ietf-rtcweb-data-channel/) could be viewed as providing > a more generic mechanism > > that can be used for applications beyond RTCWEB. > > > Yes. The rtcweb data channel is designed so that it works with > JavaScript applications. But, as I said on the call, there is > nothing JavaScript specific about. Not even all rtcweb > applications will be JavaScript based. > > > > That all said, as an individual, I don't see it to be a tremendous > amount of work to write a clue-data-channel document that uses > identical > > mechanisms but has content specific to CLUE. For example, the > generic aspects in the RTCWEB seem to be primarily limited to > > section 5 (just over 3 pages of text). Section 4 has some > generic aspects, but also some of it is RTCWEB specific. And, > section 3 is totally specific > > to RTCWEB. And, we need to decide how much of section 6 > applies to CLUE.So, personally, I think CLUE could just write > their own document > > (and perhaps mention that procedures in section blah are > identical to those for RTCWEB OR write a general document that > both CLUE and > > RTCWEB can reference (although the doc would have more boiler > plate than content. Or perhaps, section 5 could be folded into th= e > > tsvwg document (although I haven't looked at that in detail to > see if it would work). [/MB] > > > We could for sure write our own document, eventhough much would be > copy/paste from the rtcweb document. > > However, even if we write our own document, assuming we want > interoperability, we would STILL have a dependency on the rtcweb > data channel, because that's where the SCTP PPID values are defined. > > I can try to put something together. > > Regards, > > Christer > > _\\|//_ > > ( O-O ) > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > Simon Pietro Romano > > Universita' di Napoli Federico II > > Computer Engineering Department > > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > > e-mail:spromano@unina.it > > > > < > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > oooO > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > > \_) ) / > > (_/ > > > > > _\\|//_ > > ( O-O ) > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > Simon Pietro Romano > > Universita' di Napoli Federico II > > Computer Engineering Department > > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > > e-mail: spromano@unina.it > > > > < > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > oooO > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > > \_) ) / > > (_/ > > > > > --001a11c2cd4e1c9a9904f13253c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sure. But, it's very important to keep in mind what we= are talking about when referring to other documents.  

=
I'm thinking the best way forward would be to put together a docum= ent that list and evaluates all the alternatives versus diving in with the = assumption that we'll use the RTCWEB mechanism.   Just to be clear= , I'm not suggesting that's a document we progress, but I think it = is important to ensure that the WG considers all the options, pros/cons and= applicability of each before we start working out the details. 

Mary.


On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmberg = <christer.holmberg@ericsson.com> wrote:

Hi,<= /p>

 

I am sure we’ll fin= d a home for the text – the important thing now is to agree on the me= chanism, and to get the text written.

 

Regards,

 

Christer

 

From: Mary Bar= nes [mailto:mary.ietf.barnes@gmail.com]
Sent: 30. tammikuuta 2014 16:13
To: Christian Groves
Cc: Christer Holmberg; Simon Pietro Romano; clue@ietf.org
Subject: Re: [clue] RTCWEB data channel for CLUE?

 

I think part of the debate here is whether any of th= e SCTP related stuff beyond what Simon has already noted is in the CLUE pro= tocol document would be in the CLUE protocol document.  I had envision= ed that as Simon noted, the CLUE protocol itself is designed to be independent of the transport.  We could add = a reference to a separate CLUE document that discusses the specifics of how= CLUE uses SCTP (and a note that other transports could also be used). &nbs= p;That latter document could reference the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide).  = ;  And, we already have that as a separate milestone. <= /u>

 

I think it's very important to decouple the prot= ocol from the transport.

 

Mary. 

 

 

 <= /p>

On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves &l= t;Christ= ian.Groves@nteczone.com> wrote:

Hello,

I think we need something in CLUE which says how it works with SCTP. There = will be things we still need to do like registering a media-subtype "C= LUE" (if that is still part of the SCTP SDP draft) etc. I assume that = wouldn't be done in RTCWEB.

Regards,
Christian



On 30/01/2014 7:42 PM, Christer Holmberg wrote:


Hi,

We need to make assumptions on whether the transport provides reliability a= nd in-order. When using “DTLS/SCTP/UDP”, those features are opt= ional, as far as I know.

Anyway, I am not saying that we haven’t made such assumptions already= – it was more a general comment when talking about the separation be= tween protocol and transport.

Regards,

Christer

*From:*Simon Pietro Romano [mailto:spromano@unina.it]
*Sent:* 30. tammikuuta 2014 10:36
*To:* Christer Holmberg
*Cc:* Mary Barnes; Christian Groves; clue@ietf.org
*Subject:* Re: [clue] RTCWEB data channel for CLUE?



Hi Christer,

    However, when we define the CLUE protocol state machine, we D= O
    need to make some assumptions about the transport, e.g. wheth= er it
    provides reliable transport, in-order transport etc. If not, = such
    mechanisms need to be implemented in the CLUE protocol itself=
    (similar to what is done in SIP with message re-transmission,=
    usage of CSeq etc).

The CLUE protocol draft currently states the following:

CLUE Participants are connected by means of the CLUE signaling
    channel.  Such channel has been conceived as a DTLS/SCTP= /UDP channel

    in [I-D.kyzivat-clue-signaling  &= lt;http://tools.ietf.org/html/dr= aft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is established as depicted in


    the same document.  CLUE protocol messages flow across s= uch channel.

We assume the
    DTLS/SCTP/UDP channel is established and define the behiavior= of the
    CLUE Participants communicating on it.  We discuss how t= he CLUE
    dialogue between them can be exploited to successfully setup = the
    telepresence session according to the principles and concepts= pointed

    out in in [I-D.ietf-clue-framework &nb= sp;<http://tools.ietf.org/html/d= raft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>].



Isn't this already enough? If not, what other assumptions do you think = we should make?

Thanks,

Simon

    But, I strongly think that we shall de= cide on **A** transport


    mechanism for the CLUE protocol. Otherwise we won’t eve= n guarantee
    interoperability between CLUE entities.

    Regards,

    Christer

    *From:*Simon Pietro Romano [mailto:spromano@unina.it]<= br>     *Sent:*30. tammikuuta 2014 10:14
    *To:*Christer Holmberg
    *Cc:*Mary Barnes; Christian Groves; clue@ietf.org
    <mailto:clue@ietf.org>
    *Subject:*Re: [clue] RTCWEB data channel for CLUE?<= /u>



    Hello folks,

    I might be perhaps too naif, but I have to admit I don't = see the
    point of discussion here. In my view, the CLUE protocol is     independent from the underlying transport means. One of the     potential transports (the best current option, IMHO) is the     RtcWeb/WebRTC data channel. I think we should keep on specify= ing
    CLUE protocol messages and state machines in the CLUE protoco= l
    document. We might then write a document illustrating how it = is
    possible to seamlessly implement such a protocol on top of th= e
    RtcWeb data channel. I am actually working on an individual     contribution which basically illustrates the above concepts, = by
    also providing a couple of call flows. I also believe that     Christer's proposal perfectly fits such an approach. Shou= ld the WG
    decide that this option is worth exploring, I would be glad t= o
    contribute.

    Cheers,

    Simon

    Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha s= critto:




    Hi,



            Could we use this for CLUE withou= t using the rtcweb data
            channel mechanism?

            If we want to have interoperabili= ty with rtcweb, we need
            to use the SCTP properties define= d in the rtcweb data
            channel draft.

            I have not heard, or identified m= yself, any reason why
            that would be a problem for CLUE.=

        [MB] I think the decision to be made by CLUE ne= eds to more
        importantly consider whether that approach work= s for CLUE
        without RTCWEB. We

        discussed on the call that the RTCWEB WG docume= nt (i.e.,
        draft-ietf-rtcweb-data-channel/) could be viewe= d as providing
        a more generic mechanism

        that can be used for applications beyond RTCWEB= .


    Yes. The rtcweb data channel is designed so that it works wit= h
    JavaScript applications. But, as I said on the call, there is=
    nothing JavaScript specific about. Not even all rtcweb
    applications will be JavaScript based.



    That all said, as an individual, I don't see it to be a t= remendous
    amount of work to write a clue-data-channel document that use= s
    identical

        mechanisms but has content specific to CLUE. Fo= r example, the
        generic aspects in the RTCWEB seem to be primar= ily limited to

        section 5 (just over 3 pages of text). Section = 4 has some
        generic aspects, but also some of it is RTCWEB = specific. And,
        section 3 is totally specific

        to RTCWEB. And, we need to decide how much of s= ection 6
        applies to CLUE.So, personally, I think CLUE co= uld just write
        their own document

        (and perhaps mention that procedures in section= blah are
        identical to those for RTCWEB OR write a genera= l document that
        both CLUE and

        RTCWEB can reference (although the doc would ha= ve more boiler
        plate than content. Or perhaps, section 5 could= be folded into the

        tsvwg document (although I haven't looked a= t that in detail to
        see if it would work). [/MB]


    We could for sure write our own document, eventhough much wou= ld be
    copy/paste from the rtcweb document.

    However, even if we write our own document, assuming we want<= br>     interoperability, we would STILL have a dependency on the rtc= web
    data channel, because that's where the SCTP PPID values a= re defined.

    I can try to put something together.

    Regards,

    Christer

    _\\|//_

    ( O-O )

    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
    Simon Pietro Romano

    Universita' di Napoli Federico II

    Computer Engineering Department

    Phone: +39 081 7683823 -- Fax: +39 081 7683816=

    e-mail:spromano@unina.it <mailto:spromano@unina.it>



    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi= degli

    idioti. Ci rifletto un istante; e mi scoraggio>>. Magri= tte.

    oooO

    ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
    \ ( ( )

    \_) ) /

    (_/




_\\|//_

( O-O )

~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

Simon Pietro Romano

Universita' di Napoli Federico II

Computer Engineering Department

Phone: +39 081 7683= 823 -- Fax: +39 081 7683816=

e-mail: spromano@unina.it <mailto:spromano@unina.it>



<<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli

idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.

oooO

~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

\ ( ( )

\_) ) /

(_/

 

 


--001a11c2cd4e1c9a9904f13253c1-- From pkyzivat@alum.mit.edu Thu Jan 30 08:21: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 9960F1A03FD for ; Thu, 30 Jan 2014 08:21: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 NlDdtBxx5Cli for ; Thu, 30 Jan 2014 08:21: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 248271A03F3 for ; Thu, 30 Jan 2014 08:21:04 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta15.westchester.pa.mail.comcast.net with comcast id LCjY1n0010SCNGk5FGM1zZ; Thu, 30 Jan 2014 16:21:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id LGM11n00B3ZTu2S3VGM1q7; Thu, 30 Jan 2014 16:21:01 +0000 Message-ID: <52EA7BED.4070007@alum.mit.edu> Date: Thu, 30 Jan 2014 11:21:01 -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: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14D5F3@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=1391098861; bh=NA7kih878sigX5eWFYQgqmM79RvHkcfBndc8aJVfj6E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=o2vfElJtRf/mkIP4m9rAH00F8M+nVeLEJ+FJmzVR38Bvw5Qta/h/WIcG7bo0AntrX ZkN6Nap8fMhDolaR97MBsj5rjgbMC9/GYzKXX/OB8RdKCHXU1jFT9dq7t51g1nbRh4 SYZM77sGDf9CBMTORoSESN02aKS3BhLeH5+NBud0MCDf02W1vj5ri7YLcg7CosqF4f AzpBluCEISl3O6yQieywc54GrhNScabhx8kra81dcn0vgF/9C2Zyioa+3VjDm7mhzH 6Fge32dRY2Kb3Pnvs9i/VVSPyosTNFLxn8+Vv2mn/ql7ycN7HoTa5biWYec0zT7Xqh RSe3a6tWkvkSg== Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 16:21:07 -0000 I agree with both Christer and Mary here. I think the *protocol* document should be independent of the specific transport. But it must make some requirements on the sort of transports it can work with. (Reliable, ordered, message oriented) But we need for some other document (e.g. signaling) to fill in the rest, so we have all the pieces necessary for successful interoperation by two implementations. This must, at least, specify how this will work when the session is negotiated via SIP and SDP O/A. And Christer is working on the latter. A couple of pieces of the puzzle are: - draft-ietf-mmusic-sctp-sdp - draft-ietf-tsvwg-sctp-dtls-encaps and the things they reference. But that only gives raw SCTP streams. If we were doing this work without regard to RTCWEB, we might stop there, and just specify how we choose SCTP streams for our purpose. But in order to give us a chance at interoperating with RTCWEB, we choose to also reuse draft-ietf-rtcweb-data-channel. This puts another layer of abstraction over SCTP, bonding pairs of unidirectional SCTP streams into bidirectional Data Channels, and making SCTP message attributes sticky for a channel. We wouldn't necessarily *need* that, but RTCWEB broswer apps won't be able to directly access the lower layers, so we need to follow that abstraction if we want to make it *possible* for an rtcweb browser app to directly access our clue protocol. I guess we *could* define clue directly on draft-ietf-rtcweb-data-channel, and simply be very careful to define it in a way that coincidentally is interoperable with how draft-ietf-rtcweb-data-channel uses SCTP. But IMO that is a dangerous approach - very difficult to maintain consistency. So I think it is better that we reference draft-ietf-rtcweb-data-channel. I agree that document has more rtcp-specifics than I would like. What are out options about that? 1) live with it 2) encourage the authors of that document to structure it so that the rtcweb specifics are clearly segregated from the more generic parts 3) work to factor that document into two separate documents, one generic and one rtcweb specific. From our perspective, (3) would probably be best. I don't know how feasible it is. We would probably need to volunteer to do it, though perhaps we could recruit Richard Ejzak. Doing this *right* would probably mean moving the generic document to another wg. (tsvwg?) I suspect that rtcweb might object on the grounds that this would unnecessarily delay them. In the interest of expediency, I can live with (2), or possibly even (1). Thanks, Paul On 1/30/14 9:18 AM, Christer Holmberg wrote: > Hi, > > I am sure well find a home for the text the important thing now is to > agree on the mechanism, and to get the text written. > > Regards, > > Christer > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* 30. tammikuuta 2014 16:13 > *To:* Christian Groves > *Cc:* Christer Holmberg; Simon Pietro Romano; clue@ietf.org > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > I think part of the debate here is whether any of the SCTP related stuff > beyond what Simon has already noted is in the CLUE protocol document > would be in the CLUE protocol document. I had envisioned that as Simon > noted, the CLUE protocol itself is designed to be independent of the > transport. We could add a reference to a separate CLUE document that > discusses the specifics of how CLUE uses SCTP (and a note that other > transports could also be used). That latter document could reference > the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide). > And, we already have that as a separate milestone. > > I think it's very important to decouple the protocol from the transport. > > Mary. > > On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves > > > wrote: > > Hello, > > I think we need something in CLUE which says how it works with SCTP. > There will be things we still need to do like registering a > media-subtype "CLUE" (if that is still part of the SCTP SDP draft) etc. > I assume that wouldn't be done in RTCWEB. > > Regards, > Christian > > > > On 30/01/2014 7:42 PM, Christer Holmberg wrote: > > > Hi, > > We need to make assumptions on whether the transport provides > reliability and in-order. When using DTLS/SCTP/UDP, those features > are optional, as far as I know. > > Anyway, I am not saying that we havent made such assumptions > already it was more a general comment when talking about the > separation between protocol and transport. > > Regards, > > Christer > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > ] > *Sent:* 30. tammikuuta 2014 10:36 > *To:* Christer Holmberg > *Cc:* Mary Barnes; Christian Groves; clue@ietf.org > > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > > > Hi Christer, > > However, when we define the CLUE protocol state machine, we DO > need to make some assumptions about the transport, e.g. whether it > provides reliable transport, in-order transport etc. If not, such > mechanisms need to be implemented in the CLUE protocol itself > (similar to what is done in SIP with message re-transmission, > usage of CSeq etc). > > The CLUE protocol draft currently states the following: > > CLUE Participants are connected by means of the CLUE signaling > channel. Such channel has been conceived as a DTLS/SCTP/UDP > channel > > in [I-D.kyzivat-clue-signaling > ] and it is established as depicted in > > > the same document. CLUE protocol messages flow across such > channel. > > We assume the > DTLS/SCTP/UDP channel is established and define the behiavior > of the > CLUE Participants communicating on it. We discuss how the CLUE > dialogue between them can be exploited to successfully setup the > telepresence session according to the principles and concepts > pointed > > out in in [I-D.ietf-clue-framework > ]. > > > > Isn't this already enough? If not, what other assumptions do you > think we should make? > > Thanks, > > Simon > > But, I strongly think that we shall decide on **A** transport > > > mechanism for the CLUE protocol. Otherwise we wont even guarantee > interoperability between CLUE entities. > > Regards, > > Christer > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > ] > *Sent:*30. tammikuuta 2014 10:14 > *To:*Christer Holmberg > *Cc:*Mary Barnes; Christian Groves; clue@ietf.org > > > > *Subject:*Re: [clue] RTCWEB data channel for CLUE? > > > > Hello folks, > > I might be perhaps too naif, but I have to admit I don't see the > point of discussion here. In my view, the CLUE protocol is > independent from the underlying transport means. One of the > potential transports (the best current option, IMHO) is the > RtcWeb/WebRTC data channel. I think we should keep on specifying > CLUE protocol messages and state machines in the CLUE protocol > document. We might then write a document illustrating how it is > possible to seamlessly implement such a protocol on top of the > RtcWeb data channel. I am actually working on an individual > contribution which basically illustrates the above concepts, by > also providing a couple of call flows. I also believe that > Christer's proposal perfectly fits such an approach. Should the WG > decide that this option is worth exploring, I would be glad to > contribute. > > Cheers, > > Simon > > Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha > scritto: > > > > > Hi, > > > > Could we use this for CLUE without using the rtcweb data > channel mechanism? > > If we want to have interoperability with rtcweb, we need > to use the SCTP properties defined in the rtcweb data > channel draft. > > I have not heard, or identified myself, any reason why > that would be a problem for CLUE. > > [MB] I think the decision to be made by CLUE needs to more > importantly consider whether that approach works for CLUE > without RTCWEB. We > > discussed on the call that the RTCWEB WG document (i.e., > draft-ietf-rtcweb-data-channel/) could be viewed as providing > a more generic mechanism > > that can be used for applications beyond RTCWEB. > > > Yes. The rtcweb data channel is designed so that it works with > JavaScript applications. But, as I said on the call, there is > nothing JavaScript specific about. Not even all rtcweb > applications will be JavaScript based. > > > > That all said, as an individual, I don't see it to be a tremendous > amount of work to write a clue-data-channel document that uses > identical > > mechanisms but has content specific to CLUE. For example, the > generic aspects in the RTCWEB seem to be primarily limited to > > section 5 (just over 3 pages of text). Section 4 has some > generic aspects, but also some of it is RTCWEB specific. And, > section 3 is totally specific > > to RTCWEB. And, we need to decide how much of section 6 > applies to CLUE.So, personally, I think CLUE could just write > their own document > > (and perhaps mention that procedures in section blah are > identical to those for RTCWEB OR write a general document that > both CLUE and > > RTCWEB can reference (although the doc would have more boiler > plate than content. Or perhaps, section 5 could be folded > into the > > tsvwg document (although I haven't looked at that in detail to > see if it would work). [/MB] > > > We could for sure write our own document, eventhough much would be > copy/paste from the rtcweb document. > > However, even if we write our own document, assuming we want > interoperability, we would STILL have a dependency on the rtcweb > data channel, because that's where the SCTP PPID values are > defined. > > I can try to put something together. > > Regards, > > Christer > > _\\|//_ > > ( O-O ) > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > Simon Pietro Romano > > Universita' di Napoli Federico II > > Computer Engineering Department > > Phone: +39 081 7683823 -- Fax: +39 > 081 7683816 > > e-mail:spromano@unina.it > > > > > > < > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > oooO > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > > \_) ) / > > (_/ > > > > > _\\|//_ > > ( O-O ) > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > Simon Pietro Romano > > Universita' di Napoli Federico II > > Computer Engineering Department > > Phone: +39 081 7683823 -- Fax: +39 081 > 7683816 > > e-mail: spromano@unina.it > > > > > > < > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > oooO > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > > \_) ) / > > (_/ > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Thu Jan 30 08:24: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 1CABF1A0419 for ; Thu, 30 Jan 2014 08:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, 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 VXO2ew_KnRCU for ; Thu, 30 Jan 2014 08:24:16 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id EC8B91A03FE for ; Thu, 30 Jan 2014 08:24:14 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-da-52ea7caaf4d6 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id F1.42.04249.AAC7AE25; Thu, 30 Jan 2014 17:24:11 +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, 30 Jan 2014 17:24:10 +0100 From: Christer Holmberg To: Mary Barnes Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AASGoAAABEq/QAAAWrOgAAGa6TgAAm/AoAAIlJjgP///J6A///sArCAABouAP//7jGwgAAmwwCAAEk/gP//7g9wAAZnk4AAAoCTUg== Date: Thu, 30 Jan 2014 16:24:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D14DEC6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se>, 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_7594FB04B1934943A5C02806D1A2204B1D14DEC6ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvje7qmldBBkfWMll8ed/IYrH/1GVm i8/79zNbbGu7wezA4rFz1l12jyVLfjJ5rDg/k8Xjx5anTAEsUVw2Kak5mWWpRfp2CVwZ1yac YipY08VU0bv3HXMD45p7jF2MnBwSAiYSm9c+YIOwxSQu3FsPZHNxCAkcYZT4tGYvI4SzmFHi 9v8eli5GDg42AQuJ7n/aIA0iAjoS3z6/BWtgFmhglJg0exkLSEJYwFDi95ZjzBBFRhK7P69i BikSEZjEKLH75kuwdSwCqhLbH60HK+IV8JW4fOw/C8S2BnaJLzuWsYJs4xQIlLi7yw+khhHo vO+n1jCB2MwC4hK3nsxngjhbQGLJnvPMELaoxMvH/1ghavIlbq1eyQIxX1Di5MwnLBMYRWYh aZ+FpGwWkjKIuIHEl/e3oWxtiWULXzND2PoS3e9PMyGLL2BkX8XIUZxanJSbbmSwiREYbQe3 /LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MHK+0b42y3Z6 96Mv5b88wy8u3ZBou3+3/93ydJ2qU9GqF940HF7SxHNL7ovMipP35ITXzMu64zrXxlz2/dPb HAu/nDbIjfb6uzHYTffg8cBVrb0TUzLcrybn97bqHTz41pXR5RGrv9L/gMTT6eFnYn8JxR1d JvSg87JejUiC30ytyO0nvi9kKVRiKc5INNRiLipOBACbxsF1hAIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 16:24:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D14DEC6ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, As far as I know, the only alternatives we have identified are: 1. Whether or not to use the rtcweb data channel PROTOCOL 2. Whether or not to use Richard=92s draft Nobody has presented an alternative to the usage of the SCTP capabilities (= PPID values, reliability, etc) defined the rtcweb data channel draft (wheth= er we will use that draft as is, or write parts in our own document, is an = editorial issue). Regards, Christer Sent from Windows Mail From: Mary Barnes Sent: =FDThursday=FD, =FDJanuary=FD =FD30=FD, =FD2014 =FD6=FD:=FD12=FD =FDP= M To: Hans-Christer Holmberg Cc: Christian Groves, Simon Pietro Ro= mano, clue@ietf.org Sure. But, it's very important to keep in mind what we are talking about wh= en referring to other documents. I'm thinking the best way forward would be to put together a document that = list and evaluates all the alternatives versus diving in with the assumptio= n that we'll use the RTCWEB mechanism. Just to be clear, I'm not suggesti= ng that's a document we progress, but I think it is important to ensure tha= t the WG considers all the options, pros/cons and applicability of each bef= ore we start working out the details. Mary. On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmberg > wrote: Hi, I am sure we=92ll find a home for the text =96 the important thing now is t= o agree on the mechanism, and to get the text written. Regards, Christer From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 30. tammikuuta 2014 16:13 To: Christian Groves Cc: Christer Holmberg; Simon Pietro Romano; clue@ietf.org Subject: Re: [clue] RTCWEB data channel for CLUE? I think part of the debate here is whether any of the SCTP related stuff be= yond what Simon has already noted is in the CLUE protocol document would be= in the CLUE protocol document. I had envisioned that as Simon noted, the = CLUE protocol itself is designed to be independent of the transport. We co= uld add a reference to a separate CLUE document that discusses the specific= s of how CLUE uses SCTP (and a note that other transports could also be use= d). That latter document could reference the RTCWEB and TSVWG documents (o= r MMUSIC if that's what we decide). And, we already have that as a separ= ate milestone. I think it's very important to decouple the protocol from the transport. Mary. On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves > wrote: Hello, I think we need something in CLUE which says how it works with SCTP. There = will be things we still need to do like registering a media-subtype "CLUE" = (if that is still part of the SCTP SDP draft) etc. I assume that wouldn't b= e done in RTCWEB. Regards, Christian On 30/01/2014 7:42 PM, Christer Holmberg wrote: Hi, We need to make assumptions on whether the transport provides reliability a= nd in-order. When using =93DTLS/SCTP/UDP=94, those features are optional, a= s far as I know. Anyway, I am not saying that we haven=92t made such assumptions already =96= it was more a general comment when talking about the separation between pr= otocol and transport. Regards, Christer *From:*Simon Pietro Romano [mailto:spromano@unina.it] *Sent:* 30. tammikuuta 2014 10:36 *To:* Christer Holmberg *Cc:* Mary Barnes; Christian Groves; clue@ietf.org *Subject:* Re: [clue] RTCWEB data channel for CLUE? Hi Christer, However, when we define the CLUE protocol state machine, we DO need to make some assumptions about the transport, e.g. whether it provides reliable transport, in-order transport etc. If not, such mechanisms need to be implemented in the CLUE protocol itself (similar to what is done in SIP with message re-transmission, usage of CSeq etc). The CLUE protocol draft currently states the following: CLUE Participants are connected by means of the CLUE signaling channel. Such channel has been conceived as a DTLS/SCTP/UDP channel in [I-D.kyzivat-clue-signaling ] and it is established a= s depicted in the same document. CLUE protocol messages flow across such channel. We assume the DTLS/SCTP/UDP channel is established and define the behiavior of the CLUE Participants communicating on it. We discuss how the CLUE dialogue between them can be exploited to successfully setup the telepresence session according to the principles and concepts pointed out in in [I-D.ietf-clue-framework ]. Isn't this already enough? If not, what other assumptions do you think we s= hould make? Thanks, Simon But, I strongly think that we shall decide on **A** transport mechanism for the CLUE protocol. Otherwise we won=92t even guarantee interoperability between CLUE entities. Regards, Christer *From:*Simon Pietro Romano [mailto:spromano@unina.it] *Sent:*30. tammikuuta 2014 10:14 *To:*Christer Holmberg *Cc:*Mary Barnes; Christian Groves; clue@ietf.org > *Subject:*Re: [clue] RTCWEB data channel for CLUE? Hello folks, I might be perhaps too naif, but I have to admit I don't see the point of discussion here. In my view, the CLUE protocol is independent from the underlying transport means. One of the potential transports (the best current option, IMHO) is the RtcWeb/WebRTC data channel. I think we should keep on specifying CLUE protocol messages and state machines in the CLUE protocol document. We might then write a document illustrating how it is possible to seamlessly implement such a protocol on top of the RtcWeb data channel. I am actually working on an individual contribution which basically illustrates the above concepts, by also providing a couple of call flows. I also believe that Christer's proposal perfectly fits such an approach. Should the WG decide that this option is worth exploring, I would be glad to contribute. Cheers, Simon Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha scritto: Hi, Could we use this for CLUE without using the rtcweb data channel mechanism? If we want to have interoperability with rtcweb, we need to use the SCTP properties defined in the rtcweb data channel draft. I have not heard, or identified myself, any reason why that would be a problem for CLUE. [MB] I think the decision to be made by CLUE needs to more importantly consider whether that approach works for CLUE without RTCWEB. We discussed on the call that the RTCWEB WG document (i.e., draft-ietf-rtcweb-data-channel/) could be viewed as providing a more generic mechanism that can be used for applications beyond RTCWEB. Yes. The rtcweb data channel is designed so that it works with JavaScript applications. But, as I said on the call, there is nothing JavaScript specific about. Not even all rtcweb applications will be JavaScript based. That all said, as an individual, I don't see it to be a tremendous amount of work to write a clue-data-channel document that uses identical mechanisms but has content specific to CLUE. For example, the generic aspects in the RTCWEB seem to be primarily limited to section 5 (just over 3 pages of text). Section 4 has some generic aspects, but also some of it is RTCWEB specific. And, section 3 is totally specific to RTCWEB. And, we need to decide how much of section 6 applies to CLUE.So, personally, I think CLUE could just write their own document (and perhaps mention that procedures in section blah are identical to those for RTCWEB OR write a general document that both CLUE and RTCWEB can reference (although the doc would have more boiler plate than content. Or perhaps, section 5 could be folded into the tsvwg document (although I haven't looked at that in detail to see if it would work). [/MB] We could for sure write our own document, eventhough much would be copy/paste from the rtcweb document. However, even if we write our own document, assuming we want interoperability, we would STILL have a dependency on the rtcweb data channel, because that's where the SCTP PPID values are defined. I can try to put something together. Regards, Christer _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 76838= 16 e-mail:spromano@unina.it > <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it > <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --_000_7594FB04B1934943A5C02806D1A2204B1D14DEC6ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

As far as I know, the only alternatives we have identified are:

  1. Whether or not to use the rtcweb data channel PROTOCOL
  2. Whether or not to use Richard=92s draft

Nobody has presented an alternative to the usage of the SCTP capabilities (= PPID values, reliability, etc) defined the rtcweb data channel draft (wheth= er we will use that draft as is, or write parts in our own document, is an = editorial issue).

Regards,

Christer

Sent from Windows Mail

From: Mary Barnes
Sent: =FDThursday=FD, =FDJanuary=FD =FD30=FD, =FD2014 =FD6=FD:= =FD12=FD =FDPM
To: Hans-Christer Holmberg
Cc: Christian Groves, Simon Pietro Romano= , clue@ietf.org

Sure. But, it's very important to keep in mind what we are= talking about when referring to other documents.  

I'm thinking the best way forward would be to put together a document = that list and evaluates all the alternatives versus diving in with the assu= mption that we'll use the RTCWEB mechanism.   Just to be clear, I'm no= t suggesting that's a document we progress, but I think it is important to ensure that the WG considers all the option= s, pros/cons and applicability of each before we start working out the deta= ils. 

Mary.


On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmbe= rg <ch= rister.holmberg@ericsson.com> wrote:

Hi,

 = ;

I am sure we= =92ll find a home for the text =96 the important thing now is to agree on t= he mechanism, and to get the text written.

 = ;

Regards,<= /u>

 = ;

Christer<= /u>

 = ;

From: Mary= Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 30. tammikuuta 2014 16:13
To: Christian Groves
Cc: Christer Holmberg; Simon Pietro Romano; clue@ietf.org
Subject: Re: [clue] RTCWEB data channel for CLUE?

 

I think part of the debate here is whether any of th= e SCTP related stuff beyond what Simon has already noted is in the CLUE pro= tocol document would be in the CLUE protocol document.  I had envision= ed that as Simon noted, the CLUE protocol itself is designed to be independent of the transport.  We could add = a reference to a separate CLUE document that discusses the specifics of how= CLUE uses SCTP (and a note that other transports could also be used). &nbs= p;That latter document could reference the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide).   &n= bsp;And, we already have that as a separate milestone. <= /p>

 

I think it's very important to decouple the protocol= from the transport.

 

Mary. 

 

 

 <= /p>

On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves &l= t;Chris= tian.Groves@nteczone.com> wrote:

Hello,

I think we need something in CLUE which says how it works with SCTP. There = will be things we still need to do like registering a media-subtype "C= LUE" (if that is still part of the SCTP SDP draft) etc. I assume that = wouldn't be done in RTCWEB.

Regards,
Christian



On 30/01/2014 7:42 PM, Christer Holmberg wrote:


Hi,

We need to make assumptions on whether the transport provides reliability a= nd in-order. When using =93DTLS/SCTP/UDP=94, those features are optional, a= s far as I know.

Anyway, I am not saying that we haven=92t made such assumptions already =96= it was more a general comment when talking about the separation between pr= otocol and transport.

Regards,

Christer

*From:*Simon Pietro Romano [mailto:spromano@unina.it]
*Sent:* 30. tammikuuta 2014 10:36
*To:* Christer Holmberg
*Cc:* Mary Barnes; Christian Groves; clue@ietf.org
*Subject:* Re: [clue] RTCWEB data channel for CLUE?



Hi Christer,

    However, when we define the CLUE protocol state machine, we D= O
    need to make some assumptions about the transport, e.g. wheth= er it
    provides reliable transport, in-order transport etc. If not, = such
    mechanisms need to be implemented in the CLUE protocol itself=
    (similar to what is done in SIP with message re-transmission,=
    usage of CSeq etc).

The CLUE protocol draft currently states the following:

CLUE Participants are connected by means of the CLUE signaling
    channel.  Such channel has been conceived as a DTLS/SCTP= /UDP channel

    in [I-D.kyzivat-clue-signaling  &= lt;http://tools.ietf.org/html/d= raft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is established as depicted in


    the same document.  CLUE protocol messages flow across s= uch channel.

We assume the
    DTLS/SCTP/UDP channel is established and define the behiavior= of the
    CLUE Participants communicating on it.  We discuss how t= he CLUE
    dialogue between them can be exploited to successfully setup = the
    telepresence session according to the principles and concepts= pointed

    out in in [I-D.ietf-clue-framework &nb= sp;<http://tools.ietf.org/html/= draft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>].<= u>



Isn't this already enough? If not, what other assumptions do you think we s= hould make?

Thanks,

Simon

    But, I strongly think that we shall de= cide on **A** transport


    mechanism for the CLUE protocol. Otherwise we won=92t even gu= arantee
    interoperability between CLUE entities.

    Regards,

    Christer

    *From:*Simon Pietro Romano [mailto:spromano@unina.it]=
    *Sent:*30. tammikuuta 2014 10:14
    *To:*Christer Holmberg
    *Cc:*Mary Barnes; Christian Groves; clue@ietf.org
    <mailto:clue@ietf.org>
    *Subject:*Re: [clue] RTCWEB data channel for CLUE?<= /u>



    Hello folks,

    I might be perhaps too naif, but I have to admit I don't see = the
    point of discussion here. In my view, the CLUE protocol is     independent from the underlying transport means. One of the     potential transports (the best current option, IMHO) is the     RtcWeb/WebRTC data channel. I think we should keep on specify= ing
    CLUE protocol messages and state machines in the CLUE protoco= l
    document. We might then write a document illustrating how it = is
    possible to seamlessly implement such a protocol on top of th= e
    RtcWeb data channel. I am actually working on an individual     contribution which basically illustrates the above concepts, = by
    also providing a couple of call flows. I also believe that     Christer's proposal perfectly fits such an approach. Should t= he WG
    decide that this option is worth exploring, I would be glad t= o
    contribute.

    Cheers,

    Simon

    Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha s= critto:




    Hi,



            Could we use this for CLUE withou= t using the rtcweb data
            channel mechanism?

            If we want to have interoperabili= ty with rtcweb, we need
            to use the SCTP properties define= d in the rtcweb data
            channel draft.

            I have not heard, or identified m= yself, any reason why
            that would be a problem for CLUE.=

        [MB] I think the decision to be made by CLUE ne= eds to more
        importantly consider whether that approach work= s for CLUE
        without RTCWEB. We

        discussed on the call that the RTCWEB WG docume= nt (i.e.,
        draft-ietf-rtcweb-data-channel/) could be viewe= d as providing
        a more generic mechanism

        that can be used for applications beyond RTCWEB= .


    Yes. The rtcweb data channel is designed so that it works wit= h
    JavaScript applications. But, as I said on the call, there is=
    nothing JavaScript specific about. Not even all rtcweb
    applications will be JavaScript based.



    That all said, as an individual, I don't see it to be a treme= ndous
    amount of work to write a clue-data-channel document that use= s
    identical

        mechanisms but has content specific to CLUE. Fo= r example, the
        generic aspects in the RTCWEB seem to be primar= ily limited to

        section 5 (just over 3 pages of text). Section = 4 has some
        generic aspects, but also some of it is RTCWEB = specific. And,
        section 3 is totally specific

        to RTCWEB. And, we need to decide how much of s= ection 6
        applies to CLUE.So, personally, I think CLUE co= uld just write
        their own document

        (and perhaps mention that procedures in section= blah are
        identical to those for RTCWEB OR write a genera= l document that
        both CLUE and

        RTCWEB can reference (although the doc would ha= ve more boiler
        plate than content. Or perhaps, section 5 could= be folded into the

        tsvwg document (although I haven't looked at th= at in detail to
        see if it would work). [/MB]


    We could for sure write our own document, eventhough much wou= ld be
    copy/paste from the rtcweb document.

    However, even if we write our own document, assuming we want<= br>     interoperability, we would STILL have a dependency on the rtc= web
    data channel, because that's where the SCTP PPID values are d= efined.

    I can try to put something together.

    Regards,

    Christer

    _\\|//_

    ( O-O )

    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
    Simon Pietro Romano

    Universita' di Napoli Federico II

    Computer Engineering Department

    Phone: +39 081 7683823 -- Fax: +39 081 768381= 6

    e-mail:spromano@unina.it <mailto:spromano@unina.it>



    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi deg= li

    idioti. Ci rifletto un istante; e mi scoraggio>>. Magri= tte.

    oooO

    ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
    \ ( ( )

    \_) ) /

    (_/




_\\|//_

( O-O )

~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

Simon Pietro Romano

Universita' di Napoli Federico II

Computer Engineering Department

Phone: +39 081= 7683823 -- Fax: +39 081 768381= 6

e-mail: spromano@unina.it <mailto:spromano@unina.it>



<<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli

idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.

oooO

~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

\ ( ( )

\_) ) /

(_/

 

 


--_000_7594FB04B1934943A5C02806D1A2204B1D14DEC6ESESSMB209erics_-- From christer.holmberg@ericsson.com Thu Jan 30 08:30: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 014B61A03F4 for ; Thu, 30 Jan 2014 08:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, 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 vfb3o47v_bIW for ; Thu, 30 Jan 2014 08:30:27 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 00C9C1A03D4 for ; Thu, 30 Jan 2014 08:30:25 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-0d-52ea7e1d24db Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 04.B2.04249.D1E7AE25; Thu, 30 Jan 2014 17:30:22 +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, 30 Jan 2014 17:30:21 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AASGoAAABEq/QAAAWrOgAAGa6TgAAm/AoAAIlJjgP///J6A///sArCAABouAP//7jGwgAAmwwCAAEk/gP//7g9wAAazkoAAAmvn8g== Date: Thu, 30 Jan 2014 16:30:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D14DF4E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se>, <52EA7BED.4070007@alum.mit.edu> In-Reply-To: <52EA7BED.4070007@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D14DF4EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvja5c3asgg0mHeSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj2ONPjAWL9zBVfLv9mq2B8VIbUxcjJ4eE gInEr8tv2CFsMYkL99azdTFycQgJHGGUeLLrBQuEs5hR4u6yacxdjBwcbAIWEt3/tEEaRAQ8 JXZ8nMIMYgsLGEr83nKMGSJuJLH78ypmkF4RgUmMEovevgJLsAioStz/ew9sM6+Ar8SJ6fuZ IBbcZpN4efgxG0iCU0BH4unGxWBFjEAnfT+1BsxmFhCXuPVkPtTZAhJL9pxnhrBFJV4+/scK UZMvcevSA3aIBYISJ2c+YZnAKDwLSfssJGWzkJRBxA0kvry/DWVrSyxb+JoZwtaX6H5/mglZ fAEj+ypGjuLU4qTcdCODTYzAaDm45bfFDsbLf20OMUpzsCiJ83586xwkJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgdFHe+ujqUdF5kzNT70x/Vnd2rxAo0PiIqaF50o5T/ofSJtw/0Kgb9rE o/MUK1g+1T2d8L6kiiPNaNW1/3uaSpf9PX1ebZYxd0VZRcGFlw9bfitMu7so13pW36f52can 12meusnmbVs//0G6iZzMy29nn96sEdrAkPr2ccCVvEDXlQpa+prnt/1QYinOSDTUYi4qTgQA y8gz32QCAAA= Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 16:30:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D14DF4EESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Paul, The =93layer=94 that the RTCWEB data channel adds are basically SCTP charac= teristics - things that we would have to define ANYWAY. So, the question is whether we are ok with the SCTP characteristics, or whe= ther we would need different ones. I have not seen any such indication. The question is whether we see a need for the rtcweb data channel PROTOCOL = or not. It has been confirmed that the usage is OPTIONAL, so it=92s up to u= s to determine whether we need it or not. Regards, Christer Sent from Windows Mail From: Paul Kyzivat Sent: =FDThursday=FD, =FDJanuary=FD =FD30=FD, =FD2014 =FD6=FD:=FD21=FD =FDP= M To: clue@ietf.org I agree with both Christer and Mary here. I think the *protocol* document should be independent of the specific transport. But it must make some requirements on the sort of transports it can work with. (Reliable, ordered, message oriented) But we need for some other document (e.g. signaling) to fill in the rest, so we have all the pieces necessary for successful interoperation by two implementations. This must, at least, specify how this will work when the session is negotiated via SIP and SDP O/A. And Christer is working on the latter. A couple of pieces of the puzzle are: - draft-ietf-mmusic-sctp-sdp - draft-ietf-tsvwg-sctp-dtls-encaps and the things they reference. But that only gives raw SCTP streams. If we were doing this work without regard to RTCWEB, we might stop there, and just specify how we choose SCTP streams for our purpose. But in order to give us a chance at interoperating with RTCWEB, we choose to also reuse draft-ietf-rtcweb-data-channel. This puts another layer of abstraction over SCTP, bonding pairs of unidirectional SCTP streams into bidirectional Data Channels, and making SCTP message attributes sticky for a channel. We wouldn't necessarily *need* that, but RTCWEB broswer apps won't be able to directly access the lower layers, so we need to follow that abstraction if we want to make it *possible* for an rtcweb browser app to directly access our clue protocol. I guess we *could* define clue directly on draft-ietf-rtcweb-data-channel, and simply be very careful to define it in a way that coincidentally is interoperable with how draft-ietf-rtcweb-data-channel uses SCTP. But IMO that is a dangerous approach - very difficult to maintain consistency. So I think it is better that we reference draft-ietf-rtcweb-data-channel. I agree that document has more rtcp-specifics than I would like. What are out options about that? 1) live with it 2) encourage the authors of that document to structure it so that the rtcweb specifics are clearly segregated from the more generic parts 3) work to factor that document into two separate documents, one generic and one rtcweb specific. From our perspective, (3) would probably be best. I don't know how feasible it is. We would probably need to volunteer to do it, though perhaps we could recruit Richard Ejzak. Doing this *right* would probably mean moving the generic document to another wg. (tsvwg?) I suspect that rtcweb might object on the grounds that this would unnecessarily delay them. In the interest of expediency, I can live with (2), or possibly even (1). Thanks, Paul On 1/30/14 9:18 AM, Christer Holmberg wrote: > Hi, > > I am sure we=92ll find a home for the text =96 the important thing now is= to > agree on the mechanism, and to get the text written. > > Regards, > > Christer > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* 30. tammikuuta 2014 16:13 > *To:* Christian Groves > *Cc:* Christer Holmberg; Simon Pietro Romano; clue@ietf.org > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > I think part of the debate here is whether any of the SCTP related stuff > beyond what Simon has already noted is in the CLUE protocol document > would be in the CLUE protocol document. I had envisioned that as Simon > noted, the CLUE protocol itself is designed to be independent of the > transport. We could add a reference to a separate CLUE document that > discusses the specifics of how CLUE uses SCTP (and a note that other > transports could also be used). That latter document could reference > the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide). > And, we already have that as a separate milestone. > > I think it's very important to decouple the protocol from the transport. > > Mary. > > On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves > > > wrote: > > Hello, > > I think we need something in CLUE which says how it works with SCTP. > There will be things we still need to do like registering a > media-subtype "CLUE" (if that is still part of the SCTP SDP draft) etc. > I assume that wouldn't be done in RTCWEB. > > Regards, > Christian > > > > On 30/01/2014 7:42 PM, Christer Holmberg wrote: > > > Hi, > > We need to make assumptions on whether the transport provides > reliability and in-order. When using =93DTLS/SCTP/UDP=94, those featu= res > are optional, as far as I know. > > Anyway, I am not saying that we haven=92t made such assumptions > already =96 it was more a general comment when talking about the > separation between protocol and transport. > > Regards, > > Christer > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > ] > *Sent:* 30. tammikuuta 2014 10:36 > *To:* Christer Holmberg > *Cc:* Mary Barnes; Christian Groves; clue@ietf.org > > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > > > Hi Christer, > > However, when we define the CLUE protocol state machine, we DO > need to make some assumptions about the transport, e.g. whether = it > provides reliable transport, in-order transport etc. If not, suc= h > mechanisms need to be implemented in the CLUE protocol itself > (similar to what is done in SIP with message re-transmission, > usage of CSeq etc). > > The CLUE protocol draft currently states the following: > > CLUE Participants are connected by means of the CLUE signaling > channel. Such channel has been conceived as a DTLS/SCTP/UDP > channel > > in [I-D.kyzivat-clue-signaling > ] and it is established as depicted in > > > the same document. CLUE protocol messages flow across such > channel. > > We assume the > DTLS/SCTP/UDP channel is established and define the behiavior > of the > CLUE Participants communicating on it. We discuss how the CLUE > dialogue between them can be exploited to successfully setup the > telepresence session according to the principles and concepts > pointed > > out in in [I-D.ietf-clue-framework > ]. > > > > Isn't this already enough? If not, what other assumptions do you > think we should make? > > Thanks, > > Simon > > But, I strongly think that we shall decide on **A** transport > > > mechanism for the CLUE protocol. Otherwise we won=92t even guara= ntee > interoperability between CLUE entities. > > Regards, > > Christer > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > ] > *Sent:*30. tammikuuta 2014 10:14 > *To:*Christer Holmberg > *Cc:*Mary Barnes; Christian Groves; clue@ietf.org > > > > *Subject:*Re: [clue] RTCWEB data channel for CLUE? > > > > Hello folks, > > I might be perhaps too naif, but I have to admit I don't see the > point of discussion here. In my view, the CLUE protocol is > independent from the underlying transport means. One of the > potential transports (the best current option, IMHO) is the > RtcWeb/WebRTC data channel. I think we should keep on specifying > CLUE protocol messages and state machines in the CLUE protocol > document. We might then write a document illustrating how it is > possible to seamlessly implement such a protocol on top of the > RtcWeb data channel. I am actually working on an individual > contribution which basically illustrates the above concepts, by > also providing a couple of call flows. I also believe that > Christer's proposal perfectly fits such an approach. Should the = WG > decide that this option is worth exploring, I would be glad to > contribute. > > Cheers, > > Simon > > Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha > scritto: > > > > > Hi, > > > > Could we use this for CLUE without using the rtcweb data > channel mechanism? > > If we want to have interoperability with rtcweb, we need > to use the SCTP properties defined in the rtcweb data > channel draft. > > I have not heard, or identified myself, any reason why > that would be a problem for CLUE. > > [MB] I think the decision to be made by CLUE needs to more > importantly consider whether that approach works for CLUE > without RTCWEB. We > > discussed on the call that the RTCWEB WG document (i.e., > draft-ietf-rtcweb-data-channel/) could be viewed as providin= g > a more generic mechanism > > that can be used for applications beyond RTCWEB. > > > Yes. The rtcweb data channel is designed so that it works with > JavaScript applications. But, as I said on the call, there is > nothing JavaScript specific about. Not even all rtcweb > applications will be JavaScript based. > > > > That all said, as an individual, I don't see it to be a tremendo= us > amount of work to write a clue-data-channel document that uses > identical > > mechanisms but has content specific to CLUE. For example, th= e > generic aspects in the RTCWEB seem to be primarily limited t= o > > section 5 (just over 3 pages of text). Section 4 has some > generic aspects, but also some of it is RTCWEB specific. And= , > section 3 is totally specific > > to RTCWEB. And, we need to decide how much of section 6 > applies to CLUE.So, personally, I think CLUE could just writ= e > their own document > > (and perhaps mention that procedures in section blah are > identical to those for RTCWEB OR write a general document th= at > both CLUE and > > RTCWEB can reference (although the doc would have more boile= r > plate than content. Or perhaps, section 5 could be folded > into the > > tsvwg document (although I haven't looked at that in detail = to > see if it would work). [/MB] > > > We could for sure write our own document, eventhough much would = be > copy/paste from the rtcweb document. > > However, even if we write our own document, assuming we want > interoperability, we would STILL have a dependency on the rtcweb > data channel, because that's where the SCTP PPID values are > defined. > > I can try to put something together. > > Regards, > > Christer > > _\\|//_ > > ( O-O ) > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > Simon Pietro Romano > > Universita' di Napoli Federico II > > Computer Engineering Department > > Phone: +39 081 7683823 -- Fax: +39 > 081 7683816 > > e-mail:spromano@unina.it > > > > > > < > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > oooO > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > > \_) ) / > > (_/ > > > > > _\\|//_ > > ( O-O ) > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > Simon Pietro Romano > > Universita' di Napoli Federico II > > Computer Engineering Department > > Phone: +39 081 7683823 -- Fax: +39 081 > 7683816 > > e-mail: spromano@unina.it > > > > > > < > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > oooO > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > > \_) ) / > > (_/ > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7594FB04B1934943A5C02806D1A2204B1D14DF4EESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Paul,

The =93layer=94 that the RTCWEB data channel adds are basically S= CTP characteristics  - things that we would have to define ANYWAY.

So, the question is whether we are ok with the SCTP characteristics, o= r whether we would need different ones. I have not seen any such indication= .

The question is whether we see a need for the rtcweb data channel PROT= OCOL or not. It has been confirmed that the usage is OPTIONAL, so it=92s up= to us to determine whether we need it or not.

Regards,

Christer

Sent from Windows Mail

From: Paul Kyzivat
Sent: =FDThursday=FD, =FDJanuary=FD =FD30=FD, =FD2014 =FD6=FD:= =FD21=FD =FDPM
To: clue@ie= tf.org

I agree with both Christer and Mary here= .

I think the *protocol* document should be independent of the specific
transport. But it must make some requirements on the sort of transports it can work with. (Reliable, ordered, message oriented)

But we need for some other document (e.g. signaling) to fill in the
rest, so we have all the pieces necessary for successful interoperation by two implementations. This must, at least, specify how this will work when the session is negotiated via SIP and SDP O/A.

And Christer is working on the latter.

A couple of pieces of the puzzle are:
- draft-ietf-mmusic-sctp-sdp
- draft-ietf-tsvwg-sctp-dtls-encaps

and the things they reference. But that only gives raw SCTP streams.

If we were doing this work without regard to RTCWEB, we might stop
there, and just specify how we choose SCTP streams for our purpose.

But in order to give us a chance at interoperating with RTCWEB, we
choose to also reuse draft-ietf-rtcweb-data-channel. This puts another
layer of abstraction over SCTP, bonding pairs of unidirectional SCTP
streams into bidirectional Data Channels, and making SCTP message
attributes sticky for a channel.

We wouldn't necessarily *need* that, but RTCWEB broswer apps won't be
able to directly access the lower layers, so we need to follow that
abstraction if we want to make it *possible* for an rtcweb browser app
to directly access our clue protocol.

I guess we *could* define clue directly on
draft-ietf-rtcweb-data-channel, and simply be very careful to define it in a way that coincidentally is interoperable with how
draft-ietf-rtcweb-data-channel uses SCTP. But IMO that is a dangerous
approach - very difficult to maintain consistency.

So I think it is better that we reference draft-ietf-rtcweb-data-channel.
I agree that document has more rtcp-specifics than I would like. What
are out options about that?
1) live with it
2) encourage the authors of that document to structure it so that
    the rtcweb specifics are clearly segregated from the mor= e generic
    parts
3) work to factor that document into two separate documents,
    one generic and one rtcweb specific.

 From our perspective, (3) would probably be best. I don't know how feasible it is. We would probably need to volunteer to do it, though
perhaps we could recruit Richard Ejzak.

Doing this *right* would probably mean moving the generic document to
another wg. (tsvwg?) I suspect that rtcweb might object on the grounds
that this would unnecessarily delay them.

In the interest of expediency, I can live with (2), or possibly even (1).
 Thanks,
 Paul

On 1/30/14 9:18 AM, Christer Holmberg wrote:
> Hi,
>
> I am sure we=92ll find a home for the text =96 the important thing now= is to
> agree on the mechanism, and to get the text written.
>
> Regards,
>
> Christer
>
> *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> *Sent:* 30. tammikuuta 2014 16:13
> *To:* Christian Groves
> *Cc:* Christer Holmberg; Simon Pietro Romano; clue@ietf.org
> *Subject:* Re: [clue] RTCWEB data channel for CLUE?
>
> I think part of the debate here is whether any of the SCTP related stu= ff
> beyond what Simon has already noted is in the CLUE protocol document > would be in the CLUE protocol document.  I had envisioned that as= Simon
> noted, the CLUE protocol itself is designed to be independent of the > transport.  We could add a reference to a separate CLUE document = that
> discusses the specifics of how CLUE uses SCTP (and a note that other > transports could also be used).  That latter document could refer= ence
> the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide). >   And, we already have that as a separate milestone.
>
> I think it's very important to decouple the protocol from the transpor= t.
>
> Mary.
>
> On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves
> <Christian.Groves@nteczone.com <mailto:Christian.Groves@nteczone= .com>>
> wrote:
>
> Hello,
>
> I think we need something in CLUE which says how it works with SCTP. > There will be things we still need to do like registering a
> media-subtype "CLUE" (if that is still part of the SCTP SDP = draft) etc.
> I assume that wouldn't be done in RTCWEB.
>
> Regards,
> Christian
>
>
>
> On 30/01/2014 7:42 PM, Christer Holmberg wrote:
>
>
>     Hi,
>
>     We need to make assumptions on whether the tra= nsport provides
>     reliability and in-order. When using =93DTLS/S= CTP/UDP=94, those features
>     are optional, as far as I know.
>
>     Anyway, I am not saying that we haven=92t made= such assumptions
>     already =96 it was more a general comment when= talking about the
>     separation between protocol and transport.
>
>     Regards,
>
>     Christer
>
>     *From:*Simon Pietro Romano [mailto:spromano@un= ina.it
>     <mailto:spromano@unina.it>]
>     *Sent:* 30. tammikuuta 2014 10:36
>     *To:* Christer Holmberg
>     *Cc:* Mary Barnes; Christian Groves; clue@ietf= .org
>     <mailto:clue@ietf.org>
>     *Subject:* Re: [clue] RTCWEB data channel for = CLUE?
>
>
>
>     Hi Christer,
>
>          However, when we= define the CLUE protocol state machine, we DO
>          need to make som= e assumptions about the transport, e.g. whether it
>          provides reliabl= e transport, in-order transport etc. If not, such
>          mechanisms need = to be implemented in the CLUE protocol itself
>          (similar to what= is done in SIP with message re-transmission,
>          usage of CSeq et= c).
>
>     The CLUE protocol draft currently states the f= ollowing:
>
>     CLUE Participants are connected by means of th= e CLUE signaling
>          channel.  S= uch channel has been conceived as a DTLS/SCTP/UDP
>     channel
>
>          in [I-D.kyzivat-= clue-signaling
>       <http://tools.ietf.org/html/dra= ft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is es= tablished as depicted in
>
>
>          the same documen= t.  CLUE protocol messages flow across such
>     channel.
>
>     We assume the
>          DTLS/SCTP/UDP ch= annel is established and define the behiavior
>     of the
>          CLUE Participant= s communicating on it.  We discuss how the CLUE
>          dialogue between= them can be exploited to successfully setup the
>          telepresence ses= sion according to the principles and concepts
>     pointed
>
>          out in in [I-D.i= etf-clue-framework
>       <http://tools.ietf.org/html/dra= ft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>].
>
>
>
>     Isn't this already enough? If not, what other = assumptions do you
>     think we should make?
>
>     Thanks,
>
>     Simon
>
>          But, I strongly = think that we shall decide on **A** transport
>
>
>          mechanism for th= e CLUE protocol. Otherwise we won=92t even guarantee
>          interoperability= between CLUE entities.
>
>          Regards,
>
>          Christer
>
>          *From:*Simon Pie= tro Romano [mailto:spromano@unina.it
>     <mailto:spromano@unina.it>]
>          *Sent:*30. tammi= kuuta 2014 10:14
>          *To:*Christer Ho= lmberg
>          *Cc:*Mary Barnes= ; Christian Groves; clue@ietf.org
>     <mailto:clue@ietf.org>
>          <mailto:clue@= ietf.org <mailto:clue@ietf.org>>
>          *Subject:*Re: [c= lue] RTCWEB data channel for CLUE?
>
>
>
>          Hello folks,
>
>          I might be perha= ps too naif, but I have to admit I don't see the
>          point of discuss= ion here. In my view, the CLUE protocol is
>          independent from= the underlying transport means. One of the
>          potential transp= orts (the best current option, IMHO) is the
>          RtcWeb/WebRTC da= ta channel. I think we should keep on specifying
>          CLUE protocol me= ssages and state machines in the CLUE protocol
>          document. We mig= ht then write a document illustrating how it is
>          possible to seam= lessly implement such a protocol on top of the
>          RtcWeb data chan= nel. I am actually working on an individual
>          contribution whi= ch basically illustrates the above concepts, by
>          also providing a= couple of call flows. I also believe that
>          Christer's propo= sal perfectly fits such an approach. Should the WG
>          decide that this= option is worth exploring, I would be glad to
>          contribute.
>
>          Cheers,
>
>          Simon
>
>          Il giorno 30/gen= /2014, alle ore 08:34, Christer Holmberg ha
>     scritto:
>
>
>
>
>          Hi,
>
>
>
>            = ;      Could we use this for CLUE without using th= e rtcweb data
>            = ;      channel mechanism?
>
>            = ;      If we want to have interoperability with rt= cweb, we need
>            = ;      to use the SCTP properties defined in the r= tcweb data
>            = ;      channel draft.
>
>            = ;      I have not heard, or identified myself, any= reason why
>            = ;      that would be a problem for CLUE.
>
>            = ;  [MB] I think the decision to be made by CLUE needs to more
>            = ;  importantly consider whether that approach works for CLUE
>            = ;  without RTCWEB. We
>
>            = ;  discussed on the call that the RTCWEB WG document (i.e.,
>            = ;  draft-ietf-rtcweb-data-channel/) could be viewed as providing
>            = ;  a more generic mechanism
>
>            = ;  that can be used for applications beyond RTCWEB.
>
>
>          Yes. The rtcweb = data channel is designed so that it works with
>          JavaScript appli= cations. But, as I said on the call, there is
>          nothing JavaScri= pt specific about. Not even all rtcweb
>          applications wil= l be JavaScript based.
>
>
>
>          That all said, a= s an individual, I don't see it to be a tremendous
>          amount of work t= o write a clue-data-channel document that uses
>          identical
>
>            = ;  mechanisms but has content specific to CLUE. For example, the
>            = ;  generic aspects in the RTCWEB seem to be primarily limited to
>
>            = ;  section 5 (just over 3 pages of text). Section 4 has some
>            = ;  generic aspects, but also some of it is RTCWEB specific. And,
>            = ;  section 3 is totally specific
>
>            = ;  to RTCWEB. And, we need to decide how much of section 6
>            = ;  applies to CLUE.So, personally, I think CLUE could just write
>            = ;  their own document
>
>            = ;  (and perhaps mention that procedures in section blah are
>            = ;  identical to those for RTCWEB OR write a general document that
>            = ;  both CLUE and
>
>            = ;  RTCWEB can reference (although the doc would have more boiler
>            = ;  plate than content. Or perhaps, section 5 could be folded
>     into the
>
>            = ;  tsvwg document (although I haven't looked at that in detail to
>            = ;  see if it would work). [/MB]
>
>
>          We could for sur= e write our own document, eventhough much would be
>          copy/paste from = the rtcweb document.
>
>          However, even if= we write our own document, assuming we want
>          interoperability= , we would STILL have a dependency on the rtcweb
>          data channel, be= cause that's where the SCTP PPID values are
>     defined.
>
>          I can try to put= something together.
>
>          Regards,
>
>          Christer
>
>          _\\|//_
>
>          ( O-O )
>
>          ~~~~~~~~~~~~~~~~= ~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>
>          Simon Pietro Rom= ano
>
>          Universita' di N= apoli Federico II
>
>          Computer Enginee= ring Department
>
>          Phone: +39 0= 81 7683823 <tel:%2B39%20081%207683823> -- Fax: +39
>     081 7683816 <tel:%2B39%20081%207683816><= br> >
>     e-mail:spromano@unina.it <mailto:e-mail%3As= promano@unina.it>
>     <mailto:spromano@unina.it <mailto:sproma= no@unina.it>>
>
>
>
>          <<Molti mi= dicono che lo scoraggiamento =E8 l'alibi degli
>
>          idioti. Ci rifle= tto un istante; e mi scoraggio>>. Magritte.
>
>          oooO
>
>          ~~~~~~~~~~~~~~~~= ~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>
>          \ ( ( )
>
>          \_) ) /
>
>          (_/
>
>
>
>
>     _\\|//_
>
>     ( O-O )
>
>     ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~= ~~~~~~~~~~~~~
>
>     Simon Pietro Romano
>
>     Universita' di Napoli Federico II
>
>     Computer Engineering Department
>
>     Phone: +39 081 7683823 <tel:%2B39%20081= %207683823> -- Fax: +39 081
>     7683816 <tel:%2B39%20081%207683816>
>
>     e-mail: spromano@unina.it <mailto:spromano@= unina.it>
>     <mailto:spromano@unina.it <mailto:sproma= no@unina.it>>
>
>
>
>     <<Molti mi dicono che lo scoraggiamento = =E8 l'alibi degli
>
>     idioti. Ci rifletto un istante; e mi scoraggio= >>. Magritte.
>
>     oooO
>
>     ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~= ~~~~~~~~~~~~~
>
>     \ ( ( )
>
>     \_) ) /
>
>     (_/
>
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue
--_000_7594FB04B1934943A5C02806D1A2204B1D14DF4EESESSMB209erics_-- From pkyzivat@alum.mit.edu Thu Jan 30 08:39: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 8E0091A03EC for ; Thu, 30 Jan 2014 08:39:39 -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 VcNj3Ym3WyRW for ; Thu, 30 Jan 2014 08:39:36 -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 317871A03A6 for ; Thu, 30 Jan 2014 08:39:36 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta01.westchester.pa.mail.comcast.net with comcast id LCsZ1n0020ldTLk51GfY5d; Thu, 30 Jan 2014 16:39:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id LGfY1n00d3ZTu2S01GfYQU; Thu, 30 Jan 2014 16:39:32 +0000 Message-ID: <52EA8044.108@alum.mit.edu> Date: Thu, 30 Jan 2014 11:39:32 -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: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D14DEC6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14DEC6@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391099972; bh=viOx2a4Hx8QU1UXE55OxSUTx1L1Zuv2kY9v27N7y0D8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FZcgsQdJO4+Ivc2+k8pmQgQerwnfeoFj3/pXfLlYuVTfcN6DC+tc6FgCizGqqUnep LqviG8pEie3D8AbOvs14voVIsOBRsC4BZTdoJeC7LV8E4wM3keHCw6wxTFJRoC+lEx CrbbgBS0nRnVAGGmgFBmt2IP4gY/eC+6wOFNipgCtScCkOPJLPEWpLISXlzKmnvqPj cBMRQd7RbcQER4TDMPB57+eIrP/HiEIvtUzLJXY1FNzVY26lwjLnR35DSYbXZ88WvP snHxRulW+BRxCKzNvC8SXK5ssEdLA0Pn/+lfxx3MDZ7OH+bu+DeeLuWohNM+LFktW9 Ty5F7616QA42w== Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 16:39:39 -0000 Yes, I didn't mention rtcweb data channel PROTOCOL in my earlier reply. As I read things, it is *possible* to avoid use of that and still be compatible with rtcweb and browser apps. Two ways we could do that: - standardize fixed channel assignments for clue. (Ugh!) - use richard's draft to negotiate the channel with SDP Since fixed channel assignment is a *really bad idea*, ISTM that practically speaking we can either: - depend on richard's draft - depend on the rtcweb data channel protocol draft Pick your poison. Thanks, Paul On 1/30/14 11:24 AM, Christer Holmberg wrote: > Hi, > > As far as I know, the only alternatives we have identified are: > > 1. > Whether or not to use the rtcweb data channel PROTOCOL > 2. > Whether or not to use Richard’s draft > > > Nobody has presented an alternative to the usage of the SCTP > capabilities (PPID values, reliability, etc) defined the rtcweb data > channel draft (whether we will use that draft as is, or write parts in > our own document, is an editorial issue). > > Regards, > > Christer > > Sent from Windows Mail > > *From:* Mary Barnes > *Sent:* ‎Thursday‎, ‎January‎ ‎30‎, ‎2014 ‎6‎:‎12‎ ‎PM > *To:* Hans-Christer Holmberg > *Cc:* Christian Groves , Simon > Pietro Romano , clue@ietf.org > > > Sure. But, it's very important to keep in mind what we are talking about > when referring to other documents. > > I'm thinking the best way forward would be to put together a document > that list and evaluates all the alternatives versus diving in with the > assumption that we'll use the RTCWEB mechanism. Just to be clear, I'm > not suggesting that's a document we progress, but I think it is > important to ensure that the WG considers all the options, pros/cons and > applicability of each before we start working out the details. > > Mary. > > > On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmberg > > > wrote: > > Hi,____ > > __ __ > > I am sure we’ll find a home for the text – the important thing now > is to agree on the mechanism, and to get the text written.____ > > __ __ > > Regards,____ > > __ __ > > Christer____ > > __ __ > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com > ] > *Sent:* 30. tammikuuta 2014 16:13 > *To:* Christian Groves > *Cc:* Christer Holmberg; Simon Pietro Romano; clue@ietf.org > > *Subject:* Re: [clue] RTCWEB data channel for CLUE?____ > > __ __ > > I think part of the debate here is whether any of the SCTP related > stuff beyond what Simon has already noted is in the CLUE protocol > document would be in the CLUE protocol document. I had envisioned > that as Simon noted, the CLUE protocol itself is designed to be > independent of the transport. We could add a reference to a > separate CLUE document that discusses the specifics of how CLUE uses > SCTP (and a note that other transports could also be used). That > latter document could reference the RTCWEB and TSVWG documents (or > MMUSIC if that's what we decide). And, we already have that as a > separate milestone. ____ > > __ __ > > I think it's very important to decouple the protocol from the > transport.____ > > __ __ > > Mary. ____ > > __ __ > > __ __ > > __ __ > > On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves > > wrote:____ > > Hello, > > I think we need something in CLUE which says how it works with SCTP. > There will be things we still need to do like registering a > media-subtype "CLUE" (if that is still part of the SCTP SDP draft) > etc. I assume that wouldn't be done in RTCWEB. > > Regards, > Christian____ > > > > On 30/01/2014 7:42 PM, Christer Holmberg wrote:____ > > > Hi, > > We need to make assumptions on whether the transport provides > reliability and in-order. When using “DTLS/SCTP/UDP”, those > features are optional, as far as I know. > > Anyway, I am not saying that we haven’t made such assumptions > already – it was more a general comment when talking about the > separation between protocol and transport. > > Regards, > > Christer____ > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > ] > *Sent:* 30. tammikuuta 2014 10:36 > *To:* Christer Holmberg > *Cc:* Mary Barnes; Christian Groves; clue@ietf.org > > *Subject:* Re: [clue] RTCWEB data channel for CLUE?____ > > > > Hi Christer, > > However, when we define the CLUE protocol state machine, we DO > need to make some assumptions about the transport, e.g. > whether it > provides reliable transport, in-order transport etc. If > not, such > mechanisms need to be implemented in the CLUE protocol itself > (similar to what is done in SIP with message re-transmission, > usage of CSeq etc). > > The CLUE protocol draft currently states the following: > > CLUE Participants are connected by means of the CLUE signaling > channel. Such channel has been conceived as a > DTLS/SCTP/UDP channel____ > > in [I-D.kyzivat-clue-signaling > ] and it is established as depicted in____ > > > the same document. CLUE protocol messages flow across such > channel. > > We assume the > DTLS/SCTP/UDP channel is established and define the > behiavior of the > CLUE Participants communicating on it. We discuss how the CLUE > dialogue between them can be exploited to successfully > setup the > telepresence session according to the principles and > concepts pointed____ > > out in in [I-D.ietf-clue-framework > ].____ > > > > Isn't this already enough? If not, what other assumptions do you > think we should make? > > Thanks, > > Simon____ > > But, I strongly think that we shall decide on **A** > transport____ > > > mechanism for the CLUE protocol. Otherwise we won’t even > guarantee > interoperability between CLUE entities. > > Regards, > > Christer____ > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > ] > *Sent:*30. tammikuuta 2014 10:14 > *To:*Christer Holmberg > *Cc:*Mary Barnes; Christian Groves; clue@ietf.org > > > > *Subject:*Re: [clue] RTCWEB data channel for CLUE?____ > > > > Hello folks, > > I might be perhaps too naif, but I have to admit I don't > see the > point of discussion here. In my view, the CLUE protocol is > independent from the underlying transport means. One of the > potential transports (the best current option, IMHO) is the > RtcWeb/WebRTC data channel. I think we should keep on > specifying > CLUE protocol messages and state machines in the CLUE protocol > document. We might then write a document illustrating how it is > possible to seamlessly implement such a protocol on top of the > RtcWeb data channel. I am actually working on an individual > contribution which basically illustrates the above concepts, by > also providing a couple of call flows. I also believe that > Christer's proposal perfectly fits such an approach. Should > the WG > decide that this option is worth exploring, I would be glad to > contribute. > > Cheers, > > Simon > > Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha > scritto: > > > > > Hi, > > > > Could we use this for CLUE without using the rtcweb > data > channel mechanism? > > If we want to have interoperability with rtcweb, we > need > to use the SCTP properties defined in the rtcweb data > channel draft. > > I have not heard, or identified myself, any reason why > that would be a problem for CLUE. > > [MB] I think the decision to be made by CLUE needs to more > importantly consider whether that approach works for CLUE > without RTCWEB. We > > discussed on the call that the RTCWEB WG document (i.e., > draft-ietf-rtcweb-data-channel/) could be viewed as > providing > a more generic mechanism > > that can be used for applications beyond RTCWEB. > > > Yes. The rtcweb data channel is designed so that it works with > JavaScript applications. But, as I said on the call, there is > nothing JavaScript specific about. Not even all rtcweb > applications will be JavaScript based. > > > > That all said, as an individual, I don't see it to be a > tremendous > amount of work to write a clue-data-channel document that uses > identical > > mechanisms but has content specific to CLUE. For > example, the > generic aspects in the RTCWEB seem to be primarily > limited to > > section 5 (just over 3 pages of text). Section 4 has some > generic aspects, but also some of it is RTCWEB > specific. And, > section 3 is totally specific > > to RTCWEB. And, we need to decide how much of section 6 > applies to CLUE.So, personally, I think CLUE could just > write > their own document > > (and perhaps mention that procedures in section blah are > identical to those for RTCWEB OR write a general > document that > both CLUE and > > RTCWEB can reference (although the doc would have more > boiler > plate than content. Or perhaps, section 5 could be > folded into the > > tsvwg document (although I haven't looked at that in > detail to > see if it would work). [/MB] > > > We could for sure write our own document, eventhough much > would be > copy/paste from the rtcweb document. > > However, even if we write our own document, assuming we want > interoperability, we would STILL have a dependency on the > rtcweb > data channel, because that's where the SCTP PPID values are > defined. > > I can try to put something together. > > Regards, > > Christer > > _\\|//_ > > ( O-O ) > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > Simon Pietro Romano > > Universita' di Napoli Federico II > > Computer Engineering Department > > Phone: +39 081 7683823 -- Fax: > +39 081 7683816 ____ > > e-mail:spromano@unina.it > >____ > > > > < > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > oooO > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > > \_) ) / > > (_/ > > > > > _\\|//_ > > ( O-O ) > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > Simon Pietro Romano > > Universita' di Napoli Federico II > > Computer Engineering Department > > Phone: +39 081 7683823 -- Fax: +39 > 081 7683816 ____ > > e-mail: spromano@unina.it > >____ > > > > < > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > oooO > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > > \_) ) / > > (_/____ > > __ __ > > __ __ > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Jan 30 08:41: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 D06C51A03D4 for ; Thu, 30 Jan 2014 08:41:58 -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 jkP6AhDVfLRJ for ; Thu, 30 Jan 2014 08:41:56 -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 A69581A03CB for ; Thu, 30 Jan 2014 08:41:55 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta04.westchester.pa.mail.comcast.net with comcast id LGTj1n00B0EZKEL54Ghsuj; Thu, 30 Jan 2014 16:41:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id LGhr1n01P3ZTu2S3MGhs1J; Thu, 30 Jan 2014 16:41:52 +0000 Message-ID: <52EA80CF.2000108@alum.mit.edu> Date: Thu, 30 Jan 2014 11:41:51 -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: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se>, <52EA7BED.4070007@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D14DF4E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14DF4E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391100112; bh=3PYP841+3tIxUyen8rK4UAIb7qR/rhPdqNvmHqcFZfw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LptDJwb856dhtZL3Scki9ICMaigaJHIqJgwRcupTWbVlrGhHqYkhHwqpblAjP5ESS UPpBsfI692np78ocFI25/0Dp+9iaTbFhZU0eRFqvPgPc1o0YN2zXiWvZSm30TM4V/4 TDjRyBnwc1sUms98l4bbsS19irWH8mtddQTAZ16ONi5tyzCm9dUGVotGVA5dEKdbuE z/k+Ur8O98bnQKDbTDAx/5e5CwRDg332ss6L4vBGS1fE4QibcZxbhZDVJ/CQN1PMyt w7TJY/mtTMlUauuDpKZMeZLz/7w693GupXz8q7JhCF3VsJ/XfEewY9iXA+CseQNHv6 a+ReGi9xxTz5Q== Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 16:41:59 -0000 On 1/30/14 11:30 AM, Christer Holmberg wrote: > Paul, > > The layer that the RTCWEB data channel adds are basically SCTP > characteristics - things that we would have to define ANYWAY. > > So, the question is whether we are ok with the SCTP characteristics, or > whether we would need different ones. I have not seen any such indication. AFAIK we need reliable ordered, an option no matter which way we go. > The question is whether we see a need for the rtcweb data channel > PROTOCOL or not. It has been confirmed that the usage is OPTIONAL, so > its up to us to determine whether we need it or not. I just commented on that. Paul > Regards, > > Christer > > Sent from Windows Mail > > *From:* Paul Kyzivat > *Sent:* Thursday, January 30, 2014 6:21 PM > *To:* clue@ietf.org > > I agree with both Christer and Mary here. > > I think the *protocol* document should be independent of the specific > transport. But it must make some requirements on the sort of transports > it can work with. (Reliable, ordered, message oriented) > > But we need for some other document (e.g. signaling) to fill in the > rest, so we have all the pieces necessary for successful interoperation > by two implementations. This must, at least, specify how this will work > when the session is negotiated via SIP and SDP O/A. > > And Christer is working on the latter. > > A couple of pieces of the puzzle are: > - draft-ietf-mmusic-sctp-sdp > - draft-ietf-tsvwg-sctp-dtls-encaps > > and the things they reference. But that only gives raw SCTP streams. > > If we were doing this work without regard to RTCWEB, we might stop > there, and just specify how we choose SCTP streams for our purpose. > > But in order to give us a chance at interoperating with RTCWEB, we > choose to also reuse draft-ietf-rtcweb-data-channel. This puts another > layer of abstraction over SCTP, bonding pairs of unidirectional SCTP > streams into bidirectional Data Channels, and making SCTP message > attributes sticky for a channel. > > We wouldn't necessarily *need* that, but RTCWEB broswer apps won't be > able to directly access the lower layers, so we need to follow that > abstraction if we want to make it *possible* for an rtcweb browser app > to directly access our clue protocol. > > I guess we *could* define clue directly on > draft-ietf-rtcweb-data-channel, and simply be very careful to define it > in a way that coincidentally is interoperable with how > draft-ietf-rtcweb-data-channel uses SCTP. But IMO that is a dangerous > approach - very difficult to maintain consistency. > > So I think it is better that we reference draft-ietf-rtcweb-data-channel. > > I agree that document has more rtcp-specifics than I would like. What > are out options about that? > 1) live with it > 2) encourage the authors of that document to structure it so that > the rtcweb specifics are clearly segregated from the more generic > parts > 3) work to factor that document into two separate documents, > one generic and one rtcweb specific. > > From our perspective, (3) would probably be best. I don't know how > feasible it is. We would probably need to volunteer to do it, though > perhaps we could recruit Richard Ejzak. > > Doing this *right* would probably mean moving the generic document to > another wg. (tsvwg?) I suspect that rtcweb might object on the grounds > that this would unnecessarily delay them. > > In the interest of expediency, I can live with (2), or possibly even (1). > > Thanks, > Paul > > On 1/30/14 9:18 AM, Christer Holmberg wrote: > > Hi, > > > > I am sure well find a home for the text the important thing now is to > > agree on the mechanism, and to get the text written. > > > > Regards, > > > > Christer > > > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > *Sent:* 30. tammikuuta 2014 16:13 > > *To:* Christian Groves > > *Cc:* Christer Holmberg; Simon Pietro Romano; clue@ietf.org > > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > > > I think part of the debate here is whether any of the SCTP related stuff > > beyond what Simon has already noted is in the CLUE protocol document > > would be in the CLUE protocol document. I had envisioned that as Simon > > noted, the CLUE protocol itself is designed to be independent of the > > transport. We could add a reference to a separate CLUE document that > > discusses the specifics of how CLUE uses SCTP (and a note that other > > transports could also be used). That latter document could reference > > the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide). > > And, we already have that as a separate milestone. > > > > I think it's very important to decouple the protocol from the transport. > > > > Mary. > > > > On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves > > > > > wrote: > > > > Hello, > > > > I think we need something in CLUE which says how it works with SCTP. > > There will be things we still need to do like registering a > > media-subtype "CLUE" (if that is still part of the SCTP SDP draft) etc. > > I assume that wouldn't be done in RTCWEB. > > > > Regards, > > Christian > > > > > > > > On 30/01/2014 7:42 PM, Christer Holmberg wrote: > > > > > > Hi, > > > > We need to make assumptions on whether the transport provides > > reliability and in-order. When using DTLS/SCTP/UDP, those features > > are optional, as far as I know. > > > > Anyway, I am not saying that we havent made such assumptions > > already it was more a general comment when talking about the > > separation between protocol and transport. > > > > Regards, > > > > Christer > > > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > > ] > > *Sent:* 30. tammikuuta 2014 10:36 > > *To:* Christer Holmberg > > *Cc:* Mary Barnes; Christian Groves; clue@ietf.org > > > > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > > > > > > > Hi Christer, > > > > However, when we define the CLUE protocol state machine, we DO > > need to make some assumptions about the transport, e.g. > whether it > > provides reliable transport, in-order transport etc. If not, > such > > mechanisms need to be implemented in the CLUE protocol itself > > (similar to what is done in SIP with message re-transmission, > > usage of CSeq etc). > > > > The CLUE protocol draft currently states the following: > > > > CLUE Participants are connected by means of the CLUE signaling > > channel. Such channel has been conceived as a DTLS/SCTP/UDP > > channel > > > > in [I-D.kyzivat-clue-signaling > > > ] > and it is established as depicted in > > > > > > the same document. CLUE protocol messages flow across such > > channel. > > > > We assume the > > DTLS/SCTP/UDP channel is established and define the behiavior > > of the > > CLUE Participants communicating on it. We discuss how the CLUE > > dialogue between them can be exploited to successfully setup the > > telepresence session according to the principles and concepts > > pointed > > > > out in in [I-D.ietf-clue-framework > > > ]. > > > > > > > > Isn't this already enough? If not, what other assumptions do you > > think we should make? > > > > Thanks, > > > > Simon > > > > But, I strongly think that we shall decide on **A** transport > > > > > > mechanism for the CLUE protocol. Otherwise we wont even > guarantee > > interoperability between CLUE entities. > > > > Regards, > > > > Christer > > > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > > ] > > *Sent:*30. tammikuuta 2014 10:14 > > *To:*Christer Holmberg > > *Cc:*Mary Barnes; Christian Groves; clue@ietf.org > > > > > > > *Subject:*Re: [clue] RTCWEB data channel for CLUE? > > > > > > > > Hello folks, > > > > I might be perhaps too naif, but I have to admit I don't see the > > point of discussion here. In my view, the CLUE protocol is > > independent from the underlying transport means. One of the > > potential transports (the best current option, IMHO) is the > > RtcWeb/WebRTC data channel. I think we should keep on specifying > > CLUE protocol messages and state machines in the CLUE protocol > > document. We might then write a document illustrating how it is > > possible to seamlessly implement such a protocol on top of the > > RtcWeb data channel. I am actually working on an individual > > contribution which basically illustrates the above concepts, by > > also providing a couple of call flows. I also believe that > > Christer's proposal perfectly fits such an approach. Should > the WG > > decide that this option is worth exploring, I would be glad to > > contribute. > > > > Cheers, > > > > Simon > > > > Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha > > scritto: > > > > > > > > > > Hi, > > > > > > > > Could we use this for CLUE without using the rtcweb data > > channel mechanism? > > > > If we want to have interoperability with rtcweb, we need > > to use the SCTP properties defined in the rtcweb data > > channel draft. > > > > I have not heard, or identified myself, any reason why > > that would be a problem for CLUE. > > > > [MB] I think the decision to be made by CLUE needs to more > > importantly consider whether that approach works for CLUE > > without RTCWEB. We > > > > discussed on the call that the RTCWEB WG document (i.e., > > draft-ietf-rtcweb-data-channel/) could be viewed as > providing > > a more generic mechanism > > > > that can be used for applications beyond RTCWEB. > > > > > > Yes. The rtcweb data channel is designed so that it works with > > JavaScript applications. But, as I said on the call, there is > > nothing JavaScript specific about. Not even all rtcweb > > applications will be JavaScript based. > > > > > > > > That all said, as an individual, I don't see it to be a > tremendous > > amount of work to write a clue-data-channel document that uses > > identical > > > > mechanisms but has content specific to CLUE. For > example, the > > generic aspects in the RTCWEB seem to be primarily > limited to > > > > section 5 (just over 3 pages of text). Section 4 has some > > generic aspects, but also some of it is RTCWEB specific. > And, > > section 3 is totally specific > > > > to RTCWEB. And, we need to decide how much of section 6 > > applies to CLUE.So, personally, I think CLUE could just > write > > their own document > > > > (and perhaps mention that procedures in section blah are > > identical to those for RTCWEB OR write a general > document that > > both CLUE and > > > > RTCWEB can reference (although the doc would have more > boiler > > plate than content. Or perhaps, section 5 could be folded > > into the > > > > tsvwg document (although I haven't looked at that in > detail to > > see if it would work). [/MB] > > > > > > We could for sure write our own document, eventhough much > would be > > copy/paste from the rtcweb document. > > > > However, even if we write our own document, assuming we want > > interoperability, we would STILL have a dependency on the rtcweb > > data channel, because that's where the SCTP PPID values are > > defined. > > > > I can try to put something together. > > > > Regards, > > > > Christer > > > > _\\|//_ > > > > ( O-O ) > > > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Simon Pietro Romano > > > > Universita' di Napoli Federico II > > > > Computer Engineering Department > > > > Phone: +39 081 7683823 -- Fax: +39 > > 081 7683816 > > > > e-mail:spromano@unina.it > > > > > > > > > > > < > > > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > > > oooO > > > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > \ ( ( ) > > > > \_) ) / > > > > (_/ > > > > > > > > > > _\\|//_ > > > > ( O-O ) > > > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Simon Pietro Romano > > > > Universita' di Napoli Federico II > > > > Computer Engineering Department > > > > Phone: +39 081 7683823 -- Fax: +39 081 > > 7683816 > > > > e-mail: spromano@unina.it > > > > > > > > > > > < > > > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > > > oooO > > > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > \ ( ( ) > > > > \_) ) / > > > > (_/ > > > > > > > > _______________________________________________ > > clue mailing 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 keith.drage@alcatel-lucent.com Thu Jan 30 09:47: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 D21411A0451 for ; Thu, 30 Jan 2014 09:47:37 -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 GZtBDVICOvbe for ; Thu, 30 Jan 2014 09:47:34 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 497291A03F3 for ; Thu, 30 Jan 2014 09:47:33 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s0UHlROO017129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Jan 2014 11:47:28 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s0UHlPic004769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 18:47:26 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 30 Jan 2014 18:47:25 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AASGoAAABEq/QAAAWrOgAAGa6TgAAm/AoAAIlJjgP///J6A///sArCAABouAP//7jGwgAAmwwCAAEk/gP//7g9wAAazkoD//9qHMA== Date: Thu, 30 Jan 2014 17:47:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B126A78@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se> <52EA7BED.4070007@alum.mit.edu> In-Reply-To: <52EA7BED.4070007@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 17:47:37 -0000 A protocol based on "(Reliable, ordered, message oriented)" transport will = be entirely different from one that is not. Therefore we should agree those requirements as a starting point. If we fail to do that, it means that every response that carries informatio= n will have to have its own response that does not carry data. We will need= to build retransmission into the protocol with timeouts. Etc. Regards Keith > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 30 January 2014 16:21 > To: clue@ietf.org > Subject: Re: [clue] RTCWEB data channel for CLUE? >=20 > I agree with both Christer and Mary here. >=20 > I think the *protocol* document should be independent of the=20 > specific transport. But it must make some requirements on the=20 > sort of transports it can work with. (Reliable, ordered,=20 > message oriented) >=20 > But we need for some other document (e.g. signaling) to fill=20 > in the rest, so we have all the pieces necessary for=20 > successful interoperation by two implementations. This must,=20 > at least, specify how this will work when the session is=20 > negotiated via SIP and SDP O/A. >=20 > And Christer is working on the latter. >=20 > A couple of pieces of the puzzle are: > - draft-ietf-mmusic-sctp-sdp > - draft-ietf-tsvwg-sctp-dtls-encaps >=20 > and the things they reference. But that only gives raw SCTP streams. >=20 > If we were doing this work without regard to RTCWEB, we might=20 > stop there, and just specify how we choose SCTP streams for=20 > our purpose. >=20 > But in order to give us a chance at interoperating with=20 > RTCWEB, we choose to also reuse=20 > draft-ietf-rtcweb-data-channel. This puts another layer of=20 > abstraction over SCTP, bonding pairs of unidirectional SCTP=20 > streams into bidirectional Data Channels, and making SCTP=20 > message attributes sticky for a channel. >=20 > We wouldn't necessarily *need* that, but RTCWEB broswer apps=20 > won't be able to directly access the lower layers, so we need=20 > to follow that abstraction if we want to make it *possible*=20 > for an rtcweb browser app to directly access our clue protocol. >=20 > I guess we *could* define clue directly on=20 > draft-ietf-rtcweb-data-channel, and simply be very careful to=20 > define it in a way that coincidentally is interoperable with=20 > how draft-ietf-rtcweb-data-channel uses SCTP. But IMO that is=20 > a dangerous approach - very difficult to maintain consistency. >=20 > So I think it is better that we reference=20 > draft-ietf-rtcweb-data-channel. >=20 > I agree that document has more rtcp-specifics than I would=20 > like. What are out options about that? > 1) live with it > 2) encourage the authors of that document to structure it so that > the rtcweb specifics are clearly segregated from the more generic > parts > 3) work to factor that document into two separate documents, > one generic and one rtcweb specific. >=20 > From our perspective, (3) would probably be best. I don't=20 > know how feasible it is. We would probably need to volunteer=20 > to do it, though perhaps we could recruit Richard Ejzak. >=20 > Doing this *right* would probably mean moving the generic=20 > document to another wg. (tsvwg?) I suspect that rtcweb might=20 > object on the grounds that this would unnecessarily delay them. >=20 > In the interest of expediency, I can live with (2), or=20 > possibly even (1). >=20 > Thanks, > Paul >=20 > On 1/30/14 9:18 AM, Christer Holmberg wrote: > > Hi, > > > > I am sure we'll find a home for the text - the important=20 > thing now is=20 > > to agree on the mechanism, and to get the text written. > > > > Regards, > > > > Christer > > > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > *Sent:* 30. tammikuuta 2014 16:13 > > *To:* Christian Groves > > *Cc:* Christer Holmberg; Simon Pietro Romano; clue@ietf.org > > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > > > I think part of the debate here is whether any of the SCTP related=20 > > stuff beyond what Simon has already noted is in the CLUE protocol=20 > > document would be in the CLUE protocol document. I had envisioned=20 > > that as Simon noted, the CLUE protocol itself is designed to be=20 > > independent of the transport. We could add a reference to=20 > a separate=20 > > CLUE document that discusses the specifics of how CLUE uses=20 > SCTP (and=20 > > a note that other transports could also be used). That latter=20 > > document could reference the RTCWEB and TSVWG documents (or=20 > MMUSIC if that's what we decide). > > And, we already have that as a separate milestone. > > > > I think it's very important to decouple the protocol from=20 > the transport. > > > > Mary. > > > > On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves=20 > > > > > wrote: > > > > Hello, > > > > I think we need something in CLUE which says how it works with SCTP. > > There will be things we still need to do like registering a=20 > > media-subtype "CLUE" (if that is still part of the SCTP SDP=20 > draft) etc. > > I assume that wouldn't be done in RTCWEB. > > > > Regards, > > Christian > > > > > > > > On 30/01/2014 7:42 PM, Christer Holmberg wrote: > > > > > > Hi, > > > > We need to make assumptions on whether the transport provides > > reliability and in-order. When using "DTLS/SCTP/UDP",=20 > those features > > are optional, as far as I know. > > > > Anyway, I am not saying that we haven't made such assumptions > > already - it was more a general comment when talking about the > > separation between protocol and transport. > > > > Regards, > > > > Christer > > > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > > ] > > *Sent:* 30. tammikuuta 2014 10:36 > > *To:* Christer Holmberg > > *Cc:* Mary Barnes; Christian Groves; clue@ietf.org > > > > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > > > > > > > Hi Christer, > > > > However, when we define the CLUE protocol state=20 > machine, we DO > > need to make some assumptions about the transport,=20 > e.g. whether it > > provides reliable transport, in-order transport=20 > etc. If not, such > > mechanisms need to be implemented in the CLUE=20 > protocol itself > > (similar to what is done in SIP with message=20 > re-transmission, > > usage of CSeq etc). > > > > The CLUE protocol draft currently states the following: > > > > CLUE Participants are connected by means of the CLUE signaling > > channel. Such channel has been conceived as a=20 > DTLS/SCTP/UDP > > channel > > > > in [I-D.kyzivat-clue-signaling > > =20 > >=20 > > vat-clue-signaling>] and it is established as depicted in > > > > > > the same document. CLUE protocol messages flow across such > > channel. > > > > We assume the > > DTLS/SCTP/UDP channel is established and define=20 > the behiavior > > of the > > CLUE Participants communicating on it. We discuss=20 > how the CLUE > > dialogue between them can be exploited to=20 > successfully setup the > > telepresence session according to the principles=20 > and concepts > > pointed > > > > out in in [I-D.ietf-clue-framework > > =20 > I-D.ietf-clue-framework>]. > > > > > > > > Isn't this already enough? If not, what other assumptions do you > > think we should make? > > > > Thanks, > > > > Simon > > > > But, I strongly think that we shall decide on=20 > **A** transport > > > > > > mechanism for the CLUE protocol. Otherwise we=20 > won't even guarantee > > interoperability between CLUE entities. > > > > Regards, > > > > Christer > > > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > > ] > > *Sent:*30. tammikuuta 2014 10:14 > > *To:*Christer Holmberg > > *Cc:*Mary Barnes; Christian Groves; clue@ietf.org > > > > > > > *Subject:*Re: [clue] RTCWEB data channel for CLUE? > > > > > > > > Hello folks, > > > > I might be perhaps too naif, but I have to admit I=20 > don't see the > > point of discussion here. In my view, the CLUE protocol is > > independent from the underlying transport means. One of the > > potential transports (the best current option, IMHO) is the > > RtcWeb/WebRTC data channel. I think we should keep=20 > on specifying > > CLUE protocol messages and state machines in the=20 > CLUE protocol > > document. We might then write a document=20 > illustrating how it is > > possible to seamlessly implement such a protocol=20 > on top of the > > RtcWeb data channel. I am actually working on an individual > > contribution which basically illustrates the above=20 > concepts, by > > also providing a couple of call flows. I also believe that > > Christer's proposal perfectly fits such an=20 > approach. Should the WG > > decide that this option is worth exploring, I=20 > would be glad to > > contribute. > > > > Cheers, > > > > Simon > > > > Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha > > scritto: > > > > > > > > > > Hi, > > > > > > > > Could we use this for CLUE without using=20 > the rtcweb data > > channel mechanism? > > > > If we want to have interoperability with=20 > rtcweb, we need > > to use the SCTP properties defined in the=20 > rtcweb data > > channel draft. > > > > I have not heard, or identified myself,=20 > any reason why > > that would be a problem for CLUE. > > > > [MB] I think the decision to be made by CLUE=20 > needs to more > > importantly consider whether that approach=20 > works for CLUE > > without RTCWEB. We > > > > discussed on the call that the RTCWEB WG=20 > document (i.e., > > draft-ietf-rtcweb-data-channel/) could be=20 > viewed as providing > > a more generic mechanism > > > > that can be used for applications beyond RTCWEB. > > > > > > Yes. The rtcweb data channel is designed so that=20 > it works with > > JavaScript applications. But, as I said on the=20 > call, there is > > nothing JavaScript specific about. Not even all rtcweb > > applications will be JavaScript based. > > > > > > > > That all said, as an individual, I don't see it to=20 > be a tremendous > > amount of work to write a clue-data-channel=20 > document that uses > > identical > > > > mechanisms but has content specific to CLUE.=20 > For example, the > > generic aspects in the RTCWEB seem to be primarily=20 > > limited to > > > > section 5 (just over 3 pages of text). Section=20 > 4 has some > > generic aspects, but also some of it is RTCWEB=20 > specific. And, > > section 3 is totally specific > > > > to RTCWEB. And, we need to decide how much of section 6 > > applies to CLUE.So, personally, I think CLUE=20 > could just write > > their own document > > > > (and perhaps mention that procedures in=20 > section blah are > > identical to those for RTCWEB OR write a=20 > general document that > > both CLUE and > > > > RTCWEB can reference (although the doc would=20 > have more boiler > > plate than content. Or perhaps, section 5=20 > could be folded > > into the > > > > tsvwg document (although I haven't looked at=20 > that in detail to > > see if it would work). [/MB] > > > > > > We could for sure write our own document,=20 > eventhough much would be > > copy/paste from the rtcweb document. > > > > However, even if we write our own document,=20 > assuming we want > > interoperability, we would STILL have a dependency=20 > on the rtcweb > > data channel, because that's where the SCTP PPID values are > > defined. > > > > I can try to put something together. > > > > Regards, > > > > Christer > > > > _\\|//_ > > > > ( O-O ) > > > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Simon Pietro Romano > > > > Universita' di Napoli Federico II > > > > Computer Engineering Department > > > > Phone: +39 081 7683823 =20 > -- Fax: +39 > > 081 7683816 > > > > e-mail:spromano@unina.it > > > > > > > > > > > < > > > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > > > oooO > > > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > \ ( ( ) > > > > \_) ) / > > > > (_/ > > > > > > > > > > _\\|//_ > > > > ( O-O ) > > > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Simon Pietro Romano > > > > Universita' di Napoli Federico II > > > > Computer Engineering Department > > > > Phone: +39 081 7683823 --=20 > Fax: +39 081 > > 7683816 > > > > e-mail: spromano@unina.it > > > > > > > > > > > < > > > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > > > oooO > > > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > \ ( ( ) > > > > \_) ) / > > > > (_/ > > > > > > > > _______________________________________________ > > 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 keith.drage@alcatel-lucent.com Thu Jan 30 09:47: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 3A2671A03F3 for ; Thu, 30 Jan 2014 09:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.918 X-Spam-Level: X-Spam-Status: No, score=-5.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, 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 7nW5euOeTqA9 for ; Thu, 30 Jan 2014 09:47:35 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 535F61A044F for ; Thu, 30 Jan 2014 09:47:35 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s0UHlRUr026499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Jan 2014 11:47:28 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s0UHlQPc026751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 18:47:26 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 30 Jan 2014 18:47:26 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Mary Barnes Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AASGoAAABEq/QAAAWrOgAAGa6TgAAm/AoAAIlJjgP///J6A///sArCAABouAP//7jGwgAAmwwCAAEk/gP//7g9wAAZnk4AAAoCTUv//60Zw Date: Thu, 30 Jan 2014 17:47:25 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B126A7D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D14DEC6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14DEC6@ESESSMB209.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B126A7DFR712WXCHMBA11zeu_" MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 17:47:39 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B126A7DFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I understand that Richard's document will need an additional set of additio= nal requirements to that which he has written for MSRP - see https://datatracker.ietf.org/doc/draft-ejzak-dispatch-msrp-data-channel/ Assuming we go that way, and I hope we do, it would be sensible to write th= ose requirements into whatever document defines setting up the transport fo= r the CLUE protocol. I would envisage two documents: the CLUE protocol itself, and the document = setting up the transport for the CLUE protocol. regards Keith ________________________________ From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 30 January 2014 16:24 To: Mary Barnes Cc: clue@ietf.org Subject: Re: [clue] RTCWEB data channel for CLUE? Hi, As far as I know, the only alternatives we have identified are: 1. Whether or not to use the rtcweb data channel PROTOCOL 2. Whether or not to use Richard=92s draft Nobody has presented an alternative to the usage of the SCTP capabilities (= PPID values, reliability, etc) defined the rtcweb data channel draft (wheth= er we will use that draft as is, or write parts in our own document, is an = editorial issue). Regards, Christer Sent from Windows Mail From: Mary Barnes Sent: =FDThursday=FD, =FDJanuary=FD =FD30=FD, =FD2014 =FD6=FD:=FD12=FD =FDP= M To: Hans-Christer Holmberg Cc: Christian Groves, Simon Pietro Ro= mano, clue@ietf.org Sure. But, it's very important to keep in mind what we are talking about wh= en referring to other documents. I'm thinking the best way forward would be to put together a document that = list and evaluates all the alternatives versus diving in with the assumptio= n that we'll use the RTCWEB mechanism. Just to be clear, I'm not suggesti= ng that's a document we progress, but I think it is important to ensure tha= t the WG considers all the options, pros/cons and applicability of each bef= ore we start working out the details. Mary. On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmberg > wrote: Hi, I am sure we=92ll find a home for the text =96 the important thing now is t= o agree on the mechanism, and to get the text written. Regards, Christer From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 30. tammikuuta 2014 16:13 To: Christian Groves Cc: Christer Holmberg; Simon Pietro Romano; clue@ietf.org Subject: Re: [clue] RTCWEB data channel for CLUE? I think part of the debate here is whether any of the SCTP related stuff be= yond what Simon has already noted is in the CLUE protocol document would be= in the CLUE protocol document. I had envisioned that as Simon noted, the = CLUE protocol itself is designed to be independent of the transport. We co= uld add a reference to a separate CLUE document that discusses the specific= s of how CLUE uses SCTP (and a note that other transports could also be use= d). That latter document could reference the RTCWEB and TSVWG documents (o= r MMUSIC if that's what we decide). And, we already have that as a separ= ate milestone. I think it's very important to decouple the protocol from the transport. Mary. On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves > wrote: Hello, I think we need something in CLUE which says how it works with SCTP. There = will be things we still need to do like registering a media-subtype "CLUE" = (if that is still part of the SCTP SDP draft) etc. I assume that wouldn't b= e done in RTCWEB. Regards, Christian On 30/01/2014 7:42 PM, Christer Holmberg wrote: Hi, We need to make assumptions on whether the transport provides reliability a= nd in-order. When using =93DTLS/SCTP/UDP=94, those features are optional, a= s far as I know. Anyway, I am not saying that we haven=92t made such assumptions already =96= it was more a general comment when talking about the separation between pr= otocol and transport. Regards, Christer *From:*Simon Pietro Romano [mailto:spromano@unina.it] *Sent:* 30. tammikuuta 2014 10:36 *To:* Christer Holmberg *Cc:* Mary Barnes; Christian Groves; clue@ietf.org *Subject:* Re: [clue] RTCWEB data channel for CLUE? Hi Christer, However, when we define the CLUE protocol state machine, we DO need to make some assumptions about the transport, e.g. whether it provides reliable transport, in-order transport etc. If not, such mechanisms need to be implemented in the CLUE protocol itself (similar to what is done in SIP with message re-transmission, usage of CSeq etc). The CLUE protocol draft currently states the following: CLUE Participants are connected by means of the CLUE signaling channel. Such channel has been conceived as a DTLS/SCTP/UDP channel in [I-D.kyzivat-clue-signaling ] and it is established a= s depicted in the same document. CLUE protocol messages flow across such channel. We assume the DTLS/SCTP/UDP channel is established and define the behiavior of the CLUE Participants communicating on it. We discuss how the CLUE dialogue between them can be exploited to successfully setup the telepresence session according to the principles and concepts pointed out in in [I-D.ietf-clue-framework ]. Isn't this already enough? If not, what other assumptions do you think we s= hould make? Thanks, Simon But, I strongly think that we shall decide on **A** transport mechanism for the CLUE protocol. Otherwise we won=92t even guarantee interoperability between CLUE entities. Regards, Christer *From:*Simon Pietro Romano [mailto:spromano@unina.it] *Sent:*30. tammikuuta 2014 10:14 *To:*Christer Holmberg *Cc:*Mary Barnes; Christian Groves; clue@ietf.org > *Subject:*Re: [clue] RTCWEB data channel for CLUE? Hello folks, I might be perhaps too naif, but I have to admit I don't see the point of discussion here. In my view, the CLUE protocol is independent from the underlying transport means. One of the potential transports (the best current option, IMHO) is the RtcWeb/WebRTC data channel. I think we should keep on specifying CLUE protocol messages and state machines in the CLUE protocol document. We might then write a document illustrating how it is possible to seamlessly implement such a protocol on top of the RtcWeb data channel. I am actually working on an individual contribution which basically illustrates the above concepts, by also providing a couple of call flows. I also believe that Christer's proposal perfectly fits such an approach. Should the WG decide that this option is worth exploring, I would be glad to contribute. Cheers, Simon Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha scritto: Hi, Could we use this for CLUE without using the rtcweb data channel mechanism? If we want to have interoperability with rtcweb, we need to use the SCTP properties defined in the rtcweb data channel draft. I have not heard, or identified myself, any reason why that would be a problem for CLUE. [MB] I think the decision to be made by CLUE needs to more importantly consider whether that approach works for CLUE without RTCWEB. We discussed on the call that the RTCWEB WG document (i.e., draft-ietf-rtcweb-data-channel/) could be viewed as providing a more generic mechanism that can be used for applications beyond RTCWEB. Yes. The rtcweb data channel is designed so that it works with JavaScript applications. But, as I said on the call, there is nothing JavaScript specific about. Not even all rtcweb applications will be JavaScript based. That all said, as an individual, I don't see it to be a tremendous amount of work to write a clue-data-channel document that uses identical mechanisms but has content specific to CLUE. For example, the generic aspects in the RTCWEB seem to be primarily limited to section 5 (just over 3 pages of text). Section 4 has some generic aspects, but also some of it is RTCWEB specific. And, section 3 is totally specific to RTCWEB. And, we need to decide how much of section 6 applies to CLUE.So, personally, I think CLUE could just write their own document (and perhaps mention that procedures in section blah are identical to those for RTCWEB OR write a general document that both CLUE and RTCWEB can reference (although the doc would have more boiler plate than content. Or perhaps, section 5 could be folded into the tsvwg document (although I haven't looked at that in detail to see if it would work). [/MB] We could for sure write our own document, eventhough much would be copy/paste from the rtcweb document. However, even if we write our own document, assuming we want interoperability, we would STILL have a dependency on the rtcweb data channel, because that's where the SCTP PPID values are defined. I can try to put something together. Regards, Christer _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 76838= 16 e-mail:spromano@unina.it > <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it > <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --_000_949EF20990823C4C85C18D59AA11AD8B126A7DFR712WXCHMBA11zeu_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
I understand that Richard's document will need a= n additional set of additional requirements to that which he has written fo= r MSRP - see
 
 
Assuming we go that way, and I hope we do, it wo= uld be sensible to write those requirements into whatever document defines = setting up the transport for the CLUE protocol.
 
I would envisage two documents: the CLUE protoco= l itself, and the document setting up the transport for the CLUE protocol.<= /font>
 
regards
 
Keith

From: clue [mailto:clue-bounces@iet= f.org] On Behalf Of Christer Holmberg
Sent: 30 January 2014 16:24
To: Mary Barnes
Cc: clue@ietf.org
Subject: Re: [clue] RTCWEB data channel for CLUE?

Hi,

As far as I know, the only alternatives we have identified are:

  1. Whether or not to use the rtcweb data channel PROTOCOL
  2. Whether or not to use Richard=92s draft

Nobody has presented an alternative to the usage of the SCTP capabilities (= PPID values, reliability, etc) defined the rtcweb data channel draft (wheth= er we will use that draft as is, or write parts in our own document, is an = editorial issue).

Regards,

Christer

Sent from Windows Mail

From: Mary Barnes
Sent: =FDThursday=FD, =FDJanuary=FD =FD30=FD, =FD2014 =FD6=FD:= =FD12=FD =FDPM
To: Hans-Christer Holmberg
Cc: Christian Groves, Simon Pietro Romano= , clue@ietf.org

Sure. But, it's very important to keep in mind what we are= talking about when referring to other documents.  

I'm thinking the best way forward would be to put together a document = that list and evaluates all the alternatives versus diving in with the assu= mption that we'll use the RTCWEB mechanism.   Just to be clear, I'm no= t suggesting that's a document we progress, but I think it is important to ensure that the WG considers all the option= s, pros/cons and applicability of each before we start working out the deta= ils. 

Mary.


On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmbe= rg <ch= rister.holmberg@ericsson.com> wrote:

Hi,

 

I am sure we=92ll find a home for t= he text =96 the important thing now is to agree on the mechanism, and to ge= t the text written.

 

Regards,

 

Christer

 

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 30. tammikuuta 2014 16:13
To: Christian Groves
Cc: Christer Holmberg; Simon Pietro Romano; clue@ietf.org
Subject: Re: [clue] RTCWEB data channel for CLUE?

 

I think part of the debate here is whether any of th= e SCTP related stuff beyond what Simon has already noted is in the CLUE pro= tocol document would be in the CLUE protocol document.  I had envision= ed that as Simon noted, the CLUE protocol itself is designed to be independent of the transport.  We could add = a reference to a separate CLUE document that discusses the specifics of how= CLUE uses SCTP (and a note that other transports could also be used). &nbs= p;That latter document could reference the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide).   &n= bsp;And, we already have that as a separate milestone. <= /p>

 

I think it's very important to decouple the protocol= from the transport.

 

Mary. 

 

 

 

On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves &l= t;Chris= tian.Groves@nteczone.com> wrote:

Hello,

I think we need something in CLUE which says how it works with SCTP. There = will be things we still need to do like registering a media-subtype "C= LUE" (if that is still part of the SCTP SDP draft) etc. I assume that = wouldn't be done in RTCWEB.

Regards,
Christian



On 30/01/2014 7:42 PM, Christer Holmberg wrote:


Hi,

We need to make assumptions on whether the transport provides reliability a= nd in-order. When using =93DTLS/SCTP/UDP=94, those features are optional, a= s far as I know.

Anyway, I am not saying that we haven=92t made such assumptions already =96= it was more a general comment when talking about the separation between pr= otocol and transport.

Regards,

Christer

*From:*Simon Pietro Romano [mailto:spromano@unina.it]
*Sent:* 30. tammikuuta 2014 10:36
*To:* Christer Holmberg
*Cc:* Mary Barnes; Christian Groves; clue@ietf.org
*Subject:* Re: [clue] RTCWEB data channel for CLUE?



Hi Christer,

    However, when we define the CLUE protocol state machine, we D= O
    need to make some assumptions about the transport, e.g. wheth= er it
    provides reliable transport, in-order transport etc. If not, = such
    mechanisms need to be implemented in the CLUE protocol itself=
    (similar to what is done in SIP with message re-transmission,=
    usage of CSeq etc).

The CLUE protocol draft currently states the following:

CLUE Participants are connected by means of the CLUE signaling
    channel.  Such channel has been conceived as a DTLS/SCTP= /UDP channel

    in [I-D.kyzivat-clue-signaling  &= lt;http://tools.ietf.org/html/d= raft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is established as depicted in


    the same document.  CLUE protocol messages flow across s= uch channel.

We assume the
    DTLS/SCTP/UDP channel is established and define the behiavior= of the
    CLUE Participants communicating on it.  We discuss how t= he CLUE
    dialogue between them can be exploited to successfully setup = the
    telepresence session according to the principles and concepts= pointed

    out in in [I-D.ietf-clue-framework &nb= sp;<http://tools.ietf.org/html/= draft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>].<= u>



Isn't this already enough? If not, what other assumptions do you think we s= hould make?

Thanks,

Simon

    But, I strongly think that we shall de= cide on **A** transport


    mechanism for the CLUE protocol. Otherwise we won=92t even gu= arantee
    interoperability between CLUE entities.

    Regards,

    Christer

    *From:*Simon Pietro Romano [mailto:spromano@unina.it]=
    *Sent:*30. tammikuuta 2014 10:14
    *To:*Christer Holmberg
    *Cc:*Mary Barnes; Christian Groves; clue@ietf.org
    <mailto:clue@ietf.org>
    *Subject:*Re: [clue] RTCWEB data channel for CLUE?<= /u>



    Hello folks,

    I might be perhaps too naif, but I have to admit I don't see = the
    point of discussion here. In my view, the CLUE protocol is     independent from the underlying transport means. One of the     potential transports (the best current option, IMHO) is the     RtcWeb/WebRTC data channel. I think we should keep on specify= ing
    CLUE protocol messages and state machines in the CLUE protoco= l
    document. We might then write a document illustrating how it = is
    possible to seamlessly implement such a protocol on top of th= e
    RtcWeb data channel. I am actually working on an individual     contribution which basically illustrates the above concepts, = by
    also providing a couple of call flows. I also believe that     Christer's proposal perfectly fits such an approach. Should t= he WG
    decide that this option is worth exploring, I would be glad t= o
    contribute.

    Cheers,

    Simon

    Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha s= critto:




    Hi,



            Could we use this for CLUE withou= t using the rtcweb data
            channel mechanism?

            If we want to have interoperabili= ty with rtcweb, we need
            to use the SCTP properties define= d in the rtcweb data
            channel draft.

            I have not heard, or identified m= yself, any reason why
            that would be a problem for CLUE.=

        [MB] I think the decision to be made by CLUE ne= eds to more
        importantly consider whether that approach work= s for CLUE
        without RTCWEB. We

        discussed on the call that the RTCWEB WG docume= nt (i.e.,
        draft-ietf-rtcweb-data-channel/) could be viewe= d as providing
        a more generic mechanism

        that can be used for applications beyond RTCWEB= .


    Yes. The rtcweb data channel is designed so that it works wit= h
    JavaScript applications. But, as I said on the call, there is=
    nothing JavaScript specific about. Not even all rtcweb
    applications will be JavaScript based.



    That all said, as an individual, I don't see it to be a treme= ndous
    amount of work to write a clue-data-channel document that use= s
    identical

        mechanisms but has content specific to CLUE. Fo= r example, the
        generic aspects in the RTCWEB seem to be primar= ily limited to

        section 5 (just over 3 pages of text). Section = 4 has some
        generic aspects, but also some of it is RTCWEB = specific. And,
        section 3 is totally specific

        to RTCWEB. And, we need to decide how much of s= ection 6
        applies to CLUE.So, personally, I think CLUE co= uld just write
        their own document

        (and perhaps mention that procedures in section= blah are
        identical to those for RTCWEB OR write a genera= l document that
        both CLUE and

        RTCWEB can reference (although the doc would ha= ve more boiler
        plate than content. Or perhaps, section 5 could= be folded into the

        tsvwg document (although I haven't looked at th= at in detail to
        see if it would work). [/MB]


    We could for sure write our own document, eventhough much wou= ld be
    copy/paste from the rtcweb document.

    However, even if we write our own document, assuming we want<= br>     interoperability, we would STILL have a dependency on the rtc= web
    data channel, because that's where the SCTP PPID values are d= efined.

    I can try to put something together.

    Regards,

    Christer

    _\\|//_

    ( O-O )

    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
    Simon Pietro Romano

    Universita' di Napoli Federico II

    Computer Engineering Department

    Phone: +39 081 7683823 -- Fax: +39 081 768381= 6

    e-mail:spromano@unina.it <mailto:spromano@unina.it>



    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi deg= li

    idioti. Ci rifletto un istante; e mi scoraggio>>. Magri= tte.

    oooO

    ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
    \ ( ( )

    \_) ) /

    (_/




_\\|//_

( O-O )

~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

Simon Pietro Romano

Universita' di Napoli Federico II

Computer Engineering Department

Phone: +39 081= 7683823 -- Fax: +39 081 768381= 6

e-mail: spromano@unina.it <mailto:spromano@unina.it>



<<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli

idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.

oooO

~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

\ ( ( )

\_) ) /

(_/

 

 


--_000_949EF20990823C4C85C18D59AA11AD8B126A7DFR712WXCHMBA11zeu_-- From christer.holmberg@ericsson.com Thu Jan 30 11:00: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 A85B51A044E for ; Thu, 30 Jan 2014 11:00:08 -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 oJGELsEvx4Ge for ; Thu, 30 Jan 2014 11:00:05 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF6B1A0435 for ; Thu, 30 Jan 2014 11:00:03 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-18-52eaa12f39f0 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 28.4A.10875.F21AAE25; Thu, 30 Jan 2014 20:00:00 +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; Thu, 30 Jan 2014 19:59:59 +0100 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] RTCWEB data channel for CLUE? Thread-Index: Ac8cL9ZyC5id0n9eQj2yyopXPJTU5AASGoAAABEq/QAAAWrOgAAGa6TgAAm/AoAAIlJjgP///J6A///sArCAABouAP//7jGwgAAmwwCAAEk/gP//7g9wAAazkoD//9qHMP//nVou Date: Thu, 30 Jan 2014 18:59:58 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se> <52EA7BED.4070007@alum.mit.edu>, <949EF20990823C4C85C18D59AA11AD8B126A78@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B126A78@FR712WXCHMBA11.zeu.alcatel-lucent.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+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvja7BwldBBl//slnsP3WZ2eJp41lG ixUbDrA6MHu0PtvL6vH3/QcmjyVLfjIFMEdx2aSk5mSWpRbp2yVwZUzrmc9acL+s4vGJggbG HyFdjJwcEgImEmubH7FA2GISF+6tZ+ti5OIQEjjEKPFp2QQmCGcxo8S/WdeBqjg42AQsJLr/ aYPERQRaGCUezrrBDNItLGAo8XvLMTBbRMBIYvfnVcwQRdMYJVrX7WADSbAIqErc6T8NZvMK uEncmnWEHWLDGnaJ67ungt3BKRAt0bvzBlgRI9BN30+tYQKxmQXEJW49mc8EcauAxJI955kh bFGJl4//sULU6EncmDqFDcLWlli28DUzxDJBiZMzn7BMYBSZhWTULCQts5C0zELSsoCRZRUj e25iZk56ueEmRmAsHNzyW3cH46lzIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAGDahf6rbyh1hARuOer+IjZmzfNoTcbOMxKNxEjXc6jo3/8mJPl+XlxrBoy38KnTh HvGVyvWf1nNkOq5UNltpp/DgPze/qNMvmZ8lE+9ltL7/ad5ywYTpcuLOy4Y9v5jWSFy8/F0v KuvPLE7/5w4z97t9Xfdgw9UABmnLU1zRHV8DjTflSuSXKrEUZyQaajEXFScCAB4CUhdTAgAA Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 19:00:08 -0000 ...and, I did suggest such criteria (reliable etc) at the virtual interim. Regards, Christer Sent from my Sony Ericsson Xperia arc S "DRAGE, Keith (Keith)" wrote: A protocol based on "(Reliable, ordered, message oriented)" transport will = be entirely different from one that is not. Therefore we should agree those requirements as a starting point. If we fail to do that, it means that every response that carries informatio= n will have to have its own response that does not carry data. We will need= to build retransmission into the protocol with timeouts. Etc. Regards Keith > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 30 January 2014 16:21 > To: clue@ietf.org > Subject: Re: [clue] RTCWEB data channel for CLUE? > > I agree with both Christer and Mary here. > > I think the *protocol* document should be independent of the > specific transport. But it must make some requirements on the > sort of transports it can work with. (Reliable, ordered, > message oriented) > > But we need for some other document (e.g. signaling) to fill > in the rest, so we have all the pieces necessary for > successful interoperation by two implementations. This must, > at least, specify how this will work when the session is > negotiated via SIP and SDP O/A. > > And Christer is working on the latter. > > A couple of pieces of the puzzle are: > - draft-ietf-mmusic-sctp-sdp > - draft-ietf-tsvwg-sctp-dtls-encaps > > and the things they reference. But that only gives raw SCTP streams. > > If we were doing this work without regard to RTCWEB, we might > stop there, and just specify how we choose SCTP streams for > our purpose. > > But in order to give us a chance at interoperating with > RTCWEB, we choose to also reuse > draft-ietf-rtcweb-data-channel. This puts another layer of > abstraction over SCTP, bonding pairs of unidirectional SCTP > streams into bidirectional Data Channels, and making SCTP > message attributes sticky for a channel. > > We wouldn't necessarily *need* that, but RTCWEB broswer apps > won't be able to directly access the lower layers, so we need > to follow that abstraction if we want to make it *possible* > for an rtcweb browser app to directly access our clue protocol. > > I guess we *could* define clue directly on > draft-ietf-rtcweb-data-channel, and simply be very careful to > define it in a way that coincidentally is interoperable with > how draft-ietf-rtcweb-data-channel uses SCTP. But IMO that is > a dangerous approach - very difficult to maintain consistency. > > So I think it is better that we reference > draft-ietf-rtcweb-data-channel. > > I agree that document has more rtcp-specifics than I would > like. What are out options about that? > 1) live with it > 2) encourage the authors of that document to structure it so that > the rtcweb specifics are clearly segregated from the more generic > parts > 3) work to factor that document into two separate documents, > one generic and one rtcweb specific. > > From our perspective, (3) would probably be best. I don't > know how feasible it is. We would probably need to volunteer > to do it, though perhaps we could recruit Richard Ejzak. > > Doing this *right* would probably mean moving the generic > document to another wg. (tsvwg?) I suspect that rtcweb might > object on the grounds that this would unnecessarily delay them. > > In the interest of expediency, I can live with (2), or > possibly even (1). > > Thanks, > Paul > > On 1/30/14 9:18 AM, Christer Holmberg wrote: > > Hi, > > > > I am sure we'll find a home for the text - the important > thing now is > > to agree on the mechanism, and to get the text written. > > > > Regards, > > > > Christer > > > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > *Sent:* 30. tammikuuta 2014 16:13 > > *To:* Christian Groves > > *Cc:* Christer Holmberg; Simon Pietro Romano; clue@ietf.org > > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > > > I think part of the debate here is whether any of the SCTP related > > stuff beyond what Simon has already noted is in the CLUE protocol > > document would be in the CLUE protocol document. I had envisioned > > that as Simon noted, the CLUE protocol itself is designed to be > > independent of the transport. We could add a reference to > a separate > > CLUE document that discusses the specifics of how CLUE uses > SCTP (and > > a note that other transports could also be used). That latter > > document could reference the RTCWEB and TSVWG documents (or > MMUSIC if that's what we decide). > > And, we already have that as a separate milestone. > > > > I think it's very important to decouple the protocol from > the transport. > > > > Mary. > > > > On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves > > > > > wrote: > > > > Hello, > > > > I think we need something in CLUE which says how it works with SCTP. > > There will be things we still need to do like registering a > > media-subtype "CLUE" (if that is still part of the SCTP SDP > draft) etc. > > I assume that wouldn't be done in RTCWEB. > > > > Regards, > > Christian > > > > > > > > On 30/01/2014 7:42 PM, Christer Holmberg wrote: > > > > > > Hi, > > > > We need to make assumptions on whether the transport provides > > reliability and in-order. When using "DTLS/SCTP/UDP", > those features > > are optional, as far as I know. > > > > Anyway, I am not saying that we haven't made such assumptions > > already - it was more a general comment when talking about the > > separation between protocol and transport. > > > > Regards, > > > > Christer > > > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > > ] > > *Sent:* 30. tammikuuta 2014 10:36 > > *To:* Christer Holmberg > > *Cc:* Mary Barnes; Christian Groves; clue@ietf.org > > > > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > > > > > > > Hi Christer, > > > > However, when we define the CLUE protocol state > machine, we DO > > need to make some assumptions about the transport, > e.g. whether it > > provides reliable transport, in-order transport > etc. If not, such > > mechanisms need to be implemented in the CLUE > protocol itself > > (similar to what is done in SIP with message > re-transmission, > > usage of CSeq etc). > > > > The CLUE protocol draft currently states the following: > > > > CLUE Participants are connected by means of the CLUE signaling > > channel. Such channel has been conceived as a > DTLS/SCTP/UDP > > channel > > > > in [I-D.kyzivat-clue-signaling > > > > > > vat-clue-signaling>] and it is established as depicted in > > > > > > the same document. CLUE protocol messages flow across such > > channel. > > > > We assume the > > DTLS/SCTP/UDP channel is established and define > the behiavior > > of the > > CLUE Participants communicating on it. We discuss > how the CLUE > > dialogue between them can be exploited to > successfully setup the > > telepresence session according to the principles > and concepts > > pointed > > > > out in in [I-D.ietf-clue-framework > > > I-D.ietf-clue-framework>]. > > > > > > > > Isn't this already enough? If not, what other assumptions do you > > think we should make? > > > > Thanks, > > > > Simon > > > > But, I strongly think that we shall decide on > **A** transport > > > > > > mechanism for the CLUE protocol. Otherwise we > won't even guarantee > > interoperability between CLUE entities. > > > > Regards, > > > > Christer > > > > *From:*Simon Pietro Romano [mailto:spromano@unina.it > > ] > > *Sent:*30. tammikuuta 2014 10:14 > > *To:*Christer Holmberg > > *Cc:*Mary Barnes; Christian Groves; clue@ietf.org > > > > > > > *Subject:*Re: [clue] RTCWEB data channel for CLUE? > > > > > > > > Hello folks, > > > > I might be perhaps too naif, but I have to admit I > don't see the > > point of discussion here. In my view, the CLUE protocol is > > independent from the underlying transport means. One of the > > potential transports (the best current option, IMHO) is the > > RtcWeb/WebRTC data channel. I think we should keep > on specifying > > CLUE protocol messages and state machines in the > CLUE protocol > > document. We might then write a document > illustrating how it is > > possible to seamlessly implement such a protocol > on top of the > > RtcWeb data channel. I am actually working on an individual > > contribution which basically illustrates the above > concepts, by > > also providing a couple of call flows. I also believe that > > Christer's proposal perfectly fits such an > approach. Should the WG > > decide that this option is worth exploring, I > would be glad to > > contribute. > > > > Cheers, > > > > Simon > > > > Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha > > scritto: > > > > > > > > > > Hi, > > > > > > > > Could we use this for CLUE without using > the rtcweb data > > channel mechanism? > > > > If we want to have interoperability with > rtcweb, we need > > to use the SCTP properties defined in the > rtcweb data > > channel draft. > > > > I have not heard, or identified myself, > any reason why > > that would be a problem for CLUE. > > > > [MB] I think the decision to be made by CLUE > needs to more > > importantly consider whether that approach > works for CLUE > > without RTCWEB. We > > > > discussed on the call that the RTCWEB WG > document (i.e., > > draft-ietf-rtcweb-data-channel/) could be > viewed as providing > > a more generic mechanism > > > > that can be used for applications beyond RTCWEB. > > > > > > Yes. The rtcweb data channel is designed so that > it works with > > JavaScript applications. But, as I said on the > call, there is > > nothing JavaScript specific about. Not even all rtcweb > > applications will be JavaScript based. > > > > > > > > That all said, as an individual, I don't see it to > be a tremendous > > amount of work to write a clue-data-channel > document that uses > > identical > > > > mechanisms but has content specific to CLUE. > For example, the > > generic aspects in the RTCWEB seem to be primarily > > limited to > > > > section 5 (just over 3 pages of text). Section > 4 has some > > generic aspects, but also some of it is RTCWEB > specific. And, > > section 3 is totally specific > > > > to RTCWEB. And, we need to decide how much of section 6 > > applies to CLUE.So, personally, I think CLUE > could just write > > their own document > > > > (and perhaps mention that procedures in > section blah are > > identical to those for RTCWEB OR write a > general document that > > both CLUE and > > > > RTCWEB can reference (although the doc would > have more boiler > > plate than content. Or perhaps, section 5 > could be folded > > into the > > > > tsvwg document (although I haven't looked at > that in detail to > > see if it would work). [/MB] > > > > > > We could for sure write our own document, > eventhough much would be > > copy/paste from the rtcweb document. > > > > However, even if we write our own document, > assuming we want > > interoperability, we would STILL have a dependency > on the rtcweb > > data channel, because that's where the SCTP PPID values are > > defined. > > > > I can try to put something together. > > > > Regards, > > > > Christer > > > > _\\|//_ > > > > ( O-O ) > > > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Simon Pietro Romano > > > > Universita' di Napoli Federico II > > > > Computer Engineering Department > > > > Phone: +39 081 7683823 > -- Fax: +39 > > 081 7683816 > > > > e-mail:spromano@unina.it > > > > > > > > > > > < > > > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > > > oooO > > > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > \ ( ( ) > > > > \_) ) / > > > > (_/ > > > > > > > > > > _\\|//_ > > > > ( O-O ) > > > > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Simon Pietro Romano > > > > Universita' di Napoli Federico II > > > > Computer Engineering Department > > > > Phone: +39 081 7683823 -- > Fax: +39 081 > > 7683816 > > > > e-mail: spromano@unina.it > > > > > > > > > > > < > > > idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > > > > oooO > > > > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > \ ( ( ) > > > > \_) ) / > > > > (_/ > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Thu Jan 30 11:06: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 78B3D1A044E for ; Thu, 30 Jan 2014 11:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 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_FONT_FACE_BAD=0.981, 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 39w6CDEg99Aq for ; Thu, 30 Jan 2014 11:06:24 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2569E1A044D for ; Thu, 30 Jan 2014 11:06:24 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id j1so7836259iga.2 for ; Thu, 30 Jan 2014 11:06:20 -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=XOxyz4WbGRNMgMAn5GP9DsjhWIBIIlZlbopKPLi1cUA=; b=LxlXIlbGbtlOWGvNFGYFmhS7DSDTbTUKaW7CLHQaU0FpRspSBNFAWI2EjmQK3lJh8V 6g40QhKcGOn5et9a1kbIWj+8LpMpjclL4xzvwrYkVluWdFm+Ul3Cx2ioWzE9z67y29/h DksCf7CDfpY7K3AAd4WiFPo3xLXlnkUNx1fE/BKcLNx7KLsZiDybRRiIBKKKhUCgarB/ 9HcEBV3NsxLehB8JLQ1gTgRM3+z/dGZlTKBlLEjSoRrZIX/bkg72hEblSg3ARAZFimja UtauRY+Xw9nQosh5EoBIvob1esFPLuS/NFkG6OO71Tr3PhUBLTCgC+hLW+sh27hgHLDR iYdQ== MIME-Version: 1.0 X-Received: by 10.42.141.193 with SMTP id p1mr2437463icu.61.1391108780754; Thu, 30 Jan 2014 11:06:20 -0800 (PST) Received: by 10.43.58.137 with HTTP; Thu, 30 Jan 2014 11:06:20 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B126A7D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D145B94@ESESSMB209.ericsson.se> <52E83D16.30400@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D148953@ESESSMB209.ericsson.se> <52E8B9CF.4040100@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D1490D4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14B7B3@ESESSMB209.ericsson.se> <13F7635F-54DE-4C00-ACD6-A8F6587DF369@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14B9D5@ESESSMB209.ericsson.se> <7C6F9A74-CF3F-4B1E-B2E9-0AE8A570BF88@unina.it> <7594FB04B1934943A5C02806D1A2204B1D14BA55@ESESSMB209.ericsson.se> <52EA2090.6040105@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D14D5F3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D14DEC6@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B126A7D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 30 Jan 2014 13:06:20 -0600 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=90e6ba6e869cb88ad404f134c0b6 Cc: "clue@ietf.org" Subject: Re: [clue] RTCWEB data channel for CLUE? 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, 30 Jan 2014 19:06:30 -0000 --90e6ba6e869cb88ad404f134c0b6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jan 30, 2014 at 11:47 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > I understand that Richard's document will need an additional set of > additional requirements to that which he has written for MSRP - see > > https://datatracker.ietf.org/doc/draft-ejzak-dispatch-msrp-data-channel/ > > Assuming we go that way, and I hope we do, it would be sensible to write > those requirements into whatever document defines setting up the transpor= t > for the CLUE protocol. > > I would envisage two documents: the CLUE protocol itself, and the documen= t > setting up the transport for the CLUE protocol. > [MB] Yes. And, we already have two separate milestones to reflect this. [/MB] > > regards > > Keith > > ------------------------------ > *From:* clue [mailto:clue-bounces@ietf.org] * On Behalf Of *Christer > Holmberg > *Sent:* 30 January 2014 16:24 > *To:* Mary Barnes > *Cc:* clue@ietf.org > > *Subject:* Re: [clue] RTCWEB data channel for CLUE? > > Hi, > > As far as I know, the only alternatives we have identified are: > > > 1. Whether or not to use the rtcweb data channel PROTOCOL > 2. Whether or not to use Richard's draft > > > Nobody has presented an alternative to the usage of the SCTP > capabilities (PPID values, reliability, etc) defined the rtcweb data > channel draft (whether we will use that draft as is, or write parts in ou= r > own document, is an editorial issue). > > Regards, > > Christer > > Sent from Windows Mail > > *From:* Mary Barnes > *Sent:* Thursday, January 30, 2014 6:12 PM > *To:* Hans-Christer Holmberg > *Cc:* Christian Groves , Simon Pietro > Romano , clue@ietf.org > > Sure. But, it's very important to keep in mind what we are talking about > when referring to other documents. > > I'm thinking the best way forward would be to put together a document > that list and evaluates all the alternatives versus diving in with the > assumption that we'll use the RTCWEB mechanism. Just to be clear, I'm n= ot > suggesting that's a document we progress, but I think it is important to > ensure that the WG considers all the options, pros/cons and applicability > of each before we start working out the details. > > Mary. > > > On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> I am sure we'll find a home for the text - the important thing now is to >> agree on the mechanism, and to get the text written. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> *Sent:* 30. tammikuuta 2014 16:13 >> *To:* Christian Groves >> *Cc:* Christer Holmberg; Simon Pietro Romano; clue@ietf.org >> *Subject:* Re: [clue] RTCWEB data channel for CLUE? >> >> >> >> I think part of the debate here is whether any of the SCTP related stuff >> beyond what Simon has already noted is in the CLUE protocol document wou= ld >> be in the CLUE protocol document. I had envisioned that as Simon noted, >> the CLUE protocol itself is designed to be independent of the transport. >> We could add a reference to a separate CLUE document that discusses the >> specifics of how CLUE uses SCTP (and a note that other transports could >> also be used). That latter document could reference the RTCWEB and TSVW= G >> documents (or MMUSIC if that's what we decide). And, we already have >> that as a separate milestone. >> >> >> >> I think it's very important to decouple the protocol from the transport. >> >> >> >> Mary. >> >> >> >> >> >> >> >> On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves < >> Christian.Groves@nteczone.com> wrote: >> >> Hello, >> >> I think we need something in CLUE which says how it works with SCTP. >> There will be things we still need to do like registering a media-subtyp= e >> "CLUE" (if that is still part of the SCTP SDP draft) etc. I assume that >> wouldn't be done in RTCWEB. >> >> Regards, >> Christian >> >> >> >> On 30/01/2014 7:42 PM, Christer Holmberg wrote: >> >> >> Hi, >> >> We need to make assumptions on whether the transport provides reliabilit= y >> and in-order. When using "DTLS/SCTP/UDP", those features are optional, a= s >> far as I know. >> >> Anyway, I am not saying that we haven't made such assumptions already - >> it was more a general comment when talking about the separation between >> protocol and transport. >> >> Regards, >> >> Christer >> >> *From:*Simon Pietro Romano [mailto:spromano@unina.it] >> *Sent:* 30. tammikuuta 2014 10:36 >> *To:* Christer Holmberg >> *Cc:* Mary Barnes; Christian Groves; clue@ietf.org >> *Subject:* Re: [clue] RTCWEB data channel for CLUE? >> >> >> >> Hi Christer, >> >> However, when we define the CLUE protocol state machine, we DO >> need to make some assumptions about the transport, e.g. whether it >> provides reliable transport, in-order transport etc. If not, such >> mechanisms need to be implemented in the CLUE protocol itself >> (similar to what is done in SIP with message re-transmission, >> usage of CSeq etc). >> >> The CLUE protocol draft currently states the following: >> >> CLUE Participants are connected by means of the CLUE signaling >> channel. Such channel has been conceived as a DTLS/SCTP/UDP channel >> >> in [I-D.kyzivat-clue-signaling < >> http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.kyzivat= -clue-signaling>] >> and it is established as depicted in >> >> >> the same document. CLUE protocol messages flow across such channel. >> >> We assume the >> DTLS/SCTP/UDP channel is established and define the behiavior of the >> CLUE Participants communicating on it. We discuss how the CLUE >> dialogue between them can be exploited to successfully setup the >> telepresence session according to the principles and concepts pointe= d >> >> out in in [I-D.ietf-clue-framework < >> http://tools.ietf.org/html/draft-presta-clue-protocol-03#ref-I-D.ietf-cl= ue-framework >> >]. >> >> >> >> Isn't this already enough? If not, what other assumptions do you think w= e >> should make? >> >> Thanks, >> >> Simon >> >> But, I strongly think that we shall decide on **A** transport >> >> >> mechanism for the CLUE protocol. Otherwise we won't even guarantee >> interoperability between CLUE entities. >> >> Regards, >> >> Christer >> >> *From:*Simon Pietro Romano [mailto:spromano@unina.it] >> *Sent:*30. tammikuuta 2014 10:14 >> *To:*Christer Holmberg >> *Cc:*Mary Barnes; Christian Groves; clue@ietf.org >> >> *Subject:*Re: [clue] RTCWEB data channel for CLUE? >> >> >> >> Hello folks, >> >> I might be perhaps too naif, but I have to admit I don't see the >> point of discussion here. In my view, the CLUE protocol is >> independent from the underlying transport means. One of the >> potential transports (the best current option, IMHO) is the >> RtcWeb/WebRTC data channel. I think we should keep on specifying >> CLUE protocol messages and state machines in the CLUE protocol >> document. We might then write a document illustrating how it is >> possible to seamlessly implement such a protocol on top of the >> RtcWeb data channel. I am actually working on an individual >> contribution which basically illustrates the above concepts, by >> also providing a couple of call flows. I also believe that >> Christer's proposal perfectly fits such an approach. Should the WG >> decide that this option is worth exploring, I would be glad to >> contribute. >> >> Cheers, >> >> Simon >> >> Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha scritto: >> >> >> >> >> Hi, >> >> >> >> Could we use this for CLUE without using the rtcweb data >> channel mechanism? >> >> If we want to have interoperability with rtcweb, we need >> to use the SCTP properties defined in the rtcweb data >> channel draft. >> >> I have not heard, or identified myself, any reason why >> that would be a problem for CLUE. >> >> [MB] I think the decision to be made by CLUE needs to more >> importantly consider whether that approach works for CLUE >> without RTCWEB. We >> >> discussed on the call that the RTCWEB WG document (i.e., >> draft-ietf-rtcweb-data-channel/) could be viewed as providing >> a more generic mechanism >> >> that can be used for applications beyond RTCWEB. >> >> >> Yes. The rtcweb data channel is designed so that it works with >> JavaScript applications. But, as I said on the call, there is >> nothing JavaScript specific about. Not even all rtcweb >> applications will be JavaScript based. >> >> >> >> That all said, as an individual, I don't see it to be a tremendous >> amount of work to write a clue-data-channel document that uses >> identical >> >> mechanisms but has content specific to CLUE. For example, the >> generic aspects in the RTCWEB seem to be primarily limited to >> >> section 5 (just over 3 pages of text). Section 4 has some >> generic aspects, but also some of it is RTCWEB specific. And, >> section 3 is totally specific >> >> to RTCWEB. And, we need to decide how much of section 6 >> applies to CLUE.So, personally, I think CLUE could just write >> their own document >> >> (and perhaps mention that procedures in section blah are >> identical to those for RTCWEB OR write a general document that >> both CLUE and >> >> RTCWEB can reference (although the doc would have more boiler >> plate than content. Or perhaps, section 5 could be folded into t= he >> >> tsvwg document (although I haven't looked at that in detail to >> see if it would work). [/MB] >> >> >> We could for sure write our own document, eventhough much would be >> copy/paste from the rtcweb document. >> >> However, even if we write our own document, assuming we want >> interoperability, we would STILL have a dependency on the rtcweb >> data channel, because that's where the SCTP PPID values are defined. >> >> I can try to put something together. >> >> Regards, >> >> Christer >> >> _\\|//_ >> >> ( O-O ) >> >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Simon Pietro Romano >> >> Universita' di Napoli Federico II >> >> Computer Engineering Department >> >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> >> e-mail:spromano@unina.it >> >> >> >> <> >> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> >> oooO >> >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> \ ( ( ) >> >> \_) ) / >> >> (_/ >> >> >> >> >> _\\|//_ >> >> ( O-O ) >> >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Simon Pietro Romano >> >> Universita' di Napoli Federico II >> >> Computer Engineering Department >> >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> >> e-mail: spromano@unina.it >> >> >> >> <> >> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> >> oooO >> >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> \ ( ( ) >> >> \_) ) / >> >> (_/ >> >> >> >> >> > > --90e6ba6e869cb88ad404f134c0b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 30, 2014 at 11:47 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
I understand = that Richard's document will need an additional set of additional requi= rements to that which he has written for MSRP - see
 
 
Assuming we g= o that way, and I hope we do, it would be sensible to write those requireme= nts into whatever document defines setting up the transport for the CLUE pr= otocol.
 
I would envis= age two documents: the CLUE protocol itself, and the document setting up th= e transport for the CLUE protocol.
[MB] Yes. And, we already have two separate milestones to reflect this. [/M= B] 
 
regards
 
Keith<= /span>

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 30 January 2014 16:24
To: Mary Barnes
Cc: clue@ietf.org=

Subject: Re: [clue] RTCWEB data channel for CLUE?

Hi,

As far as I know, the only alternatives we have identified are:

  1. Whether or not to use the rtcweb data channel PROTOCOL
  2. Whether or not to use Richard’s draft

Nobody has presented an alternative to the usage of the SCTP capabilities (= PPID values, reliability, etc) defined the rtcweb data channel draft (wheth= er we will use that draft as is, or write parts in our own document, is an = editorial issue).

Regards,

Christer

Sent from Windows Mail

From: Mary Barnes
Sent: Thursday, January 30, 2014 6:12 PM
To: Hans-Christer Holmberg
Cc: Christian Groves, Simon Pietro Romano<= /a>, clue@ietf.org

Sure. But, it's very important to keep in mind what we= are talking about when referring to other documents.  

I'm thinking the best way forward would be to put together a docum= ent that list and evaluates all the alternatives versus diving in with the = assumption that we'll use the RTCWEB mechanism.   Just to be clear= , I'm not suggesting that's a document we progress, but I think it is important to ensure that the WG considers all the option= s, pros/cons and applicability of each before we start working out the deta= ils. 

Mary.


On Thu, Jan 30, 2014 at 8:18 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,=

&nb= sp;

I am sure we’ll fi= nd a home for the text – the important thing now is to agree on the m= echanism, and to get the text written.

&nb= sp;

Regards,

&nb= sp;

Christer

&nb= sp;

From: Mary Barnes [mailto:= mary.ietf.b= arnes@gmail.com]
Sent: 30. tammikuuta 2014 16:13
To: Christian Groves
Cc: Christer Holmberg; Simon Pietro Romano; clue@ietf.org
Subject: Re: [clue] RTCWEB data channel for CLUE?

 

I think part of the debate here is whether any of th= e SCTP related stuff beyond what Simon has already noted is in the CLUE pro= tocol document would be in the CLUE protocol document.  I had envision= ed that as Simon noted, the CLUE protocol itself is designed to be independent of the transport.  We could add = a reference to a separate CLUE document that discusses the specifics of how= CLUE uses SCTP (and a note that other transports could also be used). &nbs= p;That latter document could reference the RTCWEB and TSVWG documents (or MMUSIC if that's what we decide).  = ;  And, we already have that as a separate milestone. <= /u>

 

I think it's very important to decouple the prot= ocol from the transport.

 

Mary. 

 

 

 

On Thu, Jan 30, 2014 at 3:51 AM, Christian Groves &l= t;Christ= ian.Groves@nteczone.com> wrote:

Hello,

I think we need something in CLUE which says how it works with SCTP. There = will be things we still need to do like registering a media-subtype "C= LUE" (if that is still part of the SCTP SDP draft) etc. I assume that = wouldn't be done in RTCWEB.

Regards,
Christian



On 30/01/2014 7:42 PM, Christer Holmberg wrote:


Hi,

We need to make assumptions on whether the transport provides reliability a= nd in-order. When using “DTLS/SCTP/UDP”, those features are opt= ional, as far as I know.

Anyway, I am not saying that we haven’t made such assumptions already= – it was more a general comment when talking about the separation be= tween protocol and transport.

Regards,

Christer

*From:*Simon Pietro Romano [mailto:spromano@unina.it]
*Sent:* 30. tammikuuta 2014 10:36
*To:* Christer Holmberg
*Cc:* Mary Barnes; Christian Groves; clue@ietf.org
*Subject:* Re: [clue] RTCWEB data channel for CLUE?



Hi Christer,

    However, when we define the CLUE protocol state machine, we D= O
    need to make some assumptions about the transport, e.g. wheth= er it
    provides reliable transport, in-order transport etc. If not, = such
    mechanisms need to be implemented in the CLUE protocol itself=
    (similar to what is done in SIP with message re-transmission,=
    usage of CSeq etc).

The CLUE protocol draft currently states the following:

CLUE Participants are connected by means of the CLUE signaling
    channel.  Such channel has been conceived as a DTLS/SCTP= /UDP channel

    in [I-D.kyzivat-clue-signaling  &= lt;http://tools.ietf.org/html/dr= aft-presta-clue-protocol-03#ref-I-D.kyzivat-clue-signaling>] and it is established as depicted in


    the same document.  CLUE protocol messages flow across s= uch channel.

We assume the
    DTLS/SCTP/UDP channel is established and define the behiavior= of the
    CLUE Participants communicating on it.  We discuss how t= he CLUE
    dialogue between them can be exploited to successfully setup = the
    telepresence session according to the principles and concepts= pointed

    out in in [I-D.ietf-clue-framework &nb= sp;<http://tools.ietf.org/html/d= raft-presta-clue-protocol-03#ref-I-D.ietf-clue-framework>].



Isn't this already enough? If not, what other assumptions do you think = we should make?

Thanks,

Simon

    But, I strongly think that we shall de= cide on **A** transport


    mechanism for the CLUE protocol. Otherwise we won’t eve= n guarantee
    interoperability between CLUE entities.

    Regards,

    Christer

    *From:*Simon Pietro Romano [mailto:spromano@unina.it]<= br>     *Sent:*30. tammikuuta 2014 10:14
    *To:*Christer Holmberg
    *Cc:*Mary Barnes; Christian Groves; clue@ietf.org
    <mailto:clue@ietf.org>
    *Subject:*Re: [clue] RTCWEB data channel for CLUE?<= /u>



    Hello folks,

    I might be perhaps too naif, but I have to admit I don't = see the
    point of discussion here. In my view, the CLUE protocol is     independent from the underlying transport means. One of the     potential transports (the best current option, IMHO) is the     RtcWeb/WebRTC data channel. I think we should keep on specify= ing
    CLUE protocol messages and state machines in the CLUE protoco= l
    document. We might then write a document illustrating how it = is
    possible to seamlessly implement such a protocol on top of th= e
    RtcWeb data channel. I am actually working on an individual     contribution which basically illustrates the above concepts, = by
    also providing a couple of call flows. I also believe that     Christer's proposal perfectly fits such an approach. Shou= ld the WG
    decide that this option is worth exploring, I would be glad t= o
    contribute.

    Cheers,

    Simon

    Il giorno 30/gen/2014, alle ore 08:34, Christer Holmberg ha s= critto:




    Hi,



            Could we use this for CLUE withou= t using the rtcweb data
            channel mechanism?

            If we want to have interoperabili= ty with rtcweb, we need
            to use the SCTP properties define= d in the rtcweb data
            channel draft.

            I have not heard, or identified m= yself, any reason why
            that would be a problem for CLUE.=

        [MB] I think the decision to be made by CLUE ne= eds to more
        importantly consider whether that approach work= s for CLUE
        without RTCWEB. We

        discussed on the call that the RTCWEB WG docume= nt (i.e.,
        draft-ietf-rtcweb-data-channel/) could be viewe= d as providing
        a more generic mechanism

        that can be used for applications beyond RTCWEB= .


    Yes. The rtcweb data channel is designed so that it works wit= h
    JavaScript applications. But, as I said on the call, there is=
    nothing JavaScript specific about. Not even all rtcweb
    applications will be JavaScript based.



    That all said, as an individual, I don't see it to be a t= remendous
    amount of work to write a clue-data-channel document that use= s
    identical

        mechanisms but has content specific to CLUE. Fo= r example, the
        generic aspects in the RTCWEB seem to be primar= ily limited to

        section 5 (just over 3 pages of text). Section = 4 has some
        generic aspects, but also some of it is RTCWEB = specific. And,
        section 3 is totally specific

        to RTCWEB. And, we need to decide how much of s= ection 6
        applies to CLUE.So, personally, I think CLUE co= uld just write
        their own document

        (and perhaps mention that procedures in section= blah are
        identical to those for RTCWEB OR write a genera= l document that
        both CLUE and

        RTCWEB can reference (although the doc would ha= ve more boiler
        plate than content. Or perhaps, section 5 could= be folded into the

        tsvwg document (although I haven't looked a= t that in detail to
        see if it would work). [/MB]


    We could for sure write our own document, eventhough much wou= ld be
    copy/paste from the rtcweb document.

    However, even if we write our own document, assuming we want<= br>     interoperability, we would STILL have a dependency on the rtc= web
    data channel, because that's where the SCTP PPID values a= re defined.

    I can try to put something together.

    Regards,

    Christer

    _\\|//_

    ( O-O )

    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
    Simon Pietro Romano

    Universita' di Napoli Federico II

    Computer Engineering Department

    Phone: +39 081 7683823 -- Fax: +39 081 7683816=

    e-mail:spromano@unina.it <mailto:spromano@unina.it>



    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi= degli

    idioti. Ci rifletto un istante; e mi scoraggio>>. Magri= tte.

    oooO

    ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
    \ ( ( )

    \_) ) /

    (_/




_\\|//_

( O-O )

~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

Simon Pietro Romano

Universita' di Napoli Federico II

Computer Engineering Department

Phone: +39 081 7683= 823 -- Fax: +39 081 7683816=

e-mail: spromano@unina.it <mailto:spromano@unina.it>



<<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli

idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.

oooO

~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

\ ( ( )

\_) ) /

(_/

 

 



--90e6ba6e869cb88ad404f134c0b6-- From georgehanes@hushmail.com Thu Jan 30 14:06: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 356051A04DA for ; Thu, 30 Jan 2014 14:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_NEUTRAL=0.112, 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 0bxDTwWfrDjh for ; Thu, 30 Jan 2014 14:06:22 -0800 (PST) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 080EA1A04B2 for ; Thu, 30 Jan 2014 14:06:22 -0800 (PST) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id BBDAD603F5 for ; Thu, 30 Jan 2014 22:06:18 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Thu, 30 Jan 2014 22:06:18 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 8783A6018A; Thu, 30 Jan 2014 22:06:18 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 30 Jan 2014 17:06:18 -0500 To: clue@ietf.org From: georgehanes@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20140130220618.8783A6018A@smtp.hushmail.com> Subject: [clue] Be cautious of this computer science conference 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, 30 Jan 2014 22:09:46 -0000 Be cautious of this computer science conference If you have any thought of attending the world’s biggest f-a-k-e conference in computer science http://www.world-academy-of-science.org you should visit any websites below https://sites.google.com/site/worlddump1 or https://sites.google.com/site/dumpconf https://sites.google.com/site/moneycomp1 https://sites.google.com/site/worlddump4 The organizer of this conference is H-amid A-rabnia http://www.cs.uga.edu/~hra a professor from University of Georgia, Athens, US. He already earned millions of dollars from the registration fee. He recently started a new conference CSCI due to his hunger for money http://www.americancse.org He did not reveal the reviews and reviewers' information for all the papers he received, despite repeated requests and challenges. The reason for his failure is there are no reviews and reviewers and he just cheated the research community for more than a decade by announcing that each draft paper is reviewed by two experts. We challenge him to publish these details at the conference website. Where are your experts? Where are your reviews? Soon he comes up with a story announcing that he lost all the information having reviews and reviewers because of computer crash or theft. DBLP stopped indexing these conferences since 2011 and displayed an explicit message; "The DBLP Advisory Board decided to discontinue indexing of this conference series". Visit http://www.informatik.uni-trier.de/~ley/db/conf/biocomp/index.html as a sample. He was forced to remove his name, the university of Georgia name, and university of Georgia email address from the conference’s contact page because the University has banned him from doing that. Do not spoil your resume by publishing in this conference. Apologies for posting to multiple mailing lists. Spreading the news is the only way to stop this conference from harming innocent researchers. Respectfully, Many researchers cheated by these conferences