Internet Engineering Task Force (IETF) J. Lennox
Request for Comments: 7656 Vidyo
Category: Informational K. Gross
ISSN: 2070-1721 AVA
S. Nandakumar
G. Salgueiro
Cisco Systems
B. Burman, Ed.
Ericsson
November 2015
Internet Engineering Task Force (IETF) J. Lennox
Request for Comments: 7656 Vidyo
Category: Informational K. Gross
ISSN: 2070-1721 AVA
S. Nandakumar
G. Salgueiro
Cisco Systems
B. Burman, Ed.
Ericsson
November 2015
A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources
实时传输协议（RTP）源的语义和机制分类
Abstract
摘要
The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships.
关于实时传输协议（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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第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/rfc7656.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7656.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Media Chain . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Physical Stimulus . . . . . . . . . . . . . . . . . . 10
2.1.2. Media Capture . . . . . . . . . . . . . . . . . . . . 10
2.1.3. Raw Stream . . . . . . . . . . . . . . . . . . . . . 10
2.1.4. Media Source . . . . . . . . . . . . . . . . . . . . 11
2.1.5. Source Stream . . . . . . . . . . . . . . . . . . . . 11
2.1.6. Media Encoder . . . . . . . . . . . . . . . . . . . . 12
2.1.7. Encoded Stream . . . . . . . . . . . . . . . . . . . 13
2.1.8. Dependent Stream . . . . . . . . . . . . . . . . . . 13
2.1.9. Media Packetizer . . . . . . . . . . . . . . . . . . 13
2.1.10. RTP Stream . . . . . . . . . . . . . . . . . . . . . 14
2.1.11. RTP-Based Redundancy . . . . . . . . . . . . . . . . 14
2.1.12. Redundancy RTP Stream . . . . . . . . . . . . . . . . 15
2.1.13. RTP-Based Security . . . . . . . . . . . . . . . . . 15
2.1.14. Secured RTP Stream . . . . . . . . . . . . . . . . . 16
2.1.15. Media Transport . . . . . . . . . . . . . . . . . . . 16
2.1.16. Media Transport Sender . . . . . . . . . . . . . . . 17
2.1.17. Sent RTP Stream . . . . . . . . . . . . . . . . . . . 18
2.1.18. Network Transport . . . . . . . . . . . . . . . . . . 18
2.1.19. Transported RTP Stream . . . . . . . . . . . . . . . 18
2.1.20. Media Transport Receiver . . . . . . . . . . . . . . 18
2.1.21. Received Secured RTP Stream . . . . . . . . . . . . . 19
2.1.22. RTP-Based Validation . . . . . . . . . . . . . . . . 19
2.1.23. Received RTP Stream . . . . . . . . . . . . . . . . . 19
2.1.24. Received Redundancy RTP Stream . . . . . . . . . . . 19
2.1.25. RTP-Based Repair . . . . . . . . . . . . . . . . . . 19
2.1.26. Repaired RTP Stream . . . . . . . . . . . . . . . . . 19
2.1.27. Media Depacketizer . . . . . . . . . . . . . . . . . 20
2.1.28. Received Encoded Stream . . . . . . . . . . . . . . . 20
2.1.29. Media Decoder . . . . . . . . . . . . . . . . . . . . 20
2.1.30. Received Source Stream . . . . . . . . . . . . . . . 20
2.1.31. Media Sink . . . . . . . . . . . . . . . . . . . . . 21
2.1.32. Received Raw Stream . . . . . . . . . . . . . . . . . 21
2.1.33. Media Render . . . . . . . . . . . . . . . . . . . . 21
2.2. Communication Entities . . . . . . . . . . . . . . . . . 22
2.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 23
2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 24
2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 24
2.2.5. Communication Session . . . . . . . . . . . . . . . . 25
3. Concepts of Inter-Relations . . . . . . . . . . . . . . . . . 25
3.1. Synchronization Context . . . . . . . . . . . . . . . . . 26
3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 26
3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Media Chain . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Physical Stimulus . . . . . . . . . . . . . . . . . . 10
2.1.2. Media Capture . . . . . . . . . . . . . . . . . . . . 10
2.1.3. Raw Stream . . . . . . . . . . . . . . . . . . . . . 10
2.1.4. Media Source . . . . . . . . . . . . . . . . . . . . 11
2.1.5. Source Stream . . . . . . . . . . . . . . . . . . . . 11
2.1.6. Media Encoder . . . . . . . . . . . . . . . . . . . . 12
2.1.7. Encoded Stream . . . . . . . . . . . . . . . . . . . 13
2.1.8. Dependent Stream . . . . . . . . . . . . . . . . . . 13
2.1.9. Media Packetizer . . . . . . . . . . . . . . . . . . 13
2.1.10. RTP Stream . . . . . . . . . . . . . . . . . . . . . 14
2.1.11. RTP-Based Redundancy . . . . . . . . . . . . . . . . 14
2.1.12. Redundancy RTP Stream . . . . . . . . . . . . . . . . 15
2.1.13. RTP-Based Security . . . . . . . . . . . . . . . . . 15
2.1.14. Secured RTP Stream . . . . . . . . . . . . . . . . . 16
2.1.15. Media Transport . . . . . . . . . . . . . . . . . . . 16
2.1.16. Media Transport Sender . . . . . . . . . . . . . . . 17
2.1.17. Sent RTP Stream . . . . . . . . . . . . . . . . . . . 18
2.1.18. Network Transport . . . . . . . . . . . . . . . . . . 18
2.1.19. Transported RTP Stream . . . . . . . . . . . . . . . 18
2.1.20. Media Transport Receiver . . . . . . . . . . . . . . 18
2.1.21. Received Secured RTP Stream . . . . . . . . . . . . . 19
2.1.22. RTP-Based Validation . . . . . . . . . . . . . . . . 19
2.1.23. Received RTP Stream . . . . . . . . . . . . . . . . . 19
2.1.24. Received Redundancy RTP Stream . . . . . . . . . . . 19
2.1.25. RTP-Based Repair . . . . . . . . . . . . . . . . . . 19
2.1.26. Repaired RTP Stream . . . . . . . . . . . . . . . . . 19
2.1.27. Media Depacketizer . . . . . . . . . . . . . . . . . 20
2.1.28. Received Encoded Stream . . . . . . . . . . . . . . . 20
2.1.29. Media Decoder . . . . . . . . . . . . . . . . . . . . 20
2.1.30. Received Source Stream . . . . . . . . . . . . . . . 20
2.1.31. Media Sink . . . . . . . . . . . . . . . . . . . . . 21
2.1.32. Received Raw Stream . . . . . . . . . . . . . . . . . 21
2.1.33. Media Render . . . . . . . . . . . . . . . . . . . . 21
2.2. Communication Entities . . . . . . . . . . . . . . . . . 22
2.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2. RTP Session . . . . . . . . . . . . . . . . . . . . . 23
2.2.3. Participant . . . . . . . . . . . . . . . . . . . . . 24
2.2.4. Multimedia Session . . . . . . . . . . . . . . . . . 24
2.2.5. Communication Session . . . . . . . . . . . . . . . . 25
3. Concepts of Inter-Relations . . . . . . . . . . . . . . . . . 25
3.1. Synchronization Context . . . . . . . . . . . . . . . . . 26
3.1.1. RTCP CNAME . . . . . . . . . . . . . . . . . . . . . 26
3.1.2. Clock Source Signaling . . . . . . . . . . . . . . . 26
3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 26
3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 26
3.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 27
3.5. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 28
3.6. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 30
3.8. RTP Stream Duplication . . . . . . . . . . . . . . . . . 32
3.9. Redundancy Format . . . . . . . . . . . . . . . . . . . . 33
3.10. RTP Retransmission . . . . . . . . . . . . . . . . . . . 33
3.11. Forward Error Correction . . . . . . . . . . . . . . . . 35
3.12. RTP Stream Separation . . . . . . . . . . . . . . . . . . 36
3.13. Multiple RTP Sessions over one Media Transport . . . . . 37
4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 37
4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 37
4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 37
4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 37
4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 38
4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 38
4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 38
4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 38
4.1.7. Media Capture . . . . . . . . . . . . . . . . . . . . 38
4.1.8. Media Consumer . . . . . . . . . . . . . . . . . . . 38
4.1.9. Media Provider . . . . . . . . . . . . . . . . . . . 39
4.1.10. Stream . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . . 39
4.2. Media Description . . . . . . . . . . . . . . . . . . . . 39
4.3. Media Stream . . . . . . . . . . . . . . . . . . . . . . 39
4.4. Multimedia Conference . . . . . . . . . . . . . . . . . . 39
4.5. Multimedia Session . . . . . . . . . . . . . . . . . . . 40
4.6. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 40
4.7. Multi-Session Transmission (MST) . . . . . . . . . . . . 40
4.8. Recording Device . . . . . . . . . . . . . . . . . . . . 41
4.9. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 41
4.10. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 41
4.11. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . 41
4.12. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 41
4.13. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 41
4.14. Single-Session Transmission (SST) . . . . . . . . . . . . 41
4.15. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6. Informative References . . . . . . . . . . . . . . . . . . . 42
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.3. Implicitly via RtcMediaStream . . . . . . . . . . . . 26
3.1.4. Explicitly via SDP Mechanisms . . . . . . . . . . . . 26
3.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Participant . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 27
3.5. Multi-Channel Audio . . . . . . . . . . . . . . . . . . . 28
3.6. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7. Layered Multi-Stream . . . . . . . . . . . . . . . . . . 30
3.8. RTP Stream Duplication . . . . . . . . . . . . . . . . . 32
3.9. Redundancy Format . . . . . . . . . . . . . . . . . . . . 33
3.10. RTP Retransmission . . . . . . . . . . . . . . . . . . . 33
3.11. Forward Error Correction . . . . . . . . . . . . . . . . 35
3.12. RTP Stream Separation . . . . . . . . . . . . . . . . . . 36
3.13. Multiple RTP Sessions over one Media Transport . . . . . 37
4. Mapping from Existing Terms . . . . . . . . . . . . . . . . . 37
4.1. Telepresence Terms . . . . . . . . . . . . . . . . . . . 37
4.1.1. Audio Capture . . . . . . . . . . . . . . . . . . . . 37
4.1.2. Capture Device . . . . . . . . . . . . . . . . . . . 37
4.1.3. Capture Encoding . . . . . . . . . . . . . . . . . . 38
4.1.4. Capture Scene . . . . . . . . . . . . . . . . . . . . 38
4.1.5. Endpoint . . . . . . . . . . . . . . . . . . . . . . 38
4.1.6. Individual Encoding . . . . . . . . . . . . . . . . . 38
4.1.7. Media Capture . . . . . . . . . . . . . . . . . . . . 38
4.1.8. Media Consumer . . . . . . . . . . . . . . . . . . . 38
4.1.9. Media Provider . . . . . . . . . . . . . . . . . . . 39
4.1.10. Stream . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.11. Video Capture . . . . . . . . . . . . . . . . . . . . 39
4.2. Media Description . . . . . . . . . . . . . . . . . . . . 39
4.3. Media Stream . . . . . . . . . . . . . . . . . . . . . . 39
4.4. Multimedia Conference . . . . . . . . . . . . . . . . . . 39
4.5. Multimedia Session . . . . . . . . . . . . . . . . . . . 40
4.6. Multipoint Control Unit (MCU) . . . . . . . . . . . . . . 40
4.7. Multi-Session Transmission (MST) . . . . . . . . . . . . 40
4.8. Recording Device . . . . . . . . . . . . . . . . . . . . 41
4.9. RtcMediaStream . . . . . . . . . . . . . . . . . . . . . 41
4.10. RtcMediaStreamTrack . . . . . . . . . . . . . . . . . . . 41
4.11. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . 41
4.12. RTP Sender . . . . . . . . . . . . . . . . . . . . . . . 41
4.13. RTP Session . . . . . . . . . . . . . . . . . . . . . . . 41
4.14. Single-Session Transmission (SST) . . . . . . . . . . . . 41
4.15. SSRC . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6. Informative References . . . . . . . . . . . . . . . . . . . 42
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
The existing taxonomy of sources in the Real-time Transport Protocol (RTP) [RFC3550] has previously been regarded as confusing and inconsistent. Consequently, a deep understanding of how the different terms relate to each other becomes a real challenge. Frequently cited examples of this confusion are (1) how different protocols that make use of RTP use the same terms to signify different things and (2) how the complexities addressed at one layer are often glossed over or ignored at another.
实时传输协议（RTP）[RFC3550]中现有的源分类以前被认为是混乱和不一致的。因此，深入理解不同术语之间的关系成为一个真正的挑战。这种混淆经常被引用的例子有：（1）使用RTP的不同协议如何使用相同的术语来表示不同的事物；（2）如何在一层处理的复杂性在另一层常常被掩盖或忽略。
This document improves clarity by reviewing the semantics of various aspects of sources in RTP. As an organizing mechanism, it approaches this by describing various ways that RTP sources are transformed on their way between sender and receiver, and how they can be grouped and associated together.
本文档通过回顾RTP中源的各个方面的语义来提高清晰度。作为一种组织机制，它通过描述RTP源在发送方和接收方之间的转换方式，以及如何将它们分组和关联在一起来实现这一点。
All non-specific references to ControLling mUltiple streams for tElepresence (CLUE) in this document map to [CLUE-FRAME], and all references to Web Real-time Communications (WebRTC) map to [WEBRTC-OVERVIEW].
本文档中所有关于控制多个流以实现远程呈现（CLUE）的非特定引用均映射到[CLUE-FRAME]，所有关于Web实时通信（WebRTC）的引用均映射到[WebRTC-OVERVIEW]。
This section defines concepts that serve to identify and name various transformations and streams in a given RTP usage. For each concept, alternate definitions and usages that coexist today are listed along with various characteristics that further describe the concept. These concepts are divided into two categories: one is related to the chain of streams and transformations that Media can be subject to, and the other is for entities involved in the communication.
本节定义了用于识别和命名给定RTP使用中的各种转换和流的概念。对于每个概念，列出了目前共存的替代定义和用法，以及进一步描述该概念的各种特征。这些概念分为两类：一类是与媒体可以遵循的流和转换链相关的，另一类是与通信相关的实体。
In the context of this document, media is a sequence of synthetic or Physical Stimuli (Section 2.1.1) -- for example, sound waves, photons, key strokes -- represented in digital form. Synthesized media is typically generated directly in the digital domain.
在本文件中，媒体是一系列合成或物理刺激（第2.1.1节）——例如，声波、光子、按键——以数字形式表示。合成媒体通常直接在数字域中生成。
This section contains the concepts that can be involved in taking media at a sender side and transporting it to a receiver, which may recover a sequence of physical stimuli. This chain of concepts is of two main types: streams and transformations. Streams are time-based sequences of samples of the physical stimulus in various representations, while transformations change the representation of the streams in some way.
本节包含在发送方获取媒体并将其传输至接收方的概念，接收方可恢复一系列物理刺激。这个概念链有两种主要类型：流和转换。流是各种表示形式的物理刺激样本的基于时间的序列，而变换以某种方式改变流的表示形式。
The below examples are basic ones, and it is important to keep in mind that this conceptual model enables more complex usages. Some will be further discussed in later sections of this document. In general the following applies to this model:
下面的示例是基本示例，请务必记住，此概念模型支持更复杂的用法。有些问题将在本文件后面的章节中进一步讨论。一般而言，以下内容适用于此型号：
o A transformation may have zero or more inputs and one or more outputs.
o 转换可以有零个或多个输入和一个或多个输出。
o A stream is of some type, such as audio, video, real-time text, etc.
o 流是某种类型的，例如音频、视频、实时文本等。
o A stream has one source transformation and one or more sink transformations (with the exception of physical stimulus (Section 2.1.1) that may lack source or sink transformation).
o 一个流有一个源转换和一个或多个汇转换（可能缺少源或汇转换的物理刺激（第2.1.1节）除外）。
o Streams can be forwarded from a transformation output to any number of inputs on other transformations that support that type.
o 流可以从转换输出转发到支持该类型的其他转换上的任意数量的输入。
o If the output of a transformation is sent to multiple transformations, those streams will be identical; it takes a transformation to make them different.
o 如果一个转换的输出被发送到多个转换，那么这些流将是相同的；这需要一个转变，使他们不同。
o There are no formal limitations on how streams are connected to transformations.
o 流与转换的连接方式没有正式的限制。
It is also important to remember that this is a conceptual model. Thus, real-world implementations may look different and have a different structure.
记住这是一个概念模型也是很重要的。因此，现实世界的实现可能看起来不同，并且具有不同的结构。
To provide a basic understanding of the relationships in the chain, we first introduce the concepts for the sender side (Figure 1). This covers physical stimuli until media packets are emitted onto the network.
为了提供对链中关系的基本理解，我们首先介绍发送方的概念（图1）。这包括物理刺激，直到媒体包发射到网络上。
Physical Stimulus
|
V
+----------------------+
| Media Capture |
+----------------------+
|
Raw Stream
V
+----------------------+
| Media Source |<- Synchronization Timing
+----------------------+
|
Source Stream
V
+----------------------+
| Media Encoder |
+----------------------+
|
Encoded Stream +------------+
V | V
+----------------------+ | +----------------------+
| Media Packetizer | | | RTP-Based Redundancy |
+----------------------+ | +----------------------+
| | |
+-------------+ Redundancy RTP Stream
Source RTP Stream |
V V
+----------------------+ +----------------------+
| RTP-Based Security | | RTP-Based Security |
+----------------------+ +----------------------+
| |
Secured RTP Stream Secured Redundancy RTP Stream
V V
+----------------------+ +----------------------+
| Media Transport | | Media Transport |
+----------------------+ +----------------------+
Physical Stimulus
|
V
+----------------------+
| Media Capture |
+----------------------+
|
Raw Stream
V
+----------------------+
| Media Source |<- Synchronization Timing
+----------------------+
|
Source Stream
V
+----------------------+
| Media Encoder |
+----------------------+
|
Encoded Stream +------------+
V | V
+----------------------+ | +----------------------+
| Media Packetizer | | | RTP-Based Redundancy |
+----------------------+ | +----------------------+
| | |
+-------------+ Redundancy RTP Stream
Source RTP Stream |
V V
+----------------------+ +----------------------+
| RTP-Based Security | | RTP-Based Security |
+----------------------+ +----------------------+
| |
Secured RTP Stream Secured Redundancy RTP Stream
V V
+----------------------+ +----------------------+
| Media Transport | | Media Transport |
+----------------------+ +----------------------+
Figure 1: Sender Side Concepts in the Media Chain
图1：媒体链中的发送方概念
In Figure 1, we have included a branched chain to cover the concepts for using redundancy to improve the reliability of the transport. The Media Transport concept is an aggregate that is decomposed in Section 2.1.15.
在图1中，我们包含了一个分支链，涵盖了使用冗余来提高传输可靠性的概念。媒体传输概念是第2.1.15节中分解的集合。
In Figure 2, we review a receiver media chain matching the sender side, to look at the inverse transformations and their attempts to recover identical streams as in the sender chain, subject to what may be lossy compression and imperfect media transport. Note that the streams out of a reverse transformation, like the Source Stream out of the Media Decoder, are in many cases not the same as the corresponding ones on the sender side; thus, they are prefixed with a "received" to denote a potentially modified version. The reason for not being the same lies in the transformations that can be of irreversible type. For example, lossy source coding in the Media Encoder prevents the source stream out of the media decoder from being the same as the one fed into the media encoder. Other reasons include packet loss in the media transport transformation that even RTP-based Repair, if used, fails to repair.
在图2中，我们回顾了与发送方匹配的接收方媒体链，以查看反向转换及其恢复发送方链中相同流的尝试，这可能会受到有损压缩和不完善的媒体传输的影响。注意，来自反向变换的流，与来自媒体解码器的源流一样，在许多情况下与发送方侧的对应流不同；因此，它们的前缀为“received”，表示可能修改的版本。不一样的原因在于可以是不可逆类型的转换。例如，媒体编码器中的有损源编码防止从媒体解码器流出的源流与馈入媒体编码器的源流相同。其他原因包括媒体传输转换中的数据包丢失，即使使用基于RTP的修复，也无法修复。
+----------------------+ +----------------------+
| Media Transport | | Media Transport |
+----------------------+ +----------------------+
Received | Received | Secured
Secured RTP Stream Redundancy RTP Stream
V V
+----------------------+ +----------------------+
| RTP-Based Validation | | RTP-Based Validation |
+----------------------+ +----------------------+
| |
Received RTP Stream Received Redundancy RTP Stream
| |
| +--------------------+
V V
+----------------------+
| RTP-Based Repair |
+----------------------+
|
Repaired RTP Stream
V
+----------------------+
| Media Depacketizer |
+----------------------+
|
Received Encoded Stream
V
+----------------------+
| Media Decoder |
+----------------------+
|
Received Source Stream
V
+----------------------+
| Media Sink |--> Synchronization Information
+----------------------+
|
Received Raw Stream
V
+----------------------+
| Media Render |
+----------------------+
|
V
Physical Stimulus
+----------------------+ +----------------------+
| Media Transport | | Media Transport |
+----------------------+ +----------------------+
Received | Received | Secured
Secured RTP Stream Redundancy RTP Stream
V V
+----------------------+ +----------------------+
| RTP-Based Validation | | RTP-Based Validation |
+----------------------+ +----------------------+
| |
Received RTP Stream Received Redundancy RTP Stream
| |
| +--------------------+
V V
+----------------------+
| RTP-Based Repair |
+----------------------+
|
Repaired RTP Stream
V
+----------------------+
| Media Depacketizer |
+----------------------+
|
Received Encoded Stream
V
+----------------------+
| Media Decoder |
+----------------------+
|
Received Source Stream
V
+----------------------+
| Media Sink |--> Synchronization Information
+----------------------+
|
Received Raw Stream
V
+----------------------+
| Media Render |
+----------------------+
|
V
Physical Stimulus
Figure 2: Receiver Side Concepts of the Media Chain
图2：媒体链的接收方概念
The physical stimulus is a physical event in the analog domain that can be sampled and converted to digital form by an appropriate sensor or transducer. This includes sound waves making up audio, photons in a light field, or other excitations or interactions with sensors, like keystrokes on a keyboard.
物理刺激是模拟域中的物理事件，可通过适当的传感器或传感器进行采样并转换为数字形式。这包括构成音频的声波、光场中的光子或其他激励或与传感器的交互作用，如键盘上的击键。
Media Capture is the process of transforming the analog physical stimulus (Section 2.1.1) into digital media using an appropriate sensor or transducer. The media capture performs a digital sampling of the physical stimulus, usually periodically, and outputs this in some representation as a Raw Stream (Section 2.1.3). This data is considered "media", because it includes data that is periodically sampled or made up of a set of timed asynchronous events. The media capture is normally instantiated in some type of device, i.e., media capture device. Examples of different types of media capturing devices are digital cameras, microphones connected to A/D converters, or keyboards.
媒体捕获是使用适当的传感器或传感器将模拟物理刺激（第2.1.1节）转换为数字媒体的过程。媒体捕获通常定期对物理刺激进行数字采样，并以某种表示形式输出为原始流（第2.1.3节）。此数据被视为“媒体”，因为它包含定期采样或由一组定时异步事件组成的数据。媒体捕获通常在某种类型的设备（即媒体捕获设备）中实例化。不同类型的媒体捕获设备的示例包括数码相机、连接到A/D转换器的麦克风或键盘。
Characteristics:
特点：
o A media capture is identified either by hardware/manufacturer ID or via a session-scoped device identifier as mandated by the application usage.
o 媒体捕获通过硬件/制造商ID或通过应用程序使用要求的会话范围设备标识符进行标识。
o A media capture can generate an Encoded Stream (Section 2.1.7) if the capture device supports such a configuration.
o 如果捕获设备支持这种配置，则媒体捕获可以生成编码流（第2.1.7节）。
o The nature of the media capture may impose constraints on the clock handling in some of the subsequent steps. For example, many audio or video capture devices are not completely free in selecting the sample rate.
o 媒体捕获的性质可能会在一些后续步骤中对时钟处理施加限制。例如，许多音频或视频捕获设备在选择采样率时并非完全免费。
A raw stream is the time progressing stream of digitally sampled information, usually periodically sampled and provided by a media capture (Section 2.1.2). A raw stream can also contain synthesized media that may not require any explicit media capture, since it is already in an appropriate digital form.
原始流是数字采样信息的时间推进流，通常定期采样并由媒体捕获提供（第2.1.2节）。原始流还可以包含不需要任何显式媒体捕获的合成媒体，因为它已经是适当的数字形式。
A Media Source is the logical source of a time progressing digital media stream synchronized to a reference clock. This stream is called a source stream (Section 2.1.5). This transformation takes one or more raw streams (Section 2.1.3) and provides a source stream as output. The output is synchronized with a reference clock (Section 3.1), which can be as simple as a system local wall clock or as complex as an NTP synchronized clock.
媒体源是与参考时钟同步的时间推进数字媒体流的逻辑源。该流称为源流（第2.1.5节）。此转换采用一个或多个原始流（第2.1.3节），并提供源流作为输出。输出与参考时钟同步（第3.1节），参考时钟可以像系统本地挂钟一样简单，也可以像NTP同步时钟一样复杂。
The output can be of different types. One type is directly associated with a particular media capture's raw stream. Others are more conceptual sources, like an audio mix of multiple source streams (Figure 3). Mixing multiple streams typically requires that the input streams are possible to relate in time, meaning that they have to be source streams (Section 2.1.5) rather than raw streams. In Figure 3, the generated source stream is a mix of the three input source streams.
输出可以是不同的类型。一种类型与特定媒体捕获的原始流直接关联。其他的则是更概念化的源，比如多个源流的音频混合（图3）。混合多个流通常要求输入流可能在时间上相关，这意味着它们必须是源流（第2.1.5节），而不是原始流。在图3中，生成的源流是三个输入源流的混合。
Source Source Source
Stream Stream Stream
| | |
V V V
+--------------------------+
| Media Source |<-- Reference Clock
| Mixer |
+--------------------------+
|
V
Source Stream
Source Source Source
Stream Stream Stream
| | |
V V V
+--------------------------+
| Media Source |<-- Reference Clock
| Mixer |
+--------------------------+
|
V
Source Stream
Figure 3: Conceptual Media Source in the form of an Audio Mixer
图3：音频混音器形式的概念媒体源
Another possible example of a conceptual media source is a video surveillance switch, where the input is multiple source streams from different cameras, and the output is one of those source streams based on some selection criteria, such as round robin or some video activity measure.
概念媒体源的另一个可能示例是视频监视开关，其中输入是来自不同摄像机的多个源流，输出是基于一些选择标准（例如循环或一些视频活动度量）的那些源流之一。
A source stream is a stream of digital samples that has been synchronized with a reference clock and comes from a particular media source (Section 2.1.4).
源流是与参考时钟同步并来自特定媒体源的数字样本流（第2.1.4节）。
A media encoder is a transform that is responsible for encoding the media data from a source stream (Section 2.1.5) into another representation, usually more compact, that is output as an encoded stream (Section 2.1.7).
媒体编码器是一种转换，负责将媒体数据从源流（第2.1.5节）编码为另一种表示形式，通常更紧凑，输出为编码流（第2.1.7节）。
The media encoder step commonly includes pre-encoding transformations, such as scaling, resampling, etc. The media encoder can have a significant number of configuration options that affects the properties of the encoded stream. This includes properties such as codec, bitrate, start points for decoding, resolution, bandwidth, or other fidelity affecting properties.
媒体编码器步骤通常包括预编码转换，例如缩放、重采样等。媒体编码器可以具有大量影响编码流属性的配置选项。这包括诸如编解码器、比特率、解码起点、分辨率、带宽或其他影响保真度的属性。
Scalable media encoders need special attention as they produce multiple outputs that are potentially of different types. As shown in Figure 4, a scalable media encoder takes one input source stream and encodes it into multiple output streams of two different types: at least one encoded stream that is independently decodable and one or more Dependent Streams (Section 2.1.8). Decoding requires at least one encoded stream and zero or more dependent streams. A dependent stream's dependency is one of the grouping relations this document discusses further in Section 3.7.
可伸缩媒体编码器需要特别注意，因为它们产生多个可能不同类型的输出。如图4所示，可伸缩媒体编码器获取一个输入源流并将其编码为两种不同类型的多个输出流：至少一个可独立解码的编码流和一个或多个从属流（第2.1.8节）。解码需要至少一个编码流和零个或多个从属流。依赖流的依赖关系是本文档在第3.7节中进一步讨论的分组关系之一。
Source Stream
|
V
+--------------------------+
| Scalable Media Encoder |
+--------------------------+
| | ... |
V V V
Encoded Dependent Dependent
Stream Stream Stream
Source Stream
|
V
+--------------------------+
| Scalable Media Encoder |
+--------------------------+
| | ... |
V V V
Encoded Dependent Dependent
Stream Stream Stream
Figure 4: Scalable Media Encoder Input and Outputs
图4：可伸缩媒体编码器输入和输出
There are also other variants of encoders, like so-called Multiple Description Coding (MDC). Such media encoders produce multiple independent and thus individually decodable encoded streams. However, (logically) combining multiple of these encoded streams into a single Received Source Stream during decoding leads to an improvement in perceptual reproduced quality when compared to decoding a single encoded stream.
还有编码器的其他变体，如所谓的多描述编码（MDC）。这样的媒体编码器产生多个独立的、因而可单独解码的编码流。然而，与解码单个编码流相比，在解码期间，（逻辑上）将这些编码流中的多个组合成单个接收源流导致感知再现质量的改进。
Creating multiple encoded streams from the same source stream, where the encoded streams are neither in a scalable nor in an MDC
从同一源流创建多个编码流，其中编码流既不在可伸缩流中，也不在MDC中
relationship is commonly utilized in simulcast [SDP-SIMULCAST] environments.
关系通常用于同步广播[SDP-simulcast]环境。
A stream of time synchronized encoded media that can be independently decoded.
可独立解码的时间同步编码媒体流。
Due to temporal dependencies, an encoded stream may have limitations in where decoding can be started. These entry points, for example, Intra frames from a video encoder, may require identification and their generation may be event based or configured to occur periodically.
由于时间依赖性，编码流在可以开始解码的地方可能有限制。这些入口点（例如，来自视频编码器的帧内）可能需要识别，并且它们的生成可能基于事件或被配置为周期性地发生。
A stream of time synchronized encoded media fragments that are dependent on one or more encoded streams (Section 2.1.7) and zero or more dependent streams to be possible to decode.
依赖于一个或多个编码流（第2.1.7节）和零个或多个可解码的依赖流的时间同步编码媒体片段流。
Each dependent stream has a set of dependencies. These dependencies must be understood by the parties in a Multimedia Session (Section 2.2.4) that intend to use a dependent stream.
每个依赖流都有一组依赖项。在多媒体会话（第2.2.4节）中，打算使用依赖流的各方必须理解这些依赖关系。
The transformation of taking one or more encoded (Section 2.1.7) or dependent streams (Section 2.1.8) and putting their content into one or more sequences of packets, normally RTP Packets, and output Source RTP Streams (Section 2.1.10). This step includes both generating RTP Payloads as well as RTP packets. The Media Packetizer then selects which synchronization source(s) (SSRC) [RFC3550] and RTP Sessions (Section 2.2.2) to use.
获取一个或多个编码流（第2.1.7节）或从属流（第2.1.8节）并将其内容放入一个或多个包序列（通常为RTP包）和输出源RTP流（第2.1.10节）的转换。此步骤包括生成RTP有效负载和RTP数据包。然后，媒体打包器选择要使用的同步源（SSRC）[RFC3550]和RTP会话（第2.2.2节）。
The media packetizer can combine multiple encoded or dependent streams into one or more RTP Streams:
媒体打包器可以将多个编码流或从属流组合成一个或多个RTP流：
o The media packetizer can use multiple inputs when producing a single RTP stream. One such example is Single RTP stream on a Single media Transport (SRST) packetization when using Scalable Video Coding (SVC) (Section 3.7).
o 媒体打包器在生成单个RTP流时可以使用多个输入。一个这样的例子是当使用可伸缩视频编码（SVC）时，单个媒体传输（SRST）分组上的单个RTP流（第3.7节）。
o The media packetizer can also produce multiple RTP streams, for example, when encoded and/or dependent streams are distributed over multiple RTP streams. One example of this is Multiple RTP streams on Multiple media Transports (MRMT) packetization when using SVC (Section 3.7).
o 例如，当编码和/或从属流分布在多个RTP流上时，媒体打包器还可以产生多个RTP流。使用SVC时，多媒体传输（MRMT）打包上的多个RTP流就是一个例子（第3.7节）。
An RTP stream is a stream of RTP packets containing media data, source or redundant. The RTP stream is identified by an SSRC belonging to a particular RTP Session. The RTP session is identified as discussed in Section 2.2.2.
RTP流是包含媒体数据、源数据或冗余数据的RTP数据包流。RTP流由属于特定RTP会话的SSRC标识。RTP会话如第2.2.2节所述。
A source RTP stream is an RTP stream directly related to an encoded stream (Section 2.1.7), targeted for transport over RTP without any additional RTP-based Redundancy (Section 2.1.11) applied.
源RTP流是与编码流（第2.1.7节）直接相关的RTP流，目标是通过RTP传输，无需应用任何额外的基于RTP的冗余（第2.1.11节）。
Characteristics:
特点：
o Each RTP stream is identified by an SSRC [RFC3550] that is carried in every RTP and RTP Control Protocol (RTCP) packet header. The SSRC is unique in a specific RTP session context.
o 每个RTP流由每个RTP和RTP控制协议（RTCP）数据包头中携带的SSRC[RFC3550]标识。SSRC在特定RTP会话上下文中是唯一的。
o At any given point in time, an RTP stream can have one and only one SSRC, but SSRCs for a given RTP stream can change over time. SSRC collision and clock rate change [RFC7160] are examples of valid reasons to change SSRC for an RTP stream. In those cases, the RTP stream itself is not changed in any significant way, only the identifying SSRC number.
o 在任何给定的时间点，RTP流可以有一个且只有一个SSRC，但给定RTP流的SSRC可以随时间而改变。SSRC冲突和时钟速率更改[RFC7160]是为RTP流更改SSRC的有效原因的示例。在这些情况下，RTP流本身没有任何显著的变化，只有识别SSRC号。
o Each SSRC defines a unique RTP sequence numbering and timing space.
o 每个SSRC定义一个唯一的RTP序列编号和时序空间。
o Several RTP streams, each with their own SSRC, may represent a single media source.
o 多个RTP流（每个流都有自己的SSRC）可以表示单个媒体源。
o Several RTP streams, each with their own SSRC, can be carried in a single RTP session.
o 在一个RTP会话中可以承载多个RTP流，每个流都有自己的SSRC。
RTP-based redundancy is defined here as a transformation that generates redundant or repair packets sent out as a Redundancy RTP Stream (Section 2.1.12) to mitigate Network Transport (Section 2.1.18) impairments, like packet loss and delay. Note that this excludes the type of redundancy that most suitable media encoders (Section 2.1.6) may add to the media format of the encoded stream (Section 2.1.7) that makes it cope better with RTP packet losses.
基于RTP的冗余在这里定义为一种转换，该转换生成作为冗余RTP流（第2.1.12节）发送的冗余或修复数据包，以减轻网络传输（第2.1.18节）损伤，如数据包丢失和延迟。注意，这排除了最合适的媒体编码器（第2.1.6节）可能添加到编码流的媒体格式（第2.1.7节）中的冗余类型，这使其能够更好地处理RTP数据包丢失。
The RTP-based redundancy exists in many flavors: they may generate independent repair streams that are used in addition to the source stream (like RTP Retransmission (Section 3.10) and some special types of Forward Error Correction (FEC) (Section 3.11), like RTP stream
基于RTP的冗余以多种形式存在：除了源流（如RTP重传（第3.10节））和一些特殊类型的前向纠错（FEC）（第3.11节）外，还可以生成独立的修复流（如RTP流）
duplication (Section 3.8)); they may generate a new source stream by combining redundancy information with source information (using XOR FEC as a redundancy payload (Section 3.9)); or they may completely replace the source information with only redundancy packets.
复制（第3.8节）；它们可以通过将冗余信息与源信息相结合（使用XOR FEC作为冗余有效载荷（第3.9节））来生成新的源流；或者，它们可以仅用冗余数据包完全替换源信息。
A redundancy RTP stream is an RTP stream (Section 2.1.10) that contains no original source data, only redundant data, which may either be used as standalone or be combined with one or more Received RTP Streams (Section 2.1.23) to produce Repaired RTP Streams (Section 2.1.26).
冗余RTP流是一个RTP流（第2.1.10节），它不包含原始源数据，只包含冗余数据，可以作为独立数据使用，也可以与一个或多个接收的RTP流（第2.1.23节）组合以产生修复的RTP流（第2.1.26节）。
The optional RTP-based Security transformation applies security services such as authentication, integrity protection, and confidentiality to an input RTP stream, like what is specified in "The Secure Real-time Transport Protocol (SRTP)" [RFC3711], producing a Secured RTP Stream (Section 2.1.14). Either an RTP stream (Section 2.1.10) or a redundancy RTP stream (Section 2.1.12) can be used as input to this transformation.
可选的基于RTP的安全转换将身份验证、完整性保护和机密性等安全服务应用于输入RTP流，如“安全实时传输协议（SRTP）”[RFC3711]中规定的内容，从而生成安全RTP流（第2.1.14节）。RTP流（第2.1.10节）或冗余RTP流（第2.1.12节）可以用作此转换的输入。
In SRTP and the related Secure RTCP (SRTCP), all of the above-mentioned security services are optional, except for integrity protection of SRTCP, which is mandatory. Also confidentiality (encryption) is effectively optional in SRTP, since it is possible to use a NULL encryption algorithm. As described in [RFC7201], the strength of SRTP data origin authentication depends on the cryptographic transform and key management used. For example, in group communication, where it is sometimes possible to authenticate group membership but not the actual RTP stream sender.
在SRTP和相关的安全RTCP（SRTCP）中，上述所有安全服务都是可选的，但SRTCP的完整性保护是强制性的。此外，在SRTP中，机密性（加密）实际上是可选的，因为可以使用空加密算法。如[RFC7201]所述，SRTP数据源身份验证的强度取决于所使用的加密转换和密钥管理。例如，在组通信中，有时可以验证组成员身份，但不能验证实际的RTP流发送方。
RTP-based security and RTP-based redundancy can be combined in a few different ways. One way is depicted in Figure 1, where an RTP stream and its corresponding redundancy RTP stream are protected by separate RTP-based security transforms. In other cases, like when a Media Translator is adding FEC in Section 3.2.1.3 of [RTP-TOPOLOGIES], a middlebox can apply RTP-based redundancy to an already secured RTP stream instead of a source RTP stream. One example of that is depicted in Figure 5 below.
基于RTP的安全性和基于RTP的冗余可以以几种不同的方式组合在一起。一种方法如图1所示，其中RTP流及其对应的冗余RTP流由单独的基于RTP的安全转换进行保护。在其他情况下，例如当媒体转换器在[RTP-Topologys]第3.2.1.3节中添加FEC时，中间盒可以将基于RTP的冗余应用于已经安全的RTP流，而不是源RTP流。下面的图5中描述了一个示例。
Source RTP Stream +------------+
V | V
+----------------------+ | +----------------------+
| RTP-Based Security | | | RTP-Based Redundancy |
+----------------------+ | +----------------------+
| | |
| | Redundancy RTP Stream
+-------------+ |
| V
| +----------------------+
Secured RTP Stream | RTP-Based Security |
| +----------------------+
| |
| Secured Redundancy RTP Stream
V V
+----------------------+ +----------------------+
| Media Transport | | Media Transport |
+----------------------+ +----------------------+
Source RTP Stream +------------+
V | V
+----------------------+ | +----------------------+
| RTP-Based Security | | | RTP-Based Redundancy |
+----------------------+ | +----------------------+
| | |
| | Redundancy RTP Stream
+-------------+ |
| V
| +----------------------+
Secured RTP Stream | RTP-Based Security |
| +----------------------+
| |
| Secured Redundancy RTP Stream
V V
+----------------------+ +----------------------+
| Media Transport | | Media Transport |
+----------------------+ +----------------------+
Figure 5: Adding Redundancy to a Secured RTP Stream
图5：向安全RTP流添加冗余
In this case, the redundancy RTP stream may already have been secured for confidentiality (encrypted) by the first RTP-based security, and it may therefore not be necessary to apply additional confidentiality protection in the second RTP-based security. To avoid attacks and negative impact on RTP-based Repair (Section 2.1.25) and the resulting repaired RTP stream (Section 2.1.26), it is, however, still necessary to have this second RTP-based security apply both authentication and integrity protection to the redundancy RTP stream.
在这种情况下，冗余RTP流可能已经由第一个基于RTP的安全性进行了保密（加密），因此可能没有必要在第二个基于RTP的安全性中应用额外的保密保护。然而，为了避免攻击和对基于RTP的修复（第2.1.25节）以及由此产生的修复RTP流（第2.1.26节）的负面影响，仍然有必要让第二个基于RTP的安全性对冗余RTP流应用身份验证和完整性保护。
A secured RTP stream is a source or redundancy RTP stream that is protected through RTP-based security (Section 2.1.13) by one or more of the confidentiality, integrity, or authentication security services.
安全RTP流是源或冗余RTP流，由一个或多个保密性、完整性或认证安全服务通过基于RTP的安全性（第2.1.13节）进行保护。
A media transport defines the transformation that the RTP streams (Section 2.1.10) are subjected to by the end-to-end transport from one RTP Sender (Section 4.12) to one specific RTP Receiver (Section 4.11) (an RTP session (Section 2.2.2) may contain multiple RTP receivers per sender). Each media transport is defined by a transport association that is normally identified by a 5-tuple (source address, source port, destination address, destination port, transport protocol), but a proposal exists for sending multiple transport associations on a single 5-tuple [TRANSPORT-MULTIPLEX].
媒体传输定义了RTP流（第2.1.10节）通过从一个RTP发送方（第4.12节）到一个特定RTP接收方（第4.11节）的端到端传输进行的转换（RTP会话（第2.2.2节）可能包含每个发送方的多个RTP接收方）。每个媒体传输由一个传输关联定义，该关联通常由一个5元组（源地址、源端口、目标地址、目标端口、传输协议）标识，但有一个建议是在一个5元组上发送多个传输关联[transport-MULTIPLEX]。
Characteristics:
特点：
o Media transport transmits RTP streams of RTP packets from a source transport address to a destination transport address.
o 媒体传输将RTP包的RTP流从源传输地址传输到目标传输地址。
o Each media transport contains only a single RTP session.
o 每个媒体传输仅包含一个RTP会话。
o A single RTP session can span multiple media transports.
o 单个RTP会话可以跨多个媒体传输。
The media transport concept sometimes needs to be decomposed into more steps to enable discussion of what a sender emits that gets transformed by the network before it is received by the receiver. Thus, we provide also this media transport decomposition (Figure 6).
媒体传输的概念有时需要分解成更多的步骤，以便讨论发送方发出的内容，这些内容在被接收方接收之前被网络转换。因此，我们也提供了这种媒体传输分解（图6）。
RTP Stream
|
V
+--------------------------+
| Media Transport Sender |
+--------------------------+
|
Sent RTP Stream
V
+--------------------------+
| Network Transport |
+--------------------------+
|
Transported RTP Stream
V
+--------------------------+
| Media Transport Receiver |
+--------------------------+
|
V
Received RTP Stream
RTP Stream
|
V
+--------------------------+
| Media Transport Sender |
+--------------------------+
|
Sent RTP Stream
V
+--------------------------+
| Network Transport |
+--------------------------+
|
Transported RTP Stream
V
+--------------------------+
| Media Transport Receiver |
+--------------------------+
|
V
Received RTP Stream
Figure 6: Decomposition of Media Transport
图6：媒体传输的分解
The first transformation within the media transport (Section 2.1.15) is the Media Transport Sender. The sending Endpoint (Section 2.2.1) takes an RTP stream and emits the packets onto the network using the transport association established for this media transport, thereby creating a Sent RTP Stream (Section 2.1.17). In the process, it transforms the RTP stream in several ways. First, it generates the necessary protocol headers for the transport association, for example, IP and UDP headers, thus forming IP/UDP/RTP packets. In
媒体传输（第2.1.15节）中的第一个转换是媒体传输发送方。发送端点（第2.2.1节）接收RTP流，并使用为此媒体传输建立的传输关联将数据包发送到网络上，从而创建发送的RTP流（第2.1.17节）。在此过程中，它以多种方式转换RTP流。首先，它为传输关联生成必要的协议头，例如IP和UDP头，从而形成IP/UDP/RTP数据包。在里面
addition, the media transport sender may queue, intentionally pace, or otherwise affect how the packets are emitted onto the network, thereby potentially introducing delay and delay variations [RFC5481] that characterize the sent RTP stream.
此外，媒体传输发送方可以排队、故意调整速度或以其他方式影响分组如何发射到网络上，从而潜在地引入表征所发送RTP流的延迟和延迟变化[RFC5481]。
The sent RTP stream is the RTP stream as entering the first hop of the network path to its destination. The sent RTP stream is identified using network transport addresses, like the 5-tuple (source IP address, source port, destination IP address, destination port, and protocol (UDP)) for IP/UDP.
发送的RTP流是进入到其目的地的网络路径的第一跳的RTP流。发送的RTP流使用网络传输地址标识，如IP/UDP的5元组（源IP地址、源端口、目标IP地址、目标端口和协议（UDP））。
Network transport is the transformation that subjects the sent RTP stream (Section 2.1.17) to traveling from the source to the destination through the network. This transformation can result in loss of some packets, delay, and delay variation on a per-packet basis, packet duplication, and packet header or data corruption. This transformation produces a Transported RTP Stream (Section 2.1.19) at the exit of the network path.
网络传输是将发送的RTP流（第2.1.17节）通过网络从源传输到目的地的转换。这种转换可能导致某些数据包丢失、延迟和每个数据包的延迟变化、数据包重复以及数据包头或数据损坏。此转换在网络路径的出口处产生传输的RTP流（第2.1.19节）。
The transported RTP stream is the RTP stream that is emitted out of the network path at the destination, subjected to the network transport's transformation (Section 2.1.18).
传输的RTP流是从目的地的网络路径发出的RTP流，经过网络传输的转换（第2.1.18节）。
The Media Transport Receiver is the receiver endpoint's (Section 2.2.1) transformation of the transported RTP stream (Section 2.1.19) by its reception process, which results in the received RTP stream (Section 2.1.23). This transformation includes transport checksums being verified. Sensible system designs typically either discard packets with mismatching checksums or pass them on while somehow marking them in the resulting received RTP stream so to alert subsequent transformations about the possible corrupt state. In this context, it is worth noting that there is typically some probability for corrupt packets to pass through undetected (with a seemingly correct checksum). Other transformations can compensate for delay variations in receiving a packet on the network interface and providing it to the application (de-jitter buffer).
媒体传输接收器是接收器端点（第2.2.1节）通过其接收过程对传输的RTP流（第2.1.19节）进行的转换，从而产生接收的RTP流（第2.1.23节）。此转换包括正在验证的传输校验和。明智的系统设计通常要么丢弃校验和不匹配的数据包，要么传递它们，同时以某种方式将它们标记在最终接收的RTP流中，以便提醒后续转换可能的损坏状态。在这种情况下，值得注意的是，通常存在腐败数据包通过而未被检测到的概率（使用看似正确的校验和）。其他转换可以补偿在网络接口上接收数据包并将其提供给应用程序（去抖动缓冲区）时的延迟变化。
This is the secured RTP stream (Section 2.1.14) resulting from the media transport (Section 2.1.15) aggregate transformation.
这是媒体传输（第2.1.15节）聚合转换产生的安全RTP流（第2.1.14节）。
RTP-based Validation is the reverse transformation of RTP-based security (Section 2.1.13). If this transformation fails, the result is either not usable and must be discarded or may be usable but cannot be trusted. If the transformation succeeds, the result can be a received RTP stream (Section 2.1.23) or a Received Redundancy RTP Stream (Section 2.1.24), depending on what was input to the corresponding RTP-based security transformation, but it can also be a Received Secured RTP Stream (Section 2.1.21) in case several RTP-based security transformations were applied.
基于RTP的验证是基于RTP的安全性的反向转换（第2.1.13节）。如果此转换失败，则结果要么不可用，必须放弃，要么可用，但不可信。如果转换成功，结果可以是接收到的RTP流（第2.1.23节）或接收到的冗余RTP流（第2.1.24节），具体取决于输入到相应的基于RTP的安全转换的内容，但也可以是接收到的安全RTP流（第2.1.21节）在这种情况下，应用了几个基于RTP的安全转换。
The received RTP stream is the RTP stream (Section 2.1.10) resulting from the media transport's aggregate transformation (Section 2.1.15), i.e., subjected to packet loss, packet corruption, packet duplication, delay, and delay variation from sender to receiver.
接收到的RTP流是由媒体传输的聚合转换（第2.1.15节）产生的RTP流（第2.1.10节），即，在发送方和接收方之间受到数据包丢失、数据包损坏、数据包复制、延迟和延迟变化的影响。
The received redundancy RTP stream is the redundancy RTP stream (Section 2.1.12) resulting from the media transport's aggregate transformation, i.e., subjected to packet loss, packet corruption, packet duplication, delay, and delay variation from sender to receiver.
接收到的冗余RTP流是由媒体传输的聚合转换产生的冗余RTP流（第2.1.12节），即，在发送方和接收方之间受到数据包丢失、数据包损坏、数据包重复、延迟和延迟变化的影响。
RTP-based repair is a transformation that takes as input zero or more received RTP streams (Section 2.1.23) and one or more received redundancy RTP streams (Section 2.1.24) and produces one or more repaired RTP streams (Section 2.1.26) that are as close to the corresponding sent source RTP streams (Section 2.1.10) as possible, using different RTP-based repair methods, for example, the ones referred to in RTP-based redundancy (Section 2.1.11).
基于RTP的修复是一种转换，它将零个或多个接收RTP流（第2.1.23节）和一个或多个接收冗余RTP流（第2.1.24节）作为输入，并产生一个或多个修复RTP流（第2.1.26节），这些流尽可能接近相应的发送源RTP流（第2.1.10节），使用不同的基于RTP的修复方法，例如，基于RTP的冗余（第2.1.11节）中提到的方法。
A repaired RTP stream is a received RTP stream (Section 2.1.23) for which received redundancy RTP stream (Section 2.1.24) information has been used to try to recover the source RTP stream (Section 2.1.10) as it was before media transport (Section 2.1.15).
修复后的RTP流是接收到的RTP流（第2.1.23节），其接收到的冗余RTP流（第2.1.24节）信息已被用于尝试恢复源RTP流（第2.1.10节），与媒体传输（第2.1.15节）之前一样。
A Media Depacketizer takes one or more RTP streams (Section 2.1.10), depacketizes them, and attempts to reconstitute the encoded streams (Section 2.1.7) or dependent streams (Section 2.1.8) present in those RTP streams.
媒体解包器获取一个或多个RTP流（第2.1.10节），对其进行解包，并尝试重建这些RTP流中存在的编码流（第2.1.7节）或从属流（第2.1.8节）。
In practical implementations, the media depacketizer and the media decoder may be tightly coupled and share information to improve or optimize the overall decoding and error concealment process. It is, however, not expected that there would be any benefit in defining a taxonomy for those detailed (and likely very implementation-dependent) steps.
在实际实现中，媒体解分组器和媒体解码器可以紧密耦合并共享信息，以改进或优化整体解码和错误隐藏过程。然而，为那些详细的（可能非常依赖于实现的）步骤定义分类法并不会带来任何好处。
The Received Encoded Stream is the received version of an encoded stream (Section 2.1.7).
接收到的编码流是编码流的接收版本（第2.1.7节）。
A media decoder is a transformation that is responsible for decoding encoded streams (Section 2.1.7) and any dependent streams (Section 2.1.8) into a source stream (Section 2.1.5).
媒体解码器是负责将编码流（第2.1.7节）和任何从属流（第2.1.8节）解码为源流（第2.1.5节）的转换。
In practical implementations, the media decoder and the media depacketizer may be tightly coupled and share information to improve or optimize the overall decoding process in various ways. It is, however, not expected that there would be any benefit in defining a taxonomy for those detailed (and likely very implementation-dependent) steps.
在实际实现中，媒体解码器和媒体解分组器可以紧密耦合并共享信息，以各种方式改进或优化整体解码过程。然而，为那些详细的（可能非常依赖于实现的）步骤定义分类法并不会带来任何好处。
A media decoder has to deal with any errors in the encoded streams that resulted from corruption or failure to repair packet losses. Therefore, it commonly is robust to error and losses, and includes concealment methods.
媒体解码器必须处理由于损坏或无法修复数据包丢失而导致的编码流中的任何错误。因此，它通常对错误和损失具有鲁棒性，并且包括隐藏方法。
The received source stream is the received version of a source stream (Section 2.1.5).
接收到的源流是源流的接收版本（第2.1.5节）。
The Media Sink receives a source stream (Section 2.1.5) that contains, usually periodically, sampled media data together with associated synchronization information. Depending on application, this source stream then needs to be transformed into a raw stream (Section 2.1.3) that is conveyed to the Media Render (Section 2.1.33) and synchronized with the output from other media sinks. The media sink may also be connected with a media source (Section 2.1.4) and be used as part of a conceptual media source.
媒体接收器接收源流（第2.1.5节），该源流通常定期包含采样的媒体数据以及相关的同步信息。根据应用程序的不同，该源流随后需要转换为原始流（第2.1.3节），该原始流被传送到媒体渲染（第2.1.33节），并与其他媒体接收器的输出同步。媒体接收器也可与媒体源（第2.1.4节）连接，并用作概念媒体源的一部分。
The media sink can further transform the source stream into a representation that is suitable for rendering on the media render as defined by the application or system-wide configuration. This includes sample scaling, level adjustments, etc.
媒体接收器可以进一步将源流转换为适合在由应用程序或系统范围配置定义的媒体渲染上渲染的表示。这包括样本缩放、级别调整等。
The Received Raw Stream is the received version of a raw stream (Section 2.1.3).
接收到的原始流是原始流的接收版本（第2.1.3节）。
A media render takes a raw stream (Section 2.1.3) and converts it into physical stimulus (Section 2.1.1) that a human user can perceive. Examples of such devices are screens and D/A converters connected to amplifiers and loudspeakers.
媒体渲染采用原始流（第2.1.3节）并将其转换为人类用户可以感知的物理刺激（第2.1.1节）。这种装置的例子是连接到放大器和扬声器的屏幕和D/A转换器。
An endpoint can potentially have multiple media renders for each media type.
对于每种媒体类型，端点可能具有多个媒体呈现。
This section contains concepts for entities involved in the communication.
本节包含通信中涉及的实体的概念。
+------------------------------------------------------------+
| Communication Session |
| |
| +----------------+ +----------------+ |
| | Participant A | +------------+ | Participant B | |
| | | | Multimedia | | | |
| | +------------+ |<==>| Session |<==>| +------------+ | |
| | | Endpoint A | | | | | | Endpoint B | | |
| | | | | +------------+ | | | | |
| | | +----------+-+----------------------+-+----------+ | | |
| | | | RTP | | | | | | | |
| | | | Session |-+---Media Transport----+>| | | | |
| | | | Audio |<+---Media Transport----+-| | | | |
| | | | | | ^ | | | | | |
| | | +----------+-+----------|-----------+-+----------+ | | |
| | | | | v | | | | |
| | | | | +-----------------+ | | | | |
| | | | | | Synchronization | | | | | |
| | | | | | Context | | | | | |
| | | | | +-----------------+ | | | | |
| | | | | ^ | | | | |
| | | +----------+-+----------|-----------+-+----------+ | | |
| | | | RTP | | v | | | | | |
| | | | Session |<+---Media Transport----+-| | | | |
| | | | Video |-+---Media Transport----+>| | | | |
| | | | | | | | | | | |
| | | +----------+-+----------------------+-+----------+ | | |
| | +------------+ | | +------------+ | |
| +----------------+ +----------------+ |
+------------------------------------------------------------+
+------------------------------------------------------------+
| Communication Session |
| |
| +----------------+ +----------------+ |
| | Participant A | +------------+ | Participant B | |
| | | | Multimedia | | | |
| | +------------+ |<==>| Session |<==>| +------------+ | |
| | | Endpoint A | | | | | | Endpoint B | | |
| | | | | +------------+ | | | | |
| | | +----------+-+----------------------+-+----------+ | | |
| | | | RTP | | | | | | | |
| | | | Session |-+---Media Transport----+>| | | | |
| | | | Audio |<+---Media Transport----+-| | | | |
| | | | | | ^ | | | | | |
| | | +----------+-+----------|-----------+-+----------+ | | |
| | | | | v | | | | |
| | | | | +-----------------+ | | | | |
| | | | | | Synchronization | | | | | |
| | | | | | Context | | | | | |
| | | | | +-----------------+ | | | | |
| | | | | ^ | | | | |
| | | +----------+-+----------|-----------+-+----------+ | | |
| | | | RTP | | v | | | | | |
| | | | Session |<+---Media Transport----+-| | | | |
| | | | Video |-+---Media Transport----+>| | | | |
| | | | | | | | | | | |
| | | +----------+-+----------------------+-+----------+ | | |
| | +------------+ | | +------------+ | |
| +----------------+ +----------------+ |
+------------------------------------------------------------+
Figure 7: Example Point-to-Point Communication Session with Two RTP Sessions
图7：具有两个RTP会话的点对点通信会话示例
Figure 7 shows a high-level example representation of a very basic point-to-point Communication Session between Participants A and B. It uses two different audio and video RTP sessions between A's and B's endpoints, where each RTP session is a group communications channel that can potentially carry a number of RTP streams. It is using separate media transports for those RTP sessions. The multimedia session shared by the participants can, for example, be established using SIP (i.e., there is a SIP dialog between A and B).
图7显示了参与者a和B之间非常基本的点对点通信会话的高级示例表示。它在a和B的端点之间使用两个不同的音频和视频RTP会话，其中每个RTP会话是一个组通信信道，可能承载多个RTP流。对于那些RTP会话，它使用单独的媒体传输。参与者共享的多媒体会话例如可以使用SIP建立（即，a和B之间存在SIP对话）。
The terms used in Figure 7 are further elaborated in the subsections below.
图7中使用的术语将在下面的小节中进一步阐述。
An endpoint is a single addressable entity sending or receiving RTP packets. It may be decomposed into several functional blocks, but as long as it behaves as a single RTP stack entity, it is classified as a single "endpoint".
端点是发送或接收RTP数据包的单个可寻址实体。它可以分解为几个功能块，但只要它作为单个RTP堆栈实体，它就被归类为单个“端点”。
Characteristics:
特点：
o Endpoints can be identified in several different ways. While RTCP Canonical Names (CNAMEs) [RFC3550] provide a globally unique and stable identification mechanism for the duration of the communication session (see Section 2.2.5), their validity applies exclusively within a Synchronization Context (Section 3.1). Thus, one endpoint can handle multiple CNAMEs, each of which can be shared among a set of endpoints belonging to the same participant (Section 2.2.3). Therefore, mechanisms outside the scope of RTP, such as application-defined mechanisms, must be used to provide endpoint identification when outside this synchronization context.
o 端点可以用几种不同的方式标识。虽然RTCP规范名称（CNAMEs）[RFC3550]在通信会话期间提供了全局唯一且稳定的标识机制（见第2.2.5节），但其有效性仅适用于同步上下文（第3.1节）。因此，一个端点可以处理多个CNAME，每个CNAME都可以在属于同一参与者的一组端点之间共享（第2.2.3节）。因此，RTP范围之外的机制（如应用程序定义的机制）必须用于在该同步上下文之外提供端点标识。
o An endpoint can be associated with at most one participant (Section 2.2.3) at any single point in time.
o 在任何单个时间点，一个端点最多可与一个参与者（第2.2.3节）关联。
o In some contexts, an endpoint would typically correspond to a single "host", for example, a computer using a single network interface and being used by a single human user. In other contexts, a single "host" can serve multiple participants, in which case each participant's endpoint may share properties, for example, the IP address part of a transport address.
o 在某些上下文中，端点通常对应于单个“主机”，例如，使用单个网络接口并由单个人类用户使用的计算机。在其他上下文中，单个“主机”可以服务于多个参与者，在这种情况下，每个参与者的端点可以共享属性，例如，传输地址的IP地址部分。
An RTP session is an association among a group of participants communicating with RTP. It is a group communications channel that can potentially carry a number of RTP streams. Within an RTP session, every participant can find metadata and control information (over RTCP) about all the RTP streams in the RTP session. The bandwidth of the RTCP control channel is shared between all participants within an RTP session.
RTP会话是一组与RTP通信的参与者之间的关联。它是一个可能承载多个RTP流的组通信信道。在RTP会话中，每个参与者都可以找到关于RTP会话中所有RTP流的元数据和控制信息（通过RTCP）。RTP控制通道的带宽在RTP会话中的所有参与者之间共享。
Characteristics:
特点：
o An RTP session can carry one or more RTP streams.
o RTP会话可以承载一个或多个RTP流。
o An RTP session shares a single SSRC space as defined in [RFC3550]. That is, the endpoints participating in an RTP session can see an SSRC identifier transmitted by any of the other endpoints. An endpoint can receive an SSRC either as SSRC or as a contributing source (CSRC) in RTP and RTCP packets, as defined by the endpoints' network interconnection topology.
o RTP会话共享[RFC3550]中定义的单个SSRC空间。也就是说，参与RTP会话的端点可以看到由任何其他端点传输的SSRC标识符。端点可以在RTP和RTCP数据包中作为SSRC或贡献源（CSC）接收SSRC，这由端点的网络互连拓扑定义。
o An RTP session uses at least two media transports (Section 2.1.15): one for sending and one for receiving. Commonly, the receiving media transport is the reverse direction of the media transport used for sending. An RTP session may use many media transports and these define the session's network interconnection topology.
o RTP会话至少使用两种媒体传输（第2.1.15节）：一种用于发送，另一种用于接收。通常，接收媒体传输与用于发送的媒体传输方向相反。RTP会话可以使用许多媒体传输，这些传输定义了会话的网络互连拓扑。
o A single media transport always carries a single RTP session.
o 单个媒体传输始终承载单个RTP会话。
o Multiple RTP sessions can be conceptually related, for example, originating from or targeted for the same participant (Section 2.2.3) or endpoint (Section 2.2.1), or by containing RTP streams that are somehow related (Section 3).
o 多个RTP会话可以是概念上相关的，例如，源于或针对同一参与者（第2.2.3节）或端点（第2.2.1节），或者通过包含某种相关的RTP流（第3节）。
A participant is an entity reachable by a single signaling address and is thus related more to the signaling context than to the media context.
参与者是可由单个信令地址访问的实体，因此与信令上下文的关系大于与媒体上下文的关系。
Characteristics:
特点：
o A single signaling-addressable entity, using an application-specific signaling address space, for example, a SIP URI.
o 单个信令可寻址实体，使用特定于应用程序的信令地址空间，例如SIPURI。
o A participant can participate in several multimedia sessions (Section 2.2.4).
o 参与者可以参加多个多媒体会议（第2.2.4节）。
o A participant can be comprised of several associated endpoints (Section 2.2.1).
o 参与者可以由多个相关端点组成（第2.2.1节）。
A multimedia session is an association among a group of participants (Section 2.2.3) engaged in the communication via one or more RTP sessions (Section 2.2.2). It defines logical relationships among media sources (Section 2.1.4) that appear in multiple RTP sessions.
多媒体会话是通过一个或多个RTP会话（第2.2.2节）参与通信的一组参与者（第2.2.3节）之间的关联。它定义了出现在多个RTP会话中的媒体源（第2.1.4节）之间的逻辑关系。
Characteristics:
特点：
o A multimedia session can be composed of several RTP sessions with potentially multiple RTP streams per RTP session.
o 多媒体会话可以由多个RTP会话组成，每个RTP会话可能有多个RTP流。
o Each participant in a multimedia session can have a multitude of media captures and media rendering devices.
o 多媒体会话中的每个参与者都可以拥有多种媒体捕获和媒体渲染设备。
o A single multimedia session can contain media from one or more synchronization contexts (Section 3.1). An example of that is a multimedia session containing one set of audio and video for communication purposes belonging to one synchronization context, and another set of audio and video for presentation purposes (like playing a video file) with a separate synchronization context that has no strong timing relationship and need not be strictly synchronized with the audio and video used for communication.
o 单个多媒体会话可以包含来自一个或多个同步上下文的媒体（第3.1节）。一个例子是多媒体会话，其中包含一组属于一个同步上下文的用于通信目的的音频和视频，以及另一组用于表示目的的音频和视频（如播放视频文件）具有独立的同步上下文，该上下文没有强的定时关系，并且不需要与用于通信的音频和视频严格同步。
A communication session is an association among two or more participants (Section 2.2.3) communicating with each other via one or more multimedia sessions (Section 2.2.4).
通信会话是两个或多个参与者（第2.2.3节）之间通过一个或多个多媒体会话（第2.2.4节）相互通信的关联。
Characteristics:
特点：
o Each participant in a communication session is identified via an application-specific signaling address.
o 通信会话中的每个参与者通过特定于应用的信令地址来识别。
o A communication session is composed of participants that share at least one multimedia session, involving one or more parallel RTP sessions with potentially multiple RTP streams per RTP session.
o 通信会话由共享至少一个多媒体会话的参与者组成，其中包括一个或多个并行RTP会话，每个RTP会话可能有多个RTP流。
For example, in a full mesh communication, the communication session consists of a set of separate multimedia sessions between each pair of participants. Another example is a centralized conference, where the communication session consists of a set of multimedia sessions between each participant and the conference handler.
例如，在全网状通信中，通信会话由每对参与者之间的一组单独的多媒体会话组成。另一个例子是集中式会议，其中通信会话由每个参与者和会议处理程序之间的一组多媒体会话组成。
This section uses the concepts from previous sections and looks at different types of relationships among them. These relationships occur at different abstraction levels and for different purposes, but the reason for the needed relationship at a certain step in the media handling chain may exist at another step. For example, the use of simulcast (Section 3.6) implies a need to determine relations at the
本节使用前几节中的概念，并研究它们之间不同类型的关系。这些关系发生在不同的抽象级别，用于不同的目的，但在媒体处理链的某个步骤中需要关系的原因可能存在于另一个步骤中。例如，使用同步广播（第3.6节）意味着需要在
RTP stream level, but the underlying reason is that multiple media encoders use the same media source, i.e., to be able to identify a common media source.
RTP流级别，但根本原因是多个媒体编码器使用相同的媒体源，即，能够识别公共媒体源。
A synchronization context defines a requirement for a strong timing relationship between the media sources, typically requiring alignment of clock sources. Such a relationship can be identified in multiple ways as listed below. A single media source can only belong to a single synchronization context, since it is assumed that a single media source can only have a single media clock and requiring alignment to several synchronization contexts (and thus reference clocks) will effectively merge those into a single synchronization context.
同步上下文定义了对媒体源之间的强定时关系的要求，通常需要对时钟源进行校准。这种关系可以通过以下多种方式确定。单个媒体源只能属于单个同步上下文，因为假定单个媒体源只能具有单个媒体时钟，并且需要与多个同步上下文（以及参考时钟）对齐，这将有效地将它们合并到单个同步上下文中。
[RFC3550] describes inter-media synchronization between RTP sessions based on RTCP CNAME, RTP, and timestamps of a reference clock formatted using the Network Time Protocol (NTP) [RFC5905]. As indicated in [RFC7273], despite using NTP format timestamps, it is not required that the clock be synchronized to an NTP source.
[RFC3550]描述了基于RTCP CNAME、RTP和使用网络时间协议（NTP）格式化的参考时钟的时间戳的RTP会话之间的媒体间同步[RFC5905]。如[RFC7273]所示，尽管使用NTP格式的时间戳，但不要求时钟与NTP源同步。
[RFC7273] provides a mechanism to signal the clock source in the Session Description Protocol (SDP) [RFC4566] both for the reference clock as well as the media clock, thus allowing a synchronization context to be defined beyond the one defined by the usage of CNAME source descriptions.
[RFC7273]提供了一种机制，用于向会话描述协议（SDP）[RFC4566]中的时钟源发送参考时钟和媒体时钟的信号，从而允许在使用CNAME源描述定义的同步上下文之外定义同步上下文。
WebRTC defines RtcMediaStream with one or more RtcMediaStreamTracks. All tracks in a RtcMediaStream are intended to be synchronized when rendered, implying that they must be generated such that synchronization is possible.
WebRTC使用一个或多个RtcMediaStreamTracks定义RtcMediaStream。RtcMediaStream中的所有曲目在渲染时都要同步，这意味着必须生成这些曲目才能实现同步。
The SDP Grouping Framework [RFC5888] defines an "m=" line (Section 4.2) grouping mechanism called Lip Synchronization (with LS identification-tag) for establishing the synchronization requirement across "m=" lines when they map to individual sources.
SDP分组框架[RFC5888]定义了一种“m=”行（第4.2节）分组机制，称为Lip同步（带LS标识标签），用于在“m=”行映射到单个源时跨它们建立同步要求。
Source-Specific Media Attributes in SDP [RFC5576] extends the above mechanism when multiple media sources are described by a single "m=" line.
SDP[RFC5576]中的源特定媒体属性扩展了上述机制，即当多个媒体源由单个“m=”行描述时。
Some applications require knowledge of what media sources originate from a particular endpoint (Section 2.2.1). This can include such decisions as packet routing between parts of the topology, knowing the endpoint origin of the RTP streams.
某些应用程序需要了解哪些媒体源来自特定端点（第2.2.1节）。这可以包括诸如拓扑部分之间的分组路由之类的决策，知道RTP流的端点来源。
In RTP, this identification has been overloaded with the synchronization context (Section 3.1) through the usage of the RTCP source description CNAME (Section 3.1.1). This works for some usages, but in others it breaks down. For example, if an endpoint has two sets of media sources that have different synchronization contexts, like the audio and video of the human participant as well as a set of media sources of audio and video for a shared movie, CNAME would not be an appropriate identification for that endpoint. Therefore, an endpoint may have multiple CNAMEs. The CNAMEs or the media sources themselves can be related to the endpoint.
在RTP中，通过使用RTCP源描述CNAME（第3.1.1节），同步上下文（第3.1节）重载了该标识。这在某些用法中有效，但在另一些用法中则失效。例如，如果一个端点有两组具有不同同步上下文的媒体源，如人类参与者的音频和视频以及一组共享电影的音频和视频媒体源，那么CNAME将不是该端点的适当标识。因此，一个端点可能有多个CNAME。CNAMEs或媒体源本身可以与端点相关。
In communication scenarios, information about which media sources originate from which participant (Section 2.2.3) is commonly needed. One reason is, for example, to enable the application to correctly display participant identity information associated with the media sources. This association is handled through signaling to point at a specific multimedia session where the media sources may be explicitly or implicitly tied to a particular endpoint.
在通信场景中，通常需要关于哪些媒体源来自哪个参与者的信息（第2.2.3节）。一个原因是，例如，使应用程序能够正确显示与媒体源关联的参与者身份信息。该关联通过指向特定多媒体会话的信令来处理，其中媒体源可以显式或隐式地绑定到特定端点。
Participant information becomes more problematic when there are media sources that are generated through mixing or other conceptual processing of raw streams or source streams that originate from different participants. These types of media sources can thus have a dynamically varying set of origins and participants. RTP contains the concept of CSRC that carries information about the previous step origin of the included media content on the RTP level.
当存在通过混合或其他概念性处理原始流或源于不同参与者的源流而生成的媒体源时，参与者信息变得更加困难。因此，这些类型的媒体源可以有一组动态变化的来源和参与者。RTP包含CSC的概念，该概念在RTP级别上承载有关所包含媒体内容的上一步骤来源的信息。
An RtcMediaStream in WebRTC is an explicit grouping of a set of media sources (RtcMediaStreamTracks) that share a common identifier and a single synchronization context (Section 3.1).
WebRTC中的RtcMediaStream是一组共享公共标识符和单个同步上下文的媒体源（RtcMediaStreamTracks）的显式分组（第3.1节）。
There exist a number of RTP payload formats that can carry multi-channel audio, despite the codec being a single-channel (mono) encoder. Multi-channel audio can be viewed as multiple media sources sharing a common synchronization context. These are independently encoded by a media encoder and the different encoded streams are packetized together in a time-synchronized way into a single source RTP stream, using the used codec's RTP payload format. Examples of codecs that support multi-channel audio are PCMA and PCMU [RFC3551], Adaptive Multi Rate (AMR) [RFC4867], and G.719 [RFC5404].
尽管编解码器是单通道（mono）编码器，但仍存在许多可以承载多通道音频的RTP有效负载格式。多通道音频可以被视为共享一个公共同步上下文的多个媒体源。这些由媒体编码器独立编码，并且使用所用编解码器的RTP有效负载格式，以时间同步的方式将不同的编码流打包到一个源RTP流中。支持多声道音频的编解码器示例有PCMA和PCMU[RFC3551]、自适应多速率（AMR）[RFC4867]和G.719[RFC5404]。
A media source represented as multiple independent encoded streams constitutes a simulcast [SDP-SIMULCAST] or Modification Detection Code (MDC) of that media source. Figure 8 shows an example of a media source that is encoded into three separate simulcast streams, that are in turn sent on the same media transport flow. When using simulcast, the RTP streams may be sharing an RTP session and media transport, or be separated on different RTP sessions and media transports, or be any combination of these two. One major reason to use separate media transports is to make use of different quality of service (QoS) for the different source RTP streams. Some considerations on separating related RTP streams are discussed in Section 3.12.
表示为多个独立编码流的媒体源构成该媒体源的同步广播[SDP-simulcast]或修改检测码（MDC）。图8显示了一个媒体源的示例，该媒体源被编码为三个单独的同步广播流，这些流依次在相同的媒体传输流上发送。当使用同步广播时，RTP流可以共享RTP会话和媒体传输，或者在不同的RTP会话和媒体传输上分离，或者是这两种的任意组合。使用单独的媒体传输的一个主要原因是对不同的源RTP流使用不同的服务质量（QoS）。第3.12节讨论了分离相关RTP流的一些注意事项。
+----------------+
| Media Source |
+----------------+
Source Stream |
+----------------------+----------------------+
| | |
V V V
+------------------+ +------------------+ +------------------+
| Media Encoder | | Media Encoder | | Media Encoder |
+------------------+ +------------------+ +------------------+
| Encoded | Encoded | Encoded
| Stream | Stream | Stream
V V V
+------------------+ +------------------+ +------------------+
| Media Packetizer | | Media Packetizer | | Media Packetizer |
+------------------+ +------------------+ +------------------+
| Source | Source | Source
| RTP | RTP | RTP
| Stream | Stream | Stream
+-----------------+ | +-----------------+
| | |
V V V
+-------------------+
| Media Transport |
+-------------------+
+----------------+
| Media Source |
+----------------+
Source Stream |
+----------------------+----------------------+
| | |
V V V
+------------------+ +------------------+ +------------------+
| Media Encoder | | Media Encoder | | Media Encoder |
+------------------+ +------------------+ +------------------+
| Encoded | Encoded | Encoded
| Stream | Stream | Stream
V V V
+------------------+ +------------------+ +------------------+
| Media Packetizer | | Media Packetizer | | Media Packetizer |
+------------------+ +------------------+ +------------------+
| Source | Source | Source
| RTP | RTP | RTP
| Stream | Stream | Stream
+-----------------+ | +-----------------+
| | |
V V V
+-------------------+
| Media Transport |
+-------------------+
Figure 8: Example of Media Source Simulcast
图8：媒体源同步广播示例
The simulcast relation between the RTP streams is the common media source. In addition, to be able to identify the common media source, a receiver of the RTP stream may need to know which configuration or encoding goals lay behind the produced encoded stream and its properties. This enables selection of the stream that is most useful in the application at that moment.
RTP流之间的同播关系是公共媒体源。此外，为了能够识别公共媒体源，RTP流的接收器可能需要知道所产生的编码流及其属性背后的配置或编码目标。这样就可以选择当时在应用程序中最有用的流。
Layered Multi-Stream (LMS) is a mechanism by which different portions of a layered or scalable encoding of a source stream are sent using separate RTP streams (sometimes in separate RTP sessions). LMSs are useful for receiver control of layered media.
分层多流（LMS）是一种机制，通过该机制，源流的分层或可伸缩编码的不同部分使用单独的RTP流（有时在单独的RTP会话中）发送。LMS可用于分层介质的接收器控制。
A media source represented as an encoded stream and multiple dependent streams constitutes a media source that has layered dependencies. Figure 9 represents an example of a media source that is encoded into three dependent layers, where two layers are sent on the same media transport using different RTP streams, i.e., SSRCs, and the third layer is sent on a separate media transport.
表示为编码流和多个从属流的媒体源构成具有分层从属关系的媒体源。图9显示了编码为三个相关层的媒体源示例，其中两个层使用不同的RTP流（即SSRC）在同一媒体传输上发送，第三层在单独的媒体传输上发送。
+----------------+
| Media Source |
+----------------+
|
|
V
+---------------------------------------------------------+
| Media Encoder |
+---------------------------------------------------------+
| | |
Encoded Stream Dependent Stream Dependent Stream
| | |
V V V
+----------------+ +----------------+ +----------------+
|Media Packetizer| |Media Packetizer| |Media Packetizer|
+----------------+ +----------------+ +----------------+
| | |
RTP Stream RTP Stream RTP Stream
| | |
+------+ +------+ |
| | |
V V V
+-----------------+ +-----------------+
| Media Transport | | Media Transport |
+-----------------+ +-----------------+
+----------------+
| Media Source |
+----------------+
|
|
V
+---------------------------------------------------------+
| Media Encoder |
+---------------------------------------------------------+
| | |
Encoded Stream Dependent Stream Dependent Stream
| | |
V V V
+----------------+ +----------------+ +----------------+
|Media Packetizer| |Media Packetizer| |Media Packetizer|
+----------------+ +----------------+ +----------------+
| | |
RTP Stream RTP Stream RTP Stream
| | |
+------+ +------+ |
| | |
V V V
+-----------------+ +-----------------+
| Media Transport | | Media Transport |
+-----------------+ +-----------------+
Figure 9: Example of Media Source Layered Dependency
图9：媒体源分层依赖关系示例
It is sometimes useful to make a distinction between using a single media transport or multiple separate media transports when (in both cases) using multiple RTP streams to carry encoded streams and dependent streams for a media source. Therefore, the following new terminology is defined here:
当（在这两种情况下）使用多个RTP流来承载媒体源的编码流和从属流时，区分使用单个媒体传输还是使用多个单独的媒体传输有时是有用的。因此，此处定义了以下新术语：
SRST: Single RTP stream on a Single media Transport
SRST：单个媒体传输上的单个RTP流
MRST: Multiple RTP streams on a Single media Transport
MRST：单个媒体传输上的多个RTP流
MRMT: Multiple RTP streams on Multiple media Transports
MRMT：多个媒体传输上的多个RTP流
MRST and MRMT relations need to identify the common media encoder origin for the encoded and dependent streams. When using different RTP sessions (MRMT), a single RTP stream per media encoder, and a single media source in each RTP session, common SSRCs and CNAMEs can be used to identify the common media source. When multiple RTP streams are sent from one media encoder in the same RTP session (MRST), then CNAME is the only currently specified RTP identifier that can be used. In cases where multiple media encoders use multiple media sources sharing synchronization context, and thus have a common CNAME, additional heuristics or identification need to be applied to create the MRST or MRMT relationships between the RTP streams.
MRST和MRMT关系需要识别编码流和从属流的公共媒体编码器来源。当使用不同的RTP会话（MRMT）、每个媒体编码器的单个RTP流以及每个RTP会话中的单个媒体源时，可以使用公共SSRC和CNAMEs来识别公共媒体源。当在同一RTP会话（MRST）中从一个媒体编码器发送多个RTP流时，CNAME是当前唯一可以使用的指定RTP标识符。在多个媒体编码器使用共享同步上下文的多个媒体源并因此具有公共CNAME的情况下，需要应用额外的启发式或标识来创建RTP流之间的MRST或MRMT关系。
RTP Stream Duplication [RFC7198], using the same or different media transports, and optionally also delaying the duplicate [RFC7197], offers a simple way to protect media flows from packet loss in some cases (see Figure 10). This is a specific type of redundancy. All but one source RTP stream (Section 2.1.10) are effectively redundancy RTP streams (Section 2.1.12), but since both source and redundant RTP streams are the same, it does not matter which one is which. This can also be seen as a specific type of simulcast (Section 3.6) that transmits the same encoded stream (Section 2.1.7) multiple times.
RTP流复制[RFC7198]，使用相同或不同的媒体传输，并可选地延迟复制[RFC7197]，在某些情况下提供了保护媒体流不丢失数据包的简单方法（见图10）。这是一种特定类型的冗余。除了一个源RTP流（第2.1.10节）外，其他所有源RTP流都是有效的冗余RTP流（第2.1.12节），但由于源RTP流和冗余RTP流都是相同的，所以哪个是哪个并不重要。这也可以看作是一种特定类型的同步广播（第3.6节），多次传输相同的编码流（第2.1.7节）。
+----------------+
| Media Source |
+----------------+
Source Stream |
V
+----------------+
| Media Encoder |
+----------------+
Encoded Stream |
+-----------+-----------+
| |
V V
+------------------+ +------------------+
| Media Packetizer | | Media Packetizer |
+------------------+ +------------------+
Source | RTP Stream Source | RTP Stream
| V
| +-------------+
| | Delay (opt) |
| +-------------+
| |
+-----------+-----------+
|
V
+-------------------+
| Media Transport |
+-------------------+
+----------------+
| Media Source |
+----------------+
Source Stream |
V
+----------------+
| Media Encoder |
+----------------+
Encoded Stream |
+-----------+-----------+
| |
V V
+------------------+ +------------------+
| Media Packetizer | | Media Packetizer |
+------------------+ +------------------+
Source | RTP Stream Source | RTP Stream
| V
| +-------------+
| | Delay (opt) |
| +-------------+
| |
+-----------+-----------+
|
V
+-------------------+
| Media Transport |
+-------------------+
Figure 10: Example of RTP Stream Duplication
图10:RTP流复制示例
"RTP Payload for Redundant Audio Data" [RFC2198] defines a transport for redundant audio data together with primary data in the same RTP payload. The redundant data can be a time-delayed version of the primary or another time-delayed encoded stream using a different media encoder to encode the same media source as the primary, as depicted in Figure 11.
“冗余音频数据的RTP有效负载”[RFC2198]定义了冗余音频数据与同一RTP有效负载中的主数据的传输。冗余数据可以是主数据流的延时版本，也可以是使用不同的媒体编码器对与主数据流相同的媒体源进行编码的另一个延时编码流，如图11所示。
+--------------------+
| Media Source |
+--------------------+
|
Source Stream
|
+------------------------+
| |
V V
+--------------------+ +--------------------+
| Media Encoder | | Media Encoder |
+--------------------+ +--------------------+
| |
| +------------+
Encoded Stream | Time Delay |
| +------------+
| |
| +------------------+
V V
+--------------------+
| Media Packetizer |
+--------------------+
|
V
RTP Stream
+--------------------+
| Media Source |
+--------------------+
|
Source Stream
|
+------------------------+
| |
V V
+--------------------+ +--------------------+
| Media Encoder | | Media Encoder |
+--------------------+ +--------------------+
| |
| +------------+
Encoded Stream | Time Delay |
| +------------+
| |
| +------------------+
V V
+--------------------+
| Media Packetizer |
+--------------------+
|
V
RTP Stream
Figure 11: Concept for Usage of Audio Redundancy with Different Media Encoders
图11：不同媒体编码器使用音频冗余的概念
The redundancy format is thus providing the necessary meta information to correctly relate different parts of the same encoded stream. The case depicted above (Figure 11) relates the received source stream fragments coming out of different media decoders, to be able to combine them together into a less erroneous source stream.
因此，冗余格式提供了必要的元信息，以正确关联同一编码流的不同部分。上面描述的情况（图11）涉及来自不同媒体解码器的接收到的源流片段，以便能够将它们组合在一起形成错误较少的源流。
Figure 12 shows an example where a media source's source RTP stream is protected by a retransmission (RTX) flow [RFC4588]. In this
图12显示了一个示例，其中媒体源的源RTP流受到重传（RTX）流[RFC4588]的保护。在这个
example, the source RTP stream and the redundancy RTP stream share the same media transport.
例如，源RTP流和冗余RTP流共享相同的媒体传输。
+--------------------+
| Media Source |
+--------------------+
|
V
+--------------------+
| Media Encoder |
+--------------------+
| Retransmission
Encoded Stream +--------+ +---- Request
V | V V
+--------------------+ | +--------------------+
| Media Packetizer | | | RTP Retransmission |
+--------------------+ | +--------------------+
| | |
+------------+ Redundancy RTP Stream
Source RTP Stream |
| |
+---------+ +---------+
| |
V V
+-----------------+
| Media Transport |
+-----------------+
+--------------------+
| Media Source |
+--------------------+
|
V
+--------------------+
| Media Encoder |
+--------------------+
| Retransmission
Encoded Stream +--------+ +---- Request
V | V V
+--------------------+ | +--------------------+
| Media Packetizer | | | RTP Retransmission |
+--------------------+ | +--------------------+
| | |
+------------+ Redundancy RTP Stream
Source RTP Stream |
| |
+---------+ +---------+
| |
V V
+-----------------+
| Media Transport |
+-----------------+
Figure 12: Example of Media Source Retransmission Flows
图12：媒体源重传流示例
The RTP retransmission example (Figure 12) illustrates that this mechanism works purely on the source RTP stream. The RTP retransmission transforms buffers from the sent source RTP stream and, upon request, emits a retransmitted packet with an extra payload header as a redundancy RTP stream. The RTP retransmission mechanism [RFC4588] is specified such that there is a one-to-one relation between the source RTP stream and the redundancy RTP stream. Therefore, a redundancy RTP stream needs to be associated with its source RTP stream. This is done based on CNAME selectors and heuristics to match requested packets for a given source RTP stream with the original sequence number in the payload of any new redundancy RTP stream using the RTX payload format. In cases where the redundancy RTP stream is sent in a different RTP session than the source RTP stream, the RTP session relation is signaled by using the SDP media grouping's [RFC5888] Flow Identification (FID identification-tag) semantics.
RTP重传示例（图12）说明了该机制仅在源RTP流上工作。RTP重传转换来自发送的源RTP流的缓冲区，并在请求时发射具有额外有效负载报头的重传分组作为冗余RTP流。指定RTP重传机制[RFC4588]，使得源RTP流和冗余RTP流之间存在一对一的关系。因此，冗余RTP流需要与其源RTP流相关联。这是基于CNAME选择器和启发式来完成的，以将给定源RTP流的请求数据包与使用RTX有效负载格式的任何新冗余RTP流的有效负载中的原始序列号相匹配。在冗余RTP流在不同于源RTP流的RTP会话中发送的情况下，RTP会话关系通过使用SDP媒体分组的[RFC5888]流标识（FID标识标签）语义发出信号。
Figure 13 shows an example where two media sources' source RTP streams are protected by FEC. Source RTP stream A has an RTP-based redundancy transformation in FEC encoder 1. This produces a redundancy RTP stream 1, that is only related to source RTP stream A. The FEC encoder 2, however, takes two source RTP streams (A and B) and produces a redundancy RTP stream 2 that protects them jointly, i.e., redundancy RTP stream 2 relates to two source RTP streams (a FEC group). FEC decoding, when needed due to packet loss or packet corruption at the receiver, requires knowledge about which source RTP streams that the FEC encoding was based on.
图13显示了两个媒体源的源RTP流受FEC保护的示例。源RTP流A在FEC编码器1中具有基于RTP的冗余转换。这产生仅与源RTP流a相关的冗余RTP流1。然而，FEC编码器2获取两个源RTP流（a和B）并产生联合保护它们的冗余RTP流2，即，冗余RTP流2与两个源RTP流（FEC组）相关。当由于接收器处的数据包丢失或数据包损坏而需要FEC解码时，需要了解FEC编码所基于的源RTP流。
In Figure 13, all RTP streams are sent on the same media transport. This is, however, not the only possible choice. Numerous combinations exist for spreading these RTP streams over different media transports to achieve the communication application's goal.
在图13中，所有RTP流都在相同的媒体传输上发送。然而，这不是唯一可能的选择。存在许多组合，用于将这些RTP流传播到不同的媒体传输上，以实现通信应用程序的目标。
+--------------------+ +--------------------+
| Media Source A | | Media Source B |
+--------------------+ +--------------------+
| |
V V
+--------------------+ +--------------------+
| Media Encoder A | | Media Encoder B |
+--------------------+ +--------------------+
| |
Encoded Stream Encoded Stream
V V
+--------------------+ +--------------------+
| Media Packetizer A | | Media Packetizer B |
+--------------------+ +--------------------+
| |
Source RTP Stream A Source RTP Stream B
| |
+-----+---------+-------------+ +---+---+
| V V V |
| +---------------+ +---------------+ |
| | FEC Encoder 1 | | FEC Encoder 2 | |
| +---------------+ +---------------+ |
| Redundancy | Redundancy | |
| RTP Stream 1 | RTP Stream 2 | |
V V V V
+----------------------------------------------------------+
| Media Transport |
+----------------------------------------------------------+
+--------------------+ +--------------------+
| Media Source A | | Media Source B |
+--------------------+ +--------------------+
| |
V V
+--------------------+ +--------------------+
| Media Encoder A | | Media Encoder B |
+--------------------+ +--------------------+
| |
Encoded Stream Encoded Stream
V V
+--------------------+ +--------------------+
| Media Packetizer A | | Media Packetizer B |
+--------------------+ +--------------------+
| |
Source RTP Stream A Source RTP Stream B
| |
+-----+---------+-------------+ +---+---+
| V V V |
| +---------------+ +---------------+ |
| | FEC Encoder 1 | | FEC Encoder 2 | |
| +---------------+ +---------------+ |
| Redundancy | Redundancy | |
| RTP Stream 1 | RTP Stream 2 | |
V V V V
+----------------------------------------------------------+
| Media Transport |
+----------------------------------------------------------+
Figure 13: Example of FEC Redundancy RTP Streams
图13:FEC冗余RTP流的示例
As FEC encoding exists in various forms, the methods for relating FEC redundancy RTP streams with its source information in source RTP streams are many. The XOR-based RTP FEC payload format [RFC5109] is defined in such a way that a redundancy RTP stream has a one-to-one relation with a source RTP stream. In fact, the RFC requires the redundancy RTP stream to use the same SSRC as the source RTP stream. This requires the use of either a separate RTP session or the redundancy RTP payload format [RFC2198]. The underlying relation requirement for this FEC format and a particular redundancy RTP stream is to know the related source RTP stream, including its SSRC.
由于FEC编码以各种形式存在，因此将FEC冗余RTP流与其源RTP流中的源信息相关联的方法很多。基于异或的RTP-FEC有效载荷格式[RFC5109]的定义方式使得冗余RTP流与源RTP流具有一对一的关系。事实上，RFC要求冗余RTP流使用与源RTP流相同的SSRC。这需要使用单独的RTP会话或冗余RTP有效负载格式[RFC2198]。此FEC格式和特定冗余RTP流的基本关系要求是了解相关源RTP流，包括其SSRC。
RTP streams can be separated exclusively based on their SSRCs, at the RTP session level, or at the multimedia session level.
RTP流可以在RTP会话级别或多媒体会话级别上基于其SSRC专门分离。
When the RTP streams that have a relationship are all sent in the same RTP session and are uniquely identified based on their SSRC only, it is termed an "SSRC-only-based separation". Such streams can be related via RTCP CNAME to identify that the streams belong to the same endpoint. SSRC-based approaches [RFC5576], when used, can explicitly relate various such RTP streams.
当具有关系的RTP流都在同一RTP会话中发送并且仅基于其SSRC进行唯一标识时，称为“仅基于SSRC的分离”。这些流可以通过RTCP CNAME进行关联，以确定这些流属于同一端点。基于SSRC的方法[RFC5576]在使用时可以明确地关联各种RTP流。
On the other hand, when RTP streams that are related are sent in the context of different RTP sessions to achieve separation, it is known as "RTP session-based separation". This is commonly used when the different RTP streams are intended for different media transports.
另一方面，当在不同RTP会话的上下文中发送相关的RTP流以实现分离时，它被称为“基于RTP会话的分离”。当不同的RTP流用于不同的媒体传输时，通常使用这种方法。
Several mechanisms that use RTP session-based separation rely on it as a grouping mechanism expressing the relationship. The solutions have been based on using the same SSRC value in the different RTP sessions to implicitly indicate their relation. That way, no explicit RTP level mechanism has been needed; only signaling level relations have been established using semantics from the media-line grouping framework [RFC5888]. Examples of this are RTP retransmission [RFC4588], SVC Multi-Session Transmission [RFC6190], and XOR-based FEC [RFC5109]. RTCP CNAME explicitly relates RTP streams across different RTP sessions, as explained in the previous section. Such a relationship can be used to perform inter-media synchronization.
一些使用基于RTP会话的分离的机制依赖于它作为表示关系的分组机制。这些解决方案基于在不同RTP会话中使用相同的SSRC值来隐式指示它们之间的关系。这样，就不需要显式的RTP级机制；仅使用媒体线路分组框架[RFC5888]中的语义建立了信令级别关系。例如RTP重传[RFC4588]、SVC多会话传输[RFC6190]和基于异或的FEC[RFC5109]。如前一节所述，RTCP CNAME在不同RTP会话之间显式关联RTP流。这种关系可用于执行媒体间同步。
RTP streams that are related and need to be associated can be part of different multimedia sessions, rather than just different RTP sessions within the same multimedia session context. This puts further demand on the scope of the mechanism(s) and its handling of identifiers used for expressing the relationships.
相关且需要关联的RTP流可以是不同多媒体会话的一部分，而不仅仅是同一多媒体会话上下文中的不同RTP会话。这进一步要求机制的范围及其对用于表示关系的标识符的处理。
[TRANSPORT-MULTIPLEX] describes a mechanism that allows several RTP sessions to be carried over a single underlying media transport. The main reasons for doing this are related to the impact of using one or more media transports (using a common network path or potentially having different ones). The fewer media transports used, the less need for NAT/firewall traversal resources and smaller number of flow-based QoS.
[TRANSPORT-Multiplexing]描述了一种机制，该机制允许在单个底层媒体传输上进行多个RTP会话。这样做的主要原因与使用一个或多个媒体传输（使用公共网络路径或可能具有不同的网络路径）的影响有关。使用的媒体传输越少，对NAT/防火墙穿越资源的需求就越少，基于流的QoS的数量也就越少。
However, multiple RTP sessions over one media transport imply that a single media transport 5-tuple is not sufficient to express in which RTP session context a particular RTP stream exists. Complexities in the relationship between media transports and RTP sessions already exist as one RTP session contains multiple media transports, e.g., even a Peer-to-Peer RTP Session with RTP/RTCP Multiplexing requires two media transports, one in each direction. The relationship between media transports and RTP sessions as well as additional levels of identifiers needs to be considered in both signaling design and when defining terminology.
然而，一个媒体传输上的多个RTP会话意味着单个媒体传输5元组不足以表示特定RTP流存在于哪个RTP会话上下文中。媒体传输和RTP会话之间的关系已经存在复杂性，因为一个RTP会话包含多个媒体传输，例如，即使是具有RTP/RTCP多路复用的对等RTP会话也需要两个媒体传输，每个方向一个。在信令设计和定义术语时，需要考虑媒体传输和RTP会话之间的关系以及标识符的附加级别。
This section describes a selected set of terms from some relevant RFCs and Internet-Drafts (at the time of writing), using the concepts from previous sections.
本节介绍了一些相关RFC和互联网草案（撰写本文时）中的一组选定术语，使用了前几节中的概念。
The terms in this subsection are used in the context of CLUE [CLUE-FRAME]. Note that some terms listed in this subsection use the same names as terms defined elsewhere in this document. Unless explicitly stated (as "RTP Taxonomy") and in this subsection, they are to be read as references to the CLUE-specific term within this subsection.
本小节中的术语用于线索[线索框架]的上下文。请注意，本小节中列出的一些术语与本文件其他地方定义的术语使用相同的名称。除非明确说明（作为“RTP分类法”）和本小节，否则应将其理解为本小节中线索特定术语的参考。
Defined in CLUE as a Media Capture (Section 4.1.7) for audio. Describes an audio media source (Section 2.1.4).
在CLUE中定义为音频的媒体捕获（第4.1.7节）。描述音频媒体源（第2.1.4节）。
Defined in CLUE as a device that converts physical input into an electrical signal. Identifies a physical entity performing an RTP Taxonomy media capture (Section 2.1.2) transformation.
在CLUE中定义为将物理输入转换为电信号的装置。标识执行RTP分类媒体捕获（第2.1.2节）转换的物理实体。
Defined in CLUE as a specific Encoding (Section 4.1.6) of a Media Capture (Section 4.1.7). Describes an encoded stream (Section 2.1.7) related to CLUE-specific semantic information.
在CLUE中定义为媒体捕获（第4.1.7节）的特定编码（第4.1.6节）。描述与线索特定语义信息相关的编码流（第2.1.7节）。
Defined in CLUE as a structure representing a spatial region captured by one or more Capture Devices (Section 4.1.2), each capturing media representing a portion of the region. Describes a set of spatially related media sources (Section 2.1.4).
在CLUE中定义为表示由一个或多个捕获设备捕获的空间区域的结构（第4.1.2节），每个捕获媒体表示该区域的一部分。描述一组空间相关的媒体源（第2.1.4节）。
Defined in CLUE as a CLUE-capable device that is the logical point of final termination through receiving, decoding, and rendering and/or initiation through capturing, encoding, and sending of media Streams (Section 4.1.10). CLUE further defines it to consist of one or more physical devices with source and sink media streams, and exactly one participant [RFC4353]. Describes exactly one participant (Section 2.2.3) and one or more RTP Taxonomy endpoints (Section 2.2.1).
在CLUE中定义为具有线索功能的设备，是通过接收、解码、呈现和/或通过捕获、编码和发送媒体流而最终终止的逻辑点（第4.1.10节）。CLUE进一步将其定义为包含一个或多个具有源和汇媒体流的物理设备，以及一个参与者[RFC4353]。仅描述一个参与者（第2.2.3节）和一个或多个RTP分类端点（第2.2.1节）。
Defined in CLUE as a set of parameters representing a way to encode a Media Capture (Section 4.1.7) to become a Capture Encoding (Section 4.1.3). Describes the configuration information needed to perform a media encoder (Section 2.1.6) transformation.
在CLUE中定义为一组参数，表示将媒体捕获（第4.1.7节）编码为捕获编码（第4.1.3节）的方法。描述执行媒体编码器（第2.1.6节）转换所需的配置信息。
Defined in CLUE as a source of media, such as from one or more Capture Devices (Section 4.1.2) or constructed from other media Streams (Section 4.1.10). Describes either an RTP Taxonomy media capture (Section 2.1.2) or a media source (Section 2.1.4), depending on in which context the term is used.
在CLUE中定义为媒体源，例如从一个或多个捕获设备（第4.1.2节）或从其他媒体流构造（第4.1.10节）。描述RTP分类法媒体捕获（第2.1.2节）或媒体源（第2.1.4节），具体取决于使用该术语的上下文。
Defined in CLUE as a CLUE-capable device that intends to receive Capture Encodings (Section 4.1.3). Describes the media receiving part of an RTP Taxonomy endpoint (Section 2.2.1).
在CLUE中定义为能够接收捕获编码的线索设备（第4.1.3节）。描述RTP分类端点的媒体接收部分（第2.2.1节）。
Defined in CLUE as a CLUE-capable device that intends to send Capture Encodings (Section 4.1.3). Describes the media sending part of an RTP Taxonomy endpoint (Section 2.2.1).
在CLUE中定义为能够发送捕获编码的线索设备（第4.1.3节）。描述RTP分类终结点的媒体发送部分（第2.2.1节）。
Defined in CLUE as a Capture Encoding (Section 4.1.3) sent from a Media Provider (Section 4.1.9) to a Media Consumer (Section 4.1.8) via RTP. Describes an RTP stream (Section 2.1.10).
在CLUE中定义为通过RTP从媒体提供商（第4.1.9节）向媒体消费者（第4.1.8节）发送的捕获编码（第4.1.3节）。描述RTP流（第2.1.10节）。
Defined in CLUE as a Media Capture (Section 4.1.7) for video. Describes a video media source (Section 2.1.4).
在CLUE中定义为视频的媒体捕获（第4.1.7节）。描述视频媒体源（第2.1.4节）。
A single Session Description Protocol (SDP) [RFC4566] Media Description (or media block; an "m=" line and all subsequent lines until the next "m=" line or the end of the SDP) describes part of the necessary configuration and identification information needed for a media encoder transformation, as well as the necessary configuration and identification information for the media decoder to be able to correctly interpret a received RTP stream.
单会话描述协议（SDP）[RFC4566]媒体描述（或媒体块；“m=”行和直到下一个“m=”行或SDP结束的所有后续行）描述媒体编码器转换所需的部分必要配置和标识信息，以及媒体解码器能够正确解释接收到的RTP流的必要配置和标识信息。
A media description typically relates to a single media source. This is, for example, an explicit restriction in WebRTC. However, nothing prevents that the same media description (and same RTP session) is reused for multiple media sources [RTP-MULTI-STREAM]. It can thus describe properties of one or more RTP streams, and can also describe properties valid for an entire RTP session (via [RFC5576] mechanisms, for example).
媒体描述通常与单个媒体源相关。例如，这是WebRTC中的一个显式限制。但是，没有什么可以阻止相同的媒体描述（和相同的RTP会话）被多个媒体源重用[RTP-MULTI-STREAM]。因此，它可以描述一个或多个RTP流的属性，也可以描述对整个RTP会话有效的属性（例如，通过[RFC5576]机制）。
RTP [RFC3550] uses media stream, audio stream, video stream, and a stream of (RTP) packets interchangeably, which are all RTP streams.
RTP[RFC3550]可交换地使用媒体流、音频流、视频流和（RTP）包流，它们都是RTP流。
A Multimedia Conference is a communication session (Section 2.2.5) between two or more participants (Section 2.2.3), along with the software they are using to communicate.
多媒体会议是两个或多个参与者（第2.2.3节）之间的通信会话（第2.2.5节），以及他们用于通信的软件。
SDP [RFC4566] defines a multimedia session as a set of multimedia senders and receivers and the data streams flowing from senders to receivers, which would correspond to a set of endpoints and the RTP streams that flow between them. In this document, multimedia session (Section 2.2.4) also assumes those endpoints belong to a set of participants that are engaged in communication via a set of related RTP streams.
SDP[RFC4566]将多媒体会话定义为一组多媒体发送方和接收方以及从发送方流向接收方的数据流，这将对应于一组端点以及在它们之间流动的RTP流。在本文档中，多媒体会话（第2.2.4节）还假设这些端点属于通过一组相关RTP流进行通信的一组参与者。
RTP [RFC3550] defines a multimedia session as a set of concurrent RTP sessions among a common group of participants. For example, a video conference may contain an audio RTP session and a video RTP session. This would correspond to a group of participants (each using one or more endpoints) sharing a set of concurrent RTP sessions. In this document, multimedia session also defines those RTP sessions to have some relation and be part of a communication among the participants.
RTP[RFC3550]将多媒体会话定义为一组公共参与者之间的并发RTP会话。例如，视频会议可以包含音频RTP会话和视频RTP会话。这将对应于共享一组并发RTP会话的一组参与者（每个参与者使用一个或多个端点）。在本文档中，多媒体会话还将这些RTP会话定义为具有某种关系，并且是参与者之间通信的一部分。
This term is commonly used to describe the central node in any type of star topology [RTP-TOPOLOGIES] conference. It describes a device that includes one participant (Section 2.2.3) (usually corresponding to a so-called conference focus) and one or more related endpoints (Section 2.2.1) (sometimes one or more per conference participant).
该术语通常用于描述任何类型的星形拓扑[RTP-Topologys]会议中的中心节点。它描述了包括一个参与者（第2.2.3节）（通常对应于所谓的会议焦点）和一个或多个相关端点（第2.2.1节）（有时每个会议参与者一个或多个）的设备。
One of two transmission modes defined in H.264-based SVC [RFC6190], the other mode being a Single-Session Transmission (SST) (Section 4.14). In Multi-Session Transmission (MST), the SVC media encoder sends encoded streams and dependent streams distributed across two or more RTP streams in one or more RTP sessions. The term "MST" is ambiguous in RFC 6190, especially since the name indicates the use of multiple "sessions", while MST-type packetization is in fact required whenever two or more RTP streams are used for the encoded and dependent streams, regardless if those are sent in one or more RTP sessions. Corresponds either to MRST or MRMT (Section 3.7) stream relations defined in this document. The SVC RTP payload RFC [RFC6190] is not particularly explicit about how the common media encoder (Section 2.1.6) relation between encoded streams (Section 2.1.7) and dependent streams (Section 2.1.8) is to be implemented.
基于H.264的SVC[RFC6190]中定义的两种传输模式之一，另一种模式是单会话传输（SST）（第4.14节）。在多会话传输（MST）中，SVC媒体编码器在一个或多个RTP会话中发送分布在两个或多个RTP流上的编码流和从属流。术语“MST”在RFC 6190中是不明确的，特别是因为该名称表示使用多个“会话”，而事实上，当两个或多个RTP流用于编码流和从属流时，无论这些流是在一个或多个RTP会话中发送的，都需要MST类型的打包。对应于本文件中定义的MRST或MRMT（第3.7节）流关系。SVC RTP有效载荷RFC[RFC6190]没有特别明确说明如何实现编码流（第2.1.7节）和从属流（第2.1.8节）之间的公共媒体编码器（第2.1.6节）关系。
WebRTC specifications use this term to refer to locally available entities performing a media capture (Section 2.1.2) transformation.
WebRTC规范使用此术语来指执行媒体捕获（第2.1.2节）转换的本地可用实体。
A WebRTC RtcMediaStream is a set of media sources (Section 2.1.4) sharing the same synchronization context (Section 3.1).
WebRTC RtcMediaStream是一组共享相同同步上下文（第3.1节）的媒体源（第2.1.4节）。
A WebRTC RtcMediaStreamTrack is a media source (Section 2.1.4).
WebRTC RtcMediaStreamTrack是媒体源（第2.1.4节）。
RTP [RFC3550] uses this term, which can be seen as the RTP protocol part of a media depacketizer (Section 2.1.27).
RTP[RFC3550]使用此术语，可以将其视为媒体解包器的RTP协议部分（第2.1.27节）。
RTP [RFC3550] uses this term, which can be seen as the RTP protocol part of a media packetizer (Section 2.1.9).
RTP[RFC3550]使用这个术语，可以将其视为媒体打包器的RTP协议部分（第2.1.9节）。
Within the context of SDP, a singe "m=" line can map to a single RTP session (Section 2.2.2), or multiple "m=" lines can map to a single RTP session. The latter is enabled via multiplexing schemes such as BUNDLE [SDP-BUNDLE], for example, which allows mapping of multiple "m=" lines to a single RTP session.
在SDP上下文中，单个“m=”行可以映射到单个RTP会话（第2.2.2节），或者多个“m=”行可以映射到单个RTP会话。后者通过多路复用方案启用，例如BUNDLE[SDP-BUNDLE]，它允许将多条“m=”线路映射到单个RTP会话。
One of two transmission modes defined in H.264-based SVC [RFC6190], the other mode being MST (Section 4.7). In SST, the SVC media encoder sends encoded streams (Section 2.1.7) and dependent streams (Section 2.1.8) combined into a single RTP stream (Section 2.1.10) in a single RTP session (Section 2.2.2), using the SVC RTP payload format. The term "SST" is ambiguous in RFC 6190, in that it sometimes refers to the use of a single RTP stream, like in sections relating to packetization, and sometimes appears to refer to use of a single RTP session, like in the context of discussing SDP. Closely corresponds to SRST (Section 3.7) defined in this document.
基于H.264的SVC[RFC6190]中定义的两种传输模式之一，另一种模式为MST（第4.7节）。在SST中，SVC媒体编码器使用SVC RTP有效负载格式在单个RTP会话（第2.2.2节）中发送编码流（第2.1.7节）和相关流（第2.1.8节），并将其组合成单个RTP流（第2.1.10节）。术语“SST”在RFC 6190中是不明确的，因为它有时指单个RTP流的使用，如在与打包相关的章节中，有时似乎指单个RTP会话的使用，如在讨论SDP的上下文中。与本文件中定义的SRST（第3.7节）密切对应。
RTP [RFC3550] defines this as "the source of a stream of RTP packets", which indicates that an SSRC is not only a unique identifier for the encoded stream (Section 2.1.7) carried in those packets but is also effectively used as a term to denote a media packetizer (Section 2.1.9). In [RFC3550], it is stated that "a synchronization source may change its data format, e.g., audio encoding, over time". The related encoded stream data format in an RTP stream (Section 2.1.10) is identified by the RTP payload type. Changing the data format for an encoded stream effectively also changes what media encoder (Section 2.1.6) is used for the encoded stream. No ambiguity is introduced to SSRC as an encoded stream identifier by allowing RTP payload type changes, as long as only a single RTP payload type is valid for any given RTP Timestamp. This is aligned with and further described by Section 5.2 of [RFC3550].
RTP[RFC3550]将其定义为“RTP数据包流的源”，这表示SSRC不仅是这些数据包中携带的编码数据流（第2.1.7节）的唯一标识符，而且还有效地用作表示媒体打包器（第2.1.9节）的术语。[RFC3550]中指出，“同步源可能随时间改变其数据格式，例如音频编码”。RTP流（第2.1.10节）中的相关编码流数据格式由RTP有效负载类型标识。更改编码流的数据格式也会有效地更改用于编码流的媒体编码器（第2.1.6节）。只要单个RTP有效负载类型对任何给定的RTP时间戳有效，就不会通过允许RTP有效负载类型更改而将模糊性引入SSRC作为编码流标识符。这与[RFC3550]第5.2节一致，并由其进一步描述。
The purpose of this document is to make clarifications and reduce the confusion prevalent in RTP taxonomy because of inconsistent usage by multiple technologies and protocols making use of the RTP protocol. It does not introduce any new security considerations beyond those already well documented in the RTP protocol [RFC3550] and each of the many respective specifications of the various protocols making use of it.
本文件的目的是澄清和减少RTP分类法中普遍存在的混淆，因为使用RTP协议的多种技术和协议的使用不一致。除了RTP协议[RFC3550]和使用它的各种协议的许多各自规范中已有的安全注意事项外，它没有引入任何新的安全注意事项。
Having a well-defined common terminology and understanding of the complexities of the RTP architecture will help lead us to better standards, avoiding security problems.
有一个定义良好的通用术语和对RTP体系结构复杂性的理解将有助于我们制定更好的标准，避免安全问题。
[CLUE-FRAME] Duckworth, M., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", Work in Progress, draft-ietf-clue-framework-22, April 2015.
[CLUE-FRAME]Duckworth，M.，Pepperll，A.，和S.Wenger，“远程呈现多流的框架”，正在进行的工作，草稿-ietf-CLUE-FRAME-22，2015年4月。
[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>.
[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>.
[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>.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <http://www.rfc-editor.org/info/rfc4353>.
[RFC4353]Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，DOI 10.17487/RFC4353，2006年2月<http://www.rfc-editor.org/info/rfc4353>.
[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>.
[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>.
[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>.
[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>.
[RFC5404] Westerlund, M. and I. Johansson, "RTP Payload Format for G.719", RFC 5404, DOI 10.17487/RFC5404, January 2009, <http://www.rfc-editor.org/info/rfc5404>.
[RFC5404]Westerlund，M.和I.Johansson，“G.719的RTP有效载荷格式”，RFC 5404，DOI 10.17487/RFC5404，2009年1月<http://www.rfc-editor.org/info/rfc5404>.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, <http://www.rfc-editor.org/info/rfc5481>.
[RFC5481]Morton，A.和B.Claise，“数据包延迟变化适用性声明”，RFC 5481，DOI 10.17487/RFC5481，2009年3月<http://www.rfc-editor.org/info/rfc5481>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <http://www.rfc-editor.org/info/rfc5576>.
[RFC5576]Lennox，J.，Ott，J.，和T.Schierl，“会话描述协议（SDP）中的源特定媒体属性”，RFC 5576，DOI 10.17487/RFC5576，2009年6月<http://www.rfc-editor.org/info/rfc5576>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <http://www.rfc-editor.org/info/rfc5888>.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，DOI 10.17487/RFC5888，2010年6月<http://www.rfc-editor.org/info/rfc5888>.
[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>.
[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>.
[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>.
[RFC7197] Begen, A., Cai, Y., and H. Ou, "Duplication Delay Attribute in the Session Description Protocol", RFC 7197, DOI 10.17487/RFC7197, April 2014, <http://www.rfc-editor.org/info/rfc7197>.
[RFC7197]Begen，A.，Cai，Y.，和H.Ou，“会话描述协议中的复制延迟属性”，RFC 7197，DOI 10.17487/RFC7197，2014年4月<http://www.rfc-editor.org/info/rfc7197>.
[RFC7198] Begen, A. and C. Perkins, "Duplicating RTP Streams", RFC 7198, DOI 10.17487/RFC7198, April 2014, <http://www.rfc-editor.org/info/rfc7198>.
[RFC7198]Begen，A.和C.Perkins，“复制RTP流”，RFC 7198，DOI 10.17487/RFC7198，2014年4月<http://www.rfc-editor.org/info/rfc7198>.
[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>.
[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>.
[RTP-MULTI-STREAM] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session", Work in Progress, draft-ietf-avtcore-rtp-multi-stream-08, July 2015.
[RTP-MULTI-STREAM]Lennox，J.，Westerlund，M.，Wu，W.，和C.Perkins，“在单个RTP会话中发送多个媒体流”，正在进行的工作，草稿-ietf-avtcore-RTP-MULTI-STREAM-082015年7月。
[RTP-TOPOLOGIES] Westerlund, M. and S. Wenger, "RTP Topologies", Work in Progress, draft-ietf-avtcore-rtp-topologies-update-10, July 2015.
[RTP-Topologys]Westerlund，M.和S.Westerlund，S.Westerlund，M.和S.Wenger，“RTP拓扑”，正在进行的工作，草稿-ietf-avtcore-RTP-Topologys-update-102015年7月。
[SDP-BUNDLE] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-23, July 2015.
[SDP-BUNDLE]Holmberg，C.，Alvestrand，H.，和C.Jennings，“使用会话描述协议（SDP）协商媒体多路复用”，正在进行的工作，草稿-ietf-mmusic-SDP-BUNDLE-negotiation-232015年7月。
[SDP-SIMULCAST] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Simulcast in SDP and RTP Sessions", Work in Progress, draft-ietf-mmusic-sdp-simulcast-01, July 2015.
[SDP-SIMULCAST]Burman，B.，Westerlund，M.，Nandakumar，S.，和M.Zanaty，“在SDP和RTP会议中使用同步广播”，正在进行的工作，草案-ietf-mmusic-SDP-SIMULCAST-012015年7月。
[TRANSPORT-MULTIPLEX] Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP Sessions onto a Single Lower-Layer Transport", Work in Progress, draft-westerlund-avtcore-transport-multiplexing-07, October 2013.
[TRANSPORT-Multiplexing]Westerlund，M.和C.Perkins，“将多个RTP会话复用到一个较低层传输上”，正在进行的工作，draft-Westerlund-avtcore-TRANSPORT-Multiplexing-07，2013年10月。
[WEBRTC-OVERVIEW] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-14, June 2015.
[WEBRTC-OVERVIEW]Alvestrand，H.，“概述：基于浏览器的应用程序的实时协议”，正在进行的工作，草稿-ietf-rtcweb-OVERVIEW-14，2015年6月。
Acknowledgements
致谢
This document has many concepts borrowed from several documents such as WebRTC [WEBRTC-OVERVIEW], CLUE [CLUE-FRAME], and Multiplexing Architecture [TRANSPORT-MULTIPLEX]. The authors would like to thank all the authors of each of those documents.
本文档借鉴了WebRTC[WebRTC-OVERVIEW]、CLUE[CLUE-FRAME]和多路复用体系结构[TRANSPORT-MULTIPLEX]等多个文档中的许多概念。作者谨感谢每一份文件的所有作者。
The authors would also like to acknowledge the insights, guidance, and contributions of Magnus Westerlund, Roni Even, Paul Kyzivat, Colin Perkins, Keith Drage, Harald Alvestrand, Alex Eleftheriadis, Mo Zanaty, Stephan Wenger, and Bernard Aboba.
作者还想感谢马格努斯·韦斯特隆德、罗尼·埃文、保罗·基齐瓦特、科林·帕金斯、基思·德拉格、哈拉尔德·阿尔韦斯特朗、亚历克斯·埃列夫瑟里亚迪斯、莫·扎纳蒂、斯蒂芬·温格和伯纳德·阿博巴的见解、指导和贡献。
Contributors
贡献者
Magnus Westerlund has contributed the concept model for the media chain using transformations and streams model, including rewriting pre-existing concepts into this model and adding missing concepts. The first proposal for updating the relationships and the topologies based on this concept was also performed by Magnus.
Magnus Westerlund使用转换和流模型为媒体链提供了概念模型，包括将预先存在的概念重写到此模型中并添加缺失的概念。Magnus还提出了第一个基于此概念更新关系和拓扑的建议。
Authors' Addresses
作者地址
Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 United States
Jonathan Lennox Vidyo，Inc.美国新泽西州哈肯萨克大街433号七楼，邮编：07601
Email: jonathan@vidyo.com
Email: jonathan@vidyo.com
Kevin Gross AVA Networks, LLC Boulder, CO United States
Kevin Gross AVA Networks有限责任公司，美国科罗拉多州博尔德
Email: kevin.gross@avanw.com
Email: kevin.gross@avanw.com
Suhas Nandakumar Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞西塔斯曼大道170号Suhas Nandakumar Cisco Systems，邮编95134
Email: snandaku@cisco.com
Email: snandaku@cisco.com
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
Email: gsalguei@cisco.com
Email: gsalguei@cisco.com
Bo Burman (editor) Ericsson Kistavagen 25 SE-16480 Stockholm Sweden
Bo Burman（编辑）爱立信Kistavagen 25 SE-16480瑞典斯德哥尔摩
Email: bo.burman@ericsson.com
Email: bo.burman@ericsson.com