在PSTN時(shí)代，運(yùn)營商的CDR計(jì)費(fèi)本身已經(jīng)存在了，隨著IP語音的突飛猛進(jìn)，包括現(xiàn)在基于VoLTE語音的部署，計(jì)費(fèi)的模式也逐漸發(fā)生了變化。在目前最新的VoLTE網(wǎng)絡(luò)中，因?yàn)橐粋�(gè)SIP呼叫跨越了很多的節(jié)點(diǎn)路徑，計(jì)費(fèi)的流程更加長一些，涉及的各種延遲也更多一些，比較重要的參數(shù)例如，Post-dial delay（PDD或者SRD）。這些延遲會(huì)影響計(jì)費(fèi)的時(shí)長和話單的準(zhǔn)確性。另外，每個(gè)國家可能因?yàn)榄h(huán)境的不同對CDR參數(shù)設(shè)置也有不同的要求，還有很多場景中需要緊急電話服務(wù)的話，電話系統(tǒng)必須需要支持規(guī)范的呼叫格式和對呼叫進(jìn)行不同的定義。

　　

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

　　因?yàn)樵赟IP網(wǎng)絡(luò)中，根據(jù)不同的SIP初始請求所產(chǎn)生的事務(wù)和dialog也可能完全不同，因此請求的不同也產(chǎn)生了不同的CDR消息記錄。這些請求可以是：INVITE，REGISTER，SUBSCRIBE，OPTIONS，MESSAGE和INFO。

　

　　這些請求的返回?cái)?shù)據(jù)都需要根據(jù)不同的請求生成一個(gè)完整的CDR記錄。這些數(shù)據(jù)的處理相對就復(fù)雜很多，需要專門的CDR服務(wù)器做解析生成。另外，在CDR生成時(shí)，SIP dialog和事務(wù)都有各自的會(huì)話結(jié)束方式，這又增加了CDR生成的邏輯流程，它們通過bCDR和cCDR實(shí)現(xiàn)基礎(chǔ)CDR和合并CDR的生成，并且創(chuàng)建了dialog和事務(wù)的連接。

　　

　　研究人員Tamás Tóthfalusi 發(fā)布了針對VoLTE的CDR生成做了比較詳細(xì)的分享說明和關(guān)于CDR生成的研究成果。在其論文中比較詳細(xì)說明了VoLET環(huán)境中SIP呼叫和CDR生成的研究。讀者可以參考其論文做進(jìn)一步的研究。

　　3GPP針對CDR有著非常詳細(xì)的規(guī)范說明（ETSI TS 132 240），包括了漫游，在線費(fèi)用，離線費(fèi)用，呼叫和服務(wù)費(fèi)用等非常詳細(xì)的說明。用戶如果有興趣的話，可以參考ETSI TS 132 240 3GPP規(guī)范做更多了解。

　

　　3GPP僅是針對網(wǎng)絡(luò)環(huán)境做的關(guān)于CDR的規(guī)范說明，一些國家也專門發(fā)布了自己的運(yùn)營商CDR規(guī)范說明。在英國的CDR規(guī)范說明中包括了固話，VoIP呼叫，移動(dòng)端和呼入呼叫（包括多腿呼叫費(fèi)用計(jì)算）。呼叫類型包括：

　　V = outbound voice call,

　　VOIP = Voice over IP call

　　D = Data/ISDN Call

　　C = Conference call

　　N = Inbound call （billable）

　　I = Standard Inbound call （usually not billable e.g. Raw call data）

　　U = Unanswered call

　　B = Busy Call

　　X = Call failed

　　M = Mobile call （made from mobile device）

　　G = GPRS Data

　　UK的CDR格式中規(guī)定了42個(gè)必要的呼叫參數(shù)，其中部分參數(shù)是可選參數(shù)。

　　除了標(biāo)準(zhǔn)的呼叫計(jì)費(fèi)以外，美國特別針對NG9-1-1呼叫的計(jì)費(fèi)也有規(guī)范說明。此規(guī)范的目的是針對電話運(yùn)營商提供的緊急呼叫中計(jì)費(fèi)的規(guī)范定義。為了滿足NG9-1-1的規(guī)范，很多呼叫的定義需要增加一些相應(yīng)的變量設(shè)置，例如對呼叫的定義和總呼叫時(shí)長的變量設(shè)置和log事件：

　

　

　　

