OpenSIPS学习笔记-ACC模块/事务-CDR记录以及BYE消息丢失-

　　VoIP计费是SIP软交换运营平台的一个核心功能，计费处理流程和呼叫流程有着非常紧密的关系。运营商对计费有着各种不同的规范和常规设置，不同的国家和运营商之间也都有着不同的设置机制，因此关于计费也存在一些不同的标准。但是，绝大部分的场景中，CDR计费都相对比较规范，在一些特殊场景中，软交换计费系统需要针对一些故障处理增加相应的支持来保证计费的准确性和完整性。OpenSIPS使用的ACC模块和CDR就实现了运营级计费的功能支持。在本文章中，我们主要针对OpenSIPS的ACC模块和CDR处理进行讨论，呼叫中BYE消息丢失问题的处理方式进行讨论。另外，笔者将针对关于两种常见计费问题中的网络故障和会话关闭时延的问题进行讨论，最后，笔者将通过完整的多腿CDR配置示例来说明OpenSIPS中的计费处理和配置文件。

　　1关于VoIP中CDR处理的背景介绍

　　在PSTN时代，运营商的CDR计费本身已经存在了，随着IP语音的突飞猛进，包括现在基于VoLTE语音的部署，计费的模式也逐渐发生了变化。在目前最新的VoLTE网络中，因为一个SIP呼叫跨越了很多的节点路径，计费的流程更加长一些，涉及的各种延迟也更多一些，比较重要的参数例如，Post-dial delay（PDD或者SRD）。这些延迟会影响计费的时长和话单的准确性。另外，每个国家可能因为环境的不同对CDR参数设置也有不同的要求，还有很多场景中需要紧急电话服务的话，电话系统必须需要支持规范的呼叫格式和对呼叫进行不同的定义。

　　此图例以及以下图例均来自于互联网资源

　　因为在SIP网络中，根据不同的SIP初始请求所产生的事务和dialog也可能完全不同，因此请求的不同也产生了不同的CDR消息记录。这些请求可以是：INVITE，REGISTER，SUBSCRIBE，OPTIONS，MESSAGE和INFO。

　　这些请求的返回数据都需要根据不同的请求生成一个完整的CDR记录。这些数据的处理相对就复杂很多，需要专门的CDR服务器做解析生成。另外，在CDR生成时，SIP dialog和事务都有各自的会话结束方式，这又增加了CDR生成的逻辑流程，它们通过bCDR和cCDR实现基础CDR和合并CDR的生成，并且创建了dialog和事务的连接。

　　研究人员Tamás Tóthfalusi 发布了针对VoLTE的CDR生成做了比较详细的分享说明和关于CDR生成的研究成果。在其论文中比较详细说明了VoLET环境中SIP呼叫和CDR生成的研究。读者可以参考其论文做进一步的研究。

　　3GPP针对CDR有着非常详细的规范说明（ETSI TS 132 240），包括了漫游，在线费用，离线费用，呼叫和服务费用等非常详细的说明。用户如果有兴趣的话，可以参考ETSI TS 132 240 3GPP规范做更多了解。

　　3GPP仅是针对网络环境做的关于CDR的规范说明，一些国家也专门发布了自己的运营商CDR规范说明。在英国的CDR规范说明中包括了固话，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格式中规定了42个必要的呼叫参数，其中部分参数是可选参数。

　　UK的CDR的标准的呼入格式规范：

　　除了标准的呼叫计费以外，美国特别针对NG9-1-1呼叫的计费也有规范说明。此规范的目的是针对电话运营商提供的紧急呼叫中计费的规范定义。为了满足NG9-1-1的规范，很多呼叫的定义需要增加一些相应的变量设置，例如对呼叫的定义和总呼叫时长的变量设置和log事件：

　　通过以上简单的背景介绍，我们可以看到，生成一个完整的CDR是非常复杂的流程，这里需要数据业务数据的参与，同时需要满足不同国家的规范的要求，并且有时如果电话系统需要紧急呼叫支持的话，系统配置也要具备一定的灵活性支持其业务要求。在第二个章节，笔者将具体介绍OpenSIPS环境中的ACC模块的存储方式讨论。

　　2OpenSIPS的Accounting 事件的存储讨论

　　为了帮助大家了解更多关于CDR计费的基本概念和应用的场景，笔者在前面章节介绍了一些关于CDR计费的一些基本知识，行业规范和几个具体的应用广泛，其目的是帮助读者了解CDR计费以外的一些业务要求，在扩充CDR支持能力时可以对其要求有比较充分的认识。当然，因为水平资源有限，笔者也没有能力对CDR处理有非常全面的了解，这里主要是提醒读者了解更多关于简单CDR以外的内容。

