映像・音声のIP伝送を支える主要メディア伝送プロトコル解説

これは「NTTテクノクロス Advent Calendar 2025 シリーズ1, 9日目」の参加記事です。

NTTテクノクロスの川崎です。普段は映像・音声データを取り扱うメディア処理・メディア伝送システムの開発業務に従事しています。

はじめに

この記事では、映像(Video)・音声(Audio)をはじめとするマルチメディア(Multimedia)データを、IP(Internet Protocol)ネットワークを介して伝送する際に用いられるメディア伝送プロトコルの概要を紹介します。

今回紹介するメディア伝送プロトコルは、一般的なWebユーザ向けから放送業界プロフェッショナル向けまで、様々なユースケースで利用されます。

• 2ユーザ間でのIP電話音声通話（VoIP; Voice over IP）
• 複数ユーザ間でのリアルタイムオンライン会議（Web会議）
• 配信サーバから大規模ユーザへのVoD(Video on Demand)動画配信
• 配信サーバから大規模ユーザへのライブ動画同時配信
• 撮影拠点から配信サーバへの動画データ伝送
• IPカメラから管理サーバへの動画データ伝送
• 放送・音響IP機材間や遠隔拠点間での素材データ伝送

メディア伝送プロトコルへの要件

映像・音声データ伝送のユースケースでは、一般的なデータ通信とは異なる技術要件が求められます。全ての要件を同時に満たすメディア伝送プロトコルは存在しないため、利用目的に応じた選択を行う必要があります。

• リアルタイム性 ：リアルタイムコミュニケーション用途では、通信遅延(Delay)の最小化が重要視されます。
• データ欠損の許容 ：リアルタイム性を実現する代償として、一定程度までのデータ欠損を許容します。映像・音声は部分的に破損しますが、短時間で復旧することが求められます。
• 双方向通信 ：リアルタイムコミュニケーション用途では、通信ホスト間でデータ送信と受信を同時に行うユースケースがあります。
• 大規模配信(1:N通信) ：受信ホスト数（ユーザ数）が数万オーダーを超えるユースケースが存在します。IPマルチキャストやCDN(Content Delivery Network)技術との親和性が求められます。
• 時刻同期制御 ：放送向けIP機材などプロフェッショナル向けユースケースでは、映像・音声データ通信機材間で厳密な時刻同期が求められます。

メディア伝送プロトコルの構成

本記事では、メディア伝送プロトコルの構成要素を以下のように整理します。

多くのメディア伝送プロトコルでは、メディア・トランスポート仕様とシグナリング仕様を規定します。¹

• IPトランスポート(IP Transport) ：通信ホスト間での汎用データ伝送プロトコル。TCP, UDP, QUICやHTTP/HTTPSが利用されます。²
• メディア・トランスポート(Media Transport) ：いずれかのIPトランスポートを利用して、映像・音声データを伝送するための通信プロトコル。
• メディア・コーデック(Media Codec) ：メディア・トランスポートで伝送される映像・音声データや、付随する時刻情報のデータ表現仕様。³
• シグナリング(Signaling) ：映像・音声データ伝送に先立って、通信ホスト間でデータ仕様について情報交換・合意するためのプロトコル。

以降のセクションから、メディア伝送プロトコルのユースケースや特徴について解説してゆきます。

RTP

RTP(Real-time Transport Protocol) は、その名前が示す通りリアルタイム通信向けのメディア・トランスポート仕様です。IPトランスポートにはUDPを利用するため、ユニキャスト通信(1:1)とマルチキャスト通信(1:N)いずれのユースケースにも対応可能です。RTPではシグナリング仕様を規定せず、別プロトコルとの組み合わせを前提とします。

RTPはTCP通信と異なり信頼性のないUDP通信を前提とするため、受信側でパケット並び替え／重複除去／欠落検知を行う必要があります。パケット欠落を検知した場合、送信側に対してパケットの自動再送要求(ARQ; Automatic Repeat reQuest)や、メディア・コーデック復旧を要求する拡張的な運用も可能です。このような仕組みにより、UDP通信の低遅延性を活かしつつデータ欠損時のダメージ最小化を図ります。

