Basic Telephony SIP End-to-End Performance Metrics

　　通過(guò)以上規范，運營(yíng)用戶(hù)還是終端用戶(hù)都可以通過(guò)評價(jià)指標來(lái)說(shuō)明SIP服務(wù)的性能，可以達到一個(gè)相對比較規范有數據說(shuō)明的一個(gè)服務(wù)標準。雖然此規范不是一個(gè)強制規范，它可以實(shí)現對SIP性能的指標的量化，體現出科學(xué)性，而非使用非常空洞的市場(chǎng)語(yǔ)言。

　　下面，筆者根據RFC6076對整個(gè)SIP服務(wù)評價(jià)指標做一個(gè)完整說(shuō)明，同時(shí)針對和SIP性能指標相關(guān)的一些要素做討論，最后，根據IP網(wǎng)絡(luò )研究人員的研究結合以上討論來(lái)進(jìn)一步說(shuō)明性能指標的各種分享。

　　在語(yǔ)音通信領(lǐng)域，經(jīng)過(guò)幾十年的發(fā)展，結合互聯(lián)網(wǎng)的帶寬的逐漸提升，SIP語(yǔ)音已經(jīng)被大部分運營(yíng)商，軟硬件產(chǎn)品和服務(wù)提供商和終端用戶(hù)的接受。不像傳統的PSTN網(wǎng)絡(luò )，SS7有著(zhù)自己的完整的規范經(jīng)過(guò)這么多年的發(fā)展，因為SIP以前網(wǎng)絡(luò )環(huán)境的差異，相互隔離和硬件差異，關(guān)于SIP評價(jià)服務(wù)方面，基于不同的部署環(huán)境，很多運營(yíng)商，不同軟硬件廠(chǎng)家都有各種不同的評價(jià)標準，有的用戶(hù)以單一的物理硬件性能為基礎來(lái)表示SIP的性能評價(jià)，有的用戶(hù)以支持的最大并發(fā)數量作為一個(gè)SIP性能評價(jià)的標準，還有的用戶(hù)以支持的最大注冊用戶(hù)為標準。因為在針對SIP性能評價(jià)方面沒(méi)有統一的規范評價(jià)體系或者標準，因此，很多廠(chǎng)家和用戶(hù)在部署使用過(guò)程中沒(méi)有一個(gè)完整的規范標準來(lái)衡量SIP性能的評價(jià)，很多用戶(hù)都對各種不同的性能評價(jià)指標產(chǎn)生了很多的誤解和迷惑。

　　因此，對SIP性能評價(jià)做規范說(shuō)明是一個(gè)勢在必行的任務(wù)。RFC6076的目的就在于為通信行業(yè)中對運營(yíng)商，軟硬件廠(chǎng)家和終端用戶(hù)提供一個(gè)基本的端對端的關(guān)于SIP性能指標規范說(shuō)明。通過(guò)此規范，運營(yíng)商可以對用戶(hù)的服務(wù)提供一個(gè)可參考的SIP性能評價(jià)指標，以方便運營(yíng)商為用戶(hù)提供量化的數據來(lái)說(shuō)明服務(wù)的水平。

　　在此評價(jià)指標中，涉及了各種外部的變量，但是以下幾個(gè)方面的指標不在討論范圍之內，例如網(wǎng)絡(luò )連接性，交換機和路由器的性能，服務(wù)器的處理能力和其他硬件資源的性能。這些指標都和真正的SIP性能評價(jià)本身沒(méi)有直接聯(lián)系，這些都是一些外部要素，而且基本上都是經(jīng)常變化的，不可統一的指標。所以，這些指標不能作為衡量SIP性能的絕對指標。為了讓讀者了解更多關(guān)于SIP性能測試的一些相關(guān)性要素，盡管這些指標不是RFC6076的評價(jià)標準，筆者仍然打算在后續的文章中針對這些外部要素做一點(diǎn)分享，其目的是完整了解其他相關(guān)指標，這些指標可能一些SIP應用的性能。

　　在RFC6076中，針對SIP評價(jià)指標的報告是基于兩個(gè)非常重要的SIP定時(shí)器為基準的。在此規范中，很多的評價(jià)標準是通過(guò)時(shí)鐘周期設置來(lái)核定兩個(gè)事件之間的不同。這里，我們主要涉及兩個(gè)重要的定時(shí)器，T1和T4定時(shí)器。具體關(guān)于T1的定義討論建議讀者歷史文檔來(lái)查看。

　　淺析SIP響應消息100 Trying的作用和傳輸機制

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.

