rfc2736.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999


   A similar issue arises with codec parameters, and whether or not they
   should be included in the payload format. An example is with a codec
   that has a choice of huffman tables for compression.  The codec may
   use either huffman table 1 or table 2 for encoding and the receiver
   needs to know this information for correct decoding. There are a
   number of ways in which this kind of information can be conveyed:

   o  Out of band signalling, prior to media transmission.

   o  Out of band signalling, but the parameter can be changed mid-
      session.  This requires synchronization of the change in the media
      stream.

   o  The change is signaled through a change in the RTP payload type
      field. This requires mapping the parameter space into particular
      payload type values and signalling this mapping out-of-band prior
      to media transmission.

   o  Including the parameter in the payload format. This allows for
      adapting the parameter in a robust manner, but makes the payload
      format less efficient.

   Which mechanism to use depends on the utility of changing the
   parameter in mid-session to support application layer adaptation.
   However, using out-of-band signalling to change a parameter in mid-
   session is generally to be discouraged due to the problem of
   synchronizing the parameter change with the media stream.

4.1.  RTP Header Extensions

   Many RTP payload formats require some additional header information
   to be carried in addition to that included in the fixed RTP packet
   header.  The recommended way of conveying this information is in the
   payload section of the packet. The RTP header extension should not be
   used to convey payload specific information ([9], section 5.3) since
   this is inefficient in its use of bandwidth; requires the definition
   of a new RTP profile or profile extension; and makes it difficult to
   employ FEC schemes such as, for example, [7].  Use of an RTP header
   extension is only appropriate for cases where the extension in
   question applies across a wide range of payload types.

4.2.  Header Compression

   Designers of payload formats should also be aware of the needs of RTP
   header compression [1]. In particular, the compression algorithm
   functions best when the RTP timestamp increments by a constant value
   between consecutive packets. Payload formats which rely on sending
   packets out of order, such that the timestamp increment is not



Handley & Perkins        Best Current Practice                  [Page 6]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999


   constant, are likely to compress less well than those which send
   packets in order. This has most often been an issue when designing
   payload formats for FEC information, although some video codecs also
   rely on out-of-order transmission of packets at the expense of
   reduced compression. Although in some cases such out-of-order
   transmission may be the best solution, payload format designers are
   encourage to look for alternative solutions where possible.

5.  Summary

   Designing packet formats for RTP is not a trivial task.  Typically a
   detailed knowledge of the codec involved is required to be able to
   design a format that is resilient to loss, does not introduce loss
   magnification effects due to inappropriate packetisation, and does
   not introduce unnecessary distortion after a packet loss.  We believe
   that considerable effort should be put into designing packet formats
   that are well tailored to the codec in question.  Typically this
   requires a very small amount of processing at the sender and
   receiver, but the result can be greatly improved quality when
   operating in typical Internet environments.

   Designers of new codecs for use with RTP should consider making the
   output of the codec "naturally packetizable". This implies that the
   codec should be designed to produce a packet stream, rather than a
   bit-stream; and that that packet stream contains the minimal amount
   of redundancy necessary to ensure that each packet is independently
   decodable with minimal loss of decoder predictor tracking. It is
   recognised that sacrificing some small amount of bandwidth to ensure
   greater robustness to packet loss is often a worthwhile tradeoff.

   It is hoped that, in the long run, new codecs should be produced
   which can be directly packetised, without the trouble of designing a
   codec-specific payload format.

   It is possible to design generic packetisation formats that do not
   pay attention to the issues described in this document, but such
   formats are only suitable for special purpose networks where packet
   loss can be avoided by careful engineering at the network layer, and
   are not suited to current best-effort networks.

6.  Security Considerations

   The guidelines in this document result in RTP payload formats that
   are robust in the presence of real world network conditions.
   Designing payload formats for special purpose networks that assume
   negligable loss rates will normally result in slightly better
   compression, but produce formats that are more fragile, thus
   rendering them easier targets for denial-of-service attacks.



Handley & Perkins        Best Current Practice                  [Page 7]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999


   Designers of payload formats should pay close attention to possible
   security issues that might arise from poor implementations of their
   formats, and should be careful to specify the correct behaviour when
   anomalous conditions arise.  Examples include how to process illegal
   field values, and conditions when there are mismatches between length
   fields and actual data.  Whilst the correct action will normally be
   to discard the packet, possible such conditions should be brought to
   the attention of the implementor to ensure that they are trapped
   properly.

   The RTP specification covers encryption of the payload.  This issue
   should not normally be dealt with by payload formats themselves.
   However, certain payload formats spread information about a
   particular application data unit over a number of packets, or rely on
   packets which relate to a number of application data units. Care must
   be taken when changing the encryption of such streams, since such
   payload formats may constrain the places in a stream where it is
   possible to change the encryption key without exposing sensitive
   data.

   Designers of payload formats which include FEC should be aware that
   the automatic addition of FEC in response to packet loss may increase
   network congestion, leading to a worsening of the problem which the
   use of FEC was intended to solve. Since this may, at its worst,
   constitute a denial of service attack, designers of such payload
   formats should take care that appropriate safeguards are in place to
   prevent abuse.

Authors' Addresses

   Mark Handley
   AT&T Center for Internet Research at ICSI,
   International Computer Science Institute,
   1947 Center Street, Suite 600,
   Berkeley, CA 94704, USA

   EMail: [e-mail]


   Colin Perkins
   Dept of Computer Science,
   University College London,
   Gower Street,
   London WC1E 6BT, UK.

   EMail: [e-mail]





Handley & Perkins        Best Current Practice                  [Page 8]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999


Acknowledgments

   This document is based on experience gained over several years by
   many people, including Van Jacobson, Steve McCanne, Steve Casner,
   Henning Schulzrinne, Thierry Turletti, Jonathan Rosenberg and
   Christian Huitema amongst others.

References

   [1]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
        Low-Speed Serial Links", RFC 2508, February 1999.

   [2]  D. Clark and  D. Tennenhouse, "Architectural Considerations for
        a New Generation of Network Protocols" Proc ACM Sigcomm 90.

   [3]  J. Mahdavi and S. Floyd. "TCP-friendly unicast rate-based flow
        control". Note sent to end2end-interest mailing list, Jan 1997.

   [4]  M. Mathis, J. Semske, J. Mahdavi, and T. Ott. "The macro-scopic
        behavior of the TCP congestion avoidance algorithm". Computer
        Communication Review, 27(3), July 1997.

   [5]  J. Nonnenmacher, E. Biersack, Don Towsley, "Parity-Based Loss
        Recovery for Reliable Multicast Transmission", Proc ACM Sigcomm

   [6]  J. Padhye, V. Firoiu, D. Towsley, J.  Kurose, "Modeling TCP
        Throughput: A Simple Model and its Empirical Validation", Proc.
        ACM Sigcomm 1998.

   [7]  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.

   [8]  Ramakrishnan, K. and  S. Floyd, "A Proposal to add Explicit
        Congestion Notification (ECN) to IP", RFC 2481, January 1999.

   [9]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "Real-Time Transport Protocol", RFC 1889, January 1996.













Handley & Perkins        Best Current Practice                  [Page 9]

RFC 2736     Guidelines for Writers of RTP Payload Formats December 1999


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.



















Handley & Perkins        Best Current Practice                 [Page 10]