Page MenuHomePhabricator

CDR
AG Projects RTC Platforms (Accounting Guides)

This document describes CDR generation, normalization, search and export.

The platform generates usage information in the form of rated Call Detail Records (CDR). It is the responsibility of the Operator to import the rated CDRs into its own billing system and to generate printable invoices out of them.

The CDRs can be easily searched and grouped by various criteria and exported into comma separated value files. Accounting can be done postpaid (default option) or prepaid (enabled per SIP account). Postpaid accounts can have a monthly quota assigned to prevent fraud.

book-general-sip-platform-cdr-flow (427×694 px, 74 KB)

CDR Generation

Call detail records (CDRs) are generated from the SIP sessions established through the platform. A CDR contains relevant information about a SIP session from both signaling and data planes. The CDR is generated by combining several Radius requests from OpenSIPS and MediaProxy as follows:

Radius requestWhenComponentDescription
FAILEDFirst INVITE with negative codeOpenSIPSZero second (failed) session
STARTFirst INVITE with positive codeOpenSIPSStart of new session
STOPBYEOpenSIPSStop of existing session
UPDATERTP stopMediaProxyStop or timeout of existing RTP stream

Radius logs

Radius requests generated by the platform are logged by the Freeradius server in the following places:

DirectoryLog type
/var/log/freeradius/radacct/IP/detail-YYYYMMRadius tickets contents
/var/log/freeradius/radacct/radius.logRadius errors

The most relevant attribute of a CDR is the session duration. The cost for the session depends on this session duration. The sessions duration is determined by the Stop time and Start time of the SIP session. The Start time is considered the moment when the answer for the first INVITE has entered the SIP Proxy. Stop time is determined either by the presence of BYE message or in case BYE is missing from the last moment RTP has ben relayed though MediaProxy.

It is not possible to determine the stop time of a session in the following situation:
  1. First INVITE is answered with a positive code
  2. No BYE is received
  3. No RTP data has been relayed

Media timeout

If the RTP media has timed out (both parties stopped sending RTP) while no BYE has been received by the SIP Proxy:

  1. MediaProxy will set in the Radius UPDATE the MediaInfo Radius attribute to *timeout*
  2. MediaProxy will trigger the sending of a a BYE message via the dialog module of OpenSIPS

In this situation, the actual duration of the SIP session contains the period of the RTP stream plus the value of the timeout. The value of the timeout is determined by the connection tracking logic in the Linux kernel. At this moment there is no mechanism to store into the Radius database the value of this timeout, which is typically 180 seconds.

CDR tables

CDRs are stored in monthly tables in radius database. The tables are named radacctYYYYMM. Tables are automatically created by the Radius server at the beginning of each month.

CDR fields

FieldTypeDescriptionNotes
RadAcctIdbigint(21)MySQL unque index auto-incremented
AcctSessionIdvarchar(255)SIP call-id header
AcctUniqueIdvarchar(255)Radius internal session id
UserNamevarchar(64)SIP UsernameMatched against billing_customers.subscriber
Realmvarchar(64)SIP domainMatched against billing_customers.domain
NASIPAddressvarchar(15)SIP Proxy IP
NASPortIdvarchar(50)SIP Proxy port
NASPortTypevarchar(255)not used
AcctStartTimedatetimeSession start time
AcctStopTimedatetimeSession stop time
AcctSessionTimeint(12)Session duration used for rating
AcctAuthenticvarchar(32)not used
ConnectInfo_startvarchar(32)not used
ConnectInfo_stopvarchar(32)not used
AcctInputOctetsbigint(12)Relayed RTP through MediaProxy
AcctOutputOctetsbigint(12)Relayed RTP through MediaProxy
CalledStationIdvarchar(50)SIP To header, the original dialed number
CallingStationIdvarchar(50)SIP From header
AcctTerminateCausevarchar(32)SIP response code
ServiceTypevarchar(32)Sip-Session
ENUMtldvarchar(64)ENUM top level domain used for lookup
FramedIPAddressvarchar(15)not used
AcctStartDelayint(12)not used
AcctStopDelayint(12)not used
SipMethodvarchar(50)SIP method
SipResponseCodesmallint(5) unsignedResponse code for INVITE
SipToTagvarchar(128)SIP to tag
SipFromTagvarchar(128)SIP from tag
SipTranslatedRequestURIvarchar(255)Final network address after DNS lookup
SipUserAgentsvarchar(255)SIP user agents/servers reported by MediaProxy
SipApplicationTypevarchar(255)Media type (e.g. audio)
SipCodecsvarchar(255)RTP codecs report by MediaProxy
SipRPIDvarchar(255)PSTN caller id
SipRPIDHeadervarchar(255)not used
SourceIPvarchar(255)Source IP of the sessionMatched against billing_customers.gateway
SourcePortvarchar(255)Source port of the session
CanonicalURIvarchar(255)Final logical destination used for ratingMatched against destinations table
DelayTimevarchar(5)not used
Timestampbigint(20)Packet timestamp
DestinationIdvarchar(15)Normalized E.164 prefixCalculated during normalization
RatetextDescription of rate calculationCalculated during normalization
Pricedouble(20,4)Cost of the sessionCalculated during normalization
Normalizedenum('0','1')If the CDR has been normalized
BillingIdvarchar(255)Reseller id used by trusted peers and SIP domainsCalculated during normalization
MediaInfovarchar(32)Mediaproxy information
RTPStatisticstextRTP statistics reported by some devices
FromHeadervarchar(128)not used
UserAgentvarchar(128)SIP User Agent and Server headers
Contactvarchar(128)not used

CDR Normalization

A CDR is considered closed when the stop time has been determined. Once the CDR is closed, a normalization process cleans up the CDR fields and calculates the price of the session. The price and the way it was calculated is saved together with the CDR in the same table. It is possible to re-normalize the sessions at a later time, for instance when the tariffs need to be changed for the past period.

Normalization is performed periodically:

  1. Whenever CDRTool web search is used
  2. By the cron job /var/www/CDRTool/script/normalize.php

Once normalized, the CDRs are no longed modified, the normalization process marks each CDR that has been processed.

OperationWhenPlatform componentDescription
NORMALIZEAfter CDR was closedCDRToolRating is applied

Un-normalized sessions

Some SIP sessions can remain in the CDR database in an un-normalized state. They show in CDRTool as "in progress". Such sessions have a start date but no end date. Such sessions cannot be normalized automatically by the CDR normalization process because there is no indication when they have actually stopped. A SIP session is considered stopped when either a BYE message has been received by the SIP Proxy or when the RTP media has stopped flowing between the end-points, which is detected by the MediaProxy. If the RTP media has not started yet and no BYE has arrived after the initial INVITE/200 OK/ACK, there is no physical indication for when the session has started or when it ended. Due to the nature of the SIP protocol and in particular the fact that the RTP media is carried separately from the SIP signaling, it is always possible to have SIP sessions that from a call completion perspective have started but never ended. Such situations occur outside the control of the operator responsible for the SIP service. You may chose to apply your own policy for such sessions like deleting or archiving them.

CDR Search

CDRs can be searched and displayed in CDRTool. Access to CDRTool can be provided to resellers or end-users of the platform.

book-general-sip-platform-cdr-search (527×1 px, 108 KB)

Last placed and received calls are also available for every SIP account using SOAP/XML functions:

  • SipPortgetCalls()

CDR Export

CDRs can be exported from CDRTool in comma separated values (CSV) format or by selecting the raw content of the MySQL radacctYYYYMM tables. Such operation can take time to complete and is advisable to use always a MySQL slave server for these queries.

Next Steps

Continue by: