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)
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.
著作権（C）インターネット協会（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）の推論やボイスオーバー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）の拡張報告（XR）パケットタイプ[9]を定義し、それがセッション記述プロトコル（SDP）を用いた場合XRパケットの使用は、アプリケーションによってシグナリングすることができる方法を定義する[4] 。 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.
定義は、はじめに続く三つのセクションに渡って分割されます。第2節では、レポート・ブロックと呼ばれる一連の構成要素が続く8つのオクテットのヘッダから成るようXRパケットを定義します。セクション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パケットのパケットごとのレポートで構成されています。第二のカテゴリーのレポートは、RTP参加者間基準時刻情報を伝えます。第三のカテゴリーでは、報告書は、自然の中で要約されているが、それは、既存の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節）：最後のレシーバのリファレンス・タイムレポート・ブロックを受信してから遅延。すでにRTCPのために定義された機構では、限り同じように、DLRRレポート・ブロックで応答することができますレシーバのリファレンス・時間レポートブロックを受信RTPデータ送信者[9、6.3.1項]、受信RTPデータ受信部送信者の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）などMUSTやSHOULDなどのキーワードの規範的な使用を定義します。
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節）の信号を送ることができる方法を説明します。文書は、Internet Assigned Numbers Authority（IANA）のために、セキュリティ上の考慮事項（第7節）の、テキストで説明したアルゴリズムを実装する方法の例を提供付録と番号の配慮の議論（第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のメトリクスのレポートブロックは、RTPとRTCPの使用が指定されている任意の1対1または1対多の音声アプリケーションに適用することができます。 R因子を含む対話メトリクス（セクション4.7.5）の使用は、単純な二当事者以外の用途で、および会話品質（MOS-CQ）の平均オピニオンスコア（[3]で定義されたEモデルによって記載されるように）呼び出しが定義されていません。したがって、これらの指標は、マルチキャスト会議アプリケーションで使用できないように識別されなければなりません。
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.
パケットごとのレポートブロックは、専用のネットワーク監視アプリケーションで使用することができます。このような用途のために、このように比例して大きく、より詳細なレポートブロックを可能にする、RTCPパケットに使用されるRTPデータ帯域幅の5％以上を可能にするために適切であるかもしれません。
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.
リアルタイムストリーミングプロトコル（RTSP）制御ストリーミングアプリケーションは、そのようなコースの講義として、1対多のマルチキャストマルチメディアアプリケーション：このドキュメント（セクション5）でXRパケットのために定義されたSDPシグナリングは念頭に置いて3つの利用シナリオでて行われました強化されたフィードバック、およびセッション開始プロトコル（SIP）との両当事者が関与する会話セッションを制御しました。 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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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）：1ビットは、パディングビットがセットされている場合、この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で説明したように、この値は、インターネット割り当て番号機関（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仕様のセクション6.4.1を参照[9]）。簡潔には、ヘッダおよびパディングを含む32ビットワードから1を引いたもの、にこのXRパケットの長さ。
SSRC: 32 bits The synchronization source identifier for the originator of this XR packet.
SSRC：このXRパケットの発信のために32ビットの同期ソース識別子。
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追加のブロックタイプは、将来の仕様で定義されるセクションで定義されています。 6.2節で説明したように、このフィールドの名前空間は、Internet 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.
ブロック長：32ビットワードから1を引いたものにヘッダを含む16ビットこのレポートブロックの長さ、、。ブロックタイプ定義が許す場合、ゼロは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.
タイプ固有のブロックの内容：可変長このフィールドの使用は、特定のブロックタイプによって定義され、それは32ビット長の倍数でなければならない制約を受けます。ブロックタイプの定義が許すならば、それはゼロのビットの長さとすることができます。
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.
受信したパケット損失、重複、パケット受信時刻、受信機の基準時刻情報に報告するためのブロックタイプ、インターレポートの遅延、詳細な受信統計、およびボイスオーバーIP（VoIP）のメトリックを受信機：このセクションでは、7つの拡張レポートブロックを定義します。実装は、関連するか、それには未知ではない種類の着信ブロックを無視すべきです。セクション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で、1はソースの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つの分野で、[9] RTP仕様に記述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.
参加者は、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.
なぜなら、シーケンス番号のラップアラウンドの、終了シーケンス番号が開始シーケンス番号よりも小さくてもよいことに注意してください。複数のラップアラウンドを識別するいかなる手段が存在しないように消失RLEレポートブロックは、シーケンス番号空間内の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ビット単位の系列から成ります。各チャンクは、ランレングスまたはビット・ベクトルを指定する、またはnullチャンクのいずれか。ランレングスは、すべて同じ（すべての領収書のいずれかまたは全ての損失）は、1〜16,383のイベントを記述する。ビットベクトルは、領収書や損失を混合することができる15回のイベントを記述する。ヌルチャンクにはイベントを記述していない、および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:
チャンクのシーケンスに失われたと受信したパケットのシーケンスからのマッピングは必ずしも一意ではありません。たとえば、次のトレースは、22日と24日が失われていると他の人が受け取ったの45個のパケットを、説明します。
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
１１１１ １１１１ １１１１ １１１１ １１１１ １０１０ １１１１ １１１１ １１１１ １１１１ １１１１ １
One way to encode this would be:
これをコード化する一つの方法は、次のようになります。
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ヌルチャンク
Another way to encode this would be:
これをエンコードする別の方法は、次のようになります。
run of 21 receipts bit vector 0101 1111 1111 111 run of 9 receipts null chunk
21枚の領収書の領収書ラン9のビットベクトル0101 1111 1111 111、実行ヌルチャンク
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
１１１１ １１１１ １１１１ １１１１ １１１１ １０１０ １１１１ １１１１ １１１１ １１１１ １１１０ １
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 1111 111ビットベクトル1111 1110 1000年000ヌルチャンク
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.
でも、ランレングス符号化により提供される圧縮して、彼らは簡単に通常のRTCPパケットと比例して帯域幅を消費することができ、ので注意が消失RLEレポートブロックを送信するときに使用する必要があります。ブロックタイプは、アプリケーションが、レポートのサイズを制限することを可能にする間引きと呼ばれるメカニズムを含みます。
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.
間引き値、Tは、シーケンス番号空間内のパケットのサブセットを選択：2 ^ Tの倍数であるシーケンス番号を有するもの。パケット受信と損失のレポートは、パケットのみに適用されます。 Tがゼロである場合、Tは、その後、シーケンス番号空間内のすべてのパケットが時に報告され、0から15の間で変化させることができます。 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:
今説明したトレースは、シーケンス番号13821から始まると仮定します。トレース内の最後のシーケンス番号は13865です。 13824、13828、13832、13836、13840、13844、13848、13852、13856、13860、13864：トレースは、T = 2の間引き値を薄くするとしたら、次のシーケンス番号は時に報告されます。以下のように薄化トレースは次のようになります。
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.
シーケンス番号13868、13872、13876、および13880を表すビットベクトル中の最後の4ビットは、トレースを越えて延び、従ってゼロに設定され、受信機によって無視されます。そのシーケンス番号、13842は、4の倍数ではないので間伐で、22日のパケットの損失が報告されていない行きます。 4の倍数でないすべてのシーケンス番号のパケット領収書も報告されていない行きます。しかし、この例では間伐は、1つの32ビット・ワードで短縮することが消失RLEレポートブロックを許可しています。
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ビット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.
このフィールドは将来の定義のために予約されている：4ビットRSVD。そのような定義がない場合、このフィールドのビットはゼロに設定しなければならなくて、受信機で無視しなければなりません。
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ビット三のチャンクタイプがあります。チャンクがすべてゼロである場合、それはヌル塊です。ビットベクトルのラン長は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秒の実行を示します。
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.
ランレングス：14ビット1と16,383の間の値。値は（実行タイプとランの両方長さフィールドにゼロがチャンク終端ヌルチャンクになるだろう）ランレングスチャンクのゼロであってはなりません。 15以下のランレングスは、彼らはまた、ビットベクトルチャンクの一部として記述され得るという事実にもかかわらず、ランレングスチャンクで説明することができます。
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パケットストリームに重複を報告します。そのような情報は、ネットワークの診断のために使用され、マルチキャストツリートポロジ推論の基礎としての損失をパケットに代替物を提供することができます。
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レポートブロックのフォーマットと同じです。情報は、パケットロスではなく、パケットの重複に関することにのみ解釈は、異なっています。この場合、符号化されるトレースはまた、0と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.
与えられたシーケンス番号の重複の存在は、レポート期間全体にわたって決定されます。例えば、パケット番号12593は、他のシーケンス番号を持つ他のパケットに続いて、到着した場合、他のパケットの報告期間の後の到着は、そのシーケンス番号の重複として12593のカウントの番号。重複は、その番号の最初のパケット直後に実行する必要はありません。ケアレポートは、シーケンス番号空間の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レポートブロック内の1つのように符号化されます。
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.
このフィールドは将来の定義のために予約されている：4ビットRSVD。そのような定義がない場合、このフィールドのビットはゼロに設定しなければならなくて、受信機で無視しなければなりません。
thinning (T): 4 bits As defined in Section 4.1.
（T）薄く：4ビットセクション4.1で定義された通りです。
block length: 16 bits Defined in Section 3.
ブロック長：セクション3で定義されている16ビット。
SSRC of source: 32 bits As defined in Section 4.1.
ソースのSSRC：32ビットは、セクション4.1で定義された通りです。
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タイムスタンプと同じ単位で表されています。これは、各パケットのために、1は同等の用語で、送信時刻と受信時刻の両方を確立することができますので、ということです。 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.
少なくとも一つのパケットは、このブロックにすると報告された各シーケンス番号のために受信されている必要があります。このブロックタイプが失われたパケットを含んでいるシーケンス番号のシリーズの受信時刻を報告するために使用されている場合は、いくつかのブロックが必要とされています。重複したパケットは、与えられたシーケンス番号のために受信されており、それらのパケットは、その受信時刻が異なる場合は、最も古い以外の時間は報告されてはなりません。これは、レポート間の整合性を確保することです。
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.
このフィールドは将来の定義のために予約されている：4ビットRSVD。そのような定義がない場合、このフィールドのビットはゼロに設定しなければならなくて、受信機で無視しなければなりません。
thinning (T): 4 bits As defined in Section 4.1.
（T）薄く：4ビットセクション4.1で定義された通りです。
block length: 16 bits Defined in Section 3.
ブロック長：セクション3で定義されている16ビット。
SSRC of source: 32 bits As defined in Section 4.1.
ソースのSSRC：32ビットは、セクション4.1で定義された通りです。
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の受信時：受信機におけるシーケンス番号iを有する32ビットのパケットの受信時刻を。パケットフォーマットの図に示すモジュラー算術シーケンス番号ロールオーバを可能にすることです。時間値は、リンク層インターフェース、またはワイヤの到着時間にできるだけ近いいずれの場合においてで確立されることが好ましいです。単位と形式は、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送信レポート[9、秒からNTPタイムスタンプフィールドを再現します。 6.3.1]。このレポートブロックを送信し、応答としてDLRRレポートブロック（次のセクションを参照）を受信することにより、[18]で提案されているように、非送信者は、他の参加者へのラウンドトリップ時間（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ビットは、受信機参考時間レポートブロックが一定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.
ブロック長：16ビット定数2、第3節では、このフィールドの定義に従っています。
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年間を想定しているので、高ビットはゼロになります。経過壁時計の時間を推定するためにサンプリング・クロックを使用することが許されます。壁時計や経過時間の概念を持っていないレポートの送信者はゼロに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、秒以来、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ビットA 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）：NTPタイムスタンプで64のうち32ビットの中間の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ビットの遅延が、参加者SSRC_nから最後の受信リファレンス時間レポートブロックを受信し、このDLRRレポート・ブロックを送信する間、1/65536秒の単位で表さ。レシーバのリファレンス・時間レポートブロックがSSRC_nから受信するためには至っていない場合は、DLRRフィールドはゼロに設定されている（またはDLRRは完全に省略されています）。 SSRC_rこのDLRRレポート・ブロックを発行する受信機を表してみましょう。参加者SSRC_nは、このレシーバタイムスタンプレポート・ブロックが受信された時点Aを記録することによって、SSRC_rへの往復伝搬遅延時間を計算することができます。それは、最後のRRタイムスタンプ（LRR）フィールドを使用し、次いで-LRR-DLRRとして往復伝搬遅延を残すために、このフィールドを減算総往復時間A-LRRを算出します。これは、[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）：lost_packetsフィールドは、そうでなければ、レポート、0が含まれている場合は1ビットのビットが1に設定されています。
duplicate report flag (D): 1 bit Bit set to 1 if the dup_packets field contains a report, 0 otherwise.
重複レポートフラグ（D）：dup_packetsフィールドがレポート、そうでなければ0が含まれている場合、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.
ジッタフラグ（J）：min_jitter、max_jitter、mean_jitter、およびdev_jitterフィールドすべてのレポート、0が含まれている場合は、それらのいずれも行わない場合は1ビットのビットが1に設定されています。
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
TTL又はホップ限界フラグ（ToHが）：2ビットフィールドのどれもmin_ttl_or_hlない場合、このフィールドは0に設定されている、max_ttl_or_hl、mean_ttl_or_hl、またはレポートを含むdev_ttl_or_hl。フィールドがゼロでない場合、すべてのこれらのフィールドのレポートが含まれています。値1は、彼らがIPv4 TTL値に報告することを意味します。値2は、彼らが報告したことを意味します
IPv6 Hop Limit values. The value 3 is undefined and MUST NOT
be used.
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.
このフィールドは将来の定義のために予約されている：3ビットRSVD。そのような定義がない場合、このフィールドのビットはゼロに設定しなければならなくて、受信機で無視しなければなりません。
block length: 16 bits The constant 9, in accordance with the definition of this field in Section 3.
ブロック長：16ビット定数9、第3節では、このフィールドの定義に従っています。
SSRC of source: 32 bits As defined in Section 4.1.
ソースのSSRC：32ビットは、セクション4.1で定義された通りです。
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：上記シーケンス番号間隔内の2つのパケット間の32ビットの最小相対通過時間。すべてのジッタ値は、パケットのRTPタイムスタンプと同じ単位で測定された到着時の記者の時計、との差額として測定されています。
max_jitter: 32 bits The maximum relative transit time between two packets in the above sequence number interval.
max_jitter：上記シーケンス番号間隔内の2つのパケット間の32ビット最大相対通過時間。
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：上記シーケンス番号間隔で各2つのパケット系列との間の32ビット平均相対通過時間は、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又はホップ限界値。
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又はホップ限界値。
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又はホップ限界値の標準偏差。
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のメトリクスレポート・ブロックは、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.
ブロック長：16ビット定数8、第3節では、このフィールドの定義に従っています。
SSRC of source: 32 bits As defined in Section 4.1.
ソースのSSRC：32ビットは、セクション4.1で定義された通りです。
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データパケットの割合が、フィールドの左端にバイナリ点を有する固定小数点数として表されます。この値は（に、パケットの総数は256で除算した結果を乗算、期待パケットの総数（例えばFECなどの任意のエラー保護を適用することの効果の後に）失われた分周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.
受信ジッタバッファにアンダーランまたはオーバーフローに起因後期又は早期の到着に、受信の開始以来、廃棄されたソースからのRTPデータパケットの8ビットの端数：レートを捨てます。この値は、フィールドの左端にバイナリ点を有する固定小数点数として表現されます。それは、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.
バーストは、パケットの高い割合がいずれかによる遅刻に紛失したり、破棄される期間です。バーストは、（a）は、紛失又は破棄パケットで始まる最長系列として、値Gminの換算で定義され、（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.
ギャップは、非公式に、低いパケット損失及び/又は廃棄の期間です。正式には、ギャップは、次のいずれかのように定義される：最初のバーストの前に最後に受信したパケットの受信時刻にRTPセッションの開始から（a）の期間、（b）は、最後のバーストの終わりまでの期間レポートの時間又はいずれか早い方のRTPセッションの終了、または2つのバースト間の時間の（c）の期間のいずれかです。
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のパケットが続かなければならない性質を有しています。 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.
それは良好な品質（すなわち、低いパケット損失率、損失したパケット間の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:
例えば、1は、受信したパケット、0失われたパケットを表し、64個のパケットをカバーする次のパターンに破棄パケットをX：
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.
パケット間隔が10msであり、Gminの値が16の推奨値である場合、バースト持続時間は120ミリ秒、バースト密度0.33、ギャップ継続時間230ミリ秒+ 290ミリ秒= 520ミリ秒、ギャップ密度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
4％バースト持続時間120ミリ秒のギャップ持続時間520の値、ミリ秒単位の値に相当する33％のギャップ密度10に対応5％バースト密度84に対応し、5％の廃棄率12に対応する損失率12、
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データパケットの割合。この値は、フィールドの左端にバイナリ点を有する固定小数点数として表現されます。これは（255の最大値を制限し、256で除算した結果を乗算し、バースト期間内に予期されたパケットの総数でバースト期間内に（重複したパケットの破棄を除く）紛失または廃棄されたパケットの合計数を割ることによって算出されます）オーバーフローを回避し、整数部を取っています。このフィールドは、取り込まなければならなくて、パケットが受信されていない場合はゼロに設定しなければなりません。
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データパケットの割合。値は、フィールドの左端にバイナリ点を有する固定小数点数として表現されます。これは（255の最大値を制限し、256で除算した結果を乗算し、ギャップ期間内に予期されたパケットの総数でギャップ期間内（重複パケットを破棄する除く）紛失または廃棄されたパケットの合計数を割ることによって算出されます）オーバーフローを回避し、整数部を取っています。このフィールドは、取り込まなければならなくて、パケットが受信されていない場合はゼロに設定しなければなりません。
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ビットの平均持続時間は、受信の開始以降に発生したギャップ期間の、ミリ秒単位で表しました。各期間の持続時間は、後続のバーストの開始を示す前のバーストとパケットの終了を示すパケットに基づいて計算されます。これは、後続のバーストパケットのタイムスタンプ、マイナス先行バーストパケットのタイムスタンプに加え、前のバーストパケットの持続時間に等しいです。実際の値が入手できない場合は、推定値を使用しなければなりません。受信の開始時に生じるギャップの場合には、前のバーストパケットのタイムスタンプと前バーストパケットの持続時間の合計は、受信開始時間によって置換されています。受信端で生じるギャップの場合には、後続のバーストパケットのタイムスタンプは、受信終了時刻に置き換えられています。隙間期間がなかった場合は、ギャップ継続時間値はゼロでなければなりません。
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、デインターリーブ、逆多重化、ジッタバッファ）との間のインターフェースです。 RTPの一部とみなさ遅延が報告されるRTPを多重化による遅延がUDPフレーム内のフレームに対し、例えば、起因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インタフェース間の最も最近に計算ラウンドトリップ時間は、ミリ秒単位で表しました。この値は、RTCP、ミリ秒単位、あるいは他のアプローチにNTPタイムスタンプ値から測定単位を変換する必要があり、この文書のセクション4.5で定義されたDLRR法を用いて測定することができます。 RTCPが使用されている場合には、報告された遅延値はソースSSRCからの最も最近のRTCPパケットの受信時刻、マイナスLSR（最後のSR）そのSR（送信者レポート）で報告された時、マイナス最後のSR以降DLSR（遅延あり）その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ビット最も最近の推定エンドシステム遅延は、ミリ秒単位で表しました。エンドシステム遅延は、送信方向及びジッターバッファ、復号化、および受信方向に関連付けられたプレイアウトバッファ遅延に関連した全試料の蓄積および符号化遅延の合計として定義されます。この遅延は、推定または測定することができます。この値は、すべての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セグメント遅延は往復とエンドシステム遅延から計算することができる一つの方法であることに注意してください。往復遅延が示されている場合、2つのエンドポイントに関連付けられたRTDとエンドシステム遅延は、次いで、ESD（A）およびESD（B）です。
one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2
一方向対称音声パス遅延=（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トークスパートパワー（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.
ノイズレベル：ノイズレベルが0 dBm0で参照するサイレント期間のバックグラウンドノイズレベルの比として定義される8ビットは、2の補数形式で符号付き整数としてデシベル単位で表さ。
noise level = 10 Log10 ( rms silence power (mW) )
ノイズレベル= 10をLog10（RMS沈黙パワー（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エンドシステムのエコーキャンセラにより直接測定してもよいし、エコーリターンロス（ERL）とエコーリターンロスエンハンスメント報告（ERLE）の値を加算することによって推定することができますエコーキャンセラによります。
RERL(dB) = ERL (dB) + ERLE (dB)
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.
VoIPゲートウェイの場合には、エコーの発生源は、典型的には、ネットワークにおける2-4線変換点で生じるラインエコーです。この8-12 dBの範囲内とすることができます。ラインエコーキャンセラ30デシベル以上のERLEを提供し、したがってデシベル40-50にこれを低減することができます。 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.
- 回路に接続されたIPゲートウェイは、2ワイヤループを有するネットワークを切り替えます。 12デシベルのエコーキャンセルせず、典型的な2-4ワイヤコンバータERL。 RERL = ERL + ERLE = 12 + 0 = 12デシベル。
- 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.
- 回路に接続されたIPゲートウェイは、2ワイヤループを有するネットワークを切り替えます。 30デシベルでエコー向上エコーキャンセラ付き。 RERL = ERL + ERLE = 12 + 30 = 42デシベル。
- 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デシベル。
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:
我々は、AとしてのVoIP経路及びBとしてリモートエンドのローカルエンドを示している場合、送信者のラウドネス定格（SLR）と受信ラウドネス定格（RLR）は（それぞれデフォルト値8デシベル2 dB）のために知られている場合、端部A（話者エコーラウドネス評価又はTELR）で、次いでエコーラウドネスレベルによって与えられます。
TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
TELR（A）は、SRL（A）+ ERL（B）+ ERLE（B）+ RLR（A）を=
TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)
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接続の終了時に音声品質推定値にエコーを組み込むために、このようなRTCP XRようなフォーマットを使用してBからERL + ERLE値を送信することが望ましいです。
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デシベル。
- PC softphone or speakerphone: extremely variable, consider reporting "undefined" (127).
- PCのソフトフォンやスピーカーフォン：非常に変数、（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デシベル）または（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セッションを介して行われるコールのセグメントを記述する音声品質メトリックです。これは使用不可と見なさ「トール品質」に対応する94の値50以下の値で、0から100の範囲の整数として表現されます。このメトリックは、[3] ITU-T G.107と一致する遅延の影響、[6]、ETSI TS 101 329から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.
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]、及びボイスオーバー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.
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
R合計= RTP R因子+ EXT。 Rファクター - 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：品質（MOS-LQ）を聴取するための8ビットの推定平均オピニオン評点5は優れた表し、1が容認できない表す、1から5までのスケール上の音声品質メトリックです。このメトリックは、遅延の影響を含むと品質（ACR）テストリスニングから得られたMOSスコアと比較することができないと定義されます。それは、例えばMOSのX 10に対応し、10〜50の範囲の整数として表現され、35の値が3.5の推定MOSスコアに対応します。
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.
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）の推定平均オピニオンスコアは通話品質に影響を与えるディレイなどのエフェクトの効果を含むものとして定義されます。メトリックは、[3] G.107で指定された式を用いて推定MOSに[6]またはETSI TS 101 329から5 ITU-T G.107に従って決定R因子を変換することによって計算することができます。これは、MOSに対応し、10〜50の範囲の整数として表現MOS-LQと同様に、10×されます。
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.
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.
ジッタバッファ適応（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）。これは、適応モードにおいて、ジッタバッファの実装固有の調整率を表します。このパラメータは、完全にそのような100ミリ秒〜30ミリ秒からピーク・ジッタのピークのステップ変化に適応するのに要するおおよその時間で定義されています。
adjustment time = 2 * J * frame size (ms)
調整時間= 2 * Jの*フレームサイズ（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.
このパラメータは、適応ジッタバッファの「攻撃性」の程度にガイドを提供することのみを意図していると推定することができます。 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ビットこれは破棄されないであろう最も早く到着したパケットに対応するミリ秒で現在の最大ジッタバッファ遅延です。単純なキューの実装では、これは、公称サイズに対応してもよいです。適応ジッタバッファの実装では、この値は、動的に（下記参照）JB絶対最大まで変化してもよいです。このパラメータは、固定および適応ジッタバッファ実装の両方のために提供されなければなりません。
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絶対最大）：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）[4] SDPを利用するアプリケーションで使用することができるXRブロックのためのシグナリングを定義します。このシグナリングは、どちらかのSDPオファー/アンサーモデルを実装するアプリケーションによって使用されるように定義された[8]又はセッションアナウンスメントプロトコル（SAP）などのプロトコルに関連して媒体搬送構成を説明するためにSDPを使用するアプリケーションによって[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の使用は任意でよいが使用される場合、ここで定義されるように、それを使用しなければならない、ことに留意されたいです。 SDPシグナリングはXRブロックは唯一の参加者の一部の割合によって実現されている環境で使用されている場合は、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ブロックを使用する必要があることをメディアセッションの参加者を知らせるために使用することができる1つの新しい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属性が増補バッカス - ナウアフォーム（ABNF）で以下に定義されている[2]。これはセッションとメディアレベル属性の両方です。セッション・レベルで指定された場合は、セッション内のすべてのメディアのレベルのブロックに適用されます。一つはそのメディアブロックについて、存在する場合、任意のメディアレベル仕様は、セッション・レベルの仕様を交換する必要があります。
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
RTCP-XR-ATTRIB = "A =" "RTCP-XR" "：" [XR-フォーマット*（SPのXR-フォーマット）] CRLF
xr-format = pkt-loss-rle / pkt-dup-rle / pkt-rcpt-times / rcvr-rtt / stat-summary / voip-metrics / format-ext
XR-FORMAT = PKT-損失RLE / PKT-DUP-RLE / PKT-RCPT回/ RCVR-RTT / STAT-要約/ VoIPのメトリック/フォーマット-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
PKT-損失RLE = "PKT-損失RLE" [ "=" 最大サイズ] PKT-DUP-RLE = "PKT-DUP-RLE" [ "=" 最大サイズ] PKT-RCPT倍=「PKT -rcpt倍 "[ "=" 最大サイズ] RCVR-RTT = "RCVR-RTT" "=" RCVR-RTTモード[ "：" 最大サイズ] RCVR-RTTモード= "すべて"/" 送信者"STAT-要約= "STAT-要約"[" = "STAT-フラグ*（"、」STAT-フラグ）] STAT-フラグ= "喪失" / "DUP" / "jitt" / "TTL" / "HL" VoIPの-メトリック= "のVoIP-メトリクス" 最大サイズ= 1 * DIGIT。オクテットDIGIT =％x30-39フォーマット-EXT =非WS-ストリングの最大ブロックサイズ
non-ws-string = 1*(%x21-FF) CRLF = %d13.10
非WS-列= 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」属性が0個、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節）を送信します。このブロックを受けた参加者は、受信機がその参加者へのRTTを計算することができ、対応してDLRRレポート・ブロック（4.5節）を送信します。この例が示すように、コラボレーション機能は、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-損失RLE"、 "PKT-DUP-RLE"、および "PKT-RCPT倍" パラメータは、整数値を指定することができます。この値は、レポート全体のブロックはオクテットで持っているべきで最大の大きさを示しています。これは、ターゲット・サイズを満たすために、必要に応じて間伐を適用しなければならないことを示す指標として見なければなりません。
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-要約」パラメータが送信された統計サマリレポートブロックに含まれるべきフィールドを示すリストが含まれています。リストは、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」の存在は、対応するフラグが「HL」の存在は、対応するフラグが指標「TTL」と「HL」と一緒に合図してはいけません2に設定されるべきであることを示す1に設定されるべきであることを示しています。
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.
共同カテゴリは、現在唯一の機能、RTPデータ受信機、すなわちRTT測定機構から成ります。レシーバのリファレンス・タイムレポート・ブロックとDLRRレポート・ブロックの集合的な機能は、「RCVR-RTT」パラメータで表されます。このパラメータは、必要に応じて、DLRRレポートブロックの最大サイズを引数として、モード値を取り。モード値は「すべて」モード値「送信者が」唯一のアクティブなRTPの送信者は、すなわち、非RTPの送信者がDLRRブロックを送信してはならない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制御セッション内のアプリケーションは、それが送信する再INVITEメッセージに該当するすべてのSDPパラメータを除去することによって、すべての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.
「sendonlyで」についてと「のsendrecv」のメディアストリームがそれは一方的な「RTCP-XR」属性パラメータを指定しています、回答が対応する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.
協力的なパラメタのオファー側が応答を送信する必要があり、ルールには例外があります。例えば、共同のパラメータは、オファーを除くモードを指定するかもしれません。または、輻輳制御または最大伝送ユニットの考慮事項は、オファーの応答に対してmilitateかもしれません。
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.
その答えで協力的パラメータを含むことによって、回答はイニシエータを受信すると応答を送信するためにその能力を宣言します。オファー側は、回答が応答と返信先となるイニシエータを送るかもしれません。協力的パラメータの提供については、回答が返信すべき規則の例外があります。
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]を介して発表、またはリアルタイムストリーミングプロトコル（RTSP）[17]を介してストリーミングされたマルチメディアセッションのために、例えば、オファー/アンサー・コンテキストの外で使用することができます。送信者がパラメータをネゴシエートしないようシグナリング・モデルは、簡単ですが、「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（Internet Assigned Numbers Authority）のレジストリ内、新しいRTCPパケットタイプ、拡張レポート（XR）タイプを定義します。 RTCP XRブロックタイプのレジストリ：この文書は、新しいIANAレジストリを定義します。この新しいレジストリ内では、この文書では、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
この文書では、256個の値を許可するBTフィールドは8ビットが含まれている第3節で指定された拡張レポートブロックタイプ（BT）フィールドの名前空間をカバーするためにRTCP XRブロックタイプレジストリと呼ばれるIANAレジストリを作成します。 RTCP XRブロックタイプレジストリは、の仕様が必要ポリシーに従ってIANAによって管理されます
RFC 2434 [7]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document:
RFC 2434 [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.
- 少なくとも名前、住所、電子メールなどの登録を行う1、の連絡先情報。
- 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属性：
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ロング形式：属性名RTP制御プロトコルは、名前のレポートパラメータタイプを拡張：属性のATT-場の種類：文字セットに従うことをセッションとメディアレベル：なし目的：この文書値：このドキュメントのリファレンスのセクション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レジストリを作成します。 "PKT-損失RLE"、 "PKT-DUP-RLE"、 "PKT-RCPT-回"、 "STAT-概要"、 "VoIPのメトリック"、および「recv-：それはセクション5.1で定義された6つのパラメータが含まれています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.
- 少なくとも名前、住所、電子メールなどの登録を行う1、の連絡先情報。
- An Augmented Backus-Naur Form (ABNF) [2] definition of the parameter, in accordance with the "format-ext" definition of Section 5.1.
- 増補バッカス - ナウアフォーム（ABNF）セクション5.1の「フォーマット-EXT」の定義に応じて、パラメータの[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のメトリクスレポート・ブロックは、進行中の音声通話の品質に関する情報を提供します。そのような情報を標準形式でそれを利用可能にする、標準の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.アルゴリズム
A.1. Sequence Number Interpretation
A.1。シーケンス番号の解釈
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ビット空間における先行1の後ろのいずれかに配置され、以下の各パケット数）。
// 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) {
//その最も可能性の高い場所のため//ヒューリスティックに基づいて、32ビットのシーケンス番号空間に置き配列。 u_int32 extend_seq（CONST u_int16配列）{
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; }
// //は我々が与えられた16ビットの数に対応した32ビットのシーケンス番号のための最善の推測を返します。 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節）のためのバースト特性を測定するためのアルゴリズムです。正確さのために働いて実装に対して検証されたアルゴリズムは、[3] ETSI TS 101 329から5から再生されます。アルゴリズムは、ここで説明するように、最終的には将来の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への遷移では、このアプリケーションのために一般に十分である1の精度までカウント状態遷移の対のいずれかを推測することが可能です。
"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_discarded」「packet_lost」とは、この関数の結果、イベントが失われたり、パケットを廃棄し、呼び出されているかどうかを示すブール変数です。
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.
その見なさ指導のためのコリンパーキンス、スティーブCasner、およびヘニングSchulzrinneと;：私たちは、以下の方々に感謝します著者間の里親のコラボレーションを支援するためのスー・ムーン。 MLDAのレポートのニーズに我々の注意を描画するためのムニールBenzaid。 MLDAブロックの種類を組み込むために私たちを励ますためDorgham SisalemとアダムWolisz。そして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
ケビンAlmeroth、UCSBラモンカセレス、IBMリサーチアラン・クラーク、ロバート・G. Telchemyコール、JHU応用物理研究所ニックダッフィールド、AT＆T Labsのリサーチティムール・フリードマン、パリ6 Kaynamヘダーヤト、ブリックスネットワークカミルSarac、UTダラスマグヌスウェスター、エリクソン
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シグナリングに関する連絡する主要人物はマグヌスウェスターです。
References
リファレンス
Normative References
引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2]クロッカー、D.、エド。そして、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]ハンドレー、M.および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.ブラドナー、BCP 11、RFC 2028、1996年10月 "IETF標準化プロセスに関与する組織"。
[6] ITU-T, "The E-Model, a computational model for use in transmission planning", Recommendation G.107, January 2003.
[6] ITU-T、 "E-モデル、伝送計画で使用するための計算モデル"、勧告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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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.、フレデリック、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] TIA / EIA-810-PCMデジタル有線電話、2000年12月オーバーIPとボイスオーバー狭帯域音声の伝送要件。
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]アダムス、A.、Buは、T.、カセレス、R.、ダフィールド、NG、フリードマン、T.、ホロウィッツ、J.、ロープレスティ、F.、月、SB、パクソン、V.およびD. Towsley 、「特徴付け内部ネットワークの動作のためのエンドツーエンドのマルチキャスト測定の使用」、IEEE通信誌、2000年5月。
[12] Baugher, McGrew, Oran, Blom, Carrara, Naslund and Norrman, "The Secure Real-time Transport Protocol", Work in Progress.
[12] Baugher、マグリュー、オラン、ブロム、カララ、NaslundとNorrman、「セキュアリアルタイムトランスポートプロトコル」が進行中で働いています。
[13] Caceres, R., Duffield, N.G. and T. Friedman, "Impromptu measurement infrastructures using RTP", Proc. IEEE Infocom 2002.
[13]カセレス、R.、ダフィールド、N.G.そして、T.フリードマン、「即興測定インフラストラクチャは、RTPを使用して」、PROC。 IEEEインフォコム2002。
[14] Clark, A.D., "Modeling the Effects of Burst Packet Loss and Recency on Subjective Voice Quality", Proc. IP Telephony Workshop 2001.
[14]クラーク、紀元、PROC「主観音声品質上のバーストパケット損失と新しさの影響をモデル化」。 IPテレフォニーワークショップ2001。
[15] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[15]ハンドレー、M.、パーキンス、C.およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[16] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
。[16]レイノルズ、J.、エド、 "番号が割り当てられ：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.とラオと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。 2000 IWQoS。
Authors' Addresses
著者のアドレス
Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106 USA
カリフォルニア州サンタバーバラのコンピュータサイエンス大学のケビン・Almeroth部門、CA 93106 USA
EMail: almeroth@cs.ucsb.edu
メールアドレス：almeroth@cs.ucsb.edu
Ramon Caceres IBM Research 19 Skyline Drive Hawthorne, NY 10532 USA
ラモン・カセレスIBMリサーチ19スカイラインドライブホーソーン、NY 10532 USA
EMail: caceres@watson.ibm.com
メールアドレス：caceres@watson.ibm.com
Alan Clark Telchemy Incorporated 3360 Martins Farm Road, Suite 200 Suwanee, GA 30024 USA
アラン・クラークTelchemy株式会社3360マルティンス農道、スイート200スワニー、GA 30024 USA
Phone: +1 770 614 6944 Fax: +1 770 614 3951 EMail: alan@telchemy.com
電話：+1 770 614 6944ファックス：+1 770 614 3951 Eメール：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
電話：+1 443 778 6951 Eメール：robert.cole@jhuapl.edu
Nick Duffield AT&T Labs-Research 180 Park Avenue, P.O. Box 971 Florham Park, NJ 07932-0971 USA
ニックダッフィールドAT＆T Labsのリサーチ180パークアベニュー、P。 971フローラムパーク、ニュージャージー州07932から0971 USA箱
Phone: +1 973 360 8726 Fax: +1 973 360 8050 EMail: duffield@research.att.com
電話：+1 973 360 8726ファックス：+1 973 360 8050 Eメール：duffield@research.att.com
Timur Friedman Universite Pierre et Marie Curie (Paris 6) Laboratoire LiP6-CNRS 8, rue du Capitaine Scott 75015 PARIS France
ティムールフリードマン大学ピエール・マリー・キュリー（パリ6）研究所Lip6-CNRS 8、RUEデュCapitaineスコット75015パリフランス
Phone: +33 1 44 27 71 06 Fax: +33 1 44 27 74 95 EMail: timur.friedman@lip6.fr
電話：+33 1 44 27 71 06ファックス：+33 1 44 27 74 95 Eメール：timur.friedman@lip6.fr
Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA
Kaynamヘダーヤトブリックスネットワーク285ミルロードチェルムズフォード、MA 01824 USA
Phone: +1 978 367 5600 Fax: +1 978 367 5700 EMail: khedayat@brixnet.com
電話：+1 978 367 5600ファックス：+1 978 367 5700 Eメール：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
コンピュータサイエンスのカミルSarac部門（ES 4.207）リチャードソンのテキサスのエンジニアリングコンピュータサイエンス大学のエリック・ヨンソン学校、TX 75083から0688 USA
Phone: +1 972 883 2337 Fax: +1 972 883 2349 EMail: ksarac@utdallas.edu
電話：+1 972 883 2337ファックス：+1 972 883 2349 Eメール：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
電話：+46 8 404 82 87ファックス：+46 8 757 55 50 Eメール：magnus.westerlund@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。