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

时间:2015-03-17 11:36:37

标签: sip rtp codec sdp

谁的编解码器在以下场景中获得优先选择

假设呼叫者发送优先的INVITE sdp:

1)编解码器A. 2)编解码器B

现在Callee发送200 OK sdp,优先选择:

1)编解码器B. 2)编解码器A

Caller的编解码器优先级是否会获得优先权(Codec A会被协商)或Callee的编解码器会获得优先权(Codec B会被协商)。

还会发送重新邀请来锁定编解码器吗?

2 个答案:

答案 0 :(得分:2)

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

从SDP优惠回答RFP .. https://www.ietf.org/rfc/rfc3264.txt

  

在这个模型中,      会话中的一个参与者生成SDP消息      构成要约 - 媒体流和编解码器的集合      提供者希望使用,以及IP地址和端口      提供者想用来接收媒体。报价是   传达给另一个参与者,称为回答者。回答者      生成一个答案,这是一个响应的SDP消息      提供者提供的报价。答案有匹配的媒体      要约中的每个流的流,指示流是否      是否接受,以及将使用的编解码器和IP      应答者想要用来接收媒体的地址和端口。

...此外

  

一旦提供者发送了报价,它必须准备接收      该提议描述的任何recvonly流的媒体。肯定是      准备发送和接收任何sendrecv流媒体      提供,并为要约中的任何sendonly流发送媒体(      当然,在对等方提供答案之前,它实际上无法发送      使用所需的地址和端口信息)。在RTP的情况下,      即使它可能在答案到来之前收到媒体,它也会      在答案到来之前无法发送RTCP接收者报告。

答案 1 :(得分:0)

根据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://tools.ietf.org/html/rfc4317

但遗憾的是并非所有SIP平台都遵循这种行为,至少不是我现在使用的那种。这取决于您使用的SIP平台/ IPPBX。