[要約] RFC 5450は、RTPストリーム内の送信時間オフセットに関する規格であり、送信者と受信者間の時刻同期を改善することを目的としています。
Network Working Group D. Singer
Request for Comments: 5450 Apple Computer Inc.
Category: Standards Track H. Desineni
Qualcomm
March 2009
Transmission Time Offsets in RTP Streams
RTPストリームの送信時間オフセット
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This document describes a method to inform Real-time Transport Protocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times.
このドキュメントでは、RTPパケットが「公称」送信時間以外の時間に送信された場合に、リアルタイムトランスポートプロトコル（RTP）クライアントに通知する方法について説明します。また、報告された送信時間を考慮して、クライアントからの攻撃間ジッターレポートを改善するメカニズムも提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3
3. Transmission Offset . . . . . . . . . . . . . . . . . . . . . . 3
4. Extended Jitter Reports . . . . . . . . . . . . . . . . . . . . 5
5. Signaling (Setup) Information . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
In the Real-time Transport Protocol (RTP) specification [RFC3550], network jitter calculations are based on the presumption that packets are transmitted essentially in accordance with their RTP timestamps. This must be true, of course, on average over longer time intervals, as the client is playing the packets out according to those timestamps. However, for individual packets, this may not be true under some circumstances, such as:
リアルタイムトランスポートプロトコル（RTP）仕様[RFC3550]では、ネットワークジッターの計算は、RTPタイムスタンプに基づいてパケットが本質的に送信されるという推定に基づいています。もちろん、これは、クライアントがこれらのタイムスタンプに従ってパケットを再生しているため、平均して平均して長い時間間隔で真でなければなりません。ただし、個々のパケットの場合、次のような状況によっては当てはまらない場合があります。
o When the data rate of the stream is bursty, such as with video where I-frames may be significantly larger than P or B frames, traffic smoothing may need to be applied to maintain an appropriate data rate.
o IフレームがPまたはBフレームよりも大幅に大きいビデオなど、ストリームのデータレートが爆発的である場合、適切なデータレートを維持するためにトラフィックスムージングを適用する必要がある場合があります。
o In video that has forward-decode dependencies, frames may need to be transmitted in decoding order (the sequence number order) but with, of course, presentation timestamps. Under these circumstances, the transmission time of a frame sent early in sequence does not correspond to its RTP timestamp.
o フォワードデコードの依存関係を持つビデオでは、フレームをデコード順（シーケンス番号の順序）で送信する必要がありますが、もちろんプレゼンテーションタイムスタンプを使用する必要があります。これらの状況では、順番に早い段階で送信されるフレームの送信時間は、そのRTPタイムスタンプに対応していません。
o When retransmissions are sent, the retransmitted packet clearly has a different actual transmission time from the original, even though they share the same timestamp.
o 再送信が送信されると、再送信されたパケットは、同じタイムスタンプを共有していても、オリジナルとは明確に異なる実際の伝送時間を持っています。
Under some circumstances, it can help the receiver, or intermediate network elements, to know the actual transmission time of the packet. This RTP header extension element allows the communication of this information.
状況によっては、受信機または中間ネットワーク要素がパケットの実際の送信時間を知るのに役立ちます。このRTPヘッダー拡張要素により、この情報の通信が可能になります。
The RTP specification does not define a transmission timestamp; nor does this specification. This specification merely provides information on the relationship between the relative transmission times and relative RTP timestamps.
RTP仕様は、送信タイムスタンプを定義しません。また、この仕様もありません。この仕様は、相対的な伝達時間と相対的なRTPタイムスタンプの関係に関する情報を提供するだけです。
This specification allows the transmitter to indicate to the receiver any known variation between the spacing of transmission times and the spacing of RTP timestamps; any unreported variation introduced at or after the point of measurement of the transmission time will be treated as network jitter by the receiver. The definition of the point where the transmission time is measured or defined is left to the transmitter, though it should, of course, be consistent from packet to packet.
この仕様により、送信機は、送信時間の間隔とRTPタイムスタンプの間隔との間の既知の変動を受信者に示すことができます。送信時間の測定点またはその後に導入された未報告のバリエーションは、受信者によってネットワークジッターとして扱われます。伝送時間が測定または定義されているポイントの定義は、送信機に任されていますが、もちろんパケットからパケットまで一貫しているはずです。
This information can also be of use to report the inter-arrival jitter caused by the network, excluding that introduced by the source. A new RTP Control Protocol (RTCP) packet is defined to enable this reporting.
この情報は、ソースによって導入されたものを除く、ネットワークによって引き起こされる攻撃間ジッターを報告するためにも使用できます。このレポートを有効にするために、新しいRTPコントロールプロトコル（RTCP）パケットが定義されています。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Classically, a pair of RTP packets with timestamps S2 and S1 are transmitted with a time interval between them of (S2 - S1). This specification permits sending an offset value O in each packet, O1 and O2. One characteristic of these offsets is that the original transmission interval can be deduced to be (S2 + O2) - (S1 + O1).
古典的には、タイムスタンプS2とS1を備えたRTPパケットのペアは、（S2 -S1）の間に時間間隔で送信されます。この仕様により、各パケット、O1およびO2にオフセット値oを送信できます。これらのオフセットの特徴の1つは、元の伝送間隔を（S2 O2） - （S1 O1）と推定できることです。
More precisely, the offset is defined as follows (with the function RtoN converting from RTP to Network Time Protocol (NTP) times, and NtoR doing the reverse):
より正確には、オフセットは次のように定義されます（関数RTONがRTPからネットワークタイムプロトコル（NTP）時間に変換され、NTORが逆を実行します）：
o Take an RTP stream that has a recent RTCP sender report relating RTP timestamp S0 to NTP timestamp N0;
o RTPタイムスタンプS0をNTPタイムスタンプN0に関連付ける最近のRTCP送信者レポートがあるRTPストリームを取ります。
o Consider a packet sent after that with RTP timestamp S1. Nominally, this is sent at N1 = (N0 + RtoN(S1 - S0));
o その後、RTPタイムスタンプS1を使用して送信されたパケットを検討してください。名目上、これはn1 =（n0 rton（s1 -s0））で送信されます。
o If it was actually sent at a different time, Na, then the offset value O1 is O1 = NtoR(Na - N1).
o 実際に別の時間に送信された場合、NA、オフセット値o1はo1 = ntor（na -n1）です。
The transmission time is signaled to the receiver in-band using the general mechanism for RTP header extensions [RFC5285]. The payload of this extension (the transmitted value) is a 24-bit signed integer. When added to the RTP timestamp of the packet, it represents the "effective" RTP transmission time of the packet, on the RTP timescale. The reported transmission time T1 of a packet with timestamp S1 and an offset of O1, from the above equations, is T1 = S1+O1 (though of course the transmission time values only have meaning when two or more are compared).
RTPヘッダー拡張の一般的なメカニズム[RFC5285]を使用して、送信時間はインバンドに受信機に通知されます。この拡張機能（送信値）のペイロードは、24ビットの署名整数です。パケットのRTPタイムスタンプに追加すると、RTPタイムスケール上のパケットの「効果的な」RTP送信時間を表します。上記の方程式からのタイムスタンプS1とO1のオフセットを備えたパケットの報告された透過時間T1はT1 = S1 O1です（もちろん、伝送時間値は2つ以上を比較した場合にのみ意味があります）。
The form of the transmission offset extension block is as follows:
トランスミッションオフセット拡張ブロックの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len=2 | transmission offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length field takes the value 2 to indicate that 3 bytes follow.
長さのフィールドは、3バイトが続くことを示すために値2を取ります。
The sign of the offset value depends greatly on the choice of the initial mapping of RTP to NTP times. In general, without scanning a stream entirely it is not possible to ensure that this mapping would keep all the offsets positive; therefore, this specification allows negative values.
オフセット値の符号は、RTPからNTP時間への初期マッピングの選択に大きく依存します。一般に、ストリームを完全にスキャンすることなく、このマッピングがすべてのオフセットを肯定的に保つことを保証することはできません。したがって、この仕様は負の値を可能にします。
Imagine a stream with the following timestamps and sizes (in KB):
次のタイムスタンプとサイズ（KB）のあるストリームを想像してください。
200 2 KB 300 4 KB 400 2 KB 500 12 KB 600 ...effective end of stream
200 2 KB 300 4 KB 400 2 KB 500 12 KB 600 ...発効終了ストリーム
This has 20 KB spread over 400 time units, i.e., on average, 1 KB per 20 time units. We traffic-smooth this, and establish that given a transmission time of x for the first packet, we would transmit the following packets at the given intervals later:
これには、400時間以上の20 kbの広がり、つまり平均して20時間あたり1 kbが1 kbになります。これを滑らかにし、最初のパケットのXの伝送時間を与えられた場合、後で次のパケットを送信することを確認します。
x + 000 2 KB x + 040 4 KB x + 120 2 KB x + 160 12 KB x + 400 ...effective end of stream
x 000 2 kb x 040 4 kb x 120 2 kb x 160 12 kb x 400 ...効果的なストリーム端
The choice of x is essentially arbitrary: only relative values of timestamps matter. Now, let's say I claim on the first packet that it went out *at* its RTP timestamp, i.e., with an offset of 0, meaning that x is 200. Then the offset values are:
xの選択は本質的に任意です。タイムスタンプの相対的な値のみが重要です。さて、最初のパケットで、RTPタイムスタンプに出た *、つまり0のオフセット、つまりxが200であると主張するとしましょう。その後、オフセット値は次のとおりです。
0 -60 -80 -140 This is because in this case, I traffic-smooth by conceptually sending the small packets 'early'. But since only the relative values are significant, it is just as valid to say x is 400, whereupon the offset values are:
0 -60 -80 -140これは、この場合、小さなパケットを「早期」に概念的に送信することで滑らかに滑らかにするためです。しかし、相対値のみが重要であるため、xが400であると言うことも有効です。オフセット値は次のとおりです。
200 140 120 60
200 140 120 60
In a stream where this extension is not in effect (i.e., not declared or negotiated), the actual transmission offset is therefore unknown. However, when the extension is in effect for the stream, it MAY be omitted in those packets for which the offset is 0 (zero); that is, packets sent at their nominal time do not need this to be tagged with this extension. Therefore, the implied transmission time of an un-tagged RTP packet depends on whether the extension is in effect for the stream (and therefore the transmission offset is 0) or not (whereupon the transmission offset is unknown).
したがって、この拡張機能が有効ではないストリーム（つまり、宣言または交渉されていない）では、実際の伝送オフセットは不明です。ただし、ストリームに対して拡張機能が有効な場合、オフセットが0（ゼロ）であるパケットで省略される場合があります。つまり、名目時間に送信されたパケットでは、この拡張機能でタグ付けする必要はありません。したがって、タグなしのRTPパケットの暗黙の送信時間は、拡張機能がストリームに対して有効であるか（したがって伝送オフセットが0）かどうかによって異なります（伝送オフセットは不明です）。
The jitter calculations performed by an RTP client MUST NOT use these transmission offsets. In general, the sender (or intermediate network elements doing RTP analysis) cannot always know whether the offsets have been taken into account or not. Therefore, for consistency, the jitter calculation should continue to operate on the 'raw' reception times. However, see Section 4 on extended jitter reports, below.
RTPクライアントが実行するジッター計算は、これらの送信オフセットを使用してはなりません。一般に、送信者（またはRTP分析を行う中間ネットワーク要素）は、オフセットが考慮されているかどうかを常に知ることはできません。したがって、一貫性のために、ジッター計算は「生の」受信時間に引き続き動作し続ける必要があります。ただし、以下の拡張ジッターレポートのセクション4を参照してください。
There are no extensionattributes defined for this extension.
この拡張機能のために定義されている拡張トリブはありません。
It is structurally possible to have more than one extension of the same type in a packet. However, this extension is only defined for the source to report. Intermediate network nodes that are not the source of the RTP session MUST NOT add this extension (whether or not it was previously present) and MUST NOT alter the existing transmission offset value in a packet, if the extension is already present.
パケットに同じタイプの複数の拡張機能を持つことは構造的に可能です。ただし、この拡張機能は、ソースが報告するためにのみ定義されます。RTPセッションのソースではない中間ネットワークノードは、この拡張機能を追加してはならない（以前に存在していたかどうかにかかわらず）、拡張機能が既に存在する場合、パケット内の既存の伝送オフセット値を変更してはなりません。
(Of course, it is clear that network elements that terminate an RTP flow, and are the source for a new RTP flow, can add a transmission offset extension header to the RTP packets of the new flow, if desired.)
（もちろん、RTPフローを終了し、新しいRTPフローのソースであるネットワーク要素は、必要に応じて、新しいフローのRTPパケットに送信オフセット拡張ヘッダーを追加できることは明らかです。）
The inter-arrival jitter computed as defined in Section 6.4.1 of RFC 3550 provides inter-arrival jitter reports that include any source-introduced jitter (transmission time offsets). If it is desired to indicate the actual network jitter, excluding the source-introduced jitter, the new RTCP packet type defined here may be used.
RFC 3550のセクション6.4.1で定義されているように計算された到着間ジッターは、ソースに導入されたジッター（伝送時間オフセット）を含む到着間ジッターレポートを提供します。ソースに導入されたジッターを除く実際のネットワークジッターを示すことが望ましい場合は、ここで定義されている新しいRTCPパケットタイプを使用できます。
It has the following form:
次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
hdr |V=2|P| RC | PT=IJ=195 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| inter-arrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
| inter-arrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If present, this RTCP packet must be placed after a receiver report (inside a compound RTCP packet), and MUST have the same value for RC (reception report count) as the receiver report. The content is exactly that number of inter-arrival jitter calculations, calculated using the same formula as for sender and receiver reports, but taking into account the transmission offsets for the streams (if any). That is, the formula uses the values T1=S1+O1, T2, etc., as defined above, instead of S1, S2, etc. (If no transmission offset information is given for a stream, then the value of inter-arrival jitter in this packet and in the receiver report will be identical).
存在する場合、このRTCPパケットは、レシーバーレポートの後に（化合物RTCPパケット内）に配置する必要があり、RC（受信レポートカウント）と同じ値がレポートと同じ値を持たなければなりません。コンテンツは、送信者および受信機のレポートと同じ式を使用して計算されたが、ストリームの送信オフセット（ある場合）を考慮に入れて、まさにその数の攻撃ジッター計算の数です。つまり、式は、S1、S2などではなく、上記で定義されているように、値T1 = S1 O1、T2などを使用します（ストリームに対して伝送オフセット情報が与えられない場合、攻撃間ジッターの値はこのパケットと受信機でレポートは同一です）。
Precisely, the replacement equation for the equation in the RTP specification is as follows, where Rj is the most recent arrival time:
正確には、RTP仕様の方程式の交換方程式は次のとおりです。ここで、RJは最新の到着時間です。
D(i,j) = (Rj - Ri) - ((Sj + Oj) - (Si + Oi))
= (Rj - (Sj + Oj)) - (Ri - (Si + Oi))
The URI for declaring this header extension in an extmap attribute is "urn:ietf:params:rtp-hdrext:toffset". There is no additional setup information needed for this extension (no extensionattributes).
ExtMap属性でこのヘッダー拡張機能を宣言するURIは、「urn：ietf：params：rtp-hdrext：toffset」です。この拡張機能に必要な追加のセットアップ情報はありません（拡張機能はありません）。
The given transmission offsets are only informative, and it is hard to see security considerations from associating them with media streams.
指定された伝送オフセットは有益であり、メディアストリームに関連するセキュリティ上の考慮事項を見るのは困難です。
The underlying security considerations of [RFC3550] should be taken into account.
[RFC3550]の基礎となるセキュリティ上の考慮事項を考慮する必要があります。
It is possible that malicious senders (or systems tampering with packets in transit) could send offsets that are implausible, could confuse the receiver, or result in calculated jitter values that might mislead the sender. Both the sender and receiver of the transmission offsets and jitter values should take care that such behavior does not result in denial of service or other problems.
悪意のある送信者（または輸送中のパケットを改ざんするシステム）は、信じられないオフセットを送信したり、受信機を混乱させたり、送信者を誤解させる可能性のある計算されたジッター値をもたらす可能性があります。送信者とジッター値の送信者と受信者の両方が、そのような動作がサービスの拒否やその他の問題をもたらさないことに注意する必要があります。
The RTCP packet type used for the adjusted inter-arrival jitter has been registered, in accordance with Section 15 of [RFC3550]. IANA has added a new value to the RTCP Control Packet types subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data:
[RFC3550]のセクション15に従って、調整された到着間ジッターに使用されるRTCPパケットタイプが登録されています。IANAは、次のデータに従って、RTCPコントロールパケットタイプのリアルタイムトランスポートプロトコル（RTP）パラメーターレジストリのサブレジストリに新しい値を追加しました。
abbrev. name value Reference
------- ------------------------------------ ------ ---------
IJ Extended inter-arrival jitter report 195 RFC 5450
Additionally, IANA has registered a new extension URI to the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data:
さらに、IANAは、以下のデータに従って、RTP Compact Header Extensions Subregistry of the Real-Time Transport Protocol（RTP）パラメーターレジストリに新しい拡張機能を登録しました。
Extension URI: urn:ietf:params:rtp-hdrext:toffset
Description: Transmission Time offsets
Contact: singer@apple.com
Reference: RFC 5450
Ron Frederick, Colin Perkins, and Steve Casner all contributed substantially to this document, and their help and contributions helped turn an idea into a specification.
Ron Frederick、Colin Perkins、Steve Casnerはすべてこの文書に大きく貢献し、彼らの助けと貢献はアイデアを仕様に変えるのに役立ちました。
[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：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008.
[RFC5285]シンガー、D。およびH.デシネニ、「RTPヘッダー拡張の一般的なメカニズム」、RFC 5285、2008年7月。
Authors' Addresses
著者のアドレス
David Singer Apple Computer Inc. 1 Infinite Loop Cupertino, CA 95014 US
David Singer Apple Computer Inc. 1 Infinite Loop Cupertino、CA 95014 US
Phone: +1 408 996 1010
EMail: singer@apple.com
Harikishan Desineni Qualcomm 5775 Morehouse Drive San Diego, CA 92121 US
Harikishan Desineni Qualcomm 5775 Morehouse Drive San Diego、CA 92121 US
Phone: +1 858 845 8996
EMail: hd@qualcomm.com