　　通過以上簡單的背景介紹，我們可以看到，生成一個(gè)完整的CDR是非常復(fù)雜的流程，這里需要數(shù)據(jù)業(yè)務(wù)數(shù)據(jù)的參與，同時(shí)需要滿足不同國家的規(guī)范的要求，并且有時(shí)如果電話系統(tǒng)需要緊急呼叫支持的話，系統(tǒng)配置也要具備一定的靈活性支持其業(yè)務(wù)要求。在第二個(gè)章節(jié)，筆者將具體介紹OpenSIPS環(huán)境中的ACC模塊的存儲(chǔ)方式討論。

　　為了幫助大家了解更多關(guān)于CDR計(jì)費(fèi)的基本概念和應(yīng)用的場景，筆者在前面章節(jié)介紹了一些關(guān)于CDR計(jì)費(fèi)的一些基本知識(shí)，行業(yè)規(guī)范和幾個(gè)具體的應(yīng)用廣泛，其目的是幫助讀者了解CDR計(jì)費(fèi)以外的一些業(yè)務(wù)要求，在擴(kuò)充CDR支持能力時(shí)可以對其要求有比較充分的認(rèn)識(shí)。當(dāng)然，因?yàn)樗�平資源有限，筆者也沒有能力對CDR處理有非常全面的了解，這里主要是提醒讀者了解更多關(guān)于簡單CDR以外的內(nèi)容。

　　如果具體到今天核心的主題-SIP網(wǎng)絡(luò)環(huán)境或者OpenSIPS平臺(tái)的話，我們主要介紹關(guān)于OpenSIPS環(huán)境中ACC模塊的功能和其存儲(chǔ)方式。OpenSIPS的呼叫ACC模塊或者Accounting是一個(gè)非常重要的模塊。用戶在部署OpenSIPS時(shí)不可避免需要接觸到ACC模塊。ACC模塊涉及了幾個(gè)主要的概念，包括ACC event，ACC核心內(nèi)容和ACC后端存儲(chǔ)處理，其他ACC拓展參數(shù)支持和多腿呼叫的CDR記錄等幾個(gè)方面的內(nèi)容。

　　首先，我們需要明確的是ACC事件，ACC事件簡單來說就是事務(wù)處理狀態(tài)的事件，包括成功事務(wù)事件，失敗事務(wù)事件和丟失的事務(wù)事件等。這些事件和呼叫本身有緊密的聯(lián)系。我們前面的討論中也說明，根據(jù)CDR規(guī)范，呼叫的事件都需要通過兩種方式進(jìn)行存儲(chǔ)，一種是系統(tǒng)log的形式，另外一種是后端數(shù)據(jù)庫存儲(chǔ)的方式。OpenSIPS也同樣遵守這個(gè)規(guī)范。在前面的介紹中和以前的歷史文檔筆者都有說明，在一個(gè)呼叫中需要通過事務(wù)處理和dialog處理，它們有著各自不同的處理方式，因此，在ACC需要支持事務(wù)和dialog實(shí)現(xiàn)對CDR的完整記錄。OpenSIPS的ACC模塊可以支持消息，事務(wù)和dialog。ACC中的消息包括多種消息，例如INVITE和BYE等。這些ACC的消息都可以通過log，數(shù)據(jù)庫存儲(chǔ)，Radius和Events形式進(jìn)行存儲(chǔ)。筆者在后續(xù)的章節(jié)會(huì)分別介紹這些處理過程。

　　如果讀者不清楚關(guān)于事務(wù)，會(huì)話和dialog的區(qū)別的話，建議首先閱讀筆者歷史文章： 再論SIP呼叫中的Call，Dialog和Transaction

　　在后續(xù)的關(guān)于CDR計(jì)費(fèi)時(shí)長的討論中，我們將使用事務(wù)處理的概念，讀者一定要明確這個(gè)概念，以免混淆了整個(gè)計(jì)費(fèi)的設(shè)置。

　　關(guān)于Acc Scope的具體設(shè)置支持，和其他數(shù)據(jù)庫設(shè)置支持的細(xì)節(jié)，讀者可以訪問官方文檔做進(jìn)一步了解。需要注意，如果需要設(shè)置ACC 模塊時(shí)，用戶需要經(jīng)過幾個(gè)流程設(shè)置：

　　在OpenSIPS的ACC模塊中，主要支持四種事件的狀態(tài)，包括事務(wù)成功事件，成功的dialog事件，丟失的呼叫事件，失敗的事務(wù)事件。

　

