跳到主要内容

5.3.2. Subsequent Answers (后续应答)

5.3.2. Subsequent Answers (后续应答)​

当第二次 (或更晚) 调用 createAnswer, 或在已安装本地描述之后调用 createAnswer 时, 其处理与初始应答略有不同。

若先前的应答未通过 setLocalDescription 应用, 即 PeerConnection 仍处于 "have-remote-offer" 状态, 则必须遵循生成初始应答的步骤, 但须受以下限制：

  • "o=" 行的各字段必须保持不变, 但 <session-version> 字段除外；若会话描述相对先前生成的应答有任何变化, 则 <session-version> 必须递增。

若此前曾向 setLocalDescription 提供过任何会话描述, 则通过遵循上述 "have-remote-offer" 状态下的步骤生成应答, 并附加以下例外：

  • "s=" 与 "t=" 行必须保持不变。

  • 每个 "m=" 与 "c=" 行必须用该 "m=" 段的默认候选的端口与地址填写, 如 [RFC8839] 第 4.2.1.2 节所述。请注意, 在某些情况下, "m=" 行中的协议可能与默认候选的不一致, 因为 "m=" 行的协议值必须与报价中提供的相符, 如上所述。

  • 每个 "a=ice-ufrag" 与 "a=ice-pwd" 行必须保持不变, 除非该 "m=" 段正在重启, 此时必须按 [RFC8839] 第 4.4.1.1.1 节的规定创建新的 ICE 凭证。若该 "m=" 段被捆绑进另一 "m=" 段, 则仍不得包含任何 ICE 凭证。

  • 每个 "a=tls-id" 行必须保持不变, 除非报价方的 "a=tls-id" 行已更改, 此时必须按 [RFC8842] 第 5.2 节的规定创建新的 tls-id 值。

  • 若报价方正在延续现有 DTLS 关联, 则每个 "a=setup" 行必须使用与现有 DTLS 关联一致的 "active" 或 "passive" 角色值。

  • 必须使用 RTCP 复用, 且当且仅当该 "m=" 段先前使用了 RTCP 复用时, 才插入 "a=rtcp-mux" 行。

  • 若该 "m=" 段未捆绑进另一 "m=" 段且 RTCP 复用未激活, 则必须用默认 RTCP 候选的端口与地址填写 "a=rtcp" 属性行。若尚未收集任何 RTCP 候选, 必须使用默认值, 如上第 5.3.1 节所述。

  • 若该 "m=" 段未捆绑进另一 "m=" 段, 对于在最近一次收集阶段 (见第 3.5.1 节) 已收集的每个候选, 必须按 [RFC8839] 第 5.1 节的定义添加 "a=candidate" 行。若该段的候选收集已完成, 必须按 [RFC8840] 第 8.2 节的描述添加 "a=end-of-candidates" 属性。若该 "m=" 段被捆绑进另一 "m=" 段, 则必须省略 "a=candidate" 与 "a=end-of-candidates"。

  • 对于未停止的 RtpTransceiver, "a=msid" 行必须保持不变, 无论收发器方向或轨道如何变化。若当前描述中不存在 "a=msid" 行, 必须按照与初始应答相同的规则生成 "a=msid" 行。

最后于 更新