Wireshark(原名:Ethereal)是一个网络封包分析软件。网络封包分析软件的功能是捕获网络封包，并尽可能显示出详细的网络封包信息。
供应商希望你相信需要用数千美元的协议分析软件去解决IP电话(VoIP)网络语音。毕竟，数据包的延迟、丢失或乱序会直接影响通话质量。幸运的是，Wireshark是一个开放源代码的软件包，它可以实现这类工具所能实现的功能，甚至更多。
Wireshark，即以前被人们所熟知的 Ethereal，它是网络封包分析软件，使用WinPCAP作为接口，直接与网卡进行数据报文交换。它要做的就是监听网络流量，并用你需要的格式来显示包内容，帮助你发现问题。VOIP涉及一系列Wireshark可以解码并相互关联的复杂协议包。例如，建立一个通话的流程会用到很多协议，而不仅仅是语音流本身。Wireshark使用建立呼叫的信息来更好地理解语音流。用你手中的这些数据，可以进一步隔离VOIP中存在的问题。
想要查找的VoIP问题的原因，你必须能够跟踪从开始到结束的流程，并确保他们产生的是正确的事件。这不但要求你懂得基础协议，而且要理解一些电话的概念。幸运的是，Wireshark提供了一些优秀的工具，以帮助你解释数据。本文将把如何使用Wireshark工具作为重点，来解决3个最常遇到的VOIP问题。
第一个例子是，电话不工作。每次拨打一个号码，即使话机处于空闲状态，也不会有振铃。Wireshark这时就该查看话机和PBX(Private Branch Exchange)交换机之间的数据了。
以root身份启动Wireshark，点击 Capture->Option ，将会弹出捕获选项对话框，如图1所示，确保接口正在使用中，否则，你不会看到的流量。在这个例子中，我们捕获PBX唯一接口eth0的数据流量：
(图1：使用Wireshark分析VOIP的捕获选项对话框)
在捕获包之前，需要指定捕获数据包的过滤器选项，来限制你将要处理的数据包数量。因为，无论是信令流(SIP)还是语音流(RTP)都是基于UDP协议的，那我就可以指定UDP作为我捕获的过滤条件。为方便起见，我还可以用实时查询选项检查数据包的更新列表，以便我可以确认我得到适当的流量。点击开始按钮，开始捕捉，很快上方窗格中会显示几个数据包(图2)。
(图2：使用Wireshark捕获的IP电话的数据流量)
图2显示出了该分组的列表。前四列显示数据包的号，来源，时间以及所涉及的主机的地址。因为Wireshark抓SIP，它能够识别作为SIP数据包的协议列，并在信息栏上给出详细信息。
图2中信息的粗略检测表明：同样的三个数据包，来回重复了四次。第一个，IP话机主机向PBX主机发送了一个SIP INVITE信令，用以开始一个对话。接下来，PBX通过产生ACK返回给该话机“407代理服务器身份验证”响应，然后用数据包6做了第二次INVITE。由于这是个不断重复的过程，因此我们可以大致猜测是用户名或密码的错误导致身份验证失败。
监听:关于本地数据包的捕获
如果你要捕获的那些数据包，很多都没有到达运行Wireshark机器的网络接口，说明网络交换出了问题。只对某个抓包的通信端口进行限制以提高性能。生成树协议 和 IP协议只会在你试图捕获数据包的地方造成干扰。
你最好直接在那台参与工作的机器抓包，如果那台机器不能使用Wireshark，你总可以使用Tcpdump进行抓取本地的数据包，然后将其移动到其他计算机上，进行数据包分析。如果做不到，或者数据流量跨越多台机器，是时候该从你的网络硬件上寻求突破口了。
大多数管理型交换机可映射一个端口到其他端口所有的数据帧。因此，你可以用Internet将Wireshark 工作平台连接到你的交换机端口上，将所有的网络数据包映射到工作平台上。并且你还可以分析所有的互联网流量。思科 称之为 交换机端口分析器(SPAN)，惠普 称之为 端口监控器，3Com公司称其为 巡回分析端口。
选择哪个端口来做镜像取决于你网络情况，一般说来，连接到其他的交换机或路由器的端口是一个不错的选择，这也是降噪过滤器必须要解决的问题。
第一个例子利用了Wireshark的高级解析单个数据包的功能，以突出一个单调的问题。接下来的例子需要更加全面的分析VOIP。Wireshark 用来查看SIP呼叫的建立和确认关键数据包。在这个例子中，这个话机正用于 单通音频。外呼的电话振铃，然后接通，但是仅有一方可以听到声音。会话数据包以与前面的例子相同的方式被捕获，总共140帧。如果没有Wireshark中先进的分析工具提供支持，数据太多以至于无法进行分析。
随着捕获工具的加载，选择 Statistics Telephony->VoIP calls，Wireshark会分析捕获到的任何与VOIP相关的数据包，并显示数据包摘要。点击通话(如果有多个呼叫被显示出来，按住Ctrl可以选择其他通话)，然后点击Graph按钮。你会看到有关SIP呼叫的摘要，如图3所示：
(图3：SIP会话在Wireshark的图形界面中的显示)该分析图表对话框显示了各方发来的SIP消息。图3中的第一消息是INVITE消息，这是建立呼叫的第一步。在这个例子中，IP电话访问PBX发出呼叫到SIP地址为：613@fwd.pulver.com，这是测试SIP呼叫FreeWorldDialup提供的回拨服务。这个是用于认证请求的响应，这是公认的。这话机再次尝试并给出了“尝试”的PBX的状态。然后，PBX继续通过联系fwd.pulver.com邀请远程端口。在呼叫被正确建立之前，已经有很多消息发生了交换。
眼下的问题是单通。实际上，图形分析窗口显示IP电话发送实时协议(RTP)的语音数据包到因特网上的SIP终端，但它并没有显示在相反方向的数据流。为了确定为什么没有音频被送回，有必要更深入地读取SIP包。
SIP的功能之一就是建立两个终端之间的RTP数据流，它正是通过带有编码信息，IP地址，以及必要的VoIP工作端口号的会话描述协议(SDP)。需要注意的是，终端发出SDP不一定非得是互相交谈！在图3中，pbxhost主机和fwd.pulver.com 正通过互联网相会谈判，但他们各自指定不同的终端终止语音呼叫。RTP流是单向的，所以一个全双工会话需要在每个方向上都设置一个独立的RTP，用来区分两个SDP信息。
考虑到这一点，找出从pbxhost发送到fwd.pulver.com的SDP信息看起来有点难度。这个SDP消息将包含IP地址，UDP端口和 对端到本地IP电话会话的编码。但SDP消息在图形分析窗口将被SDP标记，来帮助你发现他们，该数据包的偏移量在图3中的0.490。当您单击图形分析窗口中的消息，相应的数据包将在 Wireshark 主窗口的数据包列表窗格中高亮显示。
Wireshark 还可以解析协议，那些协议被包含在当前分组细节窗口选中的数据包里。另外，还提供所述报文列表窗格中报文的摘要。解码是分层的，比如：以太网层，IP协议层，UDP协议 和 SIP协议。你可以通过点击窗口的左侧的箭头深入信息。图4显示的是与以上SDP(会话描述协议)相关字段的扩展信息。
(图4：包含SDP信息的SIP数据包在Wireshark图形界面中的显示)每一行SDP消息，描述的是将要创建会话的特定属性，并遵循简单的形式，即：属性=值。其中”属性”是一个单个字母，而”值”是一个文本字符串。 Wireshark使用该协议的知识来添加一些额外的文本，比如属性的描述。对于VoIP会话，最重要的属性如下：
a—attributes，属性，例如编解码器和静音抑制
c—connection information，连接信息，包括IP地址期望的RTP流值
m—media description，间媒体描述，包括在RTP终端侦听的端口号
t—active time，工作时间。
从连接信息(c)行，可以确定正在发送数据的主机是IP为192.168.1.151的机器。m属性指定的是34008端口的RTP的期望值。通过属性，可以看到他提供 PCMU和PCMA的编码，包括GSM压缩格式和通过电话事件的按键音媒体格式。这个问题就是，提供的IP地址192.168.1.151是一个私有地址，无法到达网络。当远程主机尝试向192.168.1.151发送数据包时，数据包丢失，因为在网络上不存在这个路由。
完整起见，会话另一端的SDP信息在7.554时间线处。当提供的数据被确认后，在刚开始的SDP信息中，这两部电话开始相互向指定的IP和端口发送语音数据包，因为pbxhost提供了一个无效的地址fwd.pulver.com，语音呼叫的另一半是从未见过此这个请求的。
这是使用网关进行VoIP网络地址转换的常见问题，这个问题是可以根据需求，使用多种方法来解决的，当然这是另一个话题了！
至此，故障排除一直集中在网络电话的呼叫信令方面。一旦终端开始发送RTP流，网络质量又会成为话音质量的影响因素了。影响VoIP的网络因素有 延迟、波动(不稳定)、丢包。延迟即数据包从A终端到B终端所花费的时间。波动是数据序列包中延迟的变量。丢包是指从A终端发出，从未到达B终端的的报文数量。由于VoIP音频是通过实时UDP协议进行传输的，如果头域在乱序的数据包到达之前就已经打开了，那么这个数据包将被丢弃。
举最后一个案例，我发起一个通话，并捕获包括呼叫建立在内的数据包。Wireshark使用所述SIP信息以获得有关RTP分组流，使用RTP分析工具来获取更多详细信息。点击 Statistics→RTP→Show All Streams，Wireshark使用经过解码的数据包，以提供所有的音频对话和一些基本统计数据的列表，如图5所示。
(图5：Wireshark捕获的RTP数据流信息列表)上图中显示出了4个RTP数据流，因为每个音频流包括两个方向的数据流，并且 PBX 主机用来桥接两个话机。用来判断数据流是否有问题的是最后一个字段，即Pb列。如果显示”X”字样，则表示与VoIP相关问题。这条数据流的最大延迟是84毫秒，质量还算可以。最大波动值也算不错，11毫秒(单向延迟150毫秒，波动20毫秒 都是可以接受的极限范围)，但 丢包却达到了将近20%，这是很可怕的。
点击并选中这条有问题的数据流，可做进一步的分析，然后 点击”Find Reverse”按钮，再选择会话的另一半，最后 点击”Analyze”按钮可以看到一个接一个的数据包流。丢失的数据包将会被标记上”Wrong sequence nr.”并显示出来，如图6所示。在该图上，还显示了一些有用的统计数据信息，比如当前的带宽，延迟 和 波动。
(图6：有关大量丢包的RTP数据流分析)图6可以清晰地表明一些网络问题，因为丢包异常(稳定的带宽和固定间隔的丢包可以有力证明队列优先级超负荷或者加强了网络设备的监管)。这些丢包在反方向是看不到的，因为捕获包是在靠近会话的源端。点击”Save as CSV…”按钮，你可以保存窗口的内容。
网络问题是比较难解决的，因为它们需要与网络设备和其它潜在方的交互。如果你的VoIP环境不使用互联网，你可以在网络上捕获不同终端的数据包来查找是哪些因素导致的。如果通话数据流是通过互联网进行传输，你必须检查你与互联网的连接，或者需要运营商配合工作。
RTP分析可使用具有特殊配置的专用系统。如果遇到Wireshark的不识别的信令，它将不能够解码所有的RTP信息。点击 Edit->Preferences->Protocols->RTP 按钮，并试图检查解码会话以外的RTP数据包。分析可能会有点慢，但Wireshark的将尝试确定每一个属于RTP流的UDP数据包，让您使用RTP工具来查看通话。
我们在这里检测的最后一个特性是监听语音通话内容的能力。在打开的流分析窗口上点击”Save Payload…”按钮，选择.au格式的文件，并提供一个文件名，然后点击”OK”按钮，语音呼叫将自动保存到硬盘驱动器上。录音文件可以使用 XMMS，soxplay或其他音频播放器进行播放。
解决VoIP的问题不同于大多数其他网络故障诊断，因为独立的信令和语音协议，以及语音的实时性。这三个例子体现Wireshark的重要功能，他可以通过分析SIP呼叫的建立和RTP语音流来做专门的处理。对手的这些商业产品的功能，可以使你找到VoIP问题的根源所在。
