Subject: [clue] WGLC for draft-ietf-clue-rtp-mapping-06 ends 18 March

From: Daniel Burnett <[email-masked]>
Date: Tue, 8 Mar 2016 14:35:52 -0500

This message announces the start of a 1.5 week WGLC for draft-ietf-clue
-rtp-mapping. The last call will end at midnight on Friday, 18 March 2016
to allow time for a rev before the 21st.

PLEASE REVIEW NOW.

-- Dan (for the Chairs)

---

From: Christian Groves <[email-masked]>
Date: Wed, 9 Mar 2016 19:31:19 +1100

Hello,

I didn't see any major issues. Mostly all editorial. Here are my comments:

General: The draft should settle on one form for "Media Capture" 
sometimes its "media Capture" sometimes "capture" etc.

Clause 1 para 1: Add (MC) after first usage of Media Capture.

Clause 1 para 3: Define MCU on first usage.

Clause 1 para 3: "... RTP[RFC3550] media streams...", Should “media” be 
removed to align with “RTP Stream” from rfc7656#section-2.1.10?

Clause 1 para 4: I think the draft should talk about "CLUE" architecture 
rather than "telepresence" architecture.

Clause 1 para 5: CLUE supports audio, video AND "text". We should add 
"text" to the usages of "audio and video" in the draft.

Clause 3 para 1: The clause introduces various RTP topologies, we should 
use the names as specified in RFC7667 with the same capitalisation etc., 
e.g. Media-Mixing Mixers. Later on in the draft it starts using the 
short names e.g. topo-mixer. Perhaps the draft should use the full name 
and short name on first usage and then use the sort name from then on?

Clause 3 para 2: Add "... is point-to-point may nonetheless have <an> 
RTP stream
    which..."

Clause 3 para 3: Change "available" to "determined" in "....media and 
media-id (SSRC) can be
    <determined> using the conference..."

Clause 4 para 2: Delete two words "...For example, main and slides video 
sources are
    separated into <> RTP sessions based on the content attribute 
[RFC4796].  This solution <> is straightforward if the multiplexing ..."

Clause 4 para 3: I don't think CLUE "recommends" using BUNDLE. 
draft-ietf-clue-signaling-07#section-7.1 indicates CLUE “MAY” support 
BUNDLE. The paragraph should be reworded accordingly. e.g. /"Even though 
Session multiplexing is supported by CLUE, for scaling reasons, CLUE 
indicates that SSRC multiplexing in a single or multiple sessions using 
[I-D.ietf-mmusic-sdp-bundle-negotiation] may be used. When SSRC 
multiplexing is used, the mapping of  RTP streams to Captures Encodings 
needs to be considered."/

Clause 4 2nd last para: Should clean up the use of MCU/Mixer, some 
places its MCU / Mixer other Mixer/MCU etc. Also TelePresence should be 
Telepresence.

Clause 4.1 1st para: Delete word "This section provides an overview of 
the RFCs and drafts that <> can be used in a..."

Clause 4.1 para 5: This needs some reword. "It" seems to refer to the 
image attribute offerring separate RTP sessions.

Clause 4.1 last para: Is this paragraph needed? Sounds more like 
something you'd see in a contribution rather than a specification.

Clause 4.4 para 1: Add "Dynamic mapping <is achieved> by tagging..."

Clause 4.4 para 3: "However, the disadvantage in using a mid in the 
stream <is> that it..."

Clause 4.4 para 4: "In this case, <it> may require up to an additional 
12 bytes in the RTP header..."

Clause 4.4 para 4: Whilst its true there's significant bandwidth 
increase for very low bandwidth audio codecs are these really candidates 
to be used for Telepresence/CLUE which would imply a higher quality codec.

Clause 4.5: Add "s" to "CLUE endpoints" and delete leading "[" on the 
reference.

Clause 5 para 1: Duplicated word "section Section".

Clause 5: The section talks about "mid". Is this the "mid" used in the 
CLUE group or? E.g. a CLUE controlled m-line may also have a mid used 
for BUNDLE.

Clause 6 para 1: I propose rewording slightly to clarify the use:
/For MCCs which can represent multiple switched MCs there is a need to//
//   know which MC represents the current RTP stream<.> This requires a 
mapping//
//   from an RTP stream to an MC.  In order to address this mapping this//
//   document defines an RTP header extension that includes the CaptureID//
//   in order to map to the original MC allowing the consumer to use the//
//   <original source> MC attributes like the spatial information.  The 
media provider MUST//
//   send for MCC <Capture encodings> the captureID of the current MC in 
the RTP header and as//
//   a RTCP SDES message./

Clause 6.1 Header figure: The separator "|" for ID seems to be in the 
wrong place. It should be between the 7 and 8 not under 9. Also should 
we include a note for the RFC editor to replace the XXX?

Clause 6.2 Header figure: The separator "|" for ID seems to be in the 
wrong place. It should be between the 7 and 8 not under 9. There's a 
similar issue for the next separator. Also "Len-1" I think can simply be 
"Length". The second instance of "CaptureId" could be deleted. Also 
should we add how the CaptureID (IDRef) is encoded, i.e. UTF-8 text?

Clause 6.2: Missing letter " Packets tagged by the sender with the 
Captur<e>Id then contain a header extension as shown below..."

Clause 7: The "composed" and "switched" attributes should be removed as 
they are no longer defined in the framework. I think this is also an 
issue for the protocol document.

