RFC3158 日本語訳
3158 RTP Testing Strategies. C. Perkins, J. Rosenberg, H. Schulzrinne. August 2001. (Format: TXT=48208 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Perkins
Request for Comments: 3158 USC/ISI
Category: Informational J. Rosenberg
dynamicsoft
H. Schulzrinne
Columbia University
August 2001
コメントを求めるワーキンググループC.パーキンス要求をネットワークでつないでください: 3158年のUSC/ISIカテゴリ: 情報のJ.のローゼンバーグdynamicsoft H.Schulzrinneコロンビア大学2001年8月
RTP Testing Strategies
RTPテスト戦略
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
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
1つの序論。 . . . . . . . . . . . . . . . . . . . . . 2 2台のエンドシステム. . . . . . . . . . . . . . . . . . . . . . 2 2.1メディアは.32.2RTP Header Extension. . . . . . . . . . . . . . . 4 2.3Basic RTCP. . . . . . . . . . . . . . . . . . . 4 2.3.1Senderを輸送します、そして、受信機レポート. . . . . . . . 4 2.3.2のRTCPソース記述パケット. . . . . . 6 2.3.3のRTCP BYEパケット. . . . . . . . . . . . . . 7 2.3.4ApplicationはRTCPパケット. . . . . . 7 2.4RTCPトランスミッション間隔を定義しました; . . . . . . . . . . . 7 2.4.1 基本的なBehavior、.82.4、.2Step、backoff.92.4.3Steady州Behavior. . . . . . . . . . 11 2.4.4Reverse Reconsideration. . . . . . . . . 12 2.4.5BYE Reconsiderationを接合してください、.132.4、.6Timing、出かけているメンバー. . . . . . . . . . . . 14 2.4.7Rapid SRの.153人のRTP翻訳者. . . . . . . . . . . . . . . . . . . . 15 4RTPミキサー。 . . . . . . . . . . . . . . . . . . . . . . 17 5 SSRC衝突検出。 . . . . . . . . . . . . . . . 18
Perkins, et al. Informational [Page 1] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[1ページ]のRFC3158RTP
6 SSRC Randomization. . . . . . . . . . . . . . . . . . . 19 7 Security Considerations . . . . . . . . . . . . . . . . 20 8 Authors' Addresses. . . . . . . . . . . . . . . . . . . 20 9 References. . . . . . . . . . . . . . . . . . . . . . . 21 Full Copyright Statement. . . . . . . . . . . . . . . . . 22
6SSRC無作為化。 . . . . . . . . . . . . . . . . . . 19 7 セキュリティ問題. . . . . . . . . . . . . . . . 20 8作者のアドレス。 . . . . . . . . . . . . . . . . . . 20 9つの参照箇所。 . . . . . . . . . . . . . . . . . . . . . . 21 完全な著作権宣言文。 . . . . . . . . . . . . . . . . 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 |
+----------------+ +----------------+
+-----------------+ +--------+ 試験計器+-----+ | +-----------------+ | | | +-------+--------+ +-------+--------+ | 最初に、RTP| | 第2RTP| | 実現| | 実現| +----------------+ +----------------+
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パケットを試験計器に送るよう命令されます。(試験計器はそれらの間にパケットを送ります)。
Perkins, et al. Informational [Page 2] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[2ページ]のRFC3158RTP
2.1 Media transport
2.1 メディア輸送
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番目のためのものです。 これが成功するなら、2番目の実現が発信していて、1番目が受信されている状態で、過程は逆にされます。
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 一連番号巻きつけて着るドレスの間、正しい操作について確かめてください。
Perkins, et al. Informational [Page 3] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[3ページ]のRFC3158RTP
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 選ばれたペイロード形式、プロフィール、およびあらゆるセッションレベルコントロールプロトコルに従って、ペイロードタイプの正しい選択について確かめてください。
2.2 RTP Header Extension
2.2 RTPヘッダー拡張子
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.
実現がヘッダー拡大を利用するなら、プロフィールの特定の分野と拡大の長さの分野が正しく設定されて、パケットの長さが一貫していることが確かめられるべきです。
2.3 Basic RTCP
2.3 基本的なRTCP
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にそんなに示されます。
2.3.1 Sender and receiver reports
2.3.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番目のアプリケーションが現在1つのレポートブロックを含むRRパケットを発生させることが確かめられるべきです。 これらのSRとRRパケットが正しく受け取られることが確かめられるべきです。 また、SRパケットの以下の特徴は確かめられるべきです:
Perkins, et al. Informational [Page 4] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[4ページ]のRFC3158RTP
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はデータ・パケットの受け取るそれと一致しています。
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 interarrivalジターは小さいです(試験計器とネットワーク条件によるので、正確な値を与えることができませんが、非常に小さいジターはこのシナリオに存在しているべきです)。
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分野に同意するべきです)
Perkins, et al. Informational [Page 5] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[5ページ]のRFC3158RTP
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.
次に、試験計器の損失率はゼロに返されます、そして、いくらかの無作為の量に従って、それは各パケットを遅らせさせられます(正確な量をメディアタイプに頼っていますが、平均したinterarrival現代のわずかな部分は妥当です)。 この効果はRRパケットの報告されたinterarrivalジターを増加させることであるべきです。
If these tests succeed, the process should be repeated with the second implementation transmitting and the first receiving.
これらのテストが成功するなら、2番目の実現が伝わっていて、1番目が受信されている状態で、過程は繰り返されるべきです。
2.3.2 RTCP source description packets
2.3.2 RTCPソース記述パケット
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の品目を含んでいて、RTP仕様とプロフィールの規則に従ってCNAMEが選ばれていることが(プロフィール定義でくつがえされて、多くの場合、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、メール、電話、LOC、注意、TOOL、および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分野が終えられたゼロでないことが確かめられるべきです。
Perkins, et al. Informational [Page 6] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[6ページ]のRFC3158RTP
It should be verified that an implementation correctly receives SDES items which do not terminate in a zero byte.
実現が正しくゼロでバイトを終えないSDESの品目を受けることが確かめられるべきです。
2.3.3 RTCP BYE packets
2.3.3 RTCP BYEパケット
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.
テストが成功するなら、実現は再開されるべきでした、そして、2番目の実現がセッションを残していて、過程は繰り返されました。
It should be verified that implementations handle BYE packets containing the optional reason for leaving text (ignoring the text is acceptable).
実現がテキストを残す任意の理由を含むBYEパケットを扱うことが(テキストを無視するのは許容できます)確かめられるべきです。
2.3.4 Application defined RTCP packets
2.3.4 アプリケーションはRTCPパケットを定義しました。
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パケットを使用する実現は、予想されるように振る舞うことを確かめるべきです。
2.4 RTCP transmission interval
2.4 RTCPトランスミッション間隔
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とRTCPにRTP実現にパケットを送ることができなければなりません。 また、試験計器はRTP実現で送られたパケットを受けることができるべきです、それらを分析して、それらのパケットに基づく測定基準を計算して。
Perkins, et al. Informational [Page 7] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[7ページ]のRFC3158RTP
+--------------+
| test |
| instrument |
+-----+--------+
|
------+-----------+-------------- LAN
|
+-------+--------+
| RTP |
| implementation |
+----------------+
+--------------+ | テスト| | 器具| +-----+--------+ | ------+-----------+-------------- LAN| +-------+--------+ | RTP| | 実現| +----------------+
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手段で試験計器までこれを運ぶのが手動の介入を必要とするでしょう。
2.4.1 Basic Behavior
2.4.1 基本的な振舞い
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 無条件の再考による無作為化間隔計算の正しい実現
Perkins, et al. Informational [Page 8] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[8ページ]のRFC3158RTP
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メガビット/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とx+500msの間隔の数はx+500msとx+1の間隔の数より少ないです、どんなxのためにも。
In particular, an implementation fails if the packets are sent with a constant interval.
一定の間隔と共にパケットを送るなら、特に、実現は失敗します。
2.4.2 Step join backoff
2.4.2 ステップはbackoffを接合します。
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パケットを発信させる際にbackoffの振舞いを示します。 以下の方法でアルゴリズムのこの局面をテストできます。
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パケットを実現に送ります、それぞれ異なったSSRCとSDES CNAMEと共に。 試験計器は、それぞれのRTCPパケットが同じ長さのものであることを確実にするはずです。 次に、器具は実現から次のRTCPパケットを受け取るまで待つはずです、そして、そのようなレセプションの時間は注意されます。
Perkins, et al. Informational [Page 9] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[9ページ]のRFC3158RTP
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パケットの長さと等しくなるでしょう。 したがって、実現からの1番目と2番目のRTCPパケットの間の最小の時間は以下の通りです。
T > 101 * S / ( B * Fr * (e-1.5) * 2 )
T>101*S/(*(e-1.5)*2B*フラン)
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パーセント)です、そして、フランは受信機(通常75パーセント)に割り当てられたRTCP帯域幅の部分です、そして、eは生まれながらの解説者です。 再考がなければ、この最小間隔Teははるかに小さいでしょう:
Te > MAX( [ S / ( B * Fr * (e-1.5) * 2 ) ] , [ 2.5 / (e-1.5) ] )
Te>最大[S/(B*フラン*(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.
Bが十分小さく選ばれるべきであるので、Tはおよそ60秒です。 これらのパラメタのための正当な選択は、950のB=bpsと、1024S=ビットです。 実現はパケットの間隔が少なくともT3回より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.
以下に注意してください。 すべてのテストで、下層UDP/IPヘッダーを含んでいて、Bに選ばれた値(RTCP帯域幅)は計算されます。 典型的なIPv4ベースの実現では、これらは1パケットあたり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秒に一度送らせることによって、これは達成されます。 この場合、1番目と2番目のRTCPパケットの間隔は以下よりそれほどノーであるべきです。
T > S / ( B * Fs * (e-1.5) * 2 )
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のこの値が間隔よりかなり小さいことに注意してください。
Perkins, et al. Informational [Page 10] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[10ページ]のRFC3158RTP
2.4.3 Steady State Behavior
2.4.3 定常状態の振舞い
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パケットから50SSRCを使用して、試験計器は50のRTPパケットを送ります。 試験計器は、それぞれのRTCPパケットが同じ長さのものであることを確実にするはずです。 次に、器具は実現から次のRTCPパケットを受け取るまで待つはずです、そして、そのようなレセプションの時間は注意されます。 RTCPパケットのレセプションと前のレセプションの違いは、計算されて、格納されます。 さらに、あらゆるRTCPパケットレセプションの後に、100RTCPと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帯域幅を分割するのを除いて。 以下の5%以内に平均したRTCP間隔があるなら、テストはうまくいくと考えられます。
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帯域幅であるところ。 Bが十分小さく選ばれるべきであるので、何十もの秒か以上の注文にはTの値があります。 適正価値は、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の代わりに50の代わりに10のRTPパケット、10RTCP SR、および90RTCP RRを送ります。 さらに、それ自身のRTCPパケットの皆のトランスミッションの間に少なくとも1つのRTPパケットを送るのを実現をします。
Perkins, et al. Informational [Page 11] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[11ページ]のRFC3158RTP
In this case, the average RTCP interval should be within 5% of:
この場合、以下の5%以内には平均したRTCP間隔があるべきです。
T = 11 * S / (B * Fs)
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です。
2.4.4 Reverse Reconsideration
2.4.4 再考を逆にしてください。
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パケット、初期のRTCPパケットの1つから異なったSSRCを含んでいますが、SSRCに合っているそれぞれを送ります。 また、各BYEは試験計器によって送られたRTCPパケットと同じサイズであるべきです。 これは、長さを広げるBYE理由を使用することによって、容易に達成されます。 そして、実現からの次のRTCPパケットの時間は注意されます。 これ(3番目のRTCPパケット)と前の間の遅れTは以下よりさらにノーであるべきです。
T < 3 * S / (B * Fr * (e-1.5) * 2)
T<3*S/(*(e-1.5)*2B*フラン)
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はRTCP帯域幅です、そして、フランは受信機に割り当てられたRTCP帯域幅の部分です、そして、eは生まれながらの解説者です。 Bが選ばれるべきであるので、何十秒もの注文にはTがあります。 正当な選択は、S=1024ビットとB=168bpsです。
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
2番目のテストに、実現は受信機としてセッションに参加します。最初のRTCPパケットを送って、試験計器が発信するとすぐに、100のRTCP RRパケット(それぞれの同じ長さS)が長さのS.Each RTCPパケットについても100のBYEパケットで続きました。
Perkins, et al. Informational [Page 12] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[12ページ]のRFC3158RTP
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.
異なった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パケットが1日T秒後に現れるなら、テストはうまくいくと考えられます、そして、以下の中にTがあります。
2.5 / (e-1.5) < T < 7.5 / (e-1.5)
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を受け取るときはいつも、不正確な実現は逆の再考を実行しようとするかもしれません。 実現がこれをするなら、BYEの流れを受ける直後それは結局、RTCPパケットを送るでしょうに。 およそ1Mb/s、扱うこのテストにおいて、大きい値になるようにBを選ばなければなりません。
2.4.5 BYE Reconsideration
2.4.5 さようなら再考
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手段でこの情報を試験計器に伝えます。 試験計器は、次に、異なったSSRCと共に100のBYEパケットをそれぞれ送って、以前に伝えられたRTCPパケットからSSRCを合わせて、それぞれ送ります。 それぞれのこれらのBYEパケットには、また、サイズS.ImmediatelyがBYEパケットに続くのがあって、試験計器は100のRTCP RRパケットを送ります、100のオリジナルのRTCPパケットと同じSSRC/CNAMEsを使用して。
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を決して送らないなら、うまくいくとテストを考えるか、またはそうするなら、3*T秒より遅さで受け取るのではなく、T秒ほど初期でない試験計器でBYEを受け取ります、Tは以下の通りであり実現がセッションを残した後に
T = 100 * S / ( 2 * (e-1.5) * B )
Tは100*S/と等しいです。(2*(e-1.5)*B)
Perkins, et al. Informational [Page 13] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[13ページ]のRFC3158RTP
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帯域幅です、そして、フランは受信機のためのRTCP帯域幅断片です。 SとBが選ばれるべきであるので、50秒の注文にはTがあります。 正当な選択は、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パケットのトランスミッションは、仲間から抜けるといったん決めると実現が非BYE RTCPパケットを無視していることを確かめることになっています。
2.4.6 Timing out members
2.4.6 タイミングアウトメンバー
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パケットを待っています。 いったん到着すると、試験計器はそれぞれ異なったSDES、SSRC、および注意がある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:
テストは1日後のRTCPパケットの間隔が以下よりそれほどノーであるならうまくいくと考えられます。
Ti > 101 * S / ( 2 * (e-1.5) * B * Fr)
Ti>101*S/(2*(e-1.5)*B*フラン)
and this minimum interval is sustained no later than Td seconds after the transmission of the 100 RR's, where Td is:
そして、この最小間隔はTdがそうであるRRの100ところのトランスミッションの秒後にTdが支えられます:
Td = 7 * 101 * S / ( B * Fr )
Td=7*101*S/(B*フラン)
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)
Perkins, et al. Informational [Page 14] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[14ページ]のRFC3158RTP
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を選ばなければならないので、数分の注文にはTiがあります。 推奨値は1024S=ビットです、そして、Bは1.9キロビット毎秒と等しいです。
2.4.7 Rapid SR's
2.4.7 急速なSRのもの
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であるので、キロビット毎秒におけるRTPセッション帯域幅を割りました。 72キロビット毎秒より大きい帯域幅に関しては、この間隔は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キロビット毎秒を使用するために構成されます。 減少している最小間隔を計算するためのお勧めのアルゴリズムが使用されているなら、結果は1回の2番目の間隔です。 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の両方にパケットを送り始めるべきです。 100回の間隔が集められるまで、RTCPパケットの間隔は、測定されて、格納されます。
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秒あたり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 |
+----------------+ +----------------+
+-----------------+ +--------+ RTP翻訳者+-----+ | +-----------------+ | | | +-------+--------+ +-------+--------+ | 最初に、RTP| | 第2RTP| | 実現| | 実現| +----------------+ +----------------+
Figure 3: Testing architecture for translators
図3: 翻訳者がないかどうか構造をテストします。
Perkins, et al. Informational [Page 15] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[15ページ]のRFC3158RTP
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 タイムスタンプは、例えば、コード化、packetisation間隔またはframerateが変えられるかどうかを変えるかもしれません。
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 また、翻訳者がzデータの符号化を変えるなら、それは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
o また、翻訳者が複数のデータ・パケットを1つに結合するなら受信機から還流するRRパケットのパケット損失と拡張最も高い一連番号分野を変えるべきである、(翻訳者がレポートを剥取るのは、法的です。
Perkins, et al. Informational [Page 16] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[16ページ]のRFC3158RTP
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 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 翻訳者はパケットをBYEに変わりがない状態で送るべきです。
o the translator should forward APP packets unchanged
o 翻訳者はパケットをAPPに変わりがない状態で送るべきです。
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パケットを処理するために確かめられるべきです(また、翻訳者がそれ自身のRTCP情報を送るなら複数のSSRCsが各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 |
+----------------+ +----------------+
+----------------+ | 第2RTP| | 実現| +-------+--------+ | | +-----------+ +-------+ RTPミキサー+-----+ | +-----------+ | | | +-------+--------+ +-------+--------+ | 最初に、RTP| | 第3RTP| | 実現| | 実現| +----------------+ +----------------+
Figure 4: Testing architecture for mixers
図4: ミキサーがないかどうか構造をテストします。
Perkins, et al. Informational [Page 17] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[17ページ]のRFC3158RTP
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パケットは1日に対応する2CSRCsと2番目のRTP実現を含んでいます。
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パケットを発生させるのは曇ります。 ミキサーは、1番目と2番目の実現の向きにRRパケットを発生させて、3番目の実現の向きに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衝突の解決への支給があります。 2人の異なったセッション関係者が同じSSRCを選ぶと、これらの衝突は起こります。 この場合、BYEを送って、セッションを残して、両方の関係者は異なった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
テストは簡単です。 受信機としてマルチキャストグループに加わるのをRTP実現をします。試験計器は最初のRTCPパケットを待っています。 いったん到着すると、試験計器はRTCPパケットからCNAMEとSSRCに注意します。 そして、試験計器はRTCP受信機レポートを作ります。 この受信機レポートはRTP実現のものに合っているSSRCにもかかわらず、異なったCNAMEがあるSDES塊を含んでいます。 ここに、実現はそうするべきです。
Perkins, et al. Informational [Page 18] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[18ページ]のRFC3158RTP
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.
BYE RTCPパケット(古いSSRCとCNAMEがあるSDES塊を含んでいる)を送ってください、そして、次に、再び加わってください、SDES塊を含んでいますが、新しい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.
RTP実現が試験計器から衝突しているRRを受けた後1分以内に上で説明されるようにRTCP BYEとRTCP RRを送るなら、テストはうまくいくと考えられます。
6 SSRC Randomization
6SSRC無作為化
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仕様に従って、32ビットのスペースに関してSSRCのものによって無作為に一様に選ばれるべきです。 この無作為化はいくつかの理由で有益です:
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に注意します。 2500SSRCの収集をもたらして、テストは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**32 / 25))に置かれます。 考えは、32ビットのスペースを25の領域に細かく分けて、各領域のSSRCの数を計算することです。 理想的に、40SSRCが各容器にあるはずです。 もちろん、各容器の実数は期待が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は**もう片方の31.5より高く2歳未満であるべきです。 この場合、変動係数が0.2であるので、8以上SSRC2**31、および26未満があれば、テストはうまくいっています。
Perkins, et al. Informational [Page 19] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[19ページ]のRFC3158RTP
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北にアーリントン、フェアファクスドライブSuite200ヴァージニア 22203を設けます。
EMail: csp@isi.edu
メール: csp@isi.edu
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave. First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグdynamicsoft72Eagle Rock Ave。 ニュージャージー 最初に、床の東ハノーバー王家、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/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027-7003
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Perkins, et al. Informational [Page 20] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[20ページ]のRFC3158RTP
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.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションへのトランスポート・プロトコル」、処理中の作業(RFC1889に、アップデートする)、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] 「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」というSchulzrinne H.とS.Casnerは進行中(RFC1890に、アップデートします)(2001年3月)で働いています。
[3] Rosenberg, J. and Schulzrinne, H. "Sampling of the Group
Membership in RTP", RFC 2762, February 2000.
[3] ローゼンバーグとJ.とSchulzrinne、H. 「RTPのグループ会員資格の標本抽出」、RFC2762、2000年2月。
Perkins, et al. Informational [Page 21] RFC 3158 RTP Testing Strategies August 2001
パーキンス、他 戦略2001年8月にテストする情報[21ページ]のRFC3158RTP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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機能のための基金は現在、インターネット協会によって提供されます。
Perkins, et al. Informational [Page 22]
パーキンス、他 情報[22ページ]
一覧
スポンサーリンク
