RFC 5109, "RTP Payload Format for Generic Forward Error Correction", December 2007Source of RFC: avt (rai)
Errata ID: 1226
Reported By: Adam Li
Date Reported: 2008-01-03
Rejected by: Robert Sparks
Date Rejected: 2010-10-28
Section 9.1 says:
In Step 13, 13. Take the next 16 bits of the recovery bit string. Whatever unsigned integer this represents (assuming network-order), take that many bytes from the recovery bit string and append ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ them to the new packet. This represents the CSRC list, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ extension, payload, and the padding of the RTP payload.
It should say:
13. Take the next 16 bits of the recovery bit string. Whatever unsigned integer this represents (assuming network-order), it represents the cumulative length of the CSRC list, ^^ ^^^^^^^^^^^^^^^^^^^^^^^^ extension, payload, and the padding of the RTP payload of the packet to be recovered. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
From Peter Musgrave's review:
Editorial: rephrases a step in the instructions for RTP header reconstruction
Action: Rejected (In my opinion the new text is not significantly clearer and the use of the word cumulative is a bit confusing).