RFC 3550 - 6. RTP 制御プロトコル (RTCP)
6. RTP 制御プロトコル (RTCP)
RTP 制御プロトコル (RTP Control Protocol, RTCP) は、データパケットと同じ配信メカニズムを用いて、セッション内の全参加者に対して制御パケットを定期的に送信することを基本とする。下位プロトコルは、データパケットと制御パケットの多重化を提供しなければならない（たとえば UDP で別ポートを用いるなど）。RTCP は 4 つの機能を果たす。
-
主たる機能はデータ配信の品質に関するフィードバックを提供することである。これは、トランスポートプロトコルとしての RTP の役割の不可欠な一部であり、他のトランスポートプロトコルのフロー制御および輻輳制御機能に関連する（輻輳制御の要件についてはセクション 10 参照）。このフィードバックは適応的符号化 [18][19] の制御に直接有用であるが、IP マルチキャストの実験により、配信の障害を診断するために受信側からのフィードバックを得ることもまた極めて重要であることが示されている。受信フィードバック報告を全参加者に送信することで、問題を観測している者はその問題が局所的か全体的かを評価できる。IP マルチキャストのような配信メカニズムでは、セッションに関与しないネットワークサービスプロバイダのような主体がフィードバック情報を受信し、サードパーティモニタとしてネットワーク問題を診断することも可能である。このフィードバック機能は、以下セクション 6.4 で記述される RTCP 送信側報告および受信側報告によって果たされる。
-
RTCP は、正規名または CNAME と呼ばれる RTP 送信元に対する永続的なトランスポートレベル識別子を運ぶ（セクション 6.5.1）。SSRC 識別子は衝突の発見やプログラムの再起動により変化し得るため、受信側は各参加者を追跡するために CNAME を必要とする。受信側はまた、たとえば音声と映像を同期させるためなど、一連の関連する RTP セッションにおいて特定の参加者からの複数のデータストリームを関連付けるために CNAME を必要とするかもしれない。メディア間同期にも、データ送信側が RTCP パケットに含める NTP および RTP タイムスタンプが必要である。
-
最初の 2 つの機能は、全参加者が RTCP パケットを送信することを必要とするため、RTP が多数の参加者へ拡張可能であるためにはレートを制御しなければならない。各参加者が自らの制御パケットを他のすべての者へ送信することで、それぞれが参加者数を独立に観測できる。この数は、セクション 6.2 で説明するようにパケットの送信レートの計算に用いられる。
-
第 4 の任意 (OPTIONAL) 機能は、最小限のセッション制御情報、たとえばユーザインタフェースに表示される参加者識別情報の伝達である。これは、参加者がメンバーシップ管理やパラメータネゴシエーションなしに出入りする「緩やかに制御された (loosely controlled)」セッションにおいて最も有用であろう。RTCP は全参加者へ到達するための便利なチャネルとして機能するが、アプリケーションのすべての制御通信要件を満たすことは必須とはされない。本書の範囲外であるより高層のセッション制御プロトコルが必要になるかもしれない。
機能 1-3 はすべての環境、とくに IP マルチキャスト環境で用いられるべきである。RTP アプリケーション設計者は、ユニキャストモードでのみ動作し、より大きな参加者数へ拡張できないメカニズムを避けるべきである。RTCP の送信は、受信側からのフィードバックが不可能な単方向リンクなどの場合について、セクション 6.2 で記述されるように送信側と受信側で別個に制御されてよい。
非規範的注記 (Non-normative note)：ソース特定マルチキャスト (Source-Specific Multicast, SSM) と呼ばれるマルチキャストルーティング方式では、「チャネル」(送信元アドレスとグループアドレスの組) ごとに送信側は 1 つだけであり、受信側（チャネル送信元を除く）はマルチキャストを用いて他のチャネルメンバと直接通信できない。ここでの勧告は、受信側の RTCP を完全に停止するというセクション 6.2 の選択肢を通じてのみ SSM に対応する。将来の作業により、受信側からのフィードバックを維持できるよう RTCP の SSM への適応が規定される予定である。
6.1 RTCP パケット形式 (RTCP Packet Format)
本書は、様々な制御情報を運ぶためのいくつかの RTCP パケット種別を定義する。
SR：送信側報告 (Sender report)。能動的な送信側である参加者からの送信・受信統計のため。
RR：受信側報告 (Receiver report)。能動的な送信側でない参加者からの受信統計のため、および 31 を超える送信元について報告する能動的送信側が SR と組み合わせて用いるため。
SDES：ソース記述項 (Source description items)。CNAME を含む。
BYE：参加の終了を示す。
APP：アプリケーション固有の機能。
各 RTCP パケットは、RTP データパケットの固定部と類似の固定部で始まり、その後にパケット種別に応じて可変長となり得る構造化要素が続くが、32 ビット境界で終わらなければならない。固定部のアラインメント要件および長さフィールドは、RTCP パケットを「スタック可能 (stackable)」にするために含まれている。複数の RTCP パケットは、区切り文字なしで連結され、下位層プロトコル（UDP など）の単一パケットとして送信される複合 RTCP パケット (compound RTCP packet) を構成できる。下位層プロトコルが複合パケットの末尾を決定する全体長を提供すると期待されるため、複合パケット内の個別の RTCP パケット数の明示的なカウントはない。
複合パケット内の各個別 RTCP パケットは、パケットの順序や組合せに関する要件なしに独立に処理されてよい。しかし、プロトコルの機能を果たすため、以下の制約が課される。
o 受信統計（SR または RR 内）は、統計の解像度を最大化するため、帯域幅の制約が許す限り頻繁に送信されるべきである。したがって、定期的に送信される各複合 RTCP パケットは報告パケットを含まなければならない。
o 新たな受信側は、発話者同期 (lip-sync) などの目的でソースを識別しメディアの関連付けを始めるために、できるだけ早くソースの CNAME を受信する必要がある。したがって各複合 RTCP パケットは、セクション 9.1 で記述される部分暗号化のために複合 RTCP パケットが分割される場合を除き、SDES CNAME を含まなければならない。
o 複合パケットの先頭に現れ得るパケット種別の数は、第 1 ワードの一定ビット数および、誤って宛先指定された RTP データパケットやその他の無関係なパケットに対する RTCP パケット妥当性検証の成功率を高めるために、限定されなければならない。
したがって、すべての RTCP パケットは少なくとも 2 つの個別パケットからなる複合パケットとして送信されなければならず、その形式は以下のとおりである。
暗号化プレフィックス (Encryption prefix)：複合パケットがセクション 9.1 の方式に従って暗号化される場合には、送信する複合パケットごとに引き直されるランダムな 32 ビット値をプレフィックスとして付けなければならない。暗号化のためにパディングが必要な場合、それは複合パケットの最後のパケットに追加されなければならない。
SR または RR：複合パケット内の最初の RTCP パケットは、付録 A.2 で記述されるヘッダ妥当性検証を容易にするため、常に報告パケットでなければならない。これは、データの送受信が行われていない場合、すなわち空の RR を送信しなければならない場合や、複合パケット内の唯一の他の RTCP パケットが BYE である場合でも同様である。
追加の RR：受信統計を報告する送信元の数が、1 つの SR または RR パケットに収まる 31 を超える場合、初期の報告パケットに続いて追加の RR パケットを置くべきである。
SDES：CNAME 項を含む SDES パケットは、セクション 9.1 で注記される場合を除き、各複合 RTCP パケットに含まれなければならない。他のソース記述項は、特定のアプリケーションで必要な場合、帯域幅の制約（セクション 6.3.9 参照）の下で任意に含めてよい。
BYE または APP：まだ定義されていないものを含め、他の RTCP パケット種別は任意の順序で続いてよいが、BYE は与えられた SSRC/CSRC で送信される最後のパケットとすべきである。パケット種別は複数回現れてよい。
個々の RTP 参加者は、参加者ごとの RTCP 帯域幅を正しく推定するため（セクション 6.2 参照）、報告間隔ごとに 1 つの複合 RTCP パケットのみを送信すべきである（セクション 9.1 で記述される部分暗号化のために複合 RTCP パケットが分割される場合を除く）。ネットワークパスの MTU を超えずにすべての必要な RR パケットを 1 つの複合 RTCP パケットに収めるのに送信元が多すぎる場合、各間隔に 1 つの MTU に収まる部分集合のみを含めるべきである。部分集合は、すべての送信元が報告されるよう、複数の間隔にわたりラウンドロビンで選択されるべきである。
トランスレータおよびミキサは、転送している複数の送信元からの個別 RTCP パケットを、可能な限り 1 つの複合パケットに統合し、パケットオーバヘッドを償却すべきであることが推奨される（セクション 7 参照）。ミキサにより生成され得る RTCP 複合パケットの例を図 1 に示す。複合パケットの全体長がネットワークパスの MTU を超える場合、それは下位プロトコルの別々のパケットで送信される複数の短い複合パケットに分割されるべきである。これは、各複合パケットが少なくとも 1 つの異なる参加者を表すため、RTCP 帯域幅推定を損なわない。各複合パケットは SR または RR パケットで始まらなければならないことに注意。
実装は、未知の種別を持つ受信 RTCP パケットを無視すべきである。追加の RTCP パケット種別は、セクション 15 で記述されるようにインターネット割り当て番号機構 (IANA) に登録されてよい。
if encrypted: random 32-bit integer | |[--------- packet --------][---------- packet ----------][-packet-] | | receiver chunk chunk V reports item item item item
R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]
| | |<----------------------- compound packet ----------------------->| |<-------------------------- UDP packet ------------------------->|
#: SSRC/CSRC identifier
Figure 1: Example of an RTCP compound packet
6.2 RTCP 送信間隔 (RTCP Transmission Interval)
RTP は、数人の参加者から数千人までのセッション規模にわたり自動的に拡張できるよう設計されている。たとえば音声会議では、一度に話すのは 1 人か 2 人だけであるためデータトラフィックは本質的に自己抑制的であり、マルチキャスト配信であればリンクごとのデータレートは参加者数にかかわらず比較的一定である。しかし制御トラフィックは自己抑制的ではない。各参加者からの受信報告が一定レートで送信されれば、制御トラフィックは参加者数に比例して線形に増大する。したがって、RTCP パケット送信間の間隔を動的に計算することで、レートを縮小させなければならない。
各セッションについて、データトラフィックは参加者間で分割される「セッション帯域幅 (session bandwidth)」と呼ばれる集約制限を受けると仮定される。この帯域幅は予約され、ネットワークによって制限が強制されてよい。予約がない場合、セッションが使用すべき「合理的 (reasonable)」最大値を確立する他の制約（環境による）が存在し得て、それがセッション帯域幅となる。セッション帯域幅は、利用可能なネットワーク帯域幅のコストや事前知識に基づいて選ばれてよい。これはメディア符号化とはやや独立しているが、符号化の選択はセッション帯域幅により制限され得る。多くの場合、セッション帯域幅は同時にアクティブと予想される送信側の公称帯域幅の和である。電話会議音声の場合、この数は典型的には 1 送信側分の帯域幅である。階層的符号化では、各層は独自のセッション帯域幅パラメータを持つ別々の RTP セッションである。
セッション帯域幅パラメータは、セッション管理アプリケーションがメディアアプリケーションを起動する際に与えられると期待されるが、メディアアプリケーションはセッションで選択された符号化の単一送信側データ帯域幅に基づく既定値を設定してよい。アプリケーションはまた、マルチキャストスコープ規則やその他の基準に基づく帯域幅制限を強制してよい。すべての参加者は、同じ RTCP 間隔が計算されるよう、セッション帯域幅に同じ値を用いなければならない。
制御トラフィックおよびデータトラフィックの帯域幅計算には、下位層のトランスポートおよびネットワークプロトコル（UDP や IP など）が含まれる。これはリソース予約システムが知る必要があるものであるためである。アプリケーションはこれらのプロトコルのどれが使用中かを知っていると期待される。リンクレベルヘッダは、パケットが伝送中に異なるリンクレベルヘッダでカプセル化されるため、計算に含まれない。
制御トラフィックは、セッション帯域幅の小さく既知の割合に制限されるべきである。小さくあるのは、データを運ぶというトランスポートプロトコルの主たる機能が損なわれないようにするためであり、既知であるのは、制御トラフィックをリソース予約プロトコルに与えられる帯域幅仕様に含められ、かつ各参加者が自らの分担を独立に計算できるようにするためである。制御トラフィックの帯域幅は、データトラフィックのセッション帯域幅に加えて別途必要となる。RTCP のために追加されるセッション帯域幅の割合は 5% に固定されることが推奨される。また、RTCP 帯域幅の 1/4 をデータを送信する参加者に専念させることが推奨される。そうすれば、多数の受信側と少数の送信側を持つセッションで、新たに参加した者が送信サイトの CNAME をより迅速に受信できる。送信側の割合が参加者の 1/4 を超える場合、送信側は RTCP 帯域幅全体のその割合を獲得する。これらの定数および間隔計算内の他の定数の値は重要ではないが、同じ間隔が計算されるよう、セッション内のすべての参加者が同じ値を用いなければならない。したがって、これらの定数は特定のプロファイルに対して固定されるべきである。
プロファイルは、制御トラフィック帯域幅がセッション帯域幅の厳密なパーセントではなく、別個のセッションパラメータであってよいと規定してよい。別個のパラメータを用いることで、レート適応アプリケーションは、セッション帯域幅パラメータで指定された最大帯域幅より低い「典型的な」データ帯域幅に一致する RTCP 帯域幅を設定できる。
プロファイルはさらに、能動的なデータ送信側とそうでない参加者向けに、制御トラフィック帯域幅が 2 つの別個のセッションパラメータに分割されてよいと規定してよい。これらのパラメータを S および R と呼ぶことにする。RTCP 帯域幅の 1/4 をデータ送信側に専念させるという勧告に従い、これら 2 パラメータの推奨デフォルト値はそれぞれ 1.25% および 3.75% となる。送信側の割合が参加者の S/(S+R) を超える場合、送信側はこれらパラメータの和のその割合を獲得する。2 つのパラメータを用いることで、非データ送信側の RTCP 帯域幅をゼロに設定しつつデータ送信側の RTCP 帯域幅を非ゼロに保つことで、特定のセッションについて RTCP 受信報告を完全に停止でき、メディア間同期のための送信側報告を引き続き送信できる。RTCP 受信報告の停止は推奨されない。なぜならそれらはセクション 6 冒頭に挙げた機能、とくに受信品質フィードバックおよび輻輳制御に必要だからである。しかし、単方向リンク上で動作するシステムや、受信品質や受信側の生存性に関するフィードバックを必要とせず、輻輳回避の他の手段を持つセッションに対しては、適切であり得る。
複合 RTCP パケット間の計算間隔には、参加者数が少なく大きな数の法則による平滑化が効かない場合にパケットの突発が許容帯域幅を超えるのを避けるための下限も設けられるべきである。また、ネットワーク分割などの一時的な障害時に報告間隔が小さくなりすぎるのを防ぎ、分割が癒えた際の適応の遅延を防ぐ。アプリケーション起動時には、報告間隔がより迅速に正しい値へ収束するよう、他の参加者からの RTCP パケットを受信する時間を確保するため、最初の複合 RTCP パケット送信前に遅延を課すべきである。この遅延は、新たな参加者の存在をより迅速に通知するため、最小間隔の半分に設定されてよい。固定最小間隔の推奨値は 5 秒である。
実装は、以下の制限の下で、最小 RTCP 間隔をセッション帯域幅パラメータに反比例するより小さな値へ縮小してよい。
o マルチキャストセッションでは、能動的なデータ送信側のみが縮小された最小値を用いて複合 RTCP パケットの送信間隔を計算してよい。
o ユニキャストセッションでは、能動的なデータ送信側でない参加者も縮小された値を用いてよく、初期複合 RTCP パケット送信前の遅延はゼロであってよい。
o すべてのセッションについて、参加者タイムアウト間隔（セクション 6.3.5 参照）を計算する際には固定最小値を用いるべきである。これは、RTCP パケット送信に縮小値を用いない実装が他の参加者から早期にタイムアウトされるのを防ぐためである。
o 秒単位の縮小最小値の推奨値は、セッション帯域幅（キロビット／秒）を 360 で割った値である。この最小値は、帯域幅が 72 kb/s を超える場合に 5 秒より小さい。
セクション 6.3 および付録 A.7 で記述されるアルゴリズムは、本節で概説した目標を達成するよう設計された。それは、参加者間で許容制御トラフィック帯域幅を分割するため、複合 RTCP パケット送信間の間隔を計算する。これにより、アプリケーションは、たとえば全参加者の識別が重要な小規模セッションで高速な応答を提供しつつ、大規模セッションへ自動的に適応できる。このアルゴリズムは以下の特性を取り入れている。
o 計算された RTCP パケット間の間隔は、グループ内のメンバ数に比例して線形に拡張する。この線形の要因により、全メンバにわたり合計したとき一定量の制御トラフィックが得られる。
o RTCP パケット間の間隔は、すべての参加者の意図せざる同期を避けるため [20]、計算間隔の [0.5, 1.5] 倍の範囲でランダムに変動する。セッション参加後に送信される最初の RTCP パケットも、最小 RTCP 間隔の半分のランダム変動により遅延される。
o 受信および送信されたすべてのパケットを含む、複合 RTCP パケットの平均サイズの動的推定が計算され、運ばれる制御情報量の変化に自動的に適応する。
o 計算間隔は観測されたグループメンバ数に依存するため、新たな利用者が既存セッションに参加する場合や多くの利用者が同時に新セッションに参加する場合に、望ましくない起動効果が生じ得る。これらの新利用者は当初、グループメンバシップの推定が不正確であるため、RTCP 送信間隔が短かすぎる。多くの利用者が同時にセッションに参加する場合、この問題は重大になり得る。これに対処するため、「タイマ再考慮 (timer reconsideration)」と呼ばれるアルゴリズムが採用される。このアルゴリズムは、グループサイズが増大している場合に利用者が RTCP パケット送信を控えるよう促す単純なバックオフメカニズムを実装する。
o 利用者が BYE やタイムアウトによりセッションを退出する場合、グループメンバシップは減少し、したがって計算間隔も減少すべきである。グループメンバシップの減少に応じてメンバがより迅速に間隔を短縮できるよう、「逆再考慮 (reverse reconsideration)」アルゴリズムが用いられる。
o BYE パケットは他の RTCP パケットと異なる扱いを受ける。利用者がグループを離れ、BYE パケットを送信したい場合、それは次に予定された RTCP パケットの前に送信してよい。しかし BYE の送信は、多数のメンバが同時にセッションを退出した際の BYE パケットの洪水を避けるバックオフアルゴリズムに従う。
このアルゴリズムは、すべての参加者が送信を許可されるセッションに用いてよい。その場合、セッション帯域幅パラメータは個々の送信側の帯域幅と参加者数の積であり、RTCP 帯域幅はその 5% である。
アルゴリズムの動作の詳細は以下の各節で与える。付録 A.7 に実装例を示す。
6.2.1 セッションメンバ数の維持 (Maintaining the Number of Session Members)
RTCP パケット間隔の計算は、セッションに参加しているサイト数の推定に依存する。新たなサイトは、それらが聞こえたときにカウントに加えられ、各サイトについて SSRC または CSRC 識別子で索引付けられた表（セクション 8.2 参照）にエントリを作成して追跡すべきである (SHOULD)。新エントリは、新たな SSRC を持つ複数のパケットを受信するまで（付録 A.1 参照）、あるいはその SSRC の CNAME を含む SDES RTCP パケットを受信するまで、有効とみなされなくてよい (MAY)。エントリは、対応する SSRC 識別子を持つ RTCP BYE パケットを受信したときに表から削除されてよい (MAY) が、BYE の後にいくつかの遅れのデータパケットが到着しエントリが再作成される可能性がある。代わりに、エントリは BYE を受信したとマークされ、その後適切な遅延の後に削除されるべきである。
参加者は、わずかな数の RTCP 報告間隔（5 を推奨）の間、RTP または RTCP パケットを受信していない場合、他のサイトを非アクティブとマークしてよく (MAY)、あるいはまだ有効でなければ削除してよい (MAY)。これはパケットロスに対するある程度の頑健性を提供する。すべてのサイトはこの乗数に同じ値を用い、このタイムアウトが正しく機能するよう RTCP 報告間隔のほぼ同じ値を計算しなければならない。したがって、この乗数は特定のプロファイルに対して固定されるべきである。
非常に多数の参加者を持つセッションでは、それらすべての SSRC 識別子と状態情報を格納する表を維持することは非現実的であり得る。実装は、[21] で記述されるように SSRC サンプリングを用いて記憶要件を低減してよい (MAY)。実装は同様の性能を持ついかなる他のアルゴリズムを用いてもよい (MAY)。重要な要件は、いかなる検討されるアルゴリズムも過小推定を実質的に避けるべき (SHOULD NOT) ことであるが、過大推定は許容される。
6.3 RTCP パケットの送信および受信規則 (RTCP Packet Send and Receive Rules)
ここでは、RTCP パケットを送信する方法、および受信時に何を行うかの規則を概説する。マルチキャスト環境またはマルチポイントユニキャスト環境での動作を許す実装は、セクション 6.2 の要件を満たさなければならない。そのような実装は、これらの要件を満たすため本節で定義されたアルゴリズムを用いてもよく (MAY)、同等以上の性能を提供する限り他のアルゴリズムを用いてもよい (MAY)。二者間ユニキャスト動作に制約された実装は、同じ環境で動作する複数のインスタンスの意図せざる同期を避めるため、RTCP 送信間隔のランダム化を用いるべきである (SHOULD) が、セクション 6.3.3、6.3.6、および 6.3.7 の「タイマ再考慮」および「逆再考慮」アルゴリズムを省略してよい (MAY)。
これらの規則を実行するため、セッション参加者はいくつかの状態を維持しなければならない。
tp：最後に RTCP パケットを送信した時刻。
tc：現在の時刻。
tn：RTCP パケットの次に予定された送信時刻。
pmembers：tn が最後に再計算されたときのセッションメンバの推定数。
members：セッションメンバ数の最新の推定値。
senders：セッション内の送信側数の最新の推定値。
rtcp_bw：目標 RTCP 帯域幅。すなわち、本セッションの全メンバが RTCP パケットに使用する帯域幅の総量（オクテット毎秒）。これは起動時にアプリケーションに与えられる「セッション帯域幅」パラメータの規定の割合となる。
we_sent：アプリケーションが前々回の RTCP 報告送信以降にデータを送信した場合に真となるフラグ。
avg_rtcp_size：この参加者が送受信した全 RTCP パケットにわたる平均複合 RTCP パケットサイズ（オクテット）。サイズには、セクション 6.2 で説明されるよう、下位層トランスポートおよびネットワークプロトコルヘッダ（UDP や IP など）が含まれる。
initial：アプリケーションがまだ RTCP パケットを送信していない場合に真となるフラグ。
これらの規則の多くは、パケット送信間の「計算間隔 (calculated interval)」を用いる。この間隔は次節で記述される。
6.3.1 RTCP 送信間隔の計算 (Computing the RTCP Transmission Interval)
拡張性を維持するため、セッション参加者からのパケット間の平均間隔はグループサイズとともに拡張すべきである。この間隔は計算間隔と呼ばれる。これは上記の状態のいくつかを組み合わせることで得られる。計算間隔 T は以下のように決定される。
-
送信側数がメンバシップ（members）の 25% 以下の場合、間隔は参加者が送信側か否か（we_sent の値に基づく）に依存する。参加者が送信側（we_sent が真）の場合、定数 C は平均 RTCP パケットサイズ（avg_rtcp_size）を RTCP 帯域幅（rtcp_bw）の 25% で割った値に設定され、定数 n は送信側数に設定される。we_sent が真でない場合、定数 C は平均 RTCP パケットサイズを RTCP 帯域幅の 75% で割った値に設定される。定数 n は受信側数（members - senders）に設定される。送信側数が 25% を超える場合、送信側と受信側は一緒に扱われる。定数 C は平均 RTCP パケットサイズを RTCP 帯域幅全体で割った値に設定され、n はメンバ総数に設定される。セクション 6.2 で述べたように、RTP プロファイルは、送信側と非送信側について RTCP 帯域幅を 2 つの別個のパラメータ（S および R と呼ぶ）で明示的に定義してよい。その場合、25% の割合は S/(S+R) となり、75% の割合は R/(S+R) となる。R がゼロの場合、送信側の割合が S/(S+R) を超えることはなく、実装はゼロ除算を避けなければならないことに注意。
-
参加者がまだ RTCP パケットを送信していない（変数 initial が真）場合、定数 Tmin は 2.5 秒に設定され、さもなければ 5 秒に設定される。
-
決定論的計算間隔 Td は max(Tmin, n*C) に設定される。
-
計算間隔 T は、決定論的計算間隔の 0.5 倍から 1.5 倍の一様分布の数に設定される。
-
得られた T の値は、タイマ再考慮アルゴリズムが意図された平均より低い RTCP 帯域幅の値へ収束するという事実を補償するため、e-3/2=1.21828 で除される。
この手続きはランダムな間隔をもたらすが、平均として送信側に少なくとも RTCP 帯域幅の 25% を、残りを受信側に与える。送信側がメンバシップの 4 分の 1 を超える場合、この手続きは平均としてすべての参加者間で帯域幅を均等に分割する。
6.3.2 初期化 (Initialization)
セッションに参加した際、参加者は tp を 0 に、tc を 0 に、senders を 0 に、pmembers を 1 に、members を 1 に、we_sent を偽に、rtcp_bw をセッション帯域幅の規定割合に、initial を真に、avg_rtcp_size をアプリケーションがのちに構成する最初の RTCP パケットの推定サイズに初期化する。計算間隔 T が計算され、最初のパケットは
時刻 tn = T に予定される。これは、時刻 T に満了する送信タイマが設定されることを意味する。アプリケーションはこのタイマの実装に任意の方式を用いてよいことに注意。
参加者は自らの SSRC をメンバ表に加える。
6.3.3 RTP または非 BYE RTCP パケットの受信 (Receiving an RTP or Non-BYE RTCP Packet)
SSRC がメンバ表にない参加者から RTP または RTCP パケットを受信した場合、その SSRC が表に加えられ、参加者がセクション 6.2.1 で記述されるように妥当性検証された後に members の値が更新される。妥当性検証された RTP パケット内の各 CSRC についても同じ処理が行われる。
SSRC が送信側表にない参加者から RTP パケットを受信した場合、その SSRC が表に加えられ、senders の値が更新される。
受信した複合 RTCP パケットごとに、avg_rtcp_size の値が更新される。
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
ここで packet_size は受信した RTCP パケットのサイズである。
6.3.4 RTCP BYE パケットの受信 (Receiving an RTCP BYE Packet)
セクション 6.3.7 で RTCP BYE の送信時の場合について記述されることを除き、受信パケットが RTCP BYE パケットの場合、その SSRC がメンバ表と照合される。存在すれば、エントリは表から削除され、members の値が更新される。つぎにその SSRC が送信側表と照合される。存在すれば、エントリは表から削除され、senders の値が更新される。
さらに、RTCP パケットの送信レートをグループメンバシップの変化に適応させるため、members を pmembers より小さい値に減少させる BYE パケットを受信した場合、以下の「逆再考慮 (reverse reconsideration)」アルゴリズムを実行すべきである (SHOULD)。
o tn の値は以下の式により更新される。
tn = tc + (members/pmembers) * (tn - tc)
o tp の値は以下の式により更新される。
tp = tc - (members/pmembers) * (tc - tp)
o 次の RTCP パケットは、より早い時刻である tn で送信するよう再スケジュールされる。
o pmembers の値は members に等しく設定される。
このアルゴリズムは、大規模セッションの大部分の参加者が一度に退出し一部が残る場合に、早期タイムアウトによりグループサイズ推定が短時間誤ってゼロへ低下するのを防ぐものではない。このアルゴリズムは推定が正しい値へより迅速に回復するようにする。この状況は十分に珍しく、その結果は十分に無害であるため、この問題は二次的な懸念に過ぎないとみなされる。
6.3.5 SSRC のタイムアウト (Timing Out an SSRC)
時折の間隔で、参加者は他の参加者のいずれかがタイムアウトしたか確認しなければならない (MUST)。これを行うため、参加者は受信側（すなわち we_sent が偽）についての決定論的（ランダム化係数なし）計算間隔 Td を計算する。時刻 tc - MTd（M はタイムアウト乗数、デフォルト 5）以降に RTP または RTCP パケットを送信していない他のセッションメンバはタイムアウトとされる。これはその SSRC がメンバリストから削除され、members が更新されることを意味する。送信側リストについても同様のチェックが行われる。時刻 tc - 2T（最後の 2 つの RTCP 報告間隔内）以降に RTP パケットを送信していない送信側リスト上のメンバは、送信側リストから削除され、senders が更新される。
メンバがタイムアウトした場合、セクション 6.3.4 で記述される逆再考慮アルゴリズムを実行すべきである (SHOULD)。
参加者はこのチェックを少なくとも RTCP 送信間隔ごとに 1 回は実行しなければならない (MUST)。
6.3.6 送信タイマの満了 (Expiration of Transmission Timer)
パケット送信タイマが満了したとき、参加者は以下の操作を実行する。
o 送信間隔 T はセクション 6.3.1 で記述されるように、ランダム化係数を含めて計算される。
o tp + T が tc 以下の場合、RTCP パケットが送信される。tp は tc に設定され、つぎに前ステップと同様に別の T の値が計算され、tn は tc + T に設定される。送信タイマは時刻 tn で再び満了するよう設定される。tp + T が tc より大きい場合、tn は tp + T に設定される。RTCP パケットは送信されない。送信タイマは時刻 tn で満了するよう設定される。
o pmembers は members に設定される。
RTCP パケットが送信された場合、initial の値は偽 (FALSE) に設定される。さらに、avg_rtcp_size の値が更新される。
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
ここで packet_size は送信された RTCP パケットのサイズである。
6.3.7 BYE パケットの送信 (Transmitting a BYE Packet)
参加者がセッションを退出したい場合、その事象を他の参加者に通知するため BYE パケットが送信される。多くの参加者がシステムを退出する際の BYE パケットの洪水を避けるため、参加者が退出を選択したときのメンバ数が 50 を超える場合、参加者は以下のアルゴリズムを実行しなければならない (MUST)。このアルゴリズムは、members 変数の通常の役割を横取りし、代わりに BYE パケットを数える。
o 参加者がシステムを退出することを決定したとき、tp は現在時刻 tc にリセットされ、members および pmembers は 1 に初期化され、initial は 1 に、we_sent は偽に、senders は 0 に、avg_rtcp_size は複合 BYE パケットのサイズに設定される。計算間隔 T が計算される。BYE パケットは時刻 tn = tc + T に予定される。
o 他の参加者からの BYE パケットを受信するたびに、その参加者がメンバ表に存在するか否か、および SSRC サンプリングを用いる場合はその BYE の SSRC がサンプルに含まれるか否かにかかわらず、members が 1 増加する。members が増加するのは BYE パケットのみであり、他の RTCP パケットや RTP パケットを受信しても増加しない。同様に、avg_rtcp_size は受信した BYE パケットについてのみ更新される。senders は RTP パケットの到着時に更新されず、0 のままである。
o BYE パケットの送信は、以上の通常の RTCP パケット送信規則に従う。
これにより BYE パケットを即座に送信できるが、その全帯域幅使用を制御できる。最悪の場合、RTCP 制御パケットが通常の 2 倍（10%）の帯域幅を使用することになる――非 BYE RTCP パケットに 5%、BYE に 5% である。
上記メカニズムが BYE パケットの送信を許可するのを待ちたくない参加者は、BYE をまったく送信せずにグループを退出してよい (MAY)。その参加者は最終的に他のグループメンバによりタイムアウトされる。
参加者が退出を決定したときのグループサイズ推定 members が 50 未満の場合、参加者は BYE パケットを直ちに送信してよい (MAY)。あるいは、参加者は上記の BYE バックオフアルゴリズムを実行することを選んでもよい (MAY)。
いずれの場合も、一度も RTP または RTCP パケットを送信していない参加者は、グループ退出時に BYE パケットを送信してはならない (MUST NOT)。
6.3.8 we_sent の更新 (Updating we_sent)
変数 we_sent は、参加者が最近 RTP パケットを送信していれば真、さもなければ偽を含む。この判定は、送信側表に列挙された他の参加者の集合を管理するのと同じメカニズムを用いて行われる。we_sent が偽のとき参加者が RTP パケットを送信した場合、それは自身を送信側表に加え、we_sent を真に設定する。SR パケット送信前の遅延を短縮し得るよう、セクション 6.3.4 で記述される逆再考慮アルゴリズムを実行すべきである (SHOULD)。別の RTP パケットが送信されるたびに、そのパケットの送信時刻が表に維持される。通常の送信側タイムアウトアルゴリズムがその参加者に適用される――時刻 tc - 2T 以降に RTP パケットが送信されていなければ、参加者は自身を送信側表から削除し、送信側カウントを減らし、we_sent を偽に設定する。
6.3.9 ソース記述帯域幅の配分 (Allocation of Source Description Bandwidth)
本書は、必須の CNAME 項に加え、NAME（個人名）や EMAIL（電子メールアドレス）などのいくつかのソース記述 (SDES) 項を定義する。また新たなアプリケーション固有 RTCP パケット種別を定義する手段も提供する。アプリケーションは、この追加情報へ制御帯域幅を配分する際に注意を払うべきである。なぜならそれは受信報告および CNAME の送信レートを遅くし、ひいてはプロトコルの性能を損なうからである。単一参加者に配分された RTCP 帯域幅の 20% を超える分を追加情報の運搬に使用しないことが推奨される。さらに、すべての SDES 項がすべてのアプリケーションに含まれることを意図するものではない。含まれるものは、その有用性に応じて帯域幅の一部が割り当てられるべきである (SHOULD)。これらの割合を動的に推定するよりはむしろ、項の典型的な長さに基づき、これらのパーセントを静的に報告間隔カウントへ変換することが推奨される。
たとえばアプリケーションは、CNAME、NAME、および EMAIL のみを送信し、それ以外は送信しないように設計されてよい。NAME はアプリケーションのユーザインタフェースに連続的に表示されるのに対し、EMAIL は要求されたときのみ表示されるため、NAME には EMAIL よりはるかに高い優先度が与えられてよい。すべての RTCP 間隔において、RR パケットと CNAME 項を持つ SDES パケットが送信される。最小間隔で動作する小規模セッションでは、平均して 5 秒ごととなる。3 回に 1 回の間隔（15 秒）ごとに、SDES パケットに 1 つ余分な項が含まれる。8 回中 7 回はそれが NAME 項であり、8 回に 1 回（2 分）は EMAIL 項となる。
複数のアプリケーションが、各参加者について共通の CNAME を用いたアプリケーション間結合 (cross-application binding) によって協調して動作する場合、たとえば各メディアの RTP セッションからなるマルチメディア会議において、追加の SDES 情報は 1 つの RTP セッションのみで送信されてよい (MAY)。他のセッションは CNAME 項のみを運ぶ。とくにこの手法は、階層的符号化方式の複数セッション（セクション 2.4 参照）に適用されるべきである。
6.4 送信側および受信側報告 (Sender and Receiver Reports)
RTP 受信側は、受信側が送信側でもあるか否かに応じて 2 つの形式のいずれかをとり得る RTCP 報告パケットを用いて受信品質フィードバックを提供する。送信側報告 (SR) と受信側報告 (RR) の形式の唯一の違いは、パケット種別コードを除き、送信側報告が能動的送信側が用いる 20 オクテットの送信側情報セクションを含むことである。サイトが最後の報告以降の間隔において何らかのデータパケットを送信していた場合は SR が発行され、さもなければ RR が発行される。
SR および RR の両形式は、この受信側が最後の報告以降に RTP データパケットを受信した各同期送信元につき 1 つずつ、0 個以上の受信報告ブロックを含む。CSRC リストに列挙された寄与送信元についての報告は発行されない。各受信報告ブロックは、そのブロックで示された特定の送信元から受信したデータに関する統計を提供する。SR または RR パケットに最大 31 個の受信報告ブロックが収まるため、最後の報告以降に聞こえたすべての送信元の受信報告を含めるため、必要に応じ初期の SR または RR パケットの後に追加の RR パケットを積み重ねるべきである (SHOULD)。すべての必要な RR パケットをネットワークパスの MTU を超えずに 1 つの複合 RTCP パケットに収めるのに送信元が多すぎる場合、各間隔には 1 つの MTU に収まる部分集合のみを含めるべきである (SHOULD)。部分集合はすべての送信元が報告されるよう、複数の間隔にわたりラウンドロビンで選択されるべきである (SHOULD)。
以下の各節は、2 つの報告の形式、アプリケーションが追加フィードバック情報を必要とする場合にプロファイル固有の方法でそれらを拡張する方法、および報告を用いる方法を定義する。トランスレータおよびミキサによる受信報告の詳細はセクション 7 にある。
6.4.1 SR: 送信側報告 RTCP パケット (SR: Sender Report RTCP Packet)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=SR=200 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ sender | NTP timestamp, most significant word | info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_1 (SSRC of first source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_2 (SSRC of second source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
送信側報告パケットは 3 つのセクションからなり、定義されていればその後に 4 つ目のプロファイル固有拡張セクションが続くことがある。第 1 セクションであるヘッダは 8 オクテット長である。各フィールドの意味は以下のとおり。
version (V)：2 ビット RTP のバージョンを識別する。これは RTP データパケットと同じである。本書で定義されるバージョンは 2 である。
padding (P)：1 ビット パディングビットがセットされている場合、この個別の RTCP パケットは、制御情報の一部ではないが長さフィールドに含まれるいくつかの追加パディングオクテットを末尾に含む。パディングの最後のオクテットは、それ自身を含め何個のパディングオクテットを無視すべきかのカウントである（4 の倍数となる）。いくつかの固定ブロックサイズの暗号化アルゴリズムにパディングが必要となる場合がある。複合 RTCP パケットでは、セクション 9.1 の方式で複合パケット全体が暗号化されるため、パディングは 1 つの個別パケットのみに必要である。したがって、パディングは最後の個別パケットにのみ追加されなければならず (MUST)、そのパケットにパディングが追加される場合、パディングビットはそのパケットにのみセットされなければならない (MUST)。この慣習は付録 A.2 で記述されるヘッダ妥当性検査を助け、最初の個別パケットに誤ってパディングビットをセットし最後の個別パケットにパディングを追加した一部の初期実装のパケットを検出できる。
reception report count (RC)：5 ビット このパケットに含まれる受信報告ブロックの数。値 0 も有効である。
packet type (PT)：8 ビット このパケットが RTCP SR パケットであることを識別する定数 200 を含む。
length：16 ビット この RTCP パケットの長さを、ヘッダおよび任意のパディングを含め、32 ビットワード単位でマイナス 1 としたもの。オフセット 1 によりゼロが有効な長さとなり、複合 RTCP パケットの走査における無限ループを回避し、32 ビットワードを数えることで 4 の倍数の妥当性検査を避ける。
SSRC：32 ビット この SR パケットの発信元の同期送信元識別子。
第 2 セクションである送信側情報は 20 オクテット長で、すべての送信側報告パケットに存在し、この送信側からのデータ送信を要約する。各フィールドの意味は以下のとおり。
NTP timestamp：64 ビット この報告が送信された掛時計時刻（セクション 4 参照）を示し、他の受信側からの受信報告で返されるタイムスタンプと組み合わせて、それらの受信側への往復伝播を測定するために用いられ得る。受信側は、タイムスタンプの測定精度が NTP タイムスタンプの分解能よりはるかに低く制限され得ることを期待すべきである。タイムスタンプの測定不確かさは判明しない場合があるため指示されない。掛時計時刻の概念はないが「システム稼働時間 (system uptime)」のようなシステム固有クロックを持つシステムでは、送信側はそのクロックを参照として相対 NTP タイムスタンプを計算してよい (MAY)。共通して用いられるクロックを選ぶことが重要であり、そうすればマルチメディアセッションの個別ストリームを生成するために別々の実装が用いられる場合でも、すべての実装が同じクロックを用いる。2036 年までは、相対タイムスタンプと絶対タイムスタンプは上位ビットで異なり、（無効な）比較は大きな差を示す。その頃には相対タイムスタンプはもはや不要となっていることが望まれる。掛時計時刻も経過時刻も概念を持たない送信側は、NTP タイムスタンプをゼロに設定してよい (MAY)。
RTP timestamp：32 ビット NTP タイムスタンプ（上）と同じ時刻に対応するが、データパケットの RTP タイムスタンプと同じ単位、同じランダムオフセットを持つ。この対応は、NTP タイムスタンプが同期されたソースのメディア内およびメディア間同期に用いられ、メディア非依存の受信側が標準 RTP クロック周波数を推定するために用いられ得る。多くの場合、このタイムスタンプは隣接するデータパケットの RTP タイムスタンプと等しくないことに注意。むしろ、それは RTP タイムスタンプカウンタと実時間の関係を用いて対応する NTP タイムスタンプから計算されなければならない (MUST)。
sender's packet count：32 ビット 転送の開始からこの SR パケットの生成時までに、送信側が送信した RTP データパケットの総数。送信側が SSRC 識別子を変更した場合、このカウントはリセットされるべきである (SHOULD)。
sender's octet count：32 ビット 転送の開始からこの SR パケットの生成時までに、送信側が RTP データパケットで送信したペイロードオクテット数（すなわち、ヘッダやパディングを除く）。送信側が SSRC 識別子を変更した場合、このカウントはリセットされるべきである (SHOULD)。このフィールドは平均ペイロードデータレートの推定に用いられ得る。
第 3 セクションは、前回の報告以降にこの送信側が聞いた他の送信元の数に応じて、0 個以上の受信報告ブロックを含む。各受信報告ブロックは、単一の同期送信元から受信した RTP データパケットに関する統計を伝える。送信元が衝突により SSRC 識別子を変更した場合、受信側は統計を引き継ぐべきではない (SHOULD NOT)。これらの統計は以下のとおり。
SSRC_n（送信元識別子）：32 ビット この受信報告ブロックの情報の対象となる送信元の SSRC 識別子。
fraction lost：8 ビット 最後に SR または RR パケットを送信して以来、送信元 SSRC_n からの RTP データパケットのうち失われた割合。小数点がフィールド左端にある固定小数点数として表される（すなわち、失われた割合に 256 を乗じた整数部に等しい）。この割合は、以下の段落で定義されるように、期待されたパケット数で除した失われたパケット数として定義される。実装例は付録 A.3 にある。重複パケットのため失われた数が負となる場合、fraction lost はゼロに設定される。受信側は最後に受信したパケット以降にパケットが失われたか判断できず、また最後の報告間隔においてその送信元のすべてのパケットが失われた場合、その送信元の受信報告ブロックは発行されないことに注意。
cumulative number of packets lost：24 ビット 受信開始以来、送信元 SSRC_n からの RTP データパケットのうち失われた総数。この数は期待されたパケット数から実際に受信したパケット数（遅延または重複パケットを含む）を引いたものとして定義される。したがって遅延パケットは失われたものとはみなされず、重複パケットが存在すれば失われた数は負になり得る。期待されたパケット数は、以下で定義される拡張最高シーケンス番号から初期的に受信したシーケンス番号を引いたものとして定義され、付録 A.3 のように計算できる。
extended highest sequence number received：32 ビット 下位 16 ビットは送信元 SSRC_n から受信した RTP データパケットの最高シーケンス番号を含み、最上位 16 ビットは対応するシーケンス番号サイクル（cycle）カウントによってそのシーケンス番号を拡張したもので、このカウントは付録 A.1 のアルゴリズムにより維持できる。同じセッション内の異なる受信側であっても、起動時刻が大きく異なれば拡張シーケンス番号が異なり得ることに注意。
interarrival jitter：32 ビット RTP データパケットの到着間隔の統計的分散の推定値。タイムスタンプ単位で表され、符号なし整数として表現される。到着間ジッタ J は、1 組のパケットについて、受信側におけるパケット間隔と送信側におけるそれとの差 D の平均偏差（平滑化された絶対値）として定義される。以下に示すように、これは 2 つのパケットの「相対伝播時間 (relative transit time)」の差に等しい。相対伝播時間とは、パケットの RTP タイムスタンプとそれが到着したときの受信側クロックとの差を、同じ単位で表したものである。
Si をパケット i の RTP タイムスタンプ、Ri をパケット i の到着時刻（RTP タイムスタンプ単位）とすると、2 つのパケット i および j について、D は次のように表される。
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
到着間ジッタは、送信元 SSRC_n からの各データパケット i の到着に伴い、そのパケットと前のパケット i-1（到着順、必ずしもシーケンス順ではない）との差 D を用いて、以下の式に従って連続的に計算されるべきである (SHOULD)。
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
受信報告が発行されるたびに、J の現在値がサンプリングされる。
ジッタ計算は、プロファイル非依存のモニタが異なる実装からの報告を有効に解釈できるよう、本書に規定された式に従わなければならない (MUST)。このアルゴリズムは、良好なノイズ抑制比を維持しつつ妥当な収束速度を得る最適な 1 次推定器であり、ゲイン 1/16 を用いる [22]。実装例は付録 A.8 にある。伝送前パケット持続時間と遅延変動の影響についての議論はセクション 6.4.4 にある。
last SR timestamp (LSR)：32 ビット 送信元 SSRC_n から最後に受信した RTCP 送信側報告（SR）パケットの一部として運ばれた NTP タイムスタンプ（セクション 4 参照）の 64 ビットのうち中間 32 ビット。SR を受信していない場合、このフィールドはゼロに設定される。
delay since last SR (DLSR)：32 ビット 送信元 SSRC_n の最後の SR パケットを受信してからこの受信報告ブロックを送信するまでの遅延。1/65536 秒単位で表される。SSRC_n から SR パケットを受信していない場合、DLSR フィールドはゼロに設定される。
SSRC_r をこの受信側報告を発行する受信側とする。送信元 SSRC_n は、この受信報告ブロックを受信した時刻 A を記録することで、SSRC_r への往復伝播遅延を計算できる。それは last SR timestamp (LSR) フィールドを用いて全往復時間 A-LSR を計算し、このフィールドを引くことで、往復伝播遅延は (A - LSR - DLSR) となる。これを図 2 に示す。時刻は 32 ビットフィールドの 16 進表現と等価の浮動小数点 10 進表現の両方で示される。コロンは 32 ビットフィールドが 16 ビットの整数部と 16 ビットの小数部に分割されることを示す。
これは受信側をクラスタ化する距離の近似尺度として用いられ得るが、一部のリンクは非対称な遅延を持ち得る。
[10 Nov 1995 11:33:25.125 UTC] [10 Nov 1995 11:33:36.5 UTC] n SR(n) A=b710:8000 (46864.500 s) ----------------------------------------------------------------> v ^ ntp_sec =0xb44db705 v ^ dlsr=0x0005:4000 ( 5.250s) ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s) (3024992005.125 s) v ^ r v ^ RR(n) ----------------------------------------------------------------> |<-DLSR->| (5.250 s)
A 0xb710:8000 (46864.500 s) DLSR -0x0005:4000 ( 5.250 s) LSR -0xb705:2000 (46853.125 s)
delay 0x0006:2000 ( 6.125 s)
Figure 2: Example for round-trip time computation
6.4.2 RR: 受信側報告 RTCP パケット (RR: Receiver Report RTCP Packet)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| SC | PT=RR=201 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_1 (SSRC of first source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_2 (SSRC of second source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
受信側報告 (RR) パケットの形式は SR パケットと同じであるが、パケット種別フィールドに定数 201 が含まれ、5 ワードの送信側情報（すなわち NTP および RTP タイムスタンプ、ならびに送信側のパケットカウントおよびオクテットカウント）が省略される。それ以外のフィールドの意味は SR パケットと同じである。
送受信されるデータがない場合、空の RR パケット（RC = 0）を複合 RTCP パケットの先頭に置かなければならない (MUST)。
6.4.3 送信側および受信側報告の拡張 (Extending the Sender and Receiver Reports)
プロファイルが送信側または受信側に関する追加情報を定期的に報告することを必要とする場合、送信側報告および受信側報告のプロファイル固有拡張を定義すべきである (SHOULD)。別の RTCP パケット種別を定義するよりも、この手法が優先されるべきである。なぜなら必要なオーバヘッドが小さいためである。
o パケット内のバイト数がより少ない（RTCP ヘッダや SSRC フィールドがない）。
o より単純かつ高速な解析が可能。そのプロファイル下で動作するアプリケーションは、受信報告の直後に拡張フィールドが置かれることを前提としてプログラムされるため。
この拡張は、送信側または受信側報告パケットの第 4 セクションであり、存在する場合は（あれば）受信報告ブロックの後に続く。追加の送信側情報が必要な場合、送信側報告についてはその情報をまず拡張セクションに含め、受信側報告については存在しない。受信側に関する情報を含める場合、そのデータは既存の受信報告ブロック配列と並行するブロック配列として構造化されるべきである (SHOULD)。すなわちブロック数は RC フィールドにより示される。
6.4.4 送信側および受信側報告の解析 (Analyzing Sender and Receiver Reports)
期待される受信品質フィードバックは、送信側にとってのみ有用なのではなく、他の受信側やサードパーティモニタにとっても有用である。送信側はフィードバックに基づき伝送を修正でき、受信側は問題が局所的か地域的か全域的かを判断でき、ネットワーク管理者はプロファイル非依存のモニタ（対応する RTP データパケットを受信せず RTCP パケットのみを受信する）を用いて、マルチキャスト配信に関するネットワーク性能を評価できる。
送信側情報および受信報告ブロックの両方に累積カウントが用いられているため、任意の 2 つの報告間で差を計算でき、短期間および長期間の両方の測定が可能となり、一部の報告が失われた場合にも強靭である。最後に受信した 2 つの報告間の差は、直近の配信品質を推定するために用いられる。NTP タイムスタンプは、2 つの報告間の間隔からこれらの差に基づくレートを計算するために含まれている。このタイムスタンプはデータ符号化のクロックレートから独立しているため、符号化およびプロファイルに依存しないサービス品質モニタが実現できる。
計算例の 1 つは、2 つの受信報告間の間隔におけるパケット欠落率である。累積欠落パケット数の差がその間隔で失われたパケット数を与え、拡張された最後に受信したシーケンス番号の差がその間隔で期待されたパケット数を与える。両者の比がその間隔におけるパケット欠落率である。2 つの報告が連続している場合、この比は fraction lost フィールドに等しくなるはずであるが、さもなければ異なり得る。欠落率（毎秒）は、欠落率を NTP タイムスタンプ差（秒単位）で除して得られる。受信パケット数は期待パケット数から失われたパケット数を引いたものである。期待パケット数は、任意の欠落推定の統計的妥当性を判断するためにも用いられ得る。たとえば 5 パケット中 1 つ失われることの意味は、1000 パケット中 200 失われることより小さい。
送信側情報から、サードパーティモニタはデータを受信せずに、ある間隔における平均ペイロードデータレートおよび平均パケットレートを計算できる。両者の比が平均ペイロードサイズを与える。パケット欠落がパケットサイズに依存しないと仮定できれば、特定の受信側が受信したパケット数に平均ペイロードサイズ（または対応するパケットサイズ）を乗じることで、その受信側が利用可能な見かけのスループットが得られる。
累積カウントによる報告間差を用いた長期欠落測定を可能にする一方、fraction lost フィールドは単一報告からの短期測定も提供する。セッション規模が拡大し、すべての受信側の受信状態情報を保持できなくなったり、報告間隔が長くて特定の受信側から 1 通の報告しか受信できない可能性が生じたりする場合、これはより重要となる。
interarrival jitter フィールドは、ネットワーク輻輳の第 2 の短期尺度を提供する。欠落は持続的輻輳を追跡し、ジッタは過渡的輻輳を追跡する。ジッタ尺度は、欠落に先立ち輻輳を示唆し得る。interarrival jitter フィールドは、報告時点のジッタのスナップショットであり、定量的に解釈されることを意図しない。むしろ、ある受信側が時間を通じて発行する複数の報告間、または複数の受信側間（たとえば同じネットワーク内で同時）で比較するために意図される。すべての受信側が同じ式でジッタを計算することは、受信側間の比較を可能にするために重要である。
ジッタ計算は RTP タイムスタンプ（パケット内の最初のデータがサンプリングされた時刻を示す）に基づくため、そのサンプリング時刻とパケットが伝送された時刻との間のいかなる遅延変動も、計算されたジッタに影響する。この遅延変動は、可変持続時間の音声パケットで生じる。映像符号化でも同様で、同じフレームのすべてのパケットは同じタイムスタンプを持つが同時に伝送されるわけではない。伝送前の遅延変動は、ジッタ計算をネットワーク自身の挙動の尺度として正確性を低下させるが、受信側バッファがそれを吸収しなければならないため、含めることが適切である。ジッタ計算が比較尺度として用いられる場合、伝送前遅延変動による（一定の）成分は相殺され、ネットワークジッタ成分の変化を観測でき、それが相対的に小さくない限りである。変化が小さければ、おそらく無関係である。
6.5 SDES: ソース記述 RTCP パケット (SDES: Source Description RTCP Packet)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| SC | PT=SDES=202 | length | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | SSRC/CSRC_1 | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | SSRC/CSRC_2 | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
SDES パケットは、ヘッダおよび 0 個以上のチャンク（chunk）からなる 3 階層構造であり、各チャンクはそのチャンクで識別された送信元を記述する項からなる。各項は後続の各節で記述される。
version (V)、padding (P)、length： SR パケットの場合と同様（セクション 6.4.1 参照）。
packet type (PT)：8 ビット このパケットが RTCP SDES パケットであることを識別する定数 202 を含む。
source count (SC)：5 ビット この SDES パケットに含まれる SSRC/CSRC チャンクの数。値 0 も有効だが無意味である。
各チャンクは、SSRC/CSRC 識別子と、その SSRC/CSRC に関する情報を運ぶ 0 個以上の項のリストからなる。各チャンクは 32 ビット境界から始まる。各項は、8 ビットの種別フィールド、8 ビットのバイトカウント（テキストの長さを記述し、したがってこの 2 バイトヘッダを含まない）、およびテキスト自身からなる。テキスト長は 255 バイトを超えられないが、これは RTCP 帯域幅消費を制限する必要性と一致する。
テキストは RFC 2279 [5] で規定される UTF-8 符号化により符号化される。US-ASCII はこの符号化の部分集合であり、追加の符号化を必要としない。複数バイト符号化の存在は、ある文字の最上位ビットを 1 に設定することで示される。
項は連続しており、つまり各項は 32 ビット境界に個別にはパディングされない。テキストは null で終端されない。なぜなら一部の複数バイト符号化は null バイトを含むためである。各チャンク内の項リストは、1 つ以上の null バイトで終端されなければならず (MUST)、最初の null バイトは種別 0 の項として解釈され、リストの終わりを示す。null 項種別バイトの後には長さバイトは続かないが、必要なら次の 32 ビット境界までパディングする追加の null バイトを含まなければならない (MUST)。このパディングは RTCP ヘッダの P ビットで示されるパディングとは別であることに注意。項を持たないチャンク（4 つの null バイト）は有効だが無意味である。
端末システムは、自身の送信元識別子（固定 RTP ヘッダの SSRC と同じ）を含む SDES パケットを送信する。ミキサは、それが SDES 情報を受信している各寄与送信元のチャンクを含む SDES パケットを送信する。あるいは、そのような送信元が 31 を超える場合、上記形式で複数の完全な SDES パケットを送信する（セクション 7 参照）。
現在定義されている SDES 項を以下の各節で記述する。CNAME 項のみが必須である。ここに示す一部の項は特定のプロファイルにのみ有用であり得るが、項種別はすべて同じ共通空間から割り当てられ、共有利用およびプロファイル非依存アプリケーションを促進する。追加項は、セクション 15 で記述されるようにプロファイル内で IANA に種別番号を登録することで定義されてよい。
6.5.1 CNAME: 正規端点識別子 SDES 項 (CNAME: Canonical End-Point Identifier SDES Item)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CNAME=1 | length | user and domain name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CNAME 識別子は以下の特性を持つ。
o SSRC 識別子はランダムに割り当てられ、衝突の発見やプログラム再起動時に変化し得るため、SSRC 識別子から送信元（送信側または受信側）に対して一定不変の識別子への結合を提供するため CNAME 項を含めなければならない (MUST)。
o SSRC 識別子と同様に、CNAME 識別子は RTP セッション内のすべての参加者間でも一意であるべきである (SHOULD)。
o 参加者が一連の関連 RTP セッションで用いる複数のメディアツール間の結合を提供するため、CNAME はその参加者に対して固定であるべきである (SHOULD)。
o サードパーティモニタリングを容易にするため、CNAME はプログラムまたは人間が送信元を特定するのに適したものであるべきである (SHOULD)。
したがって、可能な場合、CNAME は手動入力ではなくアルゴリズムから導出されるべきである (SHOULD)。これらの要求を満たすため、プロファイルが別の構文または意味論を規定しない限り、以下の形式を用いるべきである (SHOULD)。CNAME 項は "user@host" の形式、あるいは単一ユーザシステムのように利用可能なユーザ名がない場合は "host" の形式をとるべきである (SHOULD)。いずれの形式でも "host" は、リアルタイムデータの由来であるホストの完全修飾ドメイン名（RFC 1034 [6]、RFC 1035 [7]、および RFC 1123 [8] セクション 2.1 の規則による）、または RTP 通信に用いるインタフェース上のそのホストの数値アドレスの標準 ASCII 表現のいずれかである。たとえば IP バージョン 4 アドレスの標準 ASCII 表現は「ドット区切り 10 進 (dotted decimal)」（dotted quad とも）であり、IP バージョン 6 ではコロン区切りの 16 進数字グループのテキスト表現を用いる（詳細は RFC 3513 [23]）。他のアドレス種別は互いに異なる ASCII 表現を持つと予想される。完全修飾ドメイン名は人間が観察するのに便利で、NAME 項を別途送信する必要をなくし得るが、一部の実行環境では信頼できる取得が困難または不可能である。そのような環境で動作し得るアプリケーションは、代わりにアドレスの ASCII 表現を用いるべきである (SHOULD)。
例として、マルチユーザシステムでは "[email protected]"、"[email protected]"、または "doe@2201:056D::112E:144A:1E24"。ユーザ名のないシステムでは "sleepy.example.com"、"192.0.2.89"、または "2201:056D::112E:144A:1E24" である。
ユーザ名は "finger" や "talk" のようなプログラムで利用可能な形式、すなわち通常はログイン名であり個人名ではないものとすべきである (SHOULD)。ホスト名は必ずしもその参加者の電子メールアドレスのものと同一ではない。
アプリケーションが 1 台のホストから複数の送信元を生成することをユーザに許す場合、この構文は各送信元に一意の識別子を提供できない。そのようなアプリケーションは、SSRC にさらに依存して送信元を識別するか、あるいはそのアプリケーションのプロファイルが CNAME 識別子の追加構文を規定しなければならない。
各アプリケーションが独立に自らの CNAME を作成する場合、生成された CNAME は同一でない可能性があり、参加者が一連の関連 RTP セッションで用いる複数のメディアツール間の結合を提供するにはそれらが同一でなければならない。メディア間結合が必要な場合、各ツールの CNAME を外部から同一の値に設定する調整ツールが必要となる可能性がある。
アプリケーション作成者は、RFC 1918 [24] で提案されている Net-10 割り当てのようなプライベートネットワークアドレス割り当てが、必ずしもグローバルに一意でないネットワークアドレスをもたらし得ることに留意すべきである。プライベートアドレスを持ち公共インターネットに直接接続されていない送信元の RTP パケットが、RTP レベルのトランスレータを通じて公共インターネットへ転送される場合、それは非一意な CNAME をもたらす（RFC 1627 [25] も参照）。この状況に対処するため、アプリケーションは一意の CNAME を設定する手段を提供してよい (MAY) が、プライベートアドレスを隠したままにする必要がある場合、トランスレータは CNAME をプライベートアドレスからパブリックアドレスへ翻訳する責任を負う。
6.5.2 NAME: ユーザ名 SDES 項 (NAME: User Name SDES Item)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAME=2 | length | common name of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
これは送信元を記述する実名、たとえば "John Doe, Bit Recycler" である。任意の形式をとり得る。会議のようなアプリケーションでは、この姓名形式は参加者リストに最も適して表示される可能性があり、したがって CNAME 以外の項の中で最も頻繁に送信される可能性がある。プロファイルはこのような優先順位を設けてよい (MAY)。NAME 値はセッション中は少なくとも一定であると予想される。すべての参加者間で一意であることには依存すべきではない (SHOULD NOT)。
6.5.3 EMAIL: 電子メールアドレス SDES 項 (EMAIL: Electronic Mail Address SDES Item)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EMAIL=3 | length | email address of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
電子メールアドレスは RFC 2822 [9] の形式、たとえば "[email protected]" で書式化される。EMAIL 値はセッション中一定と予想される。
6.5.4 PHONE: 電話番号 SDES 項 (PHONE: Phone Number SDES Item)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHONE=4 | length | phone number of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
電話番号は国際接続コードの代わりにプラス記号を用いて書式化されるべきである (SHOULD)。たとえば米国の番号は "+1 908 555 1212" の形式である。
6.5.5 LOC: 地理的ユーザ位置 SDES 項 (LOC: Geographic User Location SDES Item)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LOC=5 | length | geographic location of site ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
アプリケーションにより、この項に適した詳細度は異なる。会議アプリケーションでは "Murray Hill, New Jersey" のような文字列で十分な場合があり、活動バッジシステムでは "Room 2A244, AT&T BL MH" のような文字列が適切であり得る。詳細度は実装および／またはユーザの決定に委ねられるが、形式および内容はプロファイルにより規定されてよい (MAY)。LOC 値はセッション中一定と予想され、移動ホストを除く。
6.5.6 TOOL: アプリケーションまたはツール名 SDES 項 (TOOL: Application or Tool Name SDES Item)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOOL=6 | length |name/version of source appl. ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
生成しているストリームのアプリケーション名、およびおそらくバージョン番号を与える文字列、たとえば "videotool 1.2"。この情報は SMTP の Mailer や Mail-System-Version ヘッダと同様、デバッグに有用であり得る。TOOL 値はセッション中一定と予想される。
6.5.7 NOTE: 通知／状態 SDES 項 (NOTE: Notice/Status SDES Item)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NOTE=7 | length | note about the source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
本項は以下の意味を提案するが、これらの意味または別の意味はプロファイルにより明示的に定義されてよい (MAY)。NOTE 項は送信元の現在の状態を表す一時的メッセージ、たとえば "on the phone, can't talk" を運ぶことを意図する。あるいは、ワークショップの期間中、この項を講演の題名を伝えるために用いてもよい。それは例外的情報を運ぶためにのみ用いるべきであり (SHOULD)、すべての参加者が常習的に含めるべきではない (SHOULD NOT)。なぜならそれは受信報告および CNAME の送信レートを遅くし、ひいてはプロトコル性能を損なうからである。とくに、ユーザプロファイル内の項として含めるべきではなく (SHOULD NOT)、「日替わりの名言 (quote-of-the-day)」のように自動生成されるべきでもない (SHOULD NOT)。
NOTE 項は活動中は重要であり表示される必要があるかもしれないため、他の非 CNAME 項（NAME など）の送信レートは低下し、NOTE 項がその RTCP 帯域幅の一部を占められるよう調整されてよい。この一時的メッセージが不活性となったとき、NOTE 項は同じ反復レートで数回送信され続けるべきである (SHOULD) が、受信側に信号を送るため長さゼロの文字列を付加する。しかし受信側がその反復レートの小さな倍数（あるいはおそらく 20–30 の RTCP 間隔）の間に NOTE 項を受信しなかった場合、それを不活性とみなすべきである (SHOULD)。
6.5.8 PRIV: 私用拡張 SDES 項 (PRIV: Private Extensions SDES Item)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRIV=8 | length | prefix length |prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | value string ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
本項は実験的またはアプリケーション固有の SDES 拡張を定義するために用いられる。項は長さ-文字列対のプレフィックス、および項の残りを満たし必要な情報を運ぶ value 文字列からなる。プレフィックス長フィールドは 8 ビット長である。プレフィックス文字列は、このアプリケーションが受信し得る他の PRIV 項に対して一意となるよう、この PRIV 項を定義する者が選んだ名前である。必要なら、アプリケーション作成者はアプリケーション名に加え、追加のサブタイプ識別子を選んでもよい。
あるいは、他者は自らが代表する実体に基づく名前を選び、その実体内でその名前の使用を調整することが推奨される (RECOMMENDED)。
プレフィックスは項の全長 255 バイトの一部を消費するため、プレフィックスはできるだけ短くすべきである。このメカニズムおよび制限された RTCP 帯域幅は過度に用いられるべきではない (SHOULD NOT)。これはすべてのアプリケーションのすべての制御通信要件を満たすことは意図されていない。
SDES PRIV プレフィックスは IANA には登録されない。ある PRIV 項の形式が広く有用であると判明した場合、プレフィックスを必要としないよう、IANA に登録された通常の SDES 項種別を用いて再定義されるべきである (SHOULD)。これは利用を単純化し伝送効率を高める。
6.6 BYE: 別れ RTCP パケット (BYE: Goodbye RTCP Packet)
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| SC | PT=BYE=203 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) | length | reason for leaving ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BYE パケットは 1 つ以上の送信元がもはや能動的でないことを示す。
version (V)、padding (P)、length： SR パケットの場合と同様（セクション 6.4.1 参照）。
packet type (PT)：8 ビット このパケットが RTCP BYE パケットであることを識別する定数 203 を含む。
source count (SC)：5 ビット この BYE パケットに含まれる SSRC/CSRC 識別子の数。カウント 0 も有効だが無意味である。
BYE パケットをいつ送信すべきかの規則はセクション 6.3.7 および 8.2 にある。
BYE パケットがミキサにより受信された場合、ミキサはそのままの SSRC/CSRC 識別子で BYE パケットを転送すべきである (SHOULD)。ミキサがシャットダウンする場合、それが処理しているすべての寄与送信元および自身の SSRC 識別子を列挙する BYE パケットを送信すべきである (SHOULD)。任意に、BYE パケットは長さを示す 8 ビットバイトカウントに続き、そのバイト数のテキストを含み、退出理由（たとえば "camera malfunction"、"RTP loop detected"）を示してよい (MAY)。文字列は SDES で記述されたものと同じ符号化を用いる。文字列が次の 32 ビット境界ちょうどに収まる場合、文字列は null 終端されない。収まらない場合、BYE パケットは次の 32 ビット境界まで null バイトでパディングされなければならない (MUST)。このパディングは RTCP ヘッダの P ビットで示されるパディングとは別である。
6.7 APP: アプリケーション定義 RTCP パケット (APP: Application-Defined RTCP Packet)
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| subtype | PT=APP=204 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name (ASCII) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application-dependent data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
APP パケットは、新機能の開発に伴い新たな RTCP パケット種別を登録する必要なく、実験のために用いられる。名前の認識されない APP パケットは無視されるべきである (SHOULD)。テストの後、より広い用途が証明された場合、各 APP パケットは subtype および name フィールドなしに、RTCP パケット種別を用いて IANA に登録し再定義されることが推奨される (RECOMMENDED)。
version (V)、padding (P)、length： SR パケットの場合と同様（セクション 6.4.1 参照）。
subtype：5 ビット サブタイプとして用いられ、一意の名前の組の下で一組の APP パケットを定義したり、任意のアプリケーション固有データに用いたりできる。
packet type (PT)：8 ビット このパケットが RTCP APP パケットであることを識別する定数 204 を含む。
name：4 バイト この組の APP パケットを定義する者が選んだ名前で、このアプリケーションが受信し得る他の APP パケットに対して一意である。アプリケーション作成者はアプリケーション名を選び、そのアプリケーションに対する新パケット種別の定義を望む者へ subtype 値を調整して割り当ててよい。あるいは、他者は自らが代表する実体に基づく名前を選び、その実体内でその名前の使用を調整することが推奨される (RECOMMENDED)。名前は 4 つの ASCII 文字からなる列として解釈され、大文字と小文字は区別される。
application-dependent data：可変長 アプリケーション固有データは APP パケットに存在してもしなくてもよい。それは RTP 自身ではなくアプリケーションにより解釈される。それは 32 ビット長の整数倍でなければならない (MUST)。