　　在以上的事件狀態(tài)中，其他幾種事件相對比較容易處理，丟失的呼叫事件是一個(gè)相對比較困難處理的事件。在丟失呼叫的事件中包括兩種狀態(tài)，一種是丟失的事件，另外一種是成功的事件。因此，如果做CDR處理時(shí)需要同時(shí)記錄這兩種事件對應(yīng)不同的UAS。我們經(jīng)�？赡苡龅�，如果是一個(gè)fork呼叫或者按續(xù)呼叫過程中，如果第一個(gè)呼叫失敗以后會(huì)繼續(xù)呼叫，繼續(xù)對第二個(gè)目的地進(jìn)行按續(xù)呼叫的流程。這種丟失呼叫的事件需要特別留意，否則CDR統(tǒng)計(jì)結(jié)果就會(huì)產(chǎn)生錯(cuò)誤。

　　這里提醒讀者，在處理這些事件中，成功的事務(wù)處理和失敗事務(wù)處理會(huì)存儲(chǔ)到同一ACC的表中，丟失的呼叫事件則會(huì)存儲(chǔ)到missed call 的表中。當(dāng)然，用戶也可以自己修改表名稱方便自己的部署環(huán)境。

　　計(jì)費(fèi)是一個(gè)非常重要的功能，無論是使用開源媒體服務(wù)器，例如Asterisk還是FreeSWITCH，或者使用SIP軟交換服務(wù)器，例如OpenSIPS和Kamailio或者很多商業(yè)IPPBX。很多用戶忽略了一個(gè)非常復(fù)雜或非常細(xì)節(jié)的問題，那就是在呼叫經(jīng)過多次轉(zhuǎn)接或者停靠以后的計(jì)費(fèi)處理。通常的CDR中，我們僅簡單計(jì)算了從呼叫方到被呼叫方的總時(shí)長。特別是在企業(yè)IPPBX的應(yīng)用場景中，我們僅考慮了呼入方到一個(gè)內(nèi)部分機(jī)之間的呼叫時(shí)長，但是，讀者是否考慮過如果呼入以后涉及了電話盲轉(zhuǎn)或者詢轉(zhuǎn)，或者執(zhí)行了一個(gè)分機(jī)隨行以后繼續(xù)呼叫一個(gè)外部電話號(hào)碼或者長途固定電話。如果涉及到了其他額外呼叫流程的話，嚴(yán)格來說，這些呼叫都需要分段計(jì)費(fèi)，有的呼叫可能是不計(jì)費(fèi)的（例如呼入）并且通過分段計(jì)費(fèi)最后聚會(huì)成一個(gè)完整的CDR計(jì)費(fèi)。不幸的是，很多的IPPBX并沒有進(jìn)行這么詳細(xì)的處理，僅簡單籠統(tǒng)地計(jì)算了一個(gè)呼叫的總時(shí)長。因此，這樣的處理結(jié)果不是一個(gè)正確的CDR計(jì)費(fèi)流程，只能算是一個(gè)CDR統(tǒng)計(jì)，它不能作為話單結(jié)算數(shù)據(jù)。在如下示例中，按照目前正常的計(jì)費(fèi)模式，如果A呼叫B，B然后轉(zhuǎn)接到C端手機(jī)的話，從A到B是免費(fèi)的，但是，從B到C端可能是付費(fèi)的，這里涉及了誰將為B到C支付問題。如果按照標(biāo)準(zhǔn)的CDR計(jì)費(fèi)的話，A應(yīng)該對C端付費(fèi)，事實(shí)上這完全是一種錯(cuò)誤的計(jì)費(fèi)方式。因此，針對復(fù)雜業(yè)務(wù)場景中，多腿分段計(jì)費(fèi)是一個(gè)必要的計(jì)費(fèi)方式。為了支持多腿呼叫，OpenSIPS支持多腿計(jì)費(fèi)時(shí)需要重新創(chuàng)建一個(gè)新的acc_new_leg（）進(jìn)行支持。

　

　　作為一個(gè)運(yùn)營級的SIP軟交換，OpenSIPS和Kamailio在早期版本并沒有真正實(shí)現(xiàn)多腿CDR的支持。在后期的OpenSIPS的發(fā)布版本中開始支持了多腿CDR記錄支持。通過多腿計(jì)費(fèi)保證了CDR的準(zhǔn)確性和完整性。OpenSIPS在多腿CDR支持時(shí)增加了一個(gè)對中間跳板的記錄，分別對分段處理進(jìn)行存儲(chǔ)支持。正常的CDR僅保存呼叫源和最終目的地的存儲(chǔ)。OpenSIPS通過支持多腿CDR實(shí)現(xiàn)了非常完整準(zhǔn)確的CDR計(jì)費(fèi)。這里提醒讀者，在ACC中，事務(wù)記錄中的duration是為空的，在CDR記錄中則包含了duration值。

