2. RTP および RTCP パケット形式とプロトコル動作

RTP および RTCP パケット形式とプロトコル動作

RFC 3550 のセクション「RTP プロファイルおよびペイロード形式仕様」には、プロファイルで指定または変更できるいくつかの項目が列挙されています。本セクションではこれらの項目について扱います。一般的に、このプロファイルは RTP 仕様のデフォルトおよび/または推奨される側面に従います。

RTP データヘッダー：固定 RTP データヘッダーの標準形式（マーカービット 1 つ）が使用されます。

ペイロードタイプ：静的ペイロードタイプはセクション 6 で定義されています。

RTP データヘッダーの追加：RTP データヘッダーに追加の固定フィールドは付加されません。

RTP データヘッダー拡張：RTP ヘッダー拡張は定義されていませんが、このプロファイルの下で動作するアプリケーションはそのような拡張を使用してもかまいません（MAY）。したがって、アプリケーションは RTP ヘッダーの X ビットが常にゼロであると仮定すべきではなく（SHOULD NOT）、ヘッダー拡張を無視する準備をしておくべきです（SHOULD）。将来ヘッダー拡張が定義される場合、その定義は、複数の異なる拡張を識別できるように、最初の 16 ビットの内容を指定しなければなりません（MUST）。

RTCP パケットタイプ：このプロファイル仕様では、追加の RTCP パケットタイプは定義されていません。

RTCP レポート間隔：RTCP レポート間隔の計算には、推奨される定数が使用されます。このプロファイルの下で動作するセッションは、セッション帯域幅のデフォルトの割合を使用する代わりに、RTCP トラフィック帯域幅に対して個別のパラメータを指定してもかまいません（MAY）。RTCP トラフィック帯域幅は、アクティブなデータ送信者とそうでない参加者のために、2 つの別々のセッションパラメータに分割してもかまいません（MAY）。データ送信者に RTCP 帯域幅の 1/4 を割り当てるという RTP 仕様 [1] の推奨に従い、これら 2 つのパラメータの推奨デフォルト値はそれぞれ 1.25% と 3.75% となります。特定のセッションでは、単方向リンクで動作している場合や、受信品質に関するフィードバックを必要としないセッションの場合、非データ送信者の RTCP 帯域幅をゼロに設定してもかまいません（MAY）。データ送信者の RTCP 帯域幅は、メディア間の同期のために送信者レポートを送信し、CNAME によってソースを識別できるように、ゼロ以外に保たれるべきです（SHOULD）。RTCP 帯域幅のための 1 つまたは 2 つのセッションパラメータを指定する手段は、本メモの範囲外です。

SR/RR 拡張：RTCP SR または RR パケットの拡張セクションは定義されていません。

SDES の使用：アプリケーションは、RTP 仕様に記載されている任意の SDES 項目を使用してもかまいません（MAY）。CNAME 情報はレポート間隔ごとに送信しなければなりませんが（MUST）、その他の項目は 3 回のレポート間隔ごとに 1 回だけ送信すべきであり（SHOULD）、RTP 仕様のセクション 6.2.2 で定義されているように、NAME はそのスロット内で 8 回中 7 回送信され、残りの SDES 項目が 8 回目のスロットを周期的に占有します。言い換えれば、NAME は RTCP パケット 1, 4, 7, 10, 13, 16, 19 で送信され、例えば EMAIL は RTCP パケット 22 で使用されます。

セキュリティ：RTP のデフォルトのセキュリティサービスは、このプロファイルの下でもデフォルトです。

文字列からキーへのマッピング：このプロファイルではマッピングは指定されていません。

輻輳：RTP およびこのプロファイルは、例えば統合サービス (RFC 1633) [4] や差別化サービス (RFC 2475) [5] を通じた拡張ネットワークサービスのコンテキストで使用される場合もあれば、ベストエフォートサービスで使用される場合もあります。

拡張サービスが使用されている場合、RTP 受信者はパケット損失を監視して、要求されたサービスが実際に提供されていることを確認すべきです（SHOULD）。そうでない場合、彼らはベストエフォートサービスを受けていると仮定し、それに応じて振る舞うべきです（SHOULD）。

ベストエフォートサービスが使用されている場合、RTP 受信者はパケット損失を監視して、パケット損失率が許容可能なパラメータ内であることを確認すべきです（SHOULD）。同じネットワークパスを経由し、同じネットワーク条件を経験する TCP フローが、適切なタイムスケールで測定された平均スループットを達成し、それが RTP フローが達成しているものと比べて少なくない場合、パケット損失は許容可能と見なされます。この条件は、送信レートを適応させるための輻輳制御メカニズムを実装する（または階層型マルチキャストセッションでサブスクライブするレイヤー数を適応させる）ことによって、あるいは損失率が許容できないほど高い場合に受信者がセッションを離脱するように手配することによって満たすことができます。

TCP との比較を厳密に指定することはできませんが、タイムスケールとスループットにおける「桁数（オーダー）」の比較を意図しています。TCP スループットが測定されるタイムスケールは、接続の往復時間（RTT）です。本質的に、この要件は、帯域幅を勝手に消費し、桁数の範囲内で TCP と公平に競合しないアプリケーション（RTP またはその他のトランスポートプロトコルを使用）をベストエフォート型インターネット上に展開することは許容されないということを述べています。

下位プロトコル：プロファイルは、ユニキャストおよびマルチキャスト UDP、ならびに TCP 上での RTP の使用を指定します。（これは、RTP が他の下位層プロトコルによって運ばれる場合にこれらの定義を使用することを排除するものではありません。）

トランスポートマッピング：トランスポートレベルアドレスへの RTP および RTCP の標準マッピングが使用されます。

カプセル化：このプロファイルは、UDP 以外のプロトコルにおける RTP カプセル化の仕様をアプリケーションに委ねます。