14 Public CDR Generation

Note:

CDR file generation can be enabled and disabled using the system setting Enable CDR Writer.

Oracle Communications Operations Monitor creates call detail record (CDR) files in CSV format. The files are placed in the cdr/ directory from the FTP/FTPS root. The CDR files have the following format:

palladion-unix_timestamp-sequence.csv

where:

unix_timestamp is the Unix timestamp when the file was created.
sequence is a number monotonically increasing.

The CDR files are rotated whenever one of the following three conditions is met:

The file reaches the maximum number of records. The maximum size is configurable in Operations Monitor with the system setting, Maximum lines of a CDR file. The default is 5000 records.
The maximum time is reached. The maximum time is configurable in Operations Monitor with the system setting, Rotate CDR files every N seconds. The default value is 0 for no time limit.
There is no new record for 150 seconds.

When a CSV file is finished, an empty CSV file with the following format is created:

palladion-unix_timestamp-sequence.csv.FIN

Several times per day, old CDR files are compressed to files having the following format, while the corresponding uncompressed files are deleted:

palladion-unix_timestamp-sequence.csv.gz

The recommended way of gathering the CDR files is to connect via FTP/FTPS, copy and delete all the files ending in csv.gz. Alternatively, to get the CDR data in near real time, the CDR files that have a corresponding FIN file can be copied and deleted.

Operations Monitor automatically limits the size of the cdr/ directory to 1 GB, by deleting the oldest files.

One record (CDR) for each call seen is created. If the call is visible in different segments, all of them are taken into account for computing the call details, but only a single record will be written. The call details are always the same as presented in Operations Monitor&rsquor;s web interface.

Operations Monitor also allows the creation of periodic CDRs for a call while a call is still active. This functionality can be enabled and disabled by using the system setting CDR Interim Update Interval.

By default the value should be 0. A value of 0 means no periodic CDR. The legal values for the system setting are between 1 and 10. This value represents the number of minutes at which a periodic CDR entry will be added to the CDR file.

Note:

Activating the periodic CDR functionality will have an adverse effect on performance.

Table 14-1 lists the fields present in the generated CSV files:

Table 14-1 CDR CSV Fields

