Configuring File Accounting
This chapter describes the method of capturing accounting records in comma separated value (.csv) format and storing the records to a file in internal flash or to an external FTP server.
Contents
Prerequisites for File Accounting
Restrictions for File Accounting
Information About File Accounting
To configure file accounting, you should understand the following concepts:
File Accounting Method
The file accounting feature provides a method for capturing accounting records in comma separated value (.csv) format and storing the records to a file in internal flash or to an external FTP server. It expands gateway accounting support which also includes the AAA and syslog mechanisms of logging accounting information.
The accounting process collects accounting data for each call leg created on a Cisco voice gateway. You can use this information for postprocessing activities such as generating billing records and network analysis. Cisco voice gateways capture accounting data in the form of call detail records (CDRs) containing attributes defined by Cisco. The gateway can send CDRs to a RADIUS server, syslog server, and with the new file method, to flash or an FTP server in.csv format.
Note
For redundant solutions that use HSRP, CDRs are only generated by the active router.
CDRs in.csv format use the following conventions to capture accounting attributes:
- Each CDR has a fixed number and order of predefined attribute fields. Fields with no data are included as empty fields.
- Twelve fields are generic and are used to capture feature-related information. For a basic call, the call record is generated with basic call information in the feature part of the fields. The fields are static in terms of their position, however, the definitions of the feature_vsa fields are determined by the type of feature.
- A CDR is generated for each feature that is invoked. For example, if a call leg has a basic call and then a call transfer, two CDRs are generated for the following:
– CDR with feature fields representing the basic feature
– CDR with feature fields representing the supplementary service, for example, call transfer
The following output is an example of a CDR for a call generated using file accounting to capture records in.csv format:
1,48,964484051,"12345",”TWC”,1234,2345, "09/01/2006 15:39:44.747”
1,49,964484062,"12345",”CXFER”,1234,2345,3456, "09/01/2006 15:39:44.747”
Configuring file accounting includes defining the primary and secondary file location for storing call records. If the file transfer to the primary device fails, the gateway retries the primary device up to the configured number of times before automatically switching over to the secondary device. You can initiate a manual switchback to the primary device when it is restored. If the secondary device also fails, the accounting process ends and the system logs an error. New CDRs are dropped until one device comes back online and you manually reset.
The gateway holds call records in memory temporarily before writing the records to the specified accounting file. It appends call records to the accounting file after a configured flush-timer limit or whenever the memory buffer becomes full. The gateway closes the accounting file and opens a new file after a configured file-close time limit or you can initiate an immediate close. Other options allow you to select the specific attributes captured in the accounting record.
For configuration information, see the “Configuring File Accounting” section.
File Accounting Filtering
CDRs generated by the file accounting process can be filtered using one of the following three methods, depending on your data collection needs.
Detailed File Accounting Format
Table 3-1 lists the name and order of the complete set of voice attribute fields generated in the detailed version of file accounting CDRs using the cdr-format detailed command.
Note Fields 0 to 22 are included in the compact version of the CDR.
|
|
|
|
|
|||
|---|---|---|---|---|---|---|
| Unique call identifier generated by the gateway. Used to identify the separate billable events (calls) within a single calling session. |
||||||
| Setup time in Network Time Protocol (NTP) format: hour, minutes, seconds, microseconds, time_zone, day, month, day_of_month, year. |
||||||
| Connect time in NTP format: hour, minutes, seconds, microseconds, time_zone, day, month, day_of_month, year. |
||||||
| Disconnect time in NTP format: hour, minutes, seconds, microseconds, time_zone, day, month, day_of_month, year. |
||||||
| Q.931 disconnect cause code retrieved from Cisco IOS call-control application programming interface (Cisco IOS CCAPI). |
||||||
| Gateway’s behavior in relation to the connection that is active for this leg. |
||||||
| Number of charged units for this connection. For incoming calls or if charging information is not supplied by the switch, the value is zero. |
||||||
| Type of information carried by media. 1=Other 9 not described |
||||||
| Username for authentication. Usually this is the same as the calling number. |
||||||
| Originating carrier identification code, used in routing to identify the network. |
||||||
| Duration, in ms, of transmit path open from this peer to the voice gateway for the call. |
||||||
| ID value of the peer table entry to which this call was made. If a peer table entry for this call does not exist, the value of this object is zero. |
||||||
| ifIndex value of the peer table entry to which this call was made. If a peer table entry for this call does not exist, the value of this object is zero. |
||||||
| ifIndex value of the logical interface through which this call was made. For ISDN media, this is the ifIndex of the B channel that was used for this call. |
||||||
| Average ACOM level, in dB, for the call (ACOM is the combined loss achieved by the echo canceler). 1 indicates that the level cannot be determined or level detection is disabled. |
||||||
| Account code entered using the Acct soft key during call setup or when connected to an active call. |
||||||
| Negotiated coder rate. Transmit rate of voice/fax compression to its associated call leg for the call. |
||||||
| Duration, in ms, of voice playout from data received on time for this call. |
||||||
| Remote system UDP listener port to which voice packets are transmitted. |
||||||
| Whether or not voice-activity detection (VAD) is enabled for the voice call. |
||||||
| Average playout FIFO delay plus the decoder delay during the voice call. |
||||||
| Voice-packet round-trip delay, in ms, between local and remote devices on the IP backbone during a call. |
||||||
| High-water mark voice playout FIFO delay during the voice call. |
||||||
| Low-water mark voice playout FIFO delay during the voice call. |
||||||
| Duration, in ms, of the voice signal played out with the signal synthesized from parameters or samples of data preceding and following in time because of voice data not received on time (or lost) from the voice gateway for this call. |
||||||
| Duration, in ms, of the voice signal played out with signal synthesized from redundancy parameters available because of voice data not received on time (or lost) from the voice gateway for this call. |
||||||
| Duration, in ms, of the voice signal replaced with the signal played out during silence because of voice data not received on time (or lost) from the voice gateway for this call |
||||||
| Duration, in ms, of voice signal played out with signal synthesized from parameters or samples of data preceding in time because of voice data not received on time (or lost) from voice gateway for this call. |
||||||
| Number of received voice packets that arrived too early to store in the jitter buffer during the call. |
||||||
| Number of received voice packets that arrived too late to play out with the codec during the call. |
||||||
| Fax start time in a call. Multiple fax start/stop time stamps can exist in one call. Recorded for both VoIP and telephony call legs. |
||||||
| Fax stop time in a call. Multiple fax start/stop time stamps can exist in one call. Recorded for both VoIP and telephony call legs. |
||||||
| Initial high-speed modulation and baud rate negotiated at the time the call is connected. |
||||||
| Whether a fax was originated (transmitted) or terminated (received) by this gateway. |
||||||
| Packet loss concealment; number of white scan lines inserted (nonzero for outbound gateway only). |
||||||
| NSF country code of the local fax device; country name per T.35, Annex A. |
||||||
| Whether fax transfer was successful, the transfer failed, or indeterminate. |
||||||
| AV pairs sent from the voice gateway to the RADIUS server that you can define. You can set (write) the value with a customized Tcl IVR script. |
||||||
| Cause of failed calls. For more information, see the “Internal Error Codes” section. |
||||||
| Value representing impairment/calculated planning impairment factor (ICPIF) of the voice quality on the connection provided by lower-layer drivers (such as the digital-signal-processor). Low numbers represent better quality. |
||||||
| Best-fit calling party category value extracted from the Generic Transparency Descriptor (GTD). Sent in start and stop accounting messages for call legs 1 and 4. Optionally, this field also contains: |
||||||
| Sent in start and stop accounting messages for call legs 1 and 4. |
||||||
| Sent in start and stop accounting records for call legs 1 and 4. |
||||||
| Gatekeeper identifier, or the destination zone or area, of the outgoing VoIP call. |
||||||
| Gatekeeper identifier, or the source zone or area, of the incoming VoIP call. |
||||||
| Trunk-group label associated with the group of voice ports from which the outgoing TDM call leaves the gateway. |
||||||
| Carrier ID of the trunk group through which the call leaves the gateway or the partnering voice services provider identifier of the outgoing VoIP call. |
||||||
| Trunk group label associated with the group of voice ports from which the incoming TDM call arrived on the gateway. |
||||||
| Carrier ID of the trunk group through which the call arrived or the partnering voice service provider identifier of the incoming VoIP call. |
||||||
| Transferor information in the REFER/BYE/ALSO of SIP call. Used only in SIP call transfer. |
||||||
| BXFER = Blind transfer |
||||||
| Feature operation time. Time stamp of the operation start and stop time, if applicable for a given feature. |
||||||
| Feature ID of the invocation. Identifies a unique instance of a feature attribute within a gateway. This number is incremented for each added feature attribute. |
||||||
| Called number received in the incoming signaling message before any translation rules are applied. |
||||||
| Calling number received in the incoming signaling message before any translation rules are applied. |
||||||
| Called number presented by the gatekeeper in the ACF RAS message. GK/GKTMP could modify the called number by appending a prefix or leave it unchanged. |
||||||
| Calling number presented by the gatekeeper in the ACF RAS message. The GK/GKTMP could modify the calling number which is carried in the ACF nonstandard parameter. |
||||||
| Destination number collected by the gateway (application) that is used to route the call. Only applicable for 2-stage calls. |
||||||
| Redirecting number extracted from the redirect number parameter. Sent in start accounting messages for all call legs. noa=Nature of address |
||||||
| T1/channel associated signaling (CAS) or E1/R2 signal information about a subscriber. |
||||||
| Description assigned to the voice port of the incoming call. |
||||||
| Description assigned to the voice port of the outgoing call. |
||||||
| Session protocol used for calls between the local and remote router through the IP backbone. Always equal to “sip” for SIP or “Cisco” for H.323. |
||||||
| Local hostname that would be accessed or used by the SNMP MIBs. |
||||||
| Sent in stop accounting messages for call legs 1 and 4. Also included in interim-update packets. |
||||||
| Feature name. Two-Way Call (TWC), Call Forward All (CFA), Call Forward Busy (CFBY), Call Forward No Answer (CFNA), Blind Transfer (BXFER), Consultive Transfer (CXFER), Hold (HOLD), Resume (RESUME). |
||||||
|
|
|
|
|
|||
Note For description of fields 114 to 123, see the “Feature VSA Attributes” section.
Compact File Accounting Format
If you do not need the complete set of voice attributes supported by the file accounting process, a smaller, compact set is configurable using the cdr-format compact command. The compact version of the CDR captures the first 23 attributes (0 to 22) listed in Table 3-1 , in the order listed.
Customized Accounting Templates
You can create accounting templates to customize your CDRs based on your billing needs. You create a template by using a text file that lists the names of the desired attributes. Only those attribute values defined in the template are sent to the accounting server.
Note For file accounting, you cannot delete attribute fields or change the order of the attributes using an accounting template. Any attribute not included in the template appears as a blank field in the CDR.
To use a customized template for filtering the specific voice attributes included in CDRs, see the “Customized Accounting Records” section.
How to Configure File Accounting
This section contains the following tasks:
- Configuring File Accounting (required)
- Manually Initiating File Processes (optional)
- Troubleshooting File Accounting (optional)
Configuring File Accounting
To generate CDRs in file format (.csv), perform the following steps.
Note From Cisco IOS XE Cupertino 17.9.1a onwards, both FTP and SFTP passwords are encrypted.
Prerequisites
Restrictions
FTP or SFTP servers in Cisco IOS software are not supported because they cannot append CDRs to a file, so every flush would create a new file.
SUMMARY STEPS
4. primary { {ftp | sftp } path/filename username username password password | ifs device : filename }
5. secondary {{ ftp | sftp } path/filename username username password password | ifs device : filename }
8. maximum fileclose-timer minutes
9. maximum cdrflush-timer minutes
10. cdr-format { compact | detailed }
DETAILED STEPS
Manually Initiating File Processes
To manually flush the buffer or to force a switch back to the primary file device from the secondary device, perform the following steps.
Prerequisites
SUMMARY STEPS
DETAILED STEPS
Troubleshooting File Accounting
To troubleshoot the file accounting configuration, perform the following steps.
SUMMARY STEPS
DETAILED STEPS
|
|
|
|
|---|---|---|
|
|
||
|
|
Displays debugging messages related to generating attributes for file accounting. |
|
|
|
Displays debugging messages related to file accounting flushing processes. |
Configuration Examples for File Accounting
This section contains the following examples:
- File Accounting Configuration: Example
- File Accounting Filename: Example
- File Accounting Detailed CDR: Example
- File Accounting Compact CDR: Example
- Hold and Resume CDR: Example
File Accounting Configuration: Example
Router# show running-config | section gw-accounting
primary ftp [server]/cdrtest1 username bob password 6 TI[^VcViOKEXJbU_I^UWNYBfHQbKfOAAB
primary sftp 203.0.113.13/cdrtest username bob password 6 P^AV^_3
primary sftp [2001:420:54ff:13::312:175]//cdrtest username bob password 6 P^AV^_3
File Accounting Filename: Example
The following examples show how the accounting file is given a unique name when it is created. The router hostname and time stamp are appended to the filename that you assign with the primary command at the time the accounting file is created.
cme-2821(config)# primary ftp server1/cdrtest1 username bob password temp
cme-2821(config)# primary sftp server1/cdrtest1 username bob password temp
The name of the accounting file that is created uses the filename . hostname . timestamp format:
File Accounting Detailed CDR: Example
The following example shows a CDR captured by file accounting using the detailed format. Because file accounting records are in.csv format, fields with no data are included as empty fields.
File Accounting Compact CDR: Example
The following example shows a CDR captured by file accounting using the compact format.
Hold and Resume CDR: Example
The following example shows CDR stop records captured by file accounting for Hold and Resume. Because file accounting records are in.csv format, fields with no data are included as empty fields.
In this example, extension 3000 calls extension 5000, which is a shared line. Extension 5000 is shared by phone 5 (mbrown) and phone 7 (jsmith). The Hold record shows that Phone 7 answered the call and put the call on hold. Phone 5 then resumed the call as shown in the Resume record.
Feature Information for File Accounting
Table 3-2 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note Table 3-2 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.
Feedback