　　這里簡(jiǎn)單說(shuō)明一下，T1是一個(gè)啟動(dòng)時(shí)間，T4是一個(gè)事務(wù)的結束時(shí)間，觸發(fā)T4定時(shí)器表示在請求發(fā)送端的SIP應用收到了響應數據中最后一bit數據。

　　除了T1和T4的定義以外，在各種網(wǎng)絡(luò )之間還存在一個(gè)和具體時(shí)間相關(guān)的一個(gè)時(shí)鐘問(wèn)題。如果時(shí)鐘計算不同步的話(huà)，可能會(huì )出現時(shí)間戳不正確，評價(jià)標準也可能出現其他的誤差，因此這里還涉及到了一個(gè)偏移計算的問(wèn)題。關(guān)于時(shí)鐘的偏移和T1定時(shí)器不同以及影響到時(shí)間計算的規范，讀者可以查閱RFC2330。如果計算T1和T4定時(shí)器必須要有一個(gè)穩定的準確的時(shí)鐘來(lái)保證其準確性，除了保證時(shí)鐘源的準確性以外，還要考慮到其他因素，包括同步響應可能對本地時(shí)鐘的操作，使用一個(gè)自由時(shí)鐘進(jìn)行基準時(shí)鐘設置，或者通過(guò)物理操作讀取時(shí)鐘時(shí)的錯誤等都會(huì )引起T1和T4定時(shí)器的錯誤，這些錯誤就會(huì )影響到T1和T4之間的時(shí)間戳錯誤或者地址延遲。

　　在RFC6076中，關(guān)于SIP評價(jià)標準有以下幾個(gè)不同的參數值，筆者將根據規范為讀者詳細說(shuō)明這些評價(jià)標準的定義和相關(guān)設置。以下圖例簡(jiǎn)單說(shuō)明了幾個(gè)注冊呼叫時(shí)延的計算方式流程。

　

　　此圖例和以下圖例均來(lái)自于互聯(lián)網(wǎng)資源

　　3.1-注冊請求時(shí)延-Registration Request Delay （RRD）-從這里的字面意思我們就可以看到，這個(gè)時(shí)延是基于注冊請求來(lái)計算的。RDD用來(lái)衡量注冊請求返回響應的時(shí)延時(shí)間。RDD是一個(gè)相對于注冊請求成功的時(shí)延結果。接下來(lái)的（IRAs）則是一個(gè)注冊請求失敗的結果。計算公式為：

　　RRD = Time of Final Response - Time of REGISTER Request

　　具體來(lái)說(shuō)，從由UA發(fā)起方發(fā)送的初始請求消息的第一個(gè)bit數據算起，到此UA收到最后一個(gè)200 OK的bit結束之間的時(shí)間。此交互過(guò)程中包含請求認證的過(guò)程處理。具體示例如下：

　　

　　3.2-無(wú)效注冊測試比率-Ineffective Registration Attempts （IRAs）：IRAs用來(lái)檢測注冊失敗或者缺陷的比率，主要針對UA到注冊服務(wù)器的注冊能力檢測。IRAs主要在UA端進(jìn)行檢測。計算方式如下：

　　其結果等于失敗注冊次數和總注冊請求次數之間的百分比率。讀者都知道，失敗返回的信息包括了4xx和5xx，甚至于6xx的返回消息。失敗的注冊通過(guò)幾次嘗試，或者定時(shí)器超時(shí)最后獲得一個(gè)IRAs結果。

　　

　　

　　3.3-會(huì )話(huà)請求時(shí)延-Session Request Delay （SRD），SRD包括兩種時(shí)延，一種是會(huì )話(huà)請求成功時(shí)延-Successful Session Setup SRD和相反的會(huì )話(huà)請求失敗時(shí)延-Failed Session Setup SRD。SRD用來(lái)檢測返回失敗或者缺陷導致的對UA響應的時(shí)延。其計算公式為：

　　SRD = Time of Status Indicative Response - Time of INVITE

　　在會(huì )話(huà)請求成功的時(shí)延中，SRD是這樣定義的，初始UA發(fā)送了初始請求的第一個(gè)bit數據到對端代理后，直到收到最后一個(gè)bit，其會(huì )話(huà)顯示創(chuàng )建請求的成功。其SRD包括了1xx臨時(shí)響應和302的響應處理時(shí)延。