RTPは約30年の歴史をもつ古い仕様ですが、2025年現在も現役で運用される重要なプロトコルです。後述するWebRTCやMoIP／AoIPなど、モダンなメディア伝送プロトコルのメディア・トランスポートでも利用されます。

RTCP

RTCP(Real Time Control Protocol) は、RTPとペアで利用される通信プロトコルです。RTCPはメディアデータを直接扱うのではなく、RTPによる映像・音声データ通信を制御するための補助的な通信を担います。RTCPはオプショナル機能であり、利用は必須ではありません。IPトランスポートにはUDPを利用し、慣例的に「RTPに偶数UDPポート番号を、RTCPには後続の奇数UDPポート番号」を動的に割り当てます。例) RTP＝UDP/5004, RTCP＝UDP/5005を割り当て。

RTP＋RTCPの組み合わせでリアルタイム通信路のネットワーク状態を間接的に監視し、送信側でパケットロス率や往復遅延時間(RTT; Round Trip Time)推定を行います。ネットワーク状態に基づいて映像・音声エンコーダをフィードバック制御することで、受信側でのユーザ体感品質(QoE; Quality of Experience)の極端な低下を防ぐことができます。例) パケットロス率が上昇した場合、送出ビットレートを下げて映像・音声の途切れを防ぐ。

FEC

FEC(Forward Error Correction) は、RTPをはじめとするリアルタイム用途メディア・トランスポートで併用されるエラー訂正技術の総称です。送信側からは本来の映像・音声データを含むパケットに加えて、エラー訂正用の特殊パケットも同時に送出します。受信側で映像・音声パケット欠落を検知したとき、エラー訂正用パケットを用いると一定程度までのパケット欠落であれば完全に復元できます。

FECのメリットとして、自動再送要求(ARQ)のように受信側から送信側へのフィードバック通信を必要としないため、受信側で正しい映像・音声データを復元するまでの遅延を最小化できます。FECのデメリットとしてエラー訂正用パケットを追加送信するため、多数のパケット欠落に備えようとするほど通信帯域を圧迫します。実運用ではFECとARQを組み合わせたパラメータ設計が重要となります。

SIP

SIP(Session Initiation Protocol) は、RTPメディア・トランスポートを用いた双方向通信のシグナリングを行う通信プロトコルです。IPトランスポートにはUDP/5060またはTCP/5060を利用します。SIPはSIPサーバとSIPクライアントからなるクライアント・サーバ構成を前提とします。SIPサーバは通信ホスト間のシグナリングのみを仲介し、映像・音声データ通信そのものには関与しません。

SIPはレガシーなIP電話システムやWeb会議システムで広く運用されきた歴史があります。長い歴史の中で各ベンダ実装の相互運用性を実現するために多数の仕様が規定されており、SIP全体ではかなり複雑な仕様となっています。既存SIPシステムと新規WebRTCシステムを中継接続するゲートウェイサーバも存在します。

SDP

SDP(Session Description Protocol) は、シグナリングにおいて映像・音声データに関する仕様を記述するプロトコルです。SDPは狭義の通信プロトコルではありませんが、メディア伝送の文脈では重要な意味を持ちます。送信側ではこれから送り出す予定のメディアデータ仕様、受信側では受け入れ可能なメディアデータ仕様の記述に利用します。

SDPでは、映像・音声データが持つ属性をテキストデータとして記述します。

• IPトランスポートの情報
• メディア・コーデック種別
• データ帯域（1秒あたりデータサイズ）
• クロックレート（メディア時刻表現の分母）
• 映像解像度、フレームレート[frame/sec]
• 音声チャネル数、サンプリング周波数[Hz]

RTSP

RTSP(Real Time Streaming Protocol) は、RTPメディア・トランスポートを用いた片方向通信のシグナリングを実現する通信プロトコルです。IPトランスポートにはTCP/554を利用します。RTSPではメディアストリーミング向け機能として、再生／一時停止／時間シークといったきめ細やかなストリーミング制御を実現します。

RTSPもRTPやSIPと同時期に策定された歴史あるプロトコルですが、仕様がシンプルなことからIPカメラなどの映像機器では広く利用され続けています。

