Subject: [clue] Comments on requirements draft 03

From: <[email-masked]>
Date: Tue, 21 Jun 2011 08:54:54 +0000

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 attendees see the video of the presenter 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:

Req-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

2)
We need to consider defining roles of streams, when spatial position is not applicable. This is especially valid for presentation (REQMT-16), since the new draft seems to consider multiple presentation streams (typically : next/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.

---

From: <[email-masked]>
Date: Wed, 22 Jun 2011 15:13:17 +0200

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éphane

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 22 Jun 2011 10:34:26 -0400

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, <[email-masked]> 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 :
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: <[email-masked]>
Date: Thu, 23 Jun 2011 10:10:30 +0200

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 
                        monaural, stereophonic (2.0), and 3.0 (left,
                        center, right) audio channels.

Regards
 
Stéphane

________________________________

De : Stephen Botzko [mailto:[email-masked]] 
Envoyé : mercredi 22 juin 2011 16:34
À : PROUST Stephane RD-TECH-LAN
Cc : [email-masked]
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

	Hi

	
	
	Thanks
	
	Stéphane

---

From: [email-masked]
Date: Fri, 24 Jun 2011 01:02:39 +0800

REQMT-2b: 
Stéphane's suggestion seems better.

REQMT-1d: The solution MUST support multi-view as described in the use 
cases.
Agree to remove this item in present requirements, at least use "SHOULD" 
rather than "MUST".

REQMT-5: The solution MUST support interoperability between endpoints 
where the number of cameras and/or displays are zero.
Agree to reword "endpoints where the number of cameras and/or displays are 
zero", 
what about "endpoints which don't send and/or receive video stream". 
Because sometimes the end user just does't send and/or receive video 
stream though there are cameras and/or displays devices.

Best regards,

Xiaoyang

<[email-masked]> 
发件人:  [email-masked]
2011-06-23 下午 04:10

收件人
<[email-masked]>
抄送
[email-masked]
主题
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 
                        monaural, stereophonic (2.0), and 3.0 (left,
                        center, right) audio channels.
 
Regards
 
Stéphane

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. 

Regards,
Stephen Botzko

On Wed, Jun 22, 2011 at 9:13 AM, <[email-masked]> 
wrote:
Hi

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éphane

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 23 Jun 2011 14:54:16 -0700

This seems fine to me.

If there aren't objections, we can make this change.

Regards,

Allyn

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 23, 2011 1:10 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [clue] clarification on requirements draft 03

Hi, 

Regards

Stéphane

Regards,
Stephen Botzko

Hi

Thanks

Stéphane