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

[Mary Barnes <[e-mail]>]

Thanks very much for your detailed review and comments with regards to
whether the REQ is currently supported in the solution.  I have a few
comments below.

Thanks,
Mary
As editor for the Requirements do


On Wed, Jul 17, 2013 at 10:01 PM, Christian Groves <
[e-mail]> wrote:

> Hello Mary,
>
> I did a review of the requirements and Appendix to see if they are met. My
> comments are below. Sorry for the length of the email but I figured it
> would be easier for people to read my comment [CNG] along with the
> requirement.
>
> 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.
>
> [CNG] Supported – via Capture Area attribute.
>
> Use case point to point symmetric, and all other use cases.
>
> REQMT-1a:The solution MUST support a means of allowing
>
> the preservation of the order of images in the
>
> captured scene.For example, if John is to
>
> Susan's right in the image capture, John is
>
> also to Susan's right in the rendered image.
>
> [CNG] Supported – via Capture Area attribute.
>
> REQMT-1b:The solution MUST support a means of allowing
>
> the preservation of order of images in the
>
> scene in two dimensions - horizontal and
>
> vertical.
>
> [CNG] Supported – via Capture Area attribute.
>
> REQMT-1c:The solution MUST support a means to identify
>
> the point of capture of individual video
>
> captures in three dimensions.
>
> [CNG] Supported – via Point of capture attribute.
>
> REQMT-1d:The solution MUST support a means to identify
>
> the extent of individual video captures in
>
> three dimensions.
>
> [CNG] Partial – Capture area attribute allows the specification of a plane
> of capture in 3 dimensions. However depth of the capture (needed for a 3D
> area) is not supported.
>
[MB] Per my comments on open issue 5 from the requirements document (and
Ticket # 41  in the tracker), I was proposing we not require 3D in the
solution at this time.  [/MB]

>
> REQMT-2:The solution MUST support a description of the spatial
>
> arrangement of captured source audio sent in audio streams
>
> which enables a satisfactory reproduction at the receiver
>
> in a spatially correct manner.This applies to each site
>
> in a point to point or a multipoint meeting and refers to
>
> the spatial ordering within a site, not the ordering of
>
> channels between sites.
>
> [CNG] Supported – Via Capture Area attribute.
>
> Use case point to point symmetric, and all use cases,
>
> especially heterogeneous.
>
> REQMT-2a:The solution MUST support a means of preserving
>
> the spatial order of audio in the captured
>
> scene.For example, if John sounds as if he is
>
> at Susan's right in the captured audio, John
>
> voice is also placed at Susan's right in the
>
> rendered image.
>
> [CNG] Supported – Via Capture Area attribute.
>
> 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]

>


> REQMT-2c:The solution MUST NOT preclude the use of
>
> binaural audio.[Edt. This is an outstanding
>
> issue.Text will be changed when the issue is
>
> resolved.]
>
> [CNG] Partial? – Binaural isn’t mentioned in the framework so isn’t
> precluded as such. There is no indication in CLUE recording a binaural
> capture.
>

