我对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>
答案 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是语音频带传真到传真)