From arnoud.vanwijk@realtimetext.org Wed Jun 1 02:46:24 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B8FE0694 for ; Wed, 1 Jun 2011 02:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ1AGC9o2svV for ; Wed, 1 Jun 2011 02:46:23 -0700 (PDT) Received: from mx-in02.nouzelle.com (mx-in02.nouzelle.com [87.119.194.141]) by ietfa.amsl.com (Postfix) with ESMTP id 40DCEE06DB for ; Wed, 1 Jun 2011 02:46:22 -0700 (PDT) Received: from internal02.nouzelle.com (mail.local [172.29.32.13]) by mx-in02.nouzelle.com (Postfix) with ESMTP id DDD5D102140CD for ; Wed, 1 Jun 2011 11:46:19 +0200 (CEST) Received: from mailscan.nouzelle.com (unknown [172.29.32.10]) by internal02.nouzelle.com (Postfix) with ESMTP id 96B5D10219AED for ; Wed, 1 Jun 2011 11:46:19 +0200 (CEST) X-Virus-Scanned: by amavisd-new at nouzelle.com Received: from internal02.nouzelle.com ([172.29.32.13]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id Dsq8QTF76kwV for ; Wed, 1 Jun 2011 11:46:07 +0200 (CEST) Received: from arnoud-van-wijks-macbook-pro.local (541BD3CF.cm-5-4d.dynamic.ziggo.nl [84.27.211.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by internal02.nouzelle.com (Postfix) with ESMTPSA id 6260410219AEC for ; Wed, 1 Jun 2011 11:46:07 +0200 (CEST) Message-ID: <4DE60A5E.105@realtimetext.org> Date: Wed, 01 Jun 2011 11:46:06 +0200 From: Arnoud van Wijk Organization: R3TF User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: <4DE0083A.3040102@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2A65D7@ESESSCMS0356.eemea.ericsson.se> <4DE4E7BF.8070301@cisco.com> In-Reply-To: <4DE4E7BF.8070301@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] 2 draft covering real-time text relevant for conferencing/ multiple participants and telepresence X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arnoud.vanwijk@realtimetext.org List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 09:46:24 -0000 Hi all, I am getting a clue about CLUE. :-) This is an excellent WG covering what we need for a good telePRESENCE without hurdles. If I communicate remote with other persons, I'd like to "forget" that I participate remote. There should be no limitations in the ability to communicate. The focus is at this moment on audio and video, lets make real-time text also a standard media to be used in all the work and scenarios as well with CLUE. The use of Total Conversation, where audio, video and real-time text are presented and available simultaneously will actually optimize the communication with others. As a deaf person, I need lipreading and real-time text together, others sign language, others having real-time text as support if the language used in the conference is not your native language and have the text in your own language. Or even to talk and discuss with others during the conference with real-time text while listening to the main conference. More about real-time text can be found at: http://www.realtimetext.org but most of you are already familiar with it. It is not only for persons with a hearing disability, it is for all breathing humans who want to communicate (and for a few robots out here :-) ) But using Total Conversation will remove the biggest Internet (telephony/conferencing) communication hurdle for persons who are deaf, hard of hearing or have a speech impairment. And that is not a joke. We have submitted now 2 drafts that are what I feel quite valuable for CLUE. Text media handling in RTP based real-time conferences https://datatracker.ietf.org/doc/draft-hellstrom-text-conference/ and Presentation of Text Conversation in real-time and en-bloc form https://datatracker.ietf.org/doc/draft-hellstrom-textpreview/ How would you feel about continuing these drafts under the CLUE banner? I am looking forward to your feedback and comments and well...anything that you throw at me and my fellow authors :-) Thank you. Sincerely Arnoud van Wijk PS we can also help with more insight on Total Conversation regarding quality of the video, camera position and the angle of the view (for example head for lipreading, upper body and sufficient area around the person for sign language etc.). From christer.holmberg@ericsson.com Wed Jun 1 03:34:55 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96002E07CE for ; Wed, 1 Jun 2011 03:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ83AXnzHHv5 for ; Wed, 1 Jun 2011 03:34:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BB0CAE0725 for ; Wed, 1 Jun 2011 03:34:53 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-88-4de615cc8bd8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5E.40.20773.CC516ED4; Wed, 1 Jun 2011 12:34:52 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 1 Jun 2011 12:34:51 +0200 From: Christer Holmberg To: Stephan Wenger , "Gorzynski, Mark E (The Right One)" , "clue@ietf.org" Date: Wed, 1 Jun 2011 12:34:49 +0200 Thread-Topic: Definitions: left, right Thread-Index: Acwf8WsNxPc7H5sCQuCkp0ZRoHP7YwAVfq6A Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F40@ESESSCMS0356.eemea.ericsson.se> References: <4168915E16BA9E47972F4A4B4EE3228276B786EB3D@GVW1096EXB.americas.hpqcorp.net> 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_7F2072F1E0DE894DA4B517B93C6A0585194E2E4F40ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Definitions: left, right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 10:34:55 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E2E4F40ESESSCMS0356e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, "Camera" only talks about the video part. We would also need something similar for audio. OR, we could use a more generic term, covering both audio and video. "captu= re-left", "capture-right" for example. Regards, Christer ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phan Wenger Sent: 1. kes=E4kuuta 2011 3:18 To: Gorzynski, Mark E (The Right One); clue@ietf.org Subject: Re: [clue] Definitions: left, right Camera Left seems to be one good choice. Should we go with this for now: "Camera Left, Camera Right: direction from a camera's viewpoint." "Left, Right": to be interpreted only in context, use Camera Left and Camer= a Right when possible". Stephan From: "Gorzynski, Mark E (The Right One)" > Date: Wed, 1 Jun 2011 00:03:11 +0000 To: Stephan Wenger >, "clue@ietf.or= g" > Subject: RE: Definitions: left, right In television and cinematography, the terms 'camera left' and 'camera right= ' are differentiated carefully from 'stage / house left', 'stage / house ri= ght'. There are many references. For example http://www.safilm.com.au/library/SA= FC_FILMMAKERS_HANDBOOK.pdf Camera Left/Camera Right: Directions given from the camera's point of view.= Opposite of STAGE LEFT and STAGE RIGHT, which are given from the actor's p= oint of view. May also be called LEFT FRAME and RIGHT FRAME. This makes sense if you observe that cameras in studios typically view acto= rs from the point of view of the local in-room audience. Thus 'stage left'= takes the sense of the actors while 'camera left' takes the sense of the l= ocal audience. We could use either for our use as long as we are clear. A point to notice= is that the receiver and sender will many times have an opposite sense. C= amera left for a receiver will often be stage left for a sender. Regards, Mark G. From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Stephan Wenger Sent: Tuesday, May 31, 2011 4:16 PM To: clue@ietf.org Subject: [clue] Definitions: left, right Hi, We did not come to a conclusion how to define "left" or "right". -Stage/auditorium/house right left have been shown to be confusing,because = some of us are not theatre majors :-) -sender/receiver left/right does not make sense either. Is "sender left" v= iewed from the viewpoint of a person in the sending endpoint room (house le= ft), or from the viewpoint of the guy adjusting the camera (which could eas= ily be stage left; at least that was the case in the TeleSuite rooms)? Als= o, we have senders and receivers that are not endpoints, i.e. MCUs. I like the idea of introducing a numbering convention, but that seems to be= solution space only. I have no suggestion except perhaps to avoid defining the words, but rather= remind CLUE authors that they can be confusing, and should only be used in= conjunction with appropriate attributes such as "from sending endpoint cam= era's view". Speaking as individual, and not as editor, I'm against any definition that = makes assumptions of "proper rendering". There is no such thing as proper= rendering; rendering is an implementation issue and I can imagine many cas= es where a camera signal that, from a person located in the room where it i= s captured, and facing the screens, would be on the left, should not be ren= dered on the right in a Remote room. (This tries to describe the natural f= eel of telepresence with more than one camera/screen). Opinions? Stephan --_000_7F2072F1E0DE894DA4B517B93C6A0585194E2E4F40ESESSCMS0356e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
"Camera"=20 only talks about the video part.
 
We would=20 also need something similar for audio.
 
OR, we could=20 use a more generic term, covering both audio and video. "capture-left",=20 "capture-right" for example.
 
Regards,
 
Christer
 
 
 
 

From: clue-bounces@ietf.org=20 [mailto:clue-bounces@ietf.org] On Behalf Of Stephan=20 Wenger
Sent: 1. kes=E4kuuta 2011 3:18
To: Gorzynski, = Mark E=20 (The Right One); clue@ietf.org
Subject: Re: [clue] Definitions:= =20 left, right

Camera Left seems to be one good choice.  Should we go with thi= s for=20 now:

"Camera Left, Camera Right: direction from a camera's viewpoint."

"Left, Right": to be interpreted only in context, use Camera Left an= d=20 Camera Right when possible".

Stephan
 

From: "Gorzynski, Mark E (The Right On= e)"=20 <mark.gorzynski@hp.com>
Date: Wed, 1 Jun 2011 00:03:11 +0000To: Stephan Wenger <stewe@stewe.org>, "clue@ietf.org" <clue@ietf.org>
Subject: RE: Definitions: left,=20 right

In=20 television and cinematography, the terms =91camera left=92 and =91camera = right=92 are=20 differentiated carefully from =91stage / house left=92, =91stage / house= =20 right=92.

There=20 are many references.  For example ht= tp://www.safilm.com.au/library/SAFC_FILMMAKERS_HANDBOOK.pdf<= /SPAN>

Camera=20 Left/Camera Right: Directions given from the camera's point of view. Oppo= site=20 of STAGE LEFT and STAGE RIGHT, which are given from the actor's point of = view.=20 May also be called LEFT FRAME and RIGHT FRAME.

This=20 makes sense if you observe that cameras in studios typically view actors = from=20 the point of view of the local in-room audience.  Thus =91stage left= =92 takes=20 the sense of the actors while =91camera left=92 takes the sense of the lo= cal=20 audience.

We=20 could use either for our use as long as we are clear.  A point to no= tice=20 is that the receiver and sender will many times have an opposite sense.&n= bsp;=20 Camera left for a receiver will often be stage left for a sender.=20

Regards,

Mark=20 G.

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] <= B>On=20 Behalf Of Stephan Wenger
Sent: Tuesday, May 31, 2011 4:16=20 PM
To: clue@ietf.org
Subject: [clue]= =20 Definitions: left, right

Hi,

We=20 did not come to a conclusion how to define "left" or=20 "right".

-Stage/auditorium/house=20 right left have been shown to be confusing,because some of us are not the= atre=20 majors :-)

-sender/receiver=20 left/right does not make sense either.  Is "sender left" viewed from= the=20 viewpoint of a person in the sending endpoint room (house left), or from = the=20 viewpoint of the guy adjusting the camera (which could easily be stage le= ft;=20 at least that was the case in the TeleSuite rooms)?  Also, we have=20 senders and receivers that are not endpoints, i.e.=20 MCUs.

I=20 like the idea of introducing a numbering convention, but that seems to be= =20 solution space only.

I=20 have no suggestion except perhaps to avoid defining the words, but rather= =20 remind CLUE authors that they can be confusing, and should only be used i= n=20 conjunction with appropriate attributes such as "from sending endpoint=20 camera's view".

Speaking=20 as individual, and not as editor, I'm against any definition that makes=20 assumptions of  "proper rendering".  There is no such thing as= =20 proper rendering; rendering is an implementation issue and I can imagine = many=20 cases where a camera signal that, from a person located in the room where= it=20 is captured, and facing the screens, would be on the left, should not be= =20 rendered on the right in a Remote room.  (This tries to describe the= =20 natural feel of telepresence with more than one=20 camera/screen).

Opinions?

Stephan

--_000_7F2072F1E0DE894DA4B517B93C6A0585194E2E4F40ESESSCMS0356e_-- From stephen.botzko@gmail.com Wed Jun 1 03:39:32 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EFDE07D0 for ; Wed, 1 Jun 2011 03:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h613IBe6gKc for ; Wed, 1 Jun 2011 03:39:31 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6A3EE07CE for ; Wed, 1 Jun 2011 03:39:30 -0700 (PDT) Received: by vws12 with SMTP id 12so5528850vws.31 for ; Wed, 01 Jun 2011 03:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Zzfr5HY70kDcPJuUEmWu6qxy+w7zfFDlbhy/3YEzq1c=; b=sss9E3tmH8d8dKpCG+KrlaawCiyPwCUEbvolm8wjJRzxHEWenBL5C1RuXlwGMBaAuM jAa0+onntBYWEyu61CN76cKsnVWnxvkEp9d862nrqzPgH8J5aZzng3+XdKEEHFPgf8Xg x0M0bAGezPp4V1Fq3qcxhf1x1BkPDiUWFwodk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=raSRM39xIc9mKGyEQl+S7zfaOf7hHjrsXKFGbvN9SxHlDdOG+m8+KJHPmyvMZ8ai3g Z2uLFO+yUUL2cBSSQMc9jOnsO24U+HnRgahSdMdJN4/NEEn1MoTkwZ5VOR1nP+w16B2o 1HfpQIGB6JNxmsT08Fb2KhKPzhqoDCvTF65r4= MIME-Version: 1.0 Received: by 10.52.98.198 with SMTP id ek6mr2098675vdb.240.1306924770299; Wed, 01 Jun 2011 03:39:30 -0700 (PDT) Received: by 10.52.116.65 with HTTP; Wed, 1 Jun 2011 03:39:30 -0700 (PDT) In-Reply-To: References: <4168915E16BA9E47972F4A4B4EE3228276B786EB3D@GVW1096EXB.americas.hpqcorp.net> Date: Wed, 1 Jun 2011 06:39:30 -0400 Message-ID: From: Stephen Botzko To: Stephan Wenger Content-Type: multipart/alternative; boundary=20cf307abdebae8d6204a4a42243 Cc: "clue@ietf.org" Subject: Re: [clue] Definitions: left, right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 10:39:32 -0000 --20cf307abdebae8d6204a4a42243 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Camera Left/Camera right is a sensible start, I think we will likely need another term. >>> I'm against any definition that makes assumptions of "proper rendering"= . There is no such thing as proper rendering; >>> I agree that making assumptions on "proper rendering" is an issue, and that we shouldn't imply that there is "improper" or "incorrect" rendering. However, the solution must enable rendering that preserves the correct spatial order. Since preserving the correct spatial order" generally requires spatial reversal/rotation prior to display, it is tricky to describe. It would be quite convenient to have a suitable definition. Stephen Botzko On Tue, May 31, 2011 at 8:17 PM, Stephan Wenger wrote: > Camera Left seems to be one good choice. Should we go with this for now: > > "Camera Left, Camera Right: direction from a camera's viewpoint." > > "Left, Right": to be interpreted only in context, use Camera Left and > Camera Right when possible". > > Stephan > > > From: "Gorzynski, Mark E (The Right One)" > Date: Wed, 1 Jun 2011 00:03:11 +0000 > To: Stephan Wenger , "clue@ietf.org" > > Subject: RE: Definitions: left, right > > In television and cinematography, the terms =91camera left=92 and =91came= ra > right=92 are differentiated carefully from =91stage / house left=92, =91s= tage / > house right=92. > > > > There are many references. For example > http://www.safilm.com.au/library/SAFC_FILMMAKERS_HANDBOOK.pdf > > > > Camera Left/Camera Right: Directions given from the camera's point of vie= w. > Opposite of STAGE LEFT and STAGE RIGHT, which are given from the actor's > point of view. May also be called LEFT FRAME and RIGHT FRAME. > > > > This makes sense if you observe that cameras in studios typically view > actors from the point of view of the local in-room audience. Thus =91sta= ge > left=92 takes the sense of the actors while =91camera left=92 takes the s= ense of > the local audience. > > > > We could use either for our use as long as we are clear. A point to noti= ce > is that the receiver and sender will many times have an opposite sense. > Camera left for a receiver will often be stage left for a sender. > > > > Regards, > > Mark G. > > > > > > > > > > > > > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > *On Behalf Of *Stephan Wenger > *Sent:* Tuesday, May 31, 2011 4:16 PM > *To:* clue@ietf.org > *Subject:* [clue] Definitions: left, right > > > > Hi, > > > > We did not come to a conclusion how to define "left" or "right". > > > > -Stage/auditorium/house right left have been shown to be confusing,becaus= e > some of us are not theatre majors :-) > > > > -sender/receiver left/right does not make sense either. Is "sender left" > viewed from the viewpoint of a person in the sending endpoint room (house > left), or from the viewpoint of the guy adjusting the camera (which could > easily be stage left; at least that was the case in the TeleSuite rooms)? > Also, we have senders and receivers that are not endpoints, i.e. MCUs. > > > > I like the idea of introducing a numbering convention, but that seems to = be > solution space only. > > > > I have no suggestion except perhaps to avoid defining the words, but rath= er > remind CLUE authors that they can be confusing, and should only be used i= n > conjunction with appropriate attributes such as "from sending endpoint > camera's view". > > > > Speaking as individual, and not as editor, I'm against any definition tha= t > makes assumptions of "proper rendering". There is no such thing as prop= er > rendering; rendering is an implementation issue and I can imagine many ca= ses > where a camera signal that, from a person located in the room where it is > captured, and facing the screens, would be on the left, should not be > rendered on the right in a Remote room. (This tries to describe the natu= ral > feel of telepresence with more than one camera/screen). > > > > Opinions? > > > > Stephan > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --20cf307abdebae8d6204a4a42243 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Camera Left/Camera right is a sensible start, I think we will likely need a= nother term.

>>>
=A0=A0 I'm against any definition t= hat makes assumptions of =A0"proper rendering". =A0There is no su= ch thing as proper rendering;
>>>
I agree that making assumptions on "proper rendering&q= uot; is an issue, and that we shouldn't imply that there is "impro= per" or "incorrect" rendering.

However, the solution = must enable rendering that preserves the correct spatial order.=A0 Since=A0= preserving the correct spatial order" generally requires spatial reve= rsal/rotation prior to display, it is tricky to describe.=A0 It would be qu= ite convenient to have a suitable definition.

Stephen Botzko



On Tue, May 31= , 2011 at 8:17 PM, Stephan Wenger <stewe@stewe.org> wrote:
Camera Left seems to be one good choice. = =A0Should we go with this for now:

"Camera Le= ft, Camera Right: direction from a camera's viewpoint."

"Left, Right": to be interpreted only in cont= ext, use Camera Left and Camera Right when possible".

Stephan
=A0

From: "Gorzynski, Mark E (The= Right One)" <mark.gorzynski@hp.com>
Dat= e: Wed, 1 Jun 2011 00:03:11 +0000
To: Stephan Wenger <stewe@stewe.org>, "clue@ietf.org" &l= t;clue@ietf.org><= div class=3D"im">
Subject: RE: Definitions: left= , right

In television and cinematography, the terms =91camera left= =92 and =91camera right=92 are differentiated carefully from =91stage / hou= se left=92, =91stage / house right=92.

=A0

There are many references.=A0 For example http://ww= w.safilm.com.au/library/SAFC_FILMMAKERS_HANDBOOK.pdf

=A0

Camera Left/Camera Right: Directions given from the camera's poi= nt of view. Opposite of STAGE LEFT and STAGE RIGHT, which are given from th= e actor's point of view. May also be called LEFT FRAME and RIGHT FRAME.=

=A0

This makes sense if you observe that cameras in studios typically vi= ew actors from the point of view of the local in-room audience.=A0 Thus =91= stage left=92 takes the sense of the actors while =91camera left=92 takes t= he sense of the local audience.

=A0

We could use either for our use as long as we are clear.=A0 A point = to notice is that the receiver and sender will many times have an opposite = sense.=A0 Camera left for a receiver will often be stage left for a sender.=

=A0

Regards,

Mark G.

=A0

=A0

=A0

=A0

=A0

=A0

=A0

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of= Stephan Wenger
Sent: Tuesday, May 31, 2011 4:16 PM
To: clue@ietf.org
Subject: [clue= ] Definitions: left, right

=A0=

Hi,

=A0

We did not come to a conclusion how to = define "left" or "right".

-Stage/auditorium/house= right left have been shown to be confusing,because some of us are not thea= tre majors :-)

=A0

-sender/receiver left/right does not make sense either. =A0Is &q= uot;sender left" viewed from the viewpoint of a person in the sending = endpoint room (house left), or from the viewpoint of the guy adjusting the = camera (which could easily be stage left; at least that was the case in the= TeleSuite rooms)? =A0Also, we have senders and receivers that are not endp= oints, i.e. MCUs.

=A0

I like the idea of introducing a numbering convention, but= that seems to be solution space only.

=A0

I have no suggestion except perhaps to avoid defining the = words, but rather remind CLUE authors that they can be confusing, and shoul= d only be used in conjunction with appropriate attributes such as "fro= m sending endpoint camera's view".

=A0

Speaking as individual, and not as editor, I'm against any d= efinition that makes assumptions of =A0"proper rendering". =A0The= re is no such thing as proper rendering; rendering is an implementation iss= ue and I can imagine many cases where a camera signal that, from a person l= ocated in the room where it is captured, and facing the screens, would be o= n the left, should not be rendered on the right in a Remote room. =A0(This = tries to describe the natural feel of telepresence with more than one camer= a/screen).

=A0

Opinions?

=A0

Stephan

=A0

<= /div>

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


--20cf307abdebae8d6204a4a42243-- From christer.holmberg@ericsson.com Wed Jun 1 03:43:27 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E955E07D0 for ; Wed, 1 Jun 2011 03:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXYg0Gi5PrGO for ; Wed, 1 Jun 2011 03:43:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6E79AE07CE for ; Wed, 1 Jun 2011 03:43:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-8c-4de617cddb9e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BB.2C.09774.DC716ED4; Wed, 1 Jun 2011 12:43:25 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 1 Jun 2011 12:43:25 +0200 From: Christer Holmberg To: Stephan Wenger , "clue@ietf.org" Date: Wed, 1 Jun 2011 12:43:23 +0200 Thread-Topic: Definition of "Solution" Thread-Index: Acwf6VNlgWT00TlOREi9SMX5Wxc1VQAXuRqg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F4F@ESESSCMS0356.eemea.ericsson.se> References: 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_7F2072F1E0DE894DA4B517B93C6A0585194E2E4F4FESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Definition of "Solution" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 10:43:27 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E2E4F4FESESSCMS0356e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Regarding "Telepresence extensions", I don't know what "non-telepresence SI= P" means. Why not only talk about "Protocol extensions defined, or referred to, in RF= C XXXX, to be used for establishment of telepresence conferences"? ...or something like that. Regards, Christer ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phan Wenger Sent: 1. kes=E4kuuta 2011 2:20 To: clue@ietf.org Subject: [clue] Definition of "Solution" Hi, A topic where we seemed to be converging: Use "solution" as a very informal word, to be interpreted widely and in con= text-sesitively. In other words, don't define it. To refer to the suite of documents defining a protocol, to be developed by= CLUE, refer top them as Telepresence Extensions, and use the definition be= low: "Telepresence Extensions": The protocol extensions beyond non-telepresence = SIP specified by RFC XXXX. (XXX to be replaced by the RFC editor with any = documents developed by the CLUE WG that contain normative content, such as = architecture, protocol specification, and whatnot.) Agreed? Stephan --_000_7F2072F1E0DE894DA4B517B93C6A0585194E2E4F4FESESSCMS0356e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Regarding=20 "Telepresence extensions", I don't know what "non-telepresence SIP" means.= =20
 
Why not only=20 talk about "Protocol extensions defined, or referred to, in RFC XXXX, to be= used=20 for establishment of telepresence conferences"?
 
...or=20 something like that.
 
Regards,
 
Christer

From: clue-bounces@ietf.org=20 [mailto:clue-bounces@ietf.org] On Behalf Of Stephan=20 Wenger
Sent: 1. kes=E4kuuta 2011 2:20
To:=20 clue@ietf.org
Subject: [clue] Definition of=20 "Solution"

Hi,

A topic where we seemed to be converging:

Use "solution" as a very informal word, to be interpreted widely and= in=20 context-sesitively.  In other words, don't define it.

To refer to the suite of documents defining a protocol,  to be= =20 developed by CLUE, refer top them as Telepresence Extensions, and use the= =20 definition below:

"Telepresence Extensions": The protocol extensions beyond=20 non-telepresence SIP specified by RFC XXXX.  (XXX to be replace= d by=20 the RFC editor with any documents developed by the CLUE WG that contain=20 normative content, such as architecture, protocol specification, and=20 whatnot.)

Agreed?

Stephan

--_000_7F2072F1E0DE894DA4B517B93C6A0585194E2E4F4FESESSCMS0356e_-- From stephen.botzko@gmail.com Wed Jun 1 03:54:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B694BE0784 for ; Wed, 1 Jun 2011 03:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo4SvM0H8tLk for ; Wed, 1 Jun 2011 03:54:55 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4C5E0703 for ; Wed, 1 Jun 2011 03:54:55 -0700 (PDT) Received: by vws12 with SMTP id 12so5540013vws.31 for ; Wed, 01 Jun 2011 03:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LB+34keJ1dkPclpvfpweHVRQg4xANc5+vpwtdbEmBcQ=; b=FN7rw+wahh57UzJSkW5d0EdRYCJXu9KrZBe3JNseDn+9J7kk1hNeSE9iVf34b9Gy1q jXzpL+k5DRwdEDGM8gx8V85E2XUw1L6H6ibTHBas9QSIITIHkJYPCaRjJXtABCtIV+ca mGyOoTpl6uCKe2dUg7CzqO63Pc4F1tMlWA1WY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aT+OAvhsrAtA34s7YNo7xMBUSlf30XZy3mRw8DuKlEnf2xj3v/5rj+DTdVDjFxfOYD X+rPTewFiDY3/3uOYsZD1gOYnSisbvY4VEUrVTNFfwiyK9QR8Bf6IpJN4y5/oZqFQrSk SQrwTz/Ae55vYns/H9lX7hOOrZJV0WVmn3A7Q= MIME-Version: 1.0 Received: by 10.52.76.131 with SMTP id k3mr4761582vdw.80.1306925694340; Wed, 01 Jun 2011 03:54:54 -0700 (PDT) Received: by 10.52.116.65 with HTTP; Wed, 1 Jun 2011 03:54:54 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F40@ESESSCMS0356.eemea.ericsson.se> References: <4168915E16BA9E47972F4A4B4EE3228276B786EB3D@GVW1096EXB.americas.hpqcorp.net> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F40@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Jun 2011 06:54:54 -0400 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec50160e3c24ff404a4a45976 Cc: "clue@ietf.org" Subject: Re: [clue] Definitions: left, right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 10:54:56 -0000 --bcaec50160e3c24ff404a4a45976 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Of course for audio, left and right are already used in RFC 3551 (among others) to describe the channels. The RFC doesn't define it, but "left" is clearly "listener's left", so the sense is backwards from "capture left". The AV and music industry broadly uses left/right in this way. Since audio is frequently captured from a microphone array (that can be gated/steered) it is important that the definitions not make any assumption= s that an audio stream or channel is captured from a single microphone. Frequently it is not. Also (unlike a camera), a microphone will pick up some level of sound from the entire room, no matter where it is placed. Stephen Botzko On Wed, Jun 1, 2011 at 6:34 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > "Camera" only talks about the video part. > > We would also need something similar for audio. > > OR, we could use a more generic term, covering both audio and video. > "capture-left", "capture-right" for example. > > Regards, > > Christer > > > > > > ------------------------------ > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Stephan Wenger > *Sent:* 1. kes=E4kuuta 2011 3:18 > *To:* Gorzynski, Mark E (The Right One); clue@ietf.org > *Subject:* Re: [clue] Definitions: left, right > > Camera Left seems to be one good choice. Should we go with this for now= : > > "Camera Left, Camera Right: direction from a camera's viewpoint." > > "Left, Right": to be interpreted only in context, use Camera Left and > Camera Right when possible". > > Stephan > > > From: "Gorzynski, Mark E (The Right One)" > Date: Wed, 1 Jun 2011 00:03:11 +0000 > To: Stephan Wenger , "clue@ietf.org" > Subject: RE: Definitions: left, right > > In television and cinematography, the terms =91camera left=92 and =91ca= mera > right=92 are differentiated carefully from =91stage / house left=92, =91s= tage / > house right=92. > > There are many references. For example > http://www.safilm.com.au/library/SAFC_FILMMAKERS_HANDBOOK.pdf > > Camera Left/Camera Right: Directions given from the camera's point of vie= w. > Opposite of STAGE LEFT and STAGE RIGHT, which are given from the actor's > point of view. May also be called LEFT FRAME and RIGHT FRAME. > > This makes sense if you observe that cameras in studios typically view > actors from the point of view of the local in-room audience. Thus =91sta= ge > left=92 takes the sense of the actors while =91camera left=92 takes the s= ense of > the local audience. > > We could use either for our use as long as we are clear. A point to noti= ce > is that the receiver and sender will many times have an opposite sense. > Camera left for a receiver will often be stage left for a sender. > > Regards, > > Mark G. > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > *On Behalf Of *Stephan Wenger > *Sent:* Tuesday, May 31, 2011 4:16 PM > *To:* clue@ietf.org > *Subject:* [clue] Definitions: left, right > > Hi, > > We did not come to a conclusion how to define "left" or "right". > > -Stage/auditorium/house right left have been shown to be > confusing,because some of us are not theatre majors :-) > > -sender/receiver left/right does not make sense either. Is "sender left= " > viewed from the viewpoint of a person in the sending endpoint room (house > left), or from the viewpoint of the guy adjusting the camera (which could > easily be stage left; at least that was the case in the TeleSuite rooms)? > Also, we have senders and receivers that are not endpoints, i.e. MCUs. > > I like the idea of introducing a numbering convention, but that seems to > be solution space only. > > I have no suggestion except perhaps to avoid defining the words, but > rather remind CLUE authors that they can be confusing, and should only be > used in conjunction with appropriate attributes such as "from sending > endpoint camera's view". > > Speaking as individual, and not as editor, I'm against any definition > that makes assumptions of "proper rendering". There is no such thing as > proper rendering; rendering is an implementation issue and I can imagine > many cases where a camera signal that, from a person located in the room > where it is captured, and facing the screens, would be on the left, shoul= d > not be rendered on the right in a Remote room. (This tries to describe t= he > natural feel of telepresence with more than one camera/screen). > > Opinions? > > Stephan > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --bcaec50160e3c24ff404a4a45976 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Of course for audio, left and right are already used in RFC 3551 (among oth= ers) to describe the channels.=A0 The RFC doesn't define it, but "= left" is clearly "listener's left", so the sense is back= wards from "capture left". The AV and music industry broadly uses= left/right in this way.

Since audio is frequently captured from a microphone array (that can be= gated/steered) it is important that the definitions not make any assumptio= ns that an audio stream or channel is captured from a single microphone.=A0= Frequently it is not.=A0 Also (unlike a camera), a microphone will pick up= some level of sound from the entire room, no matter where it is placed.
Stephen Botzko

On Wed, Jun 1, 2011 at= 6:34 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrot= e:
Hi,
=A0
"Camera"= =20 only talks about the video part.
=A0
We would=20 also need something similar for audio.
=A0
OR, we could=20 use a more generic term, covering both audio and video. "capture-left&= quot;,=20 "capture-right" for example.
=A0
Regards,
=A0
Christer
=A0
=A0
=A0
=A0

From: clue-bounces@ietf.org=20 [mailto:clue-b= ounces@ietf.org] On Behalf Of Stephan=20 Wenger
Sent: 1. kes=E4kuuta 2011 3:18
To: Gorzy= nski, Mark E=20 (The Right One); clue@= ietf.org
Subject: Re: [clue] Definitions:=20 left, right

Camera Left seems to be one good choice. =A0Should we go with this f= or=20 now:

"Camera Left, Camera Right: direction from a camera's viewp= oint."

"Left, Right": to be interpreted only in context, use Came= ra Left and=20 Camera Right when possible".

Stephan
=A0

From: "Gorzynski, Mark E (The = Right One)"=20 <mark.gorzy= nski@hp.com>
Date: Wed, 1= Jun 2011 00:03:11 +0000
To: Ste= phan Wenger <stewe@= stewe.org>, "clue@ietf.org" <clue@ietf.org>
Subject: RE: Definitions: left,=20 right

=20

In=20 television and cinematography, the terms =91camera left=92 and =91camera = right=92 are=20 differentiated carefully from =91stage / house left=92, =91stage / house= =20 right=92.

There=20 are many references.=A0 For example http://www.safilm.co= m.au/library/SAFC_FILMMAKERS_HANDBOOK.pdf

Camera=20 Left/Camera Right: Directions given from the camera's point of view. = Opposite=20 of STAGE LEFT and STAGE RIGHT, which are given from the actor's point= of view.=20 May also be called LEFT FRAME and RIGHT FRAME.

This=20 makes sense if you observe that cameras in studios typically view actors = from=20 the point of view of the local in-room audience.=A0 Thus =91stage left=92= takes=20 the sense of the actors while =91camera left=92 takes the sense of the lo= cal=20 audience.

We=20 could use either for our use as long as we are clear.=A0 A point to notic= e=20 is that the receiver and sender will many times have an opposite sense.= =A0=20 Camera left for a receiver will often be stage left for a sender.=20

Regards,

Mark=20 G.

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 Behalf Of Stephan Wenger
Sent: Tuesday, May 31, 2011 4:16= =20 PM
To: clue@= ietf.org
Subject: [clue]=20 Definitions: left, right

Hi,

We=20 did not come to a conclusion how to define "left" or=20 "right".

-Stage/auditorium/house=20 right left have been shown to be confusing,because some of us are not the= atre=20 majors :-)

-sender/receiver=20 left/right does not make sense either. =A0Is "sender left" view= ed from the=20 viewpoint of a person in the sending endpoint room (house left), or from = the=20 viewpoint of the guy adjusting the camera (which could easily be stage le= ft;=20 at least that was the case in the TeleSuite rooms)? =A0Also, we have=20 senders and receivers that are not endpoints, i.e.=20 MCUs.

I=20 like the idea of introducing a numbering convention, but that seems to be= =20 solution space only.

I=20 have no suggestion except perhaps to avoid defining the words, but rather= =20 remind CLUE authors that they can be confusing, and should only be used i= n=20 conjunction with appropriate attributes such as "from sending endpoi= nt=20 camera's view".

Speaking=20 as individual, and not as editor, I'm against any definition that mak= es=20 assumptions of =A0"proper rendering". =A0There is no such thing= as=20 proper rendering; rendering is an implementation issue and I can imagine = many=20 cases where a camera signal that, from a person located in the room where= it=20 is captured, and facing the screens, would be on the left, should not be= =20 rendered on the right in a Remote room. =A0(This tries to describe the=20 natural feel of telepresence with more than one=20 camera/screen).

Opinions?

Stephan

=

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


--bcaec50160e3c24ff404a4a45976-- From christer.holmberg@ericsson.com Wed Jun 1 03:56:27 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70761E0785 for ; Wed, 1 Jun 2011 03:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to20x8bu8DZe for ; Wed, 1 Jun 2011 03:56:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEBFE07D4 for ; Wed, 1 Jun 2011 03:56:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-57-4de61ad9580b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2D.F1.09774.9DA16ED4; Wed, 1 Jun 2011 12:56:25 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 1 Jun 2011 12:56:24 +0200 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Date: Wed, 1 Jun 2011 12:56:23 +0200 Thread-Topic: [clue] Definitions: Participant Thread-Index: Acwf7XoJs2kDmon4QJecxn4JCAjuAgAXHslw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> References: <4DE57EA5.6060406@cisco.com> In-Reply-To: <4DE57EA5.6060406@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 10:56:27 -0000 Hi, In my ears, "particiapant" has always been associated with a human. Also, my understanding is that ITU-T defines participant as a human partici= pating in a conference, and I strongly think we should avoid identical word= ing with different meaning - it will only cause problems sooner or later. Why can't we simply talk about "endpoint" or "client" when talking about th= e SIP device (whether it's a full blown telepresence room or a small mobile= phone)? That's wording that people are used to, so I don't see why we need= to come up with something new... Regards, Christer =20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 1. kes=E4kuuta 2011 2:50 > To: clue@ietf.org > Subject: Re: [clue] Definitions: Participant >=20 > I support using Participant in the 4353 sense. > (Its really the only definition that most of the software can=20 > use in a useful way. E.g. the conference roster is about=20 > these automata. This becomes especially obvious when you have=20 > the same "person" showing up multiple times in the roster.) >=20 > If there is need to talk about the human(s) associated with a=20 > participant, then it would make sense to define another term for that. >=20 > Thanks, > Paul (as individual) >=20 > On 5/31/2011 7:03 PM, Stephan Wenger wrote: > > Hi all, > > I thought I would quickly rev the definitions doc, and=20 > found out that=20 > > I cannot find agreements on a number of terms. This is the=20 > first of a=20 > > set of eamils that will hopefully lead us to close the=20 > definitions on=20 > > a few terms. > > So this email is about "Participant". > > > > We have the odd definition that RFC 4353 lists participant=20 > essentially=20 > > as a piece of software and not as a human. To Song Haibin, Steve=20 > > Botzko (and to me), Participants sounds like human, though. > > > > Several ways forward: > > > > 1. Use Participant in the 4353 sense only > > 2. Use Participant in the sense of a human participating in a > > telepresence session only. That would mean that there=20 > can be many > > participants at any endpoint, and endpoint can have=20 > no participant > > (empty room or webcam), and so forth. > > 3. Use Participant in the sense of 2) above, and add=20 > remark that if > > 4353 Participant is meant, this will be explicitely mentioned. > > > > My preference is 1. 2 and 3 have too much potential for confusion.=20 > > Shame on 4353 for that. > > > > Opinions? > > > > Stephan > > > > > > > > > > _______________________________________________ > > clue mailing 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 erlendur.karlsson@ericsson.com Wed Jun 1 04:11:43 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6785E07D3 for ; Wed, 1 Jun 2011 04:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFFCSKd9iG5B for ; Wed, 1 Jun 2011 04:11:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 33569E06D8 for ; Wed, 1 Jun 2011 04:11:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c6-4de61e66e5f3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 76.8E.20773.66E16ED4; Wed, 1 Jun 2011 13:11:35 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.19]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 1 Jun 2011 13:11:26 +0200 From: Erlendur Karlsson To: Stephen Botzko , Christer Holmberg Date: Wed, 1 Jun 2011 13:11:25 +0200 Thread-Topic: [clue] Definitions: left, right Thread-Index: AcwgSl6X3c9xzAkzTOSYmmNgcoajGQAAKXzg Message-ID: <41F80411E3CC644A844E6BED6E472FD91AEA9730D0@ESESSCMS0363.eemea.ericsson.se> References: <4168915E16BA9E47972F4A4B4EE3228276B786EB3D@GVW1096EXB.americas.hpqcorp.net> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F40@ESESSCMS0356.eemea.ericsson.se> 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_41F80411E3CC644A844E6BED6E472FD91AEA9730D0ESESSCMS0363e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Definitions: left, right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 11:11:44 -0000 --_000_41F80411E3CC644A844E6BED6E472FD91AEA9730D0ESESSCMS0363e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable With regard to: but "left" is clearly "listener's left", so the sense is ba= ckwards from "capture left" A left/righ audio capture is usually rendered in such a way that the listen= er hears the left audio captured signal from the left and the right audio captured signal from the right, so wouldn't capture-lef= t be in agreement with the listener's left? Br, Erlendur ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phen Botzko Sent: den 1 juni 2011 12:55 To: Christer Holmberg Cc: clue@ietf.org Subject: Re: [clue] Definitions: left, right Of course for audio, left and right are already used in RFC 3551 (among oth= ers) to describe the channels. The RFC doesn't define it, but "left" is cl= early "listener's left", so the sense is backwards from "capture left". The= AV and music industry broadly uses left/right in this way. Since audio is frequently captured from a microphone array (that can be gat= ed/steered) it is important that the definitions not make any assumptions t= hat an audio stream or channel is captured from a single microphone. Frequ= ently it is not. Also (unlike a camera), a microphone will pick up some le= vel of sound from the entire room, no matter where it is placed. Stephen Botzko On Wed, Jun 1, 2011 at 6:34 AM, Christer Holmberg > wrote: Hi, "Camera" only talks about the video part. We would also need something similar for audio. OR, we could use a more generic term, covering both audio and video. "captu= re-left", "capture-right" for example. Regards, Christer ________________________________ From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Stephan Wenger Sent: 1. kes=E4kuuta 2011 3:18 To: Gorzynski, Mark E (The Right One); clue@ietf.org Subject: Re: [clue] Definitions: left, right Camera Left seems to be one good choice. Should we go with this for now: "Camera Left, Camera Right: direction from a camera's viewpoint." "Left, Right": to be interpreted only in context, use Camera Left and Camer= a Right when possible". Stephan From: "Gorzynski, Mark E (The Right One)" > Date: Wed, 1 Jun 2011 00:03:11 +0000 To: Stephan Wenger >, "clue@ietf.or= g" > Subject: RE: Definitions: left, right In television and cinematography, the terms 'camera left' and 'camera right= ' are differentiated carefully from 'stage / house left', 'stage / house ri= ght'. There are many references. For example http://www.safilm.com.au/library/SA= FC_FILMMAKERS_HANDBOOK.pdf Camera Left/Camera Right: Directions given from the camera's point of view.= Opposite of STAGE LEFT and STAGE RIGHT, which are given from the actor's p= oint of view. May also be called LEFT FRAME and RIGHT FRAME. This makes sense if you observe that cameras in studios typically view acto= rs from the point of view of the local in-room audience. Thus 'stage left'= takes the sense of the actors while 'camera left' takes the sense of the l= ocal audience. We could use either for our use as long as we are clear. A point to notice= is that the receiver and sender will many times have an opposite sense. C= amera left for a receiver will often be stage left for a sender. Regards, Mark G. From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Stephan Wenger Sent: Tuesday, May 31, 2011 4:16 PM To: clue@ietf.org Subject: [clue] Definitions: left, right Hi, We did not come to a conclusion how to define "left" or "right". -Stage/auditorium/house right left have been shown to be confusing,because = some of us are not theatre majors :-) -sender/receiver left/right does not make sense either. Is "sender left" v= iewed from the viewpoint of a person in the sending endpoint room (house le= ft), or from the viewpoint of the guy adjusting the camera (which could eas= ily be stage left; at least that was the case in the TeleSuite rooms)? Als= o, we have senders and receivers that are not endpoints, i.e. MCUs. I like the idea of introducing a numbering convention, but that seems to be= solution space only. I have no suggestion except perhaps to avoid defining the words, but rather= remind CLUE authors that they can be confusing, and should only be used in= conjunction with appropriate attributes such as "from sending endpoint cam= era's view". Speaking as individual, and not as editor, I'm against any definition that = makes assumptions of "proper rendering". There is no such thing as proper= rendering; rendering is an implementation issue and I can imagine many cas= es where a camera signal that, from a person located in the room where it i= s captured, and facing the screens, would be on the left, should not be ren= dered on the right in a Remote room. (This tries to describe the natural f= eel of telepresence with more than one camera/screen). Opinions? Stephan _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_41F80411E3CC644A844E6BED6E472FD91AEA9730D0ESESSCMS0363e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
With regard to: but "left"= is clearly=20 "listener's left", so the sense is backwards from "capture=20 left"
 
A left/righ audio capture is usually rendered = in such=20 a way that the listener hears the left audio captured signal from the=20 left 
and the right audio captured signal from the right, so wouldn't=20 capture-left be in agreement with the listener's left?
 
Br,
 
Erlendur 
 
 
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On=20 Behalf Of Stephen Botzko
Sent: den 1 juni 2011 12:55
To= :=20 Christer Holmberg
Cc: clue@ietf.org
Subject: Re: [clue]= =20 Definitions: left, right

Of course for audio, left and right are already used in RFC 3551= =20 (among others) to describe the channels.  The RFC doesn't define it, b= ut=20 "left" is clearly "listener's left", so the sense is backwards from "captur= e=20 left". The AV and music industry broadly uses left/right in this=20 way.

Since audio is frequently captured from a microphone array (tha= t can=20 be gated/steered) it is important that the definitions not make any assumpt= ions=20 that an audio stream or channel is captured from a single microphone. = =20 Frequently it is not.  Also (unlike a camera), a microphone will pick = up=20 some level of sound from the entire room, no matter where it is=20 placed.

Stephen Botzko

On Wed, Jun 1, 2011 at 6:34 AM, Christer Holmberg = <christer.holmberg@ericsson.c= om>=20 wrote:
Hi,
 
"Camera" only talks abou= t the video=20 part.
 
We would also need somet= hing=20 similar for audio.
 
OR, we could use a more = generic=20 term, covering both audio and video. "capture-left", "capture-right" for= =20 example.
 
Regards,
 
Christer
 
 
 
 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf= .org]=20 On Behalf Of Stephan Wenger
Sent: 1. kes=E4kuuta= 2011=20 3:18
To: Gorzynski, Mark E (The Right One); clue@ietf.org
Subject: Re: [clue] Definit= ions:=20 left, right

Camera Left seems to be one good choice.  Should we go with t= his=20 for now:

"Camera Left, Camera Right: direction from a camera's viewpoint."<= /DIV>

"Left, Right": to be interpreted only in context, use Camera Left = and=20 Camera Right when possible".

Stephan
 

From: "Gorzynski, Mark E (The Right = One)"=20 <mark.gorzynski@hp.com>
Date: Wed, 1 Jun 2011 00:03:11=20 +0000
To: Stephan Wenger &l= t;stewe@stewe.org>= , "clue@ietf.org" <clue@ietf.org>
= Subject: RE: Definitions: left,=20 right

In=20 television and cinematography, the terms =91camera left=92 and =91camer= a right=92=20 are differentiated carefully from =91stage / house left=92, =91stage / = house=20 right=92.

There=20 are many references.  For example http://www.safilm.com.au/library/SAFC_FILMMAKERS_HANDBO= OK.pdf

Camera=20 Left/Camera Right: Directions given from the camera's point of view.=20 Opposite of STAGE LEFT and STAGE RIGHT, which are given from the actor'= s=20 point of view. May also be called LEFT FRAME and RIGHT FRAME.

This=20 makes sense if you observe that cameras in studios typically view actor= s=20 from the point of view of the local in-room audience.  Thus =91sta= ge=20 left=92 takes the sense of the actors while =91camera left=92 takes the= sense of=20 the local audience.

We=20 could use either for our use as long as we are clear.  A point to= =20 notice is that the receiver and sender will many times have an opposite= =20 sense.  Camera left for a receiver will often be stage left for a= =20 sender.

Regards,

Mark=20 G.

From:= clue-bounces@ietf= .org=20 [mailto:clue-bounces@ietf.org] On Behalf Of S= tephan=20 Wenger
Sent: Tuesday, May 31, 2011 4:16 PM
To: clue@ietf.org
Subject: [clue] Definitions= : left,=20 right

Hi,

We=20 did not come to a conclusion how to define "left" or=20 "right".

-Stage/auditorium/house=20 right left have been shown to be confusing,because some of us are not=20 theatre majors :-)

-sender/receiver=20 left/right does not make sense either.  Is "sender left" viewed fr= om=20 the viewpoint of a person in the sending endpoint room (house left), or= from=20 the viewpoint of the guy adjusting the camera (which could easily be st= age=20 left; at least that was the case in the TeleSuite rooms)?  Also, w= e=20 have senders and receivers that are not endpoints, i.e.=20 MCUs.

I=20 like the idea of introducing a numbering convention, but that seems to = be=20 solution space only.

I=20 have no suggestion except perhaps to avoid defining the words, but rath= er=20 remind CLUE authors that they can be confusing, and should only be used= in=20 conjunction with appropriate attributes such as "from sending endpoint= =20 camera's view".

Speaking=20 as individual, and not as editor, I'm against any definition that makes= =20 assumptions of  "proper rendering".  There is no such thing a= s=20 proper rendering; rendering is an implementation issue and I can imagin= e=20 many cases where a camera signal that, from a person located in the roo= m=20 where it is captured, and facing the screens, would be on the left, sho= uld=20 not be rendered on the right in a Remote room.  (This tries to des= cribe=20 the natural feel of telepresence with more than one=20 camera/screen).

Opinions?

Stephan


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


--_000_41F80411E3CC644A844E6BED6E472FD91AEA9730D0ESESSCMS0363e_-- From stephen.botzko@gmail.com Wed Jun 1 05:45:03 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC551E0C1D for ; Wed, 1 Jun 2011 05:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.094 X-Spam-Level: X-Spam-Status: No, score=-3.094 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxEICjH5jNAo for ; Wed, 1 Jun 2011 05:45:01 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED49913C47A for ; Wed, 1 Jun 2011 05:17:57 -0700 (PDT) Received: by vxg33 with SMTP id 33so5600631vxg.31 for ; Wed, 01 Jun 2011 05:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xKU+1BqYG71tlxvPiIzWWHEmBRfP52WLE7IjccjDA0Y=; b=LGwh7WYNLFrTfxC5uBXoY8haFHtc8CxzPmIsUPYbZh5D7GbO/D3lQ6HzgWiOtOjMkP oN4mLtN8ynxPSwqMbZ77JOD3uazDzLH6Ce9dWDVQdt0CAInJKzeXapTHjTE8yExdHL4k /moD7B9ohdxfGLgODyaOmu1HmHY6A6ltMeV6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AcdJ+MRH0Y3xb8hzj58taWD/ar5m9jJQTU0BTNm33nxuJP4jpWWOzEjLfNOO+TJebu 6u4hLMi0sB3v7UNCgC83U4vK7ASkX/Xy2f8M8PdJThXYtI4nZ4OqffIwqp+2pdFrb3Jb Q+aVxpNHidgcULhXf1dohyGdeNl3FqptlrBr8= MIME-Version: 1.0 Received: by 10.52.66.206 with SMTP id h14mr4293128vdt.40.1306930677155; Wed, 01 Jun 2011 05:17:57 -0700 (PDT) Received: by 10.52.116.65 with HTTP; Wed, 1 Jun 2011 05:17:57 -0700 (PDT) In-Reply-To: <41F80411E3CC644A844E6BED6E472FD91AEA9730D0@ESESSCMS0363.eemea.ericsson.se> References: <4168915E16BA9E47972F4A4B4EE3228276B786EB3D@GVW1096EXB.americas.hpqcorp.net> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F40@ESESSCMS0356.eemea.ericsson.se> <41F80411E3CC644A844E6BED6E472FD91AEA9730D0@ESESSCMS0363.eemea.ericsson.se> Date: Wed, 1 Jun 2011 08:17:57 -0400 Message-ID: From: Stephen Botzko To: Erlendur Karlsson Content-Type: multipart/alternative; boundary=20cf307cfd82c2087104a4a582b5 Cc: "clue@ietf.org" Subject: Re: [clue] Definitions: left, right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 12:45:04 -0000 --20cf307cfd82c2087104a4a582b5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Good point, it may be consistent. >>> Camera Left/Camera Right: Directions given from the camera's point of view >>> This definition makes sense because there is a view through the lens. It does break down a bit with a 360 degree camera, though from a definition perspective I think that is ok, since we can discuss such cameras using contextually defined terms if we wish. "Camera left" can mean "the "left side in the camera picture", or also "to the left but out of view"; the latter implying an operator standing behind the lens. I see issues trying to extend this definition to audio capture (Directions given from the microphone's point of view???). Microphone elements can be located up front, overhead, on the table, or may be lapel or headset microphones, and all these placements can and are used to generate the same left,center,right audio as defined in RFC 3551. Individual microphones may be monophonic or stereo, and may have any pickup pattern including omnidirectional. Individual microphones simply don't have a natural viewpoint like a camera does. Stephen Botzko On Wed, Jun 1, 2011 at 7:11 AM, Erlendur Karlsson < erlendur.karlsson@ericsson.com> wrote: > With regard to: but "left" is clearly "listener's left", so the sense is > backwards from "capture left" > > A left/righ audio capture is usually rendered in such a way that the > listener hears the left audio captured signal from the left > and the right audio captured signal from the right, so wouldn't > capture-left be in agreement with the listener's left? > > Br, > > Erlendur > > > ------------------------------ > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Stephen Botzko > *Sent:* den 1 juni 2011 12:55 > *To:* Christer Holmberg > *Cc:* clue@ietf.org > > *Subject:* Re: [clue] Definitions: left, right > > Of course for audio, left and right are already used in RFC 3551 (among > others) to describe the channels. The RFC doesn't define it, but "left" = is > clearly "listener's left", so the sense is backwards from "capture left". > The AV and music industry broadly uses left/right in this way. > > Since audio is frequently captured from a microphone array (that can be > gated/steered) it is important that the definitions not make any assumpti= ons > that an audio stream or channel is captured from a single microphone. > Frequently it is not. Also (unlike a camera), a microphone will pick up > some level of sound from the entire room, no matter where it is placed. > > Stephen Botzko > > On Wed, Jun 1, 2011 at 6:34 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> "Camera" only talks about the video part. >> >> We would also need something similar for audio. >> >> OR, we could use a more generic term, covering both audio and video. >> "capture-left", "capture-right" for example. >> >> Regards, >> >> Christer >> >> >> >> >> >> ------------------------------ >> *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Stephan Wenger >> *Sent:* 1. kes=E4kuuta 2011 3:18 >> *To:* Gorzynski, Mark E (The Right One); clue@ietf.org >> *Subject:* Re: [clue] Definitions: left, right >> >> Camera Left seems to be one good choice. Should we go with this for >> now: >> >> "Camera Left, Camera Right: direction from a camera's viewpoint." >> >> "Left, Right": to be interpreted only in context, use Camera Left and >> Camera Right when possible". >> >> Stephan >> >> >> From: "Gorzynski, Mark E (The Right One)" >> Date: Wed, 1 Jun 2011 00:03:11 +0000 >> To: Stephan Wenger , "clue@ietf.org" >> Subject: RE: Definitions: left, right >> >> In television and cinematography, the terms =91camera left=92 and =91c= amera >> right=92 are differentiated carefully from =91stage / house left=92, =91= stage / >> house right=92. >> >> There are many references. For example >> http://www.safilm.com.au/library/SAFC_FILMMAKERS_HANDBOOK.pdf >> >> Camera Left/Camera Right: Directions given from the camera's point of >> view. Opposite of STAGE LEFT and STAGE RIGHT, which are given from the >> actor's point of view. May also be called LEFT FRAME and RIGHT FRAME. >> >> This makes sense if you observe that cameras in studios typically view >> actors from the point of view of the local in-room audience. Thus =91st= age >> left=92 takes the sense of the actors while =91camera left=92 takes the = sense of >> the local audience. >> >> We could use either for our use as long as we are clear. A point to >> notice is that the receiver and sender will many times have an opposite >> sense. Camera left for a receiver will often be stage left for a sender= . >> >> Regards, >> >> Mark G. >> >> *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] >> *On Behalf Of *Stephan Wenger >> *Sent:* Tuesday, May 31, 2011 4:16 PM >> *To:* clue@ietf.org >> *Subject:* [clue] Definitions: left, right >> >> Hi, >> >> We did not come to a conclusion how to define "left" or "right". >> >> -Stage/auditorium/house right left have been shown to be >> confusing,because some of us are not theatre majors :-) >> >> -sender/receiver left/right does not make sense either. Is "sender >> left" viewed from the viewpoint of a person in the sending endpoint room >> (house left), or from the viewpoint of the guy adjusting the camera (whi= ch >> could easily be stage left; at least that was the case in the TeleSuite >> rooms)? Also, we have senders and receivers that are not endpoints, i.e= . >> MCUs. >> >> I like the idea of introducing a numbering convention, but that seems t= o >> be solution space only. >> >> I have no suggestion except perhaps to avoid defining the words, but >> rather remind CLUE authors that they can be confusing, and should only b= e >> used in conjunction with appropriate attributes such as "from sending >> endpoint camera's view". >> >> Speaking as individual, and not as editor, I'm against any definition >> that makes assumptions of "proper rendering". There is no such thing a= s >> proper rendering; rendering is an implementation issue and I can imagine >> many cases where a camera signal that, from a person located in the room >> where it is captured, and facing the screens, would be on the left, shou= ld >> not be rendered on the right in a Remote room. (This tries to describe = the >> natural feel of telepresence with more than one camera/screen). >> >> Opinions? >> >> Stephan >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > --20cf307cfd82c2087104a4a582b5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Good point, it may be consistent.=A0

>>>

Camera Left/Camera Right: Directions gi= ven from the camera's point of view

>>>
This definition makes sense because there is a view through= the lens.=A0 It does break down a bit with a 360 degree camera, though fro= m a definition perspective I think that is ok, since we can discuss such ca= meras using contextually defined terms if we wish.

"Camera left" can mean "the "left side in the camer= a picture", or also "to the left but out of view"; the latte= r implying an operator standing behind the lens.

I see issues trying= to extend this definition to audio capture (Directions given from the microphone's point of view??= ?).=A0 Microphone elements can be located up front, overhead, on the= table, or may be lapel or headset microphones, and all these placements ca= n and are used to generate the same left,center,right audio as defined in R= FC 3551.=A0 Individual microphones may be monophonic or stereo, and may hav= e any pickup pattern including omnidirectional.=A0 Individual microphones s= imply don't have a natural viewpoint like a camera does.

Stephen Botzko

On Wed, Jun 1, 2011 at= 7:11 AM, Erlendur Karlsson <erlendur.karlsson@ericsson.com> wrot= e:
With = regard to: but "left" i= s clearly=20 "listener's left", so the sense is backwards from "captu= re=20 left"
=A0
A=A0l= eft/righ audio capture=A0is usually=A0rendered=A0in such=20 a way that the listener hears the left audio captured signal from the=20 left=A0
and t= he right audio captured signal from the right, so wouldn't=20 capture-left be in agreement with the=A0listener's left?<= /div>
=A0
Br,
=A0
Erlendur=A0
=A0
=A0
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 Behalf Of Stephen Botzko
Sent: den 1 juni 2011 12:55
To= :=20 Christer Holmberg
Cc: clue@ietf.org

Subject:<= /b> Re: [clue]=20 Definitions: left, right

Of course for audio, left and right are already used in RFC 3551= =20 (among others) to describe the channels.=A0 The RFC doesn't define it, = but=20 "left" is clearly "listener's left", so the sense i= s backwards from "capture=20 left". The AV and music industry broadly uses left/right in this=20 way.

Since audio is frequently captured from a microphone array (tha= t can=20 be gated/steered) it is important that the definitions not make any assumpt= ions=20 that an audio stream or channel is captured from a single microphone.=A0=20 Frequently it is not.=A0 Also (unlike a camera), a microphone will pick up= =20 some level of sound from the entire room, no matter where it is=20 placed.

Stephen Botzko

On Wed, Jun 1, 2011 at 6:34 AM, Christer Holmber= g <christer.holmberg@ericsson.com>=20 wrote:
Hi,<= /div>
=A0<= /div>
"Camera"= only talks about the video=20 part.
=A0<= /div>
We would also need= something=20 similar for audio.
=A0<= /div>
OR, we could use a= more generic=20 term, covering both audio and video. "capture-left", "capt= ure-right" for=20 example.
=A0<= /div>
Regards,
=A0<= /div>
Christer
=A0
=A0
=A0
=A0

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org]=20 On Behalf Of Stephan Wenger
Sent: 1. kes=E4kuuta= 2011=20 3:18
To: Gorzynski, Mark E (The Right One); clue@ietf.org
Subject: Re: = [clue] Definitions:=20 left, right

Camera Left seems to be one good choice. =A0Should we go with this= =20 for now:

"Camera Left, Camera Right: direction from a camera's vie= wpoint."

"Left, Right": to be interpreted only in context, use Ca= mera Left and=20 Camera Right when possible".

Stephan
=A0

From: "Gorzynski, Mark E (The = Right One)"=20 <mark.gor= zynski@hp.com>
Date: Wed,= 1 Jun 2011 00:03:11=20 +0000
To: Stephan Wenger <= ;stewe@stewe.org&g= t;, "clue@ietf.org<= /a>" <clue@ietf.= org>
Subject: RE: Definitions: left,=20 right

In=20 television and cinematography, the terms =91camera left=92 and =91camer= a right=92=20 are differentiated carefully from =91stage / house left=92, =91stage / = house=20 right=92.

There=20 are many references.=A0 For example http://www.safilm.= com.au/library/SAFC_FILMMAKERS_HANDBOOK.pdf

Camera=20 Left/Camera Right: Directions given from the camera's point of view= .=20 Opposite of STAGE LEFT and STAGE RIGHT, which are given from the actor&= #39;s=20 point of view. May also be called LEFT FRAME and RIGHT FRAME.

This=20 makes sense if you observe that cameras in studios typically view actor= s=20 from the point of view of the local in-room audience.=A0 Thus =91stage= =20 left=92 takes the sense of the actors while =91camera left=92 takes the= sense of=20 the local audience.

We=20 could use either for our use as long as we are clear.=A0 A point to=20 notice is that the receiver and sender will many times have an opposite= =20 sense.=A0 Camera left for a receiver will often be stage left for a=20 sender.

Regards,

Mark=20 G.

From: clue-bounces@ietf.org=20 [mailto:clue= -bounces@ietf.org] On Behalf Of Stephan=20 Wenger
Sent: Tuesday, May 31, 2011 4:16 PM
To: clue@ietf.org
Subj= ect: [clue] Definitions: left,=20 right

Hi,

We=20 did not come to a conclusion how to define "left" or=20 "right".

-Stage/auditorium/house=20 right left have been shown to be confusing,because some of us are not= =20 theatre majors :-)

-sender/receiver=20 left/right does not make sense either. =A0Is "sender left" vi= ewed from=20 the viewpoint of a person in the sending endpoint room (house left), or= from=20 the viewpoint of the guy adjusting the camera (which could easily be st= age=20 left; at least that was the case in the TeleSuite rooms)? =A0Also, we= =20 have senders and receivers that are not endpoints, i.e.=20 MCUs.

I=20 like the idea of introducing a numbering convention, but that seems to = be=20 solution space only.

I=20 have no suggestion except perhaps to avoid defining the words, but rath= er=20 remind CLUE authors that they can be confusing, and should only be used= in=20 conjunction with appropriate attributes such as "from sending endp= oint=20 camera's view".

Speaking=20 as individual, and not as editor, I'm against any definition that m= akes=20 assumptions of =A0"proper rendering". =A0There is no such thi= ng as=20 proper rendering; rendering is an implementation issue and I can imagin= e=20 many cases where a camera signal that, from a person located in the roo= m=20 where it is captured, and facing the screens, would be on the left, sho= uld=20 not be rendered on the right in a Remote room. =A0(This tries to descri= be=20 the natural feel of telepresence with more than one=20 camera/screen).

Opinions?

Stephan


____________________________________________= ___
clue=20 mailing list
clue@i= etf.org
https://www.ietf.org/mailman/listinfo/clue



--20cf307cfd82c2087104a4a582b5-- From hmmr@cisco.com Wed Jun 1 06:03:39 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11035E087A for ; Wed, 1 Jun 2011 06:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.805 X-Spam-Level: X-Spam-Status: No, score=-9.805 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6inw2yd+xoCP for ; Wed, 1 Jun 2011 06:03:38 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 43CE0E11BD for ; Wed, 1 Jun 2011 05:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=3506; q=dns/txt; s=iport; t=1306932924; x=1308142524; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=CC4rplmAZ97f4NSyhe3iMK0R7diih+gJoEbOY8HqNAo=; b=jpHb/M4Gwxu/+MeGT8wCiik8BIKK1fiOdV+2ORajDGwT8/G3ihGHCKIG B6tURQyOib/JaY260X0HNf2N92TBrZImjBvUHeBSg0SiY5eVudx1U0Lcu mPMjkqlrRwwtNScPrU9jNxO7M2kFAmqyXxO7b2Jsm/aApu+JGLFeKvOM3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBAJ415k2tJXG+/2dsb2JhbABTl1COVHepX51PhiAEhmWOPIp9 X-IronPort-AV: E=Sophos;i="4.65,303,1304294400"; d="scan'208";a="368086594" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2011 12:55:23 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p51CtNP2026874; Wed, 1 Jun 2011 12:55:23 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 07:55:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jun 2011 07:55:22 -0500 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Definitions: Participant Thread-Index: Acwf7XoJs2kDmon4QJecxn4JCAjuAgAXHslwAARDaIA= References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> From: "Mike Hammer (hmmr)" To: "Christer Holmberg" , "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 01 Jun 2011 12:55:23.0329 (UTC) FILETIME=[2BA5A310:01CC205B] Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:03:39 -0000 Option 4: don't use participant at all, since it is ambiguous. If you mean to talk about a human, then simply say Human. Hopefully, that term is unambiguous. Mike -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Christer Holmberg Sent: Wednesday, June 01, 2011 6:56 AM To: Paul Kyzivat (pkyzivat); clue@ietf.org Subject: Re: [clue] Definitions: Participant Hi, In my ears, "particiapant" has always been associated with a human. Also, my understanding is that ITU-T defines participant as a human = participating in a conference, and I strongly think we should avoid = identical wording with different meaning - it will only cause problems = sooner or later. Why can't we simply talk about "endpoint" or "client" when talking about = the SIP device (whether it's a full blown telepresence room or a small = mobile phone)? That's wording that people are used to, so I don't see = why we need to come up with something new... Regards, Christer =20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 1. kes=E4kuuta 2011 2:50 > To: clue@ietf.org > Subject: Re: [clue] Definitions: Participant >=20 > I support using Participant in the 4353 sense. > (Its really the only definition that most of the software can=20 > use in a useful way. E.g. the conference roster is about=20 > these automata. This becomes especially obvious when you have=20 > the same "person" showing up multiple times in the roster.) >=20 > If there is need to talk about the human(s) associated with a=20 > participant, then it would make sense to define another term for that. >=20 > Thanks, > Paul (as individual) >=20 > On 5/31/2011 7:03 PM, Stephan Wenger wrote: > > Hi all, > > I thought I would quickly rev the definitions doc, and=20 > found out that=20 > > I cannot find agreements on a number of terms. This is the=20 > first of a=20 > > set of eamils that will hopefully lead us to close the=20 > definitions on=20 > > a few terms. > > So this email is about "Participant". > > > > We have the odd definition that RFC 4353 lists participant=20 > essentially=20 > > as a piece of software and not as a human. To Song Haibin, Steve=20 > > Botzko (and to me), Participants sounds like human, though. > > > > Several ways forward: > > > > 1. Use Participant in the 4353 sense only > > 2. Use Participant in the sense of a human participating in a > > telepresence session only. That would mean that there=20 > can be many > > participants at any endpoint, and endpoint can have=20 > no participant > > (empty room or webcam), and so forth. > > 3. Use Participant in the sense of 2) above, and add=20 > remark that if > > 4353 Participant is meant, this will be explicitely mentioned. > > > > My preference is 1. 2 and 3 have too much potential for confusion.=20 > > Shame on 4353 for that. > > > > Opinions? > > > > Stephan > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@cisco.com Wed Jun 1 06:04:17 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F594E07F2 for ; Wed, 1 Jun 2011 06:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.375 X-Spam-Level: X-Spam-Status: No, score=-110.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZW9bjPKNp5T for ; Wed, 1 Jun 2011 06:04:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 06176E08ED for ; Wed, 1 Jun 2011 06:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4046; q=dns/txt; s=iport; t=1306933206; x=1308142806; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=u/V5+eFeFOiyIaYUDP9kF0loK5pJ6bhoyK+JVo7WJ4o=; b=WN8+Y7OkUqeivCxQaBwgFQY264e8vq4XtLVr6xRMQqUO+UaWbkTF2riz SfbjctuaCygnhWBd+NAI6XQPg3mG1KWC4wlwlDVMQAkzr2xgVDsl7BGYq G5wiNWoD0x9RR8mGwvHgzUIDm5m2uEnQMAPtDGbH4jW/XAsAsnokaDhX1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBAMo25k2rRDoI/2dsb2JhbABTl1COVHepb51OhiAEkFWEQ4sE X-IronPort-AV: E=Sophos;i="4.65,303,1304294400"; d="scan'208";a="327763483" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2011 13:00:05 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p51D05nG008929 for ; Wed, 1 Jun 2011 13:00:05 GMT Message-ID: <4DE637D4.6080404@cisco.com> Date: Wed, 01 Jun 2011 09:00:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Definitions: left, right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:04:17 -0000 On 5/31/2011 8:17 PM, Stephan Wenger wrote: > Camera Left seems to be one good choice. Should we go with this for now: > > "Camera Left, Camera Right: direction from a camera's viewpoint." This has the advantage of solving my question about theater in the round. Presumably no one camera has the full 360 degree view, and so each has a notion of left and right. (There *are* cameras that take 360 degree views, but maybe we can count on them not being used for telepresence.) This of course does mean that "camera left" may have a different meaning for each camera. That's fine, but something to keep in mind when using it. Thanks, Paul > "Left, Right": to be interpreted only in context, use Camera Left and > Camera Right when possible". > > Stephan > > From: "Gorzynski, Mark E (The Right One)" > > Date: Wed, 1 Jun 2011 00:03:11 +0000 > To: Stephan Wenger >, > "clue@ietf.org " > > Subject: RE: Definitions: left, right > > In television and cinematography, the terms ‘camera left’ and ‘camera > right’ are differentiated carefully from ‘stage / house left’, ‘stage / > house right’. > > There are many references. For example > http://www.safilm.com.au/library/SAFC_FILMMAKERS_HANDBOOK.pdf > > Camera Left/Camera Right: Directions given from the camera's point of > view. Opposite of STAGE LEFT and STAGE RIGHT, which are given from the > actor's point of view. May also be called LEFT FRAME and RIGHT FRAME. > > This makes sense if you observe that cameras in studios typically view > actors from the point of view of the local in-room audience. Thus ‘stage > left’ takes the sense of the actors while ‘camera left’ takes the sense > of the local audience. > > We could use either for our use as long as we are clear. A point to > notice is that the receiver and sender will many times have an opposite > sense. Camera left for a receiver will often be stage left for a sender. > > Regards, > > Mark G. > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephan Wenger > *Sent:* Tuesday, May 31, 2011 4:16 PM > *To:* clue@ietf.org > *Subject:* [clue] Definitions: left, right > > Hi, > > We did not come to a conclusion how to define "left" or "right". > > -Stage/auditorium/house right left have been shown to be > confusing,because some of us are not theatre majors :-) > > -sender/receiver left/right does not make sense either. Is "sender left" > viewed from the viewpoint of a person in the sending endpoint room > (house left), or from the viewpoint of the guy adjusting the camera > (which could easily be stage left; at least that was the case in the > TeleSuite rooms)? Also, we have senders and receivers that are not > endpoints, i.e. MCUs. > > I like the idea of introducing a numbering convention, but that seems to > be solution space only. > > I have no suggestion except perhaps to avoid defining the words, but > rather remind CLUE authors that they can be confusing, and should only > be used in conjunction with appropriate attributes such as "from sending > endpoint camera's view". > > Speaking as individual, and not as editor, I'm against any definition > that makes assumptions of "proper rendering". There is no such thing as > proper rendering; rendering is an implementation issue and I can imagine > many cases where a camera signal that, from a person located in the room > where it is captured, and facing the screens, would be on the left, > should not be rendered on the right in a Remote room. (This tries to > describe the natural feel of telepresence with more than one camera/screen). > > Opinions? > > Stephan > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From hmmr@cisco.com Wed Jun 1 06:04:45 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A15AE0900 for ; Wed, 1 Jun 2011 06:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.893 X-Spam-Level: X-Spam-Status: No, score=-9.893 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2WWT8dBj68D for ; Wed, 1 Jun 2011 06:04:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4C325E06D6 for ; Wed, 1 Jun 2011 06:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=27918; q=dns/txt; s=iport; t=1306933296; x=1308142896; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=GT9G3PkhH3C5Y9T7pqOBtav29zjI1BwJ/GzWYnGGOp8=; b=ArXF+6AslLLYxo9yG5joprkWWar3W+bXlzM9KJcUpSFU3EFTqU04/DuQ o5SkhhMP2KqQcrwxfYCBIFW4FXmQ/ULGgkiZYtSJzF5mDerS4Be/6l5VM 5IIKv6EmeuPFdXgXQDDLus3c8JhB9wzwbZ+j0Cp9VOdgcvIMMQMFFa+iM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBAKs35k2tJV2b/2dsb2JhbABTglKUfo5Ud6lcnU6GIASCN4QujjyKfQ X-IronPort-AV: E=Sophos;i="4.65,303,1304294400"; d="scan'208,217";a="457748533" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-1.cisco.com with ESMTP; 01 Jun 2011 13:01:35 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p51D1Z18005123; Wed, 1 Jun 2011 13:01:35 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 08:01:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC205C.08F9687A" Date: Wed, 1 Jun 2011 08:01:34 -0500 Message-ID: In-Reply-To: <41F80411E3CC644A844E6BED6E472FD91AEA9730D0@ESESSCMS0363.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Definitions: left, right Thread-Index: AcwgSl6X3c9xzAkzTOSYmmNgcoajGQAAKXzgAAQk3QA= References: <4168915E16BA9E47972F4A4B4EE3228276B786EB3D@GVW1096EXB.americas.hpqcorp.net><7F2072F1E0DE894DA4B517B93C6A0585194E2E4F40@ESESSCMS0356.eemea.ericsson.se> <41F80411E3CC644A844E6BED6E472FD91AEA9730D0@ESESSCMS0363.eemea.ericsson.se> From: "Mike Hammer (hmmr)" To: "Erlendur Karlsson" , "Stephen Botzko" , "Christer Holmberg" X-OriginalArrivalTime: 01 Jun 2011 13:01:34.0948 (UTC) FILETIME=[09263240:01CC205C] Cc: clue@ietf.org Subject: Re: [clue] Definitions: left, right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:04:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC205C.08F9687A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would be careful of using camera to represent the viewer, since the = camera is on the sender side in these cases. =20 Sender: camera left, camera right, microphone left, microphone right =20 Rendering: screen (viewer) left, screen right, speaker left, speaker = right =20 Mike =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Erlendur Karlsson Sent: Wednesday, June 01, 2011 7:11 AM To: Stephen Botzko; Christer Holmberg Cc: clue@ietf.org Subject: Re: [clue] Definitions: left, right =20 With regard to: but "left" is clearly "listener's left", so the sense is = backwards from "capture left" =20 A left/righ audio capture is usually rendered in such a way that the = listener hears the left audio captured signal from the left=20 and the right audio captured signal from the right, so wouldn't = capture-left be in agreement with the listener's left? =20 Br, =20 Erlendur=20 =20 =20 ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko Sent: den 1 juni 2011 12:55 To: Christer Holmberg Cc: clue@ietf.org Subject: Re: [clue] Definitions: left, right Of course for audio, left and right are already used in RFC 3551 (among = others) to describe the channels. The RFC doesn't define it, but "left" = is clearly "listener's left", so the sense is backwards from "capture = left". The AV and music industry broadly uses left/right in this way. Since audio is frequently captured from a microphone array (that can be = gated/steered) it is important that the definitions not make any = assumptions that an audio stream or channel is captured from a single = microphone. Frequently it is not. Also (unlike a camera), a microphone = will pick up some level of sound from the entire room, no matter where = it is placed. Stephen Botzko On Wed, Jun 1, 2011 at 6:34 AM, Christer Holmberg = wrote: Hi, =20 "Camera" only talks about the video part. =20 We would also need something similar for audio. =20 OR, we could use a more generic term, covering both audio and video. = "capture-left", "capture-right" for example. =20 Regards, =20 Christer =20 =20 =20 =20 =20 =09 ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephan Wenger Sent: 1. kes=E4kuuta 2011 3:18 To: Gorzynski, Mark E (The Right One); clue@ietf.org Subject: Re: [clue] Definitions: left, right Camera Left seems to be one good choice. Should we go with this for = now: =20 "Camera Left, Camera Right: direction from a camera's viewpoint." =20 "Left, Right": to be interpreted only in context, use Camera Left and = Camera Right when possible". =20 Stephan =20 =20 From: "Gorzynski, Mark E (The Right One)" Date: Wed, 1 Jun 2011 00:03:11 +0000 To: Stephan Wenger , "clue@ietf.org" Subject: RE: Definitions: left, right =20 In television and cinematography, the terms 'camera left' and 'camera = right' are differentiated carefully from 'stage / house left', 'stage / = house right'. There are many references. For example = http://www.safilm.com.au/library/SAFC_FILMMAKERS_HANDBOOK.pdf Camera Left/Camera Right: Directions given from the camera's point of = view. Opposite of STAGE LEFT and STAGE RIGHT, which are given from the = actor's point of view. May also be called LEFT FRAME and RIGHT FRAME. This makes sense if you observe that cameras in studios typically view = actors from the point of view of the local in-room audience. Thus = 'stage left' takes the sense of the actors while 'camera left' takes the = sense of the local audience. We could use either for our use as long as we are clear. A point to = notice is that the receiver and sender will many times have an opposite = sense. Camera left for a receiver will often be stage left for a = sender.=20 Regards, Mark G.=20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephan Wenger Sent: Tuesday, May 31, 2011 4:16 PM To: clue@ietf.org Subject: [clue] Definitions: left, right Hi, We did not come to a conclusion how to define "left" or "right". -Stage/auditorium/house right left have been shown to be = confusing,because some of us are not theatre majors :-) -sender/receiver left/right does not make sense either. Is "sender = left" viewed from the viewpoint of a person in the sending endpoint room = (house left), or from the viewpoint of the guy adjusting the camera = (which could easily be stage left; at least that was the case in the = TeleSuite rooms)? Also, we have senders and receivers that are not = endpoints, i.e. MCUs. I like the idea of introducing a numbering convention, but that seems = to be solution space only. I have no suggestion except perhaps to avoid defining the words, but = rather remind CLUE authors that they can be confusing, and should only = be used in conjunction with appropriate attributes such as "from sending = endpoint camera's view". Speaking as individual, and not as editor, I'm against any definition = that makes assumptions of "proper rendering". There is no such thing = as proper rendering; rendering is an implementation issue and I can = imagine many cases where a camera signal that, from a person located in = the room where it is captured, and facing the screens, would be on the = left, should not be rendered on the right in a Remote room. (This tries = to describe the natural feel of telepresence with more than one = camera/screen). Opinions? Stephan _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CC205C.08F9687A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I would be careful of using = camera to represent the viewer, since the camera is on the sender side = in these cases.

 

Sender:=A0 camera left, camera = right, microphone left, microphone right

 

Rendering:=A0 screen (viewer) = left, screen right, speaker left, speaker right

 

Mike

=A0 =

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Erlendur Karlsson
Sent: Wednesday, June 01, 2011 7:11 = AM
To: Stephen Botzko; Christer Holmberg
Cc: = clue@ietf.org
Subject: Re: [clue] Definitions: left, = right

 

With regard = to: but "left" is clearly "listener's left", = so the sense is backwards from "capture left"

 

A left/r= igh audio capture is usually rendered in such a way that = the listener hears the left audio captured signal from the = left 

and the = right audio captured signal from the right, so wouldn't capture-left be = in agreement with the listener's left?

 

Br,

 

Erlendur 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko
Sent: den 1 juni 2011 12:55
To: = Christer Holmberg
Cc: clue@ietf.org
Subject: Re: = [clue] Definitions: left, right

Of course for audio, = left and right are already used in RFC 3551 (among others) to describe = the channels.  The RFC doesn't define it, but "left" is = clearly "listener's left", so the sense is backwards from = "capture left". The AV and music industry broadly uses = left/right in this way.

Since audio is frequently captured from a = microphone array (that can be gated/steered) it is important that the = definitions not make any assumptions that an audio stream or channel is = captured from a single microphone.  Frequently it is not.  = Also (unlike a camera), a microphone will pick up some level of sound = from the entire room, no matter where it is placed.

Stephen = Botzko

On Wed, Jun 1, 2011 at = 6:34 AM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:

Hi,

 

"Camera" only talks about the video part.

 

We would also need something similar for audio.

 

OR, we could use a more generic term, covering both audio and video. = "capture-left", "capture-right" for = example.

 

Regards,

 

Christer

 

 

 

 

 

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan = Wenger

= Sent:= 1. kes=E4kuuta 2011 3:18
To: Gorzynski, Mark E (The Right = One); clue@ietf.org
Subject: Re: [clue] = Definitions: left, right

Camera Left seems to be one good choice.  Should we go with this = for now:

 

"Camera Left, Camera Right: direction from a camera's = viewpoint."

 

"Left, Right": to be interpreted only in context, use Camera = Left and Camera Right when = possible".

 

Stephan

 

 

From: "Gorzynski, Mark E (The Right One)" <mark.gorzynski@hp.com>
Date: Wed, 1 = Jun 2011 00:03:11 +0000
To: Stephan Wenger <stewe@stewe.org>, "clue@ietf.org" = <clue@ietf.org>
Subject: RE: = Definitions: left, right

 

In television and cinematography, the terms ‘camera left’ = and ‘camera right’ are differentiated carefully from = ‘stage / house left’, ‘stage / house = right’.

There are many references.  For example http://www.safilm.com.au/library/SAFC_FILMMAKERS_HANDBO= OK.pdf

Camera Left/Camera Right: Directions given from the camera's point of = view. Opposite of STAGE LEFT and STAGE RIGHT, which are given from the = actor's point of view. May also be called LEFT FRAME and RIGHT = FRAME.

This makes sense if you observe that cameras in studios typically = view actors from the point of view of the local in-room audience.  = Thus ‘stage left’ takes the sense of the actors while = ‘camera left’ takes the sense of the local = audience.

We could use either for our use as long as we are clear.  A = point to notice is that the receiver and sender will many times have an = opposite sense.  Camera left for a receiver will often be stage = left for a sender.

Regards,

Mark G.

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephan Wenger
Sent: Tuesday, May 31, 2011 4:16 = PM
To: clue@ietf.org
Subject: [clue] = Definitions: left, right

Hi,

We did not come to a conclusion how to define "left" or = "right".

-Stage/auditorium/house right left have been shown to be = confusing,because some of us are not theatre majors :-)

-sender/receiver left/right does not make sense either.  Is = "sender left" viewed from the viewpoint of a person in the = sending endpoint room (house left), or from the viewpoint of the guy = adjusting the camera (which could easily be stage left; at least that = was the case in the TeleSuite rooms)?  Also, we have senders and = receivers that are not endpoints, i.e. MCUs.

I like the idea of introducing a numbering convention, but that seems = to be solution space only.

I have no suggestion except perhaps to avoid defining the words, but = rather remind CLUE authors that they can be confusing, and should only = be used in conjunction with appropriate attributes such as "from = sending endpoint camera's view".

Speaking as individual, and not as editor, I'm against any definition = that makes assumptions of  "proper rendering". =  There is no such thing as proper rendering; rendering is an = implementation issue and I can imagine many cases where a camera signal = that, from a person located in the room where it is captured, and facing = the screens, would be on the left, should not be rendered on the right = in a Remote room.  (This tries to describe the natural feel of = telepresence with more than one camera/screen).

Opinions?

Stephan


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

 

------_=_NextPart_001_01CC205C.08F9687A-- From Even.roni@huawei.com Wed Jun 1 06:17:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3335AE06D4 for ; Wed, 1 Jun 2011 06:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.298 X-Spam-Level: X-Spam-Status: No, score=-105.298 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7k7rt3uwiDj for ; Wed, 1 Jun 2011 06:17:51 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id E61C8E06D6 for ; Wed, 1 Jun 2011 06:17:28 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM4002AB4X360@szxga04-in.huawei.com> for clue@ietf.org; Wed, 01 Jun 2011 21:17:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM400N184X34X@szxga04-in.huawei.com> for clue@ietf.org; Wed, 01 Jun 2011 21:17:27 +0800 (CST) Received: from YOUR6108 (bzq-79-180-46-28.red.bezeqint.net [79.180.46.28]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LM4003534WS3K@szxml11-in.huawei.com>; Wed, 01 Jun 2011 21:17:27 +0800 (CST) Date: Wed, 01 Jun 2011 16:17:13 +0300 From: Roni Even In-reply-to: To: 'Stephen Botzko' , 'Erlendur Karlsson' Message-id: <005401cc205e$3e8c79b0$bba56d10$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_RrPxJYPTPDvRurFr4FLfhQ)" Content-language: he Thread-index: AcwgXJ7JkMsR6yRWSR+KbSUUkOQNKwAAXnnw References: <4168915E16BA9E47972F4A4B4EE3228276B786EB3D@GVW1096EXB.americas.hpqcorp.net> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F40@ESESSCMS0356.eemea.ericsson.se> <41F80411E3CC644A844E6BED6E472FD91AEA9730D0@ESESSCMS0363.eemea.ericsson.se> Cc: clue@ietf.org Subject: Re: [clue] Definitions: left, right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:17:56 -0000 This is a multi-part message in MIME format. --Boundary_(ID_RrPxJYPTPDvRurFr4FLfhQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi, So how do we describe the room that has three screens from left to = right. What is left here Roni =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, June 01, 2011 3:18 PM To: Erlendur Karlsson Cc: clue@ietf.org Subject: Re: [clue] Definitions: left, right =20 Good point, it may be consistent. =20 >>> Camera Left/Camera Right: Directions given from the camera's point of = view >>> This definition makes sense because there is a view through the lens. = It does break down a bit with a 360 degree camera, though from a definition perspective I think that is ok, since we can discuss such cameras using contextually defined terms if we wish. "Camera left" can mean "the "left side in the camera picture", or also = "to the left but out of view"; the latter implying an operator standing = behind the lens. I see issues trying to extend this definition to audio capture = (Directions given from the microphone's point of view???). Microphone elements can = be located up front, overhead, on the table, or may be lapel or headset microphones, and all these placements can and are used to generate the = same left,center,right audio as defined in RFC 3551. Individual microphones = may be monophonic or stereo, and may have any pickup pattern including omnidirectional. Individual microphones simply don't have a natural viewpoint like a camera does. Stephen Botzko On Wed, Jun 1, 2011 at 7:11 AM, Erlendur Karlsson wrote: With regard to: but "left" is clearly "listener's left", so the sense is backwards from "capture left" =20 A left/righ audio capture is usually rendered in such a way that the listener hears the left audio captured signal from the left=20 and the right audio captured signal from the right, so wouldn't = capture-left be in agreement with the listener's left? =20 Br, =20 Erlendur=20 =20 =20 _____ =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: den 1 juni 2011 12:55 To: Christer Holmberg Cc: clue@ietf.org Subject: Re: [clue] Definitions: left, right =20 Of course for audio, left and right are already used in RFC 3551 (among others) to describe the channels. The RFC doesn't define it, but "left" = is clearly "listener's left", so the sense is backwards from "capture = left". The AV and music industry broadly uses left/right in this way. Since audio is frequently captured from a microphone array (that can be gated/steered) it is important that the definitions not make any = assumptions that an audio stream or channel is captured from a single microphone. Frequently it is not. Also (unlike a camera), a microphone will pick up some level of sound from the entire room, no matter where it is placed. Stephen Botzko On Wed, Jun 1, 2011 at 6:34 AM, Christer Holmberg wrote: Hi, =20 "Camera" only talks about the video part. =20 We would also need something similar for audio. =20 OR, we could use a more generic term, covering both audio and video. "capture-left", "capture-right" for example. =20 Regards, =20 Christer =20 =20 =20 =20 =20 _____ =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: 1. kes=E4kuuta 2011 3:18 To: Gorzynski, Mark E (The Right One); clue@ietf.org Subject: Re: [clue] Definitions: left, right Camera Left seems to be one good choice. Should we go with this for = now: =20 "Camera Left, Camera Right: direction from a camera's viewpoint." =20 "Left, Right": to be interpreted only in context, use Camera Left and = Camera Right when possible". =20 Stephan =20 =20 From: "Gorzynski, Mark E (The Right One)" Date: Wed, 1 Jun 2011 00:03:11 +0000 To: Stephan Wenger , "clue@ietf.org" Subject: RE: Definitions: left, right =20 In television and cinematography, the terms =91camera left=92 and = =91camera right=92 are differentiated carefully from =91stage / house left=92, =91stage / = house right=92. There are many references. For example http://www.safilm.com.au/library/SAFC_FILMMAKERS_HANDBOOK.pdf Camera Left/Camera Right: Directions given from the camera's point of = view. Opposite of STAGE LEFT and STAGE RIGHT, which are given from the actor's point of view. May also be called LEFT FRAME and RIGHT FRAME. This makes sense if you observe that cameras in studios typically view actors from the point of view of the local in-room audience. Thus = =91stage left=92 takes the sense of the actors while =91camera left=92 takes the = sense of the local audience. We could use either for our use as long as we are clear. A point to = notice is that the receiver and sender will many times have an opposite sense. Camera left for a receiver will often be stage left for a sender.=20 Regards, Mark G.=20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Tuesday, May 31, 2011 4:16 PM To: clue@ietf.org Subject: [clue] Definitions: left, right Hi, We did not come to a conclusion how to define "left" or "right". -Stage/auditorium/house right left have been shown to be = confusing,because some of us are not theatre majors :-) -sender/receiver left/right does not make sense either. Is "sender = left" viewed from the viewpoint of a person in the sending endpoint room = (house left), or from the viewpoint of the guy adjusting the camera (which = could easily be stage left; at least that was the case in the TeleSuite = rooms)? Also, we have senders and receivers that are not endpoints, i.e. MCUs. I like the idea of introducing a numbering convention, but that seems to = be solution space only. I have no suggestion except perhaps to avoid defining the words, but = rather remind CLUE authors that they can be confusing, and should only be used = in conjunction with appropriate attributes such as "from sending endpoint camera's view". Speaking as individual, and not as editor, I'm against any definition = that makes assumptions of "proper rendering". There is no such thing as = proper rendering; rendering is an implementation issue and I can imagine many = cases where a camera signal that, from a person located in the room where it = is captured, and facing the screens, would be on the left, should not be rendered on the right in a Remote room. (This tries to describe the = natural feel of telepresence with more than one camera/screen). Opinions? Stephan _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 =20 =20 __________ Information from ESET NOD32 Antivirus, version of virus = signature database 6170 (20110601) __________ =20 The message was checked by ESET NOD32 Antivirus. =20 http://www.eset.com --Boundary_(ID_RrPxJYPTPDvRurFr4FLfhQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi,

So how do we describe the room that has three screens from left to = right. What is left here

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko
Sent: Wednesday, June 01, 2011 3:18 = PM
To: Erlendur Karlsson
Cc: = clue@ietf.org
Subject: Re: [clue] Definitions: left, = right

 

Good point, = it may be consistent. 

>>>

Camera Left/Camera Right: = Directions given from the camera's point of view

>>>
This = definition makes sense because there is a view through the lens.  = It does break down a bit with a 360 degree camera, though from a = definition perspective I think that is ok, since we can discuss such = cameras using contextually defined terms if we wish.

"Camera = left" can mean "the "left side in the camera = picture", or also "to the left but out of view"; the = latter implying an operator standing behind the lens.

I see = issues trying to extend this definition to audio capture (Directions given from the = microphone's point of view???).  Microphone elements can be = located up front, overhead, on the table, or may be lapel or headset = microphones, and all these placements can and are used to generate the = same left,center,right audio as defined in RFC 3551.  Individual = microphones may be monophonic or stereo, and may have any pickup pattern = including omnidirectional.  Individual microphones simply don't = have a natural viewpoint like a camera does.

Stephen = Botzko

On Wed, Jun 1, 2011 at = 7:11 AM, Erlendur Karlsson <erlendur.karlsson@ericsson= .com> wrote:

With regard = to: but "left" is clearly "listener's left", = so the sense is backwards from "capture left"

 

A left/r= igh audio capture is usually rendered in such a way that = the listener hears the left audio captured signal from the = left 

and the = right audio captured signal from the right, so wouldn't capture-left be = in agreement with the listener's left?

 

Br,

 

Erlendur 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen = Botzko
Sent: den 1 juni 2011 12:55
To: Christer = Holmberg
Cc: clue@ietf.org


Subje= ct: Re: [clue] Definitions: left, = right

 

Of course for audio, left and right are = already used in RFC 3551 (among others) to describe the channels.  = The RFC doesn't define it, but "left" is clearly = "listener's left", so the sense is backwards from = "capture left". The AV and music industry broadly uses = left/right in this way.

Since audio is frequently captured from a = microphone array (that can be gated/steered) it is important that the = definitions not make any assumptions that an audio stream or channel is = captured from a single microphone.  Frequently it is not.  = Also (unlike a camera), a microphone will pick up some level of sound = from the entire room, no matter where it is placed.

Stephen = Botzko

On Wed, Jun 1, 2011 at = 6:34 AM, Christer Holmberg <christer.holmberg@ericsson.com> = wrote:

Hi,

 

"Camera" only talks about the video part.

 

We would also need something similar for audio.

 

OR, we could use a more generic term, covering both audio and video. = "capture-left", "capture-right" for = example.

 

Regards,

 

Christer

 

 

 

 

 

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan = Wenger

= Sent:= 1. kes=E4kuuta 2011 3:18
To: Gorzynski, Mark E (The Right = One); clue@ietf.org
Subject: Re: [clue] = Definitions: left, right

Camera Left seems to be one good choice.  Should we go with this = for now:

 

"Camera Left, Camera Right: direction from a camera's = viewpoint."

 

"Left, Right": to be interpreted only in context, use Camera = Left and Camera Right when = possible".

 

Stephan

 

 

From: "Gorzynski, Mark E (The Right One)" <mark.gorzynski@hp.com>
Date: Wed, 1 = Jun 2011 00:03:11 +0000
To: Stephan Wenger <stewe@stewe.org>, "clue@ietf.org" = <clue@ietf.org>
Subject: RE: = Definitions: left, right

 

In television and cinematography, the terms ‘camera left’ = and ‘camera right’ are differentiated carefully from = ‘stage / house left’, ‘stage / house = right’.

There are many references.  For example http://www.safilm.com.au/library/SAFC_FILMMAKERS_HANDBO= OK.pdf

Camera Left/Camera Right: Directions given from the camera's point of = view. Opposite of STAGE LEFT and STAGE RIGHT, which are given from the = actor's point of view. May also be called LEFT FRAME and RIGHT = FRAME.

This makes sense if you observe that cameras in studios typically = view actors from the point of view of the local in-room audience.  = Thus ‘stage left’ takes the sense of the actors while = ‘camera left’ takes the sense of the local = audience.

We could use either for our use as long as we are clear.  A = point to notice is that the receiver and sender will many times have an = opposite sense.  Camera left for a receiver will often be stage = left for a sender.

Regards,

Mark G.

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephan Wenger
Sent: Tuesday, May 31, 2011 4:16 = PM
To: clue@ietf.org
Subject: [clue] = Definitions: left, right

Hi,

We did not come to a conclusion how to define "left" or = "right".

-Stage/auditorium/house right left have been shown to be = confusing,because some of us are not theatre majors :-)

-sender/receiver left/right does not make sense either.  Is = "sender left" viewed from the viewpoint of a person in the = sending endpoint room (house left), or from the viewpoint of the guy = adjusting the camera (which could easily be stage left; at least that = was the case in the TeleSuite rooms)?  Also, we have senders and = receivers that are not endpoints, i.e. MCUs.

I like the idea of introducing a numbering convention, but that seems = to be solution space only.

I have no suggestion except perhaps to avoid defining the words, but = rather remind CLUE authors that they can be confusing, and should only = be used in conjunction with appropriate attributes such as "from = sending endpoint camera's view".

Speaking as individual, and not as editor, I'm against any definition = that makes assumptions of  "proper rendering". =  There is no such thing as proper rendering; rendering is an = implementation issue and I can imagine many cases where a camera signal = that, from a person located in the room where it is captured, and facing = the screens, would be on the left, should not be rendered on the right = in a Remote room.  (This tries to describe the natural feel of = telepresence with more than one camera/screen).

Opinions?

Stephan


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

 

 

 

__________ Information from = ESET NOD32 Antivirus, version of virus signature database 6170 = (20110601) __________

 

The message was checked by = ESET NOD32 Antivirus.

 

http://www.eset.com<= /p>



__________ Information from ESET NOD32 = Antivirus, version of virus signature database 6170 (20110601) = __________

The message was checked by ESET NOD32 = Antivirus.

http://www.eset.com
= --Boundary_(ID_RrPxJYPTPDvRurFr4FLfhQ)-- From stephen.botzko@gmail.com Wed Jun 1 07:13:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D77DE06FC for ; Wed, 1 Jun 2011 07:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcbbV7FtYKdq for ; Wed, 1 Jun 2011 07:13:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF84E07C3 for ; Wed, 1 Jun 2011 07:12:41 -0700 (PDT) Received: by vws12 with SMTP id 12so5711061vws.31 for ; Wed, 01 Jun 2011 07:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/F/g2Z7pTZIfdq8aK0yWSwnMakx56h3gGvf4l8LUM3E=; b=q/7kvcXkxObpMNDSYqCTWhG12zMj949+VgRpv9di516BP3Ob7a99Nk/WtuJ3+h1lDA yfchQUmBtbBMfiY/T8e4WCYYRo4aDw0q+QxCPuJ9nY+52VzNLT5+aTAIxNWclZkcTQwV yNOBo2+agm5IJCMbB7t6poQL6+6tmyBmfcEks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jS72GjI8vOb9XCdUd7vHpkXBTOXn9ZA9kovhEb2xJ5przpk8Uxw6clhq4OUaaYqj70 SRD/sZjy+btLq9VHl23w3xl/LgzPi/Ad8T2pEuK9taverdJDkIoNRxQAP+b7ISnHNjTN MxitLPx+Y5fiz70/2QxjkMZx4JaTt6VBFrUkQ= MIME-Version: 1.0 Received: by 10.52.98.5 with SMTP id ee5mr3778792vdb.200.1306937560277; Wed, 01 Jun 2011 07:12:40 -0700 (PDT) Received: by 10.52.116.65 with HTTP; Wed, 1 Jun 2011 07:12:40 -0700 (PDT) In-Reply-To: References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Jun 2011 10:12:40 -0400 Message-ID: From: Stephen Botzko To: "Mike Hammer (hmmr)" Content-Type: multipart/alternative; boundary=20cf307f34a606229404a4a71d9a Cc: clue@ietf.org Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:13:31 -0000 --20cf307f34a606229404a4a71d9a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And use "device" or "UA" instead of RFC 4353 participant? Unfortunately (IMO), the use of participant in the RFC 4353 sense is pretty widespread in RAI. So we probably need to find a new word. The text is frequently awkward if you use human as a noun. And not all humans are participants, some are operators or administrators (or possibly even spectators). The thesaurus doesn't help much: >>> *Synonyms* actor, partaker, participator, party, player, sharer *Related Words* accessory (also accessary), aide, assistant, helper; colleague, partner *Near Antonyms* bystander, looker-on, observer, onlooker, spectator, watcher; wallflower *Antonyms* nonparticipant >>> I suppose we could use "human participant", and the traditional Alice, Bob... Stephen Botzko On Wed, Jun 1, 2011 at 8:55 AM, Mike Hammer (hmmr) wrote: > Option 4: don't use participant at all, since it is ambiguous. > > If you mean to talk about a human, then simply say Human. > > Hopefully, that term is unambiguous. > > Mike > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: Wednesday, June 01, 2011 6:56 AM > To: Paul Kyzivat (pkyzivat); clue@ietf.org > Subject: Re: [clue] Definitions: Participant > > > Hi, > > In my ears, "particiapant" has always been associated with a human. > > Also, my understanding is that ITU-T defines participant as a human > participating in a conference, and I strongly think we should avoid > identical wording with different meaning - it will only cause problems > sooner or later. > > Why can't we simply talk about "endpoint" or "client" when talking about > the SIP device (whether it's a full blown telepresence room or a small > mobile phone)? That's wording that people are used to, so I don't see why= we > need to come up with something new... > > Regards, > > Christer > > > > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: 1. kes=E4kuuta 2011 2:50 > > To: clue@ietf.org > > Subject: Re: [clue] Definitions: Participant > > > > I support using Participant in the 4353 sense. > > (Its really the only definition that most of the software can > > use in a useful way. E.g. the conference roster is about > > these automata. This becomes especially obvious when you have > > the same "person" showing up multiple times in the roster.) > > > > If there is need to talk about the human(s) associated with a > > participant, then it would make sense to define another term for that. > > > > Thanks, > > Paul (as individual) > > > > On 5/31/2011 7:03 PM, Stephan Wenger wrote: > > > Hi all, > > > I thought I would quickly rev the definitions doc, and > > found out that > > > I cannot find agreements on a number of terms. This is the > > first of a > > > set of eamils that will hopefully lead us to close the > > definitions on > > > a few terms. > > > So this email is about "Participant". > > > > > > We have the odd definition that RFC 4353 lists participant > > essentially > > > as a piece of software and not as a human. To Song Haibin, Steve > > > Botzko (and to me), Participants sounds like human, though. > > > > > > Several ways forward: > > > > > > 1. Use Participant in the 4353 sense only > > > 2. Use Participant in the sense of a human participating in a > > > telepresence session only. That would mean that there > > can be many > > > participants at any endpoint, and endpoint can have > > no participant > > > (empty room or webcam), and so forth. > > > 3. Use Participant in the sense of 2) above, and add > > remark that if > > > 4353 Participant is meant, this will be explicitely mentioned. > > > > > > My preference is 1. 2 and 3 have too much potential for confusion. > > > Shame on 4353 for that. > > > > > > Opinions? > > > > > > Stephan > > > > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307f34a606229404a4a71d9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And use "device" or "UA" instead of RFC 4353 participan= t?=A0

Unfortunately (IMO), the use of participant in the RFC 4353 s= ense is pretty widespread in RAI.=A0 So we probably need to find a new word= .

The text is frequently awkward if you use human as a noun.=A0 And not all h= umans are=20 participants, some are operators or administrators (or possibly even=20 spectators).

The thesaurus doesn't help much:

>>>= ;
Synonyms actor, partaker, participator, p= arty, player, sharer
Related Words accessory (also accessary), ai= de, assistant, helper; colleague, partner
Near Antonyms bystander, looker-on, observer, onlooker, spectator, w= atcher; wallflower
Antonyms nonparticipant
>>>
I suppose we could use "human participant", and the traditional= Alice, Bob...

Stephen Botzko


On Wed, J= un 1, 2011 at 8:55 AM, Mike Hammer (hmmr) <hmmr@cisco.com> wrote:
Option 4: =A0don't use participant at all, since it is ambiguous.

If you mean to talk about a human, then simply say Human.

Hopefully, that term is unambiguous.

Mike


-----Original Message-----
From: clue-bounces@ietf.org [m= ailto:clue-bounces@ietf.org] O= n Behalf Of Christer Holmberg
Sent: Wednesday, June 01, 2011 6:56 AM
To: Paul Kyzivat (pkyzivat); clue@ietf.org=
Subject: Re: [clue] Definitions: Participant


Hi,

In my ears, "particiapant" has always been associated with a huma= n.

Also, my understanding is that ITU-T defines participant as a human partici= pating in a conference, and I strongly think we should avoid identical word= ing with different meaning - it will only cause problems sooner or later.
Why can't we simply talk about "endpoint" or "client&quo= t; when talking about the SIP device (whether it's a full blown telepre= sence room or a small mobile phone)? That's wording that people are use= d to, so I don't see why we need to come up with something new...

Regards,

Christer






> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: 1. kes=E4kuuta 2011 2:50
> To: clue@ietf.org
> Subject: Re: [clue] Definitions: Participant
>
> I support using Participant in the 4353 sense.
> (Its really the only definition that most of the software can
> use in a useful way. E.g. the conference roster is about
> these automata. This becomes especially obvious when you have
> the same "person" showing up multiple times in the roster.)<= br> >
> If there is need to talk about the human(s) associated with a
> participant, then it would make sense to define another term for that.=
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul (as individual)
>
> On 5/31/2011 7:03 PM, Stephan Wenger wrote:
> > Hi all,
> > I thought I would quickly rev the definitions doc, and
> found out that
> > I cannot find agreements on a number of terms. This is the
> first of a
> > set of eamils that will hopefully lead us to close the
> definitions on
> > a few terms.
> > So this email is about "Participant".
> >
> > We have the odd definition that RFC 4353 lists participant
> essentially
> > as a piece of software and not as a human. To Song Haibin, Steve<= br> > > Botzko (and to me), Participants sounds like human, though.
> >
> > Several ways forward:
> >
> > =A0 =A01. Use Participant in the 4353 sense only
> > =A0 =A02. Use Participant in the sense of a human participating i= n a
> > =A0 =A0 =A0 telepresence session only. That would mean that there=
> can be many
> > =A0 =A0 =A0 participants at any endpoint, and endpoint can have > no participant
> > =A0 =A0 =A0 (empty room or webcam), and so forth.
> > =A0 =A03. Use Participant in the sense of 2) above, and add
> remark that if
> > =A0 =A0 =A0 4353 Participant is meant, this will be explicitely m= entioned.
> >
> > My preference is 1. 2 and 3 have too much potential for confusion= .
> > Shame on 4353 for that.
> >
> > Opinions?
> >
> > Stephan
> >
> >
> >
> >
> > _______________________________________________
> > clue mailing list
> > clue@ietf.org
> > https://www.ietf.org/mailman/listinfo/clue
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf307f34a606229404a4a71d9a-- From hmmr@cisco.com Wed Jun 1 07:15:43 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09A5E06C8 for ; Wed, 1 Jun 2011 07:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.964 X-Spam-Level: X-Spam-Status: No, score=-9.964 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtCCW8C7o5Ma for ; Wed, 1 Jun 2011 07:15:43 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 1E08BE0699 for ; Wed, 1 Jun 2011 07:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hmmr@cisco.com; l=4056; q=dns/txt; s=iport; t=1306937742; x=1308147342; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=zKPJNxWZUWFW9X2ZgQ3HEJKtGAn/Gmax/4gWNWviQgQ=; b=aJ85h9u9zO1JTBh3rbBZ88WOgsCjxIg4G5kytmFFhp76IizKtowWRYY5 4jpvisg2jEglW2FUC/LoJiRyxmEsUx8mULXJ/QHpqunNf0roi6fskoU5W 2+DYq+lqaLH1vXKTJueKwcjxiEIVmjHYbtOIEwQyECFr6F7BMWWCMTVI9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBANBI5k2tJXHA/2dsb2JhbABFDpdQjlR3qhqdUoMXgwkEhmWOPIp9 X-IronPort-AV: E=Sophos;i="4.65,303,1304294400"; d="scan'208";a="357438945" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-5.cisco.com with ESMTP; 01 Jun 2011 14:15:42 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p51EFgNd031219; Wed, 1 Jun 2011 14:15:42 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 09:15:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jun 2011 09:15:41 -0500 Message-ID: In-Reply-To: <4DE60A5E.105@realtimetext.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] 2 draft covering real-time text relevant for conferencing/ multiple participants and telepresence Thread-Index: AcwgQMkAZMhjCg7IRlG8VXTAcDPwIgAI94Jw References: <4DE0083A.3040102@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2A65D7@ESESSCMS0356.eemea.ericsson.se><4DE4E7BF.8070301@cisco.com> <4DE60A5E.105@realtimetext.org> From: "Mike Hammer (hmmr)" To: , X-OriginalArrivalTime: 01 Jun 2011 14:15:42.0176 (UTC) FILETIME=[63E75600:01CC2066] Subject: Re: [clue] 2 draft covering real-time text relevant for conferencing/ multiple participants and telepresence X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:15:43 -0000 Arnoud, Is that keyboard left and keyboard right? :) I took a quick look through the referenced ID and did not see reference to audio and video feeds in a multi-party situation. With TP, the system may be designed to select one of multiple cameras to display when there are more participants than displays. So, is your intent that when a 'texter' is 'speaking' that the keyboard input should direct the camera on him/her to be the one selected for display? How do you identify the text-speaker from someone just doing email? Does the rate of texting translate to volume for selection of video feed? Is the text intended to be overwritten on the screen, or is there a separate screen? If there is a separate display screen, do all 'text-speakers' get equal time, or does an algorithm select which one is displayed there? If there is a conflict between an audio feed and a text feed for attention, how do you decide which video is displayed? Are there signers or text to audio speakers possible? Lots of questions. I think you should contribute to CLUE. However, I would question bolting on a solution after the fact with separate drafts. Perhaps, all input and output devices should be integrated into the base drafts. Mike -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Arnoud van Wijk Sent: Wednesday, June 01, 2011 5:46 AM To: clue@ietf.org Subject: [clue] 2 draft covering real-time text relevant for conferencing/ multiple participants and telepresence Hi all, I am getting a clue about CLUE. :-) This is an excellent WG covering what we need for a good telePRESENCE=20 without hurdles. If I communicate remote with other persons, I'd like to "forget" that I=20 participate remote. There should be no limitations in the ability to=20 communicate. The focus is at this moment on audio and video, lets make real-time text also a standard media to be used in all the work and scenarios as well=20 with CLUE. The use of Total Conversation, where audio, video and real-time text are presented and available simultaneously will actually optimize the=20 communication with others. As a deaf person, I need lipreading and real-time text together, others=20 sign language, others having real-time text as support if the language=20 used in the conference is not your native language and have the text in=20 your own language. Or even to talk and discuss with others during the conference with=20 real-time text while listening to the main conference. More about real-time text can be found at: http://www.realtimetext.org=20 but most of you are already familiar with it. It is not only for persons with a hearing disability, it is for all=20 breathing humans who want to communicate (and for a few robots out here=20 :-) ) But using Total Conversation will remove the biggest Internet=20 (telephony/conferencing) communication hurdle for persons who are deaf,=20 hard of hearing or have a speech impairment. And that is not a joke. We have submitted now 2 drafts that are what I feel quite valuable for CLUE. Text media handling in RTP based real-time conferences https://datatracker.ietf.org/doc/draft-hellstrom-text-conference/ and Presentation of Text Conversation in real-time and en-bloc form https://datatracker.ietf.org/doc/draft-hellstrom-textpreview/ How would you feel about continuing these drafts under the CLUE banner? I am looking forward to your feedback and comments and well...anything=20 that you throw at me and my fellow authors :-) Thank you. Sincerely Arnoud van Wijk PS we can also help with more insight on Total Conversation regarding=20 quality of the video, camera position and the angle of the view (for=20 example head for lipreading, upper body and sufficient area around the=20 person for sign language etc.). _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Wed Jun 1 09:12:45 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E214E0671 for ; Wed, 1 Jun 2011 09:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.573 X-Spam-Level: X-Spam-Status: No, score=-103.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSOBooi5kaFk for ; Wed, 1 Jun 2011 09:12:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F74DE0677 for ; Wed, 1 Jun 2011 09:12:17 -0700 (PDT) Received: by vxg33 with SMTP id 33so5835515vxg.31 for ; Wed, 01 Jun 2011 09:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BrclwkcYWdYMCu6t+OHxs5KLlVU5rHFJGiM6PtbJs+U=; b=w6vHexG0Ba/zKOd9HEheYNgFlznXWaUqjtlhINFCke5m0X96pgKyImDbxTLB3FPGv7 d8B5N2zneyOAAG9z7gF0AVR6wYyIyqwnyGH3WL4dH2VDBrfaJ3TOvNaBtDMk20ynU2UZ 7l+wt2sKoJhz7UDzjiEx4GeVNItrf+/CEWTJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kZ6kxeoR0cXO7FCDBhkRHl5WJf95b4KEdJb61P+ueMVT6LoWDR6WMBcjKAHHp/e1hV h8A/s9icsWzrrjhJ8CyglshJz8qKaLzGc/F2z1MugEq/12gR7LPAy1TMpCq8kbik0ibJ xY2MFgEfQEP4fd1z1yYYbyvrujDl57GGJb7Ks= MIME-Version: 1.0 Received: by 10.52.98.33 with SMTP id ef1mr2372166vdb.23.1306944735590; Wed, 01 Jun 2011 09:12:15 -0700 (PDT) Received: by 10.52.158.39 with HTTP; Wed, 1 Jun 2011 09:12:15 -0700 (PDT) In-Reply-To: <4DE60A5E.105@realtimetext.org> References: <4DE0083A.3040102@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2A65D7@ESESSCMS0356.eemea.ericsson.se> <4DE4E7BF.8070301@cisco.com> <4DE60A5E.105@realtimetext.org> Date: Wed, 1 Jun 2011 11:12:15 -0500 Message-ID: From: Mary Barnes To: arnoud.vanwijk@realtimetext.org Content-Type: multipart/alternative; boundary=20cf307f354ab4ba5104a4a8c828 Cc: clue@ietf.org Subject: Re: [clue] 2 draft covering real-time text relevant for conferencing/ multiple participants and telepresence X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:12:45 -0000 --20cf307f354ab4ba5104a4a8c828 Content-Type: text/plain; charset=ISO-8859-1 Given that this work has been submitted to DISPATCH for discussion, the thread of discussion needs to occur on the DISPATCH WG mailing list - in particular the requirements for this solution. That all said, if there is anything in the current set of CLUE requirements that would prevent this functionality in the future, feedback of that nature would be useful. Regards, Mary. CLUE WG co-chair On Wed, Jun 1, 2011 at 4:46 AM, Arnoud van Wijk < arnoud.vanwijk@realtimetext.org> wrote: > Hi all, > I am getting a clue about CLUE. :-) > This is an excellent WG covering what we need for a good telePRESENCE > without hurdles. > If I communicate remote with other persons, I'd like to "forget" that I > participate remote. There should be no limitations in the ability to > communicate. > > The focus is at this moment on audio and video, lets make real-time text > also a standard media to be used in all the work and scenarios as well with > CLUE. > The use of Total Conversation, where audio, video and real-time text are > presented and available simultaneously will actually optimize the > communication with others. > As a deaf person, I need lipreading and real-time text together, others > sign language, others having real-time text as support if the language used > in the conference is not your native language and have the text in your own > language. > Or even to talk and discuss with others during the conference with > real-time text while listening to the main conference. > > More about real-time text can be found at: http://www.realtimetext.org but > most of you are already familiar with it. > > It is not only for persons with a hearing disability, it is for all > breathing humans who want to communicate (and for a few robots out here :-) > ) > But using Total Conversation will remove the biggest Internet > (telephony/conferencing) communication hurdle for persons who are deaf, hard > of hearing or have a speech impairment. And that is not a joke. > > We have submitted now 2 drafts that are what I feel quite valuable for > CLUE. > > Text media handling in RTP based real-time conferences > https://datatracker.ietf.org/doc/draft-hellstrom-text-conference/ > > and > Presentation of Text Conversation in real-time and en-bloc form > https://datatracker.ietf.org/doc/draft-hellstrom-textpreview/ > > How would you feel about continuing these drafts under the CLUE banner? > I am looking forward to your feedback and comments and well...anything that > you throw at me and my fellow authors :-) > > Thank you. > > Sincerely > > Arnoud van Wijk > > PS we can also help with more insight on Total Conversation regarding > quality of the video, camera position and the angle of the view (for example > head for lipreading, upper body and sufficient area around the person for > sign language etc.). > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307f354ab4ba5104a4a8c828 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given that this work has been submitted to DISPATCH for discussion, =A0the = thread of discussion needs to occur on the DISPATCH WG mailing list - in pa= rticular the requirements for this solution.=A0

That all= said, if there is anything in the current set of CLUE requirements that wo= uld prevent this functionality in the future, feedback of that nature would= be useful.=A0

Regards,
Mary.
CLUE WG co-chair
=
On Wed, Jun 1, 2011 at 4:46 AM, Arnoud van W= ijk <arnoud.vanwijk@realtimetext.org> wrote:
Hi all,
I am getting a clue about CLUE. :-)
This is an excellent WG covering what we need for a good telePRESENCE witho= ut hurdles.
If I communicate remote with other persons, I'd like to "forget&qu= ot; that I participate remote. There should be no limitations in the abilit= y to communicate.

The focus is at this moment on audio and video, lets make real-time text al= so a standard media to be used in all the work and scenarios as well with C= LUE.
The use of Total Conversation, where audio, video and real-time text are pr= esented and available simultaneously will actually optimize the communicati= on with others.
As a deaf person, I need lipreading and real-time text together, others sig= n language, others having real-time text as support if the language used in= the conference is not your native language and have the text in your own l= anguage.
Or even to talk and discuss with others during the conference with real-tim= e text while listening to the main conference.

More about real-time text can be found at: http://www.realtimetext.org but most of you a= re already familiar with it.

It is not only for persons with a hearing disability, it is for all breathi= ng humans who want to communicate (and for a few robots out here :-) )
But using Total Conversation will remove the biggest Internet (telephony/co= nferencing) communication hurdle for persons who are deaf, hard of hearing = or have a speech impairment. And that is not a joke.

We have submitted now 2 drafts that are what I feel quite valuable for CLUE= .

Text media handling in RTP based real-time conferences
https://datatracker.ietf.org/doc/draft-hellstrom-text-= conference/

and
Presentation of Text Conversation in real-time and en-bloc form
https://datatracker.ietf.org/doc/draft-hellstrom-textprevi= ew/

How would you feel about continuing these drafts under the CLUE banner?
I am looking forward to your feedback and comments and well...anything that= you throw at me and my fellow authors :-)

Thank you.

Sincerely

Arnoud van Wijk

PS we can also help with more insight on Total Conversation regarding quali= ty of the video, camera position and the angle of the view (for example hea= d for lipreading, upper body and sufficient area around the person for sign= language etc.).

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

--20cf307f354ab4ba5104a4a8c828-- From pkyzivat@cisco.com Wed Jun 1 13:27:20 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0682FE0950 for ; Wed, 1 Jun 2011 13:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.38 X-Spam-Level: X-Spam-Status: No, score=-110.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqBhl9aRaYhU for ; Wed, 1 Jun 2011 13:27:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id EE67BE07A5 for ; Wed, 1 Jun 2011 13:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3271; q=dns/txt; s=iport; t=1306960036; x=1308169636; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TTfNAB222pdbxiD7ftg6w/ZdZ8RzsCZKzmWxLl7P818=; b=TkF1IqjO0d0RlhxcsVKcYuXfLK/W7Sp4yiu6UsGscbhqVT3srPz3+CEF RUD+4wovWUk0Idtx8UrDFsuP9d+osGwR3xtlXfKYCvP+moa/Q2xbYUltG gw0k3wXquigrB+cElC3+Z0VaPYxvS057zb6o+DIFynRrVOZ22QFasHMMx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACOf5k2tJV2a/2dsb2JhbABTpi93iHGhY51XhiAEkFWEQ4sE X-IronPort-AV: E=Sophos;i="4.65,305,1304294400"; d="scan'208";a="368408202" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2011 20:27:16 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p51KRFGR015202; Wed, 1 Jun 2011 20:27:16 GMT Message-ID: <4DE6A0A3.7090009@cisco.com> Date: Wed, 01 Jun 2011 16:27:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "clue@ietf.org" Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:27:20 -0000 On 6/1/2011 6:56 AM, Christer Holmberg wrote: > > Hi, > > In my ears, "particiapant" has always been associated with a human. > > Also, my understanding is that ITU-T defines participant as a human participating in a conference, Can you provide a reference? And, is it something CLUE wants/needs to reference? > and I strongly think we should avoid identical wording with different meaning - it will only cause problems sooner or later. Which is why we are concerned about being consistent with RFC 4353. (We have a more difficult problem if we have dependency on documents that have conflicting definitions for the term.) Thanks, Paul > Why can't we simply talk about "endpoint" or "client" when talking about the SIP device (whether it's a full blown telepresence room or a small mobile phone)? That's wording that people are used to, so I don't see why we need to come up with something new... > > Regards, > > Christer > > > > > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 1. kesäkuuta 2011 2:50 >> To: clue@ietf.org >> Subject: Re: [clue] Definitions: Participant >> >> I support using Participant in the 4353 sense. >> (Its really the only definition that most of the software can >> use in a useful way. E.g. the conference roster is about >> these automata. This becomes especially obvious when you have >> the same "person" showing up multiple times in the roster.) >> >> If there is need to talk about the human(s) associated with a >> participant, then it would make sense to define another term for that. >> >> Thanks, >> Paul (as individual) >> >> On 5/31/2011 7:03 PM, Stephan Wenger wrote: >>> Hi all, >>> I thought I would quickly rev the definitions doc, and >> found out that >>> I cannot find agreements on a number of terms. This is the >> first of a >>> set of eamils that will hopefully lead us to close the >> definitions on >>> a few terms. >>> So this email is about "Participant". >>> >>> We have the odd definition that RFC 4353 lists participant >> essentially >>> as a piece of software and not as a human. To Song Haibin, Steve >>> Botzko (and to me), Participants sounds like human, though. >>> >>> Several ways forward: >>> >>> 1. Use Participant in the 4353 sense only >>> 2. Use Participant in the sense of a human participating in a >>> telepresence session only. That would mean that there >> can be many >>> participants at any endpoint, and endpoint can have >> no participant >>> (empty room or webcam), and so forth. >>> 3. Use Participant in the sense of 2) above, and add >> remark that if >>> 4353 Participant is meant, this will be explicitely mentioned. >>> >>> My preference is 1. 2 and 3 have too much potential for confusion. >>> Shame on 4353 for that. >>> >>> Opinions? >>> >>> Stephan >>> >>> >>> >>> >>> _______________________________________________ >>> clue mailing 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 stephen.botzko@gmail.com Wed Jun 1 13:59:16 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBCFE0813 for ; Wed, 1 Jun 2011 13:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhtHBtIrLmvP for ; Wed, 1 Jun 2011 13:59:15 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50841E07CF for ; Wed, 1 Jun 2011 13:59:15 -0700 (PDT) Received: by vws12 with SMTP id 12so220811vws.31 for ; Wed, 01 Jun 2011 13:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=N1tsjt3PY4YbkSGi7MqpJtn/ROqbKa4Pc5tcTPZT6Tk=; b=ouJBCflvlpxiKfEWKoFy+HwImtYMaCi2yoAciCvQd2XMd8vbU57OdQOStVFwhVZJK7 Of7RIg6EgcOcEqsEH15vlR+4D+WDqL4H7mCTEfQzgr7oo9HZSPCI7TmqRg/BD73OD8kx ip8ZY5K4AbzZa4I64cB/dVyIWiS+2Lp7huqGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cde/9F0Cu9jH9UvkJIWO5Dhid1YuywR9ZmXXT7TeFOf3Sxy3bxp7T+3B3DQIMxZXma euGuFys7UJt4GCOiLhVjv6vDz6XvCge28sm6zMXS6VkoORkEatm2JgxtwgRtFqLQdoi6 WSVcS+gTMPOkum9QHUSeBQjtxaDDoebrlOG7M= MIME-Version: 1.0 Received: by 10.52.76.131 with SMTP id k3mr5691303vdw.80.1306961954418; Wed, 01 Jun 2011 13:59:14 -0700 (PDT) Received: by 10.52.116.65 with HTTP; Wed, 1 Jun 2011 13:59:14 -0700 (PDT) In-Reply-To: <4DE6A0A3.7090009@cisco.com> References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> <4DE6A0A3.7090009@cisco.com> Date: Wed, 1 Jun 2011 16:59:14 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=bcaec50160e30730a404a4accbfe Cc: "clue@ietf.org" Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:59:16 -0000 --bcaec50160e30730a404a4accbfe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line, addressing the question on ITU-T definitions. Stephen Botzko On Wed, Jun 1, 2011 at 4:27 PM, Paul Kyzivat wrote: > > > On 6/1/2011 6:56 AM, Christer Holmberg wrote: > >> >> Hi, >> >> In my ears, "participant" has always been associated with a human. >> >> Also, my understanding is that ITU-T defines participant as a human >> participating in a conference, >> > > Can you provide a reference? > The ITU has a definitions database (prototype) here: http://www.itu.int/ITU-R/index.asp?redirect=3Dtrue&category=3Dinformation&l= ink=3Dterminology-database&lang=3Den&adsearch=3D&SearchTerminology=3D§o= r=3D&language=3Dall&part=3Dabbreviationterm&kind=3Danywhere According this database, there are 4 ITU-T recommendations that define "participant". Two of these recommendations define it is as human - I.254.5 (The served user or a conferee.) and T.124 (A person participating in a conference at a node.) The other two recommendations do not define it as a human user (and none define it like RFC 4353). And, is it something CLUE wants/needs to reference? > > Neither recommendation seems relevant to CLUE > and I strongly think we should avoid identical wording with different >> meaning - it will only cause problems sooner or later. >> > > Which is why we are concerned about being consistent with RFC 4353. > > (We have a more difficult problem if we have dependency on documents that > have conflicting definitions for the term.) > > Thanks, > Paul > > > Why can't we simply talk about "endpoint" or "client" when talking about >> the SIP device (whether it's a full blown telepresence room or a small >> mobile phone)? That's wording that people are used to, so I don't see wh= y we >> need to come up with something new... >> >> Regards, >> >> Christer >> >> >> >> >> >> >> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: 1. kes=E4kuuta 2011 2:50 >>> To: clue@ietf.org >>> Subject: Re: [clue] Definitions: Participant >>> >>> I support using Participant in the 4353 sense. >>> (Its really the only definition that most of the software can >>> use in a useful way. E.g. the conference roster is about >>> these automata. This becomes especially obvious when you have >>> the same "person" showing up multiple times in the roster.) >>> >>> If there is need to talk about the human(s) associated with a >>> participant, then it would make sense to define another term for that. >>> >>> Thanks, >>> Paul (as individual) >>> >>> On 5/31/2011 7:03 PM, Stephan Wenger wrote: >>> >>>> Hi all, >>>> I thought I would quickly rev the definitions doc, and >>>> >>> found out that >>> >>>> I cannot find agreements on a number of terms. This is the >>>> >>> first of a >>> >>>> set of eamils that will hopefully lead us to close the >>>> >>> definitions on >>> >>>> a few terms. >>>> So this email is about "Participant". >>>> >>>> We have the odd definition that RFC 4353 lists participant >>>> >>> essentially >>> >>>> as a piece of software and not as a human. To Song Haibin, Steve >>>> Botzko (and to me), Participants sounds like human, though. >>>> >>>> Several ways forward: >>>> >>>> 1. Use Participant in the 4353 sense only >>>> 2. Use Participant in the sense of a human participating in a >>>> telepresence session only. That would mean that there >>>> >>> can be many >>> >>>> participants at any endpoint, and endpoint can have >>>> >>> no participant >>> >>>> (empty room or webcam), and so forth. >>>> 3. Use Participant in the sense of 2) above, and add >>>> >>> remark that if >>> >>>> 4353 Participant is meant, this will be explicitely mentioned. >>>> >>>> My preference is 1. 2 and 3 have too much potential for confusion. >>>> Shame on 4353 for that. >>>> >>>> Opinions? >>>> >>>> Stephan >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec50160e30730a404a4accbfe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line, addressing the question on ITU-T definitions.

Stephen Botzk= o

On Wed, Jun 1, 2011 at 4:27 PM, Paul Ky= zivat <pkyzivat@= cisco.com> wrote:


On 6/1/2011 6:56 AM, Christer Holmberg wrote:

Hi,

In my ears, "participant" has always been associated with a human= .

Also, my understanding is that ITU-T defines participant as a human partici= pating in a conference,

Can you provide a reference?

The ITU has a definitions database (prototype) here: http://www.itu.int/ITU-R/index.asp?redirect=3Dtr= ue&category=3Dinformation&link=3Dterminology-database&lang=3Den= &adsearch=3D&SearchTerminology=3D&sector=3D&language=3Dall&= amp;part=3Dabbreviationterm&kind=3Danywhere

Acc= ording this database, there are 4 ITU-T recommendations that define "p= articipant".=A0 Two of these recommendations define it is as human=A0 = - I.254.5 (Th= e served user or a conferee.) and T.124 (A person participating in a conference at= a node.)=A0 The other two recommendations do not define it as a human user= (and none define it like RFC 4353).

And, is it something CLUE wants/needs to reference?

=A0
Neither recommendation seems relevant t= o CLUE


and I strongly think we should avoid identical wording with different meani= ng - it will only cause problems sooner or later.

Which is why we are concerned about being consistent with RFC 4353.

(We have a more difficult problem if we have dependency on documents that h= ave conflicting definitions for the term.)

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


Why can't we simply talk about "endpoint" or "client&quo= t; when talking about the SIP device (whether it's a full blown telepre= sence room or a small mobile phone)? That's wording that people are use= d to, so I don't see why we need to come up with something new...

Regards,

Christer






-----Original Message-----
From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On
Behalf Of Paul Kyzivat
Sent: 1. kes=E4kuuta 2011 2:50
To: clue@ietf.org Subject: Re: [clue] Definitions: Participant

I support using Participant in the 4353 sense.
(Its really the only definition that most of the software can
use in a useful way. E.g. the conference roster is about
these automata. This becomes especially obvious when you have
the same "person" showing up multiple times in the roster.)

If there is need to talk about the human(s) associated with a
participant, then it would make sense to define another term for that.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul (as individual)

On 5/31/2011 7:03 PM, Stephan Wenger wrote:
Hi all,
I thought I would quickly rev the definitions doc, and
found out that
I cannot find agreements on a number of terms. This is the
first of a
set of eamils that will hopefully lead us to close the
definitions on
a few terms.
So this email is about "Participant".

We have the odd definition that RFC 4353 lists participant
essentially
as a piece of software and not as a human. To Song Haibin, Steve
Botzko (and to me), Participants sounds like human, though.

Several ways forward:

=A0 =A01. Use Participant in the 4353 sense only
=A0 =A02. Use Participant in the sense of a human participating in a
=A0 =A0 =A0 telepresence session only. That would mean that there
can be many
=A0 =A0 =A0 participants at any endpoint, and endpoint can have
no participant
=A0 =A0 =A0 (empty room or webcam), and so forth.
=A0 =A03. Use Participant in the sense of 2) above, and add
remark that if
=A0 =A0 =A0 4353 Participant is meant, this will be explicitely mentioned.=

My preference is 1. 2 and 3 have too much potential for confusion.
Shame on 4353 for that.

Opinions?

Stephan




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

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

--bcaec50160e30730a404a4accbfe-- From mary.ietf.barnes@gmail.com Wed Jun 1 14:00:15 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440CBE0813 for ; Wed, 1 Jun 2011 14:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhzTZKG0PgCX for ; Wed, 1 Jun 2011 14:00:14 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC08E07CF for ; Wed, 1 Jun 2011 14:00:13 -0700 (PDT) Received: by vxg33 with SMTP id 33so225926vxg.31 for ; Wed, 01 Jun 2011 14:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dK8UusmVS14i2XJvfXVyMzs51KZAFZRGtK0PX67D74c=; b=iTDPZyLSNhqhilbycg3GutPyHGZSgxbzlfhQN311ANMjooHbEzI6d499iAN/7n1gcQ AG9LE718Uo5RAkkQlCMEcWvJNx/p+fPpTZ8mBexIGBTnq6pr1KWcoF8dNZfaXPTO1zri BmjgJrtAwGOAzYL8Ek/hwNVVK2oAkTgvk+OnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iX9oRR4uliCivi4yJW2XqWyoMYGACCD0FgXMpuOM2jWzAqPm+yeOJwrgrs3VUgfumW rNcRO81cKYwGuYr1HwuazIR0gxufgKv2gK1DGaqLfmyjiNg/vyLeLDWEU1veD2p5sNZV hQkU+tFOoqSfWQMTnQsCotGPzLs7YFy6gy8Rs= MIME-Version: 1.0 Received: by 10.52.176.1 with SMTP id ce1mr3019481vdc.63.1306962013292; Wed, 01 Jun 2011 14:00:13 -0700 (PDT) Received: by 10.52.158.39 with HTTP; Wed, 1 Jun 2011 14:00:13 -0700 (PDT) In-Reply-To: <4DE6A0A3.7090009@cisco.com> References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> <4DE6A0A3.7090009@cisco.com> Date: Wed, 1 Jun 2011 16:00:13 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=bcaec517a812898a9604a4accef9 Cc: "clue@ietf.org" Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:00:15 -0000 --bcaec517a812898a9604a4accef9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable XCON also uses "participant" in the same context as RFC 4353. So, I think that consistency within the IETF context is more important than how other SDOs might use the term. References to humans in both RFC 4353 and XCON are qualifications of "operator" and "participant" rather than a standalone term. I will also note that SIPREC documents use the term participant in the same context as RFC 4353, although there are cases where it is used to refer to the human. But, the context makes that clear. So, my recommendation is that we use "human participant" in cases where the qualification is necessary. We also use the term "user" in both RFC 4353 and XCON (and SIPREC) in the context of actions that would be performed by a human (e.g., keypresses), etc. However, that term is overloaded in that it also is used for the logical representation of the physical/human user in the data model/conference object. And, SIPREC seems to use "participant" and "user" interchangeably (3rd para in the Into of requirements when it's discussing notification and opt out of recording). So, I still think that "human participant" is the best choice when a qualification is necessary. Mary. (as an individual) On Wed, Jun 1, 2011 at 3:27 PM, Paul Kyzivat wrote: > > > On 6/1/2011 6:56 AM, Christer Holmberg wrote: > >> >> Hi, >> >> In my ears, "particiapant" has always been associated with a human. >> >> Also, my understanding is that ITU-T defines participant as a human >> participating in a conference, >> > > Can you provide a reference? > And, is it something CLUE wants/needs to reference? > > > and I strongly think we should avoid identical wording with different >> meaning - it will only cause problems sooner or later. >> > > Which is why we are concerned about being consistent with RFC 4353. > > (We have a more difficult problem if we have dependency on documents that > have conflicting definitions for the term.) > > Thanks, > Paul > > > Why can't we simply talk about "endpoint" or "client" when talking about >> the SIP device (whether it's a full blown telepresence room or a small >> mobile phone)? That's wording that people are used to, so I don't see wh= y we >> need to come up with something new... >> >> Regards, >> >> Christer >> >> >> >> >> >> >> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: 1. kes=E4kuuta 2011 2:50 >>> To: clue@ietf.org >>> Subject: Re: [clue] Definitions: Participant >>> >>> I support using Participant in the 4353 sense. >>> (Its really the only definition that most of the software can >>> use in a useful way. E.g. the conference roster is about >>> these automata. This becomes especially obvious when you have >>> the same "person" showing up multiple times in the roster.) >>> >>> If there is need to talk about the human(s) associated with a >>> participant, then it would make sense to define another term for that. >>> >>> Thanks, >>> Paul (as individual) >>> >>> On 5/31/2011 7:03 PM, Stephan Wenger wrote: >>> >>>> Hi all, >>>> I thought I would quickly rev the definitions doc, and >>>> >>> found out that >>> >>>> I cannot find agreements on a number of terms. This is the >>>> >>> first of a >>> >>>> set of eamils that will hopefully lead us to close the >>>> >>> definitions on >>> >>>> a few terms. >>>> So this email is about "Participant". >>>> >>>> We have the odd definition that RFC 4353 lists participant >>>> >>> essentially >>> >>>> as a piece of software and not as a human. To Song Haibin, Steve >>>> Botzko (and to me), Participants sounds like human, though. >>>> >>>> Several ways forward: >>>> >>>> 1. Use Participant in the 4353 sense only >>>> 2. Use Participant in the sense of a human participating in a >>>> telepresence session only. That would mean that there >>>> >>> can be many >>> >>>> participants at any endpoint, and endpoint can have >>>> >>> no participant >>> >>>> (empty room or webcam), and so forth. >>>> 3. Use Participant in the sense of 2) above, and add >>>> >>> remark that if >>> >>>> 4353 Participant is meant, this will be explicitely mentioned. >>>> >>>> My preference is 1. 2 and 3 have too much potential for confusion. >>>> Shame on 4353 for that. >>>> >>>> Opinions? >>>> >>>> Stephan >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec517a812898a9604a4accef9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable XCON also uses "participant" in the same context as RFC 4353. =A0= So, I think that consistency within the IETF context is more important than= how other SDOs might use the term. =A0 References to humans in both RFC 43= 53 and XCON are qualifications of "operator" and "participan= t" rather than a standalone term. =A0I will also note that SIPREC docu= ments use the term participant in the same context as RFC 4353, although th= ere are cases where it is used to refer to the human. =A0But, the context m= akes that clear. So, my recommendation is that we use "human participa= nt" in cases where the qualification is necessary. =A0

We also use the term "user" in both RFC 4353 and X= CON (and SIPREC) in the context of actions that would be performed by a hum= an (e.g., keypresses), etc. However, that term is overloaded in that it als= o is used for the logical representation of the physical/human user in the = data model/conference object. And, SIPREC seems to use "participant&qu= ot; and "user" interchangeably (3rd para in the Into of requireme= nts when it's discussing notification and opt out of recording).=A0

So, I still think that "human participant" is= the best choice when a qualification is necessary. =A0

=
Mary.=A0
(as an individual)

On Wed, Jun 1, 2011 at 3:27 PM, Paul Kyzivat <pkyzivat@cisco.com> wrote:
=


On 6/1/2011 6:56 AM, Christer Holmberg wrote:

Hi,

In my ears, "particiapant" has always been associated with a huma= n.

Also, my understanding is that ITU-T defines participant as a human partici= pating in a conference,

Can you provide a reference?
And, is it something CLUE wants/needs to reference?


and I strongly think we should avoid identical wording with different meani= ng - it will only cause problems sooner or later.

Which is why we are concerned about being consistent with RFC 4353.

(We have a more difficult problem if we have dependency on documents that h= ave conflicting definitions for the term.)

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


Why can't we simply talk about "endpoint" or "client&quo= t; when talking about the SIP device (whether it's a full blown telepre= sence room or a small mobile phone)? That's wording that people are use= d to, so I don't see why we need to come up with something new...

Regards,

Christer






-----Original Message-----
From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On
Behalf Of Paul Kyzivat
Sent: 1. kes=E4kuuta 2011 2:50
To: clue@ietf.org Subject: Re: [clue] Definitions: Participant

I support using Participant in the 4353 sense.
(Its really the only definition that most of the software can
use in a useful way. E.g. the conference roster is about
these automata. This becomes especially obvious when you have
the same "person" showing up multiple times in the roster.)

If there is need to talk about the human(s) associated with a
participant, then it would make sense to define another term for that.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul (as individual)

On 5/31/2011 7:03 PM, Stephan Wenger wrote:
Hi all,
I thought I would quickly rev the definitions doc, and
found out that
I cannot find agreements on a number of terms. This is the
first of a
set of eamils that will hopefully lead us to close the
definitions on
a few terms.
So this email is about "Participant".

We have the odd definition that RFC 4353 lists participant
essentially
as a piece of software and not as a human. To Song Haibin, Steve
Botzko (and to me), Participants sounds like human, though.

Several ways forward:

=A0 =A01. Use Participant in the 4353 sense only
=A0 =A02. Use Participant in the sense of a human participating in a
=A0 =A0 =A0 telepresence session only. That would mean that there
can be many
=A0 =A0 =A0 participants at any endpoint, and endpoint can have
no participant
=A0 =A0 =A0 (empty room or webcam), and so forth.
=A0 =A03. Use Participant in the sense of 2) above, and add
remark that if
=A0 =A0 =A0 4353 Participant is meant, this will be explicitely mentioned.=

My preference is 1. 2 and 3 have too much potential for confusion.
Shame on 4353 for that.

Opinions?

Stephan




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

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

--bcaec517a812898a9604a4accef9-- From christer.holmberg@ericsson.com Wed Jun 1 14:03:03 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4247DE098F for ; Wed, 1 Jun 2011 14:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTVQhpyi-Qdy for ; Wed, 1 Jun 2011 14:03:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 07EE7E098E for ; Wed, 1 Jun 2011 14:03:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-cf-4de6a904e963 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3A.3D.09774.409A6ED4; Wed, 1 Jun 2011 23:03:00 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 1 Jun 2011 23:02:58 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 1 Jun 2011 23:02:57 +0200 Thread-Topic: [clue] Definitions: Participant Thread-Index: Acwgmk5uOFm6hrrKQ++fX+MsHtbnxAAA2nkO Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A405@ESESSCMS0356.eemea.ericsson.se> References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se>, <4DE6A0A3.7090009@cisco.com> In-Reply-To: <4DE6A0A3.7090009@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:03:03 -0000 Hi, >> In my ears, "particiapant" has always been associated with a human. >> >> Also, my understanding is that ITU-T defines participant as a human part= icipating in a conference, > >Can you provide a reference? I will look for it when I'm back in office on friday. >And, is it something CLUE wants/needs to reference? Not necessarily. I just think we should try to avoid definition conflicts. = And, if we are aware of such conflicts, I think we should document them. >>and I strongly think we should avoid identical wording with different mea= ning - it will only cause problems sooner or later. > >Which is why we are concerned about being consistent with RFC 4353. > >(We have a more difficult problem if we have dependency on documents >that have conflicting definitions for the term.) I'm not even sure if 4353 is always alligned with itself :) For example, in one place it talks about "anonymous particiapant", and to m= e that sounds more like a user, rather than a piece of software. Some parts= of the security text also seems to make a similar impression.=20 But, maybe that's not important for CLUE, if we only refer to the definitio= n part in 4353. Also, the 4353 definition talks about software that connects *A* user to a = conference. We would need to specify, that in the scope of our work, it can= connect multiple users to a conference. Regards, Christer > Why can't we simply talk about "endpoint" or "client" when talking about = the SIP device (whether it's a full blown telepresence room or a small mobi= le phone)? That's wording that people are used to, so I don't see why we ne= ed to come up with something new... > > Regards, > > Christer > > > > > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 1. kes=E4kuuta 2011 2:50 >> To: clue@ietf.org >> Subject: Re: [clue] Definitions: Participant >> >> I support using Participant in the 4353 sense. >> (Its really the only definition that most of the software can >> use in a useful way. E.g. the conference roster is about >> these automata. This becomes especially obvious when you have >> the same "person" showing up multiple times in the roster.) >> >> If there is need to talk about the human(s) associated with a >> participant, then it would make sense to define another term for that. >> >> Thanks, >> Paul (as individual) >> >> On 5/31/2011 7:03 PM, Stephan Wenger wrote: >>> Hi all, >>> I thought I would quickly rev the definitions doc, and >> found out that >>> I cannot find agreements on a number of terms. This is the >> first of a >>> set of eamils that will hopefully lead us to close the >> definitions on >>> a few terms. >>> So this email is about "Participant". >>> >>> We have the odd definition that RFC 4353 lists participant >> essentially >>> as a piece of software and not as a human. To Song Haibin, Steve >>> Botzko (and to me), Participants sounds like human, though. >>> >>> Several ways forward: >>> >>> 1. Use Participant in the 4353 sense only >>> 2. Use Participant in the sense of a human participating in a >>> telepresence session only. That would mean that there >> can be many >>> participants at any endpoint, and endpoint can have >> no participant >>> (empty room or webcam), and so forth. >>> 3. Use Participant in the sense of 2) above, and add >> remark that if >>> 4353 Participant is meant, this will be explicitely mentioned. >>> >>> My preference is 1. 2 and 3 have too much potential for confusion. >>> Shame on 4353 for that. >>> >>> Opinions? >>> >>> Stephan >>> >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>= From pkyzivat@cisco.com Wed Jun 1 14:04:16 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA27E0978 for ; Wed, 1 Jun 2011 14:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.384 X-Spam-Level: X-Spam-Status: No, score=-110.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlQkCMNXC8Xj for ; Wed, 1 Jun 2011 14:04:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 331A6E0970 for ; Wed, 1 Jun 2011 14:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6008; q=dns/txt; s=iport; t=1306962256; x=1308171856; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vG0xn7uLbNvBzv+GTIO8inKJX6qA0xpmVYnmoPiUepo=; b=dQQf716zxPDf9aSE1MsClsugz7pWOQR317qdabpYejShkc6VaQAOxZDS vA+vaLrjq4ctgnVLmVJGiOSKrJBHrKPMxN2uEsob5qzf2gyLQWJmZhZfx xzMpkL8MAqX6STdI8A2fAD3OPMF5YeYkiXLY5+w/XrxDBa4M9b0UKyl3n s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAC6o5k2tJV2b/2dsb2JhbABTpjB3iHGhWp1ZhiAEkFWEQ4sE X-IronPort-AV: E=Sophos;i="4.65,305,1304294400"; d="scan'208";a="328127931" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2011 21:04:15 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p51L4EVE003196; Wed, 1 Jun 2011 21:04:15 GMT Message-ID: <4DE6A94E.6010005@cisco.com> Date: Wed, 01 Jun 2011 17:04:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mary Barnes References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> <4DE6A0A3.7090009@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "clue@ietf.org" Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:04:17 -0000 wfm On 6/1/2011 5:00 PM, Mary Barnes wrote: > XCON also uses "participant" in the same context as RFC 4353. So, I > think that consistency within the IETF context is more important than > how other SDOs might use the term. References to humans in both RFC > 4353 and XCON are qualifications of "operator" and "participant" rather > than a standalone term. I will also note that SIPREC documents use the > term participant in the same context as RFC 4353, although there are > cases where it is used to refer to the human. But, the context makes > that clear. So, my recommendation is that we use "human participant" in > cases where the qualification is necessary. > > We also use the term "user" in both RFC 4353 and XCON (and SIPREC) in > the context of actions that would be performed by a human (e.g., > keypresses), etc. However, that term is overloaded in that it also is > used for the logical representation of the physical/human user in the > data model/conference object. And, SIPREC seems to use "participant" and > "user" interchangeably (3rd para in the Into of requirements when it's > discussing notification and opt out of recording). > > So, I still think that "human participant" is the best choice when a > qualification is necessary. > > Mary. > (as an individual) > > On Wed, Jun 1, 2011 at 3:27 PM, Paul Kyzivat > wrote: > > > > On 6/1/2011 6:56 AM, Christer Holmberg wrote: > > > Hi, > > In my ears, "particiapant" has always been associated with a human. > > Also, my understanding is that ITU-T defines participant as a > human participating in a conference, > > > Can you provide a reference? > And, is it something CLUE wants/needs to reference? > > > and I strongly think we should avoid identical wording with > different meaning - it will only cause problems sooner or later. > > > Which is why we are concerned about being consistent with RFC 4353. > > (We have a more difficult problem if we have dependency on documents > that have conflicting definitions for the term.) > > Thanks, > Paul > > > Why can't we simply talk about "endpoint" or "client" when > talking about the SIP device (whether it's a full blown > telepresence room or a small mobile phone)? That's wording that > people are used to, so I don't see why we need to come up with > something new... > > Regards, > > Christer > > > > > > > -----Original Message----- > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] On > Behalf Of Paul Kyzivat > Sent: 1. kesäkuuta 2011 2:50 > To: clue@ietf.org > Subject: Re: [clue] Definitions: Participant > > I support using Participant in the 4353 sense. > (Its really the only definition that most of the software can > use in a useful way. E.g. the conference roster is about > these automata. This becomes especially obvious when you have > the same "person" showing up multiple times in the roster.) > > If there is need to talk about the human(s) associated with a > participant, then it would make sense to define another term > for that. > > Thanks, > Paul (as individual) > > On 5/31/2011 7:03 PM, Stephan Wenger wrote: > > Hi all, > I thought I would quickly rev the definitions doc, and > > found out that > > I cannot find agreements on a number of terms. This is the > > first of a > > set of eamils that will hopefully lead us to close the > > definitions on > > a few terms. > So this email is about "Participant". > > We have the odd definition that RFC 4353 lists participant > > essentially > > as a piece of software and not as a human. To Song > Haibin, Steve > Botzko (and to me), Participants sounds like human, though. > > Several ways forward: > > 1. Use Participant in the 4353 sense only > 2. Use Participant in the sense of a human > participating in a > telepresence session only. That would mean that there > > can be many > > participants at any endpoint, and endpoint can have > > no participant > > (empty room or webcam), and so forth. > 3. Use Participant in the sense of 2) above, and add > > remark that if > > 4353 Participant is meant, this will be > explicitely mentioned. > > My preference is 1. 2 and 3 have too much potential for > confusion. > Shame on 4353 for that. > > Opinions? > > Stephan > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From christer.holmberg@ericsson.com Wed Jun 1 14:27:45 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37746E083F for ; Wed, 1 Jun 2011 14:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOrTSJhfb10d for ; Wed, 1 Jun 2011 14:27:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EDFC0E099D for ; Wed, 1 Jun 2011 14:27:25 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1c-4de6aebca131 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 01.D9.20773.CBEA6ED4; Wed, 1 Jun 2011 23:27:24 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 1 Jun 2011 23:27:22 +0200 From: Christer Holmberg To: Mary Barnes , Paul Kyzivat Date: Wed, 1 Jun 2011 23:24:24 +0200 Thread-Topic: [clue] Definitions: Participant Thread-Index: AcwgnueyCpMkYtAVQO6GdptPMA/gsgAA2AQo Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A407@ESESSCMS0356.eemea.ericsson.se> References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> <4DE6A0A3.7090009@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:27:45 -0000 Hi, If we go for the 4353 definition of "participant", when then talking about = humans/users, I would prefer "user" instead of "human participant". Regards, Christer ________________________________ From: Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Thursday, June 02, 2011 12:00 AM To: Paul Kyzivat Cc: Christer Holmberg; clue@ietf.org Subject: Re: [clue] Definitions: Participant XCON also uses "participant" in the same context as RFC 4353. So, I think = that consistency within the IETF context is more important than how other S= DOs might use the term. References to humans in both RFC 4353 and XCON ar= e qualifications of "operator" and "participant" rather than a standalone t= erm. I will also note that SIPREC documents use the term participant in th= e same context as RFC 4353, although there are cases where it is used to re= fer to the human. But, the context makes that clear. So, my recommendation= is that we use "human participant" in cases where the qualification is nec= essary. We also use the term "user" in both RFC 4353 and XCON (and SIPREC) in the c= ontext of actions that would be performed by a human (e.g., keypresses), et= c. However, that term is overloaded in that it also is used for the logical= representation of the physical/human user in the data model/conference obj= ect. And, SIPREC seems to use "participant" and "user" interchangeably (3rd= para in the Into of requirements when it's discussing notification and opt= out of recording). So, I still think that "human participant" is the best choice when a qualif= ication is necessary. Mary. (as an individual) On Wed, Jun 1, 2011 at 3:27 PM, Paul Kyzivat > wrote: On 6/1/2011 6:56 AM, Christer Holmberg wrote: Hi, In my ears, "particiapant" has always been associated with a human. Also, my understanding is that ITU-T defines participant as a human partici= pating in a conference, Can you provide a reference? And, is it something CLUE wants/needs to reference? and I strongly think we should avoid identical wording with different meani= ng - it will only cause problems sooner or later. Which is why we are concerned about being consistent with RFC 4353. (We have a more difficult problem if we have dependency on documents that h= ave conflicting definitions for the term.) Thanks, Paul Why can't we simply talk about "endpoint" or "client" when talking about th= e SIP device (whether it's a full blown telepresence room or a small mobile= phone)? That's wording that people are used to, so I don't see why we need= to come up with something new... Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Paul Kyzivat Sent: 1. kes=E4kuuta 2011 2:50 To: clue@ietf.org Subject: Re: [clue] Definitions: Participant I support using Participant in the 4353 sense. (Its really the only definition that most of the software can use in a useful way. E.g. the conference roster is about these automata. This becomes especially obvious when you have the same "person" showing up multiple times in the roster.) If there is need to talk about the human(s) associated with a participant, then it would make sense to define another term for that. Thanks, Paul (as individual) On 5/31/2011 7:03 PM, Stephan Wenger wrote: Hi all, I thought I would quickly rev the definitions doc, and found out that I cannot find agreements on a number of terms. This is the first of a set of eamils that will hopefully lead us to close the definitions on a few terms. So this email is about "Participant". We have the odd definition that RFC 4353 lists participant essentially as a piece of software and not as a human. To Song Haibin, Steve Botzko (and to me), Participants sounds like human, though. Several ways forward: 1. Use Participant in the 4353 sense only 2. Use Participant in the sense of a human participating in a telepresence session only. That would mean that there can be many participants at any endpoint, and endpoint can have no participant (empty room or webcam), and so forth. 3. Use Participant in the sense of 2) above, and add remark that if 4353 Participant is meant, this will be explicitely mentioned. My preference is 1. 2 and 3 have too much potential for confusion. Shame on 4353 for that. Opinions? Stephan _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing 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 coverdale@sympatico.ca Wed Jun 1 15:19:55 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872AEE082A for ; Wed, 1 Jun 2011 15:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62A9J7ohpNP2 for ; Wed, 1 Jun 2011 15:19:54 -0700 (PDT) Received: from blu0-omc4-s27.blu0.hotmail.com (blu0-omc4-s27.blu0.hotmail.com [65.55.111.166]) by ietfa.amsl.com (Postfix) with ESMTP id 9E555E0713 for ; Wed, 1 Jun 2011 15:19:54 -0700 (PDT) Received: from BLU0-SMTP88 ([65.55.111.135]) by blu0-omc4-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 15:19:54 -0700 X-Originating-IP: [67.70.131.169] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([67.70.131.169]) by BLU0-SMTP88.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 15:19:53 -0700 From: Paul Coverdale To: "'Christer Holmberg'" , "'Mary Barnes'" , "'Paul Kyzivat'" References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> <4DE6A0A3.7090009@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A407@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A407@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Jun 2011 18:19:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwgnueyCpMkYtAVQO6GdptPMA/gsgAA2AQoAAF4DjA= Content-Language: en-us X-OriginalArrivalTime: 01 Jun 2011 22:19:53.0368 (UTC) FILETIME=[07C37180:01CC20AA] Cc: clue@ietf.org Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 22:19:55 -0000 I wasn't familiar with RFC4353, so I took a quick look. It seems that = they did a great job of hi-jacking a perfectly good English word. E.G. "Participant" - a person who takes part in or becomes involved in a particular activity. So we will create a nice tautology if we talk about a human participant. Unless we want to differentiate between in-human participants. If we are going to treat the RFC4353 definition of "participant" as sacrosanct, then I would support "user" as the next best choice for CLUE purposes. ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Christer Holmberg >Sent: Wednesday, June 01, 2011 5:24 PM >To: Mary Barnes; Paul Kyzivat >Cc: clue@ietf.org >Subject: Re: [clue] Definitions: Participant > >Hi, > >If we go for the 4353 definition of "participant", when then talking >about humans/users, I would prefer "user" instead of "human >participant". > >Regards, > >Christer > >________________________________ >From: Mary Barnes [mary.ietf.barnes@gmail.com] >Sent: Thursday, June 02, 2011 12:00 AM >To: Paul Kyzivat >Cc: Christer Holmberg; clue@ietf.org >Subject: Re: [clue] Definitions: Participant > >XCON also uses "participant" in the same context as RFC 4353. So, I >think that consistency within the IETF context is more important than >how other SDOs might use the term. References to humans in both RFC >4353 and XCON are qualifications of "operator" and "participant" rather >than a standalone term. I will also note that SIPREC documents use the >term participant in the same context as RFC 4353, although there are >cases where it is used to refer to the human. But, the context makes >that clear. So, my recommendation is that we use "human participant" in >cases where the qualification is necessary. > >We also use the term "user" in both RFC 4353 and XCON (and SIPREC) in >the context of actions that would be performed by a human (e.g., >keypresses), etc. However, that term is overloaded in that it also is >used for the logical representation of the physical/human user in the >data model/conference object. And, SIPREC seems to use "participant" = and >"user" interchangeably (3rd para in the Into of requirements when it's >discussing notification and opt out of recording). > >So, I still think that "human participant" is the best choice when a >qualification is necessary. > >Mary. >(as an individual) > >On Wed, Jun 1, 2011 at 3:27 PM, Paul Kyzivat >> wrote: > > >On 6/1/2011 6:56 AM, Christer Holmberg wrote: > >Hi, > >In my ears, "particiapant" has always been associated with a human. > >Also, my understanding is that ITU-T defines participant as a human >participating in a conference, > >Can you provide a reference? >And, is it something CLUE wants/needs to reference? > > >and I strongly think we should avoid identical wording with different >meaning - it will only cause problems sooner or later. > >Which is why we are concerned about being consistent with RFC 4353. > >(We have a more difficult problem if we have dependency on documents >that have conflicting definitions for the term.) > > Thanks, > Paul > > >Why can't we simply talk about "endpoint" or "client" when talking = about >the SIP device (whether it's a full blown telepresence room or a small >mobile phone)? That's wording that people are used to, so I don't see >why we need to come up with something new... > >Regards, > >Christer > > > > > > >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue- >bounces@ietf.org] On >Behalf Of Paul Kyzivat >Sent: 1. kes=E4kuuta 2011 2:50 >To: clue@ietf.org >Subject: Re: [clue] Definitions: Participant > >I support using Participant in the 4353 sense. >(Its really the only definition that most of the software can >use in a useful way. E.g. the conference roster is about >these automata. This becomes especially obvious when you have >the same "person" showing up multiple times in the roster.) > >If there is need to talk about the human(s) associated with a >participant, then it would make sense to define another term for that. > > Thanks, > Paul (as individual) > >On 5/31/2011 7:03 PM, Stephan Wenger wrote: >Hi all, >I thought I would quickly rev the definitions doc, and >found out that >I cannot find agreements on a number of terms. This is the >first of a >set of eamils that will hopefully lead us to close the >definitions on >a few terms. >So this email is about "Participant". > >We have the odd definition that RFC 4353 lists participant >essentially >as a piece of software and not as a human. To Song Haibin, Steve >Botzko (and to me), Participants sounds like human, though. > >Several ways forward: > > 1. Use Participant in the 4353 sense only > 2. Use Participant in the sense of a human participating in a > telepresence session only. That would mean that there >can be many > participants at any endpoint, and endpoint can have >no participant > (empty room or webcam), and so forth. > 3. Use Participant in the sense of 2) above, and add >remark that if > 4353 Participant is meant, this will be explicitely mentioned. > >My preference is 1. 2 and 3 have too much potential for confusion. >Shame on 4353 for that. > >Opinions? > >Stephan > > > > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Wed Jun 1 15:39:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAF1E09B3 for ; Wed, 1 Jun 2011 15:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.575 X-Spam-Level: X-Spam-Status: No, score=-103.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRx5bdMgYdCd for ; Wed, 1 Jun 2011 15:39:29 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80D5EE06B5 for ; Wed, 1 Jun 2011 15:39:29 -0700 (PDT) Received: by vxg33 with SMTP id 33so302260vxg.31 for ; Wed, 01 Jun 2011 15:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F/lgwhYq7GqOaaGz81G9aquc8LHcoYKVkKObxTLpEnc=; b=bB4l7maqxT3UQumJbyWTpd3zXC8UyXGyIfzWkGTZo7RNRVmB1OYh/hPSxC6MXd4aEq mw22uhCFmvGxlxt/6xp1qqWwrQ4uugE6QWK70Qnc5OpLJ3DZw+e67NZrhoHp04l34di+ qorl0fQRC9IUgVzGRDTLvcCsLnsZvqxdRarTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lNyyu2CNTqQCG1vVf3+g11h7Ri8GJiqKEuE0QNHWomX/P3QUXJ8g+6hx5AMJI27yRV Kijd1iIIkYGd/lUMiQ1OF3L4jmPITAf4vn90pziGojYrHLfSsRCHDR4tKJg3y4Fsdz14 QkifPygZeXnukFwtxjvJbrr7+OyZImWDT1Zk0= MIME-Version: 1.0 Received: by 10.52.98.33 with SMTP id ef1mr68375vdb.23.1306967968706; Wed, 01 Jun 2011 15:39:28 -0700 (PDT) Received: by 10.52.158.39 with HTTP; Wed, 1 Jun 2011 15:39:28 -0700 (PDT) In-Reply-To: References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> <4DE6A0A3.7090009@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A407@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Jun 2011 17:39:28 -0500 Message-ID: From: Mary Barnes To: Paul Coverdale Content-Type: multipart/alternative; boundary=20cf307f354a81f06204a4ae31ee Cc: clue@ietf.org Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 22:39:31 -0000 --20cf307f354a81f06204a4ae31ee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the end, I think the context is what will be necessary to clarify the meaning (human, non-human physical entity or logical entity) whether we use participant or user, per my comment with regards to the XCON usage of the latter term. So, let's just pick one and ensure that it's clear in the context that it's used. Mary. On Wed, Jun 1, 2011 at 5:19 PM, Paul Coverdale wrot= e: > I wasn't familiar with RFC4353, so I took a quick look. It seems that the= y > did a great job of hi-jacking a perfectly good English word. > > E.G. > "Participant" - a person who takes part in or becomes involved in a > particular activity. > > So we will create a nice tautology if we talk about a human participant. > Unless we want to differentiate between in-human participants. > > If we are going to treat the RFC4353 definition of "participant" as > sacrosanct, then I would support "user" as the next best choice for CLUE > purposes. > > > ...Paul > > > > >-----Original Message----- > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > >Christer Holmberg > >Sent: Wednesday, June 01, 2011 5:24 PM > >To: Mary Barnes; Paul Kyzivat > >Cc: clue@ietf.org > >Subject: Re: [clue] Definitions: Participant > > > >Hi, > > > >If we go for the 4353 definition of "participant", when then talking > >about humans/users, I would prefer "user" instead of "human > >participant". > > > >Regards, > > > >Christer > > > >________________________________ > >From: Mary Barnes [mary.ietf.barnes@gmail.com] > >Sent: Thursday, June 02, 2011 12:00 AM > >To: Paul Kyzivat > >Cc: Christer Holmberg; clue@ietf.org > >Subject: Re: [clue] Definitions: Participant > > > >XCON also uses "participant" in the same context as RFC 4353. So, I > >think that consistency within the IETF context is more important than > >how other SDOs might use the term. References to humans in both RFC > >4353 and XCON are qualifications of "operator" and "participant" rather > >than a standalone term. I will also note that SIPREC documents use the > >term participant in the same context as RFC 4353, although there are > >cases where it is used to refer to the human. But, the context makes > >that clear. So, my recommendation is that we use "human participant" in > >cases where the qualification is necessary. > > > >We also use the term "user" in both RFC 4353 and XCON (and SIPREC) in > >the context of actions that would be performed by a human (e.g., > >keypresses), etc. However, that term is overloaded in that it also is > >used for the logical representation of the physical/human user in the > >data model/conference object. And, SIPREC seems to use "participant" and > >"user" interchangeably (3rd para in the Into of requirements when it's > >discussing notification and opt out of recording). > > > >So, I still think that "human participant" is the best choice when a > >qualification is necessary. > > > >Mary. > >(as an individual) > > > >On Wed, Jun 1, 2011 at 3:27 PM, Paul Kyzivat > >> wrote: > > > > > >On 6/1/2011 6:56 AM, Christer Holmberg wrote: > > > >Hi, > > > >In my ears, "particiapant" has always been associated with a human. > > > >Also, my understanding is that ITU-T defines participant as a human > >participating in a conference, > > > >Can you provide a reference? > >And, is it something CLUE wants/needs to reference? > > > > > >and I strongly think we should avoid identical wording with different > >meaning - it will only cause problems sooner or later. > > > >Which is why we are concerned about being consistent with RFC 4353. > > > >(We have a more difficult problem if we have dependency on documents > >that have conflicting definitions for the term.) > > > > Thanks, > > Paul > > > > > >Why can't we simply talk about "endpoint" or "client" when talking about > >the SIP device (whether it's a full blown telepresence room or a small > >mobile phone)? That's wording that people are used to, so I don't see > >why we need to come up with something new... > > > >Regards, > > > >Christer > > > > > > > > > > > > > >-----Original Message----- > >From: clue-bounces@ietf.org [mailto:clue- > >bounces@ietf.org] On > >Behalf Of Paul Kyzivat > >Sent: 1. kes=E4kuuta 2011 2:50 > >To: clue@ietf.org > >Subject: Re: [clue] Definitions: Participant > > > >I support using Participant in the 4353 sense. > >(Its really the only definition that most of the software can > >use in a useful way. E.g. the conference roster is about > >these automata. This becomes especially obvious when you have > >the same "person" showing up multiple times in the roster.) > > > >If there is need to talk about the human(s) associated with a > >participant, then it would make sense to define another term for that. > > > > Thanks, > > Paul (as individual) > > > >On 5/31/2011 7:03 PM, Stephan Wenger wrote: > >Hi all, > >I thought I would quickly rev the definitions doc, and > >found out that > >I cannot find agreements on a number of terms. This is the > >first of a > >set of eamils that will hopefully lead us to close the > >definitions on > >a few terms. > >So this email is about "Participant". > > > >We have the odd definition that RFC 4353 lists participant > >essentially > >as a piece of software and not as a human. To Song Haibin, Steve > >Botzko (and to me), Participants sounds like human, though. > > > >Several ways forward: > > > > 1. Use Participant in the 4353 sense only > > 2. Use Participant in the sense of a human participating in a > > telepresence session only. That would mean that there > >can be many > > participants at any endpoint, and endpoint can have > >no participant > > (empty room or webcam), and so forth. > > 3. Use Participant in the sense of 2) above, and add > >remark that if > > 4353 Participant is meant, this will be explicitely mentioned. > > > >My preference is 1. 2 and 3 have too much potential for confusion. > >Shame on 4353 for that. > > > >Opinions? > > > >Stephan > > > > > > > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > --20cf307f354a81f06204a4ae31ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the end, I think the context is what will be necessary to clarify the me= aning (human, non-human physical entity or logical entity) whether we use p= articipant or user, per my comment with regards to the XCON usage of the la= tter term. =A0So, let's just pick one and ensure that it's clear in= the context that it's used. =A0=A0

Mary.

On Wed, Jun 1, 2011 = at 5:19 PM, Paul Coverdale <coverdale@sympatico.ca> wrote:
I wasn't familiar with RFC4353, so I took a quick look. It seems that t= hey
did a great job of hi-jacking a perfectly good English word.

E.G.
"Participant" - a person who takes part in or becomes involved in= a
particular activity.

So we will create a nice tautology if we talk about a human participant. Unless we want to differentiate between in-human participants.

If we are going to treat the RFC4353 definition of "participant" = as
sacrosanct, then I would support "user" as the next best choice f= or CLUE
purposes.


...Paul



>-----Original Message-----
>From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
>Christer Holmberg
>Sent: Wednesday, June 01, 2011 5:24 PM
>To: Mary Barnes; Paul Kyzivat
>Cc: clue@ietf.org
>Subject: Re: [clue] Definitions: Part= icipant
>
>Hi,
>
>If we go for the 4353 definition of "participant", when then = talking
>about humans/users, I would prefer "user" instead of "hu= man
>participant".
>
>Regards,
>
>Christer
>
>________________________________
>From: Mary Barnes [mary.i= etf.barnes@gmail.com]
>Sent: Thursday, June 02, 2011 12:00 AM
>To: Paul Kyzivat
>Cc: Christer Holmberg; clue@ietf.org
>Subject: Re: [clue] Definitions: Participant
>
>XCON also uses "participant" in the same context as RFC 4353.= =A0So, I
>think that consistency within the IETF context is more important than >how other SDOs might use the term. =A0 References to humans in both RFC=
>4353 and XCON are qualifications of "operator" and "part= icipant" rather
>than a standalone term. =A0I will also note that SIPREC documents use t= he
>term participant in the same context as RFC 4353, although there are >cases where it is used to refer to the human. =A0But, the context makes=
>that clear. So, my recommendation is that we use "human participan= t" in
>cases where the qualification is necessary.
>
>We also use the term "user" in both RFC 4353 and XCON (and SI= PREC) in
>the context of actions that would be performed by a human (e.g.,
>keypresses), etc. However, that term is overloaded in that it also is >used for the logical representation of the physical/human user in the >data model/conference object. And, SIPREC seems to use "participan= t" and
>"user" interchangeably (3rd para in the Into of requirements = when it's
>discussing notification and opt out of recording).
>
>So, I still think that "human participant" is the best choice= when a
>qualification is necessary.
>
>Mary.
>(as an individual)
>
>On Wed, Jun 1, 2011 at 3:27 PM, Paul Kyzivat
><pkyzivat@cisco.com<mai= lto:pkyzivat@cisco.com>> wr= ote:
>
>
>On 6/1/2011 6:56 AM, Christer Holmberg wrote:
>
>Hi,
>
>In my ears, "particiapant" has always been associated with a = human.
>
>Also, my understanding is that ITU-T defines participant as a human
>participating in a conference,
>
>Can you provide a reference?
>And, is it something CLUE wants/needs to reference?
>
>
>and I strongly think we should avoid identical wording with different >meaning - it will only cause problems sooner or later.
>
>Which is why we are concerned about being consistent with RFC 4353.
>
>(We have a more difficult problem if we have dependency on documents >that have conflicting definitions for the term.)
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>
>Why can't we simply talk about "endpoint" or "client= " when talking about
>the SIP device (whether it's a full blown telepresence room or a sm= all
>mobile phone)? That's wording that people are used to, so I don'= ;t see
>why we need to come up with something new...
>
>Regards,
>
>Christer
>
>
>
>
>
>
>-----Original Message-----
>From: clue-bounces@ietf.org<mailto:clue-bounces@ietf.org<= /a>> [mailto:clue-
>bounces@ietf.org<mailto:clue-bounces@ietf.org>] On
>Behalf Of Paul Kyzivat
>Sent: 1. kes=E4kuuta 2011 2:50
>To: clue@ietf.org<mailto:clue@ietf.org>
>Subject: Re: [clue] Definitions: Participant
>
>I support using Participant in the 4353 sense.
>(Its really the only definition that most of the software can
>use in a useful way. E.g. the conference roster is about
>these automata. This becomes especially obvious when you have
>the same "person" showing up multiple times in the roster.) >
>If there is need to talk about the human(s) associated with a
>participant, then it would make sense to define another term for that.<= br> >
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul (as individual)
>
>On 5/31/2011 7:03 PM, Stephan Wenger wrote:
>Hi all,
>I thought I would quickly rev the definitions doc, and
>found out that
>I cannot find agreements on a number of terms. This is the
>first of a
>set of eamils that will hopefully lead us to close the
>definitions on
>a few terms.
>So this email is about "Participant".
>
>We have the odd definition that RFC 4353 lists participant
>essentially
>as a piece of software and not as a human. To Song Haibin, Steve
>Botzko (and to me), Participants sounds like human, though.
>
>Several ways forward:
>
> =A0 1. Use Participant in the 4353 sense only
> =A0 2. Use Participant in the sense of a human participating in a
> =A0 =A0 =A0telepresence session only. That would mean that there
>can be many
> =A0 =A0 =A0participants at any endpoint, and endpoint can have
>no participant
> =A0 =A0 =A0(empty room or webcam), and so forth.
> =A0 3. Use Participant in the sense of 2) above, and add
>remark that if
> =A0 =A0 =A04353 Participant is meant, this will be explicitely mention= ed.
>
>My preference is 1. 2 and 3 have too much potential for confusion.
>Shame on 4353 for that.
>
>Opinions?
>
>Stephan
>
>
>
>
>_______________________________________________
>clue mailing list
>clue@ietf.org<mailto:clue@ietf.org>
>https://www.ietf.org/mailman/listinfo/clue
>_______________________________________________
>clue mailing list
>clue@ietf.org<mailto:clue@ietf.org>
>https://www.ietf.org/mailman/listinfo/clue
>
>_______________________________________________
>clue mailing list
>clue@ietf.org<mailto:clue@ietf.org>
>https://www.ietf.org/mailman/listinfo/clue
>
>_______________________________________________
>clue mailing list
>clue@ietf.org
>https://www.ietf.org/mailman/listinfo/clue


--20cf307f354a81f06204a4ae31ee-- From pkyzivat@cisco.com Wed Jun 1 16:45:21 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70993E0760 for ; Wed, 1 Jun 2011 16:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.388 X-Spam-Level: X-Spam-Status: No, score=-110.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9B2inZUD+4n for ; Wed, 1 Jun 2011 16:45:20 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 37281E0678 for ; Wed, 1 Jun 2011 16:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=7707; q=dns/txt; s=iport; t=1306971920; x=1308181520; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iHyKrTaDcEvxP4xvh8hPuCj+yZQScru0/tvuuuN+er4=; b=Hw3VqT72EbMUQfN254v4rZgPrsXBRBLwTiQQ1C4Lw2HhU/+rWueXwnmh MFKwEE7u92TFLqOqsoDnBrc6pNxH6u3DnZvXr8dzANNJMaYQvn5mmmJMU fXdEdwxm798lCNrRkC0FTQP0VJFNbB1ugw+5/CXAOLk4Jj46Odde1qzyV c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAGjO5k2tJV2b/2dsb2JhbABFDpdZjll3iHGhE51hgxeDCQSQVoRDhC2GWA X-IronPort-AV: E=Sophos;i="4.65,305,1304294400"; d="scan'208";a="706817962" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-6.cisco.com with ESMTP; 01 Jun 2011 23:45:18 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p51NjHbP014973; Wed, 1 Jun 2011 23:45:17 GMT Message-ID: <4DE6CF0D.8050104@cisco.com> Date: Wed, 01 Jun 2011 19:45:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Coverdale References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> <4DE6A0A3.7090009@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A407@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 23:45:21 -0000 On 6/1/2011 6:19 PM, Paul Coverdale wrote: > I wasn't familiar with RFC4353, so I took a quick look. It seems that they > did a great job of hi-jacking a perfectly good English word. Well, if corporations can be people wrt free speech, then UAs can be participants in conferences. :-) (In XCON conferences anyway. I guess IETF82 is conference too, that has human participants - though they are more properly called "registrants" I think.) Pretty much all of the conference/xcon stuff is about interactions among software entities. So its makes perfect sense to me to call those UAs that are involved in a conference 'participants' in the conference. (The people only interact with their UA.) Even in CLUE, afaik the human participants will be pretty hard to identify in the resulting protocols. They are some blotchy things that show up in the field of view of cameras, but most likely the software can't distinguish a participant from an empty chair. And while its possible to decide which camera to display based on where there is audio energy, will clue facilitate identifying *who* is speaking, as distinct from which microphone the audio is coming from? And regarding anonymous participants, I believe that those are the UAs whose From address is sip:anonymous@anonymous.invalid. Thanks, Paul > E.G. > "Participant" - a person who takes part in or becomes involved in a > particular activity. > > So we will create a nice tautology if we talk about a human participant. > Unless we want to differentiate between in-human participants. > > If we are going to treat the RFC4353 definition of "participant" as > sacrosanct, then I would support "user" as the next best choice for CLUE > purposes. > > > ...Paul > > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christer Holmberg >> Sent: Wednesday, June 01, 2011 5:24 PM >> To: Mary Barnes; Paul Kyzivat >> Cc: clue@ietf.org >> Subject: Re: [clue] Definitions: Participant >> >> Hi, >> >> If we go for the 4353 definition of "participant", when then talking >> about humans/users, I would prefer "user" instead of "human >> participant". >> >> Regards, >> >> Christer >> >> ________________________________ >> From: Mary Barnes [mary.ietf.barnes@gmail.com] >> Sent: Thursday, June 02, 2011 12:00 AM >> To: Paul Kyzivat >> Cc: Christer Holmberg; clue@ietf.org >> Subject: Re: [clue] Definitions: Participant >> >> XCON also uses "participant" in the same context as RFC 4353. So, I >> think that consistency within the IETF context is more important than >> how other SDOs might use the term. References to humans in both RFC >> 4353 and XCON are qualifications of "operator" and "participant" rather >> than a standalone term. I will also note that SIPREC documents use the >> term participant in the same context as RFC 4353, although there are >> cases where it is used to refer to the human. But, the context makes >> that clear. So, my recommendation is that we use "human participant" in >> cases where the qualification is necessary. >> >> We also use the term "user" in both RFC 4353 and XCON (and SIPREC) in >> the context of actions that would be performed by a human (e.g., >> keypresses), etc. However, that term is overloaded in that it also is >> used for the logical representation of the physical/human user in the >> data model/conference object. And, SIPREC seems to use "participant" and >> "user" interchangeably (3rd para in the Into of requirements when it's >> discussing notification and opt out of recording). >> >> So, I still think that "human participant" is the best choice when a >> qualification is necessary. >> >> Mary. >> (as an individual) >> >> On Wed, Jun 1, 2011 at 3:27 PM, Paul Kyzivat >> > wrote: >> >> >> On 6/1/2011 6:56 AM, Christer Holmberg wrote: >> >> Hi, >> >> In my ears, "particiapant" has always been associated with a human. >> >> Also, my understanding is that ITU-T defines participant as a human >> participating in a conference, >> >> Can you provide a reference? >> And, is it something CLUE wants/needs to reference? >> >> >> and I strongly think we should avoid identical wording with different >> meaning - it will only cause problems sooner or later. >> >> Which is why we are concerned about being consistent with RFC 4353. >> >> (We have a more difficult problem if we have dependency on documents >> that have conflicting definitions for the term.) >> >> Thanks, >> Paul >> >> >> Why can't we simply talk about "endpoint" or "client" when talking about >> the SIP device (whether it's a full blown telepresence room or a small >> mobile phone)? That's wording that people are used to, so I don't see >> why we need to come up with something new... >> >> Regards, >> >> Christer >> >> >> >> >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue- >> bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 1. kesäkuuta 2011 2:50 >> To: clue@ietf.org >> Subject: Re: [clue] Definitions: Participant >> >> I support using Participant in the 4353 sense. >> (Its really the only definition that most of the software can >> use in a useful way. E.g. the conference roster is about >> these automata. This becomes especially obvious when you have >> the same "person" showing up multiple times in the roster.) >> >> If there is need to talk about the human(s) associated with a >> participant, then it would make sense to define another term for that. >> >> Thanks, >> Paul (as individual) >> >> On 5/31/2011 7:03 PM, Stephan Wenger wrote: >> Hi all, >> I thought I would quickly rev the definitions doc, and >> found out that >> I cannot find agreements on a number of terms. This is the >> first of a >> set of eamils that will hopefully lead us to close the >> definitions on >> a few terms. >> So this email is about "Participant". >> >> We have the odd definition that RFC 4353 lists participant >> essentially >> as a piece of software and not as a human. To Song Haibin, Steve >> Botzko (and to me), Participants sounds like human, though. >> >> Several ways forward: >> >> 1. Use Participant in the 4353 sense only >> 2. Use Participant in the sense of a human participating in a >> telepresence session only. That would mean that there >> can be many >> participants at any endpoint, and endpoint can have >> no participant >> (empty room or webcam), and so forth. >> 3. Use Participant in the sense of 2) above, and add >> remark that if >> 4353 Participant is meant, this will be explicitely mentioned. >> >> My preference is 1. 2 and 3 have too much potential for confusion. >> Shame on 4353 for that. >> >> Opinions? >> >> Stephan >> >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing 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 coverdale@sympatico.ca Wed Jun 1 17:49:03 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A76E07CA for ; Wed, 1 Jun 2011 17:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlZ37TegyMgy for ; Wed, 1 Jun 2011 17:49:03 -0700 (PDT) Received: from blu0-omc4-s8.blu0.hotmail.com (blu0-omc4-s8.blu0.hotmail.com [65.55.111.147]) by ietfa.amsl.com (Postfix) with ESMTP id DBEE9E06E6 for ; Wed, 1 Jun 2011 17:49:02 -0700 (PDT) Received: from BLU0-SMTP50 ([65.55.111.137]) by blu0-omc4-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 17:49:02 -0700 X-Originating-IP: [65.93.174.101] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([65.93.174.101]) by BLU0-SMTP50.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 17:49:01 -0700 From: Paul Coverdale To: "'Paul Kyzivat'" References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> <4DE6A0A3.7090009@cisco.com>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A407@ESESSCMS0356.eemea.ericsson.se> <4DE6CF0D.8050104@cisco.com> In-Reply-To: <4DE6CF0D.8050104@cisco.com> Date: Wed, 1 Jun 2011 20:48:54 -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: Acwgtful7GZchzauRXesaYkPcku3fAABxlgA Content-Language: en-us X-OriginalArrivalTime: 02 Jun 2011 00:49:01.0473 (UTC) FILETIME=[DD3FE910:01CC20BE] Cc: clue@ietf.org Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 00:49:03 -0000 >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: Wednesday, June 01, 2011 7:45 PM >To: Paul Coverdale >Cc: 'Christer Holmberg'; 'Mary Barnes'; clue@ietf.org >Subject: Re: [clue] Definitions: Participant > > >(In XCON conferences anyway. I guess IETF82 is conference too, that has >human participants - though they are more properly called "registrants" >I think.) > It's a philosophical point, I suppose, but would the typical "participant" in IETF conferences consider themselves as a "person", or as a "software element that connects a user or automata to a conference". Actually, RFC 4353 got it right in one definition. I've noticed a few "Conference-Unaware Participants". ...Paul From arnoud.vanwijk@realtimetext.org Mon Jun 6 02:57:33 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F323011E80F8 for ; Mon, 6 Jun 2011 02:57:32 -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_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GPEB6lF9iXo for ; Mon, 6 Jun 2011 02:57:31 -0700 (PDT) Received: from mx-in01.nouzelle.com (mx-in01.nouzelle.com [87.119.194.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE1D11E80EC for ; Mon, 6 Jun 2011 02:57:31 -0700 (PDT) Received: from internal02.nouzelle.com (internal02.nouzelle.local [172.29.32.13]) by mx-in01.nouzelle.com (Postfix) with ESMTP id 8D2D0125BA1; Mon, 6 Jun 2011 11:56:37 +0200 (CEST) Received: from mailscan.nouzelle.com (unknown [172.29.32.10]) by internal02.nouzelle.com (Postfix) with ESMTP id E2B6E10219AB7; Mon, 6 Jun 2011 11:57:28 +0200 (CEST) X-Virus-Scanned: by amavisd-new at nouzelle.com Received: from internal02.nouzelle.com ([172.29.32.13]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id ceOIlEyxzckc; Mon, 6 Jun 2011 11:57:27 +0200 (CEST) Received: from arnoud-van-wijks-macbook-pro.local (541BD3CF.cm-5-4d.dynamic.ziggo.nl [84.27.211.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by internal02.nouzelle.com (Postfix) with ESMTPSA id 649C410219AC1; Mon, 6 Jun 2011 11:57:27 +0200 (CEST) Message-ID: <4DECA486.9000702@realtimetext.org> Date: Mon, 06 Jun 2011 11:57:26 +0200 From: Arnoud van Wijk Organization: R3TF User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Mike Hammer (hmmr)" References: <4DE0083A.3040102@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2A65D7@ESESSCMS0356.eemea.ericsson.se><4DE4E7BF.8070301@cisco.com> <4DE60A5E.105@realtimetext.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] 2 draft covering real-time text relevant for conferencing/ multiple participants and telepresence X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arnoud.vanwijk@realtimetext.org List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 09:57:33 -0000 Hi Mike, Good questions actually. We have to visualize how to have Real-Time Text (RTT) included with telepresence. comments inline.. > Is that keyboard left and keyboard right? :) Actually, not a bad comment. If you have a conference with say 3 people. The camera will zoom/focus o the speaker based on microphone activity. The same thing is also possible when the speaker uses a keyboard. When typing with RTT, the camera will zoom/focus on the typing person. Use 3 wireless keyboards here. > I took a quick look through the referenced ID and did not see reference > to audio and video feeds in a multi-party situation. With TP, the > system may be designed to select one of multiple cameras to display when > there are more participants than displays. So, is your intent that when > a 'texter' is 'speaking' that the keyboard input should direct the > camera on him/her to be the one selected for display? Yes. :-) For example. > How do you identify the text-speaker from someone just doing email? Assign a hot key for RTT/TP activity for example. That key can also be used as a raising the hand signal to the conference floor manager as well. > Does the rate of texting translate to volume for selection of video > feed? We have slow typist and fast typists, I think the duration of activity can be used parallel as to volume yes. But I think we have to test this kind of scenarios on what is most convenient/realistic. Or even when 3 people type..have 3 mosaics screens and the longest or most text typing person will grow full screen. I am just brainstorming a bit here. > Is the text intended to be overwritten on the screen, or is there a > separate screen? Both. Depending on what is preferred by the users. I think with discussions where the camera moves between several users, the RTT can be used as an overlay on the video or at the bottom. But at the same time you can use the text on a separate screen and when the camera/audio is locked on a certain user, the user id will be added to the RTT on the common screen for example. > If there is a separate display screen, do all 'text-speakers' get equal > time, or does an algorithm select which one is displayed there? All get equal time if a separate display is used for text. The text preview draft does give an example of multiple users with RTT. As in figure 3 for example https://datatracker.ietf.org/doc/draft-hellstrom-textpreview/?include_text=1 > If there is a conflict between an audio feed and a text feed for > attention, how do you decide which video is displayed? That depends on the users participating. I encounter the issue myself that I have a hard time to insert myself in a discussion because my text get overlooked or takes more time to be noticed. If you would allow user tags per stream identifying the speaker, you can perhaps add a flag that this person talks by text. In such case the RTT may have the highest priority in the media stream selection. The RTT user must be perfectly aware of this then. > Are there signers or text to audio speakers possible? Sure, we have to incorporate them in the scenarios and work out the details. It is all about behavior and conference handling /protocol between the people and the system. But a signer can wave to the camera and with the rapid development of motion sensors like the kinect and similar, that is not really an obstacle technically. We just need to add it to the possible system behavior. > Lots of questions. Much appreciated. Questions will help. I still have to think more on Total Conversation with TP but the addition of RTT is and will be SO important! I also like that the telepresence can be used to enable remote sign and speech to text interpretation services. The biggest problem is that a remote interpreter cannot see who is talking and who the person is. And with video added the interpreter can see the body language to see if the speaker is joking or angry or frustrated. Such things are always very well expressible via sign. :-) > I think you should contribute to CLUE. Yes I agree. The more I am learning about what CLUE wants to do the more I see how important this work is. And to inCLUdE persons who use alternative modes of communication besides voice. > However, I would question bolting on a solution after the fact with > separate drafts. > > Perhaps, all input and output devices should be integrated into the base > drafts. I agree. By standard all CLUE work should use Total Conversation. Then we have audio and video as it has been described already but also include Real-Time Text! And use cases can include signing users (wave to camera or sensor to get focus on the signing user), type text to get the focus/"raising hand" and where you have a remote speech to text/ sign language interpreter participating in the conference session. etc etc (you do not need to be deaf or speech impaired, since you can also have a remote Spanish to English interpreter participating, and the output is via text and audio). cheers Arnoud > Mike > > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Arnoud van Wijk > Sent: Wednesday, June 01, 2011 5:46 AM > To: clue@ietf.org > Subject: [clue] 2 draft covering real-time text relevant for > conferencing/ multiple participants and telepresence > > Hi all, > I am getting a clue about CLUE. :-) > This is an excellent WG covering what we need for a good telePRESENCE > without hurdles. > If I communicate remote with other persons, I'd like to "forget" that I > participate remote. There should be no limitations in the ability to > communicate. > > The focus is at this moment on audio and video, lets make real-time text > > also a standard media to be used in all the work and scenarios as well > with CLUE. > The use of Total Conversation, where audio, video and real-time text are > > presented and available simultaneously will actually optimize the > communication with others. > As a deaf person, I need lipreading and real-time text together, others > sign language, others having real-time text as support if the language > used in the conference is not your native language and have the text in > your own language. > Or even to talk and discuss with others during the conference with > real-time text while listening to the main conference. > > More about real-time text can be found at: http://www.realtimetext.org > but most of you are already familiar with it. > > It is not only for persons with a hearing disability, it is for all > breathing humans who want to communicate (and for a few robots out here > :-) ) > But using Total Conversation will remove the biggest Internet > (telephony/conferencing) communication hurdle for persons who are deaf, > hard of hearing or have a speech impairment. And that is not a joke. > > We have submitted now 2 drafts that are what I feel quite valuable for > CLUE. > > Text media handling in RTP based real-time conferences > https://datatracker.ietf.org/doc/draft-hellstrom-text-conference/ > > and > Presentation of Text Conversation in real-time and en-bloc form > https://datatracker.ietf.org/doc/draft-hellstrom-textpreview/ > > How would you feel about continuing these drafts under the CLUE banner? > I am looking forward to your feedback and comments and well...anything > that you throw at me and my fellow authors :-) > > Thank you. > > Sincerely > > Arnoud van Wijk > > PS we can also help with more insight on Total Conversation regarding > quality of the video, camera position and the angle of the view (for > example head for lipreading, upper body and sufficient area around the > person for sign language etc.). > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From arnoud.vanwijk@realtimetext.org Mon Jun 6 03:05:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC01D11E808F for ; Mon, 6 Jun 2011 03:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCF4LLGJBQUf for ; Mon, 6 Jun 2011 03:05:46 -0700 (PDT) Received: from mx-in01.nouzelle.com (mx-in01.nouzelle.com [87.119.194.132]) by ietfa.amsl.com (Postfix) with ESMTP id 557EF11E808C for ; Mon, 6 Jun 2011 03:05:45 -0700 (PDT) Received: from internal02.nouzelle.com (internal02.nouzelle.local [172.29.32.13]) by mx-in01.nouzelle.com (Postfix) with ESMTP id 11530125B2D; Mon, 6 Jun 2011 12:04:41 +0200 (CEST) Received: from mailscan.nouzelle.com (unknown [172.29.32.10]) by internal02.nouzelle.com (Postfix) with ESMTP id 6550910219AC1; Mon, 6 Jun 2011 12:05:32 +0200 (CEST) X-Virus-Scanned: by amavisd-new at nouzelle.com Received: from internal02.nouzelle.com ([172.29.32.13]) by mailscan.nouzelle.com (mailscan.nouzelle.com [172.29.32.10]) (amavisd-new, port 10026) with ESMTP id 2ggt5qB7BPUE; Mon, 6 Jun 2011 12:05:31 +0200 (CEST) Received: from arnoud-van-wijks-macbook-pro.local (541BD3CF.cm-5-4d.dynamic.ziggo.nl [84.27.211.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by internal02.nouzelle.com (Postfix) with ESMTPSA id 3CA0D10219ABB; Mon, 6 Jun 2011 12:05:31 +0200 (CEST) Message-ID: <4DECA66A.20807@realtimetext.org> Date: Mon, 06 Jun 2011 12:05:30 +0200 From: Arnoud van Wijk Organization: R3TF User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mary Barnes References: <4DE0083A.3040102@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2A65D7@ESESSCMS0356.eemea.ericsson.se> <4DE4E7BF.8070301@cisco.com> <4DE60A5E.105@realtimetext.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090305090700070204090406" Cc: clue@ietf.org Subject: Re: [clue] 2 draft covering real-time text relevant for conferencing/ multiple participants and telepresence X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arnoud.vanwijk@realtimetext.org List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 10:05:47 -0000 This is a multi-part message in MIME format. --------------090305090700070204090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Mary, I see an overlap between part what the drafts makes possible and with CLUE. As you can see in another mail with Mike, the addition of Real-Time Text (RTT) as part of CLUE basis documents and scenarios will be important to ensure maximal inclusion and presence. With what we will learn here and with the scenarios/use cases. We can also take such insights and considerations in the 2 drafts. I encourage you all to give feedback on those 2 drafts in the DISPATCH list. I will appreciate that. It does not need to be as CLUE, but I have seen many AVT and XCON people here who may be the best WGs to adopt the drafts. Or from any other WG who feels the drafts are useful. And yes lets discuss them on the DISPATCH list. Thanks! Arnoud On 01-06-11 18:12, Mary Barnes wrote: > Given that this work has been submitted to DISPATCH for discussion, > the thread of discussion needs to occur on the DISPATCH WG mailing > list - in particular the requirements for this solution. > > That all said, if there is anything in the current set of CLUE > requirements that would prevent this functionality in the future, > feedback of that nature would be useful. > > Regards, > Mary. > CLUE WG co-chair > > On Wed, Jun 1, 2011 at 4:46 AM, Arnoud van Wijk > > wrote: > > Hi all, > I am getting a clue about CLUE. :-) > This is an excellent WG covering what we need for a good > telePRESENCE without hurdles. > If I communicate remote with other persons, I'd like to "forget" > that I participate remote. There should be no limitations in the > ability to communicate. > > The focus is at this moment on audio and video, lets make > real-time text also a standard media to be used in all the work > and scenarios as well with CLUE. > The use of Total Conversation, where audio, video and real-time > text are presented and available simultaneously will actually > optimize the communication with others. > As a deaf person, I need lipreading and real-time text together, > others sign language, others having real-time text as support if > the language used in the conference is not your native language > and have the text in your own language. > Or even to talk and discuss with others during the conference with > real-time text while listening to the main conference. > > More about real-time text can be found at: > http://www.realtimetext.org but most of you are already familiar > with it. > > It is not only for persons with a hearing disability, it is for > all breathing humans who want to communicate (and for a few robots > out here :-) ) > But using Total Conversation will remove the biggest Internet > (telephony/conferencing) communication hurdle for persons who are > deaf, hard of hearing or have a speech impairment. And that is not > a joke. > > We have submitted now 2 drafts that are what I feel quite valuable > for CLUE. > > Text media handling in RTP based real-time conferences > https://datatracker.ietf.org/doc/draft-hellstrom-text-conference/ > > and > Presentation of Text Conversation in real-time and en-bloc form > https://datatracker.ietf.org/doc/draft-hellstrom-textpreview/ > > How would you feel about continuing these drafts under the CLUE > banner? > I am looking forward to your feedback and comments and > well...anything that you throw at me and my fellow authors :-) > > Thank you. > > Sincerely > > Arnoud van Wijk > > PS we can also help with more insight on Total Conversation > regarding quality of the video, camera position and the angle of > the view (for example head for lipreading, upper body and > sufficient area around the person for sign language etc.). > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --------------090305090700070204090406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mary,
I see an overlap between part what the drafts makes possible and with CLUE.
As you can see in another mail with Mike, the addition of Real-Time Text (RTT) as part of CLUE basis documents and scenarios will be important to ensure maximal inclusion and presence.

With what we will learn here and with the scenarios/use cases. We can also take such insights and considerations in the 2 drafts.

I encourage you all to give feedback on those 2 drafts in the DISPATCH list. I will appreciate that. It does not need to be as CLUE, but I have seen many AVT and XCON people here who may be the best WGs to adopt the drafts.
Or from any other WG who feels the drafts are useful.

And yes lets discuss them on the DISPATCH list.
Thanks!

Arnoud

On 01-06-11 18:12, Mary Barnes wrote:
Given that this work has been submitted to DISPATCH for discussion,  the thread of discussion needs to occur on the DISPATCH WG mailing list - in particular the requirements for this solution. 

That all said, if there is anything in the current set of CLUE requirements that would prevent this functionality in the future, feedback of that nature would be useful. 

Regards,
Mary.
CLUE WG co-chair

On Wed, Jun 1, 2011 at 4:46 AM, Arnoud van Wijk <arnoud.vanwijk@realtimetext.org> wrote:
Hi all,
I am getting a clue about CLUE. :-)
This is an excellent WG covering what we need for a good telePRESENCE without hurdles.
If I communicate remote with other persons, I'd like to "forget" that I participate remote. There should be no limitations in the ability to communicate.

The focus is at this moment on audio and video, lets make real-time text also a standard media to be used in all the work and scenarios as well with CLUE.
The use of Total Conversation, where audio, video and real-time text are presented and available simultaneously will actually optimize the communication with others.
As a deaf person, I need lipreading and real-time text together, others sign language, others having real-time text as support if the language used in the conference is not your native language and have the text in your own language.
Or even to talk and discuss with others during the conference with real-time text while listening to the main conference.

More about real-time text can be found at: http://www.realtimetext.org but most of you are already familiar with it.

It is not only for persons with a hearing disability, it is for all breathing humans who want to communicate (and for a few robots out here :-) )
But using Total Conversation will remove the biggest Internet (telephony/conferencing) communication hurdle for persons who are deaf, hard of hearing or have a speech impairment. And that is not a joke.

We have submitted now 2 drafts that are what I feel quite valuable for CLUE.

Text media handling in RTP based real-time conferences
https://datatracker.ietf.org/doc/draft-hellstrom-text-conference/

and
Presentation of Text Conversation in real-time and en-bloc form
https://datatracker.ietf.org/doc/draft-hellstrom-textpreview/

How would you feel about continuing these drafts under the CLUE banner?
I am looking forward to your feedback and comments and well...anything that you throw at me and my fellow authors :-)

Thank you.

Sincerely

Arnoud van Wijk

PS we can also help with more insight on Total Conversation regarding quality of the video, camera position and the angle of the view (for example head for lipreading, upper body and sufficient area around the person for sign language etc.).

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

--------------090305090700070204090406-- From allyn@cisco.com Wed Jun 8 18:50:13 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA89511E80E4 for ; Wed, 8 Jun 2011 18:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWyaUpzUl+-P for ; Wed, 8 Jun 2011 18:50:13 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1C611E8084 for ; Wed, 8 Jun 2011 18:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=2518; q=dns/txt; s=iport; t=1307584213; x=1308793813; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=GZqBVf0N+XDCYswXE4W8zRvO70FDCR/TADTwDi+Bnb0=; b=OGunjdn29DFVj5WZR3n588sF1inWAlHJR6L949/4tAHgVb597eth+s4i x7WQUjrUUvpZHjC4DS+mB71u++ieIHRQr2DzxfGdnsHucFK7AkLuKO5Mk bL/YiTxjoSIkqW2zprEXvE/PyU8wj50egywH3HIV2vc+yNJyFltRj+c8S U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngBAMUl8E2rRDoJ/2dsb2JhbABShEmSfEGNNHt3qUaNEJB0gSuDboEKBIcEjnOLFg X-IronPort-AV: E=Sophos;i="4.65,340,1304294400"; d="scan'208";a="333178809" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 09 Jun 2011 01:50:12 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p591oCDn002832; Thu, 9 Jun 2011 01:50:12 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Jun 2011 18:50:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 8 Jun 2011 18:50:05 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0494A190@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-romanow-clue-telepresence-requirements-03.txt Thread-Index: AcwmRyurwoq3Gp8rT+WBXv6wTj3SFgAAAx+A From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 09 Jun 2011 01:50:12.0718 (UTC) FILETIME=[925FB0E0:01CC2647] Subject: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 01:50:14 -0000 Rm9sa3MsDQpIZXJlIGlzIGEgbmV3IGRyYWZ0IG9mIG15IENMVUUgcmVxdWlyZW1lbnRzIGRyYWZ0 LiBTdGV2ZSBCb3R6a28gYW5kIE1hcmsgR29yeXppbnNraSBhcmUgY28tYXV0aG9ycy4NCg0KVGhp cyBkcmFmdCBmb2N1c2VkIG9ubHkgb24gdGhlIFJlcXVpcmVtZW50cyBzZWN0aW9uLCBub3Qgb24g dGhlIG90aGVyIHNlY3Rpb25zIChJbnRybyBhbmQgUHJvYmxlbSBTdGF0ZW1lbnQpLiBUaGUgZGVm aW5pdGlvbnMgYXJlIHRha2VuIGZyb20gU3RlcGhhbuKAmXMgZHJhZnQuDQoNClRoZSBtYWluIGdv YWwgb2YgdGhpcyBkcmFmdCBpcyB0byBleHByZXNzIHJlcXVpcmVtZW50cyBwcmVjaXNlbHkgZW5v dWdoIHRvIGhhdmUgYSBwcm9kdWN0aXZlIGRpc2N1c3Npb24tIGFuZCBub3Qgc28gc3BlY2lmaWNh bGx5IGFzIHRvIGRlc2lnbiB0aGUgc29sdXRpb24gd2l0aGluIHRoZSByZXF1aXJlbWVudHMgZG9j dW1lbnQuDQoNCkV2ZXJ5b25lIHdpbGwgaGF2ZSBwYXJ0aWN1bGFyIHRoaW5ncyB0aGV5IHdhbnQg dG8gbWFrZSBzdXJlIGFyZSBjb3ZlcmVkLiBUaGlzIGlzIGdvb2QuIEhvcGVmdWxseSwgdGhlIHJl cXVpcmVtZW50cyBhcmUgZ2VuZXJhbCBlbm91Z2ggdG8gY292ZXIgb3VyIHNwZWNpZmljIHJlcXVp cmVtZW50cyDigJMgd2hlcmUgbm90LCBuZXcgd2VsbC1zcGVjaWZpZWQgcmVxdWlyZW1lbnRzIGNh biBiZSBhZGRlZC4NCg0KV2XigJlsbCBleHBlY3QgcGxlbnR5IG9mIGNvbnZlcnNhdGlvbi0NCg0K VGhhbmtzLA0KQWxseW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBXZWRuZXNkYXksIEp1bmUgMDgsIDIwMTEgNjo0NyBQTQ0KVG86IEFsbHluIFJvbWFub3cg KGFsbHluKQ0KQ2M6IEFsbHluIFJvbWFub3cgKGFsbHluKTsgc3RlcGhlbi5ib3R6a29AcG9seWNv bS5jb207IG1hcmsuZ29yenluc2tpQGhwLmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvcmRyYWZ0LXJvbWFub3ctY2x1ZS10ZWxlcHJlc2VuY2UtcmVxdWlyZW1lbnRzLTAz LnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcm9tYW5vdy1jbHVlLXRlbGVwcmVz ZW5jZS1yZXF1aXJlbWVudHMtMDMudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgQWxseW4gUm9tYW5vdyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZp bGVuYW1lOgkgZHJhZnQtcm9tYW5vdy1jbHVlLXRlbGVwcmVzZW5jZS1yZXF1aXJlbWVudHMNClJl dmlzaW9uOgkgMDMNClRpdGxlOgkJIFJlcXVpcmVtZW50cyBmb3IgVGVsZXByZXNlbmNlIE11bHRp LVN0cmVhbXMNCkNyZWF0aW9uIGRhdGU6CSAyMDExLTA2LTA5DQpXRyBJRDoJCSBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTINCg0KQWJzdHJhY3Q6DQogICBUaGlzIG1l bW8gZGlzY3Vzc2VzIHRoZSByZXF1aXJlbWVudHMgZm9yIGEgc3BlY2lmaWNhdGlvbiB0aGF0IGVu YWJsZXMNCiAgIHRlbGVwcmVzZW5jZSBpbnRlcm9wZXJhYmlsaXR5LCBieSBkZXNjcmliaW5nIHRo ZSByZWxhdGlvbnNoaXAgYmV0d2Vlbg0KICAgbXVsdGlwbGUgUlRQIHN0cmVhbXMuICBJbiBhZGRp dGlvbiwgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZA0KICAgZGVmaW5pdGlvbnMgYXJlIGFsc28g Y292ZXJlZCBoZXJlaW4uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0K From christer.holmberg@ericsson.com Thu Jun 9 07:09:25 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F55421F8546 for ; Thu, 9 Jun 2011 07:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8fLG93+rwvs for ; Thu, 9 Jun 2011 07:09:25 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6A821F851C for ; Thu, 9 Jun 2011 07:09:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-07-4df0d41236a1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BA.BB.09774.214D0FD4; Thu, 9 Jun 2011 16:09:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 9 Jun 2011 16:09:22 +0200 From: Christer Holmberg To: "Allyn Romanow (allyn)" , "clue@ietf.org" Date: Thu, 9 Jun 2011 16:09:20 +0200 Thread-Topic: New Version Notification for draft-romanow-clue-telepresence-requirements-03.txt - REQMT-12 Thread-Index: AcwmRyurwoq3Gp8rT+WBXv6wTj3SFgAAAx+AABnc1tA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3600BE@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0494A190@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0494A190@xmb-sjc-221.amer.cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] New Version Notification for draft-romanow-clue-telepresence-requirements-03.txt - REQMT-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:09:25 -0000 Hi, REQMT-12 still mentions "CLUE". "REQMT-12: The solution MUST support a mechanism for determining whether or not an endpoint or MCU is capable of CLUE." I would suggesting to change that to "telepresence extensions", as in REQMT= -11. Regards, Christer =20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of Allyn Romanow (allyn) > Sent: 9. kes=E4kuuta 2011 4:50 > To: clue@ietf.org > Subject: [clue] FW: New Version Notification for=20 > draft-romanow-clue-telepresence-requirements-03.txt >=20 > Folks, > Here is a new draft of my CLUE requirements draft. Steve=20 > Botzko and Mark Goryzinski are co-authors. >=20 > This draft focused only on the Requirements section, not on=20 > the other sections (Intro and Problem Statement). The=20 > definitions are taken from Stephan's draft. >=20 > The main goal of this draft is to express requirements=20 > precisely enough to have a productive discussion- and not so=20 > specifically as to design the solution within the=20 > requirements document. >=20 > Everyone will have particular things they want to make sure=20 > are covered. This is good. Hopefully, the requirements are=20 > general enough to cover our specific requirements - where=20 > not, new well-specified requirements can be added. >=20 > We'll expect plenty of conversation- >=20 > Thanks, > Allyn >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, June 08, 2011 6:47 PM > To: Allyn Romanow (allyn) > Cc: Allyn Romanow (allyn); stephen.botzko@polycom.com;=20 > mark.gorzynski@hp.com > Subject: New Version Notification=20 > fordraft-romanow-clue-telepresence-requirements-03.txt >=20 > A new version of I-D,=20 > draft-romanow-clue-telepresence-requirements-03.txt has been=20 > successfully submitted by Allyn Romanow and posted to the=20 > IETF repository. >=20 > Filename: draft-romanow-clue-telepresence-requirements > Revision: 03 > Title: Requirements for Telepresence Multi-Streams > Creation date: 2011-06-09 > WG ID: Individual Submission > Number of pages: 12 >=20 > Abstract: > This memo discusses the requirements for a specification=20 > that enables > telepresence interoperability, by describing the=20 > relationship between > multiple RTP streams. In addition, the problem statement and > definitions are also covered herein. >=20 > =20 > =20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > = From mary.ietf.barnes@gmail.com Thu Jun 9 07:21:27 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAF311E80B7 for ; Thu, 9 Jun 2011 07:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94W7QGi59YRh for ; Thu, 9 Jun 2011 07:21:25 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E58E511E808B for ; Thu, 9 Jun 2011 07:21:24 -0700 (PDT) Received: by qyk29 with SMTP id 29so919847qyk.10 for ; Thu, 09 Jun 2011 07:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MXIjLKVJG65CQ1flCXRh9blG85w13ddKhacjEyeosMU=; b=TY+JwXFPE3g2mMy7GsqF2A+JL5Xdh8FYHaN4Nu5JIHi6VwZyzolLdtv+nn2vu0aBqw jj3mRuUKRMPKR5LbCRDC59WKaMVLwKpoohJ9uArKxALvrYYq4Vxo/MIOIRAVcf6Iy0q2 Dr36tKCI8V2PYp1FTzygoeodgQtDiQNtbsbYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bsKQCQ8QeS554dp+ci98ZAG8FG8+jE+6ctrJ326vBG9rWAmzHDvCsV9TzT/8sO42e1 h79hwcUiJvk/gz5QfHsCH+jMCnw5VHae6bxu9wRbZ12AFosPSpx0W+jDIRqhPlstZMzH 5QkNyJLXsK65wG5lE64nZzrnNStM1lTHslXPo= MIME-Version: 1.0 Received: by 10.52.181.164 with SMTP id dx4mr1169148vdc.183.1307629193076; Thu, 09 Jun 2011 07:19:53 -0700 (PDT) Received: by 10.52.158.39 with HTTP; Thu, 9 Jun 2011 07:19:52 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0494A190@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0494A190@xmb-sjc-221.amer.cisco.com> Date: Thu, 9 Jun 2011 09:19:52 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec547c8ff8d1fc004a5482513 Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:21:27 -0000 --bcaec547c8ff8d1fc004a5482513 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As chair, I just want to add that it is extremely important that folks review this updated document in detail. The requirements have been pretty much re-written,so a diff would not be particularly useful. If you could please review the document and past any concerns on the mailin= g list prior to June 17th, that will give Allyn time to assimilate the issues into discussion points for the meeting. Thanks, Mary. On Wed, Jun 8, 2011 at 8:50 PM, Allyn Romanow (allyn) wrot= e: > Folks, > Here is a new draft of my CLUE requirements draft. Steve Botzko and Mark > Goryzinski are co-authors. > > This draft focused only on the Requirements section, not on the other > sections (Intro and Problem Statement). The definitions are taken from > Stephan=92s draft. > > The main goal of this draft is to express requirements precisely enough t= o > have a productive discussion- and not so specifically as to design the > solution within the requirements document. > > Everyone will have particular things they want to make sure are covered. > This is good. Hopefully, the requirements are general enough to cover our > specific requirements =96 where not, new well-specified requirements can = be > added. > > We=92ll expect plenty of conversation- > > Thanks, > Allyn > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, June 08, 2011 6:47 PM > To: Allyn Romanow (allyn) > Cc: Allyn Romanow (allyn); stephen.botzko@polycom.com; > mark.gorzynski@hp.com > Subject: New Version Notification > fordraft-romanow-clue-telepresence-requirements-03.txt > > A new version of I-D, draft-romanow-clue-telepresence-requirements-03.txt > has been successfully submitted by Allyn Romanow and posted to the IETF > repository. > > Filename: draft-romanow-clue-telepresence-requirements > Revision: 03 > Title: Requirements for Telepresence Multi-Streams > Creation date: 2011-06-09 > WG ID: Individual Submission > Number of pages: 12 > > Abstract: > This memo discusses the requirements for a specification that enables > telepresence interoperability, by describing the relationship between > multiple RTP streams. In addition, the problem statement and > definitions are also covered herein. > > > > > The IETF Secretariat > --bcaec547c8ff8d1fc004a5482513 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
As chair, I just want to add that it is extremely important that folks= review this updated document in detail.=A0 The requirements have been pret= ty much re-written,so a diff would not be particularly useful.=A0=A0
=A0
If=A0you could please review the document and past any concerns on the= mailing list prior to June 17th, that will give Allyn time to assimilate t= he issues into discussion points for the meeting.=A0
=A0
Thanks,
Mary. =A0

On Wed, Jun 8, 2011 at 8:50 PM, Allyn Romanow (a= llyn) <allyn@cisco.= com> wrote:
Folks,
Here is a new draft of= my CLUE requirements draft. Steve Botzko and Mark Goryzinski are co-author= s.

This draft focused only on the Requirements section, not on the other s= ections (Intro and Problem Statement). The definitions are taken from Steph= an=92s draft.

The main goal of this draft is to express requirements= precisely enough to have a productive discussion- and not so specifically = as to design the solution within the requirements document.

Everyone will have particular things they want to make sure are covered= . This is good. Hopefully, the requirements are general enough to cover our= specific requirements =96 where not, new well-specified requirements can b= e added.

We=92ll expect plenty of conversation-

Thanks,
Allyn

-= ----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, June 08, 2011 6:47 PM
To: Allyn Romanow (allyn)
Cc: = Allyn Romanow (allyn); stephe= n.botzko@polycom.com; mark.gor= zynski@hp.com
Subject: New Version Notification fordraft-romanow-clue-telepresence-requir= ements-03.txt

A new version of I-D, draft-romanow-clue-telepresence-= requirements-03.txt has been successfully submitted by Allyn Romanow and po= sted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-romanow-clue-telepresence-requirementsRevision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 Requirements fo= r Telepresence Multi-Streams
Creation date: =A0 2011-06-09
WG ID: =A0= =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12

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




The IETF Secret= ariat

--bcaec547c8ff8d1fc004a5482513-- From allyn@cisco.com Thu Jun 9 09:09:06 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2C021F84B9 for ; Thu, 9 Jun 2011 09:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z-PH3JBPbpC for ; Thu, 9 Jun 2011 09:09:05 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id BD1B021F84B3 for ; Thu, 9 Jun 2011 09:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=3112; q=dns/txt; s=iport; t=1307635741; x=1308845341; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=v6sLmYS0nXWIWKIfQ1FzEAHobbDGS0uv7i96peDKaG0=; b=diQDDFDRbzaaB3y0O5tb3qjFyGK5UBqPw/XZSt0Tn1YVVOt3fWyi1EiU luw576oPV10I92z4tNaoUqFy+iG1af0QecGwxp1IgqiKoc3bVJGpzUq8m E3xm/o0sA6MM8rfM/KfE2THr/6+whRXxqRnFwR+daGELGwXfZh0SMrK4i Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwBAPvv8E2rRDoJ/2dsb2JhbABTl0iOc3epb54lhiMEhwiOeIsc X-IronPort-AV: E=Sophos;i="4.65,342,1304294400"; d="scan'208";a="373558329" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2011 16:08:41 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p59G8dL5030972; Thu, 9 Jun 2011 16:08:41 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 09:08:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jun 2011 09:08:25 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0494A2CC@xmb-sjc-221.amer.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3600BE@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-romanow-clue-telepresence-requirements-03.txt - REQMT-12 Thread-Index: AcwmRyurwoq3Gp8rT+WBXv6wTj3SFgAAAx+AABnc1tAABCrxcA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0494A190@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3600BE@ESESSCMS0356.eemea.ericsson.se> From: "Allyn Romanow (allyn)" To: "Christer Holmberg" , X-OriginalArrivalTime: 09 Jun 2011 16:08:29.0640 (UTC) FILETIME=[78EE6480:01CC26BF] Subject: Re: [clue] New Version Notification for draft-romanow-clue-telepresence-requirements-03.txt - REQMT-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 16:09:06 -0000 Yes - sounds good- thanks > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, June 09, 2011 7:09 AM > To: Allyn Romanow (allyn); clue@ietf.org > Subject: RE: New Version Notification for draft-romanow-clue- > telepresence-requirements-03.txt - REQMT-12 >=20 >=20 > Hi, >=20 > REQMT-12 still mentions "CLUE". >=20 > "REQMT-12: The solution MUST support a mechanism for determining > whether or not an endpoint or MCU is capable of CLUE." >=20 > I would suggesting to change that to "telepresence extensions", as in > REQMT-11. >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf Of Allyn Romanow (allyn) > > Sent: 9. kes=E4kuuta 2011 4:50 > > To: clue@ietf.org > > Subject: [clue] FW: New Version Notification for > > draft-romanow-clue-telepresence-requirements-03.txt > > > > Folks, > > Here is a new draft of my CLUE requirements draft. Steve > > Botzko and Mark Goryzinski are co-authors. > > > > This draft focused only on the Requirements section, not on > > the other sections (Intro and Problem Statement). The > > definitions are taken from Stephan's draft. > > > > The main goal of this draft is to express requirements > > precisely enough to have a productive discussion- and not so > > specifically as to design the solution within the > > requirements document. > > > > Everyone will have particular things they want to make sure > > are covered. This is good. Hopefully, the requirements are > > general enough to cover our specific requirements - where > > not, new well-specified requirements can be added. > > > > We'll expect plenty of conversation- > > > > Thanks, > > Allyn > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, June 08, 2011 6:47 PM > > To: Allyn Romanow (allyn) > > Cc: Allyn Romanow (allyn); stephen.botzko@polycom.com; > > mark.gorzynski@hp.com > > Subject: New Version Notification > > fordraft-romanow-clue-telepresence-requirements-03.txt > > > > A new version of I-D, > > draft-romanow-clue-telepresence-requirements-03.txt has been > > successfully submitted by Allyn Romanow and posted to the > > IETF repository. > > > > Filename: draft-romanow-clue-telepresence-requirements > > Revision: 03 > > Title: Requirements for Telepresence Multi-Streams > > Creation date: 2011-06-09 > > WG ID: Individual Submission > > Number of pages: 12 > > > > Abstract: > > This memo discusses the requirements for a specification > > that enables > > telepresence interoperability, by describing the > > relationship between > > multiple RTP streams. In addition, the problem statement and > > definitions are also covered herein. > > > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > From eckelcu@cisco.com Fri Jun 10 13:30:53 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA47311E812B for ; Fri, 10 Jun 2011 13:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP7P5O5sQm32 for ; Fri, 10 Jun 2011 13:30:53 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF2511E8118 for ; Fri, 10 Jun 2011 13:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2624; q=dns/txt; s=iport; t=1307737853; x=1308947453; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=E7Nn0tUUNY7dtuZGXNULHHiwX4StBiU5YginiH/RaR8=; b=QPmFiW/RexJ7vu8nJhiYqCEfJa1ZAwracL+1FCm/DU6pvh5yuB/4jvgW n2KdRtmOdv8azBax8Dh8C8LaOqYYoCNfV2J3bfgc0D3oZOAKHJwuA1rLa kElvv4LgOYq9AoWGBS6Ep2Qalge3ul0S3B6RfzZmf989bAF7LggpZBPBG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgBAKF+8k2rRDoI/2dsb2JhbABSl1WOeHenBJ4GhiMEhwiOeosg X-IronPort-AV: E=Sophos;i="4.65,348,1304294400"; d="scan'208";a="711814262" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 10 Jun 2011 20:30:43 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5AKUhkp002425 for ; Fri, 10 Jun 2011 20:30:43 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Jun 2011 13:30:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jun 2011 13:30:41 -0700 Message-ID: In-Reply-To: <4DE57EA5.6060406@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [clue] Definitions: Participant thread-index: Acwf7Xs9+pY44D5FQUCF3dvVMSG9PgHv2Fvg References: <4DE57EA5.6060406@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 10 Jun 2011 20:30:43.0658 (UTC) FILETIME=[458CC2A0:01CC27AD] Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 20:30:54 -0000 Sorry I am late to the thread. I was out of the office a couple weeks and having too much fun to check e-mail. I prefer use participant in the RFC 4353 sense, as you never really know how many humans, if any, are in a room or in the field of vision of a camera, and the number may change without any signaling or other indication. Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) > Sent: Tuesday, May 31, 2011 4:50 PM > To: clue@ietf.org > Subject: Re: [clue] Definitions: Participant >=20 > I support using Participant in the 4353 sense. > (Its really the only definition that most of the software can use in a > useful way. E.g. the conference roster is about these automata. This > becomes especially obvious when you have the same "person" showing up > multiple times in the roster.) >=20 > If there is need to talk about the human(s) associated with a > participant, then it would make sense to define another term for that. >=20 > Thanks, > Paul (as individual) >=20 > On 5/31/2011 7:03 PM, Stephan Wenger wrote: > > Hi all, > > I thought I would quickly rev the definitions doc, and found out that I > > cannot find agreements on a number of terms. This is the first of a set > > of eamils that will hopefully lead us to close the definitions on a few > > terms. > > So this email is about "Participant". > > > > We have the odd definition that RFC 4353 lists participant essentially > > as a piece of software and not as a human. To Song Haibin, Steve Botzko > > (and to me), Participants sounds like human, though. > > > > Several ways forward: > > > > 1. Use Participant in the 4353 sense only > > 2. Use Participant in the sense of a human participating in a > > telepresence session only. That would mean that there can be many > > participants at any endpoint, and endpoint can have no participant > > (empty room or webcam), and so forth. > > 3. Use Participant in the sense of 2) above, and add remark that if > > 4353 Participant is meant, this will be explicitely mentioned. > > > > My preference is 1. 2 and 3 have too much potential for confusion. Shame > > on 4353 for that. > > > > Opinions? > > > > Stephan > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Mon Jun 13 23:47:01 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D46111E807A for ; Mon, 13 Jun 2011 23:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akHUv+BCG86V for ; Mon, 13 Jun 2011 23:47:00 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 7929C11E8074 for ; Mon, 13 Jun 2011 23:47:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcCACwB90120Vva/2dsb2JhbAAMRpgMtxCfNoYkBKE+ Received: from ppp118-209-91-218.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.91.218]) by ipmail06.adl2.internode.on.net with ESMTP; 14 Jun 2011 16:16:58 +0930 Message-ID: <4DF703DE.4020608@nteczone.com> Date: Tue, 14 Jun 2011 16:46:54 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Comments on draft-wenger-clue-definitions-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 06:47:01 -0000 Hello Stephan, I've been reviewing draft-wenger-clue-definitions-00.txt and have a few comments: General: The documents uses "speakers" and "loudspeakers" interchangeably. We probably should be consistent. Section 3: -------------- Audio Mixing: It says "... See RTP Topologies, [RFC5117]." There no use of the term "Audio Mixing" in RFC5117. WE may want to be more specific as to what we are referring to in RFC5117. The definition of "Conference" uses the title of the RFC when making the reference, should this same convention be used for Audio Mixing? Capture device: Given Arnoud's comment's regarding TTS should we consider a keyboard a capture device? Conference: RFC4353 indicates that when used in that RFC "... a conference is always a tightly coupled conference". Are we intending that the CLUE definition also always assumes a tightly coupled conference or a wider definition? Left: "Wikipadia" should be "Wikipedia"? Local: Something doesn't read right "physically co-located in the context of the discussion". Tt least I stared at it for awhile?? The definition of "Remote" doesn't mention "... in the context of the discussion". How about "Local: When used it describes the sender and/or receiver physically co-located with the participant?/endpoint? in question; not remote." Model: Instead of using the term "Model" would "Profile" (with the same definition) be more appropriate? For me a model is a generic description of a system whereas a profile is a specific instantiation of a system. Remote: "A remote can be an Endpoint or an MCU". I don't think "remote" is being proposed to be a noun by the definition. Perhaps "A remote can be...."? Rendering Device: The use of "optical signals" could suggest fibre optic signalling. Would "visual communication" be a better term? Regards, Christian From christer.holmberg@ericsson.com Tue Jun 14 07:23:07 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9907711E80B6 for ; Tue, 14 Jun 2011 07:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8JXduoup6M6 for ; Tue, 14 Jun 2011 07:23:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 92EF011E80A0 for ; Tue, 14 Jun 2011 07:23:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-f6-4df76ec25919 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D4.52.09774.2CE67FD4; Tue, 14 Jun 2011 16:22:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 14 Jun 2011 16:22:57 +0200 From: Christer Holmberg To: "clue@ietf.org" Date: Tue, 14 Jun 2011 16:22:57 +0200 Thread-Topic: Requirement on centralized media mixing Thread-Index: Acwqno7BLwl3j+PMSjaOF3ZfYi/FNw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A1471ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 14:23:07 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A1471ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, During the last interim meeting (May 12th) we discussed a requirement propo= sal stating that an endpoint must be able to request central audio rendering of different predefined formats, including 3D binaural rendering. (Link to proposal: http://www.ietf.org/mail-archive/web/clue/current/msg001= 79.html) The proposal was well received, with the reservation that it should not be = mandatory for the solution to implement centralized 3D binaural rendering, i.e.an end= point should be able to request 3D binaural rendering, but had no guaranty that such ren= dering was supported by the system. It was decided to look how such requirement could look like. When I look the -03 version of the req draft, Requirement 2c states: "The solution MUST NOT preclude the use of binaural audio." I think that requirement is unclear, and it doesn't really give any guidanc= e to our work. Due to that, and also due to the fact that rather than talking about specif= ic rendering types, I would like to propose more general requirement text on the negotiation of= the media mixing type, and the usage of centralized media mixing in the first place. The mechanism would be extendable, so new types can be added in future. So, the proposed requirements are: REQ-x: It MUST be possible to negotiate the usage of centralized media m= ixing. System support of centralized media mixing is optional. REQ-y: When centralized media mixing is used, it MUST be possible to neg= otiate the type of media rendering provided for each media stream received = by a client. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A1471ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
During the last interim meeting (May 12th) we discuss= ed a requirement proposal
stating that an endpoint must be able to request cent= ral audio rendering
of different predefined formats, including 3D binaura= l rendering.
 
The proposal was well received, with the reservation = that it should not be mandatory
for the solution to implement centralized 3D binaural= rendering, i.e.an endpoint should
be able to request 3D binaural rendering, but had no = guaranty that such rendering was
supported by the system.
 
It was decided to look how such requirement could loo= k like.
 
When I look the -03 version of the req draft, Require= ment 2c states:
 
    "The solution MUST NOT preclu= de the use of binaural audio."
 
I think that requirement is unclear, and it doesn't r= eally give any guidance to our work.
 
Due to that, and also due to the fact that rather tha= n talking about specific rendering types,
I would like to propose more general requirement text= on the negotiation of the media mixing type,
and the usage of centralized media mixing in the firs= t place.
 
The mechanism would be extendable, so new types can b= e added in future.
 
So, the proposed requirements are:
 
REQ-x:    It MUST be possible to negot= iate the usage of centralized media mixing. System support of centralized m= edia mixing is optional.
 
REQ-y:    When centralized media mixin= g is used, it MUST be possible to negotiate the type of media rendering pro= vided for each media stream received by a client.
 
Regards,
 
Christer
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E3A1471ESESSCMS0356e_-- From stephen.botzko@gmail.com Tue Jun 14 07:52:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8183011E80C0 for ; Tue, 14 Jun 2011 07:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veA7SxQZ1sNh for ; Tue, 14 Jun 2011 07:52:45 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4A811E80AD for ; Tue, 14 Jun 2011 07:52:45 -0700 (PDT) Received: by vws12 with SMTP id 12so6563855vws.31 for ; Tue, 14 Jun 2011 07:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qLqBiRbIZS7IVum2yTRJ6i1b/rGucpnLH8UO4FVPPxk=; b=iTivlAVu2kGiA+f1hNQdQEC50/nkGgIKbg46l6Mou5uIx4+zdD55+uX+R1VClj9IOP SzrTGZJ/7Sm9edoylTpkS9QEC/48Qx0rnv1RgNHRIoN07RycXDQdYCV8ThtKB3GdFGud 0jQ5aUg2qF6n73ZkhXMt1XrPtr7wGlLysjORk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pIhQfedAia1V++xMpk3SVHeucYGsiy9Ccs8Cuw2dkgCrZMc+EzASN8EYna4ICxiHW9 p6xQy3Nbe2DTn5uX/uERT3FCCzhptCmtrTXhAdQTCpNvbmpSH/isKY1Nm4g+pgvRKHyi dCdwIbNhI4pa0Q+K6dU1ez/NuiEP4DivDM3cE= MIME-Version: 1.0 Received: by 10.52.160.68 with SMTP id xi4mr6872661vdb.106.1308063164795; Tue, 14 Jun 2011 07:52:44 -0700 (PDT) Received: by 10.52.188.137 with HTTP; Tue, 14 Jun 2011 07:52:44 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 14 Jun 2011 10:52:44 -0400 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec53f9779480db404a5ad3027 Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 14:52:46 -0000 --bcaec53f9779480db404a5ad3027 Content-Type: text/plain; charset=ISO-8859-1 If some other WG (for instance MMUSIC) defined a mechanism for general use of binaural audio for SIP/RTP, then I would fully support requirements that such a facility should be enabled in CLUE. But I do not think that CLUE is the right place to invent negotiation of binaural audio. Telepresence system users generally do not use headsets. Regards, Stephen Botzko On Tue, Jun 14, 2011 at 10:22 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > During the last interim meeting (May 12th) we discussed a requirement > proposal > stating that an endpoint must be able to request central audio rendering > of different predefined formats, including 3D binaural rendering. > (Link to proposal: * > http://www.ietf.org/mail-archive/web/clue/current/msg00179.html* > ) > > The proposal was well received, with the reservation that it should not be > mandatory > for the solution to implement centralized 3D binaural rendering, i.e.anendpoint should > be able to request 3D binaural rendering, but had no guaranty that such > rendering was > supported by the system. > > It was decided to look how such requirement could look like. > > When I look the -03 version of the req draft, Requirement 2c states: > > "The solution MUST NOT preclude the use of binaural audio." > > I think that requirement is unclear, and it doesn't really give any > guidance to our work. > > Due to that, and also due to the fact that rather than talking about > specific rendering types, > I would like to propose more general requirement text on the negotiation of > the media mixing type, > and the usage of centralized media mixing in the first place. > > The mechanism would be extendable, so new types can be added in future. > > So, the proposed requirements are: > > REQ-x: It MUST be possible to negotiate the usage of centralized media > mixing. System support of centralized media mixing is optional. > > REQ-y: When centralized media mixing is used, it MUST be possible to > negotiate the type of media rendering provided for each media stream > received by a client. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --bcaec53f9779480db404a5ad3027 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If some other WG (for instance MMUSIC) defined a mechanism for general use = of binaural audio for SIP/RTP, then I would fully support requirements that= such a facility should be enabled in CLUE.

But I do not think that = CLUE is the right place to invent negotiation of binaural audio.=A0 Telepre= sence system users generally do not use headsets.

Regards,
Stephen Botzko

On Tue, Ju= n 14, 2011 at 10:22 AM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:
=A0
Hi,
=A0
During the last interim meeting (May 12th) we discuss= ed a requirement proposal
stating that an endpoint must be able to request cent= ral audio rendering
of different predefined formats, including 3D binaura= l rendering.
=A0
The proposal was well received, with the reservation = that it should not be mandatory
for the solution to implement centralized 3D binaural= rendering, i.e.an endpoint= should
be able to request 3D binaural rendering, but had no = guaranty that such rendering was
supported by the system.
=A0
It was decided to look how such requirement could loo= k like.
=A0
When I look the -03 version of the req draft, Require= ment 2c states:
=A0
=A0=A0=A0 "The solution MUST NOT preclude the us= e of binaural audio."
=A0
I think that requirement is unclear, and it doesn'= ;t really give any guidance to our work.
=A0
Due to that, and also due to the fact that rather tha= n talking about specific rendering types,
I would like to propose more general requirement text= on the negotiation of the media mixing type,
and the usage of centralized media mixing in the firs= t place.
=A0
The mechanism would be extendable, so new types can b= e added in future.
=A0
So, the proposed requirements are:
=A0
REQ-x:=A0=A0=A0 It MUST be possible to negotiate the = usage of centralized media mixing. System support of centralized media mixi= ng is optional.
=A0
REQ-y:=A0=A0=A0 When centralized media mixing is used= , it MUST be possible to negotiate the type of media rendering provided for= each media stream received by a client.
=A0
Regards,
=A0
Christer
=A0
=A0

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


--bcaec53f9779480db404a5ad3027-- From christer.holmberg@ericsson.com Tue Jun 14 09:15:06 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9591F0C36 for ; Tue, 14 Jun 2011 09:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUGVG4Xe9vDu for ; Tue, 14 Jun 2011 09:15:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 54BCA11E8078 for ; Tue, 14 Jun 2011 09:15:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-14-4df7890465fd Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.7E.09774.40987FD4; Tue, 14 Jun 2011 18:15:00 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 14 Jun 2011 18:14:58 +0200 From: Christer Holmberg To: Stephen Botzko Date: Tue, 14 Jun 2011 18:10:46 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwqorlli+U2v2hzRP6M3/zng09quQACuVUj Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:15:06 -0000 Hi, >If some other WG (for instance MMUSIC) defined a mechanism for general use= of binaural audio for SIP/RTP, then >I would fully support requirements that such a facility should be enabled = in CLUE. > >But I do not think that CLUE is the right place to invent negotiation of b= inaural audio. Telepresence system users >generally do not use headsets. No, but users communicating with a telepresence system using other types of= devices may. But, again, the proposed requirements are not specific to binaural audio. It is about having a generic mechanism for negotiation of centralized media= mixing usage, if the system supports it. Regards, Christer On Tue, Jun 14, 2011 at 10:22 AM, Christer Holmberg > wrote: Hi, During the last interim meeting (May 12th) we discussed a requirement propo= sal stating that an endpoint must be able to request central audio rendering of different predefined formats, including 3D binaural rendering. (Link to proposal: http://www.ietf.org/mail-archive/web/clue/current/msg001= 79.html) The proposal was well received, with the reservation that it should not be = mandatory for the solution to implement centralized 3D binaural rendering, i.e.an endpoint should be able to request 3D binaural rendering, but had no guaranty that such ren= dering was supported by the system. It was decided to look how such requirement could look like. When I look the -03 version of the req draft, Requirement 2c states: "The solution MUST NOT preclude the use of binaural audio." I think that requirement is unclear, and it doesn't really give any guidanc= e to our work. Due to that, and also due to the fact that rather than talking about specif= ic rendering types, I would like to propose more general requirement text on the negotiation of= the media mixing type, and the usage of centralized media mixing in the first place. The mechanism would be extendable, so new types can be added in future. So, the proposed requirements are: REQ-x: It MUST be possible to negotiate the usage of centralized media m= ixing. System support of centralized media mixing is optional. REQ-y: When centralized media mixing is used, it MUST be possible to neg= otiate the type of media rendering provided for each media stream received = by a client. Regards, Christer _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Tue Jun 14 10:04:33 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9E3228007 for ; Tue, 14 Jun 2011 10:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id req3fXCkFfnF for ; Tue, 14 Jun 2011 10:04:32 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F711228006 for ; Tue, 14 Jun 2011 10:04:24 -0700 (PDT) Received: by vxg33 with SMTP id 33so6687409vxg.31 for ; Tue, 14 Jun 2011 10:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aLsw+LXvoAmrn2nrIdAFqk3/xX+DGXDrYQ47nQ3vdbQ=; b=Qx1XR/XyvPIg0tymekGp3FxQTldtn20PJYw9k+Inkj+MNPZSDkrzhbeLOvNlgy1xLe 3MgdNEJAxNHNON1VthYCbdbq9cqV1Xf1a7B3+umuALzVI/ejvNaHEMn+wcCwKz8Gj/qQ udK4vnoqz9LcVmTDZ4aEP7pRPO0BX4EVE8hko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fxtDSG4fdyCbgMiKI7vrYhCA4bz3FXUMYKF/TEb+wIwEiqDsGgwR6C55j7D7nWPU7B cdqHTjokFEL36Kiwnev33BHuZclw1TVeeQ1zbNG3XQ+wr2GbzJ396mdB4iRsOncRx/jR 2WZ6iCiAzoN/ILLXEj0qJ9Xn/DaDextsk1BSI= MIME-Version: 1.0 Received: by 10.52.66.206 with SMTP id h14mr6098953vdt.40.1308071063610; Tue, 14 Jun 2011 10:04:23 -0700 (PDT) Received: by 10.52.188.137 with HTTP; Tue, 14 Jun 2011 10:04:23 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 14 Jun 2011 13:04:23 -0400 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf307cfd8216670504a5af07c7 Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 17:04:33 -0000 --20cf307cfd8216670504a5af07c7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 14, 2011 at 12:10 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >If some other WG (for instance MMUSIC) defined a mechanism for general use > of binaural audio for SIP/RTP, then > >I would fully support requirements that such a facility should be enabled > in CLUE. > > > >But I do not think that CLUE is the right place to invent negotiation of > binaural audio. Telepresence system users > >generally do not use headsets. > > > > No, but users communicating with a telepresence system using other types of > devices may. > > > Yes they might. But CLUE is not the place to create completely new facilities that are not intended for telepresence systems. > > But, again, the proposed requirements are not specific to binaural audio. > > > > It is about having a generic mechanism for negotiation of centralized media > mixing usage, if the system supports it. > > > I don't understand what "*negotiate the type of media rendering*" means. Maybe you can describe more precisely what is meant? > > Regards, > > > > Christer > > > > > > On Tue, Jun 14, 2011 at 10:22 AM, Christer Holmberg < > christer.holmberg@ericsson.com> > wrote: > > Hi, > > During the last interim meeting (May 12th) we discussed a requirement > proposal > stating that an endpoint must be able to request central audio rendering > of different predefined formats, including 3D binaural rendering. > (Link to proposal: > http://www.ietf.org/mail-archive/web/clue/current/msg00179.html) > > The proposal was well received, with the reservation that it should not be > mandatory > for the solution to implement centralized 3D binaural rendering, i.e.an< > http://i.e.an> endpoint should > be able to request 3D binaural rendering, but had no guaranty that such > rendering was > supported by the system. > > It was decided to look how such requirement could look like. > > When I look the -03 version of the req draft, Requirement 2c states: > > "The solution MUST NOT preclude the use of binaural audio." > > I think that requirement is unclear, and it doesn't really give any > guidance to our work. > > Due to that, and also due to the fact that rather than talking about > specific rendering types, > I would like to propose more general requirement text on the negotiation of > the media mixing type, > and the usage of centralized media mixing in the first place. > > The mechanism would be extendable, so new types can be added in future. > > So, the proposed requirements are: > > REQ-x: It MUST be possible to negotiate the usage of centralized media > mixing. System support of centralized media mixing is optional. > > REQ-y: When centralized media mixing is used, it MUST be possible to > negotiate the type of media rendering provided for each media stream > received by a client. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > --20cf307cfd8216670504a5af07c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 14, 2011 at 12:10 PM, Christ= er Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

>If some other WG (for instance MMUSIC) defined a mechanism for general = use of binaural audio for SIP/RTP, then
>I would fully support requirements that such a facility should be enabl= ed in CLUE.
>
>But I do not think that CLUE is the right place to invent negotiation o= f binaural audio. =A0Telepresence system users
>generally do not use headsets.



No, but users communicating with a telepresence system using other ty= pes of devices may.


Yes they might.=A0 But CLUE is not the place to creat= e completely new facilities that are not intended for telepresence systems.=

But, again, the proposed requirements are not specific to binaural audio. =A0


It is about having a generic mechanism for negotiation of centralized media= mixing usage, if the system supports it.


I don't understand what=A0 "negotiate the= type of media rendering" means.=A0 Maybe you can describe more pr= ecisely what is meant?

Regards,



Christer





On Tue, Jun 14, 2011 at 10:22 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto= :christer.holmberg@ericss= on.com>> wrote:

Hi,

During the last interim meeting (May 12th) we discussed a requirement propo= sal
stating that an endpoint must be able to request central audio rendering of different predefined formats, including 3D binaural rendering.
(Link to proposal: http://www.ietf.org/mail-archive/web/= clue/current/msg00179.html)

The proposal was well received, with the reservation that it should not be = mandatory
for the solution to implement centralized 3D binaural rendering, i.e.an<http://i.e.an> endpoint should
be able to request 3D binaural rendering, but had no guar= anty that such rendering was
supported by the system.

It was decided to look how such requirement could look like.

When I look the -03 version of the req draft, Requirement 2c states:

=A0 =A0"The solution MUST NOT preclude the use of binaural audio.&quo= t;

I think that requirement is unclear, and it doesn't really give any gui= dance to our work.

Due to that, and also due to the fact that rather than talking about specif= ic rendering types,
I would like to propose more general requirement text on the negotiation of= the media mixing type,
and the usage of centralized media mixing in the first place.

The mechanism would be extendable, so new types can be added in future.

So, the proposed requirements are:

REQ-x: =A0 =A0It MUST be possible to negotiate the usage of centralized med= ia mixing. System support of centralized media mixing is optional.

REQ-y: =A0 =A0When centralized media mixing is used, it MUST be possible to= negotiate the type of media rendering provided for each media stream recei= ved by a client.

Regards,

Christer



_______________________________________________
clue mailing list
clue@ietf.org<mailto:clue@ietf.org>

--20cf307cfd8216670504a5af07c7-- From jmpolk@cisco.com Tue Jun 14 16:58:32 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF3A11E8152 for ; Tue, 14 Jun 2011 16:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN7eZ2UjRI5P for ; Tue, 14 Jun 2011 16:58:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id DA94111E8174 for ; Tue, 14 Jun 2011 16:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2937; q=dns/txt; s=iport; t=1308095911; x=1309305511; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=Q+o876CMg3hzRnI3NopNBeaGcAvMweLN8TaB6Uid5JY=; b=DNfzUZFzqSpAFXt76hGvHzEfTEcwouHVSgaflH34q9pIN/88UKgXQUu6 I9TUWTCAnS4Ga7/6K11p6nDDOpDn06danES6YE866BTmBoHQfFcsoTaOi 0QZdcQcU3/9arqrGtsUEaTtl3aN2XPwR4xHdGU5ACblyvWO72jL54bYN/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF31902rRDoJ/2dsb2JhbABSplF3qhKeNIYmBIcVmkA X-IronPort-AV: E=Sophos;i="4.65,367,1304294400"; d="scan'208";a="337070188" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2011 23:58:31 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5ENwVMw017754; Tue, 14 Jun 2011 23:58:31 GMT Message-Id: <201106142358.p5ENwVMw017754@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Jun 2011 18:58:29 -0500 To: Christian Groves , clue@ietf.org From: "James M. Polk" In-Reply-To: <4DF703DE.4020608@nteczone.com> References: <4DF703DE.4020608@nteczone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [clue] Comments on draft-wenger-clue-definitions-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 23:58:32 -0000 At 01:46 AM 6/14/2011, Christian Groves wrote: >Hello Stephan, > >I've been reviewing draft-wenger-clue-definitions-00.txt and have a >few comments: > >General: The documents uses "speakers" and "loudspeakers" >interchangeably. We probably should be consistent. > >Section 3: >-------------- >Audio Mixing: It says "... See RTP Topologies, [RFC5117]." There no >use of the term "Audio Mixing" in RFC5117. WE may want to be more >specific as to what we are referring to in RFC5117. The definition >of "Conference" uses the title of the RFC when making the reference, >should this same convention be used for Audio Mixing? > >Capture device: Given Arnoud's comment's regarding TTS should we >consider a keyboard a capture device? > >Conference: RFC4353 indicates that when used in that RFC "... a >conference is always a tightly coupled conference". Are we intending >that the CLUE definition also always assumes a tightly coupled >conference or a wider definition? > >Left: "Wikipadia" should be "Wikipedia"? > >Local: Something doesn't read right "physically co-located in the >context of the discussion". Tt least I stared at it for awhile?? The >definition of "Remote" doesn't mention "... in the context of the discussion". >How about "Local: When used it describes the sender and/or receiver >physically co-located with the participant?/endpoint? in question; not remote." does being co-located also mean in the same room? or building? or city? I think this gets into the relative nature of how one thinks. My corporate offices are in San Jose, CA, and for all intents and purposes *everyone* else in the world working for my company considers any two individuals that are both in San Jose, CA to be local to each other, regardless of the actual distance between the seats the two are sitting in. For those who don't know, we have dozens and dozens of buildings within our campus in San Jose, CA - thus "local" is relative to the point of view from where one's at, IMO. Should this be considered here? IMO - "local" from a CLUE point of view would likely involve being in the "same room", and not in the same building or in the same city. James >Model: Instead of using the term "Model" would "Profile" (with the >same definition) be more appropriate? For me a model is a generic >description of a system whereas a profile is a specific >instantiation of a system. > >Remote: "A remote can be an Endpoint or an MCU". I don't think >"remote" is being proposed to be a noun by the definition. Perhaps >"A remote can be...."? > >Rendering Device: The use of "optical signals" could suggest fibre >optic signalling. Would "visual communication" be a better term? > >Regards, Christian > > > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From gao.yang2@zte.com.cn Tue Jun 14 18:29:48 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD31721F852B for ; Tue, 14 Jun 2011 18:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u5J7NTt1IpV for ; Tue, 14 Jun 2011 18:29:48 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9101421F8529 for ; Tue, 14 Jun 2011 18:29:47 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641074741547; Wed, 15 Jun 2011 09:29:16 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 23654.2684705110; Wed, 15 Jun 2011 09:28:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p5F1SkWm079755; Wed, 15 Jun 2011 09:28:46 +0800 (GMT-8) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg MIME-Version: 1.0 X-KeepSent: A971A678:7223800A-482578B0:0007ED20; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 15 Jun 2011 09:28:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-15 09:28:47, Serialize complete at 2011-06-15 09:28:47 Content-Type: multipart/alternative; boundary="=_alternative 00083AB8482578B0_=" X-MAIL: mse02.zte.com.cn p5F1SkWm079755 Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 01:29:48 -0000 This is a multipart message in MIME format. --=_alternative 00083AB8482578B0_= Content-Type: text/plain; charset="US-ASCII" Christer, I think this function is meaningful for operating network, such as IMS, NGN. Thanks, Gao > So, the proposed requirements are: > > REQ-x: It MUST be possible to negotiate the usage of centralized > media mixing. System support of centralized media mixing is optional. > > REQ-y: When centralized media mixing is used, it MUST be possible > to negotiate the type of media rendering provided for each media > stream received by a client. > > Regards, > > Christer > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00083AB8482578B0_= Content-Type: text/html; charset="US-ASCII"
Christer,

I think this function is meaningful for operating network, such as IMS, NGN.

Thanks,

Gao


> So, the proposed requirements are:
>  
> REQ-x:    It MUST be possible to negotiate the usage of centralized
> media mixing. System support of centralized media mixing is optional.
>  
> REQ-y:    When centralized media mixing is used, it MUST be possible
> to negotiate the type of media rendering provided for each media
> stream received by a client.
>  
> Regards,
>  
> Christer
>   

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00083AB8482578B0_=-- From christer.holmberg@ericsson.com Wed Jun 15 03:08:18 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3EC11E8075 for ; Wed, 15 Jun 2011 03:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqKytmTiTy5M for ; Wed, 15 Jun 2011 03:08:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7E82411E8074 for ; Wed, 15 Jun 2011 03:08:17 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-fd-4df884901000 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 17.0C.20773.09488FD4; Wed, 15 Jun 2011 12:08:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 15 Jun 2011 12:08:12 +0200 From: Christer Holmberg To: Stephen Botzko Date: Wed, 15 Jun 2011 12:08:11 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: AcwqtRzbg5jZCBmUSoyqAJooUM2sfAAjta2Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1878@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 10:08:18 -0000 Hi Stephen, =09 >>>If some other WG (for instance MMUSIC) defined a mechanism for=20 >>>general use of binaural audio for SIP/RTP, then I would fully support re= quirements that such a facility should be enabled in CLUE. >>> >>>But I do not think that CLUE is the right place to invent negotiation=20 >>>of binaural audio. Telepresence system users generally do not use heads= ets. >>=09 >>No, but users communicating with a telepresence system using other types = of devices may. > >Yes they might. But CLUE is not the place to create completely new facilit= ies that are not intended for telepresence systems.=20 Being able to connect to telepresence system with non-TP devices is within = the scope of the work, and we think it would create great added value if we= have a mechanism which allows offering an optimized "near-telepresence exp= erience" also to such devices. >>It is about having a generic mechanism for negotiation of centralized med= ia mixing usage, if the system supports it. >=09 >I don't understand what "negotiate the type of media rendering" means. M= aybe you can describe more precisely what is meant?=20 It's about two things: First, to be able to find out whether the system supports centralized rende= ring in the first place. Note that such functionality is optional. Second, to be able to request centralized rendering, and the type of render= ing. (Solution wise, we might be talking about some SDP attributes in order to d= o this) Note that this proposal does not have any impact on the definitions, or on = the telepresence "room model". Regards, Christer =09 =20 On Tue, Jun 14, 2011 at 10:22 AM, Christer Holmberg > wrote: =09 Hi, =09 During the last interim meeting (May 12th) we discussed a requirement pro= posal stating that an endpoint must be able to request central audio rendering of different predefined formats, including 3D binaural rendering. (Link to proposal: http://www.ietf.org/mail-archive/web/clue/current/msg0= 0179.html) =09 The proposal was well received, with the reservation that it should not b= e mandatory =09 for the solution to implement centralized 3D binaural rendering, i.e.an endpoint should =09 be able to request 3D binaural rendering, but had no guaranty that such r= endering was supported by the system. =09 It was decided to look how such requirement could look like. =09 When I look the -03 version of the req draft, Requirement 2c states: =09 "The solution MUST NOT preclude the use of binaural audio." =09 I think that requirement is unclear, and it doesn't really give any guida= nce to our work. =09 Due to that, and also due to the fact that rather than talking about spec= ific rendering types, I would like to propose more general requirement text on the negotiation = of the media mixing type, and the usage of centralized media mixing in the first place. =09 The mechanism would be extendable, so new types can be added in future. =09 So, the proposed requirements are: =09 REQ-x: It MUST be possible to negotiate the usage of centralized media= mixing. System support of centralized media mixing is optional. =09 REQ-y: When centralized media mixing is used, it MUST be possible to n= egotiate the type of media rendering provided for each media stream receive= d by a client. =09 Regards, =09 Christer= From stephen.botzko@gmail.com Wed Jun 15 03:47:47 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8CD11E8074 for ; Wed, 15 Jun 2011 03:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFuXp0wp+-GO for ; Wed, 15 Jun 2011 03:47:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1C539E800D for ; Wed, 15 Jun 2011 03:47:46 -0700 (PDT) Received: by vxg33 with SMTP id 33so264362vxg.31 for ; Wed, 15 Jun 2011 03:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/dWGzRIVY68RtY3S2/9iIIRpmv5EJEbqJgsrO7IxS+g=; b=gnLpvnBeMalwe1ZvQ416XbuF7eyyiR5UtEZDcJWjfJimgHqrl6bRahOnC6llUQp5e0 /K1Iwt+9379ruURGJP84fH8P00WhGw3IkmCnNeDcDEHGONO1lj/B7H+z8P9ayUT8+omL VeUUOwhWsLCgIibL0CylO71mUPtZYSlZnQw68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MMHYoX5cH+hC9jyYIWPdw2Z+T+vngyFOO3sBEL2sqCMsCeeqJu/zR1b1QLjPkybWQV FNtt/tAIpMaIAPvIzUlYN+uN80pA8WaGZ13w1D4HHgjoTpVwt9WFkGxVeJ1OPoFYHLQy /ZyT7fQwj/L5TpxRJryy+607nZEJ9xBMM8Azw= MIME-Version: 1.0 Received: by 10.52.76.131 with SMTP id k3mr560343vdw.80.1308134865907; Wed, 15 Jun 2011 03:47:45 -0700 (PDT) Received: by 10.52.107.138 with HTTP; Wed, 15 Jun 2011 03:47:45 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1878@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1878@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 06:47:45 -0400 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec50160e30030f704a5bde2a5 Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 10:47:48 -0000 --bcaec50160e30030f704a5bde2a5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 15, 2011 at 6:08 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi Stephen, > > >>>If some other WG (for instance MMUSIC) defined a mechanism for > >>>general use of binaural audio for SIP/RTP, then I would fully support > requirements that such a facility should be enabled in CLUE. > >>> > >>>But I do not think that CLUE is the right place to invent negotiation > >>>of binaural audio. Telepresence system users generally do not use > headsets. > >> > >>No, but users communicating with a telepresence system using other types > of devices may. > > > >Yes they might. But CLUE is not the place to create completely new > facilities that are not intended for telepresence systems. > > Being able to connect to telepresence system with non-TP devices is within > the scope of the work, and we think it would create great added value if we > have a mechanism which allows offering an optimized "near-telepresence > experience" also to such devices. > Yes, connecting telepresence systems to legacy devices is within scope. And identifying relationships between streams is within scope. Binaural audio is not in either category. It is a specific mode of audio which for some reason has not been standardized. Telepresence systems do not use it, and there is no SDP defined for legacy devices to use either And It is not a stream relationship like left, right. I am not saying that binaural audio has no value; I think it does. But I don't think it is in scope. There is trouble ahead if every shiny new media idea becomes CLUE work because some hypothetical future non-telepresence device might want to use it to talk to a telepresence system through a middle box. > > >>It is about having a generic mechanism for negotiation of centralized > media mixing usage, if the system supports it. > > > >I don't understand what "negotiate the type of media rendering" means. > Maybe you can describe more precisely what is meant? > > It's about two things: > > First, to be able to find out whether the system supports centralized > rendering in the first place. Note that such functionality is optional. > > Second, to be able to request centralized rendering, and the type of > rendering. > What is the* type* of rendering? If this is a general facility not limited to binaural audio, then I'd like some other "types" to be identified. And I think we will need a definition. As it stands, I have no idea how to tell if a proposed solution meets this requirement or not. > (Solution wise, we might be talking about some SDP attributes in order to > do this) > > Note that this proposal does not have any impact on the definitions, or on > the telepresence "room model". > > Regards, > > Christer > > > > > > On Tue, Jun 14, 2011 at 10:22 AM, Christer Holmberg < > christer.holmberg@ericsson.com> > wrote: > > Hi, > > During the last interim meeting (May 12th) we discussed a > requirement proposal > stating that an endpoint must be able to request central > audio rendering > of different predefined formats, including 3D binaural > rendering. > (Link to proposal: > http://www.ietf.org/mail-archive/web/clue/current/msg00179.html) > > The proposal was well received, with the reservation that it > should not be mandatory > > for the solution to implement centralized 3D binaural > rendering, i.e.an endpoint should > > be able to request 3D binaural rendering, but had no > guaranty that such rendering was > supported by the system. > > It was decided to look how such requirement could look like. > > When I look the -03 version of the req draft, Requirement 2c > states: > > "The solution MUST NOT preclude the use of binaural > audio." > > I think that requirement is unclear, and it doesn't really > give any guidance to our work. > > Due to that, and also due to the fact that rather than > talking about specific rendering types, > I would like to propose more general requirement text on the > negotiation of the media mixing type, > and the usage of centralized media mixing in the first > place. > > The mechanism would be extendable, so new types can be added > in future. > > So, the proposed requirements are: > > REQ-x: It MUST be possible to negotiate the usage of > centralized media mixing. System support of centralized media mixing is > optional. > > REQ-y: When centralized media mixing is used, it MUST be > possible to negotiate the type of media rendering provided for each media > stream received by a client. > > Regards, > > Christer > --bcaec50160e30030f704a5bde2a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 6:08 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Stephen,

>>>If some other WG (for instance MMUSIC) defined a mechanism for<= br> >>>general use of binaural audio for SIP/RTP, then I would fully s= upport requirements that such a facility should be enabled in CLUE.
>>>
>>>But I do not think that CLUE is the right place to invent negot= iation
>>>of binaural audio. =A0Telepresence system users generally do no= t use headsets.
>>
>>No, but users communicating with a telepresence system using other = types of devices may.
>
>Yes they might. But CLUE is not the place to create completely new faci= lities that are not intended for telepresence systems.

Being able to connect to telepresence system with non-TP devices is w= ithin the scope of the work, and we think it would create great added value= if we have a mechanism which allows offering an optimized "near-telep= resence experience" also to such devices.
Yes, connecting telepresence systems to legacy devices is= within scope.=A0 And identifying relationships between streams is within s= cope.

Binaural audio is not in either category.=A0 It is a specific= mode of audio which for some reason has not been standardized.=A0 Telepres= ence systems do not use it, and there is no SDP defined for legacy devices = to use either=A0 And It is not a stream relationship like left, right.=A0 <= br>
I am not saying that binaural audio has no value; I think it does. =A0 = But I don't think it is in scope. There is trouble ahead if every shiny= new media idea becomes CLUE work because some hypothetical future non-tele= presence device might want to use it to talk to a telepresence system throu= gh a middle box.

>>It is about having a generic mechanism for negotiation of centraliz= ed media mixing usage, if the system supports it.
>
>I don't understand what =A0"negotiate the type of media render= ing" means. =A0Maybe you can describe more precisely what is meant?
It's about two things:

First, to be able to find out whether the system supports centralized rende= ring in the first place. Note that such functionality is optional.

Second, to be able to request centralized rendering, and the type of render= ing.
What is the type of rendering?=A0 If this = is a general facility not limited to binaural audio, then I'd like some= other "types" to be identified. And I think we will need=A0 a de= finition.=A0 As it stands, I have no idea how to tell if a proposed solutio= n meets this requirement or not.


(Solution wise, we might be talking about some SDP attributes in order to d= o this)

Note that this proposal does not have any impact on the definitions, or on = the telepresence "room model".

Regards,

Christer





=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On Tue, Jun 14, 2011 at 10:22 AM, Christer = Holmberg <christer.hol= mberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hi,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0During the last interim meeting (May 12th) = we discussed a requirement proposal
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0stating that an endpoint must be able to re= quest central audio rendering
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of different predefined formats, including = 3D binaural rendering.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Link to proposal: http:= //www.ietf.org/mail-archive/web/clue/current/msg00179.html)

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The proposal was well received, with the re= servation that it should not be mandatory

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for the solution to implement centralized 3= D binaural rendering, i.e.an<http://i.e.an> endp= oint should

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be able to request 3D binaural rendering, b= ut had no guaranty that such rendering was
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0supported by the system.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0It was decided to look how such requirement= could look like.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0When I look the -03 version of the req draf= t, Requirement 2c states:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The solution MUST NOT preclude t= he use of binaural audio."

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I think that requirement is unclear, and it= doesn't really give any guidance to our work.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Due to that, and also due to the fact that = rather than talking about specific rendering types,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I would like to propose more general requir= ement text on the negotiation of the media mixing type,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and the usage of centralized media mixing i= n the first place.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The mechanism would be extendable, so new t= ypes can be added in future.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0So, the proposed requirements are:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0REQ-x: =A0 =A0It MUST be possible to negoti= ate the usage of centralized media mixing. System support of centralized me= dia mixing is optional.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0REQ-y: =A0 =A0When centralized media mixing= is used, it MUST be possible to negotiate the type of media rendering prov= ided for each media stream received by a client.

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

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Christer

--bcaec50160e30030f704a5bde2a5-- From christer.holmberg@ericsson.com Wed Jun 15 06:28:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A99F11E812C for ; Wed, 15 Jun 2011 06:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzvmi0sMjQhN for ; Wed, 15 Jun 2011 06:28:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 03B4311E8126 for ; Wed, 15 Jun 2011 06:28:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-27-4df8b3953628 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 26.47.09774.593B8FD4; Wed, 15 Jun 2011 15:28:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 15 Jun 2011 15:28:53 +0200 From: Christer Holmberg To: Stephen Botzko Date: Wed, 15 Jun 2011 15:28:52 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: AcwrSap3QX80qNhUT7qPE6Yp3ytY0gAFQ1YQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A7D@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1878@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:28:56 -0000 Hi Stephen, >>>>>If some other WG (for instance MMUSIC) defined a mechanism for=20 >>>>>general use of binaural audio for SIP/RTP, then I would fully support = requirements that such a facility should be enabled in CLUE. >>>>> >>>>>But I do not think that CLUE is the right place to invent=20 >>>>>negotiation of binaural audio. Telepresence system users generally do= not use headsets. >>>> >>>>No, but users communicating with a telepresence system using other type= s of devices may. >>> >>>Yes they might. But CLUE is not the place to create completely new facil= ities that are not intended for telepresence systems. >> >>Being able to connect to telepresence system with non-TP devices is=20 >>within the scope of the work, and we think it would create great added va= lue if we have a mechanism which allows offering an optimized "near-telepre= sence experience" also to such devices. > >Yes, connecting telepresence systems to legacy devices is within scope. A= nd identifying relationships between streams is within scope.=20 > >Binaural audio is not in either category. It is a specific mode of=20 >audio which for some reason has not been standardized. Telepresence system= s do not use it, and there is no SDP defined for legacy devices to use eith= er And It is not a stream relationship like left, right. > >I am not saying that binaural audio has no value; I think it does. But=20 >I don't think it is in scope. There is trouble ahead if every shiny new=20 >media idea becomes CLUE work because some hypothetical future non-telepres= ence device might want to use it to talk to a telepresence system through a= middle box. We are not talking about any "hypothetical future non-telepresence device".= We are talking about the most widely spread communication device in the wo= rld, and we are talking about providing means for optimizing the user exper= ience for such a device. As we see it this is perfectly inline with the CLU= E charter. >>>It is about having a generic mechanism for negotiation of centralized me= dia mixing usage, if the system supports it. >> >>I don't understand what "negotiate the type of media rendering" means. = Maybe you can describe more precisely what is meant? > >It's about two things: > >First, to be able to find out whether the system supports centralized rend= ering in the first place. Note that such functionality is optional. > >Second, to be able to request centralized rendering, and the type of rende= ring. > >What is the type of rendering? If this is a general facility not limited t= o binaural audio, then I'd like some other "types" to be identified.=20 For audio, you could have "mono", and different types of "stereo" (e.g plai= n, paning, binaural). Note that we are not suggesting that, within the CLUE work, start to define= every possible type, or even specific types. We propose a generic mechanis= m. For video, once you have negotiated the usage of centralized rendering, you= could negotiate whether the rendered stream is "most active speaker", and = different types of layout options. I do realize, however, that we might not= be talking about "rendering type" in the same meaning as for audio in that= case. It might be more related to "rendering control", and if we want that= it should probably be covered in a separate requirement. >And I think we will need a definition. As it stands, I have no idea how to= tell if a proposed solution meets this requirement or not. As discussed the interim meeting, the task was to come up with suitable wor= ding. I've tried to do that, but of course I am willing to do modifications= in order to clarify the text. Regards, Christer =20 ________________________________ From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: 15. kes=E4kuuta 2011 13:48 To: Christer Holmberg Cc: clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing =09 =09 On Wed, Jun 15, 2011 at 6:08 AM, Christer Holmberg wrote: =09 Hi Stephen, =09 >>>If some other WG (for instance MMUSIC) defined a mechanism for >>>general use of binaural audio for SIP/RTP, then I would fully support = requirements that such a facility should be enabled in CLUE. >>> >>>But I do not think that CLUE is the right place to invent negotiation >>>of binaural audio. Telepresence system users generally do not use hea= dsets. >> >>No, but users communicating with a telepresence system using other type= s of devices may. > >Yes they might. But CLUE is not the place to create completely new facil= ities that are not intended for telepresence systems. =09 =09 Being able to connect to telepresence system with non-TP devices is withi= n the scope of the work, and we think it would create great added value if = we have a mechanism which allows offering an optimized "near-telepresence e= xperience" also to such devices. =09 Yes, connecting telepresence systems to legacy devices is within scope. A= nd identifying relationships between streams is within scope.=20 =09 Binaural audio is not in either category. It is a specific mode of audio = which for some reason has not been standardized. Telepresence systems do n= ot use it, and there is no SDP defined for legacy devices to use either An= d It is not a stream relationship like left, right. =20 =09 I am not saying that binaural audio has no value; I think it does. But I= don't think it is in scope. There is trouble ahead if every shiny new medi= a idea becomes CLUE work because some hypothetical future non-telepresence = device might want to use it to talk to a telepresence system through a midd= le box. =09 >>It is about having a generic mechanism for negotiation of centralized m= edia mixing usage, if the system supports it. > >I don't understand what "negotiate the type of media rendering" means. = Maybe you can describe more precisely what is meant? =09 =09 It's about two things: =09 First, to be able to find out whether the system supports centralized ren= dering in the first place. Note that such functionality is optional. =09 Second, to be able to request centralized rendering, and the type of rend= ering. =09 What is the type of rendering? If this is a general facility not limited = to binaural audio, then I'd like some other "types" to be identified. And I= think we will need a definition. As it stands, I have no idea how to tel= l if a proposed solution meets this requirement or not. =09 =09 (Solution wise, we might be talking about some SDP attributes in order to= do this) =09 Note that this proposal does not have any impact on the definitions, or o= n the telepresence "room model". =09 Regards, =09 Christer =09 =09 =09 =09 =09 On Tue, Jun 14, 2011 at 10:22 AM, Christer Holmberg > wrote: =09 Hi, =09 During the last interim meeting (May 12th) we discussed a = requirement proposal stating that an endpoint must be able to request central a= udio rendering of different predefined formats, including 3D binaural ren= dering. (Link to proposal: http://www.ietf.org/mail-archive/web/cl= ue/current/msg00179.html) =09 The proposal was well received, with the reservation that = it should not be mandatory =09 for the solution to implement centralized 3D binaural rend= ering, i.e.an endpoint should =09 be able to request 3D binaural rendering, but had no guara= nty that such rendering was supported by the system. =09 It was decided to look how such requirement could look lik= e. =09 When I look the -03 version of the req draft, Requirement = 2c states: =09 "The solution MUST NOT preclude the use of binaural aud= io." =09 I think that requirement is unclear, and it doesn't really= give any guidance to our work. =09 Due to that, and also due to the fact that rather than tal= king about specific rendering types, I would like to propose more general requirement text on t= he negotiation of the media mixing type, and the usage of centralized media mixing in the first pla= ce. =09 The mechanism would be extendable, so new types can be add= ed in future. =09 So, the proposed requirements are: =09 REQ-x: It MUST be possible to negotiate the usage of ce= ntralized media mixing. System support of centralized media mixing is optio= nal. =09 REQ-y: When centralized media mixing is used, it MUST b= e possible to negotiate the type of media rendering provided for each media= stream received by a client. =09 Regards, =09 Christer From stephane.cazeaux@orange-ftgroup.com Wed Jun 15 09:07:27 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E115C11E811F for ; Wed, 15 Jun 2011 09:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1b9ANKhoetB for ; Wed, 15 Jun 2011 09:07:27 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5B51C11E8081 for ; Wed, 15 Jun 2011 09:07:26 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F13AB7B800C; Wed, 15 Jun 2011 18:08:41 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id CFDDA7B8005; Wed, 15 Jun 2011 18:08:41 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr ([10.194.32.11]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 18:03:11 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH01.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Wed, 15 Jun 2011 18:03:10 +0200 From: To: , Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: AcwrSap3NvbGElwge02VJzOdJpilfQAFQ1YQAAUPPzA= Date: Wed, 15 Jun 2011 16:03:09 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1878@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A7D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A7D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.198.77] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jun 2011 16:03:11.0410 (UTC) FILETIME=[B9BAD920:01CC2B75] Cc: clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:07:28 -0000 Hi, I agree that these requirements are meaningful for CLUE, and correspond to = valid use cases of telepresence experience. > For video, once you have negotiated the usage of centralized rendering, y= ou could negotiate whether the rendered > stream is "most active speaker", and different types of layout options. I= do realize, however, that we might not be > talking about "rendering type" in the same meaning as for audio in that c= ase. It might be more related to "rendering > control", and if we want that it should probably be covered in a separate= requirement. What do you think of the wording "rendering policy"? Stephane.=20 -----Message d'origine----- De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de C= hrister Holmberg Envoy=E9=A0: mercredi 15 juin 2011 15:29 =C0=A0: Stephen Botzko Cc=A0: clue@ietf.org Objet=A0: Re: [clue] Requirement on centralized media mixing Hi Stephen, >>>>>If some other WG (for instance MMUSIC) defined a mechanism for=20 >>>>>general use of binaural audio for SIP/RTP, then I would fully support = requirements that such a facility should be enabled in CLUE. >>>>> >>>>>But I do not think that CLUE is the right place to invent=20 >>>>>negotiation of binaural audio. Telepresence system users generally do= not use headsets. >>>> >>>>No, but users communicating with a telepresence system using other type= s of devices may. >>> >>>Yes they might. But CLUE is not the place to create completely new facil= ities that are not intended for telepresence systems. >> >>Being able to connect to telepresence system with non-TP devices is=20 >>within the scope of the work, and we think it would create great added va= lue if we have a mechanism which allows offering an optimized "near-telepre= sence experience" also to such devices. > >Yes, connecting telepresence systems to legacy devices is within scope. A= nd identifying relationships between streams is within scope.=20 > >Binaural audio is not in either category. It is a specific mode of=20 >audio which for some reason has not been standardized. Telepresence system= s do not use it, and there is no SDP defined for legacy devices to use eith= er And It is not a stream relationship like left, right. > >I am not saying that binaural audio has no value; I think it does. But=20 >I don't think it is in scope. There is trouble ahead if every shiny new=20 >media idea becomes CLUE work because some hypothetical future non-telepres= ence device might want to use it to talk to a telepresence system through a= middle box. We are not talking about any "hypothetical future non-telepresence device".= We are talking about the most widely spread communication device in the wo= rld, and we are talking about providing means for optimizing the user exper= ience for such a device. As we see it this is perfectly inline with the CLU= E charter. >>>It is about having a generic mechanism for negotiation of centralized me= dia mixing usage, if the system supports it. >> >>I don't understand what "negotiate the type of media rendering" means. = Maybe you can describe more precisely what is meant? > >It's about two things: > >First, to be able to find out whether the system supports centralized rend= ering in the first place. Note that such functionality is optional. > >Second, to be able to request centralized rendering, and the type of rende= ring. > >What is the type of rendering? If this is a general facility not limited t= o binaural audio, then I'd like some other "types" to be identified.=20 For audio, you could have "mono", and different types of "stereo" (e.g plai= n, paning, binaural). Note that we are not suggesting that, within the CLUE work, start to define= every possible type, or even specific types. We propose a generic mechanis= m. For video, once you have negotiated the usage of centralized rendering, you= could negotiate whether the rendered stream is "most active speaker", and = different types of layout options. I do realize, however, that we might not= be talking about "rendering type" in the same meaning as for audio in that= case. It might be more related to "rendering control", and if we want that= it should probably be covered in a separate requirement. >And I think we will need a definition. As it stands, I have no idea how to= tell if a proposed solution meets this requirement or not. As discussed the interim meeting, the task was to come up with suitable wor= ding. I've tried to do that, but of course I am willing to do modifications= in order to clarify the text. Regards, Christer =20 ________________________________ From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: 15. kes=E4kuuta 2011 13:48 To: Christer Holmberg Cc: clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing =09 =09 On Wed, Jun 15, 2011 at 6:08 AM, Christer Holmberg wrote: =09 Hi Stephen, =09 >>>If some other WG (for instance MMUSIC) defined a mechanism for >>>general use of binaural audio for SIP/RTP, then I would fully support = requirements that such a facility should be enabled in CLUE. >>> >>>But I do not think that CLUE is the right place to invent negotiation >>>of binaural audio. Telepresence system users generally do not use hea= dsets. >> >>No, but users communicating with a telepresence system using other type= s of devices may. > >Yes they might. But CLUE is not the place to create completely new facil= ities that are not intended for telepresence systems. =09 =09 Being able to connect to telepresence system with non-TP devices is withi= n the scope of the work, and we think it would create great added value if = we have a mechanism which allows offering an optimized "near-telepresence e= xperience" also to such devices. =09 Yes, connecting telepresence systems to legacy devices is within scope. A= nd identifying relationships between streams is within scope.=20 =09 Binaural audio is not in either category. It is a specific mode of audio = which for some reason has not been standardized. Telepresence systems do n= ot use it, and there is no SDP defined for legacy devices to use either An= d It is not a stream relationship like left, right. =20 =09 I am not saying that binaural audio has no value; I think it does. But I= don't think it is in scope. There is trouble ahead if every shiny new medi= a idea becomes CLUE work because some hypothetical future non-telepresence = device might want to use it to talk to a telepresence system through a midd= le box. =09 >>It is about having a generic mechanism for negotiation of centralized m= edia mixing usage, if the system supports it. > >I don't understand what "negotiate the type of media rendering" means. = Maybe you can describe more precisely what is meant? =09 =09 It's about two things: =09 First, to be able to find out whether the system supports centralized ren= dering in the first place. Note that such functionality is optional. =09 Second, to be able to request centralized rendering, and the type of rend= ering. =09 What is the type of rendering? If this is a general facility not limited = to binaural audio, then I'd like some other "types" to be identified. And I= think we will need a definition. As it stands, I have no idea how to tel= l if a proposed solution meets this requirement or not. =09 =09 (Solution wise, we might be talking about some SDP attributes in order to= do this) =09 Note that this proposal does not have any impact on the definitions, or o= n the telepresence "room model". =09 Regards, =09 Christer =09 =09 =09 =09 =09 On Tue, Jun 14, 2011 at 10:22 AM, Christer Holmberg > wrote: =09 Hi, =09 During the last interim meeting (May 12th) we discussed a = requirement proposal stating that an endpoint must be able to request central a= udio rendering of different predefined formats, including 3D binaural ren= dering. (Link to proposal: http://www.ietf.org/mail-archive/web/cl= ue/current/msg00179.html) =09 The proposal was well received, with the reservation that = it should not be mandatory =09 for the solution to implement centralized 3D binaural rend= ering, i.e.an endpoint should =09 be able to request 3D binaural rendering, but had no guara= nty that such rendering was supported by the system. =09 It was decided to look how such requirement could look lik= e. =09 When I look the -03 version of the req draft, Requirement = 2c states: =09 "The solution MUST NOT preclude the use of binaural aud= io." =09 I think that requirement is unclear, and it doesn't really= give any guidance to our work. =09 Due to that, and also due to the fact that rather than tal= king about specific rendering types, I would like to propose more general requirement text on t= he negotiation of the media mixing type, and the usage of centralized media mixing in the first pla= ce. =09 The mechanism would be extendable, so new types can be add= ed in future. =09 So, the proposed requirements are: =09 REQ-x: It MUST be possible to negotiate the usage of ce= ntralized media mixing. System support of centralized media mixing is optio= nal. =09 REQ-y: When centralized media mixing is used, it MUST b= e possible to negotiate the type of media rendering provided for each media= stream received by a client. =09 Regards, =09 Christer _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Wed Jun 15 09:08:39 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AEA11E8158 for ; Wed, 15 Jun 2011 09:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aV9ZC3IrMDNj for ; Wed, 15 Jun 2011 09:08:38 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6555011E8081 for ; Wed, 15 Jun 2011 09:08:37 -0700 (PDT) Received: by vws12 with SMTP id 12so583935vws.31 for ; Wed, 15 Jun 2011 09:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Xs1ehiIFKeY5mRw/4EqRg1XSPalk6h+LG2wHETTmJ84=; b=V6A1m4q049tyggh3X21o6kVW2cmDRMKD6IC0qDZ+9cKmAaAHtVOsw4MclNRcgTFYQs kSzgQ3NThoI9TrRycBUtWsp3FGijbe9wG4Fjy/n9jFcMzZ66zwvXyV7cGdzNE/HT6AHn GNUFkv4SMB2aaX+MIA6U2C34PukwVVSZIqnc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=URcAS68mcbfdTIJNwXBJMc6lGz9czUnTisQmQs53TCsK+ZULP7MPl6vf5f4OWibqtC odKAFZ+MoHsXqFfDeO419ZERN5Mi0e5A7XN2pXCxTU7UQKSaCxPdBvMKmFBOKD+KHXF0 PVv9g6j1JIBrGxlSJwmOSYQ7amcIkLi0kGq2U= MIME-Version: 1.0 Received: by 10.52.98.5 with SMTP id ee5mr1055349vdb.200.1308154060774; Wed, 15 Jun 2011 09:07:40 -0700 (PDT) Received: by 10.52.107.138 with HTTP; Wed, 15 Jun 2011 09:07:40 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A7D@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1878@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A7D@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 12:07:40 -0400 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf307f34a61a9d0004a5c25a74 Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:08:39 -0000 --20cf307f34a61a9d0004a5c25a74 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 15, 2011 at 9:28 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi Stephen, > > >>>>>If some other WG (for instance MMUSIC) defined a mechanism for > >>>>>general use of binaural audio for SIP/RTP, then I would fully suppor= t > requirements that such a facility should be enabled in CLUE. > >>>>> > >>>>>But I do not think that CLUE is the right place to invent > >>>>>negotiation of binaural audio. Telepresence system users generally = do > not use headsets. > >>>> > >>>>No, but users communicating with a telepresence system using other > types of devices may. > >>> > >>>Yes they might. But CLUE is not the place to create completely new > facilities that are not intended for telepresence systems. > >> > >>Being able to connect to telepresence system with non-TP devices is > >>within the scope of the work, and we think it would create great added > value if we have a mechanism which allows offering an optimized > "near-telepresence experience" also to such devices. > > > >Yes, connecting telepresence systems to legacy devices is within scope. > And identifying relationships between streams is within scope. > > > >Binaural audio is not in either category. It is a specific mode of > >audio which for some reason has not been standardized. Telepresence > systems do not use it, and there is no SDP defined for legacy devices to = use > either And It is not a stream relationship like left, right. > > > >I am not saying that binaural audio has no value; I think it does. But > >I don't think it is in scope. There is trouble ahead if every shiny new > >media idea becomes CLUE work because some hypothetical future > non-telepresence device might want to use it to talk to a telepresence > system through a middle box. > > We are not talking about any "hypothetical future non-telepresence device= ". > We are talking about the most widely spread communication device in the > world, and we are talking about providing means for optimizing the user > experience for such a device. As we see it this is perfectly inline with = the > CLUE charter. > Then we disagree on our understanding of the charter... Anyway, SIP doesn't negotiate binaural audio at all, so I don't see how binaural audio is wide-spread communication. Also, I suspect you'd want binaural audio enabled generally in audio conferences, not just for CLUE devices. This is not really (IMO) related to multiple streams. It is more broadly applicable than that. > >>>It is about having a generic mechanism for negotiation of centralized > media mixing usage, if the system supports it. > >> > >>I don't understand what "negotiate the type of media rendering" means. > Maybe you can describe more precisely what is meant? > > > >It's about two things: > > > >First, to be able to find out whether the system supports centralized > rendering in the first place. Note that such functionality is optional. > > > >Second, to be able to request centralized rendering, and the type of > rendering. > > > >What is the type of rendering? If this is a general facility not limited > to binaural audio, then I'd like some other "types" to be identified. > > For audio, you could have "mono", and different types of "stereo" (e.g > plain, paning, binaural). > > Note that we are not suggesting that, within the CLUE work, start to defi= ne > every possible type, or even specific types. We propose a generic mechani= sm. > > For video, once you have negotiated the usage of centralized rendering, y= ou > could negotiate whether the rendered stream is "most active speaker", and > different types of layout options. I do realize, however, that we might n= ot > be talking about "rendering type" in the same meaning as for audio in tha= t > case. It might be more related to "rendering control", and if we want tha= t > it should probably be covered in a separate requirement. > > >And I think we will need a definition. As it stands, I have no idea how = to > tell if a proposed solution meets this requirement or not. > > As discussed the interim meeting, the task was to come up with suitable > wording. I've tried to do that, but of course I am willing to do > modifications in order to clarify the text. > > Regards, > > Christer > > > > > ________________________________ > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: 15. kes=E4kuuta 2011 13:48 > To: Christer Holmberg > Cc: clue@ietf.org > Subject: Re: [clue] Requirement on centralized media mixing > > > > > On Wed, Jun 15, 2011 at 6:08 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > Hi Stephen, > > > >>>If some other WG (for instance MMUSIC) defined a > mechanism for > >>>general use of binaural audio for SIP/RTP, then I would > fully support requirements that such a facility should be enabled in CLUE= . > >>> > >>>But I do not think that CLUE is the right place to inve= nt > negotiation > >>>of binaural audio. Telepresence system users generally > do not use headsets. > >> > >>No, but users communicating with a telepresence system > using other types of devices may. > > > >Yes they might. But CLUE is not the place to create > completely new facilities that are not intended for telepresence systems. > > > Being able to connect to telepresence system with non-TP > devices is within the scope of the work, and we think it would create gre= at > added value if we have a mechanism which allows offering an optimized > "near-telepresence experience" also to such devices. > > > Yes, connecting telepresence systems to legacy devices is within > scope. And identifying relationships between streams is within scope. > > Binaural audio is not in either category. It is a specific mode o= f > audio which for some reason has not been standardized. Telepresence syst= ems > do not use it, and there is no SDP defined for legacy devices to use eith= er > And It is not a stream relationship like left, right. > > I am not saying that binaural audio has no value; I think it does. > But I don't think it is in scope. There is trouble ahead if every shiny n= ew > media idea becomes CLUE work because some hypothetical future > non-telepresence device might want to use it to talk to a telepresence > system through a middle box. > > > > >>It is about having a generic mechanism for negotiation o= f > centralized media mixing usage, if the system supports it. > > > >I don't understand what "negotiate the type of media > rendering" means. Maybe you can describe more precisely what is meant? > > > It's about two things: > > First, to be able to find out whether the system supports > centralized rendering in the first place. Note that such functionality is > optional. > > Second, to be able to request centralized rendering, and t= he > type of rendering. > > > What is the type of rendering? If this is a general facility not > limited to binaural audio, then I'd like some other "types" to be > identified. And I think we will need a definition. As it stands, I have= no > idea how to tell if a proposed solution meets this requirement or not. > > > > > (Solution wise, we might be talking about some SDP > attributes in order to do this) > > Note that this proposal does not have any impact on the > definitions, or on the telepresence "room model". > > > Regards, > > Christer > > > > > > On Tue, Jun 14, 2011 at 10:22 AM, Christer > Holmberg christer.holmberg@ericsson.com>> wrote: > > Hi, > > During the last interim meeting (May 12th) = we > discussed a requirement proposal > stating that an endpoint must be able to > request central audio rendering > of different predefined formats, including = 3D > binaural rendering. > (Link to proposal: > http://www.ietf.org/mail-archive/web/clue/current/msg00179.html) > > The proposal was well received, with the > reservation that it should not be mandatory > > for the solution to implement centralized 3= D > binaural rendering, i.e.an endpoint should > > be able to request 3D binaural rendering, b= ut > had no guaranty that such rendering was > supported by the system. > > It was decided to look how such requirement > could look like. > > When I look the -03 version of the req draf= t, > Requirement 2c states: > > "The solution MUST NOT preclude the use = of > binaural audio." > > I think that requirement is unclear, and it > doesn't really give any guidance to our work. > > Due to that, and also due to the fact that > rather than talking about specific rendering types, > I would like to propose more general > requirement text on the negotiation of the media mixing type, > and the usage of centralized media mixing i= n > the first place. > > The mechanism would be extendable, so new > types can be added in future. > > So, the proposed requirements are: > > REQ-x: It MUST be possible to negotiate > the usage of centralized media mixing. System support of centralized medi= a > mixing is optional. > > REQ-y: When centralized media mixing is > used, it MUST be possible to negotiate the type of media rendering provid= ed > for each media stream received by a client. > > Regards, > > Christer > > > --20cf307f34a61a9d0004a5c25a74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 9:28 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Stephen,

>>>>>If some other WG (for instance MMUSIC) defined a mechan= ism for
>>>>>general use of binaural audio for SIP/RTP, then I would= fully support requirements that such a facility should be enabled in CLUE.=
>>>>>
>>>>>But I do not think that CLUE is the right place to inve= nt
>>>>>negotiation of binaural audio. =A0Telepresence system u= sers generally do not use headsets.
>>>>
>>>>No, but users communicating with a telepresence system usin= g other types of devices may.
>>>
>>>Yes they might. But CLUE is not the place to create completely = new facilities that are not intended for telepresence systems.
>>
>>Being able to connect to telepresence system with non-TP devices is=
>>within the scope of the work, and we think it would create great ad= ded value if we have a mechanism which allows offering an optimized "n= ear-telepresence experience" also to such devices.
>
>Yes, connecting telepresence systems to legacy devices is within scope.= =A0And identifying relationships between streams is within scope.
>
>Binaural audio is not in either category. It is a specific mode of
>audio which for some reason has not been standardized. Telepresence sys= tems do not use it, and there is no SDP defined for legacy devices to use e= ither =A0And It is not a stream relationship like left, right.
>
>I am not saying that binaural audio has no value; I think it does. But<= br> >I don't think it is in scope. There is trouble ahead if every shiny= new
>media idea becomes CLUE work because some hypothetical future non-telep= resence device might want to use it to talk to a telepresence system throug= h a middle box.

We are not talking about any "hypothetical future non-telepresen= ce device". We are talking about the most widely spread communication = device in the world, and we are talking about providing means for optimizin= g the user experience for such a device. As we see it this is perfectly inl= ine with the CLUE charter.

Then we disagree on our understanding of the charter.= ..

Anyway, SIP doesn't negotiate binaural audio at all, so I do= n't see how binaural audio is wide-spread communication.=A0 Also, I sus= pect you'd want binaural audio enabled generally in audio conferences, = not just for CLUE devices.=A0 This is not really (IMO) related to multiple = streams.=A0 It is more broadly applicable than that.


>>>It is about having a generic mechanism for negotiation of centr= alized media mixing usage, if the system supports it.
>>
>>I don't understand what =A0"negotiate the type of media re= ndering" means. =A0Maybe you can describe more precisely what is meant= ?
>
>It's about two things:
>
>First, to be able to find out whether the system supports centralized r= endering in the first place. Note that such functionality is optional.
>
>Second, to be able to request centralized rendering, and the type of re= ndering.
>
>What is the type of rendering? If this is a general facility not limite= d to binaural audio, then I'd like some other "types" to be i= dentified.

For audio, you could have "mono", and different types of &q= uot;stereo" (e.g plain, paning, binaural).

Note that we are not suggesting that, within the CLUE work, start to define= every possible type, or even specific types. We propose a generic mechanis= m.

For video, once you have negotiated the usage of centralized rendering, you= could negotiate whether the rendered stream is "most active speaker&q= uot;, and different types of layout options. I do realize, however, that we= might not be talking about "rendering type" in the same meaning = as for audio in that case. It might be more related to "rendering cont= rol", and if we want that it should probably be covered in a separate = requirement.

>And I think we will need a definition. As it stands, I have no idea how= to tell if a proposed solution meets this requirement or not.

As discussed the interim meeting, the task was to come up with suitab= le wording. I've tried to do that, but of course I am willing to do mod= ifications in order to clarify the text.

Regards,

Christer




________________________________

=A0 =A0 =A0 =A0From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
=A0 =A0 =A0 =A0Sent: 15. kes=E4kuuta 2011 13:48
=A0 =A0 =A0 =A0To: Christer Holmberg
=A0 =A0 =A0 =A0Cc: clue@ietf.org
=A0 =A0 =A0 =A0Subject: Re: [clue] Requirement on centralized media mixing=




=A0 =A0 =A0 =A0On Wed, Jun 15, 2011 at 6:08 AM, Christer Holmberg <christer.holmberg@ericsson.co= m> wrote:



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hi Stephen,


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>If some other WG (for instance = MMUSIC) defined a mechanism for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>general use of binaural audio f= or SIP/RTP, then I would fully support requirements that such a facility sh= ould be enabled in CLUE.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>But I do not think that CLUE is= the right place to invent negotiation
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>>of binaural audio. =A0Teleprese= nce system users generally do not use headsets.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>No, but users communicating with a = telepresence system using other types of devices may.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>Yes they might. But CLUE is not the pla= ce to create completely new facilities that are not intended for telepresen= ce systems.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Being able to connect to telepresence syste= m with non-TP devices is within the scope of the work, and we think it woul= d create great added value if we have a mechanism which allows offering an = optimized "near-telepresence experience" also to such devices.

=A0 =A0 =A0 =A0Yes, connecting telepresence systems to legacy devices is w= ithin scope. =A0And identifying relationships between streams is within sco= pe.

=A0 =A0 =A0 =A0Binaural audio is not in either category. =A0It is a specif= ic mode of audio which for some reason has not been standardized. =A0Telepr= esence systems do not use it, and there is no SDP defined for legacy device= s to use either =A0And It is not a stream relationship like left, right.
=A0 =A0 =A0 =A0I am not saying that binaural audio has no value; I think i= t does. =A0 But I don't think it is in scope. There is trouble ahead if= every shiny new media idea becomes CLUE work because some hypothetical fut= ure non-telepresence device might want to use it to talk to a telepresence = system through a middle box.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>>It is about having a generic mechan= ism for negotiation of centralized media mixing usage, if the system suppor= ts it.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>I don't understand what =A0"ne= gotiate the type of media rendering" means. =A0Maybe you can describe = more precisely what is meant?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0It's about two things:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0First, to be able to find out whether the s= ystem supports centralized rendering in the first place. Note that such fun= ctionality is optional.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Second, to be able to request centralized r= endering, and the type of rendering.


=A0 =A0 =A0 =A0What is the type of rendering? =A0If this is a general faci= lity not limited to binaural audio, then I'd like some other "type= s" to be identified. And I think we will need =A0a definition. =A0As i= t stands, I have no idea how to tell if a proposed solution meets this requ= irement or not.




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Solution wise, we might be talking about s= ome SDP attributes in order to do this)

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Note that this proposal does not have any i= mpact on the definitions, or on the telepresence "room model".

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

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Christer





=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Tue, Jun 14= , 2011 at 10:22 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>= > wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 During the las= t interim meeting (May 12th) we discussed a requirement proposal
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stating that a= n endpoint must be able to request central audio rendering
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of different p= redefined formats, including 3D binaural rendering.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Link to propo= sal: http://www.ietf.org/mail-archive/web/clue/current/m= sg00179.html)

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The proposal w= as well received, with the reservation that it should not be mandatory

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for the soluti= on to implement centralized 3D binaural rendering, i.e.an<http://i.e.an> endpoint should

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 be able to req= uest 3D binaural rendering, but had no guaranty that such rendering was
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 supported by t= he system.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 It was decided= to look how such requirement could look like.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 When I look th= e -03 version of the req draft, Requirement 2c states:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"T= he solution MUST NOT preclude the use of binaural audio."

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I think that r= equirement is unclear, and it doesn't really give any guidance to our w= ork.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Due to that, a= nd also due to the fact that rather than talking about specific rendering t= ypes,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I would like t= o propose more general requirement text on the negotiation of the media mix= ing type,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and the usage = of centralized media mixing in the first place.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The mechanism = would be extendable, so new types can be added in future.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 So, the propos= ed requirements are:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 REQ-x: =A0 =A0= It MUST be possible to negotiate the usage of centralized media mixing. Sys= tem support of centralized media mixing is optional.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 REQ-y: =A0 =A0= When centralized media mixing is used, it MUST be possible to negotiate the= type of media rendering provided for each media stream received by a clien= t.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Regards,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Christer



--20cf307f34a61a9d0004a5c25a74-- From john.elwell@siemens-enterprise.com Wed Jun 15 09:30:28 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542CC11E8081 for ; Wed, 15 Jun 2011 09:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVaOxFcNENBc for ; Wed, 15 Jun 2011 09:30:27 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 5C8A311E808D for ; Wed, 15 Jun 2011 09:30:27 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1308155416!40651843!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 9644 invoked from network); 15 Jun 2011 16:30:16 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-6.tower-27.messagelabs.com with SMTP; 15 Jun 2011 16:30:16 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 89EB81EB83ED for ; Wed, 15 Jun 2011 18:30:25 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 15 Jun 2011 18:30:25 +0200 From: "Elwell, John" To: "clue@ietf.org" Date: Wed, 15 Jun 2011 18:30:24 +0200 Thread-Topic: Comment on requirements-03 - aspect ratio Thread-Index: AcwreYbvuyWp0YkTT8mIyfuGzYlTTA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] Comment on requirements-03 - aspect ratio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:30:28 -0000 We have: "REQMT-1: The solution MUST support a description of the spatial arrangement of source video images sent in video streams which enables a satisfactory reproduction at the receiver of the original scene. This applies to each site in a point to point or a multipoint meeting and refers to the spatial ordering within a site, not to the ordering of images between sites." and below that: "REQMT-1c: The solution MUST support a means to communicate the aspect ratio." Is this the aspect ratio of a particular camera? If so, what is the relevan= ce of this to REQMT-1, which is concerned with the spatial ordering of vide= o images? Also REQMT-6 addresses aspect ratios, so how does REQMT-1c relate= to REQMT-6? John From christer.holmberg@ericsson.com Wed Jun 15 10:59:45 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097A611E80C7 for ; Wed, 15 Jun 2011 10:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehQymskOjSnD for ; Wed, 15 Jun 2011 10:59:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1C13311E8081 for ; Wed, 15 Jun 2011 10:59:43 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-3e-4df8f30f2b16 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2F.F3.20773.F03F8FD4; Wed, 15 Jun 2011 19:59:43 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 15 Jun 2011 19:59:42 +0200 From: Christer Holmberg To: Stephen Botzko Date: Wed, 15 Jun 2011 19:59:42 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwrdnxt3dSpInMsRyKf460SfVRusgACy9n9 Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A44B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1878@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A7D@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 17:59:45 -0000 Hi Stephen, >>>>>>>If some other WG (for instance MMUSIC) defined a mechanism for >>>>>>>general use of binaural audio for SIP/RTP, then I would fully suppor= t requirements that such a facility should be enabled in CLUE. >>>>>>> >>>>>>>But I do not think that CLUE is the right place to invent >>>>>>>negotiation of binaural audio. Telepresence system users generally = do not use headsets. >>>>>> >>>>>>No, but users communicating with a telepresence system using other ty= pes of devices may. >>>>> >>>>>Yes they might. But CLUE is not the place to create completely new fac= ilities that are not intended for telepresence systems. >>>> >>>>Being able to connect to telepresence system with non-TP devices is >>>>within the scope of the work, and we think it would create great added = value if we have a mechanism which allows offering an optimized "near-telep= resence experience" also to such devices. >>> >>>Yes, connecting telepresence systems to legacy devices is within scope. = And identifying relationships between streams is within scope. >>> >>>Binaural audio is not in either category. It is a specific mode of >>>audio which for some reason has not been standardized. Telepresence syst= ems do not use it, and there is no SDP defined for legacy devices to use ei= ther And It is not a stream relationship like left, right. >>> >>>I am not saying that binaural audio has no value; I think it does. But >>>I don't think it is in scope. There is trouble ahead if every shiny new >>>media idea becomes CLUE work because some hypothetical future non-telepr= esence device might want to use it to talk to a telepresence system through= a middle box. >>> >>We are not talking about any "hypothetical future non-telepresence device= ". We are talking about the most widely spread communication device in the = world, and we are talking about providing means for optimizing the user exp= erience for such a device. As we see it this is perfectly >>inline with the CLUE charter. > >Then we disagree on our understanding of the charter... The charter states: "The WG will create specifications for SIP-based conferencing systems to enable communication of information about media streams so that a sending system, receiving system, or intermediate system can make reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimize use= r experience." ...and what we are proposing is exactly that: namely to provide support for= a rendering type that is aimed for optimizing the user experience for mobile = endpoints. >Anyway, SIP doesn't negotiate binaural audio at all, so I don't see how bi= naural audio is wide-spread communication. Also, I suspect you'd want >binaural audio enabled generally in audio conferences, not just for CLUE d= evices. This is not really (IMO) related to multiple streams. It is more >broadly applicable than that. It is related to interworking with multistream telepresence clients, and to= be able to get the best possible experience when a mobile device supports only a single stream. Another example: if a mobile user is in a area with very bad radio covereag= e/low bandwidth, it could request the media to be rendered in mono. Regards, Christer From stephen.botzko@gmail.com Wed Jun 15 12:25:55 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA17D11E815A for ; Wed, 15 Jun 2011 12:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FquNN8zPShi for ; Wed, 15 Jun 2011 12:25:54 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76B0411E8151 for ; Wed, 15 Jun 2011 12:25:54 -0700 (PDT) Received: by vws12 with SMTP id 12so788826vws.31 for ; Wed, 15 Jun 2011 12:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eE69YAaVE78Wc+oPOaL/ir2u/xDTqgwQMg7L0vs1CFM=; b=qSur1JGrZfODHiNuqXqVbjsje8VS/Ao6EaWW7kScGr7c5y1sg9raTJB+kRubZxXrOV oZu8gEgf1IWUX56Dc8Tc6PZ0xFOBR3G88bXD5Eo55MoR7xNLGT4Vg8/GGk5T/fm2d9av iKYkeSXfPxFBGJk64wWlys0CpKvv2IQfgTdvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EPMjF0PmDK3aYYLA5h4iRR/w5oLJEcu05lsduT6hg2IclrcVroWOmQjBqvp/mT5/ez 1zfOmCWqVXN3RM/02cqZtWAcI5oNlsJq+T0yHaM86jC8U20lkg828IGIe/Ts+XlpmNzy 8XpWneYL9/PU75Pqg/092iplW4Hn3p7GcgjME= MIME-Version: 1.0 Received: by 10.52.66.206 with SMTP id h14mr716vdt.40.1308165882322; Wed, 15 Jun 2011 12:24:42 -0700 (PDT) Received: by 10.52.107.138 with HTTP; Wed, 15 Jun 2011 12:24:42 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A44B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1878@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1A7D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A44B@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Jun 2011 15:24:42 -0400 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf307cfd82b91f9f04a5c51ac7 Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 19:25:55 -0000 --20cf307cfd82b91f9f04a5c51ac7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 15, 2011 at 1:59 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Stephen, > > >>>>>>>If some other WG (for instance MMUSIC) defined a mechanism for > >>>>>>>general use of binaural audio for SIP/RTP, then I would fully > support requirements that such a facility should be enabled in CLUE. > >>>>>>> > >>>>>>>But I do not think that CLUE is the right place to invent > >>>>>>>negotiation of binaural audio. Telepresence system users generally > do not use headsets. > >>>>>> > >>>>>>No, but users communicating with a telepresence system using other > types of devices may. > >>>>> > >>>>>Yes they might. But CLUE is not the place to create completely new > facilities that are not intended for telepresence systems. > >>>> > >>>>Being able to connect to telepresence system with non-TP devices is > >>>>within the scope of the work, and we think it would create great added > value if we have a mechanism which allows offering an optimized > "near-telepresence experience" also to such devices. > >>> > >>>Yes, connecting telepresence systems to legacy devices is within scope. > And identifying relationships between streams is within scope. > >>> > >>>Binaural audio is not in either category. It is a specific mode of > >>>audio which for some reason has not been standardized. Telepresence > systems do not use it, and there is no SDP defined for legacy devices to use > either And It is not a stream relationship like left, right. > >>> > >>>I am not saying that binaural audio has no value; I think it does. But > >>>I don't think it is in scope. There is trouble ahead if every shiny new > >>>media idea becomes CLUE work because some hypothetical future > non-telepresence device might want to use it to talk to a telepresence > system through a middle box. > >>> > >>We are not talking about any "hypothetical future non-telepresence > device". We are talking about the most widely spread communication device in > the world, and we are talking about providing means for optimizing the user > experience for such a device. As we see it this is perfectly > >>inline with the CLUE charter. > > > >Then we disagree on our understanding of the charter... > > > > The charter states: > > > > "The WG will create specifications for SIP-based conferencing systems > to enable communication of information about media streams so that a > sending system, receiving system, or intermediate system can make > reasonable decisions about transmitting, selecting, and rendering > media streams. This enables systems to make choices that optimize user > experience." > > > Yes, that is the introduction. The charter then goes on to list specifics, and nothing further on leads me to believe that binaural audio standardization is in scope. Defining spatial relationships is in scope, but binaural audio standardization is about signaling / negotiating the use of HRTF (Head Related Transfer Functions) filters in the proposed central mixer, which in itself is not about defining relationships between streams, etc. All I am saying is that binaural audio should be taken to MMUSIC. Not that it is a bad idea. > ...and what we are proposing is exactly that: namely to provide support for > a > > rendering type that is aimed for optimizing the user experience for mobile > endpoints. > > >Anyway, SIP doesn't negotiate binaural audio at all, so I don't see how > binaural audio is wide-spread communication. Also, I suspect you'd want > >binaural audio enabled generally in audio conferences, not just for CLUE > devices. This is not really (IMO) related to multiple streams. It is more > >broadly applicable than that. > > > > It is related to interworking with multistream telepresence clients, and to > be able to get the best possible experience when a mobile device supports > > only a single stream. > > > > Another example: if a mobile user is in a area with very bad radio > covereage/low bandwidth, it could request the media to be rendered in mono. > > > > Regards, > > > > Christer > > > > > --20cf307cfd82b91f9f04a5c51ac7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 15, 2011 at 1:59 PM, Christe= r Holmberg <christer.holmberg@ericsson.com> wro= te:
Hi Stephen,

>>>>>>>If some other WG (for instance MMUSIC) defined = a mechanism for
>>>>>>>general use of binaural audio for SIP/RTP, then= I would fully support requirements that such a facility should be enabled = in CLUE.
>>>>>>>
>>>>>>>But I do not think that CLUE is the right place= to invent
>>>>>>>negotiation of binaural audio. =A0Telepresence = system users generally do not use headsets.
>>>>>>
>>>>>>No, but users communicating with a telepresence sys= tem using other types of devices may.
>>>>>
>>>>>Yes they might. But CLUE is not the place to create com= pletely new facilities that are not intended for telepresence systems.
>>>>
>>>>Being able to connect to telepresence system with non-TP de= vices is
>>>>within the scope of the work, and we think it would create = great added value if we have a mechanism which allows offering an optimized= "near-telepresence experience" also to such devices.
>>>
>>>Yes, connecting telepresence systems to legacy devices is withi= n scope. =A0And identifying relationships between streams is within scope.<= br> >>>
>>>Binaural audio is not in either category. It is a specific mode= of
>>>audio which for some reason has not been standardized. Telepres= ence systems do not use it, and there is no SDP defined for legacy devices = to use either =A0And It is not a stream relationship like left, right.
>>>
>>>I am not saying that binaural audio has no value; I think it do= es. But
>>>I don't think it is in scope. There is trouble ahead if eve= ry shiny new
>>>media idea becomes CLUE work because some hypothetical future n= on-telepresence device might want to use it to talk to a telepresence syste= m through a middle box.
>>>
>>We are not talking about any "hypothetical future non-telepres= ence device". We are talking about the most widely spread communicatio= n device in the world, and we are talking about providing means for optimiz= ing the user experience for such a device. As we see it this is perfectly >>inline with the CLUE charter.
>
>Then we disagree on our understanding of the charter...



The charter states:



=A0 =A0 =A0"The WG will create specifications for SIP-based conferenc= ing systems
=A0 =A0 =A0to enable communication of information about media streams so t= hat a
=A0 =A0 =A0sending system, receiving system, or intermediate system can ma= ke
=A0 =A0 =A0reasonable decisions about transmitting, selecting, and renderi= ng
=A0 =A0 =A0media streams. This enables systems to make choices that optimi= ze user
=A0 =A0 =A0experience."


=A0
Yes, that is the introduction. The char= ter then goes on to list specifics, and nothing further on leads me to beli= eve that binaural audio standardization is in scope.=A0 Defining spatial re= lationships is in scope, but binaural audio standardization is about signal= ing / negotiating the use of HRTF (Head Related Transfer Functions) filters= in the proposed central mixer, which in itself is not about defining relat= ionships between streams, etc.=A0 All I am saying is that binaural audio sh= ould be taken to MMUSIC.=A0 Not that it is a bad idea.

=A0
...and what we are proposing is exactly that: namely to provide support for= a

rendering type that is aimed for optimizing the user experience for mobile = endpoints.

>Anyway, SIP doesn't negotiate binaural audio at all, so I don't= see how binaural audio is wide-spread communication. =A0Also, I suspect yo= u'd want
>binaural audio enabled generally in audio conferences, not just for CLU= E devices. =A0This is not really (IMO) related to multiple streams. =A0It i= s more
>broadly applicable than that.



It is related to interworking with multistream telepresence clients, = and to be able to get the best possible experience when a mobile device sup= ports

only a single stream.



Another example: if a mobile user is in a area with very bad radio covereag= e/low bandwidth, it could request the media to be rendered in mono.



Regards,



Christer





--20cf307cfd82b91f9f04a5c51ac7-- From keith.drage@alcatel-lucent.com Wed Jun 15 17:06:59 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426E922800D for ; Wed, 15 Jun 2011 17:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9TNVAhBAqP4 for ; Wed, 15 Jun 2011 17:06:58 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBE621F856E for ; Wed, 15 Jun 2011 17:06:58 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5G06mxn011809 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Jun 2011 02:06:48 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 16 Jun 2011 02:06:48 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Stephen Botzko Date: Thu, 16 Jun 2011 02:06:47 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: AcwqtRzbg5jZCBmUSoyqAJooUM2sfAAjta2QAByQNWA= Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1878@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1878@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 00:06:59 -0000 My understanding is that it can define new requirements that can be used by= telepresence systems, even if those new capabilities may have a more gener= al use. What may occur is that then the definition of a solution for a general capa= bility may well be assigned to a more appropriate working group. It is of course perfectly valid to argue that the requirement is inappropri= ate or not useful enough for telepresence sustems. Regards Keith > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: 15 June 2011 11:08 > To: Stephen Botzko > Cc: clue@ietf.org > Subject: Re: [clue] Requirement on centralized media mixing >=20 >=20 > Hi Stephen, >=20 > >>>If some other WG (for instance MMUSIC) defined a mechanism for > >>>general use of binaural audio for SIP/RTP, then I would fully support > requirements that such a facility should be enabled in CLUE. > >>> > >>>But I do not think that CLUE is the right place to invent negotiation > >>>of binaural audio. Telepresence system users generally do not use > headsets. > >> > >>No, but users communicating with a telepresence system using other type= s > of devices may. > > > >Yes they might. But CLUE is not the place to create completely new > facilities that are not intended for telepresence systems. >=20 > Being able to connect to telepresence system with non-TP devices is withi= n > the scope of the work, and we think it would create great added value if > we have a mechanism which allows offering an optimized "near-telepresence > experience" also to such devices. >=20 >=20 > >>It is about having a generic mechanism for negotiation of centralized > media mixing usage, if the system supports it. > > > >I don't understand what "negotiate the type of media rendering" means. > Maybe you can describe more precisely what is meant? >=20 > It's about two things: >=20 > First, to be able to find out whether the system supports centralized > rendering in the first place. Note that such functionality is optional. >=20 > Second, to be able to request centralized rendering, and the type of > rendering. >=20 > (Solution wise, we might be talking about some SDP attributes in order to > do this) >=20 > Note that this proposal does not have any impact on the definitions, or o= n > the telepresence "room model". >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > On Tue, Jun 14, 2011 at 10:22 AM, Christer Holmberg > > > wrote: >=20 > Hi, >=20 > During the last interim meeting (May 12th) we discussed a > requirement proposal > stating that an endpoint must be able to request central audio > rendering > of different predefined formats, including 3D binaural > rendering. > (Link to proposal: http://www.ietf.org/mail- > archive/web/clue/current/msg00179.html) >=20 > The proposal was well received, with the reservation that it > should not be mandatory >=20 > for the solution to implement centralized 3D binaural > rendering, i.e.an endpoint should >=20 > be able to request 3D binaural rendering, but had no guaranty > that such rendering was > supported by the system. >=20 > It was decided to look how such requirement could look like. >=20 > When I look the -03 version of the req draft, Requirement 2c > states: >=20 > "The solution MUST NOT preclude the use of binaural audio." >=20 > I think that requirement is unclear, and it doesn't really > give any guidance to our work. >=20 > Due to that, and also due to the fact that rather than talking > about specific rendering types, > I would like to propose more general requirement text on the > negotiation of the media mixing type, > and the usage of centralized media mixing in the first place. >=20 > The mechanism would be extendable, so new types can be added > in future. >=20 > So, the proposed requirements are: >=20 > REQ-x: It MUST be possible to negotiate the usage of > centralized media mixing. System support of centralized media mixing is > optional. >=20 > REQ-y: When centralized media mixing is used, it MUST be > possible to negotiate the type of media rendering provided for each media > stream received by a client. >=20 > Regards, >=20 > Christer > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Wed Jun 15 21:46:02 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D4D11E811E for ; Wed, 15 Jun 2011 21:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofI51qDtFI6u for ; Wed, 15 Jun 2011 21:45:57 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 023B811E812B for ; Wed, 15 Jun 2011 21:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=25034; q=dns/txt; s=iport; t=1308199557; x=1309409157; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=aY3IKhxxQaUyhiPTDp6boruWjRZZE/VmXSvztMGZLo0=; b=EOQSUaIWWNMIeg2B0K2xMKG3EITfvjw4U2rHwFHi1h1eacolc0Q57jLu DocW+1OQxSoxbWng0ZwxVk5cUNdkIwcqHlE+bbqVelfkYgFI6xwOivGPN 8Yik9Bx3Yh69jvqmu2Xzz5k+pjHbQTcD+yQFvWyaW+PClY+gT1Ey1SmDs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIBALOJ+U2rRDoJ/2dsb2JhbABSglGVBo8Id6s7ni+GJgSHGo8aiy8 X-IronPort-AV: E=Sophos;i="4.65,373,1304294400"; d="scan'208,217";a="338057804" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 16 Jun 2011 04:45:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5G4jt5H003417; Thu, 16 Jun 2011 04:45:55 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 21:45:55 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2BE0.472539F6" Date: Wed, 15 Jun 2011 21:45:50 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF0919@xmb-sjc-221.amer.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwqno7BLwl3j+PMSjaOF3ZfYi/FNwBOY9JA References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> From: "Allyn Romanow (allyn)" To: "Christer Holmberg" X-OriginalArrivalTime: 16 Jun 2011 04:45:55.0759 (UTC) FILETIME=[476853F0:01CC2BE0] Cc: clue@ietf.org, "Botzko, Stephen" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 04:46:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2BE0.472539F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer - In spirit I am enthusiastic about what you are proposing (meaning good quality mobile participation). I'm not clear on how the spirit becomes instantiated in our protocol, so I have some questions below J Thanks, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, June 14, 2011 7:23 AM To: clue@ietf.org Subject: [clue] Requirement on centralized media mixing =20 =20 Hi, =20 During the last interim meeting (May 12th) we discussed a requirement proposal stating that an endpoint must be able to request central audio rendering of different predefined formats, including 3D binaural rendering.=20 (Link to proposal: http://www.ietf.org/mail-archive/web/clue/current/msg00179.html) =20 The proposal was well received, with the reservation that it should not be mandatory=20 for the solution to implement centralized 3D binaural rendering, i.e.an endpoint should=20 be able to request 3D binaural rendering, but had no guaranty that such rendering was=20 supported by the system. =20 It was decided to look how such requirement could look like. =20 When I look the -03 version of the req draft, Requirement 2c states:=20 =20 "The solution MUST NOT preclude the use of binaural audio." =20 I think that requirement is unclear, and it doesn't really give any guidance to our work. =20 Due to that, and also due to the fact that rather than talking about specific rendering types,=20 I would like to propose more general requirement text on the negotiation of the media mixing type,=20 and the usage of centralized media mixing in the first place. =20 The mechanism would be extendable, so new types can be added in future. =20 So, the proposed requirements are: =20 REQ-x: It MUST be possible to negotiate the usage of centralized media mixing. System support of centralized media mixing is optional. =20 REQ-y: When centralized media mixing is used, it MUST be possible to negotiate the type of media rendering provided for each media stream received by a client. --- [ar] I have a few questions/comments: 1. The term "negotiate" troubles me as I think it means a particular form of communication that dictates the solution. What is being asked for is the receiver to know that it is receiving "centralized media mixing". This may not be the end product of a negotiation. The same is true of the use of the term negotiate in the second requirement. What is needed is a mechanism by which the receiver may know what type of "media rendering" is being received. So, I'd rather offer, The solution must support a means for identifying a stream which is "centralized media mixing". And, When "centralized media mixing" is used, the solution must support a means for identifying...=20 =20 2. Also, I'm not too sure what "media rendering", the phrase in the second reqmt, represents- SDP and RTP recognize audio channels and recognize codecs. Is this what is referred to as "media rendering"? Or is it something different? What very specifically? =20 3. After reading more of the discussion, I realize that I don't fully understand what is meant in the first reqmt by "centralized media mixing" or "rendering", which term is used in another email. I had thought you meant the usual audio mixing such as discussed in RFC 5117.( I figured it was an understood part of the topology so didn't need to be called out in particular. But I don't mind calling it out.) In any case, now I'm not sure what you mean, maybe it is something other than typical MCU mixing behavior as described in RFC 5117? =20 4. As for the discussion of binaural.. here is what it seems like to me.. AVP, RFC 3551 specifies the number of audio channels, what they refer to, and types of codecs. Binaural is neither. As you say, Christer, it's a type of stereo channel. Steve feels that "binaural" must be recognized in SDP, which of course, it is not currently.=20 =20 I'm not entirely sure what needs to be specified about binaural, given that it is neither channel -type nor codec-type. What needs to be standardized? This question is probably more for Steve, or both of you. If the receiving device knows it's getting binaural stereo, then it can run some algorithms to improve quality and if it isn't binaural, it won't run those algs., or something analogous? If that is the case, I don't see what needs to be standardized that isn't already standardized... But I'm eager to learn. =20 Thanks- Allyn=20 =20 Regards, =20 Christer =20 =20 ------_=_NextPart_001_01CC2BE0.472539F6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer –

In spirit I am enthusiastic about what you are proposing = (meaning good quality mobile participation). I’m not clear on how the = spirit becomes instantiated in our protocol, so I have some questions below = J<= o:p>

Thanks,

Allyn

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Christer Holmberg
Sent: Tuesday, June 14, 2011 7:23 AM
To: clue@ietf.org
Subject: [clue] Requirement on centralized media = mixing

 

 

Hi,

 =

During the last interim meeting (May 12th) we discussed a requirement = proposal

stating that an endpoint must be able to request central audio = rendering

of different predefined formats, including 3D binaural rendering. =

 =

The proposal was well received, with the reservation that it should not be mandatory

for the solution to implement centralized 3D binaural rendering, i.e.an = endpoint should

be able to request 3D binaural rendering, but had no guaranty that such = rendering was

supported by the system.

 =

It was decided to look how such requirement could look like.

 =

When I look the -03 version of the req draft, Requirement 2c states: =

 =

  &= nbsp; "The solution MUST NOT preclude the use of binaural = audio."

 =

I think that requirement is unclear, and it doesn't really give any = guidance to our work.

 =

Due to that, and also due to the fact that rather than talking about = specific rendering types,

I would like to propose more general requirement text on the negotiation = of the media mixing type,

and the usage of centralized media mixing in the first place.

 =

The mechanism would be extendable, so new types can be added in = future.

 =

So, the proposed requirements are:

 =

REQ-x: &= nbsp;  It MUST be possible to negotiate the usage of centralized media mixing. = System support of centralized media mixing is optional.

 =

REQ-y: &= nbsp;  When centralized media mixing is used, it MUST be possible to negotiate = the type of media rendering provided for each media stream received by a = client.

 ---

[ar] I have a few = questions/comments:

<= span style=3D'mso-list:Ignore'>1.         The term “negotiate” troubles me as I = think it means a particular form of communication that dictates the solution. = What is being asked for is the receiver to know that it is receiving = “centralized media mixing”. This may not be the end product of a negotiation. = The same is true of the use of the term negotiate in the second requirement. What = is needed is a mechanism by which the receiver may know what type of = “media rendering” is being received.

&= nbsp;    So, I’d rather offer, The solution must support a means for = identifying a stream which is “centralized media = mixing”.

And, When = “centralized media mixing” is used, the solution must support a means for = identifying…

 

<= span style=3D'mso-list:Ignore'>2.       Also,  I’m not too sure what “media = rendering”,  the phrase in the second reqmt, represents- SDP and RTP recognize = audio channels and recognize codecs. Is this what is referred to as = “media rendering”? Or is it something different? What very = specifically?

 

<= span style=3D'mso-list:Ignore'>3.       After reading more of the discussion, I realize that I = don’t fully understand what is meant in the first reqmt by “centralized = media mixing” or “rendering”, which term is used in another = email. I had thought you meant the usual audio mixing such as discussed in RFC = 5117.( I figured it was an understood part of the topology so didn’t need to  be called out in particular. But I don’t mind calling it = out.)  In any case, now I’m not sure what you mean, maybe it is something = other than typical MCU mixing behavior as described in RFC = 5117?

 

<= span style=3D'mso-list:Ignore'>4.       As for the discussion of binaural.. here is what it seems = like to me.. AVP, RFC 3551 specifies  the number of  audio channels, = what they refer to,  and types of codecs. Binaural is neither. As you = say, Christer, it’s a type of stereo channel.  Steve feels that = “binaural” must be recognized in SDP, which of course, it is not currently. =

 

I’m not entirely = sure what needs to be specified about binaural, given that it is neither channel = –type nor codec-type. What needs to be standardized? This question is probably = more for Steve, or both of you.  If the receiving device knows = it’s getting binaural stereo, then it can run some algorithms to improve = quality and if it isn’t binaural, it won’t run those algs., or something analogous? If that is the case, I don’t see what needs to be = standardized that isn’t already standardized… But I’m eager to = learn.

 

Thanks—

Allyn

 

Regards,

 =

Christer

 =

 =

------_=_NextPart_001_01CC2BE0.472539F6-- From allyn@cisco.com Wed Jun 15 21:48:23 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C8711E815A for ; Wed, 15 Jun 2011 21:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMN3PQcFDXTg for ; Wed, 15 Jun 2011 21:48:21 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id B35F011E813D for ; Wed, 15 Jun 2011 21:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=9436; q=dns/txt; s=iport; t=1308199701; x=1309409301; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=6kj6O11z+F55eQ4BLi6O5WyStr3LwrzUCkUoZxGDPTE=; b=jtkHy86nCYoTxENCuqKIbhInv27Cer/CxtZ/dKGCLFJND4B9h5o+l5qd lBo7RN+fEBghyeWXUrXgUWEgrq1Cxy8fAjuU+ClF/bjKoLR0Fz/jYSLf5 Fg25PnVnjYQBDz13rVlQ6T2BhVTBzXeN3AKsdeqBDlJ/8PScl7UKzHx0c g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIBAOSJ+U2rRDoJ/2dsb2JhbABSglGVBo8Id4hzokieL4YmBIcajxqLLw X-IronPort-AV: E=Sophos;i="4.65,373,1304294400"; d="scan'208,217";a="714377062" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2011 04:48:21 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5G4mLlO004478; Thu, 16 Jun 2011 04:48:21 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 21:48:21 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2BE0.9DA2BC17" Date: Wed, 15 Jun 2011 21:48:17 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF091D@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwq+8CiZbZxAs++SSCZodzWDRjJ8wA3Wk8A References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> From: "Allyn Romanow (allyn)" To: , "Christer Holmberg" X-OriginalArrivalTime: 16 Jun 2011 04:48:21.0093 (UTC) FILETIME=[9E088950:01CC2BE0] Cc: clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 04:48:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2BE0.9DA2BC17 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gao,=20 =20 Would you care to describe more about what you have in mind? What are you thinking about the relationship between CLUE - a way to specify multiple streams in a telepresence conference, and network operation? =20 Best regards, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of gao.yang2@zte.com.cn Sent: Tuesday, June 14, 2011 6:29 PM To: Christer Holmberg Cc: clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing =20 Christer,=20 I think this function is meaningful for operating network, such as IMS, NGN.=20 Thanks,=20 Gao=20 > So, the proposed requirements are:=20 > =20 > REQ-x: It MUST be possible to negotiate the usage of centralized=20 > media mixing. System support of centralized media mixing is optional.=20 > =20 > REQ-y: When centralized media mixing is used, it MUST be possible > to negotiate the type of media rendering provided for each media=20 > stream received by a client.=20 > =20 > Regards,=20 > =20 > Christer=20 > =20 =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. ------_=_NextPart_001_01CC2BE0.9DA2BC17 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Gao,

 

Would you care to describe more about what you have in = mind? What are you thinking about the relationship between CLUE – a way to = specify multiple streams in a telepresence conference, and network = operation?

 

Best regards,

Allyn

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = gao.yang2@zte.com.cn
Sent: Tuesday, June 14, 2011 6:29 PM
To: Christer Holmberg
Cc: clue@ietf.org
Subject: Re: [clue] Requirement on centralized media = mixing

 


Christer,

I think this function is meaningful = for operating network, such as IMS, NGN.

Thanks,

Gao


> So, the proposed requirements = are:
>  
> REQ-x:    It MUST be = possible to negotiate the usage of centralized
> media mixing. System support of centralized media mixing is = optional.
>  
> REQ-y:    When = centralized media mixing is used, it MUST be possible
> to negotiate the type of media rendering provided for each = media
> stream received by a client.
>  
> Regards,
>  
> Christer
>   = 

 
----------------------------------------=
----------------
ZTE Information Security&=
nbsp;Notice: The information contained in this&n=
bsp;mail is solely property of the sender's=
 organization. This mail communication is c=
onfidential. Recipients named above are obligate=
d to maintain secrecy and are not perm=
itted to disclose the contents of this =
;communication to others.
This email&=
nbsp;and any files transmitted with it are&=
nbsp;confidential and intended solely for the&nb=
sp;use of the individual or entity to =
whom they are addressed. If you have r=
eceived this email in error please notify&n=
bsp;the originator of the message. Any view=
s expressed in this message are those =
of the individual sender.
This m=
essage has been scanned for viruses and&nbs=
p;Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01CC2BE0.9DA2BC17-- From christer.holmberg@ericsson.com Wed Jun 15 22:06:13 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2235911E80B4 for ; Wed, 15 Jun 2011 22:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ssfzubH5Pdm for ; Wed, 15 Jun 2011 22:06:12 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CC06F11E807C for ; Wed, 15 Jun 2011 22:06:11 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d8-4df98f41486f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3B.F3.20773.14F89FD4; Thu, 16 Jun 2011 07:06:10 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 16 Jun 2011 07:06:08 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Stephen Botzko Date: Thu, 16 Jun 2011 07:06:08 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: AcwqtRzbg5jZCBmUSoyqAJooUM2sfAAjta2QAByQNWAACyzB8A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3E6A81@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A440@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E3A1878@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 05:06:13 -0000 Hi Keith,=20 >My understanding is that it can define new requirements that=20 >can be used by telepresence systems, even if those new=20 >capabilities may have a more general use. >=20 >What may occur is that then the definition of a solution for=20 >a general capability may well be assigned to a more=20 >appropriate working group. I totally agree. I am not talking about who is going to specify what protoc= ol elements - I am only talking about requirements. Regards, Christer > It is of course perfectly valid to argue that the requirement=20 > is inappropriate or not useful enough for telepresence sustems. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org]=20 > On Behalf=20 > > Of Christer Holmberg > > Sent: 15 June 2011 11:08 > > To: Stephen Botzko > > Cc: clue@ietf.org > > Subject: Re: [clue] Requirement on centralized media mixing > >=20 > >=20 > > Hi Stephen, > >=20 > > >>>If some other WG (for instance MMUSIC) defined a mechanism for=20 > > >>>general use of binaural audio for SIP/RTP, then I would fully=20 > > >>>support > > requirements that such a facility should be enabled in CLUE. > > >>> > > >>>But I do not think that CLUE is the right place to invent=20 > > >>>negotiation of binaural audio. Telepresence system=20 > users generally=20 > > >>>do not use > > headsets. > > >> > > >>No, but users communicating with a telepresence system=20 > using other=20 > > >>types > > of devices may. > > > > > >Yes they might. But CLUE is not the place to create completely new > > facilities that are not intended for telepresence systems. > >=20 > > Being able to connect to telepresence system with non-TP devices is=20 > > within the scope of the work, and we think it would create=20 > great added=20 > > value if we have a mechanism which allows offering an optimized=20 > > "near-telepresence experience" also to such devices. > >=20 > >=20 > > >>It is about having a generic mechanism for negotiation of=20 > > >>centralized > > media mixing usage, if the system supports it. > > > > > >I don't understand what "negotiate the type of media=20 > rendering" means. > > Maybe you can describe more precisely what is meant? > >=20 > > It's about two things: > >=20 > > First, to be able to find out whether the system supports=20 > centralized=20 > > rendering in the first place. Note that such functionality=20 > is optional. > >=20 > > Second, to be able to request centralized rendering, and=20 > the type of=20 > > rendering. > >=20 > > (Solution wise, we might be talking about some SDP=20 > attributes in order=20 > > to do this) > >=20 > > Note that this proposal does not have any impact on the=20 > definitions,=20 > > or on the telepresence "room model". > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > On Tue, Jun 14, 2011 at 10:22 AM, Christer Holmberg=20 > >=20 > > > > > > wrote: > >=20 > > Hi, > >=20 > > During the last interim meeting (May 12th) we=20 > discussed a=20 > > requirement proposal > > stating that an endpoint must be able to=20 > request central audio=20 > > rendering > > of different predefined formats, including 3D=20 > binaural rendering. > > (Link to proposal: http://www.ietf.org/mail- > > archive/web/clue/current/msg00179.html) > >=20 > > The proposal was well received, with the=20 > reservation that it should=20 > > not be mandatory > >=20 > > for the solution to implement centralized 3D=20 > binaural rendering,=20 > > i.e.an endpoint should > >=20 > > be able to request 3D binaural rendering, but=20 > had no guaranty that=20 > > such rendering was > > supported by the system. > >=20 > > It was decided to look how such requirement=20 > could look like. > >=20 > > When I look the -03 version of the req draft,=20 > Requirement 2c > > states: > >=20 > > "The solution MUST NOT preclude the use of=20 > binaural audio." > >=20 > > I think that requirement is unclear, and it=20 > doesn't really give any=20 > > guidance to our work. > >=20 > > Due to that, and also due to the fact that=20 > rather than talking about=20 > > specific rendering types, > > I would like to propose more general=20 > requirement text on the=20 > > negotiation of the media mixing type, > > and the usage of centralized media mixing in=20 > the first place. > >=20 > > The mechanism would be extendable, so new types=20 > can be added in=20 > > future. > >=20 > > So, the proposed requirements are: > >=20 > > REQ-x: It MUST be possible to negotiate the usage of > > centralized media mixing. System support of centralized=20 > media mixing=20 > > is optional. > >=20 > > REQ-y: When centralized media mixing is=20 > used, it MUST be > > possible to negotiate the type of media rendering provided for each=20 > > media stream received by a client. > >=20 > > Regards, > >=20 > > Christer > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > = From gao.yang2@zte.com.cn Wed Jun 15 22:11:55 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C120511E8179 for ; Wed, 15 Jun 2011 22:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.885 X-Spam-Level: X-Spam-Status: No, score=-98.885 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M8VJ6fZCs3P for ; Wed, 15 Jun 2011 22:11:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 56A8F11E8132 for ; Wed, 15 Jun 2011 22:11:53 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131321074741547; Thu, 16 Jun 2011 13:10:44 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 64162.2834955800; Thu, 16 Jun 2011 13:11:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p5G5BS8N063745; Thu, 16 Jun 2011 13:11:28 +0800 (GMT-8) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF091D@xmb-sjc-221.amer.cisco.com> To: "Allyn Romanow (allyn)" MIME-Version: 1.0 X-KeepSent: 613B533C:BAC137A9-482578B1:001B7BFF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 16 Jun 2011 13:11:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-16 13:11:30, Serialize complete at 2011-06-16 13:11:30 Content-Type: multipart/alternative; boundary="=_alternative 001C9EBB482578B1_=" X-MAIL: mse02.zte.com.cn p5G5BS8N063745 Cc: clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 05:11:55 -0000 This is a multipart message in MIME format. --=_alternative 001C9EBB482578B1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQWxseW4sDQpXaGF0IEkgY2FyZSBpcyBhYm91dCBjZW50cmFsaXplZCBtZWRpYSBtaXhpbmcg dGFsa2VkIGluIENocmlzdGVyJ3MgbWFpbC4NClRlbGNvbSBjYXJyaWVyL29wZXJhdG9yIHVzdWFs bHkgZGVwbG95IGxhcmdlIHNjYWxlIGNvbmZlcmVuY2Ugc3lzdGVtcyhzdWNoIA0KYXMgY29uZmVy ZW5jZSBBUy9NUkYgaW4gSU1TKSBpbiB0aGVpciBvcGVyYXRpbmcgbmV0d29yaywgdGhlbiBzZWxs IHRoZSANCmNvbmZlcmVuY2Ugc2VydmljZSB0byB0aGVpciBzdWJzY3JpYmVycy4gVGhlIHN1YnNj cmliZXJzIGNvdWxkIGJlIG5vcm1hbCANCmVuZCB1c2Vycywgb3IgZW50ZXJwcmlzZSB1c2Vycyhi eSBzeXN0ZW0gc3VjaCBhcyBJUCBDZW50cmV4IGluIHRoZSANCm9wZXJhdGluZyBuZXR3b3JrKS4N CkNvbnNpZGVyaW5nIHN1Y2ggdXNlIGNhc2VzLCBJIHRoaW5rIGl0IHdvdWxkIGJlIG1lYW5pbmdm dWwgdG8gY29uc2lkZXIgDQpjZW50cmFsaXplZCBtZWRpYSBtaXhpbmcgZnVuY3Rpb24gZm9yIHRl bGVwcmVzZW5jZSBjb25mZXJlbmNlIHN5c3RlbSwgZm9yIA0Kb3BlcmF0aW5nIG5ldHdvcmsgdGFs a2VkIGFib3ZlLg0KVGhhbmtzLA0KR2FvIA0KDQoNCj4gSGkgR2FvLCANCj4gDQo+IFdvdWxkIHlv dSBjYXJlIHRvIGRlc2NyaWJlIG1vcmUgYWJvdXQgd2hhdCB5b3UgaGF2ZSBpbiBtaW5kPyBXaGF0 IA0KPiBhcmUgeW91IHRoaW5raW5nIGFib3V0IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBDTFVF IKhDIGEgd2F5IHRvIA0KPiBzcGVjaWZ5IG11bHRpcGxlIHN0cmVhbXMgaW4gYSB0ZWxlcHJlc2Vu Y2UgY29uZmVyZW5jZSwgYW5kIG5ldHdvcmsgDQpvcGVyYXRpb24/DQo+IA0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IEFsbHluDQo+IA0KPiBGcm9tOiBjbHVlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpj bHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCj4gZ2FvLnlhbmcyQHp0ZS5jb20u Y24NCj4gU2VudDogVHVlc2RheSwgSnVuZSAxNCwgMjAxMSA2OjI5IFBNDQo+IFRvOiBDaHJpc3Rl ciBIb2xtYmVyZw0KPiBDYzogY2x1ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2NsdWVdIFJl cXVpcmVtZW50IG9uIGNlbnRyYWxpemVkIG1lZGlhIG1peGluZw0KPiANCj4gDQo+IENocmlzdGVy LCANCj4gDQo+IEkgdGhpbmsgdGhpcyBmdW5jdGlvbiBpcyBtZWFuaW5nZnVsIGZvciBvcGVyYXRp bmcgbmV0d29yaywgc3VjaCBhcyBJTVMsIA0KTkdOLiANCj4gDQo+IFRoYW5rcywgDQo+IA0KPiBH YW8gDQo+IA0KPiANCj4gPiBTbywgdGhlIHByb3Bvc2VkIHJlcXVpcmVtZW50cyBhcmU6IA0KPiA+ IA0KPiA+IFJFUS14OiAgICBJdCBNVVNUIGJlIHBvc3NpYmxlIHRvIG5lZ290aWF0ZSB0aGUgdXNh Z2Ugb2YgY2VudHJhbGl6ZWQgDQo+ID4gbWVkaWEgbWl4aW5nLiBTeXN0ZW0gc3VwcG9ydCBvZiBj ZW50cmFsaXplZCBtZWRpYSBtaXhpbmcgaXMgb3B0aW9uYWwuIA0KPiA+IA0KPiA+IFJFUS15OiAg ICBXaGVuIGNlbnRyYWxpemVkIG1lZGlhIG1peGluZyBpcyB1c2VkLCBpdCBNVVNUIGJlIHBvc3Np YmxlDQo+ID4gdG8gbmVnb3RpYXRlIHRoZSB0eXBlIG9mIG1lZGlhIHJlbmRlcmluZyBwcm92aWRl ZCBmb3IgZWFjaCBtZWRpYSANCj4gPiBzdHJlYW0gcmVjZWl2ZWQgYnkgYSBjbGllbnQuIA0KPiA+ IA0KPiA+IFJlZ2FyZHMsIA0KPiA+IA0KPiA+IENocmlzdGVyIA0KIA0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFi b3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 001C9EBB482578B1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8cD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SGkgPC9mb250Pjx0dD48Zm9udCBz aXplPTI+QWxseW48L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+LDwv Zm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XaGF0IEkgY2FyZSBpcyBh Ym91dCA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5jZW50cmFsaXplZA0KbWVkaWEgbWl4aW5nPC9m b250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiB0YWxrZWQgaW4gQ2hyaXN0 ZXIncw0KbWFpbC48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGVs Y29tIDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPmNhcnJpZXIvb3BlcmF0b3INCnVzdWFsbHkgZGVw bG95IGxhcmdlIHNjYWxlIGNvbmZlcmVuY2Ugc3lzdGVtcyhzdWNoIGFzIGNvbmZlcmVuY2UgQVMv TVJGDQppbiBJTVMpIGluIHRoZWlyIG9wZXJhdGluZyBuZXR3b3JrLCB0aGVuIHNlbGwgdGhlIGNv bmZlcmVuY2Ugc2VydmljZSB0bw0KdGhlaXIgc3Vic2NyaWJlcnMuIFRoZSBzdWJzY3JpYmVycyBj b3VsZCBiZSBub3JtYWwgZW5kIHVzZXJzLCBvciBlbnRlcnByaXNlDQp1c2VycyhieSBzeXN0ZW0g c3VjaCBhcyBJUCBDZW50cmV4IGluIHRoZSBvcGVyYXRpbmcgbmV0d29yaykuPC9mb250PjwvdHQ+ DQo8cD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q29uc2lkZXJpbmcgc3VjaCB1c2Ug Y2FzZXMsIEkgdGhpbmsgaXQNCndvdWxkIGJlIG1lYW5pbmdmdWwgdG8gY29uc2lkZXIgPC9mb250 Pjx0dD48Zm9udCBzaXplPTI+Y2VudHJhbGl6ZWQgbWVkaWENCm1peGluZzwvZm9udD48L3R0Pjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4gZnVuY3Rpb24gZm9yIDwvZm9udD48dHQ+PGZv bnQgc2l6ZT0yPnRlbGVwcmVzZW5jZQ0KY29uZmVyZW5jZTwvZm9udD48L3R0Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4gc3lzdGVtLCBmb3IgPC9mb250Pjx0dD48Zm9udCBzaXplPTI+ b3BlcmF0aW5nDQpuZXR3b3JrPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiB0YWxrZWQgYWJvdmUuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlRoYW5rcyw8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2Fv IDwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgSGkgR2FvLCA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFdvdWxkIHlvdSBjYXJlIHRvIGRlc2NyaWJlIG1v cmUgYWJvdXQgd2hhdCB5b3UNCmhhdmUgaW4gbWluZD8gV2hhdCA8YnI+DQomZ3Q7IGFyZSB5b3Ug dGhpbmtpbmcgYWJvdXQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIENMVUUgqEMgYSB3YXkgdG8N Cjxicj4NCiZndDsgc3BlY2lmeSBtdWx0aXBsZSBzdHJlYW1zIGluIGEgdGVsZXByZXNlbmNlIGNv bmZlcmVuY2UsIGFuZCBuZXR3b3JrDQpvcGVyYXRpb24/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyBCZXN0IHJlZ2FyZHMsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IEFsbHluPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBjbHVlLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddDQpPbiBCZWhhbGYgT2YgPGJyPg0K Jmd0OyBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCiZndDsgU2VudDogVHVlc2RheSwgSnVuZSAx NCwgMjAxMSA2OjI5IFBNPGJyPg0KJmd0OyBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQomZ3Q7 IENjOiBjbHVlQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW2NsdWVdIFJlcXVpcmVt ZW50IG9uIGNlbnRyYWxpemVkIG1lZGlhIG1peGluZzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgPGJyPg0KJmd0OyBDaHJpc3RlciwgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgdGhpbmsgdGhp cyBmdW5jdGlvbiBpcyBtZWFuaW5nZnVsIGZvciBvcGVyYXRpbmcgbmV0d29yaywgc3VjaCBhcw0K SU1TLCBOR04uIDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MsIDxicj4NCiZndDsgPGJyPg0K Jmd0OyBHYW8gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBTbywgdGhlIHBy b3Bvc2VkIHJlcXVpcmVtZW50cyBhcmU6IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0 OyAmZ3Q7IFJFUS14OiAmbmJzcDsgJm5ic3A7SXQgTVVTVCBiZSBwb3NzaWJsZSB0byBuZWdvdGlh dGUgdGhlIHVzYWdlDQpvZiBjZW50cmFsaXplZCA8YnI+DQomZ3Q7ICZndDsgbWVkaWEgbWl4aW5n LiBTeXN0ZW0gc3VwcG9ydCBvZiBjZW50cmFsaXplZCBtZWRpYSBtaXhpbmcgaXMgb3B0aW9uYWwu DQo8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBSRVEteTogJm5ic3A7ICZu YnNwO1doZW4gY2VudHJhbGl6ZWQgbWVkaWEgbWl4aW5nIGlzIHVzZWQsIGl0DQpNVVNUIGJlIHBv c3NpYmxlPGJyPg0KJmd0OyAmZ3Q7IHRvIG5lZ290aWF0ZSB0aGUgdHlwZSBvZiBtZWRpYSByZW5k ZXJpbmcgcHJvdmlkZWQgZm9yIGVhY2ggbWVkaWENCjxicj4NCiZndDsgJmd0OyBzdHJlYW0gcmVj ZWl2ZWQgYnkgYSBjbGllbnQuIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7 IFJlZ2FyZHMsIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IENocmlzdGVy IDxicj4NCiA8L2ZvbnQ+PC90dD4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5i c3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtj b250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkm bmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6 YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJz cDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJz cDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZu YnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlz Y2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZu YnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJz cDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVs eSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNw O2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNl aXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2Um bmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMm bmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJz cDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3By ZT4= --=_alternative 001C9EBB482578B1_=-- From stephen.botzko@gmail.com Thu Jun 16 04:33:32 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCA221F84B1 for ; Thu, 16 Jun 2011 04:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZw9x07h5Ju8 for ; Thu, 16 Jun 2011 04:33:31 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3D7121F84B2 for ; Thu, 16 Jun 2011 04:33:30 -0700 (PDT) Received: by vxg33 with SMTP id 33so1389487vxg.31 for ; Thu, 16 Jun 2011 04:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UKADdW6wXhrfrUJ9My3JVqX9zhJCDDlGhO/J58T3sxI=; b=JOVQExA6KWsHzIrcyyG/FNL31alNsMro43CqcPoMC98KYTvn0JVKS1rcvLtc3kQbzR KjqZvV9xsog/GgyAg96kVFohzdvTAuAt0HK1U7hfCYzC/hSHJH59Un7zTBLkZRJuVzdz VXfBSFZl0KXOAz+Ss+pYKsiuVkJRznsAhQXms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dHTCcZfb5ZYc3hdvVXwOmUNmrgSxCcPl3M14G8DQnvOHAn62WqHywZLZLVHRTJ3R1l 38VcWTogfeVt6OooyxPvJoL8BuvWB8wTL6ZS9IUqPhGTdVKhyyH0NmHQFohZn3kP3kk/ 5WBt0dpjuQOSEci1l/8c82TiWfqiFg7tgU0uY= MIME-Version: 1.0 Received: by 10.52.176.10 with SMTP id ce10mr1056913vdc.280.1308224007795; Thu, 16 Jun 2011 04:33:27 -0700 (PDT) Received: by 10.52.107.138 with HTTP; Thu, 16 Jun 2011 04:33:27 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF0919@xmb-sjc-221.amer.cisco.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF0919@xmb-sjc-221.amer.cisco.com> Date: Thu, 16 Jun 2011 07:33:27 -0400 Message-ID: From: Stephen Botzko To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=bcaec51a818445723d04a5d2a363 Cc: "Botzko, Stephen" , clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 11:33:32 -0000 --bcaec51a818445723d04a5d2a363 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>> {allyn] I=92m not entirely sure what needs to be specified about binaural, given th= at it is neither channel =96type nor codec-type. What needs to be standardized= ? This question is probably more for Steve, or both of you. If the receiving device knows it=92s getting binaural stereo, then it can run some algorithm= s to improve quality and if it isn=92t binaural, it won=92t run those algs., = or something analogous? If that is the case, I don=92t see what needs to be standardized that isn=92t already standardized=85 But I=92m eager to learn. >>> When you listen to live audio in a real space, the sound on your left side reaches both of your ears. But what you hear in your right ear is quite different from what you hear in the left - this is because your head (and the shape of your ears) modifies the sound. Among other things, your head creates an acoustic "shadow". If you listen to ordinary stereo audio through earphones, sound in the left earphone does not reach your the right earphone in any form. The result is that the spatial positioning of the audio sound stage is marred. For instance,if a singer is center-stage, through earphones she might sound lik= e she is singing inside your head. Filtering the stereo sound through a special filter (called the HRTF) largely eliminates this effect. The "head-related transfer function" adjusts the audio being presented to the earphones to something much closer to what you'd hear in the ordinary room (by modeling the effect of a typica= l human head). Done well, you get a 3D soundstage, similar to what you would hear naturally. To some degree, how well it works depends on how closely th= e HRTF function being used matches your own head and ears. Of course the HRTF-processed sound is intended to be heard through earphones. If you listen to it through normal speakers, the audio might no= t sound good. (There are several variations of HRTF, and some work much better than others with normal speakers). And some receivers might have their own approach to creating 3D sound through speakers, and pre-application of HRTF would interfere with that. So a receiver that is rendering through speakers must not receive HRTF-processed audio. Ordinarily, the HRTF processing would be simply done in the final receiver = - and in that case there would be no negotiation needed. However, the HTRF filters are quite complicated, and therefore Ericsson desires to move the processing to a central server in order to reduce the complexity/power requirements in the mobile device. A second reason for doing the HRTF in the server is that the server potentially has the original audio captures available, which allows the server to "place" each source prior to mixing. To take advantage of this i= n the mobile device, you need to forward the original streams, which adds bandwidth. So this is not about being able to run "special algorithms" if you are receiving binaural audio. It is more about making sure HRTF is not inappropriately applied (for a normal telepresence rooms using loudspeakers). Also, some special algorithms (including HRTF) can only be run if you are NOT receiving binaural audio.from a central server. One obvious example - you wouldn't want to run HRTF twice. The ability to negotiate an audio or video layout is clearly within scope, and has general value it the group wants to take it on. For instance, if you combine video switching of multiple sources with audio mixing/transcoding, then the receiver is responsible for the video layout but has no control over the audio layout. In that case, there are advantages to allowing the receiver to tell the central audio mixer where i= t wants the sources placed on the sound stage. I have no objection in principle to adding that kind of negotiation to the requirements, though I think the group should consider the impact on the schedule. All I've been trying to say is the negotiation of sender-side HRTF/binaural audio itself does not appear to be in scope, and that part would be better done in MMUSIC. As Keith observes, the charter indicates that we can redirect stuff like that to the appropriate group, and I'd suggest that we do that in this case. I don't see HRTF negotiation as a telepresence requirement, it is really a mobile application, so I'd prefer to see Ericsson do this directly. I also don't think CLUE has a dependency on suc= h a negotiation, since the development of a protocol to specify audio layout doesn't really depend on the availability of binaural negotiation. When I drafted the "not preclude" requirement on binaural audio I was presuming this kind of outcome. As far as the appropriate mechanism for binaural negotiation, I'd imagine this is a new a=3D parameter in SDP. It can be applied to any stereo audio= , and is not codec dependent. Hopefully this helps to clarify, as far as I know it is a correct and fair summary of what Ericsson has in mind - the ability to negotiate an audio layout independently from the video layout, the ability to modify such a layout mid-call, and optionally negotiate the pre-application the HRTF function (or equivalent binaural processing means) in a central server for mobile devices. Stephen Botzko On Thu, Jun 16, 2011 at 12:45 AM, Allyn Romanow (allyn) wr= ote: > Hi Christer =96 > > In spirit I am enthusiastic about what you are proposing (meaning good > quality mobile participation). I=92m not clear on how the spirit becomes > instantiated in our protocol, so I have some questions below J > > Thanks, > > Allyn > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Christer Holmberg > *Sent:* Tuesday, June 14, 2011 7:23 AM > *To:* clue@ietf.org > *Subject:* [clue] Requirement on centralized media mixing > > > > > > Hi, > > > > During the last interim meeting (May 12th) we discussed a requirement > proposal > > stating that an endpoint must be able to request central audio rendering > > of different predefined formats, including 3D binaural rendering. > > (Link to proposal: > http://www.ietf.org/mail-archive/web/clue/current/msg00179.html) > > > > The proposal was well received, with the reservation that it should not b= e > mandatory > > for the solution to implement centralized 3D binaural rendering, i.e.anen= dpoint should > > be able to request 3D binaural rendering, but had no guaranty that such > rendering was > > supported by the system. > > > > It was decided to look how such requirement could look like. > > > > When I look the -03 version of the req draft, Requirement 2c states: > > > > "The solution MUST NOT preclude the use of binaural audio." > > > > I think that requirement is unclear, and it doesn't really give any > guidance to our work. > > > > Due to that, and also due to the fact that rather than talking about > specific rendering types, > > I would like to propose more general requirement text on the negotiation = of > the media mixing type, > > and the usage of centralized media mixing in the first place. > > > > The mechanism would be extendable, so new types can be added in future. > > > > So, the proposed requirements are: > > > > REQ-x: It MUST be possible to negotiate the usage of centralized media > mixing. System support of centralized media mixing is optional. > > > > REQ-y: When centralized media mixing is used, it MUST be possible to > negotiate the type of media rendering provided for each media stream > received by a client. > > --- > > [ar] I have a few questions/comments: > > 1. The term =93negotiate=94 troubles me as I think it means a > particular form of communication that dictates the solution. What is bein= g > asked for is the receiver to know that it is receiving =93centralized med= ia > mixing=94. This may not be the end product of a negotiation. The same is = true > of the use of the term negotiate in the second requirement. What is neede= d > is a mechanism by which the receiver may know what type of =93media rende= ring=94 > is being received. > > So, I=92d rather offer, The solution must support a means for > identifying a stream which is =93centralized media mixing=94. > > And, When =93centralized media mixing=94 is used, the solution must suppo= rt a > means for identifying=85 > > > > 2. Also, I=92m not too sure what =93media rendering=94, the phras= e in > the second reqmt, represents- SDP and RTP recognize audio channels and > recognize codecs. Is this what is referred to as =93media rendering=94? O= r is it > something different? What very specifically? > > > > 3. After reading more of the discussion, I realize that I don=92t > fully understand what is meant in the first reqmt by =93centralized media > mixing=94 or =93rendering=94, which term is used in another email. I had = thought > you meant the usual audio mixing such as discussed in RFC 5117.( I figure= d > it was an understood part of the topology so didn=92t need to be called = out > in particular. But I don=92t mind calling it out.) In any case, now I=92= m not > sure what you mean, maybe it is something other than typical MCU mixing > behavior as described in RFC 5117? > > > > 4. As for the discussion of binaural.. here is what it seems like t= o > me.. AVP, RFC 3551 specifies the number of audio channels, what they re= fer > to, and types of codecs. Binaural is neither. As you say, Christer, it= =92s a > type of stereo channel. Steve feels that =93binaural=94 must be recogniz= ed in > SDP, which of course, it is not currently. > > > > I=92m not entirely sure what needs to be specified about binaural, given = that > it is neither channel =96type nor codec-type. What needs to be standardiz= ed? > This question is probably more for Steve, or both of you. If the receivi= ng > device knows it=92s getting binaural stereo, then it can run some algorit= hms > to improve quality and if it isn=92t binaural, it won=92t run those algs.= , or > something analogous? If that is the case, I don=92t see what needs to be > standardized that isn=92t already standardized=85 But I=92m eager to lear= n. > > > > Thanks=97 > > Allyn > > > > Regards, > > > > Christer > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --bcaec51a818445723d04a5d2a363 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>> {allyn]
I=92m no= t entirely sure what needs to be specified about binaural, given that it is neither channel =96t= ype nor codec-type. What needs to be standardized? This question is probably mo= re for Steve, or both of you.=A0 If the receiving device knows it=92s getting binaural stereo, then it can run some algorithms to improve quality= and if it isn=92t binaural, it won=92t run those algs., or something analogous? If that is the case, I don=92t see what needs to be standardized that isn=92t already standardized=85 But I=92m eager to learn.
&g= t;>>

When you listen to live audio in a real space, the sound = on your left side reaches both of your ears.=A0 But what you hear in your r= ight ear is quite different from what you hear in the left - this is becaus= e your head (and the shape of your ears) modifies the sound.=A0 Among other= things, your head creates an acoustic "shadow".

If you listen to ordinary stereo audio through earphones, sound in the = left earphone does not reach your the right earphone in any form.=A0 The re= sult is that the spatial positioning of the audio sound stage is marred.=A0= For instance,if a singer is center-stage, through earphones she might soun= d like she is singing inside your head.

Filtering the stereo sound through a special filter (called the HRTF) l= argely eliminates this effect.=A0 The "head-related transfer function&= quot; adjusts the audio being presented to the earphones to something much = closer to what you'd hear in the ordinary room (by modeling the effect = of a typical human head).=A0 Done well, you get a 3D soundstage, similar to= what you would hear naturally. To some degree, how well it works depends o= n how closely the HRTF function being used matches your own head and ears.<= br>
Of course the HRTF-processed sound is intended to be heard through earp= hones.=A0 If you listen to it through normal speakers, the audio might not = sound good.=A0 (There are several variations of HRTF, and some work much be= tter than others with normal speakers). And some receivers might have their= own approach to creating 3D sound through speakers, and pre-application of= HRTF would interfere with that.=A0 So a receiver that is rendering through= speakers must not receive HRTF-processed audio.

Ordinarily, the HRTF processing would be simply done in the final recei= ver - and in that case there would be no negotiation needed.=A0 However, th= e HTRF filters are quite complicated, and therefore Ericsson desires to mov= e the processing to a central server in order to reduce the complexity/powe= r requirements in the mobile device.

A second reason for doing the HRTF in the server is that the server pot= entially has the original audio captures available, which allows the server= to "place" each source prior to mixing.=A0 To take advantage of = this in the mobile device, you need to forward the original streams, which = adds bandwidth.

So this is not about being able to run "special algorithms" i= f you are receiving binaural audio.=A0 It is more about making sure HRTF is= not inappropriately applied (for a normal telepresence rooms using loudspe= akers).=A0 Also, some special algorithms (including HRTF) can only be run i= f you are NOT receiving binaural audio.from a central server.=A0 One obviou= s example - you wouldn't want to run HRTF twice.



The ability to negotiate an audio or video layout is clearly wi= thin scope, and has general value it the group wants to take it on.=A0 For = instance, if you combine video switching of multiple sources with audio mix= ing/transcoding, then the receiver is responsible for the video layout but = has no control over the audio layout.=A0 In that case, there are advantages= to allowing the receiver to tell the central audio mixer where it wants th= e sources placed on the sound stage.=A0 I have no objection in principle to= adding that kind of negotiation to the requirements, though I think the gr= oup should consider the impact on the schedule.

All I've been trying to say is the negotiation of sender-side HRTF/= binaural audio itself does not appear to be in scope, and that part would b= e better done in MMUSIC.=A0 As Keith observes, the charter indicates that w= e can redirect stuff like that to the appropriate group, and I'd sugges= t that we do that in this case.=A0 I don't see HRTF negotiation as a te= lepresence requirement, it is really a mobile application, so I'd prefe= r to see Ericsson do this directly.=A0 I also don't think CLUE has a de= pendency on such a negotiation, since the development of a protocol to spec= ify audio layout doesn't really depend on the availability of binaural = negotiation. When I drafted the "not preclude" requirement on bin= aural audio I was presuming this kind of outcome.

As far as the appropriate mechanism for binaural negotiation, I'd i= magine this is a new a=3D parameter in SDP.=A0 It can be applied to any ste= reo audio, and is not codec dependent.

Hopefully this helps to clari= fy, as far as I know it is a correct and fair summary of what Ericsson has = in mind - the ability to negotiate an audio layout independently from the v= ideo layout, the ability to modify such a layout mid-call, and optionally n= egotiate the pre-application the HRTF function (or equivalent binaural proc= essing means) in a central server for mobile devices.

Stephen Botzko


On Thu, Jun 16, 20= 11 at 12:45 AM, Allyn Romanow (allyn) <allyn@cisco.com> wrote:

Hi Christ= er =96

In spirit= I am enthusiastic about what you are proposing (meaning good quality mobile participation). I=92m not clear on how the spirit becomes instantiated in our protocol, so I have some questions below J<= span style=3D"font-size:11.0pt;color:red">

Thanks,

Allyn

=A0

From:= clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Tuesday, June 14, 2011 7:23 AM
To: clue@ietf.org=
Subject: [clue] Requirement on centralized media mixing

=A0

=A0

Hi,

=A0

During the last interim meeting (May 12th) we discussed a requirement proposal

stating that an endpoint must be able to request central audio rendering

of different predefined formats, including 3D binaural rendering.

=A0

The proposal was well received, with the reservation that it should not be mandatory

for the solution to implement centralized 3D binaural rendering, i.e.an endpoint should

be able to request 3D binaural rendering, but had no guaranty that such render= ing was

supported by the system.

=A0

It was decided to look how such requirement could look like.

=A0

When I look the -03 version of the req draft, Requirement 2c states:

=A0

=A0=A0=A0 "The solution MUST NOT preclude the use of binaural audio."

=A0

I think that requirement is unclear, and it doesn't really give any guida= nce to our work.

=A0

Due to that, and also due to the fact that rather than talking about specific rendering types,

I would like to propose more general requirement text on the negotiation of t= he media mixing type,

and the usage of centralized media mixing in the first place.

=A0

The mechanism would be extendable, so new types can be added in future.<= span>

=A0

So, the proposed requirements are:

=A0

REQ-x:=A0=A0=A0 It MUST be possible to negotiate the usage of centralized media mixing. Sys= tem support of centralized media mixing is optional.

=A0

REQ-y:=A0=A0=A0 When centralized media mixing is used, it MUST be possible to negotiate the type of media rendering provided for each media stream received by a client= .

=A0---

[ar] = I have a few questions/comments:

1.=A0=A0=A0=A0=A0=A0 =A0=A0The t= erm =93negotiate=94 troubles me as I think it means a particular form of communication that dictates the solution. Wha= t is being asked for is the receiver to know that it is receiving =93centralized media mixing=94. This may not be the end product of a negotiation. The same is true of the use of the term negotiate in the second requirement. What is needed is a mechanism by which the receiver may know what type of =93media rendering=94 is being received.

=A0=A0=A0=A0 So, I=92d rather offer, The solution must support a means for identifying a stream which is =93centralized media mixing=94.

And, When =93centralized media mixing=94 is used, the solution must support a means for identifying= =85

=A0

2.=A0=A0=A0=A0=A0=A0 Also, =A0I= =92m not too sure what =93media rendering=94, =A0the phrase in the second reqmt, represents- SDP and RTP recognize audio channels and recognize codecs. Is this what is referred to as =93media rendering=94? Or is it something different? What very specifically?<= /p>

=A0

3.=A0=A0=A0=A0=A0=A0 After readi= ng more of the discussion, I realize that I don=92t fully understand what is meant in the first reqmt by =93centralized media mixing=94 or =93rendering=94, which term is used in another email. I had thought you meant the usual audio mixing such as discussed in RFC 511= 7.( I figured it was an understood part of the topology so didn=92t need to=A0 be called out in particular. But I don=92t mind calling it out.)=A0 In any case, now I=92m not sure what you mean, maybe it is something other than typical MCU mixing behavior as described in RFC 5117?

=A0

4.=A0=A0=A0=A0=A0=A0 As for the = discussion of binaural.. here is what it seems like to me.. AVP, RFC 3551 specifies=A0 the number of =A0audio channels, what they refer to, =A0and types of codecs. Binaural is neither. As you say, Christer, it=92s a type of stereo channel.=A0 Steve feels that =93binaural= =94 must be recognized in SDP, which of course, it is not currently.

=A0

I=92m not entirely sure what needs to be specified about binaural, given that it is neither channel =96t= ype nor codec-type. What needs to be standardized? This question is probably mo= re for Steve, or both of you.=A0 If the receiving device knows it=92s getting binaural stereo, then it can run some algorithms to improve quality= and if it isn=92t binaural, it won=92t run those algs., or something analogous? If that is the case, I don=92t see what needs to be standardized that isn=92t already standardized=85 But I=92m eager to learn.

=A0

Thanks=97=

Allyn

=A0

Regards,

=A0

Christer

=A0

=A0


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


--bcaec51a818445723d04a5d2a363-- From allyn@cisco.com Sun Jun 19 16:48:09 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2219D21F84AF for ; Sun, 19 Jun 2011 16:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.57 X-Spam-Level: X-Spam-Status: No, score=-10.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f32EFAsFHeqo for ; Sun, 19 Jun 2011 16:48:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 724F221F84AC for ; Sun, 19 Jun 2011 16:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=1926; q=dns/txt; s=iport; t=1308527288; x=1309736888; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+5ffeyiuSdL/m0aFP4YQHZbEXsNgea8xsYsuFGBQTvg=; b=AsepbGyQG9fQqDpK6CvCL6xs6a4prCaEd+HxMKqPBKfAiRDhiVWzb/mh MQxB2zEryjxLVRYaHTYSJO9Dws17cpjgpBxrn2LzmbZ3PN0iJtMtbQSIN 17oCJ34y4f4K6l228nn48L+81MP52gzCLg03ULL3CGOqqKJqI1Gbrp40X c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAACGK/k2rRDoH/2dsb2JhbABSl1KPCnepaJ0RhioEhyCPJ4s4 X-IronPort-AV: E=Sophos;i="4.65,390,1304294400"; d="scan'208";a="716883938" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2011 23:48:08 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5JNm8w7023243; Sun, 19 Jun 2011 23:48:08 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 19 Jun 2011 16:48:07 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Jun 2011 16:45:18 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A5@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Comment on requirements-03 - aspect ratio Thread-Index: AcwreYbvuyWp0YkTT8mIyfuGzYlTTADYGxNw References: From: "Allyn Romanow (allyn)" To: "Elwell, John" , X-OriginalArrivalTime: 19 Jun 2011 23:48:07.0870 (UTC) FILETIME=[56F7D5E0:01CC2EDB] Subject: Re: [clue] Comment on requirements-03 - aspect ratio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 23:48:09 -0000 Hi John, Thanks for your comments.=20 I agree with them. Aspect ratio is not part of ordering, and should be a separate requirement, not part of Reqmt 1. Reqmt 6 which says The solution MUST support means of enabling interoperability between telepresence endpoints where cameras are of different aspect ratios. Certainly includes supporting communicating information about aspect ratio, which is what 1c says. Also, 1d, on supporting multi-view, as described in use cases, could be pulled out of 1 and made a separate requirement as well.=20 I propose making these changes. How is that? Regards, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Elwell, John > Sent: Wednesday, June 15, 2011 9:30 AM > To: clue@ietf.org > Subject: [clue] Comment on requirements-03 - aspect ratio >=20 > We have: > "REQMT-1: The solution MUST support a description of the spatial > arrangement of source video images sent in video streams > which enables a satisfactory reproduction at the receiver > of the original scene. This applies to each site in a > point to point or a multipoint meeting and refers to the > spatial ordering within a site, not to the ordering of > images between sites." > and below that: > "REQMT-1c: The solution MUST support a means to > communicate the aspect ratio." > Is this the aspect ratio of a particular camera? If so, what is the > relevance of this to REQMT-1, which is concerned with the spatial > ordering of video images? Also REQMT-6 addresses aspect ratios, so how > does REQMT-1c relate to REQMT-6? >=20 > John > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Sun Jun 19 16:48:12 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8893C21F84B5 for ; Sun, 19 Jun 2011 16:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.575 X-Spam-Level: X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iboI5gZIW3GT for ; Sun, 19 Jun 2011 16:48:08 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id B79BE21F84AD for ; Sun, 19 Jun 2011 16:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=32132; q=dns/txt; s=iport; t=1308527288; x=1309736888; h=mime-version:subject:date:message-id:in-reply-to: references:list-help:list-subscribe:list-unsubscribe:from: to:cc; bh=Rn2JwbLXDkLpYyG8agq2W9FV1UUoSf38Qc4hfNOkj/8=; b=cy69TXUmT3VqcfLhlUt+eGM7utmn8YC0tcXt+FLI90C14K/E3zynqKvZ C0C3ZVVxgF8WwN8fl0+DFXRHF1fquzEn37xsRa++RXz/MD83iHv+gTFjj VFjSk9Jv8cOJ6cX+LPt+3WSO69X2of4XeeBoD/2ZumZtxWEyuctQMrylf 4=; X-Files: ATT2792105.txt : 127 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAOSJ/k2rRDoJ/2dsb2JhbABSglGVAY4iaHepf50RhioEhyCFcYk2izg X-IronPort-AV: E=Sophos;i="4.65,390,1304294400"; d="txt'?scan'208,217";a="380367760" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 19 Jun 2011 23:48:07 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5JNm7uG005997; Sun, 19 Jun 2011 23:48:07 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 19 Jun 2011 16:48:07 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 21:47:22 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC2EDB.56462C8E" Received: from xbh-rcd-201.cisco.com ([72.163.62.200]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 21:47:22 -0700 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 23:47:19 -0500 Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 16 Jun 2011 04:46:07 +0000 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5G4k4FQ003532; Thu, 16 Jun 2011 04:46:07 GMT Received: from mail.ietf.org ([64.170.98.30]) by sj-inbound-d.cisco.com with ESMTP; 16 Jun 2011 04:46:07 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C9911E8136; Wed, 15 Jun 2011 21:46:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D4D11E811E for ; Wed, 15 Jun 2011 21:46:02 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofI51qDtFI6u for ; Wed, 15 Jun 2011 21:45:57 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 023B811E812B for ; Wed, 15 Jun 2011 21:45:56 -0700 (PDT) Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 16 Jun 2011 04:45:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5G4jt5H003417; Thu, 16 Jun 2011 04:45:55 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 21:45:55 -0700 Content-class: urn:content-classes:message Date: Sun, 19 Jun 2011 16:48:06 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A3@xmb-sjc-221.amer.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwqno7BLwl3j+PMSjaOF3ZfYi/FNwBOY9JA X-Priority: 1 Priority: Urgent Importance: high References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> From: "Allyn Romanow (allyn)" To: "Christer Holmberg" , "Mary Barnes" X-OriginalArrivalTime: 19 Jun 2011 23:48:07.0386 (UTC) FILETIME=[56ADFBA0:01CC2EDB] Cc: "Botzko, Stephen" , clue@ietf.org, "Bill Mauchly \(bmauchly\)" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 23:48:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2EDB.56462C8E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC2EDB.56462C8E" ------_=_NextPart_002_01CC2EDB.56462C8E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, I'm resending my original message to you as I think the questions it asks are important. I would like to try to get your requirements clear. I don't think they are clear yet. =20 Also, as Mary said in her previous email, email discussions on the list must be 3 days before the virtual meeting in order to be included in the virtual meeting. Last minute emails won't be included in the virtual discussion. =20 I cannot tell if by "centralized media mixing" you are referring to the normal functions of an MCU, such as described in RTP Topologies, or if you mean something else? The reason centralized media mixing wasn't included in the requirements is because it's assumed behavior of an MCU. You can say you want it in the requirements anyway.. the point is what you mean by it? =20 Also, what kind of support are you asking for binaural? I believe it's often considered as a subset of stereo. What are you asking for? A simple tag that says "binaural", or the specification of a rendering system for binaural? Precisely what are asking for? =20 I suggest we do not say negotiate, as I think it is unnecessary and we can use the notion of sending information between senders and receivers, as is currently specified. Are you all right with the specific suggestion I made to replace the term "negotiate" as below? =20 What did you mean by "media rendering", as below? =20 =20 Thanks, Allyn =20 =20 =20 =20 Hi Christer - In spirit I am enthusiastic about what you are proposing (meaning good quality mobile participation). I'm not clear on how the spirit becomes instantiated in our protocol, so I have some questions below J Thanks, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, June 14, 2011 7:23 AM To: clue@ietf.org Subject: [clue] Requirement on centralized media mixing =20 =20 Hi, =20 During the last interim meeting (May 12th) we discussed a requirement proposal stating that an endpoint must be able to request central audio rendering of different predefined formats, including 3D binaural rendering.=20 (Link to proposal:=20 http://www.ietf.org/mail-archive/web/clue/current/msg00179.html) =20 The proposal was well received, with the reservation that it should not be mandatory=20 for the solution to implement centralized 3D binaural rendering, i.e.an endpoint should=20 be able to request 3D binaural rendering, but had no guaranty that such rendering was=20 supported by the system. =20 It was decided to look how such requirement could look like. =20 When I look the -03 version of the req draft, Requirement 2c states:=20 =20 "The solution MUST NOT preclude the use of binaural audio." =20 I think that requirement is unclear, and it doesn't really give any guidance to our work. =20 Due to that, and also due to the fact that rather than talking about specific rendering types,=20 I would like to propose more general requirement text on the negotiation of the media mixing type,=20 and the usage of centralized media mixing in the first place. =20 The mechanism would be extendable, so new types can be added in future. =20 So, the proposed requirements are: =20 REQ-x: It MUST be possible to negotiate the usage of centralized media mixing. System support of centralized media mixing is optional. =20 REQ-y: When centralized media mixing is used, it MUST be possible to negotiate the type of media rendering provided for each media stream received by a client. --- [ar] I have a few questions/comments: 1. The term "negotiate" troubles me as I think it means a particular form of communication that dictates the solution. What is being asked for is the receiver to know that it is receiving "centralized media mixing". This may not be the end product of a negotiation. The same is true of the use of the term negotiate in the second requirement. What is needed is a mechanism by which the receiver may know what type of "media rendering" is being received. So, I'd rather offer, The solution must support a means for identifying a stream which is "centralized media mixing". And, When "centralized media mixing" is used, the solution must support a means for identifying...=20 =20 2. Also, I'm not too sure what "media rendering", the phrase in the second reqmt, represents- SDP and RTP recognize audio channels and recognize codecs. Is this what is referred to as "media rendering"? Or is it something different? What very specifically? =20 3. After reading more of the discussion, I realize that I don't fully understand what is meant in the first reqmt by "centralized media mixing" or "rendering", which term is used in another email. I had thought you meant the usual audio mixing such as discussed in RFC 5117.( I figured it was an understood part of the topology so didn't need to be called out in particular. But I don't mind calling it out.) In any case, now I'm not sure what you mean, maybe it is something other than typical MCU mixing behavior as described in RFC 5117? =20 4. As for the discussion of binaural.. here is what it seems like to me.. AVP, RFC 3551 specifies the number of audio channels, what they refer to, and types of codecs. Binaural is neither. As you say, Christer, it's a type of stereo channel. Steve feels that "binaural" must be recognized in SDP, which of course, it is not currently.=20 =20 I'm not entirely sure what needs to be specified about binaural, given that it is neither channel -type nor codec-type. What needs to be standardized? This question is probably more for Steve, or both of you. If the receiving device knows it's getting binaural stereo, then it can run some algorithms to improve quality and if it isn't binaural, it won't run those algs., or something analogous? If that is the case, I don't see what needs to be standardized that isn't already standardized... But I'm eager to learn. =20 Thanks- Allyn=20 =20 Regards, =20 Christer =20 =20 ------_=_NextPart_002_01CC2EDB.56462C8E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

I’m resending my original message to you as I think = the questions it asks are important. I would like to try to get your = requirements clear. I don’t think they are clear yet.

 

Also, as Mary said in her previous email, email discussions = on the list must be 3 days before the virtual meeting in order to be included = in the virtual meeting. Last minute emails won’t be included in the = virtual discussion.

 

I cannot tell if by “centralized media mixing” = you are referring to the normal functions of an MCU, such as described in RTP = Topologies, or if you mean something else? The reason centralized media mixing = wasn’t included in the requirements is because it’s assumed behavior of = an MCU. You can say you want it in the requirements anyway.. the point is what = you mean by it?

 

Also, what kind of support are you asking for binaural? I = believe it’s often considered as a subset of stereo. What are you asking = for? A simple tag that says “binaural”, or  the specification = of a rendering system for binaural? Precisely what are asking = for?

 

I suggest we do not say negotiate, as I think it is = unnecessary and we can use the notion of sending information between senders and = receivers, as is currently specified. Are you all right with the specific = suggestion I made to replace the term “negotiate” as = below?

 

What did you mean by “media rendering”, as = below?

 

 

Thanks,

Allyn

 

 

 

 

Hi Christer –

In spirit I am enthusiastic about what you are proposing = (meaning good quality mobile participation). I’m not clear on how the = spirit becomes instantiated in our protocol, so I have some questions below = J<= o:p>

Thanks,

Allyn

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Christer Holmberg
Sent: Tuesday, June 14, 2011 7:23 AM
To: clue@ietf.org
Subject: [clue] Requirement on centralized media = mixing

 

 

Hi,

 =

During the last interim meeting (May 12th) we discussed a requirement = proposal

stating that an endpoint must be able to request central audio = rendering

of different predefined formats, including 3D binaural rendering. =

 =

The proposal was well received, with the reservation that it should not be mandatory

for the solution to implement centralized 3D binaural rendering, i.e.an = endpoint should

be able to request 3D binaural rendering, but had no guaranty that such = rendering was

supported by the system.

 =

It was decided to look how such requirement could look like.

 =

When I look the -03 version of the req draft, Requirement 2c states: =

 =

  &= nbsp; "The solution MUST NOT preclude the use of binaural = audio."

 =

I think that requirement is unclear, and it doesn't really give any = guidance to our work.

 =

Due to that, and also due to the fact that rather than talking about = specific rendering types,

I would like to propose more general requirement text on the negotiation = of the media mixing type,

and the usage of centralized media mixing in the first place.

 =

The mechanism would be extendable, so new types can be added in = future.

 =

So, the proposed requirements are:

 =

REQ-x: &= nbsp;  It MUST be possible to negotiate the usage of centralized media mixing. = System support of centralized media mixing is optional.

 =

REQ-y: &= nbsp;  When centralized media mixing is used, it MUST be possible to negotiate = the type of media rendering provided for each media stream received by a = client.

 ---

[ar] I have a few = questions/comments:

<= span style=3D'mso-list:Ignore'>1.         The term “negotiate” troubles me as I = think it means a particular form of communication that dictates the solution. = What is being asked for is the receiver to know that it is receiving = “centralized media mixing”. This may not be the end product of a negotiation. = The same is true of the use of the term negotiate in the second requirement. What = is needed is a mechanism by which the receiver may know what type of = “media rendering” is being received.

&= nbsp;    So, I’d rather offer, The solution must support a means for = identifying a stream which is “centralized media = mixing”.

And, When = “centralized media mixing” is used, the solution must support a means for = identifying…

 

<= span style=3D'mso-list:Ignore'>2.       Also,  I’m not too sure what “media rendering”,  the phrase in the second reqmt, represents- SDP = and RTP recognize audio channels and recognize codecs. Is this what is referred = to as “media rendering”? Or is it something different? What very specifically?

 

<= span style=3D'mso-list:Ignore'>3.       After reading more of the discussion, I realize that I = don’t fully understand what is meant in the first reqmt by “centralized = media mixing” or “rendering”, which term is used in another = email. I had thought you meant the usual audio mixing such as discussed in RFC = 5117.( I figured it was an understood part of the topology so didn’t need to  be called out in particular. But I don’t mind calling it out.)  In any case, now I’m not sure what you mean, maybe it = is something other than typical MCU mixing behavior as described in RFC = 5117?

 

<= span style=3D'mso-list:Ignore'>4.       As for the discussion of binaural.. here is what it seems = like to me.. AVP, RFC 3551 specifies  the number of  audio channels, = what they refer to,  and types of codecs. Binaural is neither. As you = say, Christer, it’s a type of stereo channel.  Steve feels that “binaural” must be recognized in SDP, which of course, it is = not currently.

 

I’m not entirely = sure what needs to be specified about binaural, given that it is neither channel –type nor codec-type. What needs to be standardized? This question = is probably more for Steve, or both of you.  If the receiving device = knows it’s getting binaural stereo, then it can run some algorithms to = improve quality and if it isn’t binaural, it won’t run those algs., = or something analogous? If that is the case, I don’t see what needs = to be standardized that isn’t already standardized… But I’m = eager to learn.

 

Thanks—

Allyn

 

Regards,

 =

Christer

 =

 =

------_=_NextPart_002_01CC2EDB.56462C8E-- ------_=_NextPart_001_01CC2EDB.56462C8E Content-Type: text/plain; name="ATT2792105.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2792105.txt Content-Disposition: inline; filename="ATT2792105.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNsdWUgbWFp bGluZyBsaXN0DQpjbHVlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NsdWUNCg== ------_=_NextPart_001_01CC2EDB.56462C8E-- From christer.holmberg@ericsson.com Sun Jun 19 22:24:01 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED84C11E8145 for ; Sun, 19 Jun 2011 22:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.033 X-Spam-Level: X-Spam-Status: No, score=-4.033 tagged_above=-999 required=5 tests=[AWL=-2.435, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huPMyPQBB4TZ for ; Sun, 19 Jun 2011 22:24:01 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AAEE411E807B for ; Sun, 19 Jun 2011 22:24:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-12-4dfed96fdcaa Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AF.A3.09774.F69DEFD4; Mon, 20 Jun 2011 07:23:59 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 20 Jun 2011 07:23:58 +0200 From: Christer Holmberg To: "clue@ietf.org" Date: Mon, 20 Jun 2011 07:23:57 +0200 Thread-Topic: Definition and examples: rendering and rendering type Thread-Index: AcwvCkDBcBHcAt0cQwi2VF2o5xTOpQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB5336404@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336404ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [clue] Definition and examples: rendering and rendering type X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 05:24:02 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336404ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There have been some questions on what we mean by "rendering" and "renderin= g type". Together with my collegeus, I've tried to put together some simple definiti= on text, and some examples, that I hope will clarify. DEFINITONS ---------- Rendering: The procedure when an entity uses one or more input media sign= als to generate an output media signal, using a specific algorithm. Rendering Type: A unique tag associated with a specific algorithm used to= perform central rendering. Audio rendering algorithms -------------------------- An audio rendering algorithm is a linear transformation that transforms mul= tiple input audio signals into a multi-channel output audio signal. There a= re three main types of linear rendering transformations, plain, panning and= 3D binaural. Video rendering algorithms -------------------------- A video rendering algorithm is a linear transformation that transforms mult= iple input video signals into an output video signal. Similar linear render= ing transformations as for audio can be applied. Panning and 3D rendering t= ransformations are the most useful for video. Non-linear rendering -------------------- For both audio and video, the linear algorithms can be combined with or com= plemented by non-linear aspects such as e.g. thresholding that excludes "we= ak" (less active) signals from being included in the render. It is also pos= sible to let some controller (user, conference owner, ...) impact the rende= ring algorithm in a multitude of ways, e.g. controlling the inclusion of in= puts into the rendering. It would also be possible to describe the rendering algorithms as "linear o= r non-linear" and include the aspects above in the algorithms themselves. ALGORITHM EXAMPLES ------------------ Example 1: Plain mixing The simplest audio transformations are the plain mixing transformations. In= the case of a mono output signal and mono and stereo input signals, the pl= ain mixing transformation is simply the sum of all the input signal channel= s. Similarly, in the case of stereo output and mono and stereo input signal= s, the left output signal is the sum of all the left input signals and scal= ed mono signals and the right output signal is the sum of all the right in= put signals and scaled mono signals. For video, it would also be possible to do plain mixing but that would crea= te an output that superimposes the inputs, which is not a particularly usef= ul way of presenting multiple video media. Example 2: Panning The algorithms to perform audio panning and 3D binaural transformations are= much more sophisticated transformations than plain mixing. They try to pos= ition each of the input signal channels, according to some positional layou= t, in the rendered audio space that is generated when the multi-channel oup= ut signal is played through a particular loudspeaker configuration. Video panning is the most common rendering transformation. Input signals ar= e mapped onto a 2D rendering layout where individual input signals can be r= epresented in the output signal having different positions and sizes. The v= ideo version of 3D binaural audio rendering could be a 3D video rendering t= hat maps the input signal into a 3D rendering layout. In that, the input vi= deo signals could themselves be either 2D or 3D. Example 3: Thresholding For audio, input thresholding can exclude weak audio signals from a mix or = pan and by that reduce the resulting output noise level. It can also limit = the number of allowed input sources such as to mix only the N most importan= t onto the output. What inputs are most important can vary, but is typicall= y chosen to be the "most active" where the algorithm for the activity measu= re can also vary. That measure will likely not have to be standardized. For video, it is similarly straightforward to limit the number of input sig= nals, N, that are included in the output mix or pan. When N=3D1, it becomes= a simple switching of input source. Input signal importance is typically t= aken from the importance of the related audio stream; "speaker activity"-ba= sed switching. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336404ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
There have been some = questions on what we mean by "rendering" and "rendering type= ".
 
Together with my coll= egeus, I've tried to put together some simple definition text, and some exa= mples, that I hope will clarify.
 
 
DEFINITONS
----------
 
Rendering:  = ; The procedure when an entity uses one or more input media signals to gene= rate an output media signal, using a specific algorithm.
 
Rendering Type: =   A unique tag associated with a specific algorithm used to perform ce= ntral rendering.
 
 
 
 
Audio rendering algor= ithms
---------------------= -----
 
An audio rendering al= gorithm is a linear transformation that transforms multiple input audio sig= nals into a multi-channel output audio signal. There are three main types o= f linear rendering transformations, plain, panning and 3D binaural.
 
Video rendering algor= ithms
---------------------= -----
 
A video rendering alg= orithm is a linear transformation that transforms multiple input video sign= als into an output video signal. Similar linear rendering transformations a= s for audio can be applied. Panning and 3D rendering transformations are the most useful for video.
 
Non-linear rendering<= /font>
--------------------<= /font>
 
For both audio and vi= deo, the linear algorithms can be combined with or complemented by non-line= ar aspects such as e.g. thresholding that excludes "weak" (less a= ctive) signals from being included in the render. It is also possible to let some controller (user, conference owner, ...) im= pact the rendering algorithm in a multitude of ways, e.g. controlling the i= nclusion of inputs into the rendering.
 
It would also be poss= ible to describe the rendering algorithms as "linear or non-linear&quo= t; and include the aspects above in the algorithms themselves.
 
 
ALGORITHM EXAMPLES
------------------
 
Example 1: Plain mixi= ng
 
The simplest audio tr= ansformations are the plain mixing transformations. In the case of a mono o= utput signal and mono and stereo input signals, the plain mixing transforma= tion is simply the sum of all the input signal channels. Similarly, in the case of stereo output and mono and stere= o input signals, the left output signal is the sum of all the left input si= gnals and scaled mono signals  and the right output signal is the sum = of all the right input signals and scaled mono signals.
 
For video, it would a= lso be possible to do plain mixing but that would create an output that sup= erimposes the inputs, which is not a particularly useful way of presenting = multiple video media.
 
Example 2: Panning
 
The algorithms to per= form audio panning and 3D binaural transformations are much more sophistica= ted transformations than plain mixing. They try to position each of the inp= ut signal channels, according to some positional layout, in the rendered audio space that is generated when the m= ulti-channel ouput signal is played through a particular loudspeaker config= uration.
 
Video panning is the = most common rendering transformation. Input signals are mapped onto a 2D re= ndering layout where individual input signals can be represented in the out= put signal having different positions and sizes. The video version of 3D binaural audio rendering could be a 3D v= ideo rendering that maps the input signal into a 3D rendering layout. In th= at, the input video signals could themselves be either 2D or 3D.
 
Example 3: Thresholdi= ng
 
For audio, input thre= sholding can exclude weak audio signals from a mix or pan and by that reduc= e the resulting output noise level. It can also limit the number of allowed= input sources such as to mix only the N most important onto the output. What inputs are most important can vary, = but is typically chosen to be the "most active" where the algorit= hm for the activity measure can also vary. That measure will likely not hav= e to be standardized.
 
For video, it is simi= larly straightforward to limit the number of input signals, N, that are inc= luded in the output mix or pan. When N=3D1, it becomes a simple switching o= f input source. Input signal importance is typically taken from the importance of the related audio stream; "s= peaker activity"-based switching.
 
 
Regards,
 
Christer
 
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336404ESESSCMS0356e_-- From christer.holmberg@ericsson.com Sun Jun 19 22:28:53 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C810611E80BB for ; Sun, 19 Jun 2011 22:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+qYBiqSPbC9 for ; Sun, 19 Jun 2011 22:28:52 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7814B11E807B for ; Sun, 19 Jun 2011 22:28:52 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-44-4dfeda92f45d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3A.25.09774.29ADEFD4; Mon, 20 Jun 2011 07:28:50 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 20 Jun 2011 07:28:47 +0200 From: Christer Holmberg To: "Allyn Romanow (allyn)" , Mary Barnes Date: Mon, 20 Jun 2011 07:28:46 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwqno7BLwl3j+PMSjaOF3ZfYi/FNwBOY9JAAMyJxDA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB5336406@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A3@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A3@xmb-sjc-221.amer.cisco.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 X-Brightmail-Tracker: AAAAAA== Cc: "Botzko, Stephen" , "clue@ietf.org" , "Bill Mauchly \(bmauchly\)" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 05:28:54 -0000 Hi Allyn, I appologise that it took some time to reply. We've been working on some definition/example text (I sent it to the list j= ust a few minutes ago), which I hope will clarify some of the questions tha= t have been asked.=20 >Also, what kind of support are you asking for binaural? I believe it's oft= en considered as a subset of stereo. What are you asking for? A simple tag = that says "binaural", or the specification=20 >of a rendering system for binaural? Precisely what are asking for? >From CLUE, we are only asking for a general mechanism to request and indica= te different rendering types (see definition in other e-mail). An example of such rendering type is binaural, BUT we are *NOT* asking CLUE= to define any binaural specific SDP attributes etc. If such are needed, we= agree that it needs to be done as a separate task. Before I try to answer your other questions, please take a look at the defi= nition/example e-mail, which I hope will clarify what we mean by rendering = and rendering type. Regards, Christer =20 =20 =20 =20 Hi Christer - In spirit I am enthusiastic about what you are proposing (meaning good qua= lity mobile participation). I'm not clear on how the spirit becomes instant= iated in our protocol, so I have some questions below J Thanks, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ch= rister Holmberg Sent: Tuesday, June 14, 2011 7:23 AM To: clue@ietf.org Subject: [clue] Requirement on centralized media mixing =20 =20 Hi, =20 During the last interim meeting (May 12th) we discussed a requirement prop= osal stating that an endpoint must be able to request central audio rendering of different predefined formats, including 3D binaural rendering.=20 (Link to proposal: http://www.ietf.org/mail-archive/web/clue/current/msg00= 179.html) =20 The proposal was well received, with the reservation that it should not be= mandatory=20 for the solution to implement centralized 3D binaural rendering, i.e.an en= dpoint should=20 be able to request 3D binaural rendering, but had no guaranty that such re= ndering was=20 supported by the system. =20 It was decided to look how such requirement could look like. =20 When I look the -03 version of the req draft, Requirement 2c states:=20 =20 "The solution MUST NOT preclude the use of binaural audio." =20 I think that requirement is unclear, and it doesn't really give any guidan= ce to our work. =20 Due to that, and also due to the fact that rather than talking about speci= fic rendering types,=20 I would like to propose more general requirement text on the negotiation o= f the media mixing type,=20 and the usage of centralized media mixing in the first place. =20 The mechanism would be extendable, so new types can be added in future. =20 So, the proposed requirements are: =20 REQ-x: It MUST be possible to negotiate the usage of centralized media = mixing. System support of centralized media mixing is optional. =20 REQ-y: When centralized media mixing is used, it MUST be possible to ne= gotiate the type of media rendering provided for each media stream received= by a client. --- [ar] I have a few questions/comments: 1. The term "negotiate" troubles me as I think it means a particul= ar form of communication that dictates the solution. What is being asked fo= r is the receiver to know that it is receiving "centralized media mixing". = This may not be the end product of a negotiation. The same is true of the u= se of the term negotiate in the second requirement. What is needed is a mec= hanism by which the receiver may know what type of "media rendering" is bei= ng received. So, I'd rather offer, The solution must support a means for identifyi= ng a stream which is "centralized media mixing". And, When "centralized media mixing" is used, the solution must support a = means for identifying...=20 =20 2. Also, I'm not too sure what "media rendering", the phrase in th= e second reqmt, represents- SDP and RTP recognize audio channels and recogn= ize codecs. Is this what is referred to as "media rendering"? Or is it some= thing different? What very specifically? =20 3. After reading more of the discussion, I realize that I don't full= y understand what is meant in the first reqmt by "centralized media mixing"= or "rendering", which term is used in another email. I had thought you mea= nt the usual audio mixing such as discussed in RFC 5117.( I figured it was = an understood part of the topology so didn't need to be called out in part= icular. But I don't mind calling it out.) In any case, now I'm not sure wh= at you mean, maybe it is something other than typical MCU mixing behavior a= s described in RFC 5117? =20 4. As for the discussion of binaural.. here is what it seems like to= me.. AVP, RFC 3551 specifies the number of audio channels, what they ref= er to, and types of codecs. Binaural is neither. As you say, Christer, it'= s a type of stereo channel. Steve feels that "binaural" must be recognized= in SDP, which of course, it is not currently.=20 =20 I'm not entirely sure what needs to be specified about binaural, given tha= t it is neither channel -type nor codec-type. What needs to be standardized= ? This question is probably more for Steve, or both of you. If the receivi= ng device knows it's getting binaural stereo, then it can run some algorith= ms to improve quality and if it isn't binaural, it won't run those algs., o= r something analogous? If that is the case, I don't see what needs to be st= andardized that isn't already standardized... But I'm eager to learn. =20 Thanks- Allyn=20 =20 Regards, =20 Christer =20 =20 From mary.ietf.barnes@gmail.com Mon Jun 20 00:15:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8F811E8077 for ; Mon, 20 Jun 2011 00:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZOstr7G+WDm for ; Mon, 20 Jun 2011 00:15:45 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3BD228016 for ; Mon, 20 Jun 2011 00:15:44 -0700 (PDT) Received: by vws12 with SMTP id 12so361694vws.31 for ; Mon, 20 Jun 2011 00:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=Xvy+ZlGSYtud90DCKm2KbnyyquFjZ5dfFLCKOoCuc7w=; b=vrajhnwKfCyoeWAV1KPFqTuoTCRbNrejy7wECbLuHCTCVcuF0vaVfOg2LCPS3d7sOS BkcKLNX7F52Qvi2yiRkvdQ2oDe3+PaNJoFw6LILgbhLhXBME6oPYHHKxABAqjVBHnDe9 XMT+3cZl4ojxs61zrYKMmiqHt8NdlR+P5zJhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=bBwD7Ugngs37JZX4SsT4m5FtK1i2hhryB1vHgx0aXiFnknGb3BNeHkEIkFxEaDHB2o TKwFgHzyehx43FXBAvFsjAkEdPOq4JGFNk68u9jigfHNEHgp3OSdTwDOiiBmj8lqlArU dqguxdr9p5wIB/Tq3woQJhseuoR1Su2+1gblo= MIME-Version: 1.0 Received: by 10.52.99.69 with SMTP id eo5mr23896vdb.303.1308554143655; Mon, 20 Jun 2011 00:15:43 -0700 (PDT) Received: by 10.52.158.39 with HTTP; Mon, 20 Jun 2011 00:15:43 -0700 (PDT) Date: Mon, 20 Jun 2011 02:15:43 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307ca06ee6e8af04a61f8057 Subject: [clue] Reminder: Preparing for Interim meeting on Thursday X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 07:15:46 -0000 --20cf307ca06ee6e8af04a61f8057 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi folks, As a reminder, we expect that folks that are participating in the meeting o= n Thursday have reviewed the requirements document in detail. The primary discussion on the mailing list has been around the lack of a specific requirement in the document with virtually no feedback on the requirements that are in the document. We can't have an effective meeting if folks are reading the document for the first time during the meeting. At this point in time, it will be difficult for Allyn to assimilate issues into charts if they arrive any later than 5pm Pacific today (Monday, June 20th). As a reminder the material for the meeting will be available on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki We'll try to have the detailed agenda out by the end of the day on Tuesday. Thanks, Mary. On Thu, Jun 9, 2011 at 9:19 AM, Mary Barnes wro= te: > As chair, I just want to add that it is extremely important that folks > review this updated document in detail. The requirements have been prett= y > much re-written,so a diff would not be particularly useful. > > If you could please review the document and past any concerns on the > mailing list prior to June 17th, that will give Allyn time to assimilate = the > issues into discussion points for the meeting. > > Thanks, > Mary. > > On Wed, Jun 8, 2011 at 8:50 PM, Allyn Romanow (allyn) wr= ote: > >> Folks, >> Here is a new draft of my CLUE requirements draft. Steve Botzko and Mark >> Goryzinski are co-authors. >> >> This draft focused only on the Requirements section, not on the other >> sections (Intro and Problem Statement). The definitions are taken from >> Stephan=92s draft. >> >> The main goal of this draft is to express requirements precisely enough = to >> have a productive discussion- and not so specifically as to design the >> solution within the requirements document. >> >> Everyone will have particular things they want to make sure are covered. >> This is good. Hopefully, the requirements are general enough to cover ou= r >> specific requirements =96 where not, new well-specified requirements can= be >> added. >> >> We=92ll expect plenty of conversation- >> >> Thanks, >> Allyn >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, June 08, 2011 6:47 PM >> To: Allyn Romanow (allyn) >> Cc: Allyn Romanow (allyn); stephen.botzko@polycom.com; >> mark.gorzynski@hp.com >> Subject: New Version Notification >> fordraft-romanow-clue-telepresence-requirements-03.txt >> >> A new version of I-D, draft-romanow-clue-telepresence-requirements-03.tx= t >> has been successfully submitted by Allyn Romanow and posted to the IETF >> repository. >> >> Filename: draft-romanow-clue-telepresence-requirements >> Revision: 03 >> Title: Requirements for Telepresence Multi-Streams >> Creation date: 2011-06-09 >> WG ID: Individual Submission >> Number of pages: 12 >> >> Abstract: >> This memo discusses the requirements for a specification that enables >> telepresence interoperability, by describing the relationship between >> multiple RTP streams. In addition, the problem statement and >> definitions are also covered herein. >> >> >> >> >> The IETF Secretariat >> > > --20cf307ca06ee6e8af04a61f8057 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi folks,

As a reminder, we expect that folks that are p= articipating in the meeting on Thursday have reviewed the requirements docu= ment in detail. =A0 The primary discussion on the mailing list has been aro= und the lack of a specific requirement in the document with virtually no fe= edback on the requirements that are in the document. We can't have an e= ffective meeting if folks are reading the document for the first time durin= g the meeting. =A0

At this point in time, it will be difficult for Allyn t= o assimilate issues into charts if they arrive any later than 5pm Pacific t= oday (Monday, June 20th).

As a reminder the materi= al for the meeting will be available on the CLUE WG wiki:

We'll try = to have the detailed agenda out by the end of the day on Tuesday. =A0

Thanks,
Mary.=A0

On Thu, Jun 9, 2011 at 9:19 AM, Mary Barnes = <mary.ietf.barnes@gmail.co= m> wrote:
As chair, I just want to add that it i= s extremely important that folks review this updated document in detail.=A0= The requirements have been pretty much re-written,so a diff would not be p= articularly useful.=A0=A0
=A0
If=A0you could please review the document and past any concerns on the= mailing list prior to June 17th, that will give Allyn time to assimilate t= he issues into discussion points for the meeting.=A0
=A0
Thanks,
Mary. =A0

On Wed, Jun 8, 2011 at 8:50 PM, Allyn Romanow (a= llyn) <allyn@cisco.com> wrote:
Folks,
Here is a new draft of my C= LUE requirements draft. Steve Botzko and Mark Goryzinski are co-authors.
This draft focused only on the Requirements section, not on the other s= ections (Intro and Problem Statement). The definitions are taken from Steph= an=92s draft.

The main goal of this draft is to express requirements= precisely enough to have a productive discussion- and not so specifically = as to design the solution within the requirements document.

Everyone will have particular things they want to make sure are covered= . This is good. Hopefully, the requirements are general enough to cover our= specific requirements =96 where not, new well-specified requirements can b= e added.

We=92ll expect plenty of conversation-

Thanks,
Allyn

-= ----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=
Sent: Wednesday, June 08, 2011 6:47 PM
To: Allyn Romanow (allyn)
Cc: = Allyn Romanow (allyn); stephen.botzko@polycom.com; mark.gorzynski@hp.com
Subject: New Version Notification fordraft-romanow-clue-telepresence-requir= ements-03.txt

A new version of I-D, draft-romanow-clue-telepresence-= requirements-03.txt has been successfully submitted by Allyn Romanow and po= sted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-romanow-clue-telepresence-requirementsRevision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 Requirements fo= r Telepresence Multi-Streams
Creation date: =A0 2011-06-09
WG ID: =A0= =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12

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




The IETF Secret= ariat


--20cf307ca06ee6e8af04a61f8057-- From john.elwell@siemens-enterprise.com Mon Jun 20 00:53:10 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6076B11E80F9 for ; Mon, 20 Jun 2011 00:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6tFTr-TAeAx for ; Mon, 20 Jun 2011 00:53:09 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 5FBAB11E80F6 for ; Mon, 20 Jun 2011 00:53:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1308556387!19868575!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 31037 invoked from network); 20 Jun 2011 07:53:07 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-6.tower-174.messagelabs.com with SMTP; 20 Jun 2011 07:53:07 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id CE8EF23F03E2; Mon, 20 Jun 2011 09:53:07 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 20 Jun 2011 09:53:07 +0200 From: "Elwell, John" To: "Allyn Romanow (allyn)" , "clue@ietf.org" Date: Mon, 20 Jun 2011 09:53:05 +0200 Thread-Topic: [clue] Comment on requirements-03 - aspect ratio Thread-Index: AcwreYbvuyWp0YkTT8mIyfuGzYlTTADYGxNwABEotaA= Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A5@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A5@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Comment on requirements-03 - aspect ratio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 07:53:10 -0000 Allyn, Removal of 1c is fine. Concerning 1d, I searched for multi-view in the rest of the document and in= the use cases, but couldn't find it, so if we retain it in the form of a s= eparate requirement, it would certainly need more explanation. John=20 > -----Original Message----- > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 > Sent: 20 June 2011 00:45 > To: Elwell, John; clue@ietf.org > Subject: RE: [clue] Comment on requirements-03 - aspect ratio >=20 > Hi John, > Thanks for your comments.=20 > I agree with them. >=20 > Aspect ratio is not part of ordering, and should be a separate > requirement, not part of Reqmt 1. Reqmt 6 which says The solution MUST > support means of enabling > interoperability between telepresence endpoints where > cameras are of different aspect ratios. > Certainly includes supporting communicating information about aspect > ratio, which is what 1c says. >=20 > Also, 1d, on supporting multi-view, as described in use=20 > cases, could be > pulled out of 1 and made a separate requirement as well.=20 >=20 > I propose making these changes. How is that? >=20 > Regards, > Allyn >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Elwell, John > > Sent: Wednesday, June 15, 2011 9:30 AM > > To: clue@ietf.org > > Subject: [clue] Comment on requirements-03 - aspect ratio > >=20 > > We have: > > "REQMT-1: The solution MUST support a description of the spatial > > arrangement of source video images sent in=20 > video streams > > which enables a satisfactory reproduction at the > receiver > > of the original scene. This applies to each site in a > > point to point or a multipoint meeting and=20 > refers to the > > spatial ordering within a site, not to the ordering of > > images between sites." > > and below that: > > "REQMT-1c: The solution MUST support a means to > > communicate the aspect ratio." > > Is this the aspect ratio of a particular camera? If so, what is the > > relevance of this to REQMT-1, which is concerned with the spatial > > ordering of video images? Also REQMT-6 addresses aspect=20 > ratios, so how > > does REQMT-1c relate to REQMT-6? > >=20 > > John > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > = From internet-drafts@ietf.org Mon Jun 20 01:05:00 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F20521F8489; Mon, 20 Jun 2011 01:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K-n+cBvIeQy; Mon, 20 Jun 2011 01:05:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B2921F8480; Mon, 20 Jun 2011 01:05:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110620080500.22343.74581.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 01:05:00 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 08:05:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEle= presence Working Group of the IETF. Title : Use Cases for Telepresence Multi-streams Author(s) : Allyn Romanow Stephen Botzko Mark Duckworth Roni Even Iformata Communications Filename : draft-ietf-clue-telepresence-use-cases-00.txt Pages : 15 Date : 2011-06-20 Telepresence conferencing systems seek to create the sense of really being present. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-clue-telepresence-use-cases-= 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-telepresence-use-cases-0= 0.txt From stephen.botzko@gmail.com Mon Jun 20 02:58:47 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D9111E80D0 for ; Mon, 20 Jun 2011 02:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSGhXOSDazrH for ; Mon, 20 Jun 2011 02:58:46 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C27EF11E80B4 for ; Mon, 20 Jun 2011 02:58:45 -0700 (PDT) Received: by vws12 with SMTP id 12so455443vws.31 for ; Mon, 20 Jun 2011 02:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bki4F4LN50ZeKahv7Or5lE20WGxyCzHQiZoYNo9C6Q8=; b=Rg5O5zYHwSM9+yQaNB9fcFF/q/ef3FE8ZKYLIIa7mV9RDx9gYVfp2IvSP3tBmSQpDg cSBWGun6mPOGrEPQ02H4ELGyGZ/J36sehQdyCgY1ASHhe49SZ1mmofAa2YgBSte+GUoj cKDNzpsTfozYxhGx7L/8aDSxSHVSa5C7g/7f4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dREx6BqmGA6rktZu2dpwqff/w0scZFaCtSMdgMHghwJDS3TvqC/9S57zmDd/h9FqB9 jpTzjDWuXlngB/jyBYY5o7GMV25iGPd/BU6kQoZnsCY3/oCpOltZFfNkCYOiG2vQpDTD i/zGk9vLwW4MuUw4UIMW7rnpRXZyxJJRKxQj0= MIME-Version: 1.0 Received: by 10.52.95.148 with SMTP id dk20mr5544418vdb.120.1308563925046; Mon, 20 Jun 2011 02:58:45 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Mon, 20 Jun 2011 02:58:45 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A5@xmb-sjc-221.amer.cisco.com> Date: Mon, 20 Jun 2011 05:58:45 -0400 Message-ID: From: Stephen Botzko To: "Elwell, John" Content-Type: multipart/alternative; boundary=20cf307f374ceb15ef04a621c725 Cc: "clue@ietf.org" Subject: Re: [clue] Comment on requirements-03 - aspect ratio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 09:58:47 -0000 --20cf307f374ceb15ef04a621c725 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable in-line Stephen Botzko On Mon, Jun 20, 2011 at 3:53 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Allyn, > > Removal of 1c is fine. > > I think the proposal is to move it, not remove it altogether. > Concerning 1d, I searched for multi-view in the rest of the document and = in > the use cases, but couldn't find it, so if we retain it in the form of a > separate requirement, it would certainly need more explanation. > > There was a use case put on the list about a month ago by Mark Gorzynski. I think it would be useful to add it to the use cases draft. >>> 1. Virtual Space Multipoint This use case describes a virtual space multipoint video meeting with good eye contact and spatial layout of participants. The use case was proposed very early in the development of video conferencing systems as described in 1983 by Allardyce and Randal (http://handle.dtic.mil/100.2/ADA127738 ). The use case is illustrated in figure 2-5 of their report. Today, the use case is implemented in multiple telepresence type video conferencing system= s on the market. The term =93virtual space=94 was used in their report. The= main difference between the result obtained with modern systems and those from 1983 are larger display sizes. Virtual space multipoint as defined here assumes endpoints with multiple cameras and displays. Usually there are the same number of cameras and displays at a given endpoint. A camera is positioned above each display. = A key aspect of virtual space multipoint is the details of how the cameras ar= e aimed. The cameras are each aimed on the same area of view of the participants at the site. Thus each camera takes a picture of the same set of people but from a different angle. Each endpoint sender in the virtual space multipoint meeting therefore offers a choice of video streams to remote receivers, each stream representing a different view point. For example a camera positioned above a display to a participant=92s left may t= ake video pictures of the participant=92s left ear while at the same time, a camera positioned above a display to the participant=92s right may take vid= eo pictures of the participant=92s right ear. Since a sending endpoint has a camera associated with each display, an association is made between the receiving stream output on a particular display and the corresponding sending stream from the camera associated wit= h that display. These associations are repeated for each display/camera pair in a meeting. The result of this system is a horizontal arrangement of video images from remote sites, one per display. The image from each display is paired with the camera output from the camera above that display resulting in excellent eye contact. >>> > John > > > -----Original Message----- > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > Sent: 20 June 2011 00:45 > > To: Elwell, John; clue@ietf.org > > Subject: RE: [clue] Comment on requirements-03 - aspect ratio > > > > Hi John, > > Thanks for your comments. > > I agree with them. > > > > Aspect ratio is not part of ordering, and should be a separate > > requirement, not part of Reqmt 1. Reqmt 6 which says The solution MUST > > support means of enabling > > interoperability between telepresence endpoints where > > cameras are of different aspect ratios. > > Certainly includes supporting communicating information about aspect > > ratio, which is what 1c says. > > > > Also, 1d, on supporting multi-view, as described in use > > cases, could be > > pulled out of 1 and made a separate requirement as well. > > > > I propose making these changes. How is that? > > > > Regards, > > Allyn > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of > > > Elwell, John > > > Sent: Wednesday, June 15, 2011 9:30 AM > > > To: clue@ietf.org > > > Subject: [clue] Comment on requirements-03 - aspect ratio > > > > > > We have: > > > "REQMT-1: The solution MUST support a description of the spatial > > > arrangement of source video images sent in > > video streams > > > which enables a satisfactory reproduction at the > > receiver > > > of the original scene. This applies to each site in a > > > point to point or a multipoint meeting and > > refers to the > > > spatial ordering within a site, not to the ordering of > > > images between sites." > > > and below that: > > > "REQMT-1c: The solution MUST support a means to > > > communicate the aspect ratio." > > > Is this the aspect ratio of a particular camera? If so, what is the > > > relevance of this to REQMT-1, which is concerned with the spatial > > > ordering of video images? Also REQMT-6 addresses aspect > > ratios, so how > > > does REQMT-1c relate to REQMT-6? > > > > > > John > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307f374ceb15ef04a621c725 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable in-line

Stephen Botzko

On Mon, Jun= 20, 2011 at 3:53 AM, Elwell, John <john.elwell@siemens-e= nterprise.com> wrote:
Allyn,

Removal of 1c is fine.

I think the proposal is to move it, not remove it alt= ogether.
=A0

There was a use case p= ut on the list about a month ago by Mark Gorzynski.=A0 I think it would be = useful to add it to the use cases draft.
>>>
1. Virtual Space Multipoint =A0

This use case describes a virtual space multipoint video meeting with good=20 eye contact and spatial layout of participants.=A0 The use case was=20 proposed very early in the development of video conferencing systems as=20 described in 1983 by Allardyce and Randal (http://handle.dtic.mil/100.2/ADA127738= =A0).=A0 The use case is illustrated in figure 2-5 of their report.=A0 Tod= ay, the use case is implemented in multiple telepresence type video=20 conferencing systems on the market.=A0 The term =93virtual space=94 was use= d=20 in their report.=A0 The main difference between the result obtained with=20 modern systems and those from 1983 are larger display sizes.

=A0

Virtual space multipoint as defined here assumes endpoints with multiple=20 cameras and displays.=A0 Usually there are the same number of cameras and= =20 displays at a given endpoint.=A0 A camera is positioned above each=20 display.=A0 A key aspect of virtual space multipoint is the details of how the cameras are aimed.=A0 The cameras are each aimed on the same area of= =20 view of the participants at the site.=A0 Thus each camera takes a picture= =20 of the same set of people but from a different angle.=A0 Each endpoint=20 sender in the virtual space multipoint meeting therefore offers a choice of video streams to remote receivers, each stream representing a=20 different view point.=A0 For example a camera positioned above a display=20 to a participant=92s left may take video pictures of the participant=92s=20 left ear while at the same time, a camera positioned above a display to=20 the participant=92s right may take video pictures of the participant=92s=20 right ear.

=A0

Since a sending endpoint has a camera associated with each display, an=20 association is made between the receiving stream output on a particular=20 display and the corresponding sending stream from the camera associated=20 with that display.=A0 These associations are repeated for each=20 display/camera pair in a meeting.=A0 The result of this system is a=20 horizontal arrangement of video images from remote sites, one per=20 display.=A0 The image from each display is paired with the camera output=20 from the camera above that display resulting in excellent eye contact.
&= gt;>>
=A0
John

> -----Original Message-----
> From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
> Sent: 20 June 2011 00:45
> To: Elwell, John; c= lue@ietf.org
> Subject: RE: [clue] Comment on requirements-03 - aspect ratio
>
> Hi John,
> Thanks for your comments.
> I agree with them.
>
> Aspect ratio is not part of ordering, and should be a separate
> requirement, not part of Reqmt 1. Reqmt 6 which says The solution MUST=
> support means of enabling
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 interoperability between telepresence endp= oints where
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 cameras are of different aspect ratios. > Certainly includes supporting communicating information about aspect > ratio, which is what 1c says.
>
> Also, 1d, on supporting multi-view, as described in use
> cases, could be
> pulled out of 1 and made a separate requirement as well.
>
> I propose making these changes. How is that?
>
> Regards,
> Allyn
>
> > -----Original Message-----
> > From: = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
> Of
> > Elwell, John
> > Sent: Wednesday, June 15, 2011 9:30 AM
> > To: clue@ietf.= org
> > Subject: [clue] Comment on requirements-03 - aspect ratio
> >
> > We have:
> > "REQMT-1: =A0 The solution MUST support a description of the= spatial
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 arrangement of source video images se= nt in
> video streams
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 which enables a satisfactory reproduc= tion at the
> receiver
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 of the original scene. =A0This applie= s to each site in a
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 point to point or a multipoint meetin= g and
> refers to the
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 spatial ordering within a site, not t= o the ordering of
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 images between sites."
> > and below that:
> > "REQMT-1c: =A0The solution MUST support a means to
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0communicate th= e aspect ratio."
> > Is this the aspect ratio of a particular camera? If so, what is t= he
> > relevance of this to REQMT-1, which is concerned with the spatial=
> > ordering of video images? Also REQMT-6 addresses aspect
> ratios, so how
> > does REQMT-1c relate to REQMT-6?
> >
> > John
> > _______________________________________________
> > clue mailing list
> > clue@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/clue
>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf307f374ceb15ef04a621c725-- From Even.roni@huawei.com Mon Jun 20 04:55:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A60A11E807E for ; Mon, 20 Jun 2011 04:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.494 X-Spam-Level: X-Spam-Status: No, score=-104.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqoXczfKXEgR for ; Mon, 20 Jun 2011 04:55:30 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7E76811E807A for ; Mon, 20 Jun 2011 04:55:30 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN300BVG7ONXT@szxga03-in.huawei.com> for clue@ietf.org; Mon, 20 Jun 2011 19:53:11 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN300BWX7ON33@szxga03-in.huawei.com> for clue@ietf.org; Mon, 20 Jun 2011 19:53:11 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-35-190.red.bezeqint.net [79.176.35.190]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN3009VL7OC28@szxml12-in.huawei.com> for clue@ietf.org; Mon, 20 Jun 2011 19:53:11 +0800 (CST) Date: Mon, 20 Jun 2011 14:51:08 +0300 From: Roni Even To: clue@ietf.org Message-id: <005101cc2f40$5e997730$1bcc6590$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6D7Ul+Iz8/KiekSDXv5EnQ)" Content-language: en-us Thread-index: AcwvQFabRfCAj//wR3yyoyznvwXf0Q== Subject: [clue] comments on Requirement draft X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 11:55:31 -0000 This is a multi-part message in MIME format. --Boundary_(ID_6D7Ul+Iz8/KiekSDXv5EnQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I think that the draft should include a reference to the use case draft since it mention it in the requirements section. Maybe the introduction should mention that the use cases draft is used for the requirements. I am not sure what is the meaning or use case for requirement 5. Regards Roni --Boundary_(ID_6D7Ul+Iz8/KiekSDXv5EnQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I think that the draft should include a reference to the use case draft since it mention it in the requirements section. Maybe the introduction should mention that the use cases draft is used for the requirements.

 

I am not sure what is the meaning or use case for requirement 5.

 

Regards

Roni

--Boundary_(ID_6D7Ul+Iz8/KiekSDXv5EnQ)-- From espeberg@cisco.com Mon Jun 20 05:04:27 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9142211E807E for ; Mon, 20 Jun 2011 05:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBSAUIPWEpyA for ; Mon, 20 Jun 2011 05:04:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9377B11E807A for ; Mon, 20 Jun 2011 05:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=2999; q=dns/txt; s=iport; t=1308571466; x=1309781066; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=S1+nCwCnlHVOA9JLHx12oRosuFWqspTNJtqQfxPT56Y=; b=Dy0Cq2myEiptzTIQJM3jwhNZYXqGJl6jVFq2pdNIT9vqroaQJup9KYGN eTXsQo0iqjGnmC6dpVNO69Rh7+O3hz6Xor5vw86BuYXfd7XsX4WWNHlRP cRxybYptrU5cRKLeCVK5wmeOUfDoPnBKQhD3d3dqqqz8CNPvp76j5RVFV 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAABo2/02Q/khL/2dsb2JhbABTl1GPCnepdp1WhioElkeLGg X-IronPort-AV: E=Sophos;i="4.65,394,1304294400"; d="scan'208";a="94873422" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2011 12:04:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5KC4Oox008517; Mon, 20 Jun 2011 12:04:24 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 14:04:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 14:04:23 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E71B6C4@XMB-AMS-214.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A5@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Comment on requirements-03 - aspect ratio Thread-Index: AcwreYbvuyWp0YkTT8mIyfuGzYlTTADYGxNwABjSwHA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A5@xmb-sjc-221.amer.cisco.com> From: "Espen Berger (espeberg)" To: "Allyn Romanow (allyn)" , "Elwell, John" , X-OriginalArrivalTime: 20 Jun 2011 12:04:24.0464 (UTC) FILETIME=[32452100:01CC2F42] Subject: Re: [clue] Comment on requirements-03 - aspect ratio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:04:27 -0000 I did not fully understand the reason for REQ-6, REQ-7 and REQ-8. These requirements are already covered in current decode rules for H.264 video. A decoder:=20 - should decode any aspect-ratio below the frame-size it can receive=20 - should decode any resolution below the max frame size=20 - The renderer is free to chose display size In addition to frame-size and aspects-ratio there are a large number of other parameters that could be negotiated in SDP and I do not think we should duplicate those in the CLUE-requirement documentation.=20 Should we drop REQ 6, 7, 8 and instead refer to SDP mechanisms for negotiating video and audio parameters? Cheers=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) Sent: 20. juni 2011 01:45 To: Elwell, John; clue@ietf.org Subject: Re: [clue] Comment on requirements-03 - aspect ratio Hi John, Thanks for your comments.=20 I agree with them. Aspect ratio is not part of ordering, and should be a separate requirement, not part of Reqmt 1. Reqmt 6 which says The solution MUST support means of enabling interoperability between telepresence endpoints where cameras are of different aspect ratios. Certainly includes supporting communicating information about aspect ratio, which is what 1c says. Also, 1d, on supporting multi-view, as described in use cases, could be pulled out of 1 and made a separate requirement as well.=20 I propose making these changes. How is that? Regards, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Elwell, John > Sent: Wednesday, June 15, 2011 9:30 AM > To: clue@ietf.org > Subject: [clue] Comment on requirements-03 - aspect ratio >=20 > We have: > "REQMT-1: The solution MUST support a description of the spatial > arrangement of source video images sent in video streams > which enables a satisfactory reproduction at the receiver > of the original scene. This applies to each site in a > point to point or a multipoint meeting and refers to the > spatial ordering within a site, not to the ordering of > images between sites." > and below that: > "REQMT-1c: The solution MUST support a means to > communicate the aspect ratio." > Is this the aspect ratio of a particular camera? If so, what is the > relevance of this to REQMT-1, which is concerned with the spatial > ordering of video images? Also REQMT-6 addresses aspect ratios, so how > does REQMT-1c relate to REQMT-6? >=20 > John > _______________________________________________ > clue mailing 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 john.elwell@siemens-enterprise.com Mon Jun 20 05:55:34 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E91711E8178 for ; Mon, 20 Jun 2011 05:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr9kQsvhpqAm for ; Mon, 20 Jun 2011 05:55:33 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id D43BA11E8170 for ; Mon, 20 Jun 2011 05:55:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1308574531!8904439!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 13082 invoked from network); 20 Jun 2011 12:55:31 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-8.tower-174.messagelabs.com with SMTP; 20 Jun 2011 12:55:31 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 7D84423F03E6; Mon, 20 Jun 2011 14:55:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 20 Jun 2011 14:55:31 +0200 From: "Elwell, John" To: Stephen Botzko Date: Mon, 20 Jun 2011 14:55:30 +0200 Thread-Topic: [clue] Comment on requirements-03 - aspect ratio Thread-Index: AcwvMKY9CruP2ZOFRnWx+7q2GQfjQQAGH7Cw Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A5@xmb-sjc-221.amer.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] Comment on requirements-03 - aspect ratio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:55:34 -0000 =20 > -----Original Message----- > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 > Sent: 20 June 2011 10:59 > To: Elwell, John > Cc: Allyn Romanow (allyn); clue@ietf.org > Subject: Re: [clue] Comment on requirements-03 - aspect ratio >=20 > in-line >=20 > Stephen Botzko >=20 >=20 > On Mon, Jun 20, 2011 at 3:53 AM, Elwell, John=20 > wrote: >=20 >=20 > Allyn, > =09 > Removal of 1c is fine. > =09 > =09 >=20 > I think the proposal is to move it, not remove it altogether. [JRE] I thought the proposal was that the existing REQMT-6 already covers i= t, and hence 1c can just be deleted. John > =20 >=20 >=20 > Concerning 1d, I searched for multi-view in the rest of=20 > the document and in the use cases, but couldn't find it, so=20 > if we retain it in the form of a separate requirement, it=20 > would certainly need more explanation. > =09 > =09 >=20 > There was a use case put on the list about a month ago by=20 > Mark Gorzynski. I think it would be useful to add it to the=20 > use cases draft. > >>> > 1. Virtual Space Multipoint=20 >=20 > =20 >=20 > This use case describes a virtual space multipoint video=20 > meeting with good eye contact and spatial layout of=20 > participants. The use case was proposed very early in the=20 > development of video conferencing systems as described in=20 > 1983 by Allardyce and Randal=20 > (http://handle.dtic.mil/100.2/ADA127738 ). The use case is=20 > illustrated in figure 2-5 of their report. Today, the use=20 > case is implemented in multiple telepresence type video=20 > conferencing systems on the market. The term "virtual space"=20 > was used in their report. The main difference between the=20 > result obtained with modern systems and those from 1983 are=20 > larger display sizes. >=20 > =20 >=20 > Virtual space multipoint as defined here assumes endpoints=20 > with multiple cameras and displays. Usually there are the=20 > same number of cameras and displays at a given endpoint. A=20 > camera is positioned above each display. A key aspect of=20 > virtual space multipoint is the details of how the cameras=20 > are aimed. The cameras are each aimed on the same area of=20 > view of the participants at the site. Thus each camera takes=20 > a picture of the same set of people but from a different=20 > angle. Each endpoint sender in the virtual space multipoint=20 > meeting therefore offers a choice of video streams to remote=20 > receivers, each stream representing a different view point. =20 > For example a camera positioned above a display to a=20 > participant's left may take video pictures of the=20 > participant's left ear while at the same time, a camera=20 > positioned above a display to the participant's right may=20 > take video pictures of the participant's right ear.=20 >=20 > =20 >=20 > Since a sending endpoint has a camera associated with each=20 > display, an association is made between the receiving stream=20 > output on a particular display and the corresponding sending=20 > stream from the camera associated with that display. These=20 > associations are repeated for each display/camera pair in a=20 > meeting. The result of this system is a horizontal=20 > arrangement of video images from remote sites, one per=20 > display. The image from each display is paired with the=20 > camera output from the camera above that display resulting in=20 > excellent eye contact. > >>> > =20 >=20 > John > =09 >=20 > > -----Original Message----- > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > Sent: 20 June 2011 00:45 > > To: Elwell, John; clue@ietf.org > > Subject: RE: [clue] Comment on requirements-03 - aspect ratio > > > > Hi John, > > Thanks for your comments. > > I agree with them. > > > > Aspect ratio is not part of ordering, and should be a separate > > requirement, not part of Reqmt 1. Reqmt 6 which says=20 > The solution MUST > > support means of enabling > > interoperability between telepresence=20 > endpoints where > > cameras are of different aspect ratios. > > Certainly includes supporting communicating=20 > information about aspect > > ratio, which is what 1c says. > > > > Also, 1d, on supporting multi-view, as described in use > > cases, could be > > pulled out of 1 and made a separate requirement as well. > > > > I propose making these changes. How is that? > > > > Regards, > > Allyn > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf > > Of > > > Elwell, John > > > Sent: Wednesday, June 15, 2011 9:30 AM > > > To: clue@ietf.org > > > Subject: [clue] Comment on requirements-03 - aspect ratio > > > > > > We have: > > > "REQMT-1: The solution MUST support a description=20 > of the spatial > > > arrangement of source video images sent in > > video streams > > > which enables a satisfactory=20 > reproduction at the > > receiver > > > of the original scene. This applies=20 > to each site in a > > > point to point or a multipoint meeting and > > refers to the > > > spatial ordering within a site, not=20 > to the ordering of > > > images between sites." > > > and below that: > > > "REQMT-1c: The solution MUST support a means to > > > communicate the aspect ratio." > > > Is this the aspect ratio of a particular camera? If=20 > so, what is the > > > relevance of this to REQMT-1, which is concerned=20 > with the spatial > > > ordering of video images? Also REQMT-6 addresses aspect > > ratios, so how > > > does REQMT-1c relate to REQMT-6? > > > > > > John > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > =09 >=20 >=20 > = From allyn@cisco.com Mon Jun 20 06:46:18 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A1F11E8094 for ; Mon, 20 Jun 2011 06:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.58 X-Spam-Level: X-Spam-Status: No, score=-10.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x73wJBNzyTRI for ; Mon, 20 Jun 2011 06:46:16 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5514E11E808B for ; Mon, 20 Jun 2011 06:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=6515; q=dns/txt; s=iport; t=1308577576; x=1309787176; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sxK6iIoUCCZKaD1kRZ9azAiobHxtk6FQnA8yOCnvjO8=; b=BB1KISPxuT/tNgzJJCUOQLfv4V1FcDSDsWKFFpuzLWQDNH0kUyDkQkK8 e60byp9M+cetcDmdRvRjHDIHuYCGA867UdbcK1QdGUYHZ3kokU4LWSG/f Ot/EFo/gevWCA1ID1Oq/WDQ9CBulSDNQT9ilJRX9Ky1MrBNju3A8JAzUb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAKBO/02Q/khM/2dsb2JhbABTl1KPC3eqD51ihioEhyCPJ4Q8hnw X-IronPort-AV: E=Sophos;i="4.65,394,1304294400"; d="scan'208";a="36070565" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 20 Jun 2011 13:46:12 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5KDkBkB012550; Mon, 20 Jun 2011 13:46:12 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 06:46:10 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 06:46:10 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1134@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Comment on requirements-03 - aspect ratio Thread-Index: AcwvMKY9CruP2ZOFRnWx+7q2GQfjQQAGH7CwAAHOI+A= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A5@xmb-sjc-221.amer.cisco.com> From: "Allyn Romanow (allyn)" To: "Elwell, John" , "Stephen Botzko" X-OriginalArrivalTime: 20 Jun 2011 13:46:10.0966 (UTC) FILETIME=[6A076360:01CC2F50] Cc: clue@ietf.org Subject: Re: [clue] Comment on requirements-03 - aspect ratio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:46:18 -0000 Yes, I believe it is covered by 6 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: Monday, June 20, 2011 5:56 AM To: Stephen Botzko Cc: Allyn Romanow (allyn); clue@ietf.org Subject: RE: [clue] Comment on requirements-03 - aspect ratio =20 > -----Original Message----- > From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 > Sent: 20 June 2011 10:59 > To: Elwell, John > Cc: Allyn Romanow (allyn); clue@ietf.org > Subject: Re: [clue] Comment on requirements-03 - aspect ratio >=20 > in-line >=20 > Stephen Botzko >=20 >=20 > On Mon, Jun 20, 2011 at 3:53 AM, Elwell, John=20 > wrote: >=20 >=20 > Allyn, > =09 > Removal of 1c is fine. > =09 > =09 >=20 > I think the proposal is to move it, not remove it altogether. [JRE] I thought the proposal was that the existing REQMT-6 already covers it, and hence 1c can just be deleted. John > =20 >=20 >=20 > Concerning 1d, I searched for multi-view in the rest of=20 > the document and in the use cases, but couldn't find it, so=20 > if we retain it in the form of a separate requirement, it=20 > would certainly need more explanation. > =09 > =09 >=20 > There was a use case put on the list about a month ago by=20 > Mark Gorzynski. I think it would be useful to add it to the=20 > use cases draft. > >>> > 1. Virtual Space Multipoint=20 >=20 > =20 >=20 > This use case describes a virtual space multipoint video=20 > meeting with good eye contact and spatial layout of=20 > participants. The use case was proposed very early in the=20 > development of video conferencing systems as described in=20 > 1983 by Allardyce and Randal=20 > (http://handle.dtic.mil/100.2/ADA127738 ). The use case is=20 > illustrated in figure 2-5 of their report. Today, the use=20 > case is implemented in multiple telepresence type video=20 > conferencing systems on the market. The term "virtual space"=20 > was used in their report. The main difference between the=20 > result obtained with modern systems and those from 1983 are=20 > larger display sizes. >=20 > =20 >=20 > Virtual space multipoint as defined here assumes endpoints=20 > with multiple cameras and displays. Usually there are the=20 > same number of cameras and displays at a given endpoint. A=20 > camera is positioned above each display. A key aspect of=20 > virtual space multipoint is the details of how the cameras=20 > are aimed. The cameras are each aimed on the same area of=20 > view of the participants at the site. Thus each camera takes=20 > a picture of the same set of people but from a different=20 > angle. Each endpoint sender in the virtual space multipoint=20 > meeting therefore offers a choice of video streams to remote=20 > receivers, each stream representing a different view point. =20 > For example a camera positioned above a display to a=20 > participant's left may take video pictures of the=20 > participant's left ear while at the same time, a camera=20 > positioned above a display to the participant's right may=20 > take video pictures of the participant's right ear.=20 >=20 > =20 >=20 > Since a sending endpoint has a camera associated with each=20 > display, an association is made between the receiving stream=20 > output on a particular display and the corresponding sending=20 > stream from the camera associated with that display. These=20 > associations are repeated for each display/camera pair in a=20 > meeting. The result of this system is a horizontal=20 > arrangement of video images from remote sites, one per=20 > display. The image from each display is paired with the=20 > camera output from the camera above that display resulting in=20 > excellent eye contact. > >>> > =20 >=20 > John > =09 >=20 > > -----Original Message----- > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > Sent: 20 June 2011 00:45 > > To: Elwell, John; clue@ietf.org > > Subject: RE: [clue] Comment on requirements-03 - aspect ratio > > > > Hi John, > > Thanks for your comments. > > I agree with them. > > > > Aspect ratio is not part of ordering, and should be a separate > > requirement, not part of Reqmt 1. Reqmt 6 which says=20 > The solution MUST > > support means of enabling > > interoperability between telepresence=20 > endpoints where > > cameras are of different aspect ratios. > > Certainly includes supporting communicating=20 > information about aspect > > ratio, which is what 1c says. > > > > Also, 1d, on supporting multi-view, as described in use > > cases, could be > > pulled out of 1 and made a separate requirement as well. > > > > I propose making these changes. How is that? > > > > Regards, > > Allyn > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf > > Of > > > Elwell, John > > > Sent: Wednesday, June 15, 2011 9:30 AM > > > To: clue@ietf.org > > > Subject: [clue] Comment on requirements-03 - aspect ratio > > > > > > We have: > > > "REQMT-1: The solution MUST support a description=20 > of the spatial > > > arrangement of source video images sent in > > video streams > > > which enables a satisfactory=20 > reproduction at the > > receiver > > > of the original scene. This applies=20 > to each site in a > > > point to point or a multipoint meeting and > > refers to the > > > spatial ordering within a site, not=20 > to the ordering of > > > images between sites." > > > and below that: > > > "REQMT-1c: The solution MUST support a means to > > > communicate the aspect ratio." > > > Is this the aspect ratio of a particular camera? If=20 > so, what is the > > > relevance of this to REQMT-1, which is concerned=20 > with the spatial > > > ordering of video images? Also REQMT-6 addresses aspect > > ratios, so how > > > does REQMT-1c relate to REQMT-6? > > > > > > John > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > =09 >=20 >=20 >=20 From stephen.botzko@gmail.com Mon Jun 20 07:11:01 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEA411E80C3 for ; Mon, 20 Jun 2011 07:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6qAzEOhwmsv for ; Mon, 20 Jun 2011 07:11:00 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEB811E80BE for ; Mon, 20 Jun 2011 07:11:00 -0700 (PDT) Received: by vxi40 with SMTP id 40so854832vxi.31 for ; Mon, 20 Jun 2011 07:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=S0FKSwe1nFbfGI3dMJRHlglqjMHTT/PJD0ZDuchmtfo=; b=ceDOqrZpX6YO+3ekcxLgJYsEiwJX8bNhUwem//THe4RDYRwFTsW1vd6CPFDIT3GIvg yrp/AkSIVIGMS0MlLYeRjfMnN9ndQ1JnRLiTG+WkGb7mgQDKGjvgulcLx0cRmOXI8A+6 o0QAPkatqEHsejmcs3GHLbKCuVYecxFq87pVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=l2yFTmizFM/CXl9ipESLhbNVjfy/WGgcQ4jfkWA4y4rCuphxhAJTLGPhf9As4EclaC ZyJm2NkOK7B+mCLhwsP3aZv4unZFCI7GqM3dRGVXOMKolpYL+84Tu1yDRAjntxREmsJG B4uTWh1mXP5z3pQe7Pn5AlGuyZtVCai6pAMkw= MIME-Version: 1.0 Received: by 10.52.160.68 with SMTP id xi4mr4289979vdb.106.1308579059807; Mon, 20 Jun 2011 07:10:59 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Mon, 20 Jun 2011 07:10:59 -0700 (PDT) In-Reply-To: <92DF9533227FC14F946C7321074B8C9E71B6C4@XMB-AMS-214.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A5@xmb-sjc-221.amer.cisco.com> <92DF9533227FC14F946C7321074B8C9E71B6C4@XMB-AMS-214.cisco.com> Date: Mon, 20 Jun 2011 10:10:59 -0400 Message-ID: From: Stephen Botzko To: "Espen Berger (espeberg)" Content-Type: multipart/alternative; boundary=bcaec53f977905380b04a6254ee1 Cc: clue@ietf.org Subject: Re: [clue] Comment on requirements-03 - aspect ratio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 14:11:01 -0000 --bcaec53f977905380b04a6254ee1 Content-Type: text/plain; charset=ISO-8859-1 Aspect Ratio creates some unique issues with multiple displays, especially if the aspect ratio of the received pictures do not match the physical displays. This is shown in the use cases. So the H.264 decoder rules are not sufficient to get the behavior we want here. Similarly, the solution needs to enable display of far-end participants at the proper apparent size. Again, H.264 decoder rules do not cover this. Requirements 6-8 were intended to fill the gap. However, we seem to have lost the "actual size" display (called "full-sized display" in the use cases draft) in the current formulation. This needs to be fixed, as the ability to match the visual scale of the incoming video is an important aspect of the solution. Regards, Stephen Botzko On Mon, Jun 20, 2011 at 8:04 AM, Espen Berger (espeberg) wrote: > I did not fully understand the reason for REQ-6, REQ-7 and REQ-8. These > requirements are already covered in current decode rules for H.264 > video. A decoder: > - should decode any aspect-ratio below the frame-size it can receive > - should decode any resolution below the max frame size > - The renderer is free to chose display size > > In addition to frame-size and aspects-ratio there are a large number of > other parameters that could be negotiated in SDP and I do not think we > should duplicate those in the CLUE-requirement documentation. > > Should we drop REQ 6, 7, 8 and instead refer to SDP mechanisms for > negotiating video and audio parameters? > > Cheers > > -Espen > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Allyn Romanow (allyn) > Sent: 20. juni 2011 01:45 > To: Elwell, John; clue@ietf.org > Subject: Re: [clue] Comment on requirements-03 - aspect ratio > > Hi John, > Thanks for your comments. > I agree with them. > > Aspect ratio is not part of ordering, and should be a separate > requirement, not part of Reqmt 1. Reqmt 6 which says The solution MUST > support means of enabling > interoperability between telepresence endpoints where > cameras are of different aspect ratios. > Certainly includes supporting communicating information about aspect > ratio, which is what 1c says. > > Also, 1d, on supporting multi-view, as described in use cases, could be > pulled out of 1 and made a separate requirement as well. > > I propose making these changes. How is that? > > Regards, > Allyn > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Elwell, John > > Sent: Wednesday, June 15, 2011 9:30 AM > > To: clue@ietf.org > > Subject: [clue] Comment on requirements-03 - aspect ratio > > > > We have: > > "REQMT-1: The solution MUST support a description of the spatial > > arrangement of source video images sent in video streams > > which enables a satisfactory reproduction at the > receiver > > of the original scene. This applies to each site in a > > point to point or a multipoint meeting and refers to the > > spatial ordering within a site, not to the ordering of > > images between sites." > > and below that: > > "REQMT-1c: The solution MUST support a means to > > communicate the aspect ratio." > > Is this the aspect ratio of a particular camera? If so, what is the > > relevance of this to REQMT-1, which is concerned with the spatial > > ordering of video images? Also REQMT-6 addresses aspect ratios, so how > > does REQMT-1c relate to REQMT-6? > > > > John > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec53f977905380b04a6254ee1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aspect Ratio creates some unique issues with multiple displays, especially = if the aspect ratio of the received pictures do not match the physical disp= lays.=A0 This is shown in the use cases.=A0 So the H.264 decoder rules are = not sufficient to get the behavior we want here.

Similarly, the solution needs to enable display of far-end participants= at the proper apparent size.=A0 Again, H.264 decoder rules do not cover th= is.=A0 Requirements 6-8=A0 were intended to fill the gap.=A0 However, we se= em to have lost the "actual size" display (called "full-size= d display" in the use cases draft) in the current formulation.=A0 This= needs to be fixed, as the ability to match the visual scale of the incomin= g video is an important aspect of the solution.

Regards,
Stephen Botzko




On Mon, Jun 20, 2011 at 8:04 AM, Espen Berger (espeberg) <espeberg@cisco.com> wrote:
I did not fully understand the reason for R= EQ-6, REQ-7 and REQ-8. These
requirements are already covered in current decode rules for H.264
video. A decoder:
=A0- should decode any aspect-ratio below the frame-size it can receive
=A0- should decode any resolution below the max frame size
=A0- The renderer is free to chose display size

In addition to frame-size and aspects-ratio there are a large number of
other parameters that could be negotiated in SDP and I do not think we
should duplicate those in the CLUE-requirement documentation.

Should we drop REQ 6, 7, 8 and instead refer to SDP mechanisms for
negotiating video and audio parameters?

Cheers

-Espen

-----Original Message-----
From: clue-bounces@ietf.org [m= ailto:clue-bounces@ietf.org] O= n Behalf Of
Allyn Romanow (allyn)
Sent: 20. juni 2011 01:45
To: Elwell, John; clue@i= etf.org
Subject: Re: [clue] Comment on requirements-03 - aspect ratio

Hi John,
Thanks for your comments.
I agree with them.

Aspect ratio is not part of ordering, and should be a separate
requirement, not part of Reqmt 1. Reqmt 6 which says The solution MUST
support means of enabling
=A0 =A0 =A0 =A0 =A0 =A0 =A0interoperability between telepresence endpoints= where
=A0 =A0 =A0 =A0 =A0 =A0 =A0cameras are of different aspect ratios.
Certainly includes supporting communicating information about aspect
ratio, which is what 1c says.

Also, 1d, on supporting multi-view, as described in use cases, could be
pulled out of 1 and made a separate requirement as well.

I propose making these changes. How is that?

Regards,
Allyn

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
Of
> Elwell, John
> Sent: Wednesday, June 15, 2011 9:30 AM
> To: clue@ietf.org
> Subject: [clue] Comment on requirements-03 - aspect ratio
>
> We have:
> "REQMT-1: =A0 The solution MUST support a description of the spat= ial
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 arrangement of source video images sent in= video streams
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 which enables a satisfactory reproduction = at the
receiver
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 of the original scene. =A0This applies to = each site in a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 point to point or a multipoint meeting and= refers to the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 spatial ordering within a site, not to the= ordering of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 images between sites."
> and below that:
> "REQMT-1c: =A0The solution MUST support a means to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0communicate the asp= ect ratio."
> Is this the aspect ratio of a particular camera? If so, what is the > relevance of this to REQMT-1, which is concerned with the spatial
> ordering of video images? Also REQMT-6 addresses aspect ratios, so how=
> does REQMT-1c relate to REQMT-6?
>
> John
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--bcaec53f977905380b04a6254ee1-- From stephen.botzko@gmail.com Mon Jun 20 07:24:50 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9735F21F84B4 for ; Mon, 20 Jun 2011 07:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrD7kveR-1Ep for ; Mon, 20 Jun 2011 07:24:50 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E36FB21F84B1 for ; Mon, 20 Jun 2011 07:24:49 -0700 (PDT) Received: by vws12 with SMTP id 12so658022vws.31 for ; Mon, 20 Jun 2011 07:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Cg1KQw8AcVgbBfQ5sHUnZZh4QaIaebUAjWX5Qce3tYw=; b=a1sFrtaOhtfbD8o2SkqvMrfBECOJ2E/UWA/i4Au39gQT8MjNXyPKgajGifPMBJzU8/ koNiaA6hmHcv8r++78iX3OHnxdktvHb11lhwizAFVLQXoAo7uA5Ork29hDhCaPUkhWGA SjUv8UnDz9brPFK1Y45YS4hPKafg9vlbOKsbo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xAyXWiMTGa33smZejXuszAKVCl8wXPgg3Kt1Lfb4ZQZfQFhFJK8Y24iD1mTtYkLcwX +f1fPKCDMYlg2q2nIOcmwndk3sKRuMwXPgpgF/YzNlihKGty1EQLDzgwYvFB/yaJc5k1 Qo5vGvjinMsfkqmoANJ4nIcZ30/lncDNe0c7c= MIME-Version: 1.0 Received: by 10.52.66.206 with SMTP id h14mr182500vdt.40.1308579889155; Mon, 20 Jun 2011 07:24:49 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Mon, 20 Jun 2011 07:24:49 -0700 (PDT) In-Reply-To: <005101cc2f40$5e997730$1bcc6590$%roni@huawei.com> References: <005101cc2f40$5e997730$1bcc6590$%roni@huawei.com> Date: Mon, 20 Jun 2011 10:24:49 -0400 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/alternative; boundary=20cf307cfd82740e0a04a6257f8d Cc: clue@ietf.org Subject: Re: [clue] comments on Requirement draft X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 14:24:50 -0000 --20cf307cfd82740e0a04a6257f8d Content-Type: text/plain; charset=ISO-8859-1 Hi Roni Requirement 4 covers the case where the number of cameras or displays are mismatched. However, with legacy devices (and perhaps CLUEd mobile devices), it is possible that there is no video at all. It wasn't clear to us if requirement 4 captured that case or not, so requirement 5 was added. Regards, Stephen Botzko On Mon, Jun 20, 2011 at 7:51 AM, Roni Even wrote: > Hi,**** > > I think that the draft should include a reference to the use case draft > since it mention it in the requirements section. Maybe the introduction > should mention that the use cases draft is used for the requirements.**** > > ** ** > > I am not sure what is the meaning or use case for requirement 5.**** > > ** ** > > Regards**** > > Roni**** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --20cf307cfd82740e0a04a6257f8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roni

Requirement 4 covers the case where the number of cameras or= displays are mismatched.=A0 However, with legacy devices (and perhaps CLUE= d mobile devices), it is possible that there is no video at all.=A0 It wasn= 't clear to us if requirement 4 captured that case or not, so requireme= nt 5 was added.=A0

Regards,
Stephen Botzko

On Mon, Ju= n 20, 2011 at 7:51 AM, Roni Even <Even.roni@huawei.com> wrote:

Hi,

I think that the draft shou= ld include a reference to the use case draft since it mention it in the req= uirements section. Maybe the introduction should mention that the use cases= draft is used for the requirements.

=A0

I am not= sure what is the meaning or use case for requirement 5.

<= p class=3D"MsoNormal">=A0

Regards

Roni


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


--20cf307cfd82740e0a04a6257f8d-- From stewe@stewe.org Mon Jun 20 07:48:23 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65CE11E808B for ; Mon, 20 Jun 2011 07:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8qn78wDCuWz for ; Mon, 20 Jun 2011 07:48:21 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9502C11E8085 for ; Mon, 20 Jun 2011 07:48:20 -0700 (PDT) Received: from [172.16.7.218] (unverified [160.79.219.114]) by stewe.org (SurgeMail 3.9e) with ESMTP id 3879-1743317 for ; Mon, 20 Jun 2011 16:48:19 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Mon, 20 Jun 2011 07:48:14 -0700 From: Stephan Wenger To: "clue@ietf.org" Message-ID: Thread-Topic: Stephan's comments on Requirements-03 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3391400898_1226580" X-Originating-IP: 160.79.219.114 X-Authenticated-User: stewe@stewe.org Subject: [clue] Stephan's comments on Requirements-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 14:48:23 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3391400898_1226580 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, Due to other commitments, I have not followed the mailing list in detail. Some of my comments may be duplicates; apologies in advance for that. Overall, this draft is better than the previous ones. However, there are still a number of issues that I would like to raise. Req.1 "preservation order"??? What is this? Needs to be defined=8A Req.1c "aspect ratio" -> "picture aspect ratio", to distinguish from pixel aspect ratio (both terms are common in video compression) Req.1d "as described in the use cases": I don't like this type of cross reference, but have not had time to come up with a good solution. Req.2a "order of audio" -> "spatial order of audio" Req.2b MUST for the 3.0? Suggest "SHOULD". Also suggest "SHOULD 5.1", as 5.1, while not common in today's systems, has appeared on at least one Telepresence roadmap I'm aware of. Req.2c Personally, I don't care about binaural support either way; however, MUST NOT seems wrong here. I think requirements should be expressed positively, with the appropriate level of mandation. So why not "MAY" support binaural? Or "SHOULD"? Req 3a fine with me as written. However, have you thought about the implications when considering centralized mixing? In order to fulfill the use cases behind the requirements, the mixer needs to be aware of both capture info and rendering info=8A Not an issue for me, but there may be IPR implications, and I would prefer to see a "SHOULD" level of mandation for the centralized audio mixing use case (only). Req. 3b this requirement needs to be rephrased. We should not put requirements on the renderer. "The solution MUST enable individual audio streams that have no camera position associated with"? Or something to thi= s extent? Req 4. Convert edt. note into regular text; it contains helpful info. Req. 5 fine Req 6 aspect ratio -> picture aspect ratio. Or do you also want to worry about pixel aspect ratios? Now that would be fun for the implementers :-) Req 7 fine, but since we should not specify rendering, this requirement is = a No-Op, right? Req 8 fine Req 9 fine Req 10 needs IMO to be more general. "different bit rates" -> "endpoints with different connectivity, i.e. in terms of bitrate, packet loss rate, an= d other connectivity aspects" Req 11 fine. Perhaps add a note indicating that, obviously, dumb endpoints cannot take advantage of solution features unless an MCU or gateway is in play which deals with those solution features. Req 12 fine Req 13 Is anywhere here advocating switching??? Can we please rid ourselve= s from concepts 10+ years out of date? Req 14 I don't understand this requirement. Needs elaboration and/or an example Req 15 What is "audio activity"? And, suggest moving this requirement up t= o where the other audio requirements are Req 16, third bullet, language is garbled. Suggest to spell out those assorted requirements. Req 17 fine Stephan =20 --B_3391400898_1226580 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi,
Due to other c= ommitments, I have not followed the mailing list in detail.  Some of my= comments may be duplicates; apologies in advance for that.
Overal= l, this draft is better than the previous ones.  However, there are sti= ll a number of issues that I would like to raise.

R= eq.1 "preservation order"???  What is this?  Needs to be defined&#= 8230;
Req.1c "aspect ratio" -> "picture aspect ratio", to disti= nguish from pixel aspect ratio (both terms are common in video compression)<= /div>
Req.1d "as described in the use cases": I don't like this type of = cross reference, but have not had time to come up with a good solution.

Req.2a "order of audio" -> "spatial order of audio"<= /div>
Req.2b MUST for the 3.0?  Suggest "SHOULD".  Also sugges= t "SHOULD 5.1", as 5.1, while not common in today's systems, has appeared on= at least one Telepresence roadmap I'm aware of.
Req.2c Personally= , I don't care about binaural support either way; however, MUST NOT seems wr= ong here.  I think requirements should be expressed positively, with th= e appropriate level of mandation.  So why not "MAY" support binaural? &= nbsp;Or "SHOULD"?

Req 3a fine with me as written. &= nbsp;However, have you thought about the implications when considering centr= alized mixing?  In order to fulfill the use cases behind the requiremen= ts, the mixer needs to be aware of both capture info and rendering info̷= 0;  Not an issue for me, but there may be IPR implications, and I would= prefer to see a "SHOULD" level of mandation for the centralized audio mixin= g use case (only).
Req. 3b this requirement needs to be rephrased.=  We should not put requirements on the renderer.  "The solution M= UST enable individual audio streams that have no camera position associated = with"?  Or something to this extent?

Req 4. &n= bsp;Convert edt. note into regular text; it contains helpful info.

Req. 5 fine

Req 6 aspect ratio ->= ; picture aspect ratio.  Or do you also want to worry about pixel aspec= t ratios?  Now that would be fun for the implementers :-)
Req 7 fine, but since we should not specify rendering, this requ= irement is a No-Op, right?

Req 8 fine
Req 9 fine

Req 10 needs IMO to be more = general.  "different bit rates"  -> "endpoints with different c= onnectivity, i.e. in terms of bitrate, packet loss rate, and other connectiv= ity aspects"  

Req 11 fine.  Perhaps add = a note indicating that, obviously, dumb endpoints cannot take advantage of s= olution features unless an MCU or gateway is in play which deals with those = solution features.

Req 12 fine

=
Req 13 Is anywhere here advocating switching???  Can we please rid= ourselves from concepts 10+ years out of date?

Req= 14  I don't understand this requirement.  Needs elaboration and/o= r an example

Req 15 What is "audio activity"?  = ;And, suggest moving this requirement up to where the other audio requiremen= ts are

Req 16, third bullet, language is garbled. &= nbsp;Suggest to spell out those assorted requirements.

<= div>Req 17 fine

Stephan






 


= --B_3391400898_1226580-- From Even.roni@huawei.com Mon Jun 20 08:09:21 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CCB21F8569 for ; Mon, 20 Jun 2011 08:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.546 X-Spam-Level: X-Spam-Status: No, score=-104.546 tagged_above=-999 required=5 tests=[AWL=2.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zn+nPScBgfW for ; Mon, 20 Jun 2011 08:09:21 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9144021F8580 for ; Mon, 20 Jun 2011 08:09:20 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN300MJRGRIFV@szxga04-in.huawei.com> for clue@ietf.org; Mon, 20 Jun 2011 23:09:19 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN3004WSGRI9S@szxga04-in.huawei.com> for clue@ietf.org; Mon, 20 Jun 2011 23:09:18 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-35-190.red.bezeqint.net [79.176.35.190]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN300MXMGRALI@szxml11-in.huawei.com>; Mon, 20 Jun 2011 23:09:18 +0800 (CST) Date: Mon, 20 Jun 2011 18:07:16 +0300 From: Roni Even In-reply-to: To: 'Stephen Botzko' Message-id: <008001cc2f5b$c3ea3fa0$4bbebee0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_PoF9Amu19LBWNPWvTCDJMQ)" Content-language: en-us Thread-index: AcwvVdPbH4kSVj2RT1OFjLVLyrLP2QABX30w References: <005101cc2f40$5e997730$1bcc6590$%roni@huawei.com> Cc: clue@ietf.org Subject: Re: [clue] comments on Requirement draft X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:09:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_PoF9Amu19LBWNPWvTCDJMQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Steve, So why not say audio only, the current text is unclear "The solution MUST support interoperability between endpoints where the number of cameras and/or displays are zero." Maybe say like IP phones Roni From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Monday, June 20, 2011 5:25 PM To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] comments on Requirement draft Hi Roni Requirement 4 covers the case where the number of cameras or displays are mismatched. However, with legacy devices (and perhaps CLUEd mobile devices), it is possible that there is no video at all. It wasn't clear to us if requirement 4 captured that case or not, so requirement 5 was added. Regards, Stephen Botzko On Mon, Jun 20, 2011 at 7:51 AM, Roni Even wrote: Hi, I think that the draft should include a reference to the use case draft since it mention it in the requirements section. Maybe the introduction should mention that the use cases draft is used for the requirements. I am not sure what is the meaning or use case for requirement 5. Regards Roni _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --Boundary_(ID_PoF9Amu19LBWNPWvTCDJMQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Steve,

So why not say audio only, the current text is unclear

 

"The solution MUST support interoperability between endpoints where the number of cameras and/or displays are    zero."

 

Maybe say like IP phone s 

Roni

 

From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: Monday, June 20, 2011 5:25 PM
To: Roni Even
Cc: clue@ietf.org
Subject: Re: [clue] comments on Requirement draft

 

Hi Roni

Requirement 4 covers the case where the number of cameras or displays are mismatched.  However, with legacy devices (and perhaps CLUEd mobile devices), it is possible that there is no video at all.  It wasn't clear to us if requirement 4 captured that case or not, so requirement 5 was added. 

Regards,
Stephen Botzko

On Mon, Jun 20, 2011 at 7:51 AM, Roni Even <Even.roni@huawei.com> wrote:

Hi,

I think that the draft should include a reference to the use case draft since it mention it in the requirements section. Maybe the introduction should mention that the use cases draft is used for the requirements.

 

I am not sure what is the meaning or use case for requirement 5.

 

Regards

Roni


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

 

--Boundary_(ID_PoF9Amu19LBWNPWvTCDJMQ)-- From allyn@cisco.com Mon Jun 20 12:07:07 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AC711E80A5 for ; Mon, 20 Jun 2011 12:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.582 X-Spam-Level: X-Spam-Status: No, score=-10.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OWMwkM3d0Fv for ; Mon, 20 Jun 2011 12:07:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id EFD1B11E808E for ; Mon, 20 Jun 2011 12:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=7182; q=dns/txt; s=iport; t=1308596825; x=1309806425; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BAJk2sT75HOxbM8Lw/0i88xC9HC2kWEpqUrwtW+WJMo=; b=Tm0si7xFy+fl1wySMDixwCdDJinIJJJ19QCxk2QSZ8AnKj1yrW5aJ02i eDlYgrLs0EpG7rRMbId9r71wKMg0lNf2o5O9Q6WK+hdXmdFfRY/k0dx/N moBDNsyWTI2vcDM8iCgV1vEulHPMPDz8IDer/rnuR9Mywo++ItWZEf3KI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAABOa/02rRDoJ/2dsb2JhbABTl1ePC3eqX54KhioEhyCPJ4s4 X-IronPort-AV: E=Sophos;i="4.65,395,1304294400"; d="scan'208";a="717639981" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 20 Jun 2011 19:06:59 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5KJ6xOQ021702; Mon, 20 Jun 2011 19:06:59 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 12:06:59 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 12:06:55 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1308@xmb-sjc-221.amer.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB5336406@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwqno7BLwl3j+PMSjaOF3ZfYi/FNwBOY9JAAMyJxDAAHFdzUA== References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A3@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB5336406@ESESSCMS0356.eemea.ericsson.se> From: "Allyn Romanow (allyn)" To: "Christer Holmberg" , "Mary Barnes" X-OriginalArrivalTime: 20 Jun 2011 19:06:59.0377 (UTC) FILETIME=[3AF9D210:01CC2F7D] Cc: "Botzko, Stephen" , clue@ietf.org, "Bill Mauchly \(bmauchly\)" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 19:07:07 -0000 Hi Christer, Still trying to get clarification- I read your description of various types of rendering. Still trying to understand what you want from CLUE- If we have a tag that says "binaural" or stereo, sub binaural, are we done? Or do you want CLUE to describe how to do some kind of rendering? To say something more about specific rendering functions? Or something additional altogether? Thanks much- =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, June 19, 2011 10:29 PM > To: Allyn Romanow (allyn); Mary Barnes > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on centralized media mixing >=20 >=20 > Hi Allyn, >=20 > I appologise that it took some time to reply. >=20 > We've been working on some definition/example text (I sent it to the > list just a few minutes ago), which I hope will clarify some of the > questions that have been asked. >=20 > >Also, what kind of support are you asking for binaural? I believe it's > often considered as a subset of stereo. What are you asking for? A > simple tag that says "binaural", or the specification > >of a rendering system for binaural? Precisely what are asking for? >=20 > From CLUE, we are only asking for a general mechanism to request and > indicate different rendering types (see definition in other e-mail). >=20 > An example of such rendering type is binaural, BUT we are *NOT* asking > CLUE to define any binaural specific SDP attributes etc. If such are > needed, we agree that it needs to be done as a separate task. >=20 > Before I try to answer your other questions, please take a look at the > definition/example e-mail, which I hope will clarify what we mean by > rendering and rendering type. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Hi Christer - >=20 > In spirit I am enthusiastic about what you are proposing (meaning > good quality mobile participation). I'm not clear on how the spirit > becomes instantiated in our protocol, so I have some questions below J >=20 > Thanks, >=20 > Allyn >=20 >=20 >=20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Tuesday, June 14, 2011 7:23 AM > To: clue@ietf.org > Subject: [clue] Requirement on centralized media mixing >=20 >=20 >=20 >=20 >=20 > Hi, >=20 >=20 >=20 > During the last interim meeting (May 12th) we discussed a > requirement proposal >=20 > stating that an endpoint must be able to request central audio > rendering >=20 > of different predefined formats, including 3D binaural rendering. >=20 > (Link to proposal: http://www.ietf.org/mail- > archive/web/clue/current/msg00179.html) >=20 >=20 >=20 > The proposal was well received, with the reservation that it > should not be mandatory >=20 > for the solution to implement centralized 3D binaural rendering, > i.e.an endpoint should >=20 > be able to request 3D binaural rendering, but had no guaranty > that such rendering was >=20 > supported by the system. >=20 >=20 >=20 > It was decided to look how such requirement could look like. >=20 >=20 >=20 > When I look the -03 version of the req draft, Requirement 2c > states: >=20 >=20 >=20 > "The solution MUST NOT preclude the use of binaural audio." >=20 >=20 >=20 > I think that requirement is unclear, and it doesn't really give > any guidance to our work. >=20 >=20 >=20 > Due to that, and also due to the fact that rather than talking > about specific rendering types, >=20 > I would like to propose more general requirement text on the > negotiation of the media mixing type, >=20 > and the usage of centralized media mixing in the first place. >=20 >=20 >=20 > The mechanism would be extendable, so new types can be added in > future. >=20 >=20 >=20 > So, the proposed requirements are: >=20 >=20 >=20 > REQ-x: It MUST be possible to negotiate the usage of > centralized media mixing. System support of centralized media mixing is > optional. >=20 >=20 >=20 > REQ-y: When centralized media mixing is used, it MUST be > possible to negotiate the type of media rendering provided for each > media stream received by a client. >=20 > --- >=20 > [ar] I have a few questions/comments: >=20 > 1. The term "negotiate" troubles me as I think it means a > particular form of communication that dictates the solution. What is > being asked for is the receiver to know that it is receiving > "centralized media mixing". This may not be the end product of a > negotiation. The same is true of the use of the term negotiate in the > second requirement. What is needed is a mechanism by which the receiver > may know what type of "media rendering" is being received. >=20 > So, I'd rather offer, The solution must support a means for > identifying a stream which is "centralized media mixing". >=20 > And, When "centralized media mixing" is used, the solution must > support a means for identifying... >=20 >=20 >=20 > 2. Also, I'm not too sure what "media rendering", the > phrase in the second reqmt, represents- SDP and RTP recognize audio > channels and recognize codecs. Is this what is referred to as "media > rendering"? Or is it something different? What very specifically? >=20 >=20 >=20 > 3. After reading more of the discussion, I realize that I > don't fully understand what is meant in the first reqmt by "centralized > media mixing" or "rendering", which term is used in another email. I > had thought you meant the usual audio mixing such as discussed in RFC > 5117.( I figured it was an understood part of the topology so didn't > need to be called out in particular. But I don't mind calling it out.) > In any case, now I'm not sure what you mean, maybe it is something > other than typical MCU mixing behavior as described in RFC 5117? >=20 >=20 >=20 > 4. As for the discussion of binaural.. here is what it > seems like to me.. AVP, RFC 3551 specifies the number of audio > channels, what they refer to, and types of codecs. Binaural is > neither. As you say, Christer, it's a type of stereo channel. Steve > feels that "binaural" must be recognized in SDP, which of course, it is > not currently. >=20 >=20 >=20 > I'm not entirely sure what needs to be specified about binaural, > given that it is neither channel -type nor codec-type. What needs to be > standardized? This question is probably more for Steve, or both of you. > If the receiving device knows it's getting binaural stereo, then it can > run some algorithms to improve quality and if it isn't binaural, it > won't run those algs., or something analogous? If that is the case, I > don't see what needs to be standardized that isn't already > standardized... But I'm eager to learn. >=20 >=20 >=20 > Thanks- >=20 > Allyn >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer >=20 >=20 >=20 >=20 From christer.holmberg@ericsson.com Mon Jun 20 12:22:47 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1555811E80FC for ; Mon, 20 Jun 2011 12:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo5kGeJI3nai for ; Mon, 20 Jun 2011 12:22:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9E68911E81F6 for ; Mon, 20 Jun 2011 12:22:45 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-05-4dff9e037cbb Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 13.BF.20773.30E9FFD4; Mon, 20 Jun 2011 21:22:44 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 20 Jun 2011 21:22:43 +0200 From: Christer Holmberg To: "Allyn Romanow (allyn)" , Mary Barnes Date: Mon, 20 Jun 2011 21:22:43 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwqno7BLwl3j+PMSjaOF3ZfYi/FNwBOY9JAAMyJxDAAHFdzUAAAtMt+ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB53FF298@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A3@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB5336406@ESESSCMS0356.eemea.ericsson.se>, <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1308@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1308@xmb-sjc-221.amer.cisco.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 X-Brightmail-Tracker: AAAAAA== Cc: "Botzko, Stephen" , "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 19:22:47 -0000 Hi Allyn, >Still trying to get clarification- > >I read your description of various types of rendering. >Still trying to understand what you want from CLUE- >If we have a tag that says "binaural" or stereo, sub binaural, are we >done? Of course we could have a binaural specific SDP attribute, e.g. a=3Dbinaura= l. But, again, what we are proposing is a general mechanism, that could look s= omething like: a=3Drendering-type =3D could then e.g. be "binaural", but it could also be something else = (we showed a few example in the e-mail). >Or do you want CLUE to describe how to do some kind of rendering? To say >something more about specific rendering functions? No, CLUE doesn't need to say anything about that.=20 There would of course need to be a rendering description associated with ea= ch rendering type value, but CLUE wouldn't define those. The idea is that an IANA registry is created, where people can register the= ir rendering type values. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, June 19, 2011 10:29 PM > To: Allyn Romanow (allyn); Mary Barnes > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on centralized media mixing > > > Hi Allyn, > > I appologise that it took some time to reply. > > We've been working on some definition/example text (I sent it to the > list just a few minutes ago), which I hope will clarify some of the > questions that have been asked. > > >Also, what kind of support are you asking for binaural? I believe it's > often considered as a subset of stereo. What are you asking for? A > simple tag that says "binaural", or the specification > >of a rendering system for binaural? Precisely what are asking for? > > From CLUE, we are only asking for a general mechanism to request and > indicate different rendering types (see definition in other e-mail). > > An example of such rendering type is binaural, BUT we are *NOT* asking > CLUE to define any binaural specific SDP attributes etc. If such are > needed, we agree that it needs to be done as a separate task. > > Before I try to answer your other questions, please take a look at the > definition/example e-mail, which I hope will clarify what we mean by > rendering and rendering type. > > Regards, > > Christer > > > > > > > > > > > > > > > Hi Christer - > > In spirit I am enthusiastic about what you are proposing (meaning > good quality mobile participation). I'm not clear on how the spirit > becomes instantiated in our protocol, so I have some questions below J > > Thanks, > > Allyn > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Tuesday, June 14, 2011 7:23 AM > To: clue@ietf.org > Subject: [clue] Requirement on centralized media mixing > > > > > > Hi, > > > > During the last interim meeting (May 12th) we discussed a > requirement proposal > > stating that an endpoint must be able to request central audio > rendering > > of different predefined formats, including 3D binaural rendering. > > (Link to proposal: http://www.ietf.org/mail- > archive/web/clue/current/msg00179.html) > > > > The proposal was well received, with the reservation that it > should not be mandatory > > for the solution to implement centralized 3D binaural rendering, > i.e.an endpoint should > > be able to request 3D binaural rendering, but had no guaranty > that such rendering was > > supported by the system. > > > > It was decided to look how such requirement could look like. > > > > When I look the -03 version of the req draft, Requirement 2c > states: > > > > "The solution MUST NOT preclude the use of binaural audio." > > > > I think that requirement is unclear, and it doesn't really give > any guidance to our work. > > > > Due to that, and also due to the fact that rather than talking > about specific rendering types, > > I would like to propose more general requirement text on the > negotiation of the media mixing type, > > and the usage of centralized media mixing in the first place. > > > > The mechanism would be extendable, so new types can be added in > future. > > > > So, the proposed requirements are: > > > > REQ-x: It MUST be possible to negotiate the usage of > centralized media mixing. System support of centralized media mixing is > optional. > > > > REQ-y: When centralized media mixing is used, it MUST be > possible to negotiate the type of media rendering provided for each > media stream received by a client. > > --- > > [ar] I have a few questions/comments: > > 1. The term "negotiate" troubles me as I think it means a > particular form of communication that dictates the solution. What is > being asked for is the receiver to know that it is receiving > "centralized media mixing". This may not be the end product of a > negotiation. The same is true of the use of the term negotiate in the > second requirement. What is needed is a mechanism by which the receiver > may know what type of "media rendering" is being received. > > So, I'd rather offer, The solution must support a means for > identifying a stream which is "centralized media mixing". > > And, When "centralized media mixing" is used, the solution must > support a means for identifying... > > > > 2. Also, I'm not too sure what "media rendering", the > phrase in the second reqmt, represents- SDP and RTP recognize audio > channels and recognize codecs. Is this what is referred to as "media > rendering"? Or is it something different? What very specifically? > > > > 3. After reading more of the discussion, I realize that I > don't fully understand what is meant in the first reqmt by "centralized > media mixing" or "rendering", which term is used in another email. I > had thought you meant the usual audio mixing such as discussed in RFC > 5117.( I figured it was an understood part of the topology so didn't > need to be called out in particular. But I don't mind calling it out.) > In any case, now I'm not sure what you mean, maybe it is something > other than typical MCU mixing behavior as described in RFC 5117? > > > > 4. As for the discussion of binaural.. here is what it > seems like to me.. AVP, RFC 3551 specifies the number of audio > channels, what they refer to, and types of codecs. Binaural is > neither. As you say, Christer, it's a type of stereo channel. Steve > feels that "binaural" must be recognized in SDP, which of course, it is > not currently. > > > > I'm not entirely sure what needs to be specified about binaural, > given that it is neither channel -type nor codec-type. What needs to be > standardized? This question is probably more for Steve, or both of you. > If the receiving device knows it's getting binaural stereo, then it can > run some algorithms to improve quality and if it isn't binaural, it > won't run those algs., or something analogous? If that is the case, I > don't see what needs to be standardized that isn't already > standardized... But I'm eager to learn. > > > > Thanks- > > Allyn > > > > Regards, > > > > Christer > > > >= From pkyzivat@cisco.com Mon Jun 20 13:11:02 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAD711E80A5 for ; Mon, 20 Jun 2011 13:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.165 X-Spam-Level: X-Spam-Status: No, score=-110.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLPkXOdMQfFV for ; Mon, 20 Jun 2011 13:11:01 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 83AC611E808E for ; Mon, 20 Jun 2011 13:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=9427; q=dns/txt; s=iport; t=1308600661; x=1309810261; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=M3ioyh3a+aLXxTRTMP8KesqdttoD9jP84SeGNIa+6ks=; b=ZVkQ2ipkW1a8R7920MY3frKCGTxoSXIKTAKs4O4WpF6jFVMHnfnxKt+J fxx8BnS/DGSW15OsKpAr20sQSLSBZB6Gt5P0W4MzXM2ZiGB1I+ygZX7+w hVbScR8wlnRbhdRXBqQidmqBDWL7KM+JyM2aHHKHvhqgg9fz8L1E1Am9R Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAHSo/02rRDoI/2dsb2JhbABTl1qPC3eqZp4YhioEkV6EYIs9 X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208";a="341978147" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 20 Jun 2011 20:11:00 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5KKAwYR020085 for ; Mon, 20 Jun 2011 20:10:59 GMT Message-ID: <4DFFA952.4020409@cisco.com> Date: Mon, 20 Jun 2011 16:10:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1471@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A3@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB5336406@ESESSCMS0356.eemea.ericsson.se>, <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1308@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF298@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB53FF298@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 20:11:02 -0000 What Christer is looking for may already be implicitly present in the existing requirements. REQMT-2a/b/c cover some of this. REQMT-4 also has some relevance. (The endpoint that wants binaural has two speakers for rendering audio. The source may have some different number.) REQMT-10 has some relevance, since the cell phone that wants this has limited bandwidth for receiving the audio. REQMT-13a almost covers part of what Christer is asking for. Its a little obscure, since it uses "transcoding" as a synonym for MCU. (And there is no definition of transcoding in this document or the definitions document - its in the use cases.) And as written it only applies to multipoint conferences. But maybe this isn't needed to get at what Christer is requesting. *If* "binaural" support was representable as an audio codec and options in SDP, and the MCU and/or peer endpoint is willing/able to negotiate support for it, then it seems like it all should "just work" based on these requirements. So I think for the most part this is a matter of accepting the use case, and maybe identifying how the use case is satisfied by the requirements. And maybe a "little" tweaking of the requirements. Thanks, Paul On 6/20/2011 3:22 PM, Christer Holmberg wrote: > Hi Allyn, > >> Still trying to get clarification- >> >> I read your description of various types of rendering. >> Still trying to understand what you want from CLUE- >> If we have a tag that says "binaural" or stereo, sub binaural, are we >> done? > > Of course we could have a binaural specific SDP attribute, e.g. a=binaural. > > But, again, what we are proposing is a general mechanism, that could look something like: > > a=rendering-type = > > could then e.g. be "binaural", but it could also be something else (we showed a few example in the e-mail). > >> Or do you want CLUE to describe how to do some kind of rendering? To say >> something more about specific rendering functions? > > No, CLUE doesn't need to say anything about that. > > There would of course need to be a rendering description associated with each rendering type value, but CLUE wouldn't define those. > > The idea is that an IANA registry is created, where people can register their rendering type values. > > Regards, > > Christer > > > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Sunday, June 19, 2011 10:29 PM >> To: Allyn Romanow (allyn); Mary Barnes >> Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) >> Subject: RE: [clue] Requirement on centralized media mixing >> >> >> Hi Allyn, >> >> I appologise that it took some time to reply. >> >> We've been working on some definition/example text (I sent it to the >> list just a few minutes ago), which I hope will clarify some of the >> questions that have been asked. >> >>> Also, what kind of support are you asking for binaural? I believe > it's >> often considered as a subset of stereo. What are you asking for? A >> simple tag that says "binaural", or the specification >>> of a rendering system for binaural? Precisely what are asking for? >> >> From CLUE, we are only asking for a general mechanism to request and >> indicate different rendering types (see definition in other e-mail). >> >> An example of such rendering type is binaural, BUT we are *NOT* asking >> CLUE to define any binaural specific SDP attributes etc. If such are >> needed, we agree that it needs to be done as a separate task. >> >> Before I try to answer your other questions, please take a look at the >> definition/example e-mail, which I hope will clarify what we mean by >> rendering and rendering type. >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hi Christer - >> >> In spirit I am enthusiastic about what you are proposing > (meaning >> good quality mobile participation). I'm not clear on how the spirit >> becomes instantiated in our protocol, so I have some questions below J >> >> Thanks, >> >> Allyn >> >> >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf Of Christer Holmberg >> Sent: Tuesday, June 14, 2011 7:23 AM >> To: clue@ietf.org >> Subject: [clue] Requirement on centralized media mixing >> >> >> >> >> >> Hi, >> >> >> >> During the last interim meeting (May 12th) we discussed a >> requirement proposal >> >> stating that an endpoint must be able to request central audio >> rendering >> >> of different predefined formats, including 3D binaural > rendering. >> >> (Link to proposal: http://www.ietf.org/mail- >> archive/web/clue/current/msg00179.html) >> >> >> >> The proposal was well received, with the reservation that it >> should not be mandatory >> >> for the solution to implement centralized 3D binaural rendering, >> i.e.an endpoint should >> >> be able to request 3D binaural rendering, but had no guaranty >> that such rendering was >> >> supported by the system. >> >> >> >> It was decided to look how such requirement could look like. >> >> >> >> When I look the -03 version of the req draft, Requirement 2c >> states: >> >> >> >> "The solution MUST NOT preclude the use of binaural audio." >> >> >> >> I think that requirement is unclear, and it doesn't really give >> any guidance to our work. >> >> >> >> Due to that, and also due to the fact that rather than talking >> about specific rendering types, >> >> I would like to propose more general requirement text on the >> negotiation of the media mixing type, >> >> and the usage of centralized media mixing in the first place. >> >> >> >> The mechanism would be extendable, so new types can be added in >> future. >> >> >> >> So, the proposed requirements are: >> >> >> >> REQ-x: It MUST be possible to negotiate the usage of >> centralized media mixing. System support of centralized media mixing > is >> optional. >> >> >> >> REQ-y: When centralized media mixing is used, it MUST be >> possible to negotiate the type of media rendering provided for each >> media stream received by a client. >> >> --- >> >> [ar] I have a few questions/comments: >> >> 1. The term "negotiate" troubles me as I think it means > a >> particular form of communication that dictates the solution. What is >> being asked for is the receiver to know that it is receiving >> "centralized media mixing". This may not be the end product of a >> negotiation. The same is true of the use of the term negotiate in the >> second requirement. What is needed is a mechanism by which the > receiver >> may know what type of "media rendering" is being received. >> >> So, I'd rather offer, The solution must support a means for >> identifying a stream which is "centralized media mixing". >> >> And, When "centralized media mixing" is used, the solution must >> support a means for identifying... >> >> >> >> 2. Also, I'm not too sure what "media rendering", the >> phrase in the second reqmt, represents- SDP and RTP recognize audio >> channels and recognize codecs. Is this what is referred to as "media >> rendering"? Or is it something different? What very specifically? >> >> >> >> 3. After reading more of the discussion, I realize that I >> don't fully understand what is meant in the first reqmt by > "centralized >> media mixing" or "rendering", which term is used in another email. I >> had thought you meant the usual audio mixing such as discussed in RFC >> 5117.( I figured it was an understood part of the topology so didn't >> need to be called out in particular. But I don't mind calling it > out.) >> In any case, now I'm not sure what you mean, maybe it is something >> other than typical MCU mixing behavior as described in RFC 5117? >> >> >> >> 4. As for the discussion of binaural.. here is what it >> seems like to me.. AVP, RFC 3551 specifies the number of audio >> channels, what they refer to, and types of codecs. Binaural is >> neither. As you say, Christer, it's a type of stereo channel. Steve >> feels that "binaural" must be recognized in SDP, which of course, it > is >> not currently. >> >> >> >> I'm not entirely sure what needs to be specified about binaural, >> given that it is neither channel -type nor codec-type. What needs to > be >> standardized? This question is probably more for Steve, or both of > you. >> If the receiving device knows it's getting binaural stereo, then it > can >> run some algorithms to improve quality and if it isn't binaural, it >> won't run those algs., or something analogous? If that is the case, I >> don't see what needs to be standardized that isn't already >> standardized... But I'm eager to learn. >> >> >> >> Thanks- >> >> Allyn >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From allyn@cisco.com Mon Jun 20 14:47:12 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2E211E80AD for ; Mon, 20 Jun 2011 14:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.285 X-Spam-Level: X-Spam-Status: No, score=-10.285 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9DviMJqifOu for ; Mon, 20 Jun 2011 14:47:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id A739B11E808E for ; Mon, 20 Jun 2011 14:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=8665; q=dns/txt; s=iport; t=1308606425; x=1309816025; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=7krJI6n+8K71OZCqcbjaP/D8Ej8V12jqZM1TUyIu6+A=; b=kuEkcmCz45U4YOKp0zeVmbgd2tcFGxbqs6vidWcOJu+i5vkWwZeLdych ocKrIqkQjSLcAirBWUGtp94UdoEaNssr6p8ODb/Fdo/0oRR4Uag2ELHV+ r6itnEX0sBEzGTsrKx90YBlrROzk2RoLJR/VPzsFTSC2fTfYerjbvzFx9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAIK//02rRDoH/2dsb2JhbABTl1uPC3eqUZ4ahioEhyCPJ4s4 X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208";a="717785044" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 20 Jun 2011 21:47:05 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5KLkw7C014334; Mon, 20 Jun 2011 21:47:05 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jun 2011 14:47:02 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2011 14:47:01 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwqno7BLwl3j+PMSjaOF3ZfYi/FNwBOY9JAAMyJxDAAHFdzUAAAtMt+AAESA4A= From: "Allyn Romanow (allyn)" To: "Christer Holmberg" X-OriginalArrivalTime: 20 Jun 2011 21:47:02.0396 (UTC) FILETIME=[96D23BC0:01CC2F93] Cc: clue@ietf.org Subject: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 21:47:12 -0000 =20 Hi Christer, I think that you are proposing that CLUE needs a mechanism to pass information, such as a tag, on "rendering type", for example, binaural, threshold, etc. Is that correct? And that you are not asking for any more from CLUE than simply identifying the rendering type. Is that correct? IF both of these statements are correct, than personally I think it is fine TO include the information of rendering type, such as "binaural", by some mechanism, such as a tag, AS LONG AS there is an accepted Use Case that shows the necessity of communicating the rendering type, such as "thresholding" or "panning". How do other people feel about this? =20 Thanks, Allyn -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, June 20, 2011 12:23 PM To: Allyn Romanow (allyn); Mary Barnes Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) Subject: RE: [clue] Requirement on centralized media mixing Hi Allyn, >Still trying to get clarification- > >I read your description of various types of rendering. >Still trying to understand what you want from CLUE- >If we have a tag that says "binaural" or stereo, sub binaural, are we >done? Of course we could have a binaural specific SDP attribute, e.g. a=3Dbinaural. But, again, what we are proposing is a general mechanism, that could look something like: a=3Drendering-type =3D could then e.g. be "binaural", but it could also be something else (we showed a few example in the e-mail). >Or do you want CLUE to describe how to do some kind of rendering? To say >something more about specific rendering functions? No, CLUE doesn't need to say anything about that.=20 There would of course need to be a rendering description associated with each rendering type value, but CLUE wouldn't define those. The idea is that an IANA registry is created, where people can register their rendering type values. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, June 19, 2011 10:29 PM > To: Allyn Romanow (allyn); Mary Barnes > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on centralized media mixing > > > Hi Allyn, > > I appologise that it took some time to reply. > > We've been working on some definition/example text (I sent it to the > list just a few minutes ago), which I hope will clarify some of the > questions that have been asked. > > >Also, what kind of support are you asking for binaural? I believe it's > often considered as a subset of stereo. What are you asking for? A > simple tag that says "binaural", or the specification > >of a rendering system for binaural? Precisely what are asking for? > > From CLUE, we are only asking for a general mechanism to request and > indicate different rendering types (see definition in other e-mail). > > An example of such rendering type is binaural, BUT we are *NOT* asking > CLUE to define any binaural specific SDP attributes etc. If such are > needed, we agree that it needs to be done as a separate task. > > Before I try to answer your other questions, please take a look at the > definition/example e-mail, which I hope will clarify what we mean by > rendering and rendering type. > > Regards, > > Christer > > > > > > > > > > > > > > > Hi Christer - > > In spirit I am enthusiastic about what you are proposing (meaning > good quality mobile participation). I'm not clear on how the spirit > becomes instantiated in our protocol, so I have some questions below J > > Thanks, > > Allyn > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Tuesday, June 14, 2011 7:23 AM > To: clue@ietf.org > Subject: [clue] Requirement on centralized media mixing > > > > > > Hi, > > > > During the last interim meeting (May 12th) we discussed a > requirement proposal > > stating that an endpoint must be able to request central audio > rendering > > of different predefined formats, including 3D binaural rendering. > > (Link to proposal: http://www.ietf.org/mail- > archive/web/clue/current/msg00179.html) > > > > The proposal was well received, with the reservation that it > should not be mandatory > > for the solution to implement centralized 3D binaural rendering, > i.e.an endpoint should > > be able to request 3D binaural rendering, but had no guaranty > that such rendering was > > supported by the system. > > > > It was decided to look how such requirement could look like. > > > > When I look the -03 version of the req draft, Requirement 2c > states: > > > > "The solution MUST NOT preclude the use of binaural audio." > > > > I think that requirement is unclear, and it doesn't really give > any guidance to our work. > > > > Due to that, and also due to the fact that rather than talking > about specific rendering types, > > I would like to propose more general requirement text on the > negotiation of the media mixing type, > > and the usage of centralized media mixing in the first place. > > > > The mechanism would be extendable, so new types can be added in > future. > > > > So, the proposed requirements are: > > > > REQ-x: It MUST be possible to negotiate the usage of > centralized media mixing. System support of centralized media mixing is > optional. > > > > REQ-y: When centralized media mixing is used, it MUST be > possible to negotiate the type of media rendering provided for each > media stream received by a client. > > --- > > [ar] I have a few questions/comments: > > 1. The term "negotiate" troubles me as I think it means a > particular form of communication that dictates the solution. What is > being asked for is the receiver to know that it is receiving > "centralized media mixing". This may not be the end product of a > negotiation. The same is true of the use of the term negotiate in the > second requirement. What is needed is a mechanism by which the receiver > may know what type of "media rendering" is being received. > > So, I'd rather offer, The solution must support a means for > identifying a stream which is "centralized media mixing". > > And, When "centralized media mixing" is used, the solution must > support a means for identifying... > > > > 2. Also, I'm not too sure what "media rendering", the > phrase in the second reqmt, represents- SDP and RTP recognize audio > channels and recognize codecs. Is this what is referred to as "media > rendering"? Or is it something different? What very specifically? > > > > 3. After reading more of the discussion, I realize that I > don't fully understand what is meant in the first reqmt by "centralized > media mixing" or "rendering", which term is used in another email. I > had thought you meant the usual audio mixing such as discussed in RFC > 5117.( I figured it was an understood part of the topology so didn't > need to be called out in particular. But I don't mind calling it out.) > In any case, now I'm not sure what you mean, maybe it is something > other than typical MCU mixing behavior as described in RFC 5117? > > > > 4. As for the discussion of binaural.. here is what it > seems like to me.. AVP, RFC 3551 specifies the number of audio > channels, what they refer to, and types of codecs. Binaural is > neither. As you say, Christer, it's a type of stereo channel. Steve > feels that "binaural" must be recognized in SDP, which of course, it is > not currently. > > > > I'm not entirely sure what needs to be specified about binaural, > given that it is neither channel -type nor codec-type. What needs to be > standardized? This question is probably more for Steve, or both of you. > If the receiving device knows it's getting binaural stereo, then it can > run some algorithms to improve quality and if it isn't binaural, it > won't run those algs., or something analogous? If that is the case, I > don't see what needs to be standardized that isn't already > standardized... But I'm eager to learn. > > > > Thanks- > > Allyn > > > > Regards, > > > > Christer > > > > From pkyzivat@cisco.com Mon Jun 20 15:12:17 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6B09E8045 for ; Mon, 20 Jun 2011 15:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.164 X-Spam-Level: X-Spam-Status: No, score=-110.164 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0crxXhvsnSNn for ; Mon, 20 Jun 2011 15:12:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 655469E8046 for ; Mon, 20 Jun 2011 15:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=9374; q=dns/txt; s=iport; t=1308607936; x=1309817536; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=KiKbB3I46waI3iGfSctOhuyMBhlzUJsQyqk7yb34AKA=; b=MgJOvJ+1HxmT7ajbsX0ReL6Zb4VZajvpYzsgYV5wwLKPBmXQhsXgg3Ct /cGhgWDqJcnYGAfFo2kwdU9kjquKgnWD7a6Xpp30ST40B52cw4WeIuZOW Z1JwoTSBCxPPLHiEveqdfPtv0sjhHqIYpNhU2RehUugvQUsPZBPETqDsM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAANHE/02rRDoG/2dsb2JhbABTl1uPDHeIc6FCnh6GKgSRXoRgiz0 X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208";a="342086276" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 20 Jun 2011 22:12:04 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5KMC4Fu018691 for ; Mon, 20 Jun 2011 22:12:04 GMT Message-ID: <4DFFC5B4.3070202@cisco.com> Date: Mon, 20 Jun 2011 18:12:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 22:12:17 -0000 On 6/20/2011 5:47 PM, Allyn Romanow (allyn) wrote: > > > > Hi Christer, > > I think that you are proposing that CLUE needs a mechanism to pass > information, such as a tag, on "rendering type", for example, binaural, > threshold, etc. > Is that correct? How does this differ from simply making an offer with the audio codec and parameters that you want to use? Thanks, Paul > And that you are not asking for any more from CLUE than simply > identifying the rendering type. > Is that correct? > > IF both of these statements are correct, than personally I think it is > fine TO include the information of rendering type, such as "binaural", > by some mechanism, such as a tag, AS LONG AS there is an accepted Use > Case that shows the necessity of communicating the rendering type, such > as "thresholding" or "panning". > > How do other people feel about this? > > Thanks, > Allyn > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 20, 2011 12:23 PM > To: Allyn Romanow (allyn); Mary Barnes > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on centralized media mixing > > Hi Allyn, > >> Still trying to get clarification- >> >> I read your description of various types of rendering. >> Still trying to understand what you want from CLUE- >> If we have a tag that says "binaural" or stereo, sub binaural, are we >> done? > > Of course we could have a binaural specific SDP attribute, e.g. > a=binaural. > > But, again, what we are proposing is a general mechanism, that could > look something like: > > a=rendering-type = > > could then e.g. be "binaural", but it could also be something > else (we showed a few example in the e-mail). > >> Or do you want CLUE to describe how to do some kind of rendering? To > say >> something more about specific rendering functions? > > No, CLUE doesn't need to say anything about that. > > There would of course need to be a rendering description associated with > each rendering type value, but CLUE wouldn't define those. > > The idea is that an IANA registry is created, where people can register > their rendering type values. > > Regards, > > Christer > > > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Sunday, June 19, 2011 10:29 PM >> To: Allyn Romanow (allyn); Mary Barnes >> Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) >> Subject: RE: [clue] Requirement on centralized media mixing >> >> >> Hi Allyn, >> >> I appologise that it took some time to reply. >> >> We've been working on some definition/example text (I sent it to the >> list just a few minutes ago), which I hope will clarify some of the >> questions that have been asked. >> >>> Also, what kind of support are you asking for binaural? I believe > it's >> often considered as a subset of stereo. What are you asking for? A >> simple tag that says "binaural", or the specification >>> of a rendering system for binaural? Precisely what are asking for? >> >> From CLUE, we are only asking for a general mechanism to request and >> indicate different rendering types (see definition in other e-mail). >> >> An example of such rendering type is binaural, BUT we are *NOT* asking >> CLUE to define any binaural specific SDP attributes etc. If such are >> needed, we agree that it needs to be done as a separate task. >> >> Before I try to answer your other questions, please take a look at the >> definition/example e-mail, which I hope will clarify what we mean by >> rendering and rendering type. >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hi Christer - >> >> In spirit I am enthusiastic about what you are proposing > (meaning >> good quality mobile participation). I'm not clear on how the spirit >> becomes instantiated in our protocol, so I have some questions below J >> >> Thanks, >> >> Allyn >> >> >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf Of Christer Holmberg >> Sent: Tuesday, June 14, 2011 7:23 AM >> To: clue@ietf.org >> Subject: [clue] Requirement on centralized media mixing >> >> >> >> >> >> Hi, >> >> >> >> During the last interim meeting (May 12th) we discussed a >> requirement proposal >> >> stating that an endpoint must be able to request central audio >> rendering >> >> of different predefined formats, including 3D binaural > rendering. >> >> (Link to proposal: http://www.ietf.org/mail- >> archive/web/clue/current/msg00179.html) >> >> >> >> The proposal was well received, with the reservation that it >> should not be mandatory >> >> for the solution to implement centralized 3D binaural rendering, >> i.e.an endpoint should >> >> be able to request 3D binaural rendering, but had no guaranty >> that such rendering was >> >> supported by the system. >> >> >> >> It was decided to look how such requirement could look like. >> >> >> >> When I look the -03 version of the req draft, Requirement 2c >> states: >> >> >> >> "The solution MUST NOT preclude the use of binaural audio." >> >> >> >> I think that requirement is unclear, and it doesn't really give >> any guidance to our work. >> >> >> >> Due to that, and also due to the fact that rather than talking >> about specific rendering types, >> >> I would like to propose more general requirement text on the >> negotiation of the media mixing type, >> >> and the usage of centralized media mixing in the first place. >> >> >> >> The mechanism would be extendable, so new types can be added in >> future. >> >> >> >> So, the proposed requirements are: >> >> >> >> REQ-x: It MUST be possible to negotiate the usage of >> centralized media mixing. System support of centralized media mixing > is >> optional. >> >> >> >> REQ-y: When centralized media mixing is used, it MUST be >> possible to negotiate the type of media rendering provided for each >> media stream received by a client. >> >> --- >> >> [ar] I have a few questions/comments: >> >> 1. The term "negotiate" troubles me as I think it means > a >> particular form of communication that dictates the solution. What is >> being asked for is the receiver to know that it is receiving >> "centralized media mixing". This may not be the end product of a >> negotiation. The same is true of the use of the term negotiate in the >> second requirement. What is needed is a mechanism by which the > receiver >> may know what type of "media rendering" is being received. >> >> So, I'd rather offer, The solution must support a means for >> identifying a stream which is "centralized media mixing". >> >> And, When "centralized media mixing" is used, the solution must >> support a means for identifying... >> >> >> >> 2. Also, I'm not too sure what "media rendering", the >> phrase in the second reqmt, represents- SDP and RTP recognize audio >> channels and recognize codecs. Is this what is referred to as "media >> rendering"? Or is it something different? What very specifically? >> >> >> >> 3. After reading more of the discussion, I realize that I >> don't fully understand what is meant in the first reqmt by > "centralized >> media mixing" or "rendering", which term is used in another email. I >> had thought you meant the usual audio mixing such as discussed in RFC >> 5117.( I figured it was an understood part of the topology so didn't >> need to be called out in particular. But I don't mind calling it > out.) >> In any case, now I'm not sure what you mean, maybe it is something >> other than typical MCU mixing behavior as described in RFC 5117? >> >> >> >> 4. As for the discussion of binaural.. here is what it >> seems like to me.. AVP, RFC 3551 specifies the number of audio >> channels, what they refer to, and types of codecs. Binaural is >> neither. As you say, Christer, it's a type of stereo channel. Steve >> feels that "binaural" must be recognized in SDP, which of course, it > is >> not currently. >> >> >> >> I'm not entirely sure what needs to be specified about binaural, >> given that it is neither channel -type nor codec-type. What needs to > be >> standardized? This question is probably more for Steve, or both of > you. >> If the receiving device knows it's getting binaural stereo, then it > can >> run some algorithms to improve quality and if it isn't binaural, it >> won't run those algs., or something analogous? If that is the case, I >> don't see what needs to be standardized that isn't already >> standardized... But I'm eager to learn. >> >> >> >> Thanks- >> >> Allyn >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From stephen.botzko@gmail.com Mon Jun 20 17:01:27 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7369E8008 for ; Mon, 20 Jun 2011 17:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbQYlZjp30Le for ; Mon, 20 Jun 2011 17:01:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAAB9E8007 for ; Mon, 20 Jun 2011 17:01:26 -0700 (PDT) Received: by vxi40 with SMTP id 40so1337699vxi.31 for ; Mon, 20 Jun 2011 17:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RxvhdfcfZkkFSbbN97R3N1eOWD+unX+KcuP2pmqSqiQ=; b=JUc0sgPMH3qejo/xcrZZEu+m//djIHoX0IZsEwLi8bj/VdU6dJ3dJbzhGT8G6KwYiU TrAqPDknwzzfGVfHsSd4a35Csp+2gpeJv9ylcmTAEYfi4Pa1jgfmuL0bmMQLTm/peSQR yBGDtrhnhF90SX+mTkaehv1Zpw8Dg0HQPi+kY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LU2O4+C933ZiUt2luN+nw3a0OwfanO33OPyL2xlC7BsZksGf1T+NY5+BxGBtB/C5HG CIFbUSL7/WokZZ289Dg88qwMwDbgXw5Lj3FZH7htjkiEsSaOjPHSZTDFyLdlvWviuOTo 6WPZRjH3n0cB/a4DTaiktqA/zyNL52VIEyH2k= MIME-Version: 1.0 Received: by 10.52.76.131 with SMTP id k3mr8613086vdw.80.1308614485776; Mon, 20 Jun 2011 17:01:25 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Mon, 20 Jun 2011 17:01:25 -0700 (PDT) In-Reply-To: <008001cc2f5b$c3ea3fa0$4bbebee0$%roni@huawei.com> References: <005101cc2f40$5e997730$1bcc6590$%roni@huawei.com> <008001cc2f5b$c3ea3fa0$4bbebee0$%roni@huawei.com> Date: Mon, 20 Jun 2011 20:01:25 -0400 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/alternative; boundary=bcaec50160e392994504a62d8dd1 Cc: clue@ietf.org Subject: Re: [clue] comments on Requirement draft X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 00:01:27 -0000 --bcaec50160e392994504a62d8dd1 Content-Type: text/plain; charset=ISO-8859-1 Roni, It's possible that we will end up with more media types than audio and video. And some systems might have displays but no cameras. Saying "no cameras" and/or "no displays" seemed more precise than "audio only". Regards Stephen On Mon, Jun 20, 2011 at 11:07 AM, Roni Even wrote: > Steve,**** > > So why not say audio only, the current text is unclear**** > > ** ** > > "The solution MUST support interoperability between endpoints where the number of cameras and/or displays are zero."**** > > ** ** > > Maybe say like IP phones****** ** > > Roni**** > > ** ** > > *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Monday, June 20, 2011 5:25 PM > *To:* Roni Even > *Cc:* clue@ietf.org > *Subject:* Re: [clue] comments on Requirement draft**** > > ** ** > > Hi Roni > > Requirement 4 covers the case where the number of cameras or displays are > mismatched. However, with legacy devices (and perhaps CLUEd mobile > devices), it is possible that there is no video at all. It wasn't clear to > us if requirement 4 captured that case or not, so requirement 5 was added. > > Regards, > Stephen Botzko**** > > On Mon, Jun 20, 2011 at 7:51 AM, Roni Even wrote:** > ** > > Hi,**** > > I think that the draft should include a reference to the use case draft > since it mention it in the requirements section. Maybe the introduction > should mention that the use cases draft is used for the requirements.**** > > **** > > I am not sure what is the meaning or use case for requirement 5.**** > > **** > > Regards**** > > Roni**** > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --bcaec50160e392994504a62d8dd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Roni,
=A0
It's possible that we will end up with more media types than audio= and video.=A0 And some systems might have displays but no cameras.=A0 Sayi= ng "no cameras" and/or "no displays" seemed more precis= e than "audio only".
=A0
Regards
Stephen
=A0
=A0
=A0


=A0
On Mon, Jun 20, 2011 at 11:07 AM, Roni Even <Even.roni@huawei.= com> wrote:

Stev= e,

So w= hy not say audio only, the current text is unclear

<= /u>=A0

=A0


Maybe say like IP phones=A0


Roni=



<=
/u>=A0








From:<=
span style=3D"FONT-SIZE: 10pt"> Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Monday, June 20, 2011 5:25 PM

To: Roni Even
Cc: clue@ietf.org
Subject: Re: [clue] comments on Req=
uirement draft








=A0


Hi Roni

Requirement 4 covers the case where the number of cameras=
 or displays are mismatched.=A0 However, with legacy devices (and perhaps C=
LUEd mobile devices), it is possible that there is no video at all.=A0 It w=
asn't clear to us if requirement 4 captured that case or not, so requir=
ement 5 was added.=A0 


Regards,
Stephen Botzko



=A0
<= /blockquote>

--bcaec50160e392994504a62d8dd1-- From christer.holmberg@ericsson.com Tue Jun 21 01:22:37 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6E311E81CF for ; Tue, 21 Jun 2011 01:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2akouU9du-9 for ; Tue, 21 Jun 2011 01:22:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 12E2D11E8203 for ; Tue, 21 Jun 2011 01:22:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-77-4e0054c70fb5 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 58.EC.09774.7C4500E4; Tue, 21 Jun 2011 10:22:32 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 21 Jun 2011 10:22:21 +0200 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Date: Tue, 21 Jun 2011 10:22:19 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwvlx+CSfEx2VdqRDmSA6ii0qH9+wAUzVTg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB5336B89@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <4DFFC5B4.3070202@cisco.com> In-Reply-To: <4DFFC5B4.3070202@cisco.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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 08:22:37 -0000 Hi Paul,=20 >>I think that you are proposing that CLUE needs a mechanism to pass=20 >>information, such as a tag, on "rendering type", for example,=20 >>binaural, threshold, etc. >>Is that correct? >=20 >How does this differ from simply making an offer with the=20 >audio codec and parameters that you want to use? Assuming we would use an SDP element (e.g. an SDP attribute) to indicate th= e rendering-type, there should be no difference. Regards, Christer > > And that you are not asking for any more from CLUE than simply=20 > > identifying the rendering type. > > Is that correct? > > > > IF both of these statements are correct, than personally I=20 > think it is=20 > > fine TO include the information of rendering type, such as=20 > "binaural",=20 > > by some mechanism, such as a tag, AS LONG AS there is an=20 > accepted Use=20 > > Case that shows the necessity of communicating the rendering type,=20 > > such as "thresholding" or "panning". > > > > How do other people feel about this? > > > > Thanks, > > Allyn > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 20, 2011 12:23 PM > > To: Allyn Romanow (allyn); Mary Barnes > > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > > Subject: RE: [clue] Requirement on centralized media mixing > > > > Hi Allyn, > > > >> Still trying to get clarification- > >> > >> I read your description of various types of rendering. > >> Still trying to understand what you want from CLUE- If we=20 > have a tag=20 > >> that says "binaural" or stereo, sub binaural, are we done? > > > > Of course we could have a binaural specific SDP attribute, e.g. > > a=3Dbinaural. > > > > But, again, what we are proposing is a general mechanism,=20 > that could=20 > > look something like: > > > > a=3Drendering-type =3D > > > > could then e.g. be "binaural", but it could also=20 > be something=20 > > else (we showed a few example in the e-mail). > > > >> Or do you want CLUE to describe how to do some kind of=20 > rendering? To > > say > >> something more about specific rendering functions? > > > > No, CLUE doesn't need to say anything about that. > > > > There would of course need to be a rendering description associated=20 > > with each rendering type value, but CLUE wouldn't define those. > > > > The idea is that an IANA registry is created, where people can=20 > > register their rendering type values. > > > > Regards, > > > > Christer > > > > > > > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Sunday, June 19, 2011 10:29 PM > >> To: Allyn Romanow (allyn); Mary Barnes > >> Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > >> Subject: RE: [clue] Requirement on centralized media mixing > >> > >> > >> Hi Allyn, > >> > >> I appologise that it took some time to reply. > >> > >> We've been working on some definition/example text (I sent=20 > it to the=20 > >> list just a few minutes ago), which I hope will clarify=20 > some of the=20 > >> questions that have been asked. > >> > >>> Also, what kind of support are you asking for binaural? I believe > > it's > >> often considered as a subset of stereo. What are you asking for? A=20 > >> simple tag that says "binaural", or the specification > >>> of a rendering system for binaural? Precisely what are asking for? > >> > >> From CLUE, we are only asking for a general mechanism to=20 > request and=20 > >> indicate different rendering types (see definition in=20 > other e-mail). > >> > >> An example of such rendering type is binaural, BUT we are *NOT*=20 > >> asking CLUE to define any binaural specific SDP attributes etc. If=20 > >> such are needed, we agree that it needs to be done as a=20 > separate task. > >> > >> Before I try to answer your other questions, please take a look at=20 > >> the definition/example e-mail, which I hope will clarify=20 > what we mean=20 > >> by rendering and rendering type. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Hi Christer - > >> > >> In spirit I am enthusiastic about what you are proposing > > (meaning > >> good quality mobile participation). I'm not clear on how=20 > the spirit=20 > >> becomes instantiated in our protocol, so I have some=20 > questions below=20 > >> J > >> > >> Thanks, > >> > >> Allyn > >> > >> > >> > >> From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On=20 > >> Behalf Of Christer Holmberg > >> Sent: Tuesday, June 14, 2011 7:23 AM > >> To: clue@ietf.org > >> Subject: [clue] Requirement on centralized media mixing > >> > >> > >> > >> > >> > >> Hi, > >> > >> > >> > >> During the last interim meeting (May 12th) we discussed a=20 > >> requirement proposal > >> > >> stating that an endpoint must be able to request=20 > central audio=20 > >> rendering > >> > >> of different predefined formats, including 3D binaural > > rendering. > >> > >> (Link to proposal: http://www.ietf.org/mail- > >> archive/web/clue/current/msg00179.html) > >> > >> > >> > >> The proposal was well received, with the=20 > reservation that it=20 > >> should not be mandatory > >> > >> for the solution to implement centralized 3D binaural=20 > >> rendering, i.e.an endpoint should > >> > >> be able to request 3D binaural rendering, but had=20 > no guaranty=20 > >> that such rendering was > >> > >> supported by the system. > >> > >> > >> > >> It was decided to look how such requirement could look like. > >> > >> > >> > >> When I look the -03 version of the req draft, Requirement 2c > >> states: > >> > >> > >> > >> "The solution MUST NOT preclude the use of=20 > binaural audio." > >> > >> > >> > >> I think that requirement is unclear, and it doesn't really=20 > >> give any guidance to our work. > >> > >> > >> > >> Due to that, and also due to the fact that rather=20 > than talking=20 > >> about specific rendering types, > >> > >> I would like to propose more general requirement=20 > text on the=20 > >> negotiation of the media mixing type, > >> > >> and the usage of centralized media mixing in the=20 > first place. > >> > >> > >> > >> The mechanism would be extendable, so new types can=20 > be added=20 > >> in future. > >> > >> > >> > >> So, the proposed requirements are: > >> > >> > >> > >> REQ-x: It MUST be possible to negotiate the usage of > >> centralized media mixing. System support of centralized=20 > media mixing > > is > >> optional. > >> > >> > >> > >> REQ-y: When centralized media mixing is used, it MUST be > >> possible to negotiate the type of media rendering provided=20 > for each=20 > >> media stream received by a client. > >> > >> --- > >> > >> [ar] I have a few questions/comments: > >> > >> 1. The term "negotiate" troubles me as I=20 > think it means > > a > >> particular form of communication that dictates the=20 > solution. What is=20 > >> being asked for is the receiver to know that it is receiving=20 > >> "centralized media mixing". This may not be the end product of a=20 > >> negotiation. The same is true of the use of the term=20 > negotiate in the=20 > >> second requirement. What is needed is a mechanism by which the > > receiver > >> may know what type of "media rendering" is being received. > >> > >> So, I'd rather offer, The solution must=20 > support a means=20 > >> for identifying a stream which is "centralized media mixing". > >> > >> And, When "centralized media mixing" is used, the solution=20 > >> must support a means for identifying... > >> > >> > >> > >> 2. Also, I'm not too sure what "media=20 > rendering", the > >> phrase in the second reqmt, represents- SDP and RTP=20 > recognize audio=20 > >> channels and recognize codecs. Is this what is referred to=20 > as "media=20 > >> rendering"? Or is it something different? What very specifically? > >> > >> > >> > >> 3. After reading more of the discussion, I=20 > realize that I > >> don't fully understand what is meant in the first reqmt by > > "centralized > >> media mixing" or "rendering", which term is used in=20 > another email. I=20 > >> had thought you meant the usual audio mixing such as=20 > discussed in RFC=20 > >> 5117.( I figured it was an understood part of the topology=20 > so didn't=20 > >> need to be called out in particular. But I don't mind calling it > > out.) > >> In any case, now I'm not sure what you mean, maybe it is something=20 > >> other than typical MCU mixing behavior as described in RFC 5117? > >> > >> > >> > >> 4. As for the discussion of binaural.. here is what it > >> seems like to me.. AVP, RFC 3551 specifies the number of audio=20 > >> channels, what they refer to, and types of codecs. Binaural is=20 > >> neither. As you say, Christer, it's a type of stereo=20 > channel. Steve=20 > >> feels that "binaural" must be recognized in SDP, which of=20 > course, it > > is > >> not currently. > >> > >> > >> > >> I'm not entirely sure what needs to be specified about=20 > >> binaural, given that it is neither channel -type nor=20 > codec-type. What=20 > >> needs to > > be > >> standardized? This question is probably more for Steve, or both of > > you. > >> If the receiving device knows it's getting binaural stereo, then it > > can > >> run some algorithms to improve quality and if it isn't=20 > binaural, it=20 > >> won't run those algs., or something analogous? If that is=20 > the case, I=20 > >> don't see what needs to be standardized that isn't already=20 > >> standardized... But I'm eager to learn. > >> > >> > >> > >> Thanks- > >> > >> Allyn > >> > >> > >> > >> Regards, > >> > >> > >> > >> Christer > >> > >> > >> > >> > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > = From christer.holmberg@ericsson.com Tue Jun 21 01:23:40 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C3011E815B for ; Tue, 21 Jun 2011 01:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRMQT3A9giez for ; Tue, 21 Jun 2011 01:23:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5E36011E80BC for ; Tue, 21 Jun 2011 01:23:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-00-4e00550a9840 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.115.90]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8B.3D.09774.A05500E4; Tue, 21 Jun 2011 10:23:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 21 Jun 2011 10:23:10 +0200 From: Christer Holmberg To: "Allyn Romanow (allyn)" Date: Tue, 21 Jun 2011 10:23:09 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwqno7BLwl3j+PMSjaOF3ZfYi/FNwBOY9JAAMyJxDAAHFdzUAAAtMt+AAESA4AAGflSQA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB5336B8C@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.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 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 08:23:41 -0000 Hi Allyn,=20 >I think that you are proposing that CLUE needs a mechanism to=20 >pass information, such as a tag, on "rendering type", for=20 >example, binaural, threshold, etc. >Is that correct? Yes. >And that you are not asking for any more from CLUE than=20 >simply identifying the rendering type. >Is that correct? Yes. Identifying, per stream, the rendering type(s) that the receiver is wi= lling to receive, and the rendering type(s) eventually associated with the = stream. Regards, Christer >IF both of these statements are correct, than personally I=20 >think it is fine TO include the information of rendering=20 >type, such as "binaural", by some mechanism, such as a tag,=20 >AS LONG AS there is an accepted Use Case that shows the=20 >necessity of communicating the rendering type, such as=20 >"thresholding" or "panning". > >=20 > How do other people feel about this? =20 >=20 > Thanks, > Allyn >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 20, 2011 12:23 PM > To: Allyn Romanow (allyn); Mary Barnes > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on centralized media mixing >=20 > Hi Allyn, >=20 > >Still trying to get clarification- > > > >I read your description of various types of rendering. > >Still trying to understand what you want from CLUE- If we have a tag=20 > >that says "binaural" or stereo, sub binaural, are we done? >=20 > Of course we could have a binaural specific SDP attribute, e.g. > a=3Dbinaural. >=20 > But, again, what we are proposing is a general mechanism,=20 > that could look something like: >=20 > a=3Drendering-type =3D >=20 > could then e.g. be "binaural", but it could also be=20 > something else (we showed a few example in the e-mail). >=20 > >Or do you want CLUE to describe how to do some kind of rendering? To > say > >something more about specific rendering functions? >=20 > No, CLUE doesn't need to say anything about that.=20 >=20 > There would of course need to be a rendering description=20 > associated with each rendering type value, but CLUE wouldn't=20 > define those. >=20 > The idea is that an IANA registry is created, where people=20 > can register their rendering type values. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Sunday, June 19, 2011 10:29 PM > > To: Allyn Romanow (allyn); Mary Barnes > > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > > Subject: RE: [clue] Requirement on centralized media mixing > > > > > > Hi Allyn, > > > > I appologise that it took some time to reply. > > > > We've been working on some definition/example text (I sent=20 > it to the=20 > > list just a few minutes ago), which I hope will clarify some of the=20 > > questions that have been asked. > > > > >Also, what kind of support are you asking for binaural? I believe > it's > > often considered as a subset of stereo. What are you asking for? A=20 > > simple tag that says "binaural", or the specification > > >of a rendering system for binaural? Precisely what are asking for? > > > > From CLUE, we are only asking for a general mechanism to=20 > request and=20 > > indicate different rendering types (see definition in other e-mail). > > > > An example of such rendering type is binaural, BUT we are=20 > *NOT* asking=20 > > CLUE to define any binaural specific SDP attributes etc. If=20 > such are=20 > > needed, we agree that it needs to be done as a separate task. > > > > Before I try to answer your other questions, please take a=20 > look at the=20 > > definition/example e-mail, which I hope will clarify what=20 > we mean by=20 > > rendering and rendering type. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Christer - > > > > In spirit I am enthusiastic about what you are proposing > (meaning > > good quality mobile participation). I'm not clear on how the spirit=20 > > becomes instantiated in our protocol, so I have some=20 > questions below J > > > > Thanks, > > > > Allyn > > > > > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > > Behalf Of Christer Holmberg > > Sent: Tuesday, June 14, 2011 7:23 AM > > To: clue@ietf.org > > Subject: [clue] Requirement on centralized media mixing > > > > > > > > > > > > Hi, > > > > > > > > During the last interim meeting (May 12th) we discussed a=20 > > requirement proposal > > > > stating that an endpoint must be able to request=20 > central audio=20 > > rendering > > > > of different predefined formats, including 3D binaural > rendering. > > > > (Link to proposal: http://www.ietf.org/mail- > > archive/web/clue/current/msg00179.html) > > > > > > > > The proposal was well received, with the reservation that it=20 > > should not be mandatory > > > > for the solution to implement centralized 3D binaural=20 > rendering,=20 > > i.e.an endpoint should > > > > be able to request 3D binaural rendering, but had no guaranty=20 > > that such rendering was > > > > supported by the system. > > > > > > > > It was decided to look how such requirement could look like. > > > > > > > > When I look the -03 version of the req draft, Requirement 2c > > states: > > > > > > > > "The solution MUST NOT preclude the use of=20 > binaural audio." > > > > > > > > I think that requirement is unclear, and it doesn't=20 > really give=20 > > any guidance to our work. > > > > > > > > Due to that, and also due to the fact that rather=20 > than talking=20 > > about specific rendering types, > > > > I would like to propose more general requirement text on the=20 > > negotiation of the media mixing type, > > > > and the usage of centralized media mixing in the first place. > > > > > > > > The mechanism would be extendable, so new types can=20 > be added in=20 > > future. > > > > > > > > So, the proposed requirements are: > > > > > > > > REQ-x: It MUST be possible to negotiate the usage of > > centralized media mixing. System support of centralized media mixing > is > > optional. > > > > > > > > REQ-y: When centralized media mixing is used, it MUST be > > possible to negotiate the type of media rendering provided for each=20 > > media stream received by a client. > > > > --- > > > > [ar] I have a few questions/comments: > > > > 1. The term "negotiate" troubles me as I=20 > think it means > a > > particular form of communication that dictates the=20 > solution. What is=20 > > being asked for is the receiver to know that it is receiving=20 > > "centralized media mixing". This may not be the end product of a=20 > > negotiation. The same is true of the use of the term=20 > negotiate in the=20 > > second requirement. What is needed is a mechanism by which the > receiver > > may know what type of "media rendering" is being received. > > > > So, I'd rather offer, The solution must support=20 > a means for=20 > > identifying a stream which is "centralized media mixing". > > > > And, When "centralized media mixing" is used, the=20 > solution must=20 > > support a means for identifying... > > > > > > > > 2. Also, I'm not too sure what "media rendering", the > > phrase in the second reqmt, represents- SDP and RTP recognize audio=20 > > channels and recognize codecs. Is this what is referred to=20 > as "media=20 > > rendering"? Or is it something different? What very specifically? > > > > > > > > 3. After reading more of the discussion, I=20 > realize that I > > don't fully understand what is meant in the first reqmt by > "centralized > > media mixing" or "rendering", which term is used in another=20 > email. I=20 > > had thought you meant the usual audio mixing such as=20 > discussed in RFC=20 > > 5117.( I figured it was an understood part of the topology=20 > so didn't=20 > > need to be called out in particular. But I don't mind calling it > out.) > > In any case, now I'm not sure what you mean, maybe it is something=20 > > other than typical MCU mixing behavior as described in RFC 5117? > > > > > > > > 4. As for the discussion of binaural.. here is what it > > seems like to me.. AVP, RFC 3551 specifies the number of audio=20 > > channels, what they refer to, and types of codecs. Binaural is=20 > > neither. As you say, Christer, it's a type of stereo=20 > channel. Steve=20 > > feels that "binaural" must be recognized in SDP, which of course, it > is > > not currently. > > > > > > > > I'm not entirely sure what needs to be specified=20 > about binaural,=20 > > given that it is neither channel -type nor codec-type. What needs to > be > > standardized? This question is probably more for Steve, or both of > you. > > If the receiving device knows it's getting binaural stereo, then it > can > > run some algorithms to improve quality and if it isn't binaural, it=20 > > won't run those algs., or something analogous? If that is=20 > the case, I=20 > > don't see what needs to be standardized that isn't already=20 > > standardized... But I'm eager to learn. > > > > > > > > Thanks- > > > > Allyn > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > = From stephane.cazeaux@orange-ftgroup.com Tue Jun 21 01:55:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A32C9E8010 for ; Tue, 21 Jun 2011 01:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kPE00J-V46M for ; Tue, 21 Jun 2011 01:55:30 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5801C9E8008 for ; Tue, 21 Jun 2011 01:55:28 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 44B0B7B802B for ; Tue, 21 Jun 2011 10:56:44 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2B5147B8013 for ; Tue, 21 Jun 2011 10:56:44 +0200 (CEST) Received: from FTRDCH02.rd.francetelecom.fr ([10.194.32.13]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 10:54:56 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH02.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Tue, 21 Jun 2011 10:54:55 +0200 From: To: Thread-Topic: Comments on requirements draft 03 Thread-Index: Acwv720MBk44QiS1RO+1tEnQLejyxw== Date: Tue, 21 Jun 2011 08:54:54 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.135] Content-Type: multipart/alternative; boundary="_000_FEE7A6136F518B4B87037A58924AB6B0A8403FFTRDMB03rdfrancet_" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jun 2011 08:54:56.0223 (UTC) FILETIME=[E4AEF6F0:01CC2FF0] Subject: [clue] Comments on requirements draft 03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 08:55:31 -0000 --_000_FEE7A6136F518B4B87037A58924AB6B0A8403FFTRDMB03rdfrancet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Few comments on the requirements draft 03. 1) I think we should consider cases where the placement is done by the remote.= For instance, a use case is a lecture conference, where we want that all a= ttendees see the video of the presenter at a certain position (e.g. the cen= ter screen). The REQMT-1 does not cover such use case, since it defines requirements tha= t enable a local endpoint to do the placement based on information relative= to each stream. I propose to add the following requirement: Req-x: the solution MUST support a means of allowing a remote to define whi= ch streams must be rendered on which position/device of a receiving endpoin= t 2) We need to consider defining roles of streams, when spatial position is not= applicable. This is especially valid for presentation (REQMT-16), since th= e new draft seems to consider multiple presentation streams (typically : ne= xt/current/previous slide ?). Req-x: the solution MUST support a means of defining roles = of streams. 3) Is it a correct understanding that REQMT-17 enables to consider other types= of media in the future (for instance the real time text)? Stephane. --_000_FEE7A6136F518B4B87037A58924AB6B0A8403FFTRDMB03rdfrancet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Few comments on the requirement= s draft 03.

 

1)

I think we should consider case= s where the placement is done by the remote. For instance, a use case is a = lecture conference, where we want that all attendees see the video of the p= resenter at a certain position (e.g. the center screen).

 

The REQMT-1 does not cover such= use case, since it defines requirements that enable a local endpoint to do= the placement based on information relative to each stream.

I propose to add the following = requirement:

     &= nbsp;         

Re= q-x: the solution MUST support a means of allowing a remote to define which= streams must be rendered on which position/device of a receiving endpoint<= o:p>

 

2)

We need to consider defining ro= les of streams, when spatial position is not applicable. This is especially= valid for presentation (REQMT-16), since the new draft seems to consider m= ultiple presentation streams (typically : next/current/previous slide ?).

 

     &= nbsp;          Req-x: the solu= tion MUST support a means of defining roles of streams.

 

3)

Is it a correct understanding t= hat REQMT-17 enables to consider other types of media in the future (for in= stance the real time text)?

 

Stephane.

--_000_FEE7A6136F518B4B87037A58924AB6B0A8403FFTRDMB03rdfrancet_-- From christer.holmberg@ericsson.com Tue Jun 21 03:52:02 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8ADB11E80B4 for ; Tue, 21 Jun 2011 03:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H29ikOnSJ5Xc for ; Tue, 21 Jun 2011 03:51:58 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B5F9711E80B3 for ; Tue, 21 Jun 2011 03:51:57 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e2-4e0077c424b4 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2C.22.20773.4C7700E4; Tue, 21 Jun 2011 12:51:48 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 21 Jun 2011 12:51:41 +0200 From: Christer Holmberg To: "clue@ietf.org" Date: Tue, 21 Jun 2011 12:51:42 +0200 Thread-Topic: Layout negotiation Thread-Index: AcwwATSD2MWMnBnxSh63CAep1FO53g== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336D16ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 10:52:03 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336D16ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A while ago there were some discussions about having requirements to negoti= ate the layout type, and at least according to Stephen B it was within the = scope of the work. "The ability to negotiate an audio or video layout is clearly withi= n scope, and has general value it the group wants to take it on. For instance, if you combine video switching of multiple sources wi= th audio mixing/transcoding, then the receiver is responsible for the video layout but has no control over the audio layout. In = that case, there are advantages to allowing the receiver to tell the central audio mixer where it wants the sources placed on the sound = stage. I have no objection in principle to adding that kind of negotiation to the requirements, though I think the group should co= nsider the impact on the schedule." However, I haven't seen any input after that. My idea would be that it is very similar to the rendering type: CLUE define= s a mechanism to negotiate the layout type, but doesn't define specific typ= es (instead an IANA registry would be created for that). So, I don't think = it would have any significant impact on our schedule. Whether it, in addition to negotiation a layout type (which specifies the s= ource locations), should be possible for the user to more explicit place in= dividual sources, as mentioned by Stephen, can be discussed. However, that = would probably require a little more work, so at least I would be happy wit= h a simple layout type negotiation at this point. So, would people be ok with such requirement? (Another alternative would be to "embed" the layout type into the rendering= type, but I think that would be very clumsy. Because, in that case you wou= ld need to define mulitple types for the same rendering, but with different= layouts.) Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336D16ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
A while ago there were some discussions= about having requirements to negotiate the layout type, and at least accor= ding to Stephen B it was within the scope of the work.
 
      &nb= sp; "The ability to negotiate an audio or video layout is clearly with= in scope, and has general value it the group wants to take it on. 
      &nb= sp; For instance, if you combine video switching of multiple sources with a= udio mixing/transcoding, then the receiver is responsible
      &nb= sp; for the video layout but has no control over the audio layout.  In= that case, there are advantages to allowing the receiver to tell the
      &nb= sp; central audio mixer where it wants the sources placed on the sound stag= e.  I have no objection in principle to adding that kind of
      &nb= sp; negotiation to the requirements, though I think the group should consid= er the impact on the schedule."
 
However, I haven't seen any input after= that.
 
My idea would be that it is very simila= r to the rendering type: CLUE defines a mechanism to negotiate the layout t= ype, but doesn't define specific types (instead an IANA registry would be c= reated for that). So, I don't think it would have any significant impact on our schedule.
 
Whether it, in addition to negotiation = a layout type (which specifies the source locations), should be possible fo= r the user to more explicit place individual sources, as mentioned by Steph= en, can be discussed. However, that would probably require a little more work, so at least I would be happy wit= h a simple layout type negotiation at this point.
 
So, would people be ok with such requir= ement?
 
(Another alternative would be to "= embed" the layout type into the rendering type, but I think that would= be very clumsy. Because, in that case you would need to define mulitple ty= pes for the same rendering, but with different layouts.)
 
Regards,
 
Christer
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336D16ESESSCMS0356e_-- From espeberg@cisco.com Tue Jun 21 05:01:07 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBFF11E8079 for ; Tue, 21 Jun 2011 05:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ7N2mejRAwI for ; Tue, 21 Jun 2011 05:01:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCA911E80C2 for ; Tue, 21 Jun 2011 05:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=16683; q=dns/txt; s=iport; t=1308657662; x=1309867262; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=0Wf3IEJfYKQQ0C4Q1hXc1Z0S7gRtNmMzHv2nBxTcXI0=; b=A23QfdIlHC3GeVbBlUt+Yz5EzJ0Qbo7/pmsoRgXtNzIArR+dxwp2aJZE SqnEcZ+HR7zvlCEcX4vMDRb6MWnNlJxGZ4A8gnPcnDCgUb6ROtUMvvmws c+lRxTqEO5zKu5Yt+PSkyR1rEOsK2DWJD7PJJm/wBYl5aGmWWJvCPdTKQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAKiHAE6Q/khR/2dsb2JhbABUglGVCo8Td6ounkGGKgSWUYQ9hmA X-IronPort-AV: E=Sophos;i="4.65,400,1304294400"; d="scan'208,217";a="95411449" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 21 Jun 2011 12:00:58 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5LC0wB3014210; Tue, 21 Jun 2011 12:00:58 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 14:00:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC300A.E199F002" Date: Tue, 21 Jun 2011 14:00:57 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E71B82A@XMB-AMS-214.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Comment on requirements-03 - aspect ratio Thread-Index: AcwvVCSVjuaQg4wSSqyyGKulIhxqNwAtkJDw References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF10A5@xmb-sjc-221.amer.cisco.com><92DF9533227FC14F946C7321074B8C9E71B6C4@XMB-AMS-214.cisco.com> From: "Espen Berger (espeberg)" To: "Stephen Botzko" X-OriginalArrivalTime: 21 Jun 2011 12:00:58.0372 (UTC) FILETIME=[E1D7BC40:01CC300A] Cc: clue@ietf.org Subject: Re: [clue] Comment on requirements-03 - aspect ratio X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 12:01:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC300A.E199F002 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We can add support for full-size display a sub-point to REQ-1.=20 =20 -Espen=20 =20 =20 From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: 20. juni 2011 16:11 To: Espen Berger (espeberg) Cc: Allyn Romanow (allyn); Elwell, John; clue@ietf.org Subject: Re: [clue] Comment on requirements-03 - aspect ratio =20 Aspect Ratio creates some unique issues with multiple displays, especially if the aspect ratio of the received pictures do not match the physical displays. This is shown in the use cases. So the H.264 decoder rules are not sufficient to get the behavior we want here. Similarly, the solution needs to enable display of far-end participants at the proper apparent size. Again, H.264 decoder rules do not cover this. Requirements 6-8 were intended to fill the gap. However, we seem to have lost the "actual size" display (called "full-sized display" in the use cases draft) in the current formulation. This needs to be fixed, as the ability to match the visual scale of the incoming video is an important aspect of the solution. Regards, Stephen Botzko On Mon, Jun 20, 2011 at 8:04 AM, Espen Berger (espeberg) wrote: I did not fully understand the reason for REQ-6, REQ-7 and REQ-8. These requirements are already covered in current decode rules for H.264 video. A decoder: - should decode any aspect-ratio below the frame-size it can receive - should decode any resolution below the max frame size - The renderer is free to chose display size In addition to frame-size and aspects-ratio there are a large number of other parameters that could be negotiated in SDP and I do not think we should duplicate those in the CLUE-requirement documentation. Should we drop REQ 6, 7, 8 and instead refer to SDP mechanisms for negotiating video and audio parameters? Cheers -Espen -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) Sent: 20. juni 2011 01:45 To: Elwell, John; clue@ietf.org Subject: Re: [clue] Comment on requirements-03 - aspect ratio Hi John, Thanks for your comments. I agree with them. Aspect ratio is not part of ordering, and should be a separate requirement, not part of Reqmt 1. Reqmt 6 which says The solution MUST support means of enabling interoperability between telepresence endpoints where cameras are of different aspect ratios. Certainly includes supporting communicating information about aspect ratio, which is what 1c says. Also, 1d, on supporting multi-view, as described in use cases, could be pulled out of 1 and made a separate requirement as well. I propose making these changes. How is that? Regards, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Elwell, John > Sent: Wednesday, June 15, 2011 9:30 AM > To: clue@ietf.org > Subject: [clue] Comment on requirements-03 - aspect ratio > > We have: > "REQMT-1: The solution MUST support a description of the spatial > arrangement of source video images sent in video streams > which enables a satisfactory reproduction at the receiver > of the original scene. This applies to each site in a > point to point or a multipoint meeting and refers to the > spatial ordering within a site, not to the ordering of > images between sites." > and below that: > "REQMT-1c: The solution MUST support a means to > communicate the aspect ratio." > Is this the aspect ratio of a particular camera? If so, what is the > relevance of this to REQMT-1, which is concerned with the spatial > ordering of video images? Also REQMT-6 addresses aspect ratios, so how > does REQMT-1c relate to REQMT-6? > > John > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CC300A.E199F002 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We can add support for full-size display a sub-point to REQ-1. =

 

-Espen

 

 

From:= Stephen = Botzko [mailto:stephen.botzko@gmail.com]
Sent: 20. juni 2011 = 16:11
To: Espen Berger (espeberg)
Cc: Allyn Romanow = (allyn); Elwell, John; clue@ietf.org
Subject: Re: [clue] = Comment on requirements-03 - aspect ratio

 

Aspect Ratio creates some unique issues = with multiple displays, especially if the aspect ratio of the received = pictures do not match the physical displays.  This is shown in the = use cases.  So the H.264 decoder rules are not sufficient to get = the behavior we want here.

Similarly, the solution needs to = enable display of far-end participants at the proper apparent = size.  Again, H.264 decoder rules do not cover this.  = Requirements 6-8  were intended to fill the gap.  However, we = seem to have lost the "actual size" display (called = "full-sized display" in the use cases draft) in the current = formulation.  This needs to be fixed, as the ability to match the = visual scale of the incoming video is an important aspect of the = solution.

Regards,
Stephen = Botzko



On Mon, = Jun 20, 2011 at 8:04 AM, Espen Berger (espeberg) <espeberg@cisco.com> = wrote:

I did not fully understand the = reason for REQ-6, REQ-7 and REQ-8. These
requirements are already = covered in current decode rules for H.264
video. A = decoder:
 - should decode any aspect-ratio below the frame-size = it can receive
 - should decode any resolution below the max = frame size
 - The renderer is free to chose display = size

In addition to frame-size and aspects-ratio there are a = large number of
other parameters that could be negotiated in SDP and = I do not think we
should duplicate those in the CLUE-requirement = documentation.

Should we drop REQ 6, 7, 8 and instead refer to = SDP mechanisms for
negotiating video and audio = parameters?

Cheers

-Espen


-----Original Message-----
From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On = Behalf Of

Allyn Romanow = (allyn)
Sent: 20. juni 2011 01:45

To: Elwell, John; clue@ietf.org

Subject: Re: [clue] Comment on requirements-03 - = aspect ratio


Hi = John,
Thanks for your comments.
I agree with them.

Aspect = ratio is not part of ordering, and should be a separate
requirement, = not part of Reqmt 1. Reqmt 6 which says The solution MUST
support = means of enabling
            =  interoperability between telepresence endpoints where
  =            cameras are of different aspect = ratios.
Certainly includes supporting communicating information about = aspect
ratio, which is what 1c says.

Also, 1d, on supporting = multi-view, as described in use cases, could be
pulled out of 1 and = made a separate requirement as well.

I propose making these = changes. How is that?

Regards,
Allyn

> -----Original = Message-----
> From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On = Behalf
Of
> Elwell, John
> Sent: Wednesday, June 15, 2011 = 9:30 AM
> To: clue@ietf.org
> Subject: [clue] = Comment on requirements-03 - aspect ratio
>
> We = have:
> "REQMT-1:   The solution MUST support a = description of the spatial
>           =     arrangement of source video images sent in video = streams
>               which = enables a satisfactory reproduction at the
receiver
>   =             of the original scene. =  This applies to each site in a
>         =       point to point or a multipoint meeting and refers = to the
>               spatial = ordering within a site, not to the ordering of
>     =           images between sites."
> = and below that:
> "REQMT-1c:  The solution MUST support = a means to
>               =            communicate the aspect = ratio."
> Is this the aspect ratio of a particular camera? If = so, what is the
> relevance of this to REQMT-1, which is concerned = with the spatial
> ordering of video images? Also REQMT-6 = addresses aspect ratios, so how
> does REQMT-1c relate to = REQMT-6?
>
> John
> = _______________________________________________
> clue mailing = list
> clue@ietf.org
> = https://www.ietf.org/mailman/listinfo/clue
_____= __________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue
_____= __________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

------_=_NextPart_001_01CC300A.E199F002-- From pkyzivat@cisco.com Tue Jun 21 05:40:15 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFAE11E808F for ; Tue, 21 Jun 2011 05:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.163 X-Spam-Level: X-Spam-Status: No, score=-110.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOuA2w31-DBv for ; Tue, 21 Jun 2011 05:40:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 391E211E80E2 for ; Tue, 21 Jun 2011 05:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=11364; q=dns/txt; s=iport; t=1308660014; x=1309869614; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NqYNQmB3Y0UQ86JA4DE5yqMSh+kY3/2FoV2XcER2N3I=; b=SpCAsUHT6SRpcQU8bckcNc8jG1x6X86K8vZKjuyhxwqttA0kwDdDRtd+ dKEcnBONNQwI3UmwN/1oqU9gE9R7/xao4VvS0S89oe4hYiJU2MUxWV+hq LBlTM9mizrv7ugHcWzM3v9iBcD9EmZqYwg2z9vua7oM3BcMLKp++tqSUj U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAA6QAE6tJV2a/2dsb2JhbABUl1uPE3eIc6FZnkSGKgSRZoRii0A X-IronPort-AV: E=Sophos;i="4.65,401,1304294400"; d="scan'208";a="718501639" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 21 Jun 2011 12:40:13 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5LCeCg5020332; Tue, 21 Jun 2011 12:40:12 GMT Message-ID: <4E00912C.4080301@cisco.com> Date: Tue, 21 Jun 2011 08:40:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <4DFFC5B4.3070202@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB5336B89@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB5336B89@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 12:40:15 -0000 On 6/21/2011 4:22 AM, Christer Holmberg wrote: > > Hi Paul, > >>> I think that you are proposing that CLUE needs a mechanism to pass >>> information, such as a tag, on "rendering type", for example, >>> binaural, threshold, etc. >>> Is that correct? >> >> How does this differ from simply making an offer with the >> audio codec and parameters that you want to use? > > Assuming we would use an SDP element (e.g. an SDP attribute) to indicate the rendering-type, there should be no difference. I'm sure I don't fully understand this. I *gather* that what you are after is a single audio media stream that carries a left and right channel (stereo). And that in addition there is some specialized audio processing of original sources to determine what is presented in the left and right channel. So, one question is whether that specialized processing is separable from the encoding and delivery of the media stream via a codec. (E.g. could that specialized processing be used with a variety of codecs, or is it intrinsically linked to a particular codec?) The answer to that will impact how it is represented in SDP, and probably the sort of work that would be required to get it standardized. But regardless, do you agree that this is fundamentally distinct from telepresence, and something that belongs in SDP, one way or another? Thanks, Paul > Regards, > > Christer > > > >>> And that you are not asking for any more from CLUE than simply >>> identifying the rendering type. >>> Is that correct? >>> >>> IF both of these statements are correct, than personally I >> think it is >>> fine TO include the information of rendering type, such as >> "binaural", >>> by some mechanism, such as a tag, AS LONG AS there is an >> accepted Use >>> Case that shows the necessity of communicating the rendering type, >>> such as "thresholding" or "panning". >>> >>> How do other people feel about this? >>> >>> Thanks, >>> Allyn >>> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Monday, June 20, 2011 12:23 PM >>> To: Allyn Romanow (allyn); Mary Barnes >>> Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) >>> Subject: RE: [clue] Requirement on centralized media mixing >>> >>> Hi Allyn, >>> >>>> Still trying to get clarification- >>>> >>>> I read your description of various types of rendering. >>>> Still trying to understand what you want from CLUE- If we >> have a tag >>>> that says "binaural" or stereo, sub binaural, are we done? >>> >>> Of course we could have a binaural specific SDP attribute, e.g. >>> a=binaural. >>> >>> But, again, what we are proposing is a general mechanism, >> that could >>> look something like: >>> >>> a=rendering-type = >>> >>> could then e.g. be "binaural", but it could also >> be something >>> else (we showed a few example in the e-mail). >>> >>>> Or do you want CLUE to describe how to do some kind of >> rendering? To >>> say >>>> something more about specific rendering functions? >>> >>> No, CLUE doesn't need to say anything about that. >>> >>> There would of course need to be a rendering description associated >>> with each rendering type value, but CLUE wouldn't define those. >>> >>> The idea is that an IANA registry is created, where people can >>> register their rendering type values. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Sunday, June 19, 2011 10:29 PM >>>> To: Allyn Romanow (allyn); Mary Barnes >>>> Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) >>>> Subject: RE: [clue] Requirement on centralized media mixing >>>> >>>> >>>> Hi Allyn, >>>> >>>> I appologise that it took some time to reply. >>>> >>>> We've been working on some definition/example text (I sent >> it to the >>>> list just a few minutes ago), which I hope will clarify >> some of the >>>> questions that have been asked. >>>> >>>>> Also, what kind of support are you asking for binaural? I believe >>> it's >>>> often considered as a subset of stereo. What are you asking for? A >>>> simple tag that says "binaural", or the specification >>>>> of a rendering system for binaural? Precisely what are asking for? >>>> >>>> From CLUE, we are only asking for a general mechanism to >> request and >>>> indicate different rendering types (see definition in >> other e-mail). >>>> >>>> An example of such rendering type is binaural, BUT we are *NOT* >>>> asking CLUE to define any binaural specific SDP attributes etc. If >>>> such are needed, we agree that it needs to be done as a >> separate task. >>>> >>>> Before I try to answer your other questions, please take a look at >>>> the definition/example e-mail, which I hope will clarify >> what we mean >>>> by rendering and rendering type. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi Christer - >>>> >>>> In spirit I am enthusiastic about what you are proposing >>> (meaning >>>> good quality mobile participation). I'm not clear on how >> the spirit >>>> becomes instantiated in our protocol, so I have some >> questions below >>>> J >>>> >>>> Thanks, >>>> >>>> Allyn >>>> >>>> >>>> >>>> From: clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org] On >>>> Behalf Of Christer Holmberg >>>> Sent: Tuesday, June 14, 2011 7:23 AM >>>> To: clue@ietf.org >>>> Subject: [clue] Requirement on centralized media mixing >>>> >>>> >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> During the last interim meeting (May 12th) we discussed a >>>> requirement proposal >>>> >>>> stating that an endpoint must be able to request >> central audio >>>> rendering >>>> >>>> of different predefined formats, including 3D binaural >>> rendering. >>>> >>>> (Link to proposal: http://www.ietf.org/mail- >>>> archive/web/clue/current/msg00179.html) >>>> >>>> >>>> >>>> The proposal was well received, with the >> reservation that it >>>> should not be mandatory >>>> >>>> for the solution to implement centralized 3D binaural >>>> rendering, i.e.an endpoint should >>>> >>>> be able to request 3D binaural rendering, but had >> no guaranty >>>> that such rendering was >>>> >>>> supported by the system. >>>> >>>> >>>> >>>> It was decided to look how such requirement could look like. >>>> >>>> >>>> >>>> When I look the -03 version of the req draft, Requirement 2c >>>> states: >>>> >>>> >>>> >>>> "The solution MUST NOT preclude the use of >> binaural audio." >>>> >>>> >>>> >>>> I think that requirement is unclear, and it doesn't really >>>> give any guidance to our work. >>>> >>>> >>>> >>>> Due to that, and also due to the fact that rather >> than talking >>>> about specific rendering types, >>>> >>>> I would like to propose more general requirement >> text on the >>>> negotiation of the media mixing type, >>>> >>>> and the usage of centralized media mixing in the >> first place. >>>> >>>> >>>> >>>> The mechanism would be extendable, so new types can >> be added >>>> in future. >>>> >>>> >>>> >>>> So, the proposed requirements are: >>>> >>>> >>>> >>>> REQ-x: It MUST be possible to negotiate the usage of >>>> centralized media mixing. System support of centralized >> media mixing >>> is >>>> optional. >>>> >>>> >>>> >>>> REQ-y: When centralized media mixing is used, it MUST be >>>> possible to negotiate the type of media rendering provided >> for each >>>> media stream received by a client. >>>> >>>> --- >>>> >>>> [ar] I have a few questions/comments: >>>> >>>> 1. The term "negotiate" troubles me as I >> think it means >>> a >>>> particular form of communication that dictates the >> solution. What is >>>> being asked for is the receiver to know that it is receiving >>>> "centralized media mixing". This may not be the end product of a >>>> negotiation. The same is true of the use of the term >> negotiate in the >>>> second requirement. What is needed is a mechanism by which the >>> receiver >>>> may know what type of "media rendering" is being received. >>>> >>>> So, I'd rather offer, The solution must >> support a means >>>> for identifying a stream which is "centralized media mixing". >>>> >>>> And, When "centralized media mixing" is used, the solution >>>> must support a means for identifying... >>>> >>>> >>>> >>>> 2. Also, I'm not too sure what "media >> rendering", the >>>> phrase in the second reqmt, represents- SDP and RTP >> recognize audio >>>> channels and recognize codecs. Is this what is referred to >> as "media >>>> rendering"? Or is it something different? What very specifically? >>>> >>>> >>>> >>>> 3. After reading more of the discussion, I >> realize that I >>>> don't fully understand what is meant in the first reqmt by >>> "centralized >>>> media mixing" or "rendering", which term is used in >> another email. I >>>> had thought you meant the usual audio mixing such as >> discussed in RFC >>>> 5117.( I figured it was an understood part of the topology >> so didn't >>>> need to be called out in particular. But I don't mind calling it >>> out.) >>>> In any case, now I'm not sure what you mean, maybe it is something >>>> other than typical MCU mixing behavior as described in RFC 5117? >>>> >>>> >>>> >>>> 4. As for the discussion of binaural.. here is what it >>>> seems like to me.. AVP, RFC 3551 specifies the number of audio >>>> channels, what they refer to, and types of codecs. Binaural is >>>> neither. As you say, Christer, it's a type of stereo >> channel. Steve >>>> feels that "binaural" must be recognized in SDP, which of >> course, it >>> is >>>> not currently. >>>> >>>> >>>> >>>> I'm not entirely sure what needs to be specified about >>>> binaural, given that it is neither channel -type nor >> codec-type. What >>>> needs to >>> be >>>> standardized? This question is probably more for Steve, or both of >>> you. >>>> If the receiving device knows it's getting binaural stereo, then it >>> can >>>> run some algorithms to improve quality and if it isn't >> binaural, it >>>> won't run those algs., or something analogous? If that is >> the case, I >>>> don't see what needs to be standardized that isn't already >>>> standardized... But I'm eager to learn. >>>> >>>> >>>> >>>> Thanks- >>>> >>>> Allyn >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> Christer >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> From christer.holmberg@ericsson.com Tue Jun 21 05:57:15 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A6B11E808D for ; Tue, 21 Jun 2011 05:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnrGtHsvYWUT for ; Tue, 21 Jun 2011 05:57:14 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D38C511E8083 for ; Tue, 21 Jun 2011 05:57:13 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-14-4e009528a9de Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4C.7B.09774.825900E4; Tue, 21 Jun 2011 14:57:13 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 21 Jun 2011 14:57:10 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 21 Jun 2011 14:57:09 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: AcwwEF/SzoZBFxbVTViloOg8yKz+QwAACYbQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB5336E7F@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <4DFFC5B4.3070202@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB5336B89@ESESSCMS0356.eemea.ericsson.se> <4E00912C.4080301@cisco.com> In-Reply-To: <4E00912C.4080301@cisco.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 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 12:57:15 -0000 Hi Paul,=20 >>>> I think that you are proposing that CLUE needs a=20 >>>> mechanism to pass information, such as a tag, on "rendering type", for= example,=20 >>>> binaural, threshold, etc. >>>> Is that correct? >>> >>> How does this differ from simply making an offer with the=20 >>> audio codec and parameters that you want to use? >> >> Assuming we would use an SDP element (e.g. an SDP=20 >> attribute) to indicate the rendering-type, there should be no=20 >> difference. >=20 >I'm sure I don't fully understand this. >I *gather* that what you are after is a single audio media=20 >stream that carries a left and right channel (stereo). > >And that in addition there is some specialized audio processing=20 >of original sources to determine what is presented in the=20 >left and right channel. In the audio binaural case, yes, but it of course depends on the media type= etc. But, again, CLUE would not define what the processing is.=20 (CLUE would only define what information is needed when one registers a ren= dering type, associated with an algorithm, with IANA.) >So, one question is whether that specialized processing is=20 >separable from the encoding and delivery of the media stream=20 >via a codec. (E.g. could that specialized processing be used with a variet= y of=20 >codecs, or is it intrinsically linked to a particular codec?)=20 It is not linked to a particular codec. >The answer to that will impact how it is represented in SDP,=20 >and probably the sort of work that would be required to get=20 >it standardized. >=20 >But regardless, do you agree that this is fundamentally=20 >distinct from telepresence, and something that belongs in=20 >SDP, one way or another? What we are discussing now are requirements (eventhough I know we have used= SDP terminology in order to better describe the mechanism, and at the mome= nt it seems quite clear that SDP would be the best solution). The actual definition of the an attribute might then take place elsewhere, = e.g. in MMUSIC. But, the CLUE requirements don't need to care about that. Regards, Christer > >>> And that you are not asking for any more from CLUE than simply=20 > >>> identifying the rendering type. > >>> Is that correct? > >>> > >>> IF both of these statements are correct, than personally I > >> think it is > >>> fine TO include the information of rendering type, such as > >> "binaural", > >>> by some mechanism, such as a tag, AS LONG AS there is an > >> accepted Use > >>> Case that shows the necessity of communicating the=20 > rendering type,=20 > >>> such as "thresholding" or "panning". > >>> > >>> How do other people feel about this? > >>> > >>> Thanks, > >>> Allyn > >>> > >>> -----Original Message----- > >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>> Sent: Monday, June 20, 2011 12:23 PM > >>> To: Allyn Romanow (allyn); Mary Barnes > >>> Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > >>> Subject: RE: [clue] Requirement on centralized media mixing > >>> > >>> Hi Allyn, > >>> > >>>> Still trying to get clarification- > >>>> > >>>> I read your description of various types of rendering. > >>>> Still trying to understand what you want from CLUE- If we > >> have a tag > >>>> that says "binaural" or stereo, sub binaural, are we done? > >>> > >>> Of course we could have a binaural specific SDP attribute, e.g. > >>> a=3Dbinaural. > >>> > >>> But, again, what we are proposing is a general mechanism, > >> that could > >>> look something like: > >>> > >>> a=3Drendering-type =3D > >>> > >>> could then e.g. be "binaural", but it could also > >> be something > >>> else (we showed a few example in the e-mail). > >>> > >>>> Or do you want CLUE to describe how to do some kind of > >> rendering? To > >>> say > >>>> something more about specific rendering functions? > >>> > >>> No, CLUE doesn't need to say anything about that. > >>> > >>> There would of course need to be a rendering description=20 > associated=20 > >>> with each rendering type value, but CLUE wouldn't define those. > >>> > >>> The idea is that an IANA registry is created, where people can=20 > >>> register their rendering type values. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>>> Sent: Sunday, June 19, 2011 10:29 PM > >>>> To: Allyn Romanow (allyn); Mary Barnes > >>>> Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > >>>> Subject: RE: [clue] Requirement on centralized media mixing > >>>> > >>>> > >>>> Hi Allyn, > >>>> > >>>> I appologise that it took some time to reply. > >>>> > >>>> We've been working on some definition/example text (I sent > >> it to the > >>>> list just a few minutes ago), which I hope will clarify > >> some of the > >>>> questions that have been asked. > >>>> > >>>>> Also, what kind of support are you asking for binaural?=20 > I believe > >>> it's > >>>> often considered as a subset of stereo. What are you=20 > asking for? A=20 > >>>> simple tag that says "binaural", or the specification > >>>>> of a rendering system for binaural? Precisely what are=20 > asking for? > >>>> > >>>> From CLUE, we are only asking for a general mechanism to > >> request and > >>>> indicate different rendering types (see definition in > >> other e-mail). > >>>> > >>>> An example of such rendering type is binaural, BUT we are *NOT*=20 > >>>> asking CLUE to define any binaural specific SDP=20 > attributes etc. If=20 > >>>> such are needed, we agree that it needs to be done as a > >> separate task. > >>>> > >>>> Before I try to answer your other questions, please take=20 > a look at=20 > >>>> the definition/example e-mail, which I hope will clarify > >> what we mean > >>>> by rendering and rendering type. > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Hi Christer - > >>>> > >>>> In spirit I am enthusiastic about what you are proposing > >>> (meaning > >>>> good quality mobile participation). I'm not clear on how > >> the spirit > >>>> becomes instantiated in our protocol, so I have some > >> questions below > >>>> J > >>>> > >>>> Thanks, > >>>> > >>>> Allyn > >>>> > >>>> > >>>> > >>>> From: clue-bounces@ietf.org > >> [mailto:clue-bounces@ietf.org] On > >>>> Behalf Of Christer Holmberg > >>>> Sent: Tuesday, June 14, 2011 7:23 AM > >>>> To: clue@ietf.org > >>>> Subject: [clue] Requirement on centralized media mixing > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Hi, > >>>> > >>>> > >>>> > >>>> During the last interim meeting (May 12th) we=20 > discussed a=20 > >>>> requirement proposal > >>>> > >>>> stating that an endpoint must be able to request > >> central audio > >>>> rendering > >>>> > >>>> of different predefined formats, including 3D binaural > >>> rendering. > >>>> > >>>> (Link to proposal: http://www.ietf.org/mail- > >>>> archive/web/clue/current/msg00179.html) > >>>> > >>>> > >>>> > >>>> The proposal was well received, with the > >> reservation that it > >>>> should not be mandatory > >>>> > >>>> for the solution to implement centralized 3D binaural=20 > >>>> rendering, i.e.an endpoint should > >>>> > >>>> be able to request 3D binaural rendering, but had > >> no guaranty > >>>> that such rendering was > >>>> > >>>> supported by the system. > >>>> > >>>> > >>>> > >>>> It was decided to look how such requirement=20 > could look like. > >>>> > >>>> > >>>> > >>>> When I look the -03 version of the req draft,=20 > Requirement=20 > >>>> 2c > >>>> states: > >>>> > >>>> > >>>> > >>>> "The solution MUST NOT preclude the use of > >> binaural audio." > >>>> > >>>> > >>>> > >>>> I think that requirement is unclear, and it=20 > doesn't really=20 > >>>> give any guidance to our work. > >>>> > >>>> > >>>> > >>>> Due to that, and also due to the fact that rather > >> than talking > >>>> about specific rendering types, > >>>> > >>>> I would like to propose more general requirement > >> text on the > >>>> negotiation of the media mixing type, > >>>> > >>>> and the usage of centralized media mixing in the > >> first place. > >>>> > >>>> > >>>> > >>>> The mechanism would be extendable, so new types can > >> be added > >>>> in future. > >>>> > >>>> > >>>> > >>>> So, the proposed requirements are: > >>>> > >>>> > >>>> > >>>> REQ-x: It MUST be possible to negotiate the usage of > >>>> centralized media mixing. System support of centralized > >> media mixing > >>> is > >>>> optional. > >>>> > >>>> > >>>> > >>>> REQ-y: When centralized media mixing is used,=20 > it MUST be > >>>> possible to negotiate the type of media rendering provided > >> for each > >>>> media stream received by a client. > >>>> > >>>> --- > >>>> > >>>> [ar] I have a few questions/comments: > >>>> > >>>> 1. The term "negotiate" troubles me as I > >> think it means > >>> a > >>>> particular form of communication that dictates the > >> solution. What is > >>>> being asked for is the receiver to know that it is receiving=20 > >>>> "centralized media mixing". This may not be the end product of a=20 > >>>> negotiation. The same is true of the use of the term > >> negotiate in the > >>>> second requirement. What is needed is a mechanism by which the > >>> receiver > >>>> may know what type of "media rendering" is being received. > >>>> > >>>> So, I'd rather offer, The solution must > >> support a means > >>>> for identifying a stream which is "centralized media mixing". > >>>> > >>>> And, When "centralized media mixing" is used,=20 > the solution=20 > >>>> must support a means for identifying... > >>>> > >>>> > >>>> > >>>> 2. Also, I'm not too sure what "media > >> rendering", the > >>>> phrase in the second reqmt, represents- SDP and RTP > >> recognize audio > >>>> channels and recognize codecs. Is this what is referred to > >> as "media > >>>> rendering"? Or is it something different? What very specifically? > >>>> > >>>> > >>>> > >>>> 3. After reading more of the discussion, I > >> realize that I > >>>> don't fully understand what is meant in the first reqmt by > >>> "centralized > >>>> media mixing" or "rendering", which term is used in > >> another email. I > >>>> had thought you meant the usual audio mixing such as > >> discussed in RFC > >>>> 5117.( I figured it was an understood part of the topology > >> so didn't > >>>> need to be called out in particular. But I don't mind calling it > >>> out.) > >>>> In any case, now I'm not sure what you mean, maybe it is=20 > something=20 > >>>> other than typical MCU mixing behavior as described in RFC 5117? > >>>> > >>>> > >>>> > >>>> 4. As for the discussion of binaural..=20 > here is what it > >>>> seems like to me.. AVP, RFC 3551 specifies the number of audio=20 > >>>> channels, what they refer to, and types of codecs. Binaural is=20 > >>>> neither. As you say, Christer, it's a type of stereo > >> channel. Steve > >>>> feels that "binaural" must be recognized in SDP, which of > >> course, it > >>> is > >>>> not currently. > >>>> > >>>> > >>>> > >>>> I'm not entirely sure what needs to be specified about=20 > >>>> binaural, given that it is neither channel -type nor > >> codec-type. What > >>>> needs to > >>> be > >>>> standardized? This question is probably more for Steve,=20 > or both of > >>> you. > >>>> If the receiving device knows it's getting binaural=20 > stereo, then it > >>> can > >>>> run some algorithms to improve quality and if it isn't > >> binaural, it > >>>> won't run those algs., or something analogous? If that is > >> the case, I > >>>> don't see what needs to be standardized that isn't already=20 > >>>> standardized... But I'm eager to learn. > >>>> > >>>> > >>>> > >>>> Thanks- > >>>> > >>>> Allyn > >>>> > >>>> > >>>> > >>>> Regards, > >>>> > >>>> > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > = From pkyzivat@cisco.com Tue Jun 21 06:44:17 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B163411E8092 for ; Tue, 21 Jun 2011 06:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.159 X-Spam-Level: X-Spam-Status: No, score=-110.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJGdeQf-IFmy for ; Tue, 21 Jun 2011 06:44:16 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 72C4B11E8078 for ; Tue, 21 Jun 2011 06:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=13642; q=dns/txt; s=iport; t=1308663856; x=1309873456; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PU/gyY49X0hsTABkLXsm7NKrkUkybb8mQUmAX2NFH58=; b=YchESw0JcExQZGmcjEy4OtiBUjIL/UFn+FnFDEvZ6MbYT7wLY3HQIBZ5 FAyG5usvMThJqbjGdlam09V7CRIBOMPJ6nXv72dfnt92/aDGRZJmLI45q 38NNtaAwsjw5rl0XhZ3UebBD5VzpPS19ky5TFURLaGZcOeKMNqMjH8Ksz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAEyfAE6tJXHB/2dsb2JhbABUl1yPE3eqbJ5DhioEkWaEYotA X-IronPort-AV: E=Sophos;i="4.65,401,1304294400"; d="scan'208";a="358936880" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2011 13:44:15 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p5LDiEKw003292; Tue, 21 Jun 2011 13:44:15 GMT Message-ID: <4E00A02E.3080909@cisco.com> Date: Tue, 21 Jun 2011 09:44:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <4DFFC5B4.3070202@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB5336B89@ESESSCMS0356.eemea.ericsson.se> <4E00912C.4080301@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB5336E7F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB5336E7F@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 13:44:17 -0000 Christer, What I'm trying to discern is whether there is *anything* about the binaural capability that is specific to CLUE. ISTM that it would be equally likely that a UA with binaural capability would want to use that on a point to point audio call without CLUE, or a regular audio conference. I can best make sense of that in the context of codecs and codec parameters. But I sense you are viewing it as something else - some higher level of audio processing, independent of codec, that also has to be negotiated. AFAIK there is currently no such notion. If so, and that is what you need, then you should be taking it up with MMUSIC. Thanks, Paul On 6/21/2011 8:57 AM, Christer Holmberg wrote: > > Hi Paul, > >>>>> I think that you are proposing that CLUE needs a >>>>> mechanism to pass information, such as a tag, on "rendering type", for example, >>>>> binaural, threshold, etc. >>>>> Is that correct? >>>> >>>> How does this differ from simply making an offer with the >>>> audio codec and parameters that you want to use? >>> >>> Assuming we would use an SDP element (e.g. an SDP >>> attribute) to indicate the rendering-type, there should be no >>> difference. >> >> I'm sure I don't fully understand this. >> I *gather* that what you are after is a single audio media >> stream that carries a left and right channel (stereo). >> >> And that in addition there is some specialized audio processing >> of original sources to determine what is presented in the >> left and right channel. > > In the audio binaural case, yes, but it of course depends on the media type etc. > > But, again, CLUE would not define what the processing is. > > (CLUE would only define what information is needed when one registers a rendering type, associated with an algorithm, with IANA.) > >> So, one question is whether that specialized processing is >> separable from the encoding and delivery of the media stream >> via a codec. (E.g. could that specialized processing be used with a variety of >> codecs, or is it intrinsically linked to a particular codec?) > > It is not linked to a particular codec. > >> The answer to that will impact how it is represented in SDP, >> and probably the sort of work that would be required to get >> it standardized. >> >> But regardless, do you agree that this is fundamentally >> distinct from telepresence, and something that belongs in >> SDP, one way or another? > > What we are discussing now are requirements (eventhough I know we have used SDP terminology in order to better describe the mechanism, and at the moment it seems quite clear that SDP would be the best solution). > > The actual definition of the an attribute might then take place elsewhere, e.g. in MMUSIC. But, the CLUE requirements don't need to care about that. > > Regards, > > Christer > > > > > > > > >>>>> And that you are not asking for any more from CLUE than simply >>>>> identifying the rendering type. >>>>> Is that correct? >>>>> >>>>> IF both of these statements are correct, than personally I >>>> think it is >>>>> fine TO include the information of rendering type, such as >>>> "binaural", >>>>> by some mechanism, such as a tag, AS LONG AS there is an >>>> accepted Use >>>>> Case that shows the necessity of communicating the >> rendering type, >>>>> such as "thresholding" or "panning". >>>>> >>>>> How do other people feel about this? >>>>> >>>>> Thanks, >>>>> Allyn >>>>> >>>>> -----Original Message----- >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>> Sent: Monday, June 20, 2011 12:23 PM >>>>> To: Allyn Romanow (allyn); Mary Barnes >>>>> Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) >>>>> Subject: RE: [clue] Requirement on centralized media mixing >>>>> >>>>> Hi Allyn, >>>>> >>>>>> Still trying to get clarification- >>>>>> >>>>>> I read your description of various types of rendering. >>>>>> Still trying to understand what you want from CLUE- If we >>>> have a tag >>>>>> that says "binaural" or stereo, sub binaural, are we done? >>>>> >>>>> Of course we could have a binaural specific SDP attribute, e.g. >>>>> a=binaural. >>>>> >>>>> But, again, what we are proposing is a general mechanism, >>>> that could >>>>> look something like: >>>>> >>>>> a=rendering-type = >>>>> >>>>> could then e.g. be "binaural", but it could also >>>> be something >>>>> else (we showed a few example in the e-mail). >>>>> >>>>>> Or do you want CLUE to describe how to do some kind of >>>> rendering? To >>>>> say >>>>>> something more about specific rendering functions? >>>>> >>>>> No, CLUE doesn't need to say anything about that. >>>>> >>>>> There would of course need to be a rendering description >> associated >>>>> with each rendering type value, but CLUE wouldn't define those. >>>>> >>>>> The idea is that an IANA registry is created, where people can >>>>> register their rendering type values. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>>> Sent: Sunday, June 19, 2011 10:29 PM >>>>>> To: Allyn Romanow (allyn); Mary Barnes >>>>>> Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) >>>>>> Subject: RE: [clue] Requirement on centralized media mixing >>>>>> >>>>>> >>>>>> Hi Allyn, >>>>>> >>>>>> I appologise that it took some time to reply. >>>>>> >>>>>> We've been working on some definition/example text (I sent >>>> it to the >>>>>> list just a few minutes ago), which I hope will clarify >>>> some of the >>>>>> questions that have been asked. >>>>>> >>>>>>> Also, what kind of support are you asking for binaural? >> I believe >>>>> it's >>>>>> often considered as a subset of stereo. What are you >> asking for? A >>>>>> simple tag that says "binaural", or the specification >>>>>>> of a rendering system for binaural? Precisely what are >> asking for? >>>>>> >>>>>> From CLUE, we are only asking for a general mechanism to >>>> request and >>>>>> indicate different rendering types (see definition in >>>> other e-mail). >>>>>> >>>>>> An example of such rendering type is binaural, BUT we are *NOT* >>>>>> asking CLUE to define any binaural specific SDP >> attributes etc. If >>>>>> such are needed, we agree that it needs to be done as a >>>> separate task. >>>>>> >>>>>> Before I try to answer your other questions, please take >> a look at >>>>>> the definition/example e-mail, which I hope will clarify >>>> what we mean >>>>>> by rendering and rendering type. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hi Christer - >>>>>> >>>>>> In spirit I am enthusiastic about what you are proposing >>>>> (meaning >>>>>> good quality mobile participation). I'm not clear on how >>>> the spirit >>>>>> becomes instantiated in our protocol, so I have some >>>> questions below >>>>>> J >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Allyn >>>>>> >>>>>> >>>>>> >>>>>> From: clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org] On >>>>>> Behalf Of Christer Holmberg >>>>>> Sent: Tuesday, June 14, 2011 7:23 AM >>>>>> To: clue@ietf.org >>>>>> Subject: [clue] Requirement on centralized media mixing >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> During the last interim meeting (May 12th) we >> discussed a >>>>>> requirement proposal >>>>>> >>>>>> stating that an endpoint must be able to request >>>> central audio >>>>>> rendering >>>>>> >>>>>> of different predefined formats, including 3D binaural >>>>> rendering. >>>>>> >>>>>> (Link to proposal: http://www.ietf.org/mail- >>>>>> archive/web/clue/current/msg00179.html) >>>>>> >>>>>> >>>>>> >>>>>> The proposal was well received, with the >>>> reservation that it >>>>>> should not be mandatory >>>>>> >>>>>> for the solution to implement centralized 3D binaural >>>>>> rendering, i.e.an endpoint should >>>>>> >>>>>> be able to request 3D binaural rendering, but had >>>> no guaranty >>>>>> that such rendering was >>>>>> >>>>>> supported by the system. >>>>>> >>>>>> >>>>>> >>>>>> It was decided to look how such requirement >> could look like. >>>>>> >>>>>> >>>>>> >>>>>> When I look the -03 version of the req draft, >> Requirement >>>>>> 2c >>>>>> states: >>>>>> >>>>>> >>>>>> >>>>>> "The solution MUST NOT preclude the use of >>>> binaural audio." >>>>>> >>>>>> >>>>>> >>>>>> I think that requirement is unclear, and it >> doesn't really >>>>>> give any guidance to our work. >>>>>> >>>>>> >>>>>> >>>>>> Due to that, and also due to the fact that rather >>>> than talking >>>>>> about specific rendering types, >>>>>> >>>>>> I would like to propose more general requirement >>>> text on the >>>>>> negotiation of the media mixing type, >>>>>> >>>>>> and the usage of centralized media mixing in the >>>> first place. >>>>>> >>>>>> >>>>>> >>>>>> The mechanism would be extendable, so new types can >>>> be added >>>>>> in future. >>>>>> >>>>>> >>>>>> >>>>>> So, the proposed requirements are: >>>>>> >>>>>> >>>>>> >>>>>> REQ-x: It MUST be possible to negotiate the usage of >>>>>> centralized media mixing. System support of centralized >>>> media mixing >>>>> is >>>>>> optional. >>>>>> >>>>>> >>>>>> >>>>>> REQ-y: When centralized media mixing is used, >> it MUST be >>>>>> possible to negotiate the type of media rendering provided >>>> for each >>>>>> media stream received by a client. >>>>>> >>>>>> --- >>>>>> >>>>>> [ar] I have a few questions/comments: >>>>>> >>>>>> 1. The term "negotiate" troubles me as I >>>> think it means >>>>> a >>>>>> particular form of communication that dictates the >>>> solution. What is >>>>>> being asked for is the receiver to know that it is receiving >>>>>> "centralized media mixing". This may not be the end product of a >>>>>> negotiation. The same is true of the use of the term >>>> negotiate in the >>>>>> second requirement. What is needed is a mechanism by which the >>>>> receiver >>>>>> may know what type of "media rendering" is being received. >>>>>> >>>>>> So, I'd rather offer, The solution must >>>> support a means >>>>>> for identifying a stream which is "centralized media mixing". >>>>>> >>>>>> And, When "centralized media mixing" is used, >> the solution >>>>>> must support a means for identifying... >>>>>> >>>>>> >>>>>> >>>>>> 2. Also, I'm not too sure what "media >>>> rendering", the >>>>>> phrase in the second reqmt, represents- SDP and RTP >>>> recognize audio >>>>>> channels and recognize codecs. Is this what is referred to >>>> as "media >>>>>> rendering"? Or is it something different? What very specifically? >>>>>> >>>>>> >>>>>> >>>>>> 3. After reading more of the discussion, I >>>> realize that I >>>>>> don't fully understand what is meant in the first reqmt by >>>>> "centralized >>>>>> media mixing" or "rendering", which term is used in >>>> another email. I >>>>>> had thought you meant the usual audio mixing such as >>>> discussed in RFC >>>>>> 5117.( I figured it was an understood part of the topology >>>> so didn't >>>>>> need to be called out in particular. But I don't mind calling it >>>>> out.) >>>>>> In any case, now I'm not sure what you mean, maybe it is >> something >>>>>> other than typical MCU mixing behavior as described in RFC 5117? >>>>>> >>>>>> >>>>>> >>>>>> 4. As for the discussion of binaural.. >> here is what it >>>>>> seems like to me.. AVP, RFC 3551 specifies the number of audio >>>>>> channels, what they refer to, and types of codecs. Binaural is >>>>>> neither. As you say, Christer, it's a type of stereo >>>> channel. Steve >>>>>> feels that "binaural" must be recognized in SDP, which of >>>> course, it >>>>> is >>>>>> not currently. >>>>>> >>>>>> >>>>>> >>>>>> I'm not entirely sure what needs to be specified about >>>>>> binaural, given that it is neither channel -type nor >>>> codec-type. What >>>>>> needs to >>>>> be >>>>>> standardized? This question is probably more for Steve, >> or both of >>>>> you. >>>>>> If the receiving device knows it's getting binaural >> stereo, then it >>>>> can >>>>>> run some algorithms to improve quality and if it isn't >>>> binaural, it >>>>>> won't run those algs., or something analogous? If that is >>>> the case, I >>>>>> don't see what needs to be standardized that isn't already >>>>>> standardized... But I'm eager to learn. >>>>>> >>>>>> >>>>>> >>>>>> Thanks- >>>>>> >>>>>> Allyn >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >> From eckelcu@cisco.com Tue Jun 21 08:46:06 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5559711E80AE for ; Tue, 21 Jun 2011 08:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8WPV-YGIV68 for ; Tue, 21 Jun 2011 08:46:05 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id B28E411E807E for ; Tue, 21 Jun 2011 08:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3131; q=dns/txt; s=iport; t=1308671165; x=1309880765; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=G6HlA6wRKiXlW5mNwbQIX5SheY0ooJfOosMOyW/NiBE=; b=TEt225T2Lv7hU5vuQY+DSYD3umoTtZxP2rm0y5IQt+su85O4Bt8BYlmo VJz1kd6DGTQtQ9uTJGuK6LDznyYre9bgiwpi2cE/uIHDd7JLJSt8Kcv1r hpYoi8eeci6r8P5vALXyAImBO6nuLTWAo94AkukklL+n30rXs8CbwixJO Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAB28AE6rRDoI/2dsb2JhbABUl12PFHeqLZ5HhioEhyKPL4s7 X-IronPort-AV: E=Sophos;i="4.65,401,1304294400"; d="scan'208";a="382299920" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2011 15:46:01 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5LFk1Dv026682; Tue, 21 Jun 2011 15:46:01 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 08:46:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jun 2011 08:45:59 -0700 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Layout negotiation Thread-Index: AcwwATSD2MWMnBnxSh63CAep1FO53gAKB6nQ References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se> From: "Charles Eckel (eckelcu)" To: "Christer Holmberg" , X-OriginalArrivalTime: 21 Jun 2011 15:46:00.0929 (UTC) FILETIME=[51FE6D10:01CC302A] Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:46:06 -0000 Hi Christer, I think I was the one that brought up layouts originally. I was more concerned with video layouts than audio layouts. Currently, the requirements draft seems to focus more on audio layout/spatial audio. Requirements 3 and 16 both deal with parts of this. I feel there needs to be more clear requirements on the ability for the to represent the potential layouts of the audio/video can that be offered. For example, I have 3 camera and 3 mics. I can provide: 1) 3 individual video each with corresponding audio 2) 1 active speaker only switched video with mixed audio 3) 1 composed video including active speaker and 'n' non-active speakers (where 'n' is may be all or some fixed limit) and mixed audio If the receiving endpoint wants to control the layout itself, it goes with option 1. If it has limited resources/bandwidth/screens/etc it may prefer option 2 or 3. Cheers, Charles=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Tuesday, June 21, 2011 3:52 AM > To: clue@ietf.org > Subject: [clue] Layout negotiation >=20 > Hi, >=20 > A while ago there were some discussions about having requirements to negotiate the layout type, and at > least according to Stephen B it was within the scope of the work. >=20 > "The ability to negotiate an audio or video layout is clearly within scope, and has general > value it the group wants to take it on. > For instance, if you combine video switching of multiple sources with audio > mixing/transcoding, then the receiver is responsible > for the video layout but has no control over the audio layout. In that case, there are > advantages to allowing the receiver to tell the > central audio mixer where it wants the sources placed on the sound stage. I have no objection > in principle to adding that kind of > negotiation to the requirements, though I think the group should consider the impact on the > schedule." >=20 > However, I haven't seen any input after that. >=20 > My idea would be that it is very similar to the rendering type: CLUE defines a mechanism to negotiate > the layout type, but doesn't define specific types (instead an IANA registry would be created for > that). So, I don't think it would have any significant impact on our schedule. >=20 > Whether it, in addition to negotiation a layout type (which specifies the source locations), should be > possible for the user to more explicit place individual sources, as mentioned by Stephen, can be > discussed. However, that would probably require a little more work, so at least I would be happy with > a simple layout type negotiation at this point. >=20 > So, would people be ok with such requirement? >=20 > (Another alternative would be to "embed" the layout type into the rendering type, but I think that > would be very clumsy. Because, in that case you would need to define mulitple types for the same > rendering, but with different layouts.) >=20 > Regards, >=20 > Christer >=20 >=20 From stephen.botzko@gmail.com Tue Jun 21 09:20:53 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863C211E8154 for ; Tue, 21 Jun 2011 09:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJa0CDhtckNp for ; Tue, 21 Jun 2011 09:20:51 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48A7211E816F for ; Tue, 21 Jun 2011 09:20:51 -0700 (PDT) Received: by vxi40 with SMTP id 40so2037472vxi.31 for ; Tue, 21 Jun 2011 09:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fIkWsV4KunRLNsb+aWNFetB+/k4ycRHVoJa8m7PYyh8=; b=BvVqg1acrLq6X1yRLsazvmtAkkJQkwC4JGSopai3oDnVZQcTdNQAuCRn5G0Hx4UQc0 /Vdc7h1Gv4Onp62puVe7yq3eiV9mK+ULOKcPGhZwVyo62udZwDdsMVQEpZ5M9C1O3Evh 1iFq2P8Mb+alk5QItNbOg/wBjlyJdReNof3yU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fMV4O/LVkKu1f/KgzURR0AkVgoJ6080A4fLJ04+G00JJ5Qb9GW1qNS7MEtLUVhha7X CaiIctIjzRLa62oGZ4sy15TXnwdfrVxss3NS4O3uQCJSro0is3yaIRYM8Bv5+0rr/WjE fh4l2e5ASOHZwOIfv/SIeFyKtQMRJJl9mK3Lk= MIME-Version: 1.0 Received: by 10.52.160.68 with SMTP id xi4mr6273939vdb.106.1308673244227; Tue, 21 Jun 2011 09:20:44 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Tue, 21 Jun 2011 09:20:44 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> Date: Tue, 21 Jun 2011 12:20:44 -0400 Message-ID: From: Stephen Botzko To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=bcaec53f9779d96b6c04a63b3b08 Cc: clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:20:53 -0000 --bcaec53f9779d96b6c04a63b3b08 Content-Type: text/plain; charset=ISO-8859-1 I would like to see use cases, particularly for non-binaural proposals. It seems to me that a receiver doesn't really care if the stereo it is receiving is "panned", "plain" or "thresholded", or if it is linear or non-linear. So use cases motivating those choices would be helpful. Also, the proposal is for a specific mechanism ("rendering type"). It may be premature to identify the mechanism in the requirements - since often there are multiple ways to achieve the desired ends. Regards Steve B. On Mon, Jun 20, 2011 at 5:47 PM, Allyn Romanow (allyn) wrote: > > > Hi Christer, > > I think that you are proposing that CLUE needs a mechanism to pass > information, such as a tag, on "rendering type", for example, binaural, > threshold, etc. > Is that correct? > > And that you are not asking for any more from CLUE than simply > identifying the rendering type. > Is that correct? > > IF both of these statements are correct, than personally I think it is > fine TO include the information of rendering type, such as "binaural", > by some mechanism, such as a tag, AS LONG AS there is an accepted Use > Case that shows the necessity of communicating the rendering type, such > as "thresholding" or "panning". > > How do other people feel about this? > > Thanks, > Allyn > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 20, 2011 12:23 PM > To: Allyn Romanow (allyn); Mary Barnes > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on centralized media mixing > > Hi Allyn, > > >Still trying to get clarification- > > > >I read your description of various types of rendering. > >Still trying to understand what you want from CLUE- > >If we have a tag that says "binaural" or stereo, sub binaural, are we > >done? > > Of course we could have a binaural specific SDP attribute, e.g. > a=binaural. > > But, again, what we are proposing is a general mechanism, that could > look something like: > > a=rendering-type = > > could then e.g. be "binaural", but it could also be something > else (we showed a few example in the e-mail). > > >Or do you want CLUE to describe how to do some kind of rendering? To > say > >something more about specific rendering functions? > > No, CLUE doesn't need to say anything about that. > > There would of course need to be a rendering description associated with > each rendering type value, but CLUE wouldn't define those. > > The idea is that an IANA registry is created, where people can register > their rendering type values. > > Regards, > > Christer > > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Sunday, June 19, 2011 10:29 PM > > To: Allyn Romanow (allyn); Mary Barnes > > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > > Subject: RE: [clue] Requirement on centralized media mixing > > > > > > Hi Allyn, > > > > I appologise that it took some time to reply. > > > > We've been working on some definition/example text (I sent it to the > > list just a few minutes ago), which I hope will clarify some of the > > questions that have been asked. > > > > >Also, what kind of support are you asking for binaural? I believe > it's > > often considered as a subset of stereo. What are you asking for? A > > simple tag that says "binaural", or the specification > > >of a rendering system for binaural? Precisely what are asking for? > > > > From CLUE, we are only asking for a general mechanism to request and > > indicate different rendering types (see definition in other e-mail). > > > > An example of such rendering type is binaural, BUT we are *NOT* asking > > CLUE to define any binaural specific SDP attributes etc. If such are > > needed, we agree that it needs to be done as a separate task. > > > > Before I try to answer your other questions, please take a look at the > > definition/example e-mail, which I hope will clarify what we mean by > > rendering and rendering type. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Christer - > > > > In spirit I am enthusiastic about what you are proposing > (meaning > > good quality mobile participation). I'm not clear on how the spirit > > becomes instantiated in our protocol, so I have some questions below J > > > > Thanks, > > > > Allyn > > > > > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > Sent: Tuesday, June 14, 2011 7:23 AM > > To: clue@ietf.org > > Subject: [clue] Requirement on centralized media mixing > > > > > > > > > > > > Hi, > > > > > > > > During the last interim meeting (May 12th) we discussed a > > requirement proposal > > > > stating that an endpoint must be able to request central audio > > rendering > > > > of different predefined formats, including 3D binaural > rendering. > > > > (Link to proposal: http://www.ietf.org/mail- > > archive/web/clue/current/msg00179.html) > > > > > > > > The proposal was well received, with the reservation that it > > should not be mandatory > > > > for the solution to implement centralized 3D binaural rendering, > > i.e.an endpoint should > > > > be able to request 3D binaural rendering, but had no guaranty > > that such rendering was > > > > supported by the system. > > > > > > > > It was decided to look how such requirement could look like. > > > > > > > > When I look the -03 version of the req draft, Requirement 2c > > states: > > > > > > > > "The solution MUST NOT preclude the use of binaural audio." > > > > > > > > I think that requirement is unclear, and it doesn't really give > > any guidance to our work. > > > > > > > > Due to that, and also due to the fact that rather than talking > > about specific rendering types, > > > > I would like to propose more general requirement text on the > > negotiation of the media mixing type, > > > > and the usage of centralized media mixing in the first place. > > > > > > > > The mechanism would be extendable, so new types can be added in > > future. > > > > > > > > So, the proposed requirements are: > > > > > > > > REQ-x: It MUST be possible to negotiate the usage of > > centralized media mixing. System support of centralized media mixing > is > > optional. > > > > > > > > REQ-y: When centralized media mixing is used, it MUST be > > possible to negotiate the type of media rendering provided for each > > media stream received by a client. > > > > --- > > > > [ar] I have a few questions/comments: > > > > 1. The term "negotiate" troubles me as I think it means > a > > particular form of communication that dictates the solution. What is > > being asked for is the receiver to know that it is receiving > > "centralized media mixing". This may not be the end product of a > > negotiation. The same is true of the use of the term negotiate in the > > second requirement. What is needed is a mechanism by which the > receiver > > may know what type of "media rendering" is being received. > > > > So, I'd rather offer, The solution must support a means for > > identifying a stream which is "centralized media mixing". > > > > And, When "centralized media mixing" is used, the solution must > > support a means for identifying... > > > > > > > > 2. Also, I'm not too sure what "media rendering", the > > phrase in the second reqmt, represents- SDP and RTP recognize audio > > channels and recognize codecs. Is this what is referred to as "media > > rendering"? Or is it something different? What very specifically? > > > > > > > > 3. After reading more of the discussion, I realize that I > > don't fully understand what is meant in the first reqmt by > "centralized > > media mixing" or "rendering", which term is used in another email. I > > had thought you meant the usual audio mixing such as discussed in RFC > > 5117.( I figured it was an understood part of the topology so didn't > > need to be called out in particular. But I don't mind calling it > out.) > > In any case, now I'm not sure what you mean, maybe it is something > > other than typical MCU mixing behavior as described in RFC 5117? > > > > > > > > 4. As for the discussion of binaural.. here is what it > > seems like to me.. AVP, RFC 3551 specifies the number of audio > > channels, what they refer to, and types of codecs. Binaural is > > neither. As you say, Christer, it's a type of stereo channel. Steve > > feels that "binaural" must be recognized in SDP, which of course, it > is > > not currently. > > > > > > > > I'm not entirely sure what needs to be specified about binaural, > > given that it is neither channel -type nor codec-type. What needs to > be > > standardized? This question is probably more for Steve, or both of > you. > > If the receiving device knows it's getting binaural stereo, then it > can > > run some algorithms to improve quality and if it isn't binaural, it > > won't run those algs., or something analogous? If that is the case, I > > don't see what needs to be standardized that isn't already > > standardized... But I'm eager to learn. > > > > > > > > Thanks- > > > > Allyn > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec53f9779d96b6c04a63b3b08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would like to see use cases, particularly for non-binaural proposals.=A0 = It seems to me that a receiver doesn't really care if the stereo it is = receiving is "panned", "plain" or "thresholded&quo= t;, or if it is linear or non-linear. So use cases motivating those choices= would be helpful.

Also, the proposal is for a specific mechanism ("rendering type&qu= ot;).=A0 It may be premature to identify the mechanism in the requirements = - since often there are multiple ways to achieve the desired ends.

Regards
Steve B.

On Mon, Jun 20, 2011= at 5:47 PM, Allyn Romanow (allyn) <allyn@cisco.com> wrote:


Hi Christer,

I think that you are proposing that CLUE needs a mechanism to pass
information, such as a tag, on "rendering type", for example, bin= aural,
threshold, etc.
Is that correct?

And that you are not asking for any more from CLUE than simply
identifying the rendering type.
Is that correct?

IF both of these statements are correct, than personally I think it is
fine TO include the information of rendering type, such as "binaural&q= uot;,
by some mechanism, such as a tag, AS LONG AS there is an accepted Use
Case that shows the necessity of communicating the rendering type, such
as "thresholding" or "panning".

How do other people feel about this?

Thanks,
Allyn

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, June 20, 2011 12:23 PM
To: Allyn Romanow (allyn); Mary Barnes
Cc: clue@ietf.org; Botzko, Stephen; Bi= ll Mauchly (bmauchly)
Subject: RE: [clue] Requirement on centralized media mixing

Hi Allyn,

>Still trying to get clarification-
>
>I read your description of various types of rendering.
>Still trying to understand what you want from CLUE-
>If we have a tag that says "binaural" or stereo, sub binaural= , are we
>done?

Of course we could have a binaural specific SDP attribute, e.g.
a=3Dbinaural.

But, again, what we are proposing is a general mechanism, that could
look something like:

a=3Drendering-type =3D <value>

<value> could then e.g. be "binaural", but it could also be= something
else (we showed a few example in the e-mail).

>Or do you want CLUE to describe how to do some kind of rendering? To say
>something more about specific rendering functions?

No, CLUE doesn't need to say anything about that.

There would of course need to be a rendering description associated with each rendering type value, but CLUE wouldn't define those.

The idea is that an IANA registry is created, where people can register
their rendering type values.

Regards,

Christer



> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Sunday, June 19, 2011 10:29 PM
> To: Allyn Romanow (allyn); Mary Barnes
> Cc: clue@ietf.org; Botzko, Stephe= n; Bill Mauchly (bmauchly)
> Subject: RE: [clue] Requirement on centralized media mixing
>
>
> Hi Allyn,
>
> I appologise that it took some time to reply.
>
> We've been working on some definition/example text (I sent it to t= he
> list just a few minutes ago), which I hope will clarify some of the > questions that have been asked.
>
> >Also, what kind of support are you asking for binaural? I believe<= br> it's
> often considered as a subset of stereo. What are you asking for? A
> simple tag that says "binaural", or =A0the specification
> >of a rendering system for binaural? Precisely what are asking for?=
>
> From CLUE, we are only asking for a general mechanism to request and > indicate different rendering types (see definition in other e-mail). >
> An example of such rendering type is binaural, BUT we are *NOT* asking=
> CLUE to define any binaural specific SDP attributes etc. If such are > needed, we agree that it needs to be done as a separate task.
>
> Before I try to answer your other questions, please take a look at the=
> definition/example e-mail, which I hope will clarify what we mean by > rendering and rendering type.
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> =A0 =A0 =A0 Hi Christer -
>
> =A0 =A0 =A0 In spirit I am enthusiastic about what you are proposing (meaning
> good quality mobile participation). I'm not clear on how the spiri= t
> becomes instantiated in our protocol, so I have some questions below J=
>
> =A0 =A0 =A0 Thanks,
>
> =A0 =A0 =A0 Allyn
>
>
>
> =A0 =A0 =A0 From: clue-bounce= s@ietf.org [mailto:clue-bounce= s@ietf.org] On
> Behalf Of Christer Holmberg
> =A0 =A0 =A0 Sent: Tuesday, June 14, 2011 7:23 AM
> =A0 =A0 =A0 To: clue@ietf.org
> =A0 =A0 =A0 Subject: [clue] Requirement on centralized media mixing >
>
>
>
>
> =A0 =A0 =A0 Hi,
>
>
>
> =A0 =A0 =A0 During the last interim meeting (May 12th) we discussed a<= br> > requirement proposal
>
> =A0 =A0 =A0 stating that an endpoint must be able to request central a= udio
> rendering
>
> =A0 =A0 =A0 of different predefined formats, including 3D binaural
rendering.
>
> =A0 =A0 =A0 (Link to proposal: http://www.ietf.org/mail-
> archive/web/clue/current/msg00179.html)
>
>
>
> =A0 =A0 =A0 The proposal was well received, with the reservation that = it
> should not be mandatory
>
> =A0 =A0 =A0 for the solution to implement centralized 3D binaural rend= ering,
> i.e.an endpoint should=
>
> =A0 =A0 =A0 be able to request 3D binaural rendering, but had no guara= nty
> that such rendering was
>
> =A0 =A0 =A0 supported by the system.
>
>
>
> =A0 =A0 =A0 It was decided to look how such requirement could look lik= e.
>
>
>
> =A0 =A0 =A0 When I look the -03 version of the req draft, Requirement = 2c
> states:
>
>
>
> =A0 =A0 =A0 =A0 =A0 "The solution MUST NOT preclude the use of bi= naural audio."
>
>
>
> =A0 =A0 =A0 I think that requirement is unclear, and it doesn't re= ally give
> any guidance to our work.
>
>
>
> =A0 =A0 =A0 Due to that, and also due to the fact that rather than tal= king
> about specific rendering types,
>
> =A0 =A0 =A0 I would like to propose more general requirement text on t= he
> negotiation of the media mixing type,
>
> =A0 =A0 =A0 and the usage of centralized media mixing in the first pla= ce.
>
>
>
> =A0 =A0 =A0 The mechanism would be extendable, so new types can be add= ed in
> future.
>
>
>
> =A0 =A0 =A0 So, the proposed requirements are:
>
>
>
> =A0 =A0 =A0 REQ-x: =A0 =A0It MUST be possible to negotiate the usage o= f
> centralized media mixing. System support of centralized media mixing is
> optional.
>
>
>
> =A0 =A0 =A0 REQ-y: =A0 =A0When centralized media mixing is used, it MU= ST be
> possible to negotiate the type of media rendering provided for each > media stream received by a client.
>
> =A0 =A0 =A0 =A0---
>
> =A0 =A0 =A0 [ar] I have a few questions/comments:
>
> =A0 =A0 =A0 1. =A0 =A0 =A0 =A0 The term "negotiate" troubles= me as I think it means
a
> particular form of communication that dictates the solution. What is > being asked for is the receiver to know that it is receiving
> "centralized media mixing". This may not be the end product = of a
> negotiation. The same is true of the use of the term negotiate in the<= br> > second requirement. What is needed is a mechanism by which the
receiver
> may know what type of "media rendering" is being received. >
> =A0 =A0 =A0 =A0 =A0 =A0So, I'd rather offer, The solution must sup= port a means for
> identifying a stream which is "centralized media mixing". >
> =A0 =A0 =A0 And, When "centralized media mixing" is used, th= e solution must
> support a means for identifying...
>
>
>
> =A0 =A0 =A0 2. =A0 =A0 =A0 Also, =A0I'm not too sure what "me= dia rendering", =A0the
> phrase in the second reqmt, represents- SDP and RTP recognize audio > channels and recognize codecs. Is this what is referred to as "me= dia
> rendering"? Or is it something different? What very specifically?=
>
>
>
> =A0 =A0 =A0 3. =A0 =A0 =A0 After reading more of the discussion, I rea= lize that I
> don't fully understand what is meant in the first reqmt by
"centralized
> media mixing" or "rendering", which term is used in ano= ther email. I
> had thought you meant the usual audio mixing such as discussed in RFC<= br> > 5117.( I figured it was an understood part of the topology so didn'= ;t
> need to =A0be called out in particular. But I don't mind calling i= t
out.)
> In any case, now I'm not sure what you mean, maybe it is something=
> other than typical MCU mixing behavior as described in RFC 5117?
>
>
>
> =A0 =A0 =A0 4. =A0 =A0 =A0 As for the discussion of binaural.. here is= what it
> seems like to me.. AVP, RFC 3551 specifies =A0the number of =A0audio > channels, what they refer to, =A0and types of codecs. Binaural is
> neither. As you say, Christer, it's a type of stereo channel. =A0S= teve
> feels that "binaural" must be recognized in SDP, which of co= urse, it
is
> not currently.
>
>
>
> =A0 =A0 =A0 I'm not entirely sure what needs to be specified about= binaural,
> given that it is neither channel -type nor codec-type. What needs to be
> standardized? This question is probably more for Steve, or both of
you.
> If the receiving device knows it's getting binaural stereo, then i= t
can
> run some algorithms to improve quality and if it isn't binaural, i= t
> won't run those algs., or something analogous? If that is the case= , I
> don't see what needs to be standardized that isn't already
> standardized... But I'm eager to learn.
>
>
>
> =A0 =A0 =A0 Thanks-
>
> =A0 =A0 =A0 Allyn
>
>
>
> =A0 =A0 =A0 Regards,
>
>
>
> =A0 =A0 =A0 Christer
>
>
>
>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--bcaec53f9779d96b6c04a63b3b08-- From christer.holmberg@ericsson.com Tue Jun 21 11:08:25 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934EE11E817C for ; Tue, 21 Jun 2011 11:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz2mFU84NQoA for ; Tue, 21 Jun 2011 11:08:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7534F11E8153 for ; Tue, 21 Jun 2011 11:08:23 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-29-4e00de16ad5b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 58.CC.09774.61ED00E4; Tue, 21 Jun 2011 20:08:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 21 Jun 2011 20:08:22 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 21 Jun 2011 20:08:21 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: AcwwGVG+G1/ib4BTRz6cI+U+nPnTMwAI/1+H Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29B@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <4DFFC5B4.3070202@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB5336B89@ESESSCMS0356.eemea.ericsson.se> <4E00912C.4080301@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB5336E7F@ESESSCMS0356.eemea.ericsson.se>, <4E00A02E.3080909@cisco.com> In-Reply-To: <4E00A02E.3080909@cisco.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 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 18:08:25 -0000 Hi Paul, >What I'm trying to discern is whether there is *anything* about the >binaural capability that is specific to CLUE. > >ISTM that it would be equally likely that a UA with binaural capability >would want to use that on a point to point audio call without CLUE,=20 No. >or a regular audio conference. I guess it depends on what you mean by "regular". You do need some kind of = "virtual room" concept, where you place the different participants, and I d= on't think you normally have that in "regular" audio conferences. >I can best make sense of that in the context of codecs and codec parameter= s. But I sense you are viewing it as something else - some >higher level of audio processing, independent of codec, that also has to b= e negotiated. AFAIK there is currently no such notion. With SDP, you don't only negotiate codecs. You negotiate media streams, ide= ntified by the SDP m- line, and parameters (including codecs) associated wi= th those. For example, every SDP attribute has (or, at least should have) d= efined offer/answer procedures. And, IF we would use SDP for this, it would most likely be a media level at= tribute. Regards, Christer On 6/21/2011 8:57 AM, Christer Holmberg wrote: > > Hi Paul, > >>>>> I think that you are proposing that CLUE needs a >>>>> mechanism to pass information, such as a tag, on "rendering type", fo= r example, >>>>> binaural, threshold, etc. >>>>> Is that correct? >>>> >>>> How does this differ from simply making an offer with the >>>> audio codec and parameters that you want to use? >>> >>> Assuming we would use an SDP element (e.g. an SDP >>> attribute) to indicate the rendering-type, there should be no >>> difference. >> >> I'm sure I don't fully understand this. >> I *gather* that what you are after is a single audio media >> stream that carries a left and right channel (stereo). >> >> And that in addition there is some specialized audio processing >> of original sources to determine what is presented in the >> left and right channel. > > In the audio binaural case, yes, but it of course depends on the media ty= pe etc. > > But, again, CLUE would not define what the processing is. > > (CLUE would only define what information is needed when one registers a r= endering type, associated with an algorithm, with IANA.) > >> So, one question is whether that specialized processing is >> separable from the encoding and delivery of the media stream >> via a codec. (E.g. could that specialized processing be used with a vari= ety of >> codecs, or is it intrinsically linked to a particular codec?) > > It is not linked to a particular codec. > >> The answer to that will impact how it is represented in SDP, >> and probably the sort of work that would be required to get >> it standardized. >> >> But regardless, do you agree that this is fundamentally >> distinct from telepresence, and something that belongs in >> SDP, one way or another? > > What we are discussing now are requirements (eventhough I know we have us= ed SDP terminology in order to better describe the mechanism, and at the mo= ment it seems quite clear that SDP would be the best solution). > > The actual definition of the an attribute might then take place elsewhere= , e.g. in MMUSIC. But, the CLUE requirements don't need to care about that. > > Regards, > > Christer > > > > > > > > >>>>> And that you are not asking for any more from CLUE than simply >>>>> identifying the rendering type. >>>>> Is that correct? >>>>> >>>>> IF both of these statements are correct, than personally I >>>> think it is >>>>> fine TO include the information of rendering type, such as >>>> "binaural", >>>>> by some mechanism, such as a tag, AS LONG AS there is an >>>> accepted Use >>>>> Case that shows the necessity of communicating the >> rendering type, >>>>> such as "thresholding" or "panning". >>>>> >>>>> How do other people feel about this? >>>>> >>>>> Thanks, >>>>> Allyn >>>>> >>>>> -----Original Message----- >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>> Sent: Monday, June 20, 2011 12:23 PM >>>>> To: Allyn Romanow (allyn); Mary Barnes >>>>> Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) >>>>> Subject: RE: [clue] Requirement on centralized media mixing >>>>> >>>>> Hi Allyn, >>>>> >>>>>> Still trying to get clarification- >>>>>> >>>>>> I read your description of various types of rendering. >>>>>> Still trying to understand what you want from CLUE- If we >>>> have a tag >>>>>> that says "binaural" or stereo, sub binaural, are we done? >>>>> >>>>> Of course we could have a binaural specific SDP attribute, e.g. >>>>> a=3Dbinaural. >>>>> >>>>> But, again, what we are proposing is a general mechanism, >>>> that could >>>>> look something like: >>>>> >>>>> a=3Drendering-type =3D >>>>> >>>>> could then e.g. be "binaural", but it could also >>>> be something >>>>> else (we showed a few example in the e-mail). >>>>> >>>>>> Or do you want CLUE to describe how to do some kind of >>>> rendering? To >>>>> say >>>>>> something more about specific rendering functions? >>>>> >>>>> No, CLUE doesn't need to say anything about that. >>>>> >>>>> There would of course need to be a rendering description >> associated >>>>> with each rendering type value, but CLUE wouldn't define those. >>>>> >>>>> The idea is that an IANA registry is created, where people can >>>>> register their rendering type values. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>>> Sent: Sunday, June 19, 2011 10:29 PM >>>>>> To: Allyn Romanow (allyn); Mary Barnes >>>>>> Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) >>>>>> Subject: RE: [clue] Requirement on centralized media mixing >>>>>> >>>>>> >>>>>> Hi Allyn, >>>>>> >>>>>> I appologise that it took some time to reply. >>>>>> >>>>>> We've been working on some definition/example text (I sent >>>> it to the >>>>>> list just a few minutes ago), which I hope will clarify >>>> some of the >>>>>> questions that have been asked. >>>>>> >>>>>>> Also, what kind of support are you asking for binaural? >> I believe >>>>> it's >>>>>> often considered as a subset of stereo. What are you >> asking for? A >>>>>> simple tag that says "binaural", or the specification >>>>>>> of a rendering system for binaural? Precisely what are >> asking for? >>>>>> >>>>>> From CLUE, we are only asking for a general mechanism to >>>> request and >>>>>> indicate different rendering types (see definition in >>>> other e-mail). >>>>>> >>>>>> An example of such rendering type is binaural, BUT we are *NOT* >>>>>> asking CLUE to define any binaural specific SDP >> attributes etc. If >>>>>> such are needed, we agree that it needs to be done as a >>>> separate task. >>>>>> >>>>>> Before I try to answer your other questions, please take >> a look at >>>>>> the definition/example e-mail, which I hope will clarify >>>> what we mean >>>>>> by rendering and rendering type. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hi Christer - >>>>>> >>>>>> In spirit I am enthusiastic about what you are proposing >>>>> (meaning >>>>>> good quality mobile participation). I'm not clear on how >>>> the spirit >>>>>> becomes instantiated in our protocol, so I have some >>>> questions below >>>>>> J >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Allyn >>>>>> >>>>>> >>>>>> >>>>>> From: clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org] On >>>>>> Behalf Of Christer Holmberg >>>>>> Sent: Tuesday, June 14, 2011 7:23 AM >>>>>> To: clue@ietf.org >>>>>> Subject: [clue] Requirement on centralized media mixing >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> During the last interim meeting (May 12th) we >> discussed a >>>>>> requirement proposal >>>>>> >>>>>> stating that an endpoint must be able to request >>>> central audio >>>>>> rendering >>>>>> >>>>>> of different predefined formats, including 3D binaural >>>>> rendering. >>>>>> >>>>>> (Link to proposal: http://www.ietf.org/mail- >>>>>> archive/web/clue/current/msg00179.html) >>>>>> >>>>>> >>>>>> >>>>>> The proposal was well received, with the >>>> reservation that it >>>>>> should not be mandatory >>>>>> >>>>>> for the solution to implement centralized 3D binaural >>>>>> rendering, i.e.an endpoint should >>>>>> >>>>>> be able to request 3D binaural rendering, but had >>>> no guaranty >>>>>> that such rendering was >>>>>> >>>>>> supported by the system. >>>>>> >>>>>> >>>>>> >>>>>> It was decided to look how such requirement >> could look like. >>>>>> >>>>>> >>>>>> >>>>>> When I look the -03 version of the req draft, >> Requirement >>>>>> 2c >>>>>> states: >>>>>> >>>>>> >>>>>> >>>>>> "The solution MUST NOT preclude the use of >>>> binaural audio." >>>>>> >>>>>> >>>>>> >>>>>> I think that requirement is unclear, and it >> doesn't really >>>>>> give any guidance to our work. >>>>>> >>>>>> >>>>>> >>>>>> Due to that, and also due to the fact that rather >>>> than talking >>>>>> about specific rendering types, >>>>>> >>>>>> I would like to propose more general requirement >>>> text on the >>>>>> negotiation of the media mixing type, >>>>>> >>>>>> and the usage of centralized media mixing in the >>>> first place. >>>>>> >>>>>> >>>>>> >>>>>> The mechanism would be extendable, so new types can >>>> be added >>>>>> in future. >>>>>> >>>>>> >>>>>> >>>>>> So, the proposed requirements are: >>>>>> >>>>>> >>>>>> >>>>>> REQ-x: It MUST be possible to negotiate the usage of >>>>>> centralized media mixing. System support of centralized >>>> media mixing >>>>> is >>>>>> optional. >>>>>> >>>>>> >>>>>> >>>>>> REQ-y: When centralized media mixing is used, >> it MUST be >>>>>> possible to negotiate the type of media rendering provided >>>> for each >>>>>> media stream received by a client. >>>>>> >>>>>> --- >>>>>> >>>>>> [ar] I have a few questions/comments: >>>>>> >>>>>> 1. The term "negotiate" troubles me as I >>>> think it means >>>>> a >>>>>> particular form of communication that dictates the >>>> solution. What is >>>>>> being asked for is the receiver to know that it is receiving >>>>>> "centralized media mixing". This may not be the end product of a >>>>>> negotiation. The same is true of the use of the term >>>> negotiate in the >>>>>> second requirement. What is needed is a mechanism by which the >>>>> receiver >>>>>> may know what type of "media rendering" is being received. >>>>>> >>>>>> So, I'd rather offer, The solution must >>>> support a means >>>>>> for identifying a stream which is "centralized media mixing". >>>>>> >>>>>> And, When "centralized media mixing" is used, >> the solution >>>>>> must support a means for identifying... >>>>>> >>>>>> >>>>>> >>>>>> 2. Also, I'm not too sure what "media >>>> rendering", the >>>>>> phrase in the second reqmt, represents- SDP and RTP >>>> recognize audio >>>>>> channels and recognize codecs. Is this what is referred to >>>> as "media >>>>>> rendering"? Or is it something different? What very specifically? >>>>>> >>>>>> >>>>>> >>>>>> 3. After reading more of the discussion, I >>>> realize that I >>>>>> don't fully understand what is meant in the first reqmt by >>>>> "centralized >>>>>> media mixing" or "rendering", which term is used in >>>> another email. I >>>>>> had thought you meant the usual audio mixing such as >>>> discussed in RFC >>>>>> 5117.( I figured it was an understood part of the topology >>>> so didn't >>>>>> need to be called out in particular. But I don't mind calling it >>>>> out.) >>>>>> In any case, now I'm not sure what you mean, maybe it is >> something >>>>>> other than typical MCU mixing behavior as described in RFC 5117? >>>>>> >>>>>> >>>>>> >>>>>> 4. As for the discussion of binaural.. >> here is what it >>>>>> seems like to me.. AVP, RFC 3551 specifies the number of audio >>>>>> channels, what they refer to, and types of codecs. Binaural is >>>>>> neither. As you say, Christer, it's a type of stereo >>>> channel. Steve >>>>>> feels that "binaural" must be recognized in SDP, which of >>>> course, it >>>>> is >>>>>> not currently. >>>>>> >>>>>> >>>>>> >>>>>> I'm not entirely sure what needs to be specified about >>>>>> binaural, given that it is neither channel -type nor >>>> codec-type. What >>>>>> needs to >>>>> be >>>>>> standardized? This question is probably more for Steve, >> or both of >>>>> you. >>>>>> If the receiving device knows it's getting binaural >> stereo, then it >>>>> can >>>>>> run some algorithms to improve quality and if it isn't >>>> binaural, it >>>>>> won't run those algs., or something analogous? If that is >>>> the case, I >>>>>> don't see what needs to be standardized that isn't already >>>>>> standardized... But I'm eager to learn. >>>>>> >>>>>> >>>>>> >>>>>> Thanks- >>>>>> >>>>>> Allyn >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>= From christer.holmberg@ericsson.com Tue Jun 21 11:14:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3FB11E8114 for ; Tue, 21 Jun 2011 11:14:46 -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=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJHGtMVksHEg for ; Tue, 21 Jun 2011 11:14:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7612011E817C for ; Tue, 21 Jun 2011 11:14:45 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-7b-4e00df931876 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CF.BD.09774.39FD00E4; Tue, 21 Jun 2011 20:14:43 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 21 Jun 2011 20:14:42 +0200 From: Christer Holmberg To: Stephen Botzko , "Allyn Romanow (allyn)" Date: Tue, 21 Jun 2011 20:11:44 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: AcwwLyzO2JxRPINtTE2o4MK4AxiBIQAD4EDw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 18:14:47 -0000 Hi, >I would like to see use cases, particularly for non-binaural proposals. I= t seems to me that a receiver doesn't really >care if the stereo it is rece= iving is "panned", "plain" or "thresholded", or if it is linear or non-line= ar. So use cases >motivating those choices would be helpful. > >Also, the proposal is for a specific mechanism ("rendering type"). It may= be premature to identify the mechanism >in the requirements - since often = there are multiple ways to achieve the desired ends. Again, I am not suggesting to specify a specific mechanism - only a mechani= sm to negotiate the rendering type mechanism. Yes, I am using binaural as a rendering type EXAMPLE, but you are the one w= ho keep saying that I am trying to specify binaural :) Regards, Christer On Mon, Jun 20, 2011 at 5:47 PM, Allyn Romanow (allyn) > wrote: Hi Christer, I think that you are proposing that CLUE needs a mechanism to pass information, such as a tag, on "rendering type", for example, binaural, threshold, etc. Is that correct? And that you are not asking for any more from CLUE than simply identifying the rendering type. Is that correct? IF both of these statements are correct, than personally I think it is fine TO include the information of rendering type, such as "binaural", by some mechanism, such as a tag, AS LONG AS there is an accepted Use Case that shows the necessity of communicating the rendering type, such as "thresholding" or "panning". How do other people feel about this? Thanks, Allyn -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 20, 2011 12:23 PM To: Allyn Romanow (allyn); Mary Barnes Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bma= uchly) Subject: RE: [clue] Requirement on centralized media mixing Hi Allyn, >Still trying to get clarification- > >I read your description of various types of rendering. >Still trying to understand what you want from CLUE- >If we have a tag that says "binaural" or stereo, sub binaural, are we >done? Of course we could have a binaural specific SDP attribute, e.g. a=3Dbinaural. But, again, what we are proposing is a general mechanism, that could look something like: a=3Drendering-type =3D could then e.g. be "binaural", but it could also be something else (we showed a few example in the e-mail). >Or do you want CLUE to describe how to do some kind of rendering? To say >something more about specific rendering functions? No, CLUE doesn't need to say anything about that. There would of course need to be a rendering description associated with each rendering type value, but CLUE wouldn't define those. The idea is that an IANA registry is created, where people can register their rendering type values. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, June 19, 2011 10:29 PM > To: Allyn Romanow (allyn); Mary Barnes > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (b= mauchly) > Subject: RE: [clue] Requirement on centralized media mixing > > > Hi Allyn, > > I appologise that it took some time to reply. > > We've been working on some definition/example text (I sent it to the > list just a few minutes ago), which I hope will clarify some of the > questions that have been asked. > > >Also, what kind of support are you asking for binaural? I believe it's > often considered as a subset of stereo. What are you asking for? A > simple tag that says "binaural", or the specification > >of a rendering system for binaural? Precisely what are asking for? > > From CLUE, we are only asking for a general mechanism to request and > indicate different rendering types (see definition in other e-mail). > > An example of such rendering type is binaural, BUT we are *NOT* asking > CLUE to define any binaural specific SDP attributes etc. If such are > needed, we agree that it needs to be done as a separate task. > > Before I try to answer your other questions, please take a look at the > definition/example e-mail, which I hope will clarify what we mean by > rendering and rendering type. > > Regards, > > Christer > > > > > > > > > > > > > > > Hi Christer - > > In spirit I am enthusiastic about what you are proposing (meaning > good quality mobile participation). I'm not clear on how the spirit > becomes instantiated in our protocol, so I have some questions below J > > Thanks, > > Allyn > > > > From: clue-bounces@ietf.org [mailto:c= lue-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Tuesday, June 14, 2011 7:23 AM > To: clue@ietf.org > Subject: [clue] Requirement on centralized media mixing > > > > > > Hi, > > > > During the last interim meeting (May 12th) we discussed a > requirement proposal > > stating that an endpoint must be able to request central audio > rendering > > of different predefined formats, including 3D binaural rendering. > > (Link to proposal: http://www.ietf.org/mail- > archive/web/clue/current/msg00179.html) > > > > The proposal was well received, with the reservation that it > should not be mandatory > > for the solution to implement centralized 3D binaural rendering, > i.e.an endpoint should > > be able to request 3D binaural rendering, but had no guaranty > that such rendering was > > supported by the system. > > > > It was decided to look how such requirement could look like. > > > > When I look the -03 version of the req draft, Requirement 2c > states: > > > > "The solution MUST NOT preclude the use of binaural audio." > > > > I think that requirement is unclear, and it doesn't really give > any guidance to our work. > > > > Due to that, and also due to the fact that rather than talking > about specific rendering types, > > I would like to propose more general requirement text on the > negotiation of the media mixing type, > > and the usage of centralized media mixing in the first place. > > > > The mechanism would be extendable, so new types can be added in > future. > > > > So, the proposed requirements are: > > > > REQ-x: It MUST be possible to negotiate the usage of > centralized media mixing. System support of centralized media mixing is > optional. > > > > REQ-y: When centralized media mixing is used, it MUST be > possible to negotiate the type of media rendering provided for each > media stream received by a client. > > --- > > [ar] I have a few questions/comments: > > 1. The term "negotiate" troubles me as I think it means a > particular form of communication that dictates the solution. What is > being asked for is the receiver to know that it is receiving > "centralized media mixing". This may not be the end product of a > negotiation. The same is true of the use of the term negotiate in the > second requirement. What is needed is a mechanism by which the receiver > may know what type of "media rendering" is being received. > > So, I'd rather offer, The solution must support a means for > identifying a stream which is "centralized media mixing". > > And, When "centralized media mixing" is used, the solution must > support a means for identifying... > > > > 2. Also, I'm not too sure what "media rendering", the > phrase in the second reqmt, represents- SDP and RTP recognize audio > channels and recognize codecs. Is this what is referred to as "media > rendering"? Or is it something different? What very specifically? > > > > 3. After reading more of the discussion, I realize that I > don't fully understand what is meant in the first reqmt by "centralized > media mixing" or "rendering", which term is used in another email. I > had thought you meant the usual audio mixing such as discussed in RFC > 5117.( I figured it was an understood part of the topology so didn't > need to be called out in particular. But I don't mind calling it out.) > In any case, now I'm not sure what you mean, maybe it is something > other than typical MCU mixing behavior as described in RFC 5117? > > > > 4. As for the discussion of binaural.. here is what it > seems like to me.. AVP, RFC 3551 specifies the number of audio > channels, what they refer to, and types of codecs. Binaural is > neither. As you say, Christer, it's a type of stereo channel. Steve > feels that "binaural" must be recognized in SDP, which of course, it is > not currently. > > > > I'm not entirely sure what needs to be specified about binaural, > given that it is neither channel -type nor codec-type. What needs to be > standardized? This question is probably more for Steve, or both of you. > If the receiving device knows it's getting binaural stereo, then it can > run some algorithms to improve quality and if it isn't binaural, it > won't run those algs., or something analogous? If that is the case, I > don't see what needs to be standardized that isn't already > standardized... But I'm eager to learn. > > > > Thanks- > > Allyn > > > > Regards, > > > > Christer > > > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Tue Jun 21 11:52:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F064E11E81DE for ; Tue, 21 Jun 2011 11:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WITKwyZlU8zZ for ; Tue, 21 Jun 2011 11:52:45 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0402211E80FA for ; Tue, 21 Jun 2011 11:52:44 -0700 (PDT) Received: by vxi40 with SMTP id 40so59612vxi.31 for ; Tue, 21 Jun 2011 11:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CX8eFBBXR2+qjs5Yn436OE1DVX2b2yWrIfoCz2yFTQ4=; b=suzGUtrL8CeyxlNO5v2ZjPBDPwRywr2KZBcT9a6hdyixCfHlNbimbFGa8WpZI5FAdd TSRJG4VRlwM/YzKJ4gx52nkx3M2quSVAK0jcOB31iKaKy/Z8CzwgwgqzksoZyUwu6mdy rOtP6tcJ8Yx0+HZ6QSZ/7sF6Gl+Age3Hl5hp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Q2RCHg+Z8pthkpaUXonqDY+d3V0LwJfz0epmt930FHanxcadtoZ1rRmOpJ/HtDd+31 HWNFi+VkOJctP5HK+H1XEipMymWZmZn6+iXP2Hnf/fnKfmhcW2+g/1XgiYUe+rEGgy+2 An0sSPOFI0gPfFHN3ad8eamF0dT6CCYLPxAhI= MIME-Version: 1.0 Received: by 10.52.98.5 with SMTP id ee5mr1631142vdb.200.1308682364297; Tue, 21 Jun 2011 11:52:44 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Tue, 21 Jun 2011 11:52:44 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 21 Jun 2011 14:52:44 -0400 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf307f34a672a1b404a63d5b0c Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 18:52:47 -0000 --20cf307f34a672a1b404a63d5b0c Content-Type: text/plain; charset=ISO-8859-1 Hi Christer I understand you are advocating a general mechanism, which is why I especially want to see use cases showing the need for the panned, plain, thresholded, linear, non-linear rendering types you proposed. If someone has other rendering types, then they would be helpful too. For me the negotiation of "rendering type" is a mechanism. I am thinking all we need is number of channels, but I am quite willing to change my view if the use cases show more is needed. Regards, Stephen Botzko On Tue, Jun 21, 2011 at 2:11 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >I would like to see use cases, particularly for non-binaural proposals. > It seems to me that a receiver doesn't really >care if the stereo it is > receiving is "panned", "plain" or "thresholded", or if it is linear or > non-linear. So use cases >motivating those choices would be helpful. > > > >Also, the proposal is for a specific mechanism ("rendering type"). It may > be premature to identify the mechanism >in the requirements - since often > there are multiple ways to achieve the desired ends. > > > > Again, I am not suggesting to specify a specific mechanism - only a > mechanism to negotiate the rendering type mechanism. > > > > Yes, I am using binaural as a rendering type EXAMPLE, but you are the one > who keep saying that I am trying to specify binaural :) > > > > Regards, > > > > Christer > > > > On Mon, Jun 20, 2011 at 5:47 PM, Allyn Romanow (allyn) > wrote: > > > Hi Christer, > > I think that you are proposing that CLUE needs a mechanism to pass > information, such as a tag, on "rendering type", for example, binaural, > threshold, etc. > Is that correct? > > And that you are not asking for any more from CLUE than simply > identifying the rendering type. > Is that correct? > > IF both of these statements are correct, than personally I think it is > fine TO include the information of rendering type, such as "binaural", > by some mechanism, such as a tag, AS LONG AS there is an accepted Use > Case that shows the necessity of communicating the rendering type, such > as "thresholding" or "panning". > > How do other people feel about this? > > Thanks, > Allyn > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com christer.holmberg@ericsson.com>] > Sent: Monday, June 20, 2011 12:23 PM > To: Allyn Romanow (allyn); Mary Barnes > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly > (bmauchly) > Subject: RE: [clue] Requirement on centralized media mixing > > Hi Allyn, > > >Still trying to get clarification- > > > >I read your description of various types of rendering. > >Still trying to understand what you want from CLUE- > >If we have a tag that says "binaural" or stereo, sub binaural, are we > >done? > > Of course we could have a binaural specific SDP attribute, e.g. > a=binaural. > > But, again, what we are proposing is a general mechanism, that could > look something like: > > a=rendering-type = > > could then e.g. be "binaural", but it could also be something > else (we showed a few example in the e-mail). > > >Or do you want CLUE to describe how to do some kind of rendering? To > say > >something more about specific rendering functions? > > No, CLUE doesn't need to say anything about that. > > There would of course need to be a rendering description associated with > each rendering type value, but CLUE wouldn't define those. > > The idea is that an IANA registry is created, where people can register > their rendering type values. > > Regards, > > Christer > > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com christer.holmberg@ericsson.com>] > > Sent: Sunday, June 19, 2011 10:29 PM > > To: Allyn Romanow (allyn); Mary Barnes > > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly > (bmauchly) > > Subject: RE: [clue] Requirement on centralized media mixing > > > > > > Hi Allyn, > > > > I appologise that it took some time to reply. > > > > We've been working on some definition/example text (I sent it to the > > list just a few minutes ago), which I hope will clarify some of the > > questions that have been asked. > > > > >Also, what kind of support are you asking for binaural? I believe > it's > > often considered as a subset of stereo. What are you asking for? A > > simple tag that says "binaural", or the specification > > >of a rendering system for binaural? Precisely what are asking for? > > > > From CLUE, we are only asking for a general mechanism to request and > > indicate different rendering types (see definition in other e-mail). > > > > An example of such rendering type is binaural, BUT we are *NOT* asking > > CLUE to define any binaural specific SDP attributes etc. If such are > > needed, we agree that it needs to be done as a separate task. > > > > Before I try to answer your other questions, please take a look at the > > definition/example e-mail, which I hope will clarify what we mean by > > rendering and rendering type. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Christer - > > > > In spirit I am enthusiastic about what you are proposing > (meaning > > good quality mobile participation). I'm not clear on how the spirit > > becomes instantiated in our protocol, so I have some questions below J > > > > Thanks, > > > > Allyn > > > > > > > > From: clue-bounces@ietf.org [mailto: > clue-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > Sent: Tuesday, June 14, 2011 7:23 AM > > To: clue@ietf.org > > Subject: [clue] Requirement on centralized media mixing > > > > > > > > > > > > Hi, > > > > > > > > During the last interim meeting (May 12th) we discussed a > > requirement proposal > > > > stating that an endpoint must be able to request central audio > > rendering > > > > of different predefined formats, including 3D binaural > rendering. > > > > (Link to proposal: http://www.ietf.org/mail- > > archive/web/clue/current/msg00179.html) > > > > > > > > The proposal was well received, with the reservation that it > > should not be mandatory > > > > for the solution to implement centralized 3D binaural rendering, > > i.e.an endpoint should > > > > be able to request 3D binaural rendering, but had no guaranty > > that such rendering was > > > > supported by the system. > > > > > > > > It was decided to look how such requirement could look like. > > > > > > > > When I look the -03 version of the req draft, Requirement 2c > > states: > > > > > > > > "The solution MUST NOT preclude the use of binaural audio." > > > > > > > > I think that requirement is unclear, and it doesn't really give > > any guidance to our work. > > > > > > > > Due to that, and also due to the fact that rather than talking > > about specific rendering types, > > > > I would like to propose more general requirement text on the > > negotiation of the media mixing type, > > > > and the usage of centralized media mixing in the first place. > > > > > > > > The mechanism would be extendable, so new types can be added in > > future. > > > > > > > > So, the proposed requirements are: > > > > > > > > REQ-x: It MUST be possible to negotiate the usage of > > centralized media mixing. System support of centralized media mixing > is > > optional. > > > > > > > > REQ-y: When centralized media mixing is used, it MUST be > > possible to negotiate the type of media rendering provided for each > > media stream received by a client. > > > > --- > > > > [ar] I have a few questions/comments: > > > > 1. The term "negotiate" troubles me as I think it means > a > > particular form of communication that dictates the solution. What is > > being asked for is the receiver to know that it is receiving > > "centralized media mixing". This may not be the end product of a > > negotiation. The same is true of the use of the term negotiate in the > > second requirement. What is needed is a mechanism by which the > receiver > > may know what type of "media rendering" is being received. > > > > So, I'd rather offer, The solution must support a means for > > identifying a stream which is "centralized media mixing". > > > > And, When "centralized media mixing" is used, the solution must > > support a means for identifying... > > > > > > > > 2. Also, I'm not too sure what "media rendering", the > > phrase in the second reqmt, represents- SDP and RTP recognize audio > > channels and recognize codecs. Is this what is referred to as "media > > rendering"? Or is it something different? What very specifically? > > > > > > > > 3. After reading more of the discussion, I realize that I > > don't fully understand what is meant in the first reqmt by > "centralized > > media mixing" or "rendering", which term is used in another email. I > > had thought you meant the usual audio mixing such as discussed in RFC > > 5117.( I figured it was an understood part of the topology so didn't > > need to be called out in particular. But I don't mind calling it > out.) > > In any case, now I'm not sure what you mean, maybe it is something > > other than typical MCU mixing behavior as described in RFC 5117? > > > > > > > > 4. As for the discussion of binaural.. here is what it > > seems like to me.. AVP, RFC 3551 specifies the number of audio > > channels, what they refer to, and types of codecs. Binaural is > > neither. As you say, Christer, it's a type of stereo channel. Steve > > feels that "binaural" must be recognized in SDP, which of course, it > is > > not currently. > > > > > > > > I'm not entirely sure what needs to be specified about binaural, > > given that it is neither channel -type nor codec-type. What needs to > be > > standardized? This question is probably more for Steve, or both of > you. > > If the receiving device knows it's getting binaural stereo, then it > can > > run some algorithms to improve quality and if it isn't binaural, it > > won't run those algs., or something analogous? If that is the case, I > > don't see what needs to be standardized that isn't already > > standardized... But I'm eager to learn. > > > > > > > > Thanks- > > > > Allyn > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --20cf307f34a672a1b404a63d5b0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christer

I understand you are advocating a general mechanism, whi= ch is why I especially want to see use cases showing the need for the panne= d, plain, thresholded, linear, non-linear rendering types you proposed.=A0 = If someone has other rendering types, then they would be helpful too.

For me the negotiation of "rendering type" is a mechanism.=A0= I am thinking all we need is number of channels, but I am quite willing to= change my view if the use cases show more is needed.

Regards,
Stephen Botzko

On Tue, Jun 21, 2011 at 2:= 11 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:<= br>
Hi,

>I would like to see use cases, particularly for non-binaural proposals.= =A0It seems to me that a receiver doesn't really >care if the stere= o it is receiving is "panned", "plain" or "thresho= lded", or if it is linear or non-linear. So use cases >motivating t= hose choices would be helpful.
>
>Also, the proposal is for a specific mechanism ("rendering type&qu= ot;). =A0It may be premature to identify the mechanism >in the requireme= nts - since often there are multiple ways to achieve the desired ends.



Again, I am not suggesting to specify a specific mechanism - only a m= echanism to negotiate the rendering type mechanism.



Yes, I am using binaural as a rendering type EXAMPLE, but you are the one w= ho keep saying that I am trying to specify binaural :)



Regards,



Christer



On Mon, Jun 20, 2011 at 5:47 PM, Allyn Romanow (allyn) <allyn@cisco.com<mailto:allyn@cisco.com>> wrote:


Hi Christer,

I think that you are proposing that CLUE needs a mechanism to pass
information, such as a tag, on "rendering type", for example, bin= aural,
threshold, etc.
Is that correct?

And that you are not asking for any more from CLUE than simply
identifying the rendering type.
Is that correct?

IF both of these statements are correct, than personally I think it is
fine TO include the information of rendering type, such as "binaural&q= uot;,
by some mechanism, such as a tag, AS LONG AS there is an accepted Use
Case that shows the necessity of communicating the rendering type, such
as "thresholding" or "panning".

How do other people feel about this?

Thanks,
Allyn

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com<mailto= :christer.holmberg@ericss= on.com>]
Sent: Monday, June 20, 2011 12:23 PM
To: Allyn Romanow (allyn); Mary Barnes
Cc: clue@ietf.org<mailto:clue@ietf.or= g>; Botzko, Stephen; Bill Mauchly (bmauchly)
Subject: RE: [clue] Requirement on centralized media mixing

Hi Allyn,

>Still trying to get clarification-
>
>I read your description of various types of rendering.
>Still trying to understand what you want from CLUE-
>If we have a tag that says "binaural" or stereo, sub binaural= , are we
>done?

Of course we could have a binaural specific SDP attribute, e.g.
a=3Dbinaural.

But, again, what we are proposing is a general mechanism, that could
look something like:

a=3Drendering-type =3D <value>

<value> could then e.g. be "binaural", but it could also be= something
else (we showed a few example in the e-mail).

>Or do you want CLUE to describe how to do some kind of rendering? To say
>something more about specific rendering functions?

No, CLUE doesn't need to say anything about that.

There would of course need to be a rendering description associated with each rendering type value, but CLUE wouldn't define those.

The idea is that an IANA registry is created, where people can register
their rendering type values.

Regards,

Christer



> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com<mailto:christer.hol= mberg@ericsson.com>]
> Sent: Sunday, June 19, 2011 10:29 PM
> To: Allyn Romanow (allyn); Mary Barnes
> Cc: clue@ietf.org<mailto:clue@ie= tf.org>; Botzko, Stephen; Bill Mauchly (bmauchly)
> Subject: RE: [clue] Requirement on centralized media mixing
>
>
> Hi Allyn,
>
> I appologise that it took some time to reply.
>
> We've been working on some definition/example text (I sent it to t= he
> list just a few minutes ago), which I hope will clarify some of the > questions that have been asked.
>
> >Also, what kind of support are you asking for binaural? I believe<= br> it's
> often considered as a subset of stereo. What are you asking for? A
> simple tag that says "binaural", or =A0the specification
> >of a rendering system for binaural? Precisely what are asking for?=
>
> From CLUE, we are only asking for a general mechanism to request and > indicate different rendering types (see definition in other e-mail). >
> An example of such rendering type is binaural, BUT we are *NOT* asking=
> CLUE to define any binaural specific SDP attributes etc. If such are > needed, we agree that it needs to be done as a separate task.
>
> Before I try to answer your other questions, please take a look at the=
> definition/example e-mail, which I hope will clarify what we mean by > rendering and rendering type.
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> =A0 =A0 =A0 Hi Christer -
>
> =A0 =A0 =A0 In spirit I am enthusiastic about what you are proposing (meaning
> good quality mobile participation). I'm not clear on how the spiri= t
> becomes instantiated in our protocol, so I have some questions below J=
>
> =A0 =A0 =A0 Thanks,
>
> =A0 =A0 =A0 Allyn
>
>
>
> =A0 =A0 =A0 From: clue-bounces@ietf.org<mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org<mailto:clue-bounces@ietf.org>] On
> Behalf Of Christer Holmberg
> =A0 =A0 =A0 Sent: Tuesday, June 14, 2011 7:23 AM
> =A0 =A0 =A0 To: clue@ietf.org<mailto:clue@ietf.org>
> =A0 =A0 =A0 Subject: [clue] Requirement on centraliz= ed media mixing
>
>
>
>
>
> =A0 =A0 =A0 Hi,
>
>
>
> =A0 =A0 =A0 During the last interim meeting (May 12th) we discussed a<= br> > requirement proposal
>
> =A0 =A0 =A0 stating that an endpoint must be able to request central a= udio
> rendering
>
> =A0 =A0 =A0 of different predefined formats, including 3D binaural
rendering.
>
> =A0 =A0 =A0 (Link to proposal: http://www.ietf.org/mail-
> archive/web/clue/current/msg00179.html)
>
>
>
> =A0 =A0 =A0 The proposal was well received, with the reservation that = it
> should not be mandatory
>
> =A0 =A0 =A0 for the solution to implement centralized 3D binaural rend= ering,
> i.e.an<http://i.e.an> endpoint should=
>
> =A0 =A0 =A0 be able to request 3D binaural rendering, but had no guara= nty
> that such rendering was
>
> =A0 =A0 =A0 supported by the system.
>
>
>
> =A0 =A0 =A0 It was decided to look how such requirement could look lik= e.
>
>
>
> =A0 =A0 =A0 When I look the -03 version of the req draft, Requirement = 2c
> states:
>
>
>
> =A0 =A0 =A0 =A0 =A0 "The solution MUST NOT preclude the use of bi= naural audio."
>
>
>
> =A0 =A0 =A0 I think that requirement is unclear, and it doesn't re= ally give
> any guidance to our work.
>
>
>
> =A0 =A0 =A0 Due to that, and also due to the fact that rather than tal= king
> about specific rendering types,
>
> =A0 =A0 =A0 I would like to propose more general requirement text on t= he
> negotiation of the media mixing type,
>
> =A0 =A0 =A0 and the usage of centralized media mixing in the first pla= ce.
>
>
>
> =A0 =A0 =A0 The mechanism would be extendable, so new types can be add= ed in
> future.
>
>
>
> =A0 =A0 =A0 So, the proposed requirements are:
>
>
>
> =A0 =A0 =A0 REQ-x: =A0 =A0It MUST be possible to negotiate the usage o= f
> centralized media mixing. System support of centralized media mixing is
> optional.
>
>
>
> =A0 =A0 =A0 REQ-y: =A0 =A0When centralized media mixing is used, it MU= ST be
> possible to negotiate the type of media rendering provided for each > media stream received by a client.
>
> =A0 =A0 =A0 =A0---
>
> =A0 =A0 =A0 [ar] I have a few questions/comments:
>
> =A0 =A0 =A0 1. =A0 =A0 =A0 =A0 The term "negotiate" troubles= me as I think it means
a
> particular form of communication that dictates the solution. What is > being asked for is the receiver to know that it is receiving
> "centralized media mixing". This may not be the end product = of a
> negotiation. The same is true of the use of the term negotiate in the<= br> > second requirement. What is needed is a mechanism by which the
receiver
> may know what type of "media rendering" is being received. >
> =A0 =A0 =A0 =A0 =A0 =A0So, I'd rather offer, The solution must sup= port a means for
> identifying a stream which is "centralized media mixing". >
> =A0 =A0 =A0 And, When "centralized media mixing" is used, th= e solution must
> support a means for identifying...
>
>
>
> =A0 =A0 =A0 2. =A0 =A0 =A0 Also, =A0I'm not too sure what "me= dia rendering", =A0the
> phrase in the second reqmt, represents- SDP and RTP recognize audio > channels and recognize codecs. Is this what is referred to as "me= dia
> rendering"? Or is it something different? What very specifically?=
>
>
>
> =A0 =A0 =A0 3. =A0 =A0 =A0 After reading more of the discussion, I rea= lize that I
> don't fully understand what is meant in the first reqmt by
"centralized
> media mixing" or "rendering", which term is used in ano= ther email. I
> had thought you meant the usual audio mixing such as discussed in RFC<= br> > 5117.( I figured it was an understood part of the topology so didn'= ;t
> need to =A0be called out in particular. But I don't mind calling i= t
out.)
> In any case, now I'm not sure what you mean, maybe it is something=
> other than typical MCU mixing behavior as described in RFC 5117?
>
>
>
> =A0 =A0 =A0 4. =A0 =A0 =A0 As for the discussion of binaural.. here is= what it
> seems like to me.. AVP, RFC 3551 specifies =A0the number of =A0audio > channels, what they refer to, =A0and types of codecs. Binaural is
> neither. As you say, Christer, it's a type of stereo channel. =A0S= teve
> feels that "binaural" must be recognized in SDP, which of co= urse, it
is
> not currently.
>
>
>
> =A0 =A0 =A0 I'm not entirely sure what needs to be specified about= binaural,
> given that it is neither channel -type nor codec-type. What needs to be
> standardized? This question is probably more for Steve, or both of
you.
> If the receiving device knows it's getting binaural stereo, then i= t
can
> run some algorithms to improve quality and if it isn't binaural, i= t
> won't run those algs., or something analogous? If that is the case= , I
> don't see what needs to be standardized that isn't already
> standardized... But I'm eager to learn.
>
>
>
> =A0 =A0 =A0 Thanks-
>
> =A0 =A0 =A0 Allyn
>
>
>
> =A0 =A0 =A0 Regards,
>
>
>
> =A0 =A0 =A0 Christer
>
>
>
>
_______________________________________________
clue mailing list
clue@ietf.org<mailto:clue@ietf.org>

--20cf307f34a672a1b404a63d5b0c-- From allyn@cisco.com Tue Jun 21 19:59:45 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD5511E8132 for ; Tue, 21 Jun 2011 19:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF89aby9R2+J for ; Tue, 21 Jun 2011 19:59:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2D33F11E80FC for ; Tue, 21 Jun 2011 19:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=3491; q=dns/txt; s=iport; t=1308711584; x=1309921184; h=mime-version:subject:date:message-id:from:to; bh=lUxlS6fkmbJfIPSKr9/u0L+usCmigSEPOSjSGTllGKU=; b=JxH4GAr2jp27RpEeLHhjKU+orPlESeOa+5ctybTEsZwbUzyEJmawYk97 +C9GpgLlhdWwTMc4QbYiW0jUDzAaUu+EY2fR9hariZWC1XzgaR0yDK22a yjrk36wRWVonjXokSndutVNxBu6uDGa86VjFKabZ9astSxWE08v2/RK1d 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQIAGVZAU6rRDoI/2dsb2JhbABUglGVZI5Wd6g6gR2eOIYrBIcjjzGLPg X-IronPort-AV: E=Sophos;i="4.65,404,1304294400"; d="scan'208,217";a="382807032" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2011 02:59:43 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5M2xh5G005361 for ; Wed, 22 Jun 2011 02:59:43 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 19:59:43 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3088.6F8D871A" Date: Tue, 21 Jun 2011 19:59:41 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6342@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: negotiation Thread-Index: AcwwiG6Qy08GGqFOT/G7GQNQ14C2ew== From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 22 Jun 2011 02:59:43.0725 (UTC) FILETIME=[6FDB99D0:01CC3088] Subject: [clue] negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 02:59:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3088.6F8D871A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe we can accomplish the exchange of information necessary for CLUE with declarations and without the need for negotiation, which is more complex. This has been the thinking thus far. =20 Several people (Christer, Charles) have recently been using the term "negotiation". I take it they mean it in the loose sense of exchange information. =20 In any case, whether the communication is via negotiation or declaration is part of the solution design, not requirements. =20 Thanks, Allyn =20 =20 ------_=_NextPart_001_01CC3088.6F8D871A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe we can accomplish the exchange of = information necessary for CLUE with declarations and without the need for = negotiation, which is more complex. This has been the thinking thus = far.

 

Several people (Christer, Charles) have recently = been using the term “negotiation”. I take it they mean it in the loose = sense of exchange information.

 

In any case, whether the communication is  via = negotiation or declaration is part of the solution design, not = requirements.

 

Thanks,

Allyn

 

 

------_=_NextPart_001_01CC3088.6F8D871A-- From allyn@cisco.com Tue Jun 21 20:07:22 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFCE11E8123 for ; Tue, 21 Jun 2011 20:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKkIGv+2kN3j for ; Tue, 21 Jun 2011 20:07:21 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 75AB711E80BE for ; Tue, 21 Jun 2011 20:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=4391; q=dns/txt; s=iport; t=1308712041; x=1309921641; h=mime-version:subject:date:message-id:from:to; bh=GAbaF46Jinm6FiwcTOPw5mhW7Z79vfHS9R2s9WSTp2E=; b=ETdZngr33PfuvGT7ESCSDUVxDhngVcrx4jptjzxrksVTVcT8+CWeRXJ1 L+SXCnfY7abn01ZD3NvyIQ/11KD+AUU5fC5kxJ111GmJAQtowayGp5xy6 o7cIjmKRA4R77BPVZ5Ue2CXyA/h5kj7E0EBRp9eBTcnJMTq8s1H6dds4b E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQIAIdbAU6rRDoG/2dsb2JhbABUglGVZI5Wd6g9gR2eN4YrBIcjjzGLPg X-IronPort-AV: E=Sophos;i="4.65,404,1304294400"; d="scan'208,217";a="466715153" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 22 Jun 2011 03:07:21 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5M37L5M018330 for ; Wed, 22 Jun 2011 03:07:21 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 20:07:21 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3089.80254E54" Date: Tue, 21 Jun 2011 20:07:19 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6348@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: binaural and other rendering types Thread-Index: AcwwiX+kJtcPBO9URfKl9y3YJ4skaQ== From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 22 Jun 2011 03:07:21.0024 (UTC) FILETIME=[806DE400:01CC3089] Subject: [clue] binaural and other rendering types X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 03:07:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3089.80254E54 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following this ongoing discussion, I have 2 concerns- =20 First, I believe we agreed to that the requirements need to be motivated by use cases, and I don't see any use cases for binaural or other rendering types. It would seem best to me for us to hold the conversation until bona fide use cases relevant to CLUE are agreed upon. =20 Secondly, I'm not clear on whether handling binaural stereo needs to be discussed in another group such as mmusic, rather than CLUE, or in addition to CLUE (if there were relevant use cases for CLUE). It would be good for the co-chairs (or someone) to sort this out. =20 One thing to consider is that the real requirement in my opinion is CLUE extensibility - the ability to define new descriptive information to be sent by senders and receivers, such as stereo binaural - I doubt that anyone imagines we would be able to define all descriptive information now for all time.=20 =20 Thanks, Allyn ------_=_NextPart_001_01CC3089.80254E54 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Following this ongoing discussion, I have 2 = concerns-

 

First, I believe we agreed to that the requirements = need to be motivated by use cases, and I don’t see any use cases for = binaural or other rendering types. It would seem best to me for us to  hold the conversation until bona fide use cases relevant to CLUE are agreed = upon.

 

Secondly, I’m not clear on whether handling = binaural stereo needs to be discussed in another group such as mmusic, rather than CLUE, = or in addition to CLUE (if there were relevant use cases for CLUE). It would = be good for the co-chairs (or someone) to sort this out.

 

One thing to consider is that the real requirement = in my opinion is CLUE extensibility – the ability to define new = descriptive information to be sent  by senders and receivers, such as stereo binaural = – I doubt that anyone imagines we would be able to define all descriptive = information now for all time.

 

Thanks,

Allyn

------_=_NextPart_001_01CC3089.80254E54-- From allyn@cisco.com Tue Jun 21 20:51:30 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE11211E80A0 for ; Tue, 21 Jun 2011 20:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f-gWm-K-hcl for ; Tue, 21 Jun 2011 20:51:30 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1A311E8089 for ; Tue, 21 Jun 2011 20:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=2569; q=dns/txt; s=iport; t=1308714690; x=1309924290; h=mime-version:subject:date:message-id:from:to:cc; bh=uzW4/xMhCJnCWSjHXyPQ+n6D3Zs2FQfPP+bR+XRC4vA=; b=SVTU+ci30L0S6+2BcjAX2vghbgrAt/ipgRQMX/xrhypXED76cI5ypTWl UczJ4hapM2BYg3IG0zrdBtDOMepM1HUEhxgTbOvCs4Ap4hf249LXv1vn2 rJR4fo7QVzZ/8R5LXeJemaj/Xg9PoKF4RDjwaJ/PEti8Uy5wSBUiMzDQN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFdmAU6rRDoJ/2dsb2JhbABUglGkO3epK542hisEhyOPMYs+ X-IronPort-AV: E=Sophos;i="4.65,404,1304294400"; d="scan'208,217";a="382829975" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2011 03:51:29 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5M3pTPE001204; Wed, 22 Jun 2011 03:51:29 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Jun 2011 20:51:29 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC308F.AABE9334" Date: Tue, 21 Jun 2011 20:51:27 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6357@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: use case for multi-view Thread-Index: Acwwj6m4l9xOCH4NSAO5KaTj+QfrLw== From: "Allyn Romanow (allyn)" To: "Roni Even" X-OriginalArrivalTime: 22 Jun 2011 03:51:29.0542 (UTC) FILETIME=[AB11AA60:01CC308F] Cc: clue@ietf.org Subject: [clue] use case for multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 03:51:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC308F.AABE9334 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, I thought Mark's use case for multi-view was added to the Use Case doc, but I couldn't find it there? Is it just not added yet or is there some issue with it? =20 Thanks much ------_=_NextPart_001_01CC308F.AABE9334 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

I thought Mark’s use case for multi-view was = added to the Use Case doc, but I couldn’t find it there? Is it just not = added yet or is there some issue with it?

 

Thanks much

------_=_NextPart_001_01CC308F.AABE9334-- From christer.holmberg@ericsson.com Tue Jun 21 22:24:43 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011C811E8094 for ; Tue, 21 Jun 2011 22:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.887 X-Spam-Level: X-Spam-Status: No, score=-5.887 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlSugn5GSWAK for ; Tue, 21 Jun 2011 22:24:38 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 447BF11E8091 for ; Tue, 21 Jun 2011 22:24:37 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-95-4e017c9456f2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 44.6E.09774.49C710E4; Wed, 22 Jun 2011 07:24:36 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 22 Jun 2011 07:24:35 +0200 From: Christer Holmberg To: Stephen Botzko Date: Wed, 22 Jun 2011 07:24:34 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: AcwwRGki/TMfisWMTZuXeog9hHBoFwAV+Y0Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 05:24:43 -0000 Hi Stephen, >I understand you are advocating a general mechanism, which is why I especi= ally want to see use cases showing the need for the panned, plain, threshol= ded, linear, non-linear rendering types you=20 >proposed. If someone has other rendering types, then they would be helpfu= l too. >=09 >For me the negotiation of "rendering type" is a mechanism. I am thinking = all we need is number of channels, but I am quite willing to change my view= if the use cases show more is needed. What do you mean by "number of channels"? In the SDP a=3Drtpmap attribute you are able to indicate the number of audi= o channels, but I don't think that helps. Regards, Christer =09 =09 On Tue, Jun 21, 2011 at 2:11 PM, Christer Holmberg wrote: =09 Hi, =09 >I would like to see use cases, particularly for non-binaural proposals. = It seems to me that a receiver doesn't really >care if the stereo it is re= ceiving is "panned", "plain" or "thresholded", or if it is linear or non-li= near. So use cases >motivating those choices would be helpful. > >Also, the proposal is for a specific mechanism ("rendering type"). It m= ay be premature to identify the mechanism >in the requirements - since ofte= n there are multiple ways to achieve the desired ends. =09 =09 =09 =09 Again, I am not suggesting to specify a specific mechanism - only a mecha= nism to negotiate the rendering type mechanism. =09 =09 =09 Yes, I am using binaural as a rendering type EXAMPLE, but you are the one= who keep saying that I am trying to specify binaural :) =09 =09 =09 Regards, =09 =09 =09 Christer =09 On Mon, Jun 20, 2011 at 5:47 PM, Allyn Romanow (allyn) > wrote: =09 =09 Hi Christer, =09 I think that you are proposing that CLUE needs a mechanism to pass information, such as a tag, on "rendering type", for example, binaural, threshold, etc. Is that correct? =09 And that you are not asking for any more from CLUE than simply identifying the rendering type. Is that correct? =09 IF both of these statements are correct, than personally I think it is fine TO include the information of rendering type, such as "binaural", by some mechanism, such as a tag, AS LONG AS there is an accepted Use Case that shows the necessity of communicating the rendering type, such as "thresholding" or "panning". =09 How do other people feel about this? =09 Thanks, Allyn =09 -----Original Message----- =09 From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 20, 2011 12:23 PM To: Allyn Romanow (allyn); Mary Barnes =09 Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (b= mauchly) Subject: RE: [clue] Requirement on centralized media mixing =09 Hi Allyn, =09 >Still trying to get clarification- > >I read your description of various types of rendering. >Still trying to understand what you want from CLUE- >If we have a tag that says "binaural" or stereo, sub binaural, are we >done? =09 Of course we could have a binaural specific SDP attribute, e.g. a=3Dbinaural. =09 But, again, what we are proposing is a general mechanism, that could look something like: =09 a=3Drendering-type =3D =09 could then e.g. be "binaural", but it could also be something else (we showed a few example in the e-mail). =09 >Or do you want CLUE to describe how to do some kind of rendering? To say >something more about specific rendering functions? =09 No, CLUE doesn't need to say anything about that. =09 There would of course need to be a rendering description associated with each rendering type value, but CLUE wouldn't define those. =09 The idea is that an IANA registry is created, where people can register their rendering type values. =09 Regards, =09 Christer =09 =09 =09 > -----Original Message----- =09 > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, June 19, 2011 10:29 PM > To: Allyn Romanow (allyn); Mary Barnes =09 > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly = (bmauchly) > Subject: RE: [clue] Requirement on centralized media mixing > > > Hi Allyn, > > I appologise that it took some time to reply. > > We've been working on some definition/example text (I sent it to the > list just a few minutes ago), which I hope will clarify some of the > questions that have been asked. > > >Also, what kind of support are you asking for binaural? I believe it's > often considered as a subset of stereo. What are you asking for? A > simple tag that says "binaural", or the specification > >of a rendering system for binaural? Precisely what are asking for? > > From CLUE, we are only asking for a general mechanism to request and > indicate different rendering types (see definition in other e-mail). > > An example of such rendering type is binaural, BUT we are *NOT* asking > CLUE to define any binaural specific SDP attributes etc. If such are > needed, we agree that it needs to be done as a separate task. > > Before I try to answer your other questions, please take a look at the > definition/example e-mail, which I hope will clarify what we mean by > rendering and rendering type. > > Regards, > > Christer > > > > > > > > > > > > > > > Hi Christer - > > In spirit I am enthusiastic about what you are proposing (meaning > good quality mobile participation). I'm not clear on how the spirit > becomes instantiated in our protocol, so I have some questions below J > > Thanks, > > Allyn > > > =09 > From: clue-bounces@ietf.org [mailto= :clue-bounces@ietf.org] On =09 > Behalf Of Christer Holmberg > Sent: Tuesday, June 14, 2011 7:23 AM =09 > To: clue@ietf.org =09 > Subject: [clue] Requirement on centralized media mixing > > > > > > Hi, > > > > During the last interim meeting (May 12th) we discussed a > requirement proposal > > stating that an endpoint must be able to request central audio > rendering > > of different predefined formats, including 3D binaural rendering. > > (Link to proposal: http://www.ietf.org/mail- > archive/web/clue/current/msg00179.html) > > > > The proposal was well received, with the reservation that it > should not be mandatory > > for the solution to implement centralized 3D binaural rendering, =09 > i.e.an endpoint should =09 > > be able to request 3D binaural rendering, but had no guaranty > that such rendering was > > supported by the system. > > > > It was decided to look how such requirement could look like. > > > > When I look the -03 version of the req draft, Requirement 2c > states: > > > > "The solution MUST NOT preclude the use of binaural audio." > > > > I think that requirement is unclear, and it doesn't really give > any guidance to our work. > > > > Due to that, and also due to the fact that rather than talking > about specific rendering types, > > I would like to propose more general requirement text on the > negotiation of the media mixing type, > > and the usage of centralized media mixing in the first place. > > > > The mechanism would be extendable, so new types can be added in > future. > > > > So, the proposed requirements are: > > > > REQ-x: It MUST be possible to negotiate the usage of > centralized media mixing. System support of centralized media mixing is > optional. > > > > REQ-y: When centralized media mixing is used, it MUST be > possible to negotiate the type of media rendering provided for each > media stream received by a client. > > --- > > [ar] I have a few questions/comments: > > 1. The term "negotiate" troubles me as I think it means a > particular form of communication that dictates the solution. What is > being asked for is the receiver to know that it is receiving > "centralized media mixing". This may not be the end product of a > negotiation. The same is true of the use of the term negotiate in the > second requirement. What is needed is a mechanism by which the receiver > may know what type of "media rendering" is being received. > > So, I'd rather offer, The solution must support a means for > identifying a stream which is "centralized media mixing". > > And, When "centralized media mixing" is used, the solution must > support a means for identifying... > > > > 2. Also, I'm not too sure what "media rendering", the > phrase in the second reqmt, represents- SDP and RTP recognize audio > channels and recognize codecs. Is this what is referred to as "media > rendering"? Or is it something different? What very specifically? > > > > 3. After reading more of the discussion, I realize that I > don't fully understand what is meant in the first reqmt by "centralized > media mixing" or "rendering", which term is used in another email. I > had thought you meant the usual audio mixing such as discussed in RFC > 5117.( I figured it was an understood part of the topology so didn't > need to be called out in particular. But I don't mind calling it out.) > In any case, now I'm not sure what you mean, maybe it is something > other than typical MCU mixing behavior as described in RFC 5117? > > > > 4. As for the discussion of binaural.. here is what it > seems like to me.. AVP, RFC 3551 specifies the number of audio > channels, what they refer to, and types of codecs. Binaural is > neither. As you say, Christer, it's a type of stereo channel. Steve > feels that "binaural" must be recognized in SDP, which of course, it is > not currently. > > > > I'm not entirely sure what needs to be specified about binaural, > given that it is neither channel -type nor codec-type. What needs to be > standardized? This question is probably more for Steve, or both of you. > If the receiving device knows it's getting binaural stereo, then it can > run some algorithms to improve quality and if it isn't binaural, it > won't run those algs., or something analogous? If that is the case, I > don't see what needs to be standardized that isn't already > standardized... But I'm eager to learn. > > > > Thanks- > > Allyn > > > > Regards, > > > > Christer > > > > _______________________________________________ clue mailing list =09 clue@ietf.org =09 https://www.ietf.org/mailman/listinfo/clue =09 =09 From christer.holmberg@ericsson.com Tue Jun 21 22:26:38 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E486711E8094 for ; Tue, 21 Jun 2011 22:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFfjBy3zuoAP for ; Tue, 21 Jun 2011 22:26:38 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3678411E8091 for ; Tue, 21 Jun 2011 22:26:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-39-4e017d0d12b6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5C.BE.09774.D0D710E4; Wed, 22 Jun 2011 07:26:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 22 Jun 2011 07:26:36 +0200 From: Christer Holmberg To: "Allyn Romanow (allyn)" , "clue@ietf.org" Date: Wed, 22 Jun 2011 07:26:35 +0200 Thread-Topic: negotiation Thread-Index: AcwwiG6Qy08GGqFOT/G7GQNQ14C2ewAFGraQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB53370DC@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6342@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6342@xmb-sjc-221.amer.cisco.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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 05:26:39 -0000 Hi,=20 >I believe we can accomplish the exchange of information necessary for CLUE= with declarations and without the need for negotiation, which is more comp= lex. This has been the thinking thus far. > >Several people (Christer, Charles) have recently been using the term "nego= tiation". I take it they mean it in the loose sense of exchange information= . > >In any case, whether the communication is via negotiation or declaration = is part of the solution design, not requirements. I agree. The requirements should only talk about being able to provide info= rmation. Regards, Christer =20 =20 From christer.holmberg@ericsson.com Tue Jun 21 22:32:26 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BBC11E80A3 for ; Tue, 21 Jun 2011 22:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4XPIqbpRTTm for ; Tue, 21 Jun 2011 22:32:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 26FDE11E80A0 for ; Tue, 21 Jun 2011 22:32:25 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-0b-4e017e686e07 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 81.37.20773.86E710E4; Wed, 22 Jun 2011 07:32:24 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 22 Jun 2011 07:32:22 +0200 From: Christer Holmberg To: "Allyn Romanow (allyn)" , "clue@ietf.org" Date: Wed, 22 Jun 2011 07:32:21 +0200 Thread-Topic: binaural and other rendering types Thread-Index: AcwwiX+kJtcPBO9URfKl9y3YJ4skaQAE4qcQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB53370E2@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6348@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6348@xmb-sjc-221.amer.cisco.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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] binaural and other rendering types X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 05:32:27 -0000 Hi,=20 >Following this ongoing discussion, I have 2 concerns- > >First, I believe we agreed to that the requirements need to be motivated b= y use cases, and I don't see any use cases for binaural or other rendering = types. It would seem best to me for us to =20 >hold the conversation until bona fide use cases relevant to CLUE are agree= d upon. I think we have provided a use-case for binaural audio. A "single stream de= vice" (e.g. a mobile phone) is able to join a telepresence conference, and = it is possible to give him a "teleprecense-like" experience. >Secondly, I'm not clear on whether handling binaural stereo needs to be di= scussed in another group such as mmusic, rather than CLUE, or in addition t= o CLUE (if there were relevant use cases for=20 >CLUE). It would be good for the co-chairs (or someone) to sort this out. We don't need to disucss the details of binaural stereo. Again, I am only s= uggesting a generic mechanism. Then, if additional binaural specific inform= ation elements etc are needed, that needs to be discussed elsewhere. >One thing to consider is that the real requirement in my opinion is CLUE e= xtensibility - the ability to define new descriptive information to be sent= by senders and receivers, such as stereo=20 >binaural - I doubt that anyone imagines we would be able to define all des= criptive information now for all time.=20 Again, I am not suggesting that. Whenever a rendering type value is registe= red, THEN one needs to provide descriptive information associated with that= value. We would ONLY require a mechanism to transport the rendering type v= alue - nothing more, nothing less :) Regards, Christer From christer.holmberg@ericsson.com Wed Jun 22 03:10:23 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AF611E807F for ; Wed, 22 Jun 2011 03:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQNoIk-7zIxQ for ; Wed, 22 Jun 2011 03:10:22 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1E33711E8098 for ; Wed, 22 Jun 2011 03:10:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-81-4e01bf8ae2e0 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FB.ED.09774.A8FB10E4; Wed, 22 Jun 2011 12:10:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 22 Jun 2011 12:10:18 +0200 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , "clue@ietf.org" Date: Wed, 22 Jun 2011 12:09:53 +0200 Thread-Topic: [clue] Layout negotiation Thread-Index: AcwwATSD2MWMnBnxSh63CAep1FO53gAKB6nQACbFy2A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 10:10:23 -0000 Hi Charles,=20 >I think I was the one that brought up layouts originally. I=20 >was more concerned with video layouts than audio layouts.=20 >Currently, the requirements draft seems to focus more on=20 >audio layout/spatial audio. >Requirements 3 and 16 both deal with parts of this. I feel=20 >there needs to be more clear requirements on the ability for=20 >the to represent the potential layouts of the audio/video can=20 >that be offered. For example, I have 3 camera and 3 mics. I=20 >can provide: >1) 3 individual video each with corresponding audio >2) 1 active speaker only switched video with mixed audio >3) 1 composed video including active speaker and 'n'=20 >non-active speakers (where 'n' is may be all or some fixed=20 >limit) and mixed audio I actually think that your examples, as written, are different RENDERING TY= PES, because they only talk about mixing and composition. In my opinion, a LAYOUT TYPE is a description of how sources are placed in = a virtual room. Of course, in order to do the mixing, a layout description is often needed = as an "input" for the rendering algorithm. Regards, Christer =20 >If the receiving endpoint wants to control the layout itself,=20 >it goes with option 1. If it has limited=20 >resources/bandwidth/screens/etc it may prefer option 2 or 3. >=20 > Cheers, > Charles=20 >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Christer Holmberg > > Sent: Tuesday, June 21, 2011 3:52 AM > > To: clue@ietf.org > > Subject: [clue] Layout negotiation > >=20 > > Hi, > >=20 > > A while ago there were some discussions about having requirements to > negotiate the layout type, and at > > least according to Stephen B it was within the scope of the work. > >=20 > > "The ability to negotiate an audio or video layout=20 > is clearly > within scope, and has general > > value it the group wants to take it on. > > For instance, if you combine video switching of multiple > sources with audio > > mixing/transcoding, then the receiver is responsible > > for the video layout but has no control over the=20 > audio layout. > In that case, there are > > advantages to allowing the receiver to tell the > > central audio mixer where it wants the sources placed on the > sound stage. I have no objection > > in principle to adding that kind of > > negotiation to the requirements, though I think the group > should consider the impact on the > > schedule." > >=20 > > However, I haven't seen any input after that. > >=20 > > My idea would be that it is very similar to the rendering type: CLUE > defines a mechanism to negotiate > > the layout type, but doesn't define specific types (instead an IANA > registry would be created for > > that). So, I don't think it would have any significant impact on our > schedule. > >=20 > > Whether it, in addition to negotiation a layout type (which=20 > specifies > the source locations), should be > > possible for the user to more explicit place individual sources, as > mentioned by Stephen, can be > > discussed. However, that would probably require a little=20 > more work, so > at least I would be happy with > > a simple layout type negotiation at this point. > >=20 > > So, would people be ok with such requirement? > >=20 > > (Another alternative would be to "embed" the layout type into the > rendering type, but I think that > > would be very clumsy. Because, in that case you would need to define > mulitple types for the same > > rendering, but with different layouts.) > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > = From Even.roni@huawei.com Wed Jun 22 04:03:12 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3102921F84B6 for ; Wed, 22 Jun 2011 04:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.778 X-Spam-Level: X-Spam-Status: No, score=-103.778 tagged_above=-999 required=5 tests=[AWL=-1.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5H2v-MHzIEEK for ; Wed, 22 Jun 2011 04:03:11 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 461E921F84B5 for ; Wed, 22 Jun 2011 04:03:11 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN600MWXUP8OU@szxga05-in.huawei.com> for clue@ietf.org; Wed, 22 Jun 2011 19:03:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN6007K1UP8IW@szxga05-in.huawei.com> for clue@ietf.org; Wed, 22 Jun 2011 19:03:08 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-35-190.red.bezeqint.net [79.176.35.190]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN6003AVUP1SB@szxml12-in.huawei.com> for clue@ietf.org; Wed, 22 Jun 2011 19:03:08 +0800 (CST) Date: Wed, 22 Jun 2011 14:01:05 +0300 From: Roni Even In-reply-to: To: clue@ietf.org Message-id: <00ea01cc30cb$b370a4e0$1a51eea0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acwgtful7GZchzauRXesaYkPcku3fAABxlgABANx/MA= References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> <4DE6A0A3.7090009@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A407@ESESSCMS0356.eemea.ericsson.se> <4DE6CF0D.8050104@cisco.com> Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 11:03:12 -0000 In term of the use cases my experience is that the participant is the endpoint itself, this is usually a fixed name like "conference room 1" or "Roni's room system" and this is what typically appears when you call a remote system or look at the conference roster. So RFC 4353 term is good. There is also a need to be able to specify who is currently using the system and any qualified name that will say that this are the current people in the conference will serve. I am not sure that the current equipment makes it easy to provide this information. Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Coverdale > Sent: Thursday, June 02, 2011 3:49 AM > To: 'Paul Kyzivat' > Cc: clue@ietf.org > Subject: Re: [clue] Definitions: Participant > > > >-----Original Message----- > >From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >Sent: Wednesday, June 01, 2011 7:45 PM > >To: Paul Coverdale > >Cc: 'Christer Holmberg'; 'Mary Barnes'; clue@ietf.org > >Subject: Re: [clue] Definitions: Participant > > > > > >(In XCON conferences anyway. I guess IETF82 is conference too, that > has > >human participants - though they are more properly called > "registrants" > >I think.) > > > > It's a philosophical point, I suppose, but would the typical > "participant" > in IETF conferences consider themselves as a "person", or as a > "software > element that connects a user or automata to a conference". > > Actually, RFC 4353 got it right in one definition. I've noticed a few > "Conference-Unaware Participants". > > ...Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6174 (20110602) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6175 (20110602) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > From stephen.botzko@gmail.com Wed Jun 22 04:28:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D7E11E8126 for ; Wed, 22 Jun 2011 04:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOp2WN74Wt0x for ; Wed, 22 Jun 2011 04:28:55 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A7EF411E811C for ; Wed, 22 Jun 2011 04:28:54 -0700 (PDT) Received: by vws12 with SMTP id 12so712185vws.31 for ; Wed, 22 Jun 2011 04:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rJyzhN8dB2pV+K1qXg0WMK1K0aJL7NU/im+aw1S4rXU=; b=QAb0oVals+3rScXqWwCTv37ANb+7JfqcuHZPR431/XtTZvqcUTkGx/a6TcKVq8+Cws oNUmoshqU4Z3MRHCniEbRQEurwbKy5u9E9pmOMr4HNPw9TsPV5BiGRFRFhOjeBsuc97x mVaoN9tCcPXUF4CNqLnyN8An77sNHhIK5DvEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uTbGu6d4m3iab7yPsQeHfmwtEHPYuN+uZO/SEBB9iK8P148YWf6HFDlQhjUTio1sJL nfb46wy1964zmRbE1bVc99MPU5+YSU4Q4o+G+tN9k/g037i9/iDYsHi4CFefTPJYIz5o DvCBD/p78eyG/UAY5xzq8RHHwG5javsHQL+yU= MIME-Version: 1.0 Received: by 10.52.98.198 with SMTP id ek6mr786191vdb.240.1308742133908; Wed, 22 Jun 2011 04:28:53 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Wed, 22 Jun 2011 04:28:53 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 22 Jun 2011 07:28:53 -0400 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf307abdebfe865e04a64b4528 Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 11:28:56 -0000 --20cf307abdebfe865e04a64b4528 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 22, 2011 at 1:24 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi Stephen, > > >I understand you are advocating a general mechanism, which is why I > especially want to see use cases showing the need for the panned, plain, > thresholded, linear, non-linear rendering types you > >proposed. If someone has other rendering types, then they would be > helpful too. > > > >For me the negotiation of "rendering type" is a mechanism. I am thinking > all we need is number of channels, but I am quite willing to change my view > if the use cases show more is needed. > > What do you mean by "number of channels"? > > In the SDP a=rtpmap attribute you are able to indicate the number of audio > channels, but I don't think that helps. > > Setting aside binaural for now, I am envisioning that I am receiving three audio channels, and that CLUE mechanisms are telling me "left, center, right" for each channel. I think that's all I need to know in order to render the audio properly, but I am thinking you don't agree. That I would also need to know "panning" vs "plain"??? I don't understand what you are thinking I would do differently if I knew that, which is why I am wanting more use cases. Regards, > > Christer > > > > > > > On Tue, Jun 21, 2011 at 2:11 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > Hi, > > > >I would like to see use cases, particularly for > non-binaural proposals. It seems to me that a receiver doesn't really >care > if the stereo it is receiving is "panned", "plain" or "thresholded", or if > it is linear or non-linear. So use cases >motivating those choices would be > helpful. > > > >Also, the proposal is for a specific mechanism ("rendering > type"). It may be premature to identify the mechanism >in the requirements > - since often there are multiple ways to achieve the desired ends. > > > > > Again, I am not suggesting to specify a specific mechanism - > only a mechanism to negotiate the rendering type mechanism. > > > > Yes, I am using binaural as a rendering type EXAMPLE, but > you are the one who keep saying that I am trying to specify binaural :) > > > > Regards, > > > > Christer > > > > > On Mon, Jun 20, 2011 at 5:47 PM, Allyn Romanow (allyn) < > allyn@cisco.com> wrote: > > > Hi Christer, > > I think that you are proposing that CLUE needs a mechanism > to pass > information, such as a tag, on "rendering type", for > example, binaural, > threshold, etc. > Is that correct? > > And that you are not asking for any more from CLUE than > simply > identifying the rendering type. > Is that correct? > > IF both of these statements are correct, than personally I > think it is > fine TO include the information of rendering type, such as > "binaural", > by some mechanism, such as a tag, AS LONG AS there is an > accepted Use > Case that shows the necessity of communicating the rendering > type, such > as "thresholding" or "panning". > > How do other people feel about this? > > Thanks, > Allyn > > -----Original Message----- > > From: Christer Holmberg [mailto: > christer.holmberg@ericsson.com] > Sent: Monday, June 20, 2011 12:23 PM > To: Allyn Romanow (allyn); Mary Barnes > > Cc: clue@ietf.org; Botzko, Stephen; > Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on centralized media mixing > > Hi Allyn, > > >Still trying to get clarification- > > > >I read your description of various types of rendering. > >Still trying to understand what you want from CLUE- > >If we have a tag that says "binaural" or stereo, sub > binaural, are we > >done? > > Of course we could have a binaural specific SDP attribute, > e.g. > a=binaural. > > But, again, what we are proposing is a general mechanism, > that could > look something like: > > a=rendering-type = > > could then e.g. be "binaural", but it could also be > something > else (we showed a few example in the e-mail). > > >Or do you want CLUE to describe how to do some kind of > rendering? To > say > >something more about specific rendering functions? > > No, CLUE doesn't need to say anything about that. > > There would of course need to be a rendering description > associated with > each rendering type value, but CLUE wouldn't define those. > > The idea is that an IANA registry is created, where people > can register > their rendering type values. > > Regards, > > Christer > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto: > christer.holmberg@ericsson.com] > > Sent: Sunday, June 19, 2011 10:29 PM > > To: Allyn Romanow (allyn); Mary Barnes > > > Cc: clue@ietf.org; Botzko, Stephen; > Bill Mauchly (bmauchly) > > Subject: RE: [clue] Requirement on centralized media > mixing > > > > > > Hi Allyn, > > > > I appologise that it took some time to reply. > > > > We've been working on some definition/example text (I sent > it to the > > list just a few minutes ago), which I hope will clarify > some of the > > questions that have been asked. > > > > >Also, what kind of support are you asking for binaural? I > believe > it's > > often considered as a subset of stereo. What are you > asking for? A > > simple tag that says "binaural", or the specification > > >of a rendering system for binaural? Precisely what are > asking for? > > > > From CLUE, we are only asking for a general mechanism to > request and > > indicate different rendering types (see definition in > other e-mail). > > > > An example of such rendering type is binaural, BUT we are > *NOT* asking > > CLUE to define any binaural specific SDP attributes etc. > If such are > > needed, we agree that it needs to be done as a separate > task. > > > > Before I try to answer your other questions, please take a > look at the > > definition/example e-mail, which I hope will clarify what > we mean by > > rendering and rendering type. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Christer - > > > > In spirit I am enthusiastic about what you are > proposing > (meaning > > good quality mobile participation). I'm not clear on how > the spirit > > becomes instantiated in our protocol, so I have some > questions below J > > > > Thanks, > > > > Allyn > > > > > > > > > From: clue-bounces@ietf.org clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org clue-bounces@ietf.org>] On > > > Behalf Of Christer Holmberg > > Sent: Tuesday, June 14, 2011 7:23 AM > > > To: clue@ietf.org > > > Subject: [clue] Requirement on centralized media > mixing > > > > > > > > > > > > Hi, > > > > > > > > During the last interim meeting (May 12th) we > discussed a > > requirement proposal > > > > stating that an endpoint must be able to request > central audio > > rendering > > > > of different predefined formats, including 3D > binaural > rendering. > > > > (Link to proposal: http://www.ietf.org/mail- > > archive/web/clue/current/msg00179.html) > > > > > > > > The proposal was well received, with the reservation > that it > > should not be mandatory > > > > for the solution to implement centralized 3D > binaural rendering, > > > i.e.an endpoint should > > > > > be able to request 3D binaural rendering, but had no > guaranty > > that such rendering was > > > > supported by the system. > > > > > > > > It was decided to look how such requirement could > look like. > > > > > > > > When I look the -03 version of the req draft, > Requirement 2c > > states: > > > > > > > > "The solution MUST NOT preclude the use of > binaural audio." > > > > > > > > I think that requirement is unclear, and it doesn't > really give > > any guidance to our work. > > > > > > > > Due to that, and also due to the fact that rather > than talking > > about specific rendering types, > > > > I would like to propose more general requirement > text on the > > negotiation of the media mixing type, > > > > and the usage of centralized media mixing in the > first place. > > > > > > > > The mechanism would be extendable, so new types can > be added in > > future. > > > > > > > > So, the proposed requirements are: > > > > > > > > REQ-x: It MUST be possible to negotiate the usage > of > > centralized media mixing. System support of centralized > media mixing > is > > optional. > > > > > > > > REQ-y: When centralized media mixing is used, it > MUST be > > possible to negotiate the type of media rendering provided > for each > > media stream received by a client. > > > > --- > > > > [ar] I have a few questions/comments: > > > > 1. The term "negotiate" troubles me as I > think it means > a > > particular form of communication that dictates the > solution. What is > > being asked for is the receiver to know that it is > receiving > > "centralized media mixing". This may not be the end > product of a > > negotiation. The same is true of the use of the term > negotiate in the > > second requirement. What is needed is a mechanism by which > the > receiver > > may know what type of "media rendering" is being received. > > > > So, I'd rather offer, The solution must support > a means for > > identifying a stream which is "centralized media mixing". > > > > And, When "centralized media mixing" is used, the > solution must > > support a means for identifying... > > > > > > > > 2. Also, I'm not too sure what "media > rendering", the > > phrase in the second reqmt, represents- SDP and RTP > recognize audio > > channels and recognize codecs. Is this what is referred to > as "media > > rendering"? Or is it something different? What very > specifically? > > > > > > > > 3. After reading more of the discussion, I > realize that I > > don't fully understand what is meant in the first reqmt by > "centralized > > media mixing" or "rendering", which term is used in > another email. I > > had thought you meant the usual audio mixing such as > discussed in RFC > > 5117.( I figured it was an understood part of the topology > so didn't > > need to be called out in particular. But I don't mind > calling it > out.) > > In any case, now I'm not sure what you mean, maybe it is > something > > other than typical MCU mixing behavior as described in RFC > 5117? > > > > > > > > 4. As for the discussion of binaural.. here is > what it > > seems like to me.. AVP, RFC 3551 specifies the number of > audio > > channels, what they refer to, and types of codecs. > Binaural is > > neither. As you say, Christer, it's a type of stereo > channel. Steve > > feels that "binaural" must be recognized in SDP, which of > course, it > is > > not currently. > > > > > > > > I'm not entirely sure what needs to be specified > about binaural, > > given that it is neither channel -type nor codec-type. > What needs to > be > > standardized? This question is probably more for Steve, or > both of > you. > > If the receiving device knows it's getting binaural > stereo, then it > can > > run some algorithms to improve quality and if it isn't > binaural, it > > won't run those algs., or something analogous? If that is > the case, I > > don't see what needs to be standardized that isn't already > > standardized... But I'm eager to learn. > > > > > > > > Thanks- > > > > Allyn > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > _______________________________________________ > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > --20cf307abdebfe865e04a64b4528 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 22, 2011 at 1:24 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Stephen,

>I understand you are advocating a general mechanism, which is why I esp= ecially want to see use cases showing the need for the panned, plain, thres= holded, linear, non-linear rendering types you
>proposed. =A0If someone has other rendering types, then they would be h= elpful too.
>
>For me the negotiation of "rendering type" is a mechanism. = =A0I am thinking all we need is number of channels, but I am quite willing = to change my view if the use cases show more is needed.

What do you mean by "number of channels"?

In the SDP a=3Drtpmap attribute you are able to indicate the number of audi= o channels, but I don't think that helps.

Setting aside binaural for now, I am envisioning that= I am receiving three audio channels, and that CLUE mechanisms are telling = me "left, center, right" for each channel.=A0 I think that's = all I need to know in order to render the audio properly, but I am thinking= you don't agree.=A0 That I would also need to know "panning"= vs "plain"???=A0 I don't understand what you are thinking I = would do differently if I knew that, which is why I am wanting more use cas= es.

Regards,

Christer






=A0 =A0 =A0 =A0On Tue, Jun 21, 2011 at 2:11 PM, Christer Holmberg <christer.holmberg@ericsson.co= m> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hi,


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>I would like to see use cases, particul= arly for non-binaural proposals. =A0It seems to me that a receiver doesn= 9;t really >care if the stereo it is receiving is "panned", &q= uot;plain" or "thresholded", or if it is linear or non-linea= r. So use cases >motivating those choices would be helpful.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>Also, the proposal is for a specific me= chanism ("rendering type"). =A0It may be premature to identify th= e mechanism >in the requirements - since often there are multiple ways t= o achieve the desired ends.




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Again, I am not suggesting to specify a spe= cific mechanism - only a mechanism to negotiate the rendering type mechanis= m.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yes, I am using binaural as a rendering typ= e EXAMPLE, but you are the one who keep saying that I am trying to specify = binaural :)



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



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Christer




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On Mon, Jun 20, 2011 at 5:47 PM, Allyn Roma= now (allyn) <allyn@cisco.com<m= ailto:allyn@cisco.com>> wrote:=


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hi Christer,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I think that you are proposing that CLUE ne= eds a mechanism to pass
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0information, such as a tag, on "render= ing type", for example, binaural,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0threshold, etc.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Is that correct?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0And that you are not asking for any more fr= om CLUE than simply
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0identifying the rendering type.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Is that correct?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IF both of these statements are correct, th= an personally I think it is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fine TO include the information of renderin= g type, such as "binaural",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0by some mechanism, such as a tag, AS LONG A= S there is an accepted Use
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Case that shows the necessity of communicat= ing the rendering type, such
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0as "thresholding" or "pannin= g".

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0How do other people feel about this?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Allyn

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-----Original Message-----

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0From: Christer Holmberg [mailto:christer.holmberg@ericsson.com&l= t;mailto:christer.holmber= g@ericsson.com>]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sent: Monday, June 20, 2011 12:23 PM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0To: Allyn Romanow (allyn); Mary Barnes

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Cc: clue@i= etf.org<mailto:clue@ietf.org>= ;; Botzko, Stephen; Bill Mauchly (bmauchly)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Subject: RE: [clue] Requirement on centrali= zed media mixing

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hi Allyn,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>Still trying to get clarification-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>I read your description of various type= s of rendering.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>Still trying to understand what you wan= t from CLUE-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>If we have a tag that says "binaur= al" or stereo, sub binaural, are we
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>done?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Of course we could have a binaural specific= SDP attribute, e.g.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a=3Dbinaural.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0But, again, what we are proposing is a gene= ral mechanism, that could
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0look something like:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a=3Drendering-type =3D <value>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<value> could then e.g. be "bina= ural", but it could also be something
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else (we showed a few example in the e-mail= ).

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>Or do you want CLUE to describe how to = do some kind of rendering? To
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0say
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>something more about specific rendering= functions?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0No, CLUE doesn't need to say anything a= bout that.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0There would of course need to be a renderin= g description associated with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0each rendering type value, but CLUE wouldn&= #39;t define those.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The idea is that an IANA registry is create= d, where people can register
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0their rendering type values.

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

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Christer



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

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com<= /a><mailto:christer.ho= lmberg@ericsson.com>]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Sent: Sunday, June 19, 2011 10:29 PM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> To: Allyn Romanow (allyn); Mary Barnes=

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Cc: c= lue@ietf.org<mailto:clue@ietf.org>; Botzko, Stephen; Bill Mauchly (bmauchly)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Subject: RE: [clue] Requirement on cen= tralized media mixing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Hi Allyn,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> I appologise that it took some time to= reply.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> We've been working on some definit= ion/example text (I sent it to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> list just a few minutes ago), which I = hope will clarify some of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> questions that have been asked.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >Also, what kind of support are you= asking for binaural? I believe
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it's
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> often considered as a subset of stereo= . What are you asking for? A
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> simple tag that says "binaural&qu= ot;, or =A0the specification
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >of a rendering system for binaural= ? Precisely what are asking for?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> From CLUE, we are only asking for a ge= neral mechanism to request and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> indicate different rendering types (se= e definition in other e-mail).
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> An example of such rendering type is b= inaural, BUT we are *NOT* asking
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> CLUE to define any binaural specific S= DP attributes etc. If such are
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> needed, we agree that it needs to be d= one as a separate task.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Before I try to answer your other ques= tions, please take a look at the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> definition/example e-mail, which I hop= e will clarify what we mean by
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> rendering and rendering type.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Regards,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Christer
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 Hi Christer -
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 In spirit I am enthusiasti= c about what you are proposing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(meaning
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> good quality mobile participation). I&= #39;m not clear on how the spirit
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> becomes instantiated in our protocol, = so I have some questions below J
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 Allyn
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 From: clue-bounces@ietf.org<mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org<mailto:clue-bounces@ietf.org>] On

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Behalf Of Christer Holmberg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 Sent: Tuesday, June 14, 20= 11 7:23 AM

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 To: clue@ietf.org<mailto:clu= e@ietf.org>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 Subject: [clue] Requiremen= t on centralized media mixing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 Hi,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 During the last interim me= eting (May 12th) we discussed a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> requirement proposal
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 stating that an endpoint m= ust be able to request central audio
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> rendering
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 of different predefined fo= rmats, including 3D binaural
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rendering.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 (Link to proposal: http://www.ietf.org/mail-<= /a>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> archive/web/clue/current/msg00179.html= )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 The proposal was well rece= ived, with the reservation that it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> should not be mandatory
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 for the solution to implem= ent centralized 3D binaural rendering,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> i.e.an<http://i.e.= an> endpoint should

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 be able to request 3D bina= ural rendering, but had no guaranty
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> that such rendering was
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 supported by the system. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 It was decided to look how= such requirement could look like.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 When I look the -03 versio= n of the req draft, Requirement 2c
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> states:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 =A0 =A0 "The solution= MUST NOT preclude the use of binaural audio."
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 I think that requirement i= s unclear, and it doesn't really give
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> any guidance to our work.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 Due to that, and also due = to the fact that rather than talking
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> about specific rendering types,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 I would like to propose mo= re general requirement text on the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> negotiation of the media mixing type,<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 and the usage of centraliz= ed media mixing in the first place.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 The mechanism would be ext= endable, so new types can be added in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> future.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 So, the proposed requireme= nts are:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 REQ-x: =A0 =A0It MUST be p= ossible to negotiate the usage of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> centralized media mixing. System suppo= rt of centralized media mixing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> optional.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 REQ-y: =A0 =A0When central= ized media mixing is used, it MUST be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> possible to negotiate the type of medi= a rendering provided for each
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> media stream received by a client.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 =A0---
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 [ar] I have a few question= s/comments:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 1. =A0 =A0 =A0 =A0 The ter= m "negotiate" troubles me as I think it means
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> particular form of communication that = dictates the solution. What is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> being asked for is the receiver to kno= w that it is receiving
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> "centralized media mixing". = This may not be the end product of a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> negotiation. The same is true of the u= se of the term negotiate in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> second requirement. What is needed is = a mechanism by which the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0receiver
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> may know what type of "media rend= ering" is being received.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 =A0 =A0 =A0So, I'd rat= her offer, The solution must support a means for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> identifying a stream which is "ce= ntralized media mixing".
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 And, When "centralize= d media mixing" is used, the solution must
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> support a means for identifying...
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 2. =A0 =A0 =A0 Also, =A0I&= #39;m not too sure what "media rendering", =A0the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> phrase in the second reqmt, represents= - SDP and RTP recognize audio
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> channels and recognize codecs. Is this= what is referred to as "media
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> rendering"? Or is it something di= fferent? What very specifically?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 3. =A0 =A0 =A0 After readi= ng more of the discussion, I realize that I
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> don't fully understand what is mea= nt in the first reqmt by
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"centralized
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> media mixing" or "rendering&= quot;, which term is used in another email. I
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> had thought you meant the usual audio = mixing such as discussed in RFC
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> 5117.( I figured it was an understood = part of the topology so didn't
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> need to =A0be called out in particular= . But I don't mind calling it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0out.)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> In any case, now I'm not sure what= you mean, maybe it is something
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> other than typical MCU mixing behavior= as described in RFC 5117?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 4. =A0 =A0 =A0 As for the = discussion of binaural.. here is what it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> seems like to me.. AVP, RFC 3551 speci= fies =A0the number of =A0audio
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> channels, what they refer to, =A0and t= ypes of codecs. Binaural is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> neither. As you say, Christer, it'= s a type of stereo channel. =A0Steve
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> feels that "binaural" must b= e recognized in SDP, which of course, it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> not currently.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 I'm not entirely sure = what needs to be specified about binaural,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> given that it is neither channel -type= nor codec-type. What needs to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> standardized? This question is probabl= y more for Steve, or both of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0you.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> If the receiving device knows it's= getting binaural stereo, then it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0can
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> run some algorithms to improve quality= and if it isn't binaural, it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> won't run those algs., or somethin= g analogous? If that is the case, I
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> don't see what needs to be standar= dized that isn't already
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> standardized... But I'm eager to l= earn.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 Thanks-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 Allyn
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 Regards,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> =A0 =A0 =A0 Christer
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________________________________________= ____
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing list

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue@ietf.= org<mailto:clue@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/clue





--20cf307abdebfe865e04a64b4528-- From coverdale@sympatico.ca Wed Jun 22 04:46:45 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7227411E8103 for ; Wed, 22 Jun 2011 04:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uP3iCRPSmTO for ; Wed, 22 Jun 2011 04:46:44 -0700 (PDT) Received: from mail9.itu.ch (mail9.itu.ch [156.106.192.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCBE11E80BC for ; Wed, 22 Jun 2011 04:46:43 -0700 (PDT) Received: from PaulNewPC ([156.106.218.33]) by mail9.itu.ch (8.13.8/8.14.4) with SMTP id p5MBkBDu001932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2011 13:46:14 +0200 From: "Paul Coverdale" To: "'Roni Even'" , References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> <4DE6A0A3.7090009@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A407@ESESSCMS0356.eemea.ericsson.se> <4DE6CF0D.8050104@cisco.com> <00ea01cc30cb$b370a4e0$1a51eea0$%roni@huawei.com> In-Reply-To: <00ea01cc30cb$b370a4e0$1a51eea0$%roni@huawei.com> Date: Wed, 22 Jun 2011 13:46:10 +0200 Message-ID: <000f01cc30d1$fd18f0b0$f74ad210$@ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: Acwgtful7GZchzauRXesaYkPcku3fAABxlgABANx/MAAAZXeMA== X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (mail9.itu.ch [156.106.192.39]); Wed, 22 Jun 2011 13:46:14 +0200 (CEST) Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 11:46:45 -0000 I'm a bit confused now. The RFC4353 definition of participant doesn't talk about an "end-point", but mentions "user" (although there is no definition of user). ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Roni Even >Sent: Wednesday, June 22, 2011 1:01 PM >To: clue@ietf.org >Subject: Re: [clue] Definitions: Participant > >In term of the use cases my experience is that the participant is the >endpoint itself, this is usually a fixed name like "conference room 1" >or >"Roni's room system" and this is what typically appears when you call a >remote system or look at the conference roster. So RFC 4353 term is >good. > >There is also a need to be able to specify who is currently using the >system >and any qualified name that will say that this are the current people in >the >conference will serve. I am not sure that the current equipment makes it >easy to provide this information. >Roni Even > From Even.roni@huawei.com Wed Jun 22 05:04:48 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A7011E8130 for ; Wed, 22 Jun 2011 05:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.581 X-Spam-Level: X-Spam-Status: No, score=-105.581 tagged_above=-999 required=5 tests=[AWL=1.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTm4IyWPa1oC for ; Wed, 22 Jun 2011 05:04:47 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A510A11E812F for ; Wed, 22 Jun 2011 05:04:47 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN600MQKXJWPB@szxga03-in.huawei.com> for clue@ietf.org; Wed, 22 Jun 2011 20:04:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN600A9ZXJWP6@szxga03-in.huawei.com> for clue@ietf.org; Wed, 22 Jun 2011 20:04:44 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-35-190.red.bezeqint.net [79.176.35.190]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN60057VXJOZT@szxml12-in.huawei.com>; Wed, 22 Jun 2011 20:04:44 +0800 (CST) Date: Wed, 22 Jun 2011 15:02:38 +0300 From: Roni Even In-reply-to: <000f01cc30d1$fd18f0b0$f74ad210$@ca> To: 'Paul Coverdale' , clue@ietf.org Message-id: <00f401cc30d4$4e808fb0$eb81af10$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acwgtful7GZchzauRXesaYkPcku3fAABxlgABANx/MAAAZXeMAAArK9Q References: <4DE57EA5.6060406@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4F90@ESESSCMS0356.eemea.ericsson.se> <4DE6A0A3.7090009@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A407@ESESSCMS0356.eemea.ericsson.se> <4DE6CF0D.8050104@cisco.com> <00ea01cc30cb$b370a4e0$1a51eea0$%roni@huawei.com> <000f01cc30d1$fd18f0b0$f74ad210$@ca> Subject: Re: [clue] Definitions: Participant X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 12:04:48 -0000 Paul, I meant that it is the equipment (software element in RFC 4353) and not the person who is currently using the system. This can be a video conferencing system, MCU or gateway. Roni > -----Original Message----- > From: Paul Coverdale [mailto:coverdale@sympatico.ca] > Sent: Wednesday, June 22, 2011 2:46 PM > To: 'Roni Even'; clue@ietf.org > Subject: RE: [clue] Definitions: Participant > > I'm a bit confused now. The RFC4353 definition of participant doesn't > talk > about an "end-point", but mentions "user" (although there is no > definition > of user). > > ...Paul > > >-----Original Message----- > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > >Roni Even > >Sent: Wednesday, June 22, 2011 1:01 PM > >To: clue@ietf.org > >Subject: Re: [clue] Definitions: Participant > > > >In term of the use cases my experience is that the participant is the > >endpoint itself, this is usually a fixed name like "conference room 1" > >or > >"Roni's room system" and this is what typically appears when you call > a > >remote system or look at the conference roster. So RFC 4353 term is > >good. > > > >There is also a need to be able to specify who is currently using the > >system > >and any qualified name that will say that this are the current people > in > >the > >conference will serve. I am not sure that the current equipment makes > it > >easy to provide this information. > >Roni Even > > From christer.holmberg@ericsson.com Wed Jun 22 05:14:35 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993D911E8104 for ; Wed, 22 Jun 2011 05:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.885 X-Spam-Level: X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIPx3DXLOJwM for ; Wed, 22 Jun 2011 05:14:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0C711E8130 for ; Wed, 22 Jun 2011 05:14:33 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-77-4e01dca06f91 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AC.FC.20773.0ACD10E4; Wed, 22 Jun 2011 14:14:24 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 22 Jun 2011 14:14:24 +0200 From: Christer Holmberg To: Stephen Botzko Date: Wed, 22 Jun 2011 14:14:22 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acwwz5HmKEHLOzzASAWu+ugkH7OczQABXOwA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A548@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 12:14:35 -0000 Hi, >>>I understand you are advocating a general mechanism, which is why I espe= cially want to see use cases showing >>>the need for the panned, plain, thresholded, linear, non-linear renderin= g types you >>>proposed. If someone has other rendering types, then they would be helpf= ul too. >> >>>For me the negotiation of "rendering type" is a mechanism. I am thinkin= g all we need is number of channels, but I am quite willing to change my vi= ew if the use cases show more is needed. >> >>What do you mean by "number of channels"? >> >>In the SDP a=3Drtpmap attribute you are able to indicate the number of au= dio channels, >>but I don't think that helps. > >Setting aside binaural for now, I am envisioning that I am receiving three= audio channels, and that >CLUE mechanisms are telling me "left, center, right" for each channel. I = think that's all I need to >know in order to render the audio properly, but I am thinking you don't ag= ree. It depends on WHO is rendering. An entity receiving all "raw material" can of course do whatever it wants w= ith it. But, in the centralized rendering case the idea is that the renderi= ng is done on behalf of a client, since the client due to different reasons= can't do it itself. >That I would also need to know "panning" vs "plain"??? I don't understand = what you are thinking I would do differently if I knew that, which is why I= am wanting more use cases. Maybe there is no need to separate "panning" vs "plain". I will need to loo= k into that (there for sure is a need to separate binaural from other stere= o, though). Other use-cases is which video and/or audio streams are sent towards a clie= nt in the first place. E.g. Sending the video of the most active speaker, s= ending the audio of the 4 most active speakers, etc. I consider that being = different rendering types also, because they affect how the output stream i= s generated. Regards, Christer Hi, >I would like to see use cases, particularly= for non-binaural proposals. It seems to me that a receiver doesn't really= >care if the stereo it is receiving is "panned", "plain" or "thresholded",= or if it is linear or non-linear. So use cases >motivating those choices w= ould be helpful. > >Also, the proposal is for a specific mechan= ism ("rendering type"). It may be premature to identify the mechanism >in = the requirements - since often there are multiple ways to achieve the desir= ed ends. Again, I am not suggesting to specify a spec= ific mechanism - only a mechanism to negotiate the rendering type mechanism= . Yes, I am using binaural as a rendering type= EXAMPLE, but you are the one who keep saying that I am trying to specify b= inaural :) Regards, Christer On Mon, Jun 20, 2011 at 5:47 PM, Allyn Roman= ow (allyn) > wrote: Hi Christer, I think that you are proposing that CLUE nee= ds a mechanism to pass information, such as a tag, on "rendering ty= pe", for example, binaural, threshold, etc. Is that correct? And that you are not asking for any more fro= m CLUE than simply identifying the rendering type. Is that correct? IF both of these statements are correct, tha= n personally I think it is fine TO include the information of rendering= type, such as "binaural", by some mechanism, such as a tag, AS LONG AS= there is an accepted Use Case that shows the necessity of communicati= ng the rendering type, such as "thresholding" or "panning". How do other people feel about this? Thanks, Allyn -----Original Message----- From: Christer Holmberg [mailto:christer.hol= mberg@ericsson.com] Sent: Monday, June 20, 2011 12:23 PM To: Allyn Romanow (allyn); Mary Barnes Cc: clue@ietf.org; Bot= zko, Stephen; Bill Mauchly (bmauchly) Subject: RE: [clue] Requirement on centraliz= ed media mixing Hi Allyn, >Still trying to get clarification- > >I read your description of various types of= rendering. >Still trying to understand what you want fr= om CLUE- >If we have a tag that says "binaural" or st= ereo, sub binaural, are we >done? Of course we could have a binaural specific = SDP attribute, e.g. a=3Dbinaural. But, again, what we are proposing is a gener= al mechanism, that could look something like: a=3Drendering-type =3D could then e.g. be "binaural", but i= t could also be something else (we showed a few example in the e-mail)= . >Or do you want CLUE to describe how to do s= ome kind of rendering? To say >something more about specific rendering fun= ctions? No, CLUE doesn't need to say anything about = that. There would of course need to be a rendering= description associated with each rendering type value, but CLUE wouldn't= define those. The idea is that an IANA registry is created= , where people can register their rendering type values. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.h= olmberg@ericsson.com] > Sent: Sunday, June 19, 2011 10:29 PM > To: Allyn Romanow (allyn); Mary Barnes > Cc: clue@ietf.org; B= otzko, Stephen; Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on central= ized media mixing > > > Hi Allyn, > > I appologise that it took some time to rep= ly. > > We've been working on some definition/exam= ple text (I sent it to the > list just a few minutes ago), which I hope= will clarify some of the > questions that have been asked. > > >Also, what kind of support are you asking= for binaural? I believe it's > often considered as a subset of stereo. Wh= at are you asking for? A > simple tag that says "binaural", or the s= pecification > >of a rendering system for binaural? Preci= sely what are asking for? > > From CLUE, we are only asking for a genera= l mechanism to request and > indicate different rendering types (see de= finition in other e-mail). > > An example of such rendering type is binau= ral, BUT we are *NOT* asking > CLUE to define any binaural specific SDP a= ttributes etc. If such are > needed, we agree that it needs to be done = as a separate task. > > Before I try to answer your other question= s, please take a look at the > definition/example e-mail, which I hope wi= ll clarify what we mean by > rendering and rendering type. > > Regards, > > Christer > > > > > > > > > > > > > > > Hi Christer - > > In spirit I am enthusiastic about wh= at you are proposing (meaning > good quality mobile participation). I'm no= t clear on how the spirit > becomes instantiated in our protocol, so I= have some questions below J > > Thanks, > > Allyn > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Tuesday, June 14, 2011 7:23 AM > To: clue@ietf.org > Subject: [clue] Requirement on centr= alized media mixing > > > > > > Hi, > > > > During the last interim meeting (May= 12th) we discussed a > requirement proposal > > stating that an endpoint must be abl= e to request central audio > rendering > > of different predefined formats, inc= luding 3D binaural rendering. > > (Link to proposal: http://www.ietf.o= rg/mail- > archive/web/clue/current/msg00179.html) > > > > The proposal was well received, with= the reservation that it > should not be mandatory > > for the solution to implement centra= lized 3D binaural rendering, > i.e.an endpoint should > > be able to request 3D binaural rende= ring, but had no guaranty > that such rendering was > > supported by the system. > > > > It was decided to look how such requ= irement could look like. > > > > When I look the -03 version of the r= eq draft, Requirement 2c > states: > > > > "The solution MUST NOT preclude = the use of binaural audio." > > > > I think that requirement is unclear,= and it doesn't really give > any guidance to our work. > > > > Due to that, and also due to the fac= t that rather than talking > about specific rendering types, > > I would like to propose more general= requirement text on the > negotiation of the media mixing type, > > and the usage of centralized media m= ixing in the first place. > > > > The mechanism would be extendable, s= o new types can be added in > future. > > > > So, the proposed requirements are: > > > > REQ-x: It MUST be possible to neg= otiate the usage of > centralized media mixing. System support o= f centralized media mixing is > optional. > > > > REQ-y: When centralized media mix= ing is used, it MUST be > possible to negotiate the type of media re= ndering provided for each > media stream received by a client. > > --- > > [ar] I have a few questions/comments= : > > 1. The term "negotiate" trou= bles me as I think it means a > particular form of communication that dict= ates the solution. What is > being asked for is the receiver to know th= at it is receiving > "centralized media mixing". This may not b= e the end product of a > negotiation. The same is true of the use o= f the term negotiate in the > second requirement. What is needed is a me= chanism by which the receiver > may know what type of "media rendering" is= being received. > > So, I'd rather offer, The solut= ion must support a means for > identifying a stream which is "centralized= media mixing". > > And, When "centralized media mixing"= is used, the solution must > support a means for identifying... > > > > 2. Also, I'm not too sure wha= t "media rendering", the > phrase in the second reqmt, represents- SD= P and RTP recognize audio > channels and recognize codecs. Is this wha= t is referred to as "media > rendering"? Or is it something different? = What very specifically? > > > > 3. After reading more of the d= iscussion, I realize that I > don't fully understand what is meant in th= e first reqmt by "centralized > media mixing" or "rendering", which term i= s used in another email. I > had thought you meant the usual audio mixi= ng such as discussed in RFC > 5117.( I figured it was an understood part= of the topology so didn't > need to be called out in particular. But = I don't mind calling it out.) > In any case, now I'm not sure what you mea= n, maybe it is something > other than typical MCU mixing behavior as = described in RFC 5117? > > > > 4. As for the discussion of bi= naural.. here is what it > seems like to me.. AVP, RFC 3551 specifies= the number of audio > channels, what they refer to, and types o= f codecs. Binaural is > neither. As you say, Christer, it's a type= of stereo channel. Steve > feels that "binaural" must be recognized i= n SDP, which of course, it is > not currently. > > > > I'm not entirely sure what needs to = be specified about binaural, > given that it is neither channel -type nor= codec-type. What needs to be > standardized? This question is probably mo= re for Steve, or both of you. > If the receiving device knows it's getting= binaural stereo, then it can > run some algorithms to improve quality and= if it isn't binaural, it > won't run those algs., or something analog= ous? If that is the case, I > don't see what needs to be standardized th= at isn't already > standardized... But I'm eager to learn. > > > > Thanks- > > Allyn > > > > Regards, > > > > Christer > > > > ____________________________________________= ___ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Wed Jun 22 05:32:53 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172BF11E80D4 for ; Wed, 22 Jun 2011 05:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.676 X-Spam-Level: X-Spam-Status: No, score=-101.676 tagged_above=-999 required=5 tests=[AWL=-3.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_32=0.6, MANGLED_SOLTNS=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FGWLBe9F2Ht for ; Wed, 22 Jun 2011 05:32:51 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A734411E8073 for ; Wed, 22 Jun 2011 05:32:50 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN600I9KYU9RM@szxga05-in.huawei.com> for clue@ietf.org; Wed, 22 Jun 2011 20:32:33 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN600861YU3WF@szxga05-in.huawei.com> for clue@ietf.org; Wed, 22 Jun 2011 20:32:33 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-35-190.red.bezeqint.net [79.176.35.190]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN6003X2YTQP2@szxml11-in.huawei.com>; Wed, 22 Jun 2011 20:32:27 +0800 (CST) Date: Wed, 22 Jun 2011 15:30:18 +0300 From: Roni Even In-reply-to: To: 'Stephen Botzko' , 'Christer Holmberg' Message-id: <00f801cc30d8$2a888140$7f9983c0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_xobEz2BWlupGWbC3KQmwjA)" Content-language: en-us Thread-index: Acww0Bm8VDTJV27YTXeT+ssx3eOWAQABm+Gw References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> Cc: clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 12:32:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_xobEz2BWlupGWbC3KQmwjA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, In XCON data model http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-31#section-4.2. 13 there is a specification of video layout control that describes the continuous presence layout. There was no requirement for something similar for audio. I assume that Christer wants to see something similar to that definition for audio but I am not sure if there is a use case for that, currently SDP RTPMAP has the encoding parameters that allows the specification of the number of audio channels which as far as I understand is sufficient for telepresence systems. If there is a general need to negotiate not only the number of channels but also a non codec specific way to negotiate audio mixing parameter, I am not sure this is a CLUE topic. In which case its support will be part of interoperability requirement with SIP systems that do not support telepresence extensions. Regards Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, June 22, 2011 2:29 PM To: Christer Holmberg Cc: clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing On Wed, Jun 22, 2011 at 1:24 AM, Christer Holmberg wrote: Hi Stephen, >I understand you are advocating a general mechanism, which is why I especially want to see use cases showing the need for the panned, plain, thresholded, linear, non-linear rendering types you >proposed. If someone has other rendering types, then they would be helpful too. > >For me the negotiation of "rendering type" is a mechanism. I am thinking all we need is number of channels, but I am quite willing to change my view if the use cases show more is needed. What do you mean by "number of channels"? In the SDP a=rtpmap attribute you are able to indicate the number of audio channels, but I don't think that helps. Setting aside binaural for now, I am envisioning that I am receiving three audio channels, and that CLUE mechanisms are telling me "left, center, right" for each channel. I think that's all I need to know in order to render the audio properly, but I am thinking you don't agree. That I would also need to know "panning" vs "plain"??? I don't understand what you are thinking I would do differently if I knew that, which is why I am wanting more use cases. Regards, Christer On Tue, Jun 21, 2011 at 2:11 PM, Christer Holmberg wrote: Hi, >I would like to see use cases, particularly for non-binaural proposals. It seems to me that a receiver doesn't really >care if the stereo it is receiving is "panned", "plain" or "thresholded", or if it is linear or non-linear. So use cases >motivating those choices would be helpful. > >Also, the proposal is for a specific mechanism ("rendering type"). It may be premature to identify the mechanism >in the requirements - since often there are multiple ways to achieve the desired ends. Again, I am not suggesting to specify a specific mechanism - only a mechanism to negotiate the rendering type mechanism. Yes, I am using binaural as a rendering type EXAMPLE, but you are the one who keep saying that I am trying to specify binaural :) Regards, Christer On Mon, Jun 20, 2011 at 5:47 PM, Allyn Romanow (allyn) > wrote: Hi Christer, I think that you are proposing that CLUE needs a mechanism to pass information, such as a tag, on "rendering type", for example, binaural, threshold, etc. Is that correct? And that you are not asking for any more from CLUE than simply identifying the rendering type. Is that correct? IF both of these statements are correct, than personally I think it is fine TO include the information of rendering type, such as "binaural", by some mechanism, such as a tag, AS LONG AS there is an accepted Use Case that shows the necessity of communicating the rendering type, such as "thresholding" or "panning". How do other people feel about this? Thanks, Allyn -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 20, 2011 12:23 PM To: Allyn Romanow (allyn); Mary Barnes Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) Subject: RE: [clue] Requirement on centralized media mixing Hi Allyn, >Still trying to get clarification- > >I read your description of various types of rendering. >Still trying to understand what you want from CLUE- >If we have a tag that says "binaural" or stereo, sub binaural, are we >done? Of course we could have a binaural specific SDP attribute, e.g. a=binaural. But, again, what we are proposing is a general mechanism, that could look something like: a=rendering-type = could then e.g. be "binaural", but it could also be something else (we showed a few example in the e-mail). >Or do you want CLUE to describe how to do some kind of rendering? To say >something more about specific rendering functions? No, CLUE doesn't need to say anything about that. There would of course need to be a rendering description associated with each rendering type value, but CLUE wouldn't define those. The idea is that an IANA registry is created, where people can register their rendering type values. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sunday, June 19, 2011 10:29 PM > To: Allyn Romanow (allyn); Mary Barnes > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on centralized media mixing > > > Hi Allyn, > > I appologise that it took some time to reply. > > We've been working on some definition/example text (I sent it to the > list just a few minutes ago), which I hope will clarify some of the > questions that have been asked. > > >Also, what kind of support are you asking for binaural? I believe it's > often considered as a subset of stereo. What are you asking for? A > simple tag that says "binaural", or the specification > >of a rendering system for binaural? Precisely what are asking for? > > From CLUE, we are only asking for a general mechanism to request and > indicate different rendering types (see definition in other e-mail). > > An example of such rendering type is binaural, BUT we are *NOT* asking > CLUE to define any binaural specific SDP attributes etc. If such are > needed, we agree that it needs to be done as a separate task. > > Before I try to answer your other questions, please take a look at the > definition/example e-mail, which I hope will clarify what we mean by > rendering and rendering type. > > Regards, > > Christer > > > > > > > > > > > > > > > Hi Christer - > > In spirit I am enthusiastic about what you are proposing (meaning > good quality mobile participation). I'm not clear on how the spirit > becomes instantiated in our protocol, so I have some questions below J > > Thanks, > > Allyn > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Tuesday, June 14, 2011 7:23 AM > To: clue@ietf.org > Subject: [clue] Requirement on centralized media mixing > > > > > > Hi, > > > > During the last interim meeting (May 12th) we discussed a > requirement proposal > > stating that an endpoint must be able to request central audio > rendering > > of different predefined formats, including 3D binaural rendering. > > (Link to proposal: http://www.ietf.org/mail- > archive/web/clue/current/msg00179.html) > > > > The proposal was well received, with the reservation that it > should not be mandatory > > for the solution to implement centralized 3D binaural rendering, > i.e.an endpoint should > > be able to request 3D binaural rendering, but had no guaranty > that such rendering was > > supported by the system. > > > > It was decided to look how such requirement could look like. > > > > When I look the -03 version of the req draft, Requirement 2c > states: > > > > "The solution MUST NOT preclude the use of binaural audio." > > > > I think that requirement is unclear, and it doesn't really give > any guidance to our work. > > > > Due to that, and also due to the fact that rather than talking > about specific rendering types, > > I would like to propose more general requirement text on the > negotiation of the media mixing type, > > and the usage of centralized media mixing in the first place. > > > > The mechanism would be extendable, so new types can be added in > future. > > > > So, the proposed requirements are: > > > > REQ-x: It MUST be possible to negotiate the usage of > centralized media mixing. System support of centralized media mixing is > optional. > > > > REQ-y: When centralized media mixing is used, it MUST be > possible to negotiate the type of media rendering provided for each > media stream received by a client. > > --- > > [ar] I have a few questions/comments: > > 1. The term "negotiate" troubles me as I think it means a > particular form of communication that dictates the solution. What is > being asked for is the receiver to know that it is receiving > "centralized media mixing". This may not be the end product of a > negotiation. The same is true of the use of the term negotiate in the > second requirement. What is needed is a mechanism by which the receiver > may know what type of "media rendering" is being received. > > So, I'd rather offer, The solution must support a means for > identifying a stream which is "centralized media mixing". > > And, When "centralized media mixing" is used, the solution must > support a means for identifying... > > > > 2. Also, I'm not too sure what "media rendering", the > phrase in the second reqmt, represents- SDP and RTP recognize audio > channels and recognize codecs. Is this what is referred to as "media > rendering"? Or is it something different? What very specifically? > > > > 3. After reading more of the discussion, I realize that I > don't fully understand what is meant in the first reqmt by "centralized > media mixing" or "rendering", which term is used in another email. I > had thought you meant the usual audio mixing such as discussed in RFC > 5117.( I figured it was an understood part of the topology so didn't > need to be called out in particular. But I don't mind calling it out.) > In any case, now I'm not sure what you mean, maybe it is something > other than typical MCU mixing behavior as described in RFC 5117? > > > > 4. As for the discussion of binaural.. here is what it > seems like to me.. AVP, RFC 3551 specifies the number of audio > channels, what they refer to, and types of codecs. Binaural is > neither. As you say, Christer, it's a type of stereo channel. Steve > feels that "binaural" must be recognized in SDP, which of course, it is > not currently. > > > > I'm not entirely sure what needs to be specified about binaural, > given that it is neither channel -type nor codec-type. What needs to be > standardized? This question is probably more for Steve, or both of you. > If the receiving device knows it's getting binaural stereo, then it can > run some algorithms to improve quality and if it isn't binaural, it > won't run those algs., or something analogous? If that is the case, I > don't see what needs to be standardized that isn't already > standardized... But I'm eager to learn. > > > > Thanks- > > Allyn > > > > Regards, > > > > Christer > > > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --Boundary_(ID_xobEz2BWlupGWbC3KQmwjA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

In XCON data model http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-31#section-4.2.13 there is a specification of video layout control that describes the continuous presence layout. There was no requirement for something similar for audio. I assume that Christer wants to see something similar to that definition for audio but I am not sure if there is a use case for that, currently SDP RTPMAP has the encoding parameters that allows the specification of the number of audio channels which as far as I understand is sufficient for telepresence systems.< mal> 

If there is a general need to negotiate not only the number of channels but also a non codec specific way to negotiate audio mixing parameter, I am not sure this is a CLUE topic. In which case its support will be part of interoperability requirement with SIP systems that do not support telepresence extensions.

 

Regards

Roni Even

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko
Sent: Wednesday, June 22, 2011 2:29 PM
To: Christer Holmberg
Cc: clue@ietf.org
Subject: Re: [clue] Requirement on centralized media mixing

 

 

On Wed, Jun 22, 2011 at 1:24 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:


Hi Stephen lass=MsoNormal style='margin-bottom:12.0pt'>
>I understand you are advocating a general mechanism, which is why I especially want to see use cases showing the need for the panned, plain, thresholded, linear, non-linear rendering types you
>proposed.  If someone has other rendering types, then they would be helpful too.
>
>For me the negotiation of "rendering type" is a mechanism.  I am thinking all we need is number of channels, but I am quite willing to change my view if the use cases show more is needed.

What do you mean by "number of channels"?

In the SDP a=rtpmap attribute you are able to indicate the number of audio channels, but I don't think that helps.

Setting aside binaural for now, I am envisioning that I am receiving three audio channels, and that CLUE mechanisms are telli ng me &q uot; for each channel.  I think that's all I need to know in order to render the audio properly, but I am thinking you don't agree.  That I would also need to know "panning" vs "plain"???  I don't understand what you are thinking I would do differently if I knew that, which is why I am wanting more use cases.

Regards,

Christer







       On Tue, Jun 21, 2011 at 2:11 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:


               Hi,


               >I would like to ly for non-binaural proposals.  It seems to me that a receiver doesn't really >care if the stereo it is receiving is "panned", "plain" or "thresholded", or if it is linear or non-linear. So use cases >motivating those choices would be helpful.
               >
               >Also, the proposal is for a specific mechanism ("rendering type").  It may be premature to identify the mechanism >in the requirements - since often there are multiple ways to achieve the desired ends.




               Again, I am not suggesting to specify a specific mechanism - only a mechanism to negotiate the rendering type mechanism.



               Yes, I am using binaural as a rendering type EXAMPLE, but you are the one who keep saying that I am try )



               Regards,



               Christer




               On Mon, Jun 20, 2011 at 5:47 PM, Allyn Romanow (allyn) <allyn@cisco.com<mailto:allyn@cisco.com>> wrote:


               Hi Christer,

               I think that you are proposing that CLUE needs a mechanism to pass
               information, such as a tag, on "rendering type", for example, binaural,
               threshold, etc.
               Is that correct?

               And tha t you ar from CLUE than simply
               identifying the rendering type.
               Is that correct?

               IF both of these statements are correct, than personally I think it is
               fine TO include the information of rendering type, such as "binaural",
               by some mechanism, such as a tag, AS LONG AS there is an accepted Use
               Case that shows the necessity of communicating the rendering type, such
               as "thresholding" or "panning".

               How do other people feel about this?

               T hanks,
               -----Original Message-----

               From: Christer Holmberg [mailto:christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>]
               Sent: Monday, June 20, 2011 12:23 PM
               To: Allyn Romanow (allyn); Mary Barnes

               Cc: clue@ietf.org<mailto:clue@ietf.org>; Botzko, Stephen; Bill Mauchly (bmauchly)
               Subject: RE: [clue] Requirement on centralized media mixing

              &n bsp;Hi A ;            >Still trying to get clarification-
               >
               >I read your description of various types of rendering.
               >Still trying to understand what you want from CLUE-
               >If we have a tag that says "binaural" or stereo, sub binaural, are we
               >done?

               Of course we could have a binaural specific SDP attribute, e.g.
               a=binaural.

               But, again, what we are proposing is a general mechanism, that could
               look something like :


               <value> could then e.g. be "binaural", but it could also be something
               else (we showed a few example in the e-mail).

               >Or do you want CLUE to describe how to do some kind of rendering? To
               say
               >something more about specific rendering functions?

               No, CLUE doesn't need to say anything about that.

               There would of course need to be a rendering description associated with
               each rendering type value, but CLUE wouldn't define those.< br>
& ;        The idea is that an IANA registry is created, where people can register
               their rendering type values.

               Regards,

               Christer



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

               > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>]
               > Sent: Sunday, June 19, 2011 10:29 PM
               > To: Allyn Romanow (allyn); Mary Barnes

               > Cc: clue@ietf.org>; Botzko, Stephen; Bill Mauchly (bmauchly)
               > Subject: RE: [clue] Requirement on centralized media mixing
               >
               >
               > Hi Allyn,
               >
               > I appologise that it took some time to reply.
               >
               > We've been working on some definition/example text (I sent it to the
               > list just a few minutes ago), which I hope will clarify some of the
              &n bsp;> asked.
               >
               > >Also, what kind of support are you asking for binaural? I believe
               it's
               > often considered as a subset of stereo. What are you asking for? A
               > simple tag that says "binaural", or  the specification
               > >of a rendering system for binaural? Precisely what are asking for?
               >
               > From CLUE, we are only asking for a general mechanism to request and
               > indicate different rendering types (see definition in other e-mail).
&nbs nbsp;      >
               > An example of such rendering type is binaural, BUT we are *NOT* asking
               > CLUE to define any binaural specific SDP attributes etc. If such are
               > needed, we agree that it needs to be done as a separate task.
               >
               > Before I try to answer your other questions, please take a look at the
               > definition/example e-mail, which I hope will clarify what we mean by
               > rendering and rendering type.
               >
               > Regards,
  & nbsp; &n    >
               > Christer
               >
               >
               >
               >
               >
               >
               >
               >
               >
               >
               >
               >
               >
               >
      & ;  >       Hi Christer -
               >
               >       In spirit I am enthusiastic about what you are proposing
               (meaning
               > good quality mobile participation). I'm not clear on how the spirit
               > becomes instantiated in our protocol, so I have some questions below J
               >
               >       Thanks,
               >
               >       Allyn
               >
        &nbs p;   bsp;              >

               >       From: clue-bounces@ietf.org<mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org<mailto:clue-bounces@ietf.org>] On

               > Behalf Of Christer Holmberg
               >       Sent: Tuesday, June 14, 2011 7:23 AM

               >       To: clue@ietf.org<mailto:clue@ietf.org>

               >       Subject: [clue] Requirement on central p;              >
               >
               >
               >
               >
               >       Hi,
               >
               >
               >
               >       During the last interim meeting (May 12th) we discussed a
               > requirement proposal
               >
               >       stating that an endpoint must be able to >               > rendering
               >
               >       of different predefined formats, including 3D binaural
               rendering.
               >
               >       (Link to proposal: http://www.ietf.org/mail-
               > archive/web/clue/current/msg00179.html)
               >
               >
               >
               >       The proposal was well re ceived, it
               > should not be mandatory
               >
               >       for the solution to implement centralized 3D binaural rendering,

               > i.e.an<http://i.e.an> endpoint should

               >
               >       be able to request 3D binaural rendering, but had no guaranty
               > that such rendering was
               >
               >       supported by the system.
      p;  >
               >
               >
               >       It was decided to look how such requirement could look like.
               >
               >
               >
               >       When I look the -03 version of the req draft, Requirement 2c
               > states:
               >
               >
               >
               >           "The sol ution MU f binaural audio."
               >
               >
               >
               >       I think that requirement is unclear, and it doesn't really give
               > any guidance to our work.
               >
               >
               >
               >       Due to that, and also due to the fact that rather than talking
               > about specific rendering types,
               >
            & nbsp; &n bsp; I would like to propose more general requirement text on the
               > negotiation of the media mixing type,
               >
               >       and the usage of centralized media mixing in the first place.
               >
               >
               >
               >       The mechanism would be extendable, so new types can be added in
               > future.
               >
               >
               >
      & ;  >       So, the proposed requirements are:
               >
               >
               >
               >       REQ-x:    It MUST be possible to negotiate the usage of
               > centralized media mixing. System support of centralized media mixing
               is
               > optional.
               >
               >
               >
               >       REQ-y:    When centralized media mixing i sp;              > possible to negotiate the type of media rendering provided for each
               > media stream received by a client.
               >
               >        ---
               >
               >       [ar] I have a few questions/comments:
               >
               >       1.         The term "negotiate" troubles me as I think it means
               a
               > particular form of communication that dictates the solution. What is< nbsp;        > being asked for is the receiver to know that it is receiving
               > "centralized media mixing". This may not be the end product of a
               > negotiation. The same is true of the use of the term negotiate in the
               > second requirement. What is needed is a mechanism by which the
               receiver
               > may know what type of "media rendering" is being received.
               >
               >            So, I'd rather offer, The solution must support a means for
               > ident ifying a ntralized media mixing".
               >
               >       And, When "centralized media mixing" is used, the solution must
               > support a means for identifying...
               >
               >
               >
               >       2.       Also,  I'm not too sure what "media rendering",  the
               > phrase in the second reqmt, represents- SDP and RTP recognize audio
               > channels and recognize codecs. Is this what is referred to as "media
  & ;      > rendering"? Or is it something different? What very specifically?
               >
               >
               >
               >       3.       After reading more of the discussion, I realize that I
               > don't fully understand what is meant in the first reqmt by
               "centralized
               > media mixing" or "rendering", which term is used in another email. I
               > had thought you meant the usual audio mixing such as discussed in RFC
               > 5117.( stood part of the topology so didn't
               > need to  be called out in particular. But I don't mind calling it
               out.)
               > In any case, now I'm not sure what you mean, maybe it is something
               > other than typical MCU mixing behavior as described in RFC 5117?
               >
               >
               >
               >       4.       As for the discussion of binaural.. here is what it
               > seems like to me.. AVP, RFC 3551 specifies  the number of  audio
    & ;    > channels, what they refer to,  and types of codecs. Binaural is
               > neither. As you say, Christer, it's a type of stereo channel.  Steve
               > feels that "binaural" must be recognized in SDP, which of course, it
               is
               > not currently.
               >
               >
               >
               >       I'm not entirely sure what needs to be specified about binaural,
               > given that it is neither channel -type nor codec-type. What needs to
  &nb sp; &nbs nbsp;  be
               > standardized? This question is probably more for Steve, or both of
               you.
               > If the receiving device knows it's getting binaural stereo, then it
               can
               > run some algorithms to improve quality and if it isn't binaural, it
               > won't run those algs., or something analogous? If that is the case, I
               > don't see what needs to be standardized that isn't already
               > standardized... But I'm eager to learn.
               >
            p;              >
               >       Thanks-
               >
               >       Allyn
               >
               >
               >
               >       Regards,
               >
               >
               >
               >       Christer
               >
               >
&nbs nbsp;      >
               >
               _______________________________________________
               clue mailing list

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

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



 

--Boundary_(ID_xobEz2BWlupGWbC3KQmwjA)-- From Even.roni@huawei.com Wed Jun 22 06:04:07 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EA011E8159 for ; Wed, 22 Jun 2011 06:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.329 X-Spam-Level: X-Spam-Status: No, score=-105.329 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-BidwDtz8xk for ; Wed, 22 Jun 2011 06:04:02 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2C62511E8139 for ; Wed, 22 Jun 2011 06:04:02 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN7003MM05EJH@szxga04-in.huawei.com> for clue@ietf.org; Wed, 22 Jun 2011 21:00:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN700CHK05EB3@szxga04-in.huawei.com> for clue@ietf.org; Wed, 22 Jun 2011 21:00:50 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-35-190.red.bezeqint.net [79.176.35.190]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN7003OX057P2@szxml11-in.huawei.com>; Wed, 22 Jun 2011 21:00:50 +0800 (CST) Date: Wed, 22 Jun 2011 15:58:47 +0300 From: Roni Even In-reply-to: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6357@xmb-sjc-221.amer.cisco.com> To: "'Allyn Romanow (allyn)'" Message-id: <00fd01cc30dc$2496e930$6dc4bb90$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_i03/KpPUjde7C+zzw9oUYA)" Content-language: en-us Thread-index: Acwwj6m4l9xOCH4NSAO5KaTj+QfrLwATEhGg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6357@xmb-sjc-221.amer.cisco.com> Cc: clue@ietf.org Subject: Re: [clue] use case for multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 13:04:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_i03/KpPUjde7C+zzw9oUYA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Allyn, I sis not add it, I sent the following question to the list on May 17th and did not get any response yet "Hi Mark, I am trying to see how to fit this case in the use-cases draft. When I ignore the term "virtual space" and look at the description it talks about describing the view point of each cameras that may overlap and allowing the receivers to select the view they want. I see some resemblance to the education usage described. Will it make sense to mention that the camera can provide different view in the point to point symmetric or asymmetric case which has a case with a PTZ camera." Roni Even From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] Sent: Wednesday, June 22, 2011 6:51 AM To: Roni Even Cc: clue@ietf.org Subject: use case for multi-view Hi Roni, I thought Mark's use case for multi-view was added to the Use Case doc, but I couldn't find it there? Is it just not added yet or is there some issue with it? Thanks much --Boundary_(ID_i03/KpPUjde7C+zzw9oUYA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Allyn,

I sis not add it, I sent the following question to the list on May 17th and did not get any response yet

 

"Hi Mark,

I am trying to see how to fit this case in the use-cases draft. When I ignore the term "virtual space" and look at the description it talks about describing the view point of each cameras that may overlap and allowing the receivers to select the view they want. I see some resemblance to the education usage described.

Will it make sense t o mentio vide different view in the point to point symmetric or asymmetric case which has a case with a PTZ camera."

 

 

Roni Even

 

 

From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent: Wednesday, June 22, 2011 6:51 AM
To: Roni Even
Cc: clue@ie tf.org

 

Hi Roni,

I thought Mark’s use case for multi-view was added to the Use Case doc, but I couldn’t find it there? Is it just not added yet or is there some issue with it?

 

Thanks much

--Boundary_(ID_i03/KpPUjde7C+zzw9oUYA)-- From stephane.proust@orange-ftgroup.com Wed Jun 22 06:13:21 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4CC1F0C39 for ; Wed, 22 Jun 2011 06:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htQQ6hRdHhFS for ; Wed, 22 Jun 2011 06:13:20 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9A89D1F0C35 for ; Wed, 22 Jun 2011 06:13:20 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 787D1FC4013 for ; Wed, 22 Jun 2011 15:13:19 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 701B8FC400E for ; Wed, 22 Jun 2011 15:13:19 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 15:13:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jun 2011 15:13:17 +0200 Message-ID: <4D1AA2A55522044480C9B9CF97A9340901BD0F39@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] clarification on requirements draft 03 Thread-Index: Acwv720MBk44QiS1RO+1tEnQLejyxwAzuDxQ References: From: To: X-OriginalArrivalTime: 22 Jun 2011 13:13:19.0508 (UTC) FILETIME=[27C64540:01CC30DE] Subject: [clue] clarification on requirements draft 03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 13:13:21 -0000 Hi I 've maybe missed some discussions related to some of the modifications = brought in draft 03 with respect to draft 02 but I would appreciate some = clarification/explanation about the limitation to 3 audio channels = introduced in REQMT-2b :=20 REQMT-2b: The solution MUST support a means to identify monaural, stereophonic (2.0), and 3.0 (left, center, right) audio channels. Is it the intent to exclude the multiplexing of a higher number of = channels ?=20 If the intent is to introduce some limitation, what is the rationale = behind and why such limit is set to 3.0 ? Thanks St=E9phane From stephen.botzko@gmail.com Wed Jun 22 07:30:38 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827BF21F84D0 for ; Wed, 22 Jun 2011 07:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuuCAE+2MI+z for ; Wed, 22 Jun 2011 07:30:36 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1832F21F8490 for ; Wed, 22 Jun 2011 07:30:36 -0700 (PDT) Received: by vws12 with SMTP id 12so875914vws.31 for ; Wed, 22 Jun 2011 07:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8e+j9LyZWRLdXu5v/dU03e5L1LrNG16kf2CGugOCqbU=; b=DaL1Acg97XgU3ZTYFApjus1lwoGJBpM7NveYXz790ylu2DY09YYJR+TCQ8wCbgjtb4 vVkc+MJcHn8VPdMOPZTwl5BN48qNqigxQl7S/VnTYHQ+62sgNtGhpxlA53B4zmu3L3JR 7GfJlIc6DYL7y1rPdjrt/ce1NDPvKncpg0WrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jsZacS/sjsIB6/97c1a19pwOakg18IH1h2I6YrG4DeMm9MWw9ybQ9Jab/EI26tE5+6 LU6meoHN4Lzd0yRl1pkDhlLTuMM98PPaE4W7L4A7iiqMg1zU/i4iJ1I+WO47eDsO7NJD C89afurYQJGIazv3nisfMYYTzO6uIpY4Txhb4= MIME-Version: 1.0 Received: by 10.52.98.5 with SMTP id ee5mr1075244vdb.200.1308753035430; Wed, 22 Jun 2011 07:30:35 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Wed, 22 Jun 2011 07:30:35 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB559A548@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A548@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 22 Jun 2011 10:30:35 -0400 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf307f34a6c68c0c04a64dcf78 Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:30:38 -0000 --20cf307f34a6c68c0c04a64dcf78 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 22, 2011 at 8:14 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > >>>I understand you are advocating a general mechanism, which is why I > especially want to see use cases showing > >>>the need for the panned, plain, thresholded, linear, non-linear > rendering types you > >>>proposed. If someone has other rendering types, then they would be > helpful too. > >> > >>>For me the negotiation of "rendering type" is a mechanism. I am > thinking all we need is number of channels, but I am quite willing to change > my view if the use cases show more is needed. > >> > >>What do you mean by "number of channels"? > >> > >>In the SDP a=rtpmap attribute you are able to indicate the number of > audio channels, > >>but I don't think that helps. > > > >Setting aside binaural for now, I am envisioning that I am receiving three > audio channels, and that > >CLUE mechanisms are telling me "left, center, right" for each channel. I > think that's all I need to > >know in order to render the audio properly, but I am thinking you don't > agree. > > It depends on WHO is rendering. > > An entity receiving all "raw material" can of course do whatever it wants > with it. But, in the centralized rendering case the idea is that the > rendering is done on behalf of a client, since the client due to different > reasons can't do it itself. > Even there, if I can receive 3 channels I am not sure why I need to tell the rendering server anything else. (I do get why I might want to choose the audio layout, but am thinking that is a distinct facility). > > >That I would also need to know "panning" vs "plain"??? I don't understand > what you are thinking I would do differently if I knew that, which is why I > am wanting more use cases. > > Maybe there is no need to separate "panning" vs "plain". I will need to > look into that (there for sure is a need to separate binaural from other > stereo, though). > Although we disagree on whether binaural is a telepresence feature, we agree that it has value and that its use should [at least] not be precluded. I am trying to set it aside, because I think I understand the requirements for that adequately [for now anyway]. I agree that binaural needs to be distinguished from normal stereo. Devices using speakers shouldn't (ideally must not) get binaural audio; since it will often degrade their audio quality; devices using stereo earphones would prefer to get it; since it enhances their audio quality. And you must not apply the hrtf filter more than once on the signal path. Where I remain somewhat confused is on the generalization proposal. I am not sure I can define "rendering type" very well, and the examples I've seen posted are actually confusing me more, rather than less. I am hoping that re-focusing on desired behaviors/use cases will be more productive. If we capture the behavioral requirements correctly [specifically for the central server case], then I am sure that we will come up with an appropriate protocol design. > Other use-cases is which video and/or audio streams are sent towards a > client in the first place. E.g. Sending the video of the most active > speaker, sending the audio of the 4 most active speakers, etc. I consider > that being different rendering types also, because they affect how the > output stream is generated. > > Regards, > > Christer > > > > > > > > Hi, > > > >I would like to see use cases, particularly > for non-binaural proposals. It seems to me that a receiver doesn't really > >care if the stereo it is receiving is "panned", "plain" or "thresholded", > or if it is linear or non-linear. So use cases >motivating those choices > would be helpful. > > > >Also, the proposal is for a specific > mechanism ("rendering type"). It may be premature to identify the mechanism > >in the requirements - since often there are multiple ways to achieve the > desired ends. > > > > > Again, I am not suggesting to specify a > specific mechanism - only a mechanism to negotiate the rendering type > mechanism. > > > > Yes, I am using binaural as a rendering type > EXAMPLE, but you are the one who keep saying that I am trying to specify > binaural :) > > > > Regards, > > > > Christer > > > > > On Mon, Jun 20, 2011 at 5:47 PM, Allyn > Romanow (allyn) > wrote: > > > Hi Christer, > > I think that you are proposing that CLUE > needs a mechanism to pass > information, such as a tag, on "rendering > type", for example, binaural, > threshold, etc. > Is that correct? > > And that you are not asking for any more from > CLUE than simply > identifying the rendering type. > Is that correct? > > IF both of these statements are correct, than > personally I think it is > fine TO include the information of rendering > type, such as "binaural", > by some mechanism, such as a tag, AS LONG AS > there is an accepted Use > Case that shows the necessity of > communicating the rendering type, such > as "thresholding" or "panning". > > How do other people feel about this? > > Thanks, > Allyn > > -----Original Message----- > > From: Christer Holmberg [mailto: > christer.holmberg@ericsson.com] > Sent: Monday, June 20, 2011 12:23 PM > To: Allyn Romanow (allyn); Mary Barnes > > Cc: clue@ietf.org; > Botzko, Stephen; Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on > centralized media mixing > > Hi Allyn, > > >Still trying to get clarification- > > > >I read your description of various types of > rendering. > >Still trying to understand what you want > from CLUE- > >If we have a tag that says "binaural" or > stereo, sub binaural, are we > >done? > > Of course we could have a binaural specific > SDP attribute, e.g. > a=binaural. > > But, again, what we are proposing is a > general mechanism, that could > look something like: > > a=rendering-type = > > could then e.g. be "binaural", but it > could also be something > else (we showed a few example in the e-mail). > > >Or do you want CLUE to describe how to do > some kind of rendering? To > say > >something more about specific rendering > functions? > > No, CLUE doesn't need to say anything about > that. > > There would of course need to be a rendering > description associated with > each rendering type value, but CLUE wouldn't > define those. > > The idea is that an IANA registry is created, > where people can register > their rendering type values. > > Regards, > > Christer > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto: > christer.holmberg@ericsson.com] > > Sent: Sunday, June 19, 2011 10:29 PM > > To: Allyn Romanow (allyn); Mary Barnes > > > Cc: clue@ietf.org; > Botzko, Stephen; Bill Mauchly (bmauchly) > > Subject: RE: [clue] Requirement on > centralized media mixing > > > > > > Hi Allyn, > > > > I appologise that it took some time to > reply. > > > > We've been working on some > definition/example text (I sent it to the > > list just a few minutes ago), which I hope > will clarify some of the > > questions that have been asked. > > > > >Also, what kind of support are you asking > for binaural? I believe > it's > > often considered as a subset of stereo. > What are you asking for? A > > simple tag that says "binaural", or the > specification > > >of a rendering system for binaural? > Precisely what are asking for? > > > > From CLUE, we are only asking for a general > mechanism to request and > > indicate different rendering types (see > definition in other e-mail). > > > > An example of such rendering type is > binaural, BUT we are *NOT* asking > > CLUE to define any binaural specific SDP > attributes etc. If such are > > needed, we agree that it needs to be done > as a separate task. > > > > Before I try to answer your other > questions, please take a look at the > > definition/example e-mail, which I hope > will clarify what we mean by > > rendering and rendering type. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Christer - > > > > In spirit I am enthusiastic about > what you are proposing > (meaning > > good quality mobile participation). I'm not > clear on how the spirit > > becomes instantiated in our protocol, so I > have some questions below J > > > > Thanks, > > > > Allyn > > > > > > > > > From: clue-bounces@ietf.org clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org clue-bounces@ietf.org>] On > > > Behalf Of Christer Holmberg > > Sent: Tuesday, June 14, 2011 7:23 AM > > > To: clue@ietf.org clue@ietf.org> > > > Subject: [clue] Requirement on > centralized media mixing > > > > > > > > > > > > Hi, > > > > > > > > During the last interim meeting (May > 12th) we discussed a > > requirement proposal > > > > stating that an endpoint must be able > to request central audio > > rendering > > > > of different predefined formats, > including 3D binaural > rendering. > > > > (Link to proposal: > http://www.ietf.org/mail- > > archive/web/clue/current/msg00179.html) > > > > > > > > The proposal was well received, with > the reservation that it > > should not be mandatory > > > > for the solution to implement > centralized 3D binaural rendering, > > > i.e.an endpoint should > > > > > be able to request 3D binaural > rendering, but had no guaranty > > that such rendering was > > > > supported by the system. > > > > > > > > It was decided to look how such > requirement could look like. > > > > > > > > When I look the -03 version of the > req draft, Requirement 2c > > states: > > > > > > > > "The solution MUST NOT preclude > the use of binaural audio." > > > > > > > > I think that requirement is unclear, > and it doesn't really give > > any guidance to our work. > > > > > > > > Due to that, and also due to the fact > that rather than talking > > about specific rendering types, > > > > I would like to propose more general > requirement text on the > > negotiation of the media mixing type, > > > > and the usage of centralized media > mixing in the first place. > > > > > > > > The mechanism would be extendable, so > new types can be added in > > future. > > > > > > > > So, the proposed requirements are: > > > > > > > > REQ-x: It MUST be possible to > negotiate the usage of > > centralized media mixing. System support of > centralized media mixing > is > > optional. > > > > > > > > REQ-y: When centralized media > mixing is used, it MUST be > > possible to negotiate the type of media > rendering provided for each > > media stream received by a client. > > > > --- > > > > [ar] I have a few questions/comments: > > > > 1. The term "negotiate" > troubles me as I think it means > a > > particular form of communication that > dictates the solution. What is > > being asked for is the receiver to know > that it is receiving > > "centralized media mixing". This may not be > the end product of a > > negotiation. The same is true of the use of > the term negotiate in the > > second requirement. What is needed is a > mechanism by which the > receiver > > may know what type of "media rendering" is > being received. > > > > So, I'd rather offer, The > solution must support a means for > > identifying a stream which is "centralized > media mixing". > > > > And, When "centralized media mixing" > is used, the solution must > > support a means for identifying... > > > > > > > > 2. Also, I'm not too sure what > "media rendering", the > > phrase in the second reqmt, represents- SDP > and RTP recognize audio > > channels and recognize codecs. Is this what > is referred to as "media > > rendering"? Or is it something different? > What very specifically? > > > > > > > > 3. After reading more of the > discussion, I realize that I > > don't fully understand what is meant in the > first reqmt by > "centralized > > media mixing" or "rendering", which term is > used in another email. I > > had thought you meant the usual audio > mixing such as discussed in RFC > > 5117.( I figured it was an understood part > of the topology so didn't > > need to be called out in particular. But I > don't mind calling it > out.) > > In any case, now I'm not sure what you > mean, maybe it is something > > other than typical MCU mixing behavior as > described in RFC 5117? > > > > > > > > 4. As for the discussion of > binaural.. here is what it > > seems like to me.. AVP, RFC 3551 specifies > the number of audio > > channels, what they refer to, and types of > codecs. Binaural is > > neither. As you say, Christer, it's a type > of stereo channel. Steve > > feels that "binaural" must be recognized in > SDP, which of course, it > is > > not currently. > > > > > > > > I'm not entirely sure what needs to > be specified about binaural, > > given that it is neither channel -type nor > codec-type. What needs to > be > > standardized? This question is probably > more for Steve, or both of > you. > > If the receiving device knows it's getting > binaural stereo, then it > can > > run some algorithms to improve quality and > if it isn't binaural, it > > won't run those algs., or something > analogous? If that is the case, I > > don't see what needs to be standardized > that isn't already > > standardized... But I'm eager to learn. > > > > > > > > Thanks- > > > > Allyn > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > _______________________________________________ > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > --20cf307f34a6c68c0c04a64dcf78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 22, 2011 at 8:14 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

>>>I understand you are advocating a general mechanism, which is w= hy I especially want to see use cases showing
>>>the need for the panned, plain, thresholded, linear, non-linear= rendering types you
>>>proposed. If someone has other rendering types, then they would= be helpful too.
>>
>>>For me the negotiation of "rendering type" is a mecha= nism. =A0I am thinking all we need is number of channels, but I am quite wi= lling to change my view if the use cases show more is needed.
>>
>>What do you mean by "number of channels"?
>>
>>In the SDP a=3Drtpmap attribute you are able to indicate the number= of audio channels,
>>but I don't think that helps.
>
>Setting aside binaural for now, I am envisioning that I am receiving th= ree audio channels, and that
>CLUE mechanisms are telling me "left, center, right" for each= channel. =A0I think that's all I need to
>know in order to render the audio properly, but I am thinking you don&#= 39;t agree.

It depends on WHO is rendering.

An entity receiving all "raw material" can of course do whatever = it wants with it. But, in the centralized rendering case the idea is that t= he rendering is done on behalf of a client, since the client due to differe= nt reasons can't do it itself.
Even there, if I can receive 3 channels I am not sure why= I need to tell the rendering server anything else.=A0 (I do get why I migh= t want to choose the audio layout, but am thinking that is a distinct facil= ity).

>That I would also need to know "panning" vs "plain"= ??? I don't understand what you are thinking I would do differently if = I knew that, which is why I am wanting more use cases.

Maybe there is no need to separate "panning" vs "plain= ". I will need to look into that (there for sure is a need to separate= binaural from other stereo, though).=A0
Although we d= isagree on whether binaural is a telepresence feature, we agree that it has= value and that its use should [at least] not be precluded.=A0 I am trying = to set it aside, because I think I understand the requirements for that ade= quately [for now anyway]. I agree that binaural needs to be distinguished f= rom normal stereo.=A0 Devices using speakers shouldn't (ideally must no= t) get binaural audio; since it will often degrade their audio quality; dev= ices using stereo earphones would prefer to get it; since it enhances their= audio quality.=A0 And you must not apply the hrtf filter more than once on= the signal path.

Where I remain somewhat confused is on the generalization proposal.=A0 = I am not sure I can define "rendering type" very well, and the ex= amples I've seen posted are actually confusing me more, rather than les= s.=A0 I am hoping that re-focusing on desired behaviors/use cases will be m= ore productive.=A0 If we capture the behavioral requirements correctly [spe= cifically for the central server case], then I am sure that we will come up= with an appropriate protocol design.


Other use-cases is which video and/or audio streams are sent towards a clie= nt in the first place. E.g. Sending the video of the most active speaker, s= ending the audio of the 4 most active speakers, etc. I consider that being = different rendering types also, because they affect how the output stream i= s generated.

Regards,

Christer







=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi,


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >I would li= ke to see use cases, particularly for non-binaural proposals. =A0It seems t= o me that a receiver doesn't really >care if the stereo it is receiv= ing is "panned", "plain" or "thresholded", or= if it is linear or non-linear. So use cases >motivating those choices w= ould be helpful.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >Also, the = proposal is for a specific mechanism ("rendering type"). =A0It ma= y be premature to identify the mechanism >in the requirements - since of= ten there are multiple ways to achieve the desired ends.




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Again, I am no= t suggesting to specify a specific mechanism - only a mechanism to negotiat= e the rendering type mechanism.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yes, I am usin= g binaural as a rendering type EXAMPLE, but you are the one who keep saying= that I am trying to specify binaural :)



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Regards,



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Christer




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Mon, Jun 20= , 2011 at 5:47 PM, Allyn Romanow (allyn) <allyn@cisco.com<mailto:allyn= @cisco.com>> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi Christer,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I think that y= ou are proposing that CLUE needs a mechanism to pass
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 information, s= uch as a tag, on "rendering type", for example, binaural,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 threshold, etc= .
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Is that correc= t?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 And that you a= re not asking for any more from CLUE than simply
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 identifying th= e rendering type.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Is that correc= t?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IF both of the= se statements are correct, than personally I think it is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fine TO includ= e the information of rendering type, such as "binaural",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 by some mechan= ism, such as a tag, AS LONG AS there is an accepted Use
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Case that show= s the necessity of communicating the rendering type, such
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 as "thres= holding" or "panning".

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 How do other p= eople feel about this?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Allyn

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -----Original = Message-----

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sent: Monday, = June 20, 2011 12:23 PM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To: Allyn Roma= now (allyn); Mary Barnes

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cc: clue@ietf.org<mailto:clue@ietf.org>; Botzko, Stephen; Bill Mauchly (bmauchly) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subject: RE: [= clue] Requirement on centralized media mixing

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi Allyn,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >Still tryi= ng to get clarification-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >I read you= r description of various types of rendering.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >Still tryi= ng to understand what you want from CLUE-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >If we have= a tag that says "binaural" or stereo, sub binaural, are we
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >done?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Of course we c= ould have a binaural specific SDP attribute, e.g.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a=3Dbinaural.<= br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 But, again, wh= at we are proposing is a general mechanism, that could
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 look something= like:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a=3Drendering-= type =3D <value>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <value> = could then e.g. be "binaural", but it could also be something
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else (we showe= d a few example in the e-mail).

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >Or do you = want CLUE to describe how to do some kind of rendering? To
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 say
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >something = more about specific rendering functions?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 No, CLUE doesn= 't need to say anything about that.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 There would of= course need to be a rendering description associated with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 each rendering= type value, but CLUE wouldn't define those.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The idea is th= at an IANA registry is created, where people can register
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 their renderin= g type values.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Regards,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Christer



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

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > From: Chr= ister Holmberg [mailto:ch= rister.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Sent: Sun= day, June 19, 2011 10:29 PM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > To: Allyn= Romanow (allyn); Mary Barnes

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Cc: clue@ietf.org<mailto:clue@ietf.org>; Botzko, Stephen; Bill Mauchly (bmauchl= y)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Subject: = RE: [clue] Requirement on centralized media mixing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Hi Allyn,=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > I appolog= ise that it took some time to reply.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > We've= been working on some definition/example text (I sent it to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > list just= a few minutes ago), which I hope will clarify some of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > questions= that have been asked.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > >Also,= what kind of support are you asking for binaural? I believe
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 it's
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > often con= sidered as a subset of stereo. What are you asking for? A
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > simple ta= g that says "binaural", or =A0the specification
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > >of a = rendering system for binaural? Precisely what are asking for?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > From CLUE= , we are only asking for a general mechanism to request and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > indicate = different rendering types (see definition in other e-mail).
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > An exampl= e of such rendering type is binaural, BUT we are *NOT* asking
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > CLUE to d= efine any binaural specific SDP attributes etc. If such are
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > needed, w= e agree that it needs to be done as a separate task.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Before I = try to answer your other questions, please take a look at the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > definitio= n/example e-mail, which I hope will clarify what we mean by
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > rendering= and rendering type.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Regards,<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Christer<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 Hi Christer -
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 In spirit I am enthusiastic about what you are proposing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (meaning
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > good qual= ity mobile participation). I'm not clear on how the spirit
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > becomes i= nstantiated in our protocol, so I have some questions below J
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 Allyn
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 From: clue-bounces@ietf.org<mailto:clue-bounces@ietf.org<= /a>> [mailto:clue-bounces@ietf.= org<mailto:clue-bounces@iet= f.org>] On

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > Behalf Of= Christer Holmberg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 Sent: Tuesday, June 14, 2011 7:23 AM

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 To: clue@ietf.org<mailto:clue@ietf.org>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 Subject: [clue] Requirement on centralized media mixing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 Hi,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 During the last interim meeting (May 12th) we discussed a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > requireme= nt proposal
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 stating that an endpoint must be able to request central audio
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > rendering=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 of different predefined formats, including 3D binaural
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rendering.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 (Link to proposal: http://www.ietf.org/mail-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > archive/w= eb/clue/current/msg00179.html)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 The proposal was well received, with the reservation that it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > should no= t be mandatory
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 for the solution to implement centralized 3D binaural rendering,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > i.e.an<http://i.e.an> endpoint should

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 be able to request 3D binaural rendering, but had no guaranty
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > that such= rendering was
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 supported by the system.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 It was decided to look how such requirement could look like.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 When I look the -03 version of the req draft, Requirement 2c
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > states: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 =A0 =A0 "The solution MUST NOT preclude the use of binaural audio.= "
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 I think that requirement is unclear, and it doesn't really give
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > any guida= nce to our work.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 Due to that, and also due to the fact that rather than talking
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > about spe= cific rendering types,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 I would like to propose more general requirement text on the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > negotiati= on of the media mixing type,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 and the usage of centralized media mixing in the first place.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 The mechanism would be extendable, so new types can be added in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > future. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 So, the proposed requirements are:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 REQ-x: =A0 =A0It MUST be possible to negotiate the usage of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > centraliz= ed media mixing. System support of centralized media mixing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > optional.=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 REQ-y: =A0 =A0When centralized media mixing is used, it MUST be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > possible = to negotiate the type of media rendering provided for each
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > media str= eam received by a client.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 =A0---
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 [ar] I have a few questions/comments:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 1. =A0 =A0 =A0 =A0 The term "negotiate" troubles me as I thin= k it means
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > particula= r form of communication that dictates the solution. What is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > being ask= ed for is the receiver to know that it is receiving
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > "cen= tralized media mixing". This may not be the end product of a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > negotiati= on. The same is true of the use of the term negotiate in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > second re= quirement. What is needed is a mechanism by which the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 receiver
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > may know = what type of "media rendering" is being received.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 =A0 =A0 =A0So, I'd rather offer, The solution must support a means = for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > identifyi= ng a stream which is "centralized media mixing".
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 And, When "centralized media mixing" is used, the solution mu= st
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > support a= means for identifying...
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 2. =A0 =A0 =A0 Also, =A0I'm not too sure what "media rendering= ", =A0the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > phrase in= the second reqmt, represents- SDP and RTP recognize audio
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > channels = and recognize codecs. Is this what is referred to as "media
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > rendering= "? Or is it something different? What very specifically?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 3. =A0 =A0 =A0 After reading more of the discussion, I realize that I =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > don't= fully understand what is meant in the first reqmt by
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "centrali= zed
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > media mix= ing" or "rendering", which term is used in another email. I<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > had thoug= ht you meant the usual audio mixing such as discussed in RFC
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > 5117.( I = figured it was an understood part of the topology so didn't
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > need to = =A0be called out in particular. But I don't mind calling it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 out.)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > In any ca= se, now I'm not sure what you mean, maybe it is something
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > other tha= n typical MCU mixing behavior as described in RFC 5117?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 4. =A0 =A0 =A0 As for the discussion of binaural.. here is what it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > seems lik= e to me.. AVP, RFC 3551 specifies =A0the number of =A0audio
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > channels,= what they refer to, =A0and types of codecs. Binaural is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > neither. = As you say, Christer, it's a type of stereo channel. =A0Steve
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > feels tha= t "binaural" must be recognized in SDP, which of course, it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > not curre= ntly.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 I'm not entirely sure what needs to be specified about binaural, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > given tha= t it is neither channel -type nor codec-type. What needs to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > standardi= zed? This question is probably more for Steve, or both of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 you.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > If the re= ceiving device knows it's getting binaural stereo, then it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 can
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > run some = algorithms to improve quality and if it isn't binaural, it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > won't= run those algs., or something analogous? If that is the case, I
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > don't= see what needs to be standardized that isn't already
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > standardi= zed... But I'm eager to learn.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 Thanks-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 Allyn
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 Regards,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 = =A0 Christer
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ______________= _________________________________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clue mailing l= ist

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

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








--20cf307f34a6c68c0c04a64dcf78-- From stephen.botzko@gmail.com Wed Jun 22 07:34:42 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0F2228006 for ; Wed, 22 Jun 2011 07:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8UIEyJLa7Ow for ; Wed, 22 Jun 2011 07:34:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32C6321F84FA for ; Wed, 22 Jun 2011 07:34:41 -0700 (PDT) Received: by vxi40 with SMTP id 40so874328vxi.31 for ; Wed, 22 Jun 2011 07:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BjlsKfO70cxY199GPc7912idRQk+LFyQ3KX9ycIl7gI=; b=rkx5pcboOwQdCsm9mcaCGn5CW398AOKmd6fCjhulZZpD3zfeBGEIGHWEaemzO41joc 7LVxTWFFYq0XkuugSrTKu5jWhJ1z6jwKMo9Gq8eriSwe/vRVuJmHUor446NiWuPuQeGg cDHNinVwx8ehYz/iBW/Co1QnG8iangJAMlZSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JkNEOLSAYcdsibkDk9683endl6X5/kXHmRrI/AEt6+3fEzr/Jo2oyjGT50d/Fuvk4U mXD1hUa13lWSJuCiZGoQfRY4lzT8hF0Vlb2wY1bSUmUsbqUDInNY8iO0xD5kJ9EVrPav PjYhb+yDT+ZxO8wcLWKTlBL1BhF+JGnjuQx8Q= MIME-Version: 1.0 Received: by 10.52.66.206 with SMTP id h14mr1097340vdt.40.1308753266421; Wed, 22 Jun 2011 07:34:26 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Wed, 22 Jun 2011 07:34:26 -0700 (PDT) In-Reply-To: <4D1AA2A55522044480C9B9CF97A9340901BD0F39@ftrdmel0.rd.francetelecom.fr> References: <4D1AA2A55522044480C9B9CF97A9340901BD0F39@ftrdmel0.rd.francetelecom.fr> Date: Wed, 22 Jun 2011 10:34:26 -0400 Message-ID: From: Stephen Botzko To: stephane.proust@orange-ftgroup.com Content-Type: multipart/alternative; boundary=20cf307cfd828b2ec204a64ddd9e Cc: clue@ietf.org Subject: Re: [clue] clarification on requirements draft 03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:34:42 -0000 --20cf307cfd828b2ec204a64ddd9e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The requirement is not intended to preclude a higher number of channels, it is intended to say that the solution has to at least include those three modes. The rationale is that those are the modes in use today by telepresence systems. Regards, Stephen Botzko On Wed, Jun 22, 2011 at 9:13 AM, wrote= : > Hi > > I 've maybe missed some discussions related to some of the modifications > brought in draft 03 with respect to draft 02 but I would appreciate some > clarification/explanation about the limitation to 3 audio channels > introduced in REQMT-2b : > > REQMT-2b: The solution MUST support a means to identify > monaural, stereophonic (2.0), and 3.0 (left, > center, right) audio channels. > > Is it the intent to exclude the multiplexing of a higher number of channe= ls > ? > If the intent is to introduce some limitation, what is the rationale behi= nd > and why such limit is set to 3.0 ? > > Thanks > > St=E9phane > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307cfd828b2ec204a64ddd9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The requirement is not intended to preclude a higher number of channels, it= is intended to say that the solution has to at least include those three m= odes.=A0

The rationale is that those are the modes in use today by = telepresence systems.

Regards,
Stephen Botzko

On Wed, Ju= n 22, 2011 at 9:13 AM, <stephane.proust@orange-ftgroup.com> = wrote:
Hi

I 've maybe missed some discussions related to some of the modification= s brought in draft 03 with respect to draft 02 but I would appreciate some = clarification/explanation about the limitation to 3 audio channels introduc= ed in REQMT-2b :

REQMT-2b: =A0The solution MUST support a means to identify
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 monaural, stereophonic (2.= 0), and 3.0 (left,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 center, right) audio chann= els.

Is it the intent to exclude the multiplexing of a higher number of channels= ?
If the intent is to introduce some limitation, what is the rationale behind= and why such limit is set to 3.0 =A0?

Thanks

St=E9phane

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

--20cf307cfd828b2ec204a64ddd9e-- From stephen.botzko@gmail.com Wed Jun 22 07:44:24 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C3811E807A for ; Wed, 22 Jun 2011 07:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTFbvDlV8wSc for ; Wed, 22 Jun 2011 07:44:23 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9B0621F84E0 for ; Wed, 22 Jun 2011 07:44:22 -0700 (PDT) Received: by vxi40 with SMTP id 40so884022vxi.31 for ; Wed, 22 Jun 2011 07:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Zp42h+4vKirjyZbaW02STvTQGbbJuTY7KoMBQJMX3GU=; b=n9/y7caQ+qCH9ehp8jUvbD07J/VSYyrEBhIwiWRacP7TIL0VbKgpXLvgrcxma5pKzE 1fElFerHR6AmJ8VaXnEPXTENB4LD/cEbayoG4+3MjfKx2V056QxefO+NCf08IDiEshIG cp3P1ANob+/KQegifz+Fe2BJW8lgQsNoKThVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kBPIIIXyfr3M4qKhQkBaD/PQHImh0Vpsg0tHHULGc744KPP3LUn29TmWgYPZjMrT73 z/fTCyrJtlRXBrSwK6emrpODioFMpaXf8S5hcml30YYNXk4g4KanGZYwJA2Pt5RBYo2i bf578RrCQ7ES6MnghhIuqTCI6iA396OlkkoYY= MIME-Version: 1.0 Received: by 10.52.176.10 with SMTP id ce10mr1038124vdc.280.1308753862179; Wed, 22 Jun 2011 07:44:22 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Wed, 22 Jun 2011 07:44:22 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 22 Jun 2011 10:44:22 -0400 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec51a81840dbb8404a64e0175 Cc: "clue@ietf.org" Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:44:24 -0000 --bcaec51a81840dbb8404a64e0175 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 22, 2011 at 6:09 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi Charles, > > >I think I was the one that brought up layouts originally. I > >was more concerned with video layouts than audio layouts. > >Currently, the requirements draft seems to focus more on > >audio layout/spatial audio. > >Requirements 3 and 16 both deal with parts of this. I feel > >there needs to be more clear requirements on the ability for > >the to represent the potential layouts of the audio/video can > >that be offered. For example, I have 3 camera and 3 mics. I > >can provide: > >1) 3 individual video each with corresponding audio > >2) 1 active speaker only switched video with mixed audio > >3) 1 composed video including active speaker and 'n' > >non-active speakers (where 'n' is may be all or some fixed > >limit) and mixed audio > > I actually think that your examples, as written, are different RENDERING > TYPES, because they only talk about mixing and composition. > Confirmation that I am clueless about rendering types. > > In my opinion, a LAYOUT TYPE is a description of how sources are placed in > a virtual room. > For me layout is about composition. Layouts do not necessarily create a virtual room experience, particularly in multipoint calls. > > Of course, in order to do the mixing, a layout description is often needed > as an "input" for the rendering algorithm. > > Regards, > > Christer > > > > >If the receiving endpoint wants to control the layout itself, > >it goes with option 1. If it has limited > >resources/bandwidth/screens/etc it may prefer option 2 or 3. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Christer Holmberg > > > Sent: Tuesday, June 21, 2011 3:52 AM > > > To: clue@ietf.org > > > Subject: [clue] Layout negotiation > > > > > > Hi, > > > > > > A while ago there were some discussions about having requirements to > > negotiate the layout type, and at > > > least according to Stephen B it was within the scope of the work. > > > > > > "The ability to negotiate an audio or video layout > > is clearly > > within scope, and has general > > > value it the group wants to take it on. > > > For instance, if you combine video switching of multiple > > sources with audio > > > mixing/transcoding, then the receiver is responsible > > > for the video layout but has no control over the > > audio layout. > > In that case, there are > > > advantages to allowing the receiver to tell the > > > central audio mixer where it wants the sources placed on the > > sound stage. I have no objection > > > in principle to adding that kind of > > > negotiation to the requirements, though I think the group > > should consider the impact on the > > > schedule." > > > > > > However, I haven't seen any input after that. > > > > > > My idea would be that it is very similar to the rendering type: CLUE > > defines a mechanism to negotiate > > > the layout type, but doesn't define specific types (instead an IANA > > registry would be created for > > > that). So, I don't think it would have any significant impact on our > > schedule. > > > > > > Whether it, in addition to negotiation a layout type (which > > specifies > > the source locations), should be > > > possible for the user to more explicit place individual sources, as > > mentioned by Stephen, can be > > > discussed. However, that would probably require a little > > more work, so > > at least I would be happy with > > > a simple layout type negotiation at this point. > > > > > > So, would people be ok with such requirement? > > > > > > (Another alternative would be to "embed" the layout type into the > > rendering type, but I think that > > > would be very clumsy. Because, in that case you would need to define > > mulitple types for the same > > > rendering, but with different layouts.) > > > > > > Regards, > > > > > > Christer > > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec51a81840dbb8404a64e0175 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 22, 2011 at 6:09 AM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Charles,

>I think I was the one that brought up layouts originally. I
>was more concerned with video layouts than audio layouts.
>Currently, the requirements draft seems to focus more on
>audio layout/spatial audio.
>Requirements 3 and 16 both deal with parts of this. I feel
>there needs to be more clear requirements on the ability for
>the to represent the potential layouts of the audio/video can
>that be offered. For example, I have 3 camera and 3 mics. I
>can provide:
>1) 3 individual video each with corresponding audio
>2) 1 active speaker only switched video with mixed audio
>3) 1 composed video including active speaker and 'n'
>non-active speakers (where 'n' is may be all or some fixed
>limit) and mixed audio

I actually think that your examples, as written, are different RENDER= ING TYPES, because they only talk about mixing and composition.
Confirmation that I am clueless about rendering types.

In my opinion, a LAYOUT TYPE is a description of how sources are placed in = a virtual room.
For me layout is about composition.=A0= Layouts do not necessarily create a virtual room experience, particularly = in multipoint calls.

Of course, in order to do the mixing, a layout description is often needed = as an "input" for the rendering algorithm.

Regards,

Christer



>If the receiving endpoint wants to control the layout itself,
>it goes with option 1. If it has limited
>resources/bandwidth/screens/etc it may prefer option 2 or 3.
>
> Cheers,
> Charles
>
> > -----Original Message-----
> > From: clue-bounces@ietf.= org [mailto:clue-bounces@ietf.= org] On Behalf
> Of Christer Holmberg
> > Sent: Tuesday, June 21, 2011 3:52 AM
> > To: clue@ietf.org
> > Subject: [clue] Layout negotiation
> >
> > Hi,
> >
> > A while ago there were some discussions about having requirements= to
> negotiate the layout type, and at
> > least according to Stephen B it was within the scope of the work.=
> >
> > =A0 =A0 =A0 =A0 "The ability to negotiate an audio or video = layout
> is clearly
> within scope, and has general
> > value it the group wants to take it on.
> > =A0 =A0 =A0 =A0 For instance, if you combine video switching of m= ultiple
> sources with audio
> > mixing/transcoding, then the receiver is responsible
> > =A0 =A0 =A0 =A0 for the video layout but has no control over the<= br> > audio layout.
> In that case, there are
> > advantages to allowing the receiver to tell the
> > =A0 =A0 =A0 =A0 central audio mixer where it wants the sources pl= aced on the
> sound stage. =A0I have no objection
> > in principle to adding that kind of
> > =A0 =A0 =A0 =A0 negotiation to the requirements, though I think t= he group
> should consider the impact on the
> > schedule."
> >
> > However, I haven't seen any input after that.
> >
> > My idea would be that it is very similar to the rendering type: C= LUE
> defines a mechanism to negotiate
> > the layout type, but doesn't define specific types (instead a= n IANA
> registry would be created for
> > that). So, I don't think it would have any significant impact= on our
> schedule.
> >
> > Whether it, in addition to negotiation a layout type (which
> specifies
> the source locations), should be
> > possible for the user to more explicit place individual sources, = as
> mentioned by Stephen, can be
> > discussed. However, that would probably require a little
> more work, so
> at least I would be happy with
> > a simple layout type negotiation at this point.
> >
> > So, would people be ok with such requirement?
> >
> > (Another alternative would be to "embed" the layout typ= e into the
> rendering type, but I think that
> > would be very clumsy. Because, in that case you would need to def= ine
> mulitple types for the same
> > rendering, but with different layouts.)
> >
> > Regards,
> >
> > Christer
> >
> >
>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--bcaec51a81840dbb8404a64e0175-- From pkyzivat@cisco.com Wed Jun 22 07:51:52 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6452522800D for ; Wed, 22 Jun 2011 07:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.254 X-Spam-Level: X-Spam-Status: No, score=-109.254 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11y0uhjJNlRG for ; Wed, 22 Jun 2011 07:51:50 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E45ED228005 for ; Wed, 22 Jun 2011 07:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=23262; q=dns/txt; s=iport; t=1308754310; x=1309963910; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=jbHWtDO3K1HcyuRFU0mXKITTIyvSgWm2s0TAeNBVIVo=; b=GjGG5qG881i2DhzTKlkDeRQdUZ2oEoZ2jtTY2AGh1TcyGQRy+Vd042kM h3BkmWfokgrWJX2Am5KWB4nBU+IUXNlw9f2I8vsLA9gpwh5kDimPjP8oS Jqh7Zst/bmgxgaAfmBAcqtyvhEGy9dgszHUWY/QDIOIJWSjsl4rtHKzL0 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AADQBAk6tJV2a/2dsb2JhbABGDpd2jxp3iHOhGp5Hgx+DDgSRaoRli0M X-IronPort-AV: E=Sophos;i="4.65,406,1304294400"; d="scan'208";a="719578199" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 22 Jun 2011 14:51:49 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5MEpmsd016662 for ; Wed, 22 Jun 2011 14:51:49 GMT Message-ID: <4E020184.1040806@cisco.com> Date: Wed, 22 Jun 2011 10:51:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A548@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB559A548@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:51:52 -0000 On 6/22/2011 8:14 AM, Christer Holmberg wrote: > > Hi, > >>>> I understand you are advocating a general mechanism, which is why I especially want to see use cases showing >>>> the need for the panned, plain, thresholded, linear, non-linear rendering types you >>>> proposed. If someone has other rendering types, then they would be helpful too. >>> >>>> For me the negotiation of "rendering type" is a mechanism. I am thinking all we need is number of channels, but I am quite willing to change my view if the use cases show more is needed. >>> >>> What do you mean by "number of channels"? >>> >>> In the SDP a=rtpmap attribute you are able to indicate the number of audio channels, >>> but I don't think that helps. >> >> Setting aside binaural for now, I am envisioning that I am receiving three audio channels, and that >> CLUE mechanisms are telling me "left, center, right" for each channel. I think that's all I need to >> know in order to render the audio properly, but I am thinking you don't agree. > > It depends on WHO is rendering. > > An entity receiving all "raw material" can of course do whatever it wants with it. But, in the centralized rendering case the idea is that the rendering is done on behalf of a client, since the client due to different reasons can't do it itself. There is a distinction here between describing "what you have" or "what you want". AFAIK the intent right now is that what is described is "what I have", and "what I can provide". E.g. - I have some microphones, speakers, cameras, displays in a particular arrangement - I can provide some selection of media streams having content, either renditions of particular cameras, microphones, etc. or specific combinations of those. It seems to me that binaural can fit into this model. The room configuration suitable to receive binaural involves "speakers" (headphones) arranged in a particular way. I guess that then there would need be a way to specify that a media stream that a room can provide is encoded as a binaural "mix" of a particular set of microphones on the source side. It isn't in principle necessary to "ask" for binaural. Rather what is being done is "offer" binaural. But the actual mechanism for doing that seems independent of CLUE. Thanks, Paul >> That I would also need to know "panning" vs "plain"??? I don't understand what you are thinking I would do differently if I knew that, which is why I am wanting more use cases. > > Maybe there is no need to separate "panning" vs "plain". I will need to look into that (there for sure is a need to separate binaural from other stereo, though). > > Other use-cases is which video and/or audio streams are sent towards a client in the first place. E.g. Sending the video of the most active speaker, sending the audio of the 4 most active speakers, etc. I consider that being different rendering types also, because they affect how the output stream is generated. > > Regards, > > Christer > > > > > > > > Hi, > > > >I would like to see use cases, particularly for non-binaural proposals. It seems to me that a receiver doesn't really>care if the stereo it is receiving is "panned", "plain" or "thresholded", or if it is linear or non-linear. So use cases>motivating those choices would be helpful. > > > >Also, the proposal is for a specific mechanism ("rendering type"). It may be premature to identify the mechanism>in the requirements - since often there are multiple ways to achieve the desired ends. > > > > > Again, I am not suggesting to specify a specific mechanism - only a mechanism to negotiate the rendering type mechanism. > > > > Yes, I am using binaural as a rendering type EXAMPLE, but you are the one who keep saying that I am trying to specify binaural :) > > > > Regards, > > > > Christer > > > > > On Mon, Jun 20, 2011 at 5:47 PM, Allyn Romanow (allyn)> wrote: > > > Hi Christer, > > I think that you are proposing that CLUE needs a mechanism to pass > information, such as a tag, on "rendering type", for example, binaural, > threshold, etc. > Is that correct? > > And that you are not asking for any more from CLUE than simply > identifying the rendering type. > Is that correct? > > IF both of these statements are correct, than personally I think it is > fine TO include the information of rendering type, such as "binaural", > by some mechanism, such as a tag, AS LONG AS there is an accepted Use > Case that shows the necessity of communicating the rendering type, such > as "thresholding" or "panning". > > How do other people feel about this? > > Thanks, > Allyn > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 20, 2011 12:23 PM > To: Allyn Romanow (allyn); Mary Barnes > > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on centralized media mixing > > Hi Allyn, > > >Still trying to get clarification- > > > >I read your description of various types of rendering. > >Still trying to understand what you want from CLUE- > >If we have a tag that says "binaural" or stereo, sub binaural, are we > >done? > > Of course we could have a binaural specific SDP attribute, e.g. > a=binaural. > > But, again, what we are proposing is a general mechanism, that could > look something like: > > a=rendering-type = > > could then e.g. be "binaural", but it could also be something > else (we showed a few example in the e-mail). > > >Or do you want CLUE to describe how to do some kind of rendering? To > say > >something more about specific rendering functions? > > No, CLUE doesn't need to say anything about that. > > There would of course need to be a rendering description associated with > each rendering type value, but CLUE wouldn't define those. > > The idea is that an IANA registry is created, where people can register > their rendering type values. > > Regards, > > Christer > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Sunday, June 19, 2011 10:29 PM > > To: Allyn Romanow (allyn); Mary Barnes > > > Cc: clue@ietf.org; Botzko, Stephen; Bill Mauchly (bmauchly) > > Subject: RE: [clue] Requirement on centralized media mixing > > > > > > Hi Allyn, > > > > I appologise that it took some time to reply. > > > > We've been working on some definition/example text (I sent it to the > > list just a few minutes ago), which I hope will clarify some of the > > questions that have been asked. > > > > >Also, what kind of support are you asking for binaural? I believe > it's > > often considered as a subset of stereo. What are you asking for? A > > simple tag that says "binaural", or the specification > > >of a rendering system for binaural? Precisely what are asking for? > > > > From CLUE, we are only asking for a general mechanism to request and > > indicate different rendering types (see definition in other e-mail). > > > > An example of such rendering type is binaural, BUT we are *NOT* asking > > CLUE to define any binaural specific SDP attributes etc. If such are > > needed, we agree that it needs to be done as a separate task. > > > > Before I try to answer your other questions, please take a look at the > > definition/example e-mail, which I hope will clarify what we mean by > > rendering and rendering type. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Christer - > > > > In spirit I am enthusiastic about what you are proposing > (meaning > > good quality mobile participation). I'm not clear on how the spirit > > becomes instantiated in our protocol, so I have some questions below J > > > > Thanks, > > > > Allyn > > > > > > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > Behalf Of Christer Holmberg > > Sent: Tuesday, June 14, 2011 7:23 AM > > > To: clue@ietf.org > > > Subject: [clue] Requirement on centralized media mixing > > > > > > > > > > > > Hi, > > > > > > > > During the last interim meeting (May 12th) we discussed a > > requirement proposal > > > > stating that an endpoint must be able to request central audio > > rendering > > > > of different predefined formats, including 3D binaural > rendering. > > > > (Link to proposal: http://www.ietf.org/mail- > > archive/web/clue/current/msg00179.html) > > > > > > > > The proposal was well received, with the reservation that it > > should not be mandatory > > > > for the solution to implement centralized 3D binaural rendering, > > > i.e.an endpoint should > > > > > be able to request 3D binaural rendering, but had no guaranty > > that such rendering was > > > > supported by the system. > > > > > > > > It was decided to look how such requirement could look like. > > > > > > > > When I look the -03 version of the req draft, Requirement 2c > > states: > > > > > > > > "The solution MUST NOT preclude the use of binaural audio." > > > > > > > > I think that requirement is unclear, and it doesn't really give > > any guidance to our work. > > > > > > > > Due to that, and also due to the fact that rather than talking > > about specific rendering types, > > > > I would like to propose more general requirement text on the > > negotiation of the media mixing type, > > > > and the usage of centralized media mixing in the first place. > > > > > > > > The mechanism would be extendable, so new types can be added in > > future. > > > > > > > > So, the proposed requirements are: > > > > > > > > REQ-x: It MUST be possible to negotiate the usage of > > centralized media mixing. System support of centralized media mixing > is > > optional. > > > > > > > > REQ-y: When centralized media mixing is used, it MUST be > > possible to negotiate the type of media rendering provided for each > > media stream received by a client. > > > > --- > > > > [ar] I have a few questions/comments: > > > > 1. The term "negotiate" troubles me as I think it means > a > > particular form of communication that dictates the solution. What is > > being asked for is the receiver to know that it is receiving > > "centralized media mixing". This may not be the end product of a > > negotiation. The same is true of the use of the term negotiate in the > > second requirement. What is needed is a mechanism by which the > receiver > > may know what type of "media rendering" is being received. > > > > So, I'd rather offer, The solution must support a means for > > identifying a stream which is "centralized media mixing". > > > > And, When "centralized media mixing" is used, the solution must > > support a means for identifying... > > > > > > > > 2. Also, I'm not too sure what "media rendering", the > > phrase in the second reqmt, represents- SDP and RTP recognize audio > > channels and recognize codecs. Is this what is referred to as "media > > rendering"? Or is it something different? What very specifically? > > > > > > > > 3. After reading more of the discussion, I realize that I > > don't fully understand what is meant in the first reqmt by > "centralized > > media mixing" or "rendering", which term is used in another email. I > > had thought you meant the usual audio mixing such as discussed in RFC > > 5117.( I figured it was an understood part of the topology so didn't > > need to be called out in particular. But I don't mind calling it > out.) > > In any case, now I'm not sure what you mean, maybe it is something > > other than typical MCU mixing behavior as described in RFC 5117? > > > > > > > > 4. As for the discussion of binaural.. here is what it > > seems like to me.. AVP, RFC 3551 specifies the number of audio > > channels, what they refer to, and types of codecs. Binaural is > > neither. As you say, Christer, it's a type of stereo channel. Steve > > feels that "binaural" must be recognized in SDP, which of course, it > is > > not currently. > > > > > > > > I'm not entirely sure what needs to be specified about binaural, > > given that it is neither channel -type nor codec-type. What needs to > be > > standardized? This question is probably more for Steve, or both of > you. > > If the receiving device knows it's getting binaural stereo, then it > can > > run some algorithms to improve quality and if it isn't binaural, it > > won't run those algs., or something analogous? If that is the case, I > > don't see what needs to be standardized that isn't already > > standardized... But I'm eager to learn. > > > > > > > > Thanks- > > > > Allyn > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > _______________________________________________ > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Wed Jun 22 08:08:00 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0F811E80D7 for ; Wed, 22 Jun 2011 08:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.88 X-Spam-Level: X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ebsIEU52OWF for ; Wed, 22 Jun 2011 08:07:59 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6D811E80BD for ; Wed, 22 Jun 2011 08:07:58 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-9d-4e02054d8b52 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3E.22.09774.D45020E4; Wed, 22 Jun 2011 17:07:57 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 22 Jun 2011 17:07:56 +0200 From: Christer Holmberg To: Roni Even , 'Stephen Botzko' Date: Wed, 22 Jun 2011 17:07:54 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acww0Bm8VDTJV27YTXeT+ssx3eOWAQABm+GwAAXgVUA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A733@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> <00f801cc30d8$2a888140$7f9983c0$%roni@huawei.com> In-Reply-To: <00f801cc30d8$2a888140$7f9983c0$%roni@huawei.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 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:08:00 -0000 Hi Roni, >In XCON data model http://tools.ietf.org/html/draft-ietf-xcon-common-data-= model-31#section-4.2.13 there is a specification of video layout control th= at >describes the continuous presence layout. There was no requirement for som= ething similar for audio. I assume that Christer wants to see something sim= ilar >to that definition for audio but I am not sure if there is a use case for = that, currently SDP RTPMAP has the encoding parameters that allows the >specification of the number of audio channels which as far as I understand= is sufficient for telepresence systems.< mal> > >If there is a general need to negotiate not only the number of channels bu= t also a non codec specific way to negotiate audio mixing parameter, I am n= ot >sure this is a CLUE topic. In which case its support will be part of inter= operability requirement with SIP systems that do not support telepresence >extensions. We do have a requirement to interoperate with "single stream devices" (that= might still be CLUE aware), and then there is a need to specify source sel= ection, both for audio and video. In the most simple case, the generated stream towards the device is done si= mply by switching, but in more advanced cases there will be need for mixing= , where source selection migth be needed for the mixing algorithm. Regards, Christer From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behal= f Of Stephen Botzko Sent: Wednesday, June 22, 2011 2:29 PM To: Christer Holmberg Cc: clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing On Wed, Jun 22, 2011 at 1:24 AM, Christer Holmberg wrote: Hi Stephen lass=3DMsoNormal style=3D'margin-bottom:12.0pt'> >I understand you are advocating a general mechanism, which is why = I especially want to see use cases showing the need for the panned, plain, = thresholded, linear, non-linear rendering types you >proposed. If someone has other rendering types, then they would b= e helpful too. > >For me the negotiation of "rendering type" is a mechanism. I am t= hinking all we need is number of channels, but I am quite willing to change= my view if the use cases show more is needed. What do you mean by "number of channels"? In the SDP a=3Drtpmap attribute you are able to indicate the number= of audio channels, but I don't think that helps. Setting aside binaural for now, I am envisioning that I am receivin= g three audio channels, and that CLUE mechanisms are telling me &q uot; for= each channel. I think that's all I need to know in order to render the au= dio properly, but I am thinking you don't agree. That I would also need to= know "panning" vs "plain"??? I don't understand what you are thinking I w= ould do differently if I knew that, which is why I am wanting more use case= s. Regards, Christer On Tue, Jun 21, 2011 at 2:11 PM, Christer Holmberg <= christer.holmberg@ericsson.com> wrote: Hi, >I would like to ly for non-binaural proposa= ls. It seems to me that a receiver doesn't really >care if the stereo it i= s receiving is "panned", "plain" or "thresholded", or if it is linear or no= n-linear. So use cases >motivating those choices would be helpful. > >Also, the proposal is for a specific mechan= ism ("rendering type"). It may be premature to identify the mechanism >in = the requirements - since often there are multiple ways to achieve the desir= ed ends. Again, I am not suggesting to specify a spec= ific mechanism - only a mechanism to negotiate the rendering type mechanism= . Yes, I am using binaural as a rendering type= EXAMPLE, but you are the one who keep saying that I am try ) Regards, Christer On Mon, Jun 20, 2011 at 5:47 PM, Allyn Roman= ow (allyn) > wrote: Hi Christer, I think that you are proposing that CLUE nee= ds a mechanism to pass information, such as a tag, on "rendering ty= pe", for example, binaural, threshold, etc. Is that correct? And that you ar from CLUE than simply identifying the rendering type. Is that correct? IF both of these statements are correct, tha= n personally I think it is fine TO include the information of rendering= type, such as "binaural", by some mechanism, such as a tag, AS LONG AS= there is an accepted Use Case that shows the necessity of communicati= ng the rendering type, such as "thresholding" or "panning". How do other people feel about this? Thanks, -----Original Message----- From: Christer Holmberg [mailto:christer.hol= mberg@ericsson.com] Sent: Monday, June 20, 2011 12:23 PM To: Allyn Romanow (allyn); Mary Barnes Cc: clue@ietf.org; Bot= zko, Stephen; Bill Mauchly (bmauchly) Subject: RE: [clue] Requirement on centraliz= ed media mixing Hi A ; >Still trying to get clari= fication- > >I read your description of various types of= rendering. >Still trying to understand what you want fr= om CLUE- >If we have a tag that says "binaural" or st= ereo, sub binaural, are we >done? Of course we could have a binaural specific = SDP attribute, e.g. a=3Dbinaural. But, again, what we are proposing is a gener= al mechanism, that could look something like: could then e.g. be "binaural", but i= t could also be something else (we showed a few example in the e-mail)= . >Or do you want CLUE to describe how to do s= ome kind of rendering? To say >something more about specific rendering fun= ctions? No, CLUE doesn't need to say anything about = that. There would of course need to be a rendering= description associated with each rendering type value, but CLUE wouldn't= define those. & ; The idea is that an IANA registry is created, wh= ere people can register their rendering type values. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.h= olmberg@ericsson.com] > Sent: Sunday, June 19, 2011 10:29 PM > To: Allyn Romanow (allyn); Mary Barnes > Cc: clue@ietf.org>; Botzko, Stephen; Bill = Mauchly (bmauchly) > Subject: RE: [clue] Requirement on central= ized media mixing > > > Hi Allyn, > > I appologise that it took some time to rep= ly. > > We've been working on some definition/exam= ple text (I sent it to the > list just a few minutes ago), which I hope= will clarify some of the > asked. > > >Also, what kind of support are you asking= for binaural? I believe it's > often considered as a subset of stereo. Wh= at are you asking for? A > simple tag that says "binaural", or the s= pecification > >of a rendering system for binaural? Preci= sely what are asking for? > > From CLUE, we are only asking for a genera= l mechanism to request and > indicate different rendering types (see de= finition in other e-mail). &nbs nbsp; > > An example of such rendering type is binau= ral, BUT we are *NOT* asking > CLUE to define any binaural specific SDP a= ttributes etc. If such are > needed, we agree that it needs to be done = as a separate task. > > Before I try to answer your other question= s, please take a look at the > definition/example e-mail, which I hope wi= ll clarify what we mean by > rendering and rendering type. > > Regards, &n > > Christer > > > > > > > > > > > > > > & ; > Hi Christer - > > In spirit I am enthusiastic about wh= at you are proposing (meaning > good quality mobile participation). I'm no= t clear on how the spirit > becomes instantiated in our protocol, so I= have some questions below J > > Thanks, > > Allyn > bsp; > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Tuesday, June 14, 2011 7:23 AM > To: clue@ietf.org > Subject: [clue] Requirement on centr= al p; > > > > > > Hi, > > > > During the last interim meeting (May= 12th) we discussed a > requirement proposal > > stating that an endpoint must be abl= e to > > rendering > > of different predefined formats, inc= luding 3D binaural rendering. > > (Link to proposal: http://www.ietf.o= rg/mail- > archive/web/clue/current/msg00179.html) > > > > The proposal was well received, it > should not be mandatory > > for the solution to implement centra= lized 3D binaural rendering, > i.e.an endpoint should > > be able to request 3D binaural rende= ring, but had no guaranty > that such rendering was > > supported by the system. p; > > > > It was decided to look how such requ= irement could look like. > > > > When I look the -03 version of the r= eq draft, Requirement 2c > states: > > > > "The solution MU f binaural audi= o." > > > > I think that requirement is unclear,= and it doesn't really give > any guidance to our work. > > > > Due to that, and also due to the fac= t that rather than talking > about specific rendering types, > &n bsp; I would like to propose more general = requirement text on the > negotiation of the media mixing type, > > and the usage of centralized media m= ixing in the first place. > > > > The mechanism would be extendable, s= o new types can be added in > future. > > > & ; > So, the proposed requirements are: > > > > REQ-x: It MUST be possible to neg= otiate the usage of > centralized media mixing. System support o= f centralized media mixing is > optional. > > > > REQ-y: When centralized media mix= ing i sp; > possible to negotiate the type of media rendering = provided for each > media stream received by a client. > > --- > > [ar] I have a few questions/comments= : > > 1. The term "negotiate" trou= bles me as I think it means a > particular form of communication that dict= ates the solution. What is< nbsp; > being asked for is the receiver = to know that it is receiving > "centralized media mixing". This may not b= e the end product of a > negotiation. The same is true of the use o= f the term negotiate in the > second requirement. What is needed is a me= chanism by which the receiver > may know what type of "media rendering" is= being received. > > So, I'd rather offer, The solut= ion must support a means for > identifying a ntralized media mixing". > > And, When "centralized media mixing"= is used, the solution must > support a means for identifying... > > > > 2. Also, I'm not too sure wha= t "media rendering", the > phrase in the second reqmt, represents- SD= P and RTP recognize audio > channels and recognize codecs. Is this wha= t is referred to as "media & ; > rendering"? Or is it something different? What= very specifically? > > > > 3. After reading more of the d= iscussion, I realize that I > don't fully understand what is meant in th= e first reqmt by "centralized > media mixing" or "rendering", which term i= s used in another email. I > had thought you meant the usual audio mixi= ng such as discussed in RFC > 5117.( stood part of the topology so didn'= t > need to be called out in particular. But = I don't mind calling it out.) > In any case, now I'm not sure what you mea= n, maybe it is something > other than typical MCU mixing behavior as = described in RFC 5117? > > > > 4. As for the discussion of bi= naural.. here is what it > seems like to me.. AVP, RFC 3551 specifies= the number of audio & ; > channels, what they refer to, and types of co= decs. Binaural is > neither. As you say, Christer, it's a type= of stereo channel. Steve > feels that "binaural" must be recognized i= n SDP, which of course, it is > not currently. > > > > I'm not entirely sure what needs to = be specified about binaural, > given that it is neither channel -type nor= codec-type. What needs to &nbs nbsp; be > standardized? This question is probably mo= re for Steve, or both of you. > If the receiving device knows it's getting= binaural stereo, then it can > run some algorithms to improve quality and= if it isn't binaural, it > won't run those algs., or something analog= ous? If that is the case, I > don't see what needs to be standardized th= at isn't already > standardized... But I'm eager to learn. > p; > > Thanks- > > Allyn > > > > Regards, > > > > Christer > > &nbs nbsp; > > ____________________________________________= ___ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Wed Jun 22 08:08:51 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C633211E80C4 for ; Wed, 22 Jun 2011 08:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmahbuiA0SWe for ; Wed, 22 Jun 2011 08:08:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48F9111E80A9 for ; Wed, 22 Jun 2011 08:08:48 -0700 (PDT) Received: by vxi40 with SMTP id 40so908679vxi.31 for ; Wed, 22 Jun 2011 08:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7xWS4PjYsZuImiqb0Al91uYpsPEynPlov8s9AGsx52M=; b=dxUA9i4CMfcONcvBIwpedzxv+Xbv1kg2mWS2VghcvJitqR3Yd2eb8k6T0JDsb7Q8pl ZxTizcNSmWIMknFxaynVKpvY7hhteZPEn/EaR7X9HX7JswH4GCybNo5qypu+lXWzt8yG T5gRKdAYTh++M1nJ8PtLkZ8WeH/lSiJA6xKZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=T7E1dL0pxG1mkWINwrRSF4FD7/0qTS1hljHf2P8H6LKU4EdtLjb1xHZK8SR+4+nqO2 E7s/Fscm56XhhHT1FY99MEZj84BMF8U/ECS+wUHKPo4Q2XsaK4ll+V1jFCbZV8B8pp2U KzdtrKMicXVMoMq8XPPQcgn9H2r+1QlqVQQAo= MIME-Version: 1.0 Received: by 10.52.76.131 with SMTP id k3mr1171473vdw.80.1308755327716; Wed, 22 Jun 2011 08:08:47 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Wed, 22 Jun 2011 08:08:47 -0700 (PDT) In-Reply-To: <00fd01cc30dc$2496e930$6dc4bb90$%roni@huawei.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6357@xmb-sjc-221.amer.cisco.com> <00fd01cc30dc$2496e930$6dc4bb90$%roni@huawei.com> Date: Wed, 22 Jun 2011 11:08:47 -0400 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/alternative; boundary=bcaec50160e3680db604a64e5860 Cc: clue@ietf.org Subject: Re: [clue] use case for multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:08:51 -0000 --bcaec50160e3680db604a64e5860 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The way I understand "view point" is that a PTZ camera has a constant view point no matter where it is aimed at the moment. That view point is determined by where the camera *is*. So if there are three cameras in a telepresence system, all co-located above the center screen (the typical case), then those cameras all have the same viewpoint. If one camera is located above each screen, then each camera has a distinct viewpoint. "Field of view" describes what the camera is aimed at (e.g., what it "sees"). Mark Gorzynski's use case is specific to the situation where multiple cameras have a distinct viewpoints, but are aimed at the same human participants [have the same field of view]. The basic idea being illustrated is that each site can choose the camera with the viewpoint that most closely matches a desired sight line in a virtual space that includes all human participants [in order to get the best eye contact]. I am not seeing this in the educational use case, or in any of the others. Since this case is somewhat narrow [and in particular is limited to camera placements that are not that common today], there might be some debate as t= o how important it is. So it might be better to isolate it into its own use case, to facilitate that discussion. Steve B. On Wed, Jun 22, 2011 at 8:58 AM, Roni Even wrote: > Hi Allyn,**** > > I sis not add it, I sent the following question to the list on May 17th a= nd > did not get any response yet**** > > ** ** > > "Hi Mark,**** > > I am trying to see how to fit this case in the use-cases draft. When I > ignore the term "virtual space" and look at the description it talks abou= t > describing the view point of each cameras that may overlap and allowing t= he > receivers to select the view they want. I see some resemblance to the > education usage described. **** > > Will it make sense t o mentio vide different view in the point to point > symmetric or asymmetric case which has a case with a PTZ camera."**** > > ** ** > > ** ** > > Roni Even**** > > ** ** > > ** ** > > *From:* Allyn Romanow (allyn) [mailto:allyn@cisco.com] > *Sent:* Wednesday, June 22, 2011 6:51 AM > *To:* Roni Even > *Cc:* clue@ie tf.org** > > ** ** > > Hi Roni,**** > > I thought Mark=92s use case for multi-view was added to the Use Case doc,= but > I couldn=92t find it there? Is it just not added yet or is there some iss= ue > with it?**** > > ** ** > > Thanks much**** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --bcaec50160e3680db604a64e5860 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The way I understand "view point" is that a PTZ camera has a cons= tant view point no matter where it is aimed at the moment.=A0 That view poi= nt is determined by where the camera is.=A0 So if there are three ca= meras in a telepresence system, all co-located above the center screen (the= typical case), then those cameras all have the same viewpoint.=A0 If one c= amera is located above each screen, then each camera has a distinct viewpoi= nt.

"Field of view" describes what the camera is aimed at (e.g., = what it "sees").

Mark Gorzynski's use case is specific= to the situation where multiple cameras have a distinct viewpoints, but ar= e aimed at the same human participants [have the same field of view].=A0 Th= e basic idea being illustrated is that each site can choose the camera with= the viewpoint that most closely matches a desired sight line in a virtual = space that includes all human participants [in order to get the best eye co= ntact].=A0 I am not seeing this in the educational use case, or in any of t= he others.

Since this case is somewhat narrow [and in particular is limited to cam= era placements that are not that common today], there might be some debate = as to how important it is.=A0 So it might be better to isolate it into its = own use case, to facilitate that discussion.

Steve B.

=A0


--bcaec50160e3680db604a64e5860-- From christer.holmberg@ericsson.com Wed Jun 22 08:17:55 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64A711E80A3 for ; Wed, 22 Jun 2011 08:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLoWeowbQ8Ym for ; Wed, 22 Jun 2011 08:17:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB3911E808E for ; Wed, 22 Jun 2011 08:17:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-57-4e020778e475 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9E.A3.09774.877020E4; Wed, 22 Jun 2011 17:17:13 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 22 Jun 2011 17:17:12 +0200 From: Christer Holmberg To: Stephen Botzko Date: Wed, 22 Jun 2011 17:17:10 +0200 Thread-Topic: [clue] Layout negotiation Thread-Index: Acww6uD+TdzXSqNlTCu/bY/VZBH7CAABAFsw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:17:55 -0000 Hi,=20 =09 >>I think I was the one that brought up layouts originally. I >>was more concerned with video layouts than audio layouts. >>Currently, the requirements draft seems to focus more on >>audio layout/spatial audio. >>Requirements 3 and 16 both deal with parts of this. I feel >>there needs to be more clear requirements on the ability for >>the to represent the potential layouts of the audio/video can >>that be offered. For example, I have 3 camera and 3 mics. I >>can provide: >>1) 3 individual video each with corresponding audio >>2) 1 active speaker only switched video with mixed audio >>3) 1 composed video including active speaker and 'n' >>non-active speakers (where 'n' is may be all or some fixed >>limit) and mixed audio > =09 > =09 >I actually think that your examples, as written, are different RENDERING T= YPES, because they only talk about mixing and composition. > =09 >Confirmation that I am clueless about rendering types.=20 A value identifying the rendering algorithm used to produce a media stream = sent towards the client. =09 >>In my opinion, a LAYOUT TYPE is a description of how sources are placed i= n a virtual room. >> =09 >For me layout is about composition. Layouts do not necessarily create a vi= rtual room experience, particularly in multipoint calls.=20 Ok, so we need to make sure we have a common understanding of layout then := ) So, just to clarify, do you think that source selection is layout? =09 Regards, Christer =09 >If the receiving endpoint wants to control the layout itself, >it goes with option 1. If it has limited >resources/bandwidth/screens/etc it may prefer option 2 or 3. > > Cheers, > Charles > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Christer Holmberg > > Sent: Tuesday, June 21, 2011 3:52 AM > > To: clue@ietf.org > > Subject: [clue] Layout negotiation > > > > Hi, > > > > A while ago there were some discussions about having requirements to > negotiate the layout type, and at > > least according to Stephen B it was within the scope of the work. > > > > "The ability to negotiate an audio or video layout > is clearly > within scope, and has general > > value it the group wants to take it on. > > For instance, if you combine video switching of multiple > sources with audio > > mixing/transcoding, then the receiver is responsible > > for the video layout but has no control over the > audio layout. > In that case, there are > > advantages to allowing the receiver to tell the > > central audio mixer where it wants the sources placed on the > sound stage. I have no objection > > in principle to adding that kind of > > negotiation to the requirements, though I think the group > should consider the impact on the > > schedule." > > > > However, I haven't seen any input after that. > > > > My idea would be that it is very similar to the rendering type: CLUE > defines a mechanism to negotiate > > the layout type, but doesn't define specific types (instead an IANA > registry would be created for > > that). So, I don't think it would have any significant impact on our > schedule. > > > > Whether it, in addition to negotiation a layout type (which > specifies > the source locations), should be > > possible for the user to more explicit place individual sources, as > mentioned by Stephen, can be > > discussed. However, that would probably require a little > more work, so > at least I would be happy with > > a simple layout type negotiation at this point. > > > > So, would people be ok with such requirement? > > > > (Another alternative would be to "embed" the layout type into the > rendering type, but I think that > > would be very clumsy. Because, in that case you would need to define > mulitple types for the same > > rendering, but with different layouts.) > > > > Regards, > > > > Christer > > > > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =09 From stephen.botzko@gmail.com Wed Jun 22 08:40:53 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFD911E809F for ; Wed, 22 Jun 2011 08:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q7FLGLZQ-GI for ; Wed, 22 Jun 2011 08:40:52 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32C6211E80B2 for ; Wed, 22 Jun 2011 08:40:51 -0700 (PDT) Received: by vxi40 with SMTP id 40so939684vxi.31 for ; Wed, 22 Jun 2011 08:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IW2eYAviq+OL9pEzj7PofRuV8j6OnBXWrgg7Sv5QU3M=; b=mJjN43k4vTPr04Rh3++flS+B6Sr4U+IfR7ZSGVuNFnKHKtOo/p+6Clc9GezwXJS5jp P2c456TqldUulR3gBtPFElpCY++/HzCgnRs7D41nMQjv0Xbvs9kGr99S05kNp1jfNmvd VWKgPR8xlOKHbtIiAZr+yAc+qbpnFBEfcfBHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KOY1nF0rsOunQfdQaaGg+p8hD+PUHFGetAe8GSH9vyp4uJzVj1lRE87BAdD4gOQFaV VzWIjhp1CbX/W6HP6MC78FDBTt+F3i9agdxYhWd6cJh3KQqF3SAqpNuPmb5NFBhKBoq5 jv0NoBEEEv34r78pebuRonVssQGMTflhTNdXA= MIME-Version: 1.0 Received: by 10.52.160.68 with SMTP id xi4mr1123442vdb.106.1308757250549; Wed, 22 Jun 2011 08:40:50 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Wed, 22 Jun 2011 08:40:50 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 22 Jun 2011 11:40:50 -0400 Message-ID: From: Stephen Botzko To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec53f977904271804a64ecb88 Cc: "clue@ietf.org" Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:40:53 -0000 --bcaec53f977904271804a64ecb88 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 22, 2011 at 11:17 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > >>I think I was the one that brought up layouts originally. I > >>was more concerned with video layouts than audio layouts. > >>Currently, the requirements draft seems to focus more on > >>audio layout/spatial audio. > >>Requirements 3 and 16 both deal with parts of this. I feel > >>there needs to be more clear requirements on the ability for > >>the to represent the potential layouts of the audio/video can > >>that be offered. For example, I have 3 camera and 3 mics. I > >>can provide: > >>1) 3 individual video each with corresponding audio > >>2) 1 active speaker only switched video with mixed audio > >>3) 1 composed video including active speaker and 'n' > >>non-active speakers (where 'n' is may be all or some fixed > >>limit) and mixed audio > > > > > >I actually think that your examples, as written, are different RENDERING > TYPES, because they only talk about mixing and composition. > > > >Confirmation that I am clueless about rendering types. > > A value identifying the rendering algorithm used to produce a media stream > sent towards the client. > In a client-to-client call this is backwards. "Capture" describes the stream production process better, rendering is that the client does with the streams it receives. Anyway, changing "Rendering type" to "rendering algorithm" doesn't help me much. > > >>In my opinion, a LAYOUT TYPE is a description of how sources are placed > in a virtual room. > >> > >For me layout is about composition. Layouts do not necessarily create a > virtual room experience, particularly in multipoint calls. > > Ok, so we need to make sure we have a common understanding of layout then > :) > > So, just to clarify, do you think that source selection is layout? > I generally separate them, though they are related. For instance, in a traditional Video MCU you can often choose a source-independent layout (2x2 array of equal size windows, a 1+5 layout, where the "1" window is bigger than the others, and at the top left, etc). Then you can control the mapping of sources to windows separately. Not sure this is the only way to partition it, just the way I tend to use. I see four distinct elements in your mobile binaural case - (a) the sources chosen for placement, (b) the set of placements used in creating a sound stage, (c) the placement used for each particular source at the moment, and (d) whether the outbound audio is binaural or not. I'd personally call (b) the audio layout, though you can equally well call (b+c) the audio layout. > > Regards, > > Christer > > > > > > > > > > >If the receiving endpoint wants to control the layout > itself, > >it goes with option 1. If it has limited > >resources/bandwidth/screens/etc it may prefer option 2 or > 3. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto: > clue-bounces@ietf.org] On Behalf > > Of Christer Holmberg > > > Sent: Tuesday, June 21, 2011 3:52 AM > > > To: clue@ietf.org > > > Subject: [clue] Layout negotiation > > > > > > Hi, > > > > > > A while ago there were some discussions about having > requirements to > > negotiate the layout type, and at > > > least according to Stephen B it was within the scope of > the work. > > > > > > "The ability to negotiate an audio or video > layout > > is clearly > > within scope, and has general > > > value it the group wants to take it on. > > > For instance, if you combine video switching of > multiple > > sources with audio > > > mixing/transcoding, then the receiver is responsible > > > for the video layout but has no control over the > > audio layout. > > In that case, there are > > > advantages to allowing the receiver to tell the > > > central audio mixer where it wants the sources > placed on the > > sound stage. I have no objection > > > in principle to adding that kind of > > > negotiation to the requirements, though I think > the group > > should consider the impact on the > > > schedule." > > > > > > However, I haven't seen any input after that. > > > > > > My idea would be that it is very similar to the > rendering type: CLUE > > defines a mechanism to negotiate > > > the layout type, but doesn't define specific types > (instead an IANA > > registry would be created for > > > that). So, I don't think it would have any significant > impact on our > > schedule. > > > > > > Whether it, in addition to negotiation a layout type > (which > > specifies > > the source locations), should be > > > possible for the user to more explicit place individual > sources, as > > mentioned by Stephen, can be > > > discussed. However, that would probably require a little > > more work, so > > at least I would be happy with > > > a simple layout type negotiation at this point. > > > > > > So, would people be ok with such requirement? > > > > > > (Another alternative would be to "embed" the layout type > into the > > rendering type, but I think that > > > would be very clumsy. Because, in that case you would > need to define > > mulitple types for the same > > > rendering, but with different layouts.) > > > > > > Regards, > > > > > > Christer > > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > --bcaec53f977904271804a64ecb88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 22, 2011 at 11:17 AM, Christ= er Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

>>I think I was the one that brought up layouts originally. I
>>was more concerned with video layouts than audio layouts.
>>Currently, the requirements draft seems to focus more on
>>audio layout/spatial audio.
>>Requirements 3 and 16 both deal with parts of this. I feel
>>there needs to be more clear requirements on the ability for
>>the to represent the potential layouts of the audio/video can
>>that be offered. For example, I have 3 camera and 3 mics. I
>>can provide:
>>1) 3 individual video each with corresponding audio
>>2) 1 active speaker only switched video with mixed audio
>>3) 1 composed video including active speaker and 'n'
>>non-active speakers (where 'n' is may be all or some fixed<= br> >>limit) and mixed audio
>
>
>I actually think that your examples, as written, are different RENDERIN= G TYPES, because they only talk about mixing and composition.
>
>Confirmation that I am clueless about rendering types.

A value identifying the rendering algorithm used to produce a media s= tream sent towards the client.
In a client-to-client c= all this is backwards.=A0 "Capture" describes the stream producti= on process better, rendering is that the client does with the streams it re= ceives.=A0 Anyway, changing "Rendering type" to "rendering a= lgorithm" doesn't help me much.=A0

>>In my opinion, a LAYOUT TYPE is a description of how sources are pl= aced in a virtual room.
>>
>For me layout is about composition. Layouts do not necessarily create a= virtual room experience, particularly in multipoint calls.

Ok, so we need to make sure we have a common understanding of layout = then :)

So, just to clarify, do you think that source selection is layout?
I generally separate them, though they are related.=A0 For ins= tance, in a traditional Video MCU you can often choose a source-independent= layout (2x2 array of equal size windows, a 1+5 layout, where the "1&q= uot; window is bigger than the others, and at the top left, etc).=A0 Then y= ou can control the mapping of sources to windows separately.=A0 Not sure th= is is the only way to partition it, just the way I tend to use.=A0

I see four distinct elements in your mobile binaural case - (a) the sou= rces chosen for placement, (b) the set of placements used in creating a sou= nd stage, (c) the placement used for each particular source at the moment, = and (d) whether the outbound audio is binaural or not.=A0 I'd personall= y call (b) the audio layout, though you can equally well call (b+c) the aud= io layout.=A0=A0=A0

Regards,

Christer









=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>If the receiving endpoint wants to cont= rol the layout itself,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>it goes with option 1. If it has limite= d
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>resources/bandwidth/screens/etc it may = prefer option 2 or 3.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Cheers,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Charles
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > -----Original Message-----
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Of Christer Holmberg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > Sent: Tuesday, June 21, 2011 3:52= AM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > To: clue@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > Subject: [clue] Layout negotiatio= n
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > Hi,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > A while ago there were some discu= ssions about having requirements to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> negotiate the layout type, and at
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > least according to Stephen B it w= as within the scope of the work.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > =A0 =A0 =A0 =A0 "The ability= to negotiate an audio or video layout
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> is clearly
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> within scope, and has general
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > value it the group wants to take = it on.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > =A0 =A0 =A0 =A0 For instance, if = you combine video switching of multiple
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> sources with audio
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > mixing/transcoding, then the rece= iver is responsible
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > =A0 =A0 =A0 =A0 for the video lay= out but has no control over the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> audio layout.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> In that case, there are
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > advantages to allowing the receiv= er to tell the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > =A0 =A0 =A0 =A0 central audio mix= er where it wants the sources placed on the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> sound stage. =A0I have no objection =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > in principle to adding that kind = of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > =A0 =A0 =A0 =A0 negotiation to th= e requirements, though I think the group
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> should consider the impact on the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > schedule."
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > However, I haven't seen any i= nput after that.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > My idea would be that it is very = similar to the rendering type: CLUE
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> defines a mechanism to negotiate
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > the layout type, but doesn't = define specific types (instead an IANA
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> registry would be created for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > that). So, I don't think it w= ould have any significant impact on our
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> schedule.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > Whether it, in addition to negoti= ation a layout type (which
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> specifies
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> the source locations), should be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > possible for the user to more exp= licit place individual sources, as
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> mentioned by Stephen, can be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > discussed. However, that would pr= obably require a little
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> more work, so
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> at least I would be happy with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > a simple layout type negotiation = at this point.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > So, would people be ok with such = requirement?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > (Another alternative would be to = "embed" the layout type into the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> rendering type, but I think that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > would be very clumsy. Because, in= that case you would need to define
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> mulitple types for the same
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > rendering, but with different lay= outs.)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > Regards,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > Christer
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________________________________________= ____
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue@ietf.= org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/clue




--bcaec53f977904271804a64ecb88-- From christer.holmberg@ericsson.com Wed Jun 22 09:46:05 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43F321F84AC for ; Wed, 22 Jun 2011 09:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdlkY4jx6HSc for ; Wed, 22 Jun 2011 09:46:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8E73C21F8482 for ; Wed, 22 Jun 2011 09:46:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-e3-4e021c4b276d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A5.31.09774.B4C120E4; Wed, 22 Jun 2011 18:46:03 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 22 Jun 2011 18:46:03 +0200 From: Christer Holmberg To: Stephen Botzko Date: Wed, 22 Jun 2011 18:46:02 +0200 Thread-Topic: [clue] Layout negotiation Thread-Index: Acww8sQlRUBW5WOSS4K6jxoq1LlJrwABhLoA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A79A@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 16:46:06 -0000 Hi,=20 >>>I think I was the one that brought up layouts originally. I >>>was more concerned with video layouts than audio layouts. >>>Currently, the requirements draft seems to focus more on >>>audio layout/spatial audio. >>>Requirements 3 and 16 both deal with parts of this. I feel >>>there needs to be more clear requirements on the ability for >>>the to represent the potential layouts of the audio/video can >>>that be offered. For example, I have 3 camera and 3 mics. I >>>can provide: >>>1) 3 individual video each with corresponding audio >>>2) 1 active speaker only switched video with mixed audio >>>3) 1 composed video including active speaker and 'n' >>>non-active speakers (where 'n' is may be all or some fixed >>>limit) and mixed audio >> >> >>>>I actually think that your examples, as written, are different RENDERIN= G TYPES, because they only talk about mixing and composition. >> >>>Confirmation that I am clueless about rendering types. > =09 > =09 >>A value identifying the rendering algorithm used to produce a media strea= m sent towards the client. =09 >In a client-to-client call this is backwards. "Capture" describes the str= eam production process better, rendering is that the client does with the=20 >streams it receives. Anyway, changing "Rendering type" to "rendering algor= ithm" doesn't help me much.=20 It's probably easier to understand rendering type if one knows what we mean= by render. Our proposed definition is: "Rendering:=A0=A0 Composing a media signal from one or more media signals u= sing a specific composition algorithm, often according to a specific spatia= l model/layout." So, the "rendering type" is a value associated with that algorithm. So, I think the important thing in our "rendering" definition is that an ou= tput media signal is generated. Now, if people think that our usage of "rendering" is confusing, we can of = course use other wording instead. >>>In my opinion, a LAYOUT TYPE is a description of how sources are placed = in a virtual room. >>> >>>For me layout is about composition. Layouts do not necessarily create a = virtual room experience, particularly in multipoint calls. >> =09 >> =09 >>Ok, so we need to make sure we have a common understanding of layout then= :) >> =09 >>So, just to clarify, do you think that source selection is layout? > > >I generally separate them, though they are related. For instance, in a tr= aditional Video MCU you can often choose a source-independent layout (2x2 a= rray=20 >of equal size windows, a 1+5 layout, where the "1" window is bigger than t= he others, and at the top left, etc). Then you can control the mapping of= =20 >sources to windows separately. Not sure this is the only way to partition= it, just the way I tend to use. =20 Ok. So, first, I guess there is "source-dependent layout" and "source-indep= endent layout". Second, there is an algorithm that creates the output stream, using the lay= out as input. Of course, in this case one might not need to be able to explicitly indicat= e the algorithm - if it's enough to indicate the layout. >I see four distinct elements in your mobile binaural case - (a) the source= s chosen for placement, Correct. That's "source selection". >(b) the set of placements used in creating a sound stage, > >(c) the placement used for each particular source at the moment,=20 >and (d) whether the outbound audio is binaural or not. >I'd personally call (b) the audio layout, though you can equally well call= (b+c) the audio layout. =20 Ok. So, that would be a "source-dependent layout", I guess? Then, (d) would be the actual rendering algorithm, using the layout as inpu= t. Regards, Christer =09 =09 =09 =09 =09 =09 =09 =09 =09 >If the receiving endpoint wants to control the layout its= elf, >it goes with option 1. If it has limited >resources/bandwidth/screens/etc it may prefer option 2 or= 3. > > Cheers, > Charles > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.= org] On Behalf > Of Christer Holmberg > > Sent: Tuesday, June 21, 2011 3:52 AM > > To: clue@ietf.org > > Subject: [clue] Layout negotiation > > > > Hi, > > > > A while ago there were some discussions about having r= equirements to > negotiate the layout type, and at > > least according to Stephen B it was within the scope o= f the work. > > > > "The ability to negotiate an audio or video la= yout > is clearly > within scope, and has general > > value it the group wants to take it on. > > For instance, if you combine video switching o= f multiple > sources with audio > > mixing/transcoding, then the receiver is responsible > > for the video layout but has no control over t= he > audio layout. > In that case, there are > > advantages to allowing the receiver to tell the > > central audio mixer where it wants the sources= placed on the > sound stage. I have no objection > > in principle to adding that kind of > > negotiation to the requirements, though I thin= k the group > should consider the impact on the > > schedule." > > > > However, I haven't seen any input after that. > > > > My idea would be that it is very similar to the render= ing type: CLUE > defines a mechanism to negotiate > > the layout type, but doesn't define specific types (in= stead an IANA > registry would be created for > > that). So, I don't think it would have any significant= impact on our > schedule. > > > > Whether it, in addition to negotiation a layout type (= which > specifies > the source locations), should be > > possible for the user to more explicit place individua= l sources, as > mentioned by Stephen, can be > > discussed. However, that would probably require a litt= le > more work, so > at least I would be happy with > > a simple layout type negotiation at this point. > > > > So, would people be ok with such requirement? > > > > (Another alternative would be to "embed" the layout ty= pe into the > rendering type, but I think that > > would be very clumsy. Because, in that case you would = need to define > mulitple types for the same > > rendering, but with different layouts.) > > > > Regards, > > > > Christer > > > > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =09 =09 =09 =09 From espeberg@cisco.com Wed Jun 22 09:49:23 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B9321F84AF for ; Wed, 22 Jun 2011 09:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAf6rUrMiwoo for ; Wed, 22 Jun 2011 09:49:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A19A321F84AB for ; Wed, 22 Jun 2011 09:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=4953; q=dns/txt; s=iport; t=1308761361; x=1309970961; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=itYrxyG2/JLylupoSMCgJem9MeMFtWFaqVBUxdYv1Lg=; b=SKUE/2uthjWP5yfurGIbb8dpBDDAVZhn+T/XF+4o43VDNF4bF3sdpdgf dfEDLcIBZJhrtQOyCdyaKIs56CRuOegtlLt8FC9KH1yLNRTc68bt8UxiI oDpWZW7I89jcywUsITekP7NJiHIwHieMhF5qPPNuUet9wiioYh7Bub6gs 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAPcbAk6Q/khM/2dsb2JhbABUl3aPGneqP55Mhi0ElliLIA X-IronPort-AV: E=Sophos;i="4.65,407,1304294400"; d="scan'208";a="96058928" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 22 Jun 2011 16:49:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5MGnKW0010163; Wed, 22 Jun 2011 16:49:20 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 18:49:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jun 2011 18:49:19 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E71BA82@XMB-AMS-214.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Layout negotiation Thread-Index: Acww6uD+TdzXSqNlTCu/bY/VZBH7CAABAFswAALtWMA= References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se> From: "Espen Berger (espeberg)" To: "Christer Holmberg" , "Stephen Botzko" X-OriginalArrivalTime: 22 Jun 2011 16:49:20.0428 (UTC) FILETIME=[5515B6C0:01CC30FC] Cc: clue@ietf.org Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 16:49:23 -0000 The CLUE definition document talks about both source selection, rendering and layouts.=20 Using the terms from that document I do not see source selection as a part of layout, but they are used together to create a good user experience.=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 22. juni 2011 17:17 To: Stephen Botzko Cc: clue@ietf.org Subject: Re: [clue] Layout negotiation Hi,=20 =09 >>I think I was the one that brought up layouts originally. I >>was more concerned with video layouts than audio layouts. >>Currently, the requirements draft seems to focus more on >>audio layout/spatial audio. >>Requirements 3 and 16 both deal with parts of this. I feel >>there needs to be more clear requirements on the ability for >>the to represent the potential layouts of the audio/video can >>that be offered. For example, I have 3 camera and 3 mics. I >>can provide: >>1) 3 individual video each with corresponding audio >>2) 1 active speaker only switched video with mixed audio >>3) 1 composed video including active speaker and 'n' >>non-active speakers (where 'n' is may be all or some fixed >>limit) and mixed audio > =09 > =09 >I actually think that your examples, as written, are different RENDERING TYPES, because they only talk about mixing and composition. > =09 >Confirmation that I am clueless about rendering types.=20 A value identifying the rendering algorithm used to produce a media stream sent towards the client. =09 >>In my opinion, a LAYOUT TYPE is a description of how sources are placed in a virtual room. >> =09 >For me layout is about composition. Layouts do not necessarily create a virtual room experience, particularly in multipoint calls.=20 Ok, so we need to make sure we have a common understanding of layout then :) So, just to clarify, do you think that source selection is layout? =09 Regards, Christer =09 >If the receiving endpoint wants to control the layout itself, >it goes with option 1. If it has limited >resources/bandwidth/screens/etc it may prefer option 2 or 3. > > Cheers, > Charles > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Christer Holmberg > > Sent: Tuesday, June 21, 2011 3:52 AM > > To: clue@ietf.org > > Subject: [clue] Layout negotiation > > > > Hi, > > > > A while ago there were some discussions about having requirements to > negotiate the layout type, and at > > least according to Stephen B it was within the scope of the work. > > > > "The ability to negotiate an audio or video layout > is clearly > within scope, and has general > > value it the group wants to take it on. > > For instance, if you combine video switching of multiple > sources with audio > > mixing/transcoding, then the receiver is responsible > > for the video layout but has no control over the > audio layout. > In that case, there are > > advantages to allowing the receiver to tell the > > central audio mixer where it wants the sources placed on the > sound stage. I have no objection > > in principle to adding that kind of > > negotiation to the requirements, though I think the group > should consider the impact on the > > schedule." > > > > However, I haven't seen any input after that. > > > > My idea would be that it is very similar to the rendering type: CLUE > defines a mechanism to negotiate > > the layout type, but doesn't define specific types (instead an IANA > registry would be created for > > that). So, I don't think it would have any significant impact on our > schedule. > > > > Whether it, in addition to negotiation a layout type (which > specifies > the source locations), should be > > possible for the user to more explicit place individual sources, as > mentioned by Stephen, can be > > discussed. However, that would probably require a little > more work, so > at least I would be happy with > > a simple layout type negotiation at this point. > > > > So, would people be ok with such requirement? > > > > (Another alternative would be to "embed" the layout type into the > rendering type, but I think that > > would be very clumsy. Because, in that case you would need to define > mulitple types for the same > > rendering, but with different layouts.) > > > > Regards, > > > > Christer > > > > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =09 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From eckelcu@cisco.com Wed Jun 22 09:51:20 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB5C21F84F9 for ; Wed, 22 Jun 2011 09:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id golOBTMHRpw0 for ; Wed, 22 Jun 2011 09:51:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 374BC21F8503 for ; Wed, 22 Jun 2011 09:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1077; q=dns/txt; s=iport; t=1308761479; x=1309971079; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=DIWY00FxFF03tBzKM6xc8UzI7sgzRyQD7dmewRncE24=; b=HsS5HyVI3yqVgb+ZAiN90n6tFNvXbD+s0VBL2dX47nK0S8xtFMv0NyqQ ONaILjaEaapuTaGtpFKyPruin5QXBAcVzbCTwCmo75AFlVhFTkcYftP1/ IkdGMm29KsVBTtRX7ifyt21tp0jaLDLlf68RjJO0q/UAJEurEfNLPMFU3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAAwdAk6rRDoJ/2dsb2JhbABUl3aPGneqTp5Nhi0EhyWPM4s+ X-IronPort-AV: E=Sophos;i="4.65,407,1304294400"; d="scan'208";a="467222354" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 22 Jun 2011 16:51:18 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5MGpICO006861; Wed, 22 Jun 2011 16:51:18 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 09:51:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jun 2011 09:51:16 -0700 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB53370DC@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] negotiation Thread-Index: AcwwiG6Qy08GGqFOT/G7GQNQ14C2ewAFGraQABfvHLA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6342@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53370DC@ESESSCMS0356.eemea.ericsson.se> From: "Charles Eckel (eckelcu)" To: "Christer Holmberg" , "Allyn Romanow (allyn)" , X-OriginalArrivalTime: 22 Jun 2011 16:51:18.0533 (UTC) FILETIME=[9B7B1B50:01CC30FC] Subject: Re: [clue] negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 16:51:20 -0000 +1 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Tuesday, June 21, 2011 10:27 PM > To: Allyn Romanow (allyn); clue@ietf.org > Subject: Re: [clue] negotiation >=20 >=20 > Hi, >=20 > >I believe we can accomplish the exchange of information necessary for CLUE with declarations and > without the need for negotiation, which is more complex. This has been the thinking thus far. > > > >Several people (Christer, Charles) have recently been using the term "negotiation". I take it they > mean it in the loose sense of exchange information. > > > >In any case, whether the communication is via negotiation or declaration is part of the solution > design, not requirements. >=20 > I agree. The requirements should only talk about being able to provide information. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From eckelcu@cisco.com Wed Jun 22 10:03:02 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C917821F8501 for ; Wed, 22 Jun 2011 10:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRJdGABTlBhQ for ; Wed, 22 Jun 2011 10:03:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id BBAED21F856F for ; Wed, 22 Jun 2011 10:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=8722; q=dns/txt; s=iport; t=1308762181; x=1309971781; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=bl7NW0SDJFZ2nAoS7PyZg64Wi5iCgEnohME1F9atk/E=; b=A8ZeLcqyv5m1LuZjjPvdvif+BaHhjYNy/YuUuaKu5Hazentgg82W+e4L sXTDDxA4PAK1ZxmI9UFB3gYgGwD5Wu2NndcAhHXN8gEM0I5GkqGZmp5bP 0HTjgCmuYvspi0S5OPpG3+Wor9jDHr3zBbhbA7aabMVSHQZsPCd9jYHSt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AACsfAk6rRDoG/2dsb2JhbABUl3aPGneIc6FXnk2GLQSHJY8ziz4 X-IronPort-AV: E=Sophos;i="4.65,407,1304294400"; d="scan'208";a="467232507" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 22 Jun 2011 17:03:01 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5MH2x9B006796; Wed, 22 Jun 2011 17:03:01 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 10:03:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jun 2011 10:03:00 -0700 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB559A79A@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Layout negotiation Thread-Index: Acww8sQlRUBW5WOSS4K6jxoq1LlJrwABhLoAAAEsT+A= References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A79A@ESESSCMS0356.eemea.ericsson.se> From: "Charles Eckel (eckelcu)" To: "Christer Holmberg" , "Stephen Botzko" X-OriginalArrivalTime: 22 Jun 2011 17:03:01.0010 (UTC) FILETIME=[3E309720:01CC30FE] Cc: clue@ietf.org Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 17:03:02 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, June 22, 2011 9:46 AM > To: Stephen Botzko > Cc: Charles Eckel (eckelcu); clue@ietf.org > Subject: RE: [clue] Layout negotiation >=20 >=20 > Hi, >=20 > >>>I think I was the one that brought up layouts originally. I > >>>was more concerned with video layouts than audio layouts. > >>>Currently, the requirements draft seems to focus more on > >>>audio layout/spatial audio. > >>>Requirements 3 and 16 both deal with parts of this. I feel > >>>there needs to be more clear requirements on the ability for > >>>the to represent the potential layouts of the audio/video can > >>>that be offered. For example, I have 3 camera and 3 mics. I > >>>can provide: > >>>1) 3 individual video each with corresponding audio > >>>2) 1 active speaker only switched video with mixed audio > >>>3) 1 composed video including active speaker and 'n' > >>>non-active speakers (where 'n' is may be all or some fixed > >>>limit) and mixed audio > >> > >> > >>>>I actually think that your examples, as written, are different = RENDERING TYPES, because they only > talk about mixing and composition. > >> > >>>Confirmation that I am clueless about rendering types. > > > > > >>A value identifying the rendering algorithm used to produce a media = stream sent towards the client. >=20 > >In a client-to-client call this is backwards. "Capture" describes = the stream production process > better, rendering is that the client does with the > >streams it receives. Anyway, changing "Rendering type" to "rendering = algorithm" doesn't help me much. >=20 > It's probably easier to understand rendering type if one knows what we = mean by render. >=20 > Our proposed definition is: >=20 > "Rendering:=A0=A0 Composing a media signal from one or more media = signals using a specific composition > algorithm, often according to a specific spatial model/layout." >=20 > So, the "rendering type" is a value associated with that algorithm. >=20 > So, I think the important thing in our "rendering" definition is that = an output media signal is > generated. >=20 > Now, if people think that our usage of "rendering" is confusing, we = can of course use other wording > instead. This works for me. It may be useful to expand with typical audio and = video examples, such as mixing multiple audio stream inputs into a = single audio stream output, or composing multiple video stream inputs = into a single video stream output. Cheers, Charles >=20 >=20 >=20 > >>>In my opinion, a LAYOUT TYPE is a description of how sources are = placed in a virtual room. > >>> > >>>For me layout is about composition. Layouts do not necessarily = create a virtual room experience, > particularly in multipoint calls. > >> > >> > >>Ok, so we need to make sure we have a common understanding of layout = then :) > >> > >>So, just to clarify, do you think that source selection is layout? > > > > > >I generally separate them, though they are related. For instance, in = a traditional Video MCU you can > often choose a source-independent layout (2x2 array > >of equal size windows, a 1+5 layout, where the "1" window is bigger = than the others, and at the top > left, etc). Then you can control the mapping of > >sources to windows separately. Not sure this is the only way to = partition it, just the way I tend to > use. >=20 > Ok. So, first, I guess there is "source-dependent layout" and = "source-independent layout". >=20 > Second, there is an algorithm that creates the output stream, using = the layout as input. >=20 > Of course, in this case one might not need to be able to explicitly = indicate the algorithm - if it's > enough to indicate the layout. >=20 >=20 >=20 >=20 > >I see four distinct elements in your mobile binaural case - (a) the = sources chosen for placement, >=20 > Correct. That's "source selection". >=20 > >(b) the set of placements used in creating a sound stage, > > > >(c) the placement used for each particular source at the moment, > >and (d) whether the outbound audio is binaural or not. > >I'd personally call (b) the audio layout, though you can equally well = call (b+c) the audio layout. >=20 > Ok. So, that would be a "source-dependent layout", I guess? >=20 > Then, (d) would be the actual rendering algorithm, using the layout as = input. >=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > >If the receiving endpoint wants to control the = layout itself, > >it goes with option 1. If it has limited > >resources/bandwidth/screens/etc it may prefer option = 2 or 3. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On Behalf > > Of Christer Holmberg > > > Sent: Tuesday, June 21, 2011 3:52 AM > > > To: clue@ietf.org > > > Subject: [clue] Layout negotiation > > > > > > Hi, > > > > > > A while ago there were some discussions about = having requirements to > > negotiate the layout type, and at > > > least according to Stephen B it was within the = scope of the work. > > > > > > "The ability to negotiate an audio or = video layout > > is clearly > > within scope, and has general > > > value it the group wants to take it on. > > > For instance, if you combine video = switching of multiple > > sources with audio > > > mixing/transcoding, then the receiver is = responsible > > > for the video layout but has no control = over the > > audio layout. > > In that case, there are > > > advantages to allowing the receiver to tell the > > > central audio mixer where it wants the = sources placed on the > > sound stage. I have no objection > > > in principle to adding that kind of > > > negotiation to the requirements, though I = think the group > > should consider the impact on the > > > schedule." > > > > > > However, I haven't seen any input after that. > > > > > > My idea would be that it is very similar to the = rendering type: CLUE > > defines a mechanism to negotiate > > > the layout type, but doesn't define specific = types (instead an IANA > > registry would be created for > > > that). So, I don't think it would have any = significant impact on our > > schedule. > > > > > > Whether it, in addition to negotiation a layout = type (which > > specifies > > the source locations), should be > > > possible for the user to more explicit place = individual sources, as > > mentioned by Stephen, can be > > > discussed. However, that would probably require a = little > > more work, so > > at least I would be happy with > > > a simple layout type negotiation at this point. > > > > > > So, would people be ok with such requirement? > > > > > > (Another alternative would be to "embed" the = layout type into the > > rendering type, but I think that > > > would be very clumsy. Because, in that case you = would need to define > > mulitple types for the same > > > rendering, but with different layouts.) > > > > > > Regards, > > > > > > Christer > > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 >=20 >=20 >=20 From eckelcu@cisco.com Wed Jun 22 10:18:53 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E4511E80EC for ; Wed, 22 Jun 2011 10:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.346 X-Spam-Level: X-Spam-Status: No, score=-9.346 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+EfNxRGNxJQ for ; Wed, 22 Jun 2011 10:18:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id B8D3111E807E for ; Wed, 22 Jun 2011 10:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=25542; q=dns/txt; s=iport; t=1308763131; x=1309972731; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=I40clf4M+LdaN8Q8ZIsfkmB72J/uX2vX5F1dfHcR5tA=; b=LtAgRQDRuF7RmH3LJ5EaBlqCnmaXkY1YQc3dju+feiKI1PYJ8ImdliBH BKfsD+sd3ElfUxuDAr2W5neH3Z8onsphkrurKQiuh5cP9qWNRP4rv2lUK M131EhtxjQF+Zb8alBAbQXi+HklldtguU+47lWGYHK8pmjNypV1ivd7YU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAOoiAk6rRDoJ/2dsb2JhbABGDpd2jxp3iHOhaJ5Lgx+DDgSHJY8ziz4 X-IronPort-AV: E=Sophos;i="4.65,407,1304294400"; d="scan'208";a="467247813" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 22 Jun 2011 17:18:51 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5MHIpYl017869 for ; Wed, 22 Jun 2011 17:18:51 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 10:18:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jun 2011 10:18:50 -0700 Message-ID: In-Reply-To: <4E020184.1040806@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acww6/a8YwI9ZRvfTRa6g67VzrDRzQAEySlA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A548@ESESSCMS0356.eemea.ericsson.se> <4E020184.1040806@cisco.com> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 22 Jun 2011 17:18:50.0970 (UTC) FILETIME=[7468FBA0:01CC3100] Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 17:18:53 -0000 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) > Sent: Wednesday, June 22, 2011 7:52 AM > To: clue@ietf.org > Subject: Re: [clue] Requirement on centralized media mixing >=20 >=20 >=20 > On 6/22/2011 8:14 AM, Christer Holmberg wrote: > > > > Hi, > > > >>>> I understand you are advocating a general mechanism, which is why I especially want to see use > cases showing > >>>> the need for the panned, plain, thresholded, linear, non-linear rendering types you > >>>> proposed. If someone has other rendering types, then they would be helpful too. > >>> > >>>> For me the negotiation of "rendering type" is a mechanism. I am thinking all we need is number > of channels, but I am quite willing to change my view if the use cases show more is needed. > >>> > >>> What do you mean by "number of channels"? > >>> > >>> In the SDP a=3Drtpmap attribute you are able to indicate the = number of audio channels, > >>> but I don't think that helps. > >> > >> Setting aside binaural for now, I am envisioning that I am receiving three audio channels, and that > >> CLUE mechanisms are telling me "left, center, right" for each channel. I think that's all I need > to > >> know in order to render the audio properly, but I am thinking you don't agree. > > > > It depends on WHO is rendering. > > > > An entity receiving all "raw material" can of course do whatever it wants with it. But, in the > centralized rendering case the idea is that the rendering is done on behalf of a client, since the > client due to different reasons can't do it itself. >=20 > There is a distinction here between describing "what you have" or "what > you want". >=20 > AFAIK the intent right now is that what is described is "what I have", > and "what I can provide". E.g. >=20 > - I have some microphones, speakers, cameras, displays in a particular > arrangement Let me refer to this as the raw inputs. >=20 > - I can provide some selection of media streams having content, either > renditions of particular cameras, microphones, etc. or specific > combinations of those. Exactly, and I can provide multiple different combinations of the raw inputs. This may include, for example: (a) all the raw inputs (b) some subset of the raw inputs (c) some composition of the raw inputs The end device may choose to receive (a) or (b) or (c) or perhaps even (a)+(c), etc. As for the requirements for CLUE, it is not clear to me that this is covered currently. I would like to see that it is added. As for how to do it, SDPCapNeg and the SDP grouping frameworks provide tools that may help. We may choose to leverage these or not, but I agree that is not in scope for the requirements. =20 Cheers, Charles >=20 > It seems to me that binaural can fit into this model. The room > configuration suitable to receive binaural involves "speakers" > (headphones) arranged in a particular way. I guess that then there would > need be a way to specify that a media stream that a room can provide is > encoded as a binaural "mix" of a particular set of microphones on the > source side. >=20 > It isn't in principle necessary to "ask" for binaural. Rather what is > being done is "offer" binaural. But the actual mechanism for doing that > seems independent of CLUE. >=20 > Thanks, > Paul >=20 > >> That I would also need to know "panning" vs "plain"??? I don't understand what you are thinking I > would do differently if I knew that, which is why I am wanting more use cases. > > > > Maybe there is no need to separate "panning" vs "plain". I will need to look into that (there for > sure is a need to separate binaural from other stereo, though). > > > > Other use-cases is which video and/or audio streams are sent towards a client in the first place. > E.g. Sending the video of the most active speaker, sending the audio of the 4 most active speakers, > etc. I consider that being different rendering types also, because they affect how the output stream > is generated. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > Hi, > > > > > > >I would like to see use cases, particularly for non-binaural > proposals. It seems to me that a receiver doesn't really>care if the stereo it is receiving is > "panned", "plain" or "thresholded", or if it is linear or non-linear. So use cases>motivating those > choices would be helpful. > > > > > >Also, the proposal is for a specific mechanism ("rendering type"). > It may be premature to identify the mechanism>in the requirements - since often there are multiple > ways to achieve the desired ends. > > > > > > > > > > Again, I am not suggesting to specify a specific mechanism - only a > mechanism to negotiate the rendering type mechanism. > > > > > > > > Yes, I am using binaural as a rendering type EXAMPLE, but you are > the one who keep saying that I am trying to specify binaural :) > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > On Mon, Jun 20, 2011 at 5:47 PM, Allyn Romanow > (allyn)> wrote: > > > > > > Hi Christer, > > > > I think that you are proposing that CLUE needs a mechanism to pass > > information, such as a tag, on "rendering type", for example, > binaural, > > threshold, etc. > > Is that correct? > > > > And that you are not asking for any more from CLUE than simply > > identifying the rendering type. > > Is that correct? > > > > IF both of these statements are correct, than personally I think it > is > > fine TO include the information of rendering type, such as > "binaural", > > by some mechanism, such as a tag, AS LONG AS there is an accepted > Use > > Case that shows the necessity of communicating the rendering type, > such > > as "thresholding" or "panning". > > > > How do other people feel about this? > > > > Thanks, > > Allyn > > > > -----Original Message----- > > > > From: Christer Holmberg > [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 20, 2011 12:23 PM > > To: Allyn Romanow (allyn); Mary Barnes > > > > Cc: clue@ietf.org; Botzko, Stephen; Bill > Mauchly (bmauchly) > > Subject: RE: [clue] Requirement on centralized media mixing > > > > Hi Allyn, > > > > >Still trying to get clarification- > > > > > >I read your description of various types of rendering. > > >Still trying to understand what you want from CLUE- > > >If we have a tag that says "binaural" or stereo, sub binaural, are > we > > >done? > > > > Of course we could have a binaural specific SDP attribute, e.g. > > a=3Dbinaural. > > > > But, again, what we are proposing is a general mechanism, that could > > look something like: > > > > a=3Drendering-type =3D > > > > could then e.g. be "binaural", but it could also be > something > > else (we showed a few example in the e-mail). > > > > >Or do you want CLUE to describe how to do some kind of rendering? > To > > say > > >something more about specific rendering functions? > > > > No, CLUE doesn't need to say anything about that. > > > > There would of course need to be a rendering description associated > with > > each rendering type value, but CLUE wouldn't define those. > > > > The idea is that an IANA registry is created, where people can > register > > their rendering type values. > > > > Regards, > > > > Christer > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > [mailto:christer.holmberg@ericsson.com] > > > Sent: Sunday, June 19, 2011 10:29 PM > > > To: Allyn Romanow (allyn); Mary Barnes > > > > > Cc: clue@ietf.org; Botzko, Stephen; Bill > Mauchly (bmauchly) > > > Subject: RE: [clue] Requirement on centralized media mixing > > > > > > > > > Hi Allyn, > > > > > > I appologise that it took some time to reply. > > > > > > We've been working on some definition/example text (I sent it to > the > > > list just a few minutes ago), which I hope will clarify some of > the > > > questions that have been asked. > > > > > > >Also, what kind of support are you asking for binaural? I > believe > > it's > > > often considered as a subset of stereo. What are you asking for? > A > > > simple tag that says "binaural", or the specification > > > >of a rendering system for binaural? Precisely what are asking > for? > > > > > > From CLUE, we are only asking for a general mechanism to request > and > > > indicate different rendering types (see definition in other e- > mail). > > > > > > An example of such rendering type is binaural, BUT we are *NOT* > asking > > > CLUE to define any binaural specific SDP attributes etc. If such > are > > > needed, we agree that it needs to be done as a separate task. > > > > > > Before I try to answer your other questions, please take a look > at the > > > definition/example e-mail, which I hope will clarify what we mean > by > > > rendering and rendering type. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Christer - > > > > > > In spirit I am enthusiastic about what you are proposing > > (meaning > > > good quality mobile participation). I'm not clear on how the > spirit > > > becomes instantiated in our protocol, so I have some questions > below J > > > > > > Thanks, > > > > > > Allyn > > > > > > > > > > > > > > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] On > > > > > Behalf Of Christer Holmberg > > > Sent: Tuesday, June 14, 2011 7:23 AM > > > > > To: clue@ietf.org > > > > > Subject: [clue] Requirement on centralized media mixing > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > During the last interim meeting (May 12th) we discussed a > > > requirement proposal > > > > > > stating that an endpoint must be able to request central > audio > > > rendering > > > > > > of different predefined formats, including 3D binaural > > rendering. > > > > > > (Link to proposal: http://www.ietf.org/mail- > > > archive/web/clue/current/msg00179.html) > > > > > > > > > > > > The proposal was well received, with the reservation that > it > > > should not be mandatory > > > > > > for the solution to implement centralized 3D binaural > rendering, > > > > > i.e.an endpoint should > > > > > > > > be able to request 3D binaural rendering, but had no > guaranty > > > that such rendering was > > > > > > supported by the system. > > > > > > > > > > > > It was decided to look how such requirement could look > like. > > > > > > > > > > > > When I look the -03 version of the req draft, Requirement > 2c > > > states: > > > > > > > > > > > > "The solution MUST NOT preclude the use of binaural > audio." > > > > > > > > > > > > I think that requirement is unclear, and it doesn't really > give > > > any guidance to our work. > > > > > > > > > > > > Due to that, and also due to the fact that rather than > talking > > > about specific rendering types, > > > > > > I would like to propose more general requirement text on > the > > > negotiation of the media mixing type, > > > > > > and the usage of centralized media mixing in the first > place. > > > > > > > > > > > > The mechanism would be extendable, so new types can be > added in > > > future. > > > > > > > > > > > > So, the proposed requirements are: > > > > > > > > > > > > REQ-x: It MUST be possible to negotiate the usage of > > > centralized media mixing. System support of centralized media > mixing > > is > > > optional. > > > > > > > > > > > > REQ-y: When centralized media mixing is used, it MUST be > > > possible to negotiate the type of media rendering provided for > each > > > media stream received by a client. > > > > > > --- > > > > > > [ar] I have a few questions/comments: > > > > > > 1. The term "negotiate" troubles me as I think it > means > > a > > > particular form of communication that dictates the solution. What > is > > > being asked for is the receiver to know that it is receiving > > > "centralized media mixing". This may not be the end product of a > > > negotiation. The same is true of the use of the term negotiate in > the > > > second requirement. What is needed is a mechanism by which the > > receiver > > > may know what type of "media rendering" is being received. > > > > > > So, I'd rather offer, The solution must support a > means for > > > identifying a stream which is "centralized media mixing". > > > > > > And, When "centralized media mixing" is used, the solution > must > > > support a means for identifying... > > > > > > > > > > > > 2. Also, I'm not too sure what "media rendering", > the > > > phrase in the second reqmt, represents- SDP and RTP recognize > audio > > > channels and recognize codecs. Is this what is referred to as > "media > > > rendering"? Or is it something different? What very specifically? > > > > > > > > > > > > 3. After reading more of the discussion, I realize > that I > > > don't fully understand what is meant in the first reqmt by > > "centralized > > > media mixing" or "rendering", which term is used in another > email. I > > > had thought you meant the usual audio mixing such as discussed in > RFC > > > 5117.( I figured it was an understood part of the topology so > didn't > > > need to be called out in particular. But I don't mind calling it > > out.) > > > In any case, now I'm not sure what you mean, maybe it is > something > > > other than typical MCU mixing behavior as described in RFC 5117? > > > > > > > > > > > > 4. As for the discussion of binaural.. here is what > it > > > seems like to me.. AVP, RFC 3551 specifies the number of audio > > > channels, what they refer to, and types of codecs. Binaural is > > > neither. As you say, Christer, it's a type of stereo channel. > Steve > > > feels that "binaural" must be recognized in SDP, which of course, > it > > is > > > not currently. > > > > > > > > > > > > I'm not entirely sure what needs to be specified about > binaural, > > > given that it is neither channel -type nor codec-type. What needs > to > > be > > > standardized? This question is probably more for Steve, or both > of > > you. > > > If the receiving device knows it's getting binaural stereo, then > it > > can > > > run some algorithms to improve quality and if it isn't binaural, > it > > > won't run those algs., or something analogous? If that is the > case, I > > > don't see what needs to be standardized that isn't already > > > standardized... But I'm eager to learn. > > > > > > > > > > > > Thanks- > > > > > > Allyn > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > > > _______________________________________________ > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Wed Jun 22 10:46:30 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1DC21F854F for ; Wed, 22 Jun 2011 10:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.871 X-Spam-Level: X-Spam-Status: No, score=-104.871 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYeGgjvRHsda for ; Wed, 22 Jun 2011 10:46:29 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BF82B21F854E for ; Wed, 22 Jun 2011 10:46:28 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN700C4UDDDSY@szxga04-in.huawei.com> for clue@ietf.org; Thu, 23 Jun 2011 01:46:25 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN700IWQDDDJE@szxga04-in.huawei.com> for clue@ietf.org; Thu, 23 Jun 2011 01:46:25 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-35-190.red.bezeqint.net [79.176.35.190]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN700BXWDD13G@szxml12-in.huawei.com>; Thu, 23 Jun 2011 01:46:25 +0800 (CST) Date: Wed, 22 Jun 2011 20:44:16 +0300 From: Roni Even In-reply-to: <7F2072F1E0DE894DA4B517B93C6A05851DB559A733@ESESSCMS0356.eemea.ericsson.se> To: 'Christer Holmberg' , 'Stephen Botzko' Message-id: <014401cc3104$076a29d0$163e7d70$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acww0Bm8VDTJV27YTXeT+ssx3eOWAQABm+GwAAXgVUAABTjWkA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> <00f801cc30d8$2a888140$7f9983c0$%roni@huawei.com> <7F2072F1E0DE894DA4B517B93C6A05851DB559A733@ESESSCMS0356.eemea.ericsson.se> Cc: clue@ietf.org Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 17:46:30 -0000 Hi Christer, What you describe is not CLUE specific. It applies to multipoint even without telepresence extension and I am not sure > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, June 22, 2011 6:08 PM > To: Roni Even; 'Stephen Botzko' > Cc: clue@ietf.org > Subject: RE: [clue] Requirement on centralized media mixing > > > Hi Roni, > > >In XCON data model http://tools.ietf.org/html/draft-ietf-xcon-common- > data-model-31#section-4.2.13 there is a specification of video layout > control that > >describes the continuous presence layout. There was no requirement for > something similar for audio. I assume that Christer wants to see > something similar > >to that definition for audio but I am not sure if there is a use case > for that, currently SDP RTPMAP has the encoding parameters that allows > the > >specification of the number of audio channels which as far as I > understand is sufficient for telepresence systems.< mal> > > > >If there is a general need to negotiate not only the number of > channels but also a non codec specific way to negotiate audio mixing > parameter, I am not > >sure this is a CLUE topic. In which case its support will be part of > interoperability requirement with SIP systems that do not support > telepresence > >extensions. > > We do have a requirement to interoperate with "single stream devices" > (that might still be CLUE aware), and then there is a need to specify > source selection, both for audio and video. > > In the most simple case, the generated stream towards the device is > done simply by switching, but in more advanced cases there will be need > for mixing, where source selection migth be needed for the mixing > algorithm. What you describe is not CLUE specific. It applies to multipoint even without telepresence extension and I am not sure what is the new requirement here. In the XCON + SIP case the XCON data model describe the video layout for the conference but the selection of sources to mix is done using SDP. What I was saying that there was no requirement in the past to describe to the MCU the mixing algorithm and if there was one it would be done by special conference definition like XCON for the whole conference and not in the protocol. In your example you want specific mixing mode per participant done by the MCU. I think that it may be needed for video (personal layout) and if there is a use case for audio. I am not sure it is CLUE work since it applies also to current SIP systems. Roni > > Regards, > > Christer > > > > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf Of Stephen Botzko > Sent: Wednesday, June 22, 2011 2:29 PM > To: Christer Holmberg > Cc: clue@ietf.org > Subject: Re: [clue] Requirement on centralized media mixing > > > > > > On Wed, Jun 22, 2011 at 1:24 AM, Christer Holmberg > wrote: > > > Hi Stephen lass=MsoNormal style='margin-bottom:12.0pt'> > >I understand you are advocating a general mechanism, which is > why I especially want to see use cases showing the need for the panned, > plain, thresholded, linear, non-linear rendering types you > >proposed. If someone has other rendering types, then they > would be helpful too. > > > >For me the negotiation of "rendering type" is a mechanism. I > am thinking all we need is number of channels, but I am quite willing > to change my view if the use cases show more is needed. > > What do you mean by "number of channels"? > > In the SDP a=rtpmap attribute you are able to indicate the > number of audio channels, but I don't think that helps. > > Setting aside binaural for now, I am envisioning that I am > receiving three audio channels, and that CLUE mechanisms are telling me > &q uot; for each channel. I think that's all I need to know in order > to render the audio properly, but I am thinking you don't agree. That > I would also need to know "panning" vs "plain"??? I don't understand > what you are thinking I would do differently if I knew that, which is > why I am wanting more use cases. > > Regards, > > Christer > > > > > > > > On Tue, Jun 21, 2011 at 2:11 PM, Christer > Holmberg wrote: > > > Hi, > > > >I would like to ly for non-binaural > proposals. It seems to me that a receiver doesn't really >care if the > stereo it is receiving is "panned", "plain" or "thresholded", or if it > is linear or non-linear. So use cases >motivating those choices would > be helpful. > > > >Also, the proposal is for a specific > mechanism ("rendering type"). It may be premature to identify the > mechanism >in the requirements - since often there are multiple ways to > achieve the desired ends. > > > > > Again, I am not suggesting to specify a > specific mechanism - only a mechanism to negotiate the rendering type > mechanism. > > > > Yes, I am using binaural as a rendering > type EXAMPLE, but you are the one who keep saying that I am try ) > > > > Regards, > > > > Christer > > > > > On Mon, Jun 20, 2011 at 5:47 PM, Allyn > Romanow (allyn) > wrote: > > > Hi Christer, > > I think that you are proposing that CLUE > needs a mechanism to pass > information, such as a tag, on > "rendering type", for example, binaural, > threshold, etc. > Is that correct? > > And that you ar from CLUE than simply > identifying the rendering type. > Is that correct? > > IF both of these statements are correct, > than personally I think it is > fine TO include the information of > rendering type, such as "binaural", > by some mechanism, such as a tag, AS > LONG AS there is an accepted Use > Case that shows the necessity of > communicating the rendering type, such > as "thresholding" or "panning". > > How do other people feel about this? > > Thanks, > > -----Original Message----- > > From: Christer Holmberg > [mailto:christer.holmberg@ericsson.com n.com>] > Sent: Monday, June 20, 2011 12:23 PM > To: Allyn Romanow (allyn); Mary Barnes > > Cc: clue@ietf.org; > Botzko, Stephen; Bill Mauchly (bmauchly) > Subject: RE: [clue] Requirement on > centralized media mixing > > Hi A ; >Still trying to get > clarification- > > > >I read your description of various > types of rendering. > >Still trying to understand what you > want from CLUE- > >If we have a tag that says "binaural" > or stereo, sub binaural, are we > >done? > > Of course we could have a binaural > specific SDP attribute, e.g. > a=binaural. > > But, again, what we are proposing is a > general mechanism, that could > look something like: > > > could then e.g. be "binaural", > but it could also be something > else (we showed a few example in the e- > mail). > > >Or do you want CLUE to describe how to > do some kind of rendering? To > say > >something more about specific rendering > functions? > > No, CLUE doesn't need to say anything > about that. > > There would of course need to be a > rendering description associated with > each rendering type value, but CLUE > wouldn't define those. > > & ; The idea is that an IANA registry is > created, where people can register > their rendering type values. > > Regards, > > Christer > > > > > -----Original Message----- > > > From: Christer Holmberg > [mailto:christer.holmberg@ericsson.com n.com>] > > Sent: Sunday, June 19, 2011 10:29 PM > > To: Allyn Romanow (allyn); Mary Barnes > > > Cc: clue@ietf.org>; Botzko, Stephen; > Bill Mauchly (bmauchly) > > Subject: RE: [clue] Requirement on > centralized media mixing > > > > > > Hi Allyn, > > > > I appologise that it took some time to > reply. > > > > We've been working on some > definition/example text (I sent it to the > > list just a few minutes ago), which I > hope will clarify some of the > > asked. > > > > >Also, what kind of support are you > asking for binaural? I believe > it's > > often considered as a subset of > stereo. What are you asking for? A > > simple tag that says "binaural", or > the specification > > >of a rendering system for binaural? > Precisely what are asking for? > > > > From CLUE, we are only asking for a > general mechanism to request and > > indicate different rendering types > (see definition in other e-mail). > &nbs nbsp; > > > An example of such rendering type is > binaural, BUT we are *NOT* asking > > CLUE to define any binaural specific > SDP attributes etc. If such are > > needed, we agree that it needs to be > done as a separate task. > > > > Before I try to answer your other > questions, please take a look at the > > definition/example e-mail, which I > hope will clarify what we mean by > > rendering and rendering type. > > > > Regards, > &n > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > & ; > Hi Christer - > > > > In spirit I am enthusiastic > about what you are proposing > (meaning > > good quality mobile participation). > I'm not clear on how the spirit > > becomes instantiated in our protocol, > so I have some questions below J > > > > Thanks, > > > > Allyn > > > bsp; > > > > From: clue- > bounces@ietf.org [mailto:clue- > bounces@ietf.org] On > > > Behalf Of Christer Holmberg > > Sent: Tuesday, June 14, 2011 > 7:23 AM > > > To: > clue@ietf.org > > > Subject: [clue] Requirement on > central p; > > > > > > > > > > > Hi, > > > > > > > > During the last interim meeting > (May 12th) we discussed a > > requirement proposal > > > > stating that an endpoint must be > able to > > rendering > > > > of different predefined formats, > including 3D binaural > rendering. > > > > (Link to proposal: > http://www.ietf.org/mail- > > > archive/web/clue/current/msg00179.html) > > > > > > > > The proposal was well received, > it > > should not be mandatory > > > > for the solution to implement > centralized 3D binaural rendering, > > > i.e.an endpoint should > > > > > be able to request 3D binaural > rendering, but had no guaranty > > that such rendering was > > > > supported by the system. > p; > > > > > > > It was decided to look how such > requirement could look like. > > > > > > > > When I look the -03 version of > the req draft, Requirement 2c > > states: > > > > > > > > "The solution MU f binaural > audio." > > > > > > > > I think that requirement is > unclear, and it doesn't really give > > any guidance to our work. > > > > > > > > Due to that, and also due to the > fact that rather than talking > > about specific rendering types, > > > &n bsp; I would like to propose more > general requirement text on the > > negotiation of the media mixing type, > > > > and the usage of centralized > media mixing in the first place. > > > > > > > > The mechanism would be > extendable, so new types can be added in > > future. > > > > > > > & ; > So, the proposed requirements are: > > > > > > > > REQ-x: It MUST be possible to > negotiate the usage of > > centralized media mixing. System > support of centralized media mixing > is > > optional. > > > > > > > > REQ-y: When centralized media > mixing i sp; > possible to negotiate the type of media > rendering provided for each > > media stream received by a client. > > > > --- > > > > [ar] I have a few > questions/comments: > > > > 1. The term "negotiate" > troubles me as I think it means > a > > particular form of communication that > dictates the solution. What is< nbsp; > being asked for is the > receiver to know that it is receiving > > "centralized media mixing". This may > not be the end product of a > > negotiation. The same is true of the > use of the term negotiate in the > > second requirement. What is needed is > a mechanism by which the > receiver > > may know what type of "media > rendering" is being received. > > > > So, I'd rather offer, The > solution must support a means for > > identifying a ntralized media mixing". > > > > And, When "centralized media > mixing" is used, the solution must > > support a means for identifying... > > > > > > > > 2. Also, I'm not too sure > what "media rendering", the > > phrase in the second reqmt, > represents- SDP and RTP recognize audio > > channels and recognize codecs. Is this > what is referred to as "media > & ; > rendering"? Or is it something different? > What very specifically? > > > > > > > > 3. After reading more of > the discussion, I realize that I > > don't fully understand what is meant > in the first reqmt by > "centralized > > media mixing" or "rendering", which > term is used in another email. I > > had thought you meant the usual audio > mixing such as discussed in RFC > > 5117.( stood part of the topology so > didn't > > need to be called out in particular. > But I don't mind calling it > out.) > > In any case, now I'm not sure what you > mean, maybe it is something > > other than typical MCU mixing behavior > as described in RFC 5117? > > > > > > > > 4. As for the discussion > of binaural.. here is what it > > seems like to me.. AVP, RFC 3551 > specifies the number of audio > & ; > channels, what they refer to, and types > of codecs. Binaural is > > neither. As you say, Christer, it's a > type of stereo channel. Steve > > feels that "binaural" must be > recognized in SDP, which of course, it > is > > not currently. > > > > > > > > I'm not entirely sure what needs > to be specified about binaural, > > given that it is neither channel -type > nor codec-type. What needs to > &nbs nbsp; be > > standardized? This question is > probably more for Steve, or both of > you. > > If the receiving device knows it's > getting binaural stereo, then it > can > > run some algorithms to improve quality > and if it isn't binaural, it > > won't run those algs., or something > analogous? If that is the case, I > > don't see what needs to be > standardized that isn't already > > standardized... But I'm eager to > learn. > > > p; > > > Thanks- > > > > Allyn > > > > > > > > Regards, > > > > > > > > Christer > > > > > &nbs nbsp; > > > > > _______________________________________________ > clue mailing list > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > From christer.holmberg@ericsson.com Wed Jun 22 11:15:12 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5485228024 for ; Wed, 22 Jun 2011 11:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmwteAjDSP4h for ; Wed, 22 Jun 2011 11:15:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB42228022 for ; Wed, 22 Jun 2011 11:15:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-23-4e02312d031f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 19.0B.09774.D21320E4; Wed, 22 Jun 2011 20:15:09 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 22 Jun 2011 20:15:09 +0200 From: Christer Holmberg To: Roni Even , 'Stephen Botzko' Date: Wed, 22 Jun 2011 20:15:07 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acww0Bm8VDTJV27YTXeT+ssx3eOWAQABm+GwAAXgVUAABTjWkAABM0Ig Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A7C2@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> <00f801cc30d8$2a888140$7f9983c0$%roni@huawei.com> <7F2072F1E0DE894DA4B517B93C6A05851DB559A733@ESESSCMS0356.eemea.ericsson.se> <014401cc3104$076a29d0$163e7d70$%roni@huawei.com> In-Reply-To: <014401cc3104$076a29d0$163e7d70$%roni@huawei.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 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 18:15:13 -0000 Hi Roni, > > >In XCON data model > http://tools.ietf.org/html/draft-ietf-xcon-common- > > data-model-31#section-4.2.13 there is a specification of > video layout > > control that > > >describes the continuous presence layout. There was no requirement > > >for > > something similar for audio. I assume that Christer wants to see > > something similar > > >to that definition for audio but I am not sure if there is > a use case > > for that, currently SDP RTPMAP has the encoding parameters > that allows > > the > > >specification of the number of audio channels which as far as I > > understand is sufficient for telepresence systems.< mal> > > > > > >If there is a general need to negotiate not only the number of > > channels but also a non codec specific way to negotiate > audio mixing > > parameter, I am not > > >sure this is a CLUE topic. In which case its support will > be part of > > interoperability requirement with SIP systems that do not support > > telepresence > > >extensions. > > > > We do have a requirement to interoperate with "single > stream devices" > > (that might still be CLUE aware), and then there is a need > to specify > > source selection, both for audio and video. > > > > In the most simple case, the generated stream towards the device is > > done simply by switching, but in more advanced cases there will be > > need for mixing, where source selection migth be needed for > the mixing > > algorithm. > > What you describe is not CLUE specific. It applies to > multipoint even without telepresence extension and I am not > sure what is the new requirement here. In the XCON + SIP case > the XCON data model describe the video layout for the > conference but the selection of sources to mix is done using SDP. > What I was saying that there was no requirement in the past > to describe to the MCU the mixing algorithm and if there was > one it would be done by special conference definition like > XCON for the whole conference and not in the protocol. > In your example you want specific mixing mode per participant > done by the MCU. I think that it may be needed for video > (personal layout) and if there is a use case for audio. I am > not sure it is CLUE work since it applies also to current SIP systems. Our task is to identify requirements for CLUE. Based on those requirements, we will choose existing protocol mechanisms, o= r define new ones (either ourselves, or ask some other WG to do it). Whether those protocol mechanisms can also be used for non-CLUE systems is = irrelevant. Regards, Christer > > > > Regards, > > > > Christer > > > > > > > > > > > > > > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] On > > Behalf Of Stephen Botzko > > Sent: Wednesday, June 22, 2011 2:29 PM > > To: Christer Holmberg > > Cc: clue@ietf.org > > Subject: Re: [clue] Requirement on centralized media mixing > > > > > > > > > > > > On Wed, Jun 22, 2011 at 1:24 AM, Christer Holmberg > > wrote: > > > > > > Hi Stephen lass=3DMsoNormal style=3D'margin-bottom:12.0pt'> > > >I understand you are advocating a general > mechanism, which is > > why I especially want to see use cases showing the need for the > > panned, plain, thresholded, linear, non-linear rendering types you > > >proposed. If someone has other rendering types, then they > > would be helpful too. > > > > > >For me the negotiation of "rendering type" is a > mechanism. I > > am thinking all we need is number of channels, but I am > quite willing > > to change my view if the use cases show more is needed. > > > > What do you mean by "number of channels"? > > > > In the SDP a=3Drtpmap attribute you are able to indicate the > > number of audio channels, but I don't think that helps. > > > > Setting aside binaural for now, I am envisioning that I am > > receiving three audio channels, and that CLUE mechanisms > are telling > > me &q uot; for each channel. I think that's all I need to know in > > order to render the audio properly, but I am thinking you > don't agree. > > That I would also need to know "panning" vs "plain"??? I don't > > understand what you are thinking I would do differently if I knew > > that, which is why I am wanting more use cases. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > On Tue, Jun 21, 2011 at 2:11 PM, Christer > > Holmberg wrote: > > > > > > Hi, > > > > > > >I would like to ly for non-binaural > > proposals. It seems to me that a receiver doesn't really > >care if the > > stereo it is receiving is "panned", "plain" or > "thresholded", or if it > > is linear or non-linear. So use cases >motivating those > choices would > > be helpful. > > > > > >Also, the proposal is for a > specific > > mechanism ("rendering type"). It may be premature to identify the > > mechanism >in the requirements - since often there are > multiple ways > > to achieve the desired ends. > > > > > > > > > > Again, I am not suggesting > to specify a > > specific mechanism - only a mechanism to negotiate the > rendering type > > mechanism. > > > > > > > > Yes, I am using binaural as > a rendering > > type EXAMPLE, but you are the one who keep saying that I am try ) > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > On Mon, Jun 20, 2011 at 5:47 > PM, Allyn > > Romanow (allyn) > wrote: > > > > > > Hi Christer, > > > > I think that you are proposing that > > CLUE needs a mechanism to pass > > information, such as a tag, on > > "rendering type", for example, binaural, > > threshold, etc. > > Is that correct? > > > > And that you ar from CLUE than simply > > identifying the rendering type. > > Is that correct? > > > > IF both of these statements are > > correct, than personally I think it is > > fine TO include the information of > > rendering type, such as "binaural", > > by some mechanism, such as a tag, AS > > LONG AS there is an accepted Use > > Case that shows the necessity of > > communicating the rendering type, such > > as "thresholding" or "panning". > > > > How do other people feel about this? > > > > Thanks, > > > > -----Original Message----- > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@ericsson.com > o > > n.com>] > > Sent: Monday, June 20, 2011 12:23 PM > > To: Allyn Romanow (allyn); > Mary Barnes > > > > Cc: > > clue@ietf.org; > > Botzko, Stephen; Bill Mauchly (bmauchly) > > Subject: RE: [clue] Requirement on > > centralized media mixing > > > > Hi A ; >Still > trying to get > > clarification- > > > > > >I read your description of various > > types of rendering. > > >Still trying to understand what you > > want from CLUE- > > >If we have a tag that says > "binaural" > > or stereo, sub binaural, are we > > >done? > > > > Of course we could have a binaural > > specific SDP attribute, e.g. > > a=3Dbinaural. > > > > But, again, what we are > proposing is a > > general mechanism, that could > > look something like: > > > > > > could then e.g. be > "binaural", > > but it could also be something > > else (we showed a few > example in the e- > > mail). > > > > >Or do you want CLUE to > describe how to > > do some kind of rendering? To > > say > > >something more about specific > > rendering functions? > > > > No, CLUE doesn't need to say > anything > > about that. > > > > There would of course need to be a > > rendering description associated with > > each rendering type value, but CLUE > > wouldn't define those. > > > > & ; The idea is that an IANA registry is > > created, where people can register > > their rendering type values. > > > > Regards, > > > > Christer > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@ericsson.com > o > > n.com>] > > > Sent: Sunday, June 19, > 2011 10:29 PM > > > To: Allyn Romanow (allyn); Mary > > Barnes > > > > > Cc: clue@ietf.org>; > Botzko, Stephen; > > Bill Mauchly (bmauchly) > > > Subject: RE: [clue] Requirement on > > centralized media mixing > > > > > > > > > Hi Allyn, > > > > > > I appologise that it took > some time > > to reply. > > > > > > We've been working on some > > definition/example text (I sent it to the > > > list just a few minutes > ago), which I > > hope will clarify some of the > > > asked. > > > > > > >Also, what kind of > support are you > > asking for binaural? I believe > > it's > > > often considered as a subset of > > stereo. What are you asking for? A > > > simple tag that says > "binaural", or > > the specification > > > >of a rendering system for > binaural? > > Precisely what are asking for? > > > > > > From CLUE, we are only > asking for a > > general mechanism to request and > > > indicate different rendering types > > (see definition in other e-mail). > > &nbs nbsp; > > > > An example of such > rendering type is > > binaural, BUT we are *NOT* asking > > > CLUE to define any > binaural specific > > SDP attributes etc. If such are > > > needed, we agree that it > needs to be > > done as a separate task. > > > > > > Before I try to answer your other > > questions, please take a look at the > > > definition/example e-mail, which I > > hope will clarify what we mean by > > > rendering and rendering type. > > > > > > Regards, > > &n > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > & ; > Hi Christer - > > > > > > In spirit I am enthusiastic > > about what you are proposing > > (meaning > > > good quality mobile participation). > > I'm not clear on how the spirit > > > becomes instantiated in > our protocol, > > so I have some questions below J > > > > > > Thanks, > > > > > > Allyn > > > > > bsp; > > > > > > From: clue- > > bounces@ietf.org [mailto:clue- > > bounces@ietf.org] On > > > > > Behalf Of Christer Holmberg > > > Sent: Tuesday, June 14, 2011 > > 7:23 AM > > > > > To: > > clue@ietf.org > > > > > Subject: [clue] > Requirement on > > central p; > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > During the last > interim meeting > > (May 12th) we discussed a > > > requirement proposal > > > > > > stating that an > endpoint must be > > able to > > rendering > > > > > > of different > predefined formats, > > including 3D binaural > > rendering. > > > > > > (Link to proposal: > > http://www.ietf.org/mail- > > > > > archive/web/clue/current/msg00179.html) > > > > > > > > > > > > The proposal was > well received, > > it > > > should not be mandatory > > > > > > for the solution to implement > > centralized 3D binaural rendering, > > > > > i.e.an > endpoint should > > > > > > > > be able to request > 3D binaural > > rendering, but had no guaranty > > > that such rendering was > > > > > > supported by the system. > > p; > > > > > > > > > > It was decided to > look how such > > requirement could look like. > > > > > > > > > > > > When I look the -03 > version of > > the req draft, Requirement 2c > > > states: > > > > > > > > > > > > "The solution MU > f binaural > > audio." > > > > > > > > > > > > I think that requirement is > > unclear, and it doesn't really give > > > any guidance to our work. > > > > > > > > > > > > Due to that, and > also due to the > > fact that rather than talking > > > about specific rendering types, > > > > > &n bsp; I would like to propose more > > general requirement text on the > > > negotiation of the media > mixing type, > > > > > > and the usage of centralized > > media mixing in the first place. > > > > > > > > > > > > The mechanism would be > > extendable, so new types can be added in > > > future. > > > > > > > > > > > & ; > So, the proposed > requirements are: > > > > > > > > > > > > REQ-x: It MUST be > possible to > > negotiate the usage of > > > centralized media mixing. System > > support of centralized media mixing > > is > > > optional. > > > > > > > > > > > > REQ-y: When > centralized media > > mixing i sp; > possible to negotiate the type of media > > rendering provided for each > > > media stream received by a client. > > > > > > --- > > > > > > [ar] I have a few > > questions/comments: > > > > > > 1. The term > "negotiate" > > troubles me as I think it means > > a > > > particular form of > communication that > > dictates the solution. What is< nbsp; > being asked > for is the > > receiver to know that it is receiving > > > "centralized media > mixing". This may > > not be the end product of a > > > negotiation. The same is > true of the > > use of the term negotiate in the > > > second requirement. What > is needed is > > a mechanism by which the > > receiver > > > may know what type of "media > > rendering" is being received. > > > > > > So, I'd rather > offer, The > > solution must support a means for > > > identifying a ntralized > media mixing". > > > > > > And, When "centralized media > > mixing" is used, the solution must > > > support a means for identifying... > > > > > > > > > > > > 2. Also, I'm > not too sure > > what "media rendering", the > > > phrase in the second reqmt, > > represents- SDP and RTP recognize audio > > > channels and recognize codecs. Is > > this what is referred to as "media > > & ; > rendering"? Or is it something > different? > > What very specifically? > > > > > > > > > > > > 3. After > reading more of > > the discussion, I realize that I > > > don't fully understand > what is meant > > in the first reqmt by > > "centralized > > > media mixing" or > "rendering", which > > term is used in another email. I > > > had thought you meant the > usual audio > > mixing such as discussed in RFC > > > 5117.( stood part of the > topology so > > didn't > > > need to be called out in > particular. > > But I don't mind calling it > > out.) > > > In any case, now I'm not sure what > > you mean, maybe it is something > > > other than typical MCU mixing > > behavior as described in RFC 5117? > > > > > > > > > > > > 4. As for the > discussion > > of binaural.. here is what it > > > seems like to me.. AVP, RFC 3551 > > specifies the number of audio > > & ; > channels, what they refer to, > and types > > of codecs. Binaural is > > > neither. As you say, > Christer, it's a > > type of stereo channel. Steve > > > feels that "binaural" must be > > recognized in SDP, which of course, it > > is > > > not currently. > > > > > > > > > > > > I'm not entirely > sure what needs > > to be specified about binaural, > > > given that it is neither channel > > -type nor codec-type. What needs to > > &nbs nbsp; be > > > standardized? This question is > > probably more for Steve, or both of > > you. > > > If the receiving device knows it's > > getting binaural stereo, then it > > can > > > run some algorithms to improve > > quality and if it isn't binaural, it > > > won't run those algs., or > something > > analogous? If that is the case, I > > > don't see what needs to be > > standardized that isn't already > > > standardized... But I'm eager to > > learn. > > > > > p; > > > > Thanks- > > > > > > Allyn > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > &nbs nbsp; > > > > > > > > _______________________________________________ > > clue mailing list > > > > clue@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > > > > From christer.holmberg@ericsson.com Wed Jun 22 11:17:40 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94E711E80B0 for ; Wed, 22 Jun 2011 11:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIcEorH5WWDx for ; Wed, 22 Jun 2011 11:17:39 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C1F0211E8099 for ; Wed, 22 Jun 2011 11:17:38 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f7-4e0231c12d7b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B2.99.20773.1C1320E4; Wed, 22 Jun 2011 20:17:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 22 Jun 2011 20:17:37 +0200 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , Stephen Botzko Date: Wed, 22 Jun 2011 20:17:36 +0200 Thread-Topic: [clue] Layout negotiation Thread-Index: Acww8sQlRUBW5WOSS4K6jxoq1LlJrwABhLoAAAEsT+AAAr/SYA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A7C3@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A79A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 18:17:40 -0000 Hi,=20 > > >>>I think I was the one that brought up layouts originally. I was=20 > > >>>more concerned with video layouts than audio layouts. > > >>>Currently, the requirements draft seems to focus more on audio=20 > > >>>layout/spatial audio. > > >>>Requirements 3 and 16 both deal with parts of this. I feel there=20 > > >>>needs to be more clear requirements on the ability for the to=20 > > >>>represent the potential layouts of the audio/video can that be=20 > > >>>offered. For example, I have 3 camera and 3 mics. I can provide: > > >>>1) 3 individual video each with corresponding audio > > >>>2) 1 active speaker only switched video with mixed audio > > >>>3) 1 composed video including active speaker and 'n' > > >>>non-active speakers (where 'n' is may be all or some fixed > > >>>limit) and mixed audio > > >> > > >> > > >>>>I actually think that your examples, as written, are different=20 > > >>>>RENDERING TYPES, because they only > > talk about mixing and composition. > > >> > > >>>Confirmation that I am clueless about rendering types. > > > > > > > > >>A value identifying the rendering algorithm used to=20 > produce a media stream sent towards the client. > >=20 > > >In a client-to-client call this is backwards. "Capture" describes=20 > > >the stream production process > > better, rendering is that the client does with the > > >streams it receives. Anyway, changing "Rendering type" to=20 > "rendering algorithm" doesn't help me much. > >=20 > > It's probably easier to understand rendering type if one=20 > knows what we mean by render. > >=20 > > Our proposed definition is: > >=20 > > "Rendering:=A0=A0 Composing a media signal from one or more=20 > media signals=20 > > using a specific composition algorithm, often according to=20 > a specific spatial model/layout." > >=20 > > So, the "rendering type" is a value associated with that algorithm. > >=20 > > So, I think the important thing in our "rendering"=20 > definition is that=20 > > an output media signal is generated. > >=20 > > Now, if people think that our usage of "rendering" is confusing, we=20 > > can of course use other wording instead. >=20 > This works for me. It may be useful to expand with typical=20 > audio and video examples, such as mixing multiple audio=20 > stream inputs into a single audio stream output, or composing=20 > multiple video stream inputs into a single video stream output. I did try to provide some examples in the "Definition and examples" e-mail. Regards, Christer > > >>>In my opinion, a LAYOUT TYPE is a description of how=20 > sources are placed in a virtual room. > > >>> > > >>>For me layout is about composition. Layouts do not necessarily=20 > > >>>create a virtual room experience, > > particularly in multipoint calls. > > >> > > >> > > >>Ok, so we need to make sure we have a common=20 > understanding of layout=20 > > >>then :) > > >> > > >>So, just to clarify, do you think that source selection is layout? > > > > > > > > >I generally separate them, though they are related. For=20 > instance, in=20 > > >a traditional Video MCU you can > > often choose a source-independent layout (2x2 array > > >of equal size windows, a 1+5 layout, where the "1" window=20 > is bigger=20 > > >than the others, and at the top > > left, etc). Then you can control the mapping of > > >sources to windows separately. Not sure this is the only way to=20 > > >partition it, just the way I tend to > > use. > >=20 > > Ok. So, first, I guess there is "source-dependent layout"=20 > and "source-independent layout". > >=20 > > Second, there is an algorithm that creates the output=20 > stream, using the layout as input. > >=20 > > Of course, in this case one might not need to be able to explicitly=20 > > indicate the algorithm - if it's enough to indicate the layout. > >=20 > >=20 > >=20 > >=20 > > >I see four distinct elements in your mobile binaural case=20 > - (a) the=20 > > >sources chosen for placement, > >=20 > > Correct. That's "source selection". > >=20 > > >(b) the set of placements used in creating a sound stage, > > > > > >(c) the placement used for each particular source at the=20 > moment, and=20 > > >(d) whether the outbound audio is binaural or not. > > >I'd personally call (b) the audio layout, though you can=20 > equally well call (b+c) the audio layout. > >=20 > > Ok. So, that would be a "source-dependent layout", I guess? > >=20 > > Then, (d) would be the actual rendering algorithm, using=20 > the layout as input. > >=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > >If the receiving endpoint wants=20 > to control the layout itself, > > >it goes with option 1. If it has limited > > >resources/bandwidth/screens/etc=20 > it may prefer option 2 or 3. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf > > > Of Christer Holmberg > > > > Sent: Tuesday, June 21, 2011 3:52 AM > > > > To: clue@ietf.org > > > > Subject: [clue] Layout negotiation > > > > > > > > Hi, > > > > > > > > A while ago there were some=20 > discussions about having requirements to > > > negotiate the layout type, and at > > > > least according to Stephen B=20 > it was within the scope of the work. > > > > > > > > "The ability to=20 > negotiate an audio or video layout > > > is clearly > > > within scope, and has general > > > > value it the group wants to=20 > take it on. > > > > For instance, if you=20 > combine video switching of multiple > > > sources with audio > > > > mixing/transcoding, then the=20 > receiver is responsible > > > > for the video layout=20 > but has no control over the > > > audio layout. > > > In that case, there are > > > > advantages to allowing the=20 > receiver to tell the > > > > central audio mixer=20 > where it wants the sources placed on the > > > sound stage. I have no objection > > > > in principle to adding that kind of > > > > negotiation to the=20 > requirements, though I think the group > > > should consider the impact on the > > > > schedule." > > > > > > > > However, I haven't seen any=20 > input after that. > > > > > > > > My idea would be that it is=20 > very similar to the rendering type: CLUE > > > defines a mechanism to negotiate > > > > the layout type, but doesn't=20 > define specific types (instead an IANA > > > registry would be created for > > > > that). So, I don't think it=20 > would have any significant impact on our > > > schedule. > > > > > > > > Whether it, in addition to=20 > negotiation a layout type (which > > > specifies > > > the source locations), should be > > > > possible for the user to=20 > more explicit place individual sources, as > > > mentioned by Stephen, can be > > > > discussed. However, that=20 > would probably require a little > > > more work, so > > > at least I would be happy with > > > > a simple layout type=20 > negotiation at this point. > > > > > > > > So, would people be ok with=20 > such requirement? > > > > > > > > (Another alternative would=20 > be to "embed" the layout type into the > > > rendering type, but I think that > > > > would be very clumsy.=20 > Because, in that case you would need to define > > > mulitple types for the same > > > > rendering, but with=20 > different layouts.) > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > =20 _______________________________________________ > > clue mailing list > > clue@ietf.org > > =20 https://www.ietf.org/mailman/listinfo/clue > >=20 > >=20 > >=20 > >=20 > >=20 >=20 > = From christer.holmberg@ericsson.com Wed Jun 22 11:25:17 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E76911E80BA for ; Wed, 22 Jun 2011 11:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jmBoseaRpoE for ; Wed, 22 Jun 2011 11:25:16 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBCB11E8082 for ; Wed, 22 Jun 2011 11:25:15 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-8b-4e02338a70c0 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3D.3C.09774.A83320E4; Wed, 22 Jun 2011 20:25:14 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 22 Jun 2011 20:25:14 +0200 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , "Paul Kyzivat (pkyzivat)" , "clue@ietf.org" Date: Wed, 22 Jun 2011 20:25:12 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acww6/a8YwI9ZRvfTRa6g67VzrDRzQAEySlAAAJoRUA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A7C4@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A548@ESESSCMS0356.eemea.ericsson.se> <4E020184.1040806@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 18:25:17 -0000 Hi Charles,=20 > > >>>> I understand you are advocating a general mechanism,=20 > which is why > I especially want to see use > > cases showing > > >>>> the need for the panned, plain, thresholded, linear, non-linear > rendering types you > > >>>> proposed. If someone has other rendering types, then they would > be helpful too. > > >>> > > >>>> For me the negotiation of "rendering type" is a=20 > mechanism. I am > thinking all we need is number > > of channels, but I am quite willing to change my view if=20 > the use cases > show more is needed. > > >>> > > >>> What do you mean by "number of channels"? > > >>> > > >>> In the SDP a=3Drtpmap attribute you are able to indicate=20 > the number > of audio channels, > > >>> but I don't think that helps. > > >> > > >> Setting aside binaural for now, I am envisioning that I am > receiving three audio channels, and that > > >> CLUE mechanisms are telling me "left, center, right" for each > channel. I think that's all I need > > to > > >> know in order to render the audio properly, but I am thinking you > don't agree. > > > > > > It depends on WHO is rendering. > > > > > > An entity receiving all "raw material" can of course do=20 > whatever it > wants with it. But, in the > > centralized rendering case the idea is that the rendering is done on > behalf of a client, since the > > client due to different reasons can't do it itself. > >=20 > > There is a distinction here between describing "what you have" or > "what > > you want". > >=20 > > AFAIK the intent right now is that what is described is=20 > "what I have",=20 > > and "what I can provide". E.g. > >=20 > > - I have some microphones, speakers, cameras, displays in a=20 > particular=20 > > arrangement >=20 > Let me refer to this as the raw inputs. >=20 > >=20 > > - I can provide some selection of media streams having=20 > content, either=20 > > renditions of particular cameras, microphones, etc. or specific=20 > > combinations of those. >=20 > Exactly, and I can provide multiple different combinations of=20 > the raw inputs. This may include, for example: > (a) all the raw inputs > (b) some subset of the raw inputs > (c) some composition of the raw inputs >=20 > The end device may choose to receive (a) or (b) or (c) or=20 > perhaps even (a)+(c), etc. A single-stream device would choose to receive (c). >As for the requirements for CLUE, it is not clear to me that=20 >this is covered currently. I would like to see that it is added. Me too. And, based on the discussions, my understanding is that (a),(b) and= (c) are layout options (either source-dependent or source-independent).=20 >As for how to do it, SDPCapNeg and the SDP grouping=20 >frameworks provide tools that may help. We may choose to=20 >leverage these or not, but I agree that is not in scope for=20 >the requirements. I don't think that would help, because it doesn't describe the "raw input c= ombinations" of the media streams. Regards, Christer From christer.holmberg@ericsson.com Wed Jun 22 11:32:55 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8024811E80E6 for ; Wed, 22 Jun 2011 11:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.271 X-Spam-Level: X-Spam-Status: No, score=-5.271 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDoArZvUgucV for ; Wed, 22 Jun 2011 11:32:53 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 07E2E11E80C7 for ; Wed, 22 Jun 2011 11:32:52 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-a3-4e023554fb7c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BE.FC.09774.455320E4; Wed, 22 Jun 2011 20:32:52 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 22 Jun 2011 20:32:51 +0200 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Date: Wed, 22 Jun 2011 20:32:49 +0200 Thread-Topic: [clue] Requirement on centralized media mixing Thread-Index: Acww6+5GR4A34umoS5Og6Ats6w1vIwAHdTgw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A7C5@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04AF1406@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB53FF29C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB53370D7@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A548@ESESSCMS0356.eemea.ericsson.se> <4E020184.1040806@cisco.com> In-Reply-To: <4E020184.1040806@cisco.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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Requirement on centralized media mixing X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 18:32:55 -0000 Hi Paul, >>>>> I understand you are advocating a general mechanism, >>>>> which is why I especially want to see use cases showing the need for >>>>> the panned, plain, thresholded, linear, non-linear rendering types >>>>> you proposed. If someone has other rendering types, then they >>>>> would be helpful too. >>>>> >>>>> For me the negotiation of "rendering type" is a >>>>> mechanism. I am thinking all we need is number of channels, >>>>> but I am quite willing to change my view if the use cases >>>>> show more is needed. >>>> >>>> What do you mean by "number of channels"? >>>> >>>> In the SDP a=3Drtpmap attribute you are able to indicate >>>> the number of >>>> audio channels, but I don't think that helps. >>> >>> Setting aside binaural for now, I am envisioning that I am >>> receiving >>> three audio channels, and that CLUE mechanisms are telling >>> me "left, center, right" for each channel. I think that's all I >>> need to know in order to render the audio properly, but I am >>> thinking you don't agree. >> >> It depends on WHO is rendering. >> >> An entity receiving all "raw material" can of course do >> whatever it wants with it. But, in the centralized rendering >> case the idea is that the rendering is done on behalf of a >> client, since the client due to different reasons can't do it itself. > > There is a distinction here between describing "what you > have" or "what you want". > > AFAIK the intent right now is that what is described is "what > I have", and "what I can provide". E.g. > > - I have some microphones, speakers, cameras, displays in a > particular arrangement > > - I can provide some selection of media streams having > content, either renditions of particular cameras, > microphones, etc. or specific combinations of those. > > It seems to me that binaural can fit into this model. The > room configuration suitable to receive binaural involves "speakers" > (headphones) arranged in a particular way. I guess that then > there would need be a way to specify that a media stream that > a room can provide is encoded as a binaural "mix" of a > particular set of microphones on the source side. The room doesn't need to provide binaural media. >It isn't in principle necessary to "ask" for binaural. Rather >what is being done is "offer" binaural. But the actual >mechanism for doing that seems independent of CLUE. I am not sure I am following. A client needs to indicate that it is willing to receive a binaural audio s= tream, and the MCU, when sending the stream, needs to indicate that it is b= inaural. Regards, Christer > > Thanks, > Paul > > >> That I would also need to know "panning" vs "plain"??? I > don't understand what you are thinking I would do differently > if I knew that, which is why I am wanting more use cases. > > > > Maybe there is no need to separate "panning" vs "plain". I > will need to look into that (there for sure is a need to > separate binaural from other stereo, though). > > > > Other use-cases is which video and/or audio streams are > sent towards a client in the first place. E.g. Sending the > video of the most active speaker, sending the audio of the 4 > most active speakers, etc. I consider that being different > rendering types also, because they affect how the output > stream is generated. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > Hi, > > > > > > >I would like to see use > cases, particularly for non-binaural proposals. It seems to > me that a receiver doesn't really>care if the stereo it is > receiving is "panned", "plain" or "thresholded", or if it is > linear or non-linear. So use cases>motivating those choices > would be helpful. > > > > > >Also, the proposal is for > a specific mechanism ("rendering type"). It may be premature > to identify the mechanism>in the requirements - since often > there are multiple ways to achieve the desired ends. > > > > > > > > > > Again, I am not suggesting > to specify a specific mechanism - only a mechanism to > negotiate the rendering type mechanism. > > > > > > > > Yes, I am using binaural as a > > rendering type EXAMPLE, but you are the one who keep saying > that I am > > trying to specify binaural :) > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > On Mon, Jun 20, 2011 at > 5:47 PM, Allyn Romanow > (allyn)> wrote: > > > > > > Hi Christer, > > > > I think that you are > proposing that CLUE needs a mechanism to pass > > information, such as a tag, > on "rendering type", for example, binaural, > > threshold, etc. > > Is that correct? > > > > And that you are not asking > for any more from CLUE than simply > > identifying the rendering type. > > Is that correct? > > > > IF both of these statements > are correct, than personally I think it is > > fine TO include the > information of rendering type, such as "binaural", > > by some mechanism, such as > a tag, AS LONG AS there is an accepted Use > > Case that shows the > necessity of communicating the rendering type, such > > as "thresholding" or "panning". > > > > How do other people feel about this? > > > > Thanks, > > Allyn > > > > -----Original Message----- > > > > From: Christer Holmberg > [mailto:christer.holmberg@ericsson.com g@ericsson.com>] > > Sent: Monday, June 20, 2011 12:23 PM > > To: Allyn Romanow (allyn); > Mary Barnes > > > > Cc: > clue@ietf.org; Botzko, Stephen; Bill > Mauchly (bmauchly) > > Subject: RE: [clue] Requirement on > > centralized media mixing > > > > Hi Allyn, > > > > >Still trying to get clarification- > > > > > >I read your description of > various types of rendering. > > >Still trying to understand > what you want from CLUE- > > >If we have a tag that says > "binaural" or stereo, sub binaural, are we > > >done? > > > > Of course we could have a > binaural specific SDP attribute, e.g. > > a=3Dbinaural. > > > > But, again, what we are > proposing is a general mechanism, that could > > look something like: > > > > a=3Drendering-type =3D > > > > could then e.g. be > "binaural", but it could also be something > > else (we showed a few > example in the e-mail). > > > > >Or do you want CLUE to > describe how to do some kind of rendering? To > > say > > >something more about > specific rendering functions? > > > > No, CLUE doesn't need to > say anything about that. > > > > There would of course need > to be a rendering description associated with > > each rendering type value, > but CLUE wouldn't define those. > > > > The idea is that an IANA > registry is created, where people can register > > their rendering type values. > > > > Regards, > > > > Christer > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > [mailto:christer.holmberg@ericsson.com g@ericsson.com>] > > > Sent: Sunday, June 19, > 2011 10:29 PM > > > To: Allyn Romanow (allyn); Mary > > Barnes > > > > > Cc: > clue@ietf.org; Botzko, Stephen; Bill > Mauchly (bmauchly) > > > Subject: RE: [clue] > Requirement on centralized media mixing > > > > > > > > > Hi Allyn, > > > > > > I appologise that it > took some time to reply. > > > > > > We've been working on > some definition/example text (I sent it to the > > > list just a few minutes > ago), which I hope will clarify some of the > > > questions that have been asked. > > > > > > >Also, what kind of > support are you asking for binaural? I believe > > it's > > > often considered as a > subset of stereo. What are you asking for? A > > > simple tag that says > "binaural", or the specification > > > >of a rendering system > for binaural? Precisely what are asking for? > > > > > > From CLUE, we are only > asking for a general mechanism to request and > > > indicate different > rendering types (see definition in other e-mail). > > > > > > An example of such > rendering type is binaural, BUT we are *NOT* asking > > > CLUE to define any > binaural specific SDP attributes etc. If such are > > > needed, we agree that it > needs to be done as a separate task. > > > > > > Before I try to answer > your other questions, please take a look at the > > > definition/example > e-mail, which I hope will clarify what we mean by > > > rendering and rendering type. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Christer - > > > > > > In spirit I am > enthusiastic about what you are proposing > > (meaning > > > good quality mobile > participation). I'm not clear on how the spirit > > > becomes instantiated in > our protocol, so I have some questions below J > > > > > > Thanks, > > > > > > Allyn > > > > > > > > > > > > > > From: > clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] On > > > > > Behalf Of Christer Holmberg > > > Sent: Tuesday, > June 14, 2011 7:23 AM > > > > > To: > clue@ietf.org > > > > > Subject: [clue] > Requirement on centralized media mixing > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > During the last > interim meeting (May 12th) we discussed a > > > requirement proposal > > > > > > stating that an > endpoint must be able to request central audio > > > rendering > > > > > > of different > predefined formats, including 3D binaural > > rendering. > > > > > > (Link to proposal: > http://www.ietf.org/mail- > > > > archive/web/clue/current/msg00179.html) > > > > > > > > > > > > The proposal was > well received, with the reservation that it > > > should not be mandatory > > > > > > for the solution > to implement centralized 3D binaural rendering, > > > > > i.e.an endpoint > > should > > > > > > > > be able to request > 3D binaural rendering, but had no guaranty > > > that such rendering was > > > > > > supported by the system. > > > > > > > > > > > > It was decided to > look how such requirement could look like. > > > > > > > > > > > > When I look the > -03 version of the req draft, Requirement 2c > > > states: > > > > > > > > > > > > "The solution > MUST NOT preclude the use of binaural audio." > > > > > > > > > > > > I think that > requirement is unclear, and it doesn't really give > > > any guidance to our work. > > > > > > > > > > > > Due to that, and > also due to the fact that rather than talking > > > about specific rendering types, > > > > > > I would like to > propose more general requirement text on the > > > negotiation of the media > mixing type, > > > > > > and the usage of > centralized media mixing in the first place. > > > > > > > > > > > > The mechanism > would be extendable, so new types can be added in > > > future. > > > > > > > > > > > > So, the proposed > requirements are: > > > > > > > > > > > > REQ-x: It MUST > be possible to negotiate the usage of > > > centralized media > mixing. System support of centralized media mixing > > is > > > optional. > > > > > > > > > > > > REQ-y: When > centralized media mixing is used, it MUST be > > > possible to negotiate > the type of media rendering provided for each > > > media stream received by > a client. > > > > > > --- > > > > > > [ar] I have a few > questions/comments: > > > > > > 1. The > term "negotiate" troubles me as I think it means > > a > > > particular form of > communication that dictates the solution. What is > > > being asked for is the > receiver to know that it is receiving > > > "centralized media > mixing". This may not be the end product of a > > > negotiation. The same is > true of the use of the term negotiate in the > > > second requirement. What > is needed is a mechanism by which the > > receiver > > > may know what type of > "media rendering" is being received. > > > > > > So, I'd > rather offer, The solution must support a means for > > > identifying a stream > which is "centralized media mixing". > > > > > > And, When > "centralized media mixing" is used, the solution must > > > support a means for > identifying... > > > > > > > > > > > > 2. Also, > I'm not too sure what "media rendering", the > > > phrase in the second > reqmt, represents- SDP and RTP recognize audio > > > channels and recognize > codecs. Is this what is referred to as "media > > > rendering"? Or is it > something different? What very specifically? > > > > > > > > > > > > 3. After > reading more of the discussion, I realize that I > > > don't fully understand > what is meant in the first reqmt by > > "centralized > > > media mixing" or > "rendering", which term is used in another email. I > > > had thought you meant > the usual audio mixing such as discussed in RFC > > > 5117.( I figured it was > an understood part of the topology so didn't > > > need to be called out > in particular. But I don't mind calling it > > out.) > > > In any case, now I'm not > sure what you mean, maybe it is something > > > other than typical MCU > mixing behavior as described in RFC 5117? > > > > > > > > > > > > 4. As for > the discussion of binaural.. here is what it > > > seems like to me.. AVP, > RFC 3551 specifies the number of audio > > > channels, what they > refer to, and types of codecs. Binaural is > > > neither. As you say, > Christer, it's a type of stereo channel. Steve > > > feels that "binaural" > must be recognized in SDP, which of course, it > > is > > > not currently. > > > > > > > > > > > > I'm not entirely > sure what needs to be specified about binaural, > > > given that it is neither > channel -type nor codec-type. What needs to > > be > > > standardized? This > question is probably more for Steve, or both of > > you. > > > If the receiving device > knows it's getting binaural stereo, then it > > can > > > run some algorithms to > improve quality and if it isn't binaural, it > > > won't run those algs., > or something analogous? If that is the case, I > > > don't see what needs to > be standardized that isn't already > > > standardized... But I'm > eager to learn. > > > > > > > > > > > > Thanks- > > > > > > Allyn > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > _______________________________________________ > > clue mailing list > > > > clue@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Wed Jun 22 11:36:35 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671D311E80AC for ; Wed, 22 Jun 2011 11:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXtlhB4BM50P for ; Wed, 22 Jun 2011 11:36:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2208F11E809C for ; Wed, 22 Jun 2011 11:36:33 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-cf-4e023631be8c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B4.6D.09774.136320E4; Wed, 22 Jun 2011 20:36:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 22 Jun 2011 20:36:33 +0200 From: Christer Holmberg To: "Espen Berger (espeberg)" , Stephen Botzko Date: Wed, 22 Jun 2011 20:36:31 +0200 Thread-Topic: [clue] Layout negotiation Thread-Index: Acww6uD+TdzXSqNlTCu/bY/VZBH7CAABAFswAALtWMAABBOsIA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A7C6@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se> <92DF9533227FC14F946C7321074B8C9E71BA82@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E71BA82@XMB-AMS-214.cisco.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 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 18:36:35 -0000 Hi,=20 >The CLUE definition document talks about both source=20 >selection, rendering and layouts.=20 >=20 >Using the terms from that document I do not see source=20 >selection as a part of layout, but they are used together to=20 >create a good user experience.=20 Yes. And, the idea is that the rendering algorithm could use the source selectio= n and layout as input when producing the output stream. Of course, source selection might not be needed for all algorithms. Regards, Christer > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of Christer Holmberg > Sent: 22. juni 2011 17:17 > To: Stephen Botzko > Cc: clue@ietf.org > Subject: Re: [clue] Layout negotiation >=20 >=20 > Hi,=20 > =09 > >>I think I was the one that brought up layouts originally. I=20 > was more=20 > >>concerned with video layouts than audio layouts. > >>Currently, the requirements draft seems to focus more on audio=20 > >>layout/spatial audio. > >>Requirements 3 and 16 both deal with parts of this. I feel=20 > there needs=20 > >>to be more clear requirements on the ability for the to=20 > represent the=20 > >>potential layouts of the audio/video can that be offered.=20 > For example,=20 > >>I have 3 camera and 3 mics. I can provide: > >>1) 3 individual video each with corresponding audio > >>2) 1 active speaker only switched video with mixed audio > >>3) 1 composed video including active speaker and 'n' > >>non-active speakers (where 'n' is may be all or some fixed > >>limit) and mixed audio > > =09 > > =09 > >I actually think that your examples, as written, are different > RENDERING TYPES, because they only talk about mixing and composition. > > =09 > >Confirmation that I am clueless about rendering types.=20 >=20 > A value identifying the rendering algorithm used to produce a=20 > media stream sent towards the client. > =09 > >>In my opinion, a LAYOUT TYPE is a description of how sources are > placed in a virtual room. > >> =09 > >For me layout is about composition. Layouts do not=20 > necessarily create a > virtual room experience, particularly in multipoint calls.=20 >=20 > Ok, so we need to make sure we have a common understanding of=20 > layout then :) >=20 > So, just to clarify, do you think that source selection is layout? > =09 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =09 >=20 >=20 >=20 > >If the receiving endpoint wants to control the=20 > layout itself, > >it goes with option 1. If it has limited > >resources/bandwidth/screens/etc it may prefer=20 > option 2 or 3. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] On Behalf > > Of Christer Holmberg > > > Sent: Tuesday, June 21, 2011 3:52 AM > > > To: clue@ietf.org > > > Subject: [clue] Layout negotiation > > > > > > Hi, > > > > > > A while ago there were some discussions=20 > about having requirements to > > negotiate the layout type, and at > > > least according to Stephen B it was within=20 > the scope of the work. > > > > > > "The ability to negotiate an audio or video > layout > > is clearly > > within scope, and has general > > > value it the group wants to take it on. > > > For instance, if you combine video switching > of multiple > > sources with audio > > > mixing/transcoding, then the receiver is responsible > > > for the video layout but has no control over > the > > audio layout. > > In that case, there are > > > advantages to allowing the receiver to tell the > > > central audio mixer where it wants the > sources placed on the > > sound stage. I have no objection > > > in principle to adding that kind of > > > negotiation to the requirements, though I > think the group > > should consider the impact on the > > > schedule." > > > > > > However, I haven't seen any input after that. > > > > > > My idea would be that it is very similar to=20 > the rendering type: CLUE > > defines a mechanism to negotiate > > > the layout type, but doesn't define=20 > specific types (instead an IANA > > registry would be created for > > > that). So, I don't think it would have any=20 > significant impact on our > > schedule. > > > > > > Whether it, in addition to negotiation a=20 > layout type (which > > specifies > > the source locations), should be > > > possible for the user to more explicit=20 > place individual sources, as > > mentioned by Stephen, can be > > > discussed. However, that would probably=20 > require a little > > more work, so > > at least I would be happy with > > > a simple layout type negotiation at this point. > > > > > > So, would people be ok with such requirement? > > > > > > (Another alternative would be to "embed"=20 > the layout type into the > > rendering type, but I think that > > > would be very clumsy. Because, in that case=20 > you would need to define > > mulitple types for the same > > > rendering, but with different layouts.) > > > > > > Regards, > > > > > > Christer > > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > =09 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > = From stephen.botzko@gmail.com Wed Jun 22 11:55:47 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1935A11E80AE for ; Wed, 22 Jun 2011 11:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THGIRNcn1tZy for ; Wed, 22 Jun 2011 11:55:45 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8222811E807E for ; Wed, 22 Jun 2011 11:55:45 -0700 (PDT) Received: by vws12 with SMTP id 12so1127032vws.31 for ; Wed, 22 Jun 2011 11:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i35R78TG/GCtsTkX/8iwBaLyx+ROjkWU1scCl+wiX3A=; b=lJGP4SxUgM5h0jsWkg+xdxwz4vbTgwnnFcxZs4OPm1UEtZLbOW8BcznD4FPlnyrXGx MgelnjWNXOcESdbgn3WmxV0O5yJ+s+dpbXhOh6e7kesBAH1UPUv3EZPbkokA7VzK6bCv JgE0ZyKMkKN8O42BxFm+kOvF1bOHomlJUBKkA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wzX/SY9iz6vEJJ88Hw9gEczd08KJn/qGKIT8eQY60s39lbZTCQ4dBsiT23sNLkjxO/ 6FTFTFSUJQK86/m7ss078BN4Gv/q1+SPyJqzChWyeBiwclO2QotBLJ+5Rqj686zPqu8R 6vXZfZ47NqdYPawhZFVPTt1bNnXx9yE6U7DEw= MIME-Version: 1.0 Received: by 10.52.66.206 with SMTP id h14mr1517231vdt.40.1308768944563; Wed, 22 Jun 2011 11:55:44 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Wed, 22 Jun 2011 11:55:44 -0700 (PDT) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB559A79A@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 22 Jun 2011 14:55:44 -0400 Message-ID: From: Stephen Botzko To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=20cf307cfd8208a50c04a65184aa Cc: clue@ietf.org Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 18:55:47 -0000 --20cf307cfd8208a50c04a65184aa Content-Type: text/plain; charset=ISO-8859-1 I'm not sure yet that we need any requirements on creating a general mechanism just yet, but that we should continue to develop the use cases. Stephen B. On Wed, Jun 22, 2011 at 1:03 PM, Charles Eckel (eckelcu) wrote: > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Wednesday, June 22, 2011 9:46 AM > > To: Stephen Botzko > > Cc: Charles Eckel (eckelcu); clue@ietf.org > > Subject: RE: [clue] Layout negotiation > > > > > > Hi, > > > > >>>I think I was the one that brought up layouts originally. I > > >>>was more concerned with video layouts than audio layouts. > > >>>Currently, the requirements draft seems to focus more on > > >>>audio layout/spatial audio. > > >>>Requirements 3 and 16 both deal with parts of this. I feel > > >>>there needs to be more clear requirements on the ability for > > >>>the to represent the potential layouts of the audio/video can > > >>>that be offered. For example, I have 3 camera and 3 mics. I > > >>>can provide: > > >>>1) 3 individual video each with corresponding audio > > >>>2) 1 active speaker only switched video with mixed audio > > >>>3) 1 composed video including active speaker and 'n' > > >>>non-active speakers (where 'n' is may be all or some fixed > > >>>limit) and mixed audio > > >> > > >> > > >>>>I actually think that your examples, as written, are different > RENDERING TYPES, because they only > > talk about mixing and composition. > > >> > > >>>Confirmation that I am clueless about rendering types. > > > > > > > > >>A value identifying the rendering algorithm used to produce a media > stream sent towards the client. > > > > >In a client-to-client call this is backwards. "Capture" describes the > stream production process > > better, rendering is that the client does with the > > >streams it receives. Anyway, changing "Rendering type" to "rendering > algorithm" doesn't help me much. > > > > It's probably easier to understand rendering type if one knows what we > mean by render. > > > > Our proposed definition is: > > > > "Rendering: Composing a media signal from one or more media signals > using a specific composition > > algorithm, often according to a specific spatial model/layout." > > > > So, the "rendering type" is a value associated with that algorithm. > > > > So, I think the important thing in our "rendering" definition is that an > output media signal is > > generated. > > > > Now, if people think that our usage of "rendering" is confusing, we can > of course use other wording > > instead. > > This works for me. It may be useful to expand with typical audio and video > examples, such as mixing multiple audio stream inputs into a single audio > stream output, or composing multiple video stream inputs into a single video > stream output. > > Cheers, > Charles > > > > > > > > > > >>>In my opinion, a LAYOUT TYPE is a description of how sources are > placed in a virtual room. > > >>> > > >>>For me layout is about composition. Layouts do not necessarily create > a virtual room experience, > > particularly in multipoint calls. > > >> > > >> > > >>Ok, so we need to make sure we have a common understanding of layout > then :) > > >> > > >>So, just to clarify, do you think that source selection is layout? > > > > > > > > >I generally separate them, though they are related. For instance, in a > traditional Video MCU you can > > often choose a source-independent layout (2x2 array > > >of equal size windows, a 1+5 layout, where the "1" window is bigger than > the others, and at the top > > left, etc). Then you can control the mapping of > > >sources to windows separately. Not sure this is the only way to > partition it, just the way I tend to > > use. > > > > Ok. So, first, I guess there is "source-dependent layout" and > "source-independent layout". > > > > Second, there is an algorithm that creates the output stream, using the > layout as input. > > > > Of course, in this case one might not need to be able to explicitly > indicate the algorithm - if it's > > enough to indicate the layout. > > > > > > > > > > >I see four distinct elements in your mobile binaural case - (a) the > sources chosen for placement, > > > > Correct. That's "source selection". > > > > >(b) the set of placements used in creating a sound stage, > > > > > >(c) the placement used for each particular source at the moment, > > >and (d) whether the outbound audio is binaural or not. > > >I'd personally call (b) the audio layout, though you can equally well > call (b+c) the audio layout. > > > > Ok. So, that would be a "source-dependent layout", I guess? > > > > Then, (d) would be the actual rendering algorithm, using the layout as > input. > > > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > > > > > >If the receiving endpoint wants to control > the layout itself, > > >it goes with option 1. If it has limited > > >resources/bandwidth/screens/etc it may > prefer option 2 or 3. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org [mailto: > clue-bounces@ietf.org] On Behalf > > > Of Christer Holmberg > > > > Sent: Tuesday, June 21, 2011 3:52 AM > > > > To: clue@ietf.org > > > > Subject: [clue] Layout negotiation > > > > > > > > Hi, > > > > > > > > A while ago there were some discussions > about having requirements to > > > negotiate the layout type, and at > > > > least according to Stephen B it was > within the scope of the work. > > > > > > > > "The ability to negotiate an > audio or video layout > > > is clearly > > > within scope, and has general > > > > value it the group wants to take it on. > > > > For instance, if you combine > video switching of multiple > > > sources with audio > > > > mixing/transcoding, then the receiver is > responsible > > > > for the video layout but has no > control over the > > > audio layout. > > > In that case, there are > > > > advantages to allowing the receiver to > tell the > > > > central audio mixer where it > wants the sources placed on the > > > sound stage. I have no objection > > > > in principle to adding that kind of > > > > negotiation to the requirements, > though I think the group > > > should consider the impact on the > > > > schedule." > > > > > > > > However, I haven't seen any input after > that. > > > > > > > > My idea would be that it is very similar > to the rendering type: CLUE > > > defines a mechanism to negotiate > > > > the layout type, but doesn't define > specific types (instead an IANA > > > registry would be created for > > > > that). So, I don't think it would have > any significant impact on our > > > schedule. > > > > > > > > Whether it, in addition to negotiation a > layout type (which > > > specifies > > > the source locations), should be > > > > possible for the user to more explicit > place individual sources, as > > > mentioned by Stephen, can be > > > > discussed. However, that would probably > require a little > > > more work, so > > > at least I would be happy with > > > > a simple layout type negotiation at this > point. > > > > > > > > So, would people be ok with such > requirement? > > > > > > > > (Another alternative would be to "embed" > the layout type into the > > > rendering type, but I think that > > > > would be very clumsy. Because, in that > case you would need to define > > > mulitple types for the same > > > > rendering, but with different layouts.) > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > --20cf307cfd8208a50c04a65184aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not sure yet that we need any requirements on creating a general me= chanism just yet, but that we should continue to develop the use cases.
=
Stephen B.

On Wed, Jun 22, 2011 at 1:= 03 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:
> ----= -Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Wednesday, June 22, 2011 9:46 AM
> To: Stephen Botzko
> Cc: Charles Eckel (eckelcu); clue@iet= f.org
> Subject: RE: [clue] Layout negotiation
>
>
> Hi,
>
> >>>I think I was the one that brought up layouts originally. = I
> >>>was more concerned with video layouts than audio layouts.<= br> > >>>Currently, the requirements draft seems to focus more on > >>>audio layout/spatial audio.
> >>>Requirements 3 and 16 both deal with parts of this. I feel=
> >>>there needs to be more clear requirements on the ability f= or
> >>>the to represent the potential layouts of the audio/video = can
> >>>that be offered. For example, I have 3 camera and 3 mics. = I
> >>>can provide:
> >>>1) 3 individual video each with corresponding audio
> >>>2) 1 active speaker only switched video with mixed audio > >>>3) 1 composed video including active speaker and 'n= 9;
> >>>non-active speakers (where 'n' is may be all or so= me fixed
> >>>limit) and mixed audio
> >>
> >>
> >>>>I actually think that your examples, as written, are d= ifferent RENDERING TYPES, because they only
> talk about mixing and composition.
> >>
> >>>Confirmation that I am clueless about rendering types.
> >
> >
> >>A value identifying the rendering algorithm used to produce a = media stream sent towards the client.
>
> >In a client-to-client call this is backwards. =A0"Capture&quo= t; describes the stream production process
> better, rendering is that the client does with the
> >streams it receives. Anyway, changing "Rendering type" t= o "rendering algorithm" doesn't help me much.
>
> It's probably easier to understand rendering type if one knows wha= t we mean by render.
>
> Our proposed definition is:
>
> "Rendering:=A0=A0 Composing a media signal from one or more media= signals using a specific composition
> algorithm, often according to a specific spatial model/layout." >
> So, the "rendering type" is a value associated with that alg= orithm.
>
> So, I think the important thing in our "rendering" definitio= n is that an output media signal is
> generated.
>
> Now, if people think that our usage of "rendering" is confus= ing, we can of course use other wording
> instead.

This works for me. It may be useful to expand with typical audi= o and video examples, such as mixing multiple audio stream inputs into a si= ngle audio stream output, or composing multiple video stream inputs into a = single video stream output.

Cheers,
Charles


>
>
>
> >>>In my opinion, a LAYOUT TYPE is a description of how sourc= es are placed in a virtual room.
> >>>
> >>>For me layout is about composition. Layouts do not necessa= rily create a virtual room experience,
> particularly in multipoint calls.
> >>
> >>
> >>Ok, so we need to make sure we have a common understanding of = layout then :)
> >>
> >>So, just to clarify, do you think that source selection is lay= out?
> >
> >
> >I generally separate them, though they are related. =A0For instanc= e, in a traditional Video MCU you can
> often choose a source-independent layout (2x2 array
> >of equal size windows, a 1+5 layout, where the "1" windo= w is bigger than the others, and at the top
> left, etc). =A0Then you can control the mapping of
> >sources to windows separately. =A0Not sure this is the only way to= partition it, just the way I tend to
> use.
>
> Ok. So, first, I guess there is "source-dependent layout" an= d "source-independent layout".
>
> Second, there is an algorithm that creates the output stream, using th= e layout as input.
>
> Of course, in this case one might not need to be able to explicitly in= dicate the algorithm - if it's
> enough to indicate the layout.
>
>
>
>
> >I see four distinct elements in your mobile binaural case - (a) th= e sources chosen for placement,
>
> Correct. That's "source selection".
>
> >(b) the set of placements used in creating a sound stage,
> >
> >(c) the placement used for each particular source at the moment, > >and (d) whether the outbound audio is binaural or not.
> >I'd personally call (b) the audio layout, though you can equal= ly well call (b+c) the audio layout.
>
> Ok. So, that would be a "source-dependent layout", I guess?<= br> >
> Then, (d) would be the actual rendering algorithm, using the layout as= input.
>
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>If the = receiving endpoint wants to control the layout itself,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>it goes= with option 1. If it has limited
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>resourc= es/bandwidth/screens/etc it may prefer option 2 or 3.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Cheers= ,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Charle= s
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > -= ----Original Message-----
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > F= rom: clue-bounces@ietf.org [ma= ilto:clue-bounces@ietf.org] On= Behalf
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Of Chr= ister Holmberg
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > S= ent: Tuesday, June 21, 2011 3:52 AM
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > T= o: clue@ietf.org
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > S= ubject: [clue] Layout negotiation
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > H= i,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > A= while ago there were some discussions about having requirements to
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> negoti= ate the layout type, and at
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > l= east according to Stephen B it was within the scope of the work.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > = =A0 =A0 =A0 =A0 "The ability to negotiate an audio or video layout
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> is cle= arly
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> within= scope, and has general
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > v= alue it the group wants to take it on.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > = =A0 =A0 =A0 =A0 For instance, if you combine video switching of multiple > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> source= s with audio
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > m= ixing/transcoding, then the receiver is responsible
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > = =A0 =A0 =A0 =A0 for the video layout but has no control over the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> audio = layout.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> In tha= t case, there are
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > a= dvantages to allowing the receiver to tell the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > = =A0 =A0 =A0 =A0 central audio mixer where it wants the sources placed on th= e
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> sound = stage. =A0I have no objection
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > i= n principle to adding that kind of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > = =A0 =A0 =A0 =A0 negotiation to the requirements, though I think the group > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> should= consider the impact on the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > s= chedule."
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > H= owever, I haven't seen any input after that.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > M= y idea would be that it is very similar to the rendering type: CLUE
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> define= s a mechanism to negotiate
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > t= he layout type, but doesn't define specific types (instead an IANA
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> regist= ry would be created for
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > t= hat). So, I don't think it would have any significant impact on our
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> schedu= le.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > W= hether it, in addition to negotiation a layout type (which
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> specif= ies
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> the so= urce locations), should be
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > p= ossible for the user to more explicit place individual sources, as
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> mentio= ned by Stephen, can be
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > d= iscussed. However, that would probably require a little
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> more w= ork, so
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> at lea= st I would be happy with
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > a= simple layout type negotiation at this point.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > S= o, would people be ok with such requirement?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > (= Another alternative would be to "embed" the layout type into the<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> render= ing type, but I think that
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > w= ould be very clumsy. Because, in that case you would need to define
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> mulitp= le types for the same
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > r= endering, but with different layouts.)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > R= egards,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > C= hrister
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________= ____________________________________
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailin= g list
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue@ietf.org
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0https://www.i= etf.org/mailman/listinfo/clue
>
>
>
>
>


--20cf307cfd8208a50c04a65184aa-- From allyn@cisco.com Wed Jun 22 12:31:25 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2C211E808A for ; Wed, 22 Jun 2011 12:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJRGUi8dMhhB for ; Wed, 22 Jun 2011 12:31:23 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id E5AB911E8073 for ; Wed, 22 Jun 2011 12:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=9681; q=dns/txt; s=iport; t=1308771083; x=1309980683; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=UTS1jyfgQH1safYLreHS4ZMHvkgRJfy1jQqM9RDiVoU=; b=B89zBbBBCMWxok4UBOGHrBt+BRuVmorOLhlZ96awp6anPb9jI3KEsSDq kv8LXvgnUSM1r+weG0oCpsKhlf4a/gKjrXZ0+hBxhQp/fz+feWyK0NH+k O+MhxxcuW4+0/MlPi9ffPyqo0mVWbOP2MdCvmezp9Qq0bHBQ6FJTJIiEO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAFZCAk6rRDoI/2dsb2JhbABTl3ePGneIc6IznkCGLQSHJY8ziz4 X-IronPort-AV: E=Sophos;i="4.65,407,1304294400"; d="scan'208";a="467354421" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 22 Jun 2011 19:31:23 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5MJVF8l015673; Wed, 22 Jun 2011 19:31:23 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 12:31:21 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jun 2011 12:31:20 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC65CC@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Layout negotiation Thread-Index: Acww8sQlRUBW5WOSS4K6jxoq1LlJrwABhLoAAAEsT+AABQroMA== References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A79A@ESESSCMS0356.eemea.ericsson.se> From: "Allyn Romanow (allyn)" To: "Charles Eckel (eckelcu)" , "Christer Holmberg" , "Stephen Botzko" X-OriginalArrivalTime: 22 Jun 2011 19:31:21.0458 (UTC) FILETIME=[F7452D20:01CC3112] Cc: clue@ietf.org Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 19:31:25 -0000 Huh? Perhaps one of you could summarize where we are in the conversation, and = what is agreed upon so far? One thing to remind you of is that we have agreed that CLUE does not = specify how rendering should be done, that is up to the receiver. The = sender (and receiver) can send info, but CLUE isn't specifying what the = receiver (renderer) does with it, meaning how it does the rendering, = what choices it makes. I thought Charles' original email may have been = suggesting specifying rendering, wasn't really sure. =20 Thanks, Allyn -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Charles Eckel (eckelcu) Sent: Wednesday, June 22, 2011 10:03 AM To: Christer Holmberg; Stephen Botzko Cc: clue@ietf.org Subject: Re: [clue] Layout negotiation > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, June 22, 2011 9:46 AM > To: Stephen Botzko > Cc: Charles Eckel (eckelcu); clue@ietf.org > Subject: RE: [clue] Layout negotiation >=20 >=20 > Hi, >=20 > >>>I think I was the one that brought up layouts originally. I > >>>was more concerned with video layouts than audio layouts. > >>>Currently, the requirements draft seems to focus more on > >>>audio layout/spatial audio. > >>>Requirements 3 and 16 both deal with parts of this. I feel > >>>there needs to be more clear requirements on the ability for > >>>the to represent the potential layouts of the audio/video can > >>>that be offered. For example, I have 3 camera and 3 mics. I > >>>can provide: > >>>1) 3 individual video each with corresponding audio > >>>2) 1 active speaker only switched video with mixed audio > >>>3) 1 composed video including active speaker and 'n' > >>>non-active speakers (where 'n' is may be all or some fixed > >>>limit) and mixed audio > >> > >> > >>>>I actually think that your examples, as written, are different = RENDERING TYPES, because they only > talk about mixing and composition. > >> > >>>Confirmation that I am clueless about rendering types. > > > > > >>A value identifying the rendering algorithm used to produce a media = stream sent towards the client. >=20 > >In a client-to-client call this is backwards. "Capture" describes = the stream production process > better, rendering is that the client does with the > >streams it receives. Anyway, changing "Rendering type" to "rendering = algorithm" doesn't help me much. >=20 > It's probably easier to understand rendering type if one knows what we = mean by render. >=20 > Our proposed definition is: >=20 > "Rendering:=A0=A0 Composing a media signal from one or more media = signals using a specific composition > algorithm, often according to a specific spatial model/layout." >=20 > So, the "rendering type" is a value associated with that algorithm. >=20 > So, I think the important thing in our "rendering" definition is that = an output media signal is > generated. >=20 > Now, if people think that our usage of "rendering" is confusing, we = can of course use other wording > instead. This works for me. It may be useful to expand with typical audio and = video examples, such as mixing multiple audio stream inputs into a = single audio stream output, or composing multiple video stream inputs = into a single video stream output. Cheers, Charles >=20 >=20 >=20 > >>>In my opinion, a LAYOUT TYPE is a description of how sources are = placed in a virtual room. > >>> > >>>For me layout is about composition. Layouts do not necessarily = create a virtual room experience, > particularly in multipoint calls. > >> > >> > >>Ok, so we need to make sure we have a common understanding of layout = then :) > >> > >>So, just to clarify, do you think that source selection is layout? > > > > > >I generally separate them, though they are related. For instance, in = a traditional Video MCU you can > often choose a source-independent layout (2x2 array > >of equal size windows, a 1+5 layout, where the "1" window is bigger = than the others, and at the top > left, etc). Then you can control the mapping of > >sources to windows separately. Not sure this is the only way to = partition it, just the way I tend to > use. >=20 > Ok. So, first, I guess there is "source-dependent layout" and = "source-independent layout". >=20 > Second, there is an algorithm that creates the output stream, using = the layout as input. >=20 > Of course, in this case one might not need to be able to explicitly = indicate the algorithm - if it's > enough to indicate the layout. >=20 >=20 >=20 >=20 > >I see four distinct elements in your mobile binaural case - (a) the = sources chosen for placement, >=20 > Correct. That's "source selection". >=20 > >(b) the set of placements used in creating a sound stage, > > > >(c) the placement used for each particular source at the moment, > >and (d) whether the outbound audio is binaural or not. > >I'd personally call (b) the audio layout, though you can equally well = call (b+c) the audio layout. >=20 > Ok. So, that would be a "source-dependent layout", I guess? >=20 > Then, (d) would be the actual rendering algorithm, using the layout as = input. >=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > >If the receiving endpoint wants to control the = layout itself, > >it goes with option 1. If it has limited > >resources/bandwidth/screens/etc it may prefer option = 2 or 3. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On Behalf > > Of Christer Holmberg > > > Sent: Tuesday, June 21, 2011 3:52 AM > > > To: clue@ietf.org > > > Subject: [clue] Layout negotiation > > > > > > Hi, > > > > > > A while ago there were some discussions about = having requirements to > > negotiate the layout type, and at > > > least according to Stephen B it was within the = scope of the work. > > > > > > "The ability to negotiate an audio or = video layout > > is clearly > > within scope, and has general > > > value it the group wants to take it on. > > > For instance, if you combine video = switching of multiple > > sources with audio > > > mixing/transcoding, then the receiver is = responsible > > > for the video layout but has no control = over the > > audio layout. > > In that case, there are > > > advantages to allowing the receiver to tell the > > > central audio mixer where it wants the = sources placed on the > > sound stage. I have no objection > > > in principle to adding that kind of > > > negotiation to the requirements, though I = think the group > > should consider the impact on the > > > schedule." > > > > > > However, I haven't seen any input after that. > > > > > > My idea would be that it is very similar to the = rendering type: CLUE > > defines a mechanism to negotiate > > > the layout type, but doesn't define specific = types (instead an IANA > > registry would be created for > > > that). So, I don't think it would have any = significant impact on our > > schedule. > > > > > > Whether it, in addition to negotiation a layout = type (which > > specifies > > the source locations), should be > > > possible for the user to more explicit place = individual sources, as > > mentioned by Stephen, can be > > > discussed. However, that would probably require a = little > > more work, so > > at least I would be happy with > > > a simple layout type negotiation at this point. > > > > > > So, would people be ok with such requirement? > > > > > > (Another alternative would be to "embed" the = layout type into the > > rendering type, but I think that > > > would be very clumsy. Because, in that case you = would need to define > > mulitple types for the same > > > rendering, but with different layouts.) > > > > > > Regards, > > > > > > Christer > > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 >=20 >=20 >=20 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Wed Jun 22 12:44:07 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2492C11E809C for ; Wed, 22 Jun 2011 12:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdtepFCMDK6k for ; Wed, 22 Jun 2011 12:44:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C87EE11E8073 for ; Wed, 22 Jun 2011 12:44:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-17-4e02460181fc Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 93.E3.09774.106420E4; Wed, 22 Jun 2011 21:44:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 22 Jun 2011 21:43:59 +0200 From: Christer Holmberg To: "Allyn Romanow (allyn)" , "Charles Eckel (eckelcu)" , Stephen Botzko Date: Wed, 22 Jun 2011 21:43:57 +0200 Thread-Topic: [clue] Layout negotiation Thread-Index: Acww8sQlRUBW5WOSS4K6jxoq1LlJrwABhLoAAAEsT+AABQroMAAAeBpQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A7CE@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A79A@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC65CC@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC65CC@xmb-sjc-221.amer.cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 19:44:07 -0000 Hi Allyn,=20 >Huh? >Perhaps one of you could summarize where we are in the=20 >conversation, and what is agreed upon so far? I think we're having more or less a definition discussion. >One thing to remind you of is that we have agreed that CLUE=20 >does not specify how rendering should be done, that is up to=20 >the receiver. The sender (and receiver) can send info, but=20 >CLUE isn't specifying what the receiver (renderer) does with=20 >it, meaning how it does the rendering, what choices it=20 >makes. I thought Charles' original email may have been=20 >suggesting specifying rendering, wasn't really sure. I think what charles is talking is about being able to indicate: 1. Which streams are used to create an output stream 2. How does the output stream look like It seems like people consider that being part of LAYOUT. Regards, Christer > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of Charles Eckel (eckelcu) > Sent: Wednesday, June 22, 2011 10:03 AM > To: Christer Holmberg; Stephen Botzko > Cc: clue@ietf.org > Subject: Re: [clue] Layout negotiation >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Wednesday, June 22, 2011 9:46 AM > > To: Stephen Botzko > > Cc: Charles Eckel (eckelcu); clue@ietf.org > > Subject: RE: [clue] Layout negotiation > >=20 > >=20 > > Hi, > >=20 > > >>>I think I was the one that brought up layouts originally. I was=20 > > >>>more concerned with video layouts than audio layouts. > > >>>Currently, the requirements draft seems to focus more on audio=20 > > >>>layout/spatial audio. > > >>>Requirements 3 and 16 both deal with parts of this. I feel there=20 > > >>>needs to be more clear requirements on the ability for the to=20 > > >>>represent the potential layouts of the audio/video can that be=20 > > >>>offered. For example, I have 3 camera and 3 mics. I can provide: > > >>>1) 3 individual video each with corresponding audio > > >>>2) 1 active speaker only switched video with mixed audio > > >>>3) 1 composed video including active speaker and 'n' > > >>>non-active speakers (where 'n' is may be all or some fixed > > >>>limit) and mixed audio > > >> > > >> > > >>>>I actually think that your examples, as written, are different=20 > > >>>>RENDERING TYPES, because they only > > talk about mixing and composition. > > >> > > >>>Confirmation that I am clueless about rendering types. > > > > > > > > >>A value identifying the rendering algorithm used to=20 > produce a media stream sent towards the client. > >=20 > > >In a client-to-client call this is backwards. "Capture" describes=20 > > >the stream production process > > better, rendering is that the client does with the > > >streams it receives. Anyway, changing "Rendering type" to=20 > "rendering algorithm" doesn't help me much. > >=20 > > It's probably easier to understand rendering type if one=20 > knows what we mean by render. > >=20 > > Our proposed definition is: > >=20 > > "Rendering:=A0=A0 Composing a media signal from one or more=20 > media signals=20 > > using a specific composition algorithm, often according to=20 > a specific spatial model/layout." > >=20 > > So, the "rendering type" is a value associated with that algorithm. > >=20 > > So, I think the important thing in our "rendering"=20 > definition is that=20 > > an output media signal is generated. > >=20 > > Now, if people think that our usage of "rendering" is confusing, we=20 > > can of course use other wording instead. >=20 > This works for me. It may be useful to expand with typical=20 > audio and video examples, such as mixing multiple audio=20 > stream inputs into a single audio stream output, or composing=20 > multiple video stream inputs into a single video stream output. >=20 > Cheers, > Charles >=20 >=20 > >=20 > >=20 > >=20 > > >>>In my opinion, a LAYOUT TYPE is a description of how=20 > sources are placed in a virtual room. > > >>> > > >>>For me layout is about composition. Layouts do not necessarily=20 > > >>>create a virtual room experience, > > particularly in multipoint calls. > > >> > > >> > > >>Ok, so we need to make sure we have a common=20 > understanding of layout=20 > > >>then :) > > >> > > >>So, just to clarify, do you think that source selection is layout? > > > > > > > > >I generally separate them, though they are related. For=20 > instance, in=20 > > >a traditional Video MCU you can > > often choose a source-independent layout (2x2 array > > >of equal size windows, a 1+5 layout, where the "1" window=20 > is bigger=20 > > >than the others, and at the top > > left, etc). Then you can control the mapping of > > >sources to windows separately. Not sure this is the only way to=20 > > >partition it, just the way I tend to > > use. > >=20 > > Ok. So, first, I guess there is "source-dependent layout"=20 > and "source-independent layout". > >=20 > > Second, there is an algorithm that creates the output=20 > stream, using the layout as input. > >=20 > > Of course, in this case one might not need to be able to explicitly=20 > > indicate the algorithm - if it's enough to indicate the layout. > >=20 > >=20 > >=20 > >=20 > > >I see four distinct elements in your mobile binaural case=20 > - (a) the=20 > > >sources chosen for placement, > >=20 > > Correct. That's "source selection". > >=20 > > >(b) the set of placements used in creating a sound stage, > > > > > >(c) the placement used for each particular source at the=20 > moment, and=20 > > >(d) whether the outbound audio is binaural or not. > > >I'd personally call (b) the audio layout, though you can=20 > equally well call (b+c) the audio layout. > >=20 > > Ok. So, that would be a "source-dependent layout", I guess? > >=20 > > Then, (d) would be the actual rendering algorithm, using=20 > the layout as input. > >=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > >If the receiving endpoint wants=20 > to control the layout itself, > > >it goes with option 1. If it has limited > > >resources/bandwidth/screens/etc=20 > it may prefer option 2 or 3. > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf > > > Of Christer Holmberg > > > > Sent: Tuesday, June 21, 2011 3:52 AM > > > > To: clue@ietf.org > > > > Subject: [clue] Layout negotiation > > > > > > > > Hi, > > > > > > > > A while ago there were some=20 > discussions about having requirements to > > > negotiate the layout type, and at > > > > least according to Stephen B=20 > it was within the scope of the work. > > > > > > > > "The ability to=20 > negotiate an audio or video layout > > > is clearly > > > within scope, and has general > > > > value it the group wants to=20 > take it on. > > > > For instance, if you=20 > combine video switching of multiple > > > sources with audio > > > > mixing/transcoding, then the=20 > receiver is responsible > > > > for the video layout=20 > but has no control over the > > > audio layout. > > > In that case, there are > > > > advantages to allowing the=20 > receiver to tell the > > > > central audio mixer=20 > where it wants the sources placed on the > > > sound stage. I have no objection > > > > in principle to adding that kind of > > > > negotiation to the=20 > requirements, though I think the group > > > should consider the impact on the > > > > schedule." > > > > > > > > However, I haven't seen any=20 > input after that. > > > > > > > > My idea would be that it is=20 > very similar to the rendering type: CLUE > > > defines a mechanism to negotiate > > > > the layout type, but doesn't=20 > define specific types (instead an IANA > > > registry would be created for > > > > that). So, I don't think it=20 > would have any significant impact on our > > > schedule. > > > > > > > > Whether it, in addition to=20 > negotiation a layout type (which > > > specifies > > > the source locations), should be > > > > possible for the user to=20 > more explicit place individual sources, as > > > mentioned by Stephen, can be > > > > discussed. However, that=20 > would probably require a little > > > more work, so > > > at least I would be happy with > > > > a simple layout type=20 > negotiation at this point. > > > > > > > > So, would people be ok with=20 > such requirement? > > > > > > > > (Another alternative would=20 > be to "embed" the layout type into the > > > rendering type, but I think that > > > > would be very clumsy.=20 > Because, in that case you would need to define > > > mulitple types for the same > > > > rendering, but with=20 > different layouts.) > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > =20 _______________________________________________ > > clue mailing list > > clue@ietf.org > > =20 https://www.ietf.org/mailman/listinfo/clue > >=20 > >=20 > >=20 > >=20 > >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > = From allyn@cisco.com Wed Jun 22 13:21:22 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6FF11E80C2 for ; Wed, 22 Jun 2011 13:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn9q27XeV0iC for ; Wed, 22 Jun 2011 13:21:19 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DF61A11E8161 for ; Wed, 22 Jun 2011 13:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=25598; q=dns/txt; s=iport; t=1308774074; x=1309983674; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=vfune0qDRqr3j0Fd6tvBNMctClgk0vdjcZweJwRU3LM=; b=ACQm1SD/YVfODhYT4EtlhUgIOecj08cj5r2dBZ9MVikojB14ZX++fZ42 mpeKvehAEjqK/lj+f13sJShIAdyf1SaiGlbCidKXCSOBSmbN5uoRgKyQ2 NXE7ozeuo+HzqZTdd0Senl3umQCxxQFlK7w1IAxiFFNpdr9x+6UWH2KgZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAExOAk6rRDoJ/2dsb2JhbABTglGVKI8Yd6s4njiGLQSHJY8ziz4 X-IronPort-AV: E=Sophos;i="4.65,407,1304294400"; d="scan'208,217";a="383513553" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2011 20:21:13 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5MKLB3V011297; Wed, 22 Jun 2011 20:21:13 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 13:21:09 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3119.EC15CFCA" Date: Wed, 22 Jun 2011 13:21:03 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC660D@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Stephan's comments on Requirements-03 Thread-Index: AcwvWSEolSlCd403Q6Sb3XE5ACLD9wBORFdA References: From: "Allyn Romanow (allyn)" To: "Stephan Wenger" , X-OriginalArrivalTime: 22 Jun 2011 20:21:09.0522 (UTC) FILETIME=[EC4B8F20:01CC3119] Subject: Re: [clue] Stephan's comments on Requirements-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 20:21:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3119.EC15CFCA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephan, Thanks for the great comments... for finding the time to go over the doc carefully- =20 These are roughly from both Steve and myself. =20 Allyn =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Monday, June 20, 2011 7:48 AM To: clue@ietf.org Subject: [clue] Stephan's comments on Requirements-03 =20 Hi, Due to other commitments, I have not followed the mailing list in detail. Some of my comments may be duplicates; apologies in advance for that. Overall, this draft is better than the previous ones. However, there are still a number of issues that I would like to raise. =20 Req.1 "preservation order"??? What is this? Needs to be defined... It's a typo - It was meant to be allowing the preservation of order of images - does that make more sense to you? There follows a simple example in case it is not clear. =20 Req.1c "aspect ratio" -> "picture aspect ratio", to distinguish from pixel aspect ratio (both terms are common in video compression) 1c was removed. =20 Req.1d "as described in the use cases": I don't like this type of cross reference, but have not had time to come up with a good solution. Agree. How is this modest change? The solution MUST support a means to communicate information allowing multi-view. Use case virtual space (multi-view). =20 =20 Req.2a "order of audio" -> "spatial order of audio" ok Req.2b MUST for the 3.0? Suggest "SHOULD". Also suggest "SHOULD 5.1", as 5.1, while not common in today's systems, has appeared on at least one Telepresence roadmap I'm aware of. =20 Let's discuss =20 Req.2c Personally, I don't care about binaural support either way; however, MUST NOT seems wrong here. I think requirements should be expressed positively, with the appropriate level of mandation. So why not "MAY" support binaural? Or "SHOULD"? Yes - this whole issue is under discussion. =20 Req 3a fine with me as written. However, have you thought about the implications when considering centralized mixing? In order to fulfill the use cases behind the requirements, the mixer needs to be aware of both capture info and rendering info... Not an issue for me, but there may be IPR implications, and I would prefer to see a "SHOULD" level of mandation for the centralized audio mixing use case (only). I don't see this, let's discuss =20 Req. 3b this requirement needs to be rephrased. We should not put requirements on the renderer. "The solution MUST enable individual audio streams that have no camera position associated with"? Or something to this extent? Yes, I agree with you. Steve suggests we discuss further. =20 Req 4. Convert edt. note into regular text; it contains helpful info. done =20 Req. 5 fine We can remove this now that the editor's note in 4 mentions the zero case, right? =20 Req 6 aspect ratio -> picture aspect ratio. Or do you also want to worry about pixel aspect ratios? Now that would be fun for the implementers :-) =20 Req 7 fine, but since we should not specify rendering, this requirement is a No-Op, right? Steve would like to discuss =20 Req 8 fine =20 Req 9 fine =20 Req 10 needs IMO to be more general. "different bit rates" -> "endpoints with different connectivity, i.e. in terms of bitrate, packet loss rate, and other connectivity aspects" =20 Ok. Would prefer a specific list rather than broad phrase open to interpretation. =20 Req 11 fine. Perhaps add a note indicating that, obviously, dumb endpoints cannot take advantage of solution features unless an MCU or gateway is in play which deals with those solution features. Don't really feel it's necessary. But don't feel very strongly. =20 Req 12 fine =20 Req 13 Is anywhere here advocating switching??? Can we please rid ourselves from concepts 10+ years out of date? Maybe I'm not clear on what you mean, since as you know some current systems use switching rather than transcoding. But, if you mean this is an unnecessary requirement, and multipoint is understood, I don't mind removing the reqmt. =20 Req 14 I don't understand this requirement. Needs elaboration and/or an example Okay, agree =20 Req 15 What is "audio activity"? And, suggest moving this requirement up to where the other audio requirements are Okay, will define audio activity. It's more about what video to show than audio, so suggest leaving where it is. =20 Req 16, third bullet, language is garbled. Suggest to spell out those assorted requirements. I think 3 is redundant with 4, so would like to remove =20 Req 17 fine =20 Stephan =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CC3119.EC15CFCA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephan,

Thanks for the great comments… for finding the time = to go over the doc carefully-

 

These are roughly from both Steve and = myself.

 

Allyn

 

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephan Wenger
Sent: Monday, June 20, 2011 7:48 AM
To: clue@ietf.org
Subject: [clue] Stephan's comments on = Requirements-03

 

Hi,

Due to other commitments, I have not followed the mailing = list in detail.  Some of my comments may be duplicates; apologies in = advance for that.

Overall, this draft is better than the previous ones.  However, there are still a number of issues that I would like to = raise.

 

Req.1 "preservation order"???  What is this?  Needs to be defined…

It’s a typo – It was meant to be allowing the preservation of order of images – does that make more sense to = you? There follows a simple example in case it is not clear.

 

Req.1c "aspect ratio" -> "picture aspect ratio", to distinguish from pixel aspect ratio (both terms are = common in video compression)

1c was removed.

 

Req.1d "as described in the use cases": I don't = like this type of cross reference, but have not had time to come up with a = good solution.

Agree. How is this modest change?

The solution MUST support = a means to communicate information allowing multi-view.

Use case virtual space = (multi-view).

 

 

Req.2a "order of audio" -> "spatial order = of audio"

ok

Req.2b MUST for the 3.0?  Suggest "SHOULD".  Also suggest "SHOULD 5.1", as 5.1, while not common in = today's systems, has appeared on at least one Telepresence roadmap I'm aware = of.

 

Let’s discuss

 

Req.2c Personally, I don't care about binaural support = either way; however, MUST NOT seems wrong here.  I think requirements should be expressed positively, with the appropriate level of mandation.  So = why not "MAY" support binaural?  Or = "SHOULD"?

Yes – this whole issue is under = discussion.

 

Req 3a fine with me as written.  However, have you = thought about the implications when considering centralized mixing?  In = order to fulfill the use cases behind the requirements, the mixer needs to be = aware of both capture info and rendering info…  Not an issue for me, = but there may be IPR implications, and I would prefer to see a = "SHOULD" level of mandation for the centralized audio mixing use case = (only).

I don’t see this, let’s = discuss

 

Req. 3b this requirement needs to be rephrased.  We = should not put requirements on the renderer.  "The solution MUST = enable individual audio streams that have no camera position associated = with"?  Or something to this extent?

Yes, I agree with you. Steve suggests we discuss = further.

 

Req 4.  Convert edt. note into regular text; it = contains helpful info.

done

 

Req. 5 fine

We can remove this now that the editor’s note in 4 mentions the zero case, right?

 

Req 6 aspect ratio -> picture aspect ratio.  Or do = you also want to worry about pixel aspect ratios?  Now that would be = fun for the implementers :-)

 

Req 7 fine, but since we should not specify rendering, this requirement is a No-Op, right?

Steve would like to discuss

 

Req 8 fine

 

Req 9 fine

 

Req 10 needs IMO to be more general.  "different = bit rates"  -> "endpoints with different connectivity, = i.e. in terms of bitrate, packet loss rate, and other connectivity aspects" =  

Ok. Would prefer a specific list rather than broad phrase = open to interpretation.

 

Req 11 fine.  Perhaps add a note indicating that, = obviously, dumb endpoints cannot take advantage of solution features unless an MCU = or gateway is in play which deals with those solution = features.

Don’t really feel it’s necessary. But = don’t feel very strongly.

 

Req 12 fine

 

Req 13 Is anywhere here advocating switching???  Can = we please rid ourselves from concepts 10+ years out of = date?

Maybe I’m not clear on what you mean, since as you = know some current systems use switching rather than transcoding. But, if you mean = this is an unnecessary requirement, and multipoint is understood, I don’t = mind removing the reqmt.

 

Req 14  I don't understand this requirement. =  Needs elaboration and/or an example

Okay, agree

 

Req 15 What is "audio activity"?  And, = suggest moving this requirement up to where the other audio requirements = are

Okay, will define audio activity. It’s more about = what video to show than audio, so suggest leaving where it = is.

 

Req 16, third bullet, language is garbled.  Suggest to = spell out those assorted requirements.

I think 3 is redundant with 4, so would like to = remove

 

Req 17 fine

 

Stephan

 

 

 

 

 

 

 

 

 

 

 

------_=_NextPart_001_01CC3119.EC15CFCA-- From stephen.botzko@gmail.com Wed Jun 22 14:01:54 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A54611E808B for ; Wed, 22 Jun 2011 14:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LS-vLLd77DDP for ; Wed, 22 Jun 2011 14:01:53 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E06211E8085 for ; Wed, 22 Jun 2011 14:01:52 -0700 (PDT) Received: by vxi40 with SMTP id 40so1226442vxi.31 for ; Wed, 22 Jun 2011 14:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=t4SVOidLHySezSg0QDeY6tGIzhJOvEwc/GSe2HhrJe0=; b=ALkzZV6LrKxTUeieYIYCyTrSEOqbjp9+hT3h7PWdwKD0QjkI2N1R3qRIcTiCweSeAd 9AnSvCK50eGLHbXJ9ibNn26GBFBr5Ww7fmkopMKEbmRh2ZwsitXBoBJbVaGGQckY6BJV 1Q4VK0iGGY+a1xjoS9oCNJGXpd7VIge42PyuM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iLmNTXbOcAwZUWvDMCVEAg8tTMP/7RmWggA+DLXonuKP40GZ+R44UgFRqnA9fj6BTH na1JCnGT6Z3NmAaPANOmrC1EEZ57RRB8qBiPwVB1QVUmbJBhi8dVGAfvPGkr5FkUnCU0 eMBbLIliP4NUjoGclsmomjuLZ3sJ3mJSgUZKU= MIME-Version: 1.0 Received: by 10.52.76.131 with SMTP id k3mr1739898vdw.80.1308776511693; Wed, 22 Jun 2011 14:01:51 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Wed, 22 Jun 2011 14:01:51 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC660D@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC660D@xmb-sjc-221.amer.cisco.com> Date: Wed, 22 Jun 2011 17:01:51 -0400 Message-ID: From: Stephen Botzko To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=bcaec50160e311e52104a6534734 Cc: clue@ietf.org Subject: Re: [clue] Stephan's comments on Requirements-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 21:01:54 -0000 --bcaec50160e311e52104a6534734 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable HI Stephan - To clarify the 3b comment: For me statements like "The solution MUST enabl= e individual audio streams to be rendered in any desired spatial position" do not put *any* requirements on the renderer. Req 3b says the solution must = * enable* receivers to do this (e.g., provide any needed information). But i= t does not say that receivers have to do anything. So I see no reason to spend time rewording it. On Req 7: I think I already posted a comment on requirement 7, suggesting that this might have been part of a larger requirement on the need to enabl= e display "at the proper size at the apparent distance". That is, telepresence systems today can display people at their true size, and I think there is a requirement to provide the appropriate scale information for that. This larger requirement has possibly gotten lost, if so we shoul= d circle back and re-capture it. It does look like a no-op as currently drafted - not because it touches on rendering, but because I cannot think of any way to prevent different size displays from working, no matter what you do in the protocol. Regards Stephen Botzko On Wed, Jun 22, 2011 at 4:21 PM, Allyn Romanow (allyn) wro= te: > Hi Stephan,**** > > Thanks for the great comments=85 for finding the time to go over the doc > carefully-**** > > ** ** > > These are roughly from both Steve and myself.**** > > ** ** > > Allyn**** > > ** ** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Stephan Wenger > *Sent:* Monday, June 20, 2011 7:48 AM > *To:* clue@ietf.org > *Subject:* [clue] Stephan's comments on Requirements-03**** > > ** ** > > Hi,**** > > Due to other commitments, I have not followed the mailing list in detail. > Some of my comments may be duplicates; apologies in advance for that.***= * > > Overall, this draft is better than the previous ones. However, there are > still a number of issues that I would like to raise.**** > > ** ** > > Req.1 "preservation order"??? What is this? Needs to be defined=85**** > > It=92s a typo =96 It was meant to be allowing the preservation of order o= f > images =96 does that make more sense to you? There follows a simple examp= le in > case it is not clear.**** > > ** ** > > Req.1c "aspect ratio" -> "picture aspect ratio", to distinguish from pixe= l > aspect ratio (both terms are common in video compression)**** > > 1c was removed.**** > > ** ** > > Req.1d "as described in the use cases": I don't like this type of cross > reference, but have not had time to come up with a good solution.**** > > Agree. How is this modest change?**** > > The solution MUST support a means to communicate information allowing > multi-view.**** > > Use case virtual space (multi-view).**** > > ** ** > > ** ** > > Req.2a "order of audio" -> "spatial order of audio"**** > > ok**** > > Req.2b MUST for the 3.0? Suggest "SHOULD". Also suggest "SHOULD 5.1", a= s > 5.1, while not common in today's systems, has appeared on at least one > Telepresence roadmap I'm aware of.**** > > ** ** > > Let=92s discuss**** > > ** ** > > Req.2c Personally, I don't care about binaural support either way; howeve= r, > MUST NOT seems wrong here. I think requirements should be expressed > positively, with the appropriate level of mandation. So why not "MAY" > support binaural? Or "SHOULD"?**** > > Yes =96 this whole issue is under discussion.**** > > ** ** > > Req 3a fine with me as written. However, have you thought about the > implications when considering centralized mixing? In order to fulfill th= e > use cases behind the requirements, the mixer needs to be aware of both > capture info and rendering info=85 Not an issue for me, but there may be= IPR > implications, and I would prefer to see a "SHOULD" level of mandation for > the centralized audio mixing use case (only).**** > > I don=92t see this, let=92s discuss**** > > ** ** > > Req. 3b this requirement needs to be rephrased. We should not put > requirements on the renderer. "The solution MUST enable individual audio > streams that have no camera position associated with"? Or something to t= his > extent?**** > > Yes, I agree with you. Steve suggests we discuss further.**** > > ** ** > > Req 4. Convert edt. note into regular text; it contains helpful info.***= * > > done**** > > ** ** > > Req. 5 fine**** > > We can remove this now that the editor=92s note in 4 mentions the zero ca= se, > right?**** > > ** ** > > Req 6 aspect ratio -> picture aspect ratio. Or do you also want to worry > about pixel aspect ratios? Now that would be fun for the implementers :-= ) > **** > > ** ** > > Req 7 fine, but since we should not specify rendering, this requirement i= s > a No-Op, right?**** > > Steve would like to discuss**** > > ** ** > > Req 8 fine**** > > ** ** > > Req 9 fine**** > > ** ** > > Req 10 needs IMO to be more general. "different bit rates" -> "endpoint= s > with different connectivity, i.e. in terms of bitrate, packet loss rate, = and > other connectivity aspects" **** > > Ok. Would prefer a specific list rather than broad phrase open to > interpretation.**** > > ** ** > > Req 11 fine. Perhaps add a note indicating that, obviously, dumb endpoin= ts > cannot take advantage of solution features unless an MCU or gateway is in > play which deals with those solution features.**** > > Don=92t really feel it=92s necessary. But don=92t feel very strongly.**** > > ** ** > > Req 12 fine**** > > ** ** > > Req 13 Is anywhere here advocating switching??? Can we please rid > ourselves from concepts 10+ years out of date?**** > > Maybe I=92m not clear on what you mean, since as you know some current > systems use switching rather than transcoding. But, if you mean this is a= n > unnecessary requirement, and multipoint is understood, I don=92t mind rem= oving > the reqmt.**** > > ** ** > > Req 14 I don't understand this requirement. Needs elaboration and/or an > example**** > > Okay, agree**** > > ** ** > > Req 15 What is "audio activity"? And, suggest moving this requirement up > to where the other audio requirements are**** > > Okay, will define audio activity. It=92s more about what video to show th= an > audio, so suggest leaving where it is.**** > > ** ** > > Req 16, third bullet, language is garbled. Suggest to spell out those > assorted requirements.**** > > I think 3 is redundant with 4, so would like to remove**** > > ** ** > > Req 17 fine**** > > ** ** > > Stephan**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > **** > > ** ** > > ** ** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --bcaec50160e311e52104a6534734 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable HI Stephan -

To clarify the 3b comment:=A0 For me = statements like "The solution MUST enable individual audio streams to be rendered in any desired spatial position" do not put any requirements = on the renderer.=A0 Req 3b says the solution must enable receivers t= o do this (e.g., provide any needed information).=A0 But it does not say th= at receivers have to do anything.=A0 So I see no reason to spend time rewor= ding it.

On Req 7:=A0 I think I already pos= ted a comment on requirement 7, suggesting that this might have been part o= f a larger requirement on the need to enable display "at the proper si= ze at the apparent distance".=A0 That is, telepresence systems today c= an display people at their true size, and I think there is a requirement to= provide the appropriate scale information for that.=A0 This larger require= ment has possibly gotten lost, if so we should circle back and re-capture i= t.

It does look like a no-op as currently drafted - not because it touches= on rendering, but because I cannot think of any way to prevent different s= ize displays from working, no matter what you do in the protocol.
Regards
Stephen Botzko

On Wed, Jun= 22, 2011 at 4:21 PM, Allyn Romanow (allyn) <allyn@cisco.com> wrote:

Hi St= ephan,

Thank= s for the great comments=85 for finding the time to go over the doc carefully-

=A0

These= are roughly from both Steve and myself.

=A0

Allyn=

=A0

=A0

From:= clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Monday, June 20, 2011 7:48 AM
To: clue@ietf.org=
Subject: [clue] Stephan's comments on Requirements-03<= /u>

=A0

Hi,<= /u>

Due to = other commitments, I have not followed the mailing list in detail. =A0Some of my comments may be duplicates; apologies in advance for that.

Overall= , this draft is better than the previous ones. =A0However, there are still a number of issues that I would like to raise.<= u>

= =A0

Req.1 &= quot;preservation order"??? =A0What is this? =A0Needs to be defined=85

It=92s a typo =96 It was meant to be allowing the preservation of order of images =96 does that make more sense to you? There follows a simple example in case it is not clear.

=A0

Req.1c = "aspect ratio" -> "picture aspect ratio", to distinguish from pixel aspect ratio (both terms are common = in video compression)

1c was removed.

=A0

Req.1d = "as described in the use cases": I don't like this type of cross reference, but have not had time to come up with a good solution.

Agree. How is this modest change?

The solution MUST support a means to communicate information allowing multi-view.

Use case virtual space (multi-view).

=A0

= =A0

Req.2a = "order of audio" -> "spatial order of audio"

ok

Req.2b = MUST for the 3.0? =A0Suggest "SHOULD". =A0Also suggest "SHOULD 5.1", as 5.1, while not common in today&#= 39;s systems, has appeared on at least one Telepresence roadmap I'm aware of= .

=A0

Let=92s discuss

=A0

Req.2c = Personally, I don't care about binaural support either way; however, MUST NOT seems wrong here. =A0I think requirements should be expressed positively, with the appropriate level of mandation. =A0So why no= t "MAY" support binaural? =A0Or "SHOULD"?

Yes =96 this whole issue is under discussion.

=A0

Req 3a = fine with me as written. =A0However, have you thought about the implications when considering centralized mixing? =A0In order to fulfill the use cases behind the requirements, the mixer needs to be aware = of both capture info and rendering info=85 =A0Not an issue for me, but there may be IPR implications, and I would prefer to see a "SHOULD&quo= t; level of mandation for the centralized audio mixing use case (only).=

I don=92t see this, let=92s discuss

=A0

Req. 3b= this requirement needs to be rephrased. =A0We should not put requirements on the renderer. =A0"The solution MUST enable individual audio streams that have no camera position associated with"= ? =A0Or something to this extent?

Yes, I agree with you. Steve suggests we discuss further.

= =A0

Req 4. = =A0Convert edt. note into regular text; it contains helpful info.

done

= =A0

Req. 5 = fine

We ca= n remove this now that the editor=92s note in 4 mentions the zero case, right?

= =A0

Req 6 a= spect ratio -> picture aspect ratio. =A0Or do you also want to worry about pixel aspect ratios? =A0Now that would be fun for the implementers :-)

= =A0

Req 7 f= ine, but since we should not specify rendering, this requirement is a No-Op, right?

Steve would like to discuss

= =A0

Req 8 f= ine

= =A0

Req 9 f= ine

= =A0

Req 10 = needs IMO to be more general. =A0"different bit rates" =A0-> "endpoints with different connectivity, i.e. in terms of bitrate, packet loss rate, and other connectivity aspects" = =A0

Ok. Would prefer a specific list rather than broad phrase open to interpretation.

= =A0

Req 11 = fine. =A0Perhaps add a note indicating that, obviously, dumb endpoints cannot take advantage of solution features unless an MCU or gateway is in play which deals with those solution features.<= /span>

Don= =92t really feel it=92s necessary. But don=92t feel very strongly.

=A0

Req 12 = fine

= =A0

Req 13 = Is anywhere here advocating switching??? =A0Can we please rid ourselves from concepts 10+ years out of date?

Maybe I=92m not clear on what you mean, since as you know some current systems use switching rather than transcoding. But, if you mean thi= s is an unnecessary requirement, and multipoint is understood, I don=92t mind removing the reqmt.

= =A0

Req 14 = =A0I don't understand this requirement. =A0Needs elaboration and/or an example

Okay, agree

=A0

Req 15 = What is "audio activity"? =A0And, suggest moving this requirement up to where the other audio requirements are=

Okay, will define audio activity. It=92s more about what video to show than audio, so suggest leaving where it is.

= =A0

Req 16,= third bullet, language is garbled. =A0Suggest to spell out those assorted requirements.

I thi= nk 3 is redundant with 4, so would like to remove

=A0

Req 17 = fine

= =A0

Stephan=

= =A0

= =A0

= =A0

= =A0

= =A0

= =A0

= =A0

= =A0

=A0<= /u>

= =A0

= =A0


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


--bcaec50160e311e52104a6534734-- From stephen.botzko@gmail.com Wed Jun 22 14:09:30 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C05211E80BD for ; Wed, 22 Jun 2011 14:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bcIcIjfidab for ; Wed, 22 Jun 2011 14:09:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A81911E8071 for ; Wed, 22 Jun 2011 14:09:28 -0700 (PDT) Received: by vws12 with SMTP id 12so1251996vws.31 for ; Wed, 22 Jun 2011 14:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FL7RmDJ9i1Cp3wQFy3TyfDZHu1xVSsi4+p3mR5U3x/I=; b=KK5AL1Sgb7JEbiQ8H1LfJodFFWon2F0MiA3fnoWsPuzMJ9X1KRdtLgjn+wTYDKY+pm wpA8lSWm78F26z6Mw3v/Oevxo3VEBzn/d6yDKIKQDPk7cTCM5G38yHO+1dMUmjGiwP06 jYnl2yYsxTgL+3ODPX0bAQnFvhyQEfLCcs/dU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Gawez/RPSTGI0KYbNOe6mDDUF7K/2ZZfRh4QETlxwczrAAJWvAdRs559lm199pK7LA BsdhgtzsGOhQOsAk5krBGlLFld6lB/ve4vD8q8Ru55XZuQo60FIhiVcMj33hh1TgqQgV 8ys6TARww23y2wwsQFyfW4h9LaQWrAKiCKtHU= MIME-Version: 1.0 Received: by 10.52.98.5 with SMTP id ee5mr1719439vdb.200.1308776967424; Wed, 22 Jun 2011 14:09:27 -0700 (PDT) Received: by 10.52.188.166 with HTTP; Wed, 22 Jun 2011 14:09:27 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC660D@xmb-sjc-221.amer.cisco.com> Date: Wed, 22 Jun 2011 17:09:27 -0400 Message-ID: From: Stephen Botzko To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=20cf307f34a63bcb6604a653622e Cc: clue@ietf.org Subject: Re: [clue] Stephan's comments on Requirements-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 21:09:30 -0000 --20cf307f34a63bcb6604a653622e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable one added comment, in-line Stephen Botzko On Wed, Jun 22, 2011 at 5:01 PM, Stephen Botzko w= rote: > HI Stephan - > > To clarify the 3b comment: For me statements like "The solution MUST > enable individual audio streams to be rendered in any desired spatial > position" do not put *any* requirements on the renderer. Req 3b says the > solution must *enable* receivers to do this (e.g., provide any needed > information). But it does not say that receivers have to do anything. S= o I > see no reason to spend time rewording it. > > Meant to add that Ericsson's mobile use case includes putting audio strea= ms from each source in fixed spatial positions, completely independently of whether there exists an associated video stream. The idea is that on a small mobile screen there is no need to align the audio and the video in space (and this is impossible with earphones and a handheld display anyway). But they do see value in spatial audio, in order to make it easie= r to distinguish voices, etc. So the absence of "camera" in this requirement was quite intentional. > On Req 7: I think I already posted a comment on requirement 7, suggestin= g > that this might have been part of a larger requirement on the need to ena= ble > display "at the proper size at the apparent distance". That is, > telepresence systems today can display people at their true size, and I > think there is a requirement to provide the appropriate scale information > for that. This larger requirement has possibly gotten lost, if so we sho= uld > circle back and re-capture it. > > It does look like a no-op as currently drafted - not because it touches o= n > rendering, but because I cannot think of any way to prevent different siz= e > displays from working, no matter what you do in the protocol. > > Regards > Stephen Botzko > > On Wed, Jun 22, 2011 at 4:21 PM, Allyn Romanow (allyn) w= rote: > >> Hi Stephan,**** >> >> Thanks for the great comments=85 for finding the time to go over the doc >> carefully-**** >> >> ** ** >> >> These are roughly from both Steve and myself.**** >> >> ** ** >> >> Allyn**** >> >> ** ** >> >> ** ** >> >> *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Stephan Wenger >> *Sent:* Monday, June 20, 2011 7:48 AM >> *To:* clue@ietf.org >> *Subject:* [clue] Stephan's comments on Requirements-03**** >> >> ** ** >> >> Hi,**** >> >> Due to other commitments, I have not followed the mailing list in detail= . >> Some of my comments may be duplicates; apologies in advance for that.**= * >> * >> >> Overall, this draft is better than the previous ones. However, there ar= e >> still a number of issues that I would like to raise.**** >> >> ** ** >> >> Req.1 "preservation order"??? What is this? Needs to be defined=85**** >> >> It=92s a typo =96 It was meant to be allowing the preservation of order = of >> images =96 does that make more sense to you? There follows a simple exam= ple in >> case it is not clear.**** >> >> ** ** >> >> Req.1c "aspect ratio" -> "picture aspect ratio", to distinguish from pix= el >> aspect ratio (both terms are common in video compression)**** >> >> 1c was removed.**** >> >> ** ** >> >> Req.1d "as described in the use cases": I don't like this type of cross >> reference, but have not had time to come up with a good solution.**** >> >> Agree. How is this modest change?**** >> >> The solution MUST support a means to communicate information allowing >> multi-view.**** >> >> Use case virtual space (multi-view).**** >> >> ** ** >> >> ** ** >> >> Req.2a "order of audio" -> "spatial order of audio"**** >> >> ok**** >> >> Req.2b MUST for the 3.0? Suggest "SHOULD". Also suggest "SHOULD 5.1", = as >> 5.1, while not common in today's systems, has appeared on at least one >> Telepresence roadmap I'm aware of.**** >> >> ** ** >> >> Let=92s discuss**** >> >> ** ** >> >> Req.2c Personally, I don't care about binaural support either way; >> however, MUST NOT seems wrong here. I think requirements should be >> expressed positively, with the appropriate level of mandation. So why n= ot >> "MAY" support binaural? Or "SHOULD"?**** >> >> Yes =96 this whole issue is under discussion.**** >> >> ** ** >> >> Req 3a fine with me as written. However, have you thought about the >> implications when considering centralized mixing? In order to fulfill t= he >> use cases behind the requirements, the mixer needs to be aware of both >> capture info and rendering info=85 Not an issue for me, but there may b= e IPR >> implications, and I would prefer to see a "SHOULD" level of mandation fo= r >> the centralized audio mixing use case (only).**** >> >> I don=92t see this, let=92s discuss**** >> >> ** ** >> >> Req. 3b this requirement needs to be rephrased. We should not put >> requirements on the renderer. "The solution MUST enable individual audi= o >> streams that have no camera position associated with"? Or something to = this >> extent?**** >> >> Yes, I agree with you. Steve suggests we discuss further.**** >> >> ** ** >> >> Req 4. Convert edt. note into regular text; it contains helpful info.**= * >> * >> >> done**** >> >> ** ** >> >> Req. 5 fine**** >> >> We can remove this now that the editor=92s note in 4 mentions the zero c= ase, >> right?**** >> >> ** ** >> >> Req 6 aspect ratio -> picture aspect ratio. Or do you also want to worr= y >> about pixel aspect ratios? Now that would be fun for the implementers := -) >> **** >> >> ** ** >> >> Req 7 fine, but since we should not specify rendering, this requirement = is >> a No-Op, right?**** >> >> Steve would like to discuss**** >> >> ** ** >> >> Req 8 fine**** >> >> ** ** >> >> Req 9 fine**** >> >> ** ** >> >> Req 10 needs IMO to be more general. "different bit rates" -> "endpoin= ts >> with different connectivity, i.e. in terms of bitrate, packet loss rate,= and >> other connectivity aspects" **** >> >> Ok. Would prefer a specific list rather than broad phrase open to >> interpretation.**** >> >> ** ** >> >> Req 11 fine. Perhaps add a note indicating that, obviously, dumb >> endpoints cannot take advantage of solution features unless an MCU or >> gateway is in play which deals with those solution features.**** >> >> Don=92t really feel it=92s necessary. But don=92t feel very strongly.***= * >> >> ** ** >> >> Req 12 fine**** >> >> ** ** >> >> Req 13 Is anywhere here advocating switching??? Can we please rid >> ourselves from concepts 10+ years out of date?**** >> >> Maybe I=92m not clear on what you mean, since as you know some current >> systems use switching rather than transcoding. But, if you mean this is = an >> unnecessary requirement, and multipoint is understood, I don=92t mind re= moving >> the reqmt.**** >> >> ** ** >> >> Req 14 I don't understand this requirement. Needs elaboration and/or a= n >> example**** >> >> Okay, agree**** >> >> ** ** >> >> Req 15 What is "audio activity"? And, suggest moving this requirement u= p >> to where the other audio requirements are**** >> >> Okay, will define audio activity. It=92s more about what video to show t= han >> audio, so suggest leaving where it is.**** >> >> ** ** >> >> Req 16, third bullet, language is garbled. Suggest to spell out those >> assorted requirements.**** >> >> I think 3 is redundant with 4, so would like to remove**** >> >> ** ** >> >> Req 17 fine**** >> >> ** ** >> >> Stephan**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> **** >> >> ** ** >> >> ** ** >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > --20cf307f34a63bcb6604a653622e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable one added comment, in-line

Stephen Botzko

On Wed, Jun 22, 2011 at 5:01 PM, Stephen Botzko &= lt;stephen.botzko@gmail.com= > wrote:
HI Stephan -

To cl= arify the 3b comment:=A0 For me statements like "The solution MUST ena= ble individual audio streams to be rendered in any desired spatial position" do not put any requirements = on the renderer.=A0 Req 3b says the solution must enable receivers t= o do this (e.g., provide any needed information).=A0 But it does not say th= at receivers have to do anything.=A0 So I see no reason to spend time rewor= ding it.

Meant to add that Ericsson's mobile use ca= se includes putting audio streams from each source in fixed spatial positio= ns, completely independently of whether there exists an associated video st= ream.=A0 The idea is that on a small mobile screen there is no need to alig= n the audio and the video in space (and this is impossible with earphones a= nd a handheld display anyway).=A0 But they do see value in spatial audio, i= n order to make it easier to distinguish voices, etc.=A0 So the absence of = "camera" in this requirement was quite intentional.
=A0
On Req 7:=A0 I think I already = posted a comment on requirement 7, suggesting that this might have been par= t of a larger requirement on the need to enable display "at the proper= size at the apparent distance".=A0 That is, telepresence systems toda= y can display people at their true size, and I think there is a requirement= to provide the appropriate scale information for that.=A0 This larger requ= irement has possibly gotten lost, if so we should circle back and re-captur= e it.

It does look like a no-op as currently drafted - not because it touches= on rendering, but because I cannot think of any way to prevent different s= ize displays from working, no matter what you do in the protocol.
Regards
Stephen Botzko

<= /div>
On Wed, Jun 22, 2011 at 4:21 PM, Allyn Romanow (ally= n) <allyn@cisco.com> wrote:

Hi St= ephan,

Thank= s for the great comments=85 for finding the time to go over the doc carefully-

=A0

These= are roughly from both Steve and myself.

=A0

Allyn=

=A0

=A0

From:= clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Monday, June 20, 2011 7:48 AM
To: clue@ietf.org=
Subject: [clue] Stephan's comments on Requirements-03<= /u>

=A0

Hi,<= /u>

Due to = other commitments, I have not followed the mailing list in detail. =A0Some of my comments may be duplicates; apologies in advance for that.

Overall= , this draft is better than the previous ones. =A0However, there are still a number of issues that I would like to raise.<= u>

= =A0

Req.1 &= quot;preservation order"??? =A0What is this? =A0Needs to be defined=85

It=92s a typo =96 It was meant to be allowing the preservation of order of images =96 does that make more sense to you? There follows a simple example in case it is not clear.

=A0

Req.1c = "aspect ratio" -> "picture aspect ratio", to distinguish from pixel aspect ratio (both terms are common = in video compression)

1c was removed.

=A0

Req.1d = "as described in the use cases": I don't like this type of cross reference, but have not had time to come up with a good solution.

Agree. How is this modest change?

The solution MUST support a means to communicate information allowing multi-view.

Use case virtual space (multi-view).

=A0

= =A0

Req.2a = "order of audio" -> "spatial order of audio"

ok

Req.2b = MUST for the 3.0? =A0Suggest "SHOULD". =A0Also suggest "SHOULD 5.1", as 5.1, while not common in today&#= 39;s systems, has appeared on at least one Telepresence roadmap I'm aware of= .

=A0

Let=92s discuss

=A0

Req.2c = Personally, I don't care about binaural support either way; however, MUST NOT seems wrong here. =A0I think requirements should be expressed positively, with the appropriate level of mandation. =A0So why no= t "MAY" support binaural? =A0Or "SHOULD"?

Yes =96 this whole issue is under discussion.

=A0

Req 3a = fine with me as written. =A0However, have you thought about the implications when considering centralized mixing? =A0In order to fulfill the use cases behind the requirements, the mixer needs to be aware = of both capture info and rendering info=85 =A0Not an issue for me, but there may be IPR implications, and I would prefer to see a "SHOULD&quo= t; level of mandation for the centralized audio mixing use case (only).=

I don=92t see this, let=92s discuss

=A0

Req. 3b= this requirement needs to be rephrased. =A0We should not put requirements on the renderer. =A0"The solution MUST enable individual audio streams that have no camera position associated with"= ? =A0Or something to this extent?

Yes, I agree with you. Steve suggests we discuss further.

= =A0

Req 4. = =A0Convert edt. note into regular text; it contains helpful info.

done

= =A0

Req. 5 = fine

We ca= n remove this now that the editor=92s note in 4 mentions the zero case, right?

= =A0

Req 6 a= spect ratio -> picture aspect ratio. =A0Or do you also want to worry about pixel aspect ratios? =A0Now that would be fun for the implementers :-)

= =A0

Req 7 f= ine, but since we should not specify rendering, this requirement is a No-Op, right?

Steve would like to discuss

= =A0

Req 8 f= ine

= =A0

Req 9 f= ine

= =A0

Req 10 = needs IMO to be more general. =A0"different bit rates" =A0-> "endpoints with different connectivity, i.e. in terms of bitrate, packet loss rate, and other connectivity aspects" = =A0

Ok. Would prefer a specific list rather than broad phrase open to interpretation.

= =A0

Req 11 = fine. =A0Perhaps add a note indicating that, obviously, dumb endpoints cannot take advantage of solution features unless an MCU or gateway is in play which deals with those solution features.<= /span>

Don= =92t really feel it=92s necessary. But don=92t feel very strongly.

=A0

Req 12 = fine

= =A0

Req 13 = Is anywhere here advocating switching??? =A0Can we please rid ourselves from concepts 10+ years out of date?

Maybe I=92m not clear on what you mean, since as you know some current systems use switching rather than transcoding. But, if you mean thi= s is an unnecessary requirement, and multipoint is understood, I don=92t mind removing the reqmt.

= =A0

Req 14 = =A0I don't understand this requirement. =A0Needs elaboration and/or an example

Okay, agree

=A0

Req 15 = What is "audio activity"? =A0And, suggest moving this requirement up to where the other audio requirements are=

Okay, will define audio activity. It=92s more about what video to show than audio, so suggest leaving where it is.

= =A0

Req 16,= third bullet, language is garbled. =A0Suggest to spell out those assorted requirements.

I thi= nk 3 is redundant with 4, so would like to remove

=A0

Req 17 = fine

= =A0

Stephan=

= =A0

= =A0

= =A0

= =A0

= =A0

= =A0

= =A0

= =A0

=A0<= /u>

= =A0

= =A0


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



--20cf307f34a63bcb6604a653622e-- From eckelcu@cisco.com Wed Jun 22 14:31:51 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC0921F84E6 for ; Wed, 22 Jun 2011 14:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.482 X-Spam-Level: X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrJN4SMP0xJX for ; Wed, 22 Jun 2011 14:31:50 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0F18421F84E5 for ; Wed, 22 Jun 2011 14:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=12351; q=dns/txt; s=iport; t=1308778309; x=1309987909; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ONeyFIAjpmTLw7r1UG0ImDSCp3FzYZgTkk276pHxVlY=; b=e02P30q+ak6x/aaLp5HLKmGaqNdmijdZYc5F6HBRVIlWptjjWh6nN4/N lz9GtTy99MfEWQmP32RyfMOp7AGjgSugcj2Yol9XV84On77MhrHmRWfQ2 cPeDqFAY3slk7LIC0298bL4Vok2QB0GGBe/ZlYPxN4WBn5nh9W1Re6/9H g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAHheAk6rRDoJ/2dsb2JhbABTl36PGHerYp40hi0EhyWPM4s+ X-IronPort-AV: E=Sophos;i="4.65,408,1304294400"; d="scan'208";a="344428545" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2011 21:31:49 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5MLVnBQ026821; Wed, 22 Jun 2011 21:31:49 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 14:31:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jun 2011 14:31:48 -0700 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB559A7CE@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Layout negotiation Thread-Index: Acww8sQlRUBW5WOSS4K6jxoq1LlJrwABhLoAAAEsT+AABQroMAAAeBpQAAPQcLA= References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A79A@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC65CC@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB559A7CE@ESESSCMS0356.eemea.ericsson.se> From: "Charles Eckel (eckelcu)" To: "Christer Holmberg" , "Allyn Romanow (allyn)" , "Stephen Botzko" X-OriginalArrivalTime: 22 Jun 2011 21:31:49.0547 (UTC) FILETIME=[CB8C07B0:01CC3123] Cc: clue@ietf.org Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 21:31:51 -0000 Here is the current definition of layout from = http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt: Layout: How rendered media streams are spatially arranged with respect to each other on a single screen/mono audio telepresence endpoint, and how rendered media streams are arranged with respect to each other on a multiple screen/speaker telepresence endpoint. Note that audio as well as video is encompassed by the term layout--in other words, included is the placement of audio streams on speakers as well as video streams on video screens. Edit. note: this is on the RENDERER side. This definition is from the perspective of the physical speakers and = displays on the endpoint. I am thinking more about how the available = media streams are encoded and transmitted as some subset of the = individual media streams, or as some composition of the individual media = streams. It is still up to the receiving endpoint to decide the layout = of these media streams with respect to its physically speakers and = displays.=20 Cheers, Charles > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, June 22, 2011 12:44 PM > To: Allyn Romanow (allyn); Charles Eckel (eckelcu); Stephen Botzko > Cc: clue@ietf.org > Subject: RE: [clue] Layout negotiation >=20 >=20 > Hi Allyn, >=20 > >Huh? > >Perhaps one of you could summarize where we are in the > >conversation, and what is agreed upon so far? >=20 > I think we're having more or less a definition discussion. >=20 > >One thing to remind you of is that we have agreed that CLUE > >does not specify how rendering should be done, that is up to > >the receiver. The sender (and receiver) can send info, but > >CLUE isn't specifying what the receiver (renderer) does with > >it, meaning how it does the rendering, what choices it > >makes. I thought Charles' original email may have been > >suggesting specifying rendering, wasn't really sure. >=20 > I think what charles is talking is about being able to indicate: >=20 > 1. Which streams are used to create an output stream > 2. How does the output stream look like >=20 > It seems like people consider that being part of LAYOUT. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Wednesday, June 22, 2011 10:03 AM > > To: Christer Holmberg; Stephen Botzko > > Cc: clue@ietf.org > > Subject: Re: [clue] Layout negotiation > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Wednesday, June 22, 2011 9:46 AM > > > To: Stephen Botzko > > > Cc: Charles Eckel (eckelcu); clue@ietf.org > > > Subject: RE: [clue] Layout negotiation > > > > > > > > > Hi, > > > > > > >>>I think I was the one that brought up layouts originally. I was > > > >>>more concerned with video layouts than audio layouts. > > > >>>Currently, the requirements draft seems to focus more on audio > > > >>>layout/spatial audio. > > > >>>Requirements 3 and 16 both deal with parts of this. I feel = there > > > >>>needs to be more clear requirements on the ability for the to > > > >>>represent the potential layouts of the audio/video can that be > > > >>>offered. For example, I have 3 camera and 3 mics. I can = provide: > > > >>>1) 3 individual video each with corresponding audio > > > >>>2) 1 active speaker only switched video with mixed audio > > > >>>3) 1 composed video including active speaker and 'n' > > > >>>non-active speakers (where 'n' is may be all or some fixed > > > >>>limit) and mixed audio > > > >> > > > >> > > > >>>>I actually think that your examples, as written, are different > > > >>>>RENDERING TYPES, because they only > > > talk about mixing and composition. > > > >> > > > >>>Confirmation that I am clueless about rendering types. > > > > > > > > > > > >>A value identifying the rendering algorithm used to > > produce a media stream sent towards the client. > > > > > > >In a client-to-client call this is backwards. "Capture" = describes > > > >the stream production process > > > better, rendering is that the client does with the > > > >streams it receives. Anyway, changing "Rendering type" to > > "rendering algorithm" doesn't help me much. > > > > > > It's probably easier to understand rendering type if one > > knows what we mean by render. > > > > > > Our proposed definition is: > > > > > > "Rendering:=A0=A0 Composing a media signal from one or more > > media signals > > > using a specific composition algorithm, often according to > > a specific spatial model/layout." > > > > > > So, the "rendering type" is a value associated with that = algorithm. > > > > > > So, I think the important thing in our "rendering" > > definition is that > > > an output media signal is generated. > > > > > > Now, if people think that our usage of "rendering" is confusing, = we > > > can of course use other wording instead. > > > > This works for me. It may be useful to expand with typical > > audio and video examples, such as mixing multiple audio > > stream inputs into a single audio stream output, or composing > > multiple video stream inputs into a single video stream output. > > > > Cheers, > > Charles > > > > > > > > > > > > > > > > >>>In my opinion, a LAYOUT TYPE is a description of how > > sources are placed in a virtual room. > > > >>> > > > >>>For me layout is about composition. Layouts do not necessarily > > > >>>create a virtual room experience, > > > particularly in multipoint calls. > > > >> > > > >> > > > >>Ok, so we need to make sure we have a common > > understanding of layout > > > >>then :) > > > >> > > > >>So, just to clarify, do you think that source selection is = layout? > > > > > > > > > > > >I generally separate them, though they are related. For > > instance, in > > > >a traditional Video MCU you can > > > often choose a source-independent layout (2x2 array > > > >of equal size windows, a 1+5 layout, where the "1" window > > is bigger > > > >than the others, and at the top > > > left, etc). Then you can control the mapping of > > > >sources to windows separately. Not sure this is the only way to > > > >partition it, just the way I tend to > > > use. > > > > > > Ok. So, first, I guess there is "source-dependent layout" > > and "source-independent layout". > > > > > > Second, there is an algorithm that creates the output > > stream, using the layout as input. > > > > > > Of course, in this case one might not need to be able to = explicitly > > > indicate the algorithm - if it's enough to indicate the layout. > > > > > > > > > > > > > > > >I see four distinct elements in your mobile binaural case > > - (a) the > > > >sources chosen for placement, > > > > > > Correct. That's "source selection". > > > > > > >(b) the set of placements used in creating a sound stage, > > > > > > > >(c) the placement used for each particular source at the > > moment, and > > > >(d) whether the outbound audio is binaural or not. > > > >I'd personally call (b) the audio layout, though you can > > equally well call (b+c) the audio layout. > > > > > > Ok. So, that would be a "source-dependent layout", I guess? > > > > > > Then, (d) would be the actual rendering algorithm, using > > the layout as input. > > > > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >If the receiving endpoint wants > > to control the layout itself, > > > >it goes with option 1. If it has limited > > > >resources/bandwidth/screens/etc > > it may prefer option 2 or 3. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On Behalf > > > > Of Christer Holmberg > > > > > Sent: Tuesday, June 21, 2011 3:52 AM > > > > > To: clue@ietf.org > > > > > Subject: [clue] Layout negotiation > > > > > > > > > > Hi, > > > > > > > > > > A while ago there were some > > discussions about having requirements to > > > > negotiate the layout type, and at > > > > > least according to Stephen B > > it was within the scope of the work. > > > > > > > > > > "The ability to > > negotiate an audio or video layout > > > > is clearly > > > > within scope, and has general > > > > > value it the group wants to > > take it on. > > > > > For instance, if you > > combine video switching of multiple > > > > sources with audio > > > > > mixing/transcoding, then the > > receiver is responsible > > > > > for the video layout > > but has no control over the > > > > audio layout. > > > > In that case, there are > > > > > advantages to allowing the > > receiver to tell the > > > > > central audio mixer > > where it wants the sources placed on the > > > > sound stage. I have no objection > > > > > in principle to adding that kind of > > > > > negotiation to the > > requirements, though I think the group > > > > should consider the impact on the > > > > > schedule." > > > > > > > > > > However, I haven't seen any > > input after that. > > > > > > > > > > My idea would be that it is > > very similar to the rendering type: CLUE > > > > defines a mechanism to negotiate > > > > > the layout type, but doesn't > > define specific types (instead an IANA > > > > registry would be created for > > > > > that). So, I don't think it > > would have any significant impact on our > > > > schedule. > > > > > > > > > > Whether it, in addition to > > negotiation a layout type (which > > > > specifies > > > > the source locations), should be > > > > > possible for the user to > > more explicit place individual sources, as > > > > mentioned by Stephen, can be > > > > > discussed. However, that > > would probably require a little > > > > more work, so > > > > at least I would be happy with > > > > > a simple layout type > > negotiation at this point. > > > > > > > > > > So, would people be ok with > > such requirement? > > > > > > > > > > (Another alternative would > > be to "embed" the layout type into the > > > > rendering type, but I think that > > > > > would be very clumsy. > > Because, in that case you would need to define > > > > mulitple types for the same > > > > > rendering, but with > > different layouts.) > > > > > > > > > > Regards, > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > From allyn@cisco.com Wed Jun 22 17:09:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F98E11E809C for ; Wed, 22 Jun 2011 17:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKWr-r8AJDtZ for ; Wed, 22 Jun 2011 17:09:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 5360211E8098 for ; Wed, 22 Jun 2011 17:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=8434; q=dns/txt; s=iport; t=1308787779; x=1309997379; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=zM9G0RluuhOsXsGOXSYkSlTq/rNqKxH41oQVvZ1x96s=; b=LLlPc662t3CyoJGmbgdZ4LBhG9omTscMTOWdGUmDELHcldOmmshg5au0 w7YclA+ahf51rXo1pevmCdvC9wkgN/lAqaRdn0UMGcW0VN9a4ptwdJnjO TtvK6rv9qJrozvuS9CDNq2nZL1SRWPrUvu/3NXxbKWxa2R8UAbxvFQthV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAFKDAk6rRDoI/2dsb2JhbABTglGVM48Yd6tRni+GLQSHJY8ziz4 X-IronPort-AV: E=Sophos;i="4.65,409,1304294400"; d="scan'208,217";a="719966769" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 23 Jun 2011 00:09:38 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5N09bVk025588; Thu, 23 Jun 2011 00:09:37 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 17:09:25 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3139.CFA2A83F" Date: Wed, 22 Jun 2011 17:09:26 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6770@xmb-sjc-221.amer.cisco.com> In-Reply-To: <00fd01cc30dc$2496e930$6dc4bb90$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: use case and requirement for multi-view Thread-Index: Acwwj6m4l9xOCH4NSAO5KaTj+QfrLwATEhGgABdIWFA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6357@xmb-sjc-221.amer.cisco.com> <00fd01cc30dc$2496e930$6dc4bb90$%roni@huawei.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Gorzynski, Mark E (The Right One)" X-OriginalArrivalTime: 23 Jun 2011 00:09:25.0671 (UTC) FILETIME=[CFD60B70:01CC3139] Cc: clue@ietf.org Subject: Re: [clue] use case and requirement for multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 00:09:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3139.CFA2A83F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, =20 The intention of the use case was for multi-view, multiple cameras on the same scene. If the material is to be put in the document, I think it should be a separate use case, not a subset of others. =20 In terms of including multi-view in the requirements, I'm fine to withdraw it and it can always be added later when someone wants it. If there is not a particular champion for multi-view who wants it now, then I think we can safely wait till later. =20 Regards, Allyn =20 =20 From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: Wednesday, June 22, 2011 5:59 AM To: Allyn Romanow (allyn) Cc: clue@ietf.org Subject: RE: use case for multi-view =20 Hi Allyn, I sis not add it, I sent the following question to the list on May 17th and did not get any response yet =20 "Hi Mark, I am trying to see how to fit this case in the use-cases draft. When I ignore the term "virtual space" and look at the description it talks about describing the view point of each cameras that may overlap and allowing the receivers to select the view they want. I see some resemblance to the education usage described.=20 Will it make sense to mentio vide different view in the point to point symmetric or asymmetric case which has a case with a PTZ camera." =20 =20 Roni Even =20 =20 From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 Sent: Wednesday, June 22, 2011 6:51 AM To: Roni Even Cc: clue@ietf.org =20 Hi Roni, I thought Mark's use case for multi-view was added to the Use Case doc, but I couldn't find it there? Is it just not added yet or is there some issue with it? =20 Thanks much ------_=_NextPart_001_01CC3139.CFA2A83F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

The intention of the use = case was for multi-view, multiple cameras on the same = scene.

If the material is to be put in the document, I = think it should be a separate use case, not a subset of = others.

 

In terms of including = multi-view in the requirements, I’m fine to withdraw it and it can = always be added later when someone wants it. If there is not a = particular champion for multi-view who wants it now, then I think we can = safely wait till later.

 

Regards,

Allyn

 

 

From:= = Roni Even [mailto:Even.roni@huawei.com]
Sent: Wednesday, June = 22, 2011 5:59 AM
To: Allyn Romanow (allyn)
Cc: = clue@ietf.org
Subject: RE: use case for = multi-view

 

Hi Allyn,

I sis not add it, I sent = the following question to the list on May 17th and did not get any = response yet

 

"Hi = Mark,

I am trying to see how to fit this case in the = use-cases draft. When I ignore the term "virtual space" and = look at the description it talks about describing the view point of each = cameras that may overlap and allowing the receivers to select the view = they want. I see some resemblance to the education usage described. =

Will it make sense to mentio vide different view = in the point to point symmetric or asymmetric case which has a case with = a PTZ camera."

 

 

Roni = Even

 

 

From:= = Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent: = Wednesday, June 22, 2011 6:51 AM
To: Roni Even
Cc: = clue@ietf.org

 

Hi = Roni,

I thought Mark’s = use case for multi-view was added to the Use Case doc, but I = couldn’t find it there? Is it just not added yet or is there some = issue with it?

 

Thanks = much

------_=_NextPart_001_01CC3139.CFA2A83F-- From stewe@stewe.org Wed Jun 22 20:34:20 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F03F11E80C5 for ; Wed, 22 Jun 2011 20:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSczCs6ewv6Z for ; Wed, 22 Jun 2011 20:34:19 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 626BA11E80BD for ; Wed, 22 Jun 2011 20:34:18 -0700 (PDT) Received: from [172.16.0.14] (unverified [12.39.47.2]) by stewe.org (SurgeMail 3.9e) with ESMTP id 5096-1743317 for ; Thu, 23 Jun 2011 05:34:16 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 22 Jun 2011 20:34:08 -0700 From: Stephan Wenger To: "clue@ietf.org" Message-ID: Thread-Topic: Cannot make call tomorrow Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3391619656_7272243" X-Originating-IP: 12.39.47.2 X-Authenticated-User: stewe@stewe.org Subject: [clue] Cannot make call tomorrow X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 03:34:20 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3391619656_7272243 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Folks, I will be on a plane tomorrow during our call. Sorry. Stephan --B_3391619656_7272243 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Folks,
I will be o= n a plane tomorrow during our call.  Sorry.
Stephan
--B_3391619656_7272243-- From allyn@cisco.com Wed Jun 22 21:12:25 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9672F11E80C7 for ; Wed, 22 Jun 2011 21:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZHdVDbMP3y2 for ; Wed, 22 Jun 2011 21:12:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4909011E80C2 for ; Wed, 22 Jun 2011 21:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=13533; q=dns/txt; s=iport; t=1308802344; x=1310011944; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=EU9wu2dcdFd/qfHl+B90GKdEf0rfa7V03WnRIRbjTKM=; b=BDCwFrGO3gfgLLwjBrciEFvCdTrOVKOclI8Vy+qE1tKGGqaz79PFVjxk bkhrO6rRWVAZw3kxUXeLm0kT+Br4RLPyDh+RXEkJNxXIyY3uGYB1j5VNW +6E4fOmjJ+KJv4s82tMLMT7tXdhEiA2HGj8S+eHY7aEHrh0g6EYSea8U1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAEi8Ak6rRDoJ/2dsb2JhbABTmASPG3eIc6Nonj2GLQSHJo86iz8 X-IronPort-AV: E=Sophos;i="4.65,410,1304294400"; d="scan'208";a="467659297" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2011 04:12:23 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5N4CNlE027905; Thu, 23 Jun 2011 04:12:23 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 21:12:23 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jun 2011 21:12:21 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC67D8@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Layout negotiation Thread-Index: Acww8sQlRUBW5WOSS4K6jxoq1LlJrwABhLoAAAEsT+AABQroMAAAeBpQAAPQcLAADh66IA== References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A79A@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC65CC@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB559A7CE@ESESSCMS0356.eemea.ericsson.se> From: "Allyn Romanow (allyn)" To: "Charles Eckel (eckelcu)" , "Christer Holmberg" , "Stephen Botzko" X-OriginalArrivalTime: 23 Jun 2011 04:12:23.0840 (UTC) FILETIME=[C11A1A00:01CC315B] Cc: clue@ietf.org Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 04:12:25 -0000 Charles, What does your note have to do with the requirements? It seems to me you're out there designing a solution. Could you save it = for the design discussion? Or, perhaps you could state succinctly what statement you want added, = subtracted, or modified in the requirements? Thanks, Allyn > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Wednesday, June 22, 2011 2:32 PM > To: Christer Holmberg; Allyn Romanow (allyn); Stephen Botzko > Cc: clue@ietf.org > Subject: RE: [clue] Layout negotiation >=20 > Here is the current definition of layout from > http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt: >=20 > Layout: How rendered media streams are spatially arranged with > respect to each other on a single screen/mono audio > telepresence > endpoint, and how rendered media streams are arranged with > respect to each other on a multiple screen/speaker = telepresence > endpoint. Note that audio as well as video is encompassed by > the term layout--in other words, included is the placement of > audio streams on speakers as well as video streams on video > screens. Edit. note: this is on the RENDERER side. >=20 > This definition is from the perspective of the physical speakers and > displays on the endpoint. I am thinking more about how the available > media streams are encoded and transmitted as some subset of the > individual media streams, or as some composition of the individual > media streams. It is still up to the receiving endpoint to decide the > layout of these media streams with respect to its physically speakers > and displays. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Wednesday, June 22, 2011 12:44 PM > > To: Allyn Romanow (allyn); Charles Eckel (eckelcu); Stephen Botzko > > Cc: clue@ietf.org > > Subject: RE: [clue] Layout negotiation > > > > > > Hi Allyn, > > > > >Huh? > > >Perhaps one of you could summarize where we are in the > > >conversation, and what is agreed upon so far? > > > > I think we're having more or less a definition discussion. > > > > >One thing to remind you of is that we have agreed that CLUE > > >does not specify how rendering should be done, that is up to > > >the receiver. The sender (and receiver) can send info, but > > >CLUE isn't specifying what the receiver (renderer) does with > > >it, meaning how it does the rendering, what choices it > > >makes. I thought Charles' original email may have been > > >suggesting specifying rendering, wasn't really sure. > > > > I think what charles is talking is about being able to indicate: > > > > 1. Which streams are used to create an output stream > > 2. How does the output stream look like > > > > It seems like people consider that being part of LAYOUT. > > > > Regards, > > > > Christer > > > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > Behalf Of Charles Eckel (eckelcu) > > > Sent: Wednesday, June 22, 2011 10:03 AM > > > To: Christer Holmberg; Stephen Botzko > > > Cc: clue@ietf.org > > > Subject: Re: [clue] Layout negotiation > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: Wednesday, June 22, 2011 9:46 AM > > > > To: Stephen Botzko > > > > Cc: Charles Eckel (eckelcu); clue@ietf.org > > > > Subject: RE: [clue] Layout negotiation > > > > > > > > > > > > Hi, > > > > > > > > >>>I think I was the one that brought up layouts originally. I > was > > > > >>>more concerned with video layouts than audio layouts. > > > > >>>Currently, the requirements draft seems to focus more on = audio > > > > >>>layout/spatial audio. > > > > >>>Requirements 3 and 16 both deal with parts of this. I feel > there > > > > >>>needs to be more clear requirements on the ability for the to > > > > >>>represent the potential layouts of the audio/video can that = be > > > > >>>offered. For example, I have 3 camera and 3 mics. I can > provide: > > > > >>>1) 3 individual video each with corresponding audio > > > > >>>2) 1 active speaker only switched video with mixed audio > > > > >>>3) 1 composed video including active speaker and 'n' > > > > >>>non-active speakers (where 'n' is may be all or some fixed > > > > >>>limit) and mixed audio > > > > >> > > > > >> > > > > >>>>I actually think that your examples, as written, are > different > > > > >>>>RENDERING TYPES, because they only > > > > talk about mixing and composition. > > > > >> > > > > >>>Confirmation that I am clueless about rendering types. > > > > > > > > > > > > > > >>A value identifying the rendering algorithm used to > > > produce a media stream sent towards the client. > > > > > > > > >In a client-to-client call this is backwards. "Capture" > describes > > > > >the stream production process > > > > better, rendering is that the client does with the > > > > >streams it receives. Anyway, changing "Rendering type" to > > > "rendering algorithm" doesn't help me much. > > > > > > > > It's probably easier to understand rendering type if one > > > knows what we mean by render. > > > > > > > > Our proposed definition is: > > > > > > > > "Rendering:=A0=A0 Composing a media signal from one or more > > > media signals > > > > using a specific composition algorithm, often according to > > > a specific spatial model/layout." > > > > > > > > So, the "rendering type" is a value associated with that > algorithm. > > > > > > > > So, I think the important thing in our "rendering" > > > definition is that > > > > an output media signal is generated. > > > > > > > > Now, if people think that our usage of "rendering" is confusing, > we > > > > can of course use other wording instead. > > > > > > This works for me. It may be useful to expand with typical > > > audio and video examples, such as mixing multiple audio > > > stream inputs into a single audio stream output, or composing > > > multiple video stream inputs into a single video stream output. > > > > > > Cheers, > > > Charles > > > > > > > > > > > > > > > > > > > > > > >>>In my opinion, a LAYOUT TYPE is a description of how > > > sources are placed in a virtual room. > > > > >>> > > > > >>>For me layout is about composition. Layouts do not = necessarily > > > > >>>create a virtual room experience, > > > > particularly in multipoint calls. > > > > >> > > > > >> > > > > >>Ok, so we need to make sure we have a common > > > understanding of layout > > > > >>then :) > > > > >> > > > > >>So, just to clarify, do you think that source selection is > layout? > > > > > > > > > > > > > > >I generally separate them, though they are related. For > > > instance, in > > > > >a traditional Video MCU you can > > > > often choose a source-independent layout (2x2 array > > > > >of equal size windows, a 1+5 layout, where the "1" window > > > is bigger > > > > >than the others, and at the top > > > > left, etc). Then you can control the mapping of > > > > >sources to windows separately. Not sure this is the only way = to > > > > >partition it, just the way I tend to > > > > use. > > > > > > > > Ok. So, first, I guess there is "source-dependent layout" > > > and "source-independent layout". > > > > > > > > Second, there is an algorithm that creates the output > > > stream, using the layout as input. > > > > > > > > Of course, in this case one might not need to be able to > explicitly > > > > indicate the algorithm - if it's enough to indicate the layout. > > > > > > > > > > > > > > > > > > > > >I see four distinct elements in your mobile binaural case > > > - (a) the > > > > >sources chosen for placement, > > > > > > > > Correct. That's "source selection". > > > > > > > > >(b) the set of placements used in creating a sound stage, > > > > > > > > > >(c) the placement used for each particular source at the > > > moment, and > > > > >(d) whether the outbound audio is binaural or not. > > > > >I'd personally call (b) the audio layout, though you can > > > equally well call (b+c) the audio layout. > > > > > > > > Ok. So, that would be a "source-dependent layout", I guess? > > > > > > > > Then, (d) would be the actual rendering algorithm, using > > > the layout as input. > > > > > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >If the receiving endpoint wants > > > to control the layout itself, > > > > >it goes with option 1. If it has > limited > > > > >resources/bandwidth/screens/etc > > > it may prefer option 2 or 3. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org] On Behalf > > > > > Of Christer Holmberg > > > > > > Sent: Tuesday, June 21, 2011 3:52 > AM > > > > > > To: clue@ietf.org > > > > > > Subject: [clue] Layout negotiation > > > > > > > > > > > > Hi, > > > > > > > > > > > > A while ago there were some > > > discussions about having requirements to > > > > > negotiate the layout type, and at > > > > > > least according to Stephen B > > > it was within the scope of the work. > > > > > > > > > > > > "The ability to > > > negotiate an audio or video layout > > > > > is clearly > > > > > within scope, and has general > > > > > > value it the group wants to > > > take it on. > > > > > > For instance, if you > > > combine video switching of multiple > > > > > sources with audio > > > > > > mixing/transcoding, then the > > > receiver is responsible > > > > > > for the video layout > > > but has no control over the > > > > > audio layout. > > > > > In that case, there are > > > > > > advantages to allowing the > > > receiver to tell the > > > > > > central audio mixer > > > where it wants the sources placed on the > > > > > sound stage. I have no objection > > > > > > in principle to adding that kind > of > > > > > > negotiation to the > > > requirements, though I think the group > > > > > should consider the impact on the > > > > > > schedule." > > > > > > > > > > > > However, I haven't seen any > > > input after that. > > > > > > > > > > > > My idea would be that it is > > > very similar to the rendering type: CLUE > > > > > defines a mechanism to negotiate > > > > > > the layout type, but doesn't > > > define specific types (instead an IANA > > > > > registry would be created for > > > > > > that). So, I don't think it > > > would have any significant impact on our > > > > > schedule. > > > > > > > > > > > > Whether it, in addition to > > > negotiation a layout type (which > > > > > specifies > > > > > the source locations), should be > > > > > > possible for the user to > > > more explicit place individual sources, as > > > > > mentioned by Stephen, can be > > > > > > discussed. However, that > > > would probably require a little > > > > > more work, so > > > > > at least I would be happy with > > > > > > a simple layout type > > > negotiation at this point. > > > > > > > > > > > > So, would people be ok with > > > such requirement? > > > > > > > > > > > > (Another alternative would > > > be to "embed" the layout type into the > > > > > rendering type, but I think that > > > > > > would be very clumsy. > > > Because, in that case you would need to define > > > > > mulitple types for the same > > > > > > rendering, but with > > > different layouts.) > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > From allyn@cisco.com Wed Jun 22 21:36:35 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358019E8047 for ; Wed, 22 Jun 2011 21:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPAtu7Q5NNVd for ; Wed, 22 Jun 2011 21:36:34 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 88B339E8042 for ; Wed, 22 Jun 2011 21:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=126954; q=dns/txt; s=iport; t=1308803793; x=1310013393; h=mime-version:subject:date:message-id:from:to; bh=YFA8GuUvUCvJABjQmjKd4Z0HMcOXruA9WYHRxU4U9Zs=; b=StVqrwwEYMK9ypfmCgi/jsvXYC0W+MCZ8dDjhw5n1E7TeXyGK8Mtiumw OJNYbApCN+jwSSXuq0elFhwQog+X97ctzjtMMka44d49pwzZ1IpYMLJfF mGg+2zWGEIIJHC+aBcBwXyKKkaD6/3ROL1xm381ZoVXWIACoDdPx4JEFJ o=; X-Files: CLUE Requirements interim june 2011.pptx : 89827 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB3CAk6rRDoH/2dsb2JhbABTglGkTnesQZ45hi0EhyaPOos/ X-IronPort-AV: E=Sophos;i="4.65,410,1304294400"; d="xml'?pptx'72,48,150?scan'72,48,150,48,72,208,145,150,217?rels'72,48,150,48,72,208,145,150,217?jpeg'72,48,150,48,72,208,145,150,217,145?png'72,48,150,48,72,208,145,150,217,145,150"; a="344695833" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 23 Jun 2011 04:36:33 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5N4aX4X024231; Thu, 23 Jun 2011 04:36:33 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 21:36:32 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC315F.207A1093" Date: Wed, 22 Jun 2011 21:36:30 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC67E4@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: slide deck for requirements draft discussion during interim meeting Thread-Index: AcwxXx+h4OeSeWLWQHO5ur/7/84UvA== From: "Allyn Romanow (allyn)" To: , "Paul Kyzivat (pkyzivat)" , "Mary Barnes" X-OriginalArrivalTime: 23 Jun 2011 04:36:32.0872 (UTC) FILETIME=[20CAD680:01CC315F] Subject: [clue] slide deck for requirements draft discussion during interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 04:36:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC315F.207A1093 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC315F.207A1093" ------_=_NextPart_002_01CC315F.207A1093 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I know I'm committing a heinous crime in wasting bandwidth, clogging mailboxes, and worse, by sending slides on the mailing list. Despite strong urging from the co-chairs to get my slides to them so they could post them for download before the meeting, I'm too late for them to do that in time for most of you to get them.=20 =20 While some of this last-minuteness is admittedly genetic, some of it also stems from the fact that the relevant mailing list comments continued through today. =20 Best, Allyn =20 =20 ------_=_NextPart_002_01CC315F.207A1093 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

I know I’m committing a heinous crime in = wasting bandwidth, clogging mailboxes, and worse, by sending slides on the = mailing list.

Despite strong urging from the co-chairs to get my = slides to them so they could post them for download before the meeting,  = I’m too late for them to do that in time for most of you to get them. =

 

While some of this last-minuteness is admittedly = genetic, some of it also stems from the fact that the relevant mailing list = comments continued through today.

 

Best,

Allyn

 

 

------_=_NextPart_002_01CC315F.207A1093-- ------_=_NextPart_001_01CC315F.207A1093 Content-Type: application/octet-stream; name="CLUE Requirements interim june 2011.pptx" Content-Transfer-Encoding: base64 Content-Description: CLUE Requirements interim june 2011.pptx Content-Disposition: attachment; filename="CLUE Requirements interim june 2011.pptx" UEsDBBQABgAIAAAAIQC4Cz63dAIAAKISAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE WMmS2jAQvacq/+DSNYUFk2SWFGYOWU5ZpmomH6DYDSixJZUlyPD3keVlNJTAYmyFCyCDXj91v17E /PaxyKMtlJJylqBZPEURsJRnlK0S9PPhy+QaRVIRlpGcM0jQDiS6Xbx+NX/YCZCR3s1kgtZKiQ8Y y3QNBZExF8D0N0teFkTpZbnCgqR/yArwxXR6iVPOFDA1URUGWsx/aAIlzSC6I6X6TgptBwuhsMz1 Q1m/vY81Ioo+1lsr6wkiQuQ0JUpzx1uW7dmd8OWSppDxdFNoa7EoQep38/Mijw34mwoU+zG4PB+D r2THN6rxRL24CsKmxvbyioPT9X/g9AmWZJOr6POjllCtWsFWe8KgRaW16vmR2DKuQN7XEnv6PBv7 DE/QXm79RqTS6ViLvl6MTslIv8b24tSweTu2a05OwXdnYVAVjruSCzm29Q7YKwqOhAvjj2FFIEyh HsYpTOn246R0TwRsXi8GC8jAeKmlydkwteMUBsMP/ZLGbXl9uAv8ve7I0TDn99OeKbAOTmEq+XNO jkb9W4C7U5svdKt27Ckhl3vdvWfsa0bNWO80s55cUyFbxTosHJ8rewZEW5uDs9sG0xOqvYwLQll7 iEPzshk12gHCWgzPAJuKZmZh93E6JMHROVmGjnHS1wHTy7FW0eCAQTWEZpBNhB4PoFQUOqEdipGh 2Rbn6WAGe4Ex6MeOX12rFPmVw73a5TD6RGNB97Gw4tW4o64fs3Mpo7txOgrmLEyknldMH8mEufZ5 xaqJUphL3ikMbs6SNVsKf4PcAjpgLx84xBnGH/3a7Eppyks4PSZtn652OwooNv8wLf4BAAD//wMA UEsDBBQABgAIAAAAIQBo+HShBQEAAOICAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLbSgMxEIbv Bd8hzH032yoi0mxvROidyPoAYzK7G90cSKbSvr2h4GFhLYK9nNM/X/LPerN3o3inlG3wCpZVDYK8 Dsb6XsFz+7C4BZEZvcExeFJwoAyb5vJi/UQjchnKg41ZFBWfFQzM8U7KrAdymKsQyZdKF5JDLmHq ZUT9hj3JVV3fyPRTA5qJptgaBWlrrkC0h1g2/0dbOmI0yCh1SLSIqZAltuUtosXUEyswQT+WdD52 VIUa5DzQ6rxAPOzci0c7zqB81arXSP1vQMu/A4Wus5rug9458jxjgpx2fDPFyDImymXsaPupH7o+ JxDtmbwhc9o0jPGTSE4us/kAAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2 bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9p wFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+ zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYA CAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzhI/B CsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3 wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE 88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nY yPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVz L19yZWxzL3NsaWRlMi54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9 e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8ii UDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2D eY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBN dHi9GwEAAB8DAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHOsksFOAjEQhu8m vsNm7raAxhhCgYOakOhF8AFqd9ht6HY2ncGwPr3lQFwSwAu3zkz6zZf+ncx2TSi+MbGnaGCoBlBg dFT6WBn4XL3ePUHBYmNpA0U00CHDbHp7M/nAYCVf4tq3XGRKZAO1SDvWml2NjWVFLcY8WVNqrOQy Vbq1bmMr1KPB4FGnPgOmR8xiURpIi/IeilXX5s3/s2m99g6fyW0bjHJiha4zKQUfNxlqU4VioLE+ CI1tCF2cO8+OlKPmMH+nMq9+2QmmaAPo046jazpGEuRl8CUeJAwopf/a3DsPVX7fc1rDa2rx3ujN drSVI69en3WvuGj2cE2z86EuBdsao/oi+dnQvNpnfTldffStp78AAAD//wMAUEsDBBQABgAIAAAA IQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHOEj8EKwjAQ RO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9p uN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7U pqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6o plZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3Jl bHMvc2xpZGU2LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wg eJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvo c457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTz jwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/ AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNy54bWwucmVsc4SPwQrCMBBE74L/EPZu Uj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO 6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQ fDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8A AAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlk ZTgueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59 eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0 IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TB KTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAA IAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU5LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8i CJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJ GA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhn uwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQ SwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTAueG1s LnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFi F7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRen DWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLq KGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEANG9vrHEBAAAcCQAAHwAIAXBw dC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAC8ls1qwzAMgO+DvUPwfXHc/46mvYxBD4OxdQ/gJmoaltjG8rr17WfSrk1L0C6ml4CU RP74FEeeLX7qKtqBxVKrlIk4YRGoTOelKlL2sXp+mLAInVS5rLSClO0B2WJ+fzd7g0o6/xJuS4OR r6IwZVvnzCPnmG2hlhhrA8rf2WhbS+dDW3Ajs09ZAO8lyYjbdg02v6gZLfOU2WXu11/tjV/5/9p6 sykzeNLZVw3KdSzBsSpz8AWlLcClrAnxkB3HnpTxbgjRD0lhLOCr1QbPJKcURREUglDRoyDGIU0Q ECMKQvRCUijtAF8kOrDnjrSSyFuBoLiCYhFySAgxCinHyXUF725f+Y1/2jitJKVDhARpdFx3qZU8 7uPDE6SgoH6ILg1JN+HlnPvTQB2FiITCGAZvUTfFgIIQQSmcHz6tn3wT8uZKfhXCj76bTJoppWJw I4g+BTG9EcSEghBBVexK+L6auafUHwW/ONPMfwEAAP//AwBQSwMEFAAGAAgAAAAhAMowVP2kAgAA Gg4AABQAAABwcHQvcHJlc2VudGF0aW9uLnhtbOyX0W6bMBSG7yftHZBvp5ZACBAUUmmbKlXqtGik D+DCSYJqDLKdNOnT79hxhhN20QfgLvbv8/v44xwHFg/HhnkHELJueU6C+wnxgJdtVfNtTl7Wj3cp 8aSivKKs5ZCTE0jysPz6ZdFlnQAJXFGFoR7acJnRnOyU6jLfl+UOGirv2w44aptWNFThUGz9StB3 tG+YH04msd/QmhMbLz4T3242dQk/23Lf4PZnEwHM5CF3dScvbt1n3NxTXKckd+170UFZU7Zi8jdf 14pBwaqcICRJD1DsXyWox5YriejIEplIVv2iUoF4qp6lupnxaowNgyiJ0mkco4nI9AyuDYi/XPj/ C+etAnljeTXnmITW5Urv03BTeqrOycxiJwsTb5K4yGngyFNtfyXHrhwN5bkTPRvIiRsdD+XQiU4G curK6UBO3IPNB3I6dcyDyVCPXN15PC7E4sMrjzmZB1E0meDjLE85idNZagbq1GG7yFIA8Oho2Zkn Y8P+rdRhFw9DuIIN3TO1hqMq1InBckEznFuthP31ZyU8RnWHAr97KXT2vruEHVjQ4ZqGimdTrZRt sbsZ8dBmTV+Lj8uOeErFzBKgz/y7eNOFjN6q5naI59rhVtiwqz0v1bnQzWY6C4lOAR6YeG8g9AWC LY2NQDPZsrp6rBkzA30ZwA8mvAPF3dTxDPRmldnV09w2tER23xp+x5Q+HM2A3ghAz0Ipb4RS9jgw Q0PG8tBG+DPs0USzRCfsjXw0FMtn2vM5l+XI58A0FMsn6vkE0ySIxwLSXaWpWEAzB1AapuZ6GDtM U7GA4h5QGKZYQOMVhBWkqVhAiQMoiabjHW3+uDQVCyjtAWk6+P4xXtIHpqlYQHMHUDxLxkvaVJCm Yj40hq+Y+PXhfgot/wIAAP//AwBQSwMEFAAGAAgAAAAhAJRR3VYWAwAAHgoAABUAAABwcHQvc2xp ZGVzL3NsaWRlMS54bWzEVm1z2jAM/r67/Qefv0N4W0dzQLuybtde1/YK/QHGMcSHY2e2oNBfP9lJ 2isro3Ts9iVxYkmWHj2S1TtZZYoshXXS6D5t1huUCM1NIvWsT+/H32pdShwwnTBltOjTtXD0ZPDx Qy+PnUoIamsXsz5NAfI4ihxPRcZc3eRC497U2IwBftpZlFj2gFYzFbUajaMoY1LTUt++Rd9Mp5KL r4YvMqGhMGKFYoCeu1TmrrKWv8VaboVDM0H7hUsDjIyPVOLfLh9bIfxKL7/bfJTf2rB9vby1RCaI FyWaZQgLjcqNUix8ahTDRbShPqsssXg1tdmgx2KMjaz6FMFf+ycqsVisgPDiJ3/+y9ObV2R5ev6K dFQdgB48HeqjKiL6PZxWFc5YghKk+RRVIcpQ9crwuSPaYJw+/CI8fr2sjPmYvfk8JbDOERkONlgr RYv9AEml4hDWgBeszkyy9rFP8B1+slg5GMFaiYAJes5itI8PzIBinqRC1+5HlCTSQoCJuAyGSjCk c4kkDIZX9+ekh3gApqO0MNnTDuqVKvuff6FBWJlturCnB979y4UWpNVoNjei2d+UT92/gcI99mkb i3xHUrAhTKFmTca0eahZ8XMhrfC17WqNdn0jPqGTW2bZ3da0F+EgQZBbFZFwWZB9O+XbFeVHiwkE 1rcOwXq3mBSsxzaBNVwVyhb2e0JttIJu57jdROeQ0u1G5/hTt+vdeu4KR61Ot+Mh9r2h3Wl97jSD 45jSwlKIvajFCo4ddbUT4s3KwrNCQb63Kr8otdYHqIm7gkIvGPNu3zzIqZJ6PlSSz4mNfZ+3F0k7 NLDQeLwIDJj3/pRLx02dm+zF6ZinXXw9NJgjEHkqNCFnBh7n5r+5sw2/ziZ+pcP1SfD3dIYDgTo4 kH+Xhp3af2g6of6K8QGX1UTBlf3B8ptlaNc4KOG1MAy/chyNvDUUfRbBTiYz3PAXKugrh7cX3qwM lVFsrKsRJFngACV1IqZSSxCU4GwDzEKfaoGjHXY4k4hxuI0huzMGQipKS3hiadqvyuNwidPd4BcA AAD//wMAUEsDBBQABgAIAAAAIQAlByjukAQAAEoPAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTkueG1s 1Ffbcts2EH1uZ/oPGD5XlkjdNZYyuvYldlzL/gCIhERMQIABINlKp//eA1C0LlYS2/F02hcJIIHF 7tmzi8PLD4+ZIBumDVeyH4QXtYAwGauEy1U/uL+bVToBMZbKhAolWT/YMhN8GPz262XeMyIh2C1N j/aD1Nq8V62aOGUZNRcqZxLvlkpn1GKqV9VE0wdYzUQ1qtVa1YxyGez265fsV8slj9lExeuMSVsY 0UxQC89NynNTWstfYi3XzMCM333k0gCRxXORuH+T32nG3Ehu/tD5PL/R/vX15kYTngCvgEiaAZag unuxW+anEsswqJ5sX5WWaO9xqbPBJe0hNvLYDwD+1v1iE+2xR0vi4mG8fxqnn86sjdPpmdXV8gB4 8HSoi6qI6Hk49TKcsZIW6JAbQWOWKpEwTaKnGIuNFIY+qvizIVIhagdGEWx8vSlNOwTcYXkKuBBL uaR47oEplxoPbunxEySNZht08bjUO2ENwyNwOlHUbbn3DqJmu9EMW3XvRmkIZxSW8559HKlk66Bd 4N85RnsSBB2urVpy65w/fCWMndutYP48QEZ7fodG6gV11cFk5X6O6vjaD6KG8yHh2vpMEaZBaZDD ZHYsGEVl7fy2g9vpn1d37iTrzytseusvMXzGYCVs9MhdyohRYu2KgVzdz++IWee50pZkLE6p5CYz xCqS0c+M5MoYvhCMoDwJ4zZFdjFaKJsSwy0sPXAbpyhW99iwlSu4/cP3dP7iyBhQ8UAXP0WGFutr NJ4iOTuKvDwPZ+D65ejE1yT10JhLGPDmyYwL4Sd6tRgLTTZU9INGu9aaDnc8PFiG+EAft9wORmfQ Rpt9DjeRjCUudwtGErbkEjMuiyH3zY+gtS7tUVxHSL4cr3+Xt83v8ZaCuVQaz1EwFOxe65jhckpy xUFHAEKNUTGnICxdJxzz2PINt1sC+qaEkpxqy+O1oCCx1YxmRxC9NfW+H9jB95lLxAY8CAOX63dj 8M+TbuL5cwLXESpHxEG9/VcDUeSBkQdaEMF3NZtyQzKlGVkxyTQVnjq7Nvh/jHHHeMMEA7HR13M0 nJgz8zuaewyCm5NEfjiKEgpCJjdU09vXXixv5tn+QH+3oY3j+i2vXX8TOzHwbf3RKPXHxBX1ofjw lzqEWSktXik+7DaHSEtscVunVCyDnSDx97IXIq4x+8GhIkGx7yMo1YHvAM/lwRJ62InCv+pRqzPt jCeVcDbpVBqd8ajSnXWHlVE0rI8aUdQKm+HfAdk5hVAtz1jRK56ri1MFgZrcdaBWNYogg8Nwn3a4 4JK3z8ORVMG+orxfl5VmmZWZUhZS4TAvDXfJ/WxellYXifmyRsdmmBRi8Qdq0Z9csusHufnGFXgK rh2MP95PyS37suaaOdlj9uB6G+8LbauEdg4pwcj1OlucANx8D4DxpQbTZzH2qv6d+T/pNMbt9nhY qc3GYaUxmoL/0263Uus0663RsNtudutP/DcucgnvHHFfQ//uPjNvpj0CL7/xMCw/+2Khr2j+aeMT jq9ZUBLSDo9ySGJXRFi6X+JsoOz+AQAA//8DAFBLAwQUAAYACAAAACEAAUgpUDIFAADWEgAAFQAA AHBwdC9zbGlkZXMvc2xpZGU4LnhtbMxY727iRhD/3Ep9h5G/VgRs/lsBBAaqky65NCQPsNhLbHW9 69tdSGhV6R6klfosfZR7ks6uMQRCOLjjqnwB2+zOzvzmN+PfcNl7ShksqFSJ4B3Hvag4QHkoooQ/ dJz7u3Gp5YDShEeECU47zpIqp9f96cfLzFcsAtzNlU86Tqx15pfLKoxpStSFyCjH32ZCpkTjrXwo R5I8otWUlb1KpVFOScKd1X55zH4xmyUhHYpwnlKucyOSMqLRcxUnmSqsZcdYyyRVaMbu3nKpi5GF ExaZb5XdSUrNFV/8IrNJdiPtz9eLGwlJhHg5wEmKsDjl1Q+rZfaW4zK8KO9sfygsEf9pJtPuJfEx NnjqOAj+0nziJuLTJw1h/jDcPA3jD3vWhvFoz+pycQB6sD7URJVH9DKcahFOILhGdOCGkZDGgkVU greOMd9I0NB7Ef6mgAuM2oCRBxteLwrTBgFzWBYjXBhLsSR/boEplioLbuHxGpJavYl0sbhUW24F L7fAaXleu2F+NxDVm7W626haNwpDeEZuOfP100BESwPtFL+NY8TnSND+XItZooHxSRbe0mgeGkqh s3iaPQ5x3OxgSk/0klHrBiJJfHQc2IKtE2cNS/OQmCKivHQ/wSL6veN4LeNqlEhtEwpUIvORQyrV AaMEz1yFp7u3o1+v7i7xZI0EIn5u05x2lOE9Bkuud05zPtzFFJRgcwMWXN1P7kDNs0xIDQRSGsaE JyoF7AAQUU1lmnCsfniMqY6RTfiYC1zKsd1EmUiQbPjoKriHREFIMjJlFMQMNGU0r9WQApYE5aZT qXOGcrFlDMHOs7qTWnM7nV9jEzQst1m36fiqnJhNiF0SjRPG7I18mAZMwoIYHlWalaBg3rNlhgc5 bXX3h1uameKEz5/+Ct7fjz5/+hu24ig4cwwPn9Pl212bLt+KJ4jNFn/eCEAbGr8hoBK+gw7W5Q2R 5PZ/I9DmwLzADBNtKR5oqLb3f4+GumP4eYXYzq+7Jbfqr1teOmc6sW3scDcxMZ3WRQ44crhUa81K Y9RfvQxf6yLvFOgYO66khLElcBpSpYhc9uCdNp2YKIVyK7rYjgrFySFyfA+XNwceT44T37aYULJT AweYt2N8D0EOvSKnQsegJeEq19r4IoxAPSY6jM1bkmSZFAS1NKZHAF4vEqPIYUMzCAWfUYlanaqT knPY79233+l8PWzf6BmAt9L2kP2EL1GSSAr2g0QLEeJMgFCvk9Hr9eDffwJUKo8UMpRpioJMIhBz qShbYIpmUqQmHyHNtAK38jMsKZEKV6ComUFENO3BMFHhXG0LlyPR3nB/j6S0xTa1MnLTB3fYmJ+D UriQwFYVG2H++ixQK2aBIbq/NQhYgY1DUiHzTxwE9DLDgSnSuSSOCZs5q+EglzxmWjIq58V0gH13 E0EhyW0zfqnJZzibmgHtj6rXaI1awbDkjoetUq0VDErtcbtfGnj96qDmeQ237v7pwMopDFUnKXUd w/uXSntXpqPyX70MGmXPw5HUdTcNBF0wVl5JHu77mqzUi6yMhUBRvZWXmun135qXmZZ5Yj7OicQT itx8YXKzJxfs+kJuXmmqu+DqrtG1cEs/zhNJzcy/XTznhrZRQDtBXU7hep5OdwCunwNg/NcETe/F 2E7Ylvbn4/+wVQuazaBfqowDt1QbjJD/o3a7VGnVq41Bv92st6tr/isTOUfvTqV/6wy0tz0p/78F L4u/YEImr0j2YWFJg/8sISVxTsJHGTZpU0S4dLPE2MCy+w8AAP//AwBQSwMEFAAGAAgAAAAhAFB3 ktbmBAAArg4AABUAAABwcHQvc2xpZGVzL3NsaWRlNy54bWysV1ly4zYQ/U6qcgcUv0fWvpalKW3O j+1xLPkAEAmJqAEBDgDKVlKpyjVyvZwkDyBpWbbHtmb0I4FEo5fXD93N888PiSBbpg1XchjUz2oB YTJUEZebYXC3vKj0AmIslREVSrJhsGMm+Dz67dfzdGBERHBamgEdBrG16aBaNWHMEmrOVMok9tZK J9TiUW+qkab30JqIaqNW61QTymVQnNcfOa/Wax6ymQqzhEmbK9FMUAvPTcxTU2pLP6It1cxAjT99 4NIIkYULEbl/ky41Y24lt7/rdJHeaL99vb3RhEfAKyCSJoAlqBYbhZh/lBDDovrs+KbURAcPa52M zukAsZGHYQDwd+4Xh+iAPVgS5i/D/dsw/vKKbBjPX5GulgbgwaNRF1Ue0ctwmmU4UyUt0CE3goYs ViJimjQeY8wPUii6VOFXQ6RC1A6MPNjweluqdgg4Y2kMuBBLKZK/98CUosaDW3r8CEmr3QVdPC7N Xr2G5QE4vUaj33H7DqJ2t9Wud5rejVIRbOSa04F9mKho56Bd4d85RgcSBB1nVq25dc4/3RLGLuxO MG8PkNGBP6GRekHd7WCycrfA7fhzGDRazoeIa+szRZgGpUEOk9ipYBQ3q/Dbjm7nf1wtnSXr7eU6 vfaPKH5FYaVeH5BlzIhRInOXgVzdLZYkoV8Z4Zakyhi+EozgLuJqR6ni0hpyz22sMktMlqZKW79r mWD5vQgZAf2YdFXBEKtISrXlIU+phVJJKDmQNQw2YNgpJdBrGH6pJZE6OzLSlYdtD+Qr8ZIDlQDS 5yb/yZO6yq5Rq/J8Fqx6L3VH232fDR9RSQ6DeV/pm8jcMB3T1JxUJ40iZFsqn/eIhyiYcuOz+4mo 1ZarzIjdJxJlyeoJu0IqcYRYx0EabSkK7YYRtd5zdM2ozVCDSSYF2EMoaDu9I+DoBhy7pzvCjWNa KrC8j3kYk4hRkRO34Ngj4Utlh2w7ETXehPyXAzL+aP7c9UcwPLrgQvgHvVlNhSZbKoZBq1vrzMdF VXsihvhQjJy4Hc2U/O+ff+1pUv/z7mikSuzImjGBGgTP0CRYiDxTvTsjE9SdqHDYi2D+2GHK0Epu xO6HkojCdkM1vT22hr4daq3WrU195QbWh8jvDfoyjvKDTlN2GN90XN/7fqttla125krq0z7r+xdm kLKLHtln7S7FPBLZvDHFVKyDovfmgbhhxLHmRfNFvdxHUDZC3/xedsI1Rj83//zVbHR68950Vqlf zHqVVm86qfQv+uPKpDFuTlqNRqferv8dkMIphGp5wuqBg/1lI33eLFG7vX076lQbDUx89fr+usEF p2Wfh4OuXBT/Y7PSLrNyoVDx9EFeWu4G/mxe1lbnifmWoaMyPORz0TuDkbdcsuud3Hyn1T0H146m l3dzcsu+ZVwzN1KbPbhex2mh7ZTQLlDnGLlGw3gGcPsUAOOjBKpfxdgPsJ72p+P/rNeadrvTcaV2 Ma1XWpM5+D/v9yu1XrvZmYz73Xa/+ch/4yKX8O5Y+nf3mflh2vualH/OYFl+4YRCX9H0y9YnHB9u oCT6Dl6laPPuEkF0L4L6wBNs+EohLw1GWMz2FIchtpS+JGDqjTJMv1xGbM0ltywg6PMWdB8GkqHU gwgqYktfp2xyi5vme1uhCRZtrtqtCnNYIrGj/wEAAP//AwBQSwMEFAAGAAgAAAAhAMltuTg5BQAA NhUAABUAAABwcHQvc2xpZGVzL3NsaWRlNi54bWzkWNtu2zYYvt6AvQOh67k+H1E7cGxnN2maJc4D 0BIVEaNIlaScuMOAPsj2cn2SfaSsuE6cQxt1KLAbW7bI/8TvP3x8e3SbCrJm2nAlx0HzTSMgTIYq 4vJ6HFwtT2qDgBhLZUSFkmwcbJgJjia//Pw2GxkREeyWZkTHQWJtNqrXTZiwlJo3KmMS72KlU2rx U1/XI01vIDUV9Vaj0aunlMtgu1+/ZL+KYx6yuQrzlElbCNFMUAvLTcIzU0rLXiIt08xAjN+9Z9IE noWXInLfJltqxtyTXP+ms8vsXPvXZ+tzTXiEeAVE0hRhCerbF9tl/qfEMjzU722/LiXR0W2s08lb OoJv5HYcIPgb94lNdMRuLQmLP8Pdv2Hy/sDaMFkcWF0vFcCCO6XOq8Kjh+60S3dmSlpEh5wLGrJE iYhp0rrzsdhIIehUhX8YIhW8dsEonA3P1qVoFwGnLEsQLvhSLin+94Eplxof3NLiu5B0un3Axcel PWg28LgXnEGrNey59y5E3X6n2+y1vRmlIOgoJGcje3usoo0L7QrfzjA6kgDoNLcq5tYZ/+UrYeyl 3Qjm9SFkdOR3aBy9oC47mKxdXSI7Po6DVsfZsPKAiLi2/ryISe1MMIq82lptJ8TpsF5TIc3LfVzk ThjTyBLg7YDQi8Xv75bfLPiAwFpvRJYJI0aJ3KUXeXd1uSQmzzKlLUnhkiEq/nZfDqhkkq4EygPh QJ5G+dB0xQW3m0q1rJi9YUwSywQrKkDIUO+iTEGtqVTVTcI0IyGqg6bVSqaQi+hHPI6hAllKTcZC W6n12hVGs4cpANdnQfHhILsWDpE+ofIzdIcig7Z5/Fyy7JD9JRqcMKCORydcCP9DX69mQpM1hbJO v9FbTLf5/cUymIa0dMvtZBpF5POnvzMe2lyzz5/+KcPznEsvN/g/TcX+/zMVffo8ib9KceeLvJ38 FHGTCbr5zglr+Ee2n1zPN5fD+bK1+82TkfpBM3WumCE24Ya4+sXjDUE1w6SBLnBE5tyEudkP0l4F +kHTtdkYVVqIn2rDNlGRIZixSYIB3XfPPRy8ElS7BrPilXcXHD1HH3ZDBlokCZX0zSxkVXrwdFp8 lwJSifm+8T3aBRuNfmPmJ0okxBNdMFUYFNZUc0xWzPxKTKJyUDYX8xulHcMjK0aumcSEIo7Ie01u EvqKgz7UFl/vCRzYrwLfiurXm1JGEFHjMhR5xKKje+eNAnZONb14yUT/8rnniRPfKfSkAsMZGE/J dDz5cfzrccrXKSnfnFq2x/c8jwIXLtncV/I9u8nAiyNbEKSEijjYcsACuo4Uu5ntAQlES9t5UBIy 3+ceMrIYeHY8/M92qzdYDGbzWvNkPqh1BrPj2vBkOK0dt6bt406r1Wt2m38FZGsUXLU8ZcXs+pDQ 3adtmGi3fbZXb7Vw89Bs7o4dJjhk7c5hjx1iX9G1vu5UuuWpnCgFOrR3Lh03/772XGKri4P5kFMN DeXZPEPQveYSXc+czSMN+n5w7WR2erUgF+xDzjVzVzv3073a0PbK0F6CZTBylqerewHuVhFgXI5B 9MEY+4sUD/vq8D8fdGb9/mxaa5zMmrXO8QL4XwyHtcag2+4dT4f97rB9h3/jPJewzgH3q+BfAex9 TSqu1fBY3rSFQr+j2fu1Bw0uEAFJsD78laFNuSTC0t0S1Aee4oWvFPLU4EIFd0wUm7FsKcuruSjH lQnHSBlzyS0LMF/iKlPbcSAZrjwBBBWxpa9TNr1ApnlmuZUEjbYQ7Z626vCIg538CwAA//8DAFBL AwQUAAYACAAAACEA5FVn8WgEAACyDgAAFgAAAHBwdC9zbGlkZXMvc2xpZGUxMC54bWy0V8ty4jgU XfdUzT+ovOyKAzbGgCvQxXM2nTQTkpq1sEWsGllySzKBnpp/nysZB5zQ1ZAwG/BDuo9zz71Hvvmy yRhaE6mo4H3Hu246iPBYJJQ/9Z3Hh5nbdZDSmCeYCU76zpYo58vg999u8kixBMFuriLcd1Kt86jR UHFKMqyuRU44vFsJmWENt/KpkUj8DFYz1vCbzbCRYcqd3X55yn6xWtGYTERcZITr0ogkDGuIXKU0 V5W1/BRruSQKzNjdtZAGkFm8YIn5V/mDJMRc8fUfMl/kc2lf363nEtEE8HIQxxnA4jR2L3bL7C2H ZXDReLX9qbKEo81KZoMbHEFuaNN3APyt+YVNOCIbjeLyYbx/GqffjqyN0+mR1Y3KAUTw4tRkVWb0 Np1Wlc5YcA3ooDnDMUkFS4hE/kuO5UYMhr6K+G+FuICsDRhlsvHdujJtEDDO8hTgglyqJeVzC0y1 VFlwq4hfIAnaHaCLxaXV9ZpwWQOn6/u90Lw3ELU7QdsLWzaMyhD4KC3nkd6MRLI10C7h3wSGIw4E HRZarKg2wR++Ykov9JYR6w8gw5HdIaH0DJvuINx9XEB3/Og7fmBiSKjUtlKISKA0kENleswIhs7a xa0H99M/bx+MJ239lTat9VMMHzHoemGEHlKClGCFaQZ0+7h4QKrIcyE1ykicYk5VphB0IzrkvUKU w7o4RRg94y3SKdaXjCxC19c1e5C1BbL8KSuwLO5gsJTg7yhwOs5H4Pj0GdV8nlO2I+b+SokkgAyp IYeoQmtKnkmC1lhSoq5QLAqYh0uCsoJpmjNy0TASqnKGt6qW2v8Kp6EkMIomM8qYvZFPyzGTkDDr O0GnGU6Hu047WAYhQYOY5XrwqRbse+vw8TjmUuRCEZQQRjQo0BUqeAxdKRHIGtQN1A/quDT8Jyg4 M+glVoRRo4wtGE61IXDIpo9nodMzI9tPo8sGgpYFAyBr0bxmImJrIInnmLQv1uAfx/CzmZPQzjHm plNN69oDgJmD0F4xMSeLK8SLbAmCZ9ih6A+CxKrW/PUmBKHmyRxLfH/u/H53PnuHVkJgmoLKVepm Bc9o7s9lPqhkfoI1qWm81U44/1QKfqbG620OjZDoUhRTzFbOTvet/Fm9N9PBXhwKP4z/fQaVCFvh favCKxiz5uz1T8sPu9PueOJ6s0nXDbrjkdub9YbuyB+2RoHvh17b+9dBu6AgVU0zUnLyrYi/FmqQ IutfD8KG78Np0/P2jIcQTPH2daidCHZadm5V2lVVZkJooN/84OwVmEn70bqstCwL873AEjxUtfnF ocx6rtj1i9r8RLlfg6sH46+PU3RPvhdU2qY7safeCW1YQbsAPSPoruzvQ4DblwAYPojA9FGM7eH5 wvyfdINxpzMeus3Z2HOD0RT4P+313Ga33QpHw16n3Wu98F+ZzGGw2ZF8Dv295gV4b4dS+S0Fl9Xn VczkLc6/rS1r4KsROAkHDHiUg0qbUsPS/RJjA/ruPwAAAP//AwBQSwMEFAAGAAgAAAAhACSS6rGh BQAA+BcAABUAAABwcHQvc2xpZGVzL3NsaWRlNC54bWzMWNty4jYYvm5n+g4aX4cA5hBgAjsJSboX OTWQ6bWwRdDUlrySTEI7ndnX6Eyfbp+kn2Q7JiRbyNbd4QZ8kP7D9x/86zv+8BRHZMmU5lIMveZh wyNMBDLk4mHo3U8vaj2PaENFSCMp2NBbMe19GP3043Ey0FFIsFvoAR16C2OSQb2ugwWLqT6UCRN4 N5cqpga36qEeKvoIqXFU9xuNbj2mXHj5frXLfjmf84CdySCNmTCZEMUiamC5XvBEF9KSXaQlimmI cbtfmDSCZ8EkCu2/TqaKMXsllj+rZJLcKvf6enmrCA+Bl0cEjQGLV89f5MvcrcAyXNQ3tj8Ukujg aa7i0TEdwDfyNPQA/sr+YhMdsCdDguxhUD4NFjdvrA0W52+srhcKYMGzUutV5tFrd1qFO2MpDNAh txEN2EJGIVPEf/Yx20gh6FIGv2kiJLy2YGTOBtfLQrRFwCpLFoALvhRLsucOmGKpduAWFj9D0u4c IV0cLq1es4HLF+D0fL/fte8tRJ2jdqfZbTkzCkHQkUlOBubpVIYrC+0M/9YwOhBI0JPUyDk3JBKT JLhjYRrYlIKx0ObUAcdyR6TNxKwi5swAknQAw0m0jJ4D5wQr+5DaImKidj9BEf0+9PyeNTXkyriA EqaQ+cghHZtxxCh05u6Z0R37FJuaT4+h3CCH6CATaxXuJPsNmYRUIs2aoGXEwwseRe5GPczGkSJL akFoHDXGBWxry6wHGeZmFCyADKvGGhcHM/KksklaiYO5SDknNA259L4Tbn6juwU3I6txcFsEt1vi VQL0Nju2Z5JO0MFpRLLoI2J7YpdLnC+f/94wh4nwlip6t0tzWC/gbwaqVOh6SNavrLT/p2md/3I1 rfnBhte7N8R1n/MqHJDpghE0ktR2ZXJ1P5mS65spwQc8iNKQEYPXqWYEwZ9xQVOFdHDwV2LFNuS3 l8phbV+SMhW2RYZcB6m2894h+VWKL5//MmTGyKMtoRBock0e6YpwQahYkYBqdrgvDtwqmUiE+pGb hR0n98UujLn7YoqQj8Tgu0ww0CCSWiqDqMrUHL4oB3yNy16we31uHVha+ziw5J3kdR9hgs4ihlQP +ZKHKRrHC5CKmeu93TrX55oQDk+K0VhXKhlzACqWai0DTm18bUEQnM/wHSSxVNWOVoCGScJjWvHI FtDEpDiGHaDRhOtByBRWGYrM+ELh94tFlT64uGY5VaXYApQDYruY/ZgmqXJdtqppKi8HhVmEKTAA +HSDHqioY+bCYTC380GVyPxLx8zPqrP0GkUHE2w7zQ43u/fS9Vln25SxfRD+YWJYgmMVUexTyrTB Z11jLLJwTz7e3F+eocC0YRTfgrkbog6KQWADsnJi3H5+rcSFUmGGI37Ls7o7vlsG4eukRbsgLc7Q Cl8wFo4JAJtT8BHvZCzMKgGzE5rs7L6g0dzLWYzsmGZpHRv0VzQGEqL0oOAOXKK+Jg/mINEsk/RH y+/2znvjs1rz4qxXa/fGp7X+Rf+kduqftE7bvt9tdpp/eiQ3Cq4aHrOmZzPnNR+wyScgOfNC6dZ9 H9xZs1mGHSZYKWUcXgQ+z+73RqVTROVCSoNiX2eS2pah+a9xmRuVBeZTSjHj4CZjmLZQTE7zJhPk sHkdm6/U8ia4ZjS+vD8nYGxSrpglJ3UJrpNRLbTdAtoJOBhGrtN4tgFwpwqAQe9C9JsYOyrQpX11 +X/Wa4+PjsYntcbFuFlrn54j/8/7/Vqj12l1T0/6R51+6zn/tfVcwLr3pn+7jMw3p73rSRkxjMuC Kw4idUWTm6ULOChwpCQ4MTxK0INtEWFpuQT9gcd44TqFuNSg+MCSUmzGsqlwLQHEYJiCIMR4yuZc cMM8dHeQ8coMPcFA2iMRZMimrk+Z+A6V5rjPXBI0mky0vcrV4RKBHf0DAAD//wMAUEsDBBQABgAI AAAAIQCHJ0S6XwMAAF0KAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTIueG1sxFbbbts4EH1fYP+B0PMq suRLbCF2Ycv2vmRTo04+gKFGFrEUqZK0126x/75DSoo3TQK0SYq+6ELODOecOTPS1YdjJcgBtOFK ToP4ohcQkEzlXO6mwd3tOhwHxFgqcyqUhGlwAhN8mP3+21WdGpET9JYmpdOgtLZOo8iwEipqLlQN EvcKpStq8VXvolzTfzBqJaKk1xtFFeUyaP319/irouAMlortK5C2CaJBUIuZm5LXpotWf0+0WoPB MN77UUozRMa2Ind3U99qAPckD3/qeltvtN++OWw04TnyFRBJK6QliNqN1sy/SjTDh+gb910XiabH QlezK5oiNnKcBkj+yV3RiaZwtIQ1i+y8ysqPz9iycvWMddQdgBk8HOpQNYiewkk6OLfcCiDxA6rG lKLrtWJ/GyIV4nTwG3js5tAFc5hd+Lok9lQjM9aFau2aTc9HZ2+QU0+WPS5UfnLA7/HuF2kqjN3a kwBPCKZNUwyOF6RfUKdQkOHdNiA519ZzRExlMwEUtdzSaGcbrWplICesRB8whEuCYiwsuej1r5Ak izVqI4PMN1TTTy8e4ADTFFNBFF3K+Nhw+jKz/Y7ZTEmLuiMbQRmUSuSgSfI2nnmOKulK8WsongtB SnoAcg+A5HLD9sYxriSxJRDsdYGtTwQ39hHhDZWez1eV9prqHRLYHugGAVEFYUiwpoJ/wQwqfsST /0C5nNTeEgk7ZbnveoJDjWgsOGiXm1Mr6tqiOpjY5+hagganlbrTTyOaVkWPcGC3/iThDDrhLKmF R6rpv001TXfmFsf7FxyYVBQBjjSnJN84vkldK7+pWwv8RLg5+bWfjMarcbYM4/VyHA7G2SKcrCfz cJHM+4tBkoziYfxv0I6MHKFaXkEcPNvsT1q8GSGuj0dRkuCXIY7P1cEUXJQX6vPKdh52VVkrZVGA /+/mwXvUpbC6KcznPdV4Qlebn97mT8i1s+z6bkU+wec91+A+veZMrp/G70vtqKN2K3gO5GZf3X9D 8PA9CMafFwz9LMd+HL+z/pfjQXZ5mc3D3jqLw8FihfpfTSZhbzzsjxbzyeVw0n/Qv3HIJWb3o/JP zpV5tez9x6z57cHH7k+ICf0XrT8efMHxBw8lmfmlGmenayI0PZu4GNh2/wEAAP//AwBQSwMEFAAG AAgAAAAhAEWGQnM0BQAAAhQAABUAAABwcHQvc2xpZGVzL3NsaWRlNS54bWy8WMly4zYQPU+q8g8o niNrX8uSy5bkXGyPY8unVA4QCVmogAANgLI1qVTNP+SU35svyQMoWqa8jBdmLhJJAL28fmh0Y//g LhZkxbThSg6D+l4tIEyGKuLyehhczY4rvYAYS2VEhZJsGKyZCQ5GP/+0nwyMiAhWSzOgw2BpbTKo Vk24ZDE1eyphEmMLpWNq8aqvq5Gmt5Aai2qjVutUY8plsFmvX7NeLRY8ZBMVpjGTNhOimaAWlpsl T0wuLXmNtEQzAzF+dcGkETwLL0Xk/k0y04y5J7n6VSeXybn2w2erc014BLwCImkMWILqZmAzzb9K TMNDdWf5dS6JDu4WOh7t0wF8I3fDAOCv3S8W0QG7syTMPobbr+Hy8xNzw+X0idnVXAEsuFfqvMo8 euxOM3dnrKQFOuRc0JAtlYiYJo17H7OFFIJOVPinIVLBawdG5mx4tspFOwScsmQJuOBLPiX77oHJ pxoPbm7xPSStdhd08bg0e/UaHgvg9BqNfseNO4ja3Va73ml6M3JB0JFJTgb27khFawftHP/OMDqQ IOhhatWCW2f8wyFh7KVdC+b1ATI68Cs0Qi+o2x1MVq4usTu+DINGy9kQcW19pAjToDTIYWI7Foxi Z23stqMLdhPbSnPulFmvMhPrFbxG9hMyB2S2ZKRMiUaJ1G0scnp1OUNGoHPBCJcRX/EopaJUXTSN uEKS0YzGplTJVpE5I5pJ8JdFsJ9QuSYRM9y9mgS7n4oCbAiKD3X248KxEi6SnjXpGVJgRpMNWV/P iCeilijDHcYFA97Csidk7hWE/RBvHDSgC4+OuRD+RV/Px0KTFQV0tVq3NvbkhzEPpuENO8lNt6MJ N2FqDPn29Z9IMUPskhuSpBaRu0kRKpfvDQEZLVi+iaY+eN7T10fle/u0oOODoam0BuWQ+2XAW91a Z3q4yYHPAI70jiPfEhZxq/S3r/+6HG4ZwX6xOHYKXu9yyGmfl7wTPv1eUPlBoKeTGTmDO2XKdBkW pCxTJJehSJGLkF2jRHFH8dsl8pRnuUzjOc5ctSAh6gtNy1WNcq6qNM4rkwi6Llk2PPjCtCoTqr0/ CtIKlCxns09/O50VdHyQg5V2diYXz1GTJonCvkOwgVCCuM654HZdKq/mzN4yJh/QqkzHXqLoj6DV ywfc/5GcSDnR+XjW/jRhgln2C1HzFacWFcx8TVo7wUUyOaeaXry1kny3eVuFvpgtVE/PhGO7pFhJ 39fPmxoLArdVuy/kXS/xfPvSytuXCdAp9C6+J0Bfl3cmb+xd7DpBjxfZrNhfUrEINv1MVtm4Bs8V M48aGjiy9SBvLnxD8bi7WKCddj3lX81GpzftjSeV+vGkV2n1xkeV/nH/sHLUOGwetRqNTr1d/zsg G6PgquUxy0rUx83JbgOCwtXrt6NOtdFAF12vbxkEE1zInonPO6PSzqNyrHAo60JcWq5O+WhcFlZn gblJqYaGPDbfaTa95t2e0GPzODbPHDK74NrR+ORqStDi3ZetW3C9jHKh7eTQXqL8ZuQsKxoeNu3t MgDGRQ9EP4mxvxTwtC+P/5Nea9ztjg8rteNxvdI6moL/036/Uuu1m52jw3633W/e8984z1EtBY64 b6F/exuZd9Pe56TsigiP+a1RKPQpTT6vfMBxGQZKoh3CpwTXX24TYep2CvIDjzHgM4U8MbgTwH0J xWJMm8n8milKcaOABpwtuOSWBeiDcC2n7TCQDLU8iKAiNvN5ysYX2Gm+A9hIgkabiXZPG3V4RGBH /wEAAP//AwBQSwMEFAAGAAgAAAAhAH6jCZikBQAA+RYAABUAAABwcHQvc2xpZGVzL3NsaWRlMy54 bWzUWN1uIjcUvm6lvoM110v4J4ACq4SEaqXdbBqIem1mTLDWY8/aHpK0qtTX6F2fpY/SJ+lnzww/ CckSoI16A8Ngn5/vfOfY55y8v48FmTNtuJK9oHpUCQiToYq4vO0FN+NhqR0QY6mMqFCS9YIHZoL3 /R++P0m6RkQEu6Xp0l4wszbplssmnLGYmiOVMIn/pkrH1OKnvi1Hmt5BaizKtUqlVY4pl0G+X2+z X02nPGTnKkxjJm0mRDNBLSw3M56YQlqyjbREMwMxfveaSX14Fo5E5L5NMtaMuSc5/1Eno+RK+78v 51ea8Ah4BUTSGLAE5fyPfJn/KbEMD+VH228LSbR7P9Vx/4R24Ru57wUA/8F9YhPtsntLwuxluHwb zj5vWBvOLjasLhcKYMFCqfMq8+ipO/XCnYGSFuiQK0FDNlMiYprUFj5mGykEfVThF0OkgtcOjMzZ 8HJeiHYIOGXJDHDBl2JJ9t4DUyw1HtzC4gUkjeYx6OJxqberFTyugdOu1Tot97+DqHncaFZbdW9G IQg6MslJ196fqejBQTvBtzOMdiUIeppaNeWWCDlKwmsWpaGjFIyFNq8OOC53CGNH9kEwbwaQpF0Y TsRcLALnBWv3krokYrJ0M0IS/dILat6ViGvrA0qYBvPBIRPbgWAUOnP3bP/64qdP41KVnkC5BYdo NxPrFG4le4PMLhnPGDFKpM5B8ulmNCYmTRKlLaEkhgGGqCmhQiiXqeSQun2+6bnPt4MKVtqRE2Yf 0loe01tm3pFwhhCyg4q2al0cIpuxKKeS+5qklyi2Lps8u3zMdwq824R482jIhfA/9O1kIDSZU8fX ynFlUDB8ZZkjW5Yetv/dzrBuIvf+9hw0L/Y3501S6mWzh8OVuvVMVC3qwGpG7hzk1SrzslnbkM2l 8SKfsxxcs2zLXGEyuqKaXm9TglcdyBPO+bFnYX8k1ZXwaxar+R6lZFM6+TPI9qvhGkrFUbGD+85Q UtrimEAVC1Ucp5KH1DLi+ERNwkJLtCvxR+SD/fv3PwzhkrTWjHscwuzkrAYO9L3K3iZ89mekLzdr DuyK7v62lFovVZvF8c0knQgc32tW/2uwrzJ9fxc5rp0avYOmEy64fSATZu8Yk8QywbIre8jQoESJ wlJD7mZMs/+joyG6Bk0NoZq5ohfx6RSe4Ma9mkXm6L93LS8pf/35vOpD3m+jNTW75lZu9IvpkQrL S3PO7gAxiZgJNZ+wyBUoV7xSw0hIDXsLyPdPm59Vil5c8C+oxIpof9K8c36BXdz1Z4THMYu4K9WS segNeLW/kwMqUQ4IjSKEDW0/bv18im4mZrgrkzuKenC0frV+jk6LBizjDT7djddZONnM7dUNWJqt eu6W8Wjx8nK//QY0rUWz6vtX10I/37U3iq793MV3tWX3rTDGGUVD/sqW3T4kGG1ENmteZ1RMg7yN z5oGN9dwfcKTPh6ILj0AXr7d9mA/7Z6nYK4bpfxar7XaF+3Beak6PG+XGu3BWakz7JyWzmqn9bNG rdaqNqu/BSQ3Cq5aHrPs4vC0IX7cUKNHz4Ldb5VrNQyPqtVl5YEJLvjPxCejB8L4uqg0i6gMlXJc XY1Lw40o9o3L1OosMF9TqqGhiM03Zixec8Gub8RmczasHvk5qIOPNxfkmn1NOYoPjjGzBNfLOCy0 rQLaETpbRi7TePII4OYhAMZ8E6I3YuxnYZ72h+P/ebsxOD4enJYqw0G11Di7AP8vOp1Spd2st85O O8fNTn3Bf+M8l7DOEfc19K8vI7Mz7X1NyiajeCyGpaHQn2jyee4DjhkwKIlJA14luIy6JMLS5RLU Bx7jD18p5EeDGRfGhBSbsWwsi+lqlGJCxmXEplxyywIcbphGa9sLJMPUGkRQERv7OmXja2SaH/7l kqDRZqLdU64Ojwhs/x8AAAD//wMAUEsDBBQABgAIAAAAIQBKr3U51AAAAL8BAAAqAAAAcHB0L25v dGVzU2xpZGVzL19yZWxzL25vdGVzU2xpZGUxLnhtbC5yZWxzrJDBasMwDIbvg72D0X1W0sMYo04v Y9BDL6V7AGEriWliG8sb7dvXUBgJFHbZSfwS+vSh7e4yT+qHs/gYDLS6AcXBRufDYODr9PnyBkoK BUdTDGzgygK77vlpe+SJSl2S0SdRlRLEwFhKekcUO/JMomPiUCd9zDOVGvOAieyZBsZN07xiXjKg WzHV3hnIe7cBdbqmevlvdux7b/kj2u+ZQ3lwAmXyjiuQ8sDFgNb3jtxLq6ss4GOP9j89QiwsB5LC eWWz6Asuwq8Zrt7e3QAAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZe RPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a 3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZD OtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQ SwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRl TGF5b3V0NS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj 7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz 3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39U KB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAA NwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc4SPwQrC MBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTr fK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo7 9qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualne B9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlv dXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQD lmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL 5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUd S/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAG AAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 My54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9 axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJ WYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNy plSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwA AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54bWwucmVsc4SPwQrCMBBE74L/ EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2u tiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVR ac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu +wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtsk ZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLi wUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6 Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAh ANXRkvG+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTAueG1s LnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMS u+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44 XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6 yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7S ehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDij tzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2 iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA //8DAFBLAwQUAAYACAAAACEAciatzCQJAACjPgAAIQAAAHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVN YXN0ZXIxLnhtbOxb3VLjOBa+36p9B5f3citDbMd2nOowBQzMdBXdSzV0zbViK8SLLXtshZ/e2qp5 m32G3ct9lHmS/Y4kOw5JGKChGZZwAbJ8rJ/v6Bx950i8+/46z6xLXtVpIca2813ftriIiyQV52P7 89lRb2hbtWQiYVkh+Ni+4bX9/e6f//SuHNVZ8oHVklcW2hD1iI3tmZTlaGenjmc8Z/V3RckF3k2L KmcSj9X5TlKxK7SdZztuvx/s5CwVtvm+us/3xXSaxvyHIp7nXEjdSMUzJjH+epaWddNaeZ/WyorX aEZ9vTSkXcwvPs0S+js5179Pqt13bFQXWZocpVmmHmii/CCrrEuWje3JuWPv7L7buSXFp1Mey+Na 0jtqj1pSBWq4Ls8qzqkkLn+sytOS3qL3j5cnlZUmUIptCZYDe2pbvTBi6lFATLe79Pl50xIbXU+r nAYL6KzrsQ0N39BvfMRG/Fpasa6MF7Xx7G9rZOPZ4RppTFZ3gAm1ndKs9IzWTKfvhs2MPgEXJs4z bnnt5PQXgLA8LuKL2hIFpqtRKA5mkOZ7VVVczThLaqrWkwdcTVeECHVezix5UwI3mcqMGzn9EmMV rXwNxK3J1YcigSyby8ImZG6hNvBDLFgFneO6rjdcxm/oulFA7wlFx438AR5oZIuGyqqWP/Iit6gw titMXXXELs3KYKNGhPoXBS0ypaRMWFdjO/JdX33QeZOnZH5Zmo/tYZ9+9KgIm0ORqI8lSzNdxlgy oRYezZgQktf7RXJDvU3wFyjAEWBos6L6YltXFQPs9S9zVnHbyt4LoB05gwEmKdWDgsS2qu6bSfeN mOcHBcwCC5iJGK3CQprigcQT4VXkJZPH4rSMSZDGQiicXf/MqtJAJbFKPxanM1bydYhpWYW1ngY1 ktXyVN5kXGGAtYhmMb/sEsMxIAEBNqqoEmtqbHPR+3yK0WXyuPtc5/Ig4wy+0Xwmdw+yNL6wZGHx JJWWcYFqjcFToktSulTDQRcoo3estwZrFLVt3Gkh8Lra5hcWMiDdKvN/egsh3Gw4G3iCxqCewlBC J3IDZdkLT7NkKYOB4wSBu7WUVUuR/7eWQnuOMpR6jaUoc+kYq1qOsNPHGuspjwuRWBm/5Nk9ulNL 8Su6O5ul1f17M6bx6MkdFfNKzu49OeVBvmJyR+n0jt4e6ON8L/BXnZz/jE4ugUnVX7C9sWxqnJ32 PEQGDCV7PCsI3MHQbPoLZ+c6ntfSAkMh4MX/gKwAY15mqS/HEb6551N84TJzFCtio4RPP4EW0FJx iFJZtzgA8ahGmsqGaSiOQb+mWaJ4+z9+GPYPD/cOnd5e/8jpDfqe04v2I7fnDoNw6IRRsOdF/wSb UiQ1YZLLNOeaA63wkltjUB5S87vdYMd1EAg5zsK/YQg0Ei6SE1Yxmk2X5OgV+HBaApMNVk02eEaT ncpK2yyxUFBdY7bKb8LfPNZsPccdNGx+vd0OI39rtw/k9i9pt+Dt5+DoMdYLLfwVE07SSqr49qHG vH5vXrFGRAXHnw+tT/yXeVohJSDkMrl5DltcE0WHz2iLSPd8nOfrzFHxiq8wx8D3vbvNcbuNIvvw +sxxgzHesp4H7KeDgzA82Ov1jw6wn+4f7veiwyjq9YfYmfb3otCPvHY/rZGm48hAKH/wkO30t1// /Zfffv3PE2ymKtTXyT0Um3RinFUfWGkhVzi2M4nciLxGKblAaXLuUp1LdSglFyixOIY3gYQpNDV4 r2taGa+p8RqZQVMzaGr8pgbcW38eNDXY2mdZKi5AkOmPbU2L7Cdd0ZS0d4EjOGY3xVy+T5C5opxE p0YxH9cZhIMh2ALmVI0oh1m9T1Qkd4cs5tHKKl5+hyxm2MqazOHGMWDurazJoWyUBSqtrAlFNsoC r1bWcKCNsnDVrazx0RtlkfppZVWW8Q4coo5stKKdJV2E5D9aXahk1uaGwyXFNSmhzpCN4kFYkcxX qURhqkqGLROr/Uyo7tFQMkeqLxXYk1OBfCWGwXGiQIlGgai8AqNE5vVMZ2rzT0UhaSIwGNUS/krd NJXa7mZTa5agWTMPea2SfbUaCWV71SMxAcPUDT/I0LlUKUCLs2OxX2G1Y4TTQsg9RSAmrMYAKcuM eZ3MRYxRakZel/E+n1KTKJ3EUmf8Vf9wYEtv96awio1y5m2HongRRRmTtqc7ThjgFxQ6aL0rRecf QgUSUxYji/3X/O+9TOEI4sFuveCMmmCjuL71Iq5N23psKk5tIx0FpUtJVE213gqUe1XKMNd4xqqa YzU0Gl/GiIAxy83bYrQeIwLGYDTYYrQeIwLGYORvMVqPEQFjMAoIo5xVx2O7OaDbeidirsveiWAy iIULxNRhHjaeLWKriBFMBrHhAjHHCx2VFtpCtgoZ4WQgizqQDd0hjqa3q0wnXZftknDSh8MdzooL IjiNXSGw2st5A1eRRaLTAmyk11Q804pEWkZfKngUx53McTWG1oS6ELS4J7Ngsa3EZH76pWXVYdMr LibMj0DOO0T1ZxBzup2Eiz5lKuPZEcvTDKk9hI8tRzOneGgcrE1VI6zWpFcrQCX3PZqaGl2XSq8M VUc/v0u4xSbCLXobCLfo3ZNwa9UHkev4MKSO6sMAp+vP5b+fR/VNzkKbw0uq3yVP/uTqX9l7b0cG WpnRMBzgOs9CmW7kBUOE/q/KjpuU1B9AmTDmb6DM2yGMVqbjDh3HgSW2punCVjGg16XN3/XKvtkL ntAr//dfK26Z/M43UOXtSMuo0o+GwZIqPcePqOJVGWY3YQuPtN7NqhuDGv4n22VfTp/ro0K37/vD rT7tx7Kml9Pn+pjV9R2vv9XnK9Tn+ojajcI+Lkl1ts6tv31IVPNy9rk+3Ec4Gg62+nyF9tnmIjrZ h3JUyBmv2lwEgucTneQxYfTqrbKFSHPypolVlwxD5oxNTnG/rklBrjuUU2da5owOX687kzOjUDf1 VJLpglf0X0x0meTJI7uVk7SnCuxXMtdvFp8NsTL908l2/cCeNoSfK1npN7uANgR1KznoNwvQhigJ N5Ip6l4EuW8WoA1hRzjQNxTbLMCbBWg9jyd0tk5a3ZHZQIwDP1w+OnyzK6hlml1ySbe72ktceMBd M/2flbv/AwAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOW ZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vm QiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L 83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYA CAAAACEAyg4Z29kAAAC+AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQx LnhtbC5yZWxzrJC9asQwEIT7QN5BbB+tfUUI4eRrwsEVacLlARZpbYtYP2h1Iff2UUhjw0GalDPL fjPM/vAVFvXJRXyKBnrdgeJok/NxMvB+Pj48gZJK0dGSIhu4ssBhuL/bv/FCtT3J7LOoRoliYK41 PyOKnTmQ6JQ5tsuYSqDaZJkwk/2giXHXdY9Y1gwYNkx1cgbKye1Ana+5Jf/NTuPoLb8kewkc640I 9KFlNyCViasBrTGw8/Tr9zrHCfB2jf4/a8jiHb+SVC6bMitfcCV63Vb8aYab1YdvAAAA//8DAFBL AwQUAAYACAAAACEAKPvAL4ADAADxCAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ3 LnhtbMxW23LaSBB9T9X+g0r7rAgZAkZlSCEueSEOZewPaEYjo/JopMwMLCS1VfmtzefkS3JmhAA7 TpW31g/LA7Rmunvm9Dnd4ur9rhDeliudl3LgR29bvsclK9Nc3g/8u9tZcOl72pBMSZSSD/w91/77 4R9vrqpYi3RO+3JjPOSQOqaBvzamisNQszUvSL8tKy6xl5WqIINHdR+miv5C7kKEF61WNywol/4h Xr0kvsyynPFJyTYFl6ZOorggg/vrdV7pJlv1kmyV4hppXPTjK5l9BbQrQfLB95yb2mIh8odAzpYi 9SQVWEich13U1a3i3Fpy+0FVy2qhnO/1dqG8PLWxhxg/PGwc3NyjhBuM8En4fZOJ4l2miuEVxSiB txv4YGpvvxFEMd8Zj9WL7LTK1p+e8WXr6TPeYXMAbnA81KKqEf0K56KBMyHDvYUgxtelSLnyoiPA OoqQZV6yB+3JEpBtJWqk7Hrb5LXw7UnV2qtLnxoI7wtIJJH5qB/ARQ6sq5B1dkYTr1FuV0ezS8p0 b2uywq9bpFhoszR7AXZgb0XkuKE45dkNyNGFGQtO0H99wJkPqnIei2JQnIF8y+fXy6g/S6a9JBj3 R+2gk3Qmwajb7gTTWRS1epNupzcd/e03eFAlkxfcKohihWOhHPQYl8HdElAf34HiGg/FZtgNLyII PYqucBsD3O4KNguX6YIUWQznyWxxkcBVqCkHilVT+XtC2w2hs7I0oPGc0ovXoDQzqub084YUTmho beRQa+C/0eoVpOauOWDcOCOXKXrcmSTuwTKz9wD3t7RaQmH9qNNpoZuUEc6J01wm6sE1bFZKM3JB K9LcR5lNLg/bCFmDQkyzxUYyHFBTK+SyYpYdXbEFM96WkDZq2Y+TPRR15pHw7Klv44b40+4oA/OP c575HXZXm7FQtzs3EVab5ZejOQOM48M1BrlzMbSaa+PMQyekuTJufDzVo+2Dpm+sfdZPrifQji8R tRmO53dT74Z/3uSK2wmuT6J2OV5X0p1G0kuRp9y73hSrJ8Juv4aw8SZE6me17Rrn/zOyJpedca83 HgWt2TjCyJomQX/a7wety3ftbjLq997128eRpW3RJIC9jNzTxPrx7Z8/f3z7fqIWI9Pm+PfkurFV v1dh2veue3UK9ZGqT1unGPzRwCyB8LFUoRnt9IPrycXmaP6qDH8CAAD//wMAUEsDBBQABgAIAAAA IQD7golBfwQAADcOAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbMxXXY/i NhR9r9T/YKXPLAmEj6CBFTBDX9hZNDB9N4kzROM4WcdQ2FWl/Vvtz9lf0mMnhoGlWuhMpc4D48T3 Hvvec++xc/N+m3KyYbJIMtF3vHeuQ5gIsygRT33ncTGpdR1SKCoiyjPB+s6OFc77wc8/3eS9gkdT usvWigBDFD3ad1ZK5b16vQhXLKXFuyxnAnNxJlOq8Cif6pGkvwM75fWG67brKU2EU/nLS/yzOE5C dpuF65QJVYJIxqnC/otVkhcWLb8ELZesAIzxPt6S2uWIFolRi0RxNhTRYusQYy83mPGcAVIQznlE BE3x4jeYJiHlxNgTZIws2FYZsyJfSMa0g9j8KvN5PpPG+34zkySJNFqF4tSricrMPAqYYVA/cX+y SLS3jWU6uKE9ZIds+w5I3OlfONEeNkHC8mV4eBuuPp6xDVd3Z6zrdgHsYL8o+M/LiL4Pp2HDOUmK tw+v9KHAmGbhc0FEhoB1Hso4w/uNRdXB63XyFSk5UZoPh2QyAXMlRZVXaWrSZL0Lk2q7/32C2u1G 4LtlmrxGo9HsHueq4bY6Zl5nrO263Xa3YxaxSFikhM57ajvKop3O9BL/Qagumr7DqA6+hOWFmqsd Z4YPZI32EBJ+YMypbjQmao9zNFqqxpxRNGLFnRqMeRI+E5URFiWKfKCFYpKYFKAtAXkDchRqo4Jk IppRSR9OkHVWaQ8rY992vyYEndl/5rH5PY+6mmachmyV8QhbaegI0QiWsH9FqU7cCaNoC9SsrYfL mfVbHQiLqf9zxLZdL+jq+f+KWNQb4Ru+Z/CVROt0G56LI6JLMg2j+LFLmmxdUVtzFmaQKc42jF8A b6i+An6xSuTl6M2yVS7O1yRbS7W6ePP+tfBJfBYdevqmLebbFrulih11lknIazsrUlCVzzgKKY+d qqeMthiV1MpqBi/l0vSzFQkraka5rIxp7UKNe5W2RizWenMiXijRvY0eVxKofY0Cxjg59dH3JQgm /p3XadVGLW9U8/2hXwtu3Wat4XmjSbPb8bxh8w+nEv8IWVJJyvTxe4mAYotm62rQrjc8XBc871Dp 2IJGeVtCW5bQSZZprX4plqYIX0tprGTJ6ac1lVjB0voDrbyKVpJSOTX3CAwezCARkTlvoZ2UP+GI CvU+wP2CLueosMDzzYkplRE/wuhUjOSzudvEmVBD47SkBc5ufV0T1TTwVjgDcSecrUWIg7Oklot5 Hmp2ijychYpsKGA9V//pTtYV9cJixOJTW2sG/8PsMMZZeYz5wq6aXa7HXC62pm6W6/nn/XCCMPYP 97gOl6VFl9NCmWHVCVEilblpXdsTF4vfePp4Rx7Yp3Uimb4HH58Ob13SbVvSc55EjNyv0+VJYbc0 J68tbHxPAPpsbZuj5/8jWbddf9zpjIc1dzL2av7oblQL7oKg5nZbzfZoGHRawUGyCp00gcB05f34 yndQrG9f//zl29e/3kCvzFWv/ATBUH+0GLa4/EDzjxtTdfhcg5ag8PEqRzOCT216MNEY9oNv8DcA AAD//wMAUEsDBBQABgAIAAAAIQD5LR8eOQQAAFcNAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDEwLnhtbMxXXXPiNhR970z/g8Z9ZrEJH8ET2OEj9IXNMoH0Xdhy8ESWvZJwYXc6s3+r /Tn7S3ok2xAonULCQ/NAhHV1fO+5954r7j5uEk5yJlWcip7jfXAdwkSQhrF47jlPi0nt1iFKUxFS ngrWc7ZMOR/7P/90l/mKh1O6TdeaAEMon/acldaZX6+rYMUSqj6kGRPYi1KZUI2v8rkeSvo7sBNe b7huu57QWDjleXnO+TSK4oCN02CdMKELEMk41fBfreJMVWjZOWiZZAow9vShS3qbIVoQoxcbh1g7 meOJ5/QRejDnIRE0wYNFrDkjIIj8BuM4oJws2EZbM5UtJGPmgMh/ldk8m0l7+iGfSRKHBq1Ecerl RmlmvwqYYVE/Ov5cIVF/E8mkf0d9sEI2PQfJ25pPHKI+nCBB8TDYPw1Wn0/YBqv7E9b16gXwYPdS 5D0rIvpnOI0qnIIUbxdVYUpxdJoGL4qIFHGa8Ivwgoe8AjMxG/hsRYoUaMNvaVdsWj4qewVOLVl6 M0zDrQl8if/2IfW50nO95cwSArepD3B8gH5OTYUzUXuao8ITPeKMogNK8nR/xOPgheiUsDDW5BNV mklinUE/APIO7Ggkp4RkIpxRSR+PkE181Meb4XTlIZYFhf9O5E1F5EFNkRmnAVulPIQrjWuQa6hy SCpjNEFR7Q7qEkVTZeYSxo2MAIVR47Tx7hT/SBfhOd8R/c58mCK36VAH+Sg4t8Tjo3qlDeqCEpiz IEVfc5Yzfga8zcgF8ItVLM9HvykYPZuvSbqWenW2881L4ePoJDp056qd0Kw6YUw1O2gASwikuNKO N6lLqNH8XzEqKI+q0rcSYEXGSNEb1MZWfs49K/fUD1lkZOFIY1Ci6IPCxqxLpTJnrVBFmDBmRHzr tBrd7rjRqrkTt1VrNrxhreuObmsdr+W2O+3huNkZ/OGUahmCJR0nzIypc3SuUE+jZO16w8M49bx9 pcMFg3LdhLaqhE7S1Ejqa02zRfjelEZaFjn9sqYSb6jS+hZJOxCxV2klCZVTO2+xeLSLWIRWRDGD KX/GJAmMH8j9gi7nqLCu12y62JTaih9hdCqG8sXeAaJU6IE9tKSKOZhNOhblNo6sMKpwZ5qtRQB9 LVLLxTwLjEcqC2aBJjkFrOeaP9PJpqJeWQxZdGxbmeH8fncQYaQdYr6yK3eX6xGXi43lZrmef90t Jwhj9+UB10VroulyqrRdlp0QxlLbG8mlPXG2+I2mT/fkkX1Zx5KZe+LhdLh2Sberkp7zOGTkYZ0s jwq7ZXLy3sLGfRvQJ2vbjp7/j2SNb5ujTmc0gGSNvFpzeA/Juu92a+5t66Y9HHQ7re7NTrKUIU0g MFN5/30z2yvWj+9//vLj+19X0Ct7Iyuu6liay73NFpefaPY5t1WHnzPQEhQ+HmVoRuTTmO5NDEb1 g6j/NwAAAP//AwBQSwMEFAAGAAgAAAAhAD4A4lJoBQAAARQAACEAAABwcHQvc2xpZGVMYXlvdXRz L3NsaWRlTGF5b3V0OS54bWysWF1y4jgQft+qvYPK+8yAwcaYCpkKJOwLk6ECOYCw5eCKLXtkwcBM bdVca/c4c5LtliWMCakQwkti5NbX6r+vW776vEkTsmaiiDM+sOxPLYswHmRhzJ8G1uN83OhZpJCU hzTJOBtYW1ZYn6///OMq7xdJOKHbbCUJYPCiTwfWUsq832wWwZKltPiU5YzDuygTKZXwUzw1Q0G/ A3aaNNutVreZ0phber84ZX8WRXHAbrNglTIuSxDBEirh/MUyzguDlp+ClgtWAIzaXT+S3OZgbR4H 841FlJhYw4JtXYPlwSwJCacpLEzjQK4EI99juSQjmuM5lEyRzwVjKM3Xf4t8lk+F2nq/ngoShwil IaymfqHF1E8OYvDQPNj+ZJBofxOJ9PqK9sEjZDOwIHBb/AubaJ9tJAnKxaBaDZZfj8gGy7sj0k2j AE6wUwoxz0uLXprTNubMY5kwYu+sKkUpbJ1kwXNBeAZ2ovmlecH92oChzQifL0npfolQWq58qfxh 5AvlU3PQnSdsz2+3e5C3YLnTgyxrHXjFdXpdBxYJ+sbtdr1OTykxSKCkhM77cjPMwi26dAH/VUho PynkTG4TCC48rxMbjkFo8gT1k0DoaT9k0QMsFT8GFiQ56FkYc3fyENk6DviV9sF6+ANbE4rlx3jj cQbll8pRwijAazvk9SiJg2ciM8LCWJIvtJBMEOUtKFY4GaJLpUNBMh5OqaB4qH1kDADtg2Yw2Biq bMcgvB7pjom0yf1pQgO2zJIQDtG+RNyh7CyoEUhgkyXnRb9rtz3PxRNVJVELvmPbmCEfjn5KxUSV YMxD4BN8RJ2L1T2QplK/lxMdSAqtUWcPysJjGxOphHJcD6XIKXjtygINovE6FZ5vOyrjT8JDyTI3 AA9BNJ5T4dkdz8a6Ou2AWAQ7QETRgO4eYA9K9jxARNGA3QoQKAAOeNYJEUUDenuAnqMid4bJiKIB exUgop0elJoPEUUD+nuAXdc7MyiIcpyTEB7SYEc+Su8LjuLZVGRZpGrgVb6Kg4wjadEwJFDi2Ddr RHUOGTmGjObY8/aZqIMpB73a9JezOhCyPjAwMPmSJpEmJcVxqhMpp2GLnin/mb5hGsnRluR2oOGU HecVVuq1oEGVSgzSOS3pXaRk14oeW5rOrzNJya6RHIJovDNJya7l/wVIyb8wJ9XwLkBJNbwLMFIN 7wKEVMO7AB/V8D5KR69S0OHIhKShJqbiw0zkGia6pZLVmMi5BBOF8gUP2WVXRf45SkSK/8xg99YE i+VphpT6wImTajnlHu8QEVyG8ELz89b1h0PfHzduup27hjN0W42h1xk1hp2ha4/88ci1x/9YerYP wUsyThneqE4ZeoFBwB4ca7vNtg0XP9uuQgZHwHeXnXO7JqDjLMP5er+5qKHyo80lkqKM6bcVFaDB zLxvDL3vCqueJ2EOgnbwcDCj6ltLgOeA2M/pYgadzsyKQqquTxid8KF4VjfWKOPyRl11FrRgFlwn ZMz1a9CxhHsL3O6nKx7AEFyGNuGzPMDoFHkwDSRZU4BFOq8IeE9iyKJDWTM7wv7q7U0E95s65p6c frtYjRIx36i8WaxmP3aPYzBj92M3o0u6mBRSSetKCGMh1f358BL2Vk0cn5KO0dLk8Y48sG+rWDD8 olHnoUuntGdSepbEISP3q3RxkNjdS3AVfBkC6KO5/cbs9K7cxgT4KGX1nJHnjW4arfHIBsq6Gzb8 O99vtHowpg1vfM/1OzvKKtBpHAxDxS9G4BfBrRjr969///r9678L8JWaA8sPS/CI36HUjJuILzT/ ulZZBx/egEsg8WEph2IEl6JoJYIY5tPd9f8AAAD//wMAUEsDBBQABgAIAAAAIQBpol8hHgEAAMcH AAAsAAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJlbHPE1d1qwyAU B/D7wd5Bzv1ikrbpBzW9GYPCrkb3ABJPPliionYsbz8pDBIojkLAm4CK5/z4K+Z4+hl68o3Gdkoy yJIUCMpKiU42DD4vby87INZxKXivJDIY0cKpfH46fmDPnd9k205b4qtIy6B1Th8otVWLA7eJ0ij9 Sq3MwJ0fmoZqXn3xBmmepgU10xpQzmqSs2BgzsL3v4zad/6/tqrrrsJXVV0HlO5OC2r7TuA7H9XV +bLcNOgYJMl03k4Hu8Tzgd6XrWLKViHZNqZsG5Jl+ZI0568Zzg7yNkNv3yzkWJTx6K3KQ7JsyYAe lQUzK2LKimBmcUMLpraJmdommJp/6+M9rVkasq1j0tYh2T6mbP8no7Pfb/kLAAD//wMAUEsDBBQA BgAIAAAAIQC8f/IqnAUAAEEUAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDgueG1s zFjbctpIEH3fqv2HKe0zASHErWyngMC+OI7L4A8YpMFoLSRlNBCc1Fblt3Y/J1+yp0cakGQSwPbD vthCOnPUPd19ukcX77erkG2ETIM4urTsdw2LiciL/SB6uLTuZ5Na12Kp4pHPwzgSl9aTSK33V7// dpH009C/5k/xWjFwRGmfX1pLpZJ+vZ56S7Hi6bs4ERGeLWK54go/5UPdl/wLuFdhvdlotOsrHkRW vl6esj5eLAJPfIi99UpEKiORIuQK9qfLIEkNW3IKWyJFChq9umySekrgbTz/a7a1mIbJDW7Y1hU8 96ahzyK+wo1RHCkwsC+BWrIRT8gOjUmTmRSC0NHmT5lMk1upl95sbiULfKLKKax6/iCH6Z8RYLio V5Y/GCbe3y7k6uqC97EjbHtpIXBP9BeLeF9sFfOym97+rrf8dADrLccH0HXzAliweylinmQePXen adyZBSoUzN55lUE5ll7H3mPKohh+kvuZe97NxpCRz0SfLFm2/Yqoclz2UO+Hwad6T42hu51ouR3k lt6OZsdpuJU9cRqNrmM7FqOdse12M0cUPc6Yk77aDmP/iXZ0jv86IrwfpmqqnkLEFteb0IYVjIcP KJ8Qked9XyzucCv9emnBDhgyN97u8AhsmQfbyvtwHn+wNORUfSKq3U9RfSs1CgUHfe6IuhqFgffI VMyEHyj2kadKSKY3C7UKy4hd6XdoShH5t1xyMqrITPvP+3gzNtU4isssxD8PNHaunPq3IffEMg59 GNF8XdgDH0lrMuP0iDtux6UoUgUcCrlr2zYQWcjdruvYiH/mflZF2u0s+cxOHAt5JdIOpVxGmecE AXDZzJO0mBXdItYAgHUOYFtFrAEA2zqApWzb2WAAwLrHsAYAbPsY1gCA7RzDGgCw3WNYAwC2dwyb AQ7VEFYyMOyK5ZU1RUKqSyot1VRWN7p48Me8UifuGWU8FV4c+SwUGxGeQK9r6wz62TKQp7PrgjiD fRKvJVreqca3KDHPoQ8WB9nR295UzVpGzWYU6qKU6Q1Brzf96UUdjNoGJBytYMnDhYXGD4HTgdSd jCRHX0x1xpP40q1ftTS75bh2Vuf7Pl/qaa12z260Xy1wbMXltZ4rgsjHiEOXZNp8fYNJUEezoGl2 SaeoJxb0L6cyjfkkvpKeVjQy5+vZLXorO4mvpI0VHc35bKdjt08l7P1Caw1ft9klqT/JwBJfRY9z vmazC/NewlfRbMPXaem2db59FV3P+Yjs5ICU/K1ov+Fru52XxeP/0R9Q2Waa0AMGzbY/n6tco0Qf uBIlJdLa+Vol8tUzHbKzaYGOGAeFCDW+9+Cceag8sVKbzsZkPXAWx2c99i5wmKID0bdxrzEYQ0hq HWfQrbUaQ6c2GLa7NWc0GTeGvUlv4oz/tvKzgY9dUsFK0IkMfaUy2z6fmqFIWrPUVbvetHFwtO19 z4UJxPK2raVtAjqJYxrQi83FpXb42pAulMxi+nnNJd6Qtxf7yAB9VljzUoTooB3cVdpBfuzxyA70 ghmfT9HpjCxLpccwJvh1NJSPNNizBY7LA31WmvNUWDiPqCDKH+MdSxx88HXgdh156DdZaMNomngU nTTxbj3FNhy06IAFQS8ghmJRxZqZGOv3TwcLHJDKnAVc/nS+HoVyttV5M19Pv+4uJ3Bj92PXDhWf X6dKo/PO6AdS6fN3NR+P1YTunseTGkfB6/sxuxOf14EU9EWkPKe+dUp3TEpPw8AX7Ga9mlcSu/0W iY0vS6A+mNtHZqezcpsSwIwwL5SsD93WqNMZDWqNyciutYbjYa037vVqDRwy28NBr+P2nJ1kpbRp ERyjFx8P7l6xfnz/548f3/99A73SfSj7MIVL+o6lZSiUH3nyaaOzDh/uoCVIfNxKUIzYUoLuIcRh Pv1d/QcAAP//AwBQSwMEFAAGAAgAAAAhAGLe40yvAwAAQwoAACEAAABwcHQvc2xpZGVMYXlvdXRz L3NsaWRlTGF5b3V0Ni54bWzMVsFy4jgQvW/V/oPKc/YYJwaDKzAFBPbCJFQgHyBsObgiyx5JsDBT UzW/Nfs58yX7JNvAsNnabIrD5EDaUner+/Xrlm4+7HJOtkyqrBB9x3/fcggTcZFk4qnvPC6nbtch SlORUF4I1nf2TDkfBr//dlNGiiczui82msCHUBHtO2uty8jzVLxmOVXvi5IJ7KWFzKnGp3zyEkn/ hO+ce1etVsfLaSac2l6+xr5I0yxmt0W8yZnQlRPJONWIX62zUjXeytd4KyVTcGOtfw5J70tkqzPN 2b3ge4dYVbnFou8MkH284AkRNMfC0mgRq2Z2VLmUjBlJbP+Q5aKcS2twt51LkiXGQW3oePVGrWY/ BdQgeGfmT40nGu1SmQ9uaAQsyK7voGR78wsjGrGdJnG1GB9X4/X9C7rxevKCttccgAgOh5qsqoz+ mc5Vk06Fg3/IqlKlMJ0V8bMiokCeJv0qvfhu2zgzORv35ZqcAF/rVZsWj0ZfAVMLlt6NimRvEl/h v12kEVd6ofecWUAQNo3gHD+An1PDaybcxwV4nesxZxS8r8HTgzHP4meiC8KSTJOPVGkmiWUBugAu b4CORnFql0wkcyrpw5lnkx+NcDKCbiKEWEH470BeN0DeUs3InNOYrQueIIKrS2CaaKT8GW1BeeqA iGCJbxO30JoCvAFjAyzfct+SnEYJSw0YZ8gCjIOOkev6GFtbnhStZBrjSycYd8OgM3HHt9PQDbpD 3+21h6HbDtptfxSGo7A3/erUHEmAks5yZvrxNdWtOGPq1/GufIwO3z+WEyEYL5ctaNAUdFoUhkin Jb2+RElTLauaftpQiROasjYt9ubWOSkryamc2SkD4cEKmUgwNa1I+RP6JzZxoPZLulqAYT0/CFoY S1Jzq8ToTIzks518aSH00BqtqGIOOlJnot6GyRoNivthvhExDqhKy8WijE1EqoznsSZbCrd+y/zZ EQFGnWiMWHqu26jB/rg7TNHIP/s80at3V5sxl8udnSSrzeLzQZwijcPHHa5Gq6Lpaqa0FetOSDKp 7Rz+vz3x+pE1e5yQB/Zpk0lm7kR1JLX1cVlKtxtKL3iWMHK3yVdnxA4uQWy8LeD6RW7bWfjrjKzb bjAOw/HQbU3HvhuMJiO3N+n13Fa3fd0ZDXthu3d9GFnKgCaQmGHef99Hx4n149v3dz++/XUs7Zvn lb2HqgcKRPOKsW8QLj/S8n5rGYOnG2YJiI+lEs1orjOoHlWMj+bxN/gbAAD//wMAUEsDBBQABgAI AAAAIQDtFLGjQgYAABoeAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDUueG1s7Fnd cto4FL7fmX0Hjfeagn+wDRPSCRT2Jk0zhTyAsEXw1pZdWVDSzs70tXYfp0+y58gWtgm0Ds1FZzY3 ibGPPkvn5/PRp4vXuyQmWybyKOUjw3zVMwjjQRpG/H5k3C1mHd8guaQ8pHHK2ch4YLnx+vL33y6y YR6H1/Qh3UgCGDwf0pGxljIbdrt5sGYJzV+lGePwbJWKhEr4Ke67oaCfADuJu1av53YTGnGjHC/a jE9Xqyhgb9JgkzAuCxDBYiph/vk6ynKNlrVBywTLAUaNbk5JPmSwWvkpXewWn9J3y78MoozFFm6b xiWsP5jHIeE0gRuTNMmoiPKUqyd5thCMoQ3f/imyeXYr1ICb7a0gUYgA5UCjWz4ozdRPDmZw0T0Y fq+R6HC3EsnlBR2CN8huZEDQHvAvDKJDtpMkKG4G1d1g/e6IbbCeHrHu6hfADPYvhXhnxYoeL8fS y1lEMmbE3K+qMKUw9DoNPuSEp7BOXH6xvOBmq8FwzQifrUnpeoQq7YqHyh/aPlc+1RPde8Lpe5BX yh2W57i23/SJb1kDF5+jZ0zTsXvwA+eigeAdBXI2lLtxGj6gR5fwX0WEDuNczuVDDLGF621slrMI 2ep9EbPabQCtm4P36BDWCH8gC2KKBcZ4524OBZbIScwoFGAZQ3k5iaPgA5EpYWEkyVuaSyaIVO7N cQI4ZakmriAZD2+poDCJBnKxNHgzrEuvRy0RXX06nvY+nphMtzEN2DqNQ5iBhd6C1NeBOyu06E8D 6gCSVGfCWRE2+3bfNO1miJ2e0zN9YC0MsWsPPFfNuU2ECeXBOgUaWhaQ9eiVwSYJFdeq4CIeAnPg pUqRzQ3QI/iGDotcIPnnkWE5mGtLvcxabqhLC7KnBNR52woVk/YAFaHw5TBNu0IdmI6aQRtU03+M ilAlqlOhmrZnqiJqBassmy5ArBK2X4P1LV/N4VxYxCph3QrWsnyYAjjsXFjEKmG9Gqzn2IppzoVF rBLWr2ARs33IjvgWsUrYQQ3W7Xs/FTLEUmxTrwnFaPgSyLo9dam3n89wSDiK4PIGw0H5PpnFHM1i k5RLqNUGkSnWOJ/IsLrXNF6VNFZQDH6vlZvwYq48pj8n+vty9ENleo7v9b9DY/agb0JxoEUbHlM0 VA/Uoy9VxU4FZM0ALjWZ1Jms+lDWDOBSU0TNVjHJHlcbgK2u+7otZuXeVhuArS7mk7baAGx1hZ60 1QZgq8vupK02AFtdSydttQHYFgXSYH9Fkvu1/RoVpMoI/uiiVd/fJ7QlcxakPCQx27L4SIEewqu6 eAL8Yh2J9ujll78148zSjZDr1pN3iopsDx+tjqJDS/6s3Vlf89risDtTMz6f1IrGu+jOkOA+bqiA trPkOOVt1YO35jjX6fcsmC422yd6NdMD5nvp1UbGS68G/fJLrzYy7P9jr+ZqTjvWq6nW6Hxae0xl iifPpjLrRL9WUdlLv4Y+b/Y/L/3aCU3nuzuew4bqpV9DCa3YDR765lft1zzNbW+oZI1NqIsd5vnE VvRroQQBsbkdNYs91cn9qHqr1gPb65uHOiWEAXY+hQaK1zVtVEkDK9DHUe3+0gNpZ+LZXmd2NbY6 jj91Ov50Oul4k/544NpTz7Nnfxul8BuCl2SUMBTZ22ilsJeB9aAa6nYtE04ETLPamcAU8NnzNuAg Lhay/yxNUZatC6Tec4R0JaHpfvzZMn+glj4prJWSCZLm+wNJk9D4HtToAOcBu98FXc4hw3SLKqSS ewij13wsPqC8SVagsVypQUuaMwNUaBnx8jGIb2uQu+HY53bDA9BMi9DGfJ4FGJ08C24DSbYUYE0Q GipJoGYxZqtDW60cwPjq6dUKZPEmZs2ufLrcTGKx2Km8WW7mn/eXM1jG/sde0pV0eZ1LZV1qAWEk pDpceWpNtN5NTq7vpuQ9+7iJBMOjrqYe9twpPdApPY+jkJGbTbI8SGylPv0sV8GRIUAfze0fSGhP ym1MAC3aNI9WWlPWG9+ZeN7kqtObTcyOM56OO4PpYNDp+X3bHV8NvP7A3lNWjk7jsDB88Y+1z4qx vn39549vX/99Br5SpzrFqSNc4tGk+rLE4i3N3m1V1sGJLLAVJD7cyqAYwaVoWpkghj7TvfwPAAD/ /wMAUEsDBBQABgAIAAAAIQCNa8DZbQIAANIFAAAfAAAAcHB0L25vdGVzU2xpZGVzL25vdGVzU2xp ZGUxLnhtbKxU2W4aMRR9r9R/sPw+GQYoTUYMEUuoIrUEheQDHI9nUb3VNhRa9d977WEITWiSSn0B j+96zrm+w8ut4GjDjK2VzHBy1sGISaryWpYZvr+bR+cYWUdkTriSLMM7ZvHl6P27oU6lcswiiJc2 JRmunNNpHFtaMUHsmdJMgq1QRhAHn6aMc0O+Q17B426nM4gFqSXex5u3xKuiqCmbKboWTLomiWGc OOjdVrW2bTb9lmzaMAtpQvQfLY0AG13x3P9bfWcY8ye5+WT0Si9NMC82S4PqHBjDSBIBxOB4b9i7 hU8JbnCIn4SXbSaSbgsjRkOSAja0zTDQv/O/EERStnWINpf08ZZWNyd8aXV1wjtuC0AHh6IeVYPo OZxuC2fF65yha0FKhpacUFYpnjODkgPOJphAss+KfrVIKkDeEKJuldufphWRJRtbzWi4atigi01b 21Pku9EVcjsNRFqeX4vSlwm0eWs4tAEWNGiMDYy/g+m1YBZhUo9hdF+H8XqnDyrfYZgCkCjQ8mK/ OnXbCQR4YX2gx0XgDRkxXjtV1M7XOzZx61ZuxxnckxQEg3mQ+ZIYcgujx4HVDDMZ3a8wymvj2vmA FOALnbTV4PgaT/2Wp0b0xVo8gNLHdPX+B10gLKSGdfIjw9/WxDhmWvbCwP8jfYGX5yQVPA8P82d3 cjXoJedJNBtfTKP+vNuLJrNxP/pw0U86849JMh8PfuHD0MG4S+jO82yeEmyFm3JGYEHuX2YzgiR1 o8SL5oJ0UPkFlRp5T2oTJGr2DBzb1UO5+UL0zSbMCWxUoGsarjTsUJ8NXB9dPHl+yke/AQAA//8D AFBLAwQUAAYACAAAACEAGDq5ytAEAADyEwAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQ0LnhtbOxYy3LiOBTdT9X8g8qzpsFgDKYSuoDAbOiECuQDhC0HT+RHy4IO3TVV/Vszn9NfMkey xStkII9lNomwjo50n7pXF58fY05WTORRmlxa9qeaRVjip0GU3F9ad7NRpW2RXNIkoDxN2KW1Zrn1 ufv7bxdZJ+fBmK7TpSTgSPIOvbQWUmadajX3Fyym+ac0YwnmwlTEVOKnuK8Ggn4Dd8yr9VrNrcY0 SqxyvThnfRqGkc+uUn8Zs0QWJIJxKnH+fBFluWHLzmHLBMtBo1fvH0muM0grv6U3878sonFihS+2 1YXo/pQHJKExPsy+pWSQJhI0eirPZoIxBUpWf4psmk2EXnG9mggSBYqhXGlVy4kSpn8mgGFQPVh+ b5ho5zEUcfeCdqAJ8nhpwWBr9ReLaIc9SuIXH/3tV39xcwTrL4ZH0FWzAU6w2RS2zgqJnopTN+LM IskZsTdSFVCKpePUf8hJkkJOJX4hnn+9MmRKZkWfLUipdkVV4opJrQ+Dz6FTrSz52E+DtRJ8jv/6 I+3wXE7lmjOtEBybdkCOP1A/p8qrWVK5m8KrYzngjMLrS+XJ7oBH/gORKWFBJMkXmksmiNRy5Yry AtqRME5JyZJgQgW9PWBW8tEOdsahzQkxLFT4vCIbRpGlN5EJpz5bpDzAIepvU2v+HdFAeWjBA+Ee xgbP6Fap68DLnGYL8apdzW7ZXt1tqANtHc6pNdquAii3cxzbdl195F13UmZTZjY6OWo1RcpX3NZY 2glYqNSrzl9vg7/Q7Q4Aw/oRrLOLNQBgG0ewtV2sAQDrPMXae2cwAGCbp7AGAKx7CmsAwLZOYQ0A 2PYprAEA653CFgCYz4STMoyOJqwkYNiEzRujS6UsHVz5XnQVEXS4pXbcFwT0lPlpEhDOVoyfQa9d 9gX0s0UkzmcvQ+ZsfY3SpZCLsw/vFBF5Pn0UHmVHUL9rXnP+L69pneA+NZfBC6+Lg7xWpBx1dapM 8+TOOJbXXKf9kdhwI3wkts5HYtsUQh+J7YyCrWkS2xWVbK9a06n49VmtKIIDiRr1oG4rCqBnExyq o9eVV/ulsLr1TQl2rAII0fyoTuaHN+zVh8NBrdJ3GnbFcfr9Sr/e8CrNds+rN1yv5zZHf1tlUR9A SzKKmeqgzinHEY66xJRdt1q30enZ9vYKxxEUy/veVK4x6ChNVeW/W4A31e36VpOGUhQ2/bqkAjuY cvxEPf4is5KYirFuCzG41YMoCdCd6iHl92h4fHUOlNYzOp/CwzzbUfUyEVJXdYTRcdIXD7pVDdHa 9vSiOc2ZhRZKRkk5jSULdFRo5yfLxMcGhWl5Ms18ZZ088ye+JCsKWhtV9rbO3kH0WXiINWU+1m9n eyE6r33OHVw5O18OuJg9ar+ZL6ffN8MRxNj8uMZLRuFadD7OpR6WjUYQCakb58P28FRMnF12DcZ3 Q3LLvi4jwdQTxn7Z+94u3TIuPeVRwMj1Mp4fOLb7Ho6NpyBQH/XtEzXZi3xbOYDpCF+Zsq7azqDV GvQqtdEAKas/7Fe8oedVau1mw+33vFbTa2xSVq6UlkAwtfHpB4Rtxvr1858/fv389x3ylb6Hihcl DNW7k05DXHyh2c1Kex1e2pBL4Pj4lCEYoVIF3UIUh3mr6/4HAAD//wMAUEsDBBQABgAIAAAAIQBn LGe8JAYAABsUAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1s5FhRb9s2EH4f sP9AaM+uLUuWZaNOEbtJMcBJgzjFnmmJioVSlErSTtJhQP/W9nP6S/aRlGTHcdq0a9cBe0lo8nh3 5H333VHPX9wWnGyYVHkpJp7/rOcRJpIyzcX1xHtzddqJPaI0FSnlpWAT744p78XRzz89r8aKp3N6 V641gQ6hxnTirbSuxt2uSlasoOpZWTGBtayUBdX4Ka+7qaQ30F3wbr/Xi7oFzYVX75dP2V9mWZ6w l2WyLpjQTolknGr4r1Z5pRpt1VO0VZIpqLG777ukVuXNGVWayQU04Vb0XYXj61xz5hG7T24w4XtH uIpkwVMiaIGJKyNBFjxPmV1S1ZVkzAiJzStZLaoLaXecby4kyVOjod7pdeuFWsz+FBDDoLu3/brR RMe3mSyOntMxbobcWlfvzF9somN2q0niJpPtbLJ6fUA2WZ0ckO42BuBBaxSxr9yJHh4nbI4zzwUj /fZQTpJi57xM3ioiytmKimu2WNGKXdnL9Y0w7CTnm0bv7vGbOYUrJMubszLFddO1LnHPjZftNQwD fwCEeQTH9ntRFGN86ErCcDSo19qj0nEllX7FygKBVnricRzFGqGbudLGya2IsS3K05xzq54LcjPx RoP+wG5QJYBgFo2YTQs245JsKAeWbt2BsbArJcu1SK2uFaPpST3WNOduDNtc2OBmGUt07ZAJiUOW vp2W6Z0RWOK/RQ92KL3Qd5xZvYgd/DfSdJyy7NIhrJ1iIr2gkmKacERo4jHRebOwsYGMjVBjA8Fy SHgcD4N7eIh/FB6CXmjCbODQj/1RuA+HuN8fRUagzZNvCIcoGPT+V3Co8sTxw0We7PNd1AACa3ot GRl5JGUqAf3nTGe8vC5bkNTbAbs8uU8bx6oC+B171kxyLGV5Y3JGmWmTpZZKWhd2uaSdXPK8avLT jIkcs2LJwMvy17QPOKD4afBMJXOhjVJkq0wuYduNtWQ6WZnpDFlezwM6qlmAE1sbLkufQF4j3yDU onU09B+QF7gN6zVa46E/CGxiPQ5ZCYe/jsF2uK3IUQ4Jz4uJB4+MfXsHn6QpyxAGAhggiAYVj3OF HwXxsIGHuUvQD4pp0OLBlQDcbltEUCufAoKmdhgMGB+qVV3QEy1txa7x4tbhq2hLkOPVBwUG9WXk BzZEYRQNwff2MpqKGw1jGzbLJ30/CAy5QKINUXsx1bhh04OMbaDFN9w3RY/yazRp0gbSETdR7yee ZTanu5a0dhrONxos5ePkdCz3aB1K9XyH5okq9IwzCkN1fPXRjOfJW6JLwtJcE9cWEdsKoTdEVTGn 0tamNfFIAdm35Dz+4oJiQIKm1HVbW5CE3xEkar10IEHDhm6qIZengyUOR0ENFhQidBw2Xbf9WdQP Y5vwpvr0g6hvWpd/ipaCyrntB3ORosm1w10ELdenpdA2DzKagON+Q2NuGn/00FUOVjulRc6NQ6DB FZWKQYdt6ADU9TmeA/Cw6SAsEIOt2/8iEBGdH4XFA2RleWCnh/2WZJVqPMaQ8CvKM6/GosOJIaya Ze8zF0L0dILZDed9FkCCfzKiGd4/5jHz+zTsx+Ew8juzaBp3wn4UdOIoCjuGIYMhsH8ym/3RvKZS lFadF8w8og4w0wMmAgdayOmjqNv38fjz/S31wAWj5RHyccn0xWRzgGii70g0mZYuwu/WVKLYNkH+ DON8UZBJywsYXB4mCFRF05RlV3S5AN7QjVh2khrPFnQdjM7FVL61hTcDhxzburSkCk9j8xQX9TJE zRsPlHKxFq5bMyHiYlGhEzCZkVwk2r2G/LajMFjbkZiybF+24Ubs364eZyhB93XuyNWryzWeX1e3 FkXL9eJ9OzRU2P5ouU3TpXtftTSX5lKDEnGyPXR+LkMOF989JaaMzuZvTsgle7fOJTPfONQW4p+q rl8JcDTf+5V0+B0Bjm9G5+viIMZtZbGd13+CyF7G4Ww4nB13eqczvxNOT6ad0clo1OnFgyCaHo+G g1HQEpkyn3sEDmYQ+KDDehDkLY99/PDnLx8//LUN8VezmO0n3acmDM0HKcP8CZdntHq9scjBJzlw ChIAUxWS0kDmnojR0XzUO/obAAD//wMAUEsDBBQABgAIAAAAIQA+U5YG9AQAAIwPAAAhAAAAcHB0 L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1szFfbcuJGEH1PVf5hSnlmkYSQgDJsAcbJA+ul DP6AQRqMyrrtaCBmt1K1v5V8zn5JTo8kEISUCfZDXuxhpuf09O106+bjSxyxrZB5mCZ9w/pgGkwk fhqEyVPfeFzcNToGyxVPAh6liegbO5EbHwc//3ST9fIomPJdulEMGEne431jrVTWazZzfy1inn9I M5HgbJXKmCv8lE/NQPLfgR1HTds03WbMw8Qo78tL7qerVeiL29TfxCJRBYgUEVd4f74Os7xCyy5B y6TIAaNvHz9J7TJYmwv/N8EDg2lBucWWZQxguz+PApbwGBtz4ZNyRoJC6tM8W0ghSC7Z/iqzeTaT +tL9diZZGBBIedlolgelmP6ZQAyL5sn1pwqJ915WMh7c8B68wV76BoK2o7+4xHviRTG/2PQPu/76 8xlZfz05I92sFOAFe6WId1ZY9E9z7MqcRagiway9VYUox9Vp6j/nLElhJ5lfmOffbyswspngszUr XK8IqpQrDrU/Kvlc+7R66N4Tnm23rJZ2h+OYbtc8cYrnebaDTUausVqubXptraRCgpICOuupl1Ea 7MilS/xH5Hjir1NkqaIbvBflaq52EeKM9Tay8CLGoyeUUYQs4L1ArB6wlX/tG1AJnUsdeJ/DAzyK SrXlTYT7GBHO5j24BH8AEnGqR5E0Hueox1iNI8GhqLRODcZR6D8zlTIRhIp94rkSkmkXonrxRkJX WoeGFEkw45LT8+rIFBXeg2Z4obJeO4Qi8+/hh7+LUlhQ7s0i7ot1GqEYmE1GolqqOF+VCeR9A2WD nK4S56qEsLum6yE5dPCqKjlOiLZpWh2vjExRZJckxLLAPJcQMZdTXaBhEoBpaEkxXW7uQaf6JbU0 ASXqiFIqFAlFsljalFsFlNP2IAZ/XIBndep4BFLitQ54XQuFcimeW8cjkBLPOeBZLc8iscseSKqL rIOVhFICtmuAHbtDdlwBSCgloHsAtO0OHngVIKGUgF4N0HNal8fkyGRCKQE7B0BCuzwoR4CEUgJ2 a4Bu27syKIRynpwIHlHbs5DWez1ZUUVqrsqPyOoaQnIqQrrlShwRkq7+txJSoMDBYPU1j1YVMRVp TB1bu4sWc+25op9oGqwotWoouvzPkAbFr2KFY6qvEwOtax1I94sVphKaL76Z7q09bk8mjbHV7TYc b2g1RmOr0xjbQ/e2M+qatuv8YZStNoCXVBgLGm0uaTewSz9dDdymbWEGs6xDyPAEQnnfDtOuAnqX ptTZ6j3GIQJ5a0hXShYx/bLhEhqqsL7ScP5TWEsCB/GAyR9OmkI5Ofj0DsR+wZdzZFhFzlLpMmOC T5ORfNZzxCpN1FCPG0ueCwONXIVJeQwda0wMGLRnm8RH1ylCGyXzzKfo5Jk/8xXbcsBa4MIDC9ck RmJ1KluRNe4fTocrTBbHmDW58nS5GUdy8aLzZrmZf90v72DG/se+KSq+nOZKS5eVEIRS6XH2dPx5 rSYup6Xp44Q9iC+bUAr6uDjmofdOabdK6XkUBoLdb+LlSWLrwfStiY2PNECfzW09nGG8+Z9Q1m3H GXveeNgw78ZWwxlNRo3uBORldtotdzTseu1ua09ZOTktgWGUea/3nANj/fj+5y8/vv/1DnylB8Pi Ow9L+iDUNBTJTzz7vNVZh29gcAkSH1sZihH5TKIHEcKovqIHfwMAAP//AwBQSwMEFAAGAAgAAAAh AL5hN5aFAwAADwwAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWzMVtty0zAQ fWeGf9CYZ+M4tyaeJkziJry0pdO0HyDsdW2QJVdS3ASGmf4WfA5fwkq222kTIBkCw4sv8u7x7tnd Ix2/WeWMlCBVJvjI8V+3HAI8EnHGb0bO9dXcHThEacpjygSHkbMG5bwZv3xxXASKxad0LZaaIAZX AR05qdZF4HkqSiGn6rUogOO3RMicanyVN14s6R1i58xrt1p9L6cZd2p/uYu/SJIsghMRLXPgugKR wKjG+FWaFapBK3ZBKyQohLHeT0PS6wKzFe8/OMQayRJffWeMeUcLFhNOc1y4yjQDguyQUHCNSNZA FVcSwJjy8q0sFsWFtH7n5YUkWWxwan/Hqz/UZvaVoxk+eM/cbxokGqwSmY+PaYBkkNXIwZqtzRWd aAArTaJqMXpcjdJ3W2yjdLbF2mt+gBE8/BTLXVQZbabTbtKp6PAfsqpMKbqeiuijIlxgnib9Kr3o vGzATM4GvkhJxbw2zNZ21UfLR2OvkFNLll5NRbw2ib/Hu12kAVN6odcMLCEYNg0QHC9IP6OmsYG7 1wts7FyHDCg2fk2eHocsiz4SLQjEmSZnVGmQxAaDY4CQx8iOxuLUkMDjCyrp5TNkkx8N8M8YdBMh PlYU/pzITkNk3U3kgtEIUsFiDKL9Z7RmMTZFw/wBGMUCEFayB+r+kGHTtpZg9YThikVLJV6aX9o0 9ijqAiKBM8qgBLYDvGV6D/irNJO7o3dMHfdAn4ul1OnOwXf3hc+SreioJAft7W7T25cQ4X5yg7rZ +31Ho2SEKVrDREpxlwKN1WMX/0o/Yo3j/Qn3AMoSB0XXNL8dcisjRmw29MRUhXEzumZSKz1qhner vFiHkvnWlgYxJKgD1ejjZFTL2MCNGhlzK0YJ7h9mG/jcafcHs0F44vrzk4HbHYRTdzgfTtxpe9KZ dtvtvt/zvzi1IsZUg85yMJsQts8zxdnUMozKNpoe9722jzul7z/2PoZgUA5b4t5mift/scSJllWN b5dUokw3Zf6NyNmq/Ysy766Ip9czcgm3y0yCOdU8lcBDV6m/WaWjv1glPCWeL/OthbI6+z/N48mg Gx4dhRO3NQ99tzud4TzOhkO3Neh1+tPJ8Kg37DzMo2JZDBxT23ccv99/ffX9/tsBhtEKVXXWxEdz LrXHSSbPaPGutP2Hx3AcjdAuFXjwruQtejQxGM1BfvwDAAD//wMAUEsDBBQABgAIAAAAIQDtoGq9 SwoAADE7AAAUAAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsW22T2jgS/n5V9x9c/p4dXszbVMgW9sDt VmVzqcxs7WdhDDhjbM42mUl+/T3dkoyFwUDizdUlY6oGWW5a6penuyV5Xv/6vImsT0GahUk8ttu/ tGwriP1kEcarsf3nw+zV0LayXMQLESVxMLY/B5n965t//uO1uM3XwSaw8Ps4uxVje53n29ubm8xH t8h+SbZBjGfLJN2IHLfp6maRiifw3UQ3nVarf7MRYWxbsdiA7QPz+n36MLPfaNbTCPzjPKMOP0rv iXGg6N8F+VOSPlrtFtMvHttElaWruRel1icRje0WX/bNm9c34lYRRHmVbsaXolMEi8dOhV+3i0n3 C35MEOVVumGLPgU/JhC+D0mqY3u4Wpq2RCSbVd79/giX4l0iks1uZc6GbCUi2XQq9IbOSkSy2avQ TzvTzmRizIeJJH2/Qt/zhpOhSc9E6yiMHyvUg+nImw4V94JkmUS/HSW/G94Np54i31PB+oX30BDL JM6P+ZJNDzfiY5LOQEE3kcjD2Mo/b4Ol8OGkkzQUEfEXt4Eo9csuPzvowsAGu00YN8p7zw4j7aVi GTemiP9eLkM/YAmXYRTd55+j4G3GQmZJFC5m6KTfMXiDAkLbNZpKoQbdKhX8GytN8r/CfH2/Flso qM0jrDLFepVZ2yQDErn7KG8aFErOJWR75H9Sm5nI/0gWshvAU/0QtGDDuF5xdNADdYnBpYN1B4op eH7NYG2a1MWjtXlq7DvGaIXIR0VDZ6FN+LwlKCq3+wifNLSV+SIKFqR3GeW0WUirut2IibK1WATK RiR31UZtNpL2FQ7V8J0jNhry1E86Gz/YjzYitt8w2iVGKgk3ck4Mp633LVbScV5bhpVzCMcoLoMz iq2nsT3qdXq25Yvt2F4iJqG52cLqWbyyLRGtkLf9PJVufxbMh/rVgpkgaLd0f0VgIw5s0yy/E9la ugY/Ui4QxTSSnH+nB7U2JYD09K+YRXcIZ/ifzQJ6NE0bLJeBn5eNXeoh3clbFUqTXR6k9+vFkzWP dukHAfOTq0KeRZjlY5sjAt2kY5u0zY/M4KxC1ZESiUYT0XYtVLgliGokS3J21WIOfFeaHmQ7OncW 7npRGPINiVJ2459MFEqVQRx0F2QBH1V2KizC69hO0nydIApt16E/S1HscOyAt1iILpSuLdT6/J0G n+hbYk7yIG5RuFrnH8KVlYbIR/k6DYL3CEvsfWeYtVXukiw1I/ao0nSzrZz2PPgURA8UA/uU221r DVfnaKLCANMd+p95rxA0X1GRU8abEUOKskJi4HtXPhLMEMqMw1zQaP0XU2RtmZWP/D3/XOfesiD0 YF9mORoVGKyUakcK9l85hStTrYxYFYk7PT05WLEqMTqLgmgr8rVFf5D/wtSP9vXtQ/IBsdXCIpCY wW3g1a9k4WFRgJSdcxROslM6E7GSqlXVLWlNJ+tGyqi9CYpxD5RNM7vE3lcquyjOzOEMLDapbKVh Q9ey76SqYdlDiKJrqRcybBjecShvCyTzjzD0HdZnu0huFGRb3DEOtu9Ta/6ERQQWJmKXJxzknpfp hp4my6X1zCHuswpwyGHPueWjs40iAb26qNY/8XdZ/q8g4Z+LT4gq7LurhW6JtW75z7FupsoPpQ/i L1SCv3A9trK4JaeTxJC2PEScULziMRqtovJnLZgR/05UcuI2TXbxgqexDsRiGi94lTu2Y2wH2RSZ I1ShUYB8sQkWslLPRRjtCXOsmuMV0HmMGELLSrEoJ6SDZLAe2WmeLD7DjtigAoTXSfoFXJC4UPz+ ZydS8Ix+j7HCHLUdh1TMN05v0CFNl5/My0/i3cZLEBxgaBH74IocppteLi3kJxuY5m18v/WJkOZC Knp4/kukW5VHc3jMu4TXvkygvQJC7WnZcaUYxCTKZM1H7UWwfA/hNiJ9y16BxgduhPEC20XclPV9 hOQaLB/E/P6LEpYEzGmXC/t14m3spo8sD20DTHhJMBcZqYe2MNRjkK5hCezAvd/FPthLsVCWbn2a Trb13yNq8uaZii/SGGUKV6NrT1vEq62/fzpZyt2FEs8SnXo632GN+PDM3jXf3X8pmrQDU9y8g6cx SS7mGlfQxgeo7nG3CTfJx5D1EPHqOIhf/XmPpTEURdFdYc2SJDvttxm88hGBIU7uuaXWBdKpsU2z EVH4JfiN+ZImsfgGNbhlm9yLAsHlEduT1zkFWAt/NsBVhFap3BMQLEMAjnJ088ny1yLNAvYNaRyp CfYy6U/c3LsZZlTExCi+0+Z7CY7HNrxOWOYlOMo4+RIcX4LjjxYcVUxEmKwWk8jvqUCKuuc1FXIP RXyzk3p8TXF4OMVVwbGzKWc2cAauWlc3cDbFywadX9Xh1bGzKa9FHzWuIpBnNdWzqWFvNOzr05cS kWx2uGIobyb1ZvRRvEtEslk9m5rwZdAzkaR3KvzvJvQx6JlI0lfPpryON3HNs7L6s6keXQb/mrMp Q9rzZ1PupN1pdxTz02dT8KQ/xNaar9pjG2ZERfuMFg4lUcasOtSHVv6MFoyHklUeK2J9Ixu6B89l T0HT1T1dTePoHkf39HRPT/f0dU8fpSOduaEGpy/b0iJgR1odxynZquio9pzCS+ckXrpeaV3cAF6c u5bb2uOPnfkYXozz0zN46ePqdg3/YVApS1T82fPoRNmg53lI+ipeXJy0Hpy1NooXd+gOJ3fGfGrx 4o46dwfzr8GL542wv6S4n8cLHYwXytQuxpVt4Twq8v7EeOmexAv5YvGeQAN4affao84FeCGzzXQO OIMXZzYcdU1/q8WLIVMJVKfwArC4E/06QIlINr89v7gdz5loWSXTWrz0PHr7wcBXc3hxht2BN1DM X/By/GUh57vhZdhvtdra1nX1GPBSvFN0Bi+zWSVf1OJlNutjFoa/1eYXr0uIMegbzS+zGco3rZML 8DId9JD1jfk0h5fZrFRQvODlOF563w0vZIyeo2xdg5dr6rEuriIXSX+rxQu93VfkTElfixeqxlyz 3msUL7TcOZh/bX6BBq/ILyRrga7z9RgZqJjMC16O46V/Ei/GO6EN1GNYOPQcHasbwstgNHBHmucF eOm7zsxtG/G5Hi+I/gf0jeLFnbozz5x/LV76LWcwuTi/DCYTz5sqac/j5cJ3UX/u9f6gEbx4usav eXe7g1foSvtt7Kffut6ntU4RQS/By5Xvbk88t+ua64uzeJloD5Xzqd0f+3vf3TYAcB4vboc+Cl4v +eV4fhmexIuxNm4gvziD/sjRe6cN5Rda6VyDF2PH6IJ6zG0jfZn56CxertlPnnawP3bF+sUdDScH 8tasX66sxyZODy/vvOAlULuA8oTm4PxldBIvVM4W6msALwMP77/r8FWDF8Onz6z3DdoL8su1+8nG Wkryr8WLobOL8ouHFZJRH9bWY9ftJxsV9fn8Qsm62Gi5LL/wqQufv8BBbHn+ApOp8xcY2f7Rzl9e /pmOC8MSFox/KPz7AfP/98905QXMjwEYvAhgnljysT96+eXTN/8FAAD//wMAUEsDBBQABgAIAAAA IQCuZVF0BwYAAD8dAAAhAAAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEueG1s7Fntjto4 FP2/0r5DlP25opAQQkADFTBDW2najsr0AUxiIMJxso6hTKuV+lq7j9Mn2Xv9QYCZbqGdrXa3qBLj +OPaPj733Gv34ukmY86aijLNec/1njRch/I4T1I+77lvb8e1yHVKSXhCWM5pz72jpfu0//NPF0WX 55KWL0kpqXDACi+7pOcupCy69XoZL2hGyid5QTm0zXKREQmfYl5PBHkH1jNW9xuNsJ6RlLtmvDhm fD6bpTG9zONVRrnURgRlRMIOykValNZacYy1QtASzKjRe0vqww7jCUvw73Suf9/QmZMmG8Cp0fDc /gXpqn3SERPOmrCeO517br1/Ucch0NmUcHBZ3ApKscTXz0QxKW4EfsSv1jcCbIJJ1+EkA4TRgGow 3dQnh27a8N7wubVEupuZyHBFAI8DK4RzvMNfGES6dCOdWFfGVW28eP1A33hx9UDvup0AtradFHel d3R/O77dznNKEiDIDSMxXeQMywojtUU9DmAsrvN4WTo8h00jFnqvgI61jADgXMXCkXcFwLRIBDDz fc/9bUUEUNAM0f1glXw7tFRY2w38PUJ+p+1FDQAPcQpabaCoMlyNLkQpn9E8c7DQcwWNpWICWV+X EpdNuraLOn49e9GVm2Ge3OFpTOEvHDo4HYxf5OK967AXvOy5HS8IYGqpPtTkriN2W6Z7LZKNcuCc OWNWyom8Y0Ax0mVr5sGmHcLm4NRMrS+hszdQhYh51a5MT7XsXQtwrkAbntwQQXAYI6gHlNfeTgwe 0ANQtruCoubC5xnRtIy4JJLu8cFHk9/Kh0S6xjdPZkIzioLQg/VVvmE95v/IB/G1fJixREnVh6EX esOrUavWvhp3akHQimqRPxzWosvBuNluDZrt0P8diKwcNYHjlmlGx+l8JejrlXYXcUAqp8zkiFEC fDWEBgIr8ZL9sO57oPOeh84lFVdhKY/P0MAydMLShDovMjLfJ2rzy0QFCXuTg1+jnOejBbgNHZQF iMRxqlay5EU2N0xWfqGkDLVPFawcfkbTPC9oNlC+gMlh1EIlUxhaOmtFM/LWDPwOdtaiZeOHFa+j 9I1AEjBOGVOTMO68Q3Fpg008nDIHGLEVP9BsFSYhGCzNvDu94HQZVxv9DqLpEB6D+PbcWKrYAXMb BVWb+QcEsGXp9QoTpz0FDL5MLDylHY3EAHcQETGu7IdELYiKtSfRyFAHWRQ04d8hjVpBFGKljpJA OkO0bZZQxcCjaASL+w4njjTkkIgOVjKfpSZW62CMTfePH0MoBMitIoETku6XhUv2RyyNl47MHZqk 0jEpskQnLDFEl5WOoV8DWMpD1I+dUqVAMNuxU05onPPEYXRN2RHmlbScYP52kYrjrSvGnWB9nK+E XBy9eOUtp5hPZw9af+wMJ7QOPs7Bw/dz3tZjePgMpGov59UOrvA4ycF1hIjAz33Ie5Tg2RDxn8x4 tmI+1Zuxvoze869MhtuWKjrVeLXKpgeECR+DMJBOgOmHOKP4eBJndrPkH5E53542+8OrsOlFXu1y 0BnVgrHfrA0vB0Gt1Qm8xrjteeNBuE2bS8xBORzecRGgypY/ffzjl08f/6yCwFfnyios62cLKNrH kJiJl6Rw4KkDrpYS8ly5gVKyhNJ07mMd3P3lBkrJEkokjuF9BXqYgq2Bdl2z7dO0NXAT002BrYHM XNe0bA0kU7omtDWgvguW8iXcqfGP68xy9lxX2JJ2KfVude+unBFxjZF+e2l24MZ8S6YTuDCrizk0 CamSAYeSaz4UMBPsGR+euPmELpjxw+vWzYrrlB9P7/Dq7SypwMc2vIZj+04KfO9FCcDFVUOSsNdL zaouWDN4V+m5v2a8xqQWP0oOGijRDXF50BCXxrZeoZpm+yKglNPHHEhDY15DzvgwBMVElmaFjyWJ fXT5cfmDoBh8ggofr9n2Qrw0nAFCVAxArR2AIj9Sb49ngBAVA1BYAeT7ERDozCCQaETFANTeAagd NDGonF2MISoGoKgCCNFRDxdnF0NUDECdHYDCVvss0ir1QVTUm9tuvog3puq/Pft/AQAA//8DAFBL AwQUAAYACAAAACEAtM9YGbsAAAAkAQAALAAAAHBwdC9ub3Rlc01hc3RlcnMvX3JlbHMvbm90ZXNN YXN0ZXIxLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7S9iAiTXoRoVepHxDSbRpsk5BEsX9voBcLgpeF mWXfzNbNe57IC0M0znIoaQEErXK9sZrDvbseTkBikraXk7PIYcEIjdjv6htOMuWjOBofSabYyGFM yZ8Zi2rEWUbqPNq8GVyYZcoyaOalekiNrCqKIwvfDBAbJml7DqHtSyDd4nPyf7YbBqPw4tRzRpt+ RLCUe2EGyqAxcaB0ddZZ0dwVmKjZ5jfxAQAA//8DAFBLAwQUAAYACAAAACEA+c8JOYMGAABcGwAA FAAAAHBwdC90aGVtZS90aGVtZTIueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbrU0bxG6HHmmJ llhTokDSSX0b2uOAAcO6YZcBu+0wbCvQArt0nyZbh60D+hX2SEqyGMtI0gbbsMWHRCJ/fP/f4yN1 /cajmKFDIiTlSdurX615iCQ+D2gStr17w/6VDQ9JhZMAM56Qtjcj0rux9f571/GmikhMEKxP5CZu e5FS6ebKivRhGMurPCUJzI25iLGCVxGuBAIfAd2YrazWausrMaaJhxIcA9m74zH1CRpqkt5WTrzH 4DVRUg/4TAw0aeKsMNhgUtcIOZNdJtAhZm0P+AT8aEgeKQ8xLBVMtL2a+XkrW9dX8Ga2iKkla0vr +uaXrcsWBJNVw1OEo4Jpvd9oXdsp6BsAU4u4Xq/X7dULegaAfR80tbKUaTb6G/VOTrMEso+LtLu1 Zq3h4kv01xZkbnU6nWYrk8USNSD72FjAb9TWG9urDt6ALL65gG90trvddQdvQBa/voDvX2utN1y8 AUWMJpMFtHZov59RLyBjznYr4RsA36hl8DkKoqGILs1izBO1LNZi/JCLPgA0kGFFE6RmKRljH6K4 ixkdCaoZ4E2CSzN2yJcLQ5oXkr6gqWp7H6YYMmJO783L79+8fI7evHx2/PjF8eOfjp88OX78o6Xl LNzFSVhe+Prbz/78+mP0x/NvXj/9ohovy/hff/jkl58/rwZCBs0levXls99ePHv11ae/f/e0Ar4t 8KgMH9KYSHSHHKEDHoNuxjCu5GQkzrdiGGFaXrGdhBInWHOpoN9TkYO+M8MMV+A6xLXgfQEVpAp4 c/rQEXgQianKXO5odiuKHeAe56zDRaUVbmleJTMPp0lYzVxMy7gDjA+reHdx4vi3N02hdNIqkt2I OGLuM5woHJKEKKTn+ISQCns9oNSx6x71BZd8rNADijqYVppkSEdONM0X7dIY/DKrEhD87dhm7z7q cFal9Q45dJGQFZhVCD8kzDHjTTxVOK4iOcQxKxv8NlZRlZCDmfDLuJ5U4OmQMI56AZGyas1dAfqW nH4Lqke12/fYLHaRQtFJFc3bmPMycodPuhGO0yrsgCZRGfuBnECIYrTPVRV8j7sZot/BDzhZ6u77 lDjuPr0a3KOhI9I8QPTMVGhfQrV2inBMk8uKfOaKvC1oZUrsnqjDy3Anq2+Xi4D++4vvDp4m+wTi fXEHuqy9l7XX+8/X3mX5fNaKOy+yUH91n2MbZNMux0u75TFlbKBmjNyWpmGWsGEEfRjU68xJkRSn pzSCx6zAO7hQYLMGCa4+oioaRDiFZrvuaSKhzEiHEqVcwiHPDFfS1nho2JU9Ijb14cHWA4nVHg/s 8Joezs8IBRmz7YTmIJozWtMEzsps7VpGFNR+G2Z1LdSZudWNaKbUOdwKlcGHi6rBYGFN6EQQ9C9g 5XU4q2vWcEjBjATa7nYTzt1ivHCRLpIRDkjmI633oo/qxkl5rJhbAYidCh/pA98pVitxa2my78Dt LE4qs2ssYZd77128lEfw3Es6b0+kI0vKyckSdNT2Ws3Vpod8nLa9MZxv4TFOwetSN3+YhXBJ5Cth w/7UZDZZPvdmK1fMTYI6XFlYuy8o7NSBVEi1g2VkQ8NMZSHAEs3Jyr/aBLNelAI20t9CirUNCIZ/ TAqwo+taMh4TX5WdXRrRtrOvWSnlU0XEIAqO0IhNxQEG9+tQBX0CKuGawlQE/QJ3atraZsotzlnS lW+yDM6OY5ZGOCu3OkXzTLZwk8eFDOatJB7oVim7Ue78qpiUvyBVymH8P1NF7ydwZbAWaA/4cKUr MNL52va4UBGHKpRG1O8LaBxM7YBogXtZmIaggotl81+QQ/3f5pylYdIaTn7qgIZIUNiPVCQI2Yey ZKLvFGL1bO+yJFlGyERUSVyZWrFH5JCwoa6B63pv91AEoW6qSVYGDO5k/LnvWQaNQt3klPPNqSHF 3mtz4O/ufGwyg1JuHTYNTW7/QsSKXdWuN8vzvbesiJ6Yt1mNPCuAWWkraGVp/5YinHOrtRVrQePV Zi4ceHFRYxgsGqIULn6Q/gP7HxU+s18p9IY65AdQWxF8dNDEIGwgqq/YxgPpAmkHR9A42UEbTJqU NW3WOmmr5Zv1BXe6Bd8TxtaSncXf5zR20Zy57JxcvEhjZxZ2bG3HlpoaPHsyRWFonB9kjGPM563y Fyg+egiO3oG7/ilT0gQTfF8SGFrPgckDSH7L0Szd+gsAAP//AwBQSwMECgAAAAAAAAAhACqG9qiG DwAAhg8AABQAAABwcHQvbWVkaWEvaW1hZ2UxLnBuZ4lQTkcNChoKAAAADUlIRFIAAAEYAAAAoAgD AAAA4L6DEgAAAMBQTFRFKSkpMTExOTk5QkJCSkpKUlJSWlpaY2Nja2trc3Nze3t7hISEjIyMlJSU nJycpaWlra2ttbW1wMDAzs7O/95Cc3OMc3OUa2uMY2OEWlp7WlqEUlJ7SkpzQkJrQkJzOTlrMTFj AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM53O0gAAABN0Uk5T//////////// ////////////ALJ93AgAAAAMY21QUEpDbXAwNzEyAAAAA0gAc7wAAA5KSURBVHhe7VyJYts4Dm3s xPGt2Gna2Z2mHf//Ty5IHAQoUiRjaXsMldmNW0MU8PTwAEKa+XTtRxKBTx2XNAIdmAwzOjAdmDbR 6IzpjOmMaUOgM6YNr64xnTGdMW0IdMa04dU1pjOmM6YNgc6YNryW15hztUPVltWG1ZceGy4OzPlc G0a1ZbXhHbhclwbmfB4qkam2rDa8B5elgfFBDOfXso/VltWG5WtOWSzLGCA9IlN0stqy2rB4yWmD RYEBRDwsZWSqLasN78Rl0VRyN5dwKehMtWW14b24LAmMwyRQZphwtdqy2vBuXBYEhrKIf01wptqy 2vB+XJYDBsVFNMZRJ+NutWW14Qy4LAYMyQvFQhglHa62rDacA5elgEExQMaI0JxTOlNtWW04Cy4L AWMACRmV0Jlqy2rDeXBZBhijLkIbz5zI7WrLasOZcFkEGNW+eI0JVTtGptqy2nAuXJYARosKJoD0 eQ4n5XqF5c2bVxhe0XK2Y/4tAVZoXVpRh0WLxfcKy9tnF6+u/HxSvCRaznfMDgwXaOlgTDOjdabC 8vb5M8SrAVT1n2+A+/qKljMecwMjzQbvHoU9qnpTelAlz1u6aCHeGAyzJNKRLH9hYK6hf5GAdf/r w3jxulG0xGgBmSnKeHTFcj5k5maMFkpGRlHCo7E7XdzkSrV+SUuOlpAJ8GrGeHSV5WzI1ABTOZt0 oV6vrxe9RRLJVfR53B5efD9jexNONbYM0SIyGl4DksKlSmfKUzPnXAUwTjaqboRz9/X6crJuRyEN q8fng+tnXiHrJiwJF/5lcLFLRpYlV+NeKmNfBgaLb+lyXFSHy3A6RAGb8B/Wm51X6OtlOOTJJYDI hxxlRpbTruK1y0cRGEyGirVC63Lcx6oSglqtn5490sP55XxyhjpgOU8RJYlMuEDCcipq6rHK0/kS MNQsQCAFkIN+nk7HXU4QHhAXavdOx32aBxytXyaBTEAzaZl3VXrNImUKwHA37/yfXEvuPPgMyJiA A0oGl+HsDSPGaChIj03wtnSrr/SJOVfV7qSEzDQwPAPBezyxlmrawTYKWGJ3uBAFkTZoGKDB6wWK UDEaKzCdk7VMu4rL030qIDMJDIfLG+TsWvqK7tIWGWYM4qJ6lhEyniIKBpagETK4yIRlylW5e/hh GpkpYIS1yMA8Z1igRTwMZ5gRXndVyvmzHISSah5fDQKfqiHAi7lzJi3HYbO20b0pVNoJYOj63gui YBplNGRdw086YIyE+YIwyJpGkCwLhPYmvTgXI7BkWYYrRoblknGd1oaJBo/0JZogJPinhMhfFAN3 tYnSxht43Q13mz4SZ4QZI2pwMskXBIDlC1PVf5lGRsLRHyayKcsYFYPcDBf0aC0x5MyjW0rCSkwi 3RUSkBGTi5AZZwdTcSTJozwaW2pXRRakYPubmEcmB4wuHjo5R5kpzA5KQWTVSeL0Re61LkOsM8gg U5hl5agEGVoEP5GtGc7wtUd3MYtMBhiVkEE7CCCzFiWO2r3IvVEKLHXaMobVhgXJNiyciDKeSDS5 gcysW96hOJsoHJFdpQ85ZCJgbnxYxqm7AddVa0UVUCedVO3zQPUoRxkv1SBIpisJNA1ZkNhABfTo E8ZskWEVFM1jagGEfMQA5YAJGUufRAV1ZgZZsZSmm+wDvt3Wah+gqCUyQ1JtVMNQgXIzxKsGWCNk bCl38YYyqGSQkqoZGDlh4oMbNeH6yjv+K67aEO7taSO3U2y5kFDlPp2iJi6coeWOjPRgTylWwrIm Dm8DYxBz5BhDU8XJXzQ+Et0g9oe2m7P9NogyJ8QIIbK4WGIp4AMyMvBUa+tbpDHMhyHAnf1UMRz3 AMPDWEUHo/7whwQN4juMAhAbahIalDhewsXSNWk5fXMZmUNUuu8CZoSMyD51tnLXzDw7yhIXW9yV iKLFWsMQ+gVNa5mznOa+MGZ7uszHGBngcwnRAhPCxUm/tBCa+lRkGZfVCvPStKkRxT4549uDqjSq Fmp0Hh4qskmAeT68mFzKMaYsWlwZtPCaIs81kwyVMhpVUAm3Wq/WChTWZ4Pkw2oFDx3h/wlTI/yB scP5YbVel6MQi00lMFKkeQOpfoNX6/Wj7cY47LFO3ibLsG46zsP6EQuYamKicgzhPg63Aa7/KBQc 10RY4sGt9bx5evKG2Z92YHwVTh7Ot6fN5mnUj4XGxMrpGBnWaP9bf7153m5j3dVFGMLd+EyDoHF2 HDCkaoh/4Xrt3WG/320BnHwsocErpNL1ctw9Pa7X6zzGq9XTZrvbwSVHnKGmxv9SX0YDJS2sCheM fwexSOro9fxZuOXyeIALW1sOVYvkcTmchmE4HQ/gaT6aB6C/4//T7jgpvtAmHnbPQAeHsuJ0+Owu uT+eoTM57pM9me3JcY108+bdjfZH5+ORxxVqZ0O+4OiC/rCHkIlcLG3CLTDcHs4+0suL8zQbDUAN 7N8Au6bLNTxIPB8PB4dyEhZIXXdJ//D55XwI2RTpaZxmsSHngJ3veqRkLKq7Nb88jdLZsSOP0kPd JtnxTvKWDmoNeJqJxrN/vz8cjoUGDx6xAsYvjg/A6PEPAOwu6QvbK7Arg4xiCN33NDJ2/uKch4OR kZQjXsjogt0Khjr5PIDbo97qOk8z0SD7X14uhS2B73FeXxHlsWaZWwGWQwqZeBiL7BhJtfvrcYoZ zmhpRb6w6uCHQK4A4nCmm2e3PkMuGsd+H3B0ZCd48GjZPWI2P+NLBmTUTYuqkCdCcjOU2B9JwJYE YWQsHrk1aZDDCsgJF/IoRDsAMxLRuGfoyWPqKYFHRmlwzBe3oOIMhxLRQBTRtv2wbmp/hIuogTHm F43SlTfIHTYM9WmURxx2TTT5TeSIfwqZFC4JZGIakCBaIOJ9ozT4FKF6MOVFivNIkovhpvmp7B7T TvqwLDITht56+kmky0xO32TqjjkTl18hjOptTGopA7Wj0LWJRoCUkqQzzE+euaNCT4ZbE40wo/Ds 2r2pgXcjf0mtwFFbgpFybTY6kwSQiMMKTJjhoxd2BFdjXFhnSk4SZ8rRMDLFtx28midKoEo6pcDj 2qOC0AocGwatpcLjHvP6B1NKXyKyEOr0dkXBSc6mYjQUWAkYyEznXC6PcJWAzGgYqxjjY2dAElNb RQUWVt/a4ijdEkYxBhW47KRwphQNxlQExmsWbBpTJVBYI8iYYSyBImTQyMSGIi+jJHl83OCrACEj Qw1CwFCBS06KAlcZloG5DkfYou5MKzmq/BoZHjqGWEyehOmRMkRbcwYFvOX9dgoXPsUhs30uOYnI VERTxxhY63Q4nvz2KH8EZGy4EToOIkZmbGj1CExPEPHBdFMx2lQ1vWHRSUSmIpqqVAIj2D3ZPXkC IEZGhrFaBgJlAjI5Q04ZDQEJTII0uLL/YhiKTnq/a6Kp0Ri3VmIvkckmfL9duSvaEAK1U9tgqwsx foaRyuV64T1bIjcZ8f3J3bryK4fe65poKsR3OoXUt44zt9VDUAoDT4gKp7YwH7KcEHENC2x2LoPd C8HhJwivEnU0nPWoEN/q6wEyGzdi5cg0A0IyuWHs0+3JHbbWsImYwhvB+HI9zJqohUkrsBhWu1o2 nBMYUPz9FopDhIxOJteVPLrJ6Bb+h7NJFWuQFwfO6nGzp7EafZGp2cqwHHCtxazAwBDnCFWEhraR +uIf3c5if4Qi4o7wMmtELup3d0dKkBc3M+CKrlLInwZLimFt2GW7eYGB8R/MWE/uLd+wnQmzAsTF T0YvFxBLHDkqHgT2RHszmKaoamWgKW2TyxgkLeYFBiUf/iUBHKJwMBIIBcHVg4ZhCg6JPh6r+J1J qixl5y8fBIRPmx0Yh43fYEWBEOnjYSwOSbjGy+cxDTLILMSX2j6mGX0OIxQjFIPxjouGJCQhRIrU nlVBGEr29Oa22W11whKMcctHYTjJydzcgCGxjJRo9G91OJ0hGjIyS+URBLAUMAGZYhCCIetSLtww gSMiLpZHSwIjyJB+FIexUsjy6YHIiAQvictyjPHZJD3w9KQrcAaCngoXp2bEweX0xWnBYqnkdYZb ea8vExMdhWFpVigt0qJ8WRaY8MCiGIQU4xIN6BkISvn08OyemrQwMPwwsxQtV7HM41UTIT0fLUJ9 HyxLA+N15gzb6cmJsY+h2tIjU7XkXdgsqTEY7wCvnxQmxoSMt5TXN7JhQT9TueQ9yCwNjBtF7PZV YlBtWW34SwMDW2j6r1wU3ay2rDYsXjJvsDhjagexfvNZeVQbVq6XMlsemDuc+5mndmAy6HdgOjBt idkZ0xnTGdOGQGdMG15dYzpjOmPaEOiMacOra0wLY36E4/17G9DeWp1vPzaulV3HffHeuFjSq/f3 b9++JRdKMubHP+H40Xp9B4w6X39sXSu3jl+zHZiMV38aMM1UzsGcRrgz5p80j39fYGZjzJ8GzGwa 04FpKgm/byq1lrjGWtmB+Vnia5q0xp5oso+5jzHarZ/T4DX7r9wU702XyH/biLJNpaJbi6eSujWt kYi9YU4xpNxl2lZZHJj7NhcYZFtIdcCEG5a2/7cCU7xfHZhMav4fgWluVZfUmF+JMc2bm38LMOm5 R02pWkB8fyXGdGAyu5IOjAEG+4X39+/ffylgnE/glTt+Uh/z4UZV+ft+z+D4gxK+eLmeA5hvfyQw xX1suS79/ScCM0dM/5ljkcYd1+KpNEdMX+dY5E8E5q0Dk9abDkxGhw0wH96Ltm0sfguN+aJT6XcG xjRkKqiPxmSA+XADPQdj7uw94NUKOP52P+7AT/Dz0Zje3r68fYF/3r5+/euv/5b7nrRF2xsp/cWh DM4dmA5MWwp2xnTGdMa0IdAZ04ZX15jOmM6YNgQ6Y9rw6hrTGdMZ04ZAZ0wbXl1jMnj9D4rfY72z KR6XAAAAAElFTkSuQmCCUEsDBAoAAAAAAAAAIQB9tfa6AIAAAACAAAAXAAAAZG9jUHJvcHMvdGh1 bWJuYWlsLmpwZWf/2P/gABBKRklGAAEBAQBgAGAAAP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/A ABEIAMABAAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAAC AQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZ GiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOU lZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T1 9vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAAB AncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Sl pqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEA AhEDEQA/AP7+KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvmb9qv 9sn9mL9iL4bH4tftUfGLwv8AB/wNJqNto+nXutpq2ra34h1e6mhiXSvCPgvwtpuu+NfGWpW8c4v9 RsfCvh7WLrStGgvdd1OK00bT7+/tvpmvwB+P39jf8RDP7Fv/AAvT+zP+Fef8MM/GL/hk/wD4S/8A sf8AsH/hp/8A4WPp/wDwsP8A4Qz7Z+9/4T//AIVT/ZOf+Xz7J/Zf9lf6TivZ4fy2jmua0cHiKlSG HhhM3zHEQw7isZiaGS5NmGdVsHgVOFSH1vF08vlh4VpwqwwcKlTHzw+MjhXg8R24SjQlSzDF4l3o ZbhKeMqYeOJhhKuKjUzHAZd7GjiamHxcKMqbx6xVWcsNXUcNhq8vZtq6/RX9lr/gpd+wz+2p4M+I njz9mX9oXwz8TtD+E0F7e/ESyi0Pxt4T8Y+FtLsNLTV5ddvvh1468MeGPiDL4buLRpYtL8S2Xhi6 0DWdTsdW0XSNSvtZ0bVbCz+kfgX8cfhd+0p8JPAnx1+Cnij/AITT4V/EvRV8Q+CfFP8AYniLw5/b WjtdXNmt5/YnizSdB8R6bm5tLiP7Pq2kWF0PL3mARujt8IfEuT/gn2P2kf2yYvBY+C//AA8Wb9ja 6k+MB0yKI/F4fBhPD2ur4WGpzFDZKxEnh4+JotMkHi2TwwPg8/jpG8Kx/CQrjf8ABDH/AJRJfsK/ 9kXg/wDUn8R13Y3LsrngM2zTLsNnWBoYWfA6wWHzaph68pw4jwnHNTMasMXQweChmWEjX4Xwn9mY 2lhMAuSrjadfD1pqlUp4ZnTjg8dgaFGGIhRxtDH4j2eOpKji6MKGX8JYzDpxjJxnSqvPsVVw+K5Y LMMu/s3HQoYN1qlB/dHwT/aa+CH7RWq/GbRPg542/wCEw1P9nz4ueJPgV8Xrb/hG/F3h/wD4RH4q +EY7WXxD4W87xToGiW+v/wBnpe2zf254Yl1rw5d+bix1e5KSBPlHxr/wV5/4J3/Dv4Q+PPjx4x/a E/sf4UfDL9o7Xf2SfG/ir/hU/wAcdQ/sT9oPw1pFxr2t/D/+w9L+Gl94k1L7FpNrPd/8JXpGj3/g m58vyLTxJPcskLfHf/BGq8sPD37Qf/Bab4f6zqWl2HjfTP8Agpz8WfiPqXhWXU9PfXLDwH8R9B0P U/A3iy90+G5kntdD8TWenai+mX06pFLNp2o2jmO7sLuCH+eHXrPxlcfsDar45+DerfDvXtf+KH/B 0ddeN/gRruvX+q6p8Mda1OZ9U0PwNqviXVPCyte6j4G1HxLokF5qV94Ou9QuLvwvObjR7s38qQxf TZHwbk+ZZxLA4jE4+OEnlXh9j8PWo1sPF1qvF+J4UWJSrSwdai6LwWc5piMtkqd7YWjUnPFwo141 /rIZFlKzniDBVMTiHgstzniTLsvqrE0KTxdHJ+HuNc9wftcV9Ur0VUxFHhrC1qtenQVOWEqYqrRo rnoypf1S/s+/8FyP+CW/7U/xi8EfAH4D/tQf8J38W/iPfahp3gzwn/wpT9ojwx/bN7pei6n4hvof 7e8ZfCTw94Z07yNH0fUbzzNV1mxil+z/AGeGSS6mggl/WOvy7/Zg/wCH1H/C3tG/4bQ/4dd/8KE/ s3W/+Eh/4Zg/4aw/4W9/a/8AZ0v/AAjn9jf8LW/4oz+zf7W8j+2/t3+lf2d5v2D/AEnZX6IeKfiJ 4L8Fa58N/DXinxBZ6Nrnxe8aX3w7+G2nXKXLT+LPGmmfDvx78WL/AMP6cYIJYo7y2+HXwv8AH3ip 3vJLW2On+Gb5Fna7e1trj5TiTCZRgsXh6WT3dGWGVWrL+3sLn8faOrVgorE4XI8ijQkowTlQlQrS 5ZQqe2SmoR+UxaoxxdWnhoyjQpwoxXPXjiuerJSqVKlPE06GFhOlyTpUvZ/V1KlWpVnKrVVSMaXa UUUV86YBRRRQAUUUUAFFFFABRRRQAUUUUAFFFflD8EP+CjaXWof8FP8AxV+01c+Cfh38FP2BP2gt R+Htp4x8KeFvHmpaqvw00vwB4Y8V3niDxppmnah441bxH4hhvtbuIj/whnhvTIpLNIIodAedJbiX pw2FrYtY50Un/Z+XPM8Qm7NYWOZ5VlLcF9up9cznBRUFq6cqk9qbT2p4etVjCVKnOrKrjMNgKVOl GVSrUxWLo4utQp06cU5Tc44KtFKKbc+SCTc0fq9RX5tfBv8A4K/f8E3P2hPin4k+C3wX/ar8FfEL 4jeFfh9qnxR1TR9D0Dx//Ztz4M0LQ9L8Sa5d+HfFt54QtPB3jDWdE0XVob3WPCHhLX9b8YaX9h1+ 3vtBt7rwv4lg0n58/wCCcf8AwWq/Zu/bw8MftW+LtQ8Z+B/hnpv7OPjfxfrV2urf8JpoeiaJ+zRp bx6b4H+Mvjbx/wCPfDnhPwtDN46udH8T+I7nRYBo+qeC9Jl07QfEOii90+TXtc9SfDHEVKlmFfEZ LmeEpZXluEzfHSxeCxOG9hl+Pxc8FgcVKNanCfsMZWoYz6tX5fYVYZfmEo1G8JVSJYbFRpQrfVcR KlLG4PL3KFGclTxOYUJ18FGokrwhirUKNGbXLUxOPy7DwvVx+FjV/aiivz+/ZZ/4Km/sC/tq6V8S dX/Zm/aL8PfElPhHok/ib4g6U3hX4ieC/FWheGra1ku7nxHD4L+IXg/wn4v1zQLdIzBPrXh7Q9W0 2HUJINKkul1O5t7SX568Tf8ABZH9kH4s/s8ftKeP/wBiz9pj4P8AjP4gfAz4B/8AC773Xvib8NP2 krv4O+AtH1G9k03QdQ+LaeBvhyvjeESX1vcpqXw/8MQTfFS3ghe6PhaK2jeYY1sgz3D1sbh8Tkub YevltLDV8xo18uxlGrl9DGwxFTB1sdTqUYzwlHFU8LiqmGqV404V4YbESpOcaNRxujhK9atGhGnK M3jKWXzc4TjGjjK2JwmDp4es1FunWeKx+Boeya9q62LwtKMHUxFGM/2Gor8zviV/wVj/AGHf2ZtK +G+i/tYftK/D34Z/Enxj+zd4S/aOaztfCfxZHhvxR4M1xodIuNa+HJufBl5qWtSan4ji1MeGvhuz 3PxduNEs5tRufB7W9hqN1Bzcf/Bbz/glXPdfAWwtv2yfh7eX37S09nbfCWysdA+I19d3kuoeLE8D Wf8AwnltZ+C55vgzHP4pM2lrP8Zk8AQr9g1e9eRdO0bVruy6YcKcS1akYYbIM6xiqYmtg6FTCZVj 8RTxOIoPFqpSw06eGftpxWAx0nCCc1HB4pyivq9bkwpUsRVweGx7wuKpYXFYClmlGrWoThB4Crg8 NmEcVz2dN4f6jjMLi3XjOVH6viKFdVHRq05y/VWiivzJ/aX/AG0Pij8Gv+Cjv/BN/wDZA8L6D4Bv /hr+2Dpn7VN78S9c17S/EV1450OX4HfC+z8beE18C6np/inS9A0yPUNVuHt/EQ1/wz4ma708LFpr 6Rcg3beflWWYrOMdHLsEoSxMsFnWYJVJqnD6tkGRZnxHmLc3dc8ctyjGSpQterWjTpKzqJq6dGdW ni6sEuTB4PEY6vd2aoYaPPVcV9qST92K1bP02or4X13/AIKU/sU+Gf2cfiP+1vrfxo+xfs9/CX4m ap8HviD8QP8AhXPxZuf+Ef8AiNovjfTvhzqfh3/hFLTwJceN9V+zeM9W0/Rv7X0Tw3qWhTfaP7Rt 9Tl0qKe+j479o7/grZ/wTu/ZH8YeIfh/+0X+0v4d+GHjfwz4M8F/EDUPCuqeEPiZquuX3hP4g6k+ leF9R8L6d4b8E61ceNbi4uY5Z9V0fwcmva34Y0qGfXPFGnaNosEuoJVDJc4xToRw2U5liJYrESwe GjQwGKrPEYuGEwmYTwtBU6UnWxEMBmGAxsqFPmqxwmNwmJcVRxNGc6hhsTVlKFPD16k41MVRlCFK pOUa2CxtPLMbSlGMW1UwmY1aWX4qm0pYfG1KeEqqFecab/Rmvmb9qv8AY2/Zi/bd+Gx+Ev7VHwd8 L/GDwNHqNtrGnWWtvq2k634e1e1mhlXVfCPjTwtqWheNfBupXEcAsNRvvCviHR7rVdGnvdC1OW70 bUL+wufMfiR/wUu/YW+Ef7LvgT9s74hftG+DNA/Zu+KFt4fuPh38QBYeKtXvfGkniXBsNL8OeAdC 8P6n8SdU8RWSrdy+JvC9t4PfxH4Mg0nX5/GGl6FD4e12TT/bv2bf2nvgH+198KND+N/7NvxO8PfF j4YeIZbq1sfEmgjULSS21GxZVvtG17QNcstK8S+FdfshJDJeeH/E+j6RrdrBc2lzPYR293bSy6f2 ZnuXKpmf9n5tgI5TmiwVXMPqmMwqyzO8JKFaOEqYv2cFg80w01CqsPKpTxdGShUUItJhSrYnBvCY 2hVr4WVeVR4DF0p1KDrSpqSqvCYiDi6kqceZVHRm3Bc3NZXPDP2Wf+CZv7DH7FXg/wCI/gf9mT9n vw58MdE+LltdWHxGvI/EHjrxb4u8UaVd6YNIfQrz4gePPFPijx7b+Hbe0M8uneHNP8S2ehaVqV9q etaZp9nrGq6lf3Xxton/AAbn/wDBGvw7rOkeING/Y6+x6voWp2Gs6Vd/8NB/tT3H2XUtMu4r2xuf s918b57WfyLqCKXybmGaCXbsmikjZkP0n+35+0P+2l8Mtb+AHwV/YT/Z78P/ABS+Mv7QHibxTZXf xf8AjP4d+LF5+yr+z54X8C6VY69qmt/HHxH8KdKl1XS7zxrDcS+HPh/px17RJr7W4rm5hTWXsY9C 1T8xLD/gtV+0v4b/AGZvjj4a+IvwZ+A+r/8ABQr4Z/t5aD/wTk8E6X8OvEPjlv2TviJ8b/iRfufA vjZNW1ia68b6B4O8MaTHq8njTwdq3iW28TaheeGLe3udb+Huo+NBovgr63JP+IgZi62eZNxFmqzT N8TlmCrOjxJisPnuZ4elm1Dh7LsbiWsXCvWyrAZ3m8Mqp4jF1lHA1sViK0YU8DHFYqHqLDZtLCTq LFzlhsy9pVx1KONlUc6dTA5xXrV8yw0JznJTy3hzM61WNWnUrzwOEpzlSdCthXV/S/8Aap/4I8f8 E2P21viInxa/aS/ZZ8K+OfiUdPt9Lv8Axroni74m/C/XvENrZ21rZWD+L734S+N/AzeNL/TdOsbL StL1XxaNa1TTNIs7XSLC8ttNt4rVO6+KX/BML9g74yfszeA/2OPHP7OfhZv2aPhn4h03xb4I+FHg 7XfHHwy0bRfE+l2XiCxh19tT+Gfinwh4j1TVr1PFfiO812+1nWtQn8S6zrN9r/iJ9U1yY6iPlL9m L/go38cPCut/to/Br/gpR4K+Efgf40fsV+FPhx8WfEvjH9k23+JXjr4VfE74SfFvTtTn8LXnw+8E eIU174wHxZo+t6Pc+FdW0a/09rrWNWvLCfS9Ns7CWGa7sf8ABNz/AIKbfE39s7xp+31cfGr4IXf7 M/gT9lnxn4KtfBngbxr4e1/TfjloPgPXvAGo+M76++OmkDW9ds7Lx1NYWEGuz+DfDWh6bceDE1J/ Bl/J4o1jSJddv+GtT4twWAxUI5/iHkvCOX5ZxPQq4biGpLKcFh8XjMFh8BmGTxjiVThiKGJzWDrT wtKnWyur9Yp46WExNqVTmlis4oVaNR4rHwxOBxtPIsF7PF1JYqk8xy6o8PTwEadZ1lgMxyaFOVKe HSo18vxWEpyXJiIUn13wF/4IXf8ABLD9mP4veBvjz8D/ANlz/hCPiv8ADbVZtb8FeKv+F2/tF+Jf 7F1OfTr3Spbn+w/F/wAXdf8ADeo77DULyDydW0e/t187zViE0cUie2ftkf8AJxX/AASd/wCz/wD4 j/8ArrL/AIKWV8kfsR/8FV/iF+2h/wAFBPjd+zzZfAbX/g9+zr4I/Z18MfGH4S698XvBfirwR8dP ipFrPjr/AIRiD4l3PhnWtYt4fCfwq8ZWRnvfh1oOseErfxhquhWmneNtT1WytvFMHhXRPrf9sj/k 4r/gk7/2f/8AEf8A9dZf8FLK4OJ3xP8AWcFHinMMxx2MngY4ihHM8xxGYYnCUKtatTlhqv1itWqY PEU69CrDFYGbp18LiITo4qlSxNOrShw4qtUq4/FwxNf63jMJDA4eviXXji+aliMvwuc4OlTxcZ1Y 1qMMNm8KsVCpKlTrV8Qo+85uX3/RRRXzJmFFFFABRRRQAUUUUAFFFecfF/4t/D74C/C7x98aPix4 g/4RT4afDDwtrHjXxz4l/srW9d/sPwzoNpJfatqf9j+G9N1jX9T+yWsUkv2PR9K1DUJ9uy2tJpCq GoQnUnCnThKpUqSjCEIRcpznJqMYQjFOUpSk0oxSbbaSTbLp051akKVKE6lWpONOnTpxc6lSc2ow hCEU5SnKTUYxim5NpJNs9HoqvaXUF9a217ayeba3lvDdW0u108yC4jWaGTZIqSJvjdW2yIrrnDKr AgePfEz9oP4V/CPxn8KPh5411fxCvjj4265qGg/Dfwt4S+HnxG+I+s6xJo0mjx+Ide1Wz+HPhPxX J4O8C+Fm8Q6EfF/xI8a/8I98PvCEesabN4m8TaVFeQO9woVqtaOHpUatTESlKMaEKc51pShGU5xj SinNyhGE5SSjeMYSk0lFtTSTrpSoJ1k6U6ydJOonRp05Vp1k4XTpQoxlVnU+CNOMptqKbPaa/lv+ IX7Pvx7vf2YP+Dj7w/Z/BH4vXevfHL42+NdW+CmiW3w18Zz6v8YNLuvhJ4F0211L4W6bFor3nxA0 +51Gzu7C3vPCcOr2817a3FrHI08Esa/0vfD74heCfit4O0P4hfDnxLpfjHwR4nt5r3w54p0Of7Xo uvWEN5cWI1LR74KsOo6Xcz2sz6fqdo0un6naeTf6dc3Vhc29zL2VdWExVXLZ5rTlRftMdlc8mr06 qlTnh0s8yLOZz5WlJVo18hpYeUJpJQr1W0pwijvwWOngK+DqqkpywWcZdm6jNuPNVy2njqUaE7K8 YVPrs3Nr3ounFJas/m18b/s4fE3Sf25/+DdTWPB/wL+INp8O/gB+z98d/CvxU1rQvht4mHhL4MS3 v7MngvQPDnh/4javZ6OdK+H9xe65Df6Lo2m+KbrSprvV4rzT7OGS9SeIfCuu/sv/ALW3xs/4J/f8 Fcv+Cc/h79l39ozwT8bdQ/bC+Kv7Ufw98Z+N/BNr4P8AgJ8dvA2s/tHeEfiBpHgr4UfGLUNYbQvF vjXWPC/h651OLTYI7PRobiTTrS+1+NzqVrbf2aUV9cuPsfGeArRwWF+s5W8XicFXqTrVXDM6viJi vEfB42tCUlDEQwma4p4WphKqdPGYWnF1ZwlKopYZdiqmXUsgUP32I4ehwxDC4mtKo5VpcO4fOMDU niFGcZSlmeX57mOHrShUhUw1WdLFYeoq1KLP5CP+Ce/7M3jXx38dPiX8e4/hZ/wW3gj+Gv7FnxW+ GNp40/4KrfGDSW1fUvGnxL0m4gm+C3we+Br/AAa/4Tfx34LH9m2fia18b6f8TPDGl2XiSw07T9S+ HkmqyaTLP9M+BP2b/it4a/4Ni9U/Z80z4FfEfRfjbqP7H/j+xu/gjb/DbxVZ/Fa7+IHiTxVr+s6h ps3w3Gjp4wl8V6zd3z6jNpzaMdUu5Lrz/IcSBj/S9RXHnnGGIzr+0IfU6eFw+Onw3KNGGIr1vYR4 dqcYYiEOao1Gf1vFcZ5hVqctOkqaoUPdqV6mJxFbSjjqlLNstzRK/wDZuOWOp4Xnn7GtVp4XIMFR lVcpSl7anh8hivaxsoyzDGww9PDYWVLC0/53PhB+z/8AFBP+CvX7C/xU8SfBf4hQ+A/hx/wRi8Ne AL/4i6v8PvE9v4O8E/GNPHBtLvwLqXiu70mPQ9B+I0fhvVdYjn8KX1/beI49KvLx309bd3evza+K n7GnxxP/AAQe/b/+F/h39lj4uyfGzx//AMFGvHPxI8O/DjSfgr41m+J3i/w6v7Unw+Gi+OvD3gy1 8Nv4o1nQT8ONMnk07xHpOmT6a/g6zubi3vG0iKeQf2kUV24Xj/HYXPMlzuODoSnk2PyfHU8M61ZU cQ8n4/j4gUaNRrWNOpj4/U5cqbjRbrwXthYTGVMHDJIUlpk0OFqatKUfrkeFuBsXwPh1iFG3u4nD Yr+0KsdVTxVKnCn+7Vzwv4+6p8dPD37PHxP1n9mrwx4S8YftCaJ8Ndc1L4Q+DfiA0sPhHxR8QdO0 eS58P+GfEMsfibwW1rZa1qEMelvczeK/DttaTXMdxeatZWsU0y/gT8FfGX7TP/BSX/go/wD8E5/2 kvGf7Ev7UX7Iel/sIfBr4/X/AO0PrH7SPwnvvhV4N8X/ABb+Pnw00n4dx+Df2fZNe1u88Q+PvDWn a9Za9rUXiO40+1uLLw3ZWP8Awkmn6PfavpA1L+mqivCyTP8A+w5Y7EUcuwtfMMRhczweDx9WddVc vo51kOd8N5rCNKM1QxEMVlee4lRjVpqVDFUMNiIVGoTpTyw1WnhspqZdTopV6mGngfr6qTU5YDEL BwxuGrYduVCq6tLBKnha6jTrYL61jpU5TlXpuh/Bz+0l4b/bQ0b/AIJ2f8FDP+CZdl/wTf8A23fG PxL1n9uDx18cfD/xk8BfB7UfFvwF8UfCDX/2kPh54/0XXfBvizTZG13x74s1GZ7W0HgbwB4Z8VX2 meGpdR8aeINR0a08KeNtL8Nfvl8OfgP43/4fB/tT/GPXvg94wXwhf/8ABND4L/DPwX8TtV8B66nh TUvE0viLVLjxl4C8O+LrrS10TUPEAhsdHl8QeGdPv59UhhgsnvrJI/LJ/azxd4v0nwRpMOtazaeK L2zn1rw9oCQ+EfBHjT4gast94n1yw8PabPNoPgLQPEmu2+i21/qVvceIfElxp0Xh3wjocd/4n8V6 rovhvStU1az6ivRzDiyrjeH6GT0sroYKmoZ1RxWNoV8XP65jc34L4e4Px1VQrzqRoOGW5PgcU8JT qSgp4pqf7qpFy68bj1iJN0MNHAqpj8Tms1SrV5+1xGP41ybjXHzcqs5SVLF5nk1XCunBqlTwuLrU oR/cxT/gJ8J/sDfteeH/ANgH/gj18XPE/wAHv+CiHgvSv2VPGH7bGifHz4d/sbaVrHwx/wCCgnw4 svjp8UNaTwF45+FPgjxboln4lnh1I2lpa+LlTTGmm+Husy3Ctpug6nqHiKw/pB/4Ig/s8a58Hvg/ 8fviVrvgX9tj4eyftEfHbU/Hmm6f+398YvD/AMT/ANpXxhomhaPZeFtK+KHxK8OaH8KvhxdfCbxf 4ztbJLfWvA3iTWPiRr0VvoOk3b+MrzSpNK3/ALa0V6vEPiTmXEWCzfBYjAYXDwzTNM1xsZ0alZPC 4PN+IanFWKwFlKP1prO61atTxOIcksNKnh3h3PDYWvRnMcxq5jSw9KrThD6vjK+MU4SqtylVxGdV 6dPkdR0Yxgs8xFOclS9pU+r4apCVGc8e8d+JX/Ba39rr9s79nz4TfD/4Y/sQfs+/tH/En4kfHLVt T0nxj8bPgJ+z54v+P15+zp8NtKn0e28SeJ9I8M6Jb2/h/U/itrNtrMqfDnRPFXiPw5pMz6TrN/c6 rYS2tjew/lVffAOLxX/wT4+Cmrfsa/sJf8FCPBHi7/gnn+398C/23viL4I/bD+CsXw5/an/bS8Qe H7nU9U+MXxA8LG48V66fil8RdU0q9+0uot7i/uF0HS/AfhDw/e3S6Bpb/wBhVcboXxC8E+J/Ffjn wP4e8TaVrPiv4aXPh+y8f6Jp8/2m78I6h4p0WLxJoGma4Y1MFjqupeHbmy16LS5JRqEei6npGqXF tDY6xpc935eQcVPIcBh6eXZTTWaYPN8Bn2IzZYnEJ4xZZmuExGDweY4aEVz5TSjGGBWGjXo044nG 1cfSlSzGrQrUtf7Saw+DoUcNClTwtPMKWL5ZOaxsM0wONy3FV60ZxlThjIYfHOlgcW4zeAhTcMNT hLF46eK/Fr/gm1oXxj+P/wC3l+3N/wAFGfiH+zj8Z/2YPhr8WfAPwG+AfwE8A/tHeEJfhn8dNV0T 4ZaVe6j8R/E3jb4aPq2tnw/Y3Xi+6srbwtqDX7wavpECyWQdob+eXuP+Ccnwt+Jvgf8Ab1/4LHeM fGvw58d+D/CPxP8A2jPg/rnw18U+KfCHiDw/4c+Iei6Z8Kn07UtY8Da5q2n2mmeLdL0/UCLG+1DQ LrULS0vD9luJo5/kr9nXdIkeSR1jjjVnkkdgiIiAs7uzEKqqoLMzEBQCSQBXxFo//BR39jPXvBHx E+ImmfGCaXwt8Mj4KfXZ7n4bfFvTtY8Q2HxO8R3fg/4Va98KPCmo+A7TxX8c/Cnxc8W6ffeF/hD4 v+CuifEDwv8AFbxFZXei/DzV/EupW81snK81xWNrZnPLcndPB1OFMBwhDCYX61i4ZdgnnvDOZYbE VK8vaVKmMzDM+HoQk6zhTxGKzLErD06fLQoQ4cRCvj3iq7o64jNcrxU6mHw/LCP9l5TPIspwT5E1 OdPKKWFwrrTk8Rip4L6xUcqtWqz4/wDhn8LfibYf8F3v2mvi/ffDnx3ZfCbXv2Bvg54O0L4oXfhD xBbfDvWvF2l/Ee4vtT8K6T42m09PDWo+JNOsmW8vtDs9Tm1O0tSLi4tY4SHr6g/bI/5OK/4JO/8A Z/8A8R//AF1l/wAFLK+tPhD8YPh18d/AOkfEz4WeIH8R+D9Zuta06G6utG1/wxrGm614Z1vUPDPi nwz4n8JeLdK0Lxd4O8XeFPEukar4c8VeEPFuhaL4n8M6/pmoaNruk6fqVncWsfyX+2R/ycV/wSd/ 7P8A/iP/AOusv+ClleRmNfETWCwWJw88LWynCzy6VKpGdOspLH47GT9tTqRjKlVhUxk6UqbScVTV 0pNowqWq4zG4vaeLeXRnBaqnLK8kyrIUk97zp5TCtUT1hVq1IL3Yo+/6KKK80AooooAKKKKACiiv ijxt/wAFKv8AgnN8NfF3iP4f/Eb9v39ijwB488HaxfeHvF3gnxt+1T8C/Cvi7wrr+mTvbalofiPw 3rvjuw1nQ9Y0+5je3vtM1Oytb20nR4riCORSoAPtev54P+CpX7EHx1/aA8dftd6poX7K/wDw1hP8 Zv2LvC3wh/ZJ8Y/8Jb8DdA/4ZJ+LGg3Pxkm+KEvnfGD4ieB/Efg//hc9n4w8CR/8Jb8JdN8T3XjD /hHv+EH+KDeHPBenWWpyfpB/w9i/4JZf9JLP2AP/ABMj9nX/AOeNR/w9i/4JZf8ASSz9gD/xMj9n X/541ellGaYjJsww+Y4WFKdbDycoRre1jFtxcdKuGq4fF0HraU8LicPUqU3PDVp1MJXxOHrduBx9 bAVJVaMacpT+rXVRTa/2XH4PMafwTptqVfBUoVYtuFShKrSlFxqNr82fiz+wN8Zr2y/4KFeOrT9l Pwd8UPiB8cP2mP2bB4DvbvUfhFf/ABI1/wDZbsvhL+yP4R+PsPw8m8YfEXwl4EnvrXXPhZ4nvh8F v2g/EmlfA/4xat4F0fS/jN4A+KPwxvofCfifF/Y4/wCCYHjfwR8Rf2SW+OP7NPgnWfAXwK8Q/wDB SxLS9+IOifswa3feEPBHx7+J/wAPPiD+zrp7+F/hZYaZ4G0jUW0/WPifbXnh74T+C9K8DfD7xHP4 007w/pui+Etd0C6179QP+HsX/BLL/pJZ+wB/4mR+zr/88aj/AIexf8Esv+kln7AH/iZH7Ov/AM8a vXXF2arL55by4f2E8H9SjL/ava0aMeE8NwdTlh39a9nRq0sto4nExnTprmzDMsfVqqphp4fCYZwz DE08HQwNNxjh6OKxeLqRUbyxc8Xl+ZZc6eKk23OhQoZpXlQpU/ZRVanh51faqk4y8K/4J9/syftD fs+/scfAP4HaZ4J+E/7ONt8OvDnjjwx8fPhnq3wo8K+L/E/xq8XSQS2dj8TPhp8Vfg3+0dpHgrwb aeLZvJv7jWvib8OPG3jnXbNLeLxJ4a8FXtrsk+CPhx/wTU8ZfCX4D/sHWHxO/YK8K/tM+FfBH7IG v/D/APaR/ZM8Pyfsw3eqr+2Tq/hv4S6P4R/aV8Xt8XfiN4G+CnxO1zwR4F8B+Mvg5B8SofiH4j+J Pw/0bxXpln8M9O1jwrq3iWXRP1s/4exf8Esv+kln7AH/AImR+zr/APPGo/4exf8ABLL/AKSWfsAf +Jkfs6//ADxqhcV5osbmeOaoOtm2KWLxrSxFKVSp9S4mwMo+3oYmli5R5eKsfiKEqmJqVsvxWFyq tllXBf2dQiVHMq8cVPFKFFTni8bjHTpwlRpqpjsbQx1TlVCdKcZQq0I01iFP65XoTq08ZicV7STf 5BfFr/gmB+1b408D66/j3wJpHx2+O/hD9kP/AIJNeAPh/wDGG98d+FdS11vjv+zn+0j8SfFH7R3i jwT4y8f6/oPjLRfFHh34Z+Kdy/FXW7Xwr4p8b6L4g1jTdF1K+1vXPEugnu/ix/wT6+M+m+EPin8B vAX7K2mal+yr4o/4KNa18SfCvwy+G037NN5D8Ov2fdU/ZF8DaRpnjL4RfAT49+MrP9kefQz+0za+ Lx4o8BfG74b+O38MPrniH4xfDb4N3HxTtvAPxC0H9Qv+HsX/AASy/wCkln7AH/iZH7Ov/wA8aj/h 7F/wSy/6SWfsAf8AiZH7Ov8A88au6px1nFWeJlUo4CUMVUxladDkxkcPTrYzHcMZg6tKlHGpRnh6 /CuFWH5uaMaWZ51TqRqxx0fYVRzXE0ZRmo0JSpyozpKdJezo1KGQvh6nOlQg4YeCWEft5UVS+rTx PuzoSwUpYOX4d2f/AASo/ag8Qfs0fFvwp8Tv2evDXjD4y+Ef+CUX7L/wD/Zw1XV/Fvwf1q/8N/ta fADxZ+1DDpmo/DPxJc+JraPwB4j8L+H/ABn4BufCHxPl/wCEMitNE8SvplprOnXcfivRNP8Asfx1 +xh+0Zrv7TPjTxhqPwNPjT4x+L/2sf2avjL8Ff8AgoE/ij4Qo37MX7Mfw8sfg/8A8Lb/AGaWutX8 b2P7RHh0+IbfwR8dfD7fDP4R/DfxV8FPikfj+b7x/wCK9Jj8W/E1/Dv37/w9i/4JZf8ASSz9gD/x Mj9nX/541H/D2L/gll/0ks/YA/8AEyP2df8A541OXHmdVMe8wqUsDUrOtja6puOMjQhUx+b5bneJ 9lCnjYOlGrjMqwlOrGnOKxGC+sYDFe3wuKxFKpj9eruL5+SpUlRVCdacIyqVYxyfLsliqy/hVqca GXLErC1ac8FLG4zG1amGnTq06NH8ffix/wAE1f26W+JvxGT4TpdWfwz0Txt44/Zf+Ct7F8UfBul6 5o37GH7dHiD4nfEj9rH4o+H1ula70fXPgV44+IPwn0T4e+B9ZaLXZ/CP7ON1beCLWc+L9MS4/SP9 uT9lT9oX4ufAm4+DHg5fhN8QvhJY/HT9h7Ufhx8GfDXw5uPhx4s8FfCz4N/tGfB3xX8UD43+J3jb 496z4J+Iunad8P8Awnr2o6Zovhv4Z/DTU0sbJND0+18VaxNaQ3fr/wDw9i/4JZf9JLP2AP8AxMj9 nX/541H/AA9i/wCCWX/SSz9gD/xMj9nX/wCeNXm/6z4/nyKp7DAc+QYnLcVh5PCpvGVcsxmCzSE8 xTm1XrYrOMPmGcYvG01QzCeP4i4gdHF0MPjqeHwxi8dUxmIqYmpToU6tShi6D+r0lQhB42MKVeth 6VNqnhK1TD4fL8LVeEjQp4jD5XgIYuniJUqkqv5o23/BNH40eHP28fF3j7wh4a8c+DPCNr8RNC1n 9nL4u/CbUf2Lvh38F/2f/wBnbw78A9N8F6J8A107Uvgt4t/bQsbfR/iXpWsJdfs7fCLW/AP7LfjP wn4xfxzqvi7QfH0/i/SNc+FrT9iT4mf2xoP7Jdh+zHpHwJ/ac+IX/BFv9vL4L+PfFereKvhbd2P7 U/7Q9xqv7KvhXX/2g9T8W/DnxR4wvdasviZ4r1D+0B8QvjJF4X+Mmsfa5ofHvg/QrLQdGnvP6F/+ HsX/AASy/wCkln7AH/iZH7Ov/wA8aj/h7F/wSy/6SWfsAf8AiZH7Ov8A88auzCcZ5lh1h41KWHrR oZLLJvaL2tPF1Y0uGM/4bwWMrYmVSrGviYRz2WNzD29GrSzavhMPUxMI4ynQx+H6aebVqeJli40c Oq/Nl84OEJU6XNl2Z0MypKpSpziqlNyoyoxheHsIVJfVnRUq0K35g/E39k/9sH46eNPir8Rov2Y/ Gfw2tvF2n/8ABHfSNC8LfED4j/s8T+K3H7IH7ZvjL4i/HW+1D/hXnxn8feFLO38O+Abyy8ZaVHF4 rvLnxLpGo2Om6NDdeM11XwnpPD+Of+CXHxk1P4J6bPc/BK7m1vVP+CiH7Wnxg/aO8AfDDT/2M/FP xj/aE/Zz8bfFn9pPxF+znD537U+n+NP2Y/iJo3gPWvih4R+Kun/Cj4+XEel+FYr3xD4m8Paf4f8A jXoHh+Jv12/4exf8Esv+kln7AH/iZH7Ov/zxqP8Ah7F/wSy/6SWfsAf+Jkfs6/8AzxqHxpmim50c PgMPF5nPNPZUqeKlTVSpSyKhLDfv8XWnLCunw/gklOcsRGVTEzjiFN0JYfmpY2pRVONOFJU6VHL8 PCm4ynBUssyPMcgwkZKc5ObhhMyq1nKTc/rtDC4iMoqnOFT8cfiT/wAEsf2g/EfgjxoX+DOo+OfH +gfs3f8ABMzw98DPEXj/AOLvwc8dePfAPxL+DH7Xvxj+JHxs0vwp8RbDQfglo/h3xB8K/g349s/D uk+NPC3w6+GmmXPhC9u/APwzuNVtTqWm3XcfGf8A4JqfHE+FviN8M/h58Jtb0j9kzRP+CkGtfGjR v2WfgdF+x9cQePf2cfEP7JHgDwfpY+GHwh/aisvEv7IltpPhX9qN/E3xF1T4U/Gzw74Z06S+svEf xO8Kafb/ABHtPh7q2pfqt/w9i/4JZf8ASSz9gD/xMj9nX/541H/D2L/gll/0ks/YA/8AEyP2df8A 541a/wCvec+0qzVHAKFWtiK7w7o4ieHhUxGP4WzByp0amKnGM6VXhTDU8PV1rUaWaZ04VFXxlGth aoY+th6cKVOFF06UaMKMJwco0Y0OH3w3BUouXLT/ANgbqPkStinzw5KSVBfjt8RP+CVvx18WfC/9 pXT9X+B8nxF8er/wTL/Z5+Hf7LesfEz4ofBT4j+OfA/7WXw68c/tTeK4NJ8HfES38N/BjQ/B/jD4 Uaf8T/Bnh/wp8TtE+Hfwr8J6Rod6fDngvWG0ax1dT7n8b/8Agn3478Xap/wU6isv2XNSvtU/ak1j 9lPx/wCF/in8LfEf7LnhDxP8QdF+Hvh74KRfFf4X3T/E1PE1j4s1mbx/4E8W+OvEPwg+N/gjQP2f PjtY6jN4Y8UfFzwrP4z1jxF4f/Rb/h7F/wAEsv8ApJZ+wB/4mR+zr/8APGo/4exf8Esv+kln7AH/ AImR+zr/APPGrnq8ZZrWqc8qeFiubESjTpPG0oU44nN8rzutClKGMVWlGeNyfAOTp1ITnSpctSc5 cs4mGx9XCOn7Gnh0qUMDThCdGNWnyZbS4do4OEqNRypThRjw5QdOnOEqdKeYZrOjGm8TR+reC/sD /sz/ALZvwp/Y8+EnwQ8feJfg18MNM0OT466N478Cav8ABCfUfHuv+EPGfi3xTf8Aw+vtFuPhV+1j r/wK/Z18QLbay+t+I/hh8MrD40/Bjwha3tn4F+FMXhLwzoNjZQeJ/sc/Aj9sn9nXTLDx5rP7L11r Gv8AwE/YQ/Y8/YS074bn43fCrQfEfx2m+AnjP4hXHxY+MHwb8TaP4i8Q+GNF8PX/AIV8V6bqfwd8 PfGjX/gv4r8XeIYr3QvH/wDwpeyt7bxRc/c3/D2L/gll/wBJLP2AP/EyP2df/njUf8PYv+CWX/SS z9gD/wATI/Z1/wDnjVhW4px2IrZ5Vr4bLpriDFYfGZjSWFdKnKrh6mctxg6FWlV9nWocQZxgqka1 Wt7PC4xRwrw9XC4Grhop4ypTw2KwcYUvq+LqQlVppThalTzjAZ7DD05UqlOUYRzHKssq+2u8ZKng aNCeKlRniIV+X/Yx8D/tE/s6fBP4ZfD7U/gjFc6V42/aT+M2o3/hu68dfDzTfGn7M/7O3jbVviX8 QfAOrfFrxFo1/wCK7P8AaI+M9tqcXhPw38V/EWj+NfHPjPxt43+IWs+PfEnxR+JF7o/iPxp4k6j9 sj/k4r/gk7/2f/8AEf8A9dZf8FLKP+HsX/BLL/pJZ+wB/wCJkfs6/wDzxq+IP2r/APgpt/wTb8R/ Hn/gmTrHh7/goN+xBrukeAv23/H3izx1qmjftX/AbVNO8F+Fbz/gm3/wUG8C2fibxZfWPj6e28Oe H7rxt408HeDrbWdYls9On8VeLPDPh6K5bV9e0uzuvHx+OqZjiKmKrUqUK9apKpVnTdZyqNwpwXtJ Vq1aVSS5HOVapKWJr1alWtiq1erPnWFaoq1erX9nTpSr1cXiK0KKlGlPEYzMMbmFarClKUoYeMXj I4ShhcKqGBw2CweEpYfC05xr1a/7vUV8Af8AD2L/AIJZf9JLP2AP/EyP2df/AJ41H/D2L/gll/0k s/YA/wDEyP2df/njVxGZ9/0V8Af8PYv+CWX/AEks/YA/8TI/Z1/+eNVi0/4Kr/8ABLy/u7awsP8A gpH+wRe317cQ2lnZ2n7YX7PNzd3d3cyLDb21tbw/ER5p7ieZ0ihhiR5JZHVEVmYAgH3vRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV8Aftkf8nFf8Enf +z//AIj/APrrL/gpZX3/AF8Aftkf8nFf8Enf+z//AIj/APrrL/gpZQB9/wBcH8QPif4D+Fum2Gre PvE2neGrDVNUtdHsJr93Bub66cKFjiiSSUw20e66vrrYLextI5Lm6liiXcfzM+IniP8A4KhaB8cU uH8O/CrxB4Fufi94n0v4K6R8Kx4si8P6j8Kbn7M2hTftHah4ikuTpHi620pNQude1XSFtvDVoLdF 8FW134idYLz4W/bP1z46+Ivirqmm/GG8PhvWdLhmj8NaboUY1LQtJ0i/aOOG+8N6fezoLuwmls47 h9Zuz5+pXsBidDdQy6Tpnh43P8Hl9V0sZh8ypuUpQwsqWXYrFrH1oqMnh8DHBU8TUr4lwcq0aHs4 1Z4ejisTCMsPg8XVodVPCVKseanOg0knU5q1On7KL056rqOCjC9ouV3FTlCDfPUpqX9CusfFj4c6 B4s8L+CNX8XaPZ+J/GVvJdeHNMe5DNqFuihoZftEYe1tlvzui0k3c0A1aeKW3037VPE8Yfo3xT+H 3iHxr4h+HejeKtL1Dxl4Wt4LnW9EgmJuLWOc4cRuVEF5LZMYo9Tis5Z5NLmuLaDUFtppkjP8nn9u 6m0Wk3i+IJ/EMGiWtvpUF/da8dbbTbLSIPKhuFv5XuVmuLQJboukzSW62dviW4trcwWumT7fg7Wv iUfGlnJ4a8PeJrTxrca61p4ctNMjuJ/Gmqa5DPIVji8NpawS6Rf38sNzMyG6NxbW8MtzeDQIXv0i 4/7ex+M/e5Jkk80wNReywuYVMfSy6hWxCtKVadPEUZYiOUQipUv7Qw1LF4mtio8mGyythJRxz0+q Uqfu4rEqhVj706MaTrTjB6KKcZxh9Ybal7GcoQjTd51o1E6R/XRRX5A/EXxJ/wAFS9I8TfCmHwr4 W+Gl/wCLNR0iCyt9JF7r+rfCJrsi1m8R3fxl1/TdP0m80q7sNLWZhdaORbNq0dpb+BhrVxeahY3n 6/DOOevfByM/XAz9cD6V7mCxc8ZS9pUwWMwE01GVDGxoxqxk4qUkpYeviKNRQbcHOlVnTlKLcJTh aT5atNU5WVWnVTu1Kk5OLV7J2nCElfdKUVJJ6pPQKKKK7DMKKKKACiiigAooooAKKKKACiiigAoo ooAKKoarqum6Fpepa3rN9a6ZpGj2F5quq6lfTx21lp+m6fbyXd9fXlzKyRW9raWsMtxcTysscUUb yOwVSR8KaB+1R8Q7jwHJqHibw54a0P4gy/Gf4BWdp4budJ1e0SL4CftL/Fvw9ofw41q/sf8AhJ9Q nj8c6Z4I1fW/CniS7TVRpD/FPwL4i1S28OWnhu4sNCp0EsRiI4SlODrutltB029YTzbG/UMB7R2a gsRiI1vZ8zUqlPC4yrTjOGErum5JQoutKcYpe2lGDuqlSnhqEq+JqU01yThh17CFZKfPGpjMLFQl Gq5Q++qK+K/DH7YOjWPhjXtV+J+i6jp99pdv+014k0268L6VDLo/iLw3+z98ctd+FcnhzRLe88R3 esXfxGudOPgu6fS7i3sdL13UfEDyaJdwxw3umaRn3n7dXhq1+L+q/CyH4EftA6jofhD4veBfgR8T /jRY6b8Iv+FWfCz4p/E3wf8ADTxh4B8NeJ7W8+MVn8WfEMfiKP4u+A9Ck174X/Cz4g+HPDWtavJJ 4y1fw54fsb3XoJpc1bEU8LSp1p1q01TpRWHrpVJSzGplEVCcqcYNSzKnHBRfNaVfEYGKb/tDAvEE 06dLF1prlo4GnWrYupvChRw8KdSrWqSjdRpQhVjJz292tH48PiI0vuSivxs/bl/bi+NXwC+PHiDw H4S+KfhT4T+APC3wd+Gfju61bV/+CVv7ff8AwUBfVPEfxA8ZfE3wwLXWfH/7I3xm+HHgv4U2Qk8H aDYaFoXjjTJta8Qajq15dabf3FtCLSD6R8Tft0aj8KPBHw11j4w/s4/F+28S/wDCmfAnxj/asT4d 6j8I9c8F/saeHfE9t5eu678Wdd8c/FP4d6/4q8OeGtT0fx688HwS8LfFrxw+g/D7xDrUngyKKbQU 1q8PH61JU6UqXtpYvDYKnQlXoKrUrYtZlKjKCVRxdJQynG1MTVclDAwpx+vPDSqRi9atCdJzUnBq lQpYio3ONKUYVqGFr0lGjXdLEVXU+uUKNKVGjUpV8TUp0KFSrUr4aNb9AqK+D/iB+3lo3gv4k+I/ hjoP7N37THxV1XQvFmsfDew134faP8GLbwp4s+KmlfBzQ/j5D8OvDmrfEj43fD2ZL7Vvhbq2oa5Z eN/Edj4e+ENlqnhjWvCHiH4j6J4yu/C+geJMr4h/8FJvgF8MvHf7JngnxPYeJ7G2/bGh8FN8L/GG r+Ifgp4J0SDUPiNc6Lp/gnQB4b+JPxf8FfFL4m+ItV1XxDo2m61ov7O3w7+Nt78PP7U0nVvihH4J 8O65oWtam6NOtiJ4anSoYiU8ZUy6lhYvD14OvUzf6y8rhT56cVJ5hHCVp4T/AJ/03RqU+aGKw0q2 dSE6SnKcZJQw2Ixjai5XwmFVN4jEwUU3Uo0faqM6lPmip0sTTTc8Jio0f0For4g+HH7c/hP4lfE/ TvAun/BX48aB4J17x78afhN4X+P3ibTfhTbfCHxL8WPgF4i+IHh74ifD+wsdK+Les/GfTb21/wCF W+PNW0nxb4l+EGg/DPWdP0B7Sz8ct4h1DSdDv8nwr/wUD+H+uXfiD/hJfhH8a/hdoEXgtviv8NPF /wARE+DVpoHx1+COn+MfDXhDxX8avhvB4X+MvirxJoPgXwKvjjwL4p8V2Pxr8PfCLx/b+EfGeh6p pXgjVrkapp+mKlCdecKVOE3VqYetiqVGUZU61XD4f2sqtWnSqKNSpGNGhiMYuSMnPL8NicxgpYDD V8TTVdfVfrn1mUKDy/ExweOjWqQpywmJdT2MqWIjOSlSdGu1hsTKaUMLipRwuJlSxE4039618Aft kf8AJxX/AASd/wCz/wD4j/8ArrL/AIKWV7N8Pv2rfhp8S/G2q/D/AMN2PiweItH+K3xK+FFzBf6b pUET3fwq0DS9b8T+NYfI1y6uT8P5LnXNF8N6TrkttDf33iPVbG1bR7ewnXUh4z+2R/ycV/wSd/7P /wDiP/66y/4KWVEXzU6NVX5K9Chiad04ydHE0YV6LnCSU6c5UqkJSpVIwq023CrCE4yipUk3NWkn Tq1aMuaEo+/RqSpTceZLnpuUG6dWHNSrQ5atKc6c4zfpvhD9rHw/4u/bC+K37H1v4Q1uz8SfCn4T eD/izqHjKe+0+TQtV07xjrM2jWmk2dhGf7RhvLaWCSWWafMLojKAh8sy/HX/AAVw/a6+CH7LngT4 O6R8afgD4q+PVt8ZPGereHfDWleDfEOn+FNb0nVfDlnpuoyBNduJ7S/todYttSksJ47G7t45rQ3k N3KscqZ/SrS/g18LtE+KfiX43aV4J0Sx+LHjDwzpng7xP47ggkXXdZ8MaNdfbdL0W8nMpiays7rE 8SpCj71Xe7BVA4n4/fsp/s6/tTaf4a0r9oT4SeE/itYeDr6+1Pwvb+Kbe6mXQ7/UoraC/urB7S6t JYZbqKytElO8gi3iIAKA16+GrZRDH4SpicJiKmXww9KOMw8KjVWtiFhXGrOElWg405Yu1VRVWnam uVKPwkSVRxkoySm37ra0UeZOz0evLdbPXUy/G3wF+EniDQ/Bvjm9+Cema14i+Evh9Nf8B+AdKOma THJqWiaPJe+HvBj28FxZeF9RTTtTjgi8PRaz5+g6PrSW+qW5t1jaavi7/gnn8ffh1+2v8Q/jb+0J Y/sieLfgX4u+G/ia7+DmoeNPGviXwv4gh1bx5pNzqFt8StE0DSvD9/NDo3iTQVi0K18WeI/7NgbX 7PV7C1stWvo11mNv1fsrK106ztNPsYUtrKwtbeys7ePPlwWtrEkFvCm4k7Ioo0RcknaoySea87+F 3wZ+FnwU07xLpHwo8DaD4E03xj4z134ieKLPQLZrWHW/G/if7L/b/iW/VpJDLqeqfYrQXUwKqy28 SqiqgFc1Krg44TGU6uGdTF1J0HhMTz1IqhGM5OupQVZQk6keWMeenVcfeaadmVaV42dopPmjZau2 lnbS2u1umh8T/tQ/8FHvC37Mn7W/7Lv7I+ofCnxZ418TftP6n4ZsdH8V6Nrug6ZovhG18Q+P7XwJ PqOr2epkXuoR6O9z/bFzb2BFxdWiG3s1kuW2r+kteYar8FvhXrfxX8LfHPVvA2hX/wAXfBPhvVvB /hTx9cQSNr+heGddeeTV9GsZxKIks797m4MytC7/AL+UI6iRgfT6WJqYKdHBRwuHnSrU8O442rOp KSxGIdapJTpwcpKnCFF04JR5eaSk3BaORFSvLmaab91JbRstH3d7v0tqFFFFcZQUUUUAFFFFABRR RQAUUUUAFFFFABRRWH4j8R6P4T0e613XbmW2060a3jc21jf6pe3FzeXMNlY2OnaVpNrfarqupahe 3FvZadpemWV5qGoXk8NrZ209xLHG106dStUhSpQnVq1Zxp06dOMp1KlSclGEIQinKc5yajGMU5Sk 0km2JtRTlJqMYpylJtJKKV223okkm23okrs5T4ufDDQPjR8PPEfwu8W3WpQ+EPGUVhpXjGw01NGk XxT4QGq2N14p8Ba1Druj65Y3HhH4iaBb6j4F8bWsdlDql14Q8Q65baJq2g6zLYa5p/y34c/4Js/s afDfxFY+I/gN8DPht+zHIL/wZqPinR/2bPhr8L/g34e+JFz8PPiT4N+KXgiT4jaP4T8D2tt4nuPC viLwe9poGoTfZ9V0fQvF/jnTNNv7X/hIpZ4Pddf+OujWGlPrmgaXca/pn/CufiZ49je8Op+GL5bn 4a6loek6h4bv9H1rQ49X0m/m1DVrq0vTqVlb3mj3OmSwT6XcPKRB6InxA8JtObQ6oUvV8TN4Oeya w1MXa+I49EHiSTT1tzZCaSNNA/4nP9opGdMbTP8ATVvDb/PXo/2TmuClhscsDXoVoV69ajXhSSxl Grl9X6pXVfkTxVCGGrOdL2GKUKUKlXEclO+IrupjLG4bFUPqU61CvhlNVFSmoVKEqlejh8ZGpCUo unUn7LDYbFUpwlKVJ4eNam4TouUfkPx7+yNL4i8W/s2eHdKtNHu/hB8KPjx8Tv2lfG3iLxD4+8W2 PxFvPGfiLV/Gfi3w38OdC8FeEPDOi+D/ABX8P9U8ffEKbxR4ivPH3i6ax0LT/ht4T0RPh5468Qa/ D4/+Hnu+p/s9eC9V/wCE0+0an4oT/hOvjd8OPj3q3k3ukr9n8YfC/wD4Vh/YGm6dv0STyfDV5/wq bw5/bFnc/a9UuPtut/YtZ0/7TY/2btaB8dvhd4mtr6+0vxBfJYWHhe98atqOr+FPGPhzTb/wnpqQ vqev6FqPiHQNLsvEem6YLi2XU5/D8+pjTpbm2hvRBLcwJJ5JL+0/qcOvG2k+G8p0MXV7EIYtW8Uy +O5Y9L0q51nVoLPSR8Nx8L9T8RaLplndatrfg/SvjRfeJtL022uLO501fGER8IHtwPDfEUq+IWHy 3F0MVhqjx+KeKUcDVjOGIy7ErESjjp4dJUKmSZU37KKjT/s/DzrJ1Z1albHE5lgmoVauIpVIyp/U aXsIKrzRTxeIlQ/2aE6lapOed42s3VdSs1mKo05LDrCUKXrWu/A74feK9b+LGqeLtMPivTPjX8Mf D/wg+IXg7xBHYah4P1nwNoJ+ISSaXLpT2CzzJr9n8TPEeneIY76+vLO9sFsILe0s2ju5L35w8W/s HeHvFWleBdAi/aF/aR8OaDoXw+8MfCL4p6bo+u/CXUJf2l/hP4O1G6vPD3gL44a94w+DnirxVDBZ 2ereJtCufGnwa174P/FHVdH8Wa8usePL/UW0zUdM+oG+MPw9/t+y8NRa3PcalqEenG2urfQPE1x4 aS51nSzrWjaXf+MrXRZ/Cela1q2lGHUNO0HUdZttbvbS806a106Yalp4uodG+LvhPVZPCOnibULr WfFnh7w74iii8OeGPHXiTQdOs/E8UzaTPq3ie38IWlh4estRltbyPS7jxjF4Wur6O2kkbT7Z1kgj 4I5Rm1KrTxyy3HxqUVhMVGcsJX5Zwo0sesHXqUZ0/Z4nD06FfNKdOdanVoRoYrHUW/Z4qvCppPG4 KrTdKpicJWpVKOJp8lSpQqwjSxay6OJ5OdyjReIeCymbnBwnOrgcBWjJ1cJh50uTl/Zw8Dy+M5fH B1TxUuqzfFzU/jM1ql7pC6avifVfgUP2fbjT0hOhm5Hh+PwYo1KC0N2dQTxN/pj6pJpX/Elr5x8Q f8E3/hdr+t+CtRT4tfHTQtF8GeAP2XfA/wDwh2hal8J7fRPFGofsb/E8/Fv4A+PPFOs3vwhv/H11 4j8J+Kp9SW/8NaV400f4SeJbDWNS/t/4Z6hqb22p2v2JB8Xfh9ca/q3htddmgv8ARU1tr29vtD8Q 6b4Zd/DKI/iS103xlqGk23hDWr/w6rSf29p2ja5f3+jta6gmo21s+m6gttpeC/iL4T+IEV/J4Zu9 Td9Laz+3WWueGvE/hHVYYNStzdaZfjRvF2j6Hq02k6pAszaZrMFlJpWova3sVleTy2N4kFfVM6wl KOIWHzXCUsJSyatHEwpYzCxw9LL/AGtLIK/t4Rp+zWEqTlPK8Rzp08XCliMNNYrD0atO1isM5ypK vh3VqVMVheTnpOr7WFeljMbQp6upCqqkISxdOny1PYynRrr6vWq05+eaR+zt4I0aP4fxQaj4muIv hx8V/ip8YNFjvLvSJUvvEnxfX4pL4n07WVTRIhc+H7Rfi34kXRbS0Fjf24s9FGoanqYt7/8AtLyb 4bfsReDvAV34yi174tfGn4u+E9b+Guv/AAW+Hvw++J198MH8J/Aj4N+KLmKfX/hr8MZfAHws8A+L Nb0fUbfTPCmlnX/jZ4o+L/j200rwV4esbDxhaRy+ITr30VB8Xfh9ca/q3htddmgv9FTW2vb2+0Px Dpvhl38Moj+JLXTfGWoaTbeENav/AA6rSf29p2ja5f3+jta6gmo21s+m6gttnWvxx+Gt3oOqeJBr Gr2mnaNfaBp+oQat4L8caJriT+K7q1sfDEtv4Y1jw5Y+Jb+w8Q3l3Fa6LqlhpF1pmp3CXUNndzSW N6tvP9kZvKbq/wBl5i6lXDQwyqrA4n2nsM3c8JRVGoqXPTlmCq18Fh61GUatelisXgqNSVLGYmlV HjcMr05YjDc0cYqvLKpRc44zKq/9oyV5NzjPBYjkxtejdRp1aWHxFeHNh6E6fmfwd/ZF+HHwU8fW /wASfD/iP4k+IfE1v8DPh/8AAf8A4rPxaus6PJpPgXV9d1rUPH39h22mabplr8VPiZeatpSfFTxd p1tZR+LbPwP4CsxpWnW/hq2jk8m/bI/5OK/4JO/9n/8AxH/9dZf8FLK+tvCHxb8B+O9SOk+GtS1S 41AWN/qAg1Pwp4u8OB4tI1KLR9at45/EehaTby6poGqzwad4h0WOV9Y0C9nhttZsbGWWNW+Sf2yP +Tiv+CTv/Z//AMR//XWX/BSysMZh8ZhavsMbha2Dqx9rOOHrYV4PkVfE18RVlDD+zpRpxqYqriKs uSnGLrTqv4nIWHnh504/VqlKpTp08PQ5qVSNRKOGwmHw9BTnGUnKosLSoc1SblVraV6sqlSpKpP7 /ooorkNwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvHvjppniHXPh/daL4a0PW/EF/ qWr6Gs2n6RaeF9StZ9NsdRh1bUbPxPo/iv4i/C2y1zwhrltpz+G/EOi2vi61vNSstaNtJa3WmPqS p7DRXVgcXPAY3C46lTpVauDxFLE0oV4ylRlVoTjUp+0hCdOU4KcYycOZRnblmpRcovOrTVWlUpOU 4KrTnTlKDSmozi4y5W1JRlytpSteL96LUkmvz20f4beMtH8JXnhG3+EHxTt7GXwn8ZvCtgml6R+z tpFjpdv8YPEek+J5WtdKs/2kfsUVn4ZvbG7tNO0y0FnDPplxZWxltZdPludQ9IQeNz8V7/x/J8Av jGNNl8HWml2mlDxF+z88R8WyG60zU/FEtj/wuaIQXqeFrbR9BtrsateG6s5Ly2ax04WkdzqXOftk ftda3+zRqfwc8LeGNH/Z2fxN8ZNf1bQNA139q/8Aaib9kb4O3GtafJoNjpHw68PfEe0+DXx61vxh 8cvHmoeJILj4efCjRfh4ZPEnhrwt8RNdn8TaVdeGNK0XxRLYftw+END8ZfETwD8Z/AfxA+EHiT4T fBn4QfFLxwZ/BnxE8eeHJNe+LPirxV4K034afD/xn4L8Aah4S+K/jXUPE+h6Hovw68IfD3Wde+J/ xS1rxZaeGvD/AMNLTxZpWq+H4PqK3GmNxznKvluUV54xZrQu3mdOdaWLqvF5tGEaWbU3UqzlSnXr R5ZypUnKtCMKfLNedSySFGrQoUK+NdevLBYihCisPiKntJ5jhMvwEFy4Wq6NfF46WHwmGwsuStjI VJxo0qtCVRkN34U8X3Pg/wAO+Ej8GPjEkXh/4J+I/g+lxE/7PkIuW1218IwReIlgH7QzraLYyeFE lOkbrkXAvjGdQiFtm54OPw5+0le6HYx6l8L/ABlplxp178RdWtvC+iH4KXCpe/EafXptbEPxKv8A 9oCO8g1YprupadoHin/hWs0HhjSta1KK/wDB/jTVLTTdZT07Xv8AgoL+y/4b8KeGPFmp638XZP8A hLdH8Ya/pngfR/2Wv2p/EfxosdI+H2seFtC8d33iv4A+Hfgxqvxx8Cx+Dr/xv4Qk8TJ42+Hvh6XR NL8R6Rruox2+h3kWomt4y/b6+Avw7+J83gLxfq+qnQLrwH8EfiBoPxC8B+D/AIk/F3wy3h344a38 StG0Dxb49v8A4V+AvF2h/B34T2rfD0XH/C7Pif4h8N/C6cavIl54k0ldKlmu+qjxtmUacYLJMkrx r4+VOi8RhsxrqePx9TGe2wmHhVzKVOWKx9TF4mLpUoSxbSdLCulTjUpvlqZPg4xjiZY/F0qdLBvF utTrYahfBYCrgMD9cliKWHhW+rZfW+qUZYiNZUMNiK8alWUcROFRWNBPxh0DVJJNB+EXxM8KeENc n0PWvEvguyg+AHiLUrfWdM8MaP4audJ8PePNV/aG0+GPwpeWmgaRDdJqHgGbxBPHFqM+max4em1G 1TR+XHg74kR3fwxe1+D3jzTl+HWgeC9AfxLpOi/BzRvifrFh4TMD3Wkf8J1pH7X1jZr4Q1+WAG/8 Fa/4U8VaAVnuJLm3vr0Wd7Ze76t+1P8ABPRPjCvwLvvEHid/HimC21G8034W/FfWvhl4c1680W38 Sab4H8ZfHHRvBF/8E/BHxN1nw5faT4g0L4WeL/iDonxH17QvEHhfV9H8LX2n+KfDtzqfPfAn9tD9 nf8AaT16Tw78IPFXi3XLyTwXpfxG8P6j4j+Dvxp+GvhX4heANW/s5YvGnwi8b/E74e+DvBvxn8Ma fLrWh2viLW/hPr3jPTvCl9r2g2Hie40i91zSoLzmpca4xVksPlOSqvWw6ajTo5hUr18Lg8JiIKpO csyqYjFRoYGeIVTE151qn1dTnWrSjDnjtWyGjh6U4YrE42jTh9VjVjWeGw9OEs3qYbE4RunHC0qN Cea1nhq+G9nTpfXJ1acqCmqkU+Mi074ptZ+KfB978MPi83wu8Qjx40PhfT7D9nez8TwyfEC41S+1 O21TxpeftHapb6jpmlanrmq3+hwaZ4V8PanGy6Vb6vrOs2tlfw6vs+ENR+M2h6jr3ibxD8KPiF4i 8Za7a+DtBfVLHQfgR4f0aDwp4RvdQuxY/wBiH9qjWL2bXdS/t/xI8utf8JBFptrd3umTweGvsul3 Nhq3jf7dv7fP/DHHi74Q+Ev7Q/Ys8N/8LS8O/EjxF/wlf7bX7cH/AAxL4Ih/4V9qPw+07/hH/CHi D/hnv4+/8Jx4p1X/AITv+0JNH+x+HP7M0vRbq8+03/neVb99pf8AwUH/AGfoPh9+z1428dal4j8O T/tC/DjwN8TdKh8FeAfid8cPBfgjwr48TSY9G8Y/Ez4sfB/wF4r+H3wq+FOoX+q+VoXxf+MOr/DX wLrWnWGraqdRsI9B8SW+iYx4sxGNpeyhkeSVoY/F0svUYYPHqrjMfGviayw8HHHRrV8diquTYqri FByxOZUsulUxLxNDDxcdauTrCOFSri8fShTw2IzRT56P1XD4OLo0qtWq44d4XC4Sg5U3Qw9X2VDC ycquFo0pKc1di074ptZ+KfB978MPi83wu8Qjx40PhfT7D9nez8TwyfEC41S+1O21TxpeftHapb6j pmlanrmq3+hwaZ4V8PanGy6Vb6vrOs2tlfw6vXttK+K9++par4z+FvxO1zxTqOq/CqQ6roei/ALw 1psegfCjxX/wl2m6W2kXP7UHiK5l1TV9RvNaGpawNajsYhfWZsfD9smnyxahS1j/AIKD/B3wlqvx 6svGXgf9pW10/wCAvxesvhFrOreA/wBj39sP40w6veXXwv8ADvxMm8T2cXwh/Z/8Yj/hFLGDVdT0 y98T6dNrXhOyFhod/qHiSyfxt4ZsLz0D4R/tffDT4u6qNN0mDxDYnxB4s0/RfhvbT+D/AIhr4k8T +Gb/AOCPw4+NreOvGPg3UfA+k+JvgvoWnab8RtM8MazP8U9P8O2Gh+Lbnwx4T1rVdO8ceN/DvhGf bDcW47ExnUwmTZJVj9SyvOKlbD4bGNrDYp4HNMvxlStTzDmVfMIyweNqc8/reY0KEquLjiKGArPD 5zyeir054zG29rmVF0fa0eROhCpQzGgqMaHJDDYBUKkJ0Ywjhcsra0o4atODla+G2keKLLxv4fu9 R+GvxK0CztY/jBHNq3iA/B7+yLb/AIWV42s/iDGbs+FfjR4t14f2bLpSeHoBYeHtR/tG6v4dQujo 1nDceX5J+2R/ycV/wSd/7P8A/iP/AOusv+Clle4/B79rH4G/Hjxh4u8C/DXxB4tvvEHg62fUpm8U fCT4wfDbw/4x8PxaxdaBP4w+D/jH4l+A/CPg/wCO3gK01e2jsb3x/wDBXXfH/gqxk1Xw493r0MPi nw3Jqvh37ZH/ACcV/wAEnf8As/8A+I//AK6y/wCCllfPZlmVXNp4bGVKGHoU6uGdXDPCqv7DEUcT isTjHiqU69fEOrCvXxNacalOo6LjaNKMYxsd9DDRwdTF4Z1KksRRxKp4ynW9mq+HxEcNh0qFelCn SdCpHDrDz9lUpxqclSFRpqpFv7/ooorzTpCiiigAooooAKKKKACiiigAooooAKKyPEGu6b4X0LWv EmsztbaRoGlahrOp3CRS3Dw2GmWst5dyR28CSTzyLBC5jghjeaZwscSPIyqfJr3466N4b059U+Iv hDxj8LLM6h4Z06yuvHEvgZdO1GTxPrUGiwyW2u+GPG3ibw7bNpck/wDaOr6fqur6drMGiwXmq2em X1rZ3Lxd+EyzHY9J4TDyruVanh6dOEqftq9epKEVSw1CU1WxU4OpTdaOHhVeHhUp1K/s6c4yeFbE 0cOk60/Zx5KtSU3GTp06dGKlUqVqqi6dCmlJJTrSpxnNqEHKb5T3CiuQk+IXgGLVtb0CXxx4Qj13 w1pja14j0WTxLoqatoGjJDb3D6trenNei80rTFgu7Wdr++hgtVhubeQyhJo2bEu/i98O4/Dtx4r0 vxVoXijQbHxPonhHU9S8La5oet2ekaxres6ToqRateW+piysBpsus2V9q8dxcpdWems1yLaZjFFL MMtzCo6ShgsU/bSw8KT9hVUZyxbjHCqM3FQ/2hzgqL5rVOZcjaaG8RQXNetS9z2nMlOLkvZQdWqu VNy5qdNOc4pc0Yq7Vj0qiuLT4k/DuTwo/jyPx94LfwPG5jk8Zp4p0NvCiSLeDTij+IlvzpCuNQZb Eq14GF4RakeeQlV774p/DDS5NGh1P4j+A9Ol8RwaZdeHor7xf4etJNettaLjR7jRkuNRjbVINWMU o0yaxE8d+Y3Fq0pRsKOXZhKUoRwOMlOFWpQnGOFruUa9FKVWjKKg3GrSjKMqlNpTgpJySTQPE4dR UniKKi4e1UnVp8rpp8rqJ81nBS93nXu30vc7yiuL8ZeP/DHgEaDN4r1CDR9O17VbvSl1rULvT9P0 XSXs/D+teI5rzW9R1K9s4LCw+xaFdQLcAzH7ZNaxNGsUkk8JdfEj4d2K+FnvfHvguzTxz9m/4Ql7 rxToduvjD7YbQWn/AAizTXyDxB9qOoWAtv7JN355vbQRbjcw71HAY6pCjUp4TE1KeIVR0J06NSpG r7L2vtVBwjK8qao1ZTj8UYU5zaUE5DlXowc4zq04OnHnmpzjHlg3Fc8uZq0bzgubZSlFN3aT8l/a E+Hn7Qvjqx0qL4C/Gf4S/DcyWWuaD438K/Hn9nS//aP+Fvjbw5rsFukhn8LeFPjb+zn4003xJYm2 fT7S8b4n6l4LvPD2teJNO1/4e63qlz4f1/wx8ZeKP+CX2heIPhV4s+Btt4u+FMHwe8RfBj4JeCbH 4Za/+zlpPjX4f6N8QPgN8bPFnxt8Gn/hAvEvxEu/A+ofsxS3viqT4f3X7MbeG7XUtJ+Genaf4c8H fG/wvc2Omarp339L8efg/Zaj4s0zWviN4L8NXHgzxHb+FdZbxL4s8NaJF/bFzotrrccFub7VonYe TPd2RW4jtpzqOja3bpC66dLKd/w98TvBfiaW7TS9c014E8QWXhvSL99T0ltP8WahqHhDSvHNm/hK 6t7+4TXbe48O6sl7C1sBPLFZahcxQPY2wu5NJ5NmVGjVnPLcXTpVKWGxVWvPDVIOpRjGpWwVT6y4 KpOOHWbvE4SMaj+qTxFLE0Y0qlGjUpTSxmGpY2jiqeIovF4epOlSTqQqqlOhisDi69P6tNzoxUsR kGFjjIypKOIp4fE4TFKrh8ZjqOI/Mjwj+wh8b/gtcfCXw1+zh4q/Ze+AyaN8Lv2gtG8feIPhL+xf 4P8Ah7+zva698VvH/wAB9U+x+AP2ZPBvxt8MeKfDPiOfw54D1y58OeL/ABD8X/ijZ2Ou2t/ffES2 8cWV54b8Maf9V3/7HmjL4I+K/wAP/DnjG60bw/8AEP8AZg+G/wCzLoYvtE/tq98J6R8NtK+Jmj6d 4mvLn+2tNHiW6vrT4hQm40wR6EI5dEdxqUg1QLp309pnj3wLrdz4jstG8aeE9XvPB7vH4ttNM8R6 Pf3PhaSNrtJI/EcFpeSy6I8b2F8rpqaWrK1ldqwBtpgnikn7VHw+h1yfTJtL8RRaZaxRXt34ge78 C77PRp7Nr6DxFe/D5fGzfGay8PS2qm+XV7r4ZQ2i6JnxVK8fhFX19e3BZZnuKVbD4XB4uc8PQoTx EJxcJyp/WcdjsBBUq8owc1/auJjgMNhKcamIo1PaQo4itKtXqYSq4HCKFR1KdOMZ1YwUJSmlUjXw 9bFVakYc0qlT61RoTxWKxPtJ05Olh6lanh3Qw8fl7W/+CavgLVP20NW/a2GlfsyaneeJNY8O+NNX 1rx1+xt8NfHf7Uvhrxx4U+Hui/DjR7f4SftZal4htNZ+Hvwzm0nwxomq6l4Qv/hp4y8bW+vXni2b wf8AFfwdpWvafo/h36Z+En7Ndl8Jj+zvFp3iS1udP/Z//Zuvv2eLLTbLwxFolnrlrdN8IvI8RWsE GsXUHhy3sovhUsMPhyGHVI/L1tVTV4l0oLqHuN98QPAema1p/hvUvG3hHT/EWrW9neaVoF94k0a0 1rU7TULsWFhdafpVxex317b31+y2VnPbQSRXN2wtoWeYhKy7n4t/CmyvLvTrz4m/D201DT7uHT7+ xufGnhuC8sr+5vZtNt7K7tZdSSe2u59Rt7iwhtpkSaW9gmtURp4njXjwmEzSjRp0MJhMd7GVqtKE cNWqxkvqmY5TGcOanO8I4TNsfg6fK3CnGvGNNRnQwzpb18RhqlSrXrV6Cn9XwOHrS9rClH2OAhh5 4NVIwlCnzU44elWdWUfa1pSrV606k8TiJ1fCPj/8Gv2ivF3xK+G/xV/Zw+NvwV+EfiTwb4K+I3gL XrT42/s5eOf2hND8RaL4+1v4c6+lxpFp4E/ah/Zkv/DOqaRffDyCNri91TxTaaja6pLGLCwmtUuJ vAfFn7AHji68H2vw48AfHPwX4Z8A/Ej4W2nwa/at0fxj8B7z4hX3xS8DyeKvGninxC3wWuIPjN4N 0L4B63rD/FT4paLYReKPDHx88DeHdB1nwnpmneAng8GsviD9EZfGnhCHxGPBsnirw2vjFtPfVo/C Ta7pSeJpdMRZGbUI9Dku01JrECKUm8+zi1URuWmVUYjP8M+PNI8U6hJplhb3cVxF4S8JeMXkefRr 6xbTPGT67HpkNtqWh6tq2n39zA3h+9N3Pp9zdaVJHLaTabqeowzNJHlRweNw/wBVxtOjiKccrf17 DyqOfsoU8di8TV55UKzdLF4KvjcRXq+wrU6+CeKcKnslVo0ZU6nWpSrc/tIwxLo1MCqtCXscRTV8 FWbhWw/JVoY2n7DAzoYyM6ePoQp0vq9enC9/hf4wfskftPeJvEnxBuvg5+0t8CvAfgX4gfGnwn8Y NV+HvxU/ZR+IfxestWTwz8K/BfgM+CvGGseCv2xfgJeeJPDUvijwF4e8eW1np8HhmxuY7V/BPjTT fHPhe91WDUfQfhN+x9P8Pfin4x+PureLPAd78b/jHq+iT/tBeLPAXwkuPh5onxZ8N6P8H/Bnw8s/ CV5o998R/HPiS2sfC3i3wjceOfhdqPiTxz421X4caV4s8YeB7C51O28UeIde1b62tPG/gu/8Rap4 PsfF3hi98W6JbC81rwtaa/pVz4i0izZbZ1utU0SG7fU7C2ZL2zcT3drFEVu7Zg+J4i+dp/xO+Gur aFfeKNK+IfgbU/DOl3yaZqfiLT/FmgXuhadqUhtQmnX2r22oSafaXzm+sglpcXEdwxvLUCMm4i31 DCZhClUpxwmLdKvg8Fgp82Hq1ObA16GBwuEoRnOEpRoY/DZXgsO4wlGOZUcOqdb6zCVRTmMsPGpV cKlOFSrJ0qqp1VBynhJVMQqUowklfB1q9XGUqdl9UxVWeMpxpYiTqv5V/Z6/ZS+Ifwo+IWjeKviT 8YPBPxP8OfCP4U6v8CP2a9G8NfBO6+GnizwJ8J/EGveENW1mz+LHjjUfix8SYPiz41urL4ZfDDSU 8R+DPCXwN8Mn/hHdY1K/8A6jfa5pz+GsL9sj/k4r/gk7/wBn/wDxH/8AXWX/AAUsr7R8PfEDwH4u uXsvCnjbwj4nvI9OttXktPD3iTRtauU0m9YpZ6o8Gm3tzKunXbgpbXrILadgVilc8V4l8evgn4k+ KvxU/Yn8daFqeh2Gl/s0/tN+K/jZ4ztdWmv4r/WvDevfsaftb/s5WumeGEs9PvLe41yLxh8f/Cms XEOq3Ok2C+G9J8Qzx6hJqkGm6VqeeJWMp+xw2NWJjPC0nTpxxaq/WFCrXr4upUrTrr29etiMVicR iq+JxEqlfE4ivVr1qtSpUlN6RqU606tenOE1XnCo1RlH6vTtQo06dPC0KbWGwmHVGFJ08NhKdHDx 5nVjSU6s5z+m6KKK5iwooooAKKKKACiiigAooooAKKKKAOR8eaq+i+D/ABDqMMUk08WnyQWsSeD/ ABP4+R7u+ZLG0F14P8GW914m1zT/ALTcxHU7fSofNi04XV3PLb2lvcXEXwdBeeTZXkugfDbWfhql rqPgnVNP+HHg74aftU3nw31vUvDPj3wx4uuNYuLT/hmXw3p3gbV/sGhX2lfa/DXgvVp/ED6uk/iC 4kOlWBX9H6K+kyTPaGUUpxngsRiassVQxCnSzBYWlbDypzhTq4Z4PEUsTeUZWniPauhzqpglhMSp Yifm4/AzxvJH21OnSjCpCUJUHUnP2nLzctZVqdSgvchzfV3SlWSlSxM6+GlKgfl94i0uBrf4pLae F/ijrg1jTvjJqXhK+uPAX7Zt7dXesfE611uSPQ/+FXax4F0/4U+GGtrnxBe2F74nt7++/tu3tobu XR9D1DU7u+sPSLjXovFA17VPFPhXxVpOo6xr3wXjGgaN8Cf2ldc0F/DHwo8Zx+KJry+vtQ+BGiTT a7q8N7qtpb6Uujvp2nw2ekWTazdI9xew/fNFe1U40pVY4dVMBmE6uGnRnSxE86hUqw9jicHjOWKq ZVOjTp1MXgqNeVKlSp06cnONCNGlOVN8f9jVOatL6xh0sRPFVK0VgnFVJ4yi6FeU3HFKcpSg9Jyn KaainKUYqJ+f3ji603XW16/0rS/im9y3xjs/ibo2jwfCr9rj4eLqNk3wy0/4f6nYXvjXwL8KV8S+ FNVe4fVdXivtHtNcgvY4oNP1G3kg1e/Njn2lp4dtvC3xD0mLw948tL/xj8GLD4fach+CH7V2vQab rJ1X4j63qkd5rvin4X6x4i1LSTf+M9Pb+2rqe41PVprK6vZdF0qNLDTYv0RorKnxjTp4Wjg44XNF RoPB+zj/AG1QUVHAfV3houksmVCTjLD80qzpPETVWrTnWlRcKcNJZTOdeWIlVwrqSjWjJvBTd1Xx k8dUXM8Y5pPEzlUUFNU+ZQm4OpCM18YfEn4jyeI7zwJqvh3wl4wurv4d+P4/FOn2HiL4LftM2Nn4 g04+AfEHh6Rbq7sfgFrEnh/VYNa8RTNZGCy1+CO00211Vpxd3LaPaeT3i3UWha1omn6L4nvV+JHh TV/C/jSfUPgV+09p6eAF1/xz4v8AGN3dfD+C1+BmoP4nh09fHV/aW1jqdz4Ea/vfDWg6q97ppu5r LTP0noqMHxVgsFRw+HoZVjFTw86c4qWbUG5yo1K1ei5y/sdP93i69XFx5HDmqyVOpz4aKw4Vsrr1 5OU8XSUnh44ZOOFqLlpxqwqxcf8AbH70ZRaTlzLlk7ptRa+BPEXj7xZb6t43t/CXhbxTqXhbxp41 0nxJqbat8N/2qvCPiO+0S18EeGvDt/4dNzpf7M3i+LSftuqeG4he6la3N7eah4fvb60tH0DVJINT tbfgnXNO8O+OdV+IE3h7x/pF34lvI7DVPDOk/BL9pjV9E0HwqfAvgvR1h8J3F78D9Gj03V9O8S+E Y0LadoehWXibw5JYtr6m+0Lw7baL94UUv9aMvWGnhoZRi6Sq4COWYmrTzen7TFYSNHB0eWvGeVTw 8qnLgcPKNaNCFWE4J05QSSR/Zdf2kajxdF8ld4mnTeEnyUq/tatZVKf+188Wqtac+TndKbVNVYVI 04xPzggea88O6l4b1XR/GOmQaD8F/GXwg8HaloXwM/acvLzxdH4nn0qRNf8AGthdfBDSLbw9IE8O 2D3ulWF94yW5vte166TVYFiSLUecTxd431HRdLu/+FZeNNBOla58WPE8NrffBr49an8Qv7Q+IyeJ rQXo0+x+EB8B3Gs6Bo2vXujaNoM/xDi0PxJ5mhalq/i3wZDpN1oUn6hUV2R42wqjONTJataMqtSt CNXM6bjSqYmniYY7ljHK4KpDHvGYmpiKWIVelTqVF9UhhoU6cI5vJqvtI1Y4yFOcZQneGGqauhDD U8LbmxcuSWEp4SjCjUpezqzSksTUxHPPm/OfVfE0tmulab4Z+H3xMvvCer+Ovgl4wv5fEfwX+PSe OvBkXgWTwJp1/o7aXa/CK88NatBp2keETeyavpnjTz0vb/U7DStD1eJ4L+5n1OHSrzSdbs4NK8dR 3mo+Ff2kdGt53/Z6/aPQR6l8ZPHdh4l0C6llT4MtKkVvpdo1t4hnjWS4huvLhsotUt8zr+iNFZR4 yw8FQ9nluNpyoVpYh1Fm1Gc61V4BZapVnVyipGXJgoqklCMOZxVWr7Sq5zkRyapHR4mjKCo4ajCm 8JKMKccLiKuLg4KGLg1KVevVnO7cUp+zpxp04qB+eWqajc33xisPHcWnfENdB0nxlH4gtlj+En7V umyX2jXnwvufAV/p2oeBdN+CcXg+41/TtTvJ9XtfGmrXfiDxNrOlJZeGG1Dw7oun2VrB2nw38YWn gFbGaTRfiFqdxb/C/wCDfgGWFPgV+0naQ/a/BF34li8UahHcN8E7h3tl0/xAt1oETW0cuq3lqbDU ToMEw1GL7ZorDEcVYPFYSnga2W42WGhg8vwHs1muGi5YXLas61CDksm5ouVWtXqVZU3CU5VpWcUo pawyurCt7eOIoKpzVJp/VKtlOrOE5yt9d11pwUVJyjTpxhSgo04RgvgRdcF1YeK/A954d8SW3hPU pfixd6R4+j/Z6/aX1X4i+d8UJ9avZIf7Gl+DGlab4dutOufEEtpqmu2vi3xA3iTSdIgtG0XRpNVa bRoI9cfxCdY1fxV4V8S6Dquo6p8DbZPD/hn4H/tOa54c/sD4ReNP+ErutRlu9S+A3h6RdX1WK/1D T9O0ddCkttOt9M0m3m8Q3UdxJJp36BUVS4swkW5RyzGxqOph6zqRzbD83t6OMo4+pWs8ncObF4vD 0a2Ijyeyg6cYYWnhqTnCallVaacZYqi4N4r3PqtTlUMXRVCdJf7ZzckIK9Jtuop2lOdS2vyB8J5t PTx/4d+zWPjC3bHx4aZ9S+Dnxr8J2Ek/xE+I2nfEDSJbrXfFvw18PeHbR4NE0e4tNRk1PV7R5dZa z0zSv7Ve5gdvr+iivnc3zGOZ4iFaFKtSjCnUjy18RSxM3OtjMVjaslUpYTBxUHVxU1CDpScEre0c eWMfQwuHlh41FKcJyq1FUlKFOVON1RpUVeM6tZ8zVJOUuZJt/De7ZRRRXlHUFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAf//ZMfh34p/ZL8U/AXxR4N8YfszeGPAnh/4AL4+8IfEXXLb4g6B8dvGOq/GX4s+OvC8dt8OJ PE/wr8G+F/CugWP018BvgT8U/gjFpF2F8AeJ9Rtf2fP2QvgleWR8V+ItFskuvg/qnjqx+KXiG21H /hAtXnuLe18N+N31jwBp0umWsni/XNKTw74iu/h9YagfFFj9qUVnTxmIhh4YWcoVqEKeXYeMJ0qN L/Zcr+t/VsNJ4WGHc1OWPxtTFYmblj8VXxVbEV8XOu41I9FRxq1qNWcIy9jQpYdU3Ko4zhTr08S3 Um6jrSc6tKEUlVUMPh4U8HgoYbB0MPh6P5h6R+yp8fLvSvjJ8CfEOg/s0aP8Gddu/wBqnVvh78fd M1Dxn4t/aF1W4/am17xv4u1bTtb+GV98PvB3hX4X6h4e1vx6+meMPG+ifHH4rSfGXQvCUTXPgv4c Xfi8p4KboX7LXx7+JU/jbx18ePBf7O3w98aeJfHH7Fdta/Dr4VfEz4hfF34Zj4f/ALIfxhk+LEPi 6613xr8FPg81p8QfENx4i17TdE8LWPwxks/Ddv4T8EwXnxO1+KaN/CX6fUVnQryw+KljqcYfW6jy qpWr2cJV8TkuYLMcBi6saTp05V6c74eaUI0J4VqLoe2p0a1PJ01LnvOrrisXiqbVWpH6u8fhqOHx VCioyS9hVnh6GLUaqq1KWMpRq0atOMp05/FnwS/Zo8R/Cz4geF/FM8ngqDSdJi/bJm1a18PPfxXV 7qv7R/7THh741+HdRWB9B062ubmPRNLvovGV3c3EdyniW4jSxOu2ks2qx/adFFTOrOpTo05O8cPG vGn3UcRjcVj6ib6/7RjK3L/LDkgtIouTc6tevJuVXE1nXrTk23OrKMIym27tykoJybbcpOUm22wo oorMAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigD//Z////f////3/6////bDsTAHgMojoBAAAA/v////////////9/ AAAAgP///3////9/QO7CDAFpdGxo5QwNkNYqOwAAAIAAAAAAAAAAAAAAAABw5QwNKM8qOwIAAIDA FggNgM4qOwMAAIDMFggNgM4qOwQAAIAAAAAAAAAAAAAAAAA1JQAA2M0qOwYAAIAAAAAAAAAAAAAA AAC0aRcw/////wAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAEAAAABAAAAAAAAAAEAAQD///////// /wAAAAAAAAAAAAAAAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0aRcw/////wAAAAAAAAAA AAAAAAEAAAAAAAAAAAAAAAEAAAABAAAAAQAAAAEAAQD//////////wAAAAAAAAAAAAAAAAMAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAVBcLDfv///9sOxMAeAyiOgEAAAD///////////// /38AAACA////f////3/6////bDsTAHgMojoBAAAA/v////////////9/AAAAgP///3////9/ZT0i MCIgZGlydHk9IjAiPjxhOmdyYWRGaWxsIGZsaXA9Im5vbmUiIHJvdFdpdGhTaGFwZT0iMSI+PGE6 Z3NMc3Q+PGE6Z3MgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAODJKjsb AACAAAAAAODJKjscAACAAQAAAODJKjsdAACAtDcIDQAAAAD///9/AAAAAAAAAAAAAAAAAAAAAGDw wgwHAAAAOH8HDYA4CA1wOAgNwOgHDTB/Bw1QOAgNQDgIDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYTplSOcMDZDWKjsAAACAAAAAAAAAAAAAAAAA UOcMDSjPKjsCAACAABgIDYDOKjsDAACADBgIDYDOKjsEAACAAAAAAAAAAAAAAAAANSUAANjNKjsG AACAAAAAAAAAAAAAAAAAAAAAACDxwgwHAAAAEH8HDYA3CA1wNwgNaOgHDQh/Bw1QNwgNQDcIDQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhcmFSAAAA AIDxwgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAODxwgwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqBzHDMjLKjsBAACAAAAAAAAAAAAAAAAAATsT AODJKjsbAACAADsTAODJKjscAACAATsTAODJKjsdAACAAAAAAOQiKzseAACAAAAAAAAAAAAAAAAA AAAAAKDywgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADzwgwBAAAA4KsKDQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGDzwgwEAAAASBjHDHgaxwyAGscMiBrHDAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6 bGF0AAAAAMDzwgwBAAAAAOu6DAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQcj48AgAAALgXCw37////bDsT AHgMojoBAAAA//////////////9/AAAAgP///3////9/+v///2w7EwB4DKI6AQAAAP7///////// ////fwAAAID///9/////f4D0wgwAAAAAMOkMDZDWKjsAAACAAAAAAAAAAAAAAAAAOOkMDSjPKjsC AACAWBkIDYDOKjsDAACAmBkIDYDOKjsEAACAAAAAAAAAAAAAAAAANSUAANjNKjsGAACAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKNcKDcjLKjsBAACAAAAAAAAAAAAAAAAAAAAAAODJKjsbAACAAAAA AODJKjscAACAAQAAAODJKjsdAACA5AINDQAAAAD///9/AAAAAAAAAAAAAAAAAAAAAED1wgwHAAAA ONcKDcACDQ3wAg0NAGUNDUDXCg0g2Q0N8NgNDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABwSBg37////bDsTAHgMojoBAAAA//////// //////9/AAAAgP///3////9/+v///2w7EwB4DKI6AQAAAP7/////////////fwAAAID///9///// f2D2wgwBPC9hEOsMDZDWKjsAAACAAAAAAAAAAAAAAAAAGOsMDSjPKjsCAACAZBoIDYDOKjsDAACA cBoIDYDOKjsEAACAAAAAAAAAAAAAAAAANSUAANjNKjsGAACAAAAAAAAAAAAAAAAAAAAAAGD2wgwB AAAAIKwKDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMD2wgwBAAAAoMYPDQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgAAADib0wz7////bDsTAHgMojoBAAAA//////////////9/AAAAgP///3// //9/+v///2w7EwB4DKI6AQAAAP7/////////////fwAAAID///9/////fwAAAAAAYTpk6OwMDZDW KjsAAACAAAAAAAAAAAAAAAAA8OwMDSjPKjsCAACAzBoIDYDOKjsDAACA2BoIDYDOKjsEAACAAAAA AAAAAAAAAAAANSUAANjNKjsGAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUHkIDcjLKjsBAACA AAAAAAAAAAAAAAAAATsTAODJKjsbAACAADsTAODJKjscAACAATsTAODJKjsdAACAxIMGDQAAAAD/ //9/AAAAAAAAAAAAAAAAAAAAAED4wgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKD4wgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABwYCw37////bDsTAHgMojoB AAAA//////////////9/AAAAgP///3////9/+v///2w7EwB4DKI6AQAAAP7/////////////fwAA AID///9/////fwAAAAABPGE6yO4MDZDWKjsAAACAAAAAAAAAAAAAAAAA0O4MDSjPKjsCAACAcBsI DYDOKjsDAACAgBsIDYDOKjsEAACAAAAAAAAAAAAAAAAANSUAANjNKjsGAACAAAAAAAAAAAAAAAAA AAAAAMD5wgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACD6wgwAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA0AcAAMDKKjsQAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ATsTAODJKjsbAACAADsTAODJKjscAACAATsTAODJKjsdAACAAAAAAOQiKzseAACAAAAAAAAAAAAA AAAAAgAAAIAYCw37////bDsTAHgMojoBAAAA//////////////9/AAAAgP///3////9/+v///2w7 EwB4DKI6AQAAAP7/////////////fwAAAID///9/////fwAAAAABIGN4qEANDZDWKjsAAACAAAAA AAAAAAAAAAAAsEANDSjPKjsCAACA2BsIDYDOKjsDAACA8BsIDYDOKjsEAACAAAAAAAAAAAAAAAAA NSUAANjNKjsGAACAAAAAAAAAAAAAAAAAAAAAAKD7wgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD8wgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAANQYCw37//// bDsTAHgMojoBAAAA//////////////9/AAAAgP///3////9/+v///2w7EwB4DKI6AQAAAP7///// ////////fwAAAID///9/////fwAAAAAAb250iEINDZDWKjsAAACAAAAAAAAAAAAAAAAAkEINDSjP KjsCAACAQBwIDYDOKjsDAACATBwIDYDOKjsEAACAAAAAAAAAAAAAAAAANSUAANjNKjsGAACAAAAA AAAAAAAAAAAAAAAAACD9wgwCAAAATLkKDaBkDw0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAID9wgwA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAADgZCw37////bDsTAHgMojoBAAAA//// //////////9/AAAAgP///3////9/+v///2w7EwB4DKI6AQAAAP7/////////////fwAAAID///9/ ////fwAAAAAAbHIgaEQNDZDWKjsAAACAAAAAAAAAAAAAAAAAcEQNDSjPKjsCAACAmBwIDYDOKjsD AACApBwIDYDOKjsEAACAAAAAAAAAAAAAAAAANSUAANjNKjsGAACAAAAAAAAAAAAAAAAAAAAAAKD+ wgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/wgwAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAGD/wgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZlJQ cj48L2E6bHZsNHBQcj48YTpsdmw1cFByIG1hckw9IjAiIGluZGVudD0iMCI+PGE6YnVGb250VHgv PjxhOlBLAwQUAAYACAAAACEAHOCHA5gBAABjAwAAEQAAAHBwdC92aWV3UHJvcHMueG1sjFI9b8Iw EN0r9T9Y3mlCBDSNCCxVJwYkaHfXNsGSY1s+E6C/vucYCqUd2Hxf79575+n80GrSSQ/KmpoOn3JK pOFWKNPU9H39NigpgcCMYNoaWdOjBDqfPT5MXdUpuV96ggAGKlbTbQiuyjLgW9kyeLJOGqxtrG9Z wNA3mfBsj8Ctzoo8n2QtU4ae5v0983azUVy+Wr5rpQkJxEvNApKHrXJwRnP3oDkvAWH66d+UNIPw gepqClqst7v20zClY4bOULiJkvpw6WOMOMF6KRZyEwh8oY3jSZHT7Lq2tq4vvYwmk76U/cUBrYSM WxIsX2lxFaUn6ZhfcabxFMOeDMRgNmUVHAhecDymRGAt75dg9vg3i6tPU66yXjXKkENNB+UQj3+M j1Hkjl38sr7ZIbcFhKipfxOcRPfQaOu/KHEWaloMk7ZzS0qW5VnwBSSCX8mLjH6LNzZIWMtDf4eT Hxc2N6Kj2n9U36TjkmTWteyk+czwRzE2/0Oh8UqsHOP4iQlHz57LvEB5iMHRuJ8oudelS34DAAD/ /wMAUEsDBBQABgAIAAAAIQDEujLU0gAAAF8BAAARAAAAcHB0L3ByZXNQcm9wcy54bWyMj8tOAzEM RfdI/EPkPc0UoYJGk1SIxw6pC/gAk/HMRMpLdlrg74l4iLLrzpbvPb532L7HoA7E4nMysF51oCi5 PPo0G3h5fry4ASUV04ghJzLwQQJbe342lL4wCaWKtVl3rBooSY8GllpLr7W4hSLKKhdK7TZljljb yrMeGd/agxj0ZddtdESf4MfPp/jzNHlH99ntYwvwDWEKX0lk8UV+aeUU2nGPf5FsK+kCP/HeDtgL z693gdUBg4Gr627zcAvaDvpP08Zj1o7tJwAAAP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAA ABMAAABwcHQvdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNRJBTCICt36gEqlCHpQGij EuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAKC3m236U8cU95c6sUV+vQ pmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJnsE3qoIgorTAp8vliGlI A1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAwQUAAYACAAAACEA4Xi5DGcBAACfAgAAEQAIAWRv Y1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhJJdT8Mg GIXvTfwPDfct0KpxpOsSp7vaEqNdNN4ReLcRW1qBffTfS9utbtHES95zeDgHSCeHsgh2YKyq9BjR iKAAtKik0usxWuaz8B4F1nEteVFpGKMGLJpk11epqJmoDDybqgbjFNjAk7Rloh6jjXM1w9iKDZTc Rt6hvbiqTMmdX5o1rrn45GvAMSF3uATHJXcct8CwHojoiJRiQNZbU3QAKTAUUIJ2FtOI4h+vA1Pa Pzd0ypmzVK6pfadj3HO2FL04uA9WDcb9fh/tky6Gz0/x+2L+2lUNlW7vSgDKUimYU66AbDpfPgUv 8LVVps+b4kFrXcIAd5XJeFE0utNOk/aOC27dwj/HSoF8aE6m30LrNbBT7TtmlNym+Hzgz+nK94eB DHwd1pc/KW/J9DGfoSwmlIYkCeNRTkYsjhlNPtpUF/vbev2gPGb7l3gXxklOblhCWELPiCdA1iW+ /FLZNwAAAP//AwBQSwMEFAAGAAgAAAAhAMrFwLl1AgAAwQUAABAACAFkb2NQcm9wcy9hcHAueG1s IKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFRRT9swEH6ftP9g5Wl7aJ3QDljl Gk0FBBOMSg3s2YsvrbXEzmxTYL9+57gNKasqbXm6u+/y2fed79jZc12RNVinjJ4m2TBNCOjCSKWX 0+Q+vxycJsR5oaWojIZp8gIuOePv37G5NQ1Yr8ARpNBumqy8byaUumIFtXBDhDUipbG18OjaJTVl qQo4N8VjDdrTozQ9pvDsQUuQg6YjTCLjZO3/l1SaItzPPeQvDV6YsxzqphIeeI6XA3J9kV8y2gVZ bryoclUD/zQef0Kk89l3Y6Xjo5NTRqPJvjRNpQrhUTF+qwprnCk9uWtrI3PzBHZulPaM9hNRL3BY dPvbZasJv9MDV1gATRYr80Q+jCejj4zuSWRzYcXSimbl+Cler+eyRaUkOJ6ljG5M9s34EGE0GuxK SQl6g2Lejs9ub2eVahxHYGuyRSEqmKGCvBSVA6TuAuwKRHgdc6Gs42ztJ2sovLHEqd/4PsYJ+SEc BN2nyVpYJbRH/UNadFq7apy3sReMIhb91uyn9W01DhVhLhoHEyNXWy3Jla/A/csRqMK+M0Iw1omH 7yoQz7grsSl+jyBZ1lekvVzUo6fB5j2+CtFZs5v7C0KutQeravL1UQM5SrOMSCtKP7CmFto8DSz8 elQWH7b2bpCOhv2CO6owEMaBJMVK6CWOrdKRhgzT0d4/ooaHsPGB//CddmeH/vf7cnwAOzmA4RB2 TG85Px/AwnS8/rjTzDftm5m6EfqFz5QrDKNbl90o/dPdN7k5D1tkMxW7QbZYCQsS19sWfw2wKxwI WwWSWSu/3Ob8DYQF8xA3Ms+Ohil+7S7ZxsKK2O5e/gcAAP//AwBQSwECLQAUAAYACAAAACEAuAs+ t3QCAACiEgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAI AAAAIQBo+HShBQEAAOICAAALAAAAAAAAAAAAAAAAAK0EAABfcmVscy8ucmVsc1BLAQItABQABgAI AAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAOMHAABwcHQvc2xpZGVzL19yZWxzL3NsaWRl NC54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAOAIAABw cHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcB AAAgAAAAAAAAAAAAAAAAAN0JAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc1BLAQIt ABQABgAIAAAAIQBNdHi9GwEAAB8DAAAgAAAAAAAAAAAAAAAAANoKAABwcHQvc2xpZGVzL19yZWxz L3NsaWRlMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAA ADMMAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3s vwAAADcBAAAgAAAAAAAAAAAAAAAAADANAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNi54bWwucmVs c1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAC0OAABwcHQvc2xpZGVz L19yZWxzL3NsaWRlNy54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAA AAAAAAAAACoPAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlOC54bWwucmVsc1BLAQItABQABgAIAAAA IQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAACcQAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlOS54 bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAhAAAAAAAAAAAAAAAAACQRAABwcHQv c2xpZGVzL19yZWxzL3NsaWRlMTAueG1sLnJlbHNQSwECLQAUAAYACAAAACEANG9vrHEBAAAcCQAA HwAAAAAAAAAAAAAAAAAiEgAAcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVsc1BLAQItABQA BgAIAAAAIQDKMFT9pAIAABoOAAAUAAAAAAAAAAAAAAAAANgUAABwcHQvcHJlc2VudGF0aW9uLnht bFBLAQItABQABgAIAAAAIQCUUd1WFgMAAB4KAAAVAAAAAAAAAAAAAAAAAK4XAABwcHQvc2xpZGVz L3NsaWRlMS54bWxQSwECLQAUAAYACAAAACEAJQco7pAEAABKDwAAFQAAAAAAAAAAAAAAAAD3GgAA cHB0L3NsaWRlcy9zbGlkZTkueG1sUEsBAi0AFAAGAAgAAAAhAAFIKVAyBQAA1hIAABUAAAAAAAAA AAAAAAAAuh8AAHBwdC9zbGlkZXMvc2xpZGU4LnhtbFBLAQItABQABgAIAAAAIQBQd5LW5gQAAK4O AAAVAAAAAAAAAAAAAAAAAB8lAABwcHQvc2xpZGVzL3NsaWRlNy54bWxQSwECLQAUAAYACAAAACEA yW25ODkFAAA2FQAAFQAAAAAAAAAAAAAAAAA4KgAAcHB0L3NsaWRlcy9zbGlkZTYueG1sUEsBAi0A FAAGAAgAAAAhAORVZ/FoBAAAsg4AABYAAAAAAAAAAAAAAAAApC8AAHBwdC9zbGlkZXMvc2xpZGUx MC54bWxQSwECLQAUAAYACAAAACEAJJLqsaEFAAD4FwAAFQAAAAAAAAAAAAAAAABANAAAcHB0L3Ns aWRlcy9zbGlkZTQueG1sUEsBAi0AFAAGAAgAAAAhAIcnRLpfAwAAXQoAABUAAAAAAAAAAAAAAAAA FDoAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbFBLAQItABQABgAIAAAAIQBFhkJzNAUAAAIUAAAVAAAA AAAAAAAAAAAAAKY9AABwcHQvc2xpZGVzL3NsaWRlNS54bWxQSwECLQAUAAYACAAAACEAfqMJmKQF AAD5FgAAFQAAAAAAAAAAAAAAAAANQwAAcHB0L3NsaWRlcy9zbGlkZTMueG1sUEsBAi0AFAAGAAgA AAAhAEqvdTnUAAAAvwEAACoAAAAAAAAAAAAAAAAA5EgAAHBwdC9ub3Rlc1NsaWRlcy9fcmVscy9u b3Rlc1NsaWRlMS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAA AAAAAABKAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc1BLAQIt ABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAAhLAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAs AAAAAAAAAAAAAAAAABBMAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwu cmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAABhNAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLx vgAAADcBAAAsAAAAAAAAAAAAAAAAACBOAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0My54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAChP AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54bWwucmVsc1BLAQItABQABgAI AAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAADBQAABwcHQvc2xpZGVMYXlvdXRzL19yZWxz L3NsaWRlTGF5b3V0OS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAAAAA AAAAAAAAADhRAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHNQ SwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAABBUgAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAHImrcwkCQAA oz4AACEAAAAAAAAAAAAAAAAASlMAAHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbFBL AQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAK1cAABwcHQvc2xpZGVMYXlv dXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc1BLAQItABQABgAIAAAAIQDKDhnb2QAAAL4B AAAsAAAAAAAAAAAAAAAAALVdAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54 bWwucmVsc1BLAQItABQABgAIAAAAIQAo+8AvgAMAAPEIAAAhAAAAAAAAAAAAAAAAANheAABwcHQv c2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWxQSwECLQAUAAYACAAAACEA+4KJQX8EAAA3DgAA IgAAAAAAAAAAAAAAAACXYgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbFBLAQIt ABQABgAIAAAAIQD5LR8eOQQAAFcNAAAiAAAAAAAAAAAAAAAAAFZnAABwcHQvc2xpZGVMYXlvdXRz L3NsaWRlTGF5b3V0MTAueG1sUEsBAi0AFAAGAAgAAAAhAD4A4lJoBQAAARQAACEAAAAAAAAAAAAA AAAAz2sAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbFBLAQItABQABgAIAAAAIQBp ol8hHgEAAMcHAAAsAAAAAAAAAAAAAAAAAHZxAABwcHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRl TWFzdGVyMS54bWwucmVsc1BLAQItABQABgAIAAAAIQC8f/IqnAUAAEEUAAAhAAAAAAAAAAAAAAAA AN5yAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54bWxQSwECLQAUAAYACAAAACEAYt7j TK8DAABDCgAAIQAAAAAAAAAAAAAAAAC5eAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDYu eG1sUEsBAi0AFAAGAAgAAAAhAO0UsaNCBgAAGh4AACEAAAAAAAAAAAAAAAAAp3wAAHBwdC9zbGlk ZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQCNa8DZbQIAANIFAAAfAAAA AAAAAAAAAAAAACiDAABwcHQvbm90ZXNTbGlkZXMvbm90ZXNTbGlkZTEueG1sUEsBAi0AFAAGAAgA AAAhABg6ucrQBAAA8hMAACEAAAAAAAAAAAAAAAAA0oUAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQ0LnhtbFBLAQItABQABgAIAAAAIQBnLGe8JAYAABsUAAAhAAAAAAAAAAAAAAAAAOGKAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwECLQAUAAYACAAAACEAPlOWBvQEAACM DwAAIQAAAAAAAAAAAAAAAABEkQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1sUEsB Ai0AFAAGAAgAAAAhAL5hN5aFAwAADwwAACEAAAAAAAAAAAAAAAAAd5YAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQyLnhtbFBLAQItABQABgAIAAAAIQDtoGq9SwoAADE7AAAUAAAAAAAAAAAA AAAAADuaAABwcHQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQCuZVF0BwYAAD8dAAAh AAAAAAAAAAAAAAAAALikAABwcHQvbm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVyMS54bWxQSwECLQAU AAYACAAAACEAtM9YGbsAAAAkAQAALAAAAAAAAAAAAAAAAAD+qgAAcHB0L25vdGVzTWFzdGVycy9f cmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA+c8JOYMGAABcGwAAFAAA AAAAAAAAAAAAAAADrAAAcHB0L3RoZW1lL3RoZW1lMi54bWxQSwECLQAKAAAAAAAAACEAKob2qIYP AACGDwAAFAAAAAAAAAAAAAAAAAC4sgAAcHB0L21lZGlhL2ltYWdlMS5wbmdQSwECLQAKAAAAAAAA ACEAfbX2ugCAAAAAgAAAFwAAAAAAAAAAAAAAAABwwgAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWdQ SwECLQAUAAYACAAAACEAHOCHA5gBAABjAwAAEQAAAAAAAAAAAAAAAAClQgEAcHB0L3ZpZXdQcm9w cy54bWxQSwECLQAUAAYACAAAACEAxLoy1NIAAABfAQAAEQAAAAAAAAAAAAAAAABsRAEAcHB0L3By ZXNQcm9wcy54bWxQSwECLQAUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAAAAAAAAAAAAAABtRQEA cHB0L3RhYmxlU3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQDheLkMZwEAAJ8CAAARAAAAAAAAAAAA AAAAAEpGAQBkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQDKxcC5dQIAAMEFAAAQAAAA AAAAAAAAAAAAAOhIAQBkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAA9AD0AOhIAAJNMAQAAAA== ------_=_NextPart_001_01CC315F.207A1093-- From espeberg@cisco.com Thu Jun 23 00:08:29 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEAB21F847F for ; Thu, 23 Jun 2011 00:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3692UtRizOpM for ; Thu, 23 Jun 2011 00:08:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0C56421F8481 for ; Thu, 23 Jun 2011 00:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=14538; q=dns/txt; s=iport; t=1308812907; x=1310022507; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=D/56NnkvlkXCqZwMABuOYMdnejlccCtht6Wv/pHCLFk=; b=KST5fhutQI2uFSt8PLQx8Eclm1blyLc7HbpArf+hRVEJREC2HE7+y/MB cyW2MUBJBAop94wOcvdWlZ0Au/AkDqoesmnivlccY0MXct8Th2WZxDfyF ZfeOoTXCW8PdefMZpHt5+oeEF5L44hV+Pm6Y5xKYuvrOpYuKf0c0P7Pk8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8BAIvlAk6Q/khR/2dsb2JhbABTglGVM48ad6t+njGGLQSWYIsi X-IronPort-AV: E=Sophos;i="4.65,411,1304294400"; d="scan'208,217";a="96419185" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 23 Jun 2011 07:08:25 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5N78PL5011880; Thu, 23 Jun 2011 07:08:25 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 09:08:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3174.5845CFDE" Date: Thu, 23 Jun 2011 09:08:24 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E71BAC0@XMB-AMS-214.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6770@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] use case and requirement for multi-view Thread-Index: Acwwj6m4l9xOCH4NSAO5KaTj+QfrLwATEhGgABdIWFAADqhtEA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6357@xmb-sjc-221.amer.cisco.com><00fd01cc30dc$2496e930$6dc4bb90$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6770@xmb-sjc-221.amer.cisco.com> From: "Espen Berger (espeberg)" To: "Allyn Romanow (allyn)" , "Roni Even" , "Gorzynski, Mark E (The Right One)" X-OriginalArrivalTime: 23 Jun 2011 07:08:25.0714 (UTC) FILETIME=[58782D20:01CC3174] Cc: clue@ietf.org Subject: Re: [clue] use case and requirement for multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 07:08:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3174.5845CFDE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Could we use multi-view as test for the extensibility of CLUE? The last CLUE requirement talks about extensibility and building Multi-view systems on top of CLUE would be a verification of CLUE extensibility. =20 =20 I think that multi-view is too much to cover in the initial CLUE work.=20 =20 Cheers =20 -Espen =20 =20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) Sent: 23. juni 2011 02:09 To: Roni Even; Gorzynski, Mark E (The Right One) Cc: clue@ietf.org Subject: Re: [clue] use case and requirement for multi-view =20 Hi Roni, =20 The intention of the use case was for multi-view, multiple cameras on the same scene. If the material is to be put in the document, I think it should be a separate use case, not a subset of others. =20 In terms of including multi-view in the requirements, I'm fine to withdraw it and it can always be added later when someone wants it. If there is not a particular champion for multi-view who wants it now, then I think we can safely wait till later. =20 Regards, Allyn =20 =20 From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: Wednesday, June 22, 2011 5:59 AM To: Allyn Romanow (allyn) Cc: clue@ietf.org Subject: RE: use case for multi-view =20 Hi Allyn, I sis not add it, I sent the following question to the list on May 17th and did not get any response yet =20 "Hi Mark, I am trying to see how to fit this case in the use-cases draft. When I ignore the term "virtual space" and look at the description it talks about describing the view point of each cameras that may overlap and allowing the receivers to select the view they want. I see some resemblance to the education usage described.=20 Will it make sense to mentio vide different view in the point to point symmetric or asymmetric case which has a case with a PTZ camera." =20 =20 Roni Even =20 =20 From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 Sent: Wednesday, June 22, 2011 6:51 AM To: Roni Even Cc: clue@ietf.org =20 Hi Roni, I thought Mark's use case for multi-view was added to the Use Case doc, but I couldn't find it there? Is it just not added yet or is there some issue with it? =20 Thanks much ------_=_NextPart_001_01CC3174.5845CFDE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Could we use multi-view as test for = the extensibility of CLUE? The last CLUE requirement talks about = extensibility and building Multi-view systems on top of CLUE would be a = verification of CLUE extensibility. 

 

I think = that multi-view is too much to cover in the initial CLUE work. =

 

Cheers

 

-Espen 

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Allyn Romanow (allyn)
Sent: 23. juni 2011 = 02:09
To: Roni Even; Gorzynski, Mark E (The Right = One)
Cc: clue@ietf.org
Subject: Re: [clue] use case = and requirement for multi-view

 

Hi Roni,

 

The = intention of the use case was for multi-view, multiple cameras on the = same scene.

If the material is to be put in the document, I = think it should be a separate use case, not a subset of = others.

 

In terms of = including multi-view in the requirements, I’m fine to withdraw it = and it can always be added later when someone wants it. If there is not = a particular champion for multi-view who wants it now, then I think we = can safely wait till later.

 

Regards,

Allyn

 

 

From:= Roni Even = [mailto:Even.roni@huawei.com]
Sent: Wednesday, June 22, 2011 = 5:59 AM
To: Allyn Romanow (allyn)
Cc: = clue@ietf.org
Subject: RE: use case for = multi-view

 

Hi Allyn,

I sis not = add it, I sent the following question to the list on May 17th and did = not get any response yet

 

"Hi = Mark,

I am trying to see how to fit this case in the = use-cases draft. When I ignore the term "virtual space" and = look at the description it talks about describing the view point of each = cameras that may overlap and allowing the receivers to select the view = they want. I see some resemblance to the education usage described. =

Will it make sense to mentio vide different view = in the point to point symmetric or asymmetric case which has a case with = a PTZ camera."

 

 

Roni = Even

 

 

From:= Allyn = Romanow (allyn) [mailto:allyn@cisco.com]
Sent: Wednesday, = June 22, 2011 6:51 AM
To: Roni Even
Cc: = clue@ietf.org

 

Hi = Roni,

I thought Mark’s use case for multi-view was added to = the Use Case doc, but I couldn’t find it there? Is it just not = added yet or is there some issue with it?

 

Thanks = much

------_=_NextPart_001_01CC3174.5845CFDE-- From stephane.proust@orange-ftgroup.com Thu Jun 23 01:10:36 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9960611E80A0 for ; Thu, 23 Jun 2011 01:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9Nm4xnyneQN for ; Thu, 23 Jun 2011 01:10:35 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC7911E8098 for ; Thu, 23 Jun 2011 01:10:34 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8D82B8C0005; Thu, 23 Jun 2011 10:11:16 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 4F1048B8008; Thu, 23 Jun 2011 10:11:16 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 10:10:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC317D.04FFE43E" Date: Thu, 23 Jun 2011 10:10:30 +0200 Message-ID: <4D1AA2A55522044480C9B9CF97A9340901BD10FC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] clarification on requirements draft 03 Thread-Index: Acww6YZZVa3mScTXQaOOjW4h3bdCLAAkoWdQ From: To: X-OriginalArrivalTime: 23 Jun 2011 08:10:31.0982 (UTC) FILETIME=[057F8CE0:01CC317D] Cc: clue@ietf.org Subject: Re: [clue] clarification on requirements draft 03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 08:10:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC317D.04FFE43E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 Since we are dealing with "requirements" and depending on how you read = and understand the hierarchy of requirements (2b with respect to 2), = this could mean that the solution MAY NOT support any mean to identify = more than the following 3 cases : monaural, stereophonic and 3.0 L/C/R.=20 =20 If the intention is not to limit to those 3 cases (although the more = important ones with respect to existing solutions) which is needed to = design a future proof solution I would suggest to make it more explicit = by using some wording like : =20 The solution MUST support a means to identify the number and spatial = arrangement of audio channels including=20 monaural, stereophonic (2.0), and 3.0 (left, center, right) audio channels. =20 Regards =20 St=E9phane ________________________________ De : Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Envoy=E9 : mercredi 22 juin 2011 16:34 =C0 : PROUST Stephane RD-TECH-LAN Cc : clue@ietf.org Objet : Re: [clue] clarification on requirements draft 03 The requirement is not intended to preclude a higher number of channels, = it is intended to say that the solution has to at least include those = three modes. =20 The rationale is that those are the modes in use today by telepresence = systems. Regards, Stephen Botzko On Wed, Jun 22, 2011 at 9:13 AM, = wrote: Hi =09 I 've maybe missed some discussions related to some of the = modifications brought in draft 03 with respect to draft 02 but I would = appreciate some clarification/explanation about the limitation to 3 = audio channels introduced in REQMT-2b : =09 REQMT-2b: The solution MUST support a means to identify monaural, stereophonic (2.0), and 3.0 (left, center, right) audio channels. =09 Is it the intent to exclude the multiplexing of a higher number of = channels ? If the intent is to introduce some limitation, what is the rationale = behind and why such limit is set to 3.0 ? =09 Thanks =09 St=E9phane =09 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =09 ------_=_NextPart_001_01CC317D.04FFE43E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,=20
 
Since we are dealing with "requirements" and = depending on=20 how you read and understand the hierarchy of requirements (2b with = respect to=20 2), this could mean that = the solution=20 MAY NOT support any mean to identify more than the following 3 cases : monaural, = stereophonic and=20 3.0 L/C/R.
 
If the=20 intention is not to limit to those 3 cases (although the more important = ones=20 with respect to existing solutions) which is needed to design a future = proof=20 solution I would suggest to make it more explicit by using some wording = like=20 :
 
The = solution MUST support=20 a means to identify the number and spatial=20 arrangement of audio channels=20 including 
        = ;            =    =20 monaural, stereophonic (2.0), and 3.0 (left,
      =  =20                 center, right) = audio=20 channels.
 
On Wed, Jun 22, = 2011 at 8:58 AM, Roni Even <Even.roni@huawei.com> wrote:

Hi Allyn,

I sis not add it, I sent the = following question to the list on May 17th and did not get any response yet=

=A0

"Hi Mark,

I am trying to see how to fit this case in the use-cases draft. When I ign= ore the term "virtual space" and look at the description it talks= about describing the view point of each cameras that may overlap and allow= ing the receivers to select the view they want. I see some resemblance to t= he education usage described.

Will it make sense t o mentio vide different view in the point to point symmetric or asymmetric case whic= h has a case with a PTZ camera."

=A0

=A0

Roni Even

=A0

=A0

From:= Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent:= Wednesday, June 22, 2011 6:51 AM
To: Roni Even
Cc: clue@ie tf.org

=A0=

Hi Roni,

I thought Mark=92s use case for multi-view was added to the Use Case doc, = but I couldn=92t find it there? Is it just not added yet or is there some i= ssue with it?

=A0

Thanks m= uch


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

Regards
 
St=E9phane

De : Stephen Botzko=20 [mailto:stephen.botzko@gmail.com]
Envoy=E9 : mercredi 22 = juin 2011=20 16:34
=C0 : PROUST Stephane = RD-TECH-LAN
Cc :=20 clue@ietf.org
Objet : Re: [clue] clarification on = requirements=20 draft 03

The requirement is not intended to preclude a higher number = of=20 channels, it is intended to say that the solution has to at least = include those=20 three modes. 

The rationale is that those are the modes in = use=20 today by telepresence systems.

Regards,
Stephen Botzko

On Wed, Jun 22, 2011 at 9:13 AM, <stephane.proust@orange= -ftgroup.com>=20 wrote:
Hi

I=20 've maybe missed some discussions related to some of the modifications = brought=20 in draft 03 with respect to draft 02 but I would appreciate some=20 clarification/explanation about the limitation to 3 audio channels = introduced=20 in REQMT-2b :

REQMT-2b:  The solution MUST support a means = to=20 identify
                =  =20       monaural, stereophonic (2.0), and 3.0 = (left,
 =20                     =  =20 center, right) audio channels.

Is it the intent to exclude the=20 multiplexing of a higher number of channels ?
If the intent is to = introduce=20 some limitation, what is the rationale behind and why such limit is = set to 3.0=20 =  ?

Thanks

St=E9phane

__________________________= _____________________
clue=20 mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

------_=_NextPart_001_01CC317D.04FFE43E-- From Even.roni@huawei.com Thu Jun 23 02:01:39 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0517D11E80BE for ; Thu, 23 Jun 2011 02:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.523 X-Spam-Level: X-Spam-Status: No, score=-105.523 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVnxEtEUyYyN for ; Thu, 23 Jun 2011 02:01:37 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3857D11E80A6 for ; Thu, 23 Jun 2011 02:01:34 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN8002TUJP3X0@szxga03-in.huawei.com> for clue@ietf.org; Thu, 23 Jun 2011 17:00:39 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN8001OMJP3ZT@szxga03-in.huawei.com> for clue@ietf.org; Thu, 23 Jun 2011 17:00:39 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-35-190.red.bezeqint.net [79.176.35.190]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN8009G3JOTSC@szxml12-in.huawei.com>; Thu, 23 Jun 2011 17:00:39 +0800 (CST) Date: Thu, 23 Jun 2011 11:58:33 +0300 From: Roni Even In-reply-to: <92DF9533227FC14F946C7321074B8C9E71BAC0@XMB-AMS-214.cisco.com> To: "'Espen Berger (espeberg)'" , "'Allyn Romanow (allyn)'" , "'Gorzynski, Mark E (The Right One)'" Message-id: <003e01cc3183$c1205460$4360fd20$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zCxAu1UXcdV5FIB1rpP0Ng)" Content-language: en-us Thread-index: Acwwj6m4l9xOCH4NSAO5KaTj+QfrLwATEhGgABdIWFAADqhtEAAD5ssA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6357@xmb-sjc-221.amer.cisco.com> <00fd01cc30dc$2496e930$6dc4bb90$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6770@xmb-sjc-221.amer.cisco.com> <92DF9533227FC14F946C7321074B8C9E71BAC0@XMB-AMS-214.cisco.com> Cc: clue@ietf.org Subject: Re: [clue] use case and requirement for multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 09:01:39 -0000 This is a multi-part message in MIME format. --Boundary_(ID_zCxAu1UXcdV5FIB1rpP0Ng) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I will add multi-view as a separate use case to the use case draft Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, June 23, 2011 10:08 AM To: Allyn Romanow (allyn); Roni Even; Gorzynski, Mark E (The Right One) Cc: clue@ietf.org Subject: RE: [clue] use case and requirement for multi-view Could we use multi-view as test for the extensibility of CLUE? The last CLUE requirement talks about extensibility and building Multi-view systems on top of CLUE would be a verification of CLUE extensibility. I think that multi-view is too much to cover in the initial CLUE work. Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) Sent: 23. juni 2011 02:09 To: Roni Even; Gorzynski, Mark E (The Right One) Cc: clue@ietf.org Subject: Re: [clue] use case and requirement for multi-view Hi Roni, The intention of the use case was for multi-view, multiple cameras on the same scene. If the material is to be put in the document, I think it should be a separate use case, not a subset of others. In terms of including multi-view in the requirements, I'm fine to withdraw it and it can always be added later when someone wants it. If there is not a particular champion for multi-view who wants it now, then I think we can safely wait till later. Regards, Allyn From: Roni Even [mailto:Even.roni@huawei.com] Sent: Wednesday, June 22, 2011 5:59 AM To: Allyn Romanow (allyn) Cc: clue@ietf.org Subject: RE: use case for multi-view Hi Allyn, I sis not add it, I sent the following question to the list on May 17th and did not get any response yet "Hi Mark, I am trying to see how to fit this case in the use-cases draft. When I ignore the term "virtual space" and look at the description it talks about describing the view point of each cameras that may overlap and allowing the receivers to select the view they want. I see some resemblance to the education usage described. Will it make sense to mentio vide different view in the point to point symmetric or asymmetric case which has a case with a PTZ camera." Roni Even From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] Sent: Wednesday, June 22, 2011 6:51 AM To: Roni Even Cc: clue@ietf.org Hi Roni, I thought Mark's use case for multi-view was added to the Use Case doc, but I couldn't find it there? Is it just not added yet or is there some issue with it? Thanks much --Boundary_(ID_zCxAu1UXcdV5FIB1rpP0Ng) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I will add multi-view as = a separate use case to the use case draft

Roni

 

From:= = Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: = Thursday, June 23, 2011 10:08 AM
To: Allyn Romanow (allyn); = Roni Even; Gorzynski, Mark E (The Right One)
Cc: = clue@ietf.org
Subject: RE: [clue] use case and requirement for = multi-view

 

Could we use multi-view as test for the = extensibility of CLUE? The last CLUE requirement talks about = extensibility and building Multi-view systems on top of CLUE would be a = verification of CLUE extensibility. 

 

I think that multi-view = is too much to cover in the initial CLUE work.

 

Cheers

 

-Espen  =

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Allyn Romanow (allyn)
Sent: 23. juni 2011 = 02:09
To: Roni Even; Gorzynski, Mark E (The Right = One)
Cc: clue@ietf.org
Subject: Re: [clue] use case = and requirement for multi-view

 

Hi = Roni,

 

The intention of the use = case was for multi-view, multiple cameras on the same = scene.

If the material is to be put in the document, I = think it should be a separate use case, not a subset of = others.

 

In terms of including = multi-view in the requirements, I’m fine to withdraw it and it can = always be added later when someone wants it. If there is not a = particular champion for multi-view who wants it now, then I think we can = safely wait till later.

 

Regards,

Allyn

 

 

From:= = Roni Even [mailto:Even.roni@huawei.com]
Sent: Wednesday, June = 22, 2011 5:59 AM
To: Allyn Romanow (allyn)
Cc: = clue@ietf.org
Subject: RE: use case for = multi-view

 

Hi Allyn,

I sis not add it, I sent = the following question to the list on May 17th and did not get any = response yet

 

"Hi = Mark,

I am trying to see how to fit this case in the = use-cases draft. When I ignore the term "virtual space" and = look at the description it talks about describing the view point of each = cameras that may overlap and allowing the receivers to select the view = they want. I see some resemblance to the education usage described. =

Will it make sense to mentio vide different view = in the point to point symmetric or asymmetric case which has a case with = a PTZ camera."

 

 

Roni = Even

 

 

From:= = Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent: = Wednesday, June 22, 2011 6:51 AM
To: Roni Even
Cc: = clue@ietf.org

 

Hi = Roni,

I thought Mark’s = use case for multi-view was added to the Use Case doc, but I = couldn’t find it there? Is it just not added yet or is there some = issue with it?

 

Thanks = much

= --Boundary_(ID_zCxAu1UXcdV5FIB1rpP0Ng)-- From christer.holmberg@ericsson.com Thu Jun 23 02:39:26 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CD821F856B for ; Thu, 23 Jun 2011 02:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDaQDd2akpkW for ; Thu, 23 Jun 2011 02:39:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4220E21F856A for ; Thu, 23 Jun 2011 02:39:25 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-53-4e0309cb051d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A7.40.20773.BC9030E4; Thu, 23 Jun 2011 11:39:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 23 Jun 2011 11:39:23 +0200 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , "Allyn Romanow (allyn)" , Stephen Botzko Date: Thu, 23 Jun 2011 11:39:21 +0200 Thread-Topic: [clue] Layout negotiation Thread-Index: Acww8sQlRUBW5WOSS4K6jxoq1LlJrwABhLoAAAEsT+AABQroMAAAeBpQAAPQcLAAGYkXMA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A9D4@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A79A@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC65CC@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB559A7CE@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 09:39:27 -0000 Hi Charles,=20 >Here is the current definition of layout from=20 >http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt: >=20 > Layout: How rendered media streams are spatially arranged with > respect to each other on a single screen/mono audio=20 > telepresence endpoint, and how rendered media streams are arrange= d with > respect to each other on a multiple screen/speaker=20 > telepresence endpoint. Note that audio as well as video is encom= passed by > the term layout--in other words, included is the placement of > audio streams on speakers as well as video streams on video > screens. Edit. note: this is on the RENDERER side. >=20 > This definition is from the perspective of the physical=20 > speakers and displays on the endpoint. I am thinking more=20 > about how the available media streams are encoded and=20 > transmitted as some subset of the individual media streams,=20 > or as some composition of the individual media streams. Exactly, that is what I am thinking about also. The layout used by an MCU t= o genereate the output stream(s) towards an endpoint. I have called that "rendering algorithm", but I don't really care what we c= all it - as long as we all have a common understanding of what we mean :) >It is still up to the receiving endpoint to decide the layout of=20 >these media streams with respect to its physically speakers=20 >and displays.=20 Yes. Regards, Christer > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Wednesday, June 22, 2011 12:44 PM > > To: Allyn Romanow (allyn); Charles Eckel (eckelcu); Stephen Botzko > > Cc: clue@ietf.org > > Subject: RE: [clue] Layout negotiation > >=20 > >=20 > > Hi Allyn, > >=20 > > >Huh? > > >Perhaps one of you could summarize where we are in the=20 > conversation,=20 > > >and what is agreed upon so far? > >=20 > > I think we're having more or less a definition discussion. > >=20 > > >One thing to remind you of is that we have agreed that=20 > CLUE does not=20 > > >specify how rendering should be done, that is up to the=20 > receiver. The=20 > > >sender (and receiver) can send info, but CLUE isn't=20 > specifying what=20 > > >the receiver (renderer) does with it, meaning how it does the=20 > > >rendering, what choices it makes. I thought Charles'=20 > original email=20 > > >may have been suggesting specifying rendering, wasn't really sure. > >=20 > > I think what charles is talking is about being able to indicate: > >=20 > > 1. Which streams are used to create an output stream 2. How=20 > does the=20 > > output stream look like > >=20 > > It seems like people consider that being part of LAYOUT. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf=20 > > > Of Charles Eckel (eckelcu) > > > Sent: Wednesday, June 22, 2011 10:03 AM > > > To: Christer Holmberg; Stephen Botzko > > > Cc: clue@ietf.org > > > Subject: Re: [clue] Layout negotiation > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: Wednesday, June 22, 2011 9:46 AM > > > > To: Stephen Botzko > > > > Cc: Charles Eckel (eckelcu); clue@ietf.org > > > > Subject: RE: [clue] Layout negotiation > > > > > > > > > > > > Hi, > > > > > > > > >>>I think I was the one that brought up layouts=20 > originally. I was=20 > > > > >>>more concerned with video layouts than audio layouts. > > > > >>>Currently, the requirements draft seems to focus=20 > more on audio=20 > > > > >>>layout/spatial audio. > > > > >>>Requirements 3 and 16 both deal with parts of this. I feel=20 > > > > >>>there needs to be more clear requirements on the ability for=20 > > > > >>>the to represent the potential layouts of the=20 > audio/video can=20 > > > > >>>that be offered. For example, I have 3 camera and 3=20 > mics. I can provide: > > > > >>>1) 3 individual video each with corresponding audio > > > > >>>2) 1 active speaker only switched video with mixed audio > > > > >>>3) 1 composed video including active speaker and 'n' > > > > >>>non-active speakers (where 'n' is may be all or some fixed > > > > >>>limit) and mixed audio > > > > >> > > > > >> > > > > >>>>I actually think that your examples, as written,=20 > are different=20 > > > > >>>>RENDERING TYPES, because they only > > > > talk about mixing and composition. > > > > >> > > > > >>>Confirmation that I am clueless about rendering types. > > > > > > > > > > > > > > >>A value identifying the rendering algorithm used to > > > produce a media stream sent towards the client. > > > > > > > > >In a client-to-client call this is backwards. "Capture"=20 > > > > >describes the stream production process > > > > better, rendering is that the client does with the > > > > >streams it receives. Anyway, changing "Rendering type" to > > > "rendering algorithm" doesn't help me much. > > > > > > > > It's probably easier to understand rendering type if one > > > knows what we mean by render. > > > > > > > > Our proposed definition is: > > > > > > > > "Rendering:=A0=A0 Composing a media signal from one or more > > > media signals > > > > using a specific composition algorithm, often according to > > > a specific spatial model/layout." > > > > > > > > So, the "rendering type" is a value associated with=20 > that algorithm. > > > > > > > > So, I think the important thing in our "rendering" > > > definition is that > > > > an output media signal is generated. > > > > > > > > Now, if people think that our usage of "rendering" is=20 > confusing,=20 > > > > we can of course use other wording instead. > > > > > > This works for me. It may be useful to expand with=20 > typical audio and=20 > > > video examples, such as mixing multiple audio stream=20 > inputs into a=20 > > > single audio stream output, or composing multiple video stream=20 > > > inputs into a single video stream output. > > > > > > Cheers, > > > Charles > > > > > > > > > > > > > > > > > > > > > > >>>In my opinion, a LAYOUT TYPE is a description of how > > > sources are placed in a virtual room. > > > > >>> > > > > >>>For me layout is about composition. Layouts do not=20 > necessarily=20 > > > > >>>create a virtual room experience, > > > > particularly in multipoint calls. > > > > >> > > > > >> > > > > >>Ok, so we need to make sure we have a common > > > understanding of layout > > > > >>then :) > > > > >> > > > > >>So, just to clarify, do you think that source=20 > selection is layout? > > > > > > > > > > > > > > >I generally separate them, though they are related. For > > > instance, in > > > > >a traditional Video MCU you can > > > > often choose a source-independent layout (2x2 array > > > > >of equal size windows, a 1+5 layout, where the "1" window > > > is bigger > > > > >than the others, and at the top > > > > left, etc). Then you can control the mapping of > > > > >sources to windows separately. Not sure this is the=20 > only way to=20 > > > > >partition it, just the way I tend to > > > > use. > > > > > > > > Ok. So, first, I guess there is "source-dependent layout" > > > and "source-independent layout". > > > > > > > > Second, there is an algorithm that creates the output > > > stream, using the layout as input. > > > > > > > > Of course, in this case one might not need to be able to=20 > > > > explicitly indicate the algorithm - if it's enough to=20 > indicate the layout. > > > > > > > > > > > > > > > > > > > > >I see four distinct elements in your mobile binaural case > > > - (a) the > > > > >sources chosen for placement, > > > > > > > > Correct. That's "source selection". > > > > > > > > >(b) the set of placements used in creating a sound stage, > > > > > > > > > >(c) the placement used for each particular source at the > > > moment, and > > > > >(d) whether the outbound audio is binaural or not. > > > > >I'd personally call (b) the audio layout, though you can > > > equally well call (b+c) the audio layout. > > > > > > > > Ok. So, that would be a "source-dependent layout", I guess? > > > > > > > > Then, (d) would be the actual rendering algorithm, using > > > the layout as input. > > > > > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >If the receiving endpoint wants > > > to control the layout itself, > > > > >it goes with option 1.=20 > If it has limited > > > > >resources/bandwidth/screens/etc > > > it may prefer option 2 or 3. > > > > > > > > > > Cheers, > > > > > Charles > > > > > > > > > > > -----Original Message----- > > > > > > From: clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org] On Behalf > > > > > Of Christer Holmberg > > > > > > Sent: Tuesday, June=20 > 21, 2011 3:52 AM > > > > > > To: clue@ietf.org > > > > > > Subject: [clue]=20 > Layout negotiation > > > > > > > > > > > > Hi, > > > > > > > > > > > > A while ago there were some > > > discussions about having requirements to > > > > > negotiate the layout=20 > type, and at > > > > > > least according to Stephen B > > > it was within the scope of the work. > > > > > > > > > > > > "The ability to > > > negotiate an audio or video layout > > > > > is clearly > > > > > within scope, and has general > > > > > > value it the group wants to > > > take it on. > > > > > > For instance, if you > > > combine video switching of multiple > > > > > sources with audio > > > > > > mixing/transcoding, then the > > > receiver is responsible > > > > > > for the video layout > > > but has no control over the > > > > > audio layout. > > > > > In that case, there are > > > > > > advantages to allowing the > > > receiver to tell the > > > > > > central audio mixer > > > where it wants the sources placed on the > > > > > sound stage. I have=20 > no objection > > > > > > in principle to=20 > adding that kind of > > > > > > negotiation to the > > > requirements, though I think the group > > > > > should consider the=20 > impact on the > > > > > > schedule." > > > > > > > > > > > > However, I haven't seen any > > > input after that. > > > > > > > > > > > > My idea would be that it is > > > very similar to the rendering type: CLUE > > > > > defines a mechanism to=20 > negotiate > > > > > > the layout type, but doesn't > > > define specific types (instead an IANA > > > > > registry would be created for > > > > > > that). So, I don't think it > > > would have any significant impact on our > > > > > schedule. > > > > > > > > > > > > Whether it, in addition to > > > negotiation a layout type (which > > > > > specifies > > > > > the source locations),=20 > should be > > > > > > possible for the user to > > > more explicit place individual sources, as > > > > > mentioned by Stephen, can be > > > > > > discussed. However, that > > > would probably require a little > > > > > more work, so > > > > > at least I would be happy with > > > > > > a simple layout type > > > negotiation at this point. > > > > > > > > > > > > So, would people be ok with > > > such requirement? > > > > > > > > > > > > (Another alternative would > > > be to "embed" the layout type into the > > > > > rendering type, but I=20 > think that > > > > > > would be very clumsy. > > > Because, in that case you would need to define > > > > > mulitple types for the same > > > > > > rendering, but with > > > different layouts.) > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > = From christer.holmberg@ericsson.com Thu Jun 23 02:41:21 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F171F0C4B for ; Thu, 23 Jun 2011 02:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6jvG3KQUsrl for ; Thu, 23 Jun 2011 02:41:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 42CBD1F0C38 for ; Thu, 23 Jun 2011 02:41:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-14-4e030a3eb754 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 53.33.09774.E3A030E4; Thu, 23 Jun 2011 11:41:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 23 Jun 2011 11:41:18 +0200 From: Christer Holmberg To: "Allyn Romanow (allyn)" , "Charles Eckel (eckelcu)" , Stephen Botzko Date: Thu, 23 Jun 2011 11:41:17 +0200 Thread-Topic: [clue] Layout negotiation Thread-Index: Acww8sQlRUBW5WOSS4K6jxoq1LlJrwABhLoAAAEsT+AABQroMAAAeBpQAAPQcLAADh66IAALidwA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB559A9DA@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336D16@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB533732C@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A741@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05851DB559A79A@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC65CC@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851DB559A7CE@ESESSCMS0356.eemea.ericsson.se> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC67D8@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC67D8@xmb-sjc-221.amer.cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Layout negotiation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 09:41:21 -0000 Hi Allyn, >What does your note have to do with the requirements? >It seems to me you're out there designing a solution. Could >you save it for the design discussion? >Or, perhaps you could state succinctly what statement you >want added, subtracted, or modified in the requirements? In my opinion, Charles is not designing a solution. One problem we have had in the requirements discussions is that we seem to = have different understandings of terminology, and I think layout is one suc= h example. Regards, Christer > > -----Original Message----- > > From: Charles Eckel (eckelcu) > > Sent: Wednesday, June 22, 2011 2:32 PM > > To: Christer Holmberg; Allyn Romanow (allyn); Stephen Botzko > > Cc: clue@ietf.org > > Subject: RE: [clue] Layout negotiation > > > > Here is the current definition of layout from > > http://www.ietf.org/id/draft-wenger-clue-definitions-00.txt: > > > > Layout: How rendered media streams are spatially > arranged with > > respect to each other on a single screen/mono audio > > telepresence > > endpoint, and how rendered media streams are arranged with > > respect to each other on a multiple screen/speaker > telepresence > > endpoint. Note that audio as well as video is > encompassed by > > the term layout--in other words, included is the > placement of > > audio streams on speakers as well as video streams on video > > screens. Edit. note: this is on the RENDERER side. > > > > This definition is from the perspective of the physical > speakers and > > displays on the endpoint. I am thinking more about how the > available > > media streams are encoded and transmitted as some subset of the > > individual media streams, or as some composition of the individual > > media streams. It is still up to the receiving endpoint to > decide the > > layout of these media streams with respect to its > physically speakers > > and displays. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Wednesday, June 22, 2011 12:44 PM > > > To: Allyn Romanow (allyn); Charles Eckel (eckelcu); Stephen Botzko > > > Cc: clue@ietf.org > > > Subject: RE: [clue] Layout negotiation > > > > > > > > > Hi Allyn, > > > > > > >Huh? > > > >Perhaps one of you could summarize where we are in the > > > >conversation, and what is agreed upon so far? > > > > > > I think we're having more or less a definition discussion. > > > > > > >One thing to remind you of is that we have agreed that CLUE does > > > >not specify how rendering should be done, that is up to the > > > >receiver. The sender (and receiver) can send info, but > CLUE isn't > > > >specifying what the receiver (renderer) does with it, > meaning how > > > >it does the rendering, what choices it makes. I thought > Charles' > > > >original email may have been suggesting specifying rendering, > > > >wasn't really sure. > > > > > > I think what charles is talking is about being able to indicate: > > > > > > 1. Which streams are used to create an output stream 2. > How does the > > > output stream look like > > > > > > It seems like people consider that being part of LAYOUT. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > > Behalf Of Charles Eckel (eckelcu) > > > > Sent: Wednesday, June 22, 2011 10:03 AM > > > > To: Christer Holmberg; Stephen Botzko > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] Layout negotiation > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: Wednesday, June 22, 2011 9:46 AM > > > > > To: Stephen Botzko > > > > > Cc: Charles Eckel (eckelcu); clue@ietf.org > > > > > Subject: RE: [clue] Layout negotiation > > > > > > > > > > > > > > > Hi, > > > > > > > > > > >>>I think I was the one that brought up layouts originally. I > > was > > > > > >>>more concerned with video layouts than audio layouts. > > > > > >>>Currently, the requirements draft seems to focus more on > > > > > >>>audio layout/spatial audio. > > > > > >>>Requirements 3 and 16 both deal with parts of this. I feel > > there > > > > > >>>needs to be more clear requirements on the ability > for the to > > > > > >>>represent the potential layouts of the audio/video > can that > > > > > >>>be offered. For example, I have 3 camera and 3 mics. I can > > provide: > > > > > >>>1) 3 individual video each with corresponding audio > > > > > >>>2) 1 active speaker only switched video with mixed audio > > > > > >>>3) 1 composed video including active speaker and 'n' > > > > > >>>non-active speakers (where 'n' is may be all or some fixed > > > > > >>>limit) and mixed audio > > > > > >> > > > > > >> > > > > > >>>>I actually think that your examples, as written, are > > different > > > > > >>>>RENDERING TYPES, because they only > > > > > talk about mixing and composition. > > > > > >> > > > > > >>>Confirmation that I am clueless about rendering types. > > > > > > > > > > > > > > > > > >>A value identifying the rendering algorithm used to > > > > produce a media stream sent towards the client. > > > > > > > > > > >In a client-to-client call this is backwards. "Capture" > > describes > > > > > >the stream production process > > > > > better, rendering is that the client does with the > > > > > >streams it receives. Anyway, changing "Rendering type" to > > > > "rendering algorithm" doesn't help me much. > > > > > > > > > > It's probably easier to understand rendering type if one > > > > knows what we mean by render. > > > > > > > > > > Our proposed definition is: > > > > > > > > > > "Rendering: Composing a media signal from one or more > > > > media signals > > > > > using a specific composition algorithm, often according to > > > > a specific spatial model/layout." > > > > > > > > > > So, the "rendering type" is a value associated with that > > algorithm. > > > > > > > > > > So, I think the important thing in our "rendering" > > > > definition is that > > > > > an output media signal is generated. > > > > > > > > > > Now, if people think that our usage of "rendering" is > confusing, > > we > > > > > can of course use other wording instead. > > > > > > > > This works for me. It may be useful to expand with > typical audio > > > > and video examples, such as mixing multiple audio stream inputs > > > > into a single audio stream output, or composing multiple video > > > > stream inputs into a single video stream output. > > > > > > > > Cheers, > > > > Charles > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>>In my opinion, a LAYOUT TYPE is a description of how > > > > sources are placed in a virtual room. > > > > > >>> > > > > > >>>For me layout is about composition. Layouts do not > > > > > >>>necessarily create a virtual room experience, > > > > > particularly in multipoint calls. > > > > > >> > > > > > >> > > > > > >>Ok, so we need to make sure we have a common > > > > understanding of layout > > > > > >>then :) > > > > > >> > > > > > >>So, just to clarify, do you think that source selection is > > layout? > > > > > > > > > > > > > > > > > >I generally separate them, though they are related. For > > > > instance, in > > > > > >a traditional Video MCU you can > > > > > often choose a source-independent layout (2x2 array > > > > > >of equal size windows, a 1+5 layout, where the "1" window > > > > is bigger > > > > > >than the others, and at the top > > > > > left, etc). Then you can control the mapping of > > > > > >sources to windows separately. Not sure this is the > only way > > > > > >to partition it, just the way I tend to > > > > > use. > > > > > > > > > > Ok. So, first, I guess there is "source-dependent layout" > > > > and "source-independent layout". > > > > > > > > > > Second, there is an algorithm that creates the output > > > > stream, using the layout as input. > > > > > > > > > > Of course, in this case one might not need to be able to > > explicitly > > > > > indicate the algorithm - if it's enough to indicate > the layout. > > > > > > > > > > > > > > > > > > > > > > > > > >I see four distinct elements in your mobile binaural case > > > > - (a) the > > > > > >sources chosen for placement, > > > > > > > > > > Correct. That's "source selection". > > > > > > > > > > >(b) the set of placements used in creating a sound stage, > > > > > > > > > > > >(c) the placement used for each particular source at the > > > > moment, and > > > > > >(d) whether the outbound audio is binaural or not. > > > > > >I'd personally call (b) the audio layout, though you can > > > > equally well call (b+c) the audio layout. > > > > > > > > > > Ok. So, that would be a "source-dependent layout", I guess? > > > > > > > > > > Then, (d) would be the actual rendering algorithm, using > > > > the layout as input. > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >If the receiving endpoint wants > > > > to control the layout itself, > > > > > >it goes with option 1. If it has > > limited > > > > > >resources/bandwidth/screens/etc > > > > it may prefer option 2 or 3. > > > > > > > > > > > > Cheers, > > > > > > Charles > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: clue-bounces@ietf.org > > > > [mailto:clue-bounces@ietf.org] On Behalf > > > > > > Of Christer Holmberg > > > > > > > Sent: Tuesday, June > 21, 2011 3:52 > > AM > > > > > > > To: clue@ietf.org > > > > > > > Subject: [clue] > Layout negotiation > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > A while ago there were some > > > > discussions about having requirements to > > > > > > negotiate the layout > type, and at > > > > > > > least according to Stephen B > > > > it was within the scope of the work. > > > > > > > > > > > > > > "The ability to > > > > negotiate an audio or video layout > > > > > > is clearly > > > > > > within scope, and has general > > > > > > > value it the group wants to > > > > take it on. > > > > > > > For instance, if you > > > > combine video switching of multiple > > > > > > sources with audio > > > > > > > mixing/transcoding, then the > > > > receiver is responsible > > > > > > > for the video layout > > > > but has no control over the > > > > > > audio layout. > > > > > > In that case, there are > > > > > > > advantages to allowing the > > > > receiver to tell the > > > > > > > central audio mixer > > > > where it wants the sources placed on the > > > > > > sound stage. I have > no objection > > > > > > > in principle to > adding that kind > > of > > > > > > > negotiation to the > > > > requirements, though I think the group > > > > > > should consider the > impact on the > > > > > > > schedule." > > > > > > > > > > > > > > However, I haven't seen any > > > > input after that. > > > > > > > > > > > > > > My idea would be that it is > > > > very similar to the rendering type: CLUE > > > > > > defines a mechanism to > negotiate > > > > > > > the layout type, but doesn't > > > > define specific types (instead an IANA > > > > > > registry would be created for > > > > > > > that). So, I don't think it > > > > would have any significant impact on our > > > > > > schedule. > > > > > > > > > > > > > > Whether it, in addition to > > > > negotiation a layout type (which > > > > > > specifies > > > > > > the source locations), > should be > > > > > > > possible for the user to > > > > more explicit place individual sources, as > > > > > > mentioned by Stephen, can be > > > > > > > discussed. However, that > > > > would probably require a little > > > > > > more work, so > > > > > > at least I would be happy with > > > > > > > a simple layout type > > > > negotiation at this point. > > > > > > > > > > > > > > So, would people be ok with > > > > such requirement? > > > > > > > > > > > > > > (Another alternative would > > > > be to "embed" the layout type into the > > > > > > rendering type, but I > think that > > > > > > > would be very clumsy. > > > > Because, in that case you would need to define > > > > > > mulitple types for the same > > > > > > > rendering, but with > > > > different layouts.) > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > clue mailing list > > > > > clue@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > From Mark.Duckworth@polycom.com Thu Jun 23 08:00:15 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9BA11E811A for ; Thu, 23 Jun 2011 08:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDBWc5Cz--tr for ; Thu, 23 Jun 2011 08:00:13 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id ECBFC11E8142 for ; Thu, 23 Jun 2011 08:00:11 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::1c3e:2e7c:4b4f:14fd%10]) with mapi; Thu, 23 Jun 2011 08:00:09 -0700 From: "Duckworth, Mark" To: Roni Even , "'Espen Berger (espeberg)'" , "'Allyn Romanow (allyn)'" , "'Gorzynski, Mark E (The Right One)'" Date: Thu, 23 Jun 2011 08:00:09 -0700 Thread-Topic: [clue] use case and requirement for multi-view Thread-Index: Acwwj6m4l9xOCH4NSAO5KaTj+QfrLwATEhGgABdIWFAADqhtEAAD5ssAAAyuUzA= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AC68C97D@CRPMBOXPRD01.polycom.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6357@xmb-sjc-221.amer.cisco.com> <00fd01cc30dc$2496e930$6dc4bb90$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6770@xmb-sjc-221.amer.cisco.com> <92DF9533227FC14F946C7321074B8C9E71BAC0@XMB-AMS-214.cisco.com> <003e01cc3183$c1205460$4360fd20$%roni@huawei.com> In-Reply-To: <003e01cc3183$c1205460$4360fd20$%roni@huawei.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_44C6B6B2D0CF424AA90B6055548D7A61AC68C97DCRPMBOXPRD01pol_" MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] use case and requirement for multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 15:00:15 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A61AC68C97DCRPMBOXPRD01pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Allyn and Espen that it would be good to leave out the multi-v= iew use case and leave it out of the requirements. Mark Duckworth From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Thursday, June 23, 2011 4:59 AM To: 'Espen Berger (espeberg)'; 'Allyn Romanow (allyn)'; 'Gorzynski, Mark E = (The Right One)' Cc: clue@ietf.org Subject: Re: [clue] use case and requirement for multi-view Hi, I will add multi-view as a separate use case to the use case draft Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, June 23, 2011 10:08 AM To: Allyn Romanow (allyn); Roni Even; Gorzynski, Mark E (The Right One) Cc: clue@ietf.org Subject: RE: [clue] use case and requirement for multi-view Could we use multi-view as test for the extensibility of CLUE? The last CLU= E requirement talks about extensibility and building Multi-view systems on = top of CLUE would be a verification of CLUE extensibility. I think that multi-view is too much to cover in the initial CLUE work. Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of All= yn Romanow (allyn) Sent: 23. juni 2011 02:09 To: Roni Even; Gorzynski, Mark E (The Right One) Cc: clue@ietf.org Subject: Re: [clue] use case and requirement for multi-view Hi Roni, The intention of the use case was for multi-view, multiple cameras on the s= ame scene. If the material is to be put in the document, I think it should be a separa= te use case, not a subset of others. In terms of including multi-view in the requirements, I'm fine to withdraw = it and it can always be added later when someone wants it. If there is not = a particular champion for multi-view who wants it now, then I think we can = safely wait till later. Regards, Allyn From: Roni Even [mailto:Even.roni@huawei.com] Sent: Wednesday, June 22, 2011 5:59 AM To: Allyn Romanow (allyn) Cc: clue@ietf.org Subject: RE: use case for multi-view Hi Allyn, I sis not add it, I sent the following question to the list on May 17th and= did not get any response yet "Hi Mark, I am trying to see how to fit this case in the use-cases draft. When I igno= re the term "virtual space" and look at the description it talks about desc= ribing the view point of each cameras that may overlap and allowing the rec= eivers to select the view they want. I see some resemblance to the educatio= n usage described. Will it make sense to mentio vide different view in the point to point symm= etric or asymmetric case which has a case with a PTZ camera." Roni Even From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] Sent: Wednesday, June 22, 2011 6:51 AM To: Roni Even Cc: clue@ietf.org Hi Roni, I thought Mark's use case for multi-view was added to the Use Case doc, but= I couldn't find it there? Is it just not added yet or is there some issue = with it? Thanks much --_000_44C6B6B2D0CF424AA90B6055548D7A61AC68C97DCRPMBOXPRD01pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable = --_000_44C6B6B2D0CF424AA90B6055548D7A61AC68C97DCRPMBOXPRD01pol_-- From ye.xiaoyang@zte.com.cn Thu Jun 23 10:02:55 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E74911E8132; Thu, 23 Jun 2011 10:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.993 X-Spam-Level: X-Spam-Status: No, score=-96.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNsp7oCHnKs0; Thu, 23 Jun 2011 10:02:54 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id F394E11E8160; Thu, 23 Jun 2011 10:02:53 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 131321682403064; Fri, 24 Jun 2011 01:00:33 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 77532.4916487007; Fri, 24 Jun 2011 01:02:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p5NH2bmS062623; Fri, 24 Jun 2011 01:02:37 +0800 (GMT-8) (envelope-from ye.xiaoyang@zte.com.cn) In-Reply-To: <4D1AA2A55522044480C9B9CF97A9340901BD10FC@ftrdmel0.rd.francetelecom.fr> To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: ye.xiaoyang@zte.com.cn Date: Fri, 24 Jun 2011 01:02:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-24 01:02:39, Serialize complete at 2011-06-24 01:02:39 Content-Type: multipart/alternative; boundary="=_alternative 005D884E482578B8_=" X-MAIL: mse01.zte.com.cn p5NH2bmS062623 Cc: clue-bounces@ietf.org, clue@ietf.org Subject: [clue] =?gb2312?b?tPC4tDogUmU6ICBjbGFyaWZpY2F0aW9uIG9uIHJlcXVp?= =?gb2312?b?cmVtZW50cyBkcmFmdCAwMw==?= X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 17:02:55 -0000 This is a multipart message in MIME format. --=_alternative 005D884E482578B8_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 UkVRTVQtMmI6IA0KU3TDqXBoYW5lJ3Mgc3VnZ2VzdGlvbiBzZWVtcyBiZXR0ZXIuDQoNClJFUU1U LTFkOiBUaGUgc29sdXRpb24gTVVTVCBzdXBwb3J0IG11bHRpLXZpZXcgYXMgZGVzY3JpYmVkIGlu IHRoZSB1c2UgDQpjYXNlcy4NCkFncmVlIHRvIHJlbW92ZSB0aGlzIGl0ZW0gaW4gcHJlc2VudCBy ZXF1aXJlbWVudHMsIGF0IGxlYXN0IHVzZSAiU0hPVUxEIiANCnJhdGhlciB0aGFuICJNVVNUIi4N Cg0KUkVRTVQtNTogVGhlIHNvbHV0aW9uIE1VU1Qgc3VwcG9ydCBpbnRlcm9wZXJhYmlsaXR5IGJl dHdlZW4gZW5kcG9pbnRzIA0Kd2hlcmUgdGhlIG51bWJlciBvZiBjYW1lcmFzIGFuZC9vciBkaXNw bGF5cyBhcmUgemVyby4NCkFncmVlIHRvIHJld29yZCAiZW5kcG9pbnRzIHdoZXJlIHRoZSBudW1i ZXIgb2YgY2FtZXJhcyBhbmQvb3IgZGlzcGxheXMgYXJlIA0KemVybyIsIA0Kd2hhdCBhYm91dCAi ZW5kcG9pbnRzIHdoaWNoIGRvbid0IHNlbmQgYW5kL29yIHJlY2VpdmUgdmlkZW8gc3RyZWFtIi4g DQpCZWNhdXNlIHNvbWV0aW1lcyB0aGUgZW5kIHVzZXIganVzdCBkb2VzJ3Qgc2VuZCBhbmQvb3Ig cmVjZWl2ZSB2aWRlbyANCnN0cmVhbSB0aG91Z2ggdGhlcmUgYXJlIGNhbWVyYXMgYW5kL29yIGRp c3BsYXlzIGRldmljZXMuDQoNCkJlc3QgcmVnYXJkcywNCg0KWGlhb3lhbmcNCg0KDQoNCg0KPHN0 ZXBoYW5lLnByb3VzdEBvcmFuZ2UtZnRncm91cC5jb20+IA0K5Y+R5Lu25Lq6OiAgY2x1ZS1ib3Vu Y2VzQGlldGYub3JnDQoyMDExLTA2LTIzIOS4i+WNiCAwNDoxMA0KDQrmlLbku7bkuroNCjxzdGVw aGVuLmJvdHprb0BnbWFpbC5jb20+DQrmioTpgIENCmNsdWVAaWV0Zi5vcmcNCuS4u+mimA0KUmU6 IFtjbHVlXSBjbGFyaWZpY2F0aW9uIG9uIHJlcXVpcmVtZW50cyBkcmFmdCAwMw0KDQoNCg0KDQoN Cg0KSGksIA0KIA0KU2luY2Ugd2UgYXJlIGRlYWxpbmcgd2l0aCAicmVxdWlyZW1lbnRzIiBhbmQg ZGVwZW5kaW5nIG9uIGhvdyB5b3UgcmVhZCBhbmQgDQp1bmRlcnN0YW5kIHRoZSBoaWVyYXJjaHkg b2YgcmVxdWlyZW1lbnRzICgyYiB3aXRoIHJlc3BlY3QgdG8gMiksIHRoaXMgDQpjb3VsZCBtZWFu IHRoYXQgdGhlIHNvbHV0aW9uIE1BWSBOT1Qgc3VwcG9ydCBhbnkgbWVhbiB0byBpZGVudGlmeSBt b3JlIA0KdGhhbiB0aGUgZm9sbG93aW5nIDMgY2FzZXMgOiBtb25hdXJhbCwgc3RlcmVvcGhvbmlj IGFuZCAzLjAgTC9DL1IuIA0KIA0KSWYgdGhlIGludGVudGlvbiBpcyBub3QgdG8gbGltaXQgdG8g dGhvc2UgMyBjYXNlcyAoYWx0aG91Z2ggdGhlIG1vcmUgDQppbXBvcnRhbnQgb25lcyB3aXRoIHJl c3BlY3QgdG8gZXhpc3Rpbmcgc29sdXRpb25zKSB3aGljaCBpcyBuZWVkZWQgdG8gDQpkZXNpZ24g YSBmdXR1cmUgcHJvb2Ygc29sdXRpb24gSSB3b3VsZCBzdWdnZXN0IHRvIG1ha2UgaXQgbW9yZSBl eHBsaWNpdCBieSANCnVzaW5nIHNvbWUgd29yZGluZyBsaWtlIDoNCiANClRoZSBzb2x1dGlvbiBN VVNUIHN1cHBvcnQgYSBtZWFucyB0byBpZGVudGlmeSB0aGUgbnVtYmVyIGFuZCBzcGF0aWFsIA0K YXJyYW5nZW1lbnQgb2YgYXVkaW8gY2hhbm5lbHMgaW5jbHVkaW5nIA0KICAgICAgICAgICAgICAg ICAgICAgICAgbW9uYXVyYWwsIHN0ZXJlb3Bob25pYyAoMi4wKSwgYW5kIDMuMCAobGVmdCwNCiAg ICAgICAgICAgICAgICAgICAgICAgIGNlbnRlciwgcmlnaHQpIGF1ZGlvIGNoYW5uZWxzLg0KIA0K UmVnYXJkcw0KIA0KU3TDqXBoYW5lDQoNCkRlIDogU3RlcGhlbiBCb3R6a28gW21haWx0bzpzdGVw aGVuLmJvdHprb0BnbWFpbC5jb21dIA0KRW52b3nDqSA6IG1lcmNyZWRpIDIyIGp1aW4gMjAxMSAx NjozNA0Kw4AgOiBQUk9VU1QgU3RlcGhhbmUgUkQtVEVDSC1MQU4NCkNjIDogY2x1ZUBpZXRmLm9y Zw0KT2JqZXQgOiBSZTogW2NsdWVdIGNsYXJpZmljYXRpb24gb24gcmVxdWlyZW1lbnRzIGRyYWZ0 IDAzDQoNClRoZSByZXF1aXJlbWVudCBpcyBub3QgaW50ZW5kZWQgdG8gcHJlY2x1ZGUgYSBoaWdo ZXIgbnVtYmVyIG9mIGNoYW5uZWxzLCANCml0IGlzIGludGVuZGVkIHRvIHNheSB0aGF0IHRoZSBz b2x1dGlvbiBoYXMgdG8gYXQgbGVhc3QgaW5jbHVkZSB0aG9zZSANCnRocmVlIG1vZGVzLiANCg0K VGhlIHJhdGlvbmFsZSBpcyB0aGF0IHRob3NlIGFyZSB0aGUgbW9kZXMgaW4gdXNlIHRvZGF5IGJ5 IHRlbGVwcmVzZW5jZSANCnN5c3RlbXMuDQoNClJlZ2FyZHMsDQpTdGVwaGVuIEJvdHprbw0KDQpP biBXZWQsIEp1biAyMiwgMjAxMSBhdCA5OjEzIEFNLCA8c3RlcGhhbmUucHJvdXN0QG9yYW5nZS1m dGdyb3VwLmNvbT4gDQp3cm90ZToNCkhpDQoNCkkgJ3ZlIG1heWJlIG1pc3NlZCBzb21lIGRpc2N1 c3Npb25zIHJlbGF0ZWQgdG8gc29tZSBvZiB0aGUgbW9kaWZpY2F0aW9ucyANCmJyb3VnaHQgaW4g ZHJhZnQgMDMgd2l0aCByZXNwZWN0IHRvIGRyYWZ0IDAyIGJ1dCBJIHdvdWxkIGFwcHJlY2lhdGUg c29tZSANCmNsYXJpZmljYXRpb24vZXhwbGFuYXRpb24gYWJvdXQgdGhlIGxpbWl0YXRpb24gdG8g MyBhdWRpbyBjaGFubmVscyANCmludHJvZHVjZWQgaW4gUkVRTVQtMmIgOg0KDQpSRVFNVC0yYjog IFRoZSBzb2x1dGlvbiBNVVNUIHN1cHBvcnQgYSBtZWFucyB0byBpZGVudGlmeQ0KICAgICAgICAg ICAgICAgICAgICAgICAgbW9uYXVyYWwsIHN0ZXJlb3Bob25pYyAoMi4wKSwgYW5kIDMuMCAobGVm dCwNCiAgICAgICAgICAgICAgICAgICAgICAgIGNlbnRlciwgcmlnaHQpIGF1ZGlvIGNoYW5uZWxz Lg0KDQpJcyBpdCB0aGUgaW50ZW50IHRvIGV4Y2x1ZGUgdGhlIG11bHRpcGxleGluZyBvZiBhIGhp Z2hlciBudW1iZXIgb2YgDQpjaGFubmVscyA/DQpJZiB0aGUgaW50ZW50IGlzIHRvIGludHJvZHVj ZSBzb21lIGxpbWl0YXRpb24sIHdoYXQgaXMgdGhlIHJhdGlvbmFsZSANCmJlaGluZCBhbmQgd2h5 IHN1Y2ggbGltaXQgaXMgc2V0IHRvIDMuMCAgPw0KDQpUaGFua3MNCg0KU3TDqXBoYW5lDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjbHVlIG1haWxp bmcgbGlzdA0KY2x1ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jbHVlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KY2x1ZSBtYWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KDQoNCg== --=_alternative 005D884E482578B8_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJFUU1ULTJiOiA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVmVyZGFuYSI+U3TDqXBoYW5lPC9mb250Pjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNhbGlicmkiPidzDQpzdWdnZXN0aW9uIHNlZW1z IGJldHRlci48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJF UU1ULTFkOiBUaGUgc29sdXRpb24gTVVTVCBzdXBwb3J0IG11bHRpLXZpZXcNCmFzIGRlc2NyaWJl ZCBpbiB0aGUgdXNlIGNhc2VzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPSJDYWxpYnJpIj5BZ3JlZSB0byByZW1vdmUgdGhpcyBpdGVtIGluDQpwcmVzZW50IHJlcXVp cmVtZW50cywgYXQgbGVhc3QgdXNlICZxdW90O1NIT1VMRCZxdW90OyByYXRoZXIgdGhhbiAmcXVv dDtNVVNUJnF1b3Q7LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+UkVRTVQtNTogVGhlIHNvbHV0aW9uIE1VU1Qgc3VwcG9ydCBpbnRlcm9wZXJhYmlsaXR5DQpi ZXR3ZWVuIGVuZHBvaW50cyB3aGVyZSB0aGUgbnVtYmVyIG9mIGNhbWVyYXMgYW5kL29yIGRpc3Bs YXlzIGFyZSB6ZXJvLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJD YWxpYnJpIj5BZ3JlZSB0byByZXdvcmQgJnF1b3Q7ZW5kcG9pbnRzDQp3aGVyZSB0aGUgbnVtYmVy IG9mIGNhbWVyYXMgYW5kL29yIGRpc3BsYXlzIGFyZSB6ZXJvJnF1b3Q7LCA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ2FsaWJyaSI+d2hhdCBhYm91dCAmcXVvdDtl bmRwb2ludHMgd2hpY2gNCmRvbid0IHNlbmQgYW5kL29yIHJlY2VpdmUgdmlkZW8gc3RyZWFtJnF1 b3Q7LiBCZWNhdXNlIHNvbWV0aW1lcyB0aGUgZW5kDQp1c2VyIGp1c3QgZG9lcyd0IHNlbmQgYW5k L29yIHJlY2VpdmUgdmlkZW8gc3RyZWFtIHRob3VnaCB0aGVyZSBhcmUgY2FtZXJhcw0KYW5kL29y IGRpc3BsYXlzIGRldmljZXMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij48YnI+DQpCZXN0IHJlZ2FyZHMsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDYWxpYnJpIj5YaWFveWFuZzwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mbHQ7c3RlcGhhbmUucHJvdXN0QG9yYW5nZS1mdGdyb3Vw LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PuWPkeS7tuS6ujogJm5ic3A7Y2x1ZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDYtMjMg5LiL5Y2IIDA0OjEwPC9mb250Pg0K PHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7mlLbku7bk uro8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtz dGVwaGVuLmJvdHprb0BnbWFpbC5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7mioTpgIE8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNsdWVAaWV0 Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuS4u+mimDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtjbHVlXSBjbGFyaWZpY2F0aW9uIG9uIHJl cXVpcmVtZW50cw0KZHJhZnQgMDM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJWZXJkYW5hIj5IaSwgPC9mb250Pg0K PGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWUgZmFjZT0iVmVyZGFuYSI+U2luY2Ugd2UgYXJlIGRlYWxpbmcgd2l0aCAmcXVvdDtyZXF1aXJl bWVudHMmcXVvdDsNCmFuZCBkZXBlbmRpbmcgb24gaG93IHlvdSByZWFkIGFuZCB1bmRlcnN0YW5k IHRoZSBoaWVyYXJjaHkgb2YgcmVxdWlyZW1lbnRzDQooMmIgd2l0aCByZXNwZWN0IHRvIDIpLCB0 aGlzIGNvdWxkIG1lYW4gdGhhdCB0aGUgc29sdXRpb24gTUFZIE5PVCBzdXBwb3J0DQphbnkgbWVh biB0byBpZGVudGlmeSBtb3JlIHRoYW4gdGhlIGZvbGxvd2luZyAzIGNhc2VzIDogbW9uYXVyYWws IHN0ZXJlb3Bob25pYw0KYW5kIDMuMCBML0MvUi4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVmVyZGFuYSI+ SWYgdGhlIGludGVudGlvbiBpcyBub3QgdG8gbGltaXQNCnRvIHRob3NlIDMgY2FzZXMgKGFsdGhv dWdoIHRoZSBtb3JlIGltcG9ydGFudCBvbmVzIHdpdGggcmVzcGVjdCB0byBleGlzdGluZw0Kc29s dXRpb25zKSB3aGljaCBpcyBuZWVkZWQgdG8gZGVzaWduIGEgZnV0dXJlIHByb29mIHNvbHV0aW9u IEkgd291bGQgc3VnZ2VzdA0KdG8gbWFrZSBpdCBtb3JlIGV4cGxpY2l0IGJ5IHVzaW5nIHNvbWUg d29yZGluZyBsaWtlIDo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTM+VGhlIHNvbHV0aW9uIE1VU1Qgc3VwcG9ydCBhIG1lYW5zIHRvIGlkZW50 aWZ5IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9cmVkPnRoZQ0KbnVtYmVyIGFuZCBzcGF0aWFs IGFycmFuZ2VtZW50IG9mIGF1ZGlvIGNoYW5uZWxzIGluY2x1ZGluZyA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDttb25hdXJhbCwgc3RlcmVvcGhv bmljICgyLjApLCBhbmQgMy4wIChsZWZ0LDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDtjZW50ZXIsIHJpZ2h0KSBhdWRpbyBjaGFubmVscy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJWZXJkYW5h Ij5SZWdhcmRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVmVyZGFuYSI+U3TDqXBoYW5lPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGhyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkRlIDo8L2I+IFN0ZXBo ZW4gQm90emtvIFttYWlsdG86c3RlcGhlbi5ib3R6a29AZ21haWwuY29tXQ0KPGI+PGJyPg0KRW52 b3nDqSA6PC9iPiBtZXJjcmVkaSAyMiBqdWluIDIwMTEgMTY6MzQ8Yj48YnI+DQrDgCA6PC9iPiBQ Uk9VU1QgU3RlcGhhbmUgUkQtVEVDSC1MQU48Yj48YnI+DQpDYyA6PC9iPiBjbHVlQGlldGYub3Jn PGI+PGJyPg0KT2JqZXQgOjwvYj4gUmU6IFtjbHVlXSBjbGFyaWZpY2F0aW9uIG9uIHJlcXVpcmVt ZW50cyBkcmFmdCAwMzwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mz5UaGUgcmVxdWlyZW1lbnQgaXMgbm90IGludGVuZGVkIHRvIHByZWNsdWRlIGEgaGln aGVyIG51bWJlcg0Kb2YgY2hhbm5lbHMsIGl0IGlzIGludGVuZGVkIHRvIHNheSB0aGF0IHRoZSBz b2x1dGlvbiBoYXMgdG8gYXQgbGVhc3QgaW5jbHVkZQ0KdGhvc2UgdGhyZWUgbW9kZXMuICZuYnNw Ozxicj4NCjxicj4NClRoZSByYXRpb25hbGUgaXMgdGhhdCB0aG9zZSBhcmUgdGhlIG1vZGVzIGlu IHVzZSB0b2RheSBieSB0ZWxlcHJlc2VuY2UNCnN5c3RlbXMuPGJyPg0KPGJyPg0KUmVnYXJkcyw8 YnI+DQpTdGVwaGVuIEJvdHprbzxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+T24gV2Vk LCBKdW4gMjIsIDIwMTEgYXQgOToxMyBBTSwgJmx0OzwvZm9udD48YSBocmVmPSJtYWlsdG86c3Rl cGhhbmUucHJvdXN0QG9yYW5nZS1mdGdyb3VwLmNvbSI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+ PHU+c3RlcGhhbmUucHJvdXN0QG9yYW5nZS1mdGdyb3VwLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9Mz4mZ3Q7DQp3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPkhpPGJyPg0KPGJy Pg0KSSAndmUgbWF5YmUgbWlzc2VkIHNvbWUgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byBzb21lIG9m IHRoZSBtb2RpZmljYXRpb25zDQpicm91Z2h0IGluIGRyYWZ0IDAzIHdpdGggcmVzcGVjdCB0byBk cmFmdCAwMiBidXQgSSB3b3VsZCBhcHByZWNpYXRlIHNvbWUNCmNsYXJpZmljYXRpb24vZXhwbGFu YXRpb24gYWJvdXQgdGhlIGxpbWl0YXRpb24gdG8gMyBhdWRpbyBjaGFubmVscyBpbnRyb2R1Y2Vk DQppbiBSRVFNVC0yYiA6PGJyPg0KPGJyPg0KUkVRTVQtMmI6ICZuYnNwO1RoZSBzb2x1dGlvbiBN VVNUIHN1cHBvcnQgYSBtZWFucyB0byBpZGVudGlmeTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDttb25hdXJhbCwgc3RlcmVvcGhvbmljICgyLjApLCBhbmQgMy4wIChsZWZ0LDxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtjZW50ZXIsIHJpZ2h0KSBhdWRpbyBjaGFubmVs cy48YnI+DQo8YnI+DQpJcyBpdCB0aGUgaW50ZW50IHRvIGV4Y2x1ZGUgdGhlIG11bHRpcGxleGlu ZyBvZiBhIGhpZ2hlciBudW1iZXIgb2YgY2hhbm5lbHMNCj88YnI+DQpJZiB0aGUgaW50ZW50IGlz IHRvIGludHJvZHVjZSBzb21lIGxpbWl0YXRpb24sIHdoYXQgaXMgdGhlIHJhdGlvbmFsZSBiZWhp bmQNCmFuZCB3aHkgc3VjaCBsaW1pdCBpcyBzZXQgdG8gMy4wICZuYnNwOz88YnI+DQo8YnI+DQpU aGFua3M8YnI+DQo8YnI+DQpTdMOpcGhhbmU8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNsdWUgbWFpbGluZyBsaXN0PC9mb250 Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWls dG86Y2x1ZUBpZXRmLm9yZz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5jbHVlQGlldGYub3Jn PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9u dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZSB0YXJn ZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2x1ZTwvdT48L2ZvbnQ+PC9hPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpj bHVlIG1haWxpbmcgbGlzdDxicj4NCmNsdWVAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWU8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 005D884E482578B8_=-- From allyn@cisco.com Thu Jun 23 14:54:20 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E0021F84C0 for ; Thu, 23 Jun 2011 14:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9TAWlN4cMzY for ; Thu, 23 Jun 2011 14:54:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2037B21F84BC for ; Thu, 23 Jun 2011 14:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=11338; q=dns/txt; s=iport; t=1308866058; x=1310075658; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=JdwROZEomWYgLVb/O/kYYa/RJmtKuc+Slf0rBJVjOiM=; b=SAgaUPUu+/wSbVh4Nw2Ffowo79PtcwFTH14Cxrr5tt21szqj2cvKyR1C SA9ENkZNhD+r1p2pfMiRdQxe8UUwRUsmYD48uvB8i4n2uBtTbwTkWoWId efwqrpXMwEEc+GWyJ8pi9Tlybtl34S1ORK/poZNLjtHqlg6cTSNTdNOHA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAN20A06rRDoJ/2dsb2JhbABEDoJRlT6PHnesb518gx+DDgSHJo86hD6HAg X-IronPort-AV: E=Sophos;i="4.65,415,1304294400"; d="scan'208,217";a="468608670" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2011 21:54:17 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5NLsH0g019283; Thu, 23 Jun 2011 21:54:17 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 14:54:17 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC31F0.192ACED7" Date: Thu, 23 Jun 2011 14:54:16 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04BC6AF1@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4D1AA2A55522044480C9B9CF97A9340901BD10FC@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] clarification on requirements draft 03 Thread-Index: Acww6YZZVa3mScTXQaOOjW4h3bdCLAAkoWdQABz6BrA= References: <4D1AA2A55522044480C9B9CF97A9340901BD10FC@ftrdmel0.rd.francetelecom.fr> From: "Allyn Romanow (allyn)" To: , X-OriginalArrivalTime: 23 Jun 2011 21:54:17.0298 (UTC) FILETIME=[19484320:01CC31F0] Cc: clue@ietf.org Subject: Re: [clue] clarification on requirements draft 03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 21:54:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC31F0.192ACED7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This seems fine to me. If there aren't objections, we can make this change. =20 Regards, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = stephane.proust@orange-ftgroup.com Sent: Thursday, June 23, 2011 1:10 AM To: stephen.botzko@gmail.com Cc: clue@ietf.org Subject: Re: [clue] clarification on requirements draft 03 =20 Hi,=20 =20 Since we are dealing with "requirements" and depending on how you read = and understand the hierarchy of requirements (2b with respect to 2), = this could mean that the solution MAY NOT support any mean to identify = more than the following 3 cases : monaural, stereophonic and 3.0 L/C/R.=20 =20 If the intention is not to limit to those 3 cases (although the more = important ones with respect to existing solutions) which is needed to = design a future proof solution I would suggest to make it more explicit = by using some wording like : =20 The solution MUST support a means to identify the number and spatial = arrangement of audio channels including=20 monaural, stereophonic (2.0), and 3.0 (left, center, right) audio channels. =20 Regards =20 St=E9phane =20 ________________________________ De : Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Envoy=E9 : mercredi 22 juin 2011 16:34 =C0 : PROUST Stephane RD-TECH-LAN Cc : clue@ietf.org Objet : Re: [clue] clarification on requirements draft 03 The requirement is not intended to preclude a higher number of channels, = it is intended to say that the solution has to at least include those = three modes. =20 The rationale is that those are the modes in use today by telepresence = systems. Regards, Stephen Botzko On Wed, Jun 22, 2011 at 9:13 AM, = wrote: Hi I 've maybe missed some discussions related to some of the modifications = brought in draft 03 with respect to draft 02 but I would appreciate some = clarification/explanation about the limitation to 3 audio channels = introduced in REQMT-2b : REQMT-2b: The solution MUST support a means to identify monaural, stereophonic (2.0), and 3.0 (left, center, right) audio channels. Is it the intent to exclude the multiplexing of a higher number of = channels ? If the intent is to introduce some limitation, what is the rationale = behind and why such limit is set to 3.0 ? Thanks St=E9phane _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CC31F0.192ACED7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This seems fine to me.

If there aren’t objections, we can make this = change.

 

Regards,

Allyn

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = stephane.proust@orange-ftgroup.com
Sent: Thursday, June 23, 2011 1:10 AM
To: stephen.botzko@gmail.com
Cc: clue@ietf.org
Subject: Re: [clue] clarification on requirements draft = 03

 

Hi,

 

Since we are dealing with "requirements" and = depending on how you read and understand the hierarchy of requirements (2b with = respect to 2), this could mean that the solution MAY NOT support any mean to = identify more than the following 3 cases : monaural, stereophonic and 3.0 = L/C/R.

 

If the intention is not to limit to those 3 cases (although = the more important ones with respect to existing solutions) which is needed = to design a future proof solution I would suggest to make it more explicit = by using some wording like :

 

The solution MUST support a means to identify the number and spatial arrangement of audio = channels including 
            &= nbsp;           monaural, stereophonic (2.0), and 3.0 (left,
                    =     center, right) audio channels.

 

Regards

 

St=E9phane

 

De : = Stephen Botzko [mailto:stephen.botzko@gmail.com]
Envoy=E9 : mercredi 22 juin 2011 16:34
=C0 : PROUST Stephane RD-TECH-LAN
Cc : clue@ietf.org
Objet : Re: [clue] clarification on requirements draft = 03

The requirement is = not intended to preclude a higher number of channels, it is intended to say that the solution has to at least include those three modes. 

The rationale is that those are the modes in use today by telepresence = systems.

Regards,
Stephen Botzko

On Wed, Jun 22, 2011 at 9:13 AM, <stephane.proust@orange= -ftgroup.com> wrote:

Hi

I 've maybe missed some discussions related to some of the modifications brought in draft 03 with respect to draft 02 but I would appreciate some clarification/explanation about the limitation to 3 audio channels = introduced in REQMT-2b :

REQMT-2b:  The solution MUST support a means to identify
                    =     monaural, stereophonic (2.0), and 3.0 (left,
                    =     center, right) audio channels.

Is it the intent to exclude the multiplexing of a higher number of = channels ?
If the intent is to introduce some limitation, what is the rationale = behind and why such limit is set to 3.0  ?

Thanks

St=E9phane

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

 

------_=_NextPart_001_01CC31F0.192ACED7-- From Even.roni@huawei.com Fri Jun 24 08:16:45 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFB422801C for ; Fri, 24 Jun 2011 08:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i2GE4bB298n for ; Fri, 24 Jun 2011 08:16:44 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DAEF622801A for ; Fri, 24 Jun 2011 08:16:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNA003PHVRMST@szxga03-in.huawei.com> for clue@ietf.org; Fri, 24 Jun 2011 23:16:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNA007CAVRMYO@szxga03-in.huawei.com> for clue@ietf.org; Fri, 24 Jun 2011 23:16:34 +0800 (CST) Received: from windows8d787f9 ([109.67.30.132]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LNA00EU5VR6UA@szxml11-in.huawei.com> for clue@ietf.org; Fri, 24 Jun 2011 23:16:33 +0800 (CST) Date: Fri, 24 Jun 2011 18:14:16 +0300 From: Roni Even To: clue@ietf.org Message-id: <005a01cc3281$69122ab0$3b368010$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tMQ0jWtCBmhTzkX3VRGskw)" Content-language: en-us Thread-index: AcwygWEsenAu014PQCebzZr5WUgrhA== Subject: [clue] proposal for rephrasing Req 3a - based on Iterim meeting discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:16:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_tMQ0jWtCBmhTzkX3VRGskw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, There was a comment from Stephan Wenger on Req 3a on the mailing list " Req 3a fine with me as written. However, have you thought about the implications when considering centralized mixing? In order to fulfill the use cases behind the requirements, the mixer needs to be aware of both capture info and rendering info. Not an issue for me, but there may be IPR implications, and I would prefer to see a "SHOULD" level of mandation for the centralized audio mixing use case (only). " The Requirement was discussed in the interim meeting. My view is that the requirement as written " The solution MUST enable individual audio streams to be associated with one or more video image captures, and individual video image captures to be associated with one or more audio captures, for the purpose of rendering proper position." may hint that it MUST be always possible to associate individual audio streams with video image captures which is not what always possible or preferred. I suggest that the text will talk about "Must have mechanism that will enable" which will make it clear that the mechanism will be there but this is not a guarantee that such association will always be available. Another comment that was made in the Interim meeting is that the first part should say "audio captures" and not "audio streams". My proposal is to change Req 3a to "The solution MUST have a mechanism that will enable individual audio captures to be associated with one or more video image captures, and individual video image captures to be associated with one or more audio captures, for the purpose of rendering proper position." We also discuss the EDT note and I assume that this will be covered in a separate email thread. Thanks Roni Even --Boundary_(ID_tMQ0jWtCBmhTzkX3VRGskw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

There was a comment from Stephan Wenger on Req 3a on the mailing list

"

Req 3a fine with me as written.  However, have you thought about the implications when considering centralized mixing?  In order to fulfill the use cases behind the requirements, the mixer needs to be aware of both capture info and rendering info…  Not an issue for me, but there may be IPR implications, and I would prefer to see a "SHOULD" level of mandation for the centralized audio mixing use case (only).

"

 

The Requirement  was discussed in the interim meeting.  

My view is that the requirement as written 

 
" The solution MUST enable individual audio streams to be associated with one or more video image captures, and individual video image captures to be associated with one or more audio captures, for the purpose of rendering proper position."
 
Another comment that was made in the Interim meeting is that the first part should say "audio captures" and not "audio streams".
 
My proposal is to change Req 3a to
<
0pt;font-family:"Calibri","sans-serif"'> 
 
"The solution MUST have a mechanism that will enable individual audio  captures to be associated with one or more video   image captures, and individual video image   captures to be associated with one or more  audio captures, for the purpose of rendering  proper position."
 
 
We also discuss the EDT note and I assume that this will be covered in a separate email thread.
 
Thanks
Roni Even
 
 
 
--Boundary_(ID_tMQ0jWtCBmhTzkX3VRGskw)-- From mary.ietf.barnes@gmail.com Fri Jun 24 13:56:03 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A5F11E822D for ; Fri, 24 Jun 2011 13:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf6aOWBg89u7 for ; Fri, 24 Jun 2011 13:56:02 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 17D8D11E8246 for ; Fri, 24 Jun 2011 13:55:37 -0700 (PDT) Received: by vws12 with SMTP id 12so3252141vws.31 for ; Fri, 24 Jun 2011 13:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=5+WtrcsAoGqW2WoQ9o24duRW+/C8vX+ZDT2ipre+gvI=; b=PPQiR/C0Ri2E2qvCArwjv09GhC68tXCsCvbpj7XwOEKf71fI4VYnmnpoCPZqb9cYVs io/pxMbmMs9XRgiQH+oNovphAMQE3xzxGM8PV/3AcBx4sGkrqGFlk887l+ZHtowCJIG2 aw3X8w7vdTDg/xT3Ui/wOK5R/TNN2+o2KaEtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=S7qfKUFKA4DTM7IyLzT+XNDezFucm8fGcNqM7pg95lJ5mzkaPS8SiZQJ90AFGmmQiZ f4CvihoHcpXGF/GkYoMGkqY0v5QgYLdmxrHseqA/3cJ6HoqNKwBpL3St2Q83wjDI2ttT BCl3/9M/NwajAl4ukwlrUGOj6i0rQHP3YexGI= MIME-Version: 1.0 Received: by 10.52.181.164 with SMTP id dx4mr5345597vdc.183.1308948932750; Fri, 24 Jun 2011 13:55:32 -0700 (PDT) Received: by 10.52.158.39 with HTTP; Fri, 24 Jun 2011 13:55:32 -0700 (PDT) In-Reply-To: References: <4E04D399.1080400@ericsson.com> Date: Fri, 24 Jun 2011 15:55:32 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec547c8ff2a6ba304a67b6cac Subject: [clue] Fwd: Nomcom 2011-2012: Second Call for Volunteers X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 20:56:03 -0000 --bcaec547c8ff2a6ba304a67b6cac Content-Type: text/plain; charset=ISO-8859-1 For folks that are not on the IETF discussion or announcement lists, please read this email on the Call for volunteers for the 2011-2012 Nominations committee. This is one of the most important positions you can be (randomly) selected for in terms of serving the community. Regards, Mary CLUE WG co-chair Past Nomcom Chair/Advisor ---------- Forwarded message ---------- From: Suresh Krishnan Date: Fri, Jun 24, 2011 at 1:12 PM Subject: Nomcom 2011-2012: Second Call for Volunteers To: IETF Discussion This is the Second call for Volunteers for the 2011-12 Nomcom. We are just about halfway through the volunteer period so if you are considering volunteering, please do so very soon. We have had a very good response to the initial call for volunteers and I am pleased to report that we have 50 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. You have until 11:59 pm EDT July 10, 2011 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible. If you volunteered before 21:00 EDT on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! Details about the process for volunteering for the Nomcom and the list of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/**ann/nomcom/2938/ The 50 volunteers who have thus far been qualified by the secretariat are: Alia Atlas , Juniper Networks Lixia Zhang , UCLA Wassim Haddad , Ericsson Glen Zorn , Network Zen Richard Barnes , BBN Technologies Stephen Kent , BBN Technologies Scott Mansfield , Ericsson Tina TSOU , FutureWei Technologies Fernando Gont , UTN/FRH Karen Seo , BBN Technologies Jie Dong , Huawei Technologies Mach Chen , Huawei Technologies Co. Sheng Jiang , Huawei Technologies Co. Ltd. Dimitri Papadimitriou , Alcatel-Lucent Thomas D. Nadeau , CA Technologies David Meyer , Cisco Systems/University of Oregon Wesley George , Time Warner Cable Cullen Jennings , Cisco Stephen Hanna , Juniper Networks Stephan Wenger , Bidyo Keyur Patel , Cisco Systems Michael Hamilton , BreakingPoint Systems Behcet Sarikaya , Huawei USA Mark Townsley , Cisco Systems Fred Baker , Cisco Systems Brian Trammell , ETH Zurich Sam Hartman , Painless Security Chris Griffiths , Comcast George Michaelson , APNIC Jiankang Yao , CNNIC Sohel Khan , Comcast Dacheng Zhang , Huawei Lianshu Zheng , Huawei Technologies Hui Deng , China Mobile Gang Chen , China Mobile Mirja Kuhlewind , University of Stuttgart John E Drake , Juniper Networks Matt Lepinski , BBN Technologies Subir Das , Telcordia Technologies Inc Yi Zhao , Huawei John Scudder , Juniper Networks Christer Holmberg , LM Ericsson Teemu Savolainen , Nokia Samita Chakrabarti , Ericsson Jaap Akkerhuis , NLnet labs Jason Weil , Time Warner Cable Randy Bush , Internet Initiative Japan Christian Schmidt , Nokia Siemens Networks Sean Shen , CNNIC Lou Berger , LabN Consulting The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that Nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the Nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com ______________________________**_________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/**listinfo/ietf-announce ______________________________**_________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/**listinfo/ietf --bcaec547c8ff2a6ba304a67b6cac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For folks that are not on the IETF discussion or= announcement lists, please read this email on the Call for volunteers for = the 2011-2012 Nominations committee. =A0 This is one of the most important = positions you can be (randomly) selected for in terms of serving the commun= ity.=A0

Regards,
Mary
CLUE WG co-chair
Past Nomcom Chair/Advisor


---------- Forwarded message ----------
From: Suresh Krishnan <suresh.krishnan@= ericsson.com>
Date: Fri, Jun 24, 2011 at 1:12 PM
Subject: Nomcom 2011-2012: Second Cal= l for Volunteers
To: IETF Discussion <ietf@ietf.org>


This is the Second cal= l for Volunteers for the 2011-12 Nomcom. =A0We are
just about halfway through the volunteer period so if you are considering volunteering, please do so very soon.

We have had a very good response to the initial call for volunteers and
I am pleased to report that we have 50 volunteers thus far whose
qualifications have been confirmed by the secretariat. I have notified
each of these volunteers by email.

However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross
section of the IETF population. You have until 11:59 pm EDT July 10, 2011 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible.

If you volunteered before 21:00 EDT on June 21 to serve as a voting member<= br> and have not received a confirmation email from me, please re-submit and bring to my attention right away!

Details about the process for volunteering for the Nomcom and the list
of open positions for which the nominating committee is responsible are
summarized in the initial announcement:

https://datatracker.ietf.org/ann/nomcom/2938/

The 50 volunteers who have thus far been qualified by the secretariat
are:

Alia Atlas , Juniper Networks
Lixia Zhang , UCLA
Wassim Haddad =A0, Ericsson
Glen Zorn , Network Zen
Richard Barnes , BBN Technologies
Stephen Kent , BBN Technologies
Scott Mansfield , Ericsson
Tina TSOU , FutureWei Technologies
Fernando Gont , UTN/FRH
Karen Seo , BBN Technologies
Jie Dong , Huawei Technologies
Mach Chen , Huawei Technologies Co.
Sheng Jiang , Huawei Technologies Co. Ltd.
Dimitri Papadimitriou , Alcatel-Lucent
Thomas D. Nadeau , CA Technologies
David Meyer , Cisco Systems/University of Oregon
Wesley George , Time Warner Cable
Cullen Jennings , Cisco
Stephen Hanna , Juniper Networks
Stephan Wenger , Bidyo
Keyur Patel , Cisco Systems
Michael Hamilton , BreakingPoint Systems
Behcet Sarikaya , Huawei USA
Mark Townsley , Cisco Systems
Fred Baker , Cisco Systems
Brian Trammell , ETH Zurich
Sam Hartman , Painless Security
Chris Griffiths , Comcast
George Michaelson , APNIC
Jiankang Yao , CNNIC
Sohel Khan , Comcast
Dacheng Zhang , Huawei
Lianshu Zheng , Huawei Technologies
Hui Deng , China Mobile
Gang Chen , China Mobile
Mirja Kuhlewind , University of Stuttgart
John E Drake , Juniper Networks
Matt Lepinski , BBN Technologies
Subir Das , Telcordia Technologies Inc
Yi Zhao , Huawei
John Scudder , Juniper Networks
Christer Holmberg , LM Ericsson
Teemu Savolainen , Nokia
Samita Chakrabarti , Ericsson
Jaap Akkerhuis , NLnet labs
Jason Weil , Time Warner Cable
Randy Bush , Internet Initiative Japan
Christian Schmidt , Nokia Siemens Networks
Sean Shen , CNNIC
Lou Berger , LabN Consulting

The primary activity for this nomcom will begin during IETF-81 in
Quebec City and should be completed by January 2012. The nomcom will
be collecting requirements from the community, as well as talking to
candidates and to community members about candidates. There will be
regularly scheduled conference calls to ensure progress. Thus, being a
nomcom member does require some time commitment.

Please volunteer by sending an email to me before
11:59 pm EDT July 10, 2011 as follows:

To: sures= h.krishnan@ericsson.com
Subject: Nomcom 2011-12 Volunteer

Please include the following information in the body of the mail:

Full Name: =A0// As you enter in the IETF Registration Form,
=A0 =A0 =A0 =A0 =A0 =A0// First/Given name followed by Last/Family Name
Current Primary Affiliation: // typically what goes in the Company
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // field in the IE= TF Registration Form

Email Address(es): // all email addresses used to Register for the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // past 5 IETF meetings
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // Please designate a Preferred email = address for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // contact if there is more than one e= mail address

Telephone number: =A0// With country code (for confirmation if selected)
Please expect an email response from me within 3 business days stating
whether or not you are qualified. =A0If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" = added
to the subject line.

If you are not yet sure you would like to volunteer, please consider
that Nomcom members play a very important role in shaping the
leadership of the IETF. =A0Ensuring the leadership of the IETF is fair
and balanced and comprised of those who can lead the IETF in the right
direction is an important responsibility that rests on the IETF
participants at large. Volunteering for the Nomcom is a good way of
contributing in that direction.

I will be publishing a more detailed target timetable, as well as
details of the randomness seeds to be used for the RFC 3797 selection
process within the next few days.

Thank you in advance for your participation.

Suresh Krishnan
Nomcom Chair 2011-2012
Email: nomcom-ch= air@ietf.org, suresh.krishnan@ericsson.com

_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ietf

I agree with Allyn and Espen that it would be good to leave o= ut the multi-view use case and leave it out of the requirements.=

 

Mark Duck= worth

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Thursday, June 23, 2011 4:59 AM
To: 'Es= pen Berger (espeberg)'; 'Allyn Romanow (allyn)'; 'Gorzynski, Mark E (The Ri= ght One)'
Cc: clue@ietf.org
Subject: Re: [clue] use cas= e and requirement for multi-view

 

Hi,

I will add multi-view as a separate use case to the use case dra= ft

= Roni

 

= From:= Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: Thurs= day, June 23, 2011 10:08 AM
To: Allyn Romanow (allyn); Roni Even;= Gorzynski, Mark E (The Right One)
Cc: clue@ietf.org
Subjec= t: RE: [clue] use case and requirement for multi-view=

 

Could we use multi-view as test for the e= xtensibility of CLUE? The last CLUE requirement talks about extensibility a= nd building Multi-view systems on top of CLUE would be a verification of CL= UE extensibility. 

 

I think that multi-view is too much to cover in t= he initial CLUE work.

 

Cheers

 

-Espen 

 

 

=

 =

From: clue-bounces@ietf.org [mailto:cl= ue-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn)
Sent:<= /b> 23. juni 2011 02:09
To: Roni Even; Gorzynski, Mark E (The Rig= ht One)
Cc: clue@ietf.org
Subject: Re: [clue] use case = and requirement for multi-view

 

Hi Roni,

 

The intention of the use case w= as for multi-view, multiple cameras on the same scene.

If the material is to b= e put in the document, I think it should be a separate use case, not a subs= et of others.

 

In terms of including multi-view in the requirements, I̵= 7;m fine to withdraw it and it can always be added later when someone wants= it. If there is not a particular champion for multi-view who wants it now,= then I think we can safely wait till later.

 

Regards,

Allyn

 

 

From: Roni Even [mailto:Even.= roni@huawei.com]
Sent: Wednesday, June 22, 2011 5:59 AM
To= : Allyn Romanow (allyn)
Cc: clue@ietf.org
Subject: = RE: use case for multi-view

 

Hi Allyn,

I sis not add it, I sent the following question to the list on M= ay 17th and did not get any response yet

 

"Hi Mark,

I am tryin= g to see how to fit this case in the use-cases draft. When I ignore the ter= m "virtual space" and look at the description it talks about desc= ribing the view point of each cameras that may overlap and allowing the rec= eivers to select the view they want. I see some resemblance to the educatio= n usage described.

Will it make sense to mentio vide different view in the = point to point symmetric or asymmetric case which has a case with a PTZ cam= era."

 

 

Roni Even

 

 

From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] Sent: Wednesday, June 22, 2011 6:51 AM
To: Roni Even
= Cc: clue@ietf.org

 

Hi Roni,

I thought Mark’s use case fo= r multi-view was added to the Use Case doc, but I couldn’t find it th= ere? Is it just not added yet or is there some issue with it?

 

= Thanks much


--bcaec547c8ff2a6ba304a67b6cac-- From allyn@cisco.com Fri Jun 24 20:41:01 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B5C11E807D for ; Fri, 24 Jun 2011 20:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.575 X-Spam-Level: X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr-VWvjylPRm for ; Fri, 24 Jun 2011 20:40:59 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0B42B11E80A4 for ; Fri, 24 Jun 2011 20:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=11143; q=dns/txt; s=iport; t=1308973259; x=1310182859; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=npPdE3fpQDKOHhqwE/nAaypS2YZ0T5PKdd2C871p69A=; b=L33rrXVJjSnpb+A/ePjf43WKFbPh5tQGWFeR+7w6QYjbfMT7XXPvXdG9 q0CB5FNEh6dvPIrTyG9rMzvyMG5EBtbcGdx1S99ZjHPZbT6U/2hfdavQN EkfHlN2kYAoGMqz6f9nEl5MPnC5dFXvYFonILXuubwJUDikntGP92iNBL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQAAINYBU6rRDoG/2dsb2JhbABSglGVS48md6wCnW+GMASHLI9Fi0E X-IronPort-AV: E=Sophos;i="4.65,422,1304294400"; d="scan'208,217";a="386022000" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2011 03:40:58 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5P3ewN4028527; Sat, 25 Jun 2011 03:40:58 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 20:40:57 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC32E9.B18CA32F" Date: Fri, 24 Jun 2011 20:40:56 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04C78114@xmb-sjc-221.amer.cisco.com> In-Reply-To: <005a01cc3281$69122ab0$3b368010$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] proposal for rephrasing Req 3a - based on Iterim meetingdiscussion Thread-Index: AcwygWEsenAu014PQCebzZr5WUgrhAAaBddw References: <005a01cc3281$69122ab0$3b368010$%roni@huawei.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , X-OriginalArrivalTime: 25 Jun 2011 03:40:57.0864 (UTC) FILETIME=[B1CC8080:01CC32E9] Subject: Re: [clue] proposal for rephrasing Req 3a - based on Iterim meetingdiscussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 03:41:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC32E9.B18CA32F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, I like your change and would like to adopt it. I'd also like to change=20 for the purpose of rendering proper position=20 to for the purpose of rendering position =20 how do you feel about that? =20 thanks, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Friday, June 24, 2011 8:14 AM To: clue@ietf.org Subject: [clue] proposal for rephrasing Req 3a - based on Iterim meetingdiscussion =20 Hi, There was a comment from Stephan Wenger on Req 3a on the mailing list "=20 Req 3a fine with me as written. However, have you thought about the implications when considering centralized mixing? In order to fulfill the use cases behind the requirements, the mixer needs to be aware of both capture info and rendering info... Not an issue for me, but there may be IPR implications, and I would prefer to see a "SHOULD" level of mandation for the centralized audio mixing use case (only). " =20 The Requirement was discussed in the interim meeting. =20 My view is that the requirement as written=20 =20 " The solution MUST enable individual audio streams to be associated with one or more video image captures, and individual video image captures to be associated with one or more audio captures, for the purpose of rendering proper position." =20 Another comment that was made in the Interim meeting is that the first part should say "audio captures" and not "audio streams". =20 My proposal is to change Req 3a to <=20 0pt;font-family:"Calibri","sans-serif"'> =20 "The solution MUST have a mechanism that will enable individual audio captures to be associated with one or more video image captures, and individual video image captures to be associated with one or more audio captures, for the purpose of rendering proper position." =20 =20 We also discuss the EDT note and I assume that this will be covered in a separate email thread. =20 Thanks Roni Even =20 =20 =20 ------_=_NextPart_001_01CC32E9.B18CA32F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Roni,

I like your change = and would like to adopt it.

I’d also like = to change

 for the purpose of rendering  proper position

to

 for the purpose of = rendering  position

 

how do you feel about = that?

 

thanks,

Allyn

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Friday, June 24, 2011 8:14 AM
To: clue@ietf.org
Subject: [clue] proposal for rephrasing Req 3a - based on Iterim meetingdiscussion

 

Hi,

There was a comment from Stephan Wenger on Req 3a = on the mailing list

" =

Req 3a fine with me as = written.  However, have you thought about the implications when considering centralized mixing?  In order to fulfill the use cases behind the requirements, the mixer needs to be aware of both capture info and = rendering info…  Not an issue for me, but there may be IPR = implications, and I would prefer to see a "SHOULD" level of mandation for the = centralized audio mixing use case (only).

"

 

The Requirement  was discussed in the interim = meeting.  

My view is that the requirement as written = 

 
" =
The =
solution MUST enable individual audio streams to be associated with one =
or more video image captures, and individual video image captures to be =
associated with one or more audio captures, for the purpose of rendering =
proper position."=

 
Another =
comment that was made in the Interim meeting is that the first part =
should say "audio captures" and not "audio =
streams".
 
My =
proposal is to change Req 3a to
< 
0pt;font-family:"Calibri"=
;,"sans-serif"'>
 
"The =
solution MUST have a mechanism that will enable individual audio  =
captures to be associated with one or more video   image =
captures, and individual video image   captures to be =
associated with one or more  audio captures, for the purpose of =
rendering  proper position."
 
 
We also discuss the EDT note and I =
assume that this will be covered in a separate email =
thread.
 
Thanks
Roni =
Even
 
 
 =
------_=_NextPart_001_01CC32E9.B18CA32F-- From mary.ietf.barnes@gmail.com Tue Jun 28 09:47:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886B811E8153 for ; Tue, 28 Jun 2011 09:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpXmpyoiDp8R for ; Tue, 28 Jun 2011 09:47:31 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD32911E8138 for ; Tue, 28 Jun 2011 09:47:29 -0700 (PDT) Received: by vxi40 with SMTP id 40so358699vxi.31 for ; Tue, 28 Jun 2011 09:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=285HG1YMN6dHFbGoN0U3Cjz2VESWxRQsRFrhbElGMwg=; b=CN7w48FLZXVeQjEvO4Jnmrre8bdBquViXc5s645lUaAGQT5hrxf3gnZ6XJj4H2oUgf igQf7OBY5BgvwkU4VtpFB94r8/XmtsOA8Lpw1J2+ZmFqLaClGJaxLuNiPfY+V2rFlbp8 gRt5zkzwu4Tzy6bQnawo4kKfK/MvcGA8/qH6I= MIME-Version: 1.0 Received: by 10.52.99.69 with SMTP id eo5mr1588187vdb.303.1309279648867; Tue, 28 Jun 2011 09:47:28 -0700 (PDT) Received: by 10.52.158.39 with HTTP; Tue, 28 Jun 2011 09:47:28 -0700 (PDT) In-Reply-To: <4483E11778CA964F9644B68621E1CA464B1D3B4A@CRPMBOXPRD02.polycom.com> References: <4483E11778CA964F9644B68621E1CA464B1D3B4A@CRPMBOXPRD02.polycom.com> Date: Tue, 28 Jun 2011 11:47:28 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307ca06e61e42c04a6c86c52 Subject: [clue] CLUE - Requested session has been scheduled for IETF 81 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 16:47:31 -0000 --20cf307ca06e61e42c04a6c86c52 Content-Type: text/plain; charset=ISO-8859-1 Note, CLUE has been moved to Thursday morning to help in resolving some other conflicts. Mary. -----Original Message----- From: IETF Secretariat [mailto:agenda@ietf.org] Sent: Tuesday, June 28, 2011 10:48 AM To: Barnes, Mary Cc: pkyzivat@cisco.com; gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; session-request@ietf.org Subject: CLUE - Requested session has been scheduled for IETF 81 Dear Mary Barnes, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. CLUE Session 1 (2 hours) Thursday, Morning Session I 0900-1130 Room Name: 206 A ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: clue Area Name: Real-time Applications and Infrastructure Area Session Requester: Mary Barnes Number of Sessions: 1 Length of Session(s): 2 hours Number of Attendees: 150 Conflicts to Avoid: First Priority: atoca avtcore avtext bliss drinks codec clue cuss drinks ecrit geopriv mmusic payload p2psip rtcweb salud simple sipclf sipcore siprec soc splices speermint xcon xmpp xrblock vipr Special Requests: If possible, please do not schedule the meeting on Monday. One of the key document authors will be arriving on Monday, but if there are travel delays, she won't make it in time for afternoon sessions. --------------------------------------------------------- --20cf307ca06e61e42c04a6c86c52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Note, CLUE has been moved to Thursday morning to= help in resolving some other conflicts.
Mary.=A0

-----Original Message---= --
From: IETF Secretariat [mailto:agenda@ie= tf.org]
Sent: Tuesday, June 28, 2011 10:48 AM
To: Barnes, Mary
Cc: pkyzivat@cisco.com; gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; session-request@ietf.org
Subject: CLUE - Requested session has been scheduled for IETF 81

Dear Mary Barnes,

The sessions that you have requested have been scheduled.
Below is the scheduled session information followed by
the information of sessions that you have requested.

CLUE Session 1 (2 hours)
Thursday, Morning Session I 0900-1130
Room Name: 206 A
----------------------------------------------



Requested Information:


---------------------------------------------------------
Working Group Name: clue
Area Name: Real-time Applications and Infrastructure Area
Session Requester: Mary Barnes

Number of Sessions: 1
Length of Session(s): =A02 hours


Number of Attendees: 150
Conflicts to Avoid:
=A0First Priority: atoca avtcore avtext bliss drinks codec clue cuss drink= s ecrit geopriv mmusic payload p2psip rtcweb salud simple sipclf sipcore si= prec soc splices speermint xcon xmpp xrblock vipr

Special Requests:
=A0If possible, please do not schedule the meeting on Monday. One of the k= ey document authors will be arriving on Monday, but if there are travel del= ays, she won't make it in time for afternoon sessions.
---------------------------------------------------------



--20cf307ca06e61e42c04a6c86c52-- From espeberg@cisco.com Wed Jun 29 02:31:05 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB2B9E8021 for ; Wed, 29 Jun 2011 02:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv48yOcZLD+D for ; Wed, 29 Jun 2011 02:31:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 51BF221F85A9 for ; Wed, 29 Jun 2011 02:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=6821; q=dns/txt; s=iport; t=1309339864; x=1310549464; h=mime-version:subject:date:message-id:from:to; bh=K3uWRc3mztIMOeXKJu0J6zlzKzwMDfdQ3FvRQYd/EP8=; b=XE/NBW2fFAAnLDeXGj0WHr+1iWc+vuhJFDLMn1f43hzRp9AoQtDLt2jT A4P/QvnTcBLV+KthQsLj4IIEDTQ92pf2ye0y1FjC12IeXIyFsXmkZCF4d PAks6vwLJvsbQ63DCTiS/uxziGPk9mfomykcqBGCP/2PQ6gusKtsFHSKi c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusIAInvCk6Q/khL/2dsb2JhbABSglGWD454d6lPgR6eCYYwBJcViy4 X-IronPort-AV: E=Sophos;i="4.65,442,1304294400"; d="scan'208,217";a="98757346" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 29 Jun 2011 09:31:00 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5T9V0ug032077 for ; Wed, 29 Jun 2011 09:31:00 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Jun 2011 11:31:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC363F.42209786" Date: Wed, 29 Jun 2011 11:31:00 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E78286F@XMB-AMS-214.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is multiple stages missing from the requirements? Thread-Index: Acw2P0HGdFEsDyvAQDaJuVG1L/shkA== From: "Espen Berger (espeberg)" To: X-OriginalArrivalTime: 29 Jun 2011 09:31:00.0763 (UTC) FILETIME=[42278EB0:01CC363F] Subject: [clue] Is multiple stages missing from the requirements? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 09:31:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC363F.42209786 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20 =20 Are we missing a definition of stages and a requirement to support describing multiple stages from the same endpoint? In the CLUE definition document the term stage is not defined, its only referred to from the definition of left and right.=20 =20 Examples of multiple stages could be=20 - Speaker-1 and speaker-2 (two camera point to different speakers)=20 - Speaker (three cameras) and audience (single camera)=20 - Lecturer, audience, questionnaire (from the lecturer use case) =20 =20 I also suggest adding a requirement into the requirement document for supporting multiple stages from the same room. =20 =20 "The solution must support a description of multiple stages from the same endpoint"=20 =20 Cheers =20 -Espen=20 =20 ------_=_NextPart_001_01CC363F.42209786 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

Are we missing a definition of stages and a requirement to = support describing multiple stages from the same endpoint? In the CLUE = definition document the term stage is not defined, its only referred to = from the definition of left and right.

 

Examples of multiple stages could = be

-          = Speaker-1 and = speaker-2 (two camera point to different speakers) =

-          = Speaker (three = cameras) and audience (single camera)

-          = Lecturer, audience, = questionnaire (from the lecturer use case) =  

 

I also suggest adding a requirement into the requirement = document for supporting multiple stages from the same room. =  

 

“The solution must support a description of multiple = stages from the same endpoint”

 

Cheers

 

-Espen

 

------_=_NextPart_001_01CC363F.42209786-- From stephen.botzko@gmail.com Wed Jun 29 03:38:37 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ED99E801F for ; Wed, 29 Jun 2011 03:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs+cStcgqixZ for ; Wed, 29 Jun 2011 03:38:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26B3B9E8029 for ; Wed, 29 Jun 2011 03:38:37 -0700 (PDT) Received: by vxi40 with SMTP id 40so951045vxi.31 for ; Wed, 29 Jun 2011 03:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vos35Ws+u2AnzsXfKDcxvvFxobkOO099KYNALP0LfAM=; b=cUAED7pttUKc896ja4Z2jC5O9pjLuzW0GijMLsUk3MKveV2GNFJ0bjS5XRXB3ddIRJ oU/vkyg6nPiDOtIgM/bNN+9KLFjbF1gECuZTxwtD410l3x8GJLTXQRdq2JTYXraw8ck9 xx4XaBoX8PWizM+eYVa5hrTzIOCGRIUTRc4Sc= MIME-Version: 1.0 Received: by 10.52.24.16 with SMTP id q16mr838186vdf.227.1309343916243; Wed, 29 Jun 2011 03:38:36 -0700 (PDT) Received: by 10.52.185.67 with HTTP; Wed, 29 Jun 2011 03:38:36 -0700 (PDT) In-Reply-To: <92DF9533227FC14F946C7321074B8C9E78286F@XMB-AMS-214.cisco.com> References: <92DF9533227FC14F946C7321074B8C9E78286F@XMB-AMS-214.cisco.com> Date: Wed, 29 Jun 2011 06:38:36 -0400 Message-ID: From: Stephen Botzko To: "Espen Berger (espeberg)" Content-Type: multipart/alternative; boundary=20cf307ac3d3043b7704a6d76332 Cc: clue@ietf.org Subject: Re: [clue] Is multiple stages missing from the requirements? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 10:38:37 -0000 --20cf307ac3d3043b7704a6d76332 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think the educational use case covers this scenario reasonably well. I agree there is no definition (there might be some debate about whether "stage" is the right term). The requirements draft doesn't discuss stages, it would be valuable to get some clarity on the topic. I am not sure if multiple stages are a "nice to have" or "must have". Regards, Stephen Botzko On Wed, Jun 29, 2011 at 5:31 AM, Espen Berger (espeberg) wrote: > Hi **** > > ** ** > > Are we missing a definition of stages and a requirement to support > describing multiple stages from the same endpoint? In the CLUE definition > document the term stage is not defined, its only referred to from the > definition of left and right. **** > > ** ** > > Examples of multiple stages could be **** > > **- **Speaker-1 and speaker-2 (two camera point to different > speakers) **** > > **- **Speaker (three cameras) and audience (single camera) **** > > **- **Lecturer, audience, questionnaire (from the lecturer use > case) **** > > ** ** > > I also suggest adding a requirement into the requirement document for > supporting multiple stages from the same room. **** > > ** ** > > =93The solution must support a description of multiple stages from the sa= me > endpoint=94 **** > > ** ** > > Cheers**** > > ** ** > > -Espen **** > > ** ** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --20cf307ac3d3043b7704a6d76332 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think the educational use case covers this scenario reasonably well.
=
I agree there is no definition (there might be some debate about whethe= r "stage" is the right term).

The requirements draft doesn= 't discuss stages, it would be valuable to get some clarity on the topi= c. =A0=A0 I am not sure if multiple stages are a "nice to have" o= r "must have".

Regards,
Stephen Botzko

On Wed, Ju= n 29, 2011 at 5:31 AM, Espen Berger (espeberg) <espeberg@cisco.com>= ; wrote:

Hi

=A0

<= span lang=3D"EN-US">Are we missing a definition of stages and a requirement= to support describing multiple stages from the same endpoint? In the CLUE = definition document the term stage is not defined, its only referred to fro= m the definition of left and right.

=A0

Examples of multiple stages could = be

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Speaker-1 and speaker-2 (two camera point to different speakers) =

-=A0=A0=A0=A0=A0=A0=A0=A0=A0= Speaker (three cameras) a= nd audience (single camera)

-=A0=A0=A0=A0=A0=A0=A0=A0=A0= Lecturer, audience, quest= ionnaire (from the lecturer use case) =A0

=A0

I also suggest adding a requiremen= t into the requirement document for supporting multiple stages from the sam= e room. =A0

=A0

=93The solution must support a des= cription of multiple stages from the same endpoint=94 =

=A0

Cheers

=A0

-Espen

=A0


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


--20cf307ac3d3043b7704a6d76332-- From mary.ietf.barnes@gmail.com Wed Jun 29 14:31:45 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4A111E808F for ; Wed, 29 Jun 2011 14:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koeSMKYZFgO4 for ; Wed, 29 Jun 2011 14:31:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD9311E807B for ; Wed, 29 Jun 2011 14:31:44 -0700 (PDT) Received: by vxi40 with SMTP id 40so1455809vxi.31 for ; Wed, 29 Jun 2011 14:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FSYxRHUpu8VNsKvlWq1nqoschKWq3B4WRthaSXLtZ1U=; b=DTrUgZ3Ax4gyKm3RozOH4FyyroRRq2p0cpZxoYBXyJVXvxJ1z52lOOy9xwIAGSZTbI fzVFbtwuslUvLklcRoZd79UAVGI4gSg0SePpQn1kePRnljT0YPsydaWsNToJAilmZDn3 3qcOIjlEBjIl/xIzfJft97nqF7sXhVERikd5Q= MIME-Version: 1.0 Received: by 10.52.75.36 with SMTP id z4mr1852026vdv.143.1309383103899; Wed, 29 Jun 2011 14:31:43 -0700 (PDT) Received: by 10.52.158.39 with HTTP; Wed, 29 Jun 2011 14:31:43 -0700 (PDT) In-Reply-To: <20110629202227.7864A21F8518@ietfa.amsl.com> References: <20110629202227.7864A21F8518@ietfa.amsl.com> Date: Wed, 29 Jun 2011 16:31:43 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec5016057c869db04a6e082ec Subject: [clue] Fwd: Internet Draft Initial Version (-00) Cut-Off Monday, July 4 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 21:31:45 -0000 --bcaec5016057c869db04a6e082ec Content-Type: text/plain; charset=ISO-8859-1 FYI... Please note that if you plan to submit a -00 and have not notified the chairs, please let us know ASAP if you are planning to submit a draft and would like agenda time. Thanks, Mary. ---------- Forwarded message ---------- From: Internet-Drafts Administrator Date: Wed, Jun 29, 2011 at 3:22 PM Subject: Internet Draft Initial Version (-00) Cut-Off Monday, July 4 To: IETF Announcement list This is a reminder that the Internet Draft Initial Version (-00) cut- off is this coming Monday, July 4, 2011. Please note that, because the AMS office is closed this Monday, manual submissions will not be processed until Tuesday, July 5. All Initial Version (-00) submissions are due by 17:00 PDT (00:00 Tuesday, July 5 UTC). All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/submit/ The Internet-Draft cutoff dates as well as other significant dates for IETF 81 can be found at: http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF81 Thank you for your understanding and cooperation. If you have any questions or concerns please send a message to internet-drafts@ietf.org. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --bcaec5016057c869db04a6e082ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI...

Please note that if you plan to submit a -00 and = have not notified the chairs, please let us know ASAP if you are planning t= o submit a draft and would like agenda time.

Thank= s,
Mary.=A0

---------- Forwarded messag= e ----------
From: Internet-Drafts Adminis= trator <internet-drafts@ietf.org>
Date: Wed, Jun 29, 2011 at 3:22 PM
Subject: Internet Draft Initial Versi= on (-00) Cut-Off Monday, July 4
To: IETF Announcement list <ietf-announce@ietf.org>


This is a reminder that the Internet Draft Initial Version (-00) cut-
off is this coming Monday, July 4, 2011. Please note that, because
the AMS office is closed this Monday, manual submissions will not be
processed until Tuesday, July 5.

All Initial Version (-00) submissions are due by 17:00 PDT (00:00
Tuesday, July 5 UTC).

All drafts can be uploaded using the ID submission tool located here:
https://= datatracker.ietf.org/submit/

The Internet-Draft cutoff dates as well as other significant dates for
IETF 81 can be found at:
http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF81<= br>
Thank you for your understanding and cooperation. If you have any
questions or concerns please send a message to
internet-drafts@ietf.org.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--bcaec5016057c869db04a6e082ec--