WebRTC-HTTP 出口协议 (WHEP)
工作组: Network Working Group
互联网草案: draft-murillo-whep-01
发布日期: 2022年10月19日
预期状态: 信息性
过期日期: 2023年4月22日
作者:
- S. Murillo
Millicast - C. Chen
ByteDance
摘要
本文档描述了一种简单的基于 HTTP 的协议,该协议将允许基于 WebRTC 的观看者从流媒体服务和/或内容分发网络(CDN)或 WebRTC 传输网络(WTN)观看内容。
本备忘录的状态
本互联网草案完全符合 BCP 78 和 BCP 79 的规定提交。
互联网草案是互联网工程任务组(IETF)的工作文档。请注意,其他组织也可能分发作为互联网草案的工作文档。当前互联网草案的列表位于 https://datatracker.ietf.org/drafts/current/。
互联网草案是有效期最长为六个月的草案文档,可能随时被其他文档更新、替换或废弃。将互联网草案用作参考材料或引用它们(除了"进行中的工作"之外)是不合适的。
本互联网草案将于 2023 年 4 月 22 日过期。
版权声明
版权所有 © 2022 IETF Trust 和确定为文档作者的人员。保留所有权利。
本文档受 BCP 78 和 IETF Trust 关于 IETF 文档的法律规定(https://trustee.ietf.org/license-info)的约束,这些规定在本文档发布之日生效。请仔细审阅这些文档,因为它们描述了您对本文档的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中描述的修订版 BSD 许可证文本,并且按照修订版 BSD 许可证中的描述不提供任何担保。
目录
- 引言
- 术语
- 概述
- 协议操作
4.1. WHEP 播放器生成的 SDP offer
4.2. WHEP 端点生成的 SDP offer
4.3. 通用程序
4.4. ICE 和 NAT 支持
4.5. WebRTC 约束
4.6. 负载均衡和重定向
4.7. STUN/TURN 服务器配置
4.8. 身份验证和授权
4.9. 协议扩展 - 安全考虑
- IANA 考虑事项
6.1. WHEP URN 子命名空间和 whep 注册表的注册
6.2. whep 的 URN 子命名空间
6.2.1. 规范模板 - 致谢
- 参考文献
8.1. 规范性参考文献
8.2. 信息性参考文献
作者地址
1. 引言
IETF RTCWEB 工作组标准化了 JSEP([RFC8829]),这是一种用于控制多媒体会话的设置、管理和拆除的机制。它还描述了如何使用会话描述协议(SDP)[RFC3264] 的 Offer/Answer 模型来协商媒体流,以及通过线路发送的数据格式(例如,媒体类型、编解码器参数和加密)。WebRTC 有意不在应用层指定信令传输协议。这种灵活性允许实现广泛的服务。然而,这些服务通常是独立的孤岛,不需要与其他服务互操作或利用可以与它们通信的工具的存在。
虽然有一些可以与 WebRTC 集成的标准信令协议可用,如 SIP [RFC3261] 或 XMPP [RFC6120],但它们并非设计用于广播/流媒体服务,并且在该行业也没有采用迹象。基于 RTP 的 RTSP [RFC7826] 在功能方面可能与 WebRTC 最接近,但与 SDP offer/answer 模型 [RFC3264] 不兼容。
因此,目前没有设计用于使用 WebRTC 从流媒体服务消费媒体的标准协议。
缺乏使用 WebRTC 从流媒体服务消费媒体的标准协议在许多情况下已成为问题:
- WebRTC 服务和产品之间的互操作性。
- 重用可以轻松集成的播放器软件。
- 与动态自适应 HTTP 流(DASH)集成,通过 WebRTC 提供直播流,同时通过 DASH 提供时移版本。
- 在不支持运行自定义 javascript 的设备(如电视)上播放 WebRTC 流。
本文档模仿了 WebRTC HTTP 摄取协议(WHIP)[I-D.draft-ietf-wish-whip] 为摄取所做的工作,并指定了一种简单的基于 HTTP 的协议,可用于使用 WebRTC 从流媒体服务消费媒体。
2. 术语
本文档中的关键词"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"和"OPTIONAL"应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释,当且仅当它们以全大写形式出现时,如此处所示。
WHEP 播放器: 作为 WHEP 协议客户端的 WebRTC 媒体播放器,通过从远程媒体服务器接收和解码媒体来工作。
WHEP 端点: 接收初始 WHEP 请求的出口服务器。
WHEP 端点 URL: 将创建 WHEP 资源的 WHEP 端点的 URL。
媒体服务器: 与 WHEP 播放器建立媒体会话并向其传递媒体的 WebRTC 媒体服务器或消费者。
WHEP 资源: WHEP 端点为正在进行的出口会话分配的资源,WHEP 播放器可以发送请求以更改会话(例如,ICE 操作或终止)。
WHEP 资源 URL: WHEP 端点分配给特定媒体会话的 URL,可用于执行诸如终止会话或 ICE 重启等操作。
3. 概述
WebRTC-HTTP 出口协议(WHEP)使用 HTTP POST 请求执行单次 SDP offer/answer,以便可以在 WHEP 播放器和流媒体服务端点(媒体服务器)之间建立 ICE/DTLS 会话。
一旦 ICE/DTLS 会话建立,媒体将从媒体服务器单向流向 WHEP 播放器。为了降低复杂性,不支持 SDP 重新协商,因此一旦通过 HTTP 完成的初始 SDP offer/answer 完成,就无法添加或删除轨道或流。
+-------------+ +---------------+ +--------------+ +---------------+
| WHEP Player | | WHEP Endpoint | | Media Server | | WHEP Resource |
+--+----------+ +---------+-----+ +------+-------+ +--------|------+
| | | |
| | | |
|HTTP POST (SDP Offer) | | |
+------------------------>+ | |
|201 Created (SDP answer) | | |
+<------------------------+ | |
| ICE REQUEST | |
+--------------------------------------->+ |
| ICE RESPONSE | |
|<---------------------------------------+ |
| DTLS SETUP | |
|<======================================>| |
| RTP/RTCP FLOW | |
+<-------------------------------------->+ |
| HTTP DELETE |
+---------------------------------------------------------->+
| 200 OK |
<-----------------------------------------------------------x
图 1:WHEP 会话设置和拆除
或者,在某些情况下,WHEP 播放器可能希望服务提供 SDP offer(例如,为了避免在仅支持音频时设置音频和视频会话),因此在这种情况下,初始 HTTP POST 请求将不包含正文,响应将包含来自服务的 SDP offer。WHEP 播放器将必须在后续的 HTTP PATCH 请求中向 WHEP 资源提供 SDP answer。
+-------------+ +---------------+ +--------------+ +---------------+
| WHEP Player | | WHEP Endpoint | | Media Server | | WHEP Resource |
+--+----------+ +---------+-----+ +------+-------+ +--------|------+
| | | |
| | | |
|HTTP POST (empty) | | |
+------------------------>+ | |
|201 Created (SDP offer) | | |
+<------------------------+ | |
| HTTP PATCH (SDP answer) | |
+---------------------------------------------------------->+
| 200 OK | |
<-----------------------------------------------------------x
| ICE REQUEST | |
+--------------------------------------->+ |
| ICE RESPONSE | |
|<---------------------------------------+ |
| DTLS SETUP | |
|<======================================>| |
| RTP/RTCP FLOW | |
+<-------------------------------------->+ |
| HTTP DELETE |
+---------------------------------------------------------->+
| 200 OK |
<-----------------------------------------------------------x
图 2:WHEP 会话设置和拆除
4. 协议操作
4.1. WHEP 播放器生成的 SDP offer
为了设置流媒体会话,WHEP 播放器将根据 JSEP 规则生成 SDP offer,并向配置的 WHEP 端点 URL 执行 HTTP POST 请求。
HTTP POST 请求的内容类型为"application/sdp",并将 SDP offer 作为正文。WHEP 端点将生成 SDP answer 并返回"201 Created"响应,内容类型为"application/sdp",SDP answer 作为正文,以及指向新创建资源的 Location 头字段。
SDP offer 应使用"recvonly"属性,SDP answer 必须使用"sendonly"属性。
POST /whep/endpoint HTTP/1.1
Host: whep.example.com
Content-Type: application/sdp
Content-Length: 1326
v=0
o=- 5228595038118931041 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:zjkk
a=ice-pwd:bP+XJMM09aR8AiX1jdukzR6Y
a=ice-options:trickle
a=fingerprint:sha-256 DA:7B:57:DC:28:CE:04:4F:31:79:85:C4:31:67:EB:27:58:29:ED:77:2A:0D:24:AE:ED:AD:30:BC:BD:F1:9C:02
a=setup:actpass
a=mid:0
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
m=video 9 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:zjkk
a=ice-pwd:bP+XJMM09aR8AiX1jdukzR6Y
a=ice-options:trickle
a=fingerprint:sha-256 DA:7B:57:DC:28:CE:04:4F:31:79:85:C4:31:67:EB:27:58:29:ED:77:2A:0D:24:AE:ED:AD:30:BC:BD:F1:9C:02
a=setup:actpass
a=mid:1
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
HTTP/1.1 201 Created
ETag: "xyzzy"
Content-Type: application/sdp
Accept-Patch: application/trickle-ice-sdpfrag
Content-Length: 1400
Location: https://whep.example.org/resource/id
v=0
o=- 1657793490019 1 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=ice-lite
a=msid-semantic: WMS *
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:526be20a538ee422
a=ice-pwd:2e13dde17c1cb009202f627fab90cbec358d766d049c9697
a=fingerprint:sha-256 F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3:8A:35:DA:70:86:4F:46:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD
a=candidate:1 1 UDP 2130706431 198.51.100.1 39132 typ host
a=setup:passive
a=mid:0
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=msid:- d46fb922-d52a-4e9c-aa87-444eadc1521b
m=video 9 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:526be20a538ee422
a=ice-pwd:2e13dde17c1cb009202f627fab90cbec358d766d049c9697
a=fingerprint:sha-256 F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3:8A:35:DA:70:86:4F:46:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD
a=candidate:1 1 UDP 2130706431 198.51.100.1 39132 typ host
a=setup:passive
a=mid:1
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=msid:- d46fb922-d52a-4e9c-aa87-444eadc1521b
图 3:执行 SDP O/A 的 HTTP POST 和 PATCH 示例
4.2. WHEP 端点生成的 SDP offer
如果 WHEP 播放器希望 WHEP 端点生成 SDP offer,WHEP 播放器将向配置的 WHEP 端点 URL 发送不带 HTTP BODY 的 POST 请求和"application/sdp"的 Accept HTTP 头。
WHEP 端点将根据 JSEP 规则生成 SDP offer,并返回"201 Created"响应,内容类型为"application/sdp",SDP offer 作为正文,指向新创建资源的 Location 头字段,以及指示 WHEP 播放器允许向 WHEP 资源发送 SDP answer 的最大时间的 Expire 头。
WHEP 播放器必须生成对 WHEP 端点提供的 SDP offer 的 SDP answer,并向 Location 头中为 WHEP 资源提供的 URL 发送 HTTP PATCH 请求。HTTP PATCH 请求的内容类型为"application/sdp",并将 SDP answer 作为正文。如果 WHEP 播放器不接受 SDP offer,它必须执行 HTTP DELETE 操作以终止到 WHEP 资源 URL 的会话。
在这种情况下,SDP offer 应使用"sendonly"属性,SDP answer 必须使用"recvonly"属性。
POST /whep/endpoint HTTP/1.1
Host: whep.example.com
Content-Length: 0
Accept: application/sdp
HTTP/1.1 201 Created
Content-Type: application/sdp
Content-Length: 1400
Location: https://whep.example.com/resource/id
Expires: Wed, 27 Jul 2022 07:28:00 GMT
v=0
o=- 5228595038118931041 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:zjkk
a=ice-pwd:bP+XJMM09aR8AiX1jdukzR6Y
a=ice-options:trickle
a=fingerprint:sha-256 DA:7B:57:DC:28:CE:04:4F:31:79:85:C4:31:67:EB:27:58:29:ED:77:2A:0D:24:AE:ED:AD:30:BC:BD:F1:9C:02
a=setup:actpass
a=mid:0
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendonly
a=msid:- d46fb922-d52a-4e9c-aa87-444eadc1521b
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
m=video 9 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:zjkk
a=ice-pwd:bP+XJMM09aR8AiX1jdukzR6Y
a=ice-options:trickle
a=fingerprint:sha-256 DA:7B:57:DC:28:CE:04:4F:31:79:85:C4:31:67:EB:27:58:29:ED:77:2A:0D:24:AE:ED:AD:30:BC:BD:F1:9C:02
a=setup:actpass
a=mid:1
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendonly
a=msid:- d46fb922-d52a-4e9c-aa87-444eadc1521b
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
PATCH /resource/id HTTP/1.1
Host: whep.example.com
Content-Type: application/sdp
Content-Length: 1326
v=0
o=- 1657793490019 1 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=ice-lite
a=msid-semantic: WMS *
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:526be20a538ee422
a=ice-pwd:2e13dde17c1cb009202f627fab90cbec358d766d049c9697
a=fingerprint:sha-256 F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3:8A:35:DA:70:86:4F:46:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD
a=candidate:1 1 UDP 2130706431 198.51.100.1 39132 typ host
a=setup:passive
a=mid:0
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
m=video 9 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:526be20a538ee422
a=ice-pwd:2e13dde17c1cb009202f627fab90cbec358d766d049c9697
a=fingerprint:sha-256 F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3:8A:35:DA:70:86:4F:46:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD
a=candidate:1 1 UDP 2130706431 198.51.100.1 39132 typ host
a=setup:passive
a=mid:1
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
HTTP/1.1 204 No Content
ETag: "xyzzy"
图 4:执行 SDP O/A 的 HTTP POST 和 PATCH 示例
如果 WHEP 资源在 HTTP POST 响应的 Expire 头指示的时间之前未收到 HTTP PATCH 请求,它应删除资源并对之后收到的 WHEP 资源 URL 上的任何请求响应 404 Not Found。
4.3. 通用程序
WHEP 资源可能要求正在进行的发布才能允许 WHEP 播放器开始观看流。在这种情况下,WHEP 资源应向 WHEP 客户端发出的 POST 请求返回"409 Conflict"响应,并带有 Retry-After 头,指示在发送新请求之前等待的秒数。WHEP 播放器可以定期尝试连接到 WHEP 资源,使用指数退避周期,初始值为"409 Conflict"响应中 Retry-After 头的值。
一旦会话建立,ICE 同意新鲜度 [RFC7675] 将用于检测突然断开连接和 DTLS 拆除以终止会话(由任一方)。
要显式终止会话,WHEP 播放器必须向初始 HTTP POST 的 Location 头字段中返回的资源 URL 执行 HTTP DELETE 请求。收到 HTTP DELETE 请求后,WHEP 资源将被删除,媒体服务器上的资源将被释放,终止 ICE 和 DTLS 会话。
终止会话的媒体服务器必须遵循 [RFC7675] 第 5.2 节中关于立即撤销同意的程序。
WHEP 端点必须对端点 URL 上的任何 HTTP GET、HEAD 或 PUT 请求返回"405 Method Not Allowed"响应,以便为本文档协议规范的未来版本保留其使用。
WHIP 端点必须支持跨源资源共享(CORS)的 OPTIONS 请求,如 [FETCH] 中定义,并且它应在根据 [W3C.REC-ldp-20150226] 收到的任何 OPTIONS 请求的"200 OK"响应中包含"Accept-Post"头,其 mime 类型值为"application/sdp"。
WHEP 资源必须对资源 URL 上的任何 HTTP GET、HEAD、POST 或 PUT 请求返回"405 Method Not Allowed",以便为本文档协议规范的未来版本保留其使用。
4.4. ICE 和 NAT 支持
WHEP 播放器提供的 SDP 可以在完整 ICE 收集完成后发送,包含完整的 ICE 候选列表,或者根据 [RFC8863],它可能只包含本地候选(甚至候选列表为空)。
为了简化协议,一旦发送 SDP answer,就不支持交换从媒体服务器 ICE 候选收集的 trickle 候选。WHEP 端点应在响应客户端请求之前收集媒体服务器的所有 ICE 候选,SDP answer 应包含媒体服务器的完整 ICE 候选列表。媒体服务器可以使用 ICE lite,而 WHEP 播放器必须实现完整 ICE。
Trickle ICE 和 ICE 重启支持对于 WHEP 资源是可选的。
如果 WHEP 资源支持 Trickle ICE 或 ICE 重启,WHEP 播放器必须在创建 WHEP 资源的 POST 请求的"201 Created"中包含"Accept-Patch"头,其 mime 类型值为"application/trickle-ice-sdpfrag",如 [RFC5789] 第 3.1 节所述。
如果 WHEP 资源支持 Trickle ICE 或 ICE 重启之一,但不支持两者,它必须对不支持的 HTTP PATCH 请求返回"405 Not Implemented"响应。
如果 WHEP 资源不支持用于任何目的的 PATCH 方法,它必须返回"501 Not Implemented"响应,如 [RFC9110] 第 6.6.2 节所述。
由于 WHEP 播放器发送的 HTTP PATCH 请求可能被 WHEP 资源乱序接收,WHEP 资源必须根据 [RFC9110] 第 2.3 节生成唯一强实体标签以标识 ICE 会话。标识初始 ICE 会话的实体标签的初始值必须在初始 POST 请求到 WHEP 端点的"201 Created"响应中的 ETag 头字段中返回(如果 WHEP 播放器充当 SDP offerer),或者在包含 SDP answer 的 HTTP PATCH 响应中返回。它还必须在触发 ICE 重启的任何 PATCH 请求的"200 OK"中返回。请注意,仅在 WHEP 资源支持 ICE 重启时才需要在原始"201 Created"响应中包含 ETag,否则是可选的。
执行 trickle ICE 的 WHEP 播放器发送 PATCH 请求时,必须根据 [RFC9110] 第 3.1 节包含"If-Match"头字段,其值为最新已知的实体标签。当 WHEP 资源收到 PATCH 请求时,它必须根据 [RFC9110] 第 3.1 节将指示的实体标签值与资源的当前实体标签进行比较,如果不匹配,则返回"412 Precondition Failed"响应。
WHEP 播放器在不需要匹配特定 ICE 会话时(例如在发起 DELETE 请求以终止会话时)不应使用实体标签验证。
接收包含新 ICE 候选但不执行 ICE 重启的 PATCH 请求的 WHEP 资源必须返回不带正文的"204 No Content"响应。如果媒体服务器不支持候选传输或无法解析连接地址,它必须接受带有 204 响应的 HTTP 请求并静默丢弃候选。
PATCH /resource/id HTTP/1.1
Host: whep.example.com
If-Match: "38sdf4fdsf54:EsAw"
Content-Type: application/trickle-ice-sdpfrag
Content-Length: 548
a=ice-ufrag:EsAw
a=ice-pwd:P2uYro0UCOQ4zxjKXaWCBui1
m=audio RTP/AVP 0
a=mid:0
a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host generation 0 ufrag EsAw network-id 1
a=candidate:3471623853 1 udp 2122194687 198.51.100.1 61765 typ host generation 0 ufrag EsAw network-id 2
a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype active generation 0 ufrag EsAw network-id 1
a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host tcptype active generation 0 ufrag EsAw network-id 2
a=end-of-candidates
HTTP/1.1 204 No Content
图 5:Trickle ICE 请求
执行 ICE 重启的 WHEP 播放器发送 PATCH 请求时,必须根据 [RFC9110] 第 3.1 节包含"If-Match"头字段,其字段值为"*"。
如果 HTTP PATCH 请求导致 ICE 重启,WHEP 资源应返回"200 OK",其"application/trickle-ice-sdpfrag"正文包含新的 ICE 用户名片段和密码。响应可以可选地包含媒体服务器的新 ICE 候选集和 ETag 响应头字段中对应于新 ICE 会话的新实体标签。
如果 WHEP 资源无法满足 ICE 请求,WHEP 资源应返回"200 OK",其"application/trickle-ice-sdpfrag"正文包含新的 ICE 用户名片段和密码。此外,成功 ICE 重启的"200 OK"响应必须包含 ETag 响应头字段中对应于新 ICE 会话的新实体标签,并且可以包含媒体服务器的新 ICE 候选集。
PATCH /resource/id HTTP/1.1
Host: whep.example.com
If-Match: "*"
Content-Type: application/trickle-ice-sdpfrag
Content-Length: 54
a=ice-ufrag:ysXw
a=ice-pwd:vw5LmwG4y/e6dPP/zAP9Gp5k
HTTP/1.1 200 OK
ETag: "289b31b754eaa438:ysXw"
Content-Type: application/trickle-ice-sdpfrag
Content-Length: 102
a=ice-lite
a=ice-ufrag:289b31b754eaa438
a=ice-pwd:0b66f472495ef0ccac7bda653ab6be49ea13114472a5d10a
图 6:ICE 重启请求
由于 WHEP 播放器需要知道与 ICE 会话关联的实体标签才能发送新的 ICE 候选,它必须在收到初始 POST 请求或带有新实体标签值的 PATCH 请求的 HTTP 响应之前缓冲任何收集的候选。一旦它知道实体标签值,WHEP 播放器应发送单个聚合的 HTTP PATCH 请求,其中包含它到目前为止缓冲的所有 ICE 候选。
在不稳定的网络条件下,ICE 重启 HTTP PATCH 请求和响应可能会乱序接收。为了缓解这种情况,当客户端执行 ICE 重启时,它必须丢弃任何先前的 ice 用户名/密码片段,并忽略从待处理的 HTTP PATCH 请求收到的任何进一步的 HTTP PATCH 响应。客户端必须仅应用在最后一个发送请求的响应中收到的 ICE 信息。如果客户端和服务器之间的 ICE 信息不匹配(由于乱序请求),STUN 请求将包含无效的 ICE 信息并被服务器拒绝。当 WHEP 播放器检测到这种情况时,它应向服务器发送新的 ICE 重启请求。
4.5. WebRTC 约束
在从流媒体服务消费媒体的特定情况下,可以对服务器端做出一些假设,这简化了 WebRTC 合规性负担,如 WebRTC 网关文档 [I-D.draft-ietf-rtcweb-gateways] 中详述。
为了降低在播放器和媒体服务器中实现 WHEP 的复杂性,WHEP 对 WebRTC 使用施加了以下限制:
WHEP 播放器和 WHEP 端点都应使用 SDP bundle [RFC9143]。每个"m="部分必须是单个 BUNDLE 组的一部分。因此,当 WHEP 播放器或 WHEP 端点发送 SDP offer 时,它必须在每个捆绑的"m="部分中包含"bundle-only"属性。根据 [RFC9143] 第 9 节,WHEP 播放器和媒体服务器必须支持与 BUNDLE 组关联的多路复用媒体。此外,根据 [RFC8858],WHEP 播放器和媒体服务器应在每个捆绑的"m="部分中包含"rtcp-mux-only"属性。
由于媒体服务器在 WHEP 播放器开始观看流时可能不知道给定流的编解码器,如果 WHEP 端点充当 SDP answerer,它必须在 SDP answer 中包含它支持的所有提供的编解码器,并且不对将实际发送的编解码器做出任何假设。
如第 4.1 节所述,Trickle ICE 和 ICE 重启支持对于 WHEP 播放器和媒体服务器都是可选的。
4.6. 负载均衡和重定向
WHEP 端点和媒体服务器可能不位于同一服务器上,因此可以将传入请求负载均衡到不同的媒体服务器。WHEP 播放器应支持通过"307 Temporary Redirect"响应进行 HTTP 重定向,如 [RFC9110] 第 6.4.7 节所述。WHEP 资源 URL 必须是最终 URL,不需要支持发送到它的 PATCH 和 DELETE 请求的重定向。
在高负载情况下,WHEP 端点可能返回"503 Service Unavailable"响应,指示服务器由于临时过载或计划维护而当前无法处理请求,这可能在延迟后得到缓解。WHEP 端点可能发送 Retry-After 头字段,指示用户代理在进行后续请求之前应等待的最短时间。
4.7. STUN/TURN 服务器配置
WHEP 端点可以在对 WHEP 端点 URL 的 HTTP POST 请求的"201 Created"响应中返回客户端可用的 STUN/TURN 服务器配置 URL 和凭据。
每个 STUN/TURN 服务器将使用"Link"头字段 [RFC8288] 返回,其"rel"属性值为"ice-server",如 [I-D.draft-ietf-wish-whip] 中指定。
也可以在 WHEP 播放器上配置由广播服务或外部 TURN 提供商提供的长期凭据的 STUN/TURN 服务器 URL,覆盖 WHEP 端点提供的值。
4.8. 身份验证和授权
WHEP 端点和资源可能要求使用 HTTP Authorization 头字段和 Bearer 令牌对 HTTP 请求进行身份验证,如 [RFC6750] 第 2.1 节中指定。WHEP 播放器必须实现此身份验证和授权机制,并在发送到 WHEP 端点或资源的所有 HTTP 请求中发送 HTTP Authorization 头字段,但用于 CORS 的预检 OPTIONS 请求除外。
Bearer 令牌的性质、语法和语义,以及如何将其分发给客户端,不在本文档的范围内。可以使用的令牌类型的示例包括但不限于根据 [RFC6750] 和 [RFC8725] 的 JWT 令牌或存储在数据库中的共享密钥。
WHEP 端点和资源可以通过在 WHEP 端点或资源的 URL 内编码身份验证令牌来执行身份验证和授权。如果 WHEP 播放器未配置为使用 bearer 令牌,则不得在任何请求中发送 HTTP Authorization 头字段。
4.9. 协议扩展
为了支持为 WHEP 协议定义的未来扩展,定义了注册和宣布新扩展的通用程序。
WHEP 服务器支持的协议扩展必须在发送到 WHEP 端点的初始 HTTP POST 请求的"201 Created"响应中向 WHEP 播放器公布。WHEP 端点必须为每个扩展返回一个"Link"头字段,其中包含扩展"rel"类型属性和将可用于接收与该扩展相关的请求的 HTTP 资源的 URI。
协议扩展对于 WHEP 播放器和 WHEP 端点和资源都是可选的。WHEP 播放器必须忽略任何具有未知"rel"属性值的 Link 属性,WHEP 端点和资源不得要求使用任何扩展。
每个协议扩展必须在 IANA 注册唯一的"rel"属性值,以前缀开头:"urn:ietf:params:whep:ext",如第 6.2 节中指定。
例如,考虑使用服务器发送事件的服务器到客户端通信的潜在扩展,如 https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events 中指定,用于连接到已发布流的服务器端事件资源的 URL 可以在初始 HTTP"201 Created"响应中使用"Link"头字段和"urn:ietf:params:whep:ext:example:server-sent-events"的"rel"属性返回。(本文档不指定这样的扩展,仅将其用作示例。)
在这种理论情况下,对 HTTP POST 请求的"201 Created"响应将如下所示:
HTTP/1.1 201 Created
Content-Type: application/sdp
Location: https://whep.example.org/resource/id
Link: <https://whep.ietf.org/publications/213786HF/sse>;
rel="urn:ietf:params:whep:ext:example:server-side-events"
5. 安全考虑
应使用 HTTPS 以保持 WebRTC 安全模型。
6. IANA 考虑事项
本规范为 WHEP 协议扩展添加了 URN 子命名空间的注册表。
6.1. WHEP URN 子命名空间和 whep 注册表的注册
IANA 已向"IETF URN 子命名空间用于已注册协议参数标识符"注册表添加条目,并根据 [RFC3553] 为已注册参数标识符创建子命名空间:"urn:ietf:params:whep"。
为了管理此子命名空间,IANA 已创建"跨域身份管理系统(WHEP)模式 URI"注册表,用于管理"urn:ietf:params:whep"命名空间内的条目。注册表描述如下:
注册表名称: WHEP
规范: 本文档(RFC TBD)
存储库: 参见第 6.2 节
索引值: 参见第 6.2 节
6.2. whep 的 URN 子命名空间
whep 端点利用 URI 来标识 Link 头的"rel"属性上支持的 whep 协议扩展,如第 4.9 节中定义。本节创建并注册一个 IETF URN 子命名空间,用于 whep 规范和未来扩展。
6.2.1. 规范模板
命名空间 ID:
已分配命名空间 ID "whep"。
注册信息:
- 版本:1
- 日期:TBD
命名空间的声明注册人:
互联网工程任务组。
指定联系人:
指定专家将监控 whep 公共邮件列表,"wish@ietf.org"。
语法结构声明:
使用"whep"命名空间 ID 的所有 URN 的命名空间特定字符串(NSS)应具有以下结构:urn:ietf:params:whep:{type}:{name}:{other}
关键字具有以下含义:
- type: 实体类型。本规范仅定义"ext"类型。
- name: 必需的 US-ASCII 字符串,符合 URN 语法要求(参见 {{RFC8141}}),定义 whep 协议扩展的主要命名空间。该值也可以是行业名称或组织名称。
- other: 任何符合 URN 语法要求(参见 {{RFC8141}})的 US-ASCII 字符串,定义子命名空间(可以进一步分解为以冒号分隔的命名空间),根据需要唯一标识 whep 协议扩展。
相关辅助文档:
无
标识符唯一性考虑:
指定联系人应负责审查和执行唯一性。
标识符持久性考虑:
一旦分配了名称,不得为不同目的重新分配。为子命名空间内的值分配提供的规则必须构建为值的含义不能改变。此注册机制不适合命名其含义可能随时间变化的值。
标识符分配过程:
类型为"ext"的命名空间(例如,"urn:ietf:params:whep:ext")保留用于 IETF 批准的 whep 规范。
标识符解析过程:
未指定。
词汇等价规则:
无特殊考虑;[RFC8141] 中指定的词汇等价规则适用。
符合 URN 语法:
无特殊考虑。
验证机制:
未指定。
范围:
全局。
7. 致谢
8. 参考文献
8.1. 规范性参考文献
[FETCH]
WHATWG, "Fetch - Living Standard", n.d., https://fetch.spec.whatwg.org.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.
[RFC3264]
Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, https://www.rfc-editor.org/info/rfc3264.
[RFC3553]
Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, https://www.rfc-editor.org/info/rfc3553.
[RFC5789]
Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010, https://www.rfc-editor.org/info/rfc5789.
[RFC6750]
Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, https://www.rfc-editor.org/info/rfc6750.
[RFC7675]
Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, October 2015, https://www.rfc-editor.org/info/rfc7675.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.
[RFC8288]
Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, https://www.rfc-editor.org/info/rfc8288.
[RFC8725]
Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, https://www.rfc-editor.org/info/rfc8725.
[RFC8829]
Uberti, J., Jennings, C., and E. Rescorla, Ed., "JavaScript Session Establishment Protocol (JSEP)", RFC 8829, DOI 10.17487/RFC8829, January 2021, https://www.rfc-editor.org/info/rfc8829.
[RFC8858]
Holmberg, C., "Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)", RFC 8858, DOI 10.17487/RFC8858, January 2021, https://www.rfc-editor.org/info/rfc8858.
[RFC8863]
Holmberg, C. and J. Uberti, "Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)", RFC 8863, DOI 10.17487/RFC8863, January 2021, https://www.rfc-editor.org/info/rfc8863.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, https://www.rfc-editor.org/info/rfc9110.
[RFC9143]
Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 9143, DOI 10.17487/RFC9143, February 2022, https://www.rfc-editor.org/info/rfc9143.
[W3C.REC-ldp-20150226]
Malhotra, A., Ed., Arwe, J., Ed., and S. Speicher, Ed., "Linked Data Platform 1.0", W3C REC REC-ldp-20150226, W3C REC-ldp-20150226, 26 February 2015, https://www.w3.org/TR/2015/REC-ldp-20150226/.
8.2. 信息性参考文献
[I-D.draft-ietf-rtcweb-gateways]
Alvestrand, H. T. and U. Rauschenbach, "WebRTC Gateways", Work in Progress, Internet-Draft, draft-ietf-rtcweb-gateways-02, 21 January 2016, https://www.ietf.org/archive/id/draft-ietf-rtcweb-gateways-02.txt.
[I-D.draft-ietf-wish-whip]
Murillo, S. G. and A. Gouaillard, "WebRTC-HTTP ingestion protocol (WHIP)", Work in Progress, Internet-Draft, draft-ietf-wish-whip-05, 19 October 2022, https://www.ietf.org/archive/id/draft-ietf-wish-whip-05.txt.
[RFC3261]
Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, https://www.rfc-editor.org/info/rfc3261.
[RFC6120]
Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, https://www.rfc-editor.org/info/rfc6120.
[RFC7826]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, https://www.rfc-editor.org/info/rfc7826.
[RFC8141]
Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, https://www.rfc-editor.org/info/rfc8141.
作者地址
Sergio Garcia Murillo
Millicast
Email: sergio.garcia.murillo@cosmosoftware.io
Cheng Chen
ByteDance
Email: webrtc@bytedance.com