7. Offerer Processing of the Answer (提议方对 Answer 的处理)

7. Offerer Processing of the Answer (提议方对 Answer 的处理)

当提议方 (offerer) 收到 Answer (应答) 后, 其可以就在已接受的媒体流上发送媒体, 前提是该流在 Answer 中被列为 sendrecv 或 recvonly。其必须使用 Answer 中列出的某一媒体格式来发送, 并且在确实发送时, 应该使用 Answer 中列出的第一种媒体格式。

此处使用 SHOULD (应该) 而非 MUST (必须) (对 Answerer (应答方) 而言同样是 SHOULD 而非 MUST), 是因为常常需要在会话过程中动态更换编解码器。例如, 在静音期间, 实现可能希望切换到舒适噪声 (comfort noise) 编解码器。又或者, 若用户在键盘上按数字键, 实现可能希望使用 RFC 2833 [9] 来发送该输入。拥塞控制也可能根据反馈而需要更换为更低码率的编解码器。

提议方应该按照 Answer 中任何 ptime 与带宽 (bandwidth) 属性的取值来发送媒体。

提议方可以立即停止监听那些在初始 Offer 中列出、但未出现在 Answer 中的媒体格式。