摘要

  • RFC 9725 的 201 Created 证明摄取端点接受了 SDP offer、生成 answer，并返回 WHIP 会话资源位置；它不证明 ICE 候选连通、DTLS 握手完成或 SRTP 媒体已经抵达。
  • 低延迟直播需要分别保存路径选择、加密关联、RTP/RTCP 持续流量、处理产物、CDN 分发和播放器结果，不能让上游的绿灯替下游作证。
  • DELETE 得到响应只是控制面收据；关闭验收还要证明正确会话的媒体状态、临时权限和各类容量已经释放。

三个“成功”并不是同一件事

直播开始前，接口团队看到 201，网络团队还在等待候选对选定，制作团队的波形图仍是一条直线。把这三种状态压成一个“上线成功”，故障就会在最需要解释时失去来路。

RFC 9725 为 WebRTC 摄取规定了一次性的 HTTP offer/answer。编码器以 application/sdp 向 WHIP endpoint 发出 POST；端点返回 201 Created、SDP answer，以及指向新会话资源的 Location。RFC Editor 条目和 IETF Datatracker显示它在 2025 年 3 月以 Proposed Standard 发布。研究冻结时，RFC 9725 errata 检索没有结果；这只描述数据库状态，不能替任何实现背书。

按照 HTTP 语义，201 对“创建了目标资源”有清晰意义。放到 WHIP 中，它还说明端点处理了初始描述并给出回答。它没有观察到随后发生的 STUN connectivity check、DTLS Finished、RTP 序列推进，更没有看到观众屏幕。

因此，状态模型至少要保留七个节点：HTTP 准入、ICE 选路、DTLS 建联、稳定媒体入流、制作链产出、分发可用、完整终止。任何节点都可以独立失败，也可以在相邻节点绿灯时失败。

协议刻意没有包办后面的决定

WHIP 沿用 JSEP 的初始 offer/answer 规则，同时把范围压到单向摄取：客户端通常声明 sendonly，服务端回答 recvonly；只有一个 MediaStream，媒体使用 BUNDLE，RTP/RTCP 复用。初始交换以后，普通的媒体段重新协商不在协议内，只有 ICE 信息可以通过 PATCH 演进。

这种“薄”不是缺陷，而是边界。RFC 还建议整单拒绝无法处理的 offer，不要留下音频成功、视频失败之类容易误导的半成品会话。但整单通过依旧只说明描述被接受。编码器可能没有可用路径，媒体可能几秒后才出现，也可能出现后立即停住。

一次直播至少应关联五类身份：业务事件、初始 POST、Location 资源、ICE generation、DTLS/SRTP 关联及其后续制作对象。只靠标题和时间戳拼接，在重试或 ICE restart 后很容易把不同代的证据混在一起。

候选地址只是待检验的提案

RFC 8445 中，ICE 把本地与远端 candidate 组成 pair，执行检查，完成 nomination，最后选出真正承载数据的 selected pair。SDP 里出现地址，不能证明该地址从编码器所在网络可达。

Trickle ICE 把这一点表现得更明显。客户端可以在候选尚未收集完时发送 offer，甚至使用空列表。201 到达前，新候选必须暂存，因为客户端尚不知道会话 URL，有时也尚不知道对应 generation 的 ETag。随后，客户端用 RFC 5789 的 PATCH，承载来自 RFC 8840 的 application/trickle-ice-sdpfrag。

这里有一个容易被统计系统误读的规定：增加 candidate 的 PATCH 成功时返回 204 No Content，但如果某个 candidate transport 不受支持，或 connection address 无法解析，WHIP session 可以静默丢弃它并继续处理其余内容。所以 204 证明服务器处理了这次更新，不证明每一个候选进入 checklist，更不证明其中任何一个被选中。

ICE restart 又开辟了新的 generation。WHIP 用 PATCH 交换新的 ice-ufrag、ice-pwd 和候选，非 ICE 的 SDP 继续沿用。强 ETag 防止交叉到达的请求错误覆盖当前代；412 或 428 暴露一部分前置条件错误。即使 restart 返回 200 和新 ETag，新的连通检查仍未由这个 HTTP 响应证明。

握手完成和节目抵达之间还有距离

DTLS-SRTP 利用 DTLS 握手生成 SRTP 密钥材料。WebRTC transport 与 RTP media 规范把安全传输、RTCP feedback 和媒体行为连接起来。握手完成是一张重要收据：指定传输上形成了受保护的关联。它仍然没有证明摄像机、编码器或实际节目在工作。

