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