原创 干货丨VoIP 网络排障新思路：从日志到 IOTA 分析

一个常见的问题是不兼容问题，目前有 100 多份与 SIP 相关的征求意见稿（RFC），其中有大量 “应该”（SHOULD）而非 “必须”（MUST）的声明。这通常会导致用户无法拨出或拨入电话。

本文将介绍一种使用 IOTA 的故障排除方法，IOTA 是一种实时流量捕获和分析工具，可简化复杂 VoIP 网络问题的根本原因识别。文章将重点介绍 IOTA 如何帮助高效地排除网络故障、识别异常并解决传统日志分析和基本流量捕获可能会遗漏的问题。

一、问题描述

VoIP 网络容易受到各种问题的影响，从而影响服务质量。典型的用户投诉可能涉及无法向外部号码拨出电话，这可能会迅速升级为高优先级支持问题。在这种情况下，必须高效地排除故障，尽快恢复服务。VoIP 管理员通常首先查看日志或通过 SPAN 端口执行基本的数据包捕获，然后进行手动分析，但这些方法不一定总能提供迅速解决问题所需的清晰度。

用户视角

从用户的角度来看，问题很明显：用户无法拨出外部号码。这让用户感到疑惑，并可能导致创建高优先级的支持票单。支持团队必须快速有效地做出响应，以避免进一步的中断。

日志视角

图 1：有 403 禁止但无详细 TCP 信息的日志视图

首次发现问题时，VoIP 管理员通常会首先查看受影响客户端的日志。在本例中，日志显示了从 PBX 到软电话的 SIP 403 “禁止 ”响应代码。此外，日志还暗示出现了身份验证错误，这促使管理员调查与 SIP 注册和身份验证相关的潜在原因。

在进一步调查后，管理员可能会发现注册数据似乎是正确的。但是，即使在验证注册过程正常运行后，403 响应仍然存在，这就促使他们进行更深入的调查。此时，管理员通常会捕获受影响呼叫期间的网络流量，以获得更多信息。

网络视角

网络级故障排除涉及捕获网络中相关点的流量，以观察 SIP 信令和 RTP 传输。此时，问题往往会变得更加复杂。VoIP 网络由多个相互连接的组件组成，包括 PBX、软电话、SBC（会话边界控制器）和 ITSP（互联网电话服务提供商）。

下一个挑战来自于 SIP 信令中的数据流与 RTP 流中的语音数据可能不同。为了有效捕获相关流量，管理员需要确保在正确的网络点进行捕获，包括软电话和 PBX、PBX 和 SBC 以及 SBC 和 ITSP 之间。

使用网络交换机 SPAN 端口的传统数据包捕获方法可能会成为瓶颈，影响捕获数据的准确性。具有在线捕获功能的 TAP 或捕获设备可以消除这一问题。不过，即使使用了正确的捕获工具，确定 SIP 403 消息的根本原因也可能既费时又复杂。

二、故障排除焦点：IOTA 如何改进 VoIP 根源分析

使用 IOTA 捕获流量

IOTA 解决了网络管理员在排除 VoIP 问题时面临的许多难题。通过提供实时流量捕获和分析，IOTA 允许管理员在受影响的呼叫期间高效地收集数据。它可在线部署在多个网段上，包括：软电话（softphone）和 PBX 之间；PBX 和 SBC 之间；SBC 和 ITSP 之间。

图2：用于排除故障的 IOTA 位置。

IOTA 能够捕获所有呼叫段（内部、DMZ 和外部）的流量，必要时甚至可以捕获 SPAN 端口的流量，从而确保全面覆盖整个通信流，帮助管理员找出问题所在。

分析 SIP 403 错误

捕获流量后，IOTA 的 VoIP 面板会提供 SIP 响应代码的详细概览。在 SIP 403 错误的情况下，管理员可以立即发现问题发生时这些响应代码频率的增加。通过将这些数据与之前呼出电话正常运行时的基线数据进行比较，管理员可以观察到信令模式中的任何显著差异，尤其是在呼叫失败前后。

图3：VoIP 面板

