Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 6051 University of Glasgow
Updates: 3550 T. Schierl
Category: Standards Track Fraunhofer HHI
ISSN: 2070-1721 November 2010
Rapid Synchronisation of RTP Flows
Abstract
抽象
This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.
このメモはRTPセッションが同期されている方法の概要を示し、そしてこのような同期が発生する可能性がありますどのように急速に説明します。私たちは、ほとんどのRTPセッションが即座に同期させることができることを示しているが、ビデオの切り替え多地点会議ユニット（MCUの）または大規模なソース固有のマルチキャスト（SSM）基の使用が大幅に同期遅延を増加させることができること。遅延の増加は層状及び/又はマルチ説明コーデックを使用するいくつかのアプリケーションに受け入れられないとすることができます。
This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew.
このメモは、このようなセッションの同期遅延を低減するために3つのメカニズムを紹介します。まず、SSMセッションの初期同期遅延を低減するためにRTP制御プロトコル（RTCP）タイミングのルールを更新します。第二に、新たなフィードバックパケットは、ビデオ切り替えマイコンが急速に再同期を要求することができ、RTCPベースのフィードバック（RTP / AVPF）の拡張RTPプロファイルで使用するために定義されています。最後に、新しいRTPヘッダ拡張は後半ジョイナーの迅速な同期を可能にし、クロック・スキューの存在下での階層化コーデックの正しいタイムスタンプベースの復号順序の回復を保証するために定義されています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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）の製品です。これは、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/rfc6051.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6051で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Synchronisation of RTP Flows ....................................4
2.1. Initial Synchronisation Delay ..............................5
2.1.1. Unicast Sessions ....................................5
2.1.2. Source-Specific Multicast (SSM) Sessions ............6
2.1.3. Any-Source Multicast (ASM) Sessions .................7
2.1.4. Discussion ..........................................8
2.2. Synchronisation for Late Joiners ...........................9
3. Reducing RTP Synchronisation Delays ............................10
3.1. Reduced Initial RTCP Interval for SSM Senders .............10
3.2. Rapid Resynchronisation Request ...........................10
3.3. In-Band Delivery of Synchronisation Metadata ..............11
4. Application to Decoding Order Recovery in Layered Codecs .......14
4.1. In-Band Synchronisation for Decoding Order Recovery .......14
4.2. Timestamp-Based Decoding Order Recovery ...................15
4.3. Example ...................................................16
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
7. Acknowledgements ...............................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
When using RTP to deliver multimedia content it's often necessary to synchronise playout of audio and video components of a presentation. This is achieved using information contained in RTP Control Protocol (RTCP) sender report (SR) packets [RFC3550]. These are sent periodically, and the components of a multimedia session cannot be synchronised until sufficient RTCP SR packets have been received for each RTP flow to allow the receiver to establish mappings between the media clock used for each RTP flow, and the common (NTP-format) reference clock used to establish synchronisation.
マルチメディアコンテンツを配信するためにRTPを使用する場合は、プレゼンテーションのオーディオおよびビデオコンポーネントの再生を同期させることがしばしば必要です。これは、RTP制御プロトコル（RTCP）センダレポート（SR）パケット[RFC3550]に含まれる情報を使用して達成されます。 NTP-（これらは、定期的に送信され、マルチメディア・セッションの成分は十分のRTCP SRパケットは受信機が各RTPフローのために使用されるメディアクロックと共通の間のマッピングを確立することを可能にするために、各RTPフローのために受信されるまで同期させることができませんフォーマット）は、基準クロックは、同期を確立するために使用されます。
Recently, concern has been expressed that this synchronisation delay is problematic for some applications, for example those using layered or multi-description video coding. This memo reviews the operations of RTP synchronisation, and describes the synchronisation delay that can be expected. Three backwards compatible extensions to the basic RTP synchronisation mechanism are proposed:
最近、懸念は、この同期遅延は、例えば、層状または多層記述ビデオコーディングを使用してそれらのために、いくつかの用途のために問題があることが表されています。このメモはRTPの同期の動作をレビューし、期待することができる同期遅延について説明します。基本的なRTP同期メカニズムに三つの下位互換性の拡張が提案されています。
o The RTCP transmission timing rules are relaxed for source-specific multicast (SSM) senders, to reduce the initial synchronisation latency for large SSM groups. See Section 3.1.
Oタイミングルールは、ソース固有マルチキャスト（SSM）送信者のために緩和されるRTCP送信が大きいSSMグループの初期同期待ち時間を低減します。 3.1節を参照してください。
o An enhancement to the extended RTP profile for RTCP-based feedback (RTP/AVPF) [RFC4585] is defined to allow receivers to request additional RTCP SR packets, providing the metadata needed to synchronise RTP flows. This can reduce the synchronisation delay when joining sessions with large RTCP reporting intervals, in the presence of packet loss, or when video switching MCUs are employed. See Section 3.2.
O RTCPベースのフィードバック（RTP / AVPF）の拡張RTPプロファイルへの拡張は、[RFC4585]はRTPフローを同期させるために必要なメタデータを提供し、受信機は追加のRTCP SRパケットを要求することを可能にするように定義されます。これは、パケット損失の存在下で、大規模なRTCP報告間隔とのセッションに参加し、またはビデオスイッチングのMCUが採用されている場合、同期遅延を低減することができます。 3.2節を参照してください。
o Two RTP header extensions are defined, to deliver synchronisation metadata in-band with RTP data packets. These extensions provide synchronisation metadata that is aligned with RTP data packets, and so eliminate the need to estimate clock skew between flows before synchronisation. They can also reduce the need to receive RTCP SR packets before flows can be synchronised, although it does not eliminate the need for RTCP. See Section 3.3.
O二つのRTPヘッダ拡張は、RTPデータパケットと帯域内同期メタデータを配信するために、定義されています。これらの拡張機能は、RTPデータパケットと整列される同期メタデータを提供し、その同期の前にフロー間のクロック・スキューを推定する必要がなくなります。それはRTCPの必要性がなくなるわけではありませんが、彼らはまた、フローを同期させることができる前に、RTCP SRパケットを受信する必要性を減らすことができます。 3.3節を参照してください。
The immediate use-case for these extensions is to reduce the delay due to synchronisation when joining a layered video session (e.g., an H.264/SVC (Scalable Video Coding) session in Non-Interleaved Timestamp-based (NI-T) mode [AVT-RTP-SVC]). The extensions are not specific to layered coding, however, and can be used in any environment when synchronisation latency is an issue.
これらの拡張のための即時のユースケースは、層状ビデオセッション（例えば、非インターリーブタイムスタンプベース（NI-T）モードでのH.264 / SVC（スケーラブルビデオ符号化）セッションに参加するときにより同期化遅延を低減することです[AVT-RTP-SVC]）。拡張子は、しかし、階層符号化に固有ではない、との同期待ち時間が問題であるとき、任意の環境で使用することができます。
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]に記載されているように解釈されます。
RTP flows are synchronised by receivers based on information that is contained in RTCP SR packets generated by senders (specifically, the NTP-format timestamp and the RTP timestamp). Synchronisation requires that a common reference clock MUST be used to generate the NTP-format timestamps in a set of flows that are to be synchronised (i.e., when synchronising several RTP flows, the RTP timestamps for each flow are derived from separate, and media specific, clocks, but the NTP-format timestamps in the RTCP SR packets of all flows to be synchronised MUST be sampled from the same clock). To achieve faster and more accurate synchronisation, it is further RECOMMENDED that senders and receivers use a synchronised common NTP-format reference clock with common properties, especially timebase, where possible (recognising that this is often not possible when RTP is used outside of controlled environments); the means by which that common reference clock and its properties are signalled and distributed is outside the scope of this memo.
RTPフローは、送信者（具体的には、NTPフォーマットのタイムスタンプとRTPタイムスタンプ）によって生成されたRTCP SRパケットに含まれる情報に基づいて受信機によって同期されます。同期は、いくつかのRTPフローを同期するときに（すなわち、各フローのためのRTPタイムスタンプは、別個の、およびメディア特定由来する共通の基準クロックが同期されるべきフローの組におけるNTPフォーマットのタイムスタンプを生成するために使用しなければならないことを要求します、同期されるすべてのフローのRTCP SRパケットでクロックが、NTP形式のタイムスタンプ）が同じクロックでサンプリングしなければなりません。より速く、より正確な同期を達成するために、さらに送信者と受信者は、共通の特性、RTPは、制御された環境の外で使用され、これはしばしば不可能であることを認識し（可能特にタイムベースに同期共通NTPフォーマットの基準クロックを使用することをお勧めします）;その共通の基準クロックと、その特性が合図と分散される手段は、このメモの範囲外です。
For multimedia sessions, each type of media (e.g., audio or video) is sent in a separate RTP session, and the receiver associates RTP flows to be synchronised by means of the canonical end-point identifier (CNAME) item included in the RTCP Source Description (SDES) packets generated by the sender or signalled out of band [RFC5576]. For layered media, different layers can be sent in different RTP sessions, or using different synchronisation source (SSRC) values within a single RTP session; in both cases, the CNAME is used to identify flows to be synchronised. To ensure synchronisation, an RTP sender MUST therefore send periodic compound RTCP packets following Section 6 of RFC 3550 [RFC3550].
マルチメディアセッションの場合、メディアの各タイプ（例えば、オーディオまたはビデオ）は、別個のRTPセッションで送信され、受信機は、RTPがRTCPソースに含まれる正規エンドポイント識別子（CNAME）項目によって同期させることが流れる関連付けされています記述（SDES）パケット送信者によって生成または帯域外シグナリング[RFC5576]。層状媒体に、異なる層は、異なるRTPセッションで送信することができ、または単一のRTPセッション内の異なる同期ソース（SSRC）値を使用して、両方の場合において、CNAMEが同期するフローを識別するために使用されます。同期を確実にするために、RTP送信者は、したがって、RFC 3550 [RFC3550]のセクション6次の周期複合RTCPパケットを送信しなければなりません。
The timing of these periodic compound RTCP packets will depend on the number of members in each RTP session, the fraction of those that are sending data, the session bandwidth, the configured RTCP bandwidth fraction, and whether the session is multicast or unicast (see RFC 3550, Section 6.2 for details). In summary, RTCP control traffic is allocated a small fraction, generally 5%, of the session bandwidth, and of that fraction, one quarter is allocated to active RTP senders, while receivers use the remaining three quarters (these fractions can be configured via the Session Description Protocol (SDP) [RFC3556]). Each member of an RTP session derives an RTCP reporting interval based on these fractions, whether the session is multicast or unicast, the number of members it has observed, and whether it is actively sending data or not. It then sends a compound
これらの周期的な化合物のRTCPパケットのタイミングは、各RTPセッションにおけるメンバーの数、データを送信しているものの割合、セッション帯域幅、構成されたRTCP帯域幅の割合に依存し、セッションは、マルチキャストまたはユニキャストであるかどうか（RFCが表示されます3550、詳細については6.2節）。受信機は、残りの四分の三を使用している間（これらの画分を介して設定することができ、要するに、RTCP制御トラフィックは、セッション帯域幅のごく一部、一般的に5％を割り当てられ、その画分、四分の一は、アクティブRTP送信者に割り当てられていますセッション記述プロトコル（SDP）[RFC3556]）。 RTPセッションの各メンバーは、これらの画分に基づくRTCPレポート間隔を導出し、セッションは、マルチキャストまたはユニキャストであるかどうか、メンバーの数は、それが観察され、それが積極的にデータを送信しているか否かをしています。その後、化合物を送信します
RTCP packet on average once per reporting interval (the actual packet transmission time is randomised in the range [0.5 ... 1.5] times the reporting interval to avoid synchronisation of reports).
間隔（実際のパケット送信時間が範囲内にランダム化されている[0.5 ... 1.5]レポートの同期を避ける倍報告間隔）を報告当たり回平均RTCPパケット。
A minimum reporting interval of 5 seconds is RECOMMENDED, except that the delay before sending the initial report "MAY be set to half the minimum interval to allow quicker notification that the new participant is present" [RFC3550]. Also, for unicast sessions, "the delay before sending the initial compound RTCP packet MAY be zero" [RFC3550]. In addition, for unicast sessions, and for active senders in a multicast session, the fixed minimum reporting interval MAY be scaled to "360 divided by the session bandwidth in kilobits/second. This minimum is smaller than 5 seconds for bandwidths greater than 72 kb/s" [RFC3550].
5秒の最小報告間隔は遅延初期レポートを送信する前に、[RFC3550]を「新しい参加者が存在しているより早く通知を許可するように半分の最小間隔に設定されるかもしれません」ということを除いて、推奨されます。また、ユニキャストセッションのために、[RFC3550]「初期複合RTCPパケットを送信する前に遅延が0であってもよいです」。また、ユニキャストセッションのために、マルチキャストセッションでアクティブな送信者のために、固定された最小のレポートインターバル/秒キロビットのセッション帯域幅で割った「360にスケーリングすることができる。この最小帯域幅のために5秒を超える72キロバイト未満であります/ S」[RFC3550]。
A multimedia session comprises a set of concurrent RTP sessions among a common group of participants, using one RTP session for each media type. For example, a videoconference (which is a multimedia session) might contain an audio RTP session and a video RTP session. To allow a receiver to synchronise the components of a multimedia session, a compound RTCP packet containing an RTCP SR packet and an RTCP SDES packet with a CNAME item MUST be sent to each of the RTP sessions in the multimedia session by each sender. A receiver cannot synchronise playout across the multimedia session until such RTCP packets have been received on all of the component RTP sessions. If there is no packet loss, this gives an expected initial synchronisation delay equal to the average time taken to receive the first RTCP packet in the RTP session with the longest RTCP reporting interval. This will vary between unicast and multicast RTP sessions.
マルチメディアセッションは、各メディアタイプに対して1つのRTPセッションを使用して、参加者の共通のグループ間で同時RTPセッションのセットを含みます。例えば、（マルチメディアセッションである）、ビデオ会議、オーディオRTPセッション及びビデオRTPセッションが含まれる可能性があります。受信機は、マルチメディアセッションのコンポーネントを同期することを可能にするために、RTCPのSRパケットとCNAME項目にRTCP SDESパケットを含む化合物RTCPパケットは、各送信者のマルチメディアセッションでRTPセッションの各々に送信されなければなりません。このようなRTCPパケットがコンポーネントRTPセッションの全てで受信されるまで、受信機は、マルチメディアセッションを横切って再生を同期させることができません。パケットロスがない場合、これは最長のRTCPレポート間隔のRTPセッションにおける最初のRTCPパケットを受信するのにかかる平均時間に等しい期待される初期同期遅延を与えます。これは、ユニキャストとマルチキャストのRTPセッションの間で変化します。
The initial synchronisation delay for layered sessions is similar to that for multimedia sessions. The layers cannot be synchronised until the RTCP SR and CNAME information has been received for each layer in the session.
層状のセッションの初期同期遅延は、マルチメディアセッションのためのものと同様です。 RTCP SRとCNAME情報は、セッション内の各レイヤのために受信されるまで層を同期させることができません。
For unicast multimedia or layered sessions, senders SHOULD transmit an initial compound RTCP packet (containing an RTCP SR packet and an RTCP SDES packet with a CNAME item) immediately on joining each RTP session in the multimedia session. The individual RTP sessions are considered to be joined once any in-band signalling for NAT traversal (e.g., [RFC5245]) and/or security keying (e.g., [RFC5764], [ZRTP]) has concluded, and the media path is open. This implies that the initial RTCP packet is sent in parallel with the first data packet following the guidance in RFC 3550 that "the delay before sending the initial compound RTCP packet MAY be zero" and, in the absence of any packet loss, flows can be synchronised immediately.
ユニキャストマルチメディア又は層状セッションのために、送信者は直ちにマルチメディアセッション内の各RTPセッションの参加に（RTCPのSRパケットとCNAME項目にRTCP SDESパケットを含む）初期複合RTCPパケットを送信しなければなりません。個々のRTPセッションがNATトラバーサルのためのシグナリング帯域内一度任意接合すると考えられている（例えば、[RFC5245]）および/またはセキュリティキー（例えば、[RFC5764]、[ZRTP]）を締結しており、メディアパスが開放されています。これは、最初のRTCPパケットが「初期複合RTCPパケットを送信する前に遅延が0であってもよい」とRFC 3550のガイダンスに続く最初のデータパケットと並列に送信されることを意味すると、任意のパケット損失が存在しない場合に、フローがあってもよいですすぐに同期。
It is expected that NAT pinholes, firewall holes, quality-of-service, and media security keys will have been negotiated as part of the signalling, whether in-band or out-of-band, before the first RTCP packet is sent. This should ensure that any middleboxes are ready to accept traffic, and reduce the likelihood that the initial RTCP packet will be lost.
帯域内または帯域外のかどうかを最初にRTCPパケットが送信される前にNATピンホール、ファイアウォールの穴、サービス品質、およびメディアのセキュリティキーは、シグナリングの一部として交渉されていることが期待されます。これは、任意のミドルボックスがトラフィックを受け入れる準備ができていることを確認し、最初のRTCPパケットが失われる可能性を減らす必要があります。
For multicast sessions, the delay before sending the initial RTCP packet, and hence the synchronisation delay, varies with the session bandwidth and the number of members in the session. For a multicast multimedia or layered session, the average synchronisation delay will depend on the slowest of the component RTP sessions; this will generally be the session with the lowest bandwidth (assuming all the RTP sessions have the same number of members).
マルチキャストセッションのために、最初のRTCPパケット、ひいては同期遅延を送信する前の遅延は、セッション帯域幅、セッション内のメンバーの数に応じて変化します。マルチキャストマルチメディア又は層状セッションのために、平均同期遅延は、成分のRTPセッションの最も遅いに依存するであろう。これは、一般的に最低帯域幅（すべてのRTPセッションはメンバーの数が同じと仮定）とのセッションになります。
When sending to a multicast group, the reduced minimum RTCP reporting interval of 360 seconds divided by the session bandwidth in kilobits per second [RFC3550] should be used when synchronisation latency is likely to be an issue. Also, as usual, the reporting interval is halved for the first RTCP packet. Depending on the session bandwidth and the number of members, this gives the average synchronisation delays shown in Figure 1.
マルチキャストグループに送信するときに同期待ち時間が問題になりそうである場合、次の[RFC3550]あたりのキロビットでセッション帯域幅で割った360秒の減少最小RTCPレポート間隔は、使用されるべきです。また、いつものように、レポート間隔は、最初のRTCPパケットのために半分になります。セッション帯域幅とメンバーの数に応じて、これは図1に示される平均の同期遅延を与えます。
Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 5.47 5.47 5.47 5.47 5.47
16 kbps| 2.50 2.50 2.73 2.73 2.73 2.73 2.73 2.73
32 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Figure 1: Average Initial Synchronisation Delay in Seconds for an RTP Session with 1 Sender
図1：1つのSenderとのRTPセッションの秒で平均初期同期遅延
These numbers assume a source-specific multicast channel with a single active sender, assuming an average RTCP packet size of 70 octets. These intervals are sufficient for lip-synchronisation without excessive delay, but might be viewed as having too much latency for synchronising parts of a layered video stream.
これらの数字は、70オクテットの平均RTCPパケットサイズを仮定すると、単一のアクティブの送信者とソース固有マルチキャストチャネルを想定します。これらの間隔は、過度の遅延なしリップ同期には十分ですが、階層化ビデオストリームの部分を同期させるためにあまりにも多くのレイテンシーを持つと見られるかもしれません。
The RTCP interval is randomised in the usual manner, so the minimum synchronisation delay will be half these intervals, and the maximum delay will be 1.5 times these intervals. Note also that these RTCP intervals are calculated assuming perfect knowledge of the number of members in the session.
最小同期遅延は半分これらの間隔になるようRTCP間隔は、通常の方法でランダム化され、最大遅延は1.5倍これらの間隔となります。これらのRTCP間隔はセッションのメンバー数の完全な知識を仮定して計算していることにも注意してください。
For ASM sessions, the fraction of members that are senders plays an important role, and causes more variation in average RTCP reporting interval. This is illustrated in Figure 2 and Figure 3, which show the RTCP reporting interval for the same session bandwidths and receiver populations as the SSM session described in Figure 1, but for sessions with 2 and 10 senders, respectively. It can be seen that the initial synchronisation delay scales with the number of senders (this is to ensure that the total RTCP traffic from all group members does not grow without bound) and can be significantly larger than for source-specific groups. Despite this, the initial synchronisation time remains acceptable for lip-synchronisation in typical small-to-medium sized group video conferencing scenarios.
ASMのセッションでは、送信者であるメンバーの一部が重要な役割を果たしており、平均RTCPのレポート間隔でより変動の原因となります。これは、それぞれ、図1で説明したSSMのセッションと同じセッション帯域幅と受信機集団のためのRTCPレポート間隔を示しており、図2及び図3に示されているが、2と10の送信者とのセッションのためのものです。初期同期の遅延は送信者の数とソース固有のグループに比べて著しく大きくなることができます（これは、すべてのグループメンバーからの総RTCPトラフィックが際限なく成長しないことを確実にするためである）に比例することがわかります。それにもかかわらず、初期同期時間は、典型的な中小グループビデオ会議のシナリオでのリップ同期のための許容可能なまま。
Note that multi-sender groups implemented using multi-unicast with a central RTP translator (Topo-Translator in the terminology of [RFC5117]) or mixer (Topo-Mixer), or some forms of video switching MCU (Topo-Video-switch-MCU) distribute RTCP packets to all members of the group, and so scale in the same way as an ASM group with regards to initial synchronisation latency.
マルチ送信者グループは、またはミキサー（TOPO-ミキサー）（[RFC5117]の用語でTOPO-翻訳）中央RTPトランスレータ有するマルチユニキャストを使用して実装ことに留意されたい、又はMCUを切り替える映像のいくつかの形態（TOPO-ビデオSWITCH- MCU）は、グループのすべてのメンバーにRTCPパケットを配布するなど初期同期待ち時間に関してASM基と同様にスケール。
Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 10.94 10.94 10.94 10.94
16 kbps| 2.50 2.50 2.73 3.42 5.47 5.47 5.47 5.47
32 kbps| 2.50 2.50 2.50 2.50 2.73 2.73 2.73 2.73
64 kbps| 2.50 2.50 2.50 2.50 2.50 2.50 2.50 2.50
128 kbps| 1.41 1.41 1.41 1.41 1.41 1.41 1.41 1.41
256 kbps| 0.70 0.70 0.70 0.70 0.70 0.70 0.70 0.70
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.35 0.35 0.35
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.18 0.18 0.18
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.04 0.04 0.04
Figure 2: Average Initial Synchronisation Delay in Seconds for an RTP Session with 2 Senders
図2：2つの差出人とのRTPセッションの秒で平均初期同期遅延
Session| Number of receivers:
Bandwidth| 2 3 4 5 10 100 1000 10000
--+------------------------------------------------
8 kbps| 2.73 4.10 5.47 6.84 13.67 54.69 54.69 54.69
16 kbps| 2.50 2.50 2.73 3.42 6.84 27.34 27.34 27.34
32 kbps| 2.50 2.50 2.50 2.50 3.42 13.67 13.67 13.67
64 kbps| 2.50 2.50 2.50 2.50 2.50 6.84 6.84 6.84
128 kbps| 1.41 1.41 1.41 1.41 1.41 3.42 3.42 3.42
256 kbps| 0.70 0.70 0.70 0.70 0.70 1.71 1.71 1.71
512 kbps| 0.35 0.35 0.35 0.35 0.35 0.85 0.85 0.85
1 Mbps| 0.18 0.18 0.18 0.18 0.18 0.43 0.43 0.43
2 Mbps| 0.09 0.09 0.09 0.09 0.09 0.21 0.21 0.21
4 Mbps| 0.04 0.04 0.04 0.04 0.04 0.11 0.11 0.11
Figure 3: Average Initial Synchronisation Delay in Seconds for an RTP Session with 10 Senders
図3：10の差出人とのRTPセッションの秒で平均初期同期遅延
For unicast sessions, the existing RTCP SR-based mechanism allows for immediate synchronisation, provided the initial RTCP packet is not lost.
ユニキャストセッションでは、既存のRTCP SRベースのメカニズムは、即時同期を可能にし、最初のRTCPパケットが失われることはありません提供。
For SSM sessions, the initial synchronisation delay is sufficient for lip-synchronisation, but may be larger than desired for some layered codecs. The rationale for not sending immediate RTCP packets for multicast groups is to avoid implosion of requests when large numbers of members simultaneously join the group ("flash crowd"). This is not an issue for SSM senders, since there can be at most one sender, so it is desirable to allow SSM senders to send an immediate RTCP SR on joining a session (as is currently allowed for unicast sessions, which also don't suffer from the implosion problem). SSM receivers using unicast feedback would not be allowed to send immediate RTCP. For ASM sessions, implosion of responses is a concern, so no change is proposed to the RTCP timing rules.
SSMセッションのために、初期同期遅延は、リップ同期化のために十分であるが、いくつかの層状のコーデックのために所望されるよりも大きくてもよいです。マルチキャストグループのための即時のRTCPパケットを送信しないための理論的根拠は、多数のメンバーが同時にグループ（「フラッシュ・クラウド」）に参加するときの要求の内部破裂を避けるためです。最大1つの送信者が存在することができるので、これは、SSM送信者のための問題ではありませんので、SSMの送信者は、現在のユニキャストセッションのために許可されているとして（セッションに参加する上での即時RTCP SRを送信できるようにすることが望ましい、またそうでありません）爆縮の問題に苦しみます。ユニキャストフィードバックを使用してSSM受信機はすぐにRTCPを送信することを許可されません。 ASMセッションでは、回答の爆縮が懸念されるので、何の変化は、RTCPタイミング規則に提案されていません。
In all cases, it is possible that the initial RTCP SR packet is lost. In this case, the receiver will not be able to synchronise the media until the reporting interval has passed, and the next RTCP SR packet is sent. This is undesirable. Section 3.2 defines a new RTP/AVPF transport layer feedback message to request that an RTCP SR be generated, allowing rapid resynchronisation in the case of packet loss.
すべての場合において、初期のRTCP SRパケットが失われている可能性があります。レポート間隔が経過すると、次のRTCP SRパケットが送信されるまで、この場合、受信機は、メディアを同期することができません。これは望ましくありません。セクション3.2は、パケット損失の場合に迅速な再同期を可能にする、RTCP SRが生成されることを要求する新たなRTP / AVPFトランスポート層フィードバックメッセージを定義します。
Synchronisation between RTP sessions is potentially slower for late joiners than for participants present at the start of the session. The reasons for this are three-fold:
RTPセッションの間の同期は、セッションの開始時に存在参加者のためのより遅くジョイナのための潜在的に遅くなります。この理由は3つある：
1. Many of the optimisations that allow rapid transmission of RTCP SR packets apply only at the start of a session. This implies that a new participant may have to wait a complete RTCP reporting interval for each session before receiving the necessary data to synchronise media streams. This might potentially take several seconds, depending on the configured session bandwidth and the number of participants.
RTCP SRパケットの迅速な伝達を許す最適化の1.多くは、唯一のセッションの開始時に適用されます。これにより、新しい参加者がメディアストリームを同期させるために必要なデータを受信する前に、各セッションのための完全なRTCPのレポート間隔を待たなければならないことを意味します。これは、潜在的に構成されたセッション帯域幅と参加者の数に応じて、数秒かかることがあります。
2. Additional synchronisation delay comes from the nature of the RTCP timing rules. Packets are generated on average once per reporting interval, but with the exact transmission times being randomised +/- 50% to avoid synchronisation of reports. This is important to avoid network congestion in multicast sessions, but does mean that the timing of RTCP sender reports for different RTP sessions isn't synchronised. Accordingly, a receiver must estimate the skew on the NTP-format clock in order to align RTP timestamps across sessions. This estimation is an essential part of an RTP synchronisation implementation, and can be done with high accuracy given sufficient reports. Collecting sufficient RTCP SR data to perform this estimation, however, may require reception of several RTCP reports, further increasing the synchronisation delay.
2.追加の同期遅延は、RTCPタイミング規則の性質から来ています。パケットは、一度の間隔を報告あたりの平均で生成されているが、正確な伝送時間でレポートの同期を避けるために+/- 50％をランダム化されています。これは、マルチキャストセッションでのネットワークの輻輳を回避することが重要であるが、異なるRTPセッションのためのRTCP送信者報告のタイミングが同期されていないことを意味します。したがって、受信機は、セッション間のRTPタイムスタンプを揃えるために、NTPフォーマットクロックにスキューを推定しなければなりません。この推定は、RTP同期実装の重要な一部であり、十分なレポート与えられた高精度に行うことができます。この推定を実行するのに十分なRTCPのSRデータの収集、しかし、いくつかのRTCPの受信が必要な場合があり、さらに同期遅延の増加、報告します。
3. Many media codecs have the notion of periodic access points, such that a newly joined receiver often cannot start decoding a media stream until the packets corresponding to the access point have been received. These access points may be sent less often than RTCP SR packets, and so may be the limiting factor in starting synchronised media playout for late joiners. The RTP extension for unicast-based rapid acquisition of multicast RTP sessions [AVT-ACQUISITION-RTP] may be used to reduce the time taken to receive the access points in some scenarios.
3.多くのメディアコーデックは、アクセスポイントに対応するパケットが受信されるまで、新たに参加し、受信機は、多くの場合、メディアストリームのデコードを開始することができないように、定期的なアクセスポイントの概念を持っています。これらのアクセスポイントは後半ジョイナのために同期したメディア再生を開始するには制限要因をRTCP SRパケットよりも頻繁に送信され、そうかもしれません。マルチキャストRTPセッション[AVT取得-RTP]のユニキャストベースの迅速な取得のためのRTPの拡張は、いくつかのシナリオでは、アクセスポイントを受信するのにかかる時間を短縮するために使用することができます。
These delays are likely an issue for tuning in to an ongoing multicast RTP session, or for video switching MCUs.
これらの遅延は、おそらく継続的なマルチキャストRTPセッションに、またはビデオスイッチングMCU用チューニングの問題です。
Three backwards compatible RTP extensions are defined to reduce the possible synchronisation delay: a reduced initial RTCP interval for SSM senders, a rapid resynchronisation request message, and RTP header extensions that can convey synchronisation metadata in-band.
帯域内同期メタデータを伝えることができるSSM送信者、迅速な再同期要求メッセージ、およびRTPヘッダ拡張の減少初期RTCP間隔：三つの下位互換性RTPの拡張は、可能な同期遅延を低減するために定義されています。
In SSM sessions where the initial synchronisation delay is important, the RTP sender MAY set the delay before sending the initial compound RTCP packet to zero, and send its first RTCP packet immediately upon joining the SSM session. This is purely a local change to the sender that can be implemented as a configurable option. RTP receivers in an SSM session, sending unicast RTCP feedback, MUST NOT send RTCP packets with zero initial delay; the timing rules defined in [RFC5760] apply unchanged to receivers.
初期同期の遅延が重要であるSSMのセッションでは、RTPの送信者はゼロに初期複合RTCPパケットを送信する前に遅延を設定することができ、SSMのセッションに参加するとすぐにその最初のRTCPパケットを送信します。これは純粋に設定可能なオプションとして実装することができ、送信者への局所的な変化です。ユニキャストRTCPフィードバックを送信するSSMセッションでRTP受信機は、ゼロ初期遅延でRTCPパケットを送ってはいけません。 [RFC5760]で定義されたタイミング規則は、受信機に不変の適用します。
The general format of an RTP/AVPF transport layer feedback message is shown in Figure 4 (see [RFC4585] for details).
RTP / AVPFトランスポート層フィードバックメッセージの一般的な形式は（詳細については[RFC4585]を参照）は、図4に示されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT=RTPFB=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 4: RTP/AVPF Transport Layer Feedback Message
図4：RTP / AVPFトランスポート層フィードバックメッセージ
One new feedback message type, RTCP-SR-REQ, is defined with FMT = 5. The Feedback Control Information (FCI) part of the feedback message MUST be empty. The SSRC of the packet sender indicates the member that is unable to synchronise media streams, while the SSRC of the media source indicates the sender of the media it is unable to synchronise. The length MUST equal 2.
一の新しいフィードバックメッセージタイプ、RTCP-SR-REQは、フィードバック制御情報（FCI）FMT = 5で定義されたフィードバック・メッセージの一部は空でなければなりません。メディアソースのSSRCは、同期することができないメディアの送信者を示しているパケットの送信者のSSRCは、メディアストリームを同期させることができないメンバーを示します。長さは2に等しくなければなりません。
If the RTP/AVPF profile [RFC4585] is in use, this feedback message MAY be sent by a receiver to indicate that it's unable to synchronise some media streams, and desires that the media source transmit an RTCP SR packet as soon as possible (within the constraints of the RTCP timing rules for early feedback). When it receives such an indication, a media source that understands the RTCP-SR-REQ packet SHOULD generate an RTCP SR packet as soon as possible while complying with the RTCP early feedback rules. If the use of non-compound RTCP [RFC5506] was previously negotiated, both the feedback request and the RTCP SR response may be sent as non-compound RTCP packets. The RTCP-SR-REQ packet MAY be repeated once per RTCP reporting interval if no RTCP SR packet is forthcoming. The media source may ignore RTCP-SR-REQ packets if its regular schedule for transmission of synchronisation metadata can be expected to allow the receiver to synchronise the media streams within a reasonable time frame.
[RFC4585]が使用されているRTP / AVPFプロファイル場合、このフィードバックメッセージは、いくつかのメディアストリームを同期させることができないということを示すために、受信機によって送信され、メディアソースとすぐ（内できるだけのRTCP SRパケットを送信することを望むかもしれませ早期のフィードバックのためのRTCPタイミング規則の制約）。そのような指示を受信するとRTCP早期フィードバック・ルールに準拠しながら、RTCP-SR-REQパケットを理解メディアソースは、できるだけ早くのRTCP SRパケットを生成すべきです。非複合RTCP [RFC5506]の使用が以前にネゴシエートされた場合、フィードバック要求及びRTCP SRの応答の両方が非複合RTCPパケットとして送信されてもよいです。 RTCP-SR-REQパケットにはRTCPのSRパケットが迫っていない場合は間隔を報告RTCP一回繰り返してもよいです。同期メタデータの伝送のために定期的なスケジュールは、受信機が合理的な時間枠内でメディアストリームを同期させることができるように期待することができる場合、メディアソースは、RTCP-SR-REQパケットを無視することができます。
When using SSM sessions with unicast feedback, it is possible that the feedback target and media source are not co-located. If a feedback target receives an RTCP-SR-REQ feedback message in such a case, the request should be forwarded to the media source. The mechanism to be used for forwarding such requests is not defined here.
ユニキャストフィードバックをSSMセッションを使用する場合、フィードバック目標とメディア・ソースが同じ場所に配置されない可能性があります。フィードバックの目標は、このような場合にRTCP-SR-REQフィードバックメッセージを受信した場合、要求は、メディアソースに転送されなければなりません。このような要求を転送するために使用されるメカニズムは、ここで定義されていません。
If the feedback target provides a network management interface, it might be useful to provide a log of which receivers send RTCP-SR-REQ feedback packets and which do not, since those that do not will see slower stream synchronisation.
フィードバック目標は、ネットワーク管理インターフェースを提供している場合、受信機はRTCP-SR-REQフィードバックパケットを送信し、低速のストリームの同期が表示されますないものから、そうでないのログを提供するのに有用であるかもしれません。
The RTP header extension mechanism defined in [RFC5285] can be adapted to carry an OPTIONAL NTP-format timestamp in RTP data packets. If such a timestamp is included, it MUST correspond to the same time instant as the RTP timestamp in the packet's header, and MUST be derived from the same clock used to generate the NTP-format timestamps included in RTCP SR packets. Provided it has knowledge of the SSRC to CNAME mapping, either from prior receipt of an RTCP CNAME packet or via out-of-band signalling [RFC5576], the receiver can use the information provided as input to the synchronisation algorithm, in exactly the same way as if an additional RTCP SR packet had been received for the flow.
[RFC5285]で定義されたRTPヘッダ拡張機構は、RTPデータパケットにおける任意のNTP形式のタイムスタンプを運ぶように適合させることができます。このようなタイムスタンプが含まれている場合、それは、パケットのヘッダ内のRTPタイムスタンプと同じ時刻に対応しなければならない、と同じクロックから導出されなければならないNTP形式のタイムスタンプを生成するために使用されるのRTCP SRパケットに含まれます。それはRTCP CNAMEパケットの前に受信またはアウトオブバンドシグナリング[RFC5576]のいずれかを介して、SSRC CNAMEへのマッピングの知識を有する設けられ、全く同じで同期アルゴリズムへの入力として提供される情報を、使用することができる受信機追加のRTCP SRパケットが流れのために受信されたかのような方法。
Two variants are defined for this header extension. The first variant extends the RTP header with a 64-bit NTP-format timestamp as defined in [RFC5905]. The second variant carries the lower 24-bit part of the Seconds of a NTP-format timestamp and the 32 bits of the Fraction of a NTP-format timestamp. The formats of the two variants are shown in Figure 5 and Figure 6.
二つの変異体は、このヘッダ拡張のために定義されています。 [RFC5905]で定義されるように、第1変形例は、64ビットのNTP形式タイムスタンプとRTPヘッダを拡張します。第二の変異体は、NTPフォーマットタイムスタンプの秒NTPフォーマットのタイムスタンプの画分の32ビットの下位24ビット部分を運びます。二つの変種のフォーマットは、図5及び図6に示されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
| timestamp |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
| synchronisation source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID-A | L=7 | NTP timestamp format - Seconds (bit 0-23) |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
|NTP Sec.(24-31)| NTP timestamp format - Fraction (bit 0-23) |n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NTP Frc.(24-31)| 0 (pad) | 0 (pad) | 0 (pad) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| payload data |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Variant A/64-Bit NTP RTP Header Extension
図5：変法A / 64ビットのNTP RTPヘッダ拡張
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
| timestamp |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
| synchronisation source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID-B | L=6 | NTP timestamp format - Seconds (bit 8-31) |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| NTP timestamp format - Fraction (bit 0-31) |n
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| payload data |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Variant B/56-Bit NTP RTP Header Extension
図6：変法B / 56ビットのNTP RTPヘッダ拡張
An NTP-format timestamp MAY be included in any RTP packets the sender chooses, but it is RECOMMENDED when performing timestamp-based decoding order recovery for layered codecs transported in multiple RTP flows, as further specified in Section 4.1. This header extension SHOULD be also sent in the RTP packets corresponding to a video random access point, and in the associated audio packets, to allow rapid synchronisation for late joiners in multimedia sessions, and in video switching scenarios.
NTPフォーマットのタイムスタンプは、任意のRTPに含まれるかもしれさらに、セクション4.1で指定されるように送信者が選択したパケットが、複数のRTPで輸送層状コーデックのタイムスタンプベースの復号化順序の回復を実行する際、それが推奨さは、流れます。このヘッダー拡張はまた、マルチメディアセッションにおいて、ビデオスイッチングシナリオで遅くジョイナーための迅速な同期を可能にするために、ビデオ・ランダム・アクセス・ポイントに対応するRTPパケット内および関連するオーディオパケットで送信されるべきです。
Note: The inclusion of an RTP header extension will reduce the efficiency of RTP header compression, if it is used. Furthermore, middleboxes that do not understand the header extensions may remove them or may not update the content according to this memo.
注：それが使用される場合、RTPヘッダ拡張を含めることは、RTPヘッダ圧縮の効率を低下させます。さらに、ヘッダ拡張を理解していないミドルボックスは、それらを削除したり、このメモに応じてコンテンツを更新することはできません。
In all cases, irrespective of whether in-band NTP-format timestamps are included or not, regular RTCP SR packets MUST be sent to provide backwards compatibility with receivers that synchronise RTP flows according to [RFC3550], and robustness in the face of middleboxes (RTP translators) that might strip RTP header extensions. If the Variant B/56-bit NTP RTP header extension is used, RTCP sender reports MUST be used to derive the upper 8 bits of the Seconds for the NTP-format timestamp.
全ての場合において、関係なくインバンドNTPフォーマットのタイムスタンプが含まれているか否かを、定期的なRTCP SRパケットが（中間装置の面に後方RTPは、[RFC3550]に従って流れる同期受信機との互換性、および堅牢性を提供するために送らなければなりませんRTPヘッダ拡張を取り除くかもしれませんRTPトランスレータ）。変法B / 56ビットNTP RTPヘッダ拡張を使用する場合、RTCP送信者レポートは、NTP形式タイムスタンプ秒の上位8ビットを導出するために使用されなければなりません。
When SDP is used, the use of the RTP header extensions defined above MUST be indicated as specified in [RFC5285]. Therefore, the following URIs MUST be used: o The URI used for signalling the use of Variant A/64-bit NTP RTP header extension in SDP is "urn:ietf:params:rtp-hdrext:ntp-64".
SDPを使用する場合、[RFC5285]で指定されるように、上記で定義されたRTPヘッダ拡張を使用することが示されなければなりません。したがって、以下のURIを使用しなければなりません：URIはSDPでは、変異体A / 64ビットのNTP RTPヘッダ拡張の使用をシグナリングするために使用○ "URN：IETF：paramsは：RTP-hdrext：NTP-64" です。
o The URI used for signalling the use of Variant B/56-bit NTP RTP header extension in SDP is "urn:ietf:params:rtp-hdrext:ntp-56".
"IETF：paramsは：RTP-hdrext：NTP-56 URN" O URIはSDPで変法B / 56ビットNTP RTPヘッダ拡張の使用をシグナリングするために使用されます。
The use of these RTP header extensions can greatly improve the user experience in IPTV channel surfing and in some interactive video conferencing scenarios. Network management tools that attempt to monitor the user experience may wish to log which sessions signal and use these extensions.
これらのRTPヘッダの拡張機能の使用が大幅にIPTVチャンネルサーフィン中に、いくつかの対話型ビデオ会議のシナリオでのユーザーエクスペリエンスを向上させることができます。ユーザーエクスペリエンスを監視しようとすると、ネットワーク管理ツールは、セッションの信号を記録し、これらの拡張機能を使用することができます。
Packets in RTP flows are often predictively coded, with a receiver having to arrange the packets into a particular order before it can decode the media data. Depending on the payload format, the decoding order might be explicitly specified as a field in the RTP payload header, or the receiver might decode the packets in order of their RTP timestamps. If a layered encoding is used, where the media data is split across several RTP flows, then it is often necessary to exactly synchronise the RTP flows comprising the different layers before layers other than the base layer can be decoded. Examples of such layered encodings are H.264 SVC in NI-T mode [AVT-RTP-SVC] and MPEG surround multi-channel audio [RFC5691]. As described in Section 2, such synchronisation is possible in RTP, but can be difficult to perform rapidly. Below, we describe how the extensions defined in Section 3.3 can be used to synchronise layered flows, and provide a common timestamp-based decoding order.
RTPフローのパケットは、多くの場合、予測受信機は、それがメディアデータを復号することができる前に、特定の順番にパケットを配置することで、符号化されます。ペイロードフォーマットに応じて、復号化順序を明示的にRTPペイロードヘッダ内のフィールドとして指定されるかもしれない、または受信機は、それらのRTPタイムスタンプの順でパケットを復号するかもしれません。階層符号化が使用される場合、メディアデータは、RTPフローをいくつかに分割されている場合、それはしばしば正確RTPベース層以外の層を復号することができる前に、異なる層を含む流れ、同期させる必要があります。このような層状符号化の例は、NI-TモードでH.264 SVCある[AVT-RTP-SVC]及びMPEGは、マルチチャンネルオーディオ[RFC5691]を囲みます。第2節で説明したように、そのような同期は、RTPに可能であるが、迅速に行うことが困難であることができます。以下、我々は、セクション3.3で定義された拡張は、層状の流れを同期させるために使用することができる方法を説明し、共通タイムスタンプベースの復号順序を提供します。
When a layered, multi-description, or multi-view codec is used, with the different components of the media being transferred on separate RTP flows, the RTP sender SHOULD use periodic synchronous in-band delivery of synchronisation metadata to allow receivers to rapidly and accurately synchronise the separate components of the layered media flow. There are three parts to this:
層状、マルチ説明、またはマルチビューコーデックが使用される場合、メディアの異なる成分が別々のRTP上に転写された状態で流入し、RTP送信機は、受信機が迅速にできるようにするためにインバンド同期メタデータの配信周期的同期を使用する必要があり、正確層状メディアフローの別のコンポーネントを同期させます。これには3つの部分があります。
o The sender must negotiate the use of the RTP header extensions described in Section 3.3, and must periodically and synchronously insert such header extensions into all the RTP flows forming the separate components of the layered, multi-description, or multi-view flow.
O送信者は、セクション3.3で説明RTPヘッダ拡張の使用を交渉しなければならず、定期的に同期RTPが積層、マルチ説明、またはマルチビュー・フローの別の構成要素を形成するフローのすべてに、このようなヘッダ拡張を挿入する必要があります。
o Synchronous insertion requires that the sender insert these RTP header extensions into packets corresponding to exactly the same sampling instant in all the flows. Since the header extensions for each flow are inserted at exactly the same sampling instant, they will have identical NTP-format timestamps, hence allowing receivers to exactly align the RTP timestamps for the component flows. This may require the insertion of extra data packets into some of the component RTP flows, if some component flows contain packets for sampling instants that do not exist in other flows (for example, a layered video codec, where the layers have differing frame rates).
O同期挿入は、送信者がすべてのフローに全く同じサンプリング時点に対応するパケットに、これらのRTPヘッダ拡張を挿入することを必要とします。各フローのためのヘッダ拡張が全く同じサンプリング時点で挿入されるので、したがって受信機が正確コンポーネントフローのためのRTPタイムスタンプを整列することができ、同じNTPフォーマットのタイムスタンプを有するであろう。いくつかのコンポーネントフローが他のフローに存在しないサンプリング時点のパケットを含む場合、これは、RTPフローコンポーネントの一部に余分なデータ・パケットの挿入を必要とするかもしれない（例えば、層は、異なるフレームレートを有する層状のビデオコーデック） 。
o The frequency with which the sender inserts the header extensions will directly correspond to the synchronisation latency, with more frequent insertion leading to higher per-flow overheads, but lower synchronisation latency. It is RECOMMENDED that the sender insert the header extensions synchronously into all component RTP flows at least once per random access point of the media, but they MAY be inserted more often.
O送信者がヘッダの拡張子を挿入する頻度は、直接高いフローごとのオーバヘッドをもたらすより頻繁な挿入が、より低い同期待ち時間で、同期待ち時間に対応することになります。送信者がRTPメディアのランダムアクセスポイントごとに少なくとも一度流れ、すべてのコンポーネントに同期ヘッダ拡張を挿入することを推奨しますが、彼らはより頻繁に挿入されてもよいです。
The sender MUST continue to send periodic RTCP reports including SR packets, and MUST ensure the RTP timestamp to NTP-format timestamp mapping in the RTCP SR packets is consistent with that used in the RTP header extensions. Receivers should use both the information contained in RTCP SR packets and the in-band mapping of RTP and NTP-format timestamps as input to the synchronisation process, but it is RECOMMENDED that receivers sanity check the mappings received and discard outliers, to provide robustness against invalid data (one might think it more likely that the RTCP SR mappings are invalid, since they are sent at irregular times and subject to skew, but the presence of broken RTP translators could also corrupt the timestamps in the RTP header extension; receivers need to cope with both types of failure).
送信者は、SRパケットを含む定期的なRTCPレポートを送信し続けなければならない、とRTPヘッダの拡張機能で使用されるものと一致しているRTCP SRパケットでNTP形式のタイムスタンプへのマッピングRTPタイムスタンプを確保しなければなりません。受信機は、RTCP SRパケットに含まれる情報と同期プロセスへの入力としてRTPとNTPフォーマットタイムスタンプのインバンドマッピングの両方を使用する必要があり、受信機正気は、受信マッピングをチェックし、廃棄外れ値を、に対するロバスト性を提供することが推奨されます無効なデータは、（1、それらが不規則な時間とスキューの対象で送信されますので、RTCPのSRのマッピングは、無効であること、それは可能性が高いと思うかもしれないが、壊れたRTP翻訳者の存在は、RTPヘッダ拡張でも壊れているタイムスタンプができ、受信機のようにする必要があり失敗の両方のタイプ）にも対応。
Once a receiver has synchronised the components of a layered, multi-description, or multi-view flow using the RTP header extensions as described in Section 4.1, it may then derive a decoding order based on the synchronised timestamps as follows (or it may use information in the RTP payload header to derive the decoding order, if present and desired).
セクション4.1で説明したように、受信機が層状、マルチ説明、RTPヘッダ拡張を使用してマルチビュー・フローのコンポーネントを同期したら、次のようには、次に同期タイムスタンプに基づいて復号化順序を導出してもよい（または、使用することができます本そして所望であれば、復号化順序を導出するRTPペイロードヘッダ内の情報）。
There may be explicit dependencies between the component flows of a layered, multi-description, or multi-view flow. For example, it is common for layered flows to be arranged in a hierarchy, where flows from "higher" layers cannot be decoded until the corresponding data in "lower" layer flows has been received and decoded. If such a decoding hierarchy exists, it MUST be signalled out of band, for example using [RFC5583] when SDP signalling is used.
層状、マルチ説明、またはマルチビュー流の成分の流れとの間の明示的な依存関係が存在してもよいです。層状の流れが「下」層流に対応するデータが受信され復号されるまで、「高い」レイヤを復号することができないから流れ階層に配置するために、例えば、それが一般的です。このような復号化階層が存在する場合、それは、SDPシグナリングが使用されている[RFC5583]を使用して、たとえば、帯域外シグナリングされなければなりません。
Each component RTP flow MUST contain packets corresponding to all the sampling instants of the RTP flows on which it depends. If such packets are not naturally present in the RTP flow, the sender MUST generate additional packets as necessary in order to satisfy this rule. The format of these packets depends on the payload format used. For H.264 SVC, the Empty Network Abstraction Layer (NAL) unit packet [AVT-RTP-SVC] should be used. Flows may also include packets corresponding to additional sampling instants that are not present in the flows on which they depend.
各成分のRTPフローは、RTPのすべてのサンプリング時点に対応するパケットを含まなければなりません、それが依存する流れます。そのようなパケットはRTPフロー中に天然に存在しない場合、送信者はこの規則を満たすために必要に応じて追加のパケットを生成しなければなりません。これらのパケットのフォーマットが使用され、ペイロードフォーマットに依存します。 H.264 SVC、空のネットワーク抽象化層（NAL）ユニットパケットの[AVT-RTP-SVC]は使用されるべきです。フローはまた、それらが依存する流れ中に存在しない追加のサンプリング時点に対応するパケットを含むことができます。
The receiver should decode the packets in all the component RTP flows as follows:
受信機は、次のようにRTPフローすべてのコンポーネントにパケットを復号する必要があります。
o For each RTP packet in each flow, use the mapping contained in the RTP header extensions and RTCP SR packets to derive the NTP-format timestamp corresponding to its RTP timestamp.
Oの各フローにおける各RTPパケットに対して、そのRTPタイムスタンプに対応するNTP形式のタイムスタンプを導出するために、RTPヘッダ拡張及びRTCPのSRパケットに含まれるマッピングを使用します。
o Group together RTP data packets from all component flows that have identical calculated NTP-format timestamps.
一緒にOグループ同じ計算されたNTPフォーマットのタイムスタンプを持つすべてのコンポーネントフローからRTPデータパケット。
o Processing groups in order of ascending NTP-format timestamps, decode the RTP packets in each group according to the signalled RTP flow decoding hierarchy. That is, pass the RTP packet data from the flow on which all other flows depend to the decoder first, then that from the next dependent flow, and so on. The decoding order of the RTP flow hierarchy may be indicated by mechanisms defined in [RFC5583] or by some other means.
O NTPフォーマットのタイムスタンプの昇順の順にグループを処理し、シグナリングRTPフロー復号化階層に従って各グループ内のRTPパケットを復号します。すなわち、その次に依存する流れから、というように、他のすべてのフローは第1のデコーダに依存している流れからRTPパケットデータを渡しています。 RTPフロー階層の復号化順序は、[RFC5583]にまたはいくつかの他の手段によって定義されたメカニズムによって示すことができます。
Note that the decoding order will not necessarily match the packet transmission order. The receiver will need to buffer packets for a codec-dependent amount of time in order for all necessary packets to arrive to allow decoding.
復号化順序は、必ずしもパケットの送信順序と一致しないことに注意してください。受信機は、復号化を可能にするために到着するために必要なすべてのパケットのために時間のコーデックに依存する量のパケットをバッファリングする必要があります。
The example shown in Figure 7 refers to three RTP flows A, B, and C, containing a layered, a multi-view, or a multi-description media stream. In the example, the dependency signalling as defined in [RFC5583] indicates that flow A is the lowest RTP flow. Flow B is the next higher RTP flow and depends on A. Flow C is the highest of the three RTP flows and depends on both A and B. A media coding structure is used that results in video access units (i.e., coded video frames) present in higher flows but not present in all lower flows. Flow A has the lowest frame rate. Flows B and C have the same frame rate, which is higher than that of Flow A. The figure shows the full video access units with their corresponding RTP timestamps "(x)". The video access units are already re-ordered according to their RTP sequence number order. The figure indicates the received video access unit part in decoding order within each RTP flow, as well as the associated NTP media timestamps ("TS[..]"). As shown in the figure, these timestamps may be derived using the NTP-format timestamp provided in the RTCP sender reports as indicated by the timestamp in "{x}", or derived directly from the NTP timestamp contained in the RTP header extensions as indicated by the timestamp in "<x>". Note that the timestamps are not in increasing order since, in this example, the decoding order is different from the output/presentation order.
図7に示す例では、3つにRTPが積層、マルチビュー、またはマルチ記述メディアストリームを含む、A、B、及びCを流れる指します。一例では、[RFC5583]で定義されるようにシグナリング依存フローAは最小RTPフローであることを示しています。フローBは、次に高いRTPフローであり、フローC三のRTPフローの最も高いA.に依存し、使用されている構造をコーディング両方AとB Aメディアに依存するビデオアクセスユニットにおける結果（すなわち、符号化されたビデオ・フレーム）高いフローの存在が、すべて下のフローに存在しません。フローAは、最低フレームレートを持っています。 B及びCは、「（X）」の図は、それらの対応するRTPタイムスタンプとの完全なビデオアクセスユニットを示すフローA.より高い同一のフレームレートを有し流れます。ビデオアクセスユニットは、すでに彼らのRTPシーケンス番号順に従って再順序付けされています。図は、各RTPフロー内復号順序、ならびに関連NTPメディアタイムスタンプ（「TS [..]」）で受信されたビデオアクセスユニットの一部を示します。同図に示すように、これらのタイムスタンプは「{X}」のタイムスタンプによって示されるようにRTCP送信者レポートに設けられたNTP形式のタイムスタンプを使用して誘導される、または示されるようにRTPヘッダ拡張内に含まれるNTPタイムスタンプから直接導出することができます「<X>」のタイムスタンプで。タイムスタンプは、以降昇順でないことに注意してください、この例では、復号化順序は出力/提示順序は異なっています。
The decoding order recovery process first advances to the video access unit parts associated with the first available synchronous insertion of the NTP timestamp into RTP header extensions at NTP media timestamp TS=[8]. The receiver starts in the highest RTP flow C and removes/ignores all preceding video access unit parts (in decoding order) to video access unit parts with TS=[8] in each of the de-jittering buffers of RTP flows A, B, and C. Then, starting from flow C, the first media timestamp available in decoding order (TS=[8]) is selected, and video access unit parts starting from RTP flow A, and flows B and C are placed in order of the RTP flow dependency as indicated by mechanisms defined in [RFC5583] (in the example for TS[8]: first flow B and then flow C into the video access unit AU(TS[8]) associated with NTP media timestamp TS=[8]). Then the next media timestamp TS=[6] (RTP timestamp=(4)) in order of appearance in the highest RTP flow C is processed, and the process described above is repeated. Note that there may be video access units with no video access unit parts present, e.g., in the lowest RTP flow A (see, e.g., TS=[5]). The decoding order recovery process could also be started after an RTP sender report containing the mapping between the RTP timestamp and the NTP-format timestamp (indicated as timestamps "(x){y}") has been received, assuming that there is no clock skew in the source used for the NTP-format timestamp generation.
復号化順序NTPメディアタイムスタンプTS =でRTPヘッダ拡張内にNTPタイムスタンプの最初の利用可能な同期の挿入に関連するビデオアクセスユニットの部品に回復処理最初の進歩[8]。受信機は、最高のRTPフローCで開始及び/ TS =有するビデオアクセスユニット部に先行するすべてのビデオアクセスユニット部（復号順で）を無視除去する[8] RTPのデジッタバッファのそれぞれにおいて、Bを流れます及びC.そして、フローCから出発して、復号順で利用可能な最初のメディアのタイムスタンプ（TS = [8]）を選択し、ビデオアクセスユニットの部品の順に配置されているRTPフローAから出発して、B及びCを流れますRTPフロー依存性[8]のTSのための例では（[RFC5583]で定義されたメカニズムで示すように第一流量Bとし、[8]）NTPメディアタイムスタンプTS =関連付けられたビデオアクセスユニットAU（TSにCを流れる[8 ]）。次いで、次のメディアのタイムスタンプTS = [6]（RTPタイムスタンプ=（4））最高RTPフローCにおける出現の順序で処理され、上述した処理が繰り返されます。最小RTPフローAに、例えば、存在しないビデオアクセスユニット部とビデオアクセスユニットが存在し得ることに留意されたい（参照、例えば、TS = [5]）。復号化順序の回復プロセスは、何クロックが存在しないと仮定すると、RTPタイムスタンプと、受信されたNTPフォーマットタイムスタンプ（タイムスタンプとして示さ「（X）{Y}」）との間のマッピングを含むRTP送信者レポート後に開始することができますNTPフォーマットのタイムスタンプ生成のために使用されるソースのスキュー。
C:-(0)----(2)----(7)<8>--(5)----(4)----(6)-----(11)----(9){10}-
| | | | | | | |
B:-(3)----(5)---(10)<8>--(8)----(7)----(9){7}--(14)----(12)----
| | | |
A:---------------(3)<8>--(1)-------------------(7){12}-(5)-----
---------------------------------------decoding/transmission order->
TS:[1] [3] [8]=<8> [6] [5] [7] [12] [10]
Key:
キー：
A, B, C - RTP flows
、B、C - RTPフロー
Integer values in "()" - video access unit with its RTP timestamp as indicated in its RTP packet.
そのRTPパケットに示すように、そのRTPタイムスタンプを有するビデオアクセスユニット - の整数値「（）」。
"|" - indicates the corresponding parts of the same video access unit AU(TS[..]) in the RTP flows.
"|" - 流れるRTPに同じビデオアクセスユニットAU（TS [..]）の対応する部分を示しています。
Integer values in "[]" - NTP media timestamp TS, sampling time as derived from the NTP timestamp associated with the video access unit AU(TS[..]), consisting of video access unit parts in the flows above.
NTPメディアタイムスタンプTS、ビデオアクセスユニットAU（TS [..]）に関連付けられたNTPタイムスタンプから導出される時間サンプリング、上記フローのビデオアクセスユニット部からなる - 「[]」の整数値。
Integer values in "<>" - NTP media timestamp TS as directly taken from the NTP RTP header extensions.
整数値「<>」 - として直接NTP RTPヘッダ拡張から採取されたNTPメディアタイムスタンプTS。
Integer values in "{}" - NTP media timestamp TS as provided in the RTCP sender reports.
「{}」の整数値 - NTPメディアタイムスタンプTS RTCP送信者レポートで提供されます。
Figure 7: Example of a Layered RTP Stream
図7：層状RTPストリームの例
The security considerations of the RTP specification [RFC3550], the extended RTP profile for RTCP-based feedback [RFC4585], and the general mechanism for RTP header extensions [RFC5285] apply.
RTP仕様[RFC3550]、RTCPベースのフィードバックのための拡張RTPプロファイル[RFC4585]、およびRTPヘッダ拡張のための一般的なメカニズム[RFC5285]のセキュリティ上の考慮事項が当てはまります。
The RTP header extensions defined in Section 3.3 include an NTP-format timestamp. When an RTP session using this header extension is protected by the Secure RTP (SRTP) framework [RFC3711], that header extension is not part of the encrypted portion of the RTP data packets or RTCP control packets; however, these NTP-format timestamps are encrypted when using SRTP without this header extension. This is a minor information leak, but one that is not believed to be significant. The inclusion of this header extension will also reduce the efficiency of RTP header compression, if it is used. Furthermore, middleboxes that do not understand the header extensions may remove them or may not update the content according to this memo.
セクション3.3で定義されたRTPヘッダ拡張は、NTP形式タイムスタンプを含みます。このヘッダ拡張を使用して、RTPセッションがセキュアRTP（SRTP）フレームワーク[RFC3711]によって保護されている場合、そのヘッダ拡張は、RTPデータパケット又はRTCP制御パケットの暗号化部分の一部ではありません。このヘッダー拡張なしSRTPを使用した場合しかし、これらのNTPフォーマットのタイムスタンプは、暗号化されています。これは、マイナーな情報漏洩が、重要であるとは考えられないものです。それが使用される場合、このヘッダ拡張を含めることはまた、RTPヘッダ圧縮の効率を低下させます。さらに、ヘッダ拡張を理解していないミドルボックスは、それらを削除したり、このメモに応じてコンテンツを更新することはできません。
The IANA has registered one new value in the table of FMT Values for RTPFB Payload Types [RFC4585] as follows:
次のようにIANAはRTPFBペイロードタイプのためのFMT値[RFC4585]のテーブル内の1つの新しい値を登録しています：
Name: RTCP-SR-REQ Long name: RTCP Rapid Resynchronisation Request Value: 5 Reference: RFC 6051
名前：RTCP-SR-REQロングネーム：RTCP迅速な再同期化要求値：5参考：RFC 6051
The IANA has also registered two new RTP Compact Header Extensions [RFC5285], according to the following:
IANAは、次のに従って、二つの新しいRTPコンパクトヘッダー拡張[RFC5285]を登録しています：
Extension URI: urn:ietf:params:rtp-hdrext:ntp-64 Description: Synchronisation metadata: 64-bit timestamp format Contact: Thomas Schierl <ts@thomas-schierl.de> IETF Audio/Video Transport Working Group Reference: RFC 6051
拡張URI：URN：IETF：のparams：RTP-hdrext：NTP-64説明：同期メタデータ：64ビットのタイムスタンプ形式の連絡先：トーマスSchierl <ts@thomas-schierl.de> IETFオーディオ/ビデオ輸送ワーキンググループ参考：RFC 6051
Extension URI: urn:ietf:params:rtp-hdrext:ntp-56 Description: Synchronisation metadata: 56-bit timestamp format Contact: Thomas Schierl <ts@thomas-schierl.de> IETF Audio/Video Transport Working Group Reference: RFC 6051
拡張URI：URN：IETF：のparams：RTP-hdrext：NTP-56説明：同期メタデータ：56ビットのタイムスタンプ形式の連絡先：トーマスSchierl <ts@thomas-schierl.de> IETFオーディオ/ビデオ輸送ワーキンググループ参考：RFC 6051
This memo has benefited from discussions with numerous members of the IETF AVT working group, including Jonathan Lennox, Magnus Westerlund, Randell Jesup, Gerard Babonneau, Ingemar Johansson, Ali C. Begen, Ye-Kui Wang, Roni Even, Michael Dolan, Art Allison, and Stefan Doehla. The RTP header extension format of Variant A in Section 3.3 was suggested by Dave Singer, matching a similar mechanism specified by the Internet Streaming Media Alliance (ISMA).
このメモはジョナサン・レノックス、マグヌスウェスター、ランデルジェサップ、ジェラールBabonneau、インゲマル・ヨハンソン、アリC. Begen、イェ・クイ王、ロニでも、マイケル・ドラン、アートアリソン含むIETF AVTワーキンググループの多数のメンバー、との議論の恩恵を受けています、そしてステファンDoehla。 3.3節では、変異体AのRTPヘッダ拡張フォーマットは、インターネットストリーミングメディアアライアンス（ISMA）によって指定された同様の機構に一致する、デイブ歌手によって示唆されました。
[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月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ「ベースのフィードバック（RTP / AVPF）リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル」、RFC 4585、2006年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月。
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009.
[RFC5506]ヨハンソン、I.およびM.ウェスター、「縮小リアルタイムトランスポート制御プロトコル（RTCP）のサポート：機会と帰結」、RFC 5506、2009年4月。
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, July 2009.
[RFC5583] Schierl、T.とS.ベンゲル監督、 "セッション記述プロトコルにおけるシグナリングメディアのデコード依存（SDP）"、RFC 5583、2009年7月。
[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]オット、J.、チェスターフィールド、J.、およびE.学生、 "ユニキャストフィードバックを有する単一ソースマルチキャストセッションのためにRTP制御プロトコル（RTCP）拡張"、RFC 5760、2010年2月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]ミルズ、D.、マーティン、J.、バーバンク、J.、およびW. Kasch、 "ネットワークタイムプロトコルバージョン4：プロトコルとアルゴリズムの仕様"、RFC 5905、2010年6月。
[AVT-ACQUISITION-RTP] VerSteeg, B., Begen, A., VanCaenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", Work in Progress, October 2010.
[AVT取得-RTP] VerSteeg、B.、Begen、A.、VanCaenegem、T.、およびZ. Vaxの、 "マルチキャストRTPセッションのユニキャストベースの高速取得"、進歩、2010年10月ワーク。
[AVT-RTP-SVC] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for SVC Video Coding", Work in Progress, October 2010.
[AVT-RTP-SVC]ウェンガー、S.、王、Y.、Schierl、T.、およびA. Eleftheriadis、 "コーディングSVCビデオのためのRTPペイロードフォーマット"、進歩、2010年10月の作業。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556] Casner、S.、 "セッション記述プロトコル（SDP）RTP制御プロトコル（RTCP）帯域の帯域幅修飾子"、RFC 3556、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]ウェスター、M.とS.ベンゲル監督、 "RTPトポロジ"、RFC 5117、2008年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[RFC5576]レノックス、J.、オット、J.、およびT. Schierl、RFC 5576、2009年6月 "ソース固有のメディアセッション記述プロトコル（SDP）の属性"。
[RFC5691] de Bont, F., Doehla, S., Schmidt, M., and R. Sperschneider, "RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio", RFC 5691, October 2009.
[RFC5691]ボン、F.、Doehla、S.、シュミット、M.、およびR. Sperschneider、 "MPEGサラウンドマルチチャンネルオーディオと基本ストリームのためのRTPペイロードフォーマット"、RFC 5691、2009年10月デ。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]マグリュー、D.およびE.レスコラ、「データグラムトランスポート層セキュリティ（DTLS）セキュアリアルタイム転送プロトコル（SRTP）のための鍵を確立するための拡張」、RFC 5764、2010年5月。
[ZRTP] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", Work in Progress, June 2010.
[ZRTP]ツィンマーマン、P.、ジョンストン、A.、エド、およびJ.カラス、。 "ZRTP：ユニキャストセキュアRTPのためのメディアパス鍵合意"、進歩、2010年6月での作業。
Authors' Addresses
著者のアドレス
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ UK
コンピューティング科学グラスゴーG12 8QQ英国のグラスゴー大学のコリン・パーキンス大学
EMail: csp@csperkins.org
メールアドレス：csp@csperkins.org
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany
トーマスSchierlフラウンホーファーHHI Einsteinufer 37 D-10587ベルリンドイツ
Phone: +49-30-31002-227 EMail: ts@thomas-schierl.de
電話：+ 49-30-31002-227 Eメール：ts@thomas-schierl.de