　　在數(shù)據(jù)庫生成的示例數(shù)據(jù)如下，包括了用戶1到用戶2，用戶2到用戶3的完整的多腿CDR記錄。

　　在呼叫過程中，因?yàn)榫W(wǎng)絡(luò)原因或者其他的終端原因，很多情況下我們會(huì)遇到呼叫失敗的問題。呼叫失敗不僅僅會(huì)影響呼叫方的體驗(yàn)，同時(shí)也影響計(jì)費(fèi)結(jié)算結(jié)果。在一些呼叫中，我們經(jīng)常會(huì)收到?jīng)]有BYE請求返回的問題，或者叫BYE消息丟失的問題。沒有BYE消息的話，CDR計(jì)費(fèi)就產(chǎn)生錯(cuò)誤。這對CDR生成是一個(gè)非常大的挑戰(zhàn)。在以前的歷史文檔中，我們討論了dialog狀態(tài)和計(jì)費(fèi)啟動(dòng)的機(jī)制，讀者可以參考OpenSIPS中的dialog使用和計(jì)費(fèi)的說明：

　　OpenSIPS學(xué)習(xí)筆記-Dialog的五種狀態(tài)及配置示例

　　研究人員Dimitris Geneiatakis在早期發(fā)表的關(guān)于CDR算法討論-A Mechanism for Ensuring the Validity and Accuracy of the Billing Services in IP Telephony中對CDR做了最簡單的描述：

　

　　這里可以看出，BYE消息是計(jì)費(fèi)計(jì)算的一個(gè)基準(zhǔn)數(shù)。

　　

　　有時(shí)，如果沒有及時(shí)處理BYE消息丟失的問題的話，可能CDR時(shí)長就會(huì)不斷增加。本來一個(gè)呼叫可能已經(jīng)在3分鐘內(nèi)結(jié)束了，但是因?yàn)闆]有收到BYE消息，最后通話時(shí)長可能是10分鐘或者20分鐘甚至于更長時(shí)間。這樣計(jì)費(fèi)就會(huì)產(chǎn)生很多問題。如果出現(xiàn)了丟失BYE消息以后，系統(tǒng)平臺(tái)應(yīng)該有一定的機(jī)制來及時(shí)正確執(zhí)行掛機(jī)，保證其CDR計(jì)費(fèi)出現(xiàn)問題。另外，如果系統(tǒng)平臺(tái)對并發(fā)呼叫有限制的話，丟失了BYE消息以后，這樣的限制設(shè)置可能會(huì)產(chǎn)生錯(cuò)誤的結(jié)果。

　　目前，在SIP網(wǎng)絡(luò)環(huán)境中，OpenSIPS運(yùn)營平臺(tái)結(jié)合其他手段來執(zhí)行丟失BYE消息以后的掛機(jī)處理。各種處理方式都有其各自的特點(diǎn)。

　

　　使用標(biāo)準(zhǔn)的SIP定時(shí)器時(shí)，SIP會(huì)話定時(shí)器設(shè)置超時(shí)以后，結(jié)束會(huì)話或者重新發(fā)起一個(gè)re-INVITE請求或者update，經(jīng)過幾個(gè)周期以后對呼叫掛機(jī)。它要求客戶端或者網(wǎng)關(guān)能夠支持會(huì)話定時(shí)器設(shè)置支持。當(dāng)然，如果終端和網(wǎng)關(guān)都在同一公司內(nèi)網(wǎng)環(huán)境中的話，用戶可以控制設(shè)備的配置，比較容易設(shè)置定時(shí)器支持。如果是運(yùn)營級的應(yīng)用場景的話，建議用戶通過網(wǎng)關(guān)或者SBC來設(shè)置定時(shí)器支持。RFC4028對SIP會(huì)話定時(shí)器有非常明確的規(guī)范，讀者可以參考RFC4028做進(jìn)一步了解。