[MB] Yeah, per my comments on Issue 1 (ticket #37) , I propose that we just
delete this requirement. [/MB]

>
> REQMT-2d:The solution MUST support a means to identify
>
> the point of capture of individual audio
>
> captures in three dimensions.
>
> [CNG] Supported – via Point of capture attribute.
>
> REQMT-2e:The solution MUST support a means to identify
>
> the extent of individual audio captures in
>
> three dimensions.
>
> [CNG] Partial – The Capture area attribute is based on capturing a plane
> in Cartesian space. There is no depth parameter. Whether the plane concept
> holds for audio like it does video needs further thought.
>
> REQMT-3:The solution MUST support a mechanism to enable a
>
> satisfactory spatial matching between audio and video
>
> streams coming from the same endpoints.
>
> [CNG] Supported - The given that an Advertiser places captures in a
> particular scene it is possible to indicate audio and video streams are
> from the same endpoint.
>
> Use case is point to point symmetric, and all use cases.
>
> REQMT-3a: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.
>
> [CNG] Supported (Partial?) – It is possible to deduce that audio and video
> relate to the same capture area in a scene by analysing the Capture Area
> parameters. It is possible to relate individual audio captures to video
> captures if the Advertisement is constructed in a limited way. However its
> not possible to deduce the relationships between individual captures by
> utilising the Scene, CSE and capture concepts. CSE only relate to one media
> type. So it’s not possible to link audio CSEs to video CSEs.
>
> REQMT-3b:The solution MUST enable individual audio
>
> streams to be rendered in any desired spatial
>
> position.
>
> [CNG] Supported? – I think its assumed that a Consumer can do whatever it
> likes with respect to rendering decisions. Ultimately that’s local policy.
>
> Edt: Rendering is an open issue. Text will
>
> be changed when it is resolved.]
>
> REQMT-4:The solution MUST enable interoperability between
>
> endpoints that have a different number of similar devices.
>
> For example, one endpoint may have 1 screen, 1 speaker, 1
>
> camera, 1 mic, and another endpoint may have 3 screens, 2
>
> speakers, 3 cameras and 2 mics.Or, in a multi-point
>
> conference, one endpoint may have one screen, another may
>
> have 2 screens and a third may have 3 screens.This
>
> includes endpoints where the number of devices of a given
>
> type is zero.
>
> Use case is asymmetric point to point and multipoint.
>
> [CNG] Supported – CLUE enables different capture capabilities to be
> signalled. It makes no assumption as to the rendering.
>
> REQMT-5:The solution MUST support means of enabling
>
> interoperability between telepresence endpoints where
>
> cameras are of different picture aspect ratios.
>
> [CNG] Supported – CLUE doesn’t describe “aspect ratio” but allows
> different capture areas to be defined. This is a means of describing aspect
> ratio.
>
> REQMT-6:The solution MUST provide scaling information which
>
> enables rendering of a video image at the actual size of
>
> the captured scene.
>
> [CNG] Supported - Capture Area, Capture Point, Point of Line of Capture
> and Scene Scale allow this.
>
> REQMT-7:The solution MUST support means of enabling
>
> interoperability between telepresence endpoints where
>
> displays are of different resolutions.
>
> [CNG] Supported? – CLUE allow encoding parameters to be associated with
> captures which could state the resolution of the captured image. However
> there is no way to indicate “display” resolution. Perhaps the requirement
> needs to be reworded?
>

[MB] Do you have any suggestions for rewording?  [/MB]

>
> REQMT-8:The solution MUST support methods for handling different
>
> bit rates in the same conference.
>
> [CNG] Supported – CLUE allow encoding parameters to be associated with
> captures which could state the bit rate.
>
> REQMT-9:The solution MUST support means of enabling
>
> interoperability between endpoints that send and receive
>
> different numbers of media streams.
>
> Use case heterogeneous and multipoint.
>
> [CNG] Supported – CLUE allows different numbers of captures to be sent.
>
> REQMT-10:The solution MUST make it possible for endpoints without
>
> support for telepresence extensions to participate in a
>
> telepresence session with those that do.
>
> [CNG] Supported – The support of a CLUE channel will be negotiated between
> endpoints. From the current signalling draft it seems a basic set of media
> can be established without CLUE. Endpoints that don’t support CLUE
> obviously won’t be able to determine spatial information etc…
>
> REQMT-11:The solution MUST support a mechanism for determining
>
> whether or not an endpoint or MCU is capable of
>
> telepresence extensions.
>
> [CNG] Supported? – The negotiation of a CLUE channel via SDP is one method
> in the signalling draft. Another indication at the SIP level may be
> beneficial such as a feature tag. This is yet to be documented.
>
> REQMT-12:The solution MUST support a means to enable more than two
>
> sites to participate in a teleconference.
>
> Use case multipoint.
>
> [CNG] Partial – This is on the agenda and there’s basic support i.e. via
> the composed attribute and “scene-switch-policy” CSE attribute. However no
> method is yet defined to keep the source information.
>
> REQMT-13:The solution MUST support both transcoding and switching
>
> approaches to providing multipoint conferences.
>
> [CNG] Supported – CLUE supports these two methods. However further work is
> needed on the details.
>
> REQMT-14:The solution MUST support mechanisms to make possible for
>
> either or both site switching or segment switching.[Edt:
>
> This needs rewording.Deferred until layout discussion is
>
> resolved.]
>
> [CNG] Partial – The “scene-switch-policy” CSE attribute supports this to
> some level but further work is needed in this area.
>
> REQMT-15:The solution MUST support mechanisms for presentations in
>
> such a way that:
>
> *Presentations can have different sources
>
> *Presentations can be seen by all
>
> *There can be variation in placement, number and size of
>
> Presentations
>
> [CNG] Partial – CLUE allows an endpoint whether the capture is related to
> a presentation or not through the use of the presentation attribute. The
> spatial attributes (i.e. capture area) allows the place and size to be
> indicated. The number can be inferred from the number of captures. CLUE
> doesn’t have any policy on who can see the presentations. The CLUE
> Advertisement mechanism may include presentation captures to all people
> within the conference. Perhaps the 2^nd bullet can be removed or clarified
> that its not related to policy?
>
[MB] I'm of a mindset to just remove that 2nd bullet. [/MB]

