[rtcweb] Review, RTP recommendations - draft-ietf-rtcweb-rtp-usage-03

[Harald Alvestrand <[e-mail]>]

At the interim, I promised to make more precise my objections to some of 
the language of this I-D. I'm taking the opportunity to read through the 
whole document and give commentary.
I hope this is helpful.

- Section 2, rationale: Should add that an important driver for the 
profile is to rule things OUT of scope - that features not mentioned 
here are not required for successful RTCWEB interoperation.

- Section 3, terminology: This should reference the RTP document and the 
rtcweb-overview document. There are lots of terms that come from there.

In particular, the term "media stream" needs to be called out, since a 
WebRTC "MediaStream" is not the same as an RTP "media stream", and both 
are used in this document. I suggest consistently using the terms 
"WebRTC MediaStream" (prefix, no space) and "RTP media stream" (prefix, 
with space) for the two concepts, and explicitly never using the term 
"media stream" without a prefix.

- Section 4.7 Symmetric RTP/RTCP: Between -02 and -03, I see that 
support for symmetric RTP/RTCP has been changed from

    Using Symmetric RTP and RTCP [RFC4961] is REQUIRED.

to

    implementations are
    REQUIRED to implement Symmetric RTP [RFC4961]

Reading RFC 4961, I see that it states:

    A device supports symmetric RTP if it selects, communicates, and uses
    IP addresses and port numbers such that, when receiving a
    bidirectional RTP media stream on UDP port "A" and IP address "a", it
    also transmits RTP media for that stream from the same source UDP
    port "A" and IP address "a".

So it's impossible to support RFC 4961 without using it, and the 
formulations are equivalent. But that's such a novel concept among the 
usual universe of RTP extensions that it's worth calling out explicitly.

It might even be beneficial to say that it's OK to not interoperate with 
devices that don't do RFC 4961.

- Section 4.8 RTCP CNAME generation - as discussed at the interim, it 
might be good to state that support for receiving RFC 6222-style CNAMEs, 
as well as RFC 3550-style names, is required.

- Section 5.1 states that RTP Transport Translators "are expected to be 
supported". RTP Transport Translators require that call setup be 
coordinated across all endpoints in the session to avoid clashing 
payload types, as discussed in the multiplex draft. I'm OK with a 
formulation that says that "this RTP profile should be able to support 
all these topologies, if supported by appropriate signallling", but I'm 
not OK with a formulation that absolutely requires signalling support 
for RTP Transport Translators; I'm not at all confident that we can 
successfully negotiate RTP Transport Translator-based applications for 
all cases.

- Section 5.1.5 TMMBR - should we say explicitly that the sender is 
expected to honor the constraint?

- Section 7.4 Legacy Interop Limitations (for congestion) seems like a 
work in progress. We'll discuss this more in the congestion context, but 
the "it's been suggested ... send 64 Kbits/sec" at the bottom should 
definitely not be stated like this in the final document.

- Section 11.1 "However, one SSRC  will identify a media stream and its 
timing. " - I think in this case, "WebRTC MediaStream" is the intended 
usage.

- Section 12.1 and 12.2 - in this section, I think all the uses of 
"media stream" refer to "RTP media stream".

I can't parse the grammar of "In addition the above discussed
    criteria to support multiple media types in one single RTP session
    results that also an end-point that has one audio and one video
    source still need two transmit using two SSRCs concurrently" - I 
think it's trying to say that when audio and video go into the same RTP 
session, they use different SSRCs.

- Section 12.3 is not very clear to me. I'm not sure I would agree with 
it if it was clear; the "relay" described here is probably an RTP 
Transport Translator, but if it is, it should be called that.

This is a quick pass, where I have focused on sections 1-7. There are 
many formulation issues, and some of them may hide technical 
disagreements. But on the whole, I think this document is very close to 
saying most of the things that need to be said.

                          Harald