Basic Telephony SIP End-to-End Performance Metrics
通过以上规范，运营用户还是终端用户都可以通过评价指标来说明SIP服务的性能，可以达到一个相对比较规范有数据说明的一个服务标准。虽然此规范不是一个强制规范，它可以实现对SIP性能的指标的量化，体现出科学性，而非使用非常空洞的市场语言。
下面，笔者根据RFC6076对整个SIP服务评价指标做一个完整说明，同时针对和SIP性能指标相关的一些要素做讨论，最后，根据IP网络研究人员的研究结合以上讨论来进一步说明性能指标的各种分享。
1关于SIP性能指标评价的背景说明
在语音通信领域，经过几十年的发展，结合互联网的带宽的逐渐提升，SIP语音已经被大部分运营商，软硬件产品和服务提供商和终端用户的接受。不像传统的PSTN网络，SS7有着自己的完整的规范经过这么多年的发展，因为SIP以前网络环境的差异，相互隔离和硬件差异，关于SIP评价服务方面，基于不同的部署环境，很多运营商，不同软硬件厂家都有各种不同的评价标准，有的用户以单一的物理硬件性能为基础来表示SIP的性能评价，有的用户以支持的最大并发数量作为一个SIP性能评价的标准，还有的用户以支持的最大注册用户为标准。因为在针对SIP性能评价方面没有统一的规范评价体系或者标准，因此，很多厂家和用户在部署使用过程中没有一个完整的规范标准来衡量SIP性能的评价，很多用户都对各种不同的性能评价指标产生了很多的误解和迷惑。
因此，对SIP性能评价做规范说明是一个势在必行的任务。RFC6076的目的就在于为通信行业中对运营商，软硬件厂家和终端用户提供一个基本的端对端的关于SIP性能指标规范说明。通过此规范，运营商可以对用户的服务提供一个可参考的SIP性能评价指标，以方便运营商为用户提供量化的数据来说明服务的水平。
在此评价指标中，涉及了各种外部的变量，但是以下几个方面的指标不在讨论范围之内，例如网络连接性，交换机和路由器的性能，服务器的处理能力和其他硬件资源的性能。这些指标都和真正的SIP性能评价本身没有直接联系，这些都是一些外部要素，而且基本上都是经常变化的，不可统一的指标。所以，这些指标不能作为衡量SIP性能的绝对指标。为了让读者了解更多关于SIP性能测试的一些相关性要素，尽管这些指标不是RFC6076的评价标准，笔者仍然打算在后续的文章中针对这些外部要素做一点分享，其目的是完整了解其他相关指标，这些指标可能一些SIP应用的性能。
2关于两种定时器的说明
在RFC6076中，针对SIP评价指标的报告是基于两个非常重要的SIP定时器为基准的。在此规范中，很多的评价标准是通过时钟周期设置来核定两个事件之间的不同。这里，我们主要涉及两个重要的定时器，T1和T4定时器。具体关于T1的定义讨论建议读者历史文档来查看。
浅析SIP响应消息100 Trying的作用和传输机制
关于T1和T4的基本定义如下：
| Attribute | 默认值设置 | 描述 |
| t1-in-millis | 500 | T1 is an estimate of the round-trip time (RTT). Nearly all of the SIP transaction timers scale with T1, and changing T1 adjusts their values. |
| t4-in-millis | 5000 | T4 represents the amount of time the network takes to clear messages between client and server transactions. |
这里简单说明一下，T1是一个启动时间，T4是一个事务的结束时间，触发T4定时器表示在请求发送端的SIP应用收到了响应数据中最后一bit数据。
除了T1和T4的定义以外，在各种网络之间还存在一个和具体时间相关的一个时钟问题。如果时钟计算不同步的话，可能会出现时间戳不正确，评价标准也可能出现其他的误差，因此这里还涉及到了一个偏移计算的问题。关于时钟的偏移和T1定时器不同以及影响到时间计算的规范，读者可以查阅RFC2330。如果计算T1和T4定时器必须要有一个稳定的准确的时钟来保证其准确性，除了保证时钟源的准确性以外，还要考虑到其他因素，包括同步响应可能对本地时钟的操作，使用一个自由时钟进行基准时钟设置，或者通过物理操作读取时钟时的错误等都会引起T1和T4定时器的错误，这些错误就会影响到T1和T4之间的时间戳错误或者地址延迟。
3RFC6076中关于SIP九大评价指标详解
在RFC6076中，关于SIP评价标准有以下几个不同的参数值，笔者将根据规范为读者详细说明这些评价标准的定义和相关设置。以下图例简单说明了几个注册呼叫时延的计算方式流程。
此图例和以下图例均来自于互联网资源
3.1-注册请求时延-Registration Request Delay （RRD）-从这里的字面意思我们就可以看到，这个时延是基于注册请求来计算的。RDD用来衡量注册请求返回响应的时延时间。RDD是一个相对于注册请求成功的时延结果。接下来的（IRAs）则是一个注册请求失败的结果。计算公式为：
RRD = Time of Final Response - Time of REGISTER Request
具体来说，从由UA发起方发送的初始请求消息的第一个bit数据算起，到此UA收到最后一个200 OK的bit结束之间的时间。此交互过程中包含请求认证的过程处理。具体示例如下：
3.2-无效注册测试比率-Ineffective Registration Attempts （IRAs）：IRAs用来检测注册失败或者缺陷的比率，主要针对UA到注册服务器的注册能力检测。IRAs主要在UA端进行检测。计算方式如下：
其结果等于失败注册次数和总注册请求次数之间的百分比率。读者都知道，失败返回的信息包括了4xx和5xx，甚至于6xx的返回消息。失败的注册通过几次尝试，或者定时器超时最后获得一个IRAs结果。
3.3-会话请求时延-Session Request Delay （SRD），SRD包括两种时延，一种是会话请求成功时延-Successful Session Setup SRD和相反的会话请求失败时延-Failed Session Setup SRD。SRD用来检测返回失败或者缺陷导致的对UA响应的时延。其计算公式为：
SRD = Time of Status Indicative Response - Time of INVITE
在会话请求成功的时延中，SRD是这样定义的，初始UA发送了初始请求的第一个bit数据到对端代理后，直到收到最后一个bit，其会话显示创建请求的成功。其SRD包括了1xx临时响应和302的响应处理时延。
在会话请求失败的时延中，SRD是这样定义的，初始UA发送了初始请求的第一个bit数据到对端代理后，直到收到最后一个bit，其会话显示创建请求的成功。其SRD包括了4xx临时响应和5xx或者6xx的响应处理时延。
3.4-会话关闭时延-Session Disconnect Delay （SDD），SDD是用来检测失败或者缺陷导致的时延来结束或者关闭会话的时间。它可以检测会话关闭成功时间和会话关闭失败时间，会话双方的代理端都可以检测其时延。SDD具体的计算公式如下：
SDD = Time of 2XX or Timeout - Time of Completion Message （BYE）
SDD主要用来检测例如BYE消息相关的200 OK回复的时间时延，双方UA都可以支持SDD检测：
如果读者以前阅读过笔者历史文档的时候，读者可能注意到了，我们曾经针对计费问题对SDD做了具体的讨论。
OpenSIPS学习笔记-ACC模块/事务-CDR记录以及BYE消息丢失-呼叫会话关闭时延影响计费和配置示例
如果读者有兴趣了解关于CDR计费的问题的话，可以查阅此链接。
3.5-会话总长-Session Duration Time （SDT）， 包括Successful Session Duration SDT和Failed Session Completion SDT。SDT的作用是检测因为会话时间不正常导致的语音质量问题。SDT可以检测在一个dialog中双方UA的SDT问题。SDT具体的计算公式如下：
SDT = Time of BYE or Timeout - Time of 200 OK response to INVITE
同样，SDT也分为成功时长和失败时长两种计算方式。在失败时长计算中包括了一个F定时器时延的处理。
3.6-会话创建比率-Session Establishment Ratio （SER）-SER是用来检测UA终端和下游终端之间在每个新会话请求中会话创建的成功比率。此检测只能在UA端进行检测。其计算公式如下：
SER和Answer Seizure Ratio（应答率）非常相似，表示一个总呼叫量和成功应答呼叫之间的比率。
3.7-会话创建有效比率Session Establishment Effectiveness Ratio （SEER），SEER是和SER有互补关系，但是，SEER排除了一些潜在的目标UA用户的影响。SEER定义为INVITE/200 OK相关的呼叫总数和INVITE/480，486，600或者603相关的呼叫总数在总呼叫数中的占比。因为480，486等几个回复需要非常清晰地表示了个体UA端的效应，例如可能UA的错误设置。另外，回复响应码如果是401，407或者420则不在此计算范围之内。其计算公式如下：
SEER呼叫流程实例和SER类似。这里不再列出。
3.8-无效会话尝试-Ineffective Session Attempts （ISAs）比率，ISAs用来表示因为代理或者agent失败或者过载情况发生后内部释放了一个已创建的请求。回复响应码可能包括408，500，503或者504。这里，可能是代理的下游网络出现过载状态后返回的408响应。其具体计算公式如下：
代理2发现了UA2可能出现了过载状态，返回408响应，记为一次无效会话尝试。
3.9-会话完成比率-Session Completion Ratio （SCR），SCR用来表示一个完整的dialog中无任何失败，这些失败可能是因为缺少来自于代理或者UA的响导致的失败，是会话成功完成和总会话之间的比率。SCR和Call Completion Ratio （CCR）-呼叫完成率类似。其计算公式为：
SCR呼叫流程如下：
如果读者有兴趣的话可以参考RFC3665，在此规范中定义了各种SIP创建成功和失败的呼叫流程的细节。这里不再展开讨论。
4SIP评价标准数据处理相关因素讨论
前面的章节笔者讨论了关于SIP评价指标的具体细节。根据RFC6076规范，这些评价标准和具体的其他要素也存在一定的依赖关系，读者需要注意。
在这些要素中，一些SIP头域值需要读者做更多了解，例如：
- To "user"
- From "user"
- 双向的 "user"
- To "domain"
- From "domain"
另外，B2BUA也是一个重要的要素，它根据处理流程的需要可能充当UAS或者UAC，另外也可能充当一个代理的角色。它需要采集不同方向的数据。
签权和认证也是需要考虑到因素。因为在dialog处理流程中可能需要认证机制，因此可能出现认证失败的处理响应。这些响应也需要考虑在评价标准中。
Forking分叉呼叫处理是SIP常见的一种呼叫场景，在分叉呼叫中也需要针对不同的回复需要分别对呼叫进行分类计算，此计算方式根据分叉呼叫发生的点点不同来计算。特别需要注意的是SRD的计算。
在计算SIP评价标准时，采集的数据可能来源于不同的数据存储方式中，例如通过CDR中来计算或者其他的数据库，这些数据需要进行同步处理，保证其数据的准确性。另外一些数据可能在其他的上下游代理或者UAS服务器端，在SIP评价标准的计算时也需要通过集中处理，保证数据的统一性。评价标准的数据传输可以通过SNMP，MIB（RFC4780）或者事件订阅方式（RFC3265）来传输。
5关于影响性能评价指标的其他因素讨论
我们在前面的章节讨论了几个SIP性能的评价指标和RFC6076中提到的其他相关的要素，除了以上这些要素以外，笔者这里再补充说明一些相关要素。这些要素的讨论是为了让读者更加了解这些要素如何影响SIP评价指标。非常重要的一个指标就是延迟（Delay）。Delay包括各种方式的延迟，包括IP网络延迟和终端延迟：
- Propagation delay：物理距离和中间代理路径的延迟。
- Transmission delay：传输产生的延迟
- Nodal Processing delay：路由设备的处理延迟
- Queuing delay：代理服务器查询延迟
- Codec delay：终端编码延迟
- Packetization delay：打包延迟
- Playout buffer delay：缓冲处理延迟
以上延迟因为物理性能或者转换打包时长不同都会导致不同的延迟，当然也会导致各种语音问题，例如抖动，丢失语音包等问题。笔者通过不同的示例来介绍目前部分典型环境中导致的各种延迟和影响SIP 评价标准的要素。
通过以下示例笔者可以看到，在MOS的评测中因为时延会产生很多的问题，当然，这些时延也可能引起请求注册等方面的问题，最后导致时延。
除了纯SIP网络的注册流程以外，在目前的IMS网络环境中，关于SIP时延的讨论也很多。读者需要特别注意RRD（注册请求时延）的时间跨度：
一些研究人员针对LTE网络环境中AMR编码等要素做的一些研究，这些要素最后导致LTE网络的拥塞也是非常需要关心的。当然，因为网络拥塞也会导致MOS问题。
很多时候，SIP消息生成过多也同样会导致时延。Jasmina发表的研究论文-Studying the Impact of SIP Message Differentiation on the Quality of VoIP Session Control Procedures提到了SIP消息的不同对语音质量和时延带来的问题。SIP消息生成如果导致了过高负载的话，也产生了前面我们所讨论的评价标准的时间延迟。他通过不同在SIP消息生成中采用不同算法优先级来（SIPPRIO package）优化过高负载降低SIP消息生成带来的系统压力。具体测试结果和SIP评价标准（RRD, SRD, 和 SDD）相关性如下：
如果我们具体到比较简单的语音环境中，SIP网络架构当然也会影响SIP 评价标准的数据质量。网上有很多测试结果，读者可以查阅。这里，笔者分享MIROSLAV发表的关于SIP Infrastructure Performance Testing的一篇研究论文。在其论文中，通过不同CPU资源，结合不同的编码，对RRD和SRD所产生的不同的影响。笔者提供此示例的目的是针对一般企业用户，或者中小型用户可以通过此配置示例对SIP评价标准进行一定的测试，也方便用户对测试环境的完善做一个补充。
更为简单的场景中，读者可以通过简单SIP注册进行压力测试，对RRD进行评价。例如， Miroslav发表的SIP Registration Stress Test对比不同版本Asterisk支持的RRD状态：
当然，如果在洪水攻击的环境中或者在实际生产环境中，如果被攻击以后，INVITE和各种后续请求等生成时延都会随着数据包不断增加时延也会随着增加。因此，用户在部署基于云平台或者无安全保障的前提下，一定要注意这些数据的变化，因为这些SIP 评价标准的数据也导致了语音质量的问题，包括抖动，语音丢失等问题。Santosh Kumar发表的研究论文中对各种延迟结合SIP请求，BYE或者Options消息等环境中做的测试，这些测试数据也影响了语音时延，抖动，语音丢失等问题，严重影响了SIP评价标准的数据。
目前比较新的技术就是使用SD-WAN，我们称之为绿色VOIP网络。SD-WAN有很多目前网络部署场景所不具备的优势，完全灵活实现了SIP网络的部署，优化了传输速度和稳定性。因此，通过SD-WAN可以降低很多的时延。Ahmadreza发表的研究论文通过对绿色VOIP部署的测试所得出的研究结果，其结果对SIP时延优化有极大的帮助，希望读者能够引起重视。
6总结
笔者在本文章中重点介绍了关于SIP评价标准RFC-6076的9大评价标准，通过一定的比较知识介绍，结合具体的SIP 评价标准和其格式以及呼叫流程对各种指标进行了详细说明。另外，笔者针对计算评价标准的其他因素也做了一点说明。最后，笔者根据以上RFC6076规范中说明的数据，对关于生成延迟的时间和各种测试做了比较完善的补充介绍，帮助读者能够完整了解这些时延产生的原因和对语音质量的影响。在一些比较新的研究论文中，突出介绍了环境部署对SIP性能的影响，网络，编码和技术架构部署，包括最新SD-WAN等技术的部署介绍。
因为笔者能力所限，有一些其他方面的时延内容没有做具体讨论，例如AMR编码的影响，各种开源媒体服务器中配置的优化和利用SBC部署方式的优化等。如果有时间的话，笔者在后续的文章中会逐一补充。
参考资料：
https://tools.ietf.org/html/rfc6076
https://tools.ietf.org/html/rfc2330#section-10.1
https://tools.ietf.org/html/rfc3665
Santosh Kumar，Effectiveness of SIP Server Under SIP Flooding Attack During VoIP Calls
Ahmadreza，Green Cloud Multimedia Networking: NFV/SDN
Based Energy-Efficient Resource Allocation
www.asterisk.org.cn
www.freepbx.org.cn
www.rbbn.cn 世界级SIP/SBC 解决方案
