rfc2733.txt

RFC 的详细文档！

   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:<number> <port> <network type> <addresss type> <connection
   address>

   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
   <number of addresses> 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:<number> <control URL>

   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: [e-mail]


   Henning Schulzrinne
   Columbia University
   M/S 0401, 1214 Amsterdam Ave.
   New York, NY 10027-7003

   EMail: [e-mail]



























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]