From nobody Sun Nov 2 17:00: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 E1C021ACE7B for ; Sun, 2 Nov 2014 17:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgigs36GTsdo for ; Sun, 2 Nov 2014 17:00:07 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2421ACE7C for ; Sun, 2 Nov 2014 17:00:06 -0800 (PST) Received: from [210.97.169.119] (port=31312 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xl5zP-00015p-VC for clue@ietf.org; Mon, 03 Nov 2014 11:59:24 +1100 Message-ID: <5456D38D.7030806@nteczone.com> Date: Mon, 03 Nov 2014 11:59:57 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4D6739@ESESSMB209.ericsson.se> <54527C2A.7020404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4D6A7B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D6A7B@ESESSMB209.ericsson.se> 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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YLo45pouWFaAtUcGlvqinnmEH_k Subject: Re: [clue] CLUE agenda for IETF91 - CLUE data channel X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 01:00:09 -0000 Hello, >> What might be work discussing is what to do if it is done in time. >> Notably, would we require it to be signaled for CLUE, or would either way be valid? > I guess we will ANYWAY need the CLUE grouping attribute value, since we need to group the CLUE audio- and video m- lines. So, we CAN use it to indicate that the data channel is used for CLUE. > > But, I still think it would be good to have a general way for negotiating the data channel usages. Especially if someone also wants to use the data channel for something else than CLUE, I think it is bad to have different mechanisms for negotiating the usage. > > Having said that, NOT having such mechanism should of course not hold CLUE hostage. [CNG] I agree. Regards, Christian > > Regards, > > Christer > > > > >> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Simon Pietro >> Romano >> *Sent:* 30. lokakuuta 2014 9:35 >> *To:* Paul Kyzivat; CLUE >> *Subject:* Re: [clue] CLUE agenda for IETF91 >> >> Hi Paul, >> >> I think that a total of 1 hour is enough for presenting both the >> protocol and the data model drafts. >> >> Simon >> >> Il 29 ottobre 2014 19:51:04 CET, Paul Kyzivat > > ha scritto: >> >> You can find a very preliminary agenda for our CLUE sessions at IETF91: >> >> http://www.ietf.org/proceedings/91/agenda/agenda-91-clue >> >> I tried to prioritize those things that need the most work, and that >> have had recent action. >> >> Note that for now I gave no time to the call flows, because there have >> been no changes since the last meeting. >> >> For the RTP Mapping, who will be leading the discussion? Roni or Jonathan? >> >> I request that all authors/presenters please review this and consider >> how much time you can effectively use. We don't have enough >> discretionary time for followup, so if you don't need as much time as >> I allotted please let me know. >> >> And note that the agenda needs to be finalized by Monday, so I need >> your feedback before then. >> >> Thanks, >> Paul >> >> ---------------------------------------------------------------------- >> -- >> >> >> clue >> >> >> >> mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Nov 3 09:52: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 42F9F1A6F3A for ; Mon, 3 Nov 2014 09:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 dDPbR_SbQ3jR for ; Mon, 3 Nov 2014 09:52:13 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.107]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F441A6F3C for ; Mon, 3 Nov 2014 09:52:06 -0800 (PST) Received: from [216.82.254.20] by server-11.bemta-7.messagelabs.com id 32/D0-02706-6C0C7545; Mon, 03 Nov 2014 17:52:06 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-3.tower-47.messagelabs.com!1415037125!12973886!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26227 invoked from network); 3 Nov 2014 17:52:05 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-3.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 3 Nov 2014 17:52:05 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 3 Nov 2014 09:52:05 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Mon, 3 Nov 2014 09:52:02 -0800 Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: Ac/ySfVYoYzB8175ST2KrCTZKlyxLQFRJ2qg Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5EC7@CRPMBOXPRD08.polycom.com> References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> In-Reply-To: <544EE990.5060607@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/hixLu6aUWq4XHDV8mUSZ2MqmhSA Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 17:52:17 -0000 > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Monday, October 27, 2014 8:56 PM > To: clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 >=20 > Hello Roni, >=20 > As I mentioned in my original reply I think the RTP based simulcast > method is probably the cleanest approach. There would be nothing > stopping a CLUE endpoint implementing it when it becomes available (like > many other RTP features). Using CLUE for simulcast I think is possible > for most scenarios. The more complicated the scenarios the more > MCs/encodings an endpoint will need to describe the situation. >=20 > Please see my response below. >=20 > Regards, Christian >=20 > On 27/10/2014 9:20 PM, Roni Even wrote: > > Hi Paul, > > > > If we want to be able to differentiate between simulcast and switched > > capture, for example if we have a three camera system that can send thr= ee > > MCs each with two encodings (simulcast) and a switched capture (loudest > > speaker or two loudest speakers out of three) using the same simulcast > > option for the each MC currently sent. In this case we can have an MC w= ith > > two encodings and an MCC with the three MCs. This will require us to > clarify > > that having multiple individual encodings in MC is simulcast and not > > switched and in MCC it is switched and not simulcast. > [CNG] I don't understand exactly what the issue is here? Could you use > some pseudo syntax to explain what you're wanting to advertise? You say > in the first sentence the switched capture uses simulcast but then in > the last sentence you say the MCC is switched and not simulcast. I would > think that an MCC can still be switched and simulcast, i.e. the endpoint > simulcasts whatever source is switched into the media stream. > If you want a pure switched MCC just set maxCaptureEncodings to 1 > against the MCC. > If you want a simultcast MCC just set maxCaptureEncodings to >=3D2 agains= t > the MCC. [Duckworth, Mark] I agree with Christian. > > > > Now what may complicate the advertisement is if the individual MCs can > > simulcast two encodings while the MCC (switched) is only with one > encoding, > > this may require different MCs for MCC or individual MCs case. > [CNG] Probably. [Duckworth, Mark] I don't see any problem. I don't understand what "may re= quire different MCs for MCC or individual MCs case" means. > > As for the data model draft, the example > > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#sectio= n- > 26 > > may be confusing. > > It has for VC0, VC1 and VC2 > 2 > > while the EG0 has only three encID so if it was meant to support simulc= ast > > it will require six encID for Scene View SE1. > [CNG] Yes I think you're right. Its worth clarifying this. We could add > some text in the introduction of the example saying simulcast is used. > > > > Roni > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: 27 October, 2014 1:37 AM > >> To: Roni Even; clue@ietf.org > >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >> > >> On 10/26/14 6:00 PM, Roni Even wrote: > >>> Paul, > >>> How does the consumer know that he can configure an MC with two > >>> encodings, and which of the encodings are allowed to co-exist? > >> Look at the data model definition of a capture. It has a field > >> . That says how many simultaneous encodings of > the > >> capture are allowed. > >> > >> So, if the encoding group for the capture includes more than one > encoding, > > and > >> maxCaptureEncodings is greater than one, then the consumer can > configure > >> simulcast. > >> > >> Thanks, > >> Paul > >> > >> > >>> Roni > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>>> Sent: 26 October, 2014 11:34 PM > >>>> To: Roni Even; clue@ietf.org > >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>> > >>>> On 10/25/14 10:53 AM, Roni Even wrote: > >>>>> Hi Paul, > >>>>> Inline > >>>>> Roni > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyziva= t > >>>>>> Sent: 24 October, 2014 7:57 PM > >>>>>> To: clue@ietf.org > >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>> > >>>>>> I agree with Mark here. > >>>>>> > >>>>>> Consider a plausible use case in clue: > >>>>>> > >>>>>> The advertiser has a number of captures, and has a number of > > encoders. > >>>>>> It can create an encoding group with all the encoders in it - some > >>>>>> do > >>>>> hi-res > >>>>>> video, some do small videos. It puts all of those in an encoding > >>>>>> group and associates all the captures with that group. > >>>>>> > >>>>>> A "normal" consumer might configure a few of the captures with the > >>>>>> hi-res encodings, and some of the other captures with the small > >>>>>> encodings. There would be no simulcast in this case. > >>>>>> > >>>>>> Some other consumer (e.g., an MCC) may decide it wants one of the > >>>>>> captures in both big and small versions of one of the MCCs. It can > >>>>>> simply do an appropriate configuration and get that. Now we have > >>>>>> *simulcast*! The advertiser didn't have to do anything special - > >>>>>> didn't have to think about simulcast at all. > >>>>> [Roni Even] How does the consumer know that these MCs are > different > >>>>> potential encodings of the same source. > >>>>> Marks, suggested different encoding group for each encoding so he > >>>>> can advertise MC1 with ENC1 and ENC2, in this case the encoding > >>>>> groups will represent different encoding parameters but will need t= o > >>>>> be defined accordingly, for example one encoding group that has CIF > >>>>> resolutions and the other with only HD resolutions > >>>> This works when the advertisement assigns the capture to an encoding > >>>> group containing multiple encodings. When the consumer configures > the > >>>> same encoding twice, using different encodings from the encoding > >>>> group, then he knows - by definition - they are simulcasts. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>>> If an advertiser *wants* to use > >>>>>> draft-westerlund-avtcore-rtp-simulcast > >>>>>> then I see no reason to prevent that. But I would hate to force > >>>>>> that > >>>>> (especially > >>>>>> since it isn't approved yet). > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>>> On 10/24/14 9:47 AM, Duckworth, Mark wrote: > >>>>>>> Hello Roni and Christian, > >>>>>>> > >>>>>>> I believe CLUE already supports simulcast today, basically as > >>>>>>> Christian > >>>>>> describes. > >>>>>>> More below. > >>>>>>> > >>>>>>> (trying to use both the "correct indentation with > > symbols", > >>>>>>> and also marking comments with my name :-) > >>>>>>> > >>>>>>> Mark > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > >>>>>>>> Sent: Friday, October 24, 2014 8:19 AM > >>>>>>>> To: 'Christian Groves'; clue@ietf.org > >>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>>> > >>>>>>>> Hi Christian, > >>>>>>>> Inline > >>>>>>>> Roni > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > Christian > >>>>>>>>> Groves > >>>>>>>>> Sent: 24 October, 2014 4:59 AM > >>>>>>>>> To: clue@ietf.org > >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>>>> > >>>>>>>>> Hello Roni, > >>>>>>>>> > >>>>>>>>> Supporting draft-westerlund-avtcore-rtp-simulcast-04 > >>>>>>>>> simulca > >>>>>>>>> st > >>>>>>>>> -0 > >>>>>>>>> 4> seems like the most straight forward approach as it keeps > >>>>>>>>> 4> things > >>>>>>>>> at the encoding level, which is really where simulcast belongs. > >>>>>>> [Duckworth, Mark] Does CLUE really need to say anything about > this? > >>>>>>> Isn't this separate from CLUE, and can be used with CLUE without > >>>>>>> any further specification in CLUE documents? > >>>>>>> > >>>>>>>>> For a CLUE based solution I don't think we need to revert to > MCCs. > >>>>>>>>> The purpose of simulcast is to provide different encoding > >>>>>>>>> options for a particular media stream. A media provider can > >>>>>>>>> Advertise a MC > >>>>> with > >>>>>> multiple encoding groups. > >>>>>>>>> A media consumer if it wants to receive multiple encodings for > >>>>>>>>> the same MC can simply choose multiple capture encodings e.g. > >>>>>>>>> MC1/Encoding1 > >>>>>>>>> MC1/Encoding2 etc. > >>>>>>> [Duckworth, Mark] Yes, a media provider can support multiple > >>>>>>> encodings for the same MC, and a consumer can choose to > configure > >>>>>>> multiple encodings for the same MC. You don't even need multiple > >>>>>>> encoding groups to do this, you can do it with just one group tha= t > >>>>>>> contains > >>>>> multiple > >>>>>> encodings. > >>>>>>>> [Roni Even] How does the media consumer know that these are > >>>>>>>> alternatives of a simulcast stream and know how many can be > used > >>>>>>>> at the > >>>>>> same time. > >>>>>>> [Duckworth, Mark] By the MC attribute "max capture encodings". > >>>>>>> Any encodings in the MC's encoding groups can be configured for a > >>>>>>> particular MC, simultaneously, up to the value of "max capture > >>>>> encodings". > >>>>>>>> You also lose here the option of the total BW that is an encodin= g > >>>>>>>> group > >>>>>> attribute. > >>>>>>> [Duckworth, Mark] You can still use that by advertising an MC wit= h > >>>>>>> a single encoding group, with multiple encodings in the group. > >>>>>>> > >>>>>>>> All these means that we need some changes to CLUE and we can > look > >>>>>>>> at what will make the best solution using MCs or MMCs. > >>>>>>> [Duckworth, Mark] I believe we don't need any changes in CLUE, al= l > >>>>>>> this is already supported. > >>>>>>> > >>>>>>>> Still the question is if we say that we will use the SDP based > >>>>>>>> solution even though it is not a WG draft, having it as a > >>>>>>>> normative reference will delay the publication of the CLUE draft > >>>>>>>> > >>>>>>>>> Regards, Christian > >>>>>>>>> > >>>>>>>>> On 22/10/2014 8:00 AM, Roni Even wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> During our weekly design team meeting we discussed simulcast > >>>>>>>>>> support in CLUE. > >>>>>>>>>> > >>>>>>>>>> Here is my take on the options, my description may not be > >>>>>>>>>> accurate and the purpose here is to continue the discussion > >>>>>>>>>> allowing us to have a better view of the options. > >>>>>>>>>> > >>>>>>>>>> Looking at the state of simulcast support in other WGs, there > >>>>>>>>>> is an individual draft > >>>>>>>>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp- > simulca > >>>>>>>>>> st > >>>>>>>>>> -0 > >>>>>>>>>> 4 that being discussed. The proposed solution is based on the > >>>>>>>>>> unified plan where all encoded streams composing alternatives > >>>>>>>>>> of a simulcast stream are in the same m-line. The alternatives > >>>>>>>>>> are described using an SDP media level attribute "a=3Dsimulcas= t". > >>>>>>>>>> This attribute is not defined for SDP session level. > >>>>>>>>>> > >>>>>>>>>> The first question we had is if we should base CLUE simulcast > >>>>>>>>>> support on this individual draft based on CLUE timeline or try > >>>>>>>>>> to define a different multicast solution at the CLUE protocol > > level. > >>>>>>>>>> If we base our solution on the avtcore-rtp-simulcast-04 > >>>>>>>>>> document the advertisement will include an individual > encoding > >>>>>>>>>> that will relate to optional multiple simulcast encoding and > >>>>>>>>>> the configure will select such encoding. The actual number of > >>>>>>>>>> different stream that will compose the simulcast stream will b= e > >>>>>>>>>> negotiated using Offer/Answer as described in the above > >>>>>>>>>> document. The risk here is that this is an individual draft an= d > >>>>>>>>>> we may need to review the CLUE support if it changes. The > >>>>>>>>>> advantage is that we will have simulcast the same for CLUE and > > non- > >> CLUE systems. > >>>>>>>>>> The other option for simulcast support in the CLUE protocol ca= n > >>>>>>>>>> be based on having separate Media Capture for each of the > >>>>>>>>>> different simulcast encoding and use MCC to compose the > >>>>>>>>>> simulcast > >>>> alternatives. > >>>>>>>>>> We will need some way to escribe that this MCC is for simulcas= t > >>>>>>>>>> description and to provide the actual allowed individual > >>>>>>>>>> encodes combinations for the Configuration by the consumer. > >>>>>>>>>> > >>>>>>>>>> Thanks > >>>>>>>>>> > >>>>>>>>>> Roni > >>>>>>> _______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>> > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Nov 3 10:06: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 B66771A6F97 for ; Mon, 3 Nov 2014 10:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 aZPUaeRlfEwp for ; Mon, 3 Nov 2014 10:06:02 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D181A6F98 for ; Mon, 3 Nov 2014 10:06:02 -0800 (PST) Received: from localhost ([::1]:47039 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XlM0r-0007OM-Nk; Mon, 03 Nov 2014 10:05:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mark.duckworth@polycom.com X-Trac-Project: clue Date: Mon, 03 Nov 2014 18:05:57 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/clue/trac/ticket/59#comment:1 Message-ID: <083.6b4a9311623d89e62a6b552d685bd213@trac.tools.ietf.org> References: <068.68e1b44c0cae081c4b73d44c305e51c3@trac.tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <068.68e1b44c0cae081c4b73d44c305e51c3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mark.duckworth@polycom.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/clue/tukghykITbdoT38MlS0yGBPg_tM Cc: clue@ietf.org Subject: Re: [clue] #59 (framework): Action: Change "Capture Scene Entry (CSE)" to "Capture Scene View (CSV)" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 18:06:03 -0000 #59: Action: Change "Capture Scene Entry (CSE)" to "Capture Scene View (CSV)" Changes (by mark.duckworth@polycom.com): * status: new => closed * resolution: => fixed Comment: Fixed in framework-17 -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | framework@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From nobody Mon Nov 3 10:09: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 ABC0A1A6F8D for ; Mon, 3 Nov 2014 10:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 CP7Fjkd93rdK for ; Mon, 3 Nov 2014 10:09:37 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E6E1A0235 for ; Mon, 3 Nov 2014 10:09:37 -0800 (PST) Received: from localhost ([::1]:47173 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XlM4M-0008EC-Ft; Mon, 03 Nov 2014 10:09:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mark.duckworth@polycom.com X-Trac-Project: clue Date: Mon, 03 Nov 2014 18:09:34 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/60#comment:1 Message-ID: <083.60a8e65a7a5b2e6ed2b8efed094a3a2e@trac.tools.ietf.org> References: <068.3182f6990e1b9d765b6cc65d7a1eeb65@trac.tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <068.3182f6990e1b9d765b6cc65d7a1eeb65@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mark.duckworth@polycom.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qEltLqldx3Q9KRx9GMhqXJze_sY Cc: clue@ietf.org Subject: Re: [clue] #60 (framework): Action: Change "Global CSE List" to "Global View List" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 18:09:43 -0000 #60: Action: Change "Global CSE List" to "Global View List" Changes (by mark.duckworth@polycom.com): * status: new => closed * resolution: => fixed Comment: Fixed in framework-17 -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | framework@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From nobody Mon Nov 3 10:10: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 3B1DC1A6FC8 for ; Mon, 3 Nov 2014 10:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 XgU3AXp9QFMh for ; Mon, 3 Nov 2014 10:10:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744F51A6FC7 for ; Mon, 3 Nov 2014 10:10:47 -0800 (PST) Received: from localhost ([::1]:47254 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XlM5V-0000Fi-3J; Mon, 03 Nov 2014 10:10:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mark.duckworth@polycom.com X-Trac-Project: clue Date: Mon, 03 Nov 2014 18:10:45 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/61#comment:2 Message-ID: <083.7e679f42f57170e54bc6c468a7a9b74a@trac.tools.ietf.org> References: <068.6fe8b0dfa8729360fcce47d730f265da@trac.tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <068.6fe8b0dfa8729360fcce47d730f265da@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mark.duckworth@polycom.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/clue/KQjLcDAz00U2l1RY8oii4xkOjnA Cc: clue@ietf.org Subject: Re: [clue] #61 (framework): Action: Proposal for describing the coordinate system X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 18:10:49 -0000 #61: Action: Proposal for describing the coordinate system Changes (by mark.duckworth@polycom.com): * status: new => closed * resolution: => fixed Comment: Fixed in framework-17 -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | framework@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From nobody Mon Nov 3 14:52: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 323F61A1A83 for ; Mon, 3 Nov 2014 14:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.354 X-Spam-Level: * X-Spam-Status: No, score=1.354 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, FRT_BELOW2=2.154, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 6iIeJWhDFYHs for ; Mon, 3 Nov 2014 14:52:05 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415011A8795 for ; Mon, 3 Nov 2014 14:52:04 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so7891635wiv.7 for ; Mon, 03 Nov 2014 14:52:02 -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=5EuyTkTDgNKUCGZGIfQsL+X0YiKqIG9S7MPbjAumkgU=; b=KOs2zfPMK+a+bC0yPySNc0zKzW7Jyfg3QdW+80dso1MAPK+5NQF6kIOYYsTcuSxvzh hA4kCPIAOCcUXz/jlroAyhtDtFzqwWMfjb6NbrYFiOkKrqJNG+X6DRzqntugwrzb0Aqh siRnlavxIZWfa3uDs2EswTnFUarZ7qY4FtmGST/spfcpfwuW9uqaiV9lCtDrWoYvUSO3 PZ4iwE85xgq3e2Wp1tm0urOEXLC2VRsnIcgA7pCF7zA4pNBaSbXxYhYuLjcbGZxCDuAT +5YBYoktbAnBS+qlDp+aXhfH3pYur6L+gDXMLESDEZCgustYQefzk8uYW3qzbOsYZrjQ nk1A== X-Received: by 10.194.94.132 with SMTP id dc4mr52961563wjb.56.1415055122879; Mon, 03 Nov 2014 14:52:02 -0800 (PST) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id x13sm3460127wjw.18.2014.11.03.14.52.00 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Nov 2014 14:52:01 -0800 (PST) From: "Roni Even" To: "'Christian Groves'" , References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> In-Reply-To: <544EE990.5060607@nteczone.com> Date: Tue, 4 Nov 2014 00:51:55 +0200 Message-ID: <0cab01cff7b8$c616cd60$52446820$@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: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczEwHhC5T4AsgMzZABSFF3zwGQAdjcm5E06BA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/AjyLiHRs2fKnCZb3W3AlTAzwy_c Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 22:52:08 -0000 > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 28 October, 2014 2:56 AM > To: clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > Hello Roni, > > As I mentioned in my original reply I think the RTP based simulcast method is > probably the cleanest approach. There would be nothing stopping a CLUE > endpoint implementing it when it becomes available (like many other RTP > features). Using CLUE for simulcast I think is possible for most scenarios. The > more complicated the scenarios the more MCs/encodings an endpoint will > need to describe the situation. > > Please see my response below. > > Regards, Christian > > On 27/10/2014 9:20 PM, Roni Even wrote: > > Hi Paul, > > > > If we want to be able to differentiate between simulcast and switched > > capture, for example if we have a three camera system that can send > > three MCs each with two encodings (simulcast) and a switched capture > > (loudest speaker or two loudest speakers out of three) using the same > > simulcast option for the each MC currently sent. In this case we can > > have an MC with two encodings and an MCC with the three MCs. This will > > require us to clarify that having multiple individual encodings in MC > > is simulcast and not switched and in MCC it is switched and not simulcast. > [CNG] I don't understand exactly what the issue is here? Could you use some > pseudo syntax to explain what you're wanting to advertise? You say in the first > sentence the switched capture uses simulcast but then in the last sentence you > say the MCC is switched and not simulcast. I would think that an MCC can still > be switched and simulcast, i.e. the endpoint simulcasts whatever source is > switched into the media stream. > If you want a pure switched MCC just set maxCaptureEncodings to 1 against the > MCC. > If you want a simultcast MCC just set maxCaptureEncodings to >=2 against the > MCC. [Roni Even] The thing is that I am not sure how to advertise this example. The advertisement has two scene views: 1. Scene view with VC0, VC1, VC2 each with two simulcast streams 2. Scene view MCC3 as represented bellow The different MCs will be: VC0- (the left camera stream), encoding group=EG0, view=table, MaxCaptures=2 VC1- (the center camera stream), encoding group=EG0, view=table, MaxCaptures=2 VC2- (the right camera stream), encoding group=EG0, view=table. MaxCaptures=2 MCC3 (VC0, VC1, VC2) - encoding group=EG0, view=room, MaxCaptures=2 Now it may be implied here that VC0, VC1, VC2 are simulcast. What about MCC3? Is it multicast from one of the cameras or is it 2 MCs out of the three? (I assume it is the first since the view is room) What if in the above example MaxCaptures=4 can it be for example VC0, VC1 each with two simulcast streams or is it VC0, VC1, VC2 and one of them is simulcast? What I am trying to say is that using implied simulcast require text explaining when a consumer can understand that the advertisement is simulcast and not something else. The other approach may be to have an attribute for an MC and MCC that will explicitly say that this is a simulcast offer. BTW: I think that the implied solution works when the individual encodings are the same (spatial or different codces) what if we the provider can send H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four different encodings but not all combinations allowed. How to represent it in an advertisement? Is it : VC0- (the left camera stream), encoding group=EG0, view=table, MaxCaptures=2 VC1- (the center camera stream), encoding group=EG0, view=table, MaxCaptures=2 VC2- (the right camera stream), encoding group=EG0, view=table. MaxCaptures=2 VC3- (the left camera stream), encoding group=EG1, view=table, MaxCaptures=2 VC4- (the center camera stream), encoding group=EG1, view=table, MaxCaptures=2 VC5- (the right camera stream), encoding group=EG1, view=table. MaxCaptures=2 Where EG0 will be for H.264 and EG1 will be for VP8 and two scene views (VC0,VC1,VC2) (VC3, VC4, VC5)? > > > > Now what may complicate the advertisement is if the individual MCs can > > simulcast two encodings while the MCC (switched) is only with one > > encoding, this may require different MCs for MCC or individual MCs case. > [CNG] Probably. > > > > As for the data model draft, the example > > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#secti > > on-26 > > may be confusing. > > It has for VC0, VC1 and VC2 > > 2 > > while the EG0 has only three encID so if it was meant to support > > simulcast it will require six encID for Scene View SE1. > [CNG] Yes I think you're right. Its worth clarifying this. We could add some text > in the introduction of the example saying simulcast is used. > > > > Roni > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: 27 October, 2014 1:37 AM > >> To: Roni Even; clue@ietf.org > >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >> > >> On 10/26/14 6:00 PM, Roni Even wrote: > >>> Paul, > >>> How does the consumer know that he can configure an MC with two > >>> encodings, and which of the encodings are allowed to co-exist? > >> Look at the data model definition of a capture. It has a field > >> . That says how many simultaneous encodings of > >> the capture are allowed. > >> > >> So, if the encoding group for the capture includes more than one > >> encoding, > > and > >> maxCaptureEncodings is greater than one, then the consumer can > >> configure simulcast. > >> > >> Thanks, > >> Paul > >> > >> > >>> Roni > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>>> Sent: 26 October, 2014 11:34 PM > >>>> To: Roni Even; clue@ietf.org > >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>> > >>>> On 10/25/14 10:53 AM, Roni Even wrote: > >>>>> Hi Paul, > >>>>> Inline > >>>>> Roni > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul > >>>>>> Kyzivat > >>>>>> Sent: 24 October, 2014 7:57 PM > >>>>>> To: clue@ietf.org > >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>> > >>>>>> I agree with Mark here. > >>>>>> > >>>>>> Consider a plausible use case in clue: > >>>>>> > >>>>>> The advertiser has a number of captures, and has a number of > > encoders. > >>>>>> It can create an encoding group with all the encoders in it - > >>>>>> some do > >>>>> hi-res > >>>>>> video, some do small videos. It puts all of those in an encoding > >>>>>> group and associates all the captures with that group. > >>>>>> > >>>>>> A "normal" consumer might configure a few of the captures with > >>>>>> the hi-res encodings, and some of the other captures with the > >>>>>> small encodings. There would be no simulcast in this case. > >>>>>> > >>>>>> Some other consumer (e.g., an MCC) may decide it wants one of the > >>>>>> captures in both big and small versions of one of the MCCs. It > >>>>>> can simply do an appropriate configuration and get that. Now we > >>>>>> have *simulcast*! The advertiser didn't have to do anything > >>>>>> special - didn't have to think about simulcast at all. > >>>>> [Roni Even] How does the consumer know that these MCs are > >>>>> different potential encodings of the same source. > >>>>> Marks, suggested different encoding group for each encoding so he > >>>>> can advertise MC1 with ENC1 and ENC2, in this case the encoding > >>>>> groups will represent different encoding parameters but will need > >>>>> to be defined accordingly, for example one encoding group that has > >>>>> CIF resolutions and the other with only HD resolutions > >>>> This works when the advertisement assigns the capture to an > >>>> encoding group containing multiple encodings. When the consumer > >>>> configures the same encoding twice, using different encodings from > >>>> the encoding group, then he knows - by definition - they are simulcasts. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>>> If an advertiser *wants* to use > >>>>>> draft-westerlund-avtcore-rtp-simulcast > >>>>>> then I see no reason to prevent that. But I would hate to force > >>>>>> that > >>>>> (especially > >>>>>> since it isn't approved yet). > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>>> On 10/24/14 9:47 AM, Duckworth, Mark wrote: > >>>>>>> Hello Roni and Christian, > >>>>>>> > >>>>>>> I believe CLUE already supports simulcast today, basically as > >>>>>>> Christian > >>>>>> describes. > >>>>>>> More below. > >>>>>>> > >>>>>>> (trying to use both the "correct indentation with > > symbols", > >>>>>>> and also marking comments with my name :-) > >>>>>>> > >>>>>>> Mark > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni > >>>>>>>> Even > >>>>>>>> Sent: Friday, October 24, 2014 8:19 AM > >>>>>>>> To: 'Christian Groves'; clue@ietf.org > >>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>>> > >>>>>>>> Hi Christian, > >>>>>>>> Inline > >>>>>>>> Roni > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > >>>>>>>>> Christian Groves > >>>>>>>>> Sent: 24 October, 2014 4:59 AM > >>>>>>>>> To: clue@ietf.org > >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>>>> > >>>>>>>>> Hello Roni, > >>>>>>>>> > >>>>>>>>> Supporting draft-westerlund-avtcore-rtp-simulcast-04 > >>>>>>>>> >>>>>>>>> ca > >>>>>>>>> st > >>>>>>>>> -0 > >>>>>>>>> 4> seems like the most straight forward approach as it keeps > >>>>>>>>> 4> things > >>>>>>>>> at the encoding level, which is really where simulcast belongs. > >>>>>>> [Duckworth, Mark] Does CLUE really need to say anything about this? > >>>>>>> Isn't this separate from CLUE, and can be used with CLUE without > >>>>>>> any further specification in CLUE documents? > >>>>>>> > >>>>>>>>> For a CLUE based solution I don't think we need to revert to MCCs. > >>>>>>>>> The purpose of simulcast is to provide different encoding > >>>>>>>>> options for a particular media stream. A media provider can > >>>>>>>>> Advertise a MC > >>>>> with > >>>>>> multiple encoding groups. > >>>>>>>>> A media consumer if it wants to receive multiple encodings for > >>>>>>>>> the same MC can simply choose multiple capture encodings e.g. > >>>>>>>>> MC1/Encoding1 > >>>>>>>>> MC1/Encoding2 etc. > >>>>>>> [Duckworth, Mark] Yes, a media provider can support multiple > >>>>>>> encodings for the same MC, and a consumer can choose to > >>>>>>> configure multiple encodings for the same MC. You don't even > >>>>>>> need multiple encoding groups to do this, you can do it with > >>>>>>> just one group that contains > >>>>> multiple > >>>>>> encodings. > >>>>>>>> [Roni Even] How does the media consumer know that these are > >>>>>>>> alternatives of a simulcast stream and know how many can be > >>>>>>>> used at the > >>>>>> same time. > >>>>>>> [Duckworth, Mark] By the MC attribute "max capture encodings". > >>>>>>> Any encodings in the MC's encoding groups can be configured for > >>>>>>> a particular MC, simultaneously, up to the value of "max capture > >>>>> encodings". > >>>>>>>> You also lose here the option of the total BW that is an > >>>>>>>> encoding group > >>>>>> attribute. > >>>>>>> [Duckworth, Mark] You can still use that by advertising an MC > >>>>>>> with a single encoding group, with multiple encodings in the group. > >>>>>>> > >>>>>>>> All these means that we need some changes to CLUE and we can > >>>>>>>> look at what will make the best solution using MCs or MMCs. > >>>>>>> [Duckworth, Mark] I believe we don't need any changes in CLUE, > >>>>>>> all this is already supported. > >>>>>>> > >>>>>>>> Still the question is if we say that we will use the SDP based > >>>>>>>> solution even though it is not a WG draft, having it as a > >>>>>>>> normative reference will delay the publication of the CLUE > >>>>>>>> draft > >>>>>>>> > >>>>>>>>> Regards, Christian > >>>>>>>>> > >>>>>>>>> On 22/10/2014 8:00 AM, Roni Even wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> During our weekly design team meeting we discussed simulcast > >>>>>>>>>> support in CLUE. > >>>>>>>>>> > >>>>>>>>>> Here is my take on the options, my description may not be > >>>>>>>>>> accurate and the purpose here is to continue the discussion > >>>>>>>>>> allowing us to have a better view of the options. > >>>>>>>>>> > >>>>>>>>>> Looking at the state of simulcast support in other WGs, there > >>>>>>>>>> is an individual draft > >>>>>>>>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simul > >>>>>>>>>> ca > >>>>>>>>>> st > >>>>>>>>>> -0 > >>>>>>>>>> 4 that being discussed. The proposed solution is based on the > >>>>>>>>>> unified plan where all encoded streams composing alternatives > >>>>>>>>>> of a simulcast stream are in the same m-line. The > >>>>>>>>>> alternatives are described using an SDP media level attribute > "a=simulcast". > >>>>>>>>>> This attribute is not defined for SDP session level. > >>>>>>>>>> > >>>>>>>>>> The first question we had is if we should base CLUE simulcast > >>>>>>>>>> support on this individual draft based on CLUE timeline or > >>>>>>>>>> try to define a different multicast solution at the CLUE > >>>>>>>>>> protocol > > level. > >>>>>>>>>> If we base our solution on the avtcore-rtp-simulcast-04 > >>>>>>>>>> document the advertisement will include an individual > >>>>>>>>>> encoding that will relate to optional multiple simulcast > >>>>>>>>>> encoding and the configure will select such encoding. The > >>>>>>>>>> actual number of different stream that will compose the > >>>>>>>>>> simulcast stream will be negotiated using Offer/Answer as > >>>>>>>>>> described in the above document. The risk here is that this > >>>>>>>>>> is an individual draft and we may need to review the CLUE > >>>>>>>>>> support if it changes. The advantage is that we will have > >>>>>>>>>> simulcast the same for CLUE and > > non- > >> CLUE systems. > >>>>>>>>>> The other option for simulcast support in the CLUE protocol > >>>>>>>>>> can be based on having separate Media Capture for each of the > >>>>>>>>>> different simulcast encoding and use MCC to compose the > >>>>>>>>>> simulcast > >>>> alternatives. > >>>>>>>>>> We will need some way to escribe that this MCC is for > >>>>>>>>>> simulcast description and to provide the actual allowed > >>>>>>>>>> individual encodes combinations for the Configuration by the > consumer. > >>>>>>>>>> > >>>>>>>>>> Thanks > >>>>>>>>>> > >>>>>>>>>> Roni > >>>>>>> _______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>> > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Nov 3 19:52: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 47A3C1A6EE9 for ; Mon, 3 Nov 2014 19:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.752 X-Spam-Level: X-Spam-Status: No, score=0.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 83r1TXfbY2h2 for ; Mon, 3 Nov 2014 19:52:17 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.105]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E871A6EDA for ; Mon, 3 Nov 2014 19:52:17 -0800 (PST) Received: from [216.82.254.19] by server-9.bemta-7.messagelabs.com id F8/DA-02953-17D48545; Tue, 04 Nov 2014 03:52:17 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-12.tower-96.messagelabs.com!1415073136!14391947!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4289 invoked from network); 4 Nov 2014 03:52:16 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-12.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 4 Nov 2014 03:52:16 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 3 Nov 2014 19:52:16 -0800 From: "Duckworth, Mark" To: Roni Even , 'Christian Groves' , "clue@ietf.org" Date: Mon, 3 Nov 2014 19:52:13 -0800 Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczEwHhC5T4AsgMzZABSFF3zwGQAdjcm5E06BCAAFmhgA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> In-Reply-To: <0cab01cff7b8$c616cd60$52446820$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/NrFLIkL0UiYtDwTWMQO2VIRAX3I Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 03:52:19 -0000 > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > Sent: Monday, November 03, 2014 5:52 PM > To: 'Christian Groves'; clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 >=20 > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > > Sent: 28 October, 2014 2:56 AM > > To: clue@ietf.org > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > Hello Roni, > > > > As I mentioned in my original reply I think the RTP based simulcast met= hod > is > > probably the cleanest approach. There would be nothing stopping a CLUE > > endpoint implementing it when it becomes available (like many other RTP > > features). Using CLUE for simulcast I think is possible for most > scenarios. The > > more complicated the scenarios the more MCs/encodings an endpoint will > > need to describe the situation. > > > > Please see my response below. > > > > Regards, Christian > > > > On 27/10/2014 9:20 PM, Roni Even wrote: > > > Hi Paul, > > > > > > If we want to be able to differentiate between simulcast and switched > > > capture, for example if we have a three camera system that can send > > > three MCs each with two encodings (simulcast) and a switched capture > > > (loudest speaker or two loudest speakers out of three) using the same > > > simulcast option for the each MC currently sent. In this case we can > > > have an MC with two encodings and an MCC with the three MCs. This wil= l > > > require us to clarify that having multiple individual encodings in MC > > > is simulcast and not switched and in MCC it is switched and not simul= cast. > > [CNG] I don't understand exactly what the issue is here? Could you use = some > > pseudo syntax to explain what you're wanting to advertise? You say in t= he first > > sentence the switched capture uses simulcast but then in the last sente= nce you > > say the MCC is switched and not simulcast. I would think that an MCC ca= n still > > be switched and simulcast, i.e. the endpoint simulcasts whatever source= is > > switched into the media stream. > > If you want a pure switched MCC just set maxCaptureEncodings to 1 again= st the > > MCC. > > If you want a simultcast MCC just set maxCaptureEncodings to >=3D2 agai= nst the > > MCC. >=20 > [Roni Even] The thing is that I am not sure how to advertise this example= . >=20 > The advertisement has two scene views: > 1. Scene view with VC0, VC1, VC2 each with two simulcast streams > 2. Scene view MCC3 as represented bellow >=20 > The different MCs will be: >=20 > VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, > MaxCaptures=3D2 [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture Encodings"= ? Don't confuse this with the MCC attribute MaxCaptures which means "Max numb= er of Captures within a MCC". > VC1- (the center camera stream), encoding group=3DEG0, view=3Dtable, > MaxCaptures=3D2 >=20 > VC2- (the right camera stream), encoding group=3DEG0, view=3Dtable. > MaxCaptures=3D2 >=20 > MCC3 (VC0, VC1, VC2) - encoding group=3DEG0, view=3Droom, MaxCapture= s=3D2 [Duckworth, Mark] It isn't clear if you really mean "max capture encodings"= or "max number of captures within a MCC". Those are two different things. > Now it may be implied here that VC0, VC1, VC2 are simulcast. [Duckworth, Mark] It depends how the consumer configures it. The provider = advertisement says it supports simulcast, so the consumer can decide to use it or not. > What about MCC3? > Is it multicast from one of the cameras or is it 2 MCs out of the three? = (I > assume it is the first since the view is room) [Duckworth, Mark] MCC3 can provide 2 MCs out of the three simultaneously on= ly if it is composed, not if it is switched. The provider can give more information, if it wants= to, with the MCC attribute "max number of captures within a MCC". > What if in the above example MaxCaptures=3D4 can it be for example VC0, = VC1 > each with two simulcast streams or is it VC0, VC1, VC2 and one of them is= simulcast? [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" capture= . It sounds like you are talking about a switched case, not a composed case, = so=20 let's say MCC3 has the attribute "max number of captures within a MCC" =3D = 1. Now let's also suppose MCC3 has "max capture encodings" =3D 2. Then the co= nsumer can ask for, say, MCC3 at 720p and SIF, for the two encodings. Then the pr= ovider decides when to switch among VC0, VC1, and VC2, and whichever one the provi= der is sending for MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast = at those two resolutions. =20 > What I am trying to say is that using implied simulcast require text > explaining when a consumer can understand that the advertisement is > simulcast and not something else. > The other approach may be to have an attribute for an MC and MCC that wil= l > explicitly say that this is a simulcast offer. [Duckworth, Mark] I think the advertisement is clear to the consumer withou= t any additional text or attributes added to the framework. It is already ex= plicit, with the attribute "max capture encodings". If it is >1, then the advertis= ement is offering simulcast. > BTW: I think that the implied solution works when the individual encoding= s > are the same (spatial or different codces) what if we the provider can se= nd > H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four differen= t > encodings but not all combinations allowed. How to represent it in an > advertisement? Is it : [Duckworth, Mark] I can consider this case after we get the first case above cleared up. > VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, > MaxCaptures=3D2 >=20 > VC1- (the center camera stream), encoding group=3DEG0, view=3Dtable, > MaxCaptures=3D2 >=20 > VC2- (the right camera stream), encoding group=3DEG0, view=3Dtable. > MaxCaptures=3D2 >=20 > VC3- (the left camera stream), encoding group=3DEG1, view=3Dtable, > MaxCaptures=3D2 >=20 > VC4- (the center camera stream), encoding group=3DEG1, view=3Dtable, > MaxCaptures=3D2 >=20 > VC5- (the right camera stream), encoding group=3DEG1, view=3Dtable. > MaxCaptures=3D2 >=20 > Where EG0 will be for H.264 and EG1 will be for VP8 and two scene views > (VC0,VC1,VC2) (VC3, VC4, VC5)? >=20 ... snip ... From nobody Wed Nov 5 08:00: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 D98D61A8A4D for ; Wed, 5 Nov 2014 08:00: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 0HgpeO0C6WSK for ; Wed, 5 Nov 2014 08:00:35 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7421A899A for ; Wed, 5 Nov 2014 08:00:35 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-09v.sys.comcast.net with comcast id Bs0W1p0034ueUHc01s0aHl; Wed, 05 Nov 2014 16:00:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-03v.sys.comcast.net with comcast id Bs0a1p0093Ge9ey01s0acG; Wed, 05 Nov 2014 16:00:34 +0000 Message-ID: <545A49A2.5020203@alum.mit.edu> Date: Wed, 05 Nov 2014 11:00:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.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=q20140121; t=1415203234; bh=9LD4KFujdGgb0SOXxCmTXsTXKW8SRfVVgwE9ogaiOX4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iPIwSwqbkjRIosrWCQJ33WaKTlCshvcj/UtJ0IfIw4U/JyUwY1/zhvwyYVEiwEs5s EFrophjj8YDMK/usAQOTlubmBS+nNAMq5BmqrLvbBALh2CJTbXzWvtGUTIfmb1MZ19 HVSmcJDX56+wY2zSWyf4JBb5y2sZDZnCIsJatQz1nXz+Ikb/wkfinCefWvcTgQE5gW HSRfxrVxMphMqoHlVdjBL/8cTBRctltgoMKhliJw9IktbunDPEkki2MD76UAkY32ua c4s9AN583kcVLSOgF2kdkMP5YvSE5Xap32mjehZWsZ7vn7l/N26V/ec8pxrAPQvz6T DEetYPDc2KHjw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/TUZGcI7DDC8gYzCsiRjX7t-xlio Subject: [clue] clue dinner in Honolulu? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 16:00:36 -0000 Do people want to have a CLUE dinner in Honolulu? If so, does anyone have suggestions of where? (As you may have noticed, I'm not very good at organizing dinners.) Thanks, Paul From nobody Wed Nov 5 10:05: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 A3FD31A907C for ; Wed, 5 Nov 2014 10:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ2iFV0dVZAq for ; Wed, 5 Nov 2014 10:05:07 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75081A1A59 for ; Wed, 5 Nov 2014 10:05:06 -0800 (PST) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-08v.sys.comcast.net with comcast id Bu541p0015FMDhs01u56Ex; Wed, 05 Nov 2014 18:05:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id Bu551p00L3Ge9ey01u55Lf; Wed, 05 Nov 2014 18:05:06 +0000 Message-ID: <545A66D1.40009@alum.mit.edu> Date: Wed, 05 Nov 2014 13:05:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.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=q20140121; t=1415210706; bh=y0DWWr7Z6aovJdNhbvWIQNGC/Teht9JzroSfNJIeqD0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PC+h++qmw/XhratwB+52pVg/Bgh6uDaJMnjMStrRY/zp2FBhU4PNf4OydxWQXpA6t PyQufnJmRGWRSYU4Y8pA1Af7hIEDKNmHa/snGYSCvw+FMKsBhinyaISrl1OyQXmqRZ 16CBdUFvySMmfdtNQoiJ5bGzccwlTfMJlgQFBVEShuAic0UeMib4fnedNH7VXvuw+c VUc/Uhhx3dwFRfI4VsFvj6KY4vtDsJe6u/N8KE1GZfJRcXmI/M94sbyFsB5AUG1VEK FoUmkmABam4ZVls1uorYiQCdIzAggOihxvb7gMpRYGoLtsOjKUtieyRWbNdtrZFOk/ aemiMRQEmsYwg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/mHa9XUi9EuhLjicmPnYRJ3BiZuE Subject: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 18:05:10 -0000 To avoid a delay in the meetings while we seek note takers, who will volunteer to take notes in Honolulu? - note taker, Wed - jabber scribe, Wed - note taker, Fri - jabber scribe, Fri As a reward to note takers, I will give you a "get out of note-taking jail" card for non-clue sessions. (Of course these are non-binding on other chairs.) Thanks, Paul From nobody Wed Nov 5 10:32: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 6F3971A90F8 for ; Wed, 5 Nov 2014 10:32:42 -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 3xjp7d1I-B6X for ; Wed, 5 Nov 2014 10:32:41 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181A91A914E for ; Wed, 5 Nov 2014 10:32:18 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-07v.sys.comcast.net with comcast id BuWF1p00957bBgG01uYJMy; Wed, 05 Nov 2014 18:32:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-13v.sys.comcast.net with comcast id BuYJ1p0013Ge9ey01uYJaQ; Wed, 05 Nov 2014 18:32:18 +0000 Message-ID: <545A6D30.7050807@alum.mit.edu> Date: Wed, 05 Nov 2014 13:32:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <545A66D1.40009@alum.mit.edu> In-Reply-To: <545A66D1.40009@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=q20140121; t=1415212338; bh=zp0pqRvnIqYCaH+6NCDhzERkQ4aLc2p5NoDkE44mIPY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RK9KJmomqdKhNNTV2WUQTDjamOXI7V/DMVqCwzrI9EG7d/aWfiP7q/7rxLbtV60vh bW0iL0Em7OFKFs5SD6qR26spnhFXjWsztkR1UumLo4lCiDxzRS1PkVOTR/agKaPV+x 351kda8ay2fswASc8AmkPsy2kPXVNx7ByRQCCK8F1dAOVze19wVY2RM8lKSASE+EXU AxZUVAvcwoGKH4hI4ct/kdPVsYBR8rew1XgWyPsCLc1z4im4rSF67Pma7MGJUy37Ly F0/Xh3s9fJ/SNkRBiGU/j8gg1iUJZ1Hg1V/JRCsDn2WqAJ6oHIh9goCtvC+8+RWnyM 4zs3uyQHweSLQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/bueRXJq_-b_DjgspM5zb8Yw1uEE Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 18:32:43 -0000 Updated. One down, three to go. Thanks, Paul On 11/5/14 1:05 PM, Paul Kyzivat wrote: > To avoid a delay in the meetings while we seek note takers, who will > volunteer to take notes in Honolulu? > > - note taker, Wed (Stephan Wenger has volunteered) > - jabber scribe, Wed > - note taker, Fri > - jabber scribe, Fri > > As a reward to note takers, I will give you a "get out of note-taking > jail" card for non-clue sessions. (Of course these are non-binding on > other chairs.) > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Nov 5 11:00: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 8C2DA1ABD3B for ; Wed, 5 Nov 2014 11:00:17 -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 k7ZhFAciaOMr for ; Wed, 5 Nov 2014 11:00:14 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0601A1B6B for ; Wed, 5 Nov 2014 11:00:13 -0800 (PST) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-03v.sys.comcast.net with comcast id Buzy1p0044vw8ds01v0DP8; Wed, 05 Nov 2014 19:00:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-04v.sys.comcast.net with comcast id Bv0C1p00M3Ge9ey01v0CSe; Wed, 05 Nov 2014 19:00:13 +0000 Message-ID: <545A73BC.2050400@alum.mit.edu> Date: Wed, 05 Nov 2014 14:00:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <545A66D1.40009@alum.mit.edu> In-Reply-To: <545A66D1.40009@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=q20140121; t=1415214013; bh=eU5FgnEdxxLNdRA0XCdHyYgx8y+Bp/BF58M6KQakFE8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=e2xHR9H3giijLS5A69TNxctUHi6NvxOdM554qridtWFlioCLbQ6PjbsDgzqacTRIM dDJP+jPB0HMetXt8qhawF9jKNJOBc3doexx7W8/Cz6ZyeqHsAYArqXNDJi2Osz0Vxy aE11mFY1O4Gr6X3thEu+MwLQdLNrZZ/fHvA63zcVrqIyUXtMNW8kc/5WvhQ9foNTGq dNWNAEv+vhw2LEpC2Tm8QEpPOZGEPr/P9s8dTQ9ncZVDhaDgt3vhgDhvQh8/qme2S1 034WQtGQEjnaxOs4oQVJ7Q6uTrGEG6oNGqL+id+TfjnPYh6k78HMtuKY9fsMtCt157 dqLVIGoR5F4DQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/V8Ju3McNs5ol31xtLDEMcJ3cZqk Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 19:00:17 -0000 I forgot that we aim to have two note takers at a time for redunancy. Wednesday Session: - Note taker 1: Stephan Wenger - Note taker 2: (volunteer needed) - Jabber scribe: (volunteer needed) Friday Session: - Note taker 1: (volunteer needed) - Note taker 2: (volunteer needed) - Jabber scribe: (volunteer needed) Thanks, Paul On 11/5/14 1:05 PM, Paul Kyzivat wrote: > To avoid a delay in the meetings while we seek note takers, who will > volunteer to take notes in Honolulu? > > - note taker, Wed > - jabber scribe, Wed > - note taker, Fri > - jabber scribe, Fri > > As a reward to note takers, I will give you a "get out of note-taking > jail" card for non-clue sessions. (Of course these are non-binding on > other chairs.) > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Nov 5 11:29: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 371451AC3EB for ; Wed, 5 Nov 2014 11:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 G8WahDOanSo7 for ; Wed, 5 Nov 2014 11:29:39 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017B71A6FB7 for ; Wed, 5 Nov 2014 11:29:38 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-56-545a7aa0498e Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7B.B7.04231.0AA7A545; Wed, 5 Nov 2014 20:29:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Wed, 5 Nov 2014 20:29:36 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Note takers for the CLUE sessions next week Thread-Index: AQHP+SMaeDaEXGhczkGl3H1cQGyOGpxSUmoAgAAY4BA= Date: Wed, 5 Nov 2014 19:29:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4E6E81@ESESSMB209.ericsson.se> References: <545A66D1.40009@alum.mit.edu> <545A73BC.2050400@alum.mit.edu> In-Reply-To: <545A73BC.2050400@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje6CqqgQg7M/jCz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj6vxHbAXHuSo+9z5ka2DcwtHFyMkhIWAi cX3SPyYIW0ziwr31bF2MXBxCAkcYJT4f+MQC4SxmlOhd9gXI4eBgE7CQ6P6nDdIgIuApsePj FGYQW1jAXmLTwYNMICUiAg4Sz+84Q5RYSazd0QDWySKgIjGvIxskzCvgK/HqSjsriC0ENKV9 wwUwm1NAR6L3whZ2EJsR6Jzvp9aAncYsIC5x68l8qDMFJJbsOc8MYYtKvHz8jxXCVpJYe3g7 C0S9jsSC3Z/YIGxtiWULXzND7BWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWF+em GxnrpRZlJhcX5+fp5aWWbGIExsjBLb91dzCufu14iFGAg1GJh3fDpMgQIdbEsuLK3EOM0hws SuK8i87NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA2G947v7v6osnL2lfvjDZx2pV8JOZ s/5/sLptphU/US7I7SubmEL+FQZu0xtnTSZM7DKqucT2Q3Eth9Of9k1Nys32nH2v4vadapu1 VO5w/sd7DcZBB+bnsLgL9xZoxr5a+OHN168f9a4qdVio2m+V+LBazbDiMydL9wXPE08Xnb0h YnxaovNTtBJLcUaioRZzUXEiAKtJim5yAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Ro22MbMF_oU_VThGLyABXdbq6x0 Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 19:29:41 -0000 I can also take notes on Wednesday. Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 05 November 2014 21:00 To: clue@ietf.org Subject: Re: [clue] Note takers for the CLUE sessions next week I forgot that we aim to have two note takers at a time for redunancy. Wednesday Session: - Note taker 1: Stephan Wenger - Note taker 2: (volunteer needed) - Jabber scribe: (volunteer needed) Friday Session: - Note taker 1: (volunteer needed) - Note taker 2: (volunteer needed) - Jabber scribe: (volunteer needed) Thanks, Paul On 11/5/14 1:05 PM, Paul Kyzivat wrote: > To avoid a delay in the meetings while we seek note takers, who will=20 > volunteer to take notes in Honolulu? > > - note taker, Wed > - jabber scribe, Wed > - note taker, Fri > - jabber scribe, Fri > > As a reward to note takers, I will give you a "get out of note-taking=20 > jail" card for non-clue sessions. (Of course these are non-binding on=20 > other chairs.) > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Wed Nov 5 14:52: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 CBEDF1A010E for ; Wed, 5 Nov 2014 14:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 vzGbS4LlXu5M for ; Wed, 5 Nov 2014 14:52:53 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350B91A0111 for ; Wed, 5 Nov 2014 14:52:15 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-05v.sys.comcast.net with comcast id ByrG1p00357bBgG01ysE9t; Wed, 05 Nov 2014 22:52:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-13v.sys.comcast.net with comcast id BysD1p00F3Ge9ey01ysDNQ; Wed, 05 Nov 2014 22:52:14 +0000 Message-ID: <545AAA1D.9090001@alum.mit.edu> Date: Wed, 05 Nov 2014 17:52:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <545A66D1.40009@alum.mit.edu> In-Reply-To: <545A66D1.40009@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=q20140121; t=1415227934; bh=GlV+0g5j93E5qZ928Dyvc1V3vZl2toEdtvLXmCJ8Ms0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GQF12R92zEhfjsuRocqOULZMXTTXkiv9sBv15EBiCv6m7qpCs7PDCyl5Ulkvf/ixb cx3Nj0GBsUWY+TtOm/ijXPp2fBm5O3ZBC0Sl0GXrjwBmuTd4+FQvu/qmbpDroa8pi1 dwbZTMo8EbPjulQzGj3U4iT8iWnGbhwv/D9IwQCVOpddDm3boR3T/OgMQSxxgNf/tu EcWlyBRZN7S3r6azRH3UaPlHUuSxUodkenT3lvY2y1WUGEcl2KgohHebCOD5Ea5fL4 781S8ZL2MRPiLSEoUQ+K8qytfiIQFpRbweMUSg9tee1NWviNL6y8ISV+YKWFgZfC0P 7WtbsQbx/9Hrw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/WjJcqoeLEYsUcFmAio9RRmFItCo Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 22:52:54 -0000 Two down. Nobody yet for Friday. Wednesday Session: - Note taker 1: Stephan Wenger - Note taker 2: Christer Holmberg - Jabber scribe: (volunteer needed) Friday Session: - Note taker 1: (volunteer needed) - Note taker 2: (volunteer needed) - Jabber scribe: (volunteer needed) Thanks, Paul On 11/5/14 1:05 PM, Paul Kyzivat wrote: > To avoid a delay in the meetings while we seek note takers, who will > volunteer to take notes in Honolulu? > > - note taker, Wed > - jabber scribe, Wed > - note taker, Fri > - jabber scribe, Fri > > As a reward to note takers, I will give you a "get out of note-taking > jail" card for non-clue sessions. (Of course these are non-binding on > other chairs.) > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Thu Nov 6 04:36: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 25F5E1A1B79 for ; Thu, 6 Nov 2014 04:36:46 -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 MncDoEkKZZRH for ; Thu, 6 Nov 2014 04:36:39 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9171A1B72 for ; Thu, 6 Nov 2014 04:36:39 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so1069476wgg.5 for ; Thu, 06 Nov 2014 04:36:38 -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=WYtabPZxZx+NWLVfn56cuB00uLNPiic0/Opf5OzztIY=; b=xwZV4wS/PngI6Ni1ljvd1/ShjmTr/7caEEmT0MpfuB9OA04yfnbUrF6fcoiGRphIEN b8w2gfXBr+HByNokpjf0oqVsFWJTxwPkVj1gbumPykiaHXbrjbtbuvvr4sO9ELjYULxv KAMEJyr1hDwkwU7styl8Hp5ttm2bwjpa09rM9cSTwtszJkEEs0pi8c54aAEhyxZM8p4h tJjxeauG5upKONJ+2XUo6AnLJhwaAfRM+y+WDUrlSr4/Mf6bCtdROkjrp1TEWp8aU63y Vr2FUjwlZmcxX/jQlXcRYNESBjkKfU0vFZB9m50FAgVGzALrRHL7DGbOHnzyXdOymqXm ARkQ== X-Received: by 10.180.99.105 with SMTP id ep9mr14209629wib.82.1415277398300; Thu, 06 Nov 2014 04:36:38 -0800 (PST) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id cz3sm7662211wjb.23.2014.11.06.04.36.36 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Nov 2014 04:36:37 -0800 (PST) From: "Roni Even" To: "'Paul Kyzivat'" , "'CLUE'" References: <545A66D1.40009@alum.mit.edu> In-Reply-To: <545A66D1.40009@alum.mit.edu> Date: Thu, 6 Nov 2014 14:36:31 +0200 Message-ID: <0eec01cff9be$4c996ee0$e5cc4ca0$@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: AQDbW8FsSqc5Du66UFWGWwcVHj5XK548xI5Q Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/sHedqfl-Ykdjo-zsw2xZ2O3AgoU Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 12:36:46 -0000 Since we have volunteers for Wednesday, I can take notes on Friday (when not presenting - Call Flows?). Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 05 November, 2014 8:05 PM > To: CLUE > Subject: [clue] Note takers for the CLUE sessions next week > > To avoid a delay in the meetings while we seek note takers, who will volunteer > to take notes in Honolulu? > > - note taker, Wed > - jabber scribe, Wed > - note taker, Fri > - jabber scribe, Fri > > As a reward to note takers, I will give you a "get out of note-taking jail" card for > non-clue sessions. (Of course these are non-binding on other chairs.) > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Nov 6 10:31: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 8ECA21A8990 for ; Thu, 6 Nov 2014 10:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 xpp02PTFFjwI for ; Thu, 6 Nov 2014 10:31:37 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A111A899B for ; Thu, 6 Nov 2014 10:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1167; q=dns/txt; s=iport; t=1415298697; x=1416508297; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=dt792lwG8s3b8m+Ne3XxlpYUFVFsbQ3CKPT/+8Ws6Zg=; b=Nd1ReVs3/ppRsmJCjPMdrtggxjDRloylr2GVx1Wzrlfxe/BAD4D2SLZ3 MYn2HPx40aW9tpW/n7Gzd/IZ6rTA+2j58HP9nPw46C0IYocwZ2qhhjgRY AzleCncEI2rB2Ni92ILxPb6awXjTrKC5QM1b15nxMaeKJ8i8SXNfsww8D Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIKAHy9W1StJssW/2dsb2JhbABbg2JZt2YFAXSSOwqHTgKBNgEBAQEBfYQCAQEBBAEBATU2Cg0ECxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAYg9Dc9SAQEBAQEBAQEBAQEBAQEBAQEBFgSGOIpgBhCENQEEnhSHdo5jg3g9L4JLAQEB X-IronPort-AV: E=Sophos;i="5.07,327,1413244800"; d="scan'208";a="236099014" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 06 Nov 2014 18:31:34 +0000 Received: from [10.47.200.91] ([10.47.200.91]) (authenticated bits=0) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sA6IVWwV015240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 6 Nov 2014 18:31:33 GMT Message-ID: <545BBE85.5020105@cisco.com> Date: Thu, 06 Nov 2014 18:31:33 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: clue@ietf.org References: <545A66D1.40009@alum.mit.edu> <0eec01cff9be$4c996ee0$e5cc4ca0$@gmail.com> In-Reply-To: <0eec01cff9be$4c996ee0$e5cc4ca0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: rohanse2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3-irpVgDYxerSfX6XMfyaJ1tx40 Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 18:31:39 -0000 I can be the second note taker on Friday, assuming we're still looking for two people. Rob On 06/11/14 12:36, Roni Even wrote: > Since we have volunteers for Wednesday, I can take notes on Friday (when not > presenting - Call Flows?). > Roni > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 05 November, 2014 8:05 PM >> To: CLUE >> Subject: [clue] Note takers for the CLUE sessions next week >> >> To avoid a delay in the meetings while we seek note takers, who will > volunteer >> to take notes in Honolulu? >> >> - note taker, Wed >> - jabber scribe, Wed >> - note taker, Fri >> - jabber scribe, Fri >> >> As a reward to note takers, I will give you a "get out of note-taking > jail" card for >> non-clue sessions. (Of course these are non-binding on other chairs.) >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Nov 6 11:33: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 918ED1A1B1D for ; Thu, 6 Nov 2014 11:33: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 FvKsIyBliILe for ; Thu, 6 Nov 2014 11:33:42 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4125E1A1B09 for ; Thu, 6 Nov 2014 11:33:42 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-02v.sys.comcast.net with comcast id CKXy1p0064tLnxL01KZhZW; Thu, 06 Nov 2014 19:33:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-02v.sys.comcast.net with comcast id CKZh1p0013Ge9ey01KZhWs; Thu, 06 Nov 2014 19:33:41 +0000 Message-ID: <545BCD1A.7060706@alum.mit.edu> Date: Thu, 06 Nov 2014 14:33:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <545A66D1.40009@alum.mit.edu> In-Reply-To: <545A66D1.40009@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=q20140121; t=1415302421; bh=c5q+c/BdSYjYrZnCAgedAbWl+2BJKUPEbLuetX9Iz9U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kgSArZesWXae4aHjq6fl3Kuy25SapsTCEVTozx12CLPzy2a1+uVUStiDmETfb4EYe MOauKr3ctlT+H3PkR/ugTmHoDKa76XRb/kleafu1tzlYGUW5dMPo8NFeIkwVXOON7y 0qMopoNarY0uAIDJhlAl4ACvgo6f5GgqvmX9rxrezRvwlZm2314D7/V8pP825M39Gf fg1N2aRtuN9PIGaVpvcidS0GUbI/ZVd/Xguhu6sXQZ996YhG/ixCyUDbLSSz7sOEHr eNSgIygfUbEBbQ8fHxa7h0ZpF4a/K0c7nPDHQ2V+h0A/t7VJJwiRdpUhHYBBBP/zl0 G8/IITSwuJzKA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/GCvXIAKFVWasWhU-s0HyNtr-n8M Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 19:33:44 -0000 OK. Now we have an excess for Friday. So I flipped a coin. Roni is on the agenda Friday, but Rob can cover that part. We still have no Jabber scribes. Jonathan - can you do it? Here is current status: Wednesday Session: - Note taker 1: Stephan Wenger - Note taker 2: Christian Groves - Jabber scribe: (volunteer needed) Friday Session: - Note taker 1: Rob Hansen - Note taker 2: Roni Even - Jabber scribe: (volunteer needed) Thanks, Paul On 11/5/14 1:05 PM, Paul Kyzivat wrote: > To avoid a delay in the meetings while we seek note takers, who will > volunteer to take notes in Honolulu? > > - note taker, Wed > - jabber scribe, Wed > - note taker, Fri > - jabber scribe, Fri > > As a reward to note takers, I will give you a "get out of note-taking > jail" card for non-clue sessions. (Of course these are non-binding on > other chairs.) > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Thu Nov 6 11:45: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 DC4E41A8A7B for ; Thu, 6 Nov 2014 11:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.852 X-Spam-Level: ** X-Spam-Status: No, score=2.852 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FRT_BELOW2=2.154, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 XkFK41wpqpfb for ; Thu, 6 Nov 2014 11:45:22 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F1C1A8A79 for ; Thu, 6 Nov 2014 11:45:21 -0800 (PST) Received: from [216.82.241.100] by server-5.bemta-8.messagelabs.com id 52/1B-17655-0DFCB545; Thu, 06 Nov 2014 19:45:20 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-10.tower-220.messagelabs.com!1415303119!13702127!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11114 invoked from network); 6 Nov 2014 19:45:20 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-10.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 6 Nov 2014 19:45:20 -0000 Received: from PWEHUB01.polycom.com (10.236.2.221) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 6 Nov 2014 11:45:19 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Thu, 6 Nov 2014 11:45:19 -0800 From: "Duckworth, Mark" To: Roni Even Date: Thu, 6 Nov 2014 11:45:17 -0800 Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczEwHhC5T4AsgMzZABSFF3zwGQAdjcm5E06BCAAFmhgIAEM+lA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.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 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/MY4pU-ECzkEj40ExgD4d63j1F4A Cc: "clue@ietf.org" Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 19:45:24 -0000 Hi Roni, Do you still have questions about the way simulcast is handled in the frame= work, regarding the attribute "Max capture encodings" and configuring multiple encodings per capture? I was hoping we could resolve it on the list, or do= you think we need to talk about it in Honolulu? Regards, Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark > Sent: Monday, November 03, 2014 10:52 PM > To: Roni Even; 'Christian Groves'; clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 >=20 > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > > Sent: Monday, November 03, 2014 5:52 PM > > To: 'Christian Groves'; clue@ietf.org > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > -----Original Message----- > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Grov= es > > > Sent: 28 October, 2014 2:56 AM > > > To: clue@ietf.org > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > Hello Roni, > > > > > > As I mentioned in my original reply I think the RTP based simulcast > method > > is > > > probably the cleanest approach. There would be nothing stopping a CLU= E > > > endpoint implementing it when it becomes available (like many other R= TP > > > features). Using CLUE for simulcast I think is possible for most > > scenarios. The > > > more complicated the scenarios the more MCs/encodings an endpoint > will > > > need to describe the situation. > > > > > > Please see my response below. > > > > > > Regards, Christian > > > > > > On 27/10/2014 9:20 PM, Roni Even wrote: > > > > Hi Paul, > > > > > > > > If we want to be able to differentiate between simulcast and switch= ed > > > > capture, for example if we have a three camera system that can send > > > > three MCs each with two encodings (simulcast) and a switched captur= e > > > > (loudest speaker or two loudest speakers out of three) using the sa= me > > > > simulcast option for the each MC currently sent. In this case we ca= n > > > > have an MC with two encodings and an MCC with the three MCs. This > will > > > > require us to clarify that having multiple individual encodings in = MC > > > > is simulcast and not switched and in MCC it is switched and not > simulcast. > > > [CNG] I don't understand exactly what the issue is here? Could you us= e > some > > > pseudo syntax to explain what you're wanting to advertise? You say in > the first > > > sentence the switched capture uses simulcast but then in the last > sentence you > > > say the MCC is switched and not simulcast. I would think that an MCC = can > still > > > be switched and simulcast, i.e. the endpoint simulcasts whatever sour= ce > is > > > switched into the media stream. > > > If you want a pure switched MCC just set maxCaptureEncodings to 1 > against the > > > MCC. > > > If you want a simultcast MCC just set maxCaptureEncodings to >=3D2 > against the > > > MCC. > > > > [Roni Even] The thing is that I am not sure how to advertise this examp= le. > > > > The advertisement has two scene views: > > 1. Scene view with VC0, VC1, VC2 each with two simulcast streams > > 2. Scene view MCC3 as represented bellow > > > > The different MCs will be: > > > > VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, > > MaxCaptures=3D2 >=20 > [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture > Encodings"? > Don't confuse this with the MCC attribute MaxCaptures which means "Max > number > of Captures within a MCC". >=20 > > VC1- (the center camera stream), encoding group=3DEG0, view=3Dtable, > > MaxCaptures=3D2 > > > > VC2- (the right camera stream), encoding group=3DEG0, view=3Dtable. > > MaxCaptures=3D2 > > > > MCC3 (VC0, VC1, VC2) - encoding group=3DEG0, view=3Droom, > MaxCaptures=3D2 >=20 > [Duckworth, Mark] It isn't clear if you really mean "max capture encoding= s" > or > "max number of captures within a MCC". Those are two different things. >=20 > > Now it may be implied here that VC0, VC1, VC2 are simulcast. >=20 > [Duckworth, Mark] It depends how the consumer configures it. The provide= r > advertisement > says it supports simulcast, so the consumer can decide to use it or not. >=20 > > What about MCC3? > > Is it multicast from one of the cameras or is it 2 MCs out of the three= ? (I > > assume it is the first since the view is room) >=20 > [Duckworth, Mark] MCC3 can provide 2 MCs out of the three simultaneously > only if it is composed, > not if it is switched. The provider can give more information, if it wan= ts to, > with the > MCC attribute "max number of captures within a MCC". >=20 > > What if in the above example MaxCaptures=3D4 can it be for example VC0= , > VC1 > > each with two simulcast streams or is it VC0, VC1, VC2 and one of them = is > simulcast? >=20 > [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" > capture. > It sounds like you are talking about a switched case, not a composed case= , so > let's say MCC3 has the attribute "max number of captures within a MCC" = =3D 1. > Now let's also suppose MCC3 has "max capture encodings" =3D 2. Then the > consumer > can ask for, say, MCC3 at 720p and SIF, for the two encodings. Then the > provider > decides when to switch among VC0, VC1, and VC2, and whichever one the > provider > is sending for MCC3 it sends it at both SIF and 720p, so MCC3 is simulcas= t at > those > two resolutions. >=20 > > What I am trying to say is that using implied simulcast require text > > explaining when a consumer can understand that the advertisement is > > simulcast and not something else. >=20 > > The other approach may be to have an attribute for an MC and MCC that > will > > explicitly say that this is a simulcast offer. >=20 > [Duckworth, Mark] I think the advertisement is clear to the consumer > without > any additional text or attributes added to the framework. It is already > explicit, > with the attribute "max capture encodings". If it is >1, then the > advertisement > is offering simulcast. >=20 > > BTW: I think that the implied solution works when the individual encodi= ngs > > are the same (spatial or different codces) what if we the provider can = send > > H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four differ= ent > > encodings but not all combinations allowed. How to represent it in an > > advertisement? Is it : >=20 > [Duckworth, Mark] I can consider this case after we get the first case > above cleared up. >=20 > > VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, > > MaxCaptures=3D2 > > > > VC1- (the center camera stream), encoding group=3DEG0, view=3Dtable, > > MaxCaptures=3D2 > > > > VC2- (the right camera stream), encoding group=3DEG0, view=3Dtable. > > MaxCaptures=3D2 > > > > VC3- (the left camera stream), encoding group=3DEG1, view=3Dtable, > > MaxCaptures=3D2 > > > > VC4- (the center camera stream), encoding group=3DEG1, view=3Dtable, > > MaxCaptures=3D2 > > > > VC5- (the right camera stream), encoding group=3DEG1, view=3Dtable. > > MaxCaptures=3D2 > > > > Where EG0 will be for H.264 and EG1 will be for VP8 and two scene views > > (VC0,VC1,VC2) (VC3, VC4, VC5)? > > > ... snip ... >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Nov 6 12:18: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 D3C941A0451 for ; Thu, 6 Nov 2014 12:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Uabf-JH3n8sf for ; Thu, 6 Nov 2014 12:18:27 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id E5A101A1A17 for ; Thu, 6 Nov 2014 12:18:26 -0800 (PST) Received: from compute03.cs.columbia.edu (compute03.cs.columbia.edu [128.59.11.33]) by mailbackend.panix.com (Postfix) with ESMTP id E58051376E; Thu, 6 Nov 2014 15:18:25 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21595.55185.413190.43161@compute03.cs.columbia.edu> Date: Thu, 6 Nov 2014 15:18:25 -0500 To: Paul Kyzivat In-Reply-To: <545BCD1A.7060706@alum.mit.edu> References: <545A66D1.40009@alum.mit.edu> <545BCD1A.7060706@alum.mit.edu> X-Mailer: VM 8.1.0 under 23.3.1 (x86_64-pc-linux-gnu) From: lennox@cs.columbia.edu Archived-At: http://mailarchive.ietf.org/arch/msg/clue/kCRQIi9fDKoOhJkRzhCYW4imqvA Cc: clue@ietf.org Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 20:18:29 -0000 I will be happy to Jabber scribe. On Thursday, November 6 2014, "Paul Kyzivat" wrote to "clue@ietf.org" saying: > OK. Now we have an excess for Friday. So I flipped a coin. > Roni is on the agenda Friday, but Rob can cover that part. > > We still have no Jabber scribes. Jonathan - can you do it? > > Here is current status: > > Wednesday Session: > > - Note taker 1: Stephan Wenger > - Note taker 2: Christian Groves > - Jabber scribe: (volunteer needed) > > Friday Session: > > - Note taker 1: Rob Hansen > - Note taker 2: Roni Even > - Jabber scribe: (volunteer needed) > > Thanks, > Paul > > On 11/5/14 1:05 PM, Paul Kyzivat wrote: > > To avoid a delay in the meetings while we seek note takers, who will > > volunteer to take notes in Honolulu? > > > > - note taker, Wed > > - jabber scribe, Wed > > - note taker, Fri > > - jabber scribe, Fri > > > > As a reward to note takers, I will give you a "get out of note-taking > > jail" card for non-clue sessions. (Of course these are non-binding on > > other chairs.) > > > > Thanks, > > Paul > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > -- Jonathan Lennox lennox@cs.columbia.edu From nobody Thu Nov 6 12:48:12 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802621A1A56 for ; Thu, 6 Nov 2014 12:48: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 ZPiLD79MRqBF for ; Thu, 6 Nov 2014 12:48:06 -0800 (PST) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D823E1A007D for ; Thu, 6 Nov 2014 12:48:04 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-06v.sys.comcast.net with comcast id CLmu1p00858ss0Y01Lo4Kw; Thu, 06 Nov 2014 20:48:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id CLo31p00P3Ge9ey01Lo3tm; Thu, 06 Nov 2014 20:48:04 +0000 Message-ID: <545BDE83.9040903@alum.mit.edu> Date: Thu, 06 Nov 2014 15:48:03 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lennox@cs.columbia.edu References: <545A66D1.40009@alum.mit.edu> <545BCD1A.7060706@alum.mit.edu> <21595.55185.413190.43161@compute03.cs.columbia.edu> In-Reply-To: <21595.55185.413190.43161@compute03.cs.columbia.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=q20140121; t=1415306884; bh=e4y24hJkkNFLM3ce6+bqOG99paVuGF6OQUU1VoXtWBs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bDmjdCS3KjtLz57IDcbDkzuxD/MwMuHEoILI8yzKa8Cp8aT9REXxdm2fgl1blAByl wECh6GWphHO5QxTO8enDpgSb+NPeKUvI1vUeGS1Mx6Xe3HXWw0tKOw6VNoY3LATzVZ 8STbuIHca7MIsQ1rY8eNJ7FXdXLxVuKW7thxzBCo7QW2UaU2Zq29T6osi17SbFzi2m /zuBUtBfWPnQ5cFzGXnwHwJy5//dE3PT/5CPbGgzwEMjDJn19Ie91SKji+T+MuVldt +/rWYE2WyzRGIz2f/POpvwDed1hz9lDMeKkiRxEJQJjCFy8f9SpANGCkXyYx5YxQtq C8C/oKlclQxEQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5Zg29jYKaTKQiZKoAPp7t1UwmMg Cc: clue@ietf.org Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 20:48:08 -0000 On 11/6/14 3:18 PM, lennox@cs.columbia.edu wrote: > I will be happy to Jabber scribe. I assume you are volunteering for both sessions? Then we are all set, and won't have to negotiate note takers or scribes during the meeting. Thanks to all who have volunteered! Thanks, Paul > On Thursday, November 6 2014, "Paul Kyzivat" wrote to "clue@ietf.org" saying: > >> OK. Now we have an excess for Friday. So I flipped a coin. >> Roni is on the agenda Friday, but Rob can cover that part. >> >> We still have no Jabber scribes. Jonathan - can you do it? >> >> Here is current status: >> >> Wednesday Session: >> >> - Note taker 1: Stephan Wenger >> - Note taker 2: Christian Groves >> - Jabber scribe: (volunteer needed) >> >> Friday Session: >> >> - Note taker 1: Rob Hansen >> - Note taker 2: Roni Even >> - Jabber scribe: (volunteer needed) >> >> Thanks, >> Paul >> >> On 11/5/14 1:05 PM, Paul Kyzivat wrote: >>> To avoid a delay in the meetings while we seek note takers, who will >>> volunteer to take notes in Honolulu? >>> >>> - note taker, Wed >>> - jabber scribe, Wed >>> - note taker, Fri >>> - jabber scribe, Fri >>> >>> As a reward to note takers, I will give you a "get out of note-taking >>> jail" card for non-clue sessions. (Of course these are non-binding on >>> other chairs.) >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > From nobody Thu Nov 6 13:58:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE431A90EE for ; Thu, 6 Nov 2014 13:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 QJX_pEQJjVUH for ; Thu, 6 Nov 2014 13:58:01 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id 63E5B1A9108 for ; Thu, 6 Nov 2014 13:58:01 -0800 (PST) Received: from compute03.cs.columbia.edu (compute03.cs.columbia.edu [128.59.11.33]) by mailbackend.panix.com (Postfix) with ESMTP id C5240136C6; Thu, 6 Nov 2014 16:58:00 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21595.61160.268214.643153@compute03.cs.columbia.edu> Date: Thu, 6 Nov 2014 16:58:00 -0500 To: Paul Kyzivat In-Reply-To: <545BDE83.9040903@alum.mit.edu> References: <545A66D1.40009@alum.mit.edu> <545BCD1A.7060706@alum.mit.edu> <21595.55185.413190.43161@compute03.cs.columbia.edu> <545BDE83.9040903@alum.mit.edu> X-Mailer: VM 8.1.0 under 23.3.1 (x86_64-pc-linux-gnu) From: lennox@cs.columbia.edu Archived-At: http://mailarchive.ietf.org/arch/msg/clue/MlHhYGoWwttLNfnYe8RXNq7WFxM Cc: clue@ietf.org Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 21:58:03 -0000 On Thursday, November 6 2014, "Paul Kyzivat" wrote to "lennox@cs.columbia.edu, clue@ietf.org" saying: > On 11/6/14 3:18 PM, lennox@cs.columbia.edu wrote: > > I will be happy to Jabber scribe. > > I assume you are volunteering for both sessions? Yes! > Then we are all set, and won't have to negotiate note takers or scribes > during the meeting. Thanks to all who have volunteered! > > Thanks, > Paul > > > On Thursday, November 6 2014, "Paul Kyzivat" wrote to "clue@ietf.org" saying: > > > >> OK. Now we have an excess for Friday. So I flipped a coin. > >> Roni is on the agenda Friday, but Rob can cover that part. > >> > >> We still have no Jabber scribes. Jonathan - can you do it? > >> > >> Here is current status: > >> > >> Wednesday Session: > >> > >> - Note taker 1: Stephan Wenger > >> - Note taker 2: Christian Groves > >> - Jabber scribe: (volunteer needed) > >> > >> Friday Session: > >> > >> - Note taker 1: Rob Hansen > >> - Note taker 2: Roni Even > >> - Jabber scribe: (volunteer needed) > >> > >> Thanks, > >> Paul > >> > >> On 11/5/14 1:05 PM, Paul Kyzivat wrote: > >>> To avoid a delay in the meetings while we seek note takers, who will > >>> volunteer to take notes in Honolulu? > >>> > >>> - note taker, Wed > >>> - jabber scribe, Wed > >>> - note taker, Fri > >>> - jabber scribe, Fri > >>> > >>> As a reward to note takers, I will give you a "get out of note-taking > >>> jail" card for non-clue sessions. (Of course these are non-binding on > >>> other chairs.) > >>> > >>> Thanks, > >>> Paul > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > -- Jonathan Lennox lennox@cs.columbia.edu From nobody Thu Nov 6 17:10: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 720ED1A19F9 for ; Thu, 6 Nov 2014 17:10: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 2oIUKJVFo7DC for ; Thu, 6 Nov 2014 17:10:08 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8277E1A0687 for ; Thu, 6 Nov 2014 17:10:08 -0800 (PST) Received: from [210.95.255.148] (port=16884 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XmY3j-0000Cn-L2 for clue@ietf.org; Fri, 07 Nov 2014 12:09:51 +1100 Message-ID: <545C1BE5.1090607@nteczone.com> Date: Fri, 07 Nov 2014 12:09:57 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <545A66D1.40009@alum.mit.edu> <545BCD1A.7060706@alum.mit.edu> In-Reply-To: <545BCD1A.7060706@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/2VHVxA5x0SteEQfTNbZbysxudxM Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 01:10:10 -0000 Hello Paul, It might be hard for me to be note taker 2 on Wednesday as i'll be in Australia. I think you meant Christer Holmberg Christian On 7/11/2014 6:33 AM, Paul Kyzivat wrote: > OK. Now we have an excess for Friday. So I flipped a coin. > Roni is on the agenda Friday, but Rob can cover that part. > > We still have no Jabber scribes. Jonathan - can you do it? > > Here is current status: > > Wednesday Session: > > - Note taker 1: Stephan Wenger > - Note taker 2: Christian Groves > - Jabber scribe: (volunteer needed) > > Friday Session: > > - Note taker 1: Rob Hansen > - Note taker 2: Roni Even > - Jabber scribe: (volunteer needed) > > Thanks, > Paul > > On 11/5/14 1:05 PM, Paul Kyzivat wrote: >> To avoid a delay in the meetings while we seek note takers, who will >> volunteer to take notes in Honolulu? >> >> - note taker, Wed >> - jabber scribe, Wed >> - note taker, Fri >> - jabber scribe, Fri >> >> As a reward to note takers, I will give you a "get out of note-taking >> jail" card for non-clue sessions. (Of course these are non-binding on >> other chairs.) >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Nov 6 18:43: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 695281A0053 for ; Thu, 6 Nov 2014 18:43: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 fOZeFM3JOaVm for ; Thu, 6 Nov 2014 18:43:38 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043B71A0037 for ; Thu, 6 Nov 2014 18:43:37 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-07v.sys.comcast.net with comcast id CSjP1p00752QWKC01SjdM7; Fri, 07 Nov 2014 02:43:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-09v.sys.comcast.net with comcast id CSjc1p00K3Ge9ey01Sjdy7; Fri, 07 Nov 2014 02:43:37 +0000 Message-ID: <545C31D8.8050605@alum.mit.edu> Date: Thu, 06 Nov 2014 21:43:36 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <545A66D1.40009@alum.mit.edu> In-Reply-To: <545A66D1.40009@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=q20140121; t=1415328217; bh=ihVGuSQ6+qN1kgJd1YzXcJ4u1iYGj/mYPh2rf77rG18=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IHb0e2Xr+F8h9LNU4012JMaH26P8B2rmoCD0S2WHRSpxXWihdqMJ69RtT0iKPWX3k MoQkkl/y6uixE9OxswfzjdoeKCUu2GAY/8kkY6JUjhHaJYkjIPaXaMYY8ijZf3VhE5 l45nNFwmvzR88Pes1H6j6/DX8ZVnyW7NyFW+bCCAqM3E7MVs7inHcUdSnqjTKh1WuS aMWshTi3mK/ibRpUS8mT6TGwlarMq9YaaourHluGZwRrxAtzkB5ZQnA94gNZ3GZQEF 9tVGpqaRX0Mqx+lU7rzzGw4yMOufOJ6t1nLBL63ZUONB/PYg9iARlW4/HUpxQu+M3p vKiEHVAHIGgzQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/jN16TPOsT2Z2uBfqrgsu1NO1020 Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 02:43:39 -0000 [corrected] OK. Now we have an excess for Friday. So I flipped a coin. Roni is on the agenda Friday, but Rob can cover that part. We still have no Jabber scribes. Jonathan - can you do it? Here is current status: Wednesday Session: - Note taker 1: Stephan Wenger - Note taker 2: Paul Coverdale - Jabber scribe: (volunteer needed) Friday Session: - Note taker 1: Rob Hansen - Note taker 2: Roni Even - Jabber scribe: (volunteer needed) Thanks, Paul On 11/5/14 1:05 PM, Paul Kyzivat wrote: > To avoid a delay in the meetings while we seek note takers, who will > volunteer to take notes in Honolulu? > > - note taker, Wed > - jabber scribe, Wed > - note taker, Fri > - jabber scribe, Fri > > As a reward to note takers, I will give you a "get out of note-taking > jail" card for non-clue sessions. (Of course these are non-binding on > other chairs.) > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Fri Nov 7 00:32: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 C2A061A1A9A for ; Fri, 7 Nov 2014 00:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPjtgMH8OLqF for ; Fri, 7 Nov 2014 00:32:53 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156B91A1A99 for ; Fri, 7 Nov 2014 00:32:53 -0800 (PST) Received: from [210.97.169.116] (port=37211 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xmey7-0004g8-RO; Fri, 07 Nov 2014 19:32:32 +1100 Message-ID: <545C83A8.6070906@nteczone.com> Date: Fri, 07 Nov 2014 19:32:40 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Roberta Presta , clue@ietf.org References: <20141024131007.25439.32459.idtracker@ietfa.amsl.com> <544A5742.6050606@unina.it> <544EA871.6010507@alum.mit.edu> <544F9257.1090207@unina.it> <544FB35C.80706@alum.mit.edu> <5451A7F4.7070804@nteczone.com> <54520CD3.5060403@unina.it> In-Reply-To: <54520CD3.5060403@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/8DFCWj9ARKJl_nRq8Y2aJ4YADyg Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-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: Fri, 07 Nov 2014 08:32:54 -0000 Hello Roberta, Sorry for the delay in getting back to you. In my understanding a retry mechanism would only apply if there was a transport related problem. I thought the READV was used in the case where the MC looses the CLUEinfo description to some internal event where the transport isn't affected. In this case the only option for the MC would be to restart the CLUE session. Having the READV would prevent the need for that. Regards, Christian On 30/10/2014 9:02 PM, Roberta Presta wrote: > Hello Christian, > > we found that with the current state machines, in any case the MC > might need a new copy of the ADV, that copy will arrive even without > asking for it. > We considered: > - when there might be channel errors for example, or end of session > events; > - when the received ADV is nacked by the MC; > - when the MP does not receive any ACK (/NACK/CONF) from the MC > In each of the aforementioned situations, what happens is that the MP > (sooner or later, thanks to a retry mechanism) will send a new ADV to > the MC and that the MC will be reached by that ADV. > What is your feeling about these considerations? > > Regards, > > Roberta > > > Il 30/10/2014 03:52, Christian Groves ha scritto: >> Hello Paul and Roberta, >> >>> >>>>> Why has READV been *removed*? Has something changed so that we don't >>>>> need it? (I was advocating for renaming it, not removing it.) >>>>> >>>> While reviewing the state machines, we found the message redundant in >>>> each case where in the past we thought it could be useful. It is >>>> one of >>>> the topic of the today's discussion. >>> >>> Based on discussion in design team call today I agree that we don't >>> seem to need it. >> >> [CNG] I thought READV the message was needed in case the MP lost the >> CLUE data model information and needed an update. It allowed the MP >> to request an update from the MC. If we remove that what is now the >> assumption? Can you elaborate, as I wasn't in the meeting? >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > From nobody Fri Nov 7 07:03: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 0E61E1A8710 for ; Fri, 7 Nov 2014 07:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 EuazUUYdY7EL for ; Fri, 7 Nov 2014 07:03:49 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9188D1A7008 for ; Fri, 7 Nov 2014 07:03:47 -0800 (PST) Received: from compute03.cs.columbia.edu (compute03.cs.columbia.edu [128.59.11.33]) by mailbackend.panix.com (Postfix) with ESMTP id EA35714995; Fri, 7 Nov 2014 10:03:46 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21596.57170.378797.192762@compute03.cs.columbia.edu> Date: Fri, 7 Nov 2014 10:03:46 -0500 To: Paul Kyzivat In-Reply-To: <545C31D8.8050605@alum.mit.edu> References: <545A66D1.40009@alum.mit.edu> <545C31D8.8050605@alum.mit.edu> X-Mailer: VM 8.1.0 under 23.3.1 (x86_64-pc-linux-gnu) From: lennox@cs.columbia.edu Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Op26P1gzufXBKRKyplQcW-nPcUQ Cc: clue@ietf.org Subject: Re: [clue] Note takers for the CLUE sessions next week X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 15:03:52 -0000 On Thursday, November 6 2014, "Paul Kyzivat" wrote to "clue@ietf.org" saying: > [corrected] > > OK. Now we have an excess for Friday. So I flipped a coin. > Roni is on the agenda Friday, but Rob can cover that part. > > We still have no Jabber scribes. Jonathan - can you do it? I thought I already said yes? If not, yes! Both days. > Here is current status: > > Wednesday Session: > > - Note taker 1: Stephan Wenger > - Note taker 2: Paul Coverdale > - Jabber scribe: (volunteer needed) > > Friday Session: > > - Note taker 1: Rob Hansen > - Note taker 2: Roni Even > - Jabber scribe: (volunteer needed) > > Thanks, > Paul > > On 11/5/14 1:05 PM, Paul Kyzivat wrote: > > To avoid a delay in the meetings while we seek note takers, who will > > volunteer to take notes in Honolulu? > > > > - note taker, Wed > > - jabber scribe, Wed > > - note taker, Fri > > - jabber scribe, Fri > > > > As a reward to note takers, I will give you a "get out of note-taking > > jail" card for non-clue sessions. (Of course these are non-binding on > > other chairs.) > > > > Thanks, > > Paul > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > -- Jonathan Lennox lennox@cs.columbia.edu From nobody Fri Nov 7 07:22: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 A82FC1A6F2F for ; Fri, 7 Nov 2014 07:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 4hVLQFndBb58 for ; Fri, 7 Nov 2014 07:22:38 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.3]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C211A010A for ; Fri, 7 Nov 2014 07:22:37 -0800 (PST) Received: from [216.82.249.212] by server-3.bemta-12.messagelabs.com id C8/1A-02951-DB3EC545; Fri, 07 Nov 2014 15:22:37 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-6.tower-219.messagelabs.com!1415373756!12243154!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12499 invoked from network); 7 Nov 2014 15:22:37 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-6.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 7 Nov 2014 15:22:37 -0000 Received: from PWEHUB01.polycom.com (10.236.2.221) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 7 Nov 2014 07:22:36 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 7 Nov 2014 07:22:36 -0800 From: "Duckworth, Mark" To: Christian Groves , Roberta Presta , "clue@ietf.org" Date: Fri, 7 Nov 2014 07:22:33 -0800 Thread-Topic: [clue] I-D Action: draft-ietf-clue-protocol-02.txt Thread-Index: Ac/6ZXCIj+QE2VdbSeS6QwRERI5gxwAOGrnA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6305@CRPMBOXPRD08.polycom.com> References: <20141024131007.25439.32459.idtracker@ietfa.amsl.com> <544A5742.6050606@unina.it> <544EA871.6010507@alum.mit.edu> <544F9257.1090207@unina.it> <544FB35C.80706@alum.mit.edu> <5451A7F4.7070804@nteczone.com> <54520CD3.5060403@unina.it> <545C83A8.6070906@nteczone.com> In-Reply-To: <545C83A8.6070906@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YKfiWhQJIYHJZQ_-thB2vnvAKBg Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-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: Fri, 07 Nov 2014 15:22:39 -0000 I agree with Christian. I think there should be a way for the consumer to = ask the provider what is the current advertisement. If the provider receive= s a READV request from the consumer, it would treat it the same as a "chang= ed telepresence settings" event in the provider state machine, which goes b= ack to the ADV state and sends an advertisement. Could it be that simple? Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Friday, November 07, 2014 3:33 AM > To: Roberta Presta; clue@ietf.org > Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-02.txt >=20 > Hello Roberta, >=20 > Sorry for the delay in getting back to you. >=20 > In my understanding a retry mechanism would only apply if there was a > transport related problem. I thought the READV was used in the case > where the MC looses the CLUEinfo description to some internal event > where the transport isn't affected. In this case the only option for the > MC would be to restart the CLUE session. Having the READV would prevent > the need for that. >=20 > Regards, Christian >=20 > On 30/10/2014 9:02 PM, Roberta Presta wrote: > > Hello Christian, > > > > we found that with the current state machines, in any case the MC > > might need a new copy of the ADV, that copy will arrive even without > > asking for it. > > We considered: > > - when there might be channel errors for example, or end of session > > events; > > - when the received ADV is nacked by the MC; > > - when the MP does not receive any ACK (/NACK/CONF) from the MC > > In each of the aforementioned situations, what happens is that the MP > > (sooner or later, thanks to a retry mechanism) will send a new ADV to > > the MC and that the MC will be reached by that ADV. > > What is your feeling about these considerations? > > > > Regards, > > > > Roberta > > > > > > Il 30/10/2014 03:52, Christian Groves ha scritto: > >> Hello Paul and Roberta, > >> > >>> > >>>>> Why has READV been *removed*? Has something changed so that > we don't > >>>>> need it? (I was advocating for renaming it, not removing it.) > >>>>> > >>>> While reviewing the state machines, we found the message redundant > in > >>>> each case where in the past we thought it could be useful. It is > >>>> one of > >>>> the topic of the today's discussion. > >>> > >>> Based on discussion in design team call today I agree that we don't > >>> seem to need it. > >> > >> [CNG] I thought READV the message was needed in case the MP lost the > >> CLUE data model information and needed an update. It allowed the MP > >> to request an update from the MC. If we remove that what is now the > >> assumption? Can you elaborate, as I wasn't in the meeting? > >> > >> Regards, Christian > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Sun Nov 9 07:31: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 2AAB81A1ADB for ; Sun, 9 Nov 2014 07:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 QJRehSoGM52l for ; Sun, 9 Nov 2014 07:31:10 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.112]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AAF21A1AD9 for ; Sun, 9 Nov 2014 07:31:10 -0800 (PST) Received: from [216.82.254.20] by server-16.bemta-7.messagelabs.com id 63/69-02697-DB88F545; Sun, 09 Nov 2014 15:31:09 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-47.messagelabs.com!1415547069!12970292!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18493 invoked from network); 9 Nov 2014 15:31:09 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-9.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 9 Nov 2014 15:31:09 -0000 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; Sun, 9 Nov 2014 07:31:09 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Sun, 9 Nov 2014 07:31:08 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Sun, 9 Nov 2014 07:30:39 -0800 Thread-Topic: Rtp mapping and ssrc and captureID Thread-Index: Ac/8Mi7Z7GR3bb9xR62+BX+at36stA== Message-ID: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.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_6juecfb2b2xv7yumt6pm1vtw1415545907193emailandroidcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/f7Kxozc5sDfeWK0JrB6BZOLMtuI Subject: [clue] Rtp mapping and ssrc and captureID X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 15:31:12 -0000 --_000_6juecfb2b2xv7yumt6pm1vtw1415545907193emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGEgY291cGxlIHF1ZXN0aW9ucyBhYm91dCBob3cgdGhlIHJ0cCBtYXBwaW5nIGRvY3Vt ZW50IGRlc2NyaWJlcyBtYXBwaW5ncyBiZXR3ZWVuIGVuY29kaW5ncywgbWVkaWEgY2FwdHVyZUlE LCBhbmQgc3NyYy9jc3JjLg0KDQpJbiBzZWN0aW9uIDUsIHRoZSBwYXJ0IGFib3V0IG1lZXRpbmcg dGhlIE1lZGlhLTcgcmVxdWlyZW1lbnQsIGl0IHNheXMgaW4gc29tZSBjYXNlcyAoc3dpdGNoZWQg bWl4ZXIgYW5kIHNlbGVjdGl2ZSBmb3J3YXJkaW5nKSB0aGUgb3JpZ2luYWwgc291cmNlIG9mIGEg c3dpdGNoZWQgY2FwdHVyZSBjYW4gYmUgZGV0ZXJtaW5lZCBmcm9tIHNzcmMgb3IgY3NyYy4gSSBk b24ndCB1bmRlcnN0YW5kIGhvdyB0aGlzIGlzIHRoZSBjYXNlLiBUaGUgcG9pbnQgaXMgZm9yIHRo ZSByZWNlaXZlciAobWVkaWEgY29uc3VtZXIpIHRvIGJlIGFibGUgdG8gcmVsYXRlIHJ0cCBwYWNr ZXRzIHRvIHRoZSBvcmlnaW5hbCBtZWRpYSBjYXB0dXJlIElELiBTbyBldmVuIGlmIGl0IGhhcyBh IHNzcmMgdmFsdWUgZnJvbSBzc3JjIG9yIGNzcmMgZmllbGQgaW4gUlRQIGhlYWRlciwgaG93IGRv ZXMgdGhpcyBoZWxwPyBXaGVyZSBkb2VzIHRoZSBtYXBwaW5nIGZyb20gc3NyYyB0byBjYXB0dXJl SUQgY29tZSBmcm9tIGluIHRoaXMgY2FzZT8NCg0KVGhlbiB0aGUgZG9jdW1lbnQgZ29lcyBvbiB0 byBzYXkgaG93IHRvIHVzZSBuZXcgcnRwIGhlYWRlciBmb3IgY2FwdHVyZUlEIGZvciBNQ0MgY29u c3RpdHVlbnQsIHdoaWNoIEkgdGhpbmsgSSB1bmRlcnN0YW5kLiBCdXQgaXMgdGhlIGRvY3VtZW50 IHNheWluZyBzb21ldGltZXMgeW91IHVzZSB0aGlzIHJ0cCBoZWFkZXIgZXh0ZW5zaW9uIGFuZCBz b21ldGltZXMgeW91IGRvbid0IG5lZWQgaXQgYmVjYXVzZSBzc3JjIHN1ZmZpY2VzPyBDYW4gYW55 Ym9keSBjbGFyaWZ5IHRoaXM/DQoNCkkgdGhpbmsgdGhlIHByb3Bvc2VkIHJ0cCBoZWFkZXIgZXh0 ZW5zaW9uIGZvciBjYXB0dXJlSUQgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBvbmx5IGZvciBpZGVu dGlmeWluZyB0aGUgY2FwdHVyZUlEIG9mICB0aGUgb3JpZ2luYWwgY2FwdHVyZSB1c2VkIGZvciBh IHB1cmVseSBzd2l0Y2hlZCBNQ0MsIGNvcnJlY3Q/ICBJZiBzbywgY291bGQgd2UgY2FsbCBpdCAi TUNDIGNvbnN0aXR1ZW50IGNhcHR1cmVJRCIgb3Igc29tZXRoaW5nIGxpa2UgdGhhdCB3aGljaCBi ZXR0ZXIgaW5kaWNhdGVzIHdoYXQgaXQgbWVhbnM/IE90aGVyd2lzZSwganVzdCBjYWxsaW5nIGl0 IENhcHR1cmVJRCBtYWtlcyBpdCBzb3VuZCBtb3JlIGJyb2FkLCBsaWtlIHRoZSBJRCBvZiB0aGUg TUNDIGl0c2VsZiwgb3IgdGhlIElEIG9mIGEgc2ltcGxlIGluZGl2aWR1YWwgbWVkaWEgY2FwdHVy ZSB0aGF0IGlzIG5vdCBzd2l0Y2hlZC4NCg0KTWFyaw0K --_000_6juecfb2b2xv7yumt6pm1vtw1415545907193emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+SSBoYXZlIGEgY291cGxlIHF1ZXN0 aW9ucyBhYm91dCBob3cgdGhlIHJ0cCBtYXBwaW5nIGRvY3VtZW50IGRlc2NyaWJlcyBtYXBwaW5n cyBiZXR3ZWVuIGVuY29kaW5ncywgbWVkaWEgY2FwdHVyZUlELCBhbmQgc3NyYy9jc3JjLjxkaXY+ PGJyPjwvZGl2PjxkaXY+SW4gc2VjdGlvbiA1LCB0aGUgcGFydCBhYm91dCBtZWV0aW5nIHRoZSBN ZWRpYS03IHJlcXVpcmVtZW50LCBpdCBzYXlzIGluIHNvbWUgY2FzZXMgKHN3aXRjaGVkIG1peGVy IGFuZCBzZWxlY3RpdmUgZm9yd2FyZGluZykgdGhlIG9yaWdpbmFsIHNvdXJjZSBvZiBhIHN3aXRj aGVkIGNhcHR1cmUgY2FuIGJlIGRldGVybWluZWQgZnJvbSBzc3JjIG9yIGNzcmMuIEkgZG9uJ3Qg dW5kZXJzdGFuZCBob3cgdGhpcyBpcyB0aGUgY2FzZS4gVGhlIHBvaW50IGlzIGZvciB0aGUgcmVj ZWl2ZXIgKG1lZGlhIGNvbnN1bWVyKSB0byBiZSBhYmxlIHRvIHJlbGF0ZSBydHAgcGFja2V0cyB0 byB0aGUgb3JpZ2luYWwgbWVkaWEgY2FwdHVyZSBJRC4gU28gZXZlbiBpZiBpdCBoYXMgYSBzc3Jj IHZhbHVlIGZyb20gc3NyYyBvciBjc3JjIGZpZWxkIGluIFJUUCBoZWFkZXIsIGhvdyBkb2VzIHRo aXMgaGVscD8gV2hlcmUgZG9lcyB0aGUgbWFwcGluZyBmcm9tIHNzcmMgdG8gY2FwdHVyZUlEIGNv bWUgZnJvbSBpbiB0aGlzIGNhc2U/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGVuIHRoZSBk b2N1bWVudCBnb2VzIG9uIHRvIHNheSBob3cgdG8gdXNlIG5ldyBydHAgaGVhZGVyIGZvciBjYXB0 dXJlSUQgZm9yIE1DQyBjb25zdGl0dWVudCwgd2hpY2ggSSB0aGluayBJIHVuZGVyc3RhbmQuIEJ1 dCBpcyB0aGUgZG9jdW1lbnQgc2F5aW5nIHNvbWV0aW1lcyB5b3UgdXNlIHRoaXMgcnRwIGhlYWRl ciBleHRlbnNpb24gYW5kIHNvbWV0aW1lcyB5b3UgZG9uJ3QgbmVlZCBpdCBiZWNhdXNlIHNzcmMg c3VmZmljZXM/IENhbiBhbnlib2R5IGNsYXJpZnkgdGhpcz88L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PkkgdGhpbmsgdGhlIHByb3Bvc2VkIHJ0cCBoZWFkZXIgZXh0ZW5zaW9uIGZvciBjYXB0dXJl SUQgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBvbmx5IGZvciBpZGVudGlmeWluZyB0aGUgY2FwdHVy ZUlEIG9mICZuYnNwO3RoZSBvcmlnaW5hbCBjYXB0dXJlIHVzZWQgZm9yIGEgcHVyZWx5IHN3aXRj aGVkIE1DQywgY29ycmVjdD8gJm5ic3A7SWYgc28sIGNvdWxkIHdlIGNhbGwgaXQgIk1DQyBjb25z dGl0dWVudCBjYXB0dXJlSUQiIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQgd2hpY2ggYmV0dGVyIGlu ZGljYXRlcyB3aGF0IGl0IG1lYW5zPyBPdGhlcndpc2UsIGp1c3QgY2FsbGluZyBpdCBDYXB0dXJl SUQgbWFrZXMgaXQgc291bmQgbW9yZSBicm9hZCwgbGlrZSB0aGUgSUQgb2YgdGhlIE1DQyBpdHNl bGYsIG9yIHRoZSBJRCBvZiBhIHNpbXBsZSBpbmRpdmlkdWFsIG1lZGlhIGNhcHR1cmUgdGhhdCBp cyBub3Qgc3dpdGNoZWQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5NYXJrPC9kaXY+PC9ib2R5 PjwvaHRtbD4= --_000_6juecfb2b2xv7yumt6pm1vtw1415545907193emailandroidcom_-- From nobody Sun Nov 9 15:15:55 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481DA1A8778 for ; Sun, 9 Nov 2014 15:15:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 mLPHRPW6V-ZA for ; Sun, 9 Nov 2014 15:15:41 -0800 (PST) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A551A875F for ; Sun, 9 Nov 2014 15:15:40 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/9/2014 6:15:38 PM X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/3/2014 5:59:48 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-190/SG:2 11/9/2014 6:15:18 PM X-GBUdb-Analysis: 0, 67.231.149.202, Ugly c=0.615865 p=-0.969543 Source White X-Signature-Violations: 0-0-0-6945-c X-Note-419: 15.6264 ms. Fail:0 Chk:1329 of 1329 total X-Note: SCH-CT/SI:0-1329/SG:1 11/9/2014 6:15:29 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.149.202 X-Note-Reverse-DNS: mx0a-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G241 G242 G243 G244 G248 G249 G361 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.149.202] (HELO mx0a-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTP id 169897904; Sun, 09 Nov 2014 18:15:37 -0500 Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id sA9NFbFS006094; Sun, 9 Nov 2014 18:15:37 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1qh4q8gen5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 09 Nov 2014 18:15:37 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Sun, 9 Nov 2014 17:15:36 -0600 From: Jonathan Lennox To: Mark Duckworth Thread-Topic: [clue] Rtp mapping and ssrc and captureID Thread-Index: Ac/8Mi7Z7GR3bb9xR62+BX+at36stAAcyyKA Date: Sun, 9 Nov 2014 23:15:35 +0000 Message-ID: References: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.com> In-Reply-To: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.151.161] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4EEF39072BA0C647B2CB6F86A55FCD3B@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-11-09_03:2014-11-07,2014-11-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411090219 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/JrjwtOHDTx2xUPp-94s-Obod0Uk Cc: "clue@ietf.org" Subject: Re: [clue] Rtp mapping and ssrc and captureID X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 23:15:44 -0000 On Nov 9, 2014, at 5:30 AM, Duckworth, Mark wr= ote: > I have a couple questions about how the rtp mapping document describes ma= ppings between encodings, media captureID, and ssrc/csrc. >=20 > In section 5, the part about meeting the Media-7 requirement, it says in = some cases (switched mixer and selective forwarding) the original source of= a switched capture can be determined from ssrc or csrc. I don't understand= how this is the case. The point is for the receiver (media consumer) to be= able to relate rtp packets to the original media capture ID. So even if it= has a ssrc value from ssrc or csrc field in RTP header, how does this help= ? Where does the mapping from ssrc to captureID come from in this case? The idea is that the mapping from SSRC (or CSRC) to CaptureID is done by th= e new RTCP SDES item or header extension, whereas which SSRC or CSRCs are m= aking up the current media is communicated by the normal RTP mechanisms. This means that communicating the SSRC/CSRC-to-CaptureID mappings isn=92t n= ecessarily timing-crucial, and so doesn=92t need to be repeated on every sw= itch, so long as the receiver already has all the relevant information. Currently the header extension flavor of the solution only works for SSRC, = so only works for what the rtp topologies update calls a =93selective forwa= rding middlebox", whereas a =93switching mixer=94 would have to use the RTC= P item only. (There isn=92t currently any specified way to send a header e= xtension that gives an SDES item for one of the media=92s CSRCs. This migh= t be worth raising with the authors of draft-westerlund-avtext-sdes-hdr-ext= , which this solution is meant to be compatible with.) > Then the document goes on to say how to use new rtp header for captureID = for MCC constituent, which I think I understand. But is the document saying= sometimes you use this rtp header extension and sometimes you don't need i= t because ssrc suffices? Can anybody clarify this? >=20 > I think the proposed rtp header extension for captureID is intended to be= used only for identifying the captureID of the original capture used for = a purely switched MCC, correct? If so, could we call it "MCC constituent c= aptureID" or something like that which better indicates what it means? Othe= rwise, just calling it CaptureID makes it sound more broad, like the ID of = the MCC itself, or the ID of a simple individual media capture that is not = switched. I agree this might be a better name. From nobody Mon Nov 10 19:16: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 336451AD4F4; Mon, 10 Nov 2014 18:59:46 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.595 X-Spam-Level: X-Spam-Status: No, score=-7.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 iRUm95ffSeEv; Mon, 10 Nov 2014 18:59:44 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74941AD4FC; Mon, 10 Nov 2014 18:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1415674782; x=1447210782; h=x-ojodefuego:message-id:x-mailer:date:to:from:subject: content-type; bh=me+wBoVNB+yVTmICEEzw1gOHtj/r51N0uc8iSAXIe5U=; b=ikk6JLZBL7vaYMh+zl4isqS5QCKxoel5mduK1nHIUTpc3tKHcPgviZuG 8pxhqEK3SDZVtNGLNTN8YkexQdofdzFWdJ7oxF5nlPhhIch5WQkSPedRt Pa/phU00uGvLtJLMqafzJvtQ14DvUn5Xyia7vcveFEZ2epK0Wo28J0FKk s=; X-IronPort-AV: E=McAfee;i="5600,1067,7618"; a="83162748" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2014 18:59:42 -0800 X-IronPort-AV: E=Sophos;i="5.07,357,1413270000"; d="scan'208";a="773491541" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2014 18:59:42 -0800 Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id sAB2xeKk019413; Mon, 10 Nov 2014 18:59:40 -0800 X-IronPort-AV: E=Sophos;i="5.07,357,1413270000"; d="scan'208";a="773491474" X-ojodefuego: yes Received: from unknown (HELO dhcp-97d8.meeting.ietf.org) ([10.64.165.21]) by Ironmsg03-L.qualcomm.com with ESMTP; 10 Nov 2014 18:59:38 -0800 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Mon, 10 Nov 2014 18:59:27 -0800 To: "clue@ietf.org" , , , , From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/a8EEKwJ4oywCpe4lri5ZNCW8RDY X-Mailman-Approved-At: Mon, 10 Nov 2014 19:16:11 -0800 Subject: [clue] New mailing list for human language discussions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 02:59:46 -0000 I'm sending this message to the IETF lists where some discussions occurred on the work to let people know that we have a new mailing list for the work. If you have any interest in it, please subscribe. https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- MIPS: Meaningless Indicator of Processor Speed. From nobody Tue Nov 11 12:27: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 5F3151A8A5F for ; Tue, 11 Nov 2014 12:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 LnO59jNYpOOG for ; Tue, 11 Nov 2014 12:27:13 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.99]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89ED21A88B2 for ; Tue, 11 Nov 2014 12:27:11 -0800 (PST) Received: from [216.82.254.19] by server-3.bemta-7.messagelabs.com id 07/74-02952-F1172645; Tue, 11 Nov 2014 20:27:11 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-4.tower-96.messagelabs.com!1415737630!13657169!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28286 invoked from network); 11 Nov 2014 20:27:10 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-4.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 11 Nov 2014 20:27:10 -0000 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, 11 Nov 2014 12:27:10 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 11 Nov 2014 12:27:10 -0800 From: "Duckworth, Mark" To: Jonathan Lennox , "Christer Holmberg (christer.holmberg@ericsson.com)" Date: Tue, 11 Nov 2014 12:27:06 -0800 Thread-Topic: [clue] Rtp mapping and ssrc and captureID Thread-Index: Ac/8Mi7Z7GR3bb9xR62+BX+at36stAAcyyKAAE80KeA= Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6631@CRPMBOXPRD08.polycom.com> References: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/E_XVh51ZVdqX5ToIYy23FlrK5QE Cc: "clue@ietf.org" Subject: Re: [clue] Rtp mapping and ssrc and captureID X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:27:18 -0000 Thanks Jonathan, I think I follow what you are saying. But I'm still trying to understand that we really have two different ways t= o associate SSRC values with CLUE captureID, and when each way is used, and= if they overlap at all. Consider the case where BUNDLE is used. Then the= re are two different mapping mechanisms in play: Mechanism 1: Use RTP/RTCP MID SDES item, conveyed in RTCP and RTP header ex= tension as described in BUNDLE sections 10.2 and 13. This associates an ss= rc value with an m line by linking them to the same SDP mid value, which is= unique per m line. The CLUE media consumer also knows the mapping from m = line to the CLUE capture ID received for that m line, because the consumer = made that mapping itself when it sent the configure message to the provider= . So with all this, both consumer and provider know the association of: CL= UE captureID, CLUE encodingID (also SDP label), SDP m line, SDP mid value. = So this seems adequate for handling all media captures that are directly c= onfigured into a CLUE encoding (and m line), but not for captures that are = constituents of MCCs. Mechanism 2: Use RTP/RTCP CaptureID SDES item, conveyed in RTCP and RTP hea= der extension as described in clue-rtp-mapping section 6. This gives a dir= ect mapping between an ssrc value and a captureID. This mechanism is inten= ded to be used only for Clue media captures that are constituents of an MCC= . This could apply to an MCC that is switched or composed. For the case of a "switching mixer", the ssrc value in RTP packets stays th= e same over time for a given m line and CLUE encoding. This is true for si= ngle MC encoded directly, and also for an MCC. For an MCC, the ssrc value = associated with the MCC captureID stays constant. But the value(s) in RTP = CSRC field change as switching occurs. So the MID SDES item maps to a cons= tant ssrc value even when switching occurs. The CaptureID SDES item (conve= yed in RTCP) maps the MCC constituent capture IDs to the values that appear= in RTP CSRC field. These mappings don't change, but the media provider sh= ould send the mapping information whenever an individual MC is switched int= o an MCC for the first time. The CaptureID RTP header extension does not a= pply for this case, it can be conveyed only in RTCP. For the case of a "selective forwarding middlebox", for RTP packets it send= s for a switched MCC, a single ssrc value can be mapped to a different capt= ureID by each of the above two mechanisms. The MID SDES item maps the ssrc= to the capture ID of the MCC itself. But the CaptureID SDES item maps the= same ssrc value to the capture ID of the original MC that is a constituent= of the MCC. When the middlebox decides to switch the MCC to a different c= onstituent MC, then the MID SDES item maps the mid value to the new ssrc (t= he receiver always needs this information right away). The CaptureID SDES = item maps the new ssrc to the new original MC capture ID (although the rece= iver might not need this if it already has this information from when the s= ame MC was previously sent as part of an MCC). So am I describing these mechanisms and scenarios correctly? If I have it right so far, then I think BUNDLE has a problem with "selectiv= e forwarding middlebox" when the same source is sent for two different m li= nes at the same time. But that is probably a topic for the mmusic list, do= es anybody know if that has already been discussed? Thanks for helping me understand. Mark > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com] > Sent: Sunday, November 09, 2014 1:16 PM > To: Duckworth, Mark > Cc: clue@ietf.org > Subject: Re: [clue] Rtp mapping and ssrc and captureID >=20 >=20 > On Nov 9, 2014, at 5:30 AM, Duckworth, Mark > wrote: >=20 > > I have a couple questions about how the rtp mapping document describes > mappings between encodings, media captureID, and ssrc/csrc. > > > > In section 5, the part about meeting the Media-7 requirement, it says i= n > some cases (switched mixer and selective forwarding) the original source = of a > switched capture can be determined from ssrc or csrc. I don't understand > how this is the case. The point is for the receiver (media consumer) to b= e > able to relate rtp packets to the original media capture ID. So even if i= t has a > ssrc value from ssrc or csrc field in RTP header, how does this help? Whe= re > does the mapping from ssrc to captureID come from in this case? >=20 > The idea is that the mapping from SSRC (or CSRC) to CaptureID is done by = the > new RTCP SDES item or header extension, whereas which SSRC or CSRCs are > making up the current media is communicated by the normal RTP > mechanisms. >=20 > This means that communicating the SSRC/CSRC-to-CaptureID mappings isn't > necessarily timing-crucial, and so doesn't need to be repeated on every > switch, so long as the receiver already has all the relevant information. >=20 > Currently the header extension flavor of the solution only works for SSRC= , so > only works for what the rtp topologies update calls a "selective forwardi= ng > middlebox", whereas a "switching mixer" would have to use the RTCP item > only. (There isn't currently any specified way to send a header extensio= n > that gives an SDES item for one of the media's CSRCs. This might be wort= h > raising with the authors of draft-westerlund-avtext-sdes-hdr-ext, which t= his > solution is meant to be compatible with.) >=20 > > Then the document goes on to say how to use new rtp header for > captureID for MCC constituent, which I think I understand. But is the > document saying sometimes you use this rtp header extension and > sometimes you don't need it because ssrc suffices? Can anybody clarify th= is? > > > > I think the proposed rtp header extension for captureID is intended to = be > used only for identifying the captureID of the original capture used for= a > purely switched MCC, correct? If so, could we call it "MCC constituent > captureID" or something like that which better indicates what it means? > Otherwise, just calling it CaptureID makes it sound more broad, like the = ID of > the MCC itself, or the ID of a simple individual media capture that is no= t > switched. >=20 > I agree this might be a better name. From nobody Tue Nov 11 13:06: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 194B41AC3FD for ; Tue, 11 Nov 2014 13:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 MNKbZ0K1i30o for ; Tue, 11 Nov 2014 13:06:42 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.107]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD4C1AC437 for ; Tue, 11 Nov 2014 13:06:42 -0800 (PST) Received: from [216.82.254.19] by server-11.bemta-7.messagelabs.com id 9F/1A-02706-16A72645; Tue, 11 Nov 2014 21:06:41 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-2.tower-96.messagelabs.com!1415740000!13709298!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6742 invoked from network); 11 Nov 2014 21:06:41 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-2.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 11 Nov 2014 21:06:41 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 11 Nov 2014 13:06:40 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 11 Nov 2014 13:06:39 -0800 Thread-Topic: provider ESTABLISHED and WAIT FOR CONF states Thread-Index: Ac/98hKXh/ivJFuDTwSgNF9i66iTDQ== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6655@CRPMBOXPRD08.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_5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6655CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YlntBdmbe8CVUZ87warvNq429XU Subject: [clue] provider ESTABLISHED and WAIT FOR CONF states X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 21:06:47 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6655CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I have a question about the protocol state machine for a media provider. S= uppose it is in the ESTABLISHED state, and then the consumer sends a new co= nfigure message. The provider receives it, and goes to CONF RESPONSE state= . Suppose for some reason the provider has to send an error response back = to the consumer. According to the state diagram, the provider then goes to= the WAIT FOR CONF state. This means it is now waiting for a new configure= message, and if it doesn't receive one it will eventually time out and go = to TERMINATED state. Is this really what we want? It seems to me that in this case the provider= is still sending media that was previously configured with the most recent= valid configure message that got it into the ESTABLISHED state in the firs= t place. Since there was no change to the advertisement, and there was a v= alid configure message previously, and valid media is flowing, would it be = better to maintain this state rather than go back to WAIT FOR CONF? In oth= er words, if the provider is already in ESTABLISHED state, and it receives = a configure and sends an error response, should it go back to ESTABLISHED s= tate rather than go to WAIT FOR CONF? Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6655CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,<= /o:p>

I have a question about the protocol state ma= chine for a media provider.  Suppose it is in the ESTABLISHED state, a= nd then the consumer sends a new configure message.  The provider rece= ives it, and goes to CONF RESPONSE state.  Suppose for some reason the= provider has to send an error response back to the consumer.  Accordi= ng to the state diagram, the provider then goes to the WAIT FOR CONF state.=   This means it is now waiting for a new configure message, and if it = doesn’t receive one it will eventually time out and go to TERMINATED = state.

 

Is this really what we want?  It seems to me that in this cas= e the provider is still sending media that was previously configured with t= he most recent valid configure message that got it into the ESTABLISHED sta= te in the first place.  Since there was no change to the advertisement= , and there was a valid configure message previously, and valid media is fl= owing, would it be better to maintain this state rather than go back to WAI= T FOR CONF?  In other words, if the provider is already in ESTABLISHED= state, and it receives a configure and sends an error response, should it = go back to ESTABLISHED state rather than go to WAIT FOR CONF?

 

Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6655CRPMBOXPRD08p_-- From nobody Tue Nov 11 13:30: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 B22F41AC408 for ; Tue, 11 Nov 2014 13:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 WgMppQfXYY3O for ; Tue, 11 Nov 2014 13:30:10 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.97]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96E11AC3A6 for ; Tue, 11 Nov 2014 13:30:09 -0800 (PST) Received: from [216.82.254.19] by server-1.bemta-7.messagelabs.com id 08/2C-02952-1EF72645; Tue, 11 Nov 2014 21:30:09 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-15.tower-96.messagelabs.com!1415741408!12031013!2 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16455 invoked from network); 11 Nov 2014 21:30:09 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-15.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 11 Nov 2014 21:30:09 -0000 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, 11 Nov 2014 13:30:08 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 11 Nov 2014 13:30:08 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 11 Nov 2014 13:30:06 -0800 Thread-Topic: provider should be able to bypass SDP O/A state in some cases Thread-Index: Ac/99bitw64SiFJ2T0a2WIdZGeybRA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6663@CRPMBOXPRD08.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_5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6663CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/rLnM1Rax4IA1HGp_fpLbYmVNzXA Subject: [clue] provider should be able to bypass SDP O/A state in some cases X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 21:30:12 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6663CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, In the protocol draft, it seems to me the provider state machine requires t= he provider to initiate an SDP offer/answer even when it is not necessary o= r desirable to do so. Suppose the provider is in ESTABLISHED state, and th= en receives a new CONF message. Provider goes to CONF RESPONSE state. Sup= pose the provider sends a successful CONF RESPONSE back to the consumer. N= ow according to the state diagram and the text in section 6.1, the provider= initiates an SDP O/A. But in this case I think SDP O/A is not required, b= ecause nothing in the SDP should change from the previous O/A, is that righ= t? If not, then what in SDP should change? If the SDP O/A is not desired in this case, then maybe when in ESTABLISHED = receiving CONF should go to a different state similar to CONF RESPONSE but= which does not lead to O/A. This is related also to my previous question = about handling a configure error after ESTABLISHED state. What do you think? Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6663CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,<= /o:p>

In the protocol draft, it seems to me the pro= vider state machine requires the provider to initiate an SDP offer/answer e= ven when it is not necessary or desirable to do so.  Suppose the provi= der is in ESTABLISHED state, and then receives a new CONF message.  Pr= ovider goes to CONF RESPONSE state.  Suppose the provider sends a succ= essful CONF RESPONSE back to the consumer.  Now according to the state= diagram and the text in section 6.1, the provider initiates an SDP O/A.&nb= sp; But in this case I think SDP O/A is not required, because nothing in th= e SDP should change from the previous O/A, is that right?  If not, the= n what in SDP should change?

 =

If the SDP O/A is not desired in this case, = then maybe when in ESTABLISHED receiving CONF should go to  a differen= t state similar to CONF RESPONSE but which does not lead to O/A.  This= is related also to my previous question about handling a configure error a= fter ESTABLISHED state.

 

What do you think?

 

Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6663CRPMBOXPRD08p_-- From nobody Tue Nov 11 14:55: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 433611A1BD6 for ; Tue, 11 Nov 2014 14:55:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 T5aP-Q6v4PSc for ; Tue, 11 Nov 2014 14:55:33 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182841A1B81 for ; Tue, 11 Nov 2014 14:55:32 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/11/2014 5:55:27 PM X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/7/2014 8:53:38 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-312/SG:2 11/11/2014 5:55:18 PM X-GBUdb-Analysis: 0, 67.231.149.202, Ugly c=0.785316 p=-0.95098 Source White X-Signature-Violations: 0-0-0-16473-c X-Note-419: 31.1999 ms. Fail:0 Chk:1329 of 1329 total X-Note: SCH-CT/SI:0-1329/SG:1 11/11/2014 5:55:17 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.149.202 X-Note-Reverse-DNS: mx0a-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G241 G242 G243 G244 G248 G249 G361 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.149.202] (HELO mx0a-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTP id 170604740; Tue, 11 Nov 2014 17:55:26 -0500 Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id sABMsPYW006276; Tue, 11 Nov 2014 17:55:26 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1qku1w808k-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 11 Nov 2014 17:55:26 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 16:55:25 -0600 From: Jonathan Lennox To: Mark Duckworth Thread-Topic: [clue] Rtp mapping and ssrc and captureID Thread-Index: Ac/8Mi7Z7GR3bb9xR62+BX+at36stAAcyyKAAE80KeAAFKyYAA== Date: Tue, 11 Nov 2014 22:55:25 +0000 Message-ID: <018AFE73-D4B0-4A5B-B5E3-69D5BE3390A7@vidyo.com> References: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6631@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6631@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.187.214] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0B1CAEA13F02E346AD7E01C18F08606C@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-11_07:2014-11-11,2014-11-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411110163 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qFfSNIzFuNtqqlGbxx1W5dXLik4 Cc: "clue@ietf.org" Subject: Re: [clue] Rtp mapping and ssrc and captureID X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 22:55:36 -0000 This is correct. The configured capture is always determined by its mappin= g to the encoding. Encodings are determined by the mid if you=92re using b= undle, or the RTP session (5-tuple) if not. Both of these are as specified= in MMUSIC. The CaptureID SDES item is only used for components of an MCC. BUNDLE indeed does not currently allow a single SSRC to be mapped to more t= han one m-line =97 this precludes the same source being used for more than = one encoding. In the case when you want to send the same media for more th= an one capture, you=92ll have to duplicate the media and re-map at least on= e SSRC. I believe this issue is going to be discussed in MMUSIC this week when BUND= LE is discussed, so if you think this is a problem, come there to discuss i= t... On Nov 11, 2014, at 10:27 AM, Duckworth, Mark = wrote: > Thanks Jonathan, I think I follow what you are saying. > But I'm still trying to understand that we really have two different ways= to associate SSRC values with CLUE captureID, and when each way is used, a= nd if they overlap at all. Consider the case where BUNDLE is used. Then t= here are two different mapping mechanisms in play: >=20 > Mechanism 1: Use RTP/RTCP MID SDES item, conveyed in RTCP and RTP header = extension as described in BUNDLE sections 10.2 and 13. This associates an = ssrc value with an m line by linking them to the same SDP mid value, which = is unique per m line. The CLUE media consumer also knows the mapping from = m line to the CLUE capture ID received for that m line, because the consume= r made that mapping itself when it sent the configure message to the provid= er. So with all this, both consumer and provider know the association of: = CLUE captureID, CLUE encodingID (also SDP label), SDP m line, SDP mid value= . So this seems adequate for handling all media captures that are directly= configured into a CLUE encoding (and m line), but not for captures that ar= e constituents of MCCs. >=20 > Mechanism 2: Use RTP/RTCP CaptureID SDES item, conveyed in RTCP and RTP h= eader extension as described in clue-rtp-mapping section 6. This gives a d= irect mapping between an ssrc value and a captureID. This mechanism is int= ended to be used only for Clue media captures that are constituents of an M= CC. This could apply to an MCC that is switched or composed. >=20 > For the case of a "switching mixer", the ssrc value in RTP packets stays = the same over time for a given m line and CLUE encoding. This is true for = single MC encoded directly, and also for an MCC. For an MCC, the ssrc valu= e associated with the MCC captureID stays constant. But the value(s) in RT= P CSRC field change as switching occurs. So the MID SDES item maps to a co= nstant ssrc value even when switching occurs. The CaptureID SDES item (con= veyed in RTCP) maps the MCC constituent capture IDs to the values that appe= ar in RTP CSRC field. These mappings don't change, but the media provider = should send the mapping information whenever an individual MC is switched i= nto an MCC for the first time. The CaptureID RTP header extension does not= apply for this case, it can be conveyed only in RTCP. >=20 > For the case of a "selective forwarding middlebox", for RTP packets it se= nds for a switched MCC, a single ssrc value can be mapped to a different ca= ptureID by each of the above two mechanisms. The MID SDES item maps the ss= rc to the capture ID of the MCC itself. But the CaptureID SDES item maps t= he same ssrc value to the capture ID of the original MC that is a constitue= nt of the MCC. When the middlebox decides to switch the MCC to a different= constituent MC, then the MID SDES item maps the mid value to the new ssrc = (the receiver always needs this information right away). The CaptureID SDE= S item maps the new ssrc to the new original MC capture ID (although the re= ceiver might not need this if it already has this information from when the= same MC was previously sent as part of an MCC). >=20 > So am I describing these mechanisms and scenarios correctly? > If I have it right so far, then I think BUNDLE has a problem with "select= ive forwarding middlebox" when the same source is sent for two different m = lines at the same time. But that is probably a topic for the mmusic list, = does anybody know if that has already been discussed? >=20 > Thanks for helping me understand. >=20 > Mark >=20 >> -----Original Message----- >> From: Jonathan Lennox [mailto:jonathan@vidyo.com] >> Sent: Sunday, November 09, 2014 1:16 PM >> To: Duckworth, Mark >> Cc: clue@ietf.org >> Subject: Re: [clue] Rtp mapping and ssrc and captureID >>=20 >>=20 >> On Nov 9, 2014, at 5:30 AM, Duckworth, Mark >> wrote: >>=20 >>> I have a couple questions about how the rtp mapping document describes >> mappings between encodings, media captureID, and ssrc/csrc. >>>=20 >>> In section 5, the part about meeting the Media-7 requirement, it says i= n >> some cases (switched mixer and selective forwarding) the original source= of a >> switched capture can be determined from ssrc or csrc. I don't understand >> how this is the case. The point is for the receiver (media consumer) to = be >> able to relate rtp packets to the original media capture ID. So even if = it has a >> ssrc value from ssrc or csrc field in RTP header, how does this help? Wh= ere >> does the mapping from ssrc to captureID come from in this case? >>=20 >> The idea is that the mapping from SSRC (or CSRC) to CaptureID is done by= the >> new RTCP SDES item or header extension, whereas which SSRC or CSRCs are >> making up the current media is communicated by the normal RTP >> mechanisms. >>=20 >> This means that communicating the SSRC/CSRC-to-CaptureID mappings isn't >> necessarily timing-crucial, and so doesn't need to be repeated on every >> switch, so long as the receiver already has all the relevant information= . >>=20 >> Currently the header extension flavor of the solution only works for SSR= C, so >> only works for what the rtp topologies update calls a "selective forward= ing >> middlebox", whereas a "switching mixer" would have to use the RTCP item >> only. (There isn't currently any specified way to send a header extensi= on >> that gives an SDES item for one of the media's CSRCs. This might be wor= th >> raising with the authors of draft-westerlund-avtext-sdes-hdr-ext, which = this >> solution is meant to be compatible with.) >>=20 >>> Then the document goes on to say how to use new rtp header for >> captureID for MCC constituent, which I think I understand. But is the >> document saying sometimes you use this rtp header extension and >> sometimes you don't need it because ssrc suffices? Can anybody clarify t= his? >>>=20 >>> I think the proposed rtp header extension for captureID is intended to = be >> used only for identifying the captureID of the original capture used fo= r a >> purely switched MCC, correct? If so, could we call it "MCC constituent >> captureID" or something like that which better indicates what it means? >> Otherwise, just calling it CaptureID makes it sound more broad, like the= ID of >> the MCC itself, or the ID of a simple individual media capture that is n= ot >> switched. >>=20 >> I agree this might be a better name. >=20 From nobody Tue Nov 11 20:15: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 648451ACD1B for ; Tue, 11 Nov 2014 20:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXW__NsSd0zI for ; Tue, 11 Nov 2014 20:15:10 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B439C1AC43B for ; Tue, 11 Nov 2014 20:15:10 -0800 (PST) Received: from ppp118-209-83-124.lns20.mel4.internode.on.net ([118.209.83.124]:57217 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XoPJR-0006TL-SA for clue@ietf.org; Wed, 12 Nov 2014 15:13:45 +1100 Message-ID: <5462DECB.3040303@nteczone.com> Date: Wed, 12 Nov 2014 15:15:07 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.com> In-Reply-To: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/IF3qfNISaZGpSAo8FsEbcJcRLhE Subject: Re: [clue] Rtp mapping and ssrc and captureID X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 04:15:13 -0000 A further question related to requirement 5: Media-5: It must be possible for a source to be placed into a MCC even if the source is a "late joiner", i.e. was added to the conference after the receiver requested the MCC. Just to clarify, is this describing the case where the RTP source relates to an existing individual MC related to an MCC? or is this a new individual MC related to an MCC? Regards, Christian On 10/11/2014 2:30 AM, Duckworth, Mark wrote: > I have a couple questions about how the rtp mapping document describes > mappings between encodings, media captureID, and ssrc/csrc. > > In section 5, the part about meeting the Media-7 requirement, it says > in some cases (switched mixer and selective forwarding) the original > source of a switched capture can be determined from ssrc or csrc. I > don't understand how this is the case. The point is for the receiver > (media consumer) to be able to relate rtp packets to the original > media capture ID. So even if it has a ssrc value from ssrc or csrc > field in RTP header, how does this help? Where does the mapping from > ssrc to captureID come from in this case? > > Then the document goes on to say how to use new rtp header for > captureID for MCC constituent, which I think I understand. But is the > document saying sometimes you use this rtp header extension and > sometimes you don't need it because ssrc suffices? Can anybody clarify > this? > > I think the proposed rtp header extension for captureID is intended to > be used only for identifying the captureID of the original capture > used for a purely switched MCC, correct? If so, could we call it "MCC > constituent captureID" or something like that which better indicates > what it means? Otherwise, just calling it CaptureID makes it sound > more broad, like the ID of the MCC itself, or the ID of a simple > individual media capture that is not switched. > > Mark > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Nov 11 20:40: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 C74621ACD8F for ; Tue, 11 Nov 2014 20:40: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 LC_tHYfZ3XAx for ; Tue, 11 Nov 2014 20:40:28 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E9D1ACD8A for ; Tue, 11 Nov 2014 20:40:27 -0800 (PST) Received: from ppp118-209-83-124.lns20.mel4.internode.on.net ([118.209.83.124]:57380 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XoPhu-0001om-Ar for clue@ietf.org; Wed, 12 Nov 2014 15:39:02 +1100 Message-ID: <5462E4B8.4000003@nteczone.com> Date: Wed, 12 Nov 2014 15:40:24 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6655@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6655@CRPMBOXPRD08.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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5QgfRJRmEM3f3WTw7buR8MIX144 Subject: Re: [clue] provider ESTABLISHED and WAIT FOR CONF states X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 04:40:30 -0000 Hello Mark, Yes, good catch. After the ESTABLISHED state the MP should transition to another state where additional CONFs could be received. These additional CONFs shouldn't be subject to the same time outs associated with the initial ADV/CONF. Regards, Christian On 12/11/2014 8:06 AM, Duckworth, Mark wrote: > > Hello all, > > I have a question about the protocol state machine for a media > provider. Suppose it is in the ESTABLISHED state, and then the > consumer sends a new configure message. The provider receives it, and > goes to CONF RESPONSE state. Suppose for some reason the provider has > to send an error response back to the consumer. According to the state > diagram, the provider then goes to the WAIT FOR CONF state. This means > it is now waiting for a new configure message, and if it doesn’t > receive one it will eventually time out and go to TERMINATED state. > > Is this really what we want? It seems to me that in this case the > provider is still sending media that was previously configured with > the most recent valid configure message that got it into the > ESTABLISHED state in the first place. Since there was no change to the > advertisement, and there was a valid configure message previously, and > valid media is flowing, would it be better to maintain this state > rather than go back to WAIT FOR CONF? In other words, if the provider > is already in ESTABLISHED state, and it receives a configure and sends > an error response, should it go back to ESTABLISHED state rather than > go to WAIT FOR CONF? > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Nov 11 20:52: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 A7E311A923B for ; Tue, 11 Nov 2014 20:52: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 FpIbVHXhk7WS for ; Tue, 11 Nov 2014 20:52:04 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130D71ACDCF for ; Tue, 11 Nov 2014 20:52:04 -0800 (PST) Received: from ppp118-209-83-124.lns20.mel4.internode.on.net ([118.209.83.124]:57441 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XoPt8-0003O8-Mj for clue@ietf.org; Wed, 12 Nov 2014 15:50:38 +1100 Message-ID: <5462E770.5050903@nteczone.com> Date: Wed, 12 Nov 2014 15:52:00 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6663@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6663@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/-jrneyXHuerc_DhJy3Bkjy481TQ Subject: Re: [clue] provider should be able to bypass SDP O/A state in some cases X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 04:52:05 -0000 Hello Mark, I think in general the SDP O/A states should be separate from the CLUE states. The SDP O/A for the CLUE controlled streams could be sent before the ADVERTISEMENT. The linkage only comes about when both the CaptureIDs and their associated EncodingIDs are communicated. It gets complicated then because some media may be established and others not established. The established state would have to be expanded to address these possibilities. In order to simplify things perhaps we should not have any "SDP O/A" / "ESTABLISHED" state in the CLUE protocol document? So rather than having these states we have a state "Waiting for additional CONF" which transitions back to the CONF RESPONSE state. Regards, Christian On 12/11/2014 8:30 AM, Duckworth, Mark wrote: > > Hello all, > > In the protocol draft, it seems to me the provider state machine > requires the provider to initiate an SDP offer/answer even when it is > not necessary or desirable to do so. Suppose the provider is in > ESTABLISHED state, and then receives a new CONF message. Provider > goes to CONF RESPONSE state. Suppose the provider sends a successful > CONF RESPONSE back to the consumer. Now according to the state > diagram and the text in section 6.1, the provider initiates an SDP > O/A. But in this case I think SDP O/A is not required, because nothing > in the SDP should change from the previous O/A, is that right? If > not, then what in SDP should change? > > If the SDP O/A is not desired in this case, then maybe when in > ESTABLISHED receiving CONF should go to a different state similar to > CONF RESPONSE but which does not lead to O/A. This is related also to > my previous question about handling a configure error after > ESTABLISHED state. > > What do you think? > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Nov 11 21:12: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 9636F1A8831 for ; Tue, 11 Nov 2014 21:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 2UX3-RbCqzKj for ; Tue, 11 Nov 2014 21:12:37 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1F61A88EE for ; Tue, 11 Nov 2014 21:12:37 -0800 (PST) Received: from ppp118-209-83-124.lns20.mel4.internode.on.net ([118.209.83.124]:57570 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XoQD1-00065l-K7 for clue@ietf.org; Wed, 12 Nov 2014 16:11:11 +1100 Message-ID: <5462EC41.6050200@nteczone.com> Date: Wed, 12 Nov 2014 16:12:33 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/uase8pPedlGPCRkCJtOwxAgYG9Y Subject: [clue] Additional Protocol state machine comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 05:12:38 -0000 Hello all, A couple of more comments related to the state machine: 1) Clause 6.2 Para.4 - PREPARING ADV I assume this should be "PROCESSING ADV"? 2) Clause 6.2 Para.5 - ADV RECEIVED and ADV ACKED states don't exist in the diagram any more. I think you could simply this clause like the MP one by removing the SDP O/A and ESTABLISHED states and replacing it with a single state that waits for an ADV or could trigger sending another CONF if some Regards, Christian From nobody Tue Nov 11 21:34: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 508DC1A9033 for ; Tue, 11 Nov 2014 21:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=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 oxicG1BQWrQ9 for ; Tue, 11 Nov 2014 21:34:22 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C761A8967 for ; Tue, 11 Nov 2014 21:34:21 -0800 (PST) Received: from ppp118-209-83-124.lns20.mel4.internode.on.net ([118.209.83.124]:57684 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XoQY3-0000ne-Jl for clue@ietf.org; Wed, 12 Nov 2014 16:32:55 +1100 Message-ID: <5462F159.7040504@nteczone.com> Date: Wed, 12 Nov 2014 16:34:17 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <20141027130315.6434.28356.idtracker@ietfa.amsl.com> In-Reply-To: <20141027130315.6434.28356.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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/FNS3XIhZPhmHcTA0bNiR0ozKZ30 Subject: Re: [clue] I-D Action: draft-ietf-clue-datachannel-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: Wed, 12 Nov 2014 05:34:23 -0000 Hello Christer, Some comments on the latest draft: The "updated" example needs to be updated further, as the SDP for datachannel has been updated and the "DTLS over SCTP" error wasn't fixed : i.e. from a=group:CLUE 3 m=application 54111 SCTP/DTLS 54111 a=sctpmap:54111 webrtc-datachannel a=mid:3 to: a=group:CLUE 3 m=application 54111 DTLS/SCTP webrtc-datachannel a=sctp-port 5000 a=mid:3 Clause 5.3 needs to be updated because there's no longer a SDP sctpmap attribute. With regards to OPEN ISSUE 2, cl.5.4 and 5.5 are fairly generic but they ignore the aspect that for CLUE the SDP O/A procedures must associate the CLUE group to the "m=" line, i.e. as per the example. I think if these are added then you can remove open issue 2. I also think the draft needs to update the text around "/If an offerer, in a subsequent offer, wants to disable the CLUE Data Channel, it assigns a zero port value to the "m=" line describing the SCTPoDTLS association used to realize the CLUE Data Channel./" I think the draft needs to be updated to reflect that this will have the effect of closing the DTLS and SCTP association (which may not be desirable as other applications may share the association). As discussed previously to close just the CLUE data channel the m=line would be removed from the CLUE group. Regards, Christian On 28/10/2014 12:03 AM, 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 : CLUE Protocol Data Channel > Author : Christer Holmberg > Filename : draft-ietf-clue-datachannel-02.txt > Pages : 13 > Date : 2014-10-27 > > Abstract: > This document defines how to use the WebRTC Data Channel mechanism, > together with the Data Channel Establishment Protocol (DCEP) in order > to establish a data channel, referred to as CLUE Data Channel, for > transporting CLUE protocol messages between two CLUE entities. > > The document defines the SCTP considerations specific to a CLUE Data > Channel, the SDP offer/answer procedures for negotiating the > establishment of, and the DCEP procedures for opening, a CLUE Data > Channel. > > Details and procedures associated with the CLUE protocol are outside > the scope of this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-datachannel-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-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 nobody Wed Nov 12 07:53: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 82F6C1A1BAE for ; Wed, 12 Nov 2014 07:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 MrdaCpHxaRmN for ; Wed, 12 Nov 2014 07:53:19 -0800 (PST) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2EF1A1A6D for ; Wed, 12 Nov 2014 07:53:19 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id q107so9117747qgd.14 for ; Wed, 12 Nov 2014 07:53:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=J0/l12E1F/BdgRkyTJ7I6DA4NT2H/UKyayH8sUgKWhc=; b=ABhyoThNWjT/oMXJLlM0Bb8dYw5FUgU9m6rMgZeDK+n3Fw051URIJAvpEyLjY+SmDj MxXc/2OJvk+71iIMsC1lvEmlI3HU92p8mYtNfAe4UpTND8ghoXSw2W9p4rQyEsNS9rvs V/QZ/Jh1kPmOgr+EwOi20tRRfeQr5VCEe8EL6vMviM7M+AOJ5MdpfppSqM5Mzxv2B+Xn aNlr5RLv9oHip7ekPjW5Ri3iy+ZKuRJ+QR4V37T/ZxW4zx/F9LGgAlRbE1eM0So6z4o3 /qsoNymnJ6eGNwYGQ0S1oChcU3eYOLA09nGqbdzXKALujN6gQ5NQYT7qAyAVmuvs8OTU pbqw== X-Gm-Message-State: ALoCoQm8Z50NU3JgfCkk786Pk9s7kAYkrVjm5w91O/iMzC2kxerD/ikA3LkuknUJH1vuEHUfTzAx X-Received: by 10.224.12.145 with SMTP id x17mr62645565qax.13.1415807598914; Wed, 12 Nov 2014 07:53:18 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/+kMOddkSXc6dpTh+ULojK+0qAsA== Date: Wed, 12 Nov 2014 10:53:16 -0500 Message-ID: <95264a0e2abbc2c1c7bf25d9429da114@mail.gmail.com> To: roni.even@mail01.huawei.com, clue@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Wvi7d3JEr3TMxWDcAQi0NyEgEaI Subject: [clue] draft-even-clue-call-flows-00: comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 15:53:21 -0000 Hi, The following are a few comments concerning draft-even-clue-call-flows-00. Thanks, Brett ----- 1 ) Concerning section 3 INVITE, the To header is missing. 2) Concerning section 3 Contact headers, the feature tag should be "+sip.clue". 3) Concerning section 3 Contact headers, the Contact's URI should be within brackets so that the transport parameter can be decoded correctly. The corresponding modification would be to include the transport parameter within the ACK's Request-URI. 4) Concerning the SIP message formatting, potentially should remove the extra line separation except for between headers and body. From nobody Wed Nov 12 11:04: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 1E68C1ACECF for ; Wed, 12 Nov 2014 11:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 c7nF7x62zZ1x for ; Wed, 12 Nov 2014 11:03:39 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.202]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8A31ACEE2 for ; Wed, 12 Nov 2014 11:03:12 -0800 (PST) Received: from [216.82.241.100] by server-10.bemta-8.messagelabs.com id 04/87-31744-FEEA3645; Wed, 12 Nov 2014 19:03:11 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-15.tower-220.messagelabs.com!1415818982!13806042!4 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20457 invoked from network); 12 Nov 2014 19:03:09 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-15.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 12 Nov 2014 19:03:09 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 12 Nov 2014 11:00:04 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Wed, 12 Nov 2014 11:00:04 -0800 Thread-Topic: [clue] Rtp mapping and ssrc and captureID Thread-Index: Ac/+L0XjDGlsxA5TStGxdo9JBOsWcQAe2Vhw Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6738@CRPMBOXPRD08.polycom.com> References: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.com> <5462DECB.3040303@nteczone.com> In-Reply-To: <5462DECB.3040303@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Y9yp378WoZNu6q0i0nUsSkkQpRs Subject: Re: [clue] Rtp mapping and ssrc and captureID X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:03:55 -0000 I was interpreting it to mean a new individual MC that did not exist in the= advertisement the receiver based the configure on. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Tuesday, November 11, 2014 6:15 PM > To: clue@ietf.org > Subject: Re: [clue] Rtp mapping and ssrc and captureID >=20 > A further question related to requirement 5: >=20 > Media-5: It must be possible for a source to be placed into a MCC > even if the source is a "late joiner", i.e. was added to the > conference after the receiver requested the MCC. >=20 > Just to clarify, is this describing the case where the RTP source > relates to an existing individual MC related to an MCC? or is this a new > individual MC related to an MCC? >=20 > Regards, Christian >=20 >=20 > On 10/11/2014 2:30 AM, Duckworth, Mark wrote: > > I have a couple questions about how the rtp mapping document describes > > mappings between encodings, media captureID, and ssrc/csrc. > > > > In section 5, the part about meeting the Media-7 requirement, it says > > in some cases (switched mixer and selective forwarding) the original > > source of a switched capture can be determined from ssrc or csrc. I > > don't understand how this is the case. The point is for the receiver > > (media consumer) to be able to relate rtp packets to the original > > media capture ID. So even if it has a ssrc value from ssrc or csrc > > field in RTP header, how does this help? Where does the mapping from > > ssrc to captureID come from in this case? > > > > Then the document goes on to say how to use new rtp header for > > captureID for MCC constituent, which I think I understand. But is the > > document saying sometimes you use this rtp header extension and > > sometimes you don't need it because ssrc suffices? Can anybody clarify > > this? > > > > I think the proposed rtp header extension for captureID is intended to > > be used only for identifying the captureID of the original capture > > used for a purely switched MCC, correct? If so, could we call it "MCC > > constituent captureID" or something like that which better indicates > > what it means? Otherwise, just calling it CaptureID makes it sound > > more broad, like the ID of the MCC itself, or the ID of a simple > > individual media capture that is not switched. > > > > 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 nobody Wed Nov 12 11:21: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 6DF581ACF15 for ; Wed, 12 Nov 2014 11:21:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 k33qttCTon72 for ; Wed, 12 Nov 2014 11:21:50 -0800 (PST) Received: from server209.appriver.com (server209h.appriver.com [8.31.233.123]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123E71ACF0E for ; Wed, 12 Nov 2014 11:21:30 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/12/2014 2:21:28 PM X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/7/2014 8:53:38 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-178/SG:2 11/12/2014 2:21:01 PM X-GBUdb-Analysis: 0, 67.231.157.197, Ugly c=0.783275 p=-0.945 Source White X-Signature-Violations: 0-0-0-7035-c X-Note-419: 15.6258 ms. Fail:0 Chk:1329 of 1329 total X-Note: SCH-CT/SI:0-1329/SG:1 11/12/2014 2:21:21 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.157.197 X-Note-Reverse-DNS: mx0b-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G241 G242 G243 G244 G248 G249 G361 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.157.197] (HELO mx0b-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTP id 26685786; Wed, 12 Nov 2014 14:21:27 -0500 Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id sACJIRRx010013; Wed, 12 Nov 2014 14:21:28 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1qku220a5v-7 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 12 Nov 2014 14:21:27 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 13:16:37 -0600 From: Jonathan Lennox To: Christian Groves Thread-Topic: [clue] Rtp mapping and ssrc and captureID Thread-Index: Ac/8Mi7Z7GR3bb9xR62+BX+at36stACL1mCAAB975AA= Date: Wed, 12 Nov 2014 19:16:36 +0000 Message-ID: References: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.com> <5462DECB.3040303@nteczone.com> In-Reply-To: <5462DECB.3040303@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.187.214] Content-Type: text/plain; charset="Windows-1252" Content-ID: <65EBC4A214E0B543A70D26FE8504E417@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-12_08:2014-11-11,2014-11-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411120148 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/1HIWZjEGgV_LxeRwWsE5u4Y0oSg Cc: "clue@ietf.org" Subject: Re: [clue] Rtp mapping and ssrc and captureID X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:21:52 -0000 I=92m not sure what you=92re asking? What this is talking about is the cas= e where the receiver requested an MCC, and the original capture being put i= n the MC is new to the conference since the latest configure/advertisement. On Nov 11, 2014, at 6:15 PM, Christian Groves wrote: > A further question related to requirement 5: >=20 > Media-5: It must be possible for a source to be placed into a MCC > even if the source is a "late joiner", i.e. was added to the > conference after the receiver requested the MCC. >=20 > Just to clarify, is this describing the case where the RTP source relates= to an existing individual MC related to an MCC? or is this a new individua= l MC related to an MCC? >=20 > Regards, Christian >=20 >=20 > On 10/11/2014 2:30 AM, Duckworth, Mark wrote: >> I have a couple questions about how the rtp mapping document describes m= appings between encodings, media captureID, and ssrc/csrc. >>=20 >> In section 5, the part about meeting the Media-7 requirement, it says in= some cases (switched mixer and selective forwarding) the original source o= f a switched capture can be determined from ssrc or csrc. I don't understan= d how this is the case. The point is for the receiver (media consumer) to b= e able to relate rtp packets to the original media capture ID. So even if i= t has a ssrc value from ssrc or csrc field in RTP header, how does this hel= p? Where does the mapping from ssrc to captureID come from in this case? >>=20 >> Then the document goes on to say how to use new rtp header for captureID= for MCC constituent, which I think I understand. But is the document sayin= g sometimes you use this rtp header extension and sometimes you don't need = it because ssrc suffices? Can anybody clarify this? >>=20 >> I think the proposed rtp header extension for captureID is intended to b= e used only for identifying the captureID of the original capture used for= a purely switched MCC, correct? If so, could we call it "MCC constituent = captureID" or something like that which better indicates what it means? Oth= erwise, just calling it CaptureID makes it sound more broad, like the ID of= the MCC itself, or the ID of a simple individual media capture that is not= switched. >>=20 >> Mark >>=20 >>=20 >> _______________________________________________ >> 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 >=20 From nobody Wed Nov 12 11:49: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 EDDF31A19E5 for ; Wed, 12 Nov 2014 11:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 2Z72MiYgwC-A for ; Wed, 12 Nov 2014 11:49:38 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.108]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 165981A0A6B for ; Wed, 12 Nov 2014 11:49:38 -0800 (PST) Received: from [216.82.254.20] by server-12.bemta-7.messagelabs.com id E0/90-02703-1D9B3645; Wed, 12 Nov 2014 19:49:37 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-16.tower-47.messagelabs.com!1415821776!12652376!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1542 invoked from network); 12 Nov 2014 19:49:37 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-16.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 12 Nov 2014 19:49:37 -0000 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; Wed, 12 Nov 2014 11:49:36 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Wed, 12 Nov 2014 11:49:35 -0800 From: "Duckworth, Mark" To: Jonathan Lennox , Christian Groves Date: Wed, 12 Nov 2014 11:49:34 -0800 Thread-Topic: [clue] Rtp mapping and ssrc and captureID Thread-Index: Ac/8Mi7Z7GR3bb9xR62+BX+at36stACL1mCAAB975AAAC3uzoA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6754@CRPMBOXPRD08.polycom.com> References: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.com> <5462DECB.3040303@nteczone.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/moJkfiJYrm6SEIREGH05dcZ2opI Cc: "clue@ietf.org" Subject: Re: [clue] Rtp mapping and ssrc and captureID X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:49:41 -0000 Jonathan, should that be "... the original capture being put in the _MCC_ i= s new ..."? I think this is consistent with my earlier response to Christian's question= . Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Jonathan Lennox > Sent: Wednesday, November 12, 2014 9:17 AM > To: Christian Groves > Cc: clue@ietf.org > Subject: Re: [clue] Rtp mapping and ssrc and captureID >=20 > I'm not sure what you're asking? What this is talking about is the case = where > the receiver requested an MCC, and the original capture being put in the = MC > is new to the conference since the latest configure/advertisement. >=20 > On Nov 11, 2014, at 6:15 PM, Christian Groves > wrote: >=20 > > A further question related to requirement 5: > > > > Media-5: It must be possible for a source to be placed into a MCC > > even if the source is a "late joiner", i.e. was added to the > > conference after the receiver requested the MCC. > > > > Just to clarify, is this describing the case where the RTP source relat= es to an > existing individual MC related to an MCC? or is this a new individual MC > related to an MCC? > > > > Regards, Christian > > > > > > On 10/11/2014 2:30 AM, Duckworth, Mark wrote: > >> I have a couple questions about how the rtp mapping document describes > mappings between encodings, media captureID, and ssrc/csrc. > >> > >> In section 5, the part about meeting the Media-7 requirement, it says = in > some cases (switched mixer and selective forwarding) the original source = of a > switched capture can be determined from ssrc or csrc. I don't understand > how this is the case. The point is for the receiver (media consumer) to b= e > able to relate rtp packets to the original media capture ID. So even if i= t has a > ssrc value from ssrc or csrc field in RTP header, how does this help? Whe= re > does the mapping from ssrc to captureID come from in this case? > >> > >> Then the document goes on to say how to use new rtp header for > captureID for MCC constituent, which I think I understand. But is the > document saying sometimes you use this rtp header extension and > sometimes you don't need it because ssrc suffices? Can anybody clarify th= is? > >> > >> I think the proposed rtp header extension for captureID is intended to= be > used only for identifying the captureID of the original capture used for= a > purely switched MCC, correct? If so, could we call it "MCC constituent > captureID" or something like that which better indicates what it means? > Otherwise, just calling it CaptureID makes it sound more broad, like the = ID of > the MCC itself, or the ID of a simple individual media capture that is no= t > switched. > >> > >> Mark > >> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Nov 12 11:53:49 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95AA1A1A86 for ; Wed, 12 Nov 2014 11:53:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 sFiwdoU4dT0s for ; Wed, 12 Nov 2014 11:53:45 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875A11A19EA for ; Wed, 12 Nov 2014 11:53:45 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/12/2014 2:53:42 PM X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/7/2014 8:53:38 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-210/SG:2 11/12/2014 2:53:02 PM X-GBUdb-Analysis: 0, 67.231.157.197, Ugly c=0.78486 p=-0.945839 Source White X-Signature-Violations: 0-0-0-9304-c X-Note-419: 31.2525 ms. Fail:1 Chk:1329 of 1329 total X-Note: SCH-CT/SI:1-1329/SG:1 11/12/2014 2:53:41 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.157.197 X-Note-Reverse-DNS: mx0b-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G241 G242 G243 G244 G248 G249 G361 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.157.197] (HELO mx0b-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTP id 26703402; Wed, 12 Nov 2014 14:53:40 -0500 Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id sACJnEcE010414; Wed, 12 Nov 2014 14:53:41 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1qme098020-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 12 Nov 2014 14:53:40 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 13:53:40 -0600 From: Jonathan Lennox To: Mark Duckworth Thread-Topic: [clue] Rtp mapping and ssrc and captureID Thread-Index: Ac/8Mi7Z7GR3bb9xR62+BX+at36stACL1mCAAB975AAAC3uzoP//rnyA Date: Wed, 12 Nov 2014 19:53:39 +0000 Message-ID: References: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.com> <5462DECB.3040303@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6754@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6754@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.187.214] Content-Type: text/plain; charset="Windows-1252" Content-ID: <166F2C6F5C2A01408C9F8B7718642249@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-12_08:2014-11-11,2014-11-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411120154 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/UDag6GvmREnLkSfIN-z7TSW5aE8 Cc: "clue@ietf.org" Subject: Re: [clue] Rtp mapping and ssrc and captureID X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:53:48 -0000 Right, yes. I agree with your earlier response. Suggestions for better wording for the requirements in the RTP Usage draft = are welcome=85I tried to update them all to current Clue terminology, but t= hink they could still all be a lot clearer. On Nov 12, 2014, at 9:49 AM, Duckworth, Mark w= rote: > Jonathan, should that be "... the original capture being put in the _MCC_= is new ..."? > I think this is consistent with my earlier response to Christian's questi= on. > Mark >=20 >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Jonathan Lennox >> Sent: Wednesday, November 12, 2014 9:17 AM >> To: Christian Groves >> Cc: clue@ietf.org >> Subject: Re: [clue] Rtp mapping and ssrc and captureID >>=20 >> I'm not sure what you're asking? What this is talking about is the case= where >> the receiver requested an MCC, and the original capture being put in the= MC >> is new to the conference since the latest configure/advertisement. >>=20 >> On Nov 11, 2014, at 6:15 PM, Christian Groves >> wrote: >>=20 >>> A further question related to requirement 5: >>>=20 >>> Media-5: It must be possible for a source to be placed into a MCC >>> even if the source is a "late joiner", i.e. was added to the >>> conference after the receiver requested the MCC. >>>=20 >>> Just to clarify, is this describing the case where the RTP source relat= es to an >> existing individual MC related to an MCC? or is this a new individual MC >> related to an MCC? >>>=20 >>> Regards, Christian >>>=20 >>>=20 >>> On 10/11/2014 2:30 AM, Duckworth, Mark wrote: >>>> I have a couple questions about how the rtp mapping document describes >> mappings between encodings, media captureID, and ssrc/csrc. >>>>=20 >>>> In section 5, the part about meeting the Media-7 requirement, it says = in >> some cases (switched mixer and selective forwarding) the original source= of a >> switched capture can be determined from ssrc or csrc. I don't understand >> how this is the case. The point is for the receiver (media consumer) to = be >> able to relate rtp packets to the original media capture ID. So even if = it has a >> ssrc value from ssrc or csrc field in RTP header, how does this help? Wh= ere >> does the mapping from ssrc to captureID come from in this case? >>>>=20 >>>> Then the document goes on to say how to use new rtp header for >> captureID for MCC constituent, which I think I understand. But is the >> document saying sometimes you use this rtp header extension and >> sometimes you don't need it because ssrc suffices? Can anybody clarify t= his? >>>>=20 >>>> I think the proposed rtp header extension for captureID is intended to= be >> used only for identifying the captureID of the original capture used fo= r a >> purely switched MCC, correct? If so, could we call it "MCC constituent >> captureID" or something like that which better indicates what it means? >> Otherwise, just calling it CaptureID makes it sound more broad, like the= ID of >> the MCC itself, or the ID of a simple individual media capture that is n= ot >> switched. >>>>=20 >>>> Mark >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >>>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Wed Nov 12 12:36: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 73D6D1A017D for ; Wed, 12 Nov 2014 12:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.954 X-Spam-Level: * X-Spam-Status: No, score=1.954 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, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 HVZG4blYz_lr for ; Wed, 12 Nov 2014 12:35:59 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DDE1A6F53 for ; Wed, 12 Nov 2014 12:35:58 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so2253286wiw.14 for ; Wed, 12 Nov 2014 12:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=VMpZJcHiBZzRcbcTdzkxMihB/aHE/IK9N4l+D10d4pE=; b=J2xGqylTGHlzfJzSBunvDJxuvYhJs2zrmMqXadP68LXJMuu3pJjKgcBkXujfoS0yJV mPRRc/ODCJ0i0TtGFpVr3rgXj5Wfh/GWO8oOXB4pS8hDJONja6RrCJj0Nxpa5mUz9oAr KqsDT2tltB0wb5nFCxmBm0pt81H7URO6ZvjDsIKVrrRnqL4oED2OlRRcmyx4HHs43MWQ JdM80V3p+wRImA9b6PFF9Twu5UdvYBww5eAovMpXquC01l8bIwxCuz/Z5tLXx39JSQp2 REeXr70GFU9Jn003JT5IORT0d2MXRxNRzwqiqyAaPYh4mqY3/aO/I/6iFeQO6rhQ26m7 8vsA== X-Received: by 10.180.93.195 with SMTP id cw3mr52154301wib.68.1415824557713; Wed, 12 Nov 2014 12:35:57 -0800 (PST) Received: from RoniE (t2001067c037001361c7206c50e76b9b6.hotel-wireless.v6.meeting.ietf.org. [2001:67c:370:136:1c72:6c5:e76:b9b6]) by mx.google.com with ESMTPSA id w5sm22991667wif.18.2014.11.12.12.35.53 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Nov 2014 12:35:57 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> Date: Wed, 12 Nov 2014 22:35:45 +0200 Message-ID: <00eb01cffeb8$41829c30$c487d490$@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: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczEwHhC5T4AsgMzZABSFF3zwGQAdjcAfUTyVUCDwh2XQGoOPavm3HaKtA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/P75dZy4pLJWTAvHxgrvEAUpBqe4 Cc: clue@ietf.org Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:36:01 -0000 Hi, This will work when we have a single encoding per m-line in the SDP and I think it requires that each simulcast set will be in separate encoding group . Still it will provide less functionality than the one proposed in the simulcast proposal that will be discussed in MMUSIC If simulcast in SDP will progress using the unified plan where we have all encodings in one m-line we will need to specify that if an MC have max capture encoding >1 will it mean that it will map to two m-lines or will it use a configuration from an SDP description a=simulcast. We will need to see how it works with retransmission if we specify a retransmission RTP stream as an individual encoding. Roni > -----Original Message----- > From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > Sent: 06 November, 2014 9:45 PM > To: Roni Even > Cc: clue@ietf.org > Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > Hi Roni, > Do you still have questions about the way simulcast is handled in the > framework, regarding the attribute "Max capture encodings" and configuring > multiple encodings per capture? I was hoping we could resolve it on the list, or > do you think we need to talk about it in Honolulu? > Regards, > Mark > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark > > Sent: Monday, November 03, 2014 10:52 PM > > To: Roni Even; 'Christian Groves'; clue@ietf.org > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > -----Original Message----- > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > > > Sent: Monday, November 03, 2014 5:52 PM > > > To: 'Christian Groves'; clue@ietf.org > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > > -----Original Message----- > > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > > > > Groves > > > > Sent: 28 October, 2014 2:56 AM > > > > To: clue@ietf.org > > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > > > Hello Roni, > > > > > > > > As I mentioned in my original reply I think the RTP based > > > > simulcast > > method > > > is > > > > probably the cleanest approach. There would be nothing stopping a > > > > CLUE endpoint implementing it when it becomes available (like many > > > > other RTP features). Using CLUE for simulcast I think is possible > > > > for most > > > scenarios. The > > > > more complicated the scenarios the more MCs/encodings an endpoint > > will > > > > need to describe the situation. > > > > > > > > Please see my response below. > > > > > > > > Regards, Christian > > > > > > > > On 27/10/2014 9:20 PM, Roni Even wrote: > > > > > Hi Paul, > > > > > > > > > > If we want to be able to differentiate between simulcast and > > > > > switched capture, for example if we have a three camera system > > > > > that can send three MCs each with two encodings (simulcast) and > > > > > a switched capture (loudest speaker or two loudest speakers out > > > > > of three) using the same simulcast option for the each MC > > > > > currently sent. In this case we can have an MC with two > > > > > encodings and an MCC with the three MCs. This > > will > > > > > require us to clarify that having multiple individual encodings > > > > > in MC is simulcast and not switched and in MCC it is switched > > > > > and not > > simulcast. > > > > [CNG] I don't understand exactly what the issue is here? Could you > > > > use > > some > > > > pseudo syntax to explain what you're wanting to advertise? You say > > > > in > > the first > > > > sentence the switched capture uses simulcast but then in the last > > sentence you > > > > say the MCC is switched and not simulcast. I would think that an > > > > MCC can > > still > > > > be switched and simulcast, i.e. the endpoint simulcasts whatever > > > > source > > is > > > > switched into the media stream. > > > > If you want a pure switched MCC just set maxCaptureEncodings to 1 > > against the > > > > MCC. > > > > If you want a simultcast MCC just set maxCaptureEncodings to >=2 > > against the > > > > MCC. > > > > > > [Roni Even] The thing is that I am not sure how to advertise this example. > > > > > > The advertisement has two scene views: > > > 1. Scene view with VC0, VC1, VC2 each with two simulcast streams 2. > > > Scene view MCC3 as represented bellow > > > > > > The different MCs will be: > > > > > > VC0- (the left camera stream), encoding group=EG0, view=table, > > > MaxCaptures=2 > > > > [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture > > Encodings"? > > Don't confuse this with the MCC attribute MaxCaptures which means "Max > > number of Captures within a MCC". > > > > > VC1- (the center camera stream), encoding group=EG0, view=table, > > > MaxCaptures=2 > > > > > > VC2- (the right camera stream), encoding group=EG0, view=table. > > > MaxCaptures=2 > > > > > > MCC3 (VC0, VC1, VC2) - encoding group=EG0, view=room, > > MaxCaptures=2 > > > > [Duckworth, Mark] It isn't clear if you really mean "max capture encodings" > > or > > "max number of captures within a MCC". Those are two different things. > > > > > Now it may be implied here that VC0, VC1, VC2 are simulcast. > > > > [Duckworth, Mark] It depends how the consumer configures it. The > > provider advertisement says it supports simulcast, so the consumer can > > decide to use it or not. > > > > > What about MCC3? > > > Is it multicast from one of the cameras or is it 2 MCs out of the > > > three? (I assume it is the first since the view is room) > > > > [Duckworth, Mark] MCC3 can provide 2 MCs out of the three > > simultaneously only if it is composed, not if it is switched. The > > provider can give more information, if it wants to, with the MCC > > attribute "max number of captures within a MCC". > > > > > What if in the above example MaxCaptures=4 can it be for example > > > VC0, > > VC1 > > > each with two simulcast streams or is it VC0, VC1, VC2 and one of > > > them is > > simulcast? > > > > [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" > > capture. > > It sounds like you are talking about a switched case, not a composed > > case, so let's say MCC3 has the attribute "max number of captures within a > MCC" = 1. > > Now let's also suppose MCC3 has "max capture encodings" = 2. Then the > > consumer can ask for, say, MCC3 at 720p and SIF, for the two > > encodings. Then the provider decides when to switch among VC0, VC1, > > and VC2, and whichever one the provider is sending for MCC3 it sends > > it at both SIF and 720p, so MCC3 is simulcast at those two > > resolutions. > > > > > What I am trying to say is that using implied simulcast require text > > > explaining when a consumer can understand that the advertisement is > > > simulcast and not something else. > > > > > The other approach may be to have an attribute for an MC and MCC > > > that > > will > > > explicitly say that this is a simulcast offer. > > > > [Duckworth, Mark] I think the advertisement is clear to the consumer > > without any additional text or attributes added to the framework. It > > is already explicit, with the attribute "max capture encodings". If > > it is >1, then the advertisement is offering simulcast. > > > > > BTW: I think that the implied solution works when the individual > > > encodings are the same (spatial or different codces) what if we the > > > provider can send > > > H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four > > > different encodings but not all combinations allowed. How to > > > represent it in an advertisement? Is it : > > > > [Duckworth, Mark] I can consider this case after we get the first case > > above cleared up. > > > > > VC0- (the left camera stream), encoding group=EG0, view=table, > > > MaxCaptures=2 > > > > > > VC1- (the center camera stream), encoding group=EG0, view=table, > > > MaxCaptures=2 > > > > > > VC2- (the right camera stream), encoding group=EG0, view=table. > > > MaxCaptures=2 > > > > > > VC3- (the left camera stream), encoding group=EG1, view=table, > > > MaxCaptures=2 > > > > > > VC4- (the center camera stream), encoding group=EG1, view=table, > > > MaxCaptures=2 > > > > > > VC5- (the right camera stream), encoding group=EG1, view=table. > > > MaxCaptures=2 > > > > > > Where EG0 will be for H.264 and EG1 will be for VP8 and two scene > > > views > > > (VC0,VC1,VC2) (VC3, VC4, VC5)? > > > > > ... snip ... > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Nov 12 12:57: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 A025A1A1B35 for ; Wed, 12 Nov 2014 12:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.052 X-Spam-Level: ** X-Spam-Status: No, score=2.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 KNyYBZPRgJQ2 for ; Wed, 12 Nov 2014 12:57:12 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.6]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5304A1A1A68 for ; Wed, 12 Nov 2014 12:57:12 -0800 (PST) Received: from [216.82.249.212] by server-6.bemta-12.messagelabs.com id A0/61-03126-8A9C3645; Wed, 12 Nov 2014 20:57:12 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-13.tower-219.messagelabs.com!1415825830!12014335!4 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23946 invoked from network); 12 Nov 2014 20:57:11 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-13.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 12 Nov 2014 20:57:11 -0000 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, 12 Nov 2014 12:54:22 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Wed, 12 Nov 2014 12:54:22 -0800 From: "Duckworth, Mark" To: Roni Even Date: Wed, 12 Nov 2014 12:54:20 -0800 Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczEwHhC5T4AsgMzZABSFF3zwGQAdjcAfUTyVUCDwh2XQGoOPavm3HaKtCAAAU/QA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> <00eb01cffeb8$41829c30$c487d490$@gmail.com> In-Reply-To: <00eb01cffeb8$41829c30$c487d490$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Sec8cQ9cElFLUCxJpm02YrmD0js Cc: "clue@ietf.org" Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:57:16 -0000 Hi, I don't understand why simulcast would need separate encoding groups. Whether an MC maps to two m-lines or one m-line with a=3Dsimulcast is up to= the consumer, and specified in the configure message sent from consumer to= provider. The mapping is done via the encoding ID labels which link media= captures to m-lines. At least that is how I see it. Would you say retransmission streams are a separate issue from simulcast? = Or are they similar enough that it is really the same issue? Do SVC layere= d codec streams also fall into this category? Sounds like we do need some more discussion about this. My first thought i= s we should cover this in the signaling document. Mark > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Wednesday, November 12, 2014 10:36 AM > To: Duckworth, Mark > Cc: clue@ietf.org > Subject: RE: [clue] CLUE and Simulcast - ticket #47 >=20 > Hi, > This will work when we have a single encoding per m-line in the SDP and I > think it requires that each simulcast set will be in separate encoding gr= oup > . Still it will provide less functionality than the one proposed in the > simulcast proposal that will be discussed in MMUSIC > If simulcast in SDP will progress using the unified plan where we have al= l > encodings in one m-line we will need to specify that if an MC have max > capture encoding >1 will it mean that it will map to two m-lines or will = it > use a configuration from an SDP description a=3Dsimulcast. >=20 > We will need to see how it works with retransmission if we specify a > retransmission RTP stream as an individual encoding. >=20 > Roni >=20 > > -----Original Message----- > > From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > > Sent: 06 November, 2014 9:45 PM > > To: Roni Even > > Cc: clue@ietf.org > > Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > > > Hi Roni, > > Do you still have questions about the way simulcast is handled in the > > framework, regarding the attribute "Max capture encodings" and > configuring > > multiple encodings per capture? I was hoping we could resolve it on th= e > list, or > > do you think we need to talk about it in Honolulu? > > Regards, > > Mark > > > > > -----Original Message----- > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, > Mark > > > Sent: Monday, November 03, 2014 10:52 PM > > > To: Roni Even; 'Christian Groves'; clue@ietf.org > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > > -----Original Message----- > > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > > > > Sent: Monday, November 03, 2014 5:52 PM > > > > To: 'Christian Groves'; clue@ietf.org > > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > > > > -----Original Message----- > > > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > > > > > Groves > > > > > Sent: 28 October, 2014 2:56 AM > > > > > To: clue@ietf.org > > > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > > > > > Hello Roni, > > > > > > > > > > As I mentioned in my original reply I think the RTP based > > > > > simulcast > > > method > > > > is > > > > > probably the cleanest approach. There would be nothing stopping a > > > > > CLUE endpoint implementing it when it becomes available (like man= y > > > > > other RTP features). Using CLUE for simulcast I think is possible > > > > > for most > > > > scenarios. The > > > > > more complicated the scenarios the more MCs/encodings an > endpoint > > > will > > > > > need to describe the situation. > > > > > > > > > > Please see my response below. > > > > > > > > > > Regards, Christian > > > > > > > > > > On 27/10/2014 9:20 PM, Roni Even wrote: > > > > > > Hi Paul, > > > > > > > > > > > > If we want to be able to differentiate between simulcast and > > > > > > switched capture, for example if we have a three camera system > > > > > > that can send three MCs each with two encodings (simulcast) and > > > > > > a switched capture (loudest speaker or two loudest speakers out > > > > > > of three) using the same simulcast option for the each MC > > > > > > currently sent. In this case we can have an MC with two > > > > > > encodings and an MCC with the three MCs. This > > > will > > > > > > require us to clarify that having multiple individual encodings > > > > > > in MC is simulcast and not switched and in MCC it is switched > > > > > > and not > > > simulcast. > > > > > [CNG] I don't understand exactly what the issue is here? Could yo= u > > > > > use > > > some > > > > > pseudo syntax to explain what you're wanting to advertise? You sa= y > > > > > in > > > the first > > > > > sentence the switched capture uses simulcast but then in the last > > > sentence you > > > > > say the MCC is switched and not simulcast. I would think that an > > > > > MCC can > > > still > > > > > be switched and simulcast, i.e. the endpoint simulcasts whatever > > > > > source > > > is > > > > > switched into the media stream. > > > > > If you want a pure switched MCC just set maxCaptureEncodings to 1 > > > against the > > > > > MCC. > > > > > If you want a simultcast MCC just set maxCaptureEncodings to >=3D= 2 > > > against the > > > > > MCC. > > > > > > > > [Roni Even] The thing is that I am not sure how to advertise this > example. > > > > > > > > The advertisement has two scene views: > > > > 1. Scene view with VC0, VC1, VC2 each with two simulcast streams 2= . > > > > Scene view MCC3 as represented bellow > > > > > > > > The different MCs will be: > > > > > > > > VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, > > > > MaxCaptures=3D2 > > > > > > [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture > > > Encodings"? > > > Don't confuse this with the MCC attribute MaxCaptures which means > "Max > > > number of Captures within a MCC". > > > > > > > VC1- (the center camera stream), encoding group=3DEG0, view=3Dtabl= e, > > > > MaxCaptures=3D2 > > > > > > > > VC2- (the right camera stream), encoding group=3DEG0, view=3Dtable= . > > > > MaxCaptures=3D2 > > > > > > > > MCC3 (VC0, VC1, VC2) - encoding group=3DEG0, view=3Droom, > > > MaxCaptures=3D2 > > > > > > [Duckworth, Mark] It isn't clear if you really mean "max capture > encodings" > > > or > > > "max number of captures within a MCC". Those are two different thing= s. > > > > > > > Now it may be implied here that VC0, VC1, VC2 are simulcast. > > > > > > [Duckworth, Mark] It depends how the consumer configures it. The > > > provider advertisement says it supports simulcast, so the consumer ca= n > > > decide to use it or not. > > > > > > > What about MCC3? > > > > Is it multicast from one of the cameras or is it 2 MCs out of the > > > > three? (I assume it is the first since the view is room) > > > > > > [Duckworth, Mark] MCC3 can provide 2 MCs out of the three > > > simultaneously only if it is composed, not if it is switched. The > > > provider can give more information, if it wants to, with the MCC > > > attribute "max number of captures within a MCC". > > > > > > > What if in the above example MaxCaptures=3D4 can it be for example > > > > VC0, > > > VC1 > > > > each with two simulcast streams or is it VC0, VC1, VC2 and one of > > > > them is > > > simulcast? > > > > > > [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" > > > capture. > > > It sounds like you are talking about a switched case, not a composed > > > case, so let's say MCC3 has the attribute "max number of captures wit= hin > a > > MCC" =3D 1. > > > Now let's also suppose MCC3 has "max capture encodings" =3D 2. Then = the > > > consumer can ask for, say, MCC3 at 720p and SIF, for the two > > > encodings. Then the provider decides when to switch among VC0, VC1, > > > and VC2, and whichever one the provider is sending for MCC3 it sends > > > it at both SIF and 720p, so MCC3 is simulcast at those two > > > resolutions. > > > > > > > What I am trying to say is that using implied simulcast require tex= t > > > > explaining when a consumer can understand that the advertisement is > > > > simulcast and not something else. > > > > > > > The other approach may be to have an attribute for an MC and MCC > > > > that > > > will > > > > explicitly say that this is a simulcast offer. > > > > > > [Duckworth, Mark] I think the advertisement is clear to the consumer > > > without any additional text or attributes added to the framework. It > > > is already explicit, with the attribute "max capture encodings". If > > > it is >1, then the advertisement is offering simulcast. > > > > > > > BTW: I think that the implied solution works when the individual > > > > encodings are the same (spatial or different codces) what if we the > > > > provider can send > > > > H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four > > > > different encodings but not all combinations allowed. How to > > > > represent it in an advertisement? Is it : > > > > > > [Duckworth, Mark] I can consider this case after we get the first cas= e > > > above cleared up. > > > > > > > VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, > > > > MaxCaptures=3D2 > > > > > > > > VC1- (the center camera stream), encoding group=3DEG0, view=3Dtabl= e, > > > > MaxCaptures=3D2 > > > > > > > > VC2- (the right camera stream), encoding group=3DEG0, view=3Dtable= . > > > > MaxCaptures=3D2 > > > > > > > > VC3- (the left camera stream), encoding group=3DEG1, view=3Dtable, > > > > MaxCaptures=3D2 > > > > > > > > VC4- (the center camera stream), encoding group=3DEG1, view=3Dtabl= e, > > > > MaxCaptures=3D2 > > > > > > > > VC5- (the right camera stream), encoding group=3DEG1, view=3Dtable= . > > > > MaxCaptures=3D2 > > > > > > > > Where EG0 will be for H.264 and EG1 will be for VP8 and two scene > > > > views > > > > (VC0,VC1,VC2) (VC3, VC4, VC5)? > > > > > > > ... snip ... > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Nov 12 13:03: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 B33C91AD005 for ; Wed, 12 Nov 2014 13:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.141 X-Spam-Level: X-Spam-Status: No, score=-11.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 gMTC8wZRXqz9 for ; Wed, 12 Nov 2014 13:02:50 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DB61A90C7 for ; Wed, 12 Nov 2014 13:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11360; q=dns/txt; s=iport; t=1415826165; x=1417035765; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7hN/iG0Q+Ep5QueUChA0JVRNDIgUZ8dyYF7iLXk6ECU=; b=YD9NmI5dZNq56DKnbdZlvT1IOK3F//CFQIdY3tL8YSGLcEQWnk/lSdIS kdzlNja2Q1PV9WxdUBSXdGLrHWapRofdPsTjfTfOrkR9ZGNCwky2+rIcq HIxdhdYAAZs1lF9Rr7e6F6ZydUsuxAVXIvaHy52hUPxsBVnVOY4bVGrYs w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAKnJY1StJA2E/2dsb2JhbABbgw5UWQTMKwqHTwKBHRYBAQEBAX2EAgEBAQQBAQE3NAsMBAIBCBEEAQEBChQJByEGCxQJCAIEAQ0FCBOIEQMSDclQDYZuAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSNRgGBFIF0FDEHBoMngR4BBJI6iWSDR4NPinGGc4N8bQGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="96037154" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 12 Nov 2014 21:02:44 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sACL2hJP012459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Nov 2014 21:02:43 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.60]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 15:02:43 -0600 From: "Robert Hansen (rohanse2)" To: "Duckworth, Mark" , Roni Even Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: Ac/taerSE4jZUcK8SdO0mSUZD2VGvQB7gMaAABWp6oAAAxjkAAAGn+eAAC34ygAAQETSgAAA60oAAANg3QAAFnr6gAAekQwAAV3PqIAACnzkgACF3kqAAS+C04AAAKYmAAAMbrHA Date: Wed, 12 Nov 2014 21:02:43 +0000 Message-ID: References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> <00eb01cffeb8$41829c30$c487d490$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.123.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6q2avd3GAVL-9J6GY9CUR6DHvts Cc: "clue@ietf.org" Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 21:02:55 -0000 Yes, I'd have thought ideally multiple simulcast qualities, repair streams = etc would be defined under a single m-line and hence be a single encoding f= rom CLUE's perspective. That matches the unified plan and the proposal in d= raft-burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it would m= ean that negotiating simulcast qualities, repair flows etc would be purely = an SDP issue and wouldn't impact CLUE. Rob -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 12 November 2014 10:54 To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] CLUE and Simulcast - ticket #47 Hi, I don't understand why simulcast would need separate encoding groups. Whether an MC maps to two m-lines or one m-line with a=3Dsimulcast is up to= the consumer, and specified in the configure message sent from consumer to= provider. The mapping is done via the encoding ID labels which link media= captures to m-lines. At least that is how I see it. Would you say retransmission streams are a separate issue from simulcast? = Or are they similar enough that it is really the same issue? Do SVC layere= d codec streams also fall into this category? Sounds like we do need some more discussion about this. My first thought i= s we should cover this in the signaling document. Mark > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Wednesday, November 12, 2014 10:36 AM > To: Duckworth, Mark > Cc: clue@ietf.org > Subject: RE: [clue] CLUE and Simulcast - ticket #47 >=20 > Hi, > This will work when we have a single encoding per m-line in the SDP=20 > and I think it requires that each simulcast set will be in separate=20 > encoding group . Still it will provide less functionality than the one=20 > proposed in the simulcast proposal that will be discussed in MMUSIC If=20 > simulcast in SDP will progress using the unified plan where we have=20 > all encodings in one m-line we will need to specify that if an MC have=20 > max capture encoding >1 will it mean that it will map to two m-lines=20 > or will it use a configuration from an SDP description a=3Dsimulcast. >=20 > We will need to see how it works with retransmission if we specify a=20 > retransmission RTP stream as an individual encoding. >=20 > Roni >=20 > > -----Original Message----- > > From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > > Sent: 06 November, 2014 9:45 PM > > To: Roni Even > > Cc: clue@ietf.org > > Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > > > Hi Roni, > > Do you still have questions about the way simulcast is handled in=20 > > the framework, regarding the attribute "Max capture encodings" and > configuring > > multiple encodings per capture? I was hoping we could resolve it on=20 > > the > list, or > > do you think we need to talk about it in Honolulu? > > Regards, > > Mark > > > > > -----Original Message----- > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, > Mark > > > Sent: Monday, November 03, 2014 10:52 PM > > > To: Roni Even; 'Christian Groves'; clue@ietf.org > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > > -----Original Message----- > > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > > > > Sent: Monday, November 03, 2014 5:52 PM > > > > To: 'Christian Groves'; clue@ietf.org > > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > > > > -----Original Message----- > > > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of=20 > > > > > Christian Groves > > > > > Sent: 28 October, 2014 2:56 AM > > > > > To: clue@ietf.org > > > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > > > > > Hello Roni, > > > > > > > > > > As I mentioned in my original reply I think the RTP based=20 > > > > > simulcast > > > method > > > > is > > > > > probably the cleanest approach. There would be nothing=20 > > > > > stopping a CLUE endpoint implementing it when it becomes=20 > > > > > available (like many other RTP features). Using CLUE for=20 > > > > > simulcast I think is possible for most > > > > scenarios. The > > > > > more complicated the scenarios the more MCs/encodings an > endpoint > > > will > > > > > need to describe the situation. > > > > > > > > > > Please see my response below. > > > > > > > > > > Regards, Christian > > > > > > > > > > On 27/10/2014 9:20 PM, Roni Even wrote: > > > > > > Hi Paul, > > > > > > > > > > > > If we want to be able to differentiate between simulcast and=20 > > > > > > switched capture, for example if we have a three camera=20 > > > > > > system that can send three MCs each with two encodings=20 > > > > > > (simulcast) and a switched capture (loudest speaker or two=20 > > > > > > loudest speakers out of three) using the same simulcast=20 > > > > > > option for the each MC currently sent. In this case we can=20 > > > > > > have an MC with two encodings and an MCC with the three MCs.=20 > > > > > > This > > > will > > > > > > require us to clarify that having multiple individual=20 > > > > > > encodings in MC is simulcast and not switched and in MCC it=20 > > > > > > is switched and not > > > simulcast. > > > > > [CNG] I don't understand exactly what the issue is here? Could=20 > > > > > you use > > > some > > > > > pseudo syntax to explain what you're wanting to advertise? You=20 > > > > > say in > > > the first > > > > > sentence the switched capture uses simulcast but then in the=20 > > > > > last > > > sentence you > > > > > say the MCC is switched and not simulcast. I would think that=20 > > > > > an MCC can > > > still > > > > > be switched and simulcast, i.e. the endpoint simulcasts=20 > > > > > whatever source > > > is > > > > > switched into the media stream. > > > > > If you want a pure switched MCC just set maxCaptureEncodings=20 > > > > > to 1 > > > against the > > > > > MCC. > > > > > If you want a simultcast MCC just set maxCaptureEncodings to=20 > > > > > >=3D2 > > > against the > > > > > MCC. > > > > > > > > [Roni Even] The thing is that I am not sure how to advertise=20 > > > > this > example. > > > > > > > > The advertisement has two scene views: > > > > 1. Scene view with VC0, VC1, VC2 each with two simulcast streams 2= . > > > > Scene view MCC3 as represented bellow > > > > > > > > The different MCs will be: > > > > > > > > VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, > > > > MaxCaptures=3D2 > > > > > > [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture=20 > > > Encodings"? > > > Don't confuse this with the MCC attribute MaxCaptures which means > "Max > > > number of Captures within a MCC". > > > > > > > VC1- (the center camera stream), encoding group=3DEG0,=20 > > > > view=3Dtable, > > > > MaxCaptures=3D2 > > > > > > > > VC2- (the right camera stream), encoding group=3DEG0, view=3Dtable= . > > > > MaxCaptures=3D2 > > > > > > > > MCC3 (VC0, VC1, VC2) - encoding group=3DEG0, view=3Droom, > > > MaxCaptures=3D2 > > > > > > [Duckworth, Mark] It isn't clear if you really mean "max capture > encodings" > > > or > > > "max number of captures within a MCC". Those are two different thing= s. > > > > > > > Now it may be implied here that VC0, VC1, VC2 are simulcast. > > > > > > [Duckworth, Mark] It depends how the consumer configures it. The=20 > > > provider advertisement says it supports simulcast, so the consumer=20 > > > can decide to use it or not. > > > > > > > What about MCC3? > > > > Is it multicast from one of the cameras or is it 2 MCs out of=20 > > > > the three? (I assume it is the first since the view is room) > > > > > > [Duckworth, Mark] MCC3 can provide 2 MCs out of the three=20 > > > simultaneously only if it is composed, not if it is switched. The=20 > > > provider can give more information, if it wants to, with the MCC=20 > > > attribute "max number of captures within a MCC". > > > > > > > What if in the above example MaxCaptures=3D4 can it be for=20 > > > > example VC0, > > > VC1 > > > > each with two simulcast streams or is it VC0, VC1, VC2 and one=20 > > > > of them is > > > simulcast? > > > > > > [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" > > > capture. > > > It sounds like you are talking about a switched case, not a=20 > > > composed case, so let's say MCC3 has the attribute "max number of=20 > > > captures within > a > > MCC" =3D 1. > > > Now let's also suppose MCC3 has "max capture encodings" =3D 2. Then= =20 > > > the consumer can ask for, say, MCC3 at 720p and SIF, for the two=20 > > > encodings. Then the provider decides when to switch among VC0,=20 > > > VC1, and VC2, and whichever one the provider is sending for MCC3=20 > > > it sends it at both SIF and 720p, so MCC3 is simulcast at those=20 > > > two resolutions. > > > > > > > What I am trying to say is that using implied simulcast require=20 > > > > text explaining when a consumer can understand that the=20 > > > > advertisement is simulcast and not something else. > > > > > > > The other approach may be to have an attribute for an MC and MCC=20 > > > > that > > > will > > > > explicitly say that this is a simulcast offer. > > > > > > [Duckworth, Mark] I think the advertisement is clear to the=20 > > > consumer without any additional text or attributes added to the=20 > > > framework. It is already explicit, with the attribute "max=20 > > > capture encodings". If it is >1, then the advertisement is offering = simulcast. > > > > > > > BTW: I think that the implied solution works when the individual=20 > > > > encodings are the same (spatial or different codces) what if we=20 > > > > the provider can send > > > > H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four=20 > > > > different encodings but not all combinations allowed. How to=20 > > > > represent it in an advertisement? Is it : > > > > > > [Duckworth, Mark] I can consider this case after we get the first=20 > > > case above cleared up. > > > > > > > VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, > > > > MaxCaptures=3D2 > > > > > > > > VC1- (the center camera stream), encoding group=3DEG0,=20 > > > > view=3Dtable, > > > > MaxCaptures=3D2 > > > > > > > > VC2- (the right camera stream), encoding group=3DEG0, view=3Dtable= . > > > > MaxCaptures=3D2 > > > > > > > > VC3- (the left camera stream), encoding group=3DEG1, view=3Dtable, > > > > MaxCaptures=3D2 > > > > > > > > VC4- (the center camera stream), encoding group=3DEG1,=20 > > > > view=3Dtable, > > > > MaxCaptures=3D2 > > > > > > > > VC5- (the right camera stream), encoding group=3DEG1, view=3Dtable= . > > > > MaxCaptures=3D2 > > > > > > > > Where EG0 will be for H.264 and EG1 will be for VP8 and two=20 > > > > scene views > > > > (VC0,VC1,VC2) (VC3, VC4, VC5)? > > > > > > > ... snip ... > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Wed Nov 12 13:16: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 E907A1ACD45 for ; Wed, 12 Nov 2014 13:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 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.594, 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 qRaZPFn6wf21 for ; Wed, 12 Nov 2014 13:15:58 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44231AD383 for ; Wed, 12 Nov 2014 13:15:57 -0800 (PST) X-ASG-Debug-ID: 1415826955-05f27518d21d3c90001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id 7D3vJPI9YVqM9JWY (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 22:15:55 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from dhcp-a226.meeting.ietf.org (dhcp-a226.meeting.ietf.org [31.133.162.38]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id sACLFojT015333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Nov 2014 22:15:53 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_5304DF25-32D4-4936-9EBE-684D2FB5E2D0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] provider should be able to bypass SDP O/A state in some cases In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6663@CRPMBOXPRD08.polycom.com> Date: Wed, 12 Nov 2014 22:15:49 +0100 Message-Id: <26BAA00C-F165-41D6-BAB6-6BDCC94EE646@unina.it> References: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6663@CRPMBOXPRD08.polycom.com> To: "Duckworth, Mark" X-Mailer: Apple Mail (2.1878.6) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1415826955 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 31.133.162.38 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.11526 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: http://mailarchive.ietf.org/arch/msg/clue/9-i9eGjZH_y_nD1QaUoUYJOTNMo Cc: "clue@ietf.org" Subject: Re: [clue] provider should be able to bypass SDP O/A state in some cases X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 21:16:01 -0000 --Apple-Mail=_5304DF25-32D4-4936-9EBE-684D2FB5E2D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello Mark, please see in-line my comments ([SPR]). > In the protocol draft, it seems to me the provider state machine = requires the provider to initiate an SDP offer/answer even when it is = not necessary or desirable to do so. Suppose the provider is in = ESTABLISHED state, and then receives a new CONF message. Provider goes = to CONF RESPONSE state. Suppose the provider sends a successful CONF = RESPONSE back to the consumer. Now according to the state diagram and = the text in section 6.1, the provider initiates an SDP O/A. But in this = case I think SDP O/A is not required, because nothing in the SDP should = change from the previous O/A, is that right? If not, then what in SDP = should change? > =20 > If the SDP O/A is not desired in this case, then maybe when in = ESTABLISHED receiving CONF should go to a different state similar to = CONF RESPONSE but which does not lead to O/A. This is related also to = my previous question about handling a configure error after ESTABLISHED = state. [SPR] We gave for granted that a new CONFIGURE triggers a new O/A phase. = If this is not the case, we definitely have to think of a state machine = modification in-line with what you are suggesting. Simon > =20 > What do you think? > =20 > Mark > _______________________________________________ > 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=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_5304DF25-32D4-4936-9EBE-684D2FB5E2D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hello = Mark,

please see in-line my comments = ([SPR]).

In the protocol draft, it seems to me the provider = state machine requires the provider to initiate an SDP offer/answer even = when it is not necessary or desirable to do so.  Suppose the = provider is in ESTABLISHED state, and then receives a new CONF = message.  Provider goes to CONF RESPONSE state.  Suppose the = provider sends a successful CONF RESPONSE back to the consumer.  = Now according to the state diagram and the text in section 6.1, the = provider initiates an SDP O/A.  But in this case I think SDP O/A is = not required, because nothing in the SDP should change from the previous = O/A, is that right?  If not, then what in SDP should = change?
 
If the SDP = O/A is not desired in this case, then maybe when in ESTABLISHED = receiving CONF should go to  a different state similar to CONF = RESPONSE but which does not lead to O/A.  This is related also to = my previous question about handling a configure error after ESTABLISHED = state.

[SPR] We gave for = granted that a new CONFIGURE triggers a new O/A phase. If this is not = the case, we definitely have to think of a state machine modification = in-line with what you are = suggesting.

Simon

 
What do = you think?
 
Mark
__________________________________= _____________
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

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






= --Apple-Mail=_5304DF25-32D4-4936-9EBE-684D2FB5E2D0-- From nobody Wed Nov 12 13:25: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 C62661AD05D for ; Wed, 12 Nov 2014 13:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 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.594, 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 D3MfEOjHcJjl for ; Wed, 12 Nov 2014 13:25:19 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6133E1A9151 for ; Wed, 12 Nov 2014 13:25:19 -0800 (PST) X-ASG-Debug-ID: 1415827516-05f27518cd1d4040001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id dZn2VG1oUPARSFu1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2014 22:25:17 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from dhcp-a226.meeting.ietf.org (dhcp-a226.meeting.ietf.org [31.133.162.38]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id sACLPBLW015969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Nov 2014 22:25:15 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_8885CEB3-D91A-426C-864C-7F67F5649485" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] provider should be able to bypass SDP O/A state in some cases In-Reply-To: <5462E770.5050903@nteczone.com> Date: Wed, 12 Nov 2014 22:25:11 +0100 Message-Id: References: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6663@CRPMBOXPRD08.polycom.com> <5462E770.5050903@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.1878.6) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1415827517 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 31.133.162.38 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.11527 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: http://mailarchive.ietf.org/arch/msg/clue/iJc-6q7X1LHLXk9HupZAdS4x_vY Cc: clue@ietf.org Subject: Re: [clue] provider should be able to bypass SDP O/A state in some cases X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 21:25:24 -0000 --Apple-Mail=_8885CEB3-D91A-426C-864C-7F67F5649485 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello Christian, please see my comments in-line ([SPR]). > Hello Mark, >=20 > I think in general the SDP O/A states should be separate from the CLUE = states. The SDP O/A for the CLUE controlled streams could be sent before = the ADVERTISEMENT. The linkage only comes about when both the CaptureIDs = and their associated EncodingIDs are communicated. It gets complicated = then because some media may be established and others not established. = The established state would have to be expanded to address these = possibilities. [SPR] If you recall my last presentation at IETF90 in Toronto, SDP-CLUE = synchronization is actually one of the hot topics we have to tackle. > In order to simplify things perhaps we should not have any "SDP O/A" / = "ESTABLISHED" state in the CLUE protocol document? So rather than having = these states we have a state "Waiting for additional CONF" which = transitions back to the CONF RESPONSE state. [SPR] We put the "SDP O/A" state there as a place-holder for the above = mentioned CLUE-SDP synchronization procedure. =46rom the protocol's = perspective, there is a bi-directional link to the O/A phase: when you = are in a CLUE state which requires that you start a new O/A phase, you = call something like 'createOffer()' and then you wait for an = SDP-triggered event which is raised as soon as the O/A phase is = completed (in much the same way as the WebRTC browser's API does with = the underlying JSEP state machine). What's your feeling about this? Cheers, Simon > Regards, Christian >=20 > On 12/11/2014 8:30 AM, Duckworth, Mark wrote: >>=20 >> Hello all, >>=20 >> In the protocol draft, it seems to me the provider state machine = requires the provider to initiate an SDP offer/answer even when it is = not necessary or desirable to do so. Suppose the provider is in = ESTABLISHED state, and then receives a new CONF message. Provider goes = to CONF RESPONSE state. Suppose the provider sends a successful CONF = RESPONSE back to the consumer. Now according to the state diagram and = the text in section 6.1, the provider initiates an SDP O/A. But in this = case I think SDP O/A is not required, because nothing in the SDP should = change from the previous O/A, is that right? If not, then what in SDP = should change? >>=20 >> If the SDP O/A is not desired in this case, then maybe when in = ESTABLISHED receiving CONF should go to a different state similar to = CONF RESPONSE but which does not lead to O/A. This is related also to = my previous question about handling a configure error after ESTABLISHED = state. >>=20 >> What do you think? >>=20 >> Mark >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 >=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=_8885CEB3-D91A-426C-864C-7F67F5649485 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hello = Christian,

please see my comments in-line = ([SPR]).

Hello = Mark,

I think in general the SDP O/A states should be separate = from the CLUE states. The SDP O/A for the CLUE controlled streams could = be sent before the ADVERTISEMENT. The linkage only comes about when both = the CaptureIDs and their associated EncodingIDs are communicated. It = gets complicated then because some media may be established and others = not established. The established state would have to be expanded to = address these possibilities.

[SPR] If you = recall my last presentation at IETF90 in Toronto, SDP-CLUE = synchronization is actually one of the hot topics we have to = tackle.

In order to simplify things = perhaps we should not have any "SDP O/A" / "ESTABLISHED" state in the = CLUE protocol document? So rather than having these states we have a = state "Waiting for additional CONF" which transitions back to the CONF = RESPONSE state.

[SPR] We put the "SDP = O/A" state there as a place-holder for the above mentioned CLUE-SDP = synchronization procedure. =46rom the protocol's perspective, there is a = bi-directional link to the O/A phase: when you are in a CLUE state which = requires that you start a new O/A phase, you call something like = 'createOffer()' and then you wait for an SDP-triggered event which is = raised as soon as the O/A phase is completed (in much the same way as = the WebRTC browser's API does with the underlying JSEP state = machine).
What's your feeling about = this?

Cheers,

Simon

Regards, Christian

On = 12/11/2014 8:30 AM, Duckworth, Mark wrote:

Hello all,

In the protocol draft, it seems to = me the provider state machine requires the provider to initiate an SDP = offer/answer even when it is not necessary or desirable to do so. =  Suppose the provider is in ESTABLISHED state, and then receives a = new CONF message.  Provider goes to CONF RESPONSE state. =  Suppose the provider sends a successful CONF RESPONSE back to the = consumer.  Now according to the state diagram and the text in = section 6.1, the provider initiates an SDP O/A. But in this case I think = SDP O/A is not required, because nothing in the SDP should change from = the previous O/A, is that right?  If not, then what in SDP should = change?

If the SDP O/A is not desired in this case, then maybe = when in ESTABLISHED receiving CONF should go to  a different state = similar to CONF RESPONSE but which does not lead to O/A.  This is = related also to my previous question about handling a configure error = after ESTABLISHED state.

What do you = think?

Mark



________________________________________= _______
clue mailing list
clue@ietf.org
https://www.ietf.org/ma= ilman/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=_8885CEB3-D91A-426C-864C-7F67F5649485-- From nobody Wed Nov 12 15:07: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 E4A131A1AC4 for ; Wed, 12 Nov 2014 15:07: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 yQk4JR85h0G8 for ; Wed, 12 Nov 2014 15:07:10 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BA71A0AFE for ; Wed, 12 Nov 2014 15:07:10 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id n3so6495793wiv.8 for ; Wed, 12 Nov 2014 15:07:08 -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=7wLyV/iWLqshckdshj5fIKzjg756sFC0BdUpxIUAP9w=; b=KGtVrlNEJTLMw+Ik8/0gaFZdvbdqFpGgGkLS8sZsatF04K3FZpeYUWB7OZTWttCx3t qw5xHLd1gsLaEVxHiFfaQSdZ/PPhtQ2ex13+LnN8jEvllSuVqUSHv6OQ4roX9/EcdQaM kMmix7UO+NKdM7prhIXcI7TXpwhQh4BhnN+yrTXym5EcktpDvMObxeFGQVRQvmX6TWaL UWwRpy8rBB7j7kk4MydzBZMmCpXXJVAmeZ0MEx4UPV3v5tluVzF9in36I2yYOgL/b2pC 4nFL6UOwForDMlchwKYBCQ/5enPi7fF1zLUOjSHx4FtdxHbWsCpA/duxqjQqIEeJ1C4f /Kzg== X-Received: by 10.194.237.162 with SMTP id vd2mr67812260wjc.52.1415833628848; Wed, 12 Nov 2014 15:07:08 -0800 (PST) Received: from RoniE (t2001067c037001605015e90cd7432e35.wireless.v6.meeting.ietf.org. [2001:67c:370:160:5015:e90c:d743:2e35]) by mx.google.com with ESMTPSA id ce1sm33211606wjc.2.2014.11.12.15.07.06 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Nov 2014 15:07:08 -0800 (PST) From: "Roni Even" To: "'Brett Tate'" , , References: <95264a0e2abbc2c1c7bf25d9429da114@mail.gmail.com> In-Reply-To: <95264a0e2abbc2c1c7bf25d9429da114@mail.gmail.com> Date: Thu, 13 Nov 2014 01:07:01 +0200 Message-ID: <010a01cffecd$60ff5250$22fdf6f0$@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: AQEjsLIoW/NwNrKdJNm/vCstltK3dZ22OPJw Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/08--MkhrBSFpJlTeiCZxyHwg3Tc Subject: Re: [clue] draft-even-clue-call-flows-00: comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 23:07:23 -0000 Hi, Thanks for the comments. We intend to update the call flows using traces from an implementation probably after this meeting if the data model and protocol will become more stable Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Brett Tate > Sent: 12 November, 2014 5:53 PM > To: roni.even@mail01.huawei.com; clue@ietf.org > Subject: [clue] draft-even-clue-call-flows-00: comments > > Hi, > > The following are a few comments concerning draft-even-clue-call-flows-00. > > Thanks, > Brett > > ----- > > 1 ) Concerning section 3 INVITE, the To header is missing. > > 2) Concerning section 3 Contact headers, the feature tag should be "+sip.clue". > > 3) Concerning section 3 Contact headers, the Contact's URI should be within > brackets so that the transport parameter can be decoded correctly. > The corresponding modification would be to include the transport parameter > within the ACK's Request-URI. > > 4) Concerning the SIP message formatting, potentially should remove the extra > line separation except for between headers and body. > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Nov 12 15:30: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 1C5031A1B4B for ; Wed, 12 Nov 2014 15:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.954 X-Spam-Level: * X-Spam-Status: No, score=1.954 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, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 kKnlldJt6Mkd for ; Wed, 12 Nov 2014 15:30:02 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427E81A1B44 for ; Wed, 12 Nov 2014 15:30:02 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bs8so6523111wib.11 for ; Wed, 12 Nov 2014 15:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=Iiw0xHzeR2wm0X57Wu55iCIH/bTbyVAbGPQjWNZ4vzE=; b=mynDwZFK4y7PVxdGmobBDcsPp6DyDshQ2VrLXWb8LWuAdTe10jDFT+JStctHp72srT HeJINyq/seoPQWtDff6GEUAceOm+IHWtmU1wWG+lZWO97SGqIF0UkFOzzDMk15ZUH9TX 5PJ4AFQq6CGPTdEL6Jlet+AUA/GkNFTtNhRnDNeAi7js9XaANPCS/hn6M7ZLNt9vfjTk DmnmuDrn3hwI5kQfh59mQFXcrKQWM+ndR0qKGVM54FXRBWdTmIS1hmCfp/EOupvDE6GM sZuR8+b3FH+Bd+WaNuB2SLFchAv0cG7MMRDsInB7jG7YwR9cMPHVG5uY0iaTLLA3PRgx l49Q== X-Received: by 10.180.73.7 with SMTP id h7mr54073729wiv.83.1415835001069; Wed, 12 Nov 2014 15:30:01 -0800 (PST) Received: from RoniE (t2001067c037001605015e90cd7432e35.wireless.v6.meeting.ietf.org. [2001:67c:370:160:5015:e90c:d743:2e35]) by mx.google.com with ESMTPSA id fq1sm23431572wib.12.2014.11.12.15.29.57 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Nov 2014 15:30:00 -0800 (PST) From: "Roni Even" To: "'Robert Hansen \(rohanse2\)'" , "'Duckworth, Mark'" References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> <00eb01cffeb8$41829c30$c487d490$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> In-Reply-To: Date: Thu, 13 Nov 2014 01:29:52 +0200 Message-ID: <013a01cffed0$926aa8f0$b73ffad0$@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: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczEwHhC5T4AsgMzZABSFF3zwGQAdjcAfUTyVUCDwh2XQGoOPavAdEH7SsBo8jwxQK9+8R9m0B2XDA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/eKcbhKptJb-WeeMBbuNlS-0chN8 Cc: clue@ietf.org Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 23:30:05 -0000 Hi, This is what started the discussion. If we do not have SDP based simulcast based on unified plan, the only semantics is an encoding per m-line. We started the discussion based on this assumption that we can do simulcast in CLUE using an encoding per m-line and can bundle them Roni > -----Original Message----- > From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] > Sent: 12 November, 2014 11:03 PM > To: Duckworth, Mark; Roni Even > Cc: clue@ietf.org > Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > Yes, I'd have thought ideally multiple simulcast qualities, repair streams etc > would be defined under a single m-line and hence be a single encoding from > CLUE's perspective. That matches the unified plan and the proposal in draft- > burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it would mean > that negotiating simulcast qualities, repair flows etc would be purely an SDP > issue and wouldn't impact CLUE. > > Rob > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark > Sent: 12 November 2014 10:54 > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > Hi, > > I don't understand why simulcast would need separate encoding groups. > > Whether an MC maps to two m-lines or one m-line with a=simulcast is up to > the consumer, and specified in the configure message sent from consumer to > provider. The mapping is done via the encoding ID labels which link media > captures to m-lines. At least that is how I see it. > > Would you say retransmission streams are a separate issue from simulcast? Or > are they similar enough that it is really the same issue? Do SVC layered codec > streams also fall into this category? > > Sounds like we do need some more discussion about this. My first thought is > we should cover this in the signaling document. > > Mark > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Wednesday, November 12, 2014 10:36 AM > > To: Duckworth, Mark > > Cc: clue@ietf.org > > Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > > > Hi, > > This will work when we have a single encoding per m-line in the SDP > > and I think it requires that each simulcast set will be in separate > > encoding group . Still it will provide less functionality than the one > > proposed in the simulcast proposal that will be discussed in MMUSIC If > > simulcast in SDP will progress using the unified plan where we have > > all encodings in one m-line we will need to specify that if an MC have > > max capture encoding >1 will it mean that it will map to two m-lines > > or will it use a configuration from an SDP description a=simulcast. > > > > We will need to see how it works with retransmission if we specify a > > retransmission RTP stream as an individual encoding. > > > > Roni > > > > > -----Original Message----- > > > From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > > > Sent: 06 November, 2014 9:45 PM > > > To: Roni Even > > > Cc: clue@ietf.org > > > Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > > > > > Hi Roni, > > > Do you still have questions about the way simulcast is handled in > > > the framework, regarding the attribute "Max capture encodings" and > > configuring > > > multiple encodings per capture? I was hoping we could resolve it on > > > the > > list, or > > > do you think we need to talk about it in Honolulu? > > > Regards, > > > Mark > > > > > > > -----Original Message----- > > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, > > Mark > > > > Sent: Monday, November 03, 2014 10:52 PM > > > > To: Roni Even; 'Christian Groves'; clue@ietf.org > > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > > > > -----Original Message----- > > > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > > > > > Sent: Monday, November 03, 2014 5:52 PM > > > > > To: 'Christian Groves'; clue@ietf.org > > > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > > > > > > -----Original Message----- > > > > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > > > > > > Christian Groves > > > > > > Sent: 28 October, 2014 2:56 AM > > > > > > To: clue@ietf.org > > > > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > > > > > > > Hello Roni, > > > > > > > > > > > > As I mentioned in my original reply I think the RTP based > > > > > > simulcast > > > > method > > > > > is > > > > > > probably the cleanest approach. There would be nothing > > > > > > stopping a CLUE endpoint implementing it when it becomes > > > > > > available (like many other RTP features). Using CLUE for > > > > > > simulcast I think is possible for most > > > > > scenarios. The > > > > > > more complicated the scenarios the more MCs/encodings an > > endpoint > > > > will > > > > > > need to describe the situation. > > > > > > > > > > > > Please see my response below. > > > > > > > > > > > > Regards, Christian > > > > > > > > > > > > On 27/10/2014 9:20 PM, Roni Even wrote: > > > > > > > Hi Paul, > > > > > > > > > > > > > > If we want to be able to differentiate between simulcast and > > > > > > > switched capture, for example if we have a three camera > > > > > > > system that can send three MCs each with two encodings > > > > > > > (simulcast) and a switched capture (loudest speaker or two > > > > > > > loudest speakers out of three) using the same simulcast > > > > > > > option for the each MC currently sent. In this case we can > > > > > > > have an MC with two encodings and an MCC with the three MCs. > > > > > > > This > > > > will > > > > > > > require us to clarify that having multiple individual > > > > > > > encodings in MC is simulcast and not switched and in MCC it > > > > > > > is switched and not > > > > simulcast. > > > > > > [CNG] I don't understand exactly what the issue is here? Could > > > > > > you use > > > > some > > > > > > pseudo syntax to explain what you're wanting to advertise? You > > > > > > say in > > > > the first > > > > > > sentence the switched capture uses simulcast but then in the > > > > > > last > > > > sentence you > > > > > > say the MCC is switched and not simulcast. I would think that > > > > > > an MCC can > > > > still > > > > > > be switched and simulcast, i.e. the endpoint simulcasts > > > > > > whatever source > > > > is > > > > > > switched into the media stream. > > > > > > If you want a pure switched MCC just set maxCaptureEncodings > > > > > > to 1 > > > > against the > > > > > > MCC. > > > > > > If you want a simultcast MCC just set maxCaptureEncodings to > > > > > > >=2 > > > > against the > > > > > > MCC. > > > > > > > > > > [Roni Even] The thing is that I am not sure how to advertise > > > > > this > > example. > > > > > > > > > > The advertisement has two scene views: > > > > > 1. Scene view with VC0, VC1, VC2 each with two simulcast streams 2. > > > > > Scene view MCC3 as represented bellow > > > > > > > > > > The different MCs will be: > > > > > > > > > > VC0- (the left camera stream), encoding group=EG0, view=table, > > > > > MaxCaptures=2 > > > > > > > > [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture > > > > Encodings"? > > > > Don't confuse this with the MCC attribute MaxCaptures which means > > "Max > > > > number of Captures within a MCC". > > > > > > > > > VC1- (the center camera stream), encoding group=EG0, > > > > > view=table, > > > > > MaxCaptures=2 > > > > > > > > > > VC2- (the right camera stream), encoding group=EG0, view=table. > > > > > MaxCaptures=2 > > > > > > > > > > MCC3 (VC0, VC1, VC2) - encoding group=EG0, view=room, > > > > MaxCaptures=2 > > > > > > > > [Duckworth, Mark] It isn't clear if you really mean "max capture > > encodings" > > > > or > > > > "max number of captures within a MCC". Those are two different things. > > > > > > > > > Now it may be implied here that VC0, VC1, VC2 are simulcast. > > > > > > > > [Duckworth, Mark] It depends how the consumer configures it. The > > > > provider advertisement says it supports simulcast, so the consumer > > > > can decide to use it or not. > > > > > > > > > What about MCC3? > > > > > Is it multicast from one of the cameras or is it 2 MCs out of > > > > > the three? (I assume it is the first since the view is room) > > > > > > > > [Duckworth, Mark] MCC3 can provide 2 MCs out of the three > > > > simultaneously only if it is composed, not if it is switched. The > > > > provider can give more information, if it wants to, with the MCC > > > > attribute "max number of captures within a MCC". > > > > > > > > > What if in the above example MaxCaptures=4 can it be for > > > > > example VC0, > > > > VC1 > > > > > each with two simulcast streams or is it VC0, VC1, VC2 and one > > > > > of them is > > > > simulcast? > > > > > > > > [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" > > > > capture. > > > > It sounds like you are talking about a switched case, not a > > > > composed case, so let's say MCC3 has the attribute "max number of > > > > captures within > > a > > > MCC" = 1. > > > > Now let's also suppose MCC3 has "max capture encodings" = 2. Then > > > > the consumer can ask for, say, MCC3 at 720p and SIF, for the two > > > > encodings. Then the provider decides when to switch among VC0, > > > > VC1, and VC2, and whichever one the provider is sending for MCC3 > > > > it sends it at both SIF and 720p, so MCC3 is simulcast at those > > > > two resolutions. > > > > > > > > > What I am trying to say is that using implied simulcast require > > > > > text explaining when a consumer can understand that the > > > > > advertisement is simulcast and not something else. > > > > > > > > > The other approach may be to have an attribute for an MC and MCC > > > > > that > > > > will > > > > > explicitly say that this is a simulcast offer. > > > > > > > > [Duckworth, Mark] I think the advertisement is clear to the > > > > consumer without any additional text or attributes added to the > > > > framework. It is already explicit, with the attribute "max > > > > capture encodings". If it is >1, then the advertisement is offering > simulcast. > > > > > > > > > BTW: I think that the implied solution works when the individual > > > > > encodings are the same (spatial or different codces) what if we > > > > > the provider can send > > > > > H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four > > > > > different encodings but not all combinations allowed. How to > > > > > represent it in an advertisement? Is it : > > > > > > > > [Duckworth, Mark] I can consider this case after we get the first > > > > case above cleared up. > > > > > > > > > VC0- (the left camera stream), encoding group=EG0, view=table, > > > > > MaxCaptures=2 > > > > > > > > > > VC1- (the center camera stream), encoding group=EG0, > > > > > view=table, > > > > > MaxCaptures=2 > > > > > > > > > > VC2- (the right camera stream), encoding group=EG0, view=table. > > > > > MaxCaptures=2 > > > > > > > > > > VC3- (the left camera stream), encoding group=EG1, view=table, > > > > > MaxCaptures=2 > > > > > > > > > > VC4- (the center camera stream), encoding group=EG1, > > > > > view=table, > > > > > MaxCaptures=2 > > > > > > > > > > VC5- (the right camera stream), encoding group=EG1, view=table. > > > > > MaxCaptures=2 > > > > > > > > > > Where EG0 will be for H.264 and EG1 will be for VP8 and two > > > > > scene views > > > > > (VC0,VC1,VC2) (VC3, VC4, VC5)? > > > > > > > > > ... snip ... > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Nov 12 16:25: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 50C801A00F9 for ; Wed, 12 Nov 2014 16:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 BLXVBc5n8A5J for ; Wed, 12 Nov 2014 16:24:57 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025981A0147 for ; Wed, 12 Nov 2014 16:24:20 -0800 (PST) Received: from ppp118-209-5-12.lns20.mel4.internode.on.net ([118.209.5.12]:53275 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XoiBQ-0001pW-GS; Thu, 13 Nov 2014 11:22:44 +1100 Message-ID: <5463FA30.5050503@nteczone.com> Date: Thu, 13 Nov 2014 11:24:16 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jonathan Lennox , Mark Duckworth References: <6juecfb2b2xv7yumt6pm1vtw.1415545907193@email.android.com> <5462DECB.3040303@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6754@CRPMBOXPRD08.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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/cidOzBf8KhiLpit7UqUW_jTJTNc Cc: "clue@ietf.org" Subject: Re: [clue] Rtp mapping and ssrc and captureID X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 00:25:00 -0000 When reading the requirement it could be interpreted that the source was added to the existing MCC and becomes part of the media stream without additional CLUE signalling. Also media-5 isn't mentioned in the CLUE section which further suggests no relation to CLUE. With the clarification it's clear it gets added as part of normal CLUE signalling. How does this wording sound? Media-5: It must be possible for a new source to be placed into an Advertised MCC even if the source is a "late joiner", i.e. the MCC was previously Advertised and added to the conference after the receiver requested the MCC. Regards, Christian On 13/11/2014 6:53 AM, Jonathan Lennox wrote: > Right, yes. I agree with your earlier response. > > Suggestions for better wording for the requirements in the RTP Usage draft are welcome…I tried to update them all to current Clue terminology, but think they could still all be a lot clearer. > > On Nov 12, 2014, at 9:49 AM, Duckworth, Mark wrote: > >> Jonathan, should that be "... the original capture being put in the _MCC_ is new ..."? >> I think this is consistent with my earlier response to Christian's question. >> Mark >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Jonathan Lennox >>> Sent: Wednesday, November 12, 2014 9:17 AM >>> To: Christian Groves >>> Cc: clue@ietf.org >>> Subject: Re: [clue] Rtp mapping and ssrc and captureID >>> >>> I'm not sure what you're asking? What this is talking about is the case where >>> the receiver requested an MCC, and the original capture being put in the MC >>> is new to the conference since the latest configure/advertisement. >>> >>> On Nov 11, 2014, at 6:15 PM, Christian Groves >>> wrote: >>> >>>> A further question related to requirement 5: >>>> >>>> Media-5: It must be possible for a source to be placed into a MCC >>>> even if the source is a "late joiner", i.e. was added to the >>>> conference after the receiver requested the MCC. >>>> >>>> Just to clarify, is this describing the case where the RTP source relates to an >>> existing individual MC related to an MCC? or is this a new individual MC >>> related to an MCC? >>>> Regards, Christian >>>> >>>> >>>> On 10/11/2014 2:30 AM, Duckworth, Mark wrote: >>>>> I have a couple questions about how the rtp mapping document describes >>> mappings between encodings, media captureID, and ssrc/csrc. >>>>> In section 5, the part about meeting the Media-7 requirement, it says in >>> some cases (switched mixer and selective forwarding) the original source of a >>> switched capture can be determined from ssrc or csrc. I don't understand >>> how this is the case. The point is for the receiver (media consumer) to be >>> able to relate rtp packets to the original media capture ID. So even if it has a >>> ssrc value from ssrc or csrc field in RTP header, how does this help? Where >>> does the mapping from ssrc to captureID come from in this case? >>>>> Then the document goes on to say how to use new rtp header for >>> captureID for MCC constituent, which I think I understand. But is the >>> document saying sometimes you use this rtp header extension and >>> sometimes you don't need it because ssrc suffices? Can anybody clarify this? >>>>> I think the proposed rtp header extension for captureID is intended to be >>> used only for identifying the captureID of the original capture used for a >>> purely switched MCC, correct? If so, could we call it "MCC constituent >>> captureID" or something like that which better indicates what it means? >>> Otherwise, just calling it CaptureID makes it sound more broad, like the ID of >>> the MCC itself, or the ID of a simple individual media capture that is not >>> switched. >>>>> Mark >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Nov 12 16:41: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 1958D1A00A6 for ; Wed, 12 Nov 2014 16:41:40 -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 jvwG_iSyMKXN for ; Wed, 12 Nov 2014 16:41:36 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7619A1A0074 for ; Wed, 12 Nov 2014 16:41:36 -0800 (PST) Received: from ppp118-209-5-12.lns20.mel4.internode.on.net ([118.209.5.12]:53405 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XoiS7-0004kC-Q9; Thu, 13 Nov 2014 11:39:59 +1100 Message-ID: <5463FE3B.7020701@nteczone.com> Date: Thu, 13 Nov 2014 11:41:31 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Simon Pietro Romano References: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6663@CRPMBOXPRD08.polycom.com> <5462E770.5050903@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/U6NIAxK4GEk-MgyJ5as0AkzUciw Cc: clue@ietf.org Subject: Re: [clue] provider should be able to bypass SDP O/A state in some cases X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 00:41:40 -0000 Hello Simon, all, SDP-CLUE interaction is something we have to address but I'm not convinced that we have to go to the level of specifying a detailed state machine for this. From a CLUE protocol draft perspective we can model inputs at a higher level rather than linking to specific SDP O/A events. Really the key criteria is for a Configure whether encoding information has been received. We have the signalling draft that specifies CLUE interwork with SDP O/A. It seems to me that we'd have an overlap in the procedures if we go into detail about SDP O/A in the protocol draft. Do we gain much by going to this detail? Regards, Christian On 13/11/2014 8:25 AM, Simon Pietro Romano wrote: > Hello Christian, > > please see my comments in-line ([SPR]). > >> Hello Mark, >> >> I think in general the SDP O/A states should be separate from the >> CLUE states. The SDP O/A for the CLUE controlled streams could be >> sent before the ADVERTISEMENT. The linkage only comes about when both >> the CaptureIDs and their associated EncodingIDs are communicated. It >> gets complicated then because some media may be established and >> others not established. The established state would have to be >> expanded to address these possibilities. > > [SPR] If you recall my last presentation at IETF90 in Toronto, > SDP-CLUE synchronization is actually one of the hot topics we have to > tackle. > >> In order to simplify things perhaps we should not have any "SDP O/A" >> / "ESTABLISHED" state in the CLUE protocol document? So rather than >> having these states we have a state "Waiting for additional CONF" >> which transitions back to the CONF RESPONSE state. > > [SPR] We put the "SDP O/A" state there as a place-holder for the above > mentioned CLUE-SDP synchronization procedure. From the protocol's > perspective, there is a bi-directional link to the O/A phase: when you > are in a CLUE state which requires that you start a new O/A phase, you > call something like 'createOffer()' and then you wait for an > SDP-triggered event which is raised as soon as the O/A phase is > completed (in much the same way as the WebRTC browser's API does with > the underlying JSEP state machine). > What's your feeling about this? > > Cheers, > > Simon > >> Regards, Christian >> >> On 12/11/2014 8:30 AM, Duckworth, Mark wrote: >>> >>> Hello all, >>> >>> In the protocol draft, it seems to me the provider state machine >>> requires the provider to initiate an SDP offer/answer even when it >>> is not necessary or desirable to do so. Suppose the provider is in >>> ESTABLISHED state, and then receives a new CONF message. Provider >>> goes to CONF RESPONSE state. Suppose the provider sends a >>> successful CONF RESPONSE back to the consumer. Now according to the >>> state diagram and the text in section 6.1, the provider initiates an >>> SDP O/A. But in this case I think SDP O/A is not required, because >>> nothing in the SDP should change from the previous O/A, is that >>> right? If not, then what in SDP should change? >>> >>> If the SDP O/A is not desired in this case, then maybe when in >>> ESTABLISHED receiving CONF should go to a different state similar >>> to CONF RESPONSE but which does not lead to O/A. This is related >>> also to my previous question about handling a configure error after >>> ESTABLISHED state. >>> >>> 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 >> > > _\\|//_ > ( 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 nobody Wed Nov 12 19:27: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 431281A1B02 for ; Wed, 12 Nov 2014 19:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.719 X-Spam-Level: ** X-Spam-Status: No, score=2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 3dt_Vz1hIUkO for ; Wed, 12 Nov 2014 19:27:47 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71EFE1A1AE4 for ; Wed, 12 Nov 2014 19:27:47 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-03v.sys.comcast.net with comcast id ErTP1p0054ueUHc01rTnQe; Thu, 13 Nov 2014 03:27:47 +0000 Received: from dhcp-b28b.meeting.ietf.org ([31.133.178.139]) by resomta-po-03v.sys.comcast.net with comcast id ErRd1p00H30qcoX01rRgmJ; Thu, 13 Nov 2014 03:25:45 +0000 Message-ID: <546424B1.7010408@alum.mit.edu> Date: Wed, 12 Nov 2014 17:25:37 -1000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> <00eb01cffeb8$41829c30$c487d490$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> <013a01cffed0$926aa8f0$b73ffad0$@gmail.com> In-Reply-To: <013a01cffed0$926aa8f0$b73ffad0$@gmail.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=q20140121; t=1415849267; bh=fitegsiwTpYSqTaKdlV9OJmnbZBDNDFcjQnFXbn9WWw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=u16FOqZj9ZbNmBxyXB2Mg5ojIBb/Y9ludd/DP5xSAISDdukKxFWtvA1Qu/B2T84Zr 9tW2DFNTJC16V6P2p+SngMREVnX0aNQa61Qhas8ZdFh5pE8JJY2f/7RJKrLvJZbKwi eShac4yGTq0OX1H7ccVa5iQgOTPCYcyFXOnVTbG2uJ8kQ2jR9+5OsqUfJXosMx2dPV fl4sFSWKSD7Et341hTHIcuEAlsb40dW0Q2lBen4fLITTdjUndbccOQ5bPENYePpryz G/kEdEpnQVcD432UASCoa5DWVMk+VsG6iBuh9bJXqJjMoOnZRnHbNp+qYZc61RlZRM ySyhMyWZwWE5w== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/4dykGtd7yQWvNsdaRm0LiCsUs74 Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 03:27:50 -0000 If an sdp-based mechanism is published that allows simulcast in a single m-line, then clue gets to take advantage of that *for free*. I don't know that we need to say anything about that. The question we have to ask is: do we want to remove the clue-specific mechanism that is already present in our data model? To that I will add the corollary question: is there any cost to having that option in there? I can't see any cost. - Advertisers don't have to use it in their advertisements. - Consumers can't use it in Configure if it wasn't in the advertisement - Consumers don't have to use it if it is in the advertisement. So I see no harm in leaving it in. And some potential benefit to having it there. Thanks, Paul On 11/12/14 1:29 PM, Roni Even wrote: > Hi, > This is what started the discussion. If we do not have SDP based simulcast > based on unified plan, the only semantics is an encoding per m-line. We > started the discussion based on this assumption that we can do simulcast in > CLUE using an encoding per m-line and can bundle them > Roni > >> -----Original Message----- >> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] >> Sent: 12 November, 2014 11:03 PM >> To: Duckworth, Mark; Roni Even >> Cc: clue@ietf.org >> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >> >> Yes, I'd have thought ideally multiple simulcast qualities, repair streams > etc >> would be defined under a single m-line and hence be a single encoding from >> CLUE's perspective. That matches the unified plan and the proposal in > draft- >> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it would mean >> that negotiating simulcast qualities, repair flows etc would be purely an > SDP >> issue and wouldn't impact CLUE. >> >> Rob >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark >> Sent: 12 November 2014 10:54 >> To: Roni Even >> Cc: clue@ietf.org >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >> >> Hi, >> >> I don't understand why simulcast would need separate encoding groups. >> >> Whether an MC maps to two m-lines or one m-line with a=simulcast is up to >> the consumer, and specified in the configure message sent from consumer to >> provider. The mapping is done via the encoding ID labels which link media >> captures to m-lines. At least that is how I see it. >> >> Would you say retransmission streams are a separate issue from simulcast? > Or >> are they similar enough that it is really the same issue? Do SVC layered > codec >> streams also fall into this category? >> >> Sounds like we do need some more discussion about this. My first thought > is >> we should cover this in the signaling document. >> >> Mark >> >>> -----Original Message----- >>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>> Sent: Wednesday, November 12, 2014 10:36 AM >>> To: Duckworth, Mark >>> Cc: clue@ietf.org >>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>> >>> Hi, >>> This will work when we have a single encoding per m-line in the SDP >>> and I think it requires that each simulcast set will be in separate >>> encoding group . Still it will provide less functionality than the one >>> proposed in the simulcast proposal that will be discussed in MMUSIC If >>> simulcast in SDP will progress using the unified plan where we have >>> all encodings in one m-line we will need to specify that if an MC have >>> max capture encoding >1 will it mean that it will map to two m-lines >>> or will it use a configuration from an SDP description a=simulcast. >>> >>> We will need to see how it works with retransmission if we specify a >>> retransmission RTP stream as an individual encoding. >>> >>> Roni >>> >>>> -----Original Message----- >>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] >>>> Sent: 06 November, 2014 9:45 PM >>>> To: Roni Even >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> Hi Roni, >>>> Do you still have questions about the way simulcast is handled in >>>> the framework, regarding the attribute "Max capture encodings" and >>> configuring >>>> multiple encodings per capture? I was hoping we could resolve it on >>>> the >>> list, or >>>> do you think we need to talk about it in Honolulu? >>>> Regards, >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, >>> Mark >>>>> Sent: Monday, November 03, 2014 10:52 PM >>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org >>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >>>>>> Sent: Monday, November 03, 2014 5:52 PM >>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>> Christian Groves >>>>>>> Sent: 28 October, 2014 2:56 AM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>> >>>>>>> Hello Roni, >>>>>>> >>>>>>> As I mentioned in my original reply I think the RTP based >>>>>>> simulcast >>>>> method >>>>>> is >>>>>>> probably the cleanest approach. There would be nothing >>>>>>> stopping a CLUE endpoint implementing it when it becomes >>>>>>> available (like many other RTP features). Using CLUE for >>>>>>> simulcast I think is possible for most >>>>>> scenarios. The >>>>>>> more complicated the scenarios the more MCs/encodings an >>> endpoint >>>>> will >>>>>>> need to describe the situation. >>>>>>> >>>>>>> Please see my response below. >>>>>>> >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: >>>>>>>> Hi Paul, >>>>>>>> >>>>>>>> If we want to be able to differentiate between simulcast and >>>>>>>> switched capture, for example if we have a three camera >>>>>>>> system that can send three MCs each with two encodings >>>>>>>> (simulcast) and a switched capture (loudest speaker or two >>>>>>>> loudest speakers out of three) using the same simulcast >>>>>>>> option for the each MC currently sent. In this case we can >>>>>>>> have an MC with two encodings and an MCC with the three MCs. >>>>>>>> This >>>>> will >>>>>>>> require us to clarify that having multiple individual >>>>>>>> encodings in MC is simulcast and not switched and in MCC it >>>>>>>> is switched and not >>>>> simulcast. >>>>>>> [CNG] I don't understand exactly what the issue is here? Could >>>>>>> you use >>>>> some >>>>>>> pseudo syntax to explain what you're wanting to advertise? You >>>>>>> say in >>>>> the first >>>>>>> sentence the switched capture uses simulcast but then in the >>>>>>> last >>>>> sentence you >>>>>>> say the MCC is switched and not simulcast. I would think that >>>>>>> an MCC can >>>>> still >>>>>>> be switched and simulcast, i.e. the endpoint simulcasts >>>>>>> whatever source >>>>> is >>>>>>> switched into the media stream. >>>>>>> If you want a pure switched MCC just set maxCaptureEncodings >>>>>>> to 1 >>>>> against the >>>>>>> MCC. >>>>>>> If you want a simultcast MCC just set maxCaptureEncodings to >>>>>>>> =2 >>>>> against the >>>>>>> MCC. >>>>>> >>>>>> [Roni Even] The thing is that I am not sure how to advertise >>>>>> this >>> example. >>>>>> >>>>>> The advertisement has two scene views: >>>>>> 1. Scene view with VC0, VC1, VC2 each with two simulcast streams > 2. >>>>>> Scene view MCC3 as represented bellow >>>>>> >>>>>> The different MCs will be: >>>>>> >>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, >>>>>> MaxCaptures=2 >>>>> >>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture >>>>> Encodings"? >>>>> Don't confuse this with the MCC attribute MaxCaptures which means >>> "Max >>>>> number of Captures within a MCC". >>>>> >>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>> view=table, >>>>>> MaxCaptures=2 >>>>>> >>>>>> VC2- (the right camera stream), encoding group=EG0, view=table. >>>>>> MaxCaptures=2 >>>>>> >>>>>> MCC3 (VC0, VC1, VC2) - encoding group=EG0, view=room, >>>>> MaxCaptures=2 >>>>> >>>>> [Duckworth, Mark] It isn't clear if you really mean "max capture >>> encodings" >>>>> or >>>>> "max number of captures within a MCC". Those are two different > things. >>>>> >>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. >>>>> >>>>> [Duckworth, Mark] It depends how the consumer configures it. The >>>>> provider advertisement says it supports simulcast, so the consumer >>>>> can decide to use it or not. >>>>> >>>>>> What about MCC3? >>>>>> Is it multicast from one of the cameras or is it 2 MCs out of >>>>>> the three? (I assume it is the first since the view is room) >>>>> >>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three >>>>> simultaneously only if it is composed, not if it is switched. The >>>>> provider can give more information, if it wants to, with the MCC >>>>> attribute "max number of captures within a MCC". >>>>> >>>>>> What if in the above example MaxCaptures=4 can it be for >>>>>> example VC0, >>>>> VC1 >>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and one >>>>>> of them is >>>>> simulcast? >>>>> >>>>> [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" >>>>> capture. >>>>> It sounds like you are talking about a switched case, not a >>>>> composed case, so let's say MCC3 has the attribute "max number of >>>>> captures within >>> a >>>> MCC" = 1. >>>>> Now let's also suppose MCC3 has "max capture encodings" = 2. Then >>>>> the consumer can ask for, say, MCC3 at 720p and SIF, for the two >>>>> encodings. Then the provider decides when to switch among VC0, >>>>> VC1, and VC2, and whichever one the provider is sending for MCC3 >>>>> it sends it at both SIF and 720p, so MCC3 is simulcast at those >>>>> two resolutions. >>>>> >>>>>> What I am trying to say is that using implied simulcast require >>>>>> text explaining when a consumer can understand that the >>>>>> advertisement is simulcast and not something else. >>>>> >>>>>> The other approach may be to have an attribute for an MC and MCC >>>>>> that >>>>> will >>>>>> explicitly say that this is a simulcast offer. >>>>> >>>>> [Duckworth, Mark] I think the advertisement is clear to the >>>>> consumer without any additional text or attributes added to the >>>>> framework. It is already explicit, with the attribute "max >>>>> capture encodings". If it is >1, then the advertisement is offering >> simulcast. >>>>> >>>>>> BTW: I think that the implied solution works when the individual >>>>>> encodings are the same (spatial or different codces) what if we >>>>>> the provider can send >>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four >>>>>> different encodings but not all combinations allowed. How to >>>>>> represent it in an advertisement? Is it : >>>>> >>>>> [Duckworth, Mark] I can consider this case after we get the first >>>>> case above cleared up. >>>>> >>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, >>>>>> MaxCaptures=2 >>>>>> >>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>> view=table, >>>>>> MaxCaptures=2 >>>>>> >>>>>> VC2- (the right camera stream), encoding group=EG0, view=table. >>>>>> MaxCaptures=2 >>>>>> >>>>>> VC3- (the left camera stream), encoding group=EG1, view=table, >>>>>> MaxCaptures=2 >>>>>> >>>>>> VC4- (the center camera stream), encoding group=EG1, >>>>>> view=table, >>>>>> MaxCaptures=2 >>>>>> >>>>>> VC5- (the right camera stream), encoding group=EG1, view=table. >>>>>> MaxCaptures=2 >>>>>> >>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two >>>>>> scene views >>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? >>>>>> >>>>> ... snip ... >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Nov 12 22:17: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 DA6661A1BBC for ; Wed, 12 Nov 2014 22:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 eNnUdvmufufn for ; Wed, 12 Nov 2014 22:16:53 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.111]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3081A1BB0 for ; Wed, 12 Nov 2014 22:16:52 -0800 (PST) Received: from [216.82.254.20] by server-15.bemta-7.messagelabs.com id C8/72-02693-4DC44645; Thu, 13 Nov 2014 06:16:52 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-10.tower-47.messagelabs.com!1415859411!12844273!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9648 invoked from network); 13 Nov 2014 06:16:51 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-10.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 13 Nov 2014 06:16:51 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Wed, 12 Nov 2014 22:16:51 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Wed, 12 Nov 2014 22:16:50 -0800 Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: Ac/+8dBgO1K05kZoStW0ekTuJDNojQAF5ja0 Message-ID: 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_g0l93qwcb32hfek74v4abr871415859414876emailandroidcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/elWHkUGjZR3RXyawQrinjMNH-Qc Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 06:16:58 -0000 --_000_g0l93qwcb32hfek74v4abr871415859414876emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Paul. Mark -------- Original message -------- From: Paul Kyzivat Date:11/12/2014 5:27 PM (GMT-10:00) To: clue@ietf.org Subject: Re: [clue] CLUE and Simulcast - ticket #47 If an sdp-based mechanism is published that allows simulcast in a single m-line, then clue gets to take advantage of that *for free*. I don't know that we need to say anything about that. The question we have to ask is: do we want to remove the clue-specific mechanism that is already present in our data model? To that I will add the corollary question: is there any cost to having that option in there? I can't see any cost. - Advertisers don't have to use it in their advertisements. - Consumers can't use it in Configure if it wasn't in the advertisement - Consumers don't have to use it if it is in the advertisement. So I see no harm in leaving it in. And some potential benefit to having it there. Thanks, Paul On 11/12/14 1:29 PM, Roni Even wrote: > Hi, > This is what started the discussion. If we do not have SDP based simulcas= t > based on unified plan, the only semantics is an encoding per m-line. We > started the discussion based on this assumption that we can do simulcast = in > CLUE using an encoding per m-line and can bundle them > Roni > >> -----Original Message----- >> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] >> Sent: 12 November, 2014 11:03 PM >> To: Duckworth, Mark; Roni Even >> Cc: clue@ietf.org >> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >> >> Yes, I'd have thought ideally multiple simulcast qualities, repair strea= ms > etc >> would be defined under a single m-line and hence be a single encoding fr= om >> CLUE's perspective. That matches the unified plan and the proposal in > draft- >> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it would mea= n >> that negotiating simulcast qualities, repair flows etc would be purely a= n > SDP >> issue and wouldn't impact CLUE. >> >> Rob >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark >> Sent: 12 November 2014 10:54 >> To: Roni Even >> Cc: clue@ietf.org >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >> >> Hi, >> >> I don't understand why simulcast would need separate encoding groups. >> >> Whether an MC maps to two m-lines or one m-line with a=3Dsimulcast is up= to >> the consumer, and specified in the configure message sent from consumer = to >> provider. The mapping is done via the encoding ID labels which link med= ia >> captures to m-lines. At least that is how I see it. >> >> Would you say retransmission streams are a separate issue from simulcast= ? > Or >> are they similar enough that it is really the same issue? Do SVC layere= d > codec >> streams also fall into this category? >> >> Sounds like we do need some more discussion about this. My first though= t > is >> we should cover this in the signaling document. >> >> Mark >> >>> -----Original Message----- >>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>> Sent: Wednesday, November 12, 2014 10:36 AM >>> To: Duckworth, Mark >>> Cc: clue@ietf.org >>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>> >>> Hi, >>> This will work when we have a single encoding per m-line in the SDP >>> and I think it requires that each simulcast set will be in separate >>> encoding group . Still it will provide less functionality than the one >>> proposed in the simulcast proposal that will be discussed in MMUSIC If >>> simulcast in SDP will progress using the unified plan where we have >>> all encodings in one m-line we will need to specify that if an MC have >>> max capture encoding >1 will it mean that it will map to two m-lines >>> or will it use a configuration from an SDP description a=3Dsimulcast. >>> >>> We will need to see how it works with retransmission if we specify a >>> retransmission RTP stream as an individual encoding. >>> >>> Roni >>> >>>> -----Original Message----- >>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] >>>> Sent: 06 November, 2014 9:45 PM >>>> To: Roni Even >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> Hi Roni, >>>> Do you still have questions about the way simulcast is handled in >>>> the framework, regarding the attribute "Max capture encodings" and >>> configuring >>>> multiple encodings per capture? I was hoping we could resolve it on >>>> the >>> list, or >>>> do you think we need to talk about it in Honolulu? >>>> Regards, >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, >>> Mark >>>>> Sent: Monday, November 03, 2014 10:52 PM >>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org >>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >>>>>> Sent: Monday, November 03, 2014 5:52 PM >>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>> Christian Groves >>>>>>> Sent: 28 October, 2014 2:56 AM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>> >>>>>>> Hello Roni, >>>>>>> >>>>>>> As I mentioned in my original reply I think the RTP based >>>>>>> simulcast >>>>> method >>>>>> is >>>>>>> probably the cleanest approach. There would be nothing >>>>>>> stopping a CLUE endpoint implementing it when it becomes >>>>>>> available (like many other RTP features). Using CLUE for >>>>>>> simulcast I think is possible for most >>>>>> scenarios. The >>>>>>> more complicated the scenarios the more MCs/encodings an >>> endpoint >>>>> will >>>>>>> need to describe the situation. >>>>>>> >>>>>>> Please see my response below. >>>>>>> >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: >>>>>>>> Hi Paul, >>>>>>>> >>>>>>>> If we want to be able to differentiate between simulcast and >>>>>>>> switched capture, for example if we have a three camera >>>>>>>> system that can send three MCs each with two encodings >>>>>>>> (simulcast) and a switched capture (loudest speaker or two >>>>>>>> loudest speakers out of three) using the same simulcast >>>>>>>> option for the each MC currently sent. In this case we can >>>>>>>> have an MC with two encodings and an MCC with the three MCs. >>>>>>>> This >>>>> will >>>>>>>> require us to clarify that having multiple individual >>>>>>>> encodings in MC is simulcast and not switched and in MCC it >>>>>>>> is switched and not >>>>> simulcast. >>>>>>> [CNG] I don't understand exactly what the issue is here? Could >>>>>>> you use >>>>> some >>>>>>> pseudo syntax to explain what you're wanting to advertise? You >>>>>>> say in >>>>> the first >>>>>>> sentence the switched capture uses simulcast but then in the >>>>>>> last >>>>> sentence you >>>>>>> say the MCC is switched and not simulcast. I would think that >>>>>>> an MCC can >>>>> still >>>>>>> be switched and simulcast, i.e. the endpoint simulcasts >>>>>>> whatever source >>>>> is >>>>>>> switched into the media stream. >>>>>>> If you want a pure switched MCC just set maxCaptureEncodings >>>>>>> to 1 >>>>> against the >>>>>>> MCC. >>>>>>> If you want a simultcast MCC just set maxCaptureEncodings to >>>>>>>> =3D2 >>>>> against the >>>>>>> MCC. >>>>>> >>>>>> [Roni Even] The thing is that I am not sure how to advertise >>>>>> this >>> example. >>>>>> >>>>>> The advertisement has two scene views: >>>>>> 1. Scene view with VC0, VC1, VC2 each with two simulcast streams > 2. >>>>>> Scene view MCC3 as represented bellow >>>>>> >>>>>> The different MCs will be: >>>>>> >>>>>> VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, >>>>>> MaxCaptures=3D2 >>>>> >>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture >>>>> Encodings"? >>>>> Don't confuse this with the MCC attribute MaxCaptures which means >>> "Max >>>>> number of Captures within a MCC". >>>>> >>>>>> VC1- (the center camera stream), encoding group=3DEG0, >>>>>> view=3Dtable, >>>>>> MaxCaptures=3D2 >>>>>> >>>>>> VC2- (the right camera stream), encoding group=3DEG0, view=3Dtable= . >>>>>> MaxCaptures=3D2 >>>>>> >>>>>> MCC3 (VC0, VC1, VC2) - encoding group=3DEG0, view=3Droom, >>>>> MaxCaptures=3D2 >>>>> >>>>> [Duckworth, Mark] It isn't clear if you really mean "max capture >>> encodings" >>>>> or >>>>> "max number of captures within a MCC". Those are two different > things. >>>>> >>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. >>>>> >>>>> [Duckworth, Mark] It depends how the consumer configures it. The >>>>> provider advertisement says it supports simulcast, so the consumer >>>>> can decide to use it or not. >>>>> >>>>>> What about MCC3? >>>>>> Is it multicast from one of the cameras or is it 2 MCs out of >>>>>> the three? (I assume it is the first since the view is room) >>>>> >>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three >>>>> simultaneously only if it is composed, not if it is switched. The >>>>> provider can give more information, if it wants to, with the MCC >>>>> attribute "max number of captures within a MCC". >>>>> >>>>>> What if in the above example MaxCaptures=3D4 can it be for >>>>>> example VC0, >>>>> VC1 >>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and one >>>>>> of them is >>>>> simulcast? >>>>> >>>>> [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" >>>>> capture. >>>>> It sounds like you are talking about a switched case, not a >>>>> composed case, so let's say MCC3 has the attribute "max number of >>>>> captures within >>> a >>>> MCC" =3D 1. >>>>> Now let's also suppose MCC3 has "max capture encodings" =3D 2. Then >>>>> the consumer can ask for, say, MCC3 at 720p and SIF, for the two >>>>> encodings. Then the provider decides when to switch among VC0, >>>>> VC1, and VC2, and whichever one the provider is sending for MCC3 >>>>> it sends it at both SIF and 720p, so MCC3 is simulcast at those >>>>> two resolutions. >>>>> >>>>>> What I am trying to say is that using implied simulcast require >>>>>> text explaining when a consumer can understand that the >>>>>> advertisement is simulcast and not something else. >>>>> >>>>>> The other approach may be to have an attribute for an MC and MCC >>>>>> that >>>>> will >>>>>> explicitly say that this is a simulcast offer. >>>>> >>>>> [Duckworth, Mark] I think the advertisement is clear to the >>>>> consumer without any additional text or attributes added to the >>>>> framework. It is already explicit, with the attribute "max >>>>> capture encodings". If it is >1, then the advertisement is offering >> simulcast. >>>>> >>>>>> BTW: I think that the implied solution works when the individual >>>>>> encodings are the same (spatial or different codces) what if we >>>>>> the provider can send >>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four >>>>>> different encodings but not all combinations allowed. How to >>>>>> represent it in an advertisement? Is it : >>>>> >>>>> [Duckworth, Mark] I can consider this case after we get the first >>>>> case above cleared up. >>>>> >>>>>> VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, >>>>>> MaxCaptures=3D2 >>>>>> >>>>>> VC1- (the center camera stream), encoding group=3DEG0, >>>>>> view=3Dtable, >>>>>> MaxCaptures=3D2 >>>>>> >>>>>> VC2- (the right camera stream), encoding group=3DEG0, view=3Dtable= . >>>>>> MaxCaptures=3D2 >>>>>> >>>>>> VC3- (the left camera stream), encoding group=3DEG1, view=3Dtable, >>>>>> MaxCaptures=3D2 >>>>>> >>>>>> VC4- (the center camera stream), encoding group=3DEG1, >>>>>> view=3Dtable, >>>>>> MaxCaptures=3D2 >>>>>> >>>>>> VC5- (the right camera stream), encoding group=3DEG1, view=3Dtable= . >>>>>> MaxCaptures=3D2 >>>>>> >>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two >>>>>> scene views >>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? >>>>>> >>>>> ... snip ... >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing 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_g0l93qwcb32hfek74v4abr871415859414876emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Paul.
Mark


-------- Original message --= ------
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Date:11/12/2= 014 5:27 PM (GMT-10:00)
To: clue@ietf.org
Subject: Re: [clue] CLUE = and Simulcast - ticket #47

If an sdp-based mechanism is publ= ished that allows simulcast in a single
m-line, then clue gets to take advantage of that *for free*. I don't
know that we need to say anything about that.

The question we have to ask is: do we want to remove the clue-specific
mechanism that is already present in our data model?

To that I will add the corollary question: is there any cost to having
that option in there?

I can't see any cost.
- Advertisers don't have to use it in their advertisements.
- Consumers can't use it in Configure if it wasn't in the advertisement
- Consumers don't have to use it if it is in the advertisement.

So I see no harm in leaving it in. And some potential benefit to having it there.

        Thanks,
        Paul

On 11/12/14 1:29 PM, Roni Even wrote:
> Hi,
> This is what started the discussion. If we do not have SDP based simul= cast
> based on unified plan, the only semantics is an encoding per m-line. W= e
> started the discussion based on this assumption that we can do simulca= st in
> CLUE using an encoding per m-line and can bundle them
> Roni
>
>> -----Original Message-----
>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com]
>> Sent: 12 November, 2014 11:03 PM
>> To: Duckworth, Mark; Roni Even
>> Cc: clue@ietf.org
>> Subject: RE: [clue] CLUE and Simulcast - ticket #47
>>
>> Yes, I'd have thought ideally multiple simulcast qualities, repair= streams
> etc
>> would be defined under a single m-line and hence be a single encod= ing from
>> CLUE's perspective. That matches the unified plan and the proposal= in
> draft-
>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it wou= ld mean
>> that negotiating simulcast qualities, repair flows etc would be pu= rely an
> SDP
>> issue and wouldn't impact CLUE.
>>
>> Rob
>>
>> -----Original Message-----
>> From: clue [mailto:clue-b= ounces@ietf.org] On Behalf Of Duckworth, Mark
>> Sent: 12 November 2014 10:54
>> To: Roni Even
>> Cc: clue@ietf.org
>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
>>
>> Hi,
>>
>> I don't understand why simulcast would need separate encoding grou= ps.
>>
>> Whether an MC maps to two m-lines or one m-line with a=3Dsimulcast= is up to
>> the consumer, and specified in the configure message sent from con= sumer to
>> provider.  The mapping is done via the encoding ID labels whi= ch link media
>> captures to m-lines.  At least that is how I see it.
>>
>> Would you say retransmission streams are a separate issue from sim= ulcast?
> Or
>> are they similar enough that it is really the same issue?  Do= SVC layered
> codec
>> streams also fall into this category?
>>
>> Sounds like we do need some more discussion about this.  My f= irst thought
> is
>> we should cover this in the signaling document.
>>
>> Mark
>>
>>> -----Original Message-----
>>> From: Roni Even [mai= lto:ron.even.tlv@gmail.com]
>>> Sent: Wednesday, November 12, 2014 10:36 AM
>>> To: Duckworth, Mark
>>> Cc: clue@ietf.org
>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47
>>>
>>> Hi,
>>> This will work when we have a single encoding per m-line in th= e SDP
>>> and I think it requires that each simulcast set will be in sep= arate
>>> encoding group . Still it will provide less functionality than= the one
>>> proposed in the simulcast proposal that will be discussed in M= MUSIC If
>>> simulcast in SDP will progress using the unified plan where we= have
>>> all encodings in one m-line we will need to specify that if an= MC have
>>> max capture encoding >1 will it mean that it will map to tw= o m-lines
>>> or will it use a configuration from an SDP description a=3Dsim= ulcast.
>>>
>>> We will need to see how it works with retransmission if we spe= cify a
>>> retransmission RTP stream as an individual encoding.
>>>
>>> Roni
>>>
>>>> -----Original Message-----
>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com]
>>>> Sent: 06 November, 2014 9:45 PM
>>>> To: Roni Even
>>>> Cc: clue@ietf.org
>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47
>>>>
>>>> Hi Roni,
>>>> Do you still have questions about the way simulcast is han= dled in
>>>> the framework, regarding the attribute "Max capture e= ncodings" and
>>> configuring
>>>> multiple encodings per capture?  I was hoping we coul= d resolve it on
>>>> the
>>> list, or
>>>> do you think we need to talk about it in Honolulu?
>>>> Regards,
>>>> Mark
>>>>
>>>>> -----Original Message-----
>>>>> From: clue [m= ailto:clue-bounces@ietf.org] On Behalf Of Duckworth,
>>> Mark
>>>>> Sent: Monday, November 03, 2014 10:52 PM
>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org
>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>
>>>>>> -----Original Message-----
>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
>>>>>> Sent: Monday, November 03, 2014 5:52 PM
>>>>>> To: 'Christian Groves'; clue@ietf.org
>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #4= 7
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of
>>>>>>> Christian Groves
>>>>>>> Sent: 28 October, 2014 2:56 AM
>>>>>>> To: clue@ietf.org
>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticke= t #47
>>>>>>>
>>>>>>> Hello Roni,
>>>>>>>
>>>>>>> As I mentioned in my original reply I think th= e RTP based
>>>>>>> simulcast
>>>>> method
>>>>>> is
>>>>>>> probably the cleanest approach. There would be= nothing
>>>>>>> stopping a CLUE endpoint implementing it when = it becomes
>>>>>>> available (like many other RTP features). Usin= g CLUE for
>>>>>>> simulcast I think is possible for most
>>>>>> scenarios. The
>>>>>>> more complicated the scenarios the more MCs/en= codings an
>>> endpoint
>>>>> will
>>>>>>> need to describe the situation.
>>>>>>>
>>>>>>> Please see my response below.
>>>>>>>
>>>>>>> Regards, Christian
>>>>>>>
>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote:
>>>>>>>> Hi Paul,
>>>>>>>>
>>>>>>>> If we want to be able to differentiate bet= ween simulcast and
>>>>>>>> switched capture, for example if we have a= three camera
>>>>>>>> system that can send three MCs each with t= wo encodings
>>>>>>>> (simulcast) and a switched capture (loudes= t speaker or two
>>>>>>>> loudest speakers out of three) using the s= ame simulcast
>>>>>>>> option for the each MC currently sent. In = this case we can
>>>>>>>> have an MC with two encodings and an MCC w= ith the three MCs.
>>>>>>>> This
>>>>> will
>>>>>>>> require us to clarify that having multiple= individual
>>>>>>>> encodings in MC is simulcast and not switc= hed and in MCC it
>>>>>>>> is switched and not
>>>>> simulcast.
>>>>>>> [CNG] I don't understand exactly what the issu= e is here? Could
>>>>>>> you use
>>>>> some
>>>>>>> pseudo syntax to explain what you're wanting t= o advertise? You
>>>>>>> say in
>>>>> the first
>>>>>>> sentence the switched capture uses simulcast b= ut then in the
>>>>>>> last
>>>>> sentence you
>>>>>>> say the MCC is switched and not simulcast. I w= ould think that
>>>>>>> an MCC can
>>>>> still
>>>>>>> be switched and simulcast, i.e. the endpoint s= imulcasts
>>>>>>> whatever source
>>>>> is
>>>>>>> switched into the media stream.
>>>>>>> If you want a pure switched MCC just set maxCa= ptureEncodings
>>>>>>> to 1
>>>>> against the
>>>>>>> MCC.
>>>>>>> If you want a simultcast MCC just set maxCaptu= reEncodings to
>>>>>>>> =3D2
>>>>> against the
>>>>>>> MCC.
>>>>>>
>>>>>> [Roni Even] The thing is that I am not sure how to= advertise
>>>>>> this
>>> example.
>>>>>>
>>>>>> The advertisement has two scene views:
>>>>>>   1. Scene view with VC0, VC1, VC2 each = with two simulcast streams
> 2.
>>>>>> Scene view MCC3 as represented bellow
>>>>>>
>>>>>> The different MCs will be:
>>>>>>
>>>>>> VC0- (the left camera stream), encoding group=3DEG= 0, view=3Dtable,
>>>>>> MaxCaptures=3D2
>>>>>
>>>>> [Duckworth, Mark] I assume "MaxCaptures" her= e means "Max Capture
>>>>> Encodings"?
>>>>> Don't confuse this with the MCC attribute MaxCaptures = which means
>>> "Max
>>>>> number of Captures within a MCC".
>>>>>
>>>>>>   VC1- (the center camera stream), encod= ing group=3DEG0,
>>>>>> view=3Dtable,
>>>>>> MaxCaptures=3D2
>>>>>>
>>>>>>   VC2- (the right camera stream), encodi= ng group=3DEG0, view=3Dtable.
>>>>>> MaxCaptures=3D2
>>>>>>
>>>>>>    MCC3 (VC0, VC1, VC2) - encoding = group=3DEG0,    view=3Droom,
>>>>> MaxCaptures=3D2
>>>>>
>>>>> [Duckworth, Mark] It isn't clear if you really mean &q= uot;max capture
>>> encodings"
>>>>> or
>>>>> "max number of captures within a MCC". = Those are two different
> things.
>>>>>
>>>>>> Now it may be implied here that VC0, VC1, VC2 are = simulcast.
>>>>>
>>>>> [Duckworth, Mark] It depends how the consumer configur= es it.  The
>>>>> provider advertisement says it supports simulcast, so = the consumer
>>>>> can decide to use it or not.
>>>>>
>>>>>> What  about MCC3?
>>>>>> Is it multicast from one of the cameras or is it 2= MCs out of
>>>>>> the three? (I assume it is the first since the vie= w is room)
>>>>>
>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the th= ree
>>>>> simultaneously only if it is composed, not if it is sw= itched.  The
>>>>> provider can give more information, if it wants to, wi= th the MCC
>>>>> attribute "max number of captures within a MCC&qu= ot;.
>>>>>
>>>>>> What if in the above example  MaxCaptures=3D4= can it be for
>>>>>> example VC0,
>>>>> VC1
>>>>>> each with two simulcast streams or is it VC0, VC1,= VC2 and one
>>>>>> of them is
>>>>> simulcast?
>>>>>
>>>>> [Duckworth, Mark] Neither.  The MCC3 provides a s= ingle "conceptual"
>>>>> capture.
>>>>> It sounds like you are talking about a switched case, = not a
>>>>> composed case, so let's say MCC3 has the attribute &qu= ot;max number of
>>>>> captures within
>>> a
>>>> MCC" =3D 1.
>>>>> Now let's also suppose MCC3 has "max capture enco= dings" =3D 2.  Then
>>>>> the consumer can ask for, say, MCC3 at 720p and SIF, f= or the two
>>>>> encodings.  Then the provider decides when to swi= tch among VC0,
>>>>> VC1, and VC2, and whichever one the provider is sendin= g for MCC3
>>>>> it sends it at both SIF and 720p, so MCC3 is simulcast= at those
>>>>> two resolutions.
>>>>>
>>>>>> What I am trying to say is that using implied simu= lcast require
>>>>>> text explaining when a consumer can understand tha= t the
>>>>>> advertisement is simulcast and not something else.=
>>>>>
>>>>>> The other approach may be to have an attribute for= an MC and MCC
>>>>>> that
>>>>> will
>>>>>> explicitly say that this is a simulcast offer.
>>>>>
>>>>> [Duckworth, Mark] I think the advertisement is clear t= o the
>>>>> consumer without any additional text or attributes add= ed to the
>>>>> framework.  It is already explicit, with the attr= ibute "max
>>>>> capture encodings".  If it is >1, then th= e advertisement is offering
>> simulcast.
>>>>>
>>>>>> BTW: I think that the implied solution works when = the individual
>>>>>> encodings are the same (spatial or different codce= s) what if we
>>>>>> the provider can send
>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP thi= s will be four
>>>>>> different encodings but not all combinations allow= ed. How to
>>>>>> represent it in an advertisement? Is it :
>>>>>
>>>>> [Duckworth, Mark] I can consider this case after we ge= t the first
>>>>> case above cleared up.
>>>>>
>>>>>> VC0- (the left camera stream), encoding group=3DEG= 0, view=3Dtable,
>>>>>> MaxCaptures=3D2
>>>>>>
>>>>>>   VC1- (the center camera stream), encod= ing group=3DEG0,
>>>>>> view=3Dtable,
>>>>>> MaxCaptures=3D2
>>>>>>
>>>>>>   VC2- (the right camera stream), encodi= ng group=3DEG0, view=3Dtable.
>>>>>> MaxCaptures=3D2
>>>>>>
>>>>>> VC3- (the left camera stream), encoding group=3DEG= 1, view=3Dtable,
>>>>>> MaxCaptures=3D2
>>>>>>
>>>>>>   VC4- (the center camera stream), encod= ing group=3DEG1,
>>>>>> view=3Dtable,
>>>>>> MaxCaptures=3D2
>>>>>>
>>>>>>   VC5- (the right camera stream), encodi= ng group=3DEG1, view=3Dtable.
>>>>>> MaxCaptures=3D2
>>>>>>
>>>>>> Where EG0 will be for H.264 and EG1 will be for VP= 8 and two
>>>>>> scene views
>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)?
>>>>>>
>>>>>   ... snip ...
>>>>>
>>>>> _______________________________________________
>>>>> clue mailing list
>>>>> clue@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www= .ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.iet= f.org/mailman/listinfo/clue
>

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org= /mailman/listinfo/clue
 --_000_g0l93qwcb32hfek74v4abr871415859414876emailandroidcom_-- From nobody Thu Nov 13 13:55: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 C9F441ADE87 for ; Thu, 13 Nov 2014 13:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na1XRIn8PoXI for ; Thu, 13 Nov 2014 13:55:35 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CBAC1ADEA7 for ; Thu, 13 Nov 2014 13:55:25 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-02v.sys.comcast.net with comcast id F9v51p00358ss0Y019vRCe; Thu, 13 Nov 2014 21:55:25 +0000 Received: from dhcp-a55a.meeting.ietf.org ([31.133.165.90]) by resomta-po-14v.sys.comcast.net with comcast id F9tG1p00N1xLjbz019tKhH; Thu, 13 Nov 2014 21:53:23 +0000 Message-ID: <5465284B.6070600@alum.mit.edu> Date: Thu, 13 Nov 2014 11:53:15 -1000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------040200030501020301010005" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415915725; bh=SZj1A3TtYeLj1av61qBlXvRd0cdgVwhkGX8ZNQd4ED0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oKQmiEBv7XfQBqRYwqvcjZygxNk7WCJGHmW4tNP1vLwWK0Sc0/+ztz6MBMqbuDQNl XIu1xCoFy2J7mBkZT6U1U/OYSC6hMaeyUIQ1He7keXVPbqgYcPQC7w+A6MCuCoFlya xtHK14JdOroMJp9nt3D9MuD187HSWSxHNu06Ah3Jh47SvCJe+CXKfFzc/hsO7SAPww F0HjEik+MyTW0VvaivPVBkawu9HF4nRltCCzaCvGCVDec49fqOy7/iXf0Tdr0GL1b/ UPP9kNlMGPXNHvYmROViELILP8324AVZdSV3lIJmuyHpjPZmCa237CpASdCBP9K8wk IuN6fOvf8SWIw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/oOqy0pFMCYEdJkJGH3CIgbBT9FE Subject: [clue] FYI: Simulcast IRP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 21:55:37 -0000 This is a multi-part message in MIME format. --------------040200030501020301010005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit -------- Original Message -------- Subject: [MMUSIC] IPR declaration relating to draft-burman-mmusic-sdp-simulcast Date: Thu, 13 Nov 2014 11:14:00 -1000 From: Bernard Aboba To: Microsoft previously filed an IPR declaration relating to draft-westerlund-avtcore-rtp-simulcast: https://datatracker.ietf.org/ipr/2157/ Given the contents of Section V of that declaration (“Disclosure of Patent Information”), the WG should be aware that this declaration may also relate to draft-burman-mmusic-sdp-simulcast --------------040200030501020301010005 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------040200030501020301010005-- From nobody Fri Nov 14 09:36: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 ED7C51A1B22; Fri, 14 Nov 2014 09:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] 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 bjWwrsA2d4Ov; Fri, 14 Nov 2014 09:36:10 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B6A1A1B14; Fri, 14 Nov 2014 09:36:10 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 9F109F68A2C77; Fri, 14 Nov 2014 17:36:05 +0000 (GMT) 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 sAEHa86J013836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Nov 2014 18:36:08 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 18:36:08 +0100 From: "DRAGE, Keith (Keith)" To: "rtcweb@ietf.org" , "mmusic@ietf.org" , CLUE , "avt@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt Thread-Index: AQHQAAM2TU9IvAskwUumiAHVoVNISJxgYKPwgAABkqA= Date: Fri, 14 Nov 2014 17:36:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B27B43B@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.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/cp25zDrenosp1mzXCqhCIqDSmTc Subject: [clue] FW: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:36:12 -0000 This is to bring your attention to the following WGLC, in which your workin= g group may have some interest. Please send your comments to avtext@ietf.org If you are not a member of that list, then please still use that address, a= nd we will release it from the moderator queue when we receive notification= . Regards Keith=20 -----Original Message----- From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of DRAGE, Keith (Ke= ith) Sent: 14 November 2014 17:32 To: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.tx= t (As WG cochair)=20 This is to start a working group last call on draft-ietf-avtext-rtp-groupin= g-taxonomy-03. To cater for the end of the IETF meeting, and for various national holidays= , this working group last call will last three weeks. Therefore please comment on this document by Friday 5th December 2014. Please send comments to the working group list. It is helpful to give some assessment of the nature of your comment, as to = whether you regard it as editorial, minor technical, or a rather more major= flaw. Regards Keith -----Original Message----- From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: 14 November 2014 12:05 To: i-d-announce@ietf.org Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Working = Group of the IETF. Title : A Taxonomy of Grouping Semantics and Mechanisms f= or Real-Time Transport Protocol (RTP) Sources Authors : Jonathan Lennox Kevin Gross Suhas Nandakumar Gonzalo Salgueiro Bo Burman Filename : draft-ietf-avtext-rtp-grouping-taxonomy-03.txt Pages : 42 Date : 2014-11-14 Abstract: The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed relationships among RTP sources, and attempts to define common terminology for discussing protocol entities and their relationships. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-grouping-taxonomy-= 03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From nobody Sat Nov 15 17:57: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 9901F1A00B7 for ; Sat, 15 Nov 2014 17:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=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 GJZ9gOxrVxOE for ; Sat, 15 Nov 2014 17:57:40 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0441A001D for ; Sat, 15 Nov 2014 17:57:39 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-e2-5468049154d3 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D3.5E.04231.19408645; Sun, 16 Nov 2014 02:57:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Sun, 16 Nov 2014 02:57:36 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] I-D Action: draft-ietf-clue-datachannel-02.txt Thread-Index: AQHP/jpTWC8b2rHiUku/dvk5FB4LNJxigvGQ Date: Sun, 16 Nov 2014 01:57:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D511407@ESESSMB209.ericsson.se> References: <20141027130315.6434.28356.idtracker@ietfa.amsl.com> <5462F159.7040504@nteczone.com> In-Reply-To: <5462F159.7040504@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje5ElowQg0M9chZf3jeyWOw/dZnZ gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mp48egYc8F3+YplF0MbGKdIdjGyc0gImEh8 1+ti5ASyxCQu3FvP1sXIxSEkcIRRYt2nC1DOEkaJtc0HmboYOTjYBCwkuv9pgzSICIRLdGy7 wghiCws4Sdxb8p4JIu4sMWfLHDYI20hi/49JYDaLgKrEts8fWEFsXgFfiU3vp4PZQgJJEu3t u8BqOAV0JKa9Ow82kxHooO+n1oDNZBYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwphK0ms2H6J EaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhFi1OLi3PT jYz1Uosyk4uL8/P08lJLNjECI+Tglt+6OxhXv3Y8xCjAwajEw7vhYFqIEGtiWXFl7iFGaQ4W JXHeRefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgzPbTWiryVaM/clObw6rQv9PcP3oX 7N4dI8qT7Xta4chF5e+TrJ9zF5nsLJu/4tOpQptfyYZr65Ye38z/cG3q6UJG9jurbzRdvbz4 zfK93XacFxXmb9rJmpvncOHu5JKe6F9sqTW2tQusVLcaRcWzzLTi23n+5F3Wt4b2W/ff2K0Q 7Fg2ZRnTDyWW4oxEQy3mouJEADYSWPxxAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/MzpTqXnjgevdxJqNmMKVO8Z8b9s Subject: Re: [clue] I-D Action: draft-ietf-clue-datachannel-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: Sun, 16 Nov 2014 01:57:42 -0000 Hi Christian, >Some comments on the latest draft: > >The "updated" example needs to be updated further, as the SDP for datachan= nel has been >updated and the "DTLS over SCTP" error wasn't fixed : > >i.e. from a=3Dgroup:CLUE 3 > m=3Dapplication 54111 SCTP/DTLS 54111 > a=3Dsctpmap:54111 webrtc-datachannel > a=3Dmid:3 >to: >a=3Dgroup:CLUE 3 >m=3Dapplication 54111 DTLS/SCTP webrtc-datachannel a=3Dsctp-port 5000 >a=3Dmid:3 > >Clause 5.3 needs to be updated because there's no longer a SDP sctpmap att= ribute. Correct. However, in Honolulu we agreed to adopt the ejzak draft, and therefor the D= TLS/SCTP m- line is not required to be associated with the CLUE group. In addition we also agree to not include the sctp-port attribute in the exa= mples, as there can only be one SCTP association per DTLS/SCTP m- line (per= agreement in MMUSIC). >With regards to OPEN ISSUE 2, cl.5.4 and 5.5 are fairly generic but they i= gnore the aspect that >for CLUE the SDP O/A procedures must associate the C= LUE group to the "m=3D" line, i.e. as per >the example. I think if these ar= e added then you can remove open issue 2. > >I also think the draft needs to update the text around "/If an offerer, in= a subsequent offer, >wants to disable the CLUE Data Channel, it assigns a = zero port value to the "m=3D" line >describing the SCTPoDTLS association us= ed to realize the CLUE Data Channel./" I think the >draft needs to be updat= ed to reflect that this will have the effect of closing the DTLS and >SCTP = association (which may not be desirable as other applications may share the= >association). As discussed previously to close just the CLUE data channel= the m=3Dline would >be removed from the CLUE group. My understanding is that some/all of this will go away, as it belongs to th= e signalling draft. And, again, it was agreed that whether the m- line is associated with the C= LUE group or not has no semantical meaning. Regards, Christer On 28/10/2014 12:03 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the ControLling mUltiple streams for tElep= resence Working Group of the IETF. > > Title : CLUE Protocol Data Channel > Author : Christer Holmberg > Filename : draft-ietf-clue-datachannel-02.txt > Pages : 13 > Date : 2014-10-27 > > Abstract: > This document defines how to use the WebRTC Data Channel mechanism, > together with the Data Channel Establishment Protocol (DCEP) in order > to establish a data channel, referred to as CLUE Data Channel, for > transporting CLUE protocol messages between two CLUE entities. > > The document defines the SCTP considerations specific to a CLUE Data > Channel, the SDP offer/answer procedures for negotiating the > establishment of, and the DCEP procedures for opening, a CLUE Data > Channel. > > Details and procedures associated with the CLUE protocol are outside > the scope of this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-datachannel-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-datachannel-02 > > > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Wed Nov 19 17:24: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 2E9261A1B88 for ; Wed, 19 Nov 2014 17:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 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, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=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 d15rzwNjPHGN for ; Wed, 19 Nov 2014 17:24:43 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DE91A03A6 for ; Wed, 19 Nov 2014 17:24:43 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hi2so3735122wib.11 for ; Wed, 19 Nov 2014 17:24:42 -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=tw71s4Pp0atTHWCxSFMeO7qu8LZwXD95eJTBDDLIXYk=; b=kZRj+kDvoA8Y45D4jm/Lmyeq6HK9MmZaMDreNakf1j2+o8T9sB7fg8QyshDCm/9mHU RtRtPWHQlE8TTwWD2xic9sMtZP0PSlvu+PwZTLMFiVy0lPNJ9yWQB+FwXUbi1QHCFpFO avMQJ0YyKn6+bY5v4ebv4h/UQGsDeNs9mA1wxRz7v068oBNJLSBsUk2UqoGrwMBhciSj uPvZjs24sCLiHRCK2rGNHXHf5GT1M/Y/uO2otqsXFG/4YEZnv1cmeN8qn7TH15bjzG1V e2ZyP///UeFV5dkkSJpCm1SNHNaIyyY5airxKQFTG0DCsGMGrfwChW84EAO5OD35Jd4r uNMg== MIME-Version: 1.0 X-Received: by 10.180.86.194 with SMTP id r2mr18202153wiz.43.1416446682072; Wed, 19 Nov 2014 17:24:42 -0800 (PST) Received: by 10.194.127.38 with HTTP; Wed, 19 Nov 2014 17:24:42 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D511407@ESESSMB209.ericsson.se> References: <20141027130315.6434.28356.idtracker@ietfa.amsl.com> <5462F159.7040504@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D511407@ESESSMB209.ericsson.se> Date: Wed, 19 Nov 2014 15:24:42 -1000 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d044286dc540a4d05084031d2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/RxE0ZhBMsQVq-TChKPZCKCEZVmM Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-datachannel-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: Thu, 20 Nov 2014 01:24:46 -0000 --f46d044286dc540a4d05084031d2 Content-Type: text/plain; charset=UTF-8 >>>And, again, it was agreed that whether the m- line is associated with the CLUE group or not has no semantical meaning. Well, this was agreed assuming the ezjak draft progresses to publication reasonably promptly. The current approach (where the m- line needed to be in the CLUE group does have meaning) is the fallback. On Sat, Nov 15, 2014 at 3:57 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Christian, > > >Some comments on the latest draft: > > > >The "updated" example needs to be updated further, as the SDP for > datachannel has been >updated and the "DTLS over SCTP" error wasn't fixed : > > > >i.e. from a=group:CLUE 3 > > m=application 54111 SCTP/DTLS 54111 > > a=sctpmap:54111 webrtc-datachannel > > a=mid:3 > >to: > >a=group:CLUE 3 > >m=application 54111 DTLS/SCTP webrtc-datachannel a=sctp-port 5000 > >a=mid:3 > > > >Clause 5.3 needs to be updated because there's no longer a SDP sctpmap > attribute. > > Correct. > > However, in Honolulu we agreed to adopt the ejzak draft, and therefor the > DTLS/SCTP m- line is not required to be associated with the CLUE group. > > In addition we also agree to not include the sctp-port attribute in the > examples, as there can only be one SCTP association per DTLS/SCTP m- line > (per agreement in MMUSIC). > > >With regards to OPEN ISSUE 2, cl.5.4 and 5.5 are fairly generic but they > ignore the aspect that >for CLUE the SDP O/A procedures must associate the > CLUE group to the "m=" line, i.e. as per >the example. I think if these are > added then you can remove open issue 2. > > > >I also think the draft needs to update the text around "/If an offerer, > in a subsequent offer, >wants to disable the CLUE Data Channel, it assigns > a zero port value to the "m=" line >describing the SCTPoDTLS association > used to realize the CLUE Data Channel./" I think the >draft needs to be > updated to reflect that this will have the effect of closing the DTLS and > >SCTP association (which may not be desirable as other applications may > share the >association). As discussed previously to close just the CLUE > data channel the m=line would >be removed from the CLUE group. > > My understanding is that some/all of this will go away, as it belongs to > the signalling draft. > > And, again, it was agreed that whether the m- line is associated with the > CLUE group or not has no semantical meaning. > > Regards, > > Christer > > > > On 28/10/2014 12:03 AM, 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 : CLUE Protocol Data Channel > > Author : Christer Holmberg > > Filename : draft-ietf-clue-datachannel-02.txt > > Pages : 13 > > Date : 2014-10-27 > > > > Abstract: > > This document defines how to use the WebRTC Data Channel mechanism, > > together with the Data Channel Establishment Protocol (DCEP) in order > > to establish a data channel, referred to as CLUE Data Channel, for > > transporting CLUE protocol messages between two CLUE entities. > > > > The document defines the SCTP considerations specific to a CLUE Data > > Channel, the SDP offer/answer procedures for negotiating the > > establishment of, and the DCEP procedures for opening, a CLUE Data > > Channel. > > > > Details and procedures associated with the CLUE protocol are outside > > the scope of this document. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-clue-datachannel-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-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 > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --f46d044286dc540a4d05084031d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>>>And, again, it was agreed that whether the m- l= ine is associated with the CLUE group or not has no semantical meaning.
Well, this was agreed assuming the ezjak draft progresses to publica= tion reasonably promptly.=C2=A0 The current approach (where the m- line nee= ded to be in the CLUE group does have meaning) is the fallback.

On Sat, No= v 15, 2014 at 3:57 PM, Christer Holmberg <christer.holmberg@e= ricsson.com> wrote:
Hi Chri= stian,

>Some comments on the latest draft:
>
>The "updated" example needs to be updated further, as the SDP= for datachannel has been >updated and the "DTLS over SCTP" er= ror wasn't fixed :
>
>i.e. from=C2=A0 a=3Dgroup:CLUE 3
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m=3Dapplication 54111 SCTP/DTL= S 54111
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a=3Dsctpmap:54111 webrtc-data= channel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a=3Dmid:3
>to:
>a=3Dgroup:CLUE 3
>m=3Dapplication 54111 DTLS/SCTP webrtc-datachannel a=3Dsctp-port 5000 >a=3Dmid:3
>
>Clause 5.3 needs to be updated because there's no longer a SDP sctp= map attribute.

Correct.

However, in Honolulu we agreed to adopt the ejzak draft, and therefor the D= TLS/SCTP m- line is not required to be associated with the CLUE group.

In addition we also agree to not include the sctp-port attribute in the exa= mples, as there can only be one SCTP association per DTLS/SCTP m- line (per= agreement in MMUSIC).

>With regards to OPEN ISSUE 2, cl.5.4 and 5.5 are fairly generic but the= y ignore the aspect that >for CLUE the SDP O/A procedures must associate= the CLUE group to the "m=3D" line, i.e. as per >the example. = I think if these are added then you can remove open issue 2.
>
>I also think the draft needs to update the text around "/If an off= erer, in a subsequent offer, >wants to disable the CLUE Data Channel, it= assigns a zero port value to the "m=3D" line >describing the = SCTPoDTLS association used to realize the CLUE Data Channel./" I think= the >draft needs to be updated to reflect that this will have the effec= t of closing the DTLS and >SCTP association (which may not be desirable = as other applications may share the >association). As discussed previous= ly to close just the CLUE data channel the m=3Dline would >be removed fr= om the CLUE group.

My understanding is that some/all of this will go away, as it belong= s to the signalling draft.

And, again, it was agreed that whether the m- line is associated with the C= LUE group or not has no semantical meaning.

Regards,

Christer



On 28/10/2014 12:03 AM, interne= t-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=C2=A0 =C2=A0This draft is a work item of the ControLling mUltiple stre= ams for tElepresence Working Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: CLUE Protocol Data Channel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : Christer Holmberg
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-clue-datachannel-02.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 13
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2014-10-27
>
> Abstract:
>=C2=A0 =C2=A0 =C2=A0This document defines how to use the WebRTC Data Ch= annel mechanism,
>=C2=A0 =C2=A0 =C2=A0together with the Data Channel Establishment Protoc= ol (DCEP) in order
>=C2=A0 =C2=A0 =C2=A0to establish a data channel, referred to as CLUE Da= ta Channel, for
>=C2=A0 =C2=A0 =C2=A0transporting CLUE protocol messages between two CLU= E entities.
>
>=C2=A0 =C2=A0 =C2=A0The document defines the SCTP considerations specif= ic to a CLUE Data
>=C2=A0 =C2=A0 =C2=A0Channel, the SDP offer/answer procedures for negoti= ating the
>=C2=A0 =C2=A0 =C2=A0establishment of, and the DCEP procedures for openi= ng, a CLUE Data
>=C2=A0 =C2=A0 =C2=A0Channel.
>
>=C2=A0 =C2=A0 =C2=A0Details and procedures associated with the CLUE pro= tocol are outside
>=C2=A0 =C2=A0 =C2=A0the scope of this document.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-clue-data= channel/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-clue-datachannel-02=
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clu= e-datachannel-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
>

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

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

--f46d044286dc540a4d05084031d2-- From nobody Thu Nov 20 17:06: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 39D8B1ACFC5; Thu, 20 Nov 2014 17:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_8eYV5VW1nh; Thu, 20 Nov 2014 17:06:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAF11ACFB9; Thu, 20 Nov 2014 17:06:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141121010651.2266.64801.idtracker@ietfa.amsl.com> Date: Thu, 20 Nov 2014 17:06:51 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/RZNPlvKukj9ROzSmkY7T0AcMkeQ Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 01:06:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : CLUE Protocol Data Channel Author : Christer Holmberg Filename : draft-ietf-clue-datachannel-03.txt Pages : 11 Date : 2014-11-20 Abstract: This document defines how to use the WebRTC Data Channel mechanism, together with the Data Channel Establishment Protocol (DCEP) and the SDP-based "SCTP over DTLS" data channel negotiation mechanism, in order to establish a data channel, referred to as CLUE Data Channel, for transporting CLUE protocol messages between two CLUE entities. The document defines the SCTP considerations specific to a CLUE Data Channel, the SDP Media Description- and SDP dcmap attribute values, and the DCEP procedures for opening, a CLUE Data Channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating a CLUE data channel, are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-datachannel-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 20 17:10: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 B1AB21ACFD9 for ; Thu, 20 Nov 2014 17:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YKZs6-D6QhY8 for ; Thu, 20 Nov 2014 17:10:16 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E2C1ACFD6 for ; Thu, 20 Nov 2014 17:10:14 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-e4-546e90f404e2 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D1.01.04081.4F09E645; Fri, 21 Nov 2014 02:10:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 02:10:12 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft new version: clue-datachannel-03 Thread-Index: AdAFJ4usxb+A7W9hQS2AY+H45QMkBg== Date: Fri, 21 Nov 2014 01:10:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52E027@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvje6XCXkhBo33pSz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL6TH5kL9rFWHLuyj7WBcQ1rFyMnh4SAicS9BzOZIWwxiQv3 1rN1MXJxCAkcYZS4c2oGC4SzhFHi9qolQBkODjYBC4nuf9ogDSICyhJHN/ezgdjCAvoSDYu/ MULETSQ2dU8HKxcR0JO43+QJEmYRUJV4v3AN2C5eAV+JOa2TwWxGoL3fT61hArGZBcQlbj2Z zwRxj4DEkj3noW4TlXj5+B/UzUoSjUuesIKMZxbQlFi/Sx+iVVFiSvdDdojxghInZz5hmcAo PAvJ1FkIHbOQdMxC0rGAkWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmBwH9zy22AH48vn jocYBTgYlXh4DSJzQ4RYE8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA2Pl1m05Txkes7rWK71Nns+RNqVe4FLgw6CVf6KmHW5+N+Vf4E6+Zmn1sFy/pr/PmOdu bjl2w2zFVmZhznfd3RqrNoZseq66oPTy9ek83xNKtAvntJdEr+x+xuDJmTDfWeH7weC/fH/l itqqN9qZ7J9lUnes+aCiT82N8qO3rrYEzex7ZN557ZISS3FGoqEWc1FxIgBUCrS+TwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VYtWf3mUacMK3BtK0MoVRThMIhg Subject: [clue] Draft new version: clue-datachannel-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 01:10:22 -0000 SGksDQoNCkkndmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gKC0wMykgb2YgdGhlIENMVUUgZGF0 YSBjaGFubmVsIGRyYWZ0Lg0KDQpUaGUgbWFpbiB0ZWNobmljYWwgY2hhbmdlIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgdGhhdCBJIGhhdmUgbm93IGFkZGVkIGRldGFpbHMgZm9yIHVzYWdl IG9mIEtlaXRoIFJpY2hhcmQncyBkcmFmdC4NCg0KTk9URSB0aGF0IG15IGFzc3VtcHRpb24gaXMg dGhhdCB3ZSB3aWxsIHN0aWxsIHVzZSBEQ0VQIHRvIGFjdHVhbGx5IG9wZW4gdGhlIENMVUUgZGF0 YSBjaGFubmVsLCBvbmNlIGl0IGhhcyBiZWVuIG5lZ290aWF0ZWQgdGhlIGRyYWZ0Lg0KDQpJIGhh dmUgYWxzbyByZW1vdmVkIHRoZSBTRFAgTy9BIHByb2NlZHVyZXMsIGFuZCBhZGRlZCBhIHJlZmVy ZW5jZSB0byB0aGUgQ0xVRSBwcm90b2NvbCBkcmFmdCBmb3IgdGhhdC4NCg0KQW5kLCB5ZXMsIEkg a25vdyBJIGhhdmUgdG8gZml4IHRhYmxlIDMgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From nobody Thu Nov 20 17:14: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 7776D1A8AD1 for ; Thu, 20 Nov 2014 17:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qNmStZ_F92PA for ; Thu, 20 Nov 2014 17:14:21 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82B01ACFD9 for ; Thu, 20 Nov 2014 17:14:20 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-c9-546e91ea782a Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 31.41.04081.AE19E645; Fri, 21 Nov 2014 02:14:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 02:14:18 +0100 From: Christer Holmberg To: Christer Holmberg , "clue@ietf.org" Thread-Topic: Draft new version: clue-datachannel-03 Thread-Index: AdAFJ4usxb+A7W9hQS2AY+H45QMkBgAANpbQ Date: Fri, 21 Nov 2014 01:14:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52E066@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D52E027@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52E027@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje6riXkhBs2bTSz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL53/9kK2jkq+npXsDUwHmTrYuTkkBAwkfh56iAzhC0mceHe eqA4F4eQwBFGiZ+nm5kgnCWMEj13TzB2MXJwsAlYSHT/0wZpEBGIlDi87h8jiC0sYCzx6+Ms Zoi4icSm7ulsIOUiAkYSc74lgJgsAqoS2zvNQCp4BXwlGpb/ZgWxhYDspyfes4PYnAJ+EnfP bQU7jRHonO+n1jCB2MwC4hK3nsxngjhTQGLJnvNQJ4tKvHz8jxXCVpJoXPKEFaJeR2LB7k9s ELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhFi1OLk3LTjYz0Uosyk4uL 8/P08lJLNjEC4+Hglt8GOxhfPnc8xCjAwajEw2sQmRsixJpYVlyZe4hRmoNFSZx34bl5wUIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY+Vu1fihF6n4WVeR0/lb7xnnKwjus24r3BJZ7nw1m /LPt3Zcgv4n7Jyk2puZbqe79EuylcsY7+IEIg4jiygO5csu3J95YIFH5VnYfY4rZljfMEjPO RSxY9OHGJOYmloZ2doHbbi5tB5vyRM7b/Ky/vTD4fE7RXf+QDaWnnJNmK16dkTThhe5jJZbi jERDLeai4kQAhE3LHWgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/nWCfjg2LDo8MyRTyyYLVCqUQPhQ Subject: Re: [clue] Draft new version: clue-datachannel-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 01:14:23 -0000 Hi, In addition, I also removed the text about SCTP interleaving, based on the = assumption that there is nothing CLUE specific regarding that. Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 21 November 2014 03:10 To: clue@ietf.org Subject: [clue] Draft new version: clue-datachannel-03 Hi, I've submitted a new version (-03) of the CLUE data channel draft. The main technical change from the previous version is that I have now adde= d details for usage of Keith Richard's draft. NOTE that my assumption is that we will still use DCEP to actually open the= CLUE data channel, once it has been negotiated the draft. I have also removed the SDP O/A procedures, and added a reference to the CL= UE protocol draft for that. And, yes, I know I have to fix table 3 :) Regards, Christer _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Thu Nov 20 19:23: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 32A161A8FD2 for ; Thu, 20 Nov 2014 19:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrS2KzrFDLuh for ; Thu, 20 Nov 2014 19:23:26 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C401A8F45 for ; Thu, 20 Nov 2014 19:23:25 -0800 (PST) Received: from ppp118-209-248-117.lns20.mel8.internode.on.net ([118.209.248.117]:55488 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XreoX-0006n0-EM for clue@ietf.org; Fri, 21 Nov 2014 14:23:17 +1100 Message-ID: <546EB026.4090207@nteczone.com> Date: Fri, 21 Nov 2014 14:23:18 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D52E027@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52E066@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52E066@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/sGlnVrTcblTh340Xgbg0nlA8UyY Subject: Re: [clue] Draft new version: clue-datachannel-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 03:23:28 -0000 Hello Christer, A few of comments: 1. You need to update table 3.... :-) 2. Cl.3.2.1 - It's draft-ietf-clue-signaling-04 that describes the SDP O/A procedures not the protocol draft. 3. Cl.3.2.4 - WebRTC datachannel indicates that the subprotocol is optional. However for CLUE I assume that this is a mandatory parameter with value equal to "CLUE"? The table suggests it's optional. 4. Cl.3.2.4 - What's your intention on the use of label? The table suggests that its optional but if included must have the value "CLUE Data Channel" 5. Cl.3.3.1 - Can we now delete the note in this section also? 6. Cl.3.3.2 - Should we move the note to the IANA considerations section given that it applies to both clauses 3.2.4 and 3.3.2? 7. Cl.3.2.4 - I'm not sure the SCTP stream ID always need to be provided especially if there's only one CLUE subprotocol instance for each DTLS/SCTP association. This is more of a comment on the ejzak draft. Regards, Christian On 21/11/2014 12:14 PM, Christer Holmberg wrote: > Hi, > > In addition, I also removed the text about SCTP interleaving, based on the assumption that there is nothing CLUE specific regarding that. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 21 November 2014 03:10 > To: clue@ietf.org > Subject: [clue] Draft new version: clue-datachannel-03 > > Hi, > > I've submitted a new version (-03) of the CLUE data channel draft. > > The main technical change from the previous version is that I have now added details for usage of Keith Richard's draft. > > NOTE that my assumption is that we will still use DCEP to actually open the CLUE data channel, once it has been negotiated the draft. > > I have also removed the SDP O/A procedures, and added a reference to the CLUE protocol draft for that. > > And, yes, I know I have to fix table 3 :) > > 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 nobody Thu Nov 20 19:25: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 CF2EB1A901C for ; Thu, 20 Nov 2014 19:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.054 X-Spam-Level: ** X-Spam-Status: No, score=2.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 CqKAbKr5vbMO for ; Thu, 20 Nov 2014 19:25:02 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D8A1A900B for ; Thu, 20 Nov 2014 19:25:01 -0800 (PST) Received: from ppp118-209-248-117.lns20.mel8.internode.on.net ([118.209.248.117]:55490 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xreq6-00073T-9t for clue@ietf.org; Fri, 21 Nov 2014 14:24:54 +1100 Message-ID: <546EB087.1060204@nteczone.com> Date: Fri, 21 Nov 2014 14:24:55 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> <00eb01cffeb8$41829c30$c487d490$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> <013a01cffed0$926aa8f0$b73ffad0$@gmail.com> <546424B1.7010408@alum.mit.edu> In-Reply-To: <546424B1.7010408@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/OkqQGJgR5gDpqZHZxMcW6RpKCv4 Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 03:25:05 -0000 What's the status of the simultcast issue after the meeting? I saw some meeting notes to suggest that it would be removed from CLUE. I certainly didn't expect that from the discussions on the list. Regards, Christian On 13/11/2014 2:25 PM, Paul Kyzivat wrote: > If an sdp-based mechanism is published that allows simulcast in a > single m-line, then clue gets to take advantage of that *for free*. I > don't know that we need to say anything about that. > > The question we have to ask is: do we want to remove the clue-specific > mechanism that is already present in our data model? > > To that I will add the corollary question: is there any cost to having > that option in there? > > I can't see any cost. > - Advertisers don't have to use it in their advertisements. > - Consumers can't use it in Configure if it wasn't in the advertisement > - Consumers don't have to use it if it is in the advertisement. > > So I see no harm in leaving it in. And some potential benefit to > having it there. > > Thanks, > Paul > > On 11/12/14 1:29 PM, Roni Even wrote: >> Hi, >> This is what started the discussion. If we do not have SDP based >> simulcast >> based on unified plan, the only semantics is an encoding per m-line. We >> started the discussion based on this assumption that we can do >> simulcast in >> CLUE using an encoding per m-line and can bundle them >> Roni >> >>> -----Original Message----- >>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] >>> Sent: 12 November, 2014 11:03 PM >>> To: Duckworth, Mark; Roni Even >>> Cc: clue@ietf.org >>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>> >>> Yes, I'd have thought ideally multiple simulcast qualities, repair >>> streams >> etc >>> would be defined under a single m-line and hence be a single >>> encoding from >>> CLUE's perspective. That matches the unified plan and the proposal in >> draft- >>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it would >>> mean >>> that negotiating simulcast qualities, repair flows etc would be >>> purely an >> SDP >>> issue and wouldn't impact CLUE. >>> >>> Rob >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark >>> Sent: 12 November 2014 10:54 >>> To: Roni Even >>> Cc: clue@ietf.org >>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>> >>> Hi, >>> >>> I don't understand why simulcast would need separate encoding groups. >>> >>> Whether an MC maps to two m-lines or one m-line with a=simulcast is >>> up to >>> the consumer, and specified in the configure message sent from >>> consumer to >>> provider. The mapping is done via the encoding ID labels which link >>> media >>> captures to m-lines. At least that is how I see it. >>> >>> Would you say retransmission streams are a separate issue from >>> simulcast? >> Or >>> are they similar enough that it is really the same issue? Do SVC >>> layered >> codec >>> streams also fall into this category? >>> >>> Sounds like we do need some more discussion about this. My first >>> thought >> is >>> we should cover this in the signaling document. >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>> Sent: Wednesday, November 12, 2014 10:36 AM >>>> To: Duckworth, Mark >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> Hi, >>>> This will work when we have a single encoding per m-line in the SDP >>>> and I think it requires that each simulcast set will be in separate >>>> encoding group . Still it will provide less functionality than the one >>>> proposed in the simulcast proposal that will be discussed in MMUSIC If >>>> simulcast in SDP will progress using the unified plan where we have >>>> all encodings in one m-line we will need to specify that if an MC have >>>> max capture encoding >1 will it mean that it will map to two m-lines >>>> or will it use a configuration from an SDP description a=simulcast. >>>> >>>> We will need to see how it works with retransmission if we specify a >>>> retransmission RTP stream as an individual encoding. >>>> >>>> Roni >>>> >>>>> -----Original Message----- >>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] >>>>> Sent: 06 November, 2014 9:45 PM >>>>> To: Roni Even >>>>> Cc: clue@ietf.org >>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>> >>>>> Hi Roni, >>>>> Do you still have questions about the way simulcast is handled in >>>>> the framework, regarding the attribute "Max capture encodings" and >>>> configuring >>>>> multiple encodings per capture? I was hoping we could resolve it on >>>>> the >>>> list, or >>>>> do you think we need to talk about it in Honolulu? >>>>> Regards, >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, >>>> Mark >>>>>> Sent: Monday, November 03, 2014 10:52 PM >>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >>>>>>> Sent: Monday, November 03, 2014 5:52 PM >>>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>> Christian Groves >>>>>>>> Sent: 28 October, 2014 2:56 AM >>>>>>>> To: clue@ietf.org >>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>> >>>>>>>> Hello Roni, >>>>>>>> >>>>>>>> As I mentioned in my original reply I think the RTP based >>>>>>>> simulcast >>>>>> method >>>>>>> is >>>>>>>> probably the cleanest approach. There would be nothing >>>>>>>> stopping a CLUE endpoint implementing it when it becomes >>>>>>>> available (like many other RTP features). Using CLUE for >>>>>>>> simulcast I think is possible for most >>>>>>> scenarios. The >>>>>>>> more complicated the scenarios the more MCs/encodings an >>>> endpoint >>>>>> will >>>>>>>> need to describe the situation. >>>>>>>> >>>>>>>> Please see my response below. >>>>>>>> >>>>>>>> Regards, Christian >>>>>>>> >>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: >>>>>>>>> Hi Paul, >>>>>>>>> >>>>>>>>> If we want to be able to differentiate between simulcast and >>>>>>>>> switched capture, for example if we have a three camera >>>>>>>>> system that can send three MCs each with two encodings >>>>>>>>> (simulcast) and a switched capture (loudest speaker or two >>>>>>>>> loudest speakers out of three) using the same simulcast >>>>>>>>> option for the each MC currently sent. In this case we can >>>>>>>>> have an MC with two encodings and an MCC with the three MCs. >>>>>>>>> This >>>>>> will >>>>>>>>> require us to clarify that having multiple individual >>>>>>>>> encodings in MC is simulcast and not switched and in MCC it >>>>>>>>> is switched and not >>>>>> simulcast. >>>>>>>> [CNG] I don't understand exactly what the issue is here? Could >>>>>>>> you use >>>>>> some >>>>>>>> pseudo syntax to explain what you're wanting to advertise? You >>>>>>>> say in >>>>>> the first >>>>>>>> sentence the switched capture uses simulcast but then in the >>>>>>>> last >>>>>> sentence you >>>>>>>> say the MCC is switched and not simulcast. I would think that >>>>>>>> an MCC can >>>>>> still >>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts >>>>>>>> whatever source >>>>>> is >>>>>>>> switched into the media stream. >>>>>>>> If you want a pure switched MCC just set maxCaptureEncodings >>>>>>>> to 1 >>>>>> against the >>>>>>>> MCC. >>>>>>>> If you want a simultcast MCC just set maxCaptureEncodings to >>>>>>>>> =2 >>>>>> against the >>>>>>>> MCC. >>>>>>> >>>>>>> [Roni Even] The thing is that I am not sure how to advertise >>>>>>> this >>>> example. >>>>>>> >>>>>>> The advertisement has two scene views: >>>>>>> 1. Scene view with VC0, VC1, VC2 each with two simulcast streams >> 2. >>>>>>> Scene view MCC3 as represented bellow >>>>>>> >>>>>>> The different MCs will be: >>>>>>> >>>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, >>>>>>> MaxCaptures=2 >>>>>> >>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture >>>>>> Encodings"? >>>>>> Don't confuse this with the MCC attribute MaxCaptures which means >>>> "Max >>>>>> number of Captures within a MCC". >>>>>> >>>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>>> view=table, >>>>>>> MaxCaptures=2 >>>>>>> >>>>>>> VC2- (the right camera stream), encoding group=EG0, view=table. >>>>>>> MaxCaptures=2 >>>>>>> >>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=EG0, view=room, >>>>>> MaxCaptures=2 >>>>>> >>>>>> [Duckworth, Mark] It isn't clear if you really mean "max capture >>>> encodings" >>>>>> or >>>>>> "max number of captures within a MCC". Those are two different >> things. >>>>>> >>>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. >>>>>> >>>>>> [Duckworth, Mark] It depends how the consumer configures it. The >>>>>> provider advertisement says it supports simulcast, so the consumer >>>>>> can decide to use it or not. >>>>>> >>>>>>> What about MCC3? >>>>>>> Is it multicast from one of the cameras or is it 2 MCs out of >>>>>>> the three? (I assume it is the first since the view is room) >>>>>> >>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three >>>>>> simultaneously only if it is composed, not if it is switched. The >>>>>> provider can give more information, if it wants to, with the MCC >>>>>> attribute "max number of captures within a MCC". >>>>>> >>>>>>> What if in the above example MaxCaptures=4 can it be for >>>>>>> example VC0, >>>>>> VC1 >>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and one >>>>>>> of them is >>>>>> simulcast? >>>>>> >>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" >>>>>> capture. >>>>>> It sounds like you are talking about a switched case, not a >>>>>> composed case, so let's say MCC3 has the attribute "max number of >>>>>> captures within >>>> a >>>>> MCC" = 1. >>>>>> Now let's also suppose MCC3 has "max capture encodings" = 2. Then >>>>>> the consumer can ask for, say, MCC3 at 720p and SIF, for the two >>>>>> encodings. Then the provider decides when to switch among VC0, >>>>>> VC1, and VC2, and whichever one the provider is sending for MCC3 >>>>>> it sends it at both SIF and 720p, so MCC3 is simulcast at those >>>>>> two resolutions. >>>>>> >>>>>>> What I am trying to say is that using implied simulcast require >>>>>>> text explaining when a consumer can understand that the >>>>>>> advertisement is simulcast and not something else. >>>>>> >>>>>>> The other approach may be to have an attribute for an MC and MCC >>>>>>> that >>>>>> will >>>>>>> explicitly say that this is a simulcast offer. >>>>>> >>>>>> [Duckworth, Mark] I think the advertisement is clear to the >>>>>> consumer without any additional text or attributes added to the >>>>>> framework. It is already explicit, with the attribute "max >>>>>> capture encodings". If it is >1, then the advertisement is offering >>> simulcast. >>>>>> >>>>>>> BTW: I think that the implied solution works when the individual >>>>>>> encodings are the same (spatial or different codces) what if we >>>>>>> the provider can send >>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four >>>>>>> different encodings but not all combinations allowed. How to >>>>>>> represent it in an advertisement? Is it : >>>>>> >>>>>> [Duckworth, Mark] I can consider this case after we get the first >>>>>> case above cleared up. >>>>>> >>>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, >>>>>>> MaxCaptures=2 >>>>>>> >>>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>>> view=table, >>>>>>> MaxCaptures=2 >>>>>>> >>>>>>> VC2- (the right camera stream), encoding group=EG0, view=table. >>>>>>> MaxCaptures=2 >>>>>>> >>>>>>> VC3- (the left camera stream), encoding group=EG1, view=table, >>>>>>> MaxCaptures=2 >>>>>>> >>>>>>> VC4- (the center camera stream), encoding group=EG1, >>>>>>> view=table, >>>>>>> MaxCaptures=2 >>>>>>> >>>>>>> VC5- (the right camera stream), encoding group=EG1, view=table. >>>>>>> MaxCaptures=2 >>>>>>> >>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two >>>>>>> scene views >>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? >>>>>>> >>>>>> ... snip ... >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Nov 20 21:59: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 C4A5F1AD0C4 for ; Thu, 20 Nov 2014 21:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hkwdUQbf5iA for ; Thu, 20 Nov 2014 21:58:58 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFE31AD0C2 for ; Thu, 20 Nov 2014 21:58:57 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-f3-546ed49f1908 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.45.04076.F94DE645; Fri, 21 Nov 2014 06:58:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 06:58:55 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczEwHhC5T4AsgMzZABSFF3zwGQAdjcAfUTyVUCDwh2XQGoOPavm3HaKtCAAAU/QP//9C2AgAApHQCAAEHegIAMknWAgAA7leA= Date: Fri, 21 Nov 2014 05:58:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52E4D5@ESESSMB209.ericsson.se> References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> <00eb01cffeb8$41829c30$c487d490$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> <013a01cffed0$926aa8f0$b73ffad0$@gmail.com> <546424B1.7010408@alum.mit.edu> <546EB087.1060204@nteczone.com> In-Reply-To: <546EB087.1060204@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvje78K3khBjfvmlp8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugSvjyNr7rAVz8yv2HNvL2MDYHN3FyMkhIWAi 8fbBdUYIW0ziwr31bF2MXBxCAkcYJWb8WQLlLGGUOLxyDZDDwcEmYCHR/U8bpEFEIFyiY9sV sGZhAWOJL/MvskLETSSe/1jGCtIrIrAJqPfxAbAiFgFViftH77OD2LwCvhL9tzYwQizYxy7x 88gcZpAEp4COxKxvp8EaGIFO+n5qDROIzSwgLnHryXwmiFMFJJbsOc8MYYtKvHz8jxXCVpJY sf0SI0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcW F+emGxnppRZlJhcX5+fp5aWWbGIExsrBLb+tdjAefO54iFGAg1GJh3fDqrwQIdbEsuLK3EOM 0hwsSuK8C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuPBK6+uQkv6eG0u5buac3LOr Si5iccTyDp/ydQrXc4VV7k6a6WLuGmR6Yl/W0nf6rOIrpsR/WnC3IWM15z0X4bechdMVHl32 m8MUZvpd1sZUoCWYW1b2bP+p6uP6/FX9eyL8zifbrTiyU+rJtP0K2pP2/1Z4cO3yvSN7EhW6 JppdXlf5Ue06pxJLcUaioRZzUXEiANbjuTh2AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3mCY7rJ1UJw18BtW31CHxoq3Wg8 Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 05:59:02 -0000 Hi, The generic simulcast draft was adopted in MMUSIC, and the idea is that it = will be used also if someone wants to provide simulcast for CLUE. Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves Sent: 21 November 2014 05:25 To: clue@ietf.org Subject: Re: [clue] CLUE and Simulcast - ticket #47 What's the status of the simultcast issue after the meeting? I saw some mee= ting notes to suggest that it would be removed from CLUE. I certainly didn'= t expect that from the discussions on the list. Regards, Christian On 13/11/2014 2:25 PM, Paul Kyzivat wrote: > If an sdp-based mechanism is published that allows simulcast in a=20 > single m-line, then clue gets to take advantage of that *for free*. I=20 > don't know that we need to say anything about that. > > The question we have to ask is: do we want to remove the clue-specific=20 > mechanism that is already present in our data model? > > To that I will add the corollary question: is there any cost to having=20 > that option in there? > > I can't see any cost. > - Advertisers don't have to use it in their advertisements. > - Consumers can't use it in Configure if it wasn't in the=20 > advertisement > - Consumers don't have to use it if it is in the advertisement. > > So I see no harm in leaving it in. And some potential benefit to=20 > having it there. > > Thanks, > Paul > > On 11/12/14 1:29 PM, Roni Even wrote: >> Hi, >> This is what started the discussion. If we do not have SDP based=20 >> simulcast based on unified plan, the only semantics is an encoding=20 >> per m-line. We started the discussion based on this assumption that=20 >> we can do simulcast in CLUE using an encoding per m-line and can=20 >> bundle them Roni >> >>> -----Original Message----- >>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] >>> Sent: 12 November, 2014 11:03 PM >>> To: Duckworth, Mark; Roni Even >>> Cc: clue@ietf.org >>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>> >>> Yes, I'd have thought ideally multiple simulcast qualities, repair=20 >>> streams >> etc >>> would be defined under a single m-line and hence be a single=20 >>> encoding from CLUE's perspective. That matches the unified plan and=20 >>> the proposal in >> draft- >>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it would=20 >>> mean that negotiating simulcast qualities, repair flows etc would be=20 >>> purely an >> SDP >>> issue and wouldn't impact CLUE. >>> >>> Rob >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth,=20 >>> Mark >>> Sent: 12 November 2014 10:54 >>> To: Roni Even >>> Cc: clue@ietf.org >>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>> >>> Hi, >>> >>> I don't understand why simulcast would need separate encoding groups. >>> >>> Whether an MC maps to two m-lines or one m-line with a=3Dsimulcast is=20 >>> up to the consumer, and specified in the configure message sent from=20 >>> consumer to provider. The mapping is done via the encoding ID=20 >>> labels which link media captures to m-lines. At least that is how I=20 >>> see it. >>> >>> Would you say retransmission streams are a separate issue from=20 >>> simulcast? >> Or >>> are they similar enough that it is really the same issue? Do SVC=20 >>> layered >> codec >>> streams also fall into this category? >>> >>> Sounds like we do need some more discussion about this. My first=20 >>> thought >> is >>> we should cover this in the signaling document. >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>> Sent: Wednesday, November 12, 2014 10:36 AM >>>> To: Duckworth, Mark >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> Hi, >>>> This will work when we have a single encoding per m-line in the SDP=20 >>>> and I think it requires that each simulcast set will be in separate=20 >>>> encoding group . Still it will provide less functionality than the=20 >>>> one proposed in the simulcast proposal that will be discussed in=20 >>>> MMUSIC If simulcast in SDP will progress using the unified plan=20 >>>> where we have all encodings in one m-line we will need to specify=20 >>>> that if an MC have max capture encoding >1 will it mean that it=20 >>>> will map to two m-lines or will it use a configuration from an SDP des= cription a=3Dsimulcast. >>>> >>>> We will need to see how it works with retransmission if we specify=20 >>>> a retransmission RTP stream as an individual encoding. >>>> >>>> Roni >>>> >>>>> -----Original Message----- >>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] >>>>> Sent: 06 November, 2014 9:45 PM >>>>> To: Roni Even >>>>> Cc: clue@ietf.org >>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>> >>>>> Hi Roni, >>>>> Do you still have questions about the way simulcast is handled in=20 >>>>> the framework, regarding the attribute "Max capture encodings" and >>>> configuring >>>>> multiple encodings per capture? I was hoping we could resolve it=20 >>>>> on the >>>> list, or >>>>> do you think we need to talk about it in Honolulu? >>>>> Regards, >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, >>>> Mark >>>>>> Sent: Monday, November 03, 2014 10:52 PM >>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >>>>>>> Sent: Monday, November 03, 2014 5:52 PM >>>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of=20 >>>>>>>> Christian Groves >>>>>>>> Sent: 28 October, 2014 2:56 AM >>>>>>>> To: clue@ietf.org >>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>> >>>>>>>> Hello Roni, >>>>>>>> >>>>>>>> As I mentioned in my original reply I think the RTP based=20 >>>>>>>> simulcast >>>>>> method >>>>>>> is >>>>>>>> probably the cleanest approach. There would be nothing stopping=20 >>>>>>>> a CLUE endpoint implementing it when it becomes available (like=20 >>>>>>>> many other RTP features). Using CLUE for simulcast I think is=20 >>>>>>>> possible for most >>>>>>> scenarios. The >>>>>>>> more complicated the scenarios the more MCs/encodings an >>>> endpoint >>>>>> will >>>>>>>> need to describe the situation. >>>>>>>> >>>>>>>> Please see my response below. >>>>>>>> >>>>>>>> Regards, Christian >>>>>>>> >>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: >>>>>>>>> Hi Paul, >>>>>>>>> >>>>>>>>> If we want to be able to differentiate between simulcast and=20 >>>>>>>>> switched capture, for example if we have a three camera system=20 >>>>>>>>> that can send three MCs each with two encodings >>>>>>>>> (simulcast) and a switched capture (loudest speaker or two=20 >>>>>>>>> loudest speakers out of three) using the same simulcast option=20 >>>>>>>>> for the each MC currently sent. In this case we can have an MC=20 >>>>>>>>> with two encodings and an MCC with the three MCs. >>>>>>>>> This >>>>>> will >>>>>>>>> require us to clarify that having multiple individual=20 >>>>>>>>> encodings in MC is simulcast and not switched and in MCC it is=20 >>>>>>>>> switched and not >>>>>> simulcast. >>>>>>>> [CNG] I don't understand exactly what the issue is here? Could=20 >>>>>>>> you use >>>>>> some >>>>>>>> pseudo syntax to explain what you're wanting to advertise? You=20 >>>>>>>> say in >>>>>> the first >>>>>>>> sentence the switched capture uses simulcast but then in the=20 >>>>>>>> last >>>>>> sentence you >>>>>>>> say the MCC is switched and not simulcast. I would think that=20 >>>>>>>> an MCC can >>>>>> still >>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts=20 >>>>>>>> whatever source >>>>>> is >>>>>>>> switched into the media stream. >>>>>>>> If you want a pure switched MCC just set maxCaptureEncodings to=20 >>>>>>>> 1 >>>>>> against the >>>>>>>> MCC. >>>>>>>> If you want a simultcast MCC just set maxCaptureEncodings to >>>>>>>>> =3D2 >>>>>> against the >>>>>>>> MCC. >>>>>>> >>>>>>> [Roni Even] The thing is that I am not sure how to advertise=20 >>>>>>> this >>>> example. >>>>>>> >>>>>>> The advertisement has two scene views: >>>>>>> 1. Scene view with VC0, VC1, VC2 each with two simulcast=20 >>>>>>> streams >> 2. >>>>>>> Scene view MCC3 as represented bellow >>>>>>> >>>>>>> The different MCs will be: >>>>>>> >>>>>>> VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, >>>>>>> MaxCaptures=3D2 >>>>>> >>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture=20 >>>>>> Encodings"? >>>>>> Don't confuse this with the MCC attribute MaxCaptures which means >>>> "Max >>>>>> number of Captures within a MCC". >>>>>> >>>>>>> VC1- (the center camera stream), encoding group=3DEG0,=20 >>>>>>> view=3Dtable, >>>>>>> MaxCaptures=3D2 >>>>>>> >>>>>>> VC2- (the right camera stream), encoding group=3DEG0, view=3Dtabl= e. >>>>>>> MaxCaptures=3D2 >>>>>>> >>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=3DEG0, view=3Droom, >>>>>> MaxCaptures=3D2 >>>>>> >>>>>> [Duckworth, Mark] It isn't clear if you really mean "max capture >>>> encodings" >>>>>> or >>>>>> "max number of captures within a MCC". Those are two different >> things. >>>>>> >>>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. >>>>>> >>>>>> [Duckworth, Mark] It depends how the consumer configures it. The=20 >>>>>> provider advertisement says it supports simulcast, so the=20 >>>>>> consumer can decide to use it or not. >>>>>> >>>>>>> What about MCC3? >>>>>>> Is it multicast from one of the cameras or is it 2 MCs out of=20 >>>>>>> the three? (I assume it is the first since the view is room) >>>>>> >>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three=20 >>>>>> simultaneously only if it is composed, not if it is switched. =20 >>>>>> The provider can give more information, if it wants to, with the=20 >>>>>> MCC attribute "max number of captures within a MCC". >>>>>> >>>>>>> What if in the above example MaxCaptures=3D4 can it be for example= =20 >>>>>>> VC0, >>>>>> VC1 >>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and one=20 >>>>>>> of them is >>>>>> simulcast? >>>>>> >>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" >>>>>> capture. >>>>>> It sounds like you are talking about a switched case, not a=20 >>>>>> composed case, so let's say MCC3 has the attribute "max number of=20 >>>>>> captures within >>>> a >>>>> MCC" =3D 1. >>>>>> Now let's also suppose MCC3 has "max capture encodings" =3D 2. =20 >>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, for the=20 >>>>>> two encodings. Then the provider decides when to switch among=20 >>>>>> VC0, VC1, and VC2, and whichever one the provider is sending for=20 >>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast at=20 >>>>>> those two resolutions. >>>>>> >>>>>>> What I am trying to say is that using implied simulcast require=20 >>>>>>> text explaining when a consumer can understand that the=20 >>>>>>> advertisement is simulcast and not something else. >>>>>> >>>>>>> The other approach may be to have an attribute for an MC and MCC=20 >>>>>>> that >>>>>> will >>>>>>> explicitly say that this is a simulcast offer. >>>>>> >>>>>> [Duckworth, Mark] I think the advertisement is clear to the=20 >>>>>> consumer without any additional text or attributes added to the=20 >>>>>> framework. It is already explicit, with the attribute "max=20 >>>>>> capture encodings". If it is >1, then the advertisement is=20 >>>>>> offering >>> simulcast. >>>>>> >>>>>>> BTW: I think that the implied solution works when the individual=20 >>>>>>> encodings are the same (spatial or different codces) what if we=20 >>>>>>> the provider can send >>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four=20 >>>>>>> different encodings but not all combinations allowed. How to=20 >>>>>>> represent it in an advertisement? Is it : >>>>>> >>>>>> [Duckworth, Mark] I can consider this case after we get the first=20 >>>>>> case above cleared up. >>>>>> >>>>>>> VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, >>>>>>> MaxCaptures=3D2 >>>>>>> >>>>>>> VC1- (the center camera stream), encoding group=3DEG0,=20 >>>>>>> view=3Dtable, >>>>>>> MaxCaptures=3D2 >>>>>>> >>>>>>> VC2- (the right camera stream), encoding group=3DEG0, view=3Dtabl= e. >>>>>>> MaxCaptures=3D2 >>>>>>> >>>>>>> VC3- (the left camera stream), encoding group=3DEG1, view=3Dtable, >>>>>>> MaxCaptures=3D2 >>>>>>> >>>>>>> VC4- (the center camera stream), encoding group=3DEG1,=20 >>>>>>> view=3Dtable, >>>>>>> MaxCaptures=3D2 >>>>>>> >>>>>>> VC5- (the right camera stream), encoding group=3DEG1, view=3Dtabl= e. >>>>>>> MaxCaptures=3D2 >>>>>>> >>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two=20 >>>>>>> scene views >>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? >>>>>>> >>>>>> ... snip ... >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Thu Nov 20 22:04: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 A0F3A1AD0C3 for ; Thu, 20 Nov 2014 22:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.054 X-Spam-Level: ** X-Spam-Status: No, score=2.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 JEkzw7aT_qLj for ; Thu, 20 Nov 2014 22:04:04 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4E61AD0C4 for ; Thu, 20 Nov 2014 22:04:03 -0800 (PST) Received: from ppp118-209-248-117.lns20.mel8.internode.on.net ([118.209.248.117]:57119 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XrhJy-0001IW-27; Fri, 21 Nov 2014 17:03:54 +1100 Message-ID: <546ED5CC.5020807@nteczone.com> Date: Fri, 21 Nov 2014 17:03:56 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> <00eb01cffeb8$41829c30$c487d490$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> <013a01cffed0$926aa8f0$b73ffad0$@gmail.com> <546424B1.7010408@alum.mit.edu> <546EB087.1060204@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D52E4D5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52E4D5@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3PhigaIPT3Yz3joDV_Ui6n3bjNc Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 06:04:09 -0000 Hello Christer, Yes, I thought the assumption was nothing in CLUE prevented the use of the generic simulcast draft. I'm wondering why the adoption of that meant part of CLUE was removed (at least as I understand from the notes)? Regards, Christian On 21/11/2014 4:58 PM, Christer Holmberg wrote: > Hi, > > The generic simulcast draft was adopted in MMUSIC, and the idea is that it will be used also if someone wants to provide simulcast for CLUE. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 21 November 2014 05:25 > To: clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > What's the status of the simultcast issue after the meeting? I saw some meeting notes to suggest that it would be removed from CLUE. I certainly didn't expect that from the discussions on the list. > > Regards, Christian > > On 13/11/2014 2:25 PM, Paul Kyzivat wrote: >> If an sdp-based mechanism is published that allows simulcast in a >> single m-line, then clue gets to take advantage of that *for free*. I >> don't know that we need to say anything about that. >> >> The question we have to ask is: do we want to remove the clue-specific >> mechanism that is already present in our data model? >> >> To that I will add the corollary question: is there any cost to having >> that option in there? >> >> I can't see any cost. >> - Advertisers don't have to use it in their advertisements. >> - Consumers can't use it in Configure if it wasn't in the >> advertisement >> - Consumers don't have to use it if it is in the advertisement. >> >> So I see no harm in leaving it in. And some potential benefit to >> having it there. >> >> Thanks, >> Paul >> >> On 11/12/14 1:29 PM, Roni Even wrote: >>> Hi, >>> This is what started the discussion. If we do not have SDP based >>> simulcast based on unified plan, the only semantics is an encoding >>> per m-line. We started the discussion based on this assumption that >>> we can do simulcast in CLUE using an encoding per m-line and can >>> bundle them Roni >>> >>>> -----Original Message----- >>>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] >>>> Sent: 12 November, 2014 11:03 PM >>>> To: Duckworth, Mark; Roni Even >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> Yes, I'd have thought ideally multiple simulcast qualities, repair >>>> streams >>> etc >>>> would be defined under a single m-line and hence be a single >>>> encoding from CLUE's perspective. That matches the unified plan and >>>> the proposal in >>> draft- >>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it would >>>> mean that negotiating simulcast qualities, repair flows etc would be >>>> purely an >>> SDP >>>> issue and wouldn't impact CLUE. >>>> >>>> Rob >>>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, >>>> Mark >>>> Sent: 12 November 2014 10:54 >>>> To: Roni Even >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> Hi, >>>> >>>> I don't understand why simulcast would need separate encoding groups. >>>> >>>> Whether an MC maps to two m-lines or one m-line with a=simulcast is >>>> up to the consumer, and specified in the configure message sent from >>>> consumer to provider. The mapping is done via the encoding ID >>>> labels which link media captures to m-lines. At least that is how I >>>> see it. >>>> >>>> Would you say retransmission streams are a separate issue from >>>> simulcast? >>> Or >>>> are they similar enough that it is really the same issue? Do SVC >>>> layered >>> codec >>>> streams also fall into this category? >>>> >>>> Sounds like we do need some more discussion about this. My first >>>> thought >>> is >>>> we should cover this in the signaling document. >>>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Wednesday, November 12, 2014 10:36 AM >>>>> To: Duckworth, Mark >>>>> Cc: clue@ietf.org >>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>> >>>>> Hi, >>>>> This will work when we have a single encoding per m-line in the SDP >>>>> and I think it requires that each simulcast set will be in separate >>>>> encoding group . Still it will provide less functionality than the >>>>> one proposed in the simulcast proposal that will be discussed in >>>>> MMUSIC If simulcast in SDP will progress using the unified plan >>>>> where we have all encodings in one m-line we will need to specify >>>>> that if an MC have max capture encoding >1 will it mean that it >>>>> will map to two m-lines or will it use a configuration from an SDP description a=simulcast. >>>>> >>>>> We will need to see how it works with retransmission if we specify >>>>> a retransmission RTP stream as an individual encoding. >>>>> >>>>> Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] >>>>>> Sent: 06 November, 2014 9:45 PM >>>>>> To: Roni Even >>>>>> Cc: clue@ietf.org >>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>> Hi Roni, >>>>>> Do you still have questions about the way simulcast is handled in >>>>>> the framework, regarding the attribute "Max capture encodings" and >>>>> configuring >>>>>> multiple encodings per capture? I was hoping we could resolve it >>>>>> on the >>>>> list, or >>>>>> do you think we need to talk about it in Honolulu? >>>>>> Regards, >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, >>>>> Mark >>>>>>> Sent: Monday, November 03, 2014 10:52 PM >>>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org >>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >>>>>>>> Sent: Monday, November 03, 2014 5:52 PM >>>>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>> Christian Groves >>>>>>>>> Sent: 28 October, 2014 2:56 AM >>>>>>>>> To: clue@ietf.org >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>> >>>>>>>>> Hello Roni, >>>>>>>>> >>>>>>>>> As I mentioned in my original reply I think the RTP based >>>>>>>>> simulcast >>>>>>> method >>>>>>>> is >>>>>>>>> probably the cleanest approach. There would be nothing stopping >>>>>>>>> a CLUE endpoint implementing it when it becomes available (like >>>>>>>>> many other RTP features). Using CLUE for simulcast I think is >>>>>>>>> possible for most >>>>>>>> scenarios. The >>>>>>>>> more complicated the scenarios the more MCs/encodings an >>>>> endpoint >>>>>>> will >>>>>>>>> need to describe the situation. >>>>>>>>> >>>>>>>>> Please see my response below. >>>>>>>>> >>>>>>>>> Regards, Christian >>>>>>>>> >>>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: >>>>>>>>>> Hi Paul, >>>>>>>>>> >>>>>>>>>> If we want to be able to differentiate between simulcast and >>>>>>>>>> switched capture, for example if we have a three camera system >>>>>>>>>> that can send three MCs each with two encodings >>>>>>>>>> (simulcast) and a switched capture (loudest speaker or two >>>>>>>>>> loudest speakers out of three) using the same simulcast option >>>>>>>>>> for the each MC currently sent. In this case we can have an MC >>>>>>>>>> with two encodings and an MCC with the three MCs. >>>>>>>>>> This >>>>>>> will >>>>>>>>>> require us to clarify that having multiple individual >>>>>>>>>> encodings in MC is simulcast and not switched and in MCC it is >>>>>>>>>> switched and not >>>>>>> simulcast. >>>>>>>>> [CNG] I don't understand exactly what the issue is here? Could >>>>>>>>> you use >>>>>>> some >>>>>>>>> pseudo syntax to explain what you're wanting to advertise? You >>>>>>>>> say in >>>>>>> the first >>>>>>>>> sentence the switched capture uses simulcast but then in the >>>>>>>>> last >>>>>>> sentence you >>>>>>>>> say the MCC is switched and not simulcast. I would think that >>>>>>>>> an MCC can >>>>>>> still >>>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts >>>>>>>>> whatever source >>>>>>> is >>>>>>>>> switched into the media stream. >>>>>>>>> If you want a pure switched MCC just set maxCaptureEncodings to >>>>>>>>> 1 >>>>>>> against the >>>>>>>>> MCC. >>>>>>>>> If you want a simultcast MCC just set maxCaptureEncodings to >>>>>>>>>> =2 >>>>>>> against the >>>>>>>>> MCC. >>>>>>>> [Roni Even] The thing is that I am not sure how to advertise >>>>>>>> this >>>>> example. >>>>>>>> The advertisement has two scene views: >>>>>>>> 1. Scene view with VC0, VC1, VC2 each with two simulcast >>>>>>>> streams >>> 2. >>>>>>>> Scene view MCC3 as represented bellow >>>>>>>> >>>>>>>> The different MCs will be: >>>>>>>> >>>>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, >>>>>>>> MaxCaptures=2 >>>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture >>>>>>> Encodings"? >>>>>>> Don't confuse this with the MCC attribute MaxCaptures which means >>>>> "Max >>>>>>> number of Captures within a MCC". >>>>>>> >>>>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>>>> view=table, >>>>>>>> MaxCaptures=2 >>>>>>>> >>>>>>>> VC2- (the right camera stream), encoding group=EG0, view=table. >>>>>>>> MaxCaptures=2 >>>>>>>> >>>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=EG0, view=room, >>>>>>> MaxCaptures=2 >>>>>>> >>>>>>> [Duckworth, Mark] It isn't clear if you really mean "max capture >>>>> encodings" >>>>>>> or >>>>>>> "max number of captures within a MCC". Those are two different >>> things. >>>>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. >>>>>>> [Duckworth, Mark] It depends how the consumer configures it. The >>>>>>> provider advertisement says it supports simulcast, so the >>>>>>> consumer can decide to use it or not. >>>>>>> >>>>>>>> What about MCC3? >>>>>>>> Is it multicast from one of the cameras or is it 2 MCs out of >>>>>>>> the three? (I assume it is the first since the view is room) >>>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three >>>>>>> simultaneously only if it is composed, not if it is switched. >>>>>>> The provider can give more information, if it wants to, with the >>>>>>> MCC attribute "max number of captures within a MCC". >>>>>>> >>>>>>>> What if in the above example MaxCaptures=4 can it be for example >>>>>>>> VC0, >>>>>>> VC1 >>>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and one >>>>>>>> of them is >>>>>>> simulcast? >>>>>>> >>>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" >>>>>>> capture. >>>>>>> It sounds like you are talking about a switched case, not a >>>>>>> composed case, so let's say MCC3 has the attribute "max number of >>>>>>> captures within >>>>> a >>>>>> MCC" = 1. >>>>>>> Now let's also suppose MCC3 has "max capture encodings" = 2. >>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, for the >>>>>>> two encodings. Then the provider decides when to switch among >>>>>>> VC0, VC1, and VC2, and whichever one the provider is sending for >>>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast at >>>>>>> those two resolutions. >>>>>>> >>>>>>>> What I am trying to say is that using implied simulcast require >>>>>>>> text explaining when a consumer can understand that the >>>>>>>> advertisement is simulcast and not something else. >>>>>>>> The other approach may be to have an attribute for an MC and MCC >>>>>>>> that >>>>>>> will >>>>>>>> explicitly say that this is a simulcast offer. >>>>>>> [Duckworth, Mark] I think the advertisement is clear to the >>>>>>> consumer without any additional text or attributes added to the >>>>>>> framework. It is already explicit, with the attribute "max >>>>>>> capture encodings". If it is >1, then the advertisement is >>>>>>> offering >>>> simulcast. >>>>>>>> BTW: I think that the implied solution works when the individual >>>>>>>> encodings are the same (spatial or different codces) what if we >>>>>>>> the provider can send >>>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be four >>>>>>>> different encodings but not all combinations allowed. How to >>>>>>>> represent it in an advertisement? Is it : >>>>>>> [Duckworth, Mark] I can consider this case after we get the first >>>>>>> case above cleared up. >>>>>>> >>>>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, >>>>>>>> MaxCaptures=2 >>>>>>>> >>>>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>>>> view=table, >>>>>>>> MaxCaptures=2 >>>>>>>> >>>>>>>> VC2- (the right camera stream), encoding group=EG0, view=table. >>>>>>>> MaxCaptures=2 >>>>>>>> >>>>>>>> VC3- (the left camera stream), encoding group=EG1, view=table, >>>>>>>> MaxCaptures=2 >>>>>>>> >>>>>>>> VC4- (the center camera stream), encoding group=EG1, >>>>>>>> view=table, >>>>>>>> MaxCaptures=2 >>>>>>>> >>>>>>>> VC5- (the right camera stream), encoding group=EG1, view=table. >>>>>>>> MaxCaptures=2 >>>>>>>> >>>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two >>>>>>>> scene views >>>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? >>>>>>>> >>>>>>> ... snip ... >>>>>>> >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Nov 20 22:18: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 249001AD0CC for ; Thu, 20 Nov 2014 22:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tfZlqMEIIC8G for ; Thu, 20 Nov 2014 22:18:35 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D111AD0C7 for ; Thu, 20 Nov 2014 22:18:34 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-7a-546ed9387d7c Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D9.B7.04076.839DE645; Fri, 21 Nov 2014 07:18:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 07:18:32 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Draft new version: clue-datachannel-03 Thread-Index: AdAFJ4usxb+A7W9hQS2AY+H45QMkBgAANpbQAAJtpQAAB7XQsA== Date: Fri, 21 Nov 2014 06:18:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52E530@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D52E027@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52E066@ESESSMB209.ericsson.se> <546EB026.4090207@nteczone.com> In-Reply-To: <546EB026.4090207@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja7lzbwQgwUrWCy+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJXxd35EwV/xirlzJ7A2MM4R7mLk5JAQMJG4 37WHBcIWk7hwbz1bFyMXh5DAEUaJ04/XMEE4SxglXi3dy9jFyMHBJmAh0f1PG6RBRCBcomPb FUYQW1jASqJx1TlGiLi1xI/uyVC2k8SCxuVgC1gEVCXerj/MCmLzCvhK/F90DmrZZkaJnZOe gDVwCuhI/P33HKyBEeii76dAjuDkYBYQl7j1ZD4TxKUCEkv2nGeGsEUlXj7+xwphK0ms2H6J EaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhFi1OLi3PT jYz0Uosyk4uL8/P08lJLNjEC4+Tglt9WOxgPPnc8xCjAwajEw7thVV6IEGtiWXFl7iFGaQ4W JXHehefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgZK95+Y1F4p2OtLtumk3y9J3dJY/f X5u9JvJKvmLBGUb+aw4M3989zpa8c0J8UU/kO5mJ++e6TrjL6jXppLT2pIU/p8cqiZw9+VPh us/bnQ4Z0T3/9652fH72HX9t/9+Ewp0TUx58zmltODz1XNfMBHl9hXv7J56w1n1gKPvMwlhq ibrkKfNlV5VYijMSDbWYi4oTASaLcMZ0AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/1TstrBXrh6EDKLlobq0CAlVSZaI Subject: Re: [clue] Draft new version: clue-datachannel-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 06:18:37 -0000 Hi, >1. You need to update table 3.... :-) I'm glad you told me :) >2. Cl.3.2.1 - It's draft-ietf-clue-signaling-04 that describes the SDP O/A procedures n= ot the protocol draft. I'll fix that. In addition, in the same section, I'll change "media channels" to "media st= reams". >3. Cl.3.2.4 - WebRTC datachannel indicates that the subprotocol is optiona= l. However for CLUE I assume that this is a=20 >mandatory parameter with value equal to "CLUE"? The table suggests it's op= tional. I am using the names used in the syntax of draft-ejzak, and according to se= ction 5.1.1.3 the parameter is mandatory.=20 I guess the "opt" wording in the syntax is confusing, and it would probably= be better to NOT use the syntax names to begin with. >4. Cl.3.2.4 - What's your intention on the use of label? The table suggest= s that its optional but if included must have the value "CLUE Data Channel" According to section 5.1.1.2 it is mandatory. My understanding is that it i= s needed for the W3C API, to identity the data channel, and data channel ev= ents. >5. Cl.3.3.1 - Can we now delete the note in this section also? In my opinion, yes. >6. Cl.3.3.2 - Should we move the note to the IANA considerations section g= iven that it applies to both clauses 3.2.4 and 3.3.2? Yes. >7. Cl.3.2.4 - I'm not sure the SCTP stream ID always need to be provided e= specially if there's only one CLUE=20 >subprotocol instance for each DTLS/SCTP association. This is more of a com= ment on the ejzak draft. True. Regards, Christer On 21/11/2014 12:14 PM, Christer Holmberg wrote: > Hi, > > In addition, I also removed the text about SCTP interleaving, based on th= e assumption that there is nothing CLUE specific regarding that. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer=20 > Holmberg > Sent: 21 November 2014 03:10 > To: clue@ietf.org > Subject: [clue] Draft new version: clue-datachannel-03 > > Hi, > > I've submitted a new version (-03) of the CLUE data channel draft. > > The main technical change from the previous version is that I have now ad= ded details for usage of Keith Richard's draft. > > NOTE that my assumption is that we will still use DCEP to actually open t= he CLUE data channel, once it has been negotiated the draft. > > I have also removed the SDP O/A procedures, and added a reference to the = CLUE protocol draft for that. > > And, yes, I know I have to fix table 3 :) > > 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 nobody Thu Nov 20 22:21: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 B89F81AD0CC for ; Thu, 20 Nov 2014 22:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUu_Jv5Om2a0 for ; Thu, 20 Nov 2014 22:21:09 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077C51AD0CE for ; Thu, 20 Nov 2014 22:21:08 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-48-546ed9d247eb Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 08.08.04076.2D9DE645; Fri, 21 Nov 2014 07:21:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 07:21:06 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczEwHhC5T4AsgMzZABSFF3zwGQAdjcAfUTyVUCDwh2XQGoOPavm3HaKtCAAAU/QP//9C2AgAApHQCAAEHegIAMknWAgAA7leD///DYAIAAFS7A Date: Fri, 21 Nov 2014 06:21:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52E555@ESESSMB209.ericsson.se> References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> <00eb01cffeb8$41829c30$c487d490$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> <013a01cffed0$926aa8f0$b73ffad0$@gmail.com> <546424B1.7010408@alum.mit.edu> <546EB087.1060204@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D52E4D5@ESESSMB209.ericsson.se> <546ED5CC.5020807@nteczone.com> In-Reply-To: <546ED5CC.5020807@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvje7lm3khBjN/C1h8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugStj+qw5TAUryiomrN/H2sDYlNjFyMkhIWAi 8XPWGxYIW0ziwr31bF2MXBxCAkcYJb7P2s4I4SxhlGj718TaxcjBwSZgIdH9TxukQUQgXKJj 2xVGEFtYwFjiy/yLrBBxE4nnP5axgvSKCOxjlFi/dAtYgkVAVeLYoY9g23gFfCXaNv5ihVjQ wiFx49pvsCJOAR2JF3MeMIPYjEAnfT+1hgnEZhYQl7j1ZD4TxKkCEkv2nGeGsEUlXj7+xwph K0ms2H6JEaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhF i1OLi3PTjYz0Uosyk4uL8/P08lJLNjECY+Xglt9WOxgPPnc8xCjAwajEw7thVV6IEGtiWXFl 7iFGaQ4WJXHehefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgbDv0a3XY0ZqEs92Lppoa njgaHPT/YoYhY5fZWd1yh+dPawUz79huPBaU1bm1YYreLVmFCzPly+RvPxNzfH4hK5Bl/s6j d9/M2FY+507qc/V2s/49Fpw784K9VOfPjDw1/2bG7cDiO3tfXtjxtmhJrsTkhb07Hs9vafz/ /4yr4uuAGSnbzgcqXVViKc5INNRiLipOBADeKBfTdgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VdlkRLPlRbIceiEEVTRZTosujjk Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 06:21:12 -0000 Hi, >Yes, I thought the assumption was nothing in CLUE prevented the use of the= generic >simulcast draft. It was more a timing issue, as we didn't want to delay the CLUE work when i= t was unsure whether the simulcast was going to be adopted. >I'm wondering why the adoption of that meant part of CLUE was removed (at = least >as I understand from the notes)? As far as I remember, yes. Nobody could come up with a reason why it should= be kept. Regards, Christer On 21/11/2014 4:58 PM, Christer Holmberg wrote: > Hi, > > The generic simulcast draft was adopted in MMUSIC, and the idea is that i= t will be used also if someone wants to provide simulcast for CLUE. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian=20 > Groves > Sent: 21 November 2014 05:25 > To: clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > What's the status of the simultcast issue after the meeting? I saw some m= eeting notes to suggest that it would be removed from CLUE. I certainly did= n't expect that from the discussions on the list. > > Regards, Christian > > On 13/11/2014 2:25 PM, Paul Kyzivat wrote: >> If an sdp-based mechanism is published that allows simulcast in a=20 >> single m-line, then clue gets to take advantage of that *for free*. I=20 >> don't know that we need to say anything about that. >> >> The question we have to ask is: do we want to remove the=20 >> clue-specific mechanism that is already present in our data model? >> >> To that I will add the corollary question: is there any cost to=20 >> having that option in there? >> >> I can't see any cost. >> - Advertisers don't have to use it in their advertisements. >> - Consumers can't use it in Configure if it wasn't in the=20 >> advertisement >> - Consumers don't have to use it if it is in the advertisement. >> >> So I see no harm in leaving it in. And some potential benefit to=20 >> having it there. >> >> Thanks, >> Paul >> >> On 11/12/14 1:29 PM, Roni Even wrote: >>> Hi, >>> This is what started the discussion. If we do not have SDP based=20 >>> simulcast based on unified plan, the only semantics is an encoding=20 >>> per m-line. We started the discussion based on this assumption that=20 >>> we can do simulcast in CLUE using an encoding per m-line and can=20 >>> bundle them Roni >>> >>>> -----Original Message----- >>>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] >>>> Sent: 12 November, 2014 11:03 PM >>>> To: Duckworth, Mark; Roni Even >>>> Cc: clue@ietf.org >>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> Yes, I'd have thought ideally multiple simulcast qualities, repair=20 >>>> streams >>> etc >>>> would be defined under a single m-line and hence be a single=20 >>>> encoding from CLUE's perspective. That matches the unified plan and=20 >>>> the proposal in >>> draft- >>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it=20 >>>> would mean that negotiating simulcast qualities, repair flows etc=20 >>>> would be purely an >>> SDP >>>> issue and wouldn't impact CLUE. >>>> >>>> Rob >>>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth,=20 >>>> Mark >>>> Sent: 12 November 2014 10:54 >>>> To: Roni Even >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> Hi, >>>> >>>> I don't understand why simulcast would need separate encoding groups. >>>> >>>> Whether an MC maps to two m-lines or one m-line with a=3Dsimulcast is= =20 >>>> up to the consumer, and specified in the configure message sent=20 >>>> from consumer to provider. The mapping is done via the encoding ID=20 >>>> labels which link media captures to m-lines. At least that is how=20 >>>> I see it. >>>> >>>> Would you say retransmission streams are a separate issue from=20 >>>> simulcast? >>> Or >>>> are they similar enough that it is really the same issue? Do SVC=20 >>>> layered >>> codec >>>> streams also fall into this category? >>>> >>>> Sounds like we do need some more discussion about this. My first=20 >>>> thought >>> is >>>> we should cover this in the signaling document. >>>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>> Sent: Wednesday, November 12, 2014 10:36 AM >>>>> To: Duckworth, Mark >>>>> Cc: clue@ietf.org >>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>> >>>>> Hi, >>>>> This will work when we have a single encoding per m-line in the=20 >>>>> SDP and I think it requires that each simulcast set will be in=20 >>>>> separate encoding group . Still it will provide less functionality=20 >>>>> than the one proposed in the simulcast proposal that will be=20 >>>>> discussed in MMUSIC If simulcast in SDP will progress using the=20 >>>>> unified plan where we have all encodings in one m-line we will=20 >>>>> need to specify that if an MC have max capture encoding >1 will it=20 >>>>> mean that it will map to two m-lines or will it use a configuration f= rom an SDP description a=3Dsimulcast. >>>>> >>>>> We will need to see how it works with retransmission if we specify=20 >>>>> a retransmission RTP stream as an individual encoding. >>>>> >>>>> Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] >>>>>> Sent: 06 November, 2014 9:45 PM >>>>>> To: Roni Even >>>>>> Cc: clue@ietf.org >>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>> Hi Roni, >>>>>> Do you still have questions about the way simulcast is handled in=20 >>>>>> the framework, regarding the attribute "Max capture encodings"=20 >>>>>> and >>>>> configuring >>>>>> multiple encodings per capture? I was hoping we could resolve it=20 >>>>>> on the >>>>> list, or >>>>>> do you think we need to talk about it in Honolulu? >>>>>> Regards, >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of=20 >>>>>>> Duckworth, >>>>> Mark >>>>>>> Sent: Monday, November 03, 2014 10:52 PM >>>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org >>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni=20 >>>>>>>> Even >>>>>>>> Sent: Monday, November 03, 2014 5:52 PM >>>>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of=20 >>>>>>>>> Christian Groves >>>>>>>>> Sent: 28 October, 2014 2:56 AM >>>>>>>>> To: clue@ietf.org >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>> >>>>>>>>> Hello Roni, >>>>>>>>> >>>>>>>>> As I mentioned in my original reply I think the RTP based=20 >>>>>>>>> simulcast >>>>>>> method >>>>>>>> is >>>>>>>>> probably the cleanest approach. There would be nothing=20 >>>>>>>>> stopping a CLUE endpoint implementing it when it becomes=20 >>>>>>>>> available (like many other RTP features). Using CLUE for=20 >>>>>>>>> simulcast I think is possible for most >>>>>>>> scenarios. The >>>>>>>>> more complicated the scenarios the more MCs/encodings an >>>>> endpoint >>>>>>> will >>>>>>>>> need to describe the situation. >>>>>>>>> >>>>>>>>> Please see my response below. >>>>>>>>> >>>>>>>>> Regards, Christian >>>>>>>>> >>>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: >>>>>>>>>> Hi Paul, >>>>>>>>>> >>>>>>>>>> If we want to be able to differentiate between simulcast and=20 >>>>>>>>>> switched capture, for example if we have a three camera=20 >>>>>>>>>> system that can send three MCs each with two encodings >>>>>>>>>> (simulcast) and a switched capture (loudest speaker or two=20 >>>>>>>>>> loudest speakers out of three) using the same simulcast=20 >>>>>>>>>> option for the each MC currently sent. In this case we can=20 >>>>>>>>>> have an MC with two encodings and an MCC with the three MCs. >>>>>>>>>> This >>>>>>> will >>>>>>>>>> require us to clarify that having multiple individual=20 >>>>>>>>>> encodings in MC is simulcast and not switched and in MCC it=20 >>>>>>>>>> is switched and not >>>>>>> simulcast. >>>>>>>>> [CNG] I don't understand exactly what the issue is here? Could=20 >>>>>>>>> you use >>>>>>> some >>>>>>>>> pseudo syntax to explain what you're wanting to advertise? You=20 >>>>>>>>> say in >>>>>>> the first >>>>>>>>> sentence the switched capture uses simulcast but then in the=20 >>>>>>>>> last >>>>>>> sentence you >>>>>>>>> say the MCC is switched and not simulcast. I would think that=20 >>>>>>>>> an MCC can >>>>>>> still >>>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts=20 >>>>>>>>> whatever source >>>>>>> is >>>>>>>>> switched into the media stream. >>>>>>>>> If you want a pure switched MCC just set maxCaptureEncodings=20 >>>>>>>>> to >>>>>>>>> 1 >>>>>>> against the >>>>>>>>> MCC. >>>>>>>>> If you want a simultcast MCC just set maxCaptureEncodings to >>>>>>>>>> =3D2 >>>>>>> against the >>>>>>>>> MCC. >>>>>>>> [Roni Even] The thing is that I am not sure how to advertise=20 >>>>>>>> this >>>>> example. >>>>>>>> The advertisement has two scene views: >>>>>>>> 1. Scene view with VC0, VC1, VC2 each with two simulcast=20 >>>>>>>> streams >>> 2. >>>>>>>> Scene view MCC3 as represented bellow >>>>>>>> >>>>>>>> The different MCs will be: >>>>>>>> >>>>>>>> VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, >>>>>>>> MaxCaptures=3D2 >>>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max Capture=20 >>>>>>> Encodings"? >>>>>>> Don't confuse this with the MCC attribute MaxCaptures which=20 >>>>>>> means >>>>> "Max >>>>>>> number of Captures within a MCC". >>>>>>> >>>>>>>> VC1- (the center camera stream), encoding group=3DEG0,=20 >>>>>>>> view=3Dtable, >>>>>>>> MaxCaptures=3D2 >>>>>>>> >>>>>>>> VC2- (the right camera stream), encoding group=3DEG0, view=3Dta= ble. >>>>>>>> MaxCaptures=3D2 >>>>>>>> >>>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=3DEG0, view=3Droom, >>>>>>> MaxCaptures=3D2 >>>>>>> >>>>>>> [Duckworth, Mark] It isn't clear if you really mean "max capture >>>>> encodings" >>>>>>> or >>>>>>> "max number of captures within a MCC". Those are two different >>> things. >>>>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. >>>>>>> [Duckworth, Mark] It depends how the consumer configures it. =20 >>>>>>> The provider advertisement says it supports simulcast, so the=20 >>>>>>> consumer can decide to use it or not. >>>>>>> >>>>>>>> What about MCC3? >>>>>>>> Is it multicast from one of the cameras or is it 2 MCs out of=20 >>>>>>>> the three? (I assume it is the first since the view is room) >>>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three=20 >>>>>>> simultaneously only if it is composed, not if it is switched. >>>>>>> The provider can give more information, if it wants to, with the=20 >>>>>>> MCC attribute "max number of captures within a MCC". >>>>>>> >>>>>>>> What if in the above example MaxCaptures=3D4 can it be for=20 >>>>>>>> example VC0, >>>>>>> VC1 >>>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and one=20 >>>>>>>> of them is >>>>>>> simulcast? >>>>>>> >>>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single "conceptual" >>>>>>> capture. >>>>>>> It sounds like you are talking about a switched case, not a=20 >>>>>>> composed case, so let's say MCC3 has the attribute "max number=20 >>>>>>> of captures within >>>>> a >>>>>> MCC" =3D 1. >>>>>>> Now let's also suppose MCC3 has "max capture encodings" =3D 2. >>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, for=20 >>>>>>> the two encodings. Then the provider decides when to switch=20 >>>>>>> among VC0, VC1, and VC2, and whichever one the provider is=20 >>>>>>> sending for >>>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast at=20 >>>>>>> those two resolutions. >>>>>>> >>>>>>>> What I am trying to say is that using implied simulcast require=20 >>>>>>>> text explaining when a consumer can understand that the=20 >>>>>>>> advertisement is simulcast and not something else. >>>>>>>> The other approach may be to have an attribute for an MC and=20 >>>>>>>> MCC that >>>>>>> will >>>>>>>> explicitly say that this is a simulcast offer. >>>>>>> [Duckworth, Mark] I think the advertisement is clear to the=20 >>>>>>> consumer without any additional text or attributes added to the=20 >>>>>>> framework. It is already explicit, with the attribute "max=20 >>>>>>> capture encodings". If it is >1, then the advertisement is=20 >>>>>>> offering >>>> simulcast. >>>>>>>> BTW: I think that the implied solution works when the=20 >>>>>>>> individual encodings are the same (spatial or different codces)=20 >>>>>>>> what if we the provider can send >>>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be=20 >>>>>>>> four different encodings but not all combinations allowed. How=20 >>>>>>>> to represent it in an advertisement? Is it : >>>>>>> [Duckworth, Mark] I can consider this case after we get the=20 >>>>>>> first case above cleared up. >>>>>>> >>>>>>>> VC0- (the left camera stream), encoding group=3DEG0, view=3Dtable, >>>>>>>> MaxCaptures=3D2 >>>>>>>> >>>>>>>> VC1- (the center camera stream), encoding group=3DEG0,=20 >>>>>>>> view=3Dtable, >>>>>>>> MaxCaptures=3D2 >>>>>>>> >>>>>>>> VC2- (the right camera stream), encoding group=3DEG0, view=3Dta= ble. >>>>>>>> MaxCaptures=3D2 >>>>>>>> >>>>>>>> VC3- (the left camera stream), encoding group=3DEG1, view=3Dtable, >>>>>>>> MaxCaptures=3D2 >>>>>>>> >>>>>>>> VC4- (the center camera stream), encoding group=3DEG1,=20 >>>>>>>> view=3Dtable, >>>>>>>> MaxCaptures=3D2 >>>>>>>> >>>>>>>> VC5- (the right camera stream), encoding group=3DEG1, view=3Dta= ble. >>>>>>>> MaxCaptures=3D2 >>>>>>>> >>>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two=20 >>>>>>>> scene views >>>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? >>>>>>>> >>>>>>> ... snip ... >>>>>>> >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Fri Nov 21 06:56:45 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034C61AD4C1 for ; Fri, 21 Nov 2014 06:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.052 X-Spam-Level: ** X-Spam-Status: No, score=2.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 AFys56qBuMPV for ; Fri, 21 Nov 2014 06:56:39 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7551E1AD491 for ; Fri, 21 Nov 2014 06:56:39 -0800 (PST) Received: from [216.82.241.100] by server-4.bemta-8.messagelabs.com id 3C/11-27904-6A25F645; Fri, 21 Nov 2014 14:56:38 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-15.tower-220.messagelabs.com!1416581794!16470627!4 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11631 invoked from network); 21 Nov 2014 14:56:37 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-15.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 21 Nov 2014 14:56:37 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 21 Nov 2014 06:52:06 -0800 From: "Duckworth, Mark" To: Christer Holmberg , Christian Groves , "clue@ietf.org" Date: Fri, 21 Nov 2014 06:52:03 -0800 Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczEwHhC5T4AsgMzZABSFF3zwGQAdjcAfUTyVUCDwh2XQGoOPavm3HaKtCAAAU/QP//9C2AgAApHQCAAEHegIAMknWAgAA7leD///DYAIAAFS7AgACN3zA= Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFDEDC@CRPMBOXPRD08.polycom.com> References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> <00eb01cffeb8$41829c30$c487d490$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> <013a01cffed0$926aa8f0$b73ffad0$@gmail.com> <546424B1.7010408@alum.mit.edu> <546EB087.1060204@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D52E4D5@ESESSMB209.ericsson.se> <546ED5CC.5020807@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D52E555@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52E555@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/7beTV7-GpgDF6eDPzMjYVO6XEyQ Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 14:56:43 -0000 Yes, the people in the room at IETF 91 were clearly in favor of removing th= e CLUE simulcast feature enabled by "Max Capture Encodings" > 1. A reason = to remove it is to avoid interop issue which could arise by having two diff= erent ways to do simulcast that don't interop with each other. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Friday, November 21, 2014 1:21 AM > To: Christian Groves; clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > Hi, > > >Yes, I thought the assumption was nothing in CLUE prevented the use of > the generic >simulcast draft. > > It was more a timing issue, as we didn't want to delay the CLUE work when= it > was unsure whether the simulcast was going to be adopted. > > >I'm wondering why the adoption of that meant part of CLUE was removed > (at least >as I understand from the notes)? > > As far as I remember, yes. Nobody could come up with a reason why it > should be kept. > > Regards, > > Christer > > > On 21/11/2014 4:58 PM, Christer Holmberg wrote: > > Hi, > > > > The generic simulcast draft was adopted in MMUSIC, and the idea is that= it > will be used also if someone wants to provide simulcast for CLUE. > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > > Groves > > Sent: 21 November 2014 05:25 > > To: clue@ietf.org > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > What's the status of the simultcast issue after the meeting? I saw some > meeting notes to suggest that it would be removed from CLUE. I certainly > didn't expect that from the discussions on the list. > > > > Regards, Christian > > > > On 13/11/2014 2:25 PM, Paul Kyzivat wrote: > >> If an sdp-based mechanism is published that allows simulcast in a > >> single m-line, then clue gets to take advantage of that *for free*. I > >> don't know that we need to say anything about that. > >> > >> The question we have to ask is: do we want to remove the > >> clue-specific mechanism that is already present in our data model? > >> > >> To that I will add the corollary question: is there any cost to > >> having that option in there? > >> > >> I can't see any cost. > >> - Advertisers don't have to use it in their advertisements. > >> - Consumers can't use it in Configure if it wasn't in the > >> advertisement > >> - Consumers don't have to use it if it is in the advertisement. > >> > >> So I see no harm in leaving it in. And some potential benefit to > >> having it there. > >> > >> Thanks, > >> Paul > >> > >> On 11/12/14 1:29 PM, Roni Even wrote: > >>> Hi, > >>> This is what started the discussion. If we do not have SDP based > >>> simulcast based on unified plan, the only semantics is an encoding > >>> per m-line. We started the discussion based on this assumption that > >>> we can do simulcast in CLUE using an encoding per m-line and can > >>> bundle them Roni > >>> > >>>> -----Original Message----- > >>>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] > >>>> Sent: 12 November, 2014 11:03 PM > >>>> To: Duckworth, Mark; Roni Even > >>>> Cc: clue@ietf.org > >>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > >>>> > >>>> Yes, I'd have thought ideally multiple simulcast qualities, repair > >>>> streams > >>> etc > >>>> would be defined under a single m-line and hence be a single > >>>> encoding from CLUE's perspective. That matches the unified plan and > >>>> the proposal in > >>> draft- > >>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it > >>>> would mean that negotiating simulcast qualities, repair flows etc > >>>> would be purely an > >>> SDP > >>>> issue and wouldn't impact CLUE. > >>>> > >>>> Rob > >>>> > >>>> -----Original Message----- > >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, > >>>> Mark > >>>> Sent: 12 November 2014 10:54 > >>>> To: Roni Even > >>>> Cc: clue@ietf.org > >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>> > >>>> Hi, > >>>> > >>>> I don't understand why simulcast would need separate encoding > groups. > >>>> > >>>> Whether an MC maps to two m-lines or one m-line with a=3Dsimulcast i= s > >>>> up to the consumer, and specified in the configure message sent > >>>> from consumer to provider. The mapping is done via the encoding ID > >>>> labels which link media captures to m-lines. At least that is how > >>>> I see it. > >>>> > >>>> Would you say retransmission streams are a separate issue from > >>>> simulcast? > >>> Or > >>>> are they similar enough that it is really the same issue? Do SVC > >>>> layered > >>> codec > >>>> streams also fall into this category? > >>>> > >>>> Sounds like we do need some more discussion about this. My first > >>>> thought > >>> is > >>>> we should cover this in the signaling document. > >>>> > >>>> Mark > >>>> > >>>>> -----Original Message----- > >>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] > >>>>> Sent: Wednesday, November 12, 2014 10:36 AM > >>>>> To: Duckworth, Mark > >>>>> Cc: clue@ietf.org > >>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > >>>>> > >>>>> Hi, > >>>>> This will work when we have a single encoding per m-line in the > >>>>> SDP and I think it requires that each simulcast set will be in > >>>>> separate encoding group . Still it will provide less functionality > >>>>> than the one proposed in the simulcast proposal that will be > >>>>> discussed in MMUSIC If simulcast in SDP will progress using the > >>>>> unified plan where we have all encodings in one m-line we will > >>>>> need to specify that if an MC have max capture encoding >1 will it > >>>>> mean that it will map to two m-lines or will it use a configuration= from > an SDP description a=3Dsimulcast. > >>>>> > >>>>> We will need to see how it works with retransmission if we specify > >>>>> a retransmission RTP stream as an individual encoding. > >>>>> > >>>>> Roni > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > >>>>>> Sent: 06 November, 2014 9:45 PM > >>>>>> To: Roni Even > >>>>>> Cc: clue@ietf.org > >>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > >>>>>> > >>>>>> Hi Roni, > >>>>>> Do you still have questions about the way simulcast is handled in > >>>>>> the framework, regarding the attribute "Max capture encodings" > >>>>>> and > >>>>> configuring > >>>>>> multiple encodings per capture? I was hoping we could resolve it > >>>>>> on the > >>>>> list, or > >>>>>> do you think we need to talk about it in Honolulu? > >>>>>> Regards, > >>>>>> Mark > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > >>>>>>> Duckworth, > >>>>> Mark > >>>>>>> Sent: Monday, November 03, 2014 10:52 PM > >>>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org > >>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni > >>>>>>>> Even > >>>>>>>> Sent: Monday, November 03, 2014 5:52 PM > >>>>>>>> To: 'Christian Groves'; clue@ietf.org > >>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > >>>>>>>>> Christian Groves > >>>>>>>>> Sent: 28 October, 2014 2:56 AM > >>>>>>>>> To: clue@ietf.org > >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>>>> > >>>>>>>>> Hello Roni, > >>>>>>>>> > >>>>>>>>> As I mentioned in my original reply I think the RTP based > >>>>>>>>> simulcast > >>>>>>> method > >>>>>>>> is > >>>>>>>>> probably the cleanest approach. There would be nothing > >>>>>>>>> stopping a CLUE endpoint implementing it when it becomes > >>>>>>>>> available (like many other RTP features). Using CLUE for > >>>>>>>>> simulcast I think is possible for most > >>>>>>>> scenarios. The > >>>>>>>>> more complicated the scenarios the more MCs/encodings an > >>>>> endpoint > >>>>>>> will > >>>>>>>>> need to describe the situation. > >>>>>>>>> > >>>>>>>>> Please see my response below. > >>>>>>>>> > >>>>>>>>> Regards, Christian > >>>>>>>>> > >>>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: > >>>>>>>>>> Hi Paul, > >>>>>>>>>> > >>>>>>>>>> If we want to be able to differentiate between simulcast and > >>>>>>>>>> switched capture, for example if we have a three camera > >>>>>>>>>> system that can send three MCs each with two encodings > >>>>>>>>>> (simulcast) and a switched capture (loudest speaker or two > >>>>>>>>>> loudest speakers out of three) using the same simulcast > >>>>>>>>>> option for the each MC currently sent. In this case we can > >>>>>>>>>> have an MC with two encodings and an MCC with the three > MCs. > >>>>>>>>>> This > >>>>>>> will > >>>>>>>>>> require us to clarify that having multiple individual > >>>>>>>>>> encodings in MC is simulcast and not switched and in MCC it > >>>>>>>>>> is switched and not > >>>>>>> simulcast. > >>>>>>>>> [CNG] I don't understand exactly what the issue is here? Could > >>>>>>>>> you use > >>>>>>> some > >>>>>>>>> pseudo syntax to explain what you're wanting to advertise? You > >>>>>>>>> say in > >>>>>>> the first > >>>>>>>>> sentence the switched capture uses simulcast but then in the > >>>>>>>>> last > >>>>>>> sentence you > >>>>>>>>> say the MCC is switched and not simulcast. I would think that > >>>>>>>>> an MCC can > >>>>>>> still > >>>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts > >>>>>>>>> whatever source > >>>>>>> is > >>>>>>>>> switched into the media stream. > >>>>>>>>> If you want a pure switched MCC just set maxCaptureEncodings > >>>>>>>>> to > >>>>>>>>> 1 > >>>>>>> against the > >>>>>>>>> MCC. > >>>>>>>>> If you want a simultcast MCC just set maxCaptureEncodings to > >>>>>>>>>> =3D2 > >>>>>>> against the > >>>>>>>>> MCC. > >>>>>>>> [Roni Even] The thing is that I am not sure how to advertise > >>>>>>>> this > >>>>> example. > >>>>>>>> The advertisement has two scene views: > >>>>>>>> 1. Scene view with VC0, VC1, VC2 each with two simulcast > >>>>>>>> streams > >>> 2. > >>>>>>>> Scene view MCC3 as represented bellow > >>>>>>>> > >>>>>>>> The different MCs will be: > >>>>>>>> > >>>>>>>> VC0- (the left camera stream), encoding group=3DEG0, view=3Dtabl= e, > >>>>>>>> MaxCaptures=3D2 > >>>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max > Capture > >>>>>>> Encodings"? > >>>>>>> Don't confuse this with the MCC attribute MaxCaptures which > >>>>>>> means > >>>>> "Max > >>>>>>> number of Captures within a MCC". > >>>>>>> > >>>>>>>> VC1- (the center camera stream), encoding group=3DEG0, > >>>>>>>> view=3Dtable, > >>>>>>>> MaxCaptures=3D2 > >>>>>>>> > >>>>>>>> VC2- (the right camera stream), encoding group=3DEG0, > view=3Dtable. > >>>>>>>> MaxCaptures=3D2 > >>>>>>>> > >>>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=3DEG0, view=3Droom, > >>>>>>> MaxCaptures=3D2 > >>>>>>> > >>>>>>> [Duckworth, Mark] It isn't clear if you really mean "max capture > >>>>> encodings" > >>>>>>> or > >>>>>>> "max number of captures within a MCC". Those are two different > >>> things. > >>>>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. > >>>>>>> [Duckworth, Mark] It depends how the consumer configures it. > >>>>>>> The provider advertisement says it supports simulcast, so the > >>>>>>> consumer can decide to use it or not. > >>>>>>> > >>>>>>>> What about MCC3? > >>>>>>>> Is it multicast from one of the cameras or is it 2 MCs out of > >>>>>>>> the three? (I assume it is the first since the view is room) > >>>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three > >>>>>>> simultaneously only if it is composed, not if it is switched. > >>>>>>> The provider can give more information, if it wants to, with the > >>>>>>> MCC attribute "max number of captures within a MCC". > >>>>>>> > >>>>>>>> What if in the above example MaxCaptures=3D4 can it be for > >>>>>>>> example VC0, > >>>>>>> VC1 > >>>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and one > >>>>>>>> of them is > >>>>>>> simulcast? > >>>>>>> > >>>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single > "conceptual" > >>>>>>> capture. > >>>>>>> It sounds like you are talking about a switched case, not a > >>>>>>> composed case, so let's say MCC3 has the attribute "max number > >>>>>>> of captures within > >>>>> a > >>>>>> MCC" =3D 1. > >>>>>>> Now let's also suppose MCC3 has "max capture encodings" =3D 2. > >>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, for > >>>>>>> the two encodings. Then the provider decides when to switch > >>>>>>> among VC0, VC1, and VC2, and whichever one the provider is > >>>>>>> sending for > >>>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast at > >>>>>>> those two resolutions. > >>>>>>> > >>>>>>>> What I am trying to say is that using implied simulcast require > >>>>>>>> text explaining when a consumer can understand that the > >>>>>>>> advertisement is simulcast and not something else. > >>>>>>>> The other approach may be to have an attribute for an MC and > >>>>>>>> MCC that > >>>>>>> will > >>>>>>>> explicitly say that this is a simulcast offer. > >>>>>>> [Duckworth, Mark] I think the advertisement is clear to the > >>>>>>> consumer without any additional text or attributes added to the > >>>>>>> framework. It is already explicit, with the attribute "max > >>>>>>> capture encodings". If it is >1, then the advertisement is > >>>>>>> offering > >>>> simulcast. > >>>>>>>> BTW: I think that the implied solution works when the > >>>>>>>> individual encodings are the same (spatial or different codces) > >>>>>>>> what if we the provider can send > >>>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be > >>>>>>>> four different encodings but not all combinations allowed. How > >>>>>>>> to represent it in an advertisement? Is it : > >>>>>>> [Duckworth, Mark] I can consider this case after we get the > >>>>>>> first case above cleared up. > >>>>>>> > >>>>>>>> VC0- (the left camera stream), encoding group=3DEG0, view=3Dtabl= e, > >>>>>>>> MaxCaptures=3D2 > >>>>>>>> > >>>>>>>> VC1- (the center camera stream), encoding group=3DEG0, > >>>>>>>> view=3Dtable, > >>>>>>>> MaxCaptures=3D2 > >>>>>>>> > >>>>>>>> VC2- (the right camera stream), encoding group=3DEG0, > view=3Dtable. > >>>>>>>> MaxCaptures=3D2 > >>>>>>>> > >>>>>>>> VC3- (the left camera stream), encoding group=3DEG1, view=3Dtabl= e, > >>>>>>>> MaxCaptures=3D2 > >>>>>>>> > >>>>>>>> VC4- (the center camera stream), encoding group=3DEG1, > >>>>>>>> view=3Dtable, > >>>>>>>> MaxCaptures=3D2 > >>>>>>>> > >>>>>>>> VC5- (the right camera stream), encoding group=3DEG1, > view=3Dtable. > >>>>>>>> MaxCaptures=3D2 > >>>>>>>> > >>>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two > >>>>>>>> scene views > >>>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? > >>>>>>>> > >>>>>>> ... snip ... > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Nov 21 10:08: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 3F61E1AD706; Fri, 21 Nov 2014 10:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC9IUOe27e_C; Fri, 21 Nov 2014 10:08:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1C31AD6F4; Fri, 21 Nov 2014 10:06:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141121180657.2980.58856.idtracker@ietfa.amsl.com> Date: Fri, 21 Nov 2014 10:06:57 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/IbyDUwXi1J35x0KlCqW0JAuwjfk Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-04.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: Fri, 21 Nov 2014 18:08:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : CLUE Protocol Data Channel Author : Christer Holmberg Filename : draft-ietf-clue-datachannel-04.txt Pages : 12 Date : 2014-11-21 Abstract: This document defines how to use the WebRTC Data Channel mechanism, together with the Data Channel Establishment Protocol (DCEP) and the SDP-based "SCTP over DTLS" data channel negotiation mechanism, in order to establish a data channel, referred to as CLUE Data Channel, for transporting CLUE protocol messages between two CLUE entities. The document defines the SCTP considerations specific to a CLUE Data Channel, the SDP Media Description- and SDP dcmap attribute values, and the DCEP procedures for opening, a CLUE Data Channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating a CLUE data channel, are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-datachannel-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-04 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 nobody Fri Nov 21 10:12: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 154131AD6DD for ; Fri, 21 Nov 2014 10:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9AZqHCgH2KtX for ; Fri, 21 Nov 2014 10:12:16 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1EB1AD8EA for ; Fri, 21 Nov 2014 10:08:16 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-51-546f7f8e05bb Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9A.C8.04081.E8F7F645; Fri, 21 Nov 2014 19:08:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 19:08:13 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft new version: draft-ietf-clue-datachannel-04 Thread-Index: AdAFtfhE2vmbim8BQU6bq4Q+AzFwcw== Date: Fri, 21 Nov 2014 18:08:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52EC18@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D52EC18ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW5ffX6IwfIXWhb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqlFn5kL/opWvJj0hbWB8ZBwFyMnh4SAicS5bT3MELaYxIV7 69m6GLk4hASOMEr8mHiFEcJZwijRPvcvUxcjBwebgIVE9z9tkAYRAWWJo5v72UBsYQEriZtr 7rJAxO0ljrR+YIew9SSW3VnDBGKzCKhK7Dj/G6yGV8BX4vys32A1jECLv5+CqGEWEJe49WQ+ E8RBAhJL9pyHOk5U4uXjf6wQtpJE45InrBD1+RKfD75igpgpKHFy5hOWCYxCs5CMmoWkbBaS Moi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQT IzAmDm75bbCD8eVzx0OMAhyMSjy8G1blhQixJpYVV+YeYpTmYFES5114bl6wkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsY4S8P4BUFmfx6qRu2yLw22mL9WKbd0e/aFNyu12GbnyR5IKdux ZvkNraptX44csRCYIpU8iyHS+0PgAc77/4urvTNaVN7c2n7s+Ql+l43SBwXU10y9Gp7B1Lxt mqHeXx3JouDdQdan101Tz+ExXPyhJlIwavqP9Tst5yUrRZuvXxlfJW2Yk6nEUpyRaKjFXFSc CAD7HThVagIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/_cxtrOK85jCUOa8hhezIZSEo8_Y Subject: [clue] Draft new version: draft-ietf-clue-datachannel-04 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 18:12:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D52EC18ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the comments from Christian, I have submitted yet a new version (-= 04) of the CLUE data channel draft. I've also added text to the IANA considerations. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D52EC18ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the comments from Christian, I have submitt= ed yet a new version (-04) of the CLUE data channel draft.

 

I’ve also added text to the IANA consideration= s.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D52EC18ESESSMB209erics_-- From nobody Fri Nov 21 11:20: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 4434A1A1A36 for ; Fri, 21 Nov 2014 11:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hvEH0JMLbtgz for ; Fri, 21 Nov 2014 11:20:27 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AB11A1A1E for ; Fri, 21 Nov 2014 11:20:24 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-ab-546f9076deef Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FE.EF.04081.6709F645; Fri, 21 Nov 2014 20:20:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Fri, 21 Nov 2014 20:20:21 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: draft-ejzak-mmusic-data-channel-sdpneg and DCEP Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHwAAJH5g Date: Fri, 21 Nov 2014 19:20:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D52ED53ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+JvjW7ZhPwQg8sPRC32n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPbjlxgLNlhUTHt4kamBcYZhFyMnh4SAicTCPxvYIGwxiQv3 1gPZXBxCAkcYJfY+WcUC4SxhlLh47geQw8HBJmAh0f1PG6RBREBZ4ujmfrBmYQEbiU3LX7BD xG0lpj/ZxwJhG0kc2X2SCcRmEVCVeHXgFZjNK+ArcWldIyuILQRkPzozA2wOp4CfxK1vV8F6 GYEO+n5qDVg9s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/VghbSaJxyRNWiPp8ic73i1ggdglK nJz5hGUCo8gsJKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2IULU4tTspN NzLSSy3KTC4uzs/Ty0st2cQIjKGDW34b7GB8+dzxEKMAB6MSD++GVXkhQqyJZcWVuYcYpTlY lMR5F56bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0T/i1XddXa/ec/Nn8CbqVemcXm57 zzVvt8nrtsMaOfqq6666qWbnc1yZ2TLlqop8h9Kzp2ckEkPiHKW5b/dPuL72AdeDeQ/ClT9Y PsixsbC5V15zvfaveLi+wk6OA54pn9+u+3aj+XJw+t+mjK0rn/ZJ/vJXWevAtOHEi/815933 THf17jLnVGIpzkg01GIuKk4EAPwQLsCCAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/TDrg4fyoUhBpRnjcKkPabtReI7E Subject: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 19:20:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D52ED53ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, I sent the following to the MMUSIC list. The CLUE data channel draft currently assumes that DCEP is used to open the= CLUE data channel, once it has been negotiated using draft-ejzak. However, if draft-ejzak forbids usage of DCEP, and/or we don't think it's n= eeded for the CLUE data channel, we can remove it. In my opinion, the advantage of also using DCEP is that the endpoints can c= hoose when to open the data channel - otherwise it is considered open once = the SCTP association has been created. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 21 November 2014 21:17 To: mmusic@ietf.org Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and DCEP Hi, draft-ejzak-mmusic-data-channel-sdpneg currently seems to assume that DCEP = will not be used to open data channels - instead data channels will be cons= idered open once the SDP O/A negotiation has finished and the SCTP associat= ion used to realize the data channel(s) has been created. My question is whether the intention is to forbid usage of DCEP together wi= th draft-ejzak-mmusic-data-channel-sdpneg, or whether it should be optional= ? If optional, there needs to be a way to indicate that application data shal= l not be sent until a channel has been opened using DCEP. In addition, it w= ould be useful to be able to indicate which endpoint is responsible for sen= ding the DCEP_CHANNEL_OPEN message. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D52ED53ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,=

 

I sent the following t= o the MMUSIC list.

 

The CLUE data channel = draft currently assumes that DCEP is used to open the CLUE data channel, on= ce it has been negotiated using draft-ejzak.

 

However, if draft-ejza= k forbids usage of DCEP, and/or we don’t think it’s needed for = the CLUE data channel, we can remove it.

 

In my opinion, the adv= antage of also using DCEP is that the endpoints can choose when to open the= data channel – otherwise it is considered open once the SCTP associa= tion has been created.

 

Regards,

 

Christer

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 21 November 2014 21:17
To: mmusic@ietf.org
Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and DCEP

 

Hi,

 

draft-ejzak-mmusic-data-channel-sdpneg currently see= ms to assume that DCEP will not be used to open data channels – inste= ad data channels will be considered open once the SDP O/A negotiation has f= inished and the SCTP association used to realize the data channel(s) has been created.

 

My question is whether the intention is to forbid us= age of DCEP together with draft-ejzak-mmusic-data-channel-sdpneg, or whethe= r it should be optional?

 

If optional, there needs to be a way to indicate tha= t application data shall not be sent until a channel has been opened using = DCEP. In addition, it would be useful to be able to indicate which endpoint= is responsible for sending the DCEP_CHANNEL_OPEN message.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D52ED53ESESSMB209erics_-- From nobody Sun Nov 23 15:58: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 397F81A1B5E for ; Sun, 23 Nov 2014 15:58:24 -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 Dk9UisipKSWo for ; Sun, 23 Nov 2014 15:58:23 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A1E1A1B5C for ; Sun, 23 Nov 2014 15:58:22 -0800 (PST) Received: from ppp118-209-241-2.lns20.mel8.internode.on.net ([118.209.241.2]:53087 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xsh24-0000qj-Ux; Mon, 24 Nov 2014 10:57:33 +1100 Message-ID: <54727498.5030500@nteczone.com> Date: Mon, 24 Nov 2014 10:58:16 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D52E027@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52E066@ESESSMB209.ericsson.se> <546EB026.4090207@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D52E530@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52E530@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5q1tnAIKiFRDM7fzlZj2uAQB-Rw Subject: Re: [clue] Draft new version: clue-datachannel-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 23:58:24 -0000 Hello Christer, >> 4. Cl.3.2.4 - What's your intention on the use of label? The table suggests that its optional but if included must have the value "CLUE Data Channel" > According to section 5.1.1.2 it is mandatory. My understanding is that it is needed for the W3C API, to identity the data channel, and data channel events. > Should CLUE be mandating a value for label? Its use is for distinguish between RTCdatachannel objects. It seems any value would suffice so long it is different and an endpoint may use different schemes to allocate it. Regards, Christian From nobody Sun Nov 23 16:00: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 744BD1A1B5C for ; Sun, 23 Nov 2014 16:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi2_vzS6UaiJ for ; Sun, 23 Nov 2014 16:00:43 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90771A1B63 for ; Sun, 23 Nov 2014 16:00:41 -0800 (PST) Received: from ppp118-209-241-2.lns20.mel8.internode.on.net ([118.209.241.2]:53183 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xsh4O-0001P7-4u for clue@ietf.org; Mon, 24 Nov 2014 10:59:56 +1100 Message-ID: <54727527.8030105@nteczone.com> Date: Mon, 24 Nov 2014 11:00:39 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52ED53@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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xODHv1V4XVX484u8fBJBLEhR2Dg Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 00:00:45 -0000 Hello Christer, I made a similar comment to the authors. If DCEP is used, it could allocate the SCTP StreamIDs so they may not have to be negotiated via draft-ejzak. Only which protocol and associated parameters. Regards, Christian On 22/11/2014 6:20 AM, Christer Holmberg wrote: > > FYI, > > I sent the following to the MMUSIC list. > > The CLUE data channel draft currently assumes that DCEP is used to > open the CLUE data channel, once it has been negotiated using draft-ejzak. > > However, if draft-ejzak forbids usage of DCEP, and/or we don’t think > it’s needed for the CLUE data channel, we can remove it. > > In my opinion, the advantage of also using DCEP is that the endpoints > can choose when to open the data channel – otherwise it is considered > open once the SCTP association has been created. > > Regards, > > Christer > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 21 November 2014 21:17 > *To:* mmusic@ietf.org > *Subject:* [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and DCEP > > Hi, > > draft-ejzak-mmusic-data-channel-sdpneg currently seems to assume that > DCEP will not be used to open data channels – instead data channels > will be considered open once the SDP O/A negotiation has finished and > the SCTP association used to realize the data channel(s) has been created. > > My question is whether the intention is to forbid usage of DCEP > together with draft-ejzak-mmusic-data-channel-sdpneg, or whether it > should be optional? > > If optional, there needs to be a way to indicate that application data > shall not be sent until a channel has been opened using DCEP. In > addition, it would be useful to be able to indicate which endpoint is > responsible for sending the DCEP_CHANNEL_OPEN message. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Sun Nov 23 16:13: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 032D61A1B6D for ; Sun, 23 Nov 2014 16:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZaAeqYnaVwH for ; Sun, 23 Nov 2014 16:13:30 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6111A1B69 for ; Sun, 23 Nov 2014 16:13:17 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-03v.sys.comcast.net with comcast id KCDC1p0064tLnxL01CDGrs; Mon, 24 Nov 2014 00:13:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-02v.sys.comcast.net with comcast id KCDF1p0133Ge9ey01CDGV3; Mon, 24 Nov 2014 00:13:16 +0000 Message-ID: <5472781B.1050209@alum.mit.edu> Date: Sun, 23 Nov 2014 19:13:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D52ED53@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=q20140121; t=1416787996; bh=T7eru7MqcFK9hxHYHjP/7G2AWkUC0IM9AN3JjcFp2uI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PLZF4HFr/lZ/IpCkvtdDCZwFU3jbbQOffCcu5ESSeaQrFf7UxPNY7CIMesP7BDUWz OaicePXuiT6ox2a0t9vSh08JB2u4ALwHCtp7LX1JLATz6gg1rK0egm41tnhBoBpbBh rFabjU3DTGFn2SEuo96fWCsbI4LEB0pNZo3F3i8FhmuMRlmuxQOs6T4RHlmnbyZeAr IL64b5qoC1gdGDYA2Gxk+IL3koK9T8GN16mVdSy+GxZw5OidINjOaiS6w0MZ8NfcJU /b6eZZOl4RJMrhMV8zSA0XJ0QD6TXRtqNEvfETm21g2wt0tnfylFEjZjIeecgcIf4k aVffg7vVjimKQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/9PzEQVNBFneXBqtSmdltbRCZbNk Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 00:13:35 -0000 On 11/21/14 2:20 PM, Christer Holmberg wrote: > FYI, > > I sent the following to the MMUSIC list. > > The CLUE data channel draft currently assumes that DCEP is used to open > the CLUE data channel, once it has been negotiated using draft-ejzak. > > However, if draft-ejzak forbids usage of DCEP, and/or we don’t think > it’s needed for the CLUE data channel, we can remove it. > > In my opinion, the advantage of also using DCEP is that the endpoints > can choose when to open the data channel – otherwise it is considered > open once the SCTP association has been created. My understanding is that DCEP is *not* used. When you use external negotiation you simply agree (externally) on which stream ids are to be used (they don't even have to be the same in each direction) and start using them. I could be wrong, but I don't think the webrtc API has a way for you to use the DCEP protocol on an externally allocated channel. You can call to open a channel without supplying a stream id, in which case DCEP is automatically used to assign the id), or else you can supply a stream id when opening a channel (in which case DCEP is not used). I suppose nothing prevents you from using DCEP messages on your externally allocated channel, but then you would have to format and send them yourself, and decode them at the other end, rather than having the library behind the API doing it for you. Thanks, Paul > Regards, > > Christer > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 21 November 2014 21:17 > *To:* mmusic@ietf.org > *Subject:* [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and DCEP > > Hi, > > draft-ejzak-mmusic-data-channel-sdpneg currently seems to assume that > DCEP will not be used to open data channels – instead data channels will > be considered open once the SDP O/A negotiation has finished and the > SCTP association used to realize the data channel(s) has been created. > > My question is whether the intention is to forbid usage of DCEP together > with draft-ejzak-mmusic-data-channel-sdpneg, or whether it should be > optional? > > If optional, there needs to be a way to indicate that application data > shall not be sent until a channel has been opened using DCEP. In > addition, it would be useful to be able to indicate which endpoint is > responsible for sending the DCEP_CHANNEL_OPEN message. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Nov 23 16:16: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 1D0751A1B5E for ; Sun, 23 Nov 2014 16:16: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 YRW7Pw_3PM1J for ; Sun, 23 Nov 2014 16:16:26 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [96.114.154.171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7691A1B66 for ; Sun, 23 Nov 2014 16:16:26 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-12v.sys.comcast.net with comcast id KCGA1p0024xDoy801CGRZU; Mon, 24 Nov 2014 00:16:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id KCGR1p0043Ge9ey01CGRFn; Mon, 24 Nov 2014 00:16:25 +0000 Message-ID: <547278D8.5050703@alum.mit.edu> Date: Sun, 23 Nov 2014 19:16:24 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D52E027@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52E066@ESESSMB209.ericsson.se> <546EB026.4090207@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D52E530@ESESSMB209.ericsson.se> <54727498.5030500@nteczone.com> In-Reply-To: <54727498.5030500@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=q20140121; t=1416788185; bh=pjofmDaOCm2be3Q4N/pCOndMvcmlBqPGnCFyxB5/zfU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fZLHl3BS7pBkdKVBXSq4NJj7l5cbSO41oUv9w4gDWu5olztWecxbYOJ43dDIBDcXw ccjjnL+fh/GKTqHzvEZYnQNckb7m7tIMDAvT4ppRmCae8g9HAgG/19nmxlp/0rBQAf KvYKcgmEaRGKoehfIzfwkb7wE1J5o0UhBggOq37sieEm5yvnZbkIYdgmSBKypDnFzm ZZ+ImJeGw6PI3obE1WdH+ORN6mbXJoHLCD/lQJ6UgS9Ov8zMfDbY+niggwuS5oi4Py QIlAbvXfkX31DuzTbFLxK2tAZX749D3F0BFWa2NvsOri0wPR2d+6n9CMC/dIIZZ2ag lBPw5VjMP2Ovg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/oNc0J_UbKPByz0xOg2UficAHakI Subject: Re: [clue] Draft new version: clue-datachannel-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 00:16:28 -0000 On 11/23/14 6:58 PM, Christian Groves wrote: > Hello Christer, > >>> 4. Cl.3.2.4 - What's your intention on the use of label? The table >>> suggests that its optional but if included must have the value "CLUE >>> Data Channel" >> According to section 5.1.1.2 it is mandatory. My understanding is that >> it is needed for the W3C API, to identity the data channel, and data >> channel events. >> > Should CLUE be mandating a value for label? Its use is for distinguish > between RTCdatachannel objects. It seems any value would suffice so long > it is different and an endpoint may use different schemes to allocate it. If we are doing the negotiation of the channel in SDP, choosing the stream id, then I see no reason to mandate any particular label. Thanks, Paul From nobody Sun Nov 23 16:28: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 596161A1B66 for ; Sun, 23 Nov 2014 16:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.754 X-Spam-Level: **** X-Spam-Status: No, score=4.754 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 kNPXjjuNB8mn for ; Sun, 23 Nov 2014 16:28:40 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0371A038A for ; Sun, 23 Nov 2014 16:28:39 -0800 (PST) Received: from ppp118-209-241-2.lns20.mel8.internode.on.net ([118.209.241.2]:53980 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XshVQ-00078V-FI; Mon, 24 Nov 2014 11:27:52 +1100 Message-ID: <54727BB3.6030603@nteczone.com> Date: Mon, 24 Nov 2014 11:28:35 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Duckworth, Mark" , Christer Holmberg , "clue@ietf.org" References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> <00eb01cffeb8$41829c30$c487d490$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> <013a01cffed0$926aa8f0$b73ffad0$@gmail.com> <546424B1.7010408@alum.mit.edu> <546EB087.1060204@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D52E4D5@ESESSMB209.ericsson.se> <546ED5CC.5020807@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D52E555@ESESSMB209.ericsson.se> <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFDEDC@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFDEDC@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/uxsU5M1qrnULismEXEWLdSQZITg Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 00:28:42 -0000 I don't think its a trivial change. I assume if we remove this then a consumer must always choose "one" encoding from an encoding group? It also changes the semantic of the encoding group to sets of mutually exclusive encodings. Then does the "maxgroupbandwidth" also become meaningless for CLUE as from a CLUE perspective only one encoding will be chosen? If we decide to remove simulcast then we should remove it completely and not rely on some functionality in SDP and others in CLUE. Regards, Christian On 22/11/2014 1:52 AM, Duckworth, Mark wrote: > Yes, the people in the room at IETF 91 were clearly in favor of removing the CLUE simulcast feature enabled by "Max Capture Encodings" > 1. A reason to remove it is to avoid interop issue which could arise by having two different ways to do simulcast that don't interop with each other. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: Friday, November 21, 2014 1:21 AM >> To: Christian Groves; clue@ietf.org >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >> >> Hi, >> >>> Yes, I thought the assumption was nothing in CLUE prevented the use of >> the generic >simulcast draft. >> >> It was more a timing issue, as we didn't want to delay the CLUE work when it >> was unsure whether the simulcast was going to be adopted. >> >>> I'm wondering why the adoption of that meant part of CLUE was removed >> (at least >as I understand from the notes)? >> >> As far as I remember, yes. Nobody could come up with a reason why it >> should be kept. >> >> Regards, >> >> Christer >> >> >> On 21/11/2014 4:58 PM, Christer Holmberg wrote: >>> Hi, >>> >>> The generic simulcast draft was adopted in MMUSIC, and the idea is that it >> will be used also if someone wants to provide simulcast for CLUE. >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: 21 November 2014 05:25 >>> To: clue@ietf.org >>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>> >>> What's the status of the simultcast issue after the meeting? I saw some >> meeting notes to suggest that it would be removed from CLUE. I certainly >> didn't expect that from the discussions on the list. >>> Regards, Christian >>> >>> On 13/11/2014 2:25 PM, Paul Kyzivat wrote: >>>> If an sdp-based mechanism is published that allows simulcast in a >>>> single m-line, then clue gets to take advantage of that *for free*. I >>>> don't know that we need to say anything about that. >>>> >>>> The question we have to ask is: do we want to remove the >>>> clue-specific mechanism that is already present in our data model? >>>> >>>> To that I will add the corollary question: is there any cost to >>>> having that option in there? >>>> >>>> I can't see any cost. >>>> - Advertisers don't have to use it in their advertisements. >>>> - Consumers can't use it in Configure if it wasn't in the >>>> advertisement >>>> - Consumers don't have to use it if it is in the advertisement. >>>> >>>> So I see no harm in leaving it in. And some potential benefit to >>>> having it there. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 11/12/14 1:29 PM, Roni Even wrote: >>>>> Hi, >>>>> This is what started the discussion. If we do not have SDP based >>>>> simulcast based on unified plan, the only semantics is an encoding >>>>> per m-line. We started the discussion based on this assumption that >>>>> we can do simulcast in CLUE using an encoding per m-line and can >>>>> bundle them Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] >>>>>> Sent: 12 November, 2014 11:03 PM >>>>>> To: Duckworth, Mark; Roni Even >>>>>> Cc: clue@ietf.org >>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>> Yes, I'd have thought ideally multiple simulcast qualities, repair >>>>>> streams >>>>> etc >>>>>> would be defined under a single m-line and hence be a single >>>>>> encoding from CLUE's perspective. That matches the unified plan and >>>>>> the proposal in >>>>> draft- >>>>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it >>>>>> would mean that negotiating simulcast qualities, repair flows etc >>>>>> would be purely an >>>>> SDP >>>>>> issue and wouldn't impact CLUE. >>>>>> >>>>>> Rob >>>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, >>>>>> Mark >>>>>> Sent: 12 November 2014 10:54 >>>>>> To: Roni Even >>>>>> Cc: clue@ietf.org >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>> Hi, >>>>>> >>>>>> I don't understand why simulcast would need separate encoding >> groups. >>>>>> Whether an MC maps to two m-lines or one m-line with a=simulcast is >>>>>> up to the consumer, and specified in the configure message sent >>>>>> from consumer to provider. The mapping is done via the encoding ID >>>>>> labels which link media captures to m-lines. At least that is how >>>>>> I see it. >>>>>> >>>>>> Would you say retransmission streams are a separate issue from >>>>>> simulcast? >>>>> Or >>>>>> are they similar enough that it is really the same issue? Do SVC >>>>>> layered >>>>> codec >>>>>> streams also fall into this category? >>>>>> >>>>>> Sounds like we do need some more discussion about this. My first >>>>>> thought >>>>> is >>>>>> we should cover this in the signaling document. >>>>>> >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>>>> Sent: Wednesday, November 12, 2014 10:36 AM >>>>>>> To: Duckworth, Mark >>>>>>> Cc: clue@ietf.org >>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>>> >>>>>>> Hi, >>>>>>> This will work when we have a single encoding per m-line in the >>>>>>> SDP and I think it requires that each simulcast set will be in >>>>>>> separate encoding group . Still it will provide less functionality >>>>>>> than the one proposed in the simulcast proposal that will be >>>>>>> discussed in MMUSIC If simulcast in SDP will progress using the >>>>>>> unified plan where we have all encodings in one m-line we will >>>>>>> need to specify that if an MC have max capture encoding >1 will it >>>>>>> mean that it will map to two m-lines or will it use a configuration from >> an SDP description a=simulcast. >>>>>>> We will need to see how it works with retransmission if we specify >>>>>>> a retransmission RTP stream as an individual encoding. >>>>>>> >>>>>>> Roni >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] >>>>>>>> Sent: 06 November, 2014 9:45 PM >>>>>>>> To: Roni Even >>>>>>>> Cc: clue@ietf.org >>>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>>>> >>>>>>>> Hi Roni, >>>>>>>> Do you still have questions about the way simulcast is handled in >>>>>>>> the framework, regarding the attribute "Max capture encodings" >>>>>>>> and >>>>>>> configuring >>>>>>>> multiple encodings per capture? I was hoping we could resolve it >>>>>>>> on the >>>>>>> list, or >>>>>>>> do you think we need to talk about it in Honolulu? >>>>>>>> Regards, >>>>>>>> Mark >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>> Duckworth, >>>>>>> Mark >>>>>>>>> Sent: Monday, November 03, 2014 10:52 PM >>>>>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni >>>>>>>>>> Even >>>>>>>>>> Sent: Monday, November 03, 2014 5:52 PM >>>>>>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>> Christian Groves >>>>>>>>>>> Sent: 28 October, 2014 2:56 AM >>>>>>>>>>> To: clue@ietf.org >>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>>> >>>>>>>>>>> Hello Roni, >>>>>>>>>>> >>>>>>>>>>> As I mentioned in my original reply I think the RTP based >>>>>>>>>>> simulcast >>>>>>>>> method >>>>>>>>>> is >>>>>>>>>>> probably the cleanest approach. There would be nothing >>>>>>>>>>> stopping a CLUE endpoint implementing it when it becomes >>>>>>>>>>> available (like many other RTP features). Using CLUE for >>>>>>>>>>> simulcast I think is possible for most >>>>>>>>>> scenarios. The >>>>>>>>>>> more complicated the scenarios the more MCs/encodings an >>>>>>> endpoint >>>>>>>>> will >>>>>>>>>>> need to describe the situation. >>>>>>>>>>> >>>>>>>>>>> Please see my response below. >>>>>>>>>>> >>>>>>>>>>> Regards, Christian >>>>>>>>>>> >>>>>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: >>>>>>>>>>>> Hi Paul, >>>>>>>>>>>> >>>>>>>>>>>> If we want to be able to differentiate between simulcast and >>>>>>>>>>>> switched capture, for example if we have a three camera >>>>>>>>>>>> system that can send three MCs each with two encodings >>>>>>>>>>>> (simulcast) and a switched capture (loudest speaker or two >>>>>>>>>>>> loudest speakers out of three) using the same simulcast >>>>>>>>>>>> option for the each MC currently sent. In this case we can >>>>>>>>>>>> have an MC with two encodings and an MCC with the three >> MCs. >>>>>>>>>>>> This >>>>>>>>> will >>>>>>>>>>>> require us to clarify that having multiple individual >>>>>>>>>>>> encodings in MC is simulcast and not switched and in MCC it >>>>>>>>>>>> is switched and not >>>>>>>>> simulcast. >>>>>>>>>>> [CNG] I don't understand exactly what the issue is here? Could >>>>>>>>>>> you use >>>>>>>>> some >>>>>>>>>>> pseudo syntax to explain what you're wanting to advertise? You >>>>>>>>>>> say in >>>>>>>>> the first >>>>>>>>>>> sentence the switched capture uses simulcast but then in the >>>>>>>>>>> last >>>>>>>>> sentence you >>>>>>>>>>> say the MCC is switched and not simulcast. I would think that >>>>>>>>>>> an MCC can >>>>>>>>> still >>>>>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts >>>>>>>>>>> whatever source >>>>>>>>> is >>>>>>>>>>> switched into the media stream. >>>>>>>>>>> If you want a pure switched MCC just set maxCaptureEncodings >>>>>>>>>>> to >>>>>>>>>>> 1 >>>>>>>>> against the >>>>>>>>>>> MCC. >>>>>>>>>>> If you want a simultcast MCC just set maxCaptureEncodings to >>>>>>>>>>>> =2 >>>>>>>>> against the >>>>>>>>>>> MCC. >>>>>>>>>> [Roni Even] The thing is that I am not sure how to advertise >>>>>>>>>> this >>>>>>> example. >>>>>>>>>> The advertisement has two scene views: >>>>>>>>>> 1. Scene view with VC0, VC1, VC2 each with two simulcast >>>>>>>>>> streams >>>>> 2. >>>>>>>>>> Scene view MCC3 as represented bellow >>>>>>>>>> >>>>>>>>>> The different MCs will be: >>>>>>>>>> >>>>>>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max >> Capture >>>>>>>>> Encodings"? >>>>>>>>> Don't confuse this with the MCC attribute MaxCaptures which >>>>>>>>> means >>>>>>> "Max >>>>>>>>> number of Captures within a MCC". >>>>>>>>> >>>>>>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>>>>>> view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC2- (the right camera stream), encoding group=EG0, >> view=table. >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=EG0, view=room, >>>>>>>>> MaxCaptures=2 >>>>>>>>> >>>>>>>>> [Duckworth, Mark] It isn't clear if you really mean "max capture >>>>>>> encodings" >>>>>>>>> or >>>>>>>>> "max number of captures within a MCC". Those are two different >>>>> things. >>>>>>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. >>>>>>>>> [Duckworth, Mark] It depends how the consumer configures it. >>>>>>>>> The provider advertisement says it supports simulcast, so the >>>>>>>>> consumer can decide to use it or not. >>>>>>>>> >>>>>>>>>> What about MCC3? >>>>>>>>>> Is it multicast from one of the cameras or is it 2 MCs out of >>>>>>>>>> the three? (I assume it is the first since the view is room) >>>>>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three >>>>>>>>> simultaneously only if it is composed, not if it is switched. >>>>>>>>> The provider can give more information, if it wants to, with the >>>>>>>>> MCC attribute "max number of captures within a MCC". >>>>>>>>> >>>>>>>>>> What if in the above example MaxCaptures=4 can it be for >>>>>>>>>> example VC0, >>>>>>>>> VC1 >>>>>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and one >>>>>>>>>> of them is >>>>>>>>> simulcast? >>>>>>>>> >>>>>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single >> "conceptual" >>>>>>>>> capture. >>>>>>>>> It sounds like you are talking about a switched case, not a >>>>>>>>> composed case, so let's say MCC3 has the attribute "max number >>>>>>>>> of captures within >>>>>>> a >>>>>>>> MCC" = 1. >>>>>>>>> Now let's also suppose MCC3 has "max capture encodings" = 2. >>>>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, for >>>>>>>>> the two encodings. Then the provider decides when to switch >>>>>>>>> among VC0, VC1, and VC2, and whichever one the provider is >>>>>>>>> sending for >>>>>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast at >>>>>>>>> those two resolutions. >>>>>>>>> >>>>>>>>>> What I am trying to say is that using implied simulcast require >>>>>>>>>> text explaining when a consumer can understand that the >>>>>>>>>> advertisement is simulcast and not something else. >>>>>>>>>> The other approach may be to have an attribute for an MC and >>>>>>>>>> MCC that >>>>>>>>> will >>>>>>>>>> explicitly say that this is a simulcast offer. >>>>>>>>> [Duckworth, Mark] I think the advertisement is clear to the >>>>>>>>> consumer without any additional text or attributes added to the >>>>>>>>> framework. It is already explicit, with the attribute "max >>>>>>>>> capture encodings". If it is >1, then the advertisement is >>>>>>>>> offering >>>>>> simulcast. >>>>>>>>>> BTW: I think that the implied solution works when the >>>>>>>>>> individual encodings are the same (spatial or different codces) >>>>>>>>>> what if we the provider can send >>>>>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be >>>>>>>>>> four different encodings but not all combinations allowed. How >>>>>>>>>> to represent it in an advertisement? Is it : >>>>>>>>> [Duckworth, Mark] I can consider this case after we get the >>>>>>>>> first case above cleared up. >>>>>>>>> >>>>>>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>>>>>> view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC2- (the right camera stream), encoding group=EG0, >> view=table. >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC3- (the left camera stream), encoding group=EG1, view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC4- (the center camera stream), encoding group=EG1, >>>>>>>>>> view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC5- (the right camera stream), encoding group=EG1, >> view=table. >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two >>>>>>>>>> scene views >>>>>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? >>>>>>>>>> >>>>>>>>> ... snip ... >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> clue mailing list >>>>>>>>> clue@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Sun Nov 23 18:33: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 4B34E1A1B9B for ; Sun, 23 Nov 2014 18:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 w2St4bthFbez for ; Sun, 23 Nov 2014 18:33:40 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1BD1A1A43 for ; Sun, 23 Nov 2014 18:33:39 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-08-547299019722 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2D.74.04231.10992745; Mon, 24 Nov 2014 03:33:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Mon, 24 Nov 2014 03:33:36 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHwAAJH5gAGzPFIAABv9ZSQ== Date: Mon, 24 Nov 2014 02:33:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> In-Reply-To: <5472781B.1050209@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D5324F3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjS7jzKIQg+2twhb7T11mtlix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVx8ex05oLtHhXTJyxnamB8aNPFyMkhIWAi cWBTOyOELSZx4d56ti5GLg4hgSOMEg+37WWCcJYwSkzfvRgow8HBJmAh0f1PG6RBRMBTYsfH KcwgtrCAu0TH4dMsEHEPiXdbNjCDlIsIOAG1goVZBFQlXjT2soHYvAK+Ej17njNDjN/IKPH8 RTdYglNAR2LZ10dMIDYj0EHfT60Bs5kFxCWavqxkhThUQGLJnvPMELaoxMvH/1hBdjEL5Ev0 r+WCmC8ocXLmE5YJjMKzkHTPQqiahaQKosRA4sv721C2tsSyha+ZIWx9ie73p5mQxRcwsq9i FC1OLS7OTTcy1kstykwuLs7P08tLLdnECIydg1t+6+5gXP3a8RCjAAejEg/vh9bCECHWxLLi ytxDjNIcLErivIvOzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJgj3FbkxJ7gLPhrgr3U vNtzH27Y3a3G78+//tqnFTF+ElXzxTML4ps2tl33LNnhW3HS4VHV37XS578s45E70hYXosi3 1KrVury5Jf5hS7otz73ElDm9B2qcnixpKb8ctOwRh8eFSkOnF7eDxR6UHZvZG7Ux2OrEp7Vr lzHaPaxfeLjx0m3DWiWW4oxEQy3mouJEAHswLkN+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/L803ZXqudS72_H4VEYTpSKiR4zg Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 02:33:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D5324F3ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I agree with what you are saying, there is no need for DCEP if we use exter= nal negotiation. The question is then whether we should remove DCEP completely from the CLUE= data channel draft? DCEP could be useful if someone implemented CLUE using another signalling p= rotocol than SIP/SDP, but we are not specifying such usage, so... Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD24/=FD11/=FD2014 02:13 To: clue@ietf.org Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP On 11/21/14 2:20 PM, Christer Holmberg wrote: > FYI, > > I sent the following to the MMUSIC list. > > The CLUE data channel draft currently assumes that DCEP is used to open > the CLUE data channel, once it has been negotiated using draft-ejzak. > > However, if draft-ejzak forbids usage of DCEP, and/or we don=92t think > it=92s needed for the CLUE data channel, we can remove it. > > In my opinion, the advantage of also using DCEP is that the endpoints > can choose when to open the data channel =96 otherwise it is considered > open once the SCTP association has been created. My understanding is that DCEP is *not* used. When you use external negotiation you simply agree (externally) on which stream ids are to be used (they don't even have to be the same in each direction) and start using them. I could be wrong, but I don't think the webrtc API has a way for you to use the DCEP protocol on an externally allocated channel. You can call to open a channel without supplying a stream id, in which case DCEP is automatically used to assign the id), or else you can supply a stream id when opening a channel (in which case DCEP is not used). I suppose nothing prevents you from using DCEP messages on your externally allocated channel, but then you would have to format and send them yourself, and decode them at the other end, rather than having the library behind the API doing it for you. Thanks, Paul > Regards, > > Christer > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 21 November 2014 21:17 > *To:* mmusic@ietf.org > *Subject:* [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and DCEP > > Hi, > > draft-ejzak-mmusic-data-channel-sdpneg currently seems to assume that > DCEP will not be used to open data channels =96 instead data channels wil= l > be considered open once the SDP O/A negotiation has finished and the > SCTP association used to realize the data channel(s) has been created. > > My question is whether the intention is to forbid usage of DCEP together > with draft-ejzak-mmusic-data-channel-sdpneg, or whether it should be > optional? > > If optional, there needs to be a way to indicate that application data > shall not be sent until a channel has been opened using DCEP. In > addition, it would be useful to be able to indicate which endpoint is > responsible for sending the DCEP_CHANNEL_OPEN message. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7594FB04B1934943A5C02806D1A2204B1D5324F3ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

I agree with what you are saying, there is no need for DCEP if we use exter= nal negotiation.

The question is then whether we should remove DCEP completely from the CLUE= data channel draft?

DCEP could be useful if someone implemented CLUE using another signalling p= rotocol than SIP/SDP, but we are not specifying such usage, so...

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD24= /=FD11/=FD2014 02:13
To: clue@ietf.org
Subject: Re: [= clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP

On 11/21/14 2:20 PM, Christer Holmberg wrote:
> FYI,
>
> I sent the following to the MMUSIC list.
>
> The CLUE data channel draft currently assumes that DCEP is used to ope= n
> the CLUE data channel, once it has been negotiated using draft-ejzak.<= br> >
> However, if draft-ejzak forbids usage of DCEP, and/or we don=92t think=
> it=92s needed for the CLUE data channel, we can remove it.
>
> In my opinion, the advantage of also using DCEP is that the endpoints<= br> > can choose when to open the data channel =96 otherwise it is considere= d
> open once the SCTP association has been created.

My understanding is that DCEP is *not* used. When you use external
negotiation you simply agree (externally) on which stream ids are to be used (they don't even have to be the same in each direction) and start
using them.

I could be wrong, but I don't think the webrtc API has a way for you to use the DCEP protocol on an externally allocated channel. You can call
to open a channel without supplying a stream id, in which case DCEP is
automatically used to assign the id), or else you can supply a stream id when opening a channel (in which case DCEP is not used).

I suppose nothing prevents you from using DCEP messages on your
externally allocated channel, but then you would have to format and send them yourself, and decode them at the other end, rather than having the library behind the API doing it for you.

        Thanks,
        Paul

> Regards,
>
> Christer
>
> *From:*mmusic [mailto:mmusi= c-bounces@ietf.org] *On Behalf Of *Christer
> Holmberg
> *Sent:* 21 November 2014 21:17
> *To:* mmusic@ietf.org
> *Subject:* [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and DCEP >
> Hi,
>
> draft-ejzak-mmusic-data-channel-sdpneg currently seems to assume that<= br> > DCEP will not be used to open data channels =96 instead data channels = will
> be considered open once the SDP O/A negotiation has finished and the > SCTP association used to realize the data channel(s) has been created.=
>
> My question is whether the intention is to forbid usage of DCEP togeth= er
> with draft-ejzak-mmusic-data-channel-sdpneg, or whether it should be > optional?
>
> If optional, there needs to be a way to indicate that application data=
> shall not be sent until a channel has been opened using DCEP. In
> addition, it would be useful to be able to indicate which endpoint is<= br> > responsible for sending the DCEP_CHANNEL_OPEN message.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.iet= f.org/mailman/listinfo/clue
>

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org= /mailman/listinfo/clue
 --_000_7594FB04B1934943A5C02806D1A2204B1D5324F3ESESSMB209erics_-- From nobody Sun Nov 23 20:26: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 552041A1BC3 for ; Sun, 23 Nov 2014 20:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.053 X-Spam-Level: ** X-Spam-Status: No, score=2.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 dQfJPwJvvuS3 for ; Sun, 23 Nov 2014 20:26:22 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.5]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065A91A1BC5 for ; Sun, 23 Nov 2014 20:26:21 -0800 (PST) Received: from [216.82.249.212] by server-5.bemta-12.messagelabs.com id B2/5D-03158-D63B2745; Mon, 24 Nov 2014 04:26:21 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-6.tower-219.messagelabs.com!1416803180!15004984!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31878 invoked from network); 24 Nov 2014 04:26:20 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-6.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 24 Nov 2014 04:26:20 -0000 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; Sun, 23 Nov 2014 20:26:20 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Sun, 23 Nov 2014 20:26:19 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Sun, 23 Nov 2014 20:26:18 -0800 Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: AdAHfZr3cksw39gnTu2pM2NAIWXBYwAIS/MW Message-ID: 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_b3fameejua53wo4wosowtaw31416803191049emailandroidcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZveI23DWxgkD82cBp-OEkpb_p6g Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 04:26:27 -0000 --_000_b3fameejua53wo4wosowtaw31416803191049emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christian, I don't follow you. The original point of encoding groups, which still hol= ds true, is that multiple media captures can use the same encoding group. = So there is still a use for an encoding group, which can have multiple indi= vidual encodings, each of which can be configured to encode a different cap= ture. So maybe I'm not understanding your concern? Mark -------- Original message -------- From: Christian Groves Date:11/23/2014 7:28 PM (GMT-05:00) To: "Duckworth, Mark" , Christer Holmberg , clue@ietf.org Subject: Re: [clue] CLUE and Simulcast - ticket #47 I don't think its a trivial change. I assume if we remove this then a consumer must always choose "one" encoding from an encoding group? It also changes the semantic of the encoding group to sets of mutually exclusive encodings. Then does the "maxgroupbandwidth" also become meaningless for CLUE as from a CLUE perspective only one encoding will be chosen? If we decide to remove simulcast then we should remove it completely and not rely on some functionality in SDP and others in CLUE. Regards, Christian On 22/11/2014 1:52 AM, Duckworth, Mark wrote: > Yes, the people in the room at IETF 91 were clearly in favor of removing = the CLUE simulcast feature enabled by "Max Capture Encodings" > 1. A reaso= n to remove it is to avoid interop issue which could arise by having two di= fferent ways to do simulcast that don't interop with each other. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: Friday, November 21, 2014 1:21 AM >> To: Christian Groves; clue@ietf.org >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >> >> Hi, >> >>> Yes, I thought the assumption was nothing in CLUE prevented the use of >> the generic >simulcast draft. >> >> It was more a timing issue, as we didn't want to delay the CLUE work whe= n it >> was unsure whether the simulcast was going to be adopted. >> >>> I'm wondering why the adoption of that meant part of CLUE was removed >> (at least >as I understand from the notes)? >> >> As far as I remember, yes. Nobody could come up with a reason why it >> should be kept. >> >> Regards, >> >> Christer >> >> >> On 21/11/2014 4:58 PM, Christer Holmberg wrote: >>> Hi, >>> >>> The generic simulcast draft was adopted in MMUSIC, and the idea is that= it >> will be used also if someone wants to provide simulcast for CLUE. >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: 21 November 2014 05:25 >>> To: clue@ietf.org >>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>> >>> What's the status of the simultcast issue after the meeting? I saw some >> meeting notes to suggest that it would be removed from CLUE. I certainly >> didn't expect that from the discussions on the list. >>> Regards, Christian >>> >>> On 13/11/2014 2:25 PM, Paul Kyzivat wrote: >>>> If an sdp-based mechanism is published that allows simulcast in a >>>> single m-line, then clue gets to take advantage of that *for free*. I >>>> don't know that we need to say anything about that. >>>> >>>> The question we have to ask is: do we want to remove the >>>> clue-specific mechanism that is already present in our data model? >>>> >>>> To that I will add the corollary question: is there any cost to >>>> having that option in there? >>>> >>>> I can't see any cost. >>>> - Advertisers don't have to use it in their advertisements. >>>> - Consumers can't use it in Configure if it wasn't in the >>>> advertisement >>>> - Consumers don't have to use it if it is in the advertisement. >>>> >>>> So I see no harm in leaving it in. And some potential benefit to >>>> having it there. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 11/12/14 1:29 PM, Roni Even wrote: >>>>> Hi, >>>>> This is what started the discussion. If we do not have SDP based >>>>> simulcast based on unified plan, the only semantics is an encoding >>>>> per m-line. We started the discussion based on this assumption that >>>>> we can do simulcast in CLUE using an encoding per m-line and can >>>>> bundle them Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] >>>>>> Sent: 12 November, 2014 11:03 PM >>>>>> To: Duckworth, Mark; Roni Even >>>>>> Cc: clue@ietf.org >>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>> Yes, I'd have thought ideally multiple simulcast qualities, repair >>>>>> streams >>>>> etc >>>>>> would be defined under a single m-line and hence be a single >>>>>> encoding from CLUE's perspective. That matches the unified plan and >>>>>> the proposal in >>>>> draft- >>>>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it >>>>>> would mean that negotiating simulcast qualities, repair flows etc >>>>>> would be purely an >>>>> SDP >>>>>> issue and wouldn't impact CLUE. >>>>>> >>>>>> Rob >>>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, >>>>>> Mark >>>>>> Sent: 12 November 2014 10:54 >>>>>> To: Roni Even >>>>>> Cc: clue@ietf.org >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>> Hi, >>>>>> >>>>>> I don't understand why simulcast would need separate encoding >> groups. >>>>>> Whether an MC maps to two m-lines or one m-line with a=3Dsimulcast i= s >>>>>> up to the consumer, and specified in the configure message sent >>>>>> from consumer to provider. The mapping is done via the encoding ID >>>>>> labels which link media captures to m-lines. At least that is how >>>>>> I see it. >>>>>> >>>>>> Would you say retransmission streams are a separate issue from >>>>>> simulcast? >>>>> Or >>>>>> are they similar enough that it is really the same issue? Do SVC >>>>>> layered >>>>> codec >>>>>> streams also fall into this category? >>>>>> >>>>>> Sounds like we do need some more discussion about this. My first >>>>>> thought >>>>> is >>>>>> we should cover this in the signaling document. >>>>>> >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>>>> Sent: Wednesday, November 12, 2014 10:36 AM >>>>>>> To: Duckworth, Mark >>>>>>> Cc: clue@ietf.org >>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>>> >>>>>>> Hi, >>>>>>> This will work when we have a single encoding per m-line in the >>>>>>> SDP and I think it requires that each simulcast set will be in >>>>>>> separate encoding group . Still it will provide less functionality >>>>>>> than the one proposed in the simulcast proposal that will be >>>>>>> discussed in MMUSIC If simulcast in SDP will progress using the >>>>>>> unified plan where we have all encodings in one m-line we will >>>>>>> need to specify that if an MC have max capture encoding >1 will it >>>>>>> mean that it will map to two m-lines or will it use a configuration= from >> an SDP description a=3Dsimulcast. >>>>>>> We will need to see how it works with retransmission if we specify >>>>>>> a retransmission RTP stream as an individual encoding. >>>>>>> >>>>>>> Roni >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] >>>>>>>> Sent: 06 November, 2014 9:45 PM >>>>>>>> To: Roni Even >>>>>>>> Cc: clue@ietf.org >>>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>>>> >>>>>>>> Hi Roni, >>>>>>>> Do you still have questions about the way simulcast is handled in >>>>>>>> the framework, regarding the attribute "Max capture encodings" >>>>>>>> and >>>>>>> configuring >>>>>>>> multiple encodings per capture? I was hoping we could resolve it >>>>>>>> on the >>>>>>> list, or >>>>>>>> do you think we need to talk about it in Honolulu? >>>>>>>> Regards, >>>>>>>> Mark >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>> Duckworth, >>>>>>> Mark >>>>>>>>> Sent: Monday, November 03, 2014 10:52 PM >>>>>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni >>>>>>>>>> Even >>>>>>>>>> Sent: Monday, November 03, 2014 5:52 PM >>>>>>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>> Christian Groves >>>>>>>>>>> Sent: 28 October, 2014 2:56 AM >>>>>>>>>>> To: clue@ietf.org >>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>>> >>>>>>>>>>> Hello Roni, >>>>>>>>>>> >>>>>>>>>>> As I mentioned in my original reply I think the RTP based >>>>>>>>>>> simulcast >>>>>>>>> method >>>>>>>>>> is >>>>>>>>>>> probably the cleanest approach. There would be nothing >>>>>>>>>>> stopping a CLUE endpoint implementing it when it becomes >>>>>>>>>>> available (like many other RTP features). Using CLUE for >>>>>>>>>>> simulcast I think is possible for most >>>>>>>>>> scenarios. The >>>>>>>>>>> more complicated the scenarios the more MCs/encodings an >>>>>>> endpoint >>>>>>>>> will >>>>>>>>>>> need to describe the situation. >>>>>>>>>>> >>>>>>>>>>> Please see my response below. >>>>>>>>>>> >>>>>>>>>>> Regards, Christian >>>>>>>>>>> >>>>>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: >>>>>>>>>>>> Hi Paul, >>>>>>>>>>>> >>>>>>>>>>>> If we want to be able to differentiate between simulcast and >>>>>>>>>>>> switched capture, for example if we have a three camera >>>>>>>>>>>> system that can send three MCs each with two encodings >>>>>>>>>>>> (simulcast) and a switched capture (loudest speaker or two >>>>>>>>>>>> loudest speakers out of three) using the same simulcast >>>>>>>>>>>> option for the each MC currently sent. In this case we can >>>>>>>>>>>> have an MC with two encodings and an MCC with the three >> MCs. >>>>>>>>>>>> This >>>>>>>>> will >>>>>>>>>>>> require us to clarify that having multiple individual >>>>>>>>>>>> encodings in MC is simulcast and not switched and in MCC it >>>>>>>>>>>> is switched and not >>>>>>>>> simulcast. >>>>>>>>>>> [CNG] I don't understand exactly what the issue is here? Could >>>>>>>>>>> you use >>>>>>>>> some >>>>>>>>>>> pseudo syntax to explain what you're wanting to advertise? You >>>>>>>>>>> say in >>>>>>>>> the first >>>>>>>>>>> sentence the switched capture uses simulcast but then in the >>>>>>>>>>> last >>>>>>>>> sentence you >>>>>>>>>>> say the MCC is switched and not simulcast. I would think that >>>>>>>>>>> an MCC can >>>>>>>>> still >>>>>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts >>>>>>>>>>> whatever source >>>>>>>>> is >>>>>>>>>>> switched into the media stream. >>>>>>>>>>> If you want a pure switched MCC just set maxCaptureEncodings >>>>>>>>>>> to >>>>>>>>>>> 1 >>>>>>>>> against the >>>>>>>>>>> MCC. >>>>>>>>>>> If you want a simultcast MCC just set maxCaptureEncodings to >>>>>>>>>>>> =3D2 >>>>>>>>> against the >>>>>>>>>>> MCC. >>>>>>>>>> [Roni Even] The thing is that I am not sure how to advertise >>>>>>>>>> this >>>>>>> example. >>>>>>>>>> The advertisement has two scene views: >>>>>>>>>> 1. Scene view with VC0, VC1, VC2 each with two simulcast >>>>>>>>>> streams >>>>> 2. >>>>>>>>>> Scene view MCC3 as represented bellow >>>>>>>>>> >>>>>>>>>> The different MCs will be: >>>>>>>>>> >>>>>>>>>> VC0- (the left camera stream), encoding group=3DEG0, view=3Dtabl= e, >>>>>>>>>> MaxCaptures=3D2 >>>>>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max >> Capture >>>>>>>>> Encodings"? >>>>>>>>> Don't confuse this with the MCC attribute MaxCaptures which >>>>>>>>> means >>>>>>> "Max >>>>>>>>> number of Captures within a MCC". >>>>>>>>> >>>>>>>>>> VC1- (the center camera stream), encoding group=3DEG0, >>>>>>>>>> view=3Dtable, >>>>>>>>>> MaxCaptures=3D2 >>>>>>>>>> >>>>>>>>>> VC2- (the right camera stream), encoding group=3DEG0, >> view=3Dtable. >>>>>>>>>> MaxCaptures=3D2 >>>>>>>>>> >>>>>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=3DEG0, view=3Droom, >>>>>>>>> MaxCaptures=3D2 >>>>>>>>> >>>>>>>>> [Duckworth, Mark] It isn't clear if you really mean "max capture >>>>>>> encodings" >>>>>>>>> or >>>>>>>>> "max number of captures within a MCC". Those are two different >>>>> things. >>>>>>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. >>>>>>>>> [Duckworth, Mark] It depends how the consumer configures it. >>>>>>>>> The provider advertisement says it supports simulcast, so the >>>>>>>>> consumer can decide to use it or not. >>>>>>>>> >>>>>>>>>> What about MCC3? >>>>>>>>>> Is it multicast from one of the cameras or is it 2 MCs out of >>>>>>>>>> the three? (I assume it is the first since the view is room) >>>>>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three >>>>>>>>> simultaneously only if it is composed, not if it is switched. >>>>>>>>> The provider can give more information, if it wants to, with the >>>>>>>>> MCC attribute "max number of captures within a MCC". >>>>>>>>> >>>>>>>>>> What if in the above example MaxCaptures=3D4 can it be for >>>>>>>>>> example VC0, >>>>>>>>> VC1 >>>>>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and one >>>>>>>>>> of them is >>>>>>>>> simulcast? >>>>>>>>> >>>>>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single >> "conceptual" >>>>>>>>> capture. >>>>>>>>> It sounds like you are talking about a switched case, not a >>>>>>>>> composed case, so let's say MCC3 has the attribute "max number >>>>>>>>> of captures within >>>>>>> a >>>>>>>> MCC" =3D 1. >>>>>>>>> Now let's also suppose MCC3 has "max capture encodings" =3D 2. >>>>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, for >>>>>>>>> the two encodings. Then the provider decides when to switch >>>>>>>>> among VC0, VC1, and VC2, and whichever one the provider is >>>>>>>>> sending for >>>>>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast at >>>>>>>>> those two resolutions. >>>>>>>>> >>>>>>>>>> What I am trying to say is that using implied simulcast require >>>>>>>>>> text explaining when a consumer can understand that the >>>>>>>>>> advertisement is simulcast and not something else. >>>>>>>>>> The other approach may be to have an attribute for an MC and >>>>>>>>>> MCC that >>>>>>>>> will >>>>>>>>>> explicitly say that this is a simulcast offer. >>>>>>>>> [Duckworth, Mark] I think the advertisement is clear to the >>>>>>>>> consumer without any additional text or attributes added to the >>>>>>>>> framework. It is already explicit, with the attribute "max >>>>>>>>> capture encodings". If it is >1, then the advertisement is >>>>>>>>> offering >>>>>> simulcast. >>>>>>>>>> BTW: I think that the implied solution works when the >>>>>>>>>> individual encodings are the same (spatial or different codces) >>>>>>>>>> what if we the provider can send >>>>>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be >>>>>>>>>> four different encodings but not all combinations allowed. How >>>>>>>>>> to represent it in an advertisement? Is it : >>>>>>>>> [Duckworth, Mark] I can consider this case after we get the >>>>>>>>> first case above cleared up. >>>>>>>>> >>>>>>>>>> VC0- (the left camera stream), encoding group=3DEG0, view=3Dtabl= e, >>>>>>>>>> MaxCaptures=3D2 >>>>>>>>>> >>>>>>>>>> VC1- (the center camera stream), encoding group=3DEG0, >>>>>>>>>> view=3Dtable, >>>>>>>>>> MaxCaptures=3D2 >>>>>>>>>> >>>>>>>>>> VC2- (the right camera stream), encoding group=3DEG0, >> view=3Dtable. >>>>>>>>>> MaxCaptures=3D2 >>>>>>>>>> >>>>>>>>>> VC3- (the left camera stream), encoding group=3DEG1, view=3Dtabl= e, >>>>>>>>>> MaxCaptures=3D2 >>>>>>>>>> >>>>>>>>>> VC4- (the center camera stream), encoding group=3DEG1, >>>>>>>>>> view=3Dtable, >>>>>>>>>> MaxCaptures=3D2 >>>>>>>>>> >>>>>>>>>> VC5- (the right camera stream), encoding group=3DEG1, >> view=3Dtable. >>>>>>>>>> MaxCaptures=3D2 >>>>>>>>>> >>>>>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two >>>>>>>>>> scene views >>>>>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? >>>>>>>>>> >>>>>>>>> ... snip ... >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> clue mailing list >>>>>>>>> clue@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing 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_b3fameejua53wo4wosowtaw31416803191049emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christian,
I don't  follow you. The original point of enc= oding groups, which still holds true, is that multiple media captures can u= se the same encoding group.  So there is still a use for an encoding g= roup, which can have multiple individual encodings, each of which can be co= nfigured to encode a different capture.
So maybe I'm not understa= nding your concern? 
Mark


-------- Original mes= sage --------
From: Christian Groves <Christian.Groves@nteczone.com&g= t;
Date:11/23/2014 7:28 PM (GMT-05:00)
To: "Duckworth, Mark&qu= ot; <Mark.Duckworth@polycom.com>, Christer Holmberg <christer.holm= berg@ericsson.com>, clue@ietf.org
Subject: Re: [clue] CLUE and Simul= cast - ticket #47

I don't think its a trivial chang= e. I assume if we remove this then a
consumer must always choose "one" encoding from an encoding group= ? It
also changes the semantic of the encoding group to sets of mutually
exclusive encodings. Then does the "maxgroupbandwidth" also becom= e
meaningless for CLUE as from a CLUE perspective only one encoding will
be chosen? If we decide to remove simulcast then we should remove it
completely and not rely on some functionality in SDP and others in CLUE.
Regards, Christian



On 22/11/2014 1:52 AM, Duckworth, Mark wrote:
> Yes, the people in the room at IETF 91 were clearly in favor of removi= ng the CLUE simulcast feature enabled by "Max Capture Encodings" = > 1.  A reason to remove it is to avoid interop issue which could a= rise by having two different ways to do simulcast that don't interop with e= ach other.
>
> Mark
>
>> -----Original Message-----
>> From: clue [mailto:clue-b= ounces@ietf.org] On Behalf Of Christer Holmberg
>> Sent: Friday, November 21, 2014 1:21 AM
>> To: Christian Groves; clue@ietf.org
>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
>>
>> Hi,
>>
>>> Yes, I thought the assumption was nothing in CLUE prevented th= e use of
>> the generic >simulcast draft.
>>
>> It was more a timing issue, as we didn't want to delay the CLUE wo= rk when it
>> was unsure whether the simulcast was going to be adopted.
>>
>>> I'm wondering why the adoption of that meant part of CLUE was = removed
>> (at least >as I understand from the notes)?
>>
>> As far as I remember, yes. Nobody could come up with a reason why = it
>> should be kept.
>>
>> Regards,
>>
>> Christer
>>
>>
>> On 21/11/2014 4:58 PM, Christer Holmberg wrote:
>>> Hi,
>>>
>>> The generic simulcast draft was adopted in MMUSIC, and the ide= a is that it
>> will be used also if someone wants to provide simulcast for CLUE.<= br> >>> Regards,
>>>
>>> Christer
>>>
>>> -----Original Message-----
>>> From: clue [mailto:cl= ue-bounces@ietf.org] On Behalf Of Christian
>>> Groves
>>> Sent: 21 November 2014 05:25
>>> To: clue@ietf.org
>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47
>>>
>>> What's the status of the simultcast issue after the meeting? I= saw some
>> meeting notes to suggest that it would be removed from CLUE. I cer= tainly
>> didn't expect that from the discussions on the list.
>>> Regards, Christian
>>>
>>> On 13/11/2014 2:25 PM, Paul Kyzivat wrote:
>>>> If an sdp-based mechanism is published that allows simulca= st in a
>>>> single m-line, then clue gets to take advantage of that *f= or free*. I
>>>> don't know that we need to say anything about that.
>>>>
>>>> The question we have to ask is: do we want to remove the >>>> clue-specific mechanism that is already present in our dat= a model?
>>>>
>>>> To that I will add the corollary question: is there any co= st to
>>>> having that option in there?
>>>>
>>>> I can't see any cost.
>>>> - Advertisers don't have to use it in their advertisements= .
>>>> - Consumers can't use it in Configure if it wasn't in the<= br> >>>> advertisement
>>>> - Consumers don't have to use it if it is in the advertise= ment.
>>>>
>>>> So I see no harm in leaving it in. And some potential bene= fit to
>>>> having it there.
>>>>
>>>>       Thanks,
>>>>       Paul
>>>>
>>>> On 11/12/14 1:29 PM, Roni Even wrote:
>>>>> Hi,
>>>>> This is what started the discussion. If we do not have= SDP based
>>>>> simulcast based on unified plan, the only semantics is= an encoding
>>>>> per m-line. We started the discussion based on this as= sumption that
>>>>> we can do simulcast in CLUE using an encoding per m-li= ne and can
>>>>> bundle them Roni
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com]
>>>>>> Sent: 12 November, 2014 11:03 PM
>>>>>> To: Duckworth, Mark; Roni Even
>>>>>> Cc: clue@ietf.org
>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #4= 7
>>>>>>
>>>>>> Yes, I'd have thought ideally multiple simulcast q= ualities, repair
>>>>>> streams
>>>>> etc
>>>>>> would be defined under a single m-line and hence b= e a single
>>>>>> encoding from CLUE's perspective. That matches the= unified plan and
>>>>>> the proposal in
>>>>> draft-
>>>>>> burman-mmusic-sdp-simulcast-00, and from CLUE's pe= rspective it
>>>>>> would mean that negotiating simulcast qualities, r= epair flows etc
>>>>>> would be purely an
>>>>> SDP
>>>>>> issue and wouldn't impact CLUE.
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth,
>>>>>> Mark
>>>>>> Sent: 12 November 2014 10:54
>>>>>> To: Roni Even
>>>>>> Cc: clue@ietf.org
>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #4= 7
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I don't understand why simulcast would need separa= te encoding
>> groups.
>>>>>> Whether an MC maps to two m-lines or one m-line wi= th a=3Dsimulcast is
>>>>>> up to the consumer, and specified in the configure= message sent
>>>>>> from consumer to provider.  The mapping is do= ne via the encoding ID
>>>>>> labels which link media captures to m-lines. = At least that is how
>>>>>> I see it.
>>>>>>
>>>>>> Would you say retransmission streams are a separat= e issue from
>>>>>> simulcast?
>>>>> Or
>>>>>> are they similar enough that it is really the same= issue?  Do SVC
>>>>>> layered
>>>>> codec
>>>>>> streams also fall into this category?
>>>>>>
>>>>>> Sounds like we do need some more discussion about = this.  My first
>>>>>> thought
>>>>> is
>>>>>> we should cover this in the signaling document. >>>>>>
>>>>>> Mark
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com]
>>>>>>> Sent: Wednesday, November 12, 2014 10:36 AM >>>>>>> To: Duckworth, Mark
>>>>>>> Cc: clue@ietf.org
>>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticke= t #47
>>>>>>>
>>>>>>> Hi,
>>>>>>> This will work when we have a single encoding = per m-line in the
>>>>>>> SDP and I think it requires that each simulcas= t set will be in
>>>>>>> separate encoding group . Still it will provid= e less functionality
>>>>>>> than the one proposed in the simulcast proposa= l that will be
>>>>>>> discussed in MMUSIC If simulcast in SDP will p= rogress using the
>>>>>>> unified plan where we have all encodings in on= e m-line we will
>>>>>>> need to specify that if an MC have max capture= encoding >1 will it
>>>>>>> mean that it will map to two m-lines or will i= t use a configuration from
>> an SDP description a=3Dsimulcast.
>>>>>>> We will need to see how it works with retransm= ission if we specify
>>>>>>> a retransmission RTP stream as an individual e= ncoding.
>>>>>>>
>>>>>>> Roni
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com]
>>>>>>>> Sent: 06 November, 2014 9:45 PM
>>>>>>>> To: Roni Even
>>>>>>>> Cc: clue@ietf.org
>>>>>>>> Subject: RE: [clue] CLUE and Simulcast - t= icket #47
>>>>>>>>
>>>>>>>> Hi Roni,
>>>>>>>> Do you still have questions about the way = simulcast is handled in
>>>>>>>> the framework, regarding the attribute &qu= ot;Max capture encodings"
>>>>>>>> and
>>>>>>> configuring
>>>>>>>> multiple encodings per capture?  I wa= s hoping we could resolve it
>>>>>>>> on the
>>>>>>> list, or
>>>>>>>> do you think we need to talk about it in H= onolulu?
>>>>>>>> Regards,
>>>>>>>> Mark
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of
>>>>>>>>> Duckworth,
>>>>>>> Mark
>>>>>>>>> Sent: Monday, November 03, 2014 10:52 = PM
>>>>>>>>> To: Roni Even; 'Christian Groves'; clu= e@ietf.org
>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast= - ticket #47
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni
>>>>>>>>>> Even
>>>>>>>>>> Sent: Monday, November 03, 2014 5:= 52 PM
>>>>>>>>>> To: 'Christian Groves'; clue@ietf.= org
>>>>>>>>>> Subject: Re: [clue] CLUE and Simul= cast - ticket #47
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of
>>>>>>>>>>> Christian Groves
>>>>>>>>>>> Sent: 28 October, 2014 2:56 AM=
>>>>>>>>>>> To: clue@ietf.org
>>>>>>>>>>> Subject: Re: [clue] CLUE and S= imulcast - ticket #47
>>>>>>>>>>>
>>>>>>>>>>> Hello Roni,
>>>>>>>>>>>
>>>>>>>>>>> As I mentioned in my original = reply I think the RTP based
>>>>>>>>>>> simulcast
>>>>>>>>> method
>>>>>>>>>> is
>>>>>>>>>>> probably the cleanest approach= . There would be nothing
>>>>>>>>>>> stopping a CLUE endpoint imple= menting it when it becomes
>>>>>>>>>>> available (like many other RTP= features). Using CLUE for
>>>>>>>>>>> simulcast I think is possible = for most
>>>>>>>>>> scenarios. The
>>>>>>>>>>> more complicated the scenarios= the more MCs/encodings an
>>>>>>> endpoint
>>>>>>>>> will
>>>>>>>>>>> need to describe the situation= .
>>>>>>>>>>>
>>>>>>>>>>> Please see my response below.<= br> >>>>>>>>>>>
>>>>>>>>>>> Regards, Christian
>>>>>>>>>>>
>>>>>>>>>>> On 27/10/2014 9:20 PM, Roni Ev= en wrote:
>>>>>>>>>>>> Hi Paul,
>>>>>>>>>>>>
>>>>>>>>>>>> If we want to be able to d= ifferentiate between simulcast and
>>>>>>>>>>>> switched capture, for exam= ple if we have a three camera
>>>>>>>>>>>> system that can send three= MCs each with two encodings
>>>>>>>>>>>> (simulcast) and a switched= capture (loudest speaker or two
>>>>>>>>>>>> loudest speakers out of th= ree) using the same simulcast
>>>>>>>>>>>> option for the each MC cur= rently sent. In this case we can
>>>>>>>>>>>> have an MC with two encodi= ngs and an MCC with the three
>> MCs.
>>>>>>>>>>>> This
>>>>>>>>> will
>>>>>>>>>>>> require us to clarify that= having multiple individual
>>>>>>>>>>>> encodings in MC is simulca= st and not switched and in MCC it
>>>>>>>>>>>> is switched and not
>>>>>>>>> simulcast.
>>>>>>>>>>> [CNG] I don't understand exact= ly what the issue is here? Could
>>>>>>>>>>> you use
>>>>>>>>> some
>>>>>>>>>>> pseudo syntax to explain what = you're wanting to advertise? You
>>>>>>>>>>> say in
>>>>>>>>> the first
>>>>>>>>>>> sentence the switched capture = uses simulcast but then in the
>>>>>>>>>>> last
>>>>>>>>> sentence you
>>>>>>>>>>> say the MCC is switched and no= t simulcast. I would think that
>>>>>>>>>>> an MCC can
>>>>>>>>> still
>>>>>>>>>>> be switched and simulcast, i.e= . the endpoint simulcasts
>>>>>>>>>>> whatever source
>>>>>>>>> is
>>>>>>>>>>> switched into the media stream= .
>>>>>>>>>>> If you want a pure switched MC= C just set maxCaptureEncodings
>>>>>>>>>>> to
>>>>>>>>>>> 1
>>>>>>>>> against the
>>>>>>>>>>> MCC.
>>>>>>>>>>> If you want a simultcast MCC j= ust set maxCaptureEncodings to
>>>>>>>>>>>> =3D2
>>>>>>>>> against the
>>>>>>>>>>> MCC.
>>>>>>>>>> [Roni Even] The thing is that I am= not sure how to advertise
>>>>>>>>>> this
>>>>>>> example.
>>>>>>>>>> The advertisement has two scene vi= ews:
>>>>>>>>>>     1. Scene v= iew with VC0, VC1, VC2 each with two simulcast
>>>>>>>>>> streams
>>>>> 2.
>>>>>>>>>> Scene view MCC3 as represented bel= low
>>>>>>>>>>
>>>>>>>>>> The different MCs will be:
>>>>>>>>>>
>>>>>>>>>> VC0- (the left camera stream), enc= oding group=3DEG0, view=3Dtable,
>>>>>>>>>> MaxCaptures=3D2
>>>>>>>>> [Duckworth, Mark] I assume "MaxCa= ptures" here means "Max
>> Capture
>>>>>>>>> Encodings"?
>>>>>>>>> Don't confuse this with the MCC attrib= ute MaxCaptures which
>>>>>>>>> means
>>>>>>> "Max
>>>>>>>>> number of Captures within a MCC".=
>>>>>>>>>
>>>>>>>>>>     VC1- (the = center camera stream), encoding group=3DEG0,
>>>>>>>>>> view=3Dtable,
>>>>>>>>>> MaxCaptures=3D2
>>>>>>>>>>
>>>>>>>>>>     VC2- (the = right camera stream), encoding group=3DEG0,
>> view=3Dtable.
>>>>>>>>>> MaxCaptures=3D2
>>>>>>>>>>
>>>>>>>>>>      MCC3= (VC0, VC1, VC2) - encoding group=3DEG0, view=3Droom,
>>>>>>>>> MaxCaptures=3D2
>>>>>>>>>
>>>>>>>>> [Duckworth, Mark] It isn't clear if yo= u really mean "max capture
>>>>>>> encodings"
>>>>>>>>> or
>>>>>>>>> "max number of captures within a = MCC".  Those are two different
>>>>> things.
>>>>>>>>>> Now it may be implied here that VC= 0, VC1, VC2 are simulcast.
>>>>>>>>> [Duckworth, Mark] It depends how the c= onsumer configures it.
>>>>>>>>> The provider advertisement says it sup= ports simulcast, so the
>>>>>>>>> consumer can decide to use it or not.<= br> >>>>>>>>>
>>>>>>>>>> What  about MCC3?
>>>>>>>>>> Is it multicast from one of the ca= meras or is it 2 MCs out of
>>>>>>>>>> the three? (I assume it is the fir= st since the view is room)
>>>>>>>>> [Duckworth, Mark] MCC3 can provide 2 M= Cs out of the three
>>>>>>>>> simultaneously only if it is composed,= not if it is switched.
>>>>>>>>> The provider can give more information= , if it wants to, with the
>>>>>>>>> MCC attribute "max number of capt= ures within a MCC".
>>>>>>>>>
>>>>>>>>>> What if in the above example MaxCa= ptures=3D4 can it be for
>>>>>>>>>> example VC0,
>>>>>>>>> VC1
>>>>>>>>>> each with two simulcast streams or= is it VC0, VC1, VC2 and one
>>>>>>>>>> of them is
>>>>>>>>> simulcast?
>>>>>>>>>
>>>>>>>>> [Duckworth, Mark] Neither.  The M= CC3 provides a single
>> "conceptual"
>>>>>>>>> capture.
>>>>>>>>> It sounds like you are talking about a= switched case, not a
>>>>>>>>> composed case, so let's say MCC3 has t= he attribute "max number
>>>>>>>>> of captures within
>>>>>>> a
>>>>>>>> MCC" =3D 1.
>>>>>>>>> Now let's also suppose MCC3 has "= max capture encodings" =3D 2.
>>>>>>>>> Then the consumer can ask for, say, MC= C3 at 720p and SIF, for
>>>>>>>>> the two encodings.  Then the prov= ider decides when to switch
>>>>>>>>> among VC0, VC1, and VC2, and whichever= one the provider is
>>>>>>>>> sending for
>>>>>>>>> MCC3 it sends it at both SIF and 720p,= so MCC3 is simulcast at
>>>>>>>>> those two resolutions.
>>>>>>>>>
>>>>>>>>>> What I am trying to say is that us= ing implied simulcast require
>>>>>>>>>> text explaining when a consumer ca= n understand that the
>>>>>>>>>> advertisement is simulcast and not= something else.
>>>>>>>>>> The other approach may be to have = an attribute for an MC and
>>>>>>>>>> MCC that
>>>>>>>>> will
>>>>>>>>>> explicitly say that this is a simu= lcast offer.
>>>>>>>>> [Duckworth, Mark] I think the advertis= ement is clear to the
>>>>>>>>> consumer without any additional text o= r attributes added to the
>>>>>>>>> framework.  It is already explici= t, with the attribute "max
>>>>>>>>> capture encodings".  If it i= s >1, then the advertisement is
>>>>>>>>> offering
>>>>>> simulcast.
>>>>>>>>>> BTW: I think that the implied solu= tion works when the
>>>>>>>>>> individual encodings are the same = (spatial or different codces)
>>>>>>>>>> what if we the provider can send >>>>>>>>>> H.264 CIF and HD or VP8 CIF and HD= . In the SDP this will be
>>>>>>>>>> four different encodings but not a= ll combinations allowed. How
>>>>>>>>>> to represent it in an advertisemen= t? Is it :
>>>>>>>>> [Duckworth, Mark] I can consider this = case after we get the
>>>>>>>>> first case above cleared up.
>>>>>>>>>
>>>>>>>>>> VC0- (the left camera stream), enc= oding group=3DEG0, view=3Dtable,
>>>>>>>>>> MaxCaptures=3D2
>>>>>>>>>>
>>>>>>>>>>     VC1- (the = center camera stream), encoding group=3DEG0,
>>>>>>>>>> view=3Dtable,
>>>>>>>>>> MaxCaptures=3D2
>>>>>>>>>>
>>>>>>>>>>     VC2- (the = right camera stream), encoding group=3DEG0,
>> view=3Dtable.
>>>>>>>>>> MaxCaptures=3D2
>>>>>>>>>>
>>>>>>>>>> VC3- (the left camera stream), enc= oding group=3DEG1, view=3Dtable,
>>>>>>>>>> MaxCaptures=3D2
>>>>>>>>>>
>>>>>>>>>>     VC4- (the = center camera stream), encoding group=3DEG1,
>>>>>>>>>> view=3Dtable,
>>>>>>>>>> MaxCaptures=3D2
>>>>>>>>>>
>>>>>>>>>>     VC5- (the = right camera stream), encoding group=3DEG1,
>> view=3Dtable.
>>>>>>>>>> MaxCaptures=3D2
>>>>>>>>>>
>>>>>>>>>> Where EG0 will be for H.264 and EG= 1 will be for VP8 and two
>>>>>>>>>> scene views
>>>>>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)?
>>>>>>>>>>
>>>>>>>>>     ... snip ... >>>>>>>>>
>>>>>>>>> ______________________________________= _________
>>>>>>>>> clue mailing list
>>>>>>>>> clue@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>> _______________________________________________ >>>>>> clue mailing list
>>>>>> clue@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>> _______________________________________________
>>>>> clue mailing list
>>>>> clue@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>
>>>> _______________________________________________
>>>> clue mailing list
>>>> clue@ietf.org
>>>> htt= ps://www.ietf.org/mailman/listinfo/clue
>>>>
>>> _______________________________________________
>>> clue mailing 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_b3fameejua53wo4wosowtaw31416803191049emailandroidcom_-- From nobody Sun Nov 23 20:45: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 3F6C91A1BCA for ; Sun, 23 Nov 2014 20:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.719 X-Spam-Level: ** X-Spam-Status: No, score=2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 4V6hAnERy9e8 for ; Sun, 23 Nov 2014 20:45:35 -0800 (PST) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED73A1A1BC6 for ; Sun, 23 Nov 2014 20:45:34 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-06v.sys.comcast.net with comcast id KGlS1p00454zqzk01Glas4; Mon, 24 Nov 2014 04:45:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-11v.sys.comcast.net with comcast id KGlZ1p00A3Ge9ey01GlZYR; Mon, 24 Nov 2014 04:45:34 +0000 Message-ID: <5472B7ED.2060000@alum.mit.edu> Date: Sun, 23 Nov 2014 23:45:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> <544EE990.5060607@nteczone.com> <0cab01cff7b8$c616cd60$52446820$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5F52@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6258@CRPMBOXPRD08.polycom.com> <00eb01cffeb8$41829c30$c487d490$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B6771@CRPMBOXPRD08.polycom.com> <013a01cffed0$926aa8f0$b73ffad0$@gmail.com> <546424B1.7010408@alum.mit.edu> <546EB087.1060204@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D52E4D5@ESESSMB209.ericsson.se> <546ED5CC.5020807@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D52E555@ESESSMB209.ericsson.se> <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFDEDC@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFDEDC@CRPMBOXPRD08.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=q20140121; t=1416804334; bh=HxQ+ps20wH01y2ifmQGvaHy4qIiMfO/0SnxIwkIv21k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mjgt8zuV6FYr8QhhE+FyfoBgKGy4RodI2ouRF8lDAJVAUQKdYbf31qz4Hh8kkwMoL b9HXLTKmxy3Rwbh1I3t2vhP68m+qUtw9ZS4xC+uOB8Puj3xgTlIQwZNCYiu+9alfa+ 3TsIidvW3EDt7bhC569VKnIl5iTXUW2j2dA5hfrLvZKLwsZXNHPX/bV6689/P5EaOF GUGpABshw1uVuHj1/6WuQMfuz/qOAbG+EwH0tCPb8sgqQ8iPOQTiptGMcwT5Qz59P1 1E3gzGJC5qHU2XelSJH34cD4DqUdCDF8LJ++Jp7IYkKTlr606DwzMkH2j7KFrPVhMd el/QYQ53BRAUg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/BgTicJ4T8QzLa-85Q-ucV79HPCE Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 04:45:38 -0000 On 11/21/14 9:52 AM, Duckworth, Mark wrote: > Yes, the people in the room at IETF 91 were clearly in favor of removing the CLUE simulcast feature enabled by "Max Capture Encodings" > 1. A reason to remove it is to avoid interop issue which could arise by having two different ways to do simulcast that don't interop with each other. I think I was the only one in the room arguing for keeping the clue mechanism (while of course the other one could also be used.) IMO both mechanisms have unique advantages over the other. But I do appreciate the interop argument. And I was the only one on that side of the issue. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: Friday, November 21, 2014 1:21 AM >> To: Christian Groves; clue@ietf.org >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >> >> Hi, >> >>> Yes, I thought the assumption was nothing in CLUE prevented the use of >> the generic >simulcast draft. >> >> It was more a timing issue, as we didn't want to delay the CLUE work when it >> was unsure whether the simulcast was going to be adopted. >> >>> I'm wondering why the adoption of that meant part of CLUE was removed >> (at least >as I understand from the notes)? >> >> As far as I remember, yes. Nobody could come up with a reason why it >> should be kept. >> >> Regards, >> >> Christer >> >> >> On 21/11/2014 4:58 PM, Christer Holmberg wrote: >>> Hi, >>> >>> The generic simulcast draft was adopted in MMUSIC, and the idea is that it >> will be used also if someone wants to provide simulcast for CLUE. >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: 21 November 2014 05:25 >>> To: clue@ietf.org >>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>> >>> What's the status of the simultcast issue after the meeting? I saw some >> meeting notes to suggest that it would be removed from CLUE. I certainly >> didn't expect that from the discussions on the list. >>> >>> Regards, Christian >>> >>> On 13/11/2014 2:25 PM, Paul Kyzivat wrote: >>>> If an sdp-based mechanism is published that allows simulcast in a >>>> single m-line, then clue gets to take advantage of that *for free*. I >>>> don't know that we need to say anything about that. >>>> >>>> The question we have to ask is: do we want to remove the >>>> clue-specific mechanism that is already present in our data model? >>>> >>>> To that I will add the corollary question: is there any cost to >>>> having that option in there? >>>> >>>> I can't see any cost. >>>> - Advertisers don't have to use it in their advertisements. >>>> - Consumers can't use it in Configure if it wasn't in the >>>> advertisement >>>> - Consumers don't have to use it if it is in the advertisement. >>>> >>>> So I see no harm in leaving it in. And some potential benefit to >>>> having it there. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 11/12/14 1:29 PM, Roni Even wrote: >>>>> Hi, >>>>> This is what started the discussion. If we do not have SDP based >>>>> simulcast based on unified plan, the only semantics is an encoding >>>>> per m-line. We started the discussion based on this assumption that >>>>> we can do simulcast in CLUE using an encoding per m-line and can >>>>> bundle them Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] >>>>>> Sent: 12 November, 2014 11:03 PM >>>>>> To: Duckworth, Mark; Roni Even >>>>>> Cc: clue@ietf.org >>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>> Yes, I'd have thought ideally multiple simulcast qualities, repair >>>>>> streams >>>>> etc >>>>>> would be defined under a single m-line and hence be a single >>>>>> encoding from CLUE's perspective. That matches the unified plan and >>>>>> the proposal in >>>>> draft- >>>>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it >>>>>> would mean that negotiating simulcast qualities, repair flows etc >>>>>> would be purely an >>>>> SDP >>>>>> issue and wouldn't impact CLUE. >>>>>> >>>>>> Rob >>>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, >>>>>> Mark >>>>>> Sent: 12 November 2014 10:54 >>>>>> To: Roni Even >>>>>> Cc: clue@ietf.org >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>> Hi, >>>>>> >>>>>> I don't understand why simulcast would need separate encoding >> groups. >>>>>> >>>>>> Whether an MC maps to two m-lines or one m-line with a=simulcast is >>>>>> up to the consumer, and specified in the configure message sent >>>>>> from consumer to provider. The mapping is done via the encoding ID >>>>>> labels which link media captures to m-lines. At least that is how >>>>>> I see it. >>>>>> >>>>>> Would you say retransmission streams are a separate issue from >>>>>> simulcast? >>>>> Or >>>>>> are they similar enough that it is really the same issue? Do SVC >>>>>> layered >>>>> codec >>>>>> streams also fall into this category? >>>>>> >>>>>> Sounds like we do need some more discussion about this. My first >>>>>> thought >>>>> is >>>>>> we should cover this in the signaling document. >>>>>> >>>>>> Mark >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>>>> Sent: Wednesday, November 12, 2014 10:36 AM >>>>>>> To: Duckworth, Mark >>>>>>> Cc: clue@ietf.org >>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>>> >>>>>>> Hi, >>>>>>> This will work when we have a single encoding per m-line in the >>>>>>> SDP and I think it requires that each simulcast set will be in >>>>>>> separate encoding group . Still it will provide less functionality >>>>>>> than the one proposed in the simulcast proposal that will be >>>>>>> discussed in MMUSIC If simulcast in SDP will progress using the >>>>>>> unified plan where we have all encodings in one m-line we will >>>>>>> need to specify that if an MC have max capture encoding >1 will it >>>>>>> mean that it will map to two m-lines or will it use a configuration from >> an SDP description a=simulcast. >>>>>>> >>>>>>> We will need to see how it works with retransmission if we specify >>>>>>> a retransmission RTP stream as an individual encoding. >>>>>>> >>>>>>> Roni >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] >>>>>>>> Sent: 06 November, 2014 9:45 PM >>>>>>>> To: Roni Even >>>>>>>> Cc: clue@ietf.org >>>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>>>> >>>>>>>> Hi Roni, >>>>>>>> Do you still have questions about the way simulcast is handled in >>>>>>>> the framework, regarding the attribute "Max capture encodings" >>>>>>>> and >>>>>>> configuring >>>>>>>> multiple encodings per capture? I was hoping we could resolve it >>>>>>>> on the >>>>>>> list, or >>>>>>>> do you think we need to talk about it in Honolulu? >>>>>>>> Regards, >>>>>>>> Mark >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>> Duckworth, >>>>>>> Mark >>>>>>>>> Sent: Monday, November 03, 2014 10:52 PM >>>>>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni >>>>>>>>>> Even >>>>>>>>>> Sent: Monday, November 03, 2014 5:52 PM >>>>>>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>> Christian Groves >>>>>>>>>>> Sent: 28 October, 2014 2:56 AM >>>>>>>>>>> To: clue@ietf.org >>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>>> >>>>>>>>>>> Hello Roni, >>>>>>>>>>> >>>>>>>>>>> As I mentioned in my original reply I think the RTP based >>>>>>>>>>> simulcast >>>>>>>>> method >>>>>>>>>> is >>>>>>>>>>> probably the cleanest approach. There would be nothing >>>>>>>>>>> stopping a CLUE endpoint implementing it when it becomes >>>>>>>>>>> available (like many other RTP features). Using CLUE for >>>>>>>>>>> simulcast I think is possible for most >>>>>>>>>> scenarios. The >>>>>>>>>>> more complicated the scenarios the more MCs/encodings an >>>>>>> endpoint >>>>>>>>> will >>>>>>>>>>> need to describe the situation. >>>>>>>>>>> >>>>>>>>>>> Please see my response below. >>>>>>>>>>> >>>>>>>>>>> Regards, Christian >>>>>>>>>>> >>>>>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: >>>>>>>>>>>> Hi Paul, >>>>>>>>>>>> >>>>>>>>>>>> If we want to be able to differentiate between simulcast and >>>>>>>>>>>> switched capture, for example if we have a three camera >>>>>>>>>>>> system that can send three MCs each with two encodings >>>>>>>>>>>> (simulcast) and a switched capture (loudest speaker or two >>>>>>>>>>>> loudest speakers out of three) using the same simulcast >>>>>>>>>>>> option for the each MC currently sent. In this case we can >>>>>>>>>>>> have an MC with two encodings and an MCC with the three >> MCs. >>>>>>>>>>>> This >>>>>>>>> will >>>>>>>>>>>> require us to clarify that having multiple individual >>>>>>>>>>>> encodings in MC is simulcast and not switched and in MCC it >>>>>>>>>>>> is switched and not >>>>>>>>> simulcast. >>>>>>>>>>> [CNG] I don't understand exactly what the issue is here? Could >>>>>>>>>>> you use >>>>>>>>> some >>>>>>>>>>> pseudo syntax to explain what you're wanting to advertise? You >>>>>>>>>>> say in >>>>>>>>> the first >>>>>>>>>>> sentence the switched capture uses simulcast but then in the >>>>>>>>>>> last >>>>>>>>> sentence you >>>>>>>>>>> say the MCC is switched and not simulcast. I would think that >>>>>>>>>>> an MCC can >>>>>>>>> still >>>>>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts >>>>>>>>>>> whatever source >>>>>>>>> is >>>>>>>>>>> switched into the media stream. >>>>>>>>>>> If you want a pure switched MCC just set maxCaptureEncodings >>>>>>>>>>> to >>>>>>>>>>> 1 >>>>>>>>> against the >>>>>>>>>>> MCC. >>>>>>>>>>> If you want a simultcast MCC just set maxCaptureEncodings to >>>>>>>>>>>> =2 >>>>>>>>> against the >>>>>>>>>>> MCC. >>>>>>>>>> [Roni Even] The thing is that I am not sure how to advertise >>>>>>>>>> this >>>>>>> example. >>>>>>>>>> The advertisement has two scene views: >>>>>>>>>> 1. Scene view with VC0, VC1, VC2 each with two simulcast >>>>>>>>>> streams >>>>> 2. >>>>>>>>>> Scene view MCC3 as represented bellow >>>>>>>>>> >>>>>>>>>> The different MCs will be: >>>>>>>>>> >>>>>>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max >> Capture >>>>>>>>> Encodings"? >>>>>>>>> Don't confuse this with the MCC attribute MaxCaptures which >>>>>>>>> means >>>>>>> "Max >>>>>>>>> number of Captures within a MCC". >>>>>>>>> >>>>>>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>>>>>> view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC2- (the right camera stream), encoding group=EG0, >> view=table. >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=EG0, view=room, >>>>>>>>> MaxCaptures=2 >>>>>>>>> >>>>>>>>> [Duckworth, Mark] It isn't clear if you really mean "max capture >>>>>>> encodings" >>>>>>>>> or >>>>>>>>> "max number of captures within a MCC". Those are two different >>>>> things. >>>>>>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. >>>>>>>>> [Duckworth, Mark] It depends how the consumer configures it. >>>>>>>>> The provider advertisement says it supports simulcast, so the >>>>>>>>> consumer can decide to use it or not. >>>>>>>>> >>>>>>>>>> What about MCC3? >>>>>>>>>> Is it multicast from one of the cameras or is it 2 MCs out of >>>>>>>>>> the three? (I assume it is the first since the view is room) >>>>>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three >>>>>>>>> simultaneously only if it is composed, not if it is switched. >>>>>>>>> The provider can give more information, if it wants to, with the >>>>>>>>> MCC attribute "max number of captures within a MCC". >>>>>>>>> >>>>>>>>>> What if in the above example MaxCaptures=4 can it be for >>>>>>>>>> example VC0, >>>>>>>>> VC1 >>>>>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and one >>>>>>>>>> of them is >>>>>>>>> simulcast? >>>>>>>>> >>>>>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single >> "conceptual" >>>>>>>>> capture. >>>>>>>>> It sounds like you are talking about a switched case, not a >>>>>>>>> composed case, so let's say MCC3 has the attribute "max number >>>>>>>>> of captures within >>>>>>> a >>>>>>>> MCC" = 1. >>>>>>>>> Now let's also suppose MCC3 has "max capture encodings" = 2. >>>>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, for >>>>>>>>> the two encodings. Then the provider decides when to switch >>>>>>>>> among VC0, VC1, and VC2, and whichever one the provider is >>>>>>>>> sending for >>>>>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast at >>>>>>>>> those two resolutions. >>>>>>>>> >>>>>>>>>> What I am trying to say is that using implied simulcast require >>>>>>>>>> text explaining when a consumer can understand that the >>>>>>>>>> advertisement is simulcast and not something else. >>>>>>>>>> The other approach may be to have an attribute for an MC and >>>>>>>>>> MCC that >>>>>>>>> will >>>>>>>>>> explicitly say that this is a simulcast offer. >>>>>>>>> [Duckworth, Mark] I think the advertisement is clear to the >>>>>>>>> consumer without any additional text or attributes added to the >>>>>>>>> framework. It is already explicit, with the attribute "max >>>>>>>>> capture encodings". If it is >1, then the advertisement is >>>>>>>>> offering >>>>>> simulcast. >>>>>>>>>> BTW: I think that the implied solution works when the >>>>>>>>>> individual encodings are the same (spatial or different codces) >>>>>>>>>> what if we the provider can send >>>>>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be >>>>>>>>>> four different encodings but not all combinations allowed. How >>>>>>>>>> to represent it in an advertisement? Is it : >>>>>>>>> [Duckworth, Mark] I can consider this case after we get the >>>>>>>>> first case above cleared up. >>>>>>>>> >>>>>>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>>>>>> view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC2- (the right camera stream), encoding group=EG0, >> view=table. >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC3- (the left camera stream), encoding group=EG1, view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC4- (the center camera stream), encoding group=EG1, >>>>>>>>>> view=table, >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> VC5- (the right camera stream), encoding group=EG1, >> view=table. >>>>>>>>>> MaxCaptures=2 >>>>>>>>>> >>>>>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two >>>>>>>>>> scene views >>>>>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? >>>>>>>>>> >>>>>>>>> ... snip ... >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> clue mailing list >>>>>>>>> clue@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Nov 23 23:18: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 4760A1A1AEC for ; Sun, 23 Nov 2014 23:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.054 X-Spam-Level: ** X-Spam-Status: No, score=2.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 UBBKdSQFNLTn for ; Sun, 23 Nov 2014 23:17:56 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A0C1A1A73 for ; Sun, 23 Nov 2014 23:17:56 -0800 (PST) Received: from ppp118-209-241-2.lns20.mel8.internode.on.net ([118.209.241.2]:60105 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XsntL-0008Nm-Qu; Mon, 24 Nov 2014 18:17:00 +1100 Message-ID: <5472DB9A.80708@nteczone.com> Date: Mon, 24 Nov 2014 18:17:46 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/1fIXirt7URShIhQ0CEZCcfN7tjw Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 07:18:00 -0000 Hello Mark, You're right, I wasn't thinking about didn't captures using the encoding group. I was trying to see what the impact of this change was. My comment comes out of the text in clause 9.3 of the framework, "Any of the Captures that use a particular Encoding Group can be encoded according to any of the Individual Encodings in the group. If there are multiple Individual Encodings in the group, then the Consumer can configure the Provider, via a Configure message, to encode a single Media Capture into multiple different Capture Encodings at the same time, subject to the Max Capture Encodings constraint, with each capture encoding following the constraints of a different Individual Encoding." If the encoding group was used for simulcast the maxgroupbandwidth could be used to apply to the simulcast streams. If we now move this out mechanism out, is there an equivalent for the simulcast cast SDP? b= ? With respect to multiple captures using one encoding group, I didn't see in the draft where it says that a media consumer can only choose one individual encoding (i.e. as identified by a=label) for one of the captures referencing the encoding group (i.e. an individual encoding can't be used more than once). Does it make sense for two captures (outside a MCC) to share an individual encoding? Regards, Christian On 24/11/2014 3:26 PM, Duckworth, Mark wrote: > Hi Christian, > I don't follow you. The original point of encoding groups, which > still holds true, is that multiple media captures can use the same > encoding group. So there is still a use for an encoding group, which > can have multiple individual encodings, each of which can be > configured to encode a different capture. > So maybe I'm not understanding your concern? > Mark > > > -------- Original message -------- > From: Christian Groves > Date:11/23/2014 7:28 PM (GMT-05:00) > To: "Duckworth, Mark" , Christer Holmberg > , clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > I don't think its a trivial change. I assume if we remove this then a > consumer must always choose "one" encoding from an encoding group? It > also changes the semantic of the encoding group to sets of mutually > exclusive encodings. Then does the "maxgroupbandwidth" also become > meaningless for CLUE as from a CLUE perspective only one encoding will > be chosen? If we decide to remove simulcast then we should remove it > completely and not rely on some functionality in SDP and others in CLUE. > > Regards, Christian > > > > On 22/11/2014 1:52 AM, Duckworth, Mark wrote: > > Yes, the people in the room at IETF 91 were clearly in favor of > removing the CLUE simulcast feature enabled by "Max Capture Encodings" > > 1. A reason to remove it is to avoid interop issue which could > arise by having two different ways to do simulcast that don't interop > with each other. > > > > Mark > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer > Holmberg > >> Sent: Friday, November 21, 2014 1:21 AM > >> To: Christian Groves; clue@ietf.org > >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >> > >> Hi, > >> > >>> Yes, I thought the assumption was nothing in CLUE prevented the use of > >> the generic >simulcast draft. > >> > >> It was more a timing issue, as we didn't want to delay the CLUE > work when it > >> was unsure whether the simulcast was going to be adopted. > >> > >>> I'm wondering why the adoption of that meant part of CLUE was removed > >> (at least >as I understand from the notes)? > >> > >> As far as I remember, yes. Nobody could come up with a reason why it > >> should be kept. > >> > >> Regards, > >> > >> Christer > >> > >> > >> On 21/11/2014 4:58 PM, Christer Holmberg wrote: > >>> Hi, > >>> > >>> The generic simulcast draft was adopted in MMUSIC, and the idea is > that it > >> will be used also if someone wants to provide simulcast for CLUE. > >>> Regards, > >>> > >>> Christer > >>> > >>> -----Original Message----- > >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >>> Groves > >>> Sent: 21 November 2014 05:25 > >>> To: clue@ietf.org > >>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>> > >>> What's the status of the simultcast issue after the meeting? I saw > some > >> meeting notes to suggest that it would be removed from CLUE. I > certainly > >> didn't expect that from the discussions on the list. > >>> Regards, Christian > >>> > >>> On 13/11/2014 2:25 PM, Paul Kyzivat wrote: > >>>> If an sdp-based mechanism is published that allows simulcast in a > >>>> single m-line, then clue gets to take advantage of that *for free*. I > >>>> don't know that we need to say anything about that. > >>>> > >>>> The question we have to ask is: do we want to remove the > >>>> clue-specific mechanism that is already present in our data model? > >>>> > >>>> To that I will add the corollary question: is there any cost to > >>>> having that option in there? > >>>> > >>>> I can't see any cost. > >>>> - Advertisers don't have to use it in their advertisements. > >>>> - Consumers can't use it in Configure if it wasn't in the > >>>> advertisement > >>>> - Consumers don't have to use it if it is in the advertisement. > >>>> > >>>> So I see no harm in leaving it in. And some potential benefit to > >>>> having it there. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 11/12/14 1:29 PM, Roni Even wrote: > >>>>> Hi, > >>>>> This is what started the discussion. If we do not have SDP based > >>>>> simulcast based on unified plan, the only semantics is an encoding > >>>>> per m-line. We started the discussion based on this assumption that > >>>>> we can do simulcast in CLUE using an encoding per m-line and can > >>>>> bundle them Roni > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] > >>>>>> Sent: 12 November, 2014 11:03 PM > >>>>>> To: Duckworth, Mark; Roni Even > >>>>>> Cc: clue@ietf.org > >>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > >>>>>> > >>>>>> Yes, I'd have thought ideally multiple simulcast qualities, repair > >>>>>> streams > >>>>> etc > >>>>>> would be defined under a single m-line and hence be a single > >>>>>> encoding from CLUE's perspective. That matches the unified plan and > >>>>>> the proposal in > >>>>> draft- > >>>>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it > >>>>>> would mean that negotiating simulcast qualities, repair flows etc > >>>>>> would be purely an > >>>>> SDP > >>>>>> issue and wouldn't impact CLUE. > >>>>>> > >>>>>> Rob > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, > >>>>>> Mark > >>>>>> Sent: 12 November 2014 10:54 > >>>>>> To: Roni Even > >>>>>> Cc: clue@ietf.org > >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I don't understand why simulcast would need separate encoding > >> groups. > >>>>>> Whether an MC maps to two m-lines or one m-line with a=simulcast is > >>>>>> up to the consumer, and specified in the configure message sent > >>>>>> from consumer to provider. The mapping is done via the encoding ID > >>>>>> labels which link media captures to m-lines. At least that is how > >>>>>> I see it. > >>>>>> > >>>>>> Would you say retransmission streams are a separate issue from > >>>>>> simulcast? > >>>>> Or > >>>>>> are they similar enough that it is really the same issue? Do SVC > >>>>>> layered > >>>>> codec > >>>>>> streams also fall into this category? > >>>>>> > >>>>>> Sounds like we do need some more discussion about this. My first > >>>>>> thought > >>>>> is > >>>>>> we should cover this in the signaling document. > >>>>>> > >>>>>> Mark > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] > >>>>>>> Sent: Wednesday, November 12, 2014 10:36 AM > >>>>>>> To: Duckworth, Mark > >>>>>>> Cc: clue@ietf.org > >>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > >>>>>>> > >>>>>>> Hi, > >>>>>>> This will work when we have a single encoding per m-line in the > >>>>>>> SDP and I think it requires that each simulcast set will be in > >>>>>>> separate encoding group . Still it will provide less functionality > >>>>>>> than the one proposed in the simulcast proposal that will be > >>>>>>> discussed in MMUSIC If simulcast in SDP will progress using the > >>>>>>> unified plan where we have all encodings in one m-line we will > >>>>>>> need to specify that if an MC have max capture encoding >1 will it > >>>>>>> mean that it will map to two m-lines or will it use a > configuration from > >> an SDP description a=simulcast. > >>>>>>> We will need to see how it works with retransmission if we specify > >>>>>>> a retransmission RTP stream as an individual encoding. > >>>>>>> > >>>>>>> Roni > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > >>>>>>>> Sent: 06 November, 2014 9:45 PM > >>>>>>>> To: Roni Even > >>>>>>>> Cc: clue@ietf.org > >>>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > >>>>>>>> > >>>>>>>> Hi Roni, > >>>>>>>> Do you still have questions about the way simulcast is handled in > >>>>>>>> the framework, regarding the attribute "Max capture encodings" > >>>>>>>> and > >>>>>>> configuring > >>>>>>>> multiple encodings per capture? I was hoping we could resolve it > >>>>>>>> on the > >>>>>>> list, or > >>>>>>>> do you think we need to talk about it in Honolulu? > >>>>>>>> Regards, > >>>>>>>> Mark > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > >>>>>>>>> Duckworth, > >>>>>>> Mark > >>>>>>>>> Sent: Monday, November 03, 2014 10:52 PM > >>>>>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org > >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni > >>>>>>>>>> Even > >>>>>>>>>> Sent: Monday, November 03, 2014 5:52 PM > >>>>>>>>>> To: 'Christian Groves'; clue@ietf.org > >>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > >>>>>>>>>>> Christian Groves > >>>>>>>>>>> Sent: 28 October, 2014 2:56 AM > >>>>>>>>>>> To: clue@ietf.org > >>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>>>>>> > >>>>>>>>>>> Hello Roni, > >>>>>>>>>>> > >>>>>>>>>>> As I mentioned in my original reply I think the RTP based > >>>>>>>>>>> simulcast > >>>>>>>>> method > >>>>>>>>>> is > >>>>>>>>>>> probably the cleanest approach. There would be nothing > >>>>>>>>>>> stopping a CLUE endpoint implementing it when it becomes > >>>>>>>>>>> available (like many other RTP features). Using CLUE for > >>>>>>>>>>> simulcast I think is possible for most > >>>>>>>>>> scenarios. The > >>>>>>>>>>> more complicated the scenarios the more MCs/encodings an > >>>>>>> endpoint > >>>>>>>>> will > >>>>>>>>>>> need to describe the situation. > >>>>>>>>>>> > >>>>>>>>>>> Please see my response below. > >>>>>>>>>>> > >>>>>>>>>>> Regards, Christian > >>>>>>>>>>> > >>>>>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: > >>>>>>>>>>>> Hi Paul, > >>>>>>>>>>>> > >>>>>>>>>>>> If we want to be able to differentiate between simulcast and > >>>>>>>>>>>> switched capture, for example if we have a three camera > >>>>>>>>>>>> system that can send three MCs each with two encodings > >>>>>>>>>>>> (simulcast) and a switched capture (loudest speaker or two > >>>>>>>>>>>> loudest speakers out of three) using the same simulcast > >>>>>>>>>>>> option for the each MC currently sent. In this case we can > >>>>>>>>>>>> have an MC with two encodings and an MCC with the three > >> MCs. > >>>>>>>>>>>> This > >>>>>>>>> will > >>>>>>>>>>>> require us to clarify that having multiple individual > >>>>>>>>>>>> encodings in MC is simulcast and not switched and in MCC it > >>>>>>>>>>>> is switched and not > >>>>>>>>> simulcast. > >>>>>>>>>>> [CNG] I don't understand exactly what the issue is here? Could > >>>>>>>>>>> you use > >>>>>>>>> some > >>>>>>>>>>> pseudo syntax to explain what you're wanting to advertise? You > >>>>>>>>>>> say in > >>>>>>>>> the first > >>>>>>>>>>> sentence the switched capture uses simulcast but then in the > >>>>>>>>>>> last > >>>>>>>>> sentence you > >>>>>>>>>>> say the MCC is switched and not simulcast. I would think that > >>>>>>>>>>> an MCC can > >>>>>>>>> still > >>>>>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts > >>>>>>>>>>> whatever source > >>>>>>>>> is > >>>>>>>>>>> switched into the media stream. > >>>>>>>>>>> If you want a pure switched MCC just set maxCaptureEncodings > >>>>>>>>>>> to > >>>>>>>>>>> 1 > >>>>>>>>> against the > >>>>>>>>>>> MCC. > >>>>>>>>>>> If you want a simultcast MCC just set maxCaptureEncodings to > >>>>>>>>>>>> =2 > >>>>>>>>> against the > >>>>>>>>>>> MCC. > >>>>>>>>>> [Roni Even] The thing is that I am not sure how to advertise > >>>>>>>>>> this > >>>>>>> example. > >>>>>>>>>> The advertisement has two scene views: > >>>>>>>>>> 1. Scene view with VC0, VC1, VC2 each with two simulcast > >>>>>>>>>> streams > >>>>> 2. > >>>>>>>>>> Scene view MCC3 as represented bellow > >>>>>>>>>> > >>>>>>>>>> The different MCs will be: > >>>>>>>>>> > >>>>>>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, > >>>>>>>>>> MaxCaptures=2 > >>>>>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max > >> Capture > >>>>>>>>> Encodings"? > >>>>>>>>> Don't confuse this with the MCC attribute MaxCaptures which > >>>>>>>>> means > >>>>>>> "Max > >>>>>>>>> number of Captures within a MCC". > >>>>>>>>> > >>>>>>>>>> VC1- (the center camera stream), encoding group=EG0, > >>>>>>>>>> view=table, > >>>>>>>>>> MaxCaptures=2 > >>>>>>>>>> > >>>>>>>>>> VC2- (the right camera stream), encoding group=EG0, > >> view=table. > >>>>>>>>>> MaxCaptures=2 > >>>>>>>>>> > >>>>>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=EG0, view=room, > >>>>>>>>> MaxCaptures=2 > >>>>>>>>> > >>>>>>>>> [Duckworth, Mark] It isn't clear if you really mean "max capture > >>>>>>> encodings" > >>>>>>>>> or > >>>>>>>>> "max number of captures within a MCC". Those are two different > >>>>> things. > >>>>>>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. > >>>>>>>>> [Duckworth, Mark] It depends how the consumer configures it. > >>>>>>>>> The provider advertisement says it supports simulcast, so the > >>>>>>>>> consumer can decide to use it or not. > >>>>>>>>> > >>>>>>>>>> What about MCC3? > >>>>>>>>>> Is it multicast from one of the cameras or is it 2 MCs out of > >>>>>>>>>> the three? (I assume it is the first since the view is room) > >>>>>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three > >>>>>>>>> simultaneously only if it is composed, not if it is switched. > >>>>>>>>> The provider can give more information, if it wants to, with the > >>>>>>>>> MCC attribute "max number of captures within a MCC". > >>>>>>>>> > >>>>>>>>>> What if in the above example MaxCaptures=4 can it be for > >>>>>>>>>> example VC0, > >>>>>>>>> VC1 > >>>>>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and one > >>>>>>>>>> of them is > >>>>>>>>> simulcast? > >>>>>>>>> > >>>>>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single > >> "conceptual" > >>>>>>>>> capture. > >>>>>>>>> It sounds like you are talking about a switched case, not a > >>>>>>>>> composed case, so let's say MCC3 has the attribute "max number > >>>>>>>>> of captures within > >>>>>>> a > >>>>>>>> MCC" = 1. > >>>>>>>>> Now let's also suppose MCC3 has "max capture encodings" = 2. > >>>>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, for > >>>>>>>>> the two encodings. Then the provider decides when to switch > >>>>>>>>> among VC0, VC1, and VC2, and whichever one the provider is > >>>>>>>>> sending for > >>>>>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast at > >>>>>>>>> those two resolutions. > >>>>>>>>> > >>>>>>>>>> What I am trying to say is that using implied simulcast require > >>>>>>>>>> text explaining when a consumer can understand that the > >>>>>>>>>> advertisement is simulcast and not something else. > >>>>>>>>>> The other approach may be to have an attribute for an MC and > >>>>>>>>>> MCC that > >>>>>>>>> will > >>>>>>>>>> explicitly say that this is a simulcast offer. > >>>>>>>>> [Duckworth, Mark] I think the advertisement is clear to the > >>>>>>>>> consumer without any additional text or attributes added to the > >>>>>>>>> framework. It is already explicit, with the attribute "max > >>>>>>>>> capture encodings". If it is >1, then the advertisement is > >>>>>>>>> offering > >>>>>> simulcast. > >>>>>>>>>> BTW: I think that the implied solution works when the > >>>>>>>>>> individual encodings are the same (spatial or different codces) > >>>>>>>>>> what if we the provider can send > >>>>>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be > >>>>>>>>>> four different encodings but not all combinations allowed. How > >>>>>>>>>> to represent it in an advertisement? Is it : > >>>>>>>>> [Duckworth, Mark] I can consider this case after we get the > >>>>>>>>> first case above cleared up. > >>>>>>>>> > >>>>>>>>>> VC0- (the left camera stream), encoding group=EG0, view=table, > >>>>>>>>>> MaxCaptures=2 > >>>>>>>>>> > >>>>>>>>>> VC1- (the center camera stream), encoding group=EG0, > >>>>>>>>>> view=table, > >>>>>>>>>> MaxCaptures=2 > >>>>>>>>>> > >>>>>>>>>> VC2- (the right camera stream), encoding group=EG0, > >> view=table. > >>>>>>>>>> MaxCaptures=2 > >>>>>>>>>> > >>>>>>>>>> VC3- (the left camera stream), encoding group=EG1, view=table, > >>>>>>>>>> MaxCaptures=2 > >>>>>>>>>> > >>>>>>>>>> VC4- (the center camera stream), encoding group=EG1, > >>>>>>>>>> view=table, > >>>>>>>>>> MaxCaptures=2 > >>>>>>>>>> > >>>>>>>>>> VC5- (the right camera stream), encoding group=EG1, > >> view=table. > >>>>>>>>>> MaxCaptures=2 > >>>>>>>>>> > >>>>>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two > >>>>>>>>>> scene views > >>>>>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? > >>>>>>>>>> > >>>>>>>>> ... snip ... > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> clue mailing list > >>>>>>>>> clue@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Nov 24 09:25: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 6A1611A6FFF for ; Mon, 24 Nov 2014 09:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.954 X-Spam-Level: * X-Spam-Status: No, score=1.954 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, FRT_BELOW2=2.154, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 D-AqE8KoEJZC for ; Mon, 24 Nov 2014 09:24:58 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9CB21A854B for ; Mon, 24 Nov 2014 09:24:50 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so5371330igb.0 for ; Mon, 24 Nov 2014 09:24:49 -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=OJDiWUghXdfLEnhxlZr+/KbwMmOncNS/BUWHoZ1ryAw=; b=BfokJXuJhr79+hsIz9HpXfkNJzNxHn+zExJ1pkNJZwJ9UU8C+hkyO7cN3tIHUq+vck AZ2RguOvhyDHyTTEkvNUad5jg1PHbmm2opJIqHN/NFwsR3icqDa5qU+sYGCBxBjI4yK6 biIFieRFUG1gEfJTwr3DQlUga3Cg4SVWawGbwcaHVlk5DDj/ahEvvO+E/ZjPafprxce8 T4TdDSfRsJhdy7KwJSLpBFYv2HfuUM4eWVA4tiYzw8T6QwEO7HkuSgmWVrBemQocl50n qf4ZqA5nC4066pmUumKGcAH1H1W1wLBES3bFlESKO4U8+lcKK6md+IiiO25Xcq7IsPEP sNQg== X-Received: by 10.107.16.88 with SMTP id y85mr19117476ioi.56.1416849889842; Mon, 24 Nov 2014 09:24:49 -0800 (PST) Received: from RoniE (209-82-80-116.dedicated.allstream.net. [209.82.80.116]) by mx.google.com with ESMTPSA id v91sm7849043iov.15.2014.11.24.09.24.44 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 24 Nov 2014 09:24:48 -0800 (PST) From: "Roni Even" To: "'Christian Groves'" , "'Duckworth, Mark'" , References: <5472DB9A.80708@nteczone.com> In-Reply-To: <5472DB9A.80708@nteczone.com> Date: Mon, 24 Nov 2014 19:24:43 +0200 Message-ID: <007801d0080b$8b6b1e60$a2415b20$@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: AQMNlD5y/Er04l+N7qx1bZ1/jnz/ogGWsqjqmeg3suA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/WK73kMdEjyB85lAaRL2n-YtTyik Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:25:02 -0000 Hi Christian, The issues were that there is no single defined semantics when having multiple individual encoding to a media capture. If we are talking about simulcast it will mean that each of the multiple multicast encoding will have its own m-line in the SDP and this is not the direction that MMUSIC is taking. The MMUSIC direction is based on the "unified" plan where all encodings from the same source should be in the same m-line. Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 24 November, 2014 9:18 AM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > Hello Mark, > > You're right, I wasn't thinking about didn't captures using the encoding group. I > was trying to see what the impact of this change was. My comment comes out > of the text in clause 9.3 of the framework, > > "Any of the Captures that use a particular Encoding Group can be encoded > according to any of the Individual Encodings in the group. If > there are multiple Individual Encodings in the group, then the > Consumer can configure the Provider, via a Configure message, to > encode a single Media Capture into multiple different Capture > Encodings at the same time, subject to the Max Capture Encodings > constraint, with each capture encoding following the constraints of > a different Individual Encoding." > > If the encoding group was used for simulcast the maxgroupbandwidth could be > used to apply to the simulcast streams. If we now move this out mechanism > out, is there an equivalent for the simulcast cast SDP? b= ? > > With respect to multiple captures using one encoding group, I didn't see in the > draft where it says that a media consumer can only choose one individual > encoding (i.e. as identified by a=label) for one of the captures referencing the > encoding group (i.e. an individual encoding can't be used more than once). > Does it make sense for two captures (outside a MCC) to share an individual > encoding? > > Regards, Christian > > On 24/11/2014 3:26 PM, Duckworth, Mark wrote: > > Hi Christian, > > I don't follow you. The original point of encoding groups, which > > still holds true, is that multiple media captures can use the same > > encoding group. So there is still a use for an encoding group, which > > can have multiple individual encodings, each of which can be > > configured to encode a different capture. > > So maybe I'm not understanding your concern? > > Mark > > > > > > -------- Original message -------- > > From: Christian Groves > > Date:11/23/2014 7:28 PM (GMT-05:00) > > To: "Duckworth, Mark" , Christer > Holmberg > > , clue@ietf.org > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > I don't think its a trivial change. I assume if we remove this then a > > consumer must always choose "one" encoding from an encoding group? It > > also changes the semantic of the encoding group to sets of mutually > > exclusive encodings. Then does the "maxgroupbandwidth" also become > > meaningless for CLUE as from a CLUE perspective only one encoding will > > be chosen? If we decide to remove simulcast then we should remove it > > completely and not rely on some functionality in SDP and others in CLUE. > > > > Regards, Christian > > > > > > > > On 22/11/2014 1:52 AM, Duckworth, Mark wrote: > > > Yes, the people in the room at IETF 91 were clearly in favor of > > removing the CLUE simulcast feature enabled by "Max Capture Encodings" > > > 1. A reason to remove it is to avoid interop issue which could > > arise by having two different ways to do simulcast that don't interop > > with each other. > > > > > > Mark > > > > > >> -----Original Message----- > > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer > > Holmberg > > >> Sent: Friday, November 21, 2014 1:21 AM > > >> To: Christian Groves; clue@ietf.org > > >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > >> > > >> Hi, > > >> > > >>> Yes, I thought the assumption was nothing in CLUE prevented the > > >>> use of > > >> the generic >simulcast draft. > > >> > > >> It was more a timing issue, as we didn't want to delay the CLUE > > work when it > > >> was unsure whether the simulcast was going to be adopted. > > >> > > >>> I'm wondering why the adoption of that meant part of CLUE was > > >>> removed > > >> (at least >as I understand from the notes)? > > >> > > >> As far as I remember, yes. Nobody could come up with a reason why > > >> it should be kept. > > >> > > >> Regards, > > >> > > >> Christer > > >> > > >> > > >> On 21/11/2014 4:58 PM, Christer Holmberg wrote: > > >>> Hi, > > >>> > > >>> The generic simulcast draft was adopted in MMUSIC, and the idea is > > that it > > >> will be used also if someone wants to provide simulcast for CLUE. > > >>> Regards, > > >>> > > >>> Christer > > >>> > > >>> -----Original Message----- > > >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > > >>> Groves > > >>> Sent: 21 November 2014 05:25 > > >>> To: clue@ietf.org > > >>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > >>> > > >>> What's the status of the simultcast issue after the meeting? I saw > > some > > >> meeting notes to suggest that it would be removed from CLUE. I > > certainly > > >> didn't expect that from the discussions on the list. > > >>> Regards, Christian > > >>> > > >>> On 13/11/2014 2:25 PM, Paul Kyzivat wrote: > > >>>> If an sdp-based mechanism is published that allows simulcast in a > > >>>> single m-line, then clue gets to take advantage of that *for > > >>>> free*. I don't know that we need to say anything about that. > > >>>> > > >>>> The question we have to ask is: do we want to remove the > > >>>> clue-specific mechanism that is already present in our data model? > > >>>> > > >>>> To that I will add the corollary question: is there any cost to > > >>>> having that option in there? > > >>>> > > >>>> I can't see any cost. > > >>>> - Advertisers don't have to use it in their advertisements. > > >>>> - Consumers can't use it in Configure if it wasn't in the > > >>>> advertisement > > >>>> - Consumers don't have to use it if it is in the advertisement. > > >>>> > > >>>> So I see no harm in leaving it in. And some potential benefit to > > >>>> having it there. > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> > > >>>> On 11/12/14 1:29 PM, Roni Even wrote: > > >>>>> Hi, > > >>>>> This is what started the discussion. If we do not have SDP based > > >>>>> simulcast based on unified plan, the only semantics is an > > >>>>> encoding per m-line. We started the discussion based on this > > >>>>> assumption that we can do simulcast in CLUE using an encoding > > >>>>> per m-line and can bundle them Roni > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] > > >>>>>> Sent: 12 November, 2014 11:03 PM > > >>>>>> To: Duckworth, Mark; Roni Even > > >>>>>> Cc: clue@ietf.org > > >>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > >>>>>> > > >>>>>> Yes, I'd have thought ideally multiple simulcast qualities, > > >>>>>> repair streams > > >>>>> etc > > >>>>>> would be defined under a single m-line and hence be a single > > >>>>>> encoding from CLUE's perspective. That matches the unified plan > > >>>>>> and the proposal in > > >>>>> draft- > > >>>>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective it > > >>>>>> would mean that negotiating simulcast qualities, repair flows > > >>>>>> etc would be purely an > > >>>>> SDP > > >>>>>> issue and wouldn't impact CLUE. > > >>>>>> > > >>>>>> Rob > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > > >>>>>> Duckworth, Mark > > >>>>>> Sent: 12 November 2014 10:54 > > >>>>>> To: Roni Even > > >>>>>> Cc: clue@ietf.org > > >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > >>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> I don't understand why simulcast would need separate encoding > > >> groups. > > >>>>>> Whether an MC maps to two m-lines or one m-line with > > >>>>>> a=simulcast is up to the consumer, and specified in the > > >>>>>> configure message sent from consumer to provider. The mapping > > >>>>>> is done via the encoding ID labels which link media captures to > > >>>>>> m-lines. At least that is how I see it. > > >>>>>> > > >>>>>> Would you say retransmission streams are a separate issue from > > >>>>>> simulcast? > > >>>>> Or > > >>>>>> are they similar enough that it is really the same issue? Do > > >>>>>> SVC layered > > >>>>> codec > > >>>>>> streams also fall into this category? > > >>>>>> > > >>>>>> Sounds like we do need some more discussion about this. My > > >>>>>> first thought > > >>>>> is > > >>>>>> we should cover this in the signaling document. > > >>>>>> > > >>>>>> Mark > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] > > >>>>>>> Sent: Wednesday, November 12, 2014 10:36 AM > > >>>>>>> To: Duckworth, Mark > > >>>>>>> Cc: clue@ietf.org > > >>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > >>>>>>> > > >>>>>>> Hi, > > >>>>>>> This will work when we have a single encoding per m-line in > > >>>>>>> the SDP and I think it requires that each simulcast set will > > >>>>>>> be in separate encoding group . Still it will provide less > > >>>>>>> functionality than the one proposed in the simulcast proposal > > >>>>>>> that will be discussed in MMUSIC If simulcast in SDP will > > >>>>>>> progress using the unified plan where we have all encodings in > > >>>>>>> one m-line we will need to specify that if an MC have max > > >>>>>>> capture encoding >1 will it mean that it will map to two > > >>>>>>> m-lines or will it use a > > configuration from > > >> an SDP description a=simulcast. > > >>>>>>> We will need to see how it works with retransmission if we > > >>>>>>> specify a retransmission RTP stream as an individual encoding. > > >>>>>>> > > >>>>>>> Roni > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > > >>>>>>>> Sent: 06 November, 2014 9:45 PM > > >>>>>>>> To: Roni Even > > >>>>>>>> Cc: clue@ietf.org > > >>>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > >>>>>>>> > > >>>>>>>> Hi Roni, > > >>>>>>>> Do you still have questions about the way simulcast is > > >>>>>>>> handled in the framework, regarding the attribute "Max capture > encodings" > > >>>>>>>> and > > >>>>>>> configuring > > >>>>>>>> multiple encodings per capture? I was hoping we could > > >>>>>>>> resolve it on the > > >>>>>>> list, or > > >>>>>>>> do you think we need to talk about it in Honolulu? > > >>>>>>>> Regards, > > >>>>>>>> Mark > > >>>>>>>> > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > > >>>>>>>>> Duckworth, > > >>>>>>> Mark > > >>>>>>>>> Sent: Monday, November 03, 2014 10:52 PM > > >>>>>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org > > >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > >>>>>>>>> > > >>>>>>>>>> -----Original Message----- > > >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni > > >>>>>>>>>> Even > > >>>>>>>>>> Sent: Monday, November 03, 2014 5:52 PM > > >>>>>>>>>> To: 'Christian Groves'; clue@ietf.org > > >>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > >>>>>>>>>> > > >>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > > >>>>>>>>>>> Christian Groves > > >>>>>>>>>>> Sent: 28 October, 2014 2:56 AM > > >>>>>>>>>>> To: clue@ietf.org > > >>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > >>>>>>>>>>> > > >>>>>>>>>>> Hello Roni, > > >>>>>>>>>>> > > >>>>>>>>>>> As I mentioned in my original reply I think the RTP based > > >>>>>>>>>>> simulcast > > >>>>>>>>> method > > >>>>>>>>>> is > > >>>>>>>>>>> probably the cleanest approach. There would be nothing > > >>>>>>>>>>> stopping a CLUE endpoint implementing it when it becomes > > >>>>>>>>>>> available (like many other RTP features). Using CLUE for > > >>>>>>>>>>> simulcast I think is possible for most > > >>>>>>>>>> scenarios. The > > >>>>>>>>>>> more complicated the scenarios the more MCs/encodings an > > >>>>>>> endpoint > > >>>>>>>>> will > > >>>>>>>>>>> need to describe the situation. > > >>>>>>>>>>> > > >>>>>>>>>>> Please see my response below. > > >>>>>>>>>>> > > >>>>>>>>>>> Regards, Christian > > >>>>>>>>>>> > > >>>>>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: > > >>>>>>>>>>>> Hi Paul, > > >>>>>>>>>>>> > > >>>>>>>>>>>> If we want to be able to differentiate between simulcast > > >>>>>>>>>>>> and switched capture, for example if we have a three > > >>>>>>>>>>>> camera system that can send three MCs each with two > > >>>>>>>>>>>> encodings > > >>>>>>>>>>>> (simulcast) and a switched capture (loudest speaker or > > >>>>>>>>>>>> two loudest speakers out of three) using the same > > >>>>>>>>>>>> simulcast option for the each MC currently sent. In this > > >>>>>>>>>>>> case we can have an MC with two encodings and an MCC with > > >>>>>>>>>>>> the three > > >> MCs. > > >>>>>>>>>>>> This > > >>>>>>>>> will > > >>>>>>>>>>>> require us to clarify that having multiple individual > > >>>>>>>>>>>> encodings in MC is simulcast and not switched and in MCC > > >>>>>>>>>>>> it is switched and not > > >>>>>>>>> simulcast. > > >>>>>>>>>>> [CNG] I don't understand exactly what the issue is here? > > >>>>>>>>>>> Could you use > > >>>>>>>>> some > > >>>>>>>>>>> pseudo syntax to explain what you're wanting to advertise? > > >>>>>>>>>>> You say in > > >>>>>>>>> the first > > >>>>>>>>>>> sentence the switched capture uses simulcast but then in > > >>>>>>>>>>> the last > > >>>>>>>>> sentence you > > >>>>>>>>>>> say the MCC is switched and not simulcast. I would think > > >>>>>>>>>>> that an MCC can > > >>>>>>>>> still > > >>>>>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts > > >>>>>>>>>>> whatever source > > >>>>>>>>> is > > >>>>>>>>>>> switched into the media stream. > > >>>>>>>>>>> If you want a pure switched MCC just set > > >>>>>>>>>>> maxCaptureEncodings to > > >>>>>>>>>>> 1 > > >>>>>>>>> against the > > >>>>>>>>>>> MCC. > > >>>>>>>>>>> If you want a simultcast MCC just set maxCaptureEncodings > > >>>>>>>>>>> to > > >>>>>>>>>>>> =2 > > >>>>>>>>> against the > > >>>>>>>>>>> MCC. > > >>>>>>>>>> [Roni Even] The thing is that I am not sure how to > > >>>>>>>>>> advertise this > > >>>>>>> example. > > >>>>>>>>>> The advertisement has two scene views: > > >>>>>>>>>> 1. Scene view with VC0, VC1, VC2 each with two > > >>>>>>>>>> simulcast streams > > >>>>> 2. > > >>>>>>>>>> Scene view MCC3 as represented bellow > > >>>>>>>>>> > > >>>>>>>>>> The different MCs will be: > > >>>>>>>>>> > > >>>>>>>>>> VC0- (the left camera stream), encoding group=EG0, > > >>>>>>>>>> view=table, > > >>>>>>>>>> MaxCaptures=2 > > >>>>>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means "Max > > >> Capture > > >>>>>>>>> Encodings"? > > >>>>>>>>> Don't confuse this with the MCC attribute MaxCaptures which > > >>>>>>>>> means > > >>>>>>> "Max > > >>>>>>>>> number of Captures within a MCC". > > >>>>>>>>> > > >>>>>>>>>> VC1- (the center camera stream), encoding group=EG0, > > >>>>>>>>>> view=table, > > >>>>>>>>>> MaxCaptures=2 > > >>>>>>>>>> > > >>>>>>>>>> VC2- (the right camera stream), encoding group=EG0, > > >> view=table. > > >>>>>>>>>> MaxCaptures=2 > > >>>>>>>>>> > > >>>>>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=EG0, view=room, > > >>>>>>>>> MaxCaptures=2 > > >>>>>>>>> > > >>>>>>>>> [Duckworth, Mark] It isn't clear if you really mean "max > > >>>>>>>>> capture > > >>>>>>> encodings" > > >>>>>>>>> or > > >>>>>>>>> "max number of captures within a MCC". Those are two > > >>>>>>>>> different > > >>>>> things. > > >>>>>>>>>> Now it may be implied here that VC0, VC1, VC2 are simulcast. > > >>>>>>>>> [Duckworth, Mark] It depends how the consumer configures it. > > >>>>>>>>> The provider advertisement says it supports simulcast, so > > >>>>>>>>> the consumer can decide to use it or not. > > >>>>>>>>> > > >>>>>>>>>> What about MCC3? > > >>>>>>>>>> Is it multicast from one of the cameras or is it 2 MCs out > > >>>>>>>>>> of the three? (I assume it is the first since the view is > > >>>>>>>>>> room) > > >>>>>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three > > >>>>>>>>> simultaneously only if it is composed, not if it is switched. > > >>>>>>>>> The provider can give more information, if it wants to, with > > >>>>>>>>> the MCC attribute "max number of captures within a MCC". > > >>>>>>>>> > > >>>>>>>>>> What if in the above example MaxCaptures=4 can it be for > > >>>>>>>>>> example VC0, > > >>>>>>>>> VC1 > > >>>>>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and > > >>>>>>>>>> one of them is > > >>>>>>>>> simulcast? > > >>>>>>>>> > > >>>>>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single > > >> "conceptual" > > >>>>>>>>> capture. > > >>>>>>>>> It sounds like you are talking about a switched case, not a > > >>>>>>>>> composed case, so let's say MCC3 has the attribute "max > > >>>>>>>>> number of captures within > > >>>>>>> a > > >>>>>>>> MCC" = 1. > > >>>>>>>>> Now let's also suppose MCC3 has "max capture encodings" = 2. > > >>>>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, > > >>>>>>>>> for the two encodings. Then the provider decides when to > > >>>>>>>>> switch among VC0, VC1, and VC2, and whichever one the > > >>>>>>>>> provider is sending for > > >>>>>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast > > >>>>>>>>> at those two resolutions. > > >>>>>>>>> > > >>>>>>>>>> What I am trying to say is that using implied simulcast > > >>>>>>>>>> require text explaining when a consumer can understand that > > >>>>>>>>>> the advertisement is simulcast and not something else. > > >>>>>>>>>> The other approach may be to have an attribute for an MC > > >>>>>>>>>> and MCC that > > >>>>>>>>> will > > >>>>>>>>>> explicitly say that this is a simulcast offer. > > >>>>>>>>> [Duckworth, Mark] I think the advertisement is clear to the > > >>>>>>>>> consumer without any additional text or attributes added to > > >>>>>>>>> the framework. It is already explicit, with the attribute > > >>>>>>>>> "max capture encodings". If it is >1, then the > > >>>>>>>>> advertisement is offering > > >>>>>> simulcast. > > >>>>>>>>>> BTW: I think that the implied solution works when the > > >>>>>>>>>> individual encodings are the same (spatial or different > > >>>>>>>>>> codces) what if we the provider can send > > >>>>>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be > > >>>>>>>>>> four different encodings but not all combinations allowed. > > >>>>>>>>>> How to represent it in an advertisement? Is it : > > >>>>>>>>> [Duckworth, Mark] I can consider this case after we get the > > >>>>>>>>> first case above cleared up. > > >>>>>>>>> > > >>>>>>>>>> VC0- (the left camera stream), encoding group=EG0, > > >>>>>>>>>> view=table, > > >>>>>>>>>> MaxCaptures=2 > > >>>>>>>>>> > > >>>>>>>>>> VC1- (the center camera stream), encoding group=EG0, > > >>>>>>>>>> view=table, > > >>>>>>>>>> MaxCaptures=2 > > >>>>>>>>>> > > >>>>>>>>>> VC2- (the right camera stream), encoding group=EG0, > > >> view=table. > > >>>>>>>>>> MaxCaptures=2 > > >>>>>>>>>> > > >>>>>>>>>> VC3- (the left camera stream), encoding group=EG1, > > >>>>>>>>>> view=table, > > >>>>>>>>>> MaxCaptures=2 > > >>>>>>>>>> > > >>>>>>>>>> VC4- (the center camera stream), encoding group=EG1, > > >>>>>>>>>> view=table, > > >>>>>>>>>> MaxCaptures=2 > > >>>>>>>>>> > > >>>>>>>>>> VC5- (the right camera stream), encoding group=EG1, > > >> view=table. > > >>>>>>>>>> MaxCaptures=2 > > >>>>>>>>>> > > >>>>>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two > > >>>>>>>>>> scene views > > >>>>>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? > > >>>>>>>>>> > > >>>>>>>>> ... snip ... > > >>>>>>>>> > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> clue mailing list > > >>>>>>>>> clue@ietf.org > > >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>>>> _______________________________________________ > > >>>>>> clue mailing list > > >>>>>> clue@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>>> _______________________________________________ > > >>>>> clue mailing list > > >>>>> clue@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>>> > > >>>> _______________________________________________ > > >>>> clue mailing list > > >>>> clue@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/clue > > >>>> > > >>> _______________________________________________ > > >>> clue mailing list > > >>> clue@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/clue > > >>> > > >> _______________________________________________ > > >> clue mailing list > > >> clue@ietf.org > > >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Nov 24 12:35: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 166731A8EA9 for ; Mon, 24 Nov 2014 12:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.052 X-Spam-Level: *** X-Spam-Status: No, score=3.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, GB_SUMOF=1, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 DT1KOHQtriVx for ; Mon, 24 Nov 2014 12:35:24 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.193]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169851A8AF0 for ; Mon, 24 Nov 2014 12:35:23 -0800 (PST) Received: from [216.82.241.100] by server-1.bemta-8.messagelabs.com id 78/31-03191-B8693745; Mon, 24 Nov 2014 20:35:23 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-7.tower-220.messagelabs.com!1416861287!16669560!8 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21746 invoked from network); 24 Nov 2014 20:35:07 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-7.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 24 Nov 2014 20:35:07 -0000 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, 24 Nov 2014 12:34:56 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Mon, 24 Nov 2014 12:34:56 -0800 From: "Duckworth, Mark" To: 'Christian Groves' Date: Mon, 24 Nov 2014 12:34:52 -0800 Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: AQMNlD5y/Er04l+N7qx1bZ1/jnz/ogGWsqjqmeg3suCAADHY8A== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE0C0@CRPMBOXPRD08.polycom.com> References: <5472DB9A.80708@nteczone.com> <007801d0080b$8b6b1e60$a2415b20$@gmail.com> In-Reply-To: <007801d0080b$8b6b1e60$a2415b20$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/oq5CUh55wJJvit2JcGN8ujZleiI Cc: "clue@ietf.org" Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 20:35:29 -0000 Hi Christian, The encoding group maxgroupbandwidth should stay the same as before. But y= ou raise an interesting point about how it relates to the bandwidth allowed= for an SDP m-line when there are multiple RTP flows for a single m-line. = I don't think the issue is just for simulcast, but also for layered coding,= FEC, and maybe other reasons. At first glance it seems to me the sum of a= ll packets associated with an m-line (which is a CLUE encoding) is what cou= nts toward the CLUE encoding group maxgroupbandwidth. If we need to descri= be this better, I think the signaling document is the place to do it, becau= se that is where we make the connection between CLUE and SDP. With respect to multiple captures using one encoding group, the framework s= ection 9.1 says "An Individual Encoding can be assigned to at most one Capt= ure Encoding at any given time." Regards, Mark > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Monday, November 24, 2014 12:25 PM > To: 'Christian Groves'; Duckworth, Mark; clue@ietf.org > Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > Hi Christian, > The issues were that there is no single defined semantics when having > multiple individual encoding to a media capture. If we are talking about > simulcast it will mean that each of the multiple multicast encoding will > have its own m-line in the SDP and this is not the direction that MMUSIC = is > taking. The MMUSIC direction is based on the "unified" plan where all > encodings from the same source should be in the same m-line. > > Roni > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > > Sent: 24 November, 2014 9:18 AM > > To: Duckworth, Mark; clue@ietf.org > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > Hello Mark, > > > > You're right, I wasn't thinking about didn't captures using the encodin= g > group. I > > was trying to see what the impact of this change was. My comment comes > out > > of the text in clause 9.3 of the framework, > > > > "Any of the Captures that use a particular Encoding Group can be encode= d > > according to any of the Individual Encodings in the group. If > > there are multiple Individual Encodings in the group, then the > > Consumer can configure the Provider, via a Configure message, to > > encode a single Media Capture into multiple different Capture > > Encodings at the same time, subject to the Max Capture Encodings > > constraint, with each capture encoding following the constraints of > > a different Individual Encoding." > > > > If the encoding group was used for simulcast the maxgroupbandwidth > could > be > > used to apply to the simulcast streams. If we now move this out > mechanism > > out, is there an equivalent for the simulcast cast SDP? b=3D ? > > > > With respect to multiple captures using one encoding group, I didn't se= e > in the > > draft where it says that a media consumer can only choose one individua= l > > encoding (i.e. as identified by a=3Dlabel) for one of the captures > referencing the > > encoding group (i.e. an individual encoding can't be used more than onc= e). > > Does it make sense for two captures (outside a MCC) to share an individ= ual > > encoding? > > > > Regards, Christian > > > > On 24/11/2014 3:26 PM, Duckworth, Mark wrote: > > > Hi Christian, > > > I don't follow you. The original point of encoding groups, which > > > still holds true, is that multiple media captures can use the same > > > encoding group. So there is still a use for an encoding group, which > > > can have multiple individual encodings, each of which can be > > > configured to encode a different capture. > > > So maybe I'm not understanding your concern? > > > Mark > > > > > > > > > -------- Original message -------- > > > From: Christian Groves > > > Date:11/23/2014 7:28 PM (GMT-05:00) > > > To: "Duckworth, Mark" , Christer > > Holmberg > > > , clue@ietf.org > > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > > > I don't think its a trivial change. I assume if we remove this then a > > > consumer must always choose "one" encoding from an encoding group? > It > > > also changes the semantic of the encoding group to sets of mutually > > > exclusive encodings. Then does the "maxgroupbandwidth" also become > > > meaningless for CLUE as from a CLUE perspective only one encoding wil= l > > > be chosen? If we decide to remove simulcast then we should remove it > > > completely and not rely on some functionality in SDP and others in CL= UE. > > > > > > Regards, Christian > > > > > > > > > > > > On 22/11/2014 1:52 AM, Duckworth, Mark wrote: > > > > Yes, the people in the room at IETF 91 were clearly in favor of > > > removing the CLUE simulcast feature enabled by "Max Capture > Encodings" > > > > 1. A reason to remove it is to avoid interop issue which could > > > arise by having two different ways to do simulcast that don't interop > > > with each other. > > > > > > > > Mark > > > > > > > >> -----Original Message----- > > > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer > > > Holmberg > > > >> Sent: Friday, November 21, 2014 1:21 AM > > > >> To: Christian Groves; clue@ietf.org > > > >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > >> > > > >> Hi, > > > >> > > > >>> Yes, I thought the assumption was nothing in CLUE prevented the > > > >>> use of > > > >> the generic >simulcast draft. > > > >> > > > >> It was more a timing issue, as we didn't want to delay the CLUE > > > work when it > > > >> was unsure whether the simulcast was going to be adopted. > > > >> > > > >>> I'm wondering why the adoption of that meant part of CLUE was > > > >>> removed > > > >> (at least >as I understand from the notes)? > > > >> > > > >> As far as I remember, yes. Nobody could come up with a reason why > > > >> it should be kept. > > > >> > > > >> Regards, > > > >> > > > >> Christer > > > >> > > > >> > > > >> On 21/11/2014 4:58 PM, Christer Holmberg wrote: > > > >>> Hi, > > > >>> > > > >>> The generic simulcast draft was adopted in MMUSIC, and the idea i= s > > > that it > > > >> will be used also if someone wants to provide simulcast for CLUE. > > > >>> Regards, > > > >>> > > > >>> Christer > > > >>> > > > >>> -----Original Message----- > > > >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > > > >>> Groves > > > >>> Sent: 21 November 2014 05:25 > > > >>> To: clue@ietf.org > > > >>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > >>> > > > >>> What's the status of the simultcast issue after the meeting? I sa= w > > > some > > > >> meeting notes to suggest that it would be removed from CLUE. I > > > certainly > > > >> didn't expect that from the discussions on the list. > > > >>> Regards, Christian > > > >>> > > > >>> On 13/11/2014 2:25 PM, Paul Kyzivat wrote: > > > >>>> If an sdp-based mechanism is published that allows simulcast in = a > > > >>>> single m-line, then clue gets to take advantage of that *for > > > >>>> free*. I don't know that we need to say anything about that. > > > >>>> > > > >>>> The question we have to ask is: do we want to remove the > > > >>>> clue-specific mechanism that is already present in our data mode= l? > > > >>>> > > > >>>> To that I will add the corollary question: is there any cost to > > > >>>> having that option in there? > > > >>>> > > > >>>> I can't see any cost. > > > >>>> - Advertisers don't have to use it in their advertisements. > > > >>>> - Consumers can't use it in Configure if it wasn't in the > > > >>>> advertisement > > > >>>> - Consumers don't have to use it if it is in the advertisement. > > > >>>> > > > >>>> So I see no harm in leaving it in. And some potential benefit to > > > >>>> having it there. > > > >>>> > > > >>>> Thanks, > > > >>>> Paul > > > >>>> > > > >>>> On 11/12/14 1:29 PM, Roni Even wrote: > > > >>>>> Hi, > > > >>>>> This is what started the discussion. If we do not have SDP base= d > > > >>>>> simulcast based on unified plan, the only semantics is an > > > >>>>> encoding per m-line. We started the discussion based on this > > > >>>>> assumption that we can do simulcast in CLUE using an encoding > > > >>>>> per m-line and can bundle them Roni > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] > > > >>>>>> Sent: 12 November, 2014 11:03 PM > > > >>>>>> To: Duckworth, Mark; Roni Even > > > >>>>>> Cc: clue@ietf.org > > > >>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > > >>>>>> > > > >>>>>> Yes, I'd have thought ideally multiple simulcast qualities, > > > >>>>>> repair streams > > > >>>>> etc > > > >>>>>> would be defined under a single m-line and hence be a single > > > >>>>>> encoding from CLUE's perspective. That matches the unified pla= n > > > >>>>>> and the proposal in > > > >>>>> draft- > > > >>>>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective > it > > > >>>>>> would mean that negotiating simulcast qualities, repair flows > > > >>>>>> etc would be purely an > > > >>>>> SDP > > > >>>>>> issue and wouldn't impact CLUE. > > > >>>>>> > > > >>>>>> Rob > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > > > >>>>>> Duckworth, Mark > > > >>>>>> Sent: 12 November 2014 10:54 > > > >>>>>> To: Roni Even > > > >>>>>> Cc: clue@ietf.org > > > >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > >>>>>> > > > >>>>>> Hi, > > > >>>>>> > > > >>>>>> I don't understand why simulcast would need separate encoding > > > >> groups. > > > >>>>>> Whether an MC maps to two m-lines or one m-line with > > > >>>>>> a=3Dsimulcast is up to the consumer, and specified in the > > > >>>>>> configure message sent from consumer to provider. The > mapping > > > >>>>>> is done via the encoding ID labels which link media captures t= o > > > >>>>>> m-lines. At least that is how I see it. > > > >>>>>> > > > >>>>>> Would you say retransmission streams are a separate issue from > > > >>>>>> simulcast? > > > >>>>> Or > > > >>>>>> are they similar enough that it is really the same issue? Do > > > >>>>>> SVC layered > > > >>>>> codec > > > >>>>>> streams also fall into this category? > > > >>>>>> > > > >>>>>> Sounds like we do need some more discussion about this. My > > > >>>>>> first thought > > > >>>>> is > > > >>>>>> we should cover this in the signaling document. > > > >>>>>> > > > >>>>>> Mark > > > >>>>>> > > > >>>>>>> -----Original Message----- > > > >>>>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > >>>>>>> Sent: Wednesday, November 12, 2014 10:36 AM > > > >>>>>>> To: Duckworth, Mark > > > >>>>>>> Cc: clue@ietf.org > > > >>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > > >>>>>>> > > > >>>>>>> Hi, > > > >>>>>>> This will work when we have a single encoding per m-line in > > > >>>>>>> the SDP and I think it requires that each simulcast set will > > > >>>>>>> be in separate encoding group . Still it will provide less > > > >>>>>>> functionality than the one proposed in the simulcast proposal > > > >>>>>>> that will be discussed in MMUSIC If simulcast in SDP will > > > >>>>>>> progress using the unified plan where we have all encodings i= n > > > >>>>>>> one m-line we will need to specify that if an MC have max > > > >>>>>>> capture encoding >1 will it mean that it will map to two > > > >>>>>>> m-lines or will it use a > > > configuration from > > > >> an SDP description a=3Dsimulcast. > > > >>>>>>> We will need to see how it works with retransmission if we > > > >>>>>>> specify a retransmission RTP stream as an individual encoding= . > > > >>>>>>> > > > >>>>>>> Roni > > > >>>>>>> > > > >>>>>>>> -----Original Message----- > > > >>>>>>>> From: Duckworth, Mark > [mailto:Mark.Duckworth@polycom.com] > > > >>>>>>>> Sent: 06 November, 2014 9:45 PM > > > >>>>>>>> To: Roni Even > > > >>>>>>>> Cc: clue@ietf.org > > > >>>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 > > > >>>>>>>> > > > >>>>>>>> Hi Roni, > > > >>>>>>>> Do you still have questions about the way simulcast is > > > >>>>>>>> handled in the framework, regarding the attribute "Max > capture > > encodings" > > > >>>>>>>> and > > > >>>>>>> configuring > > > >>>>>>>> multiple encodings per capture? I was hoping we could > > > >>>>>>>> resolve it on the > > > >>>>>>> list, or > > > >>>>>>>> do you think we need to talk about it in Honolulu? > > > >>>>>>>> Regards, > > > >>>>>>>> Mark > > > >>>>>>>> > > > >>>>>>>>> -----Original Message----- > > > >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > > > >>>>>>>>> Duckworth, > > > >>>>>>> Mark > > > >>>>>>>>> Sent: Monday, November 03, 2014 10:52 PM > > > >>>>>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org > > > >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > >>>>>>>>> > > > >>>>>>>>>> -----Original Message----- > > > >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > Roni > > > >>>>>>>>>> Even > > > >>>>>>>>>> Sent: Monday, November 03, 2014 5:52 PM > > > >>>>>>>>>> To: 'Christian Groves'; clue@ietf.org > > > >>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > >>>>>>>>>> > > > >>>>>>>>>>> -----Original Message----- > > > >>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > > > >>>>>>>>>>> Christian Groves > > > >>>>>>>>>>> Sent: 28 October, 2014 2:56 AM > > > >>>>>>>>>>> To: clue@ietf.org > > > >>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > >>>>>>>>>>> > > > >>>>>>>>>>> Hello Roni, > > > >>>>>>>>>>> > > > >>>>>>>>>>> As I mentioned in my original reply I think the RTP based > > > >>>>>>>>>>> simulcast > > > >>>>>>>>> method > > > >>>>>>>>>> is > > > >>>>>>>>>>> probably the cleanest approach. There would be nothing > > > >>>>>>>>>>> stopping a CLUE endpoint implementing it when it > becomes > > > >>>>>>>>>>> available (like many other RTP features). Using CLUE for > > > >>>>>>>>>>> simulcast I think is possible for most > > > >>>>>>>>>> scenarios. The > > > >>>>>>>>>>> more complicated the scenarios the more MCs/encodings > an > > > >>>>>>> endpoint > > > >>>>>>>>> will > > > >>>>>>>>>>> need to describe the situation. > > > >>>>>>>>>>> > > > >>>>>>>>>>> Please see my response below. > > > >>>>>>>>>>> > > > >>>>>>>>>>> Regards, Christian > > > >>>>>>>>>>> > > > >>>>>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: > > > >>>>>>>>>>>> Hi Paul, > > > >>>>>>>>>>>> > > > >>>>>>>>>>>> If we want to be able to differentiate between simulcast > > > >>>>>>>>>>>> and switched capture, for example if we have a three > > > >>>>>>>>>>>> camera system that can send three MCs each with two > > > >>>>>>>>>>>> encodings > > > >>>>>>>>>>>> (simulcast) and a switched capture (loudest speaker or > > > >>>>>>>>>>>> two loudest speakers out of three) using the same > > > >>>>>>>>>>>> simulcast option for the each MC currently sent. In this > > > >>>>>>>>>>>> case we can have an MC with two encodings and an MCC > with > > > >>>>>>>>>>>> the three > > > >> MCs. > > > >>>>>>>>>>>> This > > > >>>>>>>>> will > > > >>>>>>>>>>>> require us to clarify that having multiple individual > > > >>>>>>>>>>>> encodings in MC is simulcast and not switched and in > MCC > > > >>>>>>>>>>>> it is switched and not > > > >>>>>>>>> simulcast. > > > >>>>>>>>>>> [CNG] I don't understand exactly what the issue is here? > > > >>>>>>>>>>> Could you use > > > >>>>>>>>> some > > > >>>>>>>>>>> pseudo syntax to explain what you're wanting to > advertise? > > > >>>>>>>>>>> You say in > > > >>>>>>>>> the first > > > >>>>>>>>>>> sentence the switched capture uses simulcast but then in > > > >>>>>>>>>>> the last > > > >>>>>>>>> sentence you > > > >>>>>>>>>>> say the MCC is switched and not simulcast. I would think > > > >>>>>>>>>>> that an MCC can > > > >>>>>>>>> still > > > >>>>>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts > > > >>>>>>>>>>> whatever source > > > >>>>>>>>> is > > > >>>>>>>>>>> switched into the media stream. > > > >>>>>>>>>>> If you want a pure switched MCC just set > > > >>>>>>>>>>> maxCaptureEncodings to > > > >>>>>>>>>>> 1 > > > >>>>>>>>> against the > > > >>>>>>>>>>> MCC. > > > >>>>>>>>>>> If you want a simultcast MCC just set > maxCaptureEncodings > > > >>>>>>>>>>> to > > > >>>>>>>>>>>> =3D2 > > > >>>>>>>>> against the > > > >>>>>>>>>>> MCC. > > > >>>>>>>>>> [Roni Even] The thing is that I am not sure how to > > > >>>>>>>>>> advertise this > > > >>>>>>> example. > > > >>>>>>>>>> The advertisement has two scene views: > > > >>>>>>>>>> 1. Scene view with VC0, VC1, VC2 each with two > > > >>>>>>>>>> simulcast streams > > > >>>>> 2. > > > >>>>>>>>>> Scene view MCC3 as represented bellow > > > >>>>>>>>>> > > > >>>>>>>>>> The different MCs will be: > > > >>>>>>>>>> > > > >>>>>>>>>> VC0- (the left camera stream), encoding group=3DEG0, > > > >>>>>>>>>> view=3Dtable, > > > >>>>>>>>>> MaxCaptures=3D2 > > > >>>>>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means > "Max > > > >> Capture > > > >>>>>>>>> Encodings"? > > > >>>>>>>>> Don't confuse this with the MCC attribute MaxCaptures > which > > > >>>>>>>>> means > > > >>>>>>> "Max > > > >>>>>>>>> number of Captures within a MCC". > > > >>>>>>>>> > > > >>>>>>>>>> VC1- (the center camera stream), encoding group=3DEG0, > > > >>>>>>>>>> view=3Dtable, > > > >>>>>>>>>> MaxCaptures=3D2 > > > >>>>>>>>>> > > > >>>>>>>>>> VC2- (the right camera stream), encoding group=3DEG0, > > > >> view=3Dtable. > > > >>>>>>>>>> MaxCaptures=3D2 > > > >>>>>>>>>> > > > >>>>>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=3DEG0, > view=3Droom, > > > >>>>>>>>> MaxCaptures=3D2 > > > >>>>>>>>> > > > >>>>>>>>> [Duckworth, Mark] It isn't clear if you really mean "max > > > >>>>>>>>> capture > > > >>>>>>> encodings" > > > >>>>>>>>> or > > > >>>>>>>>> "max number of captures within a MCC". Those are two > > > >>>>>>>>> different > > > >>>>> things. > > > >>>>>>>>>> Now it may be implied here that VC0, VC1, VC2 are > simulcast. > > > >>>>>>>>> [Duckworth, Mark] It depends how the consumer configures > it. > > > >>>>>>>>> The provider advertisement says it supports simulcast, so > > > >>>>>>>>> the consumer can decide to use it or not. > > > >>>>>>>>> > > > >>>>>>>>>> What about MCC3? > > > >>>>>>>>>> Is it multicast from one of the cameras or is it 2 MCs out > > > >>>>>>>>>> of the three? (I assume it is the first since the view is > > > >>>>>>>>>> room) > > > >>>>>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three > > > >>>>>>>>> simultaneously only if it is composed, not if it is switche= d. > > > >>>>>>>>> The provider can give more information, if it wants to, wit= h > > > >>>>>>>>> the MCC attribute "max number of captures within a MCC". > > > >>>>>>>>> > > > >>>>>>>>>> What if in the above example MaxCaptures=3D4 can it be for > > > >>>>>>>>>> example VC0, > > > >>>>>>>>> VC1 > > > >>>>>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and > > > >>>>>>>>>> one of them is > > > >>>>>>>>> simulcast? > > > >>>>>>>>> > > > >>>>>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single > > > >> "conceptual" > > > >>>>>>>>> capture. > > > >>>>>>>>> It sounds like you are talking about a switched case, not a > > > >>>>>>>>> composed case, so let's say MCC3 has the attribute "max > > > >>>>>>>>> number of captures within > > > >>>>>>> a > > > >>>>>>>> MCC" =3D 1. > > > >>>>>>>>> Now let's also suppose MCC3 has "max capture encodings" =3D > 2. > > > >>>>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, > > > >>>>>>>>> for the two encodings. Then the provider decides when to > > > >>>>>>>>> switch among VC0, VC1, and VC2, and whichever one the > > > >>>>>>>>> provider is sending for > > > >>>>>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast > > > >>>>>>>>> at those two resolutions. > > > >>>>>>>>> > > > >>>>>>>>>> What I am trying to say is that using implied simulcast > > > >>>>>>>>>> require text explaining when a consumer can understand > that > > > >>>>>>>>>> the advertisement is simulcast and not something else. > > > >>>>>>>>>> The other approach may be to have an attribute for an MC > > > >>>>>>>>>> and MCC that > > > >>>>>>>>> will > > > >>>>>>>>>> explicitly say that this is a simulcast offer. > > > >>>>>>>>> [Duckworth, Mark] I think the advertisement is clear to the > > > >>>>>>>>> consumer without any additional text or attributes added to > > > >>>>>>>>> the framework. It is already explicit, with the attribute > > > >>>>>>>>> "max capture encodings". If it is >1, then the > > > >>>>>>>>> advertisement is offering > > > >>>>>> simulcast. > > > >>>>>>>>>> BTW: I think that the implied solution works when the > > > >>>>>>>>>> individual encodings are the same (spatial or different > > > >>>>>>>>>> codces) what if we the provider can send > > > >>>>>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will b= e > > > >>>>>>>>>> four different encodings but not all combinations allowed. > > > >>>>>>>>>> How to represent it in an advertisement? Is it : > > > >>>>>>>>> [Duckworth, Mark] I can consider this case after we get the > > > >>>>>>>>> first case above cleared up. > > > >>>>>>>>> > > > >>>>>>>>>> VC0- (the left camera stream), encoding group=3DEG0, > > > >>>>>>>>>> view=3Dtable, > > > >>>>>>>>>> MaxCaptures=3D2 > > > >>>>>>>>>> > > > >>>>>>>>>> VC1- (the center camera stream), encoding group=3DEG0, > > > >>>>>>>>>> view=3Dtable, > > > >>>>>>>>>> MaxCaptures=3D2 > > > >>>>>>>>>> > > > >>>>>>>>>> VC2- (the right camera stream), encoding group=3DEG0, > > > >> view=3Dtable. > > > >>>>>>>>>> MaxCaptures=3D2 > > > >>>>>>>>>> > > > >>>>>>>>>> VC3- (the left camera stream), encoding group=3DEG1, > > > >>>>>>>>>> view=3Dtable, > > > >>>>>>>>>> MaxCaptures=3D2 > > > >>>>>>>>>> > > > >>>>>>>>>> VC4- (the center camera stream), encoding group=3DEG1, > > > >>>>>>>>>> view=3Dtable, > > > >>>>>>>>>> MaxCaptures=3D2 > > > >>>>>>>>>> > > > >>>>>>>>>> VC5- (the right camera stream), encoding group=3DEG1, > > > >> view=3Dtable. > > > >>>>>>>>>> MaxCaptures=3D2 > > > >>>>>>>>>> > > > >>>>>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and tw= o > > > >>>>>>>>>> scene views > > > >>>>>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? > > > >>>>>>>>>> > > > >>>>>>>>> ... snip ... > > > >>>>>>>>> > > > >>>>>>>>> > _______________________________________________ > > > >>>>>>>>> clue mailing list > > > >>>>>>>>> clue@ietf.org > > > >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue > > > >>>>>> _______________________________________________ > > > >>>>>> clue mailing list > > > >>>>>> clue@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/clue > > > >>>>> _______________________________________________ > > > >>>>> clue mailing list > > > >>>>> clue@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/clue > > > >>>>> > > > >>>> _______________________________________________ > > > >>>> clue mailing list > > > >>>> clue@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > > >>>> > > > >>> _______________________________________________ > > > >>> clue mailing list > > > >>> clue@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/clue > > > >>> > > > >> _______________________________________________ > > > >> clue mailing list > > > >> clue@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/clue > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Nov 24 14:07: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 1154C1AC44D for ; Mon, 24 Nov 2014 14:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0NsuuMsIBYD for ; Mon, 24 Nov 2014 14:07:31 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4B91ACCF3 for ; Mon, 24 Nov 2014 14:07:30 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-08v.sys.comcast.net with comcast id Ka751p0074yXVJQ01a7WWw; Mon, 24 Nov 2014 22:07:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-06v.sys.comcast.net with comcast id Ka7V1p00A3Ge9ey01a7VkK; Mon, 24 Nov 2014 22:07:30 +0000 Message-ID: <5473AC21.7000205@alum.mit.edu> Date: Mon, 24 Nov 2014 17:07:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.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=q20140121; t=1416866850; bh=IbpcPkEx6yFxkGHUpyEwoHHB1EPGDN3bPNmn7sShob0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qJkL5XunPT1DFrdwXCV4PSWSWYGcbaO9oxGPOsO6WAghEfwTb0g3au9nz20yMALHm tUI5mOjs2Gx9kLXp+eQyW1REQfboI3cAhy5rZlnBMUL3uqn4OglwADdKeDTN9vTFRx 4Hnf5yPl5cXwaDAIBgBfjtLmQgYN/wh5U0wrZRIxajlRo0a63YBjE6zatLZpVQnblC XTXm8TfS6tU6ntK8BPd49uZAmFFy3D/5v/a6byTfAV3/lNVingrvKtwrhIavw4Ussl RzpLUWXv3BHYe6djEIf/c65JVp8hrD1+uff3YkevvKWR/how16sqge0hfrL5Hb7Kmb 7j6R3CHIidWuQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/clUYKGxOfYBhNyS6Rhe5ORn5ihc Subject: [clue] Consensus call: remove clue-specific simulcast X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 22:07:32 -0000 During the Honululu meeting we had consensus to remove the clue-specific simulcast mechanism (via configuring the same capture with two or more encodings). The expectation is that, in lieu of this clue will rely on an SDP mechanism for negotiating simulcast within a single m-line. (The mmusic wg adopted draft-westerlund-avtcore-rtp-simulcast-04 as a wg item at this meeting.) This message brings that question to the list for confirmation. Please indicate if you support removal of the clue-specific simulcast mechanism: YES/NO. If you indicate NO, please provide a detailed reason why not. Thanks, Paul From nobody Mon Nov 24 15:25: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 461F11A0250 for ; Mon, 24 Nov 2014 15:25:24 -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_14=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 UJJPHgLJ2fF5 for ; Mon, 24 Nov 2014 15:25:22 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9C31A7026 for ; Mon, 24 Nov 2014 15:25:19 -0800 (PST) Received: from ppp118-209-16-208.lns20.mel4.internode.on.net ([118.209.16.208]:51064 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xt2zS-0008Vu-UF for clue@ietf.org; Tue, 25 Nov 2014 10:24:19 +1100 Message-ID: <5473BE59.4070805@nteczone.com> Date: Tue, 25 Nov 2014 10:25:13 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/_utNMzze3-iO2xm6Sx_7XZOOqTU Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 23:25:24 -0000 I thought the reason we used DCEP was so that it was compatible with WebRTC endpoints. So is this not a concern anymore? My view is that it should be possible to use external negotiation to negotiate the protocols that are used for the data channel and then use DCEP to establish the SCTP channel. This effectively emulates what we had in our CLUE data channel draft where the a=GROUP:CLUE on the datachannel m=line indicated that CLUE would be used and then DCEP was used to establish the SCTP channel. Christian On 24/11/2014 1:33 PM, Christer Holmberg wrote: > Hi, > > I agree with what you are saying, there is no need for DCEP if we use > external negotiation. > > The question is then whether we should remove DCEP completely from the > CLUE data channel draft? > > DCEP could be useful if someone implemented CLUE using another > signalling protocol than SIP/SDP, but we are not specifying such > usage, so... > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ‎24/‎11/‎2014 02:13 > To: clue@ietf.org > Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP > > On 11/21/14 2:20 PM, Christer Holmberg wrote: > > FYI, > > > > I sent the following to the MMUSIC list. > > > > The CLUE data channel draft currently assumes that DCEP is used to open > > the CLUE data channel, once it has been negotiated using draft-ejzak. > > > > However, if draft-ejzak forbids usage of DCEP, and/or we don’t think > > it’s needed for the CLUE data channel, we can remove it. > > > > In my opinion, the advantage of also using DCEP is that the endpoints > > can choose when to open the data channel – otherwise it is considered > > open once the SCTP association has been created. > > My understanding is that DCEP is *not* used. When you use external > negotiation you simply agree (externally) on which stream ids are to be > used (they don't even have to be the same in each direction) and start > using them. > > I could be wrong, but I don't think the webrtc API has a way for you to > use the DCEP protocol on an externally allocated channel. You can call > to open a channel without supplying a stream id, in which case DCEP is > automatically used to assign the id), or else you can supply a stream id > when opening a channel (in which case DCEP is not used). > > I suppose nothing prevents you from using DCEP messages on your > externally allocated channel, but then you would have to format and send > them yourself, and decode them at the other end, rather than having the > library behind the API doing it for you. > > Thanks, > Paul > > > Regards, > > > > Christer > > > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > > Holmberg > > *Sent:* 21 November 2014 21:17 > > *To:* mmusic@ietf.org > > *Subject:* [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and DCEP > > > > Hi, > > > > draft-ejzak-mmusic-data-channel-sdpneg currently seems to assume that > > DCEP will not be used to open data channels – instead data channels will > > be considered open once the SDP O/A negotiation has finished and the > > SCTP association used to realize the data channel(s) has been created. > > > > My question is whether the intention is to forbid usage of DCEP together > > with draft-ejzak-mmusic-data-channel-sdpneg, or whether it should be > > optional? > > > > If optional, there needs to be a way to indicate that application data > > shall not be sent until a channel has been opened using DCEP. In > > addition, it would be useful to be able to indicate which endpoint is > > responsible for sending the DCEP_CHANNEL_OPEN message. > > > > 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 nobody Mon Nov 24 15:34: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 C950F1A700E for ; Mon, 24 Nov 2014 15:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 oq6Yzd9Phoio for ; Mon, 24 Nov 2014 15:34:45 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCFD1A701D for ; Mon, 24 Nov 2014 15:34:44 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 179C7474F1F17; Mon, 24 Nov 2014 23:34:35 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sAONYdcr019362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Nov 2014 18:34:39 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 24 Nov 2014 18:34:39 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHwBvENaOAA9cNwAAK7ZTgAAKalZw Date: Mon, 24 Nov 2014 23:34:38 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> <5473BE59.4070805@nteczone.com> In-Reply-To: <5473BE59.4070805@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/vk2RQTptoZsdRiOJmf696R5XB9w Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 23:34:48 -0000 DQpQZXIgZGlzY3Vzc2lvbnMgd2l0aCBDaHJpc3RpYW4sIHdlIGFyZSBnb2luZyB0byBwcm9wb3Nl IG5ldyBiYWNrd2FyZCBjb21wYXRpYmxlIHN5bnRheCBhbmQgdXNlIGNhc2VzIG9mIGVqemFrLW1t dXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnIHRvIHVzZSBpdCBleHRlcm5hbCBuZWdvdGlhdGlvbiBv ZiBzdWJwcm90b2NvbChzKSBhbmQgdGhlaXIgYXR0cmlidXRlcyB3aGlsZSB1c2luZyBEQ0VQIGZv ciBlc3RhYmxpc2htZW50IG9mIHRoZSBEQy4gV2Ugd2lsbCB1cGRhdGUgTU1VU0lDIGxpc3QgZm9y IGZlZWRiYWNrIG9uIHRoZSBwcm9wb3NhbCBhbmQgd2lsbCBjYyBjbHVlIGFsaWFzLg0KUGxlYXNl IHN0YXkgdHVuZWQuDQoNCkJSDQpSYWp1DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQ2hyaXN0aWFuIEdyb3Zlcw0KPiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDI0LCAyMDE0IDU6 MjUgUE0NCj4gVG86IGNsdWVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtjbHVlXSBGVzogZHJh ZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcgYW5kIERDRVANCj4gDQo+IEkgdGhv dWdodCB0aGUgcmVhc29uIHdlIHVzZWQgRENFUCB3YXMgc28gdGhhdCBpdCB3YXMgY29tcGF0aWJs ZSB3aXRoDQo+IFdlYlJUQyBlbmRwb2ludHMuIFNvIGlzIHRoaXMgbm90IGEgY29uY2VybiBhbnlt b3JlPw0KPiANCj4gTXkgdmlldyBpcyB0aGF0IGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byB1c2Ug ZXh0ZXJuYWwgbmVnb3RpYXRpb24gdG8NCj4gbmVnb3RpYXRlIHRoZSBwcm90b2NvbHMgdGhhdCBh cmUgdXNlZCBmb3IgdGhlIGRhdGEgY2hhbm5lbCBhbmQgdGhlbiB1c2UNCj4gRENFUCB0byBlc3Rh Ymxpc2ggdGhlIFNDVFAgY2hhbm5lbC4gVGhpcyBlZmZlY3RpdmVseSBlbXVsYXRlcyB3aGF0IHdl DQo+IGhhZCBpbiBvdXIgQ0xVRSBkYXRhIGNoYW5uZWwgZHJhZnQgd2hlcmUgdGhlIGE9R1JPVVA6 Q0xVRSBvbiB0aGUNCj4gZGF0YWNoYW5uZWwgbT1saW5lIGluZGljYXRlZCB0aGF0IENMVUUgd291 bGQgYmUgdXNlZCBhbmQgdGhlbiBEQ0VQIHdhcw0KPiB1c2VkIHRvIGVzdGFibGlzaCB0aGUgU0NU UCBjaGFubmVsLg0KPiANCj4gQ2hyaXN0aWFuDQo+IA0KPiBPbiAyNC8xMS8yMDE0IDE6MzMgUE0s IENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4gSSBhZ3JlZSB3aXRo IHdoYXQgeW91IGFyZSBzYXlpbmcsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIERDRVAgaWYgd2UgdXNl DQo+ID4gZXh0ZXJuYWwgbmVnb3RpYXRpb24uDQo+ID4NCj4gPiBUaGUgcXVlc3Rpb24gaXMgdGhl biB3aGV0aGVyIHdlIHNob3VsZCByZW1vdmUgRENFUCBjb21wbGV0ZWx5IGZyb20gdGhlDQo+ID4g Q0xVRSBkYXRhIGNoYW5uZWwgZHJhZnQ/DQo+ID4NCj4gPiBEQ0VQIGNvdWxkIGJlIHVzZWZ1bCBp ZiBzb21lb25lIGltcGxlbWVudGVkIENMVUUgdXNpbmcgYW5vdGhlcg0KPiA+IHNpZ25hbGxpbmcg cHJvdG9jb2wgdGhhbiBTSVAvU0RQLCBidXQgd2UgYXJlIG5vdCBzcGVjaWZ5aW5nIHN1Y2gNCj4g PiB1c2FnZSwgc28uLi4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBDaHJpc3Rlcg0KPiA+ DQo+ID4gU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g PiBGcm9tOiBQYXVsIEt5eml2YXQgPG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+DQo+ID4g U2VudDog4oCOMjQv4oCOMTEv4oCOMjAxNCAwMjoxMw0KPiA+IFRvOiBjbHVlQGlldGYub3JnIDxt YWlsdG86Y2x1ZUBpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBSZTogW2NsdWVdIEZXOiBkcmFmdC1l anphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBhbmQgRENFUA0KPiA+DQo+ID4gT24gMTEv MjEvMTQgMjoyMCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+ID4gPiBGWUksDQo+ID4g Pg0KPiA+ID4gSSBzZW50IHRoZSBmb2xsb3dpbmcgdG8gdGhlIE1NVVNJQyBsaXN0Lg0KPiA+ID4N Cj4gPiA+IFRoZSBDTFVFIGRhdGEgY2hhbm5lbCBkcmFmdCBjdXJyZW50bHkgYXNzdW1lcyB0aGF0 IERDRVAgaXMgdXNlZCB0byBvcGVuDQo+ID4gPiB0aGUgQ0xVRSBkYXRhIGNoYW5uZWwsIG9uY2Ug aXQgaGFzIGJlZW4gbmVnb3RpYXRlZCB1c2luZyBkcmFmdC1lanphay4NCj4gPiA+DQo+ID4gPiBI b3dldmVyLCBpZiBkcmFmdC1lanphayBmb3JiaWRzIHVzYWdlIG9mIERDRVAsIGFuZC9vciB3ZSBk b27igJl0IHRoaW5rDQo+ID4gPiBpdOKAmXMgbmVlZGVkIGZvciB0aGUgQ0xVRSBkYXRhIGNoYW5u ZWwsIHdlIGNhbiByZW1vdmUgaXQuDQo+ID4gPg0KPiA+ID4gSW4gbXkgb3BpbmlvbiwgdGhlIGFk dmFudGFnZSBvZiBhbHNvIHVzaW5nIERDRVAgaXMgdGhhdCB0aGUgZW5kcG9pbnRzDQo+ID4gPiBj YW4gY2hvb3NlIHdoZW4gdG8gb3BlbiB0aGUgZGF0YSBjaGFubmVsIOKAkyBvdGhlcndpc2UgaXQg aXMgY29uc2lkZXJlZA0KPiA+ID4gb3BlbiBvbmNlIHRoZSBTQ1RQIGFzc29jaWF0aW9uIGhhcyBi ZWVuIGNyZWF0ZWQuDQo+ID4NCj4gPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgRENFUCBpcyAq bm90KiB1c2VkLiBXaGVuIHlvdSB1c2UgZXh0ZXJuYWwNCj4gPiBuZWdvdGlhdGlvbiB5b3Ugc2lt cGx5IGFncmVlIChleHRlcm5hbGx5KSBvbiB3aGljaCBzdHJlYW0gaWRzIGFyZSB0byBiZQ0KPiA+ IHVzZWQgKHRoZXkgZG9uJ3QgZXZlbiBoYXZlIHRvIGJlIHRoZSBzYW1lIGluIGVhY2ggZGlyZWN0 aW9uKSBhbmQgc3RhcnQNCj4gPiB1c2luZyB0aGVtLg0KPiA+DQo+ID4gSSBjb3VsZCBiZSB3cm9u ZywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhlIHdlYnJ0YyBBUEkgaGFzIGEgd2F5IGZvciB5b3UgdG8N Cj4gPiB1c2UgdGhlIERDRVAgcHJvdG9jb2wgb24gYW4gZXh0ZXJuYWxseSBhbGxvY2F0ZWQgY2hh bm5lbC4gWW91IGNhbiBjYWxsDQo+ID4gdG8gb3BlbiBhIGNoYW5uZWwgd2l0aG91dCBzdXBwbHlp bmcgYSBzdHJlYW0gaWQsIGluIHdoaWNoIGNhc2UgRENFUCBpcw0KPiA+IGF1dG9tYXRpY2FsbHkg dXNlZCB0byBhc3NpZ24gdGhlIGlkKSwgb3IgZWxzZSB5b3UgY2FuIHN1cHBseSBhIHN0cmVhbSBp ZA0KPiA+IHdoZW4gb3BlbmluZyBhIGNoYW5uZWwgKGluIHdoaWNoIGNhc2UgRENFUCBpcyBub3Qg dXNlZCkuDQo+ID4NCj4gPiBJIHN1cHBvc2Ugbm90aGluZyBwcmV2ZW50cyB5b3UgZnJvbSB1c2lu ZyBEQ0VQIG1lc3NhZ2VzIG9uIHlvdXINCj4gPiBleHRlcm5hbGx5IGFsbG9jYXRlZCBjaGFubmVs LCBidXQgdGhlbiB5b3Ugd291bGQgaGF2ZSB0byBmb3JtYXQgYW5kIHNlbmQNCj4gPiB0aGVtIHlv dXJzZWxmLCBhbmQgZGVjb2RlIHRoZW0gYXQgdGhlIG90aGVyIGVuZCwgcmF0aGVyIHRoYW4gaGF2 aW5nIHRoZQ0KPiA+IGxpYnJhcnkgYmVoaW5kIHRoZSBBUEkgZG9pbmcgaXQgZm9yIHlvdS4NCj4g Pg0KPiA+IFRoYW5rcywNCj4gPiBQYXVsDQo+ID4NCj4gPiA+IFJlZ2FyZHMsDQo+ID4gPg0KPiA+ ID4gQ2hyaXN0ZXINCj4gPiA+DQo+ID4gPiAqRnJvbToqbW11c2ljIFttYWlsdG86bW11c2ljLWJv dW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkNocmlzdGVyDQo+ID4gPiBIb2xtYmVyZw0K PiA+ID4gKlNlbnQ6KiAyMSBOb3ZlbWJlciAyMDE0IDIxOjE3DQo+ID4gPiAqVG86KiBtbXVzaWNA aWV0Zi5vcmcNCj4gPiA+ICpTdWJqZWN0OiogW01NVVNJQ10gZHJhZnQtZWp6YWstbW11c2ljLWRh dGEtY2hhbm5lbC1zZHBuZWcgYW5kIERDRVANCj4gPiA+DQo+ID4gPiBIaSwNCj4gPiA+DQo+ID4g PiBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBjdXJyZW50bHkgc2VlbXMg dG8gYXNzdW1lIHRoYXQNCj4gPiA+IERDRVAgd2lsbCBub3QgYmUgdXNlZCB0byBvcGVuIGRhdGEg Y2hhbm5lbHMg4oCTIGluc3RlYWQgZGF0YSBjaGFubmVscyB3aWxsDQo+ID4gPiBiZSBjb25zaWRl cmVkIG9wZW4gb25jZSB0aGUgU0RQIE8vQSBuZWdvdGlhdGlvbiBoYXMgZmluaXNoZWQgYW5kIHRo ZQ0KPiA+ID4gU0NUUCBhc3NvY2lhdGlvbiB1c2VkIHRvIHJlYWxpemUgdGhlIGRhdGEgY2hhbm5l bChzKSBoYXMgYmVlbiBjcmVhdGVkLg0KPiA+ID4NCj4gPiA+IE15IHF1ZXN0aW9uIGlzIHdoZXRo ZXIgdGhlIGludGVudGlvbiBpcyB0byBmb3JiaWQgdXNhZ2Ugb2YgRENFUCB0b2dldGhlcg0KPiA+ ID4gd2l0aCBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZywgb3Igd2hldGhl ciBpdCBzaG91bGQgYmUNCj4gPiA+IG9wdGlvbmFsPw0KPiA+ID4NCj4gPiA+IElmIG9wdGlvbmFs LCB0aGVyZSBuZWVkcyB0byBiZSBhIHdheSB0byBpbmRpY2F0ZSB0aGF0IGFwcGxpY2F0aW9uIGRh dGENCj4gPiA+IHNoYWxsIG5vdCBiZSBzZW50IHVudGlsIGEgY2hhbm5lbCBoYXMgYmVlbiBvcGVu ZWQgdXNpbmcgRENFUC4gSW4NCj4gPiA+IGFkZGl0aW9uLCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8g YmUgYWJsZSB0byBpbmRpY2F0ZSB3aGljaCBlbmRwb2ludCBpcw0KPiA+ID4gcmVzcG9uc2libGUg Zm9yIHNlbmRpbmcgdGhlIERDRVBfQ0hBTk5FTF9PUEVOIG1lc3NhZ2UuDQo+ID4gPg0KPiA+ID4g UmVnYXJkcywNCj4gPiA+DQo+ID4gPiBDaHJpc3Rlcg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ IGNsdWUgbWFpbGluZyBsaXN0DQo+ID4gPiBjbHVlQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4gPiA+DQo+ID4NCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGNsdWUgbWFpbGlu ZyBsaXN0DQo+ID4gY2x1ZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY2x1ZQ0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGNsdWUgbWFpbGluZyBsaXN0DQo+ID4gY2x1ZUBp ZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Y2x1ZSBtYWlsaW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg== From nobody Mon Nov 24 15:45: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 36E5E1A871E for ; Mon, 24 Nov 2014 15:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.054 X-Spam-Level: *** X-Spam-Status: No, score=3.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, GB_SUMOF=1, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=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 bXBNa5huoGnB for ; Mon, 24 Nov 2014 15:45:33 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0EEB1A700E for ; Mon, 24 Nov 2014 15:45:32 -0800 (PST) Received: from ppp118-209-16-208.lns20.mel4.internode.on.net ([118.209.16.208]:51201 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xt3J3-0003PK-G1; Tue, 25 Nov 2014 10:44:33 +1100 Message-ID: <5473C317.1050902@nteczone.com> Date: Tue, 25 Nov 2014 10:45:27 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Duckworth, Mark" References: <5472DB9A.80708@nteczone.com> <007801d0080b$8b6b1e60$a2415b20$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE0C0@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE0C0@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/MZ8_LgsbQ78BcTI_8XzT93UdejQ Cc: "clue@ietf.org" Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 23:45:37 -0000 Hello Mark, Thanks for the reference to 9.1 I missed the sentence. With regards to the encoding group maxgroupbandwidth I think it would be good to have some sort of guidance for it. If an endpoint uses an encoding group with a single encoding that uses draft-westerlund-avtcore-rtp-simulcast should it uses maxgroupbandwidth or an SDP based mechanism? To me for this case an SDP specific mechanism should be used. Maxgroupbandwidth would only come into play when there is >1 encoding in the group. Regards, Christian On 25/11/2014 7:34 AM, Duckworth, Mark wrote: > Hi Christian, > > The encoding group maxgroupbandwidth should stay the same as before. But you raise an interesting point about how it relates to the bandwidth allowed for an SDP m-line when there are multiple RTP flows for a single m-line. I don't think the issue is just for simulcast, but also for layered coding, FEC, and maybe other reasons. At first glance it seems to me the sum of all packets associated with an m-line (which is a CLUE encoding) is what counts toward the CLUE encoding group maxgroupbandwidth. If we need to describe this better, I think the signaling document is the place to do it, because that is where we make the connection between CLUE and SDP. > > With respect to multiple captures using one encoding group, the framework section 9.1 says "An Individual Encoding can be assigned to at most one Capture Encoding at any given time." > > Regards, > Mark > >> -----Original Message----- >> From: Roni Even [mailto:ron.even.tlv@gmail.com] >> Sent: Monday, November 24, 2014 12:25 PM >> To: 'Christian Groves'; Duckworth, Mark; clue@ietf.org >> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >> >> Hi Christian, >> The issues were that there is no single defined semantics when having >> multiple individual encoding to a media capture. If we are talking about >> simulcast it will mean that each of the multiple multicast encoding will >> have its own m-line in the SDP and this is not the direction that MMUSIC is >> taking. The MMUSIC direction is based on the "unified" plan where all >> encodings from the same source should be in the same m-line. >> >> Roni >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >>> Sent: 24 November, 2014 9:18 AM >>> To: Duckworth, Mark; clue@ietf.org >>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>> >>> Hello Mark, >>> >>> You're right, I wasn't thinking about didn't captures using the encoding >> group. I >>> was trying to see what the impact of this change was. My comment comes >> out >>> of the text in clause 9.3 of the framework, >>> >>> "Any of the Captures that use a particular Encoding Group can be encoded >>> according to any of the Individual Encodings in the group. If >>> there are multiple Individual Encodings in the group, then the >>> Consumer can configure the Provider, via a Configure message, to >>> encode a single Media Capture into multiple different Capture >>> Encodings at the same time, subject to the Max Capture Encodings >>> constraint, with each capture encoding following the constraints of >>> a different Individual Encoding." >>> >>> If the encoding group was used for simulcast the maxgroupbandwidth >> could >> be >>> used to apply to the simulcast streams. If we now move this out >> mechanism >>> out, is there an equivalent for the simulcast cast SDP? b= ? >>> >>> With respect to multiple captures using one encoding group, I didn't see >> in the >>> draft where it says that a media consumer can only choose one individual >>> encoding (i.e. as identified by a=label) for one of the captures >> referencing the >>> encoding group (i.e. an individual encoding can't be used more than once). >>> Does it make sense for two captures (outside a MCC) to share an individual >>> encoding? >>> >>> Regards, Christian >>> >>> On 24/11/2014 3:26 PM, Duckworth, Mark wrote: >>>> Hi Christian, >>>> I don't follow you. The original point of encoding groups, which >>>> still holds true, is that multiple media captures can use the same >>>> encoding group. So there is still a use for an encoding group, which >>>> can have multiple individual encodings, each of which can be >>>> configured to encode a different capture. >>>> So maybe I'm not understanding your concern? >>>> Mark >>>> >>>> >>>> -------- Original message -------- >>>> From: Christian Groves >>>> Date:11/23/2014 7:28 PM (GMT-05:00) >>>> To: "Duckworth, Mark" , Christer >>> Holmberg >>>> , clue@ietf.org >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> I don't think its a trivial change. I assume if we remove this then a >>>> consumer must always choose "one" encoding from an encoding group? >> It >>>> also changes the semantic of the encoding group to sets of mutually >>>> exclusive encodings. Then does the "maxgroupbandwidth" also become >>>> meaningless for CLUE as from a CLUE perspective only one encoding will >>>> be chosen? If we decide to remove simulcast then we should remove it >>>> completely and not rely on some functionality in SDP and others in CLUE. >>>> >>>> Regards, Christian >>>> >>>> >>>> >>>> On 22/11/2014 1:52 AM, Duckworth, Mark wrote: >>>>> Yes, the people in the room at IETF 91 were clearly in favor of >>>> removing the CLUE simulcast feature enabled by "Max Capture >> Encodings" >>>>> 1. A reason to remove it is to avoid interop issue which could >>>> arise by having two different ways to do simulcast that don't interop >>>> with each other. >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer >>>> Holmberg >>>>>> Sent: Friday, November 21, 2014 1:21 AM >>>>>> To: Christian Groves; clue@ietf.org >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>> Hi, >>>>>> >>>>>>> Yes, I thought the assumption was nothing in CLUE prevented the >>>>>>> use of >>>>>> the generic >simulcast draft. >>>>>> >>>>>> It was more a timing issue, as we didn't want to delay the CLUE >>>> work when it >>>>>> was unsure whether the simulcast was going to be adopted. >>>>>> >>>>>>> I'm wondering why the adoption of that meant part of CLUE was >>>>>>> removed >>>>>> (at least >as I understand from the notes)? >>>>>> >>>>>> As far as I remember, yes. Nobody could come up with a reason why >>>>>> it should be kept. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> On 21/11/2014 4:58 PM, Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The generic simulcast draft was adopted in MMUSIC, and the idea is >>>> that it >>>>>> will be used also if someone wants to provide simulcast for CLUE. >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>>>> Groves >>>>>>> Sent: 21 November 2014 05:25 >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>> >>>>>>> What's the status of the simultcast issue after the meeting? I saw >>>> some >>>>>> meeting notes to suggest that it would be removed from CLUE. I >>>> certainly >>>>>> didn't expect that from the discussions on the list. >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 13/11/2014 2:25 PM, Paul Kyzivat wrote: >>>>>>>> If an sdp-based mechanism is published that allows simulcast in a >>>>>>>> single m-line, then clue gets to take advantage of that *for >>>>>>>> free*. I don't know that we need to say anything about that. >>>>>>>> >>>>>>>> The question we have to ask is: do we want to remove the >>>>>>>> clue-specific mechanism that is already present in our data model? >>>>>>>> >>>>>>>> To that I will add the corollary question: is there any cost to >>>>>>>> having that option in there? >>>>>>>> >>>>>>>> I can't see any cost. >>>>>>>> - Advertisers don't have to use it in their advertisements. >>>>>>>> - Consumers can't use it in Configure if it wasn't in the >>>>>>>> advertisement >>>>>>>> - Consumers don't have to use it if it is in the advertisement. >>>>>>>> >>>>>>>> So I see no harm in leaving it in. And some potential benefit to >>>>>>>> having it there. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>> On 11/12/14 1:29 PM, Roni Even wrote: >>>>>>>>> Hi, >>>>>>>>> This is what started the discussion. If we do not have SDP based >>>>>>>>> simulcast based on unified plan, the only semantics is an >>>>>>>>> encoding per m-line. We started the discussion based on this >>>>>>>>> assumption that we can do simulcast in CLUE using an encoding >>>>>>>>> per m-line and can bundle them Roni >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] >>>>>>>>>> Sent: 12 November, 2014 11:03 PM >>>>>>>>>> To: Duckworth, Mark; Roni Even >>>>>>>>>> Cc: clue@ietf.org >>>>>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>> >>>>>>>>>> Yes, I'd have thought ideally multiple simulcast qualities, >>>>>>>>>> repair streams >>>>>>>>> etc >>>>>>>>>> would be defined under a single m-line and hence be a single >>>>>>>>>> encoding from CLUE's perspective. That matches the unified plan >>>>>>>>>> and the proposal in >>>>>>>>> draft- >>>>>>>>>> burman-mmusic-sdp-simulcast-00, and from CLUE's perspective >> it >>>>>>>>>> would mean that negotiating simulcast qualities, repair flows >>>>>>>>>> etc would be purely an >>>>>>>>> SDP >>>>>>>>>> issue and wouldn't impact CLUE. >>>>>>>>>> >>>>>>>>>> Rob >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>> Duckworth, Mark >>>>>>>>>> Sent: 12 November 2014 10:54 >>>>>>>>>> To: Roni Even >>>>>>>>>> Cc: clue@ietf.org >>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I don't understand why simulcast would need separate encoding >>>>>> groups. >>>>>>>>>> Whether an MC maps to two m-lines or one m-line with >>>>>>>>>> a=simulcast is up to the consumer, and specified in the >>>>>>>>>> configure message sent from consumer to provider. The >> mapping >>>>>>>>>> is done via the encoding ID labels which link media captures to >>>>>>>>>> m-lines. At least that is how I see it. >>>>>>>>>> >>>>>>>>>> Would you say retransmission streams are a separate issue from >>>>>>>>>> simulcast? >>>>>>>>> Or >>>>>>>>>> are they similar enough that it is really the same issue? Do >>>>>>>>>> SVC layered >>>>>>>>> codec >>>>>>>>>> streams also fall into this category? >>>>>>>>>> >>>>>>>>>> Sounds like we do need some more discussion about this. My >>>>>>>>>> first thought >>>>>>>>> is >>>>>>>>>> we should cover this in the signaling document. >>>>>>>>>> >>>>>>>>>> Mark >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>>>>>>>>> Sent: Wednesday, November 12, 2014 10:36 AM >>>>>>>>>>> To: Duckworth, Mark >>>>>>>>>>> Cc: clue@ietf.org >>>>>>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> This will work when we have a single encoding per m-line in >>>>>>>>>>> the SDP and I think it requires that each simulcast set will >>>>>>>>>>> be in separate encoding group . Still it will provide less >>>>>>>>>>> functionality than the one proposed in the simulcast proposal >>>>>>>>>>> that will be discussed in MMUSIC If simulcast in SDP will >>>>>>>>>>> progress using the unified plan where we have all encodings in >>>>>>>>>>> one m-line we will need to specify that if an MC have max >>>>>>>>>>> capture encoding >1 will it mean that it will map to two >>>>>>>>>>> m-lines or will it use a >>>> configuration from >>>>>> an SDP description a=simulcast. >>>>>>>>>>> We will need to see how it works with retransmission if we >>>>>>>>>>> specify a retransmission RTP stream as an individual encoding. >>>>>>>>>>> >>>>>>>>>>> Roni >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Duckworth, Mark >> [mailto:Mark.Duckworth@polycom.com] >>>>>>>>>>>> Sent: 06 November, 2014 9:45 PM >>>>>>>>>>>> To: Roni Even >>>>>>>>>>>> Cc: clue@ietf.org >>>>>>>>>>>> Subject: RE: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>>>> >>>>>>>>>>>> Hi Roni, >>>>>>>>>>>> Do you still have questions about the way simulcast is >>>>>>>>>>>> handled in the framework, regarding the attribute "Max >> capture >>> encodings" >>>>>>>>>>>> and >>>>>>>>>>> configuring >>>>>>>>>>>> multiple encodings per capture? I was hoping we could >>>>>>>>>>>> resolve it on the >>>>>>>>>>> list, or >>>>>>>>>>>> do you think we need to talk about it in Honolulu? >>>>>>>>>>>> Regards, >>>>>>>>>>>> Mark >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>>>> Duckworth, >>>>>>>>>>> Mark >>>>>>>>>>>>> Sent: Monday, November 03, 2014 10:52 PM >>>>>>>>>>>>> To: Roni Even; 'Christian Groves'; clue@ietf.org >>>>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >> Roni >>>>>>>>>>>>>> Even >>>>>>>>>>>>>> Sent: Monday, November 03, 2014 5:52 PM >>>>>>>>>>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >>>>>>>>>>>>>>> Christian Groves >>>>>>>>>>>>>>> Sent: 28 October, 2014 2:56 AM >>>>>>>>>>>>>>> To: clue@ietf.org >>>>>>>>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello Roni, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As I mentioned in my original reply I think the RTP based >>>>>>>>>>>>>>> simulcast >>>>>>>>>>>>> method >>>>>>>>>>>>>> is >>>>>>>>>>>>>>> probably the cleanest approach. There would be nothing >>>>>>>>>>>>>>> stopping a CLUE endpoint implementing it when it >> becomes >>>>>>>>>>>>>>> available (like many other RTP features). Using CLUE for >>>>>>>>>>>>>>> simulcast I think is possible for most >>>>>>>>>>>>>> scenarios. The >>>>>>>>>>>>>>> more complicated the scenarios the more MCs/encodings >> an >>>>>>>>>>> endpoint >>>>>>>>>>>>> will >>>>>>>>>>>>>>> need to describe the situation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please see my response below. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, Christian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 27/10/2014 9:20 PM, Roni Even wrote: >>>>>>>>>>>>>>>> Hi Paul, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If we want to be able to differentiate between simulcast >>>>>>>>>>>>>>>> and switched capture, for example if we have a three >>>>>>>>>>>>>>>> camera system that can send three MCs each with two >>>>>>>>>>>>>>>> encodings >>>>>>>>>>>>>>>> (simulcast) and a switched capture (loudest speaker or >>>>>>>>>>>>>>>> two loudest speakers out of three) using the same >>>>>>>>>>>>>>>> simulcast option for the each MC currently sent. In this >>>>>>>>>>>>>>>> case we can have an MC with two encodings and an MCC >> with >>>>>>>>>>>>>>>> the three >>>>>> MCs. >>>>>>>>>>>>>>>> This >>>>>>>>>>>>> will >>>>>>>>>>>>>>>> require us to clarify that having multiple individual >>>>>>>>>>>>>>>> encodings in MC is simulcast and not switched and in >> MCC >>>>>>>>>>>>>>>> it is switched and not >>>>>>>>>>>>> simulcast. >>>>>>>>>>>>>>> [CNG] I don't understand exactly what the issue is here? >>>>>>>>>>>>>>> Could you use >>>>>>>>>>>>> some >>>>>>>>>>>>>>> pseudo syntax to explain what you're wanting to >> advertise? >>>>>>>>>>>>>>> You say in >>>>>>>>>>>>> the first >>>>>>>>>>>>>>> sentence the switched capture uses simulcast but then in >>>>>>>>>>>>>>> the last >>>>>>>>>>>>> sentence you >>>>>>>>>>>>>>> say the MCC is switched and not simulcast. I would think >>>>>>>>>>>>>>> that an MCC can >>>>>>>>>>>>> still >>>>>>>>>>>>>>> be switched and simulcast, i.e. the endpoint simulcasts >>>>>>>>>>>>>>> whatever source >>>>>>>>>>>>> is >>>>>>>>>>>>>>> switched into the media stream. >>>>>>>>>>>>>>> If you want a pure switched MCC just set >>>>>>>>>>>>>>> maxCaptureEncodings to >>>>>>>>>>>>>>> 1 >>>>>>>>>>>>> against the >>>>>>>>>>>>>>> MCC. >>>>>>>>>>>>>>> If you want a simultcast MCC just set >> maxCaptureEncodings >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> =2 >>>>>>>>>>>>> against the >>>>>>>>>>>>>>> MCC. >>>>>>>>>>>>>> [Roni Even] The thing is that I am not sure how to >>>>>>>>>>>>>> advertise this >>>>>>>>>>> example. >>>>>>>>>>>>>> The advertisement has two scene views: >>>>>>>>>>>>>> 1. Scene view with VC0, VC1, VC2 each with two >>>>>>>>>>>>>> simulcast streams >>>>>>>>> 2. >>>>>>>>>>>>>> Scene view MCC3 as represented bellow >>>>>>>>>>>>>> >>>>>>>>>>>>>> The different MCs will be: >>>>>>>>>>>>>> >>>>>>>>>>>>>> VC0- (the left camera stream), encoding group=EG0, >>>>>>>>>>>>>> view=table, >>>>>>>>>>>>>> MaxCaptures=2 >>>>>>>>>>>>> [Duckworth, Mark] I assume "MaxCaptures" here means >> "Max >>>>>> Capture >>>>>>>>>>>>> Encodings"? >>>>>>>>>>>>> Don't confuse this with the MCC attribute MaxCaptures >> which >>>>>>>>>>>>> means >>>>>>>>>>> "Max >>>>>>>>>>>>> number of Captures within a MCC". >>>>>>>>>>>>> >>>>>>>>>>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>>>>>>>>>> view=table, >>>>>>>>>>>>>> MaxCaptures=2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> VC2- (the right camera stream), encoding group=EG0, >>>>>> view=table. >>>>>>>>>>>>>> MaxCaptures=2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> MCC3 (VC0, VC1, VC2) - encoding group=EG0, >> view=room, >>>>>>>>>>>>> MaxCaptures=2 >>>>>>>>>>>>> >>>>>>>>>>>>> [Duckworth, Mark] It isn't clear if you really mean "max >>>>>>>>>>>>> capture >>>>>>>>>>> encodings" >>>>>>>>>>>>> or >>>>>>>>>>>>> "max number of captures within a MCC". Those are two >>>>>>>>>>>>> different >>>>>>>>> things. >>>>>>>>>>>>>> Now it may be implied here that VC0, VC1, VC2 are >> simulcast. >>>>>>>>>>>>> [Duckworth, Mark] It depends how the consumer configures >> it. >>>>>>>>>>>>> The provider advertisement says it supports simulcast, so >>>>>>>>>>>>> the consumer can decide to use it or not. >>>>>>>>>>>>> >>>>>>>>>>>>>> What about MCC3? >>>>>>>>>>>>>> Is it multicast from one of the cameras or is it 2 MCs out >>>>>>>>>>>>>> of the three? (I assume it is the first since the view is >>>>>>>>>>>>>> room) >>>>>>>>>>>>> [Duckworth, Mark] MCC3 can provide 2 MCs out of the three >>>>>>>>>>>>> simultaneously only if it is composed, not if it is switched. >>>>>>>>>>>>> The provider can give more information, if it wants to, with >>>>>>>>>>>>> the MCC attribute "max number of captures within a MCC". >>>>>>>>>>>>> >>>>>>>>>>>>>> What if in the above example MaxCaptures=4 can it be for >>>>>>>>>>>>>> example VC0, >>>>>>>>>>>>> VC1 >>>>>>>>>>>>>> each with two simulcast streams or is it VC0, VC1, VC2 and >>>>>>>>>>>>>> one of them is >>>>>>>>>>>>> simulcast? >>>>>>>>>>>>> >>>>>>>>>>>>> [Duckworth, Mark] Neither. The MCC3 provides a single >>>>>> "conceptual" >>>>>>>>>>>>> capture. >>>>>>>>>>>>> It sounds like you are talking about a switched case, not a >>>>>>>>>>>>> composed case, so let's say MCC3 has the attribute "max >>>>>>>>>>>>> number of captures within >>>>>>>>>>> a >>>>>>>>>>>> MCC" = 1. >>>>>>>>>>>>> Now let's also suppose MCC3 has "max capture encodings" = >> 2. >>>>>>>>>>>>> Then the consumer can ask for, say, MCC3 at 720p and SIF, >>>>>>>>>>>>> for the two encodings. Then the provider decides when to >>>>>>>>>>>>> switch among VC0, VC1, and VC2, and whichever one the >>>>>>>>>>>>> provider is sending for >>>>>>>>>>>>> MCC3 it sends it at both SIF and 720p, so MCC3 is simulcast >>>>>>>>>>>>> at those two resolutions. >>>>>>>>>>>>> >>>>>>>>>>>>>> What I am trying to say is that using implied simulcast >>>>>>>>>>>>>> require text explaining when a consumer can understand >> that >>>>>>>>>>>>>> the advertisement is simulcast and not something else. >>>>>>>>>>>>>> The other approach may be to have an attribute for an MC >>>>>>>>>>>>>> and MCC that >>>>>>>>>>>>> will >>>>>>>>>>>>>> explicitly say that this is a simulcast offer. >>>>>>>>>>>>> [Duckworth, Mark] I think the advertisement is clear to the >>>>>>>>>>>>> consumer without any additional text or attributes added to >>>>>>>>>>>>> the framework. It is already explicit, with the attribute >>>>>>>>>>>>> "max capture encodings". If it is >1, then the >>>>>>>>>>>>> advertisement is offering >>>>>>>>>> simulcast. >>>>>>>>>>>>>> BTW: I think that the implied solution works when the >>>>>>>>>>>>>> individual encodings are the same (spatial or different >>>>>>>>>>>>>> codces) what if we the provider can send >>>>>>>>>>>>>> H.264 CIF and HD or VP8 CIF and HD. In the SDP this will be >>>>>>>>>>>>>> four different encodings but not all combinations allowed. >>>>>>>>>>>>>> How to represent it in an advertisement? Is it : >>>>>>>>>>>>> [Duckworth, Mark] I can consider this case after we get the >>>>>>>>>>>>> first case above cleared up. >>>>>>>>>>>>> >>>>>>>>>>>>>> VC0- (the left camera stream), encoding group=EG0, >>>>>>>>>>>>>> view=table, >>>>>>>>>>>>>> MaxCaptures=2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> VC1- (the center camera stream), encoding group=EG0, >>>>>>>>>>>>>> view=table, >>>>>>>>>>>>>> MaxCaptures=2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> VC2- (the right camera stream), encoding group=EG0, >>>>>> view=table. >>>>>>>>>>>>>> MaxCaptures=2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> VC3- (the left camera stream), encoding group=EG1, >>>>>>>>>>>>>> view=table, >>>>>>>>>>>>>> MaxCaptures=2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> VC4- (the center camera stream), encoding group=EG1, >>>>>>>>>>>>>> view=table, >>>>>>>>>>>>>> MaxCaptures=2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> VC5- (the right camera stream), encoding group=EG1, >>>>>> view=table. >>>>>>>>>>>>>> MaxCaptures=2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Where EG0 will be for H.264 and EG1 will be for VP8 and two >>>>>>>>>>>>>> scene views >>>>>>>>>>>>>> (VC0,VC1,VC2) (VC3, VC4, VC5)? >>>>>>>>>>>>>> >>>>>>>>>>>>> ... snip ... >>>>>>>>>>>>> >>>>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>>>> clue mailing list >>>>>>>>>>>>> clue@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>> _______________________________________________ >>>>>>>>>> clue mailing list >>>>>>>>>> clue@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>> _______________________________________________ >>>>>>>>> clue mailing list >>>>>>>>> clue@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> clue mailing list >>>>>>>> clue@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Nov 25 02:09: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 2868D1A0081 for ; Tue, 25 Nov 2014 02:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 bwJ-GZWvTJ11 for ; Tue, 25 Nov 2014 02:09:14 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28D81A00B1 for ; Tue, 25 Nov 2014 02:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1141; q=dns/txt; s=iport; t=1416910154; x=1418119754; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rjmZu0ImO272zrOH21Ar5o0Il6K6/iK7NB9cM5Q9VbA=; b=X4xXvvPPb0UyUApSZnZ7saYyizFSVjypzrc9TnxGZqhpyNMaem/t1DT1 Q+ULejzTZysLjFjpu3qBjElO7vejl9o0DICYPknc7Zxo6JkEydvvWlFMf 46rSEE8H3NeLyn/srM2TgSXq1+es37lwzAsakMazVa2LafO2x5y8aDSih E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAB1UdFStJA2M/2dsb2JhbABbgwZSVwTJFgqGUAKBExYBAQEBAX2EAgEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEEwiIOA3QaAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkEk4BoMogR8BBJJjjUuDWJIMg3x3gUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="99876489" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP; 25 Nov 2014 10:09:14 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sAPA9Dtl005054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Nov 2014 10:09:13 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.173]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 04:09:13 -0600 From: "Robert Hansen (rohanse2)" To: CLUE Thread-Topic: [clue] Consensus call: remove clue-specific simulcast Thread-Index: AQHQCDMWmqFd6P8eh0yqOo+KJlhJqpxxHoDQ Date: Tue, 25 Nov 2014 10:09:12 +0000 Message-ID: References: <5473AC21.7000205@alum.mit.edu> In-Reply-To: <5473AC21.7000205@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.64.203] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZnKQes_vBJL0ri5Z5AqaYiCrgaU Subject: Re: [clue] Consensus call: remove clue-specific simulcast X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 10:09:19 -0000 YES, I support removing this. (specifically, removing the maxCaptureEncodings element and mandating that = a capture can be mapped to at most one encoding). Rob -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 24 November 2014 22:07 To: CLUE Subject: [clue] Consensus call: remove clue-specific simulcast During the Honululu meeting we had consensus to remove the clue-specific si= mulcast mechanism (via configuring the same capture with two or more encodi= ngs). The expectation is that, in lieu of this clue will rely on an SDP mec= hanism for negotiating simulcast within a single m-line. (The mmusic wg ado= pted draft-westerlund-avtcore-rtp-simulcast-04 as a wg item at this meeting= .) This message brings that question to the list for confirmation. Please indicate if you support removal of the clue-specific simulcast mechanism: YES/NO. If you indicate NO, please provide a detailed reason why not. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Tue Nov 25 02:51: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 D06711A00C0 for ; Tue, 25 Nov 2014 02:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 G8V8uoHmZ9q9 for ; Tue, 25 Nov 2014 02:51:24 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6BD1A00B9 for ; Tue, 25 Nov 2014 02:51:23 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-64-54745f2994fa Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 74.8A.04076.92F54745; Tue, 25 Nov 2014 11:51:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 11:51:21 +0100 From: Christer Holmberg To: Paul Kyzivat , CLUE Thread-Topic: [clue] Consensus call: remove clue-specific simulcast Thread-Index: AQHQCDMSWhQ6XalF8EqylSUJZMIwM5xxKvRQ Date: Tue, 25 Nov 2014 10:51:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53534B@ESESSMB209.ericsson.se> References: <5473AC21.7000205@alum.mit.edu> In-Reply-To: <5473AC21.7000205@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja5WfEmIwdQTjBb7T11mtlix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJUx6VALa8FyjootE86zNTB+Yuti5OSQEDCR 2NSzghnCFpO4cG89UJyLQ0jgCKPEg4OXWSGcJYwSr+f9Zuxi5OBgE7CQ6P6nDdIgImAnMX/L VVYQW1jASeLw7LvsEHFniUnz/jBB2EYSV19fAFvGIqAq0XDrPwuIzSvgK7H1TzNYXEhAW2LP xgmMIDangI7El41rwHoZgQ76fgrCZhYQl7j1ZD4TxKECEkv2nIc6WlTi5eN/rCCnSQgoSUzb mgZRriOxYDfEj8xA45ctfM0MsVZQ4uTMJywTGEVnIZk6C0nLLCQts5C0LGBkWcUoWpxaXJyb bmSkl1qUmVxcnJ+nl5dasokRGCUHt/y22sF48LnjIUYBDkYlHt4NH4pDhFgTy4orcw8xSnOw KInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY0Mmq5wk56WaZ1P/75V62G08i5GB u8nCcILHtqD9ikqznF2Os7LV5ijtbTpy9WqvM+dBS6b9zT8SFvWxP95dUv+ucrfQ8jnfOxvD U/dW7dZg4blzedn36rlZDH//bFHdFVpmcEo1Puz/DePK4JIrYly6h6Oy+7W3hR9fuebSU57k u+nrnx+2VGIpzkg01GIuKk4EAHu0NdxzAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Jm3-YHdpfzaJ70Z7hHBITqhB-64 Subject: Re: [clue] Consensus call: remove clue-specific simulcast X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 10:51:26 -0000 YES, I support removing the clue-specific simulcast mechanism. Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 25. marraskuuta 2014 0:07 To: CLUE Subject: [clue] Consensus call: remove clue-specific simulcast During the Honululu meeting we had consensus to remove the clue-specific si= mulcast mechanism (via configuring the same capture with two or more encodi= ngs). The expectation is that, in lieu of this clue will rely on an SDP mec= hanism for negotiating simulcast within a single m-line. (The mmusic wg ado= pted draft-westerlund-avtcore-rtp-simulcast-04 as a wg item at this meeting= .) This message brings that question to the list for confirmation. Please indicate if you support removal of the clue-specific simulcast mechanism: YES/NO. If you indicate NO, please provide a detailed reason why not. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Tue Nov 25 03:23: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 794B21A00A9 for ; Tue, 25 Nov 2014 03:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=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 STc2tTqL84Ac for ; Tue, 25 Nov 2014 03:23:53 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE041A008B for ; Tue, 25 Nov 2014 03:23:52 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-31-547466c6b717 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A7.A0.04076.6C664745; Tue, 25 Nov 2014 12:23:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 12:23:50 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHwAAJH5gAGzPFIAABv9ZSQApnc6AABrtWkA= Date: Tue, 25 Nov 2014 11:23:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53548A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> <5473BE59.4070805@nteczone.com> In-Reply-To: <5473BE59.4070805@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje6xtJIQg3NLrSy+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJUxZdkRxoJbphWr7s5lb2BcYdLFyMkhIWAi sfTLXBYIW0ziwr31bF2MXBxCAkcYJZYf/s4E4SxhlGj7PZmxi5GDg03AQqL7nzZIg4hAuETH tiuMILawgLtEx+HTLBBxD4l3WzYwQ9h+EhM2T2ECsVkEVCUWr53KBmLzCvhKtL/tYgWxhQRm MUkcnGQIYnMK6EicPf8GrJcR6KDvp9aA9TILiEvcejKfCeJQAYkle84zQ9iiEi8f/2MFOU1C QEli2tY0EJNZQFNi/S59iE5FiSndD9khtgpKnJz5hGUCo+gsJENnIXTMQtIxC0nHAkaWVYyi xanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBEXJwy2+rHYwHnzseYhTgYFTi4d3woThEiDWxrLgy 9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwTpzp4LPr1O6p55b9EDuy ry1sYXWrY/WkluUOAvJl1vx7WcP58k+FLn22nclY43XBNaM97j89pTbMzdh0Krz604u0w5N1 K2s7JwYW9RxZqzrxW41nwoFPeqFM6WaKqRIOXN4Z26cctExQuxp150TeFP/Gd991di/8dmb7 4kT+l09rNjxIvWbdpcRSnJFoqMVcVJwIAHNe9IhxAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/O0mpxscEOYeF2PDR4nNKogvrPzk Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 11:23:55 -0000 SGksDQoNCklmIEkgdW5kZXJzdG9vZCBQYXVsJ3MgY29tbWVudCwgRENFUCBpcyBub3QgcmVxdWly ZWQgZm9yIGNvbXBhdGliaWxpdHkgd2l0aCBXZWJSVEMgZW5kcG9pbnRzLiBJZiB5b3UgcHJvdmlk ZSB0aGUgU0NUUCBwb3J0IGluIHRoZSBXZWJSVEMgQVBJLCB0aGVuIERDRVAgd29uJ3QgYmUgdXNl ZC4NCg0KVGhlIHF1ZXN0aW9uIGlzIHJlYWxseSB3aGV0aGVyIHdlIHdhbnQgdG8gbWFuZGF0ZSBu b24tV2ViUlRDIENMVUUgZGV2aWNlcyB0byBpbXBsZW1lbnQgRENFUCBvciBub3QuDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjbHVl IFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIEdy b3Zlcw0KU2VudDogMjUuIG1hcnJhc2t1dXRhIDIwMTQgMToyNQ0KVG86IGNsdWVAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbY2x1ZV0gRlc6IGRyYWZ0LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5uZWwt c2RwbmVnIGFuZCBEQ0VQDQoNCkkgdGhvdWdodCB0aGUgcmVhc29uIHdlIHVzZWQgRENFUCB3YXMg c28gdGhhdCBpdCB3YXMgY29tcGF0aWJsZSB3aXRoIFdlYlJUQyBlbmRwb2ludHMuIFNvIGlzIHRo aXMgbm90IGEgY29uY2VybiBhbnltb3JlPw0KDQpNeSB2aWV3IGlzIHRoYXQgaXQgc2hvdWxkIGJl IHBvc3NpYmxlIHRvIHVzZSBleHRlcm5hbCBuZWdvdGlhdGlvbiB0byBuZWdvdGlhdGUgdGhlIHBy b3RvY29scyB0aGF0IGFyZSB1c2VkIGZvciB0aGUgZGF0YSBjaGFubmVsIGFuZCB0aGVuIHVzZSBE Q0VQIHRvIGVzdGFibGlzaCB0aGUgU0NUUCBjaGFubmVsLiBUaGlzIGVmZmVjdGl2ZWx5IGVtdWxh dGVzIHdoYXQgd2UgaGFkIGluIG91ciBDTFVFIGRhdGEgY2hhbm5lbCBkcmFmdCB3aGVyZSB0aGUg YT1HUk9VUDpDTFVFIG9uIHRoZSBkYXRhY2hhbm5lbCBtPWxpbmUgaW5kaWNhdGVkIHRoYXQgQ0xV RSB3b3VsZCBiZSB1c2VkIGFuZCB0aGVuIERDRVAgd2FzIHVzZWQgdG8gZXN0YWJsaXNoIHRoZSBT Q1RQIGNoYW5uZWwuDQoNCkNocmlzdGlhbg0KDQpPbiAyNC8xMS8yMDE0IDE6MzMgUE0sIENocmlz dGVyIEhvbG1iZXJnIHdyb3RlOg0KPiBIaSwNCj4NCj4gSSBhZ3JlZSB3aXRoIHdoYXQgeW91IGFy ZSBzYXlpbmcsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIERDRVAgaWYgd2UgdXNlIA0KPiBleHRlcm5h bCBuZWdvdGlhdGlvbi4NCj4NCj4gVGhlIHF1ZXN0aW9uIGlzIHRoZW4gd2hldGhlciB3ZSBzaG91 bGQgcmVtb3ZlIERDRVAgY29tcGxldGVseSBmcm9tIHRoZSANCj4gQ0xVRSBkYXRhIGNoYW5uZWwg ZHJhZnQ/DQo+DQo+IERDRVAgY291bGQgYmUgdXNlZnVsIGlmIHNvbWVvbmUgaW1wbGVtZW50ZWQg Q0xVRSB1c2luZyBhbm90aGVyIA0KPiBzaWduYWxsaW5nIHByb3RvY29sIHRoYW4gU0lQL1NEUCwg YnV0IHdlIGFyZSBub3Qgc3BlY2lmeWluZyBzdWNoIA0KPiB1c2FnZSwgc28uLi4NCj4NCj4gUmVn YXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4gU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiBGcm9tOiBQYXVsIEt5eml2YXQgPG1haWx0bzpwa3l6aXZh dEBhbHVtLm1pdC5lZHU+DQo+IFNlbnQ6IOKAjjI0L+KAjjExL+KAjjIwMTQgMDI6MTMNCj4gVG86 IGNsdWVAaWV0Zi5vcmcgPG1haWx0bzpjbHVlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW2Ns dWVdIEZXOiBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBhbmQgDQo+IERD RVANCj4NCj4gT24gMTEvMjEvMTQgMjoyMCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+ ID4gRllJLA0KPiA+DQo+ID4gSSBzZW50IHRoZSBmb2xsb3dpbmcgdG8gdGhlIE1NVVNJQyBsaXN0 Lg0KPiA+DQo+ID4gVGhlIENMVUUgZGF0YSBjaGFubmVsIGRyYWZ0IGN1cnJlbnRseSBhc3N1bWVz IHRoYXQgRENFUCBpcyB1c2VkIHRvIA0KPiA+IG9wZW4gdGhlIENMVUUgZGF0YSBjaGFubmVsLCBv bmNlIGl0IGhhcyBiZWVuIG5lZ290aWF0ZWQgdXNpbmcgZHJhZnQtZWp6YWsuDQo+ID4NCj4gPiBI b3dldmVyLCBpZiBkcmFmdC1lanphayBmb3JiaWRzIHVzYWdlIG9mIERDRVAsIGFuZC9vciB3ZSBk b27igJl0IHRoaW5rIA0KPiA+IGl04oCZcyBuZWVkZWQgZm9yIHRoZSBDTFVFIGRhdGEgY2hhbm5l bCwgd2UgY2FuIHJlbW92ZSBpdC4NCj4gPg0KPiA+IEluIG15IG9waW5pb24sIHRoZSBhZHZhbnRh Z2Ugb2YgYWxzbyB1c2luZyBEQ0VQIGlzIHRoYXQgdGhlIA0KPiA+IGVuZHBvaW50cyBjYW4gY2hv b3NlIHdoZW4gdG8gb3BlbiB0aGUgZGF0YSBjaGFubmVsIOKAkyBvdGhlcndpc2UgaXQgaXMgDQo+ ID4gY29uc2lkZXJlZCBvcGVuIG9uY2UgdGhlIFNDVFAgYXNzb2NpYXRpb24gaGFzIGJlZW4gY3Jl YXRlZC4NCj4NCj4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IERDRVAgaXMgKm5vdCogdXNlZC4g V2hlbiB5b3UgdXNlIGV4dGVybmFsIA0KPiBuZWdvdGlhdGlvbiB5b3Ugc2ltcGx5IGFncmVlIChl eHRlcm5hbGx5KSBvbiB3aGljaCBzdHJlYW0gaWRzIGFyZSB0byANCj4gYmUgdXNlZCAodGhleSBk b24ndCBldmVuIGhhdmUgdG8gYmUgdGhlIHNhbWUgaW4gZWFjaCBkaXJlY3Rpb24pIGFuZCANCj4g c3RhcnQgdXNpbmcgdGhlbS4NCj4NCj4gSSBjb3VsZCBiZSB3cm9uZywgYnV0IEkgZG9uJ3QgdGhp bmsgdGhlIHdlYnJ0YyBBUEkgaGFzIGEgd2F5IGZvciB5b3UgDQo+IHRvIHVzZSB0aGUgRENFUCBw cm90b2NvbCBvbiBhbiBleHRlcm5hbGx5IGFsbG9jYXRlZCBjaGFubmVsLiBZb3UgY2FuIA0KPiBj YWxsIHRvIG9wZW4gYSBjaGFubmVsIHdpdGhvdXQgc3VwcGx5aW5nIGEgc3RyZWFtIGlkLCBpbiB3 aGljaCBjYXNlIA0KPiBEQ0VQIGlzIGF1dG9tYXRpY2FsbHkgdXNlZCB0byBhc3NpZ24gdGhlIGlk KSwgb3IgZWxzZSB5b3UgY2FuIHN1cHBseSBhIA0KPiBzdHJlYW0gaWQgd2hlbiBvcGVuaW5nIGEg Y2hhbm5lbCAoaW4gd2hpY2ggY2FzZSBEQ0VQIGlzIG5vdCB1c2VkKS4NCj4NCj4gSSBzdXBwb3Nl IG5vdGhpbmcgcHJldmVudHMgeW91IGZyb20gdXNpbmcgRENFUCBtZXNzYWdlcyBvbiB5b3VyIA0K PiBleHRlcm5hbGx5IGFsbG9jYXRlZCBjaGFubmVsLCBidXQgdGhlbiB5b3Ugd291bGQgaGF2ZSB0 byBmb3JtYXQgYW5kIA0KPiBzZW5kIHRoZW0geW91cnNlbGYsIGFuZCBkZWNvZGUgdGhlbSBhdCB0 aGUgb3RoZXIgZW5kLCByYXRoZXIgdGhhbiANCj4gaGF2aW5nIHRoZSBsaWJyYXJ5IGJlaGluZCB0 aGUgQVBJIGRvaW5nIGl0IGZvciB5b3UuDQo+DQo+IFRoYW5rcywNCj4gUGF1bA0KPg0KPiA+IFJl Z2FyZHMsDQo+ID4NCj4gPiBDaHJpc3Rlcg0KPiA+DQo+ID4gKkZyb206Km1tdXNpYyBbbWFpbHRv Om1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mIA0KPiA+ICpDaHJpc3RlciBI b2xtYmVyZw0KPiA+ICpTZW50OiogMjEgTm92ZW1iZXIgMjAxNCAyMToxNw0KPiA+ICpUbzoqIG1t dXNpY0BpZXRmLm9yZw0KPiA+ICpTdWJqZWN0OiogW01NVVNJQ10gZHJhZnQtZWp6YWstbW11c2lj LWRhdGEtY2hhbm5lbC1zZHBuZWcgYW5kIERDRVANCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gZHJh ZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcgY3VycmVudGx5IHNlZW1zIHRvIGFz c3VtZSANCj4gPiB0aGF0IERDRVAgd2lsbCBub3QgYmUgdXNlZCB0byBvcGVuIGRhdGEgY2hhbm5l bHMg4oCTIGluc3RlYWQgZGF0YSANCj4gPiBjaGFubmVscyB3aWxsIGJlIGNvbnNpZGVyZWQgb3Bl biBvbmNlIHRoZSBTRFAgTy9BIG5lZ290aWF0aW9uIGhhcyANCj4gPiBmaW5pc2hlZCBhbmQgdGhl IFNDVFAgYXNzb2NpYXRpb24gdXNlZCB0byByZWFsaXplIHRoZSBkYXRhIGNoYW5uZWwocykgaGFz IGJlZW4gY3JlYXRlZC4NCj4gPg0KPiA+IE15IHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhlIGludGVu dGlvbiBpcyB0byBmb3JiaWQgdXNhZ2Ugb2YgRENFUCANCj4gPiB0b2dldGhlciB3aXRoIGRyYWZ0 LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLCBvciB3aGV0aGVyIGl0IA0KPiA+IHNo b3VsZCBiZSBvcHRpb25hbD8NCj4gPg0KPiA+IElmIG9wdGlvbmFsLCB0aGVyZSBuZWVkcyB0byBi ZSBhIHdheSB0byBpbmRpY2F0ZSB0aGF0IGFwcGxpY2F0aW9uIA0KPiA+IGRhdGEgc2hhbGwgbm90 IGJlIHNlbnQgdW50aWwgYSBjaGFubmVsIGhhcyBiZWVuIG9wZW5lZCB1c2luZyBEQ0VQLiANCj4g PiBJbiBhZGRpdGlvbiwgaXQgd291bGQgYmUgdXNlZnVsIHRvIGJlIGFibGUgdG8gaW5kaWNhdGUg d2hpY2ggDQo+ID4gZW5kcG9pbnQgaXMgcmVzcG9uc2libGUgZm9yIHNlbmRpbmcgdGhlIERDRVBf Q0hBTk5FTF9PUEVOIG1lc3NhZ2UuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+DQo+ID4gQ2hyaXN0 ZXINCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IGNsdWUgbWFpbGluZyBsaXN0DQo+ID4gY2x1ZUBpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiA+DQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNsdWUg bWFpbGluZyBsaXN0DQo+IGNsdWVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jbHVlDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IGNsdWUgbWFpbGluZyBsaXN0DQo+IGNsdWVAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjbHVlIG1haWxpbmcgbGlz dA0KY2x1ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j bHVlDQo= From nobody Tue Nov 25 03:33: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 8C5F01A00E8 for ; Tue, 25 Nov 2014 03:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=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 2cjYNKPKeMfh for ; Tue, 25 Nov 2014 03:33:06 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CC81A00F0 for ; Tue, 25 Nov 2014 03:33:05 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-89-547468ef62df Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.94.04231.FE864745; Tue, 25 Nov 2014 12:33:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 12:33:03 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , Christian Groves , "clue@ietf.org" Thread-Topic: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHwAAJH5gAGzPFIAABv9ZSQApnc6AAABUMQAAGyQk4A== Date: Tue, 25 Nov 2014 11:33:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5354E2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> <5473BE59.4070805@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.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje6HjJIQg/UdfBZf3jeyWOw/dZnZ omHjFVYHZo/WZ3tZPZYs+cnkseL8TJYA5igum5TUnMyy1CJ9uwSujKXvz7MUzLOp+LrmFGMD 4w2rLkZODgkBE4mpOzaxQ9hiEhfurWfrYuTiEBI4wiixeNdDRghnCaPEn/8HmLoYOTjYBCwk uv9pg8RFBOYwSmx+c48JpFtYwF2i4/BpFhBbRMBD4t2WDcwQdpjEzXvXwWpYBFQl1sy5zAhi 8wr4Suzo2MoCseAtk8TzuxBncArESrze9IgVxGYEOun7qTVgzcwC4hK3nsxngjhVQGLJnvPM ELaoxMvH/1hBjpMQUJKYtjUNxGQW0JRYv0sfolNRYkr3Q3aItYISJ2c+YZnAKDoLydBZCB2z kHTMQtKxgJFlFaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZg5Bzc8lt3B+Pq146HGAU4GJV4 eDd8KA4RYk0sK67MPcQozcGiJM676Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MGTv5 rlYs1Nx+V3FVpSTnxKd//vxfw2Of//fZmaxjK/9ppnfbP9rYO7/FpkJWyPXpT55tjnf7P3a+ Zt2ux9G0ZKFX42uN+o3Z/PuPLpu0oNb3GN/L+mKB+efmBrlNX3/n4oz5m1/cPRP6Y9bbWuWJ N2w3HzZaljQnuy3y1Iw58ptunM+Yfe+wVaMSS3FGoqEWc1FxIgCf7D4OfQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/SuJgoySjpeyFqZNBQp6l1EkX3JE Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 11:33:08 -0000 SGksDQoNCj5QZXIgZGlzY3Vzc2lvbnMgd2l0aCBDaHJpc3RpYW4sIHdlIGFyZSBnb2luZyB0byBw cm9wb3NlIG5ldyBiYWNrd2FyZCBjb21wYXRpYmxlIHN5bnRheCBhbmQgdXNlIGNhc2VzIG9mIGVq emFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnIHRvIHVzZSBpdCBleHRlcm5hbCBuZWdvdGlh dGlvbiBvZiBzdWJwcm90b2NvbChzKSBhbmQgdGhlaXIgYXR0cmlidXRlcyB3aGlsZSB1c2luZyBE Q0VQIGZvciBlc3RhYmxpc2htZW50IG9mIHRoZSBEQy4gDQo+DQo+V2Ugd2lsbCB1cGRhdGUgTU1V U0lDIGxpc3QgZm9yIGZlZWRiYWNrIG9uIHRoZSBwcm9wb3NhbCBhbmQgd2lsbCBjYyBjbHVlIGFs aWFzLg0KDQpQbGVhc2UgZG9uJ3QgY3Jvc3MtcG9zdCBvbiBtdWx0aXBsZSBsaXN0cy4gSW50ZXJl c3RlZCBwZW9wbGUgc2hvdWxkIGZvbGxvdyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgTU1VU0lDIGxp c3QuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IGNsdWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBDaHJpc3RpYW4gDQo+IEdyb3Zlcw0KPiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDI0 LCAyMDE0IDU6MjUgUE0NCj4gVG86IGNsdWVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtjbHVl XSBGVzogZHJhZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcgYW5kIA0KPiBEQ0VQ DQo+IA0KPiBJIHRob3VnaHQgdGhlIHJlYXNvbiB3ZSB1c2VkIERDRVAgd2FzIHNvIHRoYXQgaXQg d2FzIGNvbXBhdGlibGUgd2l0aCANCj4gV2ViUlRDIGVuZHBvaW50cy4gU28gaXMgdGhpcyBub3Qg YSBjb25jZXJuIGFueW1vcmU/DQo+IA0KPiBNeSB2aWV3IGlzIHRoYXQgaXQgc2hvdWxkIGJlIHBv c3NpYmxlIHRvIHVzZSBleHRlcm5hbCBuZWdvdGlhdGlvbiB0byANCj4gbmVnb3RpYXRlIHRoZSBw cm90b2NvbHMgdGhhdCBhcmUgdXNlZCBmb3IgdGhlIGRhdGEgY2hhbm5lbCBhbmQgdGhlbiANCj4g dXNlIERDRVAgdG8gZXN0YWJsaXNoIHRoZSBTQ1RQIGNoYW5uZWwuIFRoaXMgZWZmZWN0aXZlbHkg ZW11bGF0ZXMgd2hhdCANCj4gd2UgaGFkIGluIG91ciBDTFVFIGRhdGEgY2hhbm5lbCBkcmFmdCB3 aGVyZSB0aGUgYT1HUk9VUDpDTFVFIG9uIHRoZSANCj4gZGF0YWNoYW5uZWwgbT1saW5lIGluZGlj YXRlZCB0aGF0IENMVUUgd291bGQgYmUgdXNlZCBhbmQgdGhlbiBEQ0VQIHdhcyANCj4gdXNlZCB0 byBlc3RhYmxpc2ggdGhlIFNDVFAgY2hhbm5lbC4NCj4gDQo+IENocmlzdGlhbg0KPiANCj4gT24g MjQvMTEvMjAxNCAxOjMzIFBNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gPiBIaSwNCj4g Pg0KPiA+IEkgYWdyZWUgd2l0aCB3aGF0IHlvdSBhcmUgc2F5aW5nLCB0aGVyZSBpcyBubyBuZWVk IGZvciBEQ0VQIGlmIHdlIA0KPiA+IHVzZSBleHRlcm5hbCBuZWdvdGlhdGlvbi4NCj4gPg0KPiA+ IFRoZSBxdWVzdGlvbiBpcyB0aGVuIHdoZXRoZXIgd2Ugc2hvdWxkIHJlbW92ZSBEQ0VQIGNvbXBs ZXRlbHkgZnJvbSANCj4gPiB0aGUgQ0xVRSBkYXRhIGNoYW5uZWwgZHJhZnQ/DQo+ID4NCj4gPiBE Q0VQIGNvdWxkIGJlIHVzZWZ1bCBpZiBzb21lb25lIGltcGxlbWVudGVkIENMVUUgdXNpbmcgYW5v dGhlciANCj4gPiBzaWduYWxsaW5nIHByb3RvY29sIHRoYW4gU0lQL1NEUCwgYnV0IHdlIGFyZSBu b3Qgc3BlY2lmeWluZyBzdWNoIA0KPiA+IHVzYWdlLCBzby4uLg0KPiA+DQo+ID4gUmVnYXJkcywN Cj4gPg0KPiA+IENocmlzdGVyDQo+ID4NCj4gPiBTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0K PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+ID4gLS0tLQ0KPiA+IEZyb206IFBhdWwgS3l6aXZhdCA8bWFpbHRv OnBreXppdmF0QGFsdW0ubWl0LmVkdT4NCj4gPiBTZW50OiDigI4yNC/igI4xMS/igI4yMDE0IDAy OjEzDQo+ID4gVG86IGNsdWVAaWV0Zi5vcmcgPG1haWx0bzpjbHVlQGlldGYub3JnPg0KPiA+IFN1 YmplY3Q6IFJlOiBbY2x1ZV0gRlc6IGRyYWZ0LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2Rw bmVnIGFuZCANCj4gPiBEQ0VQDQo+ID4NCj4gPiBPbiAxMS8yMS8xNCAyOjIwIFBNLCBDaHJpc3Rl ciBIb2xtYmVyZyB3cm90ZToNCj4gPiA+IEZZSSwNCj4gPiA+DQo+ID4gPiBJIHNlbnQgdGhlIGZv bGxvd2luZyB0byB0aGUgTU1VU0lDIGxpc3QuDQo+ID4gPg0KPiA+ID4gVGhlIENMVUUgZGF0YSBj aGFubmVsIGRyYWZ0IGN1cnJlbnRseSBhc3N1bWVzIHRoYXQgRENFUCBpcyB1c2VkIHRvIA0KPiA+ ID4gb3BlbiB0aGUgQ0xVRSBkYXRhIGNoYW5uZWwsIG9uY2UgaXQgaGFzIGJlZW4gbmVnb3RpYXRl ZCB1c2luZyBkcmFmdC1lanphay4NCj4gPiA+DQo+ID4gPiBIb3dldmVyLCBpZiBkcmFmdC1lanph ayBmb3JiaWRzIHVzYWdlIG9mIERDRVAsIGFuZC9vciB3ZSBkb27igJl0IA0KPiA+ID4gdGhpbmsg aXTigJlzIG5lZWRlZCBmb3IgdGhlIENMVUUgZGF0YSBjaGFubmVsLCB3ZSBjYW4gcmVtb3ZlIGl0 Lg0KPiA+ID4NCj4gPiA+IEluIG15IG9waW5pb24sIHRoZSBhZHZhbnRhZ2Ugb2YgYWxzbyB1c2lu ZyBEQ0VQIGlzIHRoYXQgdGhlIA0KPiA+ID4gZW5kcG9pbnRzIGNhbiBjaG9vc2Ugd2hlbiB0byBv cGVuIHRoZSBkYXRhIGNoYW5uZWwg4oCTIG90aGVyd2lzZSBpdCANCj4gPiA+IGlzIGNvbnNpZGVy ZWQgb3BlbiBvbmNlIHRoZSBTQ1RQIGFzc29jaWF0aW9uIGhhcyBiZWVuIGNyZWF0ZWQuDQo+ID4N Cj4gPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgRENFUCBpcyAqbm90KiB1c2VkLiBXaGVuIHlv dSB1c2UgZXh0ZXJuYWwgDQo+ID4gbmVnb3RpYXRpb24geW91IHNpbXBseSBhZ3JlZSAoZXh0ZXJu YWxseSkgb24gd2hpY2ggc3RyZWFtIGlkcyBhcmUgdG8gDQo+ID4gYmUgdXNlZCAodGhleSBkb24n dCBldmVuIGhhdmUgdG8gYmUgdGhlIHNhbWUgaW4gZWFjaCBkaXJlY3Rpb24pIGFuZCANCj4gPiBz dGFydCB1c2luZyB0aGVtLg0KPiA+DQo+ID4gSSBjb3VsZCBiZSB3cm9uZywgYnV0IEkgZG9uJ3Qg dGhpbmsgdGhlIHdlYnJ0YyBBUEkgaGFzIGEgd2F5IGZvciB5b3UgDQo+ID4gdG8gdXNlIHRoZSBE Q0VQIHByb3RvY29sIG9uIGFuIGV4dGVybmFsbHkgYWxsb2NhdGVkIGNoYW5uZWwuIFlvdSBjYW4g DQo+ID4gY2FsbCB0byBvcGVuIGEgY2hhbm5lbCB3aXRob3V0IHN1cHBseWluZyBhIHN0cmVhbSBp ZCwgaW4gd2hpY2ggY2FzZSANCj4gPiBEQ0VQIGlzIGF1dG9tYXRpY2FsbHkgdXNlZCB0byBhc3Np Z24gdGhlIGlkKSwgb3IgZWxzZSB5b3UgY2FuIHN1cHBseSANCj4gPiBhIHN0cmVhbSBpZCB3aGVu IG9wZW5pbmcgYSBjaGFubmVsIChpbiB3aGljaCBjYXNlIERDRVAgaXMgbm90IHVzZWQpLg0KPiA+ DQo+ID4gSSBzdXBwb3NlIG5vdGhpbmcgcHJldmVudHMgeW91IGZyb20gdXNpbmcgRENFUCBtZXNz YWdlcyBvbiB5b3VyIA0KPiA+IGV4dGVybmFsbHkgYWxsb2NhdGVkIGNoYW5uZWwsIGJ1dCB0aGVu IHlvdSB3b3VsZCBoYXZlIHRvIGZvcm1hdCBhbmQgDQo+ID4gc2VuZCB0aGVtIHlvdXJzZWxmLCBh bmQgZGVjb2RlIHRoZW0gYXQgdGhlIG90aGVyIGVuZCwgcmF0aGVyIHRoYW4gDQo+ID4gaGF2aW5n IHRoZSBsaWJyYXJ5IGJlaGluZCB0aGUgQVBJIGRvaW5nIGl0IGZvciB5b3UuDQo+ID4NCj4gPiBU aGFua3MsDQo+ID4gUGF1bA0KPiA+DQo+ID4gPiBSZWdhcmRzLA0KPiA+ID4NCj4gPiA+IENocmlz dGVyDQo+ID4gPg0KPiA+ID4gKkZyb206Km1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGll dGYub3JnXSAqT24gQmVoYWxmIE9mIA0KPiA+ID4gKkNocmlzdGVyIEhvbG1iZXJnDQo+ID4gPiAq U2VudDoqIDIxIE5vdmVtYmVyIDIwMTQgMjE6MTcNCj4gPiA+ICpUbzoqIG1tdXNpY0BpZXRmLm9y Zw0KPiA+ID4gKlN1YmplY3Q6KiBbTU1VU0lDXSBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFu bmVsLXNkcG5lZyBhbmQgDQo+ID4gPiBEQ0VQDQo+ID4gPg0KPiA+ID4gSGksDQo+ID4gPg0KPiA+ ID4gZHJhZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcgY3VycmVudGx5IHNlZW1z IHRvIGFzc3VtZSANCj4gPiA+IHRoYXQgRENFUCB3aWxsIG5vdCBiZSB1c2VkIHRvIG9wZW4gZGF0 YSBjaGFubmVscyDigJMgaW5zdGVhZCBkYXRhIA0KPiA+ID4gY2hhbm5lbHMgd2lsbCBiZSBjb25z aWRlcmVkIG9wZW4gb25jZSB0aGUgU0RQIE8vQSBuZWdvdGlhdGlvbiBoYXMgDQo+ID4gPiBmaW5p c2hlZCBhbmQgdGhlIFNDVFAgYXNzb2NpYXRpb24gdXNlZCB0byByZWFsaXplIHRoZSBkYXRhIGNo YW5uZWwocykgaGFzIGJlZW4gY3JlYXRlZC4NCj4gPiA+DQo+ID4gPiBNeSBxdWVzdGlvbiBpcyB3 aGV0aGVyIHRoZSBpbnRlbnRpb24gaXMgdG8gZm9yYmlkIHVzYWdlIG9mIERDRVAgDQo+ID4gPiB0 b2dldGhlciB3aXRoIGRyYWZ0LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLCBvciB3 aGV0aGVyIA0KPiA+ID4gaXQgc2hvdWxkIGJlIG9wdGlvbmFsPw0KPiA+ID4NCj4gPiA+IElmIG9w dGlvbmFsLCB0aGVyZSBuZWVkcyB0byBiZSBhIHdheSB0byBpbmRpY2F0ZSB0aGF0IGFwcGxpY2F0 aW9uIA0KPiA+ID4gZGF0YSBzaGFsbCBub3QgYmUgc2VudCB1bnRpbCBhIGNoYW5uZWwgaGFzIGJl ZW4gb3BlbmVkIHVzaW5nIERDRVAuIA0KPiA+ID4gSW4gYWRkaXRpb24sIGl0IHdvdWxkIGJlIHVz ZWZ1bCB0byBiZSBhYmxlIHRvIGluZGljYXRlIHdoaWNoIA0KPiA+ID4gZW5kcG9pbnQgaXMgcmVz cG9uc2libGUgZm9yIHNlbmRpbmcgdGhlIERDRVBfQ0hBTk5FTF9PUEVOIG1lc3NhZ2UuDQo+ID4g Pg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+DQo+ID4gPiBDaHJpc3Rlcg0KPiA+ID4NCj4gPiA+DQo+ ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiA+IGNsdWUgbWFpbGluZyBsaXN0DQo+ID4gPiBjbHVlQGlldGYub3JnDQo+ID4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4gPiA+DQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGNs dWUgbWFpbGluZyBsaXN0DQo+ID4gY2x1ZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGNsdWUgbWFpbGluZyBsaXN0DQo+ ID4gY2x1ZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2x1ZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpjbHVlIG1haWxpbmcgbGlzdA0KY2x1ZUBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo= From nobody Tue Nov 25 03:41: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 40AA91A00B9 for ; Tue, 25 Nov 2014 03:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 SoUxE4qUPoDU for ; Tue, 25 Nov 2014 03:41:18 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8CD1A00D0 for ; Tue, 25 Nov 2014 03:41:17 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 90A249F5AF811; Tue, 25 Nov 2014 11:41:13 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sAPBfDai020040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 06:41:13 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 06:41:13 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Christian Groves , "clue@ietf.org" Thread-Topic: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHwBvENaOAA9cNwAAK7ZTgAAZGO8AAAoBUIA= Date: Tue, 25 Nov 2014 11:41:12 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> <5473BE59.4070805@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D53548A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D53548A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/0djaHSqjZJIgIZAw2R_TqZhM_jw Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 11:41:20 -0000 PiBJZiB5b3UgcHJvdmlkZSB0aGUgU0NUUCBwb3J0IGluIHRoZSBXZWJSVEMgQVBJLCB0aGVuIERD RVAgd29uJ3QgYmUgdXNlZC4NCllvdSBtZWFudCAiKHN0cmVhbSkgaWQiIGluc3RlYWQgb2YgIlND VFAgcG9ydCI/IEluIFdlYlJUQyBBUEkgY3JlYXRlRGF0YUNoYW5uZWwoKSwgdXNlIG9mIERDRVAg aXMgY29udHJvbGxlZCBieSB1c2luZyAibmVnb3RpYXRlZCIgcGFyYW1ldGVyLiAoU3RyZWFtKSBp ZCBzcGVjaWZpY2F0aW9uIG9ubHkgZGV0ZXJtaW5lcyB0aGUgc3RyZWFtIGlkIHRvIGJlIHVzZWQu DQoNCkJSDQpSYWp1DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBj bHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIg SG9sbWJlcmcNCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjUsIDIwMTQgNToyNCBBTQ0KPiBU bzogQ2hyaXN0aWFuIEdyb3ZlczsgY2x1ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2NsdWVd IEZXOiBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBhbmQgRENFUA0KPiAN Cj4gSGksDQo+IA0KPiBJZiBJIHVuZGVyc3Rvb2QgUGF1bCdzIGNvbW1lbnQsIERDRVAgaXMgbm90 IHJlcXVpcmVkIGZvciBjb21wYXRpYmlsaXR5IHdpdGgNCj4gV2ViUlRDIGVuZHBvaW50cy4gSWYg eW91IHByb3ZpZGUgdGhlIFNDVFAgcG9ydCBpbiB0aGUgV2ViUlRDIEFQSSwgdGhlbiBEQ0VQDQo+ IHdvbid0IGJlIHVzZWQuDQo+IA0KPiBUaGUgcXVlc3Rpb24gaXMgcmVhbGx5IHdoZXRoZXIgd2Ug d2FudCB0byBtYW5kYXRlIG5vbi1XZWJSVEMgQ0xVRSBkZXZpY2VzIHRvDQo+IGltcGxlbWVudCBE Q0VQIG9yIG5vdC4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2x1ZSBbbWFpbHRvOmNsdWUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGlhbiBHcm92ZXMNCj4gU2VudDogMjUuIG1hcnJh c2t1dXRhIDIwMTQgMToyNQ0KPiBUbzogY2x1ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2Ns dWVdIEZXOiBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBhbmQgRENFUA0K PiANCj4gSSB0aG91Z2h0IHRoZSByZWFzb24gd2UgdXNlZCBEQ0VQIHdhcyBzbyB0aGF0IGl0IHdh cyBjb21wYXRpYmxlIHdpdGggV2ViUlRDDQo+IGVuZHBvaW50cy4gU28gaXMgdGhpcyBub3QgYSBj b25jZXJuIGFueW1vcmU/DQo+IA0KPiBNeSB2aWV3IGlzIHRoYXQgaXQgc2hvdWxkIGJlIHBvc3Np YmxlIHRvIHVzZSBleHRlcm5hbCBuZWdvdGlhdGlvbiB0bw0KPiBuZWdvdGlhdGUgdGhlIHByb3Rv Y29scyB0aGF0IGFyZSB1c2VkIGZvciB0aGUgZGF0YSBjaGFubmVsIGFuZCB0aGVuIHVzZSBEQ0VQ DQo+IHRvIGVzdGFibGlzaCB0aGUgU0NUUCBjaGFubmVsLiBUaGlzIGVmZmVjdGl2ZWx5IGVtdWxh dGVzIHdoYXQgd2UgaGFkIGluIG91cg0KPiBDTFVFIGRhdGEgY2hhbm5lbCBkcmFmdCB3aGVyZSB0 aGUgYT1HUk9VUDpDTFVFIG9uIHRoZSBkYXRhY2hhbm5lbCBtPWxpbmUNCj4gaW5kaWNhdGVkIHRo YXQgQ0xVRSB3b3VsZCBiZSB1c2VkIGFuZCB0aGVuIERDRVAgd2FzIHVzZWQgdG8gZXN0YWJsaXNo IHRoZQ0KPiBTQ1RQIGNoYW5uZWwuDQo+IA0KPiBDaHJpc3RpYW4NCj4gDQo+IE9uIDI0LzExLzIw MTQgMTozMyBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4gPiBJ IGFncmVlIHdpdGggd2hhdCB5b3UgYXJlIHNheWluZywgdGhlcmUgaXMgbm8gbmVlZCBmb3IgRENF UCBpZiB3ZSB1c2UNCj4gPiBleHRlcm5hbCBuZWdvdGlhdGlvbi4NCj4gPg0KPiA+IFRoZSBxdWVz dGlvbiBpcyB0aGVuIHdoZXRoZXIgd2Ugc2hvdWxkIHJlbW92ZSBEQ0VQIGNvbXBsZXRlbHkgZnJv bSB0aGUNCj4gPiBDTFVFIGRhdGEgY2hhbm5lbCBkcmFmdD8NCj4gPg0KPiA+IERDRVAgY291bGQg YmUgdXNlZnVsIGlmIHNvbWVvbmUgaW1wbGVtZW50ZWQgQ0xVRSB1c2luZyBhbm90aGVyDQo+ID4g c2lnbmFsbGluZyBwcm90b2NvbCB0aGFuIFNJUC9TRFAsIGJ1dCB3ZSBhcmUgbm90IHNwZWNpZnlp bmcgc3VjaA0KPiA+IHVzYWdlLCBzby4uLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IENo cmlzdGVyDQo+ID4NCj4gPiBTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPiAtLQ0KPiA+IEZyb206IFBhdWwgS3l6aXZhdCA8bWFpbHRvOnBreXppdmF0QGFs dW0ubWl0LmVkdT4NCj4gPiBTZW50OiDigI4yNC/igI4xMS/igI4yMDE0IDAyOjEzDQo+ID4gVG86 IGNsdWVAaWV0Zi5vcmcgPG1haWx0bzpjbHVlQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJlOiBb Y2x1ZV0gRlc6IGRyYWZ0LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnIGFuZA0KPiA+ IERDRVANCj4gPg0KPiA+IE9uIDExLzIxLzE0IDI6MjAgUE0sIENocmlzdGVyIEhvbG1iZXJnIHdy b3RlOg0KPiA+ID4gRllJLA0KPiA+ID4NCj4gPiA+IEkgc2VudCB0aGUgZm9sbG93aW5nIHRvIHRo ZSBNTVVTSUMgbGlzdC4NCj4gPiA+DQo+ID4gPiBUaGUgQ0xVRSBkYXRhIGNoYW5uZWwgZHJhZnQg Y3VycmVudGx5IGFzc3VtZXMgdGhhdCBEQ0VQIGlzIHVzZWQgdG8NCj4gPiA+IG9wZW4gdGhlIENM VUUgZGF0YSBjaGFubmVsLCBvbmNlIGl0IGhhcyBiZWVuIG5lZ290aWF0ZWQgdXNpbmcgZHJhZnQt DQo+IGVqemFrLg0KPiA+ID4NCj4gPiA+IEhvd2V2ZXIsIGlmIGRyYWZ0LWVqemFrIGZvcmJpZHMg dXNhZ2Ugb2YgRENFUCwgYW5kL29yIHdlIGRvbuKAmXQgdGhpbmsNCj4gPiA+IGl04oCZcyBuZWVk ZWQgZm9yIHRoZSBDTFVFIGRhdGEgY2hhbm5lbCwgd2UgY2FuIHJlbW92ZSBpdC4NCj4gPiA+DQo+ ID4gPiBJbiBteSBvcGluaW9uLCB0aGUgYWR2YW50YWdlIG9mIGFsc28gdXNpbmcgRENFUCBpcyB0 aGF0IHRoZQ0KPiA+ID4gZW5kcG9pbnRzIGNhbiBjaG9vc2Ugd2hlbiB0byBvcGVuIHRoZSBkYXRh IGNoYW5uZWwg4oCTIG90aGVyd2lzZSBpdCBpcw0KPiA+ID4gY29uc2lkZXJlZCBvcGVuIG9uY2Ug dGhlIFNDVFAgYXNzb2NpYXRpb24gaGFzIGJlZW4gY3JlYXRlZC4NCj4gPg0KPiA+IE15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCBEQ0VQIGlzICpub3QqIHVzZWQuIFdoZW4geW91IHVzZSBleHRlcm5h bA0KPiA+IG5lZ290aWF0aW9uIHlvdSBzaW1wbHkgYWdyZWUgKGV4dGVybmFsbHkpIG9uIHdoaWNo IHN0cmVhbSBpZHMgYXJlIHRvDQo+ID4gYmUgdXNlZCAodGhleSBkb24ndCBldmVuIGhhdmUgdG8g YmUgdGhlIHNhbWUgaW4gZWFjaCBkaXJlY3Rpb24pIGFuZA0KPiA+IHN0YXJ0IHVzaW5nIHRoZW0u DQo+ID4NCj4gPiBJIGNvdWxkIGJlIHdyb25nLCBidXQgSSBkb24ndCB0aGluayB0aGUgd2VicnRj IEFQSSBoYXMgYSB3YXkgZm9yIHlvdQ0KPiA+IHRvIHVzZSB0aGUgRENFUCBwcm90b2NvbCBvbiBh biBleHRlcm5hbGx5IGFsbG9jYXRlZCBjaGFubmVsLiBZb3UgY2FuDQo+ID4gY2FsbCB0byBvcGVu IGEgY2hhbm5lbCB3aXRob3V0IHN1cHBseWluZyBhIHN0cmVhbSBpZCwgaW4gd2hpY2ggY2FzZQ0K PiA+IERDRVAgaXMgYXV0b21hdGljYWxseSB1c2VkIHRvIGFzc2lnbiB0aGUgaWQpLCBvciBlbHNl IHlvdSBjYW4gc3VwcGx5IGENCj4gPiBzdHJlYW0gaWQgd2hlbiBvcGVuaW5nIGEgY2hhbm5lbCAo aW4gd2hpY2ggY2FzZSBEQ0VQIGlzIG5vdCB1c2VkKS4NCj4gPg0KPiA+IEkgc3VwcG9zZSBub3Ro aW5nIHByZXZlbnRzIHlvdSBmcm9tIHVzaW5nIERDRVAgbWVzc2FnZXMgb24geW91cg0KPiA+IGV4 dGVybmFsbHkgYWxsb2NhdGVkIGNoYW5uZWwsIGJ1dCB0aGVuIHlvdSB3b3VsZCBoYXZlIHRvIGZv cm1hdCBhbmQNCj4gPiBzZW5kIHRoZW0geW91cnNlbGYsIGFuZCBkZWNvZGUgdGhlbSBhdCB0aGUg b3RoZXIgZW5kLCByYXRoZXIgdGhhbg0KPiA+IGhhdmluZyB0aGUgbGlicmFyeSBiZWhpbmQgdGhl IEFQSSBkb2luZyBpdCBmb3IgeW91Lg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IFBhdWwNCj4gPg0K PiA+ID4gUmVnYXJkcywNCj4gPiA+DQo+ID4gPiBDaHJpc3Rlcg0KPiA+ID4NCj4gPiA+ICpGcm9t OiptbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZg0K PiA+ID4gKkNocmlzdGVyIEhvbG1iZXJnDQo+ID4gPiAqU2VudDoqIDIxIE5vdmVtYmVyIDIwMTQg MjE6MTcNCj4gPiA+ICpUbzoqIG1tdXNpY0BpZXRmLm9yZw0KPiA+ID4gKlN1YmplY3Q6KiBbTU1V U0lDXSBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBhbmQgRENFUA0KPiA+ ID4NCj4gPiA+IEhpLA0KPiA+ID4NCj4gPiA+IGRyYWZ0LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5u ZWwtc2RwbmVnIGN1cnJlbnRseSBzZWVtcyB0byBhc3N1bWUNCj4gPiA+IHRoYXQgRENFUCB3aWxs IG5vdCBiZSB1c2VkIHRvIG9wZW4gZGF0YSBjaGFubmVscyDigJMgaW5zdGVhZCBkYXRhDQo+ID4g PiBjaGFubmVscyB3aWxsIGJlIGNvbnNpZGVyZWQgb3BlbiBvbmNlIHRoZSBTRFAgTy9BIG5lZ290 aWF0aW9uIGhhcw0KPiA+ID4gZmluaXNoZWQgYW5kIHRoZSBTQ1RQIGFzc29jaWF0aW9uIHVzZWQg dG8gcmVhbGl6ZSB0aGUgZGF0YSBjaGFubmVsKHMpDQo+IGhhcyBiZWVuIGNyZWF0ZWQuDQo+ID4g Pg0KPiA+ID4gTXkgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUgaW50ZW50aW9uIGlzIHRvIGZvcmJp ZCB1c2FnZSBvZiBEQ0VQDQo+ID4gPiB0b2dldGhlciB3aXRoIGRyYWZ0LWVqemFrLW1tdXNpYy1k YXRhLWNoYW5uZWwtc2RwbmVnLCBvciB3aGV0aGVyIGl0DQo+ID4gPiBzaG91bGQgYmUgb3B0aW9u YWw/DQo+ID4gPg0KPiA+ID4gSWYgb3B0aW9uYWwsIHRoZXJlIG5lZWRzIHRvIGJlIGEgd2F5IHRv IGluZGljYXRlIHRoYXQgYXBwbGljYXRpb24NCj4gPiA+IGRhdGEgc2hhbGwgbm90IGJlIHNlbnQg dW50aWwgYSBjaGFubmVsIGhhcyBiZWVuIG9wZW5lZCB1c2luZyBEQ0VQLg0KPiA+ID4gSW4gYWRk aXRpb24sIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBiZSBhYmxlIHRvIGluZGljYXRlIHdoaWNoDQo+ ID4gPiBlbmRwb2ludCBpcyByZXNwb25zaWJsZSBmb3Igc2VuZGluZyB0aGUgRENFUF9DSEFOTkVM X09QRU4gbWVzc2FnZS4NCj4gPiA+DQo+ID4gPiBSZWdhcmRzLA0KPiA+ID4NCj4gPiA+IENocmlz dGVyDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gPiA+IGNs dWVAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2x1ZQ0KPiA+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gPiBjbHVlQGlldGYub3JnDQo+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo+ID4NCj4gPg0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g Y2x1ZSBtYWlsaW5nIGxpc3QNCj4gPiBjbHVlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcgbGlzdA0KPiBjbHVlQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjbHVlIG1h aWxpbmcgbGlzdA0KPiBjbHVlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY2x1ZQ0K From nobody Tue Nov 25 03:47:34 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29851A00EF for ; Tue, 25 Nov 2014 03:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=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 jCT7n5Z3bKcj for ; Tue, 25 Nov 2014 03:47:30 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A481A00D0 for ; Tue, 25 Nov 2014 03:47:29 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-1a-54746c4fabb4 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 34.26.24955.F4C64745; Tue, 25 Nov 2014 12:47:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 12:47:27 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , Christian Groves , "clue@ietf.org" Thread-Topic: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHwAAJH5gAGzPFIAABv9ZSQApnc6AABrtWkD///Y2AP//7lFQ Date: Tue, 25 Nov 2014 11:47:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53577E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> <5473BE59.4070805@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D53548A@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvja5/TkmIwad/MhZf3jeyWOw/dZnZ omHjFVYHZo/WZ3tZPZYs+cnkseL8TJYA5igum5TUnMyy1CJ9uwSujEfdC1kKFjlVdC9vYGxg POHQxcjJISFgIvH+0wV2CFtM4sK99WxdjFwcQgJHGCVObH/ADuEsYZTY29nG0sXIwcEmYCHR /U8bJC4iMIdRYvObe0wg3cIC7hIdh0+zgNgiAh4S77ZsYIawoyReTlrKCmKzCKhK3Lp5FKye V8BXYurp86wQCzYyS7R/bmMDSXAKxEq0bjgLVsQIdNL3U2vAbGYBcYlbT+YzQZwqILFkz3lm CFtU4uXjf6wgx0kIKElM25oGYjILaEqs36UP0akoMaX7ITvEWkGJkzOfsExgFJ2FZOgshI5Z SDpmIelYwMiyilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwcg5u+a26g/HyG8dDjAIcjEo8 vBs+FIcIsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGt3Ve LNPnn/3QLJERo3HkVPLfvw85b9c6OQp2eQUt7XjVdrD/KctMQ589z1rPzXVceLtw/6V3Og8/ OjFcmdm2iqUy/Z7BTJ0NTmvjrnZ8ehGyVHLVr4+vBc3eurxxtNNtUcjT2ujPfXQ1+/ItLJ2z 3qSdUN9TbpQq3yUhLynzruNBcnr31ptrlViKMxINtZiLihMBPTS/+X0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/sr_cCNzT5UGA6JpPihMPWAqL8t0 Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 11:47:33 -0000 SGksDQoNCj4+IElmIHlvdSBwcm92aWRlIHRoZSBTQ1RQIHBvcnQgaW4gdGhlIFdlYlJUQyBBUEks IHRoZW4gRENFUCB3b24ndCBiZSB1c2VkLg0KPiBZb3UgbWVhbnQgIihzdHJlYW0pIGlkIiBpbnN0 ZWFkIG9mICJTQ1RQIHBvcnQiPw0KDQpZZXMuDQoNCj4gSW4gV2ViUlRDIEFQSSBjcmVhdGVEYXRh Q2hhbm5lbCgpLCB1c2Ugb2YgRENFUCBpcyBjb250cm9sbGVkIGJ5IHVzaW5nICJuZWdvdGlhdGVk IiBwYXJhbWV0ZXIuIChTdHJlYW0pIGlkIHNwZWNpZmljYXRpb24gb25seSBkZXRlcm1pbmVzIHRo ZSBzdHJlYW0gaWQgdG8gYmUgdXNlZC4NCg0KT2suIEJ1dCwgdGhlIHBvaW50IGlzIHRoYXQgeW91 IGNhbiBjcmVhdGUgYSBkYXRhIGNoYW5uZWwgd2l0aG91dCBEQ0VQLg0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjbHVl IFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgDQo+ IEhvbG1iZXJnDQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI1LCAyMDE0IDU6MjQgQU0NCj4g VG86IENocmlzdGlhbiBHcm92ZXM7IGNsdWVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtjbHVl XSBGVzogZHJhZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcgYW5kIA0KPiBEQ0VQ DQo+IA0KPiBIaSwNCj4gDQo+IElmIEkgdW5kZXJzdG9vZCBQYXVsJ3MgY29tbWVudCwgRENFUCBp cyBub3QgcmVxdWlyZWQgZm9yIGNvbXBhdGliaWxpdHkgDQo+IHdpdGggV2ViUlRDIGVuZHBvaW50 cy4gSWYgeW91IHByb3ZpZGUgdGhlIFNDVFAgcG9ydCBpbiB0aGUgV2ViUlRDIEFQSSwgDQo+IHRo ZW4gRENFUCB3b24ndCBiZSB1c2VkLg0KPiANCj4gVGhlIHF1ZXN0aW9uIGlzIHJlYWxseSB3aGV0 aGVyIHdlIHdhbnQgdG8gbWFuZGF0ZSBub24tV2ViUlRDIENMVUUgDQo+IGRldmljZXMgdG8gaW1w bGVtZW50IERDRVAgb3Igbm90Lg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IENocmlzdGVyDQo+IA0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjbHVlIFttYWlsdG86Y2x1ZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIA0KPiBHcm92ZXMNCj4gU2Vu dDogMjUuIG1hcnJhc2t1dXRhIDIwMTQgMToyNQ0KPiBUbzogY2x1ZUBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW2NsdWVdIEZXOiBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5l ZyBhbmQgDQo+IERDRVANCj4gDQo+IEkgdGhvdWdodCB0aGUgcmVhc29uIHdlIHVzZWQgRENFUCB3 YXMgc28gdGhhdCBpdCB3YXMgY29tcGF0aWJsZSB3aXRoIA0KPiBXZWJSVEMgZW5kcG9pbnRzLiBT byBpcyB0aGlzIG5vdCBhIGNvbmNlcm4gYW55bW9yZT8NCj4gDQo+IE15IHZpZXcgaXMgdGhhdCBp dCBzaG91bGQgYmUgcG9zc2libGUgdG8gdXNlIGV4dGVybmFsIG5lZ290aWF0aW9uIHRvIA0KPiBu ZWdvdGlhdGUgdGhlIHByb3RvY29scyB0aGF0IGFyZSB1c2VkIGZvciB0aGUgZGF0YSBjaGFubmVs IGFuZCB0aGVuIA0KPiB1c2UgRENFUCB0byBlc3RhYmxpc2ggdGhlIFNDVFAgY2hhbm5lbC4gVGhp cyBlZmZlY3RpdmVseSBlbXVsYXRlcyB3aGF0IA0KPiB3ZSBoYWQgaW4gb3VyIENMVUUgZGF0YSBj aGFubmVsIGRyYWZ0IHdoZXJlIHRoZSBhPUdST1VQOkNMVUUgb24gdGhlIA0KPiBkYXRhY2hhbm5l bCBtPWxpbmUgaW5kaWNhdGVkIHRoYXQgQ0xVRSB3b3VsZCBiZSB1c2VkIGFuZCB0aGVuIERDRVAg d2FzIA0KPiB1c2VkIHRvIGVzdGFibGlzaCB0aGUgU0NUUCBjaGFubmVsLg0KPiANCj4gQ2hyaXN0 aWFuDQo+IA0KPiBPbiAyNC8xMS8yMDE0IDE6MzMgUE0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3Rl Og0KPiA+IEhpLA0KPiA+DQo+ID4gSSBhZ3JlZSB3aXRoIHdoYXQgeW91IGFyZSBzYXlpbmcsIHRo ZXJlIGlzIG5vIG5lZWQgZm9yIERDRVAgaWYgd2UgDQo+ID4gdXNlIGV4dGVybmFsIG5lZ290aWF0 aW9uLg0KPiA+DQo+ID4gVGhlIHF1ZXN0aW9uIGlzIHRoZW4gd2hldGhlciB3ZSBzaG91bGQgcmVt b3ZlIERDRVAgY29tcGxldGVseSBmcm9tIA0KPiA+IHRoZSBDTFVFIGRhdGEgY2hhbm5lbCBkcmFm dD8NCj4gPg0KPiA+IERDRVAgY291bGQgYmUgdXNlZnVsIGlmIHNvbWVvbmUgaW1wbGVtZW50ZWQg Q0xVRSB1c2luZyBhbm90aGVyIA0KPiA+IHNpZ25hbGxpbmcgcHJvdG9jb2wgdGhhbiBTSVAvU0RQ LCBidXQgd2UgYXJlIG5vdCBzcGVjaWZ5aW5nIHN1Y2ggDQo+ID4gdXNhZ2UsIHNvLi4uDQo+ID4N Cj4gPiBSZWdhcmRzLA0KPiA+DQo+ID4gQ2hyaXN0ZXINCj4gPg0KPiA+IFNlbnQgZnJvbSBteSBX aW5kb3dzIFBob25lDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLQ0KPiA+IC0tDQo+ID4gRnJvbTog UGF1bCBLeXppdmF0IDxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KPiA+IFNlbnQ6IOKA jjI0L+KAjjExL+KAjjIwMTQgMDI6MTMNCj4gPiBUbzogY2x1ZUBpZXRmLm9yZyA8bWFpbHRvOmNs dWVAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFtjbHVlXSBGVzogZHJhZnQtZWp6YWstbW11 c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcgYW5kIA0KPiA+IERDRVANCj4gPg0KPiA+IE9uIDExLzIx LzE0IDI6MjAgUE0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPiA+ID4gRllJLA0KPiA+ID4N Cj4gPiA+IEkgc2VudCB0aGUgZm9sbG93aW5nIHRvIHRoZSBNTVVTSUMgbGlzdC4NCj4gPiA+DQo+ ID4gPiBUaGUgQ0xVRSBkYXRhIGNoYW5uZWwgZHJhZnQgY3VycmVudGx5IGFzc3VtZXMgdGhhdCBE Q0VQIGlzIHVzZWQgdG8gDQo+ID4gPiBvcGVuIHRoZSBDTFVFIGRhdGEgY2hhbm5lbCwgb25jZSBp dCBoYXMgYmVlbiBuZWdvdGlhdGVkIHVzaW5nIA0KPiA+ID4gZHJhZnQtDQo+IGVqemFrLg0KPiA+ ID4NCj4gPiA+IEhvd2V2ZXIsIGlmIGRyYWZ0LWVqemFrIGZvcmJpZHMgdXNhZ2Ugb2YgRENFUCwg YW5kL29yIHdlIGRvbuKAmXQgDQo+ID4gPiB0aGluayBpdOKAmXMgbmVlZGVkIGZvciB0aGUgQ0xV RSBkYXRhIGNoYW5uZWwsIHdlIGNhbiByZW1vdmUgaXQuDQo+ID4gPg0KPiA+ID4gSW4gbXkgb3Bp bmlvbiwgdGhlIGFkdmFudGFnZSBvZiBhbHNvIHVzaW5nIERDRVAgaXMgdGhhdCB0aGUgDQo+ID4g PiBlbmRwb2ludHMgY2FuIGNob29zZSB3aGVuIHRvIG9wZW4gdGhlIGRhdGEgY2hhbm5lbCDigJMg b3RoZXJ3aXNlIGl0IA0KPiA+ID4gaXMgY29uc2lkZXJlZCBvcGVuIG9uY2UgdGhlIFNDVFAgYXNz b2NpYXRpb24gaGFzIGJlZW4gY3JlYXRlZC4NCj4gPg0KPiA+IE15IHVuZGVyc3RhbmRpbmcgaXMg dGhhdCBEQ0VQIGlzICpub3QqIHVzZWQuIFdoZW4geW91IHVzZSBleHRlcm5hbCANCj4gPiBuZWdv dGlhdGlvbiB5b3Ugc2ltcGx5IGFncmVlIChleHRlcm5hbGx5KSBvbiB3aGljaCBzdHJlYW0gaWRz IGFyZSB0byANCj4gPiBiZSB1c2VkICh0aGV5IGRvbid0IGV2ZW4gaGF2ZSB0byBiZSB0aGUgc2Ft ZSBpbiBlYWNoIGRpcmVjdGlvbikgYW5kIA0KPiA+IHN0YXJ0IHVzaW5nIHRoZW0uDQo+ID4NCj4g PiBJIGNvdWxkIGJlIHdyb25nLCBidXQgSSBkb24ndCB0aGluayB0aGUgd2VicnRjIEFQSSBoYXMg YSB3YXkgZm9yIHlvdSANCj4gPiB0byB1c2UgdGhlIERDRVAgcHJvdG9jb2wgb24gYW4gZXh0ZXJu YWxseSBhbGxvY2F0ZWQgY2hhbm5lbC4gWW91IGNhbiANCj4gPiBjYWxsIHRvIG9wZW4gYSBjaGFu bmVsIHdpdGhvdXQgc3VwcGx5aW5nIGEgc3RyZWFtIGlkLCBpbiB3aGljaCBjYXNlIA0KPiA+IERD RVAgaXMgYXV0b21hdGljYWxseSB1c2VkIHRvIGFzc2lnbiB0aGUgaWQpLCBvciBlbHNlIHlvdSBj YW4gc3VwcGx5IA0KPiA+IGEgc3RyZWFtIGlkIHdoZW4gb3BlbmluZyBhIGNoYW5uZWwgKGluIHdo aWNoIGNhc2UgRENFUCBpcyBub3QgdXNlZCkuDQo+ID4NCj4gPiBJIHN1cHBvc2Ugbm90aGluZyBw cmV2ZW50cyB5b3UgZnJvbSB1c2luZyBEQ0VQIG1lc3NhZ2VzIG9uIHlvdXIgDQo+ID4gZXh0ZXJu YWxseSBhbGxvY2F0ZWQgY2hhbm5lbCwgYnV0IHRoZW4geW91IHdvdWxkIGhhdmUgdG8gZm9ybWF0 IGFuZCANCj4gPiBzZW5kIHRoZW0geW91cnNlbGYsIGFuZCBkZWNvZGUgdGhlbSBhdCB0aGUgb3Ro ZXIgZW5kLCByYXRoZXIgdGhhbiANCj4gPiBoYXZpbmcgdGhlIGxpYnJhcnkgYmVoaW5kIHRoZSBB UEkgZG9pbmcgaXQgZm9yIHlvdS4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBQYXVsDQo+ID4NCj4g PiA+IFJlZ2FyZHMsDQo+ID4gPg0KPiA+ID4gQ2hyaXN0ZXINCj4gPiA+DQo+ID4gPiAqRnJvbToq bW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgDQo+ ID4gPiAqQ2hyaXN0ZXIgSG9sbWJlcmcNCj4gPiA+ICpTZW50OiogMjEgTm92ZW1iZXIgMjAxNCAy MToxNw0KPiA+ID4gKlRvOiogbW11c2ljQGlldGYub3JnDQo+ID4gPiAqU3ViamVjdDoqIFtNTVVT SUNdIGRyYWZ0LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnIGFuZCANCj4gPiA+IERD RVANCj4gPiA+DQo+ID4gPiBIaSwNCj4gPiA+DQo+ID4gPiBkcmFmdC1lanphay1tbXVzaWMtZGF0 YS1jaGFubmVsLXNkcG5lZyBjdXJyZW50bHkgc2VlbXMgdG8gYXNzdW1lIA0KPiA+ID4gdGhhdCBE Q0VQIHdpbGwgbm90IGJlIHVzZWQgdG8gb3BlbiBkYXRhIGNoYW5uZWxzIOKAkyBpbnN0ZWFkIGRh dGEgDQo+ID4gPiBjaGFubmVscyB3aWxsIGJlIGNvbnNpZGVyZWQgb3BlbiBvbmNlIHRoZSBTRFAg Ty9BIG5lZ290aWF0aW9uIGhhcyANCj4gPiA+IGZpbmlzaGVkIGFuZCB0aGUgU0NUUCBhc3NvY2lh dGlvbiB1c2VkIHRvIHJlYWxpemUgdGhlIGRhdGEgDQo+ID4gPiBjaGFubmVsKHMpDQo+IGhhcyBi ZWVuIGNyZWF0ZWQuDQo+ID4gPg0KPiA+ID4gTXkgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUgaW50 ZW50aW9uIGlzIHRvIGZvcmJpZCB1c2FnZSBvZiBEQ0VQIA0KPiA+ID4gdG9nZXRoZXIgd2l0aCBk cmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZywgb3Igd2hldGhlciANCj4gPiA+ IGl0IHNob3VsZCBiZSBvcHRpb25hbD8NCj4gPiA+DQo+ID4gPiBJZiBvcHRpb25hbCwgdGhlcmUg bmVlZHMgdG8gYmUgYSB3YXkgdG8gaW5kaWNhdGUgdGhhdCBhcHBsaWNhdGlvbiANCj4gPiA+IGRh dGEgc2hhbGwgbm90IGJlIHNlbnQgdW50aWwgYSBjaGFubmVsIGhhcyBiZWVuIG9wZW5lZCB1c2lu ZyBEQ0VQLg0KPiA+ID4gSW4gYWRkaXRpb24sIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBiZSBhYmxl IHRvIGluZGljYXRlIHdoaWNoIA0KPiA+ID4gZW5kcG9pbnQgaXMgcmVzcG9uc2libGUgZm9yIHNl bmRpbmcgdGhlIERDRVBfQ0hBTk5FTF9PUEVOIG1lc3NhZ2UuDQo+ID4gPg0KPiA+ID4gUmVnYXJk cywNCj4gPiA+DQo+ID4gPiBDaHJpc3Rlcg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IGNsdWUg bWFpbGluZyBsaXN0DQo+ID4gPiBjbHVlQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4gPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGNsdWUgbWFpbGluZyBsaXN0 DQo+ID4gY2x1ZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2x1ZQ0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IGNsdWUgbWFpbGluZyBsaXN0DQo+ID4gY2x1ZUBpZXRmLm9y Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY2x1ZSBt YWlsaW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NsdWUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg== From nobody Tue Nov 25 04:00: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 A386B1A0104 for ; Tue, 25 Nov 2014 04:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 w_4vE9AfLT07 for ; Tue, 25 Nov 2014 04:00:12 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F127A1A00F9 for ; Tue, 25 Nov 2014 04:00:11 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 706C0B314400B; Tue, 25 Nov 2014 12:00:07 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id sAPC08Gi030680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 07:00:08 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 07:00:08 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Christian Groves , "clue@ietf.org" Thread-Topic: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHwBvENaOAA9cNwAAK7ZTgAAZGO8AAAoBUID//7aNAIAAUXvw Date: Tue, 25 Nov 2014 12:00:07 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> <5473BE59.4070805@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D53548A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53577E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D53577E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/IdKEkGXo73PnQNtIZR1draoCM3c Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 12:00:13 -0000 DQo+IEhpLA0KPiANCj4gPj4gSWYgeW91IHByb3ZpZGUgdGhlIFNDVFAgcG9ydCBpbiB0aGUgV2Vi UlRDIEFQSSwgdGhlbiBEQ0VQIHdvbid0IGJlIHVzZWQuDQo+ID4gWW91IG1lYW50ICIoc3RyZWFt KSBpZCIgaW5zdGVhZCBvZiAiU0NUUCBwb3J0Ij8NCj4gDQo+IFllcy4NCj4gDQo+ID4gSW4gV2Vi UlRDIEFQSSBjcmVhdGVEYXRhQ2hhbm5lbCgpLCB1c2Ugb2YgRENFUCBpcyBjb250cm9sbGVkIGJ5 IHVzaW5nDQo+ICJuZWdvdGlhdGVkIiBwYXJhbWV0ZXIuIChTdHJlYW0pIGlkIHNwZWNpZmljYXRp b24gb25seSBkZXRlcm1pbmVzIHRoZSBzdHJlYW0NCj4gaWQgdG8gYmUgdXNlZC4NCj4gDQo+IE9r LiBCdXQsIHRoZSBwb2ludCBpcyB0aGF0IHlvdSBjYW4gY3JlYXRlIGEgZGF0YSBjaGFubmVsIHdp dGhvdXQgRENFUC4NCltSYWp1XSANCklNSE8sIEkgYW0gaW4gZmF2b3Igb2Ygbm90IG1hbmRhdGlu ZyBEQ0VQIGZvciBub24tV2ViUlRDIGRldmljZSBDTFVFIHVzYWdlLiBGdXJ0aGVybW9yZSwgdG8g YmUgY29uc2lzdGVudCBpdCBtYXkgYmUgYmV0dGVyIG5vdCB0byB1c2UgRENFUCBldmVuIHdoZW4g Q0xVRSBpcyB1c2VkIGJ5IGEgV2ViUlRDIGRldmljZS4NCg0KQlINClJhanUNCg0KPiANCj4gUmVn YXJkcywNCj4gDQo+IENocmlzdGVyDQo+IA0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiBGcm9tOiBjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQ2hyaXN0ZXINCj4gPiBIb2xtYmVyZw0KPiA+IFNlbnQ6IFR1ZXNkYXksIE5v dmVtYmVyIDI1LCAyMDE0IDU6MjQgQU0NCj4gPiBUbzogQ2hyaXN0aWFuIEdyb3ZlczsgY2x1ZUBp ZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gRlc6IGRyYWZ0LWVqemFrLW1tdXNpYy1k YXRhLWNoYW5uZWwtc2RwbmVnIGFuZA0KPiA+IERDRVANCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4g SWYgSSB1bmRlcnN0b29kIFBhdWwncyBjb21tZW50LCBEQ0VQIGlzIG5vdCByZXF1aXJlZCBmb3Ig Y29tcGF0aWJpbGl0eQ0KPiA+IHdpdGggV2ViUlRDIGVuZHBvaW50cy4gSWYgeW91IHByb3ZpZGUg dGhlIFNDVFAgcG9ydCBpbiB0aGUgV2ViUlRDIEFQSSwNCj4gPiB0aGVuIERDRVAgd29uJ3QgYmUg dXNlZC4NCj4gPg0KPiA+IFRoZSBxdWVzdGlvbiBpcyByZWFsbHkgd2hldGhlciB3ZSB3YW50IHRv IG1hbmRhdGUgbm9uLVdlYlJUQyBDTFVFDQo+ID4gZGV2aWNlcyB0byBpbXBsZW1lbnQgRENFUCBv ciBub3QuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+DQo+ID4gQ2hyaXN0ZXINCg== From nobody Tue Nov 25 05:57: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 DE5861A1A4C for ; Tue, 25 Nov 2014 05:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 qGD3Riy-k0aJ for ; Tue, 25 Nov 2014 05:56:59 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.98]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704AE1A1A32 for ; Tue, 25 Nov 2014 05:56:59 -0800 (PST) Received: from [216.82.254.19] by server-2.bemta-7.messagelabs.com id A0/00-03095-AAA84745; Tue, 25 Nov 2014 13:56:58 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-11.tower-96.messagelabs.com!1416923752!17147258!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21196 invoked from network); 25 Nov 2014 13:55:53 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-11.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 25 Nov 2014 13:55:53 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 25 Nov 2014 05:55:51 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , CLUE Date: Tue, 25 Nov 2014 05:55:49 -0800 Thread-Topic: [clue] Consensus call: remove clue-specific simulcast Thread-Index: AdAIMxKb7asxz8ZfRAi/pCtUFp8qVQAhGerA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE135@CRPMBOXPRD08.polycom.com> References: <5473AC21.7000205@alum.mit.edu> In-Reply-To: <5473AC21.7000205@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YrPGon2LxayqsHxqzN5qBKaZx4k Subject: Re: [clue] Consensus call: remove clue-specific simulcast X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 13:57:01 -0000 YES Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, November 24, 2014 5:07 PM > To: CLUE > Subject: [clue] Consensus call: remove clue-specific simulcast >=20 > During the Honululu meeting we had consensus to remove the clue-specific > simulcast mechanism (via configuring the same capture with two or more > encodings). The expectation is that, in lieu of this clue will rely on > an SDP mechanism for negotiating simulcast within a single m-line. (The > mmusic wg adopted draft-westerlund-avtcore-rtp-simulcast-04 as a wg item > at this meeting.) >=20 > This message brings that question to the list for confirmation. >=20 > Please indicate if you support removal of the clue-specific simulcast > mechanism: YES/NO. >=20 > If you indicate NO, please provide a detailed reason why not. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Nov 25 06:21: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 48DDD1A1A3B for ; Tue, 25 Nov 2014 06:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tohUgLiWnZZx for ; Tue, 25 Nov 2014 06:21:40 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD731A1A91 for ; Tue, 25 Nov 2014 06:21:10 -0800 (PST) X-ASG-Debug-ID: 1416925263-05f27518c360d300001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id fAdbdsSJ1EMGQ8hH (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 15:21:03 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.169] ([143.225.28.169]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id sAPEL2Xj018560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 15:21:03 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_39ECEA1E-15E4-43A5-A737-1E25A33603F9" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Consensus call: remove clue-specific simulcast In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE135@CRPMBOXPRD08.polycom.com> Date: Tue, 25 Nov 2014 15:21:02 +0100 Message-Id: <3C1EB3B9-4B22-4F1D-A01B-470564562054@unina.it> References: <5473AC21.7000205@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE135@CRPMBOXPRD08.polycom.com> To: CLUE X-Mailer: Apple Mail (2.1993) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1416925263 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.12026 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Y5kTLg3cWJyZoYkAB-RqsUR2XgM Subject: Re: [clue] Consensus call: remove clue-specific simulcast X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 14:21:43 -0000 --Apple-Mail=_39ECEA1E-15E4-43A5-A737-1E25A33603F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 YES. Simon > On 25/nov/2014, at 14:55, Duckworth, Mark = wrote: >=20 > YES > Mark >=20 >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, November 24, 2014 5:07 PM >> To: CLUE >> Subject: [clue] Consensus call: remove clue-specific simulcast >>=20 >> During the Honululu meeting we had consensus to remove the = clue-specific >> simulcast mechanism (via configuring the same capture with two or = more >> encodings). The expectation is that, in lieu of this clue will rely = on >> an SDP mechanism for negotiating simulcast within a single m-line. = (The >> mmusic wg adopted draft-westerlund-avtcore-rtp-simulcast-04 as a wg = item >> at this meeting.) >>=20 >> This message brings that question to the list for confirmation. >>=20 >> Please indicate if you support removal of the clue-specific simulcast >> mechanism: YES/NO. >>=20 >> If you indicate NO, please provide a detailed reason why not. >>=20 >> Thanks, >> Paul >>=20 >> _______________________________________________ >> 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 >=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=_39ECEA1E-15E4-43A5-A737-1E25A33603F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
YES.

Simon


On 25/nov/2014, at 14:55, Duckworth, Mark = <Mark.Duckworth@polycom.com> wrote:

YES
Mark

-----Original Message-----
From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul = Kyzivat
Sent: Monday, November 24, 2014 5:07 PM
To: CLUE
Subject: [clue] Consensus call: remove = clue-specific simulcast

During the Honululu = meeting we had consensus to remove the clue-specific
simulcast mechanism (via configuring the same capture with = two or more
encodings). The expectation is that, in lieu = of this clue will rely on
an SDP mechanism for negotiating = simulcast within a single m-line. (The
mmusic wg adopted = draft-westerlund-avtcore-rtp-simulcast-04 as a wg item
at = this meeting.)

This message brings that = question to the list for confirmation.

Please= indicate if you support removal of the clue-specific simulcast
mechanism: YES/NO.

If you = indicate NO, please provide a detailed reason why not.

= 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


  =                   =   =        = _\\|//_
            =                 =       ( 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 =C3=A8 l'alibi = degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
           =      =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   )
=                 =                   \_) =          ) /
    =                     =                     =                     =        (_/






= --Apple-Mail=_39ECEA1E-15E4-43A5-A737-1E25A33603F9-- From nobody Tue Nov 25 10:43: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 6B5061ACECA for ; Tue, 25 Nov 2014 10:42: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 6rJ0p4I1BwHn for ; Tue, 25 Nov 2014 10:42:51 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C4E1A871A for ; Tue, 25 Nov 2014 10:42:50 -0800 (PST) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-07v.sys.comcast.net with comcast id KueA1p00J5BUCh401uipy0; Tue, 25 Nov 2014 18:42:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-16v.sys.comcast.net with comcast id Kuio1p00j3Ge9ey01uipM4; Tue, 25 Nov 2014 18:42:49 +0000 Message-ID: <5474CDA8.8030004@alum.mit.edu> Date: Tue, 25 Nov 2014 13:42:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> <5473BE59.4070805@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D53548A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53577E@ESESSMB209.ericsson.se> 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=q20140121; t=1416940969; bh=SYp9l4Lry7Uu6eOvzeswYpMcDiloGyKrk6zn/aRvFWA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pHPUeC0bTbL/nrzfEKjKQ6QILXgtF7p1YDkAMTTEPqt+khGf6zeqsBiucyC4E6IuB 7jSWvhb/TvWQ02/62ryvzm7sA+x6rWcvbgkYcyFRmxZPm1gV1UxArSzzcUrUbd5+le 3sE5u4ns2XX8MXIQEF9oGspRVMFpisRgJMOM4Q2NkACkV5g89sikQUrtf9g31fW16Q 7NzykslaGW+TG23pYjXTOSM7lLjcOlJZiI9eyVwjhkHfyQ9I1GfCWK9gyTCZsUEbP5 2eo88uyM9InB9B8ohL6korGmhg2IdTBtOTVVgXknk2uLxRjBU45fmbjVH8AnUN5ltB ig4bfmRh7tW5Q== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/1bB1yNe-dcOIIL7YSM1A1Nxs4Qw Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 18:42:52 -0000 On 11/25/14 7:00 AM, Makaraju, Maridi Raju (Raju) wrote: > >> Hi, >> >>>> If you provide the SCTP port in the WebRTC API, then DCEP won't be used. >>> You meant "(stream) id" instead of "SCTP port"? >> >> Yes. >> >>> In WebRTC API createDataChannel(), use of DCEP is controlled by using >> "negotiated" parameter. (Stream) id specification only determines the stream >> id to be used. >> >> Ok. But, the point is that you can create a data channel without DCEP. > [Raju] > IMHO, I am in favor of not mandating DCEP for non-WebRTC device CLUE usage. Furthermore, to be consistent it may be better not to use DCEP even when CLUE is used by a WebRTC device. If we mandate using draft-ejzak for establishing the clue channel, then DCEP won't be *used*. I think we simply make a requirement for support of draft-ietf-rtcweb-data-channel, and don't mention draft-ietf-rtcweb-data-protocol. If there are dependencies between those two, then that is not our problem. (I thought data-channel had a dependency on data-protocol, but I don't see it now, which is a good thing.) Thanks, Paul > BR > Raju > >> >> Regards, >> >> Christer >> >> >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer >>> Holmberg >>> Sent: Tuesday, November 25, 2014 5:24 AM >>> To: Christian Groves; clue@ietf.org >>> Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and >>> DCEP >>> >>> Hi, >>> >>> If I understood Paul's comment, DCEP is not required for compatibility >>> with WebRTC endpoints. If you provide the SCTP port in the WebRTC API, >>> then DCEP won't be used. >>> >>> The question is really whether we want to mandate non-WebRTC CLUE >>> devices to implement DCEP or not. >>> >>> Regards, >>> >>> Christer > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Nov 25 11:19: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 A0A6D1ACE00 for ; Tue, 25 Nov 2014 11:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 huUUzJGqkk6Y for ; Tue, 25 Nov 2014 11:17:44 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90F31ACDFF for ; Tue, 25 Nov 2014 11:17:43 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-d8-5474d5d54574 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C3.F9.29772.5D5D4745; Tue, 25 Nov 2014 20:17:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 20:17:41 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP Thread-Index: AdAFv0DSisjv6UE4T7mZyJHhbq+IHwAAJH5gAGzPFIAABv9ZSQApnc6AABrtWkD///Y2AP//7lFQgAAW+ICAAHCDAIAAGoLn Date: Tue, 25 Nov 2014 19:17:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5366AB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> <5473BE59.4070805@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D53548A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53577E@ESESSMB209.ericsson.se> , <5474CDA8.8030004@alum.mit.edu> In-Reply-To: <5474CDA8.8030004@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D5366ABESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje7VqyUhBhuPWlnsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGmT/d7AVbbSsWbVnC1MC4wqSLkYNDQsBE YtU26S5GTiBTTOLCvfVsILaQwBFGiWnbtboYuYDsJYwS+/4cYgKpZxOwkOj+pw1SIyLgKbHj 4xRmEFtYwF2i4/BpFoi4h8S7LRuYIew8iRkX/4LNZBFQlVjV+Z4JxOYV8JX4v3EXM8T8FywS 23a9BGvgFNCRePvvHZjNCHTQ91NrwBqYBcQlmr6sZIU4VEBiyZ7zzBC2qMTLx/9YIWryJe5s vAe1QFDi5MwnLBMYhWchaZ+FpGwWkjKIuIHEl/e3oWxtiWULXzND2PoS3e9PMyGLL2BkX8Uo WpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGD0Ht/w22MH48rnjIUYBDkYlHt4NH4pDhFgTy4or cw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4yK9ySGcfqZz385+dpXr qPT81Efc71maQtL2vWp7ve6x2c7+E+dXvv45c7u2hazJF+3g7LBFEd1HezfcYzF4t3euQt2t hoaPiZy9J4RY7UpyDNsyrTsWThZsmvosNUXb+07jgyNOp6SOrDa4vjnn2P4z9jWWQvNc3tk0 1d8suL9i6pbcqAfBy5VYijMSDbWYi4oTASFwXTJ/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZZdw5pKTTCKJeFodpWYefWlgwyY Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 19:17:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D5366ABESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I agree with Paul. But, the question is still whether the CLUE data channel spec ahould still = define the DCEP code point for the CLUE data channel, IF someone e.g. want = to specify usage of CLUE in a non-O/A environment. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD25/=FD11/=FD2014 20:43 To: clue@ietf.org Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP On 11/25/14 7:00 AM, Makaraju, Maridi Raju (Raju) wrote: > >> Hi, >> >>>> If you provide the SCTP port in the WebRTC API, then DCEP won't be use= d. >>> You meant "(stream) id" instead of "SCTP port"? >> >> Yes. >> >>> In WebRTC API createDataChannel(), use of DCEP is controlled by using >> "negotiated" parameter. (Stream) id specification only determines the st= ream >> id to be used. >> >> Ok. But, the point is that you can create a data channel without DCEP. > [Raju] > IMHO, I am in favor of not mandating DCEP for non-WebRTC device CLUE usag= e. Furthermore, to be consistent it may be better not to use DCEP even when= CLUE is used by a WebRTC device. If we mandate using draft-ejzak for establishing the clue channel, then DCEP won't be *used*. I think we simply make a requirement for support of draft-ietf-rtcweb-data-channel, and don't mention draft-ietf-rtcweb-data-protocol. If there are dependencies between those two, then that is not our problem. (I thought data-channel had a dependency on data-protocol, but I don't see it now, which is a good thing.= ) Thanks, Paul > BR > Raju > >> >> Regards, >> >> Christer >> >> >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer >>> Holmberg >>> Sent: Tuesday, November 25, 2014 5:24 AM >>> To: Christian Groves; clue@ietf.org >>> Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and >>> DCEP >>> >>> Hi, >>> >>> If I understood Paul's comment, DCEP is not required for compatibility >>> with WebRTC endpoints. If you provide the SCTP port in the WebRTC API, >>> then DCEP won't be used. >>> >>> The question is really whether we want to mandate non-WebRTC CLUE >>> devices to implement DCEP or not. >>> >>> Regards, >>> >>> Christer > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7594FB04B1934943A5C02806D1A2204B1D5366ABESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

I agree with Paul.

But, the question is still whether the CLUE data channel spec ahould still = define the DCEP code point for the CLUE data channel, IF someone e.g. want = to specify usage of CLUE in a non-O/A environment.

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD25= /=FD11/=FD2014 20:43
To: clue@ietf.org
Subject: Re: [= clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP

On 11/25/14 7:00 AM, Makaraju, Maridi Raju (Raju) = wrote:
>
>> Hi,
>>
>>>> If you provide the SCTP port in the WebRTC API, then DCEP = won't be used.
>>> You meant "(stream) id" instead of "SCTP port&q= uot;?
>>
>> Yes.
>>
>>> In WebRTC API createDataChannel(), use of DCEP is controlled b= y using
>> "negotiated" parameter. (Stream) id specification only d= etermines the stream
>> id to be used.
>>
>> Ok. But, the point is that you can create a data channel without D= CEP.
> [Raju]
> IMHO, I am in favor of not mandating DCEP for non-WebRTC device CLUE u= sage. Furthermore, to be consistent it may be better not to use DCEP even w= hen CLUE is used by a WebRTC device.

If we mandate using draft-ejzak for establishing the clue channel, then DCEP won't be *used*. I think we simply make a requirement for support
of draft-ietf-rtcweb-data-channel, and don't mention
draft-ietf-rtcweb-data-protocol. If there are dependencies between those two, then that is not our problem. (I thought data-channel had a
dependency on data-protocol, but I don't see it now, which is a good thing.= )

        Thanks,
        Paul

> BR
> Raju
>
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>> -----Original Message-----
>>> From: clue [mailto:cl= ue-bounces@ietf.org] On Behalf Of Christer
>>> Holmberg
>>> Sent: Tuesday, November 25, 2014 5:24 AM
>>> To: Christian Groves; clue@ietf.org
>>> Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg= and
>>> DCEP
>>>
>>> Hi,
>>>
>>> If I understood Paul's comment, DCEP is not required for compa= tibility
>>> with WebRTC endpoints. If you provide the SCTP port in the Web= RTC API,
>>> then DCEP won't be used.
>>>
>>> The question is really whether we want to mandate non-WebRTC C= LUE
>>> devices to implement DCEP or not.
>>>
>>> Regards,
>>>
>>> Christer
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.iet= f.org/mailman/listinfo/clue
>

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org= /mailman/listinfo/clue
 --_000_7594FB04B1934943A5C02806D1A2204B1D5366ABESESSMB209erics_-- From nobody Tue Nov 25 11:23: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 5B7061ACE02 for ; Tue, 25 Nov 2014 11:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 vFTXYIZRP5sl for ; Tue, 25 Nov 2014 11:21:33 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BB61A6EED for ; Tue, 25 Nov 2014 11:21:31 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-08v.sys.comcast.net with comcast id KvKF1p0044ueUHc01vMXrz; Tue, 25 Nov 2014 19:21:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-03v.sys.comcast.net with comcast id KvMW1p00F3Ge9ey01vMWUz; Tue, 25 Nov 2014 19:21:31 +0000 Message-ID: <5474D6BA.2000301@alum.mit.edu> Date: Tue, 25 Nov 2014 14:21:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.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=q20140121; t=1416943291; bh=MDer4q+TB+2Je9XsKNobTKqyo9ixaInFswUwjKjZ7nc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Kq/83ibGSqq7ZTG7c8vVrAOaPDRkI3FXF5Vkxpz4Kmu5nwCthEF3RM7j89GJiH7ab KquXsUsTR2loVm33a/zAE90bEFqnTNqO5LPUgcdqPwyb6RIbsZH/llMUB5paLlD42f NerYea1MAye0kxSqwdhP2aGu3OiPEZGDmHuOIlZwGLHHmslaKJJeBypTF3dicpZZrN xmIHEkvEhGu1ZhWhANrF38CmztTzLBQdfjOoc52OeeJo+zecAefzxAVo+x49HYYWRJ wZHg2koaa3XOBSKA8HBzock1eOJE94PUxW1IbQI2mCH45d8VlUooHPvIrbqb+E+KrQ Ba0qXApOhbaiA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/yqFny6dXFzqJpdxEKpTP18a0vHk Subject: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 19:21:34 -0000 During IETF91 we agreed to start the WGLC of the Framework immediately after the meeting. So I am calling the start of that WGLC today. At least here in the US people are pretty distracted around the holidays (starting this week), so we will allow extra calendar time to complete this. The end of this WGLC will be end of the day (wherever you are) on Wednesday December 17. That gives three weeks plus roundoff for today. If all is in order this will be the last review of this document by the WG before it goes to the ADs and the IESG. So we need careful, thorough reviews of the full document, not just diffs from a prior version. To ensure that you are all paying attention, please respond to this message with your indication that you indeed plan to submit a review. (To get the ball rolling, *I* plan to do a WGLC reviewe of this draft.) Thanks, Paul (for all the chairs) From nobody Tue Nov 25 12: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 E0B7A1A7005 for ; Tue, 25 Nov 2014 12:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 VUnFe3K74p74 for ; Tue, 25 Nov 2014 12:29:14 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.102]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACDF1A2119 for ; Tue, 25 Nov 2014 12:29:14 -0800 (PST) Received: from [216.82.254.20] by server-6.bemta-7.messagelabs.com id 52/FC-03126-A96E4745; Tue, 25 Nov 2014 20:29:14 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-12.tower-47.messagelabs.com!1416947262!15968634!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3317 invoked from network); 25 Nov 2014 20:27:43 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-12.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 25 Nov 2014 20:27:43 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 25 Nov 2014 12:27:42 -0800 From: "Duckworth, Mark" To: Paul Kyzivat Date: Tue, 25 Nov 2014 12:27:40 -0800 Thread-Topic: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. Thread-Index: AdAI5T+xMd7/rD0QQgSQ9ozpHq0XXQACHFiw Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE1E4@CRPMBOXPRD08.polycom.com> References: <5474D6BA.2000301@alum.mit.edu> In-Reply-To: <5474D6BA.2000301@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/JrjdbLep8UXXv3Z-hn3O7GHDil0 Cc: CLUE Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 20:29:17 -0000 Hi Paul, Assuming the consensus call about removing CLUE controlled simulcast says y= es remove it, I can submit a new version of the framework shortly after tha= t, so I assume by Dec 4. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, November 25, 2014 2:22 PM > To: CLUE > Subject: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec > 17. >=20 > During IETF91 we agreed to start the WGLC of the Framework immediately > after the meeting. So I am calling the start of that WGLC today. At > least here in the US people are pretty distracted around the holidays > (starting this week), so we will allow extra calendar time to complete > this. The end of this WGLC will be end of the day (wherever you are) on > Wednesday December 17. That gives three weeks plus roundoff for today. >=20 > If all is in order this will be the last review of this document by the > WG before it goes to the ADs and the IESG. So we need careful, thorough > reviews of the full document, not just diffs from a prior version. >=20 > To ensure that you are all paying attention, please respond to this > message with your indication that you indeed plan to submit a review. >=20 > (To get the ball rolling, *I* plan to do a WGLC reviewe of this draft.) >=20 > Thanks, > Paul (for all the chairs) >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Nov 25 13:08: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 1386C1A6FF7 for ; Tue, 25 Nov 2014 13:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 HwduFAcYlZ39 for ; Tue, 25 Nov 2014 13:07:11 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.111]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A841A7D81 for ; Tue, 25 Nov 2014 13:07:11 -0800 (PST) Received: from [216.82.254.20] by server-15.bemta-7.messagelabs.com id A4/5D-02693-E7FE4745; Tue, 25 Nov 2014 21:07:10 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-47.messagelabs.com!1416949510!15787704!3 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21011 invoked from network); 25 Nov 2014 21:05:30 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-14.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 25 Nov 2014 21:05:30 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 25 Nov 2014 13:05:18 -0800 From: "Duckworth, Mark" To: Paul Kyzivat Date: Tue, 25 Nov 2014 13:05:15 -0800 Thread-Topic: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. Thread-Index: AdAI5T+xMd7/rD0QQgSQ9ozpHq0XXQACHFiwAAFTPvA= Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE1EF@CRPMBOXPRD08.polycom.com> References: <5474D6BA.2000301@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE1E4@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE1E4@CRPMBOXPRD08.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_5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE1EFCRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/lneuJdiwTajJwDQaWa6YkOjg0S0 Cc: CLUE Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2014 21:07:15 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE1EFCRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I forgot to mention I also have to make a small change to resolve Ticket #6= 4. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark > Sent: Tuesday, November 25, 2014 3:28 PM > To: Paul Kyzivat > Cc: CLUE > Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday > Dec 17. > > Hi Paul, > Assuming the consensus call about removing CLUE controlled simulcast says > yes remove it, I can submit a new version of the framework shortly after > that, so I assume by Dec 4. > Mark > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Tuesday, November 25, 2014 2:22 PM > > To: CLUE > > Subject: [clue] WGLC of CLUE Framework now started. Ends Wednesday > Dec > > 17. > > > > During IETF91 we agreed to start the WGLC of the Framework immediately > > after the meeting. So I am calling the start of that WGLC today. At > > least here in the US people are pretty distracted around the holidays > > (starting this week), so we will allow extra calendar time to complete > > this. The end of this WGLC will be end of the day (wherever you are) on > > Wednesday December 17. That gives three weeks plus roundoff for today. > > > > If all is in order this will be the last review of this document by the > > WG before it goes to the ADs and the IESG. So we need careful, thorough > > reviews of the full document, not just diffs from a prior version. > > > > To ensure that you are all paying attention, please respond to this > > message with your indication that you indeed plan to submit a review. > > > > (To get the ball rolling, *I* plan to do a WGLC reviewe of this draft.) > > > > Thanks, > > Paul (for all the chairs) --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE1EFCRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I forgot to m= ention I also have to make a small change to resolve Ticket #64.

Mark

 

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

> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Du= ckworth, Mark

> Sent: Tuesday, November 25, 2= 014 3:28 PM

> To: Paul Kyzivat

> Cc: CLUE

> Subject: Re: [cl= ue] WGLC of CLUE Framework now started. Ends Wednesday

> Dec 17.

>

> Hi Paul,

> Assuming the consensus c= all about removing CLUE controlled simulcast says

> yes remove it, I can submit a new version of the framework shortly a= fter

> that, so I assume by Dec 4.

> Mark

>

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

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

> > Sent: Tuesday, November 25, 2014 2= :22 PM

> > To: CLUE

> > Subject: [clue] WGLC of CLUE Framework now started. Ends Wed= nesday

> Dec

> = > 17.

> >

&g= t; > During IETF91 we agreed to start the WGLC of the Framework immediat= ely

> > after the meeting. So I am calling= the start of that WGLC today. At

> > leas= t here in the US people are pretty distracted around the holidays

> > (starting this week), so we will allow extra ca= lendar time to complete

> > this. The end = of this WGLC will be end of the day (wherever you are) on

> > Wednesday December 17. That gives three weeks plus roun= doff for today.

> >

> > If all is in order this will be the last review of this docu= ment by the

> > WG before it goes to the A= Ds and the IESG. So we need careful, thorough

&g= t; > reviews of the full document, not just diffs from a prior version.<= /p>

> >

> > T= o ensure that you are all paying attention, please respond to this

> > message with your indication that you indeed p= lan to submit a review.

> >

> > (To get the ball rolling, *I* plan to do a WGLC revi= ewe of this draft.)

> >

> >          Thanks,=

> >       &= nbsp;  Paul (for all the chairs)

 = ;

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE1EFCRPMBOXPRD08p_-- From nobody Tue Nov 25 16:20: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 D18701A89B3 for ; Tue, 25 Nov 2014 16: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 HWOyFSUuAtBy for ; Tue, 25 Nov 2014 16:20:39 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5A81A89A6 for ; Tue, 25 Nov 2014 16:20:39 -0800 (PST) Received: from ppp118-209-10-178.lns20.mel4.internode.on.net ([118.209.10.178]:52590 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XtQKL-0000BR-M6 for clue@ietf.org; Wed, 26 Nov 2014 11:19:25 +1100 Message-ID: <54751CD0.2070805@nteczone.com> Date: Wed, 26 Nov 2014 11:20:32 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> <5473BE59.4070805@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D53548A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53577E@ESESSMB209.ericsson.se> , <5474CDA8.8030004@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5366AB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5366AB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6SpXSdaVmIr873RDlLwdaVEB1kg Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2014 00:20:42 -0000 I'm OK with dropping DCEP. It could be worth keeping the DCEP code point as you say for non-O/A environment. Regards, Christian On 26/11/2014 6:17 AM, Christer Holmberg wrote: > Hi, > > I agree with Paul. > > But, the question is still whether the CLUE data channel spec ahould > still define the DCEP code point for the CLUE data channel, IF someone > e.g. want to specify usage of CLUE in a non-O/A environment. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Paul Kyzivat > Sent: ‎25/‎11/‎2014 20:43 > To: clue@ietf.org > Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP > > On 11/25/14 7:00 AM, Makaraju, Maridi Raju (Raju) wrote: > > > >> Hi, > >> > >>>> If you provide the SCTP port in the WebRTC API, then DCEP won't > be used. > >>> You meant "(stream) id" instead of "SCTP port"? > >> > >> Yes. > >> > >>> In WebRTC API createDataChannel(), use of DCEP is controlled by using > >> "negotiated" parameter. (Stream) id specification only determines > the stream > >> id to be used. > >> > >> Ok. But, the point is that you can create a data channel without DCEP. > > [Raju] > > IMHO, I am in favor of not mandating DCEP for non-WebRTC device CLUE > usage. Furthermore, to be consistent it may be better not to use DCEP > even when CLUE is used by a WebRTC device. > > If we mandate using draft-ejzak for establishing the clue channel, then > DCEP won't be *used*. I think we simply make a requirement for support > of draft-ietf-rtcweb-data-channel, and don't mention > draft-ietf-rtcweb-data-protocol. If there are dependencies between those > two, then that is not our problem. (I thought data-channel had a > dependency on data-protocol, but I don't see it now, which is a good > thing.) > > Thanks, > Paul > > > BR > > Raju > > > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >>> -----Original Message----- > >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer > >>> Holmberg > >>> Sent: Tuesday, November 25, 2014 5:24 AM > >>> To: Christian Groves; clue@ietf.org > >>> Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and > >>> DCEP > >>> > >>> Hi, > >>> > >>> If I understood Paul's comment, DCEP is not required for compatibility > >>> with WebRTC endpoints. If you provide the SCTP port in the WebRTC API, > >>> then DCEP won't be used. > >>> > >>> The question is really whether we want to mandate non-WebRTC CLUE > >>> devices to implement DCEP or not. > >>> > >>> 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 nobody Tue Nov 25 16:25: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 F01301A878A for ; Tue, 25 Nov 2014 16:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 1mQJuc5s-QH1 for ; Tue, 25 Nov 2014 16:24:59 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8511A701B for ; Tue, 25 Nov 2014 16:24:59 -0800 (PST) Received: from ppp118-209-10-178.lns20.mel4.internode.on.net ([118.209.10.178]:52599 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XtQOY-0000iG-Hs for clue@ietf.org; Wed, 26 Nov 2014 11:23:46 +1100 Message-ID: <54751DD5.20308@nteczone.com> Date: Wed, 26 Nov 2014 11:24:53 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5473AC21.7000205@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/lY5El5b_BSvr9Mup3Jpl9lsmqBs Subject: Re: [clue] Consensus call: remove clue-specific simulcast X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2014 00:25:01 -0000 I'm OK with removing list with Rob's clarification below. As a result we'll need to revisit some of the examples. Also as I raised, we should provide some clarification on the use of maxbandwidth as a result. Regards, Christian On 25/11/2014 9:09 PM, Robert Hansen (rohanse2) wrote: > YES, I support removing this. > > (specifically, removing the maxCaptureEncodings element and mandating that a capture can be mapped to at most one encoding). > > Rob > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 24 November 2014 22:07 > To: CLUE > Subject: [clue] Consensus call: remove clue-specific simulcast > > During the Honululu meeting we had consensus to remove the clue-specific simulcast mechanism (via configuring the same capture with two or more encodings). The expectation is that, in lieu of this clue will rely on an SDP mechanism for negotiating simulcast within a single m-line. (The mmusic wg adopted draft-westerlund-avtcore-rtp-simulcast-04 as a wg item at this meeting.) > > This message brings that question to the list for confirmation. > > Please indicate if you support removal of the clue-specific simulcast > mechanism: YES/NO. > > If you indicate NO, please provide a detailed reason why not. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Nov 26 08:18: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 03C411A0204 for ; Wed, 26 Nov 2014 08:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 xlAn14cl4EmW for ; Wed, 26 Nov 2014 08:18:54 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.205]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAE81A01AA for ; Wed, 26 Nov 2014 08:18:53 -0800 (PST) Received: from [216.82.241.100] by server-13.bemta-8.messagelabs.com id D8/5F-30616-C6DF5745; Wed, 26 Nov 2014 16:18:52 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-220.messagelabs.com!1417018728!17747638!5 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13748 invoked from network); 26 Nov 2014 16:18:52 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-9.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 26 Nov 2014 16:18:52 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 26 Nov 2014 08:17:12 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Wed, 26 Nov 2014 08:17:09 -0800 Thread-Topic: maxgroupbandwidth clarification? Thread-Index: AdAJlFN+5j09/EvWRxm1diwe3NgX+Q== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE262@CRPMBOXPRD08.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 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6CV0jCnR8CHS_15FyXaxgOw8tDg Subject: [clue] maxgroupbandwidth clarification? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2014 16:18:56 -0000 Hi Christian, Maybe we should have some clarification about maxgroupbandwidth, but I thin= k the simulcast question really has no bearing on it. Use of maxgroupbandw= idth, and relation to SDP, should be the same whether we do CLUE protocol l= evel simulcast or not. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Tuesday, November 25, 2014 7:25 PM > To: clue@ietf.org > Subject: Re: [clue] Consensus call: remove clue-specific simulcast >=20 > I'm OK with removing list with Rob's clarification below. As a result > we'll need to revisit some of the examples. Also as I raised, we should > provide some clarification on the use of maxbandwidth as a result. >=20 > Regards, Christian >=20 >=20 > On 25/11/2014 9:09 PM, Robert Hansen (rohanse2) wrote: > > YES, I support removing this. > > > > (specifically, removing the maxCaptureEncodings element and mandating > that a capture can be mapped to at most one encoding). > > > > Rob > > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 24 November 2014 22:07 > > To: CLUE > > Subject: [clue] Consensus call: remove clue-specific simulcast > > > > During the Honululu meeting we had consensus to remove the clue- > specific simulcast mechanism (via configuring the same capture with two o= r > more encodings). The expectation is that, in lieu of this clue will rely = on an > SDP mechanism for negotiating simulcast within a single m-line. (The mmus= ic > wg adopted draft-westerlund-avtcore-rtp-simulcast-04 as a wg item at this > meeting.) > > > > This message brings that question to the list for confirmation. > > > > Please indicate if you support removal of the clue-specific simulcast > > mechanism: YES/NO. > > > > If you indicate NO, please provide a detailed reason why not. > > > > 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 > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Nov 26 11:26: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 471651A038E for ; Wed, 26 Nov 2014 11:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1UklD-7WW3c for ; Wed, 26 Nov 2014 11:26:47 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9960C1A0364 for ; Wed, 26 Nov 2014 11:26:46 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so13608669wiw.7 for ; Wed, 26 Nov 2014 11:26:45 -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=propJXGpjNVyRxvH8qK6yh/ZbLOcH17nJiSQ3d5T2Rs=; b=ePeBruBSf08+Wwi6wRQypAOkI6k5YzXtEjDYYiKPi57lCwz9aHy+PAQQTjkTAsO84K JZfFlv89RoVbDqgRQ4ajaVW8QJeR0ny9br6auYQ6hZOudgMp3nq477PrsRSYAzW+YkhR BUpJ2Vs6rTX3MOCoszkYdfzNLIFiisbJg15WslqVUsTwPytYxgVGM+acFrPaHue9zyxH b4lY3Ix6TKvtVudkyL1K3iNnqgycTZwGkHPk1FP3bwQpkbQ6+Ea8Re2jDH8yrFwZ46IY 2nD6a7zC/72sYdk0sjqMt85Y4emu1u83FtQC+NNmiujFtIy+m/ShOsYOJ99Eztwj1j65 //2w== X-Received: by 10.194.5.227 with SMTP id v3mr52870264wjv.63.1417030005375; Wed, 26 Nov 2014 11:26:45 -0800 (PST) Received: from RoniE ([109.65.124.153]) by mx.google.com with ESMTPSA id hs1sm22168413wib.1.2014.11.26.11.26.42 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 26 Nov 2014 11:26:44 -0800 (PST) From: "Roni Even" To: "'Simon Pietro Romano'" , "'CLUE'" References: <5473AC21.7000205@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE135@CRPMBOXPRD08.polycom.com> <3C1EB3B9-4B22-4F1D-A01B-470564562054@unina.it> In-Reply-To: <3C1EB3B9-4B22-4F1D-A01B-470564562054@unina.it> Date: Wed, 26 Nov 2014 21:26:41 +0200 Message-ID: <021401d009ae$ea0e4e70$be2aeb50$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0215_01D009BF.AD98A510" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFYrTjyH2sq5liyj4lwg1046jFbcQHj3GWUAq2H6lKdPXgQoA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/s9b1oT_BUdxvrf9hNZ3bZu9KWFw Subject: Re: [clue] Consensus call: remove clue-specific simulcast X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2014 19:26:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0215_01D009BF.AD98A510 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, will add the reference to the SDP based solution in the RTP mapping = document. Roni =20 From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Simon Pietro = Romano Sent: 25 November, 2014 4:21 PM To: CLUE Subject: Re: [clue] Consensus call: remove clue-specific simulcast =20 YES. =20 Simon =20 =20 On 25/nov/2014, at 14:55, Duckworth, Mark = wrote: =20 YES Mark -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, November 24, 2014 5:07 PM To: CLUE Subject: [clue] Consensus call: remove clue-specific simulcast During the Honululu meeting we had consensus to remove the clue-specific simulcast mechanism (via configuring the same capture with two or more encodings). The expectation is that, in lieu of this clue will rely on an SDP mechanism for negotiating simulcast within a single m-line. (The mmusic wg adopted draft-westerlund-avtcore-rtp-simulcast-04 as a wg item at this meeting.) This message brings that question to the list for confirmation. Please indicate if you support removal of the clue-specific simulcast mechanism: YES/NO. If you indicate NO, please provide a detailed reason why not. 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 =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 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ = \ ( ( ) \_) = ) / = (_/ =20 =20 =20 =20 ------=_NextPart_000_0215_01D009BF.AD98A510 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Yes, will add the reference to the SDP based solution in the RTP = mapping document.

Roni

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Simon Pietro = Romano
Sent: 25 November, 2014 4:21 PM
To: = CLUE
Subject: Re: [clue] Consensus call: remove clue-specific = simulcast

 

YES.

 

Simon

 

 

On 25/nov/2014, at 14:55, Duckworth, Mark <Mark.Duckworth@polycom.com= > wrote:

 

YES
Mark


-----Original Message-----
From: clue [mailto:clue-bounces@ietf.org] = On Behalf Of Paul Kyzivat
Sent: Monday, November 24, 2014 5:07 = PM
To: CLUE
Subject: [clue] Consensus call: remove clue-specific = simulcast

During the Honululu meeting we had consensus to remove = the clue-specific
simulcast mechanism (via configuring the same = capture with two or more
encodings). The expectation is that, in lieu = of this clue will rely on
an SDP mechanism for negotiating simulcast = within a single m-line. (The
mmusic wg adopted = draft-westerlund-avtcore-rtp-simulcast-04 as a wg item
at this = meeting.)

This message brings that question to the list for = confirmation.

Please indicate if you support removal of the = clue-specific simulcast
mechanism: YES/NO.

If you indicate NO, = please provide a detailed reason why not.

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

_______________________________________________
clu= e mailing list
clue@ietf.org
https://www.ietf.org/= mailman/listinfo/clue


______________________________________= _________
clue mailing list
clue@ietf.org
https://www.ietf.org/= mailman/listinfo/clue

 

    =                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0        = _\\|//_

    =                     =    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     =   ( O-O )

  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

    =                 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Simon Pietro Romano

    =          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =  Universita' di = Napoli Federico II

    =             =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     =  Computer Engineering = Department 

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     =          Phone: +39 081 7683823 -- Fax: +39 081 = 7683816

    =                     =                   =  e-mail: spromano@unina.it=

 

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     = <<Molti mi dicono che lo scoraggiamento =C3=A8 l'alibi = degli 

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0    =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.

    =            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0   =                   =  oooO

  = ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

<= p class=3DMsoNormal>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0     =              \ (       =      (   )

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0     =                     =           \_)         =  ) /

    =                     =                     =                     =        (_/

 

 

 



 

------=_NextPart_000_0215_01D009BF.AD98A510-- From nobody Wed Nov 26 19:33: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 8BBDB1A8739 for ; Wed, 26 Nov 2014 19:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28-KeIuSaoN8 for ; Wed, 26 Nov 2014 19:33:45 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664961A870B for ; Wed, 26 Nov 2014 19:33:45 -0800 (PST) Received: from ppp118-209-73-194.lns20.mel4.internode.on.net ([118.209.73.194]:54036 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XtpoV-0001O9-Pc; Thu, 27 Nov 2014 14:32:15 +1100 Message-ID: <54769B91.5090807@nteczone.com> Date: Thu, 27 Nov 2014 14:33:37 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE262@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DAFE262@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/z1l3rDeIJqmunvzP0GPUq7isziM Subject: Re: [clue] maxgroupbandwidth clarification? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2014 03:33:47 -0000 Hello Mark, I agree in general. A specific case I was thinking about was that previously with the CLUE simulcast if additional encodings (say for other media) were added to the group, the maxgroupbandwidth would apply to all the encodings. Moving simulcast to SDP would allow a "simulcast" maxbandwidth to be assigned (via SDP) as well as the overall CLUE encoding group maxbandwidth. This would prevent the simulcast media from dominating the bandwidth where other encodings are involved. Regards, Christian On 27/11/2014 3:17 AM, Duckworth, Mark wrote: > Hi Christian, > Maybe we should have some clarification about maxgroupbandwidth, but I think the simulcast question really has no bearing on it. Use of maxgroupbandwidth, and relation to SDP, should be the same whether we do CLUE protocol level simulcast or not. > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Tuesday, November 25, 2014 7:25 PM >> To: clue@ietf.org >> Subject: Re: [clue] Consensus call: remove clue-specific simulcast >> >> I'm OK with removing list with Rob's clarification below. As a result >> we'll need to revisit some of the examples. Also as I raised, we should >> provide some clarification on the use of maxbandwidth as a result. >> >> Regards, Christian >> >> >> On 25/11/2014 9:09 PM, Robert Hansen (rohanse2) wrote: >>> YES, I support removing this. >>> >>> (specifically, removing the maxCaptureEncodings element and mandating >> that a capture can be mapped to at most one encoding). >>> Rob >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: 24 November 2014 22:07 >>> To: CLUE >>> Subject: [clue] Consensus call: remove clue-specific simulcast >>> >>> During the Honululu meeting we had consensus to remove the clue- >> specific simulcast mechanism (via configuring the same capture with two or >> more encodings). The expectation is that, in lieu of this clue will rely on an >> SDP mechanism for negotiating simulcast within a single m-line. (The mmusic >> wg adopted draft-westerlund-avtcore-rtp-simulcast-04 as a wg item at this >> meeting.) >>> This message brings that question to the list for confirmation. >>> >>> Please indicate if you support removal of the clue-specific simulcast >>> mechanism: YES/NO. >>> >>> If you indicate NO, please provide a detailed reason why not. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Thu Nov 27 01:04: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 190391A88AD; Thu, 27 Nov 2014 01:04:33 -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 fipvstRdYC2N; Thu, 27 Nov 2014 01:04:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 777D71A88AC; Thu, 27 Nov 2014 01:04:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141127090429.5188.2980.idtracker@ietfa.amsl.com> Date: Thu, 27 Nov 2014 01:04:29 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/rhYSg65E9f_RIZa2WKRro8IGUPE Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 09:04:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : CLUE Protocol Data Channel Author : Christer Holmberg Filename : draft-ietf-clue-datachannel-05.txt Pages : 12 Date : 2014-11-27 Abstract: This document defines how to use the WebRTC Data Channel mechanism in order to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association used to realize the CLUE data channel using SDP, and defines usage of two mechanisms for establishing a CLUE data channel: the Data Channel Establishment Protocol (DCEP) and the SDP-based "SCTP over DTLS" data channel negotiation mechanism. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating usage of a CLUE data channel, are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-datachannel-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 27 01:07: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 160461A6F1D for ; Thu, 27 Nov 2014 01:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZbyFFZ7el5ry for ; Thu, 27 Nov 2014 01:07:20 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B331A88AB for ; Thu, 27 Nov 2014 01:07:19 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-30-5476e9c5fdde Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AD.D7.04076.5C9E6745; Thu, 27 Nov 2014 10:07:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0195.001; Thu, 27 Nov 2014 10:07:17 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft new version: draft-ietf-clue-datachannel-05 Thread-Index: AdAKIUwZiYIXRXLbR4mwJbN/fwgIPg== Date: Thu, 27 Nov 2014 09:07:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53B265@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D53B265ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje7Rl2UhBgfXmFjsP3WZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGf/WnWEvuC9ZsevCHKYGxvNiXYycHBICJhIfp/9nhrDFJC7c W8/WxcjFISRwhFHi2qNeZghnCaPEjHfrWLoYOTjYBCwkuv9pgzSICChLHN3czwZiCwtYSVzp vs4EUiIiYC8xZ7EMhKknsW5KJUgFi4CqxMcbq1hBbF4BX4klm1YxgdiMQGu/n1oDZjMLiEvc ejKfCeIcAYkle85DnSYq8fLxP1YIW1Fi59l2Zoj6fImJl9vYIGYKSpyc+YRlAqPQLCSjZiEp m4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1OLS7OTTcy0kstykwuLs7P08tL LdnECIyHg1t+W+1gPPjc8RCjAAejEg/vh9NlIUKsiWXFlbmHGKU5WJTEeReemxcsJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgbHpTOKs8lqVu7G7P92N+7S7S/ae/6cbS28cFjlenHCUq01m 6d2W0KezHCTMor4f6Dgz5cG2/hbjmq6P3g8PX/MumVC9IuRytXLAR+9T3/dv1XNteCX2Y2NQ MN9h1R8vnQPXPCz33+R+aK/baVs3y5DnF1YaazLMmhjd4rHS++DzfS+4LRS/X0tUYinOSDTU Yi4qTgQAIkKj22gCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/MKV5ZwYbWuqGInM2uqJd6dH8nWo Subject: [clue] Draft new version: draft-ietf-clue-datachannel-05 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2014 09:07:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D53B265ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the CLUE data channel draft. I have now described DCEP and Keith Richard as two separate mechanisms for = establishing a CLUE Data Channel. Both mechanisms are based on usage of SDP Offer/Answer (e.g. how the m- lin= e is created, which endpoints sends the DCEP open message etc), but there a= re notes indicating that other protocols might also be used. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D53B265ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version of the CLUE data = channel draft.

 

I have now described DCEP and Keith Richard as two s= eparate mechanisms for establishing a CLUE Data Channel.

 

Both mechanisms are based on usage of SDP Offer/Answ= er (e.g. how the m- line is created, which endpoints sends the DCEP open me= ssage etc), but there are notes indicating that other protocols might also = be used.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D53B265ESESSMB209erics_-- From nobody Thu Nov 27 17:24:57 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE611A038A for ; Thu, 27 Nov 2014 17:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 hgNIrRQcBaEK for ; Thu, 27 Nov 2014 17:24:54 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D912D1A0387 for ; Thu, 27 Nov 2014 17:24:53 -0800 (PST) Received: from ppp118-209-167-44.lns20.mel8.internode.on.net ([118.209.167.44]:54757 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XuAHA-00043l-VC for clue@ietf.org; Fri, 28 Nov 2014 12:23:13 +1100 Message-ID: <5477CEDE.30907@nteczone.com> Date: Fri, 28 Nov 2014 12:24:46 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5_-dDMpSkL2C1kkPgqjEhar1kYI Subject: [clue] Diff mechanism X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 28 Nov 2014 01:24:55 -0000 Hello, Another issue that seemed to come up in the Hawaii meeting was whether the diff mechanism should be kept? I'm for keeping it in the protocol draft. If people don't want it to be mandatory then its use could be signalled through the OPTIONS message. Regards, Christian From nobody Fri Nov 28 06:10: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 7402C1A1A98 for ; Fri, 28 Nov 2014 06:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ejnyX6bmA6SR for ; Fri, 28 Nov 2014 06:09:37 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABAC1A1B26 for ; Fri, 28 Nov 2014 06:09:36 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-db-5478821e6210 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 86.4B.04231.E1288745; Fri, 28 Nov 2014 15:09:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.126]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 15:09:34 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-08.txt Thread-Index: AQHQCxRx1iae8tO9U0eS4jtCB30HDpx2E6lg Date: Fri, 28 Nov 2014 14:09:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D53F594@ESESSMB209.ericsson.se> References: <20141128140523.13879.56557.idtracker@ietfa.amsl.com> In-Reply-To: <20141128140523.13879.56557.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvja5cU0WIwccV1hb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsqVa5kLlghWXN7TyNzAeI23i5GTQ0LARGLvzSuMELaYxIV7 69m6GLk4hASOMEqsfvyaDSQhJLCEUWLSJ58uRg4ONgELie5/2iBhEQFliaOb+8FKhAWcJa5c 38oEEXeR2PBwOgtIuYiAkcTUqbIgYRYBVYmzM2awgti8Ar4SC598ZYSY7ihx/dF2sDingJPE 2vblYGMYgc75fmoNmM0sIC5x68l8JogzBSSW7DnPDGGLSrx8/I8VwlaS+LHhEgtEvY7Egt2f 2CBsbYllC18zQ+wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxihanFhfnphsZ66UWZSYX F+fn6eWllmxiBMbDwS2/dXcwrn7teIhRgINRiYe3QLYiRIg1say4MvcQozQHi5I476Jz84KF BNITS1KzU1MLUovii0pzUosPMTJxcEo1MDYf6KoNMFo/69LvVL8Xi95KPqoPuG508sNz2YRm +39nMjb+5fM8+znw8EXxSV5V9cJX1li/NDhv3z9HcPOd9DYzwyurzq68+8i6y9/d7ebPk9zr uur/xK9ymBQhKu8SJnThxa2qQ58muqXusFQQ2XrMaIF61uTm1WsyyhOUMze3zMw/X7Eofq4S S3FGoqEWc1FxIgAn7BEFaAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/DQsaw5fUWkey2JTx2yaDQcDv6ZA Subject: [clue] FW: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-08.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: Fri, 28 Nov 2014 14:09:45 -0000 FYI, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: 28. marraskuuta 2014 16:05 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Stream Control Transmission Protocol (SCTP)-Based= Media Transport in the Session Description Protocol (SDP) Authors : Christer Holmberg Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-08.txt Pages : 16 Date : 2014-11-28 Abstract: SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This specification describes how to describe SCTP associations using the Session Description Protocol (SDP), and defines the following new SDP Media Description protocol identifiers (proto values):'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'. The specification also describes how to use the new proto values together with the SDP Offer/Answer mechanism in order to negotiate and establish SCTP associations, and how to indicate the SCTP application usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-08 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic