Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 8088 Ericsson
Updates: 2736 May 2017
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 8088 Ericsson
Updates: 2736 May 2017
Category: Informational
ISSN: 2070-1721
How to Write an RTP Payload Format
如何编写RTP有效负载格式
Abstract
摘要
This document contains information on how best to write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions.
本文档包含有关如何最好地编写RTP有效负载格式规范的信息。它提供了阅读技巧、设计实践以及如何快速生成RTP有效负载格式规范并获得良好结果的实用技巧。说明中还包括一个模板。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8088.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8088.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Structure ..................................................4
2. Terminology .....................................................5
2.1. Definitions ................................................5
2.2. Abbreviations ..............................................5
2.3. Use of Normative Requirements Language .....................6
3. Preparations ....................................................6
3.1. Read and Understand the Media Coding Specification .........6
3.2. Recommended Reading ........................................7
3.2.1. IETF Process and Publication ........................7
3.2.2. RTP .................................................9
3.3. Important RTP Details .....................................13
3.3.1. The RTP Session ....................................13
3.3.2. RTP Header .........................................14
3.3.3. RTP Multiplexing ...................................16
3.3.4. RTP Synchronization ................................16
3.4. Signaling Aspects .........................................18
3.4.1. Media Types ........................................19
3.4.2. Mapping to SDP .....................................20
3.5. Transport Characteristics .................................23
3.5.1. Path MTU ...........................................23
3.5.2. Different Queuing Algorithms .......................23
3.5.3. Quality of Service .................................24
4. Standardization Process for an RTP Payload Format ..............24
4.1. IETF ......................................................25
4.1.1. Steps from Idea to Publication .....................25
4.1.2. WG Meetings ........................................27
4.1.3. Draft Naming .......................................27
4.1.4. Writing Style ......................................28
4.1.5. How to Speed Up the Process ........................29
4.2. Other Standards Bodies ....................................29
4.3. Proprietary and Vendor Specific ...........................30
4.4. Joint Development of Media Coding Specification
and RTP Payload Format ....................................31
5. Designing Payload Formats ......................................31
5.1. Features of RTP Payload Formats ...........................32
5.1.1. Aggregation ........................................32
5.1.2. Fragmentation ......................................33
5.1.3. Interleaving and Transmission Rescheduling .........33
5.1.4. Media Back Channels ................................34
5.1.5. Media Scalability ..................................34
5.1.6. High Packet Rates ..................................37
5.2. Selecting Timestamp Definition ............................37
1. Introduction ....................................................4
1.1. Structure ..................................................4
2. Terminology .....................................................5
2.1. Definitions ................................................5
2.2. Abbreviations ..............................................5
2.3. Use of Normative Requirements Language .....................6
3. Preparations ....................................................6
3.1. Read and Understand the Media Coding Specification .........6
3.2. Recommended Reading ........................................7
3.2.1. IETF Process and Publication ........................7
3.2.2. RTP .................................................9
3.3. Important RTP Details .....................................13
3.3.1. The RTP Session ....................................13
3.3.2. RTP Header .........................................14
3.3.3. RTP Multiplexing ...................................16
3.3.4. RTP Synchronization ................................16
3.4. Signaling Aspects .........................................18
3.4.1. Media Types ........................................19
3.4.2. Mapping to SDP .....................................20
3.5. Transport Characteristics .................................23
3.5.1. Path MTU ...........................................23
3.5.2. Different Queuing Algorithms .......................23
3.5.3. Quality of Service .................................24
4. Standardization Process for an RTP Payload Format ..............24
4.1. IETF ......................................................25
4.1.1. Steps from Idea to Publication .....................25
4.1.2. WG Meetings ........................................27
4.1.3. Draft Naming .......................................27
4.1.4. Writing Style ......................................28
4.1.5. How to Speed Up the Process ........................29
4.2. Other Standards Bodies ....................................29
4.3. Proprietary and Vendor Specific ...........................30
4.4. Joint Development of Media Coding Specification
and RTP Payload Format ....................................31
5. Designing Payload Formats ......................................31
5.1. Features of RTP Payload Formats ...........................32
5.1.1. Aggregation ........................................32
5.1.2. Fragmentation ......................................33
5.1.3. Interleaving and Transmission Rescheduling .........33
5.1.4. Media Back Channels ................................34
5.1.5. Media Scalability ..................................34
5.1.6. High Packet Rates ..................................37
5.2. Selecting Timestamp Definition ............................37
6. Noteworthy Aspects in Payload Format Design ....................39
6.1. Audio Payloads ............................................39
6.2. Video .....................................................40
6.3. Text ......................................................41
6.4. Application ...............................................41
7. Important Specification Sections ...............................42
7.1. Media Format Description ..................................42
7.2. Security Considerations ...................................43
7.3. Congestion Control ........................................44
7.4. IANA Considerations .......................................45
8. Authoring Tools ................................................45
8.1. Editing Tools .............................................46
8.2. Verification Tools ........................................46
9. Security Considerations ........................................47
10. Informative References ........................................47
Appendix A. RTP Payload Format Template ...........................58
A.1. Title .....................................................58
A.2. Front-Page Boilerplate ....................................58
A.3. Abstract ..................................................58
A.4. Table of Contents .........................................58
A.5. Introduction ..............................................59
A.6. Conventions, Definitions, and Abbreviations ...............59
A.7. Media Format Description ..................................59
A.8. Payload Format ............................................59
A.8.1. RTP Header Usage ......................................59
A.8.2. Payload Header ........................................59
A.8.3. Payload Data ..........................................60
A.9. Payload Examples ..........................................60
A.10. Congestion Control Considerations .........................60
A.11. Payload Format Parameters .................................60
A.11.1. Media Type Definition ................................60
A.11.2. Mapping to SDP .......................................62
A.12. IANA Considerations .......................................63
A.13. Security Considerations ...................................63
A.14. RFC Editor Considerations .................................64
A.15. References ................................................64
A.15.1. Normative References .................................64
A.15.2. Informative References ...............................64
A.16. Authors' Addresses ........................................64
Acknowledgements ..................................................64
Contributors ......................................................65
Author's Address ..................................................65
6. Noteworthy Aspects in Payload Format Design ....................39
6.1. Audio Payloads ............................................39
6.2. Video .....................................................40
6.3. Text ......................................................41
6.4. Application ...............................................41
7. Important Specification Sections ...............................42
7.1. Media Format Description ..................................42
7.2. Security Considerations ...................................43
7.3. Congestion Control ........................................44
7.4. IANA Considerations .......................................45
8. Authoring Tools ................................................45
8.1. Editing Tools .............................................46
8.2. Verification Tools ........................................46
9. Security Considerations ........................................47
10. Informative References ........................................47
Appendix A. RTP Payload Format Template ...........................58
A.1. Title .....................................................58
A.2. Front-Page Boilerplate ....................................58
A.3. Abstract ..................................................58
A.4. Table of Contents .........................................58
A.5. Introduction ..............................................59
A.6. Conventions, Definitions, and Abbreviations ...............59
A.7. Media Format Description ..................................59
A.8. Payload Format ............................................59
A.8.1. RTP Header Usage ......................................59
A.8.2. Payload Header ........................................59
A.8.3. Payload Data ..........................................60
A.9. Payload Examples ..........................................60
A.10. Congestion Control Considerations .........................60
A.11. Payload Format Parameters .................................60
A.11.1. Media Type Definition ................................60
A.11.2. Mapping to SDP .......................................62
A.12. IANA Considerations .......................................63
A.13. Security Considerations ...................................63
A.14. RFC Editor Considerations .................................64
A.15. References ................................................64
A.15.1. Normative References .................................64
A.15.2. Informative References ...............................64
A.16. Authors' Addresses ........................................64
Acknowledgements ..................................................64
Contributors ......................................................65
Author's Address ..................................................65
RTP [RFC3550] payload formats define how a specific real-time data format is structured in the payload of an RTP packet. A real-time data format without a payload format specification cannot be transported using RTP. This creates an interest in many individuals/ organizations with media encoders or other types of real-time data to define RTP payload formats. However, the specification of a well-designed RTP payload format is nontrivial and requires knowledge of both RTP and the real-time data format.
RTP[RFC3550]有效负载格式定义RTP数据包有效负载中特定实时数据格式的结构。没有有效负载格式规范的实时数据格式无法使用RTP传输。这引起了许多个人/组织的兴趣，他们使用媒体编码器或其他类型的实时数据来定义RTP有效负载格式。然而，设计良好的RTP有效负载格式的规范并不重要，需要了解RTP和实时数据格式。
This document is intended to help any author of an RTP payload format specification make important design decisions, consider important features of RTP and RTP security, etc. The document is also intended to be a good starting point for any person with little experience in the IETF and/or RTP to learn the necessary steps.
本文档旨在帮助RTP有效载荷格式规范的任何作者做出重要的设计决策，考虑RTP和RTP安全性等重要特征。该文档也意在对IETF和/或RTP中缺乏经验的任何人学习好必要的步骤的良好起点。
This document extends and updates the information that is available in "Guidelines for Writers of RTP Payload Format Specifications" [RFC2736]. Since that RFC was written, further experience has been gained on the design and specification of RTP payload formats. Several new RTP profiles and robustness tools have been defined, and these need to be considered.
本文档扩展并更新了“RTP有效负载格式规范编写者指南”[RFC2736]中的可用信息。自编写RFC以来，在RTP有效负载格式的设计和规范方面获得了进一步的经验。已经定义了几个新的RTP配置文件和健壮性工具，需要考虑这些。
This document also discusses the possible venues for defining an RTP payload format: the IETF, other standards bodies, and proprietary ones.
本文件还讨论了定义RTP有效载荷格式的可能场所：IETF、其他标准机构和专有机构。
Note, this document does discuss IETF, IANA, and RFC Editor processes and rules as they were when this document was published. This to make clear how the work to specify an RTP payload formats depends, uses, and interacts with these rules and processes. However, these rules and processes are subject to change and the formal rule and process specifications always takes precedence over what is written here.
注意，本文档确实讨论了IETF、IANA和RFC编辑器的流程和规则，正如本文档发布时一样。这是为了明确指定RTP有效负载格式的工作如何依赖、使用这些规则和流程，以及如何与这些规则和流程交互。但是，这些规则和流程可能会发生变化，正式的规则和流程规范始终优先于此处所述内容。
This document has several different parts discussing different aspects of the creation of an RTP payload format specification. Section 3 discusses the preparations the author(s) should make before starting to write a specification. Section 4 discusses the different processes used when specifying and completing a payload format, with focus on working inside the IETF. Section 5 discusses the design of payload formats themselves in detail. Section 6 discusses current design trends and provides good examples of practices that should be followed when applicable. Following that, Section 7 provides a discussion on important sections in the RTP payload format
本文档有几个不同的部分讨论创建RTP有效负载格式规范的不同方面。第3节讨论了作者在开始编写规范之前应该做的准备工作。第4节讨论了指定和完成有效负载格式时使用的不同过程，重点是在IETF内部工作。第5节详细讨论了有效负载格式本身的设计。第6节讨论了当前的设计趋势，并提供了适用时应遵循的良好实践示例。接下来，第7节讨论了RTP有效负载格式中的重要部分
specification itself such as Security Considerations and IANA Considerations. This document ends with an appendix containing a template that can be used when writing RTP payload formats specifications.
规范本身，如安全注意事项和IANA注意事项。本文档以一个附录结尾，其中包含一个模板，可在编写RTP有效负载格式规范时使用该模板。
RTP Stream: A sequence of RTP packets that together carry part or all of the content of a specific media (audio, video, text, or data whose form and meaning are defined by a specific real-time application) from a specific sender source within a given RTP session.
RTP流：一系列RTP数据包，在给定的RTP会话中，这些数据包一起携带特定媒体的部分或全部内容（音频、视频、文本或数据，其形式和含义由特定的实时应用程序定义）。
RTP Session: An association among a set of participants communicating with RTP. The distinguishing feature of an RTP session is that each session maintains a full, separate space of synchronization source (SSRC) identifiers. See also Section 3.3.1.
RTP会话：一组与RTP通信的参与者之间的关联。RTP会话的显著特征是，每个会话维护一个完整的、独立的同步源（SSRC）标识符空间。另见第3.3.1节。
RTP Payload Format: The RTP payload format specifies how units of a specific encoded media are put into the RTP packet payloads and how the fields of the RTP packet header are used, thus enabling the format to be used in RTP applications.
RTP有效负载格式：RTP有效负载格式指定如何将特定编码媒体的单元放入RTP数据包有效负载中，以及如何使用RTP数据包头的字段，从而使RTP应用程序能够使用该格式。
A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources [RFC7656] defines many useful terms.
实时传输协议（RTP）源的语义和机制分类[RFC7656]定义了许多有用的术语。
ABNF: Augmented Backus-Naur Form [RFC5234]
ABNF：扩充的巴科斯诺尔表[RFC5234]
ADU: Application Data Unit
ADU：应用数据单元
ALF: Application Level Framing
ALF：应用程序级框架
ASM: Any-Source Multicast
ASM：任何源多播
BCP: Best Current Practice
BCP：当前最佳实践
I-D: Internet-Draft
互联网草稿
IESG: Internet Engineering Steering Group
IESG：互联网工程指导小组
MTU: Maximum Transmission Unit
最大传输单位
WG: Working Group
工作组：工作组
QoS: Quality of Service
QoS：服务质量
RFC: Request For Comments
RFC：征求意见
RTP: Real-time Transport Protocol
实时传输协议
RTCP: RTP Control Protocol
RTCP:RTP控制协议
RTT: Round-Trip Time
RTT：往返时间
SSM: Source-Specific Multicast
SSM：源特定多播
As this document is both Informational and instructional rather than a specification, this document does not use any RFC 2119 language and the use of "may", "should", "recommended", and "must" carries no special connotation.
由于本文件为信息性和指导性文件，而非规范性文件，因此本文件不使用任何RFC 2119语言，且“可能”、“应该”、“建议”和“必须”的使用没有特殊含义。
RTP is a complex real-time media delivery framework, and it has a lot of details that need to be considered when writing an RTP payload format. It is also important to have a good understanding of the media codec / format so that all of its important features and properties are considered. Only when one has sufficient understanding of both parts can one produce an RTP payload format of high quality. On top of this, one needs to understand the process within the IETF and especially the Working Group responsible for standardizing payload formats (currently the PAYLOAD WG) to go quickly from the initial idea stage to a finished RFC. This and the next sections help an author prepare himself in those regards.
RTP是一个复杂的实时媒体交付框架，在编写RTP有效负载格式时需要考虑很多细节。对媒体编解码器/格式有很好的理解也很重要，以便考虑其所有重要特性和属性。只有充分了解这两个部分，才能生成高质量的RTP有效负载格式。除此之外，还需要了解IETF内的流程，尤其是负责有效载荷格式标准化的工作组（目前为有效载荷工作组），以便快速从初始构思阶段进入完成RFC。本节和下一节将帮助作者在这些方面做好准备。
It may be obvious, but it is necessary for an author of an RTP payload specification to have a solid understanding of the media to be transported. Important are not only the specifically spelled out transport aspects (if any) in the media coding specification, but also core concepts of the underlying technology. For example, an RTP payload format for video coded with inter-picture prediction will perform poorly if the payload designer does not take the use of inter-picture prediction into account. On the other hand, some (mostly older) media codecs offer error-resilience tools against bit errors, which, when misapplied over RTP, in almost all cases would only introduce overhead with no measurable return.
这可能是显而易见的，但RTP有效负载规范的作者有必要对要传输的介质有一个坚实的理解。重要的不仅是媒体编码规范中明确规定的传输方面（如果有），还有底层技术的核心概念。例如，如果有效负载设计者不考虑使用图片间预测，则用于使用图片间预测编码的视频的RTP有效负载格式将执行不良。另一方面，一些（大部分是较旧的）媒体编解码器提供了针对位错误的错误恢复工具，当在RTP上误用时，几乎所有情况下都只会引入开销，而没有可测量的回报。
The following subsections list a number of documents. Not all need to be read in full detail. However, an author basically needs to be aware of everything listed below.
以下小节列出了一些文件。并非所有这些都需要详细阅读。但是，作者基本上需要了解下面列出的所有内容。
Newcomers to the IETF are strongly recommended to read the "Tao of the IETF" [TAO] that goes through most things that one needs to know about the IETF: the history, organizational structure, how the WGs and meetings work, etc.
强烈建议IETF的新手阅读“IETF之道”[Tao]，它涵盖了人们需要了解的IETF的大部分内容：历史、组织结构、工作组和会议的工作方式等。
It is very important to note and understand the IETF Intellectual Property Rights (IPR) policy that requires early disclosures based on personal knowledge from anyone contributing in IETF. The IETF policies associated with IPR are documented in BCP 78 [BCP78] (related to copyright, including software copyright, for example, code) and BCP 79 [BCP79] (related to patent rights). These rules may be different from other standardization organizations. For example, a person that has a patent or a patent application that he or she reasonably and personally believes to cover a mechanism that gets added to the Internet-Draft they are contributing to (e.g., by submitting the draft, posting comments or suggestions on a mailing list, or speaking at a meeting) will need to make a timely IPR disclosure. Read the above documents for the authoritative rules. Failure to follow the IPR rules can have dire implications for the specification and the author(s) as discussed in [RFC6701].
注意并理解IETF知识产权（IPR）政策非常重要，该政策要求根据IETF贡献者的个人知识提前披露。与知识产权相关的IETF政策记录在BCP 78[BCP78]（与版权相关，包括软件版权，例如代码）和BCP 79[BCP79]（与专利权相关）中。这些规则可能不同于其他标准化组织。例如，一个人拥有一项专利或一项专利申请，他或她个人合理地认为该专利或专利申请涵盖了一种机制，该机制被添加到他们正在参与的互联网草案中（例如，通过提交草案、在邮件列表上发布评论或建议、或在会议上发言）需要及时披露知识产权信息。请阅读上述文件以了解权威规则。如[RFC6701]所述，不遵守IPR规则可能会对规范和作者造成严重影响。
Note: These IPR rules apply on what is specified in the RTP payload format Internet-Draft (and later RFC); an IPR that relates to a codec specification from an external body does not require IETF IPR disclosure. Informative text explaining the nature of the codec would not normally require an IETF IPR declaration. Appropriate IPR declarations for the codec itself would normally be found in files of the external body defining the codec, in accordance with that external body's own IPR rules.
注：这些知识产权规则适用于RTP有效载荷格式互联网草案（以及后来的RFC）中规定的内容；与外部主体的编解码器规范相关的IPR不需要披露IETF IPR。解释编解码器性质的信息性文本通常不需要IETF IPR声明。根据外部机构自身的IPR规则，通常可以在定义编解码器的外部机构的文件中找到编解码器本身的适当IPR声明。
The main part of the IETF process is formally defined in BCP 9 [BCP9]. BCP 25 [BCP25] describes the WG process, the relation between the IESG and the WG, and the responsibilities of WG Chairs and participants.
IETF过程的主要部分在BCP 9[BCP9]中正式定义。BCP 25[BCP25]描述了工作组流程、IESG和工作组之间的关系以及工作组主席和参与者的职责。
It is important to note that the RFC Series contains documents of several different publication streams as defined by The RFC Series and RFC Editor [RFC4844]. The most important stream for RTP payload formats authors is the IETF Stream. In this stream, the work of the IETF is published. The stream contains documents of several
需要注意的是，RFC系列包含由RFC系列和RFC编辑器[RFC4844]定义的几个不同发布流的文档。RTP有效负载格式的最重要流是IETF流。在这个流中，IETF的工作被发布。该流包含多个类型的文档
different categories: Standards Track, Informational, Experimental, Best Current Practice, and Historic. "Standards Track" contains two maturity levels: Proposed Standard and Internet Standard [RFC6410]. A Standards Track document must start as a Proposed Standard; after successful deployment and operational experience with at least two implementations, it can be moved to an Internet Standard. The Independent Submission Stream could appear to be of interest as it provides a way of publishing documents of certain categories such as Experimental and Informational with a different review process. However, as long as IETF has a WG that is chartered to work on RTP payload formats, this stream should not be used.
不同类别：标准跟踪、信息、实验、最佳当前实践和历史。“标准跟踪”包含两个成熟度级别：建议标准和互联网标准[RFC6410]。标准跟踪文件必须作为提议的标准开始；在至少两次实现的成功部署和操作经验之后，可以将其移动到Internet标准。独立提交流可能会引起人们的兴趣，因为它提供了一种通过不同的审查流程发布某些类别的文档的方法，例如实验性文档和信息性文档。然而，只要IETF有一个工作组被授权在RTP有效负载格式上工作，就不应该使用这个流。
As the content of a given RFC is not allowed to change once published, the only way to modify an RFC is to write and publish a new one that either updates or replaces the old one. Therefore, whether reading or referencing an RFC, it is important to consider both the Category field in the document header and to check if the RFC is the latest on the subject and still valid. One way of checking the current status of an RFC is to use the RFC Editor's RFC search page (https://www.rfc-editor.org/search), which displays the current status and which if any RFC has updated or obsoleted it. The RFC Editor search engine will also indicate if there exist any errata reports for the RFC. Any verified errata report contains issues of significant importance with the RFC; thus, they should be known prior to an update and replacement publication.
由于给定RFC的内容在发布后不允许更改，因此修改RFC的唯一方法是编写并发布一个新RFC，该RFC可以更新或替换旧RFC。因此，无论是读取或引用RFC，重要的是要考虑文档标题中的类别字段，并检查RFC是否是主题上最新的并且仍然有效。检查RFC当前状态的一种方法是使用RFC编辑器的RFC搜索页面(https://www.rfc-editor.org/search)，显示当前状态，如果任何RFC已更新或淘汰该状态，则显示当前状态。RFC编辑器搜索引擎还将指示RFC是否存在任何勘误表报告。任何经核实的勘误表报告均包含与RFC有重大关系的问题；因此，应在更新和替换出版物之前了解这些信息。
Before starting to write a draft, one should also read the Internet-Draft writing guidelines (http://www.ietf.org/ietf/1id-guidelines.txt), the I-D checklist (http://www.ietf.org/ID-Checklist.html), and the RFC Style Guide [RFC7322]. Another document that can be useful is "Guide for Internet Standards Writers" [RFC2360].
在开始写草稿之前，还应该阅读互联网草稿写作指南(http://www.ietf.org/ietf/1id-guidelines.txt)，I-D检查表(http://www.ietf.org/ID-Checklist.html)，以及RFC样式指南[RFC7322]。另一个有用的文档是“互联网标准编写者指南”[RFC2360]。
There are also a number of documents to consider in the process of writing drafts intended to become RFCs. These are important when writing certain types of text.
在起草旨在成为RFC的草案的过程中也有许多文件要考虑。在编写某些类型的文本时，这些都很重要。
RFC 2606: When writing examples using DNS names in Internet-Drafts, those names shall be chosen from the example.com, example.net, and example.org domains.
RFC 2606：在互联网草稿中使用DNS名称编写示例时，这些名称应从example.com、example.net和example.org域中选择。
RFC 3849: Defines the range of IPv6 unicast addresses (2001:DB8::/32) that should be used in any examples.
RFC 3849：定义应在任何示例中使用的IPv6单播地址范围（2001:DB8:：/32）。
RFC 5737: Defines the ranges of IPv4 unicast addresses reserved for documentation and examples: 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24.
RFC 5737：定义为文档和示例保留的IPv4单播地址范围：192.0.2.0/24、198.51.100.0/24和203.0.113.0/24。
RFC 5234: Augmented Backus-Naur Form (ABNF) is often used when writing text field specifications. Not commonly used in RTP payload formats, but may be useful when defining media type parameters of some complexity.
RFC 5234：在编写文本字段规范时，通常使用增广的巴科斯瑙格式（ABNF）。在RTP有效负载格式中不常用，但在定义某些复杂的媒体类型参数时可能有用。
The recommended reading for RTP consists of several different parts: design guidelines, the RTP protocol, profiles, robustness tools, and media-specific recommendations.
RTP的推荐阅读由几个不同部分组成：设计指南、RTP协议、概要文件、健壮性工具和特定于媒体的建议。
Any author of RTP payload formats should start by reading "Guidelines for Writers of RTP Payload Format Specifications" [RFC2736], which contains an introduction to the Application Level Framing (ALF) principle, the channel characteristics of IP channels, and design guidelines for RTP payload formats. The goal of ALF is to be able to transmit Application Data Units (ADUs) that are independently usable by the receiver in individual RTP packets, thus minimizing dependencies between RTP packets and the effects of packet loss.
RTP有效负载格式的任何作者都应该从阅读“RTP有效负载格式规范的作者指南”[RFC2736]开始，其中包括对应用级成帧（ALF）原理、IP信道特性和RTP有效负载格式设计指南的介绍。ALF的目标是能够在单个RTP数据包中传输接收机可独立使用的应用数据单元（ADU），从而最小化RTP数据包之间的依赖性和数据包丢失的影响。
Then, it is advisable to learn more about the RTP protocol, by studying the RTP specification "RTP: A Transport Protocol for Real-Time Applications" [RFC3550] and the existing profiles. As a complement to the Standards Track documents, there exists a book totally dedicated to RTP [CSP-RTP]. There exist several profiles for RTP today, but all are based on "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551] (abbreviated as RTP/AVP). The other profiles that one should know about are "The Secure Real-time Transport Protocol (SRTP)" (RTP/SAVP) [RFC3711], "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" [RFC4585], and "Extended Secure Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124]. It is important to understand RTP and the RTP/AVP profile in detail. For the other profiles, it is sufficient to have an understanding of what functionality they provide and the limitations they create.
然后，建议通过研究RTP规范“RTP：实时应用的传输协议”[RFC3550]和现有配置文件来了解更多关于RTP协议的信息。作为对标准跟踪文件的补充，有一本专门介绍RTP[CSP-RTP]的书。目前存在多个RTP配置文件，但都基于“具有最小控制的音频和视频会议的RTP配置文件”[RFC3551]（缩写为RTP/AVP）。我们应该了解的其他概要文件包括“安全实时传输协议（SRTP）”（RTP/SAVP）[RFC3711]，“基于RTCP的反馈的扩展RTP概要文件（RTP/AVPF）”[RFC4585]，以及“基于扩展安全实时传输控制协议（RTCP）的反馈（RTP/SAVPF）”[RFC5124]。详细了解RTP和RTP/AVP配置文件非常重要。对于其他概要文件，了解它们提供的功能以及它们创建的限制就足够了。
A number of robustness tools have been developed for RTP. The tools are for different use cases and real-time requirements.
已经为RTP开发了许多健壮性工具。这些工具用于不同的用例和实时需求。
RFC 2198: "RTP Payload for Redundant Audio Data" [RFC2198] provides functionalities to transmit redundant copies of audio or text payloads. These redundant copies are sent together with a primary format in the same RTP payload. This format relies on the RTP timestamp to determine where data belongs in a sequence; therefore, it is usually most suitable to be used with audio. However, the RTP Payload format for T.140 [RFC4103] text format also uses this format. The format's major property is that it only preserves the timestamp of the redundant payloads, not the
RFC 2198：“冗余音频数据的RTP有效载荷”[RFC2198]提供传输音频或文本有效载荷的冗余副本的功能。这些冗余副本与同一RTP有效负载中的主格式一起发送。该格式依赖于RTP时间戳来确定数据在序列中所属的位置；因此，它通常最适合与音频一起使用。但是，T.140[RFC4103]文本格式的RTP有效负载格式也使用此格式。该格式的主要特性是，它只保留冗余有效负载的时间戳，而不保留
original sequence number. This makes it unusable for most video formats. This format is also only suitable for media formats that produce relatively small RTP payloads.
原始序列号。这使得它无法用于大多数视频格式。此格式也仅适用于产生相对较小RTP有效负载的媒体格式。
RFC 6354: The "Forward-Shifted RTP Redundancy Payload Support" [RFC6354] is a variant of RFC 2198 that allows the redundant data to be transmitted prior to the original.
RFC 6354：“前移RTP冗余有效负载支持”[RFC6354]是RFC 2198的一个变体，它允许在原始数据之前传输冗余数据。
RFC 5109: The "RTP Payload Format for Generic Forward Error Correction" [RFC5109] provides an XOR-based Forward Error Correction (FEC) of the whole or parts of a number of RTP packets. This specification replaced the previous specification for XOR-based FEC [RFC2733]. These FEC packets are sent in a separate stream or as a redundant encoding using RFC 2198. This FEC scheme has certain restrictions in the number of packets it can protect. It is suitable for applications with low-to-medium delay tolerance with a limited amount of RTP packets.
RFC 5109：“通用前向纠错的RTP有效负载格式”[RFC5109]提供了一个基于异或的前向纠错（FEC），用于对多个RTP数据包的全部或部分进行纠错。本规范取代了先前基于XOR的FEC[RFC2733]规范。这些FEC分组以单独的流或使用RFC 2198作为冗余编码发送。该FEC方案在其可以保护的数据包数量上有一定的限制。它适用于RTP数据包数量有限的低到中等延迟容限的应用。
RFC 6015: "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)" [RFC6015] provides a variant of the XOR-based Generic protection defined in [RFC2733]. The main difference is to use interleaving scheme on which packets gets included as source packets for a particular protection packet. The interleaving is defined by using every L packets as source data and then producing protection data over D number of packets. Thus, each block of D x L source packets will result in L number of Repair packets, each capable of repairing one loss. The goal is to provide better burst-error robustness when the packet rate is higher.
RFC 6015：“用于1-D交错奇偶校验前向纠错（FEC）的RTP有效负载格式”[RFC6015]提供了[RFC2733]中定义的基于异或的通用保护的变体。主要区别在于使用交织方案，其中数据包作为特定保护数据包的源数据包被包括在内。交织是通过使用每L个数据包作为源数据，然后在D个数据包上生成保护数据来定义的。因此，dxl源分组的每个块将导致L个修复分组，每个能够修复一个丢失。目标是在包速率较高时提供更好的突发错误鲁棒性。
FEC Framework: "Forward Error Correction (FEC) Framework" [RFC6363] defines how to use FEC protection for arbitrary packet flows. This framework can be applied for RTP/RTCP packet flows, including using RTP for transmission of repair symbols, an example is in "RTP Payload Format for Raptor Forward Error Correction (FEC)" [RFC6682].
FEC框架：“前向纠错（FEC）框架”[RFC6363]定义了如何对任意数据包流使用FEC保护。该框架可应用于RTP/RTCP分组流，包括使用RTP传输修复符号，例如“Raptor前向纠错（FEC）的RTP有效载荷格式”[RFC6682]。
RTP Retransmission: The RTP retransmission scheme [RFC4588] is used for semi-reliability of the most important RTP packets in a RTP stream. The level of reliability between semi- and in-practice full reliability depends on the targeted properties and situation where parameters such as round-trip time (RTT) allowed additional overhead and allowable delay. It often requires the application to be quite delay tolerant as a minimum of one round-trip time plus processing delay is required to perform a retransmission. Thus, it is mostly suitable for streaming applications but may also be usable in certain other cases when operating in networks with short round-trip times.
RTP重传：RTP重传方案[RFC4588]用于RTP流中最重要的RTP数据包的半可靠性。半可靠性和实际全可靠性之间的可靠性水平取决于目标特性和情况，其中，往返时间（RTT）等参数允许额外的开销和允许的延迟。它通常要求应用程序具有相当的延迟容忍能力，因为执行重传至少需要一个往返时间加上处理延迟。因此，它主要适用于流式应用程序，但在往返时间较短的网络中运行时，在某些其他情况下也可以使用。
RTP over TCP: RFC 4571 [RFC4571] defines how one sends RTP and RTCP packets over connection-oriented transports like TCP. If one uses TCP, one gets reliability for all packets but loses some of the real-time behavior that RTP was designed to provide. Issues with TCP transport of real-time media include head-of-line blocking and wasting resources on retransmission of data that is already late. TCP is also limited to point-to-point connections, which further restricts its applicability.
TCP上的RTP:RFC 4571[RFC4571]定义了如何通过面向连接的传输（如TCP）发送RTP和RTCP数据包。如果使用TCP，则可以获得所有数据包的可靠性，但会丢失RTP设计用于提供的一些实时行为。实时媒体的TCP传输存在的问题包括线首阻塞和在重新传输已经延迟的数据时浪费资源。TCP还限于点对点连接，这进一步限制了其适用性。
There have been both discussion and design of RTP payload formats, e.g., Adaptive Multi-Rate (AMR) and AMR Wideband (AMR-WB) [RFC4867], supporting the unequal error detection provided by UDP-Lite [RFC3828]. The idea is that by not having a checksum over part of the RTP payload one can allow bit errors from the lower layers. By allowing bit errors one can increase the efficiency of some link layers and also avoid unnecessary discarding of data when the payload and media codec can get at least some benefit from the data. The main issue is that one has no idea of the level of bit errors present in the unprotected part of the payload. This makes it hard or impossible to determine whether or not one can design something usable. Payload format designers are not recommended to consider features for unequal error detection using UDP-Lite unless very clear requirements exist.
已经讨论并设计了RTP有效负载格式，例如自适应多速率（AMR）和AMR宽带（AMR-WB）[RFC4867]，支持UDP Lite[RFC3828]提供的不等错误检测。其思想是，通过在RTP有效负载的一部分上不具有校验和，可以允许来自较低层的位错误。通过允许比特错误，可以提高某些链路层的效率，并且当有效负载和媒体编解码器至少可以从数据中获得一些好处时，还可以避免不必要的数据丢弃。主要问题是，人们不知道有效载荷未受保护部分中存在的比特错误级别。这使得人们很难或不可能确定是否能设计出有用的东西。有效载荷格式设计者不推荐考虑使用UDP Lite的不相等错误检测的特征，除非存在非常明确的要求。
There also exist some management and monitoring extensions.
还存在一些管理和监视扩展。
RFC 2959: The RTP protocol Management Information Database (MIB) [RFC2959] that is used with SNMP [RFC3410] to configure and retrieve information about RTP sessions.
RFC 2959：RTP协议管理信息数据库（MIB）[RFC2959]，与SNMP[RFC3410]一起使用，以配置和检索有关RTP会话的信息。
RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consists of a framework for reports sent within RTCP. It can easily be extended by defining new report formats, which has and is occurring. The XRBLOCK WG in the IETF is chartered (at the time of writing) with defining new report formats. The list of specified formats is available in IANA's RTCP XR Block Type registry (http://www.iana.org/assignments/rtcp-xr-block-types/). The report formats that are defined in RFC 3611 provide report information on packet loss, packet duplication, packet reception times, RTCP statistics summary, and VoIP Quality. [RFC3611] also defines a mechanism that allows receivers to calculate the RTT to other session participants when used.
RFC 3611:RTCP扩展报告（RTCP XR）[RFC3611]由RTCP内发送的报告框架组成。通过定义新的报告格式，可以很容易地对其进行扩展，而新的报告格式已经出现并且正在出现。IETF中的XRBLOCK工作组（在编写本文时）被授权定义新的报告格式。IANA的RTCP XR块类型注册表中提供了指定格式的列表(http://www.iana.org/assignments/rtcp-xr-block-types/). RFC 3611中定义的报告格式提供关于数据包丢失、数据包重复、数据包接收时间、RTCP统计摘要和VoIP质量的报告信息。[RFC3611]还定义了一种机制，允许接收者在使用时向其他会话参与者计算RTT。
RMONMIB: The Remote Network Monitoring WG has defined a mechanism [RFC3577] based on usage of the MIB that can be an alternative to RTCP XR.
RMONMIB：远程网络监控工作组根据MIB的使用情况定义了一种机制[RFC3577]，该机制可以作为RTCP XR的替代方案。
A number of transport optimizations have also been developed for use in certain environments. They are all intended to be transparent and do not require special consideration by the RTP payload format writer. Thus, they are primarily listed here for informational reasons.
还开发了一些用于特定环境的传输优化。它们都是透明的，不需要RTP有效负载格式编写器特别考虑。因此，此处列出它们主要是为了提供信息。
RFC 2508: "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links" (CRTP) [RFC2508] is the first IETF-developed RTP header compression mechanism. It provides quite good compression; however, it has clear performance problems when subject to packet loss or reordering between compressor and decompressor.
RFC 2508：“压缩低速串行链路的IP/UDP/RTP报头”（CRTP）[RFC2508]是IETF开发的第一个RTP报头压缩机制。它提供了相当好的压缩；然而，当在压缩器和解压缩器之间发生数据包丢失或重新排序时，它有明显的性能问题。
RFCs 3095 and 5795: These are the base specifications of the robust header compression (ROHC) protocol version 1 [RFC3095] and version 2 [RFC5795]. This solution was created as a result of CRTP's lack of performance when compressed packets are subject to loss.
RFCs 3095和5795：这些是健壮报头压缩（ROHC）协议版本1[RFC3095]和版本2[RFC5795]的基本规范。此解决方案是由于CRTP在压缩数据包丢失时缺乏性能而创建的。
RFC 3545: Enhanced compressed RTP (E-CRTP) [RFC3545] was developed to provide extensions to CRTP that allow for better performance over links with long RTTs, packet loss, and/or reordering.
RFC 3545：开发增强型压缩RTP（E-CRTP）[RFC3545]是为了提供CRTP的扩展，允许在长RTT、丢包和/或重新排序的链路上实现更好的性能。
RFC 4170: "Tunneling Multiplexed Compressed RTP (TCRTP)" [RFC4170] is a solution that allows header compression within a tunnel carrying multiple multiplexed RTP flows. This is primarily used in voice trunking.
RFC 4170：“隧道多路复用压缩RTP（TCRTP）”[RFC4170]是一种解决方案，允许在承载多个多路复用RTP流的隧道内进行报头压缩。这主要用于语音中继。
There exist a couple of different security mechanisms that may be used with RTP. By definition, generic mechanisms are transparent for the RTP payload format and do not need special consideration by the format designer. The main reason that different solutions exist is that different applications have different requirements; thus, different solutions have been developed. For more discussion on this, please see "Options for Securing RTP Sessions" [RFC7201] and "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202]. The main properties for an RTP security mechanism are to provide confidentiality for the RTP payload, integrity protection to detect manipulation of payload and headers, and source authentication. Not all mechanisms provide all of these features, a point that will need to be considered when a specific mechanisms is chosen.
RTP可以使用两种不同的安全机制。根据定义，通用机制对于RTP有效负载格式是透明的，不需要格式设计者特别考虑。存在不同解决方案的主要原因是不同的应用有不同的需求；因此，开发了不同的解决方案。有关这方面的更多讨论，请参阅“保护RTP会话的选项”[RFC7201]和“保护RTP框架：为什么RTP不要求单一媒体安全解决方案”[RFC7202]。RTP安全机制的主要属性是为RTP有效负载提供机密性、检测有效负载和报头操纵的完整性保护以及源身份验证。并非所有机制都提供所有这些特性，在选择特定机制时需要考虑这一点。
The profile for Secure RTP - SRTP (RTP/SAVP) [RFC3711] and the derived profile (RTP/SAVPF [RFC5124]) are a solution that enables confidentiality, integrity protection, replay protection, and partial source authentication. It is the solution most commonly used with RTP at the time of writing this document. There exist several key-management solutions for SRTP, as well other choices, affecting the
安全RTP-SRTP（RTP/SAVP）[RFC3711]配置文件和派生配置文件（RTP/SAVPF[RFC5124]）是一种实现机密性、完整性保护、重播保护和部分源身份验证的解决方案。在编写本文档时，它是RTP最常用的解决方案。SRTP存在多个关键管理解决方案，以及其他选择，影响
security properties. For a more in-depth review of the options and solutions other than SRTP consult "Options for Securing RTP Sessions" [RFC7201].
安全属性。有关SRTP以外的选项和解决方案的更深入审查，请参阅“保护RTP会话的选项”[RFC7201]。
This section reviews a number of RTP features and concepts that are available in RTP, independent of the payload format. The RTP payload format can make use of these when appropriate, and even affect the behavior (RTP timestamp and marker bit), but it is important to note that not all features and concepts are relevant to every payload format. This section does not remove the necessity to read up on RTP. However, it does point out a few important details to remember when designing a payload format.
本节回顾了RTP中提供的许多RTP特性和概念，这些特性和概念与有效负载格式无关。RTP有效负载格式可以在适当的时候使用它们，甚至影响行为（RTP时间戳和标记位），但需要注意的是，并非所有的特性和概念都与每个有效负载格式相关。本节不排除阅读RTP的必要性。然而，它确实指出了设计有效负载格式时需要记住的一些重要细节。
The definition of the RTP session from RFC 3550 is:
RFC 3550中RTP会话的定义为：
An association among a set of participants communicating with RTP. A participant may be involved in multiple RTP sessions at the same time. In a multimedia session, each medium is typically carried in a separate RTP session with its own RTCP packets unless the encoding itself multiplexes multiple media into a single data stream. A participant distinguishes multiple RTP sessions by reception of different sessions using different pairs of destination transport addresses, where a pair of transport addresses comprises one network address plus a pair of ports for RTP and RTCP. All participants in an RTP session may share a common destination transport address pair, as in the case of IP multicast, or the pairs may be different for each participant, as in the case of individual unicast network addresses and port pairs. In the unicast case, a participant may receive from all other participants in the session using the same pair of ports, or may use a distinct pair of ports for each.
与RTP通信的一组参与者之间的关联。参与者可能同时参与多个RTP会话。在多媒体会话中，除非编码本身将多个媒体多路复用到单个数据流中，否则每个媒体通常在单独的RTP会话中携带其自身的RTCP数据包。参与者通过使用不同的目的地传输地址对接收不同会话来区分多个RTP会话，其中一对传输地址包括一个网络地址加上一对RTP和RTCP端口。RTP会话中的所有参与者可以共享一个公共目的地传输地址对，如在IP多播的情况下，或者对于每个参与者，该对可以不同，如在单个单播网络地址和端口对的情况下。在单播情况下，参与者可以使用相同的端口对从会话中的所有其他参与者接收，或者可以为每个端口使用不同的端口对。
The distinguishing feature of an RTP session is that each session maintains a full, separate space of SSRC identifiers (defined next). The set of participants included in one RTP session consists of those that can receive an SSRC identifier transmitted by any one of the participants either in RTP as the SSRC or a CSRC (also defined below) or in RTCP. For example, consider a three-party conference implemented using unicast UDP with each participant receiving from the other two on separate port pairs. If each participant sends RTCP feedback about data received from one other participant only back to that participant, then the conference is composed of three separate point-to-point RTP sessions. If each participant provides RTCP feedback about its
RTP会话的显著特征是，每个会话维护一个完整的、单独的SSRC标识符空间（定义见下文）。一个RTP会话中包含的参与者集包括那些可以接收任何一个参与者在RTP中作为SSRC或CSC（定义见下文）或RTCP传输的SSRC标识符的参与者。例如，考虑使用单播UDP实现的三方会议，每个参与者在单独的端口对上从其他两个接收。如果每个参与者仅向该参与者发送关于从另一参与者收到的数据的RTCP反馈，则会议由三个独立的点对点RTP会话组成。如果每个参与者提供RTCP对其
reception of one other participant to both of the other participants, then the conference is composed of one multi-party RTP session. The latter case simulates the behavior that would occur with IP multicast communication among the three participants.
将另一名与会者接待给其他两名与会者，然后会议由一个多方RTP会议组成。后一种情况模拟了三个参与者之间IP多播通信的行为。
The RTP framework allows the variations defined here, but a particular control protocol or application design will usually impose constraints on these variations.
RTP框架允许此处定义的变体，但特定的控制协议或应用程序设计通常会对这些变体施加约束。
The RTP header contains a number of fields. Two fields always require additional specification by the RTP payload format, namely the RTP timestamp and the marker bit. Certain RTP payload formats also use the RTP sequence number to realize certain functionalities, primarily related to the order of their application data units. The payload type is used to indicate the used payload format. The SSRC is used to distinguish RTP packets from multiple senders and media sources identifying the RTP stream. Finally, [RFC5285] specifies how to transport payload format independent metadata relating to the RTP packet or stream.
RTP标头包含多个字段。两个字段始终需要RTP有效负载格式的附加规范，即RTP时间戳和标记位。某些RTP有效负载格式还使用RTP序列号来实现某些功能，这些功能主要与其应用程序数据单元的顺序有关。有效负载类型用于指示使用的有效负载格式。SSRC用于区分来自多个发送方的RTP数据包和标识RTP流的媒体源。最后，[RFC5285]指定如何传输与RTP数据包或流相关的有效负载格式独立的元数据。
Marker Bit: A single bit normally used to provide important indications. In audio, it is normally used to indicate the start of a talk burst. This enables jitter buffer adaptation prior to the beginning of the burst with minimal audio quality impact. In video, the marker bit is normally used to indicate the last packet part of a frame. This enables a decoder to finish decoding the picture, where it otherwise may need to wait for the next packet to explicitly know that the frame is finished.
标记位：通常用于提供重要指示的单个位。在音频中，它通常用于指示通话突发的开始。这在突发开始之前启用抖动缓冲自适应，对音频质量的影响最小。在视频中，标记位通常用于指示帧的最后一个数据包部分。这使得解码器能够完成对图片的解码，否则它可能需要等待下一个分组明确地知道帧已经完成。
Timestamp: The RTP timestamp indicates the time instance the media sample belongs to. For discrete media like video, it normally indicates when the media (frame) was sampled. For continuous media, it normally indicates the first time instance the media present in the payload represents. For audio, this is the sampling time of the first sample. All RTP payload formats must specify the meaning of the timestamp value and the clock rates allowed. Selecting a timestamp rate is an active design choice and is further discussed in Section 5.2.
时间戳：RTP时间戳表示媒体样本所属的时间实例。对于离散媒体（如视频），它通常指示媒体（帧）的采样时间。对于连续介质，它通常表示有效负载中存在的介质代表的第一个实例。对于音频，这是第一个采样的采样时间。所有RTP有效负载格式必须指定时间戳值的含义和允许的时钟速率。选择时间戳速率是一种积极的设计选择，将在第5.2节中进一步讨论。
Discontinuous Transmission (DTX) that is common among speech codecs, typically results in gaps or jumps in the timestamp values due to that there is no media payload to transmit and the next used timestamp value represent the actual sampling time of the data transmitted.
语音编解码器中常见的不连续传输（DTX）通常会导致时间戳值出现间隙或跳跃，因为没有要传输的媒体负载，下一个使用的时间戳值表示传输数据的实际采样时间。
Sequence Number: The sequence number is monotonically increasing and is set as the packet is sent. This property is used in many payload formats to recover the order of everything from the whole stream down to fragments of application data units (ADUs) and the order they need to be decoded. Discontinuous transmissions do not result in gaps in the sequence number, as it is monotonically increasing for each sent RTP packet.
序列号：序列号单调递增，在发送数据包时设置。此属性在许多有效负载格式中用于恢复从整个流到应用程序数据单元（ADU）片段的所有内容的顺序以及它们需要解码的顺序。不连续传输不会导致序列号中的间隔，因为它对于每个发送的RTP数据包是单调增加的。
Payload Type: The payload type is used to indicate, on a per-packet basis, which format is used. The binding between a payload type number and a payload format and its configuration are dynamically bound and RTP session specific. The configuration information can be bound to a payload type value by out-of-band signaling (Section 3.4). An example of this would be video decoder configuration information. Commonly, the same payload type is used for a media stream for the whole duration of a session. However, in some cases it may be necessary to change the payload format or its configuration during the session.
有效负载类型：有效负载类型用于在每个数据包的基础上指示所使用的格式。有效负载类型号和有效负载格式及其配置之间的绑定是动态绑定的，并且特定于RTP会话。配置信息可以通过带外信令绑定到有效负载类型值（第3.4节）。这方面的一个例子是视频解码器配置信息。通常，在整个会话期间，相同的有效负载类型用于媒体流。但是，在某些情况下，可能需要在会话期间更改有效负载格式或其配置。
SSRC: The synchronization source (SSRC) identifier is normally not used by a payload format other than to identify the RTP timestamp and sequence number space a packet belongs to, allowing simultaneously reception of multiple media sources. However, some of the RTP mechanisms for improving resilience to packet loss uses multiple SSRCs to separate original data and repair or redundant data, as well as multi-stream transmission of scalable codecs.
SSRC：有效负载格式通常不使用同步源（SSRC）标识符，而只是用于标识数据包所属的RTP时间戳和序列号空间，从而允许同时接收多个媒体源。然而，一些用于提高分组丢失恢复能力的RTP机制使用多个SSRC来分离原始数据和修复或冗余数据，以及可伸缩编解码器的多流传输。
Header Extensions: RTP payload formats often need to include metadata relating to the payload data being transported. Such metadata is sent as a payload header, at the start of the payload section of the RTP packet. The RTP packet also includes space for a header extension [RFC5285]; this can be used to transport payload format independent metadata, for example, an SMPTE time code for the packet [RFC5484]. The RTP header extensions are not intended to carry headers that relate to a particular payload format, and must not contain information needed in order to decode the payload.
标头扩展：RTP有效负载格式通常需要包含与正在传输的有效负载数据相关的元数据。这种元数据在RTP数据包的有效负载部分的开头作为有效负载报头发送。RTP分组还包括用于报头扩展的空间[RFC5285]；这可用于传输与有效负载格式无关的元数据，例如，数据包的SMPTE时间码[RFC5484]。RTP报头扩展不打算携带与特定有效负载格式相关的报头，并且不得包含解码有效负载所需的信息。
The remaining fields do not commonly influence the RTP payload format. The padding bit is worth clarifying as it indicates that one or more bytes are appended after the RTP payload. This padding must be removed by a receiver before payload format processing can occur. Thus, it is completely separate from any padding that may occur within the payload format itself.
其余字段通常不会影响RTP有效负载格式。填充位值得澄清，因为它指示在RTP有效负载之后追加一个或多个字节。在进行有效负载格式处理之前，接收器必须删除此填充。因此，它与有效负载格式本身中可能出现的任何填充完全分离。
RTP has three multiplexing points that are used for different purposes. A proper understanding of this is important to correctly use them.
RTP有三个用于不同目的的多路复用点。正确理解这一点对于正确使用它们很重要。
The first one is separation of RTP streams of different types or usages, which is accomplished using different RTP sessions. So, for example, in the common multimedia session with audio and video, RTP commonly multiplexes audio and video in different RTP sessions. To achieve this separation, transport-level functionalities are used, normally UDP port numbers. Different RTP sessions can also be used to realize layered scalability as it allows a receiver to select one or more layers for multicast RTP sessions simply by joining the multicast groups over which the desired layers are transported. This separation also allows different Quality of Service (QoS) to be applied to different media types. Use of multiple transport flows has potential issues due to NAT and firewall traversal. The choices how one applies RTP sessions as well as transport flows can affect the transport properties an RTP media stream experiences.
第一种是分离不同类型或用途的RTP流，这是通过使用不同的RTP会话来实现的。因此，例如，在具有音频和视频的公共多媒体会话中，RTP通常在不同的RTP会话中复用音频和视频。为了实现这种分离，使用了传输级功能，通常是UDP端口号。不同的RTP会话还可用于实现分层可伸缩性，因为它允许接收器仅通过加入在其上传输所需层的多播组来为多播RTP会话选择一个或多个层。这种分离还允许对不同的媒体类型应用不同的服务质量（QoS）。由于NAT和防火墙穿越，使用多个传输流存在潜在问题。如何应用RTP会话以及传输流的选择会影响RTP媒体流体验的传输属性。
The next multiplexing point is separation of different RTP streams within an RTP session. Here, RTP uses the SSRC to identify individual sources of RTP streams. An example of individual media sources would be the capture of different microphones that are carried in an RTP session for audio, independently of whether they are connected to the same host or different hosts. There also exist cases where a single media source, is transmitted using multiple RTP streams. For each SSRC, a unique RTP sequence number and timestamp space is used.
下一个复用点是在RTP会话中分离不同的RTP流。这里，RTP使用SSRC来识别RTP流的各个源。单个媒体源的一个示例是捕获RTP会话中携带的用于音频的不同话筒，而与它们是连接到同一主机还是不同主机无关。还存在使用多个RTP流传输单个媒体源的情况。对于每个SSRC，使用唯一的RTP序列号和时间戳空间。
The third multiplexing point is the RTP header payload type field. The payload type identifies what format the content in the RTP payload has. This includes different payload format configurations, different codecs, and also usage of robustness mechanisms like the one described in RFC 2198 [RFC2198].
第三个多路复用点是RTP报头有效负载类型字段。有效负载类型标识RTP有效负载中内容的格式。这包括不同的有效负载格式配置、不同的编解码器，以及使用RFC 2198[RFC2198]中描述的健壮性机制。
There are several types of synchronization, and we will here describe how RTP handles the different types:
有几种类型的同步，我们将在这里描述RTP如何处理不同类型的同步：
Intra media: The synchronization within a media stream from a synchronization source (SSRC) is accomplished using the RTP timestamp field. Each RTP packet carries the RTP timestamp, which specifies the position in time of the media payload contained in this packet relative to the content of other RTP packets in the same RTP stream (i.e., a given SSRC). This is especially useful
媒体内：使用RTP时间戳字段完成来自同步源（SSRC）的媒体流内的同步。每个RTP分组携带RTP时间戳，该时间戳指定该分组中包含的媒体有效载荷相对于同一RTP流（即，给定SSRC）中其他RTP分组的内容的时间位置。这尤其有用
in cases of discontinuous transmissions. Discontinuities can be caused by network conditions; when extensive losses occur the RTP timestamp tells the receiver how much later than previously received media the present media should be played out.
在不连续传输的情况下。网络条件可能导致不连续性；当大量丢失发生时，RTP时间戳告诉接收器当前媒体的播放时间应比以前接收的媒体晚多少。
Inter-media: Applications commonly have a desire to use several media sources, possibly of different media types, at the same time. Thus, there exists a need to synchronize different media from the same endpoint. This puts two requirements on RTP: the possibility to determine which media are from the same endpoint and if they should be synchronized with each other and the functionality to facilitate the synchronization itself.
跨媒体：应用程序通常希望同时使用多个媒体源，可能是不同的媒体类型。因此，需要同步来自同一端点的不同媒体。这对RTP提出了两个要求：确定哪些介质来自同一端点、它们是否应该彼此同步的可能性以及促进同步本身的功能。
The first step in inter-media synchronization is to determine which SSRCs in each session should be synchronized with each other. This is accomplished by comparing the CNAME fields in the RTCP source description (SDES) packets. SSRCs with the same CNAME sent in any of multiple RTP sessions can be synchronized.
媒体间同步的第一步是确定每个会话中的哪些SSRC应该彼此同步。这是通过比较RTCP源描述（SDES）数据包中的CNAME字段来实现的。可以同步在任意多个RTP会话中发送的具有相同CNAME的SSRC。
The actual RTCP mechanism for inter-media synchronization is based on the idea that each RTP stream provides a position on the media specific time line (measured in RTP timestamp ticks) and a common reference time line. The common reference time line is expressed in RTCP as a wall-clock time in the Network Time Protocol (NTP) format. It is important to notice that the wall-clock time is not required to be synchronized between hosts, for example, by using NTP [RFC5905]. It can even have nothing at all to do with the actual time; for example, the host system's up-time can be used for this purpose. The important factor is that all media streams from a particular source that are being synchronized use the same reference clock to derive their relative RTP timestamp time scales. The type of reference clock and its timebase can be signaled using RTP Clock Source Signaling [RFC7273].
用于媒体间同步的实际RTCP机制基于以下思想：每个RTP流在媒体特定时间线上提供一个位置（以RTP时间戳刻度测量）和一个公共参考时间线上。公共参考时间线以RTCP表示为网络时间协议（NTP）格式的挂钟时间。需要注意的是，不需要在主机之间同步挂钟时间，例如，通过使用NTP[RFC5905]。它甚至与实际时间毫无关系；例如，主机系统的启动时间可用于此目的。重要的因素是，来自正在同步的特定源的所有媒体流使用相同的参考时钟来推导其相对RTP时间戳时间尺度。参考时钟的类型及其时基可以使用RTP时钟源信令[RFC7273]来发送信号。
Figure 1 illustrates how if one receives RTCP Sender Report (SR) packet P1 for one RTP stream and RTCP SR packet P2 for the other RTP stream, then one can calculate the corresponding RTP timestamp values for any arbitrary point in time T. However, to be able to do that, it is also required to know the RTP timestamp rates for each RTP stream currently used in the sessions.
图1说明了如果接收到一个RTP流的RTCP发送者报告（SR）数据包P1和另一个RTP流的RTCP SR数据包P2，则可以计算任意时间点T的相应RTP时间戳值。然而，为了能够做到这一点，还需要知道会话中当前使用的每个RTP流的RTP时间戳速率。
TS1 --+---------------+------->
| |
P1 |
| |
NTP ---+-----+---------T------>
| |
P2 |
| |
TS2 ---------+---------+---X-->
TS1 --+---------------+------->
| |
P1 |
| |
NTP ---+-----+---------T------>
| |
P2 |
| |
TS2 ---------+---------+---X-->
Figure 1: RTCP Synchronization
图1:RTCP同步
Assume that medium 1 uses an RTP timestamp clock rate of 16 kHz, and medium 2 uses a clock rate of 90 kHz. Then, TS1 and TS2 for point T can be calculated in the following way: TS1(T) = TS1(P1) + 16000 * (NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)). This calculation is useful as it allows the implementation to generate a common synchronization point for which all time values are provided (TS1(T), TS2(T) and T). So, when one wishes to calculate the NTP time that the timestamp value present in packet X corresponds to, one can do that in the following way: NTP(X) = NTP(T) + (TS2(X) - TS2(T))/90000.
假设介质1使用16 kHz的RTP时间戳时钟速率，介质2使用90 kHz的时钟速率。然后，点T的TS1和TS2可按以下方式计算：TS1（T）=TS1（P1）+16000*（NTP（T）-NTP（P1））和TS2（T）=TS2（P2）+90000*（NTP（T）-NTP（P2））。此计算非常有用，因为它允许实现生成一个公共同步点，为该点提供所有时间值（TS1（T）、TS2（T）和T）。因此，当希望计算分组X中存在的时间戳值对应的NTP时间时，可以通过以下方式进行：NTP（X）=NTP（T）+（TS2（X）-TS2（T））/90000。
Improved signaling for layered codecs and fast tune-in have been specified in "Rapid Synchronization for RTP Flows" [RFC6051].
“RTP流的快速同步”[RFC6051]中规定了分层编解码器和快速调谐的改进信令。
Leap seconds are extra seconds added or seconds removed to keep our clocks in sync with the earth's rotation. Adding or removing seconds can impact the reference clock as discussed in "RTP and Leap Seconds" [RFC7164]; also, in cases where the RTP timestamp values are derived using the wall clock during the leap second event, errors can occur. Implementations need to consider leap seconds and should consider the recommendations in [RFC7164].
闰秒是额外增加或减少的秒数，以保持我们的时钟与地球自转同步。添加或删除秒数可能会影响参考时钟，如“RTP和闰秒”[RFC7164]中所述；此外，在闰秒事件期间使用挂钟导出RTP时间戳值的情况下，可能会发生错误。实现需要考虑跳跃秒，并且应该考虑[RCF7164]中的建议。
RTP payload formats are used in the context of application signaling protocols such as SIP [RFC3261] using the Session Description Protocol (SDP) [RFC4566] with Offer/Answer [RFC3264], RTSP [RFC7826], or the Session Announcement Protocol [RFC2974]. These examples all use out-of-band signaling to indicate which type of RTP streams are desired to be used in the session and how they are configured. To be able to declare or negotiate the media format and RTP payload packetization, the payload format must be given an identifier. In addition to the identifier, many payload formats also have the need to signal further configuration information out-of-band for the RTP payloads prior to the media transport session.
RTP有效负载格式在应用信令协议的上下文中使用，例如使用会话描述协议（SDP）[RFC4566]和提供/应答[RFC3264]、RTSP[RFC7826]或会话公告协议[RFC2974]的SIP[RFC3261]。这些示例都使用带外信令来指示希望在会话中使用哪种类型的RTP流以及如何配置它们。为了能够声明或协商媒体格式和RTP有效负载打包，必须为有效负载格式提供一个标识符。除了标识符之外，许多有效负载格式还需要在媒体传输会话之前向RTP有效负载的带外发送更多配置信息的信号。
The above examples of session-establishing protocols all use SDP, but other session description formats may be used. For example, there was discussion of a new XML-based session description format within the IETF (SDP-NG). In the end, the proposal did not get beyond draft protocol specification because of the enormous installed base of SDP implementations. However, to avoid locking the usage of RTP to SDP based out-of-band signaling, the payload formats are identified using a separate definition format for the identifier and associated parameters. That format is the media type.
上述会话建立协议的示例都使用SDP，但也可以使用其他会话描述格式。例如，在IETF（SDP-NG）中讨论了一种新的基于XML的会话描述格式。最后，由于SDP实现的巨大安装基础，该提案没有超出协议规范草案。然而，为了避免将RTP的使用锁定到基于SDP的带外信令，使用标识符和相关参数的单独定义格式来识别有效负载格式。这种格式就是媒体类型。
Media types [RFC6838] are identifiers originally created for identifying media formats included in email. In this usage, they were known as MIME types, where the expansion of the MIME acronym includes the word "mail". The term "media type" was introduced to reflect a broader usage, which includes HTTP [RFC7231], Message Session Relay Protocol (MSRP) [RFC4975], and many other protocols to identify arbitrary content carried within the protocols. Media types also provide a media hierarchy that fits RTP payload formats well. Media type names are of two parts and consist of content type and sub-type separated with a slash, e.g., 'audio/PCMA' or 'video/ h263-2000'. It is important to choose the correct content-type when creating the media type identifying an RTP payload format. However, in most cases, there is little doubt what content type the format belongs to. Guidelines for choosing the correct media type and registration rules for media type names are provided in "Media Type Specifications and Registration Procedures" [RFC6838]. The additional rules for media types for RTP payload formats are provided in "Media Type Registration of RTP Payload Formats" [RFC4855].
媒体类型[RFC6838]是最初为标识电子邮件中包含的媒体格式而创建的标识符。在这种用法中，它们被称为MIME类型，其中MIME首字母缩略词的扩展包括单词“mail”。引入术语“媒体类型”是为了反映更广泛的用途，包括HTTP[RFC7231]、消息会话中继协议（MSRP）[RFC4975]和许多其他用于识别协议中携带的任意内容的协议。媒体类型还提供了一个媒体层次结构，它非常适合RTP有效负载格式。媒体类型名称由两部分组成，由内容类型和用斜杠分隔的子类型组成，例如“音频/PCMA”或“视频/h263-2000”。创建标识RTP有效负载格式的媒体类型时，选择正确的内容类型非常重要。但是，在大多数情况下，毫无疑问，格式属于什么内容类型。“介质类型规范和注册程序”[RFC6838]中提供了选择正确介质类型和介质类型名称注册规则的指南。RTP有效负载格式的媒体类型的附加规则在“RTP有效负载格式的媒体类型注册”[RFC4855]中提供。
Registration of the RTP payload name is something that is required to avoid name collision in the future. Note that "x-" names are not suitable for any documented format as they have the same problem with name collision and can't be registered. The list of already-registered media types can be found at <https://www.iana.org/assignments/media-types/media-types.xhtml>.
注册RTP有效负载名称是避免将来名称冲突所必需的。请注意，“x-”名称不适用于任何文档格式，因为它们与名称冲突有相同的问题，无法注册。已注册的媒体类型列表可在以下位置找到：<https://www.iana.org/assignments/media-types/media-types.xhtml>.
Media types are allowed any number of parameters, which may be required or optional for that media type. They are always specified on the form "name=value". There exist no restrictions on how the value is defined from the media type's perspective, except that parameters must have a value. However, the usage of media types in
介质类型允许有任意数量的参数，这些参数对于该介质类型可能是必需的或可选的。它们总是以“名称=值”的形式指定。对于如何从媒体类型的角度定义该值，不存在任何限制，但参数必须有一个值。但是，中媒体类型的使用
SDP, etc., has resulted in the following restrictions that need to be followed to make media types usable for RTP-identifying payload formats:
SDP等导致了需要遵循以下限制，以使媒体类型可用于RTP识别有效负载格式：
1. Arbitrary binary content in the parameters is allowed, but it needs to be encoded so that it can be placed within text-based protocols. Base64 [RFC4648] is recommended, but for shorter content Base16 [RFC4648] may be more appropriate as it is simpler to interpret for humans. This needs to be explicitly stated when defining a media type parameter with binary values.
1. 允许参数中包含任意二进制内容，但需要对其进行编码，以便将其放入基于文本的协议中。建议使用Base64[RFC4648]，但对于较短的内容，Base16[RFC4648]可能更合适，因为它更容易为人类解释。在使用二进制值定义媒体类型参数时，需要明确说明这一点。
2. The end of the value needs to be easily found when parsing a message. Thus, parameter values that are continuous and not interrupted by common text separators, such as space and semicolon characters, are recommended. If that is not possible, some type of escaping should be used. Usage of quote (") is recommended; do not forget to provide a method of encoding any character used for quoting inside the quoted element.
2. 解析消息时，需要轻松找到值的结尾。因此，建议使用连续且不被常用文本分隔符（如空格和分号字符）打断的参数值。如果不可能，则应使用某种类型的转义。建议使用引号（“）；不要忘记提供一种在引号元素内对用于引号的任何字符进行编码的方法。
3. A common representation form for the media type and its parameters is on a single line. In that case, the media type is followed by a semicolon-separated list of the parameter value pairs, e.g.:
3. 媒体类型及其参数的通用表示形式在一行上。在这种情况下，媒体类型后面是以分号分隔的参数值对列表，例如：
audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2
audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2
Since SDP [RFC4566] is so commonly used as an out-of-band signaling protocol, a mapping of the media type into SDP exists. The details on how to map the media type and its parameters into SDP are described in [RFC4855]. However, this is not sufficient to explain how certain parameters must be interpreted, for example, in the context of Offer/Answer negotiation [RFC3264].
由于SDP[RFC4566]通常用作带外信令协议，因此存在媒体类型到SDP的映射。有关如何将媒体类型及其参数映射到SDP的详细信息，请参见[RFC4855]。然而，这不足以解释某些参数必须如何解释，例如，在要约/应答协商[RFC3264]的上下文中。
The Offer/Answer (O/A) model allows SIP to negotiate which media formats and payload formats are to be used in a session and how they are to be configured. However, O/A does not define a default behavior; instead, it points out the need to define how parameters behave. To make things even more complex, the direction of media within a session has an impact on these rules, so that some cases may require separate descriptions for RTP streams that are send-only, receive-only, or both sent and received as identified by the SDP attributes a=sendonly, a=recvonly, and a=sendrecv. In addition, the usage of multicast adds further limitations as the same RTP stream is
提供/应答（O/A）模型允许SIP协商在会话中使用哪些媒体格式和有效负载格式以及如何配置它们。但是，O/A没有定义默认行为；相反，它指出需要定义参数的行为方式。为了使事情更加复杂，会话中媒体的方向对这些规则有影响，因此某些情况下可能需要对由SDP属性a=sendonly、a=RecvoOnly和a=sendrecv标识的仅发送、仅接收或同时发送和接收的RTP流进行单独描述。此外，由于使用相同的RTP流，多播的使用增加了进一步的限制
delivered to all participants. If those multicast-imposed restrictions are too limiting for unicast, then separate rules for unicast and multicast will be required.
交付给所有参与者。如果这些多播施加的限制对于单播来说太过有限，那么单播和多播将需要单独的规则。
The simplest and most common O/A interpretation is that a parameter is defined to be declarative; i.e., the SDP Offer/Answer sending agent can declare a value and that has no direct impact on the other agent's values. This declared value applies to all media that are going to be sent to the declaring entity. For example, most video codecs have a level parameter that tells the other participants the highest complexity the video decoder supports. The level parameter can be declared independently by two participants in a unicast session as it will be the media sender's responsibility to transmit a video stream that fulfills the limitation the other side has declared. However, in multicast, it will be necessary to send a stream that follows the limitation of the weakest receiver, i.e., the one that supports the lowest level. To simplify the negotiation in these cases, it is common to require any answerer to a multicast session to take a yes or no approach to parameters.
最简单也是最常见的O/A解释是将参数定义为声明性的；i、 例如，SDP提供/应答发送代理可以声明一个值，该值对其他代理的值没有直接影响。此声明的值适用于将要发送到声明实体的所有媒体。例如，大多数视频编解码器都有一个级别参数，告诉其他参与者视频解码器支持的最高复杂度。级别参数可以由单播会话中的两个参与者独立声明，因为媒体发送方负责传输满足另一方声明的限制的视频流。然而，在多播中，必须发送一个遵循最弱接收器限制的流，即支持最低级别的接收器。为了简化这些情况下的协商，通常要求多播会话的任何应答者对参数采取是或否的方法。
A "negotiated" parameter is a different case, for which both sides need to agree on its value. Such a parameter requires the answerer to either accept it as it is offered or remove the payload type the parameter belonged to from its answer. The removal of the payload type from the answer indicates to the offerer the lack of support for the parameter values presented. An unfortunate implication of the need to use complete payload types to indicate each possible configuration so as to maximize the chances of achieving interoperability, is that the number of necessary payload types can quickly grow large. This is one reason to limit the total number of sets of capabilities that may be implemented.
“协商”参数是另一种情况，双方需要就其价值达成一致。这样的参数要求应答者要么接受提供的参数，要么从其应答中删除该参数所属的有效负载类型。从答案中删除有效负载类型向报价人表明，对所提供的参数值缺乏支持。需要使用完整的有效负载类型来指示每个可能的配置，以便最大限度地实现互操作性，这一点的一个不幸含义是，必要的有效负载类型的数量可能会迅速增加。这是限制可能实现的功能集总数的一个原因。
The most problematic type of parameters are those that relate to the media the entity sends. They do not really fit the O/A model, but can be shoehorned in. Examples of such parameters can be found in the H.264 video codec's payload format [RFC6184], where the name of all parameters with this property starts with "sprop-". The issue with these parameters is that they declare properties for a RTP stream that the other party may not accept. The best one can make of the situation is to explain the assumption that the other party will accept the same parameter value for the media it will receive as the offerer of the session has proposed. If the answerer needs to change any declarative parameter relating to streams it will receive, then the offerer may be required to make a new offer to update the parameter values for its outgoing RTP stream.
最有问题的参数类型是与实体发送的媒体相关的参数。它们并不真正适合O/A模型，但可以嵌入其中。此类参数的示例可以在H.264视频编解码器的有效负载格式[RFC6184]中找到，其中具有此属性的所有参数的名称以“sprop-”开头。这些参数的问题在于，它们为RTP流声明了另一方可能不接受的属性。对于这种情况，最好的解释是，假设另一方将接受其将收到的媒体的参数值，与会议的发盘人所提议的相同。如果应答者需要更改与其将接收的流相关的任何声明性参数，则可能需要报价者发出新报价，以更新其传出RTP流的参数值。
Another issue to consider is the send-only RTP streams in offers. Parameters that relate to what the answering entity accepts to receive have no meaning other than to provide a template for the answer. It is worth pointing out in the specification that these really provide a set of parameter values that the sender recommends. Note that send-only streams in answers will need to indicate the offerer's parameters to ensure that the offerer can match the answer to the offer.
另一个需要考虑的问题是在发送中只发送RTP流。与应答实体接受接收的内容相关的参数除了为应答提供模板外没有其他意义。值得在规范中指出的是，它们确实提供了发送者推荐的一组参数值。请注意，答案中的仅发送流需要指明报价人的参数，以确保报价人能够将答案与报价相匹配。
A further issue with Offer/Answer that complicates things is that the answerer is allowed to renumber the payload types between offer and answer. This is not recommended, but allowed for support of gateways to the ITU conferencing suite. This means that it must be possible to bind answers for payload types to the payload types in the offer even when the payload type number has been changed, and some of the proposed payload types have been removed. This binding must normally be done by matching the configurations originally offered against those in the answer. This may require specification in the payload format of which parameters that constitute a configuration, for example, as done in Section 8.2.2 of the H.264 RTP Payload format [RFC6184], which states: "The parameters identifying a media format configuration for H.264 are profile-level-id and packetization-mode".
要约/应答的另一个使事情复杂化的问题是，应答者可以在要约和应答之间重新编号有效负载类型。不建议这样做，但允许支持到ITU会议套件的网关。这意味着，即使有效负载类型编号已更改，并且某些建议的有效负载类型已删除，也必须能够将有效负载类型的答案绑定到报价中的有效负载类型。这种绑定通常必须通过将最初提供的配置与应答中的配置进行匹配来完成。这可能需要有效载荷格式的规范，其中的参数构成配置，例如，如H.264 RTP有效载荷格式[RFC6184]第8.2.2节所述，其中规定：“识别H.264媒体格式配置的参数是配置文件级别id和打包模式”。
SAP (Session Announcement Protocol) [RFC2974] was experimentally used for announcing multicast sessions. Similar but better protocols are using SDP in a declarative style to configure multicast-based applications. Independently of the usage of Source-Specific Multicast (SSM) [RFC3569] or Any-Source Multicast (ASM), the SDP provided by these configuration delivery protocols applies to all participants. All media that is sent to the session must follow the RTP stream definition as specified by the SDP. This enables everyone to receive the session if they support the configuration. Here, SDP provides a one-way channel with no possibility to affect the configuration that the session creator has decided upon. Any RTP payload format that requires parameters for the send direction and that needs individual values per implementation or instance will fail in a SAP session for a multicast session allowing anyone to send.
SAP（Session Announcement Protocol）[RFC2974]被实验性地用于宣布多播会话。类似但更好的协议使用声明式SDP来配置基于多播的应用程序。独立于源特定多播（SSM）[RFC3569]或任何源多播（ASM）的使用，这些配置交付协议提供的SDP适用于所有参与者。发送到会话的所有媒体必须遵循SDP指定的RTP流定义。这使每个人都能够接收会话（如果他们支持该配置）。这里，SDP提供单向通道，不可能影响会话创建者决定的配置。对于允许任何人发送的多播会话，任何需要发送方向参数且每个实现或实例需要单个值的RTP有效负载格式都将在SAP会话中失败。
Real-Time Streaming Protocol (RTSP) [RFC7826] allows the negotiation of transport parameters for RTP streams that are part of a streaming session between a server and client. RTSP has divided the transport parameters from the media configuration. SDP is commonly used for media configuration in RTSP and is sent to the client prior to session establishment, either through use of the DESCRIBE method or
实时流协议（RTSP）[RFC7826]允许协商RTP流的传输参数，RTP流是服务器和客户端之间流会话的一部分。RTSP已将传输参数与介质配置分开。SDP通常用于RTSP中的媒体配置，并在会话建立之前通过使用描述方法或
by means of an out-of-band channel like HTTP, email, etc. The SDP is used to determine which RTP streams and what formats are being used prior to session establishment.
通过HTTP、电子邮件等带外通道，SDP用于确定会话建立之前使用的RTP流和格式。
Thus, both SAP and RTSP use SDP to configure receivers and senders with a predetermined configuration for a RTP stream including the payload format and any of its parameters. All parameters are used in a declarative fashion. This can result in different treatment of parameters between Offer/Answer and declarative usage in RTSP and SAP. Any such difference will need to be spelled out by the payload format specification.
因此，SAP和RTSP都使用SDP为RTP流（包括有效负载格式及其任何参数）配置具有预定配置的接收器和发送器。所有参数都以声明方式使用。这可能导致在RTSP和SAP中对提供/应答和声明性使用之间的参数进行不同的处理。任何此类差异都需要通过有效负载格式规范加以说明。
The general channel characteristics that RTP flows experience are documented in Section 3 of "Guidelines for Writers of RTP Payload Format Specifications" [RFC2736]. The discussion below provides additional information.
RTP流经历的一般信道特性记录在“RTP有效负载格式规范编写者指南”[RFC2736]第3节中。下面的讨论提供了更多信息。
At the time of writing, the most common IP Maximum Transmission Unit (MTU) in commonly deployed link layers is 1500 bytes (Ethernet data payload). However, there exist both links with smaller MTUs and links with much larger MTUs. An example for links with small MTU size is older generation cellular links. Certain parts of the Internet already support an IP MTU of 8000 bytes or more, but these are limited islands. The most likely places to find MTUs larger than 1500 bytes are within enterprise networks, university networks, data centers, storage networks, and over high capacity (10 Gbps or more) links. There is a slow, ongoing evolution towards larger MTU sizes. However, at the same time, it has become common to use tunneling protocols, often multiple ones, whose overhead when added together can shrink the MTU significantly. Thus, there exists a need both to consider limited MTUs as well as enable support of larger MTUs. This should be considered in the design, especially in regard to features such as aggregation of independently decodable data units.
在撰写本文时，通常部署的链路层中最常见的IP最大传输单元（MTU）为1500字节（以太网数据有效负载）。然而，存在具有较小MTU的链路和具有更大MTU的链路。具有较小MTU大小的链路的一个示例是老一代蜂窝链路。互联网的某些部分已经支持8000字节或更多的IP MTU，但这些都是有限的孤岛。在企业网络、大学网络、数据中心、存储网络和超大容量（10 Gbps或以上）链路中，最有可能找到大于1500字节的MTU。向更大的MTU尺寸发展是一个缓慢、持续的过程。然而，同时，使用隧道协议（通常是多个协议）已变得很普遍，当将这些协议的开销加在一起时，可以显著减少MTU。因此，既需要考虑有限的MTU，也允许支持更大的MTU。在设计中应考虑这一点，尤其是在诸如独立可解码数据单元的聚合等特性方面。
Routers and switches on the network path between an IP sender and a particular receiver can exhibit different behaviors affecting the end-to-end characteristics. One of the more important aspects of this is queuing behavior. Routers and switches have some amount of queuing to handle temporary bursts of data that designated to leave the switch or router on the same egress link. A queue, when not empty, results in an increased path delay.
IP发送方和特定接收方之间的网络路径上的路由器和交换机可以表现出影响端到端特性的不同行为。其中一个更重要的方面是排队行为。路由器和交换机有一定数量的队列来处理指定离开同一出口链路上的交换机或路由器的临时数据突发。队列不为空时，会导致路径延迟增加。
The implementation of the queuing affects the delay and also how congestion signals (Explicit Congestion Notification (ECN) [RFC6679] or packet drops) are provided to the flow. The other aspects are if the flow shares the queue with other flows and how the implementation affects the flow interaction. This becomes important, for example, when real-time flows interact with long-lived TCP flows. TCP has a built-in behavior in its congestion control that strives to fill the buffer; thus, all flows sharing the buffer experienced the delay build up.
队列的实现会影响延迟以及拥塞信号（显式拥塞通知（ECN）[RFC6679]或分组丢弃）如何提供给流。其他方面包括流是否与其他流共享队列以及实现如何影响流交互。例如，当实时流与长寿命TCP流交互时，这一点变得非常重要。TCP在其拥塞控制中有一个内置行为，它努力填充缓冲区；因此，共享缓冲区的所有流都经历了延迟累积。
A common, but quite poor, queue-handling mechanism is tail-drop, i.e., only drop packets when the incoming packet doesn't fit in the queue. If a bad queuing algorithm is combined with too much queue space, the queuing time can grow to be very significant and can even become multiple seconds. This is called "bufferbloat" [BLOAT]. Active Queue Management (AQM) is a term covering mechanisms that try to do something smarter by actively managing the queue, for example, sending congestion signals earlier by dropping packets earlier in the queue. The behavior also affects the flow interactions. For example, Random Early Detection (RED) [RED] selects which packet(s) to drop randomly. This gives flows that have more packets in the queue a higher probability to experience the packet loss (congestion signal). There is ongoing work in the IETF WG AQM to find suitable mechanisms to recommend for implementation and reduce the use of tail-drop.
一种常见但非常差的队列处理机制是尾部丢弃，即，只有当传入的数据包不适合队列时才丢弃数据包。如果一个糟糕的排队算法与太多的队列空间相结合，排队时间可能会增长到非常显著的程度，甚至可能达到几秒钟。这称为“缓冲区膨胀”[BLOAT]。主动队列管理（AQM）是一个术语，涵盖了一些机制，这些机制通过主动管理队列来尝试做一些更智能的事情，例如，通过在队列中更早地丢弃数据包来更早地发送拥塞信号。该行为也会影响流的相互作用。例如，随机早期检测（RED）[RED]选择要随机丢弃的数据包。这使得队列中有更多数据包的流更有可能经历数据包丢失（拥塞信号）。IETF工作组AQM正在进行工作，以找到合适的机制来建议实施，并减少尾部脱落的使用。
Using best-effort Internet has no guarantees for the path's properties. QoS mechanisms are intended to provide the possibility to bound the path properties. Where Diffserv [RFC2475] markings affect the queuing and forwarding behaviors of routers, the mechanism provides only statistical guarantees and care in how much marked packets of different types that are entering the network. Flow-based QoS, like IntServ [RFC1633], has the potential for stricter guarantees as the properties are agreed on by each hop on the path, at the cost of per-flow state in the network.
使用尽力而为的Internet无法保证路径的属性。QoS机制旨在提供绑定路径属性的可能性。当Diffserv[RFC2475]标记影响路由器的排队和转发行为时，该机制仅提供统计保证，并关注进入网络的不同类型的标记数据包的数量。与IntServ[RFC1633]一样，基于流的QoS有可能得到更严格的保证，因为属性由路径上的每个跃点商定，而代价是网络中的每个流状态。
This section discusses the recommended process to produce an RTP payload format in the described venues. This is to document the best current practice on how to get a well-designed and specified payload format as quickly as possible. For specifications that are defined by standards bodies other than the IETF, the primary milestone is the registration of the media type for the RTP payload format. For
本节讨论在所述场馆中生成RTP有效负载格式的推荐过程。这是为了记录关于如何尽快获得设计良好且指定的有效负载格式的最佳当前实践。对于IETF以外的标准机构定义的规范，主要里程碑是注册RTP有效负载格式的媒体类型。对于
proprietary media formats, the primary goal depends on whether interoperability is desired at the RTP level. However, there is also the issue of ensuring best possible quality of any specification.
专有媒体格式，主要目标取决于RTP级别是否需要互操作性。然而，也存在确保任何规格的最佳质量的问题。
For all standardized media formats, it is recommended that the payload format be specified in the IETF. The main reason is to provide an openly available RTP payload format specification that has been reviewed by people experienced with RTP payload formats. At the time of writing, this work is done in the PAYLOAD Working Group (WG), but that may change in the future.
对于所有标准化媒体格式，建议在IETF中指定有效负载格式。主要原因是提供一个公开可用的RTP有效负载格式规范，该规范已经过RTP有效负载格式经验丰富的人员的审查。在撰写本文时，这项工作是在有效载荷工作组（WG）中完成的，但将来可能会发生变化。
There are a number of steps that an RTP payload format should go through from the initial idea until it is published. This also documents the process that the PAYLOAD WG applies when working with RTP payload formats.
RTP有效负载格式从最初的想法到发布，应该经历许多步骤。这还记录了有效负载工作组在使用RTP有效负载格式时应用的过程。
Idea: Determine the need for an RTP payload format as an IETF specification.
想法：确定RTP有效负载格式作为IETF规范的需求。
Initial effort: Using this document as a guideline, one should be able to get started on the work. If one's media codec doesn't fit any of the common design patterns or one has problems understanding what the most suitable way forward is, then one should contact the PAYLOAD WG and/or the WG Chairs. The goal of this stage is to have an initial individual draft. This draft needs to focus on the introductory parts that describe the real-time media format and the basic idea on how to packetize it. Not all the details are required to be filled in. However, the security chapter is not something that one should skip, even initially. From the start, it is important to consider any serious security risks that need to be solved. The first step is completed when one has a draft that is sufficiently detailed for a first review by the WG. The less confident one is of the solution, the less work should be spent on details; instead, concentrate on the codec properties and what is required to make the packetization work.
最初的努力：使用本文档作为指导，应该能够开始工作。如果您的媒体编解码器不符合任何常见的设计模式，或者您在理解最合适的前进方向时遇到问题，那么您应该联系有效负载工作组和/或工作组。这一阶段的目标是有一个初步的个人草案。本草稿需要重点介绍描述实时媒体格式的介绍部分，以及如何将其打包的基本思想。并非所有细节都需要填写。然而，安全一章是不应该跳过的，即使是最初。从一开始，重要的是要考虑任何严重的安全风险，需要解决。当一个人有足够详细的草案供工作组第一次审查时，第一步就完成了。对解决方案的信心越低，在细节上花费的工作就越少；相反，请专注于编解码器属性以及使打包工作正常所需的内容。
Submission of the first version: When one has performed the above, one submits the draft as an individual draft (https://datatracker.ietf.org/submit/). This can be done at any time, except for a period prior to an IETF meeting (see important dates related to the next IETF meeting for draft submission cutoff date). When the Internet-Draft announcement has been sent out on
提交第一版：完成上述工作后，将草案作为单独草案提交(https://datatracker.ietf.org/submit/). 这可以在任何时候进行，IETF会议之前的一段时间除外（草案提交截止日期见与下一次IETF会议相关的重要日期）。当互联网公告草案于
the draft announcement list (https://www.ietf.org/mailman/listinfo/I-D-Announce), forward it to the PAYLOAD WG (https://www.ietf.org/mailman/listinfo/payload) and request that it be reviewed. In the email, outline any issues the authors currently have with the design.
公告清单草案(https://www.ietf.org/mailman/listinfo/I-D-Announce)，将其转发到有效负载工作组(https://www.ietf.org/mailman/listinfo/payload)并要求对其进行审查。在电子邮件中，概述作者目前与设计有关的任何问题。
Iterative improvements: Taking the feedback received into account, one updates the draft and tries resolve issues. New revisions of the draft can be submitted at any time (again except for a short period before meetings). It is recommended to submit a new version whenever one has made major updates or has new issues that are easiest to discuss in the context of a new draft version.
迭代改进：考虑收到的反馈，更新草案并尝试解决问题。草案的新修订可随时提交（会议前短期除外）。建议在进行重大更新或有最容易在新版本草案中讨论的新问题时提交新版本。
Becoming a WG document: Given that the definition of RTP payload formats is part of the PAYLOAD WG's charter, RTP payload formats that are going to be published as Standards Track RFCs need to become WG documents. Becoming a WG document means that the WG Chairs or an appointed document shepherd are responsible for administrative handling, for example, issuing publication requests. However, be aware that making a document into a WG document changes the formal ownership and responsibility from the individual authors to the WG. The initial authors normally continue being the document editors, unless unusual circumstances occur. The PAYLOAD WG accepts new RTP payload formats based on their suitability and document maturity. The document maturity is a requirement to ensure that there are dedicated document editors and that there exists a good solution.
成为工作组文件：鉴于RTP有效负载格式的定义是有效负载工作组章程的一部分，将作为标准跟踪RFC发布的RTP有效负载格式需要成为工作组文件。成为工作组文件意味着工作组主席或指定的文件管理员负责行政处理，例如发布发布请求。但是，请注意，将文档转换为工作组文档会改变单个作者对工作组的正式所有权和责任。最初的作者通常继续担任文档编辑，除非出现异常情况。有效负载工作组根据其适用性和文档成熟度接受新的RTP有效负载格式。文档成熟度是确保有专门的文档编辑器以及存在良好解决方案的要求。
Iterative improvements: The updates and review cycles continue until the draft has reached the level of maturity suitable for publication. The authors are responsible for judging when the document is ready for the next step, most likely WG Last Call, but they can ask the WG chairs or Shepherd.
迭代改进：更新和审查周期将持续，直到草案达到适合发布的成熟度。作者负责判断文档何时准备好进行下一步，很可能是工作组的最后一次呼叫，但他们可以询问工作组主席或Shepherd。
WG Last Call: A WG Last Call of at least two weeks is always performed for payload formats in the PAYLOAD WG (see Section 7.4 of [RFC2418]). The authors request WG Last Call for a draft when they think it is mature enough for publication. The WG Chairs or shepherd perform a review to check if they agree with the authors' assessment. If the WG Chairs or shepherd agree on the maturity, the WG Last Call is announced on the WG mailing list. If there are issues raised, these need to be addressed with an updated draft version. For any more substantial changes to the draft, a new WG Last Call is announced for the updated version. Minor changes, like editorial fixes, can be progressed without an additional WG Last Call.
WG Last Call（工作组最后调用）：对于有效负载工作组中的有效负载格式，始终执行至少两周的工作组最后调用（见[RFC2418]第7.4节）。当作者认为草稿已经足够成熟，可以出版时，他们要求工作组最后一次征求意见稿。工作组主席或shepherd进行审查，以检查他们是否同意作者的评估。如果工作组主席或shepherd同意到期日，工作组最后一次通话将在工作组邮件列表中公布。如果提出了问题，则需要通过更新的草案版本解决这些问题。对于草案的任何实质性更改，将宣布更新版本的新工作组最后通知。微小的更改，如编辑修复，无需额外的WG Last Call即可进行。
Publication requested: For WG documents, the WG Chairs or shepherd request publication of the draft after it has passed WG Last Call. After this, the approval and publication process described in BCP 9 [BCP9] is performed. The status after the publication has been requested can be tracked using the IETF Datatracker [TRACKER]. Documents do not expire as they normally do after publication has been requested, so authors do not have to issue keep-alive updates. In addition, any submission of document updates requires the approval of WG Chair(s). The authors are commonly asked to address comments or issues raised by the IESG. The authors also do one last review of the document immediately prior to its publication as an RFC to ensure that no errors or formatting problems have been introduced during the publication process.
要求公布：对于工作组文件，工作组主席或shepherd在通过工作组最后一次会议后要求公布草案。在此之后，执行BCP 9[BCP9]中描述的批准和发布流程。可以使用IETF数据跟踪器[TRACKER]跟踪请求发布后的状态。文档不会像通常在请求发布后那样过期，因此作者不必发布保持活动状态的更新。此外，任何文件更新的提交都需要工作组主席的批准。作者通常被要求回答IESG提出的评论或问题。作者还将在文件作为RFC发布之前对其进行最后一次审查，以确保在发布过程中不会出现错误或格式问题。
WG meetings are for discussing issues, not presentations. This means that most RTP payload formats should never need to be discussed in a WG meeting. RTP payload formats that would be discussed are either those with controversial issues that failed to be resolved on the mailing list or those including new design concepts worth a general discussion.
工作组会议是讨论问题，而不是介绍。这意味着大多数RTP有效负载格式不需要在工作组会议上讨论。将要讨论的RTP有效负载格式要么是那些有争议的问题但在邮件列表中没有得到解决的格式，要么是那些包含值得一般讨论的新设计概念的格式。
There exists no requirement to present or discuss a draft at a WG meeting before it becomes published as an RFC. Thus, even authors who lack the possibility to go to WG meetings should be able to successfully specify an RTP payload format in the IETF. WG meetings may become necessary only if the draft gets stuck in a serious debate that cannot easily be resolved.
在草案作为RFC发布之前，不要求在工作组会议上提交或讨论草案。因此，即使是无法参加工作组会议的作者也应该能够在IETF中成功地指定RTP有效载荷格式。只有在草案陷入无法轻松解决的严肃辩论时，工作组会议才有必要。
To simplify the work of the PAYLOAD WG Chairs and WG members, a specific Internet-Draft file-naming convention shall be used for RTP payload formats. Individual submissions shall be named using the template: draft-<lead author family name>-payload-rtp-<descriptive name>-<version>. The WG documents shall be named according to this template: draft-ietf-payload-rtp-<descriptive name>-<version>. The inclusion of "payload" in the draft file name ensures that the search for "payload-" will find all PAYLOAD-related drafts. Inclusion of "rtp" tells us that it is an RTP payload format draft. The descriptive name should be as short as possible while still describing what the payload format is for. It is recommended to use the media format or codec abbreviation. Please note that the version must start at 00 and is increased by one for each submission to the IETF secretary of the draft. No version numbers may be skipped. For more details on draft naming, please see Section 7 of [ID-GUIDE].
为简化有效载荷工作组主席和工作组成员的工作，RTP有效载荷格式应使用特定的互联网文件命名约定草案。个人提交的文件应使用以下模板命名：草稿-<主要作者姓氏>-有效载荷rtp-<描述性名称>-<版本>。工作组文件应根据以下模板命名：ietf有效载荷rtp草案-<描述性名称>-<版本>。草案文件名中包含“payload”可确保搜索“payload-”将找到所有与有效负载相关的草案。“rtp”的加入告诉我们它是一个rtp有效负载格式草案。描述性名称应尽可能简短，同时仍描述有效负载格式的用途。建议使用媒体格式或编解码器缩写。请注意，版本必须从00开始，并且每次向IETF秘书处提交草案时增加一个版本。不能跳过任何版本号。有关草案命名的更多详细信息，请参见[ID-GUIDE]第7节。
When writing an Internet-Draft for an RTP payload format, one should observe some few considerations (that may be somewhat divergent from the style of other IETF documents and/or the media coding spec's author group may use):
在为RTP有效载荷格式编写互联网草案时，应注意以下几点（可能与其他IETF文件和/或媒体编码规范作者组可能使用的风格有所不同）：
Include Motivations: In the IETF, it is common to include the motivation for why a particular design or technical path was chosen. These are not long statements: a sentence here and there explaining why suffice.
包括动机：在IETF中，通常包括选择特定设计或技术路径的动机。这些不是很长的陈述：一句话在这里和那里解释为什么就足够了。
Use the Defined Terminology: There exists defined terminology both in RTP and in the media codec specification for which the RTP payload format is designed. A payload format specification needs to use both to make clear the relation of features and their functions. It is unwise to introduce or, worse, use without introduction, terminology that appears to be more accessible to average readers but may miss certain nuances that the defined terms imply. An RTP payload format author can assume the reader to be reasonably familiar with the terminology in the media coding specification.
使用定义的术语：RTP和媒体编解码器规范中都有定义的术语，RTP有效负载格式就是针对这些术语设计的。有效负载格式规范需要同时使用这两者来明确特征及其功能之间的关系。引入，或者更糟糕的是，在没有引入的情况下使用，普通读者似乎更容易理解的术语是不明智的，但可能会忽略定义术语所暗示的某些细微差别。RTP有效负载格式的作者可以假设读者对媒体编码规范中的术语相当熟悉。
Keeping It Simple: The IETF has a history of specifications that are focused on their main usage. Historically, some RTP payload formats have a lot of modes and features, while the actual deployments have only included the most basic features that had very clear requirements. Time and effort can be saved by focusing on only the most important use cases and keeping the solution simple. An extension mechanism should be provided to enable backward-compatible extensions, if that is an organic fit.
保持简单：IETF有一个专注于其主要用途的规范历史。从历史上看，一些RTP有效负载格式有很多模式和特性，而实际部署只包括最基本的特性，这些特性有非常明确的要求。通过只关注最重要的用例并保持解决方案简单，可以节省时间和精力。如果向后兼容的扩展是有机的，那么应该提供扩展机制来支持向后兼容的扩展。
Normative Requirements: When writing specifications, there is commonly a need to make it clear when something is normative and at what level. In the IETF, the most common method is to use "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119], which defines the meaning of "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL".
规范性要求：在编写规范时，通常需要明确什么时候是规范性的，在什么级别。在IETF中，最常用的方法是使用“RFC中用于表示需求水平的关键词”[RFC2119]，它定义了“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不建议”、“不建议”、“可”和“可选”的含义。
There a number of ways to lose a lot of time in the above process. This section discusses what to do and what to avoid.
在上述过程中，有许多方法会浪费大量时间。本节讨论应做什么和应避免什么。
o Do not update the draft only for the meeting deadline. An update to each meeting automatically limits the draft to three updates per year. Instead, ignore the meeting schedule and publish new versions as soon as possible.
o 不要仅在会议截止日期前更新草案。每次会议的更新会自动将草稿限制为每年三次更新。相反，请忽略会议日程安排，并尽快发布新版本。
o Try to avoid requesting reviews when people are busy, like the few weeks before a meeting. It is actually more likely that people have time for them directly after a meeting.
o 当人们很忙时，尽量避免要求评论，比如开会前的几周。事实上，人们更有可能在会议结束后有时间与他们交谈。
o Perform draft updates quickly. A common mistake is that the authors let the draft slip. By performing updates to the draft text directly after getting resolution on an issue, things speed up. This minimizes the delay that the author has direct control over. The time taken for reviews, responses from Area Directors and WG Chairs, etc., can be much harder to speed up.
o 快速执行草稿更新。一个常见的错误是作者疏忽了草稿。通过在问题得到解决后直接对草案文本进行更新，事情会加快。这样可以最大限度地减少作者直接控制的延迟。审查、区域主管和工作组主席的回应等所需的时间可能更难加快。
o Do not fail to take human nature into account. It happens that people forget or need to be reminded about tasks. Send a kind reminder to the people you are waiting for if things take longer than expected. Ask people to estimate when they expect to fulfill the requested task.
o 不要不考虑人性。人们往往会忘记或需要提醒任务。如果事情比预期的时间长，给你正在等待的人发一个善意的提醒。让员工估计他们期望何时完成要求的任务。
o Ensure there is enough review. It is common that documents take a long time and many iterations because not enough review is performed in each iteration. To improve the amount of review you get on your own document, trade review time with other document authors. Make a deal with some other document author that you will review their draft if they review yours. Even inexperienced reviewers can help with language, editorial, or clarity issues. Also, try approaching the more experienced people in the WG and getting them to commit to a review. The WG Chairs cannot, even if desirable, be expected to review all versions. Due to workload, the Chairs may need to concentrate on key points in a draft evolution like checking on initial submissions, a draft's readiness to become a WG document, or its readiness for WG Last Call.
o 确保有足够的审查。文档花费很长时间和多次迭代是很常见的，因为在每次迭代中没有执行足够的评审。要提高您对自己文档的审阅量，请与其他文档作者交换审阅时间。与其他文档作者达成协议，如果他们审阅您的草稿，您将审阅他们的草稿。即使是没有经验的评论员也可以帮助解决语言、编辑或清晰度问题。此外，试着与工作组中更有经验的人接触，让他们承诺进行审查。即使可取，工作组主席也不能期望审查所有版本。由于工作量，主席们可能需要将注意力集中在草案演变过程中的关键点上，如检查初始提交的文件、草案是否准备好成为工作组文件或是否准备好工作组最后一次电话会议。
Other standards bodies may define RTP payloads in their own specifications. When they do this, they are strongly recommended to contact the PAYLOAD WG Chairs and request review of the work. It is recommended that at least two review steps are performed. The first
其他标准机构可在其自身规范中定义RTP有效载荷。当他们这样做时，强烈建议他们联系工作组主席并要求审查工作。建议至少执行两个审查步骤。第一
should be early in the process when more fundamental issues can be easily resolved without abandoning a lot of effort. Then, when nearing completion, but while it is still possible to update the specification, a second review should be scheduled. In that pass, the quality can be assessed; hopefully, no updates will be needed. Using this procedure can avoid both conflicting definitions and serious mistakes, like breaking certain aspects of the RTP model.
应该在过程的早期，在不放弃大量努力的情况下，更基本的问题可以轻松解决。然后，在接近完成时，但仍有可能更新规范，应安排第二次审查。在这一过程中，可以对质量进行评估；希望不需要更新。使用此过程可以避免定义冲突和严重错误，如破坏RTP模型的某些方面。
RTP payload media types may be registered in the standards tree by other standards bodies. The requirements on the organization are outlined in the media types registration documents [RFC4855] and [RFC6838]). This registration requires a request to the IESG, which ensures that the filled-in registration template is acceptable. To avoid last-minute problems with these registrations the registration template must be sent for review both to the PAYLOAD WG and the media types list (ietf-types@iana.org) and is something that should be included in the IETF reviews of the payload format specification.
RTP有效负载介质类型可由其他标准机构在标准树中注册。媒体类型注册文件[RFC4855]和[RFC6838]概述了对组织的要求。此注册需要向IESG发出请求，以确保填写的注册模板是可接受的。为了避免这些注册在最后一刻出现问题，必须将注册模板发送给有效负载工作组和媒体类型列表（ietf）进行审查-types@iana.org)并且应该包括在IETF对有效载荷格式规范的审查中。
Proprietary RTP payload formats are commonly specified when the real-time media format is proprietary and not intended to be part of any standardized system. However, there are reasons why also proprietary formats should be correctly documented and registered:
当实时媒体格式是专有的且不打算成为任何标准化系统的一部分时，通常指定专有RTP有效负载格式。但是，也有一些原因说明为什么也应该正确记录和注册专有格式：
o Usage in a standardized signaling environment, such as SIP/SDP. RTP needs to be configured with the RTP profiles, payload formats, and their payload types being used. To accomplish this, it is desirable to have registered media type names to ensure that the names do not collide with those of other formats.
o 在标准化信令环境（如SIP/SDP）中的使用。RTP需要配置RTP配置文件、有效负载格式以及所使用的有效负载类型。为此，需要注册媒体类型名称，以确保名称不会与其他格式的名称冲突。
o Sharing with business partners. As RTP payload formats are used for communication, situations often arise where business partners would like to support a proprietary format. Having a well-written specification of the format will save time and money for both parties, as interoperability will be much easier to accomplish.
o 与业务伙伴共享。由于RTP有效负载格式用于通信，通常会出现业务合作伙伴希望支持专有格式的情况。有一个编写良好的格式规范将为双方节省时间和金钱，因为互操作性将更容易实现。
o To ensure interoperability between different implementations on different platforms.
o 确保不同平台上不同实现之间的互操作性。
To avoid name collisions, there is a central registry keeping track of the registered media type names used by different RTP payload formats. When it comes to proprietary formats, they should be registered in the vendor's own tree. All vendor-specific registrations use sub-type names that start with "vnd.<vendor-name>". Names in the vendor's own tree are not required to be registered with IANA. However, registration [RFC6838] is recommended if the media type is used at all in public environments.
为了避免名称冲突，有一个中央注册表，用于跟踪不同RTP有效负载格式使用的已注册媒体类型名称。当涉及到专有格式时，它们应该在供应商自己的树中注册。所有特定于供应商的注册都使用以“vnd.<vendor name>”开头的子类型名称。供应商自身树中的名称不需要向IANA注册。但是，如果媒体类型在公共环境中使用，则建议注册[RFC6838]。
If interoperability at the RTP level is desired, a payload type specification should be standardized in the IETF following the process described above. The IETF does not require full disclosure of the codec when defining an RTP payload format to carry that codec, but a description must be provided that is sufficient to allow the IETF to judge whether the payload format is well designed. The media type identifier assigned to a standardized payload format of this sort will lie in the standards tree rather than the vendor tree.
如果需要RTP级别的互操作性，则应按照上述过程在IETF中标准化有效负载类型规范。当定义RTP有效载荷格式以承载该编解码器时，IETF不要求完全公开该编解码器，但必须提供足以允许IETF判断有效载荷格式是否设计良好的描述。分配给此类标准有效负载格式的媒体类型标识符将位于标准树中，而不是供应商树中。
4.4. Joint Development of Media Coding Specification and RTP Payload Format
4.4. 媒体编码规范和RTP有效载荷格式的联合开发
In the last decade, there have been a few cases where the media codec and the associated RTP payload format have been developed concurrently and jointly. Developing the two specs not only concurrently but also jointly, in close cooperation with the group developing the media codec, allows one to leverage the benefits joint source/channel coding can provide. Doing so has historically resulted in well-performing payload formats and in success of both the media coding specification and associated RTP payload format. Insofar, whenever the opportunity presents it, it may be useful to closely keep the media coding group in the loop (through appropriate liaison means whatever those may be) and influence the media coding specification to be RTP friendly. One example for such a media coding specification is H.264, where the RTP payload header co-serves as the H.264 NAL unit header and vice versa, and is documented in both specifications.
在过去的十年中，有一些情况下，媒体编解码器和相关的RTP有效载荷格式被同时和联合开发。与开发媒体编解码器的团队密切合作，不仅同时而且联合开发这两个规范，可以利用联合信源/信道编码可以提供的好处。这样做在历史上已经产生了性能良好的有效负载格式，并成功地实现了媒体编码规范和相关的RTP有效负载格式。到目前为止，只要有机会，密切联系媒体编码组（通过适当的联络方式，无论这些联络方式是什么）并影响媒体编码规范，使其对RTP友好可能是有用的。这种媒体编码规范的一个示例是H.264，其中RTP有效负载报头共同用作H.264 NAL单元报头，反之亦然，并且在两个规范中都有记录。
The best summary of payload format design is KISS (Keep It Simple, Stupid). A simple payload format is easier to review for correctness, easier to implement, and has low complexity. Unfortunately, contradictory requirements sometimes make it hard to do things simply. Complexity issues and problems that occur for RTP payload formats are:
有效负载格式设计的最佳总结是KISS（保持简单，愚蠢）。简单的有效负载格式更容易检查正确性，更容易实现，并且具有较低的复杂性。不幸的是，相互矛盾的需求有时使简单地做事情变得困难。RTP有效负载格式的复杂性问题和出现的问题包括：
Too many configurations: Contradictory requirements lead to the result that one configuration is created for each conceivable case. Such contradictory requirements are often between functionality and bandwidth. This outcome has two big disadvantages; First all configurations need to be implemented. Second, the user application must select the most suitable configuration. Selecting the best configuration can be very difficult and, in negotiating applications, this can create interoperability problems. The recommendation is to try to select
配置过多：相互矛盾的需求导致为每个可能的情况创建一个配置。这种相互矛盾的需求往往介于功能和带宽之间。这一结果有两大缺点；首先，需要实现所有配置。其次，用户应用程序必须选择最合适的配置。选择最佳配置可能非常困难，在协商应用程序时，这可能会产生互操作性问题。建议尝试选择
a very limited set of configurations (preferably one) that perform well for the most common cases and are capable of handling the other cases, but maybe not that well.
一组非常有限的配置（最好是一个），在最常见的情况下表现良好，并且能够处理其他情况，但可能没有那么好。
Hard to implement: Certain payload formats may become difficult to implement both correctly and efficiently. This needs to be considered in the design.
难以实现：某些有效负载格式可能难以正确有效地实现。这需要在设计中加以考虑。
Interaction with general mechanisms: Special solutions may create issues with deployed tools for RTP, such as tools for more robust transport of RTP. For example, a requirement for an unbroken sequence number space creates issues for mechanisms relying on payload type switching interleaving media-independent resilience within a stream.
与通用机制的交互：特殊的解决方案可能会导致RTP部署工具出现问题，例如用于更健壮的RTP传输的工具。例如，对未中断序列号空间的要求为依赖于有效负载类型切换的机制在流中交错媒体独立弹性产生了问题。
There are a number of common features in RTP payload formats. There is no general requirement to support these features; instead, their applicability must be considered for each payload format. In fact, it may be that certain features are not even applicable.
RTP有效负载格式中有许多常见特性。没有支持这些功能的一般要求；相反，必须考虑每种有效负载格式的适用性。事实上，某些功能甚至可能不适用。
Aggregation allows for the inclusion of multiple Application Data Units (ADUs) within the same RTP payload. This is commonly supported for codecs that produce ADUs of sizes smaller than the IP MTU. One reason for the use of aggregation is the reduction of header overhead (IP/UDP/RTP headers). When setting into relation the ADU size and the MTU size, do remember that the MTU may be significantly larger than 1500 bytes. An MTU of 9000 bytes is available today and an MTU of 64k may be available in the future. Many speech codecs have the property of ADUs of a few fixed sizes. Video encoders may generally produce ADUs of quite flexible sizes. Thus, the need for aggregation may be less. But some codecs produce small ADUs mixed with large ones, for example, H.264 Supplemental Enhancement Information (SEI) messages. Sending individual SEI message in separate packets are not efficient compared to combing the with other ADUs. Also, some small ADUs are, within the media domain, semantically coupled to the larger ADUs (for example, in-band parameter sets in H.264 [RFC6184]). In such cases, aggregation is sensible, even if not required from a payload/header overhead viewpoint. There also exist cases when the ADUs are pre-produced and can't be adopted to a specific networks MTU. Instead, their packetization needs to be adopted to the network. All above factors should be taken into account when deciding on the inclusion of aggregation, and weighting its benefits
聚合允许在同一RTP负载中包含多个应用程序数据单元（ADU）。这通常适用于产生小于IP MTU的ADU的编解码器。使用聚合的一个原因是减少了报头开销（IP/UDP/RTP报头）。当设置ADU大小和MTU大小的关系时，请记住MTU可能明显大于1500字节。现在可以使用9000字节的MTU，将来可能可以使用64k的MTU。许多语音编解码器都具有ADU的特性，只有几个固定大小。视频编码器通常可以产生尺寸相当灵活的ADU。因此，对聚合的需求可能更少。但是一些编解码器会产生小ADU和大ADU的混合，例如，H.264补充增强信息（SEI）消息。与与其他ADU组合相比，在单独的数据包中发送单个SEI消息并不高效。此外，在媒体域内，一些小的adu在语义上耦合到较大的adu（例如，H.264[RFC6184]中的带内参数集）。在这种情况下，聚合是合理的，即使从负载/报头开销的角度来看不需要聚合。也存在ADU是预先生产的，无法用于特定网络MTU的情况。相反，需要将其打包到网络中。在决定是否包含聚合并对其效益进行加权时，应考虑上述所有因素
against the complexity of defining them (which can be significant especially when aggregation is performed over ADUs with different playback times).
针对定义它们的复杂性（这可能非常重要，尤其是在具有不同播放时间的ADU上执行聚合时）。
The main disadvantage of aggregation, beyond implementation complexity, is the extra delay introduced (due to buffering until a sufficient number of ADUs have been collected at the sender) and reduced robustness against packet loss. Aggregation also introduces buffering requirements at the receiver.
除了实现复杂性之外，聚合的主要缺点是引入了额外的延迟（由于在发送方收集足够数量的ADU之前进行缓冲），并且降低了对数据包丢失的鲁棒性。聚合还引入了接收器的缓冲要求。
If the real-time media format has the property that it may produce ADUs that are larger than common MTU sizes, then fragmentation support should be considered. An RTP payload format may always fall back on IP fragmentation; however, as discussed in RFC 2736, this has some drawbacks. Perhaps the most important reason to avoid IP fragmentation is that IP fragmented packets commonly are discarded in the network, especially by NATs or firewalls. The usage of fragmentation at the RTP payload format level allows for more efficient usage of RTP packet loss recovery mechanisms. It may also in some cases also allow better usage of partial ADUs by doing media specific fragmentation at media-specific boundaries. In use cases where the ADUs are pre-produced and can't be adopted to the network's MTU size, support for fragmentation can be crucial.
如果实时媒体格式具有这样的特性，即它可能会产生大于普通MTU大小的ADU，则应考虑碎片支持。RTP有效负载格式可能总是依赖于IP碎片；然而，正如RFC 2736中所讨论的，这有一些缺点。避免IP碎片化的最重要原因可能是，IP碎片化的数据包通常会在网络中被丢弃，尤其是被NAT或防火墙丢弃。在RTP有效负载格式级别使用分段允许更有效地使用RTP数据包丢失恢复机制。在某些情况下，它还可以通过在特定于介质的边界上进行特定于介质的碎片化来更好地使用部分ADU。在ADU是预生产的且无法适应网络MTU大小的使用情况下，对碎片化的支持至关重要。
Interleaving has been implemented in a number of payload formats to allow for less quality reduction when packet loss occurs. When losses are bursty and several consecutive packets are lost, the impact on quality can be quite severe. Interleaving is used to convert that burst loss to several spread-out individual packet losses. It can also be used when several ADUs are aggregated in the same packets. A loss of an RTP packet with several ADUs in the payload has the same effect as a burst loss if the ADUs would have been transmitted in individual packets. To reduce the burstiness of the loss, the data present in an aggregated payload may be interleaved, thus, spreading the loss over a longer time period.
交织已在许多有效负载格式中实现，以允许在发生分组丢失时降低质量。当丢失是突发性的，并且几个连续的数据包丢失时，对质量的影响可能相当严重。交织用于将突发丢失转换为几个分散的单个数据包丢失。当多个ADU聚集在同一个数据包中时，也可以使用它。如果ADU将在单个数据包中传输，则有效负载中包含多个ADU的RTP数据包的丢失与突发丢失具有相同的效果。为了减少丢失的突发性，聚集的有效载荷中存在的数据可以交错，从而在更长的时间段内分散丢失。
A requirement for doing interleaving within an RTP payload format is the aggregation of multiple ADUs. For formats that do not use aggregation, there is still a possibility of implementing a transmission order rescheduling mechanism. That has the effect that the packets transmitted consecutively originate from different points in the RTP stream. This can be used to mitigate burst losses, which may be useful if one transmits packets at frequent intervals. However, it may also be used to transmit more significant data
在RTP有效负载格式内进行交织的要求是多个ADU的聚合。对于不使用聚合的格式，仍然有可能实现传输顺序重新调度机制。其效果是连续发送的分组来自RTP流中的不同点。这可以用来减轻突发丢失，如果一个人以频繁的间隔发送数据包，这可能是有用的。然而，它也可用于传输更重要的数据
earlier in combination with RTP retransmission to allow for more graceful degradation and increased possibility to receive the most important data, e.g., intra frames of video.
早些时候与RTP重传相结合，以允许更优雅的降级，并增加接收最重要数据（例如，视频帧内）的可能性。
The drawback of interleaving is the significantly increased transmission buffering delay, making it less useful for low-delay applications. It may also create significant buffering requirements on the receiver. That buffering is also problematic, as it is usually difficult to indicate when a receiver may start consume data and still avoid buffer under run caused by the interleaving mechanism itself. Transmission rescheduling is only useful in a few specific cases, as in streaming with retransmissions. The potential gains must be weighed against the complexity of these schemes.
交织的缺点是传输缓冲延迟显著增加，使其对低延迟应用不太有用。它还可能对接收器产生重要的缓冲要求。这种缓冲也有问题，因为通常很难指示接收器何时开始使用数据，并且仍然可以避免交错机制本身造成的缓冲区不足。传输重新调度仅在少数特定情况下有用，例如在具有重传的流中。必须根据这些方案的复杂性权衡潜在收益。
A few RTP payload formats have implemented back channels within the media format. Those have been for specific features, like the AMR [RFC4867] codec mode request (CMR) field. The CMR field is used in the operation of gateways to circuit-switched voice to allow an IP terminal to react to the circuit-switched network's need for a specific encoder mode. A common motivation for media back channels is the need to have signaling in direct relation to the media or the media path.
一些RTP有效负载格式在媒体格式中实现了反向通道。这些是针对特定功能的，比如AMR[RFC4867]编解码器模式请求（CMR）字段。CMR字段用于电路交换语音网关的操作，以允许IP终端对电路交换网络对特定编码器模式的需求作出反应。媒体反向通道的一个共同动机是需要有与媒体或媒体路径直接相关的信令。
If back channels are considered for an RTP payload format they should be for a specific requirements which cannot be easily satisfied by more generic mechanisms within RTP or RTCP.
如果考虑RTP有效负载格式的反向通道，则它们应满足RTP或RTCP中更通用的机制无法轻松满足的特定要求。
Some codecs support various types of media scalability, i.e. some data of a RTP stream may be removed to adapt the media's properties, such as bitrate and quality. The adaptation may be applied in the following dimensions of the media:
一些编解码器支持各种类型的媒体可伸缩性，即，可以移除RTP流的一些数据以适应媒体的属性，例如比特率和质量。改编可应用于媒体的以下方面：
Temporal: For most video codecs it is possible to adapt the frame rate without any specific definition of a temporal scalability mode, e.g., for H.264 [RFC6184]. In these cases, the sender changes which frames it delivers and the RTP timestamp makes it clear the frame interval and each frames relative capture time. H.264 Scalable Video Coding (SVC) [RFC6190] has more explicit support for temporal scalability.
时态：对于大多数视频编解码器，可以在没有任何特定的时态可伸缩性模式定义的情况下调整帧速率，例如，对于H.264[RFC6184]。在这些情况下，发送方会更改发送的帧，RTP时间戳会明确帧间隔和每个帧的相对捕获时间。H.264可伸缩视频编码（SVC）[RFC6190]更明确地支持时间可伸缩性。
Spatial: Video codecs supporting scalability may adapt the resolution, e.g., in SVC [RFC6190].
空间：支持可伸缩性的视频编解码器可以调整分辨率，例如在SVC[RFC6190]中。
Quality: The quality of the encoded stream may be scaled by adapting the accuracy of the coding process, as, e.g. possible with Signal to Noise Ratio (SNR) fidelity scalability of SVC [RFC6190].
质量：编码流的质量可以通过调整编码过程的精度来调整，例如，可以通过SVC的信噪比（SNR）保真度可伸缩性来调整[RFC6190]。
At the time of writing this document, codecs that support scalability have a bit of a revival. It has been realized that getting the required functionality for supporting the features of the media stream into the RTP framework is quite challenging. One of the recent examples for layered and scalable codecs is SVC [RFC6190].
在撰写本文档时，支持可伸缩性的编解码器有了一些复兴。人们已经意识到，将支持媒体流特性所需的功能引入RTP框架是相当具有挑战性的。SVC[RFC6190]是分层可伸缩编解码器的最新示例之一。
SVC is a good example for a payload format supporting media scalability features, which have been in its basic form already included in RTP. A layered codec supports the dropping of data parts of a RTP stream, i.e., RTP packets may not be transmitted or forwarded to a client in order to adapt the RTP streams bitrate as well as the received encoded stream's quality, while still providing a decodable subset of the encoded stream to a client. One example for using the scalability feature may be an RTP Mixer (Multipoint Control Unit) [RFC7667], which controls the rate and quality sent out to participants in a communication based on dropping RTP packets or removing part of the payload. Another example may be a transport channel, which allows for differentiation in Quality of Service (QoS) parameters based on RTP sessions in a multicast session. In such a case, the more important packets of the scalable encoded stream (base layer) may get better QoS parameters than the less important packets (enhancement layer) in order to provide some kind of graceful degradation. The scalability features required for allowing an adaptive transport, as described in the two examples above, are based on RTP multiplexing in order to identify the packets to be dropped or transmitted/forwarded. The multiplexing features defined for Scalable Video Coding [RFC6190] are:
SVC是支持媒体可伸缩性特性的有效负载格式的一个很好的例子，其基本形式已经包含在RTP中。分层编解码器支持RTP流的数据部分的丢弃，即，RTP分组可以不被发送或转发到客户端以适应RTP流比特率以及接收到的编码流的质量，同时仍然向客户端提供编码流的可解码子集。使用可伸缩性特征的一个示例可以是RTP混合器（多点控制单元）[RFC7667]，其基于丢弃RTP分组或移除部分有效负载来控制发送给通信中的参与者的速率和质量。另一示例可以是传输信道，其允许基于多播会话中的RTP会话区分服务质量（QoS）参数。在这种情况下，可伸缩编码流的更重要的分组（基本层）可以获得比不太重要的分组（增强层）更好的QoS参数，以便提供某种优雅的降级。如上两个示例中所述，允许自适应传输所需的可伸缩性特征基于RTP多路复用，以便识别要丢弃或发送/转发的分组。为可伸缩视频编码[RFC6190]定义的多路复用功能包括：
Single Session Transmission (SST), where all media layers of the media are transported as a single synchronization source (SSRC) in a single RTP session; as well as
单会话传输（SST），其中媒体的所有媒体层在单个RTP会话中作为单个同步源（SSRC）传输；以及
Multi-Session Transmission (MST), which should more accurately be called multi-stream transmission, where different media layers or a set of media layers are transported in different RTP streams, i.e., using multiple sources (SSRCs).
多会话传输（MST），应更准确地称为多流传输，其中不同的媒体层或一组媒体层在不同的RTP流中传输，即使用多个源（SSRC）。
In the first case (SST), additional in-band as well as out-of-band signaling is required in order to allow identification of packets belonging to a specific media layer. Furthermore, an adaptation of the encoded stream requires dropping of specific packets in order to provide the client with a compliant encoded stream. In case of using encryption, it is typically required for an adapting network device
在第一种情况（SST）中，为了允许识别属于特定媒体层的分组，需要额外的带内和带外信令。此外，编码流的自适应要求丢弃特定分组，以便向客户端提供兼容的编码流。在使用加密的情况下，自适应网络设备通常需要加密
to be in the security context to allow packet dropping and providing an intact RTP session to the client. This typically requires the network device to be an RTP mixer.
处于安全上下文中，以允许数据包丢弃并向客户端提供完整的RTP会话。这通常要求网络设备是RTP混频器。
In general, having a media-unaware network device dropping excessive packets will be more problematic than having a Media-Aware Network Entity (MANE). First is the need to understand the media format and know which ADUs or payloads belong to the layers, that no other layer will be dependent on after the dropping. Second, if the MANE can work as an RTP mixer or translator, it can rewrite the RTP and RTCP in such a way that the receiver will not suspect unintentional RTP packet losses needing repair actions. This as the receiver can't determine if a lost packet was an important base layer packet or one of the less important extension layers.
一般来说，让媒体感知网络设备丢弃过多的数据包比让媒体感知网络实体（MANE）更麻烦。首先，需要了解媒体格式，并知道哪些ADU或有效载荷属于这些层，在丢弃之后，其他层将不依赖于这些层。第二，如果MANE可以作为RTP混频器或转换器工作，那么它可以重写RTP和RTCP，使得接收器不会怀疑需要修复操作的无意RTP数据包丢失。这是因为接收器无法确定丢失的数据包是重要的基本层数据包还是不太重要的扩展层之一。
In the second case (MST), the RTP packet streams can be sent using a single or multiple RTP session, and thus transport flows, e.g., on different multicast groups. Transmitting the streams in different RTP sessions, then the out-of-band signaling typically provides enough information to identify the media layers and its properties. The decision on dropping packets is based on the Network Address that identifies the RTP session to be dropped. In order to allow correct data provisioning to a decoder after reception from different sessions, data realignment mechanisms are required. In some cases, existing generic tools, as described below, can be employed to enable such realignment; when those generic mechanisms are sufficient, they should be used. For example, "Rapid Synchronisation for RTP Flows" [RFC6051], uses existing RTP mechanisms, i.e. the NTP timestamp, to ensure timely inter-session synchronization. Another is the signaling feature for indicating dependencies of RTP sessions in SDP, as defined in the Media Decoding Dependency Grouping in SDP [RFC5583].
在第二种情况（MST）中，可以使用单个或多个RTP会话发送RTP分组流，从而例如在不同的多播组上传输流。在不同的RTP会话中传输流，然后带外信令通常提供足够的信息来识别媒体层及其属性。丢弃数据包的决定基于标识要丢弃的RTP会话的网络地址。为了允许在接收到来自不同会话的数据后向解码器提供正确的数据，需要数据重新调整机制。在某些情况下，可以使用如下所述的现有通用工具来实现这种重新调整；当这些通用机制足够时，应使用它们。例如，“RTP流的快速同步”[RFC6051]使用现有RTP机制，即NTP时间戳，以确保及时的会话间同步。另一个是用于指示SDP中RTP会话的依赖性的信令特性，如SDP[RFC5583]中的媒体解码依赖性分组中所定义。
Using MST within a single RTP session is also possible and allows stream level handling instead of looking deeper into the packets by a MANE. However, transport flow-level properties will be the same unless packet based mechanisms like Diffserv is used.
在单个RTP会话中使用MST也是可能的，并且允许流级处理，而不是通过MANE深入查看数据包。但是，除非使用基于分组的机制（如Diffserv），否则传输流级别的属性将是相同的。
When QoS settings, e.g., Diffserv markings, are used to ensure that the extension layers are dropped prior the base layer the receiving endpoint has the benefit in MST to know which layer or set of layers the missing packets belong to as it will be bound to different RTP sessions or RTP packet streams (SSRCs), thus, explicitly indicating the importance of the loss.
当QoS设置（例如，区分服务标记）用于确保扩展层在基本层之前被丢弃时，接收端点在MST中有利于知道丢失的数据包属于哪一层或哪一组层，因为它将绑定到不同的RTP会话或RTP数据包流（SSRC），因此，明确指出损失的重要性。
Some media codecs require high packet rates; in these cases, the RTP sequence number wraps too quickly. As a rule of thumb, it must not be possible to wrap the sequence number space within at least three RTCP reporting intervals. As the reporting interval can vary widely due to configuration and session properties, and also must take into account the randomization of the interval, one can use the TCP maximum segment lifetime (MSL), i.e., 2 minutes, in ones consideration. If earlier wrapping may occur, then the payload format should specify an extended sequence number field to allow the receiver to determine where a specific payload belongs in the sequence, even in the face of extensive reordering. The RTP payload format for uncompressed video [RFC4175] can be used as an example for such a field.
一些媒体编解码器需要高分组速率；在这些情况下，RTP序列号换行过快。根据经验，至少在三个RTCP报告间隔内不能将序列号空间包装起来。由于报告间隔可能因配置和会话属性而变化很大，并且还必须考虑间隔的随机性，因此可以使用TCP最大段生存期（MSL），即2分钟。如果可能发生较早的包装，则有效负载格式应指定扩展序列号字段，以允许接收机确定特定有效负载在序列中的位置，即使在面临广泛的重新排序时也是如此。未压缩视频的RTP有效负载格式[RFC4175]可以用作此类字段的示例。
RTCP is also affected by high packet rates. For RTCP mechanisms that do not use extended counters, there is significant risk that they wrap multiple times between RTCP reporting or feedback; thus, producing uncertainty about which packet(s) are referenced. The payload designer can't effect the RTCP packet formats used and their design, but can note this considerations when configuring RTCP bandwidth and reporting intervals to avoid to wrapping issues.
RTCP还受到高数据包速率的影响。对于不使用扩展计数器的RTCP机制，在RTCP报告或反馈之间存在多次包装的重大风险；因此，产生关于引用哪些数据包的不确定性。有效负载设计器不能影响所使用的RTCP数据包格式及其设计，但可以在配置RTCP带宽和报告间隔时注意这些注意事项，以避免包装问题。
The RTP timestamp is an important part and has two design choices associated with it. The first is the definition that determines what the timestamp value in a particular RTP packet will be, the second is which timestamp rate should be used.
RTP时间戳是一个重要部分，有两种与之相关的设计选择。第一个是确定特定RTP数据包中的时间戳值的定义，第二个是应该使用的时间戳速率。
The timestamp definition needs to explicitly define what the timestamp value in the RTP packet represent for a particular payload format. Two common definitions are used; for discretely sampled media, like video frames, the sampling time of the earliest included video frame which the data represent (fully or partially) is used; for continuous media like audio, the sampling time of the earliest sample which the payload data represent. There exist cases where more elaborate or other definitions are used.
时间戳定义需要明确定义RTP数据包中的时间戳值对于特定有效负载格式表示的内容。使用了两种常见的定义；对于离散采样的媒体，如视频帧，使用数据表示（全部或部分）的最早包含的视频帧的采样时间；对于音频等连续媒体，指有效负载数据所代表的最早样本的采样时间。在某些情况下，会使用更详细的定义或其他定义。
RTP payload formats with a timestamp definition that results in no or little correlation between the media time instance and its transmission time cause the RTCP jitter calculation to become unusable due to the errors introduced on the sender side. A common example is a payload format for a video codec where the RTP timestamp represents the capture time of the video frame, but frames are large
具有时间戳定义的RTP有效负载格式导致媒体时间实例与其传输时间之间没有或几乎没有相关性，从而导致RTCP抖动计算因发送方引入的错误而变得不可用。一个常见的示例是视频编解码器的有效负载格式，其中RTP时间戳表示视频帧的捕获时间，但帧较大
enough that multiple RTP packets need to be sent for each frame spread across the framing interval. It should be noted whether or not the payload format has this property.
足以使跨帧间隔的每个帧都需要发送多个RTP数据包。应注意有效负载格式是否具有此属性。
An RTP payload format also needs to define what timestamp rates, or clock rates (as it is also called), may be used. Depending on the RTP payload format, this may be a single rate or multiple ones or theoretically any rate. So what needs to be considered when selecting a rate?
RTP有效负载格式还需要定义可以使用的时间戳速率或时钟速率（也称为时钟速率）。根据RTP有效负载格式，这可能是单速率、多速率或理论上的任意速率。那么，在选择利率时需要考虑什么呢？
The rate needs be selected so that one can determine where in the time line of the media a particular sample (e.g., individual audio sample, or video frame) or set of samples (e.g., audio frames) belong. To enable correct synchronization of this data with previous frames, including over periods of discontinuous transmission or irregularities.
需要选择速率，以便能够确定特定样本（例如，单个音频样本或视频帧）或样本集（例如，音频帧）在媒体的时间线中所属的位置。使该数据与先前帧正确同步，包括在不连续传输或不规则传输期间。
For audio, it is common to require audio sample accuracy. Thus, one commonly selects the input sampling rate as the timestamp rate. This can, however, be challenging for audio codecs that support multiple different sampling frequencies, either as codec input or being used internally but effecting output, for example, frame duration. Depending on how one expects to use these different sampling rates one can allow multiple timestamp rates, each matching a particular codec input or sampling rate. However, due to the issues with using multiple different RTP timestamp rates for the same source (SSRC) [RFC7160], this should be avoided if one expects to need to switch between modes.
对于音频，通常要求音频采样精度。因此，通常选择输入采样率作为时间戳速率。然而，对于支持多个不同采样频率的音频编解码器来说，这可能是一个挑战，无论是作为编解码器输入还是在内部使用，但会影响输出，例如，帧持续时间。根据人们期望如何使用这些不同的采样率，可以允许多个时间戳速率，每个时间戳速率与特定的编解码器输入或采样速率相匹配。但是，由于对同一源（SSRC）[RFC7160]使用多个不同RTP时间戳速率的问题，如果需要在模式之间切换，则应避免这种情况。
Then, an alternative is to find a common denominator frequency between the different modes, e.g., OPUS [RFC7587] that uses 48 kHz. If the different modes uses or can use a common input/output frequency, then selecting this also needs to be considered. However, it is important to consider all aspects as the case of AMR-WB+ [RFC4352] illustrates. AMR-WB+'s RTP timestamp rate has the very unusual value of 72 kHz, despite the fact that output normally is at a sample rate of 48kHz. The design is motivated by the media codec's production of a large range of different frame lengths in time perspective. The 72 kHz timestamp rate is the smallest found value that would make all of the frames the codec could produce result in an integer frame length in RTP timestamp ticks. This way, a receiver can always correctly place the frames in relation to any other frame, even when the frame length changes. The downside is that the decoder outputs for certain frame lengths are, in fact, partial samples. The result is that the output in samples from the codec will vary from frame to frame, potentially making implementation more difficult.
然后，另一种方法是在不同模式之间找到共同分母频率，例如，使用48 kHz的OPUS[RFC7587]。如果不同模式使用或可以使用公共输入/输出频率，则也需要考虑选择该频率。然而，重要的是考虑AMR WB+[RCF4352]所示的所有方面。AMR-WB+的RTP时间戳速率具有非常不寻常的72 kHz值，尽管事实上输出通常为48 kHz的采样率。该设计的动机是媒体编解码器在时间角度上产生大量不同的帧长度。72 kHz时间戳速率是发现的最小值，该值将使编解码器可能产生的所有帧以RTP时间戳滴答为单位产生整数帧长度。这样，即使帧长度发生变化，接收机也可以始终相对于任何其他帧正确放置帧。缺点是，解码器对于某些帧长度的输出实际上是部分采样。结果是，来自编解码器的样本中的输出将因帧而异，这可能使实现更加困难。
Video codecs have commonly been using 90 kHz; the reason is this is a common denominator between the usually used frame rates such as 24, 25, 30, 50 and 60, and NTSC's odd 29.97 Hz. There does, however, exist at least one exception in the payload format for SMPTE 292M video [RFC3497] that uses a clock rate of 148.5 MHz. The reason here is that the timestamp then identify the exact start sample within a video frame.
视频编解码器通常使用90 kHz；原因是这是通常使用的帧速率（如24、25、30、50和60）与NTSC的奇数29.97 Hz之间的共同点。然而，SMPTE 292M视频[RFC3497]的有效负载格式中至少存在一个例外，该格式使用148.5 MHz的时钟频率。这里的原因是时间戳随后标识视频帧中的确切开始样本。
Timestamp rates below 1000 Hz are not appropriate, because this will cause a resolution too low in the RTCP measurements that are expressed in RTP timestamps. This is the main reason that the text RTP payload formats, like T.140 [RFC4103], use 1000 Hz.
低于1000 Hz的时间戳速率不合适，因为这将导致RTP测量中以RTP时间戳表示的分辨率过低。这是文本RTP有效负载格式（如T.140[RFC4103]）使用1000 Hz的主要原因。
This section provides a few examples of payload formats that are worth noting for good or bad design in general or in specific details.
本节提供了一些有效负载格式的示例，这些格式对于总体设计或具体细节的好坏都值得注意。
The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558] payload formats are all quite similar. They are all for frame-based audio codecs and use a table of contents structure. Each frame has a table of contents entry that indicates the type of the frame and if additional frames are present. This is quite flexible, but produces unnecessary overhead if the ADU is of fixed size and if, when aggregating multiple ADUs, they are commonly of the same type. In that case, a solution like the one in AMR-WB+ [RFC4352] may be more suitable.
AMR[RFC4867]、AMR-WB[RFC4867]、EVRC[RFC3558]、SMV[RFC3558]有效载荷格式都非常相似。它们都用于基于帧的音频编解码器，并使用目录结构。每个框架都有一个目录条目，该条目指示框架的类型以及是否存在其他框架。这是非常灵活的，但如果ADU大小固定，并且在聚合多个ADU时，它们通常是同一类型，则会产生不必要的开销。在这种情况下，类似AMR-WB+[RFC4352]中的解决方案可能更合适。
The RTP payload format for MIDI [RFC6295] contains some interesting features. MIDI is an audio format sensitive to packet losses, as the loss of a "note off" command will result in a note being stuck in an "on" state. To counter this, a recovery journal is defined that provides a summarized state that allows the receiver to recover from packet losses quickly. It also uses RTCP and the reported highest sequence number to be able to prune the state the recovery journal needs to contain. These features appear limited in applicability to media formats that are highly stateful and primarily use symbolic media representations.
MIDI[RFC6295]的RTP有效负载格式包含一些有趣的特性。MIDI是一种对数据包丢失非常敏感的音频格式，因为丢失“note off”命令将导致音符卡在“on”状态。为了解决这个问题，定义了一个恢复日志，它提供了一个汇总状态，允许接收方快速从数据包丢失中恢复。它还使用RTCP和报告的最高序列号来删除恢复日志需要包含的状态。这些功能在适用于高度有状态且主要使用符号媒体表示的媒体格式方面受到限制。
There exists a security concern with variable bitrate audio and speech codecs that changes their payload length based on the input data. This can leak information, especially in structured communication like a speech recognition prompt service that asks people to enter information verbally. This issue also exists to some degree for discontinuous transmission as that allows the length of
可变比特率音频和语音编解码器存在一个安全问题，该编解码器根据输入数据更改其有效负载长度。这可能会泄露信息，特别是在结构化通信中，比如要求人们口头输入信息的语音识别提示服务。对于不连续传输，在一定程度上也存在此问题，因为这允许
phrases to be determined. The issue is further discussed in "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP" [RFC6562], which needs to be read by anyone writing an RTP payload format for an audio or speech codec with these properties.
短语待定。该问题在“带安全RTP的可变比特率音频使用指南”[RFC6562]中作了进一步讨论，任何为具有这些属性的音频或语音编解码器编写RTP有效负载格式的人都需要阅读该指南。
The definition of RTP payload formats for video has seen an evolution from the early ones such as H.261 [RFC4587] towards the latest for VP8 [RFC7741] and H.265/HEVC [RFC7798].
视频RTP有效负载格式的定义已经经历了从早期的H.261[RFC4587]到最新的VP8[RFC7741]和H.265/HEVC[RFC7798]的演变。
The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord of functionality: some of it, such as the interleaving, being pretty advanced. The reason for this was to ensure that the majority of applications considered by the ITU-T and MPEG that can be supported by RTP are indeed supported. This has created a payload format that rarely is fully implemented. Despite that, no major issues with interoperability has been reported with one exception namely the Offer/Answer and parameter signaling, which resulted in a revised specification [RFC6184]. However, complaints about its complexity are common.
H.264 RTP有效负载格式[RFC3984]可以看作是一个功能的大杂烩：其中一些，如交织，非常先进。这样做的原因是为了确保ITU-T和MPEG考虑的RTP支持的大多数应用程序确实得到支持。这创建了一种很少完全实现的有效负载格式。尽管如此，互操作性方面没有重大问题，只有一个例外，即提供/应答和参数信令，这导致修订了规范[RFC6184]。然而，对其复杂性的抱怨是常见的。
The RTP payload format for uncompressed video [RFC4175] must be mentioned in this context as it contains a special feature not commonly seen in RTP payload formats. Due to the high bitrate and thus packet rate of uncompressed video (gigabits rather than megabits per second) the payload format includes a field to extend the RTP sequence number since the normal 16-bit one can wrap in less than a second. [RFC4175] also specifies a registry of different color sub-samplings that can be reused in other video RTP payload formats.
未压缩视频的RTP有效载荷格式[RFC4175]必须在本文中提及，因为它包含RTP有效载荷格式中不常见的特殊功能。由于未压缩视频的高比特率和分组率（千兆比特/秒，而不是兆比特/秒），有效负载格式包括一个字段，用于扩展RTP序列号，因为正常的16比特格式可以在不到一秒钟的时间内包装。[RFC4175]还指定了可在其他视频RTP有效负载格式中重用的不同颜色子采样的注册表。
Both the H.264 and the uncompressed video format enable the implementer to fulfill the goals of application-level framing, i.e., each individual RTP Packet's payload can be independently decoded and its content used to create a video frame (or part of) and that irrespective of whether preceding packets has been lost (see Section 4) [RFC2736]. For uncompressed, this is straightforward as each pixel is independently represented from others and its location in the video frame known. H.264 is more dependent on the actual implementation, configuration of the video encoder and usage of the RTP payload format.
H.264和未压缩视频格式都使实现者能够实现应用级成帧的目标，即，每个单独RTP数据包的有效载荷可以独立解码，其内容用于创建视频帧（或其一部分），而不管前面的数据包是否丢失（见第4节）[RFC2736]。对于未压缩，这是很简单的，因为每个像素独立于其他像素表示，并且其在视频帧中的位置已知。H.264更依赖于视频编码器的实际实现、配置和RTP有效负载格式的使用。
The common challenge with video is that, in most cases, a single compressed video frame doesn't fit into a single IP packet. Thus, the compressed representation of a video frame needs to be split over multiple packets. This can be done unintelligently with a basic payload level fragmentation method or more integrated by interfacing with the encoder's possibilities to create ADUs that are independent
视频的常见挑战是，在大多数情况下，单个压缩视频帧不能装入单个IP数据包。因此，视频帧的压缩表示需要在多个分组上分割。这可以通过基本有效负载级别的分段方法来实现，也可以通过与编码器接口来创建独立的ADU来实现
and fit the MTU for the RTP packet. The latter is more robust and commonly recommended unless strong packet loss mechanisms are used and sufficient delay budget for the repair exist. Commonly, both payload-level fragmentation as well as explaining how tailored ADUs can be created are needed in a video payload format. Also, the handling of crucial metadata, like H.264 Parameter Sets, needs to be considered as decoding is not possible without receiving the used parameter sets.
并为RTP数据包安装MTU。后者更健壮，通常推荐使用，除非使用强大的丢包机制，并且存在足够的修复延迟预算。通常，在视频有效负载格式中需要有效负载级别的碎片以及解释如何创建定制的ADU。此外，需要考虑关键元数据（如H.264参数集）的处理，因为如果不接收所使用的参数集，解码是不可能的。
Only a single format text format has been standardized in the IETF, namely T.140 [RFC4103]. The 3GPP Timed Text format [RFC4396] should be considered to be text, even though in the end was registered as a video format. It was registered in that part of the tree because it deals with decorated text, usable for subtitles and other embellishments of video. However, it has many of the properties that text formats generally have.
IETF中仅标准化了一种格式的文本格式，即T.140[RFC4103]。3GPP定时文本格式[RFC4396]应被视为文本，即使最终注册为视频格式。它被注册在树的这一部分，因为它处理装饰文本，可用于字幕和其他视频装饰。但是，它具有文本格式通常具有的许多属性。
The RTP payload format for T.140 was designed with high reliability in mind as real-time text commonly is an extremely low bitrate application. Thus, it recommends the use of RFC 2198 with many generations of redundancy. However, the format failed to provide a text-block-specific sequence number and instead relies on the RTP one to detect loss. This makes detection of missing text blocks unnecessarily difficult and hinders deployment with other robustness mechanisms that would involve switching the payload type, as that may result in erroneous error marking in the T.140 text stream.
T.140的RTP有效负载格式设计时考虑到了高可靠性，因为实时文本通常是一种极低比特率的应用。因此，建议使用具有多代冗余的RFC 2198。但是，该格式无法提供文本块特定的序列号，而是依赖RTP序列号来检测丢失。这使得检测丢失的文本块变得不必要的困难，并妨碍使用其他健壮性机制进行部署，这些机制将涉及切换有效负载类型，因为这可能导致T.140文本流中错误的错误标记。
At the time of writing, the application content type contains two media types that aren't RTP transport robustness tools such as FEC [RFC3009] [RFC5109] [RFC6015] [RFC6682] and RTP retransmission [RFC4588].
在撰写本文时，应用程序内容类型包含两种不是RTP传输健壮性工具的媒体类型，如FEC[RFC3009][RFC5109][RFC6015][RFC6682]和RTP重传[RFC4588]。
The first one is H.224 [RFC4573], which enables far-end camera control over RTP. This is not an IETF-defined RTP format, only an IETF-performed registration.
第一个是H.224[RFC4573]，它支持通过RTP控制远端摄像机。这不是IETF定义的RTP格式，只是IETF执行的注册。
The second one is "RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data" [RFC6597], which carries generic key length value (KLV) triplets. These pairs may contain arbitrary binary metadata associated with video transmissions. It has a very basic fragmentation mechanism requiring reception without packet loss, not only of the triplet itself but also one packet before and after the sequence of fragmented KLV triplet, to ensure correct reception. Specific KLV triplets
第二种是“电影和电视工程师协会（SMPTE）ST336编码数据的RTP有效载荷格式”[RFC6597]，它携带通用密钥长度值（KLV）三元组。这些对可以包含与视频传输相关联的任意二进制元数据。它有一个非常基本的分段机制，要求接收时不丢失数据包，不仅是三元组本身，而且在分段KLV三元组序列之前和之后都有一个数据包，以确保正确接收。特异性KLV三胞胎
themselves may have recommendations on how to handle incomplete ones allowing the use and repair of them. In general, the application using such a mechanism must be robust to errors and also use some combination of application-level repetition, RTP-level transport robustness tools, and network-level requirements to achieve low levels of packet loss rates and repair of KLV triplets.
他们自己可能会对如何处理不完整的部件提出建议，允许使用和维修这些部件。一般来说，使用这种机制的应用程序必须对错误具有鲁棒性，并且还使用应用程序级重复、RTP级传输鲁棒性工具和网络级要求的某种组合，以实现低水平的丢包率和KLV三元组的修复。
An author should consider applying for a media subtype under the application media type (application/<foo>) when the payload format is of a generic nature or does not clearly match any of the media types described above (audio, video, or text). However, existing limitations in, for example, SDP, have resulted in generic mechanisms normally registered in all media types possibly having been associated with any existing media types in an RTP session.
当有效载荷格式具有通用性或与上面描述的任何媒体类型（音频、视频或文本）不匹配时，作者应考虑在应用媒体类型（应用程序/< Fo>）下应用媒体子类型。然而，例如SDP中的现有限制已导致通常在所有媒体类型中注册的通用机制可能已与RTP会话中的任何现有媒体类型关联。
A number of sections in the payload format draft need special consideration. These include the Security Considerations and IANA Considerations sections that are required in all drafts. Payload formats are also strongly recommended to have the media format description and congestion control considerations. The included RTP payload format template (Appendix A) contains sample text for some of these sections.
有效载荷格式草案中的一些章节需要特别考虑。其中包括所有草案中需要的安全注意事项和IANA注意事项部分。此外，强烈建议有效负载格式包含媒体格式说明和拥塞控制注意事项。所包含的RTP有效负载格式模板（附录A）包含这些部分的示例文本。
The intention of this section is to enable reviewers and other readers to get an overview of the capabilities and major properties of the media format. It should be kept short and concise and is not a complete replacement for reading the media format specification.
本节的目的是使审阅者和其他读者能够全面了解媒体格式的功能和主要属性。它应该保持简短，不能完全代替阅读媒体格式规范。
The actual specification of the RTP payload format generally uses normative references to the codec format specification to define how codec data elements are included in the payload format. This normative reference can be to anything that have sufficient stability for a normative reference. There exist no formal requirement on the codec format specification being publicly available or free to access. However, it significantly helps in the review process if that specification is made available to any reviewer. There exist RTP payload format RFCs for open-source project specifications as well as an individual company's proprietary format, and a large variety of standards development organizations or industrial forums.
RTP有效负载格式的实际规范通常使用对编解码器格式规范的规范性引用来定义有效负载格式中如何包括编解码器数据元素。本规范性引用可以是任何具有足够稳定性的规范性引用。编解码器格式规范不存在公开或免费访问的正式要求。但是，如果该规范可供任何审查人员使用，则在审查过程中会有很大帮助。存在用于开源项目规范的RTP有效负载格式RFC以及单个公司的专有格式，以及各种各样的标准开发组织或行业论坛。
All Internet-Drafts require a Security Considerations section. The Security Considerations section in an RTP payload format needs to concentrate on the security properties this particular format has. Some payload formats have very few specific issues or properties and can fully fall back on the security considerations for RTP in general and those of the profile being used. Because those documents are always applicable, a reference to these is normally placed first in the Security Considerations section. There is suggested text in the template below.
所有Internet草稿都需要“安全注意事项”部分。RTP有效负载格式中的“安全注意事项”部分需要重点关注此特定格式具有的安全属性。一些有效负载格式几乎没有特定的问题或属性，可以完全依赖于RTP的安全考虑以及所使用的概要文件的安全考虑。由于这些文件始终适用，因此通常在“安全注意事项”一节中首先提到这些文件。下面的模板中有建议的文本。
The security issues of confidentiality, integrity protection, replay protection and source authentication are common issue for all payload formats. These should be solved by mechanisms external to the payload and do not need any special consideration in the payload format except for a reminder on these issues. There exist exceptions, such as payload formats that includes security functionality, like ISMAcrypt [ISMACrypt2]. Reasons for this division is further documented in "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202]. For a survey of available mechanisms to meet these goals, review "Options for Securing RTP Sessions" [RFC7201]. This also includes key-exchange mechanisms for the security mechanisms, which can be both integrated or separate. The choice of key-management can have significant impact on the security properties of the RTP-based application. Suitable stock text to inform people about this is included in the template.
机密性、完整性保护、重播保护和源身份验证等安全问题是所有有效负载格式的常见问题。这些问题应通过有效载荷外部的机制解决，在有效载荷格式中不需要任何特殊考虑，除非提醒这些问题。也存在例外情况，例如包含安全功能的有效负载格式，如ISMAcrypt[ISMACrypt2]。这种划分的原因在“保护RTP协议框架：为什么RTP不强制使用单一媒体安全解决方案”[RFC7202]中有进一步的说明。有关实现这些目标的可用机制的调查，请查看“保护RTP会话的选项”[RFC7201]。这还包括安全机制的密钥交换机制，可以是集成的，也可以是单独的。密钥管理的选择会对基于RTP的应用程序的安全属性产生重大影响。模板中包含适当的库存文本，以告知人们这一点。
Potential security issues with an RTP payload format and the media encoding that need to be considered if they are applicable:
RTP有效负载格式和媒体编码的潜在安全问题（如果适用）：
1. The decoding of the payload format or its media results in substantial non-uniformity, either in output or in complexity to perform the decoding operation. For example, a generic non-destructive compression algorithm may provide an output of almost an infinite size for a very limited input, thus consuming memory or storage space out of proportion with what the receiving application expected. Such inputs can cause some sort of disruption, i.e., a denial-of-service attack on the receiver side by preventing that host from performing usable work. Certain decoding operations may also vary in the amount of processing needed to perform those operations depending on the input. This may also be a security risk if it is possible to raise processing load significantly above nominal simply by designing a malicious input sequence. If such potential attacks exist, this must be
1. 有效载荷格式或其媒体的解码导致在输出或执行解码操作的复杂性方面的实质性不均匀性。例如，通用无损压缩算法可以为非常有限的输入提供几乎无限大小的输出，从而消耗与接收应用程序预期不相称的内存或存储空间。此类输入可能会导致某种中断，即通过阻止主机执行可用工作，在接收方发起拒绝服务攻击。根据输入，某些解码操作在执行这些操作所需的处理量上也可能有所不同。如果仅仅通过设计恶意输入序列就可以将处理负载显著提高到标称负载以上，那么这也可能是一种安全风险。如果存在此类潜在攻击，则必须
made clear in the Security Considerations section to make implementers aware of the need to take precautions against such behavior.
在“安全注意事项”一节中明确说明，以使实施者意识到需要采取预防措施防止此类行为。
2. The inclusion of active content in the media format or its transport. "Active content" means scripts, etc., that allow an attacker to perform potentially arbitrary operations on the receiver. Most active contents has limited possibility to access the system or perform operations outside a protected sandbox. RFC 4855 [RFC4855] has a requirement that it be noted in the media types registration whether or not the payload format contains active content. If the payload format has active content, it is strongly recommended that references to any security model applicable for such content are provided. A boilerplate text for "no active content" is included in the template. This must be changed if the format actually carries active content.
2. 在媒体格式或其传输中包含活动内容。“活动内容”指允许攻击者在接收器上执行潜在任意操作的脚本等。大多数活动内容访问系统或在受保护的沙箱之外执行操作的可能性有限。RFC 4855[RFC4855]要求在媒体类型注册中注明有效负载格式是否包含活动内容。如果有效负载格式具有活动内容，强烈建议提供适用于此类内容的任何安全模型的参考。模板中包含“无活动内容”的样板文本。如果格式实际包含活动内容，则必须更改此设置。
3. Some media formats allow for the carrying of "user data", or types of data which are not known at the time of the specification of the payload format. Such data may be a security risk and should be mentioned.
3. 一些媒体格式允许携带“用户数据”，或在指定有效负载格式时未知的数据类型。此类数据可能存在安全风险，应予以提及。
4. Audio or Speech codecs supporting variable bitrate based on 'audio/speech' input or having discontinuous transmission support must consider the issues discussed in "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP" [RFC6562].
4. 支持基于“音频/语音”输入或具有不连续传输支持的可变比特率的音频或语音编解码器必须考虑在“使用安全RTP的可变比特率音频的准则”中讨论的问题[RCF6562]。
Suitable stock text for the Security Considerations section is provided in the template in Appendix A. However, authors do need to actively consider any security issues from the start. Failure to address these issues may block approval and publication.
在附件A中的模板中提供了安全考虑部分的合适的股票文本，然而，作者确实需要从一开始就积极地考虑任何安全问题。未能解决这些问题可能会阻碍批准和发布。
RTP and its profiles do discuss congestion control. There is ongoing work in the IETF with both a basic circuit-breaker mechanism [RFC8083] using basic RTCP messages intended to prevent persistent congestion and also work on more capable congestion avoidance / bitrate adaptation mechanism in the RMCAT WG.
RTP及其配置文件确实讨论了拥塞控制。IETF中正在进行使用基本RTCP消息的基本断路器机制[RFC8083]的工作，以防止持续拥塞，并在RMCAT WG中进行更有效的拥塞避免/比特率自适应机制的工作。
Congestion control is an important issue in any usage in networks that are not dedicated. For that reason, it is recommended that all RTP payload format documents discuss the possibilities that exist to regulate the bitrate of the transmissions using the described RTP payload format. Some formats may have limited or step-wise regulation of bitrate. Such limiting factors should be discussed.
拥塞控制在非专用网络中的任何使用中都是一个重要问题。因此，建议所有RTP有效载荷格式文档讨论使用所述RTP有效载荷格式调节传输比特率的可能性。某些格式可能对比特率进行有限或分步调节。应该讨论这些限制因素。
Since all RTP payload formats contain a media type specification, they also need an IANA Considerations section. The media type name must be registered, and this is done by requesting that IANA register that media name. When that registration request is written, it shall also be requested that the media type is included under the "RTP Payload Format media types" subregistry of the RTP registry (http://www.iana.org/assignments/rtp-parameters).
由于所有RTP有效负载格式都包含媒体类型规范，因此它们还需要IANA注意事项部分。必须注册媒体类型名称，这可以通过请求IANA注册该媒体名称来完成。当写入该注册请求时，还应请求将媒体类型包括在RTP注册表的“RTP有效负载格式媒体类型”子目录下(http://www.iana.org/assignments/rtp-parameters).
Parameters for the payload format need to be included in this registration and can be specified as required or optional ones. The format of these parameters should be such that they can be included in the SDP attribute "a=fmtp" string (see Section 6 [RFC4566]), which is the common mapping. Some parameters, such as "Channel" are normally mapped to the rtpmap attribute instead; see Section 3 of [RFC4855].
有效负载格式的参数需要包含在该注册中，并且可以指定为必需的或可选的参数。这些参数的格式应确保它们可以包含在SDP属性“a=fmtp”字符串中（参见第6节[RFC4566]），这是常见的映射。某些参数（如“通道”）通常映射到rtpmap属性；参见[RFC4855]第3节。
In addition to the above request for media type registration, some payload formats may have parameters where, in the future, new parameter values need to be added. In these cases, a registry for that parameter must be created. This is done by defining the registry in the IANA Considerations section. BCP 26 [BCP26] provides guidelines to specifying such registries. Care should be taken when defining the policy for new registrations.
除了上述媒体类型注册请求之外，一些有效负载格式可能具有参数，其中将来需要添加新的参数值。在这些情况下，必须为该参数创建注册表。这是通过在IANA注意事项部分中定义注册表来完成的。BCP 26[BCP26]提供了指定此类注册的指南。在定义新注册的策略时应小心。
Before specifying a new registry, it is worth checking the existing ones in the IANA "MIME Media Type Sub-Parameter Registries". For example, video formats that need a media parameter expressing color sub-sampling may be able to reuse those defined for 'video/raw' [RFC4175].
在指定新注册表之前，需要检查IANA“MIME媒体类型子参数注册表”中的现有注册表。例如，需要表示颜色子采样的媒体参数的视频格式可以重用为“视频/raw”[RFC4175]定义的格式。
This section provides information about some tools that may be used. Don't feel pressured to follow these recommendations. There exist a number of alternatives, including the ones listed at <http://tools.ietf.org>. But these suggestions are worth checking out before deciding that the grass is greener somewhere else.
本节提供有关可能使用的某些工具的信息。不要觉得遵循这些建议有压力。存在许多备选方案，包括在<http://tools.ietf.org>. 但在决定其他地方的草是否更绿之前，这些建议值得一看。
Note that these options are related to the old text only RFC format, and do not cover tools for at the time of publication recently approved new RFC format, see [RFC7990].
请注意，这些选项与旧的纯文本RFC格式相关，不包括发布时的工具，最近批准的新RFC格式，请参阅[RFC7990]。
There are many choices when it comes to tools to choose for authoring Internet-Drafts. However, in the end, they need to be able to produce a draft that conforms to the Internet-Draft requirements. If you don't have any previous experience with authoring Internet-Drafts, xml2rfc does have some advantages. It helps by creating a lot of the necessary boilerplate in accordance with the latest rules, thus reducing the effort. It also speeds up publication after approval as the RFC Editor can use the source XML document to produce the RFC more quickly.
在创作互联网草稿的工具方面，有很多选择。然而，最终，他们需要能够制作出符合互联网草案要求的草案。如果您以前没有编写Internet草稿的经验，xml2rfc确实有一些优势。它根据最新的规则创建了大量必要的样板文件，从而减少了工作量。由于RFC编辑器可以使用源XML文档更快地生成RFC，因此它还可以加快批准后的发布速度。
Another common choice is to use Microsoft Word and a suitable template (see [RFC5385]) to produce the draft and print that to file using the generic text printer. It has some advantages when it comes to spell checking and change bars. However, Word may also produce some problems, like changing formatting, and inconsistent results between what one sees in the editor and in the generated text document, at least according to the author's personal experience.
另一种常见的选择是使用Microsoft Word和合适的模板（请参见[RFC5385]）生成草稿，并使用通用文本打印机将其打印到文件中。当涉及到拼写检查和更改条时，它有一些优势。但是，Word也可能会产生一些问题，如更改格式，以及在编辑器中看到的内容与生成的文本文档中看到的结果不一致，至少根据作者的个人经验是这样。
There are a few tools that are very good to know about when writing a draft. These help check and verify parts of one's work. These tools can be found at <http://tools.ietf.org>.
在撰写草稿时，有一些工具非常值得了解。这些有助于检查和验证一个人的部分工作。这些工具可以在<http://tools.ietf.org>.
o I-D Nits checker (https://tools.ietf.org/tools/idnits/). It checks that the boilerplate and some other things that are easily verifiable by machine are okay in your draft. Always use it before submitting a draft to avoid direct refusal in the submission step.
o I-D Nits检测器(https://tools.ietf.org/tools/idnits/). 它检查样板文件和其他一些可以通过机器轻松验证的东西在草稿中是否正确。在提交草稿之前务必使用它，以避免在提交步骤中直接拒绝。
o ABNF Parser and verification (https://tools.ietf.org/tools/bap/ abnf.cgi). Checks that your ABNF parses correctly and warns about loose ends, like undefined symbols. However, the actual content can only be verified by humans knowing what it intends to describe.
o ABNF解析器与验证(https://tools.ietf.org/tools/bap/ abnf.cgi）。检查ABNF是否正确解析，并警告未定义的符号等松散端。然而，实际的内容只能由知道它打算描述什么的人来验证。
o RFC diff (https://tools.ietf.org/rfcdiff). A diff tool that is optimized for drafts and RFCs. For example, it does not point out that the footer and header have moved in relation to the text on every page.
o RFC差异(https://tools.ietf.org/rfcdiff). 为草稿和RFC优化的差异工具。例如，它没有指出页脚和页眉相对于每页上的文本已经移动。
As this is an Informational RFC about writing drafts that are intended to become RFCs, there are no direct security considerations. However, the document does discuss the writing of Security Considerations sections and what should be particularly considered when specifying RTP payload formats.
由于这是一个关于编写打算成为RFC的草稿的信息RFC，因此没有直接的安全考虑。然而，本文档确实讨论了安全注意事项部分的编写，以及在指定RTP有效负载格式时应特别考虑的内容。
[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[BCP9]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
Kolkman, O., Bradner, S., and S. Turner, "Characterization of Proposed Standards", BCP 9, RFC 7127, January 2014.
Kolkman，O.，Bradner，S.和S.Turner，“拟定标准的特征”，BCP 9，RFC 7127，2014年1月。
Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009.
Dusseault，L.和R.Sparks，“推进标准草案的互操作和实施报告指南”，BCP 9，RFC 5657，2009年9月。
Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011.
Housley，R.，Crocker，D.，和E.Burger，“将标准轨道降低到两个成熟度水平”，BCP 9，RFC 6410，2011年10月。
Resnick, P., "Retirement of the "Internet Official Protocol Standards" Summary Document", BCP 9, RFC 7100, December 2013.
Resnick，P.，“互联网官方协议标准”的退役摘要文件，BCP 9，RFC 7100，2013年12月。
Dawkins, S., "Increasing the Number of Area Directors in an IETF Area", BCP 9, RFC 7475, March 2015.
Dawkins，S.，“增加IETF区域的区域主管数量”，BCP 9，RFC 7475，2015年3月。
<http://www.rfc-editor.org/info/bcp9>
<http://www.rfc-editor.org/info/bcp9>
[BCP25] Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, October 2004.
[BCP25]Wasserman，M.，“关于IETF邮件列表管理的RFC 2418更新”，BCP 25，RFC 3934，2004年10月。
Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
Bradner，S.，“IETF工作组指南和程序”，BCP 25，RFC 2418，1998年9月。
Resnick, P. and A. Farrel, "IETF Anti-Harassment Procedures", BCP 25, RFC 7776, March 2016.
Resnick，P.和A.Farrel，“IETF反骚扰程序”，BCP 25，RFC 77762016年3月。
<http://www.rfc-editor.org/info/bcp25>
<http://www.rfc-editor.org/info/bcp25>
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/bcp26>.
[BCP26]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/bcp26>.
[BCP78] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008, <http://www.rfc-editor.org/info/bcp78>.
[BCP78]Bradner，S.，Ed.和J.Contreras，Ed.，“向IETF信托提供的权利出资人”，BCP 78，RFC 5378，2008年11月<http://www.rfc-editor.org/info/bcp78>.
[BCP79] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[BCP79]Bradner，S.，Ed.，“IETF技术中的知识产权”，BCP 79，RFC 3979，2005年3月。
Narten, T., "Clarification of the Third Party Disclosure Procedure in RFC 3979", BCP 79, RFC 4879, April 2007.
Narten，T.，“RFC 3979中第三方披露程序的澄清”，BCP 79，RFC 4879，2007年4月。
<http://www.rfc-editor.org/info/bcp79>
<http://www.rfc-editor.org/info/bcp79>
[BLOAT] Nichols, K. and V. Jacobson, "Controlling Queue Delay", ACM Networks, Vol. 10, No. 5, DOI 10.1145/2208917.2209336, May 2012, <http://queue.acm.org/detail.cfm?id=2209336>.
[BLOAT]Nichols，K.和V.Jacobson，“控制队列延迟”，ACM网络，第10卷，第5期，DOI 10.1145/2208917.2209336，2012年5月<http://queue.acm.org/detail.cfm?id=2209336>.
[CSP-RTP] Perkins, C., "RTP: Audio and Video for the Internet", Addison-Wesley Professional, ISBN 0-672-32249-8, June 2003.
[CSP-RTP]Perkins，C.，“RTP：互联网音频和视频”，Addison-Wesley Professional，ISBN 0-672-32249-82003年6月。
[ID-GUIDE] Housley, R., "Guidelines to Authors of Internet-Drafts", December 2010, <http://www.ietf.org/id-info/guidelines.html>.
[ID-GUIDE]Housley，R.，“互联网草稿作者指南”，2010年12月<http://www.ietf.org/id-info/guidelines.html>.
[ISMACrypt2] Internet Streaming Media Alliance (ISMA), "ISMA Encryption and Authentication, Version 2.0 release version", November 2007, <http://www.oipf.tv/docs/mpegif/isma_easpec2.0.pdf>.
[ISMACrypt2]互联网流媒体联盟（ISMA），“ISMA加密和认证，2.0版发布版”，2007年11月<http://www.oipf.tv/docs/mpegif/isma_easpec2.0.pdf>.
[RED] Floyd, S. and V. Jacobson, "Random Early Detection (RED) gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking 1(4) 397--413, August 1993, <http://www.aciri.org/floyd/papers/early.pdf>.
[RED]Floyd，S.和V.Jacobson，“避免拥塞的随机早期检测（RED）网关”，IEEE/ACM网络事务1（4）397-413，1993年8月<http://www.aciri.org/floyd/papers/early.pdf>.
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, DOI 10.17487/RFC1633, June 1994, <http://www.rfc-editor.org/info/rfc1633>.
[RFC1633]Braden，R.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 1633，DOI 10.17487/RFC1633，1994年6月<http://www.rfc-editor.org/info/rfc1633>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, <http://www.rfc-editor.org/info/rfc2198>.
[RFC2198]Perkins，C.，Kouvelas，I.，Hodson，O.，Hardman，V.，Handley，M.，Bolot，J.，Vega Garcia，A.，和S.Fosse Parisis，“冗余音频数据的RTP有效载荷”，RFC 2198，DOI 10.17487/RFC2198，1997年9月<http://www.rfc-editor.org/info/rfc2198>.
[RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, RFC 2360, DOI 10.17487/RFC2360, June 1998, <http://www.rfc-editor.org/info/rfc2360>.
[RFC2360]Scott，G.“互联网标准编写者指南”，BCP 22，RFC 2360，DOI 10.17487/RFC2360，1998年6月<http://www.rfc-editor.org/info/rfc2360>.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, September 1998, <http://www.rfc-editor.org/info/rfc2418>.
[RFC2418]Bradner，S.，“IETF工作组指南和程序”，BCP 25，RFC 2418，DOI 10.17487/RFC2418，1998年9月<http://www.rfc-editor.org/info/rfc2418>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 2475，DOI 10.17487/RFC2475，1998年12月<http://www.rfc-editor.org/info/rfc2475>.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, DOI 10.17487/RFC2508, February 1999, <http://www.rfc-editor.org/info/rfc2508>.
[RFC2508]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，DOI 10.17487/RFC2508，1999年2月<http://www.rfc-editor.org/info/rfc2508>.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, DOI 10.17487/RFC2733, December 1999, <http://www.rfc-editor.org/info/rfc2733>.
[RFC2733]Rosenberg，J.和H.Schulzrinne，“通用前向纠错的RTP有效载荷格式”，RFC 2733，DOI 10.17487/RFC2733，1999年12月<http://www.rfc-editor.org/info/rfc2733>.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, DOI 10.17487/RFC2736, December 1999, <http://www.rfc-editor.org/info/rfc2736>.
[RFC2736]Handley，M.和C.Perkins，“RTP有效载荷格式规范编写者指南”，BCP 36，RFC 2736，DOI 10.17487/RFC2736，1999年12月<http://www.rfc-editor.org/info/rfc2736>.
[RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time Transport Protocol Management Information Base", RFC 2959, DOI 10.17487/RFC2959, October 2000, <http://www.rfc-editor.org/info/rfc2959>.
[RFC2959]Baugher，M.，Strahm，B.，和I.Suconick，“实时传输协议管理信息库”，RFC 2959，DOI 10.17487/RFC2959，2000年10月<http://www.rfc-editor.org/info/rfc2959>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，DOI 10.17487/RFC2974，2000年10月<http://www.rfc-editor.org/info/rfc2974>.
[RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of parityfec MIME types", RFC 3009, DOI 10.17487/RFC3009, November 2000, <http://www.rfc-editor.org/info/rfc3009>.
[RFC3009]Rosenberg，J.和H.Schulzrinne，“parityfec MIME类型的注册”，RFC 3009，DOI 10.17487/RFC3009，2000年11月<http://www.rfc-editor.org/info/rfc3009>.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, July 2001, <http://www.rfc-editor.org/info/rfc3095>.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP，和未压缩”，RFC 3095，内政部10.17487/RFC30952001年7月<http://www.rfc-editor.org/info/rfc3095>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://www.rfc-editor.org/info/rfc3264>.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, DOI 10.17487/RFC3410, December 2002, <http://www.rfc-editor.org/info/rfc3410>.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 3410，DOI 10.17487/RFC3410，2002年12月<http://www.rfc-editor.org/info/rfc3410>.
[RFC3497] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video", RFC 3497, DOI 10.17487/RFC3497, March 2003, <http://www.rfc-editor.org/info/rfc3497>.
[RFC3497]Gharai，L.，Perkins，C.，Goncher，G.，和A.Mankin，“电影电视工程师学会（SMPTE）292M视频RTP有效载荷格式”，RFC 3497，DOI 10.17487/RFC3497，2003年3月<http://www.rfc-editor.org/info/rfc3497>.
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, DOI 10.17487/RFC3545, July 2003, <http://www.rfc-editor.org/info/rfc3545>.
[RFC3545]Koren，T.，Casner，S.，Geevarghese，J.，Thompson，B.，和P.Ruddy，“具有高延迟、数据包丢失和重新排序的链路的增强压缩RTP（CRTP）”，RFC 3545，DOI 10.17487/RFC3545，2003年7月<http://www.rfc-editor.org/info/rfc3545>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，DOI 10.17487/RFC3551，2003年7月<http://www.rfc-editor.org/info/rfc3551>.
[RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, DOI 10.17487/RFC3558, July 2003, <http://www.rfc-editor.org/info/rfc3558>.
[RFC3558]Li，A.“增强型变速率编解码器（EVRC）和可选模式声码器（SMV）的RTP有效载荷格式”，RFC 3558，DOI 10.17487/RFC3558，2003年7月<http://www.rfc-editor.org/info/rfc3558>.
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2003, <http://www.rfc-editor.org/info/rfc3569>.
[RFC3569]Bhattacharyya，S.，编辑，“源特定多播（SSM）概述”，RFC 3569，DOI 10.17487/RFC3569，2003年7月<http://www.rfc-editor.org/info/rfc3569>.
[RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, DOI 10.17487/RFC3577, August 2003, <http://www.rfc-editor.org/info/rfc3577>.
[RFC3577]Waldbusser，S.，Cole，R.，Kalbflish，C.，和D.Romascanu，“MIB模块远程监控（RMON）系列介绍”，RFC 3577，DOI 10.17487/RFC3577，2003年8月<http://www.rfc-editor.org/info/rfc3577>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]Friedman，T.，Ed.，Caceres，R.，Ed.，和A.Clark，Ed.，“RTP控制协议扩展报告（RTCP XR）”，RFC 3611，DOI 10.17487/RFC36112003年11月<http://www.rfc-editor.org/info/rfc3611>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<http://www.rfc-editor.org/info/rfc3711>.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, <http://www.rfc-editor.org/info/rfc3828>.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，Ed.，和G.Fairhurst，Ed.，“轻量级用户数据报协议（UDP Lite）”，RFC 3828，DOI 10.17487/RFC3828，2004年7月<http://www.rfc-editor.org/info/rfc3828>.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, M., and D. Singer, "RTP Payload Format for H.264 Video", RFC 3984, DOI 10.17487/RFC3984, February 2005, <http://www.rfc-editor.org/info/rfc3984>.
[RFC3984]Wenger，S.，Hannuksela，M.，Stockhammer，T.，Westerlund，M.，和D.Singer，“H.264视频的RTP有效载荷格式”，RFC 3984，DOI 10.17487/RFC3984，2005年2月<http://www.rfc-editor.org/info/rfc3984>.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <http://www.rfc-editor.org/info/rfc4103>.
[RFC4103]Hellstrom，G.和P.Jones，“文本对话的RTP有效载荷”，RFC 4103，DOI 10.17487/RFC4103，2005年6月<http://www.rfc-editor.org/info/rfc4103>.
[RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, DOI 10.17487/RFC4170, November 2005, <http://www.rfc-editor.org/info/rfc4170>.
[RFC4170]Thompson，B.，Koren，T.，和D.Wing，“隧道多路复用压缩RTP（TCRTP）”，BCP 110，RFC 4170，DOI 10.17487/RFC4170，2005年11月<http://www.rfc-editor.org/info/rfc4170>.
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, September 2005, <http://www.rfc-editor.org/info/rfc4175>.
[RFC4175]Gharai，L.和C.Perkins，“未压缩视频的RTP有效载荷格式”，RFC 4175，DOI 10.17487/RFC4175，2005年9月<http://www.rfc-editor.org/info/rfc4175>.
[RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger, "RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec", RFC 4352, DOI 10.17487/RFC4352, January 2006, <http://www.rfc-editor.org/info/rfc4352>.
[RFC4352]Sjoberg，J.，Westerlund，M.，Lakaniemi，A.，和S.Wenger，“扩展自适应多速率宽带（AMR-WB+）音频编解码器的RTP有效载荷格式”，RFC 4352，DOI 10.17487/RFC4352，2006年1月<http://www.rfc-editor.org/info/rfc4352>.
[RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text", RFC 4396, DOI 10.17487/RFC4396, February 2006, <http://www.rfc-editor.org/info/rfc4396>.
[RFC4396]Rey，J.和Y.Matsui，“第三代合作伙伴关系项目（3GPP）定时文本的RTP有效载荷格式”，RFC 4396，DOI 10.17487/RFC4396，2006年2月<http://www.rfc-editor.org/info/rfc4396>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, <http://www.rfc-editor.org/info/rfc4571>.
[RFC4571]Lazzaro，J.，“面向连接传输上的帧实时传输协议（RTP）和RTP控制协议（RTCP）数据包”，RFC 4571，DOI 10.17487/RFC4571，2006年7月<http://www.rfc-editor.org/info/rfc4571>.
[RFC4573] Even, R. and A. Lochbaum, "MIME Type Registration for RTP Payload Format for H.224", RFC 4573, DOI 10.17487/RFC4573, July 2006, <http://www.rfc-editor.org/info/rfc4573>.
[RFC4573]Even，R.和A.Lochbaum，“H.224 RTP有效载荷格式的MIME类型注册”，RFC 4573，DOI 10.17487/RFC4573，2006年7月<http://www.rfc-editor.org/info/rfc4573>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<http://www.rfc-editor.org/info/rfc4585>.
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, DOI 10.17487/RFC4587, August 2006, <http://www.rfc-editor.org/info/rfc4587>.
[RFC4587]偶数，R.，“H.261视频流的RTP有效载荷格式”，RFC 4587，DOI 10.17487/RFC4587，2006年8月<http://www.rfc-editor.org/info/rfc4587>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <http://www.rfc-editor.org/info/rfc4588>.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，DOI 10.17487/RFC4588，2006年7月<http://www.rfc-editor.org/info/rfc4588>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, July 2007, <http://www.rfc-editor.org/info/rfc4844>.
[RFC4844]Daigle，L.，Ed.和互联网架构委员会，“RFC系列和RFC编辑器”，RFC 4844，DOI 10.17487/RFC4844，2007年7月<http://www.rfc-editor.org/info/rfc4844>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <http://www.rfc-editor.org/info/rfc4855>.
[RFC4855]Casner，S.，“RTP有效载荷格式的媒体类型注册”，RFC 4855，DOI 10.17487/RFC4855，2007年2月<http://www.rfc-editor.org/info/rfc4855>.
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, April 2007, <http://www.rfc-editor.org/info/rfc4867>.
[RFC4867]Sjoberg，J.，Westerlund，M.，Lakaniemi，A.，和Q.Xie，“自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的RTP有效载荷格式和文件存储格式”，RFC 4867，DOI 10.17487/RFC4867，2007年4月<http://www.rfc-editor.org/info/rfc4867>.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <http://www.rfc-editor.org/info/rfc4975>.
[RFC4975]Campbell，B.，Ed.，Mahy，R.，Ed.，和C.Jennings，Ed.，“消息会话中继协议（MSRP）”，RFC 4975，DOI 10.17487/RFC4975，2007年9月<http://www.rfc-editor.org/info/rfc4975>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5109]Li，A.，Ed.“通用前向纠错的RTP有效载荷格式”，RFC 5109，DOI 10.17487/RFC5109，2007年12月<http://www.rfc-editor.org/info/rfc5109>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 5124DOI 10.17487/RFC5124，2008年2月<http://www.rfc-editor.org/info/rfc5124>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC5285]Singer，D.和H.Desneni，“RTP报头扩展的一般机制”，RFC 5285，DOI 10.17487/RFC5285，2008年7月<http://www.rfc-editor.org/info/rfc5285>.
[RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", RFC 5385, DOI 10.17487/RFC5385, February 2010, <http://www.rfc-editor.org/info/rfc5385>.
[RFC5385]Touch，J.，“用于创建互联网草稿和RFC的2.0版Microsoft Word模板”，RFC 5385，DOI 10.17487/RFC5385，2010年2月<http://www.rfc-editor.org/info/rfc5385>.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 5484, DOI 10.17487/RFC5484, March 2009, <http://www.rfc-editor.org/info/rfc5484>.
[RFC5484]Singer，D.，“将时间码与RTP流相关联”，RFC 5484，DOI 10.17487/RFC54842009年3月<http://www.rfc-editor.org/info/rfc5484>.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, <http://www.rfc-editor.org/info/rfc5583>.
[RFC5583]Schierl，T.和S.Wenger，“会话描述协议（SDP）中的信令媒体解码依赖性”，RFC 5583，DOI 10.17487/RFC5583，2009年7月<http://www.rfc-editor.org/info/rfc5583>.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010, <http://www.rfc-editor.org/info/rfc5795>.
[RFC5795]Sandlund，K.，Pelletier，G.和L-E.Jonsson，“鲁棒头压缩（ROHC）框架”，RFC 5795，DOI 10.17487/RFC5795，2010年3月<http://www.rfc-editor.org/info/rfc5795>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<http://www.rfc-editor.org/info/rfc5905>.
[RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)", RFC 6015, DOI 10.17487/RFC6015, October 2010, <http://www.rfc-editor.org/info/rfc6015>.
[RFC6015]Begen，A.，“用于1-D交错奇偶校验前向纠错（FEC）的RTP有效载荷格式”，RFC 6015，DOI 10.17487/RFC6015，2010年10月<http://www.rfc-editor.org/info/rfc6015>.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, <http://www.rfc-editor.org/info/rfc6051>.
[RFC6051]Perkins，C.和T.Schierl，“RTP流的快速同步”，RFC 6051，DOI 10.17487/RFC6051，2010年11月<http://www.rfc-editor.org/info/rfc6051>.
[RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/RFC6184, May 2011, <http://www.rfc-editor.org/info/rfc6184>.
[RFC6184]Wang，Y.，Even，R.，Kristensen，T.，和R.Jesup，“H.264视频的RTP有效载荷格式”，RFC 6184，DOI 10.17487/RFC6184，2011年5月<http://www.rfc-editor.org/info/rfc6184>.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, <http://www.rfc-editor.org/info/rfc6190>.
[RFC6190]Wenger，S.，Wang，Y.，Schierl，T.，和A.Eleftheriadis，“可伸缩视频编码的RTP有效载荷格式”，RFC 6190，DOI 10.17487/RFC6190，2011年5月<http://www.rfc-editor.org/info/rfc6190>.
[RFC6295] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for MIDI", RFC 6295, DOI 10.17487/RFC6295, June 2011, <http://www.rfc-editor.org/info/rfc6295>.
[RFC6295]Lazzaro，J.和J.Wawrzynek，“MIDI的RTP有效载荷格式”，RFC 6295，DOI 10.17487/RFC6295，2011年6月<http://www.rfc-editor.org/info/rfc6295>.
[RFC6354] Xie, Q., "Forward-Shifted RTP Redundancy Payload Support", RFC 6354, DOI 10.17487/RFC6354, August 2011, <http://www.rfc-editor.org/info/rfc6354>.
[RFC6354]谢，Q，“前向移位RTP冗余有效载荷支持”，RFC 6354，DOI 10.17487/RFC6354，2011年8月<http://www.rfc-editor.org/info/rfc6354>.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <http://www.rfc-editor.org/info/rfc6363>.
[RFC6363]Watson，M.，Begen，A.和V.Roca，“前向纠错（FEC）框架”，RFC 6363，DOI 10.17487/RFC6363，2011年10月<http://www.rfc-editor.org/info/rfc6363>.
[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, DOI 10.17487/RFC6410, October 2011, <http://www.rfc-editor.org/info/rfc6410>.
[RFC6410]Housley，R.，Crocker，D.，和E.Burger，“将标准轨道降低到两个成熟度水平”，BCP 9，RFC 6410，DOI 10.17487/RFC6410，2011年10月<http://www.rfc-editor.org/info/rfc6410>.
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 10.17487/RFC6562, March 2012, <http://www.rfc-editor.org/info/rfc6562>.
[RFC6562]Perkins，C.和JM。Valin，“带安全RTP的可变比特率音频使用指南”，RFC 6562，DOI 10.17487/RFC6562，2012年3月<http://www.rfc-editor.org/info/rfc6562>.
[RFC6597] Downs, J., Ed. and J. Arbeiter, Ed., "RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data", RFC 6597, DOI 10.17487/RFC6597, April 2012, <http://www.rfc-editor.org/info/rfc6597>.
[RFC6597]Downs，J.，Ed.和J.Arbeiter，Ed.，“电影和电视工程师学会（SMPTE）ST 336编码数据的RTP有效载荷格式”，RFC 6597，DOI 10.17487/RFC6597，2012年4月<http://www.rfc-editor.org/info/rfc6597>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6679]Westerlund，M.，Johansson，I.，Perkins，C.，O'Hanlon，P.，和K.Carlberg，“UDP上RTP的显式拥塞通知（ECN）”，RFC 6679，DOI 10.17487/RFC66792012年8月<http://www.rfc-editor.org/info/rfc6679>.
[RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload Format for Raptor Forward Error Correction (FEC)", RFC 6682, DOI 10.17487/RFC6682, August 2012, <http://www.rfc-editor.org/info/rfc6682>.
[RFC6682]Watson，M.，Stockhammer，T.和M.Luby，“猛禽前向纠错（FEC）的RTP有效载荷格式”，RFC 6682，DOI 10.17487/RFC6682，2012年8月<http://www.rfc-editor.org/info/rfc6682>.
[RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for Application to Violators of IETF IPR Policy", RFC 6701, DOI 10.17487/RFC6701, August 2012, <http://www.rfc-editor.org/info/rfc6701>.
[RFC6701]Farrel，A.和P.Resnick，“适用于违反IETF知识产权政策者的制裁”，RFC 6701，DOI 10.17487/RFC6701，2012年8月<http://www.rfc-editor.org/info/rfc6701>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<http://www.rfc-editor.org/info/rfc6838>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, <http://www.rfc-editor.org/info/rfc7160>.
[RFC7160]Petit Huguenin，M.和G.Zorn，Ed.，“在RTP会话中支持多个时钟速率”，RFC 7160，DOI 10.17487/RFC7160，2014年4月<http://www.rfc-editor.org/info/rfc7160>.
[RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC 7164, DOI 10.17487/RFC7164, March 2014, <http://www.rfc-editor.org/info/rfc7164>.
[RFC7164]Gross，K.和R.Brandenburg，“RTP和闰秒”，RFC 7164，DOI 10.17487/RFC7164，2014年3月<http://www.rfc-editor.org/info/rfc7164>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201]Westerlund，M.和C.Perkins，“保护RTP会话的选项”，RFC 7201，DOI 10.17487/RFC7201，2014年4月<http://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7202]Perkins，C.和M.Westerlund，“保护RTP框架：为什么RTP不要求单一媒体安全解决方案”，RFC 7202，DOI 10.17487/RFC7202，2014年4月<http://www.rfc-editor.org/info/rfc7202>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. Stokking, "RTP Clock Source Signalling", RFC 7273, DOI 10.17487/RFC7273, June 2014, <http://www.rfc-editor.org/info/rfc7273>.
[RFC7273]Williams，A.，Gross，K.，van Brandenburg，R.，和H.Stokking，“RTP时钟源信令”，RFC 7273，DOI 10.17487/RFC7273，2014年6月<http://www.rfc-editor.org/info/rfc7273>.
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014, <http://www.rfc-editor.org/info/rfc7322>.
[RFC7322]Flanagan，H.和S.Ginoza，“RFC风格指南”，RFC 7322，DOI 10.17487/RFC7322，2014年9月<http://www.rfc-editor.org/info/rfc7322>.
[RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, DOI 10.17487/RFC7587, June 2015, <http://www.rfc-editor.org/info/rfc7587>.
[RFC7587]Spittka，J.，Vos，K.，和JM。Valin，“Opus语音和音频编解码器的RTP有效载荷格式”，RFC 7587，DOI 10.17487/RFC7587，2015年6月<http://www.rfc-editor.org/info/rfc7587>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656]Lennox，J.，Gross，K.，Nandakumar，S.，Salgueiro，G.，和B.Burman，Ed.，“实时传输协议（RTP）源的语义和机制分类”，RFC 7656，DOI 10.17487/RFC7656，2015年11月<http://www.rfc-editor.org/info/rfc7656>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <http://www.rfc-editor.org/info/rfc7667>.
[RFC7667]Westerlund，M.和S.Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 7667，DOI 10.17487/RFC7667，2015年11月<http://www.rfc-editor.org/info/rfc7667>.
[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, <http://www.rfc-editor.org/info/rfc7741>.
[RFC7741]威斯汀，P.，伦丁，H.，格洛弗，M.，尤伯蒂，J.，和F.加里根，“VP8视频的RTP有效载荷格式”，RFC 7741，DOI 10.17487/RFC77412016年3月<http://www.rfc-editor.org/info/rfc7741>.
[RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. Hannuksela, "RTP Payload Format for High Efficiency Video Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 2016, <http://www.rfc-editor.org/info/rfc7798>.
[RFC7798]Wang，Y.，Sanchez，Y.，Schierl，T.，Wenger，S.，和M.Hannuksela，“高效视频编码（HEVC）的RTP有效载荷格式”，RFC 7798，DOI 10.17487/RFC7798，2016年3月<http://www.rfc-editor.org/info/rfc7798>.
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, <http://www.rfc-editor.org/info/rfc7826>.
[RFC7826]Schulzrinne，H.，Rao，A.，Lanphier，R.，Westerlund，M.，和M.Stiemering，Ed.，“实时流协议版本2.0”，RFC 7826，DOI 10.17487/RFC78262016年12月<http://www.rfc-editor.org/info/rfc7826>.
[RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990, DOI 10.17487/RFC7990, December 2016, <http://www.rfc-editor.org/info/rfc7990>.
[RFC7990]Flanagan，H.，“RFC格式框架”，RFC 7990，DOI 10.17487/RFC7990，2016年12月<http://www.rfc-editor.org/info/rfc7990>.
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <http://www.rfc-editor.org/info/rfc8083>.
[RFC8083]Perkins，C.和V.Singh，“多媒体拥塞控制：单播RTP会话的断路器”，RFC 8083，DOI 10.17487/RFC8083，2017年3月<http://www.rfc-editor.org/info/rfc8083>.
[TAO] Hoffman, P., Ed., "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", November 2012, <http://www.ietf.org/tao.html>.
[TAO]Hoffman，P.，Ed.“IETF之道：互联网工程任务组新手指南”，2012年11月<http://www.ietf.org/tao.html>.
[TRACKER] "IETF Datatracker", <https://datatracker.ietf.org/>.
[跟踪器]“IETF数据跟踪器”<https://datatracker.ietf.org/>.
This section contains a template for writing an RTP payload format in the form of an Internet-Draft. Text within [...] are instructions and must be removed from the draft itself. Some text proposals that are included are conditional. "..." is used to indicate where further text should be written.
本节包含一个模板，用于以Internet草稿的形式编写RTP有效负载格式。[…]中的文本是说明，必须从草案中删除。所包括的一些文本提案是有条件的。“…”用于指示应在何处写入更多文本。
[The title shall be descriptive but as compact as possible. RTP is allowed and recommended abbreviation in the title]
[标题应具有描述性，但应尽可能紧凑。标题中允许使用RTP，建议使用缩写]
RTP payload format for ...
RTP有效负载格式。。。
Status of this Memo
本备忘录的状况
[Insert the IPR notice and copyright boilerplate from BCP 78 and 79 that applies to this draft.]
[插入BCP 78和79中适用于本草案的知识产权声明和版权模板。]
[Insert the current Internet-Draft document explanation. At the time of publishing it was:]
[插入当前的互联网文件草稿解释。发布时为：]
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
互联网草案是互联网工程任务组（IETF）的工作文件。请注意，其他小组也可以将工作文件作为互联网草稿分发。当前互联网草稿列表位于http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
互联网草案是最长有效期为六个月的文件草案，可随时由其他文件更新、替换或废弃。使用互联网草稿作为参考资料或引用它们而不是“正在进行的工作”是不合适的
[A payload format abstract should mention the capabilities of the format, for which media format is used, and a little about that codec formats capabilities. Any abbreviation used in the payload format must be spelled out here except the very well known like RTP. No citations are allowed, and no use of language from RFC 2119 either.]
[有效负载格式摘要应提及使用媒体格式的格式的功能，以及编解码器格式的一些功能。有效负载格式中使用的任何缩写必须在此处拼写，但众所周知的RTP除外。不允许引用，也不允许使用RFC 2119中的语言。]
[If your draft is approved for publication as an RFC, a Table of Contents is required, per [RFC7322].]
[如果您的草稿被批准作为RFC发布，则需要根据[RFC7322]提供目录。]
[The Introduction should provide a background and overview of the payload format's capabilities. No normative language in this section, i.e., no MUST, SHOULDs etc.]
[引言应提供有效负载格式功能的背景和概述。本节中没有规范性语言，即没有必须、应该等。]
[Define conventions, definitions, and abbreviations used in the document in this section. The most common definition used in RTP payload formats are the RFC 2119 definitions of the uppercase normative words, e.g., MUST and SHOULD.]
[定义本节文件中使用的约定、定义和缩写。RTP有效载荷格式中最常用的定义是RFC 2119大写规范性词语的定义，例如必须和应该。]
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
[The intention of this section is to enable reviewers and persons to get an overview of the capabilities and major properties of the media format. It should be kept short and concise and is not a complete replacement for reading the media format specification.]
[本节的目的是使审查人员和个人能够全面了解媒体格式的功能和主要属性。本节内容应简洁明了，不能完全替代阅读媒体格式规范。]
[Overview of payload structure]
[有效载荷结构概述]
[RTP header usage needs to be defined. The fields that absolutely need to be defined are timestamp and marker bit. Further fields may be specified if used. All the rest should be left to their RTP specification definition.]
[需要定义RTP标头的用法。绝对需要定义的字段是时间戳和标记位。如果使用，可能会指定其他字段。其余所有字段应留给RTP规范定义。]
The remaining RTP header fields are used as specified in RTP [RFC3550].
剩余的RTP头字段按照RTP[RFC3550]中的规定使用。
[Define how the payload header, if it exists, is structured and used.]
[定义有效负载标头（如果存在）的结构和使用方式。]
[The payload data, i.e., what the media codec has produced. Commonly done through reference to the media codec specification, which defines how the data is structured. Rules for padding may need to be defined to bring data to octet alignment.]
[有效负载数据，即媒体编解码器产生的数据。通常通过参考媒体编解码器规范来完成，该规范定义了数据的结构。可能需要定义填充规则，以使数据与八位字节对齐。]
[One or more examples are good to help ease the understanding of the RTP payload format.]
[一个或多个示例有助于简化对RTP有效负载格式的理解。]
[This section is to describe the possibility to vary the bitrate as a response to congestion. Below is also a proposal for an initial text that reference RTP and profiles definition of congestion control.]
[本节将描述改变比特率作为拥塞响应的可能性。以下也是参考RTP和配置文件拥塞控制定义的初始文本提案。]
Congestion control for RTP SHALL be used in accordance with RFC 3550 [RFC3550], and with any applicable RTP profile: e.g., RFC 3551 [RFC3551]. An additional requirement if best-effort service is being used is users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Circuit Breakers [RFC8083] is an update to RTP [RFC3550] that defines criteria for when one is required to stop sending RTP Packet Streams. The circuit breakers is to be implemented and followed.
RTP的拥塞控制应根据RFC 3550[RFC3550]和任何适用的RTP配置文件使用：例如，RFC 3551[RFC3551]。如果使用尽力而为服务，另一个要求是此有效负载格式的用户必须监控数据包丢失，以确保数据包丢失率在可接受的参数范围内。断路器[RFC8083]是对RTP[RFC3550]的更新，它定义了何时需要停止发送RTP数据包流的标准。应实施并遵循断路器。
This RTP payload format is identified using the ... media type, which is registered in accordance with RFC 4855 [RFC4855] and using the template of RFC 6838 [RFC6838].
此RTP有效负载格式使用。。。媒体类型，根据RFC 4855[RFC4855]注册，并使用RFC 6838[RFC6838]模板。
[Here the media type registration template from RFC 6838 is placed and filled out. This template is provided with some common RTP boilerplate.]
[此处放置并填写来自RFC 6838的媒体类型注册模板。此模板随一些常见RTP样板提供。]
Type name:
类型名称：
Subtype name:
子类型名称：
Required parameters:
所需参数：
Optional parameters:
可选参数：
Encoding considerations:
编码注意事项：
This media type is framed and binary; see Section 4.8 in RFC 6838 [RFC6838].
这种媒体类型是框架和二进制的；参见RFC 6838[RFC6838]中的第4.8节。
Security considerations:
安全考虑：
Please see the Security Considerations section in RFC XXXX
请参阅RFC XXXX中的安全注意事项部分
Interoperability considerations:
互操作性注意事项：
Published specification:
已发布的规范：
Applications that use this media type:
使用此媒体类型的应用程序：
Additional information:
其他信息：
Deprecated alias names for this type:
此类型的不推荐别名：
[Only applicable if there exists widely deployed alias for this media type; see Section 4.2.9 of [RFC6838]. Remove or use N/A otherwise.]
[仅当此媒体类型存在广泛部署的别名时适用；请参阅[RFC6838]的第4.2.9节。否则，请删除或使用N/A。]
Magic number(s):
幻数：
[Only applicable for media types that has file format specification. Remove or use N/A otherwise.]
[仅适用于具有文件格式规范的媒体类型。否则请删除或使用N/A。]
File extension(s):
文件扩展名：
[Only applicable for media types that has file format specification. Remove or use N/A otherwise.]
[仅适用于具有文件格式规范的媒体类型。否则请删除或使用N/A。]
Macintosh file type code(s):
Macintosh文件类型代码：
[Only applicable for media types that has file format specification. Even for file formats they can be skipped as they are not relied on after Mac OS 9.X. Remove or use N/A otherwise.]
[仅适用于具有文件格式规范的媒体类型。即使对于文件格式，也可以跳过它们，因为它们在Mac OS 9.X之后不受依赖。否则请删除或使用N/A。]
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Intended usage:
预期用途：
[One of COMMON, LIMITED USE, or OBSOLETE.]
[通用的、有限使用的或过时的。]
Restrictions on usage:
使用限制：
[The below text is for media types that is only defined for RTP payload formats. There exist certain media types that are defined both as RTP payload formats and file transfer. The rules for such types are documented in RFC 4855 [RFC4855].]
[以下文本适用于仅为RTP有效负载格式定义的媒体类型。存在同时定义为RTP有效负载格式和文件传输的某些媒体类型。RFC 4855[RFC4855]中记录了此类类型的规则。]
This media type depends on RTP framing and, hence, is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
此媒体类型取决于RTP帧，因此仅定义为通过RTP传输[RFC3550]。此时未定义其他帧协议内的传输。
Author:
作者：
Change controller:
更改控制器：
IETF Payload working group delegated from the IESG.
IESG授权的IETF有效载荷工作组。
Provisional registration? (standards tree only):
临时登记？（仅限标准树）：
No
不
(Any other information that the author deems interesting may be added below this line.)
（作者认为有趣的任何其他信息可添加在此行下方。）
[From RFC 6838:
[来自RFC 6838:
"N/A", written exactly that way, can be used in any field if desired to emphasize the fact that it does not apply or that the question was not omitted by accident. Do not use 'none' or other words that could be mistaken for a response.
正是这样写的“N/A”可以用在任何领域，如果想要强调它不适用或者这个问题不是偶然遗漏的。不要使用“无”或其他可能被误认为是响应的词语。
Limited-use media types should also note in the applications list whether or not that list is exhaustive.]
有限使用介质类型还应在应用程序列表中注明该列表是否详尽。]
The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of RFC 4855 [RFC4855].
应根据RFC 4855[RFC4855]第3节的规定，映射上述定义的有效负载格式媒体类型及其参数。
[More specific rules only need to be included if some parameter does not match these rules.]
[仅当某些参数与这些规则不匹配时，才需要包括更具体的规则。]
[Here write your Offer/Answer considerations section; please see Section 3.4.2.1 for help.]
[在此处填写您的报价/答复注意事项部分；请参阅第3.4.2.1节以获取帮助。]
[Here write your considerations for declarative SDP, please see Section 3.4.2.2 for help.]
[在这里写下您对声明性SDP的注意事项，请参阅第3.4.2.2节以获取帮助。]
This memo requests that IANA registers [insert media type name here] as specified in Appendix A.11.1. The media type is also requested to be added to the IANA registry for "RTP Payload Format MIME types" <http://www.iana.org/assignments/rtp-parameters>.
本备忘录要求IANA按照附录A.11.1的规定注册[在此插入媒体类型名称]。对于“RTP有效负载格式MIME类型”，还请求将媒体类型添加到IANA注册表中<http://www.iana.org/assignments/rtp-parameters>.
[See Section 7.4 and consider if any of the parameter needs a registered name space.]
[参见第7.4节并考虑是否有任何参数需要注册的名称空间。]
[See Section 7.2.]
[见第7.2节。]
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] , and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in "Options for Securing RTP Sessions" [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this Security Considerations section discusses the security impacting properties of the payload format itself.
使用本规范中定义的有效负载格式的RTP数据包受RTP规范[RFC3550]和任何适用RTP配置文件（如RTP/AVP[RFC3551]、RTP/AVPF[RFC4585]、RTP/SAVP[RFC3711]或RTP/SAVPF[RFC5124]中讨论的安全注意事项的约束。然而，正如[RFC7202]所讨论的“保护RTP协议框架：为什么RTP不强制要求单一媒体安全解决方案”，RTP有效负载格式不负责讨论或强制要求使用什么解决方案来满足RTP的基本安全目标，如机密性、完整性和源真实性。这一责任由在应用程序中使用RTP的任何人承担。他们可以在“保护RTP会话的选项”[RFC7201]中找到关于可用安全机制和重要注意事项的指导。应用程序应使用一个或多个适当的强安全机制。本安全注意事项部分的其余部分讨论影响有效负载格式本身安全性的属性。
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content.
此RTP有效载荷格式及其媒体解码器在用于分组处理的接收器端计算复杂度方面不表现出任何显著的非均匀性，因此不太可能由于接收病理数据而造成拒绝服务威胁。RTP有效负载格式也不包含任何活动内容。
[The previous paragraph may need editing due to the format breaking either of the statements. Fill in here any further potential security threats created by the payload format itself.]
[上一段可能需要编辑，因为格式破坏了其中一条语句。请在此处填写有效负载格式本身造成的任何进一步潜在安全威胁。]
Note to RFC Editor: This section may be removed after carrying out all the instructions of this section.
RFC编辑器注意：执行本节的所有说明后，可以删除本节。
RFC XXXX is to be replaced by the RFC number this specification receives when published.
RFC XXXX将替换为本规范发布时收到的RFC编号。
[References must be classified as either normative or informative and added to the relevant section. References should use descriptive reference tags.]
[参考文献必须分类为规范性或信息性，并添加到相关章节。参考文献应使用描述性参考标签。]
[Normative references are those that are required to be used to correctly implement the payload format. Also, when requirements language is used, as in the sample text for "Congestion Control Considerations" above, there should be a normative reference to [RFC2119].]
[规范性参考是指正确实施有效负载格式所需使用的参考。此外，当使用需求语言时，如上文“拥塞控制注意事项”的示例文本中所述，应该有对[RFC2119]的规范性参考。]
[All other references.]
[所有其他参考资料。]
[All authors need to include their name and email address as a minimum: postal mail and possibly phone numbers are included commonly.]
[所有作者至少需要包括他们的姓名和电子邮件地址：通常包括邮政邮件和电话号码。]
[The Template Ends Here!]
[模板到此结束！]
Acknowledgements
致谢
The author would like to thank the individuals who have provided input to this document. These individuals include Richard Barnes, Ali C. Begen, Bo Burman, Ross Finlayson, Russ Housley, John Lazzaro, Jonathan Lennox, Colin Perkins, Tom Taylor, Stephan Wenger, and Qin Wu.
作者要感谢为本文件提供投入的个人。这些人包括理查德·巴恩斯、阿里·贝根、波·伯曼、罗斯·芬莱森、罗斯·霍斯利、约翰·拉扎罗、乔纳森·伦诺克斯、科林·帕金斯、汤姆·泰勒、斯蒂芬·温格和秦武。
Contributors
贡献者
The author would like to thank Tom Taylor for the editing pass of the whole document and contributing text regarding proprietary RTP payload formats. Thanks also goes to Thomas Schierl who contributed text regarding Media Scalability features in payload formats (Section 5.1.5). Stephan Wenger has contributed text on the need to understand the media coding (Section 3.1) as well as joint development of payload format with the media coding (Section 4.4).
作者要感谢Tom Taylor编辑了整个文档，并提供了有关专有RTP有效负载格式的文本。还要感谢Thomas Schierl，他提供了有关有效负载格式的媒体可伸缩性特性的文本（第5.1.5节）。Stephan Wenger就需要理解媒体编码（第3.1节）以及有效载荷格式与媒体编码的联合开发（第4.4节）提供了文本。
Author's Address
作者地址
Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 2 SE-164 80瑞典基斯塔
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com