[要約] RFC 5104は、RTPオーディオビジュアルプロファイルで使用されるコーデック制御メッセージに関する仕様です。このRFCの目的は、AVPFフィードバックメカニズムを使用して、リアルタイム通信セッションの品質を向上させることです。
Network Working Group S. Wenger
Request for Comments: 5104 U. Chandra
Category: Standards Track Nokia
M. Westerlund
B. Burman
Ericsson
February 2008
Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
RTPオーディオビジュアルプロファイルのフィードバック（AVPF）のコーデック制御メッセージ
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.
このドキュメントは、フィードバック（AVPF）を使用して、オーディオビジュアルプロファイルで定義されているメッセージに対するいくつかの拡張機能を指定します。これらは、主に集中マルチポイント関数が使用されている会話型マルチメディアシナリオで役立ちます。ただし、一部は小規模なマルチキャスト環境やポイントツーポイントコールで使用可能です。
The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off.
説明されている拡張機能は、ITU-T RECに関連するメッセージです。H.271ビデオバックチャネル、完全なリクエスト、一時的な最大メディアストリームビットレート、および時間空間トレードオフ。
Table of Contents
目次
1. Introduction ....................................................4
2. Definitions .....................................................5
2.1. Glossary ...................................................5
2.2. Terminology ................................................5
2.3. Topologies .................................................8
3. Motivation ......................................................8
3.1. Use Cases ..................................................9
3.2. Using the Media Path ......................................11
3.3. Using AVPF ................................................11
3.3.1. Reliability ........................................12
3.4. Multicast .................................................12
3.5. Feedback Messages .........................................12
3.5.1. Full Intra Request Command .........................12
3.5.1.1. Reliability ...............................13
3.5.2. Temporal-Spatial Trade-off Request and
Notification .......................................14
3.5.2.1. Point-to-Point ............................15
3.5.2.2. Point-to-Multipoint Using
Multicast or Translators ..................15
3.5.2.3. Point-to-Multipoint Using RTP Mixer .......15
3.5.2.4. Reliability ...............................16
3.5.3. H.271 Video Back Channel Message ...................16
3.5.3.1. Reliability ...............................19
3.5.4. Temporary Maximum Media Stream Bit Rate
Request and Notification ...........................19
3.5.4.1. Behavior for Media Receivers Using TMMBR ..21
3.5.4.2. Algorithm for Establishing Current
Limitations ...............................23
3.5.4.3. Use of TMMBR in a Mixer-Based
Multipoint Operation ......................29
3.5.4.4. Use of TMMBR in Point-to-Multipoint Using
Multicast or Translators ..................30
3.5.4.5. Use of TMMBR in Point-to-Point Operation ..31
3.5.4.6. Reliability ...............................31
4. RTCP Receiver Report Extensions ................................32
4.1. Design Principles of the Extension Mechanism ..............32
4.2. Transport Layer Feedback Messages .........................33
4.2.1. Temporary Maximum Media Stream Bit Rate
Request (TMMBR) ....................................34
4.2.1.1. Message Format ............................34
4.2.1.2. Semantics .................................35
4.2.1.3. Timing Rules ..............................39
4.2.1.4. Handling in Translators and Mixers ........39
4.2.2. Temporary Maximum Media Stream Bit Rate
Notification (TMMBN) ...............................39
4.2.2.1. Message Format ............................39
4.2.2.2. Semantics .................................40
4.2.2.3. Timing Rules ..............................41
4.2.2.4. Handling by Translators and Mixers ........41
4.3. Payload-Specific Feedback Messages ........................41
4.3.1. Full Intra Request (FIR) ...........................42
4.3.1.1. Message Format ............................42
4.3.1.2. Semantics .................................43
4.3.1.3. Timing Rules ..............................44
4.3.1.4. Handling of FIR Message in Mixers and
Translators ...............................44
4.3.1.5. Remarks ...................................44
4.3.2. Temporal-Spatial Trade-off Request (TSTR) ..........45
4.3.2.1. Message Format ............................46
4.3.2.2. Semantics .................................46
4.3.2.3. Timing Rules ..............................47
4.3.2.4. Handling of Message in Mixers and
Translators ...............................47
4.3.2.5. Remarks ...................................47
4.3.3. Temporal-Spatial Trade-off Notification (TSTN) .....48
4.3.3.1. Message Format ............................48
4.3.3.2. Semantics .................................49
4.3.3.3. Timing Rules ..............................49
4.3.3.4. Handling of TSTN in Mixers and
Translators ...............................49
4.3.3.5. Remarks ...................................49
4.3.4. H.271 Video Back Channel Message (VBCM) ............50
4.3.4.1. Message Format ............................50
4.3.4.2. Semantics .................................51
4.3.4.3. Timing Rules ..............................52
4.3.4.4. Handling of Message in Mixers or
Translators ...............................52
4.3.4.5. Remarks ...................................52
5. Congestion Control .............................................52
6. Security Considerations ........................................53
7. SDP Definitions ................................................54
7.1. Extension of the rtcp-fb Attribute ........................54
7.2. Offer-Answer ..............................................55
7.3. Examples ..................................................56
8. IANA Considerations ............................................58
9. Contributors ...................................................60
10. Acknowledgements ..............................................60
11. References ....................................................60
11.1. Normative References .....................................60
11.2. Informative References ...................................61
When the Audio-Visual Profile with Feedback (AVPF) [RFC4585] was developed, the main emphasis lay in the efficient support of point-to-point and small multipoint scenarios without centralized multipoint control. However, in practice, many small multipoint conferences operate utilizing devices known as Multipoint Control Units (MCUs). Long-standing experience of the conversational video conferencing industry suggests that there is a need for a few additional feedback messages, to support centralized multipoint conferencing efficiently. Some of the messages have applications beyond centralized multipoint, and this is indicated in the description of the message. This is especially true for the message intended to carry ITU-T Rec. H.271 [H.271] bit strings for Video Back Channel messages.
フィードバック（AVPF）[RFC4585]を備えたオーディオビジュアルプロファイルが開発されたとき、主な重点は、集中マルチポイント制御なしでポイントツーポイントおよび小さなマルチポイントシナリオの効率的なサポートにありました。ただし、実際には、多くの小規模なマルチポイント会議は、マルチポイントコントロールユニット（MCU）として知られるデバイスを利用して運営されています。会話型ビデオ会議業界の長年の経験は、集中型マルチポイント会議を効率的にサポートするために、いくつかの追加のフィードバックメッセージが必要であることを示唆しています。一部のメッセージには、集中マルチポイントを超えたアプリケーションがあり、これはメッセージの説明に示されています。これは、ITU-T RECを運ぶことを目的としたメッセージに特に当てはまります。H.271 [H.271]ビデオバックチャネルメッセージのビット文字列。
In Real-time Transport Protocol (RTP) [RFC3550] terminology, MCUs comprise mixers and translators. Most MCUs also include signaling support. During the development of this memo, it was noticed that there is considerable confusion in the community related to the use of terms such as mixer, translator, and MCU. In response to these concerns, a number of topologies have been identified that are of practical relevance to the industry, but are not documented in sufficient detail in [RFC3550]. These topologies are documented in [RFC5117], and understanding this memo requires previous or parallel study of [RFC5117].
リアルタイムトランスポートプロトコル（RTP）[RFC3550]用語では、MCUSはミキサーと翻訳者で構成されています。ほとんどのMCUには、シグナリングサポートも含まれています。このメモの開発中に、ミキサー、翻訳者、MCUなどの用語の使用に関連するコミュニティにかなりの混乱があることがわかりました。これらの懸念に応えて、業界に実際的に関連する多くのトポロジが特定されていますが、[RFC3550]で十分に詳細に文書化されていません。これらのトポロジーは[RFC5117]に文書化されており、このメモを理解するには、[RFC5117]の以前または並行した研究が必要です。
Some of the messages defined here are forward only, in that they do not require an explicit notification to the message emitter that they have been received and/or indicating the message receiver's actions. Other messages require a response, leading to a two-way communication model that one could view as useful for control purposes. However, it is not the intention of this memo to open up RTP Control Protocol (RTCP) to a generalized control protocol. All mentioned messages have relatively strict real-time constraints, in the sense that their value diminishes with increased delay. This makes the use of more traditional control protocol means, such as Session Initiation Protocol (SIP) [RFC3261], undesirable when used for the same purpose. That is why this solution is recommended instead of "XML Schema for Media Control" [XML-MC], which uses SIP Info to transfer XML messages with similar semantics to what are defined in this memo. Furthermore, all messages are of a very simple format that can be easily processed by an RTP/RTCP sender/receiver. Finally, and most importantly, all messages relate only to the RTP stream with which they are associated, and not to any other property of a communication system. In particular, none of them relate to the properties of the access links traversed by the session.
ここで定義されているメッセージのいくつかは、送信されたというメッセージエミッタへの明示的な通知を必要とせず、メッセージ受信者のアクションをメッセージを示すという点で、フォワードのみです。他のメッセージには応答が必要であり、双方向通信モデルにつながり、制御目的に役立つと見なすことができます。ただし、RTP制御プロトコル（RTCP）を一般化されたコントロールプロトコルに開くことは、このメモの意図ではありません。言及されたすべてのメッセージは、その価値が遅延を増やすと減少するという意味で、比較的厳格なリアルタイムの制約を持っています。これにより、セッション開始プロトコル（SIP）[RFC3261]などのより従来の制御プロトコル手段が使用され、同じ目的で使用される場合は望ましくありません。そのため、「メディア制御用のXMLスキーマ」[XML-MC]の代わりにこのソリューションが推奨されます。これは、SIP情報を使用して、このメモで定義されているものと同様のセマンティクスを持つXMLメッセージを転送します。さらに、すべてのメッセージは、RTP/RTCP送信者/レシーバーによって簡単に処理できる非常にシンプルな形式です。最後に、そして最も重要なことは、すべてのメッセージは、それらが関連付けられているRTPストリームのみに関連しており、通信システムの他のプロパティには関係していません。特に、セッションで通過したアクセスリンクのプロパティに関連するものはありません。
AIMD - Additive Increase Multiplicative Decrease AVPF - The extended RTP profile for RTCP-based feedback FCI - Feedback Control Information [RFC4585] FEC - Forward Error Correction FIR - Full Intra Request MCU - Multipoint Control Unit MPEG - Moving Picture Experts Group PLI - Picture Loss Indication PR - Packet rate QP - Quantizer Parameter RTT - Round trip time SSRC - Synchronization Source TMMBN - Temporary Maximum Media Stream Bit Rate Notification TMMBR - Temporary Maximum Media Stream Bit Rate Request TSTN - Temporal-Spatial Trade-off Notification TSTR - Temporal-Spatial Trade-off Request VBCM - Video Back Channel Message
AIMD-加法増加乗数削減AVPF- RTCPベースのフィードバックFCIの拡張RTPプロファイル - フィードバック制御情報[RFC4585] FEC-フォワードエラー補正FIR -FULL INTRAリクエストMCU-マルチポイントコントロールユニットMPEG -Moving Picture Experts Group PLI-画像損失表示PR-パケットレートQP-量子化器パラメーターRTT-ラウンドトリップタイムSSRC-同期ソースTMMBN-一時的な最大メディアストリームビットレート通知TMMBR-一時的な最大メディアストリームビットレートリクエストTSTN-時間空間トレードオフ通知TSTR-時間空間的トレードオフリクエストVBCM-ビデオバックチャネルメッセージ
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Message: An RTCP feedback message [RFC4585] defined by this specification, of one of the following types:
メッセージ：次のタイプの1つのこの仕様で定義されたRTCPフィードバックメッセージ[RFC4585]：
Request: Message that requires acknowledgement
リクエスト：承認が必要なメッセージ
Command: Message that forces the receiver to an action
コマンド：受信者にアクションを強制するメッセージ
Indication: Message that reports a situation
表示：状況を報告するメッセージ
Notification: Message that provides a notification that an event has occurred. Notifications are commonly generated in response to a Request.
通知：イベントが発生したという通知を提供するメッセージ。通知は、一般にリクエストに応じて生成されます。
Note that, with the exception of "Notification", this terminology is in alignment with ITU-T Rec. H.245 [H245].
「通知」を除いて、この用語はITU-T Recと一致していることに注意してください。H.245 [H245]。
Decoder Refresh Point: A bit string, packetized in one or more RTP packets, that completely resets the decoder to a known state.
デコーダーリフレッシュポイント：デコーダーを既知の状態に完全にリセットする1つまたは複数のRTPパケットでパケット化された少し文字列。
Examples for "hard" decoder refresh points are Intra pictures in H.261, H.263, MPEG-1, MPEG-2, and MPEG-4 part 2, and Instantaneous Decoder Refresh (IDR) pictures in H.264. "Gradual" decoder refresh points may also be used; see for example [AVC]. While both "hard" and "gradual" decoder refresh points are acceptable in the scope of this specification, in most cases the user experience will benefit from using a "hard" decoder refresh point.
「ハード」デコーダーリフレッシュポイントの例は、H.261、H.263、MPEG-1、MPEG-2、およびMPEG-4パート2の写真とH.264の瞬時デコーダーリフレッシュ（IDR）写真です。「段階的な」デコーダーリフレッシュポイントも使用できます。たとえば[AVC]を参照してください。この仕様の範囲では、「ハード」と「段階的な」デコーダーリフレッシュポイントの両方が許容されますが、ほとんどの場合、ユーザーエクスペリエンスは「ハード」デコーダーリフレッシュポイントを使用することで恩恵を受けます。
A decoder refresh point also contains all header information above the picture layer (or equivalent, depending on the video compression standard) that is conveyed in-band. In H.264, for example, a decoder refresh point contains parameter set Network Adaptation Layer (NAL) units that generate parameter sets necessary for the decoding of the following slice/data partition NAL units (and that are not conveyed out of band).
デコーダーリフレッシュポイントには、バンド内で伝えられる画像レイヤー（またはビデオ圧縮標準に応じて同等の）上のすべてのヘッダー情報も含まれています。たとえば、H.264では、デコーダーリフレッシュポイントには、次のスライス/データパーティションNALユニットのデコードに必要なパラメーターセットを生成するパラメーターセットネットワーク適応レイヤー（NAL）ユニットが含まれています（およびバンドから伝えられていません）。
Decoding: The operation of reconstructing the media stream.
デコード：メディアストリームの再構築の操作。
Rendering: The operation of presenting (parts of) the reconstructed media stream to the user.
レンダリング：再構築されたメディアストリームをユーザーに提示（その一部）の操作。
Stream thinning: The operation of removing some of the packets from a media stream. Stream thinning, preferably, is media-aware, implying that media packets are removed in the order of increasing relevance to the reproductive quality. However, even when employing media-aware stream thinning, most media streams quickly lose quality when subjected to increasing levels of thinning. Media-unaware stream thinning leads to even worse quality degradation. In contrast to transcoding, stream thinning is typically seen as a computationally lightweight operation.
ストリーム薄化：メディアストリームからパケットの一部を削除する動作。できれば、ストリームの薄化はメディアを意識していることであり、メディアパケットが生殖品質との関連性を高める順に削除されることを意味します。ただし、メディア認識のストリームの薄化を使用しても、ほとんどのメディアストリームは、薄くなるレベルの増加にさらされるとすぐに品質を失います。メディアに不名誉なストリームが薄くなると、品質の劣化がさらに悪化します。トランスコーディングとは対照的に、ストリームの薄化は通常、計算的に軽量操作と見なされます。
Media: Often used (sometimes in conjunction with terms like bit rate, stream, sender, etc.) to identify the content of the forward RTP packet stream (carrying the codec data), to which the codec control message applies.
メディア：頻繁に使用される（ビットレート、ストリーム、送信者などなどの用語と組み合わせて）、フォワードRTPパケットストリームのコンテンツ（コーデックデータを運ぶ）を識別し、コーデックコントロールメッセージが適用されます。
Media Stream: The stream of RTP packets labeled with a single Synchronization Source (SSRC) carrying the media (and also in some cases repair information such as retransmission or Forward Error Correction (FEC) information).
メディアストリーム：メディアを運ぶ単一の同期ソース（SSRC）でラベル付けされたRTPパケットのストリーム（また、場合によっては再送信またはフォワードエラー補正（FEC）情報などの修復情報）。
Total media bit rate: The total bits per second transferred in a media stream, measured at an observer-selected protocol layer and averaged over a reasonable timescale, the length of which depends on the application. In general, a media sender and a media receiver will observe different total media bit rates for the same stream, first because they may have selected different reference protocol layers, and second, because of changes in per-packet overhead along the transmission path. The goal with bit rate averaging is to be able to ignore any burstiness on very short timescales (e.g., below 100 ms) introduced by scheduling or link layer packetization effects.
合計メディアビットレート：オブザーバーが選択したプロトコル層で測定され、合理的なタイムスケールで平均化されたメディアストリームで1秒あたりの合計ビットが転送され、その長さはアプリケーションに依存します。一般に、メディア送信者とメディアレシーバーは、同じストリームの異なる合計メディアビットレートを観察します。最初に、異なる参照プロトコルレイヤーを選択した可能性があるため、2つ目は、送信パスに沿ったパケットごとのオーバーヘッドの変更のためです。ビットレート平均の目標は、スケジューリングまたはリンクレイヤーのパケット化効果によって導入された非常に短いタイムスケール（例：100ミリ秒未満）での破裂を無視できるようにすることです。
Maximum total media bit rate: The upper limit on total media bit rate for a given media stream at a particular receiver and for its selected protocol layer. Note that this value cannot be measured on the received media stream. Instead, it needs to be calculated or determined through other means, such as quality of service (QoS) negotiations or local resource limitations. Also note that this value is an average (on a timescale that is reasonable for the application) and that it may be different from the instantaneous bit rate seen by packets in the media stream.
最大総メディアビットレート：特定の受信機および選択したプロトコル層の特定のメディアストリームの合計メディアビットレートの上限。この値は、受信したメディアストリームで測定できないことに注意してください。代わりに、サービス品質（QO）交渉やローカルリソースの制限など、他の手段を通じて計算または決定する必要があります。また、この値は平均（アプリケーションにとって合理的なタイムスケール）であり、メディアストリームのパケットで見られる瞬間的なビットレートとは異なる場合があることに注意してください。
Overhead: All protocol header information required to convey a packet with media data from sender to receiver, from the application layer down to a pre-defined protocol level (for example, down to, and including, the IP header). Overhead may include, for example, IP, UDP, and RTP headers, any layer 2 headers, any Contributing Sources (CSRCs), RTP padding, and RTP header extensions. Overhead excludes any RTP payload headers and the payload itself.
オーバーヘッド：送信者から受信機へ、アプリケーションレイヤーから事前定義されたプロトコルレベルまで（たとえば、IPヘッダーを含む）までのメディアデータを含むパケットを伝達するために必要なすべてのプロトコルヘッダー情報。オーバーヘッドには、たとえば、IP、UDP、およびRTPヘッダー、任意のレイヤー2ヘッダー、寄与源（CSRC）、RTPパディング、RTPヘッダー拡張が含まれます。オーバーヘッドは、RTPペイロードヘッダーとペイロード自体を除外します。
Net media bit rate: The bit rate carried by a media stream, net of overhead. That is, the bits per second accounted for by encoded media, any applicable payload headers, and any directly associated meta payload information placed in the RTP packet. A typical example of the latter is redundancy data provided by the use of RFC 2198 [RFC2198]. Note that, unlike the total media bit rate, the net media bit rate will have the same value at the media sender and at the media receiver unless any mixing or translating of the media has occurred.
ネットメディアビットレート：オーバーヘッドのネットであるメディアストリームによって運ばれるビットレート。つまり、1秒あたりのビットは、エンコードされたメディア、該当するペイロードヘッダー、およびRTPパケットに配置された直接関連のメタペイロード情報によって説明されます。後者の典型的な例は、RFC 2198 [RFC2198]の使用によって提供される冗長データです。メディアビットレートの合計とは異なり、ネットメディアビットレートは、メディアのミキシングまたは翻訳が発生しない限り、メディア送信者とメディアレシーバーで同じ値を持つことに注意してください。
For a given observer, the total media bit rate for a media stream is equal to the sum of the net media bit rate and the per-packet overhead as defined above multiplied by the packet rate.
特定のオブザーバーの場合、メディアストリームの合計メディアビットレートは、上記のパケットレートを掛けたように、ネットメディアビットレートとパケットごとのオーバーヘッドの合計に等しくなります。
Feasible region: The set of all combinations of packet rate and net media bit rate that do not exceed the restrictions in maximum media bit rate placed on a given media sender by the Temporary Maximum Media Stream Bit Rate Request (TMMBR) messages it has received. The feasible region will change as new TMMBR messages are received.
実行可能な領域：パケットレートとネットメディアビットレートのすべての組み合わせのセットは、一時的な最大メディアストリームビットレートリクエスト（TMMBR）メッセージによって、特定のメディア送信者に配置された最大メディアビットレートの制限を超えません。新しいTMMBRメッセージが受信されると、実行可能な領域が変更されます。
Bounding set: The set of TMMBR tuples, selected from all those received at a given media sender, that define the feasible region for that media sender. The media sender uses an algorithm such as that in section 3.5.4.2 to determine or iteratively approximate the current bounding set, and reports that set back to the media receivers in a Temporary Maximum Media Stream Bit Rate Notification (TMMBN) message.
境界セット：そのメディア送信者の実行可能な領域を定義する特定のメディア送信者で受け取ったすべての人から選択されたTMMBRタプルのセット。メディア送信者は、セクション3.5.4.2のようなアルゴリズムを使用して、現在の境界セットを決定または繰り返し近似し、一時的な最大メディアストリームビットレート通知（TMMBN）メッセージでメディアレシーバーに後退するレポートをレポートします。
Please refer to [RFC5117] for an in-depth discussion. The topologies referred to throughout this memo are labeled (consistently with [RFC5117]) as follows:
詳細な議論については、[RFC5117]を参照してください。このメモ全体で言及されているトポロジは、次のように（[RFC5117]と一貫して）ラベル付けされています。
Topo-Point-to-Point . . . . . Point-to-point communication
Topo-Multicast . . . . . . . Multicast communication
Topo-Translator . . . . . . . Translator based
Topo-Mixer . . . . . . . . . Mixer based
Topo-RTP-switch-MCU . . . . . RTP stream switching MCU
Topo-RTCP-terminating-MCU . . Mixer but terminating RTCP
This section discusses the motivation and usage of the different video and media control messages. The video control messages have been under discussion for a long time, and a requirement document was drawn up [Basso]. That document has expired; however, we quote relevant sections of it to provide motivation and requirements.
このセクションでは、さまざまなビデオおよびメディア制御メッセージの動機と使用について説明します。ビデオ制御メッセージは長い間議論されており、要件文書が作成されました[Basso]。そのドキュメントは期限切れになりました。ただし、動機付けと要件を提供するために、関連するセクションを引用します。
There are a number of possible usages for the proposed feedback messages. Let us begin by looking through the use cases Basso et al. [Basso] proposed. Some of the use cases have been reformulated and comments have been added.
提案されたフィードバックメッセージには、多くの使用可能な使用があります。Basso et al。[Basso]提案。一部のユースケースは再定式化されており、コメントが追加されています。
1. An RTP video mixer composes multiple encoded video sources into a single encoded video stream. Each time a video source is added, the RTP mixer needs to request a decoder refresh point from the video source, so as to start an uncorrupted prediction chain on the spatial area of the mixed picture occupied by the data from the new video source.
1. RTPビデオミキサーは、複数のエンコードされたビデオソースを単一のエンコードビデオストリームに構成します。ビデオソースが追加されるたびに、RTPミキサーはビデオソースからデコーダーリフレッシュポイントをリクエストする必要があります。これにより、新しいビデオソースからのデータが占める混合画像の空間領域で腐敗していない予測チェーンを開始する必要があります。
2. An RTP video mixer receives multiple encoded RTP video streams from conference participants, and dynamically selects one of the streams to be included in its output RTP stream. At the time of a bit stream change (determined through means such as voice activation or the user interface), the mixer requests a decoder refresh point from the remote source, in order to avoid using unrelated content as reference data for inter picture prediction. After requesting the decoder refresh point, the video mixer stops the delivery of the current RTP stream and monitors the RTP stream from the new source until it detects data belonging to the decoder refresh point. At that time, the RTP mixer starts forwarding the newly selected stream to the receiver(s).
2. RTPビデオミキサーは、会議参加者から複数のエンコードされたRTPビデオストリームを受信し、出力RTPストリームに含まれるストリームの1つを動的に選択します。少しストリームの変更（音声アクティベーションやユーザーインターフェイスなどの手段で決定）の時点で、ミキサーは、無関係なコンテンツをインターピクチャー予測の参照データとして使用しないように、リモートソースからデコーダーリフレッシュポイントを要求します。デコーダーリフレッシュポイントを要求した後、ビデオミキサーは現在のRTPストリームの配信を停止し、デコーダーリフレッシュポイントに属するデータを検出するまで、新しいソースからRTPストリームを監視します。その時点で、RTPミキサーは、新しく選択されたストリームをレシーバーに転送し始めます。
3. An application needs to signal to the remote encoder that the desired trade-off between temporal and spatial resolution has changed. For example, one user may prefer a higher frame rate and a lower spatial quality, and another user may prefer the opposite. This choice is also highly content dependent. Many current video conferencing systems offer in the user interface a mechanism to make this selection, usually in the form of a slider. The mechanism is helpful in point-to-point, centralized multipoint and non-centralized multipoint uses.
3.
4. Use case 4 of the Basso document applies only to Picture Loss Indication (PLI) as defined in AVPF [RFC4585] and is not reproduced here.
4.
5. Use case 5 of the Basso document relates to a mechanism known as "freeze picture request". Sending freeze picture requests over a non-reliable forward RTCP channel has been identified as problematic. Therefore, no freeze picture request has been included in this memo, and the use case discussion is not reproduced here.
5. Bassoドキュメントのユースケース5は、「フリーズ画像リクエスト」と呼ばれるメカニズムに関連しています。信頼できないフォワードRTCPチャネルを介してフリーズ画像リクエストを送信することは、問題があると特定されています。したがって、このメモにフリーズ画像リクエストは含まれていません。ここでは、ユースケースのディスカッションは再現されていません。
6. A video mixer dynamically selects one of the received video streams to be sent out to participants and tries to provide the highest bit rate possible to all participants, while minimizing stream trans-rating. One way of achieving this is to set up sessions with endpoints using the maximum bit rate accepted by each endpoint, and accepted by the call admission method used by the mixer. By means of commands that reduce the maximum media stream bit rate below what has been negotiated during session set up, the mixer can reduce the maximum bit rate sent by endpoints to the lowest of all the accepted bit rates. As the lowest accepted bit rate changes due to endpoints joining and leaving or due to network congestion, the mixer can adjust the limits at which endpoints can send their streams to match the new value. The mixer then requests a new maximum bit rate, which is equal to or less than the maximum bit rate negotiated at session setup for a specific media stream, and the remote endpoint can respond with the actual bit rate that it can support.
6. ビデオミキサーは、受信したビデオストリームの1つを参加者に動的に選択し、すべての参加者に可能な限り最高のビットレートを提供しようとし、ストリームトランスレーティングを最小限に抑えようとします。これを達成する1つの方法は、各エンドポイントによって受け入れられ、ミキサーが使用するコール入学方法で受け入れられた最大ビットレートを使用して、エンドポイントでセッションをセットアップすることです。セッションのセットアップ中にネゴシエートされたメディアストリームビットレートを最大限に低下させるコマンドにより、ミキサーはエンドポイントによって送信される最大ビットレートを、受け入れられているすべてのビットレートの中で最低に減らすことができます。エンドポイントが参加して出発するか、ネットワークの輻輳が発生するため、最低の受け入れられたビットレートの変更は、エンドポイントが新しい値に合わせてストリームを送信できる制限を調整できます。その後、ミキサーは新しい最大ビットレートを要求します。これは、特定のメディアストリームのセッションセットアップでネゴシエートされた最大ビットレート以下に等しく、リモートエンドポイントはサポートできる実際のビットレートで応答できます。
The picture Basso, et al., draw up covers most applications we foresee. However, we would like to extend the list with two additional use cases:
7. Currently deployed congestion control algorithms (AIMD and TCP Friendly Rate Control (TFRC) [RFC3448]) probe for additional available capacity as long as there is something to send. With congestion control algorithms using packet loss as the indication for congestion, this probing generally results in reduced media quality (often to a point where the distortion is large enough to make the media unusable), due to packet loss and increased delay.
7. 現在展開されている混雑制御アルゴリズム（AIMDおよびTCPフレンドリーレートコントロール（TFRC）[RFC3448]）プローブを送信するものがある限り、追加の利用可能な容量をプローブします。混雑の兆候としてパケット損失を使用した輻輳制御アルゴリズムでは、一般に、このプローブは、パケットの損失と遅延の増加により、メディアの品質が低下します（多くの場合、メディアを使用できないほど大きくするポイントまで）。
In a number of deployment scenarios, especially cellular ones, the bottleneck link is often the last hop link. That cellular link also commonly has some type of QoS negotiation enabling the cellular device to learn the maximal bit rate available over this last hop. A media receiver behind this link can, in most (if not all) cases, calculate at least an upper bound for the bit rate available for each media stream it presently receives. How this is done is an implementation detail and not discussed herein. Indicating the maximum available bit rate to the transmitting party for the various media streams can be beneficial to prevent that party from probing for bandwidth for this stream in excess of a known hard limit. For cellular or other mobile devices, the known available bit rate for each stream (deduced from the link bit rate) can change quickly, due to handover to another transmission technology, QoS renegotiation due to congestion, etc. To enable minimal disruption of service, quick convergence is necessary, and therefore media path signaling is desirable.
多くの展開シナリオ、特に携帯電話のシナリオでは、ボトルネックリンクがしばしば最後のホップリンクです。このセルラーリンクには、一般に、セルラーデバイスがこの最後のホップで利用可能な最大ビットレートを学習できるようにするための何らかのタイプのQoS交渉もあります。このリンクの背後にあるメディアレシーバーは、ほとんど（すべてではないにしても）で、現在受け取っている各メディアストリームで使用可能なビットレートの少なくとも上限を計算できます。これがどのように行われるかは、実装の詳細であり、ここでは議論されていません。さまざまなメディアストリームの送信当事者への最大利用可能なビットレートを示すことは、既知のハードリミットを超えるこのストリームの帯域幅を調査するのを防ぐために有益です。セルラーまたは他のモバイルデバイスの場合、各ストリームで既知の利用可能なビットレート（リンクビットレートから推定）は、別の伝送テクノロジーへの引き渡し、混雑によるQoS再交渉など、サービスの最小限の侵害を可能にするために迅速に変化する可能性があります。迅速な収束が必要であるため、メディアパスシグナル伝達が望ましいです。
8. The use of reference picture selection (RPS) as an error resilience tool was introduced in 1997 as NEWPRED [NEWPRED], and is now widely deployed. When RPS is in use, simplistically put, the receiver can send a feedback message to the sender, indicating a reference picture that should be used for future prediction. ([NEWPRED] mentions other forms of feedback as well.) AVPF contains a mechanism for conveying such a message, but did not specify for which codec and according to which syntax the message should conform. Recently, the ITU-T finalized Rec. H.271, which (among other message types) also includes a feedback message. It is expected that this feedback message will fairly quickly enjoy wide support. Therefore, a mechanism to convey feedback messages according to H.271 appears to be desirable.
8. エラーレジリエンスツールとしての参照画像選択（RPS）の使用は、1997年にNewPred [NewPred]として導入され、現在広く展開されています。RPSが単純に使用されている場合、受信者は送信者にフィードバックメッセージを送信でき、将来の予測に使用する必要がある参照画像を示します。（[NewPred]他の形式のフィードバックも言及しています。）AVPFには、そのようなメッセージを伝えるためのメカニズムが含まれていますが、どのコーデックを指定していませんでした。最近、ITU-TはRecを確定しました。（他のメッセージタイプの中でも）フィードバックメッセージも含まれているH.271。このフィードバックメッセージは、かなり迅速に幅広いサポートを享受できると予想されます。したがって、H.271に従ってフィードバックメッセージを伝えるメカニズムが望ましいと思われます。
There are two reasons why we use the media path for the codec control messages.
コーデック制御メッセージにメディアパスを使用する理由は2つあります。
First, systems employing MCUs often separate the control and media processing parts. As these messages are intended for or generated by the media part rather than the signaling part of the MCU, having them on the media path avoids transmission across interfaces and unnecessary control traffic between signaling and processing. If the MCU is physically decomposed, the use of the media path avoids the need for media control protocol extensions (e.g., in media gateway control (MEGACO) [RFC3525]).
第一に、MCUを使用するシステムは、多くの場合、コントロールとメディアの処理部品を分離します。これらのメッセージは、MCUの信号部分ではなくメディア部分によって意図されている、または生成されているため、メディアパスにそれらを置くことで、インターフェイス間の送信とシグナリングと処理の間の不必要な制御トラフィックが回避されます。MCUが物理的に分解されている場合、メディアパスを使用すると、メディア制御プロトコル拡張機能（メディアゲートウェイ制御（Megaco）[RFC3525]）の必要性が回避されます。
Secondly, the signaling path quite commonly contains several signaling entities, e.g., SIP proxies and application servers. Avoiding going through signaling entities avoids delay for several reasons. Proxies have less stringent delay requirements than media processing, and due to their complex and more generic nature may result in significant processing delay. The topological locations of the signaling entities are also commonly not optimized for minimal delay, but rather towards other architectural goals. Thus, the signaling path can be significantly longer in both geographical and delay sense.
第二に、信号パスには、一般に、SIPプロキシやアプリケーションサーバーなど、いくつかのシグナリングエンティティが含まれています。シグナルエンティティを通過することを避けることは、いくつかの理由で遅延を回避します。プロキシは、メディア処理よりも厳しい遅延要件が少なく、複雑で一般的な性質により、処理遅延が大幅に発生する可能性があります。シグナルエンティティのトポロジカル位置も、最小限の遅延のために最適化されていませんが、他の建築目標に向けて最適化されています。したがって、地理的感覚と遅延感覚の両方で、シグナリングパスはかなり長くなる可能性があります。
The AVPF feedback message framework [RFC4585] provides the appropriate framework to implement the new messages. AVPF implements rules controlling the timing of feedback messages to avoid congestion through network flooding by RTCP traffic. We re-use these rules by referencing AVPF.
AVPFフィードバックメッセージフレームワーク[RFC4585]は、新しいメッセージを実装するための適切なフレームワークを提供します。AVPFは、RTCPトラフィックによるネットワーク洪水による輻輳を回避するために、フィードバックメッセージのタイミングを制御するルールを実装します。AVPFを参照することにより、これらのルールを再利用します。
The signaling setup for AVPF allows each individual type of function to be configured or negotiated on an RTP session basis.
AVPFのシグナリングセットアップにより、個々のタイプの機能をRTPセッションベースで構成またはネゴシエートすることができます。
The use of RTCP messages implies that each message transfer is unreliable, unless the lower layer transport provides reliability. The different messages proposed in this specification have different requirements in terms of reliability. However, in all cases, the reaction to an (occasional) loss of a feedback message is specified.
RTCPメッセージの使用は、下層輸送が信頼性を提供しない限り、各メッセージ転送が信頼できないことを意味します。この仕様で提案されている異なるメッセージは、信頼性の点で異なる要件を持っています。ただし、すべての場合において、フィードバックメッセージの（時折）損失に対する反応が指定されています。
The codec control messages might be used with multicast. The RTCP timing rules specified in [RFC3550] and [RFC4585] ensure that the messages do not cause overload of the RTCP connection. The use of multicast may result in the reception of messages with inconsistent semantics. The reaction to inconsistencies depends on the message type, and is discussed for each message type separately.
コーデック制御メッセージは、マルチキャストで使用される場合があります。[RFC3550]および[RFC4585]で指定されたRTCPタイミングルールは、メッセージがRTCP接続の過負荷を引き起こさないことを確認します。マルチキャストを使用すると、一貫性のないセマンティクスを含むメッセージが受信される可能性があります。矛盾に対する反応はメッセージタイプに依存し、各メッセージタイプについて個別に説明されています。
This section describes the semantics of the different feedback messages and how they apply to the different use cases.
このセクションでは、さまざまなフィードバックメッセージのセマンティクスと、それらが異なるユースケースにどのように適用するかについて説明します。
A Full Intra Request (FIR) Command, when received by the designated media sender, requires that the media sender sends a Decoder Refresh Point (see section 2.2) at the earliest opportunity. The evaluation of such an opportunity includes the current encoder coding strategy and the current available network resources.
指定されたメディア送信者が受信した場合、完全なリクエスト（FIR）コマンドでは、メディア送信者が最も早い機会にデコーダーリフレッシュポイント（セクション2.2を参照）を送信する必要があります。このような機会の評価には、現在のエンコーダーコーディング戦略と現在の利用可能なネットワークリソースが含まれます。
FIR is also known as an "instantaneous decoder refresh request", "fast video update request" or "video fast update request".
FIRは、「瞬時デコーダー更新リクエスト」、「高速ビデオ更新リクエスト」、または「ビデオ高速更新リクエスト」としても知られています。
Using a decoder refresh point implies refraining from using any picture sent prior to that point as a reference for the encoding process of any subsequent picture sent in the stream. For predictive media types that are not video, the analogue applies. For example, if in MPEG-4 systems scene updates are used, the decoder refresh point consists of the full representation of the scene and is not delta-coded relative to previous updates.
デコーダーリフレッシュポイントを使用すると、ストリームで送信された後続の画像のエンコーディングプロセスの参照として、そのポイントの前に送信された画像を使用することを控えることを意味します。ビデオではない予測メディアタイプの場合、アナログが適用されます。たとえば、MPEG-4システムのシーンの更新を使用している場合、デコーダーリフレッシュポイントはシーンの完全な表現で構成されており、以前の更新と比較してデルタコード化されていません。
Decoder refresh points, especially Intra or IDR pictures, are in general several times larger in size than predicted pictures. Thus, in scenarios in which the available bit rate is small, the use of a decoder refresh point implies a delay that is significantly longer than the typical picture duration.
デコーダーリフレッシュポイント、特にIntraまたはIDRの写真は、一般的に予測される写真の数倍大きいサイズです。したがって、利用可能なビットレートが小さいシナリオでは、デコーダーリフレッシュポイントの使用は、一般的な画像期間よりもかなり長い遅延を意味します。
Usage in multicast is possible; however, aggregation of the commands is recommended. A receiver that receives a request closely after sending a decoder refresh point -- within 2 times the longest round trip time (RTT) known, plus any AVPF-induced RTCP packet sending delays -- should await a second request message to ensure that the media receiver has not been served by the previously delivered decoder refresh point. The reason for the specified delay is to avoid sending unnecessary decoder refresh points. A session participant may have sent its own request while another participant's request was in-flight to them. Suppressing those requests that may have been sent without knowledge about the other request avoids this issue.
マルチキャストでの使用が可能です。ただし、コマンドの集約をお勧めします。デコーダーリフレッシュポイントを送信した後に密接にリクエストを受信するレシーバー - 既知の最長の往復時間（RTT）の2倍以内に、さらにAVPF誘発RTCPパケット送信の遅延が送信される必要があります。レシーバーは、以前に配信されたデコーダーリフレッシュポイントによって提供されていません。指定された遅延の理由は、不必要なデコーダーリフレッシュポイントの送信を避けるためです。セッションの参加者は、別の参加者の要求が彼らに機内に照らされている間、独自の要求を送信したかもしれません。他の要求について知らずに送信された可能性のあるリクエストを抑制すると、この問題は回避されます。
Using the FIR command to recover from errors is explicitly disallowed, and instead the PLI message defined in AVPF [RFC4585] should be used. The PLI message reports lost pictures and has been included in AVPF for precisely that purpose.
FIRコマンドを使用してエラーから回復することは明示的に許可されており、代わりにAVPF [RFC4585]で定義されているPLIメッセージを使用する必要があります。PLIメッセージは失われた写真を報告し、まさにその目的のためにAVPFに含まれています。
Full Intra Request is applicable in use-cases 1 and 2.
完全なリクエストは、ユースケース1および2で適用されます。
The FIR message results in the delivery of a decoder refresh point, unless the message is lost. Decoder refresh points are easily identifiable from the bit stream. Therefore, there is no need for protocol-level notification, and a simple command repetition mechanism is sufficient for ensuring the level of reliability required. However, the potential use of repetition does require a mechanism to prevent the recipient from responding to messages already received and responded to.
FIRメッセージは、メッセージが失われない限り、デコーダーリフレッシュポイントの配信になります。デコーダーリフレッシュポイントは、ビットストリームから簡単に識別できます。したがって、プロトコルレベルの通知は必要ありません。また、必要な信頼性のレベルを保証するには、単純なコマンド繰り返しメカニズムで十分です。ただし、繰り返しの潜在的な使用には、受信者がすでに受信および応答されたメッセージに応答することを防ぐためのメカニズムが必要です。
To ensure the best possible reliability, a sender of FIR may repeat the FIR until the desired content has been received. The repetition interval is determined by the RTCP timing rules applicable to the session. Upon reception of a complete decoder refresh point or the detection of an attempt to send a decoder refresh point (which got damaged due to a packet loss), the repetition of the FIR must stop. If another FIR is necessary, the request sequence number must be increased. A FIR sender shall not have more than one FIR (different request sequence number) outstanding at any time per media sender in the session.
可能な限り最高の信頼性を確保するために、FIRの送信者は、目的のコンテンツが受信されるまでFIRを繰り返すことができます。繰り返し間隔は、セッションに適用されるRTCPタイミングルールによって決定されます。完全なデコーダーリフレッシュポイントを受信したり、デコーダーリフレッシュポイントを送信しようとする試み（パケット損失のために損傷した）を検出すると、FIRの繰り返しが停止する必要があります。別のFIRが必要な場合は、リクエストシーケンス番号を増やす必要があります。FIR送信者は、セッションのメディア送信者ごとに、いつでも1つ以上のFIR（異なるリクエストシーケンス番号）を傑出させてはなりません。
The receiver of FIR (i.e., the media sender) behaves in complementary fashion to ensure delivery of a decoder refresh point. If it receives repetitions of the FIR more than 2*RTT after it has sent a decoder refresh point, it shall send a new decoder refresh point. Two round trip times allow time for the decoder refresh point to arrive back to the requestor and for the end of repetitions of FIR to reach and be detected by the media sender.
FIRの受信者（つまり、メディア送信者）は、デコーダーリフレッシュポイントの配信を確保するために、補完的な方法で動作します。デコーダーリフレッシュポイントを送信した後、2*RTTを超えるFIRの繰り返しを受信した場合、新しいデコーダーリフレッシュポイントを送信するものとします。2つの往復時間により、デコーダーリフレッシュポイントがリクエスターに戻り、MIRの繰り返しが終了してメディア送信者に到達して検出されるまでの時間が得られます。
An RTP mixer or RTP switching MCU that receive a FIR from a media receiver is responsible to ensure that a decoder refresh point is delivered to the requesting receiver. It may be necessary for the mixer/MCU to generate FIR commands. From a reliability perspective, the two legs (FIR-requesting endpoint to mixer/MCU, and mixer/MCU to decoder refresh point generating endpoint) are handled independently from each other.
メディアレシーバーからFIRを受け取るRTPミキサーまたはRTPスイッチングMCUは、デコーダーリフレッシュポイントが要求レシーバーに配信されるように責任があります。ミキサー/MCUがFIRコマンドを生成する必要がある場合があります。信頼性の観点から、2本の脚（ミキサー/MCU、ミキサー/MCUへのFIR-Requestingエンドポイント、デコーダーリフレッシュポイント生成エンドポイント）は、互いに独立して処理されます。
The Temporal-Spatial Trade-off Request (TSTR) instructs the video encoder to change its trade-off between temporal and spatial resolution. Index values from 0 to 31 indicate monotonically a desire for higher frame rate. That is, a requester asking for an index of 0 prefers a high quality and is willing to accept a low frame rate, whereas a requester asking for 31 wishes a high frame rate, potentially at the cost of low spatial quality.
時間空間トレードオフリクエスト（TSTR）は、ビデオエンコーダーに、時間分解能と空間解像度の間のトレードオフを変更するよう指示します。0から31のインデックス値は、単調に高いフレームレートの欲求を示しています。つまり、0のインデックスを要求する要求者は高品質を好み、低いフレームレートを受け入れることをいとわないのに対し、31の希望を求める要求者は、空間品質が低い場合の高いフレームレートを希望する可能性があります。
In general, the encoder reaction time may be significantly longer than the typical picture duration. See use case 3 for an example. The encoder decides whether and to what extent the request results in a change of the trade-off. It returns a Temporal-Spatial Trade-off Notification (TSTN) message to indicate the trade-off that it will use henceforth.
一般に、エンコーダーの反応時間は、典型的な画像期間よりも大幅に長くなる場合があります。例については、ユースケース3を参照してください。エンコーダは、リクエストがトレードオフの変更をもたらすかどうか、どの程度まで決定します。時間空間トレードオフ通知（TSTN）メッセージを返して、今後使用するというトレードオフを示します。
TSTR and TSTN have been introduced primarily because it is believed that control protocol mechanisms, e.g., a SIP re-invite, are too heavyweight and too slow to allow for a reasonable user experience. Consider, for example, a user interface where the remote user selects the temporal/spatial trade-off with a slider. An immediate feedback to any slider movement is required for a reasonable user experience. A SIP re-INVITE [RFC3261] would require at least two round-trips more (compared to the TSTR/TSTN mechanism) and may involve proxies and other complex mechanisms. Even in a well-designed system, it could take a second or so until the new trade-off is finally selected. Furthermore, the use of RTCP solves the multicast use case very efficiently.
TSTRとTSTNは、主に制御プロトコルメカニズム（たとえば、SIP Re-Inviteが重すぎて遅すぎて、合理的なユーザーエクスペリエンスを可能にすることができないと考えられているため、導入されています。たとえば、リモートユーザーがスライダーとの時間的/空間的トレードオフを選択するユーザーインターフェイスを検討してください。合理的なユーザーエクスペリエンスには、スライダーの動きに対する即時フィードバックが必要です。SIP Re-Invite [RFC3261]には、少なくとも2つのラウンドトリップが必要になり（TSTR/TSTNメカニズムと比較して）、プロキシやその他の複雑なメカニズムが含まれる場合があります。適切に設計されたシステムであっても、新しいトレードオフが最終的に選択されるまで1秒ほどかかる可能性があります。さらに、RTCPの使用は、マルチキャストユースケースを非常に効率的に解決します。
The use of TSTR and TSTN in multipoint scenarios is a non-trivial subject, and can be achieved in many implementation-specific ways.
マルチポイントシナリオでのTSTRとTSTNの使用は、自明ではない主題であり、多くの実装固有の方法で達成できます。
Problems stem from the fact that TSTRs will typically arrive unsynchronized, and may request different trade-off values for the same stream and/or endpoint encoder. This memo does not specify a translator's, mixer's, or endpoint's reaction to the reception of a suggested trade-off as conveyed in the TSTR. We only require the receiver of a TSTR message to reply to it by sending a TSTN, carrying the new trade-off chosen by its own criteria (which may or may not be based on the trade-off conveyed by the TSTR). In other words, the trade-off sent in a TSTR is a non-binding recommendation, nothing more.
問題は、TSTRSが通常異常に到着し、同じストリームおよび/またはエンドポイントエンコーダーの異なるトレードオフ値を要求する可能性があるという事実に起因します。このメモは、TSTRで伝えられている推奨されるトレードオフの受容に対する翻訳者、ミキサー、またはエンドポイントの反応を指定しません。TSTNメッセージの受信者は、TSTNを送信して、独自の基準（TSTRによって伝えられるトレードオフに基づいている場合と基づいている場合がある場合があります）でTSTNを送信することによってのみ返信する必要があります。言い換えれば、TSTRで送信されたトレードオフは、拘束力のない推奨事項であり、それ以上のものではありません。
Three TSTR/TSTN scenarios need to be distinguished, based on the topologies described in [RFC5117]. The scenarios are described in the following subsections.
[RFC5117]で説明されているトポロジに基づいて、3つのTSTR/TSTNシナリオを区別する必要があります。シナリオは、次のサブセクションで説明されています。
In this most trivial case (Topo-Point-to-Point), the media sender typically adjusts its temporal/spatial trade-off based on the requested value in TSTR, subject to its own capabilities. The TSTN message conveys back the new trade-off value (which may be identical to the old one if, for example, the sender is not capable of adjusting its trade-off).
この最も些細なケース（トポポイントからポイントへ）では、メディア送信者は通常、独自の能力を条件として、TSTRの要求された値に基づいて時間的/空間的トレードオフを調整します。TSTNメッセージは、新しいトレードオフ値を伝えます（たとえば、送信者がトレードオフを調整できない場合、古いものと同一である可能性があります）。
RTCP Multicast is used either with media multicast according to Topo-Multicast, or following RFC 3550's translator model according to Topo-Translator. In these cases, unsynchronized TSTR messages from different receivers may be received, possibly with different requested trade-offs (because of different user preferences). This memo does not specify how the media sender tunes its trade-off. Possible strategies include selecting the mean or median of all trade-off requests received, giving priority to certain participants, or continuing to use the previously selected trade-off (e.g., when the sender is not capable of adjusting it). Again, all TSTR messages need to be acknowledged by TSTN, and the value conveyed back has to reflect the decision made.
RTCPマルチキャストは、Topo-Multicastによるとメディアマルチキャストで使用されるか、Topo-Translatorに応じてRFC 3550の翻訳モデルに従います。これらの場合、さまざまな受信機からの非色素化されていないTSTRメッセージが受信される場合があります。このメモは、メディアの送信者がトレードオフをどのように調整するかを指定していません。可能な戦略には、受け取ったすべてのトレードオフリクエストの平均または中央値の選択、特定の参加者に優先順位を与える、または以前に選択されたトレードオフの使用を継続することが含まれます（たとえば、送信者がそれを調整できない場合）。繰り返しますが、すべてのTSTRメッセージはTSTNによって確認される必要があり、伝達される値は決定を反映する必要があります。
In this scenario (Topo-Mixer), the RTP mixer receives all TSTR messages, and has the opportunity to act on them based on its own criteria. In most cases, the mixer should form a "consensus" of potentially conflicting TSTR messages arriving from different participants, and initiate its own TSTR message(s) to the media sender(s). As in the previous scenario, the strategy for forming this "consensus" is up to the implementation, and can, for example, encompass averaging the participants' request values, giving priority to certain participants, or using session default values.
このシナリオ（Topo-Mixer）では、RTPミキサーはすべてのTSTRメッセージを受信し、独自の基準に基づいて行動する機会があります。ほとんどの場合、ミキサーは、異なる参加者から到着する潜在的に矛盾するTSTRメッセージの「コンセンサス」を形成し、独自のTSTRメッセージをメディア送信者に開始する必要があります。以前のシナリオのように、この「コンセンサス」を形成するための戦略は実装次第であり、たとえば、参加者の要求値を平均する、特定の参加者に優先順位を与える、またはセッションのデフォルト値を使用することができます。
Even if a mixer or translator performs transcoding, it is very difficult to deliver media with the requested trade-off, unless the content the mixer or translator receives is already close to that trade-off. Thus, if the mixer changes its trade-off, it needs to request the media sender(s) to use the new value, by creating a TSTR of its own. Upon reaching a decision on the used trade-off, it includes that value in the acknowledgement to the downstream requestors. Only in cases where the original source has substantially higher quality (and bit rate) is it likely that transcoding alone can result in the requested trade-off.
ミキサーまたは翻訳者がトランスコーディングを実行したとしても、ミキサーまたは翻訳者が受け取るコンテンツがすでにそのトレードオフに近い場合を除き、要求されたトレードオフでメディアを配信することは非常に困難です。したがって、ミキサーがトレードオフを変更する場合、独自のTSTRを作成することにより、メディア送信者に新しい値を使用するように要求する必要があります。使用済みのトレードオフに関する決定に到達すると、下流の要求者に対する謝辞にその値が含まれます。元のソースが実質的に高品質（およびビットレート）を持っている場合にのみ、トランスコーディングだけで要求されたトレードオフにつながる可能性があります。
A request and reception acknowledgement mechanism is specified. The Temporal-Spatial Trade-off Notification (TSTN) message informs the requester that its request has been received, and what trade-off is used henceforth. This acknowledgement mechanism is desirable for at least the following reasons:
リクエストとレセプションの確認メカニズムが指定されています。時間空間トレードオフ通知（TSTN）メッセージは、要求者がその要求を受け取ったこと、そして今後どのようなトレードオフが使用されるかを要求者に通知します。この承認メカニズムは、少なくとも次の理由で望ましいものです。
o A change in the trade-off cannot be directly identified from the media bit stream. o User feedback cannot be implemented without knowing the chosen trade-off value, according to the media sender's constraints. o Repetitive sending of messages requesting an unimplementable trade-off can be avoided.
o トレードオフの変更は、メディアビットストリームから直接識別することはできません。oメディア送信者の制約に従って、選択したトレードオフ値を知らずにユーザーフィードバックを実装することはできません。o実現不可能なトレードオフを要求するメッセージの反復送信は回避できます。
ITU-T Rec. H.271 defines syntax, semantics, and suggested encoder reaction to a Video Back Channel Message. The structure defined in this memo is used to transparently convey such a message from media receiver to media sender. In this memo, we refrain from an in-depth discussion of the available code points within H.271 and refer to the specification text [H.271] instead.
itu-t rec。H.271は、構文、セマンティクス、およびビデオバックチャネルメッセージに対する推奨エンコーダー反応を定義します。このメモで定義されている構造は、メディアの受信者からメディア送信者にそのようなメッセージを透過的に伝えるために使用されます。このメモでは、H.271内の利用可能なコードポイントの詳細な説明を控え、代わりに仕様テキスト[H.271]を参照します。
However, we note that some H.271 messages bear similarities with native messages of AVPF and this memo. Furthermore, we note that some H.271 message are known to require caution in multicast environments -- or are plainly not usable in multicast or multipoint scenarios. Table 1 provides a brief, simplified overview of the messages currently defined in H.271, their roughly corresponding AVPF or Codec Control Messages (CCMs) (the latter as specified in this memo), and an indication of our current knowledge of their multicast safety.
ただし、一部のH.271メッセージは、AVPFのネイティブメッセージとこのメモとの類似点があることに注意してください。さらに、いくつかのH.271メッセージは、マルチキャスト環境では注意が必要であることが知られているか、マルチキャストまたはマルチポイントシナリオでは明らかに使用できないことに注意してください。表1に、H.271で現在定義されているメッセージの簡単な簡単な概要、ほぼ対応するAVPFまたはコーデック制御メッセージ（CCMS）（このメモで指定されている後者）、およびマルチキャストの安全性に関する現在の知識の兆候を示します。。
H.271 msg type AVPF/CCM msg type multicast-safe
--------------------------------------------------------------------
0 (when used for
reference picture
selection) AVPF RPSI No (positive ACK of pictures)
1 picture loss AVPF PLI Yes
2 partial loss AVPF SLI Yes
3 one parameter CRC N/A Yes (no required sender action)
4 all parameter CRC N/A Yes (no required sender action)
5 refresh point CCM FIR Yes
Table 1: H.271 messages and their AVPF/CCM equivalents
表1：H.271メッセージとそのAVPF/CCM相当
Note: H.271 message type 0 is not a strict equivalent to AVPF's Reference Picture Selection Indication (RPSI); it is an indication of known-as-correct reference picture(s) at the decoder. It does not command an encoder to use a defined reference picture (the form of control information envisioned to be carried in RPSI). However, it is believed and intended that H.271 message type 0 will be used for the same purpose as AVPF's RPSI -- although other use forms are also possible.
注：H.271メッセージタイプ0は、AVPFのリファレンス画像選択表示（RPSI）に相当するものではありません。これは、デコーダーで既知の正しい参照画像の兆候です。エンコーダーに定義された参照画像（RPSIで運ばれると想定される制御情報の形式）を使用するように指示しません。ただし、H.271メッセージタイプ0はAVPFのRPSIと同じ目的で使用されると考えられており、他の使用フォームも可能です。
In response to the opaqueness of the H.271 messages, especially with respect to the multicast safety, the following guidelines MUST be followed when an implementation wishes to employ the H.271 video back channel message:
特にマルチキャストの安全性に関して、H.271メッセージの不透明度に応じて、実装がH.271ビデオバックチャネルメッセージを採用したい場合は、次のガイドラインに従う必要があります。
1. Implementations utilizing the H.271 feedback message MUST stay in compliance with congestion control principles, as outlined in section 5.
1. H.271フィードバックメッセージを利用する実装は、セクション5で概説されているように、輻輳制御原則に準拠している必要があります。
2. An implementation SHOULD utilize the IETF-native messages as defined in [RFC4585] and in this memo instead of similar messages defined in [H.271]. Our current understanding of similar messages is documented in Table 1 above. One good reason to divert from the SHOULD statement above would be if it is clearly understood that, for a given application and video compression standard, the aforementioned "similarity" is not given, in contrast to what the table indicates.
2. [RFC4585]で定義されているIETFネイティブメッセージと、[H.271]で定義された同様のメッセージの代わりに、このメモで実装する必要があります。同様のメッセージの現在の理解は、上記の表1に記載されています。上記の声明から迂回する正当な理由の1つは、特定のアプリケーションとビデオ圧縮基準について、テーブルが示すものとは対照的に、前述の「類似性」が与えられていないことが明確に理解されている場合です。
3. It has been observed that some of the H.271 code points currently in existence are not multicast-safe. Therefore, the sensible thing to do is not to use the H.271 feedback message type in multicast environments. It MAY be used only when all the issues mentioned later are fully understood by the implementer, and properly taken into account by all endpoints. In all other cases, the H.271 message type MUST NOT be used in conjunction with multicast.
3. 現在存在しているH.271コードポイントの一部はマルチキャストセーフではないことが観察されています。したがって、賢明なことは、マルチキャスト環境でH.271フィードバックメッセージタイプを使用しないことです。後で言及されたすべての問題が実装者によって完全に理解され、すべてのエンドポイントによって適切に考慮された場合にのみ使用できます。他のすべてのケースでは、H.271メッセージタイプをマルチキャストと併用してはいけません。
4. It has been observed that even in centralized multipoint environments, where the mixer should theoretically be able to resolve issues as documented below, the implementation of such a mixer and cooperative endpoints is a very difficult and tedious task. Therefore, H.271 messages MUST NOT be used in centralized multipoint scenarios, unless all the issues mentioned below are fully understood by the implementer, and properly taken into account by both mixer and endpoints.
4. ミキサーが理論的に以下に文書化するように問題を解決できるようにするための集中型マルチポイント環境でさえ、このようなミキサーと協同組合のエンドポイントの実装は非常に困難で退屈な作業であることが観察されています。したがって、以下のすべての問題が実装者によって完全に理解され、ミキサーとエンドポイントの両方で適切に考慮されない限り、H.271メッセージは集中型マルチポイントシナリオで使用してはなりません。
Issues to be taken into account when considering the use of H.271 in multipoint environments:
マルチポイント環境でのH.271の使用を検討する際に考慮すべき問題：
1. Different state on different receivers. In many environments, it cannot be guaranteed that the decoder state of all media receivers is identical at any given point in time. The most obvious reason for such a possible misalignment of state is a loss that occurs on the path to only one of many media receivers. However, there are other not so obvious reasons, such as recent joins to the multipoint conference (be it by joining the multicast group or through additional mixer output). Different states can lead the media receivers to issue potentially contradicting H.271 messages (or one media receiver issuing an H.271 message that, when observed by the media sender, is not helpful for the other media receivers). A naive reaction of the media sender to these contradicting messages can lead to unpredictable and annoying results.
1. 異なるレシーバーの異なる状態。多くの環境では、すべてのメディアレシーバーのデコーダー状態が任意の時点で同一であることを保証することはできません。このような国家の不整合の可能性のある最も明白な理由は、多くのメディアレシーバーの1つだけへの道で発生する損失です。ただし、最近のMultipoint Conferenceへの参加など、それほど明白ではない理由はありません（マルチキャストグループに参加するか、追加のミキサー出力を介して）。さまざまな状態が、メディアレシーバーが潜在的に矛盾するH.271メッセージ（またはメディア送信者によって観察された場合、他のメディアレシーバーには役に立たないというH.271メッセージを発行する1つのメディアレシーバーを発行するように導く可能性があります。これらの矛盾するメッセージに対するメディア送信者の素朴な反応は、予測不可能で迷惑な結果につながる可能性があります。
2. Combining messages from different media receivers in a media sender is a non-trivial task. As reasons, we note that these messages may be contradicting each other, and that their transport is unreliable (there may well be other reasons). In case of many H.271 messages (i.e., types 0, 2, 3, and 4), the algorithm for combining must be aware both of the network/protocol environment (i.e., with respect to congestion) and of the media codec employed, as H.271 messages of a given type can have different semantics for different media codecs.
2. メディア送信者のさまざまなメディアレシーバーからのメッセージを組み合わせることは、非自明なタスクです。理由として、これらのメッセージは互いに矛盾している可能性があり、それらの輸送は信頼できないことに注意してください（他の理由があるかもしれません）。多くのH.271メッセージ（つまり、タイプ0、2、3、および4）の場合、組み合わせのためのアルゴリズムは、ネットワーク/プロトコル環境（すなわち、うっ血に関して）と採用されたメディアコーデックの両方に注意する必要があります。、特定のタイプのH.271メッセージには、さまざまなメディアコーデックに対して異なるセマンティクスを持つことができます。
3. The suppression of requests may need to go beyond the basic mechanisms described in AVPF (which are driven exclusively by timing and transport considerations on the protocol level). For example, a receiver is often required to refrain from (or delay) generating requests, based on information it receives from the media stream. For instance, it makes no sense for a receiver to issue a FIR when a transmission of an Intra/IDR picture is ongoing.
3. リクエストの抑制は、AVPFで説明されている基本的なメカニズムを超える必要がある場合があります（これは、プロトコルレベルでのタイミングと輸送の考慮事項によってのみ駆動されます）。たとえば、メディアストリームから受け取った情報に基づいて、リクエストの生成を控える（または遅延）する（または遅延）レシーバーが必要になることがよくあります。たとえば、Intra/IDR画像の送信が進行中の場合、受信者がFIRを発行することは意味がありません。
4. When using the non-multicast-safe messages (e.g., H.271 type 0 positive ACK of received pictures/slices) in larger multicast groups, the media receiver will likely be forced to delay or even omit sending these messages. For the media sender, this looks like data has not been properly received (although it was received properly), and a naively implemented media sender reacts to these perceived problems where it should not.
4. 大規模なマルチキャストグループで非マルチキャストセーフメッセージ（たとえば、H.271タイプ0の受信写真/スライスの陽性ACK）を使用する場合、メディアレシーバーはこれらのメッセージの送信を遅らせるか、省略することを余儀なくされる可能性があります。メディア送信者の場合、これはデータが適切に受信されていないように見えますが（適切に受信されましたが）、素朴に実装されたメディア送信者は、これらの知覚されていない問題に反応します。
H.271 Video Back Channel Messages do not require reliable transmission, and confirmation of the reception of a message can be derived from the forward video bit stream. Therefore, no specific reception acknowledgement is specified.
H.271ビデオバックチャネルメッセージには信頼できる送信は必要ありません。メッセージの受信の確認は、フォワードビデオビットストリームから導き出すことができます。したがって、特定の受信承認は指定されていません。
With respect to re-sending rules, section 3.5.1.1 applies.
再配置ルールに関しては、セクション3.5.1.1が適用されます。
A receiver, translator, or mixer uses the Temporary Maximum Media Stream Bit Rate Request (TMMBR, "timber") to request a sender to limit the maximum bit rate for a media stream (see section 2.2) to, or below, the provided value. The Temporary Maximum Media Stream Bit Rate Notification (TMMBN) contains the media sender's current view of the most limiting subset of the TMMBR-defined limits it has received, to help the participants to suppress TMMBRs that would not further restrict the media sender. The primary usage for the TMMBR/TMMBN messages is in a scenario with an MCU or mixer (use case 6), corresponding to Topo-Translator or Topo-Mixer, but also to Topo-Point-to-Point.
レシーバー、翻訳者、またはミキサーは、一時的な最大メディアストリームビットレートリクエスト（TMMBR、「Timber」）を使用して、送信者にメディアストリームの最大ビットレートを制限するように要求します（セクション2.2を参照）。。一時的な最大メディアストリームビットレート通知（TMMBN）には、受信したTMMBR定義の制限の最も制限的なサブセットのメディア送信者の現在のビューが含まれており、参加者がメディア送信者をさらに制限しないTMMBRを抑制するのに役立ちます。TMMBR/TMMBNメッセージの主要な使用法は、MCUまたはミキサーのシナリオにあり（ケース6）、Topo-TranslatorまたはTopo-Mixerに対応するだけでなく、トポポイントからポイントにも対応しています。
Each temporary limitation on the media stream is expressed as a tuple. The first component of the tuple is the maximum total media bit rate (as defined in section 2.2) that the media receiver is currently prepared to accept for this media stream. The second component is the per-packet overhead that the media receiver has observed for this media stream at its chosen reference protocol layer.
メディアストリームの各一時的な制限は、タプルとして表されます。タプルの最初のコンポーネントは、メディアレシーバーが現在このメディアストリームに受け入れる準備ができている最大メディアビットレート（セクション2.2で定義されている）です。2番目のコンポーネントは、選択した参照プロトコルレイヤーでメディアレシーバーがこのメディアストリームに対して観察したパケットごとのオーバーヘッドです。
As indicated in section 2.2, the overhead as observed by the sender of the TMMBR (i.e., the media receiver) may differ from the overhead observed at the receiver of the TMMBR (i.e., the media sender) due to use of a different reference protocol layer at the other end or due to the intervention of translators or mixers that affect the amount of per packet overhead. For example, a gateway in between the two that converts between IPv4 and IPv6 affects the per-packet overhead by 20 bytes. Other mechanisms that change the overhead include tunnels. The problem with varying overhead is also discussed in
セクション2.2に示されているように、TMMBRの送信者（つまり、メディアレシーバー）によって観察されるオーバーヘッドは、異なる参照プロトコルの使用によりTMMBRの受信機（つまり、メディア送信者）で観察されたオーバーヘッドとは異なる場合があります。もう一方の端に層状にするか、パケットあたりのオーバーヘッドの量に影響する翻訳者またはミキサーの介入によるものです。たとえば、IPv4とIPv6の間に変換される2つの間にあるゲートウェイは、パケットごとのオーバーヘッドに20バイトに影響します。オーバーヘッドを変更する他のメカニズムには、トンネルが含まれます。さまざまなオーバーヘッドの問題についても説明します
[RFC3890]. As will be seen in the description of the algorithm for use of TMMBR, the difference in perceived overhead between the sending and receiving ends presents no difficulty because calculations are carried out in terms of variables that have the same value at the sender as at the receiver -- for example, packet rate and net media rate.
[RFC3890]。TMMBRの使用のためのアルゴリズムの説明に見られるように、送信先と受信端の間の知覚オーバーヘッドの違いは、受信者と同じ値を持つ変数の観点から計算が実行されるため、困難はありません - たとえば、パケットレートとネットメディアレート。
Reporting both maximum total media bit rate and per-packet overhead allows different receivers to provide bit rate and overhead values for different protocol layers, for example, at the IP level, at the outer part of a tunnel protocol, or at the link layer. The protocol level a peer reports on depends on the level of integration the peer has, as it needs to be able to extract the information from that protocol level. For example, an application with no knowledge of the IP version it is running over cannot meaningfully determine the overhead of the IP header, and hence will not want to include IP overhead in the overhead or maximum total media bit rate calculation.
最大総メディアビットレートとパケットあたりのオーバーヘッドの両方を報告すると、異なるレシーバーが、たとえば、IPレベル、トンネルプロトコルの外側部分、またはリンクレイヤーで、異なるプロトコル層のビットレートとオーバーヘッド値を提供できます。ピアが報告するプロトコルレベルは、そのプロトコルレベルから情報を抽出できる必要があるため、ピアが持っている統合のレベルに依存します。たとえば、実行中のIPバージョンの知識がないアプリケーションは、IPヘッダーのオーバーヘッドを有意義に決定することができないため、オーバーヘッドまたは最大総メディアビットレートの計算にIPオーバーヘッドを含めることは望ましくありません。
It is expected that most peers will be able to report values at least for the IP layer. In certain implementations, it may be advantageous to also include information pertaining to the link layer, which in turn allows for a more precise overhead calculation and a better optimization of connectivity resources.
ほとんどのピアは、少なくともIPレイヤーについて値を報告できると予想されます。特定の実装では、リンクレイヤーに関する情報も含めることが有利になる場合があります。これにより、より正確なオーバーヘッド計算と接続リソースの最適化が向上します。
The Temporary Maximum Media Stream Bit Rate messages are generic messages that can be applied to any RTP packet stream. This separates them from the other codec control messages defined in this specification, which apply only to specific media types or payload formats. The TMMBR functionality applies to the transport, and the requirements the transport places on the media encoding.
一時的な最大メディアストリームビットレートメッセージは、任意のRTPパケットストリームに適用できる一般的なメッセージです。これにより、特定のメディアタイプまたはペイロード形式にのみ適用されるこの仕様で定義されている他のコーデックコントロールメッセージからそれらを分離します。TMMBR機能は、輸送に適用され、輸送はメディアエンコーディングに配置されます。
The reasoning below assumes that the participants have negotiated a session maximum bit rate, using a signaling protocol. This value can be global, for example, in case of point-to-point, multicast, or translators. It may also be local between the participant and the peer or mixer. In either case, the bit rate negotiated in signaling is the one that the participant guarantees to be able to handle (depacketize and decode). In practice, the connectivity of the participant also influences the negotiated value -- it does not make much sense to negotiate a total media bit rate that one's network interface does not support.
以下の理由は、参加者がシグナリングプロトコルを使用してセッションの最大ビットレートを交渉したことを前提としています。この値は、たとえばポイントツーポイント、マルチキャスト、または翻訳者の場合、グローバルにすることができます。また、参加者とピアまたはミキサーの間にローカルである場合があります。どちらの場合でも、シグナリングで交渉されたビットレートは、参加者が処理できることを保証するものです（脱離およびデコード）。実際には、参加者の接続性は交渉された価値にも影響します。ネットワークインターフェイスがサポートしていない総メディアビットレートを交渉することはあまり意味がありません。
It is also beneficial to have negotiated a maximum packet rate for the session or sender. RFC 3890 provides an SDP [RFC4566] attribute that can be used for this purpose; however, that attribute is not usable in RTP sessions established using offer/answer [RFC3264]. Therefore, an optional maximum packet rate signaling parameter is specified in this memo.
また、セッションまたは送信者の最大パケットレートを交渉したことも有益です。RFC 3890は、この目的に使用できるSDP [RFC4566]属性を提供します。ただし、その属性は、オファー/回答[RFC3264]を使用して確立されたRTPセッションでは使用できません。したがって、このメモでオプションの最大パケットレートシグナリングパラメーターが指定されています。
An already established maximum total media bit rate may be changed at any time, subject to the timing rules governing the sending of feedback messages. The limit may change to any value between zero and the session maximum, as negotiated during session establishment signaling. However, even if a sender has received a TMMBR message allowing an increase in the bit rate, all increases must be governed by a congestion control mechanism. TMMBR indicates known limitations only, usually in the local environment, and does not provide any guarantees about the full path. Furthermore, any increases in TMMBR-established bit rate limits are to be executed only after a certain delay from the sending of the TMMBN message that notifies the world about the increase in limit. The delay is specified as at least twice the longest RTT as known by the media sender, plus the media sender's calculation of the required wait time for the sending of another TMMBR message for this session based on AVPF timing rules. This delay is introduced to allow other session participants to make known their bit rate limit requirements, which may be lower.
すでに確立された最大メディアビットレートは、フィードバックメッセージの送信を管理するタイミングルールを条件として、いつでも変更される場合があります。セッションの確立シグナル伝達中に交渉されたように、制限はゼロとセッションの最大値の間の任意の値に変化する場合があります。ただし、送信者がビットレートの増加を可能にするTMMBRメッセージを受け取ったとしても、すべての増加は渋滞制御メカニズムによって支配されなければなりません。TMMBRは、通常はローカル環境での既知の制限のみを示し、フルパスについての保証を提供しません。さらに、TMMBRが確立したビットレート制限の増加は、制限の増加について世界に通知するTMMBNメッセージの送信による特定の遅延後にのみ実行されます。遅延は、メディア送信者が知っている最長のRTTの少なくとも2倍の最長RTTに加えて、AVPFタイミングルールに基づいてこのセッションに別のTMMBRメッセージを送信するために必要な待機時間のメディア送信者の計算として指定されます。この遅延は、他のセッション参加者がビットレート制限要件をより低い可能性があることを知らせることができるように導入されています。
If it is likely that the new value indicated by TMMBR will be valid for the remainder of the session, the TMMBR sender is expected to perform a renegotiation of the session upper limit using the session signaling protocol.
TMMBRによって示される新しい値がセッションの残りの部分に有効である可能性がある場合、TMMBR送信者は、セッションシグナリングプロトコルを使用してセッション上限の再交渉を実行することが期待されます。
This section is an informal description of behaviour described more precisely in section 4.2.
A media sender begins the session limited by the maximum media bit rate and maximum packet rate negotiated in session signaling, if any. Note that this value may be negotiated for another protocol layer than the one the participant uses in its TMMBR messages. Each media receiver selects a reference protocol layer, forms an estimate of the overhead it is observing (or estimating it if no packets has been seen yet) at that reference level, and determines the maximum total media bit rate it can accept, taking into account its own limitations and any transport path limitations of which it may be aware. In case the current limitations are more restricting than what was agreed on in the session signaling, the media receiver reports its initial estimate of these two quantities to the media sender using a TMMBR message. Overall message traffic is reduced by the possibility of including tuples for multiple media senders in the same TMMBR message.
メディア送信者は、セッションのビットレートとセッションシグナリングで交渉された最大パケットレートによって制限されています。この値は、参加者がTMMBRメッセージで使用するものよりも別のプロトコル層に対してネゴシエートされる可能性があることに注意してください。各メディアレシーバーは、参照プロトコルレイヤーを選択し、その参照レベルでパケットがまだ見られていない場合に観察している（または推定する）オーバーヘッドの推定を形成し、受け入れることができる最大合計メディアビットレートを決定します。独自の制限と、それが認識される可能性のある輸送パスの制限。現在の制限がセッションシグナリングで合意されたものよりも制限がある場合、メディアレシーバーは、TMMBRメッセージを使用してこれらの2つの数量の最初の推定をメディア送信者に報告しています。全体的なメッセージトラフィックは、同じTMMBRメッセージに複数のメディア送信者にタプルを含める可能性によって削減されます。
The media sender applies an algorithm such as that specified in section 3.5.4.2 to select which of the tuples it has received are most limiting (i.e., the bounding set as defined in section 2.2). It modifies its operation to stay within the feasible region (as defined in section 2.2), and also sends out a TMMBN to the media receivers indicating the selected bounding set. That notification also indicates who was responsible for the tuples in the bounding set, i.e., the "owner"(s) of the limitation. A session participant that owns no tuple in the bounding set is called a "non-owner".
メディア送信者は、セクション3.5.4.2で指定されているようなアルゴリズムを適用して、受け取ったタプルのどれが最も制限されているかを選択します（つまり、セクション2.2で定義されている境界セット）。実行可能な領域内にとどまるように操作を変更し（セクション2.2で定義されている）、選択した境界セットを示すメディアレシーバーにTMMBNを送信します。この通知は、境界セットのタプル、つまり制限の「所有者」の責任者であることを示しています。境界セットにタプルを所有していないセッション参加者は、「非所有者」と呼ばれます。
If a media receiver does not own one of the tuples in the bounding set reported by the TMMBN, it applies the same algorithm as the media sender to determine if its current estimated (maximum total media bit rate, overhead) tuple would enter the bounding set if known to the media sender. If so, it issues a TMMBR reporting the tuple value to the sender. Otherwise, it takes no action for the moment. Periodically, its estimated tuple values may change or it may receive a new TMMBN. If so, it reapplies the algorithm to decide whether it needs to issue a TMMBR.
メディアレシーバーがTMMBNによって報告された境界セットのタプルの1つを所有していない場合、メディア送信者と同じアルゴリズムを適用して、現在の推定（最大総メディアビットレート、オーバーヘッド）タプルが境界セットに入るかどうかを判断しますメディア送信者に知られている場合。その場合、送信者にタプル値を報告するTMMBRを発行します。そうでなければ、今のところ行動は必要ありません。定期的に、推定されたタプル値が変化するか、新しいTMMBNを受け取る可能性があります。その場合、アルゴリズムを再度提出して、TMMBRを発行する必要があるかどうかを決定します。
If, alternatively, a media receiver owns one of the tuples in the reported bounding set, it takes no action until such time as its estimate of its own tuple values changes. At that time, it sends a TMMBR to the media sender to report the changed values.
あるいは、メディアレシーバーが報告された境界セットのタプルの1つを所有している場合、独自のタプル値の推定値が変化するまでアクションは必要ありません。その時点で、TMMBRをメディア送信者に送信して、変更された値を報告します。
A media receiver may change status between owner and non-owner of a bounding tuple between one TMMBN message and the next. Thus, it must check the contents of each TMMBN to determine its subsequent actions.
メディアレシーバーは、所有者と1つのTMMBNメッセージと次のメッセージの間の境界タプルの非所有者との間のステータスを変更する場合があります。したがって、各TMMBNの内容をチェックして、その後のアクションを決定する必要があります。
Implementations may use other algorithms of their choosing, as long as the bit rate limitations resulting from the exchange of TMMBR and TMMBN messages are at least as strict (at least as low, in the bit rate dimension) as the ones resulting from the use of the aforementioned algorithm.
実装は、TMMBRとTMMBNメッセージの交換に起因するビットレートの制限が少なくとも少なくとも（少なくとも低い、ビットレート寸法では少なくとも低い）ものである限り、選択の他のアルゴリズムを使用する場合があります。前述のアルゴリズム。
Obviously, in point-to-point cases, when there is only one media receiver, this receiver becomes "owner" once it receives the first TMMBN in response to its own TMMBR, and stays "owner" for the rest of the session. Therefore, when it is known that there will always be only a single media receiver, the above algorithm is not required. Media receivers that are aware they are the only ones in a session can send TMMBR messages with bit rate limits both higher and lower than the previously notified limit, at any time (subject to the AVPF [RFC4585] RTCP RR send timing rules). However, it may be difficult for a session participant to determine if it is the only receiver in the session. Because of this, any implementation of TMMBR is required to include the algorithm described in the next section or a stricter equivalent.
明らかに、ポイントツーポイントの場合、メディアレシーバーが1つしかない場合、この受信者は、独自のTMMBRに応じて最初のTMMBNを受信すると「所有者」になり、セッションの残りの部分で「所有者」を留めます。したがって、常に単一のメディアレシーバーのみがあることがわかっている場合、上記のアルゴリズムは必要ありません。セッションで唯一の人であることを認識しているメディアレシーバーは、以前に通知された制限よりも高いおよび低いビット制限のTMMBRメッセージをいつでも送信できます（AVPF [RFC4585] RTCP RRがタイミングルールを送信）。ただし、セッション参加者がセッションで唯一のレシーバーかどうかを判断することは難しい場合があります。このため、TMMBRの実装は、次のセクションで説明されているアルゴリズムまたはより厳しい同等物を含める必要があります。
This section introduces an example algorithm for the calculation of a session limit. Other algorithms can be employed, as long as the result of the calculation is at least as restrictive as the result that is obtained by this algorithm.
このセクションでは、セッション制限の計算のためのアルゴリズムの例を紹介します。計算の結果が少なくともこのアルゴリズムによって得られる結果と同じくらい制限的である限り、他のアルゴリズムを使用できます。
First, it is important to consider the implications of using a tuple for limiting the media sender's behavior. The bit rate and the overhead value result in a two-dimensional solution space for the calculation of the bit rate of media streams. Fortunately, the two variables are linked. Specifically, the bit rate available for RTP payloads is equal to the TMMBR reported bit rate minus the packet rate used, multiplied by the TMMBR reported overhead converted to bits. As a result, when different bit rate/overhead combinations need to be considered, the packet rate determines the correct limitation. This is perhaps best explained by an example:
まず、メディア送信者の行動を制限するためにタプルを使用することの意味を考慮することが重要です。ビットレートとオーバーヘッド値は、メディアストリームのビットレートを計算するための2次元ソリューションスペースになります。幸いなことに、2つの変数がリンクされています。具体的には、RTPペイロードで利用可能なビットレートは、使用されたパケットレートを差し引いたTMMBRに報告されたビットレートを差し引いて、BITに変換されたTMMBRが報告されたTMMBRを掛けたものに等しくなります。その結果、異なるビットレート/オーバーヘッドの組み合わせを考慮する必要がある場合、パケットレートが正しい制限を決定します。これはおそらく、例で最もよく説明されています。
Example:
例：
Receiver A: TMMBR_max total BR = 35 kbps, TMMBR_OH = 40 bytes
Receiver B: TMMBR_max total BR = 40 kbps, TMMBR_OH = 60 bytes
For a given packet rate (PR), the bit rate available for media payloads in RTP will be:
特定のパケットレート（PR）の場合、RTPのメディアペイロードで利用可能なビットレートは次のとおりです。
Max_net media_BR_A =
TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ... (1)
Max_net media_BR_B =
TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ... (2)
For a PR = 20, these calculations will yield a Max_net media_BR_A = 28600 bps and Max_net media_BR_B = 30400 bps, which suggests that receiver A is the limiting one for this packet rate. However, at a certain PR there is a switchover point at which receiver B becomes the limiting one. The switchover point can be identified by setting Max_media_BR_A equal to Max_media_BR_B and breaking out PR:
PR = 20の場合、これらの計算はMAX_NET MEDIA_BR_A = 28600 BPSおよびMAX_NET MEDIA_BR_B = 30400 BPSを生成します。これは、受信機Aがこのパケットレートの制限1であることを示唆しています。ただし、特定のPRには、レシーバーBが制限されたものになるスイッチオーバーポイントがあります。スイッチオーバーポイントは、max_media_br_aをmax_media_br_bに等しく設定し、PRを壊すことで識別できます。
TMMBR_max total BR_A - TMMBR_max total BR_B
PR = ------------------------------------------- ... (3)
8*(TMMBR_OH_A - TMMBR_OH_B)
which, for the numbers above, yields 31.25 as the switchover point between the two limits. That is, for packet rates below 31.25 per second, receiver A is the limiting receiver, and for higher packet rates, receiver B is more limiting. The implications of this behavior have to be considered by implementations that are going to control media encoding and its packetization. As exemplified above, multiple TMMBR limits may apply to the trade-off between net media bit rate and packet rate. Which limitation applies depends on the packet rate being considered.
上記の数字では、2つの制限間のスイッチオーバーポイントとして31.25が得られます。つまり、1秒あたり31.25未満のパケットレートの場合、レシーバーAは制限レシーバーであり、パケットレートが高い場合、レシーバーBはより制限的です。この動作の意味は、メディアのエンコードとそのパケット化を制御する実装によって考慮されなければなりません。上記で例示されているように、複数のTMMBR制限は、ネットメディアビットレートとパケットレートのトレードオフに適用される場合があります。適用される制限は、考慮されるパケットレートに依存します。
This also has implications for how the TMMBR mechanism needs to work. First, there is the possibility that multiple TMMBR tuples are providing limitations on the media sender. Secondly, there is a need for any session participant (media sender and receivers) to be able to determine if a given tuple will become a limitation upon the media sender, or if the set of already given limitations is stricter than the given values. In the absence of the ability to make this determination, the suppression of TMMBRs would not work.
これは、TMMBRメカニズムがどのように機能するかにも影響を与えます。第一に、複数のTMMBRタプルがメディア送信者に制限を提供している可能性があります。第二に、特定のタプルがメディア送信者の制限になるかどうか、または既に指定された制限のセットが指定された値よりも厳格であるかどうかを判断できるようにするために、セッション参加者（メディア送信者と受信機）が必要です。この決定を行う能力がない場合、TMMBRの抑制は機能しません。
The basic idea of the algorithm is as follows. Each TMMBR tuple can be viewed as the equation of a straight line (cf. equations (1) and (2)) in a space where packet rate lies along the X-axis and net bit rate along the Y-axis. The lower envelope of the set of lines corresponding to the complete set of TMMBR tuples, together with the X and Y axes, defines a polygon. Points lying within this polygon are combinations of packet rate and bit rate that meet all of the TMMBR constraints. The highest feasible packet rate within this region is the minimum of the rate at which the bounding polygon meets the X-axis or the session maximum packet rate (SMAXPR, measured in packets per second) provided by signaling, if any. Typically, a media sender will prefer to operate at a lower rate than this theoretical maximum, so as to increase the rate at which actual media content reaches the receivers. The purpose of the algorithm is to distinguish the TMMBR tuples constituting the bounding set and thus delineate the feasible region, so that the media sender can select its preferred operating point within that region
アルゴリズムの基本的なアイデアは次のとおりです。各TMMBRタプルは、パケットレートがY軸に沿ってX軸と正味ビットレートに沿ってある空間で、直線（方程式（1）および（2）を参照）の方程式として見ることができます。TMMBRタプルの完全なセットに対応する線のセットの下部エンベロープは、x軸とy軸とともにポリゴンを定義します。このポリゴン内にあるポイントは、すべてのTMMBR制約を満たすパケットレートとビットレートの組み合わせです。この領域内で最も高い実行可能なパケットレートは、境界ポリゴンがX軸またはセッションの最大パケットレート（SMAXPR、パケットで測定されたSMAXPR）を満たすレートの最小値です。通常、メディア送信者は、実際のメディアコンテンツが受信機に届く速度を上げるために、この理論的な最大よりも低いレートで動作することを好みます。アルゴリズムの目的は、境界セットを構成するTMMBRタプルを区別し、したがって、実行可能な領域を描写し、メディア送信者がその領域内でその優先動作点を選択できるようにすることです。
Figure 1 below shows a bounding polygon formed by TMMBR tuples A and B. A third tuple C lies outside the bounding polygon and is therefore irrelevant in determining feasible trade-offs between media rate and packet rate. The line labeled ss..s represents the limit on packet rate imposed by the session maximum packet rate (SMAXPR) obtained by signaling during session setup. In Figure 1, the limit determined by tuple B happens to be more restrictive than SMAXPR. The situation could easily be the reverse, meaning that the bounding polygon is terminated on the right by the vertical line representing the SMAXPR constraint.
以下の図1は、TMMBRタプルAとBによって形成された境界ポリゴンを示しています。3番目のタプルCは、境界ポリゴンの外側にあるため、メディアレートとパケットレートの間の実行可能なトレードオフを決定することとは無関係です。SS..Sというラベルのラベルは、セッションのセットアップ中にシグナリングによって取得されるセッション最大パケットレート（SMAXPR）によって課されるパケットレートの制限を表します。図1では、Tuple Bによって決定される制限は、たまたまSMAXPRよりも制限があります。状況は簡単に逆になる可能性があります。つまり、境界ポリゴンは、SMAXPRの制約を表す垂直線によって右側に終了します。
Net ^
Media|a c b s
Bit | a c b s
Rate | a c b s
| a cb s
| a c s
| a bc s
| a b c s
| ab c s
| Feasible b c s
| region ba s
| b a s c
| b s c
| b s a
| bs
+------------------------------>
Packet rate
パケットレート
Figure 1 - Geometric Interpretation of TMMBR Tuples
図1- TMMBRタプルの幾何学的解釈
Note that the slopes of the lines making up the bounding polygon are increasingly negative as one moves in the direction of increasing packet rate. Note also that with slight rearrangement, equations (1) and (2) have the canonical form:
境界ポリゴンを構成するラインの斜面は、パケットレートの増加の方向に移動するにつれてますます負になることに注意してください。また、わずかな再配置で、方程式（1）と（2）には標準的な形があることに注意してください。
y = mx + b
y = mx b
where m is the slope and has value equal to the negative of the tuple overhead (in bits), and b is the y-intercept and has value equal to the tuple maximum total media bit rate.
ここで、mは勾配であり、値をタプルオーバーヘッド（ビット）の負と等しく、bはy interceptであり、値がタプルの最大総メディアビットレートに等しい値を持っています。
These observations lead to the conclusion that when processing the TMMBR tuples to select the initial bounding set, one should sort and process the tuples by order of increasing overhead. Once a particular tuple has been added to the bounding set, all tuples not already selected and having lower overhead can be eliminated, because the next side of the bounding polygon has to be steeper (i.e., the corresponding TMMBR must have higher overhead) than the latest added tuple.
これらの観察結果は、TMMBRタプルを処理して初期境界セットを選択するとき、オーバーヘッドを増やす順序でタプルをソートして処理する必要があるという結論につながります。特定のタプルが境界セットに追加されると、すべてのタプルがまだ選択されておらず、オーバーヘッドが低いすべてのタプルを排除できます。最新の追加タプル。
Line cc..c in Figure 1 illustrates another principle. This line is parallel to line aa..a, but has a higher Y-intercept. That is, the corresponding TMMBR tuple contains a higher maximum total media bit rate value. Since line cc..c is outside the bounding polygon, it illustrates the conclusion that if two TMMBR tuples have the same overhead value, the one with higher maximum total media bit rate value cannot be part of the bounding set and can be set aside.
図1の行CC..Cは、別の原則を示しています。この行は、aa..aに平行ですが、y intecteが高くなります。つまり、対応するTMMBRタプルには、より高い最大総メディアビットレート値が含まれています。ラインCC..Cは境界ポリゴンの外側にあるため、2つのTMMBRタプルが同じオーバーヘッド値を持っている場合、最大総メディアビットレート値を持つものが境界セットの一部になり、脇に置くことができるという結論を示しています。
Two further observations complete the algorithm. Obviously, moving from the left, the successive corners of the bounding polygon (i.e., the intersection points between successive pairs of sides) lie at successively higher packet rates. On the other hand, again moving from the left, each successive line making up the bounding set crosses the X-axis at a lower packet rate.
さらに2つの観察結果がアルゴリズムを完成させます。明らかに、左から移動すると、境界ポリゴンの連続した角（つまり、連続した辺のペア間の交差点）は、連続的に高いパケットレートにあります。一方、左から再び移動すると、境界セットを構成する各連続したラインは、より低いパケットレートでX軸を横切ります。
The complete algorithm can now be specified. The algorithm works with two lists of TMMBR tuples, the candidate list X and the selected list Y, both ordered by increasing overhead value. The algorithm terminates when all members of X have been discarded or removed for processing. Membership of the selected list Y is probationary until the algorithm is complete. Each member of the selected list is associated with an intersection value, which is the packet rate at which the line corresponding to that TMMBR tuple intersects with the line corresponding to the previous TMMBR tuple in the selected list. Each member of the selected list is also associated with a maximum packet rate value, which is the lesser of the session maximum packet rate SMAXPR (if any) and the packet rate at which the line corresponding to that tuple crosses the X-axis.
完全なアルゴリズムを指定できるようになりました。アルゴリズムは、TMMBRタプルの2つのリスト、候補リストXと選択したリストYで動作します。どちらもオーバーヘッド値を増やすことで順序付けられます。アルゴリズムは、Xのすべてのメンバーが処理のために破棄または削除されたときに終了します。選択されたリストyのメンバーシップは、アルゴリズムが完了するまで保護観察です。選択したリストの各メンバーは、交差点値に関連付けられています。これは、そのtmmBRタプルに対応するラインが、選択したリストの前のTMMBRタプルに対応するラインと交差するパケットレートです。選択したリストの各メンバーは、セッションの最大パケットレートSMAXPR（もしあれば）の低い最大パケットレート値と、そのタプルに対応するラインがX軸を通過するパケットレートに関連付けられています。
When the algorithm terminates, the selected list is equal to the bounding set as defined in section 2.2.
アルゴリズムが終了すると、選択されたリストはセクション2.2で定義されているように境界セットに等しくなります。
Initial Algorithm
初期アルゴリズム
This algorithm is used by the media sender when it has received one or more TMMBRs and before it has determined a bounding set for the first time.
このアルゴリズムは、メディア送信者が1つ以上のTMMBRを受け取ったときに使用され、前に初めて境界セットを決定する前に使用されます。
1. Sort the TMMBR tuples by order of increasing overhead. This is the initial candidate list X.
1. オーバーヘッドを増やす順序でTMMBRタプルを並べ替えます。これが最初の候補リストxです。
2. When multiple tuples in the candidate list have the same overhead value, discard all but the one with the lowest maximum total media bit rate value.
2. 候補リストの複数のタプルが同じオーバーヘッド値を持っている場合、最大総メディアビットレート値を持つものを除くすべてを廃棄します。
3. Select and remove from the candidate list the TMMBR tuple with the lowest maximum total media bit rate value. If there is more than one tuple with that value, choose the one with the highest overhead value. This is the first member of the selected list Y. Set its intersection value equal to zero. Calculate its maximum packet rate as the minimum of SMAXPR (if available) and the value obtained from the following formula, which is the packet rate at which the corresponding line crosses the X-axis.
3. 候補から選択して削除し、最大の最大メディアビットレート値を持つTMMBRタプルをリストします。その値で複数のタプルがある場合は、最も高いオーバーヘッド値を持つものを選択します。これは、選択したリストYの最初のメンバーです。交差点をゼロに等しく設定します。最大パケットレートをSMAXPRの最小（利用可能な場合）と、次の式から得られた値を計算します。これは、対応するラインがX軸を通過するパケットレートです。
Max PR = TMMBR max total BR / (8 * TMMBR OH) ... (4)
4. Discard from the candidate list all tuples with a lower overhead value than the selected tuple.
4. 候補者リストからすべてのタプルを選択したタプルよりもオーバーヘッド値が低いすべてのタプルを廃棄します。
5. Remove the first remaining tuple from the candidate list for processing. Call this the current candidate.
5. 処理のために候補リストから最初の残りのタプルを削除します。これを現在の候補と呼びます。
6. Calculate the packet rate PR at the intersection of the line generated by the current candidate with the line generated by the last tuple in the selected list Y, using equation (3).
6. 式（3）を使用して、選択したリストYの最後のタプルによって生成された線で現在の候補によって生成された線の交差点でパケットレートPRを計算します。
7. If the calculated value PR is equal to or lower than the intersection value stored for the last tuple of the selected list, discard the last tuple of the selected list and go back to step 6 (retaining the same current candidate).
7. 計算された値PRが、選択したリストの最後のタプルに保存されている交差値以下の場合、選択したリストの最後のタプルを破棄し、ステップ6に戻ります（同じ現在の候補を保持します）。
Note that the choice of the initial member of the selected list Y in step 3 guarantees that the selected list will never be emptied by this process, meaning that the algorithm must eventually (if not immediately) fall through to step 8.
ステップ3の選択したリストYの初期メンバーの選択は、選択したリストがこのプロセスによって空にされることはないことを保証することに注意してください。つまり、アルゴリズムは最終的に（すぐにそうではない場合）ステップ8に落ちなければなりません。
8. (This step is reached when the calculated PR value of the current candidate is greater than the intersection value of the current last member of the selected list Y.) If the calculated value PR of the current candidate is lower than the maximum packet rate associated with the last tuple in the selected list, add the current candidate tuple to the end of the selected list. Store PR as its intersection value. Calculate its maximum packet rate as the lesser of SMAXPR (if available) and the maximum packet rate calculated using equation (4).
8. （現在の候補者の計算されたPR値が、選択したリストYの現在の最後のメンバーの交差値よりも大きい場合に到達します。）現在の候補の計算値PRが、関連する最大パケットレートよりも低い場合選択したリストの最後のタプルは、選択したリストの最後に現在の候補のタプルを追加します。交差点としてPRを保存します。最大パケットレートをSMAXPRの低い（利用可能な場合）と式（4）を使用して計算された最大パケットレートとして計算します。
9. If any tuples remain in the candidate list, go back to step 5.
9. タプルが候補リストに残っている場合は、ステップ5に戻ります。
Incremental Algorithm
増分アルゴリズム
The previous algorithm covered the initial case, where no selected list had previously been created. It also applied only to the media sender. When a previously created selected list is available at either the media sender or media receiver, two other cases can be considered:
以前のアルゴリズムは、選択されたリストが以前に作成されていなかった最初のケースをカバーしました。また、メディア送信者にのみ適用されました。以前に作成された選択したリストがメディア送信者またはメディアレシーバーのいずれかで利用可能である場合、他の2つのケースを考慮することができます。
o when a TMMBR tuple not currently in the selected list is a candidate for addition;
o 現在選択したリストにないTMMBRタプルが追加の候補である場合。
o when the values change in a TMMBR tuple currently in the selected list.
o 現在選択されているリストにあるTMMBRタプルの値が変化したとき。
At the media receiver, these cases correspond, respectively, to those of the non-owner and owner of a tuple in the TMMBN-reported bounding set.
メディアレシーバーでは、これらのケースは、それぞれTMMBNが報告した境界セットのタプルの所有者であり所有者であり、所有者のケースに対応しています。
In either case, the process of updating the selected list to take account of the new/changed tuple can use the basic algorithm described above, with the modification that the initial candidate set consists only of the existing selected list and the new or changed tuple. Some further optimization is possible (beyond starting with a reduced candidate set) by taking advantage of the following observations.
どちらの場合でも、選択したリストを更新して新しい/変更されたタプルを考慮して、上記の基本アルゴリズムを使用できます。最初の候補セットは、既存の選択リストと新規または変更されたタプルのみで構成されていることを変更します。以下の観察を活用することにより、いくつかのさらなる最適化が可能です（候補セットの削減から始めることはできません）。
The first observation is that if the new/changed candidate becomes part of the new selected list, the result may be to cause zero or more other tuples to be dropped from the list. However, if more than one other tuple is dropped, the dropped tuples will be consecutive. This can be confirmed geometrically by visualizing a new line that cuts off a series of segments from the previously existing bounding polygon. The cut-off segments are connected one to the next, the geometric equivalent of consecutive tuples in a list ordered by overhead value. Beyond the dropped set in either direction all of the tuples that were in the earlier selected list will be in the updated one. The second observation is that, leaving aside the new candidate, the order of tuples remaining in the updated selected list is unchanged because their overhead values have not changed.
最初の観察は、新しい/変更された候補者が新しい選択リストの一部になった場合、結果はゼロ以上のタプルをリストから削除することになる可能性があることです。ただし、他の複数のタプルがドロップされると、ドロップされたタプルが連続しています。これは、以前に既存の境界ポリゴンから一連のセグメントを遮断する新しいラインを視覚化することにより、幾何学的に確認できます。カットオフセグメントは次のものに接続されており、オーバーヘッド値で注文されたリストの連続したタプルに相当する幾何学的なタプルです。いずれかの方向にドロップされたセットを超えて、以前に選択されたリストにあったすべてのタプルが更新されたリストに含まれます。2番目の観察は、新しい候補者を除いて、更新された選択したリストに残っているタプルの順序が変更されていないため、変更されていないことです。
The consequence of these two observations is that, once the placement of the new candidate and the extent of the dropped set of tuples (if any) has been determined, the remaining tuples can be copied directly from the candidate list into the selected list, preserving their order. This conclusion suggests the following modified algorithm:
これら2つの観察の結果は、新しい候補者の配置と、ドロップされたタプルのセット（ある場合）の範囲が決定されると、残りのタプルを候補リストから選択したリストに直接コピーできることです。彼らの注文。この結論は、次の修正アルゴリズムを示唆しています。
o Run steps 1-4 of the basic algorithm.
o 基本アルゴリズムの手順1〜4を実行します。
o If the new candidate has survived steps 2 and 4 and has become the new first member of the selected list, run steps 5-9 on subsequent candidates until another candidate is added to the selected list. Then move all remaining candidates to the selected list, preserving their order.
o 新しい候補者が手順2と4を生き延び、選択したリストの新しい最初のメンバーになった場合、選択したリストに別の候補者が追加されるまで、後続の候補者の手順5-9を実行します。次に、残りのすべての候補者を選択したリストに移動し、注文を維持します。
o If the new candidate has survived steps 2 and 4 and has not become the new first member of the selected list, start by moving all tuples in the candidate list with lower overhead values than that of the new candidate to the selected list, preserving their order. Run steps 5-9 for the new candidate, with the modification that the intersection values and maximum packet rates for the tuples on the selected list have to be calculated on the fly because they were not previously stored. Continue processing only until a subsequent tuple has been added to the selected list, then move all remaining candidates to the selected list, preserving their order.
o 新しい候補者が手順2と4を生き延び、選択したリストの新しい最初のメンバーになっていない場合は、候補リスト内のすべてのタプルを選択したリストの新しい候補者よりも低いオーバーヘッド値で移動し、注文を維持することから始めます。。新しい候補者の手順5-9を実行します。選択したリストのタプルの交差値と最大パケットレートは、以前に保存されていなかったため、その場で計算する必要があります。後続のタプルが選択されたリストに追加されるまでのみ処理を続け、その後、残りのすべての候補者を選択したリストに移動し、注文を維持します。
Note that the new candidate could be added to the selected list only to be dropped again when the next tuple is processed. It can easily be seen that in this case the new candidate does not displace any of the earlier tuples in the selected list. The limitations of ASCII art make this difficult to show in a figure. Line cc..c in Figure 1 would be an example if it had a steeper slope (tuple C had a higher overhead value), but still intersected line aa..a beyond where line aa..a intersects line bb..b.
新しい候補者は、次のタプルが処理されたときに再びドロップするために、選択したリストにのみ追加できることに注意してください。この場合、新しい候補者は、選択したリストの以前のタプルを置き換えないことが簡単にわかります。ASCIIアートの限界により、これを図に表示するのが難しくなります。図1のラインCC..Cは、急勾配の勾配（タプルCのオーバーヘッド値が高い）がある場合の例ですが、それでも行われたラインaa..a .. a where rine aa..aが交差する行Bb..b。
The algorithm just described is approximate, because it does not take account of tuples outside the selected list. To see how such tuples can become relevant, consider Figure 1 and suppose that the maximum total media bit rate in tuple A increases to the point that line aa..a moves outside line cc..c. Tuple A will remain in the bounding set calculated by the media sender. However, once it issues a new TMMBN, media receiver C will apply the algorithm and discover that its tuple C should now enter the bounding set. It will issue a TMMBR to the media sender, which will repeat its calculation and come to the appropriate conclusion.
これまでに説明したアルゴリズムは、選択したリストの外側のタプルを考慮していないため、おおよそです。このようなタプルがどのように関連するかを確認するには、図1を考慮し、タプルAの最大総メディアビットレートが、ラインA.Aが外側のラインCC..Cを移動するポイントまで増加すると仮定します。Tuple Aは、メディア送信者によって計算された境界セットに残ります。ただし、新しいTMMBNを発行すると、メディアレシーバーCがアルゴリズムを適用し、タプルCが境界セットに入る必要があることを発見します。メディア送信者にTMMBRを発行し、計算を繰り返し、適切な結論に達します。
The rules of section 4.2 require that the media sender refrain from raising its sending rate until media receivers have had a chance to respond to the TMMBN. In the example just given, this delay ensures that the relaxation of tuple A does not actually result in an attempt to send media at a rate exceeding the capacity at C.
セクション4.2の規則では、メディアの送信者がメディアの受信者がTMMBNに対応する機会が得られるまで送信率の引き上げを控えることを要求しています。ちょうど与えられた例では、この遅延により、Tuple Aの緩和が実際にCの容量を超えるレートでメディアを送信しようとすることはできないことが保証されます。
Assume a small mixer-based multiparty conference is ongoing, as depicted in Topo-Mixer of [RFC5117]. All participants have negotiated a common maximum bit rate that this session can use. The conference operates over a number of unicast paths between the participants and the mixer. The congestion situation on each of these paths can be monitored by the participant in question and by the mixer, utilizing, for example, RTCP receiver reports (RRs) or the transport protocol, e.g., Datagram Congestion Control Protocol (DCCP) [RFC4340]. However, any given participant has no knowledge of the congestion situation of the connections to the other participants. Worse, without mechanisms similar to the ones discussed in this document, the mixer (which is aware of the congestion situation on all connections it manages) has no standardized means to inform media senders to slow down, short of forging its own receiver reports (which is undesirable). In principle, a mixer confronted with such a situation is obliged to thin or transcode streams intended for connections that detected congestion.
[RFC5117]のTopo-Mixerに示されているように、小さなミキサーベースのマルチパーティ会議が進行中であると仮定します。すべての参加者は、このセッションが使用できる共通の最大ビットレートを交渉しました。会議は、参加者とミキサーの間の多くのユニキャストパスで動作します。これらの各パスの輻輳状況は、問題の参加者と、たとえばRTCP受信者レポート（RRS）または輸送プロトコルなどを使用してミキサーによって監視できます。ただし、指定された参加者は、他の参加者とのつながりの混雑状況についての知識を持っていません。さらに悪いことに、このドキュメントで議論されているメカニズムと同様のメカニズムがなければ、ミキサー（これは、管理するすべての接続の混雑状況を認識しています）には、独自のレシーバーレポートを偽造する以外に、メディア送信者に減速するように通知する標準化された手段がありません。望ましくない）。原則として、このような状況に直面したミキサーは、混雑を検出した接続を目的とした薄いストリームまたはトランスコードストリームを義務付けられています。
In practice, unfortunately, media-aware streaming thinning is a very difficult and cumbersome operation and adds undesirable delay. If media-unaware, it leads very quickly to unacceptable reproduced media quality. Hence, a means to slow down senders even in the absence of congestion on their connections to the mixer is desirable.
実際には、残念ながら、メディアを認識しているストリーミング薄化は非常に困難で扱いにくい操作であり、望ましくない遅延を追加します。Media-Unawareの場合、それは非常に迅速に、容認できない複製されたメディアの品質につながります。したがって、ミキサーへの接続に混雑がない場合でも、送信者を遅くする手段が望ましいです。
To allow the mixer to throttle traffic on the individual links, without performing transcoding, there is a need for a mechanism that enables the mixer to ask a participant's media encoders to limit the media stream bit rate they are currently generating. TMMBR provides the required mechanism. When the mixer detects congestion between itself and a given participant, it executes the following procedure:
トランスコーディングを実行せずに、ミキサーが個々のリンクのトラフィックをスロットルできるようにするために、ミキサーが参加者のメディアエンコーダーに現在生成しているメディアストリームビットレートを制限するように依頼できるメカニズムが必要です。TMMBRは、必要なメカニズムを提供します。ミキサーがそれ自体と特定の参加者との間の輻輳を検出すると、次の手順を実行します。
1. It starts thinning the media traffic to the congested participant to the supported bit rate.
1. メディアのトラフィックを混雑した参加者へのサポートビットレートまで薄くし始めます。
2. It uses TMMBR to request the media sender(s) to reduce the total media bit rate sent by them to the mixer, to a value that is in compliance with congestion control principles for the slowest link. Slow refers here to the available bandwidth / bit rate / capacity and packet rate after congestion control.
2. TMMBRを使用して、メディアの送信者を要求して、ミキサーに送信されたメディアビットレートの合計ビットレートを低下させ、最も遅いリンクの輻輳制御原則に準拠した値になります。Slowは、ここでは、混雑制御後の利用可能な帯域幅 /ビットレート /容量とパケットレートを参照します。
3. As soon as the bit rate has been reduced by the sending part, the mixer stops stream thinning implicitly, because there is no need for it once the stream is in compliance with congestion control.
3. 送信部によってビットレートが低下するとすぐに、ミキサーは渋滞制御に準拠した後に必要がないため、ミキサーが暗黙的に薄くなることを停止します。
This use of stream thinning as an immediate reaction tool followed up by a quick control mechanism appears to be a reasonable compromise between media quality and the need to combat congestion.
迅速な制御メカニズムが続く即時反応ツールとしてのストリーム薄化のこの使用は、メディアの品質と混雑と戦う必要性の間の合理的な妥協のようです。
In these topologies, corresponding to Topo-Multicast or Topo-Translator, RTCP RRs are transmitted globally. This allows all participants to detect transmission problems such as congestion, on a medium timescale. As all media senders are aware of the congestion situation of all media receivers, the rationale for the use of TMMBR in the previous section does not apply. However, even in this case the congestion control response can be improved when the unicast links are using congestion controlled transport protocols (such as TCP or DCCP). A peer may also report local limitations to the media sender.
これらのトポロジーでは、Topo-MulticastまたはTopo-Translatorに対応して、RTCP RRSはグローバルに送信されます。これにより、すべての参加者が中程度のタイムスケールで、混雑などの伝送問題を検出できます。すべてのメディアの送信者は、すべてのメディアレシーバーの混雑状況を認識しているため、前のセクションでTMMBRを使用するための理論的根拠は適用されません。ただし、この場合でも、ユニキャストリンクが混雑制御輸送プロトコル（TCPやDCCPなど）を使用している場合、混雑制御応答を改善できます。ピアは、メディア送信者にローカルの制限を報告することもできます。
In use case 7, it is possible to use TMMBR to improve the performance when the known upper limit of the bit rate changes. In this use case, the signaling protocol has established an upper limit for the session and total media bit rates. However, at the time of transport link bit rate reduction, a receiver can avoid serious congestion by sending a TMMBR to the sending side. Thus, TMMBR is useful for putting restrictions on the application and thus placing the congestion control mechanism in the right ballpark. However, TMMBR is usually unable to provide the continuously quick feedback loop required for real congestion control. Nor do its semantics match those of congestion control given its different purpose. For these reasons, TMMBR SHALL NOT be used as a substitute for congestion control.
ユースケース7では、ビットレートの既知の上限が変更された場合、TMMBRを使用してパフォーマンスを改善することができます。このユースケースでは、シグナル伝達プロトコルは、セッションおよび総メディアビットレートの上限を確立しています。ただし、輸送リンクビットレートの削減の時点で、受信者はTMMBRを送信側に送信することにより、深刻な輻輳を回避できます。したがって、TMMBRは、アプリケーションに制限を掲載し、右の球場に混雑制御メカニズムを配置するのに役立ちます。ただし、TMMBRは通常、実際の輻輳制御に必要な連続的にクイックフィードバックループを提供することができません。また、そのセマンティクスは、異なる目的を考慮して、混雑制御のセマンティクスと一致しません。これらの理由により、TMMBRは混雑制御の代替として使用されてはなりません。
The reaction of a media sender to the reception of a TMMBR message is not immediately identifiable through inspection of the media stream. Therefore, a more explicit mechanism is needed to avoid unnecessary re-sending of TMMBR messages. Using a statistically based retransmission scheme would only provide statistical guarantees of the request being received. It would also not avoid the retransmission of already received messages. In addition, it would not allow for easy suppression of other participants' requests. For these reasons, a mechanism based on explicit notification is used.
TMMBRメッセージの受信に対するメディア送信者の反応は、メディアストリームの検査を通じてすぐに識別できません。したがって、TMMBRメッセージの不必要な再配置を避けるために、より明確なメカニズムが必要です。統計ベースの再送信スキームを使用すると、受信中の要求の統計的保証のみが提供されます。また、すでに受信したメッセージの再送信を避けません。さらに、他の参加者の要求を容易に抑制することはできません。これらの理由により、明示的な通知に基づくメカニズムが使用されます。
Upon the reception of a TMMBR, a media sender sends a TMMBN containing the current bounding set, and indicating which session participants own that limit. In multicast scenarios, that allows all other participants to suppress any request they may have, if their limitations are less strict than the current ones (i.e., define lines lying outside the feasible region as defined in section 2.2). Keeping and notifying only the bounding set of tuples allows for small message sizes and media sender states. A media sender only keeps state for the SSRCs of the current owners of the bounding set of tuples; all other requests and their sources are not saved. Once the bounding set has been established, new TMMBR messages should be generated only by owners of the bounding tuples and by other entities that determine (by applying the algorithm of section 3.5.4.2 or its equivalent) that their limitations should now be part of the bounding set.
TMMBRを受信すると、メディア送信者は現在の境界セットを含むTMMBNを送信し、参加者がその制限を所有しているセッションを示します。マルチキャストシナリオでは、他のすべての参加者が、現在の参加者よりも厳格でない場合（つまり、セクション2.2で定義されているように、実行可能な領域の外側にある行を定義します）。タプルの境界セットのみを維持および通知することで、小さなメッセージサイズとメディア送信者の状態が可能になります。メディア送信者は、タプルの境界セットの現在の所有者のSSRCのみを維持します。他のすべてのリクエストとそのソースは保存されません。境界セットが確立されると、新しいTMMBRメッセージは、境界タプルの所有者と（セクション3.5.4.2のアルゴリズムを適用することにより）他のエンティティによってのみ生成される必要があります。境界セット。
This memo specifies six new feedback messages. The Full Intra Request (FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal-Spatial Trade-off Notification (TSTN), and Video Back Channel Message (VBCM) are "Payload Specific Feedback Messages" as defined in section 6.3 of AVPF [RFC4585]. The Temporary Maximum Media Stream Bit Rate Request (TMMBR) and Temporary Maximum Media Stream Bit Rate Notification (TMMBN) are "Transport Layer Feedback Messages" as defined in section 6.2 of AVPF.
このメモは、6つの新しいフィードバックメッセージを指定します。完全なリクエスト（FIR）、時間空間トレードオフリクエスト（TSTR）、時間空間トレードオフ通知（TSTN）、およびビデオバックチャネルメッセージ（VBCM）は、セクション6.3で定義されている「ペイロード固有のフィードバックメッセージ」です。AVPF [RFC4585]の。一時的な最大メディアストリームビットレートリクエスト（TMMBR）および一時的な最大メディアストリームビットレート通知（TMMBN）は、AVPFのセクション6.2で定義されている「輸送層フィードバックメッセージ」です。
The new feedback messages are defined in the following subsections, following a similar structure to that in sections 6.2 and 6.3 of the AVPF specification [RFC4585].
新しいフィードバックメッセージは、AVPF仕様[RFC4585]のセクション6.2および6.3の構造と同様の構造に従って、次のサブセクションで定義されています。
RTCP was originally introduced as a channel to convey presence, reception quality statistics and hints on the desired media coding. A limited set of media control mechanisms was introduced in early RTP payload formats for video formats, for example, in RFC 2032 [RFC2032] (which was obsoleted by RFC 4587 [RFC4587]). However, this specification, for the first time, suggests a two-way handshake for some of its messages. There is danger that this introduction could be misunderstood as a precedent for the use of RTCP as an RTP session control protocol. To prevent such a misunderstanding, this subsection attempts to clarify the scope of the extensions specified in this memo, and it strongly suggests that future extensions follow the rationale spelled out here, or compellingly explain why they divert from the rationale.
RTCPはもともと、存在感、受信品質の統計、および目的のメディアコーディングに関するヒントを伝えるチャネルとして導入されました。たとえば、RFC 2032 [RFC2032]（RFC 4587 [RFC4587]）で、ビデオ形式の初期RTPペイロード形式で限られたメディア制御メカニズムが導入されました。ただし、この仕様は、初めて、そのメッセージの一部の双方向の握手を示唆しています。この導入は、RTPセッションコントロールプロトコルとしてRTCPを使用する前例として誤解される可能性があるという危険があります。このような誤解を防ぐために、このサブセクションは、このメモで指定された拡張機能の範囲を明確にしようとします。これは、将来の拡張がここで綴られた理論的根拠に従うこと、または彼らが理論的根拠から迂回する理由を説得力を持って説明することを強く示唆しています。
In this memo, and in AVPF [RFC4585], only such messages have been included as:
このメモ、およびAVPF [RFC4585]では、次のようなメッセージのみが含まれています。
a) have comparatively strict real-time constraints, which prevent the use of mechanisms such as a SIP re-invite in most application scenarios (the real-time constraints are explained separately for each message where necessary);
a) 比較的厳格なリアルタイム制約があり、ほとんどのアプリケーションシナリオでのSIPリンバイトなどのメカニズムの使用を妨げます（リアルタイムの制約は、必要に応じて各メッセージに対して個別に説明されます）。
b) are multicast-safe in that the reaction to potentially contradicting feedback messages is specified, as necessary for each message; and
b) 潜在的に矛盾するフィードバックメッセージに対する反応が指定されているという点で、各メッセージに必要に応じて、マルチキャストセーフです。と
c) are directly related to activities of a certain media codec, class of media codecs (e.g., video codecs), or a given RTP packet stream.
c) 特定のメディアコーデック、メディアコーデックのクラス（ビデオコーデックなど）、または特定のRTPパケットストリームのアクティビティに直接関連しています。
In this memo, a two-way handshake is introduced only for messages for which:
このメモでは、双方向の握手がメッセージに対してのみ導入されます。
a) a notification or acknowledgement is required due to their nature. An analysis to determine whether this requirement exists has been performed separately for each message.
a) その性質のために通知または謝辞が必要です。この要件が存在するかどうかを判断するための分析は、各メッセージに対して個別に実行されています。
b) the notification or acknowledgement cannot be easily derived from the media bit stream.
b) 通知または承認は、メディアビットストリームから簡単に導き出すことはできません。
All messages in AVPF [RFC4585] and in this memo present their contents in a simple, fixed binary format. This accommodates media receivers that have not implemented higher control protocol functionalities (SDP, XML parsers, and such) in their media path.
AVPF [RFC4585]およびこのメモのすべてのメッセージは、その内容を単純な固定バイナリ形式で示しています。これにより、メディアパスに高等制御プロトコル機能（SDP、XMLパーサーなど）を実装していないメディアレシーバーに対応します。
Messages that do not conform to the design principles just described are not an appropriate use of RTCP or of the Codec Control Framework defined in this document.
これまでに説明した設計原則に準拠していないメッセージは、RTCPまたはこのドキュメントで定義されているコーデック制御フレームワークの適切な使用ではありません。
As specified in section 6.1 of RFC 4585 [RFC4585], transport layer feedback messages are identified by the RTCP packet type value RTPFB (205).
RFC 4585 [RFC4585]のセクション6.1で指定されているように、輸送層のフィードバックメッセージは、RTCPパケットタイプ値RTPFB（205）によって識別されます。
In AVPF, one message of this category had been defined. This memo specifies two more such messages. They are identified by means of the feedback message type (FMT) parameter as follows:
AVPFでは、このカテゴリの1つのメッセージが定義されていました。このメモは、さらに2つのこのようなメッセージを指定します。次のように、フィードバックメッセージタイプ（FMT）パラメーターによって識別されます。
Assigned in AVPF [RFC4585]:
AVPF [RFC4585]に割り当てられています：
1: Generic NACK 31: reserved for future expansion of the identifier number space
1：ジェネリックナック31：識別子番号スペースの将来の拡張のために予約されています
Assigned in this memo:
このメモに割り当てられています：
2: reserved (see note below) 3: Temporary Maximum Media Stream Bit Rate Request (TMMBR) 4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN)
2：予約済み（以下を参照）
Note: early versions of AVPF [RFC4585] reserved FMT=2 for a code point that has later been removed. It has been pointed out that there may be implementations in the field using this value in accordance with the expired document. As there is sufficient numbering space available, we mark FMT=2 as reserved so to avoid possible interoperability problems with any such early implementations.
注：AVPF [RFC4585]の初期バージョンは、後で削除されたコードポイントについてFMT = 2を予約しました。期限切れのドキュメントに従って、この値を使用してフィールドに実装がある可能性があることが指摘されています。十分な番号付けスペースが利用可能であるため、FMT = 2は予約されているとマークし、そのような早期の実装で可能な相互運用性の問題を回避します。
Available for assignment:
割り当てに利用可能：
0: unassigned 5-30: unassigned
0：未割り当て5-30：割り当てられていない
The following subsection defines the formats of the Feedback Control Information (FCI) entries for the TMMBR and TMMBN messages, respectively, and specifies the associated behaviour at the media sender and receiver.
次のサブセクションでは、TMMBRおよびTMMBNメッセージのフィードバック制御情報（FCI）エントリの形式をそれぞれ定義し、メディア送信者と受信機で関連する動作を指定します。
The Temporary Maximum Media Stream Bit Rate Request is identified by RTCP packet type value PT=RTPFB and FMT=3.
一時的な最大メディアストリームビットレートリクエストは、RTCPパケットタイプ値PT = RTPFBおよびFMT = 3によって識別されます。
The FCI field of a Temporary Maximum Media Stream Bit Rate Request (TMMBR) message SHALL contain one or more FCI entries.
一時的な最大メディアストリームビットレートリクエスト（TMMBR）メッセージのFCIフィールドには、1つ以上のFCIエントリが含まれている必要があります。
The Feedback Control Information (FCI) consists of one or more TMMBR FCI entries with the following syntax:
フィードバック制御情報（FCI）は、次の構文を使用した1つ以上のTMMBR FCIエントリで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Syntax of an FCI Entry in the TMMBR Message
図2- TMMBRメッセージのFCIエントリの構文
SSRC (32 bits): The SSRC value of the media sender that is requested to obey the new maximum bit rate.
SSRC（32ビット）：新しい最大ビットレートに従うように要求されるメディア送信者のSSRC値。
MxTBR Exp (6 bits): The exponential scaling of the mantissa for the maximum total media bit rate value. The value is an unsigned integer [0..63].
MXTBR Exp（6ビット）：最大総メディアビットレート値のためのマンティッサの指数スケーリング。値は署名されていない整数です[0..63]。
MxTBR Mantissa (17 bits): The mantissa of the maximum total media bit rate value as an unsigned integer.
Mxtbr Mantissa（17ビット）：署名されていない整数としての最大総メディアビットレート値のマンティッサ。
Measured Overhead (9 bits): The measured average packet overhead value in bytes. The measurement SHALL be done according to the description in section 4.2.1.2. The value is an unsigned integer [0..511].
測定されたオーバーヘッド（9ビット）：バイトの測定された平均パケットオーバーヘッド値。測定は、セクション4.2.1.2の説明に従って行うものとします。値は署名されていない整数です[0..511]。
The maximum total media bit rate (MxTBR) value in bits per second is calculated from the MxTBR exponent (exp) and mantissa in the following way:
1秒あたりビットの最大総メディアビットレート（MXTBR）値は、MXTBRエクスペンテント（EXP）とMantissaから次の方法で計算されます。
MxTBR = mantissa * 2^exp
This allows for 17 bits of resolution in the range 0 to 131072*2^63 (approximately 1.2*10^24).
これにより、0〜131072*2^63（約1.2*10^24）の範囲で17ビットの解像度が可能になります。
The length of the TMMBR feedback message SHALL be set to 2+2*N where N is the number of TMMBR FCI entries.
TMMBRフィードバックメッセージの長さは、2 2*nに設定する必要があります。ここで、NはTMMBR FCIエントリの数です。
Behaviour at the Media Receiver (Sender of the TMMBR)
メディアレシーバーでの動作（TMMBRの送信者）
TMMBR is used to indicate a transport-related limitation at the reporting entity acting as a media receiver. TMMBR has the form of a tuple containing two components. The first value is the highest bit rate per sender of a media stream, available at a receiver-chosen protocol layer, which the receiver currently supports in this RTP session. The second value is the measured header overhead in bytes as defined in section 2.2 and measured at the chosen protocol layer in the packets received for the stream. The measurement of the overhead is a running average that is updated for each packet received for this particular media source (SSRC), using the following formula:
TMMBRは、メディアレシーバーとして機能するレポートエンティティの輸送関連の制限を示すために使用されます。TMMBRには、2つのコンポーネントを含むタプルの形があります。最初の値は、メディアストリームの送信者ごとの最高ビットレートであり、受信者が選択したプロトコルレイヤーで利用できます。このRTPセッションでは、受信者が現在サポートしています。2番目の値は、セクション2.2で定義されており、ストリーム用に受信したパケットの選択されたプロトコル層で測定されたバイトの測定ヘッダーオーバーヘッドです。オーバーヘッドの測定は、次の式を使用して、この特定のメディアソース（SSRC）で受信した各パケットに対して更新される実行平均です。
avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH,
avg_oh（new）= 15/16*avg_oh（old）1/16*pckt_oh、
where avg_OH is the running (exponentially smoothed) average and pckt_OH is the overhead observed in the latest packet.
ここで、AVG_OHは実行中の（指数関数的にスムーズになった）平均であり、PCKT_OHは最新のパケットで観察されるオーバーヘッドです。
If a maximum bit rate has been negotiated through signaling, the maximum total media bit rate that the receiver reports in a TMMBR message MUST NOT exceed the negotiated value converted to a common basis (i.e., with overheads adjusted to bring it to the same reference protocol layer).
シグナリングを通じて最大ビットレートが交渉されている場合、TMMBRメッセージ内の受信機がレポートする最大総メディアビットレートは、共通ベースに変換された交渉値を超えてはなりません（つまり、オーバーヘッドを調整して同じ参照プロトコルに持ち込むように調整されています層）。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. Within a particular TMMBR FCI entry, the "SSRC of media source" in the FCI field denotes the media sender that the tuple applies to. This is useful in the multicast or translator topologies where the reporting entity may address all of the media senders in a single TMMBR message using multiple FCI entries.
フィードバックメッセージの一般的なパケットヘッダー内（[RFC4585]のセクション6.1で定義されているように）内で、「パケット送信者のSSRC」フィールドはリクエストのソースを示し、「メディアソースのSSRC」は使用されず、設定されます0に0.特定のTMMBR FCIエントリ内で、FCIフィールドの「メディアソースのSSRC」は、タプルが適用するメディア送信者を示します。これは、複数のFCIエントリを使用して1つのTMMBRメッセージでレポートエンティティがすべてのメディア送信者に対処できるマルチキャストまたは翻訳者トポロジに役立ちます。
The media receiver SHALL save the contents of the latest TMMBN message received from each media sender.
メディアレシーバーは、各メディア送信者から受信した最新のTMMBNメッセージの内容を保存するものとします。
The media receiver MAY send a TMMBR FCI entry to a particular media sender under the following circumstances:
メディアレシーバーは、次の状況では、特定のメディア送信者にTMMBR FCIエントリを送信できます。
o before any TMMBN message has been received from that media sender;
o そのメディア送信者からTMMBNメッセージが受信される前に。
o when the media receiver has been identified as the source of a bounding tuple within the latest TMMBN message received from that media sender, and the value of the maximum total media bit rate or the overhead relating to that media sender has changed;
o メディアレシーバーが、そのメディア送信者から受け取った最新のTMMBNメッセージ内の境界タプルのソースとして識別された場合、およびメディア送信者に関連する最大総メディアビットレートまたはそのオーバーヘッドの価値が変更されました。
o when the media receiver has not been identified as the source of a bounding tuple within the latest TMMBN message received from that media sender, and, after the media receiver applies the incremental algorithm from section 3.5.4.2 or a stricter equivalent, the media receiver's tuple relating to that media sender is determined to belong to the bounding set.
o メディアレシーバーがそのメディア送信者から受信した最新のTMMBNメッセージ内の境界タプルのソースとして識別されていない場合、メディアレシーバーがセクション3.5.4.2またはより厳格なアルゴリズムを適用した後、メディアレシーバーのタプルそのメディア送信者に関連するものは、境界セットに属すると判断されます。
A TMMBR FCI entry MAY be repeated in subsequent TMMBR messages if no Temporary Maximum Media Stream Bit Rate Notification (TMMBN) FCI has been received from the media sender at the time of transmission of the next RTCP packet. The bit rate value of a TMMBR FCI entry MAY be changed from one TMMBR message to the next. The overhead measurement SHALL be updated to the current value of avg_OH each time the entry is sent.
次のRTCPパケットの送信時に、一時的な最大メディアストリームビットレート通知（TMMBN）FCIがメディア送信者から受信されていない場合、TMMBR FCIエントリを後続のTMMBRメッセージで繰り返すことができます。TMMBR FCIエントリのビットレート値は、1つのTMMBRメッセージから次のTMMBRメッセージに変更できます。オーバーヘッド測定は、エントリが送信されるたびにAVG_OHの現在の値に更新するものとします。
If the value set by a TMMBR message is expected to be permanent, the TMMBR setting party SHOULD renegotiate the session parameters to reflect that using session setup signaling, e.g., a SIP re-invite.
TMMBRメッセージによって設定された値が永続的であると予想される場合、TMMBR設定パーティはセッションパラメーターを再交渉して、セッションセットアップシグナリング、たとえばSIP Re Inviteを使用して反映する必要があります。
Behaviour at the Media Sender (Receiver of the TMMBR)
メディア送信者での動作（TMMBRの受信者）
When it receives a TMMBR message containing an FCI entry relating to it, the media sender SHALL use an initial or incremental algorithm as applicable to determine the bounding set of tuples based on the new information. The algorithm used SHALL be at least as strict as the corresponding algorithm defined in section 3.5.4.2. The media sender MAY accumulate TMMBRs over a small interval (relative to the RTCP sending interval) before making this calculation.
それに関連するFCIエントリを含むTMMBRメッセージを受信した場合、メディア送信者は、新しい情報に基づいてタプルの境界セットを決定するために、該当する初期または増分アルゴリズムを使用するものとします。使用されるアルゴリズムは、少なくともセクション3.5.4.2で定義されている対応するアルゴリズムと同じくらい厳格でなければなりません。メディア送信者は、この計算を行う前に（RTCP送信間隔と比較して）わずかな間隔でTMMBRを蓄積する場合があります。
Once it has determined the bounding set of tuples, the media sender MAY use any combination of packet rate and net media bit rate within the feasible region that these tuples describe to produce a lower total media stream bit rate, as it may need to address a congestion situation or other limiting factors. See section 5 (congestion control) for more discussion.
タプルの境界セットを決定すると、メディア送信者は、これらのタプルが、より低いメディアストリームビットレートを生成するために説明する実行可能な領域内のパケットレートとネットメディアビットレートの任意の組み合わせを使用する場合があります。混雑の状況またはその他の制限要因。詳細については、セクション5（混雑制御）を参照してください。
If the media sender concludes that it can increase the maximum total media bit rate value, it SHALL wait before actually doing so, for a period long enough to allow a media receiver to respond to the TMMBN if it determines that its tuple belongs in the bounding set. This delay period is estimated by the formula:
メディアの送信者が、メディアビットレートの最大値を上げることができると結論付けた場合、メディアの受信者がタプルが境界に属していると判断した場合、メディアの受信者がTMMBNに応答できるようにするのに十分な期間、実際にそうするまで待ちます設定。この遅延期間は、式によって推定されます。
2 * RTT + T_Dither_Max,
2 * rtt t_dither_max、
where RTT is the longest round trip time known to the media sender and T_Dither_Max is defined in section 3.4 of [RFC4585]. Even in point-to-point sessions, a media sender MUST obey the aforementioned rule, as it is not guaranteed that a participant is able to determine correctly whether all the sources are co-located in a single node, and are coordinated.
ここで、RTTはメディア送信者に知られている最長の往復時間であり、T_Dither_Maxは[RFC4585]のセクション3.4で定義されています。ポイントツーポイントセッションでさえ、メディア送信者は、参加者がすべてのソースが単一のノードで共同住宅され、調整されているかどうかを正しく決定できることを保証されていないため、前述のルールに従わなければなりません。
A TMMBN message SHALL be sent by the media sender at the earliest possible point in time, in response to any TMMBR messages received since the last sending of TMMBN. The TMMBN message indicates the calculated set of bounding tuples and the owners of those tuples at the time of the transmission of the message.
TMMBNメッセージは、TMMBNの最後の送信以降に受信されたTMMBRメッセージに応じて、可能な限り早い時期にメディア送信者によって送信されるものとします。TMMBNメッセージは、メッセージの送信時に境界タプルの計算セットとそれらのタプルの所有者を示します。
An SSRC may time out according to the default rules for RTP session participants, i.e., the media sender has not received any RTP or RTCP packets from the owner for the last five regular reporting intervals. An SSRC may also explicitly leave the session, with the participant indicating this through the transmission of an RTCP BYE packet or using an external signaling channel. If the media sender determines that the owner of a tuple in the bounding set has left the session, the media sender SHALL transmit a new TMMBN containing the previously determined set of bounding tuples but with the tuple belonging to the departed owner removed.
SSRCは、RTPセッションの参加者のデフォルトルールに従ってタイムアウトする場合があります。つまり、メディア送信者は、最後の5つの通常のレポート間隔で所有者からRTPまたはRTCPパケットを受け取っていません。SSRCは、RTCP Byeパケットの送信または外部シグナル伝達チャネルを使用してこれを示すため、SSRCがセッションを明示的に離れることもできます。メディアの送信者が、境界セットのタプルの所有者がセッションを去ったと判断した場合、メディア送信者は、以前に決定された境界タプルのセットを含むが、タプルが出発した所有者に属するタプルを除去した新しいTMMBNを送信するものとします。
A media sender MAY proactively initiate the equivalent to a TMMBR message to itself, when it is aware that its transmission path is more restrictive than the current limitations. As a result, a TMMBN indicating the media source itself as the owner of a tuple is being sent, thereby avoiding unnecessary TMMBR messages from other participants. However, like any other participant, when the media sender becomes aware of changed limitations, it is required to change the tuple, and to send a corresponding TMMBN.
メディア送信者は、その送信パスが現在の制限よりも制限的であることを認識している場合、TMMBRメッセージに相当するものを積極的に開始する場合があります。その結果、メディアソース自体がタプルの所有者であることを示すTMMBNが送信されているため、他の参加者からの不要なTMMBRメッセージを回避します。ただし、他の参加者と同様に、メディアの送信者が変更された制限に気付くと、タプルを変更し、対応するTMMBNを送信する必要があります。
Discussion
考察
Due to the unreliable nature of transport of TMMBR and TMMBN, the above rules may lead to the sending of TMMBR messages that appear to disobey those rules. Furthermore, in multicast scenarios it can happen that more than one "non-owning" session participant may determine, rightly or wrongly, that its tuple belongs in the bounding set. This is not critical for a number of reasons:
TMMBRおよびTMMBNの輸送の信頼性が低い性質により、上記のルールは、これらのルールに依存するように見えるTMMBRメッセージの送信につながる可能性があります。さらに、マルチキャストのシナリオでは、複数の「所有」セッションの参加者が、そのタプルが境界セットに属していることを正または誤って決定することができることが起こります。これはいくつかの理由で重要ではありません：
a) If a TMMBR message is lost in transmission, either the media sender sends a new TMMBN message in response to some other media receiver or it does not send a new TMMBN message at all. In the first case, the media receiver applies the incremental algorithm and, if it determines that its tuple should be part of the bounding set, sends out another TMMBR. In the second case, it repeats the sending of a TMMBR unconditionally. Either way, the media sender eventually gets the information it needs.
a) TMMBRメッセージが送信で失われた場合、メディア送信者が他のメディアレシーバーに応じて新しいTMMBNメッセージを送信するか、新しいTMMBNメッセージをまったく送信しません。最初のケースでは、メディアレシーバーがインクリメンタルアルゴリズムを適用し、タプルが境界セットの一部であると判断した場合、別のTMMBRを送信します。2番目のケースでは、無条件にTMMBRの送信を繰り返します。いずれにせよ、メディア送信者は最終的に必要な情報を取得します。
b) Similarly, if a TMMBN message gets lost, the media receiver that has sent the corresponding TMMBR does not receive the notification and is expected to re-send the request and trigger the transmission of another TMMBN.
b) 同様に、TMMBNメッセージが紛失した場合、対応するTMMBRを送信したメディアレシーバーは通知を受信せず、リクエストを再検討し、別のTMMBNの送信をトリガーすることが期待されます。
c) If multiple competing TMMBR messages are sent by different session participants, then the algorithm can be applied taking all of these messages into account, and the resulting TMMBN provides the participants with an updated view of how their tuples compare with the bounded set.
c) 複数の競合するTMMBRメッセージが異なるセッション参加者によって送信される場合、これらのすべてのメッセージを考慮に入れてアルゴリズムを適用でき、結果のTMMBNは参加者に、タプルが境界セットと比較される方法の更新ビューを提供します。
d) If more than one session participant happens to send TMMBR messages at the same time and with the same tuple component values, it does not matter which of those tuples is taken into the bounding set. The losing session participant will determine, after applying the algorithm, that its tuple does not enter the bounding set, and will therefore stop sending its TMMBR.
d) 複数のセッションの参加者がたまたまTMMBRメッセージを同時に送信し、同じタプルコンポーネント値で送信した場合、それらのタプルのどれが境界セットに移動するかは関係ありません。負けセッションの参加者は、アルゴリズムを適用した後、そのタプルが境界セットに入ることがないため、TMMBRの送信を停止することを決定します。
It is important to consider the security risks involved with faked TMMBRs. See the security considerations in section 6.
偽造されたTMMBRに関係するセキュリティリスクを考慮することが重要です。セクション6のセキュリティ上の考慮事項を参照してください。
As indicated already, the feedback messages may be used in both multicast and unicast sessions in any of the specified topologies. However, for sessions with a large number of participants, using the lowest common denominator, as required by this mechanism, may not be the most suitable course of action. Large sessions may need to consider other ways to adapt the bit rate to participants' capabilities, such as partitioning the session into different quality tiers or using some other method of achieving bit rate scalability.
すでに示されているように、フィードバックメッセージは、指定されたトポロジのいずれかのマルチキャストセッションとユニキャストセッションの両方で使用できます。ただし、このメカニズムで要求される最も低い一般的な分母を使用する多数の参加者とのセッションの場合、最も適切な行動方針ではない場合があります。大規模なセッションでは、セッションを異なる品質層に分割する、ビットレートのスケーラビリティを達成する他の方法を使用するなど、参加者の機能にビットレートを適応させる他の方法を検討する必要がある場合があります。
The first transmission of the TMMBR message MAY use early or immediate feedback in cases when timeliness is desirable. Any repetition of a request message SHOULD use regular RTCP mode for its transmission timing.
TMMBRメッセージの最初の送信は、適時性が望ましい場合に早期または即時のフィードバックを使用する場合があります。リクエストメッセージの繰り返しは、送信タイミングに通常のRTCPモードを使用する必要があります。
Media translators and mixers will need to receive and respond to TMMBR messages as they are part of the chain that provides a certain media stream to the receiver. The mixer or translator may act locally on the TMMBR and thus generate a TMMBN to indicate that it has done so. Alternatively, in the case of a media translator it can forward the request, or in the case of a mixer generate one of its own and pass it forward. In the latter case, the mixer will need to send a TMMBN back to the original requestor to indicate that it is handling the request.
The Temporary Maximum Media Stream Bit Rate Notification is identified by RTCP packet type value PT=RTPFB and FMT=4.
一時的な最大メディアストリームビットレート通知は、RTCPパケットタイプ値PT = RTPFBおよびFMT = 4によって識別されます。
The FCI field of the TMMBN feedback message may contain zero, one, or more TMMBN FCI entries.
TMMBNフィードバックメッセージのFCIフィールドには、ゼロ、1つ、またはそれ以上のTMMBN FCIエントリが含まれる場合があります。
The Feedback Control Information (FCI) consists of zero, one, or more TMMBN FCI entries with the following syntax:
フィードバック制御情報（FCI）は、次の構文を備えたゼロ、1つ、またはそれ以上のTMMBN FCIエントリで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp | MxTBR Mantissa |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Syntax of an FCI Entry in the TMMBN Message
図3- TMMBNメッセージのFCIエントリの構文
SSRC (32 bits): The SSRC value of the "owner" of this tuple.
SSRC（32ビット）：このタプルの「所有者」のSSRC値。
MxTBR Exp (6 bits): The exponential scaling of the mantissa for the maximum total media bit rate value. The value is an unsigned integer [0..63].
MXTBR Exp（6ビット）：最大総メディアビットレート値のためのマンティッサの指数スケーリング。値は署名されていない整数です[0..63]。
MxTBR Mantissa (17 bits): The mantissa of the maximum total media bit rate value as an unsigned integer.
Mxtbr Mantissa（17ビット）：署名されていない整数としての最大総メディアビットレート値のマンティッサ。
Measured Overhead (9 bits): The measured average packet overhead value in bytes represented as an unsigned integer [0..511].
測定されたオーバーヘッド（9ビット）：署名されていない整数[0..511]として表されるバイトの測定された平均パケットオーバーヘッド値。
Thus, the FCI within the TMMBN message contains entries indicating the bounding tuples. For each tuple, the entry gives the owner by the SSRC, followed by the applicable maximum total media bit rate and overhead value.
したがって、TMMBNメッセージ内のFCIには、境界タプルを示すエントリが含まれています。タプルごとに、エントリはSSRCによって所有者に与えられ、その後に該当する最大メディアビットレートとオーバーヘッド値が続きます。
The length of the TMMBN message SHALL be set to 2+2*N where N is the number of TMMBN FCI entries.
TMMBNメッセージの長さは2 2*nに設定する必要があります。ここで、nはTMMBN FCIエントリの数です。
This feedback message is used to notify the senders of any TMMBR message that one or more TMMBR messages have been received or that an owner has left the session. It indicates to all participants the current set of bounding tuples and the "owners" of those tuples.
このフィードバックメッセージは、1つまたは複数のTMMBRメッセージが受信されたこと、または所有者がセッションを去ったことを送信者に通知するために使用されます。これは、すべての参加者に、現在の境界タプルのセットとそれらのタプルの「所有者」を示しています。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the notification. The "SSRC of media source" is not used and SHALL be set to 0.
フィードバックメッセージの一般的なパケットヘッダー（[RFC4585]のセクション6.1で定義されているように）内で、「パケット送信者のSSRC」フィールドは通知のソースを示します。「メディアソースのSSRC」は使用されず、0に設定されます。
A TMMBN message SHALL be scheduled for transmission after the reception of a TMMBR message with an FCI entry identifying this media sender. Only a single TMMBN SHALL be sent, even if more than one TMMBR message is received between the scheduling of the transmission and the actual transmission of the TMMBN message. The TMMBN message indicates the bounding tuples and their owners at the time of transmitting the message. The bounding tuples included SHALL be the set arrived at through application of the applicable algorithm of section 3.5.4.2 or an equivalent, applied to the previous bounding set, if any, and tuples received in TMMBR messages since the last TMMBN was transmitted.
TMMBNメッセージは、このメディア送信者を識別するFCIエントリを備えたTMMBRメッセージを受信した後、送信が予定されているものとします。送信のスケジューリングとTMMBNメッセージの実際の送信の間に複数のTMMBRメッセージが受信された場合でも、単一のTMMBNのみが送信されます。TMMBNメッセージは、メッセージの送信時の境界タプルとその所有者を示します。含まれる境界タプルは、セクション3.5.4.2の該当するアルゴリズムの適用を通じて到達したセットまたは同等のアルゴリズム、以前の境界セット（ある場合）に適用され、最後のTMMBNが送信されてからTMMBRメッセージで受信されたタプルが適用されます。
The reception of a TMMBR message SHALL still result in the transmission of a TMMBN message even if, after application of the algorithm, the newly reported TMMBR tuple is not accepted into the bounding set. In such a case, the bounding tuples and their owners are not changed, unless the TMMBR was from an owner of a tuple within the previously calculated bounding set. This procedure allows session participants that did not see the last TMMBN message to get a correct view of this media sender's state.
TMMBRメッセージの受信は、アルゴリズムの適用後、新たに報告されたTMMBRタプルが境界セットに受け入れられない場合でも、TMMBNメッセージの送信をもたらすものとします。そのような場合、TMMBRが以前に計算された境界セット内のタプルの所有者からのものでない限り、境界タプルとその所有者は変更されません。この手順により、最後のTMMBNメッセージが表示されなかったセッション参加者は、このメディア送信者の状態を正しい見解を得ることができます。
As indicated in section 4.2.1.2, when a media sender determines that an "owner" of a bounding tuple has left the session, then that tuple is removed from the bounding set, and the media sender SHALL send a TMMBN message indicating the remaining bounding tuples. If there are no remaining bounding tuples, a TMMBN without any FCI SHALL be sent to indicate this. Without a remaining bounding tuple, the maximum media bit rate and maximum packet rate negotiated in session signaling, if any, apply.
セクション4.2.1.2に示されているように、メディア送信者が境界タプルの「所有者」がセッションを離れたと判断した場合、そのタプルは境界セットから削除され、メディア送信者は残りの境界を示すTMMBNメッセージを送信するものとします。タプル。残りの境界タプルがない場合、これを示すためにFCIのないTMMBNを送信するものとします。残りの境界タプルなしでは、セッションシグナリングで最大メディアビットレートと最大パケットレートが交渉された場合（もしあれば、適用されます。
Note: if any media receivers remain in the session, this last will be a temporary situation. The empty TMMBN will cause every remaining media receiver to determine that its limitation belongs in the bounding set and send a TMMBR in consequence.
注：メディアレシーバーがセッションに残っている場合、この最後は一時的な状況になります。空のTMMBNにより、残りのすべてのメディアレシーバーは、その制限が境界セットに属し、結果としてTMMBRを送信することを判断します。
In unicast scenarios (i.e., where a single sender talks to a single receiver), the aforementioned algorithm to determine ownership degenerates to the media receiver becoming the "owner" of the one bounding tuple as soon as the media receiver has issued the first TMMBR message.
ユニキャストシナリオ（つまり、単一の送信者が単一のレシーバーと協議する場合）では、前述のアルゴリズムがメディアレシーバーに退化し、メディアレシーバーが最初のTMMBRメッセージを発行するとすぐに、1つの境界タプルの「所有者」になります。。
The TMMBN acknowledgement SHOULD be sent as soon as allowed by the applied timing rules for the session. Immediate or early feedback mode SHOULD be used for these messages.
TMMBNの謝辞は、セッションの適用されたタイミングルールによって許可される限りすぐに送信する必要があります。これらのメッセージには、即時または早期フィードバックモードを使用する必要があります。
As discussed in section 4.2.1.4, mixers or translators may need to issue TMMBN messages as responses to TMMBR messages for SSRCs handled by them.
セクション4.2.1.4で説明したように、ミキサーまたは翻訳者は、それらによって処理されたSSRCのTMMBRメッセージへの応答としてTMMBNメッセージを発行する必要がある場合があります。
As specified by section 6.1 of RFC 4585 [RFC4585], Payload-Specific FB messages are identified by the RTCP packet type value PSFB (206).
RFC 4585 [RFC4585]のセクション6.1で指定されているように、ペイロード固有のFBメッセージは、RTCPパケットタイプ値PSFB（206）によって識別されます。
AVPF [RFC4585] defines three payload-specific feedback messages and one application layer feedback message. This memo specifies four additional payload-specific feedback messages. All are identified by means of the FMT parameter as follows: Assigned in [RFC4585]:
AVPF [RFC4585]は、3つのペイロード固有のフィードバックメッセージと1つのアプリケーションレイヤーフィードバックメッセージを定義します。このメモは、4つの追加ペイロード固有のフィードバックメッセージを指定します。すべてがFMTパラメーターによって次のように識別されます。[RFC4585]で割り当てられます。
1: Picture Loss Indication (PLI) 2: Slice Lost Indication (SLI) 3: Reference Picture Selection Indication (RPSI) 15: Application layer FB message 31: reserved for future expansion of the number space
1：画像の損失表示（PLI）2：スライスロスト表示（SLI）3：参照画像選択表示（RPSI）15：アプリケーションレイヤーFBメッセージ31：数値スペースの将来の拡張のために予約されています
Assigned in this memo:
このメモに割り当てられています：
4: Full Intra Request (FIR) Command 5: Temporal-Spatial Trade-off Request (TSTR) 6: Temporal-Spatial Trade-off Notification (TSTN) 7: Video Back Channel Message (VBCM)
4：完全なリクエスト（FIR）コマンド5：時間空間トレードオフリクエスト（TSTR）6：時間空間トレードオフ通知（TSTN）7：ビデオバックチャネルメッセージ（VBCM）
Unassigned:
割り当てられていない：
0: unassigned 8-14: unassigned 16-30: unassigned
0：割り当てされていない8-14：割り当てられていない16-30：割り当てられていない
The following subsections define the new FCI formats for the payload-specific feedback messages.
次のサブセクションでは、ペイロード固有のフィードバックメッセージの新しいFCI形式を定義します。
The FIR message is identified by RTCP packet type value PT=PSFB and FMT=4.
FIRメッセージは、RTCPパケットタイプ値PT = PSFBおよびFMT = 4によって識別されます。
The FCI field MUST contain one or more FIR entries. Each entry applies to a different media sender, identified by its SSRC.
FCIフィールドには、1つ以上のFIRエントリが含まれている必要があります。各エントリは、SSRCによって識別される別のメディア送信者に適用されます。
The Feedback Control Information (FCI) for the Full Intra Request consists of one or more FCI entries, the content of which is depicted in Figure 4. The length of the FIR feedback message MUST be set to 2+2*N, where N is the number of FCI entries.
完全なイントラリクエストのフィードバック制御情報（FCI）は1つ以上のFCIエントリで構成されており、その内容を図4に示します。FIRフィードバックメッセージの長さは2 2*nに設定する必要があります。ここで、nはnです。FCIエントリの数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - Syntax of an FCI Entry in the FIR Message
図4 -FIRメッセージのFCIエントリの構文
SSRC (32 bits): The SSRC value of the media sender that is requested to send a decoder refresh point.
SSRC（32ビット）：デコーダーリフレッシュポイントを送信するように要求されるメディア送信者のSSRC値。
Seq nr. (8 bits): Command sequence number. The sequence number space is unique for each pairing of the SSRC of command source and the SSRC of the command target. The sequence number SHALL be increased by 1 modulo 256 for each new command. A repetition SHALL NOT increase the sequence number. The initial value is arbitrary.
seq nr。（8ビット）：コマンドシーケンス番号。シーケンス番号スペースは、コマンドソースのSSRCとコマンドターゲットのSSRCのペアリングごとに一意です。シーケンス番号は、新しいコマンドごとに1 Modulo 256増加するものとします。繰り返しはシーケンス番号を増やしてはなりません。初期値は任意です。
Reserved (24 bits): All bits SHALL be set to 0 by the sender and SHALL be ignored on reception.
予約済み（24ビット）：すべてのビットは送信者によって0に設定され、受信時に無視されます。
The semantics of this feedback message is independent of the RTP payload type.
このフィードバックメッセージのセマンティクスは、RTPペイロードタイプとは無関係です。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the media senders to which the FIR command applies are in the corresponding FCI entries. A FIR message MAY contain requests to multiple media senders, using one FCI entry per target media sender.
フィードバックメッセージの一般的なパケットヘッダー内（[RFC4585]のセクション6.1で定義されているように）内で、「パケット送信者のSSRC」フィールドはリクエストのソースを示し、「メディアソースのSSRC」は使用されず、設定されます0.に、FIRコマンドが適用されるメディア送信者のSSRCは、対応するFCIエントリにあります。FIRメッセージには、ターゲットメディア送信者ごとに1つのFCIエントリを使用して、複数のメディア送信者へのリクエストが含まれる場合があります。
Upon reception of FIR, the encoder MUST send a decoder refresh point (see section 2.2) as soon as possible.
FIRを受信すると、エンコーダーはできるだけ早くデコーダーリフレッシュポイント（セクション2.2を参照）を送信する必要があります。
The sender MUST consider congestion control as outlined in section 5, which MAY restrict its ability to send a decoder refresh point quickly.
送信者は、セクション5で概説されている渋滞制御を考慮する必要があります。これにより、デコーダーリフレッシュポイントをすばやく送信する能力が制限される場合があります。
FIR SHALL NOT be sent as a reaction to picture losses -- it is RECOMMENDED to use PLI [RFC4585] instead. FIR SHOULD be used only in situations where not sending a decoder refresh point would render the video unusable for the users.
FIRは、画像損失に対する反応として送られてはなりません。代わりにPLI [RFC4585]を使用することをお勧めします。FIRは、デコーダーリフレッシュポイントを送信しないとユーザーが使用できない状況でのみ使用する必要があります。
A typical example where sending FIR is appropriate is when, in a multipoint conference, a new user joins the session and no regular decoder refresh point interval is established. Another example would be a video switching MCU that changes streams. Here, normally, the MCU issues a FIR to the new sender so to force it to emit a decoder refresh point. The decoder refresh point normally includes a Freeze Picture Release (defined outside this specification), which re-starts the rendering process of the receivers. Both techniques mentioned are commonly used in MCU-based multipoint conferences.
FIRの送信が適切である典型的な例は、マルチポイント会議で新しいユーザーがセッションに参加し、通常のデコーダーリフレッシュポイント間隔が確立されない場合です。別の例は、ストリームを変更するビデオスイッチングMCUです。ここでは、通常、MCUは新しい送信者にFIRを発行して、デコーダーのリフレッシュポイントを放出するように強制します。デコーダーリフレッシュポイントには、通常、フリーズ画像リリース（この仕様の外部で定義されている）が含まれており、受信機のレンダリングプロセスを再起動します。言及された両方の手法は、MCUベースのマルチポイント会議で一般的に使用されています。
Other RTP payload specifications such as RFC 2032 [RFC2032] already define a feedback mechanism for certain codecs. An application supporting both schemes MUST use the feedback mechanism defined in this specification when sending feedback. For backward-compatibility reasons, such an application SHOULD also be capable of receiving and reacting to the feedback scheme defined in the respective RTP payload format, if this is required by that payload format.
RFC 2032 [RFC2032]などの他のRTPペイロード仕様は、特定のコーデックのフィードバックメカニズムをすでに定義しています。両方のスキームをサポートするアプリケーションは、フィードバックを送信するときにこの仕様で定義されたフィードバックメカニズムを使用する必要があります。後方適合性の理由から、このようなアプリケーションは、そのペイロード形式で必要とされる場合、それぞれのRTPペイロード形式で定義されたフィードバックスキームを受信して対応できる必要があります。
The timing follows the rules outlined in section 3 of [RFC4585]. FIR commands MAY be used with early or immediate feedback. The FIR feedback message MAY be repeated. If using immediate feedback mode, the repetition SHOULD wait at least one RTT before being sent. In early or regular RTCP mode, the repetition is sent in the next regular RTCP packet.
タイミングは、[RFC4585]のセクション3で概説されているルールに従います。FIRコマンドは、早期または即時のフィードバックで使用できます。FIRフィードバックメッセージが繰り返される場合があります。即時フィードバックモードを使用する場合、繰り返しは送信される前に少なくとも1つのRTTを待つ必要があります。早期または通常のRTCPモードでは、繰り返しが次の通常のRTCPパケットで送信されます。
A media translator or a mixer performing media encoding of the content for which the session participant has issued a FIR is responsible for acting upon it. A mixer acting upon a FIR SHOULD NOT forward the message unaltered; instead, it SHOULD issue a FIR itself.
セッション参加者がFIRを発行したコンテンツをエンコードするメディア翻訳者またはミキサーを実行するミキサーは、それに基づいて行動する責任があります。FIRに作用するミキサーは、メッセージを変更せずに転送しないでください。代わりに、FIR自体を発行する必要があります。
Currently, video appears to be the only useful application for FIR, as it appears to be the only RTP payload widely deployed that relies heavily on media prediction across RTP packet boundaries. However, use of FIR could also reasonably be envisioned for other media types that share essential properties with compressed video, namely, cross-frame prediction (whatever a frame may be for that media type). One possible example may be the dynamic updates of MPEG-4 scene descriptions. It is suggested that payload formats for such media types refer to FIR and other message types defined in this specification and in AVPF [RFC4585], instead of creating similar mechanisms in the payload specifications. The payload specifications may have to explain how the payload-specific terminologies map to the video-centric terminology used herein.
現在、ビデオはFIRの唯一の有用なアプリケーションのように見えます。これは、RTPパケットの境界全体でメディアの予測に大きく依存している広く展開されている唯一のRTPペイロードであると思われるためです。ただし、FIRの使用は、圧縮されたビデオ、つまりクロスフレーム予測（そのメディアタイプにフレームが何であれ）で重要なプロパティを共有する他のメディアタイプについても合理的に想定することができます。考えられる例の1つは、MPEG-4シーンの説明の動的な更新です。このようなメディアタイプのペイロード形式は、ペイロード仕様に同様のメカニズムを作成する代わりに、この仕様およびAVPF [RFC4585]で定義されているFIRおよびその他のメッセージタイプを指すことが示唆されています。ペイロード仕様は、ペイロード固有の用語がここで使用されるビデオ中心の用語にどのようにマッピングされるかを説明する必要がある場合があります。
In conjunction with video codecs, FIR messages typically trigger the sending of full intra or IDR pictures. Both are several times larger than predicted (inter) pictures. Their size is independent of the time they are generated. In most environments, especially when employing bandwidth-limited links, the use of an intra picture implies an allowed delay that is a significant multiple of the typical frame duration. An example: if the sending frame rate is 10 fps, and an intra picture is assumed to be 10 times as big as an inter picture, then a full second of latency has to be accepted. In such an environment, there is no need for a particularly short delay in sending the FIR message. Hence, waiting for the next possible time slot allowed by RTCP timing rules as per [RFC4585] should not have an overly negative impact on the system performance.
ビデオコーデックと組み合わせて、FIRメッセージは通常、完全な内部またはIDRの写真の送信をトリガーします。どちらも予測された（インター）写真の数倍です。それらのサイズは、生成される時間とは無関係です。ほとんどの環境では、特に帯域幅が制限されたリンクを採用する場合、内部の画像を使用することは、一般的なフレーム持続時間の大幅な倍数である許可された遅延を意味します。例：送信フレームレートが10 fpsであり、内部画像がインターピクチャーの10倍の大きさであると想定される場合、レイテンシの完全なレイテンシーを受け入れる必要があります。このような環境では、FIRメッセージの送信に特に短い遅延は必要ありません。したがって、[RFC4585]に従ってRTCPタイミングルールによって許可される次の時間スロットを待っているのを待ってください。
Mandating a maximum delay for completing the sending of a decoder refresh point would be desirable from an application viewpoint, but is problematic from a congestion control point of view. "As soon as possible" as mentioned above appears to be a reasonable compromise.
デコーダーリフレッシュポイントの送信を完了するために最大の遅延を義務付けることは、アプリケーションの観点からは望ましいものですが、輻輳制御の観点からは問題があります。上記のように「できるだけ早く」は、合理的な妥協のようです。
In environments where the sender has no control over the codec (e.g., when streaming pre-recorded and pre-coded content), the reaction to this command cannot be specified. One suitable reaction of a sender would be to skip forward in the video bit stream to the next decoder refresh point. In other scenarios, it may be preferable not to react to the command at all, e.g., when streaming to a large multicast group. Other reactions may also be possible. When deciding on a strategy, a sender could take into account factors such as the size of the receiving group, the "importance" of the sender of the FIR message (however "importance" may be defined in this specific application), the frequency of decoder refresh points in the content, and so on. However, a session that predominantly handles pre-coded content is not expected to use FIR at all.
送信者がコーデックを制御できない環境（たとえば、事前に録音されたコンテンツと事前にコード化されたコンテンツをストリーミングするとき）では、このコマンドに対する反応を指定できません。送信者の適切な反応の1つは、ビデオビットストリームで次のデコーダーリフレッシュポイントまで前方にスキップすることです。他のシナリオでは、大規模なマルチキャストグループにストリーミングする場合、コマンドにまったく反応しないことが望ましい場合があります。他の反応も可能かもしれません。戦略を決定する場合、送信者は受信グループのサイズなどの要因を考慮することができます。FIRメッセージの送信者の「重要性」（ただし、この特定のアプリケーションで「重要」が定義される場合があります）、頻度の頻度コンテンツのデコーダーリフレッシュポイントなど。ただし、主に事前にコード化されたコンテンツを処理するセッションでは、FIRをまったく使用することはまったくありません。
The relationship between the Picture Loss Indication and FIR is as follows. As discussed in section 6.3.1 of AVPF [RFC4585], a Picture Loss Indication informs the decoder about the loss of a picture and hence the likelihood of misalignment of the reference pictures between the encoder and decoder. Such a scenario is normally related to losses in an ongoing connection. In point-to-point scenarios, and without the presence of advanced error resilience tools, one possible option for an encoder consists in sending a decoder refresh point. However, there are other options. One example is that the media sender ignores the PLI, because the embedded stream redundancy is likely to clean up the reproduced picture within a reasonable amount of time. The FIR, in contrast, leaves a (real-time) encoder no choice but to send a decoder refresh point. It does not allow the encoder to take into account any considerations such as the ones mentioned above.
画像喪失の表示とFIRの関係は次のとおりです。AVPF [RFC4585]のセクション6.3.1で説明したように、画像の損失の表示は、画像の喪失、したがってエンコーダとデコーダー間の参照画像の不整列の可能性についてデコーダーに通知します。このようなシナリオは、通常、進行中の接続での損失に関連しています。ポイントツーポイントシナリオでは、高度なエラーレジリエンスツールが存在しない場合、エンコーダーの可能なオプションの1つは、デコーダーリフレッシュポイントの送信で構成されています。ただし、他にはオプションがあります。1つの例は、メディア送信者がPLIを無視することです。これは、埋め込まれたストリーム冗長性が合理的な時間内に再現された画像をクリーンアップする可能性が高いためです。対照的に、FIRは（リアルタイム）エンコーダーを残し、デコーダーリフレッシュポイントを送信する以外に選択肢がありません。エンコーダーは、上記のような考慮事項を考慮に入れることができません。
The TSTR feedback message is identified by RTCP packet type value PT=PSFB and FMT=5.
TSTRフィードバックメッセージは、RTCPパケットタイプ値PT = PSFBおよびFMT = 5によって識別されます。
The FCI field MUST contain one or more TSTR FCI entries.
FCIフィールドには、1つ以上のTSTR FCIエントリが含まれている必要があります。
The content of the FCI entry for the Temporal-Spatial Trade-off Request is depicted in Figure 5. The length of the feedback message MUST be set to 2+2*N, where N is the number of FCI entries included.
時間空間トレードオフリクエストのFCIエントリの内容を図5に示します。フィードバックメッセージの長さは2 2*nに設定する必要があります。ここで、nは含まれるFCIエントリの数です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - Syntax of an FCI Entry in the TSTR Message
図5- TSTRメッセージのFCIエントリの構文
SSRC (32 bits): The SSRC of the media sender that is requested to apply the trade-off value given in Index.
SSRC（32ビット）：インデックスに与えられたトレードオフ値を適用するように要求されたメディア送信者のSSRC。
Seq nr. (8 bits): Request sequence number. The sequence number space is unique for pairing of the SSRC of request source and the SSRC of the request target. The sequence number SHALL be increased by 1 modulo 256 for each new command. A repetition SHALL NOT increase the sequence number. The initial value is arbitrary.
seq nr。（8ビット）：シーケンス番号を要求します。シーケンス番号スペースは、リクエストソースのSSRCとリクエストターゲットのSSRCのペアリングにユニークです。シーケンス番号は、新しいコマンドごとに1 Modulo 256増加するものとします。繰り返しはシーケンス番号を増やしてはなりません。初期値は任意です。
Reserved (19 bits): All bits SHALL be set to 0 by the sender and SHALL be ignored on reception.
予約済み（19ビット）：すべてのビットは送信者によって0に設定され、受信時に無視されます。
Index (5 bits): An integer value between 0 and 31 that indicates the relative trade-off that is requested. An index value of 0 indicates the highest possible spatial quality, while 31 indicates the highest possible temporal resolution.
インデックス（5ビット）：要求される相対的なトレードオフを示す0〜31の整数値。0のインデックス値は、可能な限り高い空間品質を示し、31は可能な限り高い時間分解能を示します。
A decoder can suggest a temporal-spatial trade-off level by sending a TSTR message to an encoder. If the encoder is capable of adjusting its temporal-spatial trade-off, it SHOULD take into account the received TSTR message for future coding of pictures. A value of 0 suggests a high spatial quality and a value of 31 suggests a high frame rate. The progression of values from 0 to 31 indicates monotonically a desire for higher frame rate. The index values do not correspond to precise values of spatial quality or frame rate.
デコーダーは、エンコーダーにTSTRメッセージを送信することにより、時間空間トレードオフレベルを提案できます。エンコーダーが時間空間トレードオフを調整できる場合、将来の写真のコーディングのための受信したTSTRメッセージを考慮する必要があります。0の値は高い空間品質を示唆し、31の値は高いフレームレートを示唆しています。0から31の値の進行は、単調に高いフレームレートの欲求を示しています。インデックス値は、空間品質またはフレームレートの正確な値に対応しません。
The reaction to the reception of more than one TSTR message by a media sender from different media receivers is left open to the implementation. The selected trade-off SHALL be communicated to the media receivers by means of the TSTN message.
さまざまなメディアレシーバーからのメディア送信者による複数のTSTRメッセージの受信に対する反応は、実装に開かれたままになります。選択されたトレードオフは、TSTNメッセージを使用してメディアレシーバーに伝達されるものとします。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the media senders to which the TSTR applies are in the corresponding FCI entries.
フィードバックメッセージの一般的なパケットヘッダー内（[RFC4585]のセクション6.1で定義されているように）内で、「パケット送信者のSSRC」フィールドはリクエストのソースを示し、「メディアソースのSSRC」は使用されず、設定されます0.TSTRが適用されるメディア送信者のSSRCは、対応するFCIエントリにあります。
A TSTR message MAY contain requests to multiple media senders, using one FCI entry per target media sender.
TSTRメッセージには、ターゲットメディア送信者ごとに1つのFCIエントリを使用して、複数のメディア送信者へのリクエストが含まれる場合があります。
The timing follows the rules outlined in section 3 of [RFC4585]. This request message is not time critical and SHOULD be sent using regular RTCP timing. Only if it is known that the user interface requires quick feedback, the message MAY be sent with early or immediate feedback timing.
タイミングは、[RFC4585]のセクション3で概説されているルールに従います。このリクエストメッセージは時間が重要ではなく、通常のRTCPタイミングを使用して送信する必要があります。ユーザーインターフェイスが迅速なフィードバックを必要とすることがわかっている場合にのみ、メッセージは早期または即時のフィードバックタイミングで送信される場合があります。
A mixer or media translator that encodes content sent to the session participant issuing the TSTR SHALL consider the request to determine if it can fulfill it by changing its own encoding parameters. A media translator unable to fulfill the request MAY forward the request unaltered towards the media sender. A mixer encoding for multiple session participants will need to consider the joint needs of these participants before generating a TSTR on its own behalf towards the media sender. See also the discussion in section 3.5.2.
TSTRを発行するセッション参加者に送信されたコンテンツをエンコードするミキサーまたはメディア翻訳者は、独自のエンコードパラメーターを変更することでそれを満たすことができるかどうかを判断するリクエストを検討するものとします。リクエストを満たせないメディア翻訳者は、メディアの送信者に変更されていないリクエストを転送することができます。複数のセッション参加者向けのミキサーエンコードは、メディア送信者に代わってTSTRを生成する前に、これらの参加者の共同ニーズを考慮する必要があります。セクション3.5.2の説明も参照してください。
The term "spatial quality" does not necessarily refer to the resolution as measured by the number of pixels the reconstructed video is using. In fact, in most scenarios the video resolution stays constant during the lifetime of a session. However, all video compression standards have means to adjust the spatial quality at a given resolution, often influenced by the Quantizer Parameter or QP. A numerically low QP results in a good reconstructed picture quality, whereas a numerically high QP yields a coarse picture. The typical reaction of an encoder to this request is to change its rate control parameters to use a lower frame rate and a numerically lower (on average) QP, or vice versa. The precise mapping of Index value to frame rate and QP is intentionally left open here, as it depends on factors such as the compression standard employed, spatial resolution, content, bit rate, and so on.
「空間品質」という用語は、再構築されたビデオが使用しているピクセルの数で測定される解像度を必ずしも指すものではありません。実際、ほとんどのシナリオでは、ビデオ解像度はセッションの存続期間中に一定のままです。ただし、すべてのビデオ圧縮標準には、特定の解像度で空間品質を調整する手段があり、多くの場合、数式パラメーターまたはQPの影響を受けます。数値的に低いQPは、良好な再構築された画質をもたらしますが、数値的に高いQPは粗い画像を生成します。この要求に対するエンコーダーの典型的な反応は、レート制御パラメーターを変更して、より低いフレームレートと数値的に（平均して）QPを使用するか、その逆を使用することです。フレームレートとQPへのインデックス値の正確なマッピングは、採用された圧縮標準、空間解像度、コンテンツ、ビットレートなどの要因に依存するため、ここで意図的に開いたままになります。
The TSTN message is identified by RTCP packet type value PT=PSFB and FMT=6.
TSTNメッセージは、RTCPパケットタイプ値PT = PSFBおよびFMT = 6によって識別されます。
The FCI field SHALL contain one or more TSTN FCI entries.
FCIフィールドには、1つ以上のTSTN FCIエントリが含まれている必要があります。
The content of an FCI entry for the Temporal-Spatial Trade-off Notification is depicted in Figure 6. The length of the TSTN message MUST be set to 2+2*N, where N is the number of FCI entries.
時間空間トレードオフ通知のFCIエントリの内容を図6に示します。TSTNメッセージの長さは2 2*nに設定する必要があります。ここで、nはFCIエントリの数です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - Syntax of the TSTN
図6- TSTNの構文
SSRC (32 bits): The SSRC of the source of the TSTR that resulted in this Notification.
SSRC（32ビット）：この通知をもたらしたTSTRのソースのSSRC。
Seq nr. (8 bits): The sequence number value from the TSTR that is being acknowledged.
Reserved (19 bits): All bits SHALL be set to 0 by the sender and SHALL be ignored on reception.
予約済み（19ビット）：すべてのビットは送信者によって0に設定され、受信時に無視されます。
Index (5 bits): The trade-off value the media sender is using henceforth.
インデックス（5ビット）：メディア送信者が次に使用しているトレードオフ値。
Informative note: The returned trade-off value (Index) may differ from the requested one, for example, in cases where a media encoder cannot tune its trade-off, or when pre-recorded content is used.
有益なメモ：返されたトレードオフ値（インデックス）は、メディアエンコーダーがトレードオフをチューニングできない場合、または事前に録音されたコンテンツが使用されている場合、要求された値（インデックス）とは異なる場合があります。
This feedback message is used to acknowledge the reception of a TSTR. For each TSTR received targeted at the session participant, a TSTN FCI entry SHALL be sent in a TSTN feedback message. A single TSTN message MAY acknowledge multiple requests using multiple FCI entries. The index value included SHALL be the same in all FCI entries of the TSTN message. Including a FCI for each requestor allows each requesting entity to determine that the media sender received the request. The Notification SHALL also be sent in response to TSTR repetitions received. If the request receiver has received TSTR with several different sequence numbers from a single requestor, it SHALL only respond to the request with the highest (modulo 256) sequence number. Note that the highest sequence number may be a smaller integer value due to the wrapping of the field. Appendix A.1 of [RFC3550] has an algorithm for keeping track of the highest received sequence number for RTP packets; it could be adapted for this usage.
このフィードバックメッセージは、TSTRの受信を確認するために使用されます。セッション参加者のターゲットを受けた各TSTRについて、TSTN FCIエントリはTSTNフィードバックメッセージで送信されます。単一のTSTNメッセージは、複数のFCIエントリを使用して複数のリクエストを確認する場合があります。含まれるインデックス値は、TSTNメッセージのすべてのFCIエントリで同じでなければなりません。各リクエスターにFCIを含めることで、各リクエストエンティティがメディア送信者がリクエストを受け取ったことを判断できます。通知は、受け取ったTSTR繰り返しに応じて送信されます。リクエストレシーバーが単一の要求者からいくつかの異なるシーケンス番号を持つTSTRを受信した場合、最高の（モジュロ256）シーケンス番号でのみリクエストに応答するものとします。最も高いシーケンス番号は、フィールドのラッピングにより、整数値が小さくなる可能性があることに注意してください。[RFC3550]の付録A.1には、RTPパケットの最高の受信シーケンス番号を追跡するためのアルゴリズムがあります。この使用に適している可能性があります。
The TSTN SHALL include the Temporal-Spatial Trade-off index that will be used as a result of the request. This is not necessarily the same index as requested, as the media sender may need to aggregate requests from several requesting session participants. It may also have some other policies or rules that limit the selection.
TSTNには、要求の結果として使用される時間空間トレードオフインデックスが含まれます。これは、メディア送信者がいくつかの要求セッション参加者からのリクエストを集約する必要がある可能性があるため、必ずしも要求と同じインデックスではありません。また、選択を制限する他のポリシーまたはルールがある場合があります。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the Notification, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the requesting entities to which the Notification applies are in the corresponding FCI entries.
フィードバックメッセージの一般的なパケットヘッダー内（[RFC4585]のセクション6.1で定義されている）内で、「パケット送信者のSSRC」フィールドは通知のソースを示し、「メディアソースのSSRC」は使用されず、設定されます0.に、通知が適用される要求エンティティのSSRCは、対応するFCIエントリにあります。
The timing follows the rules outlined in section 3 of [RFC4585]. This acknowledgement message is not extremely time critical and SHOULD be sent using regular RTCP timing.
タイミングは、[RFC4585]のセクション3で概説されているルールに従います。この承認メッセージは非常に時間的に重要ではなく、通常のRTCPタイミングを使用して送信する必要があります。
A mixer or translator that acts upon a TSTR SHALL also send the corresponding TSTN. In cases where it needs to forward a TSTR itself, the notification message MAY need to be delayed until the TSTR has been responded to.
TSTRに作用するミキサーまたは翻訳者も、対応するTSTNを送信するものとします。TSTR自体を転送する必要がある場合は、TSTRが応答するまで通知メッセージを遅らせる必要がある場合があります。
None.
なし。
The VBCM is identified by RTCP packet type value PT=PSFB and FMT=7.
VBCMは、RTCPパケットタイプ値PT = PSFBおよびFMT = 7によって識別されます。
The FCI field MUST contain one or more VBCM FCI entries.
FCIフィールドには、1つ以上のVBCM FCIエントリを含める必要があります。
The syntax of an FCI entry within the VBCM indication is depicted in Figure 7.
VBCM表示内のFCIエントリの構文を図7に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. |0| Payload Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VBCM Octet String.... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 - Syntax of an FCI Entry in the VBCM
図7- VBCMのFCIエントリの構文
SSRC (32 bits): The SSRC value of the media sender that is requested to instruct its encoder to react to the VBCM.
SSRC（32ビット）：エンコーダーにVBCMに反応するように指示するように要求されるメディア送信者のSSRC値。
Seq nr. (8 bits): Command sequence number. The sequence number space is unique for pairing of the SSRC of the command source and the SSRC of the command target. The sequence number SHALL be increased by 1 modulo 256 for each new command. A repetition SHALL NOT increase the sequence number. The initial value is arbitrary.
seq nr。（8ビット）：コマンドシーケンス番号。シーケンス番号スペースは、コマンドソースのSSRCとコマンドターゲットのSSRCのペアリングにユニークです。シーケンス番号は、新しいコマンドごとに1 Modulo 256増加するものとします。繰り返しはシーケンス番号を増やしてはなりません。初期値は任意です。
0: Must be set to 0 by the sender and should not be acted upon by the message receiver.
0：送信者によって0に設定する必要があり、メッセージ受信機によって動作しないでください。
Payload Type (7 bits): The RTP payload type for which the VBCM bit stream must be interpreted.
ペイロードタイプ（7ビット）：VBCMビットストリームを解釈する必要があるRTPペイロードタイプ。
Length (16 bits): The length of the VBCM octet string in octets exclusive of any padding octets.
長さ（16ビット）：パディングオクテットを除くオクテットのVBCMオクテット文字列の長さ。
VBCM Octet String (variable length): This is the octet string generated by the decoder carrying a specific feedback sub-message.
VBCMオクテット文字列（可変長）：これは、特定のフィードバックサブメッセージを運ぶデコーダーによって生成されるオクテット文字列です。
Padding (variable length): Bits set to 0 to make up a 32-bit boundary.
パディング（可変長）：32ビットの境界を構成するために0に設定されています。
The "payload" of the VBCM indication carries different types of codec-specific, feedback information. The type of feedback information can be classified as a 'status report' (such as an indication that a bit stream was received without errors, or that a partial or complete picture or block was lost) or 'update requests' (such as complete refresh of the bit stream).
VBCM表示の「ペイロード」には、さまざまな種類のコーデック固有のフィードバック情報が含まれています。フィードバック情報のタイプは、「ステータスレポート」（エラーなしで少しストリームが受信されたこと、または部分的または完全な画像またはブロックが失われたことを示すことなど）または「更新リクエスト」（完全な更新など）として分類できます。ビットストリームの）。
Note: There are possible overlaps between the VBCM sub-messages and CCM/AVPF feedback messages, such as FIR. Please see section 3.5.3 for further discussion.
注：VBCMサブメッセージとFIRなどのCCM/AVPFフィードバックメッセージとの間には重複があります。詳細については、セクション3.5.3を参照してください。
The different types of feedback sub-messages carried in the VBCM are indicated by the "payloadType" as defined in [H.271]. These sub-message types are reproduced below for convenience. "payloadType", in ITU-T Rec. H.271 terminology, refers to the sub-type of the H.271 message and should not be confused with an RTP payload type.
VBCMで運ばれるさまざまな種類のフィードバックサブメッセージは、[h.271]で定義されている「payloadtype」で示されます。これらのサブメッセージタイプは、便利なために以下に再現されています。「PayloadType」、ITU-T Rec。H.271用語は、H.271メッセージのサブタイプを指し、RTPペイロードタイプと混同しないでください。
Payload Message Content
Type
---------------------------------------------------------------------
0 One or more pictures without detected bit stream error
mismatch
1 One or more pictures that are entirely or partially lost
2 A set of blocks of one picture that is entirely or partially
lost
3 CRC for one parameter set
4 CRC for all parameter sets of a certain type
5 A "reset" request indicating that the sender should completely
refresh the video bit stream as if no prior bit stream data
had been received
> 5 Reserved for future use by ITU-T
Table 2: H.271 message types ("payloadTypes")
表2：H.271メッセージタイプ（ "PayloadTypes"）
The bit string or the "payload" of a VBCM is of variable length and is self-contained and coded in a variable-length, binary format. The media sender necessarily has to be able to parse this optimized binary format to make use of VBCMs.
VBCMのビット文字列または「ペイロード」はさまざまな長さであり、自己完結型であり、可変長のバイナリ形式でコーディングされています。メディア送信者は、VBCMを使用するためにこの最適化されたバイナリ形式を解析できる必要がある必要があります。
Each of the different types of sub-messages (indicated by payloadType) may have different semantics depending on the codec used.
さまざまな種類のサブメッセージ（PayloadTypeで示されている）のそれぞれは、使用されるコーデックに応じて異なるセマンティクスを持つ場合があります。
Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the media senders to which the VBCM applies are in the corresponding FCI entries. The sender of the VBCM MAY send H.271 messages to multiple media senders and MAY send more than one H.271 message to the same media sender within the same VBCM.
フィードバックメッセージの一般的なパケットヘッダー内（[RFC4585]のセクション6.1で定義されているように）内で、「パケット送信者のSSRC」フィールドはリクエストのソースを示し、「メディアソースのSSRC」は使用されず、設定されます0.に、VBCMが適用するメディア送信者のSSRCは、対応するFCIエントリにあります。VBCMの送信者は、複数のメディア送信者にH.271メッセージを送信し、同じVBCM内の同じメディア送信者に複数のH.271メッセージを送信する場合があります。
The timing follows the rules outlined in section 3 of [RFC4585]. The different sub-message types may have different properties in regards to the timing of messages that should be used. If several different types are included in the same feedback packet, then the requirements for the sub-message type with the most stringent requirements should be followed.
タイミングは、[RFC4585]のセクション3で概説されているルールに従います。さまざまなサブメッセージタイプは、使用する必要があるメッセージのタイミングに関して異なるプロパティを持つ場合があります。いくつかの異なるタイプが同じフィードバックパケットに含まれている場合、最も厳しい要件を持つサブメッセージタイプの要件に従う必要があります。
The handling of a VBCM in a mixer or translator is sub-message type dependent.
ミキサーまたは翻訳者でのVBCMの取り扱いは、サブメッセージタイプに依存します。
Please see section 3.5.3 for a discussion of the usage of H.271 messages and messages defined in AVPF [RFC4585] and this memo with similar functionality.
AVPF [RFC4585]で定義されているH.271メッセージとメッセージの使用と、同様の機能を備えたこのメモの使用については、セクション3.5.3を参照してください。
Note: There has been some discussion whether the RTP payload type field in this message is needed. It will be needed if there is potentially more than one VBCM-capable RTP payload type in the same session, and the semantics of a given VBCM changes between payload types. For example, the picture identification mechanism in messages of H.271 type 0 is fundamentally different between H.263 and H.264 (although both use the same syntax). Therefore, the payload field is justified here. There was a further comment that for TSTR and FIR such a need does not exist, because the semantics of TSTR and FIR are either loosely enough defined, or generic enough, to apply to all video payloads currently in existence/envisioned.
注：このメッセージのRTPペイロードタイプフィールドが必要かどうかは、いくつかの議論がありました。同じセッションに複数のVBCM対応のRTPペイロードタイプが潜在的に存在する可能性があり、特定のVBCMのセマンティクスがペイロードタイプ間で変化する場合が必要になります。たとえば、H.271タイプ0のメッセージの画像識別メカニズムは、H.263とH.264の間で根本的に異なります（どちらも同じ構文を使用しています）。したがって、ここではペイロードフィールドが正当化されます。TSTRとFIRのセマンティクスは、現在存在/想定されているすべてのビデオペイロードに適用するために、TSTRとFIRのセマンティクスが十分に定義されているか、十分に一般的であるため、TSTRとFIRのそのようなニーズは存在しないというさらなるコメントがありました。
The correct application of the AVPF [RFC4585] timing rules prevents the network from being flooded by feedback messages. Hence, assuming a correct implementation and configuration, the RTCP channel cannot break its bit rate commitment and introduce congestion.
AVPF [RFC4585]タイミングルールの正しいアプリケーションにより、ネットワークがフィードバックメッセージに浸水するのを防ぎます。したがって、正しい実装と構成を想定すると、RTCPチャネルはビットレートのコミットメントを破って混雑を導入することはできません。
The reception of some of the feedback messages modifies the behaviour of the media senders or, more specifically, the media encoders.
一部のフィードバックメッセージを受信すると、メディア送信者、より具体的にはメディアエンコーダーの動作が変更されます。
Thus, modified behaviour MUST respect the bandwidth limits that the application of congestion control provides. For example, when a media sender is reacting to a FIR, the unusually high number of packets that form the decoder refresh point have to be paced in compliance with the congestion control algorithm, even if the user experience suffers from a slowly transmitted decoder refresh point.
したがって、修正された動作は、輻輳制御の適用が提供する帯域幅の制限を尊重する必要があります。たとえば、メディア送信者がFIRに反応している場合、ユーザーエクスペリエンスがゆっくりと送信されたデコーダーリフレッシュポイントに苦しんでいても、デコーダーリフレッシュポイントを形成する非常に多数のパケットをペースで順守する必要があります。。
A change of the Temporary Maximum Media Stream Bit Rate value can only mitigate congestion, but not cause congestion as long as congestion control is also employed. An increase of the value by a request REQUIRES the media sender to use congestion control when increasing its transmission rate to that value. A reduction of the value results in a reduced transmission bit rate, thus reducing the risk for congestion.
一時的な最大メディアストリームビットレート値の変更は、うっ血を軽減するだけですが、混雑制御も採用されている限り、混雑を引き起こすことはありません。リクエストによる価値の増加には、メディア送信者がその値に送信速度を上げる際に混雑制御を使用する必要があります。値を減らすと、伝送ビットレートが低下し、輻輳のリスクが減少します。
The defined messages have certain properties that have security implications. These must be addressed and taken into account by users of this protocol.
定義されたメッセージには、セキュリティに影響を与える特定のプロパティがあります。これらは、このプロトコルのユーザーが対処し、考慮する必要があります。
The defined setup signaling mechanism is sensitive to modification attacks that can result in session creation with sub-optimal configuration, and, in the worst case, session rejection. To prevent this type of attack, authentication and integrity protection of the setup signaling is required.
定義されたセットアップシグナル伝達メカニズムは、最適な構成でセッションの作成をもたらす可能性のある修正攻撃に敏感であり、最悪の場合、セッションの拒否です。このタイプの攻撃を防ぐために、セットアップシグナリングの認証と整合性保護が必要です。
Spoofed or maliciously created feedback messages of the type defined in this specification can have the following implications:
この仕様で定義されたタイプのスプーフィングまたは悪意のあるフィードバックメッセージは、次の意味を持つことができます。
a. severely reduced media bit rate due to false TMMBR messages that sets the maximum to a very low value;
a. 最大値を非常に低い値に設定する誤ったTMMBRメッセージにより、メディアビットレートが大幅に低下しました。
b. assignment of the ownership of a bounding tuple to the wrong participant within a TMMBN message, potentially causing unnecessary oscillation in the bounding set as the mistakenly identified owner reports a change in its tuple and the true owner possibly holds back on changes until a correct TMMBN message reaches the participants;
b. TMMBNメッセージ内の間違った参加者への境界タプルの所有権の割り当ては、誤って識別された所有者がそのタプルの変更を報告し、真の所有者が正しいTMMBNメッセージまで変更を抑えているため、境界セットで不必要な振動を引き起こす可能性があります。参加者に到達します。
c. sending TSTRs that result in a video quality different from the user's desire, rendering the session less useful;
c. ユーザーの欲求とは異なるビデオ品質をもたらすTSTRを送信すると、セッションの有用性が低下します。
d. sending multiple FIR commands to reduce the frame rate, and make the video jerky, due to the frequent usage of decoder refresh points.
d. デコーダーリフレッシュポイントの使用が頻繁に使用されるため、フレームレートを下げるために複数のFIRコマンドを送信し、ビデオをぎくしゃくします。
To prevent these attacks, there is a need to apply authentication and integrity protection of the feedback messages. This can be accomplished against threats external to the current RTP session using the RTP profile that combines Secure RTP [SRTP] and AVPF into SAVPF [SAVPF]. In the mixer cases, separate security contexts and filtering can be applied between the mixer and the participants, thus protecting other users on the mixer from a misbehaving participant.
これらの攻撃を防ぐために、フィードバックメッセージの認証と整合性の保護を適用する必要があります。これは、Secure RTP [SRTP]とAVPFをSAVPF [SAVPF]に組み合わせたRTPプロファイルを使用して、現在のRTPセッションの外部の脅威に対して達成できます。ミキサーのケースでは、ミキサーと参加者の間に個別のセキュリティコンテキストとフィルタリングを適用できるため、ミキサーの他のユーザーを誤動作の参加者から保護できます。
Section 4 of [RFC4585] defines a new SDP [RFC4566] attribute, rtcp-fb, that may be used to negotiate the capability to handle specific AVPF commands and indications, such as Reference Picture Selection, Picture Loss Indication, etc. The ABNF for rtcp-fb is described in section 4.2 of [RFC4585]. In this section, we extend the rtcp-fb attribute to include the commands and indications that are described for codec control in the present document. We also discuss the Offer/Answer implications for the codec control commands and indications.
[RFC4585]のセクション4では、参照画像選択、画像損失の表示など、特定のAVPFコマンドと適応症を処理する能力を交渉するために使用できる新しいSDP [RFC4566]属性RTCP-FBを定義しています。RTCP-FBは、[RFC4585]のセクション4.2で説明されています。このセクションでは、RTCP-FB属性を拡張して、現在のドキュメントでコーデック制御について説明されているコマンドと表示を含めます。また、コーデック制御コマンドと表示に対するオファー/回答の意味についても説明します。
As described in AVPF [RFC4585], the rtcp-fb attribute indicates the capability of using RTCP feedback. AVPF specifies that the rtcp-fb attribute must only be used as a media level attribute and must not be provided at session level. All the rules described in [RFC4585] for rtcp-fb attribute relating to payload type and to multiple rtcp-fb attributes in a session description also apply to the new feedback messages defined in this memo.
AVPF [RFC4585]で説明されているように、RTCP-FB属性はRTCPフィードバックを使用する機能を示します。AVPFは、RTCP-FB属性をメディアレベルの属性としてのみ使用する必要があり、セッションレベルで提供されないことを指定します。ペイロードタイプとセッション説明の複数のRTCP-FB属性に関連するRTCP-FB属性の[RFC4585]で説明されているすべてのルールは、このメモで定義された新しいフィードバックメッセージにも適用されます。
The ABNF [RFC4234] for rtcp-fb as defined in [RFC4585] is
[RFC4585]で定義されているRTCP-FBのABNF [RFC4234]は
"a=rtcp-fb: " rtcp-fb-pt SP rtcp-fb-val CRLF
where rtcp-fb-pt is the payload type and rtcp-fb-val defines the type of the feedback message such as ack, nack, trr-int, and rtcp-fb-id. For example, to indicate the support of feedback of Picture Loss Indication, the sender declares the following in SDP
ここで、RTCP-FB-PTはペイロードタイプであり、RTCP-FB-ValはACK、NACK、TRR-INT、RTCP-FB-IDなどのフィードバックメッセージのタイプを定義します。たとえば、画像喪失の兆候のフィードバックのサポートを示すために、送信者はSDPで以下を宣言します
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 nack pli
In this document, we define a new feedback value "ccm", which indicates the support of codec control using RTCP feedback messages. The "ccm" feedback value SHOULD be used with parameters that indicate the specific codec control commands supported. In this document, we define four such parameters, namely:
このドキュメントでは、RTCPフィードバックメッセージを使用してコーデック制御のサポートを示す新しいフィードバック値「CCM」を定義します。「CCM」フィードバック値は、サポートされている特定のコーデック制御コマンドを示すパラメーターで使用する必要があります。このドキュメントでは、4つのそのようなパラメーターを定義します。
o "fir" indicates support of the Full Intra Request (FIR).
o "tmmbr" indicates support of the Temporary Maximum Media Stream
Bit Rate Request/Notification (TMMBR/TMMBN). It has an
optional sub-parameter to indicate the session maximum packet
rate (measured in packets per second) to be used. If not
included, this defaults to infinity.
o "tstr" indicates support of the Temporal-Spatial Trade-off
Request/Notification (TSTR/TSTN).
o "vbcm" indicates support of H.271 Video Back Channel Messages
(VBCMs). It has zero or more subparameters identifying the
supported H.271 "payloadType" values.
In the ABNF for rtcp-fb-val defined in [RFC4585], there is a placeholder called rtcp-fb-id to define new feedback types. "ccm" is defined as a new feedback type in this document, and the ABNF for the parameters for ccm is defined here (please refer to section 4.2 of [RFC4585] for complete ABNF syntax).
[RFC4585]で定義されているRTCP-FB-ValのABNFには、新しいフィードバックタイプを定義するためのRTCP-FB-IDと呼ばれるプレースホルダーがあります。「CCM」はこのドキュメントの新しいフィードバックタイプとして定義されており、CCMのパラメーターのABNFはここで定義されています（完全なABNF構文については[RFC4585]のセクション4.2を参照してください）。
rtcp-fb-val =/ "ccm" rtcp-fb-ccm-param
rtcp-fb-ccm-param = SP "fir" ; Full Intra Request
/ SP "tmmbr" [SP "smaxpr=" MaxPacketRateValue]
; Temporary max media bit rate
/ SP "tstr" ; Temporal-Spatial Trade-Off
/ SP "vbcm" *(SP subMessageType) ; H.271 VBCMs
/ SP token [SP byte-string]
; for future commands/indications
subMessageType = 1*8DIGIT
byte-string = <as defined in section 4.2 of [RFC4585] >
MaxPacketRateValue = 1*15DIGIT
The Offer/Answer [RFC3264] implications for codec control protocol feedback messages are similar to those described in [RFC4585]. The offerer MAY indicate the capability to support selected codec commands and indications. The answerer MUST remove all CCM parameters corresponding to the CCMs that it does not wish to support in this particular media session (for example, because it does not implement the message in question, or because its application logic suggests that support of the message adds no value). The answerer MUST NOT add new ccm parameters in addition to what has been offered.
オファー/回答[RFC3264] Codec制御プロトコルフィードバックメッセージへの影響は、[RFC4585]に記載されているものと類似しています。オファーは、選択したコーデックコマンドと適応をサポートする機能を示している場合があります。回答者は、この特定のメディアセッションでサポートしたくないCCMに対応するすべてのCCMパラメーターを削除する必要があります（たとえば、問題のメッセージを実装していないか、そのアプリケーションロジックがメッセージのサポートがNOを追加することを示唆しているため価値）。応答者は、提供されたものに加えて、新しいCCMパラメーターを追加してはなりません。
The answer is binding for the media session and both offerer and answerer MUST NOT use any feedback messages other than what both sides have explicitly indicated as being supported. In other words, only the joint subset of CCM parameters from the offer and answer may be used.
答えはメディアセッションの拘束力があり、OffererとReswersの両方が、双方がサポートされていると明示的に示したもの以外のフィードバックメッセージを使用してはなりません。言い換えれば、オファーと回答のCCMパラメーターの共同サブセットのみを使用できます。
Note that including a CCM parameter in an offer or answer indicates that the party (offerer or answerer) is at least capable of receiving the corresponding CCM(s) and act upon them. In cases when the reception of a negotiated CCM mandates the party to respond with another CCM, it must also have that capability. Although it is not mandated to initiate CCMs of any negotiated type, it is generally expected that a party will initiate CCMs when appropriate.
オファーまたは回答にCCMパラメーターを含めることは、当事者（提供者または回答者）が少なくとも対応するCCMを受け取ることができ、それらに基づいて行動できることを示していることに注意してください。交渉されたCCMの受容が当事者に別のCCMに対応することを義務付けている場合、その能力も必要です。交渉されたタイプのCCMを開始することは義務付けられていませんが、一般に、当事者は必要に応じてCCMを開始することが予想されます。
The session maximum packet rate parameter part of the TMMBR indication is declarative, and the highest value from offer and answer SHALL be used. If the session maximum packet rate parameter is not present in an offer, it SHALL NOT be included by the answerer.
TMMBR指示のセッションの最大パケットレートパラメーター部分は宣言的であり、オファーと回答からの最高値を使用するものとします。セッションの最大パケットレートパラメーターがオファーに存在しない場合、応答者に含まれてはなりません。
Example 1: The following SDP describes a point-to-point video call with H.263, with the originator of the call declaring its capability to support the FIR and TSTR/TSTN codec control messages. The SDP is carried in a high-level signaling protocol like SIP.
例1：次のSDPでは、H.263によるポイントツーポイントビデオコールについて説明します。コールのオリジネーターは、FIRおよびTSTR/TSTNコーデック制御メッセージをサポートする能力を宣言しています。SDPは、SIPのような高レベルのシグナル伝達プロトコルで運ばれます。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Point-to-Point call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
In the above example, when the sender receives a TSTR message from the remote party it is capable of adjusting the trade-off as indicated in the RTCP TSTN feedback message.
Example 2: The following SDP describes a SIP end point joining a video mixer that is hosting a multiparty video conferencing session. The participant supports only the FIR (Full Intra Request) codec control command and it declares it in its session description.
例2：次のSDPでは、マルチパーティビデオ会議セッションをホストしているビデオミキサーに参加するSIPエンドポイントについて説明します。参加者は、FIR（完全なリクエスト）Codec Controlコマンドのみをサポートし、セッションの説明で宣言します。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multiparty Video Call
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm fir
When the video MCU decides to route the video of this participant, it sends an RTCP FIR feedback message. Upon receiving this feedback message, the end point is required to generate a full intra request.
ビデオMCUがこの参加者のビデオをルーティングすることに決めたとき、RTCP FIRフィードバックメッセージを送信します。このフィードバックメッセージを受信すると、完全なリクエストを生成するにはエンドポイントが必要です。
Example 3: The following example describes the Offer/Answer implications for the codec control messages. The offerer wishes to support "tstr", "fir" and "tmmbr". The offered SDP is
例3：次の例では、コーデック制御メッセージに対するオファー/回答の影響について説明します。オファーは、「TSTR」、「FIR」、「TMMBR」をサポートしたいと考えています。提供されているSDPはです
-------------> Offer
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
a=rtcp-fb:* ccm tmmbr smaxpr=120
The answerer wishes to support only the FIR and TSTR/TSTN messages and the answerer SDP is
Answererは、FIRとTSTR/TSTNメッセージのみをサポートしたいと考えています。
<---------------- Answer
v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer
c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm tstr
a=rtcp-fb:98 ccm fir
Example 4: The following example describes the Offer/Answer implications for H.271 Video Back Channel Messages (VBCMs). The offerer wishes to support VBCM and the sub-messages of payloadType 1 (one or more pictures that are entirely or partially lost) and 2 (a set of blocks of one picture that are entirely or partially lost).
例4：次の例では、H.271ビデオバックチャネルメッセージ（VBCMS）のオファー/回答の影響について説明します。提供者は、VBCMとPayloadType 1（完全または部分的に失われた1つ以上の写真）と2（完全または部分的に失われた1つの画像のブロックのセット）のサブメッセージをサポートしたいと考えています。
-------------> Offer
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Offer/Answer
c=IN IP4 192.0.2.124
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1 2
The answerer only wishes to support sub-messages of type 1 only
回答者は、タイプ1のサブメッセージのみをサポートすることのみを希望します
<---------------- Answer
v=0
o=alice 3203093520 3203093524 IN IP4 otherhost.example.com
s=Offer/Answer
c=IN IP4 192.0.2.37
m=audio 47190 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53273 RTP/AVPF 98
a=rtpmap:98 H263-1998/90000
a=rtcp-fb:98 ccm vbcm 1
So, in the above example, only VBCM indications comprised of "payloadType" 1 will be supported.
したがって、上記の例では、「PayloadType」1で構成されるVBCM適応症のみがサポートされます。
The new value "ccm" has been registered with IANA in the "rtcp-fb" Attribute Values registry located at the time of publication at: http://www.iana.org/assignments/sdp-parameters
新しい値「CCM」は、http：//www.iana.org/assignments/sdp-parametersの出版時にある「RTCP-FB」属性値レジストリにIANAに登録されています
Value name: ccm Long Name: Codec Control Commands and Indications Reference: RFC 5104
値名：CCMロング名：コーデック制御コマンドと表示リファレンス：RFC 5104
A new registry "Codec Control Messages" has been created to hold "ccm" parameters located at time of publication at: http://www.iana.org/assignments/sdp-parameters New registration in this registry follows the "Specification required" policy as defined by [RFC2434]. In addition, they are required to indicate any additional RTCP feedback types, such as "nack" and "ack".
新しいレジストリ「Codec Controlメッセージ」は、http：//www.iana.org/assignments/SDP-Parametersの出版時にある「CCM」パラメーターを保持するために作成されました。[RFC2434]で定義されているポリシー。さらに、「NACK」や「ACK」などの追加のRTCPフィードバックタイプを示す必要があります。
The initial content of the registry is the following values:
レジストリの初期コンテンツは次の値です。
Value name: fir Long name: Full Intra Request Command Usable with: ccm Reference: RFC 5104
値名：fir long name：完全なリクエストコマンド使用可能：CCMリファレンス：RFC 5104
Value name: tmmbr Long name: Temporary Maximum Media Stream Bit Rate Usable with: ccm Reference: RFC 5104
値名：TMMBRロング名：一時的な最大メディアストリームビットレート使用可能：CCMリファレンス：RFC 5104
Value name: tstr Long name: Temporal Spatial Trade Off Usable with: ccm Reference: RFC 5104
値名：TSTRロング名：時間空間トレードオフ使用可能：CCMリファレンス：RFC 5104
Value name: vbcm Long name: H.271 video back channel messages Usable with: ccm Reference: RFC 5104
値名：VBCMロング名：H.271ビデオバックチャネルメッセージ使用可能：CCMリファレンス：RFC 5104
The following values have been registered as FMT values in the "FMT Values for RTPFB Payload Types" registry located at the time of publication at: http://www.iana.org/assignments/rtp-parameters
次の値は、http：//www.iana.org/assignments/rtp-parametersの出版時にある「RTPFBペイロードタイプのFMT値」レジストリのFMT値として登録されています
RTPFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
Reserved 2 [RFC5104]
TMMBR Temporary Maximum Media Stream Bit 3 [RFC5104]
Rate Request
TMMBN Temporary Maximum Media Stream Bit 4 [RFC5104]
Rate Notification
The following values have been registered as FMT values in the "FMT
Values for PSFB Payload Types" registry located at the time of
publication at: http://www.iana.org/assignments/rtp-parameters
PSFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
FIR Full Intra Request Command 4 [RFC5104]
TSTR Temporal-Spatial Trade-off Request 5 [RFC5104]
TSTN Temporal-Spatial Trade-off Notification 6 [RFC5104]
VBCM Video Back Channel Message 7 [RFC5104]
Tom Taylor has made a very significant contribution to this specification, for which the authors are very grateful, by helping rewrite the specification. Especially the parts regarding the algorithm for determining bounding sets for TMMBR have benefited.
トム・テイラーは、この仕様に非常に重要な貢献をしました。この仕様は、仕様の書き換えを手伝うことで非常に感謝しています。特に、TMMBRの境界セットを決定するためのアルゴリズムに関する部分が恩恵を受けています。
The authors would like to thank Andrea Basso, Orit Levin, and Nermeen Ismail for their work on the requirement and discussion document [Basso].
著者は、Andrea Basso、Orit Levin、およびNermeen Ismailに、要件とディスカッションの文書[Basso]に関する作業に感謝します。
Versions of this memo were reviewed and extensively commented on by Roni Even, Colin Perkins, Randell Jesup, Keith Lantz, Harikishan Desineni, Guido Franceschini, and others. The authors appreciate these reviews.
このメモのバージョンはレビューされ、Roni Even、Colin Perkins、Randell Jesup、Keith Lantz、Harikishan Desineni、Guido Franceschiniなどによって広範囲にコメントされました。著者はこれらのレビューに感謝しています。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-Time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル"、RFC 4585、2006年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[Basso] Basso, A., Levin, O., and N. Ismail, "Requirements for transport of video control commands", Work in Progress, October 2004.
[Basso] Basso、A.、Levin、O。、およびN. Ismail、「ビデオ制御コマンドの輸送の要件」、2004年10月、進行中の作業。
[AVC] Joint Video Team of ITU-T and ISO/IEC JTC 1, Draft ITU-T Recommendation and Final Draft International Standard of Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC 14496-10 AVC), Joint Video Team (JVT) of ISO/IEC MPEG and ITU-T VCEG, JVT-G050, March 2003.
[AVC] ITU-TおよびISO/IEC JTC 1の共同ビデオチーム、ITU-Tの推奨ドラフトおよび最終ドラフト共同ビデオ仕様の国際標準草案（ITU-TRec。H.264| ISO/IEC 14496-10 AVC）、2003年3月、JVT-G050、ISO/IEC MPEGおよびITU-T VCEGの共同ビデオチーム（JVT）。
[H245] ITU-T Rec. H.245, "Control protocol for multimedia communication", May 2006.
[H245] itu-t rec。H.245、「マルチメディア通信のための制御プロトコル」、2006年5月。
[NEWPRED] S. Fukunaga, T. Nakai, and H. Inoue, "Error Resilient Video Coding by Dynamic Replacing of Reference Pictures", in Proc. Globcom'96, vol. 3, pp. 1503 - 1508, 1996.
[Newpred] S. Fukunaga、T。Nakai、およびH. Inoue、「リファレンス写真の動的置換によるエラーの回復力のあるビデオコーディング」、Proc。Globcom'96、vol。3、pp。1503-1508、1996。
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[SRTP] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Leal-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC2032] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.
[RFC2032] Turletti、T。およびC. Huitema、「H.261ビデオストリームのRTPペイロード形式」、RFC 2032、1996年10月。
[SAVPF] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", Work in Progress, November 2007.
[Savpf] Ott、J。およびE. Carrara、「RTCPベースのフィードバック（RTP/SAVPF）のセキュアなRTPプロファイルを拡張しました」、2007年11月、Work in Progress。
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3525] Groves、C.、Pantaleo、M.、Anderson、T.、およびT. Taylor、「Gateway Control Protocol 1」、RFC 3525、2003年6月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（TFRC）：プロトコル仕様」、RFC 3448、2003年1月。
[H.271] ITU-T Rec. H.271, "Video Back Channel Messages", June 2006.
[H.271] itu-t rec。H.271、「ビデオバックチャンネルメッセージ」、2006年6月。
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[RFC3890] Westerlund、M。、「セッション説明プロトコル（SDP）の輸送独立帯域幅修飾子」、RFC 3890、2004年9月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、 "RTPペイロード冗長なオーディオデータの場合」、RFC 2198、1997年9月。
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, August 2006.
[RFC4587] Even、R。、「H.261ビデオストリームのRTPペイロード形式」、RFC 4587、2006年8月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117] Westerlund、M。およびS. Wenger、「RTP Topologies」、RFC 5117、2008年1月。
[XML-MC] Levin, O., Even, R., and P. Hagendorf, "XML Schema for Media Control", Work in Progress, November 2007.
[XML-MC] Levin、O。、Even、R。、およびP. Hagendorf、「XML Schema for Media Control」、2007年11月、進行中の作業。
Authors' Addresses
著者のアドレス
Stephan Wenger Nokia Corporation 975, Page Mill Road, Palo Alto,CA 94304 USA
Stephan Wenger Nokia Corporation 975、Page Mill Road、Palo Alto、CA 94304 USA
Phone: +1-650-862-7368
EMail: stewe@stewe.org
Umesh Chandra Nokia Research Center 975, Page Mill Road, Palo Alto,CA 94304 USA
Umesh Chandra Nokia Research Center 975、Page Mill Road、Palo Alto、CA 94304 USA
Phone: +1-650-796-7502
Email: Umesh.1.Chandra@nokia.com
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
マグナスウェスターランドエリクソンリサーチエリクソンAB SE-164 80ストックホルム、スウェーデン
Phone: +46 8 7190000
EMail: magnus.westerlund@ericsson.com
Bo Burman Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
Bo Burman Ericsson Research Ericsson AB SE-164 80ストックホルム、スウェーデン
Phone: +46 8 7190000
EMail: bo.burman@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。