媒体证据必须同时有方向、对象和时间窗口。发送端记录 packet/octet/timestamp 是否推进，SSRC 与 MID/RID 是否对应预期轨道；接收端记录 first/last packet、sequence continuity、loss、jitter、bitrate，以及 RTCP 或其他 transport feedback。一个首包只能证明“至少看到一次”；某一秒的码率不能说明五分钟后还在流动。

RFC 8836 的实时媒体拥塞控制要求又增加一层责任：媒体不是只要发得出去就算成功，还要对共享路径的容量变化作出反应。入流绿色但持续挤压拥塞路径，既不稳定，也可能伤害同路流量。

过了摄取点，责任主体已经变了

RFC 9725 的目标是把内容摄取进 streaming service 或 CDN，它没有规范从媒体服务器到每一位观众的完整交付。SRTP 可以稳定到达，而 decoder 没有接受输入；decoder 正常而 transcoder 没有 slot；rendition 正常而 manifest 不再更新；origin 正常而 cache、路由或播放器失败。

RFC 7336 的 CDNI framework 把 request routing、metadata、acquisition 与 distribution 分开。RFC 7937 还显示，下游 CDN 日志会经历生成、聚合、过滤、收集和校正。所谓“交付日志”也有来源、延迟和覆盖范围，并不是天然完整的观众证明。

可审计的交接应当逐段换人作证：摄取团队只证明接收器看到什么；制作团队证明哪些输入被解码、哪些 rendition 持续推进；分发团队证明哪些对象和请求在什么范围内被观察；播放器探针证明从特定地区、设备和网络能否启动、持续出画出声、是否卡顿。

如果这些证据冲突，冲突本身就是事实。没有投诉不等于收到节目；没有 loss 告警不等于零丢包；manifest 新鲜不等于视频已呈现在屏幕上。

控制面先花钱，媒体可能永远不来

RFC 9725 要求各方支持 HTTP authentication 和 bearer token 机制，但 token 的形态、分发和具体语义不在 RFC 内。某个 token 能创建会话，不代表它自动拥有任意活动、码率、地区、时长或预算。

服务器在媒体到来前已经承担成本。持有有效凭据的客户端可以连续 POST，迫使系统解析 SDP、分配会话并等待从未开始的 ICE/DTLS 超时。RFC 明确把这种情况列为资源耗尽风险，建议对 POST 做 rate limit 与 avalanche control；PATCH flooding 和可猜测的 session URL 也分别可能消耗资源或被用于恶意 DELETE。

容量账因此不能只按“总会话数”记。应分别看：created 未 connected、connected 未 DTLS-ready、secure 未 media、media 不稳定、ingest ready 未 distribution ready、distributed 无 viewer receipt、deleted/expired 但资源未下降。每一组的存量和年龄，才揭示真正的瓶颈。

初始 POST 可以用 307 做负载均衡，以保留方法和请求体；过载时可用 503 和 Retry-After。PATCH 与 DELETE 不要求支持重定向。审计记录要保存初始 endpoint、redirect chain、最终 session authority 与实际 media server，否则路由把流量交给了新人，责任记录却仍指向旧人。

DELETE 后还需要做一次对账

客户端向 Location 给出的会话资源发送 DELETE。RFC 9725 描述的结果包括删除 WHIP session、终止 ICE/DTLS、释放 media server 资源。RFC 7675 的 consent freshness 另行处理非优雅断线：它维持的是某个 five-tuple 上远端继续收流的技术许可，不是人的授权，也不证明节目有用。

真正的关闭凭据还要回答：opaque URL 对应哪一代会话；谁以什么理由终止；入流计数何时停止；DTLS 是关闭还是 consent 到期；TURN allocation、decoder、transcoder、packager、origin reservation 是否逐项归还；临时凭据是否过期；最后一个 manifest 是否仍冒充 live。以上是本文提出的运营控制，不是新增 RFC 义务。

Lu Heng 的 Running-Code Primacy 在这里给出判断顺序：真正重要的是正在运行、被客户使用的流，而不是行政状态看起来完成。他提出的最小初始规范、未来决定本地化与自愿采用说明，共同协议应该只承担必要的互操作，授权、容量、监测和事故权力由各运营者明确承担。BTW 记录现实而非倡议则要求留下不一致：HTTP 绿而媒体空，摄取绿而观众失败，DELETE 已回而容量仍被占用。

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。