要約

  • RFC 9725の201 Createdは、SDP offerが受理され、answerとセッション資源の場所が返ったことを示す。ICE接続、DTLS完了、SRTPメディア到着の証明ではない。
  • 運用上の「ライブ」は、選択された経路、暗号化された関連、一定時間続くRTP/RTCP、処理出力、CDN配信、プレイヤー側の結果を別々に確認して初めて成立する。
  • DELETEへの応答は終了命令の受領であり、該当するメディア状態と依存資源が実際に解放されたかは、別の照合が必要になる。

最初のフレームはHTTP応答の中にない

配信開始の瞬間、オーケストレーターは成功を表示し、エンコーダーは接続処理を続け、監視用プレイヤーは黒いままということがある。三者は異なる事実を見ている。問題は、そのうち一つだけを全体の状態に採用することである。

RFC 9725は、WebRTC-HTTP Ingestion Protocolを一度のSDP offer/answer交換として定義する。クライアントはapplication/sdpのPOSTをWHIP endpointへ送り、endpointは201 Created、SDP answer、新しいWHIP sessionを指すLocationを返す。RFC Editorの記録とDatatrackerによれば、2025年3月公開のProposed Standardである。調査時点のerrata検索は該当なしだったが、これは実装品質の認定ではない。

RFC 9110のHTTP意味論に照らせば、201は対象資源が作成されたという強い情報である。WHIPでは、初期offerを処理しanswerを作ったことも分かる。しかし、endpointはその応答だけでUDP経路を観測したわけでも、DTLSの完了や映像のデコードを見届けたわけでもない。

ここから、別々の時計が動き始める。資源作成、ICE経路選択、DTLS確立、メディアの継続到着、変換・パッケージング、CDN配信、視聴開始、終了・解放である。時刻と所有者を分けなければ、どの段階で黒画面になったのかを後から復元できない。

制約が明確だからこそ、範囲外も明確になる

WHIPはJSEPの初期offer/answer手順を利用し、取り込み向けに範囲を絞る。クライアントは通常sendonly、サーバーはrecvonlyとし、単一MediaStream、BUNDLE、RTP/RTCP多重化を用いる。初期交換後にメディアセクションを変更する一般的な再ネゴシエーションは行わない。変更可能なのはICE関連情報である。

endpointは、個別のm=セクションだけを拒否した半端な成功を作らず、offer全体を拒否することが推奨される。音声だけ通った状態を完全なライブとして扱う危険を減らすためだ。それでも、全体を受理したという事実は、記述の整合性と現在のポリシーを通過したことに限られる。

セッションの追跡では、イベント名だけに頼れない。初期POST、Locationの資源、ICE generation、DTLS/SRTPの関連、その後の制作・配信オブジェクトを一つの相関IDで結ぶ必要がある。再試行やrestartが入ると、時刻が近いというだけでは別世代のログを誤って連結する。

ICEの204は候補採用票ではない

RFC 8445のICEでは、ローカル候補とリモート候補からpairを作り、STUNで確認し、nominationを経てselected pairを決める。SDPに候補が書かれた時点では、まだ可能性の一覧にすぎない。

Trickle ICEでは、候補収集が終わる前にofferを送れる。空の候補リストさえ許される。クライアントは、201でsession URL、場合によってはETagを得るまで、後から見つかった候補を保持する。その後、RFC 5789のPATCHに、RFC 8840由来のapplication/trickle-ice-sdpfragを載せる。

候補追加PATCHの成功は204 No Contentで返る。しかしRFC 9725は、未対応transportや解決不能なconnection addressの候補を静かに破棄できるとしている。したがって204は、fragment処理の受領証であって、候補ごとの利用可能性や選択結果ではない。

ICE restartでは新しいice-ufrag、ice-pwd、候補をPATCHで交換し、非ICEのSDPは以前のものを引き継ぐ。強いETagがgenerationを区別し、古い条件は412、欠けた条件は428になり得る。新しいETagを伴う200はrestart記述の更新を示すが、新しいpairの接続成功はその後の観測事項である。

鍵ができても、映像はまだ数えられていない

RFC 5764のDTLS-SRTPは、DTLS handshakeからSRTPの鍵材料を得る。RFC 8835はWebRTC transportを、RFC 8834はRTP/RTCPのメディア利用を規定する。DTLS完了は、選択されたtransport上に保護された関連が成立したという証拠である。それ以上でも以下でもない。

カメラ停止、エンコーダー停止、誤ったtrack、codec不整合、送信直後の途絶は、DTLS成功と両立する。そこでメディアの証拠は一定時間の変化を含める。送信側ではpacket、octet、timestamp、SSRC、MID/RIDを追い、受信側ではfirst/last packet、sequence、loss、jitter、bitrate、RTCPまたはtransport feedbackを明示した観測窓で記録する。

