8.4 Putting a Unicast Media Stream on Hold (将单播媒体流置于保持)

8.4 Putting a Unicast Media Stream on Hold (将单播媒体流置于保持)

若通话中的一方希望将对方 "置于保持 (on hold)", 即请求对方暂时停止发送一条或多条单播媒体流, 则该方向对方提供一份更新后的 SDP。

若待置于保持的流此前为 sendrecv 媒体流, 则通过将其标记为 sendonly 来置于保持。若待置于保持的流此前为 recvonly 媒体流, 则通过将其标记为 inactive 来置于保持。

这意味着每个方向上分别对一条流执行 "置于保持"。每条流独立地被置于保持。收到针对处于保持状态的流的 Offer 的一方, 不应该自动在 Answer 中将对应流也置于保持。所有流均处于保持状态的 SDP 称为 held SDP (保持态 SDP)。

在某些第三方呼叫控制 (third party call control) 场景中, 若 Answerer 以 held SDP 回应 held SDP, 则无法正常工作。

通常, 当用户 "按下" 保持时, 实现会生成一份 Offer, 其中 SDP 内所有流的方向均为 sendonly, 并且还会在本地静音, 从而既不向远端发送媒体, 也不播放输出。

RFC 2543 [10] 曾规定通过将连接地址设为 0.0.0.0 来将用户置于保持。将呼叫置于保持时, 不再建议使用这种做法, 因为其不允许在保持流上使用 RTCP, 在 IPv6 下不可用, 且会破坏面向连接的媒体。然而, 在初始 Offer 中, 当提议方已知希望使用的一组媒体流与格式、但在 Offer 时尚未知地址与端口时, 这种做法仍有用处。当然, 使用时端口号绝对不能为零, 否则表示该流已被禁用。实现必须能够接收连接地址为 0.0.0.0 的 SDP, 此时表示既不应向对等方发送 RTP, 也不应发送 RTCP。