rfc2733.txt

中、英文RFC文档大全打包下载完全版 .


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