From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2733.txt | 1459 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1459 insertions(+) create mode 100644 doc/rfc/rfc2733.txt (limited to 'doc/rfc/rfc2733.txt') diff --git a/doc/rfc/rfc2733.txt b/doc/rfc/rfc2733.txt new file mode 100644 index 0000000..08889bb --- /dev/null +++ b/doc/rfc/rfc2733.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group J. Rosenberg +Request for Comments: 2733 dynamicsoft +Category: Standards Track H. Schulzrinne + Columbia University + December 1999 + + + An RTP Payload Format for Generic Forward Error Correction + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + This document specifies a payload format for generic forward error + correction of media encapsulated in RTP. It is engineered for FEC + algorithms based on the exclusive-or (parity) operation. The payload + format allows end systems to transmit using arbitrary block lengths + and parity schemes. It also allows for the recovery of both the + payload and critical RTP header fields. Since FEC is sent as a + separate stream, it is backwards compatible with non-FEC capable + hosts, so that receivers which do not wish to implement FEC can just + ignore the extensions. + +Table of Contents + + 1 Introduction ........................................... 2 + 2 Terminology ............................................ 2 + 3 Basic Operation ........................................ 3 + 4 Parity Codes ........................................... 5 + 5 RTP Media Packet Structure ............................. 6 + 6 FEC Packet Structure ................................... 7 + 6.1 RTP Header of FEC Packets .............................. 7 + 6.2 FEC Header ............................................. 7 + 7 Protection Operation ................................... 9 + 8 Recovery Procedures .................................... 10 + 8.1 Reconstruction ......................................... 10 + 8.2 Determination of When to Recover ....................... 12 + + + +Rosenberg & Schulzrinne Standards Track [Page 1] + +RFC 2733 Generic FEC December 1999 + + + 9 Example ................................................ 16 + 10 Use with Redundant Encodings ........................... 17 + 11 Indicating FEC Usage in SDP ............................ 20 + 11.1 FEC as a Separate Stream ............................... 20 + 11.2 Use with Redundant Encodings ........................... 21 + 11.3 Usage with RTSP ........................................ 22 + 12 Security Considerations ................................ 23 + 13 Acknowledgments ........................................ 24 + 14 Authors' Addresses ..................................... 24 + 15 Bibliography ........................................... 25 + 16 Full Copyright Statement ............................... 26 + +1 Introduction + + The quality of packet voice on the Internet has been mediocre due, in + part, to high packet loss rates. This is especially true on wide-area + connections. Unfortunately, the strict delay requirements of real- + time multimedia usually eliminate the possibility of retransmissions. + + It is for this reason that forward error correction (FEC) has been + proposed to compensate for packet loss in the Internet [1] [2]. In + particular, the use of traditional error correcting codes, such as + parity, Reed-Solomon, and Hamming codes, has attracted attention. To + support these mechanisms, protocol support is required. + + This document defines a payload format for RTP [3] which allows for + generic forward error correction of real time media. In this context, + generic means that the FEC protocol is (1) independent of the nature + of the media being protected, be it audio, video, or otherwise, (2) + flexible enough to support a wide variety of FEC mechanisms, (3) + designed for adaptivity so that the FEC technique can be modified + easily without out of band signaling, and (4) supportive of a number + of different mechanisms for transporting the FEC packets. + +2 Terminology + + The following terms are used throughout this document: + + Media Payload: is a piece of raw, un-protected user data which + is to be transmitted from the sender. The media payload is + placed inside of an RTP packet. + + Media Header: is the RTP header for the packet containing the + media payload. + + Media Packet: The combination of a media payload and media + header is called a media packet. + + + + +Rosenberg & Schulzrinne Standards Track [Page 2] + +RFC 2733 Generic FEC December 1999 + + + FEC Packet: The forward error correction algorithms at the + transmitter take the media packets as an input. They output + both the media packets that they are passed, and new + packets called FEC packets. The FEC packets are formatted + according to the rules specified in this document. + + FEC Header: The FEC header is the header information contained + in an FEC packet. + + FEC Payload: The FEC payload is the payload in an FEC packet. + + Associated: An FEC packet is said to be "associated" with one or + more media packets when those media packets are used to + generate the FEC packet (by use of the exclusive or + operation). + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + +3 Basic Operation + + The payload format described here is used whenever a participant in + an RTP session would like to protect a media stream it is sending + with forward error correction (FEC). The FEC supported by the format + are those codes based on simple exclusive or (xor) parities. The + sender takes some set of packets from the media stream, and applies + an xor operation across the payloads. The sender also applies the xor + operation over components of the RTP headers. Based on the procedures + defined here, the result is an RTP packet containing FEC information. + This packet can be used at the receiver to recover any one of the + packets used to generate the FEC packet. This document does not + mandate the particular set of media packets combined to generate an + FEC packet (such a set [is] referred to as a code). Use of differing + sets results in a tradeoff between overhead, delay, and + recoverability. Section 4 outlines some possible combinations. + + The payload format contains information that allows the sender to + tell the receiver exactly which media packets have been used to + generate the FEC. Specifically, each FEC packet contains a bitmask, + called the offset mask, containing 24 bits. If bit i in the mask is + set to 1, the media packet with sequence number N + i was used to + generate this FEC packet. N is called the sequence number base, and + is sent in the FEC packet as well. The offset mask and payload type + are sufficient to signal arbitrary parity based forward error + correction schemes with little overhead. + + + + + +Rosenberg & Schulzrinne Standards Track [Page 3] + +RFC 2733 Generic FEC December 1999 + + + This document also describes procedures that allow the receiver to + make use of the FEC without having to know the details of specific + codes. This allows the sender much flexibility; it can adapt the code + in use based on network conditions, and be certain the receivers can + still make use of the FEC for recovery. + + As the sender generates FEC packets, they are sent to the receivers. + The sender still usually sends the original media stream, as if there + were no FEC. This allows the media stream to still be used by + receivers who are not FEC capable. However, some FEC codes do not + require the original media to be sent; the FEC stream is sufficient + for recovery. These codes have the drawback that all receivers must + be FEC capable. However, they are supported by this format. + + The FEC packets are not sent in the same RTP stream as the media + packets. They can be sent as a separate stream, or as a secondary + codec in the redundant codec payload format [5]. When sent as a + separate stream, the FEC packets have their own sequence number + space. Although the timestamps for the FEC packets are derived from + the media packets, they increment monotonically. FEC packet streams + thus work well with any header compression mechanism which requires + fixed deltas between fields in the packet header. + + This document does not prescribe the definition of "separate + streams", but leaves this to applications and higher level protocols + to define. For multicast, the separate stream may be implemented by + separate multicast groups, different ports in the same group, or by a + different SSRC within the same group/port. For unicast, different + ports or different SSRC may be used. Each of these approaches has + drawbacks and benefits which depend on the application. + + At the receiver, the FEC and original media are received. If no media + packets are lost, the FEC can be ignored. In the event of loss, the + FEC packets can be combined with other media and FEC packets that + have been received, resulting in recovery of missing media packets. + The recovery is exact; the payload is perfectly reconstructed, along + with most components of the header. + + RTP packets which contain data formatted according to this + specification (i.e., FEC packets) are signaled using dynamic RTP + payload types. + + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 4] + +RFC 2733 Generic FEC December 1999 + + +4 Parity Codes + + For brevity, we define the function f(x,y,..) to be the XOR (parity) + operator applied to the packets x,y,... The output of this function + is another packet, called the parity packet. For simplicity, we + assume here that the parity packet is computed as the bitwise XOR of + the input packets. The exact procedure is specified in section 6. + + Recovery of data packets using parity codes is accomplished by + generating one or more parity packets over a group of data packets. + To be effective, the parity packets must be generated by linearly + independent combinations of data packets. The particular combination + is called a parity code. One class of codes takes a group of k data + packets, and generates n-k parity packets. There are a large number + of possible parity codes for a given n,k. The payload format does not + mandate a particular code. + + For example, consider a parity code which generates a single parity + packet over two data packets. If the original media packets are + a,b,c,d, the packets generated by the sender are: + + a b c d <-- media stream + f(a,b) f(c,d) <-- FEC stream + + where time increases to the right. In this example, the error + correction scheme (we use the terms scheme and code interchangeably) + introduces a 50% overhead. But if b is lost, a and f(a,b) can be used + to recover b. + + Some additional codes are listed below. In each, the original media + stream consists of packets a,b,c,d and so on. + + Scheme 1 + -------- + + This scheme is the similar to the one in the example above. However, + instead of sending b, followed by f(a,b), f(a,b) is sent before b. + Doing this clearly requires additional delay at the sender. However, + if allows some bursts of two consecutive packet losses to be + recovered. The packets generated by the sender look like: + + a b c d e <-- media stream + f(a,b) f(b,c) f(c,d) f(d,e) <-- FEC stream + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 5] + +RFC 2733 Generic FEC December 1999 + + + Scheme 2 + -------- + + It is not strictly necessary for the original media stream to be + transmitted. In this scheme, only FEC packets are transmitted. This + scheme allows for recovery of all single packet losses and some + consecutive packet losses, but with slightly less overhead than + scheme 1. The packets generated by the sender look like: + + f(a,b) f(a,c) f(a,b,c) f(c,d) f(c,e) f(c,d,e) <-- FEC stream + + Scheme 3 + -------- + + This scheme requires the receiver to wait an additional four packet + intervals to recover the original media packets. However, it can + recover from one, two or three consecutive packet losses. The packets + generated by the sender look like: + + a b c d <-- media stream + f(a,b,c) f(a,c,d) f(a,b,d) <-- FEC stream + +5 RTP Media Packet Structure + + The formatting of the media packets is unaffected by FEC. If the FEC + is sent as a separate stream, the media packets are sent as if there + was no FEC. If the FEC is being sent as a redundant codec, the media + packets are sent as the main codec as defined in RFC 2198 [5]. + + This lends to a very efficient encoding. When little (or no) FEC is + used, there are mostly media packets being sent. This means that the + overhead (present in FEC packets only) tracks the amount of FEC in + use. + + + + + + + + + + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 6] + +RFC 2733 Generic FEC December 1999 + + +6 FEC Packet Structure + + An FEC packet is constructed by placing an FEC header and FEC payload + in the RTP payload, as shown in Figure 1: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RTP Header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | FEC Header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | FEC Payload | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: FEC Packet Structure + +6.1 RTP Header of FEC Packets + + The version field is set to 2. The padding bit is computed via the + protection operation, defined below. The extension bit is also + computed via the protection operation. The SSRC value will generally + be the same as the SSRC value of the media stream it protects. It MAY + be different if the FEC stream is being demultiplexed via the SSRC + value. The CC value is computed via the protection operation. The + CSRC list is never present, independent of the value of the CC field. + The extension is never present, independent of the value of the X + bit. The marker bit is computed via the protection operation. + + The sequence number has the standard definition: it MUST be one + higher than the sequence number in the previously transmitted FEC + packet. The timestamp MUST be set to the value of the media RTP clock + at the instant the FEC packet is transmitted. This results in the TS + value in FEC packets to be monotonically increasing, independent of + the FEC scheme. + + The payload type for the FEC packet is determined through dynamic, + out of band means. According to RFC 1889 [3], RTP participants which + cannot recognize a payload type must discard it. This provides + backwards compatibility. The FEC mechanisms can then be used in a + multicast group with mixed FEC-capable and FEC-incapable receivers. + +6.2 FEC Header + + This header is 12 bytes. The format of the header is shown in Figure + 2, and consists of an SN base field, length recovery field, E field, + PT recovery field, mask field and TS recovery field. + + + + + +Rosenberg & Schulzrinne Standards Track [Page 7] + +RFC 2733 Generic FEC December 1999 + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SN base | length recovery | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |E| PT recovery | mask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TS recovery | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Parity Header Format + + The length recovery field is used to determine the length of any + recovered packets. It is computed via the protection operation + applied to the unsigned network-ordered 16 bit representation of the + sums of the lengths (in bytes) of the media payload, CSRC list, + extension and padding of media packets associated with this FEC + packet (in other words, the CSRC list, extension, and padding, if + present, are "counted" as part of the payload). This allows the FEC + procedure to be applied even when the lengths of the media packets + are not identical. For example, assume an FEC packet is being + generated by xor'ing two media packets together. The length of the + two media packets are 3 (0b011) and 5 (0b101) bytes, respectively. + The length recovery field is then encoded as 0b011 xor 0b101 = 0b110. + + The E bit indicates a header extension. Implementations conforming to + this version of the specification MUST set this bit to zero. + + The PT recovery field is obtained via the protection operation + applied to the payload type values of the media packets associated + with the FEC packet. + + The mask field is 24 bits. If bit i in the mask is set to 1, then the + media packet with sequence number N + i is associated with this FEC + packet, where N is the SN Base field in the FEC packet header. The + least significant bit corresponds to i=0, and the most significant to + i=23. + + The SN base field MUST be set to the minimum sequence number of those + media packets protected by FEC. This allows for the FEC operation to + extend over any string of at most 24 packets. + + The TS recovery field is computed via the protection operation + applied to the timestamps of the media packets associated with this + FEC packet. This allows the timestamp to be completely recovered. + + The payload of the FEC packet is the protection operation applied to + the concatenation of the CSRC list, RTP extension, media payload, and + padding of the media packets associated with the FEC packet. + + + + +Rosenberg & Schulzrinne Standards Track [Page 8] + +RFC 2733 Generic FEC December 1999 + + + Note that it's possible for the FEC packet to be slightly larger than + the media packets it protects (due to the presence of the FEC + header). This could cause difficulties if this results in the FEC + packet exceeding the Maximum Transmission Unit size for the path + along which it is sent. + +7 Protection Operation + + The protection operation involves concatenating specific fields from + the RTP header of the media packet, appending the payload, padding + with zeroes, and then computing the xor across the resulting bit + strings. The resulting bit string is used to generate the FEC packet. + + The following procedure MAY be followed for the protection operation. + Other procedures MAY be followed, but the end result MUST be + identical to the one described here. For each media packet to be + protected, a bit string is generated by concatenating the following + fields together in the order specifed: + + o Padding Bit (1 bit) + + o Extension Bit (1 bit) + + o CC bits (4 bits) + + o Marker bit (1 bit) + + o Payload Type (7 bits) + + o Timestamp (32 bits) + + o Unsigned network-ordered 16 bit representation of the sum of + the lengths (in bytes) of the CSRC List, length of the padding, + length of the extension, and length of the media payload (16 + bits) + + o if CC is nonzero, the CSRC List (variable length) + + o if X is 1, the Header Extension (variable length) + + o the payload (variable length) + + o Padding, if present (variable length) + + Note that the Padding Bit (first entry above) forms the most + significant bit of the bit string. + + + + + +Rosenberg & Schulzrinne Standards Track [Page 9] + +RFC 2733 Generic FEC December 1999 + + + If the lengths of the bit strings are not equal, each bit string that + is shorter than the length of the longest, MUST be padded to the + length of the longest. Any value for the pad may be used. The pad + MUST be added at the end of the bit string. + + The parity operation is then applied across the bit strings. The + result is the bit string used to build the FEC packet. Call this the + FEC bit string. + + The first (most significant) bit in the FEC bit string is written + into the Padding Bit of the FEC packet. The second bit in the FEC bit + string is written into the Extension bit of the FEC packet. The next + four bits of the FEC bit string are written into the CC field of the + FEC packet. The next bit of the FEC bit string is written into the + marker bit of the FEC packet. The next 7 bits of the FEC bit string + are written into the PT recovery field in the FEC packet header. The + next 32 bits of the FEC bit string are written into the TS recovery + field in the packet header. The next 16 bits are written into the + length recovery field in the FEC packet header. The remaining bits + are set to be the payload of the FEC packet. + +8 Recovery Procedures + + The FEC packets allow end systems to recover from the loss of media + packets. All of the header fields of the missing packets, including + CSRC lists, extensions, padding bits, marker and payload type, are + recoverable. This section describes the procedure for performing + this recovery. + + Recovery requires two distinct operations. The first determines which + packets (media and FEC) must be combined in order to recover a + missing packet. Once this is done, the second step is to actually + reconstruct the data. The second step MUST be performed as described + below. The first step MAY be based on any algorithm chosen by the + implementer. Different algorithms result in a tradeoff between + complexity and the ability to recover missing packets if at all + possible. + +8.1 Reconstruction + + Let T be the list of packets (FEC and media) which can be combined to + recover some media packet xi. The procedure is as follows: + + 1. For the media packets in T, compute the bit string as + described in the protection operation of the previous + section. + + + + + +Rosenberg & Schulzrinne Standards Track [Page 10] + +RFC 2733 Generic FEC December 1999 + + + 2. For the FEC packet in T, compute the bit string in the same + fashion, except use the PT Recovery instead of Payload Type, + TS Recovery instead of Timestamp, and always set the CSRC + list, extension, and padding to null. + + 3. If any of the bit strings generated from the media packets + are shorter than the bit string generated from the FEC + packet, pad them to be the same length as the bit string + generated from the FEC. The padding MUST be added at the + end of the bit string, and MAY be of any value. + + 4. Perform the exclusive or (parity) operation across the bit + strings, resulting in a recovery bit string. + + 5. Create a new packet with the standard 12 byte RTP header + and no payload. + + 6. Set the version of the new packet to 2. + + 7. Set the Padding bit in the new packet to the first bit in + the recovery bit string. + + 8. Set the Extension bit in the new packet to the second bit + in the recovery bit string. + + 9. Set the CC field to the next four bits in the recovery bit + string. + + 10. Set the marker bit in the new packet to the next bit in the + recovery bit string. + + 11. Set the payload type in the new packet to the next 7 bits + in the recovery bit string. + + 12. Set the SN field in the new packet to xi. + + 13. Set the TS field in the new packet to the next 32 bits in + the recovery bit string. + + 14. 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 padding. + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 11] + +RFC 2733 Generic FEC December 1999 + + + 15. Set the SSRC of the new packet to the SSRC of the media + stream it's protecting. + + This procedure will completely recover both the header and payload of + an RTP packet. + +8.2 Determination of When to Recover + + The previous section discussed how to recover a media packet with + sequence number xi when all of the packets needed to recover it were + available. The decision about whether to attempt recovery of some + media packet xi, and how to determine if sufficient data is available + to recover it, is left to the implementer. However, this section + provides a simple algorithm which MAY be used for this purpose. + + The algorithm is described below in C code. The code assumes that + several functions exist. recover_packet() takes the sequence number + of a packet, and an FEC packet. Using the FEC packet and data packets + received previously, the data packet with the given sequence number + is recovered. add_fec_to_pending_list() adds the given FEC packet to + a linked list of FEC packets which have not yet been used for + recovery. wait_for_packet() waits for a packet, FEC or data, from the + network. remove_from_pending_list() removes the FEC packet from the + pending list. The structure packet contains a boolean variable fec + which is true when the packet is FEC, false if it's media. When its + an FEC packet, the mask and snbase field contain those values from + the FEC packet header. When it's a media packet, the sn variable + contains the sequence number of the packet. The global array A + indicates which media packets have been received, and which have not. + It is indexed by the sequence number of the packet. + + The function fec_recovery implements the algorithm. It waits for + packets, and when it receives an FEC packet, calls recover_with_fec() + to attempt to use it to recover. If no recovery is possible, the FEC + packet is stored for later attempts. If the received packet was a + media packet, its presence is noted, and any old FEC packets are + checked to see if recovery is now possible. Recovered packets are + treated as if they were received, triggering further attempts at + recovery. + + A real implementation will need to use a circular buffer instead of + the simple array (A in the code) in order to avoid running off the + end of the buffer. In addition, the code below does not attempt to + free up FEC packets that are old and were never used. Normally, such + discarding is done based on time constraints introduced by the + playout buffer. If an FEC data protects packets whose play time has + elapsed, the FEC is no longer needed. + + + + +Rosenberg & Schulzrinne Standards Track [Page 12] + +RFC 2733 Generic FEC December 1999 + + +typedef struct packet_s { + + BOOLEAN fec; /* FEC or media */ + + int sn; /* SN of the packet, for media only */ + + BOOLEAN mask[24]; /* Mask, FEC only */ + int snbase; /* SN Base, FEC only */ + + struct packet_s *next; + +} packet; + + + +BOOLEAN A[65535]; +packet *pending_list; + +packet *recover_with_fec(packet *fec_pkt) { + + packet *data_pkt; + int pkts_present, /* number of packets from the mask that are + present */ + pkts_needed, /* number of packets needed is the number of ones + in the mask minus 1 */ + pkt_to_recover, /* sn of the packet we are recovering */ + i; + + pkts_present = 0; + + /* The number of packets needed is the number of ones in the mask + minus 1. The code below increments pkts_needed by the number + of ones in the mask, so we initialize this to -1 so that the + final count is correct */ + + pkts_needed = -1; + + /* Go through all 24 bits in the mask, and check if we have + all but one of the media packets */ + + for(i = 0; i < 24; i++) { + + /* If the packet is here and in the mask, increment counter */ + + if(A[i+fec_pkt->snbase] && fec_pkt->mask[i]) pkts_present++; + + /* Count the number of packets needed as well */ + if(fec_pkt->mask[i]) pkts_needed++; + + + +Rosenberg & Schulzrinne Standards Track [Page 13] + +RFC 2733 Generic FEC December 1999 + + + /* The packet to recover is the one with a bit in the + mask that's not here yet */ + if(!A[i+fec_pkt->snbase] && fec_pkt->mask[i]) + pkt_to_recover = i+fec_pkt->snbase; + } + + /* If we can recover, do so. Otherwise, return NULL */ + + if(pkts_present == pkts_needed) { + data_pkt = recover_packet(pkt_to_recover, fec_pkt); + } else { + data_pkt = NULL; + } + + return(data_pkt); + } + + + void fec_recovery() { + + packet *p, /* packet received or regenerated */ + *fecp, /* fec packet from pending list */ + *pnew; /* new packets recovered */ + + while(1) { + + p = wait_for_packet(); /* get packet from network */ + + while(p) { + + /* if it's an FEC packet, try to recover with it. If we can't, + store it for later potential use. If we can recover, act as + if the recovered packet is received and try to recover some + more. Otherwise, if it's a data packet, mark it as received, + and check if we can now recover a data packet with the list + of pending FEC packets */ + + if(p->fec == TRUE) { + pnew = recover_with_fec(p); + + if(pnew) + + A[pnew->sn] = TRUE; + else + add_fec_to_pending_list(p); + + /* We assign pnew to p since the while loop will continue + to recover based on p not being NULL */ + + + +Rosenberg & Schulzrinne Standards Track [Page 14] + +RFC 2733 Generic FEC December 1999 + + + p = pnew; + + } else { + + /* Mark this data packet as here */ + A[p->sn] = TRUE; + + free(p); + p = NULL; + + /* Go through pending list. Try and recover a packet using + each FEC. If we are successful, add the data packet to + the list of received packets, remove the FEC packet from + the pending list, since we've used it, and then try to + recover some more */ + + for(fecp = pending_list; fecp != NULL; fecp = fecp->next) { + pnew = recover_with_fec(fecp); + if(pnew) { + + /* The packet is now here, as we've recovered it */ + A[pnew->sn] = TRUE; + + /* One FEC packet can only be used once to recover, + so remove it from the pending list */ + + remove_fec_from_pending_list(fecp); + + p = pnew; + + break; + } + + } /*for*/ + + } /*p->fec was false */ + + } /* while p*/ + + } /* while 1 */ + + } + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 15] + +RFC 2733 Generic FEC December 1999 + + +9 Example + + Consider 2 media packets to be sent, x and y, from SSRC 2. Their + sequence numbers are 8 and 9, respectively, with timestamps of 3 and + 5, respectively. Packet x uses payload type 11, and packet y uses + payload type 18. Packet x is has 10 bytes of payload, and packet y + 11. Packet y has its marker bit set. The RTP headers for packets x + and y are shown in Figures 3 and 4 respectively. + +Media Packet x + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 0|0|0|0 0 0 0|0|0 0 0 1 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Version: 2 + Padding: 0 + Extension: 0 + Marker: 0 + PTI: 11 + SN: 8 + TS: 3 + SSRC: 2 + + Figure 3: RTP Header for Media Packet X + + An FEC packet is generated from these two. We assume that payload + type 127 is used to indicate an FEC packet. The resulting RTP header + is shown in Figure 5. + + The FEC header in the FEC packet is shown in Figure 6. + + + + + + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 16] + +RFC 2733 Generic FEC December 1999 + + +11 Use with Redundant Encodings + + One can consider an FEC packet as a "redundant coding" of the media. + +Media Packet y + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 0|0|0|0 0 0 0|1|0 0 1 0 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Version: 2 + Padding: 0 + Extension: 0 + Marker: 1 + PTI: 18 + SN: 9 + TS: 5 + SSRC: 2 + + Figure 4: RTP Header for Media Packet Y + + Because of this, the payload format for encoding of redundant audio + data [5] can be used to carry the FEC data along with the media. The + procedure for this is as follows. + + The FEC operation defined above acts on a stream of RTP media + packets. The stream which is operated on is the stream before the + encapsulation defined in RFC 2198 [5]. In other words, the media + stream to be protected is encapsulated in standard RTP media packets. + The FEC operation above is performed (with one minor change), + generating a stream of FEC packets. The change to the procedure above + is that if the RTP packets being protected contain an RTP extension, + padding, or a CSRC list, these MUST be removed from the packets, and + the CC field, Padding Bit, and Extension but MUST be set to zero, + before the FEC operation is applied. These modified packets are used + in the procedure above. Note that the sender MUST still send the + original packets (with the CSRC list, padding, and extension in tact) + as the primary encoding in RFC 2198. The removal of these fields only + applies to the protection operation. + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 17] + +RFC 2733 Generic FEC December 1999 + + + Once the FEC packets have been generated, the media payload is + extracted from the media packets. This payload is used as the primary + encoding as defined in RFC 2198. Then, the FEC header and payload of + the FEC packets is extracted, and treated as a redundant encoding. + Additional redundant encodings, besides FEC, MAY be added to the + packet as well. These encodings will not be protected by FEC, + however. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 0|0|0|0 0 0 0|1|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Version: 2 + Padding: 0 + Extension: 0 + Marker: 1 + PTI: 127 + SN: 1 + TS: 5 + SSRC: 2 + + Figure 5: RTP Header of FEC for Packets X and Y + + The redundant encodings header for the primary codec is set as + defined in RFC 2198. The redundant encodings header for the FEC data + is set as follows. The block PT is set to the dynamic PT associated + with the FEC format. The block length is set to the sum of the + lengths of the FEC header and payload. The timestamp offset SHOULD be + set to zero. The secondary coder payload includes the FEC header and + FEC payload. + + At the receiver, the primary codec and all secondary codecs are + extracted as separate RTP packets. This is done by copying the + sequence number, SSRC, marker bit, CC field, RTP version, and + extension bit from the RTP header of the redundant encodings packet + to the RTP header of each extracted packet. If the secondary codec + contains FEC, the CC field, Extension Bit, and Padding Bit in the RTP + header of the FEC packet MUST be set to zero instead. The payload + type identifier in the extracted packet is copied from the block PT + of the redundant encodings header. The timestamp of the extracted + packet is the difference between the timestamp in the RTP header and + + + + +Rosenberg & Schulzrinne Standards Track [Page 18] + +RFC 2733 Generic FEC December 1999 + + + the offset in the block header. The payload of the extracted packet + is the data block. This will result in the FEC stream and media + stream being extracted. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + SN base: 8 [min(8,9)] + len. rec.: 1 [8 xor 9] + E: 0 + PTI rec.: 25 [11 xor 18] + mask: 3 + TS rec.: 6 [3 xor 5] + + The payload length is 11 bytes. + + Figure 6: FEC Header of Result + + To use the FEC and media packets for recovery, the CSRC list, + extension, and padding MUST be removed from the media packets, if + present, and the CC field, Extension Bit, and Padding Bit MUST be set + to zero. These modified media packets, along with the FEC packets, + are then used to recover based on the procedures in section 8. The + recovered media packets will always have no extension, padding, or + CSRC list. An implementation MAY copy these fields into the recovered + packet from another media packet, if available. + + Using the redundant encodings payload format also implies that the + marker bit may not be recovered correctly. Applications MUST set the + marker bit to zero in media packets reconstructed using FEC + encapsulated in RFC 2198 redundancy. + + An advantage of this approach is a reduction in the overhead for + sending FEC packets. + + + + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 19] + +RFC 2733 Generic FEC December 1999 + + +11 Indicating FEC Usage in SDP + + FEC packets contain RTP packets with dynamic payload type values. In + addition, the FEC packets can be sent on separate multicast groups or + separate ports from the media. The FEC can even be carried in packets + containing media, using the redundant encodings payload format [5]. + These configuration options must be indicated out of band. This + section describes how this can be accomplished using the Session + Description Protocol (SDP), specified in RFC 2327 [6]. + +11.1 FEC as a Separate Stream + + In the first case, the FEC packets are sent as a separate stream. + This can mean they are sent on a different port and/or multicast + group from the media. When this is done, several pieces of + information must be conveyed: + + o The address and port where the FEC is being sent to + + o The payload type number for the FEC + + o Which media stream the FEC is protecting + + The payload type number for the FEC is conveyed in the m line of the + media it is protecting, listed as if it were another valid encoding + for the stream. There is no static payload type assignment for FEC, + so dynamic payload type numbers MUST be used. The binding to the + number is indicated by an rtpmap attribute. The name used in this + binding is "parityfec". + + The presence of the payload type number in the m line of the media it + is protecting does not mean the FEC is sent to the same address and + port as the media. Instead, this information is conveyed through an + fmtp attribute line. The presence of the FEC payload type on the m + line of the media serves only to indicate which stream the FEC is + protecting. + + The format for the fmtp line for FEC is: + + a=fmtp: + + where 'number' is the payload type number present in the m line. Port + is the port number where the FEC is sent to. The remaining three + items - network type, address type, and connection address - have the + same syntax and semantics as the c line from SDP. This allows the + fmtp line to be partially parsed by the same parser used on the c + + + + +Rosenberg & Schulzrinne Standards Track [Page 20] + +RFC 2733 Generic FEC December 1999 + + + lines. Note that since FEC cannot be hierarchically encoded, the + parameter MUST NOT appear in the connection + address. + + The following is an example SDP for FEC: + + v=0 + o=hamming 2890844526 2890842807 IN IP4 126.16.64.4 + s=FEC Seminar + c=IN IP4 224.2.17.12/127 + t=0 0 + m=audio 49170 RTP/AVP 0 78 + a=rtpmap:78 parityfec/8000 + a=fmtp:78 49172 IN IP4 224.2.17.12/127 + m=video 51372 RTP/AVP 31 79 + a=rtpmap:79 parityfec/8000 + a=fmtp:79 51372 IN IP4 224.2.17.13/127 + + The presence of two m lines in this SDP indicates that there are two + media streams - one audio and one video. The media format of 0 + indicates that the audio uses PCM, and is protected by FEC with + payload type number 78. The FEC is sent to the same multicast group + and TTL as the audio, but on a port number two higher (49172). The + video is protected by FEC with payload type number 79. The FEC + appears on the same port as the video (51372), but on a different + multicast address. + +11.2 Use with Redundant Encodings + + When the FEC stream is being sent as a secondary codec in the + redundant encodings format, this must be signaled through SDP. To do + this, the procedures defined in RFC 2198 are used to signal the use + of redundant encodings. The FEC payload type is indicated in the same + fashion as any other secondary codec. An rtpmap attribute MUST be + used to indicate a dynamic payload type number for the FEC packets. + The FEC MUST protect only the main codec. In this case, the fmtp + attribute for the FEC MUST NOT be present. + + For example: + + m=audio 12345 RTP/AVP 121 0 5 100 + a=rtpmap:121 red/8000/1 + a=rtpmap:100 parityfec/8000 + a=fmtp:121 0/5/100 + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 21] + +RFC 2733 Generic FEC December 1999 + + + This SDP indicates that there is a single audio stream, which can + consist of PCM (media format 0) , DVI (media format 5), the redundant + encodings (indicated by media format 121, which is bound to red + through the rtpmap attribute), or FEC (media format 100, which is + bound to parityfec through the rtpmap attribute). Although the FEC + format is specified as a possible coding for this stream, the FEC + MUST NOT be sent by itself for this stream. Its presence in the m + line is required only because non-primary codecs must be listed here + according to RFC 2198. The fmtp attribute indicates that the + redundant encodings format can be used, with DVI as a secondary + coding and FEC as a tertiary encoding. + +11.3 Usage with RTSP + + RTSP [7] can be used to request FEC packets to be sent as a separate + stream. When SDP is used with RTSP, the Session Description does not + include a connection address and port number for each stream. + Instead, RTSP uses the concept of a "Control URL". Control URLs are + used in SDP in two distinct ways. + + 1. There is a single control URL for all streams. This is + referred to as "aggregate control". In this case, the fmtp + line for the FEC stream is omitted. + + 2. There is a Control URL assigned to each stream. This is + referred to as "non-aggregate control". In this case, the + fmtp line specifies the Control URL for the stream of FEC + packets. The URL may be used in a SETUP command by an RTSP + client. + + The format for the fmtp line for FEC with RTSP and non-aggregate + control is: + + a=fmtp: + + where 'number' is the payload type number present in the m line. + Control URL is the URL used to control the stream of FEC packets. + Note that the Control URL does not need to be an absolute URL. The + rules for converting a relative Control URL to an absolute URL are + given in RFC 2326, Section C.1.1. + + + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 22] + +RFC 2733 Generic FEC December 1999 + + +12 Security Considerations + + The use of FEC has implications on the usage and changing of keys for + encryption. As the FEC packets do consist of a separate stream, there + are a number of permutations on the usage of encryption. In + particular: + + o The FEC stream may be encrypted, while the media stream is + not. + + o The media stream may be encrypted, while the FEC stream is + not. + + o The media stream and FEC stream are both encrypted, but using + different keys. + + o The media stream and FEC stream are both encrypted, but using + the same key. + + The first three of these would require any application level + signaling protocols to be aware of the usage of FEC, and to thus + exchange keys for it and negotiate its usage on the media and FEC + streams separately. In the final case, no such additional mechanisms + are needed. The first two cases present a layering violation, as FEC + packets should really be treated no differently than other RTP + packets. Encrypting just one may also make certain known-plaintext + attacks possible. For these reasons, applications utilizing + encryption SHOULD encrypt both streams. + + However, the changing of keys becomes problematic. For example, if + two packets a and b are sent, and FEC packet f(a,b) is sent, and the + keys used for a and b are different, which key should be used to + decode f(a,b)? In general, old keys will likely need to be cached, so + that when the keys change for the media stream, the old key is kept, + and used, until it is determined that the key has changed on the FEC + packets as well. + + Another issue with the use of FEC is its impact on network + congestion. Adding FEC in the face of increasing network losses is a + bad idea, as it can lead to increased congestion and eventual + congestion collapse if done on a widespread basis. As a result, + implementers MUST NOT substantially increase the amount of FEC in use + as network losses increase. + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 23] + +RFC 2733 Generic FEC December 1999 + + +13 Acknowledgments + + This work is based on an earlier draft on FEC, submitted by Budge and + Mackenzie in 1997. We would also like to thank Steve Casner, Mark + Handley, Orion Hodson and Colin Perkins for their comments. Thanks to + Anders Klemets who wrote the section on usage with RTSP. + +14 Authors' Addresses + + Jonathan Rosenberg + dynamicsoft + 200 Executive Drive + Suite 120 + West Orange, NJ 07046 + + Email: jdrosen@dynamicsoft.com + + + Henning Schulzrinne + Columbia University + M/S 0401, 1214 Amsterdam Ave. + New York, NY 10027-7003 + + EMail: schulzrinne@cs.columbia.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 24] + +RFC 2733 Generic FEC December 1999 + + +15 Bibliography + + [1] J.C. Bolot and A. V. Garcia, "Control mechanisms for packet audio + in the internet," in Proceedings of the Conference on Computer + Communications (IEEE Infocom) , (San Francisco, California), Mar. + 1996. + + [2] Perkins, C. and O. Hodson, "Options for Repair of Streaming + media", RFC 2354, June 1998. + + [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: + A Transport Protocol for Real-Time Applications", RFC 1889, + January 1996. + + [4] Bradner, S., "Key words for use in RFCs to indicate requirement + levels", BCP 14, RFC 2119, March 1997. + + [5] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., + Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload + for Redundant Audio Data", RFC 2198, September 1997. + + [6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", + RFC 2327, April 1998. + + [7] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming + Protocol (RTSP)", RFC 2326, April 1998. + + + + + + + + + + + + + + + + + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 25] + +RFC 2733 Generic FEC December 1999 + + +16. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rosenberg & Schulzrinne Standards Track [Page 26] + -- cgit v1.2.3