Local CDR Storage and FTP Push
The local CDR storage feature allows you to save RADIUS CDR data to a local CSV text file on the OCSBC. Local CDR file creation and storage can be used in addition to or independently of sending CDRs to RADIUS servers for every call. Once the OCSBC creates and saves local CDR files, you can:
- Send the files to an FTP server by configuring a push receiver
- Develop and implement your own script for retrieving them as necessary from the OCSBC
You configure the OCSBC to:
- Set directory path where you want to save local CDR files
- Set a maximum file size for the CSV file
- Set a maximum number of local CDR files
- Set an interval in which to close the existing local CDR file and begin writing a new file.
Once local CDR file creation is enabled, you can configure push receivers to push any non-active and closed CDR files to an FTP server using FTP or SFTP protocols. You configure the OCSBC with the push receiver’s:
- server IP address and port information
- login credentials
- path to save the local CDR Files
- The interval at which the OCSBC should send files to a push receiver
For flexibility and security, the OCSBC can log into a push receiver with either FTP or SFTP. If you are creating a secure connection with SFTP, your OCSBC can authenticate to the server with either a public shared key or SSH-encrypted username and password.
Bear in mind that the OCSBC deletes a local CDR file after the local CDR file has been successfully transferred to a push receiver.
Local CDR File Format
The CDRs are written as comma-delimited ASCII records to files on the OCSBC. The types of records are controlled by the same accounting configuration parameters used for RADIUS. The fields of the comma-delimited entries correspond to RADIUS START, INTERIM, and STOP records. Using the accounting configuration, you can configure the OCSBC to record STOP records only.
Because the record types do not have consistent field positioning, any server parsing them would need to read the first field to determine the type and learn how to parse the remaining fields.
Local CDR File Format Consistency
Unpopulated or unused fields in the RADIUS CDR are omitted from the locally-stored CSV file. This means that there is no fixed position for a RADIUS attribute across all CSV files. Instead, the missing values are skipped in the CSV file so that the order and appearance for attribute values can differ from record to record.
You can optionally guarantee the placement of attributes in locally-stored CSV files with the cdr-output-inclusive parameter. With this enhancement enabled, RADIUS records sent to a RADIUS client contain even empty attributes with an integer, date and time, or IP address format; the default value is zero. In other words, when there is no value to report:
- An IP address attribute will report as 0.0.0.0
- A date and time attribute will report as 00:00:00.000 UTC Jan 01 1970
- An integer attribute value will report as 0
To maintain RFC 2865 and 2866 compliance, the Oracle Communications Session Border Controller will not send empty attributes that are string values to a RADIUS client. And when you enable this feature, the Oracle Communications Session Border Controller adds all attributes to the locally-stored CSV file.
Refer to Appendix B of this document for an example of where VSAs appear in a locally-generated CSV file for a successful Interim record.
Generate Local CDR Layout Files
Numerous factors determine the layout of local CDR files. In order to obtain an accurate local CDR layout, the SBC can write a special CDR layout file that only includes the data layout for your local CDRs based on your configuration. You can then use this file to interpret local CDR files with the proper data field order, source and identification label.
You can configure the system to produce CDR layout files with the dump_csv_format command at the superuser prompt.
ORACLE# dump_csv_formatThis function uses the same process, input and output mechanisms the system uses to produce local CDRs. While this command is activated, the system produces layout files instead of actual CDRs. Once the layout files have been obtained, turn the generation feature off with the no_dump_csv_format command at the superuser prompt.
Format files are written to the same directory as local CDR files, and they use the same naming convention as local CDR files. Refer to local CDR generation instructions to identify the files you intend to retrieve, based on your configuration for rotation, naming, file size, and so forth.
Note that the push-receiver configuration may not be an efficient means of retrieving your local CDR format files because they are configured for time and size windows appropriate for CDR collection. Use SFTP manually to control what and when you retrieve.
Preform this procedure in a maintenance window. You must have complete control over prototype calls. Limit them to a single successful, and depending on your configuration, single unsuccessful call. The following is the general procedure used to capture local CDR layout files.
- Turn on dump_csv_format from the system's enable prompt. The system stops generating local CDR files, generating local CDR format files instead.
- Place a successful call.
- Complete the call.
- If you are configured for INTERIM generation upon an unsuccessful call, place an unsuccessful call.
- Depending on your configuration, identify the file that has the format. For example, if using rotation you may decide to wait for the data to rotate from the temp file to be sure the file is closed.
- Use SFTP to retrieve the layout file from the local CDR directory.
- Turn off the feature using no_dump_csv_format. The system begins to generate local CDR files again.
- Use the files to identify your CDR format and establish your collection and collation process.
Local CDR Layout File Reference and Example
Local CDR Layout File Reference and Example
The first line of every record contains the following comma-delimited information:
"1", "Accounting Status", ,"40",["## START ##" | "## INTERIM ##" | "##STOP##"]Each line after the initial line of each record contains the following comma-delimited information:
<CDR Attribute position>,<CDR Attribute Name>,<VSA Vendor>,<VSA Number>The CDR Attribute name only presents the shorthand of the attribute. Cross-reference the VSA number with the RADIUS dictionary to obtain the full VSA name.
The following is an example of the first 10 rows of a CDR Layout file, start record.
1,"Accounting Status",,40,## START ##
2,"NAS IP Address",,4
3,"NAS Port",,5
4,"Accounting Session ID",,44
5,"Ingress Session ID",ACME,3
6,"Egress Session ID",ACME,4
7,"Session Protocol Type",ACME,43
8,"Session-Forked-Call-Id",ACME,171
9,"Generic ID",ACME,40
10,"Calling Station ID",,31Requirements
If you want to guarantee the CSV placement for RADIUS attribute values, you must use the entire RADIUS dictionary. You cannot use the RADIUS CDR abbreviation feature. Using an abbreviated form of the RADIUS dictionary results in adverse effects for the CSV file.
In your configuration, then, you must set the vsa-id-range parameter to use the entire range of attributes. Leaving this parameter blank disables abbreviation and all attributes are included. Alternatively, you can specify all of the parameters (by attribute number) that are used in the OS release loaded on your system.
See the RADIUS CDR Content Control section for more information.
Local CDR File Naming Convention
Filenames are derived from the date and time that the CDR file is opened for writing. The format is cdrYYYYMMDDHHMM[a-j], where:
- YYYY=the year
- MM=the month
- DD=the day
- HH=the hour
- MM=the minute
- [a-j]=a suffix that provides additional discrimination in case of changing system time, setting the rotation time for this feature to one minute, or in case of another occurrence that might compromise the date and time
Your file name will resemble the following sample: cdr200511151200.
Call Detail Record Sequence Number in Filename
To assist in the identification of lost Call Detail Record (CDR) files, the customer can enable the file-seq-number attribute to assign a sequence number to append to the file. A separate configuration element, temp-remote-file, allows for the prepending of the characters "tmp-" to CDR files during transfer.
Sometimes there are failures in the transmission of CDR files due to underlying network or infrastructure issues. Customers can identify missing files through the combination of a timestamp (YYYYMMDDMM) and 9-digit unique sequence numbers (SNs) appended to the file. This behavior is enabled through the file-seq-number attribute. The SN will start from one at boot time. This attribute replaces the use of alpha characters (a-z) appended to the CDR file name when more than one file is created in the same minute.
Separately, one can set the temp-remote-file attribute so the characters "tmp-" are prepended to the CDR file during transfer. Once delivered, the file will be renamed on the remote host to remove "tmp-".
For example, with both attributes enabled, a file named tmp-cdr<timestamp>-<9-digit-sequence-number> would be created and upon complete transfer to the destination renamed cdr<timestamp>-<9-digit-sequence-number>.
Local CDR File Storage Directories
The OCSBC only allows local storage of
CDRs to the /opt directory. If you try to save to another directory (such
as /code or /boot), you will receive an error
message.
Setting the location to /opt/logs may cause the package-logfiles command
and the package-crashfiles command to fail. Instead, use /opt/accounting.
If you are using the ACLI and enter an inappropriate directory, the ACLI will issue an error message.
Local CDR File Size and Rotation
You can configure maximum file size, maximum number of local CSV files to store, and the interval at which the files rotate.
The OCSBC saves up to the file size limit (max file size) and maintains only number of files that you configure (max files). When the maximum file size is reached, the OCSBC closes that file and begins writing VSA attributes and values to a new local CDR file. When it is time for the OCSBC to write the max files + 1 file, the oldest file is deleted so that the newest one can be stored.
More About File Rotation Time
You can use the CDR local storage feature on its own, without enabling the ftp push feature. The OCSBC uses a period of time that you set to periodically rotate the files. The file rotate time parameter rotates the local CSV files regardless of whether you use the FTP push feature.
RADIUS CDR Redundancy
When you are using the RADIUS CDR storage and FTP push feature, the OCSBC can create a redundant copy of the comma-delimited CDR files that it stores on the standby system in the HA node.
This enhancement to the CDR storage feature ensures against data loss if, for example, an active OCSBC fails immediately before an FTP push. The standby has a duplicate set of records that it sends. This feature is enabled with the CDR output redundancy parameter found in the account config configuration element.
Caveats for H.323
H.323 calls proceed without interruption over an HA node in the event of a failover from one OCSBC to another, and RADIUS records are generated and duplicated across the active and standby systems in an HA node. However if a switchover occurs during an H.323 call (that has been initiated, but not completed), the newly active (formerly standby) system will not generate RADIUS Stop records when the call completes.
FTP Push
The FTP push feature is used to copy local CDR files to a remote FTP server on a periodic basis. This feature is configured by defining push receivers which contain standard login and FTP server credentials of the remote machine. At the configured time interval (file rotate time), the OCSBC closes the current file, and pushes the files that are complete and have not yet been pushed; including the just-closed-file.
Deprecated ACLI Configuration
The following parameters in the account-config configuration element are deprecated:
- ftp-address
- ftp-port
- ftp-user
- ftp-password
- ftp-remote-path
These parameters will only be used if no account-config, push-receiver configuration elements have been defined. All new push receivers must be defined in the account-config, push-receiver configuration element.
Multiple Push Receivers
OCSBC (OCSBC) supports up to five CDR push receivers for use with the local file storage and FTP push feature. For each receiver you configure, you can set the file transfer protocol that you want to use. (FTP or SFTP). The system uses the push receivers according to the priorities you assign by setting a 0 through 4 priority number to the server. 0 is the highest priority, and 4 (default) is the lowest.
Based on the priority level you set, the OCSBC uses the strategy that you set to select a CDR push receiver. If the highest priority push receiver selected using the strategy becomes unavailable, the OCSBC uses the strategy (hunt, round robin) to select another.
This feature is dynamically configurable. When you change the configuration, the OCSBC updates the list of push receivers if it has changed.
Push Receivers
A push receiver configuration includes all the credentials that the OCSBC needs to log into an FTP server and upload any recent local CDR files. Push receiver configurations must include:
- the server’s IP address and port
- remote path of where to upload the local CDR files
- protocol used to connect to the server
- account login credentials
Secure FTP Push Configuration
You can configure the Oracle Communications Session Border Controller (OCSBC) to securely log on to a push receiver using one of the following methods that creates a secure connection.
- Set the protocol parameter on the push receiver to SFTP.
- Configure a username and password.
- Leave the public-key parameter blank.
- Import the host key from the SFTP server to the OCSBC as a known-host key.
See "SSH Key Management" in the Configuration Guide.
- Set the protocol parameter on the push receiver to SFTP.
- Configure the username.
- Leave the public-key parameter blank, regardless of authentication type.
- Export the OCSBC's public key
with the
show security public-host-key rsacommand. - Append the OCSBC's public-key to the SFTP server's authorized_keys file.
- Import the host key from the SFTP server to the OCSBC as a known-host key.
See "SSH Key Management" in the Configuration Guide.
It is often difficult to determine whether the SFTP server uses its RSA key or its DSA key for its server application. For this reason, Oracle recommends that you import both the RSA key and the DSA key to the OCSBC to ensure a successful FTP Push.
It is also common for the SFTP server to run the Linux operating system. For Linux, the command ssh-keygen -e creates the public key that you need to import to the OCSBC. The ssh-keygen-e command sequence requires you to specify the file export type, as follows.
[linux-vpn-1 ~]# ssh-keygen -e
Enter file in which the key is (/root/.ssh/id_rsa/): /etc/ssh/ssh_host_rsa_key.pubIf you cannot access the SFTP server directly, but you can access it from another Linux host, use the ssh-keyscan command to get the key. An example command line follows.
root@server:~$ ssh-keyscan -t rsa sftp.server.comACLI Instructions and Examples
This section shows you how to configure Local CDR storage and FTP push on your OCSBC.
Accessing the Accounting Configuration
To configure parameter for these features, you must access the accounting configuration.
To access the accounting configuration:
Enabling Local CDR Storage
To enable local CDR storage:
- file-output—Enable this parameter for the OCSBC to create comma-delimited CDRs (generated from RADIUS records). By default, this parameter is disabled.
- file-path—You must configure this path for the CDR push feature to work. Set the path to use on the
OCSBC for file storage:
-
/opt
-
/opt/logs
To use FTP push, you must configure a usable path.Note:
When a Hard Disk Drive is available, you may opt to store CDRs in the data-disk.
-
- max-file-size—Set the maximum CDR file size in bytes. The default and minimum value is 1000000. Oracle recommends you limit local CDR storage on your system to 30M. For example, if you retain the max-file-size default, set max-files to 30. However, if you are using a Storage Expansion Module the maximum value is 108.
- max-files—Set the maximum number of files to be stored on the OCSBC at one time. The parameter's value range is from 0 to unlimited. The user should consider the max-file-size setting, the 30M recommendation, and their preferences to specify this value. The default is 5.
- file-rotate-time—Set how often in minutes you want to rotate the stored files; the OCSBC will overwrite the oldest file first. The minimum rotation time is 2 minutes; the default is 60 minutes. This parameter defaults to 0, and leaving it set to the default means that the OCSBC will not rotate the files.
- cdr-output-redundancy—Set this parameter to enabled for the OCSBC to store a redundant copy of the local CSV file to the standby HA node. Set this parameter to standby-push to enable the function and enable local storage and implement push capabilities on an HA deployment's standby to protect against CDR data loss.
Configuring a Push Receiver Fallback Method
You set the push receiver strategy and define the maximum timeout in seconds in the main accounting configuration.
Note:
You may ignore the following two parameters if only one push receiver is configured.