Cisco SPS generates Accounting-Request packets for all branches of each INVITE and BYE transaction. This facilitates start and stop records being sent to a RADIUS server for all call attempts, including all branches of forked call-attempts, whether successful, unsuccessful, or canceled. All Accounting-Request packets for the same call contain the same Call ID, and the RADIUS server, or a billing server working with the RADIUS server, must be able to correlate Accounting-Request packets based on this Call ID. The high-level diagram in Figure 9-2 shows a SIP call from one SIP phone to another through Cisco SPS and the corresponding RADIUS Accounting-Request packet that Cisco SPS sends to the RADIUS server. In this example, the RADIUS server forms a CDR from the Accounting-Request packet and forwards the CDR to the billing server for correlation.
Cisco SIP-Based VoIP Accounting Components
The configuration options in the Cisco SPS enable the customization of accounting triggers. To upstream entities, Cisco SPS appears as a server-side entity that handles requests. To downstream entities, Cisco SPS appears as a client-side entity that initiates requests. Configuration options enable accounting for call attempts on the server side or client side and for successful or unsuccessful call attempts.
The call flow in Figure 9-3 demonstrates the various accounting records that a call can generate.
Typical SIP-based VoIP Accounting Call Flow
The following process describes the call-flow protocol outlined in Figure 9-3:
User A wants to call User B. User A sends an INVITE for User B to Cisco SPS.
User B has registered at both B1 and B2.
Cisco SPS sends the INVITE to both B1 and B2.
B2 is busy and returns 486. Cisco SPS sends client-side unsuccessful Stop.
User B has a Call Forward Busy contact set to B3, so Cisco SPS forwards INVITE to B3.
The INVITE to B1 times out. Cisco SPS generates an internal 408 and sends client-side unsuccessful Stop.
B3 answers the call and returns 200. Cisco SPS sends client-side Start.
Cisco SPS forwards 200 to User A and sends server-side Start.
User A sends an ACK.
Cisco SPS forwards the ACK to User B.
User A sends the BYE to Cisco SPS.
Cisco SPS forwards the BYE to B3.
Cisco SPS receives the 200 for the BYE from B3 and sends client-side successful Stop.
Cisco SPS forwards the 200 for the BYE to User A and sends server-side successful Stop.
This completes the callflow steps in Cisco SPS client-side interface with the RADIUS server.
The RADIUS server accounting details are described next.
RADIUS Server Accounting
For a successful server-side call attempt, a Start record is sent when a 200 final response for the INVITE is returned upstream. A Stop record is sent when a final response is sent for the BYE.
RADIUS Interface for Cisco SPS
The Start record contains an h323-start-time, which is the time the INVITE was received, and an h323-connect-time, which is the time at which the 200 was sent. The h323-call-origin is set to answer, indicating that this is a server-side accounting record. The sip-status-code VSA is set to 200, which is the value of the final response for the INVITE. A text representation of the Start, complete with all standard RADIUS attributes and Cisco-defined VSAs, is as follows:
NAS-IP-Address = a.4.61.72 NAS-Port-Type = Virtual User-Name = "1230" Service-Type = Login-User Acct-Status-Type = Start Acct-Session-Id = "04fb5d3908f3bfbe24fabfbe24f9bfbe@a.4.61.70" Called-Station-Id = "<sip:5670@a.4.61.72:5060>" Calling-Station-Id = "<sip:1230@a.4.61.70:9090>" Vendor-Specific-9-25 = "h323-setup-time=21:31:14.578 GMT Mon Apr 14 2003" Vendor-Specific-9-28 = "h323-connect-time=21:31:24.692 GMT Mon Apr 14 2003" Vendor-Specific-9-26 = "h323-call-origin=answer" Vendor-Specific-9-27 = "h323-call-type=VoIP" Vendor-Specific-9-1 = "sip-status-code=200" Vendor-Specific-9-1 = "session-protocol=sip" Vendor-Specific-9-1 = "call-id=04fb5d3908f3bfbe24fabfbe24f9bfbe@a.4.61.70" Vendor-Specific-9-1 = "method=INVITE" Vendor-Specific-9-1 = "prev-hop-via=SIP/2.0/UDP a.4.61.70:9090" Vendor-Specific-9-1 = "prev-hop-ip=a.4.61.70:9090" Vendor-Specific-9-1 = "incoming-req-uri=sip:5670@a.4.61.72:5060" Vendor-Specific-9-1 = "outgoing-req-uri=sip:5670@a.4.106.19:5060" Vendor-Specific-9-1 = "next-hop-ip=a.4.106.19:5060"
The Stop record contains an h323-disconnect-time, which is the time at which the BYE was received. The h323-call-origin is set to answer, indicating that this is a server-side accounting record. The h323-disconnect-cause is not used; instead, the sip-status-code VSA is added and set to the value of the final response for the BYE. For this reason, the Stop is not sent until the final response for the BYE has been sent. A text representation of the Stop, complete with all standard RADIUS attributes and Cisco-defined VSAs, is as follows:
NAS-IP-Address = a.4.61.72 NAS-Port-Type = Virtual User-Name = "1230" Service-Type = Login-User Acct-Status-Type = Stop Acct-Session-Id = "04fb5d3908f3bfbe24fabfbe24f9bfbe@a.4.61.70" Called-Station-Id = "<sip:5670@a.4.61.72:5060>;tag=1F37F280-21AD" Calling-Station-Id = "<sip:1230@a.4.61.70:9090>" Vendor-Specific-9-29 = "h323-disconnect-time=21:31:44.770 GMT Mon Apr 14 2003" Vendor-Specific-9-26 = "h323-call-origin=answer" Vendor-Specific-9-27 = "h323-call-type=VoIP" Vendor-Specific-9-1 = "sip-status-code=200" Vendor-Specific-9-1 = "session-protocol=sip" Vendor-Specific-9-1 = "call-id=04fb5d3908f3bfbe24fabfbe24f9bfbe@a.4.61.70" Vendor-Specific-9-1 = "method=BYE" Vendor-Specific-9-1 = "prev-hop-via=SIP/2.0/UDP a.4.61.70:9090" Vendor-Specific-9-1 = "prev-hop-ip=a.4.61.70:9090" Vendor-Specific-9-1 = "incoming-req-uri=sip:5670@a.4.61.72:5060" Vendor-Specific-9-1 = "outgoing-req-uri=sip:5670@a.4.106.19:5060" Vendor-Specific-9-1 = "next-hop-ip=a.4.106.19:5060"
An unsuccessful server-side call attempt has no Start record. A Stop record is sent when the best non-200 response for the INVITE is returned upstream, including the CANCEL scenario in which Cisco SPS waits for the 487 from the downstream and returns it upstream. The Stop record contains an h323-start-time, which is the time at which the INVITE message was received, and an h323-disconnect-time, which is the time at which the final response was sent. The h323-call-origin is set to answer, indicating that this is a server-side accounting record. The sip-status-code VSA is set to the value of the final response for the INVITE and is the most common attribute extension, as used in the networks.
Most of the Cisco VoIP network elements provide a RADIUS interface, acting as RADIUS clients for the support of the AAA functionality.
The AAA functionality corresponds to the authentication of the caller, the authorization of the call, and the accounting for the call. The authentication and authorization functions are used when subscriber billing is required or when the support of whitelists or blacklists is required. The accounting function is required for all types of billing—prepaid and postpaid billing and intercarrier settlements. Cisco VoIP-enabled network elements support the RADIUS Accounting Start, Accounting Stop, and Accounting Interim-Update messages, in addition to the Accounting-On and Accounting-Off messages.
Similarly, in today's H.323 VoIP implementation, the voice-enabled gateways send RADIUS accounting Start and Stop messages to a RADIUS server-based mediation or billing system. For the debit card application, the gateway interacts with the RADIUS server to obtain credit balance and time limit for the call (call authorization). Many commercial IP-based billing systems such as Digiquant and Mind have built-in RADIUS servers that can support billing for basic VoIP services without a mediation device. However, it is in the customer's best interest to use a separate mediation system if the services on offer are, or might become, more complex than a basic point-to-point call.
Cisco collaborates with mediation and billing partners, enabling customers to select the most appropriate level of functionality for their needs. Some Cisco partners perform mediation only, others perform mediation and billing in a tightly coupled fashion, and still others sell mediation and billing platforms independently or in an integrated fashion.
Note - H.323 was the original protocol developed for VoIP on the Cisco VoIP gateways. That is why "h323" is present in the command names. However, because SIP and H.323 use a similar distributed call-processing and billing model, the same commands work for either H.323 or SIP as the VoIP protocol.
Prepaid and Postpaid Applications
Prepaid is one of the most common applications for billing. In prepaid applications, information access to user funds before the call is important so that you can see how much cash is available for the call to be made. When the call destination is known, a timer is started to disconnect the call when the prepaid funds have been consumed. A user-friendly approach might entail interrupting the call for clarity. Another important feature might be the ability to place the existing call on hold, ask the originating caller to add more funds to the card, collect the funds, and potentially resume the call.
Furthermore, these applications require an accurate way to apply the tariff to rate other calls. Other critical considerations include security and authenticating in scenarios when PINs are used and multiple calls are tried.
For postpaid applications, the call originator needs to be authorized. The call flow for such a service involves collecting the phone number of the person who originated the call (ANI) and sending it to the RADIUS server, essentially using it as an account number. An interactive voice response (IVR) system guides the caller throughout the application and enables him to use dual-tone multifrequency (DTMF) tones to traverse through the validation process.
Prepaid or postpaid, the cost of each call is an interesting issue to consider. The rating aspect becomes more important in VoIP because the caller location can be mobile and is not tied to a geographical coordinate. That is why you should assign negotiated rates for various combinations of locations or charge a flat rate.
The VoIP network generates CDRs that contain data about which extension made or received calls to or from which number and for how long. These records are generally stored in plain-text logfiles at the servers or even located in a PostgreSQL package or in MySQL databases with additional processing. The billing process starts only when the generation of rating procedures for CDRs has been defined well.
Challenges for VoIP Networks
The VoIP networks have evolved from proof-of-concept stages to mature services that drive revenues and cost savings. Over the years, the networks became a mix of many different call agents, proxy servers, VoIP gateways, and other elements that were added in evaluation phases with many different features. The providers now face two fundamental problems:
Mixed usage and billing record formats
Volume
All the different softswitches and services created a chaotic mix of usage and billing records in several different formats. The mix of formats became a problem in terms of interoperability and loss of data integrity.
With regard to volume, IP-related events typically produce far more records than traditional voice calls, and this is agnostic of the voice protocol in use at the softswitches. The VoIP records averaged nine events for normal calls and even more for special services or error cases. The data to be analyzed involves checking for the number of packets lost or delayed from the transmit side and the received side, checking for media packet inactivity between the source and destinations, and the usual call duration and calling/called number details. Furthermore, different records are generated by the ingress (incoming) than by the egress (outgoing) softswitches, requiring correlation of the records to provide a comprehensive view of the whole call. Even if the billing system could understand the VoIP services, the sheer number of records it would have to process would be a challenge in itself.
To address these challenges, a new group of mediation services companies have emerged to collect, correlate, and aggregate billing and accounting under one umbrella suite of services.
Mediation Services
A mediation system collects, correlates, and aggregates the accounting messages generated by the various VoIP-enabled network elements involved in a call. It converts these into standard or proprietary CDR formats, such that one and only one CDR is generated for each call. Mediation systems are usually required by service providers that already have a billing system and expect the output of the mediation system to be in a format that their existing billing system recognizes. Many mediation systems are able to support the commercial billing systems from various vendors such as Keenan, Amdocs, Portal, and Solect. Almost all VoIP deployments in Incumbent Local Exchange Carriers (ILEC), Regional Bell Operating Companies (RBOC), and the more traditional U.S. and Canadian service providers with legacy billing systems expect CDRs to be presented in Belcore AMA Format (BAF).
However, VoIP also requires the billing system to know what is to be counted and analyzed. This information for analysis could be call duration, but it could also mean transferring megabytes of data (voice/video), fixing a price for video, or counting the instances of text-based messaging (SMS) or multimedia messaging service (MMS). A billing system has to rely on a mediation system that identifies what end users are doing with their configured calling plans and service-level agreements. The system can thus create an event-type record on which to rate the bill. As an end result, these systems provide the value addition to the billing systems to offer a comprehensive view of customer data and voice services.
Mediation Service vendors are now offering services that range from basic mediation (capture and aggregation of call events, generation of multiple CDR formats) to database-centric services such as reporting and analysis. Some also offer more sophistication via certain value-add modules for various rating methods and correlation services. Correlation will become a critical component in the coming days as we see VoIP calls being tied up with web access, audio/video conferencing, and telepresence in deployments.
Summary
Billing and mediation are important revenue-affecting pieces of any VoIP-based service. With so many VoIP protocols and small service providers and businesses launching VoIP, it is imperative that billing procedures are standardized and formats picked up prior to launch of service.
The global growth of VoIP-based systems presents several challenges to the service provider with regard to data capture, processing, and billing. Mediation software plays a key role in VoIP networks. It accepts data from various network elements (for example, softswitches, media servers, signaling gateways, and service development platforms) and transforms it into industry-standard billing data structures that can be used by virtually any billing system, including the legacy voice billing system of a service provider.
Copyright © 2007 Pearson Education. All rights reserved.