1.1. Applicability (適用可能性)
1.1. Applicability (適用可能性)
XR パケットは複数のアプリケーションで有用であるため, RTCP 送信者レポートまたは受信者レポートへのプロファイル固有の拡張として定義されていません [9, セクション 6.4.3]。それにもかかわらず, すべてのコンテキストで有用というわけではありません。特に, VoIP メトリクスレポートブロック (セクション 4.7) は音声アプリケーションに固有のものですが, さまざまなそのようなアプリケーションで使用できます。
VoIP メトリクスレポートブロックは, RTP と RTCP の使用が指定されている任意の 1 対 1 または 1 対多の音声アプリケーションに適用できます。会話メトリクス (セクション 4.7.5) の使用, [3] で定義された E モデルで説明されている R ファクターおよび会話品質の平均オピニオンスコア (MOS-CQ) を含むものは, 単純な 2 者間通話以外のアプリケーションでは定義されていません。したがって, これらのメトリクスはマルチキャスト会議アプリケーションでは利用不可として識別する必要があります。
パケット単位のレポートブロックタイプ, 損失 RLE (セクション 4.1), 重複 RLE (セクション 4.2), およびパケット受信時刻 (セクション 4.3) は, ネットワーク特性のマルチキャスト推論 (MINC) [11] などのネットワークトモグラフィアプリケーションを念頭に置いて定義されています。MINC は, マルチキャスト配信ツリーの大まかな構造と, そのツリーの分岐点間のパスに適用される損失率や遅延などのパラメータを推測するために, マルチキャストセッション受信者からの詳細なパケット受信トレースを必要とします。
任意のリアルタイムマルチキャストマルチメディアアプリケーションは, パケット単位のレポートブロックタイプを使用できます。そのようなアプリケーションは, マルチキャストツリートポロジ情報を提供する MINC 推論サブシステムを使用できます。そのようなサブシステムの潜在的な用途の 1 つは, マルチキャストツリー内の高損失領域の識別と, 失われたパケットの再送信を提供するのに適した位置にあるマルキャストセッション参加者の識別です。
詳細なパケット単位のレポートは, 他の RTCP パケットに対して不釣り合いな帯域幅を消費する必要は必ずしもありません。アプリケーションはこれらのブロックのサイズを制限できます。これらのレポートブロックには「間引き」と呼ばれるメカニズムが提供されており, 任意のシーケンス番号間隔内で報告されるパケット数を制限することにより, サイズ制限を遵守するために使用できます。このメカニズムの根拠と使用法は [13] で説明されています。さらに, アプリケーションは, マルチキャストツリー内のどこに定義された損失率しきい値を超えるパスがあるかなどの重要な質問に答えるために, すべての受信者からのレポートブロックを必要としない場合があります。どの受信者がこれらのレポートブロックを送信するかに関する賢明な決定により, それらが消費する RTCP 帯域幅の部分をさらに制限できます。
パケット単位のレポートブロックは, 専用のネットワーク監視アプリケーションでも使用できます。そのようなアプリケーションでは, RTP データ帯域幅の 5% を超える量を RTCP パケットに使用することが適切な場合があり, これにより比例してより大きく詳細なレポートブロックが可能になります。
パケット単位のブロックタイプの内容は, マルチキャストアプリケーションへの使用を制限するものではありません。特に, MINC に似たネットワークトモグラフィに使用できますが, 代わりにストライプユニキャストパケットを使用します。さらに, 有用であることがわかった場合, 2 人の参加者に限定されたアプリケーションに使用できます。
パケット単位のレポートがすぐには適していない用途の 1 つは, パケット再送信メカニズムの一部としてのデータパケット確認応答です。その理由は, これらのブロックに提案されているパケット計上技術が RTP で通常使用されるパケット計上とは異なるためです。測定アプリケーションを優先するために, データ受信者でできるだけ少なく解釈し, レポートブロックを受信する参加者にできるだけ多くの解釈を任せる努力がなされています。したがって, たとえば, 異常な SSRC ID または異常なシーケンス番号を持つパケットは, 通常の RTP 計上では除外される可能性がありますが, ネットワーク監視の目的で報告されます。
統計サマリレポートブロック (セクション 4.6) も, ネットワーク監視を念頭に置いて定義されています。このブロックタイプは, ユニキャストおよびマルチキャストパケット受信の報告に同様に使用できます。
参照時刻関連のブロックタイプは, 受信者ベースの TCP フレンドリーマルチキャスト輻輳制御 [18] のために考案されました。データ受信者が送信者への往復時間を計算できるようにすることで, 受信者が要求すべきダウンストリーム帯域幅を推定するのに役立ちます。すべての受信者が受信者参照時刻レポートブロック (セクション 4.4) を送信する場合, 送信者は報告間隔内に送信者に到着した RTCP パケットの受信者数に等しい数の DLRR レポートブロック (セクション 4.5) を送信する可能性があることに注意してください。マルチキャストセッションの参加者数が増加するにつれて, アプリケーションはどの参加者がこれらのブロックを送信するか, またどのくらいの頻度で送信するかについて慎重に判断する必要があります。
XR パケットは既存の RTCP パケットを補完し, 他の RTCP パケットと積み重ねて複合 RTCP パケットを形成できます [9, セクション 6]。XR パケットをセッションに導入しても, RTCP 報告間隔の計算を管理する規則が変更されることは決してありません [9, セクション 6.2]。XR パケットは RTCP パケットであるため, 帯域幅計算ではそのようにカウントされます。その結果, 拡張レポート情報の追加により, 平均 RTCP パケットサイズが増加する傾向があり, したがって平均報告間隔も増加します。この増加は, XR パケットのサイズを制限することで制限できます。
この文書で XR パケットに定義された SDP シグナリング (セクション 5) は, 3 つの使用シナリオを念頭に置いて行われました: リアルタイムストリーミングプロトコル (RTSP) 制御のストリーミングアプリケーション, 強化されたフィードバックを備えたコース講義などの 1 対多マルチキャストマルチメディアアプリケーション, および 2 者が関与するセッション開始プロトコル (SIP) 制御の会話セッション。SDP を使用するアプリケーションは, ここでカバーされていないケースに対して追加の SDP シグナリングを自由に使用できます。さらに, アプリケーションは SDP 以外のシグナリングメカニズムを自由に使用できます。