　　通過dialog的ping實(shí)現(xiàn)BYE消息丟失的掛機(jī)控制的話，這是一種非標(biāo)準(zhǔn)的控制手段，它需要通過SIP 信令發(fā)送OPTIONS消息來實(shí)現(xiàn)。當(dāng)然要求客戶端或者網(wǎng)關(guān)支持OPTIONS/INVIET消息。因?yàn)槟壳昂芏嘟K端都支持發(fā)送OPTIONS消息或者re-INVITE, 相對來說是一種比較簡單的處理BYE消息丟失的方式，所以筆者推薦終端，ATA和網(wǎng)關(guān)設(shè)置OPTIONS消息檢測來實(shí)現(xiàn)BYE消息丟失的掛機(jī)處理。

　　最后一種方式是通過RTP提示來對BYE消息丟失進(jìn)行處理。這種處理方式也是一種非標(biāo)準(zhǔn)的處理方式，但是，它需要通過RTP流的檢測來實(shí)現(xiàn)。OpenSIPS不能支持RTP超時(shí)檢測，所以只能通過媒體服務(wù)器端通過對雙方的RTP流檢測或者靜音檢測來實(shí)現(xiàn)掛機(jī)處理。如果媒體服務(wù)器檢測到雙方的RTP語音流無任何有效數(shù)據(jù)時(shí)，說明雙方已不再繼續(xù)通話，所以執(zhí)行掛機(jī)處理。這種檢測方式也沒有對終端有任何的要求。如果以上兩種處理方式不能使用時(shí)，讀者也可以考慮通過媒體服務(wù)器檢測RTP語音超時(shí)來實(shí)現(xiàn)。開源媒體軟交換Asterisk和FreeSWITCH都可以支持這樣的檢測機(jī)制來實(shí)現(xiàn)BYE消息丟失的掛機(jī)。但是，這種檢測機(jī)制很難非常準(zhǔn)確及時(shí)地實(shí)現(xiàn)掛機(jī)處理。因此，如果要實(shí)現(xiàn)CDR記錄的完整性和準(zhǔn)確性，這是一個(gè)相對比較差的選擇。

　　再次說明，選擇何種處理方式需要用戶根據(jù)自己的部署環(huán)境做判斷，最終使用一個(gè)較低成本的方式來解決問題，筆者僅提供一個(gè)比較完整的建議。

　　大部分情況下，我們的通話是在正常狀態(tài)完成，整個(gè)CDR數(shù)據(jù)也非常正確。但是，在基于SIP網(wǎng)絡(luò)環(huán)境中，特別是基于云平臺(tái)或者全球部署的呼叫環(huán)境中，呼叫過程中出現(xiàn)網(wǎng)絡(luò)故障是非常正常的事情。因?yàn)榫W(wǎng)絡(luò)故障，整個(gè)Acc 模塊的記錄就會(huì)出現(xiàn)問題，最終導(dǎo)致CDR和話單錯(cuò)誤。如下示例中，如果運(yùn)營商和用戶代理服務(wù)器之間出現(xiàn)了網(wǎng)絡(luò)故障，如何進(jìn)行結(jié)算是一個(gè)比較頭疼的問題。

　　

　　在以上示例中，運(yùn)營商已經(jīng)對代理服務(wù)器發(fā)送了200 OK，但是代理服務(wù)器和運(yùn)營商之間的網(wǎng)絡(luò)出現(xiàn)了故障以后，我們需要特別關(guān)注是運(yùn)營商支付這個(gè)話單還是我們的代理服務(wù)器負(fù)責(zé)支付這個(gè)話單。這里有幾個(gè)爭議的地方需要大家討論：

　　對運(yùn)營商來說，它已經(jīng)發(fā)送了 200 OK， 網(wǎng)絡(luò)問題可能不是運(yùn)營商端的網(wǎng)絡(luò)問題。

　　對客戶代理服務(wù)器來說，代理服務(wù)器沒有收到 200 OK, 當(dāng)然也沒有繼續(xù)發(fā)送后續(xù)回復(fù)（BYE，ACK等）信息到運(yùn)營商端，客戶代理服務(wù)器也可能拒絕支付這個(gè)話單。但是，如果是運(yùn)營商上游呼叫的話，運(yùn)營商和上游呼叫方已經(jīng)產(chǎn)生了話單，如何處理這個(gè)呼叫的話單也是一個(gè)問題。

　　運(yùn)營商是否應(yīng)該提供定時(shí)器設(shè)置來網(wǎng)絡(luò)檢測確認(rèn) 200 OK返回ACK消息，以便確認(rèn)話單的準(zhǔn)確性。

　　一些運(yùn)營商和代理之間的網(wǎng)絡(luò)問題很難準(zhǔn)確及時(shí)到位。