　　在會(huì )話(huà)請求失敗的時(shí)延中，SRD是這樣定義的，初始UA發(fā)送了初始請求的第一個(gè)bit數據到對端代理后，直到收到最后一個(gè)bit，其會(huì )話(huà)顯示創(chuàng )建請求的成功。其SRD包括了4xx臨時(shí)響應和5xx或者6xx的響應處理時(shí)延。

　　　

　　3.4-會(huì )話(huà)關(guān)閉時(shí)延-Session Disconnect Delay （SDD），SDD是用來(lái)檢測失敗或者缺陷導致的時(shí)延來(lái)結束或者關(guān)閉會(huì )話(huà)的時(shí)間。它可以檢測會(huì )話(huà)關(guān)閉成功時(shí)間和會(huì )話(huà)關(guān)閉失敗時(shí)間，會(huì )話(huà)雙方的代理端都可以檢測其時(shí)延。SDD具體的計算公式如下：

　　SDD = Time of 2XX or Timeout - Time of Completion Message （BYE）

　　SDD主要用來(lái)檢測例如BYE消息相關(guān)的200 OK回復的時(shí)間時(shí)延，雙方UA都可以支持SDD檢測：

　　

　　如果讀者以前閱讀過(guò)筆者歷史文檔的時(shí)候，讀者可能注意到了，我們曾經(jīng)針對計費問(wèn)題對SDD做了具體的討論。

　　OpenSIPS學(xué)習筆記-ACC模塊/事務(wù)-CDR記錄以及BYE消息丟失-呼叫會(huì )話(huà)關(guān)閉時(shí)延影響計費和配置示例

　　

　　如果讀者有興趣了解關(guān)于CDR計費的問(wèn)題的話(huà)，可以查閱此鏈接。

　　3.5-會(huì )話(huà)總長(cháng)-Session Duration Time （SDT）， 包括Successful Session Duration SDT和Failed Session Completion SDT。SDT的作用是檢測因為會(huì )話(huà)時(shí)間不正常導致的語(yǔ)音質(zhì)量問(wèn)題。SDT可以檢測在一個(gè)dialog中雙方UA的SDT問(wèn)題。SDT具體的計算公式如下：

　　SDT = Time of BYE or Timeout - Time of 200 OK response to INVITE

　　同樣，SDT也分為成功時(shí)長(cháng)和失敗時(shí)長(cháng)兩種計算方式。在失敗時(shí)長(cháng)計算中包括了一個(gè)F定時(shí)器時(shí)延的處理。

　　

　

　

　　3.6-會(huì )話(huà)創(chuàng )建比率-Session Establishment Ratio （SER）-SER是用來(lái)檢測UA終端和下游終端之間在每個(gè)新會(huì )話(huà)請求中會(huì )話(huà)創(chuàng )建的成功比率。此檢測只能在UA端進(jìn)行檢測。其計算公式如下：

　　SER和Answer Seizure Ratio（應答率）非常相似，表示一個(gè)總呼叫量和成功應答呼叫之間的比率。

　　

　　

　　3.7-會(huì )話(huà)創(chuàng )建有效比率Session Establishment Effectiveness Ratio （SEER），SEER是和SER有互補關(guān)系，但是，SEER排除了一些潛在的目標UA用戶(hù)的影響。SEER定義為INVITE/200 OK相關(guān)的呼叫總數和INVITE/480，486，600或者603相關(guān)的呼叫總數在總呼叫數中的占比。因為480，486等幾個(gè)回復需要非常清晰地表示了個(gè)體UA端的效應，例如可能UA的錯誤設置。另外，回復響應碼如果是401，407或者420則不在此計算范圍之內。其計算公式如下：

　　

　　SEER呼叫流程實(shí)例和SER類(lèi)似。這里不再列出。

　　3.8-無(wú)效會(huì )話(huà)嘗試-Ineffective Session Attempts （ISAs）比率，ISAs用來(lái)表示因為代理或者agent失敗或者過(guò)載情況發(fā)生后內部釋放了一個(gè)已創(chuàng )建的請求。回復響應碼可能包括408，500，503或者504。這里，可能是代理的下游網(wǎng)絡(luò )出現過(guò)載狀態(tài)后返回的408響應。其具體計算公式如下：

　　

　　

　　代理2發(fā)現了UA2可能出現了過(guò)載狀態(tài)，返回408響應，記為一次無(wú)效會(huì )話(huà)嘗試。

　　3.9-會(huì )話(huà)完成比率-Session Completion Ratio （SCR），SCR用來(lái)表示一個(gè)完整的dialog中無(wú)任何失敗，這些失敗可能是因為缺少來(lái)自于代理或者UA的響導致的失敗，是會(huì )話(huà)成功完成和總會(huì )話(huà)之間的比率。SCR和Call Completion Ratio （CCR）-呼叫完成率類(lèi)似。其計算公式為：

　　

　