Clause 7: If understand the example "MaxCaptures" I think should be "3" 
to indicate switched and composition. Not "1" which indicates switching.

Regards, Christian

On 9/03/2016 6:35 AM, Daniel Burnett wrote:
> This message announces the start of a 1.5 week WGLC for 
> draft-ietf-clue-rtp-mapping. The last call will end at 
> midnight on Friday, 18 March 2016 to allow time for a rev before the 21st.
>
> PLEASE REVIEW NOW.
>
> -- Dan (for the Chairs)
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 9 Mar 2016 17:43:11 -0500

> midnight on Friday, 18 March 2016 to allow time for a rev before the 21st.

In general I find this draft to be in good shape. I saw that Christian 
already offered a lot of editorial comments. I won't try to compete with 
that. I did find a few things:

* General:

There are assorted language problems with articles, plurals, etc. I 
didn't try to note them.

* Section 4.1:

There are a couple of instances of 
[I-D.ietf-mmusic-sdp-bundle-negotiation] and one instance of [bundle] 
that isn't linked. I expect they should all be the same. It would 
improve readability if you used mnemonic tags for the references (e.g. 
[bundle]) rather than the default.

It seems this is logically a list of "tools". It would read better if it 
were formatted as a list. As it is, it isn't obvious which paragraphs 
start new list items.

* Section 5:

    This can be done by a Selective Forwarding middlebox, but not by a
    Switching Mixer.  The last requirement can be accomplished through an
    FIR message [RFC5104], though potentially a faster mechanism (not
    requiring a round-trip time from the receiver) would be preferable.

I don't see how the final comment on a faster mechanism is helpful in 
the document at this point.

I don't know how to take:

    For a Selective Forwarding middlebox, this may be a problem since an
    encoding can be used by a single MC, it will require using the same
    SDP label for multiple MC (example middle camera and active speaker
    MC) this can also be done for an environment with a hybrid of mixer
    topologies and static and dynamic captures.

If using the same label for multiple MC is a solution, then why might 
there be a problem? OTOH, if that usage isn't defined, then why is it 
suggested? (I am unsure whether this usage is allowed.)

	Thanks,
	Paul

---

From: Colin Perkins <[email-masked]>
Date: Wed, 16 Mar 2016 22:58:56 +0000

> On 8 Mar 2016, at 19:35, Daniel Burnett <[email-masked]> wrote:
> 
> This message announces the start of a 1.5 week WGLC for draft-ietf-clue-rtp-mapping. The last call will end at midnight on Friday, 18 March 2016 to allow time for a rev before the 21st.

I’ve reviewed this draft, and have a number of comments. Most of these relate to how RTP sessions are used, and to terminology. In particular, in section 3, and likely elsewhere, the draft uses the term “mixer” to refer to something that is clearly not a mixer in the RTP sense. The terminology needs to be corrected. 

Details:

Section 3: some diagrams might help illustrate the various options.

Section 3, 2nd paragraph: for clarity, I suggest changing “There can be one or more RTP sessions, and each RTP session can carry multiple RTP streams identified by their SSRC” to “There can be one or more RTP sessions, each sent on a separate 5-tuple, and having a separate SSRC space, with each RTP session carrying multiple RTP streams identified by their SSRC”.

Section 3, 4th paragraph: how does the mixer handle RTCP? That is, does it forward RTCP for the SSRCs that it sends as CSRCs, or not? 

Section 3, 5th paragraph: what is meant by “In the Selective Forwarding middlebox topology, the peer to mixer communication is unicast with RTCP mixer feedback”? Is this intending to say that there is a separate unicast RTP session on between each peer and the mixer? If so, the terminology “mixer” is incorrect: a mixer is a well-defined RTP concept, that shares a single RTP session.

Section 3, 5th paragraph: what is meant by “projected”? The draft doesn’t define this operation, or explain what the middlebox has to do to project an SSRC. I assume this is some sort of back-to-back pair of RTP sessions, but it’s not explained.

Section 3, 5th paragraph: RTCP is terminated by the “mixer”, but SSRCs are “projected”. What is done about RTCP for the projected SSRCs?

Section 3, 1st bullet point: “The mixer may either use the source SSRC when forwarding RTP packets, or use its own created SSRC” is unclear. A middlebox that is acting as an RTP mixer will always use its own SSRC, and include the SSRC of the mixed streams as the CSRC; this happens even if it’s only forwarding a single RTP stream. If the middlebox forwards packets with their original SSRC, it’s not an RTP mixer. The terminology needs fixing.

Section 3, 2nd bullet point: “The mixer terminates the RTCP from the source, creating separate RTP sessions with the peers” - this is not how an RTP mixer works. The terminology needs to be fixed. 

Section 4.5, Media-7, 2nd paragraph: a mixer always provides CSRCs, so this requirement is unclear.

-- 
Colin Perkins
https://csperkins.org/

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 18 Mar 2016 18:12:28 -0700

I reviewed the document again. I don’t have anything to add to the suggestions other reviewers have already made.

Mark

From: clue [mailto:[email-masked]] On Behalf Of Daniel Burnett
Sent: Tuesday, March 08, 2016 2:36 PM
To: [email-masked]
Subject: [clue] WGLC for draft-ietf-clue-rtp-mapping-06 ends 18 March

PLEASE REVIEW NOW.

-- Dan (for the Chairs)