　　UDP過度碎片化或者超過MTU數(shù)據(jù)限定，終端編碼協(xié)商等導(dǎo)致的問題。

　　在一些小并發(fā)的呼叫環(huán)境中，可能這樣的故障不會(huì)引起太多的問題，但是如果并發(fā)量在1W以上的話，網(wǎng)絡(luò)故障引起的計(jì)費(fèi)就會(huì)導(dǎo)致很大問題。這里，筆者拋出的這些問題的目的是讓用戶知道這些問題的存在，具體如何兌付話單和運(yùn)營商如何協(xié)商不在筆者討論范圍之內(nèi)，很多運(yùn)營商對此問題有著不同的商務(wù)解決方案。筆者在這里討論的目的是網(wǎng)絡(luò)穩(wěn)定是正確計(jì)費(fèi)的非常重要的前提條件。

　　計(jì)費(fèi)中另外一個(gè)比較重要的話題是會(huì)話掛機(jī)時(shí)延。大家討論到計(jì)費(fèi)通�？赡鼙容^關(guān)心的是價(jià)格。事實(shí)上，在運(yùn)營商提供的SIP trunk或者其他線路服務(wù)環(huán)境中，除了價(jià)格以外，語音穩(wěn)定和語音質(zhì)量以外，用戶好像沒有太多的指標(biāo)來判斷線路運(yùn)營商的服務(wù)水平。事實(shí)上，除了筆者前面提到的結(jié)果指標(biāo)以外，用戶端可能還要注意幾個(gè)潛在的問題。這些設(shè)置指標(biāo)可能有的是運(yùn)營商故意設(shè)置的，有的是因?yàn)檫\(yùn)營網(wǎng)絡(luò)被動(dòng)體現(xiàn)出來的。

　　一些比較“聰明”的運(yùn)營商為客戶提供了相對比較低的價(jià)格，用戶自己體驗(yàn)也沒有發(fā)現(xiàn)什么大的問題。但是，如果運(yùn)營商因?yàn)榉��?wù)器處理能力問題或者其他硬件問題的限制，在計(jì)費(fèi)中故意設(shè)置了一些參數(shù)的話，整個(gè)呼叫的時(shí)間就會(huì)延長，但是，一般用戶可能沒有什么特別明顯的反應(yīng)。在呼叫流程中，幾個(gè)需要用戶特別關(guān)注的延遲設(shè)置可能會(huì)導(dǎo)致整個(gè)通話的時(shí)延，而且運(yùn)營商在任何一個(gè)節(jié)點(diǎn)做延遲設(shè)置都可能影響整個(gè)通話的計(jì)費(fèi)。因此，時(shí)延的問題需要讀者認(rèn)真去考慮。以下示例就是在SIP呼叫中，各種會(huì)話響應(yīng)之間的的創(chuàng)建所消耗的時(shí)間。

　　在以上圖例中，我們可以看到各種時(shí)延的設(shè)置。根據(jù)RFC6076規(guī)范，各種會(huì)話時(shí)延都有比較明確的規(guī)定，包括9個(gè)評價(jià)指標(biāo)：

　　Registration Request Delay （RRD）

　　Session Request Delay （SRD）

　　Session Disconnect Delay （SDD）

　　Session Duration Time （SDT）

　　Session Establishment Ratio （SER）

　　Session Establishment Effectiveness Ratio （SEER）

　　Session Completion Ratio （SCR）

　　Ineffective Session Attempts （ISAs） 等。

　　如果是傳統(tǒng)PSTN的話可能還要涉及到其他的時(shí)延，例如PDD時(shí)延。

　　這些時(shí)延構(gòu)成了評價(jià)SIP端對端性能的評價(jià)指標(biāo)。雖然很多SIP運(yùn)營商都聲稱自己的SIP服務(wù)如何優(yōu)質(zhì)，但是，筆者建議避免使用空洞夸張的市場語言來說服用戶，最好還是給出一個(gè)客觀的數(shù)據(jù)來說服用戶。在SIP端對端的執(zhí)行性能評價(jià)指標(biāo)中，SDD是一個(gè)非常重要的指標(biāo)。在INVITE呼叫中其中一個(gè)比較重要的時(shí)延就是SDD的時(shí)長。根據(jù)RFC6076規(guī)范說明，SDD是介于BYE消息和其200 OK返回消息之間的時(shí)延時(shí)間。

　　