　　如果具体到今天核心的主题-SIP网络环境或者OpenSIPS平台的话，我们主要介绍关于OpenSIPS环境中ACC模块的功能和其存储方式。OpenSIPS的呼叫ACC模块或者Accounting是一个非常重要的模块。用户在部署OpenSIPS时不可避免需要接触到ACC模块。ACC模块涉及了几个主要的概念，包括ACC event，ACC核心内容和ACC后端存储处理，其他ACC拓展参数支持和多腿呼叫的CDR记录等几个方面的内容。

　　首先，我们需要明确的是ACC事件，ACC事件简单来说就是事务处理状态的事件，包括成功事务事件，失败事务事件和丢失的事务事件等。这些事件和呼叫本身有紧密的联系。我们前面的讨论中也说明，根据CDR规范，呼叫的事件都需要通过两种方式进行存储，一种是系统log的形式，另外一种是后端数据库存储的方式。OpenSIPS也同样遵守这个规范。在前面的介绍中和以前的历史文档笔者都有说明，在一个呼叫中需要通过事务处理和dialog处理，它们有着各自不同的处理方式，因此，在ACC需要支持事务和dialog实现对CDR的完整记录。OpenSIPS的ACC模块可以支持消息，事务和dialog。ACC中的消息包括多种消息，例如INVITE和BYE等。这些ACC的消息都可以通过log，数据库存储，Radius和Events形式进行存储。笔者在后续的章节会分别介绍这些处理过程。

　　如果读者不清楚关于事务，会话和dialog的区别的话，建议首先阅读笔者历史文章：再论SIP呼叫中的Call，Dialog和Transaction

　　在后续的关于CDR计费时长的讨论中，我们将使用事务处理的概念，读者一定要明确这个概念，以免混淆了整个计费的设置。

OpenSIPS可以对以上数据进行后端存储支持，支持的存储方式包括：
log，支持系统的log文件
数据库，支持MYSQL，PG和甲骨文数据库等开源数据库
AAA，支持Radius和Diameter（比较老的版本可能支持，读者自己查阅官方文档）
EVI，event接口包括RabbitMQ，Datagram Event

　　关于Acc Scope的具体设置支持，和其他数据库设置支持的细节，读者可以访问官方文档做进一步了解。需要注意，如果需要设置ACC 模块时，用户需要经过几个流程设置：

加载模块和相应参数
为初始的INVITE请求设置ACC支持
为BYE请求设置ACC支持
为ACC设置支持丢失呼叫配置

　　笔者在后续的示例配置中会体现以上核心步骤。

　　3Accounting 事件的讨论

　　在OpenSIPS的ACC模块中，主要支持四种事件的状态，包括事务成功事件，成功的dialog事件，丢失的呼叫事件，失败的事务事件。

　　在以上的事件状态中，其他几种事件相对比较容易处理，丢失的呼叫事件是一个相对比较困难处理的事件。在丢失呼叫的事件中包括两种状态，一种是丢失的事件，另外一种是成功的事件。因此，如果做CDR处理时需要同时记录这两种事件对应不同的UAS。我们经常可能遇到，如果是一个fork呼叫或者按续呼叫过程中，如果第一个呼叫失败以后会继续呼叫，继续对第二个目的地进行按续呼叫的流程。这种丢失呼叫的事件需要特别留意，否则CDR统计结果就会产生错误。

　　这里提醒读者，在处理这些事件中，成功的事务处理和失败事务处理会存储到同一ACC的表中，丢失的呼叫事件则会存储到missed call 的表中。当然，用户也可以自己修改表名称方便自己的部署环境。

　　4OpenSIPS中关于多腿呼叫的计费讨论

