我对SIP Offer-Answer模型感到困惑。场景是这样的。
我在客户端配置了两个带有星号服务器的帐户（比如A和B），并从A打电话到B。
的账户详细信息
客户端（应用程序）：具有视频编解码器H264、音频编解码器G722、G711 的A
服务器端（星号）：无视频编解码器，音频编解码器G722，G711
B 的账户详细信息
客户端（应用程序）：无视频编解码器，音频编解码器G722，G711
服务器端（星号）：无视频编解码器，音频编解码器G722，G711
在第一个INVITE（offer）中，我发送了带有音频和视频参数"m="的SDP（视频端口为52162），星号在183会话进度和200 OK时向我发送了音频和视频的带有参数"m＝"的答案（视频端口是0）（因为星号没有任何视频编解码器）。
从应用程序端，我将发送下一个INVITE来暂停呼叫。为此，我只发送一个=sendonly和"m="参数用于音频。
如果我得到的第一个报价的视频端口为0的答案，我的疑问是"我能从应用程序端避免吗"m="第二个INVITE的视频参数（在我的情况下为保持）"。
SIP要约/应答模型要求在会话的所有修改中以相同的顺序重复使用所有m=行。
唯一允许的操作是在现有行的下方添加额外的m=行。
在您的用例中，如果不包含m=video行，则远程端应该拒绝您的INVITE。
编辑：这是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类型（音频、视频…）可能被修改的异常是有用的：它在第8.3.3节更改媒体类型中提供。这个例外是非常具体的，不会适用于99,99%。。。（来自rfc的示例是语音带传真到传真）