>
> REQMT-16:The solution MUST include extensibility mechanisms.
>
> [CNG] Supported? – whilst not explicitly documented I think there’s
> general agreement this is needed.
>
> REQMT-17:The solution must support a mechanism for allowing
>
> information about media captures to change during a
>
> conference.
>
> [CNG] Supported? – Keeping the CLUE signalling channel open would allow
> for this and people seem in agreement this should be possible. Further
> detailed work is needed in the signalling draft to describe this. i.e.
> incremental vs full updates. Interaction with bearer signalling (i.e. SDP
> O/A) etc.
>
> REQMT-18:The solution MUST provide a mechanism for the secure
>
> exchange of information about the media captures.
>
> [CNG] Partial? – It is assumed that CLUE will operate over a DTLS/SCTP
> however there’s no documentation regarding CLUE security.
>
[MB] There is an open action item (Ticket #33) for me to work with Mark
with regards to an overview of the security solution required for CLUE.
[/MB]

>
> Appendix A. open issues
>
> OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural
>
> audio is unresolved, and the "MUST NOT preclude" language in
>
> this requirement is problematic.The authors believe this
>
> requirement needs to be either changed or withdrawn,
>
> depending on how the issue is resolved.
>
> [CNG] Not supported - This is still unresolved.
>
[MB] See my suggestion here:
http://www.ietf.org/mail-archive/web/clue/current/msg02753.html
[/MB]

OPEN-2Reference to Rendering [REQMT-3b] This is the only
>
> requirement which refers to rendering.It may also be empty,
>
> since receivers can rendering audio captures as they wish.
>
> This is deferred until broader discussion on rendering
>
> requirements is concluded.
>
> [CNG] I think we should frame the requirements with regards to captures as
> that’s the way the framework is written. Perhaps some text to say that
> rendering is based on the receivers local policy.
>

[MB] See my suggestion here:
http://www.ietf.org/mail-archive/web/clue/current/msg02751.html
[/MB]

> OPEN-3Conference modes [REQMT-14] This wording of this requirement
>
> is problematic in part because the conference modes (site
>
> switching and segment switching) are not defined.It at
>
> least needs rewording.This is deferred until broader
>
> discussion on layout is concluded.
>
> [CNG] Yes this is still open.
>
[MB]  I know the issue is open in the solution. But, I think the
requirements stands, but just needs rewording.  See my suggestion here:
http://www.ietf.org/mail-archive/web/clue/current/msg02750.html
[/MB]


OPEN-4Need to capture requirement that attributes can change at any
>
> time during the call.
>
> [CNG] Yes although it seems REQMT-17 covers this.
>
[MB] That is my thought as well:
http://www.ietf.org/mail-archive/web/clue/current/msg02749.html
[/MB]

>
> OPEN-5Need to add requirement for three dimensions in the right
>
> place
>
> [CNG] Requirements 1d and 2e do capture an aspect of 3D.
>
[MB] Here's my thoughts on this one:
 http://www.ietf.org/mail-archive/web/clue/current/msg02755.html
 I think it's good that we have some requirements that capture some aspects
and the FW/solution will support those requirements, I'm just not sure it's
a priority to support 3D in the current set of deliverables. [/MB]

OPEN-6Multi-view, is there a requirement needed?
>
> [CNG] Even if there’s no requirement we appear to support it because we
> allow both the capture area and capture point to be sent for captures. An
> Advertiser could describe multiple capture points capturing the same area
> of capture.
>
[MB]  I didn't know what multi-view meant:
http://www.ietf.org/mail-archive/web/clue/current/msg02754.html
 However, isn't that functionality supporting other requirements?  So, my
question is do we really need an explicit requirement and if so we need to
be clear what we mean by multi-view (in more general terms. [/MB]

>
>
> Regards, Christian
>
>
> On 17/07/2013 6:07 AM, Mary Barnes wrote:
>
>> There really were no changes other than to refresh this draft. I was
>> going to extend the security section with more detail, but I really can't
>> add much more detail without referencing things that are defined in the
>> framework. So, I think the next step is for me to work with Mark on the
>> security for the framework.
>>
>> There are some open issues identified in the appendix of this document
>> that we need to figure out whether they are issues that need resolution for
>> this document. I will open issues in the tracker and we can discuss each
>> one and perhaps make some decisions before Berlin.
>>
>> We also need to consider whether the current framework meets these
>> requirements. If some requirements are not met, we need to decide whether
>> it's because they'll be met by the solution documents or won't be met at
>> all. In which case, we need to decide whether we actually need them for the
>> solution.
>>
>> Regards,
>> Mary.
>>
>>
>> On Tue, Jul 16, 2013 at 11:29 AM, <[e-mail] <mailto:
>> internet-drafts@ietf.**org <[e-mail]>>> wrote:
>>
>>
>>     A New Internet-Draft is available from the on-line Internet-Drafts
>>     directories.
>>     This draft is a work item of the ControLling mUltiple streams for
>>     tElepresence Working Group of the IETF.
>>
>>     Title : Requirements for Telepresence Multi-Streams
>>     Author(s) : Allyn Romanow
>>     Stephen Botzko
>>     Mary Barnes
>>     Filename : draft-ietf-clue-telepresence-**requirements-04.txt
>>     Pages : 14
>>     Date : 2013-07-15
>>
>>     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 datatracker status page for this draft is:
>>     https://datatracker.ietf.org/**doc/draft-ietf-clue-**
>> telepresence-requirements<https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements>
>>
>>     There's also a htmlized version available at:
>>     http://tools.ietf.org/html/**draft-ietf-clue-telepresence-**
>> requirements-04<http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-04>
>>
>>     A diff from the previous version is available at:
>>     http://www.ietf.org/rfcdiff?**url2=draft-ietf-clue-**
>> telepresence-requirements-04<http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-04>
>>
>>
>>     Internet-Drafts are also available by anonymous FTP at:
>>     ftp://ftp.ietf.org/internet-**drafts/<ftp://ftp.ietf.org/internet-drafts/>
>>
>>     ______________________________**_________________
>>     I-D-Announce mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/**listinfo/i-d-announce<https://www.ietf.org/mailman/listinfo/i-d-announce>
>>     Internet-Draft
>>     <https://www.ietf.org/mailman/**listinfo/i-d-announce%**
>> 0AInternet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft>
>> >
>>
>>     directories: http://www.ietf.org/shadow.**html<http://www.ietf.org/shadow.html>
>>     or ftp://ftp.ietf.org/ietf/**1shadow-sites.txt<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>
>>
>>
>>
>> ______________________________**_________________
>> clue mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>
> ______________________________**_________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>