　　计费是一个非常重要的功能，无论是使用开源媒体服务器，例如Asterisk还是FreeSWITCH，或者使用SIP软交换服务器，例如OpenSIPS和Kamailio或者很多商业IPPBX。很多用户忽略了一个非常复杂或非常细节的问题，那就是在呼叫经过多次转接或者停靠以后的计费处理。通常的CDR中，我们仅简单计算了从呼叫方到被呼叫方的总时长。特别是在企业IPPBX的应用场景中，我们仅考虑了呼入方到一个内部分机之间的呼叫时长，但是，读者是否考虑过如果呼入以后涉及了电话盲转或者询转，或者执行了一个分机随行以后继续呼叫一个外部电话号码或者长途固定电话。如果涉及到了其他额外呼叫流程的话，严格来说，这些呼叫都需要分段计费，有的呼叫可能是不计费的（例如呼入）并且通过分段计费最后聚会成一个完整的CDR计费。不幸的是，很多的IPPBX并没有进行这么详细的处理，仅简单笼统地计算了一个呼叫的总时长。因此，这样的处理结果不是一个正确的CDR计费流程，只能算是一个CDR统计，它不能作为话单结算数据。在如下示例中，按照目前正常的计费模式，如果A呼叫B，B然后转接到C端手机的话，从A到B是免费的，但是，从B到C端可能是付费的，这里涉及了谁将为B到C支付问题。如果按照标准的CDR计费的话，A应该对C端付费，事实上这完全是一种错误的计费方式。因此，针对复杂业务场景中，多腿分段计费是一个必要的计费方式。为了支持多腿呼叫，OpenSIPS支持多腿计费时需要重新创建一个新的acc_new_leg（）进行支持。

　　作为一个运营级的SIP软交换，OpenSIPS和Kamailio在早期版本并没有真正实现多腿CDR的支持。在后期的OpenSIPS的发布版本中开始支持了多腿CDR记录支持。通过多腿计费保证了CDR的准确性和完整性。OpenSIPS在多腿CDR支持时增加了一个对中间跳板的记录，分别对分段处理进行存储支持。正常的CDR仅保存呼叫源和最终目的地的存储。OpenSIPS通过支持多腿CDR实现了非常完整准确的CDR计费。这里提醒读者，在ACC中，事务记录中的duration是为空的，在CDR记录中则包含了duration值。

　　在数据库生成的示例数据如下，包括了用户1到用户2，用户2到用户3的完整的多腿CDR记录。

　　5OpenSIPS环境中关于BYE丢失的处理

　　在呼叫过程中，因为网络原因或者其他的终端原因，很多情况下我们会遇到呼叫失败的问题。呼叫失败不仅仅会影响呼叫方的体验，同时也影响计费结算结果。在一些呼叫中，我们经常会收到没有BYE请求返回的问题，或者叫BYE消息丢失的问题。没有BYE消息的话，CDR计费就产生错误。这对CDR生成是一个非常大的挑战。在以前的历史文档中，我们讨论了dialog状态和计费启动的机制，读者可以参考OpenSIPS中的dialog使用和计费的说明：

　　OpenSIPS学习笔记-Dialog的五种状态及配置示例

　　研究人员Dimitris Geneiatakis在早期发表的关于CDR算法讨论-A Mechanism for Ensuring the Validity and Accuracy of the Billing Services in IP Telephony中对CDR做了最简单的描述：

　　这里可以看出，BYE消息是计费计算的一个基准数。

　　有时，如果没有及时处理BYE消息丢失的问题的话，可能CDR时长就会不断增加。本来一个呼叫可能已经在3分钟内结束了，但是因为没有收到BYE消息，最后通话时长可能是10分钟或者20分钟甚至于更长时间。这样计费就会产生很多问题。如果出现了丢失BYE消息以后，系统平台应该有一定的机制来及时正确执行挂机，保证其CDR计费出现问题。另外，如果系统平台对并发呼叫有限制的话，丢失了BYE消息以后，这样的限制设置可能会产生错误的结果。

　　目前，在SIP网络环境中，OpenSIPS运营平台结合其他手段来执行丢失BYE消息以后的挂机处理。各种处理方式都有其各自的特点。

　　使用标准的SIP定时器时，SIP会话定时器设置超时以后，结束会话或者重新发起一个re-INVITE请求或者update，经过几个周期以后对呼叫挂机。它要求客户端或者网关能够支持会话定时器设置支持。当然，如果终端和网关都在同一公司内网环境中的话，用户可以控制设备的配置，比较容易设置定时器支持。如果是运营级的应用场景的话，建议用户通过网关或者SBC来设置定时器支持。RFC4028对SIP会话定时器有非常明确的规范，读者可以参考RFC4028做进一步了解。

　　通过dialog的ping实现BYE消息丢失的挂机控制的话，这是一种非标准的控制手段，它需要通过SIP 信令发送OPTIONS消息来实现。当然要求客户端或者网关支持OPTIONS/INVIET消息。因为目前很多终端都支持发送OPTIONS消息或者re-INVITE, 相对来说是一种比较简单的处理BYE消息丢失的方式，所以笔者推荐终端，ATA和网关设置OPTIONS消息检测来实现BYE消息丢失的挂机处理。

