From nobody Thu May 1 03:59: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 53CE41A6F1F for ; Thu, 1 May 2014 03:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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_81=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 IqJUz8YVGL0m for ; Thu, 1 May 2014 03:58:58 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B625F1A075F for ; Thu, 1 May 2014 03:58:57 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id ld13so3689930vcb.2 for ; Thu, 01 May 2014 03:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8tFiLgAV4/lMclQ/rGWf8BMTh/Hi9YpRFVwtovgOdyI=; b=FPziBxRKC3GHTHBCDzO57wOm8pjnRZvly3dmBZddmeEmmwXpnsyXQQzzS/EiTBKzGP ZzFz278yjTljIrqaNbN9BZqrEN08TmIZjLMiOOpxbeYwEVlFnAcZKmrhSqKIwhmQ0mJ8 WBVDrlcFsKJApHDoMfgO5RT2O/T6leG/l+nbDb7FPJAYJ4qnclZlG8jSGk1rgihU0OQY uKCJrKmKGTGkH+fE53Mzoak/8pJXxeScJhWQYBRMbl3kxX8QT/yXi9Nes0NDlw5/MktI KTYHUrug1dmi9qUMHtH3jJn0j/7xMHMtNOWnAthJy0gIL2tn+81h18j8bGDmT3ACbP2O JWRA== MIME-Version: 1.0 X-Received: by 10.58.105.105 with SMTP id gl9mr8405912veb.3.1398941935691; Thu, 01 May 2014 03:58:55 -0700 (PDT) Received: by 10.221.40.135 with HTTP; Thu, 1 May 2014 03:58:55 -0700 (PDT) In-Reply-To: <5361C8EA.2060206@nteczone.com> References: <533AF351.9050201@alum.mit.edu> <20140410222705.GW39240@verdi> <53475572.4040807@nteczone.com> <20140411150055.GE60844@verdi> <49E45C59CA48264997FEBFB29B6BC2D6215295A8AE@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D62409219636@CRPMBOXPRD07.polycom.com> <534B4303.7060707@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F07152B@CRPMBOXPRD08.polycom.com> <534B536B.8000205@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13D9B2@CRPMBOXPRD08.polycom.com> <535F0B3A.70808@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13DAE6@CRPMBOXPRD08.polycom.com> <5361C8EA.2060206@nteczone.com> Date: Thu, 1 May 2014 06:58:55 -0400 Message-ID: From: Stephen Botzko To: Christian Groves Content-Type: multipart/alternative; boundary=047d7b5d2c30236d7d04f8548dc5 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YhGjoUSbOA4nhG3m2ve5fk_-AlA Cc: "clue@ietf.org" Subject: Re: [clue] Improving treatment of audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 10:59:00 -0000 --047d7b5d2c30236d7d04f8548dc5 Content-Type: text/plain; charset=UTF-8 In-line On Thu, May 1, 2014 at 12:09 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mark, > > Please see my replies below. > > Regards, Christian > > > On 30/04/2014 11:28 PM, Duckworth, Mark wrote: > >> Hi Christian, >> Thanks for elaborating on the idea. I have some more questions inline. >> I see basically what you are trying to do, but I still think it doesn't >> work in practice any better than what we already have, as I explain below. >> Mark >> >> -----Original Message----- >>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>> Sent: Monday, April 28, 2014 10:15 PM >>> To: Duckworth, Mark; clue@ietf.org >>> Subject: Re: [clue] Improving treatment of audio >>> >>> Hello Mark, >>> >>> Please see below. >>> >>> Regards, Christian >>> >>> On 29/04/2014 11:36 AM, Duckworth, Mark wrote: >>> >>>> Hi Christian, >>>> I'm coming back to this message, because I'm trying to understand your >>>> >>> proposal. You proposed "in each audio capture we say what VC it relates >>> to." >>> What does this mean? What does it mean for an audio capture to relate >>> to a >>> video capture? What exactly is the producer telling the consumer? Can >>> an >>> audio capture relate to more than one video capture? >>> [CNG] The meaning has largely the same semantic as if the ADV used the >>> same capture area on a VC and AC. Basically its saying that the audio >>> comes >>> from the same "region" as what the video capture does. I think the >>> difference is that its not trying to put a mathematical certainty about >>> what >>> that region is. Its a way for the producer to say to the consumer if you >>> choose >>> video capture A you probably want to choose audio capture B for a good >>> experience. >>> >> [Duckworth, Mark] If that is the meaning, then would it be better for the >> provider to advertise a list of audio captures that are "related to" each >> video capture? Rather than the other way around? Maybe I'm not >> understanding the problem you are trying to solve. >> > [CNG] I don't think it matters the way it is defined. video related to > audio or audio related to video is essentially the same thing. The problem > I'm trying to solve is how does the media consumer know which audio > captures to choose when presented with a list of captures. > > As I mentioned in an earlier email I think people where seeing the "area > of capture" in two separate ways. The first way was using the area of > capture to determine which video captures the audio related to (i.e. > capture selection). The second was concentrating on how to use the area of > capture information for audio rendering (i.e. capture rendering). I'm > focusing on the first, capture selection. > > [SB] I am wondering if you are interested in static selection - based on spatial information alone - or if you are more focused on dynamic capture selection - finding the video of the current talker for instance. Also, it might matter if you are trying to select video captures that go along with audio captures, or the other way around. My view is that selecting a subset of the audio captures in the room for rendering or distribution will likely result in bad audio much of the time - unless the sending system has expressly designed its audio pickup and seating arrangements to enable that. And a lot of systems won't be designed to allow it. I don't think it will be all that easy to detect that from details of the pickup pattern of each microphone or capture information. The general acoustics of the room also play into it, and I think the seating arrangement does also. It is possible that senders will create alternative sets of audio captures - for instance,a set of spatial audio captures that together provide full room pickup, and a single downmixed monophonic channel that also covers the full room. Receivers obviously need to sort that out, just like they do in the corresponding video case. My view is also that trying to select an appropriate video capture for display by examining the voice activity in all the audio captures in the room will result in showing the wrong video quite often. This is based on practical interoperability experience with TIP. It might be helpful if we first try to reach agreement on the limitations of this kind of selection before we dive into the protocol mechanics.[/SB] > > > > >> In terms of whether an audio capture can relate to more than >>> one video capture yes I think so. You could have one audio capture for a >>> room and three video captures. >>> >>>> More comments inline below. >>>> >>>> Regards, >>>> Mark >>>> >>>> -----Original Message----- >>>>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>>>> Sent: Sunday, April 13, 2014 11:18 PM >>>>> To: Duckworth, Mark; clue@ietf.org >>>>> Subject: Re: [clue] Improving treatment of audio >>>>> >>>>> Hello Mark, >>>>> >>>>> Sorry I didn't consider the entire 12.1.1. if I do that, according to >>>>> that >>>>> example: >>>>> >>>>> Video areas of capture: >>>>> >>>>> bottom left bottom right top left top right >>>>> VC0 (-2011,2850,0) (-673,3000,0) (-2011,2850,757) (-673,3000,757) >>>>> VC1 ( -673,3000,0) ( 673,3000,0) ( -673,3000,757) ( 673,3000,757) >>>>> VC2 ( 673,3000,0) (2011,2850,0) ( 673,3000,757) (2011,3000,757) >>>>> VC3 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) >>>>> VC4 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) >>>>> VC5 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) >>>>> VC6 none >>>>> >>>>> Areas of capture for audio (from 12.1.1): >>>>> >>>>> bottom left bottom right top left top right >>>>> >>>>> AC0 (-2011,2850,0) (-673,3000,0) (-2011,2850,757) (-673,3000,757) >>>>> AC1 ( 673,3000,0) (2011,2850,0) ( 673,3000,757) (2011,3000,757) >>>>> AC2 ( -673,3000,0) ( 673,3000,0) ( -673,3000,757) ( 673,3000,757) >>>>> AC3 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) >>>>> AC4 none >>>>> >>>>> Using a reference rather than area of capture: >>>>> AC0 (VC0) >>>>> AC1 (VC2) >>>>> AC2 (VC1) >>>>> AC3 (VC3,VC4,VC5) >>>>> I would think they are basically conveying the same information??? >>>>> >>>> [Duckworth, Mark] Looking from the consumer point of view, in trying to >>>> >>> understand the advertisement, what does the consumer know from the >>> advertisement? Suppose the consumer wants to get all three of VC0, VC1, >>> VC2, but it only wants a single audio capture. It should probably ask >>> for AC3, >>> but according to the advertisement AC3 doesn't "relate to" VC0, VC1, or >>> VC2. >>> [CNG] I agree. If the provider wanted to indicate that AC3 could also be >>> used >>> for VC0,VC1,VC2 it could advertise: >>> AC0 (VC0) >>> AC1 (VC2) >>> AC2 (VC1) >>> AC3 (VC0,VC1,VC2,VC3,VC4,VC5) >>> >> [Duckworth, Mark] I agree that AC3 (the whole room audio) "relates to" >> all those video captures. But earlier you said "the audio comes from the >> same 'region' as what the video capture does." So now do we have to modify >> that to say something like "the audio comes from the same region as the >> video, or a subset of that region, or a superset, or an overlapping >> region"? In this example, AC3 covers a region that is a superset of the >> VC0 region, a superset of the VC1 region, and a superset of the VC2 region. >> > [CNG] I was trying to illustrate the concept when I used the term > "region". I didn't mean for that to relate to a specific area. I prefer > "relates to" because that is essentially I'm trying specify. For the > purposes of capture selection you could specify the relation in terms of a > mathematical area or you can simply say the captures are related. > > > >> [Duckworth, Mark] For a case with a different consumer, suppose the >>>> >>> consumer wants the single video capture VC5, but it would like to receive >>> and render spatial audio. There is no audio capture with multiple >>> channels, >>> so it could ask for AC0, AC1, and AC2 if it knew how they were spatially >>> "related to" VC5. But according to the advertisement, AC0, AC1 and AC2 >>> aren't "related to" VC5 at all. >>> [CNG] So in this case there is no AC3? In that case the advertisement >>> could >>> look like: >>> AC0 (VC0,VC5) >>> AC1 (VC2,VC5) >>> AC2 (VC1,VC5) >>> >> [Duckworth, Mark] I didn't mean to remove AC3. That would still be there >> in this example. So now since the provider forms it's advertisement >> without knowing what the consumer wants to do, the provider has to give all >> this information: >> AC0 relates to (VC0, VC3, VC4, VC5) >> AC1 relates to (VC2, VC3, VC4, VC5) >> AC2 relates to (VC1, VC3, VC4, VC5) >> AC3 relates to (VC0, VC1, VC2, VC3, VC4, VC5) >> [Duckworth, Mark] Does this information really help the consumer? I >> don't think it is any better than what we already have with area of capture. >> > [CNG] Well it does say to the MC a number of things, for exmaple: > - if you're going to choose VC0 then either AC0 and AC3 would be the best > choice. > - AC3 is the best choice if you want one audio capture as it relates to > all video captures. > > My proposal was only duplicate what is supported by area of capture in > terms of relating audio and video captures for capture selection. The way > the discussion is going it seems that people are dubious about specifying > capture area for audio. The proposal is trying to get around that. > Another option would be to indicate that the capture area when used for > audio actually relates to a video capture region. However that seems to be > confusing to people. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --047d7b5d2c30236d7d04f8548dc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In-line


On Thu, May 1, 2014 at 12:09 AM, Christian Groves <= Christian.Groves@nteczone.com> wrote:
Hello Mark,

Please see my replies below.

Regards, Christian


On 30/04/2014 11:28 PM, Duckworth, Mark wrote:
Hi Christian,
Thanks for elaborating on the idea. =C2=A0I have some more questions inline= .
I see basically what you are trying to do, but I still think it doesn't= work in practice any better than what we already have, as I explain below.=
Mark

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@nteczone.com]
Sent: Monday, April 28, 2014 10:15 PM
To: Duckworth, Mark; clu= e@ietf.org
Subject: Re: [clue] Improving treatment of audio

Hello Mark,

Please see below.

Regards, Christian

On 29/04/2014 11:36 AM, Duckworth, Mark wrote:
Hi Christian,
I'm coming back to this message, because I'm trying to understand y= our
proposal. =C2=A0You proposed "in each audio capture we say what VC it = relates to."
What does this mean? =C2=A0What does it mean for an audio capture to relate= to a
video capture? =C2=A0What exactly is the producer telling the consumer? =C2= =A0Can an
audio capture relate to more than one video capture?
[CNG] The meaning has largely the same semantic as if the ADV used the
same capture area on a VC and AC. Basically its saying that the audio comes=
from the same "region" as what the video capture does. I think th= e
difference is that its not trying to put a mathematical certainty about wha= t
that region is. Its a way for the producer to say to the consumer if you ch= oose
video capture A you probably want to choose audio capture B for a good
experience.
[Duckworth, Mark] If that is the meaning, then would it be better for the p= rovider to advertise a list of audio captures that are "related to&quo= t; each video capture? =C2=A0Rather than the other way around? =C2=A0Maybe = I'm not understanding the problem you are trying to solve.
[CNG] I don't think it matters the way it is defined. video related to = audio or audio related to video is essentially the same thing. The problem = I'm trying to solve is how does the media consumer know which audio cap= tures to choose when presented with a list of captures.

As I mentioned in an earlier email I think people where seeing the "ar= ea of capture" in two separate ways. The first way was using the area = of capture to determine which video captures the audio related to (i.e. cap= ture selection). The second was concentrating on how to use the area of cap= ture information for audio rendering (i.e. capture rendering). I'm focu= sing on the first, capture selection.

[SB] I am wondering if = you are interested in static selection - based on spatial information alone= - or if you are more focused on dynamic capture selection - finding the vi= deo of the current talker for instance.
Also, it might matter if you are trying to select video captures that = go along with audio captures, or the other way around.

=
My view is that selecting a subset of the audio captures in the room f= or rendering or distribution will likely result in bad audio much of the ti= me - unless the sending system has expressly designed its audio pickup and = seating arrangements to enable that. And a lot of systems won't be desi= gned to allow it. I don't think it will be all that easy to detect that= from details of the pickup pattern of each microphone or capture informati= on. =C2=A0The general acoustics of the room also play into it, and I think = the seating arrangement does also.

It is possible that senders will create alternative set= s of audio captures - for instance,a set of spatial audio captures that tog= ether provide full room pickup, and a single downmixed monophonic channel t= hat also covers the full room. =C2=A0Receivers obviously need to sort that = out, just like they do in the corresponding video case.

My view is also that trying to select an appropriate vi= deo capture for display by examining the voice activity in all the audio ca= ptures in the room will result in showing the wrong video quite often. =C2= =A0This is based on practical interoperability experience with TIP.

It might be helpful if we first try to reach agreement = on the limitations of this kind of selection before we dive into the protoc= ol mechanics.[/SB]




In terms of whether an audio capture can relate to more than
one video capture yes I think so. You could have one audio capture for a room and three video captures.
More comments inline below.

Regards,
Mark

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@nteczone.com]
Sent: Sunday, April 13, 2014 11:18 PM
To: Duckworth, Mark; clu= e@ietf.org
Subject: Re: [clue] Improving treatment of audio

Hello Mark,

Sorry I didn't consider the entire 12.1.1. if I do that, according to that
example:

Video areas of capture:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bottom left =C2=A0 =C2=A0bottom right = =C2=A0top left =C2=A0 =C2=A0 =C2=A0 =C2=A0 top right
=C2=A0 =C2=A0 =C2=A0 VC0 (-2011,2850,0) (-673,3000,0) (-2011,2850,757) (-67= 3,3000,757)
=C2=A0 =C2=A0 =C2=A0 VC1 ( -673,3000,0) ( 673,3000,0) ( -673,3000,757) ( 67= 3,3000,757)
=C2=A0 =C2=A0 =C2=A0 VC2 ( =C2=A0673,3000,0) (2011,2850,0) ( =C2=A0673,3000= ,757) (2011,3000,757)
=C2=A0 =C2=A0 =C2=A0 VC3 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (201= 1,3000,757)
=C2=A0 =C2=A0 =C2=A0 VC4 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (201= 1,3000,757)
=C2=A0 =C2=A0 =C2=A0 VC5 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (201= 1,3000,757)
=C2=A0 =C2=A0 =C2=A0 VC6 none

Areas of capture for audio (from 12.1.1):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bottom left =C2=A0 =C2=A0bottom right = =C2=A0top left =C2=A0 =C2=A0 =C2=A0 =C2=A0 top right

=C2=A0 =C2=A0 =C2=A0 AC0 (-2011,2850,0) (-673,3000,0) (-2011,2850,757) (-67= 3,3000,757)
=C2=A0 =C2=A0 =C2=A0 AC1 ( =C2=A0673,3000,0) (2011,2850,0) ( =C2=A0673,3000= ,757) (2011,3000,757)
=C2=A0 =C2=A0 =C2=A0 AC2 ( -673,3000,0) ( 673,3000,0) ( -673,3000,757) ( 67= 3,3000,757)
=C2=A0 =C2=A0 =C2=A0 AC3 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (201= 1,3000,757)
=C2=A0 =C2=A0 =C2=A0 AC4 none

Using a reference rather than area of capture:
=C2=A0 =C2=A0 =C2=A0 =C2=A0AC0 (VC0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0AC1 (VC2)
=C2=A0 =C2=A0 =C2=A0 =C2=A0AC2 (VC1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0AC3 (VC3,VC4,VC5)
I would think they are basically conveying the same information???
[Duckworth, Mark] Looking from the consumer point of view, in trying to
understand the advertisement, what does the consumer know from the
advertisement? =C2=A0Suppose the consumer wants to get all three of VC0, VC= 1,
VC2, but it only wants a single audio capture. =C2=A0It should probably ask= for AC3,
but according to the advertisement AC3 doesn't "relate to" VC= 0, VC1, or VC2.
[CNG] I agree. If the provider wanted to indicate that AC3 could also be us= ed
for VC0,VC1,VC2 it could advertise:
=C2=A0 =C2=A0 =C2=A0 =C2=A0AC0 (VC0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0AC1 (VC2)
=C2=A0 =C2=A0 =C2=A0 =C2=A0AC2 (VC1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0AC3 (VC0,VC1,VC2,VC3,VC4,VC5)
[Duckworth, Mark] I agree that =C2=A0AC3 (the whole room audio) "relat= es to" all those video captures. =C2=A0But earlier you said "the = audio comes from the same 'region' as what the video capture does.&= quot; =C2=A0So now do we have to modify that to say something like "th= e audio comes from the same region as the video, or a subset of that region= , or a superset, or an overlapping region"? =C2=A0In this example, AC3= covers a region that is a superset of the VC0 region, a superset of the VC= 1 region, and a superset of the VC2 region.
[CNG] I was trying to illustrate the concept when I used the term "reg= ion". I didn't mean for that to relate to a specific area. I prefe= r "relates to" because that is essentially I'm trying specify= . For the purposes of capture selection you could specify the relation in t= erms of a mathematical area or you can simply say the captures are related.=



[Duckworth, Mark] For a case with a different consumer, suppose the
consumer wants the single video capture VC5, but it would like to receive and render spatial audio. =C2=A0There is no audio capture with multiple cha= nnels,
so it could ask for AC0, AC1, and AC2 if it knew how they were spatially "related to" VC5. =C2=A0But according to the advertisement, AC0, = AC1 and AC2
aren't "related to" VC5 at all.
[CNG] So in this case there is no AC3? In that case the advertisement could=
look like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0AC0 (VC0,VC5)
=C2=A0 =C2=A0 =C2=A0 =C2=A0AC1 (VC2,VC5)
=C2=A0 =C2=A0 =C2=A0 =C2=A0AC2 (VC1,VC5)
[Duckworth, Mark] I didn't mean to remove AC3. =C2=A0That would still b= e there in this example. =C2=A0So now since the provider forms it's adv= ertisement without knowing what the consumer wants to do, the provider has = to give all this information:
=C2=A0 =C2=A0AC0 relates to (VC0, VC3, VC4, VC5)
=C2=A0 =C2=A0AC1 relates to (VC2, VC3, VC4, VC5)
=C2=A0 =C2=A0AC2 relates to (VC1, VC3, VC4, VC5)
=C2=A0 =C2=A0AC3 relates to (VC0, VC1, VC2, VC3, VC4, VC5)
[Duckworth, Mark] Does this information really help the consumer? =C2=A0I d= on't think it is any better than what we already have with area of capt= ure.
[CNG] Well it does say to the MC a number of things, for exmaple:
- if you're going to choose VC0 then either AC0 and AC3 would be the be= st choice.
- AC3 is the best choice if you want one audio capture as it relates to all= video captures.

My proposal was only duplicate what is supported by area of capture in term= s of relating audio and video captures for capture selection. The way the d= iscussion is going it seems that people are dubious about specifying captur= e area for audio. The proposal is trying to get around that.
Another option would be to indicate that the capture area when used for aud= io actually relates to a video capture region. However that seems to be con= fusing to people.


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

--047d7b5d2c30236d7d04f8548dc5-- From nobody Thu May 1 04:35: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 1E2891A88E8 for ; Thu, 1 May 2014 04:34:52 -0700 (PDT) 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_81=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 RJbEev5eDVbf for ; Thu, 1 May 2014 04:34:51 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCAF1A0764 for ; Thu, 1 May 2014 04:34:50 -0700 (PDT) Received: from ppp118-209-119-137.lns20.mel4.internode.on.net ([118.209.119.137]:59099 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WfpGH-0000FA-Pq; Thu, 01 May 2014 21:34:45 +1000 Message-ID: <53623151.3070904@nteczone.com> Date: Thu, 01 May 2014 21:34:41 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Botzko References: <533AF351.9050201@alum.mit.edu> <20140410222705.GW39240@verdi> <53475572.4040807@nteczone.com> <20140411150055.GE60844@verdi> <49E45C59CA48264997FEBFB29B6BC2D6215295A8AE@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D62409219636@CRPMBOXPRD07.polycom.com> <534B4303.7060707@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F07152B@CRPMBOXPRD08.polycom.com> <534B536B.8000205@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13D9B2@CRPMBOXPRD08.polycom.com> <535F0B3A.70808@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13DAE6@CRPMBOXPRD08.polycom.com> <5361C8EA.2060206@nteczone.com> In-Reply-To: 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/jwq_yet_LmQGZZA1LrDWC9MNzjU Cc: "clue@ietf.org" Subject: Re: [clue] Improving treatment of audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 11:34:52 -0000 Hello Stephen, Please see below. Regards, Christian On 1/05/2014 8:58 PM, Stephen Botzko wrote: > In-line > > > On Thu, May 1, 2014 at 12:09 AM, Christian Groves > > > wrote: > > Hello Mark, > > Please see my replies below. > > Regards, Christian > > > On 30/04/2014 11:28 PM, Duckworth, Mark wrote: > > Hi Christian, > Thanks for elaborating on the idea. I have some more > questions inline. > I see basically what you are trying to do, but I still think > it doesn't work in practice any better than what we already > have, as I explain below. > Mark > > -----Original Message----- > From: Christian Groves > [mailto:Christian.Groves@nteczone.com > ] > Sent: Monday, April 28, 2014 10:15 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] Improving treatment of audio > > Hello Mark, > > Please see below. > > Regards, Christian > > On 29/04/2014 11:36 AM, Duckworth, Mark wrote: > > Hi Christian, > I'm coming back to this message, because I'm trying to > understand your > > proposal. You proposed "in each audio capture we say what > VC it relates to." > What does this mean? What does it mean for an audio > capture to relate to a > video capture? What exactly is the producer telling the > consumer? Can an > audio capture relate to more than one video capture? > [CNG] The meaning has largely the same semantic as if the > ADV used the > same capture area on a VC and AC. Basically its saying > that the audio comes > from the same "region" as what the video capture does. I > think the > difference is that its not trying to put a mathematical > certainty about what > that region is. Its a way for the producer to say to the > consumer if you choose > video capture A you probably want to choose audio capture > B for a good > experience. > > [Duckworth, Mark] If that is the meaning, then would it be > better for the provider to advertise a list of audio captures > that are "related to" each video capture? Rather than the > other way around? Maybe I'm not understanding the problem you > are trying to solve. > > [CNG] I don't think it matters the way it is defined. video > related to audio or audio related to video is essentially the same > thing. The problem I'm trying to solve is how does the media > consumer know which audio captures to choose when presented with a > list of captures. > > As I mentioned in an earlier email I think people where seeing the > "area of capture" in two separate ways. The first way was using > the area of capture to determine which video captures the audio > related to (i.e. capture selection). The second was concentrating > on how to use the area of capture information for audio rendering > (i.e. capture rendering). I'm focusing on the first, capture > selection. > > [SB] I am wondering if you are interested in static selection - based > on spatial information alone - or if you are more focused on dynamic > capture selection - finding the video of the current talker for instance. [CNG] I was thinking about a static selection. > Also, it might matter if you are trying to select video captures that > go along with audio captures, or the other way around. > > My view is that selecting a subset of the audio captures in the room > for rendering or distribution will likely result in bad audio much of > the time - unless the sending system has expressly designed its audio > pickup and seating arrangements to enable that. And a lot of systems > won't be designed to allow it. I don't think it will be all that easy > to detect that from details of the pickup pattern of each microphone > or capture information. The general acoustics of the room also play > into it, and I think the seating arrangement does also. > > It is possible that senders will create alternative sets of audio > captures - for instance,a set of spatial audio captures that together > provide full room pickup, and a single downmixed monophonic channel > that also covers the full room. Receivers obviously need to sort that > out, just like they do in the corresponding video case. [CNG] Its the aspect of alternate sets of audio captures that I was concentrating on. If a MP sends several audio captures and video captures AND we don't have audio capture area how does the MP figure out which audio to select? > > My view is also that trying to select an appropriate video capture for > display by examining the voice activity in all the audio captures in > the room will result in showing the wrong video quite often. This is > based on practical interoperability experience with TIP. > > It might be helpful if we first try to reach agreement on the > limitations of this kind of selection before we dive into the protocol > mechanics.[/SB] > > > From nobody Thu May 1 04:39:36 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69B21A6F3B for ; Thu, 1 May 2014 04:39:12 -0700 (PDT) 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 gxM7gJizKDWJ for ; Thu, 1 May 2014 04:39:11 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0A30C1A0764 for ; Thu, 1 May 2014 04:39:10 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jy13so3670800veb.2 for ; Thu, 01 May 2014 04:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/BMJJZgcVfRq+hZYS56fLrSxKZRnjk+1PRorI2VQLbs=; b=Wl98OuqZVc/JJE9hBM5lKbir1ZuBbJq1Mo7IrvJhpAhZX+Lw5fQJ111Mk4Mix2WIVD o0PwvKX5xsRTql8PAldGMBQitmfJ9jnu0yPiDcP2R1RG/XK7wqFrsuKIlD+lBJ6fJdVU U9tXljPI0YJR7lnfKU66Xa0vFZhxija1hVKxOv3vm7lSqWCFLB50syEVwJ8xzNa+koFV jGHMecc7KEV+TJPH+9/OWApAZ/T/m7EodHSwHm+PkwUp+fz9ibn0322lZXKzBnSCpe9s wQd/ZuKV9ZAf2Bz8pxY27Jlq3KdGJVuFUJO+VSai8HHHXVglJ4FFVemh7RN/GUcdVeZp dFSA== MIME-Version: 1.0 X-Received: by 10.52.123.39 with SMTP id lx7mr7214641vdb.22.1398944348974; Thu, 01 May 2014 04:39:08 -0700 (PDT) Received: by 10.221.40.135 with HTTP; Thu, 1 May 2014 04:39:08 -0700 (PDT) In-Reply-To: <5361BA1C.7030509@nteczone.com> References: <5361BA1C.7030509@nteczone.com> Date: Thu, 1 May 2014 07:39:08 -0400 Message-ID: From: Stephen Botzko To: Christian Groves Content-Type: multipart/alternative; boundary=bcaec51dd2abfb327204f8551c0b Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZHvlpUQdfkAd2vIP7dIwLwuZZK8 Cc: "clue@ietf.org" Subject: Re: [clue] Taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 11:39:12 -0000 --bcaec51dd2abfb327204f8551c0b Content-Type: text/plain; charset=UTF-8 Precision, clarity, and consistency are of course is good ideas. The use cases were just published, and that RFC uses "participant" consistently to mean "person".and "site" to mean room/location. I don't think anyone will think that "participants" in that RFC are using the RFC4353 definition. If someone did, that would have surfaced in the IETF last call, AD reviews, etc. It didn't. The requirements document is just entering the editors queue, and uses "participant" exactly once (in the definition of endpoint). That use cross-references RFC4353. It consistently uses "users" to describe people. I propose that we not re-publish the existing RFC, and also that we leave the requirements document usage as it is. I guess we could use AUTH48 to revise "user" usage, but only if we close on the terminology very quickly. Also, I agree that we ought to make sure that the remaining documents are aligned on these basic terms, and that those terms are also used consistently with existing RFCs as much as possible. "Person information" just doesn't sound right to me though. "User Information" and "Participant Information" simply sound better. Perhaps that is because I speak American, and not English? Stephen Botzko On Wed, Apr 30, 2014 at 11:06 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello all, > > At the London meeting it was mentioned there is a potential conflict in > the way that CLUE uses some of the terminology from the RTP taxonomy draft > (draft-ietf-avtext-rtp-grouping-taxonomy). > > I think this mainly relates to the use of the term "Participant". > > In cl.2.2.3 of the taxonomy draft there is a definition for the term > "participant": > /"A participant is an entity reachable by a single signaling address,// > // and is thus related more to the signaling context than to the media// > // context." > > /In the XCON data model cl.4.6.5/[RFC6501] it uses the term "user" to > describe the concept outlined in the draft definition. RFC4575 also uses > the term "user" for this. > > In CLUE we use participant as per the definition above (i.e. in the > definition of Endpoint and MCU) but we also use "participant" to mean > someone captured by the endpoint, i.e. the people in the room. > > In order to minimise any confusion between the two uses I propose that we > change the later use to "person" in our documents. > > For example: in the framework: > - "Participant Information" becomes "Person Information", > - "participant type" becomes "person type". > - Where "participant" is used in the text it becomes "person" or "people". > i.e. Table - Captures the conference table with seated people. > Individual - Captures an individual person. > > > Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec51dd2abfb327204f8551c0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Precision, clarity, and consistency are of course is good = ideas.

The use cases were just published, and that RFC u= ses "participant" consistently to mean "person".and &qu= ot;site" to mean room/location. =C2=A0I don't think anyone will th= ink that "participants" in that RFC are using the RFC4353 definit= ion. =C2=A0 If someone did, that would have surfaced in the IETF last call,= AD reviews, etc. =C2=A0It didn't. =C2=A0

The requirements document is just entering the editors = queue, and uses "participant" exactly once (in the definition of = endpoint). =C2=A0That use cross-references=C2=A0RFC4353. =C2=A0It consistently uses = "users" to describe people.

=
I propose that we not re-publish the existing RFC, and also that w= e leave the requirements document usage as it is. =C2=A0I guess we could us= e AUTH48 to revise "user" usage, but only if we close on the term= inology very quickly. =C2=A0

=
Also, I agree that we ought to make sure that the remaining docume= nts are aligned on these basic terms, and that those terms are also used co= nsistently with existing RFCs as much as possible.

=
"Person information" just doesn't sound right to me = though. =C2=A0"User Information" and "Participant Informatio= n" simply sound better. Perhaps that is because I speak American, and = not English? =C2=A0

=
Stephen Botzko


<= /div>


On Wed,= Apr 30, 2014 at 11:06 PM, Christian Groves <Christian.Grove= s@nteczone.com> wrote:
Hello all,

At the London meeting it was mentioned there is a potential conflict in the= way that CLUE uses some of the terminology from the RTP taxonomy draft (dr= aft-ietf-avtext-rtp-grouping-taxonomy).

I think this mainly relates to the use of the term "Participant".=

In cl.2.2.3 of the taxonomy draft there is a definition for the term "= participant":
/"A participant is an entity reachable by a single signaling address,/= /
// =C2=A0 and is thus related more to the signaling context than to the med= ia//
// =C2=A0 context."

/In the XCON data model cl.4.6.5/[RFC6501] it uses the term "user"= ; to describe the concept outlined in the draft definition. RFC4575 also us= es the term "user" for this.

In CLUE we use participant as per the definition above (i.e. in the definit= ion of Endpoint and MCU) but we also use "participant" to mean so= meone captured by the endpoint, i.e. the people in the room.

In order to minimise any confusion between the two uses I propose that we c= hange the later use to "person" in our documents.

For example: in the framework:
- "Participant Information" becomes "Person Information"= ;,
- "participant type" becomes "person type".
- Where "participant" is used in the text it becomes "person= " or "people".
=C2=A0 i.e. =C2=A0 Table - Captures the conference table with seated people= .
=C2=A0 =C2=A0 Individual - Captures an individual person.


Christian

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

--bcaec51dd2abfb327204f8551c0b-- From nobody Thu May 1 04:57: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 E94211A88E4 for ; Thu, 1 May 2014 04:56:55 -0700 (PDT) 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 r8UoDX6k155V for ; Thu, 1 May 2014 04:56:54 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1891A0764 for ; Thu, 1 May 2014 04:56:54 -0700 (PDT) Received: from ppp118-209-119-137.lns20.mel4.internode.on.net ([118.209.119.137]:59359 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wfpbd-0002xG-Q2; Thu, 01 May 2014 21:56:49 +1000 Message-ID: <5362367D.1050509@nteczone.com> Date: Thu, 01 May 2014 21:56:45 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Botzko References: <5361BA1C.7030509@nteczone.com> In-Reply-To: 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/NAJWg0blt90aod8tGCnoM6HCGds Cc: "clue@ietf.org" Subject: Re: [clue] Taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 11:56:56 -0000 Hello Stephen, Please see below. Regards, Christian On 1/05/2014 9:39 PM, Stephen Botzko wrote: > Precision, clarity, and consistency are of course is good ideas. > > The use cases were just published, and that RFC uses "participant" > consistently to mean "person".and "site" to mean room/location. I > don't think anyone will think that "participants" in that RFC are > using the RFC4353 definition. If someone did, that would have surfaced > in the IETF last call, AD reviews, etc. It didn't. [CNG] It didn't come up during review but it did come up in London that we should check the CLUE work against the taxonomy. > > The requirements document is just entering the editors queue, and uses > "participant" exactly once (in the definition of endpoint). That use > cross-references RFC4353. It consistently uses "users" to describe > people. > > I propose that we not re-publish the existing RFC, and also that we > leave the requirements document usage as it is. I guess we could use > AUTH48 to revise "user" usage, but only if we close on the terminology > very quickly. [CNG] I thinking to re-open the existing RFC or those in the RFC queue. Its not worth the effort to update those as they're largely informative and this isn't a big issue. > > Also, I agree that we ought to make sure that the remaining documents > are aligned on these basic terms, and that those terms are also used > consistently with existing RFCs as much as possible. > > "Person information" just doesn't sound right to me though. "User > Information" and "Participant Information" simply sound better. > Perhaps that is because I speak American, and not English? [CNG] I'm not particularly fond of "Person Information" either but I was trying to use "participant" or "user" which already have a definition in the XCON model. I'm just thinking forward and if we do eventually update XCON to include some information related to clue it would seem strange to have a hierarchy: Users->User->Endpoint->"capture"->participant when RFC6501 talks about User=Participant. > > Stephen Botzko > > > > > On Wed, Apr 30, 2014 at 11:06 PM, Christian Groves > > > wrote: > > Hello all, > > At the London meeting it was mentioned there is a potential > conflict in the way that CLUE uses some of the terminology from > the RTP taxonomy draft (draft-ietf-avtext-rtp-grouping-taxonomy). > > I think this mainly relates to the use of the term "Participant". > > In cl.2.2.3 of the taxonomy draft there is a definition for the > term "participant": > /"A participant is an entity reachable by a single signaling > address,// > // and is thus related more to the signaling context than to the > media// > // context." > > /In the XCON data model cl.4.6.5/[RFC6501] it uses the term "user" > to describe the concept outlined in the draft definition. RFC4575 > also uses the term "user" for this. > > In CLUE we use participant as per the definition above (i.e. in > the definition of Endpoint and MCU) but we also use "participant" > to mean someone captured by the endpoint, i.e. the people in the room. > > In order to minimise any confusion between the two uses I propose > that we change the later use to "person" in our documents. > > For example: in the framework: > - "Participant Information" becomes "Person Information", > - "participant type" becomes "person type". > - Where "participant" is used in the text it becomes "person" or > "people". > i.e. Table - Captures the conference table with seated people. > Individual - Captures an individual person. > > > Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From nobody Thu May 1 04:58: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 A4A691A88E8 for ; Thu, 1 May 2014 04:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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_81=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 KGoqgXBdTWzq for ; Thu, 1 May 2014 04:58:17 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7871A88E4 for ; Thu, 1 May 2014 04:58:17 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id pa12so2725852veb.40 for ; Thu, 01 May 2014 04:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h50pieSktMOPeFaLjTQ65WOg6IhuTmtc1Lx8xxwRatI=; b=r6YNmOJeesRK7BHDWHF9R7SK/lpr2fJb+UZGE/GyVmLe0XehSI0AJ/z7U6Ts3kRwfc TOYzzSVF0v0W6fIzgV3/DmfNbnx430AOxaYuWrBipugswOCAwzkuf6CIy0MrKSCC8zJf OWvblpDFV8AeluZMpzRrWmDaD3ckUROpJiNsrKmMSbuxRWgy7YU6vdXtYeTCLwBy0mXa //auAUQfYO2fqtYHSHEQE05o7iku6fM2sR2EISXebsxKLcZ+vNJMYojbm4ytwsYGDIIG gXZpJYOcJwvgwpBWupcgddG3R7RGhoQZN2ES3EnGTokOfmloHM7Fu1K1GzKW15XBXvSP 8jsQ== MIME-Version: 1.0 X-Received: by 10.58.46.207 with SMTP id x15mr8923154vem.17.1398945495470; Thu, 01 May 2014 04:58:15 -0700 (PDT) Received: by 10.221.40.135 with HTTP; Thu, 1 May 2014 04:58:15 -0700 (PDT) In-Reply-To: <53623151.3070904@nteczone.com> References: <533AF351.9050201@alum.mit.edu> <20140410222705.GW39240@verdi> <53475572.4040807@nteczone.com> <20140411150055.GE60844@verdi> <49E45C59CA48264997FEBFB29B6BC2D6215295A8AE@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D62409219636@CRPMBOXPRD07.polycom.com> <534B4303.7060707@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F07152B@CRPMBOXPRD08.polycom.com> <534B536B.8000205@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13D9B2@CRPMBOXPRD08.polycom.com> <535F0B3A.70808@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13DAE6@CRPMBOXPRD08.polycom.com> <5361C8EA.2060206@nteczone.com> <53623151.3070904@nteczone.com> Date: Thu, 1 May 2014 07:58:15 -0400 Message-ID: From: Stephen Botzko To: Christian Groves Content-Type: multipart/alternative; boundary=089e013a18c251592404f85561e1 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/teF_k3pRI8Nf0S3h4RtOBNovY6Q Cc: "clue@ietf.org" Subject: Re: [clue] Improving treatment of audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 11:58:19 -0000 --089e013a18c251592404f85561e1 Content-Type: text/plain; charset=UTF-8 inline On Thu, May 1, 2014 at 7:34 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Stephen, > > > Please see below. > > Regards, Christian > > On 1/05/2014 8:58 PM, Stephen Botzko wrote: > >> In-line >> >> >> >> On Thu, May 1, 2014 at 12:09 AM, Christian Groves < >> Christian.Groves@nteczone.com > >> wrote: >> >> Hello Mark, >> >> Please see my replies below. >> >> Regards, Christian >> >> >> On 30/04/2014 11:28 PM, Duckworth, Mark wrote: >> >> Hi Christian, >> Thanks for elaborating on the idea. I have some more >> questions inline. >> I see basically what you are trying to do, but I still think >> it doesn't work in practice any better than what we already >> have, as I explain below. >> Mark >> >> -----Original Message----- >> From: Christian Groves >> [mailto:Christian.Groves@nteczone.com >> ] >> Sent: Monday, April 28, 2014 10:15 PM >> To: Duckworth, Mark; clue@ietf.org >> Subject: Re: [clue] Improving treatment of audio >> >> Hello Mark, >> >> Please see below. >> >> Regards, Christian >> >> On 29/04/2014 11:36 AM, Duckworth, Mark wrote: >> >> Hi Christian, >> I'm coming back to this message, because I'm trying to >> understand your >> >> proposal. You proposed "in each audio capture we say what >> VC it relates to." >> What does this mean? What does it mean for an audio >> capture to relate to a >> video capture? What exactly is the producer telling the >> consumer? Can an >> audio capture relate to more than one video capture? >> [CNG] The meaning has largely the same semantic as if the >> ADV used the >> same capture area on a VC and AC. Basically its saying >> that the audio comes >> from the same "region" as what the video capture does. I >> think the >> difference is that its not trying to put a mathematical >> certainty about what >> that region is. Its a way for the producer to say to the >> consumer if you choose >> video capture A you probably want to choose audio capture >> B for a good >> experience. >> >> [Duckworth, Mark] If that is the meaning, then would it be >> better for the provider to advertise a list of audio captures >> that are "related to" each video capture? Rather than the >> other way around? Maybe I'm not understanding the problem you >> are trying to solve. >> >> [CNG] I don't think it matters the way it is defined. video >> related to audio or audio related to video is essentially the same >> thing. The problem I'm trying to solve is how does the media >> consumer know which audio captures to choose when presented with a >> list of captures. >> >> As I mentioned in an earlier email I think people where seeing the >> "area of capture" in two separate ways. The first way was using >> the area of capture to determine which video captures the audio >> related to (i.e. capture selection). The second was concentrating >> on how to use the area of capture information for audio rendering >> (i.e. capture rendering). I'm focusing on the first, capture >> selection. >> >> [SB] I am wondering if you are interested in static selection - based on >> spatial information alone - or if you are more focused on dynamic capture >> selection - finding the video of the current talker for instance. >> > [CNG] I was thinking about a static selection. > > Also, it might matter if you are trying to select video captures that go >> along with audio captures, or the other way around. >> >> My view is that selecting a subset of the audio captures in the room for >> rendering or distribution will likely result in bad audio much of the time >> - unless the sending system has expressly designed its audio pickup and >> seating arrangements to enable that. And a lot of systems won't be designed >> to allow it. I don't think it will be all that easy to detect that from >> details of the pickup pattern of each microphone or capture information. >> The general acoustics of the room also play into it, and I think the >> seating arrangement does also. >> >> It is possible that senders will create alternative sets of audio >> captures - for instance,a set of spatial audio captures that together >> provide full room pickup, and a single downmixed monophonic channel that >> also covers the full room. Receivers obviously need to sort that out, just >> like they do in the corresponding video case. >> > [CNG] Its the aspect of alternate sets of audio captures that I was > concentrating on. If a MP sends several audio captures and video captures > AND we don't have audio capture area how does the MP figure out which audio > to select? > > ]SB} I agree that we need to ensure that alternate sets of audio captures of the room can be advertised and distinguished. I think it is quite likely that systems will include an alternate monophonic capture of the entire room at least. Taking individual audio captures from different alternate sets and attempting to render them together will certainly result in bad audio.. The group may disagree on the value of taking a subset of the full room audio, but I think the need to distinguish alternate sets of audio captures is something we can agree on. > > >> My view is also that trying to select an appropriate video capture for >> display by examining the voice activity in all the audio captures in the >> room will result in showing the wrong video quite often. This is based on >> practical interoperability experience with TIP. >> >> It might be helpful if we first try to reach agreement on the limitations >> of this kind of selection before we dive into the protocol mechanics.[/SB] >> >> >> >> > --089e013a18c251592404f85561e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
inline


On Thu, May 1, 2014 at 7:34 AM, Christian Groves <Christian.Groves@nteczone.com> wrote:
Hello Stephen,


Please see below.

Regards, Christian

On 1/05/2014 8:58 PM, Stephen Botzko wrote:
In-line



On Thu, May 1, 2014 at 12:09 AM, Christian Groves <Christian.Groves@nteczone.com= <mailto:Christian.Groves@nteczone.com>> wrote:

=C2=A0 =C2=A0 Hello Mark,

=C2=A0 =C2=A0 Please see my replies below.

=C2=A0 =C2=A0 Regards, Christian


=C2=A0 =C2=A0 On 30/04/2014 11:28 PM, Duckworth, Mark wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Christian,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks for elaborating on the idea. =C2=A0I hav= e some more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 questions inline.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I see basically what you are trying to do, but = I still think
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it doesn't work in practice any better than= what we already
=C2=A0 =C2=A0 =C2=A0 =C2=A0 have, as I explain below.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mark

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Christian Groves
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [mailto:Christian.Groves@nteczone.= com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:Christian.Groves@nteczo= ne.com>]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: Monday, April 28, 2014 10:1= 5 PM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Duckworth, Mark; clue@ietf.org <mailto:clue@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [clue] Improving tre= atment of audio

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hello Mark,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Please see below.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards, Christian

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 29/04/2014 11:36 AM, Duckworth= , Mark wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Christian,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I'm coming back= to this message, because I'm trying to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 understand your

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 proposal. =C2=A0You proposed &quo= t;in each audio capture we say what
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VC it relates to."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 What does this mean? =C2=A0What d= oes it mean for an audio
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 capture to relate to a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 video capture? =C2=A0What exactly= is the producer telling the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consumer? =C2=A0Can an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 audio capture relate to more than= one video capture?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [CNG] The meaning has largely the= same semantic as if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ADV used the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 same capture area on a VC and AC.= Basically its saying
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that the audio comes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from the same "region" = as what the video capture does. I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 think the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 difference is that its not trying= to put a mathematical
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 certainty about what
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that region is. Its a way for the= producer to say to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consumer if you choose
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 video capture A you probably want= to choose audio capture
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 B for a good
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 experience.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [Duckworth, Mark] If that is the meaning, then = would it be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 better for the provider to advertise a list of = audio captures
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that are "related to" each video capt= ure? =C2=A0Rather than the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other way around? =C2=A0Maybe I'm not under= standing the problem you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are trying to solve.

=C2=A0 =C2=A0 [CNG] I don't think it matters the way it is defined. vid= eo
=C2=A0 =C2=A0 related to audio or audio related to video is essentially the= same
=C2=A0 =C2=A0 thing. The problem I'm trying to solve is how does the me= dia
=C2=A0 =C2=A0 consumer know which audio captures to choose when presented w= ith a
=C2=A0 =C2=A0 list of captures.

=C2=A0 =C2=A0 As I mentioned in an earlier email I think people where seein= g the
=C2=A0 =C2=A0 "area of capture" in two separate ways. The first w= ay was using
=C2=A0 =C2=A0 the area of capture to determine which video captures the aud= io
=C2=A0 =C2=A0 related to (i.e. capture selection). The second was concentra= ting
=C2=A0 =C2=A0 on how to use the area of capture information for audio rende= ring
=C2=A0 =C2=A0 (i.e. capture rendering). I'm focusing on the first, capt= ure
=C2=A0 =C2=A0 selection.

[SB] I am wondering if you are interested in static selection - based on sp= atial information alone - or if you are more focused on dynamic capture sel= ection - finding the video of the current talker for instance.
[CNG] I was thinking about a static selection.=C2=A0


Also, it might matter if you are trying to select video captures that go al= ong with audio captures, or the other way around.

My view is that selecting a subset of the audio captures in the room for re= ndering or distribution will likely result in bad audio much of the time - = unless the sending system has expressly designed its audio pickup and seati= ng arrangements to enable that. And a lot of systems won't be designed = to allow it. I don't think it will be all that easy to detect that from= details of the pickup pattern of each microphone or capture information. = =C2=A0The general acoustics of the room also play into it, and I think the = seating arrangement does also.

It is possible that senders will create alternative sets of audio captures = - for instance,a set of spatial audio captures that together provide full r= oom pickup, and a single downmixed monophonic channel that also covers the = full room. =C2=A0Receivers obviously need to sort that out, just like they = do in the corresponding video case.
[CNG] Its the aspect of alternate sets of audio captures that I was concent= rating on. If a MP sends several audio captures and video captures AND we d= on't have audio capture area how does the MP figure out which audio to = select?

]SB} I agree that we ne= ed to ensure that alternate sets of audio captures of the room can be adver= tised and distinguished. =C2=A0I think it is quite likely that systems will= include an alternate monophonic capture of the entire room at least. =C2= =A0Taking individual audio captures from different alternate sets and attem= pting to render them together will certainly result in bad audio..

The group may disagree on the value of taking a subset = of the full room audio, but I think the need to distinguish alternate sets = of audio captures is something we can agree on.


My view is also that trying to select an appropriate video capture for disp= lay by examining the voice activity in all the audio captures in the room w= ill result in showing the wrong video quite often. =C2=A0This is based on p= ractical interoperability experience with TIP.

It might be helpful if we first try to reach agreement on the limitations o= f this kind of selection before we dive into the protocol mechanics.[/SB]




--089e013a18c251592404f85561e1-- From nobody Thu May 1 05:09:58 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011E01A6F49 for ; Thu, 1 May 2014 05:09:18 -0700 (PDT) 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 n-RjA7hIMiTc for ; Thu, 1 May 2014 05:09:16 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B03161A0764 for ; Thu, 1 May 2014 05:09:15 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hr9so3858027vcb.29 for ; Thu, 01 May 2014 05:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3xuTFPHTmSv+XSdx1pwDfv1t+igS1Z6g74LcTtNfSNY=; b=OuqIMe5PR9Ls9X/lf2jyyItn+tSNe8t9LAcV9did5nMRhP4iiPszVsEly5J8P9bVLo ohn3dnt3TolvXf+loJft7sLwJurN5W2rBjDV7hSODIjqY1lB8iEwzxZ6rPG7V+S+1TKy shRYpkcN+1qrBO/E24b8A9Yq3+VirYGICLqFqn5HXbUo74Dj/oDIR8wnhc5Aqg1Vk1TP ty+eDOxdcPVeyh5svmjxnh2qg7EjG81RK0RKa9MZJcUMAaGo8ThIPGMxbL16BQZdZEj+ iRwCGgZif9+K6VhIg67+Nnyr8CXIMlojKp7IaKBbo0Ihr73SWhAR3u90O0nlRSvrsSnk oPGA== MIME-Version: 1.0 X-Received: by 10.58.126.4 with SMTP id mu4mr8946345veb.0.1398946153653; Thu, 01 May 2014 05:09:13 -0700 (PDT) Received: by 10.221.40.135 with HTTP; Thu, 1 May 2014 05:09:13 -0700 (PDT) In-Reply-To: <5362367D.1050509@nteczone.com> References: <5361BA1C.7030509@nteczone.com> <5362367D.1050509@nteczone.com> Date: Thu, 1 May 2014 08:09:13 -0400 Message-ID: From: Stephen Botzko To: Christian Groves Content-Type: multipart/alternative; boundary=047d7b6700af8c6b4e04f855881b Archived-At: http://mailarchive.ietf.org/arch/msg/clue/PQ0xcPYekg1LD_JKLWCTiyyorQs Cc: "clue@ietf.org" Subject: Re: [clue] Taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 12:09:18 -0000 --047d7b6700af8c6b4e04f855881b Content-Type: text/plain; charset=UTF-8 in-line On Thu, May 1, 2014 at 7:56 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Stephen, > > Please see below. > > Regards, Christian > > > On 1/05/2014 9:39 PM, Stephen Botzko wrote: > >> Precision, clarity, and consistency are of course is good ideas. >> >> The use cases were just published, and that RFC uses "participant" >> consistently to mean "person".and "site" to mean room/location. I don't >> think anyone will think that "participants" in that RFC are using the >> RFC4353 definition. If someone did, that would have surfaced in the IETF >> last call, AD reviews, etc. It didn't. >> > [CNG] It didn't come up during review but it did come up in London that we > should check the CLUE work against the taxonomy. [SB] As you know I wasn't there, but I agree that is a good idea. > > >> The requirements document is just entering the editors queue, and uses >> "participant" exactly once (in the definition of endpoint). That use >> cross-references RFC4353. It consistently uses "users" to describe people. >> >> I propose that we not re-publish the existing RFC, and also that we leave >> the requirements document usage as it is. I guess we could use AUTH48 to >> revise "user" usage, but only if we close on the terminology very quickly. >> > [CNG] I thinking to re-open the existing RFC or those in the RFC queue. > Its not worth the effort to update those as they're largely informative and > this isn't a big issue. > > [SB]That will certainly make resolving this simpler. > >> Also, I agree that we ought to make sure that the remaining documents are >> aligned on these basic terms, and that those terms are also used >> consistently with existing RFCs as much as possible. >> >> "Person information" just doesn't sound right to me though. "User >> Information" and "Participant Information" simply sound better. Perhaps >> that is because I speak American, and not English? >> > [CNG] I'm not particularly fond of "Person Information" either but I was > trying to use "participant" or "user" which already have a definition in > the XCON model. I'm just thinking forward and if we do eventually update > XCON to include some information related to clue it would seem strange to > have a hierarchy: > Users->User->Endpoint->"capture"->participant > > when RFC6501 talks about User=Participant. [SB] I'm glad to know its not just me who finds "Person information" a bit off.. Maybe someone can think of a term that reads better. To some degree, we are constrained because previous RFCs needlessly took an anthropomorphic approach when describing equipment. IMO that should have been easily been avoided back then, but that ship has sailed. > > >> Stephen Botzko >> >> >> >> >> >> On Wed, Apr 30, 2014 at 11:06 PM, Christian Groves < >> Christian.Groves@nteczone.com > >> wrote: >> >> Hello all, >> >> At the London meeting it was mentioned there is a potential >> conflict in the way that CLUE uses some of the terminology from >> the RTP taxonomy draft (draft-ietf-avtext-rtp-grouping-taxonomy). >> >> I think this mainly relates to the use of the term "Participant". >> >> In cl.2.2.3 of the taxonomy draft there is a definition for the >> term "participant": >> /"A participant is an entity reachable by a single signaling >> address,// >> // and is thus related more to the signaling context than to the >> media// >> // context." >> >> /In the XCON data model cl.4.6.5/[RFC6501] it uses the term "user" >> to describe the concept outlined in the draft definition. RFC4575 >> also uses the term "user" for this. >> >> In CLUE we use participant as per the definition above (i.e. in >> the definition of Endpoint and MCU) but we also use "participant" >> to mean someone captured by the endpoint, i.e. the people in the room. >> >> In order to minimise any confusion between the two uses I propose >> that we change the later use to "person" in our documents. >> >> For example: in the framework: >> - "Participant Information" becomes "Person Information", >> - "participant type" becomes "person type". >> - Where "participant" is used in the text it becomes "person" or >> "people". >> i.e. Table - Captures the conference table with seated people. >> Individual - Captures an individual person. >> >> >> Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> > --047d7b6700af8c6b4e04f855881b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
in-line


On Thu, May 1, 2014 at 7:56 AM, Christian Groves <Christian.Groves@nteczone.com> wrote:
Hello Stephen,

Please see below.

Regards, Christian


On 1/05/2014 9:39 PM, Stephen Botzko wrote:
Precision, clarity, and consistency are of course is good ideas.

The use cases were just published, and that RFC uses "participant"= ; consistently to mean "person".and "site" to mean room= /location. =C2=A0I don't think anyone will think that "participant= s" in that RFC are using the RFC4353 definition. If someone did, that = would have surfaced in the IETF last call, AD reviews, etc. =C2=A0It didn&#= 39;t.
[CNG] It didn't come up during review but it did come up in London that= we should check the CLUE work against the taxonomy.
[SB] = As you know I wasn't there, but I agree that is a good idea.=C2=A0


The requirements document is just entering the editors queue, and uses &quo= t;participant" exactly once (in the definition of endpoint). =C2=A0Tha= t use cross-references RFC4353. =C2=A0It consistently uses "users"= ; to describe people.

I propose that we not re-publish the existing RFC, and also that we leave t= he requirements document usage as it is. =C2=A0I guess we could use AUTH48 = to revise "user" usage, but only if we close on the terminology v= ery quickly.
[CNG] I thinking to re-open the existing RFC or those in the RFC queue. Its= not worth the effort to update those as they're largely informative an= d this isn't a big issue.

[SB]That will certainly make resolving this simpler.=C2=A0

Also, I agree that we ought to make sure that the remaining documents are a= ligned on these basic terms, and that those terms are also used consistentl= y with existing RFCs as much as possible.

"Person information" just doesn't sound right to me though. = =C2=A0"User Information" and "Participant Information" = simply sound better. Perhaps that is because I speak American, and not Engl= ish?
[CNG] I'm not particularly fond of "Person Information" eithe= r but I was trying to use "participant" or "user" which= already have a definition in the XCON model. I'm just thinking forward= and if we do eventually update XCON to include some information related to= clue it would seem strange to have a hierarchy:=C2=A0

Users->User->Endpoint->"capture"->participant<= br>
when RFC6501 talks about User=3DParticipant.=C2=A0
[SB] I&= #39;m glad to know its not just me who finds "Person information"= a bit off.. =C2=A0Maybe someone can think of a term that reads better. =C2= =A0To some degree, we are constrained because previous RFCs needlessly took= an anthropomorphic approach when describing equipment. =C2=A0IMO that shou= ld have been easily been avoided back then, but that ship has sailed.


Stephen Botzko





On Wed, Apr 30, 2014 at 11:06 PM, Christian Groves <Christian.Groves@nteczone.co= m <mailto:Christian.Groves@nteczone.com>> wrote:

=C2=A0 =C2=A0 Hello all,

=C2=A0 =C2=A0 At the London meeting it was mentioned there is a potential =C2=A0 =C2=A0 conflict in the way that CLUE uses some of the terminology fr= om
=C2=A0 =C2=A0 the RTP taxonomy draft (draft-ietf-avtext-rtp-grouping= -taxonomy).

=C2=A0 =C2=A0 I think this mainly relates to the use of the term "Part= icipant".

=C2=A0 =C2=A0 In cl.2.2.3 of the taxonomy draft there is a definition for t= he
=C2=A0 =C2=A0 term "participant":
=C2=A0 =C2=A0 /"A participant is an entity reachable by a single signa= ling
=C2=A0 =C2=A0 address,//
=C2=A0 =C2=A0 // =C2=A0 and is thus related more to the signaling context t= han to the
=C2=A0 =C2=A0 media//
=C2=A0 =C2=A0 // =C2=A0 context."

=C2=A0 =C2=A0 /In the XCON data model cl.4.6.5/[RFC6501] it uses the term &= quot;user"
=C2=A0 =C2=A0 to describe the concept outlined in the draft definition. RFC= 4575
=C2=A0 =C2=A0 also uses the term "user" for this.

=C2=A0 =C2=A0 In CLUE we use participant as per the definition above (i.e. = in
=C2=A0 =C2=A0 the definition of Endpoint and MCU) but we also use "par= ticipant"
=C2=A0 =C2=A0 to mean someone captured by the endpoint, i.e. the people in = the room.

=C2=A0 =C2=A0 In order to minimise any confusion between the two uses I pro= pose
=C2=A0 =C2=A0 that we change the later use to "person" in our doc= uments.

=C2=A0 =C2=A0 For example: in the framework:
=C2=A0 =C2=A0 - "Participant Information" becomes "Person In= formation",
=C2=A0 =C2=A0 - "participant type" becomes "person type"= ;.
=C2=A0 =C2=A0 - Where "participant" is used in the text it become= s "person" or
=C2=A0 =C2=A0 "people".
=C2=A0 =C2=A0 =C2=A0 i.e. =C2=A0 Table - Captures the conference table with= seated people.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual - Captures an individual person.


=C2=A0 =C2=A0 Christian

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 clue mailing list
=C2=A0 =C2=A0 clue@ietf.= org <mailto:clue@= ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/clue




--047d7b6700af8c6b4e04f855881b-- From nobody Thu May 1 08:47: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 EFACD1A6F7B for ; Thu, 1 May 2014 08:47:43 -0700 (PDT) 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 Wtgn0GSKf8ur for ; Thu, 1 May 2014 08:47:42 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 08C921A6F92 for ; Thu, 1 May 2014 08:47:40 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so2403911wes.23 for ; Thu, 01 May 2014 08:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=I5+Qb4bC8Hz2BU4XGjmbuA+NLhzjJAQPA89Abo0cUGk=; b=wSASZ8TLJqzVJV7YFy0th139nRTmq56nOSDhq/QcK4ppleu8VtAX8UQ+JdsfxQxfL8 DFTCHOf3vjVHwm3JerUTYbv2GSvEN7lOGV83JwKgyynEdbR99bVAc/g150UCRzgTY95g h0kKcBd+FNjectNfAM5N83nMG0JYAZkGxVFM105gchu3buZfg0SpVQb4z5RBnrIElf0C Ul8STOVdrAPj69k18WsoROv7rAYPT2bGZB3wq2K65c40pMffvPS9upDf0ZjfvIO3Tewx pwFHtFw0GEpV1lUsTexDR4CNiwQ5SOEXO0w7O1u0YqpFncNpblUD/LdcioCsH+GQGTOj HgZQ== MIME-Version: 1.0 X-Received: by 10.180.90.79 with SMTP id bu15mr2777467wib.38.1398959258668; Thu, 01 May 2014 08:47:38 -0700 (PDT) Received: by 10.216.93.68 with HTTP; Thu, 1 May 2014 08:47:38 -0700 (PDT) In-Reply-To: <20140430193810.6483.37869.idtracker@ietfa.amsl.com> References: <20140430193810.6483.37869.idtracker@ietfa.amsl.com> Date: Thu, 1 May 2014 10:47:38 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d043c092eab183b04f85895e4 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/gkwDxFtll5wlaOLxdCqqPokUKtk Subject: [clue] Fwd: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-clue-framework-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 15:47:44 -0000 --f46d043c092eab183b04f85895e4 Content-Type: text/plain; charset=UTF-8 Per RFC 6701, given this IPR declaration, folks should consider whether the WG should continue with this document or whether some alternatives ought to be considered. Note, there are other IPR declarations against this document and other CLUE WG documents. You can find those identified in the tracker and follow the links to the declarations: http://datatracker.ietf.org/wg/clue/ You click on the document name and then the second field at the bottom of the document description summary shows the number of IPRs. Clicking on that link takes you to the list of IPR declarations. Regards, Mary As WG co-chair ---------- Forwarded message ---------- From: IETF Secretariat Date: Wed, Apr 30, 2014 at 2:38 PM Subject: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-clue-framework-14 To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Cc: rlb@ipv.sx, alissa@cooperw.in, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, clue@ietf.org, ipr-announce@ietf.org Dear Andrew Pepperell, Mark Duckworth, Stephan Wenger: An IPR disclosure that pertains to your Internet-Draft entitled "Framework for Telepresence Multi-Streams" (draft-ietf-clue-framework) was submitted to the IETF Secretariat on 2014-04-28 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2347/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-clue- framework-14.""); The IETF Secretariat --f46d043c092eab183b04f85895e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Per RFC 6701, given this IPR declaration, folks should con= sider whether the WG should continue with this document or whether some alt= ernatives ought to be considered. =C2=A0Note, there are other IPR declarati= ons against this document and other CLUE WG documents.=C2=A0You can find th= ose identified in the tracker and follow the links to the declarations:http://datatracker.ietf.org/wg= /clue/
You click on the document name and then the second field at the bottom of t= he document description summary shows the number of IPRs. =C2=A0Clicking on= that link takes you to the list of IPR declarations.=C2=A0

Regards,
Mary
As WG co-chair

---------- Forwarded message ----------
From: IETF Secretariat <ietf-ipr@ietf.org>
Date: Wed, Apr 30, 2014 at 2:38 PM
Subject: IPR Disclosure: Huawei Techn= ologies Co., Ltd's Statement about IPR related to draft-ietf-clue-frame= work-14
To: apeppere@gmail.com= , mark.duckworth@polycom.com<= /a>, stewe@stewe.org
Cc: rlb@ipv.sx, alissa@cooperw.in,= mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, clue@ietf.org, ipr-announce@ietf.org



Dear Andrew Pepperell, Mark Duckworth, Stephan Wenger:

=C2=A0An IPR disclosure that pertains to your Internet-Draft entitled "= ;Framework for
Telepresence Multi-Streams" (draft-ietf-clue-framework) was submitted = to the
IETF Secretariat on 2014-04-28 and has been posted on the "IETF Page o= f
Intellectual Property Rights Disclosures"
(https= ://datatracker.ietf.org/ipr/2347/). The title of the IPR disclosure is<= br> "Huawei Technologies Co.,Ltd's Statement about IPR related to draf= t-ietf-clue-
framework-14."");

The IETF Secretariat


--f46d043c092eab183b04f85895e4-- From nobody Thu May 1 08:50: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 4B3401A6FB6 for ; Thu, 1 May 2014 08:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gRZZ-iy6UDUL for ; Thu, 1 May 2014 08:50:21 -0700 (PDT) Received: from blu0-omc1-s12.blu0.hotmail.com (blu0-omc1-s12.blu0.hotmail.com [65.55.116.23]) by ietfa.amsl.com (Postfix) with ESMTP id C2A3E1A08CE for ; Thu, 1 May 2014 08:50:20 -0700 (PDT) Received: from BLU0-SMTP4 ([65.55.116.9]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 May 2014 08:50:18 -0700 X-TMN: [Z8FJEPNn/00CbPEFKYlm1B2Lm7vGlqd0] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.38.66]) by BLU0-SMTP4.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 May 2014 08:50:18 -0700 From: Paul Coverdale To: "'Stephen Botzko'" References: <533AF351.9050201@alum.mit.edu> <20140410222705.GW39240@verdi> <53475572.4040807@nteczone.com> <20140411150055.GE60844@verdi> <49E45C59CA48264997FEBFB29B6BC2D6215295A8AE@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D62409219636@CRPMBOXPRD07.polycom.com> <534B4303.7060707@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F07152B@CRPMBOXPRD08.polycom.com> <534B536B.8000205@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13D9B2@CRPMBOXPRD08.polycom.com> <535F0B3A.70808@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13DAE6@CRPMBOXPRD08.polycom.com> <5361C8EA.2060206@nteczone.com> In-Reply-To: Date: Thu, 1 May 2014 11:50:13 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01CF6533.8350C5C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9lLHCnRPMbEh/YQ2WEfB2rz1o3fgAJd/Jw Content-Language: en-us X-OriginalArrivalTime: 01 May 2014 15:50:18.0532 (UTC) FILETIME=[0D364640:01CF6555] Archived-At: http://mailarchive.ietf.org/arch/msg/clue/k1Wz1XjPNW5GFTe1L2rKDq00DJE Cc: clue@ietf.org Subject: Re: [clue] Improving treatment of audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 15:50:22 -0000 ------=_NextPart_000_00EE_01CF6533.8350C5C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My view is that selecting a subset of the audio captures in the room for = rendering or distribution will likely result in bad audio much of the = time - unless the sending system has expressly designed its audio pickup = and seating arrangements to enable that. And a lot of systems won't be = designed to allow it. I don't think it will be all that easy to detect = that from details of the pickup pattern of each microphone or capture = information. The general acoustics of the room also play into it, and I = think the seating arrangement does also. =20 It is possible that senders will create alternative sets of audio = captures - for instance,a set of spatial audio captures that together = provide full room pickup, and a single downmixed monophonic channel that = also covers the full room. Receivers obviously need to sort that out, = just like they do in the corresponding video case. =20 My view is also that trying to select an appropriate video capture for = display by examining the voice activity in all the audio captures in the = room will result in showing the wrong video quite often. This is based = on practical interoperability experience with TIP. [Paul Coverdale] I agree with this. Using voice activity to trigger the = appropriate video in a multi-site conference is one thing, but to = reliably differentiate between talkers in the same room is much more = complicated. =20 It might be helpful if we first try to reach agreement on the = limitations of this kind of selection before we dive into the protocol = mechanics.[/SB] =20 ------=_NextPart_000_00EE_01CF6533.8350C5C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

My view is that = selecting a subset of the audio captures in the room for rendering or = distribution will likely result in bad audio much of the time - unless = the sending system has expressly designed its audio pickup and seating = arrangements to enable that. And a lot of systems won't be designed to = allow it. I don't think it will be all that easy to detect that from = details of the pickup pattern of each microphone or capture information. =  The general acoustics of the room also play into it, and I think = the seating arrangement does also.

 

It is possible that senders will create alternative = sets of audio captures - for instance,a set of spatial audio captures = that together provide full room pickup, and a single downmixed = monophonic channel that also covers the full room.  Receivers = obviously need to sort that out, just like they do in the corresponding = video case.

 

My view is also that trying to select an appropriate = video capture for display by examining the voice activity in all the = audio captures in the room will result in showing the wrong video quite = often.  This is based on practical interoperability experience with = TIP.

[Paul Coverdale] I agree with this. Using voice activity to trigger = the appropriate video in a multi-site conference is one thing, but to = reliably differentiate between talkers in the same room is much more = complicated.

 

It might be helpful if we first try to reach agreement = on the limitations of this kind of selection before we dive into the = protocol mechanics.[/SB]

 

------=_NextPart_000_00EE_01CF6533.8350C5C0-- From nobody Thu May 1 09:33: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 8C6221A091C for ; Thu, 1 May 2014 09:33:22 -0700 (PDT) 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 Zd4BJXfNVAJR for ; Thu, 1 May 2014 09:33:21 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id A859C1A0904 for ; Thu, 1 May 2014 09:33:21 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta06.westchester.pa.mail.comcast.net with comcast id wcuS1n0031vXlb856gZKs3; Thu, 01 May 2014 16:33:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id wgZK1n00W3ZTu2S3dgZKD1; Thu, 01 May 2014 16:33:19 +0000 Message-ID: <5362774F.2020708@alum.mit.edu> Date: Thu, 01 May 2014 12:33:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <533AF351.9050201@alum.mit.edu> <20140410222705.GW39240@verdi> <53475572.4040807@nteczone.com> <20140411150055.GE60844@verdi> <49E45C59CA48264997FEBFB29B6BC2D6215295A8AE@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D62409219636@CRPMBOXPRD07.polycom.com> <534B4303.7060707@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F07152B@CRPMBOXPRD08.polycom.com> <534B536B.8000205@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13D9B2@CRPMBOXPRD08.polycom.com> <535F0B3A.70808@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13DAE6@CRPMBOXPRD08.polycom.com> <5361C8EA.2060206@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398961999; bh=xPtGoKcmu6ZaMZbWw8iM5cTRycVR+ybnmjwiqQ9uC9I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XGYdqVBbsvR8BGrifPIKURTa4UakVKr+9pDBTOhN2m08hl37Sesi96F+pQi9Qca2F w+YYj7SN81og30OcrX+RJLxux6yd7Q60mpWlgNGjJyDFll5uvmMCPRkK2lM7pRWf7C 5JGjVxs9zZqlXC7TuJ2YRSsfdgIJCGjEX7js0eUFcHc0xBcyEly/cz2Ck1bjAdW5Wm aByA9jVMQEuOTDf5Ks83oReynHrAybvQnl9j/PDxoC4l3hNUsRn595BoPEo5Z05Inf esdpUNZDe29YAisjNZOL41oG77m5Fe6UMtGPBMXnemNZqr2TgT7btsatnncpHl90mZ iHTd7PPkG4ptw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/f3_rsB0GgJKaig_BBqmG3wpz58Q Subject: Re: [clue] Improving treatment of audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 16:33:22 -0000 On 5/1/14 6:58 AM, Stephen Botzko wrote: > My view is also that trying to select an appropriate video capture for > display by examining the voice activity in all the audio captures in the > room will result in showing the wrong video quite often. This is based > on practical interoperability experience with TIP. > > It might be helpful if we first try to reach agreement on the > limitations of this kind of selection before we dive into the protocol > mechanics.[/SB] I think it would be helpful to describe the kinds of choices we intend to facilitate, and those that we think are non-goals and likely not supported by the mechanism. I think it is important that we agree on what these are. Then, for the kinds of choices we intend to facilitate it would be good to (somewhere) have some existence proofs (examples) of how this can be achieved. These need not be normative. Part of our problem right now may be that we *don't* agree on this. For instance, for video, I think it is in scope for a consumer to select a subset of the captures - even a subset of a CSE that might be useful *to some consumers*. (For instance somebody who only wants to monitor the behavior of his boss.) For audio, I see hints of a consensus that a subset of the captures in a CSE will almost never provide a useful experience. But perhaps the general assertion ought to be that one complete video CSE and one complete audio CSE per scene is the minimum that can be expected to provide a good experience. Subsets of that are allowed, but without any promises about the acceptability of the result. Thanks, Paul From nobody Thu May 1 09:54: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 A9BA11A0926 for ; Thu, 1 May 2014 09:54:50 -0700 (PDT) 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 7ZQR9_ipWILD for ; Thu, 1 May 2014 09:54:48 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0D45A1A6F9F for ; Thu, 1 May 2014 09:54:47 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so4118987veb.37 for ; Thu, 01 May 2014 09:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sj5NF/qjPOT6bRqjHqyknEzgq+a492885YsebRHrclk=; b=m9NocVX43AjXCiquEDrffSDunlX6Zl8CJJLCVdmVKz/L/Am3pgmWQP+t/kJftacwpl MbtV7tRY6+XV9A9lu0y0fmXKIAR815LgA9QkvU+CI24B3l2lBFmFl1rc9PxMOwSF9Nda X+SG/7MPXdICzxq+PeIow9x05z4z0Zl6ARat+AGrZvo8UQNjdM+9ZEtH5eveEzc3voqk NFsfVjYc+IrT5hP/TJs92s6AcOkzBWqDgekgu954EGzXz5y1etNXwbUB6s0IpHsQ0XYa 18IpwM4MqVRlsR6ny1hhSY47Pe/O5vxHA1aEMpakOKHY9r7ZEH9NVRgfRat6/CbiE2LP TvtA== MIME-Version: 1.0 X-Received: by 10.58.132.2 with SMTP id oq2mr132428veb.76.1398963285861; Thu, 01 May 2014 09:54:45 -0700 (PDT) Received: by 10.221.40.135 with HTTP; Thu, 1 May 2014 09:54:45 -0700 (PDT) In-Reply-To: <5362774F.2020708@alum.mit.edu> References: <533AF351.9050201@alum.mit.edu> <20140410222705.GW39240@verdi> <53475572.4040807@nteczone.com> <20140411150055.GE60844@verdi> <49E45C59CA48264997FEBFB29B6BC2D6215295A8AE@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D62409219636@CRPMBOXPRD07.polycom.com> <534B4303.7060707@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F07152B@CRPMBOXPRD08.polycom.com> <534B536B.8000205@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13D9B2@CRPMBOXPRD08.polycom.com> <535F0B3A.70808@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13DAE6@CRPMBOXPRD08.polycom.com> <5361C8EA.2060206@nteczone.com> <5362774F.2020708@alum.mit.edu> Date: Thu, 1 May 2014 12:54:45 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b67670cb52a3d04f8598532 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/QWAFKErrpKFjtMyqoHnuEURKGtw Cc: CLUE Subject: Re: [clue] Improving treatment of audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 16:54:50 -0000 --047d7b67670cb52a3d04f8598532 Content-Type: text/plain; charset=UTF-8 On Thu, May 1, 2014 at 12:33 PM, Paul Kyzivat wrote: > On 5/1/14 6:58 AM, Stephen Botzko wrote: > > My view is also that trying to select an appropriate video capture for >> display by examining the voice activity in all the audio captures in the >> room will result in showing the wrong video quite often. This is based >> on practical interoperability experience with TIP. >> >> It might be helpful if we first try to reach agreement on the >> limitations of this kind of selection before we dive into the protocol >> mechanics.[/SB] >> > > I think it would be helpful to describe the kinds of choices we intend to > facilitate, and those that we think are non-goals and likely not supported > by the mechanism. I think it is important that we agree on what these are. > > Then, for the kinds of choices we intend to facilitate it would be good to > (somewhere) have some existence proofs (examples) of how this can be > achieved. These need not be normative. > > Part of our problem right now may be that we *don't* agree on this. > > For instance, for video, I think it is in scope for a consumer to select a > subset of the captures - even a subset of a CSE that might be useful *to > some consumers*. (For instance somebody who only wants to monitor the > behavior of his boss.) > > For audio, I see hints of a consensus that a subset of the captures in a > CSE will almost never provide a useful experience. > > But perhaps the general assertion ought to be that one complete video CSE > and one complete audio CSE per scene is the minimum that can be expected to > provide a good experience. Subsets of that are allowed, but without any > promises about the acceptability of the result. > [sb]I think this is in the right direction, though perhaps it needs some more refinement. We probably need to acknowledge some differences between audio and video in any general assertions. For video, arguably you can get a better experience in some cases if you use fewer captures displayed at a larger size - getting closeups of a few people instead of a crowd of indistinguishable people. You can of course also render video captures in more than one place on the screen, which makes no sense for audio. With video you need to manage screen real estate - especially in multipoint, where it quickly becomes a scarce resource. There is no corresponding thing to manage for audio.[\sb] > > Thanks, > Paul > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --047d7b67670cb52a3d04f8598532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, May 1, 2014 at 12:33 PM, Paul Kyzivat <= ;pkyzivat@alum.m= it.edu> wrote:
On 5/1/14 6:58 AM, Stephen B= otzko wrote:

My view is also that trying to select an appropriate video capture for
display by examining the voice activity in all the audio captures in the room will result in showing the wrong video quite often. =C2=A0This is base= d
on practical interoperability experience with TIP.

It might be helpful if we first try to reach agreement on the
limitations of this kind of selection before we dive into the protocol
mechanics.[/SB]

I think it would be helpful to describe the kinds of choices we intend to f= acilitate, and those that we think are non-goals and likely not supported b= y the mechanism. I think it is important that we agree on what these are.
Then, for the kinds of choices we intend to facilitate it would be good to = (somewhere) have some existence proofs (examples) of how this can be achiev= ed. These need not be normative.

Part of our problem right now may be that we *don't* agree on this.

For instance, for video, I think it is in scope for a consumer to select a = subset of the captures - even a subset of a CSE that might be useful *to so= me consumers*. (For instance somebody who only wants to monitor the behavio= r of his boss.)

For audio, I see hints of a consensus that a subset of the captures in a CS= E will almost never provide a useful experience.

But perhaps the general assertion ought to be that one complete video CSE a= nd one complete audio CSE per scene is the minimum that can be expected to = provide a good experience. Subsets of that are allowed, but without any pro= mises about the acceptability of the result.
[sb]I think this is in the right direction, though perhap= s it needs some more refinement. =C2=A0We probably need to acknowledge some= differences between audio and video in any general assertions.

For video, arguably you can get a better experience in some = cases if you use fewer captures displayed at a larger size - getting closeu= ps of a few people instead of a crowd of indistinguishable people.=C2=A0

You can of course also render video captures in more th= an one place on the screen, which makes no sense for audio. =C2=A0=C2=A0

With video you need to manage screen real estate - e= specially in multipoint, where it quickly becomes a scarce resource. There = is no corresponding thing to manage for audio.[\sb]

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

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

--047d7b67670cb52a3d04f8598532-- From nobody Thu May 1 11: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 B32591A08B3 for ; Thu, 1 May 2014 11:48:11 -0700 (PDT) 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 rDYrOEFGRSqf for ; Thu, 1 May 2014 11:48:11 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id CB7AF1A073F for ; Thu, 1 May 2014 11:48:10 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta04.westchester.pa.mail.comcast.net with comcast id wi1U1n00616LCl054io89h; Thu, 01 May 2014 18:48:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id wio81n00h3ZTu2S3Sio828; Thu, 01 May 2014 18:48:08 +0000 Message-ID: <536296E8.8090706@alum.mit.edu> Date: Thu, 01 May 2014 14:48:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Botzko References: <533AF351.9050201@alum.mit.edu> <20140410222705.GW39240@verdi> <53475572.4040807@nteczone.com> <20140411150055.GE60844@verdi> <49E45C59CA48264997FEBFB29B6BC2D6215295A8AE@CRPMBOXPRD07.polycom.com> <49E45C59CA48264997FEBFB29B6BC2D62409219636@CRPMBOXPRD07.polycom.com> <534B4303.7060707@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F07152B@CRPMBOXPRD08.polycom.com> <534B536B.8000205@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13D9B2@CRPMBOXPRD08.polycom.com> <535F0B3A.70808@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13DAE6@CRPMBOXPRD08.polycom.com> <5361C8EA.2060206@nteczone.com> <5362774F.2020708@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398970088; bh=9xKi9cPdBoIsrmX3oDWlG28j3FpnBey2yKehLXEqnmI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GfkrLTGnoIlsVGdUl8el6LL1fz/boUqn40ZD4OTE8Ny6qhwRUrgCkEft2nf5pJuXw +eg7yQQ786c9N+HsBWLX3g7eDyqR8hZBB4ENFzMV7N1jnyewhH9d7zmw1QaxPtQPaM Tkr1zhGAmt+5vHMeeYS7i8LV8Zb0R9lyH8dGYseYdra9NxyG9CDvWaQEcLG5alng3M 6404UWn3LoMafQ8tg1P4NUIhfrC9090jH+wqTU+fRy2z07wWOgbV6ZgouFD0o1OcBL bQB3GjVbY5NaRDqv8ul/NWeO+EVN2yJG6+4j0nnpFxARwiq2smsdZVyIhNrp+0AWLI pHaaUOW88ulMQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/869-_ZHqItG1AokVy6DUGZeczMI Cc: CLUE Subject: Re: [clue] Improving treatment of audio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 01 May 2014 18:48:11 -0000 On 5/1/14 12:54 PM, Stephen Botzko wrote: > > On Thu, May 1, 2014 at 12:33 PM, Paul Kyzivat > wrote: > > On 5/1/14 6:58 AM, Stephen Botzko wrote: > > My view is also that trying to select an appropriate video > capture for > display by examining the voice activity in all the audio > captures in the > room will result in showing the wrong video quite often. This > is based > on practical interoperability experience with TIP. > > It might be helpful if we first try to reach agreement on the > limitations of this kind of selection before we dive into the > protocol > mechanics.[/SB] > > > I think it would be helpful to describe the kinds of choices we > intend to facilitate, and those that we think are non-goals and > likely not supported by the mechanism. I think it is important that > we agree on what these are. > > Then, for the kinds of choices we intend to facilitate it would be > good to (somewhere) have some existence proofs (examples) of how > this can be achieved. These need not be normative. > > Part of our problem right now may be that we *don't* agree on this. > > For instance, for video, I think it is in scope for a consumer to > select a subset of the captures - even a subset of a CSE that might > be useful *to some consumers*. (For instance somebody who only wants > to monitor the behavior of his boss.) > > For audio, I see hints of a consensus that a subset of the captures > in a CSE will almost never provide a useful experience. > > But perhaps the general assertion ought to be that one complete > video CSE and one complete audio CSE per scene is the minimum that > can be expected to provide a good experience. Subsets of that are > allowed, but without any promises about the acceptability of the result. > > [sb]I think this is in the right direction, though perhaps it needs some > more refinement. I'm *sure* it needs more refinement! > We probably need to acknowledge some differences > between audio and video in any general assertions. > > For video, arguably you can get a better experience in some cases if you > use fewer captures displayed at a larger size - getting closeups of a > few people instead of a crowd of indistinguishable people. > > You can of course also render video captures in more than one place on > the screen, which makes no sense for audio. > > With video you need to manage screen real estate - especially in > multipoint, where it quickly becomes a scarce resource. There is no > corresponding thing to manage for audio.[\sb] I'm hoping those of you who know more about this than I do can do the refinement. I'm approaching this from an information theoretic perspective - what inferences are possible given the information in the framework. And at the moment it seems to me that lots of unexplained assumptions are required to use the information in the advertisement to correlate audio with video, or to extract enough about the audio to decide how best to render it. Thanks, Paul From nobody Thu May 1 16:55: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 016781A0958 for ; Thu, 1 May 2014 16:55:44 -0700 (PDT) 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 9oOo8iCD6tfE for ; Thu, 1 May 2014 16:55:42 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2757A1A066A for ; Thu, 1 May 2014 16:55:42 -0700 (PDT) Received: from ppp118-209-101-136.lns20.mel4.internode.on.net ([118.209.101.136]:62803 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wg0pE-0006ys-UK for clue@ietf.org; Fri, 02 May 2014 09:55:37 +1000 Message-ID: <5362DEF5.7060608@nteczone.com> Date: Fri, 02 May 2014 09:55:33 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "clue@ietf.org" References: <533A22FC.7080004@nteczone.com> In-Reply-To: <533A22FC.7080004@nteczone.com> X-Forwarded-Message-Id: <533A22FC.7080004@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/SsxcBXoTNIpkyPmSNF65CwMuFNA Subject: [clue] Fwd: Comments Re: I-D Action: draft-ietf-clue-datachannel-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 23:55:44 -0000 Hello Christer, Some comments on the latest draft: cl.3.2: The first two paragraphs need to be merged somehow. The first indicates mandatory support of DCEP, the 2nd indicates optional support of DCEP. I think the 2nd paragraph can be used as the 1st sentence of the first paragraph. cl.3.3.2: With respect to the note. It says partial reliability is not needed for CLUE and the reason. The part on limited retransmission is vague. It doesn't say CLUE doesn't use it nor the reason. (yes I know the paragraph above rules it out). cl.3.3.4: The extension defined by RFC6525 is "STCP Stream Reconfiguration". It has more than just "reset" procedures, e.g. adding streams, rec-configuration streams. We may want to be a bit more precise here to avoid any confusion that only the reset procedures are supported. Regards, Christian On 22/03/2014 1:11 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-00.txt > Pages : 12 > Date : 2014-03-20 > > 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-00 > > > 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 Fri May 2 06:00: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 53DC41A6F49 for ; Fri, 2 May 2014 06:00:38 -0700 (PDT) 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 jjmxRmIRyeBw for ; Fri, 2 May 2014 06:00:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1395A1A0821 for ; Fri, 2 May 2014 06:00:35 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-8c-536396f17e89 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E4.6A.04714.1F693635; Fri, 2 May 2014 15:00:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Fri, 2 May 2014 15:00:32 +0200 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Fwd: Comments Re: I-D Action: draft-ietf-clue-datachannel-00.txt Thread-Index: AQHPZZjeVnP3llK0fUa07IATO8VUK5stPYPQ Date: Fri, 2 May 2014 13:00:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2E9901@ESESSMB209.ericsson.se> References: <533A22FC.7080004@nteczone.com> <5362DEF5.7060608@nteczone.com> In-Reply-To: <5362DEF5.7060608@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje7HacnBBvs+Cll8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugSvj39ZDrAUPpCoW/l3E2sDYJtrFyMEhIWAi 0fm1pouRE8gUk7hwbz1bFyMXh5DAUUaJk39uMUM4ixklbh54wgzSwCZgIdH9TxukQUQgXKJj 2xVGEFtYIExi2ZELbDDxubfaWCBsI4nJ3ROZQGwWARWJzrZnYPW8Ar4Sm89PBasREvCWuLIQ ooZTQEfi7p33YHMYgQ76fmoNWJxZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B8rhK0osfNsOzNE vY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxihanFhfnphsZ 66UWZSYXF+fn6eWllmxiBEbJwS2/dXcwrn7teIhRgINRiYe3+EtksBBrYllxZe4hRmkOFiVx 3ra73sFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGP32b3SynMQUW3O4WPKUh8c2qduKLw5t yTDNyb467cLz05WfzIp2SWgtYotfIifo2bcuZMJR+813zQ7oGLIqi5+vfcpcvj+U78uiFvG3 rb1/H0496Sfz+qztAsaPG3IO5m14emAGO9fG46WagTlLvi7e+33FxZKz391M/s727J1899B/ XRvjmu1KLMUZiYZazEXFiQAfoFJecwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/7RXsaJ_QIN6fl8wylRWMNuvpZN4 Subject: Re: [clue] Fwd: Comments Re: I-D Action: draft-ietf-clue-datachannel-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 13:00:38 -0000 Hi Christian, > cl.3.2: The first two paragraphs need to be merged somehow. The first ind= icates mandatory support of DCEP, the 2nd indicates=20 > optional support of DCEP. I think the 2nd paragraph can be used as the 1s= t sentence of the first paragraph. Note that there is a difference between the mandatory SUPPORT of DCEP, and = the OPTIONAL use of DCEP. I wrote it that way in order to allow for the usage of the mechanism descri= bed in "Richard's draft", if it gets ready in time for the publication of t= he datachannel draft. However, lately I have seen zero progress of "Richard's draft", so I don't = know what/if the authors intend to do... Richard? Keith? > cl.3.3.2: With respect to the note. It says partial reliability is not ne= eded for CLUE and the reason. The part on=20 > limited retransmission is vague. It doesn't say CLUE doesn't use it nor t= he reason. (yes I know the paragraph=20 > above rules it out). Ok, maybe some extra text is needed. > cl.3.3.4: The extension defined by RFC6525 is "STCP Stream Reconfiguratio= n". It has more than just "reset" procedures, e.g.=20 > adding streams, rec-configuration streams. We may want to be a bit more p= recise here to avoid any confusion that only the=20 > reset procedures are supported. As far as I know, we DO only need the reset procedures. As far as I know, t= he general data channel framework doesn't require anything else either, but= I may be wrong. Regards Christer On 22/03/2014 1:11 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-00.txt > Pages : 12 > Date : 2014-03-20 > > 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-00 > > > 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 Fri May 2 07:17:54 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1B51A6FBC for ; Fri, 2 May 2014 07:17:53 -0700 (PDT) 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 KRsf_xNbTNXb for ; Fri, 2 May 2014 07:17:51 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 695381A6FB4 for ; Fri, 2 May 2014 07:17:51 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id hq16so5309405vcb.25 for ; Fri, 02 May 2014 07:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5ewzoITljGtBoJUNwGz//siALmBHaD138FY83H5I7pM=; b=iaMBYe1BX8S/dT/qZnB+XeGX4uersEQVOy/oWnMUdEiBDNuIVleI2wFUotMlelsrTY zyeQzASVuExK7zD7l6TWkdIBv7D9ZjUv4p/jgG8XMGoaEBilWzP1i3LYYPNskF0hOfzZ j5vXzC3HdcpRS6+iKOZZ1Dr6Ku8YHvWCteeKTmD2z4db9EbI5dkJK7N9SduncvBXXXy+ xbv3Vpf3pLXB05vH7FfeUZjX4TY2UKee4ywluoslVdfE8e/+n37HpAgOme/WefdQ04Yr fBTrHlRdr/BWZ2cirNtERHcflFl5eUlFa6QvDnPPyP453XhzHZvETSFsKZxgjDoNu5i2 ZpPQ== MIME-Version: 1.0 X-Received: by 10.221.34.7 with SMTP id sq7mr13587865vcb.5.1399040268955; Fri, 02 May 2014 07:17:48 -0700 (PDT) Received: by 10.221.40.135 with HTTP; Fri, 2 May 2014 07:17:48 -0700 (PDT) In-Reply-To: References: <20140430193810.6483.37869.idtracker@ietfa.amsl.com> Date: Fri, 2 May 2014 10:17:48 -0400 Message-ID: From: Stephen Botzko To: Mary Barnes Content-Type: multipart/alternative; boundary=001a1136526a41f7f004f86b72a1 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/t02BT7S69-lMeJu1P1I1R9XyLjI Cc: CLUE Subject: Re: [clue] Fwd: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-clue-framework-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:17:53 -0000 --001a1136526a41f7f004f86b72a1 Content-Type: text/plain; charset=UTF-8 Since in this particular case, the declaration includes an unpublished application, a full technical assessment is not possible. So finding alternatives seems problematic. I propose that we continue working on this draft, at least for now, and re-assess this later on - when perhaps the application is published or issues. Stephen On Thu, May 1, 2014 at 11:47 AM, Mary Barnes wrote: > Per RFC 6701, given this IPR declaration, folks should consider whether > the WG should continue with this document or whether some alternatives > ought to be considered. Note, there are other IPR declarations against > this document and other CLUE WG documents. You can find those identified in > the tracker and follow the links to the declarations: > http://datatracker.ietf.org/wg/clue/ > You click on the document name and then the second field at the bottom of > the document description summary shows the number of IPRs. Clicking on > that link takes you to the list of IPR declarations. > > Regards, > Mary > As WG co-chair > > > ---------- Forwarded message ---------- > From: IETF Secretariat > Date: Wed, Apr 30, 2014 at 2:38 PM > Subject: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about > IPR related to draft-ietf-clue-framework-14 > To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org > Cc: rlb@ipv.sx, alissa@cooperw.in, mary.ietf.barnes@gmail.com, > pkyzivat@alum.mit.edu, clue@ietf.org, ipr-announce@ietf.org > > > > Dear Andrew Pepperell, Mark Duckworth, Stephan Wenger: > > An IPR disclosure that pertains to your Internet-Draft entitled > "Framework for > Telepresence Multi-Streams" (draft-ietf-clue-framework) was submitted to > the > IETF Secretariat on 2014-04-28 and has been posted on the "IETF Page of > Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/2347/). The title of the IPR disclosure > is > "Huawei Technologies Co.,Ltd's Statement about IPR related to > draft-ietf-clue- > framework-14.""); > > The IETF Secretariat > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --001a1136526a41f7f004f86b72a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since in this particular case, the declaration includes an= unpublished application, a full technical assessment is not possible. =C2= =A0So finding alternatives seems problematic.

I propose = that we continue working on this draft, at least for now, and re-assess thi= s later on - when perhaps the application is published or issues.

Stephen



On Thu, May 1, 2014 at 11:47 AM, M= ary Barnes <mary.ietf.barnes@gmail.com> wrote:
Per RFC 6701, given this IP= R declaration, folks should consider whether the WG should continue with th= is document or whether some alternatives ought to be considered. =C2=A0Note= , there are other IPR declarations against this document and other CLUE WG = documents.=C2=A0You can find those identified in the tracker and follow the= links to the declarations:http://datatracker.ietf.org/wg/clue/
You click on the document name and then the second field at the bottom of t= he document description summary shows the number of IPRs. =C2=A0Clicking on= that link takes you to the list of IPR declarations.=C2=A0

Regards,
Mary
As WG co-chair

---------- Forwarded message ----------
From= : IETF Secretariat <= ietf-ipr@ietf.org>
Date: Wed, Apr 30, 2014 at 2:38 PM
Subject: IPR Disclosure: Huawei Techn= ologies Co., Ltd's Statement about IPR related to draft-ietf-clue-frame= work-14
To: apep= pere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org
Cc: rlb@ipv.sx, alis= sa@cooperw.in, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, clue@ietf.org, ipr-announce@ietf.org



Dear Andrew Pepperell, Mark Duckworth, Stephan Wenger:

=C2=A0An IPR disclosure that pertains to your Internet-Draft entitled "= ;Framework for
Telepresence Multi-Streams" (draft-ietf-clue-framework) was submitted = to the
IETF Secretariat on 2014-04-28 and has been posted on the "IETF Page o= f
Intellectual Property Rights Disclosures"
(https= ://datatracker.ietf.org/ipr/2347/). The title of the IPR disclosure is<= br> "Huawei Technologies Co.,Ltd's Statement about IPR related to draf= t-ietf-clue-
framework-14."");

The IETF Secretariat



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


--001a1136526a41f7f004f86b72a1-- From nobody Fri May 2 07:52:33 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0504C1A7011 for ; Fri, 2 May 2014 07:52:32 -0700 (PDT) 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 sGZzAywwPtx6 for ; Fri, 2 May 2014 07:52:31 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id DBC931A6FF4 for ; Fri, 2 May 2014 07:52:30 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta09.westchester.pa.mail.comcast.net with comcast id x1Mt1n0011ap0As592sUBK; Fri, 02 May 2014 14:52:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id x2sU1n0083ZTu2S3i2sUHb; Fri, 02 May 2014 14:52:28 +0000 Message-ID: <5363B12C.30106@alum.mit.edu> Date: Fri, 02 May 2014 10:52:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <533A22FC.7080004@nteczone.com> <5362DEF5.7060608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D2E9901@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2E9901@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399042348; bh=5ZRe0iat+YEZznLA8DScyCouYA5fmupsTE4Qq1LtrCQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=T+3IRUJlysxM+03/0pH6flRewGyLAvRXKrPvhTr16H7/WwAWM0AP6lYYnyezwwdS4 4bgRVJevtDwIE0cUkt5gfPaYvvj92TzKjlzcrZl1V5cTkjjBbCtQ8QdudYl9AXD3hg fJd62By1tdMp/lFwd8FkCIh2UwP7zDHWH1X1ObJ4E6vf/VKh/P1Dh0nAEy9Y4Cjz/W 3qzw8e4PTWWHzNGa/bV8cT/5hATbwexyfOAE0OXhgLmhiHY5I3OUdRRiQu1S/XC5ep k3eT9o51zElO2yiJVLdcf6sZABQ40Qh0A22csn12jvSUSmetDRRh0js3ifm1GhEBBX 7UkSnh4HTGHMg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3uMbohU1lh3xiNvlV9iztgXJLBY Subject: Re: [clue] Fwd: Comments Re: I-D Action: draft-ietf-clue-datachannel-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 14:52:32 -0000 On 5/2/14 9:00 AM, Christer Holmberg wrote: > Hi Christian, > >> cl.3.2: The first two paragraphs need to be merged somehow. The first indicates mandatory support of DCEP, the 2nd indicates >> optional support of DCEP. I think the 2nd paragraph can be used as the 1st sentence of the first paragraph. > > Note that there is a difference between the mandatory SUPPORT of DCEP, and the OPTIONAL use of DCEP. > > I wrote it that way in order to allow for the usage of the mechanism described in "Richard's draft", if it gets ready in time for the publication of the datachannel draft. > > However, lately I have seen zero progress of "Richard's draft", so I don't know what/if the authors intend to do... Richard? Keith? > >> cl.3.3.2: With respect to the note. It says partial reliability is not needed for CLUE and the reason. The part on >> limited retransmission is vague. It doesn't say CLUE doesn't use it nor the reason. (yes I know the paragraph >> above rules it out). > > Ok, maybe some extra text is needed. > >> cl.3.3.4: The extension defined by RFC6525 is "STCP Stream Reconfiguration". It has more than just "reset" procedures, e.g. >> adding streams, rec-configuration streams. We may want to be a bit more precise here to avoid any confusion that only the >> reset procedures are supported. > > As far as I know, we DO only need the reset procedures. As far as I know, the general data channel framework doesn't require anything else either, but I may be wrong. That is my understanding too. But I doubt we want to go into details about this, or try to respecify the normative requirements. If we specify the dependency on the DCEP draft, then we inherit the requirements it pulls in. Thanks, Paul From nobody Fri May 2 09:56: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 857541A084B for ; Fri, 2 May 2014 09:56:40 -0700 (PDT) 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 RbdTIr9GwTY4 for ; Fri, 2 May 2014 09:56:38 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 767971A08D0 for ; Fri, 2 May 2014 09:56:38 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm4so2669176wib.17 for ; Fri, 02 May 2014 09:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=erUIP1+WgUqXO9lPaGPNcSFUvuTWKpvbu8ra20wvaP0=; b=ooDAdmCYYmUuoqzRmBHjti+FAQyymCdOYiDFfQpci/vS/vD2bqEoHbudfc8GvXjb0o nEo6HwIUsXhKsauHlW6XDrc+IKpYjeGMY7GFcVTmCoxaxAqnakAQi9x28ZVBtUUhzyvA SS5vfDJfy5G6B+1KjBerQRkiuNdSJwza7BH/7xejxEEfmxInj+DOk+0q4EtQLqGIs8s/ O5WZ4hycC/M0jvaKLsU3woCoH2Grm619pevgQGFnw+nza1laz435TcagJHdEjZMtEIcA dSEL6272lnd5S/UwjtJDOzKa1ZN5kLDbZLEb12YGonaTWNgCSGIFM4uk+AcHFxSvuuwf Iyag== MIME-Version: 1.0 X-Received: by 10.180.80.3 with SMTP id n3mr3769524wix.36.1399049795624; Fri, 02 May 2014 09:56:35 -0700 (PDT) Received: by 10.216.93.68 with HTTP; Fri, 2 May 2014 09:56:35 -0700 (PDT) In-Reply-To: References: <20140430193810.6483.37869.idtracker@ietfa.amsl.com> Date: Fri, 2 May 2014 11:56:35 -0500 Message-ID: From: Mary Barnes To: Stephen Botzko Content-Type: multipart/alternative; boundary=f46d041825381762eb04f86daafe Archived-At: http://mailarchive.ietf.org/arch/msg/clue/LtN2A7yhm9UwZckCmFFUB48WYYo Cc: CLUE Subject: Re: [clue] Fwd: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-clue-framework-14 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 16:56:40 -0000 --f46d041825381762eb04f86daafe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Certainly, that seems sensible. One question of curiosity is whether this IPR also applies to any of the solution documents? I don't see any declarations from Huawei against either the Signaling or CLUE Protocol. Another question is given the IPR that's piling up against these documents, will there be anyone other than the folks with IPR that would be willing to implement the work that =10CLUE is producing? For example, the Open Source community. Regards, Mary. On Fri, May 2, 2014 at 9:17 AM, Stephen Botzko wr= ote: > Since in this particular case, the declaration includes an unpublished > application, a full technical assessment is not possible. So finding > alternatives seems problematic. > > I propose that we continue working on this draft, at least for now, and > re-assess this later on - when perhaps the application is published or > issues. > > Stephen > > > > On Thu, May 1, 2014 at 11:47 AM, Mary Barnes = wrote: > >> Per RFC 6701, given this IPR declaration, folks should consider whether >> the WG should continue with this document or whether some alternatives >> ought to be considered. Note, there are other IPR declarations against >> this document and other CLUE WG documents. You can find those identified= in >> the tracker and follow the links to the declarations: >> http://datatracker.ietf.org/wg/clue/ >> You click on the document name and then the second field at the bottom o= f >> the document description summary shows the number of IPRs. Clicking on >> that link takes you to the list of IPR declarations. >> >> Regards, >> Mary >> As WG co-chair >> >> >> ---------- Forwarded message ---------- >> From: IETF Secretariat >> Date: Wed, Apr 30, 2014 at 2:38 PM >> Subject: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about >> IPR related to draft-ietf-clue-framework-14 >> To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org >> Cc: rlb@ipv.sx, alissa@cooperw.in, mary.ietf.barnes@gmail.com, >> pkyzivat@alum.mit.edu, clue@ietf.org, ipr-announce@ietf.org >> >> >> >> Dear Andrew Pepperell, Mark Duckworth, Stephan Wenger: >> >> An IPR disclosure that pertains to your Internet-Draft entitled >> "Framework for >> Telepresence Multi-Streams" (draft-ietf-clue-framework) was submitted to >> the >> IETF Secretariat on 2014-04-28 and has been posted on the "IETF Page of >> Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/2347/). The title of the IPR >> disclosure is >> "Huawei Technologies Co.,Ltd's Statement about IPR related to >> draft-ietf-clue- >> framework-14.""); >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > --f46d041825381762eb04f86daafe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Certainly, that seems sensible. =C2=A0One question of curi= osity is whether this IPR also applies to any of the solution documents? = =C2=A0I don't see any declarations from Huawei against either the Signa= ling or CLUE Protocol.

Another question is given the IPR that's piling up again= st these documents, will there be anyone other than the folks with IPR that= would be willing to implement the work that =10CLUE is producing? =C2=A0Fo= r example, the Open Source community.

Regards,
Mary.=C2=A0


On Fri, May 2, 2014 at 9:1= 7 AM, Stephen Botzko <stephen.botzko@gmail.com> wrote= :
Since in this particular ca= se, the declaration includes an unpublished application, a full technical a= ssessment is not possible. =C2=A0So finding alternatives seems problematic.=

I propose that we continue working on this draft, at least f= or now, and re-assess this later on - when perhaps the application is publi= shed or issues.

Stephen



On Thu, May 1, 2014 at 11:47 AM, Mary Barnes <mary.ietf.barnes= @gmail.com> wrote:
Per RFC 6701, given this IPR declaration, folks should consider wh= ether the WG should continue with this document or whether some alternative= s ought to be considered. =C2=A0Note, there are other IPR declarations agai= nst this document and other CLUE WG documents.=C2=A0You can find those iden= tified in the tracker and follow the links to the declarations:http://datatracker.i= etf.org/wg/clue/
You click on the document name and then the second field at the bottom of t= he document description summary shows the number of IPRs. =C2=A0Clicking on= that link takes you to the list of IPR declarations.=C2=A0

Regards,
Mary
As WG co-chair


---------- Forwarded message ----------
From: IETF Secretariat <ietf-ipr@ietf.org>
Date: Wed, Apr 30, 2014 at 2:38 PM
Subject: IPR Disclosure: Huawei Techn= ologies Co., Ltd's Statement about IPR related to draft-ietf-clue-frame= work-14
To: apep= pere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org
Cc: rlb@ipv.sx, alis= sa@cooperw.in, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, clue@ietf.org, ipr-announce@ietf.org



Dear Andrew Pepperell, Mark Duckworth, Stephan Wenger:

=C2=A0An IPR disclosure that pertains to your Internet-Draft entitled "= ;Framework for
Telepresence Multi-Streams" (draft-ietf-clue-framework) was submitted = to the
IETF Secretariat on 2014-04-28 and has been posted on the "IETF Page o= f
Intellectual Property Rights Disclosures"
(https= ://datatracker.ietf.org/ipr/2347/). The title of the IPR disclosure is<= br> "Huawei Technologies Co.,Ltd's Statement about IPR related to draf= t-ietf-clue-
framework-14."");

The IETF Secretariat



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



--f46d041825381762eb04f86daafe-- From nobody Sun May 4 21:43:01 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432481A0242 for ; Sun, 4 May 2014 21:42:59 -0700 (PDT) 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 fgeDr38gJV6g for ; Sun, 4 May 2014 21:42:57 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1171A0241 for ; Sun, 4 May 2014 21:42:56 -0700 (PDT) Received: from ppp118-209-6-179.lns20.mel4.internode.on.net ([118.209.6.179]:52703 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WhAjk-0004fW-Mz for clue@ietf.org; Mon, 05 May 2014 14:42:44 +1000 Message-ID: <536716CA.303@nteczone.com> Date: Mon, 05 May 2014 14:42:50 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <533A22FC.7080004@nteczone.com> <5362DEF5.7060608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D2E9901@ESESSMB209.ericsson.se> <5363B12C.30106@alum.mit.edu> In-Reply-To: <5363B12C.30106@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/Ch1XWy2qO_MbV-G7KvlH0J6tGlE Subject: Re: [clue] Fwd: Comments Re: I-D Action: draft-ietf-clue-datachannel-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 04:42:59 -0000 Hello Paul and Christer, Please see my comments below. Regards, Christian On 3/05/2014 12:52 AM, Paul Kyzivat wrote: > On 5/2/14 9:00 AM, Christer Holmberg wrote: >> Hi Christian, >> >>> cl.3.2: The first two paragraphs need to be merged somehow. The >>> first indicates mandatory support of DCEP, the 2nd indicates >>> optional support of DCEP. I think the 2nd paragraph can be used as >>> the 1st sentence of the first paragraph. >> >> Note that there is a difference between the mandatory SUPPORT of >> DCEP, and the OPTIONAL use of DCEP. >> >> I wrote it that way in order to allow for the usage of the mechanism >> described in "Richard's draft", if it gets ready in time for the >> publication of the datachannel draft. [CNG] I think you can still capture that in one paragraph: "In the absence of another mechanism, a CLUE entity MUST support the Data Channel Establishment Protocol(DCEP) [I-D.ietf-rtcweb-data-channel], which can be used in order to open a WebRTC Data Channel." >> >> However, lately I have seen zero progress of "Richard's draft", so I >> don't know what/if the authors intend to do... Richard? Keith? >> >>> cl.3.3.2: With respect to the note. It says partial reliability is >>> not needed for CLUE and the reason. The part on >>> limited retransmission is vague. It doesn't say CLUE doesn't use it >>> nor the reason. (yes I know the paragraph >>> above rules it out). >> >> Ok, maybe some extra text is needed. >> >>> cl.3.3.4: The extension defined by RFC6525 is "STCP Stream >>> Reconfiguration". It has more than just "reset" procedures, e.g. >>> adding streams, rec-configuration streams. We may want to be a bit >>> more precise here to avoid any confusion that only the >>> reset procedures are supported. >> >> As far as I know, we DO only need the reset procedures. As far as I >> know, the general data channel framework doesn't require anything >> else either, but I may be wrong. > > That is my understanding too. But I doubt we want to go into details > about this, or try to respecify the normative requirements. If we > specify the dependency on the DCEP draft, then we inherit the > requirements it pulls in. [CNG] The problem is for this we don't specify the dependency and we only partially normatively say how stream reset is used. If you want to defer to the data channel draft then all we'd need to say is "A CLUE entity MUST support RFC6525 and RFC5061 according to [I-D.ietf-rtcweb-data-channel]. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon May 5 07:30: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 6962E1A037D for ; Mon, 5 May 2014 07:30:28 -0700 (PDT) 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 yMAqX1Gk8U4O for ; Mon, 5 May 2014 07:30:27 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0851A02FF for ; Mon, 5 May 2014 07:30:27 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta09.westchester.pa.mail.comcast.net with comcast id yDd01n0040SCNGk59EWPFE; Mon, 05 May 2014 14:30:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id yEWP1n00b3ZTu2S3VEWPhv; Mon, 05 May 2014 14:30:23 +0000 Message-ID: <5367A07F.4080405@alum.mit.edu> Date: Mon, 05 May 2014 10:30:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <533A22FC.7080004@nteczone.com> <5362DEF5.7060608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D2E9901@ESESSMB209.ericsson.se> <5363B12C.30106@alum.mit.edu> <536716CA.303@nteczone.com> In-Reply-To: <536716CA.303@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=1399300223; bh=eH8YlksWIjib2SG7fdz5T/30m8bRUtuLeYiQBb6ySQ8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oxKvuVHL4YnFBodc2cx90F4QYV0ZXkaH08r19ltjL+7Ic1c8VVIdQoMbOyVcd/1LA 4sIFZFiJfjb22fC8FtsJIyEr/rlKHboyKlaj/mqfwpy7//fIH1avRXc1oiSBWJL6J2 jX0Dhl3oAOXsNx7VgIb/XLWN7iwlO/hnIbFNQjoZuMNGV4topG19b3LQ1j+cMBdxZ3 nwZPskqmsr6eO8a2+HWFsRlb351uQ0tusCTCrmVUpPQPZ2LoFJhjXQKoIitBQo60tv EF1qQ/Cu4YsYa+Utta9s0QrINfx5Qbtj5dW+6rYCGy5FeM7uJamSzQdmeNySc08Idl 7Uyv7/Em0N5kw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/V-kEOk46WSDNZHpX28u4K4ezuu8 Subject: Re: [clue] Fwd: Comments Re: I-D Action: draft-ietf-clue-datachannel-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 14:30:28 -0000 Christ(er & ian), inline... On 5/5/14 12:42 AM, Christian Groves wrote: > Hello Paul and Christer, > > Please see my comments below. > > Regards, Christian > > On 3/05/2014 12:52 AM, Paul Kyzivat wrote: >> On 5/2/14 9:00 AM, Christer Holmberg wrote: >>> Hi Christian, >>> >>>> cl.3.2: The first two paragraphs need to be merged somehow. The >>>> first indicates mandatory support of DCEP, the 2nd indicates >>>> optional support of DCEP. I think the 2nd paragraph can be used as >>>> the 1st sentence of the first paragraph. >>> >>> Note that there is a difference between the mandatory SUPPORT of >>> DCEP, and the OPTIONAL use of DCEP. >>> >>> I wrote it that way in order to allow for the usage of the mechanism >>> described in "Richard's draft", if it gets ready in time for the >>> publication of the datachannel draft. > [CNG] I think you can still capture that in one paragraph: > "In the absence of another mechanism, a CLUE entity MUST support the > Data Channel Establishment Protocol(DCEP) > [I-D.ietf-rtcweb-data-channel], which can be used in order to > open a WebRTC Data Channel." That seems to say that in the *presence* of another mechanism support of DCEP is *not* required. That would either make this other, unspecified, mechanism the one that is mandatory to implement. Or, it might mean there is no mandatory to implement mechanism. IIUC the intent was that DCEP be required to *support*. Some other mechanism could be *used* if it can be determined to be supported by both ends. That requires two statements, whether in one paragraph or two. >>> However, lately I have seen zero progress of "Richard's draft", so I >>> don't know what/if the authors intend to do... Richard? Keith? > >>> >>>> cl.3.3.2: With respect to the note. It says partial reliability is >>>> not needed for CLUE and the reason. The part on >>>> limited retransmission is vague. It doesn't say CLUE doesn't use it >>>> nor the reason. (yes I know the paragraph >>>> above rules it out). >>> >>> Ok, maybe some extra text is needed. >>> >>>> cl.3.3.4: The extension defined by RFC6525 is "STCP Stream >>>> Reconfiguration". It has more than just "reset" procedures, e.g. >>>> adding streams, rec-configuration streams. We may want to be a bit >>>> more precise here to avoid any confusion that only the >>>> reset procedures are supported. >>> >>> As far as I know, we DO only need the reset procedures. As far as I >>> know, the general data channel framework doesn't require anything >>> else either, but I may be wrong. >> >> That is my understanding too. But I doubt we want to go into details >> about this, or try to respecify the normative requirements. If we >> specify the dependency on the DCEP draft, then we inherit the >> requirements it pulls in. > [CNG] The problem is for this we don't specify the dependency and we > only partially normatively say how stream reset is used. If you want to > defer to the data channel draft then all we'd need to say is "A CLUE > entity MUST support RFC6525 and RFC5061 according to > [I-D.ietf-rtcweb-data-channel]. That would work for me. I do have a problem with "Other features of [RFC5061] MUST NOT be used." For one thing, it is in the section on Stream Reset. Does this mean the other features MUST NOT be used for resetting streams? Or that they must not be used at all? It is entirely possible that an implementation will use the same SCTP session for the clue channel and some other channels. It may use other features of 5061 in conjunction with some of those other channels. It is even possible that it will first use the SCTP session for other channels, and then eventually want to enable clue. It may decide it needs to adjust the max number of channels before creating the clue channel with DCEP. That should not be forbidden. Bottom line - I would like to see the statement "Other features of [RFC5061] MUST NOT be used." removed. Thanks, Paul From nobody Mon May 5 08:40: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 266AB1A03CC for ; Mon, 5 May 2014 08:40:17 -0700 (PDT) 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 6z8h1_PU_bFt for ; Mon, 5 May 2014 08:40:16 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFF01A03C9 for ; Mon, 5 May 2014 08:40:16 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta04.westchester.pa.mail.comcast.net with comcast id yEWW1n0051ZXKqc54FgCJi; Mon, 05 May 2014 15:40:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id yFgC1n00M3ZTu2S3hFgCMJ; Mon, 05 May 2014 15:40:12 +0000 Message-ID: <5367B0DC.9090509@alum.mit.edu> Date: Mon, 05 May 2014 11:40:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: CLUE , John Leslie , Stephen Botzko 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=1399304412; bh=w7QvOvyUUIfydZMND7iY50JbDmVP1+2FXmXr/vDlJeg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tRdDO6R79zLcI1FfmW8KJP7IjgqPlpirfvlTPN+NpQpDoOrn54imSfeiW3d8dG7Zy dchYaK+E7fwVT7wPCwUe/MZyH731a00agIJbX6OsnI2HCjrIDW+vUg5hIfmXZTbDGw qdmL9OHeMtArn5HlfCiPZSo1FVoOgb0wTnyzjgshbz22USiDPlLowKDTz5w0kh806O WW85tLiV4pHztmSBxG/EOasNtlxmwqePi9nygZc2BrlH3XfiQI0A1jvQ9JvhKnIr7e ePRKjBDsmbA2Ozj/To4/UX50hjC4/u9XqulUoE/6WXqvpUy9SmLmXFAsYe9g4rrcgR Z6qgH9VtX/x9Q== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/NzJzUdfEofq_R9e5r7wN_7QvJCk Subject: [clue] Design Team meetings this week and next X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 05 May 2014 15:40:17 -0000 We have no topic scheduled for the design team meeting tomorrow (6-may), so we won't hold that one. This does NOT mean you get the week off! We had productive sessions on signaling and protocol in past weeks. Authors, please use this "free" time to get out new versions of those documents reflecting decisions made. The purpose of the meeting next week (13-may) is to thrash out the audio issues that we've been discussing on the mailing list for some time. There has been a lot of heat, but it is unclear to me how much light. Please come to that meeting prepared to make decisions. We need *text*. The meeting is not the best place to *create* text, so please post proposed text to the list prior to the meeting. And if you have an opinion on this that please be present on 13-may for the call! If any of the active parties won't be able to be there please inform us now! Thanks, Paul From nobody Tue May 6 14:22:52 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F441A0453 for ; Tue, 6 May 2014 14:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 m1EGODBD0jrY for ; Tue, 6 May 2014 14:22:46 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.10]) by ietfa.amsl.com (Postfix) with ESMTP id BEE371A03A8 for ; Tue, 6 May 2014 14:22:46 -0700 (PDT) Received: from [216.82.249.212:45926] by server-10.bemta-12.messagelabs.com id F0/7C-19574-2A259635; Tue, 06 May 2014 21:22:42 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-4.tower-219.messagelabs.com!1399411355!990582!11 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15977 invoked from network); 6 May 2014 21:22:42 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-4.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 6 May 2014 21:22:42 -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, 6 May 2014 14:22:32 -0700 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.94]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 6 May 2014 14:22:32 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 6 May 2014 14:22:29 -0700 Thread-Topic: voice activated switching example for the Framework Thread-Index: Ac9pb63cj0gTvST0Rg+ip+WCewFXhw== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F13E179@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/X_6-4UMWHVA1xVamtMmvOsPf3tA Subject: [clue] voice activated switching example for the Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 21:22:48 -0000 I had an action item from IETF89 to add an example to the Framework to show= how an MCU can implement "voice activated switching" with endpoints that s= end multiple video streams, so the MCU can choose one to send to a simple e= ndpoint that receives only one video stream. To do this, we want to use a = switched MCC from the multi-camera endpoints to the MCU to carry the active= talker video from each endpoint. This example also addresses, at least in some cases, the issue Steve brough= t up about cases where "talker identification does not work". http://www.i= etf.org/mail-archive/web/clue/current/msg03733.html Here is my proposed text to add to the Framework, in the Examples (Informat= ive) section: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D begin proposed text =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 12.3.4. Heterogeneous conference with voice activated switching This example illustrates how multipoint "voice activated switching" behavio= r can be realized, with an endpoint making its own decision about which of = its outgoing video streams is considered the "active talker" from that endp= oint. Then an MCU can decide which is the active talker among the whole co= nference. Consider a conference between endpoints with the following characteristics: Endpoint A - 3 screens, 3 cameras Endpoint B - 3 screens, 3 cameras Endpoint C - 1 screen, 1 cameras This example focuses on what the user at endpoint C sees. The user would l= ike to see the video capture of the current talker, without composing it wi= th any other video capture. In this example endpoint C is capable of recei= ving only a single video stream. The following tables describe advertiseme= nts from A and B to the MCU, and from the MCU to C, that can be used to acc= omplish this. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=3DEndpoint x | +-----------------------|---------------------------------+ | VC1 | CaptureArea=3DLeft | | | EncodingGroup=3D1 | | VC2 | CaptureArea=3DCenter | | | EncodingGroup=3D1 | | VC3 | CaptureArea=3DRight | | | EncodingGroup=3D1 | | MCC1(VC1,VC2,VC3) | MaxCaptures=3D1 | | | CaptureArea=3Dwhole scene | | | Policy=3DSoundLevel:0 | | | EncodingGroup=3D1 | | AC1 | CaptureArea=3Dwhole scene | | | EncodingGroup=3D2 | | CSE1(VC1, VC2, VC3) | | | CSE2(MCC1) | | | CSE3(AC1) | | +---------------------------------------------------------+ Table 25: Advertisement received at the MCU from Endpoints A and B Endpoints A and B are advertising each individual video capture, and also a= switched capture MCC1 which switches between the other three based on who = is the active talker. These endpoints do not advertise distinct audio capt= ures associated with each individual video capture, so it would be impossib= le for the MCU (as a media consumer) to make its own determination of which= video capture is the active talker based just on information in the audio = streams. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=3Dconference | +-----------------------|---------------------------------+ | MCC1() | CaptureArea=3DLeft | | | MaxCaptures=3D1 | | | SynchronisationID=3D1 | | | Policy=3DSoundLevel:0 | | | EncodingGroup=3D1 | | | | | MCC2() | CaptureArea=3DCenter | | | MaxCaptures=3D1 | | | SynchronisationID=3D1 | | | Policy=3DSoundLevel:0 | | | EncodingGroup=3D1 | | | | | MCC3() | CaptureArea=3DRight | | | MaxCaptures=3D1 | | | SynchronisationID=3D1 | | | Policy=3DSoundLevel:0 | | | EncodingGroup=3D1 | | | | | MCC4() | CaptureArea=3Dwhole scene | | | MaxCaptures=3D1 | | | Policy=3DSoundLevel:0 | | | EncodingGroup=3D1 | | | | | MCC5() (for audio) | CaptureArea=3Dwhole scene | | | MaxCaptures=3D1 | | | Policy=3DSoundLevel:0 | | | EncodingGroup=3D2 | | | | | MCC6() (for audio) | CaptureArea=3Dwhole scene | | | MaxCaptures=3D1 | | | Policy=3DSoundLevel:1 | | | EncodingGroup=3D2 | | CSE1(MCC1,MCC2,MCC3 | | | CSE2(MCC4) | | | CSE3(MCC5,MCC6) | | +---------------------------------------------------------+ Table 26: Advertisement sent from the MCU to C The MCU advertises one scene, with four video MCCs. Three of them in CSE1 = give a left, center, right view of the conference, with "site switching". M= CC4 provides a single video capture representing a view of the whole confer= ence, which is simply switched between all the other original source captur= es. Endpoint C, in its configure message to the MCU, requests to receive MCC4. = In order for the MCU to get the information it needs to construct MCC4, it= has to send configure messages to A and B asking to receive MCC1 from each= of them, along with their AC1 audio. Now the MCU can use audio energy inf= ormation from the two incoming audio streams from A and B to determine whic= h of those alternatives is the current talker. Based on that, the MCU uses= either MCC1 from A or MCC1 from B as the source of MCC4 to send to C. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D end proposed text =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Tue May 6 19:40: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 6BDB51A0479 for ; Tue, 6 May 2014 19:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 cz5u9xM21Fij for ; Tue, 6 May 2014 19:40:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED741A0415 for ; Tue, 6 May 2014 19:40:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDW90573; Wed, 07 May 2014 02:40:40 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 7 May 2014 03:39:23 +0100 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 7 May 2014 03:40:39 +0100 Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.101]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Wed, 7 May 2014 10:40:36 +0800 From: "Liuyan (Scarlett)" To: Christer Holmberg Thread-Topic: [clue] I-D Action: draft-ietf-clue-datachannel-00.txt Thread-Index: AQHPRQ97PHUe7FvzBkizuTpLinQvRZs0rsAw Date: Wed, 7 May 2014 02:40:35 +0000 Message-ID: References: <20140321141121.16330.32657.idtracker@ietfa.amsl.com> In-Reply-To: <20140321141121.16330.32657.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.137.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3OR9-IEiraCd9Xa2ruqhfgRJmJ4 Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-datachannel-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 02:40:48 -0000 Hi Christer, I notice that there is a typo in section 5.6 of draft-ietf-clue-datacha= nnel-00 below: 5.6. Example m=3Dapplication 54111 SCTP/DTLS 54111 a=3Dsctpmap:54111 webrtc-datachannel Figure 1: SDP Media Description for a CLUE Data Channel =20 As described in section 3 of draft-ietf-mmusic-sctp-sdp-06 below: The 'SCTP/DTLS' protocol identifier indicates that the media described will use the Datagram Transport Layer Security (DTLS) [RFC4347] over SCTP as specified in [RFC6083]. The 'DTLS/SCTP' protocol identifier indicates that the media described will use SCTP on top of the Datagram Transport Layer Security (DTLS) protocol as specified in [I-D.tuexen-tsvwg-sctp-dtls-encaps]. The actual layer below DTLS can be plain UDP or what ICE agrees on (in the case ICE is used to negotiate the actual transport flow). The lower layer used is identified from the elements present inside the m=3D line block. so it should be reworded below: 5.6. Example m=3Dapplication 54111 DTLS/SCTP 54111 a=3Dsctpmap:54111 webrtc-datachannel Figure 1: SDP Media Description for a CLUE Data Channel Best Regards, Scarlett =20 -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, March 21, 2014 10:11 PM To: i-d-announce@ietf.org Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : CLUE Protocol Data Channel Author : Christer Holmberg Filename : draft-ietf-clue-datachannel-00.txt Pages : 12 Date : 2014-03-20 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-00 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/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Wed May 7 03: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 5AD941A049D for ; Wed, 7 May 2014 03:00:15 -0700 (PDT) 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_111=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnezG6H_tqF2 for ; Wed, 7 May 2014 03:00:12 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D85C81A0462 for ; Wed, 7 May 2014 03:00:11 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-cb-536a0426de4b Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.E2.04199.6240A635; Wed, 7 May 2014 12:00:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Wed, 7 May 2014 12:00:06 +0200 From: Christer Holmberg To: "Liuyan (Scarlett)" Thread-Topic: [clue] I-D Action: draft-ietf-clue-datachannel-00.txt Thread-Index: AQHPRQ9uXRrtGgMNuEWP2p9HE+Z6eZs0j8uAgACcP4A= Date: Wed, 7 May 2014 10:00:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2EFC38@ESESSMB209.ericsson.se> References: <20140321141121.16330.32657.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja46S1awweJefov9py4zWxx80cLk wOTRcuQtq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIOvj7BWLBJumLu5CVMDYxrRLsYOTgkBEwk /v+K7WLkBDLFJC7cW8/WxcjFISRwlFHi+tRdTBDOYkaJWQ2XmUEa2AQsJLr/aYM0iAD1Hpn6 lhXEZhZQlvjasIkJxBYWcJKYPPM0C0SNs8S0/z/ZIGwriQVzHjGBjGERUJHYuS4bJMwr4Cux cvVaZohVvYwST/6uBevlFAiTmHBjITOIzQh03PdTa5ggdolL3HoynwniaAGJJXvOM0PYohIv H/9jhbAVJXaebWeGqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUB I8sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMDoObjlt8EOxpfPHQ8xCnAwKvHwPnyVESzE mlhWXJl7iFGag0VJnPfbWfdgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwTd4RvnaW+tMzk jv4TXobNp93WF+w5/X/vmolvm7ne9C2+uSSqg38/z4+G6ZuzPGp9j5itnfdSheNTyue6ataC M0XfOtS11U74GvowTXLr/Nql+Xzfo23LTt1kDNhxe9ufu3ecZjd/85Up2rHPPG1S1yapmxdK b9fs8/8131Q4QWeKxdtfzAF6SizFGYmGWsxFxYkA6pPC1H8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/HeptMZrLqyr7oA3j1dSwk5nszVU Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-datachannel-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 10:00:15 -0000 Hi Scarlett, Thanks for spotting the typo! :) Regards, Christer -----Original Message----- From: Liuyan (Scarlett) [mailto:scarlett.liuyan@huawei.com]=20 Sent: 7. toukokuuta 2014 5:41 To: Christer Holmberg Cc: clue@ietf.org Subject: RE: [clue] I-D Action: draft-ietf-clue-datachannel-00.txt Hi Christer, I notice that there is a typo in section 5.6 of draft-ietf-clue-datacha= nnel-00 below: 5.6. Example m=3Dapplication 54111 SCTP/DTLS 54111 a=3Dsctpmap:54111 webrtc-datachannel Figure 1: SDP Media Description for a CLUE Data Channel =20 As described in section 3 of draft-ietf-mmusic-sctp-sdp-06 below: The 'SCTP/DTLS' protocol identifier indicates that the media described will use the Datagram Transport Layer Security (DTLS) [RFC4347] over SCTP as specified in [RFC6083]. The 'DTLS/SCTP' protocol identifier indicates that the media described will use SCTP on top of the Datagram Transport Layer Security (DTLS) protocol as specified in [I-D.tuexen-tsvwg-sctp-dtls-encaps]. The actual layer below DTLS can be plain UDP or what ICE agrees on (in the case ICE is used to negotiate the actual transport flow). The lower layer used is identified from the elements present inside the m=3D line block. so it should be reworded below: 5.6. Example m=3Dapplication 54111 DTLS/SCTP 54111 a=3Dsctpmap:54111 webrtc-datachannel Figure 1: SDP Media Description for a CLUE Data Channel Best Regards, Scarlett =20 -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, March 21, 2014 10:11 PM To: i-d-announce@ietf.org Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : CLUE Protocol Data Channel Author : Christer Holmberg Filename : draft-ietf-clue-datachannel-00.txt Pages : 12 Date : 2014-03-20 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-00 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/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Wed May 7 12:09: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 F15CC1A02E8 for ; Wed, 7 May 2014 12:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 9xMsyubMZOlo for ; Wed, 7 May 2014 12:09:01 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.107]) by ietfa.amsl.com (Postfix) with ESMTP id 47F471A02A8 for ; Wed, 7 May 2014 12:09:01 -0700 (PDT) Received: from [216.82.254.20:15440] by server-11.bemta-7.messagelabs.com id 04/4E-21432-8C48A635; Wed, 07 May 2014 19:08:56 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-15.tower-47.messagelabs.com!1399489735!2655490!4 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2604 invoked from network); 7 May 2014 19:08:56 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-15.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 7 May 2014 19:08:56 -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, 7 May 2014 12:07:54 -0700 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.94]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Wed, 7 May 2014 12:07:53 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , CLUE , John Leslie , Stephen Botzko Date: Wed, 7 May 2014 12:07:51 -0700 Thread-Topic: [clue] Design Team meetings this week and next Thread-Index: Ac9oeGyW3QxWpWXlRwq3EDVrzC5f6wBrajWA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F13E2D6@CRPMBOXPRD08.polycom.com> References: <5367B0DC.9090509@alum.mit.edu> In-Reply-To: <5367B0DC.9090509@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/SUBXpetg-JtOhrmnJiAkSLG929U Subject: Re: [clue] Design Team meetings this week and next X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2014 19:09:03 -0000 Hello Paul, Regarding the meeting next week to discuss audio issues, I don't have any p= roposed text to post because I think the existing framework and data model = are adequate as is. However, I am interested in any other proposals people= have about associating audio with video without using the area of capture = for audio. I'd like to understand the use cases and motivation for such pr= oposals - I think I'm still missing that. Even without using area of captu= re, CLUE still associates audio with video when they are in the same CLUE s= cene. If there is a need and for more fine grained association within a sc= ene, that's what I don't understand. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, May 05, 2014 11:40 AM > To: CLUE; John Leslie; Stephen Botzko > Subject: [clue] Design Team meetings this week and next >=20 > We have no topic scheduled for the design team meeting tomorrow (6-may), > so we won't hold that one. >=20 > This does NOT mean you get the week off! >=20 > We had productive sessions on signaling and protocol in past weeks. > Authors, please use this "free" time to get out new versions of those > documents reflecting decisions made. >=20 > The purpose of the meeting next week (13-may) is to thrash out the audio > issues that we've been discussing on the mailing list for some time. > There has been a lot of heat, but it is unclear to me how much light. > Please come to that meeting prepared to make decisions. We need *text*. > The meeting is not the best place to *create* text, so please post propos= ed > text to the list prior to the meeting. >=20 > And if you have an opinion on this that please be present on 13-may for t= he > call! If any of the active parties won't be able to be there please infor= m us > now! >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed May 7 12:54: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 21F6B1A0366 for ; Wed, 7 May 2014 12:54:07 -0700 (PDT) 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 uF8JhvzV2Eib for ; Wed, 7 May 2014 12:54:04 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BAA121A02F5 for ; Wed, 7 May 2014 12:54:04 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id jw12so1949925veb.6 for ; Wed, 07 May 2014 12:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4UE17D9ovQyum4VCcNfK8IxqJzgqq5xoFQzwO6SdMsU=; b=gf0r5UsiH47y+ryJqo7YUC7wE6cTTSU9ERK19m9StgtVz3avJRvGtcQTVgcshzQmCa QKdKXuNh0sj5ztAjbn7sbgNRNJu+CExee06uHKBVyoOCHN98b2O5cnXGn8psaOVDLZN1 Det4hGxeCbFpmPPKfQk4C0M0I5hpAS9b5esXdscKFf5oBao3yi3A7RN9J9F2tuk2uA8n CrVUASaZprXAMG/rv5Ng1O1I9bcfEdzmaSI3EGub+/4Rp8RQsSQ3exW859gsoWWvUfh4 lMJTsQO9hVBjvWXhOfb6isW7Y1/oV+WGmJ0Ggx28kGAOPOOiEbEpPqe4V56WAueoQpOO tkBw== MIME-Version: 1.0 X-Received: by 10.52.139.101 with SMTP id qx5mr9537035vdb.17.1399492440404; Wed, 07 May 2014 12:54:00 -0700 (PDT) Received: by 10.221.40.135 with HTTP; Wed, 7 May 2014 12:54:00 -0700 (PDT) In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F13E2D6@CRPMBOXPRD08.polycom.com> References: <5367B0DC.9090509@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F13E2D6@CRPMBOXPRD08.polycom.com> Date: Wed, 7 May 2014 15:54:00 -0400 Message-ID: From: Stephen Botzko To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=bcaec51a8bd2c6b7ae04f8d4b92a Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ayHLEfhold8HNKwz0vwbvixF1f4 Cc: CLUE Subject: Re: [clue] Design Team meetings this week and next X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 07 May 2014 19:54:07 -0000 --bcaec51a8bd2c6b7ae04f8d4b92a Content-Type: text/plain; charset=UTF-8 I also feel that the framework is adequate, and that all we really need to do is solve is the talker identification use. It would be helpful to talk through the motivations behind any alternatives before we jump to text. /BR Stephen On Wed, May 7, 2014 at 3:07 PM, Duckworth, Mark wrote: > Hello Paul, > Regarding the meeting next week to discuss audio issues, I don't have any > proposed text to post because I think the existing framework and data model > are adequate as is. However, I am interested in any other proposals people > have about associating audio with video without using the area of capture > for audio. I'd like to understand the use cases and motivation for such > proposals - I think I'm still missing that. Even without using area of > capture, CLUE still associates audio with video when they are in the same > CLUE scene. If there is a need and for more fine grained association > within a scene, that's what I don't understand. > > Mark > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Monday, May 05, 2014 11:40 AM > > To: CLUE; John Leslie; Stephen Botzko > > Subject: [clue] Design Team meetings this week and next > > > > We have no topic scheduled for the design team meeting tomorrow (6-may), > > so we won't hold that one. > > > > This does NOT mean you get the week off! > > > > We had productive sessions on signaling and protocol in past weeks. > > Authors, please use this "free" time to get out new versions of those > > documents reflecting decisions made. > > > > The purpose of the meeting next week (13-may) is to thrash out the audio > > issues that we've been discussing on the mailing list for some time. > > There has been a lot of heat, but it is unclear to me how much light. > > Please come to that meeting prepared to make decisions. We need *text*. > > The meeting is not the best place to *create* text, so please post > proposed > > text to the list prior to the meeting. > > > > And if you have an opinion on this that please be present on 13-may for > the > > call! If any of the active parties won't be able to be there please > inform us > > now! > > > > Thanks, > > Paul > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > --bcaec51a8bd2c6b7ae04f8d4b92a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also feel that the framework is adequate, and = that all we really need to do is solve is the talker identification use.
It would be helpful to talk through the motivations behind any a= lternatives before we jump to text.

/BR
Stephen


On Wed, May 7, 2014 at 3:07 PM, Duckworth, Mark <Mark.Duckworth@polycom.com> wrote:
Hello Paul,
Regarding the meeting next week to discuss audio issues, I don't have a= ny proposed text to post because I think the existing framework and data mo= del are adequate as is. =C2=A0However, I am interested in any other proposa= ls people have about associating audio with video without using the area of= capture for audio. =C2=A0I'd like to understand the use cases and moti= vation for such proposals - I think I'm still missing that. =C2=A0Even = without using area of capture, CLUE still associates audio with video when = they are in the same CLUE scene. =C2=A0If there is a need and for more fine= grained association within a scene, that's what I don't understand= .

Mark

> -----Original Message-----
> From: clue [mailto:clue-bounc= es@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Monday, May 05, 2014 11:40 AM
> To: CLUE; John Leslie; Stephen Botzko
> Subject: [clue] Design Team meetings this week and next
>
> We have no topic scheduled for the design team meeting tomorrow (6-may= ),
> so we won't hold that one.
>
> This does NOT mean you get the week off!
>
> We had productive sessions on signaling and protocol in past weeks. > Authors, please use this "free" time to get out new versions= of those
> documents reflecting decisions made.
>
> The purpose of the meeting next week (13-may) is to thrash out the aud= io
> issues that we've been discussing on the mailing list for some tim= e.
> There has been a lot of heat, but it is unclear to me how much light.<= br> > Please come to that meeting prepared to make decisions. We need *text*= .
> The meeting is not the best place to *create* text, so please post pro= posed
> text to the list prior to the meeting.
>
> And if you have an opinion on this that please be present on 13-may fo= r the
> call! If any of the active parties won't be able to be there pleas= e inform us
> now!
>
> =C2=A0 =C2=A0 =C2=A0 Thanks,
> =C2=A0 =C2=A0 =C2=A0 Paul
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

--bcaec51a8bd2c6b7ae04f8d4b92a-- From nobody Thu May 8 09:18: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 4F5D01A009C for ; Thu, 8 May 2014 09:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.989 X-Spam-Level: X-Spam-Status: No, score=-3.989 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, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 rUY9IXaFBdod for ; Thu, 8 May 2014 09:18:01 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4A1A007B for ; Thu, 8 May 2014 09:18:00 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a1so2751146wgh.27 for ; Thu, 08 May 2014 09:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HQUGS2kqZrJYS/a3gZwNdL8jn7YaVrxNJkLCrwP7fUY=; b=IgFZa+YF8FF34Epj6auW4YDKLcWx98u4qLjlTE5E4HQk0w80v93yNeCnc34brrIyPK +2fJlyCE0ff4hUGk7f+7X0JAbaxr3hW/BpeIhQyHgxl1QlUaM9uMkPBDHyx6a3HDu1Fa qmlYsXrSaDdR38UWOsPTrXjHLIjJlxjM9c0pW9V6qczAU7zNij3BX4KgMOyKc6PnU7uA kOmCBnBmzMctHy/iXNdP+Y6ABXlGvGU8UUL3Ca5TrofHy7j9mudL1oTP4eIWz0ARKZJH 50W6lLYSd8EVXlMpLjOiB2gcVFzZztZRcKJm4MmL79vGGT6mbeUFn+uIOyK7GFrSyesT HFsQ== MIME-Version: 1.0 X-Received: by 10.180.97.10 with SMTP id dw10mr13894564wib.38.1399565875994; Thu, 08 May 2014 09:17:55 -0700 (PDT) Received: by 10.216.93.68 with HTTP; Thu, 8 May 2014 09:17:55 -0700 (PDT) Date: Thu, 8 May 2014 11:17:55 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0443064ee0e4da04f8e5d2dc Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xa3HAdgD-vv4mfPVPFoCqvfU2vA Subject: [clue] Meeting invitation: CLUE WG Virtual Interim on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 16:18:03 -0000 --f46d0443064ee0e4da04f8e5d2dc Content-Type: text/plain; charset=UTF-8 Below please find the details for the CLUE WG virtual interim meeting scheduled for May 29, 2014 (15:00-17:00 Central US). A preliminary agenda is on the wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140529 Regards, Mary. ---------- Forwarded message ---------- From: Clue Working Group Date: Thu, May 8, 2014 at 11:06 AM Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim To: clue-chairs@tools.ietf.org **** You can forward this email invitation to attendees **** Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG Virtual Interim Date: Thursday, May 29, 2014 Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 640 349 010 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=m6504f06c147f1aa7d8aadafe1093cffa 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=m4e5260b422e7fbc58daf046157c0f133 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:640 349 010 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=m30b4368d59ceb34681d5abd7e037cc6d The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x640349010# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --f46d0443064ee0e4da04f8e5d2dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Below please find the details for the CLUE WG virtual inte= rim meeting scheduled for May 29, 2014 (15:00-17:00 Central US).

A preliminary agenda is on the wiki:=C2=A0

Regards,
Mary.

---------- Forwarded message ----------
From: Clue Working Group <messenger@webex.com>
Date: Thu, May 8, 2014 at 11:06 AM
Subject: (Forward to attendees) Meeti= ng invitation: CLUE WG Virtual Interim
To: clue-chairs@tools.ietf.org



**** You can forward this email invitation to attendees ****

Hel= lo ,

Clue Working Group invites you to attend this online meeting= .

Topic: CLUE WG Virtual Interim
Date: Thursday, May 29, 201= 4
Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00)
Meeting Num= ber: 640 349 010
Meeting Password: 1234


---------------= ----------------------------------------
To join the online meeting (N= ow from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06= c147f1aa7d8aadafe1093cffa
2. If requested, enter your name and email address.
3. If a password = is required, enter the meeting password: 1234
4. Click "Join"= ;.

To view in other time zones or languages, please click the lin= k:
https://ietf.webex.com/ietf/j.php?MTID=3Dm4e= 5260b422e7fbc58daf046157c0f133

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

Access code:640 349 010

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

You ca= n contact me at:
clue-chairs@tools.ietf.org


To add this meeti= ng to your calendar program (for example Microsoft Outlook), click this lin= k:
https://ietf.webex.com/ietf/j.php?MTID=3Dm30= b4368d59ceb34681d5abd7e037cc6d

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

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial=

http://ww= w.webex.com

CCP:+16504793208x640349010#

IMPORTANT NOTICE: This WebEx se= rvice includes a feature that allows audio and any documents and other mate= rials exchanged or viewed during the session to be recorded. By joining thi= s session, you automatically consent to such recordings. If you do not cons= ent to the recording, discuss your concerns with the meeting host prior to = the start of the recording or do not join the session. Please note that any= such recordings may be subject to discovery in the event of litigation.

--f46d0443064ee0e4da04f8e5d2dc-- From nobody Thu May 8 10:48: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 3AC631A00A8 for ; Thu, 8 May 2014 10:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.89 X-Spam-Level: X-Spam-Status: No, score=-3.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 rBSb9WHj9l6R for ; Thu, 8 May 2014 10:48:13 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id 59CC11A0078 for ; Thu, 8 May 2014 10:48:12 -0700 (PDT) X-AuditID: c1b4fb3a-f79a86d0000010e9-c9-536bc3572359 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 50.2D.04329.753CB635; Thu, 8 May 2014 19:48:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Thu, 8 May 2014 19:48:06 +0200 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] Meeting invitation: CLUE WG Virtual Interim on May 29, 2014 Thread-Index: AQHPatkWg518GAUxHESPJ3tDYLXHRps29ZjA Date: Thu, 8 May 2014 17:48:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2F21D8@ESESSMB209.ericsson.se> References: 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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2F21D8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW744exgg69nBSz2n7rMbPF5/35m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj89MGloJ39RXv/k9ib2DcUtPFyMkhIWAi MbvjNBOELSZx4d56ti5GLg4hgaOMErNOrmKFcBYzSiz9vgOoioODTcBCovufNkiDiICTxIWX 71lAbGGBQIlzs38xQcSDJNZsXMIOUi4iYCSx/W8qSJhFQEXi29V/rCA2r4CvxLnnt9lAbCGB AIlFJ/rA4pxAYxZOXscMYjMC3fP91BqwkcwC4hK3nsyHulNAYsme88wQtqjEy8cQMyUElCQa lzxhhajPlziw6x4zxC5BiZMzn7BMYBSZhWTULCRls5CUzQK6mllAU2L9Ln2IEkWJKd0P2SFs DYnWOXPZkcUXMLKvYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMqYNbflvtYDz43PEQowAH oxIP78KSrGAh1sSy4srcQ4zSHCxK4ryTFrkHCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCU tTV76vd1idyD4mfMH+xmsCzTVK6edUlJS1lJ8MXTA3PZlW6V66SIzy/x1DA4rmYx3Tmo/k3r Sa1s6X/eStVGdTs2zdy+X3BG/aPF3byGYhdnTIu8MIVjhrqtk/KdqVd3/Lm6te/16c+fw41F LS+9MFfI3iRfZhXyxmvi+5VCZ/V+1G1RO8WtxFKckWioxVxUnAgA4IT0wooCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5hfyzxZC5Suprm_7FSZqBoAF9wc Subject: Re: [clue] Meeting invitation: CLUE WG Virtual Interim on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:48:18 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2F21D8ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcV3JhcHVwICYgUGxhbnMgZm9yIExvbmRvbiAoNSBtaW4p4oCdDQoNCkkgYXNzdW1lIHlvdSBt ZWFuIFRvcm9udG8gOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogY2x1ZSBbbWFp bHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnkgQmFybmVzDQpTZW50 OiAwOCBNYXkgMjAxNCAxOToxOA0KVG86IENMVUUNClN1YmplY3Q6IFtjbHVlXSBNZWV0aW5nIGlu dml0YXRpb246IENMVUUgV0cgVmlydHVhbCBJbnRlcmltIG9uIE1heSAyOSwgMjAxNA0KDQpCZWxv dyBwbGVhc2UgZmluZCB0aGUgZGV0YWlscyBmb3IgdGhlIENMVUUgV0cgdmlydHVhbCBpbnRlcmlt IG1lZXRpbmcgc2NoZWR1bGVkIGZvciBNYXkgMjksIDIwMTQgKDE1OjAwLTE3OjAwIENlbnRyYWwg VVMpLg0KDQpBIHByZWxpbWluYXJ5IGFnZW5kYSBpcyBvbiB0aGUgd2lraToNCmh0dHA6Ly90cmFj LnRvb2xzLmlldGYub3JnL3dnL2NsdWUvdHJhYy93aWtpL2ludGVyaW0xNDA1MjkNCg0KUmVnYXJk cywNCk1hcnkuDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206 IENsdWUgV29ya2luZyBHcm91cCA8bWVzc2VuZ2VyQHdlYmV4LmNvbTxtYWlsdG86bWVzc2VuZ2Vy QHdlYmV4LmNvbT4+DQpEYXRlOiBUaHUsIE1heSA4LCAyMDE0IGF0IDExOjA2IEFNDQpTdWJqZWN0 OiAoRm9yd2FyZCB0byBhdHRlbmRlZXMpIE1lZXRpbmcgaW52aXRhdGlvbjogQ0xVRSBXRyBWaXJ0 dWFsIEludGVyaW0NClRvOiBjbHVlLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86Y2x1ZS1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQoNCg0KDQoqKioqIFlvdSBjYW4gZm9yd2FyZCB0aGlzIGVt YWlsIGludml0YXRpb24gdG8gYXR0ZW5kZWVzICoqKioNCg0KSGVsbG8gLA0KDQpDbHVlIFdvcmtp bmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gYXR0ZW5kIHRoaXMgb25saW5lIG1lZXRpbmcuDQoNClRv cGljOiBDTFVFIFdHIFZpcnR1YWwgSW50ZXJpbQ0KRGF0ZTogVGh1cnNkYXksIE1heSAyOSwgMjAx NA0KVGltZTogMzowMCBwbSwgQ2VudHJhbCBEYXlsaWdodCBUaW1lIChDaGljYWdvLCBHTVQtMDU6 MDApDQpNZWV0aW5nIE51bWJlcjogNjQwIDM0OSAwMTANCk1lZXRpbmcgUGFzc3dvcmQ6IDEyMzQN Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpUbyBqb2luIHRoZSBvbmxpbmUgbWVldGluZyAoTm93IGZyb20gbW9iaWxlIGRldmljZXMh KQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KMS4gR28gdG8gaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTY1MDRm MDZjMTQ3ZjFhYTdkOGFhZGFmZTEwOTNjZmZhDQoyLiBJZiByZXF1ZXN0ZWQsIGVudGVyIHlvdXIg bmFtZSBhbmQgZW1haWwgYWRkcmVzcy4NCjMuIElmIGEgcGFzc3dvcmQgaXMgcmVxdWlyZWQsIGVu dGVyIHRoZSBtZWV0aW5nIHBhc3N3b3JkOiAxMjM0DQo0LiBDbGljayAiSm9pbiIuDQoNClRvIHZp ZXcgaW4gb3RoZXIgdGltZSB6b25lcyBvciBsYW5ndWFnZXMsIHBsZWFzZSBjbGljayB0aGUgbGlu azoNCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW00ZTUyNjBiNDIyZTdm YmM1OGRhZjA0NjE1N2MwZjEzMw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUbyBqb2luIHRoZSBhdWRpbyBjb25mZXJlbmNlIG9ubHkN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CkNhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk6IDEtNjUwLTQ3OS0zMjA4PHRlbDoxLTY1 MC00NzktMzIwOD4NCg0KQWNjZXNzIGNvZGU6NjQwIDM0OSAwMTANCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRm9yIGFzc2lzdGFuY2UN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CjEuIEdvIHRvIGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYw0KMi4gT24gdGhlIGxlZnQg bmF2aWdhdGlvbiBiYXIsIGNsaWNrICJTdXBwb3J0Ii4NCg0KWW91IGNhbiBjb250YWN0IG1lIGF0 Og0KY2x1ZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmNsdWUtY2hhaXJzQHRvb2xzLmll dGYub3JnPg0KDQoNClRvIGFkZCB0aGlzIG1lZXRpbmcgdG8geW91ciBjYWxlbmRhciBwcm9ncmFt IChmb3IgZXhhbXBsZSBNaWNyb3NvZnQgT3V0bG9vayksIGNsaWNrIHRoaXMgbGluazoNCmh0dHBz Oi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0zMGI0MzY4ZDU5Y2ViMzQ2ODFkNWFi ZDdlMDM3Y2M2ZA0KDQpUaGUgcGxheWJhY2sgb2YgVUNGIChVbml2ZXJzYWwgQ29tbXVuaWNhdGlv bnMgRm9ybWF0KSByaWNoIG1lZGlhIGZpbGVzIHJlcXVpcmVzIGFwcHJvcHJpYXRlIHBsYXllcnMu IFRvIHZpZXcgdGhpcyB0eXBlIG9mIHJpY2ggbWVkaWEgZmlsZXMgaW4gdGhlIG1lZXRpbmcsIHBs ZWFzZSBjaGVjayB3aGV0aGVyIHlvdSBoYXZlIHRoZSBwbGF5ZXJzIGluc3RhbGxlZCBvbiB5b3Vy IGNvbXB1dGVyIGJ5IGdvaW5nIHRvIGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9zeXN0ZW1k aWFnbm9zaXMucGhwLg0KDQpTaWduIHVwIGZvciBhIGZyZWUgdHJpYWwgb2YgV2ViRXgNCmh0dHA6 Ly93d3cud2ViZXguY29tL2dvL21jZW1mcmVldHJpYWwNCg0KaHR0cDovL3d3dy53ZWJleC5jb20N Cg0KQ0NQOisxNjUwNDc5MzIwOHg2NDAzNDkwMTAjDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoaXMg V2ViRXggc2VydmljZSBpbmNsdWRlcyBhIGZlYXR1cmUgdGhhdCBhbGxvd3MgYXVkaW8gYW5kIGFu eSBkb2N1bWVudHMgYW5kIG90aGVyIG1hdGVyaWFscyBleGNoYW5nZWQgb3Igdmlld2VkIGR1cmlu ZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZC4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlv dSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90 IGNvbnNlbnQgdG8gdGhlIHJlY29yZGluZywgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhl IG1lZXRpbmcgaG9zdCBwcmlvciB0byB0aGUgc3RhcnQgb2YgdGhlIHJlY29yZGluZyBvciBkbyBu b3Qgam9pbiB0aGUgc2Vzc2lvbi4gUGxlYXNlIG5vdGUgdGhhdCBhbnkgc3VjaCByZWNvcmRpbmdz IG1heSBiZSBzdWJqZWN0IHRvIGRpc2NvdmVyeSBpbiB0aGUgZXZlbnQgb2YgbGl0aWdhdGlvbi4N Cg0K --_000_7594FB04B1934943A5C02806D1A2204B1D2F21D8ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+4oCcV3JhcHVwICZhbXA7IFBsYW5zIGZvciBM b25kb24gKDUgbWluKeKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBhc3N1bWUgeW91IG1lYW4gVG9yb250byA6KTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gY2x1ZSBbbWFpbHRvOmNs dWUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWFyeSBCYXJuZXM8YnI+ DQo8Yj5TZW50OjwvYj4gMDggTWF5IDIwMTQgMTk6MTg8YnI+DQo8Yj5Ubzo8L2I+IENMVUU8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW2NsdWVdIE1lZXRpbmcgaW52aXRhdGlvbjogQ0xVRSBXRyBWaXJ0 dWFsIEludGVyaW0gb24gTWF5IDI5LCAyMDE0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QmVsb3cgcGxlYXNlIGZpbmQgdGhlIGRldGFpbHMgZm9yIHRoZSBDTFVFIFdHIHZp cnR1YWwgaW50ZXJpbSBtZWV0aW5nIHNjaGVkdWxlZCBmb3IgTWF5IDI5LCAyMDE0ICgxNTowMC0x NzowMCBDZW50cmFsIFVTKS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkEgcHJlbGltaW5hcnkgYWdlbmRhIGlzIG9uIHRoZSB3aWtpOiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvY2x1ZS90cmFjL3dpa2kvaW50ZXJpbTE0MDUyOSI+ aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvY2x1ZS90cmFjL3dpa2kvaW50ZXJpbTE0MDUy OTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk1hcnkuPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLSBGb3J3YXJkZWQg bWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogPGI+Q2x1ZSBXb3JraW5nIEdyb3VwPC9iPiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1lc3NlbmdlckB3ZWJleC5jb20iPm1lc3NlbmdlckB3ZWJleC5j b208L2E+Jmd0Ozxicj4NCkRhdGU6IFRodSwgTWF5IDgsIDIwMTQgYXQgMTE6MDYgQU08YnI+DQpT dWJqZWN0OiAoRm9yd2FyZCB0byBhdHRlbmRlZXMpIE1lZXRpbmcgaW52aXRhdGlvbjogQ0xVRSBX RyBWaXJ0dWFsIEludGVyaW08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOmNsdWUtY2hhaXJzQHRv b2xzLmlldGYub3JnIj5jbHVlLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8YnI+DQo8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxicj4NCioqKiogWW91IGNhbiBmb3J3YXJkIHRoaXMgZW1haWwgaW52 aXRhdGlvbiB0byBhdHRlbmRlZXMgKioqKiA8YnI+DQo8YnI+DQpIZWxsbyAsIDxicj4NCjxicj4N CkNsdWUgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBhdHRlbmQgdGhpcyBvbmxpbmUgbWVl dGluZy4gPGJyPg0KPGJyPg0KVG9waWM6IENMVUUgV0cgVmlydHVhbCBJbnRlcmltIDxicj4NCkRh dGU6IFRodXJzZGF5LCBNYXkgMjksIDIwMTQgPGJyPg0KVGltZTogMzowMCBwbSwgQ2VudHJhbCBE YXlsaWdodCBUaW1lIChDaGljYWdvLCBHTVQtMDU6MDApIDxicj4NCk1lZXRpbmcgTnVtYmVyOiA2 NDAgMzQ5IDAxMCA8YnI+DQpNZWV0aW5nIFBhc3N3b3JkOiAxMjM0IDxicj4NCjxicj4NCjxicj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g PGJyPg0KVG8gam9pbiB0aGUgb25saW5lIG1lZXRpbmcgKE5vdyBmcm9tIG1vYmlsZSBkZXZpY2Vz ISkgPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSA8YnI+DQoxLiBHbyB0byA8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tNjUwNGYwNmMxNDdmMWFhN2Q4YWFkYWZlMTA5M2NmZmEiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW02NTA0ZjA2 YzE0N2YxYWE3ZDhhYWRhZmUxMDkzY2ZmYTwvYT4gPGJyPg0KMi4gSWYgcmVxdWVzdGVkLCBlbnRl ciB5b3VyIG5hbWUgYW5kIGVtYWlsIGFkZHJlc3MuIDxicj4NCjMuIElmIGEgcGFzc3dvcmQgaXMg cmVxdWlyZWQsIGVudGVyIHRoZSBtZWV0aW5nIHBhc3N3b3JkOiAxMjM0IDxicj4NCjQuIENsaWNr ICZxdW90O0pvaW4mcXVvdDsuIDxicj4NCjxicj4NClRvIHZpZXcgaW4gb3RoZXIgdGltZSB6b25l cyBvciBsYW5ndWFnZXMsIHBsZWFzZSBjbGljayB0aGUgbGluazogPGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTRlNTI2MGI0MjJlN2ZiYzU4ZGFm MDQ2MTU3YzBmMTMzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9bTRlNTI2MGI0MjJlN2ZiYzU4ZGFmMDQ2MTU3YzBmMTMzPC9hPg0KPGJyPg0K PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSA8YnI+DQpUbyBqb2luIHRoZSBhdWRpbyBjb25mZXJlbmNlIG9ubHkgPGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpD YWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpOiA8YSBocmVmPSJ0ZWw6MS02NTAtNDc5LTMy MDgiIHRhcmdldD0iX2JsYW5rIj4xLTY1MC00NzktMzIwODwvYT4NCjxicj4NCjxicj4NCkFjY2Vz cyBjb2RlOjY0MCAzNDkgMDEwIDxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KRm9yIGFzc2lzdGFuY2UgPGJyPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8 YnI+DQoxLiBHbyB0byA8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWM8L2E+DQo8YnI+DQoy LiBPbiB0aGUgbGVmdCBuYXZpZ2F0aW9uIGJhciwgY2xpY2sgJnF1b3Q7U3VwcG9ydCZxdW90Oy4g PGJyPg0KPGJyPg0KWW91IGNhbiBjb250YWN0IG1lIGF0OiA8YnI+DQo8YSBocmVmPSJtYWlsdG86 Y2x1ZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jbHVlLWNoYWlyc0B0 b29scy5pZXRmLm9yZzwvYT4NCjxicj4NCjxicj4NCjxicj4NClRvIGFkZCB0aGlzIG1lZXRpbmcg dG8geW91ciBjYWxlbmRhciBwcm9ncmFtIChmb3IgZXhhbXBsZSBNaWNyb3NvZnQgT3V0bG9vayks IGNsaWNrIHRoaXMgbGluazoNCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9NVElEPW0zMGI0MzY4ZDU5Y2ViMzQ2ODFkNWFiZDdlMDM3Y2M2ZCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0zMGI0MzY4 ZDU5Y2ViMzQ2ODFkNWFiZDdlMDM3Y2M2ZDwvYT4NCjxicj4NCjxicj4NClRoZSBwbGF5YmFjayBv ZiBVQ0YgKFVuaXZlcnNhbCBDb21tdW5pY2F0aW9ucyBGb3JtYXQpIHJpY2ggbWVkaWEgZmlsZXMg cmVxdWlyZXMgYXBwcm9wcmlhdGUgcGxheWVycy4gVG8gdmlldyB0aGlzIHR5cGUgb2YgcmljaCBt ZWRpYSBmaWxlcyBpbiB0aGUgbWVldGluZywgcGxlYXNlIGNoZWNrIHdoZXRoZXIgeW91IGhhdmUg dGhlIHBsYXllcnMgaW5zdGFsbGVkIG9uIHlvdXIgY29tcHV0ZXIgYnkgZ29pbmcgdG8NCjxhIGhy ZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9zeXN0ZW1kaWFnbm9zaXMucGhwIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL3N5c3RlbWRpYWdub3Npcy5w aHA8L2E+Lg0KPGJyPg0KPGJyPg0KU2lnbiB1cCBmb3IgYSBmcmVlIHRyaWFsIG9mIFdlYkV4IDxi cj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL2dvL21jZW1mcmVldHJpYWwiIHRhcmdl dD0iX2JsYW5rIj5odHRwOi8vd3d3LndlYmV4LmNvbS9nby9tY2VtZnJlZXRyaWFsPC9hPg0KPGJy Pg0KPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20iIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vd3d3LndlYmV4LmNvbTwvYT4gPGJyPg0KPGJyPg0KQ0NQOiYjNDM7MTY1MDQ3OTMyMDh4 NjQwMzQ5MDEwIyA8YnI+DQo8YnI+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGlzIFdlYkV4IHNlcnZp Y2UgaW5jbHVkZXMgYSBmZWF0dXJlIHRoYXQgYWxsb3dzIGF1ZGlvIGFuZCBhbnkgZG9jdW1lbnRz IGFuZCBvdGhlciBtYXRlcmlhbHMgZXhjaGFuZ2VkIG9yIHZpZXdlZCBkdXJpbmcgdGhlIHNlc3Np b24gdG8gYmUgcmVjb3JkZWQuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGlj YWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50DQog dG8gdGhlIHJlY29yZGluZywgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIG1lZXRpbmcg aG9zdCBwcmlvciB0byB0aGUgc3RhcnQgb2YgdGhlIHJlY29yZGluZyBvciBkbyBub3Qgam9pbiB0 aGUgc2Vzc2lvbi4gUGxlYXNlIG5vdGUgdGhhdCBhbnkgc3VjaCByZWNvcmRpbmdzIG1heSBiZSBz dWJqZWN0IHRvIGRpc2NvdmVyeSBpbiB0aGUgZXZlbnQgb2YgbGl0aWdhdGlvbi4NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D2F21D8ESESSMB209erics_-- From nobody Thu May 8 11:37: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 EB5C51A00D3; Thu, 8 May 2014 11:37:38 -0700 (PDT) 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 2RTV-OzFFco9; Thu, 8 May 2014 11:37:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7551A00BA; Thu, 8 May 2014 11:37:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140508183737.28277.7819.idtracker@ietfa.amsl.com> Date: Thu, 08 May 2014 11:37:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/THJ70iihDlVJ_4SLSWx3Gk9IBS8 Cc: clue@ietf.org Subject: [clue] CLUE WG Virtual Interim Meeting, May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Reply-To: clue@ietf.org List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 18:37:39 -0000 The CLUE WG will hold an Interim meeting on: May 29, 2014 20:00-22:00 UTC (starting at 13.00 Pacific, 15.00 Central, 16.00 Eastern) Webex details and the preliminary agenda are available on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140529 From nobody Thu May 8 14:15:52 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B890A1A0162 for ; Thu, 8 May 2014 14:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.989 X-Spam-Level: X-Spam-Status: No, score=-3.989 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, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 9r8G20BqWEjc for ; Thu, 8 May 2014 14:15:47 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 92A051A0161 for ; Thu, 8 May 2014 14:15:46 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so3077377wes.4 for ; Thu, 08 May 2014 14:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/OrAWaiMkjix+xHtgsgnaa/oAfBAPe8l444SFbW2mRc=; b=QFl1EIqMLh/yx2yTROIWULs+QcGJ8S/fbVVGkz8DCquTLRn2MrppTqLpdGgie6Di9+ +AF60enaxpPIwqYnwbKLDS0Xp8cP/fS6mGXcqKJC13+jihxo25b+4IOcjB/046ZETHm2 fe9n6py443NwcLYAjzMbCgTRDY2H/z40+YUGXcTuJu3pSJ+g6zQcf2fUmGo4thjrExAq wy6bf5In2fpgs4PaFJjkCG7jvAk3T3bfjCYp63EKaJpAFwpIekJ0Vjc+6++8RAgQ/iyb cjspvoBS9YV3PgJtUsgHmtExydU/62iFZpK3nK2XJnxG2cETfYs1EnpD5C2DPNJa8jzo +fVw== MIME-Version: 1.0 X-Received: by 10.180.97.10 with SMTP id dw10mr103510wib.38.1399583741538; Thu, 08 May 2014 14:15:41 -0700 (PDT) Received: by 10.216.93.68 with HTTP; Thu, 8 May 2014 14:15:41 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2F21D8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2F21D8@ESESSMB209.ericsson.se> Date: Thu, 8 May 2014 16:15:41 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d0443064ebf76e704f8e9fbe3 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/cUlklUhzGgD2igVsMgGE5ay3FrM Cc: CLUE Subject: Re: [clue] Meeting invitation: CLUE WG Virtual Interim on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 21:15:49 -0000 --f46d0443064ebf76e704f8e9fbe3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah - I'm multi-tasking in an all day meeting. It's fixed. On Thu, May 8, 2014 at 12:48 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > =E2=80=9CWrapup & Plans for London (5 min)=E2=80=9D > > > > I assume you mean Toronto :) > > > > Regards, > > > > Christer > > > > *From:* clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes > *Sent:* 08 May 2014 19:18 > *To:* CLUE > *Subject:* [clue] Meeting invitation: CLUE WG Virtual Interim on May 29, > 2014 > > > > Below please find the details for the CLUE WG virtual interim meeting > scheduled for May 29, 2014 (15:00-17:00 Central US). > > > > A preliminary agenda is on the wiki: > > http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140529 > > > > Regards, > > Mary. > > ---------- Forwarded message ---------- > From: *Clue Working Group* > Date: Thu, May 8, 2014 at 11:06 AM > Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Inter= im > To: clue-chairs@tools.ietf.org > > > > **** You can forward this email invitation to attendees **** > > Hello , > > Clue Working Group invites you to attend this online meeting. > > Topic: CLUE WG Virtual Interim > Date: Thursday, May 29, 2014 > Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00) > Meeting Number: 640 349 010 > Meeting Password: 1234 > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06c147f1aa7d8aadafe1093cff= a > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: 1234 > 4. Click "Join". > > To view in other time zones or languages, please click the link: > https://ietf.webex.com/ietf/j.php?MTID=3Dm4e5260b422e7fbc58daf046157c0f13= 3 > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > Call-in toll number (US/Canada): 1-650-479-3208 > > Access code:640 349 010 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://ietf.webex.com/ietf/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > clue-chairs@tools.ietf.org > > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://ietf.webex.com/ietf/j.php?MTID=3Dm30b4368d59ceb34681d5abd7e037cc6= d > > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in th= e > meeting, please check whether you have the players installed on your > computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+16504793208x640349010# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows audio > and any documents and other materials exchanged or viewed during the > session to be recorded. By joining this session, you automatically consen= t > to such recordings. If you do not consent to the recording, discuss your > concerns with the meeting host prior to the start of the recording or do > not join the session. Please note that any such recordings may be subject > to discovery in the event of litigation. > > > --f46d0443064ebf76e704f8e9fbe3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah - I'm multi-tasking in an all day meeting. It'= ;s fixed.


On Thu, May 8, 2014 at 12:48 PM, Christer Holmberg <= christe= r.holmberg@ericsson.com> wrote:

=E2=80=9CWrapup & Pla= ns for London (5 min)=E2=80=9D

=C2=A0

I assume you mean Toronto= :)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 08 May 2014 19:18
To: CLUE
Subject: [clue] Meeting invitation: CLUE WG Virtual Interim on May 2= 9, 2014

=C2=A0

Below please find the details for the CLUE WG virtua= l interim meeting scheduled for May 29, 2014 (15:00-17:00 Central US).

=C2=A0

A preliminary agenda is on the wiki:=C2=A0=

=C2=A0

Regards,

Mary.

---------- Forwarded message ----------
From: Clue Working Group <messenger@webex.com>
Date: Thu, May 8, 2014 at 11:06 AM
Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim=
To: clue-ch= airs@tools.ietf.org



**** You can forward this email invitation to attendees ****

Hello ,

Clue Working Group invites you to attend this online meeting.

Topic: CLUE WG Virtual Interim
Date: Thursday, May 29, 2014
Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 640 349 010
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06c147f1aa7d8aadafe1093cffa<= /a>
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm4e5= 260b422e7fbc58daf046157c0f133

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

Access code:640 349 010

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

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


To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm30b= 4368d59ceb34681d5abd7e037cc6d

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

Sign up for a free trial of WebEx
http://= www.webex.com/go/mcemfreetrial

http://www.webex.com=

CCP:+16504793208x640349010#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.

=C2=A0


--f46d0443064ebf76e704f8e9fbe3-- From nobody Thu May 8 20:06: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 A803C1A015C for ; Thu, 8 May 2014 20:06:05 -0700 (PDT) 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 5VDWpICAfOgT for ; Thu, 8 May 2014 20:06:03 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2B31A0157 for ; Thu, 8 May 2014 20:06:02 -0700 (PDT) Received: from ppp118-209-230-3.lns20.mel6.internode.on.net ([118.209.230.3]:52492 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wib84-0004yU-ML for clue@ietf.org; Fri, 09 May 2014 13:05:44 +1000 Message-ID: <536C460F.4060001@nteczone.com> Date: Fri, 09 May 2014 13:05:51 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F13E179@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F13E179@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/Xoe600ZAlLIfSGYAqtMPvWmgoW0 Subject: Re: [clue] voice activated switching example for the Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 03:06:05 -0000 Hello Mark, Please see my comments below. Regards, Christian On 7/05/2014 7:22 AM, Duckworth, Mark wrote: > I had an action item from IETF89 to add an example to the Framework to show how an MCU can implement "voice activated switching" with endpoints that send multiple video streams, so the MCU can choose one to send to a simple endpoint that receives only one video stream. To do this, we want to use a switched MCC from the multi-camera endpoints to the MCU to carry the active talker video from each endpoint. > > This example also addresses, at least in some cases, the issue Steve brought up about cases where "talker identification does not work". http://www.ietf.org/mail-archive/web/clue/current/msg03733.html > > Here is my proposed text to add to the Framework, in the Examples (Informative) section: > > ================ begin proposed text ======================== > 12.3.4. Heterogeneous conference with voice activated switching > > This example illustrates how multipoint "voice activated switching" behavior can be realized, with an endpoint making its own decision about which of its outgoing video streams is considered the "active talker" from that endpoint. Then an MCU can decide which is the active talker among the whole conference. > > Consider a conference between endpoints with the following characteristics: > > Endpoint A - 3 screens, 3 cameras > Endpoint B - 3 screens, 3 cameras > Endpoint C - 1 screen, 1 cameras [CNG] Editorial nit: 1 camera delete > > This example focuses on what the user at endpoint C sees. The user would like to see the video capture of the current talker, without composing it with any other video capture. In this example endpoint C is capable of receiving only a single video stream. The following tables describe advertisements from A and B to the MCU, and from the MCU to C, that can be used to accomplish this. > > +-----------------------+---------------------------------+ > | Capture Scene #1 | Description=Endpoint x | > +-----------------------|---------------------------------+ > | VC1 | CaptureArea=Left | > | | EncodingGroup=1 | > | VC2 | CaptureArea=Center | > | | EncodingGroup=1 | > | VC3 | CaptureArea=Right | > | | EncodingGroup=1 | > | MCC1(VC1,VC2,VC3) | MaxCaptures=1 | > | | CaptureArea=whole scene | > | | Policy=SoundLevel:0 | > | | EncodingGroup=1 | > | AC1 | CaptureArea=whole scene | > | | EncodingGroup=2 | > | CSE1(VC1, VC2, VC3) | | > | CSE2(MCC1) | | > | CSE3(AC1) | | > +---------------------------------------------------------+ > Table 25: Advertisement received at the MCU from Endpoints A and B > > Endpoints A and B are advertising each individual video capture, and also a switched capture MCC1 which switches between the other three based on who is the active talker. These endpoints do not advertise distinct audio captures associated with each individual video capture, so it would be impossible for the MCU (as a media consumer) to make its own determination of which video capture is the active talker based just on information in the audio streams. > > +-----------------------+---------------------------------+ > | Capture Scene #1 | Description=conference | > +-----------------------|---------------------------------+ > | MCC1() | CaptureArea=Left | > | | MaxCaptures=1 | > | | SynchronisationID=1 | > | | Policy=SoundLevel:0 | > | | EncodingGroup=1 | > | | | > | MCC2() | CaptureArea=Center | > | | MaxCaptures=1 | > | | SynchronisationID=1 | > | | Policy=SoundLevel:0 | > | | EncodingGroup=1 | > | | | > | MCC3() | CaptureArea=Right | > | | MaxCaptures=1 | > | | SynchronisationID=1 | > | | Policy=SoundLevel:0 | > | | EncodingGroup=1 | > | | | > | MCC4() | CaptureArea=whole scene | > | | MaxCaptures=1 | > | | Policy=SoundLevel:0 | > | | EncodingGroup=1 | > | | | > | MCC5() (for audio) | CaptureArea=whole scene | > | | MaxCaptures=1 | > | | Policy=SoundLevel:0 | > | | EncodingGroup=2 | > | | | > | MCC6() (for audio) | CaptureArea=whole scene | > | | MaxCaptures=1 | > | | Policy=SoundLevel:1 | > | | EncodingGroup=2 | > | CSE1(MCC1,MCC2,MCC3 | | > | CSE2(MCC4) | | > | CSE3(MCC5,MCC6) | | > +---------------------------------------------------------+ > Table 26: Advertisement sent from the MCU to C > > The MCU advertises one scene, with four video MCCs. Three of them in CSE1 give a left, center, right view of the conference, with "site switching". MCC4 provides a single video capture representing a view of the whole conference, which is simply switched between all the other original source captures. [CNG] According to the above table from a MC perspective it wouldn't know which sources are included. Nothing about the original sources has been advertised. There's no description of MCC5 and MCC6 and CSE3? Does the MCU need to send two Audio MCCs? > > Endpoint C, in its configure message to the MCU, requests to receive MCC4. In order for the MCU to get the [CNG] And an audio capture/s? > information it needs to construct MCC4, it has to send configure messages to A and B asking to receive MCC1 from each of them, along with their AC1 audio. Now the MCU can use audio energy information from the two incoming audio streams from A and B to determine which of those alternatives is the current talker. Based on that, the MCU uses either MCC1 from A or MCC1 from B as the source of MCC4 to send to C. > ================ end proposed text ========================= > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Fri May 9 07:26: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 AA0641A00BE for ; Fri, 9 May 2014 07:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7sF_OENzXfN for ; Fri, 9 May 2014 07:26:55 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA341A02A3 for ; Fri, 9 May 2014 07:26:55 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9AEDDC94C0; Fri, 9 May 2014 10:26:48 -0400 (EDT) Date: Fri, 9 May 2014 10:26:48 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20140509142648.GC20206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5367B0DC.9090509@alum.mit.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Xx6XqYPkE7Eo6JRBMW8LkYFwpJk Cc: CLUE Subject: [clue] Audio Issues X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 14:26:56 -0000 Paul Kyzivat wrote: > > The purpose of the meeting next week (13-may) is to thrash out the audio > issues that we've been discussing on the mailing list for some time. > There has been a lot of heat, but it is unclear to me how much light. > Please come to that meeting prepared to make decisions. We need *text*. > The meeting is not the best place to *create* text, so please post > proposed text to the list prior to the meeting. Working up text has been totally exhausting for the past few days! However, it's time to post _something_... So, I have drafty text relating to about seven issues, that I will post today in separate threads. I don't expect to find time to respond to comments about them today, but I will respond over the weekend. Questions about the appropriateness of this can be posted to this thread, or even questions about what else is coming, and I'll try to respond to them today. Issues (in no particular order) for which I have "some" text: ==== Add surround-sound type ==== Clarify that not all mediaCaptures are offered to be sent to a receiver ==== Clarify the separate availability (if any) of the inputs to a mixer vs. the output of a mixer ==== Note that XY-stereo microphones are commonly available ==== Add a way to specify floor-area intended-capture area for mikes and mixers ==== Add a way to link audio captures to video captures ==== Discuss receiver tactics for rendering mono sources using multiple loudspeakers ==== I do expect to add issues later today... -- John Leslie From nobody Fri May 9 07:28: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 3E4D81A02B3 for ; Fri, 9 May 2014 07:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euLOGFwsn122 for ; Fri, 9 May 2014 07:28:53 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id CD1041A00BE for ; Fri, 9 May 2014 07:28:53 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 68E0FC94C2; Fri, 9 May 2014 10:28:47 -0400 (EDT) Date: Fri, 9 May 2014 10:28:47 -0400 From: John Leslie To: clue@ietf.org Message-ID: <20140509142847.GD20206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/btazQRMVcrmx9VGYmz88W5biQ-c Subject: [clue] Add surround-sound type X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 14:28:55 -0000 We need a surround-sound audioChannelFormatType: I recommend 5.1 (letting others fight whether it's Dolby or DTS or both). This is needed to satisfy REQMT-2a, IMHO. Clearly, the audioChannelFormat enumeration-list needs to be expandable, and we should specify how to expand it in the future (e.g. IANA-FCFS) -- John Leslie From nobody Fri May 9 07:31: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 0D1EC1A02FF for ; Fri, 9 May 2014 07:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n99goGSSyO9p for ; Fri, 9 May 2014 07:31:46 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id F1EE91A02FC for ; Fri, 9 May 2014 07:31:45 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 91D7BC94C0; Fri, 9 May 2014 10:31:39 -0400 (EDT) Date: Fri, 9 May 2014 10:31:39 -0400 From: John Leslie To: clue@ietf.org Message-ID: <20140509143139.GE20206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/d1gbdj05SdY0tYVIHBJyPPEk_dM Subject: [clue] Clarify that not all mediaCaptures are offered to be sent to a receiver X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 14:31:47 -0000 A mediaCapture can refer to a microphone that only serves as input to a mixer. It is helpful to know the locations of microphones going into a particular mix even if they are not separately available to the receiver. (Currently draft-ietf-clue-data-model-schema describes mediaCaptures as a list of all "available on the media provider's side". This is accurate but a bit ambiguous.) I suggest substituting "defined" for "available". -- John Leslie From nobody Fri May 9 07:36:13 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3451A00BE for ; Fri, 9 May 2014 07:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBgPF5YrPMCJ for ; Fri, 9 May 2014 07:36:10 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 935791A0008 for ; Fri, 9 May 2014 07:36:10 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2D877C94C0; Fri, 9 May 2014 10:36:04 -0400 (EDT) Date: Fri, 9 May 2014 10:36:04 -0400 From: John Leslie To: clue@ietf.org Message-ID: <20140509143604.GF20206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/LTJ8X2AM7tmHZCi_YtJ53gWmjM8 Subject: [clue] Clarify availability of inputs to a mixer vs. output X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 14:36:12 -0000 Clarify the separate availability (if any) of the inputs to a mixer vs. the output of a mixer ==== audioCaptureType should include a way to distinguish microphones from mixer outputs. This is needed to satisfy REQMT-2b, IMHO. We now have the boolean to indicate that an audioCapture is a mix of streams, and contentType to list the captureIDREFs and/or sceneEntryIDREFs which go into the mix; but this is awfully hard to find. AFAICT, you have to search the simultaneousSets to find whether a particular mediaCapture is available to be sent. This might require a _very_ long list of simultaneousSets. ISTM that audioCaptureType could include a separately-available boolean. -- John Leslie From nobody Fri May 9 07:38: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 334601A02CD for ; Fri, 9 May 2014 07:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afcVqncpCFK7 for ; Fri, 9 May 2014 07:38:52 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 75B0D1A02D9 for ; Fri, 9 May 2014 07:38:52 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0A183C94C5; Fri, 9 May 2014 10:38:46 -0400 (EDT) Date: Fri, 9 May 2014 10:38:46 -0400 From: John Leslie To: clue@ietf.org Message-ID: <20140509143846.GG20206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/DEXmcQUCV4NIea1zRsw3Ejr9SgU Subject: [clue] Note that XY-stereo microphones are commonly available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 14:38:55 -0000 A mediaCapture can refer to a stereo microphone; but the audioChannelFormat for "stereo" is too generic, IMHO. An XY-stereo microphone produces two streams which represent ~90 degrees difference in orientation, but no difference in position. This is very useful, but needs to be processed entirely differently from a stereo pair separated by a significant distance and aimed in approximately the same direction. Clearly, the audioChannelFormat enumeration-list needs to be expandable, and we should specify how to expand it in the future (e.g. IANA-FCFS) -- John Leslie From nobody Fri May 9 07:44: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 557171A02C7 for ; Fri, 9 May 2014 07:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWd9XiR-oxqT for ; Fri, 9 May 2014 07:43:59 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1134A1A02B0 for ; Fri, 9 May 2014 07:43:59 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A0677C94C2; Fri, 9 May 2014 10:43:52 -0400 (EDT) Date: Fri, 9 May 2014 10:43:52 -0400 From: John Leslie To: clue@ietf.org Message-ID: <20140509144352.GH20206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/N1VGcaZ7lee3tqfTM3IPuHsrGao Subject: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 14:44:00 -0000 Add a way to specify floor-area intended-capture area for mikes and mixers ==== Currently we have spatialInformation within mediaCaptureType, and spatialInformation includes captureArea. This has already led to much confusion. I suggest renaming "captureArea" to "videoCaptureFrame" and adding "audioCapturePolygon" to spatialInformation. The current video captureArea defines a trapezoid in a plane more-or-less perpendicular to the floor. Actually the video includes infinitely many rectangles at differing distances from the point of capture, with no way to distinguish them except that some are out of focus. Thus video can be thought of as insensitive to distance from the camera. Audio mediaCaptures, however, are mostly insensitive to height above the floor, but necessarily concentrate on capturing the sound within some distance of the microphone. The audio level decreases with the square of the distance. While microphones pick up _some_ sound from anywhere in the room, the _intent_ in setting up microphones is to pick up sound in a defined area. This deserves a way to specify it -- at least in the case where that microphone's sound output is separately available. In many cases, the sound engineer will wish to only offer one mixer output (hopefully stereo or surround) for the entire room. But when the individual microphones are separately available, it would be very helpful to know the area each is intended to cover. This will not be a rectangle, so I advise defining it as a polygon. -- John Leslie From nobody Fri May 9 14:40: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 8452A1A00EC for ; Fri, 9 May 2014 14:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 xlst1FeWeE9H for ; Fri, 9 May 2014 14:40:43 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.97]) by ietfa.amsl.com (Postfix) with ESMTP id BCA7E1A0102 for ; Fri, 9 May 2014 14:40:43 -0700 (PDT) Received: from [216.82.254.19:34641] by server-1.bemta-7.messagelabs.com id 8B/78-29805-65B4D635; Fri, 09 May 2014 21:40:38 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-8.tower-96.messagelabs.com!1399671637!4166351!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20832 invoked from network); 9 May 2014 21:40:37 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-8.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 9 May 2014 21:40:37 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.94]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 9 May 2014 14:40:37 -0700 From: "Duckworth, Mark" To: John Leslie , "clue@ietf.org" Date: Fri, 9 May 2014 14:40:35 -0700 Thread-Topic: [clue] Note that XY-stereo microphones are commonly available Thread-Index: Ac9rlGetHF8D47q5SZKorszyjQN2PgAOeCLQ Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F13E60B@CRPMBOXPRD08.polycom.com> References: <20140509143846.GG20206@verdi> In-Reply-To: <20140509143846.GG20206@verdi> 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/zMe_CZWhviqKi8ELOPN6WpKhzk8 Subject: Re: [clue] Note that XY-stereo microphones are commonly available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 21:40:45 -0000 I had a different proposal about the Audio Channel Format attribute. I thi= nk we should consider it along with John's proposals about 5.1 format and X= Y-stereo. I'm thinking this "audio channel format" parameter is really a characterist= ic of a particular audio *encoding*, not an audio *capture*. So my idea is we should remove this audio capture attribute from the framew= ork and data model. The format of a particular audio encoding would be des= cribed entirely in SDP (not CLUE messages). And a media provider could adv= ertise one single audio capture for the whole room, which maybe it could en= code as mono, or stereo, or 3 channel, or surround sound, or whatever. Or = maybe even offer multiple encodings for simulcast, but these are still all = just different encodings of the same audio capture. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie > Sent: Friday, May 09, 2014 10:39 AM > To: clue@ietf.org > Subject: [clue] Note that XY-stereo microphones are commonly available >=20 > A mediaCapture can refer to a stereo microphone; but the > audioChannelFormat for "stereo" is too generic, IMHO. An XY-stereo > microphone produces two streams which represent ~90 degrees difference > in orientation, but no difference in position. >=20 > This is very useful, but needs to be processed entirely differently fr= om a > stereo pair separated by a significant distance and aimed in approximatel= y > the same direction. >=20 > Clearly, the audioChannelFormat enumeration-list needs to be expandabl= e, > and we should specify how to expand it in the future (e.g. IANA-FCFS) >=20 > -- > John Leslie >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri May 9 14:51: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 C57D71A00EC for ; Fri, 9 May 2014 14:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 rzC4K1o7rbTY for ; Fri, 9 May 2014 14:51:10 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.8]) by ietfa.amsl.com (Postfix) with ESMTP id EA22D1A00BF for ; Fri, 9 May 2014 14:51:09 -0700 (PDT) Received: from [216.82.249.212:22547] by server-8.bemta-12.messagelabs.com id DA/3D-30775-8CD4D635; Fri, 09 May 2014 21:51:04 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-8.tower-219.messagelabs.com!1399672263!1907925!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25500 invoked from network); 9 May 2014 21:51:04 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-8.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 9 May 2014 21:51:04 -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, 9 May 2014 14:51:03 -0700 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.94]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 9 May 2014 14:51:02 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Fri, 9 May 2014 14:51:00 -0700 Thread-Topic: [clue] voice activated switching example for the Framework Thread-Index: Ac9rM54KuS/N6NlcSkqeX2vElaj+2AAm+gLg Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F13E611@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F13E179@CRPMBOXPRD08.polycom.com> <536C460F.4060001@nteczone.com> In-Reply-To: <536C460F.4060001@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/KNGIgDxA5VxMtlCLq7Jzk2cnCns Subject: Re: [clue] voice activated switching example for the Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 21:51:12 -0000 Hi Christian, thanks for the feedback. more below. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Thursday, May 08, 2014 11:06 PM > To: clue@ietf.org > Subject: Re: [clue] voice activated switching example for the Framework >=20 > Hello Mark, >=20 > Please see my comments below. >=20 > Regards, Christian >=20 > On 7/05/2014 7:22 AM, Duckworth, Mark wrote: > > I had an action item from IETF89 to add an example to the Framework to > show how an MCU can implement "voice activated switching" with endpoints > that send multiple video streams, so the MCU can choose one to send to a > simple endpoint that receives only one video stream. To do this, we want= to > use a switched MCC from the multi-camera endpoints to the MCU to carry > the active talker video from each endpoint. > > > > This example also addresses, at least in some cases, the issue Steve > > brought up about cases where "talker identification does not work". > > http://www.ietf.org/mail-archive/web/clue/current/msg03733.html > > > > Here is my proposed text to add to the Framework, in the Examples > (Informative) section: > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D begin proposed text = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 12.3.4. > > Heterogeneous conference with voice activated switching > > > > This example illustrates how multipoint "voice activated switching" > behavior can be realized, with an endpoint making its own decision about > which of its outgoing video streams is considered the "active talker" fro= m > that endpoint. Then an MCU can decide which is the active talker among t= he > whole conference. > > > > Consider a conference between endpoints with the following > characteristics: > > > > Endpoint A - 3 screens, 3 cameras > > Endpoint B - 3 screens, 3 cameras > > Endpoint C - 1 screen, 1 cameras > [CNG] Editorial nit: 1 camera delete > > > > This example focuses on what the user at endpoint C sees. The user wou= ld > like to see the video capture of the current talker, without composing it= with > any other video capture. In this example endpoint C is capable of receiv= ing > only a single video stream. The following tables describe advertisements > from A and B to the MCU, and from the MCU to C, that can be used to > accomplish this. > > > > +-----------------------+---------------------------------+ > > | Capture Scene #1 | Description=3DEndpoint x | > > +-----------------------|---------------------------------+ > > | VC1 | CaptureArea=3DLeft | > > | | EncodingGroup=3D1 | > > | VC2 | CaptureArea=3DCenter | > > | | EncodingGroup=3D1 | > > | VC3 | CaptureArea=3DRight | > > | | EncodingGroup=3D1 | > > | MCC1(VC1,VC2,VC3) | MaxCaptures=3D1 | > > | | CaptureArea=3Dwhole scene | > > | | Policy=3DSoundLevel:0 | > > | | EncodingGroup=3D1 | > > | AC1 | CaptureArea=3Dwhole scene | > > | | EncodingGroup=3D2 | > > | CSE1(VC1, VC2, VC3) | | > > | CSE2(MCC1) | | > > | CSE3(AC1) | | > > +---------------------------------------------------------+ > > Table 25: Advertisement received at the MCU from Endpoints A and B > > > > Endpoints A and B are advertising each individual video capture, and al= so a > switched capture MCC1 which switches between the other three based on > who is the active talker. These endpoints do not advertise distinct audi= o > captures associated with each individual video capture, so it would be > impossible for the MCU (as a media consumer) to make its own > determination of which video capture is the active talker based just on > information in the audio streams. > > > > +-----------------------+---------------------------------+ > > | Capture Scene #1 | Description=3Dconference | > > +-----------------------|---------------------------------+ > > | MCC1() | CaptureArea=3DLeft | > > | | MaxCaptures=3D1 | > > | | SynchronisationID=3D1 | > > | | Policy=3DSoundLevel:0 | > > | | EncodingGroup=3D1 | > > | | | > > | MCC2() | CaptureArea=3DCenter | > > | | MaxCaptures=3D1 | > > | | SynchronisationID=3D1 | > > | | Policy=3DSoundLevel:0 | > > | | EncodingGroup=3D1 | > > | | | > > | MCC3() | CaptureArea=3DRight | > > | | MaxCaptures=3D1 | > > | | SynchronisationID=3D1 | > > | | Policy=3DSoundLevel:0 | > > | | EncodingGroup=3D1 | > > | | | > > | MCC4() | CaptureArea=3Dwhole scene | > > | | MaxCaptures=3D1 | > > | | Policy=3DSoundLevel:0 | > > | | EncodingGroup=3D1 | > > | | | > > | MCC5() (for audio) | CaptureArea=3Dwhole scene | > > | | MaxCaptures=3D1 | > > | | Policy=3DSoundLevel:0 | > > | | EncodingGroup=3D2 | > > | | | > > | MCC6() (for audio) | CaptureArea=3Dwhole scene | > > | | MaxCaptures=3D1 | > > | | Policy=3DSoundLevel:1 | > > | | EncodingGroup=3D2 | > > | CSE1(MCC1,MCC2,MCC3 | | > > | CSE2(MCC4) | | > > | CSE3(MCC5,MCC6) | | > > +---------------------------------------------------------+ > > Table 26: Advertisement sent from the MCU to C > > > > The MCU advertises one scene, with four video MCCs. Three of them in > CSE1 give a left, center, right view of the conference, with "site switch= ing". > MCC4 provides a single video capture representing a view of the whole > conference, which is simply switched between all the other original sourc= e > captures. > [CNG] According to the above table from a MC perspective it wouldn't know > which sources are included. Nothing about the original sources has been > advertised. [Duckworth, Mark] Correct. That is allowed according to the definition of = an MCC. I want to keep this example as simple as possible to illustrate the point, = and it isn't necessary to include all those other captures without encoding groups in or= der to do that. > There's no description of MCC5 and MCC6 and CSE3? Does the MCU need to > send two Audio MCCs? [Duckworth, Mark] MCC5 and MCC6 have a bunch of attributes describing them= , so I'm not sure what you mean? Maybe the MCU should advertise: CSE3(MCC5, MCC6) CSE4(MCC5) This would make it clear the advertisement suggests MCC5 if the consumer wa= nts just one audio capture. >=20 > > > > Endpoint C, in its configure message to the MCU, requests to receive > > MCC4. In order for the MCU to get the > [CNG] And an audio capture/s? [Duckworth, Mark] Yes, I will add that for completeness in the text. > > information it needs to construct MCC4, it has to send configure messag= es > to A and B asking to receive MCC1 from each of them, along with their AC1 > audio. Now the MCU can use audio energy information from the two > incoming audio streams from A and B to determine which of those > alternatives is the current talker. Based on that, the MCU uses either M= CC1 > from A or MCC1 from B as the source of MCC4 to send to C. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D end proposed text =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Fri May 9 14:59: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 B56C81A0118 for ; Fri, 9 May 2014 14:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 btuc7TNYC5IU for ; Fri, 9 May 2014 14:59:05 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDC31A0117 for ; Fri, 9 May 2014 14:59:05 -0700 (PDT) Received: from [216.82.254.20:44528] by server-6.bemta-7.messagelabs.com id D9/31-20645-4AF4D635; Fri, 09 May 2014 21:59:00 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-4.tower-47.messagelabs.com!1399672738!3258730!3 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8904 invoked from network); 9 May 2014 21:59:00 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-4.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 9 May 2014 21:59:00 -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; Fri, 9 May 2014 14:57:56 -0700 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.94]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 9 May 2014 14:57:56 -0700 From: "Duckworth, Mark" To: John Leslie , "clue@ietf.org" Date: Fri, 9 May 2014 14:57:54 -0700 Thread-Topic: [clue] Clarify that not all mediaCaptures are offered to be sent to a receiver Thread-Index: Ac9rk3OKlY+K2h0vRJCzeHKRFNNFJAAPeU3A Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F13E615@CRPMBOXPRD08.polycom.com> References: <20140509143139.GE20206@verdi> In-Reply-To: <20140509143139.GE20206@verdi> 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/7AWMRzbGOQlg8BBSYEjD_b5N_kk Subject: Re: [clue] Clarify that not all mediaCaptures are offered to be sent to a receiver X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 21:59:06 -0000 I agree using "defined" is better than "available". It is used in sections= 3, 4, 10, and 14 of the data model. Seems like if we change one we should= change them all. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie > Sent: Friday, May 09, 2014 10:32 AM > To: clue@ietf.org > Subject: [clue] Clarify that not all mediaCaptures are offered to be sent= to a > receiver >=20 > A mediaCapture can refer to a microphone that only serves as input to = a > mixer. It is helpful to know the locations of microphones going into a > particular mix even if they are not separately available to the receiver. >=20 > (Currently draft-ietf-clue-data-model-schema describes mediaCaptures a= s > a list of all "available on the media provider's side". This is accurate = but a bit > ambiguous.) >=20 > I suggest substituting "defined" for "available". >=20 > -- > John Leslie >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri May 9 15:06:13 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0561A0102 for ; Fri, 9 May 2014 15:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 IjvSUfboLo1Y for ; Fri, 9 May 2014 15:06:10 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.7]) by ietfa.amsl.com (Postfix) with ESMTP id 493111A00BF for ; Fri, 9 May 2014 15:06:10 -0700 (PDT) Received: from [216.82.249.212:27988] by server-7.bemta-12.messagelabs.com id 56/2E-31293-D415D635; Fri, 09 May 2014 22:06:05 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-15.tower-219.messagelabs.com!1399673159!1893536!4 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4501 invoked from network); 9 May 2014 22:06:04 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-15.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 9 May 2014 22:06:04 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.94]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 9 May 2014 15:05:37 -0700 From: "Duckworth, Mark" To: John Leslie , "clue@ietf.org" Date: Fri, 9 May 2014 15:05:36 -0700 Thread-Topic: [clue] Clarify availability of inputs to a mixer vs. output Thread-Index: Ac9rlAZJcAeBTWNXQh6KVY01f8b5PAAPdhpw Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F13E616@CRPMBOXPRD08.polycom.com> References: <20140509143604.GF20206@verdi> In-Reply-To: <20140509143604.GF20206@verdi> 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/iM4BHqOYzgdg9u1oviSZZpSAZuM Subject: Re: [clue] Clarify availability of inputs to a mixer vs. output X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 09 May 2014 22:06:11 -0000 Hi John, There is a simple way to advertise a capture that you can't send (such as o= ne that is just an input to a mixer). You just don't give an encoding grou= p for that capture. Does this give you what you are looking for? Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie > Sent: Friday, May 09, 2014 10:36 AM > To: clue@ietf.org > Subject: [clue] Clarify availability of inputs to a mixer vs. output >=20 > Clarify the separate availability (if any) of the inputs to a mixer vs. t= he output > of a mixer =3D=3D=3D=3D >=20 > audioCaptureType should include a way to distinguish microphones from > mixer outputs. >=20 > This is needed to satisfy REQMT-2b, IMHO. >=20 > We now have the boolean to indicate that an audioCapture is > a mix of streams, and contentType to list the captureIDREFs and/or > sceneEntryIDREFs which go into the mix; but this is awfully hard to find. >=20 > AFAICT, you have to search the simultaneousSets to find whether a > particular mediaCapture is available to be sent. This might require a _ve= ry_ > long list of simultaneousSets. >=20 > ISTM that audioCaptureType could include a separately-available boolea= n. >=20 > -- > John Leslie >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Sat May 10 06:10: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 A00F11A0246 for ; Sat, 10 May 2014 06:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3xikdXhJ5Lq for ; Sat, 10 May 2014 06:10:07 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 088961A0245 for ; Sat, 10 May 2014 06:10:06 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A968EC94A9; Sat, 10 May 2014 09:09:59 -0400 (EDT) Date: Sat, 10 May 2014 09:09:59 -0400 From: John Leslie To: clue@ietf.org Message-ID: <20140510130959.GK20206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5OpdeTBwQns1jBm_i_D9SYOrtkI Subject: [clue] Add a way to link audio captures to video captures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 13:10:11 -0000 Whenever there are separate cameras which can be separately displayed, the receiver faces the question of which audio source to render so as to seem to come from that video area. Sometimes, of course, there will only be one audio source available; but when there are several, it would help for the sender to link the "most appropriate" audio to each separate video. (How "most appropriate" is determined is way out-of-scope for this standard.) Currently we have spatialInformation within mediaCaptureType, and spatialInformation includes captureArea. This has already led to much confusion. I suggest renaming "captureArea" to "videoCaptureFrame" and adding "audioCapturePolygon" to spatialInformation. The current video captureArea defines a trapezoid in a plane more-or-less perpendicular to the floor. Actually the video includes infinitely many rectangles at differing distances from the point of capture, with no way to distinguish them except that some are out of focus. Thus video can be thought of as insensitive to distance from the camera. Audio mediaCaptures, however, are mostly insensitive to height above the floor, but necessarily concentrate on capturing the sound within some distance of the microphone. The audio level decreases with the square of the distance. While microphones pick up some sound from anywhere in the room, the _intent_ in setting up microphones is to pick up sound in a defined area. This deserves a way to specify it -- at least in the case where that microphone's sound output is separately available. In many cases, the sound engineer will wish to only offer one mixer output (hopefully stereo or surround) for the entire room. But when the individual microphones are separately available, it would be very helpful to know the area each is intended to cover. This will not be a rectangle, so I advise defining it as a polygon. Given a videoCaptureFrame and audioCapturePolygons to choose from, it's easy enough for a receiver to test overlap. (OK, maybe it is a bit confusing to test overlap of a pyramid with a two-dimensional plane in three-space, but it's "easy math".) This automatically gives you a list of audio captures appropriate for a video capture being displayed. OTOH, it's even easier for the sender to do this; and there could be cases where the audio is most appropriate despite lack of overlap. And, if the sender does it, an order of preference could be noted. But it's still not clear to me what XML is appropriate to record this. I think I'd prefer a list of audio capture IDREFs within the videoCaptureType; but that's not a strong preference if some other way is available and appropriate. -- John Leslie From nobody Sun May 11 18:54: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 C422A1A03B4 for ; Sun, 11 May 2014 18:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBWIJcziRocO for ; Sun, 11 May 2014 18:54:55 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5131A03AE for ; Sun, 11 May 2014 18:54:54 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 45B40C94A9; Sun, 11 May 2014 21:54:45 -0400 (EDT) Date: Sun, 11 May 2014 21:54:45 -0400 From: John Leslie To: "Duckworth, Mark" Message-ID: <20140512015445.GL20206@verdi> References: <20140509143846.GG20206@verdi> <5C4AC54BFF7A0842A6A11F554D6FB52F13E60B@CRPMBOXPRD08.polycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F13E60B@CRPMBOXPRD08.polycom.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/r_h8A7XYkAEDfFXAEE6Yn1a1auw Cc: clue@ietf.org Subject: Re: [clue] Note that XY-stereo microphones are commonly available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 01:54:57 -0000 Duckworth, Mark wrote: > > I had a different proposal about the Audio Channel Format attribute. > I think we should consider it along with John's proposals about 5.1 > format and XY-stereo. > > I'm thinking this "audio channel format" parameter is really a > characteristic of a particular audio *encoding*, not an audio *capture*. Hmm... That sounds funny... > So my idea is we should remove this audio capture attribute from the > framework and data model. The format of a particular audio encoding > would be described entirely in SDP (not CLUE messages). I'm not _opposed_ to that; but there are _so_many_details_... > And a media provider could advertise one single audio capture for the > whole room, which maybe it could encode as mono, or stereo, or > 3 channel, or surround sound, or whatever. Or maybe even offer > multiple encodings for simulcast, but these are still all just > different encodings of the same audio capture. Mark is correct that a whole-room feed may be appropriate to receive in different formats: obviously folks who want to render mono might balk at receiving six channels in order to do so. I'm not sure how to manage that, though. If a mix is prepared in 5.1 surround, I doubt that SDP is the right conduit for negotiating the number of channels -- offhand that sounds like a middlebox task. And I'm _sure_ SDP isn't the right conduit for remapping the components of a whole-room feed to fit an incompatible conference room paradigm. (Nonetheless, there probably should be _some_ consideration of conserving bandwith for receivers that don't do surround-sound...) -- John Leslie From nobody Sun May 11 18:59: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 8EEBD1A03B6 for ; Sun, 11 May 2014 18:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUUtC-IV18KX for ; Sun, 11 May 2014 18:59:50 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2D81A03AE for ; Sun, 11 May 2014 18:59:50 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 94C4AC94A9; Sun, 11 May 2014 21:59:41 -0400 (EDT) Date: Sun, 11 May 2014 21:59:41 -0400 From: John Leslie To: "Duckworth, Mark" Message-ID: <20140512015941.GM20206@verdi> References: <20140509143604.GF20206@verdi> <5C4AC54BFF7A0842A6A11F554D6FB52F13E616@CRPMBOXPRD08.polycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F13E616@CRPMBOXPRD08.polycom.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/MYZkd9HV9zrwYvLRcCqVfG3Ic-0 Cc: clue@ietf.org Subject: Re: [clue] Clarify availability of inputs to a mixer vs. output X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 01:59:51 -0000 Duckworth, Mark wrote: > > There is a simple way to advertise a capture that you can't send > (such as one that is just an input to a mixer). You just don't give > an encoding group for that capture. Does this give you what you are > looking for? Quite possibly it does... I wasn't able to grok encodingGroup from the data-model-schema. :^( -- John Leslie From nobody Sun May 11 19:29: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 450D41A0145 for ; Sun, 11 May 2014 19:28:58 -0700 (PDT) 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 HYKYfjyTbowb for ; Sun, 11 May 2014 19:28:56 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF6A1A03CA for ; Sun, 11 May 2014 19:28:55 -0700 (PDT) Received: from ppp118-209-77-85.lns20.mel4.internode.on.net ([118.209.77.85]:55261 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wjfy6-0002iu-Hp; Mon, 12 May 2014 12:27:54 +1000 Message-ID: <537031DB.2080306@nteczone.com> Date: Mon, 12 May 2014 12:28:43 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52F13E179@CRPMBOXPRD08.polycom.com> <536C460F.4060001@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13E611@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F13E611@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/bDCa15jJZhp7HKysqfxJvSHHdGw Subject: Re: [clue] voice activated switching example for the Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 02:28:58 -0000 Hello Mark, Please see below. Regards, Christian On 10/05/2014 7:51 AM, Duckworth, Mark wrote: > Hi Christian, > thanks for the feedback. more below. > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Thursday, May 08, 2014 11:06 PM >> To: clue@ietf.org >> Subject: Re: [clue] voice activated switching example for the Framework >> >> Hello Mark, >> >> Please see my comments below. >> >> Regards, Christian >> >> On 7/05/2014 7:22 AM, Duckworth, Mark wrote: >>> I had an action item from IETF89 to add an example to the Framework to >> show how an MCU can implement "voice activated switching" with endpoints >> that send multiple video streams, so the MCU can choose one to send to a >> simple endpoint that receives only one video stream. To do this, we want to >> use a switched MCC from the multi-camera endpoints to the MCU to carry >> the active talker video from each endpoint. >>> This example also addresses, at least in some cases, the issue Steve >>> brought up about cases where "talker identification does not work". >>> http://www.ietf.org/mail-archive/web/clue/current/msg03733.html >>> >>> Here is my proposed text to add to the Framework, in the Examples >> (Informative) section: >>> ================ begin proposed text ======================== >> 12.3.4. >>> Heterogeneous conference with voice activated switching >>> >>> This example illustrates how multipoint "voice activated switching" >> behavior can be realized, with an endpoint making its own decision about >> which of its outgoing video streams is considered the "active talker" from >> that endpoint. Then an MCU can decide which is the active talker among the >> whole conference. >>> Consider a conference between endpoints with the following >> characteristics: >>> Endpoint A - 3 screens, 3 cameras >>> Endpoint B - 3 screens, 3 cameras >>> Endpoint C - 1 screen, 1 cameras >> [CNG] Editorial nit: 1 camera delete >>> This example focuses on what the user at endpoint C sees. The user would >> like to see the video capture of the current talker, without composing it with >> any other video capture. In this example endpoint C is capable of receiving >> only a single video stream. The following tables describe advertisements >> from A and B to the MCU, and from the MCU to C, that can be used to >> accomplish this. >>> +-----------------------+---------------------------------+ >>> | Capture Scene #1 | Description=Endpoint x | >>> +-----------------------|---------------------------------+ >>> | VC1 | CaptureArea=Left | >>> | | EncodingGroup=1 | >>> | VC2 | CaptureArea=Center | >>> | | EncodingGroup=1 | >>> | VC3 | CaptureArea=Right | >>> | | EncodingGroup=1 | >>> | MCC1(VC1,VC2,VC3) | MaxCaptures=1 | >>> | | CaptureArea=whole scene | >>> | | Policy=SoundLevel:0 | >>> | | EncodingGroup=1 | >>> | AC1 | CaptureArea=whole scene | >>> | | EncodingGroup=2 | >>> | CSE1(VC1, VC2, VC3) | | >>> | CSE2(MCC1) | | >>> | CSE3(AC1) | | >>> +---------------------------------------------------------+ >>> Table 25: Advertisement received at the MCU from Endpoints A and B >>> >>> Endpoints A and B are advertising each individual video capture, and also a >> switched capture MCC1 which switches between the other three based on >> who is the active talker. These endpoints do not advertise distinct audio >> captures associated with each individual video capture, so it would be >> impossible for the MCU (as a media consumer) to make its own >> determination of which video capture is the active talker based just on >> information in the audio streams. >>> +-----------------------+---------------------------------+ >>> | Capture Scene #1 | Description=conference | >>> +-----------------------|---------------------------------+ >>> | MCC1() | CaptureArea=Left | >>> | | MaxCaptures=1 | >>> | | SynchronisationID=1 | >>> | | Policy=SoundLevel:0 | >>> | | EncodingGroup=1 | >>> | | | >>> | MCC2() | CaptureArea=Center | >>> | | MaxCaptures=1 | >>> | | SynchronisationID=1 | >>> | | Policy=SoundLevel:0 | >>> | | EncodingGroup=1 | >>> | | | >>> | MCC3() | CaptureArea=Right | >>> | | MaxCaptures=1 | >>> | | SynchronisationID=1 | >>> | | Policy=SoundLevel:0 | >>> | | EncodingGroup=1 | >>> | | | >>> | MCC4() | CaptureArea=whole scene | >>> | | MaxCaptures=1 | >>> | | Policy=SoundLevel:0 | >>> | | EncodingGroup=1 | >>> | | | >>> | MCC5() (for audio) | CaptureArea=whole scene | >>> | | MaxCaptures=1 | >>> | | Policy=SoundLevel:0 | >>> | | EncodingGroup=2 | >>> | | | >>> | MCC6() (for audio) | CaptureArea=whole scene | >>> | | MaxCaptures=1 | >>> | | Policy=SoundLevel:1 | >>> | | EncodingGroup=2 | >>> | CSE1(MCC1,MCC2,MCC3 | | >>> | CSE2(MCC4) | | >>> | CSE3(MCC5,MCC6) | | >>> +---------------------------------------------------------+ >>> Table 26: Advertisement sent from the MCU to C >>> >>> The MCU advertises one scene, with four video MCCs. Three of them in >> CSE1 give a left, center, right view of the conference, with "site switching". >> MCC4 provides a single video capture representing a view of the whole >> conference, which is simply switched between all the other original source >> captures. >> [CNG] According to the above table from a MC perspective it wouldn't know >> which sources are included. Nothing about the original sources has been >> advertised. > [Duckworth, Mark] Correct. That is allowed according to the definition of an MCC. > I want to keep this example as simple as possible to illustrate the point, and it isn't > necessary to include all those other captures without encoding groups in order to do that. [CNG] That's fine, however I think its worth to add a note that the source captures would be sent but not included for brevity reasons. Otherwise the MC doesn't know that they are simply switched between all the other original source captures." > >> There's no description of MCC5 and MCC6 and CSE3? Does the MCU need to >> send two Audio MCCs? > [Duckworth, Mark] MCC5 and MCC6 have a bunch of attributes describing them, so I'm not sure what you mean? > Maybe the MCU should advertise: > CSE3(MCC5, MCC6) > CSE4(MCC5) > This would make it clear the advertisement suggests MCC5 if the consumer wants just one audio capture. [CNG] I mean there's no text procedural description saying what these are. The video MCCs also have attributes but you describe the video in the paragraph below the table. > >>> Endpoint C, in its configure message to the MCU, requests to receive >>> MCC4. In order for the MCU to get the >> [CNG] And an audio capture/s? > [Duckworth, Mark] Yes, I will add that for completeness in the text. > >>> information it needs to construct MCC4, it has to send configure messages >> to A and B asking to receive MCC1 from each of them, along with their AC1 >> audio. Now the MCU can use audio energy information from the two >> incoming audio streams from A and B to determine which of those >> alternatives is the current talker. Based on that, the MCU uses either MCC1 >> from A or MCC1 from B as the source of MCC4 to send to C. >>> ================ end proposed text ========================= From nobody Sun May 11 19:33: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 2325A1A03CA for ; Sun, 11 May 2014 19:33:41 -0700 (PDT) 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 dy66075Hlo6l for ; Sun, 11 May 2014 19:33:39 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F881A03C1 for ; Sun, 11 May 2014 19:33:39 -0700 (PDT) Received: from ppp118-209-77-85.lns20.mel4.internode.on.net ([118.209.77.85]:55281 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wjg2j-0003Pp-HO for clue@ietf.org; Mon, 12 May 2014 12:32:41 +1000 Message-ID: <537032FA.1010601@nteczone.com> Date: Mon, 12 May 2014 12:33:30 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140509142847.GD20206@verdi> In-Reply-To: <20140509142847.GD20206@verdi> 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/mkr4gGaNxTMcmUjFNsS-sGCvPG8 Subject: Re: [clue] Add surround-sound type X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 02:33:41 -0000 Hello John, I had earlier proposed to change the audioChannelFormatType to a number (i.e. number of channels) to aid extension, e.g. 1 = mono 2 = stereo 5 = 5.1 surround sound So I'm OK with adding 5.1 and I agree that with for this (and all CLUE attributes) we need to specify how to extent them. Regards, Christian On 10/05/2014 12:28 AM, John Leslie wrote: > We need a surround-sound audioChannelFormatType: I recommend 5.1 (letting others fight whether it's Dolby or DTS or both). > > This is needed to satisfy REQMT-2a, IMHO. > > Clearly, the audioChannelFormat enumeration-list needs to be expandable, and we should specify how to expand it in the future (e.g. IANA-FCFS) > > -- > John Leslie > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun May 11 19:44: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 D2DC31A03CC for ; Sun, 11 May 2014 19:44:29 -0700 (PDT) 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 xGMmuSXx1u9a for ; Sun, 11 May 2014 19:44:27 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CF61A03D0 for ; Sun, 11 May 2014 19:44:27 -0700 (PDT) Received: from ppp118-209-77-85.lns20.mel4.internode.on.net ([118.209.77.85]:55343 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WjgDB-0004lP-GP for clue@ietf.org; Mon, 12 May 2014 12:43:29 +1000 Message-ID: <53703582.2080409@nteczone.com> Date: Mon, 12 May 2014 12:44:18 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140509143139.GE20206@verdi> <5C4AC54BFF7A0842A6A11F554D6FB52F13E615@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F13E615@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/ZkYcJkkHhT7mOlUaZRqogeAR_8w Subject: Re: [clue] Clarify that not all mediaCaptures are offered to be sent to a receiver X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 02:44:30 -0000 Hello I section 3 I think it makes sense to say: : the list of defined media captures Actually we could probably remove defined altogether. However I'm not so sure there should be a blanket change. The framework draft also uses term "available" and I think in some cases it sounds correct. Regards, Christian On 10/05/2014 7:57 AM, Duckworth, Mark wrote: > I agree using "defined" is better than "available". It is used in sections 3, 4, 10, and 14 of the data model. Seems like if we change one we should change them all. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie >> Sent: Friday, May 09, 2014 10:32 AM >> To: clue@ietf.org >> Subject: [clue] Clarify that not all mediaCaptures are offered to be sent to a >> receiver >> >> A mediaCapture can refer to a microphone that only serves as input to a >> mixer. It is helpful to know the locations of microphones going into a >> particular mix even if they are not separately available to the receiver. >> >> (Currently draft-ietf-clue-data-model-schema describes mediaCaptures as >> a list of all "available on the media provider's side". This is accurate but a bit >> ambiguous.) >> >> I suggest substituting "defined" for "available". >> >> -- >> John Leslie >> >> _______________________________________________ >> clue mailing 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 May 11 20:04:11 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893461A03DD for ; Sun, 11 May 2014 20:04:10 -0700 (PDT) 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 wkl-oUCceXgn for ; Sun, 11 May 2014 20:04:09 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB21E1A03D9 for ; Sun, 11 May 2014 20:04:08 -0700 (PDT) Received: from ppp118-209-77-85.lns20.mel4.internode.on.net ([118.209.77.85]:55493 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WjgWE-0007xO-Gg for clue@ietf.org; Mon, 12 May 2014 13:03:10 +1000 Message-ID: <53703A1F.6070909@nteczone.com> Date: Mon, 12 May 2014 13:03:59 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140509144352.GH20206@verdi> In-Reply-To: <20140509144352.GH20206@verdi> 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/dTxycSQ4VeB8l_bMgQ8es-99FHI Subject: Re: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 03:04:10 -0000 Hello John, Do you propose that the audioCapturePolygon has a relationship to the capturePoint/lineOfCapturePoint. Regards, Christian On 10/05/2014 12:43 AM, John Leslie wrote: > Add a way to specify floor-area intended-capture area for mikes and mixers > ==== > Currently we have spatialInformation within mediaCaptureType, and > spatialInformation includes captureArea. > > This has already led to much confusion. I suggest renaming > "captureArea" to "videoCaptureFrame" and adding "audioCapturePolygon" > to spatialInformation. > > The current video captureArea defines a trapezoid in a plane > more-or-less perpendicular to the floor. Actually the video includes > infinitely many rectangles at differing distances from the point of > capture, with no way to distinguish them except that some are out of > focus. Thus video can be thought of as insensitive to distance from > the camera. > > Audio mediaCaptures, however, are mostly insensitive to height above > the floor, but necessarily concentrate on capturing the sound within > some distance of the microphone. The audio level decreases with the > square of the distance. > > While microphones pick up _some_ sound from anywhere in the room, > the _intent_ in setting up microphones is to pick up sound in a > defined area. This deserves a way to specify it -- at least in the case > where that microphone's sound output is separately available. > > In many cases, the sound engineer will wish to only offer one mixer > output (hopefully stereo or surround) for the entire room. But when the > individual microphones are separately available, it would be very helpful > to know the area each is intended to cover. This will not be a rectangle, > so I advise defining it as a polygon. > > -- > John Leslie > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon May 12 04:06: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 C15EF1A066F for ; Mon, 12 May 2014 04:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbQHARVbUSEf for ; Mon, 12 May 2014 04:06:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 61A871A0677 for ; Mon, 12 May 2014 04:06:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id BF215C94BD; Mon, 12 May 2014 07:06:16 -0400 (EDT) Date: Mon, 12 May 2014 07:06:16 -0400 From: John Leslie To: clue@ietf.org Message-ID: <20140512110616.GO20206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/eWGB3bMOYuC8IZ3P4X9y3y5s_rg Subject: [clue] Add an attribute for sensitivity pattern of microphones X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 11:06:27 -0000 Actual microphones are never equally sensitive in every direction. So-called "omnidirectional" microphones are noticeably less sensitive to sounds 90 degrees off-axis. This sensitivity also varies with frequency. "Cardioid" microphones have a pronounced null 180 degrees off-axis. There are also "shotgun" microphones and "noise-cancelling" microphones which have pronounced patterns. Not every sound engineer will want to reveal which kind of microphone is being used for each pickup point (or, perhaps, even know the difference). But sensitivity pattern is needed to fully describe individual microphone media streams. Thus I recommend adding an element for audioCapturePattern to the audioCaptureType: an enumeration value, initially "generic omnidirectional", "generic cardioid", and "unknown". There will be a need to expand the possible values, and I propose an IANA registry first-come-first-served. -- John Leslie From nobody Mon May 12 04:12: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 803C01A066F for ; Mon, 12 May 2014 04:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esqLY2SWNM9f for ; Mon, 12 May 2014 04:12:25 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 232361A0683 for ; Mon, 12 May 2014 04:12:25 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 24E05C94BD; Mon, 12 May 2014 07:12:18 -0400 (EDT) Date: Mon, 12 May 2014 07:12:18 -0400 From: John Leslie To: clue@ietf.org Message-ID: <20140512111218.GP20206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3MtUK8TrQHGMqo8Y01dwkGimnAY Subject: [clue] Attribute to indicate whether echo cancellation is done X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 11:12:26 -0000 Add an attribute (per audio source) to indicate whether echo cancellation is done ==== In any teleconferencing room with both speakers and microphones, "echo" must be considered. Sound received from remote locations plays through your loudspeakers, reverberates through the room (with some delay), and is picked up by your microphones. If ignored, this signal feeds through network delay back to its original source; and the process repeats. This problem too often destroys communication when someone unmutes the microphones in order to speak. Telepresence requires echo cancellation (where the reverberation is modeled and subtracted from the audio signal you send) to be performed by the sender. But there will be cases where some sender doesn't do it; and there will probably be cases where echo cancellation is only done for the mixed whole-room feed. Thus I recommend an attribute for audioEchoRemoval to the audioCaptureType: an enumeration value, selected from "echo cancellation done", "echo suppression done", or "none". Obviously, if receivers choose to use an audioCapture which does no echo cancellation, they must find a way to keep echo under control. Feeding it only to headphones/earbuds will always work; ensuring that every participant is close-miked will often work; and to some degree including it in your own echo-cancellation processing might be good enough... -- John Leslie From nobody Mon May 12 04:18: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 7F9BB1A067D for ; Mon, 12 May 2014 04:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28R4hMDIHGSb for ; Mon, 12 May 2014 04:18:00 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A59BC1A067C for ; Mon, 12 May 2014 04:18:00 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A7C7DC94A8; Mon, 12 May 2014 07:17:53 -0400 (EDT) Date: Mon, 12 May 2014 07:17:53 -0400 From: John Leslie To: Christian Groves Message-ID: <20140512111753.GQ20206@verdi> References: <20140509144352.GH20206@verdi> <53703A1F.6070909@nteczone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53703A1F.6070909@nteczone.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Yw1AYOFtdrQoBvlgiTNWYyaW2vI Cc: clue@ietf.org Subject: Re: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 11:18:01 -0000 Christian Groves wrote: > > Do you propose that the audioCapturePolygon has a relationship to the > capturePoint/lineOfCapturePoint. There is (IMHO) no necessary relationship. Sometimes the microphone will be a boundary microphone positioned on a table (with axis upward); sometimes it will be a mix of cardioid microphones aimed inward; and there are _many_ other possibilities. -- John Leslie From nobody Mon May 12 04:47: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 0FAC51A069B for ; Mon, 12 May 2014 04:47:53 -0700 (PDT) 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 1DY45EfOUqt7 for ; Mon, 12 May 2014 04:47:51 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2D71A067A for ; Mon, 12 May 2014 04:47:51 -0700 (PDT) Received: from ppp118-209-77-85.lns20.mel4.internode.on.net ([118.209.77.85]:50489 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wjogy-0004A9-AC; Mon, 12 May 2014 21:46:48 +1000 Message-ID: <5370B4DD.2020301@nteczone.com> Date: Mon, 12 May 2014 21:47:41 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Leslie References: <20140509144352.GH20206@verdi> <53703A1F.6070909@nteczone.com> <20140512111753.GQ20206@verdi> In-Reply-To: <20140512111753.GQ20206@verdi> 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/O1yHIobNkvrc4gOoNM-8N0r215k Cc: clue@ietf.org Subject: Re: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 11:47:53 -0000 OK then we should make it clear if we go for audioCapturePolygon that the capturePoint/lineOfCapturePoint only apply to the video case. Christian On 12/05/2014 9:17 PM, John Leslie wrote: > Christian Groves wrote: >> Do you propose that the audioCapturePolygon has a relationship to the >> capturePoint/lineOfCapturePoint. > There is (IMHO) no necessary relationship. Sometimes the microphone > will be a boundary microphone positioned on a table (with axis upward); > sometimes it will be a mix of cardioid microphones aimed inward; and > there are _many_ other possibilities. > > -- > John Leslie > From nobody Mon May 12 05:02: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 3DB2D1A06FA for ; Mon, 12 May 2014 05:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgivXV2QVgme for ; Mon, 12 May 2014 05:02:00 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id ACA951A06F9 for ; Mon, 12 May 2014 05:02:00 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6AF4EC94BF; Mon, 12 May 2014 08:01:53 -0400 (EDT) Date: Mon, 12 May 2014 08:01:53 -0400 From: John Leslie To: Christian Groves Message-ID: <20140512120153.GR20206@verdi> References: <20140509144352.GH20206@verdi> <53703A1F.6070909@nteczone.com> <20140512111753.GQ20206@verdi> <5370B4DD.2020301@nteczone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5370B4DD.2020301@nteczone.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/dbBeOOrsnLUrICVZt37Y--gLCzc Cc: clue@ietf.org Subject: Re: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 12:02:03 -0000 Christian Groves wrote: > On 12/05/2014 9:17 PM, John Leslie wrote: >> Christian Groves wrote: >> >>> Do you propose that the audioCapturePolygon has a relationship to the >>> capturePoint/lineOfCapturePoint. >> >> There is (IMHO) no necessary relationship. Sometimes the microphone >> will be a boundary microphone positioned on a table (with axis upward); >> sometimes it will be a mix of cardioid microphones aimed inward; and >> there are _many_ other possibilities. > > OK then we should make it clear if we go for audioCapturePolygon that > the capturePoint/lineOfCapturePoint only apply to the video case. I don't follow... audioCapturePolygon is about the _intent_, while capturePoint is about what the microphone _is_ recording. These are different purposes. Note, BTW, that a mixer output _already_ has no capturePoint. Both metrics are necessarily optional... -- John Leslie From nobody Mon May 12 05:42:33 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D108F1A0693 for ; Mon, 12 May 2014 05:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 eNsI_Sw0Sja5 for ; Mon, 12 May 2014 05:42:30 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6368D1A068C for ; Mon, 12 May 2014 05:42:30 -0700 (PDT) Received: from [216.82.254.19:62038] by server-4.bemta-7.messagelabs.com id 28/31-05677-0B1C0735; Mon, 12 May 2014 12:42:24 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-16.tower-96.messagelabs.com!1399898543!3601668!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 698 invoked from network); 12 May 2014 12:42:23 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-16.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 12 May 2014 12:42:23 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by crpehubprd02.polycom.com ([::1]) with mapi; Mon, 12 May 2014 05:41:33 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Mon, 12 May 2014 05:41:32 -0700 Thread-Topic: [clue] voice activated switching example for the Framework Thread-Index: Ac9tiesI8ZW7mHL+STGN1uTdEQ/i/wAVK4Tg Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F0110ABDE@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F13E179@CRPMBOXPRD08.polycom.com> <536C460F.4060001@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13E611@CRPMBOXPRD08.polycom.com> <537031DB.2080306@nteczone.com> In-Reply-To: <537031DB.2080306@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/2YVcozxPga6qzJJEGwtG67Hq4uk Subject: Re: [clue] voice activated switching example for the Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 12:42:33 -0000 Hi Christian, More below. Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Sunday, May 11, 2014 10:29 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] voice activated switching example for the Framework >=20 > Hello Mark, >=20 > Please see below. >=20 > Regards, Christian >=20 > On 10/05/2014 7:51 AM, Duckworth, Mark wrote: > > Hi Christian, > > thanks for the feedback. more below. > > Mark > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >> Groves > >> Sent: Thursday, May 08, 2014 11:06 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] voice activated switching example for the > >> Framework > >> > >> Hello Mark, > >> > >> Please see my comments below. > >> > >> Regards, Christian > >> > >> On 7/05/2014 7:22 AM, Duckworth, Mark wrote: > >>> I had an action item from IETF89 to add an example to the Framework > >>> to > >> show how an MCU can implement "voice activated switching" with > >> endpoints that send multiple video streams, so the MCU can choose one > >> to send to a simple endpoint that receives only one video stream. To > >> do this, we want to use a switched MCC from the multi-camera > >> endpoints to the MCU to carry the active talker video from each endpoi= nt. > >>> This example also addresses, at least in some cases, the issue Steve > >>> brought up about cases where "talker identification does not work". > >>> http://www.ietf.org/mail-archive/web/clue/current/msg03733.html > >>> > >>> Here is my proposed text to add to the Framework, in the Examples > >> (Informative) section: > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D begin proposed text > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> 12.3.4. > >>> Heterogeneous conference with voice activated switching > >>> > >>> This example illustrates how multipoint "voice activated switching" > >> behavior can be realized, with an endpoint making its own decision > >> about which of its outgoing video streams is considered the "active > >> talker" from that endpoint. Then an MCU can decide which is the > >> active talker among the whole conference. > >>> Consider a conference between endpoints with the following > >> characteristics: > >>> Endpoint A - 3 screens, 3 cameras > >>> Endpoint B - 3 screens, 3 cameras > >>> Endpoint C - 1 screen, 1 cameras > >> [CNG] Editorial nit: 1 camera delete > >>> This example focuses on what the user at endpoint C sees. The user > >>> would > >> like to see the video capture of the current talker, without > >> composing it with any other video capture. In this example endpoint > >> C is capable of receiving only a single video stream. The following > >> tables describe advertisements from A and B to the MCU, and from the > >> MCU to C, that can be used to accomplish this. > >>> +-----------------------+---------------------------------+ > >>> | Capture Scene #1 | Description=3DEndpoint x | > >>> +-----------------------|---------------------------------+ > >>> | VC1 | CaptureArea=3DLeft | > >>> | | EncodingGroup=3D1 | > >>> | VC2 | CaptureArea=3DCenter | > >>> | | EncodingGroup=3D1 | > >>> | VC3 | CaptureArea=3DRight | > >>> | | EncodingGroup=3D1 | > >>> | MCC1(VC1,VC2,VC3) | MaxCaptures=3D1 | > >>> | | CaptureArea=3Dwhole scene | > >>> | | Policy=3DSoundLevel:0 | > >>> | | EncodingGroup=3D1 | > >>> | AC1 | CaptureArea=3Dwhole scene | > >>> | | EncodingGroup=3D2 | > >>> | CSE1(VC1, VC2, VC3) | | > >>> | CSE2(MCC1) | | > >>> | CSE3(AC1) | | > >>> +---------------------------------------------------------+ > >>> Table 25: Advertisement received at the MCU from Endpoints A and B > >>> > >>> Endpoints A and B are advertising each individual video capture, and > >>> also a > >> switched capture MCC1 which switches between the other three based > on > >> who is the active talker. These endpoints do not advertise distinct > >> audio captures associated with each individual video capture, so it > >> would be impossible for the MCU (as a media consumer) to make its own > >> determination of which video capture is the active talker based just > >> on information in the audio streams. > >>> +-----------------------+---------------------------------+ > >>> | Capture Scene #1 | Description=3Dconference | > >>> +-----------------------|---------------------------------+ > >>> | MCC1() | CaptureArea=3DLeft | > >>> | | MaxCaptures=3D1 | > >>> | | SynchronisationID=3D1 | > >>> | | Policy=3DSoundLevel:0 | > >>> | | EncodingGroup=3D1 | > >>> | | | > >>> | MCC2() | CaptureArea=3DCenter | > >>> | | MaxCaptures=3D1 | > >>> | | SynchronisationID=3D1 | > >>> | | Policy=3DSoundLevel:0 | > >>> | | EncodingGroup=3D1 | > >>> | | | > >>> | MCC3() | CaptureArea=3DRight | > >>> | | MaxCaptures=3D1 | > >>> | | SynchronisationID=3D1 | > >>> | | Policy=3DSoundLevel:0 | > >>> | | EncodingGroup=3D1 | > >>> | | | > >>> | MCC4() | CaptureArea=3Dwhole scene | > >>> | | MaxCaptures=3D1 | > >>> | | Policy=3DSoundLevel:0 | > >>> | | EncodingGroup=3D1 | > >>> | | | > >>> | MCC5() (for audio) | CaptureArea=3Dwhole scene | > >>> | | MaxCaptures=3D1 | > >>> | | Policy=3DSoundLevel:0 | > >>> | | EncodingGroup=3D2 | > >>> | | | > >>> | MCC6() (for audio) | CaptureArea=3Dwhole scene | > >>> | | MaxCaptures=3D1 | > >>> | | Policy=3DSoundLevel:1 | > >>> | | EncodingGroup=3D2 | > >>> | CSE1(MCC1,MCC2,MCC3 | | > >>> | CSE2(MCC4) | | > >>> | CSE3(MCC5,MCC6) | | > >>> +---------------------------------------------------------+ > >>> Table 26: Advertisement sent from the MCU to C > >>> > >>> The MCU advertises one scene, with four video MCCs. Three of them > >>> in > >> CSE1 give a left, center, right view of the conference, with "site > switching". > >> MCC4 provides a single video capture representing a view of the whole > >> conference, which is simply switched between all the other original > >> source captures. > >> [CNG] According to the above table from a MC perspective it wouldn't > >> know which sources are included. Nothing about the original sources > >> has been advertised. > > [Duckworth, Mark] Correct. That is allowed according to the definition= of > an MCC. > > I want to keep this example as simple as possible to illustrate the > > point, and it isn't necessary to include all those other captures witho= ut > encoding groups in order to do that. > [CNG] That's fine, however I think its worth to add a note that the sourc= e > captures would be sent but not included for brevity reasons. > Otherwise the MC doesn't know that they are simply switched between all > the other original source captures." [Duckworth, Mark] The MCU, as a provider, certainly could advertise informa= tion about all the other endpoint scenes, but it doesn't have to. My inten= t with this particular example is the MCU does not advertise all those othe= r scenes. I think the example works fine without it. The endpoints, as co= nsumers, do not *need* to know all that. Possibly if that information was = included in the MCUs advertisement it could enable other behavior, but that= 's not what this example is about. > >> There's no description of MCC5 and MCC6 and CSE3? Does the MCU need > >> to send two Audio MCCs? > > [Duckworth, Mark] MCC5 and MCC6 have a bunch of attributes describing > them, so I'm not sure what you mean? > > Maybe the MCU should advertise: > > CSE3(MCC5, MCC6) > > CSE4(MCC5) > > This would make it clear the advertisement suggests MCC5 if the consume= r > wants just one audio capture. > [CNG] I mean there's no text procedural description saying what these are= . > The video MCCs also have attributes but you describe the video in the > paragraph below the table. [Duckworth, Mark] I understand. I can add a sentence or two. > >>> Endpoint C, in its configure message to the MCU, requests to receive > >>> MCC4. In order for the MCU to get the > >> [CNG] And an audio capture/s? > > [Duckworth, Mark] Yes, I will add that for completeness in the text. > > > >>> information it needs to construct MCC4, it has to send configure > messages > >> to A and B asking to receive MCC1 from each of them, along with their > AC1 > >> audio. Now the MCU can use audio energy information from the two > >> incoming audio streams from A and B to determine which of those > >> alternatives is the current talker. Based on that, the MCU uses eithe= r > MCC1 > >> from A or MCC1 from B as the source of MCC4 to send to C. > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D end proposed text > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D From nobody Mon May 12 07:02:52 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5141B1A0717 for ; Mon, 12 May 2014 07:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP7kQ_-gW_m0 for ; Mon, 12 May 2014 07:02:49 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A66B21A0716 for ; Mon, 12 May 2014 07:02:49 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C39B7C94C2; Mon, 12 May 2014 10:02:40 -0400 (EDT) Date: Mon, 12 May 2014 10:02:40 -0400 From: John Leslie To: clue@ietf.org Message-ID: <20140512140240.GS20206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/AULjkVXJ4NftjPqcAt8ZwLqG0aY Subject: [clue] Rendering mono sources using multiple loudspeakers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 14:02:51 -0000 Receiver tactics for rendering mono sources using multiple loudspeakers ==== When individual microphone sources are available to a receiver, the receiver may render the sound differently from the sender's mixer output. This is not a trivial thing. But there will be cases where the receiver must do this. A common case will be a remote individual (in an airport, perhaps) participating in discussion of a single issue. That individual will likely be shown in a more-or-less fixed position in the rendered video; and we should trust the receiving sound manager to render the mono audio to appear to come from that area of the screen (or be muted when the signal/noise ration is too low). There will be other cases where, for whatever reason, there is no usable full-room mix or there is no screen real-estate to show that room; but individuals in that room speak, and the receiver can show video including the person speaking. The interesting issue arises when there are multiple microphone mediaCaptures and one must be chosen to be rendered to match the video position. Clearly there are proprietary tricks outside the scope of this standard. But we note that measuring relative delay of each available microphone can show which microphone is closest to the speaker. Unfortunately, this is difficult for the receiver -- while it is easy for the sender to measure this. I recommend we consider a per-participant attribute to link to the "nearest" microphone. In some cases this will be a lavalier mike; in other cases it will be a fixed-position mike which the sender calculates to be closest (whether determined statically or dynamically). I think it would also help to include an attribute for whether the microphone is worn (thus moving when the participant moves) or attached to furniture, etc. Note that having a lavalier or gooseneck mike for each individual expected to talk will be very helpful to some receivers. -- John Leslie From nobody Mon May 12 07:50:52 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA001A01EA for ; Mon, 12 May 2014 07:50:44 -0700 (PDT) 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 KX8F_TYXFiGo for ; Mon, 12 May 2014 07:50:43 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 6F93E1A0733 for ; Mon, 12 May 2014 07:50:43 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta06.westchester.pa.mail.comcast.net with comcast id 10Kd1o0021ap0As562qdKu; Mon, 12 May 2014 14:50:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 12qd1o0083ZTu2S3i2qdyz; Mon, 12 May 2014 14:50:37 +0000 Message-ID: <5370DFBD.9010600@alum.mit.edu> Date: Mon, 12 May 2014 10:50:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140509143846.GG20206@verdi> In-Reply-To: <20140509143846.GG20206@verdi> 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=1399906237; bh=OKmcsG8SZNMfx/iwa+aCJZU/8dlPpfAtv0Vzu9ifmfI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Gy/Cmz9R4xZTm+sblVy0BneWH2IPc7VxqHLdHpvpjIr3FLwLFbX9aJ7EwU/0tI+oZ v87240BHcMBqVa2mLRCeXMf/uUiL1IBFbs+FTX03zs/EFmusb18nLd4Zkpb+4DSLmz 6uLpyrfAue8tRBeeBVE8lIyqPN4VOvXHxkzpOKs9q1GRxMeXi/L4WcB6l8+VlBf0IO w96DiXohxdvNz30IRAtzc/MnKzzZUVWhr6bzOj38gOlG9IiR5PkrmMrOz7Wulmajd4 ZV3+Mkulqlr2IZfsmPOloWUwNGXwanVeGcoh+ZOTLoBuUQmjHOELBuKJfLNMJlBC8d GDpSh4tlQb5Ew== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/U75Qqr91QNT6BzqcHXh-0Xnp94E Subject: Re: [clue] Note that XY-stereo microphones are commonly available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 14:50:45 -0000 On 5/9/14 10:38 AM, John Leslie wrote: > A mediaCapture can refer to a stereo microphone; but the > audioChannelFormat for "stereo" is too generic, IMHO. An XY-stereo > microphone produces two streams which represent ~90 degrees difference > in orientation, but no difference in position. > > This is very useful, but needs to be processed entirely differently > from a stereo pair separated by a significant distance and aimed in > approximately the same direction. ISTM that in case of stereo there are at least two different axis of capture values and possibly two point of capture values. We don't have a way to represent that in a description of a single unmixed capture. We could try to expand the definition to allow it, or we could simply expect a stereo capture to be described as a mix. Since I think it can be done as a mix, that seems preferable to me. Thanks, Paul > Clearly, the audioChannelFormat enumeration-list needs to be > expandable, and we should specify how to expand it in the future > (e.g. IANA-FCFS) > > -- > John Leslie > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon May 12 07:54: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 BB7231A0712 for ; Mon, 12 May 2014 07:54:30 -0700 (PDT) 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 is23JZV13WrJ for ; Mon, 12 May 2014 07:54:29 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 97BFA1A01EA for ; Mon, 12 May 2014 07:54:29 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta09.westchester.pa.mail.comcast.net with comcast id 112a1o0041GhbT8592uPkz; Mon, 12 May 2014 14:54:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id 12uP1o00V3ZTu2S3T2uP0M; Mon, 12 May 2014 14:54:23 +0000 Message-ID: <5370E09F.5050401@alum.mit.edu> Date: Mon, 12 May 2014 10:54:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140509142847.GD20206@verdi> <537032FA.1010601@nteczone.com> In-Reply-To: <537032FA.1010601@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=1399906463; bh=JKM0too3fEUT0aLC8F3dtKY3tklfbJVdgiAzSlFwfuI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QJauwcARxfUDVnjmAbWu/ltcBhu5Y2Cw74lg5ErNCHvzwyWo3kvFjrZ9Wd+h9u5Nb fg8zNBMWqTToeKfT7XJ1qVca56wYNcPbk8jEPLsXJv9B79/Nq8VG5tsJ3rW9mLy0go BlmmqtPohELM11p3DbdEzFODmEW67y1iEsFF76vEDqZkTYyNEZFi+P2NTOksLDI+YW D/6sEhnmFXTMkhcqTMjChQBAxkMBISf6uUfRuORtHgM6hP/grPl9CiFoVv41KY5gID FzZcKgG8yYV3oxkGsxxblgNZHc3yWiRPlaywzhXUvryY72wvwG3AY1e3xJn+O41EN9 9fxJipMlnn10A== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/0ReTuzhD4wTYez9g80qVKdVwljc Subject: Re: [clue] Add surround-sound type X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 14:54:30 -0000 On 5/11/14 10:33 PM, Christian Groves wrote: > Hello John, > > I had earlier proposed to change the audioChannelFormatType to a number > (i.e. number of channels) to aid extension, e.g. > 1 = mono > 2 = stereo > 5 = 5.1 surround sound This seems to be the same problem as stereo. Again, each component needs its own point of capture and axis of capture, and this can be described as a mix. The number of inputs to the mix is then obvious from the MCC declaration. We then *may* need something more to describe how the mix is done. Thanks, Paul > So I'm OK with adding 5.1 and I agree that with for this (and all CLUE > attributes) we need to specify how to extent them. > > Regards, > Christian > > On 10/05/2014 12:28 AM, John Leslie wrote: >> We need a surround-sound audioChannelFormatType: I recommend 5.1 >> (letting others fight whether it's Dolby or DTS or both). >> >> This is needed to satisfy REQMT-2a, IMHO. >> >> Clearly, the audioChannelFormat enumeration-list needs to be >> expandable, and we should specify how to expand it in the future (e.g. >> IANA-FCFS) >> >> -- >> John Leslie >> >> _______________________________________________ >> clue mailing 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 May 12 08:05: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 356861A072A for ; Mon, 12 May 2014 08:05:36 -0700 (PDT) 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 YmYpCg1ySfvu for ; Mon, 12 May 2014 08:05:35 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 87D291A0735 for ; Mon, 12 May 2014 08:05:16 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id 12pK1o0031c6gX85D35Asx; Mon, 12 May 2014 15:05:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id 135A1o00A3ZTu2S3j35A8E; Mon, 12 May 2014 15:05:10 +0000 Message-ID: <5370E325.7050407@alum.mit.edu> Date: Mon, 12 May 2014 11:05:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140509144352.GH20206@verdi> <53703A1F.6070909@nteczone.com> <20140512111753.GQ20206@verdi> <5370B4DD.2020301@nteczone.com> <20140512120153.GR20206@verdi> In-Reply-To: <20140512120153.GR20206@verdi> 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=1399907110; bh=9iRAW+Xrn6p6yNwxtk4ci5iyxQn9GOwInskXmVWcaW8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wHkpbDuhkBLGP/E5OZ325DEUqMrvrhivyH0dP4Rx999VxTi0v+glE+3xhMdTq6yy+ fdNwD3Sk/Ewer8YhHAAFe4lfCOQnDE/Ld60CSmdMvQGUKOTiTRUJGf18h/yOcY4Pxu y5sw09Shiu1BhenYK2kpzqWphnXP+vBDubI9BP1+exKjAd8IQd5QgSeZQT7vzeEPL2 nyUhvzp6meq8wWDTRiMxX6p+wIEp1O79ziCcgNtNmrFDsJB/nbjeBDYzLPG4ZpeOm/ TRtb9FM0vRokVvD2JsfqXxUA7Dzhi5acKp+Xifl0wK3hz+Dp6aSdGB6Wz1QXBVkC/B nImGQddsRvogA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/OU-P1KfkULJBLnHBIL96_tKJkHY Subject: Re: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 15:05:36 -0000 On 5/12/14 8:01 AM, John Leslie wrote: > Christian Groves wrote: >> On 12/05/2014 9:17 PM, John Leslie wrote: >>> Christian Groves wrote: >>> >>>> Do you propose that the audioCapturePolygon has a relationship to the >>>> capturePoint/lineOfCapturePoint. >>> >>> There is (IMHO) no necessary relationship. Sometimes the microphone >>> will be a boundary microphone positioned on a table (with axis upward); >>> sometimes it will be a mix of cardioid microphones aimed inward; and >>> there are _many_ other possibilities. >> >> OK then we should make it clear if we go for audioCapturePolygon that >> the capturePoint/lineOfCapturePoint only apply to the video case. > > I don't follow... audioCapturePolygon is about the _intent_, while > capturePoint is about what the microphone _is_ recording. These are > different purposes. I think I understand, to some degree. But you said that the audio level drops with the square of the distance from the mic. So is the capture polygon to be evaluated together with the point of capture? Is it your intent that the audio capture polygon be meaningful for mixes, while the point of capture isn't? Thanks, Paul > Note, BTW, that a mixer output _already_ has no capturePoint. Both > metrics are necessarily optional... > > -- > John Leslie > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon May 12 08:09: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 8966A1A071A for ; Mon, 12 May 2014 08:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tdOrEQzSyjU for ; Mon, 12 May 2014 08:09:18 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5481A0713 for ; Mon, 12 May 2014 08:09:18 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A97CFC94A9; Mon, 12 May 2014 11:09:09 -0400 (EDT) Date: Mon, 12 May 2014 11:09:09 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20140512150909.GU20206@verdi> References: <20140509143846.GG20206@verdi> <5370DFBD.9010600@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5370DFBD.9010600@alum.mit.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/37m9OgY75cVJLx2sTJrlBYpnUGw Cc: clue@ietf.org Subject: Re: [clue] Note that XY-stereo microphones are commonly available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 15:09:19 -0000 Paul Kyzivat wrote: > On 5/9/14 10:38 AM, John Leslie wrote: >> >> A mediaCapture can refer to a stereo microphone; but the >> audioChannelFormat for "stereo" is too generic, IMHO. An XY-stereo >> microphone produces two streams which represent ~90 degrees difference >> in orientation, but no difference in position. >> >> This is very useful, but needs to be processed entirely differently >> from a stereo pair separated by a significant distance and aimed in >> approximately the same direction. > > ISTM that in case of stereo there are at least two different axis of > capture values and possibly two point of capture values. We don't have a > way to represent that in a description of a single unmixed capture. An XY-stereo mike can be nicely represented by a single point of capture and two axes of capture; but in fact those two have a fixed relation to each other. Thus, using a single axis of capture, with the two offsets known, would be a perfect representation. (Alternatively, using the same "averaged" axis of capture, the two channels can be processed as two-dimensioned samples -- and reveal the actual direction to the source.) > We could try to expand the definition to allow it, or we could simply > expect a stereo capture to be described as a mix. The trouble with that is that there is no compatibility between microphone-pair-at-a-distance stereo and XY stereo. So we'd have to define two kinds of stereo output of a mixer. (Obviously, the mix could be reduced to mono; but then there's really no point in having two transducers at all.) > Since I think it can be done as a mix, that seems preferable to me. I really don't think that makes anything easier. -- John Leslie From nobody Mon May 12 08:16:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B083E1A0713 for ; Mon, 12 May 2014 08:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cObs1FOSkRBY for ; Mon, 12 May 2014 08:16:46 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0301A0697 for ; Mon, 12 May 2014 08:16:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C7317C94BE; Mon, 12 May 2014 11:16:38 -0400 (EDT) Date: Mon, 12 May 2014 11:16:38 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20140512151638.GV20206@verdi> References: <20140509142847.GD20206@verdi> <537032FA.1010601@nteczone.com> <5370E09F.5050401@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5370E09F.5050401@alum.mit.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/a-b34JWVYIOq1rYz_cokAlpVt_U Cc: clue@ietf.org Subject: Re: [clue] Add surround-sound type X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 15:16:47 -0000 Paul Kyzivat wrote: > On 5/11/14 10:33 PM, Christian Groves wrote: >> >> I had earlier proposed to change the audioChannelFormatType to a number >> (i.e. number of channels) to aid extension, e.g. >> 1 = mono >> 2 = stereo >> 5 = 5.1 surround sound > > This seems to be the same problem as stereo. Again, each component needs > its own point of capture and axis of capture, and this can be described > as a mix. While there _are_ detail differences in surround-sound miking, these aren't terribly important for sound reproduction, since the total (multi-channel) output represents a virtual room. (Stereo doesn't attempt a virtual room, so it means simply two channels. The reproduction is left to the student! XY stereo needs completely different reproduction from separate-mike stereo; and "binaural" needs headphones; etc.) > The number of inputs to the mix is then obvious from the MCC > declaration. We then *may* need something more to describe how the mix is done. My mind boggles at trying to describe in CLUE the many different ways a "mix" can be done. It boggles considerably more when we're talking about a mix with surround-sound output! -- John Leslie From nobody Mon May 12 08:24: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 DB4A51A0247 for ; Mon, 12 May 2014 08:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6gDX7vkLkLO for ; Mon, 12 May 2014 08:24:42 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD3E1A0711 for ; Mon, 12 May 2014 08:24:42 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 61A91C94BE; Mon, 12 May 2014 11:24:34 -0400 (EDT) Date: Mon, 12 May 2014 11:24:34 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20140512152434.GW20206@verdi> References: <20140509144352.GH20206@verdi> <53703A1F.6070909@nteczone.com> <20140512111753.GQ20206@verdi> <5370B4DD.2020301@nteczone.com> <20140512120153.GR20206@verdi> <5370E325.7050407@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5370E325.7050407@alum.mit.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/TQK5NSqFmhl04itOJHPhB82OQ2M Cc: clue@ietf.org Subject: Re: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 15:24:44 -0000 Paul Kyzivat wrote: > On 5/12/14 8:01 AM, John Leslie wrote: >>Christian Groves wrote: >>>On 12/05/2014 9:17 PM, John Leslie wrote: >>>> >>>> There is (IMHO) no necessary relationship. Sometimes the microphone >>>> will be a boundary microphone positioned on a table (with axis upward); >>>> sometimes it will be a mix of cardioid microphones aimed inward; and >>>> there are _many_ other possibilities. >>> >>> OK then we should make it clear if we go for audioCapturePolygon that >>> the capturePoint/lineOfCapturePoint only apply to the video case. >> >> I don't follow... audioCapturePolygon is about the _intent_, while >> capturePoint is about what the microphone _is_ recording. These are >> different purposes. > > I think I understand, to some degree. But you said that the audio level > drops with the square of the distance from the mic. Always, yes. > So is the capture polygon to be evaluated together with the point > of capture? I see no reason to do so. If a capture-polygon is given, the intent is that the entire contained area is "uniform enough". A receiver _could_, for an audioCapture with both axis-of-capture and capture-polygon, evaluate distance-to-speaker for participants; but it's probably not worth one's while to do anything about it. Most of the time, IMHO, you won't get both -- so I definitely wouldn't bother. > Is it your intent that the audio capture polygon be meaningful for > mixes, while the point of capture isn't? It's my expectation that it won't be there at all in most cases. Point-of-capture is typically meaningless for a mix -- only point-of-capture for the inputs to that mix make sense to me. -- John Leslie From nobody Mon May 12 08:26: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 6E7EC1A0712 for ; Mon, 12 May 2014 08:26:30 -0700 (PDT) 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 qeSbgpnHCiwH for ; Mon, 12 May 2014 08:26:28 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 45C741A0711 for ; Mon, 12 May 2014 08:26:28 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta13.westchester.pa.mail.comcast.net with comcast id 11PE1o0020vyq2s5D3SNnM; Mon, 12 May 2014 15:26:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id 13SM1o00M3ZTu2S3R3SMN9; Mon, 12 May 2014 15:26:22 +0000 Message-ID: <5370E81D.6080603@alum.mit.edu> Date: Mon, 12 May 2014 11:26:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140512111218.GP20206@verdi> In-Reply-To: <20140512111218.GP20206@verdi> 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=1399908382; bh=TV2D2Dn6OUkie5Abr+Rhrj5MFYcziGA0YiKloIs7TaE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tuwFrc7MB0E/Zkbv7Wpea+J1gOhe1rHli+Ea7IjjVf2oLZDc+TjjfjG5T8Xl9mR8Y DLmtAXuzK0LN/ESyDn50dIqDi3GfBiBuDxdQA3O4ilrWhJZROYN4JQKliDZx3pVsGg QLWr3HAeHeAVowHAHEwmwzYseilFwavZnWDVk2OUuU1gU3RNQ3YC09ifEQZZOKiv3l 8LjGZ4ytrKRjkyJUPmCEYczGU/YvcoptT0N18Opy9RXjj27KRCrEhITqZ67pDciIMt sRaBPVAxYx8eowUQsuXR0juro13c5HxGLChUwj00y2L6F7peJ09+atlVW/ueWdg2rH LkEM6nl/8x6hg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/4dPd_Czy4sncpEQLw79CxMenjEA Subject: Re: [clue] Attribute to indicate whether echo cancellation is done X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 15:26:30 -0000 Comment at end... On 5/12/14 7:12 AM, John Leslie wrote: > Add an attribute (per audio source) to indicate whether echo cancellation > is done > ==== > > In any teleconferencing room with both speakers and microphones, > "echo" must be considered. Sound received from remote locations > plays through your loudspeakers, reverberates through the room > (with some delay), and is picked up by your microphones. If ignored, > this signal feeds through network delay back to its original source; > and the process repeats. This problem too often destroys communication > when someone unmutes the microphones in order to speak. > > Telepresence requires echo cancellation (where the reverberation > is modeled and subtracted from the audio signal you send) to be > performed by the sender. But there will be cases where some sender > doesn't do it; and there will probably be cases where echo cancellation > is only done for the mixed whole-room feed. > > Thus I recommend an attribute for audioEchoRemoval to the > audioCaptureType: an enumeration value, selected from "echo > cancellation done", "echo suppression done", or "none". > > Obviously, if receivers choose to use an audioCapture which does > no echo cancellation, they must find a way to keep echo under control. > Feeding it only to headphones/earbuds will always work; ensuring that > every participant is close-miked will often work; and to some degree > including it in your own echo-cancellation processing might be good > enough... IMO the question is whether we want to include this possibility. Putting it in obligates every consumer to have logic to deal with it. Taking it out obligates every provider to ensure echo has been cancelled. Since most TP endpoints will have echo suppression, they won't be further burdened if we leave this out, but will have extra work to do if we add it. ISTM the cases that need most consideration are: - legacy mode clients. By definition we can't expect anything special about their behavior. An MCU that allows them into a clue conference will need to do *something* about this. - clue-aware devices that don't have the the equipment that a typcial TP room or endpoint has. E.g. a cell phone with the smarts to do the clue protocol. These might be common. Can we assume they will be capable of handling the echo suppression? Thanks, Paul From nobody Mon May 12 08:39: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 CA82D1A072D for ; Mon, 12 May 2014 08:39:36 -0700 (PDT) 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, MSGID_FROM_MTA_HEADER=0.001, 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 4drcuLZJHCOp for ; Mon, 12 May 2014 08:39:29 -0700 (PDT) Received: from blu0-omc1-s26.blu0.hotmail.com (blu0-omc1-s26.blu0.hotmail.com [65.55.116.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC1C1A0733 for ; Mon, 12 May 2014 08:39:29 -0700 (PDT) Received: from BLU0-SMTP43 ([65.55.116.9]) by blu0-omc1-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 May 2014 08:39:23 -0700 X-TMN: [huVAiqdcTKI8fvGXdzxjeTYmhDJbTH8F] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.38.66]) by BLU0-SMTP43.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 May 2014 08:39:22 -0700 From: Paul Coverdale To: "'John Leslie'" , References: <20140512110616.GO20206@verdi> In-Reply-To: <20140512110616.GO20206@verdi> Date: Mon, 12 May 2014 11:39:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9t0jb629XeHs/8Rlu3RXGszqr8lAAHwbaQ Content-Language: en-us X-OriginalArrivalTime: 12 May 2014 15:39:23.0044 (UTC) FILETIME=[590DFE40:01CF6DF8] Archived-At: http://mailarchive.ietf.org/arch/msg/clue/e9j83bNe9ZYcU8ePUmxVLIdEjz4 Subject: Re: [clue] Add an attribute for sensitivity pattern of microphones X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 15:39:37 -0000 >-----Original Message----- >From: clue [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie >Sent: Monday, May 12, 2014 7:06 AM >To: clue@ietf.org >Subject: [clue] Add an attribute for sensitivity pattern of microphones > > Actual microphones are never equally sensitive in every direction. >So-called "omnidirectional" microphones are noticeably less sensitive to >sounds 90 degrees off-axis. This sensitivity also varies with frequency. [Paul Coverdale] I guess you're referring to the free-field correction. If so, it's only noticeable at high frequencies, and depends on the microphone size. But I agree with the notion that a given "ideal" microphone pattern will not necessarily be achieved in practice, so the use of the term "generic" is more appropriate. > "Cardioid" microphones have a pronounced null 180 degrees off-axis. >There are also "shotgun" microphones and "noise-cancelling" microphones >which have pronounced patterns. > > Not every sound engineer will want to reveal which kind of microphone >is being used for each pickup point (or, perhaps, even know the >difference). But sensitivity pattern is needed to fully describe >individual microphone media streams. Thus I recommend adding an element >for audioCapturePattern to the audioCaptureType: >an enumeration value, initially "generic omnidirectional", "generic >cardioid", and "unknown". There will be a need to expand the possible >values, and I propose an IANA registry first-come-first-served. >-- >John Leslie > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From nobody Mon May 12 09:02: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 8E5311A0711 for ; Mon, 12 May 2014 09:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhmlyyvnE_go for ; Mon, 12 May 2014 09:02:53 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 039C81A0352 for ; Mon, 12 May 2014 09:02:53 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id BF235C94BD; Mon, 12 May 2014 12:02:44 -0400 (EDT) Date: Mon, 12 May 2014 12:02:44 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20140512160244.GY20206@verdi> References: <20140512111218.GP20206@verdi> <5370E81D.6080603@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5370E81D.6080603@alum.mit.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/w4kwdBEpU1LrrrUUiFnwYvs9QkU Cc: clue@ietf.org Subject: Re: [clue] Attribute to indicate whether echo cancellation is done X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 16:02:54 -0000 Paul Kyzivat wrote: > On 5/12/14 7:12 AM, John Leslie wrote: >>... >> Obviously, if receivers choose to use an audioCapture which does >> no echo cancellation, they must find a way to keep echo under control. >> Feeding it only to headphones/earbuds will always work; ensuring that >> every participant is close-miked will often work; and to some degree >> including it in your own echo-cancellation processing might be good >> enough... > > IMO the question is whether we want to include this possibility. Which possibility, exactly? > Putting it in obligates every consumer to have logic to deal with it. Sufficient logic to realize echo cancellation in what is sent has or has not been performed, yes. > Taking it out obligates every provider to ensure echo has been cancelled. Every sender, yes but... Some senders won't. :^( I tried to mention some of the cases in the text I elided. I suppose I could mention them again, but won't in this message. > Since most TP endpoints will have echo suppression, they won't be > further burdened if we leave this out, but will have extra work to do if > we add it. I can assure you that failure to cancel echo can be _very_ disruptive to communication. The echo cancellation one site does cannot protect that site from echo received. Echo _suppression_ can be applied to mute a source when echo is detected, but the detection can be a bit buggy, and a source which drops out in the middle of a word is also disruptive. > ISTM the cases that need most consideration are: > > - legacy mode clients. By definition we can't expect anything special > about their behavior. An MCU that allows them into a clue conference > will need to do *something* about this. Which is what I said, isn't it? > - clue-aware devices that don't have the the equipment that a typcial TP > room or endpoint has. E.g. a cell phone with the smarts to do the clue > protocol. These might be common. Can we assume they will be capable of > handling the echo suppression? IMHO: no. BTW, we should keep "echo suppression" distinct from "echo cancellation". Echo cancellation removes the reverberation of sound received from the sound you send; echo suppression merely mute the entire source when echo is "detected". But we can't reasonably expect smart-phones to do either. -- John Leslie From nobody Mon May 12 09:54:37 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563411A0756 for ; Mon, 12 May 2014 09:54:35 -0700 (PDT) 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, MSGID_FROM_MTA_HEADER=0.001, 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 CJ3y2S9y4dnv for ; Mon, 12 May 2014 09:54:33 -0700 (PDT) Received: from blu0-omc1-s29.blu0.hotmail.com (blu0-omc1-s29.blu0.hotmail.com [65.55.116.40]) by ietfa.amsl.com (Postfix) with ESMTP id 58D4F1A0761 for ; Mon, 12 May 2014 09:54:33 -0700 (PDT) Received: from BLU0-SMTP61 ([65.55.116.7]) by blu0-omc1-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 May 2014 09:54:26 -0700 X-TMN: [0bYzTMyyQZkrIhfBRARv4N228yLqT73A] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.38.66]) by BLU0-SMTP61.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 May 2014 09:54:26 -0700 From: Paul Coverdale To: "'John Leslie'" , "'Paul Kyzivat'" References: <20140509144352.GH20206@verdi> <53703A1F.6070909@nteczone.com> <20140512111753.GQ20206@verdi> <5370B4DD.2020301@nteczone.com> <20140512120153.GR20206@verdi> <5370E325.7050407@alum.mit.edu> <20140512152434.GW20206@verdi> In-Reply-To: <20140512152434.GW20206@verdi> Date: Mon, 12 May 2014 12:54:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9t9kq4fG3dpy3wRoKGx7lF8U1CoAACkmHg Content-Language: en-us X-OriginalArrivalTime: 12 May 2014 16:54:26.0302 (UTC) FILETIME=[D534A1E0:01CF6E02] Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Vu75BWP3G399N6brtbg1kIN8_to Cc: clue@ietf.org Subject: Re: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 16:54:35 -0000 I'm still having a hard time trying to understand what capture area (or polygon) means for audio. The sound waves that a microphone collects are defined by a volume, not an area. The waves emanating from further away just take longer to be picked up. So if you want to inform the other telepresence end-point as to the details of your local microphone arrangement (which I assume is what we're trying to do in CLUE....), it seems to me that the only useful information is the physical location of each microphone, its generic pattern type and its axis of orientation. Of course, one could say the same thing about using capture area for video - it implies zero depth of field. ...Paul >-----Original Message----- >From: clue [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie >Sent: Monday, May 12, 2014 11:25 AM >To: Paul Kyzivat >Cc: clue@ietf.org >Subject: Re: [clue] Add floor-area intended-capture area for mikes and >mixers > >Paul Kyzivat wrote: >> On 5/12/14 8:01 AM, John Leslie wrote: >>>Christian Groves wrote: >>>>On 12/05/2014 9:17 PM, John Leslie wrote: >>>>> >>>>> There is (IMHO) no necessary relationship. Sometimes the microphone >>>>> will be a boundary microphone positioned on a table (with axis >>>>> upward); sometimes it will be a mix of cardioid microphones aimed >>>>> inward; and there are _many_ other possibilities. >>>> >>>> OK then we should make it clear if we go for audioCapturePolygon >>>> that the capturePoint/lineOfCapturePoint only apply to the video >case. >>> >>> I don't follow... audioCapturePolygon is about the _intent_, while >>> capturePoint is about what the microphone _is_ recording. These are >>> different purposes. >> >> I think I understand, to some degree. But you said that the audio >> level drops with the square of the distance from the mic. > > Always, yes. > >> So is the capture polygon to be evaluated together with the point of >> capture? > > I see no reason to do so. > > If a capture-polygon is given, the intent is that the entire >contained area is "uniform enough". > > A receiver _could_, for an audioCapture with both axis-of-capture and >capture-polygon, evaluate distance-to-speaker for participants; but it's >probably not worth one's while to do anything about it. > > Most of the time, IMHO, you won't get both -- so I definitely >wouldn't bother. > >> Is it your intent that the audio capture polygon be meaningful for >> mixes, while the point of capture isn't? > > It's my expectation that it won't be there at all in most cases. > > Point-of-capture is typically meaningless for a mix -- only point-of- >capture for the inputs to that mix make sense to me. > >-- >John Leslie > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From nobody Mon May 12 10:16:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBF61A073C for ; Mon, 12 May 2014 10:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrqDvTLxX3MF for ; Mon, 12 May 2014 10:16:46 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC171A072A for ; Mon, 12 May 2014 10:16:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2C8ABC94BF; Mon, 12 May 2014 13:16:37 -0400 (EDT) Date: Mon, 12 May 2014 13:16:37 -0400 From: John Leslie To: Paul Coverdale Message-ID: <20140512171637.GB20206@verdi> References: <20140509144352.GH20206@verdi> <53703A1F.6070909@nteczone.com> <20140512111753.GQ20206@verdi> <5370B4DD.2020301@nteczone.com> <20140512120153.GR20206@verdi> <5370E325.7050407@alum.mit.edu> <20140512152434.GW20206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3iCZhHwAFFKj1aBnKb0hh1_lEew Cc: clue@ietf.org Subject: Re: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 17:16:47 -0000 Paul Coverdale wrote: > > I'm still having a hard time trying to understand what capture area (or > polygon) means for audio. The sound waves that a microphone collects are > defined by a volume, not an area. The waves emanating from further away just > take longer to be picked up. So if you want to inform the other telepresence > end-point as to the details of your local microphone arrangement (which I > assume is what we're trying to do in CLUE....), it seems to me that the only > useful information is the physical location of each microphone, its generic > pattern type and its axis of orientation. I mostly agree. > Of course, one could say the same thing about using capture area for video - > it implies zero depth of field. (Which is nonsense!) It _is_ possible, of course, to derive the pyramid which is the actual field of a camera; and it is possible to, for any point within that pyramid, determine the "closest" microphone (adjusting for sensitivity pattern). Folks don't seem to want to do that. So I explained a shortcut -- measuring propagation time to find the actually nearest microphone. This gets dicey, IMHO, unless it's done by the sender (which is the only party with all the possible sound sources synchronized in time. Thus the sender could do that calculation and rank distances from persons speaking to available microphones. Folks don't seem a lot more enthusiastic about that. Similarly, the sender could have the sound engineer record the _intended_ coverage area of microphones: that is what I recommended adding a way to record. Whether that will generate any enthusiasm, only time will tell. But it is a reasonably easy thing for any sound engineer who cares to do. Thus I thought it worth providing a way to signal it. YMMV, as always... -- John Leslie From nobody Mon May 12 10:50:01 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F901A0756 for ; Mon, 12 May 2014 10:49:59 -0700 (PDT) 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 sfx1DqaafSzv for ; Mon, 12 May 2014 10:49:58 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7218D1A075C for ; Mon, 12 May 2014 10:49:58 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id 0zr71o0021ZXKqc555psEx; Mon, 12 May 2014 17:49:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id 15pq1o00H3ZTu2S3h5pqWx; Mon, 12 May 2014 17:49:52 +0000 Message-ID: <537109BE.9080904@alum.mit.edu> Date: Mon, 12 May 2014 13:49:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Coverdale , 'John Leslie' References: <20140509144352.GH20206@verdi> <53703A1F.6070909@nteczone.com> <20140512111753.GQ20206@verdi> <5370B4DD.2020301@nteczone.com> <20140512120153.GR20206@verdi> <5370E325.7050407@alum.mit.edu> <20140512152434.GW20206@verdi> 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=1399916992; bh=UddvdY2oEHy7CxLPhJeOTfCjsP699MswPRmDNJBv0lA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=vFfgaqAfU70EKN+OHwxGzrKmGeYnQtRzt2nWBH7njsCpXO/Vmdtt5EyakCvyWGmPD Y4KBPsgeUvvsCS/LsS0xjEpXMq5brWmclI0YfQEq8bOCVLrkPuzP40bDj24bRvVDVO x9Fe4xi7ywTBnuHiHv08kqBApliiFwP6uwmzgVy8kSCYhe4xOGA8ueQaZ6maRp9q1D BKhaw0U0bAsB9kPjGj0tGJXEhI518Vqvf0HDZBma/HwEJSp5UCyIQaw1y1D11sqiAT qRpvxcJb3PSqs5tZKRT2oAt9ODIkgUAQcXeWYPHiRKszj+MAFmEW0lzGfGsuOsbezO OskCWE34qBElw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/7zvJUPkUxjh-Gy2wWAGLOcs1q-4 Cc: clue@ietf.org Subject: Re: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 17:50:00 -0000 On 5/12/14 12:54 PM, Paul Coverdale wrote: > I'm still having a hard time trying to understand what capture area (or > polygon) means for audio. The sound waves that a microphone collects are > defined by a volume, not an area. The waves emanating from further away just > take longer to be picked up. So if you want to inform the other telepresence > end-point as to the details of your local microphone arrangement (which I > assume is what we're trying to do in CLUE....), it seems to me that the only > useful information is the physical location of each microphone, its generic > pattern type and its axis of orientation. > > Of course, one could say the same thing about using capture area for video - > it implies zero depth of field. This has always troubled me a bit. I have been assuming that there is really a volume of capture that consists of the pyramid with peak at the point of capture with edges passing through the boundary of the area of capture, and continuing to the (unspecified) boundary of the scene. And that the area of capture is expected to be in focus, while the rest might not be. Thanks, Paul > ...Paul > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie >> Sent: Monday, May 12, 2014 11:25 AM >> To: Paul Kyzivat >> Cc: clue@ietf.org >> Subject: Re: [clue] Add floor-area intended-capture area for mikes and >> mixers >> >> Paul Kyzivat wrote: >>> On 5/12/14 8:01 AM, John Leslie wrote: >>>> Christian Groves wrote: >>>>> On 12/05/2014 9:17 PM, John Leslie wrote: >>>>>> >>>>>> There is (IMHO) no necessary relationship. Sometimes the microphone >>>>>> will be a boundary microphone positioned on a table (with axis >>>>>> upward); sometimes it will be a mix of cardioid microphones aimed >>>>>> inward; and there are _many_ other possibilities. >>>>> >>>>> OK then we should make it clear if we go for audioCapturePolygon >>>>> that the capturePoint/lineOfCapturePoint only apply to the video >> case. >>>> >>>> I don't follow... audioCapturePolygon is about the _intent_, while >>>> capturePoint is about what the microphone _is_ recording. These are >>>> different purposes. >>> >>> I think I understand, to some degree. But you said that the audio >>> level drops with the square of the distance from the mic. >> >> Always, yes. >> >>> So is the capture polygon to be evaluated together with the point of >>> capture? >> >> I see no reason to do so. >> >> If a capture-polygon is given, the intent is that the entire >> contained area is "uniform enough". >> >> A receiver _could_, for an audioCapture with both axis-of-capture and >> capture-polygon, evaluate distance-to-speaker for participants; but it's >> probably not worth one's while to do anything about it. >> >> Most of the time, IMHO, you won't get both -- so I definitely >> wouldn't bother. >> >>> Is it your intent that the audio capture polygon be meaningful for >>> mixes, while the point of capture isn't? >> >> It's my expectation that it won't be there at all in most cases. >> >> Point-of-capture is typically meaningless for a mix -- only point-of- >> capture for the inputs to that mix make sense to me. >> >> -- >> John Leslie >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From nobody Mon May 12 10:52: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 B3A7F1A077C for ; Mon, 12 May 2014 10:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 s0bPXQvyYn4h for ; Mon, 12 May 2014 10:52:40 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9D41A0757 for ; Mon, 12 May 2014 10:52:40 -0700 (PDT) Received: from [216.82.241.100:57369] by server-2.bemta-8.messagelabs.com id C6/EC-16293-26A01735; Mon, 12 May 2014 17:52:34 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-220.messagelabs.com!1399917152!3558115!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13688 invoked from network); 12 May 2014 17:52:33 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-9.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 12 May 2014 17:52:33 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 12 May 2014 10:52:32 -0700 From: "Duckworth, Mark" To: John Leslie Date: Mon, 12 May 2014 10:52:31 -0700 Thread-Topic: Audio channel format - RE: [clue] Note that XY-stereo microphones are commonly available Thread-Index: Ac9uCvJb53ihRP/hRtCkyIVneCA3Zw== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AC52@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/VoLpeabB20aZSmM1i9a8rwG9I7c Cc: "clue@ietf.org" Subject: [clue] Audio channel format - RE: Note that XY-stereo microphones are commonly available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 17:52:41 -0000 Hi John, Comments below. Mark > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: Sunday, May 11, 2014 9:55 PM > To: Duckworth, Mark > Cc: clue@ietf.org > Subject: Re: [clue] Note that XY-stereo microphones are commonly availabl= e >=20 > Duckworth, Mark wrote: > > > > I had a different proposal about the Audio Channel Format attribute. > > I think we should consider it along with John's proposals about 5.1 > > format and XY-stereo. > > > > I'm thinking this "audio channel format" parameter is really a > > characteristic of a particular audio *encoding*, not an audio *capture*= . >=20 > Hmm... That sounds funny... >=20 > > So my idea is we should remove this audio capture attribute from the > > framework and data model. The format of a particular audio encoding > > would be described entirely in SDP (not CLUE messages). >=20 > I'm not _opposed_ to that; but there are _so_many_details_... >=20 > > And a media provider could advertise one single audio capture for the > > whole room, which maybe it could encode as mono, or stereo, or > > 3 channel, or surround sound, or whatever. Or maybe even offer > > multiple encodings for simulcast, but these are still all just > > different encodings of the same audio capture. >=20 > Mark is correct that a whole-room feed may be appropriate to receive i= n > different formats: obviously folks who want to render mono might balk at > receiving six channels in order to do so. [Duckworth, Mark] Not just balk at it, I expect the endpoint that wants to = render mono=20 would be incapable of receiving a six channel audio encoding format. > I'm not sure how to manage that, though. If a mix is prepared in > 5.1 surround, I doubt that SDP is the right conduit for negotiating the n= umber > of channels -- offhand that sounds like a middlebox task. [Duckworth, Mark] Maybe we're talking about different things, because I thi= nk SDP is=20 exactly the right thing for this, and is commonly done today, at least with= stereo and=20 mono. Endpoints I am familiar with today are capable of encoding their out= going room audio=20 as mono, stereo, and in some cases 3 channel. If the receiving side (wheth= er middlebox=20 or another endpoint) is capable only of mono, then the sender and receiver = negotiate=20 mono. This is done with SDP offer/answer today. And I think it should be = done that way with CLUE also. > And I'm _sure_ SDP isn't the right conduit for remapping the component= s > of a whole-room feed to fit an incompatible conference room paradigm. >=20 > (Nonetheless, there probably should be _some_ consideration of > conserving bandwith for receivers that don't do surround-sound...) [Duckworth, Mark] It isn't about conserving bandwidth. It is about a recei= ver selecting an audio encoding format it is capable of decoding. >=20 > -- > John Leslie From nobody Mon May 12 10:55: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 A74EC1A0757 for ; Mon, 12 May 2014 10:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 zK4aYH_PiliH for ; Mon, 12 May 2014 10:55:37 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.113]) by ietfa.amsl.com (Postfix) with ESMTP id 483C51A0741 for ; Mon, 12 May 2014 10:55:37 -0700 (PDT) Received: from [216.82.254.20:16822] by server-17.bemta-7.messagelabs.com id FA/58-21050-21B01735; Mon, 12 May 2014 17:55:30 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-47.messagelabs.com!1399917329!3724246!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17249 invoked from network); 12 May 2014 17:55: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; 12 May 2014 17:55:30 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 12 May 2014 10:55:29 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , Paul Coverdale , 'John Leslie' Date: Mon, 12 May 2014 10:55:26 -0700 Thread-Topic: [clue] Add floor-area intended-capture area for mikes and mixers Thread-Index: Ac9uCpgBqQLFaeUATPui2KhVphF8cQAAHz7w Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AC58@CRPMBOXPRD08.polycom.com> References: <20140509144352.GH20206@verdi> <53703A1F.6070909@nteczone.com> <20140512111753.GQ20206@verdi> <5370B4DD.2020301@nteczone.com> <20140512120153.GR20206@verdi> <5370E325.7050407@alum.mit.edu> <20140512152434.GW20206@verdi> <537109BE.9080904@alum.mit.edu> In-Reply-To: <537109BE.9080904@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/gwPm6Am-l3bM5_RxW-MI7SFUT7c Cc: "clue@ietf.org" Subject: Re: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 17:55:38 -0000 Hi Paul, I agree with your assumption, but it doesn't trouble me :) And sometimes there won't be any point of capture, for example for a composed capture, so there is no defined volume. Yet the area of capture i= s still useful. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, May 12, 2014 1:50 PM > To: Paul Coverdale; 'John Leslie' > Cc: clue@ietf.org > Subject: Re: [clue] Add floor-area intended-capture area for mikes and > mixers >=20 > On 5/12/14 12:54 PM, Paul Coverdale wrote: > > I'm still having a hard time trying to understand what capture area > > (or > > polygon) means for audio. The sound waves that a microphone collects > > are defined by a volume, not an area. The waves emanating from further > > away just take longer to be picked up. So if you want to inform the > > other telepresence end-point as to the details of your local > > microphone arrangement (which I assume is what we're trying to do in > > CLUE....), it seems to me that the only useful information is the > > physical location of each microphone, its generic pattern type and its = axis of > orientation. > > > > Of course, one could say the same thing about using capture area for > > video - it implies zero depth of field. >=20 > This has always troubled me a bit. I have been assuming that there is rea= lly a > volume of capture that consists of the pyramid with peak at the point of > capture with edges passing through the boundary of the area of capture, a= nd > continuing to the (unspecified) boundary of the scene. And that the area = of > capture is expected to be in focus, while the rest might not be. >=20 > Thanks, > Paul >=20 > > ...Paul > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie > >> Sent: Monday, May 12, 2014 11:25 AM > >> To: Paul Kyzivat > >> Cc: clue@ietf.org > >> Subject: Re: [clue] Add floor-area intended-capture area for mikes > >> and mixers > >> > >> Paul Kyzivat wrote: > >>> On 5/12/14 8:01 AM, John Leslie wrote: > >>>> Christian Groves wrote: > >>>>> On 12/05/2014 9:17 PM, John Leslie wrote: > >>>>>> > >>>>>> There is (IMHO) no necessary relationship. Sometimes the > >>>>>> microphone will be a boundary microphone positioned on a table > >>>>>> (with axis upward); sometimes it will be a mix of cardioid > >>>>>> microphones aimed inward; and there are _many_ other > possibilities. > >>>>> > >>>>> OK then we should make it clear if we go for audioCapturePolygon > >>>>> that the capturePoint/lineOfCapturePoint only apply to the video > >> case. > >>>> > >>>> I don't follow... audioCapturePolygon is about the _intent_, while > >>>> capturePoint is about what the microphone _is_ recording. These are > >>>> different purposes. > >>> > >>> I think I understand, to some degree. But you said that the audio > >>> level drops with the square of the distance from the mic. > >> > >> Always, yes. > >> > >>> So is the capture polygon to be evaluated together with the point of > >>> capture? > >> > >> I see no reason to do so. > >> > >> If a capture-polygon is given, the intent is that the entire > >> contained area is "uniform enough". > >> > >> A receiver _could_, for an audioCapture with both axis-of-capture > >> and capture-polygon, evaluate distance-to-speaker for participants; > >> but it's probably not worth one's while to do anything about it. > >> > >> Most of the time, IMHO, you won't get both -- so I definitely > >> wouldn't bother. > >> > >>> Is it your intent that the audio capture polygon be meaningful for > >>> mixes, while the point of capture isn't? > >> > >> It's my expectation that it won't be there at all in most cases. > >> > >> Point-of-capture is typically meaningless for a mix -- only > >> point-of- capture for the inputs to that mix make sense to me. > >> > >> -- > >> John Leslie > >> > >> _______________________________________________ > >> 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 May 12 11:08: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 75CF71A0745 for ; Mon, 12 May 2014 11:08:45 -0700 (PDT) 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, MSGID_FROM_MTA_HEADER=0.001, 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 EuVvq_NNP9Mr for ; Mon, 12 May 2014 11:08:43 -0700 (PDT) Received: from blu0-omc1-s22.blu0.hotmail.com (blu0-omc1-s22.blu0.hotmail.com [65.55.116.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF771A0727 for ; Mon, 12 May 2014 11:08:43 -0700 (PDT) Received: from BLU0-SMTP94 ([65.55.116.9]) by blu0-omc1-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 May 2014 11:08:37 -0700 X-TMN: [Qt0HzrnRURhqf3lRWtGeTbjDjHBlHLko] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.38.66]) by BLU0-SMTP94.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 May 2014 11:08:36 -0700 From: Paul Coverdale To: "'John Leslie'" , "'Paul Kyzivat'" References: <20140512111218.GP20206@verdi> <5370E81D.6080603@alum.mit.edu> <20140512160244.GY20206@verdi> In-Reply-To: <20140512160244.GY20206@verdi> Date: Mon, 12 May 2014 14:08:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9t+5+qYHkpinyxSxmUMH6HyJAabQAD3wTA Content-Language: en-us X-OriginalArrivalTime: 12 May 2014 18:08:36.0920 (UTC) FILETIME=[31FB0B80:01CF6E0D] Archived-At: http://mailarchive.ietf.org/arch/msg/clue/N0LZV2ZZBBCD2pY-x-qD5Pgq5bw Cc: clue@ietf.org Subject: Re: [clue] Attribute to indicate whether echo cancellation is done X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 18:08:45 -0000 >-----Original Message----- >From: clue [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie >Sent: Monday, May 12, 2014 12:03 PM >To: Paul Kyzivat >Cc: clue@ietf.org >Subject: Re: [clue] Attribute to indicate whether echo cancellation is >done > >Paul Kyzivat wrote: >> On 5/12/14 7:12 AM, John Leslie wrote: >>>... >>> Obviously, if receivers choose to use an audioCapture which does no >>>echo cancellation, they must find a way to keep echo under control. >>> Feeding it only to headphones/earbuds will always work; ensuring that >>>every participant is close-miked will often work; and to some degree >>>including it in your own echo-cancellation processing might be good >>>enough... >> >> IMO the question is whether we want to include this possibility. > > Which possibility, exactly? > >> Putting it in obligates every consumer to have logic to deal with it. > > Sufficient logic to realize echo cancellation in what is sent has or >has not been performed, yes. > >> Taking it out obligates every provider to ensure echo has been >cancelled. > > Every sender, yes but... > > Some senders won't. :^( > > I tried to mention some of the cases in the text I elided. I suppose >I could mention them again, but won't in this message. > >> Since most TP endpoints will have echo suppression, they won't be >> further burdened if we leave this out, but will have extra work to do >> if we add it. > > I can assure you that failure to cancel echo can be _very_ disruptive >to communication. > > The echo cancellation one site does cannot protect that site from >echo received. Echo _suppression_ can be applied to mute a source when >echo is detected, but the detection can be a bit buggy, and a source >which drops out in the middle of a word is also disruptive. > >> ISTM the cases that need most consideration are: >> >> - legacy mode clients. By definition we can't expect anything special >> about their behavior. An MCU that allows them into a clue conference >> will need to do *something* about this. > > Which is what I said, isn't it? > >> - clue-aware devices that don't have the the equipment that a typcial >> TP room or endpoint has. E.g. a cell phone with the smarts to do the >> clue protocol. These might be common. Can we assume they will be >> capable of handling the echo suppression? > > IMHO: no. > > BTW, we should keep "echo suppression" distinct from "echo >cancellation". >Echo cancellation removes the reverberation of sound received from the >sound you send; echo suppression merely mute the entire source when echo >is "detected". [Paul Coverdale] This isn't entirely correct. Modern echo cancellers include both echo cancellation and echo suppression. The echo canceller tries to adaptively cancel out the linear (and sometimes non-linear) echo-path response but generally this doesn't provide sufficient echo-path loss alone. The remaining low-level echo is taken out by the non-linear processor (NLP) which is effectively an echo suppressor. I doubt that anybody is using echo suppression alone for conferencing, it would lead to very choppy audio (might as well just use push-to-talk) > > But we can't reasonably expect smart-phones to do either. [Paul Coverdale] Some smart-phones, maybe. But remember that the smart-phone only has to eliminate the echo that it generates itself (spec'd by terminal coupling loss). If it's good enough when it's talking to another cell-phone (or even land-line), it should be good enough when it's talking to a telepresence end-point. > >-- >John Leslie > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From nobody Mon May 12 11:16: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 922C01A0757 for ; Mon, 12 May 2014 11:16:25 -0700 (PDT) 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 FlvCn2Opx6XL for ; Mon, 12 May 2014 11:16:24 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 3240B1A074E for ; Mon, 12 May 2014 11:16:24 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 13fl1o00317dt5G5B6GJWL; Mon, 12 May 2014 18:16:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id 16GH1o00U3ZTu2S3Z6GHfP; Mon, 12 May 2014 18:16:18 +0000 Message-ID: <53710FF1.8000201@alum.mit.edu> Date: Mon, 12 May 2014 14:16:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Duckworth, Mark" , Paul Coverdale , 'John Leslie' References: <20140509144352.GH20206@verdi> <53703A1F.6070909@nteczone.com> <20140512111753.GQ20206@verdi> <5370B4DD.2020301@nteczone.com> <20140512120153.GR20206@verdi> <5370E325.7050407@alum.mit.edu> <20140512152434.GW20206@verdi> <537109BE.9080904@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F0110AC58@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AC58@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=1399918578; bh=4ToEiv2B14ZmPbikORb/jDAbmybeL1R5a3WvdCa7YCE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=R5Qk7WHpf9hEDSVYF8d4w+mcJu7G5ZTjtQ4nRly6JZXJ9fQtWSKcX766S7gvDNAHy LZxM2Ut0Aq78eIHmTVqABAZiXPCcQACniEuFnihRI3G/sxGulL8r7fbuEHd3ajr571 2MpfXnT55WNXyaDxiSoV3lIL93yUWenvs6vuKclj6KE2NFmxFC+7peoYtM+7KQvOsd An7BWJpMh5OpVx20IDDWVU13LtwsLIfnibl4kqHvXs8mHvlaOsFCVc0VSPB6bhtObA Z2LSqMIFbQGHst6+S03qkdp2IV7dfLqtNJ/PsntXGfxR7sq6DrPumugQ/BbjaPbJMr T8/U8IFsBoyLw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/l309UsGzpb02oG9vVXkRD6wRf-8 Cc: "clue@ietf.org" Subject: Re: [clue] Add floor-area intended-capture area for mikes and mixers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 18:16:25 -0000 On 5/12/14 1:55 PM, Duckworth, Mark wrote: > Hi Paul, > > I agree with your assumption, but it doesn't trouble me :) > And sometimes there won't be any point of capture, for example for a > composed capture, so there is no defined volume. Yet the area of capture is still useful. Yes, there might not be a point of capture. In that case we need to take greater pains to specify what whe area of capture *means*. If it is synthetic (e.g. a powerpoint) then this makes sense. A composed capture can probably be treated the same way. But then these cases present further problems for associating audio and video. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, May 12, 2014 1:50 PM >> To: Paul Coverdale; 'John Leslie' >> Cc: clue@ietf.org >> Subject: Re: [clue] Add floor-area intended-capture area for mikes and >> mixers >> >> On 5/12/14 12:54 PM, Paul Coverdale wrote: >>> I'm still having a hard time trying to understand what capture area >>> (or >>> polygon) means for audio. The sound waves that a microphone collects >>> are defined by a volume, not an area. The waves emanating from further >>> away just take longer to be picked up. So if you want to inform the >>> other telepresence end-point as to the details of your local >>> microphone arrangement (which I assume is what we're trying to do in >>> CLUE....), it seems to me that the only useful information is the >>> physical location of each microphone, its generic pattern type and its axis of >> orientation. >>> >>> Of course, one could say the same thing about using capture area for >>> video - it implies zero depth of field. >> >> This has always troubled me a bit. I have been assuming that there is really a >> volume of capture that consists of the pyramid with peak at the point of >> capture with edges passing through the boundary of the area of capture, and >> continuing to the (unspecified) boundary of the scene. And that the area of >> capture is expected to be in focus, while the rest might not be. >> >> Thanks, >> Paul >> >>> ...Paul >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie >>>> Sent: Monday, May 12, 2014 11:25 AM >>>> To: Paul Kyzivat >>>> Cc: clue@ietf.org >>>> Subject: Re: [clue] Add floor-area intended-capture area for mikes >>>> and mixers >>>> >>>> Paul Kyzivat wrote: >>>>> On 5/12/14 8:01 AM, John Leslie wrote: >>>>>> Christian Groves wrote: >>>>>>> On 12/05/2014 9:17 PM, John Leslie wrote: >>>>>>>> >>>>>>>> There is (IMHO) no necessary relationship. Sometimes the >>>>>>>> microphone will be a boundary microphone positioned on a table >>>>>>>> (with axis upward); sometimes it will be a mix of cardioid >>>>>>>> microphones aimed inward; and there are _many_ other >> possibilities. >>>>>>> >>>>>>> OK then we should make it clear if we go for audioCapturePolygon >>>>>>> that the capturePoint/lineOfCapturePoint only apply to the video >>>> case. >>>>>> >>>>>> I don't follow... audioCapturePolygon is about the _intent_, while >>>>>> capturePoint is about what the microphone _is_ recording. These are >>>>>> different purposes. >>>>> >>>>> I think I understand, to some degree. But you said that the audio >>>>> level drops with the square of the distance from the mic. >>>> >>>> Always, yes. >>>> >>>>> So is the capture polygon to be evaluated together with the point of >>>>> capture? >>>> >>>> I see no reason to do so. >>>> >>>> If a capture-polygon is given, the intent is that the entire >>>> contained area is "uniform enough". >>>> >>>> A receiver _could_, for an audioCapture with both axis-of-capture >>>> and capture-polygon, evaluate distance-to-speaker for participants; >>>> but it's probably not worth one's while to do anything about it. >>>> >>>> Most of the time, IMHO, you won't get both -- so I definitely >>>> wouldn't bother. >>>> >>>>> Is it your intent that the audio capture polygon be meaningful for >>>>> mixes, while the point of capture isn't? >>>> >>>> It's my expectation that it won't be there at all in most cases. >>>> >>>> Point-of-capture is typically meaningless for a mix -- only >>>> point-of- capture for the inputs to that mix make sense to me. >>>> >>>> -- >>>> John Leslie >>>> >>>> _______________________________________________ >>>> clue mailing 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 May 12 12:31: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 4B2EE1A07D0 for ; Mon, 12 May 2014 12:31:53 -0700 (PDT) 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 9LfMdSSnbh3j for ; Mon, 12 May 2014 12:31:52 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id EA44E1A07CF for ; Mon, 12 May 2014 12:31:51 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta05.westchester.pa.mail.comcast.net with comcast id 11Di1o0020bG4ec557Xl4u; Mon, 12 May 2014 19:31:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id 17Xl1o00P3ZTu2S3P7Xl8t; Mon, 12 May 2014 19:31:45 +0000 Message-ID: <537121A1.9000701@alum.mit.edu> Date: Mon, 12 May 2014 15:31:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140512140240.GS20206@verdi> In-Reply-To: <20140512140240.GS20206@verdi> 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=1399923105; bh=S+9VBdPXcG1yldieXPpzi/ZQqVoXIPj908d1UpxpMvQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rqUwrOx25f/D1u+k9d69x622wZftTRJzzvQguNAU0lVeLRQ71ckDdEgdJmuR4Yzgs I3WRZfksoxHjvsiEbcEI0lodq3ZEKROQnzfSrXaMsHn464Xf7fdYVPgvTNIIhhAcOC GYynorhmvwX0BmUg3edX5RcCigwhWK1LgQFo2QCfOWzwVwNGxKV+wC9A4BnA6JoZTq 2zFfzCtkKxf2Eh3GKTEHnv1AB10bPny2MjVMUZ4qHJmV1b8Egs8rmO3cseq4FZQLA1 jKgyZ75RPMohAQGbb8xZjLHoM4+FdcZHZGGQ2jZ66SSz6y7LOOYOMhMDx33bh7LNTd FF3WjSRp7uwzQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/e2QrOGQFil034647iGip4cddKR8 Subject: Re: [clue] Rendering mono sources using multiple loudspeakers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 19:31:53 -0000 On 5/12/14 10:02 AM, John Leslie wrote: > Receiver tactics for rendering mono sources using multiple loudspeakers > ==== > > When individual microphone sources are available to a receiver, > the receiver may render the sound differently from the sender's mixer > output. This is not a trivial thing. But there will be cases where > the receiver must do this. > > A common case will be a remote individual (in an airport, perhaps) > participating in discussion of a single issue. That individual will > likely be shown in a more-or-less fixed position in the rendered > video; and we should trust the receiving sound manager to render the > mono audio to appear to come from that area of the screen (or be > muted when the signal/noise ration is too low). The consumer is supposed to distinguish the above case from the below case by the presence of a single video and a single audio capture? > There will be other cases where, for whatever reason, there is no > usable full-room mix or there is no screen real-estate to show that > room; but individuals in that room speak, and the receiver can show > video including the person speaking. The interesting issue arises > when there are multiple microphone mediaCaptures and one must be > chosen to be rendered to match the video position. > > Clearly there are proprietary tricks outside the scope of this > standard. Proprietary tricks that work with the information made available from an arbitrary clue peer? Or based on knowledge that both parties have some agreement in addition to clue? Such an agreement had better not require non-standard usage of the standard clue signaling and protocol. (Though it could be based on *extensions* to that.) > But we note that measuring relative delay of each available > microphone can show which microphone is closest to the speaker. > Unfortunately, this is difficult for the receiver -- while it is > easy for the sender to measure this. > > I recommend we consider a per-participant attribute to link to > the "nearest" microphone. Do you really mean *participant*? Or do you mean per-video-capture? If you really mean participant, how do you expect that to be used here? Thanks, Paul > In some cases this will be a lavalier > mike; in other cases it will be a fixed-position mike which the > sender calculates to be closest (whether determined statically or > dynamically). I think it would also help to include an attribute for > whether the microphone is worn (thus moving when the participant > moves) or attached to furniture, etc. > > Note that having a lavalier or gooseneck mike for each individual > expected to talk will be very helpful to some receivers. > > -- > John Leslie > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon May 12 13:14: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 3FB891A0765 for ; Mon, 12 May 2014 13:14:23 -0700 (PDT) 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 XmPru31PJuZU for ; Mon, 12 May 2014 13:14:22 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0841A0727 for ; Mon, 12 May 2014 13:14:21 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta04.westchester.pa.mail.comcast.net with comcast id 15D11o0031wpRvQ548EFED; Mon, 12 May 2014 20:14:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 18EF1o00f3ZTu2S3e8EFJB; Mon, 12 May 2014 20:14:15 +0000 Message-ID: <53712B97.8040109@alum.mit.edu> Date: Mon, 12 May 2014 16:14:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <5367B0DC.9090509@alum.mit.edu> In-Reply-To: <5367B0DC.9090509@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=1399925655; bh=CGmH3xeXZswfRFiHkHK2y+bZJLmy+AAU/Zoc1VEtZ0Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iUtFqoctx0VVon+ox6CLowWIBO1ZtV8rcNqfD/Gfoi9grd409LiZyYnKF4zzJo6u3 vJqPHdPQQsGIkdDRPw09NPAMWPDHPkS+VC0BACE01+6UeSSJG6X2ympYpWj/4Sg9d9 Opr4OvuCn2mijGGAJq+QnGhg2zQ9zAXSHxmOpNSNtXbMmUNXq4/HypXwwWDoqgp1nG OyKFAyL72vgmEH/JFJ3oMPKJHO4zCIC6/XHl/0F/S8Sa23m2EO0gUoC086fO78rr6z 7iHdtLihtKaqJTsnJtdjJi9wxVBVbcROtBMs3jAbnYI8dJ5rNIOc91QU87TOVdFq7N UUFEfG1EkX+Ug== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/nKVg4DjLxgWsJ_Y9G2gAitfss2U Subject: Re: [clue] Design Team meeting tomorrow - May 13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 20:14:23 -0000 Thanks for the active list discussion on tomorrow's topic - audio issues. If you have any concerns or opinions about audio please join tomorrow and be ready to make decisions. Thanks, Paul On 5/5/14 11:40 AM, Paul Kyzivat wrote: > We have no topic scheduled for the design team meeting tomorrow (6-may), > so we won't hold that one. > > This does NOT mean you get the week off! > > We had productive sessions on signaling and protocol in past weeks. > Authors, please use this "free" time to get out new versions of those > documents reflecting decisions made. > > The purpose of the meeting next week (13-may) is to thrash out the audio > issues that we've been discussing on the mailing list for some time. > There has been a lot of heat, but it is unclear to me how much light. > Please come to that meeting prepared to make decisions. We need *text*. > The meeting is not the best place to *create* text, so please post > proposed text to the list prior to the meeting. > > And if you have an opinion on this that please be present on 13-may for > the call! If any of the active parties won't be able to be there please > inform us now! > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon May 12 13:26: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 8A72A1A076E for ; Mon, 12 May 2014 13:26:29 -0700 (PDT) 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 Pz42eKPdDccv for ; Mon, 12 May 2014 13:26:28 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8771A076B for ; Mon, 12 May 2014 13:26:28 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta08.westchester.pa.mail.comcast.net with comcast id 15ar1o0010EZKEL588SNDz; Mon, 12 May 2014 20:26:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id 18SM1o00d3ZTu2S3M8SMCk; Mon, 12 May 2014 20:26:22 +0000 Message-ID: <53712E6D.8050304@alum.mit.edu> Date: Mon, 12 May 2014 16:26:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Leslie References: <20140512111218.GP20206@verdi> <5370E81D.6080603@alum.mit.edu> <20140512160244.GY20206@verdi> In-Reply-To: <20140512160244.GY20206@verdi> 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=1399926382; bh=vLyVCsxu5dH0q+/pXJ5wn2E1K7UVUStkxLZx6KMsDd0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RVClK82DJzxm7uZ9HxD1LbRlEJg1q824IhxBceBkOIAb9t8h5wRQdiBsVw+2LiIwD TuisE63yrZvRAXFCczz/vj4L5DX+2QCngLLwRSOecatzpCpdRVleyu3VglHwKpT39h QwQipBG3J/DD9OaJcdFTgcD4eb2CV36rKKbj3iXJnrS9UD1okq7YeFwexV7wjJeu3J LbeGpPhNHjmKprETKOrZDfQVgxph2qUvQI17A6gJAz3FssHVZ3XxtsKNrCN075m58z +uUKMWp7F8IHBfZVL+rG9PpdA2OIzmoxnBJy8NafBWKqNfKAWOA8MhaEdv2xMY4/q2 MUYJWcTLXGbjg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/eIsYX1F_Q0L-XGWnuG-LFjvZ9nM Cc: clue@ietf.org Subject: Re: [clue] Attribute to indicate whether echo cancellation is done X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 20:26:29 -0000 On 5/12/14 12:02 PM, John Leslie wrote: > Paul Kyzivat wrote: >> On 5/12/14 7:12 AM, John Leslie wrote: >>> ... >>> Obviously, if receivers choose to use an audioCapture which does >>> no echo cancellation, they must find a way to keep echo under control. >>> Feeding it only to headphones/earbuds will always work; ensuring that >>> every participant is close-miked will often work; and to some degree >>> including it in your own echo-cancellation processing might be good >>> enough... >> >> IMO the question is whether we want to include this possibility. > > Which possibility, exactly? The possibility of captures where echo cancellation has not been done. >> Putting it in obligates every consumer to have logic to deal with it. > > Sufficient logic to realize echo cancellation in what is sent has or > has not been performed, yes. Things are simpler for the consumer if it can assume that echo cancellation has been done for every capture it receives. Once there is the possibility that it might not have been done then further algorithms must be available. >> Taking it out obligates every provider to ensure echo has been cancelled. > > Every sender, yes but... > > Some senders won't. :^( Then that becomes like any other non-conformance. The ones that cause trouble get identified, and those implementation must be fixed or get black listed. > I tried to mention some of the cases in the text I elided. I suppose > I could mention them again, but won't in this message. > >> Since most TP endpoints will have echo suppression, they won't be >> further burdened if we leave this out, but will have extra work to do if >> we add it. > > I can assure you that failure to cancel echo can be _very_ > disruptive to communication. > > The echo cancellation one site does cannot protect that site from > echo received. Echo _suppression_ can be applied to mute a source > when echo is detected, but the detection can be a bit buggy, and a > source which drops out in the middle of a word is also disruptive. My assumption is that we would require that advertised captures MUST NOT contain echo. That will require echo cancellation or suppression if there is any possibility of echo in the first place. (An endpoint that is just playing a powerpoint with background music doesn't need to do anything.) >> ISTM the cases that need most consideration are: >> >> - legacy mode clients. By definition we can't expect anything special >> about their behavior. An MCU that allows them into a clue conference >> will need to do *something* about this. > > Which is what I said, isn't it? Legacy mode clients are "special", because they don't send or consume advertisements. So there is no way for the receiver to be told whether the incoming audio might have echo or not. Thanks, Paul >> - clue-aware devices that don't have the the equipment that a typcial TP >> room or endpoint has. E.g. a cell phone with the smarts to do the clue >> protocol. These might be common. Can we assume they will be capable of >> handling the echo suppression? > > IMHO: no. > > BTW, we should keep "echo suppression" distinct from "echo cancellation". > Echo cancellation removes the reverberation of sound received from the > sound you send; echo suppression merely mute the entire source when echo > is "detected". > > But we can't reasonably expect smart-phones to do either. > > -- > John Leslie > From nobody Mon May 12 15:03: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 CBDCD1A0788 for ; Mon, 12 May 2014 15:02:59 -0700 (PDT) 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 prfG-vO8SmmV for ; Mon, 12 May 2014 15:02:56 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BB07C1A035C for ; Mon, 12 May 2014 15:02:55 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id jw12so9615568veb.34 for ; Mon, 12 May 2014 15:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GT3yaq3GcD9amVwN3rukMaT+fCD70RJlJD5ZIbyfLvs=; b=OG52pm1OT/kPak8Q8j/OmcQBGPXGz6H9fIVCFhSzNXtmFTpvJmL/ItZ/8dGw3h88iM bfiSxcsyeqB2kITAiO1oxfowtg8Kj7SC2LvPugfxCq1pV/r147QoteH6CPymPZcjxAKY IoYuRI3NeaLxqrC7LFSk1R5/CdZ/iTfi9Qw3SRjzBofW97dx/ySrb68nFFzL0G3x+Mug FsPEW2dtkc7gU4b8MsNXKT2ENDeIz3UBF3gimB+aS0AySnudryVKc1k6po04RRIbKGpl x9lKjBkCFYlsKiv4bRxHtgkjSJgrqKXaz8gBlo4pwcbTdABKiM6Ahp85o3DEmk6gVZNL Ding== MIME-Version: 1.0 X-Received: by 10.52.53.69 with SMTP id z5mr2440160vdo.42.1399932169440; Mon, 12 May 2014 15:02:49 -0700 (PDT) Received: by 10.221.40.135 with HTTP; Mon, 12 May 2014 15:02:49 -0700 (PDT) In-Reply-To: <53712E6D.8050304@alum.mit.edu> References: <20140512111218.GP20206@verdi> <5370E81D.6080603@alum.mit.edu> <20140512160244.GY20206@verdi> <53712E6D.8050304@alum.mit.edu> Date: Mon, 12 May 2014 18:02:49 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e01183caeab535004f93b1b0f Archived-At: http://mailarchive.ietf.org/arch/msg/clue/A68bDbffriRmrbcnLl7V9wk_3gA Cc: CLUE Subject: Re: [clue] Attribute to indicate whether echo cancellation is done X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 12 May 2014 22:03:00 -0000 --089e01183caeab535004f93b1b0f Content-Type: text/plain; charset=UTF-8 Echo Cancellation algorithms all require a mathematically linear relationship between the electrical signal sent to the loudspeakers, and the electrical signal of the echo picked by the microphone. This is the case with a local system doing the cancellation, as long as the speakers and the microphones are not overloaded so there is non-linear distortion products. However, in general, remote acoustic echo cancellation cannot be done. One reason is that the remote system simply does not have any knowledge of exactly what signal was rendered at the source loudspeakers. The second reason is that most codecs that are used to compress the audio stream introduce non-linearities which defeat the echo cancellation algorithms. A third reason is that the sampling clock at the remote system is not precisely matched to the source system. Even a small mismatch in clock rate results in a failure in the cancellation. Commercial grade clock sources are not that precise, and they are subject to thermal drift. I did a simple experiment some years ago - I started with a 60 seconds of audio. I then resampled to to add 1 sample (I believe this was at 48 Khz, so I was stretching the signal from 288000 to 288001 samples). I subtracted those waveforms, and listened to the difference signal - and could clearly hear the speech after about 15 seconds. Even a very small clock mismatch builds quickly (and since it is a form of non-linear distortion, it isn't canceled). Commercial systems solve this problem by phase-locking their local A/D and D/A clocks. So in my experience, it is not possible for a remote system to remove the echo introduced by a far end system. All it can do is not render that far-end's audio in the first place. Therefore I see no point to signaling a "hey I should have removed the echo, but I didn't" parameter. The only sensible strategy for a receiver is to not ask for that capture. Steve On Mon, May 12, 2014 at 4:26 PM, Paul Kyzivat wrote: > On 5/12/14 12:02 PM, John Leslie wrote: > >> Paul Kyzivat wrote: >> >>> On 5/12/14 7:12 AM, John Leslie wrote: >>> >>>> ... >>>> Obviously, if receivers choose to use an audioCapture which does >>>> no echo cancellation, they must find a way to keep echo under control. >>>> Feeding it only to headphones/earbuds will always work; ensuring that >>>> every participant is close-miked will often work; and to some degree >>>> including it in your own echo-cancellation processing might be good >>>> enough... >>>> >>> >>> IMO the question is whether we want to include this possibility. >>> >> >> Which possibility, exactly? >> > > The possibility of captures where echo cancellation has not been done. > > > Putting it in obligates every consumer to have logic to deal with it. >>> >> >> Sufficient logic to realize echo cancellation in what is sent has or >> has not been performed, yes. >> > > Things are simpler for the consumer if it can assume that echo > cancellation has been done for every capture it receives. > > Once there is the possibility that it might not have been done then > further algorithms must be available. > > > Taking it out obligates every provider to ensure echo has been cancelled. >>> >> >> Every sender, yes but... >> >> Some senders won't. :^( >> > > Then that becomes like any other non-conformance. > The ones that cause trouble get identified, and those implementation must > be fixed or get black listed. > > > I tried to mention some of the cases in the text I elided. I suppose >> I could mention them again, but won't in this message. >> >> Since most TP endpoints will have echo suppression, they won't be >>> further burdened if we leave this out, but will have extra work to do if >>> we add it. >>> >> >> I can assure you that failure to cancel echo can be _very_ >> disruptive to communication. >> >> The echo cancellation one site does cannot protect that site from >> echo received. Echo _suppression_ can be applied to mute a source >> when echo is detected, but the detection can be a bit buggy, and a >> source which drops out in the middle of a word is also disruptive. >> > > My assumption is that we would require that advertised captures MUST NOT > contain echo. That will require echo cancellation or suppression if there > is any possibility of echo in the first place. (An endpoint that is just > playing a powerpoint with background music doesn't need to do anything.) > > > ISTM the cases that need most consideration are: >>> >>> - legacy mode clients. By definition we can't expect anything special >>> about their behavior. An MCU that allows them into a clue conference >>> will need to do *something* about this. >>> >> >> Which is what I said, isn't it? >> > > Legacy mode clients are "special", because they don't send or consume > advertisements. So there is no way for the receiver to be told whether the > incoming audio might have echo or not. > > Thanks, > Paul > > > - clue-aware devices that don't have the the equipment that a typcial TP >>> room or endpoint has. E.g. a cell phone with the smarts to do the clue >>> protocol. These might be common. Can we assume they will be capable of >>> handling the echo suppression? >>> >> >> IMHO: no. >> >> BTW, we should keep "echo suppression" distinct from "echo >> cancellation". >> Echo cancellation removes the reverberation of sound received from the >> sound you send; echo suppression merely mute the entire source when echo >> is "detected". >> >> But we can't reasonably expect smart-phones to do either. >> >> -- >> John Leslie >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --089e01183caeab535004f93b1b0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Echo Cancellation algorithms all require a mathematically = linear relationship between the electrical signal sent to the loudspeakers,= and the electrical signal of the echo picked by the microphone.

This is the case with a local system doing the cancellation, as long a= s the speakers and the microphones are not overloaded so there is non-linea= r distortion products.

However, in general, remote= acoustic echo cancellation cannot be done. =C2=A0One reason is that the re= mote system simply does not have any knowledge of exactly what signal was r= endered at the source loudspeakers. =C2=A0The second reason is that most co= decs that are used to compress the audio stream introduce non-linearities w= hich defeat the echo cancellation algorithms. =C2=A0

A third reason is that the sampling clock at the remote= system is not precisely matched to the source system. =C2=A0Even a small m= ismatch in clock rate results in a failure in the cancellation. =C2=A0 Comm= ercial grade clock sources are not that precise, and they are subject to th= ermal drift. =C2=A0I did a simple experiment some years ago - I started wit= h a 60 seconds of audio. =C2=A0I then resampled to to add 1 sample (I belie= ve this was at 48 Khz, so I was stretching the signal from 288000 to 288001= samples). =C2=A0I subtracted those waveforms, and listened to the differen= ce signal - and could clearly hear the speech after about 15 seconds. =C2= =A0Even a very small clock mismatch builds quickly (and since it is a form = of non-linear distortion, it isn't canceled). Commercial systems solve = this problem by phase-locking their local A/D and D/A clocks.

So in my experience, it is not possible for a remote sy= stem to remove the echo introduced by a far end system. =C2=A0All it can do= is not render that far-end's audio in the first place. =C2=A0Therefore= I see no point to signaling a "hey I should have removed the echo, bu= t I didn't" parameter. =C2=A0The only sensible strategy for a rece= iver is to not ask for that capture.

Steve




On Mon, May 12, 2014 = at 4:26 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:<= br>
On 5/12/14 12:02 PM, John Le= slie wrote:
Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 5/12/14 7:12 AM, John Leslie wrote:
...
Obviously, if receivers choose to use an audioCapture which does
no echo cancellation, they must find a way to keep echo under control.
Feeding it only to headphones/earbuds will always work; ensuring that
every participant is close-miked will often work; and to some degree
including it in your own echo-cancellation processing might be good
enough...

IMO the question is whether we want to include this possibility.

=C2=A0 =C2=A0 Which possibility, exactly?

The possibility of captures where echo cancellation has not been done.


Putting it in obligates every consumer to have logic to deal with it.

=C2=A0 =C2=A0 Sufficient logic to realize echo cancellation in what is sent= has or
has not been performed, yes.

Things are simpler for the consumer if it can assume that echo cancellation= has been done for every capture it receives.

Once there is the possibility that it might not have been done then further= algorithms must be available.


Taking it out obligates every provider to ensure echo has been cancelled.

=C2=A0 =C2=A0 Every sender, yes but...

=C2=A0 =C2=A0 Some senders won't. :^(

Then that becomes like any other non-conformance.
The ones that cause trouble get identified, and those implementation must b= e fixed or get black listed.


=C2=A0 =C2=A0 I tried to mention some of the cases in the text I elided. I = suppose
I could mention them again, but won't in this message.

Since most TP endpoints will have echo suppression, they won't be
further burdened if we leave this out, but will have extra work to do if we add it.

=C2=A0 =C2=A0 I can assure you that failure to cancel echo can be _very_ disruptive to communication.

=C2=A0 =C2=A0 The echo cancellation one site does cannot protect that site = from
echo received. Echo _suppression_ can be applied to mute a source
when echo is detected, but the detection can be a bit buggy, and a
source which drops out in the middle of a word is also disruptive.

My assumption is that we would require that advertised captures MUST NOT co= ntain echo. That will require echo cancellation or suppression if there is = any possibility of echo in the first place. (An endpoint that is just playi= ng a powerpoint with background music doesn't need to do anything.)

ISTM the cases that need most consideration are:

- legacy mode clients. By definition we can't expect anything special about their behavior. An MCU that allows them into a clue conference
will need to do *something* about this.

=C2=A0 =C2=A0 Which is what I said, isn't it?

Legacy mode clients are "special", because they don't send or= consume advertisements. So there is no way for the receiver to be told whe= ther the incoming audio might have echo or not.

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

- clue-aware devices that don't have the the equipment that a typcial T= P
room or endpoint has. E.g. a cell phone with the smarts to do the clue
protocol. These might be common. Can we assume they will be capable of
handling the echo suppression?

=C2=A0 =C2=A0 IMHO: no.

=C2=A0 =C2=A0 BTW, we should keep "echo suppression" distinct fro= m "echo cancellation".
Echo cancellation removes the reverberation of sound received from the
sound you send; echo suppression merely mute the entire source when echo is "detected".

=C2=A0 =C2=A0 But we can't reasonably expect smart-phones to do either.=

--
John Leslie <john@jlc.= net>


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

--089e01183caeab535004f93b1b0f-- From nobody Mon May 12 16:57:11 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCF71A0792 for ; Mon, 12 May 2014 16:57:09 -0700 (PDT) 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 iKozPUQrdt1Z for ; Mon, 12 May 2014 16:57:06 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D581A037B for ; Mon, 12 May 2014 16:57:06 -0700 (PDT) Received: from ppp118-209-72-238.lns20.mel4.internode.on.net ([118.209.72.238]:50028 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wk04Z-000881-SI; Tue, 13 May 2014 09:55:56 +1000 Message-ID: <53715FC7.6050509@nteczone.com> Date: Tue, 13 May 2014 09:56:55 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52F13E179@CRPMBOXPRD08.polycom.com> <536C460F.4060001@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13E611@CRPMBOXPRD08.polycom.com> <537031DB.2080306@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F0110ABDE@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F0110ABDE@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/wuqFOGPhE4hG1J0cOdv3_sAyvgQ Subject: Re: [clue] voice activated switching example for the Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 23:57:09 -0000 Hello Mark, Please see below. Regards, Christian ..snip.. >>>>> +-----------------------+---------------------------------+ >>>>> | Capture Scene #1 | Description=conference | >>>>> +-----------------------|---------------------------------+ >>>>> | MCC1() | CaptureArea=Left | >>>>> | | MaxCaptures=1 | >>>>> | | SynchronisationID=1 | >>>>> | | Policy=SoundLevel:0 | >>>>> | | EncodingGroup=1 | >>>>> | | | >>>>> | MCC2() | CaptureArea=Center | >>>>> | | MaxCaptures=1 | >>>>> | | SynchronisationID=1 | >>>>> | | Policy=SoundLevel:0 | >>>>> | | EncodingGroup=1 | >>>>> | | | >>>>> | MCC3() | CaptureArea=Right | >>>>> | | MaxCaptures=1 | >>>>> | | SynchronisationID=1 | >>>>> | | Policy=SoundLevel:0 | >>>>> | | EncodingGroup=1 | >>>>> | | | >>>>> | MCC4() | CaptureArea=whole scene | >>>>> | | MaxCaptures=1 | >>>>> | | Policy=SoundLevel:0 | >>>>> | | EncodingGroup=1 | >>>>> | | | >>>>> | MCC5() (for audio) | CaptureArea=whole scene | >>>>> | | MaxCaptures=1 | >>>>> | | Policy=SoundLevel:0 | >>>>> | | EncodingGroup=2 | >>>>> | | | >>>>> | MCC6() (for audio) | CaptureArea=whole scene | >>>>> | | MaxCaptures=1 | >>>>> | | Policy=SoundLevel:1 | >>>>> | | EncodingGroup=2 | >>>>> | CSE1(MCC1,MCC2,MCC3 | | >>>>> | CSE2(MCC4) | | >>>>> | CSE3(MCC5,MCC6) | | >>>>> +---------------------------------------------------------+ >>>>> Table 26: Advertisement sent from the MCU to C >>>>> >>>>> The MCU advertises one scene, with four video MCCs. Three of them >>>>> in >>>> CSE1 give a left, center, right view of the conference, with "site >> switching". >>>> MCC4 provides a single video capture representing a view of the whole >>>> conference, which is simply switched between all the other original >>>> source captures. >>>> [CNG] According to the above table from a MC perspective it wouldn't >>>> know which sources are included. Nothing about the original sources >>>> has been advertised. >>> [Duckworth, Mark] Correct. That is allowed according to the definition of >> an MCC. >>> I want to keep this example as simple as possible to illustrate the >>> point, and it isn't necessary to include all those other captures without >> encoding groups in order to do that. >> [CNG] That's fine, however I think its worth to add a note that the source >> captures would be sent but not included for brevity reasons. >> Otherwise the MC doesn't know that they are simply switched between all >> the other original source captures." > [Duckworth, Mark] The MCU, as a provider, certainly could advertise information about all the other endpoint scenes, but it doesn't have to. My intent with this particular example is the MCU does not advertise all those other scenes. I think the example works fine without it. The endpoints, as consumers, do not *need* to know all that. Possibly if that information was included in the MCUs advertisement it could enable other behavior, but that's not what this example is about. > [CNG] I agree the MCU as the provider can provide what ever it wants. The point is with the current example the text says "MCC4 provides a single video capture representing a view of the whole conference, which is simply switched between all the other original source captures." The MP may know this but all the MC knows from the Advertisement (without the sources) is that MCC4 is a switched capture. It doesn't know that its "switched between all the other original sources". There's the intent of the MP and what is actually advertised. From nobody Mon May 12 17:25: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 3C4521A07B8 for ; Mon, 12 May 2014 17:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 JI-wfOnONkCE for ; Mon, 12 May 2014 17:25:16 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 583D51A07B3 for ; Mon, 12 May 2014 17:25:16 -0700 (PDT) Received: from [216.82.254.19:28604] by server-2.bemta-7.messagelabs.com id 4E/22-13907-56661735; Tue, 13 May 2014 00:25:09 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-10.tower-96.messagelabs.com!1399940708!4672355!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14012 invoked from network); 13 May 2014 00:25:09 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-10.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 13 May 2014 00:25:09 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 12 May 2014 17:25:08 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Mon, 12 May 2014 17:25:07 -0700 Thread-Topic: [clue] voice activated switching example for the Framework Thread-Index: Ac9uPd++M4uCWnGQSK2Sfx492XOmqwAA00ew Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F0110ACFA@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F13E179@CRPMBOXPRD08.polycom.com> <536C460F.4060001@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F13E611@CRPMBOXPRD08.polycom.com> <537031DB.2080306@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F0110ABDE@CRPMBOXPRD08.polycom.com> <53715FC7.6050509@nteczone.com> In-Reply-To: <53715FC7.6050509@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/DbfMKQkFjE48TCkvpXJ-TzaWuHw Subject: Re: [clue] voice activated switching example for the Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 00:25:18 -0000 Hi Christian, Thanks for clarifying, please see below. Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Monday, May 12, 2014 7:57 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] voice activated switching example for the Framework >=20 > Hello Mark, >=20 > Please see below. >=20 > Regards, Christian > ..snip.. > >>>>> +-----------------------+---------------------------------+ > >>>>> | Capture Scene #1 | Description=3Dconference = | > >>>>> +-----------------------|---------------------------------+ > >>>>> | MCC1() | CaptureArea=3DLeft = | > >>>>> | | MaxCaptures=3D1 = | > >>>>> | | SynchronisationID=3D1 = | > >>>>> | | Policy=3DSoundLevel:0 = | > >>>>> | | EncodingGroup=3D1 = | > >>>>> | | | > >>>>> | MCC2() | CaptureArea=3DCenter = | > >>>>> | | MaxCaptures=3D1 = | > >>>>> | | SynchronisationID=3D1 = | > >>>>> | | Policy=3DSoundLevel:0 = | > >>>>> | | EncodingGroup=3D1 = | > >>>>> | | | > >>>>> | MCC3() | CaptureArea=3DRight = | > >>>>> | | MaxCaptures=3D1 = | > >>>>> | | SynchronisationID=3D1 = | > >>>>> | | Policy=3DSoundLevel:0 = | > >>>>> | | EncodingGroup=3D1 = | > >>>>> | | | > >>>>> | MCC4() | CaptureArea=3Dwhole scene = | > >>>>> | | MaxCaptures=3D1 = | > >>>>> | | Policy=3DSoundLevel:0 = | > >>>>> | | EncodingGroup=3D1 = | > >>>>> | | | > >>>>> | MCC5() (for audio) | CaptureArea=3Dwhole scene = | > >>>>> | | MaxCaptures=3D1 = | > >>>>> | | Policy=3DSoundLevel:0 = | > >>>>> | | EncodingGroup=3D2 = | > >>>>> | | | > >>>>> | MCC6() (for audio) | CaptureArea=3Dwhole scene = | > >>>>> | | MaxCaptures=3D1 = | > >>>>> | | Policy=3DSoundLevel:1 = | > >>>>> | | EncodingGroup=3D2 = | > >>>>> | CSE1(MCC1,MCC2,MCC3 | | > >>>>> | CSE2(MCC4) | | > >>>>> | CSE3(MCC5,MCC6) | | > >>>>> +---------------------------------------------------------+ > >>>>> Table 26: Advertisement sent from the MCU to C > >>>>> > >>>>> The MCU advertises one scene, with four video MCCs. Three of them > >>>>> in > >>>> CSE1 give a left, center, right view of the conference, with "site > >> switching". > >>>> MCC4 provides a single video capture representing a view of the > >>>> whole conference, which is simply switched between all the other > >>>> original source captures. > >>>> [CNG] According to the above table from a MC perspective it > >>>> wouldn't know which sources are included. Nothing about the > >>>> original sources has been advertised. > >>> [Duckworth, Mark] Correct. That is allowed according to the > >>> definition of > >> an MCC. > >>> I want to keep this example as simple as possible to illustrate the > >>> point, and it isn't necessary to include all those other captures > >>> without > >> encoding groups in order to do that. > >> [CNG] That's fine, however I think its worth to add a note that the > >> source captures would be sent but not included for brevity reasons. > >> Otherwise the MC doesn't know that they are simply switched between > >> all the other original source captures." > > [Duckworth, Mark] The MCU, as a provider, certainly could advertise > information about all the other endpoint scenes, but it doesn't have to. = My > intent with this particular example is the MCU does not advertise all tho= se > other scenes. I think the example works fine without it. The endpoints,= as > consumers, do not *need* to know all that. Possibly if that information = was > included in the MCUs advertisement it could enable other behavior, but > that's not what this example is about. > > > [CNG] I agree the MCU as the provider can provide what ever it wants. > The point is with the current example the text says "MCC4 provides a sing= le > video capture representing a view of the whole conference, which is simpl= y > switched between all the other original source captures." The MP may know > this but all the MC knows from the Advertisement (without the sources) is > that MCC4 is a switched capture. It doesn't know that its "switched betwe= en > all the other original sources". There's the intent of the MP and what is > actually advertised. [Duckworth, Mark] You are right. I will clarify that in the text, about wh= at the MCU MP is doing, vs. how much information it gives in the advertisem= ent. Do you agree the example still works even though the endpoint consume= r does not know MCC4 is "simply switched between all the other original sou= rce captures"? From nobody Mon May 12 17:32: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 617C51A07B8 for ; Mon, 12 May 2014 17:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDktFxWiKJEi for ; Mon, 12 May 2014 17:32:01 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 78CB51A07B3 for ; Mon, 12 May 2014 17:32:01 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8C1A9C94BD; Mon, 12 May 2014 20:31:50 -0400 (EDT) Date: Mon, 12 May 2014 20:31:50 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20140513003150.GA6449@verdi> References: <20140512111218.GP20206@verdi> <5370E81D.6080603@alum.mit.edu> <20140512160244.GY20206@verdi> <53712E6D.8050304@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53712E6D.8050304@alum.mit.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Eli1WXagQB5F5eapODluE0UGBV0 Cc: clue@ietf.org Subject: Re: [clue] Attribute to indicate whether echo cancellation is done X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 May 2014 00:32:03 -0000 Paul Kyzivat wrote: > On 5/12/14 12:02 PM, John Leslie wrote: >>Paul Kyzivat wrote: >>>On 5/12/14 7:12 AM, John Leslie wrote: >>>>... >>>> Obviously, if receivers choose to use an audioCapture which does >>>> no echo cancellation, they must find a way to keep echo under control. >>>> Feeding it only to headphones/earbuds will always work; ensuring that >>>> every participant is close-miked will often work; and to some degree >>>> including it in your own echo-cancellation processing might be good >>>> enough... I wonder if everyone saw where I said "chooses to use"... If you are signaled that a source doesn't handle echo cancellation or suppression, you can "just say no", and the reason can be obvious to the sender. I didn't mean to imply any obligation to _use_ such a source. >>> IMO the question is whether we want to include this possibility. >> >>> Putting it in obligates every consumer to have logic to deal with it. > > Things are simpler for the consumer if it can assume that echo > cancellation has been done for every capture it receives. Such an unwarranted assumption can _really_ hurt! > Once there is the possibility that it might not have been done then > further algorithms must be available. Actually, the "possibility" is no greater with a signal such as I propose -- only the probability of learning about it without disrupting the conference changes. >>> Taking it out obligates every provider to ensure echo has been cancelled. >> >> Some senders won't. :^( > > Then that becomes like any other non-conformance. > The ones that cause trouble get identified, and those implementation > must be fixed or get black listed. Do you have the 800-number for the protocol police? (I'm sorry to come on so strongly, but I experience echo disruption _regularly_ on IESG telechats. It _really_ is worth automating the diagnosis of these problems!) >> The echo cancellation one site does cannot protect that site from >> echo received. Echo _suppression_ can be applied to mute a source >> when echo is detected, but the detection can be a bit buggy, and a >> source which drops out in the middle of a word is also disruptive. > > My assumption is that we would require that advertised captures MUST NOT > contain echo. That will require echo cancellation or suppression if > there is any possibility of echo in the first place. (An endpoint that > is just playing a powerpoint with background music doesn't need to do > anything.) I have no problem adding a state for "pre-recorded audio" or whatever you suggest. In addition to pre-recorded, there are "earbud-only" applications which remove the issue. We could add a state for that, too. >>> ISTM the cases that need most consideration are: >>> >>> - legacy mode clients. By definition we can't expect anything special >>> about their behavior. An MCU that allows them into a clue conference >>> will need to do *something* about this. > > Legacy mode clients are "special", because they don't send or consume > advertisements. So there is no way for the receiver to be told whether > the incoming audio might have echo or not. I'm not sure the term "legacy-mode" implies "not clue-speaking" to all our readers. I agree that how to deal with clue-less clients is outside the scope of what we're writing here. But I'd prefer that we not prohibit applications that don't do echo cancellation to our specs from speaking CLUE at all. (_Really_prefer_, that is...) -- John Leslie From nobody Mon May 12 17:44:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016D91A0382 for ; Mon, 12 May 2014 17:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDR7DKhqYnvZ for ; Mon, 12 May 2014 17:44:56 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 43AF71A037F for ; Mon, 12 May 2014 17:44:56 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 23BE3C94A9; Mon, 12 May 2014 20:44:47 -0400 (EDT) Date: Mon, 12 May 2014 20:44:47 -0400 From: John Leslie To: Stephen Botzko Message-ID: <20140513004447.GB6449@verdi> References: <20140512111218.GP20206@verdi> <5370E81D.6080603@alum.mit.edu> <20140512160244.GY20206@verdi> <53712E6D.8050304@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/wuW98LehOsXNg6Fqcp_8Bw7svEQ Cc: CLUE Subject: Re: [clue] Attribute to indicate whether echo cancellation is done X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 May 2014 00:44:58 -0000 Stephen Botzko wrote: > > Echo Cancellation algorithms all require a mathematically linear > relationship between the electrical signal sent to the loudspeakers, and > the electrical signal of the echo picked by the microphone. Yes. > This is the case with a local system doing the cancellation, as long as the > speakers and the microphones are not overloaded so there is non-linear > distortion products. Yes. > However, in general, remote acoustic echo cancellation cannot be done. One > reason is that the remote system simply does not have any knowledge of > exactly what signal was rendered at the source loudspeakers. The second > reason is that most codecs that are used to compress the audio stream > introduce non-linearities which defeat the echo cancellation algorithms. Yes. > A third reason is that the sampling clock at the remote system is not > precisely matched to the source system. Even a small mismatch in clock > rate results in a failure in the cancellation. Commercial grade clock > sources are not that precise, and they are subject to thermal drift... Yes. > So in my experience, it is not possible for a remote system to remove the > echo introduced by a far end system. This is where we part ways. I quite agree that the receiving system cannot adequately do echo-cancellation that the sender failed to do. But the receiving system still has echo-suppression tricks available to it. And most important, if the receiving system knows beforehand that echo-cancellation isn't being done, it can signal the problem and refuse to use that source. > All it can do is not render that far-end's audio in the first place. Which, of course, it can't do before it knows the problem exists... > Therefore I see no point to signaling a "hey I should have removed > the echo, but I didn't" parameter. (I figured we'd have a better chance of getting an honest statement if we didn't word it _quite_ that way... ;^) > The only sensible strategy for a receiver is to not ask for that capture. I mostly agree. But others _will_ come up with ways to deal with smart-phones that omit echo-cancellation. I see no reason to get in their way if they try to deal with it before it becomes disruptive to the conference. (Did I mention that the protocol police really don't have all that great a record of preventing non-compliance?) -- John Leslie From nobody Mon May 12 17:53: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 1CB7E1A07D4 for ; Mon, 12 May 2014 17:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_AXb2EUGAcR for ; Mon, 12 May 2014 17:53:41 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6965B1A07B3 for ; Mon, 12 May 2014 17:53:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 46D54C94A9; Mon, 12 May 2014 20:53:31 -0400 (EDT) Date: Mon, 12 May 2014 20:53:31 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20140513005331.GC6449@verdi> References: <20140512140240.GS20206@verdi> <537121A1.9000701@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <537121A1.9000701@alum.mit.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/2mtars4wo15pF3EHX-PXI2QAYZM Cc: clue@ietf.org Subject: Re: [clue] Rendering mono sources using multiple loudspeakers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 May 2014 00:53:43 -0000 Paul Kyzivat wrote: > On 5/12/14 10:02 AM, John Leslie wrote: >> >> A common case will be a remote individual (in an airport, perhaps) >> participating in discussion of a single issue. That individual will >> likely be shown in a more-or-less fixed position in the rendered >> video; and we should trust the receiving sound manager to render the >> mono audio to appear to come from that area of the screen (or be >> muted when the signal/noise ration is too low). > > The consumer is supposed to distinguish the above case from the below > case by the presence of a single video and a single audio capture? I really wasn't thinking in terms of "distinguishing two cases"... >> There will be other cases where, for whatever reason, there is no >> usable full-room mix or there is no screen real-estate to show that >> room; but individuals in that room speak, and the receiver can show >> video including the person speaking. The interesting issue arises >> when there are multiple microphone mediaCaptures and one must be >> chosen to be rendered to match the video position. >> >> Clearly there are proprietary tricks outside the scope of this >> standard. > > Proprietary tricks that work with the information made available from an > arbitrary clue peer? Or based on knowledge that both parties have some > agreement in addition to clue? Such an agreement had better not require > non-standard usage of the standard clue signaling and protocol. (Though > it could be based on *extensions* to that.) To me, "proprietary" mean "I'm not going to explain it!" So, I am not expressing an opinion on what information they use... >> But we note that measuring relative delay of each available >> microphone can show which microphone is closest to the speaker. >> Unfortunately, this is difficult for the receiver -- while it is >> easy for the sender to measure this. (Though I noted there that both sender and receiver _can_ use this trick...) >> I recommend we consider a per-participant attribute to link to >> the "nearest" microphone. > > Do you really mean *participant*? Or do you mean per-video-capture? I was thinking per-participant when I wrote that. > If you really mean participant, how do you expect that to be used here? I don't know: I don't believe we've settled what the participant data will look ilke. (I could _guess_ we might have position information available...) -- John Leslie From nobody Mon May 12 18:06: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 5EBDD1A07EC for ; Mon, 12 May 2014 18:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k_YPJ96NhGS for ; Mon, 12 May 2014 18:06:34 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 113641A0814 for ; Mon, 12 May 2014 18:06:33 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5F54EC94BD; Mon, 12 May 2014 21:06:23 -0400 (EDT) Date: Mon, 12 May 2014 21:06:23 -0400 From: John Leslie To: "Duckworth, Mark" Message-ID: <20140513010623.GD6449@verdi> References: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AC52@CRPMBOXPRD08.polycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AC52@CRPMBOXPRD08.polycom.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/_nubm1oQOE2u_XmH0F03ajFwiPs Cc: "clue@ietf.org" Subject: Re: [clue] Audio channel format - RE: Note that XY-stereo microphones are commonly available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 May 2014 01:06:36 -0000 Duckworth, Mark wrote: > [John Leslie wrote:] >> Duckworth, Mark wrote: >>> >>> I'm thinking this "audio channel format" parameter is really a >>> characteristic of a particular audio *encoding*, not an audio >>> *capture*. >> >>> So my idea is we should remove this audio capture attribute from the >>> framework and data model. The format of a particular audio encoding >>> would be described entirely in SDP (not CLUE messages). >> >> I'm not _opposed_ to that; but there are _so_many_details_... Alas, the bottom-line, regarding tomorrows design-team call, is that I won't have time to get into details before mid-week. :^( >>> And a media provider could advertise one single audio capture for the >>> whole room, which maybe it could encode as mono, or stereo, or >>> 3 channel, or surround sound, or whatever. Or maybe even offer >>> multiple encodings for simulcast, but these are still all just >>> different encodings of the same audio capture. (Note that there are other cases than whole-room capture that we should deal with, IMHO.) >> I'm not sure how to manage that, though. If a mix is prepared in >> 5.1 surround, I doubt that SDP is the right conduit for negotiating >> the number of channels -- offhand that sounds like a middlebox task. > > [Duckworth, Mark] Maybe we're talking about different things, because > I think SDP is exactly the right thing for this, and is commonly done > today, at least with stereo and mono. No doubt it would help for Mark and me to exchange email as I study this later this week. > Endpoints I am familiar with today are capable of encoding their > outgoing room audio as mono, stereo, and in some cases 3 channel. > If the receiving side (whether middlebox or another endpoint) is > capable only of mono, then the sender and receiver negotiate mono. > This is done with SDP offer/answer today. And I think it should be > done that way with CLUE also. That sounds superficially reasonable. Some details which come to mind are how to proceed when receiving audio from two or more sending rooms... >> And I'm _sure_ SDP isn't the right conduit for remapping the components >> of a whole-room feed to fit an incompatible conference room paradigm. Well, I was sure yesterday, anyway. ;^) > [Duckworth, Mark] It isn't about conserving bandwidth. It is about a > receiver selecting an audio encoding format it is capable of decoding. That does sound like an SDP issue. I had assumed multi-room teleconferencing systems would be able to decode at least one multi-channel surround format. -- John Leslie From nobody Mon May 12 18:40:21 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144601A07DD for ; Mon, 12 May 2014 18:40:16 -0700 (PDT) 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 0y80VtyYXRWj for ; Mon, 12 May 2014 18:40:13 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 56A831A0387 for ; Mon, 12 May 2014 18:40:13 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz11so9829132veb.17 for ; Mon, 12 May 2014 18:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o7tDZV0O66N/jnozSulZK2nLUCxYExt+yTtQg2CdHMk=; b=qpRVITGrxOLDcm03XTZrvQJ2h1h++4IJs0HUF14Vl2185tfiTWx+ryD6YZcLA1Z0RM J1ZOV9CBDMNkh/2BNdpzih2cOJ7xseXocTmcKlRvPbOMVxaBc7HN/9SIsQ+GvaaR0XAN VaoOnv/tNatP+ks8OXtFSyU6iyVo3MRazqZQdZQDhwPyTP7u1xUOfNwHbm/gYC7ua4rX 89EDP4qFmhOPB4oN0havuc4qE/EInz6dX/24weIQddXU4XMnj/kMd4YQ15fbkOMOsTDR hPeZv+recWQnzqXC5kRmrqeX9UINNOsQXyZVqNKoOaferWELP3DfLX5T/PZb/ua0uv+y KY9g== MIME-Version: 1.0 X-Received: by 10.221.44.73 with SMTP id uf9mr26456374vcb.9.1399945206895; Mon, 12 May 2014 18:40:06 -0700 (PDT) Received: by 10.221.40.135 with HTTP; Mon, 12 May 2014 18:40:06 -0700 (PDT) In-Reply-To: <20140513004447.GB6449@verdi> References: <20140512111218.GP20206@verdi> <5370E81D.6080603@alum.mit.edu> <20140512160244.GY20206@verdi> <53712E6D.8050304@alum.mit.edu> <20140513004447.GB6449@verdi> Date: Mon, 12 May 2014 21:40:06 -0400 Message-ID: From: Stephen Botzko To: John Leslie Content-Type: multipart/alternative; boundary=001a11337e42c31c4f04f93e2435 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/wL5jCjdjXvc9WWwT9U3GYELwoX0 Cc: CLUE Subject: Re: [clue] Attribute to indicate whether echo cancellation is done X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 May 2014 01:40:16 -0000 --001a11337e42c31c4f04f93e2435 Content-Type: text/plain; charset=UTF-8 in-line On Mon, May 12, 2014 at 8:44 PM, John Leslie wrote: > Stephen Botzko wrote: > > > > Echo Cancellation algorithms all require a mathematically linear > > relationship between the electrical signal sent to the loudspeakers, and > > the electrical signal of the echo picked by the microphone. > > Yes. > > > This is the case with a local system doing the cancellation, as long as > the > > speakers and the microphones are not overloaded so there is non-linear > > distortion products. > > Yes. > > > However, in general, remote acoustic echo cancellation cannot be done. > One > > reason is that the remote system simply does not have any knowledge of > > exactly what signal was rendered at the source loudspeakers. The second > > reason is that most codecs that are used to compress the audio stream > > introduce non-linearities which defeat the echo cancellation algorithms. > > Yes. > > > A third reason is that the sampling clock at the remote system is not > > precisely matched to the source system. Even a small mismatch in clock > > rate results in a failure in the cancellation. Commercial grade clock > > sources are not that precise, and they are subject to thermal drift... > > Yes. > > > So in my experience, it is not possible for a remote system to remove the > > echo introduced by a far end system. > > This is where we part ways. I quite agree that the receiving system > cannot adequately do echo-cancellation that the sender failed to do. > > But the receiving system still has echo-suppression tricks available > to it. > Ok. So here's a real example. We have a mesh with Alice, Bob, and Carol. Each has selected audio captures from the other two. Carol is sending audio that is not echo-canceled. So her audio capture includes echo from both Alice and Bob. Neither Alice nor Bob can echo-cancel for Carol - we agree on that. You say that there are echo-suppression tricks that Alice can use that will work for her, without knowledge of anything Bob might (or might not) be doing. Please tell us what they are - especially if Alice doesn't actually know what captures Carol has chosen to receive and render. > And most important, if the receiving system knows beforehand that > echo-cancellation isn't being done, it can signal the problem and > refuse to use that source. > > > All it can do is not render that far-end's audio in the first place. > > Which, of course, it can't do before it knows the problem exists... > Far more direct for Carol not to advertise her audio in the first place. Or not allow her system to be used without earphones. > > > Therefore I see no point to signaling a "hey I should have removed > > the echo, but I didn't" parameter. > > (I figured we'd have a better chance of getting an honest statement > if we didn't word it _quite_ that way... ;^) > Though it sounds pejorative, I don't what else you can call it. If I am using earphones, I don't need to echo-cancel, since there is no possibility of echo in the first place. If I have open loudspeakers,and I choose to echo cancel then I have taken care of any problem. Both of those captures can safely be used by all receivers. The problem case is if I have open loudspeakers and deliberately didn't echo-cancel. I think its fair to call that "hey I should have removed it but didn't". It's not like this problem is unknown. Some conferencing products are better at echo cancellation others. But everyone building these devices/apps know they need to do it, and they all have something. If for some reason they choose not to, then they should use push-to-talk, and mute their received audio signal when they are in talk-mode. > > > The only sensible strategy for a receiver is to not ask for that capture. > > I mostly agree. > > But others _will_ come up with ways to deal with smart-phones that > omit echo-cancellation. I see no reason to get in their way if they > try to deal with it before it becomes disruptive to the conference. Based on what people are already doing today, I don't think it is likely that any successful devices/apps will simply omit it. lt is far more likely that devices which are inserting echo are doing so because their algorithms simply aren't working well at the moment. Users pushing up the volume so the speakers distort is one common scenario that defeats echo cancellation. People can certainly innovate in this area, but they can't depend on signaling, since the devices inserting the echo generally can't detect that they are doing so.. > > (Did I mention that the protocol police really don't have all that > great a record of preventing non-compliance?) > Not sure how that applies to this discussion. > > -- > John Leslie > --001a11337e42c31c4f04f93e2435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
in-line


On Mon, May 12, 2014 at 8:44 PM, John Leslie &= lt;john@jlc.net> wrote:
Stephen Botzko <stephen.botzko@gmail.com> wrote= :
>
> Echo Cancellation algorithms all require a mathematically linear
> relationship between the electrical signal sent to the loudspeakers, a= nd
> the electrical signal of the echo picked by the microphone.

=C2=A0 =C2=A0Yes.

> This is the case with a local system doing the cancellation, as long a= s the
> speakers and the microphones are not overloaded so there is non-linear=
> distortion products.

=C2=A0 =C2=A0Yes.

> However, in general, remote acoustic echo cancellation cannot be done.= =C2=A0One
> reason is that the remote system simply does not have any knowledge of=
> exactly what signal was rendered at the source loudspeakers. =C2=A0The= second
> reason is that most codecs that are used to compress the audio stream<= br> > introduce non-linearities which defeat the echo cancellation algorithm= s.

=C2=A0 =C2=A0Yes.

> A third reason is that the sampling clock at the remote system is not<= br> > precisely matched to the source system. =C2=A0Even a small mismatch in= clock
> rate results in a failure in the cancellation. =C2=A0 Commercial grade= clock
> sources are not that precise, and they are subject to thermal dr= ift...

=C2=A0 =C2=A0Yes.

> So in my experience, it is not possible for a remote system to remove = the
> echo introduced by a far end system.

=C2=A0 =C2=A0This is where we part ways. I quite agree that the recei= ving system
cannot adequately do echo-cancellation that the sender failed to do.

=C2=A0 =C2=A0But the receiving system still has echo-suppression tricks ava= ilable
to it.
Ok. =C2=A0So here's a real example.
We have a mesh with Alice, Bob, and Carol. =C2=A0 Each has selected audi= o captures from the other two. =C2=A0Carol is sending audio that is not ech= o-canceled.
So her audio capture includes echo from both Alice and Bob. Neither Al= ice nor Bob can echo-cancel for Carol - we agree on that.

You say that there are echo-suppression tricks that Alice can use t= hat will work for her, without knowledge of anything Bob might (or might no= t) be doing. =C2=A0Please tell us what they are - especially if Alice doesn= 't actually know what captures Carol has chosen to receive and render.<= /div>



=C2=A0 =C2=A0And most important, if the receiving system knows beforehand t= hat
echo-cancellation isn't being done, it can signal the problem and
refuse to use that source.

> All it can do is not render that far-end's audio in the first plac= e.

=C2=A0 =C2=A0Which, of course, it can't do before it knows the pr= oblem exists...
Far more direct for Carol not to adver= tise her audio in the first place. =C2=A0Or not allow her system to be used= without earphones.=C2=A0

> Therefore I see no point to signaling a "hey I should have remove= d
> the echo, but I didn't" parameter.

=C2=A0 =C2=A0(I figured we'd have a better chance of getting an h= onest statement
if we didn't word it _quite_ that way... ;^)
=C2= =A0
Though it sounds pejorative, I don't what else you can ca= ll it.=C2=A0

If I am using earphones, I don't = need to echo-cancel, since there is no possibility of echo in the first pla= ce. =C2=A0If I have open loudspeakers,and =C2=A0I choose to echo cancel the= n I have taken care of any problem. =C2=A0Both of those captures can safely= be used by all receivers. =C2=A0

The problem case is if I have open loudspeakers and del= iberately didn't echo-cancel. =C2=A0I think its fair to call that "= ;hey I should have removed it but didn't". =C2=A0It's not like= this problem is unknown. =C2=A0Some conferencing products are better at ec= ho cancellation others. =C2=A0But everyone building these devices/apps know= they need to do it, and they all have something.

If for some reason they choose not to, then they should= use push-to-talk, and mute their received audio signal when they are in ta= lk-mode.
=C2=A0

> The only sensible strategy for a receiver is to not ask for that captu= re.

=C2=A0 =C2=A0I mostly agree.

=C2=A0 =C2=A0But others _will_ come up with ways to deal with smart-phones = that
omit echo-cancellation. I see no reason to get in their way if they
try to deal with it before it becomes disruptive to the conference.
Based on what people are already doing today, I don't think i= t is likely that any successful devices/apps will simply omit it. =C2=A0

lt is far more likely that devices which are inserting = echo are doing so because their algorithms simply aren't working well a= t the moment. =C2=A0Users pushing up the volume so the speakers distort is = one common scenario that defeats echo cancellation. =C2=A0People can certai= nly innovate in this area, but they can't depend on signaling, since th= e devices inserting the echo generally can't detect that they are doing= so..
=C2=A0

=C2=A0 =C2=A0(Did I mention that the protocol police really don't have = all that
great a record of preventing non-compliance?)
Not sure= how that applies to this discussion.=C2=A0

--
John Leslie <john@jlc.net>

--001a11337e42c31c4f04f93e2435-- From nobody Tue May 13 13:56:01 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B04A1A01EB for ; Tue, 13 May 2014 13:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 T-rz-UQJe90B for ; Tue, 13 May 2014 13:55:57 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) by ietfa.amsl.com (Postfix) with ESMTP id 84CBD1A01F5 for ; Tue, 13 May 2014 13:55:56 -0700 (PDT) Received: from [216.82.241.100:22465] by server-6.bemta-8.messagelabs.com id 81/E7-09054-5D682735; Tue, 13 May 2014 20:55:49 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-220.messagelabs.com!1400014547!3922672!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29057 invoked from network); 13 May 2014 20:55:48 -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; 13 May 2014 20:55:48 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 13 May 2014 13:54:30 -0700 From: "Duckworth, Mark" To: Stephen Botzko , Christian Groves Date: Tue, 13 May 2014 13:54:27 -0700 Thread-Topic: [clue] Taxonomy Thread-Index: Ac9lNkdqSLSaRfwlQ02sYreW2/0q5gJtqhFA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AE26@CRPMBOXPRD08.polycom.com> References: <5361BA1C.7030509@nteczone.com> <5362367D.1050509@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: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE26CRPMBOXPRD08pol_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/rDn7SzK9Myd8tyEK4k-if7fZBTQ Cc: "clue@ietf.org" Subject: Re: [clue] Taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 13 May 2014 20:55:59 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE26CRPMBOXPRD08pol_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3ZSBzaG91bGQgdXNlIHRoZSB0ZXJtIOKAnHBlcnNvbuKAnSBpbnN0ZWFkIG9mIOKA nHBhcnRpY2lwYW504oCdIHdoZW4gd2UgcmVhbGx5IG1lYW4gYSBwZXJzb24uICBFdmVuIHRob3Vn aCDigJxwZXJzb24gaW5mb3JtYXRpb27igJ0gc291bmRzIGEgYml0IG9kZCwgSSB0aGluayBpdOKA mXMgYmV0dGVyIHRoYW4gb3ZlcmxvYWRpbmcgdGhlIG1lYW5pbmcgb2YgcGFydGljaXBhbnQgd2hp Y2ggaXMgYWxyZWFkeSBkZWZpbmVkIHRvIG1lYW4gc29tZXRoaW5nIGVsc2UgaW4gdGhvc2UgcmVs YXRlZCBSRkNzLg0KDQpTbyBpZiBub2JvZHkgb2JqZWN0cywgSeKAmWxsIG1ha2UgdGhlIGNoYW5n ZSBpbiB0aGUgZnJhbWV3b3JrIGRvY3VtZW50Lg0KDQpNYXJrDQoNCkZyb206IGNsdWUgW21haWx0 bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEJvdHprbw0KU2Vu dDogVGh1cnNkYXksIE1heSAwMSwgMjAxNCA4OjA5IEFNDQpUbzogQ2hyaXN0aWFuIEdyb3Zlcw0K Q2M6IGNsdWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY2x1ZV0gVGF4b25vbXkNCg0KaW4tbGlu ZQ0KDQpPbiBUaHUsIE1heSAxLCAyMDE0IGF0IDc6NTYgQU0sIENocmlzdGlhbiBHcm92ZXMgPENo cmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29tPG1haWx0bzpDaHJpc3RpYW4uR3JvdmVzQG50ZWN6 b25lLmNvbT4+IHdyb3RlOg0KSGVsbG8gU3RlcGhlbiwNCg0KUGxlYXNlIHNlZSBiZWxvdy4NCg0K UmVnYXJkcywgQ2hyaXN0aWFuDQoNCg0KT24gMS8wNS8yMDE0IDk6MzkgUE0sIFN0ZXBoZW4gQm90 emtvIHdyb3RlOg0KUHJlY2lzaW9uLCBjbGFyaXR5LCBhbmQgY29uc2lzdGVuY3kgYXJlIG9mIGNv dXJzZSBpcyBnb29kIGlkZWFzLg0KDQpUaGUgdXNlIGNhc2VzIHdlcmUganVzdCBwdWJsaXNoZWQs IGFuZCB0aGF0IFJGQyB1c2VzICJwYXJ0aWNpcGFudCIgY29uc2lzdGVudGx5IHRvIG1lYW4gInBl cnNvbiIuYW5kICJzaXRlIiB0byBtZWFuIHJvb20vbG9jYXRpb24uICBJIGRvbid0IHRoaW5rIGFu eW9uZSB3aWxsIHRoaW5rIHRoYXQgInBhcnRpY2lwYW50cyIgaW4gdGhhdCBSRkMgYXJlIHVzaW5n IHRoZSBSRkM0MzUzIGRlZmluaXRpb24uIElmIHNvbWVvbmUgZGlkLCB0aGF0IHdvdWxkIGhhdmUg c3VyZmFjZWQgaW4gdGhlIElFVEYgbGFzdCBjYWxsLCBBRCByZXZpZXdzLCBldGMuICBJdCBkaWRu J3QuDQpbQ05HXSBJdCBkaWRuJ3QgY29tZSB1cCBkdXJpbmcgcmV2aWV3IGJ1dCBpdCBkaWQgY29t ZSB1cCBpbiBMb25kb24gdGhhdCB3ZSBzaG91bGQgY2hlY2sgdGhlIENMVUUgd29yayBhZ2FpbnN0 IHRoZSB0YXhvbm9teS4NCltTQl0gQXMgeW91IGtub3cgSSB3YXNuJ3QgdGhlcmUsIGJ1dCBJIGFn cmVlIHRoYXQgaXMgYSBnb29kIGlkZWEuDQoNCg0KVGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudCBp cyBqdXN0IGVudGVyaW5nIHRoZSBlZGl0b3JzIHF1ZXVlLCBhbmQgdXNlcyAicGFydGljaXBhbnQi IGV4YWN0bHkgb25jZSAoaW4gdGhlIGRlZmluaXRpb24gb2YgZW5kcG9pbnQpLiAgVGhhdCB1c2Ug Y3Jvc3MtcmVmZXJlbmNlcyBSRkM0MzUzLiAgSXQgY29uc2lzdGVudGx5IHVzZXMgInVzZXJzIiB0 byBkZXNjcmliZSBwZW9wbGUuDQoNCkkgcHJvcG9zZSB0aGF0IHdlIG5vdCByZS1wdWJsaXNoIHRo ZSBleGlzdGluZyBSRkMsIGFuZCBhbHNvIHRoYXQgd2UgbGVhdmUgdGhlIHJlcXVpcmVtZW50cyBk b2N1bWVudCB1c2FnZSBhcyBpdCBpcy4gIEkgZ3Vlc3Mgd2UgY291bGQgdXNlIEFVVEg0OCB0byBy ZXZpc2UgInVzZXIiIHVzYWdlLCBidXQgb25seSBpZiB3ZSBjbG9zZSBvbiB0aGUgdGVybWlub2xv Z3kgdmVyeSBxdWlja2x5Lg0KW0NOR10gSSB0aGlua2luZyB0byByZS1vcGVuIHRoZSBleGlzdGlu ZyBSRkMgb3IgdGhvc2UgaW4gdGhlIFJGQyBxdWV1ZS4gSXRzIG5vdCB3b3J0aCB0aGUgZWZmb3J0 IHRvIHVwZGF0ZSB0aG9zZSBhcyB0aGV5J3JlIGxhcmdlbHkgaW5mb3JtYXRpdmUgYW5kIHRoaXMg aXNuJ3QgYSBiaWcgaXNzdWUuDQoNCltTQl1UaGF0IHdpbGwgY2VydGFpbmx5IG1ha2UgcmVzb2x2 aW5nIHRoaXMgc2ltcGxlci4NCg0KQWxzbywgSSBhZ3JlZSB0aGF0IHdlIG91Z2h0IHRvIG1ha2Ug c3VyZSB0aGF0IHRoZSByZW1haW5pbmcgZG9jdW1lbnRzIGFyZSBhbGlnbmVkIG9uIHRoZXNlIGJh c2ljIHRlcm1zLCBhbmQgdGhhdCB0aG9zZSB0ZXJtcyBhcmUgYWxzbyB1c2VkIGNvbnNpc3RlbnRs eSB3aXRoIGV4aXN0aW5nIFJGQ3MgYXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KIlBlcnNvbiBpbmZv cm1hdGlvbiIganVzdCBkb2Vzbid0IHNvdW5kIHJpZ2h0IHRvIG1lIHRob3VnaC4gICJVc2VyIElu Zm9ybWF0aW9uIiBhbmQgIlBhcnRpY2lwYW50IEluZm9ybWF0aW9uIiBzaW1wbHkgc291bmQgYmV0 dGVyLiBQZXJoYXBzIHRoYXQgaXMgYmVjYXVzZSBJIHNwZWFrIEFtZXJpY2FuLCBhbmQgbm90IEVu Z2xpc2g/DQpbQ05HXSBJJ20gbm90IHBhcnRpY3VsYXJseSBmb25kIG9mICJQZXJzb24gSW5mb3Jt YXRpb24iIGVpdGhlciBidXQgSSB3YXMgdHJ5aW5nIHRvIHVzZSAicGFydGljaXBhbnQiIG9yICJ1 c2VyIiB3aGljaCBhbHJlYWR5IGhhdmUgYSBkZWZpbml0aW9uIGluIHRoZSBYQ09OIG1vZGVsLiBJ J20ganVzdCB0aGlua2luZyBmb3J3YXJkIGFuZCBpZiB3ZSBkbyBldmVudHVhbGx5IHVwZGF0ZSBY Q09OIHRvIGluY2x1ZGUgc29tZSBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIGNsdWUgaXQgd291bGQg c2VlbSBzdHJhbmdlIHRvIGhhdmUgYSBoaWVyYXJjaHk6DQoNClVzZXJzLT5Vc2VyLT5FbmRwb2lu dC0+ImNhcHR1cmUiLT5wYXJ0aWNpcGFudA0KDQp3aGVuIFJGQzY1MDEgdGFsa3MgYWJvdXQgVXNl cj1QYXJ0aWNpcGFudC4NCltTQl0gSSdtIGdsYWQgdG8ga25vdyBpdHMgbm90IGp1c3QgbWUgd2hv IGZpbmRzICJQZXJzb24gaW5mb3JtYXRpb24iIGEgYml0IG9mZi4uICBNYXliZSBzb21lb25lIGNh biB0aGluayBvZiBhIHRlcm0gdGhhdCByZWFkcyBiZXR0ZXIuICBUbyBzb21lIGRlZ3JlZSwgd2Ug YXJlIGNvbnN0cmFpbmVkIGJlY2F1c2UgcHJldmlvdXMgUkZDcyBuZWVkbGVzc2x5IHRvb2sgYW4g YW50aHJvcG9tb3JwaGljIGFwcHJvYWNoIHdoZW4gZGVzY3JpYmluZyBlcXVpcG1lbnQuICBJTU8g dGhhdCBzaG91bGQgaGF2ZSBiZWVuIGVhc2lseSBiZWVuIGF2b2lkZWQgYmFjayB0aGVuLCBidXQg dGhhdCBzaGlwIGhhcyBzYWlsZWQuDQoNCg0KU3RlcGhlbiBCb3R6a28NCg0KDQoNCg0KDQpPbiBX ZWQsIEFwciAzMCwgMjAxNCBhdCAxMTowNiBQTSwgQ2hyaXN0aWFuIEdyb3ZlcyA8Q2hyaXN0aWFu Lkdyb3Zlc0BudGVjem9uZS5jb208bWFpbHRvOkNocmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29t PiA8bWFpbHRvOkNocmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29tPG1haWx0bzpDaHJpc3RpYW4u R3JvdmVzQG50ZWN6b25lLmNvbT4+PiB3cm90ZToNCg0KICAgIEhlbGxvIGFsbCwNCg0KICAgIEF0 IHRoZSBMb25kb24gbWVldGluZyBpdCB3YXMgbWVudGlvbmVkIHRoZXJlIGlzIGEgcG90ZW50aWFs DQogICAgY29uZmxpY3QgaW4gdGhlIHdheSB0aGF0IENMVUUgdXNlcyBzb21lIG9mIHRoZSB0ZXJt aW5vbG9neSBmcm9tDQogICAgdGhlIFJUUCB0YXhvbm9teSBkcmFmdCAoZHJhZnQtaWV0Zi1hdnRl eHQtcnRwLWdyb3VwaW5nLXRheG9ub215KS4NCg0KICAgIEkgdGhpbmsgdGhpcyBtYWlubHkgcmVs YXRlcyB0byB0aGUgdXNlIG9mIHRoZSB0ZXJtICJQYXJ0aWNpcGFudCIuDQoNCiAgICBJbiBjbC4y LjIuMyBvZiB0aGUgdGF4b25vbXkgZHJhZnQgdGhlcmUgaXMgYSBkZWZpbml0aW9uIGZvciB0aGUN CiAgICB0ZXJtICJwYXJ0aWNpcGFudCI6DQogICAgLyJBIHBhcnRpY2lwYW50IGlzIGFuIGVudGl0 eSByZWFjaGFibGUgYnkgYSBzaW5nbGUgc2lnbmFsaW5nDQogICAgYWRkcmVzcywvLw0KICAgIC8v ICAgYW5kIGlzIHRodXMgcmVsYXRlZCBtb3JlIHRvIHRoZSBzaWduYWxpbmcgY29udGV4dCB0aGFu IHRvIHRoZQ0KICAgIG1lZGlhLy8NCiAgICAvLyAgIGNvbnRleHQuIg0KDQogICAgL0luIHRoZSBY Q09OIGRhdGEgbW9kZWwgY2wuNC42LjUvW1JGQzY1MDFdIGl0IHVzZXMgdGhlIHRlcm0gInVzZXIi DQogICAgdG8gZGVzY3JpYmUgdGhlIGNvbmNlcHQgb3V0bGluZWQgaW4gdGhlIGRyYWZ0IGRlZmlu aXRpb24uIFJGQzQ1NzUNCiAgICBhbHNvIHVzZXMgdGhlIHRlcm0gInVzZXIiIGZvciB0aGlzLg0K DQogICAgSW4gQ0xVRSB3ZSB1c2UgcGFydGljaXBhbnQgYXMgcGVyIHRoZSBkZWZpbml0aW9uIGFi b3ZlIChpLmUuIGluDQogICAgdGhlIGRlZmluaXRpb24gb2YgRW5kcG9pbnQgYW5kIE1DVSkgYnV0 IHdlIGFsc28gdXNlICJwYXJ0aWNpcGFudCINCiAgICB0byBtZWFuIHNvbWVvbmUgY2FwdHVyZWQg YnkgdGhlIGVuZHBvaW50LCBpLmUuIHRoZSBwZW9wbGUgaW4gdGhlIHJvb20uDQoNCiAgICBJbiBv cmRlciB0byBtaW5pbWlzZSBhbnkgY29uZnVzaW9uIGJldHdlZW4gdGhlIHR3byB1c2VzIEkgcHJv cG9zZQ0KICAgIHRoYXQgd2UgY2hhbmdlIHRoZSBsYXRlciB1c2UgdG8gInBlcnNvbiIgaW4gb3Vy IGRvY3VtZW50cy4NCg0KICAgIEZvciBleGFtcGxlOiBpbiB0aGUgZnJhbWV3b3JrOg0KICAgIC0g IlBhcnRpY2lwYW50IEluZm9ybWF0aW9uIiBiZWNvbWVzICJQZXJzb24gSW5mb3JtYXRpb24iLA0K ICAgIC0gInBhcnRpY2lwYW50IHR5cGUiIGJlY29tZXMgInBlcnNvbiB0eXBlIi4NCiAgICAtIFdo ZXJlICJwYXJ0aWNpcGFudCIgaXMgdXNlZCBpbiB0aGUgdGV4dCBpdCBiZWNvbWVzICJwZXJzb24i IG9yDQogICAgInBlb3BsZSIuDQogICAgICBpLmUuICAgVGFibGUgLSBDYXB0dXJlcyB0aGUgY29u ZmVyZW5jZSB0YWJsZSB3aXRoIHNlYXRlZCBwZW9wbGUuDQogICAgICAgIEluZGl2aWR1YWwgLSBD YXB0dXJlcyBhbiBpbmRpdmlkdWFsIHBlcnNvbi4NCg0KDQogICAgQ2hyaXN0aWFuDQoNCiAgICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIGNsdWUg bWFpbGluZyBsaXN0DQogICAgY2x1ZUBpZXRmLm9yZzxtYWlsdG86Y2x1ZUBpZXRmLm9yZz4gPG1h aWx0bzpjbHVlQGlldGYub3JnPG1haWx0bzpjbHVlQGlldGYub3JnPj4NCiAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg0KDQoNCg== --_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE26CRPMBOXPRD08pol_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0 ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0KLyogRm9udCBE ZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9z ZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFo b21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9k eSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlv bjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBhZ3JlZSB3ZSBz aG91bGQgdXNlIHRoZSB0ZXJtIOKAnHBlcnNvbuKAnSBpbnN0ZWFkIG9mIOKAnHBhcnRpY2lwYW50 4oCdIHdoZW4gd2UgcmVhbGx5IG1lYW4gYSBwZXJzb24uwqAgRXZlbiB0aG91Z2gg4oCccGVyc29u IGluZm9ybWF0aW9u4oCdIHNvdW5kcyBhIGJpdCBvZGQsIEkgdGhpbmsgaXTigJlzIGJldHRlciB0 aGFuIG92ZXJsb2FkaW5nIHRoZSBtZWFuaW5nIG9mIHBhcnRpY2lwYW50IHdoaWNoIGlzIGFscmVh ZHkgZGVmaW5lZCB0byBtZWFuIHNvbWV0aGluZyBlbHNlIGluIHRob3NlIHJlbGF0ZWQgUkZDcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPlNvIGlmIG5vYm9keSBvYmplY3RzLCBJ4oCZbGwgbWFrZSB0aGUg Y2hhbmdlIGluIHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxicj5NYXJrPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRp diBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPiBjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSA8 Yj5PbiBCZWhhbGYgT2YgPC9iPlN0ZXBoZW4gQm90emtvPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgTWF5IDAxLCAyMDE0IDg6MDkgQU08YnI+PGI+VG86PC9iPiBDaHJpc3RpYW4gR3JvdmVzPGJy PjxiPkNjOjwvYj4gY2x1ZUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtjbHVlXSBU YXhvbm9teTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aW4tbGluZTxv OnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24g VGh1LCBNYXkgMSwgMjAxNCBhdCA3OjU2IEFNLCBDaHJpc3RpYW4gR3JvdmVzICZsdDs8YSBocmVm PSJtYWlsdG86Q2hyaXN0aWFuLkdyb3Zlc0BudGVjem9uZS5jb20iIHRhcmdldD0iX2JsYW5rIj5D aHJpc3RpYW4uR3JvdmVzQG50ZWN6b25lLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD5IZWxsbyBTdGVwaGVuLDxicj48YnI+UGxlYXNlIHNlZSBiZWxv dy48YnI+PGJyPlJlZ2FyZHMsIENocmlzdGlhbjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxicj48YnI+T24gMS8wNS8yMDE0IDk6MzkgUE0sIFN0ZXBoZW4gQm90emtvIHdy b3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5QcmVjaXNpb24sIGNsYXJpdHks IGFuZCBjb25zaXN0ZW5jeSBhcmUgb2YgY291cnNlIGlzIGdvb2QgaWRlYXMuPGJyPjxicj5UaGUg dXNlIGNhc2VzIHdlcmUganVzdCBwdWJsaXNoZWQsIGFuZCB0aGF0IFJGQyB1c2VzICZxdW90O3Bh cnRpY2lwYW50JnF1b3Q7IGNvbnNpc3RlbnRseSB0byBtZWFuICZxdW90O3BlcnNvbiZxdW90Oy5h bmQgJnF1b3Q7c2l0ZSZxdW90OyB0byBtZWFuIHJvb20vbG9jYXRpb24uICZuYnNwO0kgZG9uJ3Qg dGhpbmsgYW55b25lIHdpbGwgdGhpbmsgdGhhdCAmcXVvdDtwYXJ0aWNpcGFudHMmcXVvdDsgaW4g dGhhdCBSRkMgYXJlIHVzaW5nIHRoZSBSRkM0MzUzIGRlZmluaXRpb24uIElmIHNvbWVvbmUgZGlk LCB0aGF0IHdvdWxkIGhhdmUgc3VyZmFjZWQgaW4gdGhlIElFVEYgbGFzdCBjYWxsLCBBRCByZXZp ZXdzLCBldGMuICZuYnNwO0l0IGRpZG4ndC48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+W0NOR10gSXQgZGlkbid0IGNvbWUgdXAgZHVyaW5nIHJldmlldyBidXQgaXQgZGlk IGNvbWUgdXAgaW4gTG9uZG9uIHRoYXQgd2Ugc2hvdWxkIGNoZWNrIHRoZSBDTFVFIHdvcmsgYWdh aW5zdCB0aGUgdGF4b25vbXkuPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ W1NCXSBBcyB5b3Uga25vdyBJIHdhc24ndCB0aGVyZSwgYnV0IEkgYWdyZWUgdGhhdCBpcyBhIGdv b2QgaWRlYS4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4nPjxkaXY+PGJsb2Nr cXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxicj5UaGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50IGlzIGp1c3QgZW50ZXJpbmcgdGhl IGVkaXRvcnMgcXVldWUsIGFuZCB1c2VzICZxdW90O3BhcnRpY2lwYW50JnF1b3Q7IGV4YWN0bHkg b25jZSAoaW4gdGhlIGRlZmluaXRpb24gb2YgZW5kcG9pbnQpLiAmbmJzcDtUaGF0IHVzZSBjcm9z cy1yZWZlcmVuY2VzIFJGQzQzNTMuICZuYnNwO0l0IGNvbnNpc3RlbnRseSB1c2VzICZxdW90O3Vz ZXJzJnF1b3Q7IHRvIGRlc2NyaWJlIHBlb3BsZS48YnI+PGJyPkkgcHJvcG9zZSB0aGF0IHdlIG5v dCByZS1wdWJsaXNoIHRoZSBleGlzdGluZyBSRkMsIGFuZCBhbHNvIHRoYXQgd2UgbGVhdmUgdGhl IHJlcXVpcmVtZW50cyBkb2N1bWVudCB1c2FnZSBhcyBpdCBpcy4gJm5ic3A7SSBndWVzcyB3ZSBj b3VsZCB1c2UgQVVUSDQ4IHRvIHJldmlzZSAmcXVvdDt1c2VyJnF1b3Q7IHVzYWdlLCBidXQgb25s eSBpZiB3ZSBjbG9zZSBvbiB0aGUgdGVybWlub2xvZ3kgdmVyeSBxdWlja2x5LjxvOnA+PC9vOnA+ PC9wPjwvYmxvY2txdW90ZT48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+W0NOR10gSSB0aGlua2lu ZyB0byByZS1vcGVuIHRoZSBleGlzdGluZyBSRkMgb3IgdGhvc2UgaW4gdGhlIFJGQyBxdWV1ZS4g SXRzIG5vdCB3b3J0aCB0aGUgZWZmb3J0IHRvIHVwZGF0ZSB0aG9zZSBhcyB0aGV5J3JlIGxhcmdl bHkgaW5mb3JtYXRpdmUgYW5kIHRoaXMgaXNuJ3QgYSBiaWcgaXNzdWUuPG86cD48L286cD48L3A+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9ibG9j a3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPltTQl1UaGF0IHdpbGwgY2VydGFpbmx5IG1h a2UgcmVzb2x2aW5nIHRoaXMgc2ltcGxlci4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48Ymxv Y2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4nPjxkaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPkFsc28sIEkgYWdy ZWUgdGhhdCB3ZSBvdWdodCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgcmVtYWluaW5nIGRvY3VtZW50 cyBhcmUgYWxpZ25lZCBvbiB0aGVzZSBiYXNpYyB0ZXJtcywgYW5kIHRoYXQgdGhvc2UgdGVybXMg YXJlIGFsc28gdXNlZCBjb25zaXN0ZW50bHkgd2l0aCBleGlzdGluZyBSRkNzIGFzIG11Y2ggYXMg cG9zc2libGUuPGJyPjxicj4mcXVvdDtQZXJzb24gaW5mb3JtYXRpb24mcXVvdDsganVzdCBkb2Vz bid0IHNvdW5kIHJpZ2h0IHRvIG1lIHRob3VnaC4gJm5ic3A7JnF1b3Q7VXNlciBJbmZvcm1hdGlv biZxdW90OyBhbmQgJnF1b3Q7UGFydGljaXBhbnQgSW5mb3JtYXRpb24mcXVvdDsgc2ltcGx5IHNv dW5kIGJldHRlci4gUGVyaGFwcyB0aGF0IGlzIGJlY2F1c2UgSSBzcGVhayBBbWVyaWNhbiwgYW5k IG5vdCBFbmdsaXNoPzxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+W0NOR10gSSdtIG5vdCBwYXJ0aWN1bGFybHkgZm9uZCBvZiAmcXVvdDtQZXJzb24g SW5mb3JtYXRpb24mcXVvdDsgZWl0aGVyIGJ1dCBJIHdhcyB0cnlpbmcgdG8gdXNlICZxdW90O3Bh cnRpY2lwYW50JnF1b3Q7IG9yICZxdW90O3VzZXImcXVvdDsgd2hpY2ggYWxyZWFkeSBoYXZlIGEg ZGVmaW5pdGlvbiBpbiB0aGUgWENPTiBtb2RlbC4gSSdtIGp1c3QgdGhpbmtpbmcgZm9yd2FyZCBh bmQgaWYgd2UgZG8gZXZlbnR1YWxseSB1cGRhdGUgWENPTiB0byBpbmNsdWRlIHNvbWUgaW5mb3Jt YXRpb24gcmVsYXRlZCB0byBjbHVlIGl0IHdvdWxkIHNlZW0gc3RyYW5nZSB0byBoYXZlIGEgaGll cmFyY2h5OiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4nPjxwIGNs YXNzPU1zb05vcm1hbD48YnI+VXNlcnMtJmd0O1VzZXItJmd0O0VuZHBvaW50LSZndDsmcXVvdDtj YXB0dXJlJnF1b3Q7LSZndDtwYXJ0aWNpcGFudDxicj48YnI+d2hlbiBSRkM2NTAxIHRhbGtzIGFi b3V0IFVzZXI9UGFydGljaXBhbnQuJm5ic3A7PG86cD48L286cD48L3A+PC9ibG9ja3F1b3RlPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPltTQl0gSSdtIGdsYWQgdG8ga25vdyBpdHMgbm90IGp1c3Qg bWUgd2hvIGZpbmRzICZxdW90O1BlcnNvbiBpbmZvcm1hdGlvbiZxdW90OyBhIGJpdCBvZmYuLiAm bmJzcDtNYXliZSBzb21lb25lIGNhbiB0aGluayBvZiBhIHRlcm0gdGhhdCByZWFkcyBiZXR0ZXIu ICZuYnNwO1RvIHNvbWUgZGVncmVlLCB3ZSBhcmUgY29uc3RyYWluZWQgYmVjYXVzZSBwcmV2aW91 cyBSRkNzIG5lZWRsZXNzbHkgdG9vayBhbiBhbnRocm9wb21vcnBoaWMgYXBwcm9hY2ggd2hlbiBk ZXNjcmliaW5nIGVxdWlwbWVudC4gJm5ic3A7SU1PIHRoYXQgc2hvdWxkIGhhdmUgYmVlbiBlYXNp bHkgYmVlbiBhdm9pZGVkIGJhY2sgdGhlbiwgYnV0IHRoYXQgc2hpcCBoYXMgc2FpbGVkLjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbic+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj5TdGVwaGVuIEJvdHpr bzxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxicj48YnI+ PGJyPjxicj5PbiBXZWQsIEFwciAzMCwgMjAxNCBhdCAxMTowNiBQTSwgQ2hyaXN0aWFuIEdyb3Zl cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkNocmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+Q2hyaXN0aWFuLkdyb3Zlc0BudGVjem9uZS5jb208L2E+ICZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOkNocmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29tIiB0YXJnZXQ9Il9i bGFuayI+Q2hyaXN0aWFuLkdyb3Zlc0BudGVjem9uZS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJy Pjxicj4mbmJzcDsgJm5ic3A7IEhlbGxvIGFsbCw8YnI+PGJyPiZuYnNwOyAmbmJzcDsgQXQgdGhl IExvbmRvbiBtZWV0aW5nIGl0IHdhcyBtZW50aW9uZWQgdGhlcmUgaXMgYSBwb3RlbnRpYWw8YnI+ Jm5ic3A7ICZuYnNwOyBjb25mbGljdCBpbiB0aGUgd2F5IHRoYXQgQ0xVRSB1c2VzIHNvbWUgb2Yg dGhlIHRlcm1pbm9sb2d5IGZyb208YnI+Jm5ic3A7ICZuYnNwOyB0aGUgUlRQIHRheG9ub215IGRy YWZ0IChkcmFmdC1pZXRmLWF2dGV4dC1ydHAtZ3JvdXBpbmctdGF4b25vbXkpLjxicj48YnI+Jm5i c3A7ICZuYnNwOyBJIHRoaW5rIHRoaXMgbWFpbmx5IHJlbGF0ZXMgdG8gdGhlIHVzZSBvZiB0aGUg dGVybSAmcXVvdDtQYXJ0aWNpcGFudCZxdW90Oy48YnI+PGJyPiZuYnNwOyAmbmJzcDsgSW4gY2wu Mi4yLjMgb2YgdGhlIHRheG9ub215IGRyYWZ0IHRoZXJlIGlzIGEgZGVmaW5pdGlvbiBmb3IgdGhl PGJyPiZuYnNwOyAmbmJzcDsgdGVybSAmcXVvdDtwYXJ0aWNpcGFudCZxdW90Ozo8YnI+Jm5ic3A7 ICZuYnNwOyAvJnF1b3Q7QSBwYXJ0aWNpcGFudCBpcyBhbiBlbnRpdHkgcmVhY2hhYmxlIGJ5IGEg c2luZ2xlIHNpZ25hbGluZzxicj4mbmJzcDsgJm5ic3A7IGFkZHJlc3MsLy88YnI+Jm5ic3A7ICZu YnNwOyAvLyAmbmJzcDsgYW5kIGlzIHRodXMgcmVsYXRlZCBtb3JlIHRvIHRoZSBzaWduYWxpbmcg Y29udGV4dCB0aGFuIHRvIHRoZTxicj4mbmJzcDsgJm5ic3A7IG1lZGlhLy88YnI+Jm5ic3A7ICZu YnNwOyAvLyAmbmJzcDsgY29udGV4dC4mcXVvdDs8YnI+PGJyPiZuYnNwOyAmbmJzcDsgL0luIHRo ZSBYQ09OIGRhdGEgbW9kZWwgY2wuNC42LjUvW1JGQzY1MDFdIGl0IHVzZXMgdGhlIHRlcm0gJnF1 b3Q7dXNlciZxdW90Ozxicj4mbmJzcDsgJm5ic3A7IHRvIGRlc2NyaWJlIHRoZSBjb25jZXB0IG91 dGxpbmVkIGluIHRoZSBkcmFmdCBkZWZpbml0aW9uLiBSRkM0NTc1PGJyPiZuYnNwOyAmbmJzcDsg YWxzbyB1c2VzIHRoZSB0ZXJtICZxdW90O3VzZXImcXVvdDsgZm9yIHRoaXMuPGJyPjxicj4mbmJz cDsgJm5ic3A7IEluIENMVUUgd2UgdXNlIHBhcnRpY2lwYW50IGFzIHBlciB0aGUgZGVmaW5pdGlv biBhYm92ZSAoaS5lLiBpbjxicj4mbmJzcDsgJm5ic3A7IHRoZSBkZWZpbml0aW9uIG9mIEVuZHBv aW50IGFuZCBNQ1UpIGJ1dCB3ZSBhbHNvIHVzZSAmcXVvdDtwYXJ0aWNpcGFudCZxdW90Ozxicj4m bmJzcDsgJm5ic3A7IHRvIG1lYW4gc29tZW9uZSBjYXB0dXJlZCBieSB0aGUgZW5kcG9pbnQsIGku ZS4gdGhlIHBlb3BsZSBpbiB0aGUgcm9vbS48YnI+PGJyPiZuYnNwOyAmbmJzcDsgSW4gb3JkZXIg dG8gbWluaW1pc2UgYW55IGNvbmZ1c2lvbiBiZXR3ZWVuIHRoZSB0d28gdXNlcyBJIHByb3Bvc2U8 YnI+Jm5ic3A7ICZuYnNwOyB0aGF0IHdlIGNoYW5nZSB0aGUgbGF0ZXIgdXNlIHRvICZxdW90O3Bl cnNvbiZxdW90OyBpbiBvdXIgZG9jdW1lbnRzLjxicj48YnI+Jm5ic3A7ICZuYnNwOyBGb3IgZXhh bXBsZTogaW4gdGhlIGZyYW1ld29yazo8YnI+Jm5ic3A7ICZuYnNwOyAtICZxdW90O1BhcnRpY2lw YW50IEluZm9ybWF0aW9uJnF1b3Q7IGJlY29tZXMgJnF1b3Q7UGVyc29uIEluZm9ybWF0aW9uJnF1 b3Q7LDxicj4mbmJzcDsgJm5ic3A7IC0gJnF1b3Q7cGFydGljaXBhbnQgdHlwZSZxdW90OyBiZWNv bWVzICZxdW90O3BlcnNvbiB0eXBlJnF1b3Q7Ljxicj4mbmJzcDsgJm5ic3A7IC0gV2hlcmUgJnF1 b3Q7cGFydGljaXBhbnQmcXVvdDsgaXMgdXNlZCBpbiB0aGUgdGV4dCBpdCBiZWNvbWVzICZxdW90 O3BlcnNvbiZxdW90OyBvcjxicj4mbmJzcDsgJm5ic3A7ICZxdW90O3Blb3BsZSZxdW90Oy48YnI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaS5lLiAmbmJzcDsgVGFibGUgLSBDYXB0dXJlcyB0aGUgY29u ZmVyZW5jZSB0YWJsZSB3aXRoIHNlYXRlZCBwZW9wbGUuPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBJbmRpdmlkdWFsIC0gQ2FwdHVyZXMgYW4gaW5kaXZpZHVhbCBwZXJzb24uPGJyPjxi cj48YnI+Jm5ic3A7ICZuYnNwOyBDaHJpc3RpYW48YnI+PGJyPiZuYnNwOyAmbmJzcDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jm5ic3A7ICZuYnNw OyBjbHVlIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPiZuYnNwOyAmbmJzcDsgPGEgaHJl Zj0ibWFpbHRvOmNsdWVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jbHVlQGlldGYub3JnPC9h PiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpjbHVlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+Y2x1ZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlPC9hPjxicj48YnI+PG86cD48 L286cD48L3A+PC9ibG9ja3F1b3RlPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Jsb2NrcXVvdGU+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE26CRPMBOXPRD08pol_-- From nobody Tue May 13 17:03: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 198641A0166 for ; Tue, 13 May 2014 17:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 HZTD_bzXn6jw for ; Tue, 13 May 2014 17:03:35 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.208]) by ietfa.amsl.com (Postfix) with ESMTP id E55051A0160 for ; Tue, 13 May 2014 17:03:34 -0700 (PDT) Received: from [216.82.241.100:1881] by server-16.bemta-8.messagelabs.com id A5/6B-04045-0D2B2735; Wed, 14 May 2014 00:03:28 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-16.tower-220.messagelabs.com!1400025806!3958568!2 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 633 invoked from network); 14 May 2014 00:03:27 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-16.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 14 May 2014 00:03:27 -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, 13 May 2014 17:03:26 -0700 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 13 May 2014 17:03:26 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 13 May 2014 17:03:25 -0700 Thread-Topic: more taxonomy Thread-Index: Ac9u8GFqVUnsOP5fTpiqTclwzPXLpg== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5B@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_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5BCRPMBOXPRD08pol_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VeQa3NzDOUEIDO6VP5CjJin1WxU Subject: [clue] more taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 14 May 2014 00:03:37 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5BCRPMBOXPRD08pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm looking at more terms and concepts that are used both in CLUE and in dr= aft-ietf-avtext-rtp-grouping-taxonomy-01. Should we add some of this to the framework definitions section, to indicat= e how the CLUE terms relate to taxonomy terms? CLUE Media Capture: I'm not sure about this. I was going to say it is the = same as taxonomy Media Capture, with either physical stimulus or synthetic = stimulus. But the taxonomy draft says a CLUE Media Capture is the same as = a taxonomy Media Source. I don't see how it makes any difference to CLUE e= ither way. What do you think? CLUE Individual Encoding: I think this is parameters of the taxonomy Media = Encoder transformation. Taxonomy draft says "CLUE's 'Capture Encoding' pro= vides specific encoding configuration for this purpose [Media Encoder]". I= think it should be "CLUE's 'Individual Encoding'", not "Capture Encoding".= (suggest change this in taxonomy draft, also in Packet Stream section) CLUE Capture Encoding: same as taxonomy Encoded Stream. (suggest add this t= o taxonomy draft) CLUE Stream: same as taxonomy Packet Stream. (taxonomy draft already equat= es CLUE Stream with Packet Stream). CLUE Endpoint: includes a taxonomy End Point and a Participant. CLUE MCU: includes multiple taxonomy End Points and a Participant for each = conference. I can post suggestions to avtext to change the taxonomy draft regarding the= se CLUE terms, but I'd like to hear feedback from this group first. Regards, Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5BCRPMBOXPRD08pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m lookin= g at more terms and concepts that are used both in CLUE and in draft-ietf-a= vtext-rtp-grouping-taxonomy-01.

&nb= sp;

Should we add some of this to the framewo= rk definitions section, to indicate how the CLUE terms relate to taxonomy t= erms?

 

CLUE Media Capture: I’m not sure about this.  I was goin= g to say it is the same as taxonomy Media Capture, with either physical sti= mulus or synthetic stimulus.  But the taxonomy draft says a CLUE Media= Capture is the same as a taxonomy Media Source.  I don’t see ho= w it makes any difference to CLUE either way.  What do you think?=

 

CL= UE Individual Encoding: I think this is parameters of the taxonomy Media En= coder transformation.  Taxonomy draft says “CLUE’s ‘= Capture Encoding’ provides specific encoding configuration for this p= urpose [Media Encoder]”.  I think it should be “CLUE’= ;s ‘Individual Encoding’”, not “Capture Encoding= 221;. (suggest change this in taxonomy draft, also in Packet Stream section= )

 

CLUE Capture Encoding: same as taxonomy Encoded Stream. (suggest add th= is to taxonomy draft)

 <= /p>

CLUE Stream:  same as taxonomy Packet Stream. = (taxonomy draft already equates CLUE Stream with Packet Stream).=

 

CLUE End= point: includes a taxonomy End Point and a Participant.

 

CLUE MCU: include= s multiple taxonomy End Points and a Participant for each conference.<= /o:p>

 

I c= an post suggestions to avtext to change the taxonomy draft regarding these = CLUE terms, but I’d like to hear feedback from this group first.=

 

Re= gards,
Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5BCRPMBOXPRD08pol_-- From nobody Tue May 13 17:05: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 A17F51A0170 for ; Tue, 13 May 2014 17:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 xI_A-ezUrtAa for ; Tue, 13 May 2014 17:05:43 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.14]) by ietfa.amsl.com (Postfix) with ESMTP id 18F9A1A0166 for ; Tue, 13 May 2014 17:05:43 -0700 (PDT) Received: from [216.82.249.212:32431] by server-14.bemta-12.messagelabs.com id C6/24-04933-F43B2735; Wed, 14 May 2014 00:05:35 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-12.tower-219.messagelabs.com!1400025935!2804272!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21878 invoked from network); 14 May 2014 00:05:35 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-12.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 14 May 2014 00:05:35 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 13 May 2014 17:05:35 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 13 May 2014 17:05:33 -0700 Thread-Topic: taxonomy synchronization context and CLUE Thread-Index: Ac9vCDKbi4ax0VR2QAG6tt2IQchENg== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5C@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_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5CCRPMBOXPRD08pol_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xn8YWGAdFWUOlmOeIzir7jIWKjA Subject: [clue] taxonomy synchronization context and CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 00:05:44 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5CCRPMBOXPRD08pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Several months ago I posted this to avtext about the taxonomy draft, but di= dn't get a response. If the CLUE group agrees with this, I'll suggest it a= gain on the avtext list: Section 3.1.1.3 CLUE Scenes says this: "In CLUE "Capture Scene", "Capture Scene Entry" and "Captures" define an im= plied Synchronization Context." This isn't generally true. I don't think CLUE is attempting to define any n= ew way to associate streams for synchronization. Sometimes the media captur= es in a CLUE scene should be synchronized, but the synchronization would be= based on something else like CNAME, not because they are in the same CLUE = scene. Sometimes the captures in a CLUE scene do not need to be synchronize= d, for example when their source streams originated from different endpoint= s and then were combined into the same scene by a media switching mixer. So I don't think there is any value in mentioning this in the taxonomy draf= t. I suggest we just delete section 3.1.1.3. Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5CCRPMBOXPRD08pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Several months a= go I posted this to avtext about the taxonomy draft, but didn’t get a= response.  If the CLUE group agrees with this, I’ll suggest it = again on the avtext list:

 

Section 3.1.1.3 CLUE Scenes says this:

“In CLUE "Capture Scene", "= Capture Scene Entry" and "Captures" define an implied Synchr= onization Context.”

 

This isn’t generally true. I don’t = think CLUE is attempting to define any new way to associate streams for syn= chronization. Sometimes the media captures in a CLUE scene should be synchr= onized, but the synchronization would be based on something else like CNAME= , not because they are in the same CLUE scene. Sometimes the captures in a = CLUE scene do not need to be synchronized, for example when their source st= reams originated from different endpoints and then were combined into the s= ame scene by a media switching mixer.

 

So I don’t think there is any= value in mentioning this in the taxonomy draft. I suggest we just delete s= ection 3.1.1.3.

 

Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110AE5CCRPMBOXPRD08pol_-- From nobody Thu May 15 14:07:11 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2364E1A0188; Thu, 15 May 2014 14:07:05 -0700 (PDT) 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 xz8N6E_vsPRO; Thu, 15 May 2014 14:07:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4461A017D; Thu, 15 May 2014 14:07:02 -0700 (PDT) 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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140515210702.24708.20831.idtracker@ietfa.amsl.com> Date: Thu, 15 May 2014 14:07:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3moPyQGBUH80aAwMEDmVpiPDHRU Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-15.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, 15 May 2014 21:07:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Authors : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-15.txt Pages : 76 Date : 2014-05-15 Abstract: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling for setting up a telepresence session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-15 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 May 15 14:09: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 7D0BE1A0124 for ; Thu, 15 May 2014 14:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.78 X-Spam-Level: X-Spam-Status: No, score=0.78 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=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 rB4_AD5x-kDL for ; Thu, 15 May 2014 14:08:59 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210AE1A011B for ; Thu, 15 May 2014 14:08:59 -0700 (PDT) Received: from [216.82.241.100:54089] by server-14.bemta-8.messagelabs.com id 0D/82-17171-3EC25735; Thu, 15 May 2014 21:08:51 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-6.tower-220.messagelabs.com!1400188130!4575470!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1440 invoked from network); 15 May 2014 21:08:50 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-6.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 15 May 2014 21:08:50 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.215]) by Crpehubprd01.polycom.com ([::1]) with mapi; Thu, 15 May 2014 14:08:49 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 15 May 2014 14:08:48 -0700 Thread-Topic: Updates in framework-15 draft Thread-Index: Ac9wgb6RadSGsd1SROu6dRurlzztXw== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F0110B104@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_5C4AC54BFF7A0842A6A11F554D6FB52F0110B104CRPMBOXPRD08pol_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VVGgEa9_FIvHtD0fQiPdW9qIv64 Subject: [clue] Updates in framework-15 draft X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 15 May 2014 21:09:00 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110B104CRPMBOXPRD08pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is a summary of the changes: Changes from 14 to 15: 1. Add "=3D" and "<=3D" qualifiers to MaxCaptures attribute, and clarify the meaning regarding switched and composed MCC. 2. Add section 7.3.3 Global Capture Scene Entry List, and a few other sentences elsewhere that refer to global CSE sets. 3. Clarify: The Provider MUST be capable of encoding and sending all Captures (*that have an encoding group*) in a single Capture Scene Entry simultaneously. 4. Add voice activated switching example in section 12. 5. Change name of attributes Participant Info/Type to Person Info/Type. 6. Clarify the Person Info/Type attributes have the same meaning regardless of whether or not the capture has a Presentation attribute. 7. Update example section 12.1 to be consistent with the rest of the document, regarding MCC and capture attributes. 8. State explicitly each CSE has a unique ID. Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F0110B104CRPMBOXPRD08pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is a summar= y of the changes:

 

<= p class=3DMsoNormal>  Changes from 14 to 15:

 

   &nb= sp; 1. Add "=3D" and "<=3D" qualifiers to MaxCapture= s attribute, and

   &n= bsp;    clarify the meaning regarding switched and composed = MCC.

 

     2. Add section 7.3.3 Global Capture S= cene Entry List, and a few

 &nbs= p;      other sentences elsewhere that refer to gl= obal CSE sets.

 

     3. Clarify: The Provider MU= ST be capable of encoding and sending

        all Captures (*that have an enc= oding group*) in a single

  = ;      Capture Scene Entry simultaneously.

 

     4. Add voice activated switching example in secti= on 12.

 

  = ;      Info/Type.

 

    = 6. Clarify the Person Info/Type attributes have the same meaning

        reg= ardless of whether or not the capture has a Presentation<= /p>

        attribute.

 

     7. Update example section 12.1 to be cons= istent with the rest of

  &= nbsp;     the document, regarding MCC and capture attri= butes.

 

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/X_hVbYxTtXv9hlCV0VfzMhddhZY Subject: [clue] Design team meeting today? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 00:37:33 -0000 Hello Will there be a design team meeting today (20th May) given that the WebRTC interim is on? Regards, Christian From nobody Mon May 19 18:19: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 F09271A0228 for ; Mon, 19 May 2014 18:19:39 -0700 (PDT) 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 ydXCKxWxsGoZ for ; Mon, 19 May 2014 18:19:38 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020301A0225 for ; Mon, 19 May 2014 18:19:37 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n15so5069769wiw.15 for ; Mon, 19 May 2014 18:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L2UT3ktMCjPLd7KIKICYLbDBzg0/NSEIz/g9dfFWJqs=; b=UpbmrLK3E1Y+GZjq0UtvmHnnxizjD9ENFL55O/UB1/zVHXotZ3wvrp++/QQa6AQt9C kGHcWUK9oSFD3f+VF5dxj5GOeuTOEomkgnsQAdyTm98eObZoUcdO9ZGbyfXPPfEN8pzX 2+cVUhroT7aO2L6+xce6KZEBTILErArcbgdC/OEA+X9oEebMQuhPna21yd/ChhO+bXU6 UKiQEohOGGP30MsgFQhgW6v70u/o3FuHOYGpjOwOHwjIAzme+8Fd/F3Q4geTUs1JxpX2 iszwQ2wb3WPItFx4jidpPU48RdFZtmYO179rm54Hbe4E6Ba3HL5AdXdZppU+2qlXGnQK eGSw== MIME-Version: 1.0 X-Received: by 10.194.184.179 with SMTP id ev19mr370855wjc.85.1400548776354; Mon, 19 May 2014 18:19:36 -0700 (PDT) Received: by 10.216.202.74 with HTTP; Mon, 19 May 2014 18:19:36 -0700 (PDT) In-Reply-To: <537AA3C6.1030600@nteczone.com> References: <537AA3C6.1030600@nteczone.com> Date: Mon, 19 May 2014 20:19:36 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=047d7b87371e4e289c04f9caac07 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qW6LJSP-ksXCpj4CfgVPLbwAze4 Cc: "clue@ietf.org" Subject: Re: [clue] Design team meeting today? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 01:19:40 -0000 --047d7b87371e4e289c04f9caac07 Content-Type: text/plain; charset=UTF-8 No design team call tomorrow. On Mon, May 19, 2014 at 7:37 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello > > Will there be a design team meeting today (20th May) given that the WebRTC > interim is on? > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --047d7b87371e4e289c04f9caac07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No design team call tomorrow.


On Mon, May 19, 2014 at 7:37 PM, Chr= istian Groves <Christian.Groves@nteczone.com> wr= ote:
Hello

Will there be a design team meeting today (20th May) given that the WebRTC = interim is on?

Regards, Christian

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

--047d7b87371e4e289c04f9caac07-- From nobody Tue May 20 08:07:07 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12FE1A0153 for ; Tue, 20 May 2014 08:06:56 -0700 (PDT) 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 8n_iVabSx-pb for ; Tue, 20 May 2014 08:06:54 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEEF1A0182 for ; Tue, 20 May 2014 08:06:54 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta09.westchester.pa.mail.comcast.net with comcast id 4BDk1o0031swQuc59F6uCW; Tue, 20 May 2014 15:06:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id 4F6t1o00V3ZTu2S3bF6tgl; Tue, 20 May 2014 15:06:53 +0000 Message-ID: <537B6F8D.4030307@alum.mit.edu> Date: Tue, 20 May 2014 11:06:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <537AA3C6.1030600@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1400598414; bh=KUfvZR8QimyfL51TGhVvTxGvewaEO4PssKpyTuScqlA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DUdFpm4LxLAjm9akrR5yIZ6LPBTBW6ZvDAJSg3tAYkVyJ+mCYkvWIsMGHfUNKmIDY T4XeQ2q8mJWQZSA6lmiS/Acs/dwC1SXs6PI7kovTZMBlviwxVRfp6BSWnc4NQ6Pite pCO6Fyv7bH4M9GCKkvfedGhAKiehACatliylCygGnyHnoKcHc8ezOBLGSHnfCR5Fxv p8yx5GA+SVMIRq8mIXwXeQKite659aUftHs7KsYMWTaIBC8mYVlYqrcPjPMCVcXE4Q a498E8c8+VYkeU4AH/VDFFNSjlmTuCYmYoO3+oJFcgaFZoXWwBJF5mUJcbEOEF2jMV t5KP2fLlDCESw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6iLQF4T9kfFwtmb9Pk0n5Cg3EI0 Subject: Re: [clue] Design team meeting today? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 15:06:58 -0000 I updated the design team wiki to fill in the schedule a ways into the future. Currently there are no topics scheduled. When in doubt that is a good place to look. http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team Thanks, Paul On 5/19/14 9:19 PM, Mary Barnes wrote: > No design team call tomorrow. > > > On Mon, May 19, 2014 at 7:37 PM, Christian Groves > > > wrote: > > Hello > > Will there be a design team meeting today (20th May) given that the > WebRTC interim is on? > > Regards, Christian > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue May 27 16:24:23 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FFE1A07AB for ; Tue, 27 May 2014 16:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVTMua6wCWWZ for ; Tue, 27 May 2014 16:24:20 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268481A0671 for ; Tue, 27 May 2014 16:24:19 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id bs8so2706899wib.6 for ; Tue, 27 May 2014 16:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uzIDresJAtY6OxDlxlpTz5P4pSR1/4DUy/q/CI7+OBQ=; b=mgUn+AbZq25ltvAwaFoInATBqJlealvePyyRpQ5H+8a+zd3PklGiyJOS4bpNOwDPKv JxO4f9a/evE6vTofufpNpLrGn3dhmtITNtxO7PcPxoIy3SD+L1NQ+upPo+rq3qN6dpnn MXE85JHgCnFe4Lhv0nO3s5NbelvRxKw44QB1N4kbpYvh9mONWYBzkwnaD8N/NdKF+Hnm ZNuDFpT4Eaobe7nyp9NQ6C/n0Ixj6p03oDQtTAVduWgzjwYZtcwMFvK+v1uQuNJWgcqi zrrzTnDaKEmEHFi0LG+rZSLB15oEqrOnx1Up5UnqLclQI/m9gNkinIyPwiFE+Fdtzwmq D4jg== MIME-Version: 1.0 X-Received: by 10.194.157.68 with SMTP id wk4mr45951750wjb.42.1401233055723; Tue, 27 May 2014 16:24:15 -0700 (PDT) Received: by 10.216.202.74 with HTTP; Tue, 27 May 2014 16:24:15 -0700 (PDT) Date: Tue, 27 May 2014 18:24:15 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e0112cbfc88b75504fa69fe4c Archived-At: http://mailarchive.ietf.org/arch/msg/clue/4aT7m1wA_UB4LIJDyTB-QUhSdxE Subject: [clue] Call for adoption: draft-presta-clue-protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 27 May 2014 23:24:21 -0000 --089e0112cbfc88b75504fa69fe4c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I'm not sure if folks noticed, but =10Roberta uploaded a revised version of the protocol document on May 9th (I don't see the email notification of such in the archives): http://datatracker.ietf.org/doc/draft-presta-clue-protocol/ Per discussions from IETF-89, the plan was to do a call for adoption to use this document as the basis for the WG deliverable. Please raise any concerns no later than June 10th, 2014. Regards, Mary. --089e0112cbfc88b75504fa69fe4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm not sure if folks notic= ed, but =10Roberta uploaded a revised version of the protocol document on M= ay 9th (I don't see the email notification of such in the archives): http:= //datatracker.ietf.org/doc/draft-presta-clue-protocol/

Per discussions from IETF-89, the plan was to do a call= for adoption to use this document as the basis for the WG deliverable.

Please raise any concerns no later than June 10th, 20= 14. =C2=A0

Regards,
Mary.
--089e0112cbfc88b75504fa69fe4c-- From nobody Wed May 28 18:00: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 43BED1A07D0 for ; Wed, 28 May 2014 18:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwrPc-jhn_Gw for ; Wed, 28 May 2014 18:00:33 -0700 (PDT) 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 AA86C1A0310 for ; Wed, 28 May 2014 18:00:33 -0700 (PDT) Received: from ppp118-209-175-231.lns20.mel6.internode.on.net ([118.209.175.231]:53316 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WpohZ-0007yt-PV for clue@ietf.org; Thu, 29 May 2014 11:00:13 +1000 Message-ID: <538686A8.3030407@nteczone.com> Date: Thu, 29 May 2014 11:00:24 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/rsQDdtjPite76TqffAIFwo3CHAM Subject: Re: [clue] Call for adoption: draft-presta-clue-protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 29 May 2014 01:00:35 -0000 Hello Mary, I missed that upload also. Whilst I haven't had a chance to do a detailed look at the latest version I'm OK with adopting it as a WG deliverable. FYI, I did see a note about a delta mechanism for Adverisements. I'm working on a draft to progress the discussion on this. Regards, Christian On 28/05/2014 9:24 AM, Mary Barnes wrote: > Hi all, > > I'm not sure if folks noticed, but Roberta uploaded a revised version > of the protocol document on May 9th (I don't see the email > notification of such in the archives): > http://datatracker.ietf.org/doc/draft-presta-clue-protocol/ > > Per discussions from IETF-89, the plan was to do a call for adoption > to use this document as the basis for the WG deliverable. > > Please raise any concerns no later than June 10th, 2014. > > Regards, > Mary. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu May 29 06:39: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 0924A1A0910 for ; Thu, 29 May 2014 06:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.989 X-Spam-Level: X-Spam-Status: No, score=-3.989 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, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 msHAydoSy9_N for ; Thu, 29 May 2014 06:39:50 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6171F1A0909 for ; Thu, 29 May 2014 06:39:50 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id r20so660741wiv.15 for ; Thu, 29 May 2014 06:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZgpSBhMhArHmT9HrgT8oGMlP+K3FmUcEahB/EKlRbW0=; b=0bc/7HUtN5wBvmfbPlGw4xTa5ZUoYupyk6pQrrNgEADORT8debG60JV8thFs2YRUZ6 Hx1plN57U+3zrhWba2b0Zcw+5niA9jY9iaERjDjTZip3hNJgaRKTTVr2G2Gpl5SiZQiL 6VDp1AM9Cdrvd1oOwj6ue3eJeK7d5ZiiJWoSfm0Yo03sy0xpttbU7bNKdP4fR6vjORtn 7AC4SEFUbsTNxbqzmoeEM4ZmAm7BLay8fQgxrfbpdHIUjYJ6ClR761In8GsEfCiXlFt2 hG/bC6y95DC3XAwqV3hqhSgiG/7pth75gS9SmtiN3jsFwjP358OYuoIJmlOyGFa6k3Sq 8EHA== MIME-Version: 1.0 X-Received: by 10.180.107.130 with SMTP id hc2mr46824265wib.7.1401370785459; Thu, 29 May 2014 06:39:45 -0700 (PDT) Received: by 10.216.202.74 with HTTP; Thu, 29 May 2014 06:39:45 -0700 (PDT) Date: Thu, 29 May 2014 08:39:45 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e01494d52ddb5b404fa8a0ff0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/nFasaz3exSJIA79EFGzJhxnok3I Subject: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:39:53 -0000 --089e01494d52ddb5b404fa8a0ff0 Content-Type: text/plain; charset=UTF-8 Just a reminder that we are still on for today. At this time, the chairs have not yet received any slides. If we can please get them no later than 13:00 Central today (in about 4.5 hours), that will allow us time to get them uploaded. The call flow topic is still tentative. If there isn't material for that, we can review the issues in the issue tracker. I have closed a number of issues, opened a few new ones (I think are still a few missing that came out of design team meetings) and reassigned some in particular in cases where they weren't against a specific WG document. The tool wasn't working on Tuesday nite and the notifications did not go to all the document authors or mailing list, but I believe they went to the assignees. There is still a bit of funkiness as the WG data channel document doesn't show up as an option, so those are against the individual doc and the individual protocol document doesn't show up as an option, so those are still against the charter, but assigned to Roberta. Regards, Mary. On Thu, May 8, 2014 at 11:17 AM, Mary Barnes wrote: > Below please find the details for the CLUE WG virtual interim meeting > scheduled for May 29, 2014 (15:00-17:00 Central US). > > A preliminary agenda is on the wiki: > http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140529 > > Regards, > Mary. > > ---------- Forwarded message ---------- > From: Clue Working Group > Date: Thu, May 8, 2014 at 11:06 AM > Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim > To: clue-chairs@tools.ietf.org > > > > **** You can forward this email invitation to attendees **** > > Hello , > > Clue Working Group invites you to attend this online meeting. > > Topic: CLUE WG Virtual Interim > Date: Thursday, May 29, 2014 > Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00) > Meeting Number: 640 349 010 > Meeting Password: 1234 > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://ietf.webex.com/ietf/j.php?MTID=m6504f06c147f1aa7d8aadafe1093cffa > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: 1234 > 4. Click "Join". > > To view in other time zones or languages, please click the link: > https://ietf.webex.com/ietf/j.php?MTID=m4e5260b422e7fbc58daf046157c0f133 > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > Call-in toll number (US/Canada): 1-650-479-3208 > > Access code:640 349 010 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://ietf.webex.com/ietf/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > clue-chairs@tools.ietf.org > > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://ietf.webex.com/ietf/j.php?MTID=m30b4368d59ceb34681d5abd7e037cc6d > > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in the > meeting, please check whether you have the players installed on your > computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+16504793208x640349010# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows audio > and any documents and other materials exchanged or viewed during the > session to be recorded. By joining this session, you automatically consent > to such recordings. If you do not consent to the recording, discuss your > concerns with the meeting host prior to the start of the recording or do > not join the session. Please note that any such recordings may be subject > to discovery in the event of litigation. > > --089e01494d52ddb5b404fa8a0ff0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just a reminder that we are still on for today.

At this time, the chairs have not yet received any slides. =C2=A0I= f we can please get them no later than 13:00 Central today (in about 4.5 ho= urs), that will allow us time to get them uploaded. =C2=A0=C2=A0

The call flow topic is still tentative. If there isn= 9;t material for that, we can review the issues in the issue tracker. =C2= =A0I have closed a number of issues, opened a few new ones (I think are sti= ll a few missing that came out of design team meetings) and reassigned some= in particular in cases where they weren't against a specific WG docume= nt. =C2=A0The tool wasn't working on Tuesday nite and the notifications= did not go to all the document authors or mailing list, but I believe they= went to the assignees. =C2=A0There is still a bit of funkiness as the WG d= ata channel document doesn't show up as an option, so those are against= the individual doc and the individual protocol document doesn't show u= p as an option, so those are still against the charter, but assigned to Rob= erta.

Regards,
Mary.=C2=A0


On Thu, May 8, 2014 at 11:17 AM, M= ary Barnes <mary.ietf.barnes@gmail.com> wrote:
Below please find the detai= ls for the CLUE WG virtual interim meeting scheduled for May 29, 2014 (15:0= 0-17:00 Central US).

A preliminary agenda is on the wiki:=C2=A0

Regards,
Mary.

---------- Forwarded message ----------
From: Clue Working Group <messenger@webex.com&g= t;
Date: Thu, May 8, 2014 at 11:06 AM
Subject: (Forward to attendees) Meeti= ng invitation: CLUE WG Virtual Interim
To: clue-chairs@tools.ietf.org


**** You can forward this email invitation to attendees ****

Hel= lo ,

Clue Working Group invites you to attend this online meeting= .

Topic: CLUE WG Virtual Interim
Date: Thursday, May 29, 201= 4
Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00)
Meeting Num= ber: 640 349 010
Meeting Password: 1234


---------------= ----------------------------------------
To join the online meeting (N= ow from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06= c147f1aa7d8aadafe1093cffa
2. If requested, enter your name and email address.
3. If a password = is required, enter the meeting password: 1234
4. Click "Join"= ;.

To view in other time zones or languages, please click the lin= k:
https://ietf.webex.com/ietf/j.php?MTID=3Dm4e= 5260b422e7fbc58daf046157c0f133

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

Access code:640 349 010

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

You ca= n contact me at:
clue-chairs@tools.ietf.org


To add this meeti= ng to your calendar program (for example Microsoft Outlook), click this lin= k:
https://ietf.webex.com/ietf/j.php?MTID=3Dm30= b4368d59ceb34681d5abd7e037cc6d

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

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial=

http://ww= w.webex.com

CCP:+16504793208x640349010#

IMPORTANT NOTICE: This WebEx se= rvice includes a feature that allows audio and any documents and other mate= rials exchanged or viewed during the session to be recorded. By joining thi= s session, you automatically consent to such recordings. If you do not cons= ent to the recording, discuss your concerns with the meeting host prior to = the start of the recording or do not join the session. Please note that any= such recordings may be subject to discovery in the event of litigation.


--089e01494d52ddb5b404fa8a0ff0-- From nobody Thu May 29 06:57: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 AAEEC1A0941; Thu, 29 May 2014 06:57:20 -0700 (PDT) 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 d5AycD9rBEHP; Thu, 29 May 2014 06:57:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B211A0935; Thu, 29 May 2014 06:57:19 -0700 (PDT) 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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140529135719.31453.25688.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 06:57:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/XBi1zN6_4zfbINImpg-RUftdQd8 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-signaling-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:57:20 -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 Signaling Authors : Paul Kyzivat Lennard Xiao Christian Groves Robert Hansen Filename : draft-ietf-clue-signaling-01.txt Pages : 43 Date : 2014-05-29 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.presta-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-signaling-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 29 07:20: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 86E321A6F56 for ; Thu, 29 May 2014 07:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 N8eAwqhzpzuS for ; Thu, 29 May 2014 07:20:24 -0700 (PDT) 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 69C3F1A6F04 for ; Thu, 29 May 2014 07:20:21 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-26-5387421f32d1 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DA.3D.16420.F1247835; Thu, 29 May 2014 16:20:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Thu, 29 May 2014 16:20:15 +0200 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 Thread-Index: AQHPe0N5rlqw6A8WA0yNtQ7h0A/A2ptXmzYq Date: Thu, 29 May 2014 14:20:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D34861D@ESESSMB209.ericsson.se> References: 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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D34861DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvja68U3uwwZXDNhb7T11mtvi8fz+z A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxqv8xa8HrpIrFOycyNTC+Ce5i5OSQEDCR WLRrAguELSZx4d56ti5GLg4hgaOMEr9XHWaGcBYzSvw79Zqpi5GDg03AQqL7nzZIg4iAk8SF l+9ZQMLCAq4SnUcEIcJuEp3HfrNC2EYSjY2rwGwWAVWJTROa2EBsXgFfifnbN7GD2EICARJr Dn4Au4FTIFDiydM1YPWMQPd8P7WGCcRmFhCXuPVkPhPEnQISS/acZ4awRSVePv7HCmErSrQ/ bWCEqM+XmHViDhPELkGJkzOfsExgFJmFZNQsJGWzkJRBxPUkbkydwgZha0ssW/iaGcLWlZjx 7xALsvgCRvZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIFRdXDLb9UdjJffOB5iFOBgVOLh VVBpCxZiTSwrrsw9xCjNwaIkzntRozpYSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2NgnOqq rQGsD88c3OosFap8kekwS6n1L4Xi1topnlP8c3tOpzUtYD61Z8Xp6twF/NZCSX/+7Pa/OSfS a8bin76Zc069Lor/tJWDJcaU+5Sv4z1x19Xt8RzCnv3b0r2kQ4/Wp+30WcyrsqIkOSFOQb9K qyR8umX5rrQdGS1+wpP/HRLfeH/RRSWW4oxEQy3mouJEADIeofKLAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Q-heARaxp4m6PYkcXMxDs7PjA0g Subject: Re: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:20:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D34861DESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I don't think there is any major issue regarding the data channel that we n= eed to discus today. We are still waiting on outcome from RTCWEB (data channel general, DCEP) an= d MMUSIC (sctp-sdp). Regards, Christer ________________________________ From: clue [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barn= es@gmail.com] Sent: Thursday, 29 May 2014 4:39 PM To: CLUE Subject: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 Just a reminder that we are still on for today. At this time, the chairs have not yet received any slides. If we can pleas= e get them no later than 13:00 Central today (in about 4.5 hours), that wil= l allow us time to get them uploaded. The call flow topic is still tentative. If there isn't material for that, w= e can review the issues in the issue tracker. I have closed a number of is= sues, opened a few new ones (I think are still a few missing that came out = of design team meetings) and reassigned some in particular in cases where t= hey weren't against a specific WG document. The tool wasn't working on Tue= sday nite and the notifications did not go to all the document authors or m= ailing list, but I believe they went to the assignees. There is still a bi= t of funkiness as the WG data channel document doesn't show up as an option= , so those are against the individual doc and the individual protocol docum= ent doesn't show up as an option, so those are still against the charter, b= ut assigned to Roberta. Regards, Mary. On Thu, May 8, 2014 at 11:17 AM, Mary Barnes > wrote: Below please find the details for the CLUE WG virtual interim meeting sched= uled for May 29, 2014 (15:00-17:00 Central US). A preliminary agenda is on the wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140529 Regards, Mary. ---------- Forwarded message ---------- From: Clue Working Group > Date: Thu, May 8, 2014 at 11:06 AM Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim To: clue-chairs@tools.ietf.org **** You can forward this email invitation to attendees **** Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG Virtual Interim Date: Thursday, May 29, 2014 Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 640 349 010 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06c147f1aa7d8aadafe= 1093cffa 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=3Dm4e5260b422e7fbc58daf046157c0f133 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:640 349 010 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://ietf.webex.com/ietf/j.php?MTID=3Dm30b4368d59ceb34681d5abd7e037cc6d The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x640349010# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_7594FB04B1934943A5C02806D1A2204B1D34861DESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I don't think there is any major issue regarding the data channel that w= e need to discus today.

 

We are still waiting on outcome from RTCWEB (data channel general, DCEP)= and MMUSIC (sctp-sdp).

 

Regards,

 

Christer

 

 

From: clue [clue-bounces@ietf.org] on beha= lf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Thursday, 29 May 2014 4:39 PM
To: CLUE
Subject: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014
Just a reminder that we are still on for today.

At this time, the chairs have not yet received any slides.  If we= can please get them no later than 13:00 Central today (in about 4.5 hours)= , that will allow us time to get them uploaded.   

The call flow topic is still tentative. If there isn't material for th= at, we can review the issues in the issue tracker.  I have closed a nu= mber of issues, opened a few new ones (I think are still a few missing that= came out of design team meetings) and reassigned some in particular in cases where they weren't against a specif= ic WG document.  The tool wasn't working on Tuesday nite and the notif= ications did not go to all the document authors or mailing list, but I beli= eve they went to the assignees.  There is still a bit of funkiness as the WG data channel document doesn't show u= p as an option, so those are against the individual doc and the individual = protocol document doesn't show up as an option, so those are still against = the charter, but assigned to Roberta.

Regards,
Mary. 


On Thu, May 8, 2014 at 11:17 AM, Mary Barnes <mary.ie= tf.barnes@gmail.com> wrote:
Below please find the details for the CLUE WG virtual inte= rim meeting scheduled for May 29, 2014 (15:00-17:00 Central US).

A preliminary agenda is on the wiki: 

Regards,
Mary.

---------- Forwarded message ----------
From: Clue Working Group <messenger@we= bex.com>
Date: Thu, May 8, 2014 at 11:06 AM
Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim=
To: clue-ch= airs@tools.ietf.org



**** You can forward this email invitation to attendees ****

Hello ,

Clue Working Group invites you to attend this online meeting.

Topic: CLUE WG Virtual Interim
Date: Thursday, May 29, 2014
Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 640 349 010
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06c147f1aa7d8aadafe1093cffa<= /a>
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm4e5= 260b422e7fbc58daf046157c0f133

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

Access code:640 349 010

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

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


To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm30b= 4368d59ceb34681d5abd7e037cc6d

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

Sign up for a free trial of WebEx
http://= www.webex.com/go/mcemfreetrial

http://www.webex.com=

CCP:+16504793208x640349010#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.


--_000_7594FB04B1934943A5C02806D1A2204B1D34861DESESSMB209erics_-- From nobody Thu May 29 07:33: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 C8D8C1A094E for ; Thu, 29 May 2014 07:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.989 X-Spam-Level: X-Spam-Status: No, score=-3.989 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, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 VaPf54MWp5z4 for ; Thu, 29 May 2014 07:33:07 -0700 (PDT) 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 3035E1A014D for ; Thu, 29 May 2014 07:33:07 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so727851wib.11 for ; Thu, 29 May 2014 07:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jL+cnVwRXnhrRAVgymKzzmRkI+QM4EyqiHqOQA3QHmM=; b=RIXCU9gS5OZ4FHO2MU9G9dVpQLGH4ATKWAHbPm7GyrOZxnwnd3Vd0blAFxAtxh9fqC FFpcKtHqVTJ8QxdiRKlUSRQ03FNEQX1Au9g13UI7GXTLQ7sSoAeeUdyeXLd7yUgbSuAE SM9RoSXuXRlyQWIhua2qQulAC6ksISoU/u0JC5yZYQ2fcXBsmuOM66Krk85QgveqSdAc XUseIf9CxaJqDMoE4bJUoluGkdGxkj40QrtgLd6OL0JZ+djUFXHssMlE+5qV9xfxHRC+ 0lay8Yp/nGQV0Jsg/jfM9kgfRHWOoU+WDF+ibn/vXZeYxJj7RF5J0hXMawz4IpxyqdKd 5JlQ== MIME-Version: 1.0 X-Received: by 10.180.36.241 with SMTP id t17mr12357923wij.38.1401373980635; Thu, 29 May 2014 07:33:00 -0700 (PDT) Received: by 10.216.202.74 with HTTP; Thu, 29 May 2014 07:33:00 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D34861D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D34861D@ESESSMB209.ericsson.se> Date: Thu, 29 May 2014 09:33:00 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=e89a8f646fef5037fd04fa8ace60 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qis56fv_ZtjefMF6tHPOleHZQro Cc: CLUE Subject: Re: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:33:10 -0000 --e89a8f646fef5037fd04fa8ace60 Content-Type: text/plain; charset=UTF-8 Can you take a look at the issue in the tracker that is assigned to the data channel document? http://trac.tools.ietf.org/wg/clue/trac/ticket/21 While it's assigned to Roni, it would be nice to ensure that the requirements are clearly delineated somewhere. It might actually be useful to document each of the dependencies in separate tickets. Thanks, Mary. On Thu, May 29, 2014 at 9:20 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I don't think there is any major issue regarding the data channel that we > need to discus today. > > > > We are still waiting on outcome from RTCWEB (data channel general, DCEP) > and MMUSIC (sctp-sdp). > > > > Regards, > > > > Christer > > > > > ------------------------------ > *From:* clue [clue-bounces@ietf.org] on behalf of Mary Barnes [ > mary.ietf.barnes@gmail.com] > *Sent:* Thursday, 29 May 2014 4:39 PM > *To:* CLUE > *Subject:* [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 > > Just a reminder that we are still on for today. > > At this time, the chairs have not yet received any slides. If we can > please get them no later than 13:00 Central today (in about 4.5 hours), > that will allow us time to get them uploaded. > > The call flow topic is still tentative. If there isn't material for > that, we can review the issues in the issue tracker. I have closed a > number of issues, opened a few new ones (I think are still a few missing > that came out of design team meetings) and reassigned some in particular in > cases where they weren't against a specific WG document. The tool wasn't > working on Tuesday nite and the notifications did not go to all the > document authors or mailing list, but I believe they went to the assignees. > There is still a bit of funkiness as the WG data channel document doesn't > show up as an option, so those are against the individual doc and the > individual protocol document doesn't show up as an option, so those are > still against the charter, but assigned to Roberta. > > Regards, > Mary. > > > On Thu, May 8, 2014 at 11:17 AM, Mary Barnes > wrote: > >> Below please find the details for the CLUE WG virtual interim meeting >> scheduled for May 29, 2014 (15:00-17:00 Central US). >> >> A preliminary agenda is on the wiki: >> http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140529 >> >> Regards, >> Mary. >> >> ---------- Forwarded message ---------- >> From: Clue Working Group >> Date: Thu, May 8, 2014 at 11:06 AM >> Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual >> Interim >> To: clue-chairs@tools.ietf.org >> >> >> >> **** You can forward this email invitation to attendees **** >> >> Hello , >> >> Clue Working Group invites you to attend this online meeting. >> >> Topic: CLUE WG Virtual Interim >> Date: Thursday, May 29, 2014 >> Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00) >> Meeting Number: 640 349 010 >> Meeting Password: 1234 >> >> >> ------------------------------------------------------- >> To join the online meeting (Now from mobile devices!) >> ------------------------------------------------------- >> 1. Go to >> https://ietf.webex.com/ietf/j.php?MTID=m6504f06c147f1aa7d8aadafe1093cffa >> 2. If requested, enter your name and email address. >> 3. If a password is required, enter the meeting password: 1234 >> 4. Click "Join". >> >> To view in other time zones or languages, please click the link: >> https://ietf.webex.com/ietf/j.php?MTID=m4e5260b422e7fbc58daf046157c0f133 >> >> ------------------------------------------------------- >> To join the audio conference only >> ------------------------------------------------------- >> Call-in toll number (US/Canada): 1-650-479-3208 >> >> Access code:640 349 010 >> >> ------------------------------------------------------- >> For assistance >> ------------------------------------------------------- >> 1. Go to https://ietf.webex.com/ietf/mc >> 2. On the left navigation bar, click "Support". >> >> You can contact me at: >> clue-chairs@tools.ietf.org >> >> >> To add this meeting to your calendar program (for example Microsoft >> Outlook), click this link: >> https://ietf.webex.com/ietf/j.php?MTID=m30b4368d59ceb34681d5abd7e037cc6d >> >> The playback of UCF (Universal Communications Format) rich media files >> requires appropriate players. To view this type of rich media files in the >> meeting, please check whether you have the players installed on your >> computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. >> >> Sign up for a free trial of WebEx >> http://www.webex.com/go/mcemfreetrial >> >> http://www.webex.com >> >> CCP:+16504793208x640349010# >> >> IMPORTANT NOTICE: This WebEx service includes a feature that allows audio >> and any documents and other materials exchanged or viewed during the >> session to be recorded. By joining this session, you automatically consent >> to such recordings. If you do not consent to the recording, discuss your >> concerns with the meeting host prior to the start of the recording or do >> not join the session. Please note that any such recordings may be subject >> to discovery in the event of litigation. >> >> > --e89a8f646fef5037fd04fa8ace60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you take a look at the issue in the tracker that is as= signed to the data channel document? =C2=A0
While it's assigned to Roni, it would be nice to ensure that the r= equirements are clearly delineated somewhere. =C2=A0It might actually be us= eful to document each of the dependencies in separate tickets. =C2=A0

Thanks,
Mary.=C2=A0

<= /div>


On= Thu, May 29, 2014 at 9:20 AM, Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:

Hi,

=C2=A0

I don't think there is any major issue regarding the data channel th= at we need to discus today.

=C2=A0

We are still waiting on outcome from RTCWEB (data channel general, DCEP)= and MMUSIC (sctp-sdp).

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

Fro= m: clue [clu= e-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Thursday, 29 May 2014 4:39 PM
To: CLUE
Subject: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014
Just a reminder that we are still on for today.

At this time, the chairs have not yet received any slides. =C2=A0If we= can please get them no later than 13:00 Central today (in about 4.5 hours)= , that will allow us time to get them uploaded. =C2=A0=C2=A0

The call flow topic is still tentative. If there isn't material fo= r that, we can review the issues in the issue tracker. =C2=A0I have closed = a number of issues, opened a few new ones (I think are still a few missing = that came out of design team meetings) and reassigned some in particular in cases where they weren't against a sp= ecific WG document. =C2=A0The tool wasn't working on Tuesday nite and t= he notifications did not go to all the document authors or mailing list, bu= t I believe they went to the assignees. =C2=A0There is still a bit of funkiness as the WG data channel document doesn't sh= ow up as an option, so those are against the individual doc and the individ= ual protocol document doesn't show up as an option, so those are still = against the charter, but assigned to Roberta.

Regards,
Mary.=C2=A0


On Thu, May 8, 2014 at 11:17 AM, Mary Barnes <mary.ie= tf.barnes@gmail.com> wrote:
Below please find the details for the CLUE WG virtual inte= rim meeting scheduled for May 29, 2014 (15:00-17:00 Central US).

A preliminary agenda is on the wiki:=C2=A0

Regards,
Mary.

---------- Forwarded message ----------
From: Clue Working Group <messenger@we= bex.com>
Date: Thu, May 8, 2014 at 11:06 AM
Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim=
To: clue-ch= airs@tools.ietf.org



**** You can forward this email invitation to attendees ****

Hello ,

Clue Working Group invites you to attend this online meeting.

Topic: CLUE WG Virtual Interim
Date: Thursday, May 29, 2014
Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 640 349 010
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06c147f1aa7d8aadafe1093cffa<= /a>
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm4e5= 260b422e7fbc58daf046157c0f133

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

Access code:640 349 010

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

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


To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm30b= 4368d59ceb34681d5abd7e037cc6d

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

Sign up for a free trial of WebEx
http://= www.webex.com/go/mcemfreetrial

http://www.webex.com=

CCP:+16504793208x640349010#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.



--e89a8f646fef5037fd04fa8ace60-- From nobody Thu May 29 08:59: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 D976B1A6FB4 for ; Thu, 29 May 2014 08:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 QFyTWi_lrKGu for ; Thu, 29 May 2014 08:58:38 -0700 (PDT) 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 06F441A0426 for ; Thu, 29 May 2014 08:58:37 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-85-538759282108 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AB.5C.25910.82957835; Thu, 29 May 2014 17:58:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Thu, 29 May 2014 17:58:32 +0200 From: Christer Holmberg To: Mary Barnes Thread-Topic: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 Thread-Index: AQHPe0N5rlqw6A8WA0yNtQ7h0A/A2ptXmzYq///igwCAADlt8g== Date: Thu, 29 May 2014 15:58:31 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D34861D@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_pkvqtws76jkapni3nj6sl2ek1401379108354emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvja5GZHuwwcGpRhb7T11mtvi8fz+z A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWxfa1lQU9NxeWbXxkbGL9mdDFyckgImEi8 PbSZHcIWk7hwbz0biC0kcJRRon8ekM0FZC9mlPi9ohnI4eBgE7CQ6P6nDVIjIqAj8e3zW7B6 ZgEJiVUXPzCC2MICrhKzd55lhKhxk+g89psVpFVEwElizSJrkDCLgKrEpecrWEFsXqCSB9uX sEOsuskosfDDRWaQBKdAoMT6L1vAbEag276fWsMEsUtc4taT+UwQNwtILNlznhnCFpV4+fgf K0RNjsTuL/8ZIRYISpyc+YRlAqPILCTts5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI 4gsY2VcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbUwS2/DXYwvnzueIhRgINRiYdXQaUt WIg1say4MvcQozQHi5I470WN6mAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjOxfoky3iigw Rsxsqtmlpi/03utS8X8+rcV9/RXfXvzdzPm0qD9OWXD/RQnnmbs4gveGJl4vnt4UuOntkqsZ V+c9DdYRCny16HPEjsqnFSkMVbVGQc9/KSqXn+je9oo5r7edi+ezl0+5Xm73Zp2iR4eM9Ldl 8nGKXO9+45qwYDmPWSjbZMHFSizFGYmGWsxFxYkAn6Arn4oCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/KpapkmA0gV5kQDQfWQ0AtotuSpE Cc: CLUE Subject: Re: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:58:49 -0000 --_000_pkvqtws76jkapni3nj6sl2ek1401379108354emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think the ongoing data channel work is fine from a CLUE perspective, so t= here is nothing we need to bring to RTCWEB or MMUSIC regarding that. Me, Pa= ul and others have commented the work as individuals, but those comments ha= ve been more general than CLUE specific. There IS an open issue whether we are going to adopt "Richard's draft", IF = it progresses before our work is published. But, as the author has not done= anything regarding that draft, we cannot make such decision at this point.= I would ask whether e.g. Keith knows what/if will happen with that draft. Regards, Christer Sent from my Sony Ericsson Xperia arc S Mary Barnes wrote: Can you take a look at the issue in the tracker that is assigned to the dat= a channel document? http://trac.tools.ietf.org/wg/clue/trac/ticket/21 While it's assigned to Roni, it would be nice to ensure that the requiremen= ts are clearly delineated somewhere. It might actually be useful to docume= nt each of the dependencies in separate tickets. Thanks, Mary. On Thu, May 29, 2014 at 9:20 AM, Christer Holmberg > wrote: Hi, I don't think there is any major issue regarding the data channel that we n= eed to discus today. We are still waiting on outcome from RTCWEB (data channel general, DCEP) an= d MMUSIC (sctp-sdp). Regards, Christer ________________________________ From: clue [clue-bounces@ietf.org] on behalf = of Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Thursday, 29 May 2014 4:39 PM To: CLUE Subject: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 Just a reminder that we are still on for today. At this time, the chairs have not yet received any slides. If we can pleas= e get them no later than 13:00 Central today (in about 4.5 hours), that wil= l allow us time to get them uploaded. The call flow topic is still tentative. If there isn't material for that, w= e can review the issues in the issue tracker. I have closed a number of is= sues, opened a few new ones (I think are still a few missing that came out = of design team meetings) and reassigned some in particular in cases where t= hey weren't against a specific WG document. The tool wasn't working on Tue= sday nite and the notifications did not go to all the document authors or m= ailing list, but I believe they went to the assignees. There is still a bi= t of funkiness as the WG data channel document doesn't show up as an option= , so those are against the individual doc and the individual protocol docum= ent doesn't show up as an option, so those are still against the charter, b= ut assigned to Roberta. Regards, Mary. On Thu, May 8, 2014 at 11:17 AM, Mary Barnes > wrote: Below please find the details for the CLUE WG virtual interim meeting sched= uled for May 29, 2014 (15:00-17:00 Central US). A preliminary agenda is on the wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140529 Regards, Mary. ---------- Forwarded message ---------- From: Clue Working Group > Date: Thu, May 8, 2014 at 11:06 AM Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim To: clue-chairs@tools.ietf.org **** You can forward this email invitation to attendees **** Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG Virtual Interim Date: Thursday, May 29, 2014 Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 640 349 010 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06c147f1aa7d8aadafe= 1093cffa 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=3Dm4e5260b422e7fbc58daf046157c0f133 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:640 349 010 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://ietf.webex.com/ietf/j.php?MTID=3Dm30b4368d59ceb34681d5abd7e037cc6d The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x640349010# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_pkvqtws76jkapni3nj6sl2ek1401379108354emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi,=0A=
=0A=
I think the ongoing data channel work is fine from a CLUE perspective, so t=
here is nothing we need to bring to RTCWEB or MMUSIC regarding that. Me, Pa=
ul and others have commented the work as individuals, but those comments ha=
ve been more general than CLUE specific.=0A=
=0A=
There IS an open issue whether we are going to adopt "Richard's draft&=
quot;, IF it progresses before our work is published. But, as the author ha=
s not done anything regarding that draft, we cannot make such decision at t=
his point. I would ask whether e.g. Keith knows what/if will happen with th=
at draft.=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Mary Barnes <mary.ietf.barnes@gmail.com> wrote:=0A=
=0A=
Can you take a look at the issue in the tracker that is as= signed to the data channel document?  
While it's assigned to Roni, it would be nice to ensure that the requi= rements are clearly delineated somewhere.  It might actually be useful= to document each of the dependencies in separate tickets.  

Thanks,
Mary. 



On Thu, May 29, 2014 at 9:20 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

I don't think there is any major issue regarding the data channel that w= e need to discus today.

 

We are still waiting on outcome from RTCWEB (data channel general, DCEP)= and MMUSIC (sctp-sdp).

 

Regards,

 

Christer

 

 

Fro= m: clue [clu= e-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Thursday, 29 May 2014 4:39 PM
To: CLUE
Subject: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014
Just a reminder that we are still on for today.

At this time, the chairs have not yet received any slides.  If we= can please get them no later than 13:00 Central today (in about 4.5 hours)= , that will allow us time to get them uploaded.   

The call flow topic is still tentative. If there isn't material for th= at, we can review the issues in the issue tracker.  I have closed a nu= mber of issues, opened a few new ones (I think are still a few missing that= came out of design team meetings) and reassigned some in particular in cases where they weren't against a specif= ic WG document.  The tool wasn't working on Tuesday nite and the notif= ications did not go to all the document authors or mailing list, but I beli= eve they went to the assignees.  There is still a bit of funkiness as the WG data channel document doesn't show u= p as an option, so those are against the individual doc and the individual = protocol document doesn't show up as an option, so those are still against = the charter, but assigned to Roberta.

Regards,
Mary. 


On Thu, May 8, 2014 at 11:17 AM, Mary Barnes <mary.ie= tf.barnes@gmail.com> wrote:
Below please find the details for the CLUE WG virtual inte= rim meeting scheduled for May 29, 2014 (15:00-17:00 Central US).

A preliminary agenda is on the wiki: 

Regards,
Mary.

---------- Forwarded message ----------
From: Clue Working Group <messenger@we= bex.com>
Date: Thu, May 8, 2014 at 11:06 AM
Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim=
To: clue-ch= airs@tools.ietf.org



**** You can forward this email invitation to attendees ****

Hello ,

Clue Working Group invites you to attend this online meeting.

Topic: CLUE WG Virtual Interim
Date: Thursday, May 29, 2014
Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 640 349 010
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06c147f1aa7d8aadafe1093cffa<= /a>
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm4e5= 260b422e7fbc58daf046157c0f133

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

Access code:640 349 010

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

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


To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm30b= 4368d59ceb34681d5abd7e037cc6d

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

Sign up for a free trial of WebEx
http://= www.webex.com/go/mcemfreetrial

http://www.webex.com=

CCP:+16504793208x640349010#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.



--_000_pkvqtws76jkapni3nj6sl2ek1401379108354emailandroidcom_-- From nobody Thu May 29 09:11: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 1B6E71A6FCB for ; Thu, 29 May 2014 09:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.889 X-Spam-Level: X-Spam-Status: No, score=-8.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_FILL_THIS_FORM_SHORT=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 QkXu2dwY60He for ; Thu, 29 May 2014 09:11:34 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B291A6FC7 for ; Thu, 29 May 2014 09:11:29 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s4TGBKHp010437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 May 2014 11:11:22 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s4TGBKQF017089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 18:11:20 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.51]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 29 May 2014 18:11:20 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Mary Barnes Thread-Topic: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 Thread-Index: AQHPe0OOP1UNjkpDGUiXmAGs6JpQ15tXn4Eh///2HYCAACTeQA== Date: Thu, 29 May 2014 16:11:19 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1BF365@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D34861D@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B1BF365FR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/2W1HPM9XqeYrAzk9aW55_VWxpjM Cc: CLUE Subject: Re: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:11:42 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B1BF365FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a set of updates based on previous discussion prepared for the ejzak= draft. At the moment I am trying to find the cycles to prepare the i-d for submiss= ion. Ditto the related MSRP document Keith ________________________________ From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 29 May 2014 16:59 To: Mary Barnes Cc: CLUE Subject: Re: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 Hi, I think the ongoing data channel work is fine from a CLUE perspective, so t= here is nothing we need to bring to RTCWEB or MMUSIC regarding that. Me, Pa= ul and others have commented the work as individuals, but those comments ha= ve been more general than CLUE specific. There IS an open issue whether we are going to adopt "Richard's draft", IF = it progresses before our work is published. But, as the author has not done= anything regarding that draft, we cannot make such decision at this point.= I would ask whether e.g. Keith knows what/if will happen with that draft. Regards, Christer Sent from my Sony Ericsson Xperia arc S Mary Barnes wrote: Can you take a look at the issue in the tracker that is assigned to the dat= a channel document? http://trac.tools.ietf.org/wg/clue/trac/ticket/21 While it's assigned to Roni, it would be nice to ensure that the requiremen= ts are clearly delineated somewhere. It might actually be useful to docume= nt each of the dependencies in separate tickets. Thanks, Mary. On Thu, May 29, 2014 at 9:20 AM, Christer Holmberg > wrote: Hi, I don't think there is any major issue regarding the data channel that we n= eed to discus today. We are still waiting on outcome from RTCWEB (data channel general, DCEP) an= d MMUSIC (sctp-sdp). Regards, Christer ________________________________ From: clue [clue-bounces@ietf.org] on behalf = of Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Thursday, 29 May 2014 4:39 PM To: CLUE Subject: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 Just a reminder that we are still on for today. At this time, the chairs have not yet received any slides. If we can pleas= e get them no later than 13:00 Central today (in about 4.5 hours), that wil= l allow us time to get them uploaded. The call flow topic is still tentative. If there isn't material for that, w= e can review the issues in the issue tracker. I have closed a number of is= sues, opened a few new ones (I think are still a few missing that came out = of design team meetings) and reassigned some in particular in cases where t= hey weren't against a specific WG document. The tool wasn't working on Tue= sday nite and the notifications did not go to all the document authors or m= ailing list, but I believe they went to the assignees. There is still a bi= t of funkiness as the WG data channel document doesn't show up as an option= , so those are against the individual doc and the individual protocol docum= ent doesn't show up as an option, so those are still against the charter, b= ut assigned to Roberta. Regards, Mary. On Thu, May 8, 2014 at 11:17 AM, Mary Barnes > wrote: Below please find the details for the CLUE WG virtual interim meeting sched= uled for May 29, 2014 (15:00-17:00 Central US). A preliminary agenda is on the wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140529 Regards, Mary. ---------- Forwarded message ---------- From: Clue Working Group > Date: Thu, May 8, 2014 at 11:06 AM Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim To: clue-chairs@tools.ietf.org **** You can forward this email invitation to attendees **** Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG Virtual Interim Date: Thursday, May 29, 2014 Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 640 349 010 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06c147f1aa7d8aadafe= 1093cffa 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=3Dm4e5260b422e7fbc58daf046157c0f133 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:640 349 010 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://ietf.webex.com/ietf/j.php?MTID=3Dm30b4368d59ceb34681d5abd7e037cc6d The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x640349010# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_949EF20990823C4C85C18D59AA11AD8B1BF365FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have a set of updates based on = previous discussion prepared for the ejzak draft.
 
At the moment I am trying to find= the cycles to prepare the i-d for submission.
 
Ditto the related MSRP document
 
Keith

From: clue [mailto:clue-bounces@iet= f.org] On Behalf Of Christer Holmberg
Sent: 29 May 2014 16:59
To: Mary Barnes
Cc: CLUE
Subject: Re: [clue] Reminder: CLUE WG Virtual Interim on May 29, 201= 4

Hi,

I think the ongoing data channel work is fine from a CLUE perspective, so t=
here is nothing we need to bring to RTCWEB or MMUSIC regarding that. Me, Pa=
ul and others have commented the work as individuals, but those comments ha=
ve been more general than CLUE specific.

There IS an open issue whether we are going to adopt "Richard's draft&=
quot;, IF it progresses before our work is published. But, as the author ha=
s not done anything regarding that draft, we cannot make such decision at t=
his point. I would ask whether e.g. Keith knows what/if will happen with th=
at draft.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Can you take a look at the issue in the tracker that is as= signed to the data channel document?  
While it's assigned to Roni, it would be nice to ensure that the requi= rements are clearly delineated somewhere.  It might actually be useful= to document each of the dependencies in separate tickets.  

Thanks,
Mary. 



On Thu, May 29, 2014 at 9:20 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

I don't think there is any major issue regarding the data channel that w= e need to discus today.

 

We are still waiting on outcome from RTCWEB (data channel general, DCEP)= and MMUSIC (sctp-sdp).

 

Regards,

 

Christer

 

 

Fr= om: clue [cl= ue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Thursday, 29 May 2014 4:39 PM
To: CLUE
Subject: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014
Just a reminder that we are still on for today.

At this time, the chairs have not yet received any slides.  If we= can please get them no later than 13:00 Central today (in about 4.5 hours)= , that will allow us time to get them uploaded.   

The call flow topic is still tentative. If there isn't material for th= at, we can review the issues in the issue tracker.  I have closed a nu= mber of issues, opened a few new ones (I think are still a few missing that= came out of design team meetings) and reassigned some in particular in cases where they weren't against a specif= ic WG document.  The tool wasn't working on Tuesday nite and the notif= ications did not go to all the document authors or mailing list, but I beli= eve they went to the assignees.  There is still a bit of funkiness as the WG data channel document doesn't show u= p as an option, so those are against the individual doc and the individual = protocol document doesn't show up as an option, so those are still against = the charter, but assigned to Roberta.

Regards,
Mary. 


On Thu, May 8, 2014 at 11:17 AM, Mary Barnes <mary.ie= tf.barnes@gmail.com> wrote:
Below please find the details for the CLUE WG virtual inte= rim meeting scheduled for May 29, 2014 (15:00-17:00 Central US).

A preliminary agenda is on the wiki: 

Regards,
Mary.

---------- Forwarded message ----------
From: Clue Working Group <messenger@we= bex.com>
Date: Thu, May 8, 2014 at 11:06 AM
Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim=
To: clue-ch= airs@tools.ietf.org



**** You can forward this email invitation to attendees ****

Hello ,

Clue Working Group invites you to attend this online meeting.

Topic: CLUE WG Virtual Interim
Date: Thursday, May 29, 2014
Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 640 349 010
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06c147f1aa7d8aadafe1093cffa<= /a>
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm4e5= 260b422e7fbc58daf046157c0f133

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

Access code:640 349 010

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

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


To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm30b= 4368d59ceb34681d5abd7e037cc6d

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

Sign up for a free trial of WebEx
http://= www.webex.com/go/mcemfreetrial

http://www.webex.com=

CCP:+16504793208x640349010#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.



--_000_949EF20990823C4C85C18D59AA11AD8B1BF365FR712WXCHMBA11zeu_-- From nobody Thu May 29 09:39: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 47BB01A0177 for ; Thu, 29 May 2014 09:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 bhhhZf5MV5q3 for ; Thu, 29 May 2014 09:39:46 -0700 (PDT) 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 1CCA31A03E9 for ; Thu, 29 May 2014 09:39:45 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-8d-538762ccde8a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A7.EF.25910.CC267835; Thu, 29 May 2014 18:39:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.28]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Thu, 29 May 2014 18:39:39 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Mary Barnes Thread-Topic: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 Thread-Index: AQHPe0N5rlqw6A8WA0yNtQ7h0A/A2ptXmzYq///igwCAADlt8v//4gyAgAAol20= Date: Thu, 29 May 2014 16:39:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3488F3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D34861D@ESESSMB209.ericsson.se>, , <949EF20990823C4C85C18D59AA11AD8B1BF365@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1BF365@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D3488F3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3RvdMUnuwQfs+PYv9py4zWzxtPMto 8Xn/fmYHZo/WZ3tZPXbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSujIW3LrIVLCysWLtxG3sD 4+eYLkZODgkBE4lJJ3YwQthiEhfurWcDsYUEjjJK7P0nBWEvZpTYtE24i5GDg03AQqL7nzZI WEQgXeLq1QawcmYBCYlVFz8wgpQIC7hKdB4RhChxk+g89psVJCwi4CfxbL4RSJhFQFXiTuM7 JhCbV8BX4v2dJvYuRi6gRS+YJFbN3QGW4BSIlug4vw/sMkagy76fWsMEsUpc4taT+UwQFwtI LNlznhnCFpV4+fgfK4StKPHxFUQvs0C+xMT/nawQywQlTs58wjKBUXQWklGzkJTNQlIGEdeT uDF1ChuErS2xbOFrZghbV2LGv0MsyOILGNlXMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgRG 38Etvw12ML587niIUYCDUYmHV0GlLViINbGsuDL3EKM0B4uSOO9FjepgIYH0xJLU7NTUgtSi +KLSnNTiQ4xMHJxSDYyhSu/UP2anbnulyOzAWzFBW7N+TvvkCUHz58ulOhn/tedQlpxwwv7T hrXyLVs+3SuN+3R6tqTBniM1r9M+8edIelStjKzZJVX32ytZK2+dzLlTE85WJN0WbUg3Keld nc6QF3rh6qk4cbFQ3d/TJoW2v+wxOilg/eOm0EID3dMHVd8fqP+mcFqJpTgj0VCLuag4EQBv YE2mnwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/dJeiqOZnIRegdqgz16M2GAAXOEQ Cc: CLUE Subject: Re: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:39:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D3488F3ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Keith, Thanks for the information! >I have a set of updates based on previous discussion prepared for the ejza= k draft. > >At the moment I am trying to find the cycles to prepare the i-d for submis= sion. > >Ditto the related MSRP document So, I guess that means we still have to wait for a while before we can star= t calling it "Keith's draft". ....or, even cooler, "Keith Richards' draft" :) Regards, Christer From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 29 May 2014 16:59 To: Mary Barnes Cc: CLUE Subject: Re: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 Hi, I think the ongoing data channel work is fine from a CLUE perspective, so t= here is nothing we need to bring to RTCWEB or MMUSIC regarding that. Me, Pa= ul and others have commented the work as individuals, but those comments ha= ve been more general than CLUE specific. There IS an open issue whether we are going to adopt "Richard's draft", IF = it progresses before our work is published. But, as the author has not done= anything regarding that draft, we cannot make such decision at this point.= I would ask whether e.g. Keith knows what/if will happen with that draft. Regards, Christer Sent from my Sony Ericsson Xperia arc S Mary Barnes wrote: Can you take a look at the issue in the tracker that is assigned to the dat= a channel document? http://trac.tools.ietf.org/wg/clue/trac/ticket/21 While it's assigned to Roni, it would be nice to ensure that the requiremen= ts are clearly delineated somewhere. It might actually be useful to docume= nt each of the dependencies in separate tickets. Thanks, Mary. On Thu, May 29, 2014 at 9:20 AM, Christer Holmberg wrote: Hi, I don't think there is any major issue regarding the data channel that we n= eed to discus today. We are still waiting on outcome from RTCWEB (data channel general, DCEP) an= d MMUSIC (sctp-sdp). Regards, Christer From: clue [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barn= es@gmail.com] Sent: Thursday, 29 May 2014 4:39 PM To: CLUE Subject: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 Just a reminder that we are still on for today. At this time, the chairs have not yet received any slides. If we can pleas= e get them no later than 13:00 Central today (in about 4.5 hours), that wil= l allow us time to get them uploaded. The call flow topic is still tentative. If there isn't material for that, w= e can review the issues in the issue tracker. I have closed a number of is= sues, opened a few new ones (I think are still a few missing that came out = of design team meetings) and reassigned some in particular in cases where t= hey weren't against a specific WG document. The tool wasn't working on Tue= sday nite and the notifications did not go to all the document authors or m= ailing list, but I believe they went to the assignees. There is still a bi= t of funkiness as the WG data channel document doesn't show up as an option= , so those are against the individual doc and the individual protocol docum= ent doesn't show up as an option, so those are still against the charter, b= ut assigned to Roberta. Regards, Mary. On Thu, May 8, 2014 at 11:17 AM, Mary Barnes w= rote: Below please find the details for the CLUE WG virtual interim meeting sched= uled for May 29, 2014 (15:00-17:00 Central US). A preliminary agenda is on the wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140529 Regards, Mary. ---------- Forwarded message ---------- From: Clue Working Group Date: Thu, May 8, 2014 at 11:06 AM Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim To: clue-chairs@tools.ietf.org **** You can forward this email invitation to attendees **** Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG Virtual Interim Date: Thursday, May 29, 2014 Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 640 349 010 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06c147f1aa7d8aadafe= 1093cffa 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=3Dm4e5260b422e7fbc58daf046157c0f133 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:640 349 010 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://ietf.webex.com/ietf/j.php?MTID=3Dm30b4368d59ceb34681d5abd7e037cc6d The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x640349010# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_7594FB04B1934943A5C02806D1A2204B1D3488F3ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Keith,

Thanks for the information!

>I have a set of updates based on previous discussion prepared for the e= jzak draft.
>
>At the moment I am trying to find the cycles to prepare the i-d for sub= mission.
>
>Ditto the related MSRP document

So, I guess that means we still have to wait for a while before we can s= tart calling it "Keith's draft".

 

....or, even cooler, "Keith Richards' draft" :)

 

Regards,

 

Christer





From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 29 May 2014 16:59
To: Mary Barnes
Cc: CLUE
Subject: Re: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014


Hi,

I think the ongoing data channel work is fine from a CLUE perspective, so t= here is nothing we need to bring to RTCWEB or MMUSIC regarding that. Me, Pa= ul and others have commented the work as individuals, but those comments ha= ve been more general than CLUE specific.

There IS an open issue whether we are going to adopt "Richard's draft&= quot;, IF it progresses before our work is published. But, as the author ha= s not done anything regarding that draft, we cannot make such decision at t= his point. I would ask whether e.g. Keith knows what/if will happen with that draft.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Mary Barnes <mary.ietf.barnes@gmail.com> wrote:


Can you take a look at the issue in the tracker that is assigned to the dat= a channel document? 

http://trac.tools.ietf.org/wg/clue/trac/ticket/21
While it's assigned to Roni, it would be nice to ensure that the requiremen= ts are clearly delineated somewhere.  It might actually be useful to d= ocument each of the dependencies in separate tickets. 



Thanks,
Mary.






On Thu, May 29, 2014 at 9:20 AM, Christer Holmberg <christer.holmberg@er= icsson.com> wrote:

Hi,

I don't think there is any major issue regarding the data channel that we n= eed to discus today.

We are still waiting on outcome from RTCWEB (data channel general, DCEP) an= d MMUSIC (sctp-sdp).

Regards,

Christer





From: clue [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barn= es@gmail.com]
Sent: Thursday, 29 May 2014 4:39 PM
To: CLUE
Subject: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014


Just a reminder that we are still on for today.


At this time, the chairs have not yet received any slides.  If we can = please get them no later than 13:00 Central today (in about 4.5 hours), tha= t will allow us time to get them uploaded.  


The call flow topic is still tentative. If there isn't material for that, w= e can review the issues in the issue tracker.  I have closed a number = of issues, opened a few new ones (I think are still a few missing that came= out of design team meetings) and reassigned some in particular in cases where they weren't against a specific WG docum= ent.  The tool wasn't working on Tuesday nite and the notifications di= d not go to all the document authors or mailing list, but I believe they we= nt to the assignees.  There is still a bit of funkiness as the WG data channel document doesn't show up as an o= ption, so those are against the individual doc and the individual protocol = document doesn't show up as an option, so those are still against the chart= er, but assigned to Roberta.


Regards,
Mary.




On Thu, May 8, 2014 at 11:17 AM, Mary Barnes <mary.ietf.barnes@gmail.com= > wrote:

Below please find the details for the CLUE WG virtual interim meeting sched= uled for May 29, 2014 (15:00-17:00 Central US).


A preliminary agenda is on the wiki:
http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140529



Regards,

Mary.


---------- Forwarded message ----------
From: Clue Working Group <messenger@webex.com>
Date: Thu, May 8, 2014 at 11:06 AM
Subject: (Forward to attendees) Meeting invitation: CLUE WG Virtual Interim=
To: clue-chairs@tools.ietf.org



**** You can forward this email invitation to attendees ****

Hello ,

Clue Working Group invites you to attend this online meeting.

Topic: CLUE WG Virtual Interim
Date: Thursday, May 29, 2014
Time: 3:00 pm, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 640 349 010
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dm6504f06c147f1aa7d8aadafe= 1093cffa
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm4e5260b422e7fbc58daf046157c0f133 =

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

Access code:640 349 010

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

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


To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm30b4368d59ceb34681d5abd7e037cc6d =

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

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com

CCP:+16504793208x640349010#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.

--_000_7594FB04B1934943A5C02806D1A2204B1D3488F3ESESSMB209erics_-- From nobody Thu May 29 11:29: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 8E1DA1A0A17 for ; Thu, 29 May 2014 11:29:33 -0700 (PDT) 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 L3gHhUpOta2S for ; Thu, 29 May 2014 11:29:32 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id A6E901A0A15 for ; Thu, 29 May 2014 11:29:32 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta12.westchester.pa.mail.comcast.net with comcast id 7nLX1o0051wpRvQ5CuVUBp; Thu, 29 May 2014 18:29:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 7uVT1o0103ZTu2S3euVUCh; Thu, 29 May 2014 18:29:28 +0000 Message-ID: <53877C87.5080907@alum.mit.edu> Date: Thu, 29 May 2014 14:29:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D34861D@ESESSMB209.ericsson.se>, , <949EF20990823C4C85C18D59AA11AD8B1BF365@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D3488F3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3488F3@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1401388168; bh=Qg4T06hiF4tpiMwKiuedb0Fr8OO2w7vLZDc1Cs8cgH8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hnQLm2vZai3i7lQH+EXovQwfL9wumPiuGE7E7mYgaxBZo5eLZ1aWvye3+fTLANeEq 1u5lPIuSeEoP2d5ROKrnALiaX6U7DsBda/tlHYPEwFUlyJVJpaK3ACM6fdtEAmHcSM 2vgrClQgQ/mns+OYeAOqlA5sNQ0ZWdheIyxpglfmdEe4MsIhWbPQxSn8JEQ0AJWXoP GmEmtXmqSzOm03O00xpsAgx83FQuqMLTeFaeA8HUJJxWPr5sX1p52ssEuqXpE2ORn/ To/n9Y02K03rly7NDF9HtovVxpXEADqLYnLrnivOFzQOxB96Tt76lztsFnQGk4zdLi xlUfmATMU7awg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qxvknAwfyNbNpT6F3_-K3Bj_lTk Subject: Re: [clue] Reminder: CLUE WG Virtual Interim on May 29, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:29:33 -0000 On 5/29/14 12:39 PM, Christer Holmberg wrote: > So, I guess that means we still have to wait for a while before we can > start calling it "Keith's draft". > > ....or, even cooler, "Keith Richards' draft" :) Cool, but not quite right. How about "Keith's Richard draft"? :-) From nobody Fri May 30 07:54:11 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684D11A08E6 for ; Fri, 30 May 2014 07:54:10 -0700 (PDT) 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 zcn849QlfnIj for ; Fri, 30 May 2014 07:54:09 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 1247F1A0904 for ; Fri, 30 May 2014 07:54:07 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta08.westchester.pa.mail.comcast.net with comcast id 8E1l1o0050ldTLk58Eu30s; Fri, 30 May 2014 14:54:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id 8Eu31o0013ZTu2S01Eu3uQ; Fri, 30 May 2014 14:54:03 +0000 Message-ID: <53889B8A.5020502@alum.mit.edu> Date: Fri, 30 May 2014 10:54:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.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=1401461643; bh=q+EcVniLt8wcL/t82hUqzNK2aUilEH+xvSJxow1ZmbU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y9RaMg9aY1ents84U8LWSu8uhCJWeQegzKsXxl/gJ/Gk3oWcp+RdAJI33wjDOhXj7 FZTxey4kiO9lZwwvc4TIyrfYIFM0TPSWgRFegPFg9EkyISWwLJ8cWROKEWyrELMqFz bHOfBMQX863wexbJylKyXoJQuGJrHqbF7oMrre+zlof77jXl4EeKvk1yr4ev+39GIC +d2MXpuyzsBXt7K6d+ngkbC2yGFyVq34O91cvolcBkwm5NgF+Gez0uduFxIceefTll EVn5yj8/hIZOMQEcAK5tQ/eMzTL5zzC6Gav9Sv3WC2AGJPKs4c2z3MG741s9Mmthwy RwczjDZ7Lm3BA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ypupnjp6PAW_mQR_FMTOhiQNGGE Subject: [clue] Comments on draft-presta-clue-protocol-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, 30 May 2014 14:54:10 -0000 I reviewed the new version. It is looking very good. I noted the following points: Section 1 (Intro): In the following: depicted respectively in [I-D.kyzivat-clue-signaling] and [I-D.kyzivat-clue-signaling]. CLUE protocol messages flowing upon presumably there should be references to two *different* documents! Section 3: This section introduces terminology that is widely used and easily confused: CP (CLUE Participant?), CI (Channel Initiator), CR (Channel Receiver). I think these need to be in the definitions section. Section 4: This is just esthetic, but I don't love the naming of the re-advertisement message (READV). When I see it I can't prevent myself from trying to parse it as READ-V rather than RE-ADV. Perhaps it could be changed to RE-ADV? What do others think? Section 4.2: Shouldn't responseCode be a short? Doesn't this message have both a 'v' attribute as well as a element? What is the expected relationship between these? Section 4.7: The lastReceivedAdv is shown as a short. But I think the sequence numbers are integers. Section 5: While I know what you are trying to say, I find the following confusing: Over such a channel there are typically two CLUE streams between the channel terminations flowing in opposite directions. In other words, typically, both channel terminations act simultaneously as a MP and as a MC. Rather than "two CLUE streams", it might be clearer to say "two CLUE negotiations". E.g.: Over such a channel there may be multiple CLUE negotiations between the channel terminations. Each negotiation involves one MP and one MC. If both channel terminations (CPs?) act simultaneously as both MP and MC then there will be two concurrent negotiations. We herein discuss a single negotiation. That is just a thought - maybe there is a better word than negotiation. This doesn't cover the fact that the options exchange is yet another negotiation, but that one doesn't involve one MP and one MC.) Also, somewhere is a mention that separate sequence numbers are to be maintained for each of these negotiations. But I didn't see that notion fleshed out anywhere. Section 6: This state machine is a little confusing because, IIUC, it is a merge of two state machines - one for the CI and one for the CR. I think it would be clearer to show these separately. I don't understand what is intended regarding exchange of OPTIONS messages while in the ACTIVE state. That needs some explanation. Section 6.1: Doesn't the message need to be parsed according to the schema simply to determine the message type? So won't parse errors be detected *before* message-specific processing? In fact it probably must be processed by the clue-participant state machine. I'm not sure how that can result in changes to the MC or MP state. I guess *semantic* errors with an advertisement can be handled according to the MC state machine. If there is an assumption that there are multiple stages of parsing, done at different points within the state machines, then that needs to be explained. (I am postponing doing a detailed analysis of the state machines.) Section 7: Since major versions are incompatible, how should an implementation structure the OPTIONS message to maximize the possibility of interoperation? Suppose X supports only v1.0, Y supports only v2.0, and Z supports both v1.0 and v2.0. When Z is sending the initial OPTIONS message on a channel, what should it set "v" to? It has to choose either 1.0 or 2.0, but either choice means it won't be able to negotiate clue with one of the other endpoints. It seems like we need some way to exclude the OPTIONS message from versioning. The following is a little odd, but might solve the problem: - define v1.0, that includes *only* the OPTIONS message and its response. - define v2.0, that includes OPTIONS and everything else you have defined. - require all clue implementations to support at least v1.0 and one other version. Then, The initial OPTIONS message could always be sent with v=1.0. It could indicate support for whatever versions it supports. E.g., Suppose X only supports v1.0, and Y only supports v2.0. Section 8: I think we need to state a rule about processing of unknown elements that fall within the "any" placeholders in the schemas. In particular, in general I think we need an "ignore unknown stuff" rule. That is needed so that a higher versioned participant doesn't have to strip out everything in its messages that isn't compatible with the peer's lower version. But it can't be a universal ignore unknown stuff rule. For instance you can't ignore unknown message types - you must at least send a error about those. Section 9: I haven't reviewed the schema in detail yet. General editorial issue: All the XML is shown aligned to the left margin. Can it be indented? Thanks, Paul From nobody Fri May 30 08:20:37 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938E31A0913 for ; Fri, 30 May 2014 08:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=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 YyJBoQZK4MeY for ; Fri, 30 May 2014 08:20:30 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id E8ADF1A0924 for ; Fri, 30 May 2014 08:20:20 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta04.westchester.pa.mail.comcast.net with comcast id 8FCo1o00216LCl054FLGsD; Fri, 30 May 2014 15:20:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 8FLG1o00H3ZTu2S3SFLGXL; Fri, 30 May 2014 15:20:16 +0000 Message-ID: <5388A1B0.9090504@alum.mit.edu> Date: Fri, 30 May 2014 11:20:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.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=1401463216; bh=olTPonSMA4HQb+VzC1RLW8190nwrV5uv7PyJdMnfKy0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lTEH5rN/cA+3x8kqfi7/R5qgHnmDccBbQ7IXBLdzZcwHI0ePYSWXYAhPbwtIv3qdv RAQQVs+S6ph03wScppGnZSpCm4ECII7W9vaB2G5dQ8Mr7p8kmsC6umPuMNTdPzI3Yf 3oPJDmXAyq96zuBrDjjKJdUy533g6ipkfAbXCMpyqOoeiWtizWotwjnPWvkOUdPD5D 2Jo2ADEuD+qae9knY7Jjs+FB7sxjAxG3vkJy90Cyz8O2yRWXezFOZzsnGwnCKSx3Wt 8aAiO2Awr+ZVG+pxJQoRyPfryPsd5XCu67aAhfiglJxmvp3/XmpmQkgLbTq0KGEMk4 AKS12ztWO1mqA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/TwTGliCceolYXwIHLmkWqHHas9g Subject: [clue] Comments on draft-ietf-clue-signaling-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:20:32 -0000 I reviewed the new version of the signaling draft. IMO this is shaping up nicely. The following are a few comments: Section 4.3: CLUE-controlled media is controlled by the CLUE protocol as negotiated on the CLUE data channel with an "mid" included in the CLUE group. If negotiation of the data channel in SDP failed due to lack of CLUE support by the remote device or for any other reason the other "m" lines in the group are still considered CLUE-controlled and under all the restrictions of CLUE-controlled media specified in this document. What does it mean for an m-line to be clue-controlled by one end when the other end doesn't support clue? The other end will be expecting the m-line to operate according to "normal" rules. Section 4.5.2.1: A CLUE-capable recipient that receives an "m" line for a data channel but no corresponding CLUE group containing the "mid" of that "m" line SHOULD include a corresponding data channel "m" line if there are any other non-CLUE protocols it can convey over that channel, otherwise it SHOULD NOT negotiate the data channel. This seems too strong - it is specifying normative behavior in a case where we have no business doing so. I would say something weaker: If a CLUE-capable recipient receives an "m" line for a data channel but no corresponding CLUE group containing the "mid" of that "m" line, then the recipient's answer to this m-line is outside the scope of CLUE. Section 4.5.2.2: This says that if the offer contains recvonly m-lines then they should be accepted as sendonly m-lines. It fails to say anything about the need for these m-lines to be *compatibile* with encodings that the answerer wishes to advertise. There are two distinct cases here: The easy case: - X sends an offer to Y including some sendonly m-lines. - Y sends an answer that rejects those m-lines because it doesn't want them at that time. - Later, Y sends an offer to X. It includes recvonly m-lines matching the earlier received sendonly ones it had previously rejected. - unsurprisingly, X finds that these match encodings it has and so accepts them as sendonly in the answer. The hard case: - X, in its first offer after discovering that CLUE is to be used, includes some recvonly m-lines for encodings it would like to receive and hopes Y might be willing to send it. - Y, when it receives the offer from X, looks for matches from among the recvonly m-lines and encodings it is planning to advertise. It accepts those that match. ISTM that the "easy" case is important. It can significantly reduce the number of O/As, and it doesn't depend on one endpoint having any implicit knowledge of other endpoints. We might want to recommend that this be done. The "hard" case might make sense if endpoints typically are connecting to known configurations, or if the endpoint only supports a small number of encoding options. Section 4.5.3.1: If the answerer is going to enable CLUE, it might choose to refuse (port=0) the non-clue-controlled m-lines. Then it wouldn't need to be prepared to receive on them. I didn't see any mention of this. Perhaps we should not only mention this as a possibility, but indicate that clue capable endpoints should not drop a call just because the non-clue-controlled m-lines have been refused. Something similar to this is mentioned in 4.5.4.1, but relates to subsequent O/A exchanges. Section 4.5.4.2: There is *some* cost to including a data channel in subsequent offers. Should we condition the SHOULD here on the presence of a sip.clue feature tag in the signaling? Section 5.1: The 2nd paragraph ends in an incomplete sentence. Something must have been lost or forgotten. Thanks, Paul