[要約] RFC 3158は、RTP（Real-time Transport Protocol）のテスト戦略についてのガイドラインです。このRFCの目的は、RTPの実装とテストに関するベストプラクティスを提供することです。
Network Working Group C. Perkins
Request for Comments: 3158 USC/ISI
Category: Informational J. Rosenberg
dynamicsoft
H. Schulzrinne
Columbia University
August 2001
RTP Testing Strategies
RTPテスト戦略
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations.
このメモは、RTP（リアルタイムトランスポートプロトコル）の実装の可能なテスト戦略について説明しています。
Table of Contents
目次
1 Introduction. . . . . . . . . . . . . . . . . . . . . . 2
2 End systems . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Media transport . . . . . . . . . . . . . . . . . 3
2.2 RTP Header Extension . . . . . . . . . . . . . . . 4
2.3 Basic RTCP . . . . . . . . . . . . . . . . . . . 4
2.3.1 Sender and receiver reports . . . . . . . . 4
2.3.2 RTCP source description packets . . . . . . 6
2.3.3 RTCP BYE packets . . . . . . . . . . . . . . 7
2.3.4 Application defined RTCP packets . . . . . . 7
2.4 RTCP transmission interval . . . . . . . . . . . . 7
2.4.1 Basic Behavior . . . . . . . . . . . . . . 8
2.4.2 Step join backoff . . . . . . . . . . . . 9
2.4.3 Steady State Behavior . . . . . . . . . . 11
2.4.4 Reverse Reconsideration . . . . . . . . . 12
2.4.5 BYE Reconsideration . . . . . . . . . . . 13
2.4.6 Timing out members . . . . . . . . . . . . 14
2.4.7 Rapid SR's . . . . . . . . . . . . . . . . 15
3 RTP translators . . . . . . . . . . . . . . . . . . . . 15
4 RTP mixers. . . . . . . . . . . . . . . . . . . . . . . 17
5 SSRC collision detection. . . . . . . . . . . . . . . . 18
6 SSRC Randomization. . . . . . . . . . . . . . . . . . . 19
7 Security Considerations . . . . . . . . . . . . . . . . 20
8 Authors' Addresses. . . . . . . . . . . . . . . . . . . 20
9 References. . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement. . . . . . . . . . . . . . . . . 22
1 Introduction
1はじめに
This memo describes a possible testing strategy for RTP [1] implementations. The tests are intended to help demonstrate interoperability of multiple implementations, and to illustrate common implementation errors. They are not intended to be an exhaustive set of tests and passing these tests does not necessarily imply conformance to the complete RTP specification.
このメモは、RTP [1]の実装の可能なテスト戦略について説明しています。このテストは、複数の実装の相互運用性を実証し、一般的な実装エラーを説明することを目的としています。それらは徹底的なテストセットであることを意図しておらず、これらのテストに合格することは、必ずしも完全なRTP仕様への適合を意味するわけではありません。
2 End systems
2つのエンドシステム
The architecture for testing RTP end systems is shown in Figure 1.
RTPエンドシステムをテストするためのアーキテクチャを図1に示します。
+-----------------+
+--------+ Test instrument +-----+
| +-----------------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Second RTP |
| implementation | | implementation |
+----------------+ +----------------+
Figure 1: Testing architecture
図1：テストアーキテクチャ
Both RTP implementations send packets to the test instrument, which forwards packets from one implementation to the other. Unless otherwise specified, packets are forwarded with no additional delay and without loss. The test instrument is required to delay or discard packets in some of the tests. The test instrument is invisible to the RTP implementations - it merely simulates poor network conditions.
両方のRTP実装は、パケットをテスト機器に送信します。これにより、パケットが1つの実装から別の実装に転送されます。特に指定されていない限り、パケットは追加の遅延なしで転送され、損失なしに転送されます。テスト機器は、一部のテストでパケットを遅らせるか破棄する必要があります。テスト機器はRTP実装には見えません - それは単に貧弱なネットワーク条件をシミュレートするだけです。
The test instrument is also capable of logging packet contents for inspection of their correctness.
テスト機器は、正確性を検査するためにパケットコンテンツを記録することもできます。
A typical test setup might comprise three machines on a single Ethernet segment. Two of these machines run the RTP implementations, the third runs the test instrument. The test instrument is an application level packet forwarder. Both RTP implementations are instructed to send unicast RTP packets to the test instrument, which forwards packets between them.
典型的なテストセットアップは、単一のイーサネットセグメント上の3つのマシンで構成される場合があります。これらのマシンのうち2つはRTP実装を実行し、3番目はテスト機器を実行します。テスト機器は、アプリケーションレベルのパケットフォワーダーです。両方のRTP実装は、ユニキャストRTPパケットをテスト機器に送信するように指示され、パケットをそれらの間に転送します。
The aim of these tests is to show that basic media flows can be exchanged between the two RTP implementations. The initial test is for the first RTP implementation to transmit and the second to receive. If this succeeds, the process is reversed, with the second implementation sending and the first receiving.
これらのテストの目的は、基本的なメディアフローが2つのRTP実装間で交換できることを示すことです。初期テストは、最初のRTP実装が送信され、2番目のRTP実装が受信されるためです。これが成功した場合、2回目の実装が送信され、最初の受信が行われ、プロセスが逆転します。
The receiving application should be able to handle the following edge cases, in addition to normal operation:
受信アプリケーションは、通常の操作に加えて、次のエッジケースを処理できる必要があります。
o Verify reception of packets which contain padding.
o パディングを含むパケットの受信を確認します。
o Verify reception of packets which have the marker bit set
o マーカービットが設定されているパケットの受信を確認する
o Verify correct operation during sequence number wrap-around.
o シーケンス番号ラップアラウンド中に正しい操作を確認します。
o Verify correct operation during timestamp wrap-around.
o タイムスタンプラップアラウンド中に正しい操作を確認します。
o Verify that the implementation correctly differentiates packets according to the payload type field.
o 実装がペイロードタイプフィールドに従ってパケットを正しく区別することを確認します。
o Verify that the implementation ignores packets with unsupported payload types
o 実装がサポートされていないペイロードタイプでパケットを無視していることを確認する
o Verify that the implementation can playout packets containing a CSRC list and non-zero CC field (see section 4).
o 実装がCSRCリストと非ゼロCCフィールドを含むプレイアウトパケットができることを確認します（セクション4を参照）。
The sending application should be verified to correctly handle the following edge cases:
送信アプリケーションは、次のエッジケースを正しく処理するために検証する必要があります。
o If padding is used, verify that the padding length indicator (last octet of the packet) is correctly set and that the length of the data section of the packet corresponds to that of this particular payload plus the padding.
o パディングを使用する場合は、パディングの長さインジケーター（パケットの最後のオクテット）が正しく設定されており、パケットのデータセクションの長さがこの特定のペイロードとパディングのそれに対応することを確認します。
o Verify correct handling of the M bit, as defined by the profile.
o プロファイルで定義されているように、mビットの正しい処理を確認します。
o Verify that the SSRC is chosen randomly.
o SSRCがランダムに選択されていることを確認します。
o Verify that the initial value of the sequence number is randomly selected.
o シーケンス番号の初期値がランダムに選択されていることを確認します。
o Verify that the sequence number increments by one for each packet sent.
o 送信されたパケットごとにシーケンス番号の増分が1つずつ確認します。
o Verify correct operation during sequence number wrap-around.
o シーケンス番号ラップアラウンド中に正しい操作を確認します。
o Verify that the initial value of the timestamp is randomly selected.
o タイムスタンプの初期値がランダムに選択されていることを確認します。
o Verify correct increment of timestamp (dependent on the payload format).
o タイムスタンプの正しい増分を確認します（ペイロード形式に応じて）。
o Verify correct operation during timestamp wrap-around.
o タイムスタンプラップアラウンド中に正しい操作を確認します。
o Verify correct choice of payload type according to the chosen payload format, profile and any session level control protocol.
o 選択したペイロード形式、プロファイル、およびセッションレベル制御プロトコルに従って、ペイロードタイプの正しい選択を確認します。
An RTP implementation which does not use an extended header should be able to process packets containing an extension header by ignoring the extension.
拡張ヘッダーを使用しないRTP実装は、拡張機能を無視して拡張ヘッダーを含むパケットを処理できる必要があります。
If an implementation makes use of the header extension, it should be verified that the profile specific field and the length field of the extension are set correctly, and that the length of the packet is consistent.
実装がヘッダー拡張機能を使用する場合、プロファイル固有のフィールドと拡張機能の長さフィールドが正しく設定され、パケットの長さが一貫していることを確認する必要があります。
An RTP implementation is required to send RTCP control packets in addition to data packets. The architecture for testing basic RTCP functions is that shown in Figure 1.
データパケットに加えてRTCP制御パケットを送信するには、RTP実装が必要です。基本的なRTCP関数をテストするためのアーキテクチャは、図1に示すものです。
The first test requires both implementations to be run, but neither sends data. It should be verified that RTCP packets are generated by each implementation, and that those packets are correctly received by the other implementation. It should also be verified that:
最初のテストでは、両方の実装を実行する必要がありますが、どちらもデータを送信しません。RTCPパケットは各実装によって生成され、それらのパケットが他の実装によって正しく受信されることを確認する必要があります。また、次のように確認する必要があります。
o all RTCP packets sent are compound packets
o 送信されるすべてのRTCPパケットは複合パケットです
o all RTCP compound packets start with an empty RR packet
o すべてのRTCP化合物パケットは、空のRRパケットから始まります
o all RTCP compound packets contain an SDES CNAME packet
o すべてのRTCP化合物パケットには、SDES CNAMEパケットが含まれています
The first implementation should then be made to transmit data packets. It should be verified that that implementation now generates SR packets in place of RR packets, and that the second application now generates RR packets containing a single report block. It should be verified that these SR and RR packets are correctly received. The following features of the SR packets should also be verified:
次に、データパケットを送信するために最初の実装を行う必要があります。実装がRRパケットの代わりにSRパケットを生成し、2番目のアプリケーションが単一のレポートブロックを含むRRパケットを生成するようになることを確認する必要があります。これらのSRおよびRRパケットが正しく受信されることを確認する必要があります。SRパケットの次の機能も検証する必要があります。
o that the length field is consistent with both the length of the packet and the RC field
o 長さフィールドがパケットの長さとRCフィールドの両方と一致していること
o that the SSRC in SR packets is consistent with that in the RTP data packets
o SRパケットのSSRCがRTPデータパケットのそれと一致していること
o that the NTP timestamp in the SR packets is sensible (matches the wall clock time on the sending machine)
o SRパケットのNTPタイムスタンプが賢明であること（送信マシンの壁の時計の時間に一致します）
o that the RTP timestamp in the SR packets is consistent with that in the RTP data packets
o SRパケットのRTPタイムスタンプがRTPデータパケットのそれと一致していること
o that the packet and octet count fields in the SR packets are consistent with the number of RTP data packets transmitted
o SRパケットのパケットカウントフィールドが、送信されたRTPデータパケットの数と一致していること
In addition, the following features of the RR packets should also be verified:
さらに、RRパケットの次の機能も検証する必要があります。
o that the SSRC in the report block is consistent with that in the data packets being received
o レポートブロックのSSRCが受信中のデータパケットのSSRCと一致していること
o that the fraction lost is zero
o 失われた割合がゼロであること
o that the cumulative number of packets lost is zero
o 失われたパケットの累積数がゼロであること
o that the extended highest sequence number received is consistent with the data packets being received (provided the round trip time between test instrument and receiver is smaller than the packet inter-arrival time, this can be directly checked by the test instrument).
o 受信された拡張最高のシーケンス数は、受信中のデータパケットと一致していること（テスト機器と受信機の間の往復時間がパケット間攻撃時間よりも小さい場合、これはテスト機器で直接チェックできます）。
o that the interarrival jitter is small (a precise value cannot be given, since it depends on the test instrument and network conditions, but very little jitter should be present in this scenario).
o 到着間ジッターは小さいこと（テスト機器とネットワーク条件に依存するため、正確な値を与えることはできませんが、このシナリオにはほとんどジッターは存在しないはずです）。
o that the last sender report timestamp is consistent with that in the SR packets (i.e., each RR passing through the test instrument should contain the middle 32 bits from the 64 bit NTP timestamp of the last SR packet which passed through the test instrument in the opposite direction).
o 最後の送信者レポートのタイムスタンプがSRパケットのそれと一致していること（つまり、テスト機器を通過する各RRは、反対側のテスト機器を通過した最後のSRパケットの64ビットNTPタイムスタンプから中央の32ビットを含む必要があります方向）。
o that the delay since last SR field is sensible (an estimate may be made by timing the passage of an SR and corresponding RR through the test instrument, this should closely agree with the DLSR field)
o 最後のSRフィールド以降の遅延が賢明であること（SRの通過と対応するRRのタイミングをテスト機器に介して行うことで、これはDLSRフィールドに密接に同意するはずです）
It should also be verified that the timestamps, packet count and octet count correctly wrap-around after the appropriate interval.
また、タイムスタンプ、パケットカウント、およびオクテットカウントが、適切な間隔の後に正しくラップアラウンドすることを確認する必要があります。
The next test is to show behavior in the presence of packet loss. The first implementation is made to transmit data packets, which are received by the second implementation. This time, however, the test instrument is made to randomly drop a small fraction (1% is suggested) of the data packets. The second implementation should be able to receive the data packets and process them in a normal manner (with, of course, some quality degradation). The RR packets should show a loss fraction corresponding to the drop rate of the test instrument and should show an increasing cumulative number of packets lost.
次のテストは、パケット損失の存在下で動作を示すことです。最初の実装は、2番目の実装によって受信されるデータパケットを送信するために行われます。ただし、今回は、データパケットのわずかな割合（1％が推奨される）をランダムに落とすようにテスト機器が作成されます。2番目の実装では、データパケットを受信して通常の方法で処理できる必要があります（もちろん、ある程度の品質の劣化を使用）。RRパケットは、テスト機器のドロップレートに対応する損失分率を表示し、失われたパケットの累積数の増加を示す必要があります。
The loss rate in the test instrument is then returned to zero and it is made to delay each packet by some random amount (the exact amount depends on the media type, but a small fraction of the average interarrival time is reasonable). The effect of this should be to increase the reported interarrival jitter in the RR packets.
テスト機器の損失率はゼロに戻され、各パケットをランダムな量だけ遅らせるようになります（正確な量はメディアタイプに依存しますが、平均到達時間のわずかな割合は妥当です）。これの効果は、RRパケットで報告された登録間ジッターを増やすことです。
If these tests succeed, the process should be repeated with the second implementation transmitting and the first receiving.
これらのテストが成功した場合、2回目の実装送信と最初の受信でプロセスを繰り返す必要があります。
Both implementations should be run, but neither is required to transmit data packets. The RTCP packets should be observed and it should be verified that each compound packet contains an SDES packet, that that packet contains a CNAME item and that the CNAME is chosen according to the rules in the RTP specification and profile (in many cases the CNAME should be of the form `example@10.0.0.1' but this may be overridden by a profile definition).
両方の実装を実行する必要がありますが、データパケットを送信するためにどちらも必要ありません。RTCPパケットを観察する必要があり、各化合物パケットにはSDESパケットが含まれていること、そのパケットにはCNAMEアイテムが含まれていること、およびcNameがRTP仕様とプロファイルのルールに従って選択されることを確認する必要があります（多くの場合、CNAMEはCNAMEである必要があります。フォーム「embles@10.0.0.1」の形式であるが、これはプロファイルの定義によってオーバーライドされる場合がある）。
If an application supports additional SDES items then it should be verified that they are sent in addition to the CNAME with some SDES packets (the exact rate at which these additional items are included is dependent on the application and profile).
アプリケーションが追加のSDEアイテムをサポートする場合、一部のSDEパケットを使用してCNAMEに加えて送信されることを確認する必要があります（これらの追加アイテムが含まれる正確なレートは、アプリケーションとプロファイルに依存します）。
It should be verified that an implementation can correctly receive NAME, EMAIL, PHONE, LOC, NOTE, TOOL and PRIV items, even if it does not send them. This is because it may reasonably be expected to interwork with other implementations which support those items. Receiving and ignoring such packets is valid behavior.
実装は、たとえ送信しなくても、名前、電子メール、電話、loc、ノート、ツール、およびprivアイテムを正しく受信できることを確認する必要があります。これは、これらのアイテムをサポートする他の実装と連携することが合理的に期待される可能性があるためです。そのようなパケットを受信して無視することは有効な動作です。
It should be verified that an implementation correctly sets the length fields in the SDES items it sends, and that the source count and packet length fields are correct. It should be verified that SDES fields are not zero terminated.
実装が送信するSDESアイテムの長さフィールドを正しく設定し、ソースカウントとパケットの長さフィールドが正しいことを確認する必要があります。SDESフィールドが終了していないことを確認する必要があります。
It should be verified that an implementation correctly receives SDES items which do not terminate in a zero byte.
実装では、ゼロバイトで終了しないSDESアイテムを正しく受信することを確認する必要があります。
Both implementations should be run, but neither is required to transmit data packets. The first implementation is then made to exit and it should be verified that an RTCP BYE packet is sent. It should be verified that the second implementation reacts to this BYE packet and notes that the first implementation has left the session.
両方の実装を実行する必要がありますが、データパケットを送信するためにどちらも必要ありません。最初の実装は終了するために行われ、RTCPバイパケットが送信されることを確認する必要があります。2番目の実装がこのByeパケットに反応し、最初の実装がセッションを離れたことに注意することを確認する必要があります。
If the test succeeds, the implementations should be restarted and the process repeated with the second implementation leaving the session.
テストが成功した場合、実装を再起動し、2回目の実装でセッションを離れるとプロセスを繰り返します。
It should be verified that implementations handle BYE packets containing the optional reason for leaving text (ignoring the text is acceptable).
実装は、テキストを残すオプションの理由を含むByeパケットを処理することを確認する必要があります（テキストを無視することは許容されます）。
Tests for the correct response to application defined packets are difficult to specify, since the response is clearly implementation dependent. It should be verified that an implementation ignores APP packets where the 4 octet name field is unrecognized. Implementations which use APP packets should verify that they behave as expected.
応答は明らかに実装依存であるため、アプリケーション定義のパケットに対する正しい応答のテストを指定することは困難です。実装は、4オクテット名フィールドが認識されていないアプリパケットを無視することを確認する必要があります。アプリパケットを使用する実装は、予想どおりに動作することを確認する必要があります。
The basic architecture for performing tests of the RTCP transmission interval is shown in Figure 2.
RTCP伝送間隔のテストを実行するための基本的なアーキテクチャを図2に示します。
The test instrument is connected to the same LAN as the RTP implementation being tested. It is assumed that the test instrument is preconfigured with the addresses and ports used by the RTP implementation, and is also aware of the RTCP bandwidth and sender/receiver fractions. The tests can be conducted using either multicast or unicast.
テスト機器は、テストされているRTP実装と同じLANに接続されています。テスト機器は、RTP実装で使用されるアドレスとポートで事前に設定されていると想定されており、RTCP帯域幅と送信者/レシーバー分数も認識しています。テストは、マルチキャストまたはユニキャストのいずれかを使用して実施できます。
The test instrument must be capable of sending arbitrarily crafted RTP and RTCP packets to the RTP implementation. The test instrument should also be capable of receiving packets sent by the RTP implementation, parsing them, and computing metrics based on those packets.
テスト機器は、RTP実装に任意に作成されたRTPおよびRTCPパケットを送信できる必要があります。また、テスト機器は、RTP実装によって送信されたパケットを受信し、それらを解析し、それらのパケットに基づいてメトリックを計算できる必要があります。
+--------------+
| test |
| instrument |
+-----+--------+
|
------+-----------+-------------- LAN
|
+-------+--------+
| RTP |
| implementation |
+----------------+
Figure 2: Testing architecture for RTCP
図2：RTCPのテストアーキテクチャ
It is furthermore assumed that a number of basic controls over the RTP implementation exist. These controls are:
さらに、RTP実装に関する多くの基本的な制御が存在すると想定されています。これらのコントロールは次のとおりです。
o the ability to force the implementation to send or not send RTP packets at any desired point in time
o 実装に強制的に希望の時点でRTPパケットを送信または送信しないことを強制する機能
o the ability to force the application to terminate its involvement in the RTP session, and for this termination to be known immediately to the test instrument
o アプリケーションにRTPセッションへの関与を強制する能力、およびこの終了がすぐにテスト機器に知られるようにする能力
o the ability to set the session bandwidth and RTCP sender and receiver fractions
o セッションの帯域幅とRTCP送信者と受信機の分数を設定する機能
The second of these is required only for the test of BYE reconsideration, and is the only aspect of these tests not easily implementable by pure automation. It will generally require manual intervention to terminate the session from the RTP implementation and to convey this to the test instrument through some non-RTP means.
これらの2番目は、Byeの再考のテストにのみ必要であり、純粋な自動化では簡単に実装できないこれらのテストの唯一の側面です。通常、RTP実装からセッションを終了し、これをいくつかの非RTP平均を使用してテスト機器に伝えるために、手動介入が必要になります。
The first test is to verify basic correctness of the implementation of the RTCP transmission rules. This basic behavior consists of:
最初のテストは、RTCP送信ルールの実装の基本的な正確性を検証することです。この基本的な動作は次のとおりです。
o periodic transmission of RTCP packets
o RTCPパケットの定期送信
o randomization of the interval for RTCP packet transmission
o RTCPパケット伝送の間隔のランダム化
o correct implementation of the randomization interval computations, with unconditional reconsideration
o 無条件の再考を伴うランダム化間隔計算の正しい実装
The RTP implementation acts as a receiver, and never sends any RTP data packets. The implementation is configured with a large session bandwidth, say 1 Mbit/s. This will cause the implementation to use the minimal interval of 5s rather than the small interval based on the session bandwidth and membership size. The implementation will generate RTCP packets at this minimal interval, on average. The test instrument generates no packets, but receives the RTCP packets generated by the implementation. When an RTCP packet is received, the time is noted by the test instrument. The difference in time between each pair of subsequent packets (called the interval) is computed. These intervals are stored, so that statistics based on these intervals can be computed. It is recommended that this observation process operate for at least 20 minutes.
RTP実装はレシーバーとして機能し、RTPデータパケットを送信しません。実装は、1 Mbit/sなどの大規模なセッション帯域幅で構成されています。これにより、セッションの帯域幅とメンバーシップサイズに基づいて、小さな間隔ではなく、5秒の最小間隔を使用します。この実装により、この最小間隔で平均してRTCPパケットが生成されます。テスト機器はパケットを生成しませんが、実装によって生成されたRTCPパケットを受信します。RTCPパケットが受信されると、テスト機器によって時間が記録されます。後続のパケットの各ペア間の時間の違い（間隔と呼ばれる）が計算されます。これらの間隔は保存されているため、これらの間隔に基づいた統計を計算できます。この観察プロセスは少なくとも20分間動作することをお勧めします。
An implementation passes this test if the intervals have the following properties:
間隔に次のプロパティがある場合、このテストに合格します。
o the minimum interval is never less than 2 seconds or more than 2.5 seconds;
o 最小間隔は、2秒以上2.5秒以上です。
o the maximum interval is never more than 7 seconds or less than 5.5 seconds;
o 最大間隔は、7秒以下または5.5秒未満ではありません。
o the average interval is between 4.5 and 5.5 seconds;
o 平均間隔は4.5〜5.5秒です。
o the number of intervals between x and x+500ms is less than the number of intervals between x+500ms and x+1s, for any x.
o x 500msとx 500msの間の間隔数は、x 500msとx 1sの間隔数よりも少ないxの場合は少なくなります。
In particular, an implementation fails if the packets are sent with a constant interval.
特に、パケットが一定の間隔で送信されると実装が失敗します。
The main purpose of the reconsideration algorithm is to avoid a flood of packets that might occur when a large number of users simultaneously join an RTP session. Reconsideration therefore exhibits a backoff behavior in sending of RTCP packets when group sizes increase. This aspect of the algorithm can be tested in the following manner.
再考アルゴリズムの主な目的は、多数のユーザーが同時にRTPセッションに参加したときに発生する可能性のあるパケットの洪水を回避することです。したがって、再考は、グループサイズが増加したときにRTCPパケットの送信にバックオフ動作を示します。アルゴリズムのこの側面は、次の方法でテストできます。
The implementation begins operation. The test instrument waits for the arrival of the first RTCP packet. When it arrives, the test instrument notes the time and then immediately sends 100 RTCP RR packets to the implementation, each with a different SSRC and SDES CNAME. The test instrument should ensure that each RTCP packet is of the same length. The instrument should then wait until the next RTCP packet is received from the implementation, and the time of such reception is noted.
実装が操作を開始します。テスト機器は、最初のRTCPパケットの到着を待ちます。到着すると、テスト機器は時間を記録し、すぐに100のRTCP RRパケットを実装に送信します。テスト機器は、各RTCPパケットが同じ長さであることを確認する必要があります。次に、機器は、次のRTCPパケットが実装から受信されるまで待機し、そのような受信の時間に注意してください。
Without reconsideration, the next RTCP packet will arrive within a short period of time. With reconsideration, transmission of this packet will be delayed. The earliest it can arrive depends on the RTCP session bandwidth, receiver fraction, and average RTCP packet size. The RTP implementation should be using the exponential averaging algorithm defined in the specification to compute the average RTCP packet size. Since this is dominated by the received packets (the implementation has only sent one itself), the average will be roughly equal to the length of the RTCP packets sent by the test instrument. Therefore, the minimum amount of time between the first and second RTCP packets from the implementation is:
再考することなく、次のRTCPパケットは短期間以内に到着します。再考すると、このパケットの送信が遅れます。到着できる最も早いのは、RTCPセッションの帯域幅、受信機の分数、および平均RTCPパケットサイズによって異なります。RTP実装では、仕様で定義された指数平均化アルゴリズムを使用して、平均RTCPパケットサイズを計算する必要があります。これは受信したパケット（実装では1つだけ送信されている）によって支配されているため、平均はテスト機器から送信されるRTCPパケットの長さとほぼ等しくなります。したがって、実装からの最初のRTCPパケットと2番目のRTCPパケットの間の最小時間は、次のとおりです。
T > 101 * S / ( B * Fr * (e-1.5) * 2 )
Where S is the size of the RTCP packets sent by the test instrument, B is the RTCP bandwidth (normally five percent of the session bandwidth), Fr is the fraction of RTCP bandwidth allocated to receivers (normally 75 percent), and e is the natural exponent. Without reconsideration, this minimum interval Te would be much smaller:
ここで、Sはテスト機器によって送信されるRTCPパケットのサイズです。BはRTCP帯域幅（通常はセッション帯域幅の5％）、FRはレシーバーに割り当てられたRTCP帯域幅の割合（通常75％）であり、EはEが自然指数。再考がなければ、この最小間隔TEははるかに小さくなります。
Te > MAX( [ S / ( B * Fr * (e-1.5) * 2 ) ] , [ 2.5 / (e-1.5) ] )
B should be chosen sufficiently small so that T is around 60 seconds. Reasonable choices for these parameters are B = 950 bits per second, and S = 1024 bits. An implementation passes this test if the interval between packets is not less than T above, and not more than 3 times T.
Tが約60秒になるように、Bを十分に小さく選択する必要があります。これらのパラメーターの合理的な選択は、1秒あたりのb = 950ビット、およびS = 1024ビットです。パケット間の間隔がT以上で、3倍以下のT以下の場合、実装はこのテストに合格します。
Note: in all tests the value chosen for B, the RTCP bandwidth, is calculated including the lower layer UDP/IP headers. In a typical IPv4 based implementation, these comprise 28 octets per packet. A common mistake is to forget that these are included when choosing the size of packets to transmit.
注：すべてのテストで、Bに選択された値であるRTCP帯域幅は、下層UDP/IPヘッダーを含めて計算されます。典型的なIPv4ベースの実装では、これらはパケットごとに28オクテットで構成されています。よくある間違いは、送信するパケットのサイズを選択するときにこれらが含まれていることを忘れることです。
The test should be repeated for the case when the RTP implementation is a sender. This is accomplished by having the implementation send RTP packets at least once a second. In this case, the interval between the first and second RTCP packets should be no less than:
RTP実装が送信者である場合、テストは繰り返される必要があります。これは、実装を少なくとも1秒に1回RTPパケットを送信させることで実現されます。この場合、最初のRTCPパケットと2番目のRTCPパケット間の間隔は次のとおりです。
T > S / ( B * Fs * (e-1.5) * 2 )
Where Fs is the fraction of RTCP bandwidth allocated to senders, usually 25%. Note that this value of T is significantly smaller than the interval for receivers.
ここで、FSは送信者に割り当てられたRTCP帯域幅の割合で、通常25％です。Tのこの値は、受信機の間隔よりも大幅に小さいことに注意してください。
In addition to the basic behavior in section 2.4.1, an implementation should correctly implement a number of other, slightly more advanced features:
セクション2.4.1の基本的な動作に加えて、実装は他の多くの、より高度な機能を正しく実装する必要があります。
o scale the RTCP interval with the group size;
o グループサイズでRTCP間隔をスケーリングします。
o correctly divide bandwidth between senders and receivers;
o 送信者と受信機の間で帯域幅を正しく分割します。
o correctly compute the RTCP interval when the user is a sender
o ユーザーが送信者である場合、RTCP間隔を正しく計算します
The implementation begins operation as a receiver. The test instrument waits for the first RTCP packet from the implementation. When it arrives, the test instrument notes the time, and immediately sends 50 RTCP RR packets and 50 RTCP SR packets to the implementation, each with a different SSRC and SDES CNAME. The test instrument then sends 50 RTP packets, using the 50 SSRC from the RTCP SR packets. The test instrument should ensure that each RTCP packet is of the same length. The instrument should then wait until the next RTCP packet is received from the implementation, and the time of such reception is noted. The difference between the reception of the RTCP packet and the reception of the previous is computed and stored. In addition, after every RTCP packet reception, the 100 RTCP and 50 RTP packets are retransmitted by the test instrument. This ensures that the sender and member status of the 100 users does not time out. The test instrument should collect the interval measurements figures for at least 100 RTCP packets.
実装はレシーバーとして操作を開始します。テスト機器は、実装から最初のRTCPパケットを待ちます。到着すると、テスト機器は時間を記録し、すぐに50のRTCP RRパケットと50のRTCP SRパケットを実装に送信し、それぞれ異なるSSRCとSDES CNAMEを備えています。テスト機器は、RTCP SRパケットから50のSSRCを使用して、50のRTPパケットを送信します。テスト機器は、各RTCPパケットが同じ長さであることを確認する必要があります。次に、機器は、次のRTCPパケットが実装から受信されるまで待機し、そのような受信の時間に注意してください。RTCPパケットの受信と前の受信の違いが計算され、保存されます。さらに、RTCPパケット受信ごとに、100のRTCPと50のRTPパケットがテスト機器によって再送信されます。これにより、100人のユーザーの送信者とメンバーのステータスがタイムアウトしないようにします。テスト機器は、少なくとも100個のRTCPパケットの間隔測定値を収集する必要があります。
With 50 senders, the implementation should not try to divide the RTCP bandwidth between senders and receivers, but rather group all users together and divide the RTCP bandwidth equally. The test is deemed successful if the average RTCP interval is within 5% of:
50人の送信者を使用すると、実装は送信者と受信機の間でRTCP帯域幅を分割しようとするのではなく、すべてのユーザーをグループ化してRTCP帯域幅を均等に分割しようとするべきです。平均RTCP間隔が5％以内である場合、テストは成功したとみなされます。
T = 101* S/B
t = 101* s/b
Where S is the size of the RTCP packets sent by the test instrument, and B is the RTCP bandwidth. B should be chosen sufficiently small so that the value of T is on the order of tens of seconds or more. Reasonable values are S=1024 bits and B=3.4 kb/s.
ここで、Sはテスト機器によって送信されるRTCPパケットのサイズで、BはRTCP帯域幅です。Tの値が数十秒以上順になるように、Bは十分に小さく選択する必要があります。合理的な値はs = 1024ビット、b = 3.4 kb/sです。
The previous test is repeated. However, the test instrument sends 10 RTP packets instead of 50, and 10 RTCP SR and 90 RTCP RR instead of 50 of each. In addition, the implementation is made to send at least one RTP packet between transmission of every one of its own RTCP packets.
前のテストが繰り返されます。ただし、テスト機器は、50個ではなく10個のRTPパケットを送信し、それぞれ50個ではなく10個のRTCP SRと90 RTCP RRを送信します。さらに、実装は、独自のRTCPパケットのすべての送信間で少なくとも1つのRTPパケットを送信するために行われます。
In this case, the average RTCP interval should be within 5% of:
この場合、平均RTCP間隔は5％以内でなければなりません。
T = 11 * S / (B * Fs)
Where S is the size of the RTCP packets sent by the test instrument, B is the RTCP bandwidth, and Fs is the fraction of RTCP bandwidth allocated for senders (normally 25%). The values for B and S should be chosen small enough so that T is on the order of tens of seconds. Reasonable choices are S=1024 bits and B=1.5 kb/s.
ここで、Sはテスト機器によって送信されるRTCPパケットのサイズ、BはRTCP帯域幅、FSは送信者に割り当てられたRTCP帯域幅の割合（通常25％）です。BとSの値は、Tが数十秒順になるように、十分に小さく選択する必要があります。合理的な選択は、S = 1024ビットとb = 1.5 kb/sです。
The reverse reconsideration algorithm is effectively the opposite of the normal reconsideration algorithm. It causes the RTCP interval to be reduced more rapidly in response to decreases in the group membership. This is advantageous in that it keeps the RTCP information as fresh as possible, and helps avoids some premature timeout problems.
逆の再考アルゴリズムは、事実上、通常の再考アルゴリズムの反対です。グループメンバーシップの減少に応じて、RTCP間隔をより迅速に減少させます。これは、RTCP情報を可能な限り新鮮に保ち、早期のタイムアウトの問題を回避するのに役立つという点で有利です。
In the first test, the implementation joins the session as a receiver. As soon as the implementation sends its first RTCP packet, the test instrument sends 100 RTCP RR packets, each of the same length S, and a different SDES CNAME and SSRC in each. It then waits for the implementation to send another RTCP packet. Once it does, the test instrument sends 100 BYE packets, each one containing a different SSRC, but matching an SSRC from one of the initial RTCP packets. Each BYE should also be the same size as the RTCP packets sent by the test instrument. This is easily accomplished by using a BYE reason to pad out the length. The time of the next RTCP packet from the implementation is then noted. The delay T between this (the third RTCP packet) and the previous should be no more than:
最初のテストでは、実装が受信機としてセッションに参加します。実装が最初のRTCPパケットを送信するとすぐに、テスト機器はそれぞれ同じ長さの100個のRTCP RRパケット、それぞれの異なるSDES CNAMEおよびSSRCを送信します。その後、実装が別のRTCPパケットを送信するのを待ちます。一度、テスト機器は100個のバイパケットを送信します。それぞれが異なるSSRCを含むが、最初のRTCPパケットの1つからSSRCを一致させます。各BYEは、テスト機器から送信されたRTCPパケットと同じサイズである必要があります。これは、さようなら理由を使用して長さをパドアウトすることで簡単に実現できます。次に、実装から次のRTCPパケットの時間に注意します。これ（3番目のRTCPパケット）と前の間の遅延tは次のとおりです。
T < 3 * S / (B * Fr * (e-1.5) * 2)
Where S is the size of the RTCP and BYE packets sent by the test instrument, B is the RTCP bandwidth, Fr is the fraction of the RTCP bandwidth allocated to receivers, and e is the natural exponent. B should be chosen such that T is on the order of tens of seconds. A reasonable choice is S=1024 bits and B=168 bits per second.
ここで、Sはテスト機器によって送信されるRTCPおよびバイパケットのサイズ、BはRTCP帯域幅、FRは受信機に割り当てられたRTCP帯域幅の割合で、Eは自然指数です。Tが数十秒の順序であるようにBを選択する必要があります。合理的な選択は、s = 1024ビットとb = 168ビットあたり168ビットです。
This test demonstrates basic correctness of implementation. An implementation without reverse reconsideration will not send its next RTCP packet for nearly 100 times as long as the above amount.
このテストは、実装の基本的な正確性を示しています。逆の再考のない実装では、次のRTCPパケットは、上記の金額のほぼ100倍も送信されません。
In the second test, the implementation joins the session as a receiver. As soon as it sends its first RTCP packet, the test instrument sends 100 RTCP RR packets, each of the same length S, followed by 100 BYE packets, also of length S. Each RTCP packet carries a different SDES CNAME and SSRC, and is matched with precisely one BYE packet with the same SSRC. This will cause the implementation to see a rapid increase and then rapid drop in group membership.
2番目のテストでは、実装が受信機としてセッションに参加します。最初のRTCPパケットを送信するとすぐに、テスト機器はそれぞれ同じ長さsの100 RTCP RRパケットを送信し、その後に100個のバイパケットを送信します。同じSSRCを使用したまったく1つのバイパケットと一致します。これにより、実装が急速に増加し、グループメンバーシップが急速に低下します。
The test is deemed successful if the next RTCP packet shows up T seconds after the first, and T is within:
次のRTCPパケットが最初の秒からT秒後に表示され、tが内にある場合、テストは成功したとみなされます。
2.5 / (e-1.5) < T < 7.5 / (e-1.5)
This tests correctness of the maintenance of the pmembers variable. An incorrect implementation might try to execute reverse reconsideration every time a BYE is received, as opposed to only when the group membership drops below pmembers. If an implementation did this, it would end up sending an RTCP packet immediately after receiving the stream of BYE's. For this test to work, B must be chosen to be a large value, around 1Mb/s.
これにより、PMEMBERS変数のメンテナンスの正しさがテストされます。誤った実装は、グループのメンバーシップがPMEMBERS以下で低下した場合とは対照的に、さようならを受信するたびに逆の再考を実行しようとする可能性があります。実装がこれを行った場合、Byeのストリームを受信した直後にRTCPパケットを送信することになります。このテストを機能させるには、Bは1MB/s前後の大きな値になるように選択する必要があります。
The BYE reconsideration algorithm works in much the same fashion as regular reconsideration, except applied to BYE packets. When a user leaves the group, instead of sending a BYE immediately, it may delay transmission of its BYE packet if others are sending BYE's.
さようなら再検討アルゴリズムは、バイパケットに適用されることを除いて、定期的な再考とほぼ同じ方法で機能します。ユーザーがグループを離れると、すぐにさようならを送信する代わりに、他の人がさようならを送信している場合、バイパケットの送信を遅らせる可能性があります。
The test for correctness of this algorithm is as follows. The RTP implementation joins the group as a receiver. The test instrument waits for the first RTCP packet. When the test instrument receives this packet, the test instrument immediately sends 100 RTCP RR packets, each of the same length S, and each containing a different SSRC and SDES CNAME. Once the test instrument receives the next RTCP packet from the implementation, the RTP implementation is made to leave the RTP session, and this information is conveyed to the test instrument through some non-RTP means. The test instrument then sends 100 BYE packets, each with a different SSRC, and each matching an SSRC from a previously transmitted RTCP packet. Each of these BYE packets is also of size S. Immediately following the BYE packets, the test instrument sends 100 RTCP RR packets, using the same SSRC/CNAMEs as the original 100 RTCP packets.
このアルゴリズムの正しさのテストは次のとおりです。RTP実装は、レシーバーとしてグループに参加します。テスト機器は、最初のRTCPパケットを待ちます。テスト機器がこのパケットを受信すると、テスト機器はすぐに同じ長さのsをそれぞれ100個のRTCP RRパケットを送信し、それぞれに異なるSSRCおよびSDES CNAMEが含まれています。テスト機器が実装から次のRTCPパケットを受信すると、RTP実装がRTPセッションを離れるように行われ、この情報はいくつかの非RTP平均を使用してテスト機器に伝えられます。テスト機器は、それぞれ異なるSSRCを備えた100個のバイパケットを送信し、それぞれが以前に送信されたRTCPパケットからSSRCを一致させます。これらの各バイパケットはサイズSです。BYEパケットの直後に、テスト機器は100 RTCP RRパケットを送信し、元の100 RTCPパケットと同じSSRC/CNAMEを使用します。
The test is deemed successful if the implementation either never sends a BYE, or if it does, the BYE is received by the test instrument not earlier than T seconds, and not later than 3 * T seconds, after the implementation left the session, where T is:
実装がさようなら送信されない場合、またはそれが行われた場合、試験機器がテスト機器によってT秒未満ではなく、3 * t秒以内ではない場合、実装がセッションを離れた後、これがテスト機器によって受信された場合、テストは成功したとみなされます。Tは次のとおりです。
T = 100 * S / ( 2 * (e-1.5) * B )
S is the size of the RTCP and BYE packets, e is the natural exponent, B is the RTCP bandwidth, and Fr is the RTCP bandwidth fraction for receivers. S and B should be chosen so that T is on the order of 50 seconds. A reasonable choice is S=1024 bits and B=1.1 kb/s.
SはRTCPおよびByeパケットのサイズ、Eは自然指数、BはRTCP帯域幅、FRは受信機のRTCP帯域幅画分です。SとBは、Tが50秒程度になるように選択する必要があります。合理的な選択は、s = 1024ビットとb = 1.1 kb/sです。
The transmission of the RTCP packets is meant to verify that the implementation is ignoring non-BYE RTCP packets once it decides to leave the group.
RTCPパケットの送信は、グループを離れることを決定した後、実装が非バイRTCPパケットを無視していることを確認することを目的としています。
Active RTP participants are supposed to send periodic RTCP packets. When a participant leaves the session, they may send a BYE, however this is not required. Furthermore, BYE reconsideration may cause a BYE to never be sent. As a result, participants must time out other participants who have not sent an RTCP packet in a long time. According to the specification, participants who have not sent an RTCP packet in the last 5 intervals are timed out. This test verifies that these timeouts are being performed correctly.
アクティブなRTP参加者は、定期的なRTCPパケットを送信することになっています。参加者がセッションを去るとき、彼らはさようならを送るかもしれませんが、これは必要ありません。さらに、さようならの再考により、さようならは決して送られない可能性があります。その結果、参加者は、長い間RTCPパケットを送信していない他の参加者をタイムアウトする必要があります。仕様によると、最後の5つの間隔でRTCPパケットを送信していない参加者がタイムアウトします。このテストは、これらのタイムアウトが正しく実行されていることを確認します。
The RTP implementation joins a session as a receiver. The test instrument waits for the first RTCP packet from the implementation. Once it arrives, the test instrument sends 100 RTCP RR packets, each with a different SDES and SSRC, and notes the time. This will cause the implementation to believe that there are now 101 group participants, causing it to increase its RTCP interval. The test instrument continues to monitor the RTCP packets from the implementation. As each RTCP packet is received, the time of its reception is noted, and the interval between RTCP packets is stored. The 100 participants spoofed by the test instrument should eventually time out at the RTP implementation. This should cause the RTCP interval to be reduced to its minimum.
RTP実装は、受信機としてセッションに参加します。テスト機器は、実装から最初のRTCPパケットを待ちます。到着すると、テスト機器は100個のRTCP RRパケットを送信します。これにより、実装により101人のグループ参加者がいると信じるようになり、RTCP間隔が増加します。テスト機器は、実装からRTCPパケットを引き続き監視し続けています。各RTCPパケットが受信されると、受信時間が記録され、RTCPパケット間の間隔が保存されます。テスト機器によってスプーフィングされた100人の参加者は、最終的にRTP実装でタイムアウトする必要があります。これにより、RTCP間隔が最小に削減されるようになります。
The test is deemed successful if the interval between RTCP packets after the first is no less than:
最初のRTCPパケット間の間隔が次のとおりである場合、テストは成功したとみなされます。
Ti > 101 * S / ( 2 * (e-1.5) * B * Fr)
and this minimum interval is sustained no later than Td seconds after the transmission of the 100 RR's, where Td is:
そして、この最小間隔は、100 RRの送信からTD秒以内に持続します。ここで、TDは次のとおりです。
Td = 7 * 101 * S / ( B * Fr )
and the interval between RTCP packets after this point is no less than:
そして、この点以降のRTCPパケット間の間隔は次のとおりです。
Tf > 2.5 / (e-1.5)
TF> 2.5 /（E-1.5）
For this test to work, B and S must be chosen so Ti is on the order of minutes. Recommended values are S = 1024 bits and B = 1.9 kbps.
このテストを機能させるには、BとSを選択する必要があります。推奨される値はS = 1024ビットとb = 1.9 kbpsです。
The minimum interval for RTCP packets can be reduced for large session bandwidths. The reduction applies to senders only. The recommended algorithm for computing this minimum interval is 360 divided by the RTP session bandwidth, in kbps. For bandwidths larger than 72 kbps, this interval is less than 5 seconds.
RTCPパケットの最小間隔は、大規模なセッション帯域幅で削減できます。削減は送信者のみに適用されます。この最小間隔を計算するための推奨アルゴリズムは、360をKBPSのRTPセッション帯域幅で除算します。72 kbpsを超える帯域幅の場合、この間隔は5秒未満です。
This test verifies the ability of an implementation to use a lower RTCP minimum interval when it is a sender in a high bandwidth session. The test can only be run on implementations that support this reduction, since it is optional.
このテストは、高帯域幅セッションで送信者である場合、より低いRTCP最小間隔を使用する実装の能力を検証します。このテストは、オプションであるため、この削減をサポートする実装でのみ実行できます。
The RTP implementation is configured to join the session as a sender. The session is configured to use 360 kbps. If the recommended algorithm for computing the reduced minimum interval is used, the result is a 1 second interval. If the RTP implementation uses a different algorithm, the session bandwidth should be set in such a way to cause the reduced minimum interval to be 1 second.
RTP実装は、セッションに送信者として参加するように構成されています。セッションは、360 kbpsを使用するように構成されています。削減された最小間隔を計算するために推奨されるアルゴリズムが使用される場合、結果は1秒間隔です。RTP実装が異なるアルゴリズムを使用する場合、セッション帯域幅をそのような方法で設定して、最小間隔を1秒にするように設定する必要があります。
Once joining the session, the RTP implementation should begin to send both RTP and RTCP packets. The interval between RTCP packets is measured and stored until 100 intervals have been collected.
セッションに参加すると、RTP実装はRTPパケットとRTCPパケットの両方の送信を開始する必要があります。RTCPパケット間の間隔は測定され、100の間隔が収集されるまで保存されます。
The test is deemed successful if the smallest interval is no less than 1/2 a second, and the largest interval is no more than 1.5 seconds. The average should be close to 1 second.
最小間隔が1/2秒以上、最大の間隔が1.5秒以内である場合、テストは成功したとみなされます。平均は1秒近くになるはずです。
3 RTP translators
3 RTP翻訳者
RTP translators should be tested in the same manner as end systems, with the addition of the tests described in this section.
RTP翻訳者は、このセクションで説明されているテストを追加して、ENDシステムと同じ方法でテストする必要があります。
The architecture for testing RTP translators is shown in Figure 3.
RTP翻訳者をテストするためのアーキテクチャを図3に示します。
+-----------------+
+--------+ RTP Translator +-----+
| +-----------------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Second RTP |
| implementation | | implementation |
+----------------+ +----------------+
Figure 3: Testing architecture for translators
図3：翻訳者のテストアーキテクチャ
The first RTP implementation is instructed to send data to the translator, which forwards the packets to the other RTP implementation, after translating then as desired. It should be verified that the second implementation can playout the translated packets.
最初のRTP実装は、翻訳者にデータを送信するように指示されます。これにより、翻訳後にパケットが他のRTP実装に転送されます。2番目の実装では、翻訳されたパケットを再生できることを確認する必要があります。
It should be verified that the packets received by the second implementation have the same SSRC as those sent by the first implementation. The CC should be zero and CSRC fields should not be present in the translated packets. The other RTP header fields may be rewritten by the translator, depending on the translation being performed, for example
2番目の実装で受信したパケットは、最初の実装によって送信されたものと同じSSRCを持っていることを確認する必要があります。CCはゼロである必要があり、CSRCフィールドは翻訳されたパケットに存在しないでください。他のRTPヘッダーフィールドは、たとえば実行される翻訳に応じて、翻訳者によって書き直される場合があります。
o the payload type should change if the translator changes the encoding of the data
o 翻訳者がデータのエンコードを変更すると、ペイロードタイプが変更されるはずです
o the timestamp may change if, for example, the encoding, packetisation interval or framerate is changed
o たとえば、エンコーディング、パケット化間隔、またはフレームレートが変更された場合、タイムスタンプが変更される場合があります
o the sequence number may change if the translator merges or splits packets
o 翻訳者がパケットをマージまたは分割すると、シーケンス番号が変更される場合があります
o padding may be added or removed, in particular if the translator is adding or removing encryption
o 特に翻訳者が暗号化を追加または削除している場合、パディングを追加または削除することができます
o the marker bit may be rewritten
o マーカービットが書き換えられる場合があります
If the translator modifies the contents of the data packets it should be verified that the corresponding change is made to the RTCP packets, and that the receivers can correctly process the modified RTCP packets. In particular
翻訳者がデータパケットの内容を変更する場合、対応する変更がRTCPパケットに行われ、受信機が変更されたRTCPパケットを正しく処理できることを確認する必要があります。特に
o the SSRC is unchanged by the translator
o SSRCは翻訳者によって変更されていません
o if the translator changes the data encoding it should also change the octet count field in the SR packets
o 翻訳者がデータをエンコードするデータを変更した場合、SRパケットのオクテットカウントフィールドも変更するはずです
o if the translator combines multiple data packets into one it should also change the packet count field in SR packets
o 翻訳者が複数のデータパケットを1つに結合する場合、SRパケットのパケットカウントフィールドも変更する必要があります
o if the translator changes the sampling frequency of the data packets it should also change the RTP timestamp field in the SR packets
o 翻訳者がデータパケットのサンプリング周波数を変更した場合、SRパケットのRTPタイムスタンプフィールドも変更するはずです
o if the translator combines multiple data packets into one it should also change the packet loss and extended highest sequence number fields of RR packets flowing back from the receiver (it is legal for the translator to strip the report blocks and send empty SR/RR packets, but this should only be done if the transformation of the data is such that the reception reports cannot sensibly be translated)
o 翻訳者が複数のデータパケットを1つに結合する場合、パケットの損失を変更し、RRパケットの最高のシーケンス番号フィールドをレシーバーから戻って延長する必要があります（翻訳者がレポートブロックを削除して空のSR/RRパケットを送信することは合法です。しかし、これは、データの変換が、受信レポートを賢明に翻訳できないようにする場合にのみ行う必要があります）
o the translator should forward SDES CNAME packets
o 翻訳者は、SDES CNAMEパケットを転送する必要があります
o the translator may forward other SDES packets
o 翻訳者は、他のSDESパケットを転送できます
o the translator should forward BYE packets unchanged
o 翻訳者は、変更されていないバイパケットを転送する必要があります
o the translator should forward APP packets unchanged
o 翻訳者は、変更されていないアプリパケットを転送する必要があります
When the translator exits it should be verified to send a BYE packet to each receiver containing the SSRC of the other receiver. The receivers should be verified to correctly process this BYE packet (this is different to the BYE test in section 2.3.3 since multiple SSRCs may be included in each BYE if the translator also sends its own RTCP information).
翻訳者が終了するときは、他のレシーバーのSSRCを含む各レシーバーにバイパケットを送信するように検証する必要があります。受信機は、このByeパケットを正しく処理するために検証する必要があります（これは、翻訳者が独自のRTCP情報を送信する場合、複数のSSRCが各BYEに含まれる可能性があるため、セクション2.3.3のBYEテストとは異なります）。
4 RTP mixers
4 RTPミキサー
RTP mixers should be tested in the same manner as end systems, with the addition of the tests described in this section.
RTPミキサーは、このセクションで説明されているテストを追加して、エンドシステムと同じ方法でテストする必要があります。
The architecture for testing RTP mixers is shown in Figure 4.
RTPミキサーをテストするためのアーキテクチャを図4に示します。
The first and second RTP implementations are instructed to send data packets to the RTP mixer. The mixer combines those packets and sends them to the third RTP implementation. The mixer should also process RTCP packets from the other implementations, and should generate its own RTCP reports.
1番目と2番目のRTP実装は、RTPミキサーにデータパケットを送信するように指示されています。ミキサーはこれらのパケットを組み合わせて、3番目のRTP実装に送信します。また、ミキサーは他の実装からRTCPパケットを処理する必要があり、独自のRTCPレポートを生成する必要があります。
+----------------+
| Second RTP |
| implementation |
+-------+--------+
|
| +-----------+
+-------+ RTP Mixer +-----+
| +-----------+ |
| |
+-------+--------+ +-------+--------+
| First RTP | | Third RTP |
| implementation | | implementation |
+----------------+ +----------------+
Figure 4: Testing architecture for mixers
図4：ミキサーのテストアーキテクチャ
It should be verified that the third RTP implementation can playout the mixed packets. It should also be verified that
3番目のRTP実装が混合パケットを再生できることを確認する必要があります。また、それを確認する必要があります
o the CC field in the RTP packets received by the third implementation is set to 2
o 3番目の実装で受信したRTPパケットのCCフィールドは2に設定されています
o the RTP packets received by the third implementation contain 2 CSRCs corresponding to the first and second RTP implementations
o 3番目の実装で受信したRTPパケットには、最初と2番目のRTP実装に対応する2つのCSRCが含まれています
o the RTP packets received by the third implementation contain an SSRC corresponding to that of the mixer
o 3番目の実装で受信したRTPパケットには、ミキサーのそれに対応するSSRCが含まれています
It should next be verified that the mixer generates SR and RR packets for each cloud. The mixer should generate RR packets in the direction of the first and second implementations, and SR packets in the direction of the third implementation.
次に、ミキサーが各クラウドのSRおよびRRパケットを生成することを確認する必要があります。ミキサーは、最初と2番目の実装の方向にRRパケットを生成し、SRパケットは3番目の実装の方向に生成する必要があります。
It should be verified that the SR packets sent to the third implementation do not reference the first or second implementations, and vice versa.
3番目の実装に送信されたSRパケットは、最初の実装または2番目の実装を参照しないことを確認する必要があります。
It should be verified that SDES CNAME information is forwarded across the mixer. Other SDES fields may optionally be forwarded.
SDES CNAME情報がミキサー全体に転送されることを確認する必要があります。他のSDESフィールドはオプションで転送される場合があります。
Finally, one of the implementations should be quit, and it should be verified that the other implementations see the BYE packet. This implementation should then be restarted and the mixer should be quit. It should be verified that the implementations see both the mixer and the implementations on the other side of the mixer quit (illustrating response to BYE packets containing multiple sources).
最後に、実装の1つを終了する必要があり、他の実装でバイパケットが表示されることを確認する必要があります。この実装は再起動し、ミキサーを終了する必要があります。実装では、ミキサーの反対側にあるミキサーと実装の両方が終了することを確認する必要があります（複数のソースを含むバイパケットへの応答を示す）。
5 SSRC collision detection
5 SSRC衝突検出
RTP has provision for the resolution of SSRC collisions. These collisions occur when two different session participants choose the same SSRC. In this case, both participants are supposed to send a BYE, leave the session, and rejoin with a different SSRC, but the same CNAME. The purpose of this test is to verify that this function is present in the implementation.
RTPには、SSRC衝突の解決に関する規定があります。これらの衝突は、2人の異なるセッション参加者が同じSSRCを選択したときに発生します。この場合、両方の参加者は、さようならを送信し、セッションを去り、別のSSRCで再生することになっていますが、同じcnameです。このテストの目的は、この機能が実装に存在することを確認することです。
The test is straightforward. The RTP implementation is made to join the multicast group as a receiver. A test instrument waits for the first RTCP packet. Once it arrives, the test instrument notes the CNAME and SSRC from the RTCP packet. The test instrument then generates an RTCP receiver report. This receiver report contains an SDES chunk with an SSRC matching that of the RTP implementation, but with a different CNAME. At this point, the implementation should send a BYE RTCP packet (containing an SDES chunk with the old SSRC and CNAME), and then rejoin, causing it to send a receiver report containing an SDES chunk, but with a new SSRC and the same CNAME.
テストは簡単です。RTP実装は、レシーバーとしてマルチキャストグループに参加するために行われます。テスト機器は、最初のRTCPパケットを待ちます。到着すると、テスト機器はRTCPパケットからCNAMEとSSRCに注意します。テスト機器は、RTCPレシーバーレポートを生成します。このレシーバーレポートには、RTP実装のそれと一致するSSRCを備えたSDEチャンクが含まれていますが、異なるCNAMEがあります。この時点で、実装はさようならRTCPパケット（古いSSRCとCNAMEとともにSDESチャンクを含む）を送信してから再生する必要があります。。
The test is deemed successful if the RTP implementation sends the RTCP BYE and RTCP RR as described above within one minute of receiving the colliding RR from the test instrument.
RTPの実装が、テスト機器から衝突RRを受け取ってから1分以内に説明したように、RTCP BYEおよびRTCP RRを送信する場合、テストは成功したとみなされます。
6 SSRC Randomization
6 SSRCランダム化
According to the RTP specification, SSRC's are supposed to be chosen randomly and uniformly over a 32 bit space. This randomization is beneficial for several reasons:
RTP仕様によれば、SSRCは32ビットスペースでランダムかつ均一に選択されることになっています。このランダム化は、いくつかの理由で有益です。
o It reduces the probability of collisions in large groups.
o 大規模なグループでの衝突の可能性を減らします。
o It simplifies the process of group sampling [3] which depends on the uniform distribution of SSRC's across the 32 bit space.
o 32ビットスペース全体にわたるSSRCの均一な分布に依存するグループサンプリング[3]のプロセスを簡素化します。
Unfortunately, verifying that a random number has 32 bits of uniform randomness requires a large number of samples. The procedure below gives only a rough validation to the randomness used for generating the SSRC.
残念ながら、乱数に32ビットの均一なランダム性があることを確認するには、多数のサンプルが必要です。以下の手順では、SSRCの生成に使用されるランダム性に対する大まかな検証のみを示します。
The test runs as follows. The RTP implementation joins the group as a receiver. The test instrument waits for the first RTCP packet. It notes the SSRC in this RTCP packet. The test is repeated 2500 times, resulting in a collection of 2500 SSRC.
テストは次のように実行されます。RTP実装は、レシーバーとしてグループに参加します。テスト機器は、最初のRTCPパケットを待ちます。このRTCPパケットのSSRCに注意してください。このテストは2500回繰り返され、2500 SSRCのコレクションが生じます。
The are then placed into 25 bins. An SSRC with value X is placed into bin FLOOR(X/(2**32 / 25)). The idea is to break the 32 bit space into 25 regions, and compute the number of SSRC in each region. Ideally, there should be 40 SSRC in each bin. Of course, the actual number in each bin is a random variable whose expectation is 40. With 2500 SSRC, the coefficient of variation of the number of SSRC in a bin is 0.1, which means the number should be between 36 and 44. The test is thus deemed successful if each bin has no less than 30 and no more than 50 SSRC.
次に、25個のビンに配置されます。値xを備えたSSRCがビン床に配置されます（x /（2 ** 32 /25））。アイデアは、32ビットスペースを25の地域に分割し、各地域のSSRCの数を計算することです。理想的には、各ビンに40のSSRCがあるはずです。もちろん、各ビンの実際の数は、期待値が40であるランダム変数です。2500SSRCでは、ビン内のSSRC数の変動係数は0.1です。つまり、数は36〜44でなければなりません。したがって、各ビンに30以上、50 SSRC以下の場合、成功したとみなされます。
Running this test may require substantial amounts of time, particularly if there is no automated way to have the implementation join the session. In such a case, the test can be run fewer times. With 26 tests, half of the SSRC should be less than 2**31, and the other half higher. The coefficient of variation in this case is 0.2, so the test is successful if there are more than 8 SSRC less than 2**31, and less than 26.
このテストを実行すると、特に実装にセッションに参加する自動化された方法がない場合は、かなりの時間がかかる場合があります。そのような場合、テストはより少ない回数を実行できます。26回のテストでは、SSRCの半分は2 ** 31未満で、残りの半分は高くする必要があります。この場合の変動係数は0.2であるため、8 SSRCを超える2 ** 31未満、26未満の場合、テストは成功します。
In general, if the SSRC is collected N times, and there are B bins, the coefficient of variation of the number of SSRC in each bin is given by:
一般に、SSRCがn回収集され、Bビンがある場合、各ビンのSSRC数の変動係数は次のように与えられます。
coeff = SQRT( (B-1)/N )
coeff = sqrt（（b-1）/n）
7 Security Considerations
7つのセキュリティ上の考慮事項
Implementations of RTP are subject to the security considerations mentioned in the RTP specification [1] and any applicable RTP profile (e.g., [2]). There are no additional security considerations implied by the testing strategies described in this memo.
RTPの実装には、RTP仕様[1]および該当するRTPプロファイル（[2]など）に記載されているセキュリティ上の考慮事項の対象となります。このメモで説明されているテスト戦略によって暗示される追加のセキュリティ上の考慮事項はありません。
8 Authors' Addresses
8著者の住所
Colin Perkins USC Information Sciences Institute 3811 North Fairfax Drive Suite 200 Arlington, VA 22203
Colin Perkins USC Information Sciences Institute 3811 North Fairfax Drive Suite 200アーリントン、バージニア州22203
EMail: csp@isi.edu
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave. First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグダイナミクスソフト72イーグルロックアベニュー1階イーストハノーバー、ニュージャージー07936
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングシュルツリンヌコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
9 References
9参照
[1] Schulzrinne, H., Casner, S., Frederick R. and V. Jacobson, "RTP: A Transport Protocol to Real-Time Applications", Work in Progress (update to RFC 1889), March 2001.
[1] Schulzrinne、H.、Casner、S.、Frederick R.、V。Jacobson、「RTP：リアルタイムアプリケーションへの輸送プロトコル」、2001年3月、進行中の作業（RFC 1889の更新）。
[2] Schulzrinne H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", Work in Progress (update to RFC 1890), March 2001.
[2] Schulzrinne H.およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、2001年3月、進行中の作業（RFC 1890の更新）。
[3] Rosenberg, J. and Schulzrinne, H. "Sampling of the Group Membership in RTP", RFC 2762, February 2000.
[3] Rosenberg、J。およびSchulzrinne、H。「RTPのグループメンバーシップのサンプリング」、RFC 2762、2000年2月。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
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エディター機能の資金は現在、インターネット協会によって提供されています。