RTMP

Real Time Messaging Protocol(RTMP) は、特定ベンダ製品で利用されていた通信仕様がデファクト標準として広まった片方向リアルタイム通信向けメディア伝送プロトコルです。IPトランスポートにはTCP/1935を利用します。UDPベース通信に比べるとリアルタイム性は劣りますが、TCPベースのためデータ欠損は生じません。

RTMPは古いデファクト標準のため新しいメディア・コーデックに追従しておらず、各ベンダによる独自拡張が行われたことで相互運用性に難点がありました。しかし近年 Enhanced RTMP という統一仕様を策定する動きが出てきたため、実装間の互換性問題は解決しつつあります。

RTMPは比較的仕様がシンプルなこととTCPによる高信頼特性から、撮影拠点から配信サーバへのデータ伝送(Ingest)、IPカメラからホストPC間といたデータ伝送で広く用いられています。

HLS／MPEG-DASH

HLS(HTTP Live Streaming) と MPEG-DASH は、従来Webコンテンツ配信技術と親和性の高い動画配信向けメディア伝送プロトコルです。IPトランスポートにHTTP/HTTPSを用いるため、通常のWebサーバにファイルを配置するだけで動画配信サーバとして機能します。クライアントからは単なるWebコンテンツのダウンロード動作となるため、CDNキャッシュサーバを利用した大規模配信にもスケーリング可能です。リアルタイム通信には不向きですが、数十秒オーダーまでの遅延を許容できるならライブ配信にも利用可能です。

HLSとMPEG-DASHは仕様策定経緯や技術詳細こそ異なるものの、基本コンセプトは「動画チャンク群に対するプレイリスト情報」と表現できます。プレイリストはシグナリング相当の情報を含みます。受信側はプレイリストに従って動画チャンクを順次ダウンロードし、映像・音声データを連続的に再生します。受信側の都合で動画品質とデータサイズのトレードオフを選択できるため、送信側では複数パターンのデータを用意しておくだけで、各ユーザのネットワーク環境に合わせた品質コントロールを実現できます(Adaptive Bitrate Streaming)。

CMAF

CMAF(Common Media Application Format) は、HLSとMPEG-DASHの統合運用を目的としたメディア・コーデック仕様です⁴。IPトランスポートにはHTTP/HTTPSを、シグナリングにはHLS（m3u8形式）／MPEG-DASH形式（MPD形式）をそのまま利用します。

CMAFデータ仕様とHTTPのチャンク転送機能(CTE; Chunked Transfer Encoding)を組み合わせた CMAF-ULL(Ultra Low Latency) では、配信遅延を数秒オーダーまで短縮した低遅延配信を実現します。CMAFベースでWebコンテンツ配信技術との親和性は高いものの、CMAF-ULLを実現するには配信サーバ、CDN、再生クライアントの全てで追加対応が必要となります。

WebRTC

WebRTC(Web Real-Time Communication) は、Web技術をベースとした双方向リアルタイム通信向けメディア伝送プロトコルです。実際にはWebRTCという名前の単一プロトコルは存在せず、様々な既存技術を組み合わせたフレームワークという表現が正確かもしれません。IPトランスポートは主にUDPを、メディア・トランスポートにはRTP＋RTCPを利用します⁵。WebRTCではシグナリング仕様を規定しないため、別プロトコルとの組み合わせが必要となります。

WebRTCは2ホスト間の双方向P2P(Peer to Peer)通信を基本としますが、MUC(Multipoint Control Unit)やSFU(Selective Forwarding Unit)機能を持つ配信サーバを介して多拠点間リアルタイム・コミュニケーションを実現します。SFU配信サーバとメディア・コーデック層のサイマルキャスト(Simulcast)やSVC(Scalable Video Codec)技術と組み合わせると、受信側のネットワーク状況に応じた低遅延伝送も実現できます｡

WebRTCは「相手と繋がること」を重要視しており、NATやファイアーウォールなど多様なネットワーク環境下にあるホスト同士での映像・音声メディア通信を実現する技術（ICE, STUN, TURN）を備えています。本記事の範囲を超えるため、ここでは用語紹介にとどめます。

