RTP(アールティーピー)とは | 意味や読み方など丁寧でわかりやすい用語解説

RTP（Real-time Transport Protocol）は、インターネット上で音声や動画などのリアルタイムなデータを効率的かつ適切に転送するためのプロトコルである。主にVoIP（Voice over IP）による音声通話やビデオ会議、オンラインゲーム、ライブストリーミングといった、時間的制約が厳しく、遅延やパケットロスがサービスの品質に直接影響を与えるアプリケーションで利用される。

RTPは、信頼性よりもリアルタイム性を重視する設計思想を持つ。そのため、インターネットの基盤プロトコルの一つであるUDP（User Datagram Protocol）をベースに動作する。TCP（Transmission Control Protocol）のような、パケットの到達保証や順序保証、再送制御といった信頼性確保のメカニズムを持たず、リアルタイムデータ転送における不確実性、具体的にはネットワークの遅延変動（ジッタ）やパケットの順序の乱れ、パケットロスといった問題に対して、受信側が可能な限り高品質な再生を行うための情報を提供する役割を担う。

RTPは、リアルタイムデータ転送において発生しうる様々な問題を解決するために設計された。UDPは単にデータを送りっぱなしにするため、パケットが失われたり、届く順番がバラバラになったりすることがある。音声や動画のようなリアルタイムデータでは、わずかな遅延や途切れがユーザー体験を大きく損なうため、RTPはこのUDPの欠点を補い、受信側でのデータ再構築や同期を支援する情報を含んだヘッダを付加する。これにより、受信側はパケットの到達順序が乱れても正しい順序で再生を試みたり、パケットロスが発生した場合でも、残りのデータを用いて滑らかな再生を継続するための適切な判断を行ったりすることが可能になる。

RTPパケットのヘッダには、リアルタイムデータ転送に必要な多くの情報が含まれている。まず、バージョン（Version）フィールドはRTPプロトコルのバージョンを示す。次に、パディング（Padding）はパケットの末尾に詰め物を追加したことを示し、特定のブロックサイズに合わせる場合などに使用される。拡張（Extension）フィールドは、RTPヘッダにさらなる拡張情報を付加するためのフラグである。CSRCカウント（CSRC count）は、貢献ソース識別子（CSRC）の数を表す。マーカー（Marker）フィールドは、フレームの開始や特別なイベントなど、重要な境界を示すために使用され、特に動画ストリームにおいてフレームの区切りを知らせる際に役立つ。

ペイロードタイプ（Payload Type）フィールドは、RTPパケットに含まれるデータの種類（エンコーディング形式）を識別するために使用される。例えば、音声であればG.711やOpus、動画であればH.264やVP8など、さまざまなコーデックが指定され、受信側はこの情報を見て適切なデコーダを選択する。シーケンス番号（Sequence Number）は、送信されるRTPパケットごとに1ずつ増加する番号であり、受信側がパケットの欠落を検出したり、バラバラに届いたパケットを正しい順序に並べ替えたりするために不可欠な情報である。UDPではパケットの順序は保証されないため、このシーケンス番号は非常に重要となる。

タイムスタンプ（Timestamp）フィールドは、RTPパケットに含まれる最初のバイトがサンプリングされた時刻を示す。これは、ネットワーク上の遅延の変動（ジッタ）を吸収するためのジッタバッファの管理や、異なるメディアストリーム（例えば音声と動画）間の同期を取るために利用される。例えば、音声パケットと動画パケットは異なるRTPセッションで送信されることがあるが、タイムスタンプによってそれらの同期が保証され、唇の動きと音声が一致するような再生が可能となる。同期ソース識別子（SSRC: Synchronization Source Identifier）は、RTPストリームの送信元を一意に識別するための32ビットの乱数である。これは、複数の送信元が存在する場合でも、どのストリームからのデータであるかを区別するために用いられる。貢献ソース識別子（CSRC: Contributing Source Identifier）は、複数の音声ストリームをミキサーが合成して単一のRTPストリームとして送信する場合に、その合成元の各ソースを識別するために使用される。

RTPの主要な機能は、シーケンス番号によるパケットの順序付けと欠落検出、タイムスタンプによる再生タイミングの同期とジッタバッファ管理、そしてペイロードタイプによるメディア形式の識別にある。シーケンス番号を用いることで、受信側はパケットが正しい順序で届いているかを確認し、欠落しているパケットがあればそれを検知できる。ただし、RTP自体には欠落したパケットを再送する機能はない。これは、リアルタイム性が重視されるため、再送による遅延の方が問題となることが多いからである。再送が必要な場合は、アプリケーション層や上位プロトコルで別途メカニズムを実装する必要がある。

タイムスタンプは、ネットワークの不規則な遅延によって発生するジッタを吸収するための重要な要素である。受信側は、このタイムスタンプと自身の再生クロックを比較することで、到着したパケットを適切なタイミングで再生キューに入れることができる。これにより、ネットワーク遅延の変動があっても、滑らかな再生体験を維持する。ジッタバッファは、到着したパケットを一時的に蓄積し、タイムスタンプに基づいて適切な順序とタイミングで再生エンジンに渡すことで、ジッタの影響を緩和する。

RTPは通常、RTCP（RTP Control Protocol）と組み合わせて使用される。RTCPは、RTPセッションの品質を監視し、参加者に関する情報を提供するためのプロトコルである。RTCPパケットはRTPパケットとは異なるポートで送信されるが、RTPセッションと関連付けられている。RTCPは、送信側から受信側へ、または受信側から送信側へ、パケットロス率、ジッタ、ラウンドトリップタイム（RTT）などの統計情報や、送信側・受信側の帯域幅に関するフィードバック情報を定期的に送信する。この情報に基づいて、送信側は送信レートを調整したり、使用するコーデックを変更したりすることで、ネットワーク状況に適応し、通信品質を最適化することが可能となる。

RTPにはいくつかの限界も存在する。UDPベースであるため、RTP単体ではパケットロスに対する信頼性のある再送メカニズムを持たないことが最大の課題の一つである。また、NAT（Network Address Translation）やファイアウォールを越えて通信を行う際には、UDPパケットの通信経路確立がTCPよりも複雑になることがあり、STUN（Session Traversal Utilities for NAT）やTURN（Traversal Using Relays around NAT）、ICE（Interactive Connectivity Establishment）といった補助的な技術が必要となる場合が多い。さらに、RTP自体にはデータの暗号化機能が含まれていないため、通信の秘匿性を確保するには、SRTP（Secure Real-time Transport Protocol）などの上位プロトコルや、IPsecなどのセキュリティプロトコルと組み合わせて利用する必要がある。

これらの特性から、RTPはIP電話システムやテレビ会議システム、オンラインゲームの音声・チャット機能、IPTVなどのストリーミング配信、WebRTC（Web Real-Time Communication）といったリアルタイム通信が求められる幅広い分野で活用されている。