Change:
While reading the document, I wrote down the following notes that the editor may take into account when revising the document: in 3.1, expland SSRC on first usage and say that this is about sending streams over RTP somewhere early on (I assume this is implied by using the term WebRTC but for outsiders like me it may help to be more specific). Acknowledged. stylistic: I am not a big fan of using citations like '[RFC2198]' as ordinary words or nouns, it makes text difficult to follow unless you know the RFC numbers by heart and your brain translates them back to something meaningful on the fly. This makes texts more difficult to read for outsiders. Example: This mechanism is similar to the [RFC2198] mechanism described above. I prefer this: This mechanism is similar to the redundant encoding mechanism described above. There are couple of such usages of [RFCXXXX] in the document OK. add reference for PCMU OK. Reminder to self, RFC 5391.

Discussion:
FEC describes the sending of redundant information in an outgoing packet stream so that information can still be recovered even in the <del> face of packet loss.  There are multiple ways in which this can be accomplished; this section enumerates the various mechanisms and describes their tradeoffs. </del> <ins> face of packet loss.  There are multiple ways this can be accomplished for RTP media streams RFC3550; this section enumerates the various mechanisms available and describes their tradeoffs. </ins> 3.1. This approach, as described in RFC5956, Section 4.3, sends FEC <del> packets as an independent SSRC-multiplexed stream, with its own SSRC and payload type.  While this approach can protect multiple packets of the primary encoding with a single FEC packet, each FEC packet will have its own IP+UDP+RTP+FEC header, and this overhead can be excessive in some cases, e.g., when protecting each primary packet with a FEC packet. </del> <ins> packets as an independent RTP stream with its own synchronization source (SSRC, RFC3550) and payload type, multiplexed with the primary encoding.  While this approach can protect multiple packets of the primary encoding with a single FEC packet, each FEC packet will have its own IP+UDP+RTP+FEC header, and this overhead can be excessive in some cases, e.g., when protecting each primary packet with a FEC packet. </ins> This approach allows for recovery of entire RTP packets, including the full RTP header. 3.2. <del> This approach, as descibed in RFC2198, allows for redundant data to </del> <ins> This approach, as described in RFC2198, allows for redundant data to </ins> be piggybacked on an existing primary encoding, all in a single packet.  This redundant data may be an exact copy of a previous packet, or for codecs that support variable-bitrate encodings,

For AMR/AMR-WB, packets can contain copies or lower-quality encodings of multiple prior audio frames.  This mechanism is similar to the <del> RFC2198 mechanism described above, but as it adds no additional framing, it can be slightly more efficient.  See RFC4867, </del> <ins> redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient.  See RFC4867, </ins> Section 3.7.1 for details on this mechanism. In-band FEC mechanisms cannot recover any of the RTP header.

4.1. <del> When using variable-bitrate codecs without an internal FEC, RFC2198 redundant encoding with lower-fidelity version(s) of the previous packet(s) is RECOMMENDED.  This provides reasonable protection of the payload with only moderate bitrate increase, as the redundant encodings can be significantly smaller than the primary encoding. </del> <ins> When using variable-bitrate codecs without an internal FEC, redundant encoding (as described in redundant-encoding) with lower-fidelity version(s) of the previous packet(s) is RECOMMENDED.  This provides reasonable protection of the payload with only moderate bitrate increase, as the redundant encodings can be significantly smaller than the primary encoding. </ins> When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED.  This provides reasonable protection of the audio stream against individual losses, with minimal overhead.  Note that, as indicated above, the built-in Opus FEC only provides single-frame redundancy; if multi-packet protection is needed, the aforementioned <del> RFC2198 redundancy with reduced-bitrate Opus encodings SHOULD be used </del> <ins> redundant encoding with reduced-bitrate Opus encodings SHOULD be used </ins> instead. When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism is RECOMMENDED.  This provides slightly more efficient protection of <del> the audio stream than RFC2198. </del> <ins> the audio stream than redundant encoding. </ins> <del> When using constant-bitrate codecs, e.g.  PCMU, use of RFC2198 redundant encoding MAY be used, but note that this will result in a potentially significant bitrate increase, and that suddenly increasing bitrate to deal with losses from congestion may actually make things worse. </del> <ins> When using constant-bitrate codecs, e.g., PCMU RFC5391, redundant encoding MAY be used, but this will result in a potentially significant bitrate increase, and suddenly increasing bitrate to deal with losses from congestion may actually make things worse. </ins> Because of the lower packet rate of audio encodings, usually a single packet per frame, use of a separate FEC stream comes with a higher