Field	Description
acct_status_type	Used for the periodic CDR. Can be one of the following: start. This is the first CDR for an established call. update. This is a periodic CDR update for an already established call. stop. This is either the last CDR that closes an already established call or it is not a periodic CDR or it is a canceled/failed call. To determine which of the above it is read the sequence_number CDR field and also the state_msg.
avg_mos	The average of MOS estimation values according to the E-model, computed by Operations Monitor either from the RTP stream or from the end point messages, depending on availability.
avg_rtcp_delay	Average RTCP delay in milliseconds: If there is RTCP-XR with a delay value, this value is used. If there are multiple streams with RTCP-XR delay values, the average of those values is used. If there is no RTCP-XR delay value, the RTCP delay is calculated using pairs of RTCP Sender Reports (see RFC 3550)
callee_ip	The IP address of the called user that connected first. This field may be empty if the call was not successful.
caller_ip	The IP address of the device initiating the call.
callid	The Call-ID header value from the initial INVITE.
call_time	The duration in milliseconds of the call. The time is measured from the final successful message until the first BYE message.
diversion_params	This field contains a "; " (semicolon) separated list of the parameters of the first Diversion header we see in the call.
diversion_uri	This field contains the uri of the first Diversion header we see in the call.
dst_codecs	The codecs, in order, offered by the callee. In case the codecs are changed during the call by using re-INVITEs, this field will contain the last offer of the callee.
dst_ip	Destination IP address of the first INVITE message.
dst_mac	Destination hardware address of the first INVITE message.
dst_port	Transport layer port of the first INVITE message.
dst_ua	User agent string of the callee.
dst_uri	Session Initiation Protocol (SIP) URI of the callee as present in the In header field.
dst_user	The user to which the call is addressed. This is usually taken from the To header field of the first call leg, or as defined by the Number Determination algorithm.
dst_user_pref_tag	If the called user string is defined as the result of the Number Determination algorithm, this field is set to the numerical ID of the matching Number Determination rule.
dtg	The value of the dtg URI parameter from the Request-URI of the initial INVITE.
egress_devs	Comma-separated list of numerical device IDs of the egress devices for the call, that is, through which the call leaves the platform.
from_tag	The value of the tag parameter from the From header of the initial INVITE.
id	Unique identifier of the call within the Operations Monitor core instance.
ingress_devs	Comma-separated list of numerical device IDs of the ingress devices for the call, that is, through which the call enters the platform.
init_devs	Comma-separated list of numerical device IDs of the initiator devices for the call, that is, of devices that initiated a call segment without incoming segments.
max_rtcp_delay	Maximum RTCP delay in milliseconds. This is the maximum value of RTCP delay values seen across all streams for this call.
mec_ids	Comma-separated list of hexadecimal strings that can be used to correlate CDRs found on multiple Mediation Engines.
media_leg_locations	Comma-separated list of storage locations for Media Leg details. Voice quality records are kept in separate CSV files with Media Detail Records. For more information, see "Voice Quality Records (MDRs)". If an MDR is related to this call, its media_leg_location field will match one of the CDR media_leg_locations. Note: There may be locations without MDRs if no RTP stream was seen by Operations Monitor.
media_types	Indicates the media types that were negotiated in the call. Multiple media types are separated by a comma (for example: audio, video).
megaco_gateway	String with the IP address of the H.248/Megaco Media Gateway.
mgcp_gateway	String with the IP address of the MGCP Media Gateway.
MOS	The minimum MOS estimation according to the E-model, computed by Operations Monitor either from the RTP stream or from the end point messages, depending on availability.
otg	The value of the otg URI parameter from the From header of the initial INVITE.
pai	The uri of the P-Asserted-Identity of the initial INVITE.
pid	Identifier of the Operations Monitor core instance that created the record.
privacy	The value of the Privacy header of the initial INVITE.
q850_cause	This header contains the Q.850 cause code learned from native Q.850/ISUP signaling and NOT SIP.
realm_ids	Comma-separated list of numerical IDs of the realms the call belongs to.
ruri	The Request-URI from the initial INVITE.
sequence_number	A sequence number for each periodic CDR update entry. Is unique in the context of each call. For non-Periodic CDR it should always have the value of 1.
setup_delay	The duration for the call setup in milliseconds. The time is measured from the first INVITE messages until the last bit of the first provisional response is received.
setup_delay_type	The setup delay type used for the setup delay. Can be one of the following: Successful Session Request Delay Failed Session Request Delay
setup_start_ts	UNIX timestamp of the initial INVITE message.
setup_time	The duration in milliseconds of the call setup. The time is measured from the first INVITE message until the final successful answer.
sip_code	The SIP response code of the last received message from the INVITE transaction. For Failed calls, this represents the SIP error code.
sip_reason_cause	The code value of the SIP Reason header.
sip_reason_protocol	If there is a Reason header then this field shall contains the protocol of that header. Can be one of the following: SIP Q.850
sip_reason_text	The text explanation contained in the SIP Reason header. If the protocol is Q.850 then this field will be empty.
src_codecs	The codecs, in order, offered by the caller. In case the codecs are changed during the call by using re-INVITEs, this field will contain the last offer of the caller.
src_ip	Source IP address of the first INVITE message.
src_mac	Source hardware address of the first INVITE message.
src_port	Transport layer port of the first INVITE message.
src_ua	User Agent string of the caller.
src_uri	SIP URI of the caller as present in the From header field.
src_user	The user making the call. This is usually taken from the From header field of the first call leg or as defined by the Number Determination algorithm.
src_user_pref_tag	If the calling user string is defined as the result of the Number Determination algorithm, this field is set to the numerical ID of the matching Number Determination rule.
state_details	Operations Monitor can add details about the call state. Example: BYE seen but no 200 OK.
state_msg	Call state. It can be one of the following: Established. The call was successfully established. Redirected. The call was not established but was redirected. Finished. The call was successfully established and closed. Timed out. The call was successfully established but the BYE message was never received, so it expired. Error. The call was not recognized properly. Unauthorized. Canceled. Failed. The call failed to get established, or there was some other reason for not being successful. Not found. 404 User not found, 604. Off-line. 480. Busy. 486, 600. Terminated. 487 If a call is ISUP based, state message might differ.
term_devs	Comma-separated list of numerical device IDs of the terminator devices for the call, that is, of devices that terminated a call segment without outgoing segments.
to_tag	The value of the tag parameter from the To header of the initial INVITE.
trav_devs	Comma-separated list of numerical device IDs of traversed devices for the call, that is, of devices that have both incoming and outgoing segments.
uid	Unique identifier for the call, generated from the Call-ID, to_tag, and from_tag. Can be used for merging the CDRs generated by different Operations Monitor instances.

Note:

The fields ts, setup_time, and call_time are time related.

Because the hardware clock of the Operations Monitor server has limited precision over time, we recommend configuring NTP servers.
The timestamp precision may be affected by the delays introduced by tapping devices. The timestamp of the message is always saved the moment it reaches Operations Monitor&rsquor;s network interface.
The fields setup_time and call_time are computed by subtracting the timestamps of the messages INVITE, 200 OK, and BYE with a precision of milliseconds.

The field sip_code in the final CDR of periodic CDRs of a canceled call may be 200 (from the response to CANCEL) instead of 487 because writing the CDR is triggered after the end of the CANCEL transaction.

Customizing CDR Generation

You can customize CDR generation by adding more columns to CSV files based on the values from SIP request header fields. This customization can be enabled and disabled using the system setting Custom SIP headers in CDR file. For more information on system settings, see "System Settings Summary". The system setting Custom SIP headers in CDR file has a space-separated list of custom SIP header field names. For each custom SIP header field name in the list, a corresponding column of the same name, prefixed with Custom- is added to the CDR CSV fields listed in Table 14-1.

For example, when the system setting is set to X-Foo Bar, the two additional columns corresponding to the custom SIP header field names X-Foo and Bar are added in the CDR CSV file called Custom-X-Foo and Custom-Bar. The position of these columns is not guaranteed, so the software which processes these CSV files must take header names in the first line of the CSV file into account.

The value of the column Custom-X-Foo for a given call is a comma-separated list of all the values occurring in the X-Foo header field of all the SIP requests (in all segments) for the call. Each value occurs only once in the list. Note that a custom SIP header field can have multiple values per message (separated by commas or in multiple header field lines) and the custom SIP header field names are case sensitive.

Note:

Creating CDRs by enabling the Custom SIP headers in CDR file setting will have an adverse effect on the performance of Session Monitor.

When you enable CDR Interim Update Interval, the list of values of the configured custom SIP header fields for a call are cleared whenever an interim CDR is written. The lists of values in the final CDR of a call do not contain all the values from all the SIP requests belonging to that call. The final CDR has the values that are seen in requests since the last interim CDR.