cc/td/doc/product/wanbu/vns/vns_30
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Call Detail Records

Call Detail Records

The VNS records information about each voice (or data) SVC call in a Call Detail Record (CDR). The CDRs are collected in files (billing.n) so that they can be uploaded by an SV+ Workstation or other billing system and used for billing. There are two CDR file parameters (CDR File Count and CDR File Interval) which are configured with the VNS Configuration Interface and are described in Chapter 7 in the section, VNS Information. These parameters specify the number of CDR files that the VNS will generate before writing over them and the interval in minutes for which a file will be generated.

This appendix describes the CDRs in the following sections:

CDR Billing File Format

The current version of the DPNSS billing file has the following format for the CDR record. The following is an example of a billing file:

------------------------------------------------------------------------------- CP_BILLING_FILE, VERSION_1, 12/06/1997 17:52:27 PDT 0.v, 600007, 900007, b4dns20-7-1, b4dns175-1, 12/06/1997 18:11:53, 0, 16, 0 1.d, 600004, 900007, b4dns20-7-1, b4dns19-5-1, 12/06/1997 18:33:24, 12, 41, 48 --------------------------------------------------------------------------------

The file is in ASCII format. It contains a file header that identifies the file as a billing file using the keyword CP_BILLING_FILE followed by the demarcating token ", ". Next the file identifies its version as VERSION_1 followed by ", " this will allow for future modifications of the billing format. Next the header contains an ASCII timestamp indicating the local time that the file was created. The file header also displays the configured time zone (PDT) of the VNS. Following this header, individual CDR records will be written as ASCII strings with each record separated by a new line "\n" character.

The CDR will contain the following fields separated by the ", " token.

    1. Record number - a sequential number that identifies the individual records (0, then 1 in the first column of the example file).

    2. Voice (v) or data (d) call indicator.

    3. Calling number (600007 in the first record in the example file).

    4. Called number (900007 in the first record in the example file).

    5. Local switch node name, local CVM slot number, and local channel number separated by the "-" token (b4dns20-7-1 in the first CDR in the example file).

    6. Remote switch node name, remote CVM slot number, and remote channel number separated by the "-" token (b4dns175-1 in the first CDR in the example file).

    7. Record creation date and timestamp separated by a space. Date is specified in the mm/dd/yyyy format. Timestamp is specified in Universal Co-ordinated Time, hh/mm/ss (12/06/1997 18:11:53 in the first CDR in the example file).


Note All dates on the VNS are displayed in the mm/dd/yyyy format to prevent problems when the year 2000 arrives.

    8. Elapsed time in seconds (defined as time difference from above timestamp to first message that released call) (0 in the first CDR in the example file).

    9. Call Failure Class (VNS defined, it shall be 0 if the VNS did not force the call to be released) (16 in the first CDR in the example file).

    10. Protocol specific Call Failure Class (DPNSS or QSIG defined value) (0 in the first CDR in the example file).

Additional Billing Information

Location of Billing

An environment variable VNS which is assigned during the installation of the system defines the root directory for the billing related files.

>From directory $VNS a sub-directory `files' exists and this is the target directory for the billing files.

The billing process collects billing information and creates files in the directory $VNS/files with the name billing.0 billing.1 billing.2 .... billing.n where n indicates the configured number of billing files that the system wants to stored before wrapping around.

Other configured parameters are

Retrieval of Billing Files

After the VNS has written a file another entity will retrieve the file and use the stored information for billing calculation. This external entity may FTP (file transfer protocol) the desired files from the VNS.

It is expected the billing application will periodically retrieve and delete the billing files from the VNS disk at a rate adequate to avoid the VNS billing process overwriting billing files that have not been retrieved.

Billing Example

For this example, assume the following:

    1. The file size has been configured for 100,000 bytes per file.

    2. Each billing record is 100 bytes long => 1000 records per file.

    3. The system is configured to store 20 files.

    4. The system is running at 1 call per second => 3600 calls per hour.

    5. Assume that the VNS environment variable is set to /usr/dns.

System Operation

The system creates the first billing file in /usr/dns/files and names it billing.0. Billing records are added to this billing file at a rate of 1 per second; thus, the billing file reaches its maximum size after 1000 seconds (approximately 20 minutes).

After 1000 seconds, the first billing file is closed and the second one is opened as billing.1. This continues until the system has cycled through all 20 files that it uses. When it attempts to open the 21 file it does not open billing.20 but instead it resets the counter to 0 and opens billing.0. If billing.0 is still on the file system its contents are deleted.

Billing File Collection

The billing application must collect the billing files from the VNS. To prevent the loss of billing information, each individual file must be transferred (FTPed) from the VNS (19*1000 seconds), approximately every six hours if the configuration as assumed above is used. The billing application may invoke the FTP operation once the file has reached its maximum size. It may also delete the file once it has been collected but this is not necessary.

The configuration parameters given above may be increased at the expense of disk space to allow a number of days records be stored prior to the overwriting of information.


hometocprevnextglossaryfeedbacksearchhelp
Copyright 1989-1998 © Cisco Systems Inc.