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

3. RTP 同期遅延の短縮

同期遅延を短縮するために、3 つのバックワードコンパチブルな RTP 拡張機能が定義されています。SSM 送信者の初期 RTCP 間隔の短縮、迅速な再同期リクエストメッセージ、および同期メタデータをインバンドで伝送できる RTP ヘッダー拡張機能です。

3.1. SSM 送信者の初期 RTCP 間隔の短縮​

初期同期遅延が重要な SSM セッションでは、RTP 送信者は、初期の複合 RTCP パケットを送信する前の遅延をゼロに設定し、SSM セッションに参加した直後に最初の RTCP パケットを送信してもよい (MAY)。これは純粋に送信者のローカルな変更であり、設定可能なオプションとして実装できます。SSM セッションでユニキャスト RTCP フィードバックを送信する RTP 受信者は、初期遅延ゼロで RTCP パケットを送信してはなりません (MUST NOT)。[RFC5760] で定義されているタイミング規則は、受信者にそのまま適用されます。

3.2. 迅速な再同期リクエスト​

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  |             長さ              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  パケット送信者の SSRC                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  メディアソースの SSRC                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :            フィードバック制御情報 (FCI)                        :
     :                                                               :

             図 4: RTP/AVPF トランスポート層フィードバックメッセージ

FMT = 5 の新しいフィードバックメッセージタイプ RTCP-SR-REQ が定義されています。フィードバックメッセージのフィードバック制御情報 (FCI) 部分は空でなければなりません (MUST)。パケット送信者の SSRC はメディアストリームを同期できないメンバーを示し、メディアソースの SSRC は同期できないメディアの送信者を示します。長さは 2 でなければなりません (MUST)。

RTP/AVPF プロファイル [RFC4585] が使用されている場合、一部のメディアストリームを同期できないこと、およびメディアソースができるだけ早く (早期フィードバックに関する RTCP タイミングルールの制約内で) RTCP SR パケットを送信することをリクエストするために、受信者がこのフィードバックメッセージを送信してもよい (MAY)。RTCP-SR-REQ パケットを理解するメディアソースは、このような指示を受け取った場合、RTCP 早期フィードバック規則を遵守しながら、できるだけ早く RTCP SR パケットを生成すべきです (SHOULD)。非複合 RTCP [RFC5506] の使用が以前にネゴシエートされていた場合、フィードバックリクエストと RTCP SR レスポンスの両方を非複合 RTCP パケットとして送信できます。RTCP SR パケットが届かない場合、RTCP-SR-REQ パケットは RTCP レポート間隔ごとに 1 回繰り返してもよい (MAY)。同期メタデータの定期的な送信スケジュールによって、受信者が妥当な時間内にメディアストリームを同期できると予想される場合、メディアソースは RTCP-SR-REQ パケットを無視してもかまいません。

ユニキャストフィードバックを備えた SSM セッションを使用する場合、フィードバックターゲットとメディアソースが同じ場所に配置されていない可能性があります。そのような場合にフィードバックターゲットが RTCP-SR-REQ フィードバックメッセージを受信した場合、リクエストはメディアソースに転送されるべきです。そのようなリクエストを転送するために使用されるメカニズムは、ここでは定義されていません。

ネットワーク管理インターフェースを提供している場合、RTCP-SR-REQ フィードバックパケットを送信する受信者と送信しない受信者のログを提供することは、送信しない受信者の方がストリーム同期が遅くなるため、有用な場合があります。

3.3. 同期メタデータのインバンド配信​

[RFC5285] で定義されている RTP ヘッダー拡張メカニズムを適合させて、RTP データパケットにオプションの NTP 形式タイムスタンプを含めることができます。そのようなタイムスタンプが含まれる場合、それはパケットヘッダーの RTP タイムスタンプと同じ時点に対応していなければならず (MUST)、また RTCP SR パケットに含まれる NTP 形式タイムスタンプの生成に使用されるものと同じクロックから派生していなければなりません (MUST)。以前に受信した RTCP CNAME パケット、またはアウトオブバンドシグナリング [RFC5576] のいずれかから SSRC と CNAME のマッピングを把握していれば、受信者は提供された情報を同期アルゴリズムへの入力として、フローに対して追加の RTCP SR パケットを受信した場合とまったく同じ方法で使用できます。

