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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
ストリームのデータレートは、IフレームがPまたはBフレームよりも大幅に大きくすることができるビデオと同様に、バースト性である場合、O、トラフィックの平滑化は、適切なデータレートを維持するために適用される必要があるかもしれません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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を送信することが可能。 （S1 + O1） - これらのオフセットの一つの特徴は、元の送信間隔を（S2 + O2）であると推定することができることです。
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):
より正確には、（RTPからネットワークタイムプロトコル（NTP）回、及びNtoR逆をやってに変換する機能RTONで）次のように定義されたオフセット：
o Take an RTP stream that has a recent RTCP sender report relating RTP timestamp S0 to NTP timestamp N0;
O NTPタイムスタンプN0にRTPタイムスタンプS0に関連する最近の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（ - N1 NA）です。
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送信時間を表します。 （二つ以上を比較したとき、もちろん送信時間値のみを意味しているが）O1のオフセットタイムスタンプS1とを有するパケットの報告の送信時間T1は、上記の式から、T1 = S1 + O1です。
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.
オフセット値の符号は、NTP時刻にRTPの初期マッピングの選択に大きく依存します。一般的には、ストリームをスキャンせず、完全にこのマッピングは、正のすべてのオフセットを続けるだろうことを保証することはできません。従って、本明細書では負の値を可能にします。
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キロバイト300 4キロバイト400 2キロバイト500 12キロバイト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時間単位当たり、すなわち、平均で、1キロバイトを超える20の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キロバイトX + 040 4キロバイトX + 120 2キロバイトX + 160 12キロバイト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の選択は、本質的に任意である：タイムスタンプの問題の唯一の相対値。それでは、私は、xが200であることを意味し、それが0のオフセットで、すなわち、そのRTPタイムスタンプ*で*出て行ったという最初のパケットに主張しましょうそして、オフセット値は次のとおりです。
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:
この場合、私は交通円滑なので、これは概念的には、小さなパケットの早期 "を送信することです。相対値だけが重要であるため、しかし、オフセット値であるところ、xは、400であると言って、同じように有効です。
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.
この拡張のために定義されextensionattributesはありません。
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:
次のようにRjは、最新の到着時間である正確には、RTP仕様の方程式の交換方程式は、次のとおりです。
D(i,j) = (Rj - Ri) - ((Sj + Oj) - (Si + Oi)) = (Rj - (Sj + Oj)) - (Ri - (Si + Oi))
D（i、j）は=（RJ - RI） - （（SJ +クラス） - シリコン（Si + OI））=（RJ - （+クラスSJ）） - （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は、 "IETF：paramsは：RTP-hdrext：TOFFSET URN" です。この拡張機能（なしextensionattributes）のために必要な追加の設定情報がありません。
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:
調整された到着間ジッタのために使用されるRTCPパケットタイプは、[RFC3550]のセクション15に応じて、登録されています。 IANAは、次のデータによると、リアルタイムトランスポートプロトコル（RTP）パラメータレジストリのRTCP制御パケットの種類の副登録に新しい値を追加しました：
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）パラメータレジストリのRTPコンパクトヘッダー拡張副登録に新しい拡張URIを登録しています：
Extension URI: urn:ietf:params:rtp-hdrext:toffset Description: Transmission Time offsets Contact: singer@apple.com Reference: RFC 5450
拡張URI：URN：IETF：のparams：RTP-hdrext：TOFFSET説明：伝送時間は、連絡先を相殺：singer@apple.com参考：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.
ロン・フレデリック、コリンパーキンス、そしてスティーブCasnerはすべて、この文書には、実質的に貢献し、そして彼らの助けと貢献は、仕様にアイデアを回す助けました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、フレデリック、R.、およびV.ヤコブソン、 "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. Desineni、 "RTPヘッダー拡張のための一般的なメカニズム"、RFC 5285、2008年7月。
Authors' Addresses
著者のアドレス
David Singer Apple Computer Inc. 1 Infinite Loop Cupertino, CA 95014 US
デビッド・シンガーアップルコンピュータ社1無限ループクパチーノ、CA 95014米国
Phone: +1 408 996 1010 EMail: singer@apple.com
電話：+1 408 996 1010 Eメール：singer@apple.com
Harikishan Desineni Qualcomm 5775 Morehouse Drive San Diego, CA 92121 US
92121のHarikishan Desineniクアルコム5775 Morehuseドライブサンディエゴ、
Phone: +1 858 845 8996 EMail: hd@qualcomm.com
電話：+1 858 845 8996 Eメール：hd@qualcomm.com