メインコンテンツまでスキップ

1. はじめに

マルチメディアコンテンツの配信に RTP を使用する場合、プレゼンテーションのオーディオコンポーネントとビデオコンポーネントの再生を同期させる必要があることがよくあります。これは、RTP 制御プロトコル (RTCP) 送信者レポート (SR) パケット [RFC3550] に含まれる情報を使用して実現されます。これらは定期的に送信され、マルチメディアセッションのコンポーネントは、各 RTP フローに対して十分な RTCP SR パケットを受信し、受信者が各 RTP フローに使用されるメディアクロックと、同期を確立するために使用される共通の (NTP 形式の) 参照クロックとの間のマッピングを確立できるまで同期できません。

最近、この同期遅延が、階層型またはマルチ記述ビデオコーディングを使用するアプリケーションなどの一部のアプリにとって問題であるとの懸念が表明されています。このメモは、RTP 同期の動作をレビューし、予想される同期遅延について説明します。基本的な RTP 同期メカニズムに対する 3 つのバックワードコンパチブルな拡張機能が提案されています。

  • 大規模な SSM グループの初期同期レイテンシを短縮するために、ソース固有マルチキャスト (SSM) 送信者の RTCP 送信タイミングルールを緩和します。セクション 3.1 を参照。

  • 受信者が追加の RTCP SR パケットをリクエストできるように、RTCP ベースのフィードバック用の拡張 RTP プロファイル (RTP/AVPF) [RFC4585] の機能強化を定義し、RTP フローの同期に必要なメタデータを提供します。これにより、RTCP レポート間隔が長いセッションに参加する場合、パケット損失が発生した場合、またはビデオスイッチング MCU が採用されている場合の同期遅延を短縮できます。セクション 3.2 を参照。

  • RTP データパケットとインバンドで同期メタデータを配信するための 2 つの RTP ヘッダー拡張を定義します。これらの拡張機能は、RTP データパケットと整合した同期メタデータを提供するため、同期前にフロー間のクロックスキューを推定する必要がなくなります。また、フローを同期できる前に RTCP SR パケットを受信する必要性を減らすこともできますが、RTCP の必要性がなくなるわけではありません。セクション 3.3 を参照。

これらの拡張機能の直接的なユースケースは、階層型ビデオセッション (例: 非インターリーブタイムスタンプベース (NI-T) モード [AVT-RTP-SVC] の H.264/SVC (Scalable Video Coding) セッション) に参加する際の同期による遅延を短縮することです。ただし、拡張機能は階層型コーディングに固有のものではなく、同期遅延が問題となるあらゆる環境で使用できます。

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC 2119 [RFC2119] の記述に従って解釈されるものとします。

2. RTP フローの同期

RTP フローは、送信者によって生成された RTCP SR パケットに含まれる情報 (具体的には NTP 形式のタイムスタンプと RTP タイムスタンプ) に基づいて、受信者によって同期されます。同期には、同期される一連のフローで NTP 形式のタイムスタンプを生成するために共通のリファレンスクロックを使用しなければなりません (MUST) (つまり、複数の RTP フローを同期する場合、各フローの RTP タイムスタンプは個別のメディア固有のクロックから派生しますが、同期されるすべてのフローの RTCP SR パケット内の NTP 形式のタイムスタンプは、同じクロックからサンプリングされなければなりません (MUST))。より高速で正確な同期を実現するために、送信者と受信者は、可能な限り共通のプロパティ、特にタイムベース (timebase) を持つ同期された共通の NTP 形式のリファレンスクロックを使用することがさらに推奨されます (RECOMMENDED) (RTP が制御された環境以外で使用される場合、これが不可能な場合が多いことを認識しています)。その共通のリファレンスクロックとそのプロパティがシグナリングおよび配信される手段は、このメモの範囲外です。

