Voice-related accounting records are usually gathered as input for network design, capacity planning, or billing purposes. As described, voice performance management ensures the voice quality and is the foundation of voice services. Voice accounting makes it possible to design and charge for the service. Traditionally, voice billing was time-based; VoIP in the Internet probably will lead to changes in this business model. An alternative is volume-based accounting, where voice is considered just another IP application, and the user is charged for the total traffic.
From a business perspective, charging for single VoIP calls is not an economical approach in most cases because of the necessary investments for metering and processing all call records. An alternative is flat-rate billing or billing based on the total transmitted volume.
When distinguishing between time- and volume-based accounting, standards are relevant for both approaches. Even though no ITU-T or IETF standard for volume-based VoIP accounting exists yet, the IPDR consortium has developed a framework called Internet Protocol Detail Record (IPDR) to capture network data usage information in IP networks.
When deploying per-call billing for VoIP, data must be correlated at the application level. One call consists of at least two records (called "call legs")—one for the call's originator and one for the receiver. Figure 15-7 illustrates the call leg concept.
If a gateway is involved in the conversation, four call legs are generated—one from the originating IP phone, one from the PSTN gateway, and two additional for the reverse direction. If these records are created from completely different systems, the result can be a com-bination of records from CallManager, SS7, RADIUS, etc. This increases the requirements for the billing application and illustrates the need for accounting standards that cover the combination of VoIP and PSTN.
For traditional signaling, SS7 is the global standard, defined by the ITU-T. Although VoIP has no global accounting standard, IPDR and TMOC (ATIS Telecom Management and Operations Committee) have proposed a collaboration document to ITU-T study group 3 (SG3). Telcordia has also defined some accounting and billing standards, such as GR-508, GR-1100, and GR-2844.
Multiple metering techniques gather voice traffic, such as NBAR, RMON, NetFlow, and the CLASS-BASED-QOS-MIB; Part II of this book covers them in detail. Depending on the requirements, some fit better than others. For example, if voice accounting is collected for billing, start and stop time stamps are required, which makes NetFlow a good candidate for metering. Alternatively, if voice traffic is assigned to a dedicated class of service and voice accounting provides input into a traffic planning application, the Cisco-CLASS-BASED-QOS-MIB fulfills these needs.
An alternative is to use RADIUS for accounting. Chapter 9, "AAA Accounting," describes the voice extensions for RADIUS, supporting H.323 and SIP. If you enable AAA on the Cisco voice gateway or gatekeeper, a RADIUS accounting record is generated when an endpoint registers or unregisters and each time a call is initiated or disconnected.
For videoconferencing scenarios, the Cisco Multimedia Conference Manager (MCM) generates H.323 videoconferencing call records. MCM is a Cisco IOS feature that works in conjunction with Cisco VoIP gateways and routers.
The CCM details of CDR and CMR were described earlier. Therefore, this section addresses the collection of Call Detail Records (CDR) in the context of accounting for billing. Because CDRs contain information about call origination, destination, and duration, they can be a source for an accounting or billing application.
CCM stores CDRs in a SQL database for post-processing activities. Each regular call between two parties logs one CDR end-call record, which contains the fields listed in Tables 15-2 and 15-3. When supplementary services are involved in a call, more end-call records may be written. In addition to the CDR end-call record, one CMR per endpoint may be involved in a call. In a regular call between two parties, each using a Cisco IP phone, two CMRs are written: one for the originator and one for the call's destination. Depending on the various call types, such as normal calls, abandoned calls, forwarded calls, and calls with busy or bad destinations, different database fields are populated. CCM does not provide tools for call correlation or distinguish between chargeable calls and nonchargeable calls.
Figure 15-3 displays a Cisco CallManager CDR report from CAR. In addition to GUI reports, CDRs can be generated as PDF files and CSV files. Table 15-4 was created from a CDR file in CSV format.