[要約] RFC 3611はRTCP XRの仕様であり、RTPセッションの品質監視と診断のための拡張レポートを提供します。目的は、ネットワークの問題を特定し、RTPセッションのパフォーマンスを向上させることです。
Network Working Group T. Friedman, Ed.
Request for Comments: 3611 Paris 6
Category: Standards Track R. Caceres, Ed.
IBM Research
A. Clark, Ed.
Telchemy
November 2003
RTP Control Protocol Extended Reports (RTCP XR)
RTPコントロールプロトコル拡張レポート（RTCP XR）
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.
このドキュメントでは、RTPコントロールプロトコル（RTCP）の拡張レポート（XR）パケットタイプを定義し、セッション説明プロトコル（SDP）を使用した場合、XRパケットの使用をアプリケーションによってどのように信号を送信できるかを定義します。XRパケットはレポートブロックで構成されており、ここで7つのブロックタイプが定義されています。拡張レポート形式の目的は、RTCPの送信者レポート（SR）およびレシーバーレポート（RR）パケットで使用されるレポートブロックに含まれる6つの統計を補足する情報を伝えることです。ネットワーク特性（MINC）のマルチキャスト推論やVoice over IP（VoIP）モニタリングなど、一部のアプリケーションには、その他の詳細な統計が必要です。ここで定義されているブロックタイプに加えて、このドキュメントが提供するフレームワークを順守することにより、追加のブロックタイプが将来定義される場合があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 7
2. XR Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7
3. Extended Report Block Framework. . . . . . . . . . . . . . . . 8
4. Extended Report Blocks . . . . . . . . . . . . . . . . . . . . 9
4.1. Loss RLE Report Block. . . . . . . . . . . . . . . . . . 9
4.1.1. Run Length Chunk . . . . . . . . . . . . . . . . 15
4.1.2. Bit Vector Chunk . . . . . . . . . . . . . . . . 15
4.1.3. Terminating Null Chunk . . . . . . . . . . . . . 16
4.2. Duplicate RLE Report Block . . . . . . . . . . . . . . . 16
4.3. Packet Receipt Times Report Block. . . . . . . . . . . . 18
4.4. Receiver Reference Time Report Block . . . . . . . . . . 20
4.5. DLRR Report Block. . . . . . . . . . . . . . . . . . . . 21
4.6. Statistics Summary Report Block. . . . . . . . . . . . . 22
4.7. VoIP Metrics Report Block. . . . . . . . . . . . . . . . 25
4.7.1. Packet Loss and Discard Metrics. . . . . . . . . 27
4.7.2. Burst Metrics. . . . . . . . . . . . . . . . . . 27
4.7.3. Delay Metrics. . . . . . . . . . . . . . . . . . 30
4.7.4. Signal Related Metrics . . . . . . . . . . . . . 31
4.7.5. Call Quality or Transmission Quality Metrics . . 33
4.7.6. Configuration Parameters . . . . . . . . . . . . 34
4.7.7. Jitter Buffer Parameters . . . . . . . . . . . . 36
5. SDP Signaling. . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1. The SDP Attribute. . . . . . . . . . . . . . . . . . . . 37
5.2. Usage in Offer/Answer. . . . . . . . . . . . . . . . . . 40
5.3. Usage Outside of Offer/Answer. . . . . . . . . . . . . . 42
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 42
6.1. XR Packet Type . . . . . . . . . . . . . . . . . . . . . 42
6.2. RTCP XR Block Type Registry. . . . . . . . . . . . . . . 42
6.3. The "rtcp-xr" SDP Attribute. . . . . . . . . . . . . . . 43
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
A. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.1. Sequence Number Interpretation . . . . . . . . . . . . . 46
A.2. Example Burst Packet Loss Calculation. . . . . . . . . . 47
Intellectual Property Notice . . . . . . . . . . . . . . . . . . . 49
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 50
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . . . . . 51
Informative References . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 55
This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP) [9], and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP) [4]. XR packets convey information beyond that already contained in the reception report blocks of RTCP's sender report (SR) or Receiver Report (RR) packets. The information is of use across RTP profiles, and so is not appropriately carried in SR or RR profile-specific extensions. Information used for network management falls into this category, for instance.
このドキュメントでは、RTPコントロールプロトコル（RTCP）[9]の拡張レポート（XR）パケットタイプを定義し、セッション説明プロトコル（SDP）[4]を使用した場合、XRパケットの使用をアプリケーションによってどのように信号を送信できるかを定義します。。XRパケットは、RTCPの送信者レポート（SR）またはレシーバーレポート（RR）パケットの受信レポートブロックに既に含まれているものを超えて情報を伝えます。情報はRTPプロファイル全体で使用されるため、SRまたはRRプロファイル固有の拡張機能では適切に運ばれていません。たとえば、ネットワーク管理に使用される情報は、このカテゴリに分類されます。
The definition is broken out over the three sections that follow the Introduction. Section 2 defines the XR packet as consisting of an eight octet header followed by a series of components called report blocks. Section 3 defines the common format, or framework, consisting of a type and a length field, required for all report blocks. Section 4 defines several specific report block types. Other block types can be defined in future documents as the need arises.
定義は、導入に続く3つのセクションで分割されています。セクション2では、XRパケットを8つのオクテットヘッダーと、それに続いてレポートブロックと呼ばれる一連のコンポーネントで構成されていると定義しています。セクション3では、すべてのレポートブロックに必要なタイプと長さのフィールドで構成される共通形式またはフレームワークを定義します。セクション4では、いくつかの特定のレポートブロックタイプを定義します。他のブロックタイプは、必要に応じて将来のドキュメントで定義できます。
The report block types defined in this document fall into three categories. The first category consists of packet-by-packet reports on received or lost RTP packets. Reports in the second category convey reference time information between RTP participants. In the third category, reports convey metrics relating to packet receipts, that are summary in nature but that are more detailed, or of a different type, than that conveyed in existing RTCP packets.
このドキュメントで定義されているレポートブロックタイプは、3つのカテゴリに分類されます。最初のカテゴリは、受信または紛失したRTPパケットに関するパケットごとのレポートで構成されています。2番目のカテゴリのレポートは、RTP参加者間で参照時間情報を伝えます。3番目のカテゴリでは、レポートは、本質的に要約ですが、既存のRTCPパケットで伝えられているものよりも詳細または異なるタイプのメトリックを伝えます。
All told, seven report block formats are defined by this document. Of these, three are packet-by-packet block types:
すべてのことに、7つのレポートブロック形式がこのドキュメントで定義されています。これらのうち、3つはパケットごとのブロックタイプです。
- Loss RLE Report Block (Section 4.1): Run length encoding of reports concerning the losses and receipts of RTP packets.
- 損失RLEレポートブロック（セクション4.1）：RTPパケットの損失と領収書に関するレポートの長さエンコードを実行します。
- Duplicate RLE Report Block (Section 4.2): Run length encoding of reports concerning duplicates of received RTP packets.
- 重複RLEレポートブロック（セクション4.2）：受信したRTPパケットの複製に関するレポートの長さエンコードを実行します。
- Packet Receipt Times Report Block (Section 4.3): A list of reception timestamps of RTP packets.
- パケットレシート時間レポートブロック（セクション4.3）：RTPパケットの受信タイムスタンプのリスト。
There are two reference time related block types:
2つの参照時間関連ブロックタイプがあります。
- Receiver Reference Time Report Block (Section 4.4): Receiver-end wallclock timestamps. Together with the DLRR Report Block mentioned next, these allow non-senders to calculate round-trip times.
- レシーバー参照時間レポートブロック（セクション4.4）：レシーバーエンドウォールクロックタイムスタンプ。次に説明したDLRRレポートブロックとともに、これらは非センダーが往復時間を計算することを可能にします。
- DLRR Report Block (Section 4.5): The delay since the last Receiver Reference Time Report Block was received. An RTP data sender that receives a Receiver Reference Time Report Block can respond with a DLRR Report Block, in much the same way as, in the mechanism already defined for RTCP [9, Section 6.3.1], an RTP data receiver that receives a sender's NTP timestamp can respond by filling in the DLSR field of an RTCP reception report block.
- DLRRレポートブロック（セクション4.5）：最後のレシーバー参照時間レポートブロック以降の遅延が受信されました。受信者参照時間レポートブロックを受信するRTPデータ送信者は、DLRRレポートブロックで応答できます。送信者のNTPタイムスタンプは、RTCP受信レポートブロックのDLSRフィールドに記入することで応答できます。
Finally, this document defines two summary metric block types:
最後に、このドキュメントでは、2つの要約メトリックブロックタイプを定義します。
- Statistics Summary Report Block (Section 4.6): Statistics on RTP packet sequence numbers, losses, duplicates, jitter, and TTL or Hop Limit values.
- 統計概要レポートブロック（セクション4.6）：RTPパケットシーケンス番号、損失、複製、ジッター、TTLまたはホップ制限値の統計。
- VoIP Metrics Report Block (Section 4.7): Metrics for monitoring Voice over IP (VoIP) calls.
- VoIPメトリックレポートブロック（セクション4.7）：IP（VOIP）コールを監視するためのメトリック。
Before proceeding to the XR packet and report block definitions, this document provides an applicability statement (Section 1.1) that describes the contexts in which these report blocks can be used. It also defines (Section 1.2) the normative use of key words, such as MUST and SHOULD, as they are employed in this document.
XRパケットとレポートブロック定義に進む前に、このドキュメントは、これらのレポートブロックを使用できるコンテキストを説明する適用可能性ステートメント（セクション1.1）を提供します。また、このドキュメントで採用されているように、必要とするようなキーワードの規範的使用を定義します（セクション1.2）。
Following the definitions of the various report blocks, this document describes how applications that employ SDP can signal their use (Section 5). The document concludes with a discussion (Section 6) of numbering considerations for the Internet Assigned Numbers Authority (IANA), of security considerations (Section 7), and with appendices that provide examples of how to implement algorithms discussed in the text.
さまざまなレポートブロックの定義に従って、このドキュメントでは、SDPを採用するアプリケーションが使用の使用をどのように通知できるかについて説明します（セクション5）。このドキュメントは、インターネットに割り当てられた数字の権限（IANA）、セキュリティに関する考慮事項（セクション7）の番号付けに関する考慮事項（セクション6）の議論（セクション6）、およびテキストで説明されているアルゴリズムを実装する方法の例を提供する付録で締めくくります。
The XR packets are useful across multiple applications, and for that reason are not defined as profile-specific extensions to RTCP sender or Receiver Reports [9, Section 6.4.3]. Nonetheless, they are not of use in all contexts. In particular, the VoIP metrics report block (Section 4.7) is specific to voice applications, though it can be employed over a wide variety of such applications.
XRパケットは複数のアプリケーションにわたって有用であり、そのため、RTCP送信者または受信者レポートへのプロファイル固有の拡張機能として定義されていません[9、セクション6.4.3]。それにもかかわらず、それらはすべての文脈では使用しません。特に、VoIPメトリックレポートブロック（セクション4.7）は音声アプリケーションに固有のものですが、さまざまなアプリケーションで使用できます。
The VoIP metrics report block can be applied to any one-to-one or one-to-many voice application for which the use of RTP and RTCP is specified. The use of conversational metrics (Section 4.7.5), including the R factor (as described by the E Model defined in [3]) and the mean opinion score for conversational quality (MOS-CQ), in applications other than simple two party calls is not defined; hence, these metrics should be identified as unavailable in multicast conferencing applications.
VoIP Metricsレポートブロックは、RTPおよびRTCPの使用が指定されている1対1または1対10の音声アプリケーションに適用できます。単純な2つのパーティ以外のアプリケーションでのR因子（[3]で定義されているEモデルで説明されているEモデルで説明されている）および会話品質（MOS-CQ）の平均意見スコアを含む会話型メトリックの使用（セクション4.7.5）の使用（セクション4.7.5）呼び出しは定義されていません。したがって、これらのメトリックは、マルチキャスト会議アプリケーションでは利用できないと特定する必要があります。
The packet-by-packet report block types, Loss RLE (Section 4.1), Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3), have been defined with network tomography applications, such as multicast inference of network characteristics (MINC) [11], in mind. MINC requires detailed packet receipt traces from multicast session receivers in order to infer the gross structure of the multicast distribution tree and the parameters, such as loss rates and delays, that apply to paths between the branching points of that tree.
パケットごとのレポートブロックタイプ、損失RLE（セクション4.1）、重複RLE（セクション4.2）、およびパケットレシート時間（セクション4.3）は、ネットワーク特性のマルチキャスト推論（MINCなどのネットワーク断層撮影アプリケーションで定義されています。）[11]、念頭に置いて。MINCは、マルチキャスト配布ツリーの総構造と、そのツリーの分岐点間のパスに適用される損失率や遅延などのパラメーターを推測するために、マルチキャストセッションレシーバーからの詳細なパケットレシートトレースを必要とします。
Any real time multicast multimedia application can use the packet-by-packet report block types. Such an application could employ a MINC inference subsystem that would provide it with multicast tree topology information. One potential use of such a subsystem would be for the identification of high loss regions in the multicast tree and the identification of multicast session participants well situated to provide retransmissions of lost packets.
リアルタイムマルチキャストマルチメディアアプリケーションは、パケットごとのレポートブロックタイプを使用できます。このようなアプリケーションは、マルチキャストツリートポロジー情報を提供するMINC推論サブシステムを使用できます。このようなサブシステムの潜在的な使用の1つは、マルチキャストツリーの高損失領域の識別と、失われたパケットの再送信を提供するために適切に位置するマルチキャストセッション参加者の識別のためです。
Detailed packet-by-packet reports do not necessarily have to consume disproportionate bandwidth with respect to other RTCP packets. An application can cap the size of these blocks. A mechanism called "thinning" is provided for these report blocks, and can be used to ensure that they adhere to a size limit by restricting the number of packets reported upon within any sequence number interval. The rationale for, and use of this mechanism is described in [13]. Furthermore, applications might not require report blocks from all receivers in order to answer such important questions as where in the multicast tree there are paths that exceed a defined loss rate threshold. Intelligent decisions regarding which receivers send these report blocks can further restrict the portion of RTCP bandwidth that they consume.
詳細なパケットごとのレポートでは、他のRTCPパケットに関して不均衡な帯域幅を消費する必要はありません。アプリケーションは、これらのブロックのサイズをキャップできます。これらのレポートブロックには「薄化」と呼ばれるメカニズムが提供され、任意のシーケンス数間隔内で報告されたパケットの数を制限することにより、サイズの制限に付着するように使用できます。このメカニズムの理論的根拠と使用は[13]で説明されています。さらに、アプリケーションは、マルチキャストツリーの場所が定義された損失率のしきい値を超えるパスがあるような重要な質問に答えるために、すべてのレシーバーからのレポートブロックを必要としない場合があります。これらのレポートブロックを送信する受信者に関するインテリジェントな決定により、消費するRTCP帯域幅の部分をさらに制限できます。
The packet-by-packet report blocks can also be used by dedicated network monitoring applications. For such an application, it might be appropriate to allow more than 5% of RTP data bandwidth to be used for RTCP packets, thus allowing proportionately larger and more detailed report blocks.
パケットごとのレポートブロックは、専用のネットワーク監視アプリケーションでも使用できます。このようなアプリケーションの場合、RTPデータ帯域幅の5％以上をRTCPパケットに使用できるようにすることが適切かもしれません。
Nothing in the packet-by-packet block types restricts their use to multicast applications. In particular, they could be used for network tomography similar to MINC, but using striped unicast packets instead. In addition, if it were found useful, they could be used for applications limited to two participants.
パケットごとのブロックタイプには、マルチキャストアプリケーションへの使用が制限されるものはありません。特に、それらはMINCに似たネットワーク断層撮影に使用できますが、代わりにストライプのユニキャストパケットを使用します。さらに、有用であると判断された場合、2人の参加者に限定されたアプリケーションに使用できます。
One use to which the packet-by-packet reports are not immediately suited is for data packet acknowledgments as part of a packet retransmission mechanism. The reason is that the packet accounting technique suggested for these blocks differs from the packet accounting normally employed by RTP. In order to favor measurement applications, an effort is made to interpret as little as possible at the data receiver, and leave the interpretation as much as possible to participants that receive the report blocks. Thus, for example, a packet with an anomalous SSRC ID or an anomalous sequence number might be excluded by normal RTP accounting, but would be reported upon for network monitoring purposes.
パケットごとのレポートがすぐに適していない場合の1つは、パケット再送信メカニズムの一部としてデータパケット承認のためです。その理由は、これらのブロックに対して提案されたパケット会計手法は、通常RTPが採用するパケット会計とは異なるためです。測定アプリケーションを支持するために、データ受信機ではできるだけ解釈を解釈し、レポートブロックを受け取った参加者にできるだけ解釈を残す努力がなされます。したがって、たとえば、異常なSSRC IDまたは異常なシーケンス番号を備えたパケットは、通常のRTPアカウンティングによって除外される可能性がありますが、ネットワーク監視目的で報告されます。
The Statistics Summary Report Block (Section 4.6) has also been defined with network monitoring in mind. This block type can be used equally well for reporting on unicast and multicast packet reception.
統計概要レポートブロック（セクション4.6）も、ネットワーク監視を念頭に置いて定義されています。このブロックタイプは、ユニキャストおよびマルチキャストパケット受信のレポートに等しく使用できます。
The reference time related block types were conceived for receiver-based TCP-friendly multicast congestion control [18]. By allowing data receivers to calculate their round trip times to senders, they help the receivers estimate the downstream bandwidth they should request. Note that if every receiver is to send Receiver Reference Time Report Blocks (Section 4.4), a sender might potentially send a number of DLRR Report Blocks (Section 4.5) equal to the number of receivers whose RTCP packets have arrived at the sender within its reporting interval. As the number of participants in a multicast session increases, an application should use discretion regarding which participants send these blocks, and how frequently.
参照時間関連ブロックタイプは、受信機ベースのTCPフレンドリーマルチキャスト輻輳制御のために考案されました[18]。データレシーバーが送信者への往復時間を計算できるようにすることで、レシーバーが要求すべき下流の帯域幅を推定するのに役立ちます。すべての受信機がレシーバー参照時間レポートブロックを送信する場合（セクション4.4）、送信者は、RTCPパケットがレポート内で送信者に到着したレシーバーの数に等しい多数のDLRRレポートブロック（セクション4.5）を送信する可能性があることに注意してください。間隔。マルチキャストセッションの参加者の数が増えると、アプリケーションは、参加者がこれらのブロックを送信する頻度に関する裁量を使用する必要があります。
XR packets supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6]. The introduction of XR packets into a session in no way changes the rules governing the calculation of the RTCP reporting interval [9, Section 6.2]. As XR packets are RTCP packets, they count as such for bandwidth calculations. As a result, the addition of extended reporting information may tend to increase the average RTCP packet size, and thus the average reporting interval. This increase may be limited by limiting the size of XR packets.
XRパケットは既存のRTCPパケットを補足し、他のRTCPパケットと積み重ねて化合物RTCPパケットを形成することができます[9、セクション6]。XRパケットをセッションに導入すると、RTCPレポート間隔の計算を管理するルールが変更されません[9、セクション6.2]。XRパケットはRTCPパケットであるため、帯域幅計算ではそのようにカウントされます。その結果、拡張レポート情報を追加すると、平均RTCPパケットサイズが増加する傾向があるため、平均レポート間隔が増加する可能性があります。この増加は、XRパケットのサイズを制限することで制限される場合があります。
The SDP signaling defined for XR packets in this document (Section 5) was done so with three use scenarios in mind: a Real Time Streaming Protocol (RTSP) controlled streaming application, a one-to-many multicast multimedia application such as a course lecture with enhanced feedback, and a Session Initiation Protocol (SIP) controlled conversational session involving two parties. Applications that employ SDP are free to use additional SDP signaling for cases not covered here. In addition, applications are free to use signaling mechanisms other than SDP.
このドキュメントでXRパケットに対して定義されたSDPシグナリング（セクション5）は、3つの使用シナリオを念頭に置いて行われました。リアルタイムストリーミングプロトコル（RTSP）制御ストリーミングアプリケーション、コース講義などの1対多くのマルチキャストマルチメディアアプリケーションでフィードバックが強化され、セッション開始プロトコル（SIP）が2つのパーティを含む会話セッションを制御します。SDPを採用するアプリケーションは、ここでカバーされていないケースに追加のSDPシグナル伝達を自由に使用できます。さらに、アプリケーションはSDP以外のシグナル伝達メカニズムを自由に使用できます。
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 BCP 14, RFC 2119 [1] and indicate requirement levels for compliance with this specification.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈され、この仕様に準拠するための要件レベルを示します。
An XR packet consists of a header of two 32-bit words, followed by a number, possibly zero, of extended report blocks. This type of packet is laid out in a manner consistent with other RTCP packets, as concerns the essential version, packet type, and length information. XR packets are thus backwards compatible with RTCP receiver implementations that do not recognize them, but that ought to be able to parse past them using the length information. A padding field and an SSRC field are also provided in the same locations that they appear in other RTCP packets, for simplicity. The format is as follows:
XRパケットは、2つの32ビット単語のヘッダーで構成され、その後に拡張レポートブロックの数（おそらくゼロ）が続きます。このタイプのパケットは、重要なバージョン、パケットタイプ、および長さの情報に関するものであるため、他のRTCPパケットと一致する方法でレイアウトされています。したがって、XRパケットは、それらを認識していないRTCPレシーバーの実装と互換性がありますが、長さの情報を使用してそれらを過ぎて解析できるはずです。パディングフィールドとSSRCフィールドは、簡単にするために、他のRTCPパケットに表示される同じ場所にも提供されます。フォーマットは次のとおりです。
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|reserved | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (V): 2 bits Identifies the version of RTP. This specification applies to RTP version two.
バージョン（v）：2ビットはRTPのバージョンを識別します。この仕様は、RTPバージョン2に適用されます。
padding (P): 1 bit If the padding bit is set, this XR packet contains some additional padding octets at the end. The semantics of this field are identical to the semantics of the padding field in the SR packet, as defined by the RTP specification.
パディング（P）：パディングビットが設定されている場合、このXRパケットには、最後に追加のパディングオクテットが含まれています。このフィールドのセマンティクスは、RTP仕様で定義されているように、SRパケットのパディングフィールドのセマンティクスと同じです。
reserved: 5 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
予約済み：5ビットこのフィールドは、将来の定義のために予約されています。このような定義がない場合、このフィールドのビットはゼロに設定する必要があり、受信機は無視する必要があります。
packet type (PT): 8 bits Contains the constant 207 to identify this as an RTCP XR packet. This value is registered with the Internet Assigned Numbers Authority (IANA), as described in Section 6.1.
パケットタイプ（PT）：8ビットには、これをRTCP XRパケットとして識別するための定数207が含まれています。この値は、セクション6.1で説明されているように、インターネットAssigned Numbers Authority（IANA）に登録されています。
length: 16 bits As described for the RTCP Sender Report (SR) packet (see Section 6.4.1 of the RTP specification [9]). Briefly, the length of this XR packet in 32-bit words minus one, including the header and any padding.
長さ：RTCP送信者レポート（SR）パケットについて説明されている16ビット（RTP仕様[9]のセクション6.4.1を参照）。簡単に言えば、このXRパケットの長さは、32ビットの単語から1つを差し引いて、ヘッダーやパディングを含みます。
SSRC: 32 bits The synchronization source identifier for the originator of this XR packet.
SSRC：32ビットこのXRパケットのオリジネーターの同期ソース識別子。
report blocks: variable length. Zero or more extended report blocks. In keeping with the extended report block framework defined below, each block MUST consist of one or more 32-bit words.
レポートブロック：可変長。ゼロ以上の拡張レポートブロック。以下に定義されている拡張レポートブロックフレームワークに合わせて、各ブロックは1つ以上の32ビット単語で構成されている必要があります。
Extended report blocks are stacked, one after the other, at the end of an XR packet. An individual block's length is a multiple of 4 octets. The XR header's length field describes the total length of the packet, including these extended report blocks.
XRパケットの最後に、拡張レポートブロックが次々と積み重ねられます。個々のブロックの長さは、4オクテットの倍数です。XRヘッダーの長さフィールドは、これらの拡張レポートブロックを含むパケットの全長を記述します。
Each block has block type and length fields that facilitate parsing. A receiving application can demultiplex the blocks based upon their type, and can use the length information to locate each successive block, even in the presence of block types it does not recognize.
各ブロックには、解析を容易にするブロックタイプと長さのフィールドがあります。受信アプリケーションは、そのタイプに基づいてブロックを非難することができ、長さの情報を使用して、それぞれのブロックタイプが存在する場合でも、それぞれの連続したブロックを見つけることができます。
An extended report block has the following format:
拡張レポートブロックには、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | type-specific | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: type-specific block contents :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits Identifies the block format. Seven block types are defined in Section 4. Additional block types may be defined in future specifications. This field's name space is managed by the Internet Assigned Numbers Authority (IANA), as described in Section 6.2.
ブロックタイプ（BT）：8ビットはブロック形式を識別します。セクション4で7つのブロックタイプを定義します。追加のブロックタイプは、将来の仕様で定義できます。このフィールドの名前スペースは、セクション6.2で説明されているように、インターネットAssigned Numbers Authority（IANA）によって管理されます。
type-specific: 8 bits The use of these bits is determined by the block type definition.
タイプ固有：8ビットこれらのビットの使用は、ブロックタイプ定義によって決定されます。
block length: 16 bits The length of this report block, including the header, in 32- bit words minus one. If the block type definition permits, zero is an acceptable value, signifying a block that consists of only the BT, type-specific, and block length fields, with a null type-specific block contents field.
ブロックの長さ：ヘッダーを含むこのレポートブロックの長さを16ビット32ビット単語から1つから1つマイナスします。ブロックタイプの定義が許可されている場合、ゼロは許容値であり、nullタイプ固有のブロックコンテンツフィールドを備えたBT、タイプ固有、およびブロック長のフィールドのみで構成されるブロックを意味します。
type-specific block contents: variable length The use of this field is defined by the particular block type, subject to the constraint that it MUST be a multiple of 32 bits long. If the block type definition permits, It MAY be zero bits long.
タイプ固有のブロックコンテンツ：可変長このフィールドの使用は、特定のブロックタイプによって定義されます。ブロックタイプの定義が許可されている場合、長さはゼロになる可能性があります。
This section defines seven extended report blocks: block types for reporting upon received packet losses and duplicates, packet reception times, receiver reference time information, receiver inter-report delays, detailed reception statistics, and voice over IP (VoIP) metrics. An implementation SHOULD ignore incoming blocks with types not relevant or unknown to it. Additional block types MUST be registered with the Internet Assigned Numbers Authority (IANA) [16], as described in Section 6.2.
このセクションでは、7つの拡張レポートブロックを定義します。受信したパケット損失と複製時のレポートのブロックタイプ、パケット受信時間、受信機の参照時間情報、受信機間レポートの遅延、詳細な受信統計、Voice over IP（VoIP）メトリック。実装は、関連性がない、または不明なタイプを持つ着信ブロックを無視する必要があります。セクション6.2で説明されているように、追加のブロックタイプは、インターネット割り当てされた番号局（IANA）[16]に登録する必要があります。
This block type permits detailed reporting upon individual packet receipt and loss events. Such reports can be used, for example, for multicast inference of network characteristics (MINC) [11]. With MINC, one can discover the topology of the multicast tree used for distributing a source's RTP packets, and of the loss rates along links within that tree, or they could be used to provide raw data to a network management application.
このブロックタイプにより、個々のパケットの領収書と損失イベントに関する詳細なレポートが可能になります。このようなレポートは、たとえば、ネットワーク特性（MINC）のマルチキャスト推論に使用できます[11]。MINCを使用すると、ソースのRTPパケットの配布に使用されるマルチキャストツリーのトポロジーと、そのツリー内のリンクに沿った損失率のトポロジを発見したり、ネットワーク管理アプリケーションに生データを提供するために使用できます。
Since a Boolean trace of lost and received RTP packets is potentially lengthy, this block type permits the trace to be compressed through run length encoding. To further reduce block size, loss event reports can be systematically dropped from the trace in a mechanism called thinning that is described below and that is studied in [13].
紛失および受信したRTPパケットのブールトレースは潜在的に長いため、このブロックタイプにより、トレースを実行された長さエンコードで圧縮できます。ブロックサイズをさらに削減するために、下記で説明し、[13]で研究されている薄化と呼ばれるメカニズムで、損失イベントレポートをトレースから体系的に削除することができます。
A participant that generates a Loss RLE Report Block should favor accuracy in reporting on observed events over interpretation of those events whenever possible. Interpretation should be left to those who observe the report blocks. Following this approach implies that accounting for Loss RLE Report Blocks will differ from the accounting for the generation of the SR and RR packets described in the RTP specification [9] in the following two areas: per-sender accounting and per-packet accounting.
損失RLEレポートブロックを生成する参加者は、可能な限りこれらのイベントの解釈をめぐる観察されたイベントに関する報告において正確性を支持する必要があります。解釈は、レポートブロックを観察する人に任されるべきです。このアプローチに従って、RLEレポートブロックの会計は、次の2つの領域でRTP仕様[9]で説明されているSRおよびRRパケットの生成の会計とは異なることを意味します：センダーごとの会計とパケットごとの会計。
In its per-sender accounting, an RTP session participant SHOULD NOT make the receipt of a threshold minimum number of RTP packets a condition for reporting upon the sender of those packets. This accounting technique differs from the technique described in Section 6.2.1 and Appendix A.1 of the RTP specification that allows a threshold to determine whether a sender is considered valid.
センダーごとの会計では、RTPセッションの参加者は、RTPパケットのしきい値の最小数を受信して、これらのパケットの送信者に報告する条件にしないでください。この会計手法は、RTP仕様のセクション6.2.1および付録A.1で説明されている手法とは異なり、しきい値が送信者が有効であると見なされるかどうかを判断できます。
In its per-packet accounting, an RTP session participant SHOULD treat all sequence numbers as valid. This accounting technique differs from the technique described in Appendix A.1 of the RTP specification that suggests ruling a sequence number valid or invalid on the basis of its contiguity with the sequence numbers of previously received packets.
パケットごとの会計では、RTPセッションの参加者は、すべてのシーケンス番号を有効なものとして扱う必要があります。この会計手法は、以前に受信したパケットのシーケンス番号との連続性に基づいて有効または無効なシーケンス番号を支配することを示唆するRTP仕様の付録A.1に記載されている手法とは異なります。
Sender validity and sequence number validity are interpretations of the raw data. Such interpretations are justified in the interest, for example, of excluding the stray old packet from an unrelated session from having an effect upon the calculation of the RTCP transmission interval. The presence of stray packets might, on the other hand, be of interest to a network monitoring application.
送信者の妥当性とシーケンス数の妥当性は、生データの解釈です。このような解釈は、たとえば、無関係なセッションからRTCP伝送間隔の計算に影響を与えることから、迷った古いパケットを除外するという利益のために正当化されます。一方、迷ったパケットの存在は、ネットワーク監視アプリケーションにとって興味深いものになる可能性があります。
One accounting interpretation that is still necessary is for a participant to decide whether the 16 bit sequence number has rolled over. Under ordinary circumstances this is not a difficult task. For example, if packet number 65,535 (the highest possible sequence number) is followed shortly by packet number 0, it is reasonable to assume that there has been a rollover. However, it is possible that the packet is an earlier one (from 65,535 packets earlier). It is also possible that the sequence numbers have rolled over multiple times, either forward or backward. The interpretation becomes more difficult when there are large gaps between the sequence numbers, even accounting for rollover, and when there are long intervals between received packets.
まだ必要な会計解釈の1つは、参加者が16ビットシーケンス番号がロールオーバーしたかどうかを決定することです。通常の状況では、これは難しい作業ではありません。たとえば、パケット番号65,535（可能な限り最高のシーケンス番号）にパケット番号0が続いている場合、ロールオーバーがあったと仮定するのが妥当です。ただし、パケットが以前のパケット（65,535個のパケットから）である可能性があります。また、シーケンス番号が前方または後方のいずれかで複数回転がった可能性もあります。シーケンス番号の間に大きなギャップがある場合、ロールオーバーを考慮しても、受信パケット間に長い間隔がある場合、解釈はより困難になります。
The per-packet accounting technique mandated here is for a participant to keep track of the sequence number of the packet most recently received from a sender. For the next packet that arrives from that sender, the sequence number MUST be judged to fall no more than 32,768 packets ahead or behind the most recent one, whichever choice places it closer. In the event that both choices are equally distant (only possible when the distance is 32,768), the choice MUST be the one that does not require a rollover. Appendix A.1 presents an algorithm that implements this technique.
ここで義務付けられているパケットごとの会計手法は、参加者が最近送信者から受け取ったパケットのシーケンス番号を追跡することです。その送信者から到着する次のパケットの場合、シーケンス番号は、最新のパケットの前または後ろに32,768個以下のパケットを下回ると判断されなければなりません。両方の選択が等しく遠い場合（距離が32,768の場合にのみ可能）、選択はロールオーバーを必要としないものでなければなりません。付録A.1は、この手法を実装するアルゴリズムを示しています。
Each block reports on a single RTP data packet source, identified by its SSRC. The receiver that is supplying the report is identified in the header of the RTCP packet.
各ブロックは、SSRCによって識別される単一のRTPデータパケットソースに報告されています。レポートを提供しているレシーバーは、RTCPパケットのヘッダーで識別されます。
Choice of beginning and ending RTP packet sequence numbers for the trace is left to the application. These values are reported in the block. The last sequence number in the trace MAY differ from the sequence number reported on in any accompanying SR or RR report.
トレースのRTPパケットシーケンス番号の開始および終了の選択は、アプリケーションに任されています。これらの値はブロックで報告されます。トレースの最後のシーケンス番号は、付随するSRまたはRRレポートで報告されたシーケンス番号とは異なる場合があります。
Note that because of sequence number wraparound, the ending sequence number MAY be less than the beginning sequence number. A Loss RLE Report Block MUST NOT be used to report upon a range of 65,534 or greater in the sequence number space, as there is no means of identifying multiple wraparounds.
シーケンス番号がラップアラウンドしているため、終了シーケンス番号は開始シーケンス番号よりも少ない可能性があることに注意してください。複数のラップアラウンドを識別する手段がないため、LOST RLEレポートブロックを使用して65,534以上の範囲の65,534以上を報告してはなりません。
The trace described by a Loss RLE report consists of a sequence of Boolean values, one for each sequence number of the trace. A value of one represents a packet receipt, meaning that one or more packets having that sequence number have been received since the most recent wraparound of sequence numbers (or since the beginning of the RTP session if no wraparound has been judged to have occurred). A value of zero represents a packet loss, meaning that there has been no packet receipt for that sequence number as of the time of the report. If a packet with a given sequence number is received after a report of a loss for that sequence number, a later Loss RLE report MAY report a packet receipt for that sequence number.
損失RLEレポートで説明されているトレースは、トレースの各シーケンス番号に1つのブール値のシーケンスで構成されています。1つの値はパケット領収書を表します。つまり、シーケンス番号の最新のラップアラウンド（またはラップアラウンドが発生したと判断されていない場合はRTPセッションの開始以来）以降、そのシーケンス番号を持つ1つ以上のパケットが受信されたことを意味します。ゼロの値はパケットの損失を表します。つまり、レポートの時点でそのシーケンス番号のパケット領収書がなかったことを意味します。そのシーケンス番号の損失のレポートの後に特定のシーケンス番号を持つパケットが受信された場合、その後の損失RLEレポートは、そのシーケンス番号のパケット領収書を報告することができます。
The encoding itself consists of a series of 16 bit units called chunks that describe sequences of packet receipts or losses in the trace. Each chunk either specifies a run length or a bit vector, or is a null chunk. A run length describes between 1 and 16,383 events that are all the same (either all receipts or all losses). A bit vector describes 15 events that may be mixed receipts and losses. A null chunk describes no events, and is used to round out the block to a 32 bit word boundary.
エンコーディング自体は、トレースのパケット領収書または損失のシーケンスを説明するチャンクと呼ばれる一連の16ビットユニットで構成されています。各チャンクは、実行の長さまたはビットベクトルを指定するか、ヌルチャンクです。実行長は、すべて同じ1〜16,383のイベントを記述します（すべての領収書またはすべての損失のいずれか）。少しベクトルは、領収書や損失が混在する可能性のある15のイベントを説明しています。Null Chunkはイベントを説明しておらず、ブロックを32ビットワード境界まで締めくくるために使用されます。
The mapping from a sequence of lost and received packets into a sequence of chunks is not necessarily unique. For example, the following trace covers 45 packets, of which the 22nd and 24th have been lost and the others received:
失われたパケットと受信したパケットのシーケンスから一連のチャンクにマッピングすることは、必ずしも一意ではありません。たとえば、次のトレースは45のパケットをカバーしています。
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
One way to encode this would be:
これをエンコードする1つの方法は、次のとおりです。
bit vector 1111 1111 1111 111 bit vector 1111 1101 0111 111 bit vector 1111 1111 1111 111 null chunk
ビットベクトル1111 1111 1111 111ビットベクトル1111 1101 0111 111ビットベクトル1111 1111 1111 111 NULL CHUNK
Another way to encode this would be:
これをエンコードする別の方法は次のとおりです。
run of 21 receipts bit vector 0101 1111 1111 111 run of 9 receipts null chunk
21回の領収書の実行ビットベクトル0101 1111 1111 111 9件の領収書Null Chunkの実行
The choice of encoding is left to the application. As part of this freedom of choice, applications MAY terminate a series of run length and bit vector chunks with a bit vector chunk that runs beyond the sequence number space described by the report block. For example, if the 44th packet in the same sequence was lost:
エンコードの選択はアプリケーションに任されています。この選択の自由の一環として、アプリケーションは、レポートブロックで説明されているシーケンス番号スペースを超えて実行されるビットベクトルチャンクで一連の実行長とビットベクトルチャンクを終了する場合があります。たとえば、同じシーケンスの44番目のパケットが失われた場合：
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
This could be encoded as:
これは次のようにエンコードできます。
run of 21 receipts bit vector 0101 1111 1111 111 bit vector 1111 1110 1000 000 null chunk
21回の領収書の実行ビットベクトル0101 1111 1111111ビットベクトル1111 1110 1000 000 nullチャンク
In this example, the last five bits of the second bit vector describe a part of the sequence number space that extends beyond the last sequence number in the trace. These bits have been set to zero.
この例では、2番目のビットベクトルの最後の5ビットは、トレースの最後のシーケンス番号を超えて伸びるシーケンス番号空間の一部を説明しています。これらのビットはゼロに設定されています。
All bits in a bit vector chunk that describe a part of the sequence number space that extends beyond the last sequence number in the trace MUST be set to zero, and MUST be ignored by the receiver.
トレース内の最後のシーケンス番号を超えて伸びるシーケンス番号空間の一部を記述するビットベクトルチャンクのすべてのビットは、ゼロに設定する必要があり、受信機は無視する必要があります。
A null packet MUST appear at the end of a Loss RLE Report Block if the number of run length plus bit vector chunks is odd. The null chunk MUST NOT appear in any other context.
nullパケットは、実行長の数とビットベクトルチャンクの数が奇妙な場合、損失rleレポートブロックの最後に表示する必要があります。ヌルチャンクは、他のコンテキストに表示されてはなりません。
Caution should be used in sending Loss RLE Report Blocks because, even with the compression provided by run length encoding, they can easily consume bandwidth out of proportion with normal RTCP packets. The block type includes a mechanism, called thinning, that allows an application to limit report sizes.
run lents rleレポートブロックの送信には注意が必要です。これは、実行された長さエンコードによって提供される圧縮があっても、通常のRTCPパケットと帯域幅を簡単に消費できるためです。ブロックタイプには、薄化と呼ばれるメカニズムが含まれており、アプリケーションがレポートサイズを制限できるようにします。
A thinning value, T, selects a subset of packets within the sequence number space: those with sequence numbers that are multiples of 2^T. Packet reception and loss reports apply only to those packets. T can vary between 0 and 15. If T is zero, then every packet in the sequence number space is reported upon. If T is fifteen, then one in every 32,768 packets is reported upon.
Thining値tは、シーケンス番号スペース内のパケットのサブセットを選択します。パケット受信と損失レポートは、これらのパケットにのみ適用されます。Tは0〜15の間で変化する可能性があります。Tがゼロの場合、シーケンス番号スペースのすべてのパケットが報告されます。tが15の場合、32,768個のパケットごとに1つが報告されます。
Suppose that the trace just described begins at sequence number 13,821. The last sequence number in the trace is 13,865. If the trace were to be thinned with a thinning value of T=2, then the following sequence numbers would be reported upon: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. The thinned trace would be as follows:
これまでに説明したトレースがシーケンス番号13,821で始まると仮定します。トレースの最後のシーケンス番号は13,865です。t = 2の薄ning値でトレースを薄くした場合、13,824、13,828、13,832、13,836、13,840、13,844、13,848、13,852、13,856、13,860、13,864に次のシーケンス数が報告されます。薄いトレースは次のとおりです。
1 1 1 1 1 0 1 1 1 1 0
1 1 1 1 1 0 1 1 1 1 0
This could be encoded as follows:
これは次のようにエンコードできます。
bit vector 1111 1011 1100 000 null chunk
ビットベクトル1111 1011 1100 000ヌルチャンク
The last four bits in the bit vector, representing sequence numbers 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are thus set to zero and are ignored by the receiver. With thinning, the loss of the 22nd packet goes unreported because its sequence number, 13,842, is not a multiple of four. Packet receipts for all sequence numbers that are not multiples of four also go unreported. However, in this example thinning has permitted the Loss RLE Report Block to be shortened by one 32 bit word.
ビットベクトルの最後の4ビットは、シーケンス番号13,868、13,872、13,876、および13,880を表し、トレースを超えて拡張されるため、受信機はゼロに設定して無視されます。薄くなると、22番目のパケットの損失は、そのシーケンス番号13,842が4つの倍数ではないため、報告されていません。4つの倍数ではないすべてのシーケンス番号のパケット領収書も報告されていません。ただし、この例では、薄化により、損失RLEレポートブロックが1つの32ビットワードで短縮されることができました。
Choice of the thinning value is left to the application.
薄くなる値の選択は、アプリケーションに残されています。
The Loss RLE Report Block has the following format:
損失rleレポートブロックには、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=1 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A Loss RLE Report Block is identified by the constant 1.
ブロックタイプ（BT）：8ビットA損失RLEレポートブロックは、定数1で識別されます。
rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
rsvd。：4ビットこのフィールドは、将来の定義のために予約されています。このような定義がない場合、このフィールドのビットはゼロに設定する必要があり、受信機は無視する必要があります。
thinning (T): 4 bits The amount of thinning performed on the sequence number space. Only those packets with sequence numbers 0 mod 2^T are reported on by this block. A value of 0 indicates that there is no thinning, and all packets are reported on. The maximum thinning is one packet in every 32,768 (amounting to two packets within each 16-bit sequence space).
薄化（T）：4ビットシーケンス番号スペースで実行される薄化量の量。シーケンス番号0 mod 2^tを持つパケットのみがこのブロックによって報告されます。0の値は、薄くなっていないことを示し、すべてのパケットが報告されています。最大薄化は、32,768ごとに1つのパケットです（16ビットシーケンススペースごとに2つのパケットに相当します）。
block length: 16 bits Defined in Section 3.
ブロック長：セクション3で定義された16ビット。
SSRC of source: 32 bits The SSRC of the RTP data packet source being reported upon by this report block.
ソースのSSRC：32ビットこのレポートブロックによって報告されているRTPデータパケットソースのSSRC。
begin_seq: 16 bits The first sequence number that this block reports on.
begin_seq：16ビットこのブロックが報告する最初のシーケンス番号。
end_seq: 16 bits The last sequence number that this block reports on plus one.
end_seq：16ビットこのブロックがプラス1に報告する最後のシーケンス番号。
chunk i: 16 bits There are three chunk types: run length, bit vector, and terminating null, defined in the following sections. If the chunk is all zeroes, then it is a terminating null chunk. Otherwise, the left most bit of the chunk determines its type: 0 for run length and 1 for bit vector.
チャンクI：16ビット次のセクションで定義されている、実行長、ビットベクトル、および終端nullの3つのチャンクタイプがあります。チャンクがすべてゼロである場合、それは終了したヌルチャンクです。それ以外の場合、チャンクの左のビットは、そのタイプを決定します：実行長は0、ビットベクトルは1です。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R| run length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit A zero identifies this as a run length chunk.
チャンクタイプ（c）：1ビットゼロは、これを実行長チャンクとして識別します。
run type (R): 1 bit Zero indicates a run of 0s. One indicates a run of 1s.
実行タイプ（r）：1ビットゼロは0秒の実行を示します。1つは1秒の実行を示します。
run length: 14 bits A value between 1 and 16,383. The value MUST not be zero for a run length chunk (zeroes in both the run type and run length fields would make the chunk a terminating null chunk). Run lengths of 15 or less MAY be described with a run length chunk despite the fact that they could also be described as part of a bit vector chunk.
実行長：1から16,383の間の14ビットの値。ランの長さチャンクの場合、値はゼロではありません（実行タイプと実行の長さフィールドの両方でゼロは、チャンクを終了したヌルチャンクにします）。走る長さは、走る長さのチャンクで記述される場合があります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| bit vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit A one identifies this as a bit vector chunk.
チャンクタイプ（c）：1ビット1は、これを少しベクトルチャンクとして識別します。
bit vector: 15 bits The vector is read from left to right, in order of increasing sequence number (with the appropriate allowance for wraparound).
ビットベクトル：15ビットベクトルは、シーケンス数を増やす順に左から右に読み取られます（ラップアラウンドに適した許容量を使用）。
This chunk is all zeroes.
このチャンクはすべてゼロです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This block type permits per-sequence-number reports on duplicates in a source's RTP packet stream. Such information can be used for network diagnosis, and provide an alternative to packet losses as a basis for multicast tree topology inference.
このブロックタイプは、ソースのRTPパケットストリームでの重複に関するシーケンス1回のレポートを許可します。このような情報は、ネットワーク診断に使用でき、マルチキャストツリートポロジー推論の基礎としてパケット損失の代替品を提供できます。
The Duplicate RLE Report Block format is identical to the Loss RLE Report Block format. Only the interpretation is different, in that the information concerns packet duplicates rather than packet losses. The trace to be encoded in this case also consists of zeros and ones, but a zero here indicates the presence of duplicate packets for a given sequence number, whereas a one indicates that no duplicates were received.
重複したRLEレポートブロック形式は、損失RLEレポートブロック形式と同一です。情報がパケットの損失ではなく、パケットが複製することに関係するという点で、解釈のみが異なります。この場合にエンコードされるトレースもゼロとそれで構成されていますが、ここでのゼロは、特定のシーケンス番号の重複パケットの存在を示しますが、1つは重複が受信されなかったことを示します。
The existence of a duplicate for a given sequence number is determined over the entire reporting period. For example, if packet number 12,593 arrives, followed by other packets with other sequence numbers, the arrival later in the reporting period of another packet numbered 12,593 counts as a duplicate for that sequence number. The duplicate does not need to follow immediately upon the first packet of that number. Care must be taken that a report does not cover a range of 65,534 or greater in the sequence number space.
特定のシーケンス番号の重複の存在は、レポート期間全体にわたって決定されます。たとえば、パケット番号12,593が到着し、その後の他のシーケンス番号が付いた他のパケットが続くと、別のパケットのレポート期間の到着は、そのシーケンス番号の重複として12,593カウントの番号が付けられました。複製は、その数の最初のパケットの後にすぐに従う必要はありません。レポートは、シーケンス番号スペースで65,534以上の範囲をカバーしないことに注意する必要があります。
No distinction is made between the existence of a single duplicate packet and multiple duplicate packets for a given sequence number. Note also that since there is no duplicate for a lost packet, a loss is encoded as a one in a Duplicate RLE Report Block.
特定のシーケンス番号の単一の複製パケットと複数の重複パケットの存在とは区別されません。また、紛失したパケットの重複がないため、損失は重複したRLEレポートブロックでエンコードされることに注意してください。
The Duplicate RLE Report Block has the following format:
重複したRLEレポートブロックには、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=2 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A Duplicate RLE Report Block is identified by the constant 2.
ブロックタイプ（BT）：8ビット重複するRLEレポートブロックは、定数2で識別されます。
rsvd.: 4 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
rsvd。：4ビットこのフィールドは、将来の定義のために予約されています。このような定義がない場合、このフィールドのビットはゼロに設定し、受信機によって無視する必要があります。
thinning (T): 4 bits As defined in Section 4.1.
薄化（T）：セクション4.1で定義されている4ビット。
block length: 16 bits Defined in Section 3.
ブロック長：セクション3で定義された16ビット。
SSRC of source: 32 bits As defined in Section 4.1.
ソースのSSRC：セクション4.1で定義されている32ビット。
begin_seq: 16 bits As defined in Section 4.1.
begin_seq：セクション4.1で定義されている16ビット。
end_seq: 16 bits As defined in Section 4.1.
end_seq：セクション4.1で定義されている16ビット。
chunk i: 16 bits As defined in Section 4.1.
チャンクI：セクション4.1で定義されている16ビット。
This block type permits per-sequence-number reports on packet receipt times for a given source's RTP packet stream. Such information can be used for MINC inference of the topology of the multicast tree used to distribute the source's RTP packets, and of the delays along the links within that tree. It can also be used to measure partial path characteristics and to model distributions for packet jitter.
このブロックタイプは、特定のソースのRTPパケットストリームのパケット受信時間に関するシーケンスごとのレポートを許可します。このような情報は、ソースのRTPパケットの配布に使用されるマルチキャストツリーのトポロジーと、そのツリー内のリンクに沿った遅延のMINC推論に使用できます。また、部分的なパス特性を測定し、パケットジッターの分布をモデル化するためにも使用できます。
Packet receipt times are expressed in the same units as in the RTP timestamps of data packets. This is so that, for each packet, one can establish both the send time and the receipt time in comparable terms. Note, however, that as an RTP sender ordinarily initializes its time to a value chosen at random, there can be no expectation that reported send and receipt times will differ by an amount equal to the one-way delay between sender and receiver. The reported times can nonetheless be useful for the purposes mentioned above.
パケット受領時間は、データパケットのRTPタイムスタンプと同じユニットで表されます。これは、各パケットについて、送信時間と領収書時間の両方を同等の条件で確立できるようにするためです。ただし、RTP送信者は通常、時間をランダムに選択した値に初期化するため、送信時間と領収書時間が送信者とレシーバーの間の一元配置遅延に等しい量によって異なるという期待はないことに注意してください。それにもかかわらず、報告された時間は、上記の目的に役立つ可能性があります。
At least one packet MUST have been received for each sequence number reported upon in this block. If this block type is used to report receipt times for a series of sequence numbers that includes lost packets, several blocks are required. If duplicate packets have been received for a given sequence number, and those packets differ in their receipt times, any time other than the earliest MUST NOT be reported. This is to ensure consistency among reports.
このブロックで報告されたシーケンス番号ごとに少なくとも1つのパケットを受信している必要があります。このブロックタイプを使用して、失われたパケットを含む一連のシーケンス番号の領収書時間を報告する場合、いくつかのブロックが必要です。特定のシーケンス番号に対して重複したパケットが受信され、それらのパケットが受領時間が異なる場合、最も早い以外の時間は報告してはなりません。これは、レポート間の一貫性を確保するためです。
Times reported in RTP timestamp format consume more bits than loss or duplicate information, and do not lend themselves to run length encoding. The use of thinning is encouraged to limit the size of Packet Receipt Times Report Blocks.
RTPタイムスタンプ形式で報告された時間は、損失または重複した情報よりも多くのビットを消費し、長さのエンコードを実行するのに役立ちません。薄化の使用は、パケットレシート時間レポートブロックのサイズを制限するために推奨されます。
The Packet Receipt Times Report Block has the following format:
パケットレシート時間レポートブロックには、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=3 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (begin_seq + 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (end_seq - 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A Packet Receipt Times Report Block is identified by the constant 3.
ブロックタイプ（BT）：8ビットパケットレシート時間レポートブロックは定数3で識別されます。
rsvd.: 4 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
rsvd。：4ビットこのフィールドは、将来の定義のために予約されています。このような定義がない場合、このフィールドのビットはゼロに設定し、受信機によって無視する必要があります。
thinning (T): 4 bits As defined in Section 4.1.
薄化（T）：セクション4.1で定義されている4ビット。
block length: 16 bits Defined in Section 3.
ブロック長：セクション3で定義された16ビット。
SSRC of source: 32 bits As defined in Section 4.1.
ソースのSSRC：セクション4.1で定義されている32ビット。
begin_seq: 16 bits As defined in Section 4.1.
begin_seq：セクション4.1で定義されている16ビット。
end_seq: 16 bits As defined in Section 4.1.
end_seq：セクション4.1で定義されている16ビット。
Packet i receipt time: 32 bits The receipt time of the packet with sequence number i at the receiver. The modular arithmetic shown in the packet format diagram is to allow for sequence number rollover. It is preferable for the time value to be established at the link layer interface, or in any case as close as possible to the wire arrival time. Units and format are the same as for the timestamp in RTP data packets. As opposed to RTP data packet timestamps, in which nominal values may be used instead of system clock values in order to convey information useful for periodic playout, the receipt times should reflect the actual time as closely as possible. For a session, if the RTP timestamp is chosen at random, the first receipt time value SHOULD also be chosen at random, and subsequent timestamps offset from this value. On the other hand, if the RTP timestamp is meant to reflect the reference time at the sender, then the receipt time SHOULD be as close as possible to the reference time at the receiver.
パケットI領収書時間：32ビットパケットの領収書時間をレシーバーでシーケンス番号Iでビットします。パケット形式の図に示されているモジュラー算術は、シーケンス番号ロールオーバーを可能にするためです。リンクレイヤーインターフェイスで時間値を確立するか、いずれにせよ、ワイヤの到着時間にできるだけ近い場合が望ましい。ユニットとフォーマットは、RTPデータパケットのタイムスタンプと同じです。定期的なプレイアウトに役立つ情報を伝えるためにシステムクロック値の代わりに公称値を使用できるRTPデータパケットタイムスタンプとは対照的に、領収書時間は実際の時間を可能な限り密接に反映する必要があります。セッションの場合、RTPタイムスタンプがランダムに選択されている場合、最初の領収書時間値もランダムに選択し、その後のタイムスタンプはこの値から相殺する必要があります。一方、RTPタイムスタンプが送信者の参照時間を反映することを意図している場合、受領時間はレシーバーの参照時間にできるだけ近くになるはずです。
This block extends RTCP's timestamp reporting so that non-senders may also send timestamps. It recapitulates the NTP timestamp fields from the RTCP Sender Report [9, Sec. 6.3.1]. A non-sender may estimate its round trip time (RTT) to other participants, as proposed in [18], by sending this report block and receiving DLRR Report Blocks (see next section) in reply.
このブロックは、RTCPのタイムスタンプの報告を拡張して、非センダーもタイムスタンプを送信できるようにします。RTCP Senderレポート[9、Sec。6.3.1]。非センダーは、[18]で提案されているように、このレポートブロックを送信し、DLRRレポートブロック（次のセクションを参照）を受け取ることにより、その往復時間（RTT）を他の参加者に推定することができます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=4 | reserved | block length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A Receiver Reference Time Report Block is identified by the constant 4.
ブロックタイプ（BT）：8ビットAレシーバー参照時間レポートブロックは、定数4で識別されます。
reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
予約済み：8ビットこのフィールドは、将来の定義のために予約されています。このような定義がない場合、このフィールドのビットはゼロに設定する必要があり、受信機は無視する必要があります。
block length: 16 bits The constant 2, in accordance with the definition of this field in Section 3.
ブロックの長さ：セクション3のこのフィールドの定義に従って、16ビット定数2をビットします。
NTP timestamp: 64 bits Indicates the wallclock time when this block was sent so that it may be used in combination with timestamps returned in DLRR Report Blocks (see next section) from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the timestamp may be limited to far less than the resolution of the NTP timestamp. The measurement uncertainty of the timestamp is not indicated as it may not be known. A report block sender that can keep track of elapsed time but has no notion of wallclock time may use the elapsed time since joining the session instead. This is assumed to be less than 68 years, so the high bit will be zero. It is permissible to use the sampling clock to estimate elapsed wallclock time. A report sender that has no notion of wallclock or elapsed time may set the NTP timestamp to zero.
NTPタイムスタンプ：64ビットは、このブロックが送信されたときに壁掛け時間を示し、DLRRレポートブロックで返されたタイムスタンプと組み合わせて使用できるようにします（次のセクションを参照）。受信機は、タイムスタンプの測定精度がNTPタイムスタンプの解像度よりもはるかに少ないことに制限される可能性があることを期待する必要があります。タイムスタンプの測定の不確実性は、知られていない可能性があるため、示されていません。経過時間を追跡できるレポートブロック送信者は、代わりにセッションに参加してから経過時間を使用する場合があります。これは68年未満であると想定されるため、高ビットはゼロになります。サンプリングクロックを使用して、経過した壁掛け時間を推定することは許可されています。Wallclockまたは経過時間の概念を持たないレポート送信者は、NTPタイムスタンプをゼロに設定する場合があります。
This block extends RTCP's delay since the last Sender Report (DLSR) mechanism [9, Sec. 6.3.1] so that non-senders may also calculate round trip times, as proposed in [18]. It is termed DLRR for delay since the last Receiver Report, and may be sent in response to a Receiver Timestamp Report Block (see previous section) from a receiver to allow that receiver to calculate its round trip time to the respondent. The report consists of one or more 3 word sub-blocks: one sub-block per Receiver Report.
このブロックは、最後の送信者レポート（DLSR）メカニズム[9、Sec。以降のRTCPの遅延を延長します。6.3.1]そうでないため、[18]で提案されているように、非センダーも往復時間を計算することができます。最後のレシーバーレポート以降、DLRRと呼ばれ、受信機から受信機のレポートブロック（前のセクションを参照）に応答して送信され、受信者が回答者への往復時間を計算できるようにします。レポートは、1つ以上の3ワードサブブロックで構成されています。レシーバーレポートごとに1つのサブブロック。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=5 | reserved | block length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last RR (DLRR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
block type (BT): 8 bits A DLRR Report Block is identified by the constant 5.
ブロックタイプ（BT）：8ビットDLRRレポートブロックは定数5で識別されます。
reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
予約済み：8ビットこのフィールドは、将来の定義のために予約されています。このような定義がない場合、このフィールドのビットはゼロに設定する必要があり、受信機は無視する必要があります。
block length: 16 bits Defined in Section 3.
ブロック長：セクション3で定義された16ビット。
last RR timestamp (LRR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in the previous section), received as part of a Receiver Reference Time Report Block from participant SSRC_n. If no such block has been received, the field is set to zero.
最後のRRタイムスタンプ（LRR）：32ビットNTPタイムスタンプの64のうち32ビット（前のセクションで説明したように）は、参加者SSRC_Nからのレシーバー参照時間レポートブロックの一部として受信しました。そのようなブロックが受信されていない場合、フィールドはゼロに設定されます。
delay since last RR (DLRR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last Receiver Reference Time Report Block from participant SSRC_n and sending this DLRR Report Block. If a Receiver Reference Time Report Block has yet to be received from SSRC_n, the DLRR field is set to zero (or the DLRR is omitted entirely). Let SSRC_r denote the receiver issuing this DLRR Report Block. Participant SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this Receiver Timestamp Report Block is received. It calculates the total round-trip time A-LRR using the last RR timestamp (LRR) field, and then subtracting this field to leave the round-trip propagation delay as A-LRR-DLRR. This is illustrated in [9, Fig. 2].
最後のRR（DLRR）以降の遅延：32ビット1/65536秒のユニットで表され、参加者SSRC_Nから最後の受信者参照時間レポートブロックを受信し、このDLRRレポートブロックの送信の間に発現します。受信者参照時間レポートブロックがSSRC_Nからまだ受信されていない場合、DLRRフィールドはゼロに設定されています（またはDLRRは完全に省略されています）。SSRC_RがこのDLRRレポートブロックを発行する受信者を示しさせます。参加者のSSRC_Nは、このレシーバータイムスタンプレポートブロックを受信した時間を記録することにより、往復伝播遅延をSSRC_Rに計算できます。最後のRRタイムスタンプ（LRR）フィールドを使用して総往復時間A-LRRを計算し、このフィールドを減算して、往復伝播遅延をA-LRR-DLRRとして残します。これは[9、図2]に示されています。
This block reports statistics beyond the information carried in the standard RTCP packet format, but is not as finely grained as that carried in the report blocks previously described. Information is recorded about lost packets, duplicate packets, jitter measurements, and TTL or Hop Limit values. Such information can be useful for network management.
このブロックは、標準のRTCPパケット形式で伝えられる情報を超えた統計を報告しますが、前述のレポートブロックで運ばれたものほど細かく粒子ではありません。情報は、失われたパケット、重複パケット、ジッター測定、TTLまたはホップ制限値に関する記録されています。このような情報は、ネットワーク管理に役立ちます。
The report block contents are dependent upon a series of flag bits carried in the first part of the header. Not all parameters need to be reported in each block. Flags indicate which are and which are not reported. The fields corresponding to unreported parameters MUST be present, but are set to zero. The receiver MUST ignore any Statistics Summary Report Block with a non-zero value in any field flagged as unreported.
レポートブロックの内容は、ヘッダーの最初の部分で運ばれる一連のフラグビットに依存します。すべてのパラメーターを各ブロックで報告する必要はありません。フラグは、どちらが報告されていないかを示します。報告されていないパラメーターに対応するフィールドは存在する必要がありますが、ゼロに設定されています。受信者は、報告されていないとフラグが付けられた任意のフィールドにゼロ以外の値を持つ統計概要レポートブロックを無視する必要があります。
The Statistics Summary Report Block has the following format:
統計概要レポートブロックには、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=6 |L|D|J|ToH|rsvd.| block length = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mean_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dev_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A Statistics Summary Report Block is identified by the constant 6.
ブロックタイプ（BT）：8ビット統計概要レポートブロックは、定数6によって識別されます。
loss report flag (L): 1 bit Bit set to 1 if the lost_packets field contains a report, 0 otherwise.
損失レポートフラグ（l）：1ビット設定1に設定されていますlost_packetsフィールドにレポートが含まれている場合、0それ以外の場合。
duplicate report flag (D): 1 bit Bit set to 1 if the dup_packets field contains a report, 0 otherwise.
DUP_Packetsフィールドにレポートが含まれている場合、レポートフラグ（d）：1ビット設定1に設定されています。
jitter flag (J): 1 bit Bit set to 1 if the min_jitter, max_jitter, mean_jitter, and dev_jitter fields all contain reports, 0 if none of them do.
Jitterフラグ（j）：1ビット設定Min_jitter、max_jitter、mean_jitter、およびdev_jitterフィールドにはすべてレポートが含まれている場合、0がない場合は0。
TTL or Hop Limit flag (ToH): 2 bits This field is set to 0 if none of the fields min_ttl_or_hl, max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain reports. If the field is non-zero, then all of these fields contain reports. The value 1 signifies that they report on IPv4 TTL values. The value 2 signifies that they report on IPv6 Hop Limit values. The value 3 is undefined and MUST NOT be used.
TTLまたはホップリミットフラグ（TOH）：2ビットこのフィールドは、フィールドmin_ttl_or_hl、max_ttl_or_hl、mean_ttl_or_hl、またはdev_ttl_or_or_hlがレポートを含む場合、0に設定されています。フィールドがゼロ以外の場合、これらのすべてのフィールドにはレポートが含まれています。値1は、IPv4 TTL値について報告することを意味します。値2は、IPv6ホップ制限値について報告することを意味します。値3は未定義であり、使用してはなりません。
rsvd.: 3 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
rsvd。：3ビットこのフィールドは、将来の定義のために予約されています。このような定義がない場合、このフィールドのビットはゼロに設定し、受信機によって無視する必要があります。
block length: 16 bits The constant 9, in accordance with the definition of this field in Section 3.
ブロックの長さ：セクション3のこのフィールドの定義に従って、16ビット定数9をビットします。
SSRC of source: 32 bits As defined in Section 4.1.
ソースのSSRC：セクション4.1で定義されている32ビット。
begin_seq: 16 bits As defined in Section 4.1.
begin_seq：セクション4.1で定義されている16ビット。
end_seq: 16 bits As defined in Section 4.1.
end_seq：セクション4.1で定義されている16ビット。
lost_packets: 32 bits Number of lost packets in the above sequence number interval.
lost_packets：上記のシーケンス番号間隔で32ビットの紛失パケット。
dup_packets: 32 bits Number of duplicate packets in the above sequence number interval.
dup_packets：上記のシーケンス番号間隔で32ビットの重複パケット。
min_jitter: 32 bits The minimum relative transit time between two packets in the above sequence number interval. All jitter values are measured as the difference between a packet's RTP timestamp and the reporter's clock at the time of arrival, measured in the same units.
min_jitter：32ビット上記のシーケンス番号間隔の2つのパケット間の最小相対輸送時間。すべてのジッター値は、同じユニットで測定された到着時のパケットのRTPタイムスタンプと到着時のレポーターの時計の違いとして測定されます。
max_jitter: 32 bits The maximum relative transit time between two packets in the above sequence number interval.
MAX_JITTER：32ビット上記のシーケンス番号間隔の2つのパケット間の最大相対輸送時間。
mean_jitter: 32 bits The mean relative transit time between each two packet series in the above sequence number interval, rounded to the nearest value expressible as an RTP timestamp.
MEAN_JITTER：32ビット上記のシーケンス番号間隔の2つのパケットシリーズごとの平均相対交通時間をビットし、RTPタイムスタンプとして表現できる最も近い値に丸められます。
dev_jitter: 32 bits The standard deviation of the relative transit time between each two packet series in the above sequence number interval.
dev_jitter：32ビット上記のシーケンス番号間隔で、それぞれ2つのパケットシリーズ間の相対輸送時間の標準偏差。
min_ttl_or_hl: 8 bits The minimum TTL or Hop Limit value of data packets in the sequence number range.
min_ttl_or_hl：8シーケンス番号範囲のデータパケットの最小TTLまたはホップ制限値の値を8ビットします。
max_ttl_or_hl: 8 bits The maximum TTL or Hop Limit value of data packets in the sequence number range.
MAX_TTL_OR_HL：8シーケンス番号範囲のデータパケットの最大TTLまたはホップ制限値の値を8ビットします。
mean_ttl_or_hl: 8 bits The mean TTL or Hop Limit value of data packets in the sequence number range, rounded to the nearest integer.
Mean_ttl_or_hl：8は、最寄りの整数に丸められたシーケンス番号範囲のデータパケットの平均TTLまたはホップ制限値をビットします。
dev_ttl_or_hl: 8 bits The standard deviation of TTL or Hop Limit values of data packets in the sequence number range.
dev_ttl_or_hl：8シーケンス番号範囲のTTLまたはホップ制限データパケットの標準偏差を8ビットします。
The VoIP Metrics Report Block provides metrics for monitoring voice over IP (VoIP) calls. These metrics include packet loss and discard metrics, delay metrics, analog metrics, and voice quality metrics. The block reports separately on packets lost on the IP channel, and those that have been received but then discarded by the receiving jitter buffer. It also reports on the combined effect of losses and discards, as both have equal effect on call quality.
VoIP Metricsレポートブロックは、IP（VOIP）呼び出しを監視するためのメトリックを提供します。これらのメトリックには、パケットの損失と破棄メトリック、遅延メトリック、アナログメトリック、音声品質メトリックが含まれます。ブロックは、IPチャンネルで失われたパケットと、受信したが受信ジッターバッファーによって破棄されたパケットに個別に報告されます。また、両方ともコールの品質に平等な影響を与えるため、損失と廃棄の組み合わせ効果についても報告しています。
In order to properly assess the quality of a Voice over IP call, it is desirable to consider the degree of burstiness of packet loss [14]. Following a Gilbert-Elliott model [3], a period of time, bounded by lost and/or discarded packets with a high rate of losses and/or discards, is a "burst", and a period of time between two bursts is a "gap". Bursts correspond to periods of time during which the packet loss rate is high enough to produce noticeable degradation in audio quality. Gaps correspond to periods of time during which only isolated lost packets may occur, and in general these can be masked by packet loss concealment. Delay reports include the transit delay between RTP end points and the VoIP end system processing delays, both of which contribute to the user perceived delay. Additional metrics include signal, echo, noise, and distortion levels. Call quality metrics include R factors (as described by the E Model defined in [6,3]) and mean opinion scores (MOS scores).
IP通話を超える音声の品質を適切に評価するためには、パケット損失の乱れの程度を考慮することが望ましい[14]。ギルバート・エリオットモデル[3]に続いて、損失や廃棄の高い紛失および/または廃棄されたパケットに制限された期間は「バースト」であり、2つのバーストの間の期間は"ギャップ"。バーストは、パケットの損失率がオーディオ品質に顕著な分解を生成するのに十分な期間に対応します。ギャップは、分離された失われたパケットのみが発生する可能性がある期間に対応し、一般にこれらはパケット損失の隠蔽によってマスクされる可能性があります。遅延レポートには、RTPエンドポイントとVoIPエンドシステムの処理遅延間のトランジット遅延が含まれます。どちらもユーザーの知覚遅延に寄与します。追加のメトリックには、信号、エコー、ノイズ、歪みレベルが含まれます。コールの品質メトリックには、R因子（[6,3]で定義されているEモデルで説明されている）および平均意見スコア（MOSスコア）が含まれます。
Implementations MUST provide values for all the fields defined here. For certain metrics, if the value is undefined or unknown, then the specified default or unknown field value MUST be provided.
実装は、ここで定義されているすべてのフィールドに値を提供する必要があります。特定のメトリックの場合、値が未定義または不明の場合、指定されたデフォルトまたは不明のフィールド値を提供する必要があります。
The block is encoded as seven 32-bit words:
ブロックは、7つの32ビット単語としてエンコードされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=7 | reserved | block length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss rate | discard rate | burst density | gap density |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burst duration | gap duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| round trip delay | end system delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signal level | noise level | RERL | Gmin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R factor | ext. R factor | MOS-LQ | MOS-CQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RX config | reserved | JB nominal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JB maximum | JB abs max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits A VoIP Metrics Report Block is identified by the constant 7.
ブロックタイプ（BT）：8ビットVoIPメトリックレポートブロックは、定数7で識別されます。
reserved: 8 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
予約済み：8ビットこのフィールドは、将来の定義のために予約されています。このような定義がない場合、このフィールドのビットはゼロに設定し、受信機によって無視する必要があります。
block length: 16 bits The constant 8, in accordance with the definition of this field in Section 3.
ブロック長：セクション3のこのフィールドの定義に従って、16ビット定数8。
SSRC of source: 32 bits As defined in Section 4.1.
ソースのSSRC：セクション4.1で定義されている32ビット。
The remaining fields are described in the following six sections: Packet Loss and Discard Metrics, Delay Metrics, Signal Related Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, and Jitter Buffer Parameters.
残りのフィールドについては、次の6つのセクションで説明します。パケット損失と破棄メトリック、遅延メトリック、信号関連メトリック、通話品質または伝送品質メトリック、構成メトリック、およびジッターバッファーパラメーター。
It is very useful to distinguish between packets lost by the network and those discarded due to jitter. Both have equal effect on the quality of the voice stream, however, having separate counts helps identify the source of quality degradation. These fields MUST be populated, and MUST be set to zero if no packets have been received.
ネットワークによって失われたパケットとジッターのために廃棄されたパケットを区別することは非常に便利です。どちらも音声ストリームの品質に平等な影響を及ぼしますが、個別のカウントを持つことは、品質の劣化の原因を特定するのに役立ちます。これらのフィールドに入力する必要があり、パケットが受信されていない場合はゼロに設定する必要があります。
loss rate: 8 bits The fraction of RTP data packets from the source lost since the beginning of reception, expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing the total number of packets lost (after the effects of applying any error protection such as FEC) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. The numbers of duplicated packets and discarded packets do not enter into this calculation. Since receivers cannot be required to maintain unlimited buffers, a receiver MAY categorize late-arriving packets as lost. The degree of lateness that triggers a loss SHOULD be significantly greater than that which triggers a discard.
損失率：8ビット受信の開始以来失われたソースからのRTPデータパケットの割合は、フィールドの左端にバイナリポイントを持つ固定点数として表現されました。この値は、失われたパケットの総数を（FECなどのエラー保護を適用する後）予想パケットの総数を割ることによって計算され、部門の結果に256を掛け、最大値を255に制限します（オーバーフローを避けます）、および整数部分を取得します。重複したパケットと破棄されたパケットの数は、この計算に入力されません。無制限のバッファーを維持するためにレシーバーを必要とすることはできないため、受信者は遅れて到着するパケットを失われたものとして分類する場合があります。損失を引き起こす遅刻の程度は、廃棄を引き起こすものよりも大幅に大きくなければなりません。
discard rate: 8 bits The fraction of RTP data packets from the source that have been discarded since the beginning of reception, due to late or early arrival, under-run or overflow at the receiving jitter buffer. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets discarded (excluding duplicate packet discards) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part.
廃棄率：8ビットRTPデータパケットの割合は、受信中または早期の到着、受信ジッターバッファでの過程、またはオーバーフローのために、受信の開始以来廃棄されたソースからのビットです。この値は、フィールドの左端にあるバイナリポイントを持つ固定点数として表されます。廃棄されたパケットの総数（重複したパケット廃棄物を除く）を予想されるパケットの総数を割ることで計算され、部門の結果に256を掛け、最大値を255に制限し（オーバーフローを避けるため）、整数を採取します。一部。
A burst is a period during which a high proportion of packets are either lost or discarded due to late arrival. A burst is defined, in terms of a value Gmin, as the longest sequence that (a) starts with a lost or discarded packet, (b) does not contain any occurrences of Gmin or more consecutively received (and not discarded) packets, and (c) ends with a lost or discarded packet.
バーストとは、到着が遅れているためにパケットの割合が高いか廃棄される期間です。値GMINの観点から、（a）紛失または廃棄されたパケットで始まる最長のシーケンスとして、（b）GMINまたはより連続して受け取った（廃棄されていない）パケットの発生を含まない、バーストが定義されます。（c）紛失または破棄されたパケットで終了します。
A gap, informally, is a period of low packet losses and/or discards. Formally, a gap is defined as any of the following: (a) the period from the start of an RTP session to the receipt time of the last received packet before the first burst, (b) the period from the end of the last burst to either the time of the report or the end of the RTP session, whichever comes first, or (c) the period of time between two bursts.
非公式には、ギャップは、パケット損失や廃棄の低さです。正式には、ギャップは次のいずれかとして定義されます。（a）RTPセッションの開始から最初のバーストの前の最後の受信パケットの受領時間までの期間、（b）最後のバーストの終わりからの期間レポートの時間またはRTPセッションの終了のいずれか、どちらか最初の方、または（c）2つのバースト間の期間。
For the purpose of determining if a lost or discarded packet near the start or end of an RTP session is within a gap or a burst, it is assumed that the RTP session is preceded and followed by at least Gmin received packets, and that the time of the report is followed by at least Gmin received packets.
RTPセッションの開始または終了の近くで紛失または廃棄されたパケットがギャップまたはバースト内にあるかどうかを判断する目的で、RTPセッションの前に、少なくともGMINが受信したパケットが続くと想定されています。レポートの後に、少なくともGMIN受信パケットが続きます。
A gap has the property that any lost or discarded packets within the gap must be preceded and followed by at least Gmin packets that were received and not discarded. This gives a maximum loss/discard rate within a gap of: 1 / (Gmin + 1).
ギャップには、ギャップ内の紛失または廃棄されたパケットの前に行われ、少なくとも廃棄されていないGMINパケットが少なくともGMINパケットが必要であるという特性があります。これにより、1 /（GMIN 1）のギャップ内で最大の損失 /廃棄率が得られます。
A Gmin value of 16 is RECOMMENDED, as it results in gap characteristics that correspond to good quality (i.e., low packet loss rate, a minimum distance of 16 received packets between lost packets), and hence differentiates nicely between good and poor quality periods.
GMIN値は、良質（つまり、低パケット損失率、失われたパケット間の16の受信パケットの最小距離）に対応するギャップ特性をもたらすため、16のGMIN値を推奨します。
For example, a 1 denotes a received packet, 0 a lost packet, and X a discarded packet in the following pattern covering 64 packets:
たとえば、A 1は受信したパケット、0が失われたパケット、x 64パケットをカバーする次のパターンで廃棄されたパケットを示します。
11110111111111111111111X111X1011110111111111111111111X111111111
|---------gap----------|--burst---|------------gap------------|
The burst consists of the twelve packets indicated above, starting at a discarded packet and ending at a lost packet. The first gap starts at the beginning of the session and the second gap ends at the time of the report.
バーストは、廃棄されたパケットから始まり、紛失したパケットで終わる上記の12のパケットで構成されています。最初のギャップはセッションの開始時に始まり、2番目のギャップはレポートの時点で終了します。
If the packet spacing is 10 ms and the Gmin value is the recommended value of 16, the burst duration is 120 ms, the burst density 0.33, the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.
パケット間隔が10ミリ秒で、GMIN値が16の推奨値である場合、バースト期間は120ミリ秒、バースト密度0.33、ギャップ期間230 ms 290 ms = 520 ms、ギャップ密度0.04です。
This would result in reported values as follows (see field descriptions for semantics and details on how these are calculated):
これにより、報告された値が次のようになります（セマンティクスのフィールドの説明と、これらの計算方法に関する詳細を参照）：
loss rate 12, which corresponds to 5%
discard rate 12, which corresponds to 5%
burst density 84, which corresponds to 33%
gap density 10, which corresponds to 4%
burst duration 120, value in milliseconds
gap duration 520, value in milliseconds
burst density: 8 bits The fraction of RTP data packets within burst periods since the beginning of reception that were either lost or discarded. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within burst periods by the total number of packets expected within the burst periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. This field MUST be populated and MUST be set to zero if no packets have been received.
バースト密度：8ビットは、紛失または廃棄された受信の開始以来、バースト期間内にRTPデータパケットの割合をビットします。この値は、フィールドの左端にあるバイナリポイントを持つ固定点数として表されます。これは、失われたパケットの総数をバースト期間内にバースト期間内に破棄または破棄したパケットの総数を割ることによって計算されます。バースト期間内に予想されるパケットの総数を除算し、部門の結果に256を掛け、最大値を255に制限します（オーバーフローを避けるため）、および整数部分を取得します。このフィールドに入力する必要があり、パケットが受信されていない場合はゼロに設定する必要があります。
gap density: 8 bits The fraction of RTP data packets within inter-burst gaps since the beginning of reception that were either lost or discarded. The value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within gap periods by the total number of packets expected within the gap periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. This field MUST be populated and MUST be set to zero if no packets have been received.
ギャップ密度：8ビットは、レセプションの開始以来、失われたか破棄されたレセプションの開始以来、バースト間ギャップ内のRTPデータパケットの割合にビットします。値は、フィールドの左端にあるバイナリポイントを持つ固定点数として表されます。これは、ギャップ期間内に失われたり破棄または破棄されたり（重複したパケット廃棄を除く）パケットの総数をギャップ期間内に予想されるパケットの総数を割ることによって計算され、部門の結果に256を掛け、最大値を255に制限します（オーバーフローを避けるため）、および整数部分を取得します。このフィールドに入力する必要があり、パケットが受信されていない場合はゼロに設定する必要があります。
burst duration: 16 bits The mean duration, expressed in milliseconds, of the burst periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packets that mark the beginning and end of that period. It is equal to the timestamp of the end packet, plus the duration of the end packet, minus the timestamp of the beginning packet. If the actual values are not available, estimated values MUST be used. If there have been no burst periods, the burst duration value MUST be zero.
バースト期間：レセプションの開始以来発生したバースト期間の16ビット平均期間、ミリ秒で表されます。各期間の期間は、その期間の開始と終了をマークするパケットに基づいて計算されます。これは、エンドパケットのタイムスタンプに加えて、エンドパケットの持続時間に等しく、開始パケットのタイムスタンプを差し引いています。実際の値が利用できない場合、推定値を使用する必要があります。バースト期間がなかった場合、バースト期間値はゼロでなければなりません。
gap duration: 16 bits The mean duration, expressed in milliseconds, of the gap periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packet that marks the end of the prior burst and the packet that marks the beginning of the subsequent burst. It is equal to the timestamp of the subsequent burst packet, minus the timestamp of the prior burst packet, plus the duration of the prior burst packet. If the actual values are not available, estimated values MUST be used. In the case of a gap that occurs at the beginning of reception, the sum of the timestamp of the prior burst packet and the duration of the prior burst packet are replaced by the reception start time. In the case of a gap that occurs at the end of reception, the timestamp of the subsequent burst packet is replaced by the reception end time. If there have been no gap periods, the gap duration value MUST be zero.
ギャップ期間：16ビットは、受信の開始以来発生したギャップ期間のミリ秒で表される平均持続時間を16ビットします。各期間の持続時間は、以前のバーストの終了をマークするパケットと、後続のバーストの始まりをマークするパケットに基づいて計算されます。これは、以前のバーストパケットのタイムスタンプを差し引いた後続のバーストパケットのタイムスタンプと、以前のバーストパケットの期間に等しくなります。実際の値が利用できない場合、推定値を使用する必要があります。受信の開始時に発生するギャップの場合、以前のバーストパケットのタイムスタンプの合計と以前のバーストパケットの期間は、受信開始時間に置き換えられます。受信の終わりに発生するギャップの場合、後続のバーストパケットのタイムスタンプは受信の終了時間に置き換えられます。ギャップ期間がなかった場合、ギャップ期間値はゼロでなければなりません。
For the purpose of the following definitions, the RTP interface is the interface between the RTP instance and the voice application (i.e., FEC, de-interleaving, de-multiplexing, jitter buffer). For example, the time delay due to RTP payload multiplexing would be considered part of the voice application or end-system delay, whereas delay due to multiplexing RTP frames within a UDP frame would be considered part of the RTP reported delay. This distinction is consistent with the use of RTCP for delay measurements.
次の定義の目的のために、RTPインターフェイスは、RTPインスタンスと音声アプリケーションの間のインターフェイスです（つまり、FEC、interLeaving、脱倍プレックス、ジッターバッファー）。たとえば、RTPペイロード多重化による時間遅延は、音声アプリケーションまたはエンドシステムの遅延の一部と見なされますが、UDPフレーム内の多重化RTPフレームによる遅延は、RTP報告遅延の一部と見なされます。この区別は、遅延測定にRTCPを使用することと一致しています。
round trip delay: 16 bits The most recently calculated round trip time between RTP interfaces, expressed in milliseconds. This value MAY be measured using RTCP, the DLRR method defined in Section 4.5 of this document, where it is necessary to convert the units of measurement from NTP timestamp values to milliseconds, or other approaches. If RTCP is used, then the reported delay value is the time of receipt of the most recent RTCP packet from source SSRC, minus the LSR (last SR) time reported in its SR (Sender Report), minus the DLSR (delay since last SR) reported in its SR. A non-zero LSR value is required in order to calculate round trip delay. A value of 0 is permissible; however, this field MUST be populated as soon as a delay estimate is available.
往復遅延：16ビットRTPインターフェイス間の最近計算された往復時間をミリ秒で表します。この値は、このドキュメントのセクション4.5で定義されているDLRRメソッドであるRTCPを使用して測定できます。ここでは、測定単位をNTPタイムスタンプ値からミリ秒またはその他のアプローチに変換する必要があります。RTCPを使用する場合、報告された遅延値は、SSRCからの最新のRTCPパケットの受領時間であり、SR（送信者レポート）で報告されたLSR（最後のSR）を差し引いて、DLSRを差し引いた（最後のSR以降の遅延））そのSRで報告されています。往復遅延を計算するには、ゼロ以外のLSR値が必要です。0の値は許容されます。ただし、遅延の見積もりが利用可能になるとすぐに、このフィールドに入力する必要があります。
end system delay: 16 bits The most recently estimated end system delay, expressed in milliseconds. End system delay is defined as the sum of the total sample accumulation and encoding delay associated with the sending direction and the jitter buffer, decoding, and playout buffer delay associated with the receiving direction. This delay MAY be estimated or measured. This value SHOULD be provided in all VoIP metrics reports. If an implementation is unable to provide the data, the value 0 MUST be used.
エンドシステムの遅延：16ビットミリ秒で表された、最近推定された最近の推定エンドシステム遅延を16ビットします。終了システムの遅延は、送信方向に関連する総サンプルの蓄積とエンコード遅延の合計と、受信方向に関連付けられたジッターバッファー、デコード、およびプレイアウトバッファー遅延の合計として定義されます。この遅延は、推定または測定される場合があります。この値は、すべてのVoIPメトリックレポートで提供される必要があります。実装がデータを提供できない場合、値0を使用する必要があります。
Note that the one way symmetric VoIP segment delay may be calculated from the round trip and end system delays is as follows; if the round trip delay is denoted, RTD and the end system delays associated with the two endpoints are ESD(A) and ESD(B) then:
往復および終了システムの遅延から、対称VoIPセグメントの1つの方法が計算される可能性があることに注意してください。往復遅延が示されている場合、RTDと2つのエンドポイントに関連付けられた最終システムの遅延はESD（a）とESD（b）です。
one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2
The following metrics are intended to provide real time information related to the non-packet elements of the voice over IP system to assist with the identification of problems affecting call quality. The values identified below must be determined for the received audio signal. The information required to populate these fields may not be available in all systems, although it is strongly recommended that this data SHOULD be provided to support problem diagnosis.
次のメトリックは、音声上のIPシステムの非パケット要素に関連するリアルタイム情報を提供することを目的としており、コールの品質に影響する問題の識別を支援します。以下に識別される値は、受信したオーディオ信号に対して決定する必要があります。これらのフィールドに入力するために必要な情報は、すべてのシステムで利用できない場合がありますが、問題の診断をサポートするためにこのデータを提供することを強くお勧めします。
signal level: 8 bits The voice signal relative level is defined as the ratio of the signal level to a 0 dBm0 reference [10], expressed in decibels as a signed integer in two's complement form. This is measured only for packets containing speech energy. The intent of this metric is not to provide a precise measurement of the signal level but to provide a real time indication that the signal level may be excessively high or low.
信号レベル：8ビット音声信号相対レベルは、信号レベルの0 dBM0参照[10]との比率として定義され、デシベルで2つの補数形式で署名された整数として表されます。これは、音声エネルギーを含むパケットに対してのみ測定されます。このメトリックの意図は、信号レベルの正確な測定を提供することではなく、信号レベルが過度に高または低い場合があることをリアルタイムの兆候を提供することです。
signal level = 10 Log10 ( rms talkspurt power (mW) )
信号レベル= 10 log10（rms talkspurt power（MW））
A value of 127 indicates that this parameter is unavailable. Typical values should generally be in the -15 to -20 dBm range.
127の値は、このパラメーターが利用できないことを示します。一般に、典型的な値は-15〜 -20 dBmの範囲にある必要があります。
noise level: 8 bits The noise level is defined as the ratio of the silent period background noise level to a 0 dBm0 reference, expressed in decibels as a signed integer in two's complement form.
ノイズレベル：8ビットノイズレベルは、サイレントピリオドバックグラウンドノイズレベルの0 dBM0参照の比として定義され、2つの補数形式の署名された整数としてデシベルで表されます。
noise level = 10 Log10 ( rms silence power (mW) )
ノイズレベル= 10 log10（rms silent power（mw））
A value of 127 indicates that this parameter is unavailable.
127の値は、このパラメーターが利用できないことを示します。
residual echo return loss (RERL): 8 bits The residual echo return loss value may be measured directly by the VoIP end system's echo canceller or may be estimated by adding the echo return loss (ERL) and echo return loss enhancement (ERLE) values reported by the echo canceller.
残留エコーリターンロス（RERL）：8ビット残差エコーリターン損失値は、VoIP End Systemのエコーキャンセラーによって直接測定される場合があります。エコーキャンセラーによって。
RERL(dB) = ERL (dB) + ERLE (dB) In the case of a VoIP gateway, the source of echo is typically line echo that occurs at 2-4 wire conversion points in the network. This can be in the 8-12 dB range. A line echo canceler can provide an ERLE of 30 dB or more and hence reduce this to 40-50 dB. In the case of an IP phone, this could be acoustic coupling between handset speaker and microphone or residual acoustic echo from speakerphone operation, and may more correctly be termed terminal coupling loss (TCL). A typical handset would result in 40-50 dB of echo loss due to acoustic feedback.
RERL（DB）= ERL（DB）ERLE（DB）VoIPゲートウェイの場合、エコーのソースは通常、ネットワーク内の2〜4ワイヤ変換ポイントで発生するラインエコーです。これは、8〜12 dBの範囲にあります。ラインエコーキャンセラーは、30 dB以上のERLEを提供するため、これを40〜50 dBに減らします。IP電話の場合、これは携帯電話スピーカーとマイクの間の音響結合、またはスピーカーフォン操作からの残留音響エコーである可能性があり、より正確に末端結合損失（TCL）と呼ばれる可能性があります。典型的な携帯電話は、音響フィードバックのために40〜50 dBのエコー損失をもたらします。
Examples:
例：
- IP gateway connected to circuit switched network with 2 wire loop. Without echo cancellation, typical 2-4 wire converter ERL of 12 dB. RERL = ERL + ERLE = 12 + 0 = 12 dB.
- 2ワイヤループを備えた回路スイッチネットワークに接続されたIPゲートウェイ。エコーキャンセルなしでは、典型的な2〜4ワイヤーコンバーターERLの12 dB。Reel = ERL ERLE = 12 0 = 12 dB。
- IP gateway connected to circuit switched network with 2 wire loop. With echo canceler that improves echo by 30 dB. RERL = ERL + ERLE = 12 + 30 = 42 dB.
- 2ワイヤループを備えた回路スイッチネットワークに接続されたIPゲートウェイ。エコーを30 dB改善するエコーキャンセラーを使用します。RERL = ERL ERLE = 12 30 = 42 dB。
- IP phone with conventional handset. Acoustic coupling from handset speaker to microphone (terminal coupling loss) is typically 40 dB. RERL = TCL = 40 dB.
- 従来の携帯電話を備えたIP電話。ハンドセットスピーカーからマイク（端子結合損失）への音響結合は、通常40 dBです。RERL = TCL = 40 dB。
If we denote the local end of the VoIP path as A and the remote end as B, and if the sender loudness rating (SLR) and receiver loudness rating (RLR) are known for A (default values 8 dB and 2 dB respectively), then the echo loudness level at end A (talker echo loudness rating or TELR) is given by:
VoIPパスのローカルエンドをAとして、リモートエンドをBとして示す場合、および送信者ラウドネス評価（SLR）とレシーバーラウドネス評価（RLR）がA（デフォルト値8 dBと2 dB）で知られている場合、次に、最後のエコーラウドネスレベル（トーカーエコーラウドネス評価またはTELR）が与えられます。
TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)
Hence, in order to incorporate echo into a voice quality estimate at the A end of a VoIP connection, it is desirable to send the ERL + ERLE value from B to A using a format such as RTCP XR.
したがって、VoIP接続のA ENDでエコーを音声品質推定に組み込むために、RTCP XRなどの形式を使用してERL ERLE値をBからAに送信することが望ましいです。
Echo related information may not be available in all VoIP end systems. As echo does have a significant effect on conversational quality, it is recommended that estimated values for echo return loss and terminal coupling loss be provided (if sensible estimates can be reasonably determined).
エコー関連情報は、すべてのVoIPエンドシステムで利用できない場合があります。エコーは会話の品質に大きな影響を与えるため、エコーリターン損失と端子結合損失の推定値を提供することをお勧めします（賢明な推定値を合理的に決定できる場合）。
Typical values for end systems are given below to provide guidance:
ガイダンスを提供するために、エンドシステムの典型的な値を以下に示します。
- IP Phone with handset: typically 45 dB.
- ハンドセット付きIP電話：通常45 dB。
- PC softphone or speakerphone: extremely variable, consider reporting "undefined" (127).
- PC SoftPhoneまたはSpeakerPhone：非常に変動します。「未定義」（127）の報告を検討してください。
- IP gateway with line echo canceller: typically has ERL and ERLE available.
- ラインエコーキャンセラーを備えたIPゲートウェイ：通常、ERLとERLEが利用可能です。
- IP gateway without line echo canceller: frequently a source of echo related problems, consider reporting either a low value (12 dB) or "undefined" (127).
- ラインのないIPゲートウェイエコーキャンセラー：多くの場合、エコー関連の問題のソースで、低い値（12 dB）または「未定義」のいずれかを報告することを検討してください（127）。
Gmin See Configuration Parameters (Section 4.7.6, below).
GMIN構成パラメーター（以下のセクション4.7.6）を参照してください。
The following metrics are direct measures of the call quality or transmission quality, and incorporate the effects of codec type, packet loss, discard, burstiness, delay etc. These metrics may not be available in all systems, however, they SHOULD be provided in order to support problem diagnosis.
次のメトリックは、コールの品質または伝送品質の直接的な測定値であり、コーデックタイプ、パケット損失、破棄、バースト、遅延などの効果を組み込みます。これらのメトリックはすべてのシステムで利用できない場合がありますが、順番に提供する必要があります。問題の診断をサポートするため。
R factor: 8 bits The R factor is a voice quality metric describing the segment of the call that is carried over this RTP session. It is expressed as an integer in the range 0 to 100, with a value of 94 corresponding to "toll quality" and values of 50 or less regarded as unusable. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3].
R因子：8ビットR因子は、このRTPセッションで実行されるコールのセグメントを説明する音声品質メトリックです。これは、0〜100の範囲の整数として表現され、94の値は「料金」に対応し、50以下の値が使用できないと見なされます。このメトリックは、ITU-T G.107 [6]およびETSI TS 101 329-5 [3]と一致する遅延の効果を含むものとして定義されます。
A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system.
127の値は、このパラメーターが利用できないことを示します。127以外の値と上記の有効な範囲を送信する必要はなく、受信システムによって無視する必要があります。
ext. R factor: 8 bits The external R factor is a voice quality metric describing the segment of the call that is carried over a network segment external to the RTP segment, for example a cellular network. Its values are interpreted in the same manner as for the RTP R factor. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3], and relates to the outward voice path from the Voice over IP termination for which this metrics block applies.
内線R因子：8ビット外部R因子は、たとえばセルラーネットワークなど、RTPセグメントの外部のネットワークセグメントに掲載されるコールのセグメントを説明する音声品質メトリックです。その値は、RTP R因子と同じ方法で解釈されます。このメトリックは、ITU-T G.107 [6]およびETSI TS 101 329-5 [3]と一致する遅延の効果を含むものとして定義され、このメトリックが行われたVoice Over IP終了からの外向きの音声パスに関連していますブロックが適用されます。
A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system.
127の値は、このパラメーターが利用できないことを示します。127以外の値と上記の有効な範囲を送信する必要はなく、受信システムによって無視する必要があります。
Note that an overall R factor may be estimated from the RTP segment R factor and the external R factor, as follows:
次のように、全体のR因子がRTPセグメントR因子と外部R因子から推定される可能性があることに注意してください。
R total = RTP R factor + ext. R factor - 94
MOS-LQ: 8 bits The estimated mean opinion score for listening quality (MOS-LQ) is a voice quality metric on a scale from 1 to 5, in which 5 represents excellent and 1 represents unacceptable. This metric is defined as not including the effects of delay and can be compared to MOS scores obtained from listening quality (ACR) tests. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10. For example, a value of 35 would correspond to an estimated MOS score of 3.5.
MOS-LQ：8ビットリスニング品質（MOS-LQ）の推定平均意見スコアは、1から5のスケールでの音声品質メトリックであり、5は優れており、1は容認できないものを表します。このメトリックは、遅延の効果を含めないものとして定義され、リスニング品質（ACR）テストから得られたMOSスコアと比較できます。これは、MOS X 10に対応する範囲10〜50の整数として表されます。たとえば、35の値は、推定MOSスコア3.5に対応します。
A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system.
127の値は、このパラメーターが利用できないことを示します。127以外の値と上記の有効な範囲を送信する必要はなく、受信システムによって無視する必要があります。
MOS-CQ: 8 bits The estimated mean opinion score for conversational quality (MOS-CQ) is defined as including the effects of delay and other effects that would affect conversational quality. The metric may be calculated by converting an R factor determined according to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated MOS using the equation specified in G.107. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10, as for MOS-LQ.
MOS-CQ：8ビット会話品質（MOS-CQ）の推定平均意見スコアは、ディレイの効果や会話の品質に影響を与えるその他の効果を含むものとして定義されます。メトリックは、G.107で指定された方程式を使用して、ITU-T G.107 [6]またはETSI TS 101 329-5 [3]に従って決定されたR因子を推定MOSに変換することによって計算できます。MOS-LQに関して、MOS X 10に対応する10〜50の範囲の整数として表されます。
A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system.
127の値は、このパラメーターが利用できないことを示します。127以外の値と上記の有効な範囲を送信する必要はなく、受信システムによって無視する必要があります。
Gmin: 8 bits The gap threshold. This field contains the value used for this report block to determine if a gap exists. The recommended value of 16 corresponds to a burst period having a minimum density of 6.25% of lost or discarded packets, which may cause noticeable degradation in call quality; during gap periods, if packet loss or discard occurs, each lost or discarded packet would be preceded by and followed by a sequence of at least 16 received non-discarded packets. Note that lost or discarded packets that occur within Gmin packets of a report being generated may be reclassified as part of a burst or gap in later reports. ETSI TS 101 329-5 [3] defines a computationally efficient algorithm for measuring burst and gap density using a packet loss/discard event driven approach. This algorithm is reproduced in Appendix A.2 of the present document. Gmin MUST not be zero, MUST be provided, and MUST remain constant across VoIP Metrics report blocks for the duration of the RTP session.
GMIN：ギャップのしきい値を8ビットします。このフィールドには、このレポートブロックに使用される値が含まれており、ギャップが存在するかどうかを判断します。推奨される値16は、失われたパケットまたは破棄されたパケットの最小密度が6.25％のバースト期間に対応し、コール品質に顕著な分解を引き起こす可能性があります。ギャップ期間中、パケットの損失または破棄が発生した場合、それぞれの紛失または破棄されたパケットの前に、少なくとも16の受信された非容認されていないパケットのシーケンスが続きます。生成されるレポートのGMINパケット内で発生する紛失または廃棄されたパケットは、後のレポートでバーストまたはギャップの一部として再分類される可能性があることに注意してください。ETSI TS 101 329-5 [3]は、パケットの損失/廃棄イベント駆動型アプローチを使用して、バーストとギャップ密度を測定するための計算効率的なアルゴリズムを定義します。このアルゴリズムは、現在のドキュメントの付録A.2に再現されています。GMINはゼロではなく、提供されている必要があり、RTPセッションの期間中、VoIPメトリックレポートブロック全体で一定のままでなければなりません。
receiver configuration byte (RX config): 8 bits This byte consists of the following fields:
受信機構成バイト（RX構成）：8ビットこのバイトは、次のフィールドで構成されています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PLC|JBA|JB rate|
+-+-+-+-+-+-+-+-+
packet loss concealment (PLC): 2 bits Standard (11) / enhanced (10) / disabled (01) / unspecified (00). When PLC = 11, then a simple replay or interpolation algorithm is being used to fill-in the missing packet; this approach is typically able to conceal isolated lost packets at low packet loss rates. When PLC = 10, then an enhanced interpolation algorithm is being used; algorithms of this type are able to conceal high packet loss rates effectively. When PLC = 01, then silence is being inserted in place of lost packets. When PLC = 00, then no information is available concerning the use of PLC; however, for some codecs this may be inferred.
パケット損失隠蔽（PLC）：2ビット標準（11） /拡張（10） /無効（01） /不特定（00）。PLC = 11の場合、不足しているパケットを埋めるために、単純なリプレイまたは補間アルゴリズムが使用されます。このアプローチは通常、低パケット損失率で孤立した紛失パケットを隠すことができます。PLC = 10の場合、拡張補間アルゴリズムが使用されています。このタイプのアルゴリズムは、高いパケット損失率を効果的に隠すことができます。plc = 01の場合、紛失パケットの代わりに沈黙が挿入されます。PLC = 00の場合、PLCの使用に関する情報は利用できません。ただし、一部のコーデックでは、これが推測される場合があります。
jitter buffer adaptive (JBA): 2 bits Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When the jitter buffer is adaptive, then its size is being dynamically adjusted to deal with varying levels of jitter. When non-adaptive, the jitter buffer size is maintained at a fixed level. When either adaptive or non-adaptive modes are specified, then the jitter buffer size parameters below MUST be specified.
Jitter Buffer Adaptive（JBA）：2ビット適応型（11） /非適応（10） /予約（01） /不明（00）。ジッターバッファが適応性がある場合、そのサイズはさまざまなレベルのジッターに対処するように動的に調整されています。適応性のない場合、ジッターバッファサイズは固定レベルに維持されます。適応モードまたは非適応モードのいずれかが指定されている場合、以下のジッターバッファサイズパラメーターを指定する必要があります。
jitter buffer rate (JB rate): 4 bits J = adjustment rate (0-15). This represents the implementation specific adjustment rate of a jitter buffer in adaptive mode. This parameter is defined in terms of the approximate time taken to fully adjust to a step change in peak to peak jitter from 30 ms to 100 ms such that:
ジッターバッファーレート（JBレート）：4ビットJ =調整率（0-15）。これは、適応モードでのジッターバッファーの実装固有の調整レートを表します。このパラメーターは、ピークのステップ変更に完全に調整するために取られたおおよその時間の観点から定義されています。
adjustment time = 2 * J * frame size (ms) This parameter is intended only to provide a guide to the degree of "aggressiveness" of an adaptive jitter buffer and may be estimated. A value of 0 indicates that the adjustment time is unknown for this implementation.
調整時間= 2 * J *フレームサイズ（MS）このパラメーターは、適応ジッターバッファの「攻撃性」の程度のガイドを提供することのみを目的としており、推定される場合があります。0の値は、この実装では調整時間が不明であることを示します。
reserved: 8 bits This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.
予約済み：8ビットこのフィールドは、将来の定義のために予約されています。このような定義がない場合、このフィールドのビットはゼロに設定し、受信機によって無視する必要があります。
The values reported in these fields SHOULD be the most recently obtained values at the time of reporting.
これらのフィールドで報告された値は、報告時に最近取得された値である必要があります。
jitter buffer nominal delay (JB nominal): 16 bits This is the current nominal jitter buffer delay in milliseconds, which corresponds to the nominal jitter buffer delay for packets that arrive exactly on time. This parameter MUST be provided for both fixed and adaptive jitter buffer implementations.
ジッターバッファー名目遅延（JB名目）：16ビットこれは、ミリ秒単位での現在の公称ジッターバッファー遅延であり、時間通りに到着するパケットの公称ジッターバッファー遅延に対応します。このパラメーターは、固定および適応型ジッターバッファーの実装の両方で提供する必要があります。
jitter buffer maximum delay (JB maximum): 16 bits This is the current maximum jitter buffer delay in milliseconds which corresponds to the earliest arriving packet that would not be discarded. In simple queue implementations this may correspond to the nominal size. In adaptive jitter buffer implementations, this value may dynamically vary up to JB abs max (see below). This parameter MUST be provided for both fixed and adaptive jitter buffer implementations.
ジッターバッファ最大遅延（JB最大）：16ビットこれは、廃棄されない最も早い到着パケットに対応するミリ秒の現在の最大ジッターバッファー遅延です。単純なキューの実装では、これは名目サイズに対応する場合があります。Adaptive Jitterバッファーの実装では、この値はJB ABS Maxまで動的に異なる場合があります（以下を参照）。このパラメーターは、固定および適応型ジッターバッファーの実装の両方で提供する必要があります。
jitter buffer absolute maximum delay (JB abs max): 16 bits This is the absolute maximum delay in milliseconds that the adaptive jitter buffer can reach under worst case conditions. If this value exceeds 65535 milliseconds, then this field SHALL convey the value 65535. This parameter MUST be provided for adaptive jitter buffer implementations and its value MUST be set to JB maximum for fixed jitter buffer implementations.
ジッターバッファー絶対最大遅延（JB ABS MAX）：16ビットこれは、最悪の場合の条件下で適応ジッターバッファが到達できるミリ秒の絶対最大遅延です。この値が65535ミリ秒を超える場合、このフィールドは値65535を伝えなければならない。このパラメーターは、適応ジッターバッファーの実装に提供する必要があり、その値は固定ジッターバッファーの実装ではJB最大に設定する必要があります。
This section defines Session Description Protocol (SDP) [4] signaling for XR blocks that can be employed by applications that utilize SDP. This signaling is defined to be used either by applications that implement the SDP Offer/Answer model [8] or by applications that use SDP to describe media and transport configurations in connection with such protocols as the Session Announcement Protocol (SAP) [15] or the Real Time Streaming Protocol (RTSP) [17]. There exist other potential signaling methods that are not defined here.
このセクションでは、SDPを利用するアプリケーションで使用できるXRブロックのセッション説明プロトコル（SDP）[4]シグナル伝達を定義します。このシグナル伝達は、SDPオファー/回答モデル[8]を実装するアプリケーションまたはSDPを使用してセッションアナウンスプロトコル（SAP）[15]などのプロトコルに関連したメディアおよび輸送構成を説明するアプリケーションのいずれかによって使用されるように定義されます。リアルタイムストリーミングプロトコル（RTSP）[17]。ここでは定義されていない他の潜在的なシグナル伝達方法が存在します。
The XR blocks MAY be used without prior signaling. This is consistent with the rules governing other RTCP packet types, as described in [9]. An example in which signaling would not be used is an application that always requires the use of one or more XR blocks. However, for applications that are configured at session initiation, the use of some type of signaling is recommended.
XRブロックは、事前の信号なしで使用できます。これは、[9]で説明されているように、他のRTCPパケットタイプを管理するルールと一致しています。シグナリングを使用しない例は、常に1つ以上のXRブロックを使用する必要があるアプリケーションです。ただし、セッション開始時に構成されたアプリケーションには、何らかのタイプのシグナル伝達の使用が推奨されます。
Note that, although the use of SDP signaling for XR blocks may be optional, if used, it MUST be used as defined here. If SDP signaling is used in an environment where XR blocks are only implemented by some fraction of the participants, the ones not implementing the XR blocks will ignore the SDP attribute.
XRブロックにSDPシグナル伝達を使用することはオプションである可能性がありますが、使用する場合は、ここで定義するように使用する必要があります。XRブロックが参加者の一部によってのみ実装されている環境でSDPシグナル伝達が使用される場合、XRブロックを実装していないものはSDP属性を無視します。
This section defines one new SDP attribute "rtcp-xr" that can be used to signal participants in a media session that they should use the specified XR blocks. This attribute can be easily extended in the future with new parameters to cover any new report blocks.
このセクションでは、メディアセッションの参加者に指定されたXRブロックを使用する必要があるというシグナルを使用するために使用できる新しいSDP属性「RTCP-XR」を定義します。この属性は、新しいレポートブロックをカバーする新しいパラメーターを使用して、将来的に簡単に拡張できます。
The RTCP XR blocks SDP attribute is defined below in Augmented Backus-Naur Form (ABNF) [2]. It is both a session and a media level attribute. When specified at session level, it applies to all media level blocks in the session. Any media level specification MUST replace a session level specification, if one is present, for that media block.
RTCP XRブロックSDP属性は、以下に拡張されたBackus-Naurフォーム（ABNF）[2]で定義されています。セッションとメディアレベルの属性の両方です。セッションレベルで指定されると、セッション内のすべてのメディアレベルブロックに適用されます。メディアレベルの仕様は、そのメディアブロックに対して、セッションレベルの仕様を存在する場合は、セッションレベルの仕様を置き換える必要があります。
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
xr-format = pkt-loss-rle
/ pkt-dup-rle
/ pkt-rcpt-times
/ rcvr-rtt
/ stat-summary
/ voip-metrics
/ format-ext
pkt-loss-rle = "pkt-loss-rle" ["=" max-size]
pkt-dup-rle = "pkt-dup-rle" ["=" max-size]
pkt-rcpt-times = "pkt-rcpt-times" ["=" max-size]
rcvr-rtt = "rcvr-rtt" "=" rcvr-rtt-mode [":" max-size]
rcvr-rtt-mode = "all"
/ "sender"
stat-summary = "stat-summary" ["=" stat-flag *("," stat-flag)]
stat-flag = "loss"
/ "dup"
/ "jitt"
/ "TTL"
/ "HL"
voip-metrics = "voip-metrics"
max-size = 1*DIGIT ; maximum block size in octets
DIGIT = %x30-39
format-ext = non-ws-string
non-ws-string = 1*(%x21-FF)
CRLF = %d13.10
The "rtcp-xr" attribute contains zero, one, or more XR block related parameters. Each parameter signals functionality for an XR block, or a group of XR blocks. The attribute is extensible so that parameters can be defined for any future XR block (and a parameter should be defined for every future block).
「RTCP-XR」属性には、ゼロ、1つ、またはそれ以上のXRブロック関連パラメーターが含まれています。各パラメーターは、XRブロックまたはXRブロックのグループの機能を信号します。属性は拡張可能であるため、将来のXRブロックに対してパラメーターを定義できるようにします（将来のブロックごとにパラメーターを定義する必要があります）。
Each "rtcp-xr" parameter belongs to one of two categories. The first category, the unilateral parameters, are for report blocks that simply report on the RTP stream and related metrics. The second category, collaborative parameters, are for XR blocks that involve actions by more than one party in order to carry out their functions.
各「RTCP-XR」パラメーターは、2つのカテゴリのいずれかに属します。最初のカテゴリである一方的なパラメーターは、RTPストリームと関連するメトリックを単に報告するレポートブロック用です。2番目のカテゴリである共同パラメーターは、機能を実行するために複数の当事者によるアクションを含むXRブロック用です。
Round trip time (RTT) measurement is an example of collaborative functionality. An RTP data packet receiver sends a Receiver Reference Time Report Block (Section 4.4). A participant that receives this block sends a DLRR Report Block (Section 4.5) in response, allowing the receiver to calculate its RTT to that participant. As this example illustrates, collaborative functionality may be implemented by two or more different XR blocks. The collaborative functionality of several XR blocks may be governed by a single "rtcp-xr" parameter.
往復時間（RTT）測定は、共同機能の例です。RTPデータパケットレシーバーは、受信者参照時間レポートブロック（セクション4.4）を送信します。このブロックを受信した参加者は、それに応じてDLRRレポートブロック（セクション4.5）を送信し、受信者がその参加者にRTTを計算できるようにします。この例が示すように、共同機能は2つ以上の異なるXRブロックによって実装される場合があります。いくつかのXRブロックの共同機能は、単一の「RTCP-XR」パラメーターによって管理される場合があります。
For the unilateral category, this document defines the following parameters. The parameter names and their corresponding XR formats are as follows:
一方的なカテゴリについては、このドキュメントで次のパラメーターを定義します。パラメーター名とそれに対応するXR形式は次のとおりです。
Parameter name XR block (block type and name)
-------------- ------------------------------------
pkt-loss-rle 1 Loss RLE Report Block
pkt-dup-rle 2 Duplicate RLE Report Block
pkt-rcpt-times 3 Packet Receipt Times Report Block
stat-summary 6 Statistics Summary Report Block
voip-metrics 7 VoIP Metrics Report Block
The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters MAY specify an integer value. This value indicates the largest size the whole report block SHOULD have in octets. This shall be seen as an indication that thinning shall be applied if necessary to meet the target size.
「PKT-LOSS-RLE」、「PKT-DUP-RLE」、および「PKT-RCPT-TIMES」パラメーターは、整数値を指定する場合があります。この値は、レポートブロック全体がオクテットに持つべき最大サイズを示しています。これは、ターゲットサイズを満たすために必要に応じて薄化を適用することを示していると見なされます。
The "stat-summary" parameter contains a list indicating which fields SHOULD be included in the Statistics Summary report blocks that are sent. The list is a comma separated list, containing one or more field indicators. The space character (0x20) SHALL NOT be present within the list. Field indicators represent the flags defined in Section 4.6. The field indicators and their respective flags are as follows:
「stat-summary」パラメーターには、送信される統計概要レポートブロックにどのフィールドを含めるべきかを示すリストが含まれています。リストは、1つ以上のフィールドインジケーターを含むコンマ分離リストです。スペース文字（0x20）はリスト内に存在してはなりません。フィールドインジケータは、セクション4.6で定義されているフラグを表します。フィールドインジケーターとそれぞれのフラグは次のとおりです。
Indicator Flag
--------- ---------------------------
loss loss report flag (L)
dup duplicate report flag (D)
jitt jitter flag (J)
TTL TTL or Hop Limit flag (ToH)
HL TTL or Hop Limit flag (ToH)
For "loss", "dup", and "jitt", the presence of the indicator indicates that the corresponding flag should be set to 1 in the Statistics Summary report blocks that are sent. The presence of "TTL" indicates that the corresponding flag should be set to 1. The presence of "HL" indicates that the corresponding flag should be set to 2. The indicators "TTL" and "HL" MUST NOT be signaled together.
「損失」、「DUP」、および「JITT」の場合、インジケータの存在は、送信される統計概要レポートブロックで対応するフラグを1に設定する必要があることを示します。「TTL」の存在は、対応するフラグを1に設定する必要があることを示します。「HL」の存在は、対応するフラグを2に設定する必要があることを示します。
Blocks in the collaborative category are classified as initiator blocks or response blocks. Signaling SHOULD indicate which participants are required to respond to the initiator block. A party that wishes to receive response blocks from those participants can trigger this by sending an initiator block.
共同カテゴリのブロックは、イニシエーターブロックまたは応答ブロックとして分類されます。シグナリングは、どの参加者がイニシエーターブロックに応答する必要があるかを示す必要があります。これらの参加者から応答ブロックを受け取りたい当事者は、イニシエーターブロックを送信することでこれをトリガーできます。
The collaborative category currently consists only of one functionality, namely the RTT measurement mechanism for RTP data receivers. The collective functionality of the Receiver Reference Time Report Block and DLRR Report Block is represented by the "rcvr-rtt" parameter. This parameter takes as its arguments a mode value and, optionally, a maximum size for the DLRR report block. The mode value "all" indicates that both RTP data senders and data receivers MAY send DLRR blocks, while the mode value "sender" indicates that only active RTP senders MAY send DLRR blocks, i.e., non RTP senders SHALL NOT send DLRR blocks. If a maximum size in octets is included, any DLRR Report Blocks that are sent SHALL NOT exceed the specified size. If size limitations mean that a DLRR Report Block sender cannot report in one block upon all participants from which it has received a Receiver Reference Time Report Block then it SHOULD report on participants in a round robin fashion across several report intervals.
共同カテゴリは現在、1つの機能、つまりRTPデータレシーバーのRTT測定メカニズムのみで構成されています。受信者参照時間レポートブロックとDLRRレポートブロックの集合機能は、「RCVR-RTT」パラメーターで表されます。このパラメーターは、引数としてモード値と、オプションでDLRRレポートブロックの最大サイズを取ります。モード値「ALL」は、RTPデータ送信者とデータ受信機の両方がDLRRブロックを送信できることを示し、モード値「送信者」は、アクティブなRTP送信者のみがDLRRブロックを送信する可能性があることを示します。オクテットの最大サイズが含まれている場合、送信されるDLRRレポートブロックは指定されたサイズを超えてはなりません。サイズの制限が、DLRRレポートブロック送信者が受信者参照時間レポートブロックを受け取ったすべての参加者に1つのブロックに報告できないことを意味する場合、いくつかのレポート間隔でラウンドロビンファッションで参加者にレポートする必要があります。
The "rtcp-xr" attributes parameter list MAY be empty. This is useful in cases in which an application needs to signal that it understands the SDP signaling but does not wish to avail itself of XR functionality. For example, an application in a SIP controlled session could signal that it wishes to stop using all XR blocks by removing all applicable SDP parameters in a re-INVITE message that it sends. If XR blocks are not to be used at all from the beginning of a session, it is RECOMMENDED that the "rtcp-xr" attribute not be supplied at all.
「RTCP-XR」属性パラメーターリストは空になる場合があります。これは、アプリケーションがSDPシグナル伝達を理解していることを信号する必要があるが、XR機能を利用することを望んでいない場合に役立ちます。たとえば、SIP制御セッションのアプリケーションは、該当するすべてのSDPパラメーターを送信するREインベンタルメッセージで削除することにより、すべてのXRブロックの使用を停止したいことを示すことができます。XRブロックをセッションの開始からまったく使用しない場合は、「RTCP-XR」属性をまったく提供しないことをお勧めします。
When the "rtcp-xr" attribute is present, participants SHOULD NOT send XR blocks other than the ones indicated by the parameters. This means that inclusion of a "rtcp-xr" attribute without any parameters tells a participant that it SHOULD NOT send any XR blocks at all. The purpose is to conserve bandwidth. This is especially important when collaborative parameters are applied to a large multicast group: the sending of an initiator block could potentially trigger responses from all participants. There are, however, contexts in which it makes sense to send an XR block in the absence of a parameter signaling its use. For instance, an application might be designed so as to send certain report blocks without negotiation, while using SDP signaling to negotiate the use of other blocks.
「rtcp-xr」属性が存在する場合、参加者はパラメーターで示されているもの以外のXRブロックを送信してはなりません。これは、パラメーターなしで「RTCP-XR」属性を含めることで、参加者にXRブロックをまったく送信してはならないことを示すことを意味します。目的は、帯域幅を節約することです。これは、共同パラメーターが大規模なマルチキャストグループに適用される場合に特に重要です。イニシエーターブロックの送信は、すべての参加者からの応答をトリガーする可能性があります。ただし、パラメーターがその使用を知らせるパラメーターがない場合にXRブロックを送信することが理にかなっているコンテキストがあります。たとえば、SDPシグナルを使用して他のブロックの使用を交渉しながら、特定のレポートブロックを交渉せずに送信するようにアプリケーションを設計する場合があります。
In the Offer/Answer context [8], the interpretation of SDP signaling for XR packets depends upon the direction attribute that is signaled: "recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute is supplied, then "sendrecv" is assumed. This section applies only to unicast media streams, except where noted. Discussion of unilateral parameters is followed by discussion of collaborative parameters in this section.
オファー/回答のコンテキスト[8]では、XRパケットのSDPシグナル伝達の解釈は、「recvonly」、「sendrecv」、または「sendonly」[4]に合図される方向属性に依存します。方向属性が提供されない場合、「sendrecv」が想定されます。このセクションは、記載されている場合を除き、ユニキャストメディアストリームにのみ適用されます。一方的なパラメーターの議論に続いて、このセクションの共同パラメーターの議論が続きます。
For "sendonly" and "sendrecv" media stream offers that specify unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send the corresponding XR blocks. For "sendrecv" offers, the answerer MAY include the "rtcp-xr" attribute in its response, and specify any unilateral parameters in order to request that the offerer send the corresponding XR blocks. The offerer SHOULD send these blocks.
一方的な「RTCP-XR」属性パラメーターを指定する「Sendonly」および「SendRecv」メディアストリームオファーの場合、応答者は対応するXRブロックを送信する必要があります。「sendrecv」オファーの場合、応答者はその応答に「RTCP-XR」属性を含めることができ、オファーが対応するXRブロックを送信するように要求するために一方的なパラメーターを指定することができます。オファーはこれらのブロックを送信する必要があります。
For "recvonly" media stream offers, the offerer's use of the "rtcp-xr" attribute in connection with unilateral parameters indicates that the offerer is capable of sending the corresponding XR blocks. If the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD send XR blocks for each specified unilateral parameter that was in its offer.
「Recvonly」メディアストリームオファーの場合、一方的なパラメーターに関連した「RTCP-XR」属性の提供者による使用は、オファーが対応するXRブロックを送信できることを示しています。回答者が「RTCP-XR」属性で応答する場合、オファーは、そのオファーにある指定された一方的なパラメーターごとにXRブロックを送信する必要があります。
For multicast media streams, the inclusion of an "rtcp-xr" attribute with unilateral parameters means that every media recipient SHOULD send the corresponding XR blocks.
マルチキャストメディアストリームの場合、「RTCP-XR」属性を一方的なパラメーターに含めると、すべてのメディア受信者が対応するXRブロックを送信する必要があります。
An SDP offer with a collaborative parameter declares the offerer capable of receiving the corresponding initiator and replying with the appropriate responses. For example, an offer that specifies the "rcvr-rtt" parameter means that the offerer is prepared to receive Receiver Reference Time Report Blocks and to send DLRR Report Blocks. An offer of a collaborative parameter means that the answerer MAY send the initiator, and, having received the initiator, the offerer SHOULD send the responses.
共同パラメーターを備えたSDPオファーは、対応するイニシエーターを受信し、適切な応答で返信できるオファーを宣言します。たとえば、「RCVR-RTT」パラメーターを指定するオファーは、オファーが受信者参照時間レポートブロックを受信し、DLRRレポートブロックを送信する準備ができていることを意味します。共同パラメーターのオファーとは、回答者がイニシエーターを送信することを意味し、イニシエーターを受け取ったため、オファーは応答を送信する必要があります。
There are exceptions to the rule that an offerer of a collaborative parameter should send responses. For instance, the collaborative parameter might specify a mode that excludes the offerer; or congestion control or maximum transmission unit considerations might militate against the offerer's response.
共同パラメーターの提供者が応答を送信する必要があるというルールには例外があります。たとえば、共同パラメーターは、オファーを除外するモードを指定する場合があります。または、輻輳制御または最大の伝送ユニットの考慮事項は、提供者の応答に対して激化する可能性があります。
By including a collaborative parameter in its answer, the answerer declares its ability to receive initiators and to send responses. The offerer MAY then send initiators, to which the answerer SHOULD reply with responses. As for the offer of a collaborative parameter, there are exceptions to the rule that the answerer should reply.
回答に共同パラメーターを含めることにより、Answererは、イニシエーターを受け取り、応答を送信する能力を宣言します。その後、オファーはイニシエーターを送信する場合があります。イニシエーターは、回答者が応答して返信する必要があります。共同パラメーターの提供に関しては、応答者が返信するというルールには例外があります。
When making an SDP offer of a collaborative parameter for a multicast media stream, the offerer SHOULD specify which participants are to respond to a received initiator. A participant that is not specified SHOULD NOT send responses. Otherwise, undue bandwidth might be consumed. The offer indicates that each participant that is specified SHOULD respond if it receives an initiator. It also indicates that a specified participant MAY send an initiator block.
マルチキャストメディアストリームに対して共同パラメーターのSDPオファーを作成する場合、オファーは受信したイニシエーターに応答する参加者を指定する必要があります。指定されていない参加者は、応答を送信しないでください。そうしないと、過度の帯域幅が消費される場合があります。オファーは、指定された各参加者がイニシエーターを受け取った場合に応答する必要があることを示しています。また、指定された参加者がイニシエーターブロックを送信できることも示しています。
An SDP answer for a multicast media stream SHOULD include all collaborative parameters that are present in the offer and that are supported by the answerer. It SHOULD NOT include any collaborative parameter that is absent from the offer.
マルチキャストメディアストリームのSDP回答には、オファーに存在し、応答者によってサポートされているすべての共同パラメーターを含める必要があります。オファーに欠けている共同パラメーターを含めるべきではありません。
If a participant receives an SDP offer and understands the "rtcp-xr" attribute but does not wish to implement XR functionality offered, its answer SHOULD include an "rtcp-xr" attribute without parameters. By doing so, the party declares that, at a minimum, is capable of understanding the signaling.
参加者がSDPのオファーを受信し、「RTCP-XR」属性を理解しているが、提供されるXR機能を実装することを希望しない場合、その回答にはパラメーターのない「RTCP-XR」属性を含める必要があります。そうすることで、当事者は、少なくともシグナリングを理解できることを宣言します。
SDP can be employed outside of the Offer/Answer context, for instance for multimedia sessions that are announced through the Session Announcement Protocol (SAP) [15], or streamed through the Real Time Streaming Protocol (RTSP) [17]. The signaling model is simpler, as the sender does not negotiate parameters, but the functionality expected from specifying the "rtcp-xr" attribute is the same as in Offer/Answer.
SDPは、セッションアナウンスプロトコル（SAP）[15]を介して発表されるマルチメディアセッションでは、オファー/回答のコンテキストの外で採用できます。送信者はパラメーターを交渉しないため、シグナルモデルはより簡単ですが、「RTCP-XR」属性を指定することから期待される機能は、オファー/回答と同じです。
When a unilateral parameter is specified for the "rtcp-xr" attribute associated with a media stream, the receiver of that stream SHOULD send the corresponding XR block. When a collaborative parameter is specified, only the participants indicated by the mode value in the collaborative parameter are concerned. Each such participant that receives an initiator block SHOULD send the corresponding response block. Each such participant MAY also send initiator blocks.
メディアストリームに関連付けられた「RTCP-XR」属性に一方的なパラメーターが指定されている場合、そのストリームの受信機は対応するXRブロックを送信する必要があります。共同パラメーターが指定されている場合、共同パラメーターのモード値で示される参加者のみが関係しています。イニシエーターブロックを受信する各参加者は、対応する応答ブロックを送信する必要があります。そのような各参加者は、イニシエーターブロックを送信することもできます。
This document defines a new RTCP packet type, the Extended Report (XR) type, within the existing Internet Assigned Numbers Authority (IANA) registry of RTP RTCP Control Packet Types. This document also defines a new IANA registry: the registry of RTCP XR Block Types. Within this new registry, this document defines an initial set of seven block types and describes how the remaining types are to be allocated.
このドキュメントでは、RTP RTCPコントロールパケットタイプの既存のインターネット割り当てされた数字局（IANA）レジストリ内で、新しいRTCPパケットタイプである拡張レポート（XR）タイプを定義します。このドキュメントは、新しいIANAレジストリ：RTCP XRブロックタイプのレジストリも定義しています。この新しいレジストリ内で、このドキュメントは7つのブロックタイプの初期セットを定義し、残りのタイプをどのように割り当てるかを説明します。
Further, this document defines a new SDP attribute, "rtcp-xr", within the existing IANA registry of SDP Parameters. It defines a new IANA registry, the registry of RTCP XR SDP Parameters, and an initial set of six parameters, and describes how additional parameters are to be allocated.
さらに、このドキュメントは、SDPパラメーターの既存のIANAレジストリ内の新しいSDP属性「RTCP-XR」を定義します。新しいIANAレジストリ、RTCP XR SDPパラメーターのレジストリ、および6つのパラメーターの初期セットを定義し、追加のパラメーターをどのように割り当てるかを説明します。
The XR packet type defined by this document is registered with the IANA as packet type 207 in the registry of RTP RTCP Control Packet types (PT).
このドキュメントで定義されたXRパケットタイプは、RTP RTCPコントロールパケットタイプ（PT）のレジストリでパケットタイプ207としてIANAに登録されています。
This document creates an IANA registry called the RTCP XR Block Type Registry to cover the name space of the Extended Report block type (BT) field specified in Section 3. The BT field contains eight bits, allowing 256 values. The RTCP XR Block Type Registry is to be managed by the IANA according to the Specification Required policy of RFC 2434 [7]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document:
このドキュメントでは、RTCP XRブロックタイプレジストリと呼ばれるIANAレジストリを作成して、セクション3で指定された拡張レポートブロックタイプ（BT）フィールドの名前スペースをカバーしています。BTフィールドには8つのビットが含まれており、256の値が許可されています。RTCP XRブロックタイプレジストリは、RFC 2434の仕様が必要なポリシーに従ってIANAによって管理されます[7]。将来の仕様は、このドキュメントに起因する値に従って、厳格な数値でブロックタイプの値を起因する必要があります。
BT name
-- ----
1 Loss RLE Report Block
2 Duplicate RLE Report Block
3 Packet Receipt Times Report Block
4 Receiver Reference Time Report Block
5 DLRR Report Block
6 Statistics Summary Report Block
7 VoIP Metrics Report Block
The BT value 255 is reserved for future extensions.
BT値255は、将来の拡張機能のために予約されています。
Furthermore, future specifications SHOULD avoid the value 0. Doing so facilitates packet validity checking, since an all-zeros field might commonly be found in an ill-formed packet.
さらに、将来の仕様は値0を回避する必要があります。そうすることで、パケットの妥当性チェックが容易になります。
Any registration MUST contain the following information:
登録には次の情報が含まれている必要があります。
- Contact information of the one doing the registration, including at least name, address, and email.
- 少なくとも名前、住所、電子メールを含む登録を行う人の連絡先情報。
- The format of the block type being registered, consistent with the extended report block format described in Section 3.
- セクション3で説明されている拡張レポートブロック形式と一致して、登録されているブロックタイプの形式。
- A description of what the block type represents and how it shall be interpreted, detailing this information for each of its fields.
- ブロックタイプが表すものとそれがどのように解釈されるかについての説明。各フィールドのこの情報を詳しく説明します。
The SDP attribute "rtcp-xr" defined by this document is registered with the IANA registry of SDP Parameters as follows:
このドキュメントで定義されたSDP属性「RTCP-XR」は、次のようにSDPパラメーターのIANAレジストリに登録されています。
SDP Attribute ("att-field"):
SDP属性（ "att-field"）：
Attribute name: rtcp-xr Long form: RTP Control Protocol Extended Report Parameters Type of name: att-field Type of attribute: session and media level Subject to charset: no Purpose: see Section 5 of this document Reference: this document Values: see this document and registrations below
属性名：RTCP-XR LONGフォーム：RTP制御プロトコル拡張レポートパラメーター名前のタイプ：ATTフィールドタイプの属性：Charsetの対象：セッションとメディアレベルcharset：なし目的：このドキュメントリファレンスのセクション5を参照：このドキュメント値：参照：参照以下のこのドキュメントと登録
The attribute has an extensible parameter field and therefore a registry for these parameters is required. This document creates an IANA registry called the RTCP XR SDP Parameters Registry. It contains the six parameters defined in Section 5.1: "pkt-loss-rle", "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and "recv-rtt".
属性には拡張可能なパラメーターフィールドがあるため、これらのパラメーターのレジストリが必要です。このドキュメントは、RTCP XR SDPパラメーターレジストリと呼ばれるIANAレジストリを作成します。セクション5.1で定義された6つのパラメーター：「PKT-LOSS-RLE」、「PKT-DUP-RLE」、「PKT-RCPT-TIMES」、「Stat-Summary」、「VoIP-Metrics」、および「Recv-が含まれています。rtt "。
Additional parameters are to be added to this registry in accordance with the Specification Required policy of RFC 2434 [7]. Any registration MUST contain the following information:
RFC 2434 [7]の仕様が必要なポリシーに従って、このレジストリに追加のパラメーターを追加する必要があります。登録には次の情報が含まれている必要があります。
- Contact information of the one doing the registration, including at least name, address, and email.
- 少なくとも名前、住所、電子メールを含む登録を行う人の連絡先情報。
- An Augmented Backus-Naur Form (ABNF) [2] definition of the parameter, in accordance with the "format-ext" definition of Section 5.1.
- セクション5.1の「形式」定義に従って、パラメーターの拡張されたBackus-Naurフォーム（ABNF）[2]の定義。
- A description of what the parameter represents and how it shall be interpreted, both normally and in Offer/Answer.
- パラメーターが表すものと、それがどのように解釈されるかについての説明は、正常に、そして提供/回答の両方で。
This document extends the RTCP reporting mechanism. The security considerations that apply to RTCP reports [9, Appendix B] also apply to XR reports. This section details the additional security considerations that apply to the extensions.
このドキュメントは、RTCPレポートメカニズムを拡張します。RTCPレポート[9、付録B]に適用されるセキュリティ上の考慮事項は、XRレポートにも適用されます。このセクションでは、拡張機能に適用される追加のセキュリティ上の考慮事項について説明します。
The extensions introduce heightened confidentiality concerns. Standard RTCP reports contain a limited number of summary statistics. The information contained in XR reports is both more detailed and more extensive (covering a larger number of parameters). The per-packet report blocks and the VoIP Metrics Report Block provide examples.
拡張により、機密性の懸念が高まることがあります。標準のRTCPレポートには、限られた数の要約統計が含まれています。XRレポートに含まれる情報は、より詳細かつより広範囲です（より多くのパラメーターをカバーしています）。パケットごとのレポートブロックとVoIPメトリックレポートブロックは例を示しています。
The per-packet information contained in Loss RLE, Duplicate RLE, and Packet Receipt Times Report Blocks facilitates multicast inference of network characteristics (MINC) [11]. Such inference can reveal the gross topology of a multicast distribution tree, as well as parameters, such as the loss rates and delays, along paths between branching points in that tree. Such information might be considered sensitive to autonomous system administrators.
損失RLE、複製RLE、およびパケットレシート時間レポートに含まれるパケットごとの情報は、ネットワーク特性（MINC）のマルチキャスト推論を促進することを促進します[11]。このような推論は、そのツリーの分岐点間のパスに沿って、マルチキャスト分布ツリーのグロストポロジーと、損失率や遅延などのパラメーターを明らかにすることができます。このような情報は、自律システム管理者に敏感であると見なされる場合があります。
The VoIP Metrics Report Block provides information on the quality of ongoing voice calls. Though such information might be carried in an application specific format in standard RTP sessions, making it available in a standard format here makes it more available to potential eavesdroppers.
VoIP Metricsレポートブロックは、進行中の音声通話の品質に関する情報を提供します。このような情報は、標準のRTPセッションでアプリケーション固有の形式で実施される可能性がありますが、ここで標準形式で利用できるようにすると、潜在的な盗聴者がより利用できるようになります。
No new mechanisms are introduced in this document to ensure confidentiality. Encryption procedures, such as those being suggested for a Secure RTCP (SRTCP) [12] at the time that this document was written, can be used when confidentiality is a concern to end hosts. Given that RTCP traffic can be encrypted by the end hosts, autonomous systems must be prepared for the fact that certain aspects of their network topology can be revealed.
このドキュメントには、機密性を確保するための新しいメカニズムは導入されていません。安全なRTCP（SRTCP）[12]のために提案されているような暗号化手順は、このドキュメントが書かれた時点で、ホストを終了するための懸念である場合に使用できます。RTCPトラフィックはエンドホストによって暗号化できることを考えると、ネットワークトポロジの特定の側面を明らかにできるという事実に対して自律システムを準備する必要があります。
Any encryption or filtering of XR report blocks entails a loss of monitoring information to third parties. For example, a network that establishes a tunnel to encrypt VoIP Report Blocks denies that information to the service providers traversed by the tunnel. The service providers cannot then monitor or respond to the quality of the VoIP calls that they carry, potentially creating problems for the network's users. As a default, XR packets should not be encrypted or filtered.
XRレポートブロックの暗号化またはフィルタリングは、第三者への監視情報の損失を伴います。たとえば、VoIPレポートブロックを暗号化するトンネルを確立するネットワークは、トンネルによって横断されるサービスプロバイダーへのその情報を否定します。その後、サービスプロバイダーは、携帯するVoIPコールの品質を監視したり、応答したりすることはできず、ネットワークのユーザーに問題が発生する可能性があります。デフォルトとして、XRパケットを暗号化またはフィルタリングしないでください。
The extensions also make certain denial of service attacks easier. This is because of the potential to create RTCP packets much larger than average with the per packet reporting capabilities of the Loss RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the automatic bandwidth adjustment mechanisms in RTCP, if some session participants are sending large RTCP packets, all participants will see their RTCP reporting intervals lengthened, meaning they will be able to report less frequently. To limit the effects of large packets, even in the absence of denial of service attacks, applications SHOULD place an upper limit on the size of the XR report blocks they employ. The "thinning" techniques described in Section 4.1 permit the packet-by-packet report blocks to adhere to a predefined size limit.
また、拡張機能は、特定のサービス攻撃を容易にします。これは、損失RLE、重複RLE、およびタイムスタンプレポートブロックのパケットレポート機能を使用して、平均よりもはるかに大きいRTCPパケットを作成する可能性があるためです。RTCPの自動帯域幅調整メカニズムのため、一部のセッション参加者が大規模なRTCPパケットを送信している場合、すべての参加者はRTCPの報告間隔が長くなることがわかります。サービス拒否攻撃がない場合でも、大規模なパケットの効果を制限するために、アプリケーションは、採用するXRレポートブロックのサイズに上限を設ける必要があります。セクション4.1で説明されている「薄化」手法では、パケットごとのレポートブロックが事前定義されたサイズ制限に準拠することを許可します。
A. Algorithms
A.アルゴリズム
This is the algorithm suggested by Section 4.1 for keeping track of the sequence numbers from a given sender. It implements the accounting practice required for the generation of Loss RLE Report Blocks.
これは、特定の送信者からシーケンス番号を追跡するためにセクション4.1で提案されたアルゴリズムです。損失RLEレポートブロックの生成に必要な会計慣行を実装します。
This algorithm keeps track of 16 bit sequence numbers by translating them into a 32 bit sequence number space. The first packet received from a source is considered to have arrived roughly in the middle of that space. Each packet that follows is placed either ahead of or behind the prior one in this 32 bit space, depending upon which choice would place it closer (or, in the event of a tie, which choice would not require a rollover in the 16 bit sequence number).
このアルゴリズムは、32ビットシーケンス番号スペースに変換することにより、16ビットシーケンス番号を追跡します。ソースから受信した最初のパケットは、そのスペースのほぼ中央に到着したと見なされます。次の各パケットは、この選択が近づくか（または、16ビットシーケンスでロールオーバーを必要としないネクタイの場合に、この32ビットスペースの前のパケットの前または後ろに配置されます。番号）。
// The reference sequence number is an extended sequence number
// that serves as the basis for determining whether a new 16 bit
// sequence number comes earlier or later in the 32 bit sequence
// space.
u_int32 _src_ref_seq;
bool _uninitialized_src_ref_seq;
// Place seq into a 32-bit sequence number space based upon a // heuristic for its most likely location. u_int32 extend_seq(const u_int16 seq) {
//最も可能性の高い場所については、a // heuristicに基づいて、seqを32ビットシーケンス番号スペースに配置します。u_int32 extend_seq（const u_int16 seq）{
u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b; if(_uninitialized_src_ref_seq) {
u_int32 extended_seq、seq_a、seq_b、diff_a、diff_b;if（_uninitialized_src_ref_seq）{
// This is the first sequence number received. Place
// it in the middle of the extended sequence number
// space.
_src_ref_seq = seq | 0x80000000u;
_uninitialized_src_ref_seq = false;
extended_seq = _src_ref_seq;
}
else {
// Prior sequence numbers have been received.
// Propose two candidates for the extended sequence
// number: seq_a is without wraparound, seq_b with
// wraparound.
seq_a = seq | (_src_ref_seq & 0xFFFF0000u);
if(_src_ref_seq < seq_a) {
seq_b = seq_a - 0x00010000u;
diff_a = seq_a - _src_ref_seq;
diff_b = _src_ref_seq - seq_b;
}
else {
seq_b = seq_a + 0x00010000u;
diff_a = _src_ref_seq - seq_a;
diff_b = seq_b - _src_ref_seq;
}
// Choose the closer candidate. If they are equally
// close, the choice is somewhat arbitrary: we choose
// the candidate for which no rollover is necessary.
if(diff_a < diff_b) {
extended_seq = seq_a;
}
else {
extended_seq = seq_b;
}
// Set the reference sequence number to be this most // recently-received sequence number. _src_ref_seq = extended_seq; }
//参照シーケンス番号をこれに最も最大に設定します//最近受信したシーケンス番号。_src_ref_seq = extended_seq;}
// Return our best guess for a 32-bit sequence number that // corresponds to the 16-bit number we were given. return extended_seq; }
// 32ビットシーケンス番号の最良の推測を返します。//与えられた16ビット番号に対応します。return extended_seq;}
A.2. Example Burst Packet Loss Calculation.
A.2. バーズパケット損失計算の例。
This is an algorithm for measuring the burst characteristics for the VoIP Metrics Report Block (Section 4.7). The algorithm, which has been verified against a working implementation for correctness, is reproduced from ETSI TS 101 329-5 [3]. The algorithm, as described here, takes precedence over any change that might eventually be made to the algorithm in future ETSI documents.
これは、VoIPメトリックレポートブロック（セクション4.7）のバースト特性を測定するためのアルゴリズムです。正確さのための実用的な実装に対して検証されているアルゴリズムは、ETSI TS 101 329-5から再現されています[3]。ここで説明するように、アルゴリズムは、将来のETSIドキュメントのアルゴリズムに最終的に行われる可能性のある変更よりも優先されます。
This algorithm is event driven and hence extremely computationally efficient.
このアルゴリズムはイベント駆動型であるため、非常に計算上効率的です。
Given the following definition of states:
状態の次の定義を考えると、
state 1 = received a packet during a gap state 2 = received a packet during a burst state 3 = lost a packet during a burst state 4 = lost an isolated packet during a gap
状態1 =ギャップ状態でパケットを受け取った状態2 =バースト状態3 =バースト状態でパケットを失った4 =ギャップ中に孤立したパケットを失った
The "c" variables below correspond to state transition counts, i.e., c14 is the transition from state 1 to state 4. It is possible to infer one of a pair of state transition counts to an accuracy of 1 which is generally sufficient for this application.
以下の「C」変数は、状態遷移カウントに対応します。つまり、C14は状態1から状態4への遷移です。。
"pkt" is the count of packets received since the last packet was declared lost or discarded, and "lost" is the number of packets lost within the current burst. "packet_lost" and "packet_discarded" are Boolean variables that indicate if the event that resulted in this function being invoked was a lost or discarded packet.
「PKT」は、最後のパケットが紛失または破棄されたと宣言されてから受信したパケットのカウントであり、「失われた」は現在のバースト内で失われたパケットの数です。「packet_lost」と「packet_discarded」は、この関数が呼び出されたイベントが紛失または廃棄されたパケットであるかどうかを示すブール変数です。
if(packet_lost) {
loss_count++;
}
if(packet_discarded) {
discard_count++;
}
if(!packet_lost && !packet_discarded) {
pkt++;
}
else {
if(pkt >= gmin) {
if(lost == 1) {
c14++;
}
else {
c13++;
}
lost = 1;
c11 += pkt;
}
else {
lost++;
if(pkt == 0) {
c33++;
}
else {
c23++;
c22 += (pkt - 1);
}
}
pkt = 0;
}
At each reporting interval the burst and gap metrics can be calculated as follows.
各レポート間隔で、バーストとギャップのメトリックを次のように計算できます。
// Calculate additional transition counts.
c31 = c13;
c32 = c23;
ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;
// Calculate burst and densities.
p32 = c32 / (c31 + c32 + c33);
if((c22 + c23) < 1) {
p23 = 1;
}
else {
p23 = 1 - c22/(c22 + c23);
}
burst_density = 256 * p23 / (p23 + p32);
gap_density = 256 * c14 / (c11 + c14);
// Calculate burst and gap durations in ms
m = frameDuration_in_ms * framesPerRTPPkt;
gap_length = (c11 + c14 + c13) * m / c13;
burst_length = ctotal * m / c13 - lgap;
/* calculate loss and discard rates */
loss_rate = 256 * loss_count / ctotal;
discard_rate = 256 * discard_count / ctotal;
Intellectual Property Notice
知的財産通知
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11 [5]. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP 11 [5]に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
Acknowledgments
謝辞
We thank the following people: Colin Perkins, Steve Casner, and Henning Schulzrinne for their considered guidance; Sue Moon for helping foster collaboration between the authors; Mounir Benzaid for drawing our attention to the reporting needs of MLDA; Dorgham Sisalem and Adam Wolisz for encouraging us to incorporate MLDA block types; and Jose Rey for valuable review of the SDP Signaling section.
次の人々に感謝します。コリン・パーキンス、スティーブ・カスナー、ヘニング・シュルツリンが考えられているガイダンスに感謝します。著者間のコラボレーションの育成を支援してくれたスームーン。MLDAの報告ニーズに注意を向けたMounir Benzaid。Dorgham SisalemとAdam Woliszは、MLDAブロックタイプを組み込むことを奨励してくれました。SDPシグナル伝達セクションの貴重なレビューについては、ホセレイ。
Contributors
貢献者
The following people are the authors of this document:
次の人はこの文書の著者です。
Kevin Almeroth, UCSB Ramon Caceres, IBM Research Alan Clark, Telchemy Robert G. Cole, JHU Applied Physics Laboratory Nick Duffield, AT&T Labs-Research Timur Friedman, Paris 6 Kaynam Hedayat, Brix Networks Kamil Sarac, UT Dallas Magnus Westerlund, Ericsson
Kevin Almeroth、UCSB Ramon Caceres、IBM Research Alan Clark、Telchemy Robert G. Cole、JHU Applied Physics Laboratory Nick Duffield、AT＆T Labs-Research Timur Friedman、Paris 6 Kaynam Hedayat、Brix Networks Kamil Sarac
The principal people to contact regarding the individual report blocks described in this document are as follows:
このドキュメントで説明されている個々のレポートブロックに関して連絡する主要な人々は次のとおりです。
sec. report block principal contributors
---- ------------ ----------------------
4.1 Loss RLE Report Block Friedman, Caceres, Duffield
4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield
4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield
4.4 Receiver Reference Time Report Block Friedman
4.5 DLRR Report Block Friedman
4.6 Statistics Summary Report Block Almeroth, Sarac
4.7 VoIP Metrics Report Block Clark, Cole, Hedayat
The principal person to contact regarding the SDP signaling described in this document is Magnus Westerlund.
この文書に記載されているSDPシグナル伝達に関して連絡する主要な人物は、Magnus Westerlundです。
References
参考文献
Normative References
引用文献
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[3] ETSI, "Quality of Service (QoS) measurement methodologies", ETSI TS 101 329-5 V1.1.1 (2000-11), November 2000.
[3] ETSI、「サービス品質（QOS）測定方法」、ETSI TS 101 329-5 V1.1.1（2000-11）、2000年11月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[4] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[5] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[5] Hovey、R。およびS. Bradner、「IETF標準プロセスに関与する組織」、BCP 11、RFC 2028、1996年10月。
[6] ITU-T, "The E-Model, a computational model for use in transmission planning", Recommendation G.107, January 2003.
[6] ITU-T、「伝送計画で使用するための計算モデルであるE-Model」、推奨G.107、2003年1月。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[9] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 3550、2003年7月。
[10] TIA/EIA-810-A Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones, December 2000.
[10] 2000年12月、IPおよびVoice over PCM Digital Wireline電話の狭帯域音声のTIA/EIA-810-A伝送要件。
Informative References
参考引用
[11] Adams, A., Bu, T., Caceres, R., Duffield, N.G., Friedman, T., Horowitz, J., Lo Presti, F., Moon, S.B., Paxson, V. and D. Towsley, "The Use of End-to-End Multicast Measurements for Characterizing Internal Network Behavior", IEEE Communications Magazine, May 2000.
[11] Adams、A.、Bu、T.、Caceres、R.、Duffield、N.G.、Friedman、T.、Horowitz、J.、Lo Presti、F.、Moon、S.B.、Paxson、V。IEEE Communications Magazine、2000年5月、IEEE Communications Magazine、IEEE Communication Magazine、内部ネットワークの動作を特徴付けるためのエンドツーエンドのマルチキャスト測定の使用。
[12] Baugher, McGrew, Oran, Blom, Carrara, Naslund and Norrman, "The Secure Real-time Transport Protocol", Work in Progress.
[12] Baugher、McGrew、Oran、Blom、Carrara、Naslund、Norrman、「安全なリアルタイム輸送プロトコル」は進行中です。
[13] Caceres, R., Duffield, N.G. and T. Friedman, "Impromptu measurement infrastructures using RTP", Proc. IEEE Infocom 2002.
[13] Caceres、R.、Duffield、N.G。T.フリードマン、「RTPを使用した即興測定インフラストラクチャ」、Proc。IEEE INFOCOM 2002。
[14] Clark, A.D., "Modeling the Effects of Burst Packet Loss and Recency on Subjective Voice Quality", Proc. IP Telephony Workshop 2001.
[14] Clark、A.D。、「主観的な音声品質に対するバーストパケットの損失と最新性の効果のモデリング」、Proc。IPテレフォニーワークショップ2001。
[15] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[15] Handley、M.、Perkins、C。and E. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[16] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[16] Reynolds、J.、ed。、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられます」、RFC 3232、2002年1月。
[17] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[17] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[18] Sisalem D. and A. Wolisz, "MLDA: A TCP-friendly Congestion Control Framework for Heterogeneous Multicast Environments", Proc. IWQoS 2000.
[18] Sisalem D.およびA. Wolisz、「MLDA：不均一なマルチキャスト環境のためのTCPに優しい混雑制御フレームワーク」、Proc。IWQOS 2000。
Authors' Addresses
著者のアドレス
Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106 USA
カリフォルニア州カリフォルニア州サンタバーバラ、カリフォルニア州カリフォルニア州コンピュータサイエンス大学ケビンアルメロス科93106 USA
EMail: almeroth@cs.ucsb.edu
Ramon Caceres IBM Research 19 Skyline Drive Hawthorne, NY 10532 USA
ラモンカセレスIBMリサーチ19スカイラインドライブホーソーン、ニューヨーク10532 USA
EMail: caceres@watson.ibm.com
Alan Clark Telchemy Incorporated 3360 Martins Farm Road, Suite 200 Suwanee, GA 30024 USA
Alan Clark Telchemy Incorporated 3360 Martins Farm Road、Suite 200 Suwanee、GA 30024 USA
Phone: +1 770 614 6944
Fax: +1 770 614 3951
EMail: alan@telchemy.com
Robert G. Cole Johns Hopkins University Applied Physics Laboratory MP2-S170 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA
ロバート・G・コール・ジョンズ・ホプキンス大学応用物理学研究所MP2-S170 11100ジョンズ・ホプキンス・ロード・ローレル、メリーランド20723-6099 USA
Phone: +1 443 778 6951
EMail: robert.cole@jhuapl.edu
Nick Duffield AT&T Labs-Research 180 Park Avenue, P.O. Box 971 Florham Park, NJ 07932-0971 USA
Nick Duffield AT＆T Labs-Research 180 Park Avenue、P.O。Box 971 Florham Park、NJ 07932-0971 USA
Phone: +1 973 360 8726 Fax: +1 973 360 8050 EMail: duffield@research.att.com Timur Friedman Universite Pierre et Marie Curie (Paris 6) Laboratoire LiP6-CNRS 8, rue du Capitaine Scott 75015 PARIS France
電話：1 973 360 8726ファックス：1 973 360 8050メール：duffield@research.att.comティムールフリードマン大学マリーキュリー（パリ6）ラボラトワールLIP6-CNRS 8、RUE DU CAPITAINE SCOTT 75015 PARIS FRANCE
Phone: +33 1 44 27 71 06
Fax: +33 1 44 27 74 95
EMail: timur.friedman@lip6.fr
Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA
Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford、MA 01824 USA
Phone: +1 978 367 5600
Fax: +1 978 367 5700
EMail: khedayat@brixnet.com
Kamil Sarac Department of Computer Science (ES 4.207) Eric Jonsson School of Engineering & Computer Science University of Texas at Dallas Richardson, TX 75083-0688 USA
カミル・サラックコンピュータサイエンス部門（ES 4.207）エリックジョンソン工学＆コンピューターサイエンス大学テキサス州ダラスリチャードソン、テキサス75083-0688 USA
Phone: +1 972 883 2337
Fax: +1 972 883 2349
EMail: ksarac@utdallas.edu
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm Sweden
マグナスウェスターランドエリクソンリサーチエリクソンAB SE-164 80ストックホルムスウェーデン
Phone: +46 8 404 82 87
Fax: +46 8 757 55 50
EMail: magnus.westerlund@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。