　　最后一种方式是通过RTP提示来对BYE消息丢失进行处理。这种处理方式也是一种非标准的处理方式，但是，它需要通过RTP流的检测来实现。OpenSIPS不能支持RTP超时检测，所以只能通过媒体服务器端通过对双方的RTP流检测或者静音检测来实现挂机处理。如果媒体服务器检测到双方的RTP语音流无任何有效数据时，说明双方已不再继续通话，所以执行挂机处理。这种检测方式也没有对终端有任何的要求。如果以上两种处理方式不能使用时，读者也可以考虑通过媒体服务器检测RTP语音超时来实现。开源媒体软交换Asterisk和FreeSWITCH都可以支持这样的检测机制来实现BYE消息丢失的挂机。但是，这种检测机制很难非常准确及时地实现挂机处理。因此，如果要实现CDR记录的完整性和准确性，这是一个相对比较差的选择。

　　再次说明，选择何种处理方式需要用户根据自己的部署环境做判断，最终使用一个较低成本的方式来解决问题，笔者仅提供一个比较完整的建议。

　　6CDR计费中网络故障和会话时延的问题讨论

　　大部分情况下，我们的通话是在正常状态完成，整个CDR数据也非常正确。但是，在基于SIP网络环境中，特别是基于云平台或者全球部署的呼叫环境中，呼叫过程中出现网络故障是非常正常的事情。因为网络故障，整个Acc 模块的记录就会出现问题，最终导致CDR和话单错误。如下示例中，如果运营商和用户代理服务器之间出现了网络故障，如何进行结算是一个比较头疼的问题。

　　在以上示例中，运营商已经对代理服务器发送了200 OK，但是代理服务器和运营商之间的网络出现了故障以后，我们需要特别关注是运营商支付这个话单还是我们的代理服务器负责支付这个话单。这里有几个争议的地方需要大家讨论：

　　对运营商来说，它已经发送了 200 OK，网络问题可能不是运营商端的网络问题。

　　对客户代理服务器来说，代理服务器没有收到 200 OK, 当然也没有继续发送后续回复（BYE，ACK等）信息到运营商端，客户代理服务器也可能拒绝支付这个话单。但是，如果是运营商上游呼叫的话，运营商和上游呼叫方已经产生了话单，如何处理这个呼叫的话单也是一个问题。

　　运营商是否应该提供定时器设置来网络检测确认 200 OK返回ACK消息，以便确认话单的准确性。

　　一些运营商和代理之间的网络问题很难准确及时到位。

　　UDP过度碎片化或者超过MTU数据限定，终端编码协商等导致的问题。

　　网络质量差导致的PDD时延

　　在一些小并发的呼叫环境中，可能这样的故障不会引起太多的问题，但是如果并发量在1W以上的话，网络故障引起的计费就会导致很大问题。这里，笔者抛出的这些问题的目的是让用户知道这些问题的存在，具体如何兑付话单和运营商如何协商不在笔者讨论范围之内，很多运营商对此问题有着不同的商务解决方案。笔者在这里讨论的目的是网络稳定是正确计费的非常重要的前提条件。

　　计费中另外一个比较重要的话题是会话挂机时延。大家讨论到计费通常可能比较关心的是价格。事实上，在运营商提供的SIP trunk或者其他线路服务环境中，除了价格以外，语音稳定和语音质量以外，用户好像没有太多的指标来判断线路运营商的服务水平。事实上，除了笔者前面提到的结果指标以外，用户端可能还要注意几个潜在的问题。这些设置指标可能有的是运营商故意设置的，有的是因为运营网络被动体现出来的。

　　一些比较“聪明”的运营商为客户提供了相对比较低的价格，用户自己体验也没有发现什么大的问题。但是，如果运营商因为服务器处理能力问题或者其他硬件问题的限制，在计费中故意设置了一些参数的话，整个呼叫的时间就会延长，但是，一般用户可能没有什么特别明显的反应。在呼叫流程中，几个需要用户特别关注的延迟设置可能会导致整个通话的时延，而且运营商在任何一个节点做延迟设置都可能影响整个通话的计费。因此，时延的问题需要读者认真去考虑。以下示例就是在SIP呼叫中，各种会话响应之间的的创建所消耗的时间。

　　在以上图例中，我们可以看到各种时延的设置。根据RFC6076规范，各种会话时延都有比较明确的规定，包括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）等。

　　如果是传统PSTN的话可能还要涉及到其他的时延，例如PDD时延。

