[要約] RFC 7509は、RTP制御プロトコル（RTCP）拡張レポート（XR）の一部であり、修復後の損失カウントメトリクスに関する情報を提供します。このRFCの目的は、ネットワーク上でのパケット損失の評価とモニタリングを向上させることです。
Internet Engineering Task Force (IETF) R. Huang
Request for Comments: 7509 Huawei
Category: Standards Track V. Singh
ISSN: 2070-1721 Aalto University
May 2015
RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics
RTP Control Protocol（RTCP）Extended Report（XR）for Post-Repair Loss Count Metrics
Abstract
概要
This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows reporting of a post-repair loss count metric for a range of RTP applications. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count when needed, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system.
このドキュメントでは、RTP制御プロトコル（RTCP）拡張レポート（XR）ブロックを定義して、一連のRTPアプリケーションの修復後の損失カウントメトリックのレポートを可能にします。さらに、このレポートブロックには、必要に応じて修理前の損失数を計算するための別のメトリックである修理済み損失数も導入されているため、RTP送信者またはサードパーティエンティティは、使用する修理方法の有効性を評価できます。システムによって。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7509.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7509で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Post-Repair Loss Count Metrics Report Block .....................3
3.1. Report Block Structure .....................................4
3.2. Example Usage ..............................................5
4. SDP Signaling ...................................................6
4.1. SDP rtcp-xr-attrib Attribute Extension .....................6
4.2. Offer/Answer Usage .........................................7
5. Security Considerations .........................................7
6. IANA Considerations .............................................7
6.1. New RTCP XR Block Type Value ...............................7
6.2. New RTCP XR SDP Parameter ..................................7
6.3. Contact Information for Registrations ......................7
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................9
Appendix A. Metrics Represented Using the Template from RFC 6390 ..10
Acknowledgments ...................................................11
Authors' Addresses ................................................11
RTCP Sender Reports (SRs) / Receiver Reports (RRs) [RFC3550] contain some rough statistics about the data received from the particular source indicated in that block. One of them is the cumulative number of packets lost, which is called the pre-repair loss metric in this document. This metric conveys information regarding the total number of RTP data packets that have been lost since the beginning of the RTP session.
RTCP送信者レポート（SR）/受信者レポート（RR）[RFC3550]には、そのブロックで示された特定のソースから受信したデータに関する大まかな統計が含まれています。それらの1つは、失われたパケットの累積数です。これは、このドキュメントでは修復前の損失メトリックと呼ばれています。このメトリックは、RTPセッションの開始以降に失われたRTPデータパケットの総数に関する情報を伝えます。
However, this metric is measured on the media stream before any loss-repair mechanism, e.g., retransmission [RFC4588] or Forward Error Correction (FEC) [RFC5109], is applied. Using a repair mechanism usually results in recovering some or all of the lost packets. The recovery process does not reduce the values reported by the two loss metrics in RTCP RR [RFC3550] -- namely, the fraction lost and the cumulative loss. Hence, the sending endpoint cannot infer the performance of the repair mechanism based on the aforementioned metrics in [RFC3550].
ただし、この測定基準は、再送[RFC4588]または転送エラー訂正（FEC）[RFC5109]などの損失修復メカニズムが適用される前に、メディアストリームで測定されます。通常、修復メカニズムを使用すると、失われたパケットの一部またはすべてが回復されます。回復プロセスは、RTCP RR [RFC3550]の2つの損失メトリックによって報告される値、つまり、損失率と累積損失を削減しません。したがって、送信エンドポイントは、[RFC3550]の前述のメトリックに基づいて修復メカニズムのパフォーマンスを推測できません。
Consequently, [RFC5725] specifies a post-repair loss Run-Length Encoding (RLE) XR report block to address this issue. The sending endpoint is able to infer which packets were repaired from the RLE report block, but the reporting overhead for the packet-by-packet report block is higher compared to other report blocks.
したがって、[RFC5725]は、この問題に対処するために、修復後の損失のRun-Length Encoding（RLE）XRレポートブロックを指定しています。送信エンドポイントはRLEレポートブロックから修復されたパケットを推測できますが、パケットごとのレポートブロックのレポートオーバーヘッドは他のレポートブロックと比較して高くなります。
When applications use multiple XR blocks, the endpoints may require more concise reporting to save bandwidth. This document defines a new XR block type to augment those defined in [RFC3611] and complement the report block defined in [RFC5725] for use in a range of RTP applications. This new block type reports the post-repair loss count metric, which records the number of primary source RTP packets that are still lost after applying one or more loss-repair mechanisms. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count during this range, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system. The metrics defined in this document are packet level rather than slice/picture level; this means the partial recovery of a packet will not be regarded as a repaired packet.
アプリケーションが複数のXRブロックを使用する場合、エンドポイントは帯域幅を節約するために、より簡潔なレポートを必要とする場合があります。このドキュメントは、新しいXRブロックタイプを定義して、[RFC3611]で定義されたものを補強し、[RFC5725]で定義されたレポートブロックを補完して、さまざまなRTPアプリケーションで使用できるようにします。この新しいブロックタイプは、修復後の損失カウントメトリックを報告します。これは、1つ以上の損失修復メカニズムを適用した後も失われたプライマリソースRTPパケットの数を記録します。さらに、RTP送信者またはサードパーティエンティティが修復方法の有効性を評価できるように、このレポートブロックには、この範囲で修復前の損失数を計算するための別のメトリック、修復済み損失数も導入されています。システムによって使用されます。このドキュメントで定義されているメトリックは、スライス/画像レベルではなくパケットレベルです。つまり、パケットの部分的な回復は修復されたパケットとは見なされません。
The metrics defined in this document belong to the class of transport-related metrics defined in [RFC6792] and are specified in accordance with the guidelines in [RFC6390] and [RFC6792]. These metrics are applicable to any RTP application, especially those that use loss-repair mechanisms.
このドキュメントで定義されているメトリックは、[RFC6792]で定義されているトランスポート関連メトリックのクラスに属し、[RFC6390]および[RFC6792]のガイドラインに従って指定されています。これらのメトリックは、RTPアプリケーション、特に損失修復メカニズムを使用するアプリケーションに適用できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
primary source RTP packet: The original RTP packet sent from the RTP sender for the first time. A lost primary source RTP packet may be repaired by some other RTP packets used in repair mechanisms like FEC or retransmission.
プライマリソースRTPパケット：RTP送信者から初めて送信された元のRTPパケット。失われたプライマリソースRTPパケットは、FECや再送信などの修復メカニズムで使用される他の一部のRTPパケットによって修復される場合があります。
This block reports the number of packets lost after applying repair mechanisms (e.g., FEC). It complements the RTCP XR metrics defined in [RFC5725]. As noted in [RFC5725], ambiguity may occur when comparing this metric with a pre-repair loss metric reported in an RTCP SR/RR, i.e., some packets were not repaired in the current RTCP interval, but they may be repaired later. Therefore, this block uses a begin sequence number and an end sequence number to explicitly indicate the actual sequence number range reported by this RTCP XR. Accordingly, only packets that have no further chance of being repaired and that have been repaired are included in this report block.
このブロックは、修復メカニズム（FECなど）の適用後に失われたパケットの数を報告します。 [RFC5725]で定義されているRTCP XRメトリックを補完します。 [RFC5725]で述べられているように、このメトリックをRTCP SR / RRで報告された修復前の損失メトリックと比較すると、あいまいさが発生する可能性があります。したがって、このブロックは開始シーケンス番号と終了シーケンス番号を使用して、このRTCP XRによって報告された実際のシーケンス番号の範囲を明示的に示します。したがって、これ以上修復される可能性がなく、修復されたパケットのみがこのレポートブロックに含まれます。
The Post-Repair Loss Count Metrics Report Block has the following format:
修復後の損失カウントメトリックレポートブロックの形式は次のとおりです。
0 1 2 3 4
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=33 | Reserved | Block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Post-repair loss count | Repaired loss count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Block Type (BT): 8 bits
ブロックタイプ（BT）：8ビット
A Post-Repair Loss Count Metrics Report Block is identified by the constant 33.
修復後の損失カウントメトリックレポートブロックは、定数33で識別されます。
Reserved: 8 bits
予約済み：8ビット
These bits are reserved for future use. They MUST be set to zero by senders and ignored by receivers (see Section 4.2 of [RFC6709]).
これらのビットは将来の使用のために予約されています。送信者はゼロに設定し、受信者は無視する必要があります（[RFC6709]のセクション4.2を参照）。
Block length: 16 bits
ブロック長：16ビット
This field is in accordance with the definition in [RFC3611]. In this report block, it MUST be set to 4. The block MUST be discarded if the block length is set to a different value.
このフィールドは、[RFC3611]の定義に準拠しています。このレポートブロックでは、4に設定する必要があります。ブロック長が別の値に設定されている場合、ブロックを破棄する必要があります。
SSRC of source: 32 bits
ソースのSSRC：32ビット
As defined in Section 4.1 of [RFC3611].
[RFC3611]のセクション4.1で定義されています。
begin_seq: 16 bits
begin_seq：16ビット
The first sequence number that this block reports on. It can remain fixed when calculating metrics over several RTCP reporting intervals.
このブロックが報告する最初のシーケンス番号。複数のRTCPレポート間隔でメトリックを計算する場合、修正されたままになる可能性があります。
end_seq: 16 bits
end_seq：16ビット
The last sequence number that this block reports on plus one.
このブロックがレポートする最後のシーケンス番号+ 1。
Post-repair loss count: 16 bits
修理後の損失カウント：16ビット
Total number of packets finally lost after applying one or more loss-repair methods, e.g., FEC and/or retransmission, during the actual sequence number range indicated by begin_seq and end_seq. This metric MUST NOT count the lost packets for which repair might still be possible. Note that this metric MUST measure only primary source RTP packets.
begin_seqとend_seqで示される実際のシーケンス番号の範囲内で、FECや再送信などの1つ以上の損失修復方法を適用した後に最終的に失われたパケットの総数。このメトリックは、修復がまだ可能である可能性がある失われたパケットをカウントしてはなりません（MUST NOT）。このメトリックは、プライマリソースRTPパケットのみを測定する必要があることに注意してください。
Repaired loss count: 16 bits
修復された損失数：16ビット
Total number of packets fully repaired after applying one or more loss-repair methods, e.g., FEC and/or retransmission, during the actual sequence number range indicated by begin_seq and end_seq. Note that this metric MUST measure only primary source RTP packets.
begin_seqおよびend_seqで示される実際のシーケンス番号の範囲内で、FECや再送信などの1つ以上の損失修復方法を適用した後に完全に修復されたパケットの総数。このメトリックは、プライマリソースRTPパケットのみを測定する必要があることに注意してください。
The metrics defined in this report block are all measured at the RTP receiver. However, the receiving endpoint can report the metrics in two different ways:
このレポートブロックで定義されたメトリックはすべて、RTPレシーバーで測定されます。ただし、受信エンドポイントは次の2つの異なる方法でメトリックを報告できます。
1) Cumulative report
1）累積レポート
In this case, implementations may set begin_seq to the first packet in the RTP session, and it will remain fixed across all reports. Hence, the "Post-repair loss count" and "Repaired loss count", respectively, will correspond to "Cumulative post-repair loss count" and "Cumulative repaired loss count" in this case. These cumulative metrics when combined with the cumulative loss metrics reported in an RTCP RR (pre-repair) assist in calculating the "Still-to-be-repaired lost packets":
この場合、実装はRTPセッションの最初のパケットにbegin_seqを設定でき、すべてのレポートで固定されたままになります。したがって、この場合、「修復後の損失数」と「修復された損失数」は、それぞれ「修復後の累積損失数」と「修復された累積損失数」に対応します。これらの累積メトリックをRTCP RR（修復前）で報告された累積損失メトリックと組み合わせると、「まだ修復されていない失われたパケット」の計算に役立ちます。
Still-to-be-repaired lost packets = Cumulative number of packets lost - Cumulative post-repair loss count - Cumulative repaired loss count
まだ修復されていない失われたパケット=失われたパケットの累積数-修復後の累積損失数-修復された累積損失数
2) Interval report
2）インターバルレポート
Some implementations may align the begin_seq and end_seq number with the highest sequence numbers of consecutive RTCP RRs (RTCP interval). This is NOT RECOMMENDED as packets that are not yet repaired in this current RTCP interval and may be repaired in the subsequent intervals will not be reported. An interval report is illustrated in the following example:
一部の実装では、begin_seqおよびend_seq番号を、連続するRTCP RRの最大シーケンス番号（RTCP間隔）に揃えます。現在のRTCP間隔でまだ修復されておらず、後続の間隔で修復される可能性のあるパケットは報告されないため、これは推奨されません。次の例は、間隔レポートを示しています。
Interval A: The extended highest sequence number received in RTCP RR is 20. Begin_seq is 10 and end_seq is 20.
インターバルA：RTCP RRで受信した拡張最大シーケンス番号は20です。Begin_seqは10で、end_seqは20です。
Interval B: The extended highest sequence number received in RTCP RR is 30. Begin_seq is 20 and end_seq is 30.
間隔B：RTCP RRで受信された拡張最大シーケンス番号は30です。Begin_seqは20で、end_seqは30です。
If packets 17 and 19 are lost and not yet repaired in interval A and subsequently repaired in interval B, they will not be reported because their sequence numbers do not belong in interval B. Therefore, if implementations want these packets to be reported as repaired, they MUST NOT align the begin_seq and end_seq to the RTCP intervals.
パケット17と19が失われ、インターバルAでまだ修復されておらず、その後インターバルBで修復された場合、シーケンス番号はインターバルBに属していないため、報告されません。それらは、begin_seqおよびend_seqをRTCP間隔に合わせてはなりません（MUST NOT）。
Alternatively, implementations may choose the begin_seq and end_seq numbers that cover several RTCP intervals. Additionally, the reported range of sequence numbers may overlap with the previous report blocks, so that the packets that were not yet repaired in one interval, but were subsequently repaired or deemed unrepairable, were reported in subsequent intervals.
あるいは、実装は、いくつかのRTCP間隔をカバーするbegin_seqおよびend_seq番号を選択できます。さらに、報告されたシーケンス番号の範囲は以前のレポートブロックと重複する場合があるため、1つの間隔ではまだ修復されなかったが、その後修復された、または修復不可能と見なされたパケットは、後続の間隔で報告されました。
In this case, the "Cumulative number of packets lost" cannot be easily compared with the post-repair metrics. However, the sending endpoint can calculate the efficiency of the error resilience algorithm using the post-repair and repaired loss count, respectively.
この場合、「失われたパケットの累積数」は、修復後のメトリックと簡単に比較できません。ただし、送信側エンドポイントは、修復後の損失数と修復された損失数をそれぞれ使用して、エラー回復アルゴリズムの効率を計算できます。
[RFC3611] defines the use of SDP (Session Description Protocol) for signaling the use of RTCP XR blocks. However, XR blocks MAY be used without prior signaling (see Section 5 of [RFC3611]).
[RFC3611]は、RTCP XRブロックの使用を通知するためのSDP（Session Description Protocol）の使用を定義しています。ただし、XRブロックは事前のシグナリングなしで使用できます（[RFC3611]のセクション5を参照）。
This session augments the SDP attribute "rtcp-xr" defined in Section 5.1 of [RFC3611] by providing an additional value of "xr-format" to signal the use of the report block defined in this document. The ABNF [RFC5234] syntax is as follows.
このセッションは、[RFC3611]のセクション5.1で定義されているSDP属性「rtcp-xr」を拡張して、このドキュメントで定義されているレポートブロックの使用を通知する「xr-format」の追加の値を提供します。 ABNF [RFC5234]の構文は次のとおりです。
xr-format =/ xr-prlr-block
xr-format = / xr-prlr-block
xr-prlr-block = "post-repair-loss-count"
xr-prlr-block = "post-repair-loss-count"
When SDP is used in offer/answer context, the SDP Offer/Answer usage defined in [RFC3611] for the unilateral "rtcp-xr" attribute parameters applies. For detailed usage of Offer/Answer for unilateral parameters, refer to Section 5.2 of [RFC3611].
SDPがオファー/アンサーコンテキストで使用される場合、片側の「rtcp-xr」属性パラメーターに対して[RFC3611]で定義されたSDPオファー/アンサーの使用法が適用されます。片側パラメーターのオファー/アンサーの詳細な使用法については、[RFC3611]のセクション5.2を参照してください。
This proposed RTCP XR block introduces no new security considerations beyond those described in [RFC3611]. This block does not provide per-packet statistics, so the risk to confidentiality documented in Section 7, paragraph 3 of [RFC3611] does not apply.
この提案されたRTCP XRブロックは、[RFC3611]で説明されているものを超える新しいセキュリティ上の考慮事項を導入していません。このブロックはパケットごとの統計を提供しないため、[RFC3611]のセクション7、パラグラフ3に記載されている機密性へのリスクは適用されません。
An attacker may put incorrect information in the Post-Repair Loss Count reports, which will affect the performance of loss-repair mechanisms. Implementers should consider the guidance in [RFC7202] for using appropriate security mechanisms, i.e., where security is a concern, the implementation should apply encryption and authentication to the report block. For example, this can be achieved by using the AVPF profile together with the Secure RTP profile as defined in [RFC3711]; an appropriate combination of the two profiles (an "SAVPF") is specified in [RFC5124]. However, other mechanisms also exist (documented in [RFC7201]) and might be more suitable.
攻撃者がPost-Repair Loss Countレポートに誤った情報を入力する可能性があり、これは損失修復メカニズムのパフォーマンスに影響を与えます。実装者は、適切なセキュリティメカニズムを使用するための[RFC7202]のガイダンスを検討する必要があります。つまり、セキュリティが懸念される場合、実装は暗号化と認証をレポートブロックに適用する必要があります。たとえば、これはAVPFプロファイルを[RFC3711]で定義されているSecure RTPプロファイルと一緒に使用することで実現できます。 2つのプロファイルの適切な組み合わせ（「SAVPF」）は、[RFC5124]で指定されています。ただし、他のメカニズムも存在し（[RFC7201]に文書化されています）、より適切な場合があります。
New block types for RTCP XR are subject to IANA registration. For general guidelines on IANA considerations for RTCP XR, refer to [RFC3611].
RTCP XRの新しいブロックタイプは、IANA登録の対象です。 RTCP XRに関するIANAの考慮事項に関する一般的なガイドラインについては、[RFC3611]を参照してください。
This document assigns the block type value 33 in the IANA "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry" to the "Post-Repair Loss Count Metrics Report Block".
このドキュメントでは、IANAの「RTP制御プロトコル拡張レポート（RTCP XR）ブロックタイプレジストリ」のブロックタイプ値33を「修復後の損失カウントメトリックレポートブロック」に割り当てています。
This document also registers a new parameter "post-repair-loss-count" in the "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry".
このドキュメントでは、「RTP制御プロトコル拡張レポート（RTCP XR）セッション記述プロトコル（SDP）パラメータレジストリ」に新しいパラメータ「post-repair-loss-count」も登録しています。
The contact information for the registrations is:
RAI Area Directors <rai-ads@ietf.org>
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、 <http://www.rfc-editor.org/info/rfc3611>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004、<http://www.rfc-editor.org/info/rfc3711>。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<http ：//www.rfc-editor.org/info/rfc5124>。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http：//www.rfc-editor .org / info / rfc5234>。
[RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February 2010, <http://www.rfc-editor.org/info/rfc5725>.
[RFC5725] Begen、A.、Hsu、D。、およびM. Lague、「RTP制御プロトコル（RTCP）拡張レポート（XR）の修復後の損失RLEレポートブロックタイプ」、RFC 5725、DOI 10.17487 / RFC5725、2月2010、<http://www.rfc-editor.org/info/rfc5725>。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <http://www.rfc-editor.org/info/rfc4588>.
[RFC4588]レイ、J、レオン、D、宮崎、A、ヴァルサ、V、およびR.ハケンバーグ、「RTP Retransmission Payload Format」、RFC 4588、DOI 10.17487 / RFC4588、2006年7月、<http：/ /www.rfc-editor.org/info/rfc4588>。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5109] Li、A。、編、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 5109、DOI 10.17487 / RFC5109、2007年12月、<http://www.rfc-editor.org/info/rfc5109> 。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <http://www.rfc-editor.org/info/rfc6390>.
[RFC6390]クラークA.およびB.クレイズ、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、DOI 10.17487 / RFC6390、2011年10月、<http://www.rfc-editor.org/info / rfc6390>。
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.
[RFC6709] Carpenter、B.、Aboba、B.、Ed。、およびS. Cheshire、「プロトコル拡張の設計上の考慮事項」、RFC 6709、DOI 10.17487 / RFC6709、2012年9月、<http：//www.rfc-editor .org / info / rfc6709>。
[RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, DOI 10.17487/RFC6792, November 2012, <http://www.rfc-editor.org/info/rfc6792>.
[RFC6792] Wu、Q.、Ed。、Hunt、G。、およびP. Arden、「RTPモニタリングフレームワークの使用に関するガイドライン」、RFC 6792、DOI 10.17487 / RFC6792、2012年11月、<http：// www。 rfc-editor.org/info/rfc6792>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<http://www.rfc-editor.org/info/rfc7201>。
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7202] Perkins、C。およびM. Westerlund、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<http：//www.rfc- editor.org/info/rfc7202>。
a. Post-Repair RTP Packet Loss Count Metric
a. 修復後のRTPパケット損失カウントメトリック
* Metric Name: Post-Repair RTP Packet Loss Count Metric.
* メトリック名：修復後のRTPパケット損失カウントメトリック。
* Metric Description: Total number of RTP packets still lost after loss-repair methods are applied.
* メトリックの説明：損失修復方法を適用した後も失われたRTPパケットの総数。
* Method of Measurement or Calculation: See the "Post-repair loss count" definition in Section 3.1. It is directly measured and must be measured for the primary source RTP packets with no further chance of repair.
* 測定または計算の方法：セクション3.1の「修理後の損失数」の定義を参照してください。これは直接測定されるため、修復の可能性がないプライマリソースRTPパケットについて測定する必要があります。
* Units of Measurement: This metric is expressed as a 16-bit unsigned integer value giving the number of RTP packets.
* 測定単位：このメトリックは、RTPパケットの数を示す16ビットの符号なし整数値として表されます。
* Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream.
* 潜在的な測定ドメインのある測定ポイント：RTPストリームの受信側で測定されます。
* Measurement Timing: This metric relies on the sequence number interval to determine measurement timing. See the Cumulative and Interval reports defined in Section 3.2.
* 測定タイミング：このメトリックは、シーケンス番号間隔に基づいて測定タイミングを決定します。セクション3.2で定義されている累積レポートと間隔レポートを参照してください。
* Use and Applications: These metrics are applicable to any RTP application, especially those that use loss-repair mechanisms. See Section 1 for details.
* 用途とアプリケーション：これらのメトリックは、RTPアプリケーション、特に損失修復メカニズムを使用するアプリケーションに適用できます。詳細については、セクション1を参照してください。
* Reporting Model: See RFC 3611.
* レポートモデル：RFC 3611を参照してください。
b. Repaired RTP Packet Loss Count Metric
b. 修復されたRTPパケット損失カウントメトリック
* Metric Name: Repaired RTP Packet Count Metric.
* メトリック名：修復されたRTPパケット数メトリック。
* Metric Description: The number of RTP packets lost but repaired after applying loss-repair methods.
* メトリックの説明：損失修復方法を適用した後に失われたが修復されたRTPパケットの数。
* Method of Measurement or Calculation: See the "Repaired loss count" in Section 3.1. It is directly measured and must be measured for the primary source RTP packets with no further chance of repair.
* 測定または計算の方法：セクション3.1の「修復された損失数」を参照してください。これは直接測定されるため、修復の可能性がないプライマリソースRTPパケットについて測定する必要があります。
* Units of Measurement: This metric is expressed as a 16-bit unsigned integer value giving the number of RTP packets.
* 測定単位：このメトリックは、RTPパケットの数を示す16ビットの符号なし整数値として表されます。
* Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream.
* 潜在的な測定ドメインのある測定ポイント：RTPストリームの受信側で測定されます。
* Measurement Timing: This metric relies on the sequence number interval to determine measurement timing. See the Cumulative and Interval reports defined in Section 3.2.
* 測定タイミング：このメトリックは、シーケンス番号間隔に基づいて測定タイミングを決定します。セクション3.2で定義されている累積レポートと間隔レポートを参照してください。
* Use and Applications: These metrics are applicable to any RTP application, especially those that use loss-repair mechanisms. See Section 1 for details.
* 用途とアプリケーション：これらのメトリックは、RTPアプリケーション、特に損失修復メカニズムを使用するアプリケーションに適用できます。詳細については、セクション1を参照してください。
* Reporting Model: See RFC 3611.
* レポートモデル：RFC 3611を参照してください。
Acknowledgments
謝辞
The authors would like to thank Roni Even, Colin Perkins, and Qin Wu for giving valuable comments and suggestions.
著者は、貴重なコメントや提案を提供してくれたRoni Even、Colin Perkins、Qin Wuに感謝します。
Authors' Addresses
著者のアドレス
Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China
Rachel Huang hu Aは101ソフトウェアアベニュー、Y Uは地区NaNjing 210012中国を描画
EMail: rachel.huang@huawei.com
Varun Singh Aalto University School of Electrical Engineering Otakaari 5 A Espoo, FIN 02150 Finland
Varun Singh Aalto大学電気工学部Otakaari 5 A Espoo、FIN 02150フィンランド
EMail: varun@comnet.tkk.fi
URI: http://www.netlab.tkk.fi/~varun/