1)实践是检验真理的唯一标准
2)事实胜于雄辩
为了实现MOS的指标测试,我提供了以下几个方面的内容,读者可以结合这些概念和具体的测试手段,基本上可以集成一套比较专业,相对完整的语音检测整体解决方案。这里,我仅大概介绍MOS的基本概念,R-Factor,E-Model和rfc3611,以及开源工具的安装和功能做一个完整的介绍。
1) 为什么使用MOS和其相关的检测工具
1.1)集成商厂家为了保证其兼容性,需要相对比较标准的衡量指标
1.2)MOS相对比较主观,很难客观反映真实的具体的用户数据。具体关于 MOS的概念用户可以查阅我以前的文档和其他权威文档。
1.3)需要对软交换中的每个SIP终端,网关进行全面覆盖监控。因为在实际生产环境中,一个软交换可能注册了成百上千个终端,这些终端发布在不同的网络环境,终端本身来自于不同的硬件厂家。如何对每一台终端进行实时数据监控是一个非常大的挑战,如果没有测试工具几乎不可能完成。
1.4)基于云平台的分布式部署托管平台需要专业的检测工具。分布式部署环境下的监控工具是一个MUST。运营商的SIP终端通过检测工具的支持,可以对每一台不同环境下的SIP终端进行实时监控,方便了运营商排查问题,也提供了及时有效的用户支持和体验。通过这些方法可以有效实现对SIP终端的检测,帮助用户排查问题,同时为集成商提供对SIP终端的有效的实时报告。
1.5)MOS相对比较主观,R-Factor是相对比较客观的指标。
因为大部分的MOS测试结果是通过对用户进行调查获得的结果。用户调查本身存在很多用户的主观因素,特别是在我们博大精深的中华文化中,“好,很好”是一个什么概念,最终可能也得不到一个真实的数据。这些主观因素可能导致MOS缺乏真实性。相当于MOS来说,R-Factor是相对客观的指标,它和MOS具有某种习惯性,事实上就是MOS指标的量化。通过对R-Factor的测试,用户可以获得比较真实统计数据。具体的两者之间的关系如下所示:

2)影响语音质量的的主要因素和衡量指标
影响语音质量的指标很多,目前,在VOIP的标准中,大部分的用户还是使用经常讨论的几个指标来衡量其语音质量。这三个指标分别是:Jitter, PL和时延。
2.1)影响语音质量的指标和建议值:
- Jitter <20ms
- Packet Loss< 0%
- Latency <150ms
以上三个指标取决于很多网络的相关因素,这些因素包括终端的编码,服务器转码,网络带宽,路由器设置和QOS和其他R-Factor所提到的参数。关于优化这些指标,笔者在以前的文档中也做过充分的讨论,读者可以查阅。关于完整R-Factor的解释,用户可以查阅 Recommendation G.107。以下图例介绍了如何计算R-Factor的介绍和实际使用环境中,在每一个流程中可能产生上述原因的节点。

2.2) R-Factor和E-Model的关系
在实际的R-Factor的计算中,其取值是通过一个E-model 来计算的。基本的计算格式如下:

以下所描述的是在实际网络环境中,影响三个参数的关键节点。当然,因为目前的互联网技术不断发展,特别是云平台和SDN的相关网络的发展也可能导致更多的影响因子。因此,用户必须注意这些要素的影响。

通过E-Model的计算,用户可以得到最终的R值。

3) 通过检测工具对语音质量进行监控跟踪
目前,网上有很多检测工具来排查语音质量,开源的工具也很多,例如Wireshak,sngrep, ngrep等工具。但是这些终端排查工具只能针对单一终端设备进行排查。如何对批量终端进行监控排查是一个非常大的问题。

4)使用RTCP-XR来获得RTP数据
在上面的介绍中,我们看到,其他的终端工具很难收集到大批量终端的比较完整的RTP数据。RTP Control Protocol Extended Reports (RTCP XR) 可以支持RTP数据的控制,通过RTCP-XR协议的支持,集成商可以轻松监控网络中所有支持RCTP-XR的终端。这是一个yealink SIP的截图。用户可以配置对RTCP-XR 服务器端的支持,推送相关的RTCP数据到相应的第三方RTCP服务器端。关于RTCP-XR的协议,读者可以查阅RFC3611来获得详细说明。

一些厂家的SIP终端支持了RTP-RxStat,P-RTP-Stat,RTCP Extended Report和 X-RTP-Stat。笔者从网上简单从几个官方网站搜索了一下,yealink和汉隆SIP话机声明支持了RFC3611,其他厂家的好像没有看到具体的解释。以下是SIP终端开启了P-RTP-Stat的Publish消息:

5)开源软交换和媒体服务器对RTCP-XR的支持
目前,很多集成商都基于Asterisk或者FreeSWITCH开发自己的IPPBX或者呼叫中心,并且部署方式也发生了很大的变化,从本地部署到基于云平台部署等解决方案。但是,这些软交换都缺乏一个对RTCP-XR的支持监控模块。Homer是一个非常强大的开源VOIP 检测工具。它可以帮助技术人员排查技术问题,同时又可以实现对SIP终端的数据进行监控。


Homer 可以通过模块的方式支持Kamailio,OpenSIPS,Asterisk和FreeSWITCH。它可以通过HEP/EEP采集器的方式获取到软交换的RTCP-XR消息,然后通过界面来显示这些实时数据。在Asterisk-12 以上版本,添加了一个HEP模块(res_hep_pjsip.so),用户可以配置hep.conf 文件来实现Homer对Asterisk的支持。配置文件示例如下:
/etc/asterisk/hep.conf
;
; res_hep Module configuration for Asterisk
;
; All settings are currently set in the general section.
[general]enabled = yes ; Enable/disable forwarding of packets to a
; HEP server. Default is "yes".
capture_address = 10.0.0.1:9060 ; The address of the HEP capture server.
capture_password = foo ; If specified, the authorization passsword
; for the HEP server. If not specified, no
; authorization password will be sent.
capture_id = 1234 ; A unique integer identifier for this
; server. This ID will be embedded sent
; with each packet from this server.
在FreeSWITCH -1.6.8 以上版本,开发人员也实现了对Homer的支持。用户可以通过命令配置来实现Homer的支持:
在sofia.conf.xml 文件配置:
在 internal.xml 文件配置:
关于Homer 和Kamailio,OpenSIPS的对接,用户可以查看Homer的官方文档链接。
除了Homer以外,还有一个开源的采集工具是RTCP-XR Collector,用户可以参考,是否可以集成到自己的语音平台。

在本章节中,我们讨论了关于使用MOS来评价SIP话机的语音质量的问题,也介绍了和MOS相关的R-Factor,以及E-Model的计算公式,然后有介绍了RTCP-XR 协议Rfc3611,以及如何使用开源工具Homer来采集RTCP-XR报告数据。这些数据看起来仅是报表数据,实际上对运营商和技术人员有非常大的帮助,同时也为SIP终端或者网关厂家能够真实客观地看到在实时网络环境中终端产品的性能表现,在面对客户时可以提供有效的数据来说服客户,以体现出真正的专业销售水平,让用户觉得现在的产品是可信赖的产品。
参考资料:
https://www.voicehost.co.uk/help/call-quality-r-factor-and-mos
https://www.itu.int/ITU-T/studygroups/com12/emodelv1/tut.htm
https://www.itu.int/rec/T-REC-G.107
http://sipcapture.org/#features-icons
https://github.com/mixja/rtcpxr-collector