4.1.10.1. Use of Provisional Answers (临时应答的使用)

4.1.10.1. Use of Provisional Answers (临时应答的使用)

大多数应用程序不需要使用 "pranswer" 类型创建 answer。虽然对 offer 立即发送响应是一种好的做法, 以便预热会话传输并防止媒体剪辑, 但 JSEP 应用程序的首选处理方式是在收到 offer 后立即创建并发送一个带有空 MediaStreamTrack 的 "sendonly" 最终 answer, 这将防止调用方发送媒体, 并允许被叫方在应答时立即发送媒体。稍后, 当被叫方实际接受呼叫时, 应用程序可以插入真实的 MediaStreamTrack 并创建新的 "sendrecv" offer 以更新先前的 offer/answer 对并开始双向媒体流。虽然这也可以通过 "sendonly" pranswer 后跟 "sendrecv" answer 来完成, 但初始 pranswer 会使 offer/answer 交换保持打开状态, 这意味着在此期间调用方无法发送更新的 offer。

作为示例, 考虑一个典型的 JSEP 应用程序, 该应用程序希望尽快设置音频和视频。当被叫方收到包含音频和视频 MediaStreamTrack 的 offer 时, 它将发送一个立即 answer, 接受这些轨道为 sendonly(意味着调用方还不会向被叫方发送任何媒体, 并且因为被叫方尚未添加自己的 MediaStreamTrack, 被叫方也不会发送任何媒体)。然后它将要求用户接受呼叫并获取所需的本地轨道。在用户接受时, 应用程序将插入它已获取的轨道, 因为 ICE 握手和 DTLS 握手可能已在此时完成, 可以立即开始传输。应用程序还将向远程端发送新的 offer, 指示接受呼叫并将音频和视频移动为双向媒体。第 7.3 节显示了沿这些方向的详细示例流程。

当然, 一些应用程序可能无法执行这种双重 offer/answer 交换, 特别是那些试图网关到传统信令协议的应用程序。在这些情况下, pranswer 仍然可以为应用程序提供一种预热传输的机制。