[要約] RFC 4585は、RTCPベースのフィードバックを使用する拡張RTPプロファイル（RTP/AVPF）に関する規格です。このRFCの目的は、リアルタイム通信におけるフィードバックメカニズムの拡張と改善を提供することです。
Network Working Group J. Ott
Request for Comments: 4585 Helsinki University of Technology
Category: Standards Track S. Wenger
Nokia
N. Sato
Oki
C. Burmeister
J. Rey
Matsushita
July 2006
Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF）
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティ用のインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups.
RTPを使用するリアルタイムメディアストリームは、ある程度、パケット損失に対して回復力があります。受信者は、リアルタイムトランスポートコントロールプロトコル（RTCP）の基本メカニズムを使用してパケット受信統計を報告し、送信者がその送信動作を中期的に適応できるようにします。これは、フィードバックとフィードバックベースのエラー修復のための唯一の手段です（いくつかのコーデック固有のメカニズムに加えて）。このドキュメントでは、オーディオビジュアルプロファイル（AVP）の拡張機能を定義します。これにより、受信者は統計的に、より迅速にフィードバックを送信者に提供できるため、短期的な適応と効率的なフィードバックベースの修復メカニズムを実装できます。この早期フィードバックプロファイル（AVPF）は、RTCPのAVP帯域幅の制約を維持し、大規模なグループへのスケーラビリティを維持します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Definitions ................................................3
1.2. Terminology ................................................5
2. RTP and RTCP Packet Formats and Protocol Behavior ...............6
2.1. RTP ........................................................6
2.2. Underlying Transport Protocols .............................6
3. Rules for RTCP Feedback .........................................7
3.1. Compound RTCP Feedback Packets .............................7
3.2. Algorithm Outline ..........................................8
3.3. Modes of Operation .........................................9
3.4. Definitions and Algorithm Overview ........................11
3.5. AVPF RTCP Scheduling Algorithm ............................14
3.5.1. Initialization .....................................15
3.5.2. Early Feedback Transmission ........................15
3.5.3. Regular RTCP Transmission ..........................18
3.5.4. Other Considerations ...............................19
3.6. Considerations on the Group Size ..........................20
3.6.1. ACK Mode ...........................................20
3.6.2. NACK Mode ..........................................20
3.7. Summary of Decision Steps .................................22
3.7.1. General Hints ......................................22
3.7.2. Media Session Attributes ...........................22
4. SDP Definitions ................................................23
4.1. Profile Identification ....................................23
4.2. RTCP Feedback Capability Attribute ........................23
4.3. RTCP Bandwidth Modifiers ..................................27
4.4. Examples ..................................................27
5. Interworking and Coexistence of AVP and AVPF Entities ..........29
6. Format of RTCP Feedback Messages ...............................31
6.1. Common Packet Format for Feedback Messages ................32
6.2. Transport Layer Feedback Messages .........................34
6.2.1. Generic NACK .......................................34
6.3. Payload-Specific Feedback Messages ........................35
6.3.1. Picture Loss Indication (PLI) ......................36
6.3.2. Slice Loss Indication (SLI) ........................37
6.3.3. Reference Picture Selection Indication (RPSI) ......39
6.4. Application Layer Feedback Messages .......................41
7. Early Feedback and Congestion Control ..........................41
8. Security Considerations ........................................42
9. IANA Considerations ............................................43
10. Acknowledgements ..............................................47
11. References ....................................................48
11.1. Normative References .....................................48
11.2. Informative References ...................................48
Real-time media streams that use RTP are, to some degree, resilient against packet losses. RTP [1] provides all the necessary mechanisms to restore ordering and timing present at the sender to properly reproduce a media stream at a recipient. RTP also provides continuous feedback about the overall reception quality from all receivers -- thereby allowing the sender(s) in the mid-term (in the order of several seconds to minutes) to adapt their coding scheme and transmission behavior to the observed network quality of service (QoS). However, except for a few payload-specific mechanisms [6], RTP makes no provision for timely feedback that would allow a sender to repair the media stream immediately: through retransmissions, retroactive Forward Error Correction (FEC) control, or media-specific mechanisms for some video codecs, such as reference picture selection.
RTPを使用するリアルタイムメディアストリームは、ある程度、パケット損失に対して回復力があります。 RTP [1]は、受信者でメディアストリームを適切に再生するために送信者に存在する順序とタイミングを復元するために必要なすべてのメカニズムを提供します。 RTPは、すべての受信者からの全体的な受信品質に関する継続的なフィードバックも提供します。これにより、送信者は中期的に（数秒から数分程度）、コーディングスキームと送信動作を観測されたネットワーク品質に適合させることができます。サービス（QoS）。ただし、いくつかのペイロード固有のメカニズム[6]を除いて、RTPは送信者がメディアストリームを即座に修復できるタイムリーなフィードバックを提供しません。再送信、遡及転送エラー修正（FEC）制御、またはメディア固有のメカニズムを通じて参照画像の選択など、一部のビデオコーデックの場合。
Current mechanisms available with RTP to improve error resilience include audio redundancy coding [13], video redundancy coding [14], RTP-level FEC [11], and general considerations on more robust media streams transmission [12]. These mechanisms may be applied proactively (thereby increasing the bandwidth of a given media stream). Alternatively, in sufficiently small groups with small round-trip times (RTTs), the senders may perform repair on-demand, using the above mechanisms and/or media-encoding-specific approaches. Note that "small group" and "sufficiently small RTT" are both highly application dependent.
エラー耐性を向上させるためにRTPで利用できる現在のメカニズムには、オーディオ冗長コーディング[13]、ビデオ冗長コーディング[14]、RTPレベルのFEC [11]、およびより堅牢なメディアストリーム伝送に関する一般的な考慮事項[12]があります。これらのメカニズムは、積極的に適用することができます（これにより、特定のメディアストリームの帯域幅が増加します）。あるいは、小さな往復時間（RTT）を持つ十分に小さなグループでは、送信者は、上記のメカニズムやメディアエンコーディング固有のアプローチを使用して、オンデマンドで修復を実行できます。 「小さいグループ」と「十分に小さいRTT」はどちらもアプリケーションに大きく依存していることに注意してください。
This document specifies a modified RTP profile for audio and video conferences with minimal control based upon [1] and [2] by means of two modifications/additions: Firstly, to achieve timely feedback, the concept of Early RTCP messages as well as algorithms allowing for low-delay feedback in small multicast groups (and preventing feedback implosion in large ones) are introduced. Special consideration is given to point-to-point scenarios. Secondly, a small number of general-purpose feedback messages as well as a format for codec- and application-specific feedback information are defined for transmission in the RTCP payloads.
このドキュメントでは、[1]および[2]に基づいて最小限の制御でオーディオおよびビデオ会議用に変更されたRTPプロファイルを2つの変更/追加により指定しています。小さなマルチキャストグループでの低遅延フィードバック（および大きなマルチキャストグループでのフィードバックの内破の防止）が導入されました。ポイントツーポイントのシナリオには特別な考慮が払われます。次に、少数の汎用フィードバックメッセージと、コーデックおよびアプリケーション固有のフィードバック情報のフォーマットが、RTCPペイロードでの送信用に定義されています。
The definitions from RTP/RTCP [1] and the "RTP Profile for Audio and Video Conferences with Minimal Control" [2] apply. In addition, the following definitions are used in this document: Early RTCP mode: The mode of operation in that a receiver of a media stream is often (but not always) capable of reporting events of interest back to the sender close to their occurrence. In Early RTCP mode, RTCP packets are transmitted according to the timing rules defined in this document.
RTP / RTCP [1]と「最小制御のオーディオおよびビデオ会議のRTPプロファイル」[2]の定義が適用されます。さらに、このドキュメントでは次の定義が使用されています。アーリーRTCPモード：メディアストリームのレシーバーは、多くの場合（常にではありませんが）、関心のあるイベントを発生に近い送信者に報告することができるという動作モード。 Early RTCPモードでは、RTCPパケットは、このドキュメントで定義されているタイミングルールに従って送信されます。
Early RTCP packet: An Early RTCP packet is a packet which is transmitted earlier than would be allowed if following the scheduling algorithm of [1], the reason being an "event" observed by a receiver. Early RTCP packets may be sent in Immediate Feedback and in Early RTCP mode. Sending an Early RTCP packet is also referred to as sending Early Feedback in this document.
アーリーRTCPパケット：アーリーRTCPパケットは、[1]のスケジューリングアルゴリズムに従っている場合に許可されるよりも早く送信されるパケットであり、その理由は、受信者によって観察される「イベント」です。初期RTCPパケットは、即時フィードバックと初期RTCPモードで送信できます。このドキュメントでは、アーリーRTCPパケットの送信をアーリーフィードバックの送信とも呼びます。
Event: An observation made by the receiver of a media stream that is (potentially) of interest to the sender -- such as a packet loss or packet reception, frame loss, etc. -- and thus useful to be reported back to the sender by means of a feedback message.
イベント：送信者が（潜在的に）関心のあるメディアストリームの受信者によって行われた観察-パケット損失またはパケット受信、フレーム損失など-したがって、送信者への報告に役立つフィードバックメッセージによって。
Feedback (FB) message: An RTCP message as defined in this document is used to convey information about events observed at a receiver -- in addition to long-term receiver status information that is carried in RTCP receiver reports (RRs) -- back to the sender of the media stream. For the sake of clarity, feedback message is referred to as FB message throughout this document.
フィードバック（FB）メッセージ：このドキュメントで定義されているRTCPメッセージは、RTCPレシーバーレポート（RR）で伝送される長期レシーバーステータス情報に加えて、レシーバーで観測されたイベントに関する情報を伝えるために使用されます。メディアストリームの送信者。明確にするために、このドキュメントではフィードバックメッセージをFBメッセージと呼びます。
Feedback (FB) threshold: The FB threshold indicates the transition between Immediate Feedback and Early RTCP mode. For a multiparty scenario, the FB threshold indicates the maximum group size at which, on average, each receiver is able to report each event back to the sender(s) immediately, i.e., by means of an Early RTCP packet without having to wait for its regularly scheduled RTCP interval. This threshold is highly dependent on the type of feedback to be provided, network QoS (e.g., packet loss probability and distribution), codec and packetization scheme in use, the session bandwidth, and application requirements. Note that the algorithms do not depend on all senders and receivers agreeing on the same value for this threshold. It is merely intended to provide conceptual guidance to application designers and is not used in any calculations. For the sake of clarity, the term feedback threshold is referred to as FB threshold throughout this document.
フィードバック（FB）しきい値：FBしきい値は、即時フィードバックと早期RTCPモード間の移行を示します。マルチパーティシナリオの場合、FBしきい値は、平均で、各レシーバが各イベントを直ちに送信者に報告できる最大グループサイズを示します。つまり、Early RTCPパケットを使用して、待機する必要はありません。定期的にスケジュールされたRTCP間隔。このしきい値は、提供されるフィードバックのタイプ、ネットワークQoS（パケット損失の確率と分布など）、使用中のコーデックとパケット化スキーム、セッション帯域幅、およびアプリケーション要件に大きく依存します。アルゴリズムは、このしきい値の同じ値に同意するすべての送信者と受信者に依存するわけではないことに注意してください。これは、アプリケーション設計者に概念的なガイダンスを提供することのみを目的としており、計算では使用されません。わかりやすくするために、このドキュメントではフィードバックしきい値という用語をFBしきい値と呼びます。
Immediate Feedback mode: A mode of operation in which each receiver of a media stream is, statistically, capable of reporting each event of interest immediately back to the media stream sender. In Immediate Feedback mode, RTCP FB messages are transmitted according to the timing rules defined in this document.
即時フィードバックモード：メディアストリームの各レシーバーが統計的に、対象の各イベントをメディアストリームセンダーにすぐに報告できる動作モード。即時フィードバックモードでは、RTCP FBメッセージは、このドキュメントで定義されているタイミングルールに従って送信されます。
Media packet: A media packet is an RTP packet.
メディアパケット：メディアパケットはRTPパケットです。
Regular RTCP mode: Mode of operation in which no preferred transmission of FB messages is allowed. Instead, RTCP messages are sent following the rules of [1]. Nevertheless, such RTCP messages may contain feedback information as defined in this document.
通常のRTCPモード：FBメッセージの優先送信が許可されない動作モード。代わりに、RTCPメッセージは[1]のルールに従って送信されます。それにもかかわらず、このようなRTCPメッセージには、このドキュメントで定義されているフィードバック情報が含まれている場合があります。
Regular RTCP packet: An RTCP packet that is not sent as an Early RTCP packet.
通常のRTCPパケット：Early RTCPパケットとして送信されないRTCPパケット。
RTP sender: An RTP sender is an RTP entity that transmits media packets as well as RTCP packets and receives Regular as well as Early RTCP (i.e., feedback) packets. Note that the RTP sender is a logical role and that the same RTP entity may at the same time act as an RTP receiver.
RTP送信者：RTP送信者は、メディアパケットとRTCPパケットを送信し、通常のパケットと初期のRTCP（つまり、フィードバック）パケットを受信するRTPエンティティです。 RTP送信側は論理的な役割であり、同じRTPエンティティが同時にRTP受信側として機能する場合があることに注意してください。
RTP receiver: An RTP receiver is an RTP entity that receives media packets as well as RTCP packets and transmits Regular as well as Early RTCP (i.e., feedback) packets. Note that the RTP receiver is a logical role and that the same RTP entity may at the same time act as an RTP sender.
RTPレシーバー：RTPレシーバーは、メディアパケットとRTCPパケットを受信し、通常のパケットと初期のRTCP（つまり、フィードバック）パケットを送信するRTPエンティティです。 RTPレシーバーは論理的な役割であり、同じRTPエンティティが同時にRTPセンダーとして機能する場合があることに注意してください。
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 [5].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [5]で説明されているように解釈されます。
The rules defined in [2] also apply to this profile except for those rules mentioned in the following:
[2]で定義されているルールは、以下で説明されているルールを除き、このプロファイルにも適用されます。
RTCP packet types: Two additional RTCP packet types are registered and the corresponding FB messages to convey feedback information are defined in Section 6 of this memo.
RTCPパケットタイプ：2つの追加のRTCPパケットタイプが登録され、フィードバック情報を伝えるための対応するFBメッセージは、このメモのセクション6で定義されています。
RTCP report intervals: This document describes three modes of operation that influence the RTCP report intervals (see Section 3.2 of this memo). In Regular RTCP mode, all rules from [1] apply except for the recommended minimal interval of five seconds between two RTCP reports from the same RTP entity. In both Immediate Feedback and Early RTCP modes, the minimal interval of five seconds between two RTCP reports is dropped and, additionally, the rules specified in Section 3 of this memo apply if RTCP packets containing FB messages (defined in Section 4 of this memo) are to be transmitted.
RTCPレポート間隔：このドキュメントでは、RTCPレポート間隔に影響する3つの操作モードについて説明します（このメモのセクション3.2を参照）。通常のRTCPモードでは、同じRTPエンティティからの2つのRTCPレポート間の推奨最小間隔である5秒を除いて、[1]のすべてのルールが適用されます。即時フィードバックモードと初期RTCPモードの両方で、2つのRTCPレポート間の最小間隔である5秒が削除され、さらに、このメッセージのセクション3で指定されたルールが、FBメッセージ（このメモのセクション4で定義）を含むRTCPパケットに適用される場合に適用されます。送信されます。
The rules set forth in [1] may be overridden by session descriptions specifying different parameters (e.g., for the bandwidth share assigned to RTCP for senders and receivers, respectively). For sessions defined using the Session Description Protocol (SDP) [3], the rules of [4] apply.
[1]で説明されているルールは、異なるパラメーターを指定するセッション記述によって上書きされる場合があります（たとえば、送信者と受信者のそれぞれに対してRTCPに割り当てられた帯域幅の共有について）。セッション記述プロトコル（SDP）[3]を使用して定義されたセッションには、[4]のルールが適用されます。
Congestion control: The same basic rules as detailed in [2] apply. Beyond this, in Section 7, further consideration is given to the impact of feedback and a sender's reaction to FB messages.
輻輳制御：[2]で詳述されているのと同じ基本ルールが適用されます。これに加えて、セクション7では、フィードバックの影響とFBメッセージに対する送信者の反応についてさらに考察します。
RTP is intended to be used on top of unreliable transport protocols, including UDP and the Datagram Congestion Control Protocol (DCCP). This section briefly describes the specifics beyond plain RTP operation introduced by RTCP feedback as specified in this memo.
RTPは、UDPやデータグラム輻輳制御プロトコル（DCCP）など、信頼性の低いトランスポートプロトコルの上で使用することを目的としています。このセクションでは、このメモで指定されているRTCPフィードバックによって導入された単純なRTP操作以外の詳細について簡単に説明します。
UDP: UDP provides best-effort delivery of datagrams for point-to-point as well as for multicast communications. UDP does not support congestion control or error repair. The RTCP-based feedback defined in this memo is able to provide minimal support for limited error repair. As RTCP feedback is not guaranteed to operate on sufficiently small timescales (in the order of RTT), RTCP feedback is not suitable to support congestion control. This memo addresses both unicast and multicast operation.
UDP：UDPは、ポイントツーポイントおよびマルチキャスト通信のデータグラムをベストエフォートで配信します。 UDPは、輻輳制御またはエラー修復をサポートしていません。このメモで定義されたRTCPベースのフィードバックは、限られたエラー修復に対して最小限のサポートを提供できます。 RTCPフィードバックは、十分に小さいタイムスケール（RTTの順序）での動作が保証されていないため、輻輳制御をサポートするのには適していません。このメモはユニキャストとマルチキャスト操作の両方を扱います。
DCCP: DCCP [19] provides for congestion-controlled but unreliable datagram flows for unicast communications. With TCP Friendly Rate Control (TFRC)-based [20] congestion control (CCID 3), DCCP is particularly suitable for audio and video communications. DCCP's acknowledgement messages may provide detailed feedback reporting about received and missed datagrams (and thus about congestion).
DCCP：DCCP [19]は、ユニキャスト通信用の輻輳制御された信頼性のないデータグラムフローを提供します。 TCPフレンドリーレートコントロール（TFRC）ベースの[20]輻輳制御（CCID 3）を備えたDCCPは、オーディオおよびビデオ通信に特に適しています。 DCCPの確認応答メッセージは、受信されたデータグラムと失われたデータグラムに関する（したがって、輻輳に関する）詳細なフィードバックレポートを提供します。
When running RTP over DCCP, congestion control is performed at the DCCP layer and no additional mechanisms are required at the RTP layer. Furthermore, an RTCP-feedback-capable sender may leverage the more frequent DCCP-based feedback and thus a receiver may refrain from using (additional) Generic Feedback messages where appropriate.
DTP over DCCPを実行する場合、輻輳制御はDCCPレイヤーで実行され、RTPレイヤーで追加のメカニズムは必要ありません。さらに、RTCPフィードバック対応の送信者は、より頻繁なDCCPベースのフィードバックを活用できるため、受信者は必要に応じて（追加の）汎用フィードバックメッセージを使用しない場合があります。
Two components constitute RTCP-based feedback as described in this document:
このドキュメントで説明するように、2つのコンポーネントがRTCPベースのフィードバックを構成します。
o Status reports are contained in sender report (SR)/received report (RR) packets and are transmitted at regular intervals as part of compound RTCP packets (which also include source description (SDES) and possibly other messages); these status reports provide an overall indication for the recent reception quality of a media stream.
o ステータスレポートは送信者レポート（SR）/受信レポート（RR）パケットに含まれ、定期的な間隔で複合RTCPパケットの一部として送信されます（送信元説明（SDES）および場合によっては他のメッセージも含まれます）。これらのステータスレポートは、メディアストリームの最近の受信品質の全体的な指標を提供します。
o FB messages as defined in this document that indicate loss or reception of particular pieces of a media stream (or provide some other form of rather immediate feedback on the data received). Rules for the transmission of FB messages are newly introduced in this document.
o このドキュメントで定義されているFBメッセージは、メディアストリームの特定の部分の損失または受信を示します（または、受信したデータに関するかなり即時のフィードバックの他の形式を提供します）。このドキュメントでは、FBメッセージの送信に関するルールが新しく導入されています。
RTCP FB messages are just another RTCP packet type (see Section 4). Therefore, multiple FB messages MAY be combined in a single compound RTCP packet and they MAY also be sent combined with other RTCP packets.
RTCP FBメッセージは、別のRTCPパケットタイプです（セクション4を参照）。したがって、複数のFBメッセージが1つの複合RTCPパケットに結合される場合があり、他のRTCPパケットと結合されて送信される場合があります。
Compound RTCP packets containing FB messages as defined in this document MUST contain RTCP packets in the order defined in [1]:
このドキュメントで定義されているFBメッセージを含む複合RTCPパケットには、[1]で定義されている順序でRTCPパケットを含める必要があります。
o OPTIONAL encryption prefix that MUST be present if the RTCP packet(s) is to be encrypted according to Section 9.1 of [1]. o MANDATORY SR or RR.
o [1]のセクション9.1に従ってRTCPパケットを暗号化する場合に必要なオプションの暗号化プレフィックス。 o必須SRまたはRR。
o MANDATORY SDES, which MUST contain the CNAME item; all other SDES items are OPTIONAL. o One or more FB messages.
o CNAME項目を含む必要がある必須のSDES。他のすべてのSDESアイテムはオプションです。 o 1つ以上のFBメッセージ。
The FB message(s) MUST be placed in the compound packet after RR and SDES RTCP packets defined in [1]. The ordering with respect to other RTCP extensions is not defined.
FBメッセージは、[1]で定義されているRRおよびSDES RTCPパケットの後の複合パケットに配置する必要があります。他のRTCP拡張に関する順序は定義されていません。
Two types of compound RTCP packets carrying feedback packets are used in this document:
このドキュメントでは、フィードバックパケットを運ぶ2種類の複合RTCPパケットが使用されています。
a) Minimal compound RTCP feedback packet
a) 最小限の複合RTCPフィードバックパケット
A minimal compound RTCP feedback packet MUST contain only the mandatory information as listed above: encryption prefix if necessary, exactly one RR or SR, exactly one SDES with only the CNAME item present, and the FB message(s). This is to minimize the size of the RTCP packet transmitted to convey feedback and thus to maximize the frequency at which feedback can be provided while still adhering to the RTCP bandwidth limitations.
最小限の複合RTCPフィードバックパケットには、上記の必須情報のみが含まれている必要があります：必要に応じて暗号化プレフィックス、1つのRRまたはSR、CNAMEアイテムのみが存在する1つのSDES、およびFBメッセージ。これは、フィードバックを伝達するために送信されるRTCPパケットのサイズを最小化し、RTCP帯域幅の制限を遵守しながらフィードバックを提供できる頻度を最大化するためです。
This packet format SHOULD be used whenever an RTCP FB message is sent as part of an Early RTCP packet. This packet type is referred to as minimal compound RTCP packet in this document.
このパケット形式は、RTCP FBメッセージがEarly RTCPパケットの一部として送信される場合は常に使用する必要があります（SHOULD）。このドキュメントタイプでは、このパケットタイプを最小複合RTCPパケットと呼びます。
b) (Full) compound RTCP feedback packet
b) （完全）複合RTCPフィードバックパケット
A (full) compound RTCP feedback packet MAY contain any additional number of RTCP packets (additional RRs, further SDES items, etc.). The above ordering rules MUST be adhered to.
（完全）複合RTCPフィードバックパケットには、追加の数のRTCPパケット（追加のRR、追加のSDESアイテムなど）が含まれる場合があります。上記の順序付け規則を遵守する必要があります。
This packet format MUST be used whenever an RTCP FB message is sent as part of a Regular RTCP packet or in Regular RTCP mode. It MAY also be used to send RTCP FB messages in Immediate Feedback or Early RTCP mode. This packet type is referred to as full compound RTCP packet in this document.
このパケット形式は、RTCP FBメッセージが通常のRTCPパケットの一部として、または通常のRTCPモードで送信される場合は常に使用する必要があります。また、即時フィードバックまたは早期RTCPモードでRTCP FBメッセージを送信するために使用される場合があります。このパケットタイプは、このドキュメントでは完全な複合RTCPパケットと呼ばれます。
RTCP packets that do not contain FB messages are referred to as non-FB RTCP packets. Such packets MUST follow the format rules in [1].
FBメッセージを含まないRTCPパケットは、非FB RTCPパケットと呼ばれます。このようなパケットは、[1]のフォーマット規則に従う必要があります。
FB messages are part of the RTCP control streams and thus subject to the RTCP bandwidth constraints. This means, in particular, that it may not be possible to report an event observed at a receiver immediately back to the sender. However, the value of feedback given to a sender typically decreases over time -- in terms of the media quality as perceived by the user at the receiving end and/or the cost required to achieve media stream repair.
FBメッセージはRTCP制御ストリームの一部であるため、RTCP帯域幅の制約を受けます。これは、特に、受信側で観測されたイベントを送信側にすぐに報告することができない場合があることを意味します。ただし、送信側に提供されるフィードバックの値は、通常、時間の経過とともに減少します。受信側のユーザーが認識するメディア品質や、メディアストリームの修復に必要なコストの観点からです。
RTP [1] and the commonly used RTP profile [2] specify rules when compound RTCP packets should be sent. This document modifies those rules in order to allow applications to timely report events (e.g., loss or reception of RTP packets) and to accommodate algorithms that use FB messages.
RTP [1]および一般的に使用されるRTPプロファイル[2]は、複合RTCPパケットを送信する必要がある場合のルールを指定します。このドキュメントでは、アプリケーションがイベント（RTPパケットの損失や受信など）をタイムリーに報告し、FBメッセージを使用するアルゴリズムに対応できるように、これらのルールを変更します。
The modified RTCP transmission algorithm can be outlined as follows: As long as no FB messages have to be conveyed, compound RTCP packets are sent following the rules of RTP [1] -- except that the five-second minimum interval between RTCP reports is not enforced. Hence, the interval between RTCP reports is only derived from the average RTCP packet size and the RTCP bandwidth share available to the RTP/RTCP entity. Optionally, a minimum interval between Regular RTCP packets may be enforced.
変更されたRTCP送信アルゴリズムの概要は次のとおりです。FBメッセージを伝達する必要がない限り、RTP [1]のルールに従って複合RTCPパケットが送信されます。ただし、RTCPレポート間の最小5秒間隔は強制。したがって、RTCPレポート間の間隔は、RTP / RTCPエンティティが使用できる平均RTCPパケットサイズとRTCP帯域幅の共有からのみ導出されます。オプションで、通常のRTCPパケット間の最小間隔を適用できます。
If a receiver detects the need to send an FB message, it may do so earlier than the next regular RTCP reporting interval (for which it would be scheduled following the above regular RTCP algorithm). Feedback suppression is used to avoid feedback implosion in multiparty sessions: The receiver waits for a (short) random dithering interval to check whether it sees a corresponding FB message from any other receiver reporting the same event. Note that for point-to-point sessions there is no such delay. If a corresponding FB message from another member is received, this receiver refrains from sending the FB message and continues to follow the Regular RTCP transmission schedule. In case the receiver has not yet seen a corresponding FB message from any other member, it checks whether it is allowed to send Early feedback. If sending Early feedback is permissible, the receiver sends the FB message as part of a minimal compound RTCP packet. The permission to send Early feedback depends on the type of the previous RTCP packet sent by this receiver and the time the previous Early feedback message was sent.
レシーバーがFBメッセージを送信する必要性を検出した場合、次の通常のRTCPレポート間隔（上記の通常のRTCPアルゴリズムに従ってスケジュールされます）よりも早く送信される場合があります。フィードバック抑制は、マルチパーティセッションでのフィードバックの急増を回避するために使用されます。レシーバーは、（短い）ランダムディザリング間隔を待って、同じイベントを報告する他のレシーバーからの対応するFBメッセージを確認するかどうかを確認します。ポイントツーポイントセッションの場合、そのような遅延はないことに注意してください。別のメンバーから対応するFBメッセージを受信した場合、このレシーバーはFBメッセージの送信を控え、通常のRTCP送信スケジュールに従います。レシーバーが他のメンバーからの対応するFBメッセージをまだ見ていない場合は、アーリーフィードバックの送信が許可されているかどうかを確認します。アーリーフィードバックの送信が許可されている場合、レシーバーは最小の複合RTCPパケットの一部としてFBメッセージを送信します。アーリーフィードバックを送信する権限は、このレシーバーによって送信された以前のRTCPパケットのタイプと、以前のアーリーフィードバックメッセージが送信された時間によって異なります。
FB messages may also be sent as part of full compound RTCP packets, which are transmitted as per [1] (except for the five-second lower bound) in regular intervals.
FBメッセージは、完全な複合RTCPパケットの一部として送信することもできます。これは、[1]に従って（5秒の下限を除く）定期的に送信されます。
RTCP-based feedback may operate in one of three modes (Figure 1) as described below. The mode of operation is just an indication of whether or not the receiver will, on average, be able to report all events to the sender in a timely fashion; the mode does not influence the algorithm used for scheduling the transmission of FB messages.
RTCPベースのフィードバックは、以下で説明する3つのモード（図1）のいずれかで動作します。動作モードは、受信者が平均してすべてのイベントをタイムリーに送信者に報告できるかどうかを示すにすぎません。このモードは、FBメッセージの送信をスケジュールするために使用されるアルゴリズムに影響を与えません。
And, depending on the reception quality and the locally monitored state of the RTP session, individual receivers may not (and do not have to) agree on a common perception on the current mode of operation.
また、RTPセッションの受信品質とローカルで監視されている状態によっては、個々の受信者が現在の動作モードに関する共通の認識に同意できない場合があります（同意する必要はありません）。
a) Immediate Feedback mode: In this mode, the group size is below the FB threshold, which gives each receiving party sufficient bandwidth to transmit the RTCP feedback packets for the intended purpose. This means that, for each receiver, there is enough bandwidth to report each event by means of a virtually "immediate" RTCP feedback packet.
a) 即時フィードバックモード：このモードでは、グループサイズがFBしきい値を下回っています。これにより、各受信側に、目的に応じてRTCPフィードバックパケットを送信するための十分な帯域幅が与えられます。これは、各レシーバーに対して、実質的に「即時」のRTCPフィードバックパケットによって各イベントを報告するのに十分な帯域幅があることを意味します。
The group size threshold is a function of a number of parameters including (but not necessarily limited to): the type of feedback used (e.g., ACK vs. NACK), bandwidth, packet rate, packet loss probability and distribution, media type, codec, and the (worst case or observed) frequency of events to report (e.g., frame received, packet lost).
グループサイズのしきい値は、使用するフィードバックのタイプ（ACKとNACKなど）、帯域幅、パケットレート、パケット損失の確率と分布、メディアタイプ、コーデックを含む（ただし、必ずしもそれに限定されない）多くのパラメーターの関数です。 、および（最悪のケースまたは観測された）レポートするイベントの頻度（たとえば、受信フレーム、パケット損失）。
As a rough estimate, let N be the average number of events to be reported per interval T by a receiver, B the RTCP bandwidth fraction for this particular receiver, and R the average RTCP packet size, then the receiver operates in Immediate Feedback mode as long as N<=B*T/R.
概算として、Nを間隔Tあたりに受信機が報告するイベントの平均数、Bをこの特定の受信機のRTCP帯域幅の割合、Rを平均RTCPパケットサイズとすると、受信機は即時フィードバックモードで次のように動作します。 N <= B * T / Rである限り。
b) Early RTCP mode: In this mode, the group size and other parameters no longer allow each receiver to react to each event that would be worth reporting (or that needed reporting). But feedback can still be given sufficiently often so that it allows the sender to adapt the media stream transmission accordingly and thereby increase the overall media playback quality.
b) 初期のRTCPモード：このモードでは、グループサイズと他のパラメーターにより、各受信者がレポートに値する（またはレポートが必要な）各イベントに反応することができなくなります。しかし、それでも十分に頻繁にフィードバックを与えることができるため、送信者はそれに応じてメディアストリーム送信を調整し、それによって全体的なメディア再生品質を向上させることができます。
Using the above notation, Early RTCP mode can be roughly characterized by N > B*T/R as "lower bound". An estimate for an upper bound is more difficult. Setting N=1, we obtain for a given R and B the interval T = R/B as average interval between events to be reported. This information can be used as a hint to determine whether or not early transmission of RTCP packets is useful.
上記の表記を使用すると、Early RTCPモードは「下限」としてN> B * T / Rによって大まかに特徴付けることができます。上限の推定はより困難です。 N = 1を設定すると、指定されたRとBについて、レポートされるイベント間の平均間隔として間隔T = R / Bが取得されます。この情報は、RTCPパケットの早期送信が有用かどうかを判断するためのヒントとして使用できます。
c) Regular RTCP Mode: From some group size upwards, it is no longer useful to provide feedback for individual events from receivers at all -- because of the time scale in which the feedback could be provided and/or because in large groups the sender(s) have no chance to react to individual feedback anymore.
c) 通常のRTCPモード：一部のグループサイズ以上では、フィードバックが提供される可能性のあるタイムスケール、および/または大規模なグループでは送信者が原因で、レシーバーからの個々のイベントにフィードバックを提供することはまったく役に立ちません。 ）個々のフィードバックに反応する機会はもうありません。
No precise group size threshold can be specified at which this mode starts but, obviously, this boundary matches the upper bound of the Early RTCP mode as specified in item b) above.
このモードを開始する正確なグループサイズのしきい値を指定することはできませんが、明らかに、この境界は上記のb）で指定したEarly RTCPモードの上限と一致します。
As the feedback algorithm described in this document scales smoothly, there is no need for an agreement among the participants on the precise values of the respective FB thresholds within the group. Hence, the borders between all these modes are soft.
このドキュメントで説明するフィードバックアルゴリズムはスムーズにスケーリングされるため、グループ内の各FBしきい値の正確な値について参加者間で合意する必要はありません。したがって、これらすべてのモード間の境界はソフトです。
ACK
feedback
V
:<- - - - NACK feedback - - - ->//
:
: Immediate ||
: Feedback mode ||Early RTCP mode Regular RTCP mode
:<=============>||<=============>//<=================>
: ||
-+---------------||---------------//------------------> group size
2 ||
Application-specific FB Threshold
= f(data rate, packet loss, codec, ...)
Figure 1: Modes of operation
図1：動作モード
As stated before, the respective FB thresholds depend on a number of technical parameters (of the codec, the transport, the type of feedback used, etc.) but also on the respective application scenarios. Section 3.6 provides some useful hints (but no precise calculations) on estimating these thresholds.
前に述べたように、それぞれのFBしきい値は、（コーデック、トランスポート、使用されるフィードバックのタイプなどの）いくつかの技術的パラメータだけでなく、それぞれのアプリケーションシナリオにも依存します。セクション3.6は、これらのしきい値の推定に関するいくつかの有用なヒントを提供します（ただし、正確な計算は行いません）。
The following pieces of state information need to be maintained per receiver (largely taken from [1]). Note that all variables (except in item h) below) are calculated independently at each receiver. Therefore, their local values may differ at any given point in time.
次の状態情報は、受信者ごとに維持する必要があります（主に[1]から取得）。すべての変数（以下の項目hを除く）は、各レシーバーで個別に計算されることに注意してください。したがって、それらのローカル値は特定の時点で異なる場合があります。
a) Let "senders" be the number of active senders in the RTP session.
a) 「送信者」をRTPセッションでアクティブな送信者の数とする。
b) Let "members" be the current estimate of the number of receivers in the RTP session.
b) 「メンバー」をRTPセッションの受信者数の現在の推定値とします。
c) Let tn and tp be the time for the next (last) scheduled RTCP RR transmission calculated prior to timer reconsideration.
c) tnとtpを、タイマーの再検討の前に計算された次の（最後の）スケジュールされたRTCP RR送信の時間とします。
d) Let Tmin be the minimal interval between RTCP packets as per [1]. Unlike in [1], the initial Tmin is set to 1 second to allow for some group size sampling before sending the first RTCP packet. After the first RTCP packet is sent, Tmin is set to 0.
d) [1]に従って、TminをRTCPパケット間の最小間隔とする。 [1]とは異なり、最初のRminパケットを送信する前にいくつかのグループサイズのサンプリングができるように、初期Tminは1秒に設定されています。最初のRTCPパケットが送信された後、Tminは0に設定されます。
e) Let T_rr be the interval after which, having just sent a regularly scheduled RTCP packet, a receiver would schedule the transmission of its next Regular RTCP packet. This value is obtained following the rules of [1] but with Tmin as defined in this document: T_rr = T (the "calculated interval" as defined in [1]) with tn = tp + T. T_rr always refers to the last value of T that has been computed (because of reconsideration or to determine tn). T_rr is also referred to as Regular RTCP interval in this document.
e) T_rrを、定期的にスケジュールされたRTCPパケットを送信した直後の間隔とすると、受信者は次の標準RTCPパケットの送信をスケジュールします。この値は、[1]の規則に従って取得されますが、このドキュメントで定義されているTminを使用します。T_rr= T（[1]で定義されている「計算間隔」）、tn = tp +T。T_rrは常に最後の値を参照します計算されたTの（再検討のため、またはtnを決定するため）。このドキュメントでは、T_rrは通常のRTCP間隔とも呼ばれます。
f) Let t0 be the time at which an event that is to be reported is detected by a receiver.
f) 報告されるイベントがレシーバーによって検出される時間をt0とします。
g) Let T_dither_max be the maximum interval for which an RTCP feedback packet MAY be additionally delayed to prevent implosions in multiparty sessions; the value for T_dither_max is dynamically calculated based upon T_rr (or may be derived by means of another mechanism common across all RTP receivers to be specified in the future). For point-to-point sessions (i.e., sessions with exactly two members with no change in the group size expected, e.g., unicast streaming sessions), T_dither_max is set to 0.
g) T_dither_maxを、マルチパーティセッションでの内破を防ぐためにRTCPフィードバックパケットをさらに遅延できる最大間隔とする。 T_dither_maxの値は、T_rrに基づいて動的に計算されます（または、将来指定されるすべてのRTPレシーバーに共通の別のメカニズムによって導出される場合があります）。ポイントツーポイントセッション（つまり、グループサイズの変更が予想されないちょうど2つのメンバーを持つセッション、たとえばユニキャストストリーミングセッション）の場合、T_dither_maxは0に設定されます。
h) Let T_max_fb_delay be the upper bound within which feedback to an event needs to be reported back to the sender to be useful at all. This value is application specific, and no values are defined in this document.
h) T_max_fb_delayを上限として、イベントへのフィードバックを送信者に報告して、まったく役立つようにする必要があります。この値はアプリケーション固有であり、このドキュメントでは値は定義されていません。
i) Let te be the time for which a feedback packet is scheduled.
i) フィードバックパケットがスケジュールされる時間をteとします。
j) Let T_fd be the actual (randomized) delay for the transmission of FB message in response to an event at time t0.
j) T_fdを、時刻t0のイベントに応答するFBメッセージの送信の実際の（ランダム化された）遅延とします。
k) Let allow_early be a Boolean variable that indicates whether the receiver currently may transmit FB messages prior to its next regularly scheduled RTCP interval tn. This variable is used to throttle the feedback sent by a single receiver. allow_early is set to FALSE after Early feedback transmission and is set to TRUE as soon as the next Regular RTCP transmission takes place.
k) allow_earlyを、次の定期的にスケジュールされたRTCP間隔tnの前に受信者が現在FBメッセージを送信できるかどうかを示すブール変数とする。この変数は、単一のレシーバーによって送信されるフィードバックを抑制するために使用されます。 allow_earlyは、早期フィードバック送信後にFALSEに設定され、次の標準RTCP送信が行われるとすぐにTRUEに設定されます。
l) Let avg_rtcp_size be the moving average on the RTCP packet size as defined in [1].
l) avg_rtcp_sizeを、[1]で定義されているRTCPパケットサイズの移動平均とします。
m) Let T_rr_interval be an OPTIONAL minimal interval to be used between Regular RTCP packets. If T_rr_interval == 0, then this variable does not have any impact on the overall operation of the RTCP feedback algorithm. If T_rr_interval != 0, then the next Regular RTCP packet will not be scheduled T_rr after the last Regular RTCP transmission (i.e., at tp+T_rr). Instead, the next Regular RTCP packet will be delayed until at least T_rr_interval after the last Regular RTCP transmission, i.e., it will be scheduled at or later than tp+T_rr_interval. Note that T_rr_interval does not affect the calculation of T_rr and tp; instead, Regular RTCP packets scheduled for transmission before tp+T_rr_interval will be suppressed if, for example, they do not contain any FB messages. The T_rr_interval does not affect transmission scheduling of Early RTCP packets.
m）T_rr_intervalを、通常のRTCPパケット間で使用されるオプションの最小間隔とします。 T_rr_interval == 0の場合、この変数はRTCPフィードバックアルゴリズムの全体的な動作に影響を与えません。 T_rr_interval！= 0の場合、次の標準RTCPパケットは、最後の標準RTCP送信後（つまり、tp + T_rr）にT_rrにスケジュールされません。代わりに、次の標準RTCPパケットは、最後の標準RTCP送信後、少なくともT_rr_intervalまで遅延されます。つまり、tp + T_rr_interval以降にスケジュールされます。 T_rr_intervalはT_rrおよびtpの計算に影響しないことに注意してください。代わりに、たとえばFBメッセージが含まれていない場合、tp + T_rr_intervalの前に送信がスケジュールされた通常のRTCPパケットは抑制されます。 T_rr_intervalは、Early RTCPパケットの送信スケジューリングには影響しません。
Note: Providing T_rr_interval as an independent variable is meant to minimize Regular RTCP feedback (and thus bandwidth consumption) as needed by the application while additionally allowing the use of more frequent Early RTCP packets to provide timely feedback. This goal could not be achieved by reducing the overall RTCP bandwidth as RTCP bandwidth reduction would also impact the frequency of Early feedback.
注：T_rr_intervalを独立変数として提供することは、アプリケーションが必要に応じて通常のRTCPフィードバック（したがって帯域幅の消費）を最小限に抑えながら、より頻繁なEarly RTCPパケットを使用してタイムリーなフィードバックを提供できるようにすることを意味します。 RTCP帯域幅の削減は早期フィードバックの頻度にも影響を与えるため、この目標はRTCP帯域幅全体を削減することでは達成できませんでした。
n) Let t_rr_last be the point in time at which the last Regular RTCP packet has been scheduled and sent, i.e., has not been suppressed due to T_rr_interval.
n) 最後のレギュラーRTCPパケットがスケジュールされて送信された時点、つまりT_rr_intervalのために抑制されなかった時点をt_rr_lastとします。
o) Let T_retention be the time window for which past FB messages are stored by an AVPF entity. This is to ensure that feedback suppression also works for entities that have received FB messages from other entities prior to noticing the feedback event itself. T_retention MUST be set to at least 2 seconds.
o) T_retentionを、過去のFBメッセージがAVPFエンティティによって保存される時間枠とする。これは、フィードバックイベント自体に気づく前に他のエンティティからFBメッセージを受信したエンティティに対してもフィードバック抑制が機能することを確認するためです。 T_retentionは少なくとも2秒に設定する必要があります。
p) Let M*Td be the timeout value for a receiver to be considered inactive (as defined in [1]).
p) M * Tdを非アクティブと見なされるレシーバーのタイムアウト値とします（[1]で定義）。
The feedback situation for an event to report at a receiver is depicted in Figure 2 below. At time t0, such an event (e.g., a packet loss) is detected at the receiver. The receiver decides -- based upon current bandwidth, group size, and other application-specific parameters -- that an FB message needs to be sent back to the sender.
レシーバーで報告するイベントのフィードバック状況は、以下の図2に示されています。時間ｔ０で、そのようなイベント（例えば、パケット損失）が受信機で検出される。受信者は、現在の帯域幅、グループサイズ、およびその他のアプリケーション固有のパラメーターに基づいて、FBメッセージを送信者に送り返す必要があると判断します。
To avoid an implosion of feedback packets in multiparty sessions, the receiver MUST delay the transmission of the RTCP feedback packet by a random amount of time T_fd (with the random number evenly distributed in the interval [0, T_dither_max]). Transmission of the compound RTCP packet MUST then be scheduled for te = t0 + T_fd.
マルチパーティセッションでのフィードバックパケットの内破を回避するために、受信者はRTCPフィードバックパケットの送信をランダムな時間T_fd（間隔[0、T_dither_max]で均等に分散される）だけ遅らせなければなりません（MUST）。次に、複合RTCPパケットの送信をte = t0 + T_fdにスケジュールする必要があります。
The T_dither_max parameter is derived from the Regular RTCP interval, T_rr, which, in turn, is based upon the group size. A future document may also specify other calculations for T_dither_max (e.g., based upon RTT) if it can be assured that all RTP receivers will use the same mechanism for calculating T_dither_max.
T_dither_maxパラメータは、通常のRTCP間隔T_rrから導出されます。これは、グループサイズに基づいています。今後のドキュメントでは、すべてのRTP受信者がT_dither_maxの計算に同じメカニズムを使用することが保証されている場合、RTTに基づいてT_dither_maxの他の計算を指定することもあります。
For a certain application scenario, a receiver may determine an upper bound for the acceptable local delay of FB messages: T_max_fb_delay. If an a priori estimation or the actual calculation of T_dither_max indicates that this upper bound MAY be violated (e.g., because T_dither_max > T_max_fb_delay), the receiver MAY decide not to send any feedback at all because the achievable gain is considered insufficient.
特定のアプリケーションシナリオでは、レシーバーはFBメッセージの許容可能なローカル遅延の上限T_max_fb_delayを決定できます。事前推定またはT_dither_maxの実際の計算がこの上限に違反する可能性があることを示す場合（たとえば、T_dither_max> T_max_fb_delayのため）、達成可能なゲインが不十分であると見なされるため、レシーバーはフィードバックをまったく送信しないことを決定できます（MAY）。
If an Early RTCP packet is scheduled, the time slot for the next Regular RTCP packet MUST be updated accordingly to have a new tn (tn=tp+2*T_rr) and a new tp (tp=tp+T_rr) afterwards. This is to ensure that the short-term average RTCP bandwidth used with Early feedback does not exceed the bandwidth used without Early feedback.
Early RTCPパケットがスケジュールされている場合、次のRegular RTCPパケットのタイムスロットは、新しいtn（tn = tp + 2 * T_rr）と新しいtp（tp = tp + T_rr）を後で更新するように更新する必要があります。これは、アーリーフィードバックで使用される短期の平均RTCP帯域幅がアーリーフィードバックなしで使用される帯域幅を超えないようにするためです。
event to
report
detected
|
| RTCP feedback range
| (T_max_fb_delay)
vXXXXXXXXXXXXXXXXXXXXXXXXXXX ) )
|---+--------+-------------+-----+------------| |--------+--->
| | | | ( ( |
| t0 te |
tp tn
\_______ ________/
\/
T_dither_max
Figure 2: Event report and parameters for Early RTCP scheduling
図2：初期RTCPスケジューリングのイベントレポートとパラメーター
Let S0 be an active sender (out of S senders) and let N be the number of receivers with R being one of these receivers.
S0をアクティブな送信者（S送信者のうち）とし、Nを受信者の数とし、Rをこれらの受信者の1つとします。
Assume that R has verified that using feedback mechanisms is reasonable at the current constellation (which is highly application specific and hence not specified in this document).
現在のコンステレーションでフィードバックメカニズムを使用することが妥当であることをRが確認したと想定します（これは非常にアプリケーション固有であるため、このドキュメントでは指定されていません）。
Assume further that T_rr_interval is 0, if no minimal interval between Regular RTCP packets is to be enforced, or T_rr_interval is set to some meaningful value, as given by the application. This value then denotes the minimal interval between Regular RTCP packets.
さらに、通常のRTCPパケット間の最小間隔を強制しない場合、またはアプリケーションによって指定された意味のある値にT_rr_intervalが設定されている場合は、T_rr_intervalが0であると想定します。この値は、通常のRTCPパケット間の最小間隔を示します。
With this, a receiver R MUST use the following rules for transmitting one or more FB messages as minimal or full compound RTCP packet.
これにより、受信者Rは次のルールを使用して、1つ以上のFBメッセージを最小または完全な複合RTCPパケットとして送信する必要があります。
Initially, R MUST set allow_early = TRUE and t_rr_last = NaN (Not-a-Number, i.e., some invalid value that can be distinguished from a valid time).
最初に、Rはallow_early = TRUEおよびt_rr_last = NaNを設定する必要があります（Not-a-Number、つまり有効な時間と区別できる無効な値）。
Furthermore, the initialization of the RTCP variables as per [1] applies except for the initial value for Tmin. For a point-to-point session, the initial Tmin is set to 0. For a multiparty session, Tmin is initialized to 1.0 seconds.
さらに、Tminの初期値を除いて、[1]によるRTCP変数の初期化が適用されます。ポイントツーポイントセッションの場合、初期Tminは0に設定されます。マルチパーティセッションの場合、Tminは1.0秒に初期化されます。
Assume that R had scheduled the last Regular RTCP RR packet for transmission at tp (and sent or suppressed this packet at tp) and has scheduled the next transmission (including possible reconsideration as per [1]) for tn = tp + T_rr. Assume also that the last Regular RTCP packet transmission has occurred at t_rr_last.
Rが最後のレギュラーRTCP RRパケットをtpで送信するようにスケジュールし（そしてこのパケットをtpで送信または抑制する）、tn = tp + T_rrについて次の送信（[1]による再考の可能性を含む）をスケジュールしたと想定します。また、最後の標準RTCPパケット送信がt_rr_lastで発生したと仮定します。
The Early Feedback algorithm then comprises the following steps:
早期フィードバックアルゴリズムは、次の手順で構成されます。
1. At time t0, R detects the need to transmit one or more FB messages, e.g., because media "units" need to be ACKed or NACKed, and finds that providing the feedback information is potentially useful for the sender.
1. 時間t0で、Rは1つまたは複数のFBメッセージを送信する必要があることを検出します。たとえば、メディア「ユニット」にACKまたはNACKを送信する必要があるため、フィードバック情報の提供が送信者にとって役立つ可能性があることがわかります。
2. R first checks whether there is already a compound RTCP packet containing one or more FB messages scheduled for transmission (either as Early or as Regular RTCP packet).
2. Rはまず、送信がスケジュールされた1つ以上のFBメッセージを含む複合RTCPパケットがすでにあるかどうかを確認します（早期または通常のRTCPパケットとして）。
2a) If so, the new FB message MUST be included in the scheduled packet; the scheduling of the waiting compound RTCP packet MUST remain unchanged. When doing so, the available feedback information SHOULD be merged to produce as few FB messages as possible. This completes the course of immediate actions to be taken.
2a）その場合、新しいFBメッセージはスケジュールされたパケットに含まれなければなりません。待機中の複合RTCPパケットのスケジューリングは変更されないままである必要があります。その際、利用可能なフィードバック情報をマージして、可能な限り少ないFBメッセージを生成する必要があります（SHOULD）。これで、取るべき即時のアクションのコースが完了します。
2b) If no compound RTCP packet is already scheduled for transmission, a new (minimal or full) compound RTCP packet MUST be created and the minimal interval for T_dither_max MUST be chosen as follows:
2b）複合RTCPパケットの送信がスケジュールされていない場合は、新しい（最小または完全）複合RTCPパケットを作成し、T_dither_maxの最小間隔を次のように選択する必要があります。
i) If the session is a point-to-point session, then
i) セッションがポイントツーポイントセッションの場合、
T_dither_max = 0.
T_dither_max = 0。
ii) If the session is a multiparty session, then
ii）セッションがマルチパーティセッションの場合、
T_dither_max = l * T_rr
T_dither_max = l * T_rr
with l=0.5.
l = 0.5で。
The value for T_dither_max MAY be calculated differently (e.g., based upon RTT), which MUST then be specified in a future document. Such a future specification MUST ensure that all RTP receivers use the same mechanism to calculate T_dither_max.
T_dither_maxの値は別の方法で（たとえば、RTTに基づいて）計算される場合があり、将来のドキュメントで指定する必要があります。このような将来の仕様では、すべてのRTP受信者が同じメカニズムを使用してT_dither_maxを計算することを保証する必要があります。
The values given above for T_dither_max are minimal values. Application-specific feedback considerations may make it worthwhile to increase T_dither_max beyond this value. This is up to the discretion of the implementer.
上記のT_dither_maxの値は最小値です。アプリケーション固有のフィードバックの考慮事項により、T_dither_maxをこの値を超えて増加させる価値がある場合があります。これは実装者の裁量次第です。
3. Then, R MUST check whether its next Regular RTCP packet would be within the time bounds for the Early RTCP packet triggered at t0, i.e., if t0 + T_dither_max > tn.
3. 次に、Rは次の標準RTCPパケットがt0でトリガーされたEarly RTCPパケットの時間境界内にあるかどうか、つまり、t0 + T_dither_max> tnであるかどうかを確認する必要があります。
3a) If so, an Early RTCP packet MUST NOT be scheduled; instead, the FB message(s) MUST be stored to be included in the Regular RTCP packet scheduled for tn. This completes the course of immediate actions to be taken.
3a）その場合、Early RTCPパケットをスケジュールしてはなりません（MUST NOT）。代わりに、FBメッセージは、tnにスケジュールされた通常のRTCPパケットに含まれるように格納する必要があります。これで、取るべき即時のアクションのコースが完了します。
3b) Otherwise, the following steps are carried out.
3b）それ以外の場合は、次の手順が実行されます。
4. R MUST check whether it is allowed to transmit an Early RTCP packet, i.e., allow_early == TRUE, or not.
4. Rは、Early RTCPパケットの送信が許可されているかどうか、つまり、allow_early == TRUEかどうかを確認する必要があります。
4a) If allow_early == FALSE, then R MUST check the time for the next scheduled Regular RTCP packet:
4a）allow_early == FALSEの場合、Rは次にスケジュールされた標準RTCPパケットの時間をチェックする必要があります：
1. If tn - t0 < T_max_fb_delay, then the feedback could still be useful for the sender, despite the late reporting. Hence, R MAY create an RTCP FB message to be included in the Regular RTCP packet for transmission at tn.
1. tn-t0 <T_max_fb_delayの場合、レポートが遅れているにもかかわらず、フィードバックは送信者にとって依然として役立つ可能性があります。したがって、Rは、tnでの送信用に標準RTCPパケットに含まれるRTCP FBメッセージを作成できます（MAY）。
2. Otherwise, R MUST discard the RTCP FB message.
2. それ以外の場合、RはRTCP FBメッセージを破棄する必要があります。
This completes the immediate course of actions to be taken.
これにより、取るべき行動の即時のコースが完了します。
4b) If allow_early == TRUE, then R MUST schedule an Early RTCP packet for te = t0 + RND * T_dither_max with RND being a pseudo random function evenly distributed between 0 and 1.
4b）allow_early == TRUEの場合、Rはte = t0 + RND * T_dither_maxのEarly RTCPパケットをスケジュールする必要があります。RNDは、0と1の間で均等に分散された擬似ランダム関数です。
5. R MUST detect overlaps in FB messages received from other members of the RTP session and the FB messages R wants to send. Therefore, while a member of the RTP session, R MUST continuously monitor the arrival of (minimal) compound RTCP packets and store each FB message contained in these RTCP packets for at least T_retention. When scheduling the transmission of its own FB message following steps 1 through 4 above, R MUST check each of the stored and newly received FB messages from the RTCP packets received during the interval [t0 - T_retention ; te] and act as follows:
5. Rは、RTPセッションの他のメンバーから受信したFBメッセージと、Rが送信したいFBメッセージの重複を検出する必要があります。したがって、RTPセッションのメンバーである間、Rは（最小の）複合RTCPパケットの到着を継続的に監視し、少なくともT_retentionの間、これらのRTCPパケットに含まれる各FBメッセージを格納する必要があります。上記のステップ1から4に従って独自のFBメッセージの送信をスケジュールする場合、Rは、間隔[t0-T_retention;の間に受信したRTCPパケットから、保存および新しく受信したFBメッセージのそれぞれをチェックする必要があります。 te]そして次のように行動します：
5a) If R understands the received FB message's semantics and the message contents is a superset of the feedback R wanted to send, then R MUST discard its own FB message and MUST re-schedule the next Regular RTCP packet transmission for tn (as calculated before).
5a）Rが受信したFBメッセージのセマンティクスを理解し、メッセージの内容がRが送信したいフィードバックのスーパーセットである場合、Rは自身のFBメッセージを破棄し、tnの次の通常のRTCPパケット送信を再スケジュールしなければなりません（以前に計算されたとおり） ）。
5b) If R understands the received FB message's semantics and the message contents is not a superset of the feedback R wanted to send, then R SHOULD transmit its own FB message as scheduled. If there is an overlap between the feedback information to send and the feedback information received, the amount of feedback transmitted is up to R: R MAY leave its feedback information to be sent unchanged, R MAY as well eliminate any redundancy between its own feedback and the feedback received so far from other session members.
5b）Rが受信したFBメッセージのセマンティクスを理解し、メッセージの内容がRが送信したいフィードバックのスーパーセットでない場合、Rはスケジュールどおりに独自のFBメッセージを送信する必要があります（SHOULD）。送信するフィードバック情報と受信したフィードバック情報に重複がある場合、送信されるフィードバックの量は最大Rです。Rはフィードバック情報を変更せずに送信できます。Rは、自身のフィードバックとこれまでに他のセッションメンバーから受け取ったフィードバック。
5c) If R does not understand the received FB message's semantics, R MAY keep its own FB message scheduled as an Early RTCP packet, or R MAY re-schedule the next Regular RTCP packet transmission for tn (as calculated before) and MAY append the FB message to the now regularly scheduled RTCP message.
5c）Rが受信したFBメッセージのセマンティクスを理解していない場合、Rは独自のFBメッセージをEarly RTCPパケットとしてスケジュールしたままにするか、Rはtn（前に計算された）の次の標準RTCPパケット送信を再スケジュールして、現在定期的にスケジュールされているRTCPメッセージへのFBメッセージ。
Note: With 5c), receiving unknown FB messages may not lead to feedback suppression at a particular receiver. As a consequence, a given event may cause M different types of FB messages (which are all appropriate but not mutually understood) to be scheduled, so that a "large" receiver group may effectively be partitioned into at most M groups. Among members of each of these M groups, feedback suppression will occur following 5a and 5b but no suppression will happen across groups. As a result, O(M) RTCP FB messages may be received by the sender. Hence, there is a chance for a very limited feedback implosion. However, as sender(s) and all receivers make up the same application using the same (set of) codecs in the same RTP session, only little divergence in semantics for FB messages can safely be assumed and, therefore, M is assumed to be small in the general case.
注：5c）では、不明なFBメッセージを受信しても、特定の受信機でフィードバックが抑制されない場合があります。結果として、特定のイベントにより、Mの異なるタイプのFBメッセージ（すべて適切ですが、相互に理解されない）がスケジュールされ、「大きな」レシーバーグループが最大でMグループに効果的に分割される場合があります。これらの各Mグループのメンバー間で、フィードバック抑制は5aおよび5bの後に発生しますが、グループ間で抑制は発生しません。その結果、O（M）RTCP FBメッセージが送信者によって受信される場合があります。そのため、フィードバックが非常に制限される可能性があります。ただし、送信者とすべての受信者が同じRTPセッションで同じ（セットの）コーデックを使用して同じアプリケーションを構成するため、FBメッセージのセマンティクスの相違はほんの少ししか想定できないため、Mは一般的なケースでは小さい。
Given further that the O(M) FB messages are randomly distributed over a time interval of T_dither_max, we find that the resulting limited number of extra compound RTCP packets (a) is assumed not to overwhelm the sender and (b) should be conveyed as all contain complementary pieces of information.
さらに、O（M）FBメッセージがT_dither_maxの時間間隔でランダムに分散されると、結果として生じる限られた数の追加の複合RTCPパケット（a）が送信者を圧倒しないと想定され、（b）は次のように伝達されます。すべて補完的な情報が含まれています。
6. If R's FB message(s) was not suppressed by other receiver FB messages as per 5, when te is reached, R MUST transmit the (minimal) compound RTCP packet containing its FB message(s). R then MUST set allow_early = FALSE, MUST recalculate tn = tp + 2*T_rr, and MUST set tp to the previous tn. As soon as the newly calculated tn is reached, regardless whether R sends its next Regular RTCP packet or suppresses it because of T_rr_interval, it MUST set allow_early = TRUE again.
6. RのFBメッセージが他の受信者FBメッセージによって5に従って抑制されなかった場合、teに到達すると、RはそのFBメッセージを含む（最小の）複合RTCPパケットを送信しなければなりません（MUST）。 Rは、allow_early = FALSEを設定する必要があり、tn = tp + 2 * T_rrを再計算する必要があり、tpを以前のtnに設定する必要があります。新しく計算されたtnに達するとすぐに、Rが次の標準RTCPパケットを送信するか、T_rr_intervalのためにそれを抑制するかに関係なく、allow_early = TRUEを再度設定する必要があります。
Full compound RTCP packets MUST be sent in regular intervals. These packets MAY also contain one or more FB messages. Transmission of Regular RTCP packets is scheduled as follows:
完全な複合RTCPパケットは定期的に送信する必要があります。これらのパケットには、1つ以上のFBメッセージも含まれる場合があります。通常のRTCPパケットの送信は、次のようにスケジュールされます。
If T_rr_interval == 0, then the transmission MUST follow the rules as specified in Sections 3.2 and 3.4 of this document and MUST adhere to the adjustments of tn specified in Section 3.5.2 (i.e., skip one regular transmission if an Early RTCP packet transmission has occurred). Timer reconsideration takes place when tn is reached as per [1]. The Regular RTCP packet is transmitted after timer reconsideration. Whenever a Regular RTCP packet is sent or suppressed, allow_early MUST be set to TRUE and tp, tn MUST be updated as per [1]. After the first transmission of a Regular RTCP packet, Tmin MUST be set to 0.
T_rr_interval == 0の場合、送信は、このドキュメントのセクション3.2および3.4で指定されたルールに従い、セクション3.5.2で指定されたtnの調整に従う必要があります（つまり、早期RTCPパケット送信の場合、1つの通常の送信をスキップする必要があります）発生しました）。 [1]のようにtnに達すると、タイマーの再検討が行われます。通常のRTCPパケットは、タイマーの再検討後に送信されます。通常のRTCPパケットが送信または抑制される場合は常に、allow_earlyをTRUEおよびtpに設定する必要があり、tp、tnは[1]に従って更新する必要があります。通常のRTCPパケットの最初の送信後、Tminを0に設定する必要があります。
If T_rr_interval != 0, then the calculation for the transmission times MUST follow the rules as specified in Sections 3.2 and 3.4 of this document and MUST adhere to the adjustments of tn specified in Section 3.5.2 (i.e., skip one regular transmission if an Early RTCP transmission has occurred). Timer reconsideration takes place when tn is reached as per [1]. After timer reconsideration, the following actions are taken:
T_rr_interval！= 0の場合、送信時間の計算は、このドキュメントのセクション3.2および3.4で指定されたルールに従い、セクション3.5.2で指定されたtnの調整に従う必要があります（つまり、初期のRTCP送信が発生しました）。 [1]のようにtnに達すると、タイマーの再検討が行われます。タイマーの再検討後、次のアクションが実行されます。
1. If no Regular RTCP packet has been sent before (i.e., if t_rr_last == NaN), then a Regular RTCP packet MUST be scheduled. Stored FB messages MAY be included in the Regular RTCP packet. After the scheduled packet has been sent, t_rr_last MUST be set to tn. Tmin MUST be set to 0.
1. 以前に通常のRTCPパケットが送信されていない場合（つまり、t_rr_last == NaNの場合）、通常のRTCPパケットをスケジュールする必要があります。保存されたFBメッセージは、通常のRTCPパケットに含まれる場合があります。スケジュールされたパケットが送信された後、t_rr_lastをtnに設定する必要があります。 Tminは0に設定する必要があります。
2. Otherwise, a temporary value T_rr_current_interval is calculated as follows:
2. それ以外の場合、一時的な値T_rr_current_intervalは次のように計算されます。
T_rr_current_interval = RND*T_rr_interval
T_rr_current_interval = RND * T_rr_interval
with RND being a pseudo random function evenly distributed between 0.5 and 1.5. This dithered value is used to determine one of the following alternatives:
RNDは、0.5と1.5の間で均等に分布する疑似ランダム関数です。このディザリングされた値は、次の選択肢のいずれかを決定するために使用されます。
2a) If t_rr_last + T_rr_current_interval <= tn, then a Regular RTCP packet MUST be scheduled. Stored RTCP FB messages MAY be included in the Regular RTCP packet. After the scheduled packet has been sent, t_rr_last MUST be set to tn.
2a）t_rr_last + T_rr_current_interval <= tnの場合、通常のRTCPパケットをスケジュールする必要があります。保存されたRTCP FBメッセージは、通常のRTCPパケットに含めることができます。スケジュールされたパケットが送信された後、t_rr_lastをtnに設定する必要があります。
2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB messages have been stored and are awaiting transmission, an RTCP packet MUST be scheduled for transmission at tn. This RTCP packet MAY be a minimal or a Regular RTCP packet (at the discretion of the implementer), and the compound RTCP packet MUST include the stored RTCP FB message(s). t_rr_last MUST remain unchanged.
2b）t_rr_last + T_rr_current_interval> tnおよびRTCP FBメッセージが保存されており、送信を待機している場合、RTCPパケットはtnで送信するようにスケジュールする必要があります。このRTCPパケットは最小または通常のRTCPパケット（実装者の裁量による）である可能性があり、複合RTCPパケットは格納されたRTCP FBメッセージを含まなければなりません（MUST）。 t_rr_lastは変更しないでください。
2c) Otherwise (if t_rr_last + T_rr_current_interval > tn but no stored RTCP FB messages are awaiting transmission), the compound RTCP packet MUST be suppressed (i.e., it MUST NOT be scheduled). t_rr_last MUST remain unchanged.
2c）それ以外の場合（t_rr_last + T_rr_current_interval> tnであるが、保存されているRTCP FBメッセージが送信を待機していない場合）、複合RTCPパケットは抑制されなければならない（つまり、スケジュールされてはならない）。 t_rr_lastは変更しないでください。
In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST be set to TRUE (possibly after sending the Regular RTCP packet) and tp and tn MUST be updated following the rules of [1] except for the five second minimum.
上記の4つのケースすべて（1、2a、2b、および2c）では、allow_earlyをTRUEに設定する必要があり（通常のRTCPパケットを送信した後）、tpとtnを5つを除いて[1]のルールに従って更新する必要があります。 2番目の最小値。
If T_rr_interval != 0, then the timeout calculation for RTP/AVPF entities (Section 6.3.5 of [1]) MUST be modified to use T_rr_interval instead of Tmin for computing Td and thus M*Td for timing out RTP entities.
T_rr_interval！= 0の場合、RTP / AVPFエンティティのタイムアウト計算（[1]のセクション6.3.5）を変更して、Tdの計算にTminの代わりにT_rr_intervalを使用し、RTPエンティティのタイムアウトにM * Tdを使用する必要があります。
Whenever a compound RTCP packet is sent or received -- minimal or full compound, Early or Regular -- the avg_rtcp_size variable MUST be updated accordingly (see [1]) and subsequent computations of tn MUST use the new avg_rtcp_size.
複合RTCPパケットが送信または受信されるときは常に-最小または完全複合、EarlyまたはRegular-avg_rtcp_size変数はそれに応じて更新されなければならず（[1]を参照）、tnの後続の計算では新しいavg_rtcp_sizeを使用する必要があります。
This section provides some guidelines to the group sizes at which the various feedback modes may be used.
このセクションでは、さまざまなフィードバックモードを使用できるグループサイズのガイドラインを示します。
The RTP session MUST have exactly two members and this group size MUST NOT grow, i.e., it MUST be point-to-point communications. Unicast addresses SHOULD be used in the session description.
RTPセッションには2つのメンバーが含まれている必要があり、このグループのサイズは拡大してはなりません。つまり、ポイントツーポイント通信でなければなりません。ユニキャストアドレスは、セッションの説明で使用する必要があります（SHOULD）。
For unidirectional as well as bi-directional communication between two parties, 2.5% of the RTP session bandwidth is available for RTCP traffic from the receivers including feedback. For a 64-kbit/s stream this yields 1,600 bit/s for RTCP. If we assume an average of 96 bytes (=768 bits) per RTCP packet, a receiver can report 2 events per second back to the sender. If acknowledgements for 10 events are collected in each FB message, then 20 events can be acknowledged per second. At 256 kbit/s, 8 events could be reported per second; thus, the ACKs may be sent in a finer granularity (e.g., only combining three ACKs per FB message).
2つのパーティ間の単方向通信と双方向通信の場合、RTPセッション帯域幅の2.5％が、フィードバックを含む受信側からのRTCPトラフィックに利用できます。 64 kbit / sストリームの場合、これはRTCPで1,600 bit / sになります。 RTCPパケットあたり平均96バイト（= 768ビット）を想定すると、受信側は1秒あたり2つのイベントを送信側に報告できます。各FBメッセージで10個のイベントの確認応答が収集される場合、1秒あたり20件のイベントを確認応答できます。 256 kbit / sでは、1秒あたり8つのイベントが報告されます。したがって、ＡＣＫは、より細かい粒度で送信されてもよい（例えば、ＦＢメッセージごとに３つのＡＣＫのみを組み合わせる）。
From 1 Mbit/s upwards, a receiver would be able to acknowledge each individual frame (not packet!) in a 30-fps video stream.
1 Mbit / s以上から、レシーバーは30 fpsのビデオストリーム内の個々のフレーム（パケットではありません！）を確認できます。
ACK strategies MUST be defined to work properly with these bandwidth limitations. An indication whether or not ACKs are allowed for a session and, if so, which ACK strategy should be used, MAY be conveyed by out-of-band mechanisms, e.g., media-specific attributes in a session description using SDP.
これらの帯域幅制限で適切に機能するように、ACK戦略を定義する必要があります。セッションでACKが許可されるかどうか、および許可される場合はどのACK戦略を使用する必要があるかの指示は、帯域外メカニズム、たとえば、SDPを使用するセッション記述内のメディア固有の属性によって伝達される場合があります。
Negative acknowledgements (and the other types of feedback exhibiting similar reporting characteristics) MUST be used for all sessions with a group size that may grow larger than two. Of course, NACKs MAY be used for point-to-point communications as well.
否定応答（および同様のレポート特性を示す他のタイプのフィードバック）は、グループサイズが2より大きくなる可能性があるすべてのセッションで使用する必要があります。もちろん、NACKはポイントツーポイント通信にも使用できます。
Whether or not the use of Early RTCP packets should be considered depends upon a number of parameters including session bandwidth, codec, special type of feedback, and number of senders and receivers.
Early RTCPパケットの使用を検討する必要があるかどうかは、セッション帯域幅、コーデック、特別なタイプのフィードバック、送信者と受信者の数など、いくつかのパラメータに依存します。
The most important parameters when determining the mode of operation are the allowed minimal interval between two compound RTCP packets (T_rr) and the average number of events that presumably need reporting per time interval (plus their distribution over time, of course). The minimum interval can be derived from the available RTCP bandwidth and the expected average size of an RTCP packet. The number of events to report (e.g., per second) may be derived from the packet loss rate and sender's rate of transmitting packets. From these two values, the allowable group size for the Immediate Feedback mode can be calculated.
動作モードを決定する際の最も重要なパラメーターは、2つの複合RTCPパケット間の許容最小間隔（T_rr）と、時間間隔ごとにレポートが必要と思われるイベントの平均数です（もちろん、時間に対する分布も同様です）。最小間隔は、利用可能なRTCP帯域幅とRTCPパケットの予想平均サイズから導出できます。報告するイベントの数（1秒あたりなど）は、パケット損失率と送信側のパケット送信率から導出できます。これらの2つの値から、即時フィードバックモードの許容グループサイズを計算できます。
As stated in Section 3.3:
セクション3.3で述べたように：
Let N be the average number of events to be reported per interval T by a receiver, B the RTCP bandwidth fraction for this particular receiver, and R the average RTCP packet size, then the receiver operates in Immediate Feedback mode as long as N<=B*T/R.
Nを間隔Tあたりに受信者が報告するイベントの平均数、Bをこの特定の受信者のRTCP帯域幅の割合、Rを平均RTCPパケットサイズとすると、N <=である限り、受信者は即時フィードバックモードで動作します。 B * T / R。
The upper bound for the Early RTCP mode then solely depends on the acceptable quality degradation, i.e., how many events per time interval may go unreported.
したがって、初期RTCPモードの上限は、許容できる品質の低下、つまり、時間間隔あたりのイベント数が報告されない可能性があることにのみ依存します。
As stated in Section 3.3:
セクション3.3で述べたように：
Using the above notation, Early RTCP mode can be roughly characterized by N > B*T/R as "lower bound". An estimate for an upper bound is more difficult. Setting N=1, we obtain for a given R and B the interval T = R/B as average interval between events to be reported. This information can be used as a hint to determine whether or not early transmission of RTCP packets is useful.
上記の表記を使用すると、Early RTCPモードは「下限」としてN> B * T / Rによって大まかに特徴付けることができます。上限の推定はより困難です。 N = 1を設定すると、指定されたRとBについて、レポートされるイベント間の平均間隔として間隔T = R / Bが取得されます。この情報は、RTCPパケットの早期送信が有用かどうかを判断するためのヒントとして使用できます。
Example: If a 256-kbit/s video with 30 fps is transmitted through a network with an MTU size of some 1,500 bytes, then, in most cases, each frame would fit in into one packet leading to a packet rate of 30 packets per second. If 5% packet loss occurs in the network (equally distributed, no inter-dependence between receivers), then each receiver will, on average, have to report 3 packets lost each two seconds. Assuming a single sender and more than three receivers, this yields 3.75% of the RTCP bandwidth allocated to the receivers and thus 9.6 kbit/s. Assuming further a size of 120 bytes for the average compound RTCP packet allows 10 RTCP packets to be sent per second or 20 in two seconds. If every receiver needs to report three lost packets per two seconds, this yields a maximum group size of 6-7 receivers if all loss events are reported. The rules for transmission of Early RTCP packets should provide sufficient flexibility for most of this reporting to occur in a timely fashion.
例：30 kpsの256 kbit / sビデオが約1,500バイトのMTUサイズのネットワークを介して送信される場合、ほとんどの場合、各フレームは1つのパケットに収まり、30パケット/秒のパケットレートになります。第二。ネットワークで5％のパケット損失が発生した場合（均等に分散され、レシーバー間の相互依存性がない場合）、各レシーバーは平均して、2秒ごとに3パケットの損失を報告する必要があります。単一の送信者と4つ以上の受信者を想定すると、受信者に割り当てられるRTCP帯域幅の3.75％、つまり9.6 kbit / sが得られます。さらに、平均的な複合RTCPパケットのサイズが120バイトであるとすると、1秒あたり10個のRTCPパケット、または2秒で20個のRTCPパケットを送信できます。すべてのレシーバーが2秒ごとに3つの損失パケットを報告する必要がある場合、すべての損失イベントが報告される場合、これにより6〜7レシーバーの最大グループサイズが生成されます。 Early RTCPパケットの送信に関するルールは、このレポートのほとんどがタイムリーに発生するのに十分な柔軟性を提供する必要があります。
Extending this example to determine the upper bound for Early RTCP mode could lead to the following considerations: assume that the underlying coding scheme and the application (as well as the tolerant users) allow on the order of one loss without repair per two seconds. Thus, the number of packets to be reported by each receiver decreases to two per two seconds and increases the group size to 10. Assuming further that some number of packet losses are correlated, feedback traffic is further reduced and group sizes of some 12 to 16 (maybe even 20) can be reasonably well supported using Early RTCP mode. Note that all these considerations are based upon statistics and will fail to hold in some cases.
この例を拡張してEarly RTCPモードの上限を決定すると、次の考慮事項につながる可能性があります。基礎となるコーディングスキームとアプリケーション（および許容ユーザー）が、2秒あたりの修復なしで約1つの損失を許容すると仮定します。したがって、各レシーバーによって報告されるパケット数は2秒あたり2に減少し、グループサイズは10に増加します。さらに、いくつかのパケット損失が相関していると仮定すると、フィードバックトラフィックはさらに減少し、グループサイズは約12〜16になります。 （たぶん20）は、Early RTCPモードを使用して十分にサポートできます。これらの考慮事項はすべて統計に基づいており、場合によっては維持できないことに注意してください。
Before even considering whether or not to send RTCP feedback information, an application has to determine whether this mechanism is applicable:
RTCPフィードバック情報を送信するかどうかを検討する前に、アプリケーションはこのメカニズムが適用可能かどうかを判断する必要があります。
1) An application has to decide whether -- for the current ratio of packet rate with the associated (application-specific) maximum feedback delay and the currently observed round-trip time (if available) -- feedback mechanisms can be applied at all.
1）アプリケーションは、関連する（アプリケーション固有の）最大フィードバック遅延を伴う現在のパケットレートの比率と、現在観測されている往復時間（可能な場合）に対して、フィードバックメカニズムを適用できるかどうかを決定する必要があります。
This decision may be based upon (and dynamically revised following) RTCP reception statistics as well as out-of-band mechanisms.
この決定は、RTCP受信統計と帯域外メカニズムに基づいて行われます（動的に変更されます）。
2) The application has to decide -- for a certain observed error rate, assigned bandwidth, frame/packet rate, and group size -- whether (and which) feedback mechanisms can be applied.
2）アプリケーションは、特定の観測されたエラー率、割り当てられた帯域幅、フレーム/パケットレート、およびグループサイズについて、フィードバックメカニズムを適用できるかどうか（およびどのフィードバックメカニズムを適用できるか）を決定する必要があります。
Regular RTCP reception statistics provide valuable input to this step, too.
定期的なRTCP受信統計も、このステップに貴重な情報を提供します。
3) If the application decides to send feedback, the application has to follow the rules for transmitting Early RTCP packets or Regular RTCP packets containing FB messages.
3）アプリケーションがフィードバックを送信することを決定した場合、アプリケーションは、FBメッセージを含むEarly RTCPパケットまたはRegular RTCPパケットを送信するためのルールに従う必要があります。
4) The type of RTCP feedback sent should not duplicate information available to the sender from a lower layer transport protocol. That is, if the transport protocol provides negative or positive acknowledgements about packet reception (such as DCCP), the receiver should avoid repeating the same information at the RTCP layer (i.e., abstain from sending Generic NACKs).
4）送信されるRTCPフィードバックのタイプは、下位層のトランスポートプロトコルから送信者が利用できる情報と重複してはなりません。つまり、トランスポートプロトコルがパケット受信（DCCPなど）に関する否定応答または肯定応答を提供する場合、受信者はRTCPレイヤーで同じ情報を繰り返すことを避けます（つまり、汎用NACKの送信を控えます）。
Media sessions are typically described using out-of-band mechanisms to convey transport addresses, codec information, etc., between sender(s) and receiver(s). Such a mechanism is two-fold: a format used to describe a media session and another mechanism for transporting this description.
メディアセッションは、送信者と受信者の間でトランスポートアドレス、コーデック情報などを伝達するために、通常、帯域外メカニズムを使用して記述されます。そのようなメカニズムは2つあります。メディアセッションを記述するために使用されるフォーマットと、この記述を転送するための別のメカニズムです。
In the IETF, the Session Description Protocol (SDP) is currently used to describe media sessions while protocols such as SIP, Session Announcement Protocol (SAP), Real Time Streaming Protocol (RTSP), and HTTP (among others) are used to convey the descriptions.
IETFでは、現在、セッション記述プロトコル（SDP）はメディアセッションの記述に使用されていますが、SIP、セッションアナウンスメントプロトコル（SAP）、リアルタイムストリーミングプロトコル（RTSP）、HTTP（その他）などのプロトコルは、説明。
A media session description format MAY include parameters to indicate that RTCP feedback mechanisms are supported in this session and which of the feedback mechanisms MAY be applied.
メディアセッション記述フォーマットには、RTCPフィードバックメカニズムがこのセッションでサポートされていること、およびどのフィードバックメカニズムが適用されるかを示すパラメーターが含まれる場合があります。
To do so, the profile "AVPF" MUST be indicated instead of "AVP". Further attributes may be defined to show which type(s) of feedback are supported.
そのためには、「AVP」ではなく、プロファイル「AVPF」を指定する必要があります。サポートされるフィードバックのタイプを示すために、さらに属性を定義できます。
Section 4 contains the syntax specification to support RTCP feedback with SDP. Similar specifications for other media session description formats are outside the scope of this document.
セクション4には、SDPでRTCPフィードバックをサポートする構文仕様が含まれています。他のメディアセッション記述形式の同様の仕様は、このドキュメントの範囲外です。
This section defines a number of additional SDP parameters that are used to describe a session. All of these are defined as media-level attributes.
このセクションでは、セッションの説明に使用されるいくつかの追加のSDPパラメータを定義します。これらはすべて、メディアレベルの属性として定義されています。
The AV profile defined in [4] is referred to as "AVP" in the context of, e.g., the Session Description Protocol (SDP) [3]. The profile specified in this document is referred to as "AVPF".
[4]で定義されているAVプロファイルは、セッション記述プロトコル（SDP）[3]などのコンテキストでは「AVP」と呼ばれます。このドキュメントで指定されているプロファイルは「AVPF」と呼ばれます。
Feedback information following the modified timing rules as specified in this document MUST NOT be sent for a particular media session unless the description for this session indicates the use of the "AVPF" profile (exclusively or jointly with other AV profiles).
このドキュメントで指定されている変更されたタイミングルールに従うフィードバック情報は、このセッションの説明で「AVPF」プロファイルの使用が示されている場合（他のAVプロファイルと排他的または共同で）を除いて、特定のメディアセッションに送信してはなりません。
A new payload format-specific SDP attribute is defined to indicate the capability of using RTCP feedback as specified in this document: "a=rtcp-fb". The "rtcp-fb" attribute MUST only be used as an SDP media attribute and MUST NOT be provided at the session level. The "rtcp-fb" attribute MUST only be used in media sessions for which the "AVPF" is specified.
このドキュメントで指定されているRTCPフィードバックを使用する機能を示すために、新しいペイロード形式固有のSDP属性が定義されています： "a = rtcp-fb"。 「rtcp-fb」属性は、SDPメディア属性としてのみ使用する必要があり、セッションレベルで提供してはなりません。 「rtcp-fb」属性は、「AVPF」が指定されているメディアセッションでのみ使用する必要があります。
The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB messages MAY be used in this media session for the indicated payload type. A wildcard payload type ("*") MAY be used to indicate that the RTCP feedback attribute applies to all payload types. If several types of feedback are supported and/or the same feedback shall be specified for a subset of the payload types, several "a=rtcp-fb" lines MUST be used.
「rtcp-fb」属性は、指定されたペイロードタイプのこのメディアセッションで使用できるRTCP FBメッセージを示すために使用する必要があります（SHOULD）。ワイルドカードペイロードタイプ（ "*"）は、RTCPフィードバック属性がすべてのペイロードタイプに適用されることを示すために使用される場合があります。複数のタイプのフィードバックがサポートされている場合、および/またはペイロードタイプのサブセットに同じフィードバックが指定されている場合は、複数の「a = rtcp-fb」行を使用する必要があります。
If no "rtcp-fb" attribute is specified, the RTP receivers MAY send feedback using other suitable RTCP feedback packets as defined for the respective media type. The RTP receivers MUST NOT rely on the RTP senders reacting to any of the FB messages. The RTP sender MAY choose to ignore some feedback messages.
「rtcp-fb」属性が指定されていない場合、RTPレシーバーは、それぞれのメディアタイプに対して定義されている他の適切なRTCPフィードバックパケットを使用してフィードバックを送信できます。 RTP受信者は、FBメッセージのいずれかに反応するRTP送信者に依存してはなりません（MUST NOT）。 RTP送信者は、一部のフィードバックメッセージを無視することを選択できます。
If one or more "rtcp-fb" attributes are present in a media session description, the RTCP receivers for the media session(s) containing the "rtcp-fb"
1つ以上の「rtcp-fb」属性がメディアセッションの説明に存在する場合、「rtcp-fb」を含むメディアセッションのRTCPレシーバー
o MUST ignore all "rtcp-fb" attributes of which they do not fully understand the semantics (i.e., where they do not understand the meaning of all values in the "a=rtcp-fb" line);
o セマンティクスを完全に理解していないすべての「rtcp-fb」属性を無視する必要があります（つまり、「a = rtcp-fb」行のすべての値の意味を理解していない場合）。
o SHOULD provide feedback information as specified in this document using any of the RTCP feedback packets as specified in one of the "rtcp-fb" attributes for this media session; and
o このメディアセッションの「rtcp-fb」属性の1つで指定されているRTCPフィードバックパケットのいずれかを使用して、このドキュメントで指定されているフィードバック情報を提供する必要があります。そして
o MUST NOT use other FB messages than those listed in one of the "rtcp-fb" attribute lines.
o 「rtcp-fb」属性行の1つにリストされているもの以外のFBメッセージを使用してはなりません。
When used in conjunction with the offer/answer model [8], the offerer MAY present a set of these AVPF attributes to its peer. The answerer MUST remove all attributes it does not understand as well as those it does not support in general or does not wish to use in this particular media session. The answerer MUST NOT add feedback parameters to the media description and MUST NOT alter values of such parameters. The answer is binding for the media session, and both offerer and answerer MUST only use feedback mechanisms negotiated in this way. Both offerer and answerer MAY independently decide to send RTCP FB messages of only a subset of the negotiated feedback mechanisms, but they SHOULD react properly to all types of the negotiated FB messages when received.
オファー/アンサーモデル[8]と組み合わせて使用すると、オファー者はこれらのAVPF属性のセットをピアに提示してもよい（MAY）。回答者は、理解していないすべての属性、および一般にサポートしていない属性、またはこの特定のメディアセッションで使用したくない属性を削除する必要があります。回答者はフィードバックパラメータをメディアの説明に追加してはならず、そのようなパラメータの値を変更してはなりません。答えはメディアセッションに拘束力があり、提供者と回答者の両方がこの方法でネゴシエートされたフィードバックメカニズムのみを使用する必要があります。提供者と回答者の両方が独立して、ネゴシエートされたフィードバックメカニズムのサブセットのみのRTCP FBメッセージを送信することを決定する場合がありますが、ネゴシエートされたすべてのタイプのFBメッセージに受信時に適切に反応する必要があります。
RTP senders MUST be prepared to receive any kind of RTCP FB messages and MUST silently discard all those RTCP FB messages that they do not understand.
RTP送信者は、あらゆる種類のRTCP FBメッセージを受信する準備をしておく必要があり、理解できないすべてのRTCP FBメッセージを警告なしで破棄する必要があります。
The syntax of the "rtcp-fb" attribute is as follows (the feedback types and optional parameters are all case sensitive):
「rtcp-fb」属性の構文は次のとおりです（フィードバックタイプとオプションのパラメーターはすべて大文字と小文字が区別されます）。
(In the following ABNF, fmt, SP, and CRLF are used as defined in [3].)
（以下のABNFでは、[3]で定義されているように、fmt、SP、およびCRLFが使用されます。）
rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
rtcp-fb-pt = "*" ; wildcard: applies to all formats
/ fmt ; as defined in SDP spec
rtcp-fb-val = "ack" rtcp-fb-ack-param
/ "nack" rtcp-fb-nack-param
/ "trr-int" SP 1*DIGIT
/ rtcp-fb-id rtcp-fb-param
rtcp-fb-id = 1*(alpha-numeric / "-" / "_")
rtcp-fb-param = SP "app" [SP byte-string] / SP token [SP byte-string] / ; empty
rtcp-fb-param = SP "app" [SPバイト文字列] / SPトークン[SPバイト文字列] /;空の
rtcp-fb-ack-param = SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
rtcp-fb-nack-param = SP "pli"
/ SP "sli"
/ SP "rpsi"
/ SP "app" [SP byte-string]
/ SP token [SP byte-string]
/ ; empty
The literals of the above grammar have the following semantics:
上記の文法のリテラルには、次の意味があります。
Feedback type "ack":
フィードバックタイプ「ack」：
This feedback type indicates that positive acknowledgements for feedback are supported.
このフィードバックタイプは、フィードバックに対する肯定的な確認応答がサポートされていることを示します。
The feedback type "ack" MUST only be used if the media session is allowed to operate in ACK mode as defined in Section 3.6.1.
フィードバックタイプ「ack」は、メディアセッションがセクション3.6.1で定義されているACKモードで動作することが許可されている場合にのみ使用する必要があります。
Parameters MUST be provided to further distinguish different types of positive acknowledgement feedback.
肯定応答のフィードバックのさまざまなタイプをさらに区別するために、パラメータを提供する必要があります。
The parameter "rpsi" indicates the use of Reference Picture Selection Indication feedback as defined in Section 6.3.3.
パラメータ「rpsi」は、セクション6.3.3で定義されている参照画像選択表示フィードバックの使用を示します。
If the parameter "app" is specified, this indicates the use of application layer feedback. In this case, additional parameters following "app" MAY be used to further differentiate various types of application layer feedback. This document does not define any parameters specific to "app".
パラメータ「app」が指定されている場合、これはアプリケーション層フィードバックの使用を示します。この場合、「app」に続く追加のパラメーターを使用して、さまざまなタイプのアプリケーションレイヤーフィードバックをさらに区別できます。このドキュメントでは、「アプリ」に固有のパラメータは定義していません。
Further parameters for "ack" MAY be defined in other documents.
「ack」のその他のパラメータは、他のドキュメントで定義される場合があります。
Feedback type "nack":
フィードバックタイプ「nack」：
This feedback type indicates that negative acknowledgements for feedback are supported.
このフィードバックタイプは、フィードバックに対する否定応答がサポートされていることを示します。
The feedback type "nack", without parameters, indicates use of the Generic NACK feedback format as defined in Section 6.2.1.
パラメータなしのフィードバックタイプ「nack」は、セクション6.2.1で定義されているGeneric NACKフィードバック形式の使用を示します。
The following three parameters are defined in this document for use with "nack" in conjunction with the media type "video":
このドキュメントでは、「nack」をメディアタイプ「video」とともに使用するために、次の3つのパラメータが定義されています。
o "pli" indicates the use of Picture Loss Indication feedback as defined in Section 6.3.1.
o 「pli」は、セクション6.3.1で定義されているPicture Loss Indicationフィードバックの使用を示します。
o "sli" indicates the use of Slice Loss Indication feedback as defined in Section 6.3.2.
o 「sli」は、セクション6.3.2で定義されているスライス損失表示フィードバックの使用を示します。
o "rpsi" indicates the use of Reference Picture Selection Indication feedback as defined in Section 6.3.3.
o 「rpsi」は、セクション6.3.3で定義されている参照画像選択表示フィードバックの使用を示します。
"app" indicates the use of application layer feedback. Additional parameters after "app" MAY be provided to differentiate different types of application layer feedback. No parameters specific to "app" are defined in this document.
「app」は、アプリケーションレイヤーフィードバックの使用を示します。さまざまなタイプのアプリケーション層フィードバックを区別するために、「app」の後に追加のパラメーターを提供できます。このドキュメントでは、「アプリ」に固有のパラメータは定義されていません。
Further parameters for "nack" MAY be defined in other documents.
「nack」のその他のパラメータは、他のドキュメントで定義される場合があります。
Other feedback types <rtcp-fb-id>:
その他のフィードバックタイプ<rtcp-fb-id>：
Other documents MAY define additional types of feedback; to keep the grammar extensible for those cases, the rtcp-fb-id is introduced as a placeholder. A new feedback scheme name MUST to be unique (and thus MUST be registered with IANA). Along with a new name, its semantics, packet formats (if necessary), and rules for its operation MUST be specified.
他のドキュメントは、追加のタイプのフィードバックを定義するかもしれません。それらの場合に文法を拡張可能に保つために、rtcp-fb-idがプレースホルダーとして導入されています。新しいフィードバックスキーム名は一意である必要があります（したがって、IANAに登録する必要があります）。新しい名前とともに、そのセマンティクス、パケット形式（必要な場合）、およびその操作のルールを指定する必要があります。
Regular RTCP minimum interval "trr-int":
通常のRTCP最小間隔「trr-int」：
The attribute "trr-int" is used to specify the minimum interval T_rr_interval between two Regular (full compound) RTCP packets in milliseconds for this media session. If "trr-int" is not specified, a default value of 0 is assumed.
属性「trr-int」は、このメディアセッションの2つの通常の（完全な複合）RTCPパケット間の最小間隔T_rr_intervalをミリ秒単位で指定するために使用されます。 「trr-int」を指定しない場合、デフォルト値の0が想定されます。
Note that it is assumed that more specific information about application layer feedback (as defined in Section 6.4) will be conveyed as feedback types and parameters defined elsewhere. Hence, no further provision for any types and parameters is made in this document.
アプリケーションレイヤーフィードバックに関するより具体的な情報（セクション6.4で定義）は、他の場所で定義されたフィードバックタイプおよびパラメーターとして伝達されると想定されていることに注意してください。したがって、このドキュメントでは、タイプとパラメータの規定はこれ以上ありません。
Further types of feedback as well as further parameters may be defined in other documents.
その他のタイプのフィードバックおよびその他のパラメータは、他のドキュメントで定義できます。
It is up to the recipients whether or not they send feedback information and up to the sender(s) (how) to make use of feedback provided.
フィードバック情報を送信するかどうかは受信者次第であり、提供されたフィードバックを利用するかどうかは送信者（方法）次第です。
The standard RTCP bandwidth assignments as defined in [1] and [2] MAY be overridden by bandwidth modifiers that explicitly define the maximum RTCP bandwidth. For use with SDP, such modifiers are specified in [4]: "b=RS:<bw>" and "b=RR:<bw>" MAY be used to assign a different bandwidth (measured in bits per second) to RTP senders and receivers, respectively. The precedence rules of [4] apply to determine the actual bandwidth to be used by senders and receivers.
[1]および[2]で定義されている標準のRTCP帯域幅割り当ては、最大RTCP帯域幅を明示的に定義する帯域幅修飾子によって上書きされる場合があります。 SDPで使用する場合、このような修飾子は[4]で指定されます： "b = RS：<bw>"および "b = RR：<bw>"を使用して、RTPに異なる帯域幅（ビット/秒で測定）を割り当てることができますそれぞれ送信者と受信者。 [4]の優先規則は、送信者と受信者が使用する実際の帯域幅を決定するために適用されます。
Applications operating knowingly over highly asymmetric links (such as satellite links) SHOULD use this mechanism to reduce the feedback rate for high bandwidth streams to prevent deterministic congestion of the feedback path(s).
高度に非対称なリンク（衛星リンクなど）で意図的に動作するアプリケーションは、このメカニズムを使用して、高帯域幅ストリームのフィードバックレートを下げ、フィードバックパスの確定的な輻輳を防止する必要があります（SHOULD）。
Example 1: The following session description indicates a session made up from audio and DTMF [18] for point-to-point communication in which the DTMF stream uses Generic NACKs. This session description could be contained in a SIP INVITE, 200 OK, or ACK message to indicate that its sender is capable of and willing to receive feedback for the DTMF stream it transmits.
例1：次のセッションの説明は、DTMFストリームがGeneric NACKを使用するポイントツーポイント通信用のオーディオとDTMF [18]から構成されるセッションを示しています。このセッションの説明は、SIP INVITE、200 OK、またはACKメッセージに含めることができ、その送信者が、送信するDTMFストリームのフィードバックを受信する能力があることを示します。
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 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
This allows sender and receiver to provide reliable transmission of DTMF events in an audio session. Assuming a 64-kbit/s audio stream with one receiver, the receiver has 2.5% RTCP bandwidth available for the negative acknowledgement stream, i.e., 250 bytes per second or some 2 RTCP feedback messages every second. Hence, the receiver can individually communicate up to two missing DTMF audio packets per second.
これにより、送信者と受信者は、オーディオセッションでDTMFイベントを確実に送信できます。レシーバーが1つの64 kbit / sオーディオストリームを想定すると、レシーバーは否定応答ストリームに2.5％のRTCP帯域幅を使用できます。つまり、250バイト/秒または毎秒2つのRTCPフィードバックメッセージです。したがって、レシーバーは1秒あたり最大2つの欠落しているDTMFオーディオパケットを個別に通信できます。
Example 2: The following session description indicates a multicast video-only session (using either H.261 or H.263+) with the video source accepting Generic NACKs for both codecs and Reference Picture Selection for H.263. Such a description may have been conveyed using the Session Announcement Protocol (SAP).
例2：次のセッションの説明は、H.261またはH.263 +を使用するマルチキャストビデオのみのセッションを示しています。ビデオソースは、コーデックとGeneric NACKの両方を受け入れ、H.263の参照画像選択を受け入れます。このような記述は、Session Announcement Protocol（SAP）を使用して伝えられた可能性があります。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
The sender may use an incoming Generic NACK as a hint to send a new intra-frame as soon as possible (congestion control permitting). Receipt of a Reference Picture Selection Indication (RPSI) message allows the sender to avoid sending a large intra-frame; instead it may continue to send inter-frames, however, choosing the indicated frame as new encoding reference.
送信者は、新しいGeneric NACKをヒントとして使用して、新しいイントラフレームをできるだけ早く送信することができます（輻輳制御が許可されています）。参照画像選択表示（RPSI）メッセージを受信すると、送信者は大きなイントラフレームの送信を回避できます。代わりに、インターフレームを送信し続けますが、指定されたフレームを新しいエンコーディング参照として選択します。
Example 3: The following session description defines the same media session as example 2 but allows for mixed-mode operation of AVP and AVPF RTP entities (see also next section). Note that both media descriptions use the same addresses; however, two m= lines are needed to convey information about both applicable RTP profiles.
例3：次のセッションの説明では、例2と同じメディアセッションを定義しますが、AVPおよびAVPF RTPエンティティの混合モード操作が可能です（次のセクションも参照）。両方のメディア記述が同じアドレスを使用していることに注意してください。ただし、該当する両方のRTPプロファイルに関する情報を伝えるには、2つのm =行が必要です。
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
m=audio 49170 RTP/AVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
m=video 51372 RTP/AVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi
Note that these two m= lines SHOULD be grouped by some appropriate mechanism to indicate that both are alternatives actually conveying the same contents. A sample framework by which this can be achieved is defined in [10].
これらの2つのm =行は、適切なメカニズムによってグループ化して、両方が実際に同じ内容を伝達する代替であることを示す必要があることに注意してください。これを実現できるサンプルフレームワークは、[10]で定義されています。
In this example, the RTCP feedback-enabled receivers will gain an occasional advantage to report events earlier back to the sender (which may benefit the entire group). On average, however, all RTP receivers will provide the same amount of feedback. The interworking between AVP and AVPF entities is discussed in depth in the next section.
この例では、RTCPフィードバック対応の受信者は、イベントを送信者に早期に報告する利点を時折得ます（これはグループ全体に利益をもたらす可能性があります）。ただし、平均して、すべてのRTPレシーバーは同じ量のフィードバックを提供します。 AVPエンティティとAVPFエンティティ間の相互作用については、次のセクションで詳しく説明します。
The AVPF profile defined in this document is an extension of the AVP profile as defined in [2]. Both profiles follow the same basic rules (including the upper bandwidth limit for RTCP and the bandwidth assignments to senders and receivers). Therefore, senders and receivers using either of the two profiles can be mixed in a single session (see Example 3 in Section 4.5).
このドキュメントで定義されているAVPFプロファイルは、[2]で定義されているAVPプロファイルの拡張です。両方のプロファイルは同じ基本ルールに従います（RTCPの帯域幅の上限と、送信者と受信者への帯域幅の割り当てを含む）。したがって、2つのプロファイルのいずれかを使用する送信者と受信者を1つのセッションで混在させることができます（セクション4.5の例3を参照）。
AVP and AVPF are defined in a way that, from a robustness point of view, the RTP entities do not need to be aware of entities of the respective other profile: they will not disturb each other's functioning. However, the quality of the media presented may suffer.
AVPとAVPFは、堅牢性の観点から、RTPエンティティが他のそれぞれのプロファイルのエンティティを認識する必要がないように定義されています。これらは互いの機能を妨げません。ただし、提示されるメディアの品質は低下する可能性があります。
The following considerations apply to senders and receivers when used in a combined session.
以下の考慮事項は、結合セッションで使用される場合の送信者と受信者に適用されます。
o AVP entities (senders and receivers)
o AVPエンティティ（送信者と受信者）
AVP senders will receive RTCP feedback packets from AVPF receivers and ignore these packets. They will see occasional closer spacing of RTCP messages (e.g., violating the five-second rule) by AVPF entities. As the overall bandwidth constraints are adhered to by both types of entities, they will still get their share of the RTCP bandwidth. However, while AVP entities are bound by the five-second rule, depending on the group size and session bandwidth, AVPF entities may provide more frequent RTCP reports than AVP ones will. Also, the overall reporting may decrease slightly as AVPF entities may send bigger compound RTCP packets (due to the extra RTCP packets).
AVP送信側は、AVPF受信側からRTCPフィードバックパケットを受信し、これらのパケットを無視します。 AVPFエンティティによって、RTCPメッセージの間隔が狭くなる（5秒のルールに違反するなど）ことがあります。両方のタイプのエンティティによって全体的な帯域幅の制約が守られているため、RTCP帯域幅のシェアは引き続き確保されます。ただし、AVPエンティティは5秒のルールに拘束されますが、グループのサイズとセッション帯域幅に応じて、AVPFエンティティは、AVPエンティティよりも頻繁にRTCPレポートを提供する場合があります。また、AVPFエンティティが（追加のRTCPパケットのために）より大きな複合RTCPパケットを送信する可能性があるため、全体的なレポートがわずかに減少する可能性があります。
If T_rr_interval is used as lower bound between Regular RTCP packets, T_rr_interval is sufficiently large (e.g., T_rr_interval > M*Td as per Section 6.3.5 of [1]), and no Early RTCP packets are sent by AVPF entities, AVP entities may accidentally time out those AVPF group members and hence underestimate the group size. Therefore, if AVP entities may be involved in a media session, T_rr_interval SHOULD NOT be larger than five seconds.
T_rr_intervalが通常のRTCPパケット間の下限として使用される場合、T_rr_intervalは十分に大きく（たとえば、[1]のセクション6.3.5に従ってT_rr_interval> M * Td）、AVPFエンティティによってEarly RTCPパケットが送信されない場合、AVPエンティティはそれらのAVPFグループメンバーを誤ってタイムアウトにして、グループサイズを低く見積もってください。したがって、AVPエンティティがメディアセッションに含まれる可能性がある場合、T_rr_intervalは5秒を超えてはなりません（SHOULD NOT）。
o AVPF entities (senders and receivers)
o AVPFエンティティ（送信者と受信者）
If the dynamically calculated T_rr is sufficiently small (e.g., less than one second), AVPF entities may accidentally time out AVP group members and hence underestimate the group size. Therefore, if AVP entities may be involved in a media session, T_rr_interval SHOULD be used and SHOULD be set to five seconds.
動的に計算されたT_rrが十分に小さい場合（たとえば、1秒未満）、AVPFエンティティは誤ってAVPグループメンバーをタイムアウトさせ、グループサイズを過小評価する可能性があります。したがって、AVPエンティティがメディアセッションに含まれる可能性がある場合は、T_rr_intervalを使用して（SHOULD）、5秒に設定する必要があります（SHOULD）。
In conclusion, if AVP entities may be involved in a media session and T_rr_interval is to be used, T_rr_interval SHOULD be set to five seconds.
結論として、AVPエンティティがメディアセッションに関与している可能性があり、T_rr_intervalを使用する場合、T_rr_intervalを5秒に設定する必要があります（SHOULD）。
o AVPF senders
o AVPF送信者
AVPF senders will receive feedback information only from AVPF receivers. If they rely on feedback to provide the target media quality, the quality achieved for AVP receivers may be suboptimal.
AVPF送信側はAVPF受信側からのみフィードバック情報を受信します。ターゲットのメディア品質を提供するためにフィードバックに依存している場合、AVPレシーバーで達成される品質は最適ではない可能性があります。
o AVPF receivers
o AVPFレシーバー
AVPF receivers SHOULD send Early RTCP feedback packets only if all sending entities in the media session support AVPF. AVPF receivers MAY send feedback information as part of regularly scheduled compound RTCP packets following the timing rules of
AVPFレシーバーは、メディアセッションのすべての送信エンティティがAVPFをサポートしている場合にのみ、早期RTCPフィードバックパケットを送信する必要があります（SHOULD）。 AVPFレシーバーは、定期的にスケジュールされた複合RTCPパケットの一部として、次のタイミングルールに従ってフィードバック情報を送信できます。
[1] and [2] also in media sessions operating in mixed mode. However, the receiver providing feedback MUST NOT rely on the sender reacting to the feedback at all.
[1] [2]混合モードで動作するメディアセッションでも。ただし、フィードバックを提供する受信者は、フィードバックに反応する送信者にまったく依存してはなりません。
This section defines the format of the low-delay RTCP feedback messages. These messages are classified into three categories as follows:
このセクションでは、低遅延RTCPフィードバックメッセージの形式を定義します。これらのメッセージは、次の3つのカテゴリに分類されます。
- Transport layer FB messages - Payload-specific FB messages - Application layer FB messages
- トランスポート層FBメッセージ-ペイロード固有のFBメッセージ-アプリケーション層FBメッセージ
Transport layer FB messages are intended to transmit general purpose feedback information, i.e., information independent of the particular codec or the application in use. The information is expected to be generated and processed at the transport/RTP layer. Currently, only a generic negative acknowledgement (NACK) message is defined.
トランスポート層のFBメッセージは、汎用のフィードバック情報、つまり特定のコーデックや使用中のアプリケーションに依存しない情報を送信することを目的としています。情報は、トランスポート/ RTPレイヤーで生成および処理されることが期待されています。現在、一般的な否定応答（NACK）メッセージのみが定義されています。
Payload-specific FB messages transport information that is specific to a certain payload type and will be generated and acted upon at the codec "layer". This document defines a common header to be used in conjunction with all payload-specific FB messages. The definition of specific messages is left either to RTP payload format specifications or to additional feedback format documents.
ペイロード固有のFBメッセージは、特定のペイロードタイプに固有の情報を転送し、コーデックの「レイヤー」で生成および処理されます。このドキュメントでは、ペイロード固有のすべてのFBメッセージと組み合わせて使用される共通のヘッダーを定義します。特定のメッセージの定義は、RTPペイロード形式の仕様または追加のフィードバック形式のドキュメントに任されています。
Application layer FB messages provide a means to transparently convey feedback from the receiver's to the sender's application. The information contained in such a message is not expected to be acted upon at the transport/RTP or the codec layer. The data to be exchanged between two application instances is usually defined in the application protocol specification and thus can be identified by the application so that there is no need for additional external information. Hence, this document defines only a common header to be used along with all application layer FB messages. From a protocol point of view, an application layer FB message is treated as a special case of a payload-specific FB message.
アプリケーション層のFBメッセージは、フィードバックを受信者から送信者のアプリケーションに透過的に伝える手段を提供します。このようなメッセージに含まれる情報は、トランスポート/ RTPまたはコーデックレイヤーで処理されることは想定されていません。 2つのアプリケーションインスタンス間で交換されるデータは、通常、アプリケーションプロトコルの仕様で定義されているため、アプリケーションで識別できるため、追加の外部情報は必要ありません。したがって、このドキュメントでは、すべてのアプリケーション層のFBメッセージとともに使用される共通のヘッダーのみを定義しています。プロトコルの観点からは、アプリケーション層のFBメッセージは、ペイロード固有のFBメッセージの特殊なケースとして扱われます。
Note: Proper processing of some FB messages at the media sender side may require the sender to know which payload type the FB message refers to. Most of the time, this knowledge can likely be derived from a media stream using only a single payload type. However, if several codecs are used simultaneously (e.g., with audio and DTMF) or when codec changes occur, the payload type information may need to be conveyed explicitly as part of the FB message. This applies to all payload-specific as well as application layer FB messages. It is up to the specification of an FB message to define how payload type information is transmitted.
注：メディア送信側で一部のFBメッセージを適切に処理するには、送信者がFBメッセージが参照するペイロードタイプを認識する必要があります。ほとんどの場合、この知識は、単一のペイロードタイプのみを使用するメディアストリームから派生する可能性があります。ただし、複数のコーデックが同時に使用される場合（たとえば、オーディオとDTMFを使用）、またはコーデックの変更が発生した場合、ペイロードタイプ情報をFBメッセージの一部として明示的に伝える必要があります。これは、ペイロード固有およびアプリケーション層のFBメッセージすべてに適用されます。ペイロードタイプ情報の送信方法を定義するのは、FBメッセージの仕様です。
This document defines two transport layer and three (video) payload-specific FB messages as well as a single container for application layer FB messages. Additional transport layer and payload-specific FB messages MAY be defined in other documents and MUST be registered through IANA (see Section 9, "IANA Considerations").
このドキュメントでは、2つのトランスポート層と3つの（ビデオ）ペイロード固有のFBメッセージ、およびアプリケーション層のFBメッセージ用の単一のコンテナーを定義します。追加のトランスポート層とペイロード固有のFBメッセージは他のドキュメントで定義される場合があり、IANAを通じて登録する必要があります（セクション9、「IANAに関する考慮事項」を参照）。
The general syntax and semantics for the above RTCP FB message types are described in the following subsections.
上記のRTCP FBメッセージタイプの一般的な構文とセマンティクスについて、以下のサブセクションで説明します。
All FB messages MUST use a common packet format that is depicted in Figure 3:
すべてのFBメッセージは、図3に示す共通のパケット形式を使用する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 3: Common Packet Format for Feedback Messages
図3：フィードバックメッセージの一般的なパケット形式
The fields V, P, SSRC, and length are defined in the RTP specification [2], the respective meaning being summarized below:
フィールドV、P、SSRC、および長さはRTP仕様[2]で定義されており、それぞれの意味は以下に要約されています。
version (V): 2 bits This field identifies the RTP version. The current version is 2.
バージョン（V）：2ビットこのフィールドはRTPバージョンを識別します。現在のバージョンは2です。
padding (P): 1 bit If set, the padding bit indicates that the packet contains additional padding octets at the end that are not part of the control information but are included in the length field.
パディング（P）：1ビットセットされている場合、パディングビットは、制御情報の一部ではないが長さフィールドに含まれている追加のパディングオクテットがパケットの最後に含まれることを示します。
Feedback message type (FMT): 5 bits This field identifies the type of the FB message and is interpreted relative to the type (transport layer, payload-specific, or application layer feedback). The values for each of the three feedback types are defined in the respective sections below.
フィードバックメッセージタイプ（FMT）：5ビットこのフィールドはFBメッセージのタイプを識別し、タイプ（トランスポート層、ペイロード固有、またはアプリケーション層フィードバック）に関連して解釈されます。 3つのフィードバックタイプのそれぞれの値は、以下の各セクションで定義されています。
Payload type (PT): 8 bits This is the RTCP packet type that identifies the packet as being an RTCP FB message. Two values are defined by the IANA:
ペイロードタイプ（PT）：8ビットこれは、パケットをRTCP FBメッセージとして識別するRTCPパケットタイプです。 IANAによって2つの値が定義されています。
Name | Value | Brief Description
----------+-------+------------------------------------
RTPFB | 205 | Transport layer FB message
PSFB | 206 | Payload-specific FB message
Length: 16 bits The length of this packet in 32-bit words minus one, including the header and any padding. This is in line with the definition of the length field used in RTCP sender and receiver reports [3].
長さ：16ビットこのパケットの長さ（32ビットワードから1を引いたもの）（ヘッダーとパディングを含む）。これは、RTCP送信者および受信者レポートで使用される長さフィールドの定義と一致しています[3]。
SSRC of packet sender: 32 bits The synchronization source identifier for the originator of this packet.
パケット送信側のSSRC：32ビットこのパケットの発信元の同期ソース識別子。
SSRC of media source: 32 bits The synchronization source identifier of the media source that this piece of feedback information is related to.
メディアソースのSSRC：32ビットこのフィードバック情報に関連するメディアソースの同期ソース識別子。
Feedback Control Information (FCI): variable length The following three sections define which additional information MAY be included in the FB message for each type of feedback: transport layer, payload-specific, or application layer feedback. Note that further FCI contents MAY be specified in further documents.
フィードバック制御情報（FCI）：可変長次の3つのセクションは、フィードバックの各タイプ（トランスポート層、ペイロード固有、またはアプリケーション層フィードバック）のFBメッセージにどの追加情報を含めることができるかを定義します。追加のFCIコンテンツは、追加のドキュメントで指定される場合があります。
Each RTCP feedback packet MUST contain at least one FB message in the FCI field. Sections 6.2 and 6.3 define for each FCI type, whether or not multiple FB messages MAY be compressed into a single FCI field. If this is the case, they MUST be of the same type, i.e., same FMT. If multiple types of feedback messages, i.e., several FMTs, need to be conveyed, then several RTCP FB messages MUST be generated and SHOULD be concatenated in the same compound RTCP packet.
各RTCPフィードバックパケットには、FCIフィールドに少なくとも1つのFBメッセージが含まれている必要があります。セクション6.2および6.3では、複数のFBメッセージを単一のFCIフィールドに圧縮できるかどうかにかかわらず、FCIタイプごとに定義します。この場合、それらは同じタイプ、つまり同じFMTである必要があります。複数のタイプのフィードバックメッセージ、つまり複数のFMTを伝達する必要がある場合は、複数のRTCP FBメッセージを生成する必要があり、同じ複合RTCPパケットに連結する必要があります（SHOULD）。
Transport layer FB messages are identified by the value RTPFB as RTCP message type.
トランスポート層FBメッセージは、RTPFBという値によってRTCPメッセージタイプとして識別されます。
A single general purpose transport layer FB message is defined in this document: Generic NACK. It is identified by means of the FMT parameter as follows:
このドキュメントでは、単一の汎用トランスポート層FBメッセージであるGeneric NACKを定義しています。これは、FMTパラメーターを使用して次のように識別されます。
0: unassigned 1: Generic NACK 2-30: unassigned 31: reserved for future expansion of the identifier number space
0：未割り当て1：ジェネリックNACK 2-30：未割り当て31：識別子番号スペースの将来の拡張用に予約済み
The following subsection defines the formats of the FCI field for this type of FB message. Further generic feedback messages MAY be defined in the future.
次のサブセクションでは、このタイプのFBメッセージのFCIフィールドの形式を定義します。さらに一般的なフィードバックメッセージは将来定義されるかもしれません。
The Generic NACK message is identified by PT=RTPFB and FMT=1.
Generic NACKメッセージは、PT = RTPFBおよびFMT = 1で識別されます。
The FCI field MUST contain at least one and MAY contain more than one Generic NACK.
FCIフィールドは少なくとも1つを含む必要があり、複数のGeneric NACKを含むことができます（MAY）。
The Generic NACK is used to indicate the loss of one or more RTP packets. The lost packet(s) are identified by the means of a packet identifier and a bit mask.
Generic NACKは、1つ以上のRTPパケットの損失を示すために使用されます。失われたパケットは、パケット識別子とビットマスクによって識別されます。
Generic NACK feedback SHOULD NOT be used if the underlying transport protocol is capable of providing similar feedback information to the sender (as may be the case, e.g., with DCCP).
基になるトランスポートプロトコルが同様のフィードバック情報を送信者に提供できる場合（たとえば、DCCPの場合など）、汎用のNACKフィードバックは使用しないでください。
The Feedback Control Information (FCI) field has the following Syntax (Figure 4):
フィードバック制御情報（FCI）フィールドの構文は次のとおりです（図4）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Syntax for the Generic NACK message
図4：Generic NACKメッセージの構文
Packet ID (PID): 16 bits The PID field is used to specify a lost packet. The PID field refers to the RTP sequence number of the lost packet.
パケットID（PID）：16ビットPIDフィールドは、失われたパケットを指定するために使用されます。 PIDフィールドは、失われたパケットのRTPシーケンス番号を参照します。
bitmask of following lost packets (BLP): 16 bits The BLP allows for reporting losses of any of the 16 RTP packets immediately following the RTP packet indicated by the PID. The BLP's definition is identical to that given in [6]. Denoting the BLP's least significant bit as bit 1, and its most significant bit as bit 16, then bit i of the bit mask is set to 1 if the receiver has not received RTP packet number (PID+i) (modulo 2^16) and indicates this packet is lost; bit i is set to 0 otherwise. Note that the sender MUST NOT assume that a receiver has received a packet because its bit mask was set to 0. For example, the least significant bit of the BLP would be set to 1 if the packet corresponding to the PID and the following packet have been lost. However, the sender cannot infer that packets PID+2 through PID+16 have been received simply because bits 2 through 15 of the BLP are 0; all the sender knows is that the receiver has not reported them as lost at this time.
次の失われたパケット（BLP）のビットマスク：16ビットBLPにより、PIDで示されるRTPパケットの直後の16個のRTPパケットのいずれかの損失を報告できます。 BLPの定義は、[6]で与えられたものと同じです。 BLPの最下位ビットをビット1、最上位ビットをビット16とすると、受信者がRTPパケット番号（PID + i）を受信していない場合、ビットマスクのビットiは1に設定されます（2 ^ 16を法とする）。このパケットが失われたことを示します。それ以外の場合、ビットiは0に設定されます。送信者は、ビットマスクが0に設定されているため、受信者がパケットを受信したと想定してはならないことに注意してください。たとえば、BIDの最下位ビットは、PIDに対応するパケットと次のパケットが失われた。ただし、BLPのビット2〜15が0であるという理由だけで、送信者はパケットPID + 2〜PID + 16が受信されたことを推測できません。送信者が知っているのは、受信者が現時点でそれらを紛失したと報告していないことだけです。
The length of the FB message MUST be set to 2+n, with n being the number of Generic NACKs contained in the FCI field.
FBメッセージの長さは2 + nに設定する必要があります。nはFCIフィールドに含まれるGeneric NACKの数です。
The Generic NACK message implicitly references the payload type through the sequence number(s).
Generic NACKメッセージは、シーケンス番号を通じてペイロードタイプを暗黙的に参照します。
Payload-Specific FB messages are identified by the value PT=PSFB as RTCP message type.
ペイロード固有のFBメッセージは、RTCPメッセージタイプとして値PT = PSFBで識別されます。
Three payload-specific FB messages are defined so far plus an application layer FB message. They are identified by means of the FMT parameter as follows:
これまでに、ペイロード固有の3つのFBメッセージと、アプリケーション層のFBメッセージが定義されています。これらは、FMTパラメーターによって次のように識別されます。
0: unassigned 1: Picture Loss Indication (PLI) 2: Slice Loss Indication (SLI) 3: Reference Picture Selection Indication (RPSI) 4-14: unassigned 15: Application layer FB (AFB) message 16-30: unassigned 31: reserved for future expansion of the sequence number space
0：未割り当て1：ピクチャロス表示（PLI）2：スライスロス表示（SLI）3：参照ピクチャ選択表示（RPSI）4-14：未割り当て15：アプリケーション層FB（AFB）メッセージ16-30：未割り当て31：予約済みシーケンス番号スペースの将来の拡張のため
The following subsections define the FCI formats for the payload-specific FB messages, Section 6.4 defines FCI format for the application layer FB message.
以下のサブセクションでは、ペイロード固有のFBメッセージのFCI形式を定義します。セクション6.4では、アプリケーション層FBメッセージのFCI形式を定義します。
The PLI FB message is identified by PT=PSFB and FMT=1.
PLI FBメッセージは、PT = PSFBおよびFMT = 1で識別されます。
There MUST be exactly one PLI contained in the FCI field.
FCIフィールドにはPLIが1つだけ含まれている必要があります。
With the Picture Loss Indication message, a decoder informs the encoder about the loss of an undefined amount of coded video data belonging to one or more pictures. When used in conjunction with any video coding scheme that is based on inter-picture prediction, an encoder that receives a PLI becomes aware that the prediction chain may be broken. The sender MAY react to a PLI by transmitting an intra-picture to achieve resynchronization (making this message effectively similar to the FIR message as defined in [6]); however, the sender MUST consider congestion control as outlined in Section 7, which MAY restrict its ability to send an intra frame.
ピクチャロス表示メッセージを使用すると、デコーダはエンコーダに、1つまたは複数のピクチャに属する未定義の量のコード化ビデオデータが失われたことを通知します。画像間予測に基づくビデオコーディング方式と組み合わせて使用すると、PLIを受信するエンコーダーは、予測チェーンが壊れている可能性があることを認識します。送信者は、イントラピクチャを送信してPLIに反応し、再同期を実現できます（このメッセージを[6]で定義されているFIRメッセージと効果的に類似させます）。ただし、送信者はセクション7で概説されているように輻輳制御を考慮しなければならず（MUST）、イントラフレームを送信する機能を制限することができます（MAY）。
Other RTP payload specifications such as RFC 2032 [6] already define a feedback mechanism for some 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 to receive and react to the feedback scheme defined in the respective RTP payload format, if this is required by that payload format.
RFC 2032 [6]などの他のRTPペイロード仕様では、特定のコーデックの一部に対してすでにフィードバックメカニズムが定義されています。両方のスキームをサポートするアプリケーションは、フィードバックを送信するときに、この仕様で定義されているフィードバックメカニズムを使用する必要があります。下位互換性の理由から、そのようなアプリケーションは、それぞれのRTPペイロード形式で定義されたフィードバックスキームを受け取り、それに対応する必要があれば、それを受信して対応する必要があります（SHOULD）。
PLI does not require parameters. Therefore, the length field MUST be 2, and there MUST NOT be any Feedback Control Information.
PLIはパラメーターを必要としません。したがって、長さフィールドは2でなければならず、フィードバック制御情報があってはなりません。
The semantics of this FB message is independent of the payload type.
このFBメッセージのセマンティクスは、ペイロードタイプとは無関係です。
The timing follows the rules outlined in Section 3. In systems that employ both PLI and other types of feedback, it may be advisable to follow the Regular RTCP RR timing rules for PLI, since PLI is not as delay critical as other FB types.
タイミングは、セクション3で概説されているルールに従います。PLIと他のタイプのフィードバックの両方を使用するシステムでは、PLIは他のFBタイプほど遅延が重要ではないため、PLIの通常のRTCP RRタイミングルールに従うことをお勧めします。
PLI messages typically trigger the sending of full intra-pictures. Intra-pictures are several times larger then 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 multitude 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 particular short delay in sending the FB message. Hence, waiting for the next possible time slot allowed by RTCP timing rules as per [2] with Tmin=0 does not have a negative impact on the system performance.
PLIメッセージは通常、完全なイントラ画像の送信をトリガーします。イントラピクチャは、予測（インター）ピクチャよりも数倍大きくなります。それらのサイズは、生成される時間とは無関係です。ほとんどの環境では、特に帯域幅が制限されたリンクを使用する場合、イントラピクチャの使用は、典型的なフレーム期間のかなりの数である許容遅延を意味します。例：送信フレームレートが10 fpsで、イントラピクチャがインターピクチャの10倍の大きさであると想定されている場合、1秒のレイテンシを受け入れる必要があります。このような環境では、FBメッセージの送信に特定の短い遅延は必要ありません。したがって、Tmin = 0の[2]に従ってRTCPタイミングルールで許可されている次の可能なタイムスロットを待機しても、システムパフォーマンスに悪影響はありません。
The SLI FB message is identified by PT=PSFB and FMT=2.
SLI FBメッセージは、PT = PSFBおよびFMT = 2で識別されます。
The FCI field MUST contain at least one and MAY contain more than one SLI.
FCIフィールドは少なくとも1つを含む必要があり、複数のSLIを含む場合があります。
With the Slice Loss Indication, a decoder can inform an encoder that it has detected the loss or corruption of one or several consecutive macroblock(s) in scan order (see below). This FB message MUST NOT be used for video codecs with non-uniform, dynamically changeable macroblock sizes such as H.263 with enabled Annex Q. In such a case, an encoder cannot always identify the corrupted spatial region.
スライス損失表示を使用すると、デコーダーはエンコーダーに、スキャン順で1つまたは複数の連続したマクロブロックの損失または破損を検出したことを通知できます（以下を参照）。このFBメッセージは、Annex Qが有効になっているH.263のように、不均一で動的に変更可能なマクロブロックサイズのビデオコーデックに使用してはなりません。
The Slice Loss Indication uses one additional FCI field, the content of which is depicted in Figure 6. The length of the FB message MUST be set to 2+n, with n being the number of SLIs contained in the FCI field.
スライス損失表示は1つの追加のFCIフィールドを使用します。その内容を図6に示します。FBメッセージの長さは2 + nに設定する必要があります。nはFCIフィールドに含まれるSLIの数です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First | Number | PictureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax of the Slice Loss Indication (SLI)
図6：スライス損失表示（SLI）の構文
First: 13 bits The macroblock (MB) address of the first lost macroblock. The MB numbering is done such that the macroblock in the upper left corner of the picture is considered macroblock number 1 and the number for each macroblock increases from left to right and then from top to bottom in raster-scan order (such that if there is a total of N macroblocks in a picture, the bottom right macroblock is considered macroblock number N).
最初：13ビット最初に失われたマクロブロックのマクロブロック（MB）アドレス。 MB番号付けは、画像の左上隅のマクロブロックがマクロブロック番号1と見なされ、各マクロブロックの番号がラスタースキャン順に左から右に、次に上から下に増加するように行われます（画像内の合計N個のマクロブロック、右下のマクロブロックはマクロブロック番号N）と見なされます。
Number: 13 bits The number of lost macroblocks, in scan order as discussed above.
数：13ビット上記のスキャン順序での失われたマクロブロックの数。
PictureID: 6 bits The six least significant bits of the codec-specific identifier that is used to reference the picture in which the loss of the macroblock(s) has occurred. For many video codecs, the PictureID is identical to the Temporal Reference.
PictureID：6ビットマクロブロックの損失が発生した画像を参照するために使用されるコーデック固有の識別子の最下位6ビット。多くのビデオコーデックでは、PictureIDはTemporal Referenceと同じです。
The applicability of this FB message is limited to a small set of video codecs; therefore, no explicit payload type information is provided.
このFBメッセージの適用範囲は、少数のビデオコーデックに限定されます。したがって、明示的なペイロードタイプ情報は提供されません。
The efficiency of algorithms using the Slice Loss Indication is reduced greatly when the Indication is not transmitted in a timely fashion. Motion compensation propagates corrupted pixels that are not reported as being corrupted. Therefore, the use of the algorithm discussed in Section 3 is highly recommended.
表示がタイムリーに送信されない場合、スライス損失表示を使用するアルゴリズムの効率は大幅に低下します。モーション補正は、破損していると報告されていない破損したピクセルを伝播します。したがって、セクション3で説明するアルゴリズムの使用を強くお勧めします。
The term Slice is defined and used here in the sense of MPEG-1 -- a consecutive number of macroblocks in scan order. More recent video coding standards sometimes have a different understanding of the term Slice. In H.263 (1998), for example, a concept known as "rectangular slice" exists. The loss of one rectangular slice may lead to the necessity of sending more than one SLI in order to precisely identify the region of lost/damaged MBs.
スライスという用語は、MPEG-1の意味でここで定義および使用されています。スキャン順の連続した数のマクロブロックです。最近のビデオコーディング標準では、スライスという用語の理解が異なる場合があります。たとえばH.263（1998）には、「長方形スライス」という概念があります。 1つの長方形のスライスが失われると、MBが失われた/破損した領域を正確に特定するために、複数のSLIを送信する必要が生じる場合があります。
The first field of the FCI defines the first macroblock of a picture as 1 and not, as one could suspect, as 0. This was done to align this specification with the comparable mechanism available in ITU-T Rec. H.245 [24]. The maximum number of macroblocks in a picture (2**13 or 8192) corresponds to the maximum picture sizes of most of the ITU-T and ISO/IEC video codecs. If future video codecs offer larger picture sizes and/or smaller macroblock sizes, then an additional FB message has to be defined. The six least significant bits of the Temporal Reference field are deemed to be sufficient to indicate the picture in which the loss occurred.
FCIの最初のフィールドは、画像の最初のマクロブロックを1として定義します。疑わしい場合は0として定義しません。これは、この仕様をITU-T Rec。 H.245 [24]。画像内のマクロブロックの最大数（2 ** 13または8192）は、ほとんどのITU-TおよびISO / IECビデオコーデックの最大画像サイズに対応しています。将来のビデオコーデックがより大きな画像サイズやより小さなマクロブロックサイズを提供する場合、追加のFBメッセージを定義する必要があります。時間参照フィールドの最下位6ビットは、損失が発生した画像を示すのに十分であると見なされます。
The reaction to an SLI is not part of this specification. One typical way of reacting to an SLI is to use intra refresh for the affected spatial region.
SLIに対する反応は、この仕様の一部ではありません。 SLIに反応する一般的な方法の1つは、影響を受ける空間領域にイントラリフレッシュを使用することです。
Algorithms were reported that keep track of the regions affected by motion compensation, in order to allow for a transmission of Intra macroblocks to all those areas, regardless of the timing of the FB (see H.263 (2000) Appendix I [17] and [15]). Although the timing of the FB is less critical when those algorithms are used than if they are not, it has to be observed that those algorithms correct large parts of the picture and, therefore, have to transmit much higher data volume in case of delayed FBs.
FBのタイミングに関係なく、イントラマクロブロックをすべての領域に送信できるようにするために、モーション補正の影響を受ける領域を追跡するアルゴリズムが報告されました（H.263（2000）付録I [17]を参照）。 [15]）。これらのアルゴリズムを使用する場合、使用しない場合よりもFBのタイミングはそれほど重要ではありませんが、これらのアルゴリズムは画像の大部分を修正するため、FBが遅延した場合ははるかに多くのデータ量を送信する必要があります。 。
The RPSI FB message is identified by PT=PSFB and FMT=3.
RPSI FBメッセージは、PT = PSFBおよびFMT = 3で識別されます。
There MUST be exactly one RPSI contained in the FCI field.
FCIフィールドには、RPSIが1つだけ含まれている必要があります。
Modern video coding standards such as MPEG-4 visual version 2 [16] or H.263 version 2 [17] allow using older reference pictures than the most recent one for predictive coding. Typically, a first-in-first-out queue of reference pictures is maintained. If an encoder has learned about a loss of encoder-decoder synchronicity, a known-as-correct reference picture can be used. As this reference picture is temporally further away then usual, the resulting predictively coded picture will use more bits.
MPEG-4ビジュアルバージョン2 [16]やH.263バージョン2 [17]などの最新のビデオコーディング標準では、最新のものよりも古い参照ピクチャを予測コーディングに使用できます。通常、参照画像の先入れ先出しキューが維持されます。エンコーダーがエンコーダーとデコーダーの同期性の喪失について学習した場合は、正しいとして知られている参照画像を使用できます。この参照画像は通常よりも時間的に離れているため、結果として生じる予測符号化画像はより多くのビットを使用します。
Both MPEG-4 and H.263 define a binary format for the "payload" of an RPSI message that includes information such as the temporal ID of the damaged picture and the size of the damaged region. This bit string is typically small (a couple of dozen bits), of variable length, and self-contained, i.e., contains all information that is necessary to perform reference picture selection.
MPEG-4とH.263はどちらも、損傷した画像の一時的なIDや損傷した領域のサイズなどの情報を含むRPSIメッセージの「ペイロード」のバイナリ形式を定義しています。このビット文字列は一般的に小さく（数十ビット）、可変長であり、自己完結型です。つまり、参照画像の選択に必要なすべての情報が含まれています。
Both MPEG-4 and H.263 allow the use of RPSI with positive feedback information as well. That is, pictures (or Slices) are reported that were decoded without error. Note that any form of positive feedback MUST NOT be used when in a multiparty session (reporting positive feedback about individual reference pictures at RTCP intervals is not expected to be of much use anyway).
MPEG-4とH.263の両方で、RPSIを使用して、肯定的なフィードバック情報を取得することもできます。つまり、エラーなしでデコードされた画像（またはスライス）が報告されます。マルチパーティセッションでは、いかなる形式の正のフィードバックも使用してはならないことに注意してください（RTCP間隔で個々の参照画像に関する正のフィードバックを報告することは、いずれにしてもあまり役に立ちません）。
The FCI for the RPSI message follows the format depicted in Figure 7:
RPSIメッセージの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB |0| Payload Type| Native RPSI bit string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined per codec ... | Padding (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Syntax of the Reference Picture Selection Indication (RPSI)
図7：参照画像選択表示（RPSI）の構文
PB: 8 bits The number of unused bits required to pad the length of the RPSI message to a multiple of 32 bits.
PB：8ビットRPSIメッセージの長さを32ビットの倍数に埋めるために必要な未使用ビットの数。
0: 1 bit MUST be set to zero upon transmission and ignored upon reception.
0：1ビットは送信時にゼロに設定し、受信時に無視する必要があります。
Payload Type: 7 bits Indicates the RTP payload type in the context of which the native RPSI bit string MUST be interpreted.
ペイロードタイプ：7ビットネイティブRPSIビット文字列を解釈する必要があるコンテキストでのRTPペイロードタイプを示します。
Native RPSI bit string: variable length The RPSI information as natively defined by the video codec.
ネイティブRPSIビット文字列：可変長ビデオコーデックによってネイティブに定義されたRPSI情報。
Padding: #PB bits A number of bits set to zero to fill up the contents of the RPSI message to the next 32-bit boundary. The number of padding bits MUST be indicated by the PB field.
パディング：#PBビットRPSIメッセージの内容を次の32ビット境界まで埋めるためにゼロに設定されたビット数。パディングビットの数は、PBフィールドで指定する必要があります。
RPSI is even more critical to delay than algorithms using SLI. This is because the older the RPSI message is, the more bits the encoder has to spend to re-establish encoder-decoder synchronicity. See [15] for some information about the overhead of RPSI for certain bit rate/frame rate/loss rate scenarios.
RPSIは、SLIを使用するアルゴリズムよりも遅延に対してさらに重要です。これは、RPSIメッセージが古いほど、エンコーダーとデコーダーの同期を再確立するためにエンコーダーが費やすビット数が増えるためです。特定のビットレート/フレームレート/損失率のシナリオでのRPSIのオーバーヘッドに関する情報については、[15]を参照してください。
Therefore, RPSI messages should typically be sent as soon as possible, employing the algorithm of Section 3.
したがって、RPSIメッセージは通常、セクション3のアルゴリズムを使用して、できるだけ早く送信する必要があります。
Application layer FB messages are a special case of payload-specific messages and are identified by PT=PSFB and FMT=15. There MUST be exactly one application layer FB message contained in the FCI field, unless the application layer FB message structure itself allows for stacking (e.g., by means of a fixed size or explicit length indicator).
アプリケーション層のFBメッセージは、ペイロード固有のメッセージの特殊なケースであり、PT = PSFBおよびFMT = 15によって識別されます。アプリケーションレイヤーFBメッセージ構造自体がスタックを許可している場合（例：固定サイズまたは明示的な長さインジケーターによるものを除く）を除いて、FCIフィールドには1つのアプリケーションレイヤーFBメッセージが含まれている必要があります。
These messages are used to transport application-defined data directly from the receiver's to the sender's application. The data that is transported is not identified by the FB message. Therefore, the application MUST be able to identify the message payload.
これらのメッセージは、アプリケーション定義のデータを受信者のアプリケーションから送信者のアプリケーションに直接転送するために使用されます。移送されるデータは、FBメッセージでは識別されません。したがって、アプリケーションはメッセージのペイロードを識別できる必要があります。
Usually, applications define their own set of messages, e.g., NEWPRED messages in MPEG-4 [16] (carried in RTP packets according to RFC 3016 [23]) or FB messages in H.263/Annex N, U [17] (packetized as per RFC 2429 [14]). These messages do not need any additional information from the RTCP message. Thus, the application message is simply placed into the FCI field as follows and the length field is set accordingly.
通常、アプリケーションは独自のメッセージセットを定義します。たとえば、MPEG-4 [16]のNEWPREDメッセージ（RFC 3016 [23]に従ってRTPパケットで伝送）またはH.263 / Annex N、U [17]のFBメッセージ（ RFC 2429 [14]に従ってパケット化されました）。これらのメッセージには、RTCPメッセージからの追加情報は必要ありません。したがって、アプリケーションメッセージは次のようにFCIフィールドに配置され、長さフィールドはそれに応じて設定されます。
Application Message (FCI): variable length This field contains the original application message that should be transported from the receiver to the source. The format is application dependent. The length of this field is variable. If the application data is not 32-bit aligned, padding bits and bytes MUST be added to achieve 32-bit alignment. Identification of padding is up to the application layer and not defined in this specification.
アプリケーションメッセージ（FCI）：可変長このフィールドには、受信側からソースに転送する必要のある元のアプリケーションメッセージが含まれます。フォーマットはアプリケーションに依存します。このフィールドの長さは可変です。アプリケーションデータが32ビットアラインされていない場合、32ビットアラインメントを実現するためにパディングビットとバイトを追加する必要があります。パディングの識別はアプリケーション層次第であり、この仕様では定義されていません。
The application layer FB message specification MUST define whether or not the message needs to be interpreted specifically in the context of a certain codec (identified by the RTP payload type). If a reference to the payload type is required for proper processing, the application layer FB message specification MUST define a way to communicate the payload type information as part of the application layer FB message itself.
アプリケーション層のFBメッセージ仕様では、特定のコーデック（RTPペイロードタイプで識別される）のコンテキストでメッセージを具体的に解釈する必要があるかどうかを定義する必要があります。ペイロードタイプへの参照が適切な処理に必要な場合、アプリケーションレイヤーFBメッセージ仕様は、ペイロードタイプ情報をアプリケーションレイヤーFBメッセージ自体の一部として通信する方法を定義する必要があります。
In the previous sections, the FB messages were defined as well as the timing rules according to which to send these messages. The way to react to the feedback received depends on the application using the feedback mechanisms and hence is beyond the scope of this document.
前のセクションでは、FBメッセージと、これらのメッセージを送信するタイミングルールを定義しました。受け取ったフィードバックに反応する方法は、フィードバックメカニズムを使用するアプリケーションに依存するため、このドキュメントの範囲を超えています。
However, across all applications, there is a common requirement for (TCP-friendly) congestion control on the media stream as defined in [1] and [2] when operating in a best-effort network environment.
ただし、すべてのアプリケーションにわたって、[1]および[2]で定義されているように、メディアストリームに対する（TCPフレンドリーな）輻輳制御に対する共通要件があり、ベストエフォートネットワーク環境で動作します。
It should be noted that RTCP feedback itself is insufficient for congestion control purposes as it is likely to operate at much slower timescales than other transport layer feedback mechanisms (that usually operate in the order of RTT). Therefore, additional mechanisms are required to perform proper congestion control.
RTCPフィードバック自体は、他のトランスポート層フィードバックメカニズム（通常はRTTの順序で動作する）よりもはるかに遅いタイムスケールで動作する可能性があるため、輻輳制御の目的には不十分であることに注意してください。したがって、適切な輻輳制御を実行するには、追加のメカニズムが必要です。
A congestion control algorithm that shares the available bandwidth reasonably fairly with competing TCP connections, e.g., TFRC [7], MUST be used to determine the data rate for the media stream within the bounds of the RTP sender's and the media session's capabilities if the RTP/AVPF session is transmitted in a best-effort environment.
使用可能な帯域幅を競合するTCP接続と合理的に公平に共有する輻輳制御アルゴリズム、たとえばTFRC [7]は、RTPの場合、RTP送信者とメディアセッションの機能の境界内のメディアストリームのデータレートを決定するために使用する必要があります。 / AVPFセッションは、ベストエフォート環境で送信されます。
RTP packets transporting information with the proposed payload format are subject to the security considerations discussed in the RTP specification [1] and in the RTP/AVP profile specification [2]. This profile does not specify any additional security services.
提案されたペイロード形式で情報を転送するRTPパケットは、RTP仕様[1]およびRTP / AVPプロファイル仕様[2]で説明されているセキュリティ上の考慮事項の対象となります。このプロファイルは、追加のセキュリティサービスを指定しません。
This profile modifies the timing behavior of RTCP and eliminates the minimum RTCP interval of five seconds and allows for earlier feedback to be provided by receivers. Group members of the associated RTP session (possibly pretending to represent a large number of entities) may disturb the operation of RTCP by sending large numbers of RTCP packets thereby reducing the RTCP bandwidth available for Regular RTCP reporting as well as for Early FB messages. (Note that an entity need not be a member of a multicast group to cause these effects.) Similarly, malicious members may send very large RTCP messages, thereby increasing the avg_rtcp_size variable and reducing the effectively available RTCP bandwidth.
このプロファイルは、RTCPのタイミング動作を変更し、5秒の最小RTCP間隔を排除し、受信者が以前のフィードバックを提供できるようにします。関連付けられたRTPセッションのグループメンバー（多数のエンティティを表すふりをしている可能性があります）は、多数のRTCPパケットを送信することによりRTCPの動作を妨害し、それにより、通常のRTCPレポートおよび初期FBメッセージに使用できるRTCP帯域幅を削減できます。 （エンティティがこれらの影響を引き起こすためにマルチキャストグループのメンバーである必要はないことに注意してください。）同様に、悪意のあるメンバーは非常に大きなRTCPメッセージを送信し、それによってavg_rtcp_size変数を増やし、有効に利用可能なRTCP帯域幅を減らします。
Feedback information may be suppressed if unknown RTCP feedback packets are received. This introduces the risk of a malicious group member reducing Early feedback by simply transmitting payload-specific RTCP feedback packets with random contents that are not recognized by any receiver (so they will suppress feedback) or by the sender (so no repair actions will be taken).
不明なRTCPフィードバックパケットを受信すると、フィードバック情報が抑制される場合があります。これにより、悪意のあるグループメンバーがランダムなコンテンツを含むペイロード固有のRTCPフィードバックパケットを送信するだけで早期フィードバックが減少するリスクが生じます。ランダムコンテンツは、レシーバー（フィードバックを抑制するため）または送信者（認識されないため、修復アクションは行われません）によって認識されません。 ）。
A malicious group member can also report arbitrary high loss rates in the feedback information to make the sender throttle the data transmission and increase the amount of redundancy information or take other action to deal with the pretended packet loss (e.g., send fewer frames or decrease audio/video quality). This may result in a degradation of the quality of the reproduced media stream.
悪意のあるグループメンバーは、フィードバック情報で任意の高い損失率を報告して、送信者にデータ送信を抑制させ、冗長情報の量を増やしたり、偽のパケット損失に対処するために他のアクションを実行したりすることができます（たとえば、送信するフレーム数を減らすか、オーディオを減らす/ビデオ品質）。これにより、再生されたメディアストリームの品質が低下することがあります。
Finally, a malicious group member can act as a large number of group members and thereby obtain an artificially large share of the Early feedback bandwidth and reduce the reactivity of the other group members -- possibly even causing them to no longer operate in Immediate or Early feedback mode and thus undermining the whole purpose of this profile.
最後に、悪意のあるグループメンバーは多数のグループメンバーとして機能し、それによってアーリーフィードバック帯域幅の人為的に大きなシェアを獲得し、他のグループメンバーの反応性を低下させる可能性があります。フィードバックモード、したがってこのプロファイルの全体の目的を損なう。
Senders as well as receivers SHOULD behave conservatively when observing strange reporting behavior. For excessive failure reporting from one or a few receivers, the sender MAY decide to no longer consider this feedback when adapting its transmission behavior for the media stream. In any case, senders and receivers SHOULD still adhere to the maximum RTCP bandwidth but make sure that they are capable of transmitting at least regularly scheduled RTCP packets. Senders SHOULD carefully consider how to adjust their transmission bandwidth when encountering strange reporting behavior; they MUST NOT increase their transmission bandwidth even if ignoring suspicious feedback.
送信者と受信者は、奇妙なレポート動作を観察する場合、保守的に動作する必要があります。 1つまたはいくつかのレシーバーからの過剰な障害報告の場合、送信者は、メディアストリームの送信動作を適応させるときに、このフィードバックを考慮しないことを決定できます（MAY）。いずれの場合でも、送信者と受信者は最大RTCP帯域幅を守る必要がありますが、少なくとも定期的にスケジュールされたRTCPパケットを送信できることを確認してください。送信者は、奇妙なレポート動作が発生した場合に送信帯域幅を調整する方法を慎重に検討する必要があります。疑わしいフィードバックを無視しても、送信帯域幅を増やしてはなりません。
Attacks using false RTCP packets (Regular as well as Early ones) can be avoided by authenticating all RTCP messages. This can be achieved by using the AVPF profile together with the Secure RTP profile as defined in [22]; as a prerequisite, an appropriate combination of those two profiles (an "SAVPF") is being specified [21]. Note that, when employing group authentication (as opposed to source authentication), the aforementioned attacks may be carried out by malicious or malfunctioning group members in possession of the right keying material.
すべてのRTCPメッセージを認証することにより、偽のRTCPパケット（通常のパケットと初期のパケット）を使用した攻撃を回避できます。これは、[22]で定義されているように、セキュアRTPプロファイルとともにAVPFプロファイルを使用することで実現できます。前提条件として、これら2つのプロファイルの適切な組み合わせ（「SAVPF」）が指定されています[21]。 （ソース認証ではなく）グループ認証を使用する場合、前述の攻撃は、適切なキー情報を所持している悪意のある、または誤動作しているグループメンバーによって実行される可能性があることに注意してください。
The following contact information shall be used for all registrations included here:
ここに含まれるすべての登録には、次の連絡先情報が使用されます。
Contact: Joerg Ott
mailto:jo@acm.org
tel:+358-9-451-2460
The feedback profile as an extension to the profile for audio-visual conferences with minimal control has been registered for the Session Description Protocol (specifically the type "proto"): "RTP/AVPF".
最小限の制御でのオーディオビジュアル会議のプロファイルの拡張としてのフィードバックプロファイルは、Session Description Protocol（具体的にはタイプ「proto」）：「RTP / AVPF」に登録されています。
SDP Protocol ("proto"):
SDPプロトコル（ "proto"）：
Name: RTP/AVPF Long form: Extended RTP Profile with RTCP-based Feedback Type of name: proto Type of attribute: Media level only Purpose: RFC 4585 Reference: RFC 4585
名前：RTP / AVPF長い形式：RTCPベースのフィードバック付きの拡張RTPプロファイル名前のタイプ：proto属性のタイプ：メディアレベルのみ目的：RFC 4585リファレンス：RFC 4585
SDP Attribute ("att-field"):
SDP属性（ "att-field"）：
Attribute name: rtcp-fb Long form: RTCP Feedback parameter Type of name: att-field Type of attribute: Media level only Subject to charset: No Purpose: RFC 4585 Reference: RFC 4585 Values: See this document and registrations below
属性名：rtcp-fb長い形式：RTCPフィードバックパラメータ名前のタイプ：att-field属性のタイプ：メディアレベルのみ文字セットの対象：いいえ目的：RFC 4585リファレンス：RFC 4585値：このドキュメントと以下の登録を参照してください
A new registry has been set up for the "rtcp-fb" attribute, with the following registrations created initially: "ack", "nack", "trr-int", and "app" as defined in this document.
「rtcp-fb」属性の新しいレジストリが設定され、次の登録が最初に作成されました：このドキュメントで定義されている「ack」、「nack」、「trr-int」、および「app」。
Initial value registration for the attribute "rtcp-fb"
属性「rtcp-fb」の初期値登録
Value name: ack Long name: Positive acknowledgement Reference: RFC 4585.
値の名前：ack長い名前：肯定的な確認のリファレンス：RFC 4585。
Value name: nack Long name: Negative Acknowledgement Reference: RFC 4585.
値の名前：nackロングネーム：Negative Acknowledgementリファレンス：RFC 4585。
Value name: trr-int Long name: Minimal receiver report interval Reference: RFC 4585.
値の名前：trr-int長い名前：最小の受信レポート間隔参照：RFC 4585。
Value name: app Long name: Application-defined parameter Reference: RFC 4585.
値の名前：appロングネーム：アプリケーション定義のパラメーターリファレンス：RFC 4585。
Further entries may be registered on a first-come first-serve basis. Each new registration needs to indicate the parameter name and the syntax of possible additional arguments. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter, the syntax and semantics of its parameters as well as corresponding feedback packet formats (if needed). The general registration procedures of [3] apply.
その他のエントリーは先着順で登録できます。新規登録のたびに、パラメーター名と可能な追加引数の構文を示す必要があります。新規登録ごとに、登録されたパラメーターのセマンティクス、パラメーターの構文とセマンティクス、および対応するフィードバックパケット形式（必要な場合）を指定する、永続的で安定した、公開されたドキュメントが存在することが必須です。 [3]の一般的な登録手順が適用されます。
For use with both "ack" and "nack", a joint sub-registry has been set up that initially registers the following values:
「ack」と「nack」の両方で使用するために、最初に次の値を登録する共同サブレジストリが設定されています。
Initial value registration for the attribute values "ack" and "nack":
属性値「ack」および「nack」の初期値登録：
Value name: sli Long name: Slice Loss Indication Usable with: nack Reference: RFC 4585.
値の名前：sliロングネーム：スライス損失表示使用可能：nack参照：RFC 4585。
Value name: pli Long name: Picture Loss Indication Usable with: nack Reference: RFC 4585.
値の名前：pliロングネーム：ピクチャロスインジケーション使用可能：nackリファレンス：RFC 4585。
Value name: rpsi Long name: Reference Picture Selection Indication Usable with: ack, nack Reference: RFC 4585.
値の名前：rpsi長い名前：参照画像の選択表示使用可能なもの：ack、nack参照：RFC 4585。
Value name: app Long name: Application layer feedback Usable with: ack, nack Reference: RFC 4585.
値の名前：appロングネーム：アプリケーションレイヤーフィードバック使用可能：ack、nack参照：RFC 4585。
Further entries may be registered on a first-come first-serve basis. Each registration needs to indicate the parameter name, the syntax of possible additional arguments, and whether the parameter is applicable to "ack" or "nack" feedback or both or some different "rtcp-fb" attribute parameter. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter, the syntax and semantics of its parameters as well as corresponding feedback packet formats (if needed). The general registration procedures of [3] apply.
その他のエントリーは先着順で登録できます。各登録では、パラメーター名、可能な追加引数の構文、およびパラメーターが「ack」または「nack」フィードバック、あるいはその両方、またはいくつかの異なる「rtcp-fb」属性パラメーターに適用可能かどうかを示す必要があります。新規登録ごとに、登録されたパラメーターのセマンティクス、パラメーターの構文とセマンティクス、および対応するフィードバックパケット形式（必要な場合）を指定する、永続的で安定した、公開されたドキュメントが存在することが必須です。 [3]の一般的な登録手順が適用されます。
Two RTCP Control Packet Types: for the class of transport layer FB messages ("RTPFB") and for the class of payload-specific FB messages ("PSFB"). Per Section 6, RTPFB=205 and PSFB=206 have been added to the RTCP registry.
2つのRTCP制御パケットタイプ：トランスポート層FBメッセージのクラス（「RTPFB」）およびペイロード固有のFBメッセージのクラス（「PSFB」）。セクション6に従って、RTPFB = 205およびPSFB = 206がRTCPレジストリに追加されました。
RTP RTCP Control Packet types (PT):
RTP RTCP制御パケットタイプ（PT）：
Name: RTPFB Long name: Generic RTP Feedback Value: 205 Reference: RFC 4585.
名前：RTPFB長い名前：一般的なRTPフィードバック値：205参照：RFC 4585。
Name: PSFB Long name: Payload-specific Value: 206 Reference: RFC 4585.
名前：PSFB長い名前：ペイロード固有の値：206参照：RFC 4585。
As AVPF defines additional RTCP payload types, the corresponding "reserved" RTP payload type space (72-76, as defined in [2]), has been expanded accordingly.
AVPFは追加のRTCPペイロードタイプを定義するので、対応する「予約済み」RTPペイロードタイプスペース（[2]で定義されている72〜76）は、それに応じて拡張されています。
A new sub-registry has been set up for the FMT values for both the RTPFB payload type and the PSFB payload type, with the following registrations created initially:
RTPFBペイロードタイプとPSFBペイロードタイプの両方のFMT値に対して、新しいサブレジストリがセットアップされ、最初に次の登録が作成されました。
Within the RTPFB range, the following two format (FMT) values are initially registered:
RTPFB範囲内では、次の2つのフォーマット（FMT）値が最初に登録されています。
Name: Generic NACK Long name: Generic negative acknowledgement Value: 1 Reference: RFC 4585.
名前：ジェネリックNACKロングネーム：ジェネリック否定応答値：1参照：RFC 4585。
Name: Extension Long name: Reserved for future extensions Value: 31 Reference: RFC 4585.
名前：拡張ロングネーム：将来の拡張用に予約済み値：31参照：RFC 4585。
Within the PSFB range, the following five format (FMT) values are initially registered:
PSFB範囲内では、次の5つのフォーマット（FMT）値が最初に登録されます。
Name: PLI Long name: Picture Loss Indication Value: 1 Reference: RFC 4585.
名前：PLI長い名前：ピクチャロス表示値：1参照：RFC 4585。
Name: SLI Long name: Slice Loss Indication Value: 2 Reference: RFC 4585.
名前：SLI長い名前：スライス損失表示値：2参照：RFC 4585。
Name: RPSI Long name: Reference Picture Selection Indication Value: 3 Reference: RFC 4585.
名前：RPSI長い名前：参照画像選択表示値：3参照：RFC 4585。
Name: AFB Long name: Application Layer Feedback Value: 15 Reference: RFC 4585.
名前：AFB長い名前：アプリケーション層フィードバック値：15参照：RFC 4585。
Name: Extension Long name: Reserved for future extensions. Value: 31 Reference: RFC 4585.
名前：拡張ロングネーム：将来の拡張のために予約されています。値：31参照：RFC 4585。
Further entries may be registered following the "Specification Required" rules as defined in RFC 2434 [9]. Each registration needs to indicate the FMT value, if there is a specific FB message to go into the FCI field, and whether or not multiple FB messages may be stacked in a single FCI field. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter as well as the syntax and semantics of the associated FB message (if any). The general registration procedures of [3] apply.
RFC 2434 [9]で定義されている「Specification Required」ルールに従って、さらにエントリを登録できます。 FCIフィールドに入る特定のFBメッセージがある場合、および複数のFBメッセージが単一のFCIフィールドにスタックされるかどうか、各登録はFMT値を示す必要があります。新規登録ごとに、登録されたパラメーターのセマンティクスおよび関連するFBメッセージ（存在する場合）の構文とセマンティクスを指定する、永続的で安定した、公的にアクセス可能なドキュメントが存在することが必須です。 [3]の一般的な登録手順が適用されます。
This document is a product of the Audio-Visual Transport (AVT) Working Group of the IETF. The authors would like to thank Steve Casner and Colin Perkins for their comments and suggestions as well as for their responsiveness to numerous questions. The authors would also like to particularly thank Magnus Westerlund for his review and his valuable suggestions and Shigeru Fukunaga for the contributions on FB message formats and semantics.
このドキュメントは、IETFのオーディオビジュアルトランスポート（AVT）ワーキンググループの製品です。著者は、スティーブキャスナーとコリンパーキンスのコメントと提案、および多数の質問への対応に感謝します。著者はまた、特に彼のレビューと彼の貴重な提案のためのマグヌス・ヴェスタールンドと、FBメッセージ形式と意味論への貢献のための福永茂に感謝したいと思います。
We would also like to thank Andreas Buesching and people at Panasonic for their simulations and the first independent implementations of the feedback profile.
シミュレーションとフィードバックプロファイルの最初の独立した実装について、Andreas BueschingとPanasonicの人々にも感謝します。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[2] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[3] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[4] Casner、S。、「RTP制御プロトコル（RTCP）帯域幅用のセッション記述プロトコル（SDP）帯域幅修飾子」、RFC 3556、2003年7月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.
[6] Turletti、T.およびC. Huitema、「RTP Payload Format for H.261 Video Streams」、RFC 2032、1996年10月。
[7] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[7] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 3448、2003年1月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、2002年6月。
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[9] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[10] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[10] Camarillo、G.、Eriksson、G.、Holler、J。、およびH. Schulzrinne、「Grouping of Media Lines in the Session Description Protocol（SDP）」、RFC 3388、2002年12月。
[11] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[11] パーキンス、C。およびO.ホドソン、「ストリーミングメディアの修復オプション」、RFC 2354、1998年6月。
[12] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[12] Rosenberg、J。およびH. Schulzrinne、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 2733、1999年12月。
[13] 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.
[13] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、「RTP Payload for Redundant Audioデータ」、RFC 2198、1997年9月。
[14] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C., Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. Zhu, "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)", RFC 2429, October 1998.
[14] Bormann、C.、Cline、L.、Deisher、G.、Gardos、T.、Maciocco、C.、Newell、D.、Ott、J.、Sullivan、G.、Wenger、S.、and C. Zhu、 「1998年版のITU-T Rec。H.263ビデオ（H.263 +）のRTPペイロード形式」、RFC 2429、1998年10月。
[15] B. Girod, N. Faerber, "Feedback-based error control for mobile video transmission", Proceedings IEEE, Vol. 87, No. 10, pp. 1707 - 1723, October, 1999.
[15] B. Girod、N。Faerber、「モバイルビデオ伝送のためのフィードバックベースのエラー制御」、Proceedings IEEE、Vol。 87、No.10、pp.1707-1723、1999年10月。
[16] ISO/IEC 14496-2:2001/Amd.1:2002, "Information technology - Coding of audio-visual objects - Part2: Visual", 2001.
[16] ISO / IEC 14496-2：2001 / Amd.1：2002、「情報技術-視聴覚オブジェクトのコーディング-パート2：ビジュアル」、2001。
[17] ITU-T Recommendation H.263, "Video Coding for Low Bit Rate Communication", November 2000.
[17] ITU-T勧告H.263、「低ビットレート通信用のビデオコーディング」、2000年11月。
[18] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[18] Schulzrinne、H。およびS. Petrack、「DTMFディジット、テレフォニートーンおよびテレフォニーシグナル用のRTPペイロード」、RFC 2833、2000年5月。
[19] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[19] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、2006年3月。
[20] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[20] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 3448、2003年1月。
[21] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", Work in Progress, December 2005.
[21] Ott、J。およびE. Carrara、「RTCPベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、進行中の作業、2005年12月。
[22] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[22] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[23] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H. Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams", RFC 3016, November 2000.
[23] きくち、 Ｙ。、 のむら、 Ｔ。、 ふくなが、 Ｓ。、 まつい、 Ｙ。、 あんｄ Ｈ。 きまた、 ”ＲＴＰ ぱｙぉあｄ ふぉｒまｔ ふぉｒ ＭぺＧー４ あうぢお／ゔぃすあｌ Ｓｔれあｍｓ”、 ＲＦＣ ３０１６、 のゔぇｍべｒ ２０００。
[24] ITU-T Recommendation H.245, "Control protocol for multimedia communication", May 2006.
[24] ITU-T勧告H.245、「マルチメディア通信の制御プロトコル」、2006年5月。
Authors' Addresses
著者のアドレス
Joerg Ott Helsinki University of Technology (TKK) Networking Laboratory PO Box 3000 FIN-02015 TKK Finland
Joerg Ott Helsinki University of Technology（TKK）Networking Laboratory PO Box 3000 FIN-02015 TKK Finland
EMail: jo@acm.org
Stephan Wenger Nokia Research Center P.O. Box 100 33721 Tampere Finland
ステファンウェンガーノキアリサーチセンターP.O.ボックス100 33721タンペレフィンランド
EMail: stewe@stewe.org
Noriyuki Sato Oki Electric Industry Co., Ltd. 1-16-8 Chuo, Warabi-city, Saitama 335-8510 Japan
のりゆき さと おき えぇｃｔりｃ いんづｓｔｒｙ こ。、 Ｌｔｄ。 １ー１６ー８ ちゅお、 わらびーしｔｙ、 さいたま ３３５ー８５１０ じゃぱん
Phone: +81 48 431 5932
Fax: +81 48 431 9115
EMail: sato652@oki.com
Carsten Burmeister Panasonic R&D Center Germany GmbH
Carsten Burmeister Panasonic R＆D Center Germany GmbH
EMail: carsten.burmeister@eu.panasonic.com
Jose Rey Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
Jose Rey Panasonic R＆D Center Germany GmbH Monzastr。 4c D-63225ランゲン、ドイツ
EMail: jose.rey@eu.panasonic.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許申請、またはその他の所有権に注意を向けるよう、関係者に呼びかけています。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。