Network Working Group Audio-Video Transport Working Group Request for Comments: 1889 H. Schulzrinne Category: Standards Track GMD Fokus S. Casner Precept Software, Inc. R. Frederick Xerox Palo Alto Research Center V. Jacobson Lawrence Berkeley National Laboratory January 1996 この翻訳に関するノート URL: http://doobie.iq.nanzan-u.ac.jp/rfc-jp/rfc1889-jp.txt 日本語訳: 南山大学経営学研究科における後藤の講義の宿題として、大部分を 学生に翻訳してもらい、修正したものです。コピーライトは原典に 準じます。複数人の作業によるので文体の不一致等は御容赦下さい。 翻訳者: comm-grad@iq.nanzan-u.ac.jp 作成日: Autumn 1997 (訳注: 本翻訳は参考のため提供されているもので、英文のものが正式である。 本翻訳の正しさについて、一切保証しない。) RTP: リアルタイムアプリケーションのための転送プロトコル このメモの位置付け この文書は インターネットコミュニティのためのインターネット標準 trackプ ロトコルについて書かれており、改良のための議論や提案を求めるものである。 標準化の状況や、このプロトコルの位置付けについては、インターネット公式プ ロトコル標準 (STD 1) の現在のものを参照せよ。 このメモの配布は制限しない。 アブストラクト このメモはRTP (リアルタイム転送プロトコル) について記述したものである。 RTPは、オーディオやビデオ、シミュレーションデータといったリアルタイム性 のあるデータをマルチキャスト、あるいはユニキャストのネットワーク上で転送 するのに適したエンドツーエンドのネットワーク転送機能を提供する。 RTPはリアルタイムサービスについて、リソース予約を行なうものでもサービス の質 (QoS) を保証するものでもない。 大きなマルチキャストネットワークへ拡張が可能な方法でデータ配送の監視を許 可したり、最小の制御と識別機能を提供するための制御プロトコル (RTCP) によ り、データ転送量は増加する。 RTPとRTCPは下のトランスポート層やネットワーク層から独立するよう設計され ている。 プロトコルはRTPレベルのトランスレーターやミキサーの利用をサポートしてい る。 目次 1. イントロダクション ........................................... 3 2. RTP 使用の概要 ............................................... 5 2.1 簡単なマルチキャストオーディオ会議 ........................... 5 2.2 オーディオ・ビデオ会議 ....................................... 6 2.3 ミキサーとトランスレータ ..................................... 6 3. 定義 ......................................................... 7 4. バイトオーダー、整列、タイムフォーマット ..................... 9 5. RTP データ転送プロトコル ..................................... 10 5.1 RTP 固定ヘッダフィールド ..................................... 10 5.2 RTPセッションの多重化 ........................................ 13 5.3 RTPヘッダに対するプロファイル固有の修正 ...................... 14 5.3.1 RTPヘッダの拡張 .............................................. 14 6. RTP制御プロトコル -- RTCP .................................... 15 6.1 RTCP パケットフォーマット .................................... 17 6.2 RTCP 送信のインターバル ...................................... 19 6.2.1 session member数の維持 ....................................... 21 6.2.2 ソース記述 バンド幅の配分 .................................... 21 6.3 sender report と receiver report ............................. 22 6.3.1 SR: sender report RTCPパケット ............................... 23 6.3.2 RR: receiver report RTCPパケット ............................. 28 6.3.3 sender report と receiver report の拡張 ...................... 29 6.3.4 sender report と receiver report の分析 ...................... 29 6.4 SDES: ソース記述 RTCPパケット ............... ................ 31 6.4.1 CNAME: SDESアイテムでの正統なエンドポイント識別子 ............ 32 6.4.2 NAME: SDESアイテムとしての ユーザ名 .......................... 34 6.4.3 EMAIL: SDESアイテムとしての電子メイルアドレス ................ 34 6.4.4 PHONE: SDESアイテムとしての電話番号 .......................... 34 6.4.5 LOC: SDESアイテムとしての地理的なユーザの配置 ................ 35 6.4.6 TOOL: SDESアイテムとしてのアプリケーションあるいはツール名 ... 35 6.4.7 NOTE: SDESアイテムとしての注意/状態 .......................... 35 6.4.8 PRIV: SDESアイテムのプライベートな拡張 ....................... 36 6.5 BYE: Goodbye RTCP パケット ................................... 37 6.6 APP: アプリケーション定義 PTCP パケット ...................... 38 7. RTPトランスレータとミキサー .................................. 39 7.1 一般的な記述 ................................................. 39 7.2 トランスレータでの RTCPの処理 ................................ 41 7.3 ミキサーにおける RTCPの処理 .................................. 43 7.4 カスケードされたミキサー ..................................... 44 8. SSRC識別子の割当と使用 ....................................... 44 8.1 衝突の起こる確率 ............................................. 44 8.2 衝突の解決法とループの発見 ................................... 45 9. セキュリティ ................................................. 49 9.1 親展性 ....................................................... 49 9.2 認証 (Authentication) とメッセージの整合性 (Integrity) ....... 50 10. ネットワークおよびトランスポートプロトコル上のRTP ............ 51 11. プロトコルでの定数の概要 ..................................... 51 11.1 RTCPパケットタイプ ........................................... 52 11.2 SDESタイプ ................................................... 52 12. RTPのプロファイルとペイロードフォーマットの仕様 .............. 53 A. アルゴリズム ................................................. 56 A.1 RTPデータヘッダ正当性チェック ................................ 59 A.2 RTCPヘッダ正当性チェック ..................................... 63 A.3 予期される RTPパケット数と失われた RTPパケット数の決定 ....... 63 A.4 SDES RTCPパケットの生成 ...................................... 64 A.5 RTCP SDESパケットの構文解析 .................................. 65 A.6 ランダムな 32ビット識別子の生成 .............................. 66 A.7 RTCP送信間隔の計算 ........................................... 68 A.8 到着間隔のジッタの評価 ....................................... 71 B. セキュリティに関する考察 ..................................... 72 C. 著作者のアドレス ............................................. 72 D. 参考文献 ..................................................... 73 1. イントロダクション このメモは Real-time Transport Protocol (RTP) について記述している。 それは対話型、もしくは会話型の映像や音声などの実時間特性のあるデータ を end-to-end に転送サービスするものである。そのサービスはペイロード (運ぶもの) タイプ、順序番号つけ、タイムスタンプ (発信時刻) の付け方、 そして発送状況の monitor を使っている。典型的なアプリケーションは UDP の上で RTP を動かし、多重化やチェックサムを使っている。両方のプロト コルはトランスポートプロトコルの機能の一部として貢献している。しか し、 RTP は他の適当下位のネットワークもしくはトランスポートプロトコ ルで使われている (10 章を見よ)。 RTP は必要に応じて、マルチキャスト を用いて複数箇所に配送するようなデータ転送をサポートしている。 RTP 自身は timely delivery を保証する如何なるメカニズムも提供しない。 また他の QoS (サービス品質) の保証を提供しない。それをするかしないか はそれより下層のサービスに依存する。それは配送の保証をしないし、配送 の順番違いを防止しない。また、下位のネットワークが、信頼できるもので あるとは保証しないし、パケット配送を正しい順序ですることを仮定しな い。RTP に含まれる順序番号は receiver に sender のパケットの順序の再 構築を許す。しかし、順序番号はまたパケットの適当な場所を探し出すこと を決定するために用いられる。例えば、映像符号化においては、必ずしも順 番にパケットを符号化しなくてもよいのである。 RTP は主として多人数マルチメディア会議のニーズに答えられるように設計 されてきたが、RTP は特定のアプリケーションに限定されるものではない。 連続したデータの蓄え、対話型、または会話型分散シミュレーション、 active badge, そして アプリケーションを 制御したり、計測することも RTP を適用できる。 この文書は RTP を定義していて、以下の2つの深く関連する部分で構成され る: o real-time transport protocol (RTP), 実時間の特性を持ったデータ の転送。 o RTP control protocol (RTCP), QoSの monitor と進行中のセッショ ンにおける参加者についての情報の伝達。後者の RTCP の側面は "loosely controlled" セッションに十分である。すなわち、明確な メンバーシップの control と set-up がない。しかし、必ずしも全 てのアプリケーションの通信制御の要求の全てをサポートする訳では ない。この機能は完全または部分的に、別の session control protocol によって包含される。それはこの文書の範疇ではないので 言及しない。 RTP はアプリケーションレベルのフレーム化と Clark と Tennehouse によっ て提唱された統合された layer processing の原理に従う新しいプロトコル である。つまり、RTP は特定のアプリケーションによって要求される情報を 供給することに順応性のあることを意図している。そして、分割された層と して実現されるよりはむしろ、アプリケーションの処理によって統合される であろう。RTP は 故意的に完成していないプロトコルフレームワークであ る。この文書はすべての RTP が適切とされる全てのアプリケーションにお いて共通であるとされるそれらの機能を特定している。従来のプロトコルと は違い、プロトコルをより一般的に作ることや分析が必要な付加機能を加え ることで機能を追加することなく、RTP は 修正されるように、必要に応じ ヘッダに情報を追加をできるように、またはいずれかをするよう意図されて いる。5.3 と 6.3.3 でその例が与えられる。 それゆえ、個々のアプリケーションに関する完全な RTP の仕様を知るため には、この文書に付け加え、他に1つ以上の付随する文書も読まなければな らない (12 章を見なさい。): o ペイロードタイプコードの集合やそれらのペイロードフォーマットへ のマッピング (つまり media encoding) などを決めるプロファイル (外形、輪郭) 仕様文書。プロファイルもまたアプリケーションの特 別なクラスに対して特定である RTP への拡張または変更を定義して いる。典型的にアプリケーションは1つの プロファイルに基づいて動 く。音声と映像データに関するプロファイルは付随する RFC TBD の 中にある。 o ペイロードフォーマット仕様文書、これは音声や映像符号化のような どんな特定なペイロードが RTP で運ばれるか定義している。 いくつかの RTP の設計決定の背景にある議論と同様に、実装のための実時 間性のサービスとアルゴリズムに関する設計での決定は[2] に記述されてい る。 いくつかの RPT アプリケーションは実験的もしくは商用的の両方において 既に原案の仕様から実現されている。これらのアプリケーションはトラ フィックモニターのような診断ツールに沿って映像と音声ツールを含んでい る。これらのツールの利用者は何千人といる。しかしながら、現在のイン ターネットは実時間サービスに全ての潜在的な要求を満たしていない。映像 のような RTP を使用した高帯域ネットワークでのサービスは潜在的かつ大 幅に他のネットワークサービスの QoS を下げる。このようにして実装者は 思いがけないバンド幅の使用を制限する適当な予防策を講じなければならな い。アプリケーションの文書は明確にインターネットや他のネットワーク サービスにおいての広帯域なバンド幅を使用する実時間サービスへの限定、 操作上の影響の概要を述べねばならない。 2. RTP 使用の概要 以下の章は いくかの RTP の使用の様子を記述している。その例として RTP が何のために使われるかに限定しないで RTP を使ったアプリケーションの 基本操作を説明するものを選んだ。これらの例では、RTP は IP, UDP の上 で動くものであり、付随するInternet-Draft, draft-ietf-avt-profile の なかで仕様化された音声]と映像への profile によって制定された取り決め に従っている。 2.1 簡単なマルチキャストオーディオ会議 IETF のワーキンググループはインターネットの音声会議における IP マル チキャストサービスを用いた最近の protocol draft について討論するため に集まる。いくつかの allocation mechanism を通してワーキンググループ 議長はマルチキャストグループアドレスと2つの ポートを得る。1つのポー トは音声データのために使用され、もう片方は contorol (RTCP) パケット のために使用される . このアドレスとポート情報は参加予定者に配送され る。もしプライバシーが欲しければ、9.1 節で述べているようにデータパ ケットとコントロールパケットを暗号化する。その場合、これらの暗号化鍵 を生成し、配らなければならない。割り当てと分配メカニズムの正確な詳細 は RTP の範疇を越えているので言及しない。 各々の会議参加者によって使われる音声会議アプリケーションは、小さな塊 に (例えば) 20ミリ秒間の音声データを入れて送る。各々の音声データの塊 の前に RTP ヘッダが付く; RTP ヘッダとデータは UDP パケットの中に順番 に入れられる。RTP ヘッダはどのタイプの音声符号化 (PCM, ADPCM や LPC のような) が各々のパケット中に含まれるかを知らせるので、例えば、低帯 域の回線を有する新しい参加者の追加、または ネットワークの輻輳の兆候 への対応をするために sender は会議の最中に符号化を変えることができ る。 他のパケットネットワークと同様に、インターネットは時おり、パケットを 失ったり再要求し、いくらかの時間の遅れが生じる。これらの欠点に対処す るため、RTP ヘッダはタイミング情報と送り先によって生成される 順序番 号を持っている。 そのため、 receiver はソースにより作られたタイミン グを再構成できる。そのため、この例では、音声の塊を20ミリ秒ごとに speaker に出される。このタイミング再構築は会議の中で RTP パケットの 各々の配送元ごとに実行される。順序番号もどれだけパケットが失われたか 見積もるために receiver に使用される。 ワーキンググループのメンバーが会議中に接続したり接続を切ったりするの で、誰がどの時点で参加しているか、そしてどれくらい音声データを受け とっているかを知るのは有用である。それらのために、会議中に、音声アプ リケーションの各々の実体は定期的に reception report とRTCP (control) ポートでの利用者の名前をマルチキャストする。 reception report は現在 の speaker はどれくらい情報を受け取られているかを示し、control adaptive encoding を使っている。利用者の名前に付け加えて、他の識別情 報もまたバンド幅制限を抑制させるために含まれる。サイトは会議を抜ける 際に RTCP BYE パケット (6.5 章) を送る。 2.2 オーディオ・ビデオ会議 もし、音声と映像のメディアの両方を会議で使うなら、それらは別の RTP セッションとして送信されねばならない。RTCP パケットは2つの各々のメ ディアごとに異なった UDP ポート、またはマルチキャストアドレスを使用 して送信されねばならない。両用セッションにおいて RTP レベルでは direct cupling が存在しない。 ただし、音声と映像セッションとの両方の 参加者が、双方のセッション統合するために、RTPC パケット内と同じ distinguished (canonical) name を使用する場合を除く。この区別をする 動機の1つは会議のいくらかの参加者に1つのメディアだけを与えることであ る。5.2 章に詳細が記述してある。区別に関わらず、ソースの音声と映像の 同調再生は両方のセッションでの RTCP パケットのなかで使われるタイミン グ情報を使って達成できる。 2.3 ミキサーとトランスレータ 今まで、すべてのサイトは 同じフォーマットのメディアデータを要求して いると仮定してきた。しかし、この方法はいつも適当な訳ではない。ある地 域の参加者は低速網を通じて、過半数の利用者が高帯域ネットワークを使用 した会議に参加するというケースを考えなさい。すべての利用者に低帯域バ ンド幅を強制する代わりに、音声のエンコーディングの質を落し、mixer と 呼ばれる RTP-level relay を低域バンド幅の地域の近くに設置する。この mixer は送信者によって生成された 20ミリ秒毎の spacing を再構築するた めに、送られてきた音声パケットについて再度同期をとり、これらの再構築 された複数の音声ストリームを一つのストリームにする。そして音声符号化 を低帯域バンド幅のものに変換し、低速網を越えて低帯域バンド幅パケット ストリームを転送する。これらのパケットは単独参加者 へユニキャストさ れたり、複数参加者への異なるアドレスへマルチキャストされる。RTP ヘッ ダは誰が話しているのかを示す情報が受信者に分かるように、mixer が混合 パケットに配分されるソース方法を含んでいる。 いくらかの音声会議参加予定者は高帯域ネットワークに接続されているが、 IP マルチキャストによって直接到達可能であるわけではない。例えば、い かなる IP パケットをも通さないアプリケーションレベルファイアウォール の影に隠れることがそうである。これらのサイトにとって、mixing は必要 ではなく、その場合においては translator と呼ばれるもう1つのタイプの RTP level relay が使われる。 2つの translator のうち、1つはファイア ウォールのどちらかの側で、もう 1つは外側にインストールされる。外側の tranlator はファイアウォールの内側の translator への確実な接続を通し て受けとったマルチキャストパケットを送る。 translator は再びマルチ キャストパケットとしてサイトの内部のネットワークで制限されたマルチ キャストグループへ送る。 mixer と translator は多目的に設計される。別の映像ストリームの中で個 人の画像ファイルを調整し、1つの映像ストリームの中に group scene を simulate するためにそれを複合する映像 mixer がその例である。 translation の他の例は IP/UDP だけを話している ST-II または再同期 や mixing を行なわないで個人配送先から映像ストリームの packet-by-packet encoding translation を理解できるホストのグループの接続を含む。mixer と translator の操作は7章で詳しく取り上げる。 3. 定義 RTP payload: RTP によって送信されるパケットの中のデータ、例えば音声 サンプルや圧縮映像データがそうである。その payload format と説明 はこの文書の範疇を越えているので言及しない。 RTP packet: 固定 RTP ヘッダ、contributing source (以下を見よ) の空か もしれないリスト、そしてペイロードデータで構成されるデータパケッ ト。いくつかの下位のプロトコルは定義されるべき RTP パケットのカ プセル化を要求する。基本的なプロトコルでは1つのパケットに対して 1つの RTP パケットを含むのが典型的であるが、カプセル化の方法 (10 章を見よ) によって許されるなら、いくつかの RTP パケットが含まれ る。 RTCP packet: RTP データパケットと類似して、固定ヘッダ部分から構成さ れる制御パケット、RTCP パケットタイプ により変化する構成要素の後 につく。そのフォーマットは6章で定義する。典型的に複数の RTCP パ ケットは基本的なプロトコルの1 パケットのなかに含まれた複数の RTCP パケットとして一緒に送られる; これはそれぞれの RTCP パケットの固 定ヘッダの中の length field により可能にしている。 Port: "トランスポートプロトコルが既定のホストコンピュータの中で複数 の配送先を識別するために用いる抽象概念。TCP/IP プロトコルは小さ い正の整数を使ってポートを見分けている。" OSI トランスポート層に よって使われていた [3] transport selectors (TSEL) は ポートと同 じである。RTP は、RTP や , セッションの RTCP パケットを多重通信 する ポートのようないくつかのメカニズムを提供するために、下位層 プロトコルに依存する。 Transport address: transport-level endpoint を識別するネットワークア ドレスとポートの組合せ、例えば IP アドレス と UDP ポート などが そうである。 パケットはソースのトランスポートアドレスから配送先 のトランスポートアドレスに送信される。 RTP session: RTP を用いた通信で参加者グループが交流すること。それぞ れの参加者は、セッションは特定の配送先トランスポートアドレスのペ アで定義される (1つの ネットワークアドレスと RTP, RTCP の 各々の 1つのポート)。 IP マルチキャストの場合のように配送先のトランス ポートアドレスのペアはすべての参加者にとって共通である、もしくは 個々のユニキャストネットワークアドレスと共通なポートのペアのよう に各々にとって異なっている。マルチメディアセッションにおいて、 RTCP パケットとともにそれぞれのメディアが別の RTP セッションで伝 送される。複数の RTP セッションは、別のポートナンバーのペアおよ び異なったマルチキャストアドレス、またはいずれかによって区別され る。 Synchronization source (SSRC): RTP パケットのストリームのソース。 RTP へッダの中の 32-bit nemeric SSRC 識別子によって識別され、ネット ワークアドレスに依存しない。 synchronization source からのすべて のパケットは 同じタイミングと順序番号スペースを構成する、そのた め receiver は、再生のために synchronization source によってパ ケットを集める。synchronizaion source の例は、マイクロフォンまた はカメラ、または RTP mixer (以下を見よ) のような signal source から引き出されるようなパケットのストリームの sender を含む。 synchronization source は時間内に (over time) そのデータフォー マットを変える可能性がある。すなわち音声符号化などがそうである。 SSRC 識別子は、特定の RTP セッションの中で、グローバルにユニーク であることを意味するランダムに選ばれた値である。 (8章を見なさ い)。マルチメディアセッションにおいてすべての RTP セッションのた めに参加者は同じ SSRC 識別子を使う必要はない; SSRC 識別子のバイ ンドは RTCP を通して提供される。 (6.4.1 を見よ)。もし 参加者が 1 つの RTP セッションにおいて複数のストリームを生成したなら、例 えば別のビデオカメラの様に、別の SSRC として識別されねばならな い。 Contributing source (CSRC): RTP パケットのストリームのソース。 RTP mixer (以下を見なさい) が生成した結合されたストリームを配分する。 mixer は特定のパケットの生成のために配分されたソースの SSRC 識別 子のリストを、そのパケット のRTP ヘッダに挿入する。そのリストは CSRC リストと呼ばれる。アプリケーションの例では、音声会議の際に、 mixer が出ていくパケットを生成するために speech を結合させ、全て の talker を知らせる。すべての音声パケットが同じ SSRC 識別子 (mixerの) を含んでいても、 receiver に現在の talker を知らせる事 が出来る。 End system: RTP パケットでの送られるべき 内容 を生成し、および受信し た RTP パケットの内容を消費するまたはいずれかのアプリケーション。 1 つの end system は、特定の RTP セッション内において 1つまた複 数の synchronization suorce として振舞う。しかし、典型的には 1つ だけである。 Mixer: 1つ以上のソースから RTP パケットを受けとる仲介システム。デー タフォーマットを変えることが可能で、いくつかの方法でパケットを組 み合わせることができ、そしてその時には新しい RTP パケットを送る ことができる。複数の入力ソース間のタイミングは一般的には同調され ないので、mixer はストリームの間にタイミングを調整し、ストリーム を組み合わせるためにそれ自身のタイミングを生成する。このようにし て、mixer から生成されたすべてのデータパケットは mixer を持って いると同様に その synchronization source として識別される。 Translator: synchronization source 識別子を変化させずに RTP パケット を送る仲介システム。translator の例としては、mixing 無しに符号化 を変換するデバイスや、マルチキャストからユニキャストへの replicator , ファイアウォールにおけるアプリケーションフィルター がある。 Monitor: RTP セッション内で参加者によって送られた RTCP パケットを受 けとり、特に distribution monitoring, fault diagnosis, long-term statistics の為の reception report と現在の QoS の評価をするアプ リケーション。monitor の機能はセッション内の参加者アプリケーショ ンに組み込まれている傾向があるが、参加しないか、RTP データパケッ トの送受信をしない別のアプリケーションかも知れない。これらは third party monitor と呼ばれる。 Non-RTP means: RTP に加えて、使えるサービスを提供することが必要なプ ロトコルとメカニズム。特に、マルチメディア会議では、会議制御アプ リケーションは、マルチキャストアドレスと key を提供し、使用され る暗号化アルゴリズムを交渉し、RTP ペイロードタイプ値とペイロード タイプ値が未定義なフォーマットを表すペイロードフォーマット間の dynamic mapping を定義する。簡単なアプリケーションとして、電子メ イルまたは会議データベスが使われている。そのようなプロトコルとメ カニズムの仕様はこの文書の範疇でないので言及しない。 4. バイトオーダー、整列、タイムフォーマット 全ての整数フィールドはネットワークバイトオーダーので運ばれる。つま り、殆どの最高位バイト (オクテット) が最初である。 バイトオーダーは ビッグエンディアン (最高位オクテットから順に) として共通に知られてい る。トランスミッションオーダーは[4]に詳しく記述されている。もし特に 書かれてないなら、定数は 10進法である (base 10). すべてのヘッダデータは自然長で整列している。つまり 16-bit フィールド は偶数の offset で並べられている、32-bit のフィールドは 4 で割れる offset で並べられているなどである。padding として設計されているオク テットは 0の値を持つ。Wallclock time (絶対時間) は Network Time Protocol (NTP) のタイムスタンプフォーマットを使って表されていて、そ れは相対的に 1900 年の1月1日0時からの通算の秒数で表す。最も詳しいNTP タイムスタンプは 64-bit の unsigned fixed-point number で、初めの 32 ビット部分を整数値として小数部分を残りの32ビットとする。もっとコンパ クトな表現が適当とされるいくつかのフィールドは、中間の 32ビットが使 われる。つまり整数部分の下の 16ビットと小数部分の上の 16ビットで表 す。上の整数部分の 16 bit は独立して決められるべきである。 5. RTP データ転送プロトコル 5.1 RTP 固定ヘッダフィールド 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|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CSRC 識別子のリストは mixer によって付けられる時のみ存在するに対し、 初めの 12 オクテットは各々の RTP パケットの中に存在する。フィールド は以下の意味を持つ: version (V): 2 bits このフィールドは RTP のバージョンを識別する。この仕様で定義され ているバージョンは2である (2). (1の値は RTP の初めの draft で使 われていて、0 の値は 初期に実装された "vat" 音声ツールの中で使わ れている) padding (P): 1 bit padding bit が設定されたら、パケットはその最後に 1 つ以上の additional padding octet を含む。それはペイロードの一部分ではな い。padddig の最後の octet はいくつの padding octet が無視される かのカウント数を表す。padding は、固定ブロックサイズを持ついくつ かの暗号化アルゴリズムによって、あるいは下位層プロトコルデータユ ニット内のいくつかの RTP パケットを運ぶために必要となるかも知れ ない。 extension (X): 1 bit もし、extension bit が設定されたなら、固定ヘッダの後に正確に1つ の拡張ヘッダが続く。5.3.1 章で定義されたフォーマットを見なさい。 CSRC count (CC): 4 bits CSRC count は固定ヘッダに続く CSRC 識別子の数を表す。 marker (M): 1 bit marker の解釈は profile によって定義されている。それはパケットス トリームの中に示されているフレームの境界のような significant event を許すことを意図している。proflie は additional marker bit を定義する . さもなくば、ペイロードタイプフィールドのビット数を 変えたことによって marker bit が存在しないような仕様を決定する。 payload type (PT): 7 bits このフィールドは RTP ペイロードのフォーマットを定義して、アプリ ケーションによる解釈を決定する。profile はペイロードタイプコード のペイロードフォーマットへの default static mapping の仕様を決め る。付加ペイロードタイプコードは RTP でない方法を通して動的に定 義される (3章を見なさい。) 音声と映像のための default mapping の 初期設定は 付随 profile の Internet-Draft draft-ietf-avf-profile の中で定義され、Assigned Number RFC [6]の将来の版において拡張さ れるであろう。RTP sender は任意の時間に1つの RTP ペイロードタイ プを発する; このフィールドでは多重通信の別のメディアのストリーム は意図されていない (5.2 章を見なさい) sequence number: 16 bits 順序番号は各々の RTP データパケットの配送毎に1つずつ増え、パケッ トロスを検出し、パケットの順序を修復するために receiver によって 使われる。パケットは暗号化する translator を通して流れるので、 ソース自体が暗号化されてない場合でさえ、暗号化された known-plaintext attack をもっと難しくするために 順序番号の初期値 は (予想されない) ランダムな値である。予想されない数を選ぶ技術は [7] で討論されている。 timestamp: 32 bits タイムスタンプは、RTPデータパケットの最初のオクテットのサンプル をとった瞬間を反映する。サンプリングの瞬間は単調かつ線形に増加す る時計から得られないといけない。時計の精度は、要求された同期の正 確さとパケット到着のジッタ (揺らぎ) を測定するのに十分でなくては ならない。 (ビデオフレーム当たり1 tickでは普通不十分)。時計の周 波数はペイロードとして運ばれるデータのフォーマットに依存する。そ して、フォーマットを定義する profile またはペイロードフォーマッ ト仕様で静的に指定される。あるいは RTP でない方法によって定義さ れたペイロードフォーマットのために動的に指定される場合がある。も し RTPパケットが定期的に生成されれば、system clock を読まずに sampling clock から決められたごくわずかなサンプリングの瞬間を利 用することができる。例として固定レートの音声のタイムスタンプ時計 は、サンプリングの瞬間毎に1ずつ増加する。もし音声アプリケーショ ンが、入力デバイスから160のサンプリング周期にわたるブロックを読 めば、タイムスタンプは、そのようなブロックのために160ずつ増やさ れる。この時ブロックがパケットの中で送られているか無音部として落 されているかには関わらない。 タイムスタンプの初期値は、順序番号に関する限りランダムである。いくつ かの連続する RTP パケットは、もしそれらが (論理的に) 一度に生成され るならば等しいタイムスタンプを持つかも知れない。例えば同じ映像フレー ムに属する場合、連続する RTP パケットは、MPEG interpolated 映像フレー ムのような場合には、もしデータがサンプルされた順に送られなければ、単 調ではないタイムスタンプを含むかもしれない。 (送られたパケットの順序 番号は、まだ単調だろう。) SSRC: 32 bits SSRC フィールドは synchronization source を識別する。この識別子 は同じ RTP セッションの中の2つの synchronization sources が同じ SSRC 識別子をを持たないためにランダムに選ばれる。ランダムな識別 子を生成するためのアルゴリズムの例は、Appendix A.6 で示す。同じ 識別子を選ぶ複数のソースの確率が低いけれども、全ての RTP インプ リメンテーションは、衝突を見つけて、解決する用意ができていなけれ ばならない。8節は、衝突を解決するためのメカニズムと一意性に基づ く RTPレベルの転送ループを検出するメカニズムに沿って衝突の確率を 述べる。もし送信元がそのソーストランスポートアドレスを変更すれ ば、ループされたソースと解釈されるのを避ける新しい SSRC 識別子を 選ばなければならない。 CSRC list: 0 to 15 items, 32 bits each CSRC リストは、このパケットで含まれたペイロードのために、 contributing sources を識別する。識別子の数は、CC フィールドに よって与えられる。もし、15個以上の contributing sources があれ ば、 15個だけは識別されるだろう。CSRC 識別子は、contributing source の SSRC 識別子を利用して、mixer によって挿入される。例え ば、音声パケットで、パケットを作るために mix された全てのソース の SSRC 識別子がリストされ、receiver が適切な talker を認識でき る。 5.2 RTPセッションの多重化 効果的なプロトコル処理のために、統合されたレイヤ処理設計原理[1]で述 べられているように、多重送信ポイント (multiplexing points) の数は最 小にされるべきである。RTPでの多重化は、RTP セッションを定義する配送 先トランスポートアドレス (ネットワークアドレスとポート) によって提供 される。例えば、別々に符号化された音声や映像のメディアから構成されて いる遠隔会議で、各々のメディアはそれ自身の配送先トランスポートアドレ スで別々の RTP セッションに運ばれるべきである。音声と映像が1つの RTP セッションで配送され、ペイロードタイプあるいは SSRC フィールドに基づ いて demultiplex されることを意図しない。異なったペイロードタイプを 持つが、同じ SSRC を使用しているパケットを交互に出すことにはいくつか の問題がある。 1. もし1つのペイロードタイプがセッションの間切り替えられれば、 どの古い値が新しいものにかえられたかを識別する一般的な方法は ないだろう。 2. SSRC は、一つのタイミングとシーケンスナンバースペースを識別 するために定義される。もしメディア clock 速度が異なり、そし てパケットロスの損害を受けたペイロードタイプを知らせるために 異なった順序番号の space を要求するならば、Interleaving multiple ペイロードタイプは、異なったタイミングの space を要 求するだろう。 3. RTCP sender と receiver レポート (6.3節を参照) は、SSRC 1つ について 1つのタイミングと順序番号の space を記述するのみで、 ペイロードタイプフィールドを含むことは出来ない。 4. RTP mixer は、一つのストリームの中へ異なるメディアの interleaved ストリームを結合することができないだろう。 5. 1つのRTPセッションでの複数のメディア配送は (以下を) 不可能に する: 適切ならば、異なったネットワーク経路かネットワーク資源 の割当の使用; 必要ならば、メディアの一部分の受信、例として映 像が利用可能な帯域幅を越えた時の音声; そして別のメディアのた めに異なった処理を使用する receiver インプリメンテーション、 それに対し、異なった RTP セッションの利用は、1つまたは複数の 処理のインプリメンテーションも許可する。 各メディアごとに異なった SSRC を使用し同じRTPセッションで送る事で、 最初の3つの問題を回避するが、最後の2つの問題は回避できないだろう。 5.3 RTPヘッダに対するプロファイル固有の修正 現存するRTPデータパケットヘッダは、RTP がサポートするであろうすべて のアプリケーションクラスで、共通に要求される機能の集合に対して完全で あると思われる。しかしながら、ALF 設計原理を保持する場合に、ヘッダ は、機能を果たすための profile-independent monitoring や recording tools を許す間、プロフィール仕様に定義された修正や付加を通して、適合 させられる場合がある。 o マーカービットとペイロードタイプフィールドは、プロファイル固有 の情報を運ぶ。しかし、多くのアプリケーションがそれらを必要とす るように期待されるので、それらは固定したヘッダに割り当てられて いなければならない。そうでなければ、それらを保っておくためにも う 1つの 32-bit word を加えなければならないかもしれない。これ らのフィールドを含むオクテットは異なった要求に適するために、プ ロフィールによって例えばより多くの、またはより少ないマーカー ビットで再定義される場合がある。もしいくらかのマーカービットが あれば、一つは profile-independent monitors がパケットロスパ ターンとマーカービットの相互関係を観察することができるかもしれ ないので、オクテットの記号ビットで置かれなければならない。 o 特定のペイロードフォーマットのために要求される追加の情報は、ビ デオ符号化のようなパケットのペイロードセクションに含まれるべき である。これは、ペイロードセクションの始まりでいつも現れるヘッ ダにあるかもしれないしデータパターンの予約した値によって指し示 されるかもしれない。 o もしアプリケーションの特定のクラスが、ペイロードフォーマットか ら独立している追加の機能性を必要としていれば、それらのアプリ ケーションが働く profile は、現存する固定ヘッダの SSRC フィー ルドの後に、追加の固定したフィールドを定義するべきである。 profile-independent monitors あるいは recorders が最初の12オク テットだけを解釈することによって RTP パケットをまだ処理するこ とができる間、それらのアプリケーションは、速くそして直接に追加 のフィールドにアクセスすることができるだろう。 もし追加の機能性が全てのプロフィールに跨って必要とされることが分かれ ば、その時、RTPの新しいバージョンは固定ヘッダが変更されて定義される。 5.3.1 RTPヘッダの拡張 拡張メカニズムは、個々のインプリメンテーションがRTPデータパケットヘッ ダで運ばれる付加的情報を必要とする新しい payload-format-independent functions が実験するのを可能にするために提供される。このメカニズム は、拡張ヘッダが拡張されていない他の interoperationg implementations によって無視されるように設計される。この拡張ヘッダが制限された使用に 対してのみ意図されることに注意せよ。このメカニズムのもっとも多くの可 能性用途は、前のセクションで述べられた方法を利用して、別の方法により 適切に与えられるだろう。例えば、固定ヘッダへの profile-specific 拡張 は処理するためにより効率的である。なぜなら、それは条件付きでもなく て、位置も変わらない。特定のペイロードフォーマットのために要求された 追加の情報は、この拡張ヘッダを利用するべきではなく、パケットのペイ ロードセクションに含まれるべきである。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | defined by profile | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header extension | | .... | もしRTP ヘッダの X ビットが1ならば、variable-length ヘッダ拡張は、 CSRC リストがあればその後に付加される。拡張ヘッダは、4-オクテット拡 張ヘッダ (それゆえに、ゼロは有効な長さである) を除外して、拡張で 32-bit単位の数を数える 16-bit length フィールドを含む。1つの拡張だけ が RTP データヘッダに付加される場合がある。複数の interoperationg implementation が それぞれ異なったヘッダ拡張をもって独立して実験を行 なうために、または、特定のインプリメンテーションがヘッダ拡張の1つ以 上のタイプで実験するのを可能にするために、ヘッダ拡張の最初の16ビット は、識別子か引数を区別するために open なままである。これらの16ビット のフォーマットは、インプリメンテーションが働いているプロフィール仕様 によって、定義することができる。このRTP仕様は、どんなヘッダの拡張そ れ自身も定義しない。 6. RTP制御プロトコル -- RTCP RTP コントロールプロトコル (RTCP) は、データパケットと同じ分配メカニ ズムを利用して、セッション内のすべての参加者へのコントロールパケット の周期的な伝送に基づいている。例えば、UDP でのセパレートポートナン バーを使って、下位層プロトコルは、データとコントロールパケットの多重 通信を提供しなければならない。RTCP の4つの機能の役割は以下である: 1. 主な機能はデータ配送の品質でのフィードバックを提供すること。 これはトランスポートプロトコルとして RTP の役割の不可欠な部 分である。そして、他のトランスポートプロトコルのフロー制御と congestioin 制御機能に関係する。フィードバックは adaptive encodings[8,9] のコントロールのために直接役立つかも知れない。 しかし IPマルチキャスティングによる実験で、配分の誤りを診断 するために receivers からフィードバックを得ることは重要であ ることを示した。すべての参加者のために reception feedback reports を送る事で、問題の観察者はそれらの問題が局所的である か大局的であるかを評価できる。 IPマルチキャストのような配分 メカニズムで、セッションに含まれていないネットワークサービス プロバイダのようなentityが、ネットワークの問題を診断する third-party monitor として振舞い、フィードバック情報を受け取 ることも可能である。このフィードバック機能は、RTCP発信者と受 信者リポートによって実行される。 6.3節の後半で述べられる。 2. RTCP は、canonical name あるいは CNAME (6.4.1節) と呼ばれる RTP ソースに対する persistent transport-level 識別子を含む。 もし衝突が発見されるか、プログラムがリスタートされたら、SSRC 識別子を変更するかもしれないので、受信者は各々の参加者を追跡 するために、CNAMEを要求する。受信者は、1セットの関連がある RTP セッションの所定の参加者からの複数のデータストリームを関 連づける (例えば、音声と映像の同期をとる) ために、CNAMEを同 じく要求する。 3. 最初の2つの機能は、全ての参加者が RTCP パケットを送ることを 要求する。従って、レートは RTP が多数の参加者までスケールアッ プするため順番に、コントロールされなければならない。参加者毎 に他の人全てのコントロールパケットを送らせることによって、参 加者の数を独立して観察することができる。この数は、パケットが 送られるレートを計算するために使われる。6.2節で説明される。 4. 第4に、オプションとして最小のセッション制御情報を伝えること である。例えば、参加者の識別はユーザインタフェースで表示され る。メンバーシップコントロールや引数交渉なしで、参加者がセッ ションに入ったり出たりする "loosely controlled" は、非常に有 益である。 RTCP は、全ての参加者に届く便利なチャンネルとして サービスする。しかし、それが必ずしもアプリケーションの全ての 制御コミュニケーション要求をサポートするように期待されるとは 限らない。より高いレベルのセッション制御プロトコル (それは、 このドキュメントの範囲を越える) が必要とされる場合がある。 RTP が IP マルチキャスト環境で利用される際、機能1-3 は強制されてい る。そして、全ての環境に対し推薦される。RTP アプリケーションの設計者 には、ユニキャストモードでのみしか動作せず、大人数では動作しないメカ ニズムを避けることを推奨される。 6.1 RTCP パケットフォーマット この仕様は、様々な制御情報を運ぶために、いくつかの RTCP パケットタイ プを定義する: SR: sender report、送信中の参加者の送受信統計のためのレポート。 RR: receiver report、送信中でない参加者からの受信統計のためのレポート。 SDES: CNAMEを含むソース説明項目。 BYE: 参加の終りを示す。 APP: アプリケーションの特定の機能。 RTCP パケットは、RTP データパケットと同じ固定された部分で始まる。パ ケットタイプに従って、長さが変わるかもしれない構成された要素に従うが 常に32-bit の最後で終る。固定した部分の整列 (alignment) 要求と長さの フィールドは、RTCP パケットを "stackable"にするために含まれる。多重 RTCP パケットは、(例えば UDP のような) 下位層プロトコルの1つのパケッ トで送られる合成 RTCP パケットを形成するために、中間にあるセパレータ なしで連結される場合がある。下位層プロトコルが合成パケットの終わりを 決定するために全部の長さを提供するように期待されるので、合成パケット 内の個々の RTCP パケットの数は明確ではない。 合成パケットのそれぞれ個々の RTCP パケットはパケットの結合や順序に依 存せず、独立して処理される場合がある。しかしながら、プロトコルの機能 を実行するために、次の強制は負わせられる: o (SRかRRでの) 受信統計は、統計の分析を最大限にするくらい頻繁に バンド幅制限は送られるべきである。従って、定期的に送られた合成 RTCP パケットはレポートパケットを含むべきである。 o 新しい receiver は、ソースに対しCNAME を受け取る必要がある。出 来るだけ早くソースを識別し、lip-sync のような目的のためにメディ アを関連づけ始めるためである。そして合成パケットごとに SDES CNAME もまた含むべきである。 o 合成パケットの最初に現れるかもしれないパケットタイプの数は、制 限されるべきである。それは、最初の word の定数ビットと、間違っ たアドレスの RTP データパケットや他の関係ないパケットに対する 成功した正しい RTCP パケットの確率を増加させるためである。 このように、全ての RTCP パケットは、次の推奨されているようなフォー マット、少なくとも2つの個々の合成パケットで送られなければならない。 Encryption prefix: 合成パケットが暗号化されている時のみ、送信される すべての合成パケットについて最構成されたランダムな 32-bit数が付 加される。 SR or RR: 合成パケットの最初のRTCPパケットは、常に、Appendix A.2で 述べられる header validationを容易にするレポートパケットでなけれ ばならない。たとえデータが送られなくて、受け取られなかったとして も、空の RRが送られた場合も、合成パケットで唯一他の RTCP パケッ トが BYE だとしてもこれは真実である。 Additional RRs: もし受信統計が報告されているソースの数 (1つの SR か RR パケットにフィットする) 数が31を越えれば、追加の RR パケット よりも初めのレポートパケットに従うだろう。 SDES: CNAME 項目を含む SDES パケットは、各々の合成の RTCP パケット に含まれなければならない。他のソース記述子は、もしバンド幅制限を 受けやすい (6.2.2節を参照) )特定のアプリケーションによって要求さ れれば、任意に含まれるだろう。 BYE or APP: 他の RTCP パケットタイプ (まだ定義されていないものを含 む) は、どんな順序で送られても良いが、任意の SSRC/CSRC の BYE は 最後のパケットとして送られる。パケットタイプは2 回以上現れる。 パケットオーバーヘッドを償却 (amortize) するために実行可能である時 は、 1つの合成パケットを転送する多数のソースから個々の RTCP パケット を結合することは、translator と mixer に得策である。mixer によって生 産されるかもしれない RTCP 合成パケットの例は、図1。もし合成のパケッ トの全部の長さがネットワーク経路の最大の伝送ユニット (MTU) を越えた 場合は、下位層プロトコルの別々のパケットで送られるよう、複数のより短 い合成のパケットへ分割するかもしれない。SR か RR パケットから各々の 合成パケットが始まらなければならないことに注意せよ。 インプリメンテーションは、入ってくる 未知のタイプの RTCP パケットを 無視するかもしれない。 追加のRTCPパケットタイプは、インターネットナ ンバー割り当て当局 (IANA) で、登録されるかもしれない。 6.2 RTCP の送信のインターバル if encrypted: random 32-bit integer | |[------- packet -------][----------- packet -----------][-packet-] | | receiver reports chunk chunk V item item item item -------------------------------------------------------------------- |R[SR|# sender #site#site][SDES|# CNAME PHONE |#CNAME LOC][BYE##why] |R[ |# report # 1 # 2 ][ |# |# ][ ## ] |R[ |# # # ][ |# |# ][ ## ] |R[ |# # # ][ |# |# ][ ## ] -------------------------------------------------------------------- |<------------------ UDP packet (compound packet) --------------->| #: SSRC/CSRC Figure 1: Example of an RTCP compound packet RTP はアプリケーションが、少数から数千の参加者に応じて session size を対応できるように設計されている。例えば、音声会議ではデータトラ フィックは限られたものになる。理由はたかだか一人か二人の人間が同時に 話をするのみだからである。従ってマルチキャストをもちいることによって 与えられたリンクがいくつあっても、データの速度は参加者の人数に比較的 依存しない。しかしながらコントロールトラフィックは限られたものにはな らない。もしそれぞれの参加者から reception report が一定の速度で送ら れた場合、コントロールトラフィックは参加者の人数によって線形的にふえ るだろう。その結果速度は落とさないといけない。 各セッションで、データトラフィックは参加者に分配される "セッションバ ンド幅" と呼ばれる aggregate limit を条件としている。このバンド幅は 予約され、ネットワークによって決められる制限かもしれないし、妥当な分 け前でもよい。セッションバンド幅はそのセッションの使用可能なネット ワークのバンド幅の知識か、いくつかのコストか何かの根拠で選んで良い。 これはメディアの符号化とは幾分か独立しているが、その符号化の選択は セッションのバンド幅によって制限されるかもしれない。セッションバンド 幅パラメータはセッション制御アプリケーションによって、メディアアプリ ケーションを呼び出した時に供給されると考えられる。しかし、メディアア プリケーションがそのセッションで選択された符号化のために、sender が 単一の場合の (に必要とされる) バンド幅に基づいた初期値を設定しても良 い。そのアプリケーションも multicast scope rule かその他の基準にした がってバンド幅を制限しても良い。 コントロールとデータトラフィックのためのバンド幅の計算は、下位トラン スポート層とネットワークプロトコル (例えば UDP と IP) を含めて考え る。理由はリソース予約システムがバンド幅の計算を知っている必要がある ものだからである。アプリケーションもどちらのプロトコルが使われている か知るとことが出来ると考えられてよい。リンクレベルヘッダは、パケット がそれが伝わる相異なるリンクレベルヘッダでカプセル化されるだろうとい う理由で、その計算には含まない。 コントロールトラフィックは小さく、そして既知の割合のセッションバンド 幅の一部程度に制限すべきである。 (データを運ぶというトランスポートプ ロトコルの第1の機能を損なわない位に小さくということと、リソース予約 プロトコルのために与えられた bandwidth specification に、コントロー ルトラフィックが含められること、そしてそれぞれの参加者が独立してそれ ぞれの配分を計算できることである。) これは RTCP に割り当てられるセッ ションバンド幅の franction が、5 パーセントに固定されるように提案さ れている。一方、同じインターバルの計算においての他の一定の値と、この 場合の値は重要ではなく、セッション中のすべての参加者は同じ値を使わな ければいけないので、同じインターバルで計算されるであろう。それゆえこ れらの定数は各 profile ごとに決めておくべきである。 Appendix A.7 で述べられているアルゴリズムは以上のようなゴールにいき つくように設計された。これは参加者の間で許されたコントロールトラ フィックバンド幅をわけ与えるために、複合 RTCP パケットを送る間の間隔 を計算している。これにより、アプリケーションは小さなセッションに対し て早い応答を与えることができるが、例えば、すべての参加者の識別が重要 である時、自動的に大きなセッションが自動的に対応できる。このアルゴリ ズムは次の特徴も合わせ持っている: o sender は少なくともコントロールトラフィックの 1/4 を配分される ようになっている。セッション中で receiver の数が多く、小数の sender であった場合、新しく加わった参加者は 送っているサイトの CNAME をより早く受けとることができるようになるだろう。 o 計算された RTCP パケット間のインターバルは、参加者の人数が少な く、トラフィックが、大数の法則に従ってスムーズでない時、許され たバンド幅を越える巨大な RTCP パケットがバーストを起こさないよ うに最小値の5 秒より大きな時間が必要である。 o すべての参加者が予期しない同期をとらないように、RTCPパケット間 のインターバルは[0.5,1.5]の範囲の乱数と計算されたintervalを掛 けてランダムに変化させる。セッションに加わった後に送られた最初 の RTCP パケットは、アプリケーションが同時に複数のサイトで始 まった場合、(例えばセッションアナウンスによって始まるように)、 最小の RTCP インターバルの半分のランダムな変化によって遅らされ る。 o 平均的な組み合わされたRTCPパケットサイズの動的の見積もりが (こ れらすべての受信と配送を含む)、コントロール情報内の変化に対応 するために、計算される。 このアルゴリズムはすべての参加者が配送することを許された時にセッショ ンに利用される。この場合、セッションバンド幅パラメータは参加者の数 X (掛ける) 個々の sender のバンド幅になる。そして RTCPバンド幅はその 5パーセントになる。 6.2.1 session member 数の維持 RTCP パケットインターバルの計算はセッション中で参加しているサイトの 数の見積りに大きく依存する。新たなサイトは要求を受けた時に加えられ、 そしてそれぞれのためのエントリーを、それらを把握するために SSRC/CCRC 識別子 (参照 8.2章) を添字とするテーブル上に作る。新しいエントリーは 新しい SSRC を運ぶ 複数のパケットが受信されるまで、有効とは考えなく て良い。 (参照 Appendix A.1) エントリーは SSRC 識別子に一致する RTCP BYE パケットを受けとった時、テーブルから消去されて良い。 もし RTP/RTCP パケット共にRTCP report インターバルが少ない数しか (5 秒と考えられている) 受信されてなければ、参加者は他のサイトを inactive にマークして良い。もしくはまだ有効でなければ消去して構わない。これに よってパケットロスに対してある程度の強さを得られる。すべてのサイトが このタイムアウトが正確に働くために、RTCP report インターバルの値を大 雑把に同じにしなけばならない。 一度あるサイトが有効であると認められると、もし後で inactive にマーク されるのであれば、そのサイトのの状態は保持されたままであるべきであ り、サイトは典型的な network partition に広がるために充分長い期間の ために RTCP バンド幅をシェアするサイトの合計数に入っているべきであ る。 RTCP report インターバルは小さくなるために partition が直った時 の過度のトラフィックを避けるために30分のタイムアウトが考えられる。こ れが、 RTCP report intervalが通常 scale するために期待されている値、 約2~5 分の5倍よりも大きいことに注意せよ。 6.2.2 ソース記述バンド幅の配分 ここでは、固定の CNAME アイテムに加えて、いくつかのソース記述 (SDES) アイテム、例えば NAME (個人名) /EMAIL (email アドレス) の定義をして いる。これは新しい application-specific RTCP パケットタイプを定義す る方法を提供する。アプリケーションはこの加えられた情報へコントロール バンド幅を割り当てる際に、予防策をこうじるべきである。というのは reception report と CNAME が送られるレートを遅くするからである。した がってこのプロトコルのパフォーマンスは損なわれる。 よく付加情報を運ぶ一人の参加者に割り当てる RTCP バンド幅は 20パーセ ント以上にならないように勧める。その上、すべての SDES アイテムすべて のアプリケーションに含まれるべきであるということを目指してはいない。 含まれているそれらは、それらの utility に従ってバンド幅を割り当てら れるべきである。むしろこれらの fraction を動的に見積もるよりも、パー センテージは、一つのアイテムの典型的な長さに基づいて report インター バルのカウントに静的に変更されることを勧める。 例えば、あるアプリケーションは CNAME, NAME, EMAIL を送るのみで他は何 もしないようにデザインしてもよい。NAME はEMAIL よりも高い優先順位を 与えて良い。というのは NAME はアプリケーションのユーザインタフェース 中で連続的に出現するだろうし、それに対して EMAIL はリクエストがあっ た時のみ現れるだろうからである。RTCP インターバル毎に、RR パケットと SDES パケットは CNAME と共に配送されるだろう。最小のインターバルで制 御されるような小さなセッションでは、それは平均して毎5秒程になるだろ う。3回毎のインターバル (15秒) で、別のアイテムは SDES パケットに含 まれる。8回中7回は、これは NAME アイテムになり、8回毎 (2分) で EMAIL アイテムになるだろう。 複数のアプリケーションは、それぞれの参加者の共通の CNAME において cross-application binding を運用するとき、例えば RTP セッションの各 媒体で構成されたマルチメディア会議中で、付加 SDES 情報は一つの RTP セッションで送っても良い。その他のセッションは CNAME アイテムを運ぶ だけかもしれない。 6.3 Sender Reports と Receiver Reports RTP receiver は、receiver が sender であるかどうかに依存する二つの form のうち一つを選択する RTP report パケットを用いて、reception quality feedbackを提供する。 sender report (SR) と receiver report (RR) の form の唯一の違いは、パケットタイプコードに加えて、active sender が使うための sender report は 20 バイト sender 情報セクション を含んでいるということである。SR は最後の report か 一つ前の report が発行されてから、サイトがいくつかのデータパケットをインターバル中に 送った場合、発行される。そうでなければ RR が発行される。 SR と RR form ともに ゼロかそれ以上の reception report ブロック (こ の receiver が最後のreport を受けてから受信した RTP データパケットか らのそれぞれの同期の資源のための 1ブロック) を含んでいる。reort は CSRC リストにリストされている contributing source にたいしては発行さ れない。それぞれの reception report ブロックはそのブロック中に現れた 特定のソースから受けとったデータについて統計を与えている。reception report ブロックは SR か RR パケットに最大31 しかフィットしないので、 加えられた RR パケットは最初の SR か RR パケットの後、最後の レポー トからのインターバルの間に聞いたすべての資源のために reception report を含む必要があるとして、積み重ねられる。 次の節では2つの report のフォーマットを定義し、もしアプリケーション が付加された feedback 情報を必要とした時、profile-specific マナーに おいてどのように拡張されるか、そしてどのように report が使われるかを 定義する。translator と mixer による reception report の詳細は 7章で 与える。 6.3.1 SR: Sender report RTCP パケット 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| RC | PT=SR=200 | length | header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NTP timestamp, most significant word | sender +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | fraction lost | cumulative number of packets lost | 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : ... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sender report パケットは3つの section からなる。ひょっとしたら定義す れば 4番めの profile-specific 拡張の section を続けられるかも知れな い。最初の section , header, は 8 octets の長さである。フィールドは 次のような意味を持つ: version (V): 2 bits RTP のバージョンを見分ける。RTCP パケットでも RTP データパケット と同じとする。この specification のバージョンは two (2) で定義す る。 padding (P): 1 bit padding bit が set された場合、この RTCP パケットはいくつもの付 加されたPadding (詰め込み) octets (コントロール情報の一部ではな い) を最後に含んでいる。この最後の詰め込みの octet はどれだけ無 視されるべき詰め込み octet があるかという数である。詰め込みはい くつかの固定長ブロックサイズの暗号化アルゴリズムによって必要とさ れてもよい。混合した RTCP パケット内では、詰め込みは最後の個々の パケットでのみ必要とされるべきである、というのはその混合パケット が全部暗号化されているからである。 reception report count (RC): 5 bits このパケットに含まれるreception report ブロック数。値ゼロは有効 である。 packet type (PT): 8 bits これはRTCP SR パケットと識別するために定数200を持つ。 length: 16 bits (32 bit words - 1) のこのRTCP パケットの長さ、header と padding を含む。 (ある一つのパケットのオフセットは ゼロを有効な長さとす る、混合したRTCPパケットを探す無限ループを避ける。一方 32bit words を数えることは4の倍数に対するvalidity checkをさける。 SSRC: 32 bits この SR パケットの生成者のための synchronization source 識別子 2 番目のsection, sender 情報、は 20 octet の長さである。そしてすべて の sender report パケットに含まれている。それは、このsender空の data transmission を要約している。 NTP timestamp: 64 bits その receiver への round-trip 伝達の量をはかるために、他の receiver からの reception report で返されるタイムスタンプによる 組み合わせで使われても良いように、report が送られた時 wallclock を表す。タイムスタンプを正確にはかることはNTP タイムスタンプの決 定より大きく限られたものかもしれないと、receiver は予想しなさい。 タイムスタンプの不正確な計測は知らされないかもしれないということ をいっているのではない。時間が立つのを記録したトラックを維持する ことができるが、wallclock 時間の考えを持っていない sender はその かわりに、セッションに加わってから過ぎた時間を用いて良い。 この68年間よりも少なく仮定されているので、high bit が ゼロになっ てるかも知れない。過ぎた時間を計算するために sampling clock を使 うことが可能である。wallclock もしくは過ぎた時間 (elapsed time) の概念を持っていない sender は NTP タイムスタンプをゼロにして良 い。 RTP timestamp: 32 bits NTP タイムスタンプ (上記) と同じ時間として一致すること、しかし同 じユニット中にある場合、そして データパケット中の RTP タイムスタ ンプとして同じランダム offset であった場合。この一致は NTP タイ ムスタンプが同期される資源のためのメディア間の同期をとるために 使って良い。そして名目上RTPクロック回数を予測するために media-independent receiver によって使って良い。多くのケースでこ のタイムスタンプはどんなに近くのデータパケットでも RTP タイムス タンプとは等しくはないだろう。むしろサンプル時間に wallclock time を定期的にチェックすることで維持する RTP タイムスタンプ counter と実時間の関係を、使って 正しい NTP タイムスタンプから計算され る。 sender's packet count: 32 bits パケットの伝達が始まってから この SR パケットが作られるまで、 sender によって伝達される RTP データパケットの総数。この count は sender が自身の SSRC 識別子を変更した時にリセットされる。 sender's octet count: 32 bits パケットの伝達が始まってから この SR パケットが作られるまで、 sender によって伝達される負荷の octet の総数 (header とか padding は含まない)。この count は sender が自身の SSRC 識別子を変更した 時にリセットされる。このフィールドは平均的な負荷 データ速度を予 測するのに使うことができる。 3番目の section はゼロかそれ以上の、最後のreport からこの sender に よって hearされた他の資源の数に依存する、reception report ブロックを 含んでいる。それぞれの reception report ブロック は1つの synchronization- source からの RTP パケットの reception 上の統計値を 運ぶ。receiver は資源がその SSRC 識別子を衝突を理由に変更した時、統 計値を持ち越してはいけない。これらの統計は以下である: SSRC_n (source identifier): 32 bits この reception report ブロック 関係 での情報資源 の SSRC 識別子。 fraction lost: 8 bits 前の SR か RR パケットが送られた後から失った、資源 SSRC_n からの RTP データパケット の部分。フィールドの左の角にある binary point の fixed point numberとして表してあるもの。 (256 を 失われた fraction に掛けた後、整数部分を取り出したものと同等。) この fraction (部品) は予想されたパケットの数で割られたパケットロスの 数で定義される - 次の節で定義する . Appemdix A.3. で実装が見られ る。重複のためにもしパケットロスが負だったら、fraction lost はゼ ロになる。receiver は最後のパケットを受けとった後、失われたパケッ トがあったかどうかは知らせることは出来なく、それはもし最後の report インターバル間に送られた資源からのすべてが失われていた場 合、その資源のために recption report ブロックが発行されることは ないということに注意する。 cumulative number of packets lost: 24 bits reception の始めから失われてきた資源 SSRC_n からの RTP データパ ケットの総数。この数は予想されるパケット数と実際に受信されたパ ケット数との差で定義される。 (その受信されたパケットの数は遅れた ものや、繰り返されたものも含む。) こうして遅れて着いたパケットは 失われたとカウントされず、繰り返されればパケットロスは負になるか も知れない。パケット数は最後の順序番号に拡張されて定義されると考 えられ、次に定義するように、最初の順序番号との差と考えられる。こ れは Appendix A.3 で示される方法で計算してよい。 extended highest sequence number received: 32 bits 下位の16bitは資源 SSRC_n からの一つの RTP データパケットに含まれ る受信された上位の順序番号を含んでいる。そしてもっとも重要な 16bit は連続数のサイクルのカウントと一致するような連続数として拡 張される。そのサイクルとは Appendix A.1. のアルゴリズムによって 維持される。同じセッション中のことなる receiver はstart time が 非常に異なる場合、順序番号の異なる拡張を行なうだろう。 interarrival jitter: 32 bits RTP データパケット インターバル時間の統計的分散の見積り。 unsigned integer で表現されており、タイムスタンプ ユニットで計算 される。インターバルの J は 2 つのパケットの到着間隔の送信時と受 信時の差 (D) の平均偏差 (標準絶対値) で定義される。以下の等式で 示されるように、これは2つのパケットのための "relative transit time" の違いを等しくしているということで、relative transit time とは一つのパケットの RTP タイムスタンプと到着時間の receiver's clock との違いであり、同じユニットで計測される。 パケット i からの RTP タイムスタンプを Si とすると、また Ri を パケッ ト i からの RTP タイムスタンプユニットにおける到着時間とすると、 i と j の二つのパケットのに関して、D は次のように表現できる。 D (i,j) = (Rj-Ri) - (Sj-Si) = (Rj-Sj) - (Ri-Si) このインターバルのジッタはそれぞれのデータパケット i が 資源 SSRC_n から受けとられたとして、続けて計算される。この計算には到着 (連続であ る必要はない) から、パケットと一つ前のパケット i-1 との 違い"D"を使 う。よって次のような公式ができる。 J=J+ (|D (i-1,i) |-J) /16 いつでも受信レポートは発行され、J の現在の値は更新される。 ちらつきの計算は profile-independ monitor が 異なるインプリメンテー ションから来る report の 正確な解釈を行なうことを許すようにここで定 められる。このアルゴリズムは最適な一次のオーダの見積り方法であり、有 効な収束率[11]を維持している間、計算されるパラメータ 1/16 は Noiseの 好減少率を与えている。Appendix A.8. でインプリメンテーションの例が述 べられている。 last SR timestamp (LSR): 32 bits (Section 4 で説明される) NTP タイムスタンプにおいて 64bit のうち 中間の32bitは 資源 SSRC_n からのもっとも最近の RTCP sender report (SR) パケットの一部として受信される。もし SR がまだ一つも受けと られたなければ、このフィールドは 0 にセットされる。 delay since last SR (DLSR): 32 bits 資源 SSRC_n からの 最後の SR パケットの receive とこの reception report block を配送する間の遅れを 1/65546秒を単位として表現する。 もしまだ DDRC_n から SR パケットが1つも受信されてなかったら、 DLSR フィールドは 0 にセットされる。 SSRC_r は receiver がこの receiver reportを発行するということを示し ている。資源 SSRC_n は この reception report block が受信された時の 時間 A を記録することによって、SSRC_r への round 伝達の遅れを計算す ることができる。これは total round-trip 時間 A-LSR を 最後の SR タイ ムスタンプ (LSR) フィールドを用いて計算し、the round-trip propagationdelay を (A-LSR-DLSR) として残す (leave) ためである。これ は Fig. 2. で表される。 これはいくつかの link が非常に非同期な遅れを持つとしても、cluster receiver への距離の近似測定として使える。 6.3.2 RR: Receiver report RTCPパケット [10 Nov 1995 11:33:25.125] [10 Nov 1995 11:33:36.5] 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) (3024992016.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 0x 6:2000 ( 6.125 s) Figure 2: Example for round-trip time computation 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| RC | PT=RR=201 | length | header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | fraction lost | cumulative number of packets lost | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : ... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ receiver report (RR) パケットの形式は、パケットタイプフィールド が定数として 201 であることと sender情報の 5 つの項目、つまり NTP と RTP のタイムスタンプ、senderのパケット数と 送信者のオクテット 数が省略されていることを除いて、SRパケットの形式と同じである。残 りのフィールドは、SRパケットに対するものと同じ意味である。 レポートに対するデータの送信や受信がない時、複合 RTCPパケットの 先頭が空の RR パケット (RC = 0 の場合) となる。 6.3.3 sender reportと receiver reportの拡張 もし sender か receiver について定期的に報告されなければならない追加 情報があるなら、そのプロファイルには sender report と receiver に対 するプロファイルの仕様かアプリケーションの仕様の拡張を定義すべきであ る。別の RTCP パケットの型を定義することより優先して、この方法は使わ れるべきである。なぜなら、必要なオーバーヘッドがより少ないからである: o パケットにおけるより少ないオクテット数 (RTCP のヘッダか SSRC フィールドがない。) o より単純でより早い解析。なぜなら、そのプロファイルのもとで実行 されているアプリケーションは、receiver report の後で直接アクセ ス可能な位置にある拡張フィールドをいつも要求するようにプログラ ムされているからである。 もし追加の sender 情報が要求されたなら、それが sender report に対す る拡張の先頭に含まれるべきである。しかし、receiver report には含まれ ない。もし receiver についての情報が含まれるのであれば、そのデータは receiver report ブロックとして存在する配列と同様なブロックの配列とし て構成される; つまり、ブロックの数は RC フィールドによって示される。 6.3.4 sender report と receiver reportの分析 受信品質のフィードバックが、sender に対してだけでなく他の receiver と第三者としての monitor に対しても有益であることが望まれる。sender はそのフィードバックに基づいて送信を変更するかも知れない; receiver は、問題が局所的であるか、地域的であるか、大域的であるかを決定するこ とができる; ネットワーク管理者は、ネットワークのマルチキャスト配送に 関する性能を評価するために、RTCPパケットだけを受けとり、それに一致す る RTPデータパケットを受けとらないような、プロファイルに依存しない monitor を利用するかも知れない。 累積カウントは、sender 情報と receiver report ブロックの両方で利用さ れる。それは短い期間と長い期間の両方での測定方法とレポートの損失に対 しての回復を提供するため、2つのレポート間でその差が計算される。最後 に受けとった 2 つのレポートの間でのその差は、配送の最近の品質を評価 するために使うことができる。NTPタイムスタンプは速度が 2つのレポート の間の差から計算できるようにするために含まれる。そのタイムスタンプが データの符号化に対するクロックレートは依存しないので、符号化とプロ ファイルに依存しない品質のmonitorを実装することが可能となる。 計算の例としては、2つの reception report 間の間隔におけるパケット損 失率をあげる。損失したパケットに関する累積数の差は、その間の時間での 損失の数である。拡張された最後の順序番号の差は、その間の時間で受け取 ることが期待されるパケットの数である。これら 2つの比率は、その間の時 間でのパケット損失の割合である。この比率は、もし2つのレポートが連続 していれば、損失部分フィールドと等しいはずである。しかしそうでなけれ ば等しくない。1 秒あたりの損失率は、損失数を秒単位で表現された NTPタ イムスタンプの差で割ることによって得ることができる。受けとったパケッ トの数は、予想されるパケットの数から損失したパケットの数を引くことで 得られる。予想されるパケットの数は、損失するものの見積りの統計的な正 当性を判断するためにも使われる。例えば、5つのパケットのうちの 1つの 損失よりも、1000のうちの 200の損失の方が重要である。 sender 情報から、第三者の monitor はデータを受けなくてもある間隔での 平均ペイロードデータ速度と平均パケット速度を計算することができる。2 つの比率をとることで、平均ペイロードサイズを求めることができる。パ ケットの損失が、パケットのサイズに依存しないことが仮定されれば、特定 の receiver によって受けとられたパケットの数に平均ペイロードサイズ ( またはそれに相当するパケットサイズ) を掛けたものが、その receiver に対して有効な、みかけ上のスループットを与える。 レポート間の差を使って長期間のパケットの損失の測定を可能にする累積数 に加えて、損失部分フィールドは 1つのレポートからの短期間の測定を提供 する。reception 状態の情報がすべての receiver に対して保たれないほど 会議の規模が十分に拡大するか、たった1つのレポートが特定の receiver から受けとられるくらいレポート間の間隔が十分長くなるにつれて、これは より重要となる。 到着間隔ジッタフィールドはネットワークの輻輳に対する第2の短い期間の 測定を提供する。そのジッタの測定が一時的な輻輳を追跡する一方、パケッ トの損失は持続的な輻輳を追跡する。輻輳がパケットの損失を導く前に、 ジッタの測定が輻輳を示す。到着間隔ジッタフィールドが report の時点に おける snapshot に過ぎないので、1つの receiver からのある程度の時間 での reportや、あるいは単一のネットワーク内で複数の receiver からの 多くの report を分析する必要があるだろう。 6.4 SDES: ソース記述 RTCPパケット 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=SDES=202 | length | header +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC/CSRC_1 | chunk +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC/CSRC_2 | chunk +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ SDES パケットはヘッダとゼロ以上のチャンクから構成される 3段階構造で ある。そして、それらはそれぞれそのチャンク内で識別されたソースを記述 するアイテムから構成される。アイテムについては続く節でで記述する。 バージョン (V), パディング (P), 長さ (length): SR パケットに対するものと同じ (詳しくは 6.3.1 を見ること). パケットタイプ (PT): 8 ビット RTCP SDESパケットとしてこれを識別するため、定数 202 を含む。 ソース カウント (SC): 5 bits この SDES パケット に含まれた SSRC/CSRS のチャンクの数。この値が 0であることは正当であるが、役に立たない。 各チャンクは 0個以上のアイテムのリストが続く SSRC/CSRC の識別子から 成る。そしてそれらは、SSRC/CSRC についての情報を伝える。各チャンクは 32 ビット単位の大きさであり、各アイテムは、8ビットのタイプフィール ド、テキストの長さを示す 8ビットのオクテットカウント (このように、こ の 2オクテットのヘッダを含まない)、そしてテキスト自身から成る。テキ ストは255オクテット以下であることに注意する。しかし、これは RTCP の バンド幅の消費を制限するという必要性と矛盾しない。 テキストは ISO標準 10646[12,13] の Annex F で仕様化された UTF-2 の符 号化に従って符号化される。この符号化は、UTF-8 あるいは UTF-FSS とし ても知られている。それは "File System Safe UCS Transformation Format (FSS_UTF) ", X/Open 準備の仕様化、ドキュメントナンバー P.316 そして Unicode Technical Report #4 に記述されている。US-ASCII はこの符号化 の部分集合で、追加の符号化を必要としない。 その複数のオクテットの符号化の表現は、最上位ビット (MSB) を値 1に設 定することで示される。 いくつかのアイテムは連続している。すなわち、アイテムはそれぞれ 32 ビットの境界にするためにつめない。ある複数のオクテットの符号化はヌル オクテットを含んでいるので、テキストは最後がヌルで終っていない。各 チャンクでのアイテムのリストは 1つ以上のヌルオクテットで終る。そして それの先頭のものはリストの最後であることを示すアイテムタイプ 0として 解釈され、残りは次の 32 ビットの境界まで埋めるために必要であるように 解釈される。アイテムを持たない (4つのヌルオクテットからなる) チャン クは、正当であるが役に立たない。 エンドシステムがそれ自身のソース識別子 (固定された RTP ヘッダでの SSRC と同じもの) を含んでいる SDES パケットを 1 つ送る。ミキサは SDES 情報を受けとっている、寄与するソースそれぞれに対するチャンクを含む 1つのSDES パケットか、31より多くのそのようなソースがある場合は、上記 の形式で複数の完全な SDESパケットを送る。 (詳しくは 7 節を) 現在定義されている SDESアイテムは、次節で記述される。CNAMEアイテムだ けが必須である。ここで示されるいくつかのアイテムは、特定のプロファイ ルに対してのみ有用である。しかしそのアイテムのタイプは、共有している 利用の促進をさせ、プロファイルに依存しないアプリケーションを単純化す るために、1つの共通な空間から全て代入される。追加のアイテムは、IANA にタイプナンバーを登録することでプロファイルで定義されるかもしれな い。 6.4.1 CNAME: SDES アイテムにおける正統なエンドポイント識別子 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識別子は、衝突が発見されるかプロ グラムが再スタートする時に変更されるかもしれないので、CNAMEア イテムは SSRC識別子とソースに対する不変な識別子とのバインディ ングを提供するために必要とされる。 o SSRC 識別子のように、CNAME 識別子はあるRTP セッション内のすべ ての参加者の間で一意であるべきである。 o 関連している RTPセッションの集合内で一人の参加者によって使われ ている複数のメディアツールを越えてバインディングを提供するため に、CNAME はその参加者に対して固定されるべきである。 o 第三者の monitor を設けるため、CNAMEはソースの位置を突き止める ためのプログラムや人間のどちらかに対して適切であるべきである。 それゆえに、CNAMEは可能な限りアルゴリズム的に得られるべきで、手動で 入力されるべきではない。これらの要求を満たすため、プロファイルが別の 構文や意味論を仕様化しない限り、次の形式が使われるべきである。CNAME アイテムは "user@host" か、シングルユーザシステムのようにユーザネー ムが利用できなければ "host" という形式をとるべきである。どちらの形式 に対しても、"host" は RFC 1034[14], RFC 1035[15], RFC 1123[16] の 2.1 節にある規則にしたがって形式化されるので、リアルタイムデータが引き出 されるホストの完全で適切なドメインネームか、あるいは RTP通信で利用さ れるインタフェースのホストの数的なアドレスの標準 ASCII表現のいずれか である。例えば、IPバージョン 4におけるアドレスの標準 ASCII 表現は。 "ドットで区切られた10進数" であり、ドットで区切られた 4つ組としても 知られている。別のアドレスのタイプとしては、相互に一意である ASCII 表現を持つことが考えられる。完全なドメイン名は、人間の観察者に対して より都合が良く、加えて NAMEアイテムを送る必要がなくなるだろう。しか し、ある操作環境において確実に得ることが難しいかそれができないことも あるだろう。そのような環境で実行されているアプリケーションは、その代 わりとしてアドレスの ASCII 表現を使うべきである。 例としては、マルチユーザシステムにおける "doe@sleepy.megacorp.com" や "doe@192.0.2.89" がある。ユーザ名を使わないシステムでは、 "sleepy.megacorp.com" や "192.0.2.89" などである。 ユーザ名は "finger" や "talk" で使うような形式であるべきである。すな わち、典型的には個人名よりもむしろログイン名である。ホスト名は参加者 の電子メイルアドレスにあるものと同じである必要はない。 ユーザがアプリケーションによって1つのホストから複数のソースを生成す ることができるならば、この構文はそれぞれのソースに対して一意の識別子 を提供しないだろう。そのようなアプリケーションは、ソースを識別するた めに SSRCに頼らなければならない。そうでなければ、そのアプリケーショ ンに対するプロファイルで CNAME 識別子に対する追加の構文を指定しなけ ればならない。 各アプリケーションが独立にその CNAME を作成するなら、結果としての CNAME は、関連する RTPセッションの集合で一人の参加者が使っている複数 のメディアツール間のバインディングを提供するために必要なものとは等し くないかもしれない。メディア間でのバインディングが要求されるならば、 調整用のツール CNAME が表面上は同じ値を用いて設定する必要がある。 アプリケーション製作者は、RFC 1597[17] で提案された Net-10 の割り当 てのようなプライベートネットワークアドレスの割り当てが、大域的に一意 ではないネットワークアドレスを生成するかもしれないということに注意す べきである。 これはプライベートアドレスを持つが、公的なインターネットに対しての直 接 IP接続を持たないホストが、RTPレベルのトランスレータを通して公的な インターネットに RTPパケットを転送する場合に、一意ではない CNAMEをひ きおこしてしまう。 (RFC 1627[18] も見ること) このような場合を扱うた め、アプリケーションは一意の CNAME を設定する方法を提供するかもしれ ない。しかしプライベートアドレスが暴かれないことが必要であれば、プラ イベートアドレスからパブリックアドレスへ CNAME を変換するトランスレー タに負担がかかる。 6.4.2 NAME: SDES アイテムとしての ユーザ名 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, Megacorp" などの実名である。それはユーザによって望まれる形式で表現さ れるかもしれない。会議をするようなアプリケーションについては、この名 前の形式は参加者リストに載せるためもっとも望まれる形のものであり、そ れゆえに CNAME 以外のアイテムで最も良く送られるかもしれない。プロファ イルは、そのような優先順位を確立する。NAMEの値は、セッションの間は少 なくとも一定であることが望まれる。そのセッションにおいて、すべての参 加者の間で一意であることを当てにすべきではない。 6.4.3 EMAIL: SDES アイテムとしての電子メイルアドレス 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 822[19] にしたがった形式である。例えば、 "Johe.Doe@megacorp.com" ようなものである。EMAILの値は、会議の間は一 定であることが望まれる。 6.4.4 PHONE: SDES アイテムとしての電話番号 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 電話番号は国際的なアクセスコードをプラス記号で置き換えられた形式であ るべきである。例えば、合衆国での番号に対して、"+1 908 555 1212" のよ うにあるべきである。 6.4.5 LOC: SDESアイテムとしての地理的なユーザの位置 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"のよう な文字列で十分である。一方、active badge system に対しては、"Room 2A244, AT&T BL MH" のような文字列が適切である。詳細の程度は、実現ま たはユーザ、あるいはその両方に依存する。しかし、形式と内容はプロファ イルにあらかじめ記述されるかもしれない。LOCの値は、移動のホストに対 するものを除いて、セッションの間は一定であることが望まれる。 6.4.6 TOOL: SDESアイテムとしてのアプリケーションあるいはツール名 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ヘッダと同様である。 TOOLの値は、セッションの間一定であることが望まれる。 6.4.7 NOTE: SDESアイテムとしての注意/状態 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 次の意味は、このアイテムに対して提案された。しかし、これらや他の意味 はプロファイルによって正確に定義されるだろう。NOTEアイテムはソースの 現在の状態を記述する、"on the phone, can't talk"のような一時的なメッ セージに向けられる。またはセミナーの間、このアイテムは話のタイトルを 伝えることにも使われるかもしれない。それは例外的な情報を伝えるためだ けに使われるべきで、全ての参加者によって習慣として含まれるべきではな い。なぜなら、これは reception report と CNAMEが送られる速度を低下さ せるからである。すなわち、これはプロトコルのパフォーマンスを低下させ る。特に、ユーザの configuration ファイルのアイテムとして含まれたり、 その日の引用句 で自動的に生成されるべきではない。 NOTEアイテムが active である間表示されることは重要であるので、NAMEの ような CNAMEアイテム以外のアイテムが送られる速度は、NOTEアイテムが RTCPのバンド幅の一部分を占められるため、減少される。一時的なメッセー ジが active でなくなった時、NOTEアイテムは同じ繰り返しの速度で数回送 られ続けるべきであるが、それは receiver に知らせるために、長さはゼロ の文字列を伴って送られる。しかし、receiver が、繰り返し間隔の数倍、 つまり 20-30 の RTCP パケットの間で NOTEアイテムを 受けとられなけれ ば、NOTEアイテは送信中ではないと考えるべきである。 6.4.8 PRIV: SDESアイテムのプライベートな拡張 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の 拡張を定義するために使われる。そのアイテムは、長さと文字列から成る prefix を含んでいる。それには、アイテムの残りを満たして、望まれた情 報を運ぶ値の文字列が続く。prefix の長さのフィールドは 8ビットである。 prefix の文字列は、このアプリケーションが受けとる PRIVアイテムで一意 である PRIVアイテムを定義する人によって選ばれた名前である。アプリケー ション製作者は、必要であればアプリケーションの名前にサブタイプ識別子 を追加した名前を使うことを選ぶかもしれない。代わりに、それらの表現す る entity に基づいた名前を選ぶことを薦められていて、その entity 内で 名前の使用を調整する。 その prefix が 255オクテットのアイテム全体の長さの中でいくつかのス ペースを使用することに注意する。そのため prefix はできるだけ短くする べきである。この機能と窮屈な RTCPのバンド幅に、負担をかけるべきでは ない; 全てのアプリケーションについての、制御のための通信の要求を全て 満たすことは考えられていない。 SDES PRIV の prefix は、IANAに登録されない。PRIVアイテムのある形式が 一般的な有益性を証明するならば、prefix を必要としないために IANA で 登録されている標準の SDESアイテムの型を代わりに割り当てるべきである。 これは利用を単純化して、送信の効率を良くする。 6.5 BYE: Goodbye RTCP パケット 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | length | reason for leaving ... (opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BYEパケットは、1つ以上のソースがもはや送信中でないことを示す。 バージョン (V), パディング (P), 長さ (length): SR パケットの記述と同様 (6.3.1 章をみよ) パケットタイプ (PT): 8 ビット このパケットを RTPC BYE パケットと識別するために 定数 203 を含ん でいる。 ソースカウント (SC): 5 ビット BYE パケット内に含まれている SSRC/CSRC 識別子の数。値 0 は有効で あるが、使用されない。 ミキサーが BYE パケットを受けとったら、ミキサーはSSRC/CSRC 識別子を 変更せずに BYE パケットを転送する。もしミキサーが shutdown したら、 ミキサーは自分自身の SSRC 識別子と同様に、ミキサーが扱っているすべて の寄与するソースを記録している BYE パケットを送る。BYE パケットは、 オプションとして 8 ビット長のオクテットカウントを含む。これに"カメラ の機能不全" や "RTP のループが発見された"というような終了する理由を 示すテキストの多くのオクテットが続く。その文字列は、SDESのために記述 された文字列と同様に符号化されている。もし文字列が次の 32ビットの境 までパケットを埋めていた場合、文字列はヌル文字で終了しない。もしそう でなければ、BYE パケットはヌルオクテットで埋められる。 6.6 APP: アプリケーション定義 RTCP パケット 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 パケットは、パケットタイプの値の登録を必要とせずに、新しいアプリ ケーションや新しい特性が開発されたときに実験的に使用することを意図し ている。認識されていない名前を持つ APP パケットは無視されるべきであ る。テストされた後、広く使用されていると証明されたならば、それぞれの APP パケットがサブタイプやネームフィールドなしに再定義され、RTCP パ ケットタイプを使用する the Internet Assigned Numbers Authority に登 録されることが推奨される。 バージョン (V), パディング (P), 長さ (length): SR パケットの記述と同様 (6.3.21 章を見よ) サブタイプ: 5 ビット このサブタイプは、APPパケットの集合が唯一の名前か、すべてのアプ リケーションに依存するデータのために定義されることを許すサブタイ プとして使用されるかもしれない。 パケットタイプ (PT): 8 ビット このパケットを RTPCP APP パケットとして識別するために、定数 204 を含んでいる。 名前: 4 オクテット あるアプリケーションが受けとる他の APPパケットについて一意である ような、APPパケットの集合を定義する人により選ばれた名前。アプリ ケーション製作者は、アプリケーションの名前を使用することを選択 し、アプリケーションの為の新しいパケットタイプを定義したい人に対 して、サブタイプの値の割当を調整する。あるいは、他者が表現した entity にもとづく名前を選択することを推奨し、その entity 本体の 中で名前の使用を調整する。名前は 4つの ASCII の文字の並びとして 解釈され、大文字小文字は区別されて扱われる。 アプリケーションに依存するデータ: 可変長 アプリケーションに依存するデータは、APP パケットの中に現れるかも 知れないし、現れないかも知れない。それは RTP 自身によってではな く、アプリケーションによって解釈される。それは 32 ビットの倍数の 長さでなければならない。 7. RTP トランスレータとミキサー エンドシステムに加えて、RTP は"トランスレータ"と"ミキサー"の概念をサ ポートしており、それらは PTP レベルにおいて"中間のシステム"として考 えることができる。このサポートはプロトコルを複雑にしているけれども、 インターネットでのマルチキャストオーディオやビデオアプリケーションの 実験からこれらの機能の必要性は明らかに認められている。2,3 章で示され ているトランスレータやミキサーの使用例はファイアウォールや低バンド接 続の存在に起因し、それらのどちらとも存続しそうなものである。 7.1 一般的な記述 RTP トランスレータ/ミキサーは 2 つ以上のトランスポートレベルの "集団 (cloud) " を接続する。それぞれの集団は一般的なネットワークやトランス ポートプロトコル (例えば IP/UDP) や、マルチキャストアドレスやユニキャ ストアドレスの組、トランスポートレベルの目的先ポートによって定義され る。 (IP version 4 から IP version 6 のようなネットワークレベルのプ ロトコルの変換は、RTP に見えない集団の範囲で示されている) あるシステ ムは、多くの RTP セッションのためにトランスレータやミキサーとして従 事しているが、それぞれは論理的に独立した entity としてみなされる。 トランスレータやミキサーが導入された時にループが生じることを避けるた めに、次の規則を守らなければならない。 o ある RTP セッションに参加しているトランスレータかミキサーのど ちらかによって接続されているそれぞれの集団は、それらのパラメー タ (プロトコルやアドレス、ポート) の少なくとも 1つに関して他の すべてのものと区別しなければならないか、または、他のものとネッ トワークレベルで分離しなければならない。 o 最初の規則からの派生は、なんらかのアレンジすることで転送される ソースの集合を分割しない限り、並行に接続された複数のトランス レータやミキサーは存在してはいけない。 同様に、1 つ以上の RTP トランスレータやミキサーを通して通信すること ができるすべての RTP エンドシステムは、同じ SSRC の空間を共有し、そ れは SSRC識別子がそれらのすべてのエンドシステム内で唯一のものでなけ ればならないことを意味している。8.2 章では SSRC識別子を唯一であるよ うにし、かつ、ループを感知するような衝突解決アルゴリズムを述べてい る。 異なった目的アプリケーションのために設計されたさまざまな種類のトラン スレータやミキサーが存在する。いくつかの例として、暗号化の追加や削 除、データや下位層のプロトコルの符号化の変更、1つのマルチキャストア ドレスと 1つ以上のユニキャストアドレス間の複製がある。トランスレータ とミキサーの違いは、トランスレータが異なったソースからそれぞれデータ ストリームを通して送信されるのに対し、ミキサーは一つの新しいストリー ムを作るために、それらを1つに 結合させる: トランスレータ: はそのままの SSRC識別子を持った RTP パケットを転送す る; すべてのソースからのパケットが同じトランスレータを通して送信 され , そして、トランスレータのネットワークのソース address を運 ぶが、これは receiver が個々のソースを識別できることを可能にして いる。ある種のトランスレータはデータ変更せずに転送するが、他のも のはデータの符号化や RTP データのぺイロードの型やタイムスタンプ を変更するかもしれない。もし、複数のデータパケットが 1つに再符号 化されたり、または反対に 1つのデータパケットが複数に符号化された 場合、トランスレータは外へ出ていくパケットに新しく順序番号を割り 当ててなければならない。到着するパケットのストリームの損失は、外 へ出ていくシーケンスナンバーに相当するギャップをひきおこす。 receiver は他の方法によってペイロードタイプや送信アドレスがもと のソースでどの様に使用されたか知らない限り、トランスレータの存在 を気づくことができない。 ミキサー: は 1つ以上のソースから RTPデータパケットのストリームを受信 し、データのフォーマットを変更したり、いくつかの方法によってスト リームを結合させ、結合されたデータを転送する。複数の入力ソースの タイミングは一般的に同期には起こらないので、ミキサーはストリーム 内のタイミングを調整し、結合されたストリームの為のタイミングを生 成する。それゆえに、それは同期ソースである。したがって、ミキサー によって転送されたすべてのデータパケットはミキサーの SSRC識別子 をつけられる。結合されたパケットに対して寄与しているソースの身元 を保存する為に、ミキサーはそれらの SSRC 識別子を、パケットの固定 長の RTPヘッダの後の CSRC 識別子リストに挿入する。自分自身いくつ かのパケットのソースとして寄与しているミキサーは、明らかにそのパ ケットの CSRC リスト内に自分自身の SSRC 識別子を加えなければいけ ない。 いくつかのアプリケーションにおいて、ミキサーが CSRC のリストでソース を識別しないことを許容しているが、しかしながら、これらのソースを巻き 込むループが発見されないという危険をひきおこす。 オーディオなどのアプリケーションおいてトランスレータよりミキサーが優 れている点は、複数のソースが入力側で送信中の場合でも、出力バンド幅が 一つのソースのバンド幅に制限されている点である。これは低バンド幅のリ ンクでは重要なことである。劣っている点は、いくつかのメカニズムでミキ サーで遠隔制御の為の実装されていない限り、出力側における receiver が、ソースが送信されるか、または、ミュートされるかといったという遠隔 制御を行なえない点である。 ミキサーによる同期情報の再生成は、receiver がもとのストリームのメディ ア間の同期をとることができないことを意味する。マルチメディアミキサー はそれを行なうことができる。 [E1] [E6] | | E1:17 | E6:15 | | | E6:15 V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17) (M1)------------->----------------->-------------->[E7] ^ ^ E4:47 ^ E4:47 E2:1 | E4:47 | | M3:89 (64,45) | | | [E2] [E4] M3:89 (64,45) | | legend: [E3] --------->(M2)----------->(M3)------------| [End system] E3:64 M2:12 (64) ^ (Mixer) | E5:45 | [E5] source: SSRC (CSRCs) -------------------> Figure 3: Sample RTP network with end systems, mixers and translators SSRC と CSRC の識別子上の影響を説明するために、ミキサーとトランスレー タの集合を 図3に示す。図の中でエンドシステムは四角[E], トランスレー タは (T)、ミキサーは (M) で示されている。"M1:48 (1,17) " という表記 は、ミキサー M1 から発生し、48 という M1 の (ランダムの) SSRC の値 と、二つの CSRC 識別子 1 と 17 を持って識別され、E1 と E2 からのパ ケットの SSRC 識別子からコピーされたパケットを示している。 7.2 トランスレータでの RTCPの処理 おそらく修正されたデータパケットの転送に付け加えて、トランスレータと ミキサーは、RTCP パケットも処理しなければならない。多くの場合、それ らは、SDES の情報を集めたり、SR や RR パケットを修正する為に、エンド システムから受けとった混合されている RTCP パケットを分離する。この情 報の再送信は、パケットの到着か、トランスレータやミキサー自身の RTCP インターバルタイマーによって引き起こされる。 例えば、マルチキャストアドレスとユニキャストアドレス間でのパケットの 複製のように、データパケットを修正しないトランスレータは、同様に修正 しない RTCP パケットを単に転送する。 いくつかの方法でペイロードを変換するトランスレータは、データの特徴や 受信品質に反映するように SR や RR 情報の中で同様の変換を行なわなけれ ばならない。これらのトランスレータは単に RTCP パケットを転送してはい けない。トランスレータは LSR や DLSR フィールドに基づいた伝達の遅れ の測定の正確さを減少させるので、一般的に、トランスレータは異なった ソースから 1 つのパケットへ SR や RR パケットを集めないてはいけない。 SR sender情報: トランスレータは自分自身の sender 情報を生成しない が、 1 つの集団か受信した SR パケットを他の集団へ転送する。SSRC はそのままだが、もし変換のために必要とされるなら、sender 情報は 修正されなければならない。もし、トランスレータがデータの符号化の 方法を変更した場合、" sender バイトカウント" フィールドも変更し なければならない。また、いくつかのデータパケットを 1つの出力パ ケットに合わせた場合、" sender パケットカウント" フィールドを変 更しなければならない。タイムスタンプを頻繁に変更した場合、SR パ ケット内の"RTP タイムスタンプ" フィールドを変更しなければならな い。 SR/RR reception report ブロック: トランスレータは 1 つの集団から受 信された reception report を他の集団へ転送する。それらはデータの 反対の方向へながれることに注意する。SSRC はそのままである。もし トランスレータがいくつかのデータを 1つの出力データに合わせた場合 や、順序番号を変更した場合、パケット損失フィールドや" extended last sequence number" フィールドために反対の操作をしなければなら ない。これは複雑かも知れない。極端な場合、reception report を変 更するために意味のある方法はないかもしれず、トランスレータはどん な場合にも reception report を渡さないか、また自分自身の受信に基 づいた統合報告を送信するかも知れない。一般的な規則は、特別な変換 が意味をなすことを行なうことである。 トランスレータは自分自身の SSRC 識別子を必要としないが、受信したもの についての report を送信する目的のために SSRC 識別子を割り当てるかも しれない。reception report は普通すべての参加者へのマルチキャストな ので、それらの集団に送られたデータストリームの変換に一致するこれら が、接続されたすべての集団に送られるだろう。 SDES: トランスレータは典型的に 1 つの集合から受信した SDES 情報の変 更なしにその他の集合へ転送するが、例えば、もしバンド幅が限定され ているとき、CNAME 以外の SDES 情報をフィルターすることを決定す る。 CNAME は、SSRC識別子の衝突の発見が機能するように転送しなけ ればならない。自分自身の RRパケットを生成するトランスレータは、 自分自身に関する SDES CNAME情報を、それらの RRパケットを送信して いる同じ集団へ送信しなければならない。 BYE: トランスレータは BYE パケットを変更することなしに転送する。も し自分自身の SSRC を持つトランスレータがパケットの転送を終了しよ うとした場合、その SSRC 識別子とともに BYEパケットを生成しなけれ ばならない。 APP: トランスレータは APP パケットを変更することなしに転送する。 7.3 ミキサーにおける RTCPの処理 ミキサーは自分自身の新しいデータストリームをを生成するので、SRパケッ トや RR パケットを通じて送信はせず、その代わり、両方のための新しい情 報を生成する。 SR sender report: ミキサーは、ミキサーがまとめたソースからの sender report を送信はしない。なぜなら、ソースストリームの特徴はまとめ た際に失われるからである。同期ソースのように、ミキサーはまとめら たデータストリームの sender reportを持つ自分自身の SRパケットを 生成し、まとめられたストリームと同様に、同じ方向へ送る。 SR/RR reception report ブロック: ミキサーはそれぞれの集団のために自 分自身の reception report を生成し、同じ集団だけに送信をする。ミ キサーはそれらの reception reportを他の集団に送信をせず、また、 1 つの集団から受信した reception reportを他の複数の集合へ転送し ない。なぜなら、ソースは SSRC ではないからである。 (CSEC のみで ある) SDES: ミキサーは 1 つの集団から受け取った SDES情報を変更することな しに他方へ転送をするが、しかし、例えば、もしバンド幅が制限されて いる場合は、CNAME SDES以外の情報をフィルターにかけるかもしれな い。 SSRC 識別子の衝突の報告が機能することを許すために CNAME は 送信されなければいけない。 (ミキサーによって生成された CSRC リス ト内の識別子は、エンドシステムによって生成された SSRC識別子と衝 突するかも知れない)。ミキサーは自分自身の SDES CNAME 情報を SRパ ケットや RRパケットを送信するのと同じ集団へ送信しなければならな い。 ミキサーは SR パケットや RR パケットを転送しないので、典型的にまとめ られた RTCPパケットから SDESパケットを抜き出そうとするだろう。オーバ ヘッドを最小化するために、SDES パケットからのチャンクはミキサーから 生成している SRパケットや RRパケット上にスタックされている単一の SDES パケットへ集められる。RTCP パケットの割合はそれぞれのミキサー上で異 なる。 CSRC識別子を挿入しないミキサーも、SDES CNAME の転送を控えるかもしれ ない。この場合、2つの集団の SSRC 識別子の空間は独立している。率直に いえば、この操作の方法はループが発見することができないという危険を生 み出す。 BYE: ミキサーは BYE パケットを転送する必要がある。ミキサーがパケッ トの送信を終えようとする時には、自分自身のSSRC 識別子を持つ BYE パケットを生成しなければならない。 APP: ミキサーによる APP パケットの扱いは アプリケーションで指定され る。 7.4 カスケードされたミキサー RTP セッションは 図 3 内で示されたように ミキサーとトランスレータの 集合を伴う。図の中の M2 と M3 のように 2 つのミキサーをカスケードさ せた場合、ミキサーが受信したパケットはすでにまとめられ、複数の識別子 を持つ CSRC リストを含むかもしれない。2 つめのミキサーは、すでにまと められた入力パケットからの CSRC 識別子やまとめられていない入力パケッ トからの SSRC 識別子を使用して外へ送信されるパケットのための CSRC リ ストを構築すべきである。これは、図の中の M3:89 (64,45) と張り付けら れているミキサー M3 の出力の括弧内に示されている。カスケードされてい ないミキサーの場合と同様に、もし CSRC リストの結果が 15 以上の識別子 を持つ場合、残りを含むことはできない。 8. SSRC識別子の割当と使用 RTP ヘッダや さまざまな RTP パケットのフィールド内で運ばれている SSRC 識別子は、RTP セッション内で全体的に一意であるような任意の 32 ビット の数である。同じネットワーク上の参加者、あるいは同時に開始した参加者 が同じ数を選ばないようににするために注意深く数が選ばれなければならな いことは重要である。 識別子のために (IPv4 アドレスのような) ローカルネットワークアドレス を使用することは十分ではない。なぜなら、アドレスは一意なものではない からである。RTPトランスレータやミキサーは異なったアドレススペースを 持つ複数のネットワーク内で内部操作することができるので、2 つのスペー ス内での、アドレスの割当てのパターンは任意の割当てで起こるよりもとて も高い割合で衝突が起きる結果になる。 1つのホストで動作している複数のソースも衝突をおこす。 慎重に状態を初期化することなしに単に関数 random() を呼び出すことに よって SSRC 識別子を得ることも十分ではない。任意の識別子を生成する方 法の例は、付録 A.6 に示されている。 8.1 衝突の起こる確率 識別子はランダムに選ばれるので、二つ以上のソースが同じ数を選ぶ可能性 がある。すべてのソース同時に始まる場合、例えば、セッション管理イベン トによって自動的に引き起こされる場合、衝突は高い確率で起こる。N が ソースの数で、L が識別子の長さ (ここでは 32 ビット) とした場合、2つ のソースが独立に同じ値を選ぶ確率は、大きなNについて、1 - exp (-N**2 / 2** (L+1) ) を近似できる (参考文献[20]). N=1000 のとき、確率はだい たい 10**-4 である。 典型的な衝突の確率は、上のもっとも悪い場合よりもかなり低くなる。他の すべてのソースがもうすでに一意の識別子を持っている RTP セッション内 に 1つの新しいソースが加わる場合、衝突の起こる確率はスペースの外で使 用されている数のにしかならない。再び、N がソースの数で、L が識別子の 長さとした場合、衝突の確率は N / 2**L である。N= 1000 の場合、確率は だいたい 2*10**-7 である。 新しいソースが最初のパケット (データパケットか制御パケット) を送る前 に他の参加者からのパケットを受信する機会を得ることでに、衝突の確率は さらに削減される。もし新しいソースが他の参加者を (SSRC 識別子によっ て) 見失わなければ、最初のパケットを送信する前に新しいソースは識別子 が受信したすべてのものと衝突を起こさないことを立証できる。見失った場 合には、再び選択する。 8.2 衝突の解決法とループの発見 SSRC 識別子の衝突の確率は低いけれども、すべての RTP の実装は衝突の発 見と、それらを解決する適切なアクションを起こすために準備しなければな らない。もし、ソースが、他のソースも自分自身と同じ SSRC識別子を使っ ていることを発見した場合はいつでも、古い識別子のために RTCP BYE パ ケットを送り、他の任意の識別子を選択しなければならない。もし、他の 2つのソースが衝突を起こしていることを receiver が発見した場合、異る ソーストランスポートアドレスや CNAMEによって発見された時には、一方か らのパケットを保持し、他方からのパケットを破棄するかもしれない。2つ のソースは、この様な状態が続かないように、衝突の解決されることを期待 される。 任意の識別子がそれぞれの RTP セッションで全体的に一意であるので、識 別子はミキサーやトランスレータによって引き起こされるループを発見する ためにも使われる。以下の例のように、ループは、修正されていないか、お そらく混合されているデータや制御情報の重複を引き起こす: o トランスレータはをパケットを受け取った同じマルチキャストのグ ループへ直接、あるいはトランスレータのつながりを通ってパケット を誤って転送するかも知れない。この場合、同じパケットが異なる ネットワークソースから引き起こされて何度も現れる。 o 誤って並行に準備された 2つのトランスレータ、つまり両方の側で同 じマルチキャストグループにあるものは、パケットを 1 つのマルチ キャストグループから他方へ転送する。一方向のトランスレータは、 二つの複製を生成する。二方向のトランスレータはループを形成す る。 o ミキサは、直接または、他のミキサやトランスレータを通して、ミキ サが受信したパケットの同じトランスポートの送信先に送ることで、 ループを止めることができる。この場合、ソースは、データパケット 中のSSRC とミックスされたデータパケット中の CSRC の両方に示さ れなければならない。 ソースは、それ自身のパケットがループしているか、他のソースからのパ ケットがループしているか (第3者のループ) を発見できる。 ソース識別子にランダムな選択をすることによるループと衝突は、ソースト ランスポートアドレスはことなるが、同じSSRC 識別子をもったパケットが 届く結果となる。その ソーストランスポートアドレスは、パケットを発信 するエンドシステムや中間的なシステムのものかも知れない。したがって、 もしソースがそのソーストランスポートアドレスを変えれば、それは、ルー プしたソースとして解釈されることを防ぐために、新しいSSRC 識別子を選 ばなければならない。トランスレータやミキサの遠くで起こったループや衝 突は、もし、パケットのコピーすべてがトランスレータやミキサを通過する なら、ソーストランスポートアドレスを使うことで、検出できない、しかし 2つのRTCP SDES パケットからのデータのチャンクが ,同じSSRC 識別子を 持っていて、ことなるCNAMEを含んでいるなら、衝突は検出されるかもしれ ない。 衝突を発見し解決するために、RTP の実装は、次に挙げるようなアルゴリズ ムを含んでいなければならない。そのアルゴリズムでは、すでに確立した ソースに衝突する新しいソースやループからのパケットを無視する。そして 識別子に対して RTCP BYE を送り、新しいものを選択することで、参加者自 身のSSRC 識別子との衝突を、解決する。しかし、衝突が参加者自身のパケッ トのループによってひきおこされるなら、このアルゴリズムは、一度だけ新 しい識別子を選び、その後に、ループしたソーストランスポートアドレスか らのパケットを無視する。これは、BYE パケットの氾濫を防ぐために必要と される。 このアルゴリズムは、あるソースに対して、RTPパケットと、RTCPパケット でソースのトランスポートアドレスが、どちらも同じであるというとに依存 している。このアルゴリズムは、この制限を見たさないアプリケーションを サポートする場合は、変更が必要である。 このアルゴリズムは、ソース識別子を添字とし、(最初に) 受信したID の ソーストランスポートアドレスや、そのソースのその他の状態を含むような 表を保持しなければならない。そのデータや制御情報を処理するために、受 信したデータや制御パケット中の、個々のSSRC または CSRC の識別子は、 表を検索される。制御パケットの場合、その SSRCのそれぞれの要素 --例え ばSDES チャンク など-- は、別の検索が必要である。 (reception report ブロック中の SSRC は例外である。) もし、SSRC や CSRCが見つからなけれ ば、新しいエントリーが作られる。これらのテーブルのエントリーは、対応 するSSRC を持つ RTCP BYE パケットが届いた時や、比較的長い時間パケッ トが届かなくなった時に削除される。 (6.2.1 節をみよ) 参加者自身が出したデータパケットのループを見つけるために、衝突として 見つかった、(識別子ではなく) ソーストランスポートアドレスの分離した リストを保持することが必要である。これは、短いリストで、通常は空であ るべきであることに注意する。このリストのそれぞれの要素は、ソースアド レスに加えて衝突したパケットを受信したもっとも最近の時間を格納する。 要素は、RTCPのレポートの間隔10回分の時間に、衝突しないパケットがその ソースから届いた時、リストから削除される。 (6.2.節をみよ) 下に示すアルゴリズムでは、参加者自身のソース識別子と状態が、ソース識 別子のテーブルに含まれると仮定する。このアルゴリズムは、まず、参加者 自身のソース識別子とは分離して比較をするように再構成される。 IF SSRC または CSRC 識別子がソース識別子の表に含まれない: THEN ソーストランスポートアドレスとSSRCまたはCSRCを新しいエント リーを作る。 CONTINUE 通常の処理をする。 (識別子が表に見つかった) IF パケットのソーストランスポートアドレスが、表に登録された識別子: THEN CONTINUE 通常の処理をする。 (衝突やループが見つかった) IF ソース識別子が、参加者自身のものでない: THEN IF ソース識別子が、表中のCNAME とことなるCNAME を含むRTCP SDESチャンクからのもの: THEN (随意に) 第三者の衝突を数える ELSE (随意に) 第三者のループをを数える ABORT データパケットまたは制御要素の処理を中止。 (参加者自身のデータの衝突またはループ) IF ソーストランスポートアドレスが、衝突しているアドレスのリスト に見つかった: THEN IF ソース識別子は、CMAME アイテム を含む RTCP SDES チャンク からのものでない。OR CNAME が参加者自身のものである。 THEN (随意に) 自分自身のトラフィックのループの出現数を数え る。衝突アドレスのリストのエントリに現在の時間を書く。 ABORT データパケットや制御要素の処理の中止。 衝突として記録する。 衝突アドレスのリストに新しいエントリーを加え、現在の時間を書く。 古いSSRC 識別子に RTCP BYE パケットを送る。 新しい識別子を選ぶ。 古いSSRC に処理中のパケットからのソーストランスポートアドレスを 加えた新しいエントリを、ソーストランスポートアドレスの表に加 える。 CONTINUE 通常の処理。 このアルゴリズムでは、新たに衝突したソース・アドレスからのパケットは 無視され、元のソースからのパケットが保持される。 (もし、元のソースが ミキサを通過したもので、後から同じソースが直接受信されたら、receiver は、ミックスされた他のソースがなくならない限り、スイッチするように忠 告する。) もし、拡張された期間を越えても、元のソースからパケットが届 かなければ、表のエントリーはタイムアウトになり、新しいソースが代りに 使用されるだろう。これは、もし元のソースが衝突を見つけ、新しいソース 識別子に変更した場合に起こる。しかし、通常タイムアウトを待たずに状態 を消すことができるように、元のソースから RTCP BYE パケットが受信され るだろう。 衝突のために新しい SSRC 識別子が選ばれた場合、識別子の候補がすでに他 のソースで使用されていないかどうかを調べるためにソース識別子の表をま ず、検索するべきだ。もしそうであれば、他の候補が生成され、繰り返し処 理されるべきである。 マルチキャストの送信先を持つデータパケットのループにより、深刻なネッ トワークの洪水を起こすことがある。すべてのミキサとトランスレータは、 ループを止めるような、ここで挙げたループを検出するアルゴリズムを実装 しなければならない。これは、元のトラフィックの 複製が高々1となるよう に過度のトラフィックを制限するべきである。そのことによりセッション は、ループの原因を発見し修正することができるようにセッションを続ける ことができる。しかし、極端な場合、ミキサーやトランスレータが、適切に ループを止めることができず、多大なトラフィックのレベルを出した場合、 エンドシステムが、完全にデータや、制御パケットの送信をやめなければな らないかもしれない。この決定は、アプリケーションに依存している。エ ラーの条件は、適切に示されなければならない。送信は、長いランダムな時 間の後 (分の単位で) 周期的にもう一度試される。 9. セキュリティ 下位層のプロトコルは、RTP のアプリケーションが要求する、認証、整合 性、親展性を含むすべてのセキュリティサービスを満たしているかも知れな い。これらのサービスは、最近IP の仕様になってきた。親展性のサービス の要求が、RTPを使うような最初のビデオやオーディオのアプリケーション でうまく満たされているで、下位の階層でのサービスが使用できるまでの RTPと RTCPでの親展性のサービスを次の章で定義する。このサービスに対す るプロトコルのオーバヘッドは少ない。よって、将来、下位の層のサービス によりこのサービスが不必要になっても、これによる不利益はとても少な い。 一方、他のサービスでは、もし保証されるのであれば、他のサービスの実装 とアルゴリズムが、将来RTPのために定義されるであろう。ここでの選択は、 相互操作性で安全なアプリケーションの実装の単純化し、実装者に対して指 針を提供することを意味する。ここで示した方法が、この種のセキュリティ の要求に適切であるとは断言できない。プロファイルは、どのサービスとア ルゴリズムがアプリケーションに提供されるか指定し、その適切な使用方針 を提供してくれるかもしれない。 鍵の配布および証明書に関してはこのドキュメントの範囲外である。 9.1 親展性 親展性とは、受けとったパケットを、意図した receiver のみが復号化でき るということをいう。つまり、他人とってはそのパケットには有益な情報が ないということである。内容の親展性は、暗号技術により確立する。 RTP またはRTCP の暗号化が要求されたら、下位層の1パケットとして送られ るオクテットすべてが、1つの暗号の単位としてカプセル化される。RTCP の 場合、よく知られている平文攻撃を妨げるために、暗号化される前に、32 ビットの乱数が、つけられる。また、RTP の場合は、順序番号とタイムスタ ンプのフィールドが、ランダムなオフセット値により初期化されるので、プ レフィックスは必要ない。 RTCP の場合、複合RTCPパケットは、下位層の2つパケットに分割することが 許される。一つは、暗号化されるもので、もう一つは暗号化されなで送られ るものである。例えば、SDES の情報は暗号化しても良いが、受信レポート は、暗号鍵を知らない第三の監視者のためには、平文で送らなければならな い。この例を、図4で示す。SDES の情報は、RR パケットの後に、報告なし として (暗号化されて) 付け加えられなければならない。これは、すべての 複合 RTCP パケットがSR または RR パケットで始まるという要求を満たし ている。 UDP packet UDP packet ------------------------------------- ------------------------- [32-bit ][ ][ # ] [ # sender # receiver] [random ][ RR ][SDES # CNAME, ...] [ SR # report # report ] [integer][(empty)][ # ] [ # # ] ------------------------------------- ------------------------- encrypted not encrypted #: SSRC Figure 4: Encrypted and non-encrypted RTCP packets 暗号化の方法と正しく鍵は使用したかは、ヘッダやペイロードの正当性 チェックにより、receiver によって調べられる。RTPと RTCPでの、そのよ うな正当性チェックの例を、付録A.1 と A.2 で示す。 デフォルトの暗号化アルゴリズムは データ・エンクリプション・スタンダー ド (DES) アルゴリズムの サイファ・ブロック・チェイン (CBC) モードで ある。それに関しては、RFC 1423[21] の1.1章で記述されている。ただし、 8の倍数のオクテットに対するパディングを記述した、5.1 章の Pビットの 記述部分を除く。乱数値は RTPヘッダまたは、複合RTCP パケットのプレ フィックスとして供給されるので、初期化ベクタは0 である。CBC の初期化 ベクタに関する詳細は [22] を参照せよ。暗号化をサポートする実装には、 相互操作性の向上のために、デフォルトとして、必ず CBC モードのDES ア ルゴリズムをサポートするべきである。インターネット上でのオーディオ・ ビデオツールの実験により、簡単で実用的であると輪証されたので、この方 法を選んだ。これ以外の暗号アルゴリズムに関しては、RTP ではない方法 で、セッションに対して、動的に仕様が決定されるであろう。 先に記述したようなRTP レベルの暗号化とは別に、プロファイルは、暗号化 により符号化された追加的なペイロードの種類を定義するかもしれない。こ れらの符号化では、パディングの方法と、暗号化処理の他の観点をあつかわ なければならない。この方法では、アプリケーションに要求されたら、ヘッ ダを平文のままにし、データのみを暗号化できる。暗号の復号化・符号化さ れたデータのの復号化を行なうハードウェア装置に特に有用である。 9.2 認証 (Authentication) とメッセージの整合性 (Integrity) 認証とメッセージの整合性は現在のRTP の仕様では定義されていない。なぜ なら、これらのサービスは鍵管理のインフラなしでは、直接解くことができ ないからである。認証と整合性のサービスは、将来、下位層のプロトコルで 提供されることを期待されている。 10. ネットワークおよびトランスポート・プロトコル上のRTP この節では、特定のネットワークおよびトランスポート・プロトコルによる RTPパケットの配送の仕様の問題について記述する。次に挙げるルールは、 この仕様以外のところで、プロトコル仕様定義により仕様決定されなけれ ば、適用される。 RTP は、RTPデータとRTCP制御ストリームの多重化 (demultiplex) を提供す ることを、下位層のプロトコルに任せている。UDP や、それと同様なプロト コルの場合、RTP は偶数ポート番号を使用する。それに対しRTCP ストリー ムは、次にくる奇数ポート番号を使用する。もしアプリケーションが RTPの ポートとして、奇数を使うようになっていたら、一つ前の番号を代りに使用 する。 RTP のデータパケットは、長さを表すフィールドや境界を表すもの (delinea- tion) を持たない。すなわち、RTPは、長さを指すものを下位層 のプロトコルに任せている。RTP パケットの最大の長さは、下位層のプロト コルによりのみ制限される。 もし、RTP パケットが、メッセージ (パケット) でなく、連続したオクテッ トストリームを概念とする下位の層のプロトコルにより配送されるのであれ ば、 RTPパケットのカプセル化は、フレーミング・メカニズムを提供するよ うに定義されなければならない。もし、下位層のプロトコルがパディングで きるかもしれないならば、RTP のペイロードは長さを決定できないので、そ の時もまた、フレーミングは必要である。フレーミングのメカニズムはここ では定義しない。 UDP パケットなどの、下位の層のプロトコルのデータの一単位で、複数の RTP パケットを配送を可能ためのフレーミングを提供するようなプロトコル により、RTP が配送される時でさえ、プロファイルはフレーミングの方法を 指定しているかもしれない。複数のRTP パケットを、一つのネットワークお よび、トランスポートプロトコル のパケットで配送することにより、ヘッ ダのオーバヘッドを減少することができ、ことなるストリーム間での同期を 簡単にすることができる。 11. プロトコルでの定数の概要 この節では、この仕様で定義された定数のリストの概要を述べる。 RTP のぺイロード・タイプ (PT) を表す定数は、このドキュメントでなくプ ロファイルの中で定義される。しかし、付録A.1 で記述した、ヘッダ・バリ デェイション処理のために、RTCP のSR とRR パケットの種類と、RTP パケッ トを区別するために、マーカ・ビットとペイロード・タイプを含むRTPヘッ ダのオクテットは、200 と201 (10進数) の予約された番号を避けなければ ならない。この仕様で示された、一つのマーカ・ビットと、7ビットのペイ ロード・タイプ・フィールドの標準的な定義では、この制限とは、ペイロー ド・タイプ 72と73は予約されているということを示す。 11.1 RTCPパケットタイプ 略記 名前 値 SR sender report 200 RR receiver report 201 SDES ソース記述 202 BYE goodby 203 APP アプリケーション定義 204 これらの種類を表す値には、RTP パケットや、その他の関連のないパケット と、RTCP パケットを比較して行なうヘッダの正当性チェック検査を向上す るために、200 から204 の値が選ばれている。RTCPのパケット・タイプの フィールドが、適応するRTP パケットのオクテットと比較された場合、この 範囲は 1の値を持つマーカ・ビット (通常はデータパケットにはない) に相 当し、そして , 1の値をもつ標準的のペイロード・タイプのハイビットに相 当する。 (なぜなら、静的なペイロード・タイプは、典型的に下位半分の ビットで定義されている。) すべてのビットが0 やすべてのビットが1 とい うのは、よくあるデータのパターンなので、この範囲は、0から255 でいく つかの間隔を空けて選ばれている。 すべての複合RTP パケットが、SR または RR で始まらなければならないの で、RTCP のバァリディティ検査で、ビット列でのもっとも大きい数でマス クし、値を調べられるように、これらのコードには、偶数/奇数のペアが選 ばれていた。 その他の定数については、IANA によって割り当てられる。実験者は、実験 に必要な番号を登録して、必要ないと証明された番号の登録を削除する。 11.2 SDESタイプ 略記 名前 値 END SDES リストの終り 0 CNAME キャノニカル・ネーム 1 NAME ユーザ・ネーム 2 EMAIL ユーザの電子メールアドレス 3 PHONE ユーザの電話番号 4 LOC ユーザの地理的な場所 5 TOOL アプリケーションツールの名前 6 NOTE ソースに対する注意 7 PRIV 個人的な拡張 8 その他の定数については、INNA によって割り当てられる。実験者は、実験 に必要な番号を登録して、必要ないと証明された番号の登録を削除する。 12. RTPのプロファイルとペイロードフォーマットの仕様 特定のアプリケーションのためのRTPの完全な仕様には、ここで記述する2種 類の手引きが、一つ以上のが必要である。それは、プロファイルとペイロー ド・フォーマットの仕様である。 RTPは、要求とはいくらかことなるいろいろなアプリケーションで使用され るであろう。これらの要求を取り入れる柔軟性は、主なプロトコルの仕様 で、複数の選択を許し、適切な選択または、特定の環境やアプリケーション と分離したプロファイルのドキュメントを定義することで満たされる。典型 的に、アプリケーションは、一つのプロファイルのもとで動作するので、明 白には、どのプロファイルが使われているか示すことができない。ビデオと オーディオのアプリケーションのためのプロファイルは、インターネットド ラフト draft-ietf-avt-profile の手引で見つかる。 もう一つの手引きは、H.261 で符号化されたビデオなど、特定のペイロード タイプがどのように RTPで配送されるかを定義したペイロードフォーマット の仕様である。これらのドキュメントは典型的に、"XYZ オーディオ/ビデオ 符合化のための RTPペイロードタイプ" というタイトルになる。ペイロード のフォーマットは、複数のプロファイルにもとで便利であろう。よって、ど んなプロファイルにも依存しない定義がされるであろう。プロファイルのド キュメントは、もし必要であれば、ペイロード・タイプの値に対するフォー マットのデフォルトのマップを割り当てる責任がある。 この仕様では、次のアイテムがプロファイルで使用できる定義として、識別 されている。しかし、このリストは完璧なものではない: RTP データヘッダ: マーカ・ビットとペイロードタイプ・フィールドを含む RTP のデータヘッダ中のオクテットは、例えば、マーカ・ビットが少し 大きくなったり少なくなったりするような、ことなる要求に適応するよ うに、プロファイルの中で新たに定義される。 (5.3章) ペイロード・タイプ: ペイロード・タイプが含まれると仮定すると、プロ ファイルは、つねに、ペイロード・フォーマット (すなわち、メディア の符号化) の集合と、ペイロード・タイプの値に対する、これらの フォーマットのデフォルトの静的マップを定義する。ペイロードフォー マットのいくつかは、分離したペイロードのフォーマットの仕様を言及 することで、定義されている。定義されてたそれぞれのペイロードタイ プでは、プロファイルは、使用されるRTPのタイムスタンプ・クロック レイトを指定しなければならない。 (5.1 章) RTP データ・ヘッダへの追加部分: もし、何らかの付加的な機能がプロファ イルで指定されたペイロードタイプとは独立なアプリケーションのクラ スを越えて (ことなるクラスで共通に) 必要なら、追加的なフィールド は、修正されたRTP データ・ヘッダに付加される。 (5.3章) RTP データヘッダ拡張: もし、このメカニズムの使用が、実装現仕様の拡張 のためのプロファイルのもとで許されるのであれば、RTPデータヘッダ 拡張用の構造体の最初の16 ビットの内容は定義されなければならない。 (5.3.1 章) RTCP パケットタイプ: 新しいアプリケーション・クラスで指定した RTCPパ ケットタイプは、定義され、IANA に登録されていなければならない。 RTCP レポート間隔: プロファイルは、RTCP のレポートの間隔の計算に費や される時間を表す定数に、6.2 章で提案した値が使われるかどうか決定 するべきだ。これらは、セッション帯域で RTCPが占める断片的大域で あり、最小限のレポートの間隔であり、sender とreceiver 間の分割さ れたバンド幅である。もし、これらが拡張された方法で動作しているこ ととわかったら、プロファイルは、他の値を決定する。 SR/RR 拡張: もし、sender と receiver に関して、規則正しく報告される べき追加的な情報がある場合、RTCP のSR とRR パケットに関して、拡 張部分は定義されるかもしれない。 SDES 使用: プロファイルは、RTCP SDES のアイテムが、送信または完全に 除外される相対的な優先度を (6.2.2 章) や、CNAME アイテムの文法や 意味 (6.4.1章) や、LOCアイテムのフォーマット (6.4.5 章) や、NOTE アイテムの意味と使用 (6.4.7章) や IANA に登録された新しい SDESア イテムの種類を指定するかもしれない。 セキュリティ: プロファイルは、アプリケーションがどのセキュリティ・ サービスとアルゴリズムを提供しているかを指定するかもしれない。そ して、適切な使用に対する案内を提供する。 文字列とキーのマッピング: プロファイルは、どのように、ユーザーが与え られたパスワードまたはパスフレーズが暗号鍵にマップされているか指 定するかも知れない。 下位層のプロトコル: RTPパケットの配送に使用する下位層のネットワーク またはトランスポート層のプロトコルをを要求する。 トランスポート・マッピング: RTP とRTCP のトランスポートアドレス、例 えば UDP のポートなどマッピングや、10 章で定義されたマッピング以 外のマッピングが指定されているかも知れない。 カプセル化: RTPパケットのカプセル化は、複数の RTPのデータパケットを 一つの下位層のパケットとして配送したり、そのようなことができない 下位層のプロトコルのためにフレーミングを提供できるように定義され る。 (10 章) 新しいプロファイルが、すべてのアプリケーションで必要となることを期待 していない。1つのアプリケーションクラスでは、アプリケーション間の相 互操作を容易にするためには、既存のプロファイルを拡張する方が、新しい プロファイルを作るより良い。なぜなら、それぞれのアプリケーションは、 ただ1つのプロファイルのもとで、典型的に動作をする。ペイロードタイプ の値のやRTCP パケットのタイプの定義への追加のような、単純な拡張は、 インターネット・アサイン・ナンバー・オーソリティ に番号を登録し、プ ロファイルを記述に追加したものや、そのペイロードフォーマットの仕様を 記述したものを公表することで成し遂げられる。 A. アルゴリズム RTP sender と receiver に アルゴリズムの外観に対してのCコードの例を 提供する。特定の操作環境においてより速いもしくは、他の利点を持つよう な別の実装方法があるかもしれない。これらの実装に関するメモは、案内が 目的であり、またRTPの仕様を明解にするためのものである。 以下の定義はすべての例に使用される; 明解さと簡潔さのために、構造定義 は 32ビットビッグエンディアン (最高位オクテットが最初) アーキテクチャ のみ有効である。ビットフィールドは、追加パディングなしでビックエン ディアンビット順できっちりと詰められることを仮定する。移植性のある実 装を構成するために修正が要求されるであろう。 /* * rtp.h -- RTP ヘッダファイル (RFC XXXX) */ #include /* * 以下の型定義は、32ビットアーキテクチャに対して有効であり、16 * もしくは 64ビットアーキテクチャに対しては調整する必要があるか * もしれない。 */ typedef unsigned char u_int8; typedef unsigned short u_int16; typedef unsigned int u_int32; typedef short int16; /* * 現在のプロトコルのバージョン */ #define RTP_VERSION 2 #define RTP_SEQ_MOD (1<<16) #define RTP_MAX_SDES 255 /* SDES の最大テキスト長 */ typedef enum { RTCP_SR = 200, RTCP_RR = 201, RTCP_SDES = 202, RTCP_BYE = 203, RTCP_APP = 204 } rtcp_type_t; typedef enum { RTCP_SDES_END = 0, RTCP_SDES_CNAME = 1, RTCP_SDES_NAME = 2, RTCP_SDES_EMAIL = 3, RTCP_SDES_PHONE = 4, RTCP_SDES_LOC = 5, RTCP_SDES_TOOL = 6, RTCP_SDES_NOTE = 7, RTCP_SDES_PRIV = 8 } rtcp_sdes_type_t; /* * RTP データヘッダ */ typedef struct { unsigned int version:2; /* プロトコルバージョン */ unsigned int p:1; /* パディングフラグ */ unsigned int x:1; /* ヘッダ拡張フラグ */ unsigned int cc:4; /* CSRC カウント */ unsigned int m:1; /* マーカービット */ unsigned int pt:7; /* ペイロードタイプ */ u_int16 seq; /* シーケンスナンバー */ u_int32 ts; /* タイムスタンプ */ u_int32 ssrc; /* 同期ソース */ u_int32 csrc[1]; /* オプションの CSRC リスト */ } rtp_hdr_t; /* * RTCP 共通ヘッダワード */ typedef struct { unsigned int version:2; /* プロトコルバージョン */ unsigned int p:1; /* パディングフラグ */ unsigned int count:5; /* パケットタイプによる varies */ unsigned int pt:8; /* RTCP パケットタイプ */ u_int16 length; /* pkt len in words, w/o this word */ } rtcp_common_t; /* * バージョンに関するビッグエンディアンマスク、 * パディングビットとパケットタイプの組 */ #define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe) #define RTCP_VALID_VALUE ( (RTP_VERSION << 14) | RTCP_SR) /* * 受信レポートブロック */ typedef struct { u_int32 ssrc; /* 報告されているデータソース */ unsigned int fraction:8; /* 最後のSR/RR以来の fraction lost*/ int lost:24; /* cumul. no. pkts lost (signed!) */ u_int32 last_seq; /* 受けとった拡張ラストシーケンスナンバー */ u_int32 jitter; /* 到着間隔ジッタ */ u_int32 lsr; /* このソースからの最後のSRパケット */ u_int32 dlsr; /* 最後のSRパケット以降の遅れ */ } rtcp_rr_t; /* * SDES アイテム */ typedef struct { u_int8 type; /* アイテム (rtcp_sdes_type_t) タイプ */ u_int8 length; /* アイテムの長さ (オクテット) */ char data[1]; /* ヌル文字で終了しないテキスト */ } rtcp_sdes_item_t; /* * 1つの RTCP パケット */ typedef struct { rtcp_common_t common; /* 共通ヘッダ */ union { /* sender report (SR) */ struct { u_int32 ssrc; /* このレポートを生成する送信者 */ u_int32 ntp_sec; /* NTP タイムスタンプ */ u_int32 ntp_frac; u_int32 rtp_ts; /* RTP タイムスタンプ */ u_int32 psent; /* 送られたパケット数 */ u_int32 osent; /* 送られたオクテット数 */ rtcp_rr_t rr[1]; /* 可変長リスト */ } sr; /* reception report (RR) */ struct { u_int32 ssrc; /* このレポートを生成する受信者 */ rtcp_rr_t rr[1]; /* 可変長リスト */ } rr; /* ソースの記述 (SDES) */ struct rtcp_sdes { u_int32 src; /* はじめの SSRC/CSRC */ rtcp_sdes_item_t item[1]; /* SDESアイテムのリスト */ } sdes; /* BYE */ struct { u_int32 src[1]; /* ソースのリスト */ /* 理由を示す後続のテキストは表現できない */ } bye; } r; } rtcp_t; typedef struct rtcp_sdes rtcp_sdes_t; /* * ソースごとの状態情報 */ typedef struct { u_int16 max_seq; /* highest seq. number seen */ u_int32 cycles; /* shifted count of seq. number cycles */ u_int32 base_seq; /* base seq number */ u_int32 bad_seq; /* last 'bad' seq number + 1 */ u_int32 probation; /* sequ. packets till source is valid */ u_int32 received; /* packets received */ u_int32 expected_prior; /* packet expected at last interval */ u_int32 received_prior; /* packet received at last interval */ u_int32 transit; /* relative trans time for prev pkt */ u_int32 jitter; /* estimated jitter */ /* ... */ } source; A.1 RTPデータヘッダ正当性チェック RTP receiver は、入ってきたパケットの RTPヘッダの正当性をチェックす べきである。なぜなら、暗号化されているかもしれず、また誤った配送が起 こった異なったアプリケーションからのものであるかも知れないからであ る。同様に、もし暗号化が可能であるならば、ヘッダの正当性チェックは、 入ってきたパケットが正確に復号化されたかを確かめるために必要とされ る。だが、ヘッダの正当性チェックでの失敗 (例: unknown payload type) が、必ずしも復号化の失敗を示さない。 弱い正当性チェックのみが、以前に聞いたことのないソースからのRTPデー タパケット上で可能である。 o RTP バージョンフィールドは 2 に等しくなければならない o ペイロードタイプは既知でなくてはならない。特にそれは SR もしく は RRに等しくてはいけない。 o もし Pビットがセットされているならば、パケットの最後のオクテッ トは、総パケット長からヘッダサイズを引いた長さより小さい正当な オクテットカウントを含まなければならない。 o もしプロファイルがヘッダ拡張機構が使用されているであろうことを 指定していないのであれば、Xビットはゼロでなくてはならない。そ うでなければ、拡張した長さのフィールドは、総パケットサイズから 固定ヘッダ長とパディングを引いた長さより少なくなければならな い。 o (もしペイロードタイプが、既知の長さを持つならば) パケットの長 さは CC とペイロードタイプで矛盾があってはならない。 最後の3つのチェックは、幾分か複雑であり、常に可能ではなく、合計が数 ビットだけになる最初の二つだけが残る。もしパケット内の SSRC識別子が、 すでに受けとったものであるならば、パケットはおそらく正当でありシーケ ンスナンバーが予想された範囲にあるかどうかを調べることで、さらに正当 性をしらべることができる。もし SSRC 識別子が以前に見られないのであれ ば、その識別子を含んでいるデータパケットは、連続したシーケンスナン バーとともに同じ識別子がいくつか到着するまで不正なものと考えられるだ ろう。 下で示す update_seq ルーチンは、MIN_SEQUENTIAL パケットが連続で受け 付けられたあとにだけソースが正当と宣言されることを保証する。それはま た新しく受けつけたパケットのシーケンスナンバー seq が正当であること を証明し、ポインタ s が指す構造体内のパケットのソースへのシーケンス 状態を更新する。 新しいソースを最初に聞いた時、つまり、その SSRC識別子がテーブル内に ない時 (8.2章参照)、ソース毎の状態がそれに割り付けられる。 s->probation はソースの正当性を宣言する前に要求される連続的なパケッ トの数にセットされ (パラメータ MIN_SEQUENTIAL)、そして s->max_seq は s->probation がまだ正当でないことをソースに示す seq-1 に初期化される べきである。だから、6.2.1章で議論されたように、その状態は長いタイム アウトよりむしろ短いタイムアウトのあとで廃棄されるかも知れない。 ソースが正当であるとみなされた後に、もし s->max_seq の前に MAX_DROPOUT 以上でなく、その後に MAX_MISORDER 以上でなければ、シーケ ンスナンバーは、正当であるとみなされる。もし新しいシーケンスナンバー が max_seq modulo の前に max_seq より小さい RTPシーケンスナンバーの 範囲にあるならば、それはひとまわりしており、シーケンスナンバーサイク ルのカウントを増加させる。値 1 は、正当なシーケンスナンバーを指し示 すために返される。 そうでなければ、値 0 は正当でないことを示すために返され、そして誤っ たシーケンスナンバーがためこまれている。もし次に受け付けられたパケッ トが次に高いシーケンスナンバーを持っているならば、おそらく広範囲のド ロップアウトかソースの再始動に起因する新しいパケットのシーケンスの正 当な始まりとみなされる。複数の完全なシーケンスナンバーサイクルは間違 えられたかも知れないので、パケット損失の統計表はリセットされる。 パラメータの典型的な値は、50 パケット/秒での最大 2 秒間の乱れる時間 と最大 1分間のドロップアウトにもとづいて示される。再始動した後の新し いシーケンスナンバーが、再始動の前からのシーケンスナンバーの受け入れ 可能な範囲で失わないであろうという合理的な見込みを与えるために、ド ロップアウトのパラメータ MAX_DROPOUTは、16ビットシーケンスナンバー空 間の小さな断片であるべきである。 void init_seq (source *s, u_int16 seq) { s->base_seq = seq - 1; s->max_seq = seq; s->bad_seq = RTP_SEQ_MOD + 1; s->cycles = 0; s->received = 0; s->received_prior = 0; s->expected_prior = 0; /* other initialization */ } int update_seq (source *s, u_int16 seq) { u_int16 udelta = seq - s->max_seq; const int MAX_DROPOUT = 3000; const int MAX_MISORDER = 100; const int MIN_SEQUENTIAL = 2; /* * ソースは、連続したシーケンスナンバーをともなう MIN_SEQUENTIAL * パケットが受け付けられるまで正当ではない。 */ if (s->probation) { /* packet is in sequence */ if (seq == s->max_seq + 1) { s->probation--; s->max_seq = seq; if (s->probation == 0) { init_seq (s, seq); s->received++; return 1; } } else { s->probation = MIN_SEQUENTIAL - 1; s->max_seq = seq; } return 0; } else if (udelta < MAX_DROPOUT) { /* in order, with permissible gap */ if (seq < s->max_seq) { /* * Sequence number wrapped - count another 64K cycle. */ s->cycles += RTP_SEQ_MOD; } s->max_seq = seq; } else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) { /* the sequence number made a very large jump */ if (seq == s->bad_seq) { /* * Two sequential packets -- assume that the other side * restarted without telling us so just re-sync * (i.e., pretend this was the first packet). */ init_seq (s, seq); } else { s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1); return 0; } } else { /* duplicate or reordered packet */ } s->received++; return 1; } 2 つより多くのパケットが連続であることを要求することにより強く正当性 のチェックを行なわせることができる。その欠点は、より多数の最初のパ ケットが廃棄されるであろうことと、高いパケット損失の割合が正当性の証 明を妨げるかもしれないことである。しかしながら、RTCP ヘッダの正当性 の証明は、比較的強いので、もし RTCPパケットがデータパケットの前にソー スから受け付けられるならば、2つのパケットが連続でくることだけが要求 されるようにカウントを調節することができる。もし数秒間の最初のデータ ロスを耐えることができるならば、アプリケーションは、正当な RTCPパケッ トがソースから受け付けられるまでソースからすべてのデータパケットを廃 棄することを選択することができる。 アプリケーションと符号化の方法に依存することで、アルゴリズムはもっと 進んだ正当化のためのペイロードフォーマットについての付加的な知識を活 用するかも知れない。タイムスタンプの増加がすべてのパケットに対して同 じであるペイロードタイプのために、タイムスタンプ値は、シーケンスナン バーの違いを使用している同じソースから受け付けられた前のパケットから 予想することができる .(ペイロードタイプに変化はないと仮定する) 強い "fast-path" チェックが可能である。なぜなら高い見込みで新しく受 けつけられた RTP データパケットのヘッダ内の最初の 4 オクテットが、 シーケンスナンバーが一つ増えているであろうことを除いて同じSSRCからの 前のパケットのそれとちょうど同じと思われるからである。 同様にして、同時に一つのソースからしか普通データを受け付けないプリ ケーションでのより速い SSRCの参照のために単一のエントリキャッシュが 使われるかもしれない。 A.2 RTCPヘッダ正当性チェック 以下のチェックが RTCP パケットに適用することができる。 o RTP バージョンフィールドは 2 に等しくなければならない。 o 複合パケットでの最初の RTCP パケットのペイロードタイプフィール ドは SR もしくは RR に等しくなければならない。 o パディングビット (P) は、複合パケットの最初のパケットに対して 0 であるべきである。なぜならば最後のそれだけがパディングを必要 とするべきだからである。 o 個々の RTCP パケットの長さフィールドは受け付けられた 複合RTCP パケットの全体の長さの合計であるべきである。これはかなり強い チェックである。 以下のコードの断片はこれらのチェックのすべてを行なうd. パケットタイ プは、後のパケットに対してチェックされない。なぜなら知らないパケット タイプが提供されるかも知れず、それは無視されるべきだからである。 u_int32 len; /* length of compound RTCP packet in words */ rtcp_t *r; /* RTCP header */ rtcp_t *end; /* end of compound RTCP packet */ if ( (* (u_int16 *) r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) { /* something wrong with packet format */ } end = (rtcp_t *) ( (u_int32 *) r + len); do r = (rtcp_t *) ( (u_int32 *) r + r->common.length + 1); while (r < end && r->common.version == 2) ; if (r != end) { /* something wrong with packet format */ } A.3 予期される RTPパケット数と失われた RTPパケット数の決定 パケット損失率の計算のために、それぞれのソースから実際に受け付けられ たのと予想されたパケットの数が知られることが必要であり、以下のコード 内のポインタ s を介して参照される構造体のソースで定義されるソース毎 の状態の情報が使われている。受け付けられたパケットの数は単純にそれら が到着したパケットのカウントであり、いくつかの遅延と重複パケットを含 んでいる。予想されるパケットの数は、受け付けたもっとも高いシーケンス ナンバー (s->max_seq) と受け付けた最初のシーケンスナンバー (s->base_seq) との違いとして receiver によって計算されることができ る。シーケンスナンバーは 16ビットだけであり、ひとまわりしているであ ろうことから、シーケンスナンバーラップラウンドの (シフトされた) カウ ントを伴うもっとも高いシーケンスナンバー (s->cycles) に拡張すること が必要である。受け付けられたパケットカウントとサイクルのカウントの両 方は、 Appendix A.1 での RTP ヘッダ正当性チェックルーチンで維持され る。 extended_max = s->cycles + s->max_seqn; expected = extended_max - s->base_seq + 1; 失われたパケット数は実際に予想されたパケットの数から受け付けられたパ ケットの数を引いたものであると定義される: lost = expected - s->received; このナンバーは 24 ビットで運ばれるので、ゼロでまわりを包むよりむしろ 0xffffff でつめるべきである。 (以前に SR もしくは RR パケットが送られたので) 最後の報告の合間に失 われたパケットの割合は、その合間での予想されたパケットの総数と受け付 けたパケットの総数との違いから計算される。expected_prior と received_priorが、以前に受け付けた報告が生成された時保存された値であ る。 expected_interval = expected - s->expected_prior; s->expected_prior = expected; received_interval = s->received - s->received_prior; s->received_prior = s->received; lost_interval = expected_interval - received_interval; if (expected_interval == 0 || lost_interval <= 0) fraction = 0; else fraction = (lost_interval << 8) / expected_interval; 結果としての割合は 左端に小数点を伴う 8 ビット固定点ナンバーである。 A.4 SDES RTCPパケットの生成 この関数は、argc,配列で与えられた項目 (type, value, length, b) から なりバッファ b のなかに一つの SDES チャンクを生成する。 char *rtp_write_sdes (char *b, u_int32 src, int argc, rtcp_sdes_type_t type[], char *value[], int length[]) { rtcp_sdes_t *s = (rtcp_sdes_t *) b; rtcp_sdes_item_t *rsp; int i; int len; int pad; /* SSRC header */ s->src = src; rsp = &s->item[0]; /* SDES items */ for (i = 0; i < argc; i++) { rsp->type = type[i]; len = length[i]; if (len > RTP_MAX_SDES) { /* invalid length, may want to take other action */ len = RTP_MAX_SDES; } rsp->length = len; memcpy (rsp->data, value[i], len); rsp = (rtcp_sdes_item_t *) &rsp->data[len]; } /* terminate with end marker and pad to next 4-octet boundary */ len = ( (char *) rsp) - b; pad = 4 - (len & 0x3); b = (char *) rsp; while (pad--) *b++ = RTCP_SDES_END; return b; } A.5 RTCP SDESパケットの構文解析 この関数は、SDESパケットを構文解析する。SSRC 識別子を与えられたセッ ションメンバに対する情報へのポインタを見つけるための find_member() 関数とそのメンバに対する新しい SDES 情報を貯めるための member_sdes() 関数を呼び出す。この関数は、RTCPパケットのヘッダへのポインタを期待す る。 void rtp_read_sdes (rtcp_t *r) { int count = r->common.count; rtcp_sdes_t *sd = &r->r.sdes; rtcp_sdes_item_t *rsp, *rspn; rtcp_sdes_item_t *end = (rtcp_sdes_item_t *) ( (u_int32 *) r + r->common.length + 1); source *s; while (--count >= 0) { rsp = &sd->item[0]; if (rsp >= end) break; s = find_member (sd->src); for (; rsp->type; rsp = rspn) { rspn = (rtcp_sdes_item_t *) ( (char*) rsp+rsp->length+2); if (rspn >= end) { rsp = rspn; break; } member_sdes (s, rsp->type, rsp->data, rsp->length); } sd = (rtcp_sdes_t *) ( (u_int32 *) sd + ( ((char *) rsp - (char *) sd) >> 2) +1); } if (count >= 0) { /* invalid packet format */ } } A.6 ランダムな 32ビット識別子の生成 以下のサブルーチンは、RFC 1321[23] で公布された MD5 ルーチンを使用す るランダムな 32 bit 識別子を生成する。システムルーチンは、すべての OSで提供されないかもしれないが、それらはどのような種類の情報が使用さ れるかと同じようなヒントを供給すべきである。適切であるかもしれない他 のシステムコールは以下を含む。 o getdomainname () , o getwd () , あるいは o getrusage () ライブビデオやオーディオサンプルもまたランダムナンバーの良いソースで あるが、ソースとして目隠しされたカメラやスイッチを切ったマイクロフォ ンを使用することを避けることに注意しなければならない。 これや似たようなルーチンの使用が、RTCP期間に生産されるランダムナン バー発生器への最初の元を生成するため (Appendix A.7 に見られるよう な)、シーケンスナンバーとタイムスタンプへの最初の値を生成するため、 そして SSRC の値を生成するために提案される。このルーチンは CPU集中の ようであるので、RTCP 期間を生成するための直接使用は適切ではない。な ぜならば予想通りに発布されないからである。このルーチンは、違う値が型 引数に与えられない限り、システムクロックの値が変化するまで呼び出しを 繰り返すことと同じ結果を提供することに注意せよ。 /* * Generate a random 32-bit quantity. */ #include /* u_long */ #include /* gettimeofday () */ #include /* get..() */ #include /* printf () */ #include /* clock () */ #include /* uname () */ #include "global.h" /* from RFC 1321 */ #include "md5.h" /* from RFC 1321 */ #define MD_CTX MD5_CTX #define MDInit MD5Init #define MDUpdate MD5Update #define MDFinal MD5Final static u_long md_32 (char *string, int length) { MD_CTX context; union { char c[16]; u_long x[4]; } digest; u_long r; int i; MDInit (&context); MDUpdate (&context, string, length); MDFinal ( (unsigned char *) &digest, &context); r = 0; for (i = 0; i < 3; i++) { r ^= digest.x[i]; } return r; } /* md_32 */ /* * Return random unsigned 32-bit quantity. Use 'type' argument if you * need to generate several different values in close succession. */ u_int32 random32 (int type) { struct { int type; struct timeval tv; clock_t cpu; pid_t pid; u_long hid; uid_t uid; gid_t gid; struct utsname name; } s; gettimeofday (&s.tv, 0); uname (&s.name); s.type = type; s.cpu = clock (); s.pid = getpid (); s.hid = gethostid (); s.uid = getuid (); s.gid = getgid (); return md_32 ((char *) &s, sizeof (s) ); } /* random32 */ A.7 RTCP送信間隔の計算 以下の関数は、秒で計った RTCPパケットの転送間の時間を返す。それは次 が送られるまでの遅延を計算するために一つの複合 RTCPパケットが送られ た後に呼ばれるべきである。またこの関数は、パケットを送ってすぐよりも むしろ起動した上での最初の RTCPパケットが送られる前に遅延を計算する ために呼ばれるべある。例えばセッションの告示の結果として、もしアプリ ケーションが同時に多くのサイトで起動されたならば、これが RTCPパケッ トのバーストを少しでも避ける。 パラメータは以下の意味を持つ: rtcp_bw: ターゲットになる RTCP バンド幅、つまり、このセッションのす べてのメンバーによって RTCP パケットのために使われるであろうバン ド幅の合計 (オクテット/秒)。これは、起動時にアプリケーションに供 給される "セッションバンド幅" パラメータの 5 であるべきである。 senders: この RTCPパケットに receiver report の構成から知られる、最 後の報告が送られて以降活動している sender の数。もし自分達もまた この間隔の間に送るならば、自分達自身を含む。 members: セッションメンバーの見積りの数。自分達自身を含む。RTP もし くは RTCPパケットの受取りから新しいセッションメンバを発見するに つれて増加し、セッションメンバーが離脱する (RTCP BYE を介して) か、状態がタイムアウト (30秒が推奨される) になるにつれて減少して いく。最初に呼ばれた時に、このパラメータは値 1 を持つべきである。 we_sent: もし最後の二つの RTCP の合い間にデータを送ったならば真とな るフラグ。もしフラグが真ならば、複合 RTCPパケットは、SR パケット を含んで送られる。 packet_size: 送られた複合 RTCPパケットのサイズ (オクテット)。 ネットワークのカプセル化の分を含む。 (つまり IP 上の UDP の 28 オクテット) avg_rtcp_size: 複合 RTCPパケットサイズに対する予測した値へのポインタ。 この関数によって送られたパケットへの初期化と更新がされ、またセッ ション内の他の参加者から受け付けられたすべての RTCP パケットに対 する RTCP 受け付けルーチン内のコードの識別ラインによって更新され る。 initial: 最初の報告が送られるまで時間を計るために起動時の最初の呼び だしに対して真であるフラグ。 #include double rtcp_interval (int members, int senders, double rtcp_bw, int we_sent, int packet_size, int *avg_rtcp_size, int initial) { /* * このサイトからの RTCP パケット間の最小時間 (秒)。 * この時間は、セッションが小さくまた大数の法則がトラフィックを * 円滑にする助けにならない時 'clumping (群生) ' から報告を妨げる。 * それはまたネットワークの区分のような瞬間的な断絶の間にばかげ * た小ささになることから報告の間隔をまもる。 */ double const RTCP_MIN_TIME = 5.; /* * 送信中の送信者の間で共有されるRTCP バンド幅の割合。 (この割合 * は送信中の一つか二つの送信者を伴う典型的なセッションでさえあ * れば選択され、受信者の報告を不必要にスローダウンをしないので * 計算された報告時間が最小の報告時間におおよそ等しくなるであろ * う。) 受信者の割合は 1 - 送信者の割合 にならなければならない。 */ double const RTCP_SENDER_BW_FRACTION = 0.25; double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION); /* * 平均的な RTCP パケットのサイズで評価するロウパスフィルタのゲ * イン。 (Cadzowリファレンスを見よ ) */ double const RTCP_SIZE_GAIN = (1./16.); double t; /* interval */ double rtcp_min_time = RTCP_MIN_TIME; int n; /* no. of members for computation */ /* * アプリケーション起動時の最初の呼びだしは、他のソースについて * 学ぶためとランダム化への報告の前とのまだ許されるいくらかの時 * 間の間に、より速い通告のために最小遅延の半分を使用する。だか * ら報告の間隔は正確な間隔により速く収束するであろう。平均的な * RTCP サイズは 控え目である 128 オクテットで初期化される。 (そ * れはそのほかに RR の代わりに SR を生成しているすべてを仮定す * る。20 IP + 8 UDP + 52 SR +48 SDES CNAME) */ if (initial) { rtcp_min_time /= 2; *avg_rtcp_size = 128; } /* * もし送信中の送信者がいたならば、すくなくとも最小の RTCP バン * ド幅の共有を与える。そうでなければすべての参加者は、RTCPバン * ド幅を等しく共有する。 */ n = members; if (senders > 0 && senders < members * RTCP_SENDER_BW_FRACTION) { if (we_sent) { rtcp_bw *= RTCP_SENDER_BW_FRACTION; n = senders; } else { rtcp_bw *= RTCP_RCVR_BW_FRACTION; n -= senders; } } /* * 送った報告パケットのサイズによって平均のサイズの評価を更新する。 */ *avg_rtcp_size += (packet_size - *avg_rtcp_size) *RTCP_SIZE_GAIN; /* * 有効なサイトの数×平均のパケットサイズが、それぞれのサイトが * 報告を送った時おくられたオクテットの総数である。 * 有効なバンド幅によってこれを割ることは、最小限の強制で、目的 * のバンド幅を満たすために送られなければならないそれらのパケッ * トに対して時間の間隔を与える。その時間の間隔で我々は一つの報 * 告をおくる。だからこの時間は報告間の平均時間でもある。 */ t = (*avg_rtcp_size) * n / rtcp_bw; if (t < rtcp_min_time) t = rtcp_min_time; /* * 他のサイトとの意図しない同期からのトラフィックバーストを避け * るために我々はその時、0.5*tと1.5*tの間の一様に分散されたラン * ダムなナンバーとして実際の次の報告間隔を選びとる。 */ return t * (drand48 () + 0.5); } A.8 到着間隔のジッタの評価 以下のコードの断片は、受けとった報告の到着間隔のジッタフィールドに挿 入されるための RTP データ到着間隔の時間の統計的な分散の評価を計算す るために 6.3.1章で与えられたアルゴリズムを実現している。その入力は、 入ってきたパケットからとおなじ単位での到着および現在時刻のタイムスタ ンプ r->ts である。ここで s はソースに対する状態へのポインタである。 s->transit は以前のパケットに対する相対的な輸送時間を保持しており、 s->jitter は評価されたジッタを保持している。受け付けた報告のジッタ フィールドは、タイムスタンプ単位で計測され unsigned integer で表現さ れるが、ジッタの評価は浮動小数点で保持される。それぞれのデータパケッ トが到着するにつれて、ジッタの評価は更新される。 int transit = arrival - r->ts; int d = transit - s->transit; s->transit = transit; if (d < 0) d = -d; s->jitter += (1./16.) * ( (double) d - s->jitter); 受信レポートブロック (rr ポインタへの) がこのメンバで生成された時、 現在のジッタの評価が返される。 rr->jitter = (u_int32) s->jitter; 代案として、ジッタの評価は integer で保持することができるが、 round-off エラーが減少するために縮尺される。その計算は最後の行を除い て同じである: s->jitter += d - ( (s->jitter + 8) >> 4); この場合では、評価は受け付けられた報告に対して見本にされる: rr->jitter = s->jitter >> 4; B. セキュリティに関する考察 RTP は、基礎となるプロトコルと同じセキュリティの責任をこうむる。例と して、詐欺師がソースや目的地のネットワークアドレスを偽造したり、ヘッ ダやペイロードを変更することができる。RTCPのなかでは、CNAME と NAME の情報が他の参加者に扮するのに使用されるかもしれない。加えて、RTP は、データを送ったすべてのreceiver を知るために送信者に直接的な手段 を提供しない。それゆえにプライバシをはからない IP マルチキャストを介 して送られるかもしれない。正しいかどうか、使用者は、彼らがネットワー ク通信のより伝統的な形式よりオーディオとビデオ通信に関係するプライバ シにより敏感であるかもしれない[24]. それゆえに、RTPを伴うセキュリティ 機構の使用は重要である。それらの機構は、9章で議論される。 RTPレベルのトランスレータやミキサは、ファイアウォールの裏側のホスト に到達するための RTPトラフィックを許すために使用されるかもしれない。 適切なファイアウォールセキュリティの原理と実施は、(このドキュメント の範囲を越えているが) ファイアウォールの裏側で使用するための RTP ア プリケーションの容認とそれらのデバイスの設計とインストールで面倒を見 るべきである。 C. 著作者のアドレス Henning Schulzrinne GMD Fokus Hardenbergplatz 2 D-10623 Berlin Germany EMail: schulzrinne@fokus.gmd.de Stephen L. Casner Precept Software, Inc. 21580 Stevens Creek Boulevard, Suite 207 Cupertino, CA 95014 United States EMail: casner@precept.com Ron Frederick Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 United States EMail: frederic@parc.xerox.com Van Jacobson MS 46a-1121 Lawrence Berkeley National Laboratory Berkeley, CA 94720 United States EMail: van@ee.lbl.gov 謝辞 このメモは、Stephen Casner氏が議長をつとめる IETF Audio/Video Transport ワーキンググループ内での議論に基づく。現在のプロトコルはそ の起源を、ネットワークボイスプロトコルやパケットビデオプロトコル (Danny Cohen氏と Randy Cole氏), vatアプリケーションで (Van Jacobson 氏 と Steve McCanne氏により) 実装されたプロトコルに持つ。ランダムな識別子 の生成については Christian Huitema氏にアイデアを提供していただいた。 D. 参考文献 [1] D. D. Clark and D. L. Tennenhouse, "Architectural considerations for a new generation of protocols," in SIGCOMM Symposium on Communications Architectures and Protocols , (Philadelphia, Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Computer Communications Review, Vol. 20 (4), Sept. 1990. [2] H. Schulzrinne, "Issues in designing a transport protocol for audio and video conferences and other multiparticipant real-time applications", Work in Progress. [3] D. E. Comer, Internetworking with TCP/IP , vol. 1. Englewood Cliffs, New Jersey: Prentice Hall, 1991. [4] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981. [5] Mills, D., "Network Time Protocol Version 3", RFC 1305, UDEL, March 1992. [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, DEC, Cybercash, MIT, December 1994. [8] J.-C. Bolot, T. Turletti, and I. Wakeman, "Scalable feedback control for multicast video distribution in the internet," in SIGCOMM Symposium on Communications Architectures and Protocols , (London, England), pp. 58--67, ACM, Aug. 1994. [9] I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS control of multimedia applications based on RTP," Computer Communications , Jan. 1996. [10] S. Floyd and V. Jacobson, "The synchronization of periodic routing messages," in SIGCOMM Symposium on Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp. 33--44, ACM, Sept. 1993. also in [25]. [11] J. A. Cadzow, Foundations of digital signal processing and data analysis New York, New York: Macmillan, 1987. [12] International Standards Organization, "ISO/IEC DIS 10646-1:1993 information technology -- universal multiple-octet coded character set (UCS) -- part I: Architecture and basic multilingual plane," 1993. [13] The Unicode Consortium, The Unicode Standard New York, New York: Addison-Wesley, 1991. [14] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [15] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. [16] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, Internet Engineering Task Force, October 1989. [17] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", RFC 1597, T.J. Watson Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994. [18] Lear, E., Fair, E., Crocker, D., and T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified) ", RFC 1627, Silicon Graphics, Inc., Apple Computer, Inc., Silicon Graphics, Inc., July 1994. [19] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [20] W. Feller, An Introduction to Probability Theory and its Applications, Volume 1 , vol. 1. New York, New York: John Wiley and Sons, third ed., 1968. [21] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS, IAB IRTF PSRG, IETF PEM WG, February 1993. [22] V. L. Voydock and S. T. Kent, "Security mechanisms in high-level network protocols," ACM Computing Surveys , vol. 15, pp. 135-- 171, June 1983. [23] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992. [24] S. Stubblebine, "Security services for multimedia conferencing," in 16th National Computer Security Conference , (Baltimore, Maryland), pp. 391--395, Sept. 1993. [25] S. Floyd and V. Jacobson, "The synchronization of periodic routing messages," IEEE/ACM Transactions on Networking , vol. 2, pp. 122-136, April 1994.