マルチメディアセッションでは、メディアの各タイプ (例: オーディオまたはビデオ) は個別の RTP セッションで送信され、受信者は、送信者によって生成されるか、またはアウトオブバンドでシグナリングされる RTCP ソース記述 (SDES) パケットに含まれる標準のエンドポイント識別子 (CNAME) アイテムによって、同期される RTP フローを関連付けます [RFC5576]。階層型メディアの場合、異なるレイヤーを異なる RTP セッションで送信したり、単一の RTP セッション内で異なる同期ソース (SSRC) 値を使用して送信したりできます。どちらの場合も、CNAME は同期されるフローを識別するために使用されます。同期を確実にするために、RTP 送信者は、RFC 3550 [RFC3550] のセクション 6 に従って、定期的に複合 RTCP パケットを送信しなければなりません (MUST)。

これらの定期的な複合 RTCP パケットのタイミングは、各 RTP セッションのメンバー数、データを送信しているメンバーの割合、セッション帯域幅、設定された RTCP 帯域幅の割合、およびセッションがマルチキャストかユニキャストかに依存します (詳細は RFC 3550、セクション 6.2 を参照)。要約すると、RTCP 制御トラフィックには、通常、セッション帯域幅の 5% というわずかな割合が割り当てられ、そのうち 4 分の 1 がアクティブな RTP 送信者に割り当てられ、受信者は残りの 4 分の 3 を使用します (これらの割合は、セッション記述プロトコル (SDP) [RFC3556] を介して設定できます)。RTP セッションの各メンバーは、これらの割合、セッションがマルチキャストかユニキャストか、観察されたメンバー数、およびアクティブにデータを送信しているかどうかに基づいて、RTCP レポート間隔を導出します。その後、レポート間隔ごとに平均して 1 回、複合 RTCP パケットを送信します (レポートの同期を避けるために、実際のパケット送信時間はレポート間隔の [0.5 ... 1.5] 倍の範囲でランダム化されます)。

最小レポート間隔 5 秒を推奨しますが (RECOMMENDED)、「新しい参加者が存在することをより迅速に通知できるように、初期レポートを送信する前の遅延は最小間隔の半分に設定してもよい (MAY)」[RFC3550]。また、ユニキャストセッションの場合、「初期の複合 RTCP パケットを送信する前の遅延はゼロでもよい (MAY)」[RFC3550]。さらに、ユニキャストセッションおよびマルチキャストセッションのアクティブな送信者の場合、固定の最小レポート間隔を「360 をキロビット/秒単位のセッション帯域幅で割った値」にスケールしてもよい (MAY)。この最小値は、72 kb/s を超える帯域幅では 5 秒未満になります」[RFC3550]。

2.1. 初期同期遅延​

マルチメディアセッションは、共通の参加者グループ間の一連の同時 RTP セッションで構成され、各メディアタイプに 1 つの RTP セッションを使用します。例えば、ビデオ会議 (マルチメディアセッション) には、オーディオ RTP セッションとビデオ RTP セッションが含まれる場合があります。受信者がマルチメディアセッションのコンポーネントを同期できるようにするために、CNAME アイテムを含む RTCP SR パケットと RTCP SDES パケットを含む複合 RTCP パケットを、各送信者によってマルチメディアセッション内の各 RTP セッションに送信しなければなりません (MUST)。受信者は、コンポーネントとなるすべての RTP セッションでそのような RTCP パケットを受信するまで、マルチメディアセッション全体で再生を同期することはできません。パケット損失がない場合、これにより、最も長い RTCP レポート間隔を持つ RTP セッションで最初の RTCP パケットを受信するのにかかる平均時間に等しい、予想される初期同期遅延が発生します。これはユニキャスト RTP セッションとマルチキャスト RTP セッションで異なります。

階層型セッションの初期同期遅延は、マルチメディアセッションの場合と同様です。セッション内の各レイヤーについて RTCP SR および CNAME 情報が受信されるまで、レイヤーを同期することはできません。

2.1.1. ユニキャストセッション​