　　這里讀者一定要注意，在OpenSIPS的CDR中的呼叫時(shí)長是基于事務(wù)（Transaction）時(shí)長來計(jì)算的，不是基于請求時(shí)長來計(jì)算的。我們假設(shè)已經(jīng)收到了BYE消息，但是，計(jì)費(fèi)結(jié)束是以BYE消息的200 OK返回消息為計(jì)算基準(zhǔn)的，如果BYE消息和其返回的200 OK消息之間的時(shí)長有過多時(shí)延的話，計(jì)費(fèi)就不是非常準(zhǔn)確，運(yùn)營商端處理返回消息出現(xiàn)了時(shí)延，可能最后導(dǎo)致客戶端實(shí)際數(shù)據(jù)延長。如果運(yùn)營商和客戶端之間的事務(wù)結(jié)束時(shí)間延遲以后，這個(gè)計(jì)費(fèi)時(shí)長就會(huì)延長。運(yùn)營商收到BYE以后，在正常時(shí)間范圍內(nèi)（1秒鐘內(nèi)）返回200 OK是正常的，但是，如果運(yùn)營商在一定延遲以后再發(fā)送200 OK，整個(gè)計(jì)費(fèi)時(shí)長就會(huì)增加。

　　很多企業(yè)級的IPPBX或者SIP軟交換平臺(tái)沒有具體的采集SIP metrics 集成解決方案，這里筆者介紹一個(gè)開源的解決方案 SIP3，它可以集成多個(gè)SIP IPPBX，和RTP語音評價(jià)指標(biāo)，通過界面來顯示其相關(guān)的SIP評價(jià)指標(biāo)。具體項(xiàng)目鏈接查閱參考資料。

　　OpenSIPS 支持ACC和CDR的模塊來實(shí)現(xiàn)計(jì)費(fèi)處理。如果需要實(shí)現(xiàn)ACC模塊和CDR模塊的處理需要經(jīng)過以下幾個(gè)步驟。

　　首先，用戶需要在ACC的表中插入acc的參數(shù)，通過mysql 命令執(zhí)行此命令：

　　mysql -u root opensips

　　然后執(zhí)行：

　　ALTER TABLE `acc` ADD `caller_id` CHAR（ 64 ） NOT NULL ;

　　ALTER TABLE `acc` ADD `callee_id` CHAR（ 64 ） NOT NULL ;

　　ALTER TABLE `acc` ADD `leg_type` CHAR（10） NOT NULL;

　　ALTER TABLE `missed_calls` ADD `caller_id` CHAR（ 64 ） NOT NULL ;

　　ALTER TABLE `missed_calls` ADD `callee_id` CHAR（ 64 ） NOT NULL ;

　　ALTER TABLE `missed_calls` ADD `leg_type` CHAR（10） NOT NULL;

　　接下來配置cfg文件，加載必要的模塊和參數(shù)：

　　loadmodule "acc.so"

　　modparam（"acc", "db_url", "mysql://opensips:opensipsrw@localhost/opensips"）

　　modparam（"acc", "extra_fields",

　　"db: CALLER->caller_id; CALLEE->callee_id; TYPE->leg_type"） // 添加了CDR拓展支持

　　modparam（"acc", "db_table_missed_calls", "acc"）

　　增加acc的參數(shù)：

　　do_accounting（"db","cdr|missed"）;

　　$acc_extra（CALLER） = $fU;

　　$acc_extra（CALLEE） = $rU;

　　增加拓展支持，對PSTN進(jìn)行cdr處理：

　　$acc_extra（TYPE） = "PSTN";

　　然后重新啟動(dòng)OpenSIPS，通過PSTN呼叫進(jìn)行測試，通過OpenSIPS Control Panel -> System -> CDRViewer查看CDR記錄。

　　如果需要支持多腿呼叫CDR的話，用戶需要執(zhí)行以下步驟。修改cfg配置文件，加載多腿CDR支持

　　modparam（"acc", "leg_fields",

　　"db: CALLER->caller_id;CALLEE->callee_id;TYPE->leg_type"）

　　在leg 1的設(shè)置中增加：

　　$acc_leg（TYPE） = "USER";

　　acc_new_leg（）; // 創(chuàng)建了一個(gè)新的leg

　　在leg 2增加

　　$acc_leg（CALLER） = $（acc_leg（CALLEE）[-2]）;

　　$acc_leg（CALLEE） = $rU;

　　xlog（"forwarded unconditionally to: $avp（callfwd）"）;

　　執(zhí)行了呼叫前轉(zhuǎn)設(shè)置。重新啟動(dòng)OpenSIPS，然后再通過界面修改用戶配置文件，增加前轉(zhuǎn)支持，呼叫從1002前轉(zhuǎn)到一個(gè)PSTN的號(hào)碼上。

