WHIP 機能¶
概要¶
RFC 9725 で定義されている WHIP (WebRTC-HTTP Ingestion Protocol) を利用した WebRTC 配信に対応しています。
ここでは Sora や WHIP 仕様について説明します。
注意¶
- Sora の WHIP は RFC 9725 準拠を前提としています
- ただし OBS Studio の WHIP での動作を優先しているため、 RFC の WHIP 仕様とは異なる場合があります
- Sora SDK は WHIP へ対応していません
- 現時点では WHIP を利用した接続の統計ウェブフックの送信には対応していません
WHIP クライアントのお問い合わせについて¶
WHIP クライアントに関する質問などの報告は Discord の利用をお願いします。
Sora の WHIP クライアントについての質問やバグ報告は Discord の #sora-sdk-faq チャンネルにお願いします。
映像コーデックパラメータについて¶
WHIP では映像コーデックのパラメーターを認証払い出し時に指定しても有効になりません。
WHIP とは何か¶
WHIP は WebRTC-HTTP ingestion protocol の略で、 WebRTC では標準化されていないシグナリングをブロードキャスト/ストリーミング系の配信ツール向けに規定した規格です。
WHIP は仕様を小さくして、実装を簡単にすることで配信ツールが取り込みやすくしています。
クライアントが HTTP POST で Offer SDP を送信して、Answer SDP を受け取るというシンプルなシグナリング規格です。
2023 年 12 月リリースの OBS 30.0 にて WebRTC/WHIP が正式にサポートされました。
最新版は以下からダウンロードができます。
https://obsproject.com/download
WHIP のシーケンス図¶
Sora の WHIP のシーケンス図¶
Sora では WHIP エンドポイント、WHIP セッション、メディアサーバーすべてを Sora が担当します。
OBS の WHIP 対応について¶
2025 年 6 月 時点での OBS の WHIP 対応では輻輳制御が実装されていません。 これは OBS が WHIP 対応のために利用している libdatachannel が輻輳制御に対応していないためです。
そのため、回線が不安定になったとしても、ビットレートを下げたりするといったことは行いません。
サイマルキャスト対応¶
- Pull-Request:
今後 OBS で対応される予定です。Sora では 2025 年 12 月リリース予定の Sora にて対応予定です。
OBS 以外の WHIP クライアントへの対応について¶
新しい WHIP クライアントへの対応は有償での優先実装として対応を検討できますので、 対応希望の WHIP クライアントと優先実装については、サポートまでメールにてご連絡ください。
ブラウザでの WHIP 対応¶
ブラウザからの WHIP 接続は条件付きでサポートしています。
- 音声は
Opusのみ - 映像は
AV1/H.264/H.265のみ - コーデックは音声、映像ともに 1 つのみ
setCodecPreferencesを利用して 1 つのみを指定してください
modeはsendonlyのみofferはa=sendonlyのみ
Linkヘッダーを利用した TURN 接続のみ
FFmpeg での WHIP 対応¶
FFmpeg の WHIP 対応は仕様がとても古く RFC 9725 に準拠していないため、2025 年 6 月 時点での実装では対応は難しいと考えています。
Sora での利用方法¶
sora.conf にて whip を true に指定してください。
whip = true
Bearer トークンを利用した認証機能を利用する場合¶
sora.conf にて whip_bearer_token_metadata_key を指定してください。
whip_bearer_token_metadata_key = whip_access_token
例えば、 access_token という文字列を指定した場合、
WHIP 接続時、認証ウェブフックに "metadata": {"access_token": "<bearer_token>""} が入ってきます。
whip_token を指定した場合は "metadata": {"whip_token": "<bearer_token>""} が入ってきます。
whip_bearer_token_metadata_key が未指定の場合は、
Bearer トークンが WHIP 接続時に送られてきたとしても Sora は無視して、
metadata も生成しません。
OBS での WHIP 利用方法¶
OBS での利用方法は以下の通りです。
- サービスに WHIP を選ぶ
- サーバーに Sora が提供する WHIP エンドポイント URL を指定する
- デフォルトでは
http://127.0.0.1:5000/whip/<channel_id>
- デフォルトでは
- Bearer トークンには好きな文字列を指定する
- Sora の認証ウェブフックの項目
whip_bearer_token_metadata_keyで指定した値をキーとして、"metadata": {"<whip_bearer_token_metadata_key>": "<bearer_token>""}が認証サーバーに送信されます
- Sora の認証ウェブフックの項目
切断方法¶
Location ヘッダーに入ってくるセッション URL に DELETE リクエストを送ることで切断できます。
OBS は配信終了することで切断リクエストを送りますので、意識する必要はありません。
Sora の OBS (WHIP) の挙動¶
- Sora は WHIP エンドポイント URL を提供します
- デフォルトでは
http://127.0.0.1:5000/whip/<channel_id>です
- デフォルトでは
- Sora の WHIP エンドポイントからの配信は、マルチストリームかつ配信のみ(sendonly)として扱われます
- Sora の WHIP エンドポイントを利用した配信では、シグナリング通知は現時点では利用できません
- Sora の WHIP セッション URL は WHIP エンドポイントのレスポンスに含まれる Location ヘッダーにて払い出されます
WHIP エンドポイント URL¶
Sora の OBS (WHIP) 対応は "role": "sendonly" として機能します。
チャネル ID の指定¶
OBS ではリクエスト時に JSON でチャネル ID を指定することができません。そのため WHIP エンドポイント URL に channel_id を含めて指定します。
channel_id に URL に利用できない文字が含まれている場合は URL エンコードしてください。
HTTP POST https://sora.example.com/whip/<channel_id>
channel_id が sora の WHIP エンドポイント URL 例:
https://sora.example.com/whip/sora
WHIP エンドポイントへの HTTP リクエストに対するレスポンスコードは 201 Created です。
WHIP セッション URL¶
Sora では WHIP セッション URL は WHIP エンドポイントのレスポンスに含まれる Location ヘッダーにて払い出されます。
以下は切断する例です。
HTTP DELETE https://sora.example.com/whip-session/<channel_id>/<secret>
以下は Trickle ICE を利用する例です。
HTTP PATCH https://sora.example.com/whip-session/<channel_id>/<secret>
<secret> は 32 バイトのランダムな値を base32 でエンコードした文字列です。
WHIP セッション URL 例:
https://sora.example.com/whip-session/sora/QBF6AFDWZGWM97BNS5YCBSXM54M01D0TFQ48MC9Z3ZJG8YPRQ1Z0
認証仕様¶
WHIP では認証に Bearer トークンを指定することができます。
OBS でも認証情報に Bearer トークンを指定できます。
Sora は sora.conf で whip_bearer_token_metadata_key に文字列を指定していた場合、
OBS の HTTP POST 時に Authentication ヘッダーで送られてきた Bearer トークンを、
認証ウェブフックの metadata に {"<whip_bearer_token_metadata_key>": "<bearer_token>"} を設定して認証サーバーに送信します。
Sora 自体は Bearer トークンのチェックやデコードなどは行いません。これらは認証ウェブフックのリクエストを受信した認証サーバーが行う必要があります。
ウェブフック仕様¶
whip¶
true が入ってきます。
ignore_disconnect_websocket¶
false が入ってきます。
metadata¶
sora.conf にて whip_bearer_token_metadata_key に指定した文字列をキーとして metadata に入ってきます。
whip_bearer_token_metadata_key = whip_bearer_token
もし文字列を whip_bearer_token にしていた場合は、
"metadata": {"whip_bearer_token": "<bearer-token>"} が送られてきます。
OBS 側に設定した Bearer Token の値がそのまま入ってきます。
role¶
sendonly が入ってきます。
channel_id¶
WHIP エンドポイント URL に渡した値が利用されます。
client_id¶
WHIP エンドポイント URL にクエリ文字列として client_id=<client_id> を指定した場合、その値が利用されます。
bundle_id¶
WHIP エンドポイント URL にクエリ文字列として bundle_id=<bundle_id> を指定した場合、その値が利用されます。
spotlight¶
WHIP エンドポイント URL にクエリ文字列として spotlight=<boolean> を指定した場合、その値が利用されます。
既知の問題として spotlight = true を指定して接続した場合、音声がそのままでは配信されません。 FocusSpotlightFixed API を利用して OBS の接続にフォーカスを当てる必要があります。
詳細は 既知の問題 - OBS 対応機能 を参照してください。
audio / video¶
OBS 側で指定した値を利用します。 OBS では音声は Opus のみ、映像は AV1 と H.264 と H.265 が利用できます。
audio: trueaudio_codec_type: "OPUS"video: truevideo_codec_type: "AV1" | "H264" | "H265"
OBS 利用時にはビットレートの指定できないため、 Sora のデフォルトの値が入ってきますが、 OBS の WHIP 実装では SDP での最大ビットレートを無視します。 そのため OBS 側で設定したビットレートで配信が行われます。
simulcast¶
現時点では false が入ってきます。
sora_client¶
OBS WHIP で User-Agent として送られてくる情報を sora_client に含めています。
"sora_client": {
"raw": "Mozilla/5.0 (OBS-Studio/30.1.0; Mac OS X; ja-JP)",
"type": "OBS-Studio-WHIP",
"version": "30.1.0",
"environment": "Mozilla/5.0 (OBS-Studio/30.1.0; Mac OS X; ja-JP)"
},
その他¶
e2ee: falsespotlight: falsedata_channel_signaling: falseignore_disconnect_webhook: falseturn_transport_type: udp- OBS 30.2 での TURN 対応は TURN-UDP のみのため
tcpになる事はありません
- OBS 30.2 での TURN 対応は TURN-UDP のみのため
認証ウェブフック成功時の払い出し¶
基本的には OBS で指定した値がそのまま利用されますので、 以下の値以外は指定することはお勧めしません。
- client_id
- bundle_id
- event_metadata
- recording_block
- signaling_notify_metadata
- connection_lifetime
- cluster_affinity
- playout_delay_min_delay
- playout_delay_max_delay
- rtp_packet_loss_simulator_incoming
- turn_tcp_only
- ただし 2025 年 6 月 現在では OBS WHIP は TURN-TCP には対応していません
- turn_tls_only
- ただし 2025 年 6 月 現在では OBS WHIP は TURN-TLS には対応していません
クラスター利用時の認証ウェブフックの挙動¶
クラスター利用時に、 WHIP で接続したノードではないノードに接続を振り分ける場合、 Sora は認証情報を担当ノードに Proxy を行います。
接続は接続したノードで行われますが、認証ウェブフックは担当ノードから送信されます。 その後 WebRTC 接続確立は担当ノードと行います。
シーケンス図¶
TURN の利用¶
Sora はデフォルトで WHIP 利用時に Link ヘッダーに TURN URLs を払い出し、 TURN のみの通信 を行います。
TURN の利用を無効にする場合は sora.conf で whip_turn を false でできますが、
この設定は 2025 年 12 月リリース予定の Sora にて廃止されます。
OBS の TURN 機能¶
2024 年 7 月にリリースされた OBS 30.2 で TURN に対応しています。そのため OBS 30.2 より前のバージョンの OBS を利用する場合は sora.conf で whip_turn を false にする必要があります。
ただし OBS で WebRTC を実現している libdatachannel が利用している ICE ライブラリの libjuice は、TURN-UDP のみに対応しています。そのため TURN-TCP や TURN-TLS には対応していません。
録画利用時の注意¶
- OBS WHIP で H.264 を利用している場合、 x264 以外を利用することを推奨します
クラスター利用時の挙動¶
whip_turn を false にした場合の挙動¶
クラスター利用時に接続したノードが指定した channel_id の担当ノードでは無い場合、
担当ノードの IP アドレスを Answer SDP に含めます。
whip_turn を true にした場合の挙動¶
クラスター利用時に、接続したノードが指定した channel_id の担当ノードではない場合、
担当ノードの TURN URLs を Link ヘッダーにて払い出します。
シーケンス図¶
単独¶
クラスターかつロードバランサー¶
クラスターを利用する場合、OBS に設定する WHIP エンドポイントはロードバランサーが提供するエンドポイントをお勧めしています。
このシーケンス図では Sora が 2 ノードになっていますが、最低 3 ノード必要です。