7.3.3 RTP (Real-time Transport Protocol)
1) RTPの機能
電話，テレビ電話，テレビ会議などのアプリケーションでは，利用者（人間）が快適に双方向の対話を行えるよう，低遅延であることが求められます．従って，音声，映像などのリアルタイム情報はUDPで送られるのですが，UDPは単にポート番号を指定しデータを転送する機能しか持ち合わせていません．マルチメディア通信に必要な次の機能は，UDPの上位層であるRTPが担います．
- パケット化 -- メディアデータをどのように区切るか，また1パケットにどのような情報を載せるかを定めます．
- パケット転送時の遅延，ゆらぎへの対策 -- IPネットワークでは，ルータでIPパケットをメモリーに蓄え宛先毎に振り分けます．その際ネットワークのトラフィックによってはパケットが遅れて到着したり，到着時刻にゆらぎが生じたりします．音声，映像などのリアルタイム・データにタイムスタンプをつけ，遅延，ゆらぎを把握しアプリケーション層で必要な対処ができるようにします．
- パケット廃棄への対策 -- IPネットワークは基本的にベスト・エフォットの考えに基づいていて，トラフィックが増えるとルータで廃棄されるパケットが出てきます．シーケンス番号を付けることで，アプリケーション層がパケット廃棄の位置を知り必要な対処（例えば，パケット廃棄により映像データの欠けた部分を周辺の映像で補い影響を見えにくくするコンシール<conceal>など）ができるようにします．
- メディア間同期 -- マルチメディア通信では，音声，映像，そのほか電子黒板からの信号のようなデータのメディアは同時並行して発生し，この時間関係をNTP (Network Time Protocol)[7-15]により受信側でも再現できるようにします．特に音声と映像の同期はリップシンク（lip sync）と呼ばれ，現実感や臨場感を伝える大切な要素です．なお「データ」という用語は，一般的にはメディアの種類を問わずディジタル化された情報を意味しますが，マルチメディアの文脈では，音声，映像以外の表現メディアを総称しています．
これらRTP機能のうち，メディア符号化の種類や情報源を示す機能，メディア間で共通的な機能はRTPヘッダとして規定され，メディア符号化に固有なパケット化の方法はそれぞれの符号化方式毎に規定されます．
2) RTPパケットヘッダ
RTPヘッダの構成，各フィールドの意味と役割を図7-10に示します．PT (Payload Type)フィールドはこのRTPパケットに入っているメディア情報が何であるかを示し，PT値が0〜95はRFC 3551[7-16]で静的に割り振られています．その一部を図7-11に示します．
PT値を各種メディア符号化に固定的に割り振る方法では，将来的に多数の符号化方法が開発されたとき対処できなくなることから，PT値が96〜127の範囲は動的割り当てになっています．具体的な割り当ては，標準ではなくアプリケーションが行い，それがどの符号化に対応しているかは，通信制御プロトコルで記述されます．新たな符号化はメディア・タイプ，サブタイプ，クロック・レート，チャネル数（音声符号化の場合），参照標準の形で登録されます．その登録手順はRFC 4585[7-17]に規定され，登録はIANA（アイアナ，Internet Assigned Numbers Authority）を通じて行います．現在どのようなメディア符号化のパケット化規定が定義済みであるかは，IANAの"Real-Time Transport Protocol (RTP) Parameters"ページ[7-18]に掲載されています．登録例を図7-12に示します．
動的なPT値と符号化の対応は，H.323テレビ会議システムではH.245のメッセージに，SIPベースのテレビ会議システムではSIPで運ばれるSDP (Session Description Protocol)メッセージに記述されます．
PT (Payload Type)でメディア符号化の種類を示します．Sequence Numberは連続した番号で，もし受信結果に飛びがあればネットワークの途中でIPパケットが廃棄されたことを知ることができます．SSRC (Synchronization SouRCe)はメディアの送信源を示すID，CSRC (Contributing SouRCe)は複数のメディア発信源からの情報をミキシングした場合の個々のメディア源を示すIDです．
RFC 3551に記載されたもの以外の符号化方式とそのパケット化規定は，IANAページに登録されています．Media Type, Subtypeの情報がシステム制御プロトコル（H.245やSIPパケット中のSDPフィールド）に表示され，システムで使う符号化方式が特定されます．音声，映像以外にもアプリケーション，テキストの範疇もあります．この図は登録表の一部を抜粋したものです．
3) パケット化規定
国際標準か否かを問わず広く実用されるメディア符号化方法毎に，そのパケット化規則がIETF RFC (Request For Comments)に記載されます．新たなメディア符号化方法が標準化されたとしても，パケット化方法（RTPペイロード・フォーマット）のRFCが発行されない限り，システム標準の中で使うことが出来ません．
既存のパケット化規定のRFC番号は，図7-11および図7-12で抜粋を示しましたようにReference欄に記されています．完全なリストは上記2)で述べましたIANAページ[7-18]に記されています．
パケット化の例として，H.261の場合をRFC 4587[7-19]に依り図7-13に示します．RTPパケットはメディア符号化と密接な関係があり，ビデオ符号化の構造を引き継いでいます[7-20]．H.261の映像符号化データは16x16画素からなるマクロブロック（MB）が単位になっていて，3行 x 11列のMBがGOB (Group Of Blocks)を構成し，さらにCIF画面の場合は8行 x 2列のGOBがピクチャを構成します．RTPパケットは整数個のマクロブロック・データを格納します．RTPパケットの始めにはH.261ヘッダが挿入され，パケット内最初のMBが属するGOBの番号，前パケット最終MBのGOB内番号，直前パケットの最終MBでどのような量子化器，動き補償ベクトルが適用されたかの情報が送られます．これによりパケット損失が生じたときの回復を支援します．
H.261映像符号化データをRTPパケットで運ぶには，ペイロードの先頭にH.261固有のヘッダを付けその後に符号化データを搭載します．H.261ヘッダはパケット損失からの回復を早めるために有効です．H.261符号化データはバイト列ではなくビット列になっているため，MBの終わりは一般にパケットの終わり（パケットはバイト区切りになっている）と一致しません．そのため，パケットの始めには前パケットの最終MBのデータが，終わりには次パケットの先頭MBのデータが含まれていますので，ヘッダのSBIT，EBITでこれを識別します．
もう一つの例として，RFC 6184[7-21]で規定のH.264/AVC映像符号化データのパケット化を紹介します[7-22]．なお，RFC 6184はRFC 3984[7-23][7-24]の更新版です．H.264/AVC符号化では，スキャン順序に連なった整数個のマクロブロックがスライスを構成し，符号化データの単位となっています．この映像符号化データにヘッダをつけたパケットはNAL (Network Abstraction Layer)ユニットと呼ばれ，図7-14にその構成を示します．NALヘッダ1バイトの後にH.264/AVC符号化データもしくは補助情報が搭載されますが，符号化データはバイト単位にはなっていないので，最後に調整用ビットRBSP trailing bitsが挿入されます．
H.264/AVCデータには映像符号化データのほか，映像符号化の構造に関わるシーケンス，ピクチャの映像符号化パラメータ，あるいは付加情報のように，復号にとって重要なデータがあります．これらは非VCL NALユニットとして，図7-15に示しますように，VCL (Video Coding Layer) NALユニットと共にH.323システムの場合はRTPで，H.320システムの場合はH.221によって送られます．
H.264/AVC符号化データをRTPパケットで運ぶには，ペイロードの先頭にNALヘッダをつけ，その後に映像符号化データあるいは符号化モードなどの補助情報が搭載されます．ヘッダのnal_unit_typeがパケット化の方法を示します．RBSP trailing bitsは，映像符号化データが8ビットの倍数にはなっていないことから，調整用に入れられるビット列で，1〜8ビットで構成されます．この図の例ではNALユニット最終バイトの5ビットは無効データです．復号器ではパケット内最後の'1'の前までを符号化データとして処理します．
映像符号化データと符号化パラメータセットは別々のNALを構成し，H.323システムの場合はRTPパケットに搭載して送られます．符号化パラメータセットは，復号にとって重要なデータで，映像符号化データが壊れたとしてもある程度の映像が再現できるよう，映像伝送の頑健性を高めます．
一つのRTPパケットにNALユニット一つを搭載するシングルNALユニットパケットが基本ですが，RFC 6184では，図7-16に示しますように一つのRTPパケットに複数のNALユニットを搭載する集合パケット，一つのNALユニットを複数のRTPパケットに分割して搭載する分割ユニットと呼ばれるパケット化を定義しています．
これら各種のパケット化は，ペイロード内容とともにNALヘッダのnal_unit_typeで表示されます．nal_unit_typeの一覧表を図7-17に示します．
H.323システムでH.264映像を送る場合，デフォールトはシングルNALユニットのパケット化により，NALユニットサイズは1400バイト以下とH.241[7-25]で規定されています．この値はEthernetのMTU (Maximum Transmission Unit)が1500バイトであることに由来しています．
NALユニットサイズとRTPペイロードサイズの大小関係により，大きくは3種類のパケット化があります．すなわちRTPパケットに一つのNALユニットが収まる場合，複数のNALユニットが収容される場合，一つのNALユニットが複数のRTPパケットに分割して収容される場合です．
H.264/AVCデータのパケット化では，パケット化の方法とペイロードの内容をNALヘッダのnal_unit_typeで識別できるようにしています．
4) RTCP
RTCの対になるプロトコルとしてRTCP (RTP Control Protocol, リアルタイム・データ転送制御プロトコル)がRTPと同じRFC 3550[7-14]に定義され，データ転送状況のモニタリングと最低限の送受信間制御を可能にしています．
RFC 3550では，RTPは偶数ポート番号で受信し，RTCPはその次に大きい奇数ポート番号で受信することが推奨されています．
RTPパケットはUDPで運ばれるため，ネットワークが輻輳したとしても，送信側は構わずデータを流し続けます．そこで，RTPストリームの受信側からRTCPで受信パケットの廃棄率やパケット到着間隔のゆらぎを報告し，ストリームの送信元が対処できるようにします．このフロー制御がRTCPの最重要機能です．
この他に，RTCPは送信ストリームに関わるタイムスタンプ（時計の刻みはストリーム毎に8 kHzや90 kHzなどと異なる）とNTP (Network Time Protocol)で得られる基準時刻の対応関係を伝えたり，ストリーム発生源を識別情報などで記述する機能を実現します．
また，RTCPはSIP環境下でピクチャが失われ，デコーダ・リフレッシュのため全イントラを要求するなど，送信側にアクションを伝えるなどの目的にも使われます．具体的にはRFC 4585[7-26]，RFC 5104[7-27]に規定されています．
5) H.323システムにおけるRTPパケット伝送例
テレビ会議システムでどのようにメディアが多重化されているかの実例を図7-18に示します．Wireshark[7-28]と呼ばれるパケット分析ツールで記録したIPパケットのうちRTPパケットを搭載したIPパケットを抽出してその内容を示しています．表の各列の意味は次の通りです．
No. -- IPパケット番号（より正確にはイーサネット・パケット番号）
Time -- 上記パケットのキャプチャ時刻
Source, Destination -- パケットの送信元と受信先IPアドレス
Protocol -- ここではRTPパケットを観察対象に選択
Length -- イーサネット・パケットのペイロードの長さで，RTP/UDP/IP/Etherヘッダ54バイトを含む値．イーサネットのMTUが1500バイトなので，それに収まるようメディア情報がパケット化される
Info -- RTPパケットヘッダに記載のペイロード・タイプ，情報源番号，シーケンス番号，タイム・スタンプ値
H.323テレビ会議端末をネットワークにつなぐイーサネット・ケーブル中を流れるパケットの観察結果です．多様なIPパケットが流れているうち，送信元から宛先に送られるRTPパケット搭載のイーサネット・パケットを1/4秒間抽出しました．各メディアがどのような頻度でパケット化されるかや，各RTPパケットに含まれるデータ量がわかります．"Info"はRTPパケットヘッダの内容を示しています．"Time="の値はタイムスタンプ値で，G.722音声では8 kHzのクロックが，H.263およびH.264映像では90 kHzのクロックが示す値です．映像パケットで"Mark"とあるのは，RTPヘッダのM (marker)ビットがonで，フレームのデータがそのパケットで終了することを示します．
この例では音声にはG.722広帯域音声符号化が使われ，64 kbit/sの速度で送られます．パケット化は20 ms毎に行われ，その間に発生する情報量は160バイトです．会議参加者を撮す映像にはH.264/AVC符号化が使われ最大ビットレートは320 kbit/sに設定されています．1映像フレームの符号化データが1〜2パケットに収容されています．その他にH.239[7-29]制御（第8.1.5項で詳述します）によるプレゼンテーションのためのPC画面伝送にH.263映像符号化が用いられ，最大ビットレートは128 kbit/sに設定されています．画面サイズがXGA (768 x 1024画素)ですので1フレームの符号化データは平均8 kbyte程度となり，8個前後のRTPパケットに分けて送られています．
6) RTP/RTCPポート番号
メディア情報（片方向）を送るためのRTPに対し，制御のRTCPは双方向に設定する必要があります．送信側からメディアに関する情報を送ることと受信側からRTPパケットの受信結果を返す，などのためです．テレビ会議のような双方向通信の場合，RTPが2本に対し，RTCPが4本ということになりますが，H.323システムではRTCPは2本にして，順方向のRTPと逆方向のRTPに関する制御情報を双方向のRTCPチャネルで送受信することとしています．
H.323システムでは，RTP/RTCPの送受信で同じポート番号を使うことにしています．従って使用するポート番号は一つのメディア情報に対し，片側が2mと2m+1，もう片側が2nと2n+1の4個です．
具体的にどのポート番号を使うかは，第8.1.1項2)で説明しますH.245の論理チャネル開設（Open Logical Channel）メッセージとそれに対するACK (ACKnowledgement)メッセージに記されています．