Section 6.2 FEC

[bernard_aboba@…]

There are several block-based FEC schemes that are designed for use
with RTP independent of the chosen RTP payload format. At the time
of this writing there is no consensus on which, if any, of these FEC
schemes is appropriate for use in the WebRTC context. Accordingly,
this memo makes no recommendation on the choice of block-based FEC
for WebRTC use.

[BA] While I realize that it is not easy to decide on which FEC scheme is appropriate for WebRTC, including a recommendation on retransmission but not FEC is problematic.

[bernard_aboba@…]

[Magnus Westerlund]

Bernard, this is the WG consensus that we so far have arrived on. If you
have a proposal regarding FEC, please make it and lets see if we can
reach consensus on such a proposal.

However, I fail to see how this is generally problematic. Retransmission
will cover certain parts of the deployment cases when the transport RTT
and delay does not prevent it from being able to repair in a timely
fashion. FEC clearly covers transport characteristics where
retransmission will show its shortcomings. If one want improved
transport performance in those cases clearly a common implemented FEC
solution is desired.

[BA] FEC is discussed in Sections 1.1.7 and 3.3 of draft-roach-mmusic-unified-plan, with examples how it might be declared using SDP, so I found it a bit odd that draft-ietf-rtcweb-rtp-usage only had recommendations for RTX, not FEC. For example, Section 1.1.7 says:

For robust applications, techniques like RTX and FEC are used to
protect media, and simulcast/layered coding can be used to provide
support to heterogeneous receivers. It needs to be possible to
support these techniques, allow the recipient to optionally use or
not use them on a source-by-source basis; and for simulcast/layered
scenarios, to control which simulcast streams or layers are received.

Here is what Section 3.3 says:

3.3. Handling of Simulcast, Forward Error Correction, and

Retransmission Streams

Simulcast refers to taking a single capture (e.g., a camera), and
encoding it multiple times at different resolutions and / or frame
rates. For example, a device with a single HD camera may send one
version of the video at full HD resolution, and a second version
encoded at a low resolution. This would allow a video conferencing
bridge to be able to send the high resolution copy to some
destination and low resolution copy to other destinations without
having to recode the video at the conference bridge.

Forward Error Correction (FEC) and Retransmission (RTX) streams are
techniques that can provide stream robustness in the face of packet
loss. These approaches frequently make use of different payload
types and different SSRC values than the stream to which they apply.

In cases where a media source needs to correspond to more than one
RTP flow, e.g. RTX, FEC, or simulcast, the a=ssrc-group [RFC5576]
concept is used to create a grouping of SSRCs for a single media
stream track. Each SSRC is declared using a=ssrc attributes, the
same MSID is shared between the SSRCs, and the a=ssrc-group attribute
defines the behavior of the grouped SSRCs.

These groupings are used to perform demux of the incoming RTP streams
and associate them (by SSRC) with their primary flows (modulo the
behavior described in Section 3.2.1, if applicable). This
multiplexing of RTX and FEC in a single RTP session is already well-
defined; RTX SSRC-multiplexing behavior is defined in [RFC4588], and
FEC SSRC-multiplexing behavior is defined in [RFC5956].

Note that both RTC and FEC also include SDP expressions that use
different m= lines for the correction streams (cf. [RFC4588],
section 8.7 and [RFC5956], section 4.2). These formats intend for
correlation of streams to be based on transport addresses, which is
inapplicable for bundled media streams. Our specific proposal is:
(1) bundling implementations will never generate such a format; and
(2) bundling implementations MAY choose to accept SDP in such a
format or MAY simply reject the repair streams and proceed as if the
indicated repair format is not supported.

For multi-resolution simulcast, we can create a similar ssrc-group,
and adapt the imageattr attribute defined in [RFC6236] for the a=ssrc
line attribute to indicate the send resolution for a given simulcast
stream. (This will be added to
[I-D.westerlund-avtcore-rtp-simulcast], as outlined in Section 2,
bullet 1). In the example below, the SDP advertises a simulcast of a
camera source at two different resolutions, as well as a screen-share
source that supports RTX; a=ssrc-group is used to correlate the
different SSRCs as part of a single media source.

Note that a characteristic of this approach is that it does not allow
for independently setting attributes for simulcast, FEC, and RTX
streams aside from those in fmtp. In particular, attributes such as
ptime and framerate are shared between the streams that are grouped
together for a simulcast group.

m=video 62537 RTP/SAVPF 96 main video
a=msid:ma ta
a=extmap:1 urn:ietf:params:rtp-hdrext:stream-correlator 15955
a=mid:1
a=rtpmap:96 VP8/90000
a=sendrecv
a=rtcp-mux
a=ssrc:29154 imageattr:96 [x=1280,y=720]
a=ssrc:47182 imageattr:96 [x=640,y=360]
a=ssrc-group:SIMULCAST 29154 47182
m=video 0 RTP/SAVPF 96 97 slide video
a=msid:ma tb
a=extmap:1 urn:ietf:params:rtp-hdrext:stream-correlator 26267
a=mid:2
a=rtpmap:96 VP8/90000
a=rtpmap:97 rtx/90000
a=sendrecv
a=rtcp-mux
a=fmtp:97 apt=96;rtx-time=3000
a=ssrc:45982
a=ssrc:9827
a=ssrc-group:FID 45982 9827 FID provides SSRC correlation
a=bundle-only

Providing explicit resolutions on a per-SSRC basis for SIMULCAST
groupings allows an intermediary (such as a Media Translator
[RFC5117]) to be able to select an appropriate SIMULCAST layer
without inspecting the media stream, which could otherwise require
decrypting and possibly partially decoding media packets.