CDR Variables

Text call detail records (CDR) can be used on the ProSBC, TMG800, TMG3200 or TMG7800. The Call Detail Records are saved in a log file on a local disk. An entry is made for each call leg, at the start of a call and at the end of the call. In addition, the system can be configured to update the CDRs periodically.

The format of the CDR traces is defined by configuration, using variables that are replaced by the Gateway application when writing to the log.

For example, the following variable will be replaced by the called number: @{CalledNumber}

In order to save disk space and simplify the archiving and backup of CDR log files, this log file is automatically archived (gzipped) and rotated every N seconds, as specified by the system configuration.

CDR Text Variables

The following variables can be used to define the CDR log format in CDR format (start), CDR format (update) and CDR format (end) configuration fields.

Variables used for identifying call (or call leg) in general

@{StatusType}:             Indicates the type of record ("Start", "Update" or "End").
@{LegId}:                  Unique Id for this leg (32 bits value).
@{OtherLegId}:             Id of the other call leg joined with current call leg.
@{SessionId}:              Unique call identifier for two joined and answered call legs, including failed outgoing call attempts (route retry)
                            Formatted as 4 values of 32 bits, printed as 4 blocks of 8 hexadecimal characters separated by a space
                            Ex: a939d169 299ffcd0 00000000 00000000
                            Note: Call Transfer Target legs have a separate SessionId. If you need an Id to correlate a transferred call
                                  to the original call, use @{OriginalSessionId}.
                            Note: Toolpack 2.9 and above support globally unique SessionId (unique across separate TMedia systems)
@{OriginalSessionId}:      Refers to @{SessionId} of the original legs for this call, in case of a call transfer.
                            In fact, Transfer Target leg has a different value for @{SessionId}, but can be linked with the original call
                            legs through @{OriginalSessionId}.
@{LinkId}:                 Same meaning as @{OriginalSessionId}, but presented as a 32 bit integer value.

For all Ids above, please see Known Limitations below for notes about the uniqueness of these values.

Timestamps

Information related to signaling

Information related to media

Statistics

The call statistics variable enables the printing of RTP, RTCP and T38 statistics in the text CDR logs.

  • Available only in the "end" CDR entry

Example:

  • Pkt=@{Stat:Rtp:Rx:Packets}/@{Stat:Rtp:Tx:Packets}, Err=@{Stat:Rtp:Rx:Errors}/@{Stat:Rtp:Tx:Errors}

Refer to the sub-page for the list of statistics (https://docs.prosbc.com/configuration-details/configuration-by-web-portal-category/call-detail-records-cdr/cdr-variables/call-statistics-available-in-cdr).

Information related to routing

Deprecated values:

CDR sample

Call sample with Start and End records

Redundancy

In a ProSBC 1+1 configuration, only the active server writes the CDR logs. Since the active server may change over time, CDR parsing must take into account that CDR logs may be found in files from the two servers.

The analysis of the logs for the purpose of extracting billing information must be done after combining the two logs, from both servers, sorting the entries by timestamp for example.

CDR entry loss due to switchover

In some situations (during HA switchover for example), some CDR entries may be lost.

Incoherent CDR during switchover

It is worth noting that some CDR records can be lost during transition from active to standby following a system fault. Consequently, a CDR analysis script must handle few "corner" cases:

A "Start" CDR entry without corresponding "End" entry

This happens if a call was terminated during the switchover period.

==> In that case, billing the call is not possible, the "End" CDR information was lost.

A "End" CDR entry without corresponding "Start" entry

This happens if a call was answered just before the HA switchover occurred, and the CDR entry was not yet flushed to disk.

==> In that case, billing can still be done using the "End" entry's "end time" versus "connected time" (unless connected time is 0, meaning the call was never answered)

A call with two "End" CDR entries

This case may happen after some partial HA switchover of the Toolpack system:

  • The CDR generating application (Gateway) remains alive, but looses it's connection with toolpack_engine

  • After a timeout, it destroys it's call contexts, and thus writes CDR "End" entries.

  • Later, connection with toolpack_engine is re-established, and some calls were still valid and connected

  • The Gateway application re-synchronizes with these calls. These call continue normally until they're hung-up

  • When hung-up, another "End" CDR entry is written

==> In that case, billing can be done by using the "end time" of the second CDR entry, minus the "connected time" of the first CDR entry.

Retrieving Text CDRs

There are 2 ways to retrieve the text CDR manually or automatically. The procedures are described in Retrieve Text CDR.

PreviousCall Detail Records (CDR)NextCall statistics available in CDR

Last updated

Was this helpful?