[要約] RFC 8872は、複数のメディアストリームをサポートするためのRTPの多重化機能のガイドラインです。このRFCの目的は、異なるメディアストリームを効率的に伝送するためのベストプラクティスを提供することです。
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 8872 B. Burman
Category: Informational Ericsson
ISSN: 2070-1721 C. Perkins
University of Glasgow
H. Alvestrand
Google
R. Even
January 2021
Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams
複数のメディアストリームをサポートするためのRTPの多重化機能を使用するためのガイドライン
Abstract
概要
The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams.
リアルタイムトランスポートプロトコル（RTP）は、幅広いアプリケーション、ネットワーク、およびシステムトポロジで使用できる柔軟なプロトコルです。その柔軟性は幅広い適用性になるが、アプリケーション設計プロセスを複雑にすることができる。多くの注意を払った1つの特定のデザイン質問は、RTPで複数のメディアストリームをサポートする方法です。このメモでは、利用可能なオプションと設計のトレードオフを説明し、RTPの多重化機能を使用して複数のメディアストリームをサポートする方法に関するガイドラインを説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8872.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8872で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Definitions
2.1. Terminology
2.2. Focus of This Document
3. RTP Multiplexing Overview
3.1. Reasons for Multiplexing and Grouping RTP Streams
3.2. RTP Multiplexing Points
3.2.1. RTP Session
3.2.2. Synchronization Source (SSRC)
3.2.3. Contributing Source (CSRC)
3.2.4. RTP Payload Type
3.3. Issues Related to RTP Topologies
3.4. Issues Related to RTP and RTCP
3.4.1. The RTP Specification
3.4.2. Multiple SSRCs in a Session
3.4.3. Binding Related Sources
3.4.4. Forward Error Correction
4. Considerations for RTP Multiplexing
4.1. Interworking Considerations
4.1.1. Application Interworking
4.1.2. RTP Translator Interworking
4.1.3. Gateway Interworking
4.1.4. Legacy Considerations for Multiple SSRCs
4.2. Network Considerations
4.2.1. Quality of Service
4.2.2. NAT and Firewall Traversal
4.2.3. Multicast
4.3. Security and Key-Management Considerations
4.3.1. Security Context Scope
4.3.2. Key Management for Multi-party Sessions
4.3.3. Complexity Implications
5. RTP Multiplexing Design Choices
5.1. Multiple Media Types in One Session
5.2. Multiple SSRCs of the Same Media Type
5.3. Multiple Sessions for One Media Type
5.4. Single SSRC per Endpoint
5.5. Summary
6. Guidelines
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Dismissing Payload Type Multiplexing
Appendix B. Signaling Considerations
B.1. Session-Oriented Properties
B.2. SDP Prevents Multiple Media Types
B.3. Signaling RTP Stream Usage
Acknowledgments
Contributors
Authors' Addresses
The Real-time Transport Protocol (RTP) [RFC3550] is a commonly used protocol for real-time media transport. It is a protocol that provides great flexibility and can support a large set of different applications. From the beginning, RTP was designed for multiple participants in a communication session. It supports many topology paradigms and usages, as defined in [RFC7667]. RTP has several multiplexing points designed for different purposes; these points enable support of multiple RTP streams and switching between different encoding or packetization techniques for the media. By using multiple RTP sessions, sets of RTP streams can be structured for efficient processing or identification. Thus, to meet an application's needs, an RTP application designer needs to understand how best to use the RTP session, the RTP stream identifier (synchronization source (SSRC)), and the RTP payload type.
リアルタイムトランスポートプロトコル（RTP）[RFC3550]は、リアルタイムメディアトランスポートに一般的に使用されているプロトコルです。それは大きな柔軟性を提供し、異なるアプリケーションの大きなセットをサポートすることができますプロトコルです。最初から、RTPは通信セッションの複数の参加者用に設計されました。[RFC7667]で定義されているように、多くのトポロジパラダイムと使用法をサポートしています。RTPには、さまざまな目的のために設計されたいくつかの多重化点があります。これらの点は、メディアのための複数のRTPストリームのサポートと、異なる符号化またはパケット化技術を切り替えることを可能にする。複数のRTPセッションを使用することによって、RTPストリームのセットを効率的な処理または識別のために構造化することができる。したがって、アプリケーションのニーズを満たすためには、RTPアプリケーション設計者は、RTPセッション、RTPストリーム識別子（同期ソース（SSRC））、およびRTPペイロードタイプをどのように使用するのが最適であるかを理解する必要があります。
There has been increased interest in more-advanced usage of RTP. For example, multiple RTP streams can be used when a single endpoint has multiple media sources (like multiple cameras or microphones) from which streams of media need to be sent simultaneously. Consequently, questions are raised regarding the most appropriate RTP usage. The limitations in some implementations, RTP/RTCP extensions, and signaling have also been exposed. This document aims to clarify the usefulness of some functionalities in RTP that, hopefully, will result in future implementations that are more complete.
RTPのより高度な使用法に関心が高まっています。たとえば、単一のエンドポイントに複数のメディアソースがある場合（複数のカメラやマイクロフォンなど）が同時に送信される必要がある場合には、複数のRTPストリームを使用できます。その結果、最も適切なRTPの使用法に関して質問が発生します。いくつかの実装、RTP / RTCP拡張、およびシグナリングの制限もまた公開されています。この文書は、RTPにおけるいくつかの機能の有用性を明確にすることを目的としています。
The purpose of this document is to provide clear information about the possibilities of RTP when it comes to multiplexing. The RTP application designer needs to understand the implications arising from a particular usage of the RTP multiplexing points. This document provides some guidelines and recommends against some usages as being unsuitable, in general or for particular purposes.
この文書の目的は、多重化に関してRTPの可能性に関する明確な情報を提供することです。RTPアプリケーションデザイナは、RTP多重点の特定の使用法から発生する影響を理解する必要があります。この文書はいくつかのガイドラインを提供し、一般的に、または特定の目的で、いくつかの用途を推奨します。
This document starts with some definitions and then goes into existing RTP functionalities around multiplexing. Both the desired behavior and the implications of a particular behavior depend on which topologies are used; therefore, this topic requires some consideration. We then discuss some choices regarding multiplexing behavior and the impacts of those choices. Some designs of RTP usage are also discussed. Finally, some guidelines and examples are provided.
このドキュメントはいくつかの定義で始まり、多重化周辺の既存のRTP機能に入ります。所望の動作と特定の行動の影響の両方が、どのトポロジが使用されているかによって異なります。したがって、このトピックでは考慮が必要です。その後、多重化動作とそれらの選択の影響に関するいくつかの選択肢について説明します。RTPの使用状況のデザインも議論されています。最後に、いくつかのガイドラインと例が提供されています。
The definitions in Section 3 of [RFC3550] are referenced normatively.
[RFC3550]のセクション3の定義は正常に参照されます。
The taxonomy defined in [RFC7656] is referenced normatively.
[RFC7656]で定義されている分類法は正常に参照されます。
The following terms and abbreviations are used in this document:
この文書では、次の用語と省略形が使用されています。
Multi-party: Communication that includes multiple endpoints. In this document, "multi-party" will be used to refer to scenarios where more than two endpoints communicate.
マルチパーティ：複数のエンドポイントを含む通信。この文書では、「マルチパーティ」は、2つ以上のエンドポイントが通信するシナリオを参照するために使用されます。
Multiplexing: An operation that takes multiple entities as input, aggregating them onto some common resource while keeping the individual entities addressable such that they can later be fully and unambiguously separated (demultiplexed) again.
多重化：複数のエンティティを入力として、個々のエンティティをアドレス指定している間にそれらをいくつかの一般的なリソースに集約し、それらが後で完全かつ明確に分離され（逆多重化されて）集約する操作。
RTP Receiver: An endpoint or middlebox receiving RTP streams and RTCP messages. It uses at least one SSRC to send RTCP messages. An RTP receiver may also be an RTP sender.
RTP受信機：RTPストリームとRTCPメッセージを受信したエンドポイントまたはミドルボックス。RTCPメッセージを送信するために少なくとも1つのSSRCを使用します。RTP受信者はRTP送信者でもあり得る。
RTP Sender: An endpoint sending one or more RTP streams but also sending RTCP messages.
RTP送信者：1つ以上のRTPストリームを送信するがRTCPメッセージを送信するエンドポイント。
RTP Session Group: One or more RTP sessions that are used together to perform some function. Examples include multiple RTP sessions used to carry different layers of a layered encoding. In an RTP Session Group, CNAMEs are assumed to be valid across all RTP sessions and designate synchronization contexts that can cross RTP sessions; i.e., SSRCs that map to a common CNAME can be assumed to have RTCP Sender Report (SR) timing information derived from a common clock such that they can be synchronized for playout.
RTPセッショングループ：いくつかの関数を実行するために一緒に使用される1つ以上のRTPセッション。例としては、レイヤードエンコードの異なるレイヤーを持ち運ぶために使用される複数のRTPセッションが含まれます。RTPセッショングループでは、CNAMESはすべてのRTPセッションにわたって有効であると見なされ、RTPセッションを渡すことができる同期コンテキストを指定します。すなわち、共通のC名にマッピングするSSRCは、RTCP送信者レポート（SR）が共通のクロックから導出されたタイミング情報をプレイアウトのために同期させることができると仮定することができる。
Signaling: The process of configuring endpoints to participate in one or more RTP sessions.
シグナリング：エンドポイントを1つ以上のRTPセッションに参加させるプロセス。
| Note: The above definitions of "RTP receiver" and "RTP sender" | are consistent with the usage in [RFC3550].
This document is focused on issues that affect RTP. Thus, issues that involve signaling protocols -- such as whether SIP [RFC3261], Jingle [JINGLE], or some other protocol is in use for session configuration; the particular syntaxes used to define RTP session properties; or the constraints imposed by particular choices in the signaling protocols -- are mentioned only as examples in order to describe the RTP issues more precisely.
この文書は、RTPに影響を与える問題に焦点を当てています。したがって、SIP [RFC3261]、Jingle [Jingle]、またはその他のプロトコルがセッション構成に使用されているのかなど、シグナリングプロトコルを含む問題。RTPセッションプロパティを定義するために使用される特定の構文。あるいは、シグナリングプロトコルの特定の選択によって課される制約は、RTPの問題をより正確に説明するために例としてのみ言及されています。
This document assumes that the applications will use RTCP. While there are applications that don't send RTCP, they do not conform to the RTP specification and thus can be regarded as reusing the RTP packet format but not implementing RTP.
このドキュメントでは、アプリケーションがRTCPを使用すると想定しています。RTCPを送信しないアプリケーションがありますが、RTP仕様に準拠しておらず、したがってRTPパケット形式を再利用するがRTPを実装していないと見なすことができます。
There are several reasons why an endpoint might choose to send multiple media streams. In the discussion below, please keep in mind that the reasons for having multiple RTP streams vary and include, but are not limited to, the following:
エンドポイントが複数のメディアストリームを送信することを選択できる理由はいくつかあります。以下の説明では、複数のRTPストリームを持つ理由は、次のものを含むがこれらに限定されないことを留意してください。
* There might be multiple media sources.
* 複数のメディアソースがあるかもしれません。
* Multiple RTP streams might be needed to represent one media source, for example:
* たとえば、1つのメディアソースを表すには、複数のRTPストリームが必要になる場合があります。
- To carry different layers of a scalable encoding of a media source
- メディアソースのスケーラブルエンコーディングの異なるレイヤーを運ぶ
- Alternative encodings during simulcast, using different codecs for the same audio stream
- 同じオーディオストリームのさまざまなコーデックを使用して、Simulcast中の代替エンコーディング
- Alternative formats during simulcast, multiple resolutions of the same video stream
- Simulcastの間の代替フォーマット、同じビデオストリームの複数の解像度
* A retransmission stream might repeat some parts of the content of another RTP stream.
* 再送信ストリームは、他のRTPストリームの内容の一部を繰り返す可能性があります。
* A Forward Error Correction (FEC) stream might provide material that can be used to repair another RTP stream.
* 順方向誤り訂正（FEC）ストリームは、他のRTPストリームを修復するために使用できる材料を提供するかもしれない。
For each of these reasons, it is necessary to decide whether each additional RTP stream is sent within the same RTP session as the other RTP streams or it is necessary to use additional RTP sessions to group the RTP streams. For a combination of reasons, the suitable choice for one situation might not be the suitable choice for another situation. The choice is easiest when multiplexing multiple media sources of the same media type. However, all reasons warrant discussion and clarification regarding how to deal with them. As the discussion below will show, a single solution does not suit all purposes. To utilize RTP well and as efficiently as possible, both are needed. The real issue is knowing when to create multiple RTP sessions versus when to send multiple RTP streams in a single RTP session.
これらの理由のそれぞれについて、追加のRTPストリームが他のRTPストリームと同じRTPセッション内で送信されるか、またはRTPストリームをグループ化するために追加のRTPセッションを使用する必要があるかを決定する必要があります。理由の組み合わせでは、ある状況に適した選択肢が他の状況に適していない可能性があります。同じメディアタイプの複数のメディアソースを多重化するときに選択が最も簡単です。しかし、すべての理由は、それらに対処する方法に関する議論と説明を保証します。以下の説明が示すように、単一の解決策はすべての目的には適していません。RTPをよくそしてできるだけ効率的に利用するためには、両方が必要です。本当の問題は、いつで複数のRTPストリームを単一のRTPセッションで送信するかをいつでも作成するかを知っています。
This section describes the multiplexing points present in RTP that can be used to distinguish RTP streams and groups of RTP streams. Figure 1 outlines the process of demultiplexing incoming RTP streams, starting with one or more sockets representing the reception of one or more transport flows, e.g., based on the UDP destination port. It also demultiplexes RTP/RTCP from any other protocols, such as Session Traversal Utilities for NAT (STUN) [RFC5389] and DTLS-SRTP [RFC5764] on the same transport as described in [RFC7983]. The Processing and Buffering (PB) step in Figure 1 terminates RTP/RTCP and prepares the RTP payload for input to the decoder.
このセクションでは、RTPストリームとRTPストリームのグループを区別するために使用できるRTPに存在する多重化ポイントについて説明します。図1は、1つまたは複数のトランスポートフローの受信を表す1つまたは複数のソケット、例えばUDP宛先ポートに基づく1つまたは複数のソケットから始めて、着信RTPストリームを逆多重化するプロセスを概説している。それはまた[RFC7983]に記載されているのと同じトランスポートで、NAT（STUN）[RFC5389]、DTLS-SRTP [RFC5764]のセッショントラバーサルユーティリティなど、他のプロトコルからRTP / RTCPをデマルチプレックスします。図1の処理とバッファリング（PB）ステップはRTP / RTCPを終端し、デコーダへの入力のためのRTPペイロードを準備します。
| | |
| | | packets
+-- v v v
| +------------+
| | Socket(s) | Transport Protocol Demultiplexing
| +------------+
| || ||
RTP | RTP/ || |+-----> DTLS (SRTP keying, SCTP, etc.)
Session | RTCP || +------> STUN (multiplexed using same port)
+-- ||
+-- ||
| ++(split by SSRC)-++---> Identify SSRC collision
| || || || ||
| (associate with signaling by MID/RID)
| vv vv vv vv
RTP | +--+ +--+ +--+ +--+ Jitter buffer,
Streams | |PB| |PB| |PB| |PB| process RTCP, etc.
| +--+ +--+ +--+ +--+
+-- | | | |
(select decoder based on payload type (PT))
+-- | / | /
| +-----+ | /
| / | |/
Payload | v v v
Formats | +---+ +---+ +---+
| |Dec| |Dec| |Dec| Decoders
| +---+ +---+ +---+
+--
Figure 1: RTP Demultiplexing Process
図1：RTP逆多重化プロセス
An RTP session is the highest semantic layer in RTP and represents an association between a group of communicating endpoints. RTP does not contain a session identifier, yet different RTP sessions must be possible to identify both across a set of different endpoints and from the perspective of a single endpoint.
RTPセッションはRTP内の最上位層であり、通信エンドポイントのグループ間の関連付けを表します。RTPにはセッションIDが含まれていません、それでも異なるRTPセッションは、一連の異なるエンドポイントと単一のエンドポイントの観点から識別できるようになります。
For RTP session separation across endpoints, the set of participants that form an RTP session is defined as those that share a single SSRC space [RFC3550]. That is, if a group of participants are each aware of the SSRC identifiers belonging to the other participants, then those participants are in a single RTP session. A participant can become aware of an SSRC identifier by receiving an RTP packet containing the identifier in the SSRC field or contributing source (CSRC) list, by receiving an RTCP packet listing it in an SSRC field, or through signaling (e.g., the Session Description Protocol (SDP) [RFC4566] "a=ssrc:" attribute [RFC5576]). Thus, the scope of an RTP session is determined by the participants' network interconnection topology, in combination with RTP and RTCP forwarding strategies deployed by the endpoints and any middleboxes, and by the signaling.
エンドポイント間でのRTPセッションの分離の場合、RTPセッションを形成する参加者のセットは、単一のSSRCスペース[RFC3550]を共有するものとして定義されています。つまり、参加者のグループが他の参加者に属するSSRC識別子を認識している場合、それらの参加者は単一のRTPセッションにあります。参加者は、SSRCフィールド内のRTCPパケットを表示するRTCPパケットを受信することによって、またはシグナリングを介して（例えばセッション記述など）を介して、SSRC識別子を受信することによって、SSRC識別子を認識することができる。プロトコル（SDP）[RFC4566] "a = ssrc："属性[RFC5576]）。したがって、RTPセッションの範囲は、エンドポイントとすべてのミドルボックスによってデプロイされたRTPおよびRTCP転送戦略と組み合わせて、参加者のネットワーク相互接続トポロジによって決定されます。
For RTP session separation within a single endpoint, RTP relies on the underlying transport layer and the signaling to identify RTP sessions in a manner that is meaningful to the application. A single endpoint can have one or more transport flows for the same RTP session, and a single RTP session can span multiple transport-layer flows even if all endpoints use a single transport-layer flow per endpoint for that RTP session. The signaling layer might give RTP sessions an explicit identifier, or the identification might be implicit based on the addresses and ports used. Accordingly, a single RTP session can have multiple associated identifiers, explicit and implicit, belonging to different contexts. For example, when running RTP on top of UDP/IP, an endpoint can identify and delimit an RTP session from other RTP sessions by their UDP source and destination IP addresses and their UDP port numbers. A single RTP session can be using multiple IP/UDP flows for receiving and/or sending RTP packets to other endpoints or middleboxes, even if the endpoint does not have multiple IP addresses. Using multiple IP addresses only makes it more likely that multiple IP/UDP flows will be required. Another example is SDP media descriptions (the "m=" line and the subsequent associated lines) that signal the transport flow and RTP session configuration for the endpoint's part of the RTP session. The SDP grouping framework [RFC5888] allows labeling of the media descriptions to be used so that RTP Session Groups can be created. Through the use of "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)" [RFC8843], multiple media descriptions become part of a common RTP session where each media description represents the RTP streams sent or received for a media source.
単一のエンドポイント内のRTPセッションの分離の場合、RTPは、アプリケーションにとって意味のある方法でRTPセッションを識別するための基礎となるトランスポート層とシグナリングに依存しています。単一のエンドポイントは、同じRTPセッションに対して1つ以上のトランスポートフローを持つことができ、すべてのエンドポイントがそのRTPセッションのエンドポイントごとに単一のトランスポート層のフローを使用していても、単一のRTPセッションが複数のトランスポート層のフローにまたがることがあります。シグナリング層はRTPセッションを明示的な識別子に与える可能性があるか、識別は使用されるアドレスとポートに基づいて暗黙的になる可能性があります。したがって、単一のRTPセッションは、さまざまなコンテキストに属する複数の関連識別子、明示的および暗黙的なものを持つことができます。たとえば、UDP / IPの上にRTPを実行するとき、エンドポイントは、UDPソースおよび宛先IPアドレスとそのUDPポート番号によって、他のRTPセッションからRTPセッションを識別して区切ることができます。単一のRTPセッションは、エンドポイントに複数のIPアドレスがない場合でも、他のエンドポイントまたはミドルボックスにRTPパケットを受信および/または送信するための複数のIP / UDPフローを使用することができます。複数のIPアドレスを使用すると、複数のIP / UDPフローが必要になる可能性が高くなります。もう1つの例は、RTPセッションのエンドポイントの部分のトランスポートフローおよびRTPセッション構成をシグナリングするSDPメディアの説明（ "m ="行と後続の関連行）です。 SDP Grouping Framework [RFC5888]では、RTPセッショングループを作成できるように、メディアの説明を使用することができます。 「セッション記述プロトコル（SDP）」[RFC8843]を使用した「メディアマルチプレックスのネゴシエーション」を使用して、複数のメディアの説明は、各メディア記述がメディアソースに対して送信または受信されたRTPストリームを表す一般的なRTPセッションの一部になります。
RTP makes no normative statements about the relationship between different RTP sessions; however, applications that use more than one RTP session need to understand how the different RTP sessions that they create relate to one another.
RTPは、さまざまなRTPセッション間の関係についての規範的ステートメントを作成しません。ただし、複数のRTPセッションを使用するアプリケーションは、作成した異なるRTPセッションが互いに関連する方法を理解する必要があります。
An SSRC identifies a source of an RTP stream, or an RTP receiver when sending RTCP. Every endpoint has at least one SSRC identifier, even if it does not send RTP packets. RTP endpoints that are only RTP receivers still send RTCP and use their SSRC identifiers in the RTCP packets they send. An endpoint can have multiple SSRC identifiers if it sends multiple RTP streams. Endpoints that function as both RTP sender and RTP receiver use the same SSRC(s) in both roles.
SSRCはRTPストリームのソース、またはRTCPを送信するときのRTP受信機を識別します。すべてのエンドポイントには、RTPパケットが送信されなくても、少なくとも1つのSSRC識別子があります。RTP受信側のRTPエンドポイントはRTCPを送信し、それらが送信するRTCPパケットでそれらのSSRC識別子を使用します。エンドポイントは、複数のRTPストリームを送信する場合、複数のSSRC識別子を持つことができます。RTP送信者とRTP受信者の両方として機能するエンドポイントは、両方の役割で同じSSRCを使用します。
The SSRC is a 32-bit identifier. It is present in every RTP and RTCP packet header and in the payload of some RTCP packet types. It can also be present in SDP signaling. Unless presignaled, e.g., using the SDP "a=ssrc:" attribute [RFC5576], the SSRC is chosen at random. It is not dependent on the network address of the endpoint and is intended to be unique within an RTP session. SSRC collisions can occur and are handled as specified in [RFC3550] and [RFC5576], resulting in the SSRC of the colliding RTP streams or receivers changing. An endpoint that changes its network transport address during a session has to choose a new SSRC identifier to avoid being interpreted as a looped source, unless a mechanism providing a virtual transport (such as Interactive Connectivity Establishment (ICE) [RFC8445]) abstracts the changes.
SSRCは32ビット識別子です。それはすべてのRTPおよびRTCPパケットヘッダーおよびいくつかのRTCPパケットタイプのペイロードに存在します。SDPシグナリングにも存在する可能性があります。PROSIGNALEDがない限り、例えばSDP "A = SSRC："属性[RFC5576]を使用すると、SSRCはランダムに選択されます。それはエンドポイントのネットワークアドレスに依存しないため、RTPセッション内で一意であることを目的としています。SSRCの衝突が発生し、[RFC3550]と[RFC5576]で指定されているとおりに処理され、衝突RTPストリームまたは受信機のSSRCが変更されます。セッション中にネットワークトランスポートアドレスを変更するエンドポイントは、仮想トランスポートを提供するメカニズム（Interactive Connectivity Estfacement（ice）[RFC8445]）を抽象化しない限り、ループソースとして解釈されないように新しいSSRC識別子を選択する必要があります。。
SSRC identifiers that belong to the same synchronization context (i.e., that represent RTP streams that can be synchronized using information in RTCP SR packets) use identical CNAME chunks in corresponding RTCP source description (SDES) packets. SDP signaling can also be used to provide explicit SSRC grouping [RFC5576].
同じ同期コンテキストに属するSSRC識別子（すなわち、RTCP SRパケット内の情報を使用して同期させることができるRTPストリームを表す）は、対応するRTCPソース記述（SDES）パケットで同一のCNAMEチャンクを使用します。SDPシグナリングは、明示的なSSRCグループ化[RFC5576]を提供するためにも使用できます。
In some cases, the same SSRC identifier value is used to relate streams in two different RTP sessions, such as in RTP retransmission [RFC4588]. This is to be avoided, since there is no guarantee that SSRC values are unique across RTP sessions. In the case of RTP retransmission [RFC4588], it is recommended to use explicit binding of the source RTP stream and the redundancy stream, e.g., using the RepairedRtpStreamId RTCP SDES item [RFC8852]. The RepairedRtpStreamId is a rather recent mechanism, so one cannot expect older applications to follow this recommendation.
場合によっては、RTP再送[RFC4588]など、2つの異なるRTPセッションでストリームを関連付けるために同じSSRC識別子値が使用されます。SSRC値がRTPセッション間で一意であるという保証がないため、これは避けられます。RTP再送[RFC4588]の場合、SOREDRTPストリームと冗長ストリームの明示的なバインディング、例えばRepaireDrtpStreamID RTCP SDES項目[RFC8852]を使用することをお勧めします。RepaireDrtpStreamIDはむしろ最近のメカニズムであるため、古いアプリケーションがこの推奨事項に従うことを期待できません。
Note that the RTP sequence number and RTP timestamp are scoped by the SSRC and are thus specific per RTP stream.
RTPシーケンス番号とRTPタイムスタンプはSSRCによってスコープされ、したがってRTPストリームごとに固有のものです。
Different types of entities use an SSRC to identify themselves, as follows:
次のように、さまざまな種類のエンティティSSRCを使用してください。
* A real media source uses the SSRC to identify a "physical" media source.
* 実際のメディアソースはSSRCを使用して「物理的な」メディアソースを識別します。
* A conceptual media source uses the SSRC to identify the result of applying some filtering function in a network node -- for example, a filtering function in an RTP mixer that provides the most active speaker based on some criteria, or a mix representing a set of other sources.
* 概念的なメディアソースはSSRCを使用してネットワークノード内でいくつかのフィルタリング機能を適用した結果を識別します。たとえば、いくつかの基準に基づいて最もアクティブなスピーカーを提供するRTPミキサー、または一連のセットを表すミックスなどのフィルタ機能を識別します。他の情報源
* An RTP receiver uses the SSRC to identify itself as the source of its RTCP reports.
* RTP受信者はSSRCを使用してRTCPレポートのソースとして識別します。
An endpoint that generates more than one media type, e.g., a conference participant sending both audio and video, need not (and, indeed, should not) use the same SSRC value across RTP sessions. Using RTCP compound packets containing the CNAME SDES item is the designated method for binding an SSRC to a CNAME, effectively cross-correlating SSRCs within and between RTP sessions as coming from the same endpoint. The main property attributed to SSRCs associated with the same CNAME is that they are from a particular synchronization context and can be synchronized at playback.
オーディオとビデオの両方を送信する会議参加者は、1つ以上のメディアタイプを生成するエンドポイント、RTPセッション間で同じSSRC値を使用する必要はありません。CNAME SDES項目を含むRTCP複合パケットの使用は、SSRCをC名にバインドし、同じエンドポイントからのRTPセッションの間およびRTPセッションの間およびRTPセッションの間のSSRCを効果的に相互に相関させるための指定方法です。同じCNAMEに関連付けられているSSRCに起因する主要なプロパティは、それらが特定の同期コンテキストからのものであり、再生時に同期されます。
An RTP receiver receiving a previously unseen SSRC value will interpret it as a new source. It might in fact be a previously existing source that had to change its SSRC number due to an SSRC conflict. Using the media identification (MID) extension [RFC8843] helps to identify which media source the new SSRC represents, and using the restriction identifier (RID) extension [RFC8851] helps to identify what encoding or redundancy stream it represents, even though the SSRC changed. However, the originator of the previous SSRC ought to have ended the conflicting source by sending an RTCP BYE for it prior to starting to send with the new SSRC, making the new SSRC a new source.
以前に目に見えないSSRC値を受信したRTP受信者は、それを新しいソースとして解釈します。実際、SSRCの競合のためにSSRC番号を変更しなければならなかった以前に既存のソースになる可能性があります。メディア識別（MID）拡張[RFC8843]を使用すると、新しいSSRCがどのメディアソースを表すか、制限識別子（RID）拡張子[RFC8851]を使用するのに役立ちます[RFC8851]は、SSRCが変更されていても、それが表す符号化または冗長ストリームを識別するのに役立ちます。。ただし、以前のSSRCの発信者は、新しいSSRCを送信し始める前にRTCP BYEを送信して、新しいSSRCを新しいソースにすることで、競合するソースを終了する必要があります。
The CSRC is not a separate identifier. Rather, an SSRC identifier is listed as a CSRC in the RTP header of a packet generated by an RTP mixer or video Multipoint Control Unit (MCU) / switch, if the corresponding SSRC was in the header of one of the packets that contributed to the output.
CSRCは別の識別子ではありません。むしろ、SSRC識別子は、対応するSSRCがに寄与されたパケットのうちの1つのヘッダにある場合、RTPミキサまたはビデオマルチポイント制御ユニット（MCU）/スイッチによって生成されたパケットのRTPヘッダ内のCSRCとしてリストされています。出力。
It is not possible, in general, to extract media represented by an individual CSRC, since it is typically the result of a media merge (e.g., mix) operation on the individual media streams corresponding to the CSRC identifiers. The exception is the case where only a single CSRC is indicated, as this represents the forwarding of an RTP stream that might have been modified. The RTP header extension ("A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication" [RFC6465]) expands on the receiver's information about a packet with a CSRC list. Due to these restrictions, a CSRC will not be considered a fully qualified multiplexing point and will be disregarded in the rest of this document.
一般に、個々のCSRCによって表される媒体を抽出することは、典型的にはCSRC識別子に対応する個々のメディアストリームに対するメディアマージ（例えばMIX）動作の結果であるので不可能である。これは、変更された可能性があるRTPストリームの転送を表しているため、単一のCSRCのみが示されている場合です。RTPヘッダー拡張子（ "Mixer-to-Clientオーディオレベル表示用のリアルタイムトランスポートプロトコル（RTP）ヘッダー拡張" "[RFC6465]）は、CSRCリストを使用したパケットに関する受信側の情報を展開します。これらの制限により、CSRCは完全修飾多重点と見なされず、この文書の残りの部分では無視されます。
Each RTP stream utilizes one or more RTP payload formats. An RTP payload format describes how the output of a particular media codec is framed and encoded into RTP packets. The payload format is identified by the payload type (PT) field in the RTP packet header. The combination of SSRC and PT therefore identifies a specific RTP stream in a specific encoding format. The format definition can be taken from [RFC3551] for statically allocated payload types but ought to be explicitly defined in signaling, such as SDP, for both static and dynamic payload types. The term "format" here includes those aspects described by out-of-band signaling means; in SDP, the term "format" includes media type, RTP timestamp sampling rate, codec, codec configuration, payload format configurations, and various robustness mechanisms such as redundant encodings [RFC2198].
各RTPストリームは1つ以上のRTPペイロードフォーマットを利用します。RTPペイロード形式は、特定のメディアコーデックの出力がどのようにフレーム化されてRTPパケットにエンコードされるかを説明します。ペイロード形式は、RTPパケットヘッダーのペイロードタイプ（PT）フィールドによって識別されます。したがって、SSRCとPTの組み合わせは、特定の符号化形式で特定のRTPストリームを識別します。フォーマット定義は、[RFC3551]から[RFC3551]から静的に割り当てられたペイロードタイプの場合は、SDPなどのシグナリングで明示的に定義される必要があります。ここでの「フォーマット」という用語は、帯域外シグナリング手段によって記述された態様を含む。SDPでは、「フォーマット」という用語は、メディアタイプ、RTPタイムスタンプサンプリングレート、コーデック、コーデック構成、ペイロードフォーマット構成、および冗長エンコーディングなどのさまざまな堅牢性メカニズムを含む[RFC2198]。
The RTP payload type is scoped by the sending endpoint within an RTP session. PT has the same meaning across all RTP streams in an RTP session. All SSRCs sent from a single endpoint share the same payload type definitions. The RTP payload type is designed such that only a single payload type is valid at any instant in time in the RTP stream's timestamp timeline, effectively time-multiplexing different payload types if any change occurs. The payload type can change on a per-packet basis for an SSRC -- for example, a speech codec making use of generic comfort noise [RFC3389]. If there is a true need to send multiple payload types for the same SSRC that are valid for the same instant, then redundant encodings [RFC2198] can be used. Several additional constraints, other than those mentioned above, need to be met to enable this usage, one of which is that the combined payload sizes of the different payload types ought not exceed the transport MTU.
RTPペイロードタイプは、RTPセッション内の送信エンドポイントによってスコープされます。PTは、RTPセッション内のすべてのRTPストリームにわたって同じ意味を持ちます。単一のエンドポイントから送信されたすべてのSSRCは、同じペイロードタイプの定義を共有します。RTPペイロードタイプは、RTPストリームのタイムスタンプタイムラインでは、単一のペイロードタイプのみがいつでも有効であるため、変更が発生した場合は異なるペイロードタイプを効果的に時間多重化するように設計されています。ペイロードタイプは、SSRCのパケットごとに変更することができます - 例えば、ジェネリックコンフォートノイズを利用した音声コーデック[RFC3389]。同じ瞬間に有効な同じSSRCに対して複数のペイロードタイプを送信する必要がある場合は、冗長エンコーディング[RFC2198]を使用できます。上記のもの以外のいくつかの追加の制約がこの使用法を可能にするために満たされる必要があり、そのうちの1つは、異なるペイロードタイプの複合ペイロードサイズがトランスポートMTUを超えないことである。
Other aspects of using the RTP payload format are described in "How to Write an RTP Payload Format" [RFC8088].
RTPペイロードフォーマットを使用するその他の態様は、「RTPペイロードフォーマットの書き方」[RFC8088]で説明されています。
The payload type is not a multiplexing point at the RTP layer (see Appendix A for a detailed discussion of why using the payload type as an RTP multiplexing point does not work). The RTP payload type is, however, used to determine how to consume and decode an RTP stream. The RTP payload type number is sometimes used to associate an RTP stream with the signaling, which in general requires that unique RTP payload type numbers be used in each context. Using MID, e.g., when bundling "m=" sections [RFC8843], can replace the payload type as a signaling association, and unique RTP payload types are then no longer required for that purpose.
ペイロードタイプはRTPレイヤの多重化ポイントではありません（PayloadタイプをRTP多重化ポイントとして使用していない理由について詳しく説明するには、付録Aを参照）。ただし、RTP Streamの消費および復号方法を決定するために使用されます。RTPペイロードタイプ番号は、RTPストリームをシグナリングと関連付けるために使用されることがあります。これには、一般に、各コンテキストで一意のRTPペイロードタイプ番号を使用する必要があります。例えば、「M =」のセクション[RFC8843]をバンドルする場合、ペイロードタイプをシグナリングアソシエーションとして置き換えることができ、その目的には一意のRTPペイロードタイプが不要になります。
The impact of how RTP multiplexing is performed will in general vary with how the RTP session participants are interconnected, as described in "RTP Topologies" [RFC7667].
RTP多重化がどのように実行されるかの影響は一般に、 "RTPトポロジ" [RFC7667]で説明されているように、RTPセッションの参加者が相互接続されるかによって異なります。
Even the most basic use case -- "Topo-Point-to-Point" as described in [RFC7667] -- raises a number of considerations, which are discussed in detail in the following sections. They range over such aspects as the following:
[RFC7667]に記載されている「トポポイントツーポイント」でも - 次のセクションで詳しく説明されています。それらは次のような側面を越えて範囲を照らします。
* Does my communication peer support RTP as defined with multiple SSRCs per RTP session?
* 私の通信ピアは、RTPセッションごとに複数のSSRCで定義されているようにRTPをサポートしていますか？
* Do I need network differentiation in the form of QoS (Section 4.2.1)?
* QoSの形式でネットワークの差別化が必要ですか（セクション4.2.1）。
* Can the application more easily process and handle the media streams if they are in different RTP sessions?
* アプリケーションは、異なるRTPセッションにある場合、アプリケーションはメディアストリームを処理して処理できますか？
* Do I need to use additional RTP streams for RTP retransmission or FEC?
* RTP再送やFECに追加のRTPストリームを使用する必要がありますか？
For some point-to-multipoint topologies (e.g., Topo-ASM and Topo-SSM [RFC7667]), multicast is used to interconnect the session participants. Special considerations (documented in Section 4.2.3) are then needed, as multicast is a one-to-many distribution system.
いくつかのポイントツーマルチポイントトポロジ（例えば、TOPO-ASMおよびTOPO-SSM [RFC7667]）の場合、マルチキャストはセッション参加者を相互接続するために使用されます。マルチキャストは1対多の配信システムであるため、その場合、特別な考慮事項（4.2.3節で文書化されています）が必要です。
Sometimes, an RTP communication session can end up in a situation where the communicating peers are not compatible, for various reasons:
時々、さまざまな理由で、通信ピアが互換性がない状況でRTP通信セッションが終了することがあります。
* No common media codec for a media type, thus requiring transcoding.
* メディアタイプのための一般的なメディアコーデックはありません。したがって、トランスコーディングが必要です。
* Different support for multiple RTP streams and RTP sessions.
* 複数のRTPストリームとRTPセッションに対するさまざまなサポート。
* Usage of different media transport protocols (i.e., one peer uses RTP, but the other peer uses a different transport protocol).
* さまざまなメディアトランスポートプロトコルの使用法（すなわち、1つのピアはRTPを使用しますが、もう一方のピアは異なるトランスポートプロトコルを使用します）。
* Usage of different transport protocols, e.g., UDP, the Datagram Congestion Control Protocol (DCCP), or TCP.
* さまざまなトランスポートプロトコル、例えばUDP、データグラム輻輳制御プロトコル（DCCP）、またはTCPの使用法。
* Different security solutions (e.g., IPsec, TLS, DTLS, or the Secure Real-time Transport Protocol (SRTP)) with different keying mechanisms.
* 異なるキーイングメカニズムを有する異なるセキュリティソリューション（例えば、IPSec、TLS、DTL、またはセキュアリアルタイムトランスポートプロトコル（SRTP））。
These compatibility issues can often be resolved by the inclusion of a translator between the two peers -- the Topo-PtP-Translator, as described in [RFC7667]. The translator's main purpose is to make the peers look compatible to each other. There can also be reasons other than compatibility for inserting a translator in the form of a middlebox or gateway -- for example, a need to monitor the RTP streams. Beware that changing the stream transport characteristics in the translator can require a thorough understanding of aspects ranging from congestion control and media-level adaptations to application-layer semantics.
[RFC7667]で説明されているように、2つのピア間のトランスレータを含めることによって、これらの互換性の問題をしばしば解決できます。翻訳者の主な目的は、ピアが互いに互換性のあるものにすることです。翻訳者をミドルボックスまたはゲートウェイの形式で挿入するための互換性以外の理由もあります - たとえば、RTPストリームを監視する必要があります。トランスレータ内のストリーム輸送特性を変更することは、輻輳制御とメディアレベルの適応からアプリケーション層の意味論への範囲の側面の完全な理解を必要とすることに注意してください。
Within the uses enabled by the RTP standard, the point-to-point topology can contain one or more RTP sessions with one or more media sources per session, each having one or more RTP streams per media source.
RTP標準によって有効にされる用途内で、ポイントツーポイントトポロジは、1つまたは複数のメディアソースを持つ1つ以上のRTPセッションを、それぞれメディアソースごとに1つ以上のRTPストリームを持つことができます。
Using multiple RTP streams is a well-supported feature of RTP. However, for most implementers or people writing RTP/RTCP applications or extensions attempting to apply multiple streams, it can be unclear when it is most appropriate to add an additional RTP stream in an existing RTP session and when it is better to use multiple RTP sessions. This section discusses the various considerations that need to be taken into account.
複数のRTPストリームを使用することは、RTPのよくサポートされている機能です。ただし、ほとんどの実装者や複数のストリームを適用しようと試みる範囲では、既存のRTPセッションに追加のRTPストリームを追加し、複数のRTPセッションを使用するのが良い場合に最も適しているほとんどの実装者または人々が不明確です。。このセクションでは、考慮に入れる必要があるさまざまな考慮事項について説明します。
RFC 3550 contains some recommendations and a numbered list (Section 5.2 of [RFC3550]) of five arguments regarding different aspects of RTP multiplexing. Please review Section 5.2 of [RFC3550]. Five important aspects are quoted below.
RFC 3550には、RTP多重化の異なる側面に関する5つの引数の推奨事項と番号付きリスト（[RFC3550]のセクション5.2）が含まれています。[RFC3550]のセクション5.2を確認してください。5つの重要な側面は以下の引用符で囲まれています。
1. | If, say, two audio streams shared the same RTP session and the
| same SSRC value, and one were to change encodings and thus
| acquire a different RTP payload type, there would be no
| general way of identifying which stream had changed encodings.
This argument advocates the use of different SSRCs for each individual RTP stream, as this is fundamental to RTP operation.
この議論は、これがRTP操作の基本的なものであるため、個々のRTPストリームごとに異なるSSRCの使用を推奨します。
2. | An SSRC is defined to identify a single timing and sequence
| number space. Interleaving multiple payload types would
| require different timing spaces if the media clock rates
| differ and would require different sequence number spaces to
| tell which payload type suffered packet loss.
This argument advocates against demultiplexing RTP streams within a session based only on their RTP payload type numbers; it still stands, as can be seen by the extensive list of issues discussed in Appendix A.
この引数は、RTPペイロードタイプ番号のみに基づいて、セッション内のRTPストリームを逆多重化することを推奨します。付録Aで議論されている課題の広範なリストからわかるように、まだ立っています。
3. | The RTCP sender and receiver reports (see Section 6.4) can | only describe one timing and sequence number space per SSRC | and do not carry a payload type field.
3.
This argument is yet another argument against payload type multiplexing.
この引数は、ペイロード型多重化に対するまだ別の議論です。
4. | An RTP mixer would not be able to combine interleaved streams | of incompatible media into one stream.
4.
This argument advocates against multiplexing RTP packets that require different handling into the same session. In most cases, the RTP mixer must embed application logic to handle streams; the separation of streams according to stream type is just another piece of application logic, which might or might not be appropriate for a particular application. One type of application that can mix different media sources blindly is the audio-only telephone bridge, although the ability to do that comes from the well-defined scenario that is aided by the use of a single media type, even though individual streams may use incompatible codec types; most other types of applications need application-specific logic to perform the mix correctly.
この引数は、同じセッションに異なる処理を必要とする多重化RTPパケットを把握します。ほとんどの場合、RTPミキサーはストリームを処理するためにアプリケーションロジックを埋め込む必要があります。ストリームタイプによるストリームの分離は、特定のアプリケーションに適している可能性があるか、適切ではない可能性があります。異なるメディアソースを盲目的に混ぜることができるアプリケーションの1つのタイプのアプリケーションは、単一のメディアタイプの使用によって支持されている明確なシナリオからの能力があるが、個々のストリームが使用することができる互換性のないコーデックタイプ。他のほとんどの種類のアプリケーションは、MIXを正しく実行するためのアプリケーション固有のロジックを必要とします。
5. | Carrying multiple media in one RTP session precludes: the use
| of different network paths or network resource allocations if
| appropriate; reception of a subset of the media if desired,
| for example just audio if video would exceed the available
| bandwidth; and receiver implementations that use separate
| processes for the different media, whereas using separate RTP
| sessions permits either single- or multiple-process
| implementations.
This argument discusses network aspects that are described in Section 4.2. It also goes into aspects of implementation, like split component terminals (see Section 3.10 of [RFC7667]) -- endpoints where different processes or interconnected devices handle different aspects of the whole multimedia session.
この引数は、セクション4.2で説明されているネットワークの側面について説明します。それはまた、分割コンポーネント端末のように、実装の側面に入ります（[RFC7667]のセクション3.10を参照） - さまざまなプロセスまたは相互接続されたデバイスがマルチメディアセッション全体のさまざまな側面を処理するエンドポイントです。
To summarize, RFC 3550's view on multiplexing is to use unique SSRCs for anything that is its own media/packet stream and use different RTP sessions for media streams that don't share a media type. This document supports the first point; it is very valid. The latter needs further discussion, as imposing a single solution on all usages of RTP is inappropriate. "Sending Multiple Types of Media in a Single RTP Session" [RFC8860] updates RFC 3550 to allow multiple media types in an RTP session and provides a detailed analysis of the potential benefits and issues related to having multiple media types in the same RTP session. Thus, [RFC8860] provides a wider scope for an RTP session and considers multiple media types in one RTP session as a possible choice for the RTP application designer.
要約すると、RFC 3550の多重化に関するビューは、独自のMedia / Packet Streamであるものに対して固有のSSRCを使用し、メディアタイプを共有しないメディアストリームに対して異なるRTPセッションを使用することです。この文書は最初の点をサポートしています。とても有効です。RTPのすべての用途に単一の解決策を課すことは不適切であるため、後者はさらなる議論を必要としています。「単一のRTPセッションで複数種類のメディアを送信する」[RFC8860] RFC 3550を更新して、RTPセッションで複数のメディアタイプを許可し、同じRTPセッションに複数のメディアタイプを持つことに関連する潜在的な利点と問題の詳細な分析を提供します。したがって、[RFC8860]はRTPセッションのためのより広いスコープを提供し、RTPアプリケーションデザイナにとって可能な選択肢として1つのRTPセッションで複数のメディアタイプを考慮します。
Using multiple SSRCs at one endpoint in an RTP session requires that some unclear aspects of the RTP specification be resolved. These items could potentially lead to some interoperability issues as well as some potential significant inefficiencies, as further discussed in "Sending Multiple RTP Streams in a Single RTP Session" [RFC8108]. An RTP application designer should consider these issues and the application's possible impact caused by a lack of appropriate RTP handling or optimization in the peer endpoints.
RTPセッションで1つのエンドポイントで複数のSSRCを使用するには、RTP仕様の一部の不明確な側面を解決する必要があります。これらの項目は、「単一のRTPセッションで複数のRTPストリームを送信する」[RFC8108]でさらに説明するように、いくつかの相互運用性の問題およびある程度の潜在的な有効性の問題につながる可能性があります。RTPアプリケーション設計者は、これらの問題と、適切なRTP処理の欠如やピアエンドポイントでの最適化によって引き起こされるアプリケーションの可能な影響を考慮する必要があります。
Using multiple RTP sessions can potentially mitigate application issues caused by multiple SSRCs in an RTP session.
複数のRTPセッションを使用すると、RTPセッション内の複数のSSRCによって引き起こされるアプリケーションの問題が軽減される可能性があります。
A common problem in a number of various RTP extensions has been how to bind related RTP streams together. This issue is common to both using additional SSRCs and multiple RTP sessions.
さまざまなRTP拡張機能の一般的な問題は、関連RTPストリームをまとめてバインドする方法でした。この問題は、追加のSSRCと複数のRTPセッションを使用して両方とも共通です。
The solutions can be divided into a few groups:
解決策はいくつかのグループに分けられます。
* RTP/RTCP based
* RTP / RTCPベース
* Signaling based, e.g., SDP
* シグナリングベース、例えばSDP
* Grouping related RTP sessions
* 関連RTPセッションのグループ化
* Grouping SSRCs within an RTP session
* RTPセッション内のSSRCをグループ化します
Most solutions are explicit, but some implicit methods have also been applied to the problem.
ほとんどの解決策は明示的ですが、いくつかの暗黙の方法も問題に適用されています。
The SDP-based signaling solutions are:
SDPベースのシグナリングソリューションは次のとおりです。
SDP media description grouping: The SDP grouping framework [RFC5888] uses various semantics to group any number of media descriptions. SDP media description grouping has primarily been used to group RTP sessions, but in combination with [RFC8843], it can also group multiple media descriptions within a single RTP session.
SDPメディア説明グループ化：SDP Grouping Framework [RFC5888]は、さまざまなセマンティクスを使用して、任意の数のメディアの説明をグループ化します。SDPメディア説明グループ化は主にRTPセッションをグループ化するために使用されていますが、[RFC8843]と組み合わせて、単一のRTPセッション内で複数のメディアの説明をグループ化することもできます。
SDP media multiplexing: "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)" [RFC8843] uses information taken from both SDP and RTCP to associate RTP streams to SDP media descriptions. This allows both SDP and RTCP to group RTP streams belonging to an SDP media description and group multiple SDP media descriptions into a single RTP session.
SDPメディア多重化：「セッション記述プロトコル（SDP）」[RFC8843]の両方から取得した情報を使用して、RTPストリームをSDPメディアの説明に関連付けるために、SDPとRTCPの両方から取得した情報を使用します。これにより、SDPとRTCPの両方がSDPメディア記述に属するRTPストリームをグループ化し、複数のSDPメディアの説明を単一のRTPセッションにグループ化できます。
SDP SSRC grouping: "Source-Specific Media Attributes in the Session Description Protocol (SDP)" [RFC5576] includes a solution for grouping SSRCs in the same way that the grouping framework groups media descriptions.
SDP SSRCグループ化：「セッション記述プロトコル（SDP）」[RFC5576]の「ソース固有のメディア属性」（RFC5576]グループ化フレームワークがメディアの説明をグループ化するのと同じ方法でSSRCをグループ化するためのソリューションを含みます。
The above grouping constructs support many use cases. Those solutions have shortcomings in cases where the session's dynamic properties are such that it is difficult or a drain on resources to keep the list of related SSRCs up to date.
上記のグループ化構成は多くのユースケースをサポートしています。これらのソリューションは、セッションの動的プロパティが、関連するSSRCSのリストを最新のSSRCSのリストを保持することが困難であるか、またはリソース上のドレインであることがある場合に欠けています。
One RTP/RTCP-based grouping solution is to use the RTCP SDES CNAME to bind related RTP streams to an endpoint or a synchronization context. For applications with a single RTP stream per type (media, source, or redundancy stream), the CNAME is sufficient for that purpose, independent of whether one or more RTP sessions are used. However, some applications choose not to use a CNAME because of perceived complexity or a desire not to implement RTCP and instead use the same SSRC value to bind related RTP streams across multiple RTP sessions. RTP retransmission [RFC4588], when configured to use multiple RTP sessions, and generic FEC [RFC5109] both use the CNAME method to relate the RTP streams, which may work but might have some downsides in RTP sessions with many participating SSRCs. It is not recommended to use identical SSRC values across RTP sessions to relate RTP streams; when an SSRC collision occurs, this will force a change of that SSRC in all RTP sessions and will thus resynchronize all of the streams instead of only the single media stream experiencing the collision.
1つのRTP / RTCPベースのグループ化ソリューションは、RTCP SDES CNAMEを使用して関連RTPストリームをエンドポイントまたは同期コンテキストにバインドすることです。タイプごとに単一のRTPストリーム（メディア、ソース、または冗長ストリーム）を持つアプリケーションの場合、1つ以上のRTPセッションが使用されているかどうかに関係なく、CNAMEはその目的に十分です。ただし、一般的な複雑さやRTCPを実装しないことのためにCNAMEを使用しないことを選択し、代わりに複数のRTPセッションにわたって関連するRTPストリームをバインドするために同じSSRC値を使用してください。 RTP再送[RFC4588]、複数のRTPセッションを使用するように設定され、一般的なFEC [RFC5109]はどちらもCNAMEメソッドを使用してRTPストリームを関連付けることができますが、これは多くの参加SSRCを使用してRTPセッションにいくつかのダウンサイックを持つ可能性があります。 RTPストリームを関連付けるために、RTPセッション間で同じSSRC値を使用することはお勧めできません。 SSRCの衝突が発生すると、これはすべてのRTPセッション内のそのSSRCの変更を強制し、したがって衝突を経験した単一のメディアストリームのみではなくすべてのストリームを再同期します。
Another method for implicitly binding SSRCs is used by RTP retransmission [RFC4588] when using the same RTP session as the source RTP stream for retransmissions. A receiver that is missing a packet issues an RTP retransmission request and then awaits a new SSRC carrying the RTP retransmission payload, where that SSRC is from the same CNAME. This limits a requester to having only one outstanding retransmission request on any new SSRCs per endpoint.
暗黙のうちにSSRCを暗黙的にバインドするためのもう1つの方法は、再送信のためにソースRTPストリームと同じRTPセッションを使用する場合、RTP再送信[RFC4588]によって使用されます。パケットが見つからない受信機はRTP再送要求を発行し、そのSSRCが同じCNAMEからのRTP再送信ペイロードを搬送する新しいSSRCを待機します。これにより、エンドポイントごとに新しいSSRCSに対して、未処理の再送信要求を1つだけ持つことを要求者に制限します。
"RTP Payload Format Restrictions" [RFC8851] provides an RTP/RTCP-based mechanism to unambiguously identify the RTP streams within an RTP session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular payload types. The mapping is done by specifying an "a=rid" value in the SDP offer/answer signaling and having the corresponding RtpStreamId value as an SDES item and an RTP header extension [RFC8852]. The RID solution also includes a solution for binding redundancy RTP streams to their original source RTP streams, given that those streams use RID identifiers. The redundancy stream uses the RepairedRtpStreamId SDES item and RTP header extension to declare the RtpStreamId value of the source stream to create the binding.
「RTPペイロード形式の制限」[RFC8851]は、RTPセッション内のRTPストリームを明確に識別するためのRTP / RTCPベースのメカニズムを提供し、通常のペイロードタイプを提供される形状を超えてCodec-Agnostic Wayに制限します。。マッピングは、SDPオファー/アンサーシグナリングで「A = RID」値を指定し、対応するRTPStreamID値をSDES項目として指定し、RTPヘッダー拡張[RFC8852]を指定することによって行われます。RIDソリューションはまた、それらのストリームがRID識別子を使用することを考えると、それらの元のソースRTPストリームに冗長性RTPストリームをバインドするための解決策を含む。冗長ストリームは、RepaireDrtpStreamID SDES項目とRTPヘッダ拡張子を使用して、ソースストリームのRTPStreamID値を宣言してバインディングを作成します。
Experience has shown that an explicit binding between the RTP streams, agnostic of SSRC values, behaves well. That way, solutions using multiple RTP streams in a single RTP session and in multiple RTP sessions will use the same type of binding.
経験は、RTPストリーム間の明示的なバインディング、SSRC値のAgnosticがよく振る舞うことを示しています。そのようにして、単一のRTPセッションおよび複数のRTPセッションで複数のRTPストリームを使用するソリューションは、同じタイプのバインディングを使用します。
There exist a number of FEC-based schemes designed to mitigate packet loss in the original streams. Most of the FEC schemes protect a single source flow. This protection is achieved by transmitting a certain amount of redundant information that is encoded such that it can repair one or more instances of packet loss over the set of packets the redundant information protects. This sequence of redundant information needs to be transmitted as its own media stream or, in some cases, instead of the original media stream. Thus, many of these schemes create a need for binding related flows, as discussed above. Looking at the history of these schemes, there are schemes using multiple SSRCs and schemes using multiple RTP sessions, and some schemes that support both modes of operation.
元のストリームのパケット損失を軽減するように設計されたいくつかのFECベースのスキームがあります。ほとんどのFEC方式は単一のソースフローを保護します。この保護は、冗長情報が保護するパケットのセットにわたって1つまたは複数のパケット損失のインスタンスを修復できるように符号化されている一定量の冗長情報を送信することによって達成される。このシーケンスの冗長情報は、独自のメディアストリームとして、あるいは場合によっては元のメディアストリームの代わりに送信される必要があります。したがって、これらの方式の多くは、上述のように関連するフローを結合する必要性を生み出す。これらのスキームの履歴を見ると、複数のRTPセッションを使用して複数のSSRCとスキームを使用しています。また、両方の操作モードをサポートするいくつかのスキームがあります。
Using multiple RTP sessions supports the case where some set of receivers might not be able to utilize the FEC information. By placing it in a separate RTP session and if separating RTP sessions at the transport level, FEC can easily be ignored at the transport level, without considering any RTP-layer information.
複数のRTPセッションを使用すると、いくつかの受信機がFEC情報を利用できない場合があります。それを別のRTPセッションに入れることによって、そしてトランスポートレベルでRTPセッションを分離する場合、RTP層情報を考慮せずに、トランスポートレベルでFECを簡単に無視することができます。
In usages involving multicast, sending FEC information in a separate multicast group allows for similar flexibility. This is especially useful when receivers see heterogeneous packet loss rates. A receiver can decide, based on measurement of experienced packet loss rates, whether to join a multicast group with suitable FEC data repair capabilities.
マルチキャストを含む用途では、別のマルチキャストグループにFEC情報を送信すると、同様の柔軟性が可能になります。これは、受信機が異種のパケット損失率を見たときに特に便利です。受信機は、経験豊富なパケット損失率の測定に基づいて、適切なFECデータ修復機能を持つマルチキャストグループに参加するかどうかを決定することができます。
There are several different kinds of interworking, and this section discusses two: interworking directly between different applications and the interworking of applications through an RTP translator. The discussion includes the implications of potentially different RTP multiplexing point choices and limitations that have to be considered when working with some legacy applications.
さまざまな種類のインターワーキングがあります。このセクションでは、異なるアプリケーションとRTPトランスレータを介したアプリケーションのインターワーキングとの間で2つのインターワーキングについて説明します。この議論には、潜在的に異なるRTP多重化点の選択肢の影響といくつかの従来のアプリケーションを扱うときに考慮されなければならない制限が含まれます。
It is not uncommon that applications or services of similar but not identical usage, especially those intended for interactive communication, encounter a situation where one wants to interconnect two or more of these applications.
同一の使用法、特に対話的な通信を目的としたもの、特にこれらのアプリケーションの2つ以上を相互接続したいという状況が発生しているのは、類似のアプリケーションやサービスのアプリケーションやサービス、特に対話的な通信を目的としていることは珍しくありません。
In these cases, one ends up in a situation where one might use a gateway to interconnect applications. This gateway must then either change the multiplexing structure or adhere to the respective limitations in each application.
このような場合、アプリケーションを相互接続するためにゲートウェイを使用する場合がある状況では、どちらかが進行中です。このゲートウェイは、多重化構造を変更するか、各アプリケーションのそれぞれの制限に従う必要があります。
There are two fundamental approaches to building a gateway: using RTP translator interworking (RTP bridging), where the gateway acts as an RTP translator with the two interconnected applications being members of the same RTP session; or using gateway interworking (Section 4.1.3) with RTP termination, where there are independent RTP sessions between each interconnected application and the gateway.
ゲートウェイを構築するための2つの基本的なアプローチがあります。RTPトランスレータインターワーキング（RTPブリッジング）を使用します。ここで、ゲートウェイは、同じRTPセッションのメンバーである2つの相互接続されたアプリケーションがRTPトランスレータとして機能します。またはRTP終端を使用して、RTP終端を使用してGateway Interworking（セクション4.1.3）を使用して、各相互接続されたアプリケーションとゲートウェイの間に独立したRTPセッションがあります。
For interworking to be feasible, any security solution in use needs to be compatible and capable of exchanging keys with either the peer or the gateway under the trust model being used. Secondly, the applications need to use media streams in a way that makes sense in both applications.
インターワーキングを実行できるようにするために、使用中のセキュリティソリューションは、使用されている信頼モデルの下でピアまたはゲートウェイのどちらかでキーを交換することができます。第二に、アプリケーションは両方のアプリケーションで意味があるような方法でメディアストリームを使用する必要があります。
From an RTP perspective, the RTP translator approach could work if all the applications are using the same codecs with the same payload types, have made the same multiplexing choices, and have the same capabilities regarding the number of simultaneous RTP streams combined with the same set of RTP/RTCP extensions being supported. Unfortunately, this might not always be true.
RTPの観点からは、すべてのアプリケーションが同じペイロードタイプと同じコーデックを使用している場合は、RTPトランスレータアプローチが機能でき、同じセットと組み合わされた同時RTPストリームの数に関して同じ機能を持つことができます。サポートされているRTP / RTCP拡張機能の。残念ながら、これは常に真実ではないかもしれません。
When a gateway is implemented via an RTP translator, an important consideration is if the two applications being interconnected need to use the same approach to multiplexing. If one side is using RTP session multiplexing and the other is using SSRC multiplexing with BUNDLE [RFC8843], it may be possible for the RTP translator to map the RTP streams between both sides using some method, e.g., based on the number and order of SDP "m=" lines from each side. There are also challenges related to SSRC collision handling, since, unless SSRC translation is applied on the RTP translator, there may be a collision on the SSRC multiplexing side that the RTP session multiplexing side will not be aware of. Furthermore, if one of the applications is capable of working in several modes (such as being able to use additional RTP streams in one RTP session or multiple RTP sessions at will) and the other one is not, successful interconnection depends on locking the more flexible application into the operating mode where interconnection can be successful, even if none of the participants are using the less flexible application when the RTP sessions are being created.
ゲートウェイがRTPトランスレータを介して実装されている場合、重要な考慮事項は、相互接続されている2つのアプリケーションが同じアプローチを多重化に使用する必要がある場合です。片側がRTPセッション多重化を使用している場合、もう1つはバンドル[RFC8843]でSSRC多重化を使用している場合、RTPトランスレータは、例えば、順序と順序に基づいて、双方の両側のRTPストリームをマッピングすることが可能です。各側からのSDP "M ="線。 SSRC変換がRTPトランスレータに適用されない限り、SSRC衝突処理に関する課題もあるので、RTPセッション多重化側が認識しないことをSSRC多重化側で衝突することができるので、SSRC多重化側で衝突する可能性がある。さらに、アプリケーションの1つがいくつかのモードで作業できる場合（1つのRTPセッションまたはWITHの複数のRTPセッションで追加のRTPストリームを使用できるなど）、もう1つがない場合は、成功した相互接続がより柔軟なロックによって異なります。 RTPセッションが作成されているときに、どの参加者も柔軟なアプリケーションを使用していなくても、相互接続が成功する可能性がある場合のアプリケーション。
When one terminates RTP sessions at the gateway, there are certain tasks that the gateway has to carry out:
ゲートウェイでRTPセッションを終了すると、ゲートウェイが実行しなければならない特定のタスクがあります。
* Generating appropriate RTCP reports for all RTP streams (possibly based on incoming RTCP reports) originating from SSRCs controlled by the gateway.
* ゲートウェイによって制御されているSSRCから発生するすべてのRTPストリームに対して（おそらく受信RTCPレポートに基づく）すべてのRTCPレポートの生成。
* Handling SSRC collision resolution in each application's RTP sessions.
* 各アプリケーションのRTPセッションのSSRC衝突解決の処理。
* Signaling, choosing, and policing appropriate bitrates for each session.
* 各セッションのための適切なビットレートのシグナリング、選択、およびポリシング。
For applications that use any security mechanism, e.g., in the form of SRTP, the gateway needs to be able to decrypt and verify source integrity of the incoming packets and then re-encrypt, integrity protect, and sign the packets as the peer in the other application's security context. This is necessary even if all that's needed is a simple remapping of SSRC numbers. If this is done, the gateway also needs to be a member of the security contexts of both sides and thus a trusted entity.
SRTPの形式では、任意のセキュリティメカニズムを使用するアプリケーションの場合、ゲートウェイは着信パケットのソースの整合性を復号化して検証し、次に再暗号化、整合性保護、およびパケットに署名する必要があります。その他のアプリケーションのセキュリティコンテキスト必要なのは、SSRC番号の単純な再マッピングであってもこれが必要です。これが行われた場合、ゲートウェイはまた、両側のセキュリティコンテキストのメンバーである必要があります。
The gateway might also need to apply transcoding (for incompatible codec types), media-level adaptations that cannot be solved through media negotiation (such as rescaling for incompatible video size requirements), suppression of content that is known not to be handled in the destination application, or the addition or removal of redundancy coding or scalability layers to fit the needs of the destination domain.
ゲートウェイはまた（互換性のないコーデックタイプのための）トランスコーディングを適用する必要があるかもしれません（互換性のないビデオサイズの要件の再スケーリングなど）、目的地で処理されないことが知られているコンテンツの抑制を抑制することができます。宛先ドメインのニーズに合わせて、アプリケーション、または冗長コーディングまたはスケーラビリティ層の追加または削除。
From the above, we can see that the gateway needs to have an intimate knowledge of the application requirements; a gateway is by its nature application specific and not a commodity product.
上記から、ゲートウェイがアプリケーション要件に関する親密な知識を持つ必要があることを確認できます。ゲートウェイはその自然申請特有のものであり、商品製品ではありません。
These gateways might therefore potentially block application evolution by blocking RTP and RTCP extensions that the applications have been extended with but that are unknown to the gateway.
したがって、これらのゲートウェイは、アプリケーションが拡張されているがゲートウェイには不明であるRTPおよびRTCP拡張をブロックすることによってアプリケーションの進化をブロックする可能性があります。
If one uses a security mechanism like SRTP, the gateway and the necessary trust in it by the peers pose an additional risk to communication security. The gateway also incurs additional complexities in the form of the decrypt-encrypt cycles needed for each forwarded packet. SRTP, due to its keying structure, also requires that each RTP session need different master keys, as the use of the same key in two RTP sessions can, for some ciphers, result in a reuse of a one-time pad that completely breaks the confidentiality of the packets.
SRTPのようなセキュリティメカニズムを使用する場合、ゲートウェイとピアによって必要な信頼は、通信セキュリティにさらなるリスクをもたらします。ゲートウェイはまた、転送された各パケットに必要な復号化暗号化サイクルの形で追加の複雑さを招く。SRTPは、そのキーイン構造のために、2つのRTPセッションで同じキーを使用することができるように、各RTPセッションが異なるマスターキーを必要とする必要があります。パケットの機密性
Historically, the most common RTP use cases have been point-to-point Voice over IP (VoIP) or streaming applications, commonly with no more than one media source per endpoint and media type (typically audio or video). Even in conferencing applications, especially voice-only, the conference focus or bridge provides to each participant a single stream containing a mix of the other participants. It is also common to have individual RTP sessions between each endpoint and the RTP mixer, meaning that the mixer functions as an RTP-terminating gateway.
歴史的に、最も一般的なRTPユースケースは、エンドポイントおよびメディアタイプごとに1つのメディアソース（通常はオーディオまたはビデオ）に1つのメディアソースを使用しないで、ポイントツーポイントボイスオーバーIP（VoIP）またはストリーミングアプリケーションです。会議アプリケーション、特に音声専用であっても、会議の焦点または橋は各参加者に他の参加者の組み合わせを含む単一のストリームを提供します。また、各エンドポイントとRTPミキサーの間に個々のRTPセッションを持つことも一般的です。つまり、ミキサーはRTPターミネートゲートウェイとして機能します。
Applications and systems that aren't updated to handle multiple streams following these recommendations can have issues with participating in RTP sessions containing multiple SSRCs within a single session, such as:
これらの推奨事項に従って複数のストリームを処理するために更新されていないアプリケーションとシステムは、次のような複数のセッション内の複数のSSRCを含むRTPセッションに参加する問題を持つことができます。
1. The need to handle more than one stream simultaneously rather than replacing an already-existing stream with a new one.
1. 既存のストリームを新しいものと置き換えるのではなく、複数のストリームを同時に処理する必要があります。
2. Being capable of decoding multiple streams simultaneously.
2. 複数のストリームを同時に復号することができる。
3. Being capable of rendering multiple streams simultaneously.
3. 複数のストリームを同時にレンダリングすることができる。
This indicates that gateways attempting to interconnect to this class of devices have to make sure that only one RTP stream of each media type gets delivered to the endpoint if it's expecting only one and that the multiplexing format is what the device expects. It is highly unlikely that RTP translator-based interworking can be made to function successfully in such a context.
これは、ゲートウェイがこのクラスのデバイスに相互接続しようとすると、各メディアタイプのRTPストリームが1つだけであると予想されている場合にはエンドポイントに配信されることを確認し、多重化フォーマットがデバイスが期待するものであることを確認します。そのようなコンテキストでRTPトランスレータベースのインターワーキングを正常に機能させることができることは非常に低いです。
The RTP implementer needs to consider that the RTP multiplexing choice also impacts network-level mechanisms.
RTP実装者は、RTP多重化選択もネットワークレベルのメカニズムに影響を与えると考える必要があります。
QoS mechanisms are either flow based or packet marking based. RSVP [RFC2205] is an example of a flow-based mechanism, while Diffserv [RFC2474] is an example of a packet-marking-based mechanism.
QoSメカニズムは、フローベースまたはパケットマーキングベースのどちらかです。RSVP [RFC2205]はフローベースのメカニズムの一例であり、DIFFSERV [RFC2474]はパケットマーキングベースのメカニズムの一例です。
For a flow-based scheme, additional SSRCs will receive the same QoS as all other RTP streams being part of the same 5-tuple (protocol, source address, destination address, source port, destination port), which is the most common selector for flow-based QoS.
フローベースの方式では、追加のSSRCは、同じ5タプル（プロトコル、送信元アドレス、宛先アドレス、送信先ポート、宛先ポート）の一部であると同じQoSを受信します。これは、最も一般的なセレクタです。フローベースのQoS
For a packet-marking-based scheme, the method of multiplexing will not affect the possibility of using QoS. Different Differentiated Services Code Points (DSCPs) can be assigned to different packets within a transport flow (5-tuple) as well as within an RTP stream, assuming the usage of UDP or other transport protocols that do not have issues with packet reordering within the transport flow (5-tuple). To avoid packet-reordering issues, packets belonging to the same RTP flow should limit their use of DSCPs to packets whose corresponding Per-Hop Behavior (PHB) do not enable reordering. If the transport protocol being used assumes in-order delivery of packets (e.g., TCP and the Stream Control Transmission Protocol (SCTP)), then a single DSCP should be used. For more discussion on this topic, see [RFC7657].
パケットマーキングベースの方式では、多重化方法はQoSを使用する可能性に影響を与えません。異なる微分サービスコードポイント（DSCP）は、UDPまたはRTPストリーム内の異なるパケットに割り当てることができます。輸送フロー（5タプル）パケットの並べ替えの問題を回避するために、同じRTPフローに属するパケットは、対応するホップごとの動作（PHB）が並べ替えを有効にしないパケットへのDSCPの使用を制限する必要があります。使用されているトランスポートプロトコルがパケットの順序配信（例えば、TCPおよびストリーム制御伝送プロトコル（SCTP））を想定している場合、単一のDSCPを使用する必要があります。このトピックに関する詳細については、[RFC7657]を参照してください。
The method for assigning marking to packets can impact what number of RTP sessions to choose. If this marking is done using a network ingress function, it can have issues discriminating the different RTP streams. The network API on the endpoint also needs to be capable of setting the marking on a per-packet basis to reach full functionality.
パケットにマーキングを割り当てる方法は、どの数のRTPセッションを選択するかに影響を与える可能性があります。このマーキングがネットワーク入力機能を使用して行われている場合は、さまざまなRTPストリームを差別するという問題がある可能性があります。エンドポイントのネットワークAPIは、パケットごとにマーキングを設定して全機能に到達することもできなければなりません。
In today's networks, there exist a large number of middleboxes. Those that normally have the most impact on RTP are Network Address Translators (NATs) and Firewalls (FWs).
今日のネットワークでは、多数のミドルボックスがあります。通常、RTPに最も影響を与えるものは、ネットワークアドレストランスレータ（NAT）とファイアウォール（FWS）です。
Below, we analyze and comment on the impact of requiring more underlying transport flows in the presence of NATs and FWs:
以下では、NATSやFWSの存在下でより根本的な輸送フローを必要とする影響について分析してコメントします。
Endpoint Port Consumption: A given IP address only has 65536 available local ports per transport protocol for all consumers of ports that exist on the machine. This is normally never an issue for an end-user machine. It can become an issue for servers that handle a large number of simultaneous streams. However, if the application uses ICE to authenticate STUN requests, a server can serve multiple endpoints from the same local port and use the whole 5-tuple (source and destination address, source and destination port, protocol) as the identifier of flows after having securely bound them to the remote endpoint address using the STUN request. In theory, the minimum number of media server ports needed is the maximum number of simultaneous RTP sessions a single endpoint can use. In practice, implementations will probably benefit from using more server ports to simplify implementation or avoid performance bottlenecks.
エンドポイントポートの消費量：特定のIPアドレスには、マシン上に存在するポートのすべてのコンシューマに対して、トランスポートプロトコルあたり65536のローカルポートのみがあります。これは通常、エンドユーザーマシンにとって問題はありません。多数の同時ストリームを処理するサーバーの問題になる可能性があります。ただし、アプリケーションがSTUNリクエストを認証するためにICEを使用している場合、サーバーは同じローカルポートから複数のエンドポイントを提供し、5タプル全体（送信元と宛先アドレス、送信元ポート、および宛先ポート、プロトコル）を使用した後のフローの識別子として使用できます。STUN要求を使用してそれらをリモートエンドポイントアドレスにしっかりとバインドします。理論的には、必要なメディアサーバーポートの最小数は、単一のエンドポイントが使用できる同時RTPセッションの最大数です。実際には、実装はおそらく、より多くのサーバーポートを使用して実装を簡素化したり、パフォーマンスのボトルネックを回避するのを促します。
NAT State: If an endpoint sits behind a NAT, each flow it generates to an external address will result in a state that has to be kept in the NAT. That state is a limited resource. In home or Small Office/Home Office (SOHO) NATs, the most limited resource is memory or processing. For large-scale NATs serving many internal endpoints, available external ports are likely the scarce resource. Port limitations are primarily a problem for larger centralized NATs where endpoint-independent mapping requires each flow to use one port for the external IP address. This affects the maximum number of internal users per external IP address. However, as a comparison, a real-time video conference session with audio and video likely uses less than 10 UDP flows, compared to certain web applications that can use 100+ TCP flows to various servers from a single browser instance.
NAT状態：エンドポイントがNATの背後にある場合、外部アドレスに生成される各フローはNATに保持されなければならない状態になります。その状態は限られたリソースです。ホームまたはスモールオフィス/ホームオフィス（SOHO）NATSでは、最も限られたリソースはメモリまたは処理です。多くの内部エンドポイントを提供する大規模なNATの場合、利用可能な外部ポートは乏しいリソースがあります。ポートの制限は、主に、エンドポイントに依存しないマッピングが各フローが外部IPアドレスに1つのポートを使用する必要がある大きな集中型NATにとって問題です。これは、外部IPアドレスごとの内部ユーザーの最大数に影響します。ただし、比較として、オーディオとビデオを使用したリアルタイムのビデオ会議セッションは、100 TCPフローを使用することができる特定のWebアプリケーションと比較して、1つのブラウザインスタンスからさまざまなサーバーに使用できる可能性があります。
Extra Delay Added by NAT Traversal: Performing the NAT/FW traversal takes a certain amount of time for each flow. The best-case scenario for additional NAT/FW traversal time after finding the first valid candidate pair following the specified ICE procedures is 1.5*RTT + Ta*(Additional_Flows-1), where Ta is the pacing timer. That assumes a message in one direction, immediately followed by a return message in the opposite direction to confirm reachability. It isn't more, because ICE first finds one candidate pair that works, prior to attempting to establish multiple flows. Thus, there is no extra time until one has found a working candidate pair. Based on that working pair, the extra time is needed to establish the additional flows (two or three, in most cases) in parallel. However, packet loss causes extra delays of at least 500 ms (the minimal retransmission timer for ICE).
NATトラバーサルによる追加の遅延：NAT / FWトラバーサルを実行すると、各フローに対して一定時間がかかります。指定されたICEプロシージャーに続いて最初の有効な候補ペアを見つけた後の追加のNAT / FWトラバース時間のための最良のシナリオは1.5 * RTT TA *（additional_flows-1）です。ここで、Taはペーシングタイマーです。これは、一方向にメッセージを想定し、直後に戻りメッセージが到達可能性を確認するために反対方向に戻るメッセージを想定しています。ICEは最初に機能する候補ペアを1つ見つけたため、複数のフローを確立しようとする前に1つの候補ペアが見つかりました。したがって、作業候補ペアが見つかるまで追加の時間はありません。その作業対に基づいて、追加の流れ（ほとんどの場合、2つまたは3つ）を並列に確立するために余分な時間が必要です。しかしながら、パケット損失は少なくとも500ms（氷のための最小再送タイマー）の余分な遅延を引き起こす。
NAT Traversal Failure Rate: Due to the need to establish more than a single flow through the NAT, there is some risk that establishing the first flow will succeed but one or more of the additional flows will fail. The risk of this happening is hard to quantify but should be fairly low, as one flow from the same interfaces has just been successfully established. Thus, only such rare events as NAT resource overload, selecting particular port numbers that are filtered, etc., ought to be reasons for failure.
NATトラバーサル故障率：NATを通る単一のフローを確立する必要があるため、最初のフローを確立すると、1つ以上の追加フローが失敗するというリスクがあります。同じインターフェースからの1つの流れが首尾よく確立されたばかりであるため、この起こっているリスクは定量化が困難ですが、かなり低いはずです。したがって、NATリソースの過負荷としてのこのようなまれなイベントのみ、フィルタリングされる特定のポート番号を選択するなど、障害の理由であるべきです。
Deep Packet Inspection and Multiple Streams: FWs differ in how deeply they inspect packets. Previous experience using FWs and Session Border Gateways (SBGs) with RTP shows that there is a significant risk that the FWs and SBGs will reject RTP sessions that use multiple SSRCs.
ディープパケット検査と複数のストリーム：FWSは、パケットの検査方法が異なります。FWSおよびセッションボーダーゲートウェイ（SBG）を使用した以前の経験RTPと、FWSとSBGが複数のSSRCを使用するRTPセッションを拒否する重大なリスクがあることを示しています。
Using additional RTP streams in the same RTP session and transport flow does not introduce any additional NAT traversal complexities per RTP stream. This can be compared with (normally) one or two additional transport flows per RTP session when using multiple RTP sessions. Additional lower-layer transport flows will be needed, unless an explicit demultiplexing layer is added between RTP and the transport protocol. At the time of this writing, no such mechanism was defined.
同じRTPセッションで追加のRTPストリームを使用し、トランスポートフローは、RTPストリームごとに追加のNATトラバーサル複雑さを導入しません。これは、複数のRTPセッションを使用するときに、RTPセッションごとに（通常）1つまたは2つの追加のトランスポートフローと比較できます。明示的な逆多重化レイヤがRTPとトランスポートプロトコルとの間に追加されない限り、追加の下位トランスポートフローが必要になるでしょう。この書き込み時には、そのようなメカニズムは定義されていません。
Multicast groups provide a powerful tool for a number of real-time applications, especially those that desire broadcast-like behaviors with one endpoint transmitting to a large number of receivers, like in IPTV. An RTP/RTCP extension to better support Source-Specific Multicast (SSM) [RFC5760] is also available. Many-to-many communication, which RTP [RFC3550] was originally built to support, has several limitations in common with multicast.
マルチキャストグループは、IPTVのように、1つのエンドポイントを1つのエンドポイントで送信するブロードキャストのような動作を望むものに強力なツールを提供します。ソース固有のマルチキャスト（SSM）[RFC5760]をサポートするためのRTP / RTCP拡張機能もあります。RTP [RFC3550]が最初にサポートされるように構築された多対多間の通信で、マルチキャストと共通のいくつかの制限があります。
One limitation is that, for any group, sender-side adaptations with the intent to suit all receivers would have to adapt to the most limited receiver experiencing the worst conditions among the group participants, which imposes degradation for all participants. For broadcast-type applications with a large number of receivers, this is not acceptable. Instead, various receiver-based solutions are employed to ensure that the receivers achieve the best possible performance. By using scalable encoding and placing each scalability layer in a different multicast group, the receiver can control the amount of traffic it receives. To have each scalability layer in a different multicast group, one RTP session per multicast group is used.
一つの制限は、すべての受信機に合うように意図された送信側の適応が、グループ参加者の間で最悪の条件を経験している最も限られた受信者に適応しなければならないことです。多数の受信機を持つブロードキャスト型アプリケーションの場合、これは受け入れられません。代わりに、受信機が最良の可能性を達成することを確実にするために、さまざまな受信機ベースの解決策が採用されています。スケーラブルエンコーディングを使用して各スケーラビリティレイヤを別のマルチキャストグループに配置することで、受信者は受信したトラフィック量を制御できます。各スケーラビリティレイヤを異なるマルチキャストグループに持つには、マルチキャストグループごとに1つのRTPセッションが使用されます。
In addition, the transport flow considerations in multicast are a bit different from unicast; NATs with port translation are not useful in the multicast environment, meaning that the entire port range of each multicast address is available for distinguishing between RTP sessions.
さらに、マルチキャストにおける輸送フローの考慮事項はユニキャストとは少し異なります。ポート変換を伴うNATはマルチキャスト環境では役に立ちません。つまり、各マルチキャストアドレスのポート範囲全体がRTPセッション間で区別できます。
Thus, when using broadcast applications it appears easiest and most straightforward to use multiple RTP sessions for sending different media flows used for adapting to network conditions. It is also common that streams improving transport robustness are sent in their own multicast group to allow for interworking with legacy applications or to support different levels of protection.
したがって、ブロードキャストアプリケーションを使用する場合、ネットワーク条件に適応するために使用される異なるメディアフローを送信するために複数のRTPセッションを使用するのが最も簡単で最も簡単に見えます。トランスポートの堅牢性を向上させるストリームは、レガシアプリケーションとの相互作用や異なるレベルの保護をサポートすることができるように、独自のマルチキャストグループで送信されることも一般的です。
Many-to-many applications have different needs, and the most appropriate multiplexing choice will depend on how the actual application is realized. Multicast applications that are capable of using sender-side congestion control can avoid the use of multiple multicast sessions and RTP sessions that result from the use of receiver-side congestion control.
多くのアプリケーションの多くのアプリケーションは異なる必要性を持ち、最も適切な多重化選択は実際のアプリケーションがどのように実現されるかによって異なります。送信側輻輳制御を使用することができるマルチキャストアプリケーションは、受信側輻輳制御の使用から生じる複数のマルチキャストセッションおよびRTPセッションの使用を回避できます。
The properties of a broadcast application using RTP multicast are as follows:
RTPマルチキャストを使用したブロードキャストアプリケーションのプロパティは次のとおりです。
1. The application uses a group of RTP sessions -- not just one. Each endpoint will need to be a member of a number of RTP sessions in order to perform well.
1. アプリケーションは、RTPセッションのグループを使用します - 1つだけではありません。各エンドポイントは、うまく実行するために多数のRTPセッションのメンバーである必要があります。
2. Within each RTP session, the number of RTP receivers is likely to be much larger than the number of RTP senders.
2. 各RTPセッション内では、RTP受信機の数はRTP送信者数よりもはるかに大きくなる可能性があります。
3. The application needs signaling functions to identify the relationships between RTP sessions.
3. アプリケーションは、RTPセッション間の関係を識別するためにシグナリング関数を必要とします。
4. The application needs signaling or RTP/RTCP functions to identify the relationships between SSRCs in different RTP sessions when more complex relations than those that can be expressed by the CNAME exist.
4. アプリケーションは、CNAMEで表現できるものよりも複雑な関係が存在する場合、さまざまなRTPセッション内のSSRC間の関係を識別するためにシグナリングまたはRTP / RTCP関数を必要とします。
Both broadcast and many-to-many multicast applications share a signaling requirement; all of the participants need the same RTP and payload type configuration. Otherwise, A could, for example, be using payload type 97 as the video codec H.264 while B thinks it is MPEG-2. SDP offer/answer [RFC3264] is not appropriate for ensuring this property in a broadcast/multicast context. The signaling aspects of broadcast/multicast are not explored further in this memo.
ブロードキャストと多対多間のマルチキャストアプリケーションの両方がシグナリング要件を共有しています。すべての参加者は、同じRTPとペイロードタイプの構成が必要です。そうでなければ、例えば、ビデオコーデックH.264としてペイロードタイプ97を使用しても、BはMPEG - 2であると考えることができる。SDPオファー/アンサー[RFC3264]は、ブロードキャスト/マルチキャストコンテキストでこのプロパティを確保するのには適していません。このメモでは、ブロードキャスト/マルチキャストのシグナリングの側面はさらに調べられません。
Security solutions for this type of group communication are also challenging. First, the key-management mechanism and the security protocol need to support group communication. Second, source authentication requires special solutions. For more discussion on this topic, please review "Options for Securing RTP Sessions" [RFC7201].
このタイプのグループコミュニケーションのためのセキュリティソリューションも困難です。まず、鍵管理メカニズムとセキュリティプロトコルはグループ通信をサポートする必要があります。第二に、ソース認証には特別な解決策が必要です。このトピックについての詳細については、「RTPセッションを確保するためのオプション」[RFC7201]を確認してください。
When dealing with point-to-point two-member RTP sessions only, there are few security issues that are relevant to the choice of having one RTP session or multiple RTP sessions. However, there are a few aspects of multi-party sessions that might warrant consideration. For general information regarding possible methods of securing RTP, please review [RFC7201].
ポイントツーポイントツーメンバーRTPセッションを扱う場合は、1つのRTPセッションまたは複数のRTPセッションを持つことの選択に関連するセキュリティ上の問題がいくつかあります。ただし、検討を保証する可能性があるマルチパーティセッションのいくつかの側面があります。RTPの保護方法に関する一般的な情報については、[RFC7201]を確認してください。
When using SRTP [RFC3711], the security context scope is important and can be a necessary differentiation in some applications. As SRTP's crypto suites are (so far) built around symmetric keys, the receiver will need to have the same key as the sender. As a result, no one in a multi-party session can be certain that a received packet was really sent by the claimed sender and not by another party having access to the key. The single SRTP algorithm not having this property is Timed Efficient Stream Loss-Tolerant Authentication (TESLA) source authentication [RFC4383]. However, TESLA adds delay to achieve source authentication. In most cases, symmetric ciphers provide sufficient security properties, but in a few cases they can create issues.
SRTP [RFC3711]を使用する場合、セキュリティコンテキストの範囲は重要であり、一部のアプリケーションでは必要な区別になる可能性があります。SRTPの暗号スイートは（これまで）対称キーを中心に構築されているので、受信機は送信者と同じキーを持つ必要があります。その結果、マルチパーティセッションには、受信したパケットが主張された送信者によって実際に送信され、そのキーにアクセスすることができないことを確認できません。このプロパティを持たない単一のSRTPアルゴリズムは、時限効率的なストリーム損失耐性認証（TESLA）ソース認証[RFC4383]です。ただし、TESLAはソース認証を達成するために遅延を追加します。ほとんどの場合、対称暗号は十分なセキュリティプロパティを提供しますが、いくつかのケースでは問題を発生させることができます。
The first case is when someone leaves a multi-party session and one wants to ensure that the party that left can no longer access the RTP streams. This requires that everyone rekey without disclosing the new keys to the excluded party.
最初のケースは、誰かがマルチパーティのセッションを残して、残っているパーティがRTPストリームにアクセスできなくなることを確認したい場合です。これには、すべての人が新しいキーを除外されたパーティーに開示せずに再登録する必要があります。
A second case is when security is used as an enforcing mechanism for stream access differentiation between different receivers. Take, for example, a scalable layer or a high-quality simulcast version that only users paying a premium are allowed to access. The mechanism preventing a receiver from getting the high-quality stream can be based on the stream being encrypted with a key that users can't access without paying a premium, using the key-management mechanism to limit access to the key.
2つ目のケースは、セキュリティが異なる受信機間のストリームアクセス差別化のための実施メカニズムとして使用されるときです。たとえば、スケーラブルなレイヤや高品質のSimulcastバージョンがプレミアムにアクセスできます。受信機が高品質のストリームを取得するのを防止するメカニズムは、鍵管理メカニズムを使用せずにユーザーがアクセスできない鍵で暗号化されているストリームに基づくことができます。
As specified in [RFC3711], SRTP uses unique keys per SSRC; however, the original assumption was a single-session master key from which SSRC-specific RTP and RTCP keys were derived. However, that assumption was proven incorrect, as the application usage and the developed key-management mechanisms have chosen many different methods for ensuring unique keys per SSRC. The key-management functions have different abilities to establish different sets of keys, normally on a per-endpoint basis. For example, DTLS-SRTP [RFC5764] and Security Descriptions [RFC4568] establish different keys for outgoing and incoming traffic from an endpoint. This key usage has to be written into the cryptographic context, possibly associated with different SSRCs. Thus, limitations do exist, depending on the chosen key-management method and due to the integration of particular implementations of the key-management method and SRTP.
[RFC3711]で指定されているように、SRTPはSSRCごとに一意のキーを使用します。ただし、元の仮定はSSRC固有のRTPとRTCPキーが導き出された単一セッションマスターキーでした。ただし、アプリケーションの使用法と開発された鍵管理メカニズムが、SSRCごとに一意のキーを確保するためのさまざまな方法を選択したため、この仮定は誤って証明されました。鍵管理機能は、通常、エンドポイントごとに異なる鍵セットを確立するための異なる能力を持っています。たとえば、DTLS-SRTP [RFC5764]とセキュリティの説明[RFC4568]エンドポイントからの発信トラフィックと着信トラフィックのさまざまなキーを確立します。この鍵の使用法は、おそらくさまざまなSSRCに関連付けられている可能性がある暗号文脈に書かれなければなりません。したがって、選択された鍵管理方法に応じて、および鍵管理方法とSRTPの特定の実装の統合により制限があります。
The capabilities of the key-management method combined with the RTP multiplexing choices affect the resulting security properties, control over the secured media, and who has access to it.
RTP多重化選択と組み合わされた鍵管理方法の機能は、結果として生じるセキュリティプロパティ、保護されたメディアを制御し、誰がアクセスできるかに影響します。
Multi-party sessions contain at least one RTP stream from each active participant. Depending on the multi-party topology [RFC7667], each participant can both send and receive multiple RTP streams. Transport translator-based sessions (Topo-Trn-Translator) and multicast sessions (Topo-ASM) can use neither Security Descriptions [RFC4568] nor DTLS-SRTP [RFC5764] without an extension, because each endpoint provides its own set of keys. In centralized conferences, the signaling counterpart is a conference server, and the transport translator is the media-plane unicast counterpart (to which DTLS messages would be sent). Thus, an extension like Encrypted Key Transport [RFC8870] or a solution based on Multimedia Internet KEYing (MIKEY) [RFC3830] that allows for keying all session participants with the same master key is needed.
マルチパーティセッションには、各アクティブな参加者から少なくとも1つのRTPストリームが含まれています。マルチパーティトポロジ[RFC7667]に応じて、各参加者は複数のRTPストリームを送受信することができます。トランスポートトランスレータベースのセッション（TOPO-TRN-Translator）とマルチキャストセッション（TOPO-ASM）は、拡張子のセットが独自のキーを提供するため、セキュリティ記述（RFC4568]もDTLS-SRTP [RFC5764]を使用しないでください。集中化された会議では、シグナリングの対応物は会議サーバーであり、トランスポートトランスレータはメディアプレーンユニキャスト対応物（DTLSメッセージが送信される）です。したがって、同じマスターキーを持つすべてのセッション参加者をキーにキーを押すことを可能にする、暗号化キートランスポート[RFC8870]のような拡張またはソリューション（Mikey）[RFC3830]。
Privacy-Enhanced RTP Conferencing (PERC) also enables a different trust model with semi-trusted media-switching RTP middleboxes [RFC8871].
Privacy-Enhanced RTP会議（PERC）はまた、半信頼されたメディアスイッチングRTPミドルボックス[RFC8871]を備えた別の信頼モデルを可能にします。
There can be complex interactions between the choice of multiplexing and topology and the security functions. This becomes especially evident in RTP topologies having any type of middlebox that processes or modifies RTP/RTCP packets. While the overhead of an RTP translator or mixer rewriting an SSRC value in the RTP packet of an unencrypted session is low, the cost is higher when using cryptographic security functions. For example, if using SRTP [RFC3711], the actual security context and exact crypto key are determined by the SSRC field value. If one changes the SSRC value, the encryption and authentication must use another key. Thus, changing the SSRC value implies a decryption using the old SSRC and its security context, followed by an encryption using the new one.
多重化とトポロジーの選択とセキュリティ機能の間に複雑な相互作用があります。これは、RTP / RTCPパケットを処理または変更するあらゆるタイプのミドルボックスを持つRTPトポロジでは特に明らかになります。暗号化されていないセッションのRTPパケット内のSSRC値をRTP翻訳者またはミキサーの書き換えのオーバーヘッドが低い間は、暗号化セキュリティ機能を使用するとコストが高くなります。たとえば、SRTP [RFC3711]を使用する場合、実際のセキュリティコンテキストと正確な暗号鍵はSSRCフィールド値によって決まります。SSRC値を変更すると、暗号化と認証は別のキーを使用する必要があります。したがって、SSRC値を変更すると、古いSSRCとそのセキュリティコンテキストを使用した復号化が行われ、その後に新しいものを使用して暗号化が行われます。
This section discusses how some RTP multiplexing design choices can be used in applications to achieve certain goals and summarizes the implications of such choices. The benefits and downsides of each design are also discussed.
このセクションでは、特定の目標を達成するためにアプリケーションでいくつかのRTP多重化設計の選択肢をどのように使用できるかについて説明し、そのような選択肢の影響を要約しています。各デザインの利点と下位側についても説明します。
This design uses a single RTP session for multiple different media types, like audio and video, and possibly also transport robustness mechanisms like FEC or retransmission. An endpoint can send zero, one, or multiple media sources per media type, resulting in a number of RTP streams of various media types for both source and redundancy streams.
このデザインは、オーディオやビデオのような複数の異なるメディアタイプに単一のRTPセッションを使用し、FECや再送信などの堅牢性メカニズムも輸送されます。エンドポイントは、メディアタイプごとにゼロ、1、または複数のメディアソースを送信でき、その結果、ソースストリームと冗長ストリームの両方に対してさまざまなメディアタイプの数のRTPストリームがあります。
Advantages:
利点：
1. Only a single RTP session is used, which implies:
1. 単一のRTPセッションだけが使用されます。
* Minimal need to keep NAT/FW state.
* NAT / FW状態を保持する必要があります。
* Minimal NAT/FW traversal cost.
* 最小NAT / FWトラバースコスト。
* Fate-sharing for all media flows.
* すべてのメディアフローの運命共有
* Minimal overhead for security association establishment.
* セキュリティ協会設立のための最小限のオーバーヘッド。
2. Dynamic allocation of RTP streams can be handled almost entirely at the RTP level. The extent to which this allocation can be kept at the RTP level depends on the application's needs for an explicit indication of stream usage and in how timely a fashion that information can be signaled.
2. RTPストリームの動的割り当ては、ほぼ完全にRTPレベルで処理することができます。この割り当てがRTPレベルに保たれることができる範囲は、ストリーム使用量の明示的な表示のためのアプリケーションのニーズと、情報をシグナリングできる方法でどのようにタイムリーになります。
Disadvantages:
デメリット：
1. It is less suitable for interworking with other applications that use individual RTP sessions per media type or multiple sessions for a single media type, due to the risk of SSRC collisions and thus a potential need for SSRC translation.
1. SSRCの衝突の危険性、したがってSSRC翻訳の可能性があるため、1つのメディアタイプのメディアタイプまたは複数のセッションの個々のRTPセッションを使用する他のアプリケーションとのインターワーキングには適していません。
2. Negotiation of individual bandwidths for the different media types is currently only possible in SDP when using RID [RFC8851].
2. さまざまなメディアタイプの個々の帯域幅のネゴシエーションは、RID [RFC8851]を使用する場合はSDPでのみ可能です。
3. It is not suitable for split component terminals (see Section 3.10 of [RFC7667]).
3. 分割コンポーネント端末には適していません（[RFC7667]のセクション3.10を参照）。
4. Flow-based QoS cannot be used to provide separate treatment of RTP streams compared to others in the single RTP session.
4. フローベースのQoSは、単一のRTPセッション内の他のRTPストリームと比較してRTPストリームの別々の処理を提供するために使用することはできません。
5. If there is significant asymmetry between the RTP streams' RTCP reporting needs, there are some challenges related to configuration and usage to avoid wasting RTCP reporting on the RTP stream that does not need such frequent reporting.
5. RTPストリームのRTCPレポートニーズの間に重要な非対称性がある場合は、そのような頻繁な報告を必要としないRTPストリームでのRTCPレポートの浪費を避けるための構成および使用に関連するいくつかの課題があります。
6. It is not suitable for applications where some receivers like to receive only a subset of the RTP streams, especially if multicast or a transport translator is being used.
6. いくつかの受信機が、特にマルチキャストまたはトランスポートトランスレータが使用されている場合には、レシーバがRTPストリームのサブセットのみを受信したいアプリケーションには適していません。
7. There are some additional concerns regarding legacy implementations that do not support the RTP specification fully when it comes to handling multiple SSRCs per endpoint, as multiple simultaneous media types are sent as separate SSRCs in the same RTP session.
7. 複数の同時メディアタイプが同じRTPセッション内の別々のSSRCとして送信されるため、RTP仕様を完全にサポートしないレガシー実装に関するいくつかの追加の懸念があります。
8. If the applications need finer control over which session participants are included in different sets of security associations, most key-management mechanisms will have difficulties establishing such a session.
8. アプリケーションがセッション参加者が異なるセキュリティアソシエーションに含まれているのを巧みに制御する必要がある場合、ほとんどの鍵管理メカニズムはそのようなセッションを確立することが困難になるでしょう。
In this design, each RTP session serves only a single media type. The RTP session can contain multiple RTP streams, from either a single endpoint or multiple endpoints. This commonly creates a low number of RTP sessions, typically only one for audio and one for video, with a corresponding need for two listening ports when using RTP/RTCP multiplexing [RFC5761].
この設計では、各RTPセッションは単一のメディアタイプのみに役立ちます。RTPセッションは、単一のエンドポイントまたは複数のエンドポイントから、複数のRTPストリームを含めることができます。これは一般的に数のRTPセッションを一般的に作成します。通常は、RTP / RTCP多重化[RFC5761]を使用する場合の2つのリスニングポートの必要性がある場合は、通常、ビデオ用の1つだけです。
Advantages:
利点：
1. It works well with split component terminals (see Section 3.10 of [RFC7667]) where the split is per media type.
1. それは分割コンポーネント端末とうまく機能します（[RFC7667]のセクション3.10を参照）。
2. It enables flow-based QoS with different prioritization levels between media types.
2. メディアタイプ間で異なる優先順位付けレベルを持つフローベースのQoSをイネーブルにします。
3. For applications with dynamic usage of RTP streams (i.e., streams are frequently added and removed), having much of the state associated with the RTP session rather than per individual SSRC can avoid the need for in-session signaling of meta-information about each SSRC. In simple cases, this allows for unsignaled RTP streams where session-level information and an RTCP SDES item (e.g., CNAME) are sufficient. In the more complex cases where more source-specific metadata needs to be signaled, the SSRC can be associated with an intermediate identifier, e.g., the MID conveyed as an SDES item as defined in Section 15 of [RFC8843].
3. RTPストリームの動的使用量（すなわち、ストリームが頻繁に追加されて削除された）のために、個々のSSRCごとではなくRTPセッションに関連する状態の多くを持つことは、各SSRCに関するメタ情報のセッション内シグナリングの必要性を回避することができる。。簡単な場合、これはセッションレベルの情報とRTCP SDES項目（例えばCNAME）が十分である符号なしRTPストリームを可能にする。より多くのソース固有のメタデータをシグナリングする必要があるより複雑なケースでは、SSRCは、[RFC8843]のセクション15で定義されているSDESアイテムとして伝送される中間識別子と関連付けることができる。
4. The overhead of security association establishment is low.
4. セキュリティアソシエーション設立のオーバーヘッドは低いです。
Disadvantages:
デメリット：
1. A slightly higher number of RTP sessions are needed, compared to multiple media types in one session (Section 5.1). This implies the following:
1. 1つのセッションで複数のメディアタイプと比較して、わずかに多数のRTPセッションが必要です（セクション5.1）。これは次のことを意味します。
* More NAT/FW state is needed.
* より多くのNAT / FW状態が必要です。
* The cost of NAT/FW traversal is increased in terms of both processing and delay.
* NAT / FWトラバースのコストは、処理と遅延の両方に関して増加します。
2. There is some potential for concern regarding legacy implementations that don't support the RTP specification fully when it comes to handling multiple SSRCs per endpoint.
2. エンドポイントごとに複数のSSRCを処理することになると、RTP仕様を完全にサポートしていないレガシー実装に関する懸念がある可能性があります。
3. It is not possible to control security associations for sets of RTP streams within the same media type with today's key-management mechanisms, unless these are split into different RTP sessions (Section 5.3).
3. これらが異なるRTPセッションに分割されていない限り、今日の鍵管理メカニズムを使用して、同じメディアタイプ内のRTPストリームのセットのセキュリティアソシエーションを制御することはできません（セクション5.3）。
For RTP applications where all RTP streams of the same media type share the same usage, this structure provides efficiency gains in the amount of network state used and provides more fate-sharing with other media flows of the same type. At the same time, it still maintains almost all functionalities for the negotiation signaling of properties per individual media type and also enables flow-based QoS prioritization between media types. It handles multi-party sessions well, independently of multicast or centralized transport distribution, as additional sources can dynamically enter and leave the session.
同じメディアタイプのすべてのRTPストリームが同じ使用法を共有するRTPアプリケーションの場合、この構造は使用されるネットワーク状態の量の効率の向上をもたらし、同じタイプの他のメディアフローとのより多くの運送を提供します。同時に、個々のメディアタイプごとにプロパティのネゴシエーションシグナリングのためのほとんどすべての機能を維持し、メディアタイプ間でフローベースのQoS優先順位付けを可能にします。追加の情報源がセッションを動的に入ってまとめることができるため、マルチキャストまたは集中型のトランスポート分布とは無関係に、マルチパーティセッションをよく処理します。
This design goes one step further than the design discussed in Section 5.2 by also using multiple RTP sessions for a single media type. The main reason for going in this direction is that the RTP application needs separation of the RTP streams according to their usage, such as, for example, scalability over multicast, simulcast, the need for extended QoS prioritization, or the need for fine-grained signaling using RTP session-focused signaling tools.
この設計は、1つのメディアタイプに対して複数のRTPセッションを使用することによって、セクション5.2で説明した設計よりもさらに一歩進みます。この方向に進む主な理由は、RTPアプリケーションが、例えばマルチキャスト、Simulcast、拡張QoS優先順位付けの必要性、微細粒の必要性など、それらの使用に応じてRTPストリームの分離を必要とすることです。RTPセッション焦点のシグナリングツールを使用したシグナリング
Advantages:
利点：
1. This design is more suitable for multicast usage where receivers can individually select which RTP sessions they want to participate in, assuming that each RTP session has its own multicast group.
1. この設計は、各RTPセッションに独自のマルチキャストグループがあると仮定して、受信者が参加したいRTPセッションを個別に選択できるマルチキャスト使用に適しています。
2. When multiple different usages exist, the application can indicate its usage of the RTP streams at the RTP session level.
2. 複数の異なる使用率が存在する場合、アプリケーションはRTPセッションレベルでRTPストリームの使用状況を示すことができます。
3. There is less need for SSRC-specific explicit signaling for each media stream and thus a reduced need for explicit and timely signaling when RTP streams are added or removed.
3. 各メディアストリームに対するSSRC固有の明示的シグナリングが必要とされ、したがって、RTPストリームが追加または削除されたときに明示的かつ適時にシグナリングする必要がなくなる。
4. It enables detailed QoS prioritization for flow-based mechanisms.
4. それはフローベースのメカニズムのための詳細なQoS優先順位付けを可能にします。
5. It works well with split component terminals (see Section 3.10 of [RFC7667]).
5. 分割コンポーネント端末でうまく機能します（[RFC7667]のセクション3.10を参照）。
6. The scope for who is included in a security association can be structured around the different RTP sessions, thus enabling such functionality with existing key-management mechanisms.
6. セキュリティアソシエーションに含まれている人の範囲は、さまざまなRTPセッションの周囲に構造化することができ、したがって、既存の鍵管理メカニズムを使用してそのような機能を有効にします。
Disadvantages:
デメリット：
1. There is an increased amount of session configuration state compared to multiple SSRCs of the same media type (Section 5.2), due to the increased amount of RTP sessions.
1. RTPセッションの量が増加したため、同じメディアタイプの複数のSSRCと比較して、セッション構成状態が増加します（セクション5.2）。
2. For RTP streams that are part of scalability, simulcast, or transport robustness, a method for binding sources across multiple RTP sessions is needed.
2. スケーラビリティ、Simulcast、またはトランスストロバスト性の一部であるRTPストリームの場合、複数のRTPセッションにわたってソースをバインドする方法が必要です。
3. There is some potential for concern regarding legacy implementations that don't support the RTP specification fully when it comes to handling multiple SSRCs per endpoint.
3. エンドポイントごとに複数のSSRCを処理することになると、RTP仕様を完全にサポートしていないレガシー実装に関する懸念がある可能性があります。
4. The overhead of security association establishment is higher, due to the increased number of RTP sessions.
4. セキュリティ協会の設立のオーバーヘッドは、RTPセッションの数が増えたためです。
5. If the applications need finer control over which participants in a given RTP session are included in different sets of security associations, most of today's key-management mechanisms will have difficulties establishing such a session.
5. 特定のRTPセッションの参加者が異なるセキュリティアソシエーションセットに含まれているどのようなコントロールが含まれる必要がある場合、今日の鍵管理メカニズムのほとんどはそのようなセッションを確立することが困難になるでしょう。
For more-complex RTP applications that have several different usages for RTP streams of the same media type or that use scalability or simulcast, this solution can enable those functions, at the cost of increased overhead associated with the additional sessions. This type of structure is suitable for more-advanced applications as well as multicast-based applications requiring differentiation to different participants.
同じメディアタイプのRTPストリームまたはその使用スケーラビリティまたはSimulcastを使用するためのいくつかの異なる使用法を持つより複雑なRTPアプリケーションの場合、このソリューションは、追加のセッションに関連するオーバーヘッドの増加のコストで、それらの機能を有効にすることができます。この種の構造は、より高度なアプリケーション、ならびにさまざまな参加者への差別化を必要とするマルチキャストベースのアプリケーションに適しています。
In this design, each endpoint in a point-to-point session has only a single SSRC; thus, the RTP session contains only two SSRCs -- one local and one remote. This session can be used either unidirectionally (i.e., one SSRC sends an RTP stream that is received by the other SSRC) or bidirectionally (i.e., the two SSRCs both send an RTP stream and receive the RTP stream sent by the other endpoint). If the application needs additional media flows between the endpoints, it will have to establish additional RTP sessions.
この設計では、ポイントツーポイントセッションの各エンドポイントは単一のSSRCしかありません。したがって、RTPセッションには2つのSSRCS - 1つのローカルと1つのリモートのみが含まれています。このセッションは単方向で使用することができます（すなわち、1つのSSRCは他のSSRCによって受信されたRTPストリームを送信する）、または双方向に（すなわち、2つのSSRCがRTPストリームを送信し、他のエンドポイントによって送信されたRTPストリームを受信する）。アプリケーションがエンドポイント間に追加のメディアフローを必要とする場合は、追加のRTPセッションを確立する必要があります。
Advantages:
利点：
1. This design has great potential for interoperability with legacy applications, as it will not tax any RTP stack implementations.
1. この設計は、RTPスタックの実装を課税されないので、レガシーアプリケーションとの相互運用性に大きな可能性があります。
2. The signaling system makes it possible to negotiate and describe the exact formats and bitrates for each RTP stream, especially using today's tools in SDP.
2. シグナリングシステムは、特にSDPの今日のツールを使用して、各RTPストリームに対して正確なフォーマットとビットレートをネゴシエートして記述することを可能にします。
3. It is possible to control security associations per RTP stream with current key-management functions, since each RTP stream is directly related to an RTP session and the most commonly used keying mechanisms operate on a per-session basis.
3. 各RTPストリームはRTPセッションに直接関係し、最も一般的に使用されているキーイングメカニズムはセッションごとに動作するため、RTPストリームごとのセキュリティアソシエーションを現在の鍵管理機能を制御することができます。
Disadvantages:
デメリット：
1. The amount of NAT/FW state grows linearly with the number of RTP streams.
1. NAT / FW状態の量は、RTPストリームの数と直線的に増加します。
2. NAT/FW traversal increases delay and resource consumption.
2. NAT / FWトラバーサルは遅延とリソース消費を増加させます。
3. There are likely more signaling message and signaling processing requirements due to the increased amount of session-related information.
3. セッション関連情報の量が増加したため、シグナリングメッセージおよびシグナリング処理要件がより多くあります。
4. There is higher potential for a single RTP stream to fail during transport between the endpoints, due to the need for a separate NAT/FW traversal for every RTP stream, since there is only one stream per session.
4. セッションごとに1つのストリームがあるため、すべてのRTPストリームに対して別のNAT / FWトラバーサルが必要なため、エンドポイント間のトランスポート中に単一のRTPストリームが故障する可能性が高くなります。
5. The amount of explicit state for relating RTP streams grows, depending on how the application relates RTP streams.
5. RTPストリームを関連付けるための明示的な状態の量は、アプリケーションがRTPストリームに関連する方法に応じて成長します。
6. Port consumption might become a problem for centralized services, where the central node's port or 5-tuple filter consumption grows rapidly with the number of sessions.
6. ポート消費量は集中型サービスにとって問題となる可能性があります。ここでは、中央ノードのポートまたは5タプルフィルタ消費量がセッション数と急速に増加します。
7. For applications where RTP stream usage is highly dynamic, i.e., entities frequently enter and leave sessions, the amount of signaling can become high. Issues can also arise from the need for timely establishment of additional RTP sessions.
7. RTPストリームの使用量が非常に動的であるアプリケーションでは、すなわちエンティティは頻繁にセッションを入力して脱退させると、シグナリングの量は高くなる可能性があります。追加のRTPセッションのタイムリーな確立の必要性から問題が発生する可能性があります。
8. If, against the recommendation in [RFC3550], the same SSRC value is reused in multiple RTP sessions rather than being randomly chosen, interworking with applications that use a different multiplexing structure will require SSRC translation.
8. [RFC3550]での推奨に対して、同じSSRC値がランダムに選択されるのではなく、複数のRTPセッションで再利用され、異なる多重化構造を使用するアプリケーションとの相互作用がSSRC変換を必要とします。
RTP applications with a strong need to interwork with legacy RTP applications can potentially benefit from this structure. However, a large number of media descriptions in SDP can also run into issues with existing implementations. For any application needing a larger number of media flows, the overhead can become very significant. This structure is also not suitable for non-mixed multi-party sessions, as any given RTP stream from each participant, although having the same usage in the application, needs its own RTP session. In addition, the dynamic behavior that can arise in multi-party applications can tax the signaling system and make timely media establishment more difficult.
従来のRTPアプリケーションとの相互作用を強く求めるRTPアプリケーションは、この構造から恩恵を受ける可能性があります。ただし、SDPの多数のメディア記述は既存の実装に関する問題にも実行できます。より多くのメディアフローを必要とするあらゆるアプリケーションのために、オーバーヘッドは非常に重要になる可能性があります。この構造は、各参加者からの任意の特定のRTPストリームとして、混在していないマルチパーティセッションにも適していませんが、アプリケーションで同じ使用法を持ち、独自のRTPセッションが必要です。さらに、マルチパーティアプリケーションで発生する可能性がある動的な動作はシグナリングシステムに課税でき、タイムリーなメディア設立をより困難にすることができます。
Both the "single SSRC per endpoint" (Section 5.4) and "multiple media types in one session" (Section 5.1) cases require full explicit signaling of the media stream relationships. However, they operate on two different levels, where the first primarily enables session-level binding and the second needs SSRC-level binding. From another perspective, the two solutions are the two extremes when it comes to the number of RTP sessions needed.
「エンドポイントごとの単SSRCごとのシングルSSRC」（セクション5.4）および「1セッション内の複数のメディアタイプ」（セクション5.1）ケースは、メディアストリーム関係の完全な明示的なシグナリングを必要とします。ただし、それらは2つの異なるレベルで動作します。ここで、最初の主にセッションレベルのバインディングを可能にし、2番目の必要なSSRCレベルのバインディングが可能になります。別の観点からは、2つの解決策は必要なRTPセッションの数に関して2つの極値です。
The two other designs -- multiple SSRCs of the same media type (Section 5.2) and multiple sessions for one media type (Section 5.3) -- are two examples that primarily allow for some implicit mapping of the role or usage of the RTP streams based on which RTP session they appear in. Thus, they potentially allow for less signaling and, in particular, reduce the need for real-time signaling in sessions with a dynamically changing number of RTP streams. They also represent points between the first two designs when it comes to the amount of RTP sessions established, i.e., they represent an attempt to balance the amount of RTP sessions with the functionality the communication session provides at both the network level and the signaling level.
他の2つのデザイン - 同じメディアタイプの複数のSSRC（セクション5.2）と1つのメディアタイプ（セクション5.3）の複数のセッション - 主にRTPストリームの役割または使用方法の暗黙のマッピングを主に許可する2つの例です。したがって、それらはどのRTPセッションに表示されます。したがって、それらは潜在的にシグナリングが少なく、特に、動的に変化する数のRTPストリームを有するセッションにおけるリアルタイムシグナリングの必要性を減らすことができる。それらはまた、それが確立されたRTPセッションの量に関して最初の2つの設計の間の点を表す、すなわち、それらは通信セッションがネットワークレベルとシグナリングレベルの両方で提供される機能とのRTPセッションの量をバランスする試みを表す。
This section contains a number of multi-stream guidelines for implementers, system designers, and specification writers.
このセクションには、実装者、システム設計者、および仕様書作成者のための多数のマルチストリームガイドラインが含まれています。
Do not require the use of the same SSRC value across RTP sessions: As discussed in Section 3.4.3, there are downsides to using the same SSRC in multiple RTP sessions as a mechanism to bind related RTP streams together. It is instead recommended to use a mechanism to explicitly signal the relationship, in either RTP/RTCP or the signaling mechanism used to establish the RTP session(s).
RTPセッション間で同じSSRC値を使用する必要はありません。セクション3.4.3で説明したように、関連RTPストリームを一緒にバインドするメカニズムとして、複数のRTPセッションで同じSSRCを使用するための小規模があります。その代わりに、RTP / RTCPまたはRTPセッションを確立するために使用されるシグナリングメカニズムのいずれかで、その関係を明示的にシグナリングするためのメカニズムを使用することをお勧めします。
Use additional RTP streams for additional media sources: In the cases where an RTP endpoint needs to transmit additional RTP streams of the same media type in the application, with the same processing requirements at the network and RTP layers, it is suggested to send them in the same RTP session. For example, in the case of a telepresence room where there are three cameras and each camera captures two persons sitting at the table, we suggest that each camera send its own RTP stream within a single RTP session.
追加のメディアソースに追加のRTPストリームを使用します.RTPエンドポイントがアプリケーション内で同じメディアタイプの追加のRTPストリームを送信する必要がある場合は、ネットワークレイヤとRTPレイヤーで同じ処理要件で、それらを送信することが推奨されます。同じRTPセッション。たとえば、3つのカメラがあるテレプレゼンスルームの場合、各カメラがテーブルに座っている2人の人をキャプチャしているため、各カメラは単一のRTPセッション内で独自のRTPストリームを送信することをお勧めします。
Use additional RTP sessions for streams with different requirements: When RTP streams have different processing requirements from the network or the RTP layer at the endpoints, it is suggested that the different types of streams be put in different RTP sessions. This includes the case where different participants want different subsets of the set of RTP streams.
要件が異なるストリームに追加のRTPセッションを使用します.RTP StreamsがネットワークまたはエンドポイントでRTPレイヤから異なる処理要件を持つ場合、さまざまな種類のストリームがさまざまなRTPセッションに入れることが示唆されます。これには、異なる参加者がRTPストリームのセットの異なるサブセットを望んでいる場合が含まれます。
Use grouping when using multiple RTP sessions: When using multiple RTP session solutions, it is suggested to explicitly group the involved RTP sessions when needed using a signaling mechanism -- for example, see "The Session Description Protocol (SDP) Grouping Framework" [RFC5888] -- using some appropriate grouping semantics.
複数のRTPセッションを使用する場合：複数のRTPセッションを使用する場合：複数のRTPセッションソリューションを使用する場合、シグナリングメカニズムを使用して必要な場合に関与するRTPセッションを明示的にグループ化することが推奨されます。たとえば、「セッション記述プロトコル（SDP）グループグループ化フレームワーク」[RFC5888]を参照してください。] - いくつかの適切なグループ化セマンティクスを使用しています。
Ensure that RTP/RTCP extensions support multiple RTP streams as well as multiple RTP sessions: When defining an RTP or RTCP extension, the creator needs to consider if this extension is applicable for use with additional SSRCs and multiple RTP sessions. Any extension intended to be generic must support both. Extensions that are not as generally applicable will have to consider whether interoperability is better served by defining a single solution or providing both options.
RTP / RTCP Extensionsが複数のRTPストリームと複数のRTPセッションをサポートしていることを確認します.RTPまたはRTCP拡張機能を定義するとき、この拡張子が追加のSSRCSおよび複数のRTPセッションで使用するために適用可能な場合にCreatorが考慮する必要があります。一般的な範囲は、両方をサポートする必要があります。一般的に適用可能ではない拡張機能は、単一のソリューションを定義することによって、または両方のオプションを提供することによって相互運用性がより良いかどうかを考慮する必要があります。
Provide adequate extensions for transport support: When defining new RTP/RTCP extensions intended for transport support, like the retransmission or FEC mechanisms, they must include support for both multiple RTP streams in the same RTP session and multiple RTP sessions, such that application developers can choose freely from the set of mechanisms without concerning themselves with which of the multiplexing choices a particular solution supports.
トランスポートサポートのための適切な拡張機能を提供する：再送またはFECメカニズムのように、トランスポートサポートを目的とした新しいRTP / RTCP拡張機能を定義する場合は、アプリケーション開発者ができるように、同じRTPセッションおよび複数のRTPセッション内の両方の複数のRTPストリームのサポートを含める必要があります。特定のソリューションがサポートされている多重化の選択肢のどちらに関係なく、メカニズムのセットから自由に選択します。
This document has no IANA actions.
この文書にはIANAの行動がありません。
The security considerations discussed in the RTP specification [RFC3550]; any applicable RTP profile [RFC3551] [RFC4585] [RFC3711]; and the extensions for sending multiple media types in a single RTP session [RFC8860], RID [RFC8851], BUNDLE [RFC8843], [RFC5760], and [RFC5761] apply if selected and thus need to be considered in the evaluation.
RTP仕様で説明したセキュリティ上の考慮事項[RFC3550]。該当するRTPプロファイル[RFC3551] [RFC4585] [RFC3711];また、単一のRTPセッションで複数のメディアタイプを送信するための拡張[RFC8860]、[RFC8851]、[RFC8843]、[RFC5760]、[RFC5761]、[RFC5761]、[RFC5761]、[評価]で考慮する必要があります。
Section 4.3 discusses the security implications of choosing multiple SSRCs vs. multiple RTP sessions.
セクション4.3は、複数のSSRCと複数のRTPセッションを選択することのセキュリティの意味を説明します。
[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, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、「RTP：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://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, <https://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H.およびS.Casner、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<https：///www.rfc-編集者。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, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E.、K.Norrman、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004年、<https：//www.rfc-editor.org/info/rfc3711>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.
[RFC4585] OTT、J.、Wenger、S.、Sato、N.、Burmeister、C.、J.REY、「リアルタイムトランスポート制御プロトコルのための拡張RTPプロファイル（RTCP）ベースのフィードバック（RTP / AVPF）"、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<https://www.rfc-editor.org/info/rfc4585>。
[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, <https://www.rfc-editor.org/info/rfc5576>.
[RFC5576] Lennox、J.、OTT、J.、およびT.Schierl、「セッション記述プロトコル（SDP）」、RFC 5576、DOI 10.17487 / RFC5576、2009年6月、<https：//のソース固有のメディア属性www.rfc-editor.org/info/rfc5576>。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, DOI 10.17487/RFC5760, February 2010, <https://www.rfc-editor.org/info/rfc5760>.
[RFC5760] OTT、J.、Chesterfield、J.、E. Schoarer、ユニキャストフィードバックによる単一ソースマルチキャストセッションの「RTP制御プロトコル（RTCP）拡張」、RFC 5760、DOI 10.17487 / RFC5760、2010年2月、<HTTPS///www.rfc-editor.org/info/rfc5760>。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <https://www.rfc-editor.org/info/rfc5761>.
[RFC5761] Perkins、C、M. Westerlund、 "1つのポート上のRFCのRTPデータとコントロールパケット"、RFC 5761、DOI 10.17487 / RFC5761、2010年4月、<https://www.rfc-editor.org/info/ RFC5761>。
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <https://www.rfc-editor.org/info/rfc7656>.
[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G.、B. Burman、ED。、「リアルタイムトランスポートプロトコル（RTP）ソースのためのセマンティクスおよびメカニズムの分類」、RFC 7656、DOI 10.17487 / RFC7656、2015年11月、<https：//www.rfc-editor.org/info/rfc7656>。
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <https://www.rfc-editor.org/info/rfc7667>.
[RFC7667] Westerlund、M.およびS.Wenger、 "RTPトポロジ"、RFC 7667、DOI 10.17487 / RFC7667、2015年11月、<https：//www.rfc-editor.org/info/rfc7667>。
[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021, <https://www.rfc-editor.org/info/rfc8843>.
[RFC8843] Holmberg、C、Alvestrand、H.、およびC.ジェンニング、「セッション記述プロトコル（SDP）」、RFC 8843、DOI 10.17487 / RFC8843、<https：// www。rfc-editor.org/info/rfc8843>。
[RFC8851] Roach, A.B., Ed., "RTP Payload Format Restrictions", RFC 8851, DOI 10.17487/RFC8851, January 2021, <https://www.rfc-editor.org/info/rfc8851>.
[RFC8851] Roach、A.B.、ED。、「RTPペイロードフォーマット制限」、RFC 8851、DOI 10.17487 / RFC8851、2021年1月、<https：//www.rfc-editor.org/info/rfc8851>。
[RFC8852] Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", RFC 8852, DOI 10.17487/RFC8852, January 2021, <https://www.rfc-editor.org/info/rfc8852>.
[RFC8852] Roach、AB、Nandakumar、S.、およびP. Thatcher、RFC 8852、DOI 10.17487 / RFC8852、2021年1月、<https：///www.rfc-編集者。org / info / rfc8852>。
[RFC8860] Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", RFC 8860, DOI 10.17487/RFC8860, January 2021, <https://www.rfc-editor.org/info/rfc8860>.
[RFC8860] Westerlund、M.、Perkins、C.、J.Lennox、「1つのRTPセッションで複数種類のメディアを送信する」、RFC 8860、DOI 10.17487 / RFC8860、2021年1月、<https：//www.rfc-editor.org/info/rfc8860>。
[RFC8870] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. Andreasen, "Encrypted Key Transport for DTLS and Secure RTP", RFC 8870, DOI 10.17487/RFC8870, January 2021, <https://www.rfc-editor.org/info/rfc8870>.
[RFC8870] Jennings、C、Mattsson、J.、McGrew、D.、Wing、D.、およびF. Andreasen、「DTLSおよびSecure RTPの暗号化キートランスポート」、RFC 8870、DOI 10.17487 / RFC8870、2021年1月、<https://www.rfc-editor.org/info/rfc8870>。
[JINGLE] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, "XEP-0166: Jingle", September 2018, <https://xmpp.org/extensions/xep-0166.html>.
[ジングル]ルドウィッヒ、S.、Beda、J.、Saint-Andre、P.、McQueen、R.、Egan、J.Hildebrand、 "XEP-0166：Jingle"、2018年9月、<https：// xeppp.org/extensions/xep-0166.html>。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, <https://www.rfc-editor.org/info/rfc2198>.
[RFC2198] Perkins、C、Kouvelas、I。、Hodson、O.、Hardman、V.、Handley、M.、Bolot、JC、Vega-Garcia、A.、およびS.FOSSE-PARISIS、「RTPペイロード」冗長オーディオデータ "、RFC 2198、DOI 10.17487 / RFC2198、1997年9月、<https://www.rfc-editor.org/info/rfc2198>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、DOI10.17487 / RFC2205、1997年9月、<https：//www.rfc-editor.org/info/rfc2205>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F.、およびD.黒、「IPv4およびIPv6ヘッダーのDSフィールドの定義」、RFC 2474、DOI 10.17487 / RFC2474、1998年12月、<https：//www.rfc-editor.org/info/rfc2474>。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <https://www.rfc-editor.org/info/rfc2974>.
[RFC2974]ハンドリー、M.、Perkins、C.、およびE.Whelan、「セッションアナウンスプロトコル」、RFC 2974、DOI 10.17487 / RFC2974、2000年10月、<https：//www.rfc-editor.org/info/RFC2974>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https：//ww.rfc-editor.org/ info / rfc3264>。
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, September 2002, <https://www.rfc-editor.org/info/rfc3389>.
[RFC3389] ZOPF、R.、「リアルタイムトランスポートプロトコル（RTP）」、RFC 3389、DOI 10.17487 / RFC3389、2002年9月、<https：//www.rfc-editor.org/情報/ RFC3389>。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, DOI 10.17487/RFC3830, August 2004, <https://www.rfc-editor.org/info/rfc3830>.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M.、およびK. Norrman、「Mikey：マルチメディアインターネットキーイン」、RFC 3830、DOI 10.17487 / RFC3830、2004年8月、<HTTPS：//www.rfc-editor.org/info/rfc3830>。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <https://www.rfc-editor.org/info/rfc4103>.
[RFC4103] Hellstrom、G.およびP. Jones、「テキスト会話のためのRTPペイロード」、RFC 4103、DOI 10.17487 / RFC4103、2005年6月、<https://www.rfc-editor.org/info/rfc4103>。
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, DOI 10.17487/RFC4383, February 2006, <https://www.rfc-editor.org/info/rfc4383>.
[RFC4383] Baugher、M.およびE. Carrara、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 4383、DOI 10.17487 / RFC4383、2006年2月、<https://www.rfc-editor.org/info/rfc4383>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566]ハンドリー、M.、Jacobson、V.、およびC.Perkins、「SDP：セッション記述プロトコル」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https：//www.rfc-editor.org/情報/ RFC4566>。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, <https://www.rfc-editor.org/info/rfc4568>.
[RFC4568] Andreasen、F.、Baugher、M.、D. Wing、Media Streamsの「セッション記述プロトコル（SDP）セキュリティ説明」、RFC 4568、DOI 10.17487 / RFC4568、2006年7月、<https：// www。rfc-editor.org/info/rfc4568>。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <https://www.rfc-editor.org/info/rfc4588>.
[RFC4588] Rey、J.、Leon、D.、Miyazaki、A.、Varsa、V.およびR.Hakenberg、「RTP再送ペイロードフォーマット」、RFC 4588、DOI 10.17487 / RFC4588、2006年7月、<https：//www.rfc-editor.org/info/rfc4588>。
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC5104] Wenger、S、Chandra、U.、Westerlund、M.、およびB.Burman、「フィードバック付きRTPオーディオビジュアルプロファイル（AVPF）」、RFC 5104、DOI 10.17487 / RFC5104、2月2008年、<https://www.rfc-editor.org/info/rfc5104>。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5109] Li、A.、ED。、「汎用フォワードエラー訂正のためのRTPペイロード形式」、RFC 5109、DOI 10.17487 / RFC5109、2007年12月、<https：//www.rfc-editor.org/info/rfc5109>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P.、およびD. Wing、「Stun（Stun）のセッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<https：//www.rfc-editor.org/info/rfc5389>。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.
[RFC5764] MCGREW、D.およびE. RESCORLA、セキュアリアルタイムトランスポートプロトコル（SRTP） "、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<HTTPS）：//www.rfc-editor.org/info/rfc5764>。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <https://www.rfc-editor.org/info/rfc5888>.
[RFC5888] Camarillo、G.およびH.Schulzrinne「セッション記述プロトコル（SDP）グループ化フレームワーク」、RFC 5888、DOI 10.17487 / RFC5888、2010年6月、<https：//www.rfc-editor.org/info/RFC5888>。
[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011, <https://www.rfc-editor.org/info/rfc6465>.
[RFC6465] IVOV、E.、ED。、Marocco、E.、ED。、およびJ.Lennox、「ミキサー間のオーディオレベル表示のためのリアルタイムトランスポートプロトコル（RTP）ヘッダ拡張」、RFC 6465、DOI 10.17487 / RFC6465、2011年12月、<https://www.rfc-editor.org/info/rfc6465>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <https://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M.およびC. Perkins、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<https://www.rfc-editor.org/info/rfc7201>。
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.
[RFC7657]黒、D.、ED。P. Jones、「差別化サービス（DiffServ）およびリアルタイム通信」、RFC 7657、DOI 10.17487 / RFC 7657、2015年11月、<https：//www.rfc-editor.org/info/rfc7657>。
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, <https://www.rfc-editor.org/info/rfc7826>.
[RFC7826] Schulzrinne、H.、Rao、A.、Lanphier、R.、Westerlund、M.、M. Stiemerling、Ed。、「リアルタイムストリーミングプロトコルバージョン2.0」、RFC 7826、DOI 10.17487 / RFC7826、12月2016年、<https：//www.rfc-editor.org/info/rfc7826>。
[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016, <https://www.rfc-editor.org/info/rfc7983>.
[RFC7983] Petit-Huguenin、M.およびG.Salgueiro、データグラムトランスポート層セキュリティ（DTLS）拡張（DTLS）拡張（DTLS）拡張（DTLS））、RFC 7983、DOI 10.17487 / RFC7983、2016年9月、<https://www.rfc-editor.org/info/rfc7983>。
[RFC8088] Westerlund, M., "How to Write an RTP Payload Format", RFC 8088, DOI 10.17487/RFC8088, May 2017, <https://www.rfc-editor.org/info/rfc8088>.
[RFC8088] Westerlund、M。、「RTPペイロードフォーマットの作成方法」、RFC 8088、DOI 10.17487 / RFC8088、2017年5月、<https：//www.rfc-editor.org/info/rfc8088>。
[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, March 2017, <https://www.rfc-editor.org/info/rfc8108>.
[RFC8108] Lennox、J.、Westerlund、M.、Wu、Q.、およびC. Perkins、「単一のRTPセッションで複数のRTPストリームを送信する」、RFC 8108、DOI 10.17487 / RFC8108、2017年3月、<https：//www.rfc-editor.org/info/rfc8108>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445]ケラネン、A.、Holmberg、C.、J.Rosenberg、「インタラクティブ接続施設（氷）：ネットワークアドレス翻訳者のためのプロトコル」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
[RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, January 2021, <https://www.rfc-editor.org/info/rfc8871>.
[RFC8871] Jones、P.、Benham、D.、C. Groves、「プライバシー強化RTP会議（PERC）」、RFC 8871、DOI 10.17487 / RFC8871、<https：//www.rfc-editor.org/info/rfc8871>。
This section documents a number of reasons why using the payload type as a multiplexing point is unsuitable for most issues related to multiple RTP streams. Attempting to use payload type multiplexing beyond its defined usage has well-known negative effects on RTP, as discussed below. To use the payload type as the single discriminator for multiple streams implies that all the different RTP streams are being sent with the same SSRC, thus using the same timestamp and sequence number space. The many effects of using payload type multiplexing are as follows:
このセクションでは、ペイロードタイプを多重化ポイントとして使用する理由はいくつかあります。複数のRTPストリームに関連するほとんどの問題には不適切です。定義された使用法を超えてペイロードタイプの多重化を使用しようとすると、以下で説明するように、RTPによく知られています。複数のストリームの単一の識別子としてペイロードタイプを使用するには、すべての異なるRTPストリームが同じSSRCで送信されていることを意味し、したがって同じタイムスタンプとシーケンス番号スペースを使用します。ペイロード型多重化の使用の多くの効果は次のとおりです。
1. Constraints are placed on the RTP timestamp rate for the multiplexed media. For example, RTP streams that use different RTP timestamp rates cannot be combined, as the timestamp values need to be consistent across all multiplexed media frames. Thus, streams are forced to use the same RTP timestamp rate. When this is not possible, payload type multiplexing cannot be used.
1. 多重化メディアのRTPタイムスタンプレートに制約が配置されます。たとえば、タイムスタンプ値はすべての多重化メディアフレームにわたって一貫性がある必要があるため、さまざまなRTPタイムスタンプレートを使用するRTPストリームを組み合わせることはできません。したがって、ストリームは同じRTPタイムスタンプレートを使用することを強制されます。これが不可能な場合は、ペイロードタイプの多重化を使用できません。
2. Many RTP payload formats can fragment a media object over multiple RTP packets, like parts of a video frame. These payload formats need to determine the order of the fragments to correctly decode them. Thus, it is important to ensure that all fragments related to a frame or a similar media object are transmitted in sequence and without interruptions within the object. This can be done relatively easily on the sender side by ensuring that the fragments of each RTP stream are sent in sequence.
2. 多くのRTPペイロードフォーマットは、ビデオフレームの一部のように、複数のRTPパケットを介してメディアオブジェクトをフラグメント化することができます。これらのペイロードフォーマットは、それらを正しく復号するためのフラグメントの順序を決定する必要があります。したがって、フレームまたは類似のメディアオブジェクトに関連するすべてのフラグメントが、オブジェクト内で順番に送信されることなく送信されることを確実にすることが重要である。これは、各RTPストリームのフラグメントがシーケンスで送信されることを確認することによって、送信側に比較的簡単に行うことができます。
3. Some media formats require uninterrupted sequence number space between media parts. These are media formats where any missing RTP sequence number will result in decoding failure or invoking a repair mechanism within a single media context. The text/t140 payload format [RFC4103] is an example of such a format. These formats will need a sequence numbering abstraction function between RTP and the individual RTP stream before being used with payload type multiplexing.
3. 一部のメディアフォーマットでは、メディアパーツ間の中断のないシーケンス番号スペースが必要です。これらは、存在しないRTPシーケンス番号が復旧または1つのメディアコンテキスト内で修復メカニズムを呼び出すことになるメディアフォーマットです。TEXT / T140ペイロードフォーマット[RFC4103]は、そのような形式の例です。これらのフォーマットは、ペイロードタイプの多重化で使用される前に、RTPと個々のRTPストリーム間のシーケンス番号付け関数を必要とします。
4. Sending multiple media streams in the same sequence number space makes it impossible to determine which media stream lost a packet. Such a scenario causes difficulties, since the receiver cannot determine to which stream it should apply packet-loss concealment or other stream-specific loss-mitigation mechanisms.
4. 同じシーケンス番号スペースに複数のメディアストリームを送信すると、どのメディアストリームがパケットを失ったかを判断できません。このようなシナリオは、受信機がパケット損失の隠蔽または他のストリーム固有の損失メカニズムを適用すべきかを判断できないので、困難を引き起こす。
5. If RTP retransmission [RFC4588] is used and packet loss occurs, it is possible to ask for the missing packet(s) by SSRC and sequence number -- not by payload type. If only some of the payload type multiplexed streams are of interest, there is no way to tell which missing packet or packets belong to the stream or streams of interest, and all lost packets need to be requested, wasting bandwidth.
5. RTP再送[RFC4588]が使用され、パケットの損失が発生した場合、Payload TypeではなくSSRCおよびシーケンス番号による欠落パケットを要求することが可能です。一部のペイロードタイプの多重化ストリームのみが興味深い場合、どの欠けているパケットまたはパケットが興味のあるストリームまたはストリームに属しているかを知る方法はありません。障害物を無駄にする必要があります。
6. The current RTCP feedback mechanisms are built around providing feedback on RTP streams based on stream ID (SSRC), packet (sequence numbers), and time interval (RTP timestamps). There is almost never a field to indicate which payload type is reported, so sending feedback for a specific RTP payload type is difficult without extending existing RTCP reporting.
6. 現在のRTCPフィードバックメカニズムは、ストリームID（SSRC）、パケット（シーケンス番号）、および時間間隔（RTPタイムスタンプ）に基づいてRTPストリームに対してフィードバックを提供するように構築されています。どのペイロードタイプが報告されているかを示すためのフィールドはほとんどありませんので、既存のRTCPレポートを拡張せずに特定のRTPペイロードタイプのフィードバックを送信します。
7. The current RTCP media control messages specification [RFC5104] is oriented around controlling particular media flows, i.e., requests are done by addressing a particular SSRC. Such mechanisms would need to be redefined to support payload type multiplexing.
7. 現在のRTCPメディア制御メッセージ仕様[RFC5104]は、特定のメディアフローを制御する、すなわち特定のSSRCをアドレス指定することによって要求が行われる。そのようなメカニズムは、ペイロードタイプの多重化をサポートするように再定義する必要があります。
8. The number of payload types is inherently limited. Accordingly, using payload type multiplexing limits the number of streams that can be multiplexed and does not scale. This limitation is exacerbated if one uses solutions like RTP and RTCP multiplexing [RFC5761] where a number of payload types are blocked due to the overlap between RTP and RTCP.
8. ペイロードタイプの数は本質的に制限されています。したがって、ペイロードタイプを使用すると、多重化されているストリームの数が制限され、スケールされないストリームの数が制限されます。この制限は、RTPとRTCP多重化[RFC5761]のようなソリューションを使用すると、RTPとRTCPの間の重なりのためにブロックされます。
9. At times, there is a need to group multiplexed streams. This is currently possible for RTP sessions and SSRCs, but there is no defined way to group payload types.
9. 時々、多重化されたストリームをグループ化する必要がある。これは現在RTPセッションとSSRCSの場合が可能ですが、ペイロードタイプをグループ化するための定義された方法はありません。
10. It is currently not possible to signal bandwidth requirements per RTP stream when using payload type multiplexing.
10. ペイロードタイプの多重化を使用するときに、RTPストリームあたりの帯域幅要件をシグナリングすることはできません。
11. Most existing SDP media-level attributes cannot be applied on a per-payload-type basis and would require redefinition in that context.
11. ほとんどの既存のSDPメディアレベルの属性は、ペイロード単位で適用できず、そのコンテキストでの再定義が必要になります。
12. A legacy endpoint that does not understand the indication that different RTP payload types are different RTP streams might be slightly confused by the large amount of possibly overlapping or identically defined RTP payload types.
12. 異なるRTPペイロードタイプが異なるRTPストリームであることを理解していないレガシエンドポイントは、大量の重複または同じRTPペイロードタイプによってわずかに混乱している可能性があります。
Signaling is not an architectural consideration for RTP itself, so this discussion has been moved to an appendix. However, it is extremely important for anyone building complete applications, so it is deserving of discussion.
シグナリングはRTP自体のためのアーキテクチャ上の検討ではありませんので、この議論は付録に移動されました。ただし、完全なアプリケーションを構築する人にとって非常に重要ですので、議論に値することに値します。
We document some issues here that need to be addressed when using some form of signaling to establish RTP sessions. These issues cannot be addressed by simply tweaking, extending, or profiling RTP; rather, they require a dedicated and in-depth look at the signaling primitives that set up the RTP sessions.
RTPセッションを確立するためにいくつかの形式のシグナリングを使用するときに対処する必要があるいくつかの問題を文書化します。これらの問題は、RTPを微調整、拡張、またはプロファイリングするだけでは対処できません。むしろ、RTPセッションを設定するシグナリングプリミティブを専用で詳細な外観を必要とします。
There exist various signaling solutions for establishing RTP sessions. Many are based on SDP [RFC4566]; however, SDP functionality is also dependent on the signaling protocols carrying the SDP. The Real-Time Streaming Protocol (RTSP) [RFC7826] and the Session Announcement Protocol (SAP) [RFC2974] both use SDP in a declarative fashion, while SIP [RFC3261] uses SDP with the additional definition of offer/answer [RFC3264]. The impact on signaling, and especially on SDP, needs to be considered, as it can greatly affect how to deploy a certain multiplexing point choice.
RTPセッションを確立するためのさまざまなシグナリングソリューションがあります。多くはSDP [RFC4566]に基づいています。ただし、SDP機能はSDPを搭載したシグナリングプロトコルにも依存します。リアルタイムストリーミングプロトコル（RFC7826]とセッションアナウンスメントプロトコル（SAP）[RFC2974]はどちらも宣言的な方法でSDPを使用しますが、SIP [RFC3261]は、オファー/アンサーの追加の定義でSDPを使用します[RFC3264]。シグナリングへの影響、特にSDPでは、特定の多重化点選択方法を展開する方法に大きな影響を与える可能性があるため、考慮する必要があります。
One aspect of existing signaling protocols is that they are focused on RTP sessions or, in the case of SDP, the concept of media descriptions. A number of things are signaled at the media description level, but those are not necessarily strictly bound to an RTP session and could be of interest for signaling, especially for a particular RTP stream (SSRC) within the session. The following properties have been identified as being potentially useful for signaling, and not only at the RTP session level:
既存のシグナリングプロトコルの一態様は、それらがRTPセッションに焦点を当てていること、またはSDPの場合、メディアの説明の概念に焦点を当てていることです。多くのものがメディア記述レベルでシグナリングされますが、それらは必ずしもRTPセッションに厳密にバインドされているわけではなく、シグナリング、特にセッション内の特定のRTPストリーム（SSRC）にとって関心がある可能性があります。次のプロパティは、RTPセッションレベルだけでなく、シグナリングに潜在的に役立つと識別されています。
* Bitrate and/or bandwidth can be specified today only as an aggregate limit, or as a common "any RTP stream" limit, unless either codec-specific bandwidth limiting or RTCP signaling using Temporary Maximum Media Stream Bit Rate Request (TMMBR) messages [RFC5104] is used.
* BitRateおよび/または帯域幅は、一時最大メディアストリームビットレート要求（TMMBR）メッセージを使用してコーデック固有の帯域幅制限またはRTCPシグナリングのいずれかを指定しない限り、集計制限または共通の「任意のRTP Stream」の制限としてのみ指定できます。[RFC5104] 使用されている。
* Which SSRC will use which RTP payload type (this information will be visible in the first media packet but is sometimes useful to have before the packet arrives).
* どのSSRCがどのRTPペイロードタイプを使用するか（この情報が最初のメディアパケットに表示されますが、パケットが到着する前に有用な場合があります）。
Some of these issues are clearly SDP's problem rather than RTP limitations. However, if the aim is to deploy a solution that uses several SSRCs and contains several sets of RTP streams with different properties (encoding/packetization parameters, bitrate, etc.), putting each set in a different RTP session would directly enable negotiation of the parameters for each set. If insisting on additional SSRCs only, a number of signaling extensions are needed to clarify that there are multiple sets of RTP streams with different properties and that they in fact need to be kept different, since a single set will not satisfy the application's requirements.
これらの問題のいくつかは、RTP制限ではなく、明らかにSDPの問題です。ただし、AIMが複数のSSRCを使用し、異なるプロパティ（エンコード/パケット化パラメータ、ビットレートなど）を持ついくつかのセットのRTPストリームを含むソリューションを展開する場合は、異なるRTPセッションに各セットを入れると、直接のネゴシエーションができます。各セットのパラメータ。追加のSSRCSのみを主張する場合、単一のセットがアプリケーションの要件を満たさないため、異なるプロパティを持つ複数のセットのRTPストリームが異なる必要があることを明確にするためにいくつかのシグナリング拡張が必要です。
For some parameters, such as RTP payload type, resolution, and frame rate, an SSRC-linked mechanism has been proposed in [RFC8851].
RTPペイロードタイプ、解像度、およびフレームレートなどのパラメータによっては、[RFC8851]にSSRCリンクメカニズムが提案されています。
SDP uses the "m=" line to both delineate an RTP session and specify the top-level media type: audio, video, text, image, application. This media type is used as the top-level media type for identifying the actual payload format and is bound to a particular payload type using the "a=rtpmap:" attribute. This binding has to be loosened in order to use SDP to describe RTP sessions containing multiple top-level media types.
SDPは "M ="行を使用してRTPセッションを描写し、最上位メディアタイプ：オーディオ、ビデオ、テキスト、イメージ、アプリケーションを指定します。このメディアタイプは、実際のペイロードフォーマットを識別するための最上位メディアタイプとして使用され、 "a = rtpmap："属性を使用して特定のペイロードタイプにバインドされます。SDPを使用して複数の最上位メディアタイプを含むRTPセッションを記述するためにこのバインディングを緩める必要があります。
[RFC8843] describes how to let multiple SDP media descriptions use a single underlying transport in SDP, which allows the definition of one RTP session with different top-level media types.
[RFC8843] SDPで複数のSDPメディアの記述を単一の基礎となるトランスポートで使用できるようにする方法について説明します。これにより、さまざまな最上位メディアタイプを持つ1つのRTPセッションの定義ができます。
RTP streams being transported in RTP have a particular usage in an RTP application. In many applications to date, this usage of the RTP stream is implicitly signaled. For example, an application might choose to take all incoming audio RTP streams, mix them, and play them out. However, in more-advanced applications that use multiple RTP streams, there will be more than a single usage or purpose among the set of RTP streams being sent or received. RTP applications will need to somehow signal this usage. The signaling that is used will have to identify the RTP streams affected by their RTP-level identifiers, which means that they have to be identified by either their session or their SSRC + session.
RTPでトランスポートされているRTPストリームは、RTPアプリケーションで特定の用途を持ちます。今日までの多くのアプリケーションでは、RTPストリームのこの使用法は暗黙的にシグナリングされています。たとえば、アプリケーションは、受信したすべてのオーディオRTPストリームを取り、それらを混在させて再生することを選択できます。ただし、複数のRTPストリームを使用するより高度なアプリケーションでは、送信または受信されているRTPストリームのセットの中で単一の使用状況または目的が多いです。RTPアプリケーションはどういうわけかこの使用法をシグナルにする必要があります。使用されるシグナリングは、RTPレベルの識別子によって影響を受けるRTPストリームを識別する必要があります。つまり、それらはそれらのセッションまたはそれらのSSRCセッションによって識別されなければならないことを意味します。
In some applications, the receiver cannot utilize the RTP stream at all before it has received the signaling message describing the RTP stream and its usage. In other applications, there exists a default handling method that is appropriate.
一部のアプリケーションでは、受信側はRTPストリームとその使用法を記述するシグナリングメッセージを受信する前に、RTPストリームをすべて利用することはできません。他のアプリケーションでは、適切なデフォルトの処理方法が存在します。
If all RTP streams in an RTP session are to be treated in the same way, identifying the session is enough. If SSRCs in a session are to be treated differently, signaling needs to identify both the session and the SSRC.
RTPセッション内のすべてのRTPストリームが同じ方法で扱われることになっている場合は、セッションを識別することが十分です。セッション内のSSRCを別の方法で扱う必要がある場合、シグナリングはセッションとSSRCの両方を識別する必要があります。
If this signaling affects how any RTP central node, like an RTP mixer or translator that selects, mixes, or processes streams, treats the streams, the node will also need to receive the same signaling to know how to treat RTP streams with different usages in the right fashion.
このシグナリングがRTPミキサーまたはトランスレータのようなRTP Centralノードがどのように影響するか、ストリームを選択、ミックス、またはプロセスする翻訳者のような、ストリームを扱うと、ノードは同じシグナリングを受信する必要があります。正しい方法。
Acknowledgments
謝辞
The authors would like to acknowledge and thank Cullen Jennings, Dale R. Worley, Huang Yihong (Rachel), Benjamin Kaduk, Mirja Kühlewind, and Vijay Gurbani for review and comments.
著者らは、Cullen Jennings、Dale R. Worley、Huang Yihong（Rachel）、Benjamin Kaduk、MirjaKühlewind、Vijay Gurbani、レビューやコメントを承認します。
Contributors
貢献者
Hui Zheng (Marvin) contributed to WG draft versions -04 and -05 of the document.
Hui Zheng（Marvin）は、DocumentのWG Draft versions -04と-05に貢献しました。
Authors' Addresses
著者の住所
Magnus Westerlund Ericsson Torshamnsgatan 23 SE-164 80 Kista Sweden
Magnus Westerlund Ericsson Torshamnsgatan 23 SE-164 80キスタスウェーデン
Email: magnus.westerlund@ericsson.com
Bo Burman Ericsson Gronlandsgatan 31 SE-164 60 Kista Sweden
Bo Burman Ericsson Gronlandsgatan 31 SE-164 60キスタスウェーデン
Email: bo.burman@ericsson.com
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom
Colin Perkins Glasgow大学コンピューティングサイエンスグラスゴーG12 8QQイギリス
Email: csp@csperkins.org
Harald Tveit Alvestrand Google Kungsbron 2 SE-11122 Stockholm Sweden
Harald Tveit Alvestrand Google Kungsbroon 2 SE-11122ストックホルムスウェーデン
Email: harald@alvestrand.no
Roni Even
ロニ
Email: ron.even.tlv@gmail.com