问sip协商(sdp)中的编解码器首选项

EN

根据我多年的经验，我看到的是被呼叫者在200 OK中选择SDP的200 OK。所以被呼叫者选择。

来自SDP offer answer RFPhttps://www.ietf.org/rfc/rfc3264.txt

在此模型中，会话中的一个参与者生成一条

消息，该消息构成提供方希望使用的一组媒体流和编解码器，以及提供方希望用于接收媒体的IP地址和端口。报价被传达给另一个参与者，称为答复者。应答方生成应答，该应答是对要约方提供的要约作出响应的SDP消息。应答中的每个流都有一个匹配的媒体流，指示该流是否被接受，以及将使用的编解码器以及应答者要用来接收媒体的IP地址和端口。

此外..。

一旦要约人发送了要约，它必须准备接收该要约所描述的任何recvonly流的媒体。它必须准备好为提供中的任何sendrecv流发送和接收媒体，并为提供中的任何仅发送流发送媒体(当然，它实际上不能发送，直到对等体提供具有所需地址和端口信息的应答)。在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。