Excerpt from Voice over IP Fundamentals, 2nd Edition.
More chapters from new and classic Cisco Press books
Rate your favorite Cisco Press books
Billing and mediation services are important in voice over IP (VoIP). They are key factors in helping a service provider or an enterprise vendor understand financial aspects, such as Return on Investment (ROI), when migrating its time-division multiplexing (TDM)-based network to VoIP. The public switched telephone network (PSTN) world offers a simpler billing structure for calls made over the network because the originator and the destination points are static and tied to a physical location. It also expects voice traffic (usage based on minutes of call durations) and data traffic (usage based on a flat fee) to be billed in different ways. VoIP changes this paradigm and allows the endpoints to move. The voice and data traffic are all packets that are transported from one location to another over the network. This raises some issues and requires protocol definitions on whom to bill, where to bill, and what to bill.
Billing Basics
In VoIP, other than a basic call made between two endpoints, you need to consider many service categories where billing requirements differ. It is important to note that the tools for implementing these services can vary. The broad categories of services are as follows:
Supplementary services:
— Forking
— Forwarding
— Transferring
— Redirecting
— Holding
— Find-me-follow-me
— Simultaneous ringing
Service categories:
— Billed by duration (voice, fax, voice mail recording/playing)
— Billed by data bytes (modem)
— Billed by page (fax)
— Billed by flat fee (for example, stock quotes)
Roaming
— Integration with billing and database services partners
Conference calling
— Planned
— Spontaneous
Multibox billing
— Conference server
— Voice-mail server
— Translations, SCP-based services
— Unified communications (UC)
— Integration of billing/UC partners
Authentication, Authorization, and Accounting (AAA)
AAA and RADIUS are two foundational blocks for billing services in the IP world. For VoIP, billing and mediation are services that a server requests. The clients are usually the entities that have call control information (for example, Media Gateway Control Protocol [MGCP] Call Agent, Session Initiation Protocol [SIP] Proxy server, and so on), whereas the server is where the processing of billing-related information takes place. Note that the client to the billing server might in turn be a server in the VoIP network for call control to its end users and VoIP clients. The three steps of AAA are as follows:
Authentication provides a vehicle to identify a client that requires access to some system and logically precedes authorization. Authentication is done through the exchange of logical keys or certificates between the client and the server.
Authorization follows authentication and sets the process of determining whether the client is allowed to perform or request certain tasks or operations. Therefore, authorization is at the heart of policy administration.
Accounting is the process of measuring resource consumption, allowing monitoring and reporting of events and usage for various purposes including billing, analysis, and ongoing policy management. VoIP offers innovative accounting models to evolve because of features like mobility, roaming, and inexpensive ways to carry voice traffic over data pipes.
RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a data-communications protocol designed to provide security management and statistics collection in remote computing environments, especially for distributed networks like VoIP. For accounting, it is well understood that centrally stored data is more secure, easier to manage, and scales more smoothly than data scattered throughout the network on multiple devices.
RADIUS operates on the client/server model. A RADIUS authentication server provides security services and stores security data, whereas a RADIUS accounting server collects and stores statistical data. Typically, a single machine provides both functions; however, the two RADIUS servers can reside on separate machines. Network engineers can configure a RADIUS client to use RADIUS security services, RADIUS accounting services, or both.
A RADIUS client consists of a network access server (NAS), which gives one or more remote users access to network resources. A single RADIUS server can serve hundreds of RADIUS clients and thousands of end users. You can address fault tolerance and redundancy concerns by configuring a RADIUS client to use one or more alternative RADIUS servers.
RADIUS provides three network services, known as authentication, authorization, and accounting (AAA). These services perform the following functions:
Identify remote users to ensure that they are valid users who can access the network (authentication)
Define what each user can do by controlling access to network resources (authorization)
Track the resources that each user consumes for the purpose of billing them for services (accounting)
The following are some other key features of RADIUS:
Network security—Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server to eliminate the possibility that someone who is snooping on an unsecured network can determine a user password.
Protocol extensions—All transactions are composed of variable-length Attribute-Length-Value 3-tuples. You can add new attribute values easily without disturbing existing implementations of the protocol. This property of RADIUS enables vendors to create certain vendor-specific attributes (VSA) that enable network providers to pass valuable information in them.
Flexible authentication schemes—The RADIUS server can support a variety of methods to authenticate a user. When it is provided with the username and the original password given by the user, it can support PPP Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP), UNIX login, and other authentication mechanisms.
Vendor-Specific Attributes (VSA)
Several VoIP protocols are in use today. Each of these protocols has its own set of features and information fields about the session established between two VoIP endpoints. Service providers looking for billing data often have special requests on certain attributes that can be passed to them only if certain additions are being made to the RADIUS accounting requests that are fed to the RADIUS servers. These new additions are mostly protocol specific (for example, H.323 or SIP may call for certain attributes).
Billing Formats
The telephony call control switch collects call detail records (CDR) during the course of the month, depending on how the billing cycle is defined. These CDRs are essentially the standards for every provider to offer billing-related information. If multiple providers are involved in a network, these also serve as tools to reconcile the charges.
Historically, the telephony billing systems were created at a time when most of the telephony industry players had essentially no competition. Now, IP telephony has made the industry unregulated by the FCC and extremely competitive. It has become more critical that the customer management and billing systems used to support IP telephony services can track and manage activities in real time.
VoIP calls are typically billed like PSTN dialed long distance, like cellular phones and prepaid cards with a pool of minutes, or like cable/satellite TV subscriptions as part of a multiservice subscription bundle. In all cases, voice call records are substantiated for billed charges, and all providers use CDRs to settle billing on interdomain calls. Call records are currently being created in several ways, as the sections that follow describe.
Typical Telco Approach
In this approach, the central office (CO) switch is responsible for the generation and exchange of billing records for PSTN-dialed calls. The CO switch produces Automatic Messaging Accounting (AMA) records, which include typical informational elements such as calling number, called number, connect time and date, call duration, and service characteristics. The AMA records are based on formats defined in Telcordia GR-1100-CORE document. They are then fed to a mediation/rating system that applies the tariff and rate basis for each call. The revenue assurance and pricing calculation are done at this step. Mostly, this is owned by the revenue accounting office for the telephony company. The next step is the final post-processing of the data after rate calculations and before being dispatched to the end-user billing system software or to the other carriers for exchange (third-party billing). Figure 9-1 illustrates the billing flow in the typical telco approach.
Basic Billing Flow
Although Telcordia is responsible for maintaining and updating the telco general requirements (GR) for mostly the U.S. markets, the incumbent telcos (IXCs) and their vendors work out their intercarrier billing and other operational issues in various committees of the Alliance for Telecommunications Industry Solutions (ATIS).
Open Settlements Protocol (OSP)-Based Approach
An alternative to the typical telco way of reconciliation of billing data is the use of Open Settlement Protocol (OSP). The European Telecommunications Standards Institute (ETSI), Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) develops OSP, which is described under the TS 101 321 specification. This method involves developing a clearinghouse provider to collect IP voice usage data. After a call is completed, OSP client software in both the originating and terminating gateways (or their controlling gatekeepers or SIP proxy servers) can report a tremendous variety of ETSI-specified usage data to the OSP server. This server, which is a third-party clearinghouse provider (such as ITXC, iBasis, and so on), typically controls, then exports, the OSP usage data or uses it to generate XML-based CDRs.
Originally developed to work with H.323 VoIP gateways, OSP is being enhanced to work with SIP. Besides facilitating billing settlements, the OSP specification defines the means to exchange interdomain pricing, routing, and authorization information. However, the OSP requires the clearinghouse to act as a trusted intermediary, and that implementation has been interoperability tested with many of those clearinghouses. Further, not all calls in the network can pass through the OSP server.
RADIUS-Based Approach
The Internet Engineering Task Force (IETF) has developed a RADIUS protocol that virtually all ISPs use to authenticate, authorize, and track the time used on dial-up Internet access. RADIUS accounting servers act as CDR archival-point VoIP softswitches and gateways. They can also be extended for vendor-proprietary RADIUS implementations to support additional data collection for VoIP, wireless, and prepaid (wireline/wireless) calling services. These servers must have ample disk memory and processing power to generate and save all the billing records and help in following an audit trail if needed.
VoIP gateways, softswitches, and intermediary servers have the information about the session and can provide information about the source and destination IP address, including port information, call duration, reason for disconnect, and so on.
SIP proxy servers, H.323 gatekeepers, and MGCP call agents in various VoIP networks pass the most common billing information.
IPDR-Based Approach
The Internet Protocol Detail Record (IPDR) Organization, an industry consortium, now offers a set of specifications for another usage record format—the Network Data Management-Usage specification Version 2.5 (NDM-U 2.5).
The intent behind these standards was to come up with a standard format for billing and mediation system vendors to use for VoIP CDRs. Although many IPDR participants have supported and endorsed the NDM-U, many vendors still have some proprietary modifications. IPDR members include vendors such as AceComm, ADC, Amdocs, Apogee, AP Engines, and Daleen Technologies.
The IPDR approach is more like packaging a traditional CDR in a more sophisticated way. It is based on XML and is readily extensible and convertible. IPDR formats enable a system to provide the billing-related information that other billing tools can transfer and process easily. Many systems prefer to use the IPDR format because it enables transforming data as needed by updating an XML schema.
Case Study: Cisco SIP Proxy Server and Billing
This case study is about a typical SIP-based VoIP network in which a Cisco SIP Proxy Server (SPS) sends to a RADIUS server Accounting-Request packets that correspond to the SIP transactions that the server processes. The Accounting-Request packets are Start and Stop records that contain a combination of standard RADIUS attributes and Cisco-defined VSAs.