　　保存以上配置。然后進(jìn)行呼叫測試，通過1000呼叫SIP 用戶1002，1002將會(huì)前轉(zhuǎn)到一個(gè)PSTN的號(hào)碼上。通過控制界面查看CDR記錄，我們會(huì)看到分別與兩個(gè)腿的呼叫，從1000到1002，然后1002到2345678 PSTN號(hào)碼。

　　默認(rèn)環(huán)境下，CDRVIEWER記錄僅支持CDR的記錄，沒有顯示ACC表的記錄消息。用戶可以通過修改CDR的配置文件顯示更多關(guān)于ACC模塊的參數(shù)設(shè)置。用戶需要修改配置文件：

　　vim /var/www/html/opensips-cp/config/tools/system/cdrviewer/local.inc.php

　　增加對ACC的數(shù)據(jù)支持，添加以下三行數(shù)據(jù)：

　　$show_field[9]['caller_id'] = "Caller ID";

　　$show_field[10]['callee_id'] = "Callee ID";

　　$show_field[11]['leg_type'] = "Call type";

　　用戶需要重新刷新界面，查看CDRviewer，用戶會(huì)看到我們剛才添加到ACC模塊數(shù)據(jù)。

　

　　CDR處理是VOIP的核心功能，每個(gè)運(yùn)營商和很多國家對關(guān)于其部署和使用都有非常明確的規(guī)范，特別是在VoLTE網(wǎng)絡(luò)中，CDR的處理變得更加復(fù)雜。筆者在本文章中討論了關(guān)于OpenSIPS的ACC模塊和CDR計(jì)費(fèi)模塊的細(xì)節(jié)流程，另外討論了關(guān)于CDR計(jì)費(fèi)時(shí)的一些相關(guān)問題的處理，多腿計(jì)費(fèi)的正確處理流程，特別針對丟失BYE消息的處理，需要關(guān)注關(guān)于網(wǎng)絡(luò)故障以后的CDR數(shù)據(jù)生成，會(huì)話關(guān)閉時(shí)延問題討論和關(guān)于OpenSIPS環(huán)境下多腿示例的配置以及如何修改cdrviewer顯示ACC 表的更多信息。

　　因?yàn)镃DR的細(xì)節(jié)很多涉及了具體的業(yè)務(wù)規(guī)范，筆者這里討論的僅局限于OpenSIPS和一般的企業(yè)IPPBX呼叫場景中，這里沒有涉及一些運(yùn)營商級的CDR級或者其他業(yè)務(wù)場景的討論，很多場景實(shí)際上和具體業(yè)務(wù)規(guī)范有非常緊密的關(guān)系，因此在處理方式上也存在很多差異。希望讀者根據(jù)自己的業(yè)務(wù)場景來理解CDR的流程，筆者文章作為一個(gè)部署OpenSIPS的參考。

　　另外，我們的討論僅局限于比較簡單的呼叫流程。因?yàn)楹艚辛鞒躺婕暗胶芏嗑唧w的企業(yè)融合通信的業(yè)務(wù)流程，呼叫流程可能涵蓋多個(gè)終端或者其他第三方的應(yīng)用，在CDR處理方面需要更多的靈活的支持，這些支持也需要媒體服務(wù)器做相應(yīng)的配合支持。如果單純完全依靠OpenSIPS一個(gè)環(huán)境來處理的話顯然是不現(xiàn)實(shí)的。因此，為了能夠完整處理CDR數(shù)據(jù)，需要配合多個(gè)平臺(tái)聚合數(shù)據(jù)庫數(shù)據(jù)才能更加準(zhǔn)確實(shí)現(xiàn)CDR，ACC的功能。

　　www.rbbn.cn  Ribbon SBC

　　www.freepbx.cn

　　https://kamailio.org/docs/modules/devel/modules/acc.html

　　https://www.opensips.org/Documentation/Tutorials-Advanced-Accounting

　　https://www.fcs.org.uk/image_upload/files/UK%20Standard%20CDR%20Format%20v3%20-%20Final.pdf

　　https://tools.ietf.org/html/rfc2865

　　https://tools.ietf.org/html/rfc2866

　　http://www.cs.columbia.edu/~dgen/papers/conferences/conference-10.pdf

　　https://tools.ietf.org/html/rfc6076

　　https://github.com/sip3io/sip3-ansible