[要約] RFC 6051は、RTPフローの迅速な同期化に関する要件と手法を提供する。目的は、異なるRTPフロー間の時刻同期を改善し、音声やビデオの再生品質を向上させることである。
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
RTPフローの迅速な同期
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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]に含まれる情報を使用して達成されます。これらは定期的に送信され、マルチメディアセッションのコンポーネントは、各RTPフローに対して十分なRTCP SRパケットが受信されるまで同期することはできません。レシーバーは各RTPフローに使用されるメディアクロック間のマッピングを確立できます（NTP--）形式）同期を確立するために使用される参照クロック。
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同期メカニズムへの3つの後方互換拡張機能が提案されています。
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 RTCP送信タイミングルールは、ソース固有のマルチキャスト（SSM）送信者のために緩和され、大規模な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）[RFC4585）の拡張RTPプロファイルの拡張は、レシーバーが追加のRTCP SRパケットを要求し、RTPフローを同期するために必要なメタデータを提供するように定義されます。これにより、大規模な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 2つの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フローは、送信者によって生成されたRTCP SRパケット（特にNTPフォーマットタイムスタンプとRTPタイムスタンプ）に含まれる情報に基づいて、受信機によって同期されます。同期には、共通の参照クロックを使用して、同期する一連のフローでNTP形式のタイムスタンプを生成する必要があります（つまり、いくつかのRTPフローを同期する場合、各フローのRTPタイムスタンプは別々のフローから派生し、メディア固有のメディア特異的、時計、しかし同期するすべてのフローのRTCP SRパケットのNTP形式のタイムスタンプは、同じクロックからサンプリングする必要があります）。より速く、より正確な同期を実現するには、送信者と受信者が一般的なプロパティ、特にタイムベースを備えた同期された一般的なNTPフォーマット参照クロックを使用することをさらにお勧めします（可能であれば、RTPが制御環境の外で使用される場合にこれがしばしば不可能であることを認識してください）;その共通の参照クロックとそのプロパティが通知および分布される手段は、このメモの範囲外です。
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セッションで送信され、RTCPソースに含まれる標準的なエンドポイント識別子（CNAME）アイテムによって同期するRTP Associates RTPフローが送信されます。説明（SDES）送信者によって生成された、またはバンドから合図されたパケット[RFC5576]。階層化されたメディアの場合、異なるレイヤーを異なるRTPセッションで送信するか、単一のRTPセッション内で異なる同期ソース（SSRC）値を使用できます。どちらの場合も、CNAMEを使用して、同期するフローを識別します。したがって、同期を確保するには、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 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).
これらの定期的な化合物RTCPパケットのタイミングは、各RTPセッションのメンバーの数、データを送信しているものの割合、セッション帯域幅、構成されたRTCP帯域幅画分、およびセッションがマルチキャストまたはユニキャストであるかどうかに依存します（RFCを参照3550、セクション6.2詳細については）。要約すると、RTCP制御トラフィックには、セッション帯域幅の5％（一般に5％）が割り当てられ、その割合の分数はアクティブなRTP送信者に割り当てられ、受信者は残りの3四半期を使用します（これらの画分は、セッション説明プロトコル（SDP）[RFC3556]）。RTPセッションの各メンバーは、セッションがマルチキャストであろうとユニキャストであろうと、これらの画分に基づいてRTCPレポート間隔を導き出します。次に、レポート間隔ごとに複合RTCPパケットを平均して1回送信します（実際のパケット送信時間は、レポートの同期を避けるために、レポート間隔の範囲[0.5 ... 1.5]の範囲でランダム化されます）。
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]。また、ユニキャストセッションの場合、「初期化合物RTCPパケットを送信する前の遅延はゼロになる可能性があります」[RFC3550]。さらに、ユニキャストセッションの場合、およびマルチキャストセッションのアクティブな送信者の場合、固定最小レポート間隔は「360をキロビット/秒のセッション帯域幅で割った360に拡大することができます。/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パケット（RTCP SRパケットとCNAMEアイテムを備えたRTCP SDESパケットを含む）を送信する必要があります。個々のRTPセッションは、NATトラバーサル（例：[RFC5245]）および/またはセキュリティキーイング（例：[RFC5764]、[ZRTP]）の帯域内シグナリングが終了すると結合されると考えられており、メディアパスは開かれています。。これは、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.
マルチキャストグループに送信する場合、360秒の最小RTCP報告間隔を1秒あたりのキロビッツのセッション帯域幅で割った[RFC3550]を使用する必要があります。また、いつものように、最初の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つの送信者との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.
これらの数値は、平均RTCPパケットサイズが70オクテットを想定して、単一のアクティブ送信者を備えたソース固有のマルチキャストチャネルを想定しています。これらの間隔では、過度の遅延なしに唇の同期に十分であるが、層状のビデオストリームの部分を同期するにはあまりにも多くの遅延があると見なされる場合があります。
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レポート間隔のより多くのばらつきを引き起こします。これを図2と図3に示します。これは、図1で説明したSSMセッションと同じセッション帯域幅とレシーバー集団のRTCP報告間隔を示していますが、それぞれ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.
マルチユニカストを使用して実装したマルチセンダーグループは、中央RTP翻訳者（[RFC5117]の用語のトポ翻訳者）またはミキサー（トポミキサー）、またはビデオスイッチングMCU（Topo-video-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パケットを送信しないという理論的根拠は、多数のメンバーが同時にグループに参加したときにリクエストの崩壊を避けることです（「フラッシュクラウド」）。これはSSM送信者にとっては問題ではありません。せいぜい1つの送信者がいる可能性があるため、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では、新しいRTP/AVPFトランスポートレイヤーフィードバックメッセージを定義して、RTCP SRを生成することを要求し、パケット損失の場合に急速な再同期を可能にします。
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.
1. RTCP SRパケットの迅速な送信を可能にする最適化の多くは、セッションの開始時にのみ適用されます。これは、新しい参加者が、メディアストリームを同期するために必要なデータを受信する前に、各セッションの完全な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タイミングルールの性質から生じます。レポート間隔ごとにパケットが平均して1回生成されますが、レポートの同期を避けるために正確な送信時間がランダム化されています。これは、マルチキャストセッションでのネットワーク輻輳を回避するために重要ですが、さまざまな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-Acquisition-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.
可能な同期遅延を減らすために3つの後方互換RTP拡張機能が定義されています。SSM送信者の初期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パケットを送信する場合があります。これは、構成可能なオプションとして実装できる送信者への局所的な変更です。SSMセッションのRTPレシーバーは、ユニキャストRTCPフィードバックを送信して、初期遅延がゼロでRTCPパケットを送信してはなりません。[RFC5760]で定義されているタイミングルールは、レシーバーに変更されていません。
The general format of an RTP/AVPF transport layer feedback message is shown in Figure 4 (see [RFC4585] for details).
RTP/AVPFトランスポートレイヤーフィードバックメッセージの一般的な形式を図4に示します（詳細については[RFC4585を参照]）。
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.
1つの新しいフィードバックメッセージタイプ、RTCP-SR-REQは、FMT = 5で定義されます。フィードバックコントロール情報（FCI）フィードバックメッセージの部分は空でなければなりません。パケット送信者の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.
RTP/AVPFプロファイル[RFC4585]が使用されている場合、このフィードバックメッセージは受信機によって送信されて、メディアストリームを同期できないことを示す場合があり、メディアソースがRTCP SRパケットをできるだけ早く送信することを望んでいます。早期フィードバックのためのRTCPタイミングルールの制約）。このような表示を受け取ると、RTCPの早期フィードバックルールを順守しながら、RTCP-SR-REQパケットを理解しているメディアソースは、できるだけ早くRTCP SRパケットを生成するはずです。非コンパウンドRTCP [RFC5506]の使用が以前に交渉された場合、フィードバックリクエストとRTCP SR応答の両方が非コンパウンドRTCPパケットとして送信される場合があります。RTCP SRパケットが近づいていない場合、RTCP-SR-REQパケットは、RTCPレポート間隔ごとに1回繰り返される場合があります。メディアソースは、同期メタデータの送信の定期的なスケジュールがレシーバーが合理的な時間枠内でメディアストリームを同期することができると予想される場合、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タイムスタンプと同じ時間に対応する必要があり、RTCP SRパケットに含まれるNTPフォーマットタイムスタンプを生成するために使用される同じクロックから派生する必要があります。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.
このヘッダー拡張機能の2つのバリアントが定義されています。最初のバリアントは、[RFC5905]で定義されているように、64ビットNTPフォーマットタイムスタンプでRTPヘッダーを拡張します。2番目のバリアントには、NTPフォーマットタイムスタンプの数秒の24ビットの下部部分と、NTPフォーマットタイムスタンプの割合の32ビットが含まれます。2つのバリアントの形式を図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翻訳者）RTPヘッダー拡張機能を削除する可能性があります。バリアントB/56ビットNTP RTPヘッダー拡張機能を使用する場合、NTPフォーマットタイムスタンプの秒の上部8ビットを導出するためにRTCP送信者レポートを使用する必要があります。
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を使用する場合、上記のRTPヘッダー拡張機能の使用は、[RFC5285]で指定されているように示す必要があります。したがって、次のURIを使用する必要があります。OSDPでのバリアントA/64ビットNTP RTPヘッダー拡張の使用を知らせるために使用されるURIは、「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".
o SDPでのバリアントb/56ビットNTP RTPヘッダー拡張の使用を知らせるために使用されるURIは、「urn：ietf：params：rtp-hdrext：ntp-56」です。
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モード[AVT-RTP-SVC]およびMPEGサラウンドマルチチャネルオーディオ[RFC5691]のH.264 SVCです。セクション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ヘッダー拡張機能を、すべてのフローでまったく同じサンプリングインスタントに対応するパケットに挿入する必要があります。各フローのヘッダー拡張機能はまったく同じサンプリング瞬間に挿入されるため、同一のNTPフォーマットタイムスタンプがあるため、コンポーネントフローのRTPタイムスタンプを正確に整列できます。これには、一部のコンポーネントフローが他のフローに存在しないサンプリングインスタント用のパケットが含まれている場合、一部のコンポーネント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 送信者がヘッダー拡張機能を挿入する周波数は、同期のレイテンシに直接対応し、より頻繁に挿入することで、フローあたりのオーバーヘッドが高くなりますが、同期レイテンシが低くなります。送信者は、メディアのランダムアクセスポイントごとに少なくとも1回、すべてのコンポーネント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-FormatのタイムスタンプからRTCP SRパケットのNTPフォーマットタイムスタンプマッピングを確認する必要があります。受信者は、RTCP SRパケットに含まれる情報と、RTPおよびNTPフォーマットタイムスタンプのインバンドマッピングの両方を同期プロセスへの入力として使用する必要がありますが、受信者の正気は、受信したマッピングを確認し、外れ値を破棄して、堅牢性を提供することをお勧めします。無効なデータ（RTCP SRマッピングは不規則な時間に送信され、スキューの影響を受けるため、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ヘッダー拡張機能とRTCP SRパケットに含まれるマッピングを使用して、RTPタイムスタンプに対応するNTPフォーマットタイムスタンプを導出します。
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パケットをデコードします。つまり、他のすべてのフローが最初にデコーダーに依存するフローから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フローであり、Aに依存します。フローCは3つのRTPフローの中で最も高く、AとBの両方に依存します。より高い流れに存在しますが、すべての低いフローには存在しません。フローAのフレームレートは最低です。フローBとCのフレームレートは同じです。これは、フローAのフレームレートよりも高いです。図は、対応するRTPタイムスタンプ（x）」を備えた完全なビデオアクセスユニットを示しています。ビデオアクセスユニットは、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 = [8]でNTPタイムスタンプのRTPヘッダー拡張機能への最初の使用可能な同期挿入に関連付けられたビデオアクセスユニットパーツに進みます。受信機は最高のRTPフローCで起動し、RTPフローA、B、b、b、b、de-jitteringバッファーの各除去バッファーで、TS = [8]を備えたビデオアクセスユニットパーツへのすべての前のビデオアクセスユニットパーツ（デコード順）を削除/無視します。C.次に、フローCから始めて、デコード順（TS = [8]）で使用可能な最初のメディアタイムスタンプが選択され、RTPフローAから始まるビデオアクセスユニットパーツ、およびフローBとCが順番に配置されます。[RFC5583]で定義されたメカニズムによって示されるRTPフロー依存性（TS [8]の例では、最初にフローBを使用し、次にNTPメディアタイムスタンプTS = [8に関連付けられたビデオアクセスユニットAU（TS [8]）に流れます。]）。次に、次のメディアタイムスタンプTS = [6]（RTPタイムスタンプ=（4））が最も高いRTPフローCの外観の順に処理され、上記のプロセスが繰り返されます。ビデオアクセスユニットの部品が存在しないビデオアクセスユニットが存在する可能性があることに注意してください。RTPタイムスタンプとNTPフォーマットタイムスタンプの間のマッピングを含むRTP送信者レポート（タイムスタンプとして示される「（x）{y} "）が受信されたと仮定して、時計がないと仮定して、デコード順序回復プロセスが開始される可能性があります。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
A、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.
RTCP送信者レポートで提供されている「{}」-NTPメディアタイムスタンプTSの整数値。
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セッションがSecure RTP（SRTP）フレームワーク[RFC3711]によって保護されている場合、そのヘッダー拡張はRTPデータパケットまたはRTCP制御パケットの暗号化された部分の一部ではありません。ただし、これらのNTPフォーマットタイムスタンプは、このヘッダー拡張機能なしでSRTPを使用する場合に暗号化されます。これは軽微な情報漏れですが、重要であるとは考えられていません。このヘッダー拡張機能を含めると、使用される場合、RTPヘッダー圧縮の効率も低下します。さらに、ヘッダー拡張機能を理解していないミドルボックスは、それらを削除するか、このメモに従ってコンテンツを更新しない場合があります。
The IANA has registered one new value in the table of FMT Values for RTPFB Payload Types [RFC4585] as follows:
IANAは、次のように、RTPFBペイロードタイプ[RFC4585]のFMT値の表に1つの新しい値を登録しています。
Name: RTCP-SR-REQ Long name: RTCP Rapid Resynchronisation Request Value: 5 Reference: RFC 6051
名前：RTCP-SR-REQ LONG NAME：RTCP Rapid Resynchronation Request Value：5リファレンス：RFC 6051
The IANA has also registered two new RTP Compact Header Extensions [RFC5285], according to the following:
IANAはまた、次の2つの新しい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
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
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).
このメモは、Jonathan Lennox、Magnus Westerlund、Randell Jesup、Gerard Babonneau、Ingemar Johansson、Ali C. Begen、Ye-Kui Wang、Ye-Kui Wang、Roni Evever、Michael Dolan、Art Allison、Art Allisonisonなど、IETF AVTワーキンググループの多数のメンバーとの議論の恩恵を受けています。、およびStefan Doehla。セクション3.3のバリアントAのRTPヘッダー拡張形式は、Dave Singerによって提案され、インターネットストリーミングメディアアライアンス（ISMA）によって指定された同様のメカニズムと一致しました。
[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月。
[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] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張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.デシネニ、「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] Johansson、I。およびM. Westerlund、「減少リアルタイム輸送制御プロトコル（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. Wenger、「セッション説明プロトコル（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] Ott、J.、Chesterfield、J。、およびE. Schooler、「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] Mills、D.、Martin、J.、Burbank、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-Acquisition-Rtp] Versteeg、B.、Begen、A.、Vancaenegem、T.、およびZ. Vax、「Unicastベースのマルチキャスト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] Wenger、S.、Wang、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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117] Westerlund、M。およびS. Wenger、「RTP Topologies」、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] Rosenberg、J。、「Interactive Connectivity Indecivity（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] Lennox、J.、Ott、J。、およびT. Schierl、「セッション説明プロトコル（SDP）のソース固有のメディア属性」、RFC 5576、2009年6月。
[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] de Bont、F.、Doehla、S.、Schmidt、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] McGrew、D。およびE. Rescorla、「Datagram Transport Layer Security（DTLS）拡張機能を確立するためのextension」、安全なリアルタイム輸送プロトコル（SRTP）のキーを確立する」、2010年5月、RFC 5764。
[ZRTP] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", Work in Progress, June 2010.
[Zrtp] Zimmermann、P.、Johnston、A.、ed。、およびJ. Callas、「Zrtp：Unicast Secure RTPのMedia Path Key契約」、2010年6月の作業。
Authors' Addresses
著者のアドレス
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ UK
コリンパーキンス大学コンピューティング科学大学グラスゴーG12 8QQ UK
EMail: csp@csperkins.org
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587ベルリンドイツ
Phone: +49-30-31002-227
EMail: ts@thomas-schierl.de