作者：Giacomo Vacca（原文链接）
翻译：刘通
VoIP/RTC平台中通常有很多的元素来处理音频。当有错误报告的时候，为了节省时间和资源，清晰地限制调查范围是十分重要的。
一个典型的情况就是在客户端发生了音频丢失或者音频质量低差。就像我之前做的一样（点击此处查看Opus相关内容，点击此处查看SILK相关内容），我想分享一些从pcap轨迹（为了校验音频接收/发送是“正确的”）中提取音频的实际方法，以及在测试台中“回放”通话。当然也可以直接从数据中推算出很多东西，比如RTCP报告摘要可以显示数据包的交换量，丢包量，和延时。有些时候这些矩阵数据是没错的，但是依旧会报错。
在本文中，我们集中注意来分析Opus音频，从网络轨迹中的pcap文件着手，让我们看看如何将RTP数据包携带的Opus框架解码成可播放的WAV文件。
你不需要捕捉信令：有携带RTP的UDP包就足够了。如果信令对Wireshark来说，信令是不可见的，它有可能不会被判别出UDP包携带RTP，但是你可以右键单击框架来选择“RTP”。
通常来说，在Wireshark中找到相关的RTP流是很简单的（“Telephony -> RTP -> RTP Streams”），选择它，然后准备一个滤波器。然后你就可以将数据包中的内容提出到专用的pcap文件中（“File -> Export Specified Packets…”）。
我已经在opus-tools中的一个叉形指令中更改了opusrtp，为了能够从给定的pcap中提取出内容，创建一个Opus文件：
这会输出一个rtpdump.opus文件，可以直接用opusdec转换成WAV文件，仍然是opus-tools的一部分：
你可以听一听这个WAV文件，并且判断被携带的RTP负荷是否是有效的。
有RTP的网络轨迹还可以被用来回放通话，插入与被调查通话一样的RTP。通过sipp的帮助，你可以一个基本但是非常有用的测试台。使用标准的UAS场景（uas.xml），但是有一个额外的部分：
就在ACK被接收之后。如果像这样使用指令来开启sipp的话：
你就可以调用sipp。其会像场景所被指定进行的工作那样响应通话，并且播放在rtp_opus.pcap中的RTP。数据流的SSRC，时间戳，甚至标志位都会被保存下来。这会给你一个对在原本通话中用户接收的数据流有一个较为精准的模拟。
接下来应该就可以之间的查询这些内容了。对于opus-tools来说，在一个基于debian的机器上，你可以进行：
对于sipp：
我希望本篇文章可以节省您在未来工作中的时间。
