虽然WebRTC在各种各样的场景中都非常成功，但它在广播/流媒体行业的应用却相对滞后。目前还没有标准协议（如SIP或RTSP）用于使用WebRTC将媒体接收到流媒体服务中，因此内容提供商仍然严重依赖RTMP等协议。¶
这些协议比WebRTC旧得多，默认情况下，WebRTC缺乏一些重要的安全和弹性功能，开销和额外延迟都很小。¶
在较旧的协议中，用于接收的媒体编解码器往往是有限的，并且没有经过协商。WebRTC包括对编解码器协商的支持，这可能会减轻接收节点上的转码（这可能会引入延迟并降低媒体质量）。在自适应比特率流（ABR）实现中，传统上用于呈现多个格式副本的服务器端转码可以被WebRTC客户端支持的同步广播和SVC编解码器所取代。此外，WebRTC客户端可以根据RTCP反馈调整客户端编码参数，以最大限度地提高编码质量。¶
本文档提出了一个简单的基于HTTP的协议，允许基于WebRTC的内容摄取到流媒体服务和/或CDN中。¶
本互联网草案完全符合BCP 78和BCP 79的规定。¶
互联网草案是互联网工程任务组（IETF）的工作文件。请注意，其他小组也可以将工作文件作为互联网草稿分发。目前互联网上的草稿列表位于https://datatracker.ietf.org/drafts/current/. ¶
互联网草案是有效期最长为六个月的文件草案，可随时由其他文件更新、替换或作废。不应将互联网草稿用作参考资料或引用as"以外的内容；工作正在进行中" ¶
版权（C）2021 IETF信托和被认定为文件作者的人。版权所有。¶
本文件受BCP 78和IETF信托'的约束；s与IETF文件相关的法律规定（https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包括简化的BSD许可证文本，如第4节所述。如简化BSD许可证所述，不提供任何担保。¶
RTCWEB标准化JSEP（[RFC8829]），一种用于控制多媒体会话的设置、管理和拆卸的机制，以及如何使用SDP提供/应答模型和通过有线发送的数据的所有格式（媒体、编解码器、加密等）应用它。此外，WebRTC有意不在应用程序级别指定信令传输协议。这种灵活性允许实施广泛的服务。然而，这些服务通常是独立的筒仓，不需要'；不需要与其他服务的互操作性，也不需要利用现有的可以与它们通信的工具。¶
在广播/流媒体世界中，使用硬件编码器可以非常简单地插入（SDI）传输原始媒体的电缆，对其进行编码，并将其推送到任何流媒体服务或CDN接收，这种情况已经无处不在。值得注意的是，每个WebRTC服务都采用了定制的信令传输协议，这阻碍了作为摄入协议的广泛采用。¶
虽然有一些标准信令协议可以与WebRTC集成，如SIP或XMPP，但它们并不是设计用于广播/流媒体服务，也没有在该行业采用的迹象。RTSP基于RTP，在功能上可能与WebRTC最接近，但与WebRTC SDP提供/应答模式不兼容。¶
在将媒体摄入流媒体服务的特定情况下，可以对服务器端进行一些假设，从而简化WebRTC合规负担，如WebRTC网关文件[I-D.draft-alvestrand-rtcweb-gateways]中所述。¶
本文件提出了一个简单的协议，用于支持WebRTC作为媒体摄取方法，即：
允许在传统媒体平台和WebRTC端到端平台中以尽可能低的延迟进行接收。¶
关键词"；必须""不得""必需的""应""不得""应该""不应该""推荐""5月"日；，和"；可选"；在本文件中，应按照[RFC2119]中所述进行解释。¶
WHIP客户端：WebRTC媒体编码器或生产者，通过编码媒体并将其传送到远程媒体服务器，充当WHIP协议的客户端。¶
媒体服务器：与WHIP客户端建立媒体会话并接收其生成的媒体的WebRTC媒体服务器或消费者。¶
WHIP resource：由WHIP端点为正在进行的摄取会话分配的资源，WHIP客户端可以发送更改会话的请求（例如，ICE操作或终止）。¶
WHIP resource URL：由WHIP端点分配给特定媒体会话的URL，可用于执行终止会话或ICE重启等操作。¶
WebRTC HTTP接收协议（WHIP）使用HTTP POST请求执行单发SDP提供/应答，以便在编码器/媒体生产者（WHIP客户端）和广播接收端点（媒体服务器）之间建立ICE/DTLS会话。¶
设置ICE/DTLS会话后，媒体将从编码器/媒体制作者（WHIP客户端）单向流到广播接收端点（媒体服务器）。为了降低复杂性，不支持SDP重新协商，因此一旦完成HTTP上的初始SDP提供/应答，就不能添加或删除任何曲目或流。¶
+-----------------++------------------++--------------++---------++---------++----+---------+---------+----+---------+--------------+--------------+--------------+----+----+--------------+--------------+----+--------------+----+----+----+----+----++----+| | | | | | | | | | | | | | | | | | | HTTP POST（SDP提供）| | |+-------------------------+--------------++++|201已创建（SDP答案）| | |+<；--------------------------------------+| | |ICE请求| |+-------------------------------------->；+| |ICE响应| |<；--------------------------------------+| |DTLS设置| |<==========================================>；| |RTP/RTCP流量| |+-------------------------------------->；| |HTTP DELETE |+--------------------------------------------------------------->；+|200好|<-------------------------------------------------------------十、
为了设置摄取会话，WHIP客户端将根据JSEP规则生成SDP提供，并向WHIP端点配置的URL发出HTTP POST请求。¶
HTTP POST请求的内容类型为application/sdp，并包含sdp offer作为主体。WHIP端点将生成一个SDP应答，并返回一个201创建的响应，其中内容类型为application/SDP，SDP应答作为主体，位置头指向新创建的资源。¶
SDP报价应使用sendonly属性，SDP应答必须使用RecVoOnly属性。¶
一旦建立了会话，ICE同意新鲜度[RFC7675]将用于检测突然断开和DTLS断开，以终止任何一方的会话。¶
要显式终止会话，WHIP客户端必须对初始HTTP POST的Location头中返回的资源URL执行HTTP DELETE请求。收到HTTP删除请求后，将删除WHIP资源，并释放媒体服务器上的资源，从而终止ICE和DTLS会话。¶
终止会话的媒体服务器必须按照[RFC7675]第5.2节中的程序立即撤销同意。¶
WHIP端点必须为资源URL上的任何HTTP GET、HEAD或PUT请求返回HTTP 405响应，以便为本协议规范的未来版本保留其使用。¶
WHIP资源必须为资源URL上的任何HTTP GET、HEAD、POST或PUT请求返回HTTP 405响应，以便为本协议规范的未来版本保留其使用。¶
WHIP客户的初始报价可以在完整的ICE会议结束后发送，包括完整的ICE候选人名单，或者只包含本地候选人，甚至是空名单。¶
为了简化协议，在发送SDP应答后，不支持从媒体服务器ICE候选者交换收集的涓涓流候选者。在响应客户端请求之前，WHIP端点应收集媒体服务器的所有候选ICE，SDP应答应包含媒体服务器的候选ICE的完整列表。媒体服务器可以使用ICE lite，而WHIP客户端必须实现完整的ICE。¶
WHIP客户端可以通过向WHIP资源URL发送HTTP补丁请求来执行涓流ICE或ICE重启[RFC8863]，该URL的主体包含MIME类型为"的SDP片段；应用/滴冰sdpfrag和#34；按照[RFC8840]中的规定，使用新的ICE候选者或ICE ufrag/pwd重新启动。WHIP资源可能不支持涓流ICE（即ICE lite媒体服务器）或ICE重启，在这种情况下，它必须为任何HTTP补丁请求返回405 Method not Allowed响应。¶
接收到带有新ICE候选的路径请求但不执行ICE重启的WHIP资源必须返回204无正文的无内容响应。¶
补丁/resource/id HTTP/1.1Host:whip。实例comContent类型：application/Drickle ice sdpfragContent长度：548a=ice ufrag:EsAwa=ice pwd:P2uYro0UCOQ4zxjKXaWCBui1m=audio RTP/AVP 0a=mid:0a=候选者：1387637174 1 udp 2122260223 192.0.2.1 61764典型主机生成0 ufrag EsAw网络id 1a=候选者：3471623853 1 udp 2122194687 198.51.100.1 61765典型主机生成0 ufrag EsAw网络id2a=候选：473322822 1 tcp 1518280447 192.0.2.1 9典型主机tcptype活动生成0 ufrag EsAw网络id 1a=候选：2154773085 1 tcp 151821491198.51.100.2 9典型主机tcptype活动生成0 ufrag EsAw网络id 2a=候选结束HTTP/1.1 204无内容
如果HTTP补丁请求导致ICE重启，则WHIP资源将返回一个200 OK，带有"；应用/滴冰sdpfrag和#34；正文包含新的ICE用户名片段和密码，以及可选的媒体服务器的新ICE候选集。¶
由于WHIP客户端发送的HTTP补丁请求可能会被WHIP资源无序接收，因此WHIP资源应该跟踪WHIP客户端使用的ICE用户名片段和客户端的先前值。如果客户端接收到HTTP补丁请求时使用了以前使用的ICE用户名片段和密码，则WHIP端点将不会执行并重新启动ICE，而是使用409冲突响应拒绝该请求。¶
为了降低在客户端和媒体服务器中实现WHIP的复杂性，对WebRTC的使用进行了一些限制。¶
SDP捆绑包应由WHIP客户端和媒体服务器使用。根据[RFC8843]，WHIP客户创建的SDP报价必须在所有m-lines中包含bundle only属性。此外，RTCP muxing还应得到WHIP客户端和媒体服务器的支持。¶
与[RFC5763]不同，WHIP客户端可以在SDP报价中使用setup:active的设置属性值，在这种情况下，WHIP端点必须在SDP应答中使用setup:passive的设置属性值。¶
WHIP端点和媒体服务器可能不在同一台服务器上共存，因此可以对不同媒体服务器的传入请求进行负载平衡。WHIP客户端应通过对WHIP端点URL的初始HTTP响应中的307临时重定向响应代码支持HTTP重定向。WHIP资源URL必须是最终URL，发送给它的补丁和删除请求不需要支持重定向。¶
在高负载的情况下，WHIP端点可能会返回503（服务不可用）状态代码，指示服务器当前由于临时过载或计划维护而无法处理请求，这可能会在一些延迟后得到缓解。¶
WHIP端点可能会发送一个Retry After标头字段，指示在发出重定向请求之前要求用户代理等待的最短时间。¶
WHIP端点可以在对WHIP端点url的HTTP POST请求的201创建的响应中返回客户端可用的ICE服务器配置url和凭证。¶
每个ICE服务器将在带有"；rel"；分配值为"；ice服务器"；其中，链接目标URI是ICE服务器URL，凭据在链接目标属性中编码如下：
用户名：如果这个链接头代表一个回合服务器，那么creadential类型是"；密码"；，然后，该属性指定要与该回合服务器一起使用的用户名。¶
凭证：如果凭证类型为"；密码"；，凭证代表长期身份验证密码，如[RFC8489]第10.2节所述。¶
creadential类型：如果此RTICEServer对象表示回合服务器，则此属性指定当该回合服务器请求授权时应如何使用凭据。如果属性不存在，则默认值为"；密码"；。¶
链接：晕眩：晕眩。实例网链接：转：转。实例网传输=udp；rel="；冰服务器"；；用户名="；用户"；；学历："；我的密码"；；凭证类型："；密码"；；链接：转：转。实例网传输=tcp；rel="；冰服务器"；；用户名="；用户"；；学历："；我的密码"；；凭证类型："；密码"；；链接：转身：转身。实例网传输=tcp；rel="；冰服务器"；；用户名="；用户"；；学历："；我的密码"；；凭证类型："；密码"；；
有些webrtc实现不支持在创建本地服务后更新ICE服务器配置。为了支持这些客户端，WHIP端点还可以在对发送到POST请求之前发送的WHIP端点URL的已验证选项请求的响应中包含ICE服务器配置。¶
还可以使用广播服务或外部轮转提供商在WHIP客户端上提供的长期凭证来配置STU/TURN服务器URL，覆盖WHIP端点提供的值。¶
通过SDP报价/应答中的协商，媒体服务器和WHIP客户端都可以支持同步广播和可伸缩视频编码（包括K-SVC模式）。¶
如果客户支持simulcast并希望使其能够发布，则必须根据[RFC8853]第5.3节中的程序协商SDP报价中的支持。接受同步广播服务的服务器必须根据程序[RFC8853]第5.3.2节创建答案。¶
为了支持为WHIP协议定义的未来扩展，定义了注册和宣布新扩展的通用过程。¶
WHIP服务器支持的协议扩展必须在发送到WHIP端点的初始HTTP POST请求的201创建响应上通告给WHIP客户端。WHIP端点必须为每个扩展返回一个链接头，扩展名为#34；rel"；类型属性和HTTP资源的URI，该资源将可用于接收与该扩展相关的请求。¶
对于WHIP客户端和服务器，协议扩展都是可选的。WHIP客户端必须忽略任何未知的链接属性"；rel"；属性值和WHIP服务器不得要求使用任何扩展。¶
每个协议扩展必须注册一个唯一的"；rel"；IANA上以前缀开头的属性值："；urn:ietf:params:whip:"；。¶
例如，使用中指定的服务器发送事件进行服务器到客户端通信的潜在扩展https://html.spec.whatwg.org/multipage/server-sent-events.html#server-发送事件时，用于连接到已发布流的服务器端事件资源的URL将在初始HTTP"中返回；创建201个#34个；回答为"；链接"；标题和a"；rel"；属性为"；urn:ietf:params:whip:server-sent-events"；。¶
IANA已根据[RFC8288]第4.2节注册了以下链接关系类型。¶
关系名称：ice服务器描述：描述ice代理可用于与对等方建立连接的STUN和TURN服务器。参考：待定