[rtcweb] Comments on draft-lennox-rtcweb-rtp-media-type-mux-00

[Magnus Westerlund <[e-mail]>]

Hi,

(as individual)

I have reviewed draft-lennox-rtcweb-rtp-media-type-mux-00 and have some
comments.

I think this document is most appropriately discussed in AVTCORE as it
concerns RTP details. Therefore both lists are cc:ed and reply-to set to
AVTCORE WG mailing list. So if you are on RTCWEB and would like to
follow this discussion, please follow the AVTCORE mailing list also
([e-mail]).

1. I think the biggest issue with multiple media type in a single RTP
session isn't discussed. I think it is very important that this issue is
brought up as it has to do with the applicability of this solution.

To start the discussion on this issue I think a quote from section 4.3
of draft-westerlund-avtcore-transport-multiplexing-01 is appropriate:

   Many transition scenarios use an RTP translator as a gateway between
   a single RTP session containing multiple media types multiplexed
   together, and several separate RTP sessions each using a single media
   type.  In this scenario, it is possible that a legacy device that
   uses one RTP session for each media type will use the same SSRC in
   each session.  When translating these into a single RTP session, it
   will be necessary to rewrite one of the SSRCs, so that each stream
   has a unique SSRC.  This SSRC translation process is straight-forward
   for RTP packets, but is very complex for RTCP packets.  It also
   hinders innovation, since such a gateway will not be able to
   translate new RTCP extensions that it is unaware of, even if they are
   supported by devices on both sides of the gateway.

The issue is that in any case where you have a desire to mix end-points
supporting this and where some don't you create a situation where you
will either get malfunctioning translators or translators that likely
are a barrier for deploying new RTP/RTCP extensions.

Even in WebRTC contexts the case combing the single session and multiple
sessions are likely to occur. One case is media plane gateways to legacy
that will negotiate the multiplexing between the WebRTC end-point and
the gateway and then attempt to perform basic splitting to two RTP
sessions on the legacy side based on the payload formats. Another
scenario is the centralized conferences where the RTP mixer or
translator can negotiate individual behavior to each end-point. Thus one
might start out fine with all being single session compliant. Then
someone joins who is not and the result is that one is in a situation
that either requires renegotiation (including NAT traversal) for the
already connected end-points or to do a translator. I am certain that
translator is going to be the approach rather than interrupting the
ongoing media streams.

So yes this would not be an issue if everyone supported it. But it is
clear that the world will be one of incremental deployment. So I am
quite worried on the future impact using a single RTP session creates. I
think RTCWEB needs to seriously consider if this really is the right way
to go or if another solution would be better.

2. Section 7.2.9 of draft-westerlund-avtcore-multiplex-architecture-00
discusses a number of aspects of this type of multiplexing. I think the
document covers most in a reasonable fashion. The ones that seems to be
missing are;

A) the number space limitation of the PT field. The 128 values should
after all cover all the RTP payload configurations one like to use/offer
+ the RTCP payload type overlap due to RTP/RTCP multiplexing. So the
fact that the real limitations in RTP payload types are in fact that all
media types need to share in 96+ available payload type values rather
than 128 per each media type.

B) I think the bit-rate issues could be improved but it is present.

C) Decomposited end-points are missing. This is not a big issue, only a
down side with this that increases the bit-rate to the actual functional
end-points and require them to have handling of the multiple media
types. So this is a limitation if one attempt to use this in a
Telepresence scenario with dedicated hardware, not an issue in a browser
context.

3. Section 3:
   For sessions using the RTP/AVPF [RFC4585] and RTP/SAVPF [RFC5124]
   profiles, however, endpoints SHOULD set the minimum RTCP regular
   reporting interval trr-int to 5000 (5 seconds), unless they
   explicitly need it to be lower.  This minimizes the excessive RTCP
   bandwidth consumption, as well as aiding compatibility with AVP
   endpoints.  Since this value only affects regular RTCP reports, not
   RTCP feedback, this does not prevent AVPF feedback messages from
   being sent as needed.

When AVP compatibility is the goal, I think 5 seconds is mostly ok. The
regular RTCP suppression algorithm has a bit of strange behavior in
cases where the Td value becomes similar to the T_rr_interval. That as
the scheduled transmission time of an regular RTCP packet might close to
the randomized value of the T_rr_interval but still smaller, that can in
worst case result in that the AVPF RTCP sender sends RTCP some cases
with close 2*T_rr_interval but no more often than 0.5*T_rr_interval.
Thus the median of the distribution gets skewed towards higher value
than T_rr_interval. I will send a separate email about this as it
requires a bit of graphs and more in detail discussion.

4. Section 3.1:

"An endpoint MAY choose to send multiple sources' RTCP messages in a
   single compound RTCP packet (though such compound packets SHOULD NOT
   exceed the path MTU, if avoidable and if it is known)."

I think this recommendation is appropriate but I think should likely
become a general recommendation for RTCP. However, that clearly requires
some feedback if it will fail with some implementations. And if it does,
I think that signalling support may be necessary. If that is the case,
this optimization can't be used when working in the separate RTP session
mode in WEBRTC, thus causing a situation where WebRTC end-points needs
to have a run-time switch to control if this is used or not.

5. Section 3.1:
   Regular (non-
   feedback) RTCP compound packets MUST still begin with an SR or RR
   packet, but otherwise may contain RTCP packets in any order.
   Receivers MUST be prepared to receive such compound packets.

I think this needs to make clear that for each SSRC include, both SR/RR
and the corresponding SDES CNAME items MUST be included.

6. Section 3.1:
  "An endpoint SHOULD NOT send reception reports from one of its own
   sources about another one ("cross-reports")."

This topic should also likely be discussed if it should be a general
clarifications to RFC3550. That includes how one determines what is the
considered the same end-point and what implications it provides. Is it
based on all SSRCs with the same CNAME in an end-point SHOULD NOT send
report blocks from more than one?

I do note that all SSRC still needs to send an SR or an RR(possibly
empty) just to announce there presence in the RTP session.

7. Section 3.1:
Similarly, an endpoint sending multiple sources SHOULD NOT send
   reception reports about a remote source from more than one of its
   local sources.

The same comments as for 6) applies to this.

8. Section 4:
   The more difficult case is if an offerer cannot reply on its
   potential peers supporting any features beyond baseline RTP (i.e.,
   neither ICE nor multiplexing).

I don't think this becomes a real issue if one assumes the offer
following the signalling as defined by
https://datatracker.ietf.org/doc/draft-holmberg-mmusic-sdp-bundle-negotiation/

9. Section 5:

So we do now have two proposals on the table for how to signal this. One
in
https://datatracker.ietf.org/doc/draft-holmberg-mmusic-sdp-bundle-negotiation/
(BUNDLE) and one in this document (Lennox).

A comparison is quite interesting.

BUNDLE will have very straightforward back-wards compatibility as that
can happen in the single offer/answer exchange. However, there exist no
way of forcing the usage of BUNDLE.

Lennox requires a new Offer if the peer doesn't support this. In
addition it creates a SDP media type that isn't supposed to be used with
MIME. That is likely going to be an interesting to execute. It does
allow for mandating support and refusing to establish a session not
compliant. In addition it reduces the risk of confusion around payload
types as they are only listed on a single media description.

I personally prefer the BUNDLE approach.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------