Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt

Christian Groves <Christian.Groves@nteczone.com> Thu, 25 July 2013 00:17 UTC

Return-Path: <Christian.Groves@nteczone.com>
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 5CE0C21F98AD for <clue@ietfa.amsl.com>; Wed, 24 Jul 2013 17:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSMkiNu5-JAN for <clue@ietfa.amsl.com>; Wed, 24 Jul 2013 17:17:52 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D721F9829 for <clue@ietf.org>; Wed, 24 Jul 2013 17:17:52 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBAGZt8FF20Thy/2dsb2JhbAANRAq+coJ9gSyDGAEBAQQyAQUbJQEQCxgJFg8JAwIBAgFFBg0BBwEBF68/kjyORIE5B4QAA6xS
Received: from ppp118-209-56-114.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.56.114]) by ipmail05.adl6.internode.on.net with ESMTP; 25 Jul 2013 09:47:50 +0930
Message-ID: <51F06EA8.8000302@nteczone.com>
Date: Thu, 25 Jul 2013 10:17:44 +1000
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Mary Barnes <mary.ietf.barnes@gmail.com>
References: <20130716162934.14206.13360.idtracker@ietfa.amsl.com> <CAHBDyN5Yz7eGtyVVVDkxfgMM580Ef=9jMsL3kePpeDW6tpQJmw@mail.gmail.com> <51E75A6C.3090707@nteczone.com> <CAHBDyN4GnMKvwVzyMS-xe5uWM2-JXCSwgn9uG5_eKJ1NwOR1_w@mail.gmail.com> <51EF3964.80206@nteczone.com> <CAHBDyN4Z4_DtQsXbGF+hM+sZpcCzjL9pzLuB2S1_NhGyOnJWQw@mail.gmail.com>
In-Reply-To: <CAHBDyN4Z4_DtQsXbGF+hM+sZpcCzjL9pzLuB2S1_NhGyOnJWQw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: CLUE <clue@ietf.org>
Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 00:17:53 -0000

Hello Mary,

Please see below.

Regards, Christian

On 25/07/2013 10:02 AM, Mary Barnes wrote:
> Hi Christian,
>
> Additional responses below [MB2].
>
> Thanks,
> Mary.

> ..snip..
>
>
>             REQMT-2b:The solution MUST support a means to identify
>
>             the number and spatial arrangement of audio
>
>             channels including monaural, stereophonic
>
>             (2.0), and 3.0 (left, center, right) audio
>
>             channels.
>
>             [CNG] Partial – the Audio Channel Format attribute
>         currently only
>             supports “mono” and “stereo”. It doesn’t support the 3.0
>         format
>
>
>         [MB] So, my question to the group is do we need to support
>         this in the current work is is this something that could be
>         extended later. I looked fairly quickly but I also could not
>         find a use case for 3.0[/MB]
>
>     [CNG] Maybe rather than an enumeration (e.g. mono, stereo) we just
>     make this an integer. So rather "Audio Channel Format" we have a
>     "Number of audio channels capture" parameter. 1 would indicate
>     single channel (e.g. mono), 2 would indicate two channels (e.g.
>     stereo), 5 would indicate five channels (e.g. 5.1). At least this
>     is a future proof way so we don't have to open up this parameter
>     in the future?
>
> [MB2] I think I agree with you.  If I understand your proposal, the 
> solution needs to support a number of audio channels.  So, we would be 
> okay with this requirement standing since the solution would provide 
> the "means to identify", although the functionality may not 
> necessarily support.  Is that correct? [/MB2]
[CNG] Yes although I'm not sure what the significance of "since the 
solution would provide the "means to identify", although the 
functionality may not necessarily support" is? Like all the 
attributes/values a endpoint isn't required to support them.

>