Re: [rtcweb] #27: Section 6.2 FEC

["rtcweb issue tracker" <[e-mail]>]

#27: Section 6.2 FEC


Comment (by [e-mail]):

 [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.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-rtcweb-rtp-
  [e-mail]          |  [e-mail]
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:  milestone1
Component:  rtp-usage                |     Version:  1.0
 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/27#comment:1>
rtcweb <http://tools.ietf.org/rtcweb/>