idnits 2.17.00 (12 Aug 2021) /tmp/idnits43294/draft-ietf-rtcweb-fec-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jul 16, 2019) is 1033 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-payload-flexible-fec-scheme has been published as RFC 8627 == Outdated reference: draft-ietf-mmusic-sdp-bundle-negotiation has been published as RFC 8843 == Outdated reference: draft-ietf-rtcweb-data-channel has been published as RFC 8831 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Uberti 3 Internet-Draft Google 4 Intended status: Standards Track Jul 16, 2019 5 Expires: January 17, 2020 7 WebRTC Forward Error Correction Requirements 8 draft-ietf-rtcweb-fec-10 10 Abstract 12 This document provides information and requirements for how Forward 13 Error Correction (FEC) should be used by WebRTC implementations. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 17, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Types of FEC . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3.1. Separate FEC Stream . . . . . . . . . . . . . . . . . . . 3 53 3.2. Redundant Encoding . . . . . . . . . . . . . . . . . . . 3 54 3.3. Codec-Specific In-band FEC . . . . . . . . . . . . . . . 3 55 4. FEC for Audio Content . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 4 57 4.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 5 58 5. FEC for Video Content . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 5 60 5.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 6 61 6. FEC for Application Content . . . . . . . . . . . . . . . . . 6 62 7. Implementation Requirements . . . . . . . . . . . . . . . . . 7 63 8. Adaptive Use of FEC . . . . . . . . . . . . . . . . . . . . . 7 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 12.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 11 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 In situations where packet loss is high, or perfect media quality is 76 essential, Forward Error Correction (FEC) can be used to proactively 77 recover from packet losses. This specification provides guidance on 78 which FEC mechanisms to use, and how to use them, for WebRTC 79 implementations. 81 2. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 85 "OPTIONAL" in this document are to be interpreted as described in BCP 86 14 [RFC2119] [RFC8174] when, and only when, they appear in all 87 capitals, as shown here. 89 3. Types of FEC 91 FEC describes the sending of redundant information in an outgoing 92 packet stream so that information can still be recovered even in the 93 face of packet loss. There are multiple ways this can be 94 accomplished for RTP media streams [RFC3550]; this section enumerates 95 the various mechanisms available and describes their tradeoffs. 97 3.1. Separate FEC Stream 99 This approach, as described in [RFC5956], Section 4.3, sends FEC 100 packets as an independent RTP stream with its own synchronization 101 source (SSRC, [RFC3550]) and payload type, multiplexed with the 102 primary encoding. While this approach can protect multiple packets 103 of the primary encoding with a single FEC packet, each FEC packet 104 will have its own IP+UDP+RTP+FEC header, and this overhead can be 105 excessive in some cases, e.g., when protecting each primary packet 106 with a FEC packet. 108 This approach allows for recovery of entire RTP packets, including 109 the full RTP header. 111 3.2. Redundant Encoding 113 This approach, as described in [RFC2198], allows for redundant data 114 to be piggybacked on an existing primary encoding, all in a single 115 packet. This redundant data may be an exact copy of a previous 116 payload, or for codecs that support variable-bitrate encodings, 117 possibly a smaller, lower-quality representation. In certain cases, 118 the redundant data could include encodings of multiple prior audio 119 frames. 121 Since there is only a single set of packet headers, this approach 122 allows for a very efficient representation of primary + redundant 123 data. However, this savings is only realized when the data all fits 124 into a single packet (i.e. the size is less than a MTU). As a 125 result, this approach is generally not useful for video content. 127 As described in [RFC2198], Section 4, this approach cannot recover 128 certain parts of the RTP header, including the marker bit, CSRC 129 information, and header extensions. 131 3.3. Codec-Specific In-band FEC 133 Some audio codecs, notably Opus [RFC6716] and AMR [RFC4867], support 134 their own in-band FEC mechanism, where redundant data is included in 135 the codec payload. This is similar to the redundant encoding 136 mechanism described above, but as it adds no additional framing, it 137 can be slightly more efficient. 139 For Opus, audio frames deemed important are re-encoded at a lower 140 bitrate and appended to the next payload, allowing partial recovery 141 of a lost packet. This scheme is fairly efficient; experiments 142 performed indicate that when Opus FEC is used, the overhead imposed 143 is only about 20-30%, depending on the amount of protection needed. 144 Note that this mechanism can only carry redundancy information for 145 the immediately preceding audio frame; as such the decoder cannot 146 fully recover multiple consecutive lost packets, which can be a 147 problem on wireless networks. See [RFC6716], Section 2.1.7, and this 148 Opus mailing list post [OpusFEC] for more details. 150 For AMR/AMR-WB, packets can contain copies or lower-quality encodings 151 of multiple prior audio frames. See [RFC4867], Section 3.7.1 for 152 details on this mechanism. 154 In-band FEC mechanisms cannot recover any of the RTP header. 156 4. FEC for Audio Content 158 The following section provides guidance on how to best use FEC for 159 transmitting audio data. As indicated in Section 8 below, FEC should 160 only be activated if network conditions warrant it, or upon explicit 161 application request. 163 4.1. Recommended Mechanism 165 When using variable-bitrate codecs without an internal FEC, redundant 166 encoding (as described in Section 3.2) with lower-fidelity version(s) 167 of the previous packet(s) is RECOMMENDED. This provides reasonable 168 protection of the payload with only moderate bitrate increase, as the 169 redundant encodings can be significantly smaller than the primary 170 encoding. 172 When using the Opus codec, use of the built-in Opus FEC mechanism is 173 RECOMMENDED. This provides reasonable protection of the audio stream 174 against individual losses, with minimal overhead. Note that, as 175 indicated above, the built-in Opus FEC only provides single-frame 176 redundancy; if multi-packet protection is needed, the aforementioned 177 redundant encoding with reduced-bitrate Opus encodings SHOULD be used 178 instead. 180 When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism 181 is RECOMMENDED. This provides slightly more efficient protection of 182 the audio stream than redundant encoding. 184 When using constant-bitrate codecs, e.g., PCMU [RFC5391], redundant 185 encoding MAY be used, but this will result in a potentially 186 significant bitrate increase, and suddenly increasing bitrate to deal 187 with losses from congestion may actually make things worse. 189 Because of the lower packet rate of audio encodings, usually a single 190 packet per frame, use of a separate FEC stream comes with a higher 191 overhead than other mechanisms, and therefore is NOT RECOMMENDED. 193 As mentioned above, the recommended mechanisms do not allow recovery 194 of parts of the RTP header that may be important in certain audio 195 applications, e.g., CSRCs and RTP header extensions like those 196 specified in [RFC6464] and [RFC6465]. Implementations SHOULD account 197 for this and attempt to approximate this information, using an 198 approach similar to those described in [RFC2198], Section 4, and 199 [RFC6464], Section 5. 201 4.2. Negotiating Support 203 Support for redundant encoding of a given RTP stream SHOULD be 204 indicated by including audio/red [RFC2198] as an additional supported 205 media type for the associated m= section in the SDP offer [RFC3264]. 206 Answerers can reject the use of redundant encoding by not including 207 the audio/red media type in the corresponding m= section in the SDP 208 answer. 210 Support for codec-specific FEC mechanisms are typically indicated via 211 "a=fmtp" parameters. 213 For Opus, a receiver MUST indicate that it is prepared to use 214 incoming FEC data with the "useinbandfec=1" parameter, as specified 215 in [RFC7587]. This parameter is declarative and can be negotiated 216 separately for either media direction. 218 For AMR/AMR-WB, support for redundant encoding, and the maximum 219 supported depth, are controlled by the 'max-red' parameter, as 220 specified in [RFC4867], Section 8.1. Receivers MUST include this 221 parameter, and set it to an appropriate value, as specified in 222 [TS.26114], Table 6.3. 224 5. FEC for Video Content 226 The following section provides guidance on how to best use FEC for 227 transmitting video data. As indicated in Section 8 below, FEC should 228 only be activated if network conditions warrant it, or upon explicit 229 application request. 231 5.1. Recommended Mechanism 233 Video frames, due to their size, often require multiple RTP packets. 234 As discussed above, a separate FEC stream can protect multiple 235 packets with a single FEC packet. In addition, the "flexfec" FEC 236 mechanism described in [I-D.ietf-payload-flexible-fec-scheme] is also 237 capable of protecting multiple RTP streams via a single FEC stream, 238 including all the streams that are part of a BUNDLE 239 [I-D.ietf-mmusic-sdp-bundle-negotiation] group. As a result, for 240 video content, use of a separate FEC stream with the flexfec RTP 241 payload format is RECOMMENDED. 243 To process the incoming FEC stream, the receiver can demultiplex it 244 by SSRC, and then correlate it with the appropriate primary stream(s) 245 via the CSRC(s) present in the RTP header of flexfec repair packets, 246 or the SSRC field present in the FEC header of flexfec retransmission 247 packets. 249 5.2. Negotiating Support 251 Support for a SSRC-multiplexed flexfec stream to protect a given RTP 252 stream SHOULD be indicated by including one of the formats described 253 in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1.2, as an 254 additional supported media type for the associated m= section in the 255 SDP offer [RFC3264]. As mentioned above, when BUNDLE is used, only a 256 single flexfec repair stream will be created for each BUNDLE group, 257 even if flexfec is negotiated for each primary stream. 259 Answerers can reject the use of SSRC-multiplexed FEC, by not 260 including the offered FEC formats in the corresponding m= section in 261 the SDP answer. 263 Use of FEC-only m-lines, and grouping using the SDP group mechanism 264 as described in [RFC5956], Section 4.1 is not currently defined for 265 WebRTC, and SHOULD NOT be offered. 267 Answerers SHOULD reject any FEC-only m-lines, unless they 268 specifically know how to handle such a thing in a WebRTC context 269 (perhaps defined by a future version of the WebRTC specifications). 271 6. FEC for Application Content 273 WebRTC also supports the ability to send generic application data, 274 and provides transport-level retransmission mechanisms to support 275 full and partial (e.g. timed) reliability. See 276 [I-D.ietf-rtcweb-data-channel] for details. 278 Because the application can control exactly what data to send, it has 279 the ability to monitor packet statistics and perform its own 280 application-level FEC, if necessary. 282 As a result, this document makes no recommendations regarding FEC for 283 the underlying data transport. 285 7. Implementation Requirements 287 To support the functionality recommended above, implementations MUST 288 be able to receive and make use of the relevant FEC formats for their 289 supported audio codecs, and MUST indicate this support, as described 290 in Section 4. Use of these formats when sending, as mentioned above, 291 is RECOMMENDED. 293 The general FEC mechanism described in 294 [I-D.ietf-payload-flexible-fec-scheme] SHOULD also be supported, as 295 mentioned in Section 5. 297 Implementations MAY support additional FEC mechanisms if desired, 298 e.g., [RFC5109]. 300 8. Adaptive Use of FEC 302 Because use of FEC always causes redundant data to be transmitted, 303 and the total amount of data must remain within any bandwidth limits 304 indicated by congestion control and the receiver, this will lead to 305 less bandwidth available for the primary encoding, even when the 306 redundant data is not being used. This is in contrast to methods 307 like RTX [RFC4588] or flexfec's retransmission mode ( 308 [I-D.ietf-payload-flexible-fec-scheme], Section 1.1.7), which only 309 transmit redundant data when necessary, at the cost of an extra 310 roundtrip and thereby increased media latency. 312 Given this, WebRTC implementations SHOULD prefer using RTX or flexfec 313 retransmissions instead of FEC when the connection RTT is within the 314 application's latency budget, and otherwise SHOULD only transmit the 315 amount of FEC needed to protect against the observed packet loss 316 (which can be determined, e.g., by monitoring transmit packet loss 317 data from RTCP Receiver Reports [RFC3550]), unless the application 318 indicates it is willing to pay a quality penalty to proactively avoid 319 losses. 321 Note that when probing bandwidth, i.e., speculatively sending extra 322 data to determine if additional link capacity exists, FEC data SHOULD 323 be used as the additional data. Given that extra data is going to be 324 sent regardless, it makes sense to have that data protect the primary 325 payload; in addition, FEC can typically be applied in a way that 326 increases bandwidth only modestly, which is necessary when probing. 328 When using FEC with layered codecs, e.g., [RFC6386], where only base 329 layer frames are critical to the decoding of future frames, 330 implementations SHOULD only apply FEC to these base layer frames. 332 Finally, it should be noted that although applying redundancy is 333 often useful in protecting a stream against packet loss, if the loss 334 is caused by network congestion, the additional bandwidth used by the 335 redundant data may actually make the situation worse, and can lead to 336 significant degradation of the network. 338 9. Security Considerations 340 In the WebRTC context, FEC is specifically concerned with recovering 341 data from lost packets; any corrupted packets will be discarded by 342 the SRTP [RFC3711] decryption process. Therefore, as described in 343 [RFC3711], Section 10, the default processing when using FEC with 344 SRTP is to perform FEC followed by SRTP at the sender, and SRTP 345 followed by FEC at the receiver. This ordering is used for all the 346 SRTP Protection Profiles used in DTLS-SRTP [RFC5763], which are 347 enumerated in [RFC5764], Section 4.1.2. 349 Additional security considerations for each individual FEC mechanism 350 are enumerated in their respective documents. 352 10. IANA Considerations 354 This document requires no actions from IANA. 356 11. Acknowledgements 358 Several people provided significant input into this document, 359 including Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, 360 Tim Terriberry, Magnus Westerlund, and Mo Zanaty. 362 12. References 364 12.1. Normative References 366 [I-D.ietf-payload-flexible-fec-scheme] 367 Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP 368 Payload Format for Flexible Forward Error Correction 369 (FEC)", draft-ietf-payload-flexible-fec-scheme-20 (work in 370 progress), May 2019. 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, 374 DOI 10.17487/RFC2119, March 1997, 375 . 377 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 378 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 379 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 380 DOI 10.17487/RFC2198, September 1997, 381 . 383 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 384 with Session Description Protocol (SDP)", RFC 3264, 385 DOI 10.17487/RFC3264, June 2002, 386 . 388 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 389 "RTP Payload Format and File Storage Format for the 390 Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 391 (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, 392 April 2007, . 394 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 395 the Session Description Protocol", RFC 5956, 396 DOI 10.17487/RFC5956, September 2010, 397 . 399 [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format 400 for the Opus Speech and Audio Codec", RFC 7587, 401 DOI 10.17487/RFC7587, June 2015, 402 . 404 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 405 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 406 May 2017, . 408 [TS.26114] 409 3GPP, "IP Multimedia Subsystem (IMS); Multimedia 410 telephony; Media handling and interaction", 3GPP TS 26.114 411 15.0.0, September 2017. 413 12.2. Informative References 415 [I-D.ietf-mmusic-sdp-bundle-negotiation] 416 Holmberg, C., Alvestrand, H., and C. Jennings, 417 "Negotiating Media Multiplexing Using the Session 418 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 419 negotiation-54 (work in progress), December 2018. 421 [I-D.ietf-rtcweb-data-channel] 422 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 423 Channels", draft-ietf-rtcweb-data-channel-13 (work in 424 progress), January 2015. 426 [OpusFEC] Terriberry, T., "Opus FEC", January 2013. 428 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 429 Jacobson, "RTP: A Transport Protocol for Real-Time 430 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 431 July 2003, . 433 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 434 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 435 RFC 3711, DOI 10.17487/RFC3711, March 2004, 436 . 438 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 439 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 440 DOI 10.17487/RFC4588, July 2006, 441 . 443 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 444 Correction", RFC 5109, DOI 10.17487/RFC5109, December 445 2007, . 447 [RFC5391] Sollaud, A., "RTP Payload Format for ITU-T Recommendation 448 G.711.1", RFC 5391, DOI 10.17487/RFC5391, November 2008, 449 . 451 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 452 for Establishing a Secure Real-time Transport Protocol 453 (SRTP) Security Context Using Datagram Transport Layer 454 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 455 2010, . 457 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 458 Security (DTLS) Extension to Establish Keys for the Secure 459 Real-time Transport Protocol (SRTP)", RFC 5764, 460 DOI 10.17487/RFC5764, May 2010, 461 . 463 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., 464 Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding 465 Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, 466 . 468 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 469 Transport Protocol (RTP) Header Extension for Client-to- 470 Mixer Audio Level Indication", RFC 6464, 471 DOI 10.17487/RFC6464, December 2011, 472 . 474 [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- 475 time Transport Protocol (RTP) Header Extension for Mixer- 476 to-Client Audio Level Indication", RFC 6465, 477 DOI 10.17487/RFC6465, December 2011, 478 . 480 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 481 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 482 September 2012, . 484 Appendix A. Change log 486 Changes in draft -10: 488 o Additional editorial changes from IETF LC. 490 Changes in draft -09: 492 o Editorial changes from IETF LC. 494 o Added new reference for Opus FEC. 496 Changes in draft -08: 498 o Switch to RFC 8174 boilerplate. 500 Changes in draft -07: 502 o Clarify how bandwidth management interacts with FEC. 504 o Make 3GPP reference normative. 506 Changes in draft -06: 508 o Discuss how multiple streams can be protected by a single FlexFEC 509 stream. 511 o Discuss FEC for bandwidth probing. 513 o Add note about recovery of RTP headers and header extensions. 515 o Add note about FEC/SRTP ordering. 517 o Clarify flexfec demux text, and mention retransmits. 519 o Clarify text regarding offers/answers. 521 o Make RFC2198 support SHOULD strength. 523 o Clean up references. 525 Changes in draft -05: 527 o No changes. 529 Changes in draft -04: 531 o Discussion of layered codecs. 533 o Discussion of RTX. 535 o Clarified implementation requirements. 537 o FlexFEC MUST -> SHOULD. 539 o Clarified AMR max-red handling. 541 o Updated references. 543 Changes in draft -03: 545 o Added overhead stats for Opus. 547 o Expanded discussion of multi-packet FEC for Opus. 549 o Added discussion of AMR/AMR-WB. 551 o Removed discussion of ssrc-group. 553 o Referenced the data channel doc. 555 o Referenced the RTP/RTCP RFC. 557 o Several small edits based on feedback from Magnus. 559 Changes in draft -02: 561 o Expanded discussion of FEC-only m-lines, and how they should be 562 handled in offers and answers. 564 Changes in draft -01: 566 o Tweaked abstract/intro text that was ambiguously normative. 568 o Removed text on FEC for Opus in CELT mode. 570 o Changed RFC 2198 recommendation for PCMU to be MAY instead of NOT 571 RECOMMENDED, based on list feedback. 573 o Explicitly called out application data as something not addressed 574 in this document. 576 o Updated flexible-fec reference. 578 Changes in draft -00: 580 o Initial version, from sidebar conversation at IETF 90. 582 Author's Address 584 Justin Uberti 585 Google 586 747 6th St S 587 Kirkland, WA 98033 588 USA 590 Email: justin@uberti.name