RFC 8836が扱う輻輳制御も、取り込み品質の一部である。ある瞬間に高いbitrateが出たことより、共有経路の変化に応じて有用なメディアを保ったかが重要だ。最初の一packetや一回のRTCP reportを、継続サービスの代わりにしてはならない。

CDNへの引き渡しで証拠の話者が変わる

RFC 9725はstreaming serviceまたはCDNへの取り込みを対象にするが、視聴者までの全経路を定義しない。取り込みサーバーがSRTPを受け取っても、decoder、transcoder、packager、origin、cache、request routing、playerのどこかで進行が止まり得る。

RFC 7336のCDNI frameworkは、request routing、metadata、acquisition、distributionを分ける。RFC 7937のlogging interfaceは、ログが生成、集約、フィルタ、収集、修正を経ることを示す。配信ログにも観測者、期間、欠落、加工履歴がある。

引き渡しの原則は単純である。取り込み担当は自分のreceiverで見たpacketを証明する。制作担当はdecode済み入力と更新中のrenditionを証明する。配信担当は新鮮なobject、routing、限られた範囲のrequestを証明する。player probeは特定の地域、端末、回線からstartup、映像・音声の進行、stallを証明する。上流の緑をそのまま受け取るのではなく、各担当が自分の境界で新しい証拠を発行する。

苦情がないことは視聴成功ではない。manifestが新しいことは画面表示ではない。サンプルログにlossがないことは全視聴者の完全配信ではない。見えない範囲も記録の一部にする必要がある。

メディアより先に消費される資源

RFC 9725はHTTP authenticationとbearer token方式の実装を要求する一方、tokenの形式、配布、意味は範囲外とする。POSTが認可されたとしても、任意のイベント、bitrate、地域、時間、費用まで無制限に認められたとは限らない。

しかもサーバーは、メディア到着前から仕事を始める。有効なcredentialを持つクライアントが大量のPOSTを送り、ICE/DTLSを開始しない場合、sessionはtimeoutまで資源を保持する可能性がある。RFCはこれを資源枯渇の攻撃面として扱い、rate limitとavalanche controlを推奨する。PATCH floodingや推測可能なsession URLによるDELETEも別の危険である。

容量は一種類のsession数ではなく、段階別に見るべきだ。作成済み未接続、接続済み未DTLS、暗号済み無メディア、メディア不安定、取り込み済み未配信、配信済み無視聴証拠、終了応答済み未解放を分ける。TURN allocation、DTLS CPU、受信帯域、transcoder slot、packager queue、origin/CDNにも別の上限がある。

初期POSTのload balancingでは307が使われ、301/302は避けられる。過負荷時は503とRetry-Afterがあり得る。PATCHとDELETEはredirect対応が必須ではない。最初のendpoint、redirect chain、最終session authority、実際のmedia serverを保存しなければ、経路変更と責任移転が一致しなくなる。

終了の成否は資源台帳に現れる

クライアントはLocationで得たURLへDELETEを送る。RFC 9725はsession削除、ICE/DTLS終了、media server資源解放を記述する。RFC 7675のconsent freshnessは、正常な終了通知がない場合に一つのfive-tupleへの送信許可が続いているかを確認する仕組みであり、人の同意や配信成功とは別物である。

監査可能な終了では、対象generation、開始者、認可と理由、最後のmedia counter、DTLS closureまたはconsent expiry、TURN・decoder・transcoder・packager・originの返却、短期credentialの失効、manifestの停止を照合する。これは本文が提案する運用統制で、RFCへ新しい規範を足すものではない。

Lu HengのRunning-Code Primacyを当てはめれば、優先すべき現実は資源の表示ではなく、利用者が依存する稼働中のサービスである。最小の初期仕様と将来判断の局所化は、WHIPが共通部分だけを薄く定義し、認可、容量、監視、事故判断を運用者に残す設計と響き合う。現実を製品にするというBTWの考えは、HTTP成功と黒画面の不一致を消さずに残すことを求める。

良い運用は201を過小評価しない。201に、証明していない仕事まで代行させない。

出典

仕様・登録情報：RFC 9725、RFC Editor、Datatracker、errata検索、RFC 8445、RFC 7675、RFC 5764、RFC 8834、RFC 8835、RFC 8836、RFC 8840、RFC 9429、RFC 9110、RFC 5789、RFC 8288、RFC 7336、RFC 7937。

分析枠組み：Running-Code Primacy、Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption、Why BTW.Media Exists — and Why Reality, Not Advocacy, Is the Product。