IOTA 的用户友好界面允许使用简单的下拉列表，根据发件人或收件人头中的 SIP URI 以及 VoIP/SIP Call-ID 或用户代理进行过滤。SIP 注册具有相同的发件人和收件人 URI，因此可以通过这种模式进行过滤。在我们的示例中，我们发现 SBC 在注册请求中发送的 VOIP_FROM_URI 没有后缀“;user=phone”，而在邀请请求中发送的 VOIP_FROM_URI 有后缀“;user=phone”，这在呼出呼叫中使用，因此我们可以在筛选器中区分它们。

图 4：通过 VOIP_FROM_URI 过滤器根据发件人中的 SIP URI 进行过滤。

之后，我们缩小了受影响电话的范围，从而更容易关注与 403 响应相关的具体问题。

图 5：按 VoIP 呼叫 ID 过滤。

深度数据包检测和 TCP 分析

对 VoIP 问题进行故障诊断的一个重要方面是检查捕获数据包的详细信息。在本例中，如果管理员查看 “概览 ”仪表板中的流量列表，就能发现 SIP 注册和 INVITE 请求使用 TCP 作为传输协议。这在 “协议栈 ”列中可见。

图 6：概览仪表板上有受影响调用的流量列表。

TCP 分析仪表板有助于更深入地检查 TCP 流量。乍一看，一切似乎都运行正常，因为所有 TCP 套接字都完成了 3 次握手，iRTT 也没有问题。

图 7：TCP 分析仪表板上的注册请求 TCP 流量。

图 8：TCP 分析仪表板上受影响通话的 TCP 流量。

随后，我们比较了来自 SIP 注册和 SIP 邀请的 TCP 流量。如图 7 和图 8 所示，IOTA 发现注册和呼叫设置请求（邀请）使用了不同的 TCP 源端口。进一步调查后发现，ITSP 拒绝未重复使用 TCP 会话的呼叫，这符合其特定的接口要求。这一发现对于诊断为什么会返回 403 响应至关重要。

三、利用可视化数据简化故障排除

传统的故障排除方法通常要求管理员筛选大量日志数据，寻找线索和不一致之处。IOTA 通过在其仪表板上提供可视化数据简化了这一过程，使管理员能够快速查看问题发生的位置以及需要进一步调查的内容。

例如，通过使用 IOTA 的 SIP 响应代码分析，管理员可以看到特定时间的 403 响应峰值，从而更容易找出根本原因。TCP 分析仪表板可帮助确定套接字的具体细节，如握手状态、iRTT 或源端口和目标端口。这种可视化方法能让用户更快地做出决策，并最大限度地减少故障排除所花费的时间。

四、使用 IOTA 进行 VoIP 故障排除的主要优势

提高采集的准确性：在网络的多个点高精度地采集数据有助于收集所有所需的数据，并确保不会忽略任何关键细节。在线和 SPAN 选项可在多种情况下提供帮助。如果在没有知识工作者的远程站点捕获流量，只需简单的硬件 “点击 ”即可启动，而无需任何知识。

更快、更高效的分析：IOTA 的实时和详细分析仪表板使管理员和分析人员能够快速发现问题，减少停机时间和服务中断。通过深度包检测和数据关联（如本例中的 SIP 和 TCP 流），IOTA 可帮助找出 SIP 403 响应等问题的根本原因，如错误配置的 TCP 流处理或身份验证不匹配。

基线分析：通过捕获流量模式使用 IOTA 进行基线分析，管理员和分析师可以将失败的流量模式与 “已知良好 ”的情况进行比较，从而发现问题。

结论

对 VoIP 网络问题进行故障排除是一项复杂而又耗时的任务，尤其是当用户因 SIP 403 错误而无法拨出电话时。通过将 IOTA 集成到故障排除流程中，网络管理员可以显著提高快速、准确地找出问题根源的能力。IOTA 能够捕获实时流量、分析 SIP 响应代码并检查 TCP 流量，为诊断 VoIP 问题提供了一种全面而有效的方法。最终，IOTA 可帮助简化故障诊断流程，减少停机时间，并确保 VoIP 服务保持正常运行，最大限度地减少中断。