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

　　

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

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

　

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

　　

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

　　3GPP針對CDR有著(zhù)非常詳細的規范說(shuō)明（ETSI TS 132 240），包括了漫游，在線(xiàn)費用，離線(xiàn)費用，呼叫和服務(wù)費用等非常詳細的說(shuō)明。用戶(hù)如果有興趣的話(huà)，可以參考ETSI TS 132 240 3GPP規范做更多了解。

　

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

　　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格式中規定了42個(gè)必要的呼叫參數，其中部分參數是可選參數。

　　除了標準的呼叫計費以外，美國特別針對NG9-1-1呼叫的計費也有規范說(shuō)明。此規范的目的是針對電話(huà)運營(yíng)商提供的緊急呼叫中計費的規范定義。為了滿(mǎn)足NG9-1-1的規范，很多呼叫的定義需要增加一些相應的變量設置，例如對呼叫的定義和總呼叫時(shí)長(cháng)的變量設置和log事件：

　

　

　　

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

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

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

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

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

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

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

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

　

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

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

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

　

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

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

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

　　OpenSIPS學(xué)習筆記-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做了最簡(jiǎn)單的描述：

　

　　這里可以看出，BYE消息是計費計算的一個(gè)基準數。

　　

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

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

　

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

　　通過(guò)dialog的ping實(shí)現BYE消息丟失的掛機控制的話(huà)，這是一種非標準的控制手段，它需要通過(guò)SIP 信令發(fā)送OPTIONS消息來(lái)實(shí)現。當然要求客戶(hù)端或者網(wǎng)關(guān)支持OPTIONS/INVIET消息。因為目前很多終端都支持發(fā)送OPTIONS消息或者re-INVITE, 相對來(lái)說(shuō)是一種比較簡(jiǎn)單的處理BYE消息丟失的方式，所以筆者推薦終端，ATA和網(wǎng)關(guān)設置OPTIONS消息檢測來(lái)實(shí)現BYE消息丟失的掛機處理。

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

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

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

　　

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

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

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

　　運營(yíng)商是否應該提供定時(shí)器設置來(lái)網(wǎng)絡(luò )檢測確認 200 OK返回ACK消息，以便確認話(huà)單的準確性。

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

　　UDP過(guò)度碎片化或者超過(guò)MTU數據限定，終端編碼協(xié)商等導致的問(wèn)題。

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

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

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

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

　　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） 等。

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

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

　　

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

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

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

　　首先，用戶(hù)需要在A(yíng)CC的表中插入acc的參數，通過(guò)mysql 命令執行此命令：

　　mysql -u root opensips

　　然后執行：

　　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;

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

　　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的參數：

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

　　$acc_extra（CALLER） = $fU;

　　$acc_extra（CALLEE） = $rU;

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

　　$acc_extra（TYPE） = "PSTN";

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

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

　　modparam（"acc", "leg_fields",

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

　　在leg 1的設置中增加：

　　$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）"）;

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

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

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

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

　　增加對ACC的數據支持，添加以下三行數據：

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

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

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

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

　

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

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

　　另外，我們的討論僅局限于比較簡(jiǎn)單的呼叫流程。因為呼叫流程涉及到很多具體的企業(yè)融合通信的業(yè)務(wù)流程，呼叫流程可能涵蓋多個(gè)終端或者其他第三方的應用，在CDR處理方面需要更多的靈活的支持，這些支持也需要媒體服務(wù)器做相應的配合支持。如果單純完全依靠OpenSIPS一個(gè)環(huán)境來(lái)處理的話(huà)顯然是不現實(shí)的。因此，為了能夠完整處理CDR數據，需要配合多個(gè)平臺聚合數據庫數據才能更加準確實(shí)現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