背景描述
最近在做 SIP 媒体转发服务时遇到了这样的问题：在某种场景下，服务器下行转发的屏幕共享流，SIP 端并没有正确解码并显示画面。
可能原因
- 媒体转发服务上行收到的媒体流不是屏幕共享流。
- 媒体转发服务器转发过程异常，导致最终转发的媒体流不是屏幕共享流。
- SIP 端未收到 sps/pps/idr，导致解码失败。
- sip/bfcp 协议的整体交互流程存在问题。
- 其他原因。
调试思路
- 如果是转发过程异常导致最终转发的媒体流是错误的，可以对比服务器上行接收与下行转发的 RTP 包的 ssrc、包长度、包数量是否一致以及验证转发的目标端口是否正确，或者将最终转发的数据包 dump 成可以播放的 h264 文件来验证问题。
- 如果是上行接收的媒体流是错误的，同样可以将上行接收的数据包 dump 成 h264 文件来验证问题。
注意，能够 dump 成可播放的 h264 文件的前提是：媒体流必须是解密后的明文数据。那么问题来了，如果服务器上行接收与下行转发的媒体流都是加密的，那么把媒体数据 dump 成 264 文件的想法是不是不可行呢？其实，在上行收流解密之后以及最终转发加密之前的整个过程，媒体流完全是解密的，我们可以在这个过程的一些关键节点将这些解密后的数据发送到本机某个端口（blackhole），比如 127.0.0.1:10000，并配合 wireshark 抓取这些解密的媒体数据（如果使用本地回环地址，记得要把 wireshark 的抓包接口设置为 Loopback）。
调试手段
下面介绍一种使用 blackhole + wireshark + h264extractor + vlc 调试媒体流的有效手段。
blackhole + wireshark
blackhole 的思路在上文已经提到，需要开发者自己编码实现，非常简单，可以参考 srs。
实现 blackhole 后，就可以在媒体转发过程中的任意节点将明文数据发送到 blackhole，并配合 wireshark 抓取解密后的媒体流。
h264extractor
wireshark 插件，将抓取后的明文数据包 dump 成 h264 文件。
注意，一定要将过滤出的特定分组的数据包保存到单独的 pcap 文件再使用插件去 dump 264 文件。
h264extractor 插件安装地址
h264extractor 插件安装教程
init.lua 文件在 mac 下的路径为：/Applications/Wireshark.app/Contents/Resources/share/wireshark，不过 mac 下的 wireshark 使用该插件会报错，还是建议在 windows 下的 wireshark 中安装并使用该插件。
vlc
验证 dump 好的 h264 文件是否可以正常播放，画面是否是预期的屏幕共享画面。
