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

　　

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

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

　

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

　　

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

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

　

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

　　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個必要的呼叫參數(shù)，其中部分參數(shù)是可選參數(shù)。

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

　

　

　　

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

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

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

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

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

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

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

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

　

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

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

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

　

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

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

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

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

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

　

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

　　

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

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

　

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

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

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

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

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

　　

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

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

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

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

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

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

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

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

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

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

　　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的話可能還要涉及到其他的時延，例如PDD時延。

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

　　

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

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

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

　　首先，用戶需要在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進行cdr處理：

　　$acc_extra（TYPE） = "PSTN";

　　然后重新啟動OpenSIPS，通過PSTN呼叫進行測試，通過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的設置中增加：

　　$acc_leg（TYPE） = "USER";

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

　　在leg 2增加

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

　　$acc_leg（CALLEE） = $rU;

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

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

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

　　默認環(huán)境下，CDRVIEWER記錄僅支持CDR的記錄，沒有顯示ACC表的記錄消息。用戶可以通過修改CDR的配置文件顯示更多關于ACC模塊的參數(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，用戶會看到我們剛才添加到ACC模塊數(shù)據(jù)。

　

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

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

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