%% You should probably cite rfc8627 instead of this I-D. @techreport{ietf-payload-flexible-fec-scheme-06, number = {draft-ietf-payload-flexible-fec-scheme-06}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/06/}, author = {Mo Zanaty and Varun Singh and Ali C. Begen and Giridhar Mandyam}, title = {{RTP Payload Format for Flexible Forward Error Correction (FEC)}}, pagetotal = 38, year = 2018, month = mar, day = 6, abstract = {This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, where a number of FEC repair packets are generated from a set of source packets. These repair packets are sent in a redundancy RTP stream separate from the source RTP stream that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes which are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications, but endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets.}, }