RFC 3550 - 付録 B. RFC 1889 からの変更
付録 B. RFC 1889 からの変更 (Appendix B - Changes from RFC 1889)
本 RFC の大部分は RFC 1889 と同一である。オンザワイヤのパケット形式に変更はなく、プロトコルの利用を統治する規則およびアルゴリズムのみに変更がある。最大の変更は、RTCP パケットの送信時期を計算する拡張可能なタイマアルゴリズムへの拡張である。
o セクション 6.2 および 6.3 で規定され付録 A.7 に示される RTCP 送信間隔計算アルゴリズムは、「再考慮 (reconsideration)」を追加して拡張され、多数の参加者が同時にセッションに参加した際に意図されたレートを超える送信を最小限に抑え、また「逆再考慮 (reverse reconsideration)」を追加して参加者数が急速に減少した際の誤った参加者タイムアウトの発生および継続時間を低減する。逆再考慮は、受動的受信側から能動的送信側モードへ移行する際の RTCP SR 送信前の遅延を短縮するためにも用いられる。
o セクション 6.3.7 は、多数の参加者が同時にセッションを退出する際のパケットの洪水を避けるため、RTCP BYE パケットをいつ送信すべきかを制御する新たな規則を規定する。
o 非アクティブな参加者の状態を、典型的なネットワーク分割をまたぐのに十分な期間保持すべきという要件は、セクション 6.2.1 から削除された。多くの参加者が短時間参加し BYE を送信しないセッションでは、この要件は参加者数の著しい過大推定をもたらす。本改訂で追加された再考慮アルゴリズムは、分割が回復した際の同時参加する多数の新参加者を補償する。
これらの拡張は、セッション参加者数が多い（数千）場合にのみ有意な効果を持ち、かつほとんどの参加者が同時に参加または退出する場合に現れることに注意。これは実運用ネットワークでの試験を困難にする。しかしアルゴリズムはその性能を検証するため徹底的な解析およびシミュレーションに付された。さらに、拡張アルゴリズムは RFC 1889 のアルゴリズムと相互運用するよう設計されており、ステップ参加時の過剰 RTCP 帯域幅の低減の度合は拡張アルゴリズムを実装する参加者の割合に比例する。両アルゴリズムの相互運用は実運用ネットワークで実験的に検証された。
その他の機能的変更は以下のとおり。
o セクション 6.2.1 は、実装が非常に大規模なセッションへの拡張を可能にするため、参加者の SSRC 識別子のサンプリングのみを格納してよい (MAY) ことを規定する。アルゴリズムは RFC 2762 [21] で規定される。
o セクション 6.2 では、RTCP 送信側および非送信側帯域幅は、セッション帯域幅の厳密なパーセントではなく別個のセッションパラメータとして設定されてよく (MAY)、かつゼロに設定されてよい (MAY) ことが規定される。IP マルチキャストを用いる RTP セッションで RTCP が必須であるという要件は緩和された。しかし、RTCP を無効にすることは推奨されない (NOT RECOMMENDED) という明確化も追加された。
o セクション 6.2、6.3.1、および付録 A.7 では、送信側が専用 RTCP 帯域幅を獲得する参加者数の閾値が、固定の 1/4 から、送信側および非送信側パラメータが与えられた場合はそれらに基づく比へと変化することが規定される。送信側がいない場合に帯域幅が送信側に専念されないという条件は、それが過渡的状態と予想されるため削除された。また、意図しない場合に非送信側が送信側 RTCP 帯域幅を使用することを防ぐ。
o またセクション 6.2 では、高帯域セッション向けに最小 RTCP 間隔をより小さな値へスケーリングしてよく (MAY)、ユニキャストセッションでは初期 RTCP 遅延をゼロに設定してよい (MAY) ことが規定される。
o 参加者のタイムアウトは、能動的送信側であっても、受信側 RTCP 帯域幅割合を用いて計算される複数の RTCP 報告間隔の非アクティブ性に基づくものとする。
o セクション 7.2 および 7.3 は、トランスレータおよびミキサが、それらがもはや転送していない送信元について BYE パケットを送信すべきである (SHOULD) ことを規定する。
o 階層的符号化の規則変更はセクション 2.4、6.3.9、8.3、および 11 で定義される。これらの最後において、アドレスおよびポート割り当て規則が SDP 仕様 RFC 2327 [15] と抵触することが注記されるが、この制限は RFC 2327 の改訂で緩和されることが意図される。
o セクション 11 における RTP および RTCP の偶数／奇数ポート対の慣習は、宛先ポートを指すよう明確化された。2 つのポートが明示的に指定される場合、偶数／奇数ポート対を用いる要件は削除された。ユニキャスト RTP セッションでは、両端に別個のポート対を用いてよい (MAY)（セクション 3、7.1、および 11）。
o 新たなセクション 10 が追加され、RTP を用いるアプリケーションにおける輻輳制御の要件を説明する。
o セクション 8.2 では、ソーストランスポートアドレスが変更されるたびに必ず新たな SSRC 識別子を選ばなければならない (MUST) という要件が緩和され、新たな SSRC 識別子を選んでもよい (MAY) とされた。それに対応し、2 つの他の参加者間で SSRC 衝突が生じた場合、実装は既存の送信元アドレスではなく新たな送信元アドレスからのパケットを保持することを選んでもよい (MAY) こと、および移動体のように一部の送信元が RTP セッション中にアドレスを変更し得る電話のようなアプリケーションではそうすべきである (SHOULD) ことが明確化された。
o RFC 1889 の印刷におけるセクション 8.2 の衝突検出および解決アルゴリズムの疑似コードのインデント不具合は、構文を疑似 C 言語へ翻訳することで修正され、また両 RTP および RTCP を同じソースポート番号から送信しなければならないという制限を除去するようアルゴリズムが修正された。
o RTCP パケットのパディング機構の記述が明確化され、パディングは複合 RTCP パケットの最後のパケットにのみ適用されなければならない (MUST) ことが規定された。
o 付録 A.1 において、base_seq の初期化が seq - 1 ではなく seq となるよう修正され、誤ったシーケンス番号に 1 を加えたものを格納するという記述が修正された。max_seq およびアルゴリズムの他の変数の初期化は init_seq() 関数の呼び出しに加えて必ず行わなければならないことを明確にするため本文から分離された（また、RFC 1889 で原本から出力形への処理中に失われた数語が復元された）。
o 付録 A.3 における失われたパケット数のクランプが、正および負の両限界を用いるよう修正された。
o RTCP SR セクションにおける「相対的 (relative)」NTP タイムスタンプの規定が、セッション経過時間（同じマシンで異なる時刻に開始された複数のアプリケーションで同一でない）ではなく、システム稼働時間などの最も一般的なシステム固有クロックに基づくよう定義するよう変更された。
非機能的変更：
o 受信側は理解できないペイロード種別を持つパケットを無視しなければならない (MUST) ことが規定された。
o 図 2 において、浮動小数点 NTP タイムスタンプ値が修正され、16 進数の先行ゼロが追加され、UTC タイムゾーンが指定された。
o 2036 年に NTP タイムスタンプが折り返すことの無影響が説明された。
o RTCP パケット種別および SDES 種別の登録ポリシーが、新たなセクション 15「IANA 考慮事項」で明確化された。実験者が必要な番号を登録し不要と判明したものを登録解除すべきという提案は、APP および PRIV を用いる方針に置き換えられた。プロファイル名の登録も規定された。
o UTF-8 文字集合への参照が X/Open 暫定仕様から RFC 2279 へ変更された。
o RFC 1597 への参照が RFC 1918 へ、RFC 2543 への参照が RFC 3261 へ更新された。
o RFC 1889 の序論最後の段落（実装者にインターネットでの展開を制限するよう警告していた）は、もはや関連しないとみなされ削除された。
o ソース特異的マルチキャスト (SSM) を用いる RTP に関する非規範的注記がセクション 6 に追加された。
o セクション 3 の「RTP セッション」の定義が拡張され、単一セッションが複数の宛先トランスポートアドレスを用い得ること（トランスレータまたはミキサの場合は常にそうであった）、ならびに RTP セッションを特徴づける点は各セッションが別個の SSRC 識別子空間に対応することであることが説明された。「マルチメディアセッション」の新たな定義が追加され、「セッション」という語の混同を減らすためである。
o 「サンプリング瞬間 (sampling instant)」の意味が、セクション 5.1 の RTP ヘッダのタイムスタンプフィールドの定義の一部としてより詳細に説明された。
o いくつかの箇所で小さな明確化が行われ、読者からの質問への対応も含まれる。とくに：
- RFC 1889 では、セクション 2.2 の第 2 文の最初の 5 語が原本から出力形への処理中に失われていたが、現在は復元されている。
- セクション 3 に「RTP メディアタイプ (RTP media type)」の定義が追加され、セクション 5.2 における複数メディアの多重化に関する説明および SSRC 識別子に基づく同一メディアの複数送信元の多重化が適切でありマルチキャストセッションの標準であることがより明確になった。
- 「非 RTP 手段 (non-RTP means)」の定義が拡張され、非 RTP 手段を構成する他のプロトコルの例が含まれた。
- セクション 6.2 においてセッション帯域幅パラメータの記述が拡張され、制御トラフィック帯域幅がデータトラフィックのセッション帯域幅に加えて別途必要であるという明確化を含む。
- パケット持続時間の変動がジッタ計算に及ぼす影響がセクション 6.4.4 で説明された。
- SDES 項の並びを終端しパディングする方法がセクション 6.5 で明確化された。
- IPv6 アドレスの例がセクション 6.5.1 の SDES CNAME の記述に追加され、「example.com」が他の例示ドメイン名に代わって用いられた。
- セキュリティ節は、利用可能となった IPSEC への正式な参照を追加し、本仕様で定義された機密性方式が主として既存の慣行を成文化するものであると述べた。デフォルトアルゴリズムの代わりに Triple-DES のようなより強力な暗号化アルゴリズムを用いることが推奨され、AES に基づく SRTP プロファイルが将来の正しい選択となることが注記された。初期化ベクトルとしての RTP ヘッダの弱点に関する警告が追加された。また、ヘッダ圧縮を許すためペイロードのみの暗号化が必要であることが注記された。
- RTCP の部分暗号化の方法が明確化された。とくに、複合 RTCP パケットを分割する際、SDES CNAME はいずれか一方の部分のみに運ばれる。
- 報告間隔ごとに 1 つの複合 RTCP パケットのみを送信すべきこと、および報告を MTU に収めるのに送信元が多すぎる場合は複数の間隔にわたりラウンドロビンで送信元の部分集合を選択すべきことが明確化された。
- 付録 A.1 に、RTP ヘッダ妥当性検査中にパケットを保存し成功時に配送してよいという注記が追加された。
- セクション 7.3 は、SDES パケットを集約するミキサはパケットが長くなるためより多くの RTCP 帯域幅を消費し、RTCP を通過させるミキサは当然に単一送信元レートより高いレートでパケットを送信するが、いずれの挙動も有効であることを説明するよう現在は記述される。
- セクション 13 は、RTP アプリケーションが複数のプロファイルを用いてもよいが、典型的には与えられたセッションで 1 つしか用いないことを明確化する。
- MUST、SHOULD、MAY などの用語は RFC 2119 での定義どおりに用いられる。
- 参考文献は規範的参照および参考的参照に分割された。