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)
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勧告に関連するメッセージです。 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勧告を運ぶために意図されたメッセージのために特に当てはまります。ビデオバックチャネルメッセージ用の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]用語で、MCUは、ミキサ及び翻訳を含みます。ほとんどの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.
ここで定義されたメッセージの一部は、その中で彼らは受信および/またはメッセージ受信者の行為を指示されているメッセージのエミッタへの明示的な通知を必要としない、唯一の楽しみです。その他のメッセージは1つが制御目的に有用であるとして見ることができる双方向通信モデルにつながる、応答を必要とします。しかし、それは一般的な制御プロトコルにRTP制御プロトコル（RTCP）を開くためにこのメモの意図ではありません。すべての言及のメッセージは、その値が大きく遅れて減少するという意味で、比較的厳格なリアルタイム制約を持っています。同じ目的のために使用される場合、このようなセッション開始プロトコル（SIP）[RFC3261]、望ましくないような、より伝統的な制御プロトコル手段を利用します。このソリューションは、代わりにこのメモで定義されているものと同様の意味を持つXMLメッセージを転送するSIP情報を使用して[XML-MC]、「メディアコントロールのための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 - フルイントラ要求MCU - マルチポイントコントロールユニットMPEG - ピクチャー・エキスパート・グループ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:
メッセージ：この仕様で定義された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勧告と整列していることに留意されたいです。 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.
デコーダリフレッシュポイント：完全に既知の状態にデコーダをリセットする一つまたは複数の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.
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).
デコーダ・リフレッシュ・ポイントはまた、インバンド搬送される（ビデオ圧縮規格に応じて、または同等の）画像層の上のすべてのヘッダー情報を含みます。 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）（ともいくつかのケースでは、このような再送信または前方誤り訂正（FEC）情報などの情報を修復）で標識したRTPパケットのストリーム。
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.
総メディアビットレート：メディアストリームで転送秒当たりの総ビット、観察者が選択したプロトコル層で測定され、アプリケーションに依存する長さは、合理的な時間スケールにわたって平均しました。一般に、メディア送信者とメディア受信機は、彼らがため、伝送経路に沿ってパケットごとのオーバヘッドの変化に、第二の異なる基準プロトコル層を選択し、そしてたかもしれない最初のため、同じストリームに対して異なる総メディアビットレートを観察します。ビットレートの平均との目標は、非常に短い時間スケール上の任意のバースト（例えば、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.
最大総メディアビットレート：特定の受信機で、その選択されたプロトコル層用の所与のメディア・ストリームの総メディアビットレートの上限。この値は、受信したメディアストリーム上で測定することができないことに注意してください。代わりに、それはそのようなサービス（QoS）の交渉やローカルリソース制限の品質などの他の手段を介して、計算または決定する必要があります。また、この値は（アプリケーションのために妥当である時間スケールで）の平均であり、それはメディアストリームのパケットによって見られる瞬間ビットレートと異なっていてもよいことに注意。
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ヘッダーを含む）レベルまで層。オーバーヘッドは、任意のレイヤ2つのヘッダー、任意の貢献ソース（CSRCs）、RTPパディング、およびRTPヘッダ拡張を、例えば、IP、UDP、及び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
ネットメディアビットレート：メディアストリームによって運ばれるビットレート、オーバーヘッドのネット。すなわち、毎秒のビットは、符号化されたメディア、該当ペイロードヘッダ、およびRTPパケットに配置された任意の直接関連するメタペイロード情報によって占め。後者の典型的な例は、RFC 2198 [RFC2198]を使用することによって提供される冗長データです。総メディアビットとは異なり、なお
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.
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タプルの集合、そのメディア送付者のための実行可能領域を定義する所定のメディアの送信者に受信されたすべてのもの、から選択されます。メディア送信者は、このような決定または反復して、現在のバウンディングセットを近似し、（TMMBN）メッセージの一時的な最大のメディアストリームビットレート通知にメディアレシーバに戻って設定されたレポートするセクション3.5.4.2でそのようなアルゴリズムを使用しています。
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.
このセクションでは、さまざまなビデオとメディア制御メッセージのモチベーションや使用方法を説明します。ビデオ制御メッセージは、長い間議論されてきた、と要求文書は、[バッソ]まで描かれました。その文書の有効期限が切れています。しかし、我々は動機と要件を提供するために、それの関連するセクションを引用します。
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.
提案されているフィードバックメッセージのための可能な用途の数があります。私たちは、ユースケース・バッソらを見することから始めましょう。 【バッソ]提案しました。ユースケースの一部が再公式化されているとのコメントが追加されました。
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.ユースケース4はAVPF [RFC4585]で定義されており、ここでは再生されないようピクチャーロス表示（PLI）に適用されます。
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ユースケース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つを選択し、ストリームトランスレーティングを最小限に抑えながら、すべての参加者に可能な最高のビットレートを提供しようとします。これを達成する一つの方法は、各エンドポイントによって受け入れられる最大ビットレートを使用して、エンドポイントとのセッションをセットアップすることで、ミキサによって使用される呼受付方法により受け付け。セットアップセッション中に交渉してきたものを、以下の最大のメディアストリームのビットレートを下げるコマンドによって、ミキサーはすべて受け入れたビットレートの最低にエンドポイントによって送信される最大ビットレートを減らすことができます。エンドポイントが参加及び離脱、または、ネットワークの輻輳に最低受け入れられ、ビットレートが変化すると、ミキサーは、エンドポイントが新しい値に一致するように、それらのストリームを送信可能な制限を調整することができます。ミキサは、特定のメディア・ストリームのためのセッションセットアップで交渉された最大ビットレート以下である新たな最大ビットレートを要求し、リモートエンドポイントは、それがサポートできる実際のビットレートで応答することができます。
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:
絵バッソ、ら、カバー我々は予見ほとんどのアプリケーションを策定。しかし、我々は、2つの追加のユースケースでリストを拡張したいと思います：
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）を使用することがNEWPRED [NEWPRED]として1997年に導入し、そして現在では広く展開されています。 RPSが使用中である場合、単純化入れて、受信機は、将来の予測に使用されるべき参照画像を示し、送信側にフィードバックメッセージを送信することができます。 AVPFは、そのようなメッセージを搬送するための機構を含んでいる（[NEWPRED]。同様に、フィードバックの他の形態を言及）が、メッセージに従うべきコーデックと記載する構文に指定しませんでした。最近では、ITU-Tは、録音を完成しました。 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が物理的に分解されている場合、メディアパスを使用することは、メディア制御プロトコルの拡張の必要性（例えば、メディア・ゲートウェイ制御中（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.
デコーダリフレッシュポイント、特に、イントラまたは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.
マルチキャストでの使用が可能です。ただし、コマンドの凝集が推奨されます。 2回最長往復時間（RTT）は、公知の、プラス遅延を送信任意AVPF誘導性RTCPパケット内 - - デコーダ・リフレッシュ・ポイントを送信した後に密接要求を受信する受信機、メディアことを保証する第2の要求メッセージを待つ必要があります受信機は、以前に配信デコーダリフレッシュポイントによって提供されていません。指定した遅延の理由は、不必要なデコーダのリフレッシュポイントを送信しないようにすることです。他の参加者の要求は機内彼らにあったセッション参加者は、独自のリクエストを送信している可能性があります。その他の要求についての知識がなくても送信された可能性があり、それらの要求を非表示にすることで、この問題を回避することができます。
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の送信者は、セッション内のメディアの送信者ごとに任意の時点で未解決の複数の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の受信機（すなわち、メディア送付者）がデコーダ・リフレッシュ・ポイントの送達を確実にするために、相補的に動作します。それはFIR以上2 * RTTの繰り返しを受信した場合、それはデコーダリフレッシュポイントを送信した後に、それは新しいデコーダのリフレッシュポイントを送信しなければなりません。二つの往復時間は、デコーダリフレッシュポイントの時間が到達すると、メディアの送信者によって検出され、リクエスタにし、FIRの繰り返しの終わりのために戻って到着することができます。
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コマンドを生成することが必要になることがあります。信頼性の観点から、二つの脚部（/ MCUをミキサーにFIR-要求エンドポイント、およびミキサー/ MCUは、リフレッシュ点発生エンドポイントをデコーダに）互いに独立に処理されます。
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再招待もヘビーかつ合理的なユーザー体験を可能にするには遅すぎます。例えば、リモートユーザーがスライダーで時間的/空間トレードオフを選択するユーザインタフェースを考えます。すべてのスライダーの動きに即座にフィードバックが合理的なユーザーエクスペリエンスのために必要とされます。 SIP再INVITE [RFC3261]（TSTR / TSTN機構と比較して）少なくとも二つの往復以上を必要とし、プロキシや他の複雑な機構を含むことができます。新しいトレードオフが最終的に選択されるまでさえうまく設計されたシステムでは、それはそう秒以上かかることがあります。さらに、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に搬送として提案トレードオフを受信したことに、エンドポイントの反応はありません。我々は唯一の（またはTSTRによって搬送トレードオフに基づいていてもいなくてもよい）独自の基準によって選択された新たなトレードオフを運ぶ、TSTNを送信することによって、それに応答するTSTRメッセージの受信を必要とします。言い換えれば、TSTRで送信されたトレードオフは、より多くの何も非結合勧告ではありません。
Three TSTR/TSTN scenarios need to be distinguished, based on the topologies described in [RFC5117]. The scenarios are described in the following subsections.
三つのTSTR / TSTNシナリオは[RFC5117]で説明トポロジに基づいて、区別する必要があります。シナリオは以下のサブセクションで説明されています。
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).
この最も些細なケース（TOPO-ポイントツーポイント）では、メディアの送信者は、通常、自身の能力の対象に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-翻訳によるRFC 3550の翻訳モデルをTOPO-マルチキャストに応じて、または次のように使われています。これらのケースでは、異なる受信機からの非同期の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-ミキサー）では、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 unimplementableトレードオフを要求するメッセージの送信の反復を回避することができます。
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勧告。 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は、（このメモで指定されるように後者）は概ね対応AVPFまたはコーデックコントロールメッセージ（CCMS）、現在H.271で定義されたメッセージを簡単に、単純化された概要を提供し、そのマルチキャスト安全性の我々の現在の知識の指示。
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.
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.
セクション5に概説されるようにH.271フィードバックメッセージを利用1.実装は、輻輳制御の原則に準拠していなければなりません。
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.
[RFC4585]にし、代わりに[H.271]で定義された同様のメッセージのこのメモで定義されるように前記実装は、IETFネイティブメッセージを利用すべきです。類似したメッセージの我々の現在の理解は、上記表1に記載されています。与えられたアプリケーションとビデオ圧縮規格のために、前述の「類似性」の表が示すものとは対照的に、与えられていない、ことを明確に理解されている場合は、上記のSHOULD声明からそらすための一つの良い理由は次のようになります。
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.別の状態。多くの環境では、すべてのメディアの受信機のデコーダ状態は、時間内の任意の点で同一であることを保証できません。状態のような可能なミスアライメントのための最も明白な理由は、多くのメディアレシーバーの唯一の道で発生損失です。しかしながら、このような最近のような他のそれほど明らかではない理由が存在する（それがマルチキャストグループに参加するか、追加のミキサ出力を介してである）多地点会議に参加します。異なる状態が潜在的に矛盾H.271メッセージを発行するメディアレシーバーを導くことができる（またはメディア送信者によって観察した場合、他のメディアレシーバーのために有用ではないH.271メッセージを発行つのメディア受信機）。これらの矛盾するメッセージへのメディア送信者の素朴な反応は予測できないと迷惑な結果につながることができます。
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で説明した基本的なメカニズムを越えて行く必要があるかもしれません。例えば、受信機は、しばしば、それがメディアストリームから受信した情報に基づいて要求を生成（又は遅延）を控えることが要求されます。例えば、それはイントラ/ 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.
大きなマルチキャストグループ内の非マルチキャスト安全なメッセージ（例えば、受信されたピクチャ/スライスのH.271タイプ0肯定ACK）を使用する場合4.は、メディア受信機は、おそらく遅延、あるいは、これらのメッセージを送信省略することを余儀なくされるであろう。 （それが正しく受信されたが）、データが正常に受信されていないように、メディアの送信者の場合、これは見て、単純に実装されたメディアの送信者はどこにすべきでないこれらの知覚の問題に反応します。
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、「木材」）を一時最大メディアストリームのビットレート要求を使用するために、以下、提供された値（セクション2.2を参照） 。一時的な最大のメディアストリームビットレートの通知（TMMBN）は、さらに、メディアの送信者を制限しないでしょうTMMBRsを抑制するために、参加者を助けるために、それが受信したTMMBR-定義された制限の中で最も制限サブセットのメディア送信者の現在のビューが含まれています。 TMMBR / TMMBNメッセージの主な用途は、又はTOPO-ミキサー翻訳をTOPOするだけでなく、TOPO-ポイントツーポイントに対応し、MCUまたはミキサー（ユースケース6）とシナリオです。
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で定義されるように）最大の総メディアビットレートです。第二の成分は、メディア受信機がその選択された基準プロトコル層で、このメディア・ストリームについて観察たパケットごとのオーバヘッドです。
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との間で変換する二つの間にゲートウェイは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.
推論は、以下の参加者は、シグナリングプロトコルを使用して、セッションの最大ビットレートを交渉していることを前提としています。この値は、ポイント・ツー・ポイント、マルチキャスト、又は翻訳の場合には、例えば、グローバルとすることができます。それはまた、参加者およびピアまたはミキサの間にローカルであってもよいです。いずれの場合においても、シグナリングにネゴシエートビットレートは、参加者が（depacketizeおよび復号）を扱うことができるように保証するものです。実際には、参加者の接続性もネゴシエートされた値に影響を与える - それは1のネットワークインタフェースがサポートされていない総メディアビットレートを交渉するあまり意味がありません。
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を指定し、プラス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.
このセクションでは、動作の非公式の説明はセクション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メッセージを使用してメディアの送信者にこれらの二つの量のその初期推定値を報告します。全体的なメッセージトラフィックは同じ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によって報告されたバウンディングセット内のタプルのいずれか所有していない場合は、その現在の推定（最大総メディアビットレート、オーバーヘッド）タプルはバウンディングセットを入力するかどうかを決定するためにメディア送信元と同じアルゴリズムを適用しますメディア送信者に知られている場合。もしそうなら、それは送信者にタプル値を報告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.
代替的に、メディア受信機が報告されたバウンディングセット内のタプルのいずれかを所有している場合、それはそれ自身のタプル値の変化のその推定値としてそのような時間まで、何のアクションもとりません。その際、変更された値を報告するために、メディアの送信者に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.
メディア受信機は所有者と一つ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.
唯一のメディア受信機がある場合、それは自身のTMMBRに応答して第1 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つの変数がリンクされています。具体的には、RTPペイロードのために利用可能なビットレートは、ビットレートを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
受信機A：TMMBR_max合計のBR = 35 kbpsの、TMMBR_OH = 40バイト受信B：TMMBR_max合計BR = 40 kbpsの、TMMBR_OH = 60のバイト
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_A = TMMBR_max総BR_A - PR * TMMBR_OH_A * 8 ...（1）
Max_net media_BR_B = TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ... (2)
Max_net media_BR_B = TMMBR_max総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のため、これらの計算は、受信機Aは、このパケットのレートを制限するものであることを示唆しているMax_net media_BR_A = 28600のBPSとMax_net media_BR_B = 30400のBPSをもたらします。しかし、特定のPRに受信機Bが限定1となるで切り替え点があります。切り替えポイントはMax_media_BR_Bに等しいMax_media_BR_Aを設定し、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が得られます。すなわち、毎秒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タプルがメディアの送信者に制限を提供している可能性があります。第二に、与えられたタプルは、メディア送信元に対する限定となるであろうかどうかを判断できるようにする任意のセッション参加者（メディア送信者と受信機）が必要である、または既に与えられた制約のセットが与えられた値よりも厳しい場合。この決意をする能力がない場合には、TMMBRsの抑制は動作しません。
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タプルは、直線の方程式とみなすことができる（参照、式（1）及び（2））のパケットレートがY軸に沿ってX軸および正味ビットレートに沿って存在する空間です。 TMMBRタプルの完全なセットに対応する行のセットの下方エンベロープは、一緒になってXおよびY軸を有する、ポリゴンを規定します。このポリゴン内にあるポイントはTMMBR制約のすべてを満たすパケットレートとビットレートの組み合わせです。この領域内の最も高い実現可能なパケットレートは、境界ポリゴンが存在する場合、シグナリングによって提供されるX軸または（秒あたりのパケット数で測定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は、以下の第三のタプルCは、境界ポリゴンの外側にあるとメディアレート及びパケットレートとの間の可能なトレードオフを決定する際に、したがって無関係であるTMMBRタプルAとBによって形成される境界多角形を示しています。 ss..s標識された行は、セッションセットアップ中にシグナリングすることによって得られたセッションの最大パケット速度（SMAXPR）によって課されるパケットレートの制限を表します。図1において、タプル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切片であり、タプル最大総メディアビットレートに等しい値を有します。
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のタプルを処理するとき、1が並べ替えるとオーバーヘッドが増加する順でタプルを処理しなければならないという結論につながります。特定のタプルがバウンディングセットに追加された後、すべてのタプルが既に選択されていないと境界ポリゴンの次側よりも（すなわち、対応する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切片を有します。すなわち、対応する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.
さらに二つの観察は、アルゴリズムを完了します。明らかに、左から移動し、境界ポリゴン（辺の連続する対の間、即ち、交点）の連続した角が連続的により高いパケットレートで横たわります。一方、再び左から移動し、バウンディングセットを構成する各連続ラインは、より低いパケット速度で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タプルの二つのリスト、候補リスト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つまたは複数のTMMBRsを受信したとき、それは最初の時間のためのバウンディングセットを決定する前に、このアルゴリズムは、メディアの送信者によって使用されます。
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.候補リスト内の複数のタプルが同じオーバーヘッド値を有し、最も低い最大総メディアビットレート値を持つすべてが、1つを廃棄します。
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)
最大PR = TMMBR最大合計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).
前記式（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).
算出値PRが選択されたリストの最後のタプルのために記憶さ交点値以下である場合7.、選択されたリストの最後のタプルを破棄して（同じ現在の候補を保持する）ステップ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.
選択されたリストは、アルゴリズムが最終的に（ない場合は、直ちに）、ステップ8にフォールスルーしなければならないことを意味し、このプロセスによって空にすることはないだろうというステップ3保証で選択したリストYの初期メンバーの選択ことに注意してください。
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）を用いて計算された最大パケットレートとしての最大パケット速度を計算します。
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:
以前のアルゴリズムには、選択リストには、以前に作成されていなかった最初のケースを、カバーしました。また、メディアのみの送信者に適用されます。以前に作成した選択リストは、メディアの送信者やメディアレシーバーのいずれかで利用可能である場合には、他の二つのケースが考えられます。
o when a TMMBR tuple not currently in the selected list is a
candidate for addition;
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.
最初の観察は、新しい/変更候補が新たな選択リストの一部になった場合、結果はゼロまたはそれ以上の他のタプルがリストから削除させるようにしてもよいということです。他の複数のタプルがドロップされた場合は、ドロップされたタプルは連続します。これは、既存の境界ポリゴンからの一連のセグメントをカットする新しい行を可視化することにより、幾何学的に確認することができます。カットオフセグメントは、次の1つ、オーバーヘッド値によって順序付けられたリスト内の連続組の幾何学的等価物に接続されています。いずれかの方向にドロップされたセット以外にも、以前の選択リストにあったタプルのすべてが更新さ1になります。第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アートの限界は、図に示すために、これは困難になります。それは（タプルCより高いオーバーヘッド値を有していた）より急峻な勾配を有していたが、それでもラインaa..aがラインbb..bと交差する場所を越えラインaa..aを交差した場合、図1のラインcc..cは一例であろう。
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を考慮し、ラインcc..c外部aa..a移動するラインポイントへのタプルA増加の最大総メディアビットレートを仮定する。タプル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に対応するための機会を持っていたまで、その送信レートを上げからメディア送信者リフレインする必要があります。所定の一例では、この遅延は、タプルAの緩和が実際℃で容量を超える速度でメディアを送信する試みをもたらさないことを確実にします
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-ミキサーに示すように小ミキサベースのマルチパーティ会議が進行中であると仮定する。すべての参加者は、このセッションを使用することができ、共通の最大ビットレートを交渉しました。会議は、参加者とミキサとの間のユニキャスト経路の数で動作します。これらの経路の各々の輻輳状況は、例えば、RTCP受信機レポート（RRS）またはトランスポートプロトコル、例えばデータグラム輻輳制御プロトコル（DCCP）[RFC4340]を利用し、当該ミキサによって参加者によって監視することができます。しかし、任意の参加者が他の参加者への接続の混雑状況を認識しません。この文書で説明したものと同様のメカニズムなしで、さらに悪いことに、独自のレシーバレポートを鍛造の短い遅くするために、メディアの送信者に通知するための標準化の手段を持っていない（それが管理するすべての接続の混雑状況を認識している）ミキサー（ました）は望ましくありません。原則的に、このような状況に直面ミキサは、輻輳を検出し接続することを意図薄い又はトランスコードストリームに義務付けられています。
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.
実際には、残念ながら、メディア対応のストリーミング間伐は非常に困難かつ面倒な操作であり、望ましくない遅延が追加されます。メディアを認識しない場合、それは容認できない再現メディアの品質に非常に迅速につながります。したがって、ミキサへの接続であっても、輻輳の不在下で送信者を遅くする手段が望ましいです。
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を使用します。スロー輻輳制御後の利用可能な帯域幅/ビットレート/容量およびパケットレートをここで参照します。
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.
即時の反応ツールは迅速な制御機構によってフォローアップとしてストリーム間伐の使用は、メディアの品質と混雑に対抗する必要性との間に合理的な妥協点であるように思われます。
3.5.4.4. Use of TMMBR in Point-to-Multipoint Using Multicast or Translators
3.5.4.4。ポイントツーマルチポイントのマルチキャストや翻訳者を使用中TMMBRの使用
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-マルチキャストまたはTOPO-翻訳に対応し、RTCP資源レコードがグローバルに送信されます。これは、すべての参加者がメディアタイムスケールでは、そのような渋滞などの伝送問題を検出することができます。すべてのメディアの送信者は、すべてのメディアレシーバーの混雑状況を認識しているとして、前節の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で定義されるように、すなわち、可能領域の外側にある線を定義する）未満厳密であれば、マルチキャストシナリオでは、それは、彼らが持っている可能性の要求を抑制するために、他のすべての参加を可能にします。維持のみ通知するタプルのバウンディングセットは、小さなメッセージサイズとメディアの送信者の状態が可能になります。メディア送信者にのみタプルのバウンディングセットの現在の所有者のSSRCsの状態を保持します。他のすべての要求とそれらのソースが保存されません。バウンディングセットが確立されると、新しい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]の。 AVPFのセクション6.2で定義された一時的な最大のメディアストリームビットレート要求（TMMBR）と一時的な最大のメディアストリームビットレートの通知（TMMBN）は、「トランスポート層フィードバックメッセージ」です。
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].
新しいフィードバックメッセージは、セクション6.2およびAVPF仕様[RFC4585]の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 4587によって廃止された[RFC4587]）[RFC2032] RFC 2032に、例えば、ビデオフォーマットのための初期RTPペイロード形式で導入しました。しかし、この仕様は、最初に、そのメッセージのいくつかのための2ウェイハンドシェイクを示唆しています。この導入は、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:
このメモでは、2ウェイハンドシェイクが唯一のメッセージのために導入されています。
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のセクション6.1 [RFC4585]で指定されるように、トランスポート層フィードバックメッセージは、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では、このカテゴリーの一つのメッセージが定義されていました。このメモは、さらに2つのようなメッセージを指定します。次のようにそれらはフィードバックメッセージタイプ（FMT）パラメータによって識別されます。
Assigned in AVPF [RFC4585]:
[RFC4585]でAVPFを割り当て：
1: Generic NACK 31: reserved for future expansion of the identifier number space
1：汎用NACK 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：予約済み（下記の注を参照）3：一時最大メディアストリームビットレート要求（TMMBR）4：一時的な最大のメディアストリームビットレート通知（TMMBN）
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.
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フィールドは、一つ以上のFCIエントリーを含まなければなりません。
The Feedback Control Information (FCI) consists of one or more TMMBR FCI entries with the following syntax:
フィードバック制御情報（FCI）は、次の構文を使用して、一つ以上の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仮数（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:
ビット毎秒の最大総メディアビットレート（MxTBR）値は、以下のようにMxTBR指数（EXP）と仮数から計算されます。
MxTBR = mantissa * 2^exp
MxTBR =仮数* 2 ^ expの
This allows for 17 bits of resolution in the range 0 to 131072*2^63 (approximately 1.2*10^24).
これは、範囲の分解能の17ビット0~63 ^ 2 * 131072まで（約1.2×10 ^ 24）を可能にします。
The length of the TMMBR feedback message SHALL be set to 2+2*N where N is the number of TMMBR FCI entries.
TMMBRフィードバックメッセージの長さは、NがTMMBR FCIエントリーの数であり、2 + 2 * Nに設定されます。
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（新しい）pckt_OH * * 1月16日+ avg_OH（旧）16分の15 =、
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」が使用されず、設定されなければなりません特定のTMMBR FCIエントリ内で0に、FCIフィールドに「メディアソースのSSRCは、」タプルが適用されるメディアの送信者を表します。これは、報告企業が複数のFCIエントリーを使用して、単一の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.
メディアレシーバセクション3.5.4.2から増分アルゴリズム又は厳しい同等、メディア受信者を適用した後、Oメディア受信機は、そのメディアの送信者から受信した最新のTMMBNメッセージ内境界タプルの源として同定されていない場合そのメディアの送信者に関連するタプルはバウンディングセットに属していると判定されます。
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.
何の一時的な最大のメディアストリームビットレート通知（TMMBN）FCIは、次のRTCPパケットの送信時にメディアの送信者から受信されていない場合。TMMBR FCIエントリーは、後続のTMMBRメッセージに繰り返されてもよいですTMMBR FCIエントリーのビットレート値は、次の1つの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再招待。
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送信間隔と比較して）小さい間隔にわたるTMMBRsを蓄積してもよいです。
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.
それはタプルのバウンディングセットを決定したら、それは対処する必要があるかもしれないとして、メディアの送信者は、低い総メディアストリームのビットレートを生成するためにこれらのタプルが記述パケットレートおよび実行可能領域内のネットメディアビットレートを任意に組み合わせて使用してもよい（MAY）混雑状況やその他の制限要因。より多くの議論のためのセクション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パケットの送信を介してこれを示すか、外部のシグナリングチャネルを使用して、セッションを終了してもよいです。メディア送信者はバウンディングセットでのタプルの所有者がセッションを残していると判断した場合、メディアの送信者は、境界タプルのが、タプルを削除出発した所有者に属すると以前に決定されたセットを含む新しい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メッセージに相当するものを開始することができます。タプルの所有者は、それによって他の参加者からの不要なTMMBRメッセージを避け、送信されている結果として、TMMBNは、メディアソース自体を示します。しかし、メディアの送信者が変更された制限に気付いた他の参加者、のように、タプルを変更するには、対応する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を送出します。第二の場合には、無条件に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.
TMMBNメッセージが失われる場合B）同様に、対応する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.
競合する複数のTMMBRメッセージが異なるセッション参加者によって送信された場合c）に、アルゴリズムは、アカウントにこれらのメッセージのすべてを取って適用することができ、そして得られた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.
複数のセッションの参加者が同時に同じタプル成分値とTMMBRメッセージを送信するために発生した場合d）には、バウンディングセットに取り込まれ、それらのタプルのどの問題ではありません。負けセッション参加者は、そのタプルがバウンディングセットに入らないよう、アルゴリズムを適用した後、決定しますので、そのTMMBRの送信を停止します。
It is important to consider the security risks involved with faked TMMBRs. See the security considerations in section 6.
偽造TMMBRsに関わるセキュリティ上のリスクを考慮することが重要です。セクション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.
メディア翻訳者とミキサーが受信し、それらが受信機に特定のメディア・ストリームを提供してチェーンの一部であるとしてTMMBRメッセージに応答する必要があります。ミキサーやトランスレータはTMMBR上でローカルに行動するので、それはそうしたことを示すためにTMMBNを発生させることができます。あるいは、メディア変換の場合には、要求を転送することができ、またはミキサーの場合には、それ自身のいずれかを生成し、前方に渡します。後者の場合、ミキサは、要求を処理していることを示すために、元のリクエスタに戻すTMMBNを送信する必要があります。
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仮数（17ビット）の符号なし整数として最大総メディアビットレート値の仮数。
Measured Overhead (9 bits): The measured average packet overhead value in bytes represented as an unsigned integer [0..511].
符号なし整数[0..511]のように表されるバイトで測定された平均パケットオーバーヘッド値：オーバーヘッド（9ビット）を測定しました。
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メッセージの長さは、NがTMMBN FCIエントリの数である2 + 2 * Nに設定されます。
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.
このフィードバックメッセージは、一つ以上のTMMBRメッセージが受信されたこと、または所有者がセッションを離れたこと任意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.
メディア送付者が境界タプルの「所有者」は、そのタプルがバウンディングセットから削除され、セッションを残している、メディア送付者が残りの境界を示すTMMBNメッセージを送信しなければならないことを決定するセクション4.2.1.2に示されているようにタプル。残っバウンディングタプルが存在しない場合は、任意の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で説明したように、ミキサーまたは翻訳者はそれらによって処理さSSRCsための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のセクション6.1で指定された[RFC4585]、ペイロード特有の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:
AVPF [RFC4585]は3ペイロード特有のフィードバックメッセージと一つのアプリケーション層フィードバックメッセージを定義します。このメモは、4つの追加のペイロード特有のフィードバックメッセージを指定します。次のようにすべてがFMTパラメータによって識別されます。
Assigned in [RFC4585]:
[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フィールドは、一つ以上の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）は、図に示されている内容は一つ以上のFCIエントリー、から成る4 FIRフィードバックメッセージの長さがNである2 + 2 * 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.
配列のNR。 （8ビット）：コマンドのシーケンス番号。シーケンス番号空間は、コマンドソースのSSRCとコマンド目標のSSRCの各ペアに対して一意です。シーケンス番号は、それぞれの新しいコマンドのために1つのモジュロ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にSSRCs FIRコマンドが適用される対応する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フィードバックメッセージを繰り返すことができます。即時フィードバックモードを使用している場合、繰り返しが送信される前に少なくとも一つの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.
現在、ビデオは、RTPパケットの境界を越えてメディアの予測に大きく依存して広く展開されている唯一のRTPペイロードのように見えるように、FIRのための唯一の便利なアプリケーションであるように思われます。しかしながら、FIRの使用はまた、合理的に（フレームは、そのメディアタイプとすることができるものは何でも）、すなわち、クロスフレーム予測、圧縮されたビデオとの本質的な特性を共有する他のメディアタイプのために想定され得ます。 1つの可能な例は、MPEG-4シーン記述を動的に更新することができます。そのようなメディアタイプのペイロードフォーマットが代わりペイロード仕様で同様のメカニズムを作成する、FIR及び本明細書およびAVPF [RFC4585]で定義された他のメッセージタイプを参照することが示唆されます。ペイロードの仕様は、ペイロード特有の用語が本明細書中で使用されるビデオ中心の用語にマップする方法を説明する必要があります。
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.
送信者は、コーデックを制御できない環境（例えば、事前に記録および事前符号化されたコンテンツをストリーミングする場合）には、このコマンドに反応を特定することができません。送信者の一つの適当な反応は、次のデコーダ・リフレッシュ・ポイントへのビデオビットストリームに前方にスキップすることであろう。他のシナリオでは、大きなマルチキャスト・グループにストリーミングする場合、例えば、まったくコマンドに反応しないことが好ましい場合があります。他の反応も可能です。戦略を決定する際に、送信者は、そのような受信基、（但し、「重要度」は、この特定のアプリケーションで定義されてもよい）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つの可能なオプションは、デコーダ・リフレッシュ・ポイントを送信することからなります。しかし、他のオプションがあります。一つの例は、埋め込まれたストリームの冗長性が妥当な時間内再生画像をクリーンアップする可能性があるため、メディアの送信者は、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フィールドは、一つ以上の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にNがFCIエントリの数が含まれている2 + 2 * Nに設定しなければならないフィードバックメッセージの長さが示されています。
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.
配列のNR。 （8ビット）：要求シーケンス番号。シーケンス番号空間は、要求元のSSRCと要求対象のSSRCのペアリングのためのユニークです。シーケンス番号は、それぞれの新しいコマンドのために1つのモジュロ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の間の整数値。 31は、可能な限り高い時間分解能を示している0のインデックス値は、可能な限り最高の空間品質を示しています。
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にSSRCs TSTRが適用される対応する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フィールドは、一つ以上の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にNがFCIエントリの数である2 + 2 * Nに設定しなければならないTSTNメッセージの長さが示されています。
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.
配列のNR。 （8ビット）：承認されているTSTRからシーケンス番号値。
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 SSRCsに対応する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フィールドは、一つ以上の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.
配列のNR。 （8ビット）：コマンドのシーケンス番号。シーケンス番号空間は、コマンドソースのSSRCとコマンド目標のSSRCのペアリングのためのユニークです。シーケンス番号は、それぞれの新しいコマンドのために1つのモジュロ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.
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.
[H.271]で定義されるようVBCMで運ばフィードバックサブメッセージの異なるタイプの「payloadType」で示されています。これらのサブメッセージタイプは、便宜のために以下に再現されています。 ITU-T勧告で "payloadType"、。 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の「ペイロード」は可変長であり、自己完結型と可変長で符号化され、バイナリ形式です。メディア送信者は必ずしもVBCMsを利用するために、この最適化されたバイナリフォーマットを解析することができなければなりません。
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にSSRCs VBCMが適用される対応する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.
H.271メッセージとAVPF [RFC4585]で定義されたメッセージの使用方法についての議論と同様の機能を持つこのメモはセクション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のために、そのような必要性が存在しないこと以上のコメントがありました。
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;
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。あまり有用でセッションをレンダリング、ユーザの希望とは別のビデオ品質につながるTSTRSを送信します。
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.
これらの攻撃を防ぐために、フィードバックメッセージの認証と完全性保護を適用する必要があります。これはSAVPF [SAVPF]にセキュアRTP [SRTP]とAVPFを組み合わせ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を定義ABNF用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
"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.
O「モミは、」フルイントラ要求（FIR）のサポートを示します。 O「tmmbrは、」一時的な最大のメディアストリームのビットレート要求/通知（TMMBR / TMMBN）のサポートを示します。それが使用される（秒あたりのパケットで測定される）セッションの最大パケットレートを示すために、オプションのサブパラメータを有しています。無限に含まれていない場合、これがデフォルトになります。 O「TSTRは」時間的・空間的なトレードオフ要求/通知（TSTR / TSTN）のサポートを示します。 O「vbcmは、」H.271ビデオバックチャネルメッセージ（VBCMs）のサポートを示します。これは、サポートされているH.271「payloadType」の値を識別し、ゼロまたはそれ以上のサブパラメータがあります。
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
Rtisipi-phambu壁= / "sikam" rtisipi-phambu-sikam-買います
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
RTCP-FB-CCM-PARAM = SP "モミ";フルイントラ要求/ SP "tmmbr" [SP "smaxpr =" MaxPacketRateValue]。一時的な最大のメディアビットレート/ SP「TSTR」。時間的・空間的トレードオフ/ SP "vbcm" *（SP subMessageType）。 H.271 VBCMs / SPトークン[SPバイト文字列];将来のコマンドの/適応subMessageType = 1 * <[RFC4585]のセクション4.2で定義されているよう> 8DIGITバイト列= 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]意味は[RFC4585]に記載のものと同様です。オファー側は、選択したコーデックコマンドおよび表示をサポートする機能がある可能性があります。回答は、それが問題のメッセージを実装していないので、それは、例えば（この特定のメディアセッションでサポートを希望しない、またはそのアプリケーションロジックがメッセージのサポートはありませんを追加することを示唆しているためというのCCMに対応するすべてのCCMパラメータを削除する必要があります値）。回答は、提供されたものに加えて、新たな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.
答えは、メディアセッションのために結合され、両方のオファー側とアンサーは両側が明示的にサポートされているものとして示されているもの以外の任意のフィードバックメッセージを使用してはなりません。換言すれば、オファーとアンサーから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は、FIRとTSTR / TSTNコーデック制御メッセージをサポートする能力を宣言し、コールの発信と、H.263とのポイントツーポイントビデオコールを記述する。 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.
上記の例では、送信者がRTCP TSTNフィードバックメッセージに示されるように、それはトレードオフを調整することが可能である相手からのTSTRメッセージを受信します。
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（フルイントラ要求）コーデック制御コマンドをサポートしており、それは、そのセッション記述でそれを宣言します。
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」、「もみ」と「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
回答はFIRおよびTSTR / TSTNメッセージをサポートしたいと回答SDPがあります
<---------------- 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
http://www.iana.org/assignments/sdp-parameters：新しい値「CCMが」で発行時点のものであり、「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
http://www.iana.org/assignments/sdp-parameters：新しいレジストリ「コーデックコントロールメッセージ」で発行時点のものであり、「CCM」パラメータを保持するために作成されています
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".
このレジストリ内の新規登録は[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
値の名前：モミロング名：フルイントラ要求コマンド使用可能と：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
http://www.iana.org/assignments/rtp-parameters値は次のとおりで発行時点のものであり、「PSFBペイロードタイプのためのFMT値は、」レジストリのFMT値として登録されています
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].
著者は、要件と議論文書[バッソ]上の自分の仕事のためにアンドレア・バッソ、のoriTレヴィン、およびNermeenイスマイルに感謝したいと思います。
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.
このメモのバージョンを見直し、広範囲であってもロニ、コリンパーキンス、ランデルジェサップ、キースランツ、Harikishan Desineni、グイド・フランセ、そして他の人がコメントしました。著者はこれらのレビューを感謝しています。
[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]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ「ベースのフィードバック（RTP / AVPF）リアルタイムトランスポート制御プロトコル（RTCP）の拡張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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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]クロッカー、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.
[バッソ]バッソ、A.、レビン、O.、およびN.イスマイル、「ビデオ制御コマンドの輸送のための要件」、進歩、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.
ITU-TとISO / IEC JTC 1の[AVC]ジョイントビデオチーム、ジョイントビデオ仕様のドラフトITU-T勧告と最終国際規格案（ITU-T勧告H.264 | ISO / IEC 14496-10 AVC）、 ISO / IEC MPEGおよびITU-T VCEG、JVT-G050、2003年3月の合同ビデオチーム（JVT）。
[H245] ITU-T Rec. H.245, "Control protocol for multimedia communication", May 2006.
[H245] ITU-T勧告。 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.福永、T.中井、およびPROCでH.井上、「動的による誤り耐性動画像の符号化の参考写真の交換」、。 Globcom'96、巻。 1508年、1996年 - 。3、頁1503。
[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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（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]オット、J.及びE.カララは、進歩、2007年11月、ワーク "RTCPベースのフィードバック（RTP / SAVPF）のためのセキュアRTPプロファイルの拡張します"。
[RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3525]グローブ、C.、パンタレオ、M.、アンダーソン、T.、およびT.テイラー、 "ゲートウェイ制御プロトコルバージョン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]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。
[H.271] ITU-T Rec. H.271, "Video Back Channel Messages", June 2006.
[H.271] ITU-T勧告。 H.271、「ビデオバックチャネルメッセージ」、2006年6月。
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[RFC3890]ウェスター、M.、RFC 3890 "トランスポート独立の帯域幅修飾子セッション記述プロトコル（SDP）について"、2004年9月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月のため。
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, August 2006.
[RFC4587]であっても、R.、 "H.261ビデオストリームのためのRTPペイロードフォーマット"、RFC 4587、2006年8月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]ウェスター、M.とS.ベンゲル監督、 "RTPトポロジ"、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]レビン、O.、でも、R.、およびP. Hagendorf、 "メディアコントロールのためのXMLスキーマ"、進歩、2007年11月に作業。
Authors' Addresses
著者のアドレス
Stephan Wenger Nokia Corporation 975, Page Mill Road, Palo Alto,CA 94304 USA
ステファン・ウェンガーノキア・コーポレーション975ページミルロード、パロアルト、CA 94304 USA
Phone: +1-650-862-7368 EMail: stewe@stewe.org
電話：+ 1-650-862-7368 Eメール：stewe@stewe.org
Umesh Chandra Nokia Research Center 975, Page Mill Road, Palo Alto,CA 94304 USA
Umeshチャンドラノキア・リサーチセンター975ページミルロード、パロアルト、CA 94304 USA
Phone: +1-650-796-7502 Email: Umesh.1.Chandra@nokia.com
電話：+ 1-650-796-7502 Eメール：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
電話：+46 8 7190000 Eメール：magnus.westerlund@ericsson.com
Bo Burman Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN
ボービルマエリクソン研究エリクソンAB、SE-164 80ストックホルム、スウェーデン
Phone: +46 8 7190000 EMail: bo.burman@ericsson.com
電話：+46 8 7190000 Eメール：bo.burman@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。