このヘッダー拡張には 2 つのバリエーションが定義されています。最初のバリエーションは、[RFC5905] で定義されている 64 ビットの NTP 形式タイムスタンプで RTP ヘッダーを拡張します。2 番目のバリエーションは、NTP 形式タイムスタンプの「秒」の下位 24 ビット部分と、「小数」部分の 31 ビットを伝送します。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      |           シーケンス番号      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
     |                          タイムスタンプ                       |T
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
     |                同期ソース (SSRC) 識別子                       |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |       0xBE    |    0xDE       |             長さ=3            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
     | ID-A  | L=7   |   NTP タイムスタンプ形式 - 秒 (bit 0-23)      |x
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
     |NTP秒(24-31)   |   NTP タイムスタンプ形式 - 小数 (bit 0-23)    |e
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
     |NTP小数(24-31) |    0 (pad)    |    0 (pad)    |    0 (pad)    |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                         ペイロードデータ                      |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             図 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      |           シーケンス番号      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R
     |                          タイムスタンプ                       |T
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P
     |                同期ソース (SSRC) 識別子                       |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |       0xBE    |    0xDE       |             長さ=2            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
     | ID-B  | L=6   |   NTP タイムスタンプ形式 - 秒 (bit 8-31)      |x
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
     |             NTP タイムスタンプ形式 - 小数 (bit 0-31)          |e
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                         ペイロードデータ                      |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             図 6: バリエーション B / 56 ビット NTP RTP ヘッダー拡張

NTP 形式タイムスタンプは、送信者が選択した任意の RTP パケットに含めてもよいですが (MAY)、セクション 4.1 でさらに規定されているように、複数の RTP フローで転送される階層型コーデックに対してタイムスタンプベースのデコード順序回復を実行する場合に推奨されます (RECOMMENDED)。このヘッダー拡張は、マルチメディアセッションの後発参加者やビデオスイッチングシナリオにおいて迅速な同期を可能にするために、ビデオランダムアクセスポイントに対応する RTP パケット、および関連するオーディオパケットでも送信すべきです (SHOULD)。

注意: RTP ヘッダー拡張を含めると、RTP ヘッダー圧縮が使用されている場合、その効率が低下します。さらに、ヘッダー拡張を理解しないミドルボックスは、それらを削除したり、このメモに従って内容を更新しなかったりする可能性があります。

どの場合でも、インバンド NTP 形式タイムスタンプが含まれているかどうかにかかわらず、[RFC3550] に従って RTP フローを同期する受信者とのバックワードコンパチビリティを確保し、RTP ヘッダー拡張を削除する可能性のあるミドルボックス (RTP トランスレーター) に対して堅牢性を確保するために、定期的な RTCP SR パケットを送信しなければなりません (MUST)。バリエーション B/56 ビット NTP RTP ヘッダー拡張が使用される場合、NTP 形式タイムスタンプの「秒」の上位 8 ビットを導出するために RTCP 送信者レポートを使用しなければなりません (MUST)。

SDP が使用される場合、上記で定義された RTP ヘッダー拡張の使用は、 [RFC5285] で規定されているように示されなければなりません (MUST)。したがって、次の URI を使用しなければなりません (MUST)。

  • SDP でバリエーション A/64 ビット NTP RTP ヘッダー拡張の使用をシグナリングするために使用される URI は "urn:ietf:params:rtp-hdrext:ntp-64" です。

  • SDP でバリエーション B/56 ビット NTP RTP ヘッダー拡張の使用をシグナリングするために使用される URI は "urn:ietf:params:rtp-hdrext:ntp-56" です。

これらの RTP ヘッダー拡張を使用すると、IPTV のチャンネルサーフィンや一部のインタラクティブなビデオ会議シナリオにおけるユーザーエクスペリエンスを大幅に向上させることができます。ユーザーエクスペリエンスを監視しようとするネットワーク管理ツールは、どのセッションがこれらの拡張機能をシグナリングし、使用しているかをログに記録したいと考えるかもしれません。