首先直接给结论：客户端发送的这条消息格式是符合SIP/SDP规范的，不过和你方当前兼容的格式存在差异，这大概率是导致异常的根源。

接下来拆解一下规范细节：
根据SDP和SIP的标准定义，要关闭某个媒体流，只需要把对应媒体行（m-line）的端口号设置为0就足够了——这个端口为0的标记是核心，明确表示终止该媒体流。至于后面的传输协议（比如RTP/SAVP或RTP/AVP）和负载类型字段，在端口为0的场景下，其实是可选的冗余信息，规范里允许忽略这些字段的具体值。

对比你提到的两种格式：

• 客户端发送的：m=video 0 RTP/SAVP 0：这里用了加密传输协议RTP/SAVP，负载类型填了0（对应PCMU音频）。虽然负载类型看起来和视频不匹配，但因为端口已经设为0，按规范来说这个字段不影响“关闭视频流”的语义，可能只是客户端实现时随手沿用了之前的协议或填了个默认值。
• 你方可正常处理的：m=video 0 RTP/AVP 96 97 98：用了非加密的RTP/AVP，带了视频相关的负载类型。

你方出现异常的原因，大概率是处理逻辑没有完全遵循规范：
可能你们的设备/软件在识别到端口为0时，没有直接判定为关闭流，反而还去校验后面的传输协议或负载类型是否符合预期——比如看到RTP/SAVP就不知道怎么处理，或者看到负载类型0（音频）和视频媒体类型不匹配就抛出异常。

给你两个解决方向：

1. 按规范优化处理逻辑：当检测到m-line的端口为0时，直接执行关闭对应媒体流的操作，忽略后面的传输协议和负载类型字段，不管它们是什么值。这是长期来看最合规、最通用的方案。
2. 临时兼容调整：如果暂时没法修改处理逻辑，可以和客户端协商，让他们调整发送的SDP格式，改成你方已经兼容的m=video 0 RTP/AVP 96 97 98样式。

内容的提问来源于stack exchange，提问作者thahgr