23 Configuring ME Accounting and Archiving
This chapter describes the ME methods for capturing SIP call detail records (CDRs) and other accounting records associated with SIP sessions
Accounting System Overview
The ME system uses industry-standard accounting targets where SIP call detail records are forwarded. The supported accounting targets are:
-
RADIUS
-
Database
-
Syslog
-
File system
-
DIAMETER
-
Archiving
Accounting records are written to directories on the file system, providing a large storage queue for call records as they are written. The accounting software then reads and distributes the call records to the configured accounting target destination(s).
In the event that an accounting target is unable, call records are automatically resent when the accounting target destination(s) become available and when all targets have been updated successfully. Use the accounting reapply action to resend call records in the file-system that met the date range to the target regardless if they previously were sent to the target successfully (or not).
The following directory structure store accounting records prior to their distribution to the various accounting targets.
/cxc/accounting/
Subdirectories: #
Files: #-sessionid
Base directory: The root location on the ME system for storing CDRs, such as /cxc/accounting.
Subdirectories: A series of numbered subdirectories each containing the number of files specified by accounting subdirectory-size property. The naming convention is # - sequential value.
Files: Each entry is a discrete CDR record. The naming convention is # - sequential value followed by the session identifier.
As the accounting software reads and processes files in the subdirectories, it creates, updates and deletes the following status markers:
-
complete: Indicates that the directory has been fully populated and that all of the files in the directory have been successfully processed.
-
lastprocessed: Indicates that the directory is currently being populated and that all of the files have been processed successfully.
-
pending: Indicates that the accounting software has selected the directory for processing and that processing has not yet begun.
-
inprogress: Indicates the files in the directory are currently being processed.
-
reapply: Indicates that the directory is currently being evaluated by the accounting reapply action.
The services\data-locations object contains the accounting-root-directory property to specify the directory where accounting records will be placed prior to being sent to the various accounting targets. The default location is the /cxc_common/accounting directory.
Configuring the Accounting Settings
General accounting settings are available under the vsp\accounting configuration object.
-
admin: Enables or disables all configured accounting targets.
-
retention-period: Specifies how many days the accounting records should be retained before being purged from the file system. The default setting is 7. The range is 0 to 21 days.
-
subdirectory-size: Specifies the number of records to be recorded in each of the sub-directories. The default is 1000. The range is 100 to 2000.
-
purge-criteria: Specifies he criteria to be used when deleting records from the file system. The purge-always setting indicated that records should be deleted even if they have not been saved to all of the defined enabled targets. The purge-only-when-complete setting indicates that even expired CDRs should be retained if they have not been sent to all of the defined targets.
-
report: Creates a named CDR summary report containing the specified field, match, and category criteria.
The accounting purge action forces an immediate purge and clears all CDRs on the file system that are eligible for deletion.
The accounting reapply action accepts a date range and selected groups and marks qualifying records on the file system back to an unprocessed state. The records are picked up and reapplied (resubmitted) to the configured accounting targets. Use this action if CDR data is lost for a selected target and the data needs to be recovered. This action is limited to data within the current retention period.
The show accounting-status command provides a summary of current accounting and processing information for existing targets, including any target exceptions.
Configuring RADIUS Groups
The Remote Authentication Dial In User Service (RADIUS) implementation allows the ME system to operate as a RADIUS client that directs SIP call detail records to a RADIUS accounting server. The RADIUS accounting server receives the accounting request and returns a response to the client indicating that it has successfully received the request.
A RADIUS group is a uniquely named object that defines the authentication and accounting services associated with a group of RADIUS servers. Including a RADIUS group in one or more VSP configurations allows the ME system (the RADIUS client) to perform user authentication and forward accounting and SIP call detail records to RADIUS servers.This means that you have flexibility to create as many unique RADIUS groups as you need, and include them with the VSPs of your choice.
Within a RADIUS group, you set the RADIUS authentication and accounting modes that you are using, the type of RADIUS accounting format, and whether the RADIUS group is to be included as a default authentication and accounting group for SIP traffic that is not governed by configured authentication and accounting policies.
The following image illustrates a sample network using a RADIUS accounting group.
CLI Session
The following CLI session creates the RADIUS accounting group named aaaGroup1 and sets the group operational properties.
NNOS-E> config vsp config vsp> config radius-group aaaGroup1 Creating ’radius-group aaaGroup1' config radius-group aaaGroup1> set admin enabled config radius-group aaaGroup1> set accounting-mode duplicate config radius-group aaaGroup1> set authentication-mode failover 3 config radius-group aaaGroup1> set type Cisco
In this session, the authentication and accounting modes are RADIUS operational algorithms. The duplicate algorithm issues multiple duplicate accounting requests to all servers in the RADIUS accounting group. A duplicate accounting request uses the same client source IP address and source UDP port. If you configure multiple authentication servers in the RADIUS group, the failover algorithm forwards authentication requests to secondary servers should the current authentication session fail. You can specify up to 256 failover attempts to other servers.
The default accounting method is cisco accounting, and the aaaGroup1 RADIUS group is a default group for all non-policy governed RADIUS requests between the ME system and the RADIUS servers.
Configuring the RADIUS Servers
You can configure multiple RADIUS servers in the RADIUS group, and you identify each server using a unique number and IP address, authentication port, accounting port, and other operational settings.
CLI Session
The following CLI session creates two numbered RADIUS servers and sets the operational properties for RADIUS requests and responses between the ME system and the RADIUS servers.
NNOS-E> config vsp config vsp> config radius-group aaaGroup1 config radius-group aaaGroup1> config server 192.168.147.6 config server 192.168.147.6> set admin enabled config server 192.168.147.6> set authentication-port 1800 config server 192.168.147.6> set accounting-port 1801 config server 192.168.147.6> set secret-tag abc123xyz config server 192.168.147.6> set timeout 1500 config server 192.168.147.6> set retries 3 config server 192.168.147.6> set window 255 config server 192.168.147.6> set priority 2 config server 192.168.147.6> return config vsp> config radius-group aaaGroup1 config radius-group aaaGroup1> config server 192.168.147.7 config server 192.168.147.7> set admin enabled config server 192.168.147.7> set authentication-port 1800 config server 192.168.147.7> set accounting-port 1801 config server 192.168.147.7> set secret-tag abcXYZ123 config server 192.168.147.7> set timeout 1500 config server 192.168.147.7> set retries 3 config server 192.168.147.7> set window 255 config server 192.168.147.7> set priority 2 config server 192.168.147.7> return
For additional information on configuring RADIUS groups and servers, refer to the Net-Net OS-E – Objects and Properties Reference.
Including the RADIUS Group
When you configure RADIUS groups, you include one or more groups with the VSP RADIUS accounting configuration. This tells the VSP what RADIUS servers to use when forwarding RADIUS accounting requests.
CLI Session
The following CLI session includes the RADIUS groups named aaaGroup1 and aaaGroup2 with the VSP RADIUS accounting configuration.
NNOS-E> config vsp config vsp> config accounting config accounting> config radius config radius> set admin enabled config radius> set group vsp radius-group aaaGroup1 config radius> set group vsp radius-group aaaGroup2 config radius> show vsp accounting radius admin enabled group vsp\radius-group aaaGroup1 group vsp\radius-group aaaGroup2
When using the set group command, specify the CLI path where you created the Radius group.
Configuring the Accounting Database
The ME accounting database is a subsystem that captures and stores SIP call detail records. If configured, these records can be forwarded to remote SQL database servers such as Oracle and Postgres where the call detail records are used with other accounting and billing applications. Access to a remote database group and server is restricted by configured user names and passwords.
Accounting policies direct SIP call detail records to specific accounting groups and servers. If you do not configure one or more remote database groups and servers, the SIP call detail records are stored in the ME accounting database only. The following image illustrates a sample network with a database server group.
CLI Session
The following CLI session creates the accounting database group named databaseGroup1, creates the associated server named dbServer1, and sets the group and server operating properties.
NNOS-E> config vsp config vsp> config accounting config accounting> config database config accounting> set admin enabled config database> config group databaseGroup1 Creating ’group databaseGroup1' config group databaseGroup1> set admin enabled config group databaseGroup1> set mode duplicate config group databaseGroup1> config server dbServer1 Creating ’server dbServer1' config group databaseGroup1> set admin enabled config group databaseGroup1> set type sqlserver 192.124.65.3 24 srvr1 config group databaseGroup1> set username frank config group databaseGroup1> set password-tag kj3k2
In this session, the duplicate mode algorithm issues a duplicate accounting request to all servers in the accounting group. A duplicate accounting request uses the same client source IP address and source UDP port. If you configure multiple database servers in the database group, the fail-over algorithm forwards one accounting request to each secondary servers should the current session fail.
The databaseGroup1 accounting group is a default group for all non-policy governed accounting database requests between the ME system and the database servers.
Note:
If you set the server type to local while using the local database as the accounting target, set the username and the password-tag to postgres. If you edit the username and password-tag properties to anything other than postgres, data will not be written to the database.For additional information on configuring accounting database groups and servers, refer to the Oracle Communications WebRTC Session Controller Media Engine Object Reference.
Configuring Syslog
Syslog allows you to log accounting information to a remote server using the configured syslog format: Oracle, CSV, tabular, or XML format. When enabled, SIP call detail records are forwarded to the specified syslog accounting group and server. The following image illustrates a sample network.
CLI Session
The following CLI session creates the syslog accounting group named syslogGroup1, specifies the associated syslog server at 192.167.43.12 on port 514, and sets the syslog group and server operating properties.
NNOS-E> config vsp config vsp> config accounting config accounting> config syslog config syslog> set admin enabled config syslog> config group syslogGroup1 Creating ’group syslogGroup1' config group syslogGroup1> set admin enabled config group syslogGroup1> set format csv config group syslogGroup1> config server 192.167.43.12:514 Creating ’server 192.167.43.12:514' config server 192.167.43.12:514> set admin enabled config server 192.167.43.12:514> set name syslogserver1 config server 192.167.43.12:514> set facility local0 config server 192.167.43.12:514> set priority info config server 192.167.43.12:514> set include-timestamp true
In this session, syslogGroup1 uses Comma-Separated Values (CSV) format. CSV format is a generic file format used for importing data into databases or spreadsheets, such as Microsoft Access or Excel (or several other database systems). CSV uses the .CSV file extension. The syslogGroup1 accounting group is a default group for all non-policy governed accounting database requests between the ME and the syslog servers.
The syslog server at IP address and port 192.67.43.12:514 is enabled with the operator-defined name syslogserver1. The facility (local0 to local7) specifies where SIP call detail records are logged. Syslog facilities help isolate the origin of messages written to the syslog server. The syslog priority (info, emergency, alert, etc.) sets the message priority to be associated SIP call detail records. All ME accounting and SIP call detail records are assigned this priority before they are forwarded to the syslog server. A time stamp can also be applied to each accounting record.
For additional information on configuring accounting database groups and servers, refer to the Oracle Communications WebRTC Session Controller Media Engine Object Reference.
Configuring the File System
The accounting file system allows you to direct SIP call detail records to a named directory path and file using a specified format: CSV, tabular., Oracle text file format, or to a temporary output file in the case of postgres format.
There are two states that the file system cycles through as it processes raw CDRs and writes to the output file.
-
Clear: The target is ready to write.
-
Writing: The target is writing to the output file.
The following image illustrates a sample network.
CLI Session
The following CLI session creates the file system group named filePath1, specifies the format, file path, and target file name, and sets the file system operational properties.
NNOS-E> config vsp config vsp> config accounting config accounting> config file-system config file-system> set admin enabled config file-system> config path filePath1 Creating ’path filePath1' config path> set admin enabled config path> set format csv config path> set call-field-filter recorded config path> set file-path \cxc\logfile1.csv config path> set roll-over never config path> set purge-old-logs true config path> set retention-period 1 days
In this session, filePath1 uses Comma-Separated Values (CSV) format. CSV format is a generic file format used for importing data into databases or spreadsheets, such as Microsoft Access or Excel (or several other database systems). CSV uses the .CSV file extension. The ME target file path is \cxc\logfile1.csv, where logfile1.csv is the name of the file to which SIP call detail records are forwarded.
The roll-over property maintains and keeps the original time as it was first applied to the log file. The log file will continue to build under this time stamp. The filePath1 file system accounting group is a default target group for capturing all non-policy governed SIP call detail records.
For additional information on configuring accounting database groups and servers, refer to the Oracle Communications WebRTC Session Controller Media Engine Object Reference.
Configuring an External File System Target
The external-file-system target allows you to send accounting records from the ME to a remote system. The target is able to read raw CDRs and write this information to a temporary output file in the format you specify during configuration.
There are four states that the external target cycles through as it processes raw CDRs, writes to the output file, and sends it to the remote system.
-
Clear: The target is ready to write.
-
Writing: The target is currently writing to the temporary file.
-
Sending: The target is sending a file. At this time, the file can also be writing to a temporary file that will become the next file to send once the current file is successfully sent.
-
Blocked: The target has one file in the middle of sending and another one ready to send. The target will not process anymore requests from the accounting server, but will send retries to the server giving retry interval based on its best estimate of when the retry can work.
If the configuration is modified or deleted, any files currently being processed are sent immediately and without retries. If the target is in the blocked state, there are two files immediately sent and if the target is in the sending or writing states, one file is sent. The modification or deleted is applied only after the send completes, successfully or not.
If there is a failure when sending a file to the external target, the send is retried every 30 seconds for an hour. After an hour, the send is retried once every hour until it succeeds.
The following is the format of the output file:
<target-name>-<yyyy-mm-dd-hh-mm>-<processingtype>-<seq-no>.<xtn>
-
target-name: Name specified in the configuration.
-
yyyy-mm-dd-hh-mm: The timestamp when the output file is created.
-
processingtype: Hourly, daily, never.
-
xtn: .csv, .tab, .cov, or .pg
CLI Session
The following CLI session creates the external file system target, sets the target format, URL address, and CDR processing.
NNOS-E>config vsp config vsp>config accounting config accounting>config external-file-system config external-file-system>config url 7 Creating 'url test' config url 7> config url test>set admin enabled config url test>set format csv config url test>set url ftp://lalenchery:BillGates#1@10.33.5.10:/acct/test/ config url test>set cdr-processing batch 10 config url test>
For additional information on configuring external file system targets, refer to the Oracle Communications WebRTC Session Controller Media Engine Object Reference.
Configuring Diameter
The Diameter protocol, as described in RFC 3588, provides Authentication, Authorization and Accounting (AAA) services for applications such as IP mobility and SIP multimedia communications sessions. An ME system (SIP proxy), operating as Diameter client, sends an accounting request to the Diameter server where the Diameter server returns an accounting response to the Diameter client indicating that it has received and processed the accounting request.
Diameter is also an essential component for the Oracle route-server functionality. Refer to the Oracle Communications OS-E Session Services Configuration Guide for detailed information on route-server.
Creating the Diameter Accounting Group
Like RADIUS, a Diameter group is a uniquely named object that defines the authentication and accounting services associated with a group of Diameter servers. Including a Diameter group in one or more VSP configurations allows the ME system (the Diameter client) to perform user authentication and forward SIP call detail records to Diameter servers.This means that you have flexibility to create as many unique Diameter groups as you need, and include them with the VSPs of your choice.
CLI Session
The following CLI session creates the Diameter accounting group named diameterGroup1 and sets the group operational properties.
NNOS-E> config vsp config vsp> config diameter-group 1 Creating ’diameter-group 1' config diameterGroup1> set admin enabled config diameterGroup1> set authentication-mode round-robin config diameterGroup1> set application sip config diameterGroup1> set origin-host text config diameterGroup1> set origin-realm text config diameterGroup1> set default-destination-realm text
In this session, the authentication-mode, sets the Diameter group authentication operational algorithm. This example allows continued authentication requests to primary and secondary servers until a valid authentication response is received (round-robin).
The application setting specifies the target application for the servers in this Diameter group. Choose SIP for standard AAA activities, 3GPPRx for inter-operation with the Camiant policy server (enabled with the Rx object), and Routing for least-cost-routing between clusters.
The origin-host specifies the text written to the Origin-Host attribute field in any Diameter requests it sends. This should be the ME domain name.
The origin-realm specifies the text written to the Origin-Realm attribute field in any Diameter requests it sends. This should be the ME domain name.
The default-destination-realm specifies the text written to the Destination-Realm attribute field in any Diameter responses it sends. This setting operates with the 3Gpp Rx application.
Configuring Diameter Servers
You can configure multiple Diameter servers in the Diameter group, and you identify each server using a unique name, authentication port, and other operational settings.
CLI session
The following CLI session creates two numbered Diameter servers and sets the operational properties for Diameter requests and responses between the ME system and the Diameter peers.
NNOS-E> config vsp config vsp> config diameter-group 1 Creating ’diameter-group 1' config diameterGroup1> set admin enabled config group diameterGroup1> config server diameterServer1 Creating ’server diameterServer1> config diameterServer 1> set admin enabled config diameterServer 1> set port 3868 config diameterServer 1> set transport tcp config diameterServer 1> set authentication-port 3868 config diameterServer 1> set request-timeout 2 config diameterServer 1> set window 8 config diameterServer 1> set priority 1 NNOS-E> config vsp config vsp> config diameter-group 1 Creating ’diameter-group 1' config diameterGroup1> set admin enabled config group diameterGroup1> config server diameterServer2 Creating ’server diameterServer2> config diameterServer 2> set admin enabled config diameterServer 2> set port 3868 config diameterServer 2> set transport tcp config diameterServer 2> set authentication-port 3868 config diameterServer 2> set request-timeout 2 config diameterServer 2> set window 8 config diameterServer 2> set priority 1
For additional information on configuring Diameter groups and servers, refer to the Oracle Communications WebRTC Session Controller Media Engine Object Reference.
Configuring Diameter Interfaces and Ports
The diameter configuration object under the box\interface\ip object identifies the IP interface on which the Diameter server application resides. This is the ME interface that listens for incoming Diameter connections. This interface must be configured on each ME domain that is referenced by a server in a Diameter group.
CLI Session
config box> config interface eth3 config interface eth3> config ip A config ip A> config diameter config diameter> set admin enabled config diameter> set origin-host text config diameter> set origin-realm text config diameter> config port 3868 Creating ’port 3868' config port 3868> set admin enabled config port 3868> set transport tcp config port 3868> set application sip config port 3868> set peer-access-control transport config port 3868> set peer ipaddress
The origin-host setting specifies the text written to the Origin-Host attribute field in any Diameter responses it sends. This should be the DNS name of the ME domain you are configuring.
The origin-realm specifies the text written to the Origin-Realm attribute field in any Diameter responses it sends. This should be the ME domain name.
The port configuration specifies properties for incoming Diameter connections. The application setting sets the application that the incoming connection must be running to use this port.Choose SIP for standard AAA activities, 3GPPRx for inter-operation with the Camiant policy server (enabled with the Rx object), and Routing for least-cost-routing between clusters.
The peer-access-control setting specifies how the ME controls incoming peer connections. You can select to allow incoming connection from all peers or from peers on a configured list based on address or Host-IP-Address AVP.
The peer setting specifies the list of peers that are allowed to connect to this port. This property is not applied if the peer-access-control property is set to none. Indicate the peer by specifying the peer IP address.
Configuring Archiving
The accounting/archiving object allows you to configure an archiving location for SIP call detail records. Archiving is the persistent storage of the contents of the call (as opposed to the database or syslog server, which just records the placement of the call).
You must configure an archiving server in one of the archiving sub-objects for the archiving mechanism to work:
-
windows-share: Archiving of accounting and SIP call records to a selected Windows server partition
-
ftp-server: Archiving of accounting and SIP call records to a selected FTP server
-
http-server: Archiving of accounting and SIP call records to a selected HTTP server
-
smtp-server: Enables archiving of accounting and SIP call records to a selected Simple Mail Transfer Protocol (SMTP) server. When enabled, the ME sends out the archives in the form of an email attachment to the specified destination mailbox.
-
db-server: Archiving of accounting and SIP call records to a selected database server
-
local: Archiving of accounting and SIP call records to a location on the ME system
The following CLI session configures a remote database server for archiving of SIP call detail records.
CLI Session
NNOS-E> config vsp config vsp> config accounting config accounting> config archiving config archiving> config db-server database1 Creating ’db-server database1' config db-server database1> set admin enabled config db-server database1> set username admin config db-server database1> set password-tag xyz123abc config db-server database1> set server 192.168.10.10 config db-server database1> set url www.companyABC.com config db-server database1> set driver-class com.oracle.jdbc.Driver
If you are archiving using the http-server method, a server-side script designed to be run with Apache 2.0 and perl 5.8.5 on Linux is needed to handle the POST requests that are sent from the ME to transfer the archive zip files to the server. The following is an example:
#!/usr/bin/perl
#---Modify the above line to match the location of perl on your system---
#---This script has been tested running with OS-E software version 3.5.2 sending
#to Apache 2.0.52 running on Redhat EL4 Linux with perl 5.8.5---
#---Make sure to modify file permissions for this script so that it can
#be executed by the user running the httpd daemon.---
#---Note this script is provided as an example, which makes no attempt to validate
#the values pulled from the HTTP POST to ensure execution security---
#---Require strict syntax---
use strict;
use warnings;
#---Use the CGI library provided with perl - CGI.pm---
use CGI;
#---The below lines are an example of code, provided as-is, used to take
#the multipart/form-data from an HTTP POST to this script, which
#apache presents on STDIN and write it out to the disk in the
#directory specified in the variable above, using the same filename
#presented in the HTTP POST---
#---Instantiate CGI object---
my $cgi = new CGI;
my %params = $cgi->Vars;
#---Get proper filehandle from unknown file param name---
my $filehandle;
my $anon_param;
foreach my $param (keys %params) {
$anon_param = "$params{$param}" if (("$param" ne "name") && ("$param" ne "path"))
};
$filehandle = $cgi->param($anon_param);
#---Pull target directory from "path" cgi variable; this comes from the "directory"
#in the OS-E config. Note: leave off the trailing slash------
#---Make sure to modify file permissions for target directory so that it can
#be executed and written to by the user running the httpd daemon.---
my $dir = $cgi->param('path');
#---Pull target filename from "name" cgi variable
#---Assemble directory and filename---
my $name = $cgi->param('name');
my $fullname = "$dir/$name";
#---Write out the file from the HTTP POST---
open(LOCAL, ">$fullname") or die $!;
binmode LOCAL;
while(<$filehandle>) { print LOCAL $_; }
close(LOCAL);
#---Needed for 200OK response---
print $cgi->header( "text/plain" ), "File received.";
The following example displays the way the ME must be configured for the http-server archiving to work:
config archiving> config http-server server1 config http-server server1> set admin enabled config http-server server1> set directory /tmp/archives config http-server server1> set url http://10.0.0.1/cgi-bin/archive_http_upload_example.pl config http-server server1> set timeout 60000
-
The server needs to be configured to allow CGI scripts.
-
The script needs to be placed in the ”cgi-bin” directory and given execute permission for the user running the server.
-
The URL needs to include the name of the script.
-
The directory needs to have ”write” permissions for the user running Apache. This argument gets passed through the HTTP POST to the scripted. It is used to determine to which directory on the server the archive file is written.
For additional information on archiving accounting records, refer to the Net-Net OS-E – Objects and Properties Reference.
The ME also supports archiving as an accounting target, configured under the accounting object. Archiving targets can be configured as either archive-local or archive-external.
Once the archiving functionality is enabled and configured on the ME, the archiver listens for requests from the accounting server. A request from the server tells the archiver that there are calls that needs to be archived. The archiver creates a task for each CDR. This task gathers data to put in the archive by executing actions and status requests and querying databases.
The archiving target cycles through two states:
-
Clear: The target is ready to handle requests.
-
Blocked: The target has reached the maximum number of files it can save. You must remove saved archives to enable the target to start processing again.
When the ME sends an archive to a remote location and the send fails, the ME retries sending the archive as many times as it is configured to do so. If all retries fail, the ME saves the archive in the archive-save-folder and logs a message similar to the following.
Warning: ”Target archive-test, saved 1234.zip containing records 1000 to 1000 as /cxc_common/archive/saved/1234.zip (failure was: Connect timed out)”
You can configure the number of archives that can be saved in the archive-save-folder via the max-saved-on-send-failure property under the archive-external and archive-local objects. Once the ME hits this threshold, the target enters the ”Blocked” state and stops processing any more CDRs until the saved archives are removed from the folder. When this condition is reached, the ME logs a message similar to the following:
Critical: ”Target archive-test cannot process any more CDRs because the maximum of 200 archives that can be saved locally on failure is met or exceeded. Delete saved archives to enable further processing.
Note that the number of saved archives may be slightly higher than the configured number. This is because archives are not created in order and it is possible that some newer CDRs finished processing earlier than the archive that finally blocked the target.
Due to accounting server purges, there may be missing CDRs. The ME handles missing records by skipping over them and continuing the process. Missing records are logged and can be viewed in the status provider.
During an HA failover, the target on the new master ME picks up from where the previous master ME left off.
You configure the archiving targets under the vsp > accounting object.
vsp accounting admin enabled duration-type default retention-period 0 days 00:01:00 subdirectory-size 100 records purge-criteria purge-always radius database syslog file-system external-file-system archiving purge-check-interval 0 days 01:00:00 purge-disk-utilization-percent 90 % archive-local archive-external archive-worker-threads automatic archive-max-inprogress 120 archive-tries 2 archive-name-format[1] recordID compatible-archives false server-idle-timeout 300
For more information on the new archiving configuration properties, see the Oracle Communications WebRTC Session Controller Media Engine Object Reference.
The target can then be applied to a session-config via the session-config > accounting object.
config vsp>config default-session-config config default-session-config>config accounting config accounting>set target archive-external-file-system "vsp\accounting\archive-external\url""archivetest""
You can view information regarding archive targets using the following status providers.
The show accounting-targets action is a previously existing status provider that displays summary data from all accounting targets. This status action now includes archiving targets.
NNOS-E>show accounting-targets
type: archive-external
name: url archive-day1
received: 641 CDRs
processed: 641 CDRs
failures: 0
missing-records: 0
last-acked-record: 1495276
acked-pending-record: 1495276
average-processing-time: 2278 milliseconds/CDR
The show accounting-targets-archive-tasks action displays information about currently running archiving tasks on the ME.
NNOS-E>show accounting-targets-archive-tasks
name record errors in-progress
------ ------ -----------
nnose-backup 1170995 2 (send)
nnose-backup 1171000 2 (send)
nnose-backup 1171001 2 (send)
For more information on these status providers, see the Oracle Communications Webrtc Session Controller Media Engine Object Reference.
Free-Form Accounting for CDRs
The ME supports free-form accounting for CDRs, meaning you have the ability to completely customize the list of columns created in CDRs by using the session-config's named variable table. These custom CDRs are supported for all accounting target types except internal database.
You still have the ability to use the pre-existing (default) accounting record columns. This is the ME's default behavior. Each target type supports both forms of accounting, but each individual target can have only one or the other. A target can have either the default accounting fields or custom accounting fields.
This feature differs from the existing CDR custom data fields because you create all of the columns yourself. In releases previous to 3.6.0m5, you could only get existing fields and filter those that you did not want. There also existed one column named custom-field that contained user-specified data.
To enable free-form accounting for CDRs:
-
Select the Configuration tab and click the vsp > accounting object.
-
Click Configure next to the type of target for which you want to create free-form accounting.
-
admin: Set to enabled and provide either a group or a path for the target (depending on which type of target you are configuring).
-
custom-accounting: Set to enabled.
Note:
The custom-accounting property overrides the call-field-filter property, where you configure the default accounting records. -
Click Set. Update and save the configuration.
To create free-form CDRs, one mechanism to populate free-form CDRs is to use named variables in the session-config. Named variables can be added to sessions on the ME in multiple ways. They can be added via the session-config > named-variables object. For more information on configuring named-variables in the session-config, see Configuring Session Configuration Objects in the Oracle Communications WebRTC Session Controller Media Engine Object Reference.
Named-variables can also be added via the named-variable-add action. For more information on this action, see the Named Variable Actions section of this guide.
The ME offers a list of pre-defined variables for you to use in free-form CDRs. These can be broken down into three types: acct, cdr, and session.
The acct class of named variables is derived from items that are already available through the accounting-data > custom-data-field.
For a complete list of named variables available on the ME, see the Oracle Communications WebRTC Session Controller Media Engine Objects and Properties Reference guide.
Once you have the named-variables configured in the session-config, you can add them to your free-form CDRs. You can add named-variables to free-form CDRs via the accounting > targets > named-variable-entries property.
To add named-variables to free-form CDRs:
-
Access the vsp > accounting > <target> > named-variable-entries object where you have the custom-accounting property set to enabled. Click Configure next to named-variable-entries.
Or, access the vsp > session-config-pool > entry > accounting-data object and click Add named-variable-entry.
-
Click Add entry.
-
From the variable-name drop-down list, select the named-variable to include.
-
display-name: Enter the name you want to be displayed for this column. This value is required if the accounting target is a database and the display-name complies with the column name rule of the corresponding database.
-
Click Create. Repeat this process for as many named-variables as you want to include.
-
Click Set. Update and save the configuration.
Using the ME Archive Viewer
The archive viewer is a standalone utility that displays information and plays video recordings from archive files that have been stored locally on a client PC. The viewer allows you to see the call diagram and message details without having to run the ME Management System.
The following image illustrates a sample Archive Viewer display.
The Archive Viewer is contained in a ZIP file included with the ME release software. The file is named nnSE360-av.zip.
Perform the following steps on a Windows PC, which is the only supported platform for the Archive Viewer:
-
Download the nnSE360-av.zip file to a location on your PC. The file is available from the Oracle support site.
-
Double-click the .ZIP file, then select Extract All. A separate folder will be created using the same name, minus the .ZIP extension.
-
Open the folder that you just created, then double-click the nnSE360-av.exe file. This will launch the Archive Viewer.
-
Select File->Open Archive, or File->Stream Viewer to browse for the archived file. The Stream Viewer replays and mixes the two audio streams (one in each direction) with the video streams (one in each direction).
Note:
You must configure the ME with both accounting and media recording enabled. You can enable archiving to periodically send the recorded files to a workstation, or you can create individual session archives on demand from the ME Management System Call Logs screen.