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
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.
著作権（C）インターネット協会（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.
典型的なテスト・セットアップでは、1つのイーサネットセグメント上に3台のマシンを構成する場合があります。これらのマシンの二つは、第三は、テスト機器を実行し、RTPの実装を実行します。試験装置は、アプリケーションレベルのパケットフォワーダです。両方の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の実施送信と第一の受信と、反転されます。
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実装が（セクション4を参照）CSRCリストと非ゼロCCフィールドを含むパケットをプレイアウトすることができることを確認します。
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.
RTPの実装は、データパケットに加えて、RTCP制御パケットを送信するために必要とされます。基本的な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パケットを生成することを確認する必要があり、そして第二のアプリケーションは現在、単一のレポートブロックを含むRRパケットを生成します。これらのSRとRRパケットが正しく受信されていることを確認する必要があります。 SRパケットの次の機能も検証する必要があります。
o that the length field is consistent with both the length of the packet and the RC field
長さフィールドは、パケットの長さおよびRCフィールドの両方と一致しているO
o that the SSRC in SR packets is consistent with that in the RTP data packets
SRパケット内のSSRCは、RTPデータパケットのそれと一致しているO
o that the NTP timestamp in the SR packets is sensible (matches the wall clock time on the sending machine)
SRパケット内のNTPタイムスタンプが賢明であるO（送信側のマシン上壁時計の時刻と一致します）
o that the RTP timestamp in the SR packets is consistent with that in the RTP data packets
SRパケット内のRTPタイムスタンプはRTPデータパケットのそれと一致しているO
o that the packet and octet count fields in the SR packets are consistent with the number of RTP data packets transmitted
SRパケット内のパケットとオクテットカウントフィールドは、送信されたRTPデータパケットの数と一致していることをO
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
レポートブロック内のSSRCは、データパケットが受信されているのものと一致していることO
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).
前回の送信者レポートのタイムスタンプは、SRパケットのそれと一致していることO（すなわち、試験機器を通過する各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)
最後のSRフィールド以降の遅延が賢明であると、O（推定値は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パケットで報告されたのinterarrivalジッタを高めるためにする必要があります。
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).
どちらの実装では、実行する必要がありますが、どちらがデータパケットを送信する必要があります。多くの場合CNAME SHOULD（RTP仕様およびプロファイル内の規則に従って、RTCPパケットは、観察されるべきであり、そのパケットはCNAME項目が含まれていることを、各化合物パケットはSDESパケットが含まれていることを確認し、CNAMEが選択されなければなりません）フォーム `example@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).
アプリケーションが追加SDESアイテムをサポートしている場合、彼らが何らかのSDESパケット（これらの追加項目が含まれているの正確な割合は、アプリケーションとプロファイルに依存している）で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.
実装が正しく、それはそれらを送信しない場合でも、NAME、EMAIL、PHONE、LOC、NOTE、ツールと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 BYEパケットが送信されることが確認されなければなりません。なお、第2の実装は、このBYEパケットに反応し、最初の実装がセッションを残していることに留意することを確認する必要があります。
If the test succeeds, the implementations should be restarted and the process repeated with the second implementation leaving the session.
テストが成功した場合、実装は、再起動処理がセッションを残して第二の実装で繰り返されるべきです。
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オクテット名フィールドが認識されないAPPパケットを無視することを確認する必要があります。 APPパケットを使用する実装は期待どおりに動作することを確認する必要があります。
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
時間内の任意の所望の時点でRTPパケットを送信する送信するかどうかを実装を強制する能力O
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
テスト機器に即座に知られるように、この終了をRTPセッションへの関与を終了するためにアプリケーションを強制し、ための能力O
o the ability to set the session bandwidth and RTCP sender and receiver fractions
セッション帯域幅とRTCPの送信者と受信者の画分を設定する機能O
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.
これらの第二は、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
RTCPパケットのO定期送信
o randomization of the interval for RTCP packet transmission
RTCPパケット送信間隔のOランダム化
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メガビット/秒と言います。これは、実装が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;
平均間隔は4.5と5.5秒の間はO;
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.
X及びX + 500msの間隔の数は、任意のxに対して、X + 500ミリ秒であり、x + 1S間隔の数よりも少ない、O。
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パケットの到着を待ちます。それが到着すると、テスト機器は、時間を指摘し、その直後に別のSSRCとSDES CNAMEでそれぞれ、実施に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パケットサイズを計算するための仕様で定義された指数平均化アルゴリズムを使用しなければなりません。これは、受信したパケット（実装は一つだけ自体を送信した）によって支配されるので、平均は、テスト機器によって送信されたRTCPパケットの長さにほぼ等しくなります。したがって、実装から第一及び第二のRTCPパケット間時間の最小量です。
T > 101 * S / ( B * Fr * (e-1.5) * 2 )
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は、Frは受信機（通常は75％）に割り当てられたRTCP帯域幅の一部であるRTCP帯域幅（セッション帯域幅の正常パーセント）であり、Eは自然指数。見直しがなければ、この最小間隔Teがはるかに小さいのようになります。
Te > MAX( [ S / ( B * Fr * (e-1.5) * 2 ) ] , [ 2.5 / (e-1.5) ] )
TE> MAX（[S /（B * Frの*（E-1.5）* 2）]、[2.5 /（S-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は十分に小さく選択しなければなりません。これらのパラメータのための合理的な選択肢は、毎秒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の実装は、送信者であるときは、テストケースのために繰り返されるべきです。これは、インプリメンテーションが少なくとも一度第二のRTPパケットを送信することによって達成されます。この場合、第1および第2のRTCPパケット間の間隔は、以上であってはなりません。
T > S / ( B * Fs * (e-1.5) * 2 )
T> C /（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が通常の25％の送信者に割り当てられたRTCP帯域幅の割合です。 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パケットを待ちます。それが到着すると、テスト機器は、時間を指摘し、そしてすぐに、実装に異なるSSRCとSDES CNAMEとそれぞれを50個のRTCP RRパケットと50のRTCP SRパケットを送信します。試験装置は、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
= 101 * S / B T
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キロバイト/秒です。
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.
前のテストが繰り返されます。しかし、試験機器は、10のRTPパケットの代わりに、50、及び10のRTCP SR 90 RTCP RRの代わりにそれぞれの50を送信します。また、実装は、独自のRTCPパケットの一つ一つの変速機との間に少なくとも1つのRTPパケットを送信するように構成されています。
In this case, the average RTCP interval should be within 5% of:
この場合には、平均RTCP間隔は5％以内であるべきです。
T = 11 * S / (B * Fs)
T = 11 C * /（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が送信者（通常は25％）のために割り当てられたRTCP帯域幅の割合です。 Tは、数十秒程度であるように、BとSの値が十分に小さく選択されるべきです。合理的な選択は、S = 1024ビット、B = 1.5 KB /秒です。
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パケットを送信し、同じ長さSのそれぞれ、および異なるSDES CNAMEとSSRC。その後、別のRTCPパケットを送信するために実装を待ちます。それがないと、試験用計器100はBYEパケット、異なるSSRCを含むそれぞれを送信するが、最初のRTCPパケットの一つからSSRCに一致します。各BYEは、試験機器によって送信されたRTCPパケットと同じサイズでなければなりません。これは簡単に長さアウトパッドにBYE理由を使用することによって達成されます。実装から次のRTCPパケットの時間は、注目されます。この（第3 RTCPパケット）と前回の間の遅延Tは、以下でなければなりません。
T < 3 * S / (B * Fr * (e-1.5) * 2)
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のサイズとBYEパケットである場合、Bは、Frは受信機に割り当てられたRTCP帯域幅の割合である、RTCP帯域幅であり、eは自然指数です。 Bは、Tは、数十秒程度であるように選択されるべきです。合理的な選択は、S = 1024ビット毎秒B = 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.
このテストは、実装の基本的な正しさを証明しています。逆再考なしの実装では、上記の金額限り、ほぼ100倍のために、その次のRTCPパケットを送信しません。
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.
第二の試験では、実装は、受信機としてセッションに参加します。すぐに、その最初のRTCPパケットを送信するように、試験用計器は、100個のRTCP RRパケットを送信し、同じ長さSのそれぞれ、100個のBYEパケットが続く、また、長さSの各RTCPパケットは異なるSDES CNAMEとSSRCを運び、そしてあります同じSSRCと正確に1つのBYEパケットと照合。これは、グループメンバーシップの急速な増加とその後の急速な低下を確認するために、実装が発生します。
The test is deemed successful if the next RTCP packet shows up T seconds after the first, and T is within:
次のRTCPパケットが最初の後にT秒を示し、Tは範囲内にある場合、テストは成功したとみなされます。
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が受信されるたびに実行しようとするかもしれません。実装はこれをしなかった場合は、すぐにBYEさんのストリームを受信した後、RTCPパケットを送信することになります。このテストが機能するためには、Bは、1MB /秒の周りに大きい値であるように選択されなければなりません。
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.
BYEの再考アルゴリズムは、BYEパケットに適用を除いて、定期的な見直しとほとんど同じ方法で動作します。ユーザーがグループを離れると他の人がBYEのを送信している場合は、代わりにすぐにBYEを送るのではなく、そのBYEパケットの送信を遅らせることがあります。
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パケットを待ちます。試験機器は、このパケットを受信した場合、試験装置は、直ちに、100個のRTCP RRパケットを送信し、同じ長さSのそれぞれ、それぞれが異なるSSRCとSDES CNAMEを含みます。試験機器は、実装から次のRTCPパケットを受信すると、RTPの実装は、RTPセッションを残すためになされたものであり、この情報は、いくつかの非RTP手段を通じて試験装置に搬送されます。試験機器は、その後、100個のBYEパケットを送信異なるSSRCとそれぞれ、それぞれが以前に送信されたRTCPパケットのSSRCと一致します。これらBYEパケットの各々は、また、サイズSの直後BYEパケット以下、試験機器は、元の100のRTCPパケットと同じSSRC /のCNAMEを使用して、100個のRTCP RRパケットを送信しています。
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:
実装がBYEを送信していないのいずれか決して場合、テストは成功したとみなされ、またはそれがない場合は、BYEはないT秒よりも早く、および試験装置で受信されません以降* 3よりT秒、実装がセッションを、左後Tは、次のとおりです。
T = 100 * S / ( 2 * (e-1.5) * B )
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帯域幅の割合です。 Tが50秒程度であるように、SとBが選択されるべきです。合理的な選択は、S = 1024ビット、B = 1.1キロバイト/ 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パケットの送信は、それがグループから脱退することを決定した後、実装は非BYE 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パケットを送信することになっています。参加者がセッションを離れたとき、彼らはBYEを送ることができ、しかし、これは必須ではありません。さらに、BYEの見直しは、BYEが送られることはありませんする可能性があります。その結果、参加者は長い時間で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パケットを送信異なるSDESとSSRCとそれぞれ、時刻を指摘しています。これは、実装は、それがそのRTCP間隔を増加させ、101グループの参加者が今そこにあると信じていることになります。試験装置は、実装から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)
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 )
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.
Tiは分のオーダーであるので、作業にこの試験のために、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パケットの最小間隔が大きいセッション帯域幅のために低減することができます。減少は唯一の送信者に適用されます。この最小間隔を計算するための推奨アルゴリズムは、kbps単位で、RTPセッション帯域幅で割った値360です。 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トランスレータは、このセクションで説明するテストを加えて、エンドシステムと同様に試験しなければなりません。
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、それはまた、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)
翻訳者がレポートブロックを削除し、空のSR / RRパケットを送信するために翻訳者が一つに複数のデータパケットを組み合わせた場合、O、それはまた、パケットロスや受信機から逆流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
翻訳者はそのままBYEパケットを転送する必要がありますoを
o the translator should forward APP packets unchanged
トランスレータは変わらないAPPパケットを転送する必要があります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パケットを送信するために確認する必要があります。受信機が正しく、このBYEパケットを処理するために検証されなければならない（これは、それぞれに含まれていてもよい複数SSRCsのでセクション2.3.3にBYE試験に異なるBYE翻訳者はまた、自身のRTCP情報を送信した場合）。
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.
第一及び第二のRTP実装はRTPミキサーにデータパケットを送信するように指示されています。ミキサーは、これらのパケットを結合し、第三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
第三のRTP実装が混在パケットをプレイアウトすることができることが確認されなければなりません。また、ことを確認する必要があります
o the CC field in the RTP packets received by the third implementation is set to 2
O第三の実装によって受信されたRTPパケットにおけるCCフィールドは2に設定されています
o the RTP packets received by the third implementation contain 2 CSRCs corresponding to the first and second RTP implementations
第三の実装によって受信されたRTPパケットは、第一及び第二のRTPの実装に対応する2 CSRCsを含むoを
o the RTP packets received by the third implementation contain an SSRC corresponding to that of the mixer
第三の実装によって受信されたRTPパケットは、ミキサのそれに対応するSSRCを含むoを
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パケットを生成することが確認されなければなりません。ミキサは、RRの第一及び第二の実装の方向にパケット、及び第三の実施の方向にSRパケットを生成すべきです。
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パケットは、第1または第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つが終了しなければならない、そして他の実装は、BYEパケットを参照することを確認する必要があります。この実装は、その後、再起動する必要があるとミキサーが終了する必要があります。実装がミキサとミキサの他方の側の実装の両方が（複数のソースを含むBYEパケットに対する応答を示す）終了見ることが確認されなければなりません。
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衝突の解決のために提供されています。これらの衝突は、二つの異なるセッションの参加者が同じSSRCを選択したときに発生します。この場合、両方の参加者は異なるSSRCが、同じCNAMEで、BYEを送ってセッションを終了し、再度参加することになっています。この試験の目的は、この機能は実装に存在することを確認することです。
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とSDESチャンクが含まれていますが、別のCNAMEと。この時点で、実装はそれがSDESチャンクを含むレシーバレポートを送信させる、（古いSSRC及びCNAMEとSDESチャンクを含む）BYE RTCPパケットを送信した後、再度参加する必要がありますが、新しいSSRCと同じCNAMEを持ちます。
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.
試験装置から衝突RRを受信してから1分以内に上記のようにRTPの実装は、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 SSRCの集まりで、その結果、2500回繰り返されます。
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はビンFLOOR（X /（2 ** 25分の32））に配置されます。アイデアは、25個の領域に32ビットの空間を破壊し、各領域におけるSSRCの数を計算することです。理想的には、各ビンに40 SSRCがあるはずです。もちろん、各ビン内の実際の数は、数36及び44の試験の間でなければならない意味を持つはずです40 2500 SSRC、ビン内のSSRCの数の変動係数は0.1である確率変数であり、各ビンが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であるので、** 31 2未満、26未満8つ以上のSSRCがある場合、試験は成功です。
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
コリン・パーキンスUSC情報科学研究所3811ノースフェアファックスドライブスイート200アーリントン、バージニア州22203
EMail: csp@isi.edu
メールアドレス：csp@isi.edu
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave. First Floor East Hanover, NJ 07936
ジョナサン・ローゼンバーグdynamicsoft 72イーグルロックアベニュー。一階イーストハノーバー、NJ 07936
EMail: jdrosen@dynamicsoft.com
メールアドレス：jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
メールアドレス：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.、フレデリックR.およびV. Jacobson氏、 "RTP：リアルタイムアプリケーションへのトランスポートプロトコル"、（RFC 1889に更新）進行中の作業、2001年3月。
[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プロフィール" が進行中で働いています（RFC 1890へのアップデート）、2001年3月。
[3] Rosenberg, J. and Schulzrinne, H. "Sampling of the Group Membership in RTP", RFC 2762, February 2000.
[3]ローゼンバーグ、J.とSchulzrinneと、H. "RTPでのグループメンバーシップのサンプリング"、RFC 2762、2000年2月。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。