　　如果讀者有興趣的話(huà)可以參考RFC3665，在此規范中定義了各種SIP創(chuàng )建成功和失敗的呼叫流程的細節。這里不再展開(kāi)討論。

　　前面的章節筆者討論了關(guān)于SIP評價(jià)指標的具體細節。根據RFC6076規范，這些評價(jià)標準和具體的其他要素也存在一定的依賴(lài)關(guān)系，讀者需要注意。

　　在這些要素中，一些SIP頭域值需要讀者做更多了解，例如：

　　另外，B2BUA也是一個(gè)重要的要素，它根據處理流程的需要可能充當UAS或者UAC，另外也可能充當一個(gè)代理的角色。它需要采集不同方向的數據。

　　簽權和認證也是需要考慮到因素。因為在dialog處理流程中可能需要認證機制，因此可能出現認證失敗的處理響應。這些響應也需要考慮在評價(jià)標準中。

　　Forking分叉呼叫處理是SIP常見(jiàn)的一種呼叫場(chǎng)景，在分叉呼叫中也需要針對不同的回復需要分別對呼叫進(jìn)行分類(lèi)計算，此計算方式根據分叉呼叫發(fā)生的點(diǎn)點(diǎn)不同來(lái)計算。特別需要注意的是SRD的計算。

　　在計算SIP評價(jià)標準時(shí)，采集的數據可能來(lái)源于不同的數據存儲方式中，例如通過(guò)CDR中來(lái)計算或者其他的數據庫，這些數據需要進(jìn)行同步處理，保證其數據的準確性。另外一些數據可能在其他的上下游代理或者UAS服務(wù)器端，在SIP評價(jià)標準的計算時(shí)也需要通過(guò)集中處理，保證數據的統一性。評價(jià)標準的數據傳輸可以通過(guò)SNMP，MIB（RFC4780）或者事件訂閱方式（RFC3265）來(lái)傳輸。

　　我們在前面的章節討論了幾個(gè)SIP性能的評價(jià)指標和RFC6076中提到的其他相關(guān)的要素，除了以上這些要素以外，筆者這里再補充說(shuō)明一些相關(guān)要素。這些要素的討論是為了讓讀者更加了解這些要素如何影響SIP評價(jià)指標。非常重要的一個(gè)指標就是延遲（Delay）。Delay包括各種方式的延遲，包括IP網(wǎng)絡(luò )延遲和終端延遲：

　　以上延遲因為物理性能或者轉換打包時(shí)長(cháng)不同都會(huì )導致不同的延遲，當然也會(huì )導致各種語(yǔ)音問(wèn)題，例如抖動(dòng)，丟失語(yǔ)音包等問(wèn)題。筆者通過(guò)不同的示例來(lái)介紹目前部分典型環(huán)境中導致的各種延遲和影響SIP 評價(jià)標準的要素。

　　通過(guò)以下示例筆者可以看到，在MOS的評測中因為時(shí)延會(huì )產(chǎn)生很多的問(wèn)題，當然，這些時(shí)延也可能引起請求注冊等方面的問(wèn)題，最后導致時(shí)延。

　　除了純SIP網(wǎng)絡(luò )的注冊流程以外，在目前的IMS網(wǎng)絡(luò )環(huán)境中，關(guān)于SIP時(shí)延的討論也很多。讀者需要特別注意RRD（注冊請求時(shí)延）的時(shí)間跨度：

　　一些研究人員針對LTE網(wǎng)絡(luò )環(huán)境中AMR編碼等要素做的一些研究，這些要素最后導致LTE網(wǎng)絡(luò )的擁塞也是非常需要關(guān)心的。當然，因為網(wǎng)絡(luò )擁塞也會(huì )導致MOS問(wèn)題。

　　

　　很多時(shí)候，SIP消息生成過(guò)多也同樣會(huì )導致時(shí)延。Jasmina發(fā)表的研究論文-Studying the Impact of SIP Message Differentiation on the Quality of VoIP Session Control Procedures提到了SIP消息的不同對語(yǔ)音質(zhì)量和時(shí)延帶來(lái)的問(wèn)題。SIP消息生成如果導致了過(guò)高負載的話(huà)，也產(chǎn)生了前面我們所討論的評價(jià)標準的時(shí)間延遲。他通過(guò)不同在SIP消息生成中采用不同算法優(yōu)先級來(lái)（SIPPRIO package）優(yōu)化過(guò)高負載降低SIP消息生成帶來(lái)的系統壓力。具體測試結果和SIP評價(jià)標準（RRD, SRD, 和 SDD）相關(guān)性如下：

　　

　

　