ユニキャストマルチメディアセッションまたは階層型セッションの場合、送信者は、マルチメディアセッション内の各 RTP セッションに参加した直後に、初期の複合 RTCP パケット (RTCP SR パケットと CNAME アイテムを含む RTCP SDES パケットを含む) を送信すべきです (SHOULD)。個々の RTP セッションは、NAT トラバーサル (例: [RFC5245]) および/またはセキュリティキーイング (例: [RFC5764]、[ZRTP]) 用のインバンドシグナリングが終了し、メディアパスが開かれた時点で参加したと見なされます。これは、RFC 3550 の「初期の複合 RTCP パケットを送信する前の遅延はゼロでもよい」というガイダンスに従って、初期の RTCP パケットが最初のデータパケットと並行して送信され、パケット損失がない場合はフローを即座に同期できることを意味します。

最初の RTCP パケットが送信される前に、インバンドまたはアウトオブバンドのシグナリングの一部として、NAT ピンホール、ファイアウォールホール、サービス品質、およびメディアセキュリティキーがネゴシエートされていることが期待されます。これにより、ミドルボックスがトラフィックを受け入れる準備ができていることが保証され、初期の RTCP パケットが失われる可能性が低くなります。

2.1.2. ソース固有マルチキャスト (SSM) セッション​

マルチキャストセッションの場合、初期の RTCP パケットを送信する前の遅延、したがって同期遅延は、セッション帯域幅とセッション内のメンバー数によって異なります。マルチキャストマルチメディアセッションまたは階層型セッションの場合、平均同期遅延は、コンポーネントとなる RTP セッションのうち最も遅いものに依存します。これは通常、帯域幅が最も低いセッションになります (すべての RTP セッションのメンバー数が同じであると仮定した場合)。

マルチキャストグループに送信する場合、同期レイテンシが問題になる可能性がある場合は、キロビット/秒単位のセッション帯域幅で 360 秒を割った、短縮された最小 RTCP レポート間隔 [RFC3550] を使用する必要があります。また、いつものように、最初の RTCP パケットについてはレポート間隔が半分になります。セッション帯域幅とメンバー数に応じて、図 1 に示す平均同期遅延が得られます。

       セッション| 受信者数:
       帯域幅    |  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

       図 1: 送信者が 1 人の RTP セッションの平均初期同期遅延 (秒)

これらの数値は、1 人のアクティブな送信者がいるソース固有マルチキャストチャネルを想定し、平均 RTCP パケットサイズを 70 オクテットと想定しています。これらの間隔は、過度な遅延なしにリップシンクを行うには十分ですが、階層型ビデオストリームの一部を同期するにはレイテンシが大きすぎると見なされる可能性があります。

RTCP 間隔はいつものようにランダム化されるため、最小同期遅延はこれらの間隔の半分になり、最大遅延は 1.5 倍になります。また、これらの RTCP 間隔は、セッション内のメンバー数を完全に把握していると仮定して計算されていることにも注意してください。

2.1.3. エニーソースマルチキャスト (ASM) セッション​

ASM セッションの場合、送信者であるメンバーの割合が重要な役割を果たし、平均 RTCP レポート間隔の変動が大きくなります。これは図 2 と図 3 に示されており、図 1 で説明した SSM セッションと同じセッション帯域幅と受信者人口に対する RTCP レポート間隔を示していますが、それぞれ送信者が 2 人と 10 人のセッションの場合です。初期同期遅延は送信者の数に応じてスケールし (これは、すべてのグループメンバーからの合計 RTCP トラフィックが無制限に増加しないようにするためです)、ソース固有グループよりも大幅に大きくなる可能性があることがわかります。それにもかかわらず、初期同期時間は、典型的な中小規模のグループビデオ会議シナリオにおけるリップシンクには許容できる範囲にとどまっています。

中心となる RTP トランスレーター ( [RFC5117] の用語では Topo-Translator) を使用したマルチユニキャストを使用して実装されたマルチ送信者グループは、トランスレーターが事実上 ASM グループを形成するため、ASM グループ (Topo-ASM) と同様の同期パフォーマンスを持つことに注意してください。

に最終更新