SIP优惠回答模型

时间:2015-12-29 09:53:09

标签: asterisk sip

我对SIP Offer-Answer模型感到困惑。场景就是这样。

我在客户端(Say A和B)配置了两个帐号和星号服务器并拨打从A到B的电话。

A的帐户详情

客户端(应用程序):具有视频编解码器H264,音频编解码器G722,G711

服务器端(星号):无视频编解码器,音频编解码器G722,G711

B的帐户详情

客户端(应用程序):无视频编解码器,音频编解码器G722,G711

服务器端(星号):无视频编解码器,音频编解码器G722,G711

在第一个邀请(提供)中,我发送带有音频和视频“m =”参数的SDP(视频端口为52162),星号正在向我发送音频和视频的“m =”参数的答案(视频端口为0)在183会话进度和200 OK,(因为星号没有任何视频编解码器)。

从应用程序方面,我发送下一个INVITE以保持呼叫。为此我只发送一个= sendonly和“m =”参数用于音频。

我的疑问是“我可以避免从应用程序端”m =“第二个INVITE的视频参数(在我的情况下是保持)”,如果我得到第一个报价的视频端口为0的答案。 / p>

1 个答案:

答案 0 :(得分:2)

SIP提供/回答模型要求您在会话的所有修改中重新使用所有m = 相同顺序

唯一允许的操作是在现有的

下添加额外的m =

在您的用例中,如果您不包含 m = video 行,则远程端应拒绝您的邀请。

编辑:这是rfc的确切措辞,清楚地显示了永不删除任何m =行的要求:

来自rfc3264部分 8修改会话

If an SDP is offered, which is different from the previous SDP, the
new SDP MUST have a matching media stream for each media stream in
the previous SDP.  In other words, if the previous SDP had N "m="
lines, the new SDP MUST have at least N "m=" lines.  The i-th media
stream in the previous SDP, counting from the top, matches the i-th
media stream in the new SDP, counting from the top.  This matching is
necessary in order for the answerer to determine which stream in the
new SDP corresponds to a stream in the previous SDP.  Because of
these requirements, the number of "m=" lines in a stream never
decreases, but either stays the same or increases.  Deleted media
streams from a previous SDP MUST NOT be removed in a new SDP;
however, attributes for these streams need not be present.

作为旁注,表示可以修改m = line type (音频,视频,...)的异常非常有用:它提供的是部分 8.3.3更改媒体类型。这个例外是非常具体的,并不适用于99,99%...(例如从rfc是语音频带传真到传真)