WebRTCはWebブラウザ上で1秒以下の低遅延性を実現するリアルタイム通信の標準技術として広く普及しています。また必ずしもWebブラウザを必要とせず、ヘッドレスクライアントからWebRTC通信を行うライブラリ実装も存在します。

WHIP／WHEP

WHIP(WebRTC-HTTP Ingestion Protocol) と WHEP(WebRTC-HTTP Egress Protocol) は、WebRTCに対するシグナリングを規定する通信プロトコルです。WHIPは撮影拠点にある配信クライアントから配信サーバに対するデータ伝送(Ingest)で、WHEPは配信サーバから再生クライアントに対するデータ伝送(Egress)での利用が想定されています。IPトランスポートはHTTP/HTTPSを利用します。

2025年現在はまだ新しいプロトコルであり、今後の普及によって各種クライアント／配信サーバ実装間での相互運用性向上が期待されます。

SRT

SRT(Secure Reliable Transport) は、安全性・高信頼性を目指すリアルタイム通信向けメディア・トランスポート仕様です。IPトランスポートにはUDPを利用します。SRT仕様はメディア・コーデックとシグナリングを規定しないため、どんなデータでも伝送可能です。SRTで映像・音声データを伝送する場合、RTPパケット（別のメディア・トランスポートの入れ子運用）やMPEG-TSデータ（メディア・コーデック層）をSRTペイロードとして扱います。

SRTの特徴として、あらかじめ送受信側双方で遅延時間(Latency)を合意しておき、その範囲内でIPネットワークの伝送遅延揺らぎ(Jitter)を隠蔽する機能があります。受信側では遅延時間分の受信バッファを用意し、時間猶予内であれば欠落パケットの自動再送要求(ARQ)を行いつつオリジナルのパケット送信タイミングを復元します。またFEC技術によるエラー訂正もサポートします。

SRTは接続性を高めるため、データ通信方向とSRTセッション確立方向を独立に制御できます。例えば送信側がSRT接続を待ち受け(Listener)、受信側からSRT接続を行うといった動作(Caller)も可能です。この機能によりネットワーク構成を柔軟に設計しやすくなります。

RIST

RIST(Reliable Internet Security Transport) は、プロフェッショナル用途を想定した低遅延・安全性・高信頼性を目指すリアルタイム通信向けメディア・トランスポート仕様です。IPトランスポートにはUDPを利用し、RTP仕様を拡張したプロトコルにより映像・音声データRTPパケットをRISTペイロードとして扱います。RISTはシグナリング仕様を規定せず、別プロトコルとの組み合わせを前提とします。

RISTは標準化団体VSF(Video Services Forum)によりVSF TR-06勧告として標準化された仕様であり、各ベンダ機器間の相互運用性が重要視されています。RTP仕様をベースとしているため、既存ネットワーク機器で取り扱いやすいというメリットもあります。また、IP/UDPマルチキャスト通信に対応しているため複数拠点への同時配信もサポートします。

MoIP／AoIP

MoIP(Media over IP) と AoIP(Audio over IP) は、プロフェッショナル向けの放送機器・音響機器間をIPネットワークベースで接続する技術の総称です。従来はSDI(Serial Digital Interface)ケーブルやXLRケーブルで接続されていた映像・音声データ伝送経路を、取り回しの良いEthernetケーブルや光ファイバに置き換えることができます。非圧縮の映像・音声データを取り扱うため、1Gbps～100Gbps超の高品質・広帯域IPネットワークが前提となります。

MoIP／AoIPでは各ベンダ機材の相互運用性が重要視されるため、標準化団体SMPTE(Society of Motion Picture and Television Engineers)によるデジュール標準としてメディア・トランスポートや関連する技術仕様が規程されます。いずれもRTPを拡張した仕様であり、IP/UDPマルチキャスト通信による運用が基本となります。