　　如果我們具體到比較簡(jiǎn)單的語(yǔ)音環(huán)境中，SIP網(wǎng)絡(luò )架構當然也會(huì )影響SIP 評價(jià)標準的數據質(zhì)量。網(wǎng)上有很多測試結果，讀者可以查閱。這里，筆者分享MIROSLAV發(fā)表的關(guān)于SIP Infrastructure Performance Testing的一篇研究論文。在其論文中，通過(guò)不同CPU資源，結合不同的編碼，對RRD和SRD所產(chǎn)生的不同的影響。筆者提供此示例的目的是針對一般企業(yè)用戶(hù)，或者中小型用戶(hù)可以通過(guò)此配置示例對SIP評價(jià)標準進(jìn)行一定的測試，也方便用戶(hù)對測試環(huán)境的完善做一個(gè)補充。

　

　　

　　更為簡(jiǎn)單的場(chǎng)景中，讀者可以通過(guò)簡(jiǎn)單SIP注冊進(jìn)行壓力測試，對RRD進(jìn)行評價(jià)。例如， Miroslav發(fā)表的SIP Registration Stress Test對比不同版本Asterisk支持的RRD狀態(tài)：

　　

　　

　　當然，如果在洪水攻擊的環(huán)境中或者在實(shí)際生產(chǎn)環(huán)境中，如果被攻擊以后，INVITE和各種后續請求等生成時(shí)延都會(huì )隨著(zhù)數據包不斷增加時(shí)延也會(huì )隨著(zhù)增加。因此，用戶(hù)在部署基于云平臺或者無(wú)安全保障的前提下，一定要注意這些數據的變化，因為這些SIP 評價(jià)標準的數據也導致了語(yǔ)音質(zhì)量的問(wèn)題，包括抖動(dòng)，語(yǔ)音丟失等問(wèn)題。Santosh Kumar發(fā)表的研究論文中對各種延遲結合SIP請求，BYE或者Options消息等環(huán)境中做的測試，這些測試數據也影響了語(yǔ)音時(shí)延，抖動(dòng)，語(yǔ)音丟失等問(wèn)題，嚴重影響了SIP評價(jià)標準的數據。

　　

　　

　　目前比較新的技術(shù)就是使用SD-WAN，我們稱(chēng)之為綠色VOIP網(wǎng)絡(luò )。SD-WAN有很多目前網(wǎng)絡(luò )部署場(chǎng)景所不具備的優(yōu)勢，完全靈活實(shí)現了SIP網(wǎng)絡(luò )的部署，優(yōu)化了傳輸速度和穩定性。因此，通過(guò)SD-WAN可以降低很多的時(shí)延。Ahmadreza發(fā)表的研究論文通過(guò)對綠色VOIP部署的測試所得出的研究結果，其結果對SIP時(shí)延優(yōu)化有極大的幫助，希望讀者能夠引起重視。

　　筆者在本文章中重點(diǎn)介紹了關(guān)于SIP評價(jià)標準RFC-6076的9大評價(jià)標準，通過(guò)一定的比較知識介紹，結合具體的SIP 評價(jià)標準和其格式以及呼叫流程對各種指標進(jìn)行了詳細說(shuō)明。另外，筆者針對計算評價(jià)標準的其他因素也做了一點(diǎn)說(shuō)明。最后，筆者根據以上RFC6076規范中說(shuō)明的數據，對關(guān)于生成延遲的時(shí)間和各種測試做了比較完善的補充介紹，幫助讀者能夠完整了解這些時(shí)延產(chǎn)生的原因和對語(yǔ)音質(zhì)量的影響。在一些比較新的研究論文中，突出介紹了環(huán)境部署對SIP性能的影響，網(wǎng)絡(luò )，編碼和技術(shù)架構部署，包括最新SD-WAN等技術(shù)的部署介紹。

　　因為筆者能力所限，有一些其他方面的時(shí)延內容沒(méi)有做具體討論，例如AMR編碼的影響，各種開(kāi)源媒體服務(wù)器中配置的優(yōu)化和利用SBC部署方式的優(yōu)化等。如果有時(shí)間的話(huà)，筆者在后續的文章中會(huì )逐一補充。

　　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 解決方案