跳到主要内容

5.11. Applying an Answer (应用应答)

5.11. Applying an Answer (应用应答)​

除上文处理本地或远端描述的步骤外, 在处理类型为 "pranswer" 或 "answer" 的描述时还要执行以下步骤.

对每个 "m=" 段, 必须执行以下步骤:

  • 若该 "m=" 段已被拒绝 (即在应答中 port 字段值设为零), 则停止该段的任何媒体收发, 且除非有未被拒绝的 "m=" 段与此段捆绑, 否则按 [RFC8839] 第 4.4.3.1 节丢弃所有关联的 ICE 组件.

  • 若远端 DTLS 指纹已变更, 或 "a=tls-id" 属性值已变更, 则拆除 DTLS 连接. 这也包括 PeerConnection 状态为 "have-remote-pranswer" 的情况. 若需要拆除 DTLS 连接, 但应答未指示 ICE 重启, 或在 "have-remote-pranswer" 情况下未提供新的 ICE 凭据, 则必须生成错误. 若在 tls-id 值或指纹未变更的情况下执行 ICE 重启, 则通过新的 ICE 信道继续使用同一 DTLS 连接. 注意, 尽管 JSEP 要求应答方仅在提议方变更时才变更 tls-id 值, 非 JSEP 应答方只要提议中包含 ICE 重启就允许变更 tls-id 值. 因此, 在收到应答之前即处理 DTLS 数据的 JSEP 实现必须准备好接收 ClientHello 或来自先前 DTLS 连接的数据.

  • 若不存在有效的 DTLS 连接, 则准备在底层 ICE 组件一旦激活后, 使用指定的角色与指纹启动 DTLS 连接.

  • 若该 "m=" 段的 proto 字段值表明使用 RTP:

    • 若该 "m=" 段引用了在对应提议 "m=" 段中不存在的 RTCP 反馈机制, 表明协商存在问题, 必须导致错误. 但是, 允许在应答中出现新的媒体格式与新的 RTP 头扩展值, 见 [RFC3264] 第 7 节与 [RFC5285] 第 6 节.

    • 若该 "m=" 段启用了 RTCP 复用, 则丢弃 RTCP ICE 组件 (若存在), 并按 [RFC5761] 第 5.1.3 节开始或继续通过 RTP ICE 组件对 RTCP 做复用. 否则, 准备通过 RTCP ICE 组件发送 RTCP; 若因先前已启用 RTCP 复用而不存在 RTCP ICE 组件, 必须导致错误.

    • 若该 "m=" 段启用了 Reduced-Size RTCP, 则按 [RFC5506] 将该 "m=" 段的 RTCP 发送配置为使用 Reduced-Size RTCP.

    • 若应答中的 direction 属性表明 JSEP 实现应当发送媒体 (本地应答为 "sendonly", 远端应答为 "recvonly", 任一应答类型均可为 "sendrecv"), 则按 [RFC3264] 第 6.1 与 7 节, 将发送的媒体格式选为远端描述中最受偏好且本地也支持的媒体格式, 并在底层传输建立后开始用该格式发送 RTP 媒体. 若尚未为此出站 RTP 流选择 SSRC, 则选择一个唯一的随机 SSRC. 若已在发送媒体, 除非新编解码器的时钟速率不同, 否则应使用同一 SSRC; 当时钟速率不同时, 必须按 [RFC7160] 第 4.1 节选择新的 SSRC.

    • 使用远端描述中的负载类型映射确定出站 RTP 流的负载类型, 包括上文所选发送媒体格式的负载类型. 应将已协商的任何 RTP 头扩展包含在出站 RTP 流中, 使用远端描述中的扩展映射. 若已协商 MID 头扩展, 则按 [RFC8843] 第 15 节将其包含在出站 RTP 流中. 若已协商 RtpStreamId 或 RepairedRtpStreamId 头扩展且已建立 rid-id, 则按 [RFC8851] 第 4 节将这些头扩展包含在出站 RTP 流中.

    • 若该 "m=" 段类型为 "audio", 且 (1) 因处理远端描述而为发送媒体格式配置了静音抑制, 且 (2) 本地描述中对该格式也启用了静音抑制, 则按第 5.2.3.2 节的指引对出站媒体使用静音抑制. 若这些条件不满足, 出站媒体绝对不能使用静音抑制.

    • 若已协商 simulcast, 则按 [RFC8853] 第 5.3.3 节发送适当数量的源 RTP 流 (Source RTP Streams).

    • 若上文所选发送媒体格式有对应的 "rtx" 媒体格式, 或已协商 FEC 机制, 则为每个源 RTP 流建立一个具有唯一随机 SSRC 的冗余 RTP 流 (redundancy RTP stream), 并按需开始或继续发送 RTX/FEC 包.

    • 若上文所选发送媒体格式有相同时钟速率的对应 "red" 媒体格式, 则按 [RFC8854] 第 3.2 节允许使用指定格式进行冗余编码以增强韧性. 注意与 RTX 或 FEC 媒体格式不同, "red" 格式在源 RTP 流上发送, 而非在冗余 RTP 流上.

    • 对使用指定媒体格式的所有源 RTP 流, 启用媒体段中引用的 RTCP 反馈机制. 具体而言, 按 [RFC4585] 第 4.2 节开始或继续发送所请求的反馈类型并对收到的反馈作出响应. 发送 RTCP 反馈时, 遵循 [RFC8108] 第 5.4.1 节的规则与建议以选择使用哪个 SSRC.

    • 若应答中的 direction 属性表明 JSEP 实现不应发送媒体 (本地应答为 "recvonly", 远端应答为 "sendonly", 任一应答类型均可为 "inactive"), 则停止发送所有 RTP 媒体, 但继续发送 RTCP, 见 [RFC3264] 第 5.1 节.

  • 若该 "m=" 段的 proto 字段值表明使用 SCTP:

    • 若已存在 SCTP 关联且远端 SCTP 端口已变更, 则丢弃现有 SCTP 关联. 这也包括 PeerConnection 状态为 "have-remote-pranswer" 的情况.

    • 若不存在有效的 SCTP 关联, 则按 [RFC8841] 第 10.2 节, 准备在关联的 ICE 组件与 DTLS 连接上发起 SCTP 关联, 使用本地描述中的本地 SCTP 端口值与远端描述中的远端 SCTP 端口值.

若应答包含有效的捆绑组, 则丢弃将被捆绑到各捆绑中主 ICE 组件上的那些 "m=" 段的 ICE 组件, 并按 [RFC8843] 第 7.4 节开始对这些 "m=" 段进行相应复用.

若描述类型为 "answer" 且 ICE 候选池中仍有剩余候选, 则将其丢弃.

最后于 更新