[要約] RFC 7160は、RTPセッションで複数のクロックレートをサポートするための仕様です。目的は、異なるクロックレートを持つデバイス間での正確なタイミング同期を可能にすることです。
Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 7160 Impedance Mismatch
Updates: 3550 G. Zorn, Ed.
Category: Standards Track Network Zen
ISSN: 2070-1721 April 2014
Support for Multiple Clock Rates in an RTP Session
RTPセッションでの複数のクロックレートのサポート
Abstract
概要
This document clarifies the RTP specification regarding the use of different clock rates in an RTP session. It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document. It updates RFC 3550.
このドキュメントでは、RTPセッションでの異なるクロックレートの使用に関するRTP仕様を明確にしています。また、複数のクロックレートを使用するレガシーRTP実装が、このドキュメントで説明されているアルゴリズムを使用するRTP実装と相互運用できる方法に関するガイダンスも提供します。 RFC 3550を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7160.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7160で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Legacy RTP . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Different SSRC . . . . . . . . . . . . . . . . . . . . . 4
3.2. Same SSRC . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Monotonic Timestamps . . . . . . . . . . . . . . . . 5
3.2.2. Non-monotonic Timestamps . . . . . . . . . . . . . . 6
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. RTP Sender (with RTCP) . . . . . . . . . . . . . . . . . 6
4.2. RTP Sender (without RTCP) . . . . . . . . . . . . . . . . 6
4.3. RTP Receiver . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Example Values . . . . . . . . . . . . . . . . . . . 10
Appendix B. Using a Fixed Clock Rate . . . . . . . . . . . . . . 12
Appendix C. Behavior of Legacy Implementations . . . . . . . . . 12
C.1. libccrtp 2.0.2 . . . . . . . . . . . . . . . . . . . . . 12
C.2. libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . . 12
C.3. libpjmedia 1.0 . . . . . . . . . . . . . . . . . . . . . 13
C.4. Android RTP Stack 4.0.3 . . . . . . . . . . . . . . . . . 13
The clock rate is a parameter of the payload format as identified in RTP and RTCP (RTP Control Protocol) by the payload type value. It is often defined as being the same as the sampling rate but that is not always the case (see, for example, the G722 and MPA audio codecs [RFC3551]).
クロックレートは、ペイロードタイプ値によってRTPおよびRTCP（RTP制御プロトコル）で識別されるペイロード形式のパラメータです。多くの場合、サンプリングレートと同じであると定義されていますが、常にそうであるとは限りません（たとえば、G722およびMPAオーディオコーデック[RFC3551]を参照）。
An RTP sender can switch between different payloads during the lifetime of an RTP session and because clock rates are defined by payload format, it is possible that the clock rate will also vary during an RTP session. Schulzrinne, et al. [RFC3550] lists using multiple clock rates as one of the reasons to not use different payloads on the same Synchronization Source (SSRC). Unfortunately, this advice has not always been followed and some RTP implementations change the payload in the same SSRC, even if the different payloads use different clock rates.
RTP送信者は、RTPセッションの存続期間中に異なるペイロード間を切り替えることができます。クロックレートはペイロード形式によって定義されるため、RTPセッション中にクロックレートも変化する可能性があります。シュルツリンネ他[RFC3550]は、同じ同期ソース（SSRC）で異なるペイロードを使用しない理由の1つとして、複数のクロックレートの使用をリストしています。残念ながら、このアドバイスは常に守られているわけではなく、RTP実装によっては、異なるペイロードが異なるクロックレートを使用している場合でも、同じSSRCのペイロードが変更されます。
This creates three problems:
これにより、3つの問題が発生します。
o The method used to calculate the RTP timestamp field in an RTP packet is underspecified.
o RTPパケットのRTPタイムスタンプフィールドを計算するために使用される方法は、十分に規定されていません。
o When the same SSRC is used for different clock rates, it is difficult to know what clock rate was used for the RTP timestamp field in an RTCP Sender Report (SR) packet.
o 同じSSRCが異なるクロックレートに使用されている場合、RTCP Sender Report（SR）パケットのRTPタイムスタンプフィールドにどのクロックレートが使用されたかを知るのは困難です。
o When the same SSRC is used for different clock rates, it is difficult to know what clock rate was used for the interarrival jitter field in an RTCP Receiver Report (RR) packet.
o 同じSSRCが異なるクロックレートに使用されている場合、RTCP受信レポート（RR）パケットの到着間ジッタフィールドにどのクロックレートが使用されたかを知るのは困難です。
Table 1 contains a non-exhaustive list of fields in RTCP packets that uses a clock rate as a unit:
表1に、クロックレートを単位として使用するRTCPパケットのフィールドの完全なリストを示します。
+---------------------+------------------+------------+
| Field name | RTCP packet type | Reference |
+---------------------+------------------+------------+
| RTP timestamp | SR | [RFC3550] |
| | | |
| Interarrival jitter | RR | [RFC3550] |
| | | |
| min_jitter | XR Summary Block | [RFC3611] |
| | | |
| max_jitter | XR Summary Block | [RFC3611] |
| | | |
| mean_jitter | XR Summary Block | [RFC3611] |
| | | |
| dev_jitter | XR Summary Block | [RFC3611] |
| | | |
| Interarrival jitter | IJ | [RFC5450] |
| | | |
| RTP timestamp | SMPTETC | [RFC5484] |
| | | |
| Jitter | RSI Jitter Block | [RFC5760] |
| | | |
| Median jitter | RSI Stats Block | [RFC5760] |
+---------------------+------------------+------------+
Table 1
表1
Section 3 and its subsections try to list all of the algorithms known to be used in existing RTP implementations at the time of writing. These sections are not normative.
セクション3とそのサブセクションでは、執筆時点で既存のRTP実装で使用されることが知られているすべてのアルゴリズムをリストしようとしています。これらのセクションは規範的ではありません。
Section 4 and its subsections recommend a unique algorithm that modifies RFC 3550. These sections are normative.
セクション4とそのサブセクションでは、RFC 3550を変更する独自のアルゴリズムを推奨しています。これらのセクションは規範的です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
In addition, this document uses the following terms:
さらに、このドキュメントでは次の用語を使用しています。
Clock rate The multiplier used to convert from a wallclock value in seconds to an equivalent RTP timestamp value (without the fixed random offset). Note that RFC 3550 uses various terms like "clock frequency", "media clock rate", "timestamp unit", "timestamp frequency", and "RTP timestamp clock rate" as synonymous to clock rate.
クロックレート秒単位のウォールクロック値から同等のRTPタイムスタンプ値（固定ランダムオフセットなし）に変換するために使用される乗数。 RFC 3550は、「クロック周波数」、「メディアクロックレート」、「タイムスタンプユニット」、「タイムスタンプ周波数」、「RTPタイムスタンプクロックレート」などのさまざまな用語を、クロックレートの同義語として使用していることに注意してください。
RTP Sender A logical network element that sends RTP packets, sends RTCP SR packets, and receives RTCP reception report blocks.
RTP送信者RTPパケットを送信し、RTCP SRパケットを送信し、RTCP受信レポートブロックを受信する論理ネットワーク要素。
RTP Receiver A logical network element that receives RTP packets, receives RTCP SR packets, and sends RTCP reception report blocks.
RTPレシーバーRTPパケットを受信し、RTCP SRパケットを受信し、RTCP受信レポートブロックを送信する論理ネットワーク要素。
The following sections describe the various ways in which legacy RTP implementations behave when multiple clock rates are used. "Legacy RTP" refers to RFC 3550 without the modifications introduced by this document.
次のセクションでは、複数のクロックレートが使用されている場合に、レガシーRTP実装が動作するさまざまな方法について説明します。 「レガシーRTP」は、このドキュメントで紹介されている変更なしのRFC 3550を指します。
One way of managing multiple clock rates is to use a different SSRC for each different clock rate, as in this case there is no ambiguity on the clock rate used by fields in the RTCP packets. This method also seems to be the original intent of RTP as can be deduced from points 2 and 3 of Section 5.2 of RFC 3550.
複数のクロックレートを管理する1つの方法は、異なるクロックレートごとに異なるSSRCを使用することです。この場合、RTCPパケットのフィールドで使用されるクロックレートに曖昧さはありません。 RFC 3550のセクション5.2のポイント2と3から推定できるように、この方法もRTPの本来の目的であると思われます。
On the other hand, changing the SSRC can be a problem for some implementations designed to work only with unicast IP addresses, where having multiple SSRCs is considered a corner case. Lip synchronization can also be a problem in the interval between the beginning of the new stream and the first RTCP SR packet.
一方、SSRCの変更は、ユニキャストIPアドレスでのみ機能するように設計された一部の実装では問題になる可能性があり、複数のSSRCを持つことは重要なケースと見なされます。リップ同期は、新しいストリームの開始と最初のRTCP SRパケットの間の間隔でも問題になることがあります。
The simplest way to manage multiple clock rates is to use the same SSRC for all of the payload types regardless of the clock rates.
複数のクロックレートを管理する最も簡単な方法は、クロックレートに関係なく、すべてのペイロードタイプに同じSSRCを使用することです。
Unfortunately, there is no clear definition on how the RTP timestamp should be calculated in this case. The following subsections present the algorithms currently in use.
残念ながら、この場合のRTPタイムスタンプの計算方法は明確に定義されていません。以下のサブセクションでは、現在使用されているアルゴリズムを示します。
This method of calculating the RTP timestamp ensures that the value increases monotonically. The formula used by this method is as follows:
RTPタイムスタンプを計算するこの方法では、値が単調に増加することが保証されます。このメソッドで使用される式は次のとおりです。
timestamp = previous_timestamp + (current_capture_time - previous_capture_time) * current_clock_rate
タイムスタンプ= previous_timestamp +（current_capture_time-previous_capture_time）* current_clock_rate
The problem with this method is that the jitter calculation on the receiving side gives an invalid result during the transition between two clock rates, as shown in Table 2 (Appendix A). The capture and arrival time are measured in seconds, starting at the beginning of the capture of the first packet; clock rate is measured in Hz; the RTP timestamp does not include the random offset; and the transit, jitter, and average jitter use the clock rate as a unit.
この方法の問題は、表2（付録A）に示すように、2つのクロックレート間の遷移中に受信側のジッター計算が無効な結果をもたらすことです。キャプチャと到着時間は秒単位で測定され、最初のパケットのキャプチャの開始から始まります。クロックレートはHzで測定されます。 RTPタイムスタンプにはランダムオフセットは含まれません。通過、ジッター、および平均ジッターは、クロックレートを1つの単位として使用します。
Calculating the correct transit time on the receiving side can be done by using the following formulas:
受信側での正しい通過時間の計算は、次の式を使用して行うことができます。
1. current_capture_time = (current_timestamp - previous_timestamp) / current_clock_rate + previous_capture_time
1. current_capture_time =（current_timestamp-previous_timestamp）/ current_clock_rate + previous_capture_time
2. transit = current_clock_rate * (arrival_time - current_capture_time)
2. トランジット= current_clock_rate *（arrival_time-current_capture_time）
3. previous_capture_time = current_capture_time
3. previous_capture_time = current_capture_time
The main problem with this method, in addition to the fact that the jitter calculation described in RFC 3550 cannot be used, is that it is dependent on the previous RTP packets, which can be reordered or lost in the network.
この方法の主な問題は、RFC 3550で説明されているジッター計算が使用できないという事実に加えて、以前のRTPパケットに依存しているため、ネットワークで並べ替えたり失われたりする可能性があることです。
An alternate way of generating the RTP timestamps is to use the following formula:
RTPタイムスタンプを生成する別の方法は、次の式を使用することです。
timestamp = capture_time * clock_rate
タイムスタンプ= capture_time * clock_rate
With this formula, the jitter calculation is correct but the RTP timestamp values are no longer increasing monotonically as shown in Table 3 (Appendix A). RFC 3550 states that "[t]he sampling instant MUST be derived from a clock that increments monotonically . . .", but it does not say that the RTP timestamp must increment monotonically.
この式を使用すると、ジッタの計算は正しくなりますが、RTPタイムスタンプ値は表3（付録A）に示すように単調に増加しなくなります。 RFC 3550は、「サンプリングインスタントは単調に増加するクロックから派生しなければならない...」と述べていますが、RTPタイムスタンプが単調に増加する必要があるとは述べていません。
The advantage with this method is that it works with the jitter calculation described in RFC 3550, as long as the correct clock rates are used. It seems that this is what most implementations are using (based on a survey done at SIPit26 and on a survey of open source implementations, see Appendix C).
この方法の利点は、正しいクロックレートが使用されている限り、RFC 3550で説明されているジッター計算で機能することです。これはほとんどの実装が使用しているようです（SIPit26で行われた調査とオープンソース実装の調査に基づく、付録Cを参照）。
The following subsections describe behavioral recommendations for RTP senders (with and without RTCP) and RTP receivers.
以下のサブセクションでは、RTP送信者（RTCPありおよびRTCPなし）およびRTP受信者の動作に関する推奨事項について説明します。
An RTP Sender with RTCP turned on MUST use a different SSRC for each different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST be used if the clock rate switches back to a value already seen in the RTP stream.
RTCPがオンになっているRTP送信者は、異なるクロックレートごとに異なるSSRCを使用する必要があります。 RTP BYEを送信する必要があり、クロックレートがRTPストリームですでに確認されている値に戻る場合は、新しいSSRCを使用する必要があります。
To accelerate lip synchronization, the next compound RTCP packet sent by the RTP sender MUST contain multiple SR packets, the first one containing the mapping for the current clock rate and the subsequent SR packet(s) containing the mapping for the other clock rates seen during the last period.
リップ同期を加速するには、RTP送信者が送信する次の複合RTCPパケットに複数のSRパケットを含める必要があります。最初のパケットには現在のクロックレートのマッピングが含まれ、後続のSRパケットには、他のクロックレートのマッピングが含まれます。最後の期間。
The RTP extension defined by Perkins & Schierl [RFC6051] MAY be used to accelerate the synchronization.
Perkins＆Schierl [RFC6051]によって定義されたRTP拡張は、同期を加速するために使用される場合があります。
An RTP Sender with RTCP turned off (i.e., having set the RTP Sender and RTP Receiver bandwidth modifiers [RFC3556] to 0) SHOULD use a different SSRC for each different clock rate but MAY use different clock rates on the same SSRC as long as the RTP timestamp is calculated as explained below: Each time the clock rate changes, the start_offset and capture_start values are calculated with the following formulas:
RTCPがオフになっている（つまり、RTP送信者とRTP受信者の帯域幅修飾子[RFC3556]を0に設定している）RTP送信者は、異なるクロックレートごとに異なるSSRCを使用する必要があります（ただし、同じSSRCで異なるクロックレートを使用する場合があります）。 RTPタイムスタンプは、以下で説明するように計算されます。クロックレートが変更されるたびに、start_offsetおよびcapture_startの値は次の式で計算されます。
start_offset += (capture_time - capture_start) * previous_clock_rate
capture_start = capture_time
For the first RTP packet, the values are initialized with the following values:
最初のRTPパケットの場合、値は次の値で初期化されます。
start_offset = random_initial_offset capture_start = capture_time
start_offset = random_initial_offset capture_start = capture_time
After eventually updating these values, the RTP timestamp is calculated with the following formula:
これらの値を最終的に更新した後、RTPタイムスタンプは次の式で計算されます。
timestamp = (capture_time - capture_start) * clock_rate
+ start_offset
Note that in all the formulas, capture_start is the first instant that the new timestamp rate is used. The output of the above method is exemplified in Table 4 (Appendix A).
すべての式で、capture_startは新しいタイムスタンプレートが使用される最初の瞬間であることに注意してください。上記の方法の出力は、表4（付録A）に例示されています。
An RTP Receiver MUST calculate the jitter using the following formula:
RTPレシーバーは、次の式を使用してジッターを計算する必要があります。
D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j)
- (arrival_time_i * clock_rate_i - timestamp_i)
An RTP Receiver MUST be able to handle a compound RTCP packet with multiple SR packets.
RTPレシーバーは、複数のSRパケットを持つ複合RTCPパケットを処理できなければなりません（MUST）。
When the algorithm described in Section 4.1 is used, the security considerations described in RFC 3550 apply.
セクション4.1で説明されているアルゴリズムが使用される場合、RFC 3550で説明されているセキュリティの考慮事項が適用されます。
The algorithm described in Section 4.2 is new and so its security properties were not considered in RFC 3550. Although the RTP timestamp is initialized with a random value like before, the timestamp value depends on the current and previous clock rates; this may or may not introduce a security vulnerability in the protocol.
セクション4.2で説明されているアルゴリズムは新しいため、そのセキュリティプロパティはRFC 3550では考慮されていません。RTPタイムスタンプは以前のようにランダムな値で初期化されますが、タイムスタンプ値は現在および以前のクロックレートに依存します。これにより、プロトコルにセキュリティの脆弱性が導入される場合と導入されない場合があります。
Thanks to Colin Perkins, Ali C. Begen, Harald Alvestrand, Qin Wu, Jonathan Lennox, Barry Leiba, David Harrington, Stephen Farrell, Spencer Dawkins, Wassim Haddad, and Magnus Westerlund for comments, suggestions, and questions that helped to improve this document.
このドキュメントの改善に役立つコメント、提案、および質問をしてくれたColin Perkins、Ali C. Begen、Harald Alvestrand、Qin Wu、Jonathan Lennox、Barry Leiba、David Harrington、Stephen Farrell、Spencer Dawkins、Wassim Haddad、およびMagnus Westerlundに感謝します。 。
Thanks to Bo Burman, who provided the values in Table 4 of Appendix A.
付録Aの表4の値を提供してくれたBo Burmanに感謝します。
Thanks to Robert Sparks and the attendees of SIPit 26 for the survey on multiple clock rates interoperability.
複数のクロックレートの相互運用性に関する調査を行ったRobert SparksとSIPit 26の参加者に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[AVT-VAR-RATE] Wenger, S. and C. Perkins, "RTP Timestamp Frequency for Variable Rate Audio Codecs", Work in Progress, October 2004.
[AVT-VAR-RATE] Wenger、S。およびC. Perkins、「可変レートオーディオコーデックのRTPタイムスタンプ周波数」、作業中、2004年10月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556] Casner、S。、「RTP制御プロトコル（RTCP）帯域幅用のセッション記述プロトコル（SDP）帯域幅修飾子」、RFC 3556、2003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]フリードマン、T。、カセレス、R。、およびA.クラーク、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in RTP Streams", RFC 5450, March 2009.
[RFC5450] Singer、D。およびH. Desineni、「RTPストリームの伝送時間オフセット」、RFC 5450、2009年3月。
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 5484, March 2009.
[RFC5484] Singer、D。、「Associating Time-Codes with RTP Streams」、RFC 5484、2009年3月。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5760] Ott、J.、Chesterfield、J。、およびE. Schooler、「ユニキャストフィードバック付きの単一ソースマルチキャストセッション用のRTP制御プロトコル（RTCP）拡張」、RFC 5760、2010年2月。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
[RFC6051] Perkins、C。およびT. Schierl、「RTPフローの迅速な同期」、RFC 6051、2010年11月。
The following tables illustrate the timestamp and jitter values produced when the various methods discussed in the text are used.
次の表は、本文で説明されているさまざまな方法を使用したときに生成されるタイムスタンプとジッターの値を示しています。
The values shown are purely exemplary, illustrative, and non-normative.
示されている値は、純粋に例示、例示、および非規範的です。
+-------+-------+-----------+---------+---------+--------+----------+
| Capt. | Clock | RTP | Arrival | Transit | Jitter | Average |
| time | rate | timestamp | time | | | jitter |
+-------+-------+-----------+---------+---------+--------+----------+
| 0 | 8000 | 0 | 0.1 | 800 | | |
| | | | | | | |
| 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 |
| | | | | | | |
| 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 |
| | | | | | | |
| 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 |
| | | | | | | |
| 0.08 | 16000 | 800 | 0.18 | 2080 | 480 | 30 |
| | | | | | | |
| 0.1 | 16000 | 1120 | 0.2 | 2080 | 0 | 28 |
| | | | | | | |
| 0.12 | 16000 | 1440 | 0.22 | 2080 | 0 | 26 |
| | | | | | | |
| 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 70 |
| | | | | | | |
| 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 65 |
+-------+-------+-----------+---------+---------+--------+----------+
Table 2: Monotonic Timestamps
表2：単調なタイムスタンプ
+-------+-------+-----------+---------+---------+--------+----------+
| Capt. | Clock | RTP | Arrival | Transit | Jitter | Average |
| time | rate | timestamp | time | | | jitter |
+-------+-------+-----------+---------+---------+--------+----------+
| 0 | 8000 | 0 | 0.1 | 800 | | |
| | | | | | | |
| 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 |
| | | | | | | |
| 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 |
| | | | | | | |
| 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 |
| | | | | | | |
| 0.08 | 16000 | 1280 | 0.18 | 1600 | 0 | 0 |
| | | | | | | |
| 0.1 | 16000 | 1600 | 0.2 | 1600 | 0 | 0 |
| | | | | | | |
| 0.12 | 16000 | 1920 | 0.22 | 1600 | 0 | 0 |
| | | | | | | |
| 0.14 | 8000 | 1120 | 0.24 | 800 | 0 | 0 |
| | | | | | | |
| 0.16 | 8000 | 1280 | 0.26 | 800 | 0 | 0 |
+-------+-------+-----------+---------+---------+--------+----------+
Table 3: Non-monotonic Timestamps
表3：非単調なタイムスタンプ
+-------+-------+-----------+---------+---------+--------+----------+
| Capt. | Clock | RTP | Arrival | Transit | Jitter | Average |
| time | rate | timestamp | time | | | jitter |
+-------+-------+-----------+---------+---------+--------+----------+
| 0 | 8000 | 0 | 0.1 | 800 | | |
| | | | | | | |
| 0.02 | 8000 | 160 | 0.12 | 800 | 0 | 0 |
| | | | | | | |
| 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 |
| | | | | | | |
| 0.06 | 8000 | 480 | 0.16 | 800 | 0 | 0 |
| | | | | | | |
| 0.08 | 16000 | 640 | 0.18 | 1600 | 0 | 0 |
| | | | | | | |
| 0.1 | 16000 | 960 | 0.2 | 1600 | 0 | 0 |
| | | | | | | |
| 0.12 | 16000 | 1280 | 0.22 | 1600 | 0 | 0 |
| | | | | | | |
| 0.14 | 8000 | 1600 | 0.24 | 320 | 0 | 0 |
| | | | | | | |
| 0.16 | 8000 | 1760 | 0.26 | 320 | 0 | 0 |
+-------+-------+-----------+---------+---------+--------+----------+
Table 4: Recommended Method for RTP Sender (without RTCP)
表4：RTP送信者に推奨される方法（RTCPなし）
An alternate way of fixing the issue with using multiple clock rates was proposed by Wenger and Perkins [AVT-VAR-RATE]. This document proposed to define a unified clock rate, but the proposal was rejected at IETF 61.
複数のクロックレートを使用して問題を修正する別の方法が、WengerとPerkinsによって提案されました[AVT-VAR-RATE]。このドキュメントは統一されたクロックレートを定義することを提案しましたが、提案はIETF 61で拒否されました。
This library uses the formula described in Section 3.2.2.
このライブラリは、セクション3.2.2で説明されている式を使用します。
Note that this library uses gettimeofday(2) which is not guaranteed to increment monotonically (e.g., when the clock is adjusted by NTP).
このライブラリは、単調にインクリメントすることが保証されていないgettimeofday（2）を使用することに注意してください（たとえば、クロックがNTPによって調整される場合）。
This library (which uses the oRTP library) uses the formula described in Section 3.2.2.
このライブラリ（oRTPライブラリを使用）は、セクション3.2.2で説明されている式を使用します。
Note that in some environments this library uses gettimeofday(2), which is not guaranteed to increment monotonically.
一部の環境では、このライブラリはgettimeofday（2）を使用することに注意してください。これは単調に増加することが保証されていません。
This library uses the formula described in Section 3.2.2.
このライブラリは、セクション3.2.2で説明されている式を使用します。
This library changes the SSRC each time the format changes, as described in Section 3.1.
このライブラリは、セクション3.1で説明されているように、フォーマットが変更されるたびにSSRCを変更します。
Authors' Addresses
著者のアドレス
Marc Petit-Huguenin Impedance Mismatch
マルクプティフーゲニンインピーダンスミスマッチ
EMail: petithug@acm.org
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
Geron Joron（編集者）Network Zen 228/356 Thanong Sunfight Bang Na、Bangkok 10260 Thailand
Phone: +66 (0) 8-1000-4155
EMail: glenzorn@gmail.com