• SMPTE ST 2022-6 ：非圧縮の映像＋音声データをそのままIPネットワーク上で伝送する仕様（SDI over IP）。
• SMPTE ST 2022-7 ：複数IPネットワーク経路で冗長伝送されたストリーム間のシームレス切替を定める。
• SMPTE ST 2110-20 ：非圧縮の映像データのみをIPネットワーク上で伝送する仕様。
• SMPTE ST 2110-30 ：非圧縮の音声データ（AES67 形式）のみをIPネットワーク上で伝送する仕様。
• SMPTE ST 2110-40 ：補助データ(ANC; Ancillary)のみをIPネットワーク上で伝送する仕様。
• PTP(Precision Time Protocol) ：SMPTE ST2022／2110通信機材間でマイクロ秒精度の時刻同期を実現するプロトコル。厳密な時刻情報源にはGNSS信号を利用する。

NMOS

NMOS(Networked Media Open Specification) は、SMPTE ST 2110通信機器間で共通のシグナリングを実現するプロトコルです。IPトランスポートはHTTP/HTTPSを利用し、RESTful APIとして仕様規定されます。NMOS RDS(Registration and Discovery Server)、NMOSノード、NMOSコントローラから構成され、NMOSコントローラからNMOSノード間のST2110通信のシグナリングを一元的に制御します。

• NMOS RDS：閉域ネットワーク上のNMOSノード情報が登録され、NMOSコントローラから発見可能とする。
• NMOSノード：SMPTE ST 2110映像・音声データ送受信を行う機材。例) カメラ、スイッチャー、ビュワーなど。
• NMOSコントローラ：NMOS RDSに登録されたNMOSノードに対して、SDP情報や通信開始／停止を指示する。

Dante

Dante は、プロフェッショナル向け音響機材間でIPネットワーク上の音声データ伝送を実現するベンダ規格です。一般的なネットワーク機材とLANケーブルを用いて、複数チャネル音声データの双方向リアルタイム通信を実現します。時刻同期プロトコルにはPTPを利用し、接続された機材は厳密に時刻同期されます。Danteコントローラから機材間の音声データ通信のシグナリングを一元的に制御します。

Dante音声データ伝送はIPトランスポートにUDP、メディア・トランスポートにRTPを利用します。Dante音声データのサブセットはAES67規格に準拠し、他のAES67準拠AoIPプロトコル⁶やSMPTE ST 2110-30対応機器との相互運用も行えます。

おわりに

NTTテクノクロスでは、本記事で紹介した各種プロトコルを一部取り扱う自社プロダクト開発・販売、OSSや他社プロダクトとも組み合わせたシステムインテグレーション業務も行っています。

これらのシステム導入や活用事例にご興味お持ちでしたら、下記紹介ページよりお気軽にお問い合わせください。

• 映像ストリームルーティングソフトウェア メディアストリームルーター
• ファイルトランスコーダ RealFeel（リアフィール） FileConvert 4K

1. シグナリング仕様を規定しないメディア伝送プロトコルも存在します。例) RTP, WebRTC, SMPTE ST2022/2110 ↩

2. "IPトランスポート" は、メディア伝送プロトコルの構成説明のために導入した固有の用語です。一般的なプロトコルスタックで定義されるレイヤとは異なることに留意ください。 ↩

3. 例) 映像データ圧縮ではH.264, VP9, AV1など、音声データ圧縮ではAAC, Opusなどが利用されます。プロフェッショナル向けの素材伝送では、データ圧縮を行わない非圧縮映像・非圧縮音声データ形式も利用されます。また映像・音声データを包含するMPEG-2 TS, MP4のメディアコンテナ(Media Container)が同時に利用されることもあります。 ↩

4. 本記事での構成要素区分に合わせて "メディア・コーデック" と表現しましたが、厳密には映像・音声データを含むメディアコンテナ仕様を規定します。HLSとMPEG-DASHの両方でサポートするFragmented MP4(fMP4)形式をベースとした仕様です。 ↩

5. 厳密にはWebRTCのIPトランスポートはDTLS（≒暗号化UDP）、メディア・トランスポートはSRTP（≒暗号化RTP）が利用されます。またWebRTC通信ではRTP＋RTCPが同一UDPポートを共用した運用が行われます。 ↩

6. AoIPを実現する規格として、Dante, Ravenna, Livewire, Q-LAN, WheatNet が存在します。これらの規格間で相互運用を実現するため、共通サブセット仕様としてAES67が定義されました。 ↩