　　这些时延构成了评价SIP端对端性能的评价指标。虽然很多SIP运营商都声称自己的SIP服务如何优质，但是，笔者建议避免使用空洞夸张的市场语言来说服用户，最好还是给出一个客观的数据来说服用户。在SIP端对端的执行性能评价指标中，SDD是一个非常重要的指标。在INVITE呼叫中其中一个比较重要的时延就是SDD的时长。根据RFC6076规范说明，SDD是介于BYE消息和其200 OK返回消息之间的时延时间。

　　这里读者一定要注意，在OpenSIPS的CDR中的呼叫时长是基于事务（Transaction）时长来计算的，不是基于请求时长来计算的。我们假设已经收到了BYE消息，但是，计费结束是以BYE消息的200 OK返回消息为计算基准的，如果BYE消息和其返回的200 OK消息之间的时长有过多时延的话，计费就不是非常准确，运营商端处理返回消息出现了时延，可能最后导致客户端实际数据延长。如果运营商和客户端之间的事务结束时间延迟以后，这个计费时长就会延长。运营商收到BYE以后，在正常时间范围内（1秒钟内）返回200 OK是正常的，但是，如果运营商在一定延迟以后再发送200 OK，整个计费时长就会增加。

　　很多企业级的IPPBX或者SIP软交换平台没有具体的采集SIP metrics 集成解决方案，这里笔者介绍一个开源的解决方案 SIP3，它可以集成多个SIP IPPBX，和RTP语音评价指标，通过界面来显示其相关的SIP评价指标。具体项目链接查阅参考资料。

　　7OpenSIPS的ACC模块和多leg CDR示例配置

　　OpenSIPS 支持ACC和CDR的模块来实现计费处理。如果需要实现ACC模块和CDR模块的处理需要经过以下几个步骤。

　　首先，用户需要在ACC的表中插入acc的参数，通过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;

　　接下来配置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进行cdr处理：

　　$acc_extra（TYPE） = "PSTN";

　　然后重新启动OpenSIPS，通过PSTN呼叫进行测试，通过OpenSIPS Control Panel -> System -> CDRViewer查看CDR记录。

　　如果需要支持多腿呼叫CDR的话，用户需要执行以下步骤。修改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（）; // 创建了一个新的leg

　　在leg 2增加

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

　　$acc_leg（CALLEE） = $rU;

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

　　执行了呼叫前转设置。重新启动OpenSIPS，然后再通过界面修改用户配置文件，增加前转支持，呼叫从1002前转到一个PSTN的号码上。

　　保存以上配置。然后进行呼叫测试，通过1000呼叫SIP 用户1002，1002将会前转到一个PSTN的号码上。通过控制界面查看CDR记录，我们会看到分别与两个腿的呼叫，从1000到1002，然后1002到2345678 PSTN号码。

　　默认环境下，CDRVIEWER记录仅支持CDR的记录，没有显示ACC表的记录消息。用户可以通过修改CDR的配置文件显示更多关于ACC模块的参数设置。用户需要修改配置文件：

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

　　用户需要重新刷新界面，查看CDRviewer，用户会看到我们刚才添加到ACC模块数据。

　　8总结

　　CDR处理是VOIP的核心功能，每个运营商和很多国家对关于其部署和使用都有非常明确的规范，特别是在VoLTE网络中，CDR的处理变得更加复杂。笔者在本文章中讨论了关于OpenSIPS的ACC模块和CDR计费模块的细节流程，另外讨论了关于CDR计费时的一些相关问题的处理，多腿计费的正确处理流程，特别针对丢失BYE消息的处理，需要关注关于网络故障以后的CDR数据生成，会话关闭时延问题讨论和关于OpenSIPS环境下多腿示例的配置以及如何修改cdrviewer显示ACC 表的更多信息。

　　因为CDR的细节很多涉及了具体的业务规范，笔者这里讨论的仅局限于OpenSIPS和一般的企业IPPBX呼叫场景中，这里没有涉及一些运营商级的CDR级或者其他业务场景的讨论，很多场景实际上和具体业务规范有非常紧密的关系，因此在处理方式上也存在很多差异。希望读者根据自己的业务场景来理解CDR的流程，笔者文章作为一个部署OpenSIPS的参考。

　　另外，我们的讨论仅局限于比较简单的呼叫流程。因为呼叫流程涉及到很多具体的企业融合通信的业务流程，呼叫流程可能涵盖多个终端或者其他第三方的应用，在CDR处理方面需要更多的灵活的支持，这些支持也需要媒体服务器做相应的配合支持。如果单纯完全依靠OpenSIPS一个环境来处理的话显然是不现实的。因此，为了能够完整处理CDR数据，需要配合多个平台聚合数据库数据才能更加准确实现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