Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-03.txt

From: [email-masked]
Date: Sat, 18 Oct 2014 14:16:19 -0700

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           : Mapping RTP streams to CLUE media captures
        Authors         : Roni Even
                          Jonathan Lennox
	Filename        : draft-ietf-clue-rtp-mapping-03.txt
	Pages           : 15
	Date            : 2014-10-18

Abstract:
   This document describes how the Real Time transport Protocol (RTP) is
   used in the context of the CLUE protocol.  It also describes the
   mechanisms and recommended practice for mapping RTP media streams
   defined in SDP to CLUE media captures.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Oct 2014 14:41:35 -0400

In prep for the design team call tomorrow I have a few comments on the 
-03 version:

* Section 1: Intro

    With regards to the media (audio and video), systems that support

I think you had better also include real-time text in the above.

* Section 4.1:

    The solution needs to also support the simulcast case where more than
    one RTP session may be advertised for a Media Capture.  Support of
    such simulcast is out of scope for CLUE but a solution is needed.

Why does this say that simulcast is out of scope. We have mechanisms by 
which a consumer can explicitly request simulcast. Do you mean that 
there are some simulcast mechanisms that are out of scope?

Exactly what requires a solution? And is it needed for CLUE, or more 
generally?

* Section 4.2:

    Media-4: It must be possible for an original source to move among
    multi-content captures (i.e. at one time be sent for one MCC, and at
    a later time be sent for another one).

I don't see a requirement that the same original to be included in 
multiple MCCs at the same time, or to be in a configured MCC and also to 
be configured on its own.

    Media-7: It must be possible for a receiver to identify the original
    capture(s) that are currently being mapped to an MCC, and correlate
    it with both the Clue advertisement and out-of-band (non-Clue)
    information such as rosters.

I guess this can only be a requirement when the currently mapped source 
is one of the sources listed in the MCC declaration, and only for 
switched captures, not mixed ones.

* Section 4.4: Dynamic Mapping

I think there should be some discussion of how often the mid needs to be 
included in the RTP packets. IIUC it is not needed in all packets, so 
the cost is not too high.

* Section 4.5: Recommendations

This could be clearer. I think a receiver SHOULD support BUNDLE, and if 
so MUST support *receiving* mid in RTP and RTCP, and using it to map 
packets to m-lines. A sender SHOULD support BUNDLE, and MUST use mid if 
bundling m-lines that require mid to be unambiguously associate packets 
to m-lines.

	Thanks,
	Paul

On 10/18/14 5:16 PM, [email-masked] wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>