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) またはミキサー (Topo-Mixer)、あるいはある種のビデオスイッチング MCU (Topo-Video-switch-MCU) を使用したマルチユニキャストを使用して実装されたマルチ送信者グループは、RTCP パケットをグループのすべてのメンバーに配信するため、初期同期レイテンシに関しては ASM グループと同じようにスケールすることに注意してください。
セッション| 受信者数:
帯域幅 | 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
図 2: 送信者が 2 人の RTP セッションの平均初期同期遅延 (秒)
セッション| 受信者数:
帯域幅 | 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
図 3: 送信者が 10 人の RTP セッションの平均初期同期遅延 (秒)
2.1.4. 考察
ユニキャストセッションの場合、既存の RTCP SR ベースのメカニズムにより、初期 RTCP パケットが失われない限り、即座に同期できます。
SSM セッションの場合、初期同期遅延はリップシンクには十分ですが、一部の階層型コーデックには期待されるよりも長い場合があります。マルチキャストグループに対して即座に RTCP パケットを送信しない理由は、多数のメンバーが同時にグループに参加したときにリクエストが殺到 (「フラッシュクラウド」) するのを避けるためです。SSM 送信者の場合、送信者は多くても 1 人であるため、これは問題になりません。したがって、SSM 送信者がセッションに参加したときに即座に RTCP SR を送信できるようにすることが望ましいです (現在、殺到の問題が発生しないユニキャストセッションで許可されているのと同様です)。ユニキャストフィードバックを使用する SSM 受信者は、即座に RTCP を送信することは許可されません。ASM セッションの場合、応答の殺到が懸念されるため、RTCP タイミングルールの変更は提案されていません。
どの場合でも、初期の RTCP SR パケットが失われる可能性があります。この場合、レポート間隔が経過して次の RTCP SR パケットが送信されるまで、受信者はメディアを同期できません。これは望ましくありません。セクション 3.2 では、RTCP SR の生成をリクエストするための新しい RTP/AVPF トランスポート層フィードバックメッセージを定義し、パケット損失が発生した場合の迅速な再同期を可能にします。
2.2. 後から参加した参加者の同期
RTP セッション間の同期は、セッション開始時に立ち会った参加者よりも、後から参加した参加者の方が、潜在的に遅くなる可能性があります。その理由は 3 つあります。
-
RTCP SR パケットの迅速な送信を可能にする最適化の多くは、セッション開始時にのみ適用されます。これは、新しい参加者がメディアストリームを同期するために必要なデータを受信する前に、各セッションの完全な RTCP レポート間隔を待たなければならない可能性があることを意味します。設定されたセッション帯域幅と参加者数によっては、これに数秒かかる可能性があります。
-
追加の同期遅延は、RTCP タイミングルールの性質に起因します。パケットは、平均してレポート間隔ごとに 1 回生成されますが、レポートの同期を避けるために、正確な送信時間は +/- 50% ランダム化されます。これはマルチキャストセッションでのネットワークの混雑を避けるために重要ですが、異なる RTP セッションの RTCP 送信者レポートのタイミングが同期されないことを意味します。したがって、受信者はセッション間で RTP タイムスタンプを調整するために、NTP 形式のクロックのスキューを推定する必要があります。この推定は RTP 同期実装の不可欠な部分であり、十分なレポートがあれば高い精度で行うことができます。ただし、この推定を行うために十分な RTCP SR データを収集するには、複数の RTCP レポートを受信する必要があり、同期遅延がさらに増加する可能性があります。
-
多くのメディアコーデックには定期的なアクセスの概念があり、新しく参加した受信者は、アクセスポイントに対応するパケットが受信されるまでメディアストリームのデコードを開始できないことがよくあります。これらのアクセスポイントは RTCP SR パケットよりも送信頻度が低い場合があるため、後から参加した参加者の同期メディア再生を開始する際の制限要因になる可能性があります。一部のシナリオでは、マルチキャスト RTP セッションのユニキャストベースの迅速な取得のための RTP 拡張 [AVT-ACQUISITION-RTP] を使用して、アクセスポイントを受信するのにかかる時間を短縮できます。
これらの遅延は、進行中のマルチキャスト RTP セッションへのチューニングや、ビデオスイッチング MCU にとって問題となる可能性があります。