Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-07 ends 4 June

[Colin Perkins <[e-mail]>]

> On 21 May 2016, at 21:20, Daniel Burnett <[e-mail]> wrote:
> 
> This message announces the start of a 2 week WGLC for draft-ietf-clue-rtp-mapping to review the updated draft. The last call will end at midnight on Saturday, 4 June 2016.
> 
> PLEASE REVIEW NOW.

Apologies for the late review. I’ve read this draft, and have a number of comments, mostly from an RTP perspective:

Section 3, paragraph starting “In the Selective Forwarding Middlebox (SFM) [RFC7667] topology”: This paragraph seems inconsistent. It starts by saying “every original source is maintained with an independent RTP identity to every receiver, maintaining separate decoding state“, which suggests each source is passed through as an SSRC, but concludes “[t]he sender may turn the projected sources on and off at any time, depending on which sources it thinks are most relevant for the receiver; this is the primary reason why this topology must act as an RTP mixer”, which (if “the sender” actually means the middlebox) suggests the sources are projected as CSRCs on a stream generated by the middlebox (if “the sender” means the original sender, then I don’t understand the intent).

Section 3, bullet 1 (“The middlebox may either use”): in both cases, should this mandate that the middlebox generates RTCP for the streams it’s distributing?

Section 3, bullet 2 (“The middlebox terminates”): does this need to specify that the middlebox forwards/rewrites RTCP for each source distributed as a CSRC?

Section 4, 2nd paragraph, seems to confuse RTP sessions with signalling contexts. The RTP session is always distinguished by having a shared SSRC/CSRC space. This doesn’t change due to the signalling, although the signalling determines which RTP flows are visible at a particular participant, and hence share an SSRC space and form a single RTP session.

Section 4: what is meant by “session multiplexing” and “SSRC multiplexing”? I strongly suggest avoiding these terms, since they don’t have a clear definition. 

Section 4: what is a static SSRC? Should this be “an SSRC signalled using the a=ssrc: line [RFC 5576]”?

In general, I find Section 4 very difficult to follow, and am not sure I could implement it from the text. It might be easier to read if the review of related documents and requirements are moved to an appendix, and the main text simply gives a statement of what should be done.

Section 4.5: the requirement that endpoints “MUST support and use” BUNDLE and a=mid is vague. What is being bundled, and when? 

Section 4.5: what do middleboxes do? I’m surprised there is no requirement here. 

Section 5: as with section 4, this might be clearer if the requirements for the solution were separated from the discussion of what an implementation has to do.

Section 6: it’s not clear how CaptureId relates to mid, why both are needed, and how this relates to the mechanisms in section 4? I haven’t followed all the details of CLUE, so perhaps this just needs a reference to an appropriate definition/discussion in one of the other documents?

Colin



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