WebRTC（Web Real-Time Communication）は、ウェブブラウザやモバイルアプリ間で、プラグイン不要のまま音声・映像・データをリアルタイムにやり取りできるオープンな技術群です。

双方向の通話やビデオ会議など、即時性が重要なユースケースに最適化されています。適切な条件下では、遅延を150ミリ秒未満に抑えることも現実的です。

ピア・ツー・ピア（P2P）のデータ伝送では、一度接続が確立されると、サーバーを介さずに当事者間で直接送受信が行われます。

ただし、接続を開始するための仲介役（シグナリング）はWebRTCの仕様外であり、従来は開発者が独自に実装する必要がありました。これがライブ配信分野での普及を阻む一因で、シグナリング設計が複雑になりがちだったのです。

仲介役（シグナリング）とは、WebRTC通信を開始する前に、通信相手（ピア）どうしが接続に必要な情報を交換する仕組みを指します。イメージとしては、電話をかける前にまず番号を伝え合うようなものです。

目次 [ close ]
  1. WebRTCとは
  2. WHIP（WebRTC-HTTP Ingestion Protocol）とは
  3. WHEP（WebRTC-HTTP Egress Protocol）とは
  4. WebRTCの仕組みが簡単になった

WebRTCとは

WebRTCの実データ転送自体はP2Pで行われますが、接続を確立するまでの段階ではサーバー経由のシグナリングが不可欠です。このシグナリングは仕様で定義されていないため、実装方式はアプリやサービスごとに異なります。

シグナリングサーバーは、通話の開始・終了・変更などセッション状態の管理を担い、相手方のIPアドレスやポート番号などの経路情報を交換します。NATやファイアウォール越えに必要な情報（ICE候補）もここで扱われます。また、利用する映像・音声コーデック、解像度、ビットレートなどメディア仕様に関する情報（SDP）も交換します。

この情報交換は、WebSocketやHTTPなどを用いたシグナリングサーバー経由で行われます。具体的には、オファーとアンサー、それに接続候補（ICE候補）をやり取りし、P2P通信の準備を整えます。シグナリングが完了して接続が確立されれば、その後のデータ転送に仲介サーバーは不要です。WHIPやWHEPは、まさにこのシグナリング手続きを標準化した仕組みです。

標準化以前は、サービスごとに実装がバラバラでツール間の相互運用性も乏しく、配信・再生の接続は非常に複雑でした。結果として、独自実装やデバッグに多大な工数がかかり、ベンダーロックインやエコシステムの分断も生じていました。WHIPとWHEPはシグナリングをHTTPベースで標準化することで、これらの課題を解消し、低遅延WebRTCライブストリーミングの構築・運用を大幅に単純化しました。

従来はシグナリング専用のWebSocketサーバー等を別途用意する必要がありましたが、WHIP/WHEPの採用により、その要件を軽減できます。

 

WHIP（WebRTC-HTTP Ingestion Protocol）とは

WHIPは、WebRTCのストリームをライブ配信向けに「送り出す（Ingestion）」ための標準的なシグナリングプロトコルです。従来、配信ツール（例：OBS Studio）からメディアサーバーへ映像を送る際は、サーバーごとに異なるシグナリング実装が必要でしたが、WHIPがこの手続きを標準化します。

HTTPのPOSTリクエストを用いてシグナリングを行うため、実装負担を減らし、RTMPに近いシンプルさで接続できます。開発・運用のハードルが下がるのが大きな利点です。

相互運用性の向上：OBS Studioをはじめ多くの配信ツールがWHIPに対応し、さまざまなサーバーへWebRTCストリームを容易に配信できるようになりました。

 

WHEP（WebRTC-HTTP Egress Protocol）とは

WHEPは、メディアサーバーから視聴者のクライアントへWebRTCストリームを「届ける（Egress）」ための標準的なシグナリングプロトコルです。WHIPが配信側を担うのに対し、WHEPは視聴側の接続を標準化します。

WHIPと同様、HTTPベースの手順で視聴を開始できるため、開発者はWebRTCストリームをクライアントアプリに容易に統合可能です。

 

WebRTCの仕組みが簡単になった

WebRTCがもつリアルタイム通信の強みを、WHIP/WHEPという「標準化されたつなぎ方」で活用することで、低遅延かつ高品質なライブストリーミングを、より簡潔かつ相互運用性高く実現できます。

例えばWHIPとWHEPを使うと、各コンポーネントが標準化手順で連携し、低遅延ライブ配信が組みやすくなります。

GStreamer → メディアサーバー（例：OvenMediaEngine） → Webアプリ の連携イメージ

送信側：GStreamer
役割：カメラやファイル入力からの映像・音声を取得しエンコード。プロトコル：WHIPクライアントとして動作し、WebRTC形式でOvenMediaEngineへ送出。具体例：gst-plugins-rsに含まれるwhipsink要素で、WebRTC送出パイプラインを構築可能。

メディアサーバー：OvenMediaEngine
役割：WHIPで送られてきたWebRTCストリームを受信し、WHEPに対応したWebアプリ向けに配信。機能：シグナリング機能を内包しているため、別途シグナリングサーバーを用意しなくても運用しやすい。

受信側：Webアプリ
役割：視聴者のブラウザでライブストリームを再生。
プロトコル：WHEPクライアントとして動作し、OvenMediaEngineから映像・音声を受信。具体例：JavaScript製のWHEPクライアントライブラリを用いれば、シンプルなHTTPリクエストで再生を開始可能。

このように、WHIP/WHEPという共通規格があることで、GStreamerのような幅広いツール、OvenMediaEngine、そしてWebブラウザといった異なるプラットフォーム間でも、互換性の問題を最小化してシームレスに連携できます。

 

* W3C WebRTC WG（ブラウザAPIの標準化）:
(https://www.w3.org/groups/wg/webrtc/)

* IETF RTCWEB WG（プロトコル標準化）:
(https://datatracker.ietf.org/wg/rtcweb/about/)

* **「シグナリングは仕様外」「SDP/ICE 交換」の根拠**（公式ドキュメント）

* MDN: Signaling とビデオ通話概説:
(https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling)

* MDN: WebRTC プロトコル（ICE/SDP 等）:
(https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols)

* **遅延の目安（≈150ms）**

* ITU-T G.114（片方向遅延の推奨値）:
(https://www.itu.int/rec/dologin_pub.asp?id=T-REC-G.114-198811-S%21%21PDF-E&lang=e&type=items)

* **WHIP の正式仕様**

* RFC 9725（WebRTC-HTTP Ingestion Protocol）:
(https://www.rfc-editor.org/rfc/rfc9725.pdf)

* **WHEP の現行ステータス**

* IETF Internet-Draft（WebRTC-HTTP Egress Protocol）:
(https://datatracker.ietf.org/doc/html/draft-ietf-wish-whep)

* **P2PでもTURN経由になり得る点の一次情報**

* webrtc.org（TURN サーバー解説）:
(https://webrtc.org/getting-started/turn-server)

* **「GStreamerでWHIP送出可能」の根拠**

* gst-plugins-rs（`whipsink` 実装）:
(https://github.com/GStreamer/gst-plugins-rs)