5.7. Processing a Rollback (处理回滚)

5.7. Processing a Rollback (处理回滚)

当 PeerConnection 处于除 "stable" 以外的任何状态时, 可以执行回滚 (rollback)。 这意味着既可以回滚提议, 也可以回滚临时应答 (provisional answer)。 回滚只能用于取消已提议的变更; 不支持从某一 "stable" 状态回滚到先前的 "stable" 状态。 若在 "stable" 状态下尝试回滚, 处理必须停止并必须返回错误。 请注意, 这意味着一旦应答方已对其应答执行 setLocalDescription, 便无法再回滚。

无论调用的是 setLocalDescription 还是 setRemoteDescription, 回滚的效果必须相同。

为了处理回滚, JSEP 实现放弃当前的提议/应答事务, 将信令状态设为 "stable", 并将待定的本地和/或远端描述 (见第 4.1.14 与 4.1.16 节) 设为 "null"。 被放弃的本地描述所分配的任何资源或候选均被丢弃; 收到的任何媒体按照先前的本地与远端描述进行处理。

回滚会解除通过应用被回滚的会话描述而与 "m=" 节关联的所有 RtpTransceiver 的关联 (见第 5.10 与 5.9 节)。 这意味着某些先前已关联的 RtpTransceiver 将不再与任何 "m=" 节关联; 在此类情况下, RtpTransceiver 的 mid 属性的值必须设为 "null", 且收发器与其 "m=" 节索引之间的映射必须丢弃。 因应用随后被回滚的远端提议而创建的 RtpTransceiver 必须停止并从 PeerConnection 中移除。 但是, 若已通过 addTrack 方法将轨道 (track) 附加到 RtpTransceiver, 则绝对不能移除该 RtpTransceiver。 这样应用程序可以先调用 addTrack, 再调用 setRemoteDescription 传入提议, 再回滚该提议, 再调用 createOffer, 并使所添加轨道对应的 "m=" 节出现在生成的提议中。