通过IP协议传输语音在企业网络和提供商环境中都带来了各种挑战。首先，存在非常高的可用性要求。但是，作为实时服务，用户也会立即注意到服务质量上的问题。特别是数据包丢失、抖动和延迟等网络质量参数对最终的语音质量有重大影响。
在VoIP环境中，重要的是要注意有三个数据流，其中两个对用户有明显的影响。
第一个数据流是信令。信令指的是设置和拆除的通信，以及变化。在这个过程中，值得保护的元数据，如来源和目的地号码，也被传输。有不同的信令协议，如SIP（会话初始协议）、H.323或MGCP（媒体网关控制协议）。在公共网络和目前的企业网络中，主要使用SIP协议。然而，有大量不同的SIP实现方式。在实践中，由于不兼容，这导致了各种错误源。在信令有效载荷中，或者更准确地说，在会话描述协议（SDP）中，一些参数，如要使用的编解码器和UDP端口，以及用于语音数据传输的相关IP地址，也被协商确定。
第二个数据流是通过实时传输协议（RTP）传输的语音。该协议基于UDP传输，作为一种实时传输，它对延迟、抖动和丢包特别敏感。这里可以使用不同的编解码器，有不同的打包时间、大小和质量。
第三个数据流是实时传输控制协议（RTCP）。它为VoIP提供带有质量指标的统计数据。这个数据流在与RTP相同的传输路径上流动，但端口号要高一个。
排除VoIP环境故障的一个主要挑战是区分信令和语音数据甚至是底层网络之间的错误原因。在许多情况下，不同的媒体流还必须通过NAT转换或安全组件（如防火墙）。在实践中，这导致负责VoIP、网络和安全的团队在发生错误时来回洗刷相关的票据。
Profitap IOTA已将使VoIP分析有效和高效作为其使命。不同团队之间的 “指责游戏 “将通过图形化的仪表盘与SIP和RTP的不同过滤选项相结合而结束，并通过快速错误分析缩短最终用户的平均恢复时间（MTTR）。因此，服务提供商也可以更好地满足他们的SLA。
VoIP网络中的根本原因分析
VoIP网络中的根本原因分析往往就像在干草堆中寻找一根针。用户通常会提出相当无序的错误信息，如 “我的电话昨天停止工作。我总是得到一个忙音信号 “或 “我在通话过程中出现了间歇性的通信问题”。这到底是由于网络、防火墙、SIP代理的信号错误，还是终端设备的错误，一开始很难区分。单向或完全没有通信（单向音频或死机效应）和间歇性掉线也是故障排除过程中的一个挑战。因此，确定问题的根本原因很重要。
如果关键性能指标数据包丢失、抖动和延迟是双向的，没有任何异常，就可以排除安全和网络问题。然后可以直接在VoIP环境中寻找原因。然而，并不是每个VoIP连接都可以直接测量端到端。所谓的会话边界控制器（SBC）可以在安全转换时终止和操纵每个通信方的SIP对话和RTP数据流。因此，可能发生的情况是，尽管测量到的数据包损失为其SBC后面的供应商的0%，但有一个数据包损失到另一个供应商。这意味着VoIP分析往往需要在网络中的多个点进行。
在VoIP环境本身，首先必须确定问题是在信令还是在语音数据流中。如果在连接建立/终止时或在呼叫保持或编解码器改变时出现问题，这是由信令问题引起的，可以用过滤器来隔离SIP数据中的问题。
分析起来更具挑战性的是错误模式，如死机和单向音频。这些可能来自网络，但也可能来自防火墙和IPS系统或VoIP系统的模块问题。网络错误的一个例子是错误的路由或NAT转换。在VoIP的背景下，NAT的问题是只有IP信息在头中被替换，而在有效载荷中没有。然而，SIP在会话描述协议（SDP）中传输了RTP流的IP和端口信息。现在，如果NAT转换操作了IP头，但没有在有效载荷中进行调整，这将导致单向或无通信，因为RTP流将被路由到错误的目的地。
同时，还有一种可能，即防火墙允许用于信令的端口，但阻断RTP数据流。但入侵防御系统也为被阻止的RTP数据流提供了一个可能的错误来源。但与此同时，在VoIP环境中，这也可能是由于只有SRTP的单边加密或编解码器的故障开关，或有缺陷的VoIP模块，如DSP。因此，为了进行根本原因分析，需要一个可以在网络的不同点上灵活使用的工具，并能以简单的手段 “深入 “到所需的信息。
Profitap IOTA能提供什么帮助？
Profitap IOTA为VoIP分析提供了一个便携式的解决方案。这使得它适合在网络的不同点进行记录和分析。
在线和SPAN模式操作都是可能的，这使得它成为VoIP分析的灵活工具，因为它可以在电话和交换机之间以在线模式连接，也可以直接在交换机的SPAN端口连接。例如，当必须分析整个VLAN或通往会话边界控制器或IP PBX的交换机端口时。
然而，除了纯粹的记录之外，IOTA还提供VoIP的应用端分析功能。这意味着，网络和语音团队之间的指责可以迅速结束。网络管理员可以检测定义时间段或甚至是特定呼叫的数据包丢失和抖动。这可以通过对呼叫者的来源或目的地URI进行过滤来实现。
如果VoIP管理员甚至通过呼叫的呼叫ID，对呼叫的过滤可以直接进行。通过这种方式，可以对错误进行预鉴定，以至于可以搜索交换机和路由器等单个网络组件上的链接错误和服务质量问题。下图提供了一个关于目的地URI的过滤器的例子
使用这个过滤器，可以得到一个到这个目标URI的呼叫列表。
对于RTP数据流中的语音数据传输的质量问题，IOTA提供了多种选择。例如，有一个准备好的呼叫细节仪表板，分别显示主叫方和被叫方的抖动和丢包量。数据包丢失的显示既显示了数据包总数的百分比，也显示了丢失数据包的纯量。除了清晰的图形外，还可以用”>=”的过滤器。这样，丢包和抖动超过某些阈值的呼叫，如抖动>=20ms，可以被过滤掉。
图形界面中的点击和拖动功能提供了在检测到异常情况下具体跳入一个时间范围的可能性。一个简单的点击和拖动就足以限制时间范围。如果网络分析员在呼叫详情仪表板中检测到与传输的数据包相比有很高的数据包丢失比例，他可以识别呼叫ID，并在过滤器中使用它们来识别有问题的通信关系。例如，如果对死机效应的分析反复引向一个特定的端口范围，那么，防火墙清除的缺失或不足可能是原因。
这为快速预审VoIP环境中的通信问题票提供了可能。IOTA通过各种过滤选项，可以越来越紧密地缩小错误范围，以达到问题的 “根本原因”。
IOTA在信令错误方面也提供了很多。为了能够识别信令错误的模式，图4所示的VoIP仪表板的图形 “SIP方法和响应 “是有用的。如果 “488这里不接受 “越来越明显，这将表明编解码器的不兼容，例如。另一方面，如果出现 “403 “错误代码，SIP代理会拒绝请求。在 “404 Not found “消息增加的情况下，人们可以专门看一下VoIP仪表板中的受话者URI，以确定错误的目标号码或目标域。在图4的例子中，一些403响应是可见的。这些是由于使用了SIP认证，因此是完全正常的。
在呼叫建立延迟的情况下，信令的延迟数据也可以提供一些见解。对于通过TCP的SIP，往返时间提供了第一个起点。IOTA也可以对此进行分析。
对于更复杂的情况，PCAP数据也可以专门下载，以便在Wireshark中进行仔细分析。例如，使用未加密的RTP和支持的编解码器，可以在RTP播放器中收听录制的音频内容，以获得独立于电话的语音质量印象。甚至可以将PCAP文件自动导出到外部数据源。
