[要約] RFC 8853は、SDPとRTPセッションでのSimulcastの使用に関する標準化された手法を提供します。このRFCの目的は、複数のビットレートや解像度のストリームを同時に送信するための一貫した方法を定義することです。
Internet Engineering Task Force (IETF) B. Burman
Request for Comments: 8853 M. Westerlund
Category: Standards Track Ericsson
ISSN: 2070-1721 S. Nandakumar
M. Zanaty
Cisco
January 2021
Using Simulcast in Session Description Protocol (SDP) and RTP Sessions
セッション記述プロトコル（SDP）およびRTPセッションのSimulcastの使用
Abstract
概要
In some application scenarios, it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in the Session Description Protocol (SDP). The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source and makes an extension to SDP to indicate that those RTP streams are different simulcast formats of that media source. The SDP extension consists of a new media-level SDP attribute that expresses capability to send and/or receive simulcast RTP streams.
いくつかのアプリケーションシナリオでは、異なるRTPストリームに複数の異なる符号化バージョンの同じメディアソースを送信することが望ましい場合がある。これはSimulcastと呼ばれます。このドキュメントでは、RTPでSimulcastを実行する方法と、セッション記述プロトコル（SDP）でそれをシグナリングする方法について説明します。説明された解決策は、RTP / RTCP識別方法を使用して、同じメディアソースに属するRTPストリームを識別し、それらのRTPストリームがそのメディアソースの異なるSimulcastフォーマットであることを示すためにSDPに拡張する。SDP拡張は、Simulcast RTPストリームを送信および/または受信する機能を表現する新しいメディアレベルのSDP属性で構成されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8853.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8853で入手できます。
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. Requirements Language
3. Use Cases
3.1. Reaching a Diverse Set of Receivers
3.2. Application-Specific Media Source Handling
3.3. Receiver Media-Source Preferences
4. Overview
5. Detailed Description
5.1. Simulcast Attribute
5.2. Simulcast Capability
5.3. Offer/Answer Use
5.3.1. Generating the Initial SDP Offer
5.3.2. Creating the SDP Answer
5.3.3. Offerer Processing the SDP Answer
5.3.4. Modifying the Session
5.4. Use with Declarative SDP
5.5. Relating Simulcast Streams
5.6. Signaling Examples
5.6.1. Single-Source Client
5.6.2. Multisource Client
5.6.3. Simulcast and Redundancy
6. RTP Aspects
6.1. Outgoing from Endpoint with Media Source
6.2. RTP Middlebox to Receiver
6.2.1. Media-Switching Mixer
6.2.2. Selective Forwarding Middlebox
6.3. RTP Middlebox to RTP Middlebox
7. Network Aspects
7.1. Bitrate Adaptation
8. Limitation
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Requirements
Acknowledgements
Contributors
Authors' Addresses
Most of today's multiparty video-conference solutions make use of centralized servers to reduce the bandwidth and CPU consumption in the endpoints. Those servers receive RTP streams from each participant and send some suitable set of possibly modified RTP streams to the rest of the participants, which usually have heterogeneous capabilities (screen size, CPU, bandwidth, codec, etc.). One of the biggest issues is how to perform RTP stream adaptation to different participants' constraints with the minimum possible impact on both video quality and server performance.
今日のマルチパーティビデオ会議ソリューションのほとんどは、エンドポイント内の帯域幅とCPUの消費量を削減するために集中型サーバーを使用しています。これらのサーバーは各参加者からRTPストリームを受け取り、通常、いくつかの適切なSETのあるセットを残りの参加者に送信します。これは通常異種機能（画面サイズ、CPU、帯域幅、コーデックなど）を持ちます。最大の問題の1つは、ビデオ品質とサーバーのパフォーマンスの両方に最小限の影響を及ぼす可能性のある異なる参加者の制約にRTPストリーム適応を実行する方法です。
Simulcast is defined in this memo as the act of simultaneously sending multiple different encoded streams of the same media source -- e.g., the same video source encoded with different video-encoder types or image resolutions. This can be done in several ways and for different purposes. This document focuses on the case where it is desirable to provide a media source as multiple encoded streams over RTP [RFC3550] towards an intermediary so that the intermediary can provide the wanted functionality by selecting which RTP stream(s) to forward to other participants in the session, and more specifically how the identification and grouping of the involved RTP streams are done.
シマールキャストは、同じメモーションソースの複数の異なる符号化ストリームを同時に送信する動作として定義されている。例えば、異なるビデオエンコーダタイプまたは画像解像度で符号化された同じビデオソース。これはいくつかの方法で、さまざまな目的で行うことができます。この文書は、仲介者が他の参加者に転送するためにどのRTPストリームをどのRTPストリームを選択することによって仲介者に向かってRTP [RFC3550]を介してメディアソースを複数の符号化ストリームとして提供することが望ましい場合に焦点を合わせている。そのセッション、そしてより具体的には、関与するRTPストリームの識別およびグループ化がどのように行われるか。
The intended scope of the defined mechanism is to support negotiation and usage of simulcast when using SDP offer/answer and media transport over RTP. The media transport topologies considered are point-to-point RTP sessions, as well as centralized multiparty RTP sessions, where a media sender will provide the simulcasted streams to an RTP middlebox or endpoint, and middleboxes may further distribute the simulcast streams to other middleboxes or endpoints. Simulcast could be used point to point between middleboxes as part of a distributed multiparty scenario. Usage of multicast or broadcast transport is out of scope and left for future extensions.
定義されたメカニズムの意図された範囲は、SDPオファー/回答とRTPを介してメディアトランスポートを使用する場合のSimulcastのネゴシエーションと使用をサポートすることです。考慮されるメディアトランスポートトポロジは、ポイントツーポイントRTPセッション、および集中マルチパーティRTPセッションであり、メディア送信者はSimulcastedストリームをRTPミドルボックスまたはエンドポイントに提供し、ミドルボックスはさらにSimulcastストリームを他のミドルボックスにさらに配布することもできます。エンドポイントSimulcastは、分散型マルチパーティシナリオの一部としてミドルボックス間を指すポイントを使用できます。マルチキャストまたはブロードキャストトランスポートの使用は範囲外で、将来の拡張のために残されています。
This document describes a few scenarios that motivate the use of simulcast and also defines the needed RTP/RTCP and SDP signaling for it.
このドキュメントでは、Simulcastの使用をやると、必要なRTP / RTCPとSDPシグナリングを定義するいくつかのシナリオについて説明します。
This document makes use of the terminology defined in "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources" [RFC7656] and "RTP Topologies" [RFC7667]. The following terms are especially noted or here defined:
この文書は、「リアルタイムトランスポートプロトコル（RTP）ソースのためのセマンティクスとメカニズムの分類」「RFC7656」と「RTPトポロジ」[RFC7667]で定義されている用語を利用しています。以下の用語が特に注目されているか、ここで定義されています。
RTP mixer: An RTP middlebox, in the wide sense of the term, encompassing Sections 3.6 to 3.9 of [RFC7667].
RTPミキサー：RTPミドルボックス、この用語の広い意味で、[RFC7667]のセクション3.6から3.9を含みます。
RTP session: An association among a group of participants communicating with RTP, as defined in [RFC3550] and amended by [RFC7656].
RTPセッション：[RFC3550]で定義され、[RFC7656]によって定義されているように、RTPと通信している参加者のグループ間の関連付け。
RTP stream: A stream of RTP packets containing media data, as defined in [RFC7656].
RTP Stream：[RFC7656]で定義されているように、メディアデータを含むRTPパケットのストリーム。
RTP switch: A common short term for the terms "switching RTP mixer", "source projecting middlebox", and "video switching Multipoint Control Unit (MCU)", as discussed in [RFC7667].
RTPスイッチ：[RFC7667]で説明したように、「RTPミキサースイッチング」、「ソース投影ミドルボックス」、「ビデオスイッチングマルチポイント制御ユニット（MCU）」という用語の一般的な短期間。
Simulcast stream: One encoded stream or dependent stream from a set of concurrently transmitted encoded streams and optional dependent streams, all sharing a common media source, as defined in [RFC7656]. For example, HD and thumbnail video simulcast versions of a single media source sent concurrently as separate RTP streams.
Simulcastストリーム：一連の同時送信された符号化されたストリームとオプションの依存ストリームからの1つのエンコードされたストリームまたは従属ストリームは、[RFC7656]で定義されているように、共通のメディアソースを共有します。たとえば、HDとThumbnailのビデオのSimulcastのシムラキャストバージョンは、別々のRTPストリームとして同時に送信されます。
Simulcast format: Different formats of a simulcast stream serve the same purpose as alternative RTP payload types in nonsimulcast SDP: to allow multiple alternative media formats for a given RTP stream. As for multiple RTP payload types on the "m=" line in offer/answer [RFC3264], any one of the negotiated alternative formats can be used in a single RTP stream at a given point in time, but not more than one (based on RTP timestamp). What format is used can change dynamically from one RTP packet to another.
Simulcast形式：Simulcastストリームの異なる形式は、Nonsimulcast SDPの代替RTPペイロードタイプと同じ目的になります。特定のRTPストリームの複数の代替メディアフォーマットを許可する。オファー/アンサー[RFC3264]の「M =」回線での複数のRTPペイロードタイプについては、ネゴシエートされた代替フォーマットのいずれかが、特定の時点で1つのRTPストリームで使用できますが、1つ以下ではありません。RTPタイムスタンプで）。どの形式が使用されているのは、あるRTPパケットから別のRTPパケットへの動的に変更できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
The use cases of simulcast described in this document relate to a multiparty communication session where one or more central nodes are used to adapt the view of the communication session towards individual participants and facilitate the media transport between participants. Thus, these cases target the RTP mixer type of topology.
この文書に記載されているSimulcastのユースケースは、1つ以上の中央ノードが個々の参加者に向かって通信セッションのビューを適応させ、参加者間のメディアトランスポートを容易にするために使用されるマルチパーティコミュニケーションセッションに関する。したがって、これらのケースはRTPミキサータイプのトポロジをターゲットにします。
There are two principal approaches for an RTP mixer to provide this adapted view of the communication session to each receiving participant:
RTPミキサーには2つの主要なアプローチがあり、この適応された通信セッションの受信側の参加者に提供されています。
* Transcoding (decoding and re-encoding) received RTP streams with characteristics adapted to each receiving participant. This often includes mixing or composition of media sources from multiple participants into a mixed media source originated by the RTP mixer. The main advantage of this approach is that it achieves close-to-optimal adaptation to individual receiving participants. The main disadvantages are that it can be very computationally expensive to the RTP mixer, typically degrades media Quality of Experience (QoE) such as creating end-to-end delay for the receiving participants, and requires the RTP mixer to have access to media content.
* トランスコーディング（復号化および再符号化）受信した各参加者に適合された特性を有するRTPストリームを受信する。これは、複数の参加者からのメディアソースのミキシングまたは構成をRTPミキサーによって発生させた混合媒体源に含めることが多い。このアプローチの主な利点は、それが個人の受信者への最適な適応を達成することです。主な欠点は、RTPミキサーにとって非常に計算的に高価になる可能性があります。通常、受信側の参加者のためのエンドツーエンド遅延を作成するなどのメディア品質（QoE）を劣化させ、RTPミキサーがメディアコンテンツにアクセスできるようにする必要があることです。。
* Switching a subset of all received RTP streams or substreams to each receiving participant, where the used subset is typically specific to each receiving participant. The main advantages of this approach are that it is computationally cheap to the RTP mixer, has very limited impact on media QoE, and does not require the RTP mixer to have (full) access to media content. The main disadvantage is that it can be difficult to combine a subset of received RTP streams into a perfect fit for the resource situation of a receiving participant. It is also a disadvantage that sending multiple RTP streams consumes more network resources from the sending participant to the RTP mixer.
* 受信したすべての参加者に、受信したすべてのRTPストリームまたはサブセットのサブセットを切り替えると、使用されるサブセットは通常各受信側の参加者に固有のものです。このアプローチの主な利点は、それがRTPミキサーに対して計算的に安く、メディアQoEへの影響は非常に限られており、RTPミキサーがメディアコンテンツにアクセスする必要はありません。主な欠点は、受信したRTPストリームのサブセットを受信した参加者のリソース状況に完全に適合させることが困難であることである。複数のRTPストリームを送信することもまた、送信参加者からRTPミキサーへのより多くのネットワークリソースを消費するという欠点である。
The use of simulcast relates to the latter approach, where it is more important to reduce the load on the RTP mixer and/or minimize QoE impact than to achieve an optimal adaptation of resource usage.
Simulcastの使用は後者のアプローチに関連しており、RTPミキサーの負荷を軽減すること、および/またはリソース使用量の最適な適応を達成するためよりもQOEの影響を最小限に抑えることが重要です。
The media sources provided by a sending participant potentially need to reach several receiving participants that differ in terms of available resources. The receiver resources that typically differ include, but are not limited to:
送信参加者によって提供されるメディアソースは、利用可能なリソースに関して異なるいくつかの受信側参加者に到達する必要がある。通常異なる受信側リソースには、以下が含まれますが、これらに限定されません。
Codec: This includes codec type (such as RTP payload format MIME type) and can include codec configuration. A couple of codec resources that differ only in codec configuration will be "different" if they are somehow not "compatible", such as if they differ in video codec profile or the transport packetization configuration.
コーデック：これにはコーデックタイプ（RTPペイロードフォーマットMIMEタイプなど）が含まれており、コーデック構成を含めることができます。コーデック構成においてのみ異なる数のコーデックリソースは、ビデオコーデックプロファイルまたはトランスポートパケット化構成が異なる場合など、「互換性」でない場合は「異なる」になります。
Sampling: This relates to how the media source is sampled, in spatial as well as temporal domain. For video streams, spatial sampling affects image resolution, and temporal sampling affects video frame rate. For audio, spatial sampling relates to the number of audio channels, and temporal sampling affects audio bandwidth. This may be used to suit different rendering capabilities or needs at the receiving endpoints.
サンプリング：これは、メディアソースがどのようにサンプリングされているか、および時間領域だけでなく、その空間内でも関連しています。ビデオストリームの場合、空間サンプリングは画像の解像度に影響を与え、時間的サンプリングはビデオフレームレートに影響します。オーディオの場合、空間サンプリングはオーディオチャネルの数に関連しており、時間サンプリングはオーディオ帯域幅に影響します。これは、受信エンドポイントでさまざまなレンダリング機能やニーズに合わせて使用できます。
Bitrate: This relates to the number of bits sent per second to transmit the media source as an RTP stream, which typically also affects the QoE for the receiving user.
bitrate：これは、メディアソースをRTPストリームとして送信するために毎秒送信されたビット数に関連しています。これは通常、受信ユーザーのQoEにも影響します。
Letting the sending participant create a simulcast of a few differently configured RTP streams per media source can be a good trade-off when using an RTP switch as middlebox, instead of sending a single RTP stream and using an RTP mixer to create individual transcodings to each receiving participant.
送信側に、メディアソースごとにRTPスイッチを使用し、RTPミキサを使用して各トランスコードを使用するのではなく、MidgleBoxとしてRTPスイッチを使用する場合は、MediderBoxとしてRTPスイッチを使用する場合は、送信された参加者に送信された参加者がMiddleBoxとしてRTPスイッチを使用する場合は、優れたトレードオフにすることができます。参加者を受け取る。
This requires that the receiving participants can be categorized in terms of available resources and that the sending participant can choose a matching configuration for a single RTP stream per category and media source. For example, a set of receiving participants differ only in screen resolution; some are able to display video with at most 360p resolution, and some support 720p resolution. A sending participant can then reach all receivers with best possible resolution by creating a simulcast of RTP streams with 360p and 720p resolution for each sent video media source.
これには、受信側の参加者が利用可能なリソースに関して分類され、送信参加者がカテゴリとメディアソースごとに単一のRTPストリームのマッチング構成を選択できることが必要です。たとえば、受信した参加者のセットはスクリーンの解像度だけでは異なります。いくつかは、最大360pの解像度でビデオを表示することができ、サポート720pの解像度をサポートします。次に、送信された参加者は、送信されたビデオメディアソースごとに360pと720pの解像度を持つRTPストリームのシマールキャストを作成することで、可能な限り最良の解像度ですべての受信機に到達できます。
The maximum number of simulcasted RTP streams that can be sent is mainly limited by the amount of processing and uplink network resources available to the sending participant.
送信できるSimulcasted RTPストリームの最大数は、主に送信された参加者が利用可能な処理量およびアップリンクネットワークリソースによって制限されます。
The application logic that controls the communication session may include special handling of some media sources. It is, for example, commonly the case that the media from a sending participant is not sent back to itself.
通信セッションを制御するアプリケーションロジックは、いくつかのメディアソースの特別な処理を含み得る。例えば、送信された参加者からのメディアがそれ自体に返送されない場合である。
It is also common that a currently active speaker participant is shown in larger size or higher quality than other participants (the sampling or bitrate aspects of Section 3.1) in a receiving client. Many conferencing systems do not send the active speaker's media back to the sender itself, which means there is some other participant's media that instead is forwarded to the active speaker -- typically the previous active speaker. This way, the previously active speaker is needed both in larger size (to current active speaker) and in small size (to the rest of the participants), which can be solved with a simulcast from the previously active speaker to the RTP switch.
現在アクティブなスピーカー参加者が、受信側クライアント内の他の参加者（セクション3.1のサンプリングまたはビットレートの側面）よりも大きいサイズ以上の品質で示されていることも一般的です。多くの会議システムは、アクティブなスピーカーのメディアを送信者自体に返送しません。つまり、代わりにアクティブなスピーカー - 通常は前のアクティブスピーカーに転送される他の参加者のメディアがあることを意味します。このようにして、以前にアクティブなスピーカーは、より大きなサイズ（現在のアクティブスピーカーへ）および小さいサイズ（参加者の残りの部分へ）の両方で必要とされており、これまで以前にアクティブなスピーカーからRTPスイッチへのシマールキャストで解決できます。
The application logic that controls the communication session may allow receiving participants to state preferences on the characteristics of the RTP stream they like to receive, for example in terms of the aspects listed in Section 3.1. Sending a simulcast of RTP streams is one way of accommodating receivers with conflicting or otherwise incompatible preferences.
通信セッションを制御するアプリケーションロジックは、受信したいRTPストリームの特性について、例えばセクション3.1に列挙されている態様に関して受信したいRTPストリームの特性に関する嗜好を述べることを可能にし得る。RTPストリームのシムランスを送信することは、矛盾する、または互換性のない好みで受信機を収容する1つの方法です。
This memo defines SDP [RFC4566] signaling that covers the above described simulcast use cases and functionalities. A number of requirements for such signaling are elaborated in Appendix A.
このメモは、上記のSimulcastの使用例と機能をカバーするSDP [RFC4566]シグナリングを定義します。そのようなシグナリングに対するいくつかの要件は付録Aで詳述されている。
The Restriction Identifier (RID) mechanism, as defined in [RFC8851], enables an SDP offerer or answerer to specify a number of different RTP stream restrictions for a rid-id by using the "a=rid" line. Examples of such restrictions are maximum bitrate, maximum spatial video resolution (width and height), maximum video frame rate, etc. Each rid-id may also be restricted to use only a subset of the RTP payload types in the associated SDP media description. Those RTP payload types can have their own configurations and parameters affecting what can be sent or received, using the "a=fmtp" line as well as other SDP attributes.
[RFC8851]で定義されている制限識別子（RID）メカニズムは、SDPオファーまたは回答者が「A = RID」回線を使用してRID-IDに対してさまざまなRTPストリーム制限の数を指定できます。そのような制限の例は、最大ビットレート、最大空間ビデオ解像度（幅および高さ）、最大ビデオフレームレートなどである。各RID - IDはまた、関連するSDPメディア記述内のRTPペイロードタイプのサブセットのみを使用するように制限され得る。これらのRTPペイロードタイプは、 "A = FMTP"行と他のSDP属性を使用して、送受信できるものに影響を与える独自の構成とパラメータを持つことができます。
A new SDP media-level attribute, "a=simulcast", is defined. The attribute describes, independently for "send" and "receive" directions, the number of simulcast RTP streams as well as potential alternative formats for each simulcast RTP stream. Each simulcast RTP stream, including alternatives, is identified using the RID identifier (rid-id), defined in [RFC8851].
新しいSDPメディアレベルの属性 "A = Simulcast"が定義されています。属性は、「送信」の方向、「受信」の方向、Simulcast RTPストリームの数、および各Simulcast RTPストリームの潜在的な代替フォーマットのために独立して記述されます。選択肢を含む各Simulcast RTPストリームは、[RFC8851]で定義されているRID ID（RID-ID）を使用して識別されます。
a=simulcast:send 1;2,3 recv 4
If this line is included in an SDP offer, the "send" part indicates the offerer's capability and proposal to send two simulcast RTP streams. Each simulcast stream is described by one or more RTP stream identifiers (rid-ids), and each group of rid-ids for a simulcast stream is separated by a semicolon (";"). When a simulcast stream has multiple rid-ids that are separated by a comma (","), they describe alternative representations for that particular simulcast RTP stream. Thus, the "send" part shown above is interpreted as an intention to send two simulcast RTP streams. The first simulcast RTP stream is identified and restricted according to rid-id 1. The second simulcast RTP stream can be sent as two alternatives, identified and restricted according to rid-ids 2 and 3. The "recv" part of the line shown here indicates that the offerer desires to receive a single RTP stream (no simulcast) according to rid-id 4.
この行がSDPオファーに含まれている場合、「送信」部分は、2つのSimulcast RTPストリームを送信するためのオファーの機能と提案を示します。各Simulcastストリームは、1つ以上のRTPストリーム識別子（RID-ID）によって記述され、SimulcastストリームのRID-IDの各グループはセミコロン（ ";"）で区切られています。Simulcastストリームにコンマ（ "、"）で区切られた複数のRID-IDがある場合、それらはその特定のSimulcast RTPストリームの代替表現を説明します。したがって、上記の「送信」部分は、2つのSimulcast RTPストリームを送信する意図として解釈されます。最初のSimulcast RTPストリームはRID-ID 1に従って識別され制限されています.Simplast RTPストリームは、RID-ID 2と3に従って識別され制限された2つの選択肢として送信できます。ここに示す行の「RECV」部分提供者がRID-ID 4に従って単一のRTPストリーム（Simulcastなし）を受信したいことを示します。
A more complete example SDP-offer media description is provided in Figure 1.
より完全な例示的なSDP-Offerメディアの説明は図1に提供されています。
m=video 49300 RTP/AVP 97 98 99
a=rtpmap:97 H264/90000
a=rtpmap:98 H264/90000
a=rtpmap:99 VP8/90000
a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000
a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600
a=fmtp:99 max-fs=240; max-fr=30
a=rid:1 send pt=97;max-width=1280;max-height=720
a=rid:2 send pt=98;max-width=320;max-height=180
a=rid:3 send pt=99;max-width=320;max-height=180
a=rid:4 recv pt=97
a=simulcast:send 1;2,3 recv 4
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
Figure 1: Example Simulcast Media Description in Offer
図1：オファーのSimulcastメディアの例の説明
The SDP media description in Figure 1 can be interpreted at a high level to say that the offerer is capable of sending two simulcast RTP streams: one H.264 encoded stream in up to 720p resolution, and one additional stream encoded as either H.264 or VP8 with a maximum resolution of 320x180 pixels. The offerer can receive one H.264 stream with maximum 720p resolution.
図1のSDPメディアの説明は、オファーが2つのSimulcast RTPストリームを送信できるようにするために、ハイレベルで解釈できます.1つのH.264符号化ストリーム、最大720pの解像度で1つの追加のストリームがH.264としてエンコードされています。最大解像度320×180ピクセルのVP8。オファーは最大720pの解像度を持つ1つのH.264ストリームを受け取ることができます。
The receiver of this SDP offer can generate an SDP answer that indicates what it accepts. It uses the "a=simulcast" attribute to indicate simulcast capability and specify what simulcast RTP streams and alternatives to receive and/or send. An example of such an answering "a=simulcast" attribute, corresponding to the above offer, is:
このSDPオファーの受信者は、受け入れたものを示すSDP回答を生成できます。それは "a = simulcast"属性を使用してSimulcast機能を示し、どのSimulcast RTPストリームと受信および/または送信するかを指定します。上記のオファーに対応するそのような答え "a = simulcast"属性の例は、次のとおりです。
a=simulcast:recv 1;2 send 4
With this SDP answer, the answerer indicates in the "recv" part that it wants to receive the two simulcast RTP streams. It has removed an alternative that it doesn't support (rid-id 3). The "send" part confirms to the offerer that it will receive one stream for this media source according to rid-id 4. The corresponding, more complete example SDP answer media description could look like Figure 2.
このSDPの回答を使用すると、回答者は2つのSimulcast RTPストリームを受信したい「RECV」部分を示します。それはサポートされていない代替手段を削除しました（RID-ID 3）。「送信」部分は、RID-ID 4に従って、このメディアソースの1つのストリームを受信することをオファーに確認します。対応する、より完全な例示的なSDP回答メディアの説明は、図2のようになります。
m=video 49674 RTP/AVP 97 98
a=rtpmap:97 H264/90000
a=rtpmap:98 H264/90000
a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000
a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600
a=rid:1 recv pt=97;max-width=1280;max-height=720
a=rid:2 recv pt=98;max-width=320;max-height=180
a=rid:4 send pt=97
a=simulcast:recv 1;2 send 4
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
Figure 2: Example Simulcast Media Description in Answer
図2：Simulcastメディアの例の例
It is assumed that a single SDP media description is used to describe a single media source. This is aligned with the concepts defined in [RFC7656] and will work in a WebRTC context, both with and without BUNDLE grouping of media descriptions [RFC8843].
単一のSDPメディアの説明が単一のメディアソースを記述するために使用されると仮定されます。これは[RFC7656]で定義されている概念と整列し、メディア記述のバンドル・グループ化の有無にかかわらず、WebRTCのコンテキストで機能します[RFC8843]。
To summarize, the "a=simulcast" line describes "send"- and "receive"- direction simulcast streams separately. Each direction can in turn describe one or more simulcast streams, separated by semicolons. The identifiers describing simulcast streams on the "a=simulcast" line are rid-ids, as defined by "a=rid" lines in [RFC8851]. Each simulcast stream can be offered as a list of alternative rid-ids, with each alternative separated by a comma as shown in the example offer in Figure 1. A detailed specification can be found in Section 5, and more detailed examples are outlined in Section 5.6.
要約すると、「A = Simulcast」行には「送信」と「受信」方向Simulcastストリームを別々に説明します。各方向には、セミコロンで区切られた1つ以上のSimulcastストリームを次に説明できます。"A = Simulcast"行のSimulcastストリームを記述する識別子は、[RFC8851]の「A = RID」行で定義されているRID-IDです。各Simulcastストリームは、図1の例のオファーの例に示されているように、各代替案がカンマで区切られて、代替のRID-IDのリストとして提供することができます。詳細な仕様はセクション5にあります。5.6。
This section provides further details to the overview in Section 4. First, formal syntax is provided (Section 5.1), followed by the rest of the SDP attribute definition in Section 5.2. "Relating Simulcast Streams" (Section 5.5) provides the definition of the RTP/RTCP mechanisms used. The section concludes with a number of examples.
このセクションでは、セクション4の概要について詳しく説明します。「Simulcast Streamsの関連」（セクション5.5）は、使用されるRTP / RTCPメカニズムの定義を提供します。セクションはいくつかの例で終わります。
This document defines a new SDP media-level "a=simulcast" attribute, with value according to the syntax in Figure 3, which uses ABNF [RFC5234] and its update, "Case-Sensitive String Support in ABNF" [RFC7405]:
このドキュメントでは、新しいSDPメディアレベルの "a = simulcast"属性が定義されています。
sc-value = ( sc-send [SP sc-recv] ) / ( sc-recv [SP sc-send] )
sc-send = %s"send" SP sc-str-list
sc-recv = %s"recv" SP sc-str-list
sc-str-list = sc-alt-list *( ";" sc-alt-list )
sc-alt-list = sc-id *( "," sc-id )
sc-id-paused = "~"
sc-id = [sc-id-paused] rid-id
; SP defined in [RFC5234]
; rid-id defined in [RFC8851]
Figure 3: ABNF for Simulcast Value
図3：Simulcast値のABNF
The "a=simulcast" attribute has a parameter in the form of one or two simulcast stream descriptions, each consisting of a direction ("send" or "recv"), followed by a list of one or more simulcast streams. Each simulcast stream consists of one or more alternative simulcast formats. Each simulcast format is identified by a simulcast stream identifier (rid-id). The rid-id MUST have the form of an RTP stream identifier, as described by "RTP Payload Format Restrictions" [RFC8851].
"a = simulcast"属性には、それぞれの方向（ "send"または "recv"）からなる1つまたは2つのSimulcastストリームの記述の形式のパラメータがあり、続いて1つ以上のSimulcastストリームのリストが続きます。各Simulcastストリームは、1つ以上の代替Simulcast形式で構成されています。各Simulcast形式は、Simulcast Stream Identifier（RID-ID）によって識別されます。RID-IDは、「RTPペイロード形式の制限事項」[RFC8851]で説明されているように、RTPストリーム識別子の形式を持たなければなりません。
In the list of simulcast streams, each simulcast stream is separated by a semicolon (";"). Each simulcast stream can, in turn, be offered in one or more alternative formats, represented by rid-ids, separated by commas (","). Each rid-id can also be specified as initially paused [RFC7728], indicated by prepending a "~" to the rid-id. The reason to allow separate initial pause states for each rid-id is that pause capability can be specified individually for each RTP payload type referenced by a rid-id. Since pause capability specified via the "a=rtcp-fb" attribute applies only to specified payload types, and a rid-id specified by "a=rid" can refer to multiple different payload types, it is unfeasible to pause streams with rid-id where any of the related RTP payload type(s) do not have pause capability.
Simulcastストリームのリストでは、各Simulcastストリームはセミコロン（ ";"）で区切られています。各Simulcastストリームは、次に、RID-IDによって表される、コンマ（ "、"）で区切られた1つ以上の代替フォーマットで提供できます。各RID-IDは、「〜」をRID-IDに追加することによって示されている、最初は一時停止したときに指定することもできます[RFC7728]。RID-IDごとに別々の初期休止状態を別々に許可する理由は、RID-IDによって参照されるRTPペイロードタイプごとに個別にPAUSE機能を指定できます。"a = rtcp-fb"属性を介して指定された一時停止機能は、指定されたペイロードタイプにのみ適用され、 "A = RID"で指定されたRID-IDは複数の異なるペイロードタイプを参照できます。関連するRTPペイロードタイプのいずれかが一時停止機能を持っていないID。
Simulcast capability is expressed through a new media-level SDP attribute, "a=simulcast" (Section 5.1). The use of this attribute at the session level is undefined. Implementations of this specification MUST NOT use it at the session level and MUST ignore it if received at the session level. Extensions to this specification may define such session-level usage. Each SDP media description MUST contain at most one "a=simulcast" line.
Simulcast機能は、新しいメディアレベルのSDP属性「A = Simulcast」（セクション5.1）を介して表現されます。セッションレベルでこの属性を使用することは未定義です。この仕様の実装はセッションレベルで使用してはいけません、セッションレベルで受信された場合は無視する必要があります。この仕様への拡張は、そのようなセッションレベルの使用法を定義することができます。各SDPメディアの説明には、最大1つの "A = Simulcast"行を含める必要があります。
There are separate and independent sets of simulcast streams in the "send" and "receive" directions. When listing multiple directions, each direction MUST NOT occur more than once on the same line.
「送信」および「受信」方向には、独立した独立したシムラストフストリームがあります。複数の方向をリストするとき、各方向は同じ行に複数回発生してはいけません。
Simulcast streams using undefined rid-ids MUST NOT be used as valid simulcast streams by an RTP stream receiver. The direction for a rid-id MUST be aligned with the direction specified for the corresponding RTP stream identifier on the "a=rid" line.
未定義のRID-IDを使用したSimulcastストリームは、RTP Stream Receiverによって有効なSimulcastストリームとして使用しないでください。RID-IDの方向は、「A = RID」行の対応するRTPストリーム識別子に指定された方向と整列している必要があります。
The listed number of simulcast streams for a direction sets a limit to the number of supported simulcast streams in that direction. The order of the listed simulcast streams in the "send" direction suggests a proposed order of preference, in decreasing order: the rid-id listed first is the most preferred, and subsequent streams have progressively lower preference. The order of the listed rid-ids in the "recv" direction expresses which simulcast streams are preferred, with the leftmost being most preferred. This can be of importance if the number of actually sent simulcast streams has to be reduced for some reason.
方向に対するSimulcastストリームのリストされた数は、その方向にサポートされているSimulcastストリームの数に制限を設定します。「送信」方向に記載されているSimulcastストリームの順序は、順序を減らす順に、順位の提案順序を示唆しています。「RECV」方向のリストされたRID - IDの順序は、左端が最も好ましいであれば、どのシマラグストリームが好ましいかを表す。何らかの理由で実際に送信されたSimulcastストリームの数を減らす必要がある場合、これは重要になる可能性があります。
rid-ids that have explicit dependencies [RFC5583] [RFC8851] to other rid-ids (even in the same media description) MAY be used.
明示的な依存関係を持つRID-ID [RFC5583] [RFC8851]（同じメディアの説明でさえ）を使用することができます。
Use of more than a single, alternative simulcast format for a simulcast stream MAY be specified as part of the attribute parameters by expressing the simulcast stream as a comma-separated list of alternative rid-ids. The order of the rid-id alternatives within a simulcast stream is significant; the rid-id alternatives are listed from (left) most preferred to (right) least preferred. For the use of simulcast, this overrides the normal codec preference as expressed by format-type ordering on the "m=" line, using regular SDP rules. This is to enable a separation of general codec preferences and simulcast-stream configuration preferences. However, the choice of which alternative to use per simulcast stream is independent, and there is currently no mechanism for the offerer to force the answerer to choose the same alternative for multiple simulcast streams.
Simulcastストリームのための単一の代替Simulcastフォーマットを使用すると、Simulcastストリームを代替のRID-IDのコンマ区切りリストとして表現することによって、属性パラメータの一部として指定できます。Simulcastストリーム内のRID-ID代替案の順序は重要です。RID-IDの代替案は（左）から（右）に最も優先され、最小の好ましいものからリストされています。Simulcastを使用するには、通常のSDPルールを使用して、 "m ="行の形式タイプの順序で表されるように、通常のコーデックの設定を上書きします。これは、一般的なコーデック環境設定とSimulcast-Stream構成設定の分離を可能にすることです。ただし、Simulcastストリームごとに使用する代替の代替案が独立しており、現在は回答者に複数のSimulcastストリームに同じ代替を選択できるようにするメカニズムはありません。
A simulcast stream can use a codec defined such that the same RTP synchronization source (SSRC) can change RTP payload type multiple times during a session, possibly even on a per-packet basis. A typical example is a speech codec that makes use of formats for Comfort Noise [RFC3389] and/or dual-tone multifrequency (DTMF) [RFC4733].
Simulcastストリームは、同じRTP同期ソース（SSRC）がセッション中にRTPペイロードタイプを複数回変更できるように定義されたコーデックを使用できます。典型的な例は、快適性雑音[RFC3389]および/またはデュアルトーン多重頻度（DTMF）[RFC4733]のフォーマットを利用する音声コーデックである。
If RTP stream pause/resume [RFC7728] is supported, any rid-id MAY be prefixed by a "~" character to indicate that the corresponding simulcast stream is paused already from the start of the RTP session. In this case, support for RTP stream pause/resume MUST also be included under the same "m=" line where "a=simulcast" is included. All RTP payload types related to such an initially paused simulcast stream MUST be listed in the SDP as pause/resume capable as specified by [RFC7728] -- e.g., by using the "*" wildcard format for "a=rtcp-fb".
RTP Stream Pause / Resume [RFC7728]がサポートされている場合は、RID-IDを「〜」文字の前に「〜」文字が表示され、対応するSimulcastストリームがRTPセッションの開始からすでに一時停止されていることを示します。この場合、RTP Stream Pause / Resumeのサポートも "a = simulcast"が含まれているのと同じ "m ="行の下に含める必要があります。このような最初に一時停止したSimulcastストリームに関連するすべてのRTPペイロードタイプは、[RFC7728] - 例えば、「a = RTCP-FB」の「*」ワイルドカード形式を使用して、SDPにSDPにリストされている必要があります。
An initially paused simulcast stream in the "send" direction for the endpoint sending the SDP MUST be considered equivalent to an unsolicited locally paused stream and handled accordingly. Initially paused simulcast streams are resumed as described by the RTP pause/ resume specification. An RTP stream receiver that wishes to resume an unsolicited locally paused stream needs to know the SSRC of that stream. The SSRC of an initially paused simulcast stream can be obtained from an RTP stream sender RTCP Sender Report (SR) or Receiver Report (RR) that includes both the desired SSRC as initial SSRC in the source description (SDES) chunk, optionally a MID SDES item [RFC8843] (if used and if rid-ids are not unique across "m=" lines), and the rid-id value in an RtpStreamId RTCP SDES item [RFC8852].
SDPを送信するエンドポイントの「送信」方向の最初に一時停止されたSimulcastストリームは、迷惑なローカルに一時停止されたストリームと同等と見なされ、それに応じて処理されなければならない。最初に一時停止したSimulcastストリームは、RTP PAUSE / RESUME仕様によって説明されているように再開されます。迷惑なローカルに一時停止したストリームを再開したいRTPストリーム受信機は、そのストリームのSSRCを知る必要がある。最初に一時停止したSimulcastストリームのSSRCは、ソース記述（SDES）チャンク（SDES）チャンク、オプションでMID SDESの最初のSSRCとしてのSSRCの両方を含むRTPストリーム送信者RTCP送信者レポート（SR）または受信者レポート（RR）から取得できます。項目[RFC8843]（RID-IDが "M ="行で一意ではない場合は、RTPStreamID RTCP SDES項目[RFC8852]のRID-ID値。
If the endpoint sending the SDP includes a "recv"-direction simulcast stream that is initially paused, then the remote RTP sender receiving the SDP SHOULD put its RTP stream in an unsolicited locally paused state. The simulcast stream sender does not put the stream in the locally paused state if there are other RTP stream receivers in the session that do not mark the simulcast stream as initially paused. However, in centralized conferencing, the RTP sender usually does not see the SDP signaling from RTP receivers and cannot make this determination. The reason for requiring that an initially paused "recv" stream be considered locally paused by the remote RTP sender instead of making it equivalent to implicitly sending a pause request is that the pausing RTP sender cannot know which receiving SSRC owns the restriction when Temporary Maximum Media Stream Bit Rate Request (TMMBR) and Temporary Maximum Media Stream Bit Rate Notification (TMMBN) are used for pause/resume signaling (Section 5.6 of [RFC7728]); this is because the RTP receiver's SSRC in the "send" direction is sometimes not yet known.
SDPを送信するエンドポイントには、最初は一時停止されている「RECV」ディレクトリキャストストリームが含まれている場合、SDPを受信したリモートRTP送信者はそのRTPストリームを迷惑なローカルに一時停止状態にする必要があります。 Simulcastストリームが最初に一時停止されているようにSimulcastストリームをマークしない場合、Simulcast Stream Senderはローカルに一時停止状態にストリームを置きません。ただし、集中化された会議では、RTP送信者は通常RTP受信機からのSDPシグナリングを見ていないため、この判断を下すことはできません。最初に一時停止された「RECV」ストリームが、一時停止要求を暗黙的に送信するのに同等のものになるのではなく、リモートRTP送信者によってローカルに一時停止されることを要求するのは、一時的な最大メディアの場合にSSRCの受信が制限を所有するかを知識しないことです。ストリームビットレート要求（TMMBR）および一時最大メディアストリームビットレート通知（TMMBN）は、一時停止/再開シグナリングに使用されます（[RFC7728]のセクション5.6）。これは、「送信」方向のRTP受信機のSSRCがまだ知られていないことがあるためです。
Use of the redundant audio data format [RFC2198] could be seen as a form of simulcast for loss-protection purposes, but it is not considered conflicting with the mechanisms described in this memo and MAY therefore be used as any other format. In this case, the "red" format, rather than the carried formats, SHOULD be the one to list as a simulcast stream on the "a=simulcast" line.
冗長オーディオデータフォーマット[RFC2198]の使用は、損失保護の目的のためのSimulcastの形として見られますが、このメモに記載されているメカニズムと矛盾するとは考えられず、したがって他の形式として使用することができます。この場合、キャリアフォーマットではなく「赤い」形式は、「a = simulcast」行のSimulcastストリームとしてリストするものにする必要があります。
The media formats and corresponding characteristics of simulcast streams SHOULD be chosen such that they are different -- e.g., as different SDP formats with differing "a=rtpmap" and/or "a=fmtp" lines, or as differently defined RTP payload format restrictions. If this difference is not required, it is RECOMMENDED to use RTP duplication procedures [RFC7104] instead of simulcast. To avoid complications in implementations, a single rid-id MUST NOT occur more than once per "a=simulcast" line. Note that this does not eliminate use of simulcast as an RTP duplication mechanism, since it is possible to define multiple different rid-ids that are effectively equivalent.
シミュラキストリームのメディアフォーマットと対応する特性は、異なる「a = rtpmap」および/または「a = fmtp」行を持つ異なるSDPフォーマット、または異なるRTPペイロードフォーマットの制限として異なるように選択されるべきである。。この違いが不要な場合は、Simulcastの代わりにRTP複製プロシージャ[RFC7104]を使用することをお勧めします。実装の複雑さを避けるために、単一のRID-IDは "A = Simulcast"行に1回以上発生してはいけません。これは、効果的に同等の複数の異なるRID-IDを定義することが可能であるため、これはRTP複製メカニズムとしてのSimulcastの使用を排除しません。
Note: The inclusion of "a=simulcast" or the use of simulcast does not change any of the interpretation or Offer/Answer procedures for other SDP attributes, such as "a=fmtp" or "a=rid".
注：「A = Simulcast」を含めるかSimulcastの使用は、「a = fmtp」や「a = rid」など、他のSDP属性の解釈またはオファー/アンサープロシージャのいずれも変更されません。
An offerer wanting to use simulcast for a media description SHALL include one "a=simulcast" attribute in that media description in the offer. An offerer listing a set of receive simulcast streams and/or alternative formats as rid-ids in the offer MUST be prepared to receive RTP streams for any of those simulcast streams and/or alternative formats from the answerer.
メディア記述にSimulcastを使用したいオファーには、オファーのそのメディアの説明に1つの "a = simulcast"属性が含まれます。オファーの一組の受信Simulcastストリームおよび/または代替フォーマットをリストすることは、オファー内のRTP-IDとしてRTPストリームを受信するように準備する必要があります。
An answerer that does not understand the concept of simulcast will also not know the attribute and will remove it in the SDP answer, as defined in existing SDP offer/answer procedures [RFC3264]. Since SDP session-level simulcast is undefined in this memo, an answerer that receives an offer with the "a=simulcast" attribute on the SDP session level SHALL remove it in the answer. An answerer that understands the attribute but receives multiple "a=simulcast" attributes in the same media description SHALL disable use of simulcast by removing all "a=simulcast" lines for that media description in the answer.
Simulcastの概念を理解していない回答者も属性を知らず、既存のSDPオファー/アンサープロシージャ[RFC3264]で定義されているようにSDP回答で削除されます。SDPセッションレベルのSimulcastはこのメモで未定義以来、SDPセッションレベルの "a = simulcast"属性を使用してオファーを受信した回答者は答えでそれを削除するものとします。属性を理解しているが同じメディアの説明に複数の「A = Simulcast」属性を受信する回答者は、その答えのメディアの説明のすべての "A = Simulcast"行を削除することによってSimulcastの使用を無効にするものとします。
An answerer that does understand the attribute and wants to support simulcast in an indicated direction SHALL reverse directionality of the unidirectional direction parameters -- "send" becomes "recv" and vice versa -- and include it in the answer.
属性を理解し、指示された方向にSimulcastをサポートしたい回答者は、一方向方向パラメータの逆方向性を逆方向にしなければならない - 「SEND」は「RECV」になり、その逆にそれを答えに含める。
An answerer that receives an offer with simulcast containing an "a=simulcast" attribute listing alternative rid-ids MAY keep all the alternative rid-ids in the answer, but it MAY also choose to remove any nondesirable alternative rid-ids in the answer. The answerer MUST NOT add any alternative rid-ids in the "send" direction in the answer that were not present in the offer receive direction. The answerer MUST be prepared to receive any of the receive-direction rid-id alternatives and MAY send any of the "send"-direction alternatives that are part of the answer.
「a = simulcast」属性リストを含むSimulcastを使用してオファーを受信する回答者は、答えのすべての代替RID-IDを維持することができますが、答えの中で非随意的な代替RID-IDを削除することも選択することもできます。答え者は、オファー受信方向に存在しなかった答えで「送信」方向に代替のRID-IDを追加してはいけません。回答者は、受信方向のRID-IDの選択肢を受けるように準備されなければならず、答えの一部である「送信」の選択肢のいずれかを送ることができます。
An answerer that receives an offer with simulcast that lists a number of simulcast streams MAY reduce the number of simulcast streams in the answer, but it MUST NOT add simulcast streams.
同様のSimulcastストリームをリストするSimulcastを使用してオファーを受信する回答者は、答えのSimulcastストリームの数を減らすことができますが、Simulcastストリームを追加しないでください。
An answerer that receives an offer without RTP stream pause/resume capability MUST NOT mark any simulcast streams as initially paused in the answer.
RTP Streamの一時停止/再開機能なしでオファーを受信する回答者は、最初は答えで一時停止しているようにSimulcastストリームをマークしないでください。
An RTP stream answerer capable of pause/resume that receives an offer with RTP stream pause/resume capability MAY mark any rid-ids that refer to pause/resume capable formats as initially paused in the answer.
RTP Stream Pause / Resume Capabilityを使用してオファーを受信するPAUSE / RESUMEが可能なRTPストリーム回答者は、最初は答えで一時停止しているとおりに、一時停止/履歴書を参照するRID-IDをマークできます。
An answerer that receives indication in an offer of a rid-id being initially paused SHOULD mark that rid-id as initially paused also in the answer, regardless of direction, unless it has good reason for the rid-id not being initially paused. One reason to remove an initial pause in the answer compared to the offer could be, for example, that all "receive"-direction simulcast streams for a media source the answerer accepts in the answer would otherwise be paused.
最初に一時停止されているRID-IDのオファーで表示を受け取る回答者は、RID-IDが最初に一時停止されていないことが正当な理由を持たない限り、最初は回答にも一時停止されているとマークされるべきです。オファーと比較して答えの最初の一時停止を削除する1つの理由は、例えば、答え担当者が答えを受け入れるメディアソースのためのすべての「受信」ディレクトリキャストストリームであればうまくいけ得る。
An offerer that receives an answer without "a=simulcast" MUST NOT use simulcast towards the answerer. An offerer that receives an answer with "a=simulcast" without any rid-id in a specified direction MUST NOT use simulcast in that direction.
「a = Simulcast」なしで回答を受け取るオファーは、同時に回答者に向かって使用してはいけません。指定された方向にRID-IDを指定せずに "A = Simulcast"で回答を受け取るオファーは、その方向にSimulcastを使用してはいけません。
An offerer that receives an answer where some rid-id alternatives are kept MUST be prepared to receive any of the kept "send"-direction rid-id alternatives and MAY send any of the kept "receive"-direction rid-id alternatives.
いくつかのRID-IDの代替案が保持されている答えを受け取るオファーは、保管されている「送信」リディ-ID-IDのいずれかを受け取るように準備しなければならず、「受信」リッダーIDの選択肢の保管を送ることができます。
An offerer that receives an answer where some of the rid-ids are removed compared to the offer MAY release the corresponding resources (codec, transport, etc) in its "receive" direction and MUST NOT send any RTP packets corresponding to the removed rid-ids.
RID-IDのいくつかがオファーと比較して削除される答えを受信するオファーは、その「受信」方向に対応するリソース（コーデック、トランスポートなど）を解放し、削除されたRIDに対応するRTPパケットを送信してはいけません。IDS
An offerer that offered some of its rid-ids as initially paused and receives an answer that does not indicate RTP stream pause/resume capability MUST NOT initially pause any simulcast streams.
最初に一時停止してRTPストリームの一時停止/再開機能を示さない答えを最初に一時停止して受信した答えを最初に一時停止して提供したオファーは、まずSimulcastストリームを一時停止してはいけません。
An offerer with RTP stream pause/resume capability that receives an answer where some rid-ids are marked as initially paused SHOULD initially pause those RTP streams, even if they were marked as initially paused also in the offer, unless it has good reason for those RTP streams not being initially paused. One such reason could be, for example, that the answerer would otherwise initially not receive any media of that type at all.
RTP Streamを持つオファーを持つ答えを受信する能力を最初に一時停止しているとマークされている場合は、最初はオファーでもマークされていたとしても、オファーでもマークされていなくても、それらがこれらのRTPストリームを一時停止する必要があります。RTPストリームは最初は一時停止されていません。そのような理由の1つは、例えば、回答者が最初にそのタイプのメディアを全く受け取らないであろう。
Offers inside an existing session follow the same rules as for initial SDP offer, with these additions:
既存のセッション内のオファーは、最初のSDPオファーと同じ規則に従います。これらの追加は次のとおりです。
1. rid-ids marked as initially paused in the offerer's "send" direction SHALL reflect the offerer's opinion of the current pause state at the time of creating the offer. This is purely informational, and RTP stream pause/resume signaling [RFC7728] in the ongoing session SHALL take precedence in case of any conflict or ambiguity.
1. オファーの「送り」方向で最初に一時停止したようにマークされたRID-IDは、オファーを作成する際の現在の一時停止状態に関するオファーの意見を反映しています。これは純粋に情報で、RTP Stream Pause / Resume Signaling [RFC7728]が紛争またはあいまいさの場合に優先されます。
2. rid-ids marked as initially paused in the offerer's "receive" direction SHALL (as in an initial offer) reflect the offerer's desired rid-id pause state. Except for the case where the offerer already paused the corresponding RTP stream through RTP stream pause/resume [RFC7728] signaling, this is identical to the conditions at an initial offer.
2. 提供者の「受信」方向で最初に一時停止したようにマークされたRID-IDは、（初期オファーのように）提供者の目的のRID-IDの一時停止状態を反映しています。オファーがRTPストリームの一時停止/再開[RFC7728]シグナリングを介して対応するRTPストリームをすでに一時停止している場合を除き、これは初期オファーの条件と同じです。
Creation of SDP answers and processing of SDP answers inside an existing session follow the same rules as described above for initial SDP offer/answer.
SDP回答の作成とSDP回答の既存のセッション内のSDP回答の処理は、最初のSDPオファー/回答について上記と同じ規則に従います。
Session modification restrictions in Section 6.5 of "RTP Payload Format Restrictions" [RFC8851] also apply.
「RTPペイロードフォーマット制限」[RFC8851]のセクション6.5のセッション変更制限も適用されます。
This document does not define the use of "a=simulcast" in declarative SDP, partly because use of the simulcast format identification [RFC8851] is not defined for use in declarative SDP. If concrete use cases for simulcast in declarative SDP are identified in the future, the authors of this memo expect that additional specifications will address such use.
この文書は、宣言型SDPの「A = Simulcast」の使用を定義していません。将来的に宣言型SDPのSimulcastの具体的なユースケースが識別されている場合、このメモの作者は追加の仕様がそのような使用に対処することを期待しています。
Simulcast RTP streams MUST be related on the RTP level through RtpStreamId [RFC8852], as specified in the SDP "a=simulcast" attribute (Section 5.2) parameters. This is sufficient as long as there is only a single media source per SDP media description. When using BUNDLE [RFC8843], where multiple SDP media descriptions jointly specify a single RTP session, the SDES MID (Media Identification) mechanism in BUNDLE allows relating RTP streams back to individual media descriptions, after which the RtpStreamId relations described above can be used. Use of the RTP header extension for the RTCP source description items [RFC7941] for both MID and RtpStreamId identifications can be important to ensure rapid initial reception, required to correctly interpret and process the RTP streams. Implementers of this specification MUST support the RTCP source description (SDES) item method and SHOULD support RTP header extension method to signal RtpStreamId on the RTP level.
SDP "A = Simulcast"属性（セクション5.2）のパラメータで指定されているように、Simulcast RTP StreamsはRTP StreamID [RFC8852]を介してRTPレベルに関連している必要があります。SDPメディア記述ごとに単一のメディアソースしかない限り、これは十分です。バンドル[RFC8843]を使用している場合、複数のSDPメディアの記述が単一のRTPセッションを共同で指定した場合、バンドルのSDES MID（メディア識別）メカニズムはRTPストリームを個々のメディアの説明に関連付けることができ、その後、上記のRTPStreamIDリレーションを使用することができます。RTCPソース記述項目のRTPヘッダー拡張機能の使用MIDSTREAMID識別情報とRTPStreamID識別の両方について[RFC7941]は、RTPストリームを正しく解釈して処理するために必要な迅速な初期受信を確実にするために重要です。この仕様の実装者は、RTCPソース記述（SDES）項目メソッドをサポートし、RTP StrameのRTPStreamIDをRTPレベルでサポートする必要があります。
NOTE: For the case where it is clear from SDP that the RTP PT uniquely maps to a corresponding RtpStreamId, an RTP receiver can use RTP PT to relate simulcast streams. This can sometimes enable decoding even in advance of receiving RtpStreamId information in RTCP SDES and/or RTP header extensions.
注：RTP PTが対応するRTPStreamIDに一意にマッピングされるSDPからクリアされている場合、RTP受信者はRTP PTを使用してSimulcastストリームを関連付けることができます。これにより、RTCP SDESおよび/またはRTPヘッダー拡張子のRTPStreamID情報を受信する前に復号化を可能にすることがあります。
RTP streams MUST only use a single alternative rid-id at a time (based on RTP timestamps) but MAY change format (and rid-id) on a per-RTP packet basis. This corresponds to the existing (nonsimulcast) SDP offer/answer case when multiple formats are included on the "m=" line in the SDP answer, enabling per-RTP packet change of RTP payload type.
RTP Streamsは、一度に単一の代替RID-IDを使用するだけです（RTPタイムスタンプに基づいて）、RTPごとのパケットごとにフォーマット（およびRID-ID）を変更することがあります。これは、SDP回答の「M =」行に複数のフォーマットが含まれている場合、RTPペイロードタイプのRTPパケットの変更を有効にして、既存の（非照度キャスト）SDPオファー/アンサーセパーに対応しています。
These examples describe a client-to-video-conference service, using a centralized media topology with an RTP mixer.
これらの例は、RTPミキサーを持つ集中型メディアトポロジを使用して、クライアントからビデオ会議サービスを説明しています。
+---+ +-----------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| F |<---->| |<---->| J |
+---+ +-----------+ +---+
Figure 4: Four-Party Mixer-Based Conference
図4：4党ミキサーベースの会議
Alice is calling in to the mixer with a simulcast-enabled client capable of a single media source per media type. The client can send a simulcast of 2 video resolutions and frame rates: HD 1280x720p 30fps and thumbnail 320x180p 15fps. This is defined below using the "imageattr" [RFC6236]. In this example, only the "pt" "a=rid" parameter is used to describe simulcast stream formats, effectively achieving a 1:1 mapping between RtpStreamId and media formats (RTP payload types). Alice's Offer:
Aliceは、メディアタイプごとに単一のメディアソースが可能なSimulcast対応クライアントでミキサーに呼び出されています。クライアントは、2つのビデオ解像度とフレームレートのシマールキャストを送信できます.HD 1280x720p 30fpsとサムネイル320x180p 15fps。これは以下の「imageAttr」[RFC6236]を使用して以下に定義されています。この例では、「PT」「A = RID」パラメータのみがSimulcastストリームフォーマットを説明するために使用され、RTPStreamIDとメディアフォーマットとの間の1：1マッピングを実現します（RTPペイロードタイプ）。アリスのオファー：
v=0
o=alice 2362969037 2362969040 IN IP4 192.0.2.156
s=Simulcast-Enabled Client
c=IN IP4 192.0.2.156
t=0 0
m=audio 49200 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49300 RTP/AVP 97 98
a=rtpmap:97 H264/90000
a=rtpmap:98 H264/90000
a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000
a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600
a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720]
a=imageattr:98 send [x=320,y=180] recv [x=320,y=180]
a=rid:1 send pt=97
a=rid:2 send pt=98
a=rid:3 recv pt=97
a=simulcast:send 1;2 recv 3
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
Figure 5: Single-Source Simulcast Offer
図5：シングルソースのSimulcastオファー
The only thing in the SDP that indicates simulcast capability is the line in the video media description containing the "simulcast" attribute. The included "a=fmtp" and "a=imageattr" parameters indicate that sent simulcast streams can differ in video resolution. The RTP header extension for RtpStreamId is offered to avoid issues with the initial binding between RTP streams (SSRCs) and the RtpStreamId identifying the simulcast stream and its format.
SMULCAST機能を示すSDPの唯一のものは、 "simulcast"属性を含むビデオメディアの説明内の行です。含まれている "A = FMTP"と "A = ImageAttr"パラメータは、送信されたSimulcastストリームがビデオ解像度が異なる可能性があることを示します。RTPStreamIDのRTPヘッダー拡張機能は、RTP Streams（SSRCS）とSimulcastストリームとそのフォーマットを識別するRTPStreamIDとの間の初期バインディングに関する問題を回避するために提供されています。
The answer from the server indicates that it, too, is simulcast capable. Should it not have been simulcast capable, the "a=simulcast" line would not have been present, and communication would have started with the media negotiated in the SDP. Also, the usage of the RtpStreamId RTP header extension is accepted.
サーバーからの答えは、それがSimulcast対応です。Simulcast対応ではなかった場合は、 "A = Simulcast"行が存在しませんでした。また、RTPStreamID RTPヘッダー拡張機能の使用は受け入れられます。
v=0
o=server 823479283 1209384938 IN IP4 192.0.2.2
s=Answer to Simulcast-Enabled Client
c=IN IP4 192.0.2.43
t=0 0
m=audio 49672 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49674 RTP/AVP 97 98
a=rtpmap:97 H264/90000
a=rtpmap:98 H264/90000
a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000
a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600
a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720]
a=imageattr:98 send [x=320,y=180] recv [x=320,y=180]
a=rid:1 recv pt=97
a=rid:2 recv pt=98
a=rid:3 send pt=97
a=simulcast:recv 1;2 send 3
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
Figure 6: Single-Source Simulcast Answer
図6：シングルソースSimulcast回答
Since the server is the simulcast media receiver, it reverses the direction of the "simulcast" and "rid" attribute parameters.
サーバーはSimulcastメディア受信者であるため、 "Simulcast"と "Rid"属性パラメータの方向を反転させます。
Fred is calling in to the same conference as in the example above with a two-camera, two-display system, thus capable of handling two separate media sources in each direction, where each media source is simulcast enabled in the "send" direction. Fred's client is restricted to a single media source per media description.
Fredは、2カメラの2ディスプレイシステムと同じ会議に電話をかけています。これにより、各ディレクトリ内の2つの別々のメディアソースを取り扱うことができ、各メディアソースは「送信」方向にSimulcastを有効にします。Fredのクライアントは、メディアの説明ごとに単一のメディアソースに制限されています。
The first two simulcast streams for the first media source use different codecs, H264-SVC [RFC6190] and H264 [RFC6184]. These two simulcast streams also have a temporal dependency. Two different video codecs, VP8 [RFC7741] and H264, are offered as alternatives for the third simulcast stream for the first media source. Only the highest-fidelity simulcast stream is sent from start, the lower-fidelity streams being initially paused.
最初のメディアソースの最初の2つのSimulcastストリームは、異なるコーデック、H264-SVC [RFC6190]とH264 [RFC6184]を使用します。これら2つのSimulcastストリームにも時間的な依存関係があります。2つの異なるビデオコーデック、VP8 [RFC7741]およびH264は、最初のメディアソースの3番目のSimulcastストリームの代替案として提供されています。最上位のSimulcastストリームのみが開始から送信され、最初は初期停止されています。
The second media source is offered with three different simulcast streams. All video streams of this second media source are loss protected by RTP retransmission [RFC4588]. In addition, all but the highest-fidelity simulcast stream are initially paused. Note that the lower resolution is more prioritized than the medium-resolution simulcast stream.
2番目のメディアソースは3つの異なるSimulcastストリームで提供されています。この2番目のメディアソースのすべてのビデオストリームは、RTP再送信[RFC4588]によって保護されている損失です。さらに、最高の忠実度のSimulcastストリームはすべて一時停止しています。低解像度は、中解像Simulcastストリームよりも優先されます。
Fred's client is also using BUNDLE to send all RTP streams from all media descriptions in the same RTP session on a single media transport. Although using many different simulcast streams in this example, the use of RtpStreamId as simulcast stream identification enables use of a low number of RTP payload types. Note that when using both BUNDLE [RFC8843] and "a=rid" [RFC8851], it is recommended to use the RTP header extension for the RTCP source descriptions items [RFC7941] for carrying these RTP stream-identification fields, which is consequently also included in the SDP. Note also that for "a=rid", the corresponding RtpStreamId SDES attribute RTP header extension is named rtp-stream-id [RFC8852].
Fredのクライアントはまた、単一のメディアトランスポートで同じRTPセッション内のすべてのメディア記述からすべてのRTPストリームを送信するためのバンドルを使用しています。この例では、さまざまなSimulcastストリームを使用していますが、Simulcastストリーム識別としてRTPStreamIDを使用すると、数回のRTPペイロードタイプを使用できます。バンドル[RFC8843]と「A = RID」[RFC8851]の両方を使用する場合は、これらのRTPストリーム識別フィールドを運ぶためのRFC7941のRFC7941のRTCPヘッダー拡張を使用することをお勧めします。SDPに含まれています。「A = RID」の場合、対応するRTPStreamID SDES属性RTPヘッダ拡張子はRTP-STREAM-ID [RFC8852]という名前です。
v=0
o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d
s=Offer from Simulcast-Enabled Multi-Source Client
c=IN IP6 2001:db8::c000:27d
t=0 0
a=group:BUNDLE foo bar zen
m=audio 49200 RTP/AVP 99
a=mid:foo
a=rtpmap:99 G722/8000
m=video 49600 RTP/AVPF 100 101 103
a=mid:bar
a=rtpmap:100 H264-SVC/90000
a=rtpmap:101 H264/90000
a=rtpmap:103 VP8/90000
a=fmtp:100 profile-level-id=42400d;max-fs=3600;max-mbps=216000; \
mst-mode=NI-TC
a=fmtp:101 profile-level-id=42c00d;max-fs=3600;max-mbps=108000
a=fmtp:103 max-fs=900; max-fr=30
a=rid:1 send pt=100;max-width=1280;max-height=720;max-fps=60;depend=2
a=rid:2 send pt=101;max-width=1280;max-height=720;max-fps=30
a=rid:3 send pt=101;max-width=640;max-height=360
a=rid:4 send pt=103;max-width=640;max-height=360
a=depend:100 lay bar:101
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtcp-fb:* ccm pause nowait
a=simulcast:send 1;2;~4,3
m=video 49602 RTP/AVPF 96 104
a=mid:zen
a=rtpmap:96 VP8/90000
a=fmtp:96 max-fs=3600; max-fr=30
a=rtpmap:104 rtx/90000
a=fmtp:104 apt=96;rtx-time=200
a=rid:1 send max-fs=921600;max-fps=30
a=rid:2 send max-fs=614400;max-fps=15
a=rid:3 send max-fs=230400;max-fps=30
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=rtcp-fb:* ccm pause nowait
a=simulcast:send 1;~3;~2
Figure 7: Fred's Multisource Simulcast Offer
図7：フレッドのマルチソースSimulcastオファー
The example in this section looks at applying simulcast with audio and video redundancy formats. The audio media description uses codec and bitrate restrictions, combined with the RTP payload for redundant audio data [RFC2198] for enhanced packet-loss resilience. The video media description applies both resolution and bitrate restrictions, combined with Forward Error Correction (FEC) in the form of flexible FEC [RFC8627] and RTP retransmission [RFC4588].
このセクションの例では、オーディオとビデオの冗長形式のSimulcastの適用を検討します。オーディオメディアの説明はコーデックとビットレートの制限を使用し、冗長オーディオデータのRTPペイロードと組み合わせて、パケット損失の強化のための冗長オーディオデータ[RFC2198]。ビデオメディアの説明は、フレキシブルFEC [RFC8627]とRTP再送[RFC4588]の形で、順方向エラー訂正（FEC）と組み合わせた解像度とビットレートの両方の制限を適用します。
The audio source is offered to be sent as two simulcast streams. The first simulcast stream is encoded with Opus, restricted to 64 kbps (rid-id=1), and the second simulcast stream (rid-id=2) is encoded with either G.711, or G.711 combined with linear predictive coding (LPC) for redundancy and explicit comfort noise (CN). Both simulcast streams include telephone-event capability. In this example, stand-alone LPC is not offered as a possible payload type for the second simulcast stream's RID, which could be motivated by, for example, not providing sufficient quality.
オーディオソースは2つのSimulcastストリームとして送信されるように提供されています。最初のSimulcastストリームは、64kbps（RID-ID = 1）に制限され、2番目のSimulcastストリーム（RID-ID = 2）がG.711、または線形予測コーディングと組み合わされたG.711のいずれかでエンコードされます。（LPC）冗長性と明示的な快適な騒音（CN）のための（LPC）。両方のSimulcastストリームには、電話イベント機能が含まれます。この例では、スタンドアロンLPCは、第2のSimulcastストリームのRIDのための可能なペイロードタイプとして提供されていないため、たとえば十分な品質を提供しないように動機付けすることができます。
The video source is offered to be sent as two simulcast streams, both with two alternative simulcast formats. Redundancy and repair are offered in the form of both flexible FEC and RTP retransmission. The flexible FEC is not bound to any particular RTP streams and is therefore able to be used across all RTP streams that are being sent as part of this media description.
ビデオソースは、2つの代替Simulcastフォーマットで、2つのSimulcastストリームとして送信されるように提供されています。冗長性と修理は、柔軟なFECとRTP再送の両方の形で提供されています。柔軟なFECは、特定のRTPストリームにバインドされておらず、したがって、このメディアの説明の一部として送信されているすべてのRTPストリームにわたって使用できます。
o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d
s=Offer from Simulcast-Enabled Client using Redundancy
c=IN IP6 2001:db8::c000:27d
t=0 0
a=group:BUNDLE foo bar
m=audio 49200 RTP/AVP 97 98 99 100 101 102
a=mid:foo
a=rtpmap:97 G711/8000
a=rtpmap:98 LPC/8000
a=rtpmap:99 OPUS/48000/1
a=rtpmap:100 RED/8000/1
a=rtpmap:101 CN/8000
a=rtpmap:102 telephone-event/8000
a=fmtp:99 useinbandfec=1;usedtx=0
a=fmtp:100 97/98
a=fmtp:102 0-15
a=ptime:20
a=maxptime:40
a=rid:1 send pt=99,102;max-br=64000
a=rid:2 send pt=100,97,101,102
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=simulcast:send 1;2
m=video 49600 RTP/AVPF 103 104 105 106 107
a=mid:bar
a=rtpmap:103 H264/90000
a=rtpmap:104 VP8/90000
a=rtpmap:105 rtx/90000
a=rtpmap:106 rtx/90000
a=rtpmap:107 flexfec/90000
a=fmtp:103 profile-level-id=42c00d;max-fs=3600;max-mbps=108000
a=fmtp:104 max-fs=3600; max-fr=30
a=fmtp:105 apt=103;rtx-time=200
a=fmtp:106 apt=104;rtx-time=200
a=fmtp:107 repair-window=100000
a=rid:1 send pt=103;max-width=1280;max-height=720;max-fps=30
a=rid:2 send pt=104;max-width=1280;max-height=720;max-fps=30
a=rid:3 send pt=103;max-width=640;max-height=360;max-br=300000
a=rid:4 send pt=104;max-width=640;max-height=360;max-br=300000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=rtcp-fb:* ccm pause nowait
a=simulcast:send 1,2;3,4
Figure 8: Simulcast and Redundancy Example
図8：Simulcastと冗長例
This section discusses what the different entities in a simulcast media path can expect to happen on the RTP level. This is explored from source to sink by starting in an endpoint with a media source that is simulcasted to an RTP middlebox. That RTP middlebox sends media sources to other RTP middleboxes (cascaded middleboxes), as well as selecting some simulcast format of the media source and sending it to receiving endpoints. Different types of RTP middleboxes and their usage of the different simulcast formats results in several different behaviors.
このセクションでは、Simulcastメディアパス内の異なるエンティティがRTPレベルで発生することを期待できるものについて説明します。これは、RTPミドルボックスにシマールキャスティングされたメディアソースを使用してエンドポイントから始めて、ソースからシンクされます。そのRTPミドルボックスは、メディアソースを他のRTPミドルボックス（カスケードミドルボックス）に送信し、メディアソースのSimulcast形式を選択し、それを受信側エンドポイントに送信することを選択します。RTPミドルボックスの種類と異なるSimulcast形式の使用法は、いくつかの異なる動作をもたらします。
The most straightforward simulcast case is the RTP streams being emitted from the endpoint that originates a media source. When simulcast has been negotiated in the sending direction, the endpoint can transmit up to the number of RTP streams needed for the negotiated simulcast streams for that media source. Each RTP stream (SSRC) is identified by associating it (Section 5.5) with an RtpStreamId SDES item, transmitted in RTCP and possibly also as an RTP header extension. In cases where multiple media sources have been negotiated for the same RTP session and thus BUNDLE [RFC8843] is used, the MID SDES item will also be sent, similarly to the RtpStreamId.
最も簡単なSimulcastケースは、メディアソースを発信するエンドポイントから放出されているRTPストリームです。Simulcastが送信方向にネゴシエートされた場合、エンドポイントはそのメディアソースのネゴシエートされたSimulcastストリームに必要なRTPストリームの数を送信できます。各RTPストリーム（SSRC）は、RTCPで送信されたRTCPで送信され、場合によってもRTPヘッダー拡張子としても送信されたRTPStreamID SDES項目を関連付けて（セクション5.5）に関連付けて識別されます。同じRTPセッションに対して複数のメディアソースがネゴシエートされている場合、このようにバンドル[RFC8843]が使用されている場合、RTPStreamIDと同様に、MID SDES項目も送信されます。
Each RTP stream might not be continuously transmitted due to any of the following reasons: temporarily paused using Pause/Resume [RFC7728], sender-side application logic temporarily pausing it, or lack of network resources to transmit this simulcast stream. However, all simulcast streams that have been negotiated have active and maintained SSRCs (at least in regular RTCP reports), even if no RTP packets are currently transmitted. The relation between an RTP stream (SSRC) and a particular simulcast stream is not expected to change, except in exceptional situations such as SSRC collisions. At SSRC changes, the usage of MID and RtpStreamId should enable the receiver to correctly identify the RTP streams even after an SSRC change.
次のいずれかの理由により、各RTPストリームは継続的に送信されない可能性があります。一時的に一時停止している[RFC7728]、送信側アプリケーションロジック、またはこのSimulcastストリームを送信するためのネットワークリソースの不足。ただし、ネゴシエートされたすべてのSimulcastストリームは、現在送信されていなくても、アクティブで維持されたSSRC（少なくとも通常のRTCPレポート）を持っています。SSRC衝突などの例外的な状況を除いて、RTPストリーム（SSRC）と特定のSimulcastストリームとの関係は変更されることは期待されていません。SSRCの変更時に、SSRCが変更された後でさえも、ReceiverがRTPストリームを正しく識別できるようにする必要があります。
RTP streams in a multiparty RTP session can be used in multiple different ways when the session utilizes simulcast at least on the media-source-to-middlebox legs. This is to a large degree due to the different RTP middlebox behaviors, but also the needs of the application. This text assumes that the RTP middlebox will select a media source and choose which simulcast stream for that media source to deliver to a specific receiver. In many cases, at most one simulcast stream per media source will be forwarded to a particular receiver at any instant in time, even if the selected simulcast stream may vary. For cases where this does not hold due to application needs, the RTP stream aspects will fall under the middlebox-to-middlebox case (Section 6.3).
マルチパーティRTPセッションのRTPストリームは、セッションが少なくともMedia-Source-To-MiddleBox RespでSimulcastを使用する場合、複数の異なる方法で使用できます。これは、RTPミドルボックスの動作が異なるため、アプリケーションのニーズも大きくなります。このテキストは、RTPミドルボックスがメディアソースを選択し、そのメディアソースのSimulcastストリームを特定の受信側に配信するように選択します。多くの場合、選択されたSimulcastストリームが異なる場合でも、メディアソースごとに1つのSimulcastストリームが特定の受信機に転送されます。アプリケーションのニーズによりこれが保持されていない場合は、RTPストリームの側面がミドルボックスからミドルボックスの場合（セクション6.3）になります。
The selection of which simulcast streams to forward towards the receiver is application specific. However, in conferencing applications, active speaker selection is common. In case the number of media sources possible to forward, N, is less than the total number of media sources available in a multimedia session, the current and previous speakers (up to N in total) are often the ones forwarded. To avoid the need for media-specific processing to determine the current speaker(s) in the RTP middlebox, the endpoint providing a media source may include metadata, such as the RTP header extension for client-to-mixer audio level indication [RFC6464].
受信者に向かって前方に転送されるシミュラキャストストリームの選択はアプリケーション固有のものです。ただし、会議アプリケーションでは、アクティブスピーカーの選択が一般的です。Purmentiaセッションで利用可能なメディアソースの数よりも維持源の数が少ない場合、現在および前のスピーカー（合計最大n）はしばしば転送されたものです。RTPミドルボックス内の現在のスピーカを決定するためのメディア固有の処理の必要性を回避するために、メディアソースを提供するエンドポイントは、クライアントからミキサーオーディオレベル表示のためのRTPヘッダ拡張などのメタデータを含み得る[RFC6464]。
The possibilities for stream switching are media type specific, but for media types with significant interframe dependencies in the encoding, like most video coding, the switching needs to be made at suitable switching points in the media stream that breaks or otherwise deals with the dependency structure. Even if switching points can be included periodically, it is common to use mechanisms like Full Intra Requests [RFC5104] to request switching points from the endpoint performing the encoding of the media source.
ストリームスイッチングの可能性は、メディアタイプ固有ですが、ほとんどのビデオコーディングと同様に、エンコーディングに大きなフレーム間の依存関係を持つメディアタイプの場合、スイッチングは、依存構造を壊すか、そうでなければ扱うメディアストリーム内の適切なスイッチングポイントで行われる必要があります。。切り替え点を定期的に含めることができる場合でも、メディアソースのエンコーディングを実行するエンドポイントからスイッチングポイントを要求するには、完全イントラ要求のようなメカニズムを使用するのが一般的です。
Inclusion of the RtpStreamId SDES item for an SSRC in the middlebox-to-receiver direction should only occur when use of RtpStreamId has been negotiated in that direction. It is worth noting that one can signal multiple RtpStreamIds when simulcast signaling indicates only a single simulcast stream, allowing one to use all of the RtpStreamIds as alternatives for that simulcast stream. One reason for including the RtpStreamId in the middlebox-to-receiver direction for an RTP stream is to let the receiver know which restrictions apply to the currently delivered RTP stream. In case the RtpStreamId is negotiated to be used, it is important to remember that the used identifiers will be specific to each signaling session. Even if the central entity can attempt to coordinate, it is likely that the RtpStreamIds need to be translated to the leg-specific values. The below cases will assume that RtpStreamId is not used in the mixer to receiver direction.
MiddleBoxから受信側の方向にSSRCのRTPStreamID SDES項目を含めると、RTPStreamIDの使用がその方向にネゴシエートされたときにのみ発生する必要があります。Simulcastシグナリングが単一のSimulcastストリームのみを示している場合、複数のRTPStreamIDをシグナリングできることは注目に値します。RTPストリームのMiddleBox-to ReceiveDiverのRTPStreamIDを含める1つの理由は、受信側に現在配信されているRTPストリームにどの制限が適用されるかを知らせることです。RTPStreamIDがネゴシエートされるとネゴシエートされる場合は、使用されている識別子が各シグナリングセッションに固有のものになることを忘れないでください。中心的なエンティティが調整を試みることができるとしても、RTPStreamIDを脚固有の値に変換する必要がある可能性があります。以下のケースは、RTPStreamIDがミキサーに受信方向に使用されていないと仮定します。
This section discusses the behavior in cases where the RTP middlebox behaves like the media-switching mixer in RTP topologies (Section 3.6.2 of [RFC7667]). The fundamental aspect here is that the media sources delivered from the middlebox will be the mixer's conceptual or functional ones. For example, one media source may be the main speaker in high-resolution video, while a number of other media sources are thumbnails of each participant.
このセクションでは、RTPのミドルボックスがRTPトポロジのメディアスイッチングミキサーのように動作する場合の動作について説明します（[RFC7667]のセクション3.6.2）。ここでの基本的な側面は、ミドルボックスから配信されたメディアソースがミキサーの概念的または機能的なものになることです。例えば、1つのメディアソースが高解像度ビデオのメインスピーカーであり得るが、他のいくつかのメディアソースは各参加者のサムネイルである。
The above results in the RTP stream produced by the mixer being one that switches between a number of received incoming RTP streams for different media sources and in different simulcast versions. The mixer selects the media source to be sent as one of the RTP streams and then selects among the available simulcast streams for the most appropriate one. The selection criteria include available bandwidth on the mixer-to-receiver path and restrictions based on the functional usage of the RTP stream delivered to the receiver. As an example of the latter, it is unnecessary to forward a full HD video to a receiver if the display area is just a thumbnail. Thus, restrictions may exist to not allow some simulcast streams to be forwarded for some of the mixer's media sources.
上記の結果は、ミキサーによって生成されたRTPストリームが、さまざまなメディアソースおよびさまざまなSimulcastバージョンで、受信した受信RTPストリームの数を切り替えるものです。ミキサーは、RTPストリームの1つとして送信されるメディアソースを選択してから、最も適切なものに対して使用可能なSimulcastストリームの中から選択します。選択基準には、受信機に配信されたRTPストリームの機能的使用法に基づく、使用可能な帯域幅が含まれます。後者の例として、表示領域がサムネイルだけである場合、フルHDビデオを受信機に転送する必要はない。したがって、一部のミキサーのメディアソースについて一部のSimulcastストリームを転送することはできないように制限があります。
This will result in a single RTP stream being used for each of the RTP mixer's media sources. At any point in time, this RTP stream is a selection of one particular RTP stream arriving to the mixer, where the RTP header-field values are rewritten to provide a consistent, single RTP stream. If the RTP mixer doesn't receive any incoming stream matched to this media source, the SSRC will not transmit but be kept alive using RTCP. The SSRC and thus RTP stream for the mixer's media source is expected to be long-term stable. It will only be changed by signaling or other disruptive events. Note that although the above talks about a single RTP stream, there can in some cases be multiple RTP streams carrying the selected simulcast stream for the originating media source, including redundancy or other auxiliary RTP streams.
これにより、RTPミキサーの各メディアソースに単一のRTPストリームが使用されます。任意の時点で、このRTPストリームはミキサに到着する1つの特定のRTPストリームの選択であり、ここでRTPヘッダフィールド値は一貫した単一のRTPストリームを提供するために書き換えられる。RTPミキサーがこのメディアソースに一致した受信ストリームを受信しない場合、SSRCは送信されませんが、RTCPを使用して生き続けます。MixerのメディアソースのSSRC、したがってRTPストリームは長期安定性であると予想されます。シグナリングやその他の破壊的なイベントによってのみ変更されます。上記は単一のRTPストリームについての会談がありますが、冗長性または他の補助RTPストリームを含む、発信元メディアソースの選択されたSimulcastストリームを伝送する複数のRTPストリームであることがあります。
The mixer may communicate the identity of the originating media source to the receiver by including the Contributing Source (CSRC) field with the originating media source's SSRC value. Note that due to the possibility that the RTP mixer switches between simulcast versions of the media source, the CSRC value may change, even if the media source is kept the same.
ミキサーは、生成元（CSRC）フィールドを発信元メディアソースのSSRC値と含めることによって、発信側メディアソースの識別情報を受信機に伝達することができる。RTPミキサがメディアソースのSimulcastバージョン間で切り替わる可能性があるため、メディアソースが同じに保たれていても、CSRC値が変わることがあります。
It is important to note that any MID SDES item from the originating media source needs to be removed and not be associated with the RTP stream's SSRC. That is, there is nothing in the signaling between the mixer and the receiver that is structured around the originating media sources, only the mixer's media sources. If they were associated with the SSRC, the receiver would likely believe that there has been an SSRC collision and the RTP stream is spurious, because it doesn't carry the identifiers used to relate it to the correct context. However, this is not true for CSRC values, as long as they are never used as an SSRC. In these cases, one could provide CNAME and MID as SDES items. A receiver could use this to determine which CSRC values that are associated with the same originating media source.
発信側メディアソースからのMID SDES項目を削除し、RTPストリームのSSRCに関連付けられないことに注意することが重要です。すなわち、ミキサーと発信側メディアソースの周囲に構造化されているシグナリングには、ミキサーのメディアソースのみがシグナリングされています。それらがSSRCに関連付けられている場合、受信者はSSRCの衝突があると考えられ、RTPストリームが正しいコンテキストに関連する識別子を持ちません。ただし、これはSSRCとして使用されていない限り、これはCSRC値には当てはまりません。このような場合、SDESアイテムとしてCNAMEとMIDを提供できます。受信機はこれを使用して、同じ発信元メディアソースに関連付けられているどのCSRC値を決定することができます。
If RtpStreamIds are used in the scenario described by this section, it should be noted that the RtpStreamId on a particular SSRC will change based on the actual simulcast stream selected for switching. These RtpStreamId identifiers will be local to this leg's signaling context. In addition, the defined RtpStreamIds and their parameters need to cover all the media sources and simulcast streams received by the RTP mixer that can be switched into this media source, sent by the RTP mixer.
このセクションで説明されているシナリオでRTPStreamIDSが使用されている場合は、特定のSSRCのRTPStreamIDがスイッチング用に選択された実際のSimulcastストリームに基づいて変更されます。これらのRTPStreamID識別子は、このレッグのシグナリングコンテキストに対してローカルになります。さらに、定義されたRTPStreamIDとそれらのパラメータは、RTPミキサーによって送信されるこのメディアソースに切り替えることができるRTPミキサーによって受信されたすべてのメディアソースおよびSimulcastストリームをカバーする必要があります。
This section discusses the behavior in cases where the RTP middlebox behaves like the Selective Forwarding Middlebox in RTP topologies (Section 3.7 of [RFC7667]). Applications for this type of RTP middlebox result in each originating media source having a corresponding media source on the leg between the middlebox and the receiver. A Selective Forwarding Middlebox (SFM) could go as far as exposing all the simulcast streams for a media source; however, this section will focus on having a single simulcast stream that can contain any of the simulcast formats. This section will assume that the SFM projection mechanism works on the media-source level and maps one of the media source's simulcast streams onto one RTP stream from the SFM to the receiver.
このセクションでは、RTPのミドルボックスがRTPトポロジのSelective Forwarding MiddleBoxのように動作する動作について説明します（[RFC7667]のセクション3.7）。このタイプのRTPミドルボックスのアプリケーションは、ミドルボックスと受信側の間の脚に対応するメディアソースを持つ各発信メディアソースになります。選択的転送ミドルボックス（SFM）は、メディアソースのすべてのSimulcastストリームを公開する限り行く可能性があります。ただし、このセクションでは、Simulcast形式のいずれかを含めることができる単一のSimulcastストリームを持つことに焦点を当てます。このセクションでは、SFM投影メカニズムがメディアソースレベルで機能し、メディアソースのSimulcastストリームの1つをSFMから受信側に1つのRTPストリームにマッピングします。
This usage will result in the individual RTP stream(s) for one media source being able to switch between being active and paused, based on the subset of media sources the SFM wants to provide the receiver for the moment. With SFMs, there exist no reasons to use CSRC to indicate the originating stream, as there is a one-to-one media-source mapping. If the application requires knowing the simulcast version received to function well, then RtpStreamId should be negotiated on the SFM to receiver leg. Which simulcast stream that is being forwarded is not made explicit unless RtpStreamId is used on the leg.
この使用法は、SFMが受信機を提供したいメディアソースのサブセットに基づいて、1つのメディアソースがアクティブで一時停止することができる個々のRTPストリームをもたらすであろう。SFMSを使用すると、1対1のメディアソースマッピングがあるため、CSRCを使用して発信元ストリームを示す理由はありません。アプリケーションが、受信したSimulcastバージョンをよく機能させることを知る必要がある場合は、RTPStreamIDをSFMに受信側の脚にネゴシエートする必要があります。RTPStreamIDが脚に使用されていない限り、転送されているSimulcastストリームは明示的にされません。
Any MID SDES items being sent by the SFM to the receiver are only those agreed between the SFM and the receiver, and no MID values from the originating side of the SFM are to be forwarded.
SFMによって受信機に送信されているMID SDES項目は、SFMと受信機との間で合意されたものだけであり、SFMの発信側からの中間値は転送されます。
An SFM could expose corresponding RTP streams for all the media sources and their simulcast streams and then, for any media source that is to be provided, forward one selected simulcast stream. However, this is not recommended, as it would unnecessarily increase the number of RTP streams and require the receiver to timely detect switching between simulcast streams. The above usage requires the same SFM functionality for switching, while avoiding the uncertainties of timely detecting that an RTP stream ends. The benefit would be that the received simulcast stream would be implicitly provided by which RTP stream would be active for a media source. However, using RtpStreamId to make this explicit also exposes which alternative format is used. The conclusion is that using one RTP stream per simulcast stream is unnecessary. The issue with timely detecting end of streams, independent of whether they are stopped temporarily or long term, is that there is no explicit indication that the transmission has intentionally been stopped. The RTCP-based pause and resume mechanism [RFC7728] includes a PAUSED indication that provides the last RTP sequence number transmitted prior to the pause. Due to usage, the timeliness of this solution depends on when delivery using RTCP can occur in relation to the transmission of the last RTP packet. If no explicit information is provided at all, then detection based on nonincreasing RTCP SR field values and timers need to be used to determine pause in RTP packet delivery. As a result, when the last RTP packet arrives (if it arrives), one usually cannot determine that this will be the last. That it was the last is something that one learns later.
SFMは、すべてのメディアソースおよびそれらのSimulcastストリームに対して対応するRTPストリームを公開し、次に提供されるメディアソースに対して、選択した1つのSimulcastストリームを転送することができる。ただし、RTPストリームの数を不必要に増やし、シミュレーションストリーム間の切り替えをタイムリーに検出する必要があるため、これはお勧めできません。上記の使用法では、RTPストリームが終了したことをタイムリーに検出する不確実性を回避しながら、スイッチングに同じSFM機能を必要とします。利点は、受信したSimulcastストリームが暗黙的に提供されることが、メディアソースに対してRTPストリームがアクティブになることです。ただし、RTPStreamIDを使用してこの明示的なものを使用すると、どの代替フォーマットが使用されているかがわかります。結論は、Simulcastストリームごとに1つのRTPストリームを使用することは不要です。一時的または長期的に停止しているかどうかにかかわらず、ストリームの終わりをタイムリーに検出するという問題は、送信が意図的に停止されたという明白な指示がないということです。 RTCPベースの一時停止および再開メカニズム[RFC7728]は、一時停止前に送信された最後のRTPシーケンス番号を提供する一時停止の指示を含む。使用法により、このソリューションのタイムレベルは、RTCPを使用した配信が最後のRTPパケットの送信に関して発生する可能性がある場合に依存します。明示的な情報がまったく提供されていない場合、RTCP SRフィールド値とタイマーが不要になっていない検出を使用して、RTPパケット配信で一時停止を決定する必要があります。その結果、最後のRTPパケットが到着したとき（到着した場合）、通常これが最後になると判断できません。最後だったことは、後で学ぶものです。
This relates to the transmission of simulcast streams between RTP middleboxes or other usages where one wants to enable the delivery of multiple simultaneous simulcast streams per media source, but the transmitting entity is not the originating endpoint. For a particular direction between middleboxes A and B, this looks very similar to the originating-to-middlebox case on a media-source basis. However, in this case, there are usually multiple media sources, originating from multiple endpoints. This can create situations where limitations in the number of simultaneously received media streams can arise -- for example, due to limitation in network bandwidth. In this case, a subset of not only the simulcast streams but also media sources can be selected. As a result, individual RTP streams can become paused at any point and later be resumed based on various criteria.
これは、RTPミドルボックスまたはその他の使用法の間のSimulcastストリームの伝送に関連していますが、メディアソースごとの複数の同時Simulcastストリームの配信を有効にしたいが、送信エンティティは発信エンドポイントではありません。ミドルボックスAとBの間の特定の方向性は、メディアソースのソースベースで、発信元ボックスの場合と非常によく似ています。ただし、この場合、複数のエンドポイントから発信された複数のメディアソースがあります。これにより、ネットワーク帯域幅の制限により、例えば、同時に受信したメディアストリームの数の制限が生じる可能性がある状況を作成できます。この場合、Simulcastストリームだけでなくメディアソースも選択できるサブセットを選択できます。その結果、個々のRTPストリームは任意の時点で一時停止される可能性があり、後で様々な基準に基づいて再開される。
The MIDs used between A and B are the ones agreed between these two identities in signaling. The RtpStreamId values will also be provided to ensure explicit information about which simulcast stream they are. The RTP-stream-to-MID and -RtpStreamId associations should here be long-term stable.
AとBの間で使用されているMIDは、シグナリングのこれら2つのID間に合意されたものです。RTPStreamID値は、どのSimulcastストリームに関する明示的な情報を確実にするために提供されます。ここでは、RTP-Stream-To-MIDおよび-RTPStreamIDアソシエーションは長期安定性です。
Simulcast is in this memo defined as the act of sending multiple alternative encoded streams of the same underlying media source. Transmitting multiple independent streams that originate from the same source could potentially be done in several different ways using RTP. A general discussion on considerations for use of the different RTP multiplexing alternatives can be found in "Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams" [RFC8872]. Discussion and clarification on how to handle multiple streams in an RTP session can be found in [RFC8108].
Simulcastはこのメモにあり、同じ基礎となるメディアソースの複数の代替符号化ストリームを送信する行為として定義されています。同じソースから発生する複数の独立したストリームを送信することは、RTPを使用していくつかの異なる方法で実行する可能性があります。異なるRTP多重化代替案の使用に関する考察に関する一般的な議論は、「RFC8872」の「RTPの多重化機能を使用するためのガイドライン」である。RTPセッションで複数のストリームを処理する方法についての説明と説明は[RFC8108]にあります。
The network aspects that are relevant for simulcast are:
Simulcastに関連するネットワークの側面は次のとおりです。
Quality of Service (QoS): When using simulcast, it might be of interest to prioritize a particular simulcast stream, rather than applying equal treatment to all streams. For example, lower-bitrate streams may be prioritized over higher-bitrate streams to minimize congestion or packet losses in the low-bitrate streams. Thus, there is a benefit to using a simulcast solution with good QoS support.
サービス品質（QoS）：Simulcastを使用する場合、すべてのストリームに等しい扱いを適用するのではなく、特定のSimulcastストリームを優先することが興味深い可能性があります。例えば、低ビットレートストリームの輻輳またはパケット損失を最小限に抑えるために、より低いビットレートストリームをより高ビットレートストリームよりも優先させることができる。したがって、優れたQoSサポートを備えたSimulcastソリューションを使用することが恩恵を受けます。
NAT/FW Traversal (Network Address Translator / Firewall Traversal): Using multiple RTP sessions incurs more cost for NAT/FW traversal unless they can reuse the same transport flow, which can be achieved by multiplexing negotiation using SDP port numbers [RFC8843].
NAT / FWトラバーサル（ネットワークアドレストランスレータ/ファイアウォールトラバーサル）：複数のRTPセッションを使用すると、SDPポート番号を使用した交渉を多重化することによって達成できる同じトランスポートフローを再利用できる限り、NAT / FWトラバーサルのコストが長くなります[RFC8843]。
Use of multiple simulcast streams can require a significant amount of network resources. The aggregate bandwidth for all simulcast streams for a media source (and thus SDP media description) is bounded by any SDP "b=" line applicable to that media source. It is assumed that a suitable congestion-control mechanism is used by the application to ensure that it doesn't cause persistent congestion. If the amount of available network resources varies during an RTP session such that it does not match what is negotiated in SDP, the bitrate used by the different simulcast streams may have to be reduced dynamically. When a simulcasting media source uses a single media transport for all of the simulcast streams, it is likely that a joint congestion control across all simulcast streams is used for that media source. What simulcast streams to prioritize when allocating available bitrate among the simulcast streams in such adaptation SHOULD be taken from the simulcast stream order on the "a=simulcast" line and ordering of alternative simulcast formats (Section 5.2). Simulcast streams that have pause/resume capability and that would be given such low bitrate by the adaptation process that they are considered not really useful can be temporarily paused until the limiting condition clears.
複数のSimulcastストリームを使用するには、かなりの量のネットワークリソースが必要です。メディアソースのすべてのSimulcastストリームの集計帯域幅（したがってSDPメディア説明）は、そのメディアソースに適用可能な任意のSDP "B ="行によって制限されます。それはそれが持続的な輻輳を引き起こさないように適切な輻輳制御メカニズムがアプリケーションによって使用されていると仮定されています。 SDPでネゴシエートされているものと一致しないように、利用可能なネットワークリソースの量が異なる場合、異なるSimulcastストリームによって使用されるビットレートを動的に削減する必要があるかもしれません。 Simulcasting Media SourceがすべてのSimulcastストリームに対して単一のメディアトランスポートを使用すると、すべてのSimulcastストリームにわたる共同輻輳制御がそのメディアソースに使用される可能性があります。そのような適応のSimulcastストリーム間で利用可能なビットレートを割り当てるときに優先されるSimulcastストリームは、「A = Simulcast」回線のSimulcastストリーム順序と代替のSimulcast形式の順序付けを行う必要があります（セクション5.2）。能力を一時停止/再開したシミュレーションストリーム、およびそれらが実際には有用ではないと見なされることは、制限条件がクリアされるまで一時的に一時停止することができます。
The chosen approach has a limitation that relates to the use of a single RTP session for all simulcast formats of a media source, which comes from sending all simulcast streams related to a media source under the same SDP media description.
選択されたアプローチは、メディアソースのすべてのSimulcastフォーマットに対する単一のRTPセッションの使用に関連する制限を有する。
It is not possible to use different simulcast streams on different media transports, which limits the possibilities for applying different QoS to different simulcast streams. When using unicast, QoS mechanisms based on individual packet marking are feasible, since they do not require separation of simulcast streams into different RTP sessions to apply different QoS.
異なるメディアトランスポートで異なるSimulcastストリームを使用することはできません。これにより、さまざまなSimulcastストリームにさまざまなQoSを適用する可能性が制限されます。ユニキャストを使用する場合、個々のパケットマーキングに基づくQoSメカニズムは、異なるQoSを適用するために異なるRTPセッションへのSimulcastストリームの分離を必要としないため、実行可能です。
It is also not possible to separate different simulcast streams into different multicast groups to allow a multicast receiver to pick the stream it wants, rather than receive all of them. In this case, the only reasonable implementation is to use different RTP sessions for each multicast group so that reporting and other RTCP functions operate as intended. Such simulcast usage in a multicast context is out of scope for the current document and would require additional specification.
マルチキャスト受信機がそれらのすべてを受信するのではなく、それが望むストリームを選択できるように、異なるSimulcastストリームをさまざまなマルチキャストグループに分離することもできません。この場合、唯一の合理的な実装は、レポート作成および他のRTCP関数が意図したとおりに動作するように、各マルチキャストグループに対して異なるRTPセッションを使用することです。マルチキャストコンテキスト内のそのようなSimulcastの使用法は現在の文書の範囲外であり、追加の仕様を必要とします。
This document registers a new media-level SDP attribute, "simulcast", in the "att-field (media level only)" registry within the "Session Description Protocol (SDP) Parameters" registry, according to the procedures of [RFC4566] and [RFC8859].
このドキュメントは、[RFC4566]の手順に従って、「Cession Description Protocol（SDP）パラメータ」レジストリ内の「att-field（メディアレベルのみ）」レジストリに、新しいメディアレベルのSDP属性「Simulcast」を登録します。[RFC8859]。
Contact name, email: The IESG (iesg@ietf.org)
連絡先名、Eメール：IESG（iesg@ietf.org）
Attribute name: simulcast
属性名：Simulcast.
Long-form attribute name: Simulcast stream description
長い形式の属性名：Simulcast Streamの説明
Charset dependent: No
文字セットに依存する：いいえ
Attribute value: sc-value; see Section 5.1 of RFC 8853.
属性値：sc値;RFC 8853のセクション5.1を参照してください。
Purpose: Signals simulcast capability for a set of RTP streams
目的：RTPストリームのセットのシグナルSimulcast機能
Mux category: NORMAL
MUXカテゴリ：標準
The simulcast capability, configuration attributes, and parameters are vulnerable to attacks in signaling.
Simulcast機能、構成属性、およびパラメータは、シグナリングの攻撃に対して脆弱です。
A false inclusion of the "a=simulcast" attribute may result in simultaneous transmission of multiple RTP streams that would otherwise not be generated. The impact is limited by the media description joint bandwidth, shared by all simulcast streams irrespective of their number. However, there may be a large number of unwanted RTP streams that will impact the share of bandwidth allocated for the originally wanted RTP stream.
「a = simulcast」属性を誤って包含すると、そうでなければ生成されないであろう複数のRTPストリームを同時に送信することがある。影響は、その数に関係なく、すべてのSimulcastストリームによって共有されているメディア記述の関節帯域幅によって制限されます。しかしながら、当初の希望のRTPストリームに割り当てられた帯域幅の割合に影響を与える多数の不要なRTPストリームがあるかもしれない。
A hostile removal of the "a=simulcast" attribute will result in simulcast not being used.
"a = simulcast"属性の敵対的な削除は、Simulcastが使用されていません。
Integrity protection and source authentication of all SDP signaling, including simulcast attributes, can mitigate the risks of such attacks that attempt to alter signaling.
Simulcast属性を含むすべてのSDPシグナリングの整合性保護とソース認証は、シグナリングを変更しようとするそのような攻撃のリスクを軽減できます。
Security considerations related to the use of "a=rid" and the RtpStreamId SDES item are covered in [RFC8851] and [RFC8852]. There are no additional security concerns related to their use in this specification.
セキュリティ上の考慮事項「A = RID」の使用とRTPStreamID SDES項目は、[RFC8851]と[RFC8852]で説明されています。この仕様の使用に関連する追加のセキュリティ上の懸念はありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[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>。
[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>。
[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>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405] KYZIVAT、P.、「ABNFの大文字と小文字の区別文字列サポート」、RFC 7405、DOI 10.17487 / RFC7405、2014年12月、<https：//www.rfc-editor.org/info/rfc7405>。
[RFC7728] Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728, February 2016, <https://www.rfc-editor.org/info/rfc7728>.
[RFC7728] Burman、B.、Akram、A.、偶数、R.、およびM.Westerlund、 "RTP Stream Pause and Resume"、RFC 7728、DOI 10.17487 / RFC7728、2016年2月、<https：//www.rfc-editor.org/info/rfc7728>
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[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>。
[RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, <https://www.rfc-editor.org/info/rfc8859>.
[RFC8859] Nandakumar、S。、「マルチプレクシング時のセッション記述プロトコル（SDP）属性のフレームワーク」、RFC 8859、DOI 10.17487 / RFC8859、2021年1月、<https：//www.rfc-editor.org/info/rfc8859>。
[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>。
[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>。
[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>。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, December 2006, <https://www.rfc-editor.org/info/rfc4733>.
[RFC4733] Schulzrinne、H.およびT.Taylor、「DTMF数字、テレフォニートーン、テレフォニー信号のRTPペイロード」、RFC 4733、DOI 10.17487 / RFC4733、2006年12月、<https：//www.rfc-editor.org/ info / rfc4733>。
[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>。
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, <https://www.rfc-editor.org/info/rfc5583>.
[RFC5583] Schierl、T.およびS.Wenger、「セッション記述プロトコル（SDP）」、RFC 5583、DOI 10.17487 / RFC5583、<https://ww.rfc-editor.org/ info / rfc5583>。
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/RFC6184, May 2011, <https://www.rfc-editor.org/info/rfc6184>.
[RFC6184] Wang、Y.-K、偶数、R.、Kristensen、T.、およびR.Jesup、RFC 6184、DOI 10.17487 / RFC6184、2011年5月、<HTTPS///www.rfc-editor.org/info/rfc6184>。
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, <https://www.rfc-editor.org/info/rfc6190>.
[RFC6190] Wenger、S.、Wang、Y.-K。、Schierl、T.、およびA. Eleftheriadis、「スケーラブルビデオコーディング用RTPペイロードフォーマット」、RFC 6190、DOI 10.17487 / RFC6190、2011年5月、<https：//www.rfc-editor.org/info/rfc6190>。
[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, DOI 10.17487/RFC6236, May 2011, <https://www.rfc-editor.org/info/rfc6236>.
[RFC6236] Johansson、I.およびK. Jung、「セッション記述プロトコル（SDP）」、RFC 6236、DOI 10.17487 / RFC6236、<https：///www.rfc-編集者の「汎用画像属性の交渉」。ORG / INFO / RFC6236>。
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, <https://www.rfc-editor.org/info/rfc6464>.
[RFC6464] Lennox、J.、Ed。、Ivov、E.、およびE.Marocco、「クライアントからミキサーのオーディオレベル表示のためのリアルタイムトランスポートプロトコル（RTP）ヘッダ拡張」、RFC 6464、DOI 10.17487 /RFC6464、2011年12月、<https://www.rfc-editor.org/info/rfc6464>。
[RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping Semantics in the Session Description Protocol", RFC 7104, DOI 10.17487/RFC7104, January 2014, <https://www.rfc-editor.org/info/rfc7104>.
[RFC7104] Begen、A.、CAI、Y、およびH。OU、「セッション記述プロトコルの重複グループ化セマンティクス」、RFC 7104、DOI 10.17487 / RFC7104、2014年1月、<https：//www.rfc-編集者.ORG / INFO / RFC7104>。
[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>。
[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, <https://www.rfc-editor.org/info/rfc7741>.
[RFC7741]ウェスティン、P.、Lundin、H.、Glover、M.、Uberti、J.、F. Grigan、「VP8ビデオのRTPペイロード形式」、RFC 7741、DOI 10.17487 / RFC7741、2016年3月、<HTTPS//www.rfc-editor.org/info/rfc7741>。
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items", RFC 7941, DOI 10.17487/RFC7941, August 2016, <https://www.rfc-editor.org/info/rfc7941>.
[RFC7941] Westerlund、M.、Burman、B.、偶数、R.、およびM.Zanaty、「RTP制御プロトコル用RTPヘッダ拡張（RTCP）ソース説明項目、RFC 7941、DOI 10.17487 / RFC7941、2016年8月<https://www.rfc-editor.org/info/rfc7941>。
[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>。
[RFC8627] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019, <https://www.rfc-editor.org/info/rfc8627>.
[RFC8627] Zanaty、M.、Singh、V.、Begen、A.、およびG. Mandyam、「柔軟な順方向誤り訂正のためのRTPペイロード形式（FEC）」、RFC 8627、DOI 10.17487 / RFC8627、2019年7月、<HTTPS：//www.rfc-editor.org/info/rfc8627>。
[RFC8872] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H., and R. Even, "Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams", RFC 8872, DOI 10.17487/RFC8872, January 2021, <https://www.rfc-editor.org/info/rfc8872>.
[RFC8872] Westerlund、M.、Burman、B.、Perkins、C.、Alvestrand、H.、R.さえ、「複数のメディアストリームをサポートするためのRTPの多重化機能を使用するためのガイドライン」、RFC 8872、DOI 10.17487 /RFC8872、2021年1月、<https://www.rfc-editor.org/info/rfc8872>。
The following requirements are met by the defined solution to support the use cases (Section 3):
以下の要件は、使用例をサポートするために定義されたソリューションによって満たされます（セクション3）。
REQ-1: Identification:
REQ-1：識別：
REQ-1.1: It must be possible to identify a set of simulcasted RTP streams as originating from the same media source in SDP signaling.
REQ-1.1：SDPシグナリングの同じメディアソースから発信されているように、Simulcasted RTPストリームのセットを識別することが可能でなければなりません。
REQ-1.2: An RTP endpoint must be capable of identifying the simulcast stream that a received RTP stream is associated with, knowing the content of the SDP signaling.
REQ-1.2：RTPエンドポイントは、受信したRTPストリームが関連付けられているSimulcastストリームを識別できなければなりません.SDPシグナリングの内容を知っています。
REQ-2: Transport usage. The solution must work when using:
REQ-2：トランスポート使用使用するときに解決策は機能する必要があります。
REQ-2.1: Legacy SDP with separate media transports per SDP media description.
REQ-2.1：SDPメディア記述ごとに別々のメディアトランスポートを持つレガシーSDP。
REQ-2.2: Bundled [RFC8843] SDP media descriptions.
REQ-2.2：バンドル[RFC8843] SDPメディアの説明。
REQ-3: Capability negotiation. The following must be possible:
REQ-3：能力交渉。次のことが可能でなければなりません。
REQ-3.1: The sender can express capability of sending simulcast.
REQ-3.1：送信者はSimulcastを送信する機能を表現できます。
REQ-3.2: The receiver can express capability of receiving simulcast.
REQ-3.2：受信機はSimulcastを受信する機能を表現できます。
REQ-3.3: The sender can express the maximum number of simulcast streams that can be provided.
REQ-3.3：送信者は提供できるSimulcastストリームの最大数を表現できます。
REQ-3.4: The receiver can express the maximum number of simulcast streams that can be received.
REQ-3.4：受信機は、受信できるSimulcastストリームの最大数を表現できます。
REQ-3.5: The sender can detail the characteristics of the simulcast streams that can be provided.
REQ-3.5：送信者は、提供できるSimulcastストリームの特性を詳述することができます。
REQ-3.6: The receiver can detail the characteristics of the simulcast streams that it prefers to receive.
REQ-3.6：受信機は、受信を好む優先されたSimulcastストリームの特性を詳述することができます。
REQ-4: Distinguishing features. It must be possible to have different simulcast streams use different codec parameters, as can be expressed by SDP format values and RTP payload types.
REQ-4：特徴を区別します。SDPフォーマット値とRTPペイロードタイプで表現できるように、異なるSimulcastストリームを使用することは可能である必要があります。
REQ-5: Compatibility. It must be possible to use simulcast in combination with other RTP mechanisms that generate additional RTP streams:
REQ-5：互換性追加のRTPストリームを生成する他のRTPメカニズムと組み合わせてSimulcastを使用することは可能である必要があります。
REQ-5.1: RTP retransmission [RFC4588].
REQ-5.1：RTP再送信[RFC4588]。
REQ-5.2: RTP Forward Error Correction [RFC5109].
REQ-5.2：RTPフォワードエラー訂正[RFC5109]。
REQ-5.3: Related payload types such as audio Comfort Noise and/or DTMF.
REQ-5.3：オーディオの快適さのノイズや/またはDTMFなどの関連ペイロードタイプ。
REQ-5.4: A single simulcast stream can consist of multiple RTP streams, to support codecs where a dependent stream is dependent on a set of encoded and dependent streams, each potentially carried in their own RTP stream.
REQ-5.4：単一のSimulcastストリームは、依存ストリームが一連の符号化されたストリームのセットに依存するコーデックをサポートするための複数のRTPストリームからなることができ、それぞれが独自のRTPストリームで実行される。
REQ-6: Interoperability. The solution must be possible to use in:
REQ-6：相互運用性以下の解決策を使用することが可能でなければなりません。
REQ-6.1: Interworking with nonsimulcast legacy clients using a single media source per media type.
REQ-6.1：メディアタイプごとに単一のメディアソースを使用して、Nonsimulcastレガシクライアントとの相互作用。
REQ-6.2: WebRTC environment with a single media source per SDP media description.
REQ-6.2：SDPメディアの単一のメディアソースを持つWEBRTC環境。
Acknowledgements
謝辞
The authors would like to thank Bernard Aboba, Thomas Belling, Roni Even, Adam Roach, Iñaki Baz Castillo, Paul Kyzivat, and Arun Arunachalam for the feedback they provided during the development of this document.
著者らは、この文書の開発中に提供されたフィードバックのために、Adam Roach、Inaki Baz Castillo、Paul Kyzivat、およびArun Arunachalamに、Bernard Aboba、Thomas Belling、Roni、Paul Kyzivat、Arun Arunachalamありがとうございます。
Contributors
貢献者
Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have contributed with important material to the first draft versions of this document. Robert Hanton and Cullen Jennings from Cisco, Peter Thatcher from Google, and Adam Roach from Mozilla contributed significantly to subsequent versions.
Ericssonの両方から、Morgan LindqvistとFredrik Janssonは、この文書の最初のドラフトバージョンに重要な資料で貢献しています。Cisco、Peter ThatcherからのRobert HantonとCullen JenningsがGoogleから、MozillaからのAdam Roachはその後のバージョンに大きく貢献しました。
Authors' Addresses
著者の住所
Bo Burman Ericsson Gronlandsgatan 31 SE-164 60 Stockholm Sweden
Bo Burman Ericsson Gronlandsgatan 31 SE-164 60ストックホルムスウェーデン
Email: bo.burman@ericsson.com
Magnus Westerlund Ericsson Torshamnsgatan 23 SE-164 83 Stockholm Sweden
Magnus Westerlund Ericsson Torshamnsgatan 23 SE-164 83ストックホルムスウェーデン
Email: magnus.westerlund@ericsson.com
Suhas Nandakumar Cisco 170 West Tasman Drive San Jose, CA 95134 United States of America
Suhas Nandakumar Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ
Email: snandaku@cisco.com
Mo Zanaty Cisco 170 West Tasman Drive San Jose, CA 95134 United States of America
Mo Zanaty Cisco 170 West Tasman Driveサンノゼ、CA 95134アメリカ
Email: mzanaty@cisco.com