[要約] RFC 8851は、RTPペイロードフォーマットの制限に関する規格であり、異なるコーデック間の相互運用性を向上させることを目的としています。ペイロードフォーマットの制限を定義し、適切なコーデックの選択や実装を促進します。
Internet Engineering Task Force (IETF) A.B. Roach, Ed.
Request for Comments: 8851 Mozilla
Updates: 4855 January 2021
Category: Standards Track
ISSN: 2070-1721
RTP Payload Format Restrictions
RTPペイロードフォーマットの制限事項
Abstract
概要
In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol (SDP). This framework defines a new "rid" ("restriction identifier") SDP attribute to unambiguously identify the RTP streams within an RTP session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular payload types.
本明細書では、セッション記述プロトコル（SDP）でRTPストリームの制限を指定するためのフレームワークを定義します。このフレームワークは、RTPセッション内のRTPストリームを明確に識別するための新しい「RID」（「制限識別子」）SDP属性を定義し、通常のペイロードタイプに与えられているものを超えてCodec-Agnostic Wayでストリームのペイロード形式のパラメータを制限します。
This specification updates RFC 4855 to give additional guidance on choice of Format Parameter (fmtp) names and their relation to the restrictions defined by this document.
この仕様は、RFC 4855を更新して、フォーマットパラメータ（FMTP）名の選択に関する追加のガイダンスと、このドキュメントによって定義された制限との関係にあります。
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/rfc8851.
この文書の現在のステータス、任意のエラータ、およびフィードバックの提供方法は、https://www.rfc-editor.org/info/rfc8851で取得できます。
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. Terminology 2. Introduction 3. Key Words for Requirements 4. SDP "a=rid" Media Level Attribute 5. "a=rid" Restrictions 6. SDP Offer/Answer Procedures 6.1. Generating the Initial SDP Offer 6.2. Answerer Processing the SDP Offer 6.2.1. "a=rid"-Unaware Answerer 6.2.2. "a=rid"-Aware Answerer 6.3. Generating the SDP Answer 6.4. Offerer Processing of the SDP Answer 6.5. Modifying the Session 7. Use with Declarative SDP 8. Interaction with Other Techniques 8.1. Interaction with VP8 Format Parameters 8.1.1. max-fr - Maximum Frame Rate 8.1.2. max-fs - Maximum Frame Size, in VP8 Macroblocks 8.2. Interaction with H.264 Format Parameters 8.2.1. profile-level-id and max-recv-level - Negotiated Subprofile 8.2.2. max-br / MaxBR - Maximum Video Bitrate 8.2.3. max-fs / MaxFS - Maximum Frame Size, in H.264 Macroblocks 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate 8.2.5. max-smbps - Maximum Decoded Picture Buffer 8.3. Redundancy Formats and Payload Type Restrictions 9. Format Parameters for Future Payloads 10. Formal Grammar 11. SDP Examples 11.1. Many Bundled Streams Using Many Codecs 11.2. Scalable Layers 12. IANA Considerations 12.1. New SDP Media-Level Attribute 12.2. Registry for RID-Level Parameters 13. Security Considerations 14. References 14.1. Normative References 14.2. Informative References Acknowledgements Contributors Author's Address
1. 用語2.要件のキーワード4. SDP "A = RID"メディアレベル属性5. "A = RID"制限事項6. SDPオファー/アンサープロシージャ6.1。初期SDPオファー6.2を生成します。回答者SDPの処理6.2.1。 "A = RID" - 中古回答者6.2.2。 "a = rid" -awareの回答者6.3。 SDP回答6.4を生成します。 SDP回答6.5のオファー処理。セッションの変更7.宣言的SDP 8.他の手法との対話8.1。 VP8フォーマットパラメータ8.1.1との対話。 MAX-FR - 最大フレームレート8.1.2。 MAX-FS - VP8マクロブロックの最大フレームサイズ8.2。 H.264フォーマットパラメータ8.2.1との対話プロファイルレベルIDとMAX-RECVレベル - ネゴシエートされたサブプロファイル8.2.2。 MAX-BR / MAXBR - 最大ビデオビットレート8.2.3。 MAX-FS / MAXFS - H.264マクロブロック8.2.4の最大フレームサイズ。 MAX-MBPS / MAXMBPS - 最大マクロブロック処理レート8.2.5。 MAX-SMBPS - 最大デコードピクチャバッファ8.3。冗長フォーマットとペイロードタイプの制限9.将来のペイロードのフォーマットパラメータ10.正式な文法11. SDPの例11.1。多くのコーデックを使用している多くのバンドルストリーム11.2。スケーラブルなレイヤ12. IANAの考慮事項12.1。新しいSDPメディアレベル属性12.2。 RIDレベルパラメータ13のレジストリ13.セキュリティ上の考慮事項14.1。規範的参考文献14.2。有益な参考文献承認担当者著者の住所
The terms "source RTP stream", "endpoint", "RTP session", and "RTP stream" are used as defined in [RFC7656].
「Source RTP Stream」、「エンドポイント」、「RTPセッション」、および「RTP Stream」という用語は、[RFC7656]で定義されているとおりに使用されます。
[RFC4566] and [RFC3264] terminology is also used where appropriate.
[RFC4566]および[RFC3264]の用語も適切な場合にも使用されます。
The payload type (PT) field in RTP provides a mapping between the RTP payload format and the associated SDP media description. For a given PT, the SDP rtpmap and/or fmtp attributes are used to describe the properties of the media that is carried in the RTP payload.
RTP内のペイロードタイプ（PT）フィールドは、RTPペイロード形式と関連するSDPメディア記述との間のマッピングを提供します。特定のPTの場合、SDP RTPMAPおよび/またはFMTPの属性は、RTPペイロードで搭載されているメディアのプロパティを記述するために使用されます。
Recent advances in standards have given rise to rich multimedia applications requiring support for either multiple RTP streams within an RTP session [RFC8843] [RFC8853] or a large number of codecs. These demands have unearthed challenges inherent with:
標準の最近の進歩は、RTPセッション[RFC8843] [RFC8853]または多数のコーデック内の複数のRTPストリームのサポートを必要とする豊富なマルチメディアアプリケーションを増加させました。これらの要求には、以下の要求が発生しました。
* The restricted RTP PT space in specifying the various payload configurations
* さまざまなペイロード構成を指定する際の制限付きRTP PTスペース
* The codec-specific constructs for the payload formats in SDP
* SDPのペイロード形式のコーデック固有の構成
* Missing or underspecified payload format parameters
* 欠落または非表示ペイロードフォーマットパラメータ
* Overloading of PTs to indicate not just codec configurations, but individual streams within an RTP session
* CODEC構成だけでなく、RTPセッション内の個々のストリームを示すためのPTSの過負荷
To expand on these points: [RFC3550] assigns 7 bits for the PT in the RTP header. However, the assignment of static mapping of RTP payload type numbers to payload formats and multiplexing of RTP with other protocols (such as the RTP Control Protocol (RTCP)) could result in a limited number of payload type numbers available for application usage. In scenarios where the number of possible RTP payload configurations exceeds the available PT space within an RTP session, there is a need for a way to represent the additional restrictions on payload configurations and effectively map an RTP stream to its corresponding restrictions. This issue is exacerbated by the increase in techniques -- such as simulcast and layered codecs -- that introduce additional streams into RTP sessions.
これらの点を展開するには：[RFC3550] RTPヘッダーのPTに7ビットを割り当てます。ただし、RTPペイロードタイプ番号のペイロードフォーマットへの静的マッピングの割り当てと他のプロトコルなどのRTPの多重化（RTP制御プロトコル（RTCPなど）には、アプリケーションの使用に使用できるペイロードタイプ番号が限られている可能性があります。可能なRTPペイロード構成の数がRTPセッション内の利用可能なPTスペースを超えるシナリオでは、ペイロード構成に対する追加の制限を表現し、RTPストリームを対応する制限に効果的にマッピングする方法が必要です。この問題は、RTPセッションに追加のストリームを導入するSimulcastおよびLayered Codecsなど、テクニックの増加によって悪化しています。
This specification defines a new SDP framework for restricting source RTP streams (Section 2.1.10 of [RFC7656]), along with the SDP attributes to restrict payload formats in a codec-agnostic way. This framework can be thought of as a complementary extension to the way the media format parameters are specified in SDP today, via the "a=fmtp" attribute.
この仕様は、ソースRTPストリームを制限するための新しいSDPフレームワーク（[RFC7656]のセクション2.1.10）を、SDP属性とともに、ペイロードフォーマットをCodec-Agnostic Wayで制限する。このフレームワークは、「a = fmtp」属性を介して、メディアフォーマットパラメータがSDPで指定されている方法の補完的な拡張として考えることができます。
The additional restrictions on individual streams are indicated with a new "a=rid" ("restriction identifier") SDP attribute. Note that the restrictions communicated via this attribute only serve to further restrict the parameters that are established on a PT format. They do not relax any restrictions imposed by other mechanisms.
個々のストリームに対する追加の制限は、新しい "A = RID"（ "制限識別子"）sdp属性で示されています。この属性を介して通信された制限は、PT形式で確立されているパラメータをさらに制限するのに役立つことに注意してください。彼らは他のメカニズムによって課される制限を緩和しません。
This specification makes use of the RTP Stream Identifier Source Description (SDES) RTCP item defined in [RFC8852] to provide correlation between the RTP packets and their format specification in the SDP.
この仕様は、[RFC8852]で定義されたRTPストリーム識別子のソース記述（SDES）RTCP項目を使用して、RTPパケットとSDPのフォーマット仕様との間の相関関係を提供します。
As described in Section 6.2.1, this mechanism achieves backwards compatibility via the normal SDP processing rules, which require unknown "a=" lines to be ignored. This means that implementations need to be prepared to handle successful offers and answers from other implementations that neither indicate nor honor the restrictions requested by this mechanism.
6.2.1項に記載されているように、このメカニズムは通常のSDP処理規則を介して後方互換性を達成します。これにより、未知の "A ="行を無視する必要があります。つまり、このメカニズムによって要求された制限を示すことも尊重されていないことも、他の実装からの成功や他の実装からの回答を処理するために実装を準備する必要があることを意味します。
Further, as described in Section 6 and its subsections, this mechanism achieves extensibility by: (a) having offerers include all supported restrictions in their offer, and (b) having answerers ignore "a=rid" lines that specify unknown restrictions.
さらに、セクション6およびその小学で説明されているように、このメカニズムは次のように拡張性を達成します。（a）提供者を持つすべてのサポートされている制限を含み、（b）回答者が未知の制限を指定する「A = RID」行を無視します。
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]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
This section defines new SDP media-level attribute [RFC4566], "a=rid", used to communicate a set of restrictions to be applied to an identified RTP stream. Roughly speaking, this attribute takes the following form (see Section 10 for a formal definition):
このセクションでは、識別されたRTPストリームに適用される制限のセットを通信するために使用される、新しいSDPメディアレベル属性[RFC4566]、「A = RID」を定義します。大まかに言って、この属性は次の形式を取ります（正式な定義のセクション10を参照）。
a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...
A = RID：<RID - <方向> [PPT = <FMT-List>;] <制限> = <value> ...
An "a=rid" SDP media attribute specifies restrictions defining a unique RTP payload configuration identified via the "rid-id" field. This value binds the restriction to the RTP stream identified by its RTP Stream Identifier Source Description (SDES) item [RFC8852]. Implementations that use the "a=rid" parameter in SDP MUST support the RtpStreamId SDES item described in [RFC8852]. Such implementations MUST send that SDES item for all streams in an SDP media description ("m=") that have "a=rid" lines remaining after applying the rules in Section 6 and its subsections.
「A = RID」SDP Media属性は、「RID-ID」フィールドを介して識別された固有のRTPペイロード構成を定義する制限を指定します。この値は、RTP Stream Identifier Source Description（SDES）項目[RFC8852]で識別されたRTPストリームへの制限にバインドされます。SDPの "A = RID"パラメータを使用する実装は、[RFC8852]に記載されているRTPStreamID SDES項目をサポートしている必要があります。そのような実装は、セクション6およびそのサブセクションの規則を適用した後に残っている「A = RID」行を持つSDPメディア記述（「M =」）内のすべてのストリームのSDES項目を送信しなければなりません。
Implementations that use the "a=rid" parameter in SDP and make use of redundancy RTP streams [RFC7656] -- e.g., RTP RTX [RFC4588] or Forward Error Correction (FEC) [RFC5109] -- for any of the source RTP streams that have "a=rid" lines remaining after applying the rules in Section 6 and its subsections MUST support the RepairedRtpStreamId SDES item described in [RFC8852] for those redundancy RTP streams. RepairedRtpStreamId MUST be used for redundancy RTP streams to which it can be applied. Use of RepairedRtpStreamId is not applicable for redundancy formats that directly associate RTP streams through shared synchronization sources (SSRCs) -- for example, [RFC8627] -- or other cases that RepairedRtpStreamId cannot support, such as referencing multiple source streams.
SDPの「A = RID」パラメータを使用し、冗長RTPストリーム[RFC7656] - 例えばRTP RTX [RFC4588]または順方向エラー訂正（FEC）[RFC5109] - 任意のソースRTPストリームの実装セクション6の規則を適用した後に残っている「A = RID」行を持ち、そのサブセクションは、それらの冗長RTPストリームの[RFC8852]で説明されているRepaireDrtpStreamID SDES項目をサポートしなければなりません。RepaireDrtpStreamIDは、適用できる冗長RTPストリームに使用する必要があります。RepaireDrtpStreamIDの使用は、Shared Synchraization Sources（SSRCS）を介してRTPストリームを直接関連付ける冗長フォーマットには適用されません。たとえば、[RFC8627]など、複数のソースストリームを参照するなど、サポートできない他のケースです。
RepairedRtpStreamId is used to provide the binding between the redundancy RTP stream and its source RTP stream by setting the RepairedRtpStreamId value for the redundancy RTP stream to the RtpStreamId value of the source RTP stream. The redundancy RTP stream MAY (but need not) have an "a=rid" line of its own, in which case the RtpStreamId SDES item value will be different from the corresponding source RTP stream.
RepaireDrtpStreamIDは、冗長RTPストリームのRepaireDrtpStreamID値をソースRTPストリームのRTPStreamID値に設定することによって、冗長RTPストリームとそのソースRTPストリーム間のバインドを提供するために使用されます。冗長RTPストリームは、それ自体の「A = RID」ラインを有することができる（しかしそうではない）、その場合、RTPStreamID SDES項目値は対応するソースRTPストリームとは異なる。
It is important to note that this indirection may result in the temporary inability to correctly associate source and redundancy data when the SSRC associated with the RtpStreamId or RepairedRtpStreamId is dynamically changed during the RTP session. This can be avoided if all RTP packets, source and repair, include their RtpStreamId or RepairedRtpStreamId, respectively, after the change. To maximize the probability of reception and utility of redundancy information after such a change, all the source packets referenced by the first several repair packets SHOULD include such information. It is RECOMMENDED that the number of such packets is large enough to give a high probability of actual updated association. Section 4.1.1 of [RFC8285] provides relevant guidance for RTP header extension transmission considerations. Alternatively, to avoid this issue, redundancy mechanisms that directly reference its source data may be used, such as [RFC8627].
RTPStreamIDまたはRepaireDrtpStreamIDに関連付けられているSSRCがRTPセッション中に動的に変更されたときに、この間接的なデータがソースと冗長データを正しく関連付けることができないことに注意することが重要です。これは、すべてのRTPパケット、ソースおよび修復が、変更後にそれぞれRTPStreamIDまたはRepaireDrtpStreamIDを含めると回避できます。このような変更後の冗長情報の受信とユーティリティの確率を最大化するために、最初のいくつかの修復パケットによって参照されるすべてのソースパケットにそのような情報を含める必要があります。そのようなパケットの数は、実際の更新された関連付けの可能性が高いのに十分な大きさであることをお勧めします。[RFC8285]のセクション4.1.1は、RTPヘッダー拡張送信の考慮事項に関する関連ガイダンスを提供します。あるいは、この問題を回避するために、[RFC8627]などのそのソースデータを直接参照する冗長メカニズムを使用することができる。
The "direction" field identifies the direction of the RTP stream packets to which the indicated restrictions are applied. It may be either "send" or "recv". Note that these restriction directions are expressed independently of any "inactive", "sendonly", "recvonly", or "sendrecv" attributes associated with the media section. It is, for example, valid to indicate "recv" restrictions on a "sendonly" stream; those restrictions would apply if, at a future point in time, the stream were changed to "sendrecv" or "recvonly".
「方向」フィールドは、示された制限が適用されるRTPストリームパケットの方向を識別する。「送信」または「RECV」のいずれかです。これらの制限方向は、メディアセクションに関連付けられている「非アクティブ」、「SENDONLY」、「RECVONLY」、または「SENDRECV」属性とは無関係に表現されています。たとえば、 "SendOnly"ストリームの "RECV"の制限を示すことが有効です。将来的には、ストリームが "SendRecv"または "Revonly"に変更された場合、それらの制限は適用されます。
The optional "pt=<fmt-list>" lists one or more PT values that can be used in the associated RTP stream. If the "a=rid" attribute contains no "pt", then any of the PT values specified in the corresponding "m=" line may be used.
オプションの「PT = <fmt-list>」には、関連付けられているRTPストリームで使用できる1つ以上のPT値が一覧表示されます。"a = rid"属性に "Pt"が含まれていない場合、対応する "M ="行で指定されたPT値のいずれかを使用できます。
The list of zero or more codec-agnostic restrictions (Section 5) describes the restrictions that the corresponding RTP stream will conform to.
ゼロ以上のコーデックアンジネック制限のリスト（セクション5）は、対応するRTPストリームがに準拠する制限を記述します。
This framework MAY be used in combination with the "a=fmtp" SDP attribute for describing the media format parameters for a given RTP payload type. In such scenarios, the "a=rid" restrictions (Section 5) further restrict the equivalent "a=fmtp" attributes.
このフレームワークは、特定のRTPペイロードタイプのメディアフォーマットパラメータを記述するための「A = FMTP」SDP属性と組み合わせて使用することができる。このようなシナリオでは、 "A = RID"の制限（セクション5）はさらに、同等の "a = fmtp"属性を制限します。
A given SDP media description MAY have zero or more "a=rid" lines describing various possible RTP payload configurations. A given "rid-id" MUST NOT be repeated in a given media description ("m=" section).
特定のSDPメディアの説明は、様々なRTPペイロード構成を記述する0個以上の「A = RID」行を有することができる。与えられた「RID-ID」は、特定のメディアの説明（ "m ="セクション）で繰り返されてはならない。
The "a=rid" media attribute MAY be used for any RTP-based media transport. It is not defined for other transports, although other documents may extend its semantics for such transports.
"A = RID"メディア属性は、任意のRTPベースのメディアトランスポートに使用できます。他のトランスポートには定義されていませんが、その他の文書はそのようなトランスポートの意味を拡張することができます。
Though the restrictions specified by the "rid" restrictions follow a syntax similar to session-level and media-level parameters, they are defined independently. All "rid" restrictions MUST be registered with IANA, using the registry defined in Section 12.
「RID」制限によって指定された制限は、セッションレベルとメディアレベルのパラメータと同様の構文に従いますが、独立して定義されます。セクション12で定義されているレジストリを使用して、すべての「RID」制限をIANAに登録する必要があります。
Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "rid" attribute. The "a=rid" media attribute is not dependent on charset.
セクション10は、「RID」属性のための正式な増強された背景 - Naur形式（ABNF）[RFC5234]文法を与えます。"A = RID"メディア属性は文字セットに依存しません。
This section defines the "a=rid" restrictions that can be used to restrict the RTP payload encoding format in a codec-agnostic way. Please also see the preceding section for a description of how the "pt" parameter is used.
このセクションでは、Codec-Agnostic WayでRTPペイロードエンコードフォーマットを制限するために使用できる「A = RID」制限を定義します。「PT」パラメータを使用する方法については、前述のセクションも参照してください。
The following restrictions are intended to apply to video codecs in a codec-independent fashion.
以下の制限は、コーデックに依存しない方法でビデオコーデックに適用することを意図しています。
* *max-width*, for spatial resolution in pixels. In the case that stream-orientation signaling is used to modify the intended display orientation, this attribute refers to the width of the stream when a rotation of zero degrees is encoded.
* *最大幅*、空間分解能のピクセル単位の解像度。ストリーム向きシグナリングが意図された表示方向を変更するために使用される場合、この属性は、ゼロ度の回転が符号化されたときのストリームの幅を指す。
* *max-height*, for spatial resolution in pixels. In the case that stream-orientation signaling is used to modify the intended display orientation, this attribute refers to the height of the stream when a rotation of zero degrees is encoded.
* * max-height *、空間分解能のピクセル単位の解像度。ストリーム方向シグナリングが意図された表示方向を変更するために使用される場合、この属性は、ゼロ度の回転が符号化されたときのストリームの高さを指す。
* *max-fps*, for frame rate in frames per second. For encoders that do not use a fixed frame rate for encoding, this value is used to restrict the minimum amount of time between frames: the time between any two consecutive frames SHOULD NOT be less than 1/max-fps seconds.
* * max-fps *、毎秒フレームのフレームレートの場合。エンコードのための固定フレームレートを使用しないエンコーダの場合、この値はフレーム間の最小時間を制限するために使用されます。任意の2つの連続したフレーム間の時間は1 / max-fps秒未満にする必要があります。
* *max-fs*, for frame size in pixels per frame. This is the product of frame width and frame height, in pixels, for rectangular frames.
* * max-fs *、フレームごとのピクセル単位のフレームサイズ。これは、長方形のフレームのための、フレーム幅とフレームの高さ、ピクセルの積です。
* *max-br*, for bitrate in bits per second. The restriction applies to the media payload only and does not include overhead introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The exact means of keeping within this limit are left up to the implementation, and instantaneous excursions outside the limit are permissible. For any given one-second sliding window, however, the total number of bits in the payload portion of RTP SHOULD NOT exceed the value specified in "max-br."
* * MAX-BR *、毎秒ビットのビットでのビット。制限はメディアペイロードのみに適用され、他のレイヤによって導入されたオーバーヘッド（例えば、RTP、UDP、IP、またはイーサネット）は含まれていません。この制限内を保つ正確な手段は実装に遅れており、限界外の瞬間的な小留きは許容されます。ただし、任意の1秒のスライディングウィンドウでは、RTPのペイロード部分の総ビット数は、「MAX-BR」で指定された値を超えてはいけません。
* *max-pps*, for pixel rate in pixels per second. This value SHOULD be handled identically to max-fps, after performing the following conversion: max-fps = max-pps / (width * height). If the stream resolution changes, this value is recalculated. Due to this recalculation, excursions outside the specified maximum are possible near resolution-change boundaries.
* * max-pps *、1秒あたりのピクセル数のピクセルレート。次の変換を実行した後、この値はMAX-FPSと同じに処理されます.max-fps = max-pps /（幅*高さ）。ストリーム解像度が変わると、この値は再計算されます。この再計算のために、指定された最大の外側の遠足は分解能変化境界の近くで可能である。
* *max-bpp*, for maximum number of bits per pixel, calculated as an average of all samples of any given coded picture. This is expressed as a floating point value, with an allowed range of 0.0001 to 48.0. These values MUST NOT be encoded with more than four digits to the right of the decimal point.
* * MAX-BPP *は、1ピクセルあたりの最大ビット数の場合、特定のコード化ピクチャのすべてのサンプルの平均として計算されます。これは浮動小数点値として表され、許容された範囲は0.0001から48.0である。これらの値は、小数点の右側に4桁以上符号化されてはいけません。
* *depend*, to identify other streams that the stream depends on. The value is a comma-separated list of rid-ids. These rid-ids identify RTP streams that this stream depends on in order to allow for proper interpretation. The mechanism defined in this document allows for such dependencies to be expressed only when the streams are in the same media section.
* *ストリームが依存する他のストリームを識別するには*依存します。値はRID-IDのコンマ区切りリストです。これらのRID-IDSは、適切な解釈を可能にするために、このストリームが依存するRTPストリームを識別します。この文書で定義されているメカニズムは、ストリームが同じメディアセクションにある場合にのみ、そのような依存関係を表現することを可能にします。
All the restrictions are optional and subject to negotiation based on the SDP offer/answer rules described in Section 6.
すべての制限はオプションであり、セクション6で説明されているSDPオファー/回答規則に基づいて交渉を受けます。
This list is intended to be an initial set of restrictions. Future documents may define additional restrictions; see Section 12.2. While this document does not define restrictions for audio codecs or any media types other than video, there is no reason such restrictions should be precluded from definition and registration by other documents.
このリストは制限の初期セットになることを目的としています。将来の文書は追加の制限を定義するかもしれません。12.2項を参照してください。この文書はオーディオコーデックまたはビデオ以外のメディアタイプの制限を定義していませんが、そのような制限を他の文書による定義と登録から排除する必要はありません。
Section 10 provides formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for each of the "a=rid" restrictions defined in this section.
セクション10は、このセクションで定義されている「A = RID」制限のそれぞれについて、正式な拡張バックス - ナウラス（ABNF）[RFC5234]文法を提供します。
This section describes the SDP offer/answer procedures [RFC3264] when using this framework.
このセクションでは、このフレームワークを使用する場合のSDPオファー/アンサープロシージャ[RFC3264]について説明します。
Note that "rid-id" values are only required to be unique within a media section ("m=" line); they do not necessarily need to be unique within an entire RTP session. In traditional usage, each media section is sent on its own unique 5-tuple (that is: combination of sending address, sending port, receiving address, receiving port, and transport protocol), which provides an unambiguous scope. Similarly, when using BUNDLE [RFC8843], Media Identification (MID) values associate RTP streams uniquely to a single media description. When restriction identifier (RID) is used with the BUNDLE mechanism, streams will be associated with both MID and RID SDES items.
「RID-ID」の値は、メディアセクション内で一意であることだけが必要です（ "m ="行）。それらは必ずしもRTPセッション全体内で一意である必要はありません。従来の使用法では、各メディアセクションは独自の固有の5タプル（つまり、送信アドレス、送信ポート、受信アドレス、受信ポート、およびトランスポートプロトコルの組み合わせ）で送信されます。同様に、バンドル[RFC8843]を使用する場合、メディア識別（MID）値はRTPストリームを単一のメディア記述に一意に関連付けます。制限識別子（RID）がバンドルメカニズムで使用されている場合、ストリームはMID SDESアイテムとRID SDESアイテムの両方に関連付けられます。
For each RTP media description in the offer, the offerer MAY choose to include one or more "a=rid" lines to specify a configuration profile for the given set of RTP payload types.
オファーの各RTPメディアの説明について、提供者は、指定されたRTPペイロード・タイプの特定のセットの構成プロファイルを指定するための1つ以上の "A = RID"行を含むことを選択できます。
In order to construct a given "a=rid" line, the offerer must follow these steps:
与えられた「A = RID」行を作成するために、オファーは次のステップに従わなければなりません。
1. It MUST generate a "rid-id" that is unique within a media description.
1. メディアの説明内で一意である「RID-ID」を生成する必要があります。
2. It MUST set the direction for the "rid-id" to one of "send" or "recv".
2. 「RID-ID」の方向を「送信」または「RECV」のいずれかに設定する必要があります。
3. It MAY include a listing of SDP media formats (usually corresponding to RTP payload types) allowed to appear in the RTP stream. Any payload type chosen MUST be a valid payload type for the media section (that is, it must be listed on the "m=" line). The order of the listed formats is significant; the alternatives are listed from (left) most preferred to (right) least preferred. When using RID, this preference overrides the normal codec preference as expressed by format type ordering on the "m=" line, using regular SDP rules.
3. RTPストリームに表示されるように許可されているSDPメディアフォーマット（通常はRTPペイロードタイプに対応する）のリストを含めることができます。選択されたペイロードタイプは、メディアセクションの有効なペイロードタイプでなければなりません（つまり、「M =」行にリストされている必要があります）。リストされているフォーマットの順序は重要です。代替案は（左）から（右）に最も優先され、最小の好ましいものからリストされています。RIDを使用する場合、この設定は通常のSDPルールを使用して、 "m ="行のフォーマットタイプ順に表されるように、通常のコーデックの設定を上書きします。
4. The offerer then chooses zero or more "a=rid" restrictions (Section 5) to be applied to the RTP stream and adds them to the "a=rid" line.
4. その後、オファーは、RTPストリームに適用され、それらを "A = RID"行に追加するために、0個以上の "A = RID"制限（セクション5）を選択します。
5. If the offerer wishes the answerer to have the ability to specify a restriction but does not wish to set a value itself, it includes the name of the restriction in the "a=rid" line, but without any indicated value.
5. オファーが回答者に制限を指定する能力を望んでいるが、値自体を設定したくない場合は、「A = RID」行の制限の名前が含まれていますが、指定された値が含まれています。
Note: If an "a=fmtp" attribute is also used to provide media-format-specific parameters, then the "a=rid" restrictions will further restrict the equivalent "a=fmtp" parameters for the given payload type for the specified RTP stream.
注：「A = FMTP」属性もメディアフォーマット固有のパラメータを提供するためにも使用されている場合、 "A = RID"の制限は、指定されたRTPの指定されたペイロードタイプの等価 "A = FMTP"パラメータをさらに制限します。ストリーム。
If a given codec would require an "a=fmtp" line when used without "a=rid", then the offer MUST include a valid corresponding "a=fmtp" line even when using "a=rid".
指定されたコーデックが "A = RID"なしで使用すると "a = fmtp"行を必要とする場合、オファーは "A = RID"を使用しても有効な対応する "a = fmtp"行を含める必要があります。
If the receiver doesn't support the framework defined in this specification, the entire "a=rid" line is ignored following the standard offer/answer rules [RFC3264].
受信側がこの仕様で定義されたフレームワークをサポートしていない場合は、標準オファー/アンサールール[RFC3264]に従って、 "A = RID"行全体が無視されます。
Section 6.1 requires the offer to include a valid "a=fmtp" line for any media formats that otherwise require it (in other words, the "a=rid" line cannot be used to replace "a=fmtp" configuration). As a result, ignoring the "a=rid" line is always guaranteed to result in a valid session description.
セクション6.1では、そうでなければ必要とするメディアフォーマットの有効な "A = FMTP"行を含める必要があります（言い換えれば、 "A = RID"行を使用して "a = fmtp"構成を置き換えることはできません）。その結果、 "A = RID"行を無視することは常に有効なセッションの説明をもたらすことが保証されています。
If the answerer supports the "a=rid" attribute, the following verification steps are executed, in order, for each "a=rid" line in a received offer:
回答者が「A = RID」属性をサポートしている場合、受信したオファーの各「A = RID」回線ごとに、以下の検証手順が実行されます。
1. The answerer ensures that the "a=rid" line is syntactically well formed. In the case of a syntax error, the "a=rid" line is discarded.
1. 回答者は、「A = RID」線が構文的によく形成されていることを保証する。構文エラーの場合、 "A = RID"行は破棄されます。
2. The answerer extracts the rid-id from the "a=rid" line and verifies its uniqueness within a media section. In the case of a duplicate, the entire "a=rid" line, and all "a=rid" lines with rid-ids that duplicate this line, are discarded and MUST NOT be included in the SDP answer.
2. 回答者は「A = RID」行からRID-IDを抽出し、メディアセクション内のその一意性を検証します。重複の場合、 "A = RID"行全体、およびこの行を複製するRID-IDを持つすべての "A = RID"行は破棄され、SDPの回答に含まれてはいけません。
3. If the "a=rid" line contains a "pt=", the list of payload types is verified against the list of valid payload types for the media section (that is, those listed on the "m=" line). Any PT missing from the "m=" line is discarded from the set of values in the "pt=". If no values are left in the "pt=" parameter after this processing, then the "a=rid" line is discarded.
3. "A = RID"行に "pt ="が含まれている場合、ペイロードタイプのリストは、メディアセクションの有効なペイロードタイプのリスト（つまり、 "m ="行にリストされているもの）に対して検証されます。「M =」回線から欠けているPTは、「PT =」の値のセットから破棄されます。この処理の後に「Pt =」パラメータに値が残っていない場合は、 "A = RID"行を破棄します。
4. If the "direction" field is "recv", the answerer ensures that the specified "a=rid" restrictions are supported. In the case of an unsupported restriction, the "a=rid" line is discarded.
4. 「方向」フィールドが「RECV」の場合、回答者は指定された「A = RID」の制限がサポートされていることを保証します。サポートされていない制限の場合、「A = RID」行は破棄されます。
5. If the "depend" restriction is included, the answerer MUST make sure that the listed rid-ids unambiguously match the rid-ids in the media description. Any "depend" "a=rid" lines that do not are discarded.
5. 「依存」制限が含まれている場合、回答者は、リストされているRID-IDがメディア記述内のRID-IDと明確に一致することを確認する必要があります。廃棄されない「依存」「a = RID」行。
6. The answerer verifies that the restrictions are consistent with at least one of the codecs to be used with the RTP stream. If the "a=rid" line contains a "pt=", it contains the list of such codecs; otherwise, the list of such codecs is taken from the associated "m=" line. See Section 8 for more detail. If the "a=rid" restrictions are incompatible with the other codec properties for all codecs, then the "a=rid" line is discarded.
6. 回答者は、制限がRTPストリームと共に使用されるべき少なくとも1つのコーデックと一致していることを検証する。"a = rid"行に "pt ="が含まれている場合、そのようなコーデックのリストが含まれています。そうでなければ、そのようなコーデックのリストは関連する「M =」行から取られる。詳細についてはセクション8を参照してください。"A = RID"の制限がすべてのコーデックの他のコーデックプロパティと互換性がない場合は、 "A = RID"行が破棄されます。
Note that the answerer does not need to understand every restriction present in a "send" line: if a stream sender restricts the stream in a way that the receiver does not understand, this causes no issues with interoperability.
回答者が「送信」行に存在するすべての制限を理解する必要はありません。ストリーム送信者が受信者が理解できない方法でストリームを制限する場合、これは相互運用性に関する問題を引き起こすことはありません。
Having performed verification of the SDP offer as described in Section 6.2.2, the answerer shall perform the following steps to generate the SDP answer.
6.2.2のSDPオファーの検証を実行した場合、回答者はSDP回答を生成するために以下のステップを実行しなければならない。
For each "a=rid" line that has not been discarded by previous processing:
前の処理によって破棄されていない「A = RID」行ごとに：
1. The value of the "direction" field is reversed: "send" is changed to "recv", and "recv" is changed to "send".
1. 「Direction」フィールドの値が反転されます。 "Send"が "RECV"に変更され、 "RECV"が "SEND"に変更されます。
2. The answerer MAY choose to modify specific "a=rid" restriction values in the answer SDP. In such a case, the modified value MUST be more restrictive than the ones specified in the offer. The answer MUST NOT include any restrictions that were not present in the offer.
2. 回答者は、回答SDP内の特定の「A = RID」制限値を変更することを選択することができる。そのような場合、変更された値はオファーで指定されたものよりも制限的でなければなりません。答えには、申し出には存在しなかった制限を含めてはいけません。
3. The answerer MUST NOT modify the "rid-id" present in the offer.
3. 回答者はオファーに存在する「RID-ID」を変更してはいけません。
4. If the "a=rid" line contains a "pt=", the answerer is allowed to discard one or more media formats from a given "a=rid" line. If the answerer chooses to discard all the media formats from an "a=rid" line, the answerer MUST discard the entire "a=rid" line. If the offer did not contain a "pt=" for a given "a=rid" line, then the answer MUST NOT contain a "pt=" in the corresponding line.
4. 「A = RID」回線が「PT =」を含む場合、回答者は特定の「A = RID」行から1つ以上のメディアフォーマットを破棄することを許可されている。回答者が "A = RID"行からすべてのメディアフォーマットを破棄することを選択した場合、回答者は "A = RID"行全体を破棄しなければなりません。指定された「A = RID」行の場合、オファーに「PT =」が含まれていない場合、答えには対応する行の「PT =」を含めることはできません。
5. In cases where the answerer is unable to support the payload configuration specified in a given "a=rid" line with a direction of "recv" in the offer, the answerer MUST discard the corresponding "a=rid" line. This includes situations in which the answerer does not understand one or more of the restrictions in an "a=rid" line with a direction of "recv".
5. オファーで「RECV」の方向を持つ指定された「A = RID」行で指定されたペイロード構成をサポートできない場合、回答者は対応する "A = RID"行を破棄しなければなりません。これには、回答者が「RECV」の方向を有する「A = RID」行の1つ以上の制限を理解していない状況を含む。
Note: In the case that the answerer uses different PT values to represent a codec than the offerer did, the "a=rid" values in the answer use the PT values that are present in its answer.
注意：回答者がオファーよりもコーデックを表すために異なるPT値を使用した場合、回答内の「A = RID」の値はその回答に存在するPT値を使用します。
The offerer SHALL follow these steps when processing the answer:
答えを処理するときに、オファーは次の手順に従うものとします。
1. The offerer matches the "a=rid" line in the answer to the "a=rid" line in the offer using the "rid-id". If no matching line can be located in the offer, the "a=rid" line is ignored.
1. オファーは、「RID-ID」を使用してオファーの「A = RID」行に答えの「A = RID」行と一致します。オファーに一致する行が見つからない場合は、 "A = RID"行が無視されます。
2. If the answer contains any restrictions that were not present in the offer, then the offerer SHALL discard the "a=rid" line.
2. 答えに申し出に存在しなかった制限が含まれている場合、オファーは「A = RID」行を破棄する。
3. If the restrictions have been changed between the offer and the answer, the offerer MUST ensure that the modifications are more restrictive than they were in the original offer and that they can be supported; if not, the offerer SHALL discard the "a=rid" line.
3. オファーと答えの間で制限が変更された場合、オファーは、修正が元のオファーにあるよりも制限があること、およびサポートできることを確認する必要があります。そうでなければ、オファーは「A = RID」ラインを破棄する。
4. If the "a=rid" line in the answer contains a "pt=" but the offer did not, the offerer SHALL discard the "a=rid" line.
4. 答えの「a = RID」回線に「Pt =」が含まれていますが、オファーはそうではなかった場合、オファーは「A = RID」ラインを破棄します。
5. If the "a=rid" line in the answer contains a "pt=" and the offer did as well, the offerer verifies that the list of payload types is a subset of those sent in the corresponding "a=rid" line in the offer. Note that this matching must be performed semantically rather than on literal PT values, as the remote end may not be using symmetric PTs. For the purpose of this comparison: for each PT listed on the "a=rid" line in the answer, the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" lines in the answer. It then searches the list of "pt=" values indicated in the offer and attempts to find one with an equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If all PTs in the answer can be matched, then the "pt=" values pass validation; otherwise, it fails. If this validation fails, the offerer SHALL discard the "a=rid" line. Note that this semantic comparison necessarily requires an understanding of the meaning of codec parameters, rather than a rote byte-wise comparison of their values.
5. 答えの「a = RID」回線に "Pt ="が含まれていて、オファーも含まれている場合、オファーはペイロードタイプのリストが対応する "A = RID"行のサブセットであることを確認します。提供。リモートエンドが対称PTSを使用していない可能性があるため、このマッチングはリテラルPT値ではなく意味的に実行する必要があります。この比較の目的のために：答えの「A = RID」行にリストされている各Ptについて、オファーは答えの対応する "a = rtpmap"と "a = fmtp"行を調べます。その後、オファーに示されている「PT =」の値のリストを検索し、オファー内の「a = rtpmap」と「a = fmtp」行の同等のセットを持つものを見つけようとします。回答内のすべてのPTSを一致させることができれば、「PT =」の値は検証を渡します。それ以外の場合は失敗します。この検証が失敗した場合、オファーは「A = RID」行を破棄する。この意味的比較は、それらの値のバイト単位比較ではなく、コーデックパラメータの意味を理解する必要があることに注意してください。
6. If the "a=rid" line contains a "pt=", the offerer verifies that the attribute values provided in the "a=rid" attributes are consistent with the corresponding codecs and their other parameters. See Section 8 for more detail. If the "a=rid" restrictions are incompatible with the other codec properties, then the offerer SHALL discard the "a=rid" line.
6. 「A = RID」回線に「PT =」が含まれている場合、オファーは「A = RID」属性に提供された属性値が対応するコーデックとその他のパラメータと一致していることを確認します。詳細についてはセクション8を参照してください。「A = RID」制限が他のコーデックプロパティと互換性がない場合、オファーは「A = RID」行を破棄する。
7. The offerer verifies that the restrictions are consistent with at least one of the codecs to be used with the RTP stream. If the "a=rid" line contains a "pt=", it contains the list of such codecs; otherwise, the list of such codecs is taken from the associated "m=" line. See Section 8 for more detail. If the "a=rid" restrictions are incompatible with the other codec properties for all codecs, then the offerer SHALL discard the "a=rid" line.
7. オファーは、制限がRTPストリームで使用されるコーデックのうちの少なくとも1つと一致していることを確認します。"a = rid"行に "pt ="が含まれている場合、そのようなコーデックのリストが含まれています。そうでなければ、そのようなコーデックのリストは関連する「M =」行から取られる。詳細についてはセクション8を参照してください。"A = RID"の制限がすべてのコーデックの他のコーデックプロパティと互換性がない場合、オファーは "A = RID"行を破棄するものとします。
Any "a=rid" line present in the offer that was not matched by step 1 above has been discarded by the answerer and does not form part of the negotiated restrictions on an RTP stream. The offerer MAY still apply any restrictions it indicated in an "a=rid" line with a direction field of "send", but it is not required to do so.
上記のステップ1と一致しなかったオファーに存在する「A = RID」回線は、回答者によって破棄されており、RTPストリームに対するネゴシエートされた制限の一部を形成していません。オファーは、「A = RID」行に示されている制限を依然として適用することができますが、「SEND」の方向フィールドの方向フィールドを適用する必要はありませんが、そうする必要はありません。
It is important to note that there are several ways in which an offer can contain a media section with "a=rid" lines, although the corresponding media section in the response does not. This includes situations in which the answerer does not support "a=rid" at all or does not support the indicated restrictions. Under such circumstances, the offerer MUST be prepared to receive a media stream to which no restrictions have been applied.
応答の対応するメディアセクションは、「A = RID」行を使用してメディアセクションを含めることができるいくつかの方法があることに注意することが重要です。これには、回答者が全く「A = RID」をサポートしていない状況が含まれているか、または示された制限をサポートしていません。このような状況下では、提供者は制限が適用されていないメディアストリームを受信するように準備しなければならない。
Offers and answers inside an existing session follow the rules for initial session negotiation. Such an offer MAY propose a change in the number of RIDs in use. To avoid race conditions with media, any RIDs with proposed changes SHOULD use a new ID rather than reusing one from the previous offer/answer exchange. RIDs without proposed changes SHOULD reuse the ID from the previous exchange.
既存のセッション内部のオファーと回答は、最初のセッションネゴシエーションのための規則に従います。そのようなオファーは、使用中のRIDの数の変化を提案することができる。メディアでの競合状態を避けるために、提案された変更を伴うRIDは、前のオファー/回答Exchangeから再利用するのではなく、新しいIDを使用する必要があります。提案された変更なしのRIDは、前の交換からIDを再利用する必要があります。
This document does not define the use of a RID in declarative SDP. If concrete use cases for RID in declarative SDP use are identified in the future, we expect that additional specifications will address such use.
この文書は、宣言型SDPのRIDの使用を定義していません。将来的に宣言的なSDPの使用を取り除くための具体的なユースケースが識別された場合、そのような使用のために追加の仕様が取り組むことを期待しています。
Historically, a number of other approaches have been defined that allow restricting media streams via SDP. These include:
歴史的に、SDPを介してメディアストリームを制限することを可能にする他のいくつかのアプローチが定義されています。これらは以下のとおりです。
* Codec-specific configuration set via format parameters ("a=fmtp") -- for example, the H.264 "max-fs" format parameter [RFC6184]
* コーデック固有の構成フォーマットパラメータ（ "A = FMTP"）を介して設定します - 例えば、H.264 "MAX-FS"フォーマットパラメータ[RFC6184]
* Size restrictions imposed by the "a=imageattr" attribute [RFC6236]
* "A = ImageAttr"属性[RFC6236]によって課されるサイズ制限
When the mechanism described in this document is used in conjunction with these other restricting mechanisms, it is intended to impose additional restrictions beyond those communicated in other techniques.
この文書に記載されているメカニズムがこれらの他の制限メカニズムと組み合わせて使用されるとき、それは他の技術で伝達されたものを超えて追加の制限を課すことを意図している。
In an offer, this means that "a=rid" lines, when combined with other restrictions on the media stream, are expected to result in a non-empty intersection. For example, if image attributes are used to indicate that a PT has a minimum width of 640, then specification of "max-width=320" in an "a=rid" line that is then applied to that PT is nonsensical. According to the rules of Section 6.2.2, this will result in the corresponding "a=rid" line being ignored by the recipient.
オファーでは、これは、メディアストリームの他の制限と組み合わされたときの「A = RID」行が、空でない交差点をもたらすと予想されます。例えば、PTが最小幅640の幅を有することを示すために画像属性が使用される場合、その後、そのPTに適用される「A = RID」行の「max width = 320」の指定は無意味である。セクション6.2.2の規則によると、これは対応する "A = RID"行が受信者によって無視されます。
In an answer, the "a=rid" lines, when combined with the other restrictions on the media stream, are also expected to result in a non-empty intersection. If the implementation generating an answer wishes to restrict a property of the stream below that which would be allowed by other parameters (e.g., those specified in "a=fmtp" or "a=imageattr"), its only recourse is to discard the "a=rid" line altogether, as described in Section 6.3. If it instead attempts to restrict the stream beyond what is allowed by other mechanisms, then the offerer will ignore the corresponding "a=rid" line, as described in Section 6.4.
回答では、メディアストリームの他の制限と組み合わせると、「A = RID」行は、空ではない交差点をもたらすと予想されます。回答を生成する実装が、他のパラメータ（例えば、 "A = FMTP"で指定されたもの、または "A = ImageAttr"で指定されたもののようなストリームのプロパティを制限したい場合、その唯一の頼みは「廃棄する」です。6.3節に記載されているように、A = RID "ライン。代わりに他のメカニズムによって許されるものを超えてストリームを制限しようとすると、セクション6.4で説明されているように、オファーは対応する "A = RID"行を無視します。
The following subsections demonstrate these interactions using commonly used video codecs. These descriptions are illustrative of the interaction principles outlined above and are not normative.
次のサブセクションでは、一般的に使用されているビデオコーデックを使用したこれらの相互作用を示しています。これらの説明は、上で概説されており、規範的ではない相互作用原理の説明である。
[RFC7741] defines two format parameters for the VP8 codec. Both correspond to restrictions on receiver capabilities and never indicate sending restrictions.
[RFC7741] VP8コーデックの2つのフォーマットパラメーターを定義します。どちらもレシーバ機能の制限に対応し、送信制限を示すことはありません。
The VP8 "max-fr" format parameter corresponds to the "max-fps" restriction defined in this specification. If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fps" parameter, then the sent stream will conform to the smaller of the two values.
VP8 "MAX-FR"フォーマットパラメータは、この仕様で定義されている「MAX-FPS」制限に対応しています。RTP送信者がこの形式パラメータで定義された形式を使用してストリームを生成し、 "A = RID"を介して定義された送信制限は "MAX-FPS"パラメータを含み、送信されたストリームは2つの値の小さい方に準拠します。。
The VP8 "max-fs" format parameter corresponds to the "max-fs" restriction defined in this document, by way of a conversion factor of the number of pixels per macroblock (typically 256). If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fs" parameter, then the sent stream will conform to the smaller of the two values; that is, the number of pixels per frame will not exceed:
VP8「MAX - FS」フォーマットパラメータは、マクロブロックごとのピクセル数の変換係数を介して、この文書で定義された「MAX-FS」制限に対応する（典型的には256）。RTP送信側がこの形式パラメータで定義された形式を使用してストリームを生成し、 "A = RID"を介して定義された送信制限は "MAX-FS"パラメータを含み、送信されたストリームは2つの値の小さい方に準拠します。;つまり、1フレームあたりのピクセル数は：
min(rid_max_fs, fmtp_max_fs * macroblock_size)
Min（RID_MAX_FS、FMTP_MAX_FS * MACROBLOCK_SIZE）
This fmtp parameter also has bearing on the max-height and max-width parameters. Section 6.1 of [RFC7741] requires that the width and height of the frame in macroblocks be less than int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width of a transmitted stream will be limited to:
このFMTPパラメーターは、最大高さおよび最大幅のパラメータにもあります。[RFC7741]のセクション6.1では、マクロブロック内のフレームの幅と高さがintより小さいことが必要です（SQRT（FMTP_MAX_FS * 8））。したがって、送信されたストリームの最大幅は次のように制限されます。
min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width)
Similarly, the stream's height will be limited to:
同様に、ストリームの高さは次のように制限されます。
min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height)
[RFC6184] defines format parameters for the H.264 video codec. The majority of these parameters do not correspond to codec-independent restrictions:
[RFC6184] H.264ビデオコーデックのフォーマットパラメータを定義します。これらのパラメータの大部分はコーデックに依存しない制限に対応していません。
* deint-buf-cap
* Deint-Buf-Cap.
* in-band-parameter-sets
* インバンドパラメータセット
* level-asymmetry-allowed
* レベル非対称性 - 許可されています
* max-rcmd-nalu-size
* MAX-RCMD-NALUサイズ
* max-cpb
* MAX-CPB.
* max-dpb
* MAX-DPB
* packetization-mode
* パケット化モード
* redundant-pic-cap
* 冗長PICキャップ
* sar-supported
* SAR支援
* sar-understood
* SAR理解
* sprop-deint-buf-req
* Sprop-Deint-Buf-Req
* sprop-init-buf-time
* スプロップinit-buf-time
* sprop-interleaving-depth
* スプロップインターリーブ深さ
* sprop-level-parameter-sets
* Spropレベルパラメータセット
* sprop-max-don-diff
* Sprop-Max-Don-Diff
* sprop-parameter-sets
* Sprop-Parameter-Sets.
* use-level-src-parameter-sets
* use-level-src-parameter-sets.
Note that the max-cpb and max-dpb format parameters for H.264 correspond to restrictions on the stream, but they are specific to the way the H.264 codec operates, and do not have codec-independent equivalents.
H.264のMAX-CPBフォーマットパラメータとMAX-DPBフォーマットパラメータはストリーム上の制限に対応していますが、H.264コーデックの動作方法に固有のもので、コーデックに依存しない均等物はありません。
The [RFC6184] codec format parameters covered in the following sections correspond to restrictions on receiver capabilities and never indicate sending restrictions.
次のセクションで説明されている[RFC6184]コーデックフォーマットパラメータは、受信側機能の制限に対応し、送信制限を示すことはありません。
These parameters include a "level" indicator, which acts as an index into Table A-1 of [H264]. This table contains a number of parameters, several of which correspond to the restrictions defined in this document. [RFC6184] also defines format parameters for the H.264 codec that may increase the maximum values indicated by the negotiated level. The following sections describe the interaction between these parameters and the restrictions defined by this document. In all cases, the H.264 parameters being discussed are the maximum of those indicated by [H264] Table A-1 and those indicated in the corresponding "a=fmtp" line.
これらのパラメータには、[H264]の表A-1へのインデックスとして機能する「レベル」インジケータが含まれています。このテーブルにはいくつかのパラメータが含まれています。そのうちのいくつかは、このドキュメントで定義されている制限に対応しています。[RFC6184]ネゴシエートされたレベルで示される最大値を増やす可能性があるH.264コーデックのフォーマットパラメータも定義します。次のセクションでは、これらのパラメータとこのドキュメントによって定義されている制限の間の相互作用について説明します。全ての場合において、議論されているH.264パラメータは、[H264]表A - 1で示される最大値、対応する「A = FMTP」行に示されている最大である。
The H.264 "MaxBR" parameter (and its equivalent "max-br" format parameter) corresponds to the "max-bps" restriction defined in this specification, by way of a conversion factor of 1000 or 1200; see [RFC6184] for details regarding which factor gets used under differing circumstances.
H.264「MAXBR」パラメータ（およびその等価 "MAX-BR"フォーマットパラメータ）は、1000または1200の変換係数によって、この仕様で定義されている「MAX-BPS」制限に対応しています。どの因子が異なる状況下で使用されるかについての詳細については、[RFC6184]を参照してください。
If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fps" parameter, then the sent stream will conform to the smaller of the two values -- that is:
RTP送信者がこの形式パラメータで定義された形式を使用してストリームを生成し、 "A = RID"を介して定義された送信制限は "MAX-FPS"パラメータを含み、送信されたストリームは2つの値の小さい方に準拠します。 - あれは：
min(rid_max_br, h264_MaxBR * conversion_factor)
min（rid_max_br、h264_maxbr * conversion_factor）
The H.264 "MaxFs" parameter (and its equivalent "max-fs" format parameter) corresponds roughly to the "max-fs" restriction defined in this document, by way of a conversion factor of 256 (the number of pixels per macroblock).
H.264「MAXFS」パラメータ（およびその同等の "MAX-FS"フォーマットパラメータ）は、このドキュメントで定義されている「MAX-FS」制限には、256の変換係数によって、（マクロブロックごとのピクセル数））。
If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fs" parameter, then the sent stream will conform to the smaller of the two values -- that is:
RTP送信側がこの形式パラメータで定義された形式を使用してストリームを生成し、 "A = RID"を介して定義された送信制限は "MAX-FS"パラメータを含み、送信されたストリームは2つの値の小さい方に準拠します。 - あれは：
min(rid_max_fs, h264_MaxFs * 256)
Min（RID_MAX_FS、H264_MAXFS * 256）
The H.264 "MaxMBPS" parameter (and its equivalent "max-mbps" format parameter) corresponds roughly to the "max-pps" restriction defined in this document, by way of a conversion factor of 256 (the number of pixels per macroblock).
H.264「MAXMbps」パラメータ（およびその等価 "MAX-MBPS"フォーマットパラメータ）は、この文書で定義されている「MAX-PPS」制限には、256の変換係数によって定義されます（マクロブロックごとのピクセル数）。
If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-pps" parameter, then the sent stream will conform to the smaller of the two values -- that is:
RTP送信者がこの形式パラメータで定義された形式を使用してストリームを生成し、 "A = RID"を介して定義された送信制限は "MAX-PPS"パラメータを含み、送信されたストリームは2つの値の小さい方に準拠します。 - あれは：
min(rid_max_pps, h264_MaxMBPS * 256)
MIN（RID_MAX_PPS、H264_MAXMBPS * 256）
The H.264 "max-smbps" format parameter operates the same way as the "max-mbps" format parameter, under the hypothetical assumption that all macroblocks are static macroblocks. It is handled by applying the conversion factor described in Section 8.1 of [RFC6184], and the result of this conversion is applied as described in Section 8.2.4.
H.264「MAX-SMBPS」フォーマットパラメータは、すべてのマクロブロックが静的マクロブロックであることを仮定した仮定の下で、「MAX-MBPS」フォーマットパラメータと同じ方法で動作します。[RFC6184]のセクション8.1で説明されている変換係数を適用することによって処理され、この変換の結果はセクション8.2.4に記載されているように適用されます。
Section 4 specifies that redundancy formats using redundancy RTP streams bind the redundancy RTP stream to the source RTP stream with either the RepairedRtpStreamId SDES item or other mechanisms. However, there exist redundancy RTP payload formats that result in the redundancy being included in the source RTP stream. An example of this is "RTP Payload for Redundant Audio Data" [RFC2198], which encapsulates one source stream with one or more redundancy streams in the same RTP payload. Formats defining the source and redundancy encodings as regular RTP payload types require some consideration for how the "a=rid" restrictions are defined. The "a=rid" line "pt=" parameter can be used to indicate whether the redundancy RTP payload type and/or the individual source RTP payload type(s) are part of the restriction.
セクション4冗長RTPストリームを使用している冗長フォーマットは、RepaireDrtpStreamID SDES項目または他のメカニズムのいずれかで、冗長RTPストリームをソースRTPストリームにバインドすることを指定します。ただし、ソースRTPストリームに冗長性が含まれている冗長性RTPペイロードフォーマットが存在します。この例は、同じRTPペイロード内の1つ以上の冗長ストリームを1つ以上のソースストリームをカプセル化する「冗長オーディオデータのRTPペイロード」です。通常のRTPペイロードタイプとしてソースエンコードと冗長エンコードを定義する形式では、「A = RID」の制限がどのように定義されるかについての考慮が必要です。"A = RID"行 "PT ="パラメータを使用して、冗長RTPペイロードタイプおよび/または個々のソースRTPペイロードタイプが制限の一部であるかどうかを示すために使用できます。
Example (SDP excerpt):
例（SDP抜粋）：
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:5 send pt=99,102;max-br=64000
a=rid:6 send pt=100,97,101,102
The RID with ID=6 restricts the payload types for this RID to 100 (the redundancy format), 97 (G.711), 101 (Comfort Noise), and 102 (dual-tone multi-frequency (DTMF) tones). This means that RID 6 can either contain the Redundant Audio Data (RED) format, encapsulating encodings of the source media stream using payload type 97 and 98, 97 without RED encapsulation, Comfort noise, or DTMF tones. Payload type 98 is not included in the RID, and can thus not be sent except as redundancy information in RED encapsulation. If 97 were to be excluded from the pt parameter, it would instead mean that payload types 97 and 98 are only allowed via RED encapsulation.
ID = 6のRIDは、このRIDのペイロードタイプを100（冗長形式）、97（G.711）、101（Comfort Noise）、102（デュアルトーンマルチ周波数（DTMF）トーン）に制限します。つまり、RID 6は、レッドカプセル化、快適なノイズ、またはDTMFトーンなしでペイロードタイプ97と98,97を使用して、ソースメディアストリームのエンコーディングを冗長オーディオデータ（RED）フォーマットをカプセル化できます。ペイロードタイプ98はRIDに含まれていないため、赤いカプセル化の冗長性情報としては送信できません。97がPTパラメータから除外されることになっている場合、それは代わりにペイロードタイプ97および98が赤カプセル化によってのみ許可されることを意味するであろう。
Registrations of future RTP payload format specifications that define media types that have parameters matching the RID restrictions specified in this memo SHOULD name those parameters in a manner that matches the names of those RID restrictions and SHOULD explicitly state what media-type parameters are restricted by what RID restrictions.
将来のRTPペイロードフォーマットの登録このメモに指定されたRID制限に一致するパラメータを持つメディアタイプを定義する仕様は、これらのRISの制限の名前と一致する方法でこれらのパラメータを名前にし、明示的にどのようなメディアタイプのパラメータが制限されているかを明示的に述べる必要があります。制限を取り除きます。
This section gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar, with the case-sensitive extensions described in [RFC7405], for each of the new media and "a=rid" attributes defined in this document.
このセクションでは、この文書のそれぞれについて、[RFC7405]、[RFC7405]に記載されている大文字と小文字を区別する拡張機能が正式な拡張されたBackus-Naur Form（ABNF）[RFC5234]文法を示します。
rid-syntax = %s"a=rid:" rid-id SP rid-dir
[ rid-pt-param-list / rid-param-list ]
rid-id = 1*(alpha-numeric / "-" / "_")
alpha-numeric = < as defined in [RFC4566] >
rid-dir = %s"send" / %s"recv"
rid-pt-param-list = SP rid-fmt-list *(";" rid-param)
rid-param-list = SP rid-param *(";" rid-param)
rid-fmt-list = %s"pt=" fmt *( "," fmt )
fmt = < as defined in [RFC4566] >
rid-param = rid-width-param
/ rid-height-param
/ rid-fps-param
/ rid-fs-param
/ rid-br-param
/ rid-pps-param
/ rid-bpp-param
/ rid-depend-param
/ rid-param-other
rid-width-param = %s"max-width" [ "=" int-param-val ]
rid-height-param = %s"max-height" [ "=" int-param-val ]
rid-fps-param = %s"max-fps" [ "=" int-param-val ]
rid-fs-param = %s"max-fs" [ "=" int-param-val ]
rid-br-param = %s"max-br" [ "=" int-param-val ]
rid-pps-param = %s"max-pps" [ "=" int-param-val ]
rid-bpp-param = %s"max-bpp" [ "=" float-param-val ]
rid-depend-param = %s"depend=" rid-list
rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ]
rid-list = rid-id *( "," rid-id )
RID-LIST = RID-ID *（ "、" RID-ID）
int-param-val = 1*DIGIT
float-param-val = 1*DIGIT "." 1*DIGIT
param-val = *(%x20-3A / %x3C-7E)
; Any printable character except semicolon
Note: See [RFC8853] for examples of RID used in simulcast scenarios.
注：Simulcastシナリオで使用されるRIDの例については、[RFC8853]を参照してください。
In this scenario, the offerer supports the Opus, G.722, G.711, and DTMF audio codecs and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC (SCBP/SCHP), and H.265 (MP/M10P) for video. An 8-way video call (to a mixer) is supported (send 1 and receive 7 video streams) by offering 7 video media sections (1 sendrecv at max resolution and 6 recvonly at smaller resolutions), all bundled on the same port, using 3 different resolutions. The resolutions include:
このシナリオでは、オファーはOpus、G.722、G.711、およびDTMFオーディオコーデック、およびVP8、VP9、H.264（CBP / CHP、モード0/1）、H.264-SVC（SCBP / SCHP）をサポートしています。）ビデオ用H.265（MP / M10P）。8ウェイビデオ呼び出し（ミキサーへ）がサポートされています（1つのビデオストリームを送信する（最大解像度で1つのSendRecvと小さな解像度で6回のレミューションで6回のリコースト）、すべて同じポートにバンドルされています。3つの解像度。解像度は次のとおりです。
* 1 receive stream of 720p resolution is offered for the active speaker.
* 1アクティブスピーカーのために720pの解像度の受信ストリームが提供されます。
* 2 receive streams of 360p resolution are offered for the prior 2 active speakers.
* 2 360pの解像度の受信ストリームが、前の2つのアクティブスピーカーに対して提供されます。
* 4 receive streams of 180p resolution are offered for others in the call.
* 4通話内の他の人には、180pの解像度の受信ストリームが提供されます。
NOTE: The SDP given below skips a few lines to keep the example short and focused, as indicated by either the "..." or the comments inserted.
注：以下のSDPは、「...」またはコメントのどちらかで示すように、例を短くして焦点を合わせるために数回のラインをスキップします。
The offer for this scenario is shown below.
このシナリオのオファーを以下に示します。
... m=audio 10000 RTP/SAVPF 96 9 8 0 123 a=rtpmap:96 OPUS/48000 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:123 telephone-event/8000 a=mid:a1 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtpmap:98 VP8/90000 a=fmtp:98 max-fs=3600; max-fr=30 a=rtpmap:99 VP9/90000 a=fmtp:99 max-fs=3600; max-fr=30 a=rtpmap:100 H264/90000 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 a=rtpmap:101 H264/90000 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 a=rtpmap:102 H264/90000 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 a=rtpmap:103 H264/90000 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 a=rtpmap:104 H264-SVC/90000 a=fmtp:104 profile-level-id=530c1f a=rtpmap:105 H264-SVC/90000 a=fmtp:105 profile-level-id=560c1f a=rtpmap:106 H265/90000 a=fmtp:106 profile-id=1; level-id=93 a=rtpmap:107 H265/90000 a=fmtp:107 profile-id=2; level-id=93 a=sendrecv a=mid:v1 (max resolution) a=rid:1 send max-width=1280;max-height=720;max-fps=30 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... a=recvonly a=mid:v2 (medium resolution) a=rid:3 recv max-width=640;max-height=360;max-fps=15 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... a=recvonly a=mid:v3 (medium resolution) a=rid:3 recv max-width=640;max-height=360;max-fps=15 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... a=recvonly a=mid:v4 (small resolution) a=rid:4 recv max-width=320;max-height=180;max-fps=15 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... ...
... M = AUDIO 10000 RTP / SAVPF 96 9 8 0 123 A = RTPMAP：96 OPU / 48000 A = RTPMAP：9 G722 / 8000 A = RTPMAP：8 PCMA / 8000 A = RTPMAP：0 PCMU / 8000 A = RTPMAP ：123電話イベント/ 8000 A = MID：A1 ... M =ビデオ1000 RTP / SAVPF 98 99 100 101 102 103 104 105 106 107 A = EXTMAP 1 URN：IETF：PARAMS：RTP-HDREXT：SDES：RTP- STREAM-ID A = RTPMAP：98 VP8 / 90000 A = FMTP：98 MAX-FS = 3600; MAX-FR = 30 A = RTPマップ：99 VP9 / 90000 A = FMTP：99 MAX-FS = 3600; MAX-FR = 30 A = RTPMAP：100 H264 / 90000 A = FMTP：100プロファイルレベルID = 42401F; Packetization-Mode = 0 A = RTPMAP：101 h264 / 90000 A = FMTP：101 profile-level-id = 42401F; Packetization-Mode = 1 A = RTPMAP：102 h264 / 90000 A = FMTP：102プロファイルレベル-ID = 640C1F; Packetization-Mode = 0 A = RTPMAP：103 h264 / 90000 A = FMTP：103プロファイルレベルID = 640C1F; Packetization-Mode = 1 A = RTPMAP：104 H264-SVC / 90000 A = FMTP：104 PROFILE-LEVEL-ID = 530C1F A = RTPMAP：105 H264-SVC / 90000 A = FMTP：105プロファイルレベルID = 560C1F = rtpmap：106 H265 / 90000 A = FMTP：106 profile-id = 1; LEVEL-ID = 93 A = RTPMAP：107 H265 / 90000 A = FMTP：107 profile-id = 2; LEVEL-ID = 93 A = SENDRECV A = MID：V1（最大解像度）A = RID：1 MAX-WIDTH = 1280を送信します。最大値= 720; MAX-FPS = 30 A = RID：2 RECV MAX-WIDTH = 1280; Max-Height = 720; MAX-FPS = 30 ... M = Video 1000 RTP / SAVPF 98 99 100 101 102 103 104 105 106 107 A = EXTMAP 1 URN：IETF：PARAMS：RTP-HDREXT：SDES：RTP -stream-id ...上記のように同じRTPMAP / FMTP ... A = Revonly A = Mid：V2（中間解像度）A = RID：3 RECV MAX-WIDTH = 640; MAX-HEIGHT = 360; MAX-FPS = 15 ... M =ビデオ10000 RTP / SAVPF 98 99 100 101 102 103 104 105 106 107 = extmap 1 URN：IETF：paramsは：RTP-hdrext：SDES：RTPストリーム-ID ...同じrtpmap /のfmtpとして上記... A = Revonly A = Mid：V3（中間分解能）A = RID：3 RECV MAX-WIDTH = 640; MAX-HEIGHT = 360; MAX-FPS = 15 ... M =ビデオ10000 RTP / SAVPF 98 99 100 101 102 103 104 105 106 107 A = extmap 1つのURN：IETF：paramsは：RTP-hdrext：SDES：... A = recvonlyでA =中間上記のように、RTPストリームid ...同じrtpmap /のfmtp：V4 （小解像度）A = RID：4 recv max-width = 320; max-height = 180; max-fps = 15 ... M =ビデオ10000 RTP / SAVPF 98 99 100 1010 103 104 105 106 107 A = extmap 1 URN：IETF：Params：RTP-HDR ext：sdes：rtp-stream-id ...上記のように同じRTPMAP / FMTP ... ...同じRID：4上記のように：V5、V6、V7（小解像度）...
Adding scalable layers to a session within a multiparty conference gives a selective forwarding unit (SFU) further flexibility to selectively forward packets from a source that best match the bandwidth and capabilities of diverse receivers. Scalable encodings have dependencies between layers, unlike independent simulcast streams. RIDs can be used to express these dependencies using the "depend" restriction. In the example below, the highest resolution is offered to be sent as 2 scalable temporal layers (using Multiple RTP Streams on a Single Media Transport (MRST)). See [RFC8853] for additional detail about simulcast usage.
マルチパーティ会議内のセッションにスケーラブルなレイヤを追加すると、選択的転送ユニット（SFU）が、多様な受信機の帯域幅と機能に最も適したパケットを選択的に転送するためのさらに柔軟性を与えます。スケーラブルエンコーディングは、独立したSimulcastストリームとは異なり、レイヤー間の依存関係を持ちます。RIDは、「依存的な」制限を使用してこれらの依存関係を表現するために使用することができます。以下の例では、最高の解像度は2つのスケーラブルな時間層として送信されるように提供されます（単一のメディアトランスポート（MRST）の複数のRTPストリームを使用して）。Simulcastの使用方法について詳しくは、[RFC8853]を参照してください。
Offer: ... m=audio ...same as previous example ... ... m=video ...same as previous example ... ...same rtpmap/fmtp as previous example ... a=sendrecv a=mid:v1 (max resolution) a=rid:0 send max-width=1280;max-height=720;max-fps=15 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 a=rid:5 send max-width=640;max-height=360;max-fps=15 a=rid:6 send max-width=320;max-height=180;max-fps=15 a=simulcast: send rid=0;1;5;6 recv rid=2 ... ...same m=video sections as previous example for mid:v2-v7... ...
オファー：... m =オーディオ...前の例と同じ... ... m =ビデオ...前の例として同じです......前の例として同じRTPMAP / FMTP ... a = sendrecva = mid：v1（最大解像度）A = RID：0 max-width = 1280を送信します。最大値= 720; max-fps = 15 a = RID：1 max-width = 1280; max-width = 720;max-fps = 30; rec = 0 = RID：2 RECV MAX-width = 1280; max-height = 720; max-fps = 30 A = RID：5 max-width = 640; max-height = 360;MAX-FPS = 15 A = RID：6 max-width = 320; max-height = 180; max-fps = 15 a = Simulcast：send red = 0; 5; 6 recv red = 2 ...。..Same M = MID：V2-V7の前の例としてのビデオセクション... ...
This specification updates [RFC4855] to give additional guidance on choice of Format Parameter (fmtp) names and their relation to RID restrictions.
この仕様は[RFC4855]を更新して、フォーマットパラメータ（FMTP）の名前（FMTP）名とRID制限との関係に関する追加のガイダンスを与えます。
This document defines "rid" as an SDP media-level attribute. This attribute has been registered by IANA under "Session Description Protocol (SDP) Parameters" under "att-field (media level only)".
このドキュメントはSDPメディアレベルの属性として「RID」を定義します。この属性は、「セッション記述プロトコル（SDP）パラメータ」の下にあるIANAによって登録されています。「ATT-FIELD（メディアレベルのみ）」。
The "rid" attribute is used to identify the properties of an RTP stream within an RTP session. Its format is defined in Section 10.
"RID"属性は、RTPセッション内のRTPストリームのプロパティを識別するために使用されます。そのフォーマットはセクション10で定義されています。
The formal registration information for this attribute follows.
この属性の正式な登録情報は次のとおりです。
Contact name, email address, and telephone number IETF MMUSIC Working Group mmusic@ietf.org +1 510 492 4080
連絡先名、電子メールアドレス、電話番号IETF MMUSICワーキンググループMMUSIC@IETF.ORG 1 510 492 4080
Attribute name (as it will appear in SDP) rid
属性名（SDPに表示されるため）RID
Long-form attribute name in English Restriction Identifier
英語制限識別子の長階属性名
Type of attribute (session level, media level, or both) Media Level
属性の種類（セッションレベル、メディアレベル、またはその両方）メディアレベル
Whether the attribute value is subject to the charset attribute The attribute is not dependent on charset.
属性値がcharset属性に従うかどうかは、属性は文字セットに依存しません。
A one-paragraph explanation of the purpose of the attribute The "rid" SDP attribute is used to unambiguously identify the RTP streams within an RTP session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular payload types.
属性の目的の1段落の説明「RID」SDP属性は、RTPセッション内のRTPストリームを明確に識別し、定期的に提供されているものを超えてCodec-Agnosticの方法でストリームのペイロードフォーマットパラメータを制限するために使用されます。ペイロードタイプ
A specification of appropriate attribute values for this attribute Valid values are defined by the ABNF in RFC 8851
この属性有効値の適切な属性値の指定は、RFC 8851のABNFによって定義されます。
Multiplexing (Mux) Category SPECIAL
多重化（MUX）カテゴリスペシャル
This specification creates a new IANA registry named "RID Attribute Parameters" within the SDP parameters registry. The "a=rid" restrictions MUST be registered with IANA and documented under the same rules as for SDP session-level and media-level attributes as specified in [RFC4566].
この仕様は、SDPパラメータレジストリ内に「RID属性パラメータ」という名前の新しいIANAレジストリを作成します。"A = RID"の制限はIANAに登録され、[RFC4566]で指定されているSDPセッションレベルとメディアレベルの属性と同じ規則に記載されていなければなりません。
Parameters for "a=rid" lines that modify the nature of encoded media MUST be of the form that the result of applying the modification to the stream results in a stream that still complies with the other parameters that affect the media. In other words, restrictions always have to restrict the definition to be a subset of what is otherwise allowable, and never expand it.
エンコードされたメディアの性質を変更する "A = RID"行のパラメータは、ストリームに変更を適用した結果が、メディアに影響を与える他のパラメータにまだ準拠しているストリームになるという形式でなければなりません。言い換えれば、制限は、定義を他の方法で許容されるサブセットであることを常に制限しなければならず、それを延長する必要はありません。
New restriction registrations are accepted according to the "Specification Required" policy of [RFC8126]. The registration MUST contain the RID parameter name and a reference to the corresponding specification. The specification itself must contain the following information (not all of which appears in the registry):
[RFC8126]の「仕様必要な」ポリシーに従って、新しい制限登録が受け付けられます。登録には、RIDパラメータ名と対応する仕様への参照が含まれている必要があります。仕様自体には次の情報が含まれている必要があります（すべてのものがレジストリに表示されない）。
* restriction name (as it will appear in SDP)
* 制限名（SDPに表示されるため）
* an explanation of the purpose of the restriction
* 制限の目的の説明
* a specification of appropriate attribute values for this restriction
* この制限に対する適切な属性値の指定
* an ABNF definition of the restriction
* 制限のABNF定義
The initial set of "a=rid" restriction names, with definitions in Section 5 of this document, is given below:
この文書のセクション5の定義を持つ「A = RID」制限名の初期セットを以下に示します。
+====================+===========+
| RID Parameter Name | Reference |
+====================+===========+
| pt | RFC 8851 |
+--------------------+-----------+
| max-width | RFC 8851 |
+--------------------+-----------+
| max-height | RFC 8851 |
+--------------------+-----------+
| max-fps | RFC 8851 |
+--------------------+-----------+
| max-fs | RFC 8851 |
+--------------------+-----------+
| max-br | RFC 8851 |
+--------------------+-----------+
| max-pps | RFC 8851 |
+--------------------+-----------+
| max-bpp | RFC 8851 |
+--------------------+-----------+
| depend | RFC 8851 |
+--------------------+-----------+
Table 1: "a=rid" restriction names
表1：「A = RID」制限名
It is conceivable that a future document will want to define RID-level restrictions that contain string values. These extensions need to take care to conform to the ABNF defined for rid-param-other. In particular, this means that such extensions will need to define escaping mechanisms if they want to allow semicolons, unprintable characters, or byte values greater than 127 in the string.
将来の文書が文字列値を含むRIDレベルの制限を定義したいと考えられます。これらの拡張機能は、RID-PARAM-OTHER用に定義されているABNFに準拠するように注意する必要があります。特に、このような拡張機能は、ストリング内のセミコロン、印刷不能文字、またはバイト値を許可する場合、エスケープメカニズムを定義する必要があることを意味します。
As with most SDP parameters, a failure to provide integrity protection over the "a=rid" attributes gives attackers a way to modify the session in potentially unwanted ways. This could result in an implementation sending greater amounts of data than a recipient wishes to receive. In general, however, since the "a=rid" attribute can only restrict a stream to be a subset of what is otherwise allowable, modification of the value cannot result in a stream that is of higher bandwidth than would be sent to an implementation that does not support this mechanism.
ほとんどのSDPパラメータと同様に、「A = RID」属性を介して整合性保護を提供できなかった場合、攻撃者は潜在的に不要な方法でセッションを変更する方法を提供します。これにより、受信者が受信者が受信したいよりも多くのデータを送信する実装が生じる可能性があります。しかしながら、一般に、「a = rid」属性は、そうでなければ許容されるもののサブセットになるためにストリームを制限することができるので、その値の修正は、実装に送信されるよりも高い帯域幅のストリームをもたらさない。このメカニズムをサポートしていません。
The actual identifiers used for RIDs are expected to be opaque. As such, they are not expected to contain information that would be sensitive, were it observed by third parties.
RIDSに使用される実際の識別子は不透明であると予想されます。そのように、彼らは敏感であるであろう情報を含むと予想されない、それは第三者によって観察されました。
[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>。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <https://www.rfc-editor.org/info/rfc4855>.
[RFC4855] Casner、S.、RTPペイロードフォーマットの「メディアタイプ登録」、RFC 4855、DOI 10.17487 / RFC4855、2007年2月、<https：//www.rfc-editor.org/info/rfc4855>。
[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>。
[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>。
[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>。
[H264] International Telecommunication Union, "Advanced video coding for generic audiovisual services", ITU-T Recommendation H.264, June 2019, <https://www.itu.int/rec/T-REC-H.264>.
[H264]国際電気通信連合、「一般的な視聴覚サービスの高度なビデオコーディング」、2019年6月、<https：//www.itu.int/rec/t-rec-h.264>。
[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>。
[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>。
[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>。
[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>。
[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>。
[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>。
[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>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, <https://www.rfc-editor.org/info/rfc8285>.
[RFC8285]歌手、D.、Desineni、H.、およびR.偶数、「RTPヘッダー拡張のための一般的なメカニズム」、RFC 8285、DOI 10.17487 / RFC8285、2017年10月、<https：//www.rfc-editor.org/info/rfc8285>。
[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>。
[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>。
[RFC8853] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Simulcast in Session Description Protocol (SDP) and RTP Sessions", RFC 8853, DOI 10.17487/RFC8853, January 2021, <https://www.rfc-editor.org/info/rfc8853>.
[RFC8853] Burman、B.、Westerlund、M.、Nandakumar、S.、およびM.Zanaty、「セッション記述プロトコル（SDP）およびRTPセッションにおけるSimulcastの使用」、RFC 8853、DOI 10.17487 / RFC8853、2021年1月、<https://www.rfc-editor.org/info/rfc8853>。
Acknowledgements
謝辞
Many thanks to Cullen Jennings, Magnus Westerlund, and Paul Kyzivat for reviewing. Thanks to Colin Perkins for input on future payload type handling.
レビューのためのカレンジェニングニング、マグナスウエスタルンド、ポールキズのおかげでおかげでねて。将来のペイロードタイプの取り扱いに入力するためのColin Perkinsのおかげで。
Contributors
貢献者
The following individuals have contributed significant text to this document.
次の個人はこの文書に重要なテキストを寄付しました。
Peter Thatcher Google
Peter Thatcher Google
Email: pthatcher@google.com
Mo Zanaty Cisco Systems
Mo Zanaty Cisco Systems
Email: mzanaty@cisco.com
Suhas Nandakumar Cisco Systems
Suhas Nandakumar Cisco Systems
Email: snandaku@cisco.com
Bo Burman Ericsson
Bo Burman Ericsson.
Email: bo.burman@ericsson.com
Byron Campen Mozilla
バイロンカンペンモジラ
Email: bcampen@mozilla.com
Author's Address
著者の住所
Adam Roach (editor) Mozilla
Adam Roach（編集）Mozilla.
Email: adam@nostrum.com