[要約] RFC 7656は、リアルタイムトランスポートプロトコル（RTP）ソースの意味とメカニズムの分類に関するものです。このRFCの目的は、RTPソースの特性と動作を明確に定義し、RTPベースのアプリケーションの開発とデプロイメントを支援することです。
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.
Real-time Transport Protocol（RTP）ソースに関する用語とそれらの間の関連は、複雑で多少不透明な場合があります。このドキュメントでは、RTPソース間の多数の既存のプロパティと提案されたプロパティ、および関係について説明し、プロトコルエンティティとその関係について説明するための一般的な用語を定義します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
Real-time Transport Protocol（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].
このドキュメントのtElepresence（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使用におけるさまざまな変換とストリームを識別して名前を付けるための概念を定義します。それぞれの概念について、今日共存する代替の定義と使用法が、概念をさらに説明するさまざまな特性とともにリストされています。これらの概念は2つのカテゴリに分類されます。1つはメディアが従うことができるストリームと変換のチェーンに関連し、もう1つは通信に関与するエンティティ用です。
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.
このセクションには、送信者側でメディアを取得し、それを受信者に転送することで一連の物理的刺激を回復する可能性のある概念が含まれています。この一連の概念には、ストリームと変換という2つの主要なタイプがあります。ストリームは、さまざまな表現での物理的刺激のサンプルの時間ベースのシーケンスですが、変換はストリームの表現を何らかの方法で変更します。
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 変換には、0個以上の入力と1つ以上の出力があります。
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 ストリームには、1つのソース変換と1つ以上のシンク変換があります（ソースまたはシンク変換を欠いている可能性がある物理的刺激（セクション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 |
+----------------------+ +----------------------+
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では、送信側と一致する受信側メディアチェーンを確認し、逆変換と、送信側チェーンと同じストリームを復元しようとする試みを調べています。ただし、不可逆圧縮と不完全なメディア転送の可能性があります。 Media DecoderからのSource Streamのような逆変換からのストリームは、多くの場合、送信側の対応するストリームと同じではないことに注意してください。したがって、変更された可能性のあるバージョンを示すために、「受信済み」という接頭辞が付きます。同じではない理由は、不可逆型になる可能性のある変換にあります。たとえば、メディアエンコーダーの不可逆ソースコーディングは、メディアデコーダーからのソースストリームが、メディアエンコーダーに供給されるものと同じになるのを防ぎます。その他の理由としては、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
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）をデジタルメディアに変換するプロセスです。メディアキャプチャは、物理的刺激のデジタルサンプリングを通常は定期的に実行し、これをRaw Streamとして何らかの表現で出力します（セクション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）。この変換は、1つ以上の生ストリーム（セクション2.1.3）を取り、出力としてソースストリームを提供します。出力は、システムローカルウォールクロックのように単純なものでも、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.
出力にはさまざまなタイプがあります。 1つのタイプは、特定のメディアキャプチャのrawストリームに直接関連付けられています。その他は、複数のソースストリームのオーディオミックスなど、より概念的なソースです（図3）。通常、複数のストリームを混合するには、入力ストリームを時間的に関連付けることができる必要があります。つまり、それらは生ストリームではなくソースストリーム（セクション2.1.5）でなければなりません。図3では、生成されたソースストリームは3つの入力ソースストリームの混合です。
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.
概念的なメディアソースのもう1つの可能な例は、ビデオ監視スイッチです。この場合、入力はさまざまなカメラからの複数のソースストリームであり、出力は、ラウンドロビンやビデオアクティビティ測定などの選択基準に基づくソースストリームの1つです。
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に示すように、スケーラブルメディアエンコーダーは1つの入力ソースストリームを受け取り、それを2つの異なるタイプの複数の出力ストリームにエンコードします：独立してデコード可能な少なくとも1つのエンコードストリームと1つ以上の依存ストリーム（セクション2.1.8）。デコードには、少なくとも1つのエンコードされたストリームと0個以上の依存ストリームが必要です。依存ストリームの依存関係は、このドキュメントでセクション3.7でさらに説明するグループ化関係の1つです。
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 relationship is commonly utilized in simulcast [SDP-SIMULCAST] environments.
同じソースストリームから複数のエンコードされたストリームを作成し、エンコードされたストリームがスケーラブルでもMDCの関係でもない場合は、一般にサイマルキャスト[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.
1つ以上のエンコードされたストリーム（セクション2.1.7）に依存する時間同期されたエンコードされたメディアフラグメントのストリームと、デコードが可能な0以上の依存するストリーム。
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.
1つまたは複数のエンコードされたストリーム（セクション2.1.7）または依存ストリーム（セクション2.1.8）を取得し、そのコンテンツを1つまたは複数のパケットシーケンス（通常はRTPパケット）に出力して、ソースRTPストリームを出力する変換（セクション2.1.10） 。この手順には、RTPペイロードとRTPパケットの両方の生成が含まれます。 Media Packetizerは、使用する同期ソース（SSRC）[RFC3550]およびRTPセッション（セクション2.2.2）を選択します。
The media packetizer can combine multiple encoded or dependent streams into one or more RTP Streams:
メディアパケタイザは、複数のエンコードされたストリームまたは依存するストリームを1つ以上の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ストリームを生成するときに複数の入力を使用できます。このような例の1つは、スケーラブルビデオコーディング（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ストリームを生成することもできます。この1つの例は、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ベースの冗長性（セクション2.1.11）が適用されていないRTPを介した転送を対象としています。
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ストリームは1つだけの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 それぞれが独自のSSRCを持ついくつかのRTPストリームは、単一のメディアソースを表す場合があります。
o Several RTP streams, each with their own SSRC, can be carried in a single RTP session.
o それぞれ独自のSSRCを備えた複数のRTPストリームを1つのRTPセッションで伝送できます。
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）の障害を軽減する変換として定義されています。これは、RTPパケット損失により適切に対処するために、最も適切なメディアエンコーダー（セクション2.1.6）がエンコードされたストリーム（セクション2.1.7）のメディアフォーマットに追加する可能性のあるタイプの冗長性を除外することに注意してください。
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）であり、スタンドアロンとして使用するか、1つ以上の受信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ベースのセキュリティトランスフォーメーションは、「The Secure Real-time Transport Protocol（SRTP）」[RFC3711]で指定されているように、認証、整合性保護、機密性などのセキュリティサービスを入力RTPストリームに適用し、セキュアな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および関連するSecure RTCP（SRTCP）では、SRTCPの整合性保護を除き、上記のセキュリティサービスはすべてオプションです（必須）。また、NULL暗号化アルゴリズムを使用できるため、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つの方法を図1に示します。RTPストリームとそれに対応する冗長RTPストリームは、個別のRTPベースのセキュリティトランスフォームによって保護されています。他のケースでは、[RTP-TOPOLOGIES]のセクション3.2.1.3でMedia Translatorが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 |
+----------------------+ +----------------------+
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ベースのセキュリティによって機密性（暗号化）のためにすでに保護されている可能性があるため、2番目のRTPベースのセキュリティで追加の機密性保護を適用する必要はありません。ただし、RTPベースの修復（セクション2.1.25）とその結果として修復されたRTPストリーム（セクション2.1.26）への攻撃と悪影響を回避するには、この2番目の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ベースのセキュリティ（セクション2.1.13）を通じて、1つ以上の機密性、整合性、または認証セキュリティサービスによって保護されるソースまたは冗長RTPストリームです。
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）が1つのRTP送信者（セクション4.12）から1つの特定の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セッションが1つだけ含まれています。
o A single RTP session can span multiple media transports.
o 1つの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
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 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.
メディアトランスポート内の最初の変換（セクション2.1.15）は、メディアトランスポートセンダーです。送信エンドポイント（セクション2.2.1）はRTPストリームを受け取り、このメディアトランスポート用に確立されたトランスポートアソシエーションを使用してネットワークにパケットを送信し、送信RTPストリーム（セクション2.1.17）を作成します。このプロセスでは、RTPストリームをいくつかの方法で変換します。まず、トランスポートアソシエーションに必要なプロトコルヘッダー（IPヘッダーやUDPヘッダーなど）を生成し、IP / UDP / RTPパケットを形成します。さらに、メディアトランスポートセンダーは、パケットがネットワークに送信される方法をキューに入れたり、意図的にペースを調整したり、その他の方法で影響を及ぼしたりする可能性があります。
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ストリームは、宛先のネットワークパスから送出され、ネットワークトランスポートの変換（2.1.18節）を受けるRTPストリームです。
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).
メディアトランスポートレシーバーは、受信プロセスによるトランスポートされたRTPストリーム（セクション2.1.19）のレシーバエンドポイント（セクション2.2.1）変換であり、これにより、受信された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ベースのセキュリティ変換への入力内容に応じて、結果は受信RTPストリーム（セクション2.1.23）または受信冗長RTPストリーム（セクション2.1.24）になりますが、いくつかのRTPベースのセキュリティ変換が適用された場合は、Received Secured RTPストリーム（セクション2.1.21）になります。
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ベースの修復は、0以上の受信RTPストリーム（セクション2.1.23）と1つ以上の受信冗長RTPストリーム（セクション2.1.24）を入力として取り、1つ以上の修復されたRTPストリーム（セクション2.1.26）を生成する変換です。 ）対応する送信済みソースRTPストリーム（セクション2.1.10）にできるだけ近く、たとえばRTPベースの冗長性（セクション2.1.11）で参照される方法など、さまざまなRTPベースの修復方法を使用します。
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.
Media Depacketizerは、1つ以上の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).
Received Encoded Streamは、エンコードされたストリームの受信バージョンです（セクション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.
Media Sinkは、通常は定期的にサンプリングされたメディアデータと関連する同期情報を含むソースストリーム（セクション2.1.5）を受信します。アプリケーションに応じて、このソースストリームは、メディアレンダー（セクション2.1.33）に伝達され、他のメディアシンクからの出力と同期されるrawストリーム（セクション2.1.3）に変換する必要があります。メディアシンクは、メディアソース（セクション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).
受信したRawストリームは、受信したバージョンのRawストリームです（セクション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----+>| | | | |
| | | | | | | | | | | |
| | | +----------+-+----------------------+-+----------+ | | |
| | +------------+ | | +------------+ | |
| +----------------+ +----------------+ |
+------------------------------------------------------------+
Figure 7: Example Point-to-Point Communication Session with Two RTP Sessions
図7：2つの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のエンドポイント間で2つの異なるオーディオおよびビデオ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正規名（CNAME）[RFC3550]は、通信セッションの期間中にグローバルに一意で安定した識別メカニズムを提供しますが（セクション2.2.5を参照）、それらの有効性は同期コンテキスト（セクション3.1）内でのみ適用されます。したがって、1つのエンドポイントで複数の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 エンドポイントは、任意の時点で最大1人の参加者（セクション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経由）を見つけることができます。 RTCP制御チャネルの帯域幅は、RTPセッション内のすべての参加者間で共有されます。
Characteristics:
特徴：
o An RTP session can carry one or more RTP streams.
o RTPセッションは、1つ以上の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 [RFC3550]で定義されているように、RTPセッションは単一のSSRCスペースを共有します。つまり、RTPセッションに参加しているエンドポイントは、他のエンドポイントのいずれかによって送信されたSSRC識別子を見ることができます。エンドポイントは、SSRCとして、またはエンドポイントのネットワーク相互接続トポロジーで定義されているように、RTPおよびRTCPパケットのコントリビューティングソース（CSRC）として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つのメディアトランスポート（セクション2.1.15）を使用します。1つは送信用、もう1つは受信用です。一般に、受信メディアトランスポートは、送信に使用されるメディアトランスポートの逆方向です。 RTPセッションは多くのメディアトランスポートを使用する場合があり、これらはセッションのネットワーク相互接続トポロジを定義します。
o A single media transport always carries a single RTP session.
o 1つのメディアトランスポートは常に1つの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 アプリケーション固有のシグナリングアドレススペース（SIP URIなど）を使用する単一のシグナリングアドレス可能なエンティティ。
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.
マルチメディアセッションは、1つ以上の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 単一のマルチメディアセッションには、1つ以上の同期コンテキストからのメディアを含めることができます（セクション3.1）。その一例は、1つの同期コンテキストに属する通信目的のオーディオとビデオの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).
通信セッションは、1つ以上のマルチメディアセッション（セクション2.2.4）を介して互いに通信する2人以上の参加者（セクション2.2.3）間の関連付けです。
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 通信セッションは、少なくとも1つのマルチメディアセッションを共有する参加者で構成され、RTPセッションごとに複数のRTPストリームを伴う可能性のある1つ以上の並列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）[RFC5905]を使用してフォーマットされた基準クロックのタイムスタンプに基づくRTPセッション間のメディア間同期について説明しています。 [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は、1つ以上の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 =」行（LS識別タグ付き）と呼ばれる「m =」行（セクション4.2）のグループ化メカニズムを定義し、「m =」行が個別のソースにマップされるときに「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）で過負荷になっています。これは一部の用途では機能しますが、他の用途では機能しません。たとえば、エンドポイントに、人間の参加者のオーディオとビデオ、および共有ムービーのオーディオとビデオのメディアソースのセットなど、同期コンテキストが異なる2セットのメディアソースがある場合、CNAMEは適切ではありません。そのエンドポイントの識別。したがって、エンドポイントには複数のCNAMEがある場合があります。 CNAMEまたはメディアソース自体をエンドポイントに関連付けることができます。
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）が一般的に必要です。たとえば、アプリケーションがメディアソースに関連付けられた参加者ID情報を正しく表示できるようにするためです。この関連付けは、メディアソースが明示的または暗黙的に特定のエンドポイントに関連付けられている可能性がある特定のマルチメディアセッションをポイントするシグナリングを通じて処理されます。
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には、RTCレベルで含まれるメディアコンテンツの前のステップの起源に関する情報を運ぶCSRCの概念が含まれています。
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].
コーデックが単一チャネル（モノ）エンコーダーであるにもかかわらず、マルチチャネルオーディオを伝送できるRTPペイロード形式がいくつか存在します。マルチチャネルオーディオは、共通の同期コンテキストを共有する複数のメディアソースとして表示できます。これらはメディアエンコーダーによって個別にエンコードされ、さまざまなエンコードされたストリームは、使用されるコーデックのRTPペイロード形式を使用して、時間同期された方法で単一のソースRTPストリームにパケット化されます。マルチチャネルオーディオをサポートするコーデックの例は、PCMAおよびPCMU [RFC3551]、Adaptive Multi Rate（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は、3つの個別の同時放送ストリームにエンコードされ、同じメディアトランスポートフローで送信されるメディアソースの例を示しています。サイマルキャストを使用する場合、RTPストリームは、RTPセッションとメディアトランスポートを共有している、異なるRTPセッションとメディアトランスポートで分離されている、またはこれら2つの組み合わせである場合があります。個別のメディアトランスポートを使用する1つの主な理由は、さまざまなソースRTPストリームに対してさまざまなサービス品質（QoS）を利用することです。関連するRTPストリームの分離に関する考慮事項については、セクション3.12で説明します。
+----------------+
| 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は、3つの依存レイヤーにエンコードされたメディアソースの例を表しています。2つのレイヤーは、異なるRTPストリーム（SSRC）を使用して同じメディアトランスポートで送信され、3番目のレイヤーは別のメディアトランスポートで送信されます。
+----------------+
| 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: SRST: Single RTP stream on a Single media Transport
エンコードされたストリームとメディアソースの依存ストリームを運ぶために複数のRTPストリームを使用する場合（両方の場合）に、単一のメディアトランスポートを使用するか複数の個別のメディアトランスポートを使用するかを区別すると便利な場合があります。したがって、ここでは次の新しい用語が定義されています。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）、メディアエンコーダーごとに1つのRTPストリーム、および各RTPセッションで1つのメディアソースを使用する場合、共通のSSRCとCNAMEを使用して共通のメディアソースを識別できます。同じRTPセッション（MRST）で1つのメディアエンコーダーから複数の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.
同じまたは異なるメディアトランスポートを使用し、オプションで複製を遅らせる[RFC7197] RTPストリーム複製[RFC7198]は、場合によってはパケット損失からメディアフローを保護する簡単な方法を提供します（図10を参照）。これは、特定のタイプの冗長性です。 1つを除くすべてのソースRTPストリーム（セクション2.1.10）は事実上冗長RTPストリーム（セクション2.1.12）ですが、ソースRTPストリームと冗長RTPストリームは同じであるため、どちらがどちらであるかは問題ではありません。これは、同じエンコードされたストリーム（セクション2.1.7）を複数回送信する特定のタイプの同時放送（セクション3.6）と見なすこともできます。
+----------------+
| 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
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 example, the source RTP stream and the redundancy RTP stream share the same media transport.
図12は、メディアソースのソースRTPストリームが再送信（RTX）フロー[RFC4588]によって保護されている例を示しています。この例では、ソース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 |
+-----------------+
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ストリームの間に1対1の関係があるように指定されています。したがって、冗長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は、2つのメディアソースのソースRTPストリームがFECによって保護されている例を示しています。ソースRTPストリームAは、FECエンコーダ1でRTPベースの冗長変換を備えています。これにより、ソースRTPストリームAにのみ関連する冗長RTPストリーム1が生成されます。ただし、FECエンコーダ2は、2つのソースRTPストリーム（AとB ）そして、それらを一緒に保護する冗長RTPストリーム2を生成します。つまり、冗長RTPストリーム2は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 |
+----------------------------------------------------------+
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ストリームのソース情報と関連付ける方法は多数あります。 XORベースのRTP FECペイロード形式[RFC5109]は、冗長RTPストリームがソースRTPストリームと1対1の関係を持つように定義されています。実際、RFCでは、ソースRTPストリームと同じSSRCを使用するために冗長RTPストリームが必要です。これには、個別のRTPセッションまたは冗長RTPペイロード形式[RFC2198]のいずれかを使用する必要があります。このFEC形式と特定の冗長RTPストリームの基本的な関係要件は、SSRCを含む、関連するソースRTPストリームを知ることです。
RTP streams can be separated exclusively based on their SSRCs, at the RTP session level, or at the multimedia session level.
RTPストリームは、SSRCに基づいて、RTPセッションレベル、またはマルチメディアセッションレベルで排他的に分離できます。
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]、およびXORベースの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-MULTIPLEX]は、複数のRTPセッションを単一の基礎となるメディアトランスポートを介して伝送できるようにするメカニズムを説明しています。これを行う主な理由は、1つ以上のメディアトランスポートを使用することの影響に関連しています（共通のネットワークパスを使用するか、異なるパスを持つ可能性があります）。使用するメディアトランスポートが少ないほど、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.
ただし、1つのメディアトランスポート上の複数のRTPセッションは、特定のRTPストリームがどのRTPセッションコンテキストに存在するかを表現するには、単一のメディアトランスポート5タプルでは不十分であることを意味します。 1つのRTPセッションに複数のメディアトランスポートが含まれているため、メディアトランスポートとRTPセッションの関係には複雑さが既に存在します。たとえば、RTP / RTCP多重化を使用したピアツーピアRTPセッションでも、各方向に1つずつ、2つのメディアトランスポートが必要です。メディアトランスポートと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.
このサブセクションの用語は、CLUE [CLUE-FRAME]のコンテキストで使用されます。このサブセクションにリストされている一部の用語は、このドキュメントの他の場所で定義されている用語と同じ名前を使用しています。 （「RTP分類法」として）明確に述べられていない限り、およびこのサブセクションでは、これらはこのサブセクション内のCLUE固有の用語への参照として読まれます。
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.
メディアキャプチャ（セクション4.1.7）の特定のエンコーディング（セクション4.1.6）としてCLUEで定義されています。 CLUE固有のセマンティック情報に関連するエンコードされたストリーム（セクション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では、1つ以上のキャプチャデバイス（セクション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では、メディアストリームのキャプチャ、エンコード、送信による受信、デコード、レンダリング、および/または開始による最終的な終了の論理ポイントであるCLUE対応デバイスとして定義されています（セクション4.1.10）。 CLUEはさらに、ソースとシンクのメディアストリームを備えた1つ以上の物理デバイス、および1人の参加者[RFC4353]で構成されると定義しています。正確に1人の参加者（セクション2.2.3）および1つ以上の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.
メディアキャプチャー（セクション4.1.7）をエンコードしてキャプチャーエンコーディング（セクション4.1.3）にする方法を表すパラメーターのセットとしてCLUEで定義されています。メディアエンコーダー（セクション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.
1つ以上のキャプチャデバイス（セクション4.1.2）から、または他のメディアストリーム（セクション4.1.10）から構築されたメディアなどのソースとしてCLUEで定義されています。用語がどのコンテキストで使用されているかに応じて、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では、キャプチャエンコーディングを受信する予定の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では、キャプチャエンコーディングを送信する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]。したがって、1つ以上の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.2.3）間の通信セッション（セクション2.2.3）と、それらが通信に使用しているソフトウェアです。
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セッションを共有する参加者のグループ（それぞれが1つ以上のエンドポイントを使用）に対応します。このドキュメントでは、マルチメディアセッションはこれらの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-TOPOLOGIES]会議の中央ノードを表すために使用されます。これは、1人の参加者（セクション2.2.3）（通常はいわゆる会議フォーカスに対応）と1つ以上の関連エンドポイント（セクション2.2.1）（会議参加者ごとに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]で定義されている2つの送信モードの1つ。もう1つのモードは、シングルセッション送信（SST）です（セクション4.14）。マルチセッション伝送（MST）では、SVCメディアエンコーダーは、1つ以上のRTPセッションで2つ以上のRTPストリームに分散されたエンコードされたストリームと依存ストリームを送信します。 「MST」という用語はRFC 6190ではあいまいです。特に、名前が複数の「セッション」の使用を示しているため、エンコードされたストリームと依存するストリームに2つ以上のRTPストリームが使用される場合は常に、MSTタイプのパケット化が実際に必要ですこれらは1つ以上のRTPセッションで送信されます。このドキュメントで定義されている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]で定義されている2つの送信モードの1つで、もう1つのモードはMST（セクション4.7）です。 SSTでは、SVCメディアエンコーダーは、エンコードされたストリーム（セクション2.1.7）と依存ストリーム（セクション2.1.8）を単一のRTPセッション（セクション2.1.10）に結合して、単一のRTPセッション（セクション2.2.2）で送信します。 SVC RTPペイロード形式。 「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ペイロードタイプが1つだけである限り、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.、Pepperell、A。、およびS. Wenger、「Telepresence Multi-Streamsのフレームワーク」、Work in Progress、draft-ietf-clue-framework-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]パーキンス、C。、コウベラス、I。、ホドソン、O。、ハードマン、V。、ハンドラリー、M。、ボロット、J。、ベガ-ガルシア、A。、およびS.フォセ-パリシス、「RTPペイロードfor Redundant Audio Data」、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：A Transport Protocol for Real-Time Applications」、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、「Minimal Controlを使用したオーディオおよびビデオ会議の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]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004、<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。、「Session Initiation Protocol（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：Session Description Protocol」、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]レイ、J。、レオン、D。、宮崎、A。、ヴァルサ、V。、およびR.ハケンバーグ、「RTP Retransmission Payload Format」、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。、編、「Generic Forward Error Correctionの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、「RTP Payload Format for G.719」、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、「Packet Delay Variation Applicability Statement」、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、「Session Description Protocol（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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年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 Payload Format for Scalable Video Coding」、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、編、「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、「Session Description Protocolの複製遅延属性」、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、「Duplicating RTP Streams」、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]ウィリアムズ、A。、グロス、K。、ファンブランデンブルク、R。、およびH.ストキング、「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セッションでの複数のメディアストリームの送信」、作業中、draft-ietf-avtcore-rtp -multi-stream-08、2015年7月。
[RTP-TOPOLOGIES] Westerlund, M. and S. Wenger, "RTP Topologies", Work in Progress, draft-ietf-avtcore-rtp-topologies-update-10, July 2015.
[RTP-TOPOLOGIES] Westerlund、M。、およびS. Wenger、「RTP Topologies」、Work in Progress、draft-ietf-avtcore-rtp-topologies-update-10、2015年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、「Session Description Protocol（SDP）を使用したメディア多重化のネゴシエーション」、進行中の作業、draft-ietf-mmusic-sdp-bundle-negotiation- 2015年7月23日。
[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]バーマン、B。、ウェスタールンド、M。、ナンダクマール、S。、およびM.ザナティー、「SDPおよびRTPセッションでのSimulcastの使用」、作業中、draft-ietf-mmusic-sdp-simulcast-01 、2015年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-MULTIPLEX] Westerlund、M。およびC. Perkins、「Multiplexing Multiple RTP Sessions on a Single Lower-Layer Transport」、Work in Progress、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。、「Overview：Real Time Protocols for Browser-based Applications」、Work in Progress、draft-ietf-rtcweb-overview-14、June 2015。
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]、Multiplexing Architecture [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は、変換とストリームモデルを使用してメディアチェーンのコンセプトモデルに貢献しています。これには、既存のコンセプトをこのモデルに書き換えたり、不足しているコンセプトを追加したりすることも含まれます。この概念に基づいて関係とトポロジーを更新する最初の提案も、マグナスによって実行されました。
Authors' Addresses
著者のアドレス
Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 United States
Jonathan Lennox Vidyo、Inc. 433 Hackensack Avenue Seventh Floor Hackensack、NJ 07601 United States
Email: jonathan@vidyo.com
Kevin Gross AVA Networks, LLC Boulder, CO United States
Kevin Gross AVA Networks、LLCボルダー、COアメリカ合衆国
Email: kevin.gross@avanw.com
Suhas Nandakumar Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States
Suhas Nandakumar Cisco Systems 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
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、NC 27709アメリカ合衆国
Email: gsalguei@cisco.com
Bo Burman (editor) Ericsson Kistavagen 25 SE-16480 Stockholm Sweden
ボー・バーマン（編集）エリクソン・キスタバゲン25 SE-16480ストックホルムスウェーデン
Email: bo.burman@ericsson.com