【发布时间】：2015-05-19 19:43:15
【问题描述】：
谁的编解码器在以下场景中获得优先权
假设 Caller 发送 INVITE sdp 有偏好：
1)编解码器 A 2)编解码器B
现在被调用者优先发送 200 OK sdp：
1)编解码器 B 2)编解码器A
呼叫者的编解码器优先级（编解码器 A 协商）或被呼叫者的编解码器优先（编解码器 B 协商）。
还会发送重新邀请以锁定编解码器吗？
【问题讨论】：
【发布时间】：2015-05-19 19:43:15
【问题描述】：
根据我多年的经验，我所看到的是被调用者在 200 OK 中选择了 SDP 的 200 OK。所以被调用者选择。
来自 SDP 报价答复 RFP..https://www.ietf.org/rfc/rfc3264.txt
在这个模型中， 会话中的一个参与者生成一条 SDP 消息，该消息 构成要约 - 媒体流和编解码器的集合 提供者希望使用，连同 IP 地址和端口 提供者想用来接收媒体。报价是 传达给另一个参与者，称为应答者。回答者 生成一个答案，它是一个 SDP 消息，用于响应 报价人提供的报价。答案有匹配的媒体 报价中每个流的流，指示流是否是 接受与否，以及将使用的编解码器和 IP 应答者想要用来接收媒体的地址和端口。
还有……
报价方发出报价后，必须准备好接收 该优惠描述的任何 recvonly 流的媒体。一定是 准备为任何 sendrecv 流发送和接收媒体 报价，并为报价中的任何 sendonly 流发送媒体（的 当然，在对等方提供答案之前，它实际上无法发送 以及所需的地址和端口信息）。在 RTP 的情况下， 即使它可能在答案到达之前接收到媒体，它也会 在应答到达之前无法发送 RTCP 接收器报告。
【讨论】：
根据 RFC4317（在第二个示例中），编解码器协商到现在还没有完成。调用者应提供第二个提议并锁定编解码器，例如另一个 ACK 请求中的 SDP。无需重新邀请。
RFC4317：
"Alice can support PCMU, PCMA, and iLBC codecs, but not more than one
at the same time. Alice offers all three to maximize chances of a
successful exchange, and Bob accepts two of them. An audio-only
session is established in the initial exchange between Alice and Bob,
using either PCMU or PCMA codecs (payload type in RTP packet tells
which is being used). Since Alice only supports one audio codec at a
time, a second offer is made with just that one codec, to limit the
codec choice to just one."
https://www.rfc-editor.org/rfc/rfc4317
但不幸的是，并非所有 SIP 平台都遵循这种行为，至少不是我现在使用的那个。这取决于您使用的 SIP 平台/IPPBX。
【讨论】：