RFC3611 日本語訳
3611 RTP Control Protocol Extended Reports (RTCP XR). T. Friedman,Ed., R. Caceres, Ed., A. Clark, Ed.. November 2003. (Format: TXT=126736 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループのT.フリードマン、エドをネットワークでつないでください。コメントのために以下を要求してください。 3611 パリ6カテゴリ: エド標準化過程R.カセレス、エドIBMの研究A.クラーク、Telchemy2003年11月
RTP Control Protocol Extended Reports (RTCP XR)
RTP制御プロトコルはレポートを広げました。(RTCP XR)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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 Controlプロトコル(RTCP)のためにExtended Report(XR)パケットタイプを定義して、Session記述プロトコル(SDP)を使うならアプリケーションでどうXRパケットの使用に合図できるかを定義します。 XRパケットはレポートブロックで構成されます、そして、7人のゴシック体がここで定義されます。 広げることの書式を報告する目的は情報を伝達するために、それがRTCPのSender Report(SR)とReceiver Report(RR)パケットによって使用されるレポートブロックに保管されている6つの統計を補うということです。 ネットワークの特性のマルチキャスト推論などのいくつかの応用(ミンツ)かIP(VoIP)モニターの上の声が他の、そして、より詳細な統計を必要とします。 ここで定義されたゴシック体に加えて、追加ゴシック体は、将来、このドキュメントが提供するフレームワークを固く守ることによって、定義されるかもしれません。
Friedman, et al. Standards Track [Page 1] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 適用性。 . . . . . . . . . . . . . . . . . . . . . 4 1.2. 用語。 . . . . . . . . . . . . . . . . . . . . . . 7 2. XRパケット・フォーマット. . . . . . . . . . . . . . . . . . . . . . . 7 3。 拡張レポートブロックフレームワーク。 . . . . . . . . . . . . . . . 8 4. 拡張レポートは.94.1を妨げます。 損失RLEはブロックを報告します。 . . . . . . . . . . . . . . . . . 9 4.1.1. ランレングス塊. . . . . . . . . . . . . . . . 15 4.1.2。 ベクトル塊. . . . . . . . . . . . . . . . 15 4.1.3に噛み付きました。 ヌル塊. . . . . . . . . . . . . 16 4.2を終えます。 RLEレポートブロック. . . . . . . . . . . . . . . 16 4.3をコピーしてください。 パケット領収書回数はブロックを報告します。 . . . . . . . . . . . 18 4.4. 受信機参照時間レポートブロック. . . . . . . . . . 20 4.5。 DLRRはブロックを報告します。 . . . . . . . . . . . . . . . . . . . 21 4.6. 統計概要はブロックを報告します。 . . . . . . . . . . . . 22 4.7. VoIP測定基準はブロックを報告します。 . . . . . . . . . . . . . . . 25 4.7.1. パケット損失と破棄測定基準 . . . . . . . . 27 4.7.2. 測定基準を押し破いてください。 . . . . . . . . . . . . . . . . . 27 4.7.3. 測定基準を遅らせてください。 . . . . . . . . . . . . . . . . . 30 4.7.4. 関連測定基準. . . . . . . . . . . . . 31 4.7.5に合図してください。 .6に品質かトランスミッション品質測定基準. . 33 4.7に電話をしてください。 設定パラメータ. . . . . . . . . . . . 34 4.7.7。 ジターバッファパラメタ. . . . . . . . . . . . 36 5。 SDPシグナリング。 . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1. SDP属性。 . . . . . . . . . . . . . . . . . . . 37 5.2. 申し出/答えにおける用法。 . . . . . . . . . . . . . . . . . 40 5.3. 申し出/答えにおける外の用法。 . . . . . . . . . . . . . 42 6. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 42 6.1. XRパケットタイプ. . . . . . . . . . . . . . . . . . . . . 42 6.2。 RTCP XRはタイプ登録を妨げます。 . . . . . . . . . . . . . . 42 6.3. "rtcp-xr"SDP属性。 . . . . . . . . . . . . . . 43 7. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 44 A.アルゴリズム. . . . . . . . . . . . . . . . . . . . . . . . . . 46A.1。 一連番号解釈. . . . . . . . . . . . . 46A.2。 例はパケット損失計算を押し破きました。 . . . . . . . . . 47 知的所有権通知. . . . . . . . . . . . . . . . . . . 49承認。 . . . . . . . . . . . . . . . . . . . . . . . . . 50人の貢献者. . . . . . . . . . . . . . . . . . . . . . . . . . . 50参照. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51引用規格. . . . . . . . . . . . . . . . . . . . . . . 51の有益な参照. . . . . . . . . . . . . . . . . . . . . . 51作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 53の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 55
Friedman, et al. Standards Track [Page 2] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[2ページ]。
1. Introduction
1. 序論
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 Controlプロトコル(RTCP)[9]のためにExtended Report(XR)パケットタイプを定義して、Session記述プロトコル(SDP)[4]を使うならアプリケーションでどうXRパケットの使用に合図できるかを定義します。 XRパケットはRTCPの送付者レポート(SR)のレセプションレポートブロックに既に保管されていたそれかReceiver Report(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.
定義はIntroductionに続く3つのセクションの上に広げられています。 セクション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パケットに関するレポートから成ります。 2番目のカテゴリにおけるレポートは参照時間情報をRTP関係者の間に伝えます。 現実に概要ですが、より詳細であるか、または異なったタイプの概要です、3番目のカテゴリでは、レポートがパケット領収書に関連する測定基準を伝えて、既存のRTCPパケットを運ばれたそれより伝えます。
All told, seven report block formats are defined by this document. Of these, three are packet-by-packet block types:
全部で、7つのレポートブロックフォーマットがこのドキュメントによって定義されます。 これらでは、パケットごとの3はゴシック体です:
- Loss RLE Report Block (Section 4.1): Run length encoding of
reports concerning the losses and receipts of RTP packets.
- 損失RLEはブロック(セクション4.1)を報告します: 損失に関するレポートのランレングスコード化とRTPパケットの領収書。
- Duplicate RLE Report Block (Section 4.2): Run length encoding of
reports concerning duplicates of received RTP packets.
- RLEレポートブロック(セクション4.2)をコピーしてください: 容認されたRTPパケットの写しに関するレポートのランレングスコード化。
- Packet Receipt Times Report Block (Section 4.3): A list of
reception timestamps of RTP packets.
- パケット領収書回数はブロック(セクション4.3)を報告します: RTPパケットに関するレセプションタイムスタンプのリスト。
There are two reference time related block types:
2参照時間関連するゴシック体がいます:
- Receiver Reference Time Report Block (Section 4.4): Receiver-end
wallclock timestamps. Together with the DLRR Report Block
mentioned next, these allow non-senders to calculate round-trip
times.
- 受信機参照時間レポートブロック(セクション4.4): 受信端末wallclockタイムスタンプ。 次に言及されたDLRR Report Blockと共に非送付者はこれらで往復の回について計算できます。
Friedman, et al. Standards Track [Page 3] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[3ページ]。
- 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)を報告します: 最後のReceiver Reference Time Report Block以来の遅れを受け取りました。 Receiver Reference Time Report Blockを受け取るRTPデータ送付者はDLRR Report Blockと共に応じることができます、大体同じようなやり方で送付者のNTPタイムスタンプを受け取るRTPデータ受信装置がRTCP[9、セクション6.3.1]のために既に定義されたメカニズムで1つの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かHop Limit値。
- 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)、あれほど、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)を示すことができるかを説明します。 ドキュメントはインターネットAssigned民数記Authority(IANA)、セキュリティ問題(セクション7)、およびどうテキストで議論したアルゴリズムを実装するかに関する例を提供する付録で問題に付番する議論(セクション6)で締めくくります。
1.1. Applicability
1.1. 適用性
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送付者かReceiver Reports[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つの音声アプリケーションにもブロックを適用できると報告します。 4.7に.5を)区分してください、R要素を含んでいて。会話の測定基準の使用、((Modelが会話の品質(MOS-CQ)のために[3])と平均である意見スコアで定義したEによって説明される純真な2パーティー以外のアプリケーションでは、呼び出しは定義されません。 したがって、これらの測定基準はマルチキャスト会議アプリケーションで入手できないとして特定されるべきです。
Friedman, et al. Standards Track [Page 4] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[4ページ]。
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.
パケットごとのレポートゴシック体(Loss RLE(セクション4.1)、Duplicate RLE(セクション4.2)、およびPacket Receiptタイムズ(セクション4.3))は、念頭でネットワークの特性(ミンツ)の[11]のマルチキャスト推論などのネットワーク断層エックス線撮影応用で定義されました。 ミンツは、マルチキャスト分配木の総計の構造と経路に適用される損失率や遅れなどのパラメタを推論するためにその木の分岐ポイントの間でマルチキャストセッション受信機から詳細なパケット領収書跡を必要とします。
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.
どんなリアルタイムのマルチキャストマルチメディア応用もパケットによるパケットレポートゴシック体を使用できます。 そのようなアプリケーションはマルチキャスト木のトポロジー情報をそれに提供するミンツ推論サブシステムを使うかもしれません。 そのようなサブシステムの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.
また、ひたむきなネットワーク監視用途でパケットごとのレポートブロックを使用できます。 そのようなアプリケーションに、5%以上のRTPデータ帯域幅がRTCPパケットに使用されるのを許容するのは適切であるかもしれません、その結果、比例して、より大きくて、より詳細なレポートブロックを許します。
Nothing in the packet-by-packet block types restricts their use to multicast applications. In particular, they could be used for network tomography similar to MINC, but using striped unicast packets instead. In addition, if it were found useful, they could be used for applications limited to two participants.
パケットごとのゴシック体の何も彼らの使用をマルチキャストアプリケーションに制限しません。 彼らは、特に、ミンツと同様のネットワーク断層エックス線撮影に使用されますが、代わりにストライプのユニキャストパケットを使用しているかもしれません。 さらに、それが役に立つのがわかるなら、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
パケットごとのレポートがすぐに合っていない1つの使用がパケット「再-トランスミッション」メカニズムの一部としてデータ・パケット承認のためのものです。 理由はこれらのブロック示されたパケット会計技術が通常、RTPによって使われたパケット会計と異なっているということです。 測定を支持します。
Friedman, et al. Standards Track [Page 5] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[5ページ]。
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.
アプリケーション、取り組みは少しがデータ受信装置で可能であると解釈して、レポートブロックを受け取る関係者に解釈をできるだけ任せるのが作られています。 このようにして、例えば、変則的な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.
また、Statistics Summary Report Block(セクション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]を基礎づけました。 送付者への自分達の周遊旅行時代であり、彼らが受信機を助けると見込むためにデータ受信装置を許容することによって、それらが要求するべきである川下の帯域幅を見積もってください。 あらゆる受信機がReceiver Reference Time Report Blocks(セクション4.4)を送るつもりであるなら、送付者が潜在的に、間隔を報告する中でRTCPパケットが送付者に到着した受信機の数と等しい多くのDLRR Report Blocks(セクション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.
シグナリングが定義したSDPは3でそうこのドキュメント(セクション5)のXRパケットをしたので、念頭でシナリオを使用します: レアルTime Streamingプロトコル(RTSP)はストリーミング・アプリケーション、高められたフィードバックがあるコース講演などの多くへの1つのマルチキャストマルチメディア応用、および2回のパーティーにかかわるSession Initiationプロトコル(SIP)の制御会話のセッションを制御しました。 SDPを使うアプリケーションはここにカバーされなかったケースに無料で追加SDPシグナリングを使用できます。 さらに、アプリケーションは無料でSDP以外のシグナル伝達機構を使用できます。
Friedman, et al. Standards Track [Page 6] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[6ページ]。
1.2. Terminology
1.2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[1]という本書ではことであり、この仕様への承諾ために要件レベルを示すべきであるかをさせましょう。
2. XR Packet Format
2. XRパケット・フォーマット
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パケットは数があとに続いた32ビットの単語がことによると合っているゼロ2歳のヘッダー、拡張レポートブロックから成ります。 このタイプのパケットは他のRTCPパケットと一致した方法で広げられます、不可欠のバージョン、パケットタイプ、および長さの情報に関しては。 XRパケットが、後方にその結果、長さの情報を使用することでそれらを認識しませんが、過去のそれらを分析できるべきであるRTCP受信機実装と互換性があった状態であります。 また、それらが他のRTCPパケットで見えるのと同じ位置に詰め物野原とSSRC野原を提供します、簡単さのために。 形式は以下の通りです:
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|予約されます。| PTはXR=207と等しいです。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ブロックを報告してください: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
version (V): 2 bits
Identifies the version of RTP. This specification applies to
RTP version two.
バージョン(V): 2ビットのIdentifies、RTPのバージョン。 この仕様はRTPバージョンtwoに適用されます。
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ビットのIfは用意ができて、このXRパケットは終わりにいくつかの追加詰め物八重奏を含みます。 この分野の意味論はSRパケットの詰め物分野の意味論と同じです、RTP仕様で定義されるように。
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.
予約される: Thisがさばく5ビットは今後の定義のために予約されます。 そのような定義がないとき、この分野のビットをゼロに設定しなければならなくて、受信機で無視しなければなりません。
Friedman, et al. Standards Track [Page 7] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[7ページ]。
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.
パケットタイプ(太平洋標準時の): 8ビットのContains、これがRTCP XRパケットであると認識する一定の207。 この値はセクション6.1で説明されるようにインターネットAssigned民数記Authorityに示されます(IANA)。
length: 16 bits
As described for the RTCP Sender Report (SR) packet (see
Section 6.4.1 of the RTP specification [9]). Briefly, the
length of this XR packet in 32-bit words minus one, including
the header and any padding.
長さ: 16ビットのAsはRTCP Sender Reportのために(SR)パケットについて説明しました。(.1のセクション6.4RTP仕様[9])を見てください。 簡潔に、32ビットのこのXRパケットの長さはヘッダーとどんな詰め物も含むマイナス1つを言い表します。
SSRC: 32 bits
The synchronization source identifier for the originator of
this XR packet.
SSRC: 32ビット、同期はこのXRパケットの生成元のために識別子の出典を明示します。
report blocks: variable length.
Zero or more extended report blocks. In keeping with the
extended report block framework defined below, each block MUST
consist of one or more 32-bit words.
ブロックを報告してください: 可変長。 ゼロか以上がレポートブロックを広げました。 拡張レポートブロックフレームワークが以下で定義されている状態で保つ際に、各ブロックは1つ以上の32ビットの単語から成らなければなりません。
3. Extended Report Block Framework
3. 拡張レポートブロックフレームワーク
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ特有です。| ブロック長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : タイプ特有のブロックコンテンツ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットのIdentifies。 7人のゴシック体がセクション4で定義されます。 追加ゴシック体は将来の仕様に基づき定義されるかもしれません。 このフィールドの名前スペースはセクション6.2で説明されるようにインターネットAssigned民数記Authority(IANA)によって管理されます。
Friedman, et al. Standards Track [Page 8] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[8ページ]。
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ビットにおけるヘッダーを含むこのレポートブロックの長さの16ビットはマイナスものを言い表します。 ブロック型定義が可能にするなら、ゼロは許容値です、成るタイプ特有の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ビットの倍数であるに違いないという規制を条件として特定のゴシック体によって定義されます。 ブロック型定義が可能にするなら、Itは長さゼロ・ビットであるかもしれません。
4. Extended Report Blocks
4. 拡張レポートブロック
This section defines seven extended report blocks: block types for reporting upon received packet losses and duplicates, packet reception times, receiver reference time information, receiver inter-report delays, detailed reception statistics, and voice over IP (VoIP) metrics. An implementation SHOULD ignore incoming blocks with types not relevant or unknown to it. Additional block types MUST be registered with the Internet Assigned Numbers Authority (IANA) [16], as described in Section 6.2.
このセクションは7つの拡張レポートブロックを定義します: パケット損失と写し、パケットレセプション回数、受信機参照時間情報、延着して、詳しく述べられた受信機相互レポートの容認されたレセプション統計について報告するためのタイプ、およびIP(VoIP)測定基準の上の声を妨げてください。 実装SHOULDはそれにおける、関連していないか未知でないタイプに従った入って来るブロックを無視します。 セクション6.2で説明されるようにインターネットAssigned民数記Authority(IANA)[16]に追加ゴシック体を示さなければなりません。
4.1. Loss RLE Report Block
4.1. 損失RLEレポートブロック
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.
このゴシック体は独特のパケット領収書と損失イベントの詳細な報告を可能にします。 例えば、ネットワークの特性(ミンツ)の[11]のマルチキャスト推論にそのようなレポートを使用できます。 ミンツと共に、人がその木の中のリンクに沿ってソースの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
Loss RLE Report Blockを生成する関係者は可能であるときはいつも、それらのイベントの解釈の上で観測されたイベントに関して報告する際に精度を支持するべきです。 解釈はレポートブロックを観測する人に任せるべきです。 このアプローチに続くと、それは含意されます。
Friedman, et al. Standards Track [Page 9] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[9ページ]。
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.
Loss RLE Report Blocksのための会計はパケットが以下の2つの領域のRTP仕様[9]で説明したSRとRRの世代のために会計と異なるでしょう: 1送付者あたりの会計学と1パケットあたりの会計。
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.
1送付者あたりの会計、関与しているSHOULD NOTが敷居の最小の番号のRTPパケットの領収書をそれらのパケットの送付者について報告するための状態にするRTPセッションのときに。 この会計技術は送付者が有効であると考えられるかどうか敷居を決定するRTP仕様のセクション6.2の.1とAppendix 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.
1パケットあたりの会計、関与しているSHOULDが有効であるとしてすべての一連番号を扱うRTPセッションのときに。 この会計技術は一連番号が以前に容認されたパケットの一連番号がある接触に基づいて有効であるか、または無効であると裁決するのを示すRTP仕様のAppendix A.1で説明されたテクニックと異なっています。
Sender validity and sequence number validity are interpretations of the raw data. Such interpretations are justified in the interest, for example, of excluding the stray old packet from an unrelated session from having an effect upon the calculation of the RTCP transmission interval. The presence of stray packets might, on the other hand, be of interest to a network monitoring application.
送付者の正当性と一連番号の正当性は生データの解釈です。 そのような解釈は例えばRTCPトランスミッション間隔の計算に影響を与えるのからの関係ないセッションに迷っている古いパケットを入れないようにする利益のためで正当化されます。 他方では、迷っているパケットの存在はネットワーク監視用途に興味があるかもしれません。
One accounting interpretation that is still necessary is for a participant to decide whether the 16 bit sequence number has rolled over. Under ordinary circumstances this is not a difficult task. For example, if packet number 65,535 (the highest possible sequence number) is followed shortly by packet number 0, it is reasonable to assume that there has been a rollover. However, it is possible that the packet is an earlier one (from 65,535 packets earlier). It is also possible that the sequence numbers have rolled over multiple times, either forward or backward. The interpretation becomes more difficult when there are large gaps between the sequence numbers, even accounting for rollover, and when there are long intervals between received packets.
1つのまだ必要な会計解釈は関係者が、16ビットの一連番号がひっくり返ったかどうか決めることです。当たり前ならこれは厄介な問題ではありません。 例えば、すぐパケットNo.0がパケットNo.65,535(可能な限り高い一連番号)のあとに続いているなら、ロールオーバーがあったと仮定するのは妥当です。しかしながら、パケットが以前のものであることが可能である、(6万5535のパケット前、) また、一連番号が複数の回に、前向きか後方にひっくり返ったのも、可能です。 一連番号の間に大穴があるとき、解釈は、より難しくなります、ロールオーバーといつ、容認されたパケットの間には、長い間隔があるか間、説明さえして。
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.
ここで強制された1パケットあたりの会計技術は関係者がごく最近送付者から受け取られたパケットの一連番号の動向をおさえることです。 その送付者から到着する次のパケットに関しては、先の秋の3万2768未満パケット、または、最新のものの後ろで一連番号を判断しなければなりません、それをより近くに置くどの選択。 両方の選択が等しくよそよそしい場合(可能なだけの距離が3万2768であるなら)、選択はロールオーバーを必要としないものであるに違いありません。付録A.1はこのテクニックを実行するアルゴリズムを提示します。
Friedman, et al. Standards Track [Page 10] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[10ページ]。
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.
一連番号巻きつけて着るドレスのために、終わりの一連番号が始めの一連番号より少ないかもしれないことに注意してください。 一連番号スペースで1つの範囲の6万5534以上について報告するのにLoss RLE Report Blockを使用してはいけません、複数の巻きつけて着るドレスを特定する手段が全くないとき。
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.
Loss RLEレポートによって説明された跡はブール値(跡の各一連番号あたり1つ)の系列から成ります。 1の値はパケット領収書を表します、一連番号の最新の巻きつけて着るドレス以来その一連番号を持っている1つ以上のパケットが受け取られていることを意味して(巻きつけて着るドレスでないならRTPセッションの始まりが起こったと判断されたので)。 ゼロの値はパケット損失(レポートの時現在、その一連番号のためのパケット領収書が全くなかった意味)を表します。 その一連番号のための損失のレポートの後に与えられた一連番号があるパケットを受け取るなら、後のLoss RLEレポートはその一連番号のためにパケット領収書を報告するかもしれません。
The encoding itself consists of a series of 16 bit units called chunks that describe sequences of packet receipts or losses in the trace. Each chunk either specifies a run length or a bit vector, or is a null chunk. A run length describes between 1 and 16,383 events that are all the same (either all receipts or all losses). A bit vector describes 15 events that may be mixed receipts and losses. A null chunk describes no events, and is used to round out the block to a 32 bit word boundary.
コード化自体は跡のパケット領収書か損失の系列について説明する塊と呼ばれる一連の16ビットのユニットから成ります。 各塊は、ランレングスかしばらくベクトルを指定するか、またはヌル塊です。 ランレングスは1〜1万6383回のちょうど同じ出来事(すべての領収書かすべての損失のどちらか)について説明します。 少し、ベクトルは複雑な領収書と損失であるかもしれない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:
塊の系列への無くなっていて容認されたパケットの系列からのマッピングは必ずユニークであるというわけではありません。 例えば、以下の跡は45のパケットを含んでいます:(そこでは、22番目と24番目が失われて、他のものは受信しました)。
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
Friedman, et al. Standards Track [Page 11] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[11ページ]。
One way to encode this would be:
これをコード化する1つの方法は以下の通りでしょう。
bit vector 1111 1111 1111 111
bit vector 1111 1101 0111 111
bit vector 1111 1111 1111 111
null chunk
111ビットの111ビットの噛み付いているベクトルのベクトル1111 1101 0111 1111 1111 1111ベクトル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
噛み付いているベクトル0101 1111 1111 111が走らせる9の21の領収書の走行はヌル塊を領収書を出させます。
The choice of encoding is left to the application. As part of this freedom of choice, applications MAY terminate a series of run length and bit vector chunks with a bit vector chunk that runs beyond the sequence number space described by the report block. For example, if the 44th packet in the same sequence was lost:
コード化の選択はアプリケーションに残されます。 この選択の自由の一部として、アプリケーションはレポートブロックによって説明された一連番号スペースを走るしばらくベクトル塊で一連のランレングスと噛み付いているベクトル塊を終えるかもしれません。 同じ系列における44番目のパケットが例えば失われたなら:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
This could be encoded as:
以下としてこれをコード化できました。
run of 21 receipts
bit vector 0101 1111 1111 111
bit vector 1111 1110 1000 000
null chunk
21の領収書の走行は111ビットのベクトル0101 1111 1111ベクトル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.
ランレングスのプラスの噛み付いているベクトル塊の数が変であるなら、ヌルパケットはLoss RLE Report Blockの端に現れなければなりません。 ヌル塊はいかなる他の文脈にも現れてはいけません。
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パケットで割合から帯域幅を容易に消費できるので、警告は送付Loss RLE Report Blocksで使用されるべきです。 ゴシック体はアプリケーションがレポートサイズを制限できる間引きと呼ばれるメカニズムを入れます。
Friedman, et al. Standards Track [Page 12] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[12ページ]。
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は0〜15を変えることができます。 Tがゼロであるなら、一連番号スペースのあらゆるパケットが報告されます。 Tが15であるなら、3万2768のパケット毎の1は報告されます。
Suppose that the trace just described begins at sequence number 13,821. The last sequence number in the trace is 13,865. If the trace were to be thinned with a thinning value of T=2, then the following sequence numbers would be reported upon: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. The thinned trace would be as follows:
ただ説明された跡が一連番号13,821で始まると仮定してください。 跡における最後の一連番号は1万3865です。 跡がT=2の間引き値で薄くされることになっているなら、以下の一連番号は報告されるでしょうに: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. 薄くされた跡は以下の通りでしょう:
1 1 1 1 1 0 1 1 1 1 0
1 1 1 1 1 0 1 1 1 1 0
This could be encoded as follows:
以下の通りこれをコード化できました:
bit vector 1111 1011 1100 000
null chunk
噛み付いているベクトル1111 1011 1100 000のヌル塊
The last four bits in the bit vector, representing sequence numbers 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are thus set to zero and are ignored by the receiver. With thinning, the loss of the 22nd packet goes unreported because its sequence number, 13,842, is not a multiple of four. Packet receipts for all sequence numbers that are not multiples of four also go unreported. However, in this example thinning has permitted the Loss RLE Report Block to be shortened by one 32 bit word.
一連番号1万3868、1万3872、1万3876、および13,880を表して、噛み付いているベクトルにおける最後の4ビットは、跡を超えて広がっていて、このようにしてゼロに設定されて、受信機によって無視されます。間引きで、一連番号(1万3842)が4の倍数でないので、22番目のパケットの損失は報告されずに終わります。 また、4の倍数でないすべての一連番号のためのパケット領収書は報告されずに終わります。 しかしながら、この例では、間引きは、Loss RLE Report Blockが1つ32の噛み付いている単語によって短くされることを許可しました。
Choice of the thinning value is left to the application.
間引き価値の選択はアプリケーションに残されます。
Friedman, et al. Standards Track [Page 13] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[13ページ]。
The Loss RLE Report Block has the following format:
Loss RLE Report Blockには、以下の形式があります:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| ブロック長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースのSSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _seqを始めてください。| 終わり_seq| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 塊1| 塊2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 塊n-1| 塊n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A Loss RLE Report Block is identified by the constant 1.
タイプ(BT)を妨げてください: 8ビットのA Loss RLE Report Blockは定数1によって特定されます。
rsvd.: 4 bits
This field is reserved for future definition. In the absence
of such definition, the bits in this field MUST be set to zero
and MUST be ignored by the receiver.
rsvd、: Thisがさばく4ビットは今後の定義のために予約されます。 そのような定義がないとき、この分野のビットをゼロに設定しなければならなくて、受信機で無視しなければなりません。
thinning (T): 4 bits
The amount of thinning performed on the sequence number space.
Only those packets with sequence numbers 0 mod 2^T are reported
on by this block. A value of 0 indicates that there is no
thinning, and all packets are reported on. The maximum
thinning is one packet in every 32,768 (amounting to two
packets within each 16-bit sequence space).
間引き(T): 間引きの量の4ビットは一連番号スペースに働きました。 一連番号0モッズ2^Tがいるそれらのパケットだけがこのブロックによってオンであると報告されます。 0の値は、薄くなってはいけないのを示します、そして、すべてのパケットがオンであると報告されます。 最大の間引きはあらゆる3万2768(それぞれの16ビットの系列スペースの中の2つのパケットに達する)で1つのパケットです。
block length: 16 bits
Defined in Section 3.
ブロック長: セクション3における16ビットのDefined。
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.
_seqを始めてください: 16ビット、これが妨げる最初の一連番号は報告します。オン。
end_seq: 16 bits
The last sequence number that this block reports on plus one.
_seqを終わらせてください: このブロックがプラス1に関して報告する最後の一連番号の16ビット。
Friedman, et al. Standards Track [Page 14] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[14ページ]。
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ビットのThereは3つの塊タイプです: 以下のセクションでヌルの、そして、定義されたランレングス、噛み付いているベクトル、および終わり。 塊がすべてゼロであるなら、それは終わりのヌル塊です。 さもなければ、大部分が噛み付いた塊の左はタイプを決定します: 0 ランレングスと噛み付いているベクトルのための1のために。
4.1.1. Run Length Chunk
4.1.1. ランレングス塊
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R| run length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R| ランレングス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit
A zero identifies this as a run length chunk.
塊タイプ(C): 1ビットAゼロは、これがランレングス塊であると認識します。
run type (R): 1 bit
Zero indicates a run of 0s. One indicates a run of 1s.
タイプ(R)は走ります: 1ビットのZeroは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.
ランレングス: 1と1万6383の間の14ビットのA値。 値はランレングス塊のためのゼロであるはずがありません(走行タイプとランレングス分野の両方のゼロは塊を終わりのヌル塊にするでしょう)。 また、しばらくベクトル塊の一部としてそれらを記述できたという事実にもかかわらず、15以下のランレングスはランレングス塊で説明されるかもしれません。
4.1.2. Bit Vector Chunk
4.1.2. 噛み付いているベクトル塊
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| bit vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| 噛み付いているベクトル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit
A one identifies this as a bit vector chunk.
塊タイプ(C): 1ビットA1は、これがしばらくベクトル塊であると認識します。
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ビット、ベクトルは左から右まで読まれます、一連番号を増加させることの順に(巻きつけて着るドレスのための適切な小遣いがある)。
Friedman, et al. Standards Track [Page 15] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[15ページ]。
4.1.3. Terminating Null Chunk
4.1.3. ヌル塊を終えます。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. Duplicate RLE Report Block
4.2. 写しRLEレポートブロック
This block type permits per-sequence-number reports on duplicates in a source's RTP packet stream. Such information can be used for network diagnosis, and provide an alternative to packet losses as a basis for multicast tree topology inference.
このゴシック体はソースのRTPパケットの流れにおける写しに関する1一連番号あたりのレポートを可能にします。 そのような情報は、マルチキャスト木のトポロジー推論の基礎としてネットワーク診断に使用されて、パケット損失への代替手段を提供できます。
The Duplicate RLE Report Block format is identical to the Loss RLE Report Block format. Only the interpretation is different, in that the information concerns packet duplicates rather than packet losses. The trace to be encoded in this case also consists of zeros and ones, but a zero here indicates the presence of duplicate packets for a given sequence number, whereas a one indicates that no duplicates were received.
Duplicate RLE Report Block形式はLoss RLE Report Block形式と同じです。 解釈だけが情報はパケット損失よりむしろパケット写しに関係があるという点において異なっています。 また、この場合コード化されるべき跡はゼロとものから成りますが、ここのゼロは与えられた一連番号のために写しパケットの存在を示しますが、人は、写しが全く受け取られなかったのを示します。
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.
与えられた一連番号のための写しの存在は全体の報告の期間にわたって決定しています。 例えば、他の一連番号がある他のパケットがあとに続いていて、パケットNo.12,593が到着するなら、別のパケットの報告時代に後での到着はその一連番号のための写しとして1万2593のカウントに付番しました。 写しはすぐその数の最初のパケットに生じる必要はありません。 注意しなければなりません一連番号スペースでaが1つの範囲の6万5534以上を報告するカバーでない。
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.
与えられた一連番号のために単一の写しパケットと複数の写しパケットの存在の間で区別を全くしません。 また、無くなっているパケットのための写しが全くないので損失がDuplicate RLE Report Blockの1つとしてコード化されることに注意してください。
Friedman, et al. Standards Track [Page 16] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[16ページ]。
The Duplicate RLE Report Block has the following format:
Duplicate RLE Report Blockには、以下の形式があります:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| ブロック長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースのSSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _seqを始めてください。| 終わり_seq| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 塊1| 塊2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 塊n-1| 塊n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A Duplicate RLE Report Block is identified by the constant 2.
タイプ(BT)を妨げてください: 8ビットのA Duplicate RLE Report Blockは一定の2時までに特定されます。
rsvd.: 4 bits
This field is reserved for future definition. In the absence
of such a definition, the bits in this field MUST be set to
zero and MUST be ignored by the receiver.
rsvd、: Thisがさばく4ビットは今後の定義のために予約されます。 そのような定義がないとき、この分野のビットをゼロに設定しなければならなくて、受信機で無視しなければなりません。
thinning (T): 4 bits
As defined in Section 4.1.
間引き(T): セクション4.1で定義された4ビットのAs。
block length: 16 bits
Defined in Section 3.
ブロック長: セクション3における16ビットのDefined。
SSRC of source: 32 bits
As defined in Section 4.1.
ソースのSSRC: セクション4.1で定義された32ビットのAs。
begin_seq: 16 bits
As defined in Section 4.1.
_seqを始めてください: セクション4.1で定義された16ビットのAs。
end_seq: 16 bits
As defined in Section 4.1.
_seqを終わらせてください: セクション4.1で定義された16ビットのAs。
chunk i: 16 bits
As defined in Section 4.1.
塊i: セクション4.1で定義された16ビットのAs。
Friedman, et al. Standards Track [Page 17] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[17ページ]。
4.3. Packet Receipt Times Report Block
4.3. パケット領収書回数はブロックを報告します。
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パケットの流れのためにパケット領収書回数に関する1一連番号あたりのレポートを可能にします。 ソースのRTPパケットを分配するのに使用されるマルチキャスト木のトポロジー、およびその木の中のリンクに沿った遅れのミンツの推論にそのような情報を使用できます。 また、部分的な経路特性を測定して、パケットジターのための配をモデル化するのにそれを使用できます。
Packet receipt times are expressed in the same units as in the RTP timestamps of data packets. This is so that, for each packet, one can establish both the send time and the receipt time in comparable terms. Note, however, that as an RTP sender ordinarily initializes its time to a value chosen at random, there can be no expectation that reported send and receipt times will differ by an amount equal to the one-way delay between sender and receiver. The reported times can nonetheless be useful for the purposes mentioned above.
パケット領収書回数はデータ・パケットに関するRTPタイムスタンプのように同じユニットで言い表されます。 匹敵する用語で時間と領収書時間を送ってください。しかしながら、RTP送付者が通常無作為に選ばれた値に時間を初期化するので送付者と受信機の間には、発信してください。そうすれば、片道遅れと等しい量に従って領収書回が異なると報告した期待が全くあるはずがないことに注意してください。これが1つが各パケットに関して両方を設立できるためのそう、報告された回はそれにもかかわらず、前記のように目的の役に立つ場合があります。
At least one packet MUST have been received for each sequence number reported upon in this block. If this block type is used to report receipt times for a series of sequence numbers that includes lost packets, several blocks are required. If duplicate packets have been received for a given sequence number, and those packets differ in their receipt times, any time other than the earliest MUST NOT be reported. This is to ensure consistency among reports.
このブロックで報告された各一連番号のために少なくとも1つのパケットを受け取ったに違いありません。 このゴシック体が一連の一連番号のためのそれの回が含む領収書がパケットを失ったと報告するのに使用されるなら、いくつかのブロックが必要です。 与えられた一連番号のために写しパケットを受け取って、それらのパケットが彼らの領収書時代において異なるなら、最も早い以外の少しの時間も報告してはいけません。 これはレポートの中で一貫性があることを保証することになっています。
Times reported in RTP timestamp format consume more bits than loss or duplicate information, and do not lend themselves to run length encoding. The use of thinning is encouraged to limit the size of Packet Receipt Times Report Blocks.
RTPタイムスタンプ形式で報告された回は、損失か写し情報より多くのビットを消費して、ランレングスコード化に自分たちを与えません。 間引きの使用がPacket ReceiptタイムズReport Blocksのサイズを制限するよう奨励されます。
Friedman, et al. Standards Track [Page 18] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[18ページ]。
The Packet Receipt Times Report Block has the following format:
Packet ReceiptタイムズReport Blockには、以下の形式があります:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| ブロック長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースのSSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _seqを始めてください。| 終わり_seq| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットの領収書時間は_seqを始めます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケット(_seq+1を始める)のモッズ風の65536の領収書時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケット(終わり_seq--1)のモッズ風の65536の領収書時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A Packet Receipt Times Report Block is identified by the
constant 3.
タイプ(BT)を妨げてください: 8ビットのA Packet ReceiptタイムズReport Blockは一定の3時までに特定されます。
rsvd.: 4 bits
This field is reserved for future definition. In the absence
of such a definition, the bits in this field MUST be set to
zero and MUST be ignored by the receiver.
rsvd、: Thisがさばく4ビットは今後の定義のために予約されます。 そのような定義がないとき、この分野のビットをゼロに設定しなければならなくて、受信機で無視しなければなりません。
thinning (T): 4 bits
As defined in Section 4.1.
間引き(T): セクション4.1で定義された4ビットのAs。
block length: 16 bits
Defined in Section 3.
ブロック長: セクション3における16ビットのDefined。
SSRC of source: 32 bits
As defined in Section 4.1.
ソースのSSRC: セクション4.1で定義された32ビットのAs。
begin_seq: 16 bits
As defined in Section 4.1.
_seqを始めてください: セクション4.1で定義された16ビットのAs。
end_seq: 16 bits
As defined in Section 4.1.
_seqを終わらせてください: セクション4.1で定義された16ビットのAs。
Friedman, et al. Standards Track [Page 19] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[19ページ]。
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データ・パケットタイムスタンプと対照的に、領収書回はできるだけ密接に実際の時間を反映するべきです。そこでは、額面価格が、システムクロック値の代わりに周期的な再生の役に立つ情報を伝えるのに使用されるかもしれません。 1番目がRTPタイムスタンプが無作為に選ばれているなら時間的価値SHOULDも領収書を出させるセッションには、無作為に選ばれてください。そうすれば、その後のタイムスタンプはこの値から相殺されます。 他方では、RTPタイムスタンプが反射することになっているなら、送付者、次に、領収書時間SHOULDの参照時間に受信機にできるだけ参照時間の近くにいてください。
4.4. Receiver Reference Time Report Block
4.4. 受信機参照時間レポートブロック
This block extends RTCP's timestamp reporting so that non-senders may also send timestamps. It recapitulates the NTP timestamp fields from the RTCP Sender Report [9, Sec. 6.3.1]. A non-sender may estimate its round trip time (RTT) to other participants, as proposed in [18], by sending this report block and receiving DLRR Report Blocks (see next section) in reply.
このブロックは、また、非送付者がタイムスタンプを送ることができるように、RTCPのタイムスタンプ報告を広げています。 それはRTCP Sender ReportからNTPタイムスタンプ分野について摘記します。[9、秒 6.3.1]. 非送付者は、このレポートブロックを送るのによる[18]で提案されて、DLRR Report Blocksを受けると回答で周遊旅行時間が(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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 予約されます。| ブロック長=2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTPタイムスタンプ、最も重要な単語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTPタイムスタンプ、最も重要でない単語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A Receiver Reference Time Report Block is identified by the
constant 4.
タイプ(BT)を妨げてください: 8ビットのA Receiver Reference Time Report Blockは一定の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.
予約される: Thisがさばく8ビットは今後の定義のために予約されます。 そのような定義がないとき、この分野のビットをゼロに設定しなければならなくて、受信機で無視しなければなりません。
Friedman, et al. Standards Track [Page 20] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[20ページ]。
block length: 16 bits
The constant 2, in accordance with the definition of this field
in Section 3.
ブロック長: セクション3とのこの分野の定義に従って、16ビットは一定の2です。
NTP timestamp: 64 bits
Indicates the wallclock time when this block was sent so that
it may be used in combination with timestamps returned in DLRR
Report Blocks (see next section) from other receivers to
measure round-trip propagation to those receivers. Receivers
should expect that the measurement accuracy of the timestamp
may be limited to far less than the resolution of the NTP
timestamp. The measurement uncertainty of the timestamp is not
indicated as it may not be known. A report block sender that
can keep track of elapsed time but has no notion of wallclock
time may use the elapsed time since joining the session
instead. This is assumed to be less than 68 years, so the high
bit will be zero. It is permissible to use the sampling clock
to estimate elapsed wallclock time. A report sender that has
no notion of wallclock or elapsed time may set the NTP
timestamp to zero.
NTPタイムスタンプ: タイムスタンプと組み合わせてそれを使用できるようにこのブロックを送ったとき、wallclockが調節する64ビットのIndicatesは他の受信機からのDLRR Report Blocks(次のセクションを見る)で戻って、それらの受信機に往復の伝播を測定しました。 受信機は、タイムスタンプの測定精度がNTPタイムスタンプの解決遠い以下に制限されるかもしれないと予想するはずです。 それが知られていないかもしれないようにタイムスタンプの測定の不確実性は示されません。 経過時間の道を保つことができますが、wallclock時間の考えを全く持っていないレポートブロック送付者は代わりにセッションに参加して以来の経過時間を費やすかもしれません。 これが68年未満であると思われるので、高いビットはゼロになるでしょう。 経過したwallclock時間を見積もるのに標本抽出時計を使用するのは許されています。 wallclockか経過時間の考えを全く持っていないレポート送付者はNTPタイムスタンプをゼロに設定するかもしれません。
4.5. DLRR Report Block
4.5. DLRRレポートブロック
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.
このブロックは最後のSender Report(DLSR)メカニズム以来のRTCPの遅れを広げています。[9、秒 6.3.1] また、非送付者が計算できるように、[18]で提案されるように旅行時間を一周させてください。 それを最後のReceiver Report以来遅れのためにDLRRと呼んで、周遊旅行時間について応答者に計算するためにその受信機を許容するためにReceiver Timestamp Report Blockに対応して受信機から送るかもしれません(前項を見ます)。 レポートは、より1 3つの単語サブブロックから成ります: 1Receiver Reportあたり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 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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| 予約されます。| ブロック長| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1(最初の受信機のSSRC)| サブ+++++++++++++++++++++++++++++++++ブロック| 最後のRR(LRR)| 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最後のRR(DLRR)以来の遅れ| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2(2番目の受信機のSSRC)| サブ+++++++++++++++++++++++++++++++++ブロック: ... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Friedman, et al. Standards Track [Page 21] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[21ページ]。
block type (BT): 8 bits
A DLRR Report Block is identified by the constant 5.
タイプ(BT)を妨げてください: 8ビットのA DLRR Report Blockは一定の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.
予約される: Thisがさばく8ビットは今後の定義のために予約されます。 そのような定義がないとき、この分野のビットをゼロに設定しなければならなくて、受信機で無視しなければなりません。
block length: 16 bits
Defined in Section 3.
ブロック長: セクション3における16ビットのDefined。
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が分ける関与しているSSRCからのReceiver Reference Time Report Blockの32ビット。 どんなそのようなブロックも受け取っていないなら、ゼロに分野を設定します。
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)以来、延着してください: 関与しているSSRCから最後のReceiver Reference Time Report Blockを受けて、このDLRR Report Blockを送ることの間の1/65536秒の単位で遅れであって、言い表された32ビット。 Receiver Reference Time Report BlockがSSRCからまだ受け取られていないなら、DLRR分野はゼロに設定されます(DLRRは完全に省略されます)。 SSRC_rにこのDLRR Report Blockを発行する受信機を指示させてください。 関与しているSSRCは、このReceiver Timestamp Report Blockが受け取られている時Aを記録することによって、丸い旅行伝播遅延をSSRC_rに計算できます。 それは、最後のRRタイムスタンプ(LRR)分野を使用して、次に、A-LRR-DLRRとして往復の伝播を遅れに残すためにこの分野を引き算しながら、総往復の時間A-LRRについて計算します。 これは[9、図2]で例証されます。
4.6. Statistics Summary Report Block
4.6. 統計概略報告ブロック
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かHop Limit値に関して記録されます。 そのような情報はネットワークマネージメントの役に立つ場合があります。
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.
レポートブロック内容はヘッダーの最初の一部で運ばれた一連のフラグビットに依存しています。 すべてのパラメタが、各ブロックで報告される必要があるというわけではありません。 旗は、どれがあるか、そして、どれが報告されないかを示します。 非報告されたパラメタに対応する分野は、存在していなければなりませんが、ゼロに設定されます。 非ゼロ値が非報告されるように旗を揚げられたどんな分野にもある状態で、受信機はどんなStatistics Summary Report Blockも無視しなければなりません。
Friedman, et al. Standards Track [Page 22] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[22ページ]。
The Statistics Summary Report Block has the following format:
Statistics Summary Report Blockには、以下の形式があります:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| ブロック長=9| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースのSSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _seqを始めてください。| 終わり_seq| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 無くなっている_パケット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dup_パケット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 分_ジター| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大_ジター| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 平均_ジター| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dev_ジター| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 分_ttl_か_hl| 最大_ttl_か_hl|平均_ttl_か_hl| dev_ttl_か_hl| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A Statistics Summary Report Block is identified by the constant
6.
タイプ(BT)を妨げてください: 8ビットのA Statistics Summary Report Blockは一定の6時までに特定されます。
loss report flag (L): 1 bit
Bit set to 1 if the lost_packets field contains a report, 0
otherwise.
損害報告旗(L): そうでなければ、無くなっている_パケット分野がレポート、0を含んでいるなら、1ビットのBitは1にセットしました。
duplicate report flag (D): 1 bit
Bit set to 1 if the dup_packets field contains a report, 0
otherwise.
レポート旗(D)をコピーしてください: そうでなければ、dup_パケット分野がレポート、0を含んでいるなら、1ビットのBitは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): 分_ジター、最大_ジター、平均_ジター、およびdev_ジター分野がすべて、レポート、0を含んでいて、それらのいずれもセットしなかったなら、1ビットのBitは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かHop Limitが(ToH)に旗を揚げさせます: 分_ttl_、_hl、最大_ttl_、_hl、平均_ttl_、_hl、dev_ttl_または_hlが含む分野のいずれも報告しないなら、Thisがさばく2ビットは0に設定されます。 分野が非ゼロであるなら、これらの分野のすべてがレポートを含んでいます。 値1は、彼らがIPv4 TTL値に関して報告するのを意味します。 彼らが報告する値2は意味します。
Friedman, et al. Standards Track [Page 23] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[23ページ]。
IPv6 Hop Limit values. The value 3 is undefined and MUST NOT
be used.
IPv6 Hop Limit値。 値3は、未定義であり、使用されてはいけません。
rsvd.: 3 bits
This field is reserved for future definition. In the absence
of such a definition, the bits in this field MUST be set to
zero and MUST be ignored by the receiver.
rsvd、: Thisがさばく3ビットは今後の定義のために予約されます。 そのような定義がないとき、この分野のビットをゼロに設定しなければならなくて、受信機で無視しなければなりません。
block length: 16 bits
The constant 9, in accordance with the definition of this field
in Section 3.
ブロック長: セクション3とのこの分野の定義に従って、16ビットは一定の9です。
SSRC of source: 32 bits
As defined in Section 4.1.
ソースのSSRC: セクション4.1で定義された32ビットのAs。
begin_seq: 16 bits
As defined in Section 4.1.
_seqを始めてください: セクション4.1で定義された16ビットのAs。
end_seq: 16 bits
As defined in Section 4.1.
_seqを終わらせてください: セクション4.1で定義された16ビットのAs。
lost_packets: 32 bits
Number of lost packets in the above sequence number interval.
無くなっている_パケット: 上の一連番号間隔の無くなっているパケットの32ビットのNumber。
dup_packets: 32 bits
Number of duplicate packets in the above sequence number
interval.
dup_パケット: 上の一連番号間隔の写しパケットの32ビットのNumber。
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.
分_ジター: 32ビット、最小の相対的なトランジットは上の一連番号間隔の2つのパケットの間で調節します。 すべてのジター値が同じユニットで測定された到着時点で、パケットのRTPタイムスタンプとレポーターの時計の違いとして測定されます。
max_jitter: 32 bits
The maximum relative transit time between two packets in the
above sequence number interval.
_ジターに最大限にしてください: 32ビット、最大の相対的なトランジットは上の一連番号間隔の2つのパケットの間で調節します。
mean_jitter: 32 bits
The mean relative transit time between each two packet series
in the above sequence number interval, rounded to the nearest
value expressible as an RTP timestamp.
意地悪な_ジター: 32ビット、意地悪な親類は時間を通過します。RTPタイムスタンプとして表現できる最も近い値に一周した上の一連番号間隔の各2つのパケットシリーズの間で。
dev_jitter: 32 bits
The standard deviation of the relative transit time between
each two packet series in the above sequence number interval.
dev_ジター: 上の一連番号間隔の各2つのパケットシリーズの間の相対的なトランジット時間の標準の逸脱の32ビット。
Friedman, et al. Standards Track [Page 24] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[24ページ]。
min_ttl_or_hl: 8 bits
The minimum TTL or Hop Limit value of data packets in the
sequence number range.
分_ttl_か_hl: 最小のTTLかHop Limitが評価するデータ・パケットの8ビットは一連番号で及びます。
max_ttl_or_hl: 8 bits
The maximum TTL or Hop Limit value of data packets in the
sequence number range.
最大_ttl_か_hl: 最大のTTLかHop Limitが評価するデータ・パケットの8ビットは一連番号で及びます。
mean_ttl_or_hl: 8 bits
The mean TTL or Hop Limit value of data packets in the sequence
number range, rounded to the nearest integer.
平均_ttl_か_hl: 意地悪なTTLかHop Limitが評価する最も近い整数に一周した一連番号範囲のデータ・パケットの8ビット。
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_か_hl: TTLの標準の逸脱の8ビットか一連番号における、データ・パケットのHop Limit値が及びます。
4.7. VoIP Metrics Report Block
4.7. VoIP測定基準はブロックを報告します。
The VoIP Metrics Report Block provides metrics for monitoring voice over IP (VoIP) calls. These metrics include packet loss and discard metrics, delay metrics, analog metrics, and voice quality metrics. The block reports separately on packets lost on the IP channel, and those that have been received but then discarded by the receiving jitter buffer. It also reports on the combined effect of losses and discards, as both have equal effect on call quality.
VoIP Metrics Report Blockは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]のburstinessの度を考えるのは望ましいです。 ギルバート-エリオットモデル[3]に従って、高い率の損失、そして/または、破棄がある無くなっているそして/または、捨てられたパケットで境界がある期間は「炸裂」です、そして、2回の炸裂の間の期間は「ギャップ」です。 炸裂はパケット損失率がオーディオ音質におけるめぼしい退行を起こすことができるくらい高い期間に対応しています。 ギャップは孤立している無くなっているパケットだけが起こるかもしれない期間に対応しています、そして、一般に、パケット損失隠すことでこれらにマスクをかけることができます。 遅れレポートはRTPエンドポイントとVoIP終わりのシステム処理遅れの間のトランジット遅れを含んでいます。それの両方がそれのために遅れであると知覚されたユーザに貢献します。 追加測定基準は信号、エコー、雑音、およびひずみレベルを含んでいます。 上質の測定基準がR要素([6、3]で定義されたE Modelによって説明されるように)を含んで、意見を意味するという要求は(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.
実現はここで定義されたすべての分野に値を提供しなければなりません。 ある測定基準において、値が未定義であるか、または未知であるなら、指定されたデフォルトか未知の分野値を提供しなければなりません。
Friedman, et al. Standards Track [Page 25] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[25ページ]。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 予約されます。| ブロック長=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースのSSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 損失率| レートを捨ててください。| 密度を押し破いてください。| ギャップ密度| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 持続時間を押し破いてください。| ギャップ持続時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 周遊旅行遅れ| 終わりのシステム遅れ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 信号レベル| 騒音レベル| RERL| Gmin| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R要素| ext。 R要素| モス-LQ| モス-CQ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RXコンフィグ| 予約されます。| JB名目上です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JB最大| JB腹筋最大| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A VoIP Metrics Report Block is identified by the constant 7.
タイプ(BT)を妨げてください: 8ビットのA VoIP Metrics Report Blockは一定の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.
予約される: Thisがさばく8ビットは今後の定義のために予約されます。 そのような定義がないとき、この分野のビットをゼロに設定しなければならなくて、受信機で無視しなければなりません。
block length: 16 bits
The constant 8, in accordance with the definition of this field
in Section 3.
ブロック長: セクション3とのこの分野の定義に従って、16ビットは一定の8です。
SSRC of source: 32 bits
As defined in Section 4.1.
ソースのSSRC: セクション4.1で定義された32ビットのAs。
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つのセクションで説明されます: 測定基準(遅れ測定基準)が示すパケット損失と破棄は測定基準か呼び出し品質かトランスミッション品質測定基準と、構成測定基準と、ジターバッファパラメタについて話しました。
Friedman, et al. Standards Track [Page 26] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[26ページ]。
4.7.1. Packet Loss and Discard Metrics
4.7.1. パケット損失と破棄測定基準
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.
損失率: 2進小数点が分野の左の縁にある状態で固定小数点数として言い表されたレセプションの始まり以来ソースからのRTPデータ・パケットの部分の8ビットは損をしました。 この値は分割の結果を256に掛けて、予想されたパケットの総数によって失われた(FECなどのどんな誤り保護も適用するという効果の後に)パケットの総数を分割することによって、計算されます、最大値を255(オーバーフローを避ける)に制限して、整数部を取って。 コピーされたパケットと捨てられたパケットの数はこの計算に入りません。 受信機が無制限なバッファを維持できる必要はないので、受信機は失われているように遅く到着しているパケットを分類するかもしれません。 引き金のaの損失SHOULDが破棄の引き金となるそれよりかなりすばらしいという遅れの度合い。
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ビットは、経営の下の遅いか早めの到着によるレセプションの始まり以来捨てられるか、または受信ジターバッファにあふれます。 2進小数点が分野の左の縁にある状態で、この値は固定小数点数として言い表されます。 分割の結果を256に掛けて、予想されたパケットの総数に従ってパケットの総数が捨てられた(写しパケット破棄を除いて)と分割することによって、見込まれます、最大値を255(オーバーフローを避ける)に制限して、整数部を取って。
4.7.2. Burst Metrics
4.7.2. 測定基準を押し破いてください。
A burst is a period during which a high proportion of packets are either lost or discarded due to late arrival. A burst is defined, in terms of a value Gmin, as the longest sequence that (a) starts with a lost or discarded packet, (b) does not contain any occurrences of Gmin or more consecutively received (and not discarded) packets, and (c) ends with a lost or discarded packet.
炸裂はパケットの高い割合が失われているか、または遅刻者のため捨てられる期間です。 炸裂は定義されます、値のGminに関して、(a)が無くなっているか捨てられたパケットから始める中で最も長い系列、(b)がGminのどんな発生か連続してより受け取られた(そして、捨てられません)パケットも含んでいなくて、(c)が無くなっているか捨てられたパケットと共に終わっている間。
A gap, informally, is a period of low packet losses and/or discards. Formally, a gap is defined as any of the following: (a) the period from the start of an RTP session to the receipt time of the last
ギャップは非公式に低いパケット損失、そして/または、破棄の一区切りです。 正式に、ギャップは以下のどれかと定義されます: (a) RTPセッションの始まりから最終領収書時間までの期間
Friedman, et al. Standards Track [Page 27] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[27ページ]。
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.
(b) 最初の炸裂の前の容認されたパケット、最終端からの期間は(c) レポートの時間か一番になるRTPセッションの終わりか2回の炸裂の間の期間のどちらかにはち切れました。
For the purpose of determining if a lost or discarded packet near the start or end of an RTP session is within a gap or a burst, it is assumed that the RTP session is preceded and followed by at least Gmin received packets, and that the time of the report is followed by at least Gmin received packets.
ギャップか炸裂の中にRTPセッションの始めか終わり頃の無くなっているか捨てられたパケットがあるかを決定する目的のために、少なくともGminの容認されたパケットがRTPセッションに先行されていて、あとに続いていて、少なくとも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のGmin値はRECOMMENDEDです、良質(すなわち、低パケット損失率、16の最小の距離は無くなっているパケットの間にパケットを受けた)に対応するギャップの特性をもたらして、したがって、うまく良くて貧しい上質の期間を区別するとき。
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を指示します、そして、Xは64のパケットを覆う以下のパターンの捨てられたパケットを指示します:
11110111111111111111111X111X1011110111111111111111111X111111111
|---------gap----------|--burst---|------------gap------------|
11110111111111111111111X111X1011110111111111111111111X111111111|---------ギャップ----------|--押し破かれます。---|------------ギャップ------------|
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の推奨値であるなら、炸裂持続時間は、120msと、炸裂密度0.33と、ギャップ持続時間230ms+290ms=520msと、ギャップ密度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
損失率12、どれが5%に対応しているかが4%の炸裂持続時間120に対応する33%のギャップ密度10に対応する5%の炸裂密度84に対応するレート12を捨てて、ミリセカンドで表現される値はギャップ持続時間520です、ミリセカンドで表現される値
Friedman, et al. Standards Track [Page 28] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[28ページ]。
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.
密度を押し破いてください: レセプションの始まり以来のどちらかであった炸裂の期間以内のRTPデータ・パケットの部分の8ビットは、損をしたか、または捨てられました。 2進小数点が分野の左の縁にある状態で、この値は固定小数点数として言い表されます。 それは炸裂の期間以内に炸裂の期間以内に予想されたパケットの総数によって失われたか、または捨てられた(写しパケット破棄を除いて)パケットの総数を分割することによって、計算されます、分割の結果を256に掛けて、最大値を255(オーバーフローを避ける)に制限して、整数部を取って。 パケットを全く受け取っていないなら、この分野に居住しなければならなくて、ゼロに設定しなければなりません。
gap density: 8 bits
The fraction of RTP data packets within inter-burst gaps since
the beginning of reception that were either lost or discarded.
The value is expressed as a fixed point number with the binary
point at the left edge of the field. It is calculated by
dividing the total number of packets lost or discarded
(excluding duplicate packet discards) within gap periods by the
total number of packets expected within the gap periods,
multiplying the result of the division by 256, limiting the
maximum value to 255 (to avoid overflow), and taking the
integer part. This field MUST be populated and MUST be set to
zero if no packets have been received.
ギャップ密度: レセプションの始まり以来のどちらかであった相互炸裂ギャップの中のRTPデータ・パケットの部分の8ビットは、損をしたか、または捨てられました。 2進小数点が分野の左の縁にある状態で、値は固定小数点数として言い表されます。 それはギャップの期間以内にギャップの期間以内に予想されたパケットの総数によって失われたか、または捨てられた(写しパケット破棄を除いて)パケットの総数を分割することによって、計算されます、分割の結果を256に掛けて、最大値を255(オーバーフローを避ける)に制限して、整数部を取って。 パケットを全く受け取っていないなら、この分野に居住しなければならなくて、ゼロに設定しなければなりません。
burst duration: 16 bits
The mean duration, expressed in milliseconds, of the burst
periods that have occurred since the beginning of reception.
The duration of each period is calculated based upon the
packets that mark the beginning and end of that period. It is
equal to the timestamp of the end packet, plus the duration of
the end packet, minus the timestamp of the beginning packet.
If the actual values are not available, estimated values MUST
be used. If there have been no burst periods, the burst
duration value MUST be zero.
持続時間を押し破いてください: レセプションの始まり以来起こっている炸裂の期間のミリセカンドで意地悪な持続時間であって、言い表された16ビット。 それぞれの期間の持続時間はその期間の首尾をマークするパケットに基づいた状態で計算されます。 それは終わりのパケットに関するタイムスタンプ、および終わりのパケットの持続時間と等しいです、始めのパケットに関するタイムスタンプを引いて。 実価が利用可能でないなら、見積価格を使用しなければなりません。 炸裂の期間が全くなかったなら、炸裂持続時間価値はゼロであるに違いありません。
gap duration: 16 bits
The mean duration, expressed in milliseconds, of the gap
periods that have occurred since the beginning of reception.
The duration of each period is calculated based upon the packet
that marks the end of the prior burst and the packet that marks
the beginning of the subsequent burst. It is equal to the
timestamp of the subsequent burst packet, minus the timestamp
of the prior burst packet, plus the duration of the prior burst
packet. If the actual values are not available, estimated
values MUST be used. In the case of a gap that occurs at the
beginning of reception, the sum of the timestamp of the prior
ギャップ持続時間: レセプションの始まり以来起こっているギャップの期間のミリセカンドで意地悪な持続時間であって、言い表された16ビット。 それぞれの期間の持続時間は先の炸裂の終わりを示すパケットとその後の炸裂の始まりを示すパケットに基づいた状態で計算されます。 それはその後の炸裂パケットに関するタイムスタンプと等しいです、先の炸裂パケットに関するタイムスタンプ、および先の炸裂パケットの持続時間を引いて。 実価が利用可能でないなら、見積価格を使用しなければなりません。 ギャップの場合では、それはレセプションの始めに起こります、先に関するタイムスタンプの合計
Friedman, et al. Standards Track [Page 29] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[29ページ]。
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.
レセプション開始時刻で先の炸裂パケットの炸裂パケットと持続時間を取り替えます。 レセプションの終わりに起こるギャップの場合では、レセプション終わりの時間はその後の炸裂パケットに関するタイムスタンプを取り替えます。 ギャップの期間が全くなかったなら、ギャップ持続時間価値はゼロであるに違いありません。
4.7.3. Delay Metrics
4.7.3. 遅れ測定基準
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ペイロードマルチプレクシングによる遅れが音声アプリケーションかエンドシステム遅れの一部であると考えられるでしょうが、UDPフレームの中にRTPフレームを多重送信するのによる遅れが考えられるだろうというとき、RTPの一部が遅れを報告しました。 この区別はRTCPの遅れ測定値の使用と一致しています。
round trip delay: 16 bits
The most recently calculated round trip time between RTP
interfaces, expressed in milliseconds. This value MAY be
measured using RTCP, the DLRR method defined in Section 4.5 of
this document, where it is necessary to convert the units of
measurement from NTP timestamp values to milliseconds, or other
approaches. If RTCP is used, then the reported delay value is
the time of receipt of the most recent RTCP packet from source
SSRC, minus the LSR (last SR) time reported in its SR (Sender
Report), minus the DLSR (delay since last SR) reported in its
SR. A non-zero LSR value is required in order to calculate
round trip delay. A value of 0 is permissible; however, this
field MUST be populated as soon as a delay estimate is
available.
旅行遅れを一周させてください: ミリセカンドで言い表されたRTPインタフェースの間の最近16ビット最も計算された周遊旅行時間。 この値は測定使用RTCPであるかもしれません、このドキュメントのセクション4.5で定義されたDLRR方法、ミリセカンド、またはNTPタイムスタンプ値から他のアプローチまでの測定の単位を変換するのが必要であるところで。 RTCPが使用されているなら、報告された遅れ値はソースSSRCからの最新のRTCPパケットの収入の時期です、SR(送付者Report)でSRで報告されたDLSR(最後のSR以来の遅れ)を引いて報告されたLSR(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測定基準レポートであったならSHOULDを評価します。 実現がデータを提供できないなら、値0を使用しなければなりません。
Friedman, et al. Standards Track [Page 30] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[30ページ]。
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セグメント遅れが周遊旅行と終わりのシステム遅れから計算されるかもしれないというメモは以下の通りです。 周遊旅行遅れが指示されるなら、RTDと2つの終点に関連している終わりのシステム遅れは、ESD(A)とESD(B)です:
one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2
一方通行の左右対称の声の経路遅れが等しい、(RTD+ESD(A)+ESD(B) ) / 2
4.7.4. Signal Related Metrics
4.7.4. 関連測定基準に合図してください。
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システムの上で声の非パケット要素に関連するリアルタイムの情報を提供することを意図します。 受信された音声信号のために以下で特定された値を決定しなければなりません。 これらの分野に居住するのに必要である情報はすべてのシステムで利用可能でないかもしれません、このデータSHOULDが問題診断を支持するために提供されることを強く勧められますが。
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.
レベルに合図してください: 定義される声が相対的なレベルに信号レベル対サインされた整数としてデシベルで言い表された0dBm0参照[10]の比率に示す8ビットは2の補数で形成されます。 これはスピーチエネルギーを含むパケットのためだけに測定されます。 これほどメートル法の意図は信号レベルの正確な寸法を提供するのではなく、信号レベルが過度に高いか、または低いかもしれないというリアルタイムの指示を提供することです。
signal level = 10 Log10 ( rms talkspurt power (mW) )
信号レベルは10Log10と等しいです。(rms talkspurtパワー(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〜-20dBm範囲にあるべきです。
noise level: 8 bits
The noise level is defined as the ratio of the silent period
background noise level to a 0 dBm0 reference, expressed in
decibels as a signed integer in two's complement form.
騒音レベル: 8ビット、騒音レベルは2の補数フォームで沈黙期暗騒音レベル対サインされた整数としてデシベルで言い表された0dBm0参照の比率と定義されます。
noise level = 10 Log10 ( rms silence power (mW) )
騒音レベルは10Log10と等しいです。(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)とエコーリターン損失増進(アール)値がエコーキャンセラーで報告したと言い足すことによって、見積もられるかもしれません。
RERL(dB) = ERL (dB) + ERLE (dB)
RERL(dB)はERL(dB)+アールと等しいです。(dB)
Friedman, et al. Standards Track [Page 31] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[31ページ]。
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-12dBの範囲にあることができます。 線エコーキャンセラは、30dB以上のアールを提供して、したがって、これを40-50dBまで減少させることができます。 これは、受話器スピーカーとマイクロホンの間の音響結合かスピーカーフォーン操作からの残りの音のエコーであるかもしれなく、IP電話の場合では、より正しく端末の結合損失(TCL)と呼ばれるかもしれません。 典型的な受話器はハウリングによる40-50dBのエコーの損失をもたらすでしょう。
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ワイヤ輪でサーキット交換網に接続しました。 エコーキャンセル、12dBの典型的な2-4ワイヤコンバータERLなしで。 RERLは12+0 = 12ERL+アール=dBと等しいです。
- IP gateway connected to circuit switched network with 2 wire
loop. With echo canceler that improves echo by 30 dB.
RERL = ERL + ERLE = 12 + 30 = 42 dB.
- IPゲートウェイは2ワイヤ輪でサーキット交換網に接続しました。 エコーキャンセラで、それはエコーを30dB改良します。 RERLは12+30 = 42ERL+アール=dBと等しいです。
- IP phone with conventional handset. Acoustic coupling from
handset speaker to microphone (terminal coupling loss) is
typically 40 dB. RERL = TCL = 40 dB.
- 従来の受話器があるIP電話。 通常、受話器スピーカーからマイクロホン(端末の結合損失)までの音響結合は40dBです。 RERL=TCLは40dBと等しいです。
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:
私たちがBとしてAとしてのVoIP経路とリモートエンドの地方の終わりを指示して、Aで、送付者高らか格付けの(SLR)と受信機高らか格付け(RLR)を知っているなら(デフォルトはそれぞれ8dBと2dBを評価します)、以下は終わりA(話し手エコー高らか格付けかTELR)のエコー大きさのレベルを与えます。
TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)
TELR(A)はSRL(A)+ERL(B)+アール(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接続のA終わりに音声の品質見積りにエコーを組み入れるために、ERL+アール値をBからAに送るのはRTCP XRなどの形式を使用することで望ましいです。
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エンドシステムで利用可能でないかもしれません。エコーが会話の品質に重要な影響を与えるとき、エコーリターンの損失と端末の結合損失のための見積価格を提供するのはお勧めです(合理的に分別がある見積りを測定できるなら)。
Friedman, et al. Standards Track [Page 32] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[32ページ]。
Typical values for end systems are given below to provide
guidance:
指導を提供するためにエンドシステムのための典型的な値を以下に与えます:
- IP Phone with handset: typically 45 dB.
- 受話器があるIP電話: 通常45dB。
- 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と手があいているアールは通常います。
- 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ゲートウェイ: 頻繁に、エコーの源は問題について話して、低値(12dB)か「未定義」の(127)のどちらかを報告すると考えてください。
Gmin
See Configuration Parameters (Section 4.7.6, below).
Gmin See Configuration Parameters(セクション4.7.6未満)。
4.7.5. Call Quality or Transmission Quality Metrics
4.7.5. 品質かトランスミッション品質測定基準に電話をしてください。
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.
以下の測定基準は、呼び出し品質かトランスミッション品質のダイレクト基準であり、コーデックタイプ、パケット損失、破棄、遅れburstinessなどの効果を取り入れます。 しかしながら、これらの測定基準はすべてのシステムで利用可能でないかもしれなく、それらはSHOULDです。問題診断を支持するために、提供します。
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要素: R要素は、このRTPセッションのときに持ち越される呼び出しのセグメントについて説明しながら、8ビット、a音声の品質メートル法です。 それは整数として範囲で0〜100に言い表されます、94の値が「品質に料金を課する」ために対応している、50以下の値が使用不可能であると見なされる状態で。 これほどメートル法、ITU-T G.107[6]とETSI TS101 329-5[3]と一致した遅れの効果を含んでいると定義されます。
A value of 127 indicates that this parameter is unavailable.
Values other than 127 and the valid range defined above MUST
not be sent and MUST be ignored by the receiving system.
127の値は、このパラメタが入手できないのを示します。 127以外の値と上で定義された有効枠を、送られてはいけなくて、受電方式で無視しなければなりません。
ext. R factor: 8 bits
The external R factor is a voice quality metric describing the
segment of the call that is carried over a network segment
external to the RTP segment, for example a cellular network.
Its values are interpreted in the same manner as for the RTP R
factor. This metric is defined as including the effects of
delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5
[3], and relates to the outward voice path from the Voice over
IP termination for which this metrics block applies.
ext。 R要素: 外部のR要素はRTPセグメントへの外部のネットワークセグメントの上まで運ばれる呼び出しのセグメントについて説明しながら、8ビット、a音声の品質メートル法です、例えば、セルラー・ネットワーク。 値はRTP R要素のように同じ方法で解釈されます。 これほどメートル法、ITU-T G.107[6]とETSI TS101 329-5[3]と一致した遅れの効果を含んでいると定義されて、この測定基準ブロックが申し込まれるボイス・オーバー IP終了から外へ向かう声の経路に関連します。
Friedman, et al. Standards Track [Page 33] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[33ページ]。
A value of 127 indicates that this parameter is unavailable.
Values other than 127 and the valid range defined above MUST
not be sent and MUST be ignored by the receiving system.
127の値は、このパラメタが入手できないのを示します。 127以外の値と上で定義された有効枠を、送られてはいけなくて、受電方式で無視しなければなりません。
Note that an overall R factor may be estimated from the RTP segment R factor and the external R factor, as follows:
総合的なR要素がRTPセグメントR要素と外部のR要素から見積もられるかもしれないことに注意してください、以下の通りです:
R total = RTP R factor + ext. R factor - 94
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.
モス-LQ: 8ビット、概算がスコアが品質(MOS-LQ)を聴くのが、aのメートル法の音声の品質であるので、素晴らしい状態で1〜5、5が表すコネをスケーリングするという意見と1を意味する、表す、容認できません。 これほどメートル法、遅れの効果を含んでいなくて、MOSスコアと比べて、含むことができると上質の(ACR)テストを聴くのから得た状態で定義されます。 MOS x10に対応している、それは整数として範囲で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.
127の値は、このパラメタが入手できないのを示します。 127以外の値と上で定義された有効枠を、送られてはいけなくて、受電方式で無視しなければなりません。
MOS-CQ: 8 bits
The estimated mean opinion score for conversational quality
(MOS-CQ) is defined as including the effects of delay and other
effects that would affect conversational quality. The metric
may be calculated by converting an R factor determined
according to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an
estimated MOS using the equation specified in G.107. It is
expressed as an integer in the range 10 to 50, corresponding to
MOS x 10, as for MOS-LQ.
モス-CQ: 会話の品質(MOS-CQ)のためのおよそ平均である意見スコアの8ビットは会話の品質に影響する遅れと他の効果の効果を含んでいると定義されます。 概算のときにITU-t G.107[6]かETSI TS101 329-5[3]によると、決定しているR要素を変換することによってメートル法が計算されているかもしれない方程式を使用するMOSがG.107で指定しました。 MOS-LQのようにMOS x10に対応している、それは整数として範囲で10〜50に言い表されます。
A value of 127 indicates that this parameter is unavailable.
Values other than 127 and the valid range defined above MUST
not be sent and MUST be ignored by the receiving system.
127の値は、このパラメタが入手できないのを示します。 127以外の値と上で定義された有効枠を、送られてはいけなくて、受電方式で無視しなければなりません。
4.7.6. Configuration Parameters
4.7.6. 設定パラメータ
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
Gmin: 8ビット、ギャップ敷居。 この分野はこのレポートブロックが、ギャップが存在するかどうか決定するのに使用される値を含んでいます。 16の推奨値は、6.25%の無くなっているか捨てられたパケットの最小の密度を持ちながら、炸裂の期間に対応しています。パケットは呼び出し品質におけるめぼしい退行を引き起こすかもしれません。 ギャップの期間、パケット損失か破棄が起こるなら、それぞれの無くなっているか捨てられたパケットは、容認された非捨てられたパケットに先行して、少なくとも16の系列はあとに続いているでしょう。 それが損をしたか、または捨てられたことに注意してください。
Friedman, et al. Standards Track [Page 34] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[34ページ]。
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パケットの中に起こるパケットは後のレポートの炸裂かギャップの一部として分類し直されるかもしれません。 ETSI TS101 329-5[3]は破棄パケット損失/イベントドリブンのアプローチを使用することで炸裂とギャップ密度を測定するための計算上効率的なアルゴリズムを定義します。 このアルゴリズムは現在のドキュメントのAppendix A.2で再生します。 Gminはゼロであってはいけなく、提供しなければならなくて、RTPセッションの持続時間のためのVoIP Metricsレポートブロックの向こう側に一定のままで残らなければなりません。
receiver configuration byte (RX config): 8 bits
This byte consists of the following fields:
受信機構成バイト(RXコンフィグ): 8ビットのThisバイトは以下の分野から成ります:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PLC|JBA|JB rate|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |PLC|JBA|JBレート| +-+-+-+-+-+-+-+-+
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ビットのStandard(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ビットの非Adaptive(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)と等しいです。 これは適応型のモードによるジターバッファの実現の特定の調整率を表します。 このパラメタは中で階段状変化に完全に適応するために取って、30msから100までのピークツーピークジターが以下のことのようなものをmsする大体の時で定義されます。
adjustment time = 2 * J * frame size (ms)
調整時間は2*J*フレーム・サイズと等しいです。(ms)
Friedman, et al. Standards Track [Page 35] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[35ページ]。
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.
予約される: Thisがさばく8ビットは今後の定義のために予約されます。 そのような定義がないとき、この分野のビットをゼロに設定しなければならなくて、受信機で無視しなければなりません。
4.7.7. Jitter Buffer Parameters
4.7.7. ジターバッファパラメタ
The values reported in these fields SHOULD be the most recently obtained values at the time of reporting.
値は、これらの分野でSHOULDが報告時点で最も最近得られた値であると報告しました。
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ビットのThisはミリセカンドの現在の名目上のジターバッファ遅延です。(そのミリセカンドは、まさに定刻に到着するパケットのための名目上のジターバッファ遅延に対応します)。 修理されたものと同様に適応型のジターバッファ実現にこのパラメタを提供しなければなりません。
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ビットのThisは捨てられない中で最も早い到着パケットに対応するミリセカンドの現在の最大のジターバッファ遅延です。 簡単な待ち行列実現では、これは公称寸法に対応するかもしれません。 適応型のジターバッファ実現では、この値はダイナミックに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ビットのThisは適応型のジターバッファが最悪の場合条件のもとで達することができるミリセカンドの絶対最大値遅れです。 この値が65535人のミリセカンドを超えているなら、この分野SHALLは値65535を伝えます。 適応型のジターバッファ実現にこのパラメタを提供しなければなりません、そして、固定ジターバッファ実現のためにJB最大に値を設定しなければなりません。
5. SDP Signaling
5. SDPシグナリング
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
このセクションは、[4] SDPを利用するアプリケーションで使うことができるXRブロック合図しながら、Session記述プロトコル(SDP)を定義します。 このシグナリングは、SDP Offer/答えモデル[8]を実行するアプリケーションか接続におけるメディアと輸送構成について説明するのにSDPを使用するアプリケーションで使用されるために定義されます。
Friedman, et al. Standards Track [Page 36] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[36ページ]。
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.
Session Announcementプロトコル(SAP)[15]やレアルTime Streamingプロトコル(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.
ここで定義されるようにSDPシグナリングのXRブロックの使用が任意であって、使用されているかもしれませんが、それを使用しなければならないことに注意してください。 SDPシグナリングがXRブロックが関係者のある部分によって実行されるだけである環境で使用されると、XRブロックを実行しない人はSDP属性を無視するでしょう。
5.1. The SDP Attribute
5.1. 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.
SDPが結果と考えるRTCP XRブロックは以下でAugmented BN記法(ABNF)[2]で定義されます。 それはセッションとメディアレベルが結果と考える両方です。 セッションレベルで指定されると、それはセッションのときにすべてのメディア定盤に適用されます。 1つがそのメディアブロックに存在しているなら、どんなメディアレベル指定もセッションレベル指定を置き換えなければなりません。
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-形式は形式voip pkt損失rle/pkt-dup-rle/pkt-rcpt-回/スタットrcvr-rtt/概要/測定基準/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)]
損失..損失..等しい..最大..サイズ..等しい..最大..サイズ..等しい..最大..サイズ..等しい..モード..最大..サイズ..モード..送付者..スタット..概要..スタット..概要[「=」スタット旗の*、(「」、スタット旗]
Friedman, et al. Standards Track [Page 37] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[37ページ]。
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
「hl」voipスタット旗=「損失」/"dup"/"jitt"/"TTL"/測定基準=「voip-測定基準」マックス-サイズは1*ケタと等しいです。 八重奏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"属性がゼロ、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つのカテゴリの1つに属します。 最初のカテゴリ、一方的なパラメタがRTPの流れと関連する測定基準に関して単に報告するレポートブロックあります。 2番目のカテゴリ(協力的なパラメタ)がそれらの機能を行うために1回以上のパーティーによる動作にかかわる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データ・パケット受信機はReceiver Reference Time Report Block(セクション4.4)を送ります。 このブロックを受け取る関係者は応答でDLRR Report Block(セクション4.5)を送ります、その関係者にRTTについて計算するために受信機を許容して。 この例が例証するように、協力的な機能性は2つ以上の異なったXRブロック以上実行されるかもしれません。 いくつかのXRブロックの協力的な機能性はただ一つの"rtcp-xr"パラメタによって決定されるかもしれません。
For the unilateral category, this document defines the following parameters. The parameter names and their corresponding XR formats are as follows:
一方的なカテゴリのために、このドキュメントは以下のパラメタを定義します。 パラメタ名とそれらの対応するXR形式は以下の通りです:
Parameter name XR block (block type and name)
-------------- ------------------------------------
pkt-loss-rle 1 Loss RLE Report Block
pkt-dup-rle 2 Duplicate RLE Report Block
pkt-rcpt-times 3 Packet Receipt Times Report Block
stat-summary 6 Statistics Summary Report Block
voip-metrics 7 VoIP Metrics Report Block
パラメタ名前XRブロック(ゴシック体と名前)-------------- ------------------------------------ pkt損失rle1Loss RLE Report Block pkt-dup-rle2Duplicate RLE Report Block pkt-rcpt-回の3Packet ReceiptタイムズReport Blockスタット概要6Statistics Summary Report Block voip-測定基準7VoIP Metrics Report Block
Friedman, et al. Standards Track [Page 38] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[38ページ]。
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-回」パラメタは整数値を指定するかもしれません。 この値は全体のレポートブロックSHOULDが八重奏で持っている中で最も大きいサイズを示します。 これは間引きが必要なら、目標サイズを達成するために適用されるものとするという指示と考えられるものとします。
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:
「スタット概要」パラメタはどの分野SHOULDが送られるStatistics Summaryレポートブロックに含まれているかを示すリストを含んでいます。 リストは1つ以上のフィールド標識を含むコンマの切り離されたリストです。 キャラクタ(0×20)SHALL NOTを区切ってください。リストの中に存在してください。 フィールド標識はセクション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)
インディケータ旗--------- --------------------------- 損失損害報告旗の(L)dupはjittジター旗(J)のTTL TTL、Hop Limit旗(ToH)のHL TTLまたはHop Limitが旗を揚げさせるレポート旗(D)をコピーします。(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"に関しては、インディケータの存在は、対応する旗が送られるStatistics Summaryレポートブロックの1に設定されるべきであるのを示します。 "TTL"の存在は、対応する旗が1に設定されるべきであるのを示します。 「hl」の存在は、対応する旗が2に設定されるべきであるのを示します。 インディケータ"TTL"と「hl」に一緒に合図してはいけません。
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.
協力的なカテゴリにおけるブロックは創始者ブロックか応答ブロックとして分類されます。 シグナリングSHOULDは、どの関係者が創始者ブロックに応じるのが必要であるかを示します。 それらの関係者から応答ブロックを受け取りたがっているパーティーは、創始者ブロックを送ることによって、これの引き金となることができます。
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
協力的なカテゴリは現在、すなわち、1つの機能性、RTPデータ受信装置のためのRTT測定メカニズムだけから成ります。 Receiver Reference Time Report BlockとDLRR Report Blockの集合的な機能性は"rcvr- rtt"パラメタによって表されます。 このパラメタは議論としてDLRRレポートブロックに最頻値と任意に最大サイズをみなします。 最頻値「すべて」は、RTPデータ送付者とデータ受信装置の両方がブロックをDLRRに送るかもしれないのを示します、最頻値「送付者」が、活発なRTP送付者だけがブロックをDLRRに送るかもしれないのを示しますがすなわち、非RTPの送付者SHALL NOTはブロックをDLRRに送ります。 八重奏における最大サイズが含まれているなら、SHALL NOTが送られるどんなDLRR Report Blocksも指定されたサイズを超えています。 サイズ制限が、DLRR Report Block送付者が一区画で、それがそうしたすべての関係者について報告できるというわけではないことを意味するなら
Friedman, et al. Standards Track [Page 39] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[39ページ]。
received a Receiver Reference Time Report Block then it SHOULD report on participants in a round robin fashion across several report intervals.
Receiver Reference Time Report Blockが受けた、そして、それはいくつかのレポート間隔の向こう側にaの関係者の上でコマドリファッションを一周させますSHOULDが、報告する。
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のそれがすべてのXRを使用するのを止めたがっているアプリケーションは発信するという再INVITEメッセージの取り外すのによるすべての適切なSDPパラメタを妨げます。 XRブロックがセッションの始まりから全く使用されないことであるなら、"rtcp-xr"属性が全く供給されないのは、RECOMMENDEDです。
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"属性が存在しているとき、関係者SHOULD NOTはパラメタによって示されたもの以外のブロックをXRに送ります。 これが、少しもパラメタのない"rtcp-xr"属性の包含がそれを関係者に言うことを意味する、それ、SHOULD NOTは全くどんなXRブロックも送ります。 目的は帯域幅を保存することです。 協力的なパラメタが大きいマルチキャストグループに適用されるとき、これは特に重要です: 1つの創始者ブロックの発信はすべての関係者から応答の潜在的に引き金となるかもしれません。 しかしながら、それがパラメタシグナリングがないときXRブロックを送る意味を使用にする文脈があります。 例えば、アプリケーションは、交渉なしである一定のレポートブロックを送るように他のブロックの使用を交渉すると合図するSDPを使用している間、設計されるかもしれません。
5.2. Usage in Offer/Answer
5.2. 申し出/答えにおける用法
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.
Offer/答え文脈[8]では、XRパケットのために合図するSDPの解釈を合図される指示属性に依存します: "recvonly"、"sendrecv"、または"sendonly"[4]。 指示属性を全く供給しないなら、"sendrecv"を想定します。 有名であるところを除いて、このセクションはユニキャストメディアの流れだけに適用されます。 このセクションでの協力的なパラメタの議論は一方的なパラメタの議論のあとに続いています。
For "sendonly" and "sendrecv" media stream offers that specify unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send the corresponding XR blocks. For "sendrecv" offers, the answerer MAY include the "rtcp-xr" attribute in its response, and specify any unilateral parameters in order to request that the offerer send the corresponding XR blocks. The offerer SHOULD send these blocks.
一方的な"rtcp-xr"属性パラメタを指定する流れが提供する"sendonly"と"sendrecv"メディアのために、answerer SHOULDは対応するXRブロックを送ります。 "sendrecv"申し出として、answererは、申出人が対応するXRブロックを送るよう要求するために応答に"rtcp-xr"属性を含んで、どんな一方的なパラメタも指定するかもしれません。 申出人SHOULDはこれらのブロックを送ります。
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
流れが提供する"recvonly"メディアのために、申出人の一方的なパラメタに関する"rtcp- xr"属性の使用は、申出人が対応するXRブロックを送ることができるのを示します。 if
Friedman, et al. Standards Track [Page 40] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[40ページ]。
the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD send XR blocks for each specified unilateral parameter that was in its offer.
answererは"rtcp-xr"属性で応じて、申出人SHOULDはそれぞれの申し出中である一方的な指定されたパラメタのためのブロックを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"属性の包含は、すべてのメディア受取人SHOULDが対応する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"パラメタを指定する申し出は、申出人がReceiver Reference Time Report Blocksを受け取って、DLRR Report Blocksを送る用意ができていることを意味します。 協力的なパラメタの申し出は、answererが創始者を送るかもしれないことを意味します、そして、創始者を受けたので、申出人SHOULDは応答を送ります。
There are exceptions to the rule that an offerer of a collaborative parameter should send responses. For instance, the collaborative parameter might specify a mode that excludes the offerer; or congestion control or maximum transmission unit considerations might militate against the offerer's response.
協力的なパラメタの申出人が応答を送るべきであるという規則への例外があります。 例えば、協力的なパラメタは申出人を除くモードを指定するかもしれません。 または、輻輳制御かマキシマム・トランスミッション・ユニット問題は申出人の応答に影響するかもしれません。
By including a collaborative parameter in its answer, the answerer declares its ability to receive initiators and to send responses. The offerer MAY then send initiators, to which the answerer SHOULD reply with responses. As for the offer of a collaborative parameter, there are exceptions to the rule that the answerer should reply.
答えに協力的なパラメタを含んでいることによって、answererは創始者を受けて、応答を送る性能を宣言します。 そして、申出人は創始者を送るかもしれません。(answerer SHOULDは応答でその創始者に返答します)。 協力的なパラメタの申し出に関して、answererが返答するはずであるという規則への例外があります。
When making an SDP offer of a collaborative parameter for a multicast media stream, the offerer SHOULD specify which participants are to respond to a received initiator. A participant that is not specified SHOULD NOT send responses. Otherwise, undue bandwidth might be consumed. The offer indicates that each participant that is specified SHOULD respond if it receives an initiator. It also indicates that a specified participant MAY send an initiator block.
マルチキャストメディアの流れのための協力的なパラメタのSDP申し出をするとき、申出人SHOULDは、容認された創始者に応じるために関係者がどれであるかを指定します。 指定されたSHOULD NOTでない関係者は応答を送ります。 さもなければ、過度の帯域幅は消費されるかもしれません。 申し出は、創始者を受けるなら指定されたSHOULDである各関係者が応じるのを示します。 また、それは、指定された関係者が創始者ブロックを送るかもしれないのを示します。
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.
マルチキャストメディアがSHOULDを流すので、SDP答えは申し出で存在していて、answererによって支持されるすべての協力的なパラメタを含んでいます。 それ、SHOULD NOTはどんな申し出で欠けている協力的なパラメタも含んでいます。
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を実行したくないなら、答えSHOULDはパラメタなしで"rtcp-xr"属性を含んでいます。 そうすることによって、パーティーは、それが最小限でシグナリングを理解できると宣言します。
Friedman, et al. Standards Track [Page 41] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[41ページ]。
5.3. Usage Outside of Offer/Answer
5.3. 申し出/答えにおける外の用法
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.
例えば、レアルTime Streamingプロトコル(RTSP)[17]を通してSession Announcementプロトコル(SAP)[15]を通して発表されるか、または流されるマルチメディアセッションにOffer/答え文脈の外でSDPを使うことができます。 送付者がパラメタを交渉しないとき、シグナリングモデルは、より簡単ですが、"rtcp-xr"属性を指定するので予想された機能性はOffer/答えと同じです。
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"属性に指定されるかはメディアの流れ(SHOULDが対応するXRブロックを送るその流れの受信機)と交際しました。 協力的なパラメタが指定されるとき、協力的なパラメタの最頻値で示された関係者だけが関係があります。 SHOULDが対応する応答ブロックを送る創始者ブロックを受け取るそのような各関係者。 また、そのような各関係者はブロックを創始者に送るかもしれません。
6. IANA Considerations
6. IANA問題
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.
このドキュメントは新しいRTCPパケットタイプを定義します、とExtended Report(XR)はタイプします、RTP RTCP Control Packet Typesの既存のインターネットAssigned民数記Authority(IANA)登録の中で。 また、このドキュメントは新しいIANA登録を定義します: RTCP XR Block Typesの登録。 この新しい登録の中では、このドキュメントは、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 Parametersの既存のIANA登録の中で新しいSDP属性、"rtcp-xr"を定義します。 それは、新しいIANA登録、RTCP XR SDP Parametersの登録、および6つのパラメタの始発を定義して、割り当てる追加パラメタがことである方法を説明します。
6.1. XR Packet Type
6.1. XRパケットタイプ
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).
RTP RTCP Control Packetの登録のパケットタイプ207がタイプするように(太平洋標準時の)このドキュメントによって定義されたXRパケットタイプはIANAに示されます。
6.2. RTCP XR Block Type Registry
6.2. RTCP XRゴシック体登録
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
このドキュメントはセクション3で指定されたExtended Reportゴシック体(BT)分野の名前スペースをカバーするためにRTCP XR Block Type Registryと呼ばれるIANA登録を作成します。 256の値を許容して、BT分野は8ビットを含んでいます。 Specification Required方針によると、RTCP XR Block Type RegistryはIANAによって管理されることになっています。
Friedman, et al. Standards Track [Page 42] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[42ページ]。
RFC 2434 [7]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document:
RFC2434[7]。 本書では結果と考えられた値に続いて、将来の仕様SHOULDは厳しい数値オーダーにおけるゴシック体値を結果と考えます:
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
BT名------ 1 損失RLEレポートブロック2写しRLEは、3つのブロックパケット領収書回数、4つのレポートブロック受信機参照時間レポートブロック5DLRRが概略報告ブロック7VoIP測定基準レポートが妨げるブロック6つの統計を報告すると報告します。
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.
その上、将来の仕様SHOULDは値0を避けます。 そうするのはオールゼロ分野が不適格なパケットで一般的に見つけられるかもしれないのでチェックするパケットの正当性を容易にします。
Any registration MUST contain the following information:
どんな登録も以下の情報を含まなければなりません:
- Contact information of the one doing the registration, including
at least name, address, and email.
- 少なくとも名前、アドレス、およびメールを含む登録をするものの問い合わせ先。
- The format of the block type being registered, consistent with the
extended report block format described in Section 3.
- セクション3で説明される拡張レポートブロックフォーマットと登録されて、一致したゴシック体の形式。
- A description of what the block type represents and how it shall
be interpreted, detailing this information for each of its fields.
- ゴシック体が何を表すか、そして、それぞれの分野のためのこの情報を詳しく述べて、それがどのように解釈されるものとするかに関する記述。
6.3. The "rtcp-xr" SDP Attribute
6.3. "rtcp-xr"SDP属性
The SDP attribute "rtcp-xr" defined by this document is registered with the IANA registry of SDP Parameters as follows:
SDP ParametersのIANA登録は以下の通りでこのドキュメントによって定義されたSDP属性"rtcp-xr"は登録されます:
SDP Attribute ("att-field"):
SDPは(「att-分野」)を結果と考えます:
Attribute name: rtcp-xr
Long form: RTP Control Protocol Extended Report Parameters
Type of name: att-field
Type of attribute: session and media level
Subject to charset: no
Purpose: see Section 5 of this document
Reference: this document
Values: see this document and registrations below
名前を結果と考えてください: rtcp-xr Longは形成します: 名前のRTP ControlプロトコルExtended Report Parameters Type: 属性のatt-分野Type: セッションとメディアはcharsetにSubjectを平らにします: Purposeがありません: このドキュメントReferenceのセクション5を見てください: このドキュメントValues: このドキュメントと以下の登録証明書を見てください。
Friedman, et al. Standards Track [Page 43] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[43ページ]。
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 Parameters Registryと呼ばれるIANA登録を作成します。 それはセクション5.1で定義された6つのパラメタを含んでいます: 「pkt損失rle」、"pkt-dup-rle"、「pkt-rcpt-回」、「スタット概要」、「voip-測定基準」、および"recv-rtt"。
Additional parameters are to be added to this registry in accordance with the Specification Required policy of RFC 2434 [7]. Any registration MUST contain the following information:
追加パラメタはRFC2434[7]のSpecification Required方針によると、この登録に加えられることです。 どんな登録も以下の情報を含まなければなりません:
- Contact information of the one doing the registration, including
at least name, address, and email.
- 少なくとも名前、アドレス、およびメールを含む登録をするものの問い合わせ先。
- An Augmented Backus-Naur Form (ABNF) [2] definition of the
parameter, in accordance with the "format-ext" definition of
Section 5.1.
- セクション5.1の「形式-ext」定義に従ったパラメタのAugmented BN記法(ABNF)[2]定義。
- A description of what the parameter represents and how it shall be
interpreted, both normally and in Offer/Answer.
- パラメタが何を表すか、そして、それが通常とOffer/答えでどのように解釈されるものとするかに関する記述。
7. Security Considerations
7. セキュリティ問題
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、Appendix 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 Metrics Report Blockは例を提供します。
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.
Loss RLE、Duplicate RLE、およびPacket ReceiptタイムズReport Blocksに含まれた1パケットあたりの情報はネットワークの特性(ミンツ)の[11]のマルチキャスト推論を容易にします。 そのような推論はマルチキャスト分配木の総計のトポロジーを明らかにすることができます、パラメタと同様に、損失率や遅れのように、その木の分岐ポイントの間の経路に沿って。 そのような情報は自律システム管理者にとって敏感であると考えられるかもしれません。
The VoIP Metrics Report Block provides information on the quality of ongoing voice calls. Though such information might be carried in an application specific format in standard RTP sessions, making it available in a standard format here makes it more available to potential eavesdroppers.
VoIP Metrics Report Blockは進行中の音声通話の品質の情報を提供します。 そのような情報は標準のRTPセッションのときにアプリケーションの特定の形式で運ばれるかもしれませんが、ここでそれを標準書式で利用可能にするのに、それは潜在的立ち聞きする者には、より利用可能になります。
Friedman, et al. Standards Track [Page 44] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[44ページ]。
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.
どんな新しいメカニズムも、秘密性を確実にするために本書では紹介されません。 秘密性が関心であるときに、このドキュメントが書かれた時にSecure 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 Report Blocksをコード化するためにトンネルを確立するネットワークはトンネルによって横断されたサービスプロバイダーに対してその情報を否定します。 次に、サービスプロバイダーは、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.
また、拡大は、より簡単な状態でサービス不能攻撃を確実にします。 これが平均より大きい状態でRTCPパケット多くを作成する可能性のためにそうである、Loss RLE、Duplicate RLE、およびTimestamp Report Blocksのパケット報告能力単位で。 RTCPの自動帯域幅調整機構のために、何人かのセッション関係者が大きいRTCPパケットを送ると、すべての関係者が、彼らのRTCPが、間隔が伸されたと報告しているのを見るでしょう、彼らがどんなより頻繁にも報告できない意味。 サービス不能攻撃がないときでさえ大きいパケットの効果を制限するために、アプリケーションSHOULDはそれらが使うXRレポートブロックのサイズに関して上限を課します。 セクション4.1で説明された「間引き」のテクニックは、パケットごとのレポートブロックが事前に定義されたサイズ限界を固く守るのを許容します。
Friedman, et al. Standards Track [Page 45] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[45ページ]。
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によって示されたアルゴリズムです。 それはLoss RLE Report Blocksの世代に必要である会計実務を実行します。
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ビットの一連番号の動向をおさえます。 ソースから受け取られた最初のパケットが手荒くそのスペースの中央に到着したと考えられます。 続く各パケットはものの前かこの32ビットのスペースの先のものの後ろに置かれます、どの選択が、より近く(繋がりの場合、どの選択が16ビットの一連番号におけるロールオーバーを必要としない)にそれを置くだろうかによって。
// 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;
//、参照一連番号は16ビットの新しい//一連番号が、より早期か後で//スペース32ビットの系列u_int32_src_審判_で来るかどうか決定する基礎としてのサーブがseqする拡張配列数//です。 bool_は_src_審判_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) {
. 最もありそうな位置のu_int32への//ヒューリスティックに基づく32ビットの一連番号スペースへの//場所seqは_seq(const u_int16 seq)を広げています。
u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b;
if(_uninitialized_src_ref_seq) {
u_int32は_seq、seq、seq_b、デフ、デフ_bを広げました。 (_非初期化している_src_審判_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 {
//、これは受け取られた最初の一連番号です。 それが広げることの中央で数の//スペースを配列する場所//。 _src_審判_seq=seq| 0x80000000u。 __src_審判_seqを= 虚偽で非初期化しました。 拡張_seqは_src_審判_seqと等しいです。 ほか
// 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;
//先の一連番号を受け取りました。 //は拡張配列//番号の2人の候補を提案します: seqが巻きつけて着るドレスなしであって、//巻きつけて着るドレスseqがあるseq_bはseqと等しいです。| (_src_審判_seqと0xFFFF0000u)。 if(_src_ref_seq < seq_a) { seq_b = seq_a - 0x00010000u; diff_a = seq_a - _src_ref_seq;
Friedman, et al. Standards Track [Page 46] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[46ページ]。
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;
}
デフ_bは_src_審判_seqと等しいです--seq_b ほかseq_bはseq+0x00010000uと等しいです。 デフは_src_審判_seqと等しいです--seq 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;
}
//は、より近い候補を選びます。 それらが等しく//近いなら、選択はいくらか任意です: 私たちがロールオーバーがないのが必要である候補を//に選ぶ、(デフ<デフ_b)である、拡張_seq=seq;、ほか拡張_seq=seq_b。
// Set the reference sequence number to be this most
// recently-received sequence number.
_src_ref_seq = extended_seq;
}
//は、参照一連番号にほとんどの最近//容認された一連番号にこれであるように設定します。 _src_審判_seq=は_seqを広げました。 }
// Return our best guess for a 32-bit sequence number that
// corresponds to the 16-bit number we were given.
return extended_seq;
}
/が私たちのベストを返す/は、32ビットの一連番号のために//が私たちが与えられた16ビットの数に対応すると推測します。リターンは_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 Metrics Report Block(セクション4.7)のために炸裂の特性を測定するためのアルゴリズムです。 アルゴリズム(正当性のための働く実現に対して確かめられた)はETSI TS101 329-5[3]から再生します。 ここで説明されるアルゴリズムはこれから結局アルゴリズムにされるどんな変更にもETSIドキュメントに優先します。
This algorithm is event driven and hence extremely computationally efficient.
このアルゴリズムは、イベントドリブンであってしたがって、非常に計算上効率的です。
Given the following definition of states:
州の以下の定義を与えます:
state 1 = received a packet during a gap
state 2 = received a packet during a burst
state 3 = lost a packet during a burst
state 4 = lost an isolated packet during a gap
炸裂州4の=の間の無くなっているa炸裂状態3の間の容認されたaギャップ状態2の間の容認されたa状態1=パケット=パケット=パケットはギャップの間、孤立しているパケットを失いました。
Friedman, et al. Standards Track [Page 47] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[47ページ]。
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の精度に1組の状態遷移カウントの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"は最後のパケットが無くなると宣言されたか、または捨てられて、「喪失」が現在の炸裂の中で失われたパケットの数であるので受け取られたパケットのカウントです。 「パケット_は負け」て「パケット_は捨てたこと」が、呼び出されるこの機能をもたらした出来事が無くなっているか捨てられたパケットであったかどうかを示すブール変数です。
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;
}
(パケット_無くなる)、損失_カウント++;、(パケット_は捨てられました)、破棄_カウント++;、(パケット_が負けた、パケット_が捨てられた、)、pkt++;、ほか(pkt>=gmin)である、(無くなっている=1)である、c14++;、ほか、c13++; 無くなっている=1; c11+=pkt;、ほか、(pkt=0)であるなら+ +を失う、c33++;、ほかのc23++; c22+=(pkt--1);、pkt=0。
At each reporting interval the burst and gap metrics can be calculated as follows.
それぞれの報告間隔を置いて、以下の通り炸裂とギャップ測定基準について計算できます。
Friedman, et al. Standards Track [Page 48] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[48ページ]。
// Calculate additional transition counts. c31 = c13; c32 = c23; ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;
//は追加変遷カウントについて計算します。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);
//は炸裂と密度について計算します。p32はc32/(c31+c32+c33)と等しいです。 (c22+c23) <1) p23=1; p23の=1--c22/(c22+c23);はほかの256*p23_密度=/(p23+p32)を押し破きました。 ギャップ_密度は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;
//は_ms*framesPerRTPPktのms m=frameDuration_で炸裂とギャップ持続時間について計算します。 ギャップ_長さは*m/c13と等しいです(c11+c14+c13)。 炸裂_長さはctotal*m/c13と等しいです--lgap
/* calculate loss and discard rates */ loss_rate = 256 * loss_count / ctotal; discard_rate = 256 * discard_count / ctotal;
/*は損失を見込みます、そして、破棄は*/損失_レート=256*損失_がカウント/ctotalであると評定します。 _レート=256*破棄_カウント/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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP11[5]で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を記述してください。
Friedman, et al. Standards Track [Page 49] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[49ページ]。
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。 作者の間の共同を伸ばすのを助けるためのスーMoon。 報告に関する私たちの留意が必要とするMLDAの図面のためのMounir Benzaid。 私たちがMLDAを組み込むよう奨励するためのDorgham SisalemとアダムWoliszはタイプを妨げます。 そして、SDP Signaling部の貴重なレビューのためのホセ・レイ。
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の研究アラン・クラーク、Telchemyロバート・G.コール、JHU応用物理研究所のニック・ダッフィールド、ティムール・フリードマン、AT&Tの研究室研究パリ6Kaynamヘダーヤト、果物の糖度の単位はカーミルSarac、ユタダラスマグヌスWesterlund、エリクソンをネットワークでつなぎます。
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
秒は、主要な貢献者を妨げるように報告します。---- ------------ ---------------------- 4.1 損失RLEレポートBlockフリードマン、カセレス、ダッフィールド4.2・写しRLEレポートBlockフリードマン、カセレス、ダッフィールド4.3のパケット領収書回数・レポートBlockフリードマン、カセレス、レポートブロックフリードマン4.5DLRRがブロックフリードマン4.6統計概略報告ブロックAlmerothを報告するダッフィールド4.4受信機参照時間、Sarac4.7VoIP測定基準レポートはクラークを妨げます、コール、ヘダーヤト
The principal person to contact regarding the SDP signaling described in this document is Magnus Westerlund.
本書では説明されたSDPシグナリングに関して連絡する主要な人はマグヌスWesterlundです。
Friedman, et al. Standards Track [Page 50] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[50ページ]。
References
参照
Normative References
引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[2] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[3] ETSI, "Quality of Service (QoS) measurement methodologies", ETSI
TS 101 329-5 V1.1.1 (2000-11), November 2000.
[3] ETSI、「Service(QoS)測定方法論の品質」、ETSI TS101 329-5V1.1.1(2000-11)、2000年11月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[4] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[5] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[5] ハービとR.とS.ブラドナー、「IETF標準化過程にかかわる組織」、BCP11、RFC2028、1996年10月。
[6] ITU-T, "The E-Model, a computational model for use in
transmission planning", Recommendation G.107, January 2003.
2003年1月の[6] ITU-T、「E-モデル、トランスミッション計画における使用のためのコンピュータのモデル」Recommendation G.107。
[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問題部に書くためのガイドライン」BCP26、RFC2434(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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[9]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、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-Aトランスミッション要件は、デジタルワイヤーライン電話、2000年12月をIPの上で声に出して、PCMの上で声に出します。
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.、ダッフィールド、N.G.、フリードマン、T.、ホロビッツ、J.、Loプレスティ、F.、月、S.B.、パクソン、V.、およびD.Towsley、「終わりから終わりへのマルチキャスト測定値の内部のネットワークの振舞いを特徴付ける使用」(IEEEコミュニケーション雑誌)は2000がそうするかもしれません。
[12] Baugher, McGrew, Oran, Blom, Carrara, Naslund and Norrman, "The
Secure Real-time Transport Protocol", Work in Progress.
[12] 「安全なリアルタイムのトランスポート・プロトコル」というBaugher、マグリュー、オラン、ブロム、カラーラ、ジーター、およびNorrmanは進行中で働いています。
Friedman, et al. Standards Track [Page 51] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[51ページ]。
[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 Infocom2002。
[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.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[16] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an
On-line Database", RFC 3232, January 2002.
[16] レイノルズ、J.、エド、「数は割り当てられました」。 「RFC1700はOn-線DatabaseによるReplacedです」、RFC3232、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)」、RFC2326 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。 IWQoS2000。
Friedman, et al. Standards Track [Page 52] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[52ページ]。
Authors' Addresses
作者のアドレス
Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106 USA
ケビンAlmerothカリフォルニア大学のサンタバーバラ、コンピュータサイエンス学部カリフォルニア93106米国
EMail: almeroth@cs.ucsb.edu
メール: almeroth@cs.ucsb.edu
Ramon Caceres IBM Research 19 Skyline Drive Hawthorne, NY 10532 USA
ラモンカセレスIBM Research19地平線ドライブサンザシ、ニューヨーク10532米国
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マーティンズ農道、200Suwanee、スイートGA30024米国を法人組織にしました。
Phone: +1 770 614 6944 Fax: +1 770 614 3951 EMail: alan@telchemy.com
以下に電話をしてください。 +1 770 614、6944Fax: +1 3951年の770 614メール: 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ジョーンズ・ホプキン・Road MD20723-6099ローレル(米国)
Phone: +1 443 778 6951 EMail: robert.cole@jhuapl.edu
以下に電話をしてください。 +1 6951年の443 778メール: 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研究室Research180Parkアベニュー、私書箱971Florham公園にニュージャージー07932-0971米国に傷を付けてください。
Phone: +1 973 360 8726 Fax: +1 973 360 8050 EMail: duffield@research.att.com
以下に電話をしてください。 +1 973 360、8726Fax: +1 8050年の973 360メール: duffield@research.att.com
Friedman, et al. Standards Track [Page 53] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[53ページ]。
Timur Friedman Universite Pierre et Marie Curie (Paris 6) Laboratoire LiP6-CNRS 8, rue du Capitaine Scott 75015 PARIS France
ティムールフリードマン・Universiteピアー・etキュリー夫人(パリ6)Laboratoire LiP6-CNRS8、悔悟du 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、Fax: +33 1 44 27 74 95はメールされます: timur.friedman@lip6.fr
Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA
Kaynamヘダーヤト果物の糖度の単位ネットワーク285はRoad MA01824チェルムズフォード(米国)を製粉します。
Phone: +1 978 367 5600 Fax: +1 978 367 5700 EMail: khedayat@brixnet.com
以下に電話をしてください。 +1 978 367、5600Fax: +1 5700年の978 367メール: 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
ダラステキサス75083-0688リチャードソン(米国)のカーミルSaracコンピュータサイエンス学部エリックイェンソン工学部とコンピュータサイエンステキサス大(ES4.207)
Phone: +1 972 883 2337 Fax: +1 972 883 2349 EMail: ksarac@utdallas.edu
以下に電話をしてください。 +1 972 883、2337Fax: +1 2349年の972 883メール: ksarac@utdallas.edu
Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm Sweden
マグヌスWesterlundエリクソン研究エリクソン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、Fax: +46 8 757 55 50はメールされます: magnus.westerlund@ericsson.com
Friedman, et al. Standards Track [Page 54] RFC 3611 RTCP XR November 2003
フリードマン、他 規格はRTCP XR2003年11月にRFC3611を追跡します[54ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Friedman, et al. Standards Track [Page 55]
フリードマン、他 標準化過程[55ページ]
一覧
スポンサーリンク
