Research and Implementation of the real-time billing function of the VoIP system

I. architecture of the billing system
The design of the VoIP Billing system follows the design principle of real-time Internet billing, and features real-time, stability, reliability, portability, and scalability. The function design not only takes into account the basic functions of the Internet billing system, it also considers users' needs and the business characteristics of the VoIP system.
The core part of the system, including the central database, the real-time billing server RTBS that can be backed up by each other, and the real-time billing proxy RTBA that is open to external devices ). With RTBA, all real-time billing functions are provided to external devices. RTBA provides a complete set of function interface APIs, allowing external devices to implement various functions simply by calling these functions. From the perspective of external devices, the internal details of the billing system are transparent, so the system can be easily transplanted and integrated. The RTBA design is a major feature of the system. Function call is performed between external devices and RTBA. RTBA and RTBS communicate with each other on standard TCP/IP, either on a LAN or on a WAN. To ensure the performance of the entire billing system, RTBA and RTBS must communicate with each other on a network with QoS Assurance.
Multiple RTBS can be used in the system, and RTBS can be backed up to each other. The RTBS redundancy can significantly improve the system capacity and stability and reliability of the system. The back-end database uses Oracle, And the RTBS and database still use a three-tier architecture. The middle layer uses Microsoft MTS to improve database access performance.
The system also provides the Keep Alive mechanism. GK maintains Keep Alive communication with RTBS through RTBA. Both GK and RTBS exceptions can be known to the other party immediately.
Ii. CDR format
CDR is the Call Detail Record), each complete Call should have a complete information CDR. The CDR information in the IP Phone is generally stored in two forms, one is the file form, can be a text file, binary file or CSV format file; the other is stored in the database, this is also the most common form. The IP Phone System background database has a table dedicated to storing CDRS.
The CDR information is generally collected by GK. Record CDRS have two main purposes: one is to serve as the basis for billing, and the other is to be used for customer query and audit. What information should be recorded in CDRS does not have a fixed requirement. Generally, different IP phone systems have different CDRS formats based on different business focuses, at the same time, some information that the customer cares most must be recorded in the CDR. The CDR format is based on the specific business characteristics of the system and the specific customer requirements. In addition to some required information fields, there are some special fields. Table 1 indicates each field in CDR and its meaning.
Iii. Formulation of tariff policies
The billing policy is a complete set of billing methods for various services, indicating who should charge and how to charge each service, it mainly includes the setting of normal rates, the setting of discount rates, the setting of fixed service fees and fines. Different suppliers have a set of tariff policies that suit their own characteristics based on their business needs. However, they must abide by the principle of uniform rate, only one Billing value can be calculated for a service under this billing policy, and there cannot be any ambiguous billing method.
The most common billing methods are:
1) billing by service duration, which is the most widely used billing method;
2) billing by service count;
3) paybytraffic may be upstream traffic, downstream traffic, or total traffic;
4) billing by bandwidth usage;
5) billing based on QoS parameters;
6) Mixed billing, for example, bandwidth and traffic.
At present, many ITSP mainly provide IP phone services in the form of PSTN + IP Gateway. In this case, the fee is calculated in two parts, namely, the fee of PSTN communication fee and IP internal service fee.
Data is transmitted in a three-segment network. The first segment is from the user's phone number to the IP Address Access Gateway, and the Access Gateway has a access number. The fee is charged by the PSTN. In section 2, from the Access Gateway to the Access Gateway, voice data is transmitted over an IP network. Large IP Phone operators generally transmit data over private networks or leased lines. This is the cost of IP internal services. The third section calls the PSTN call from the receiving gateway to the called phone. The first fee is generally paid by the caller, which is equivalent to the city charge. The fee in the second and third sections is the IP phone fee paid by the user. The carrier calculates the total cost and calculates the fee. The vast majority of such systems are billed Based on the call duration.
There will be discounts/preferential policies as needed in the IP Phone tariff policies, generally including time-out discounts, holiday discounts, and total discounts.
Billing policy management is critical to VoIP services. Flexible billing policy management is not only conducive to the operation and business expansion of service providers, but also greatly protects the interests of customers. Good tariff policy management should support the rate reservation and rate backtracking, support the real-time rate, and provide the accounting and comparison of multiple rates.
In addition to four basic business models: PC to PC, PC to Phone, Phone to PC, and Phone to Phone, VoIP also provides value-added services such as sending and receiving Voice Mail and call transfer, therefore, all services can be divided into two categories: one is the same with the PSTN, and the other is internal services without the PSTN fee.
In addition to the preceding billing methods, you must set the PSTN call rate and discount policy.
Iv. Main business Implementation of the billing system
1. Clock Synchronization
Clock Synchronization is critical in distributed applications. Especially in VoIP systems, time consistency is more important, and the clock error between devices cannot exceed 1 s. All devices in the system use the clock of the machine where the central database is located as the benchmark clock and provide a clock synchronization function. Each device in the system calls this function at intervals to proofread the local clock.
2. logon/Authentication
Here, we take the login of a Terminal as an example to introduce the authentication process of the billing system.
1) The terminal sends grq1_keeper Request to the specified top-level GK ). Top-level GK sends the gcf1_keeper Confirm packet back to the terminal, assigns a primary GK to the terminal, and enables the terminal to register with the specified Primary GK.
2) in GCF messages, top-level GK returns the IP address and Port of the primary GK to the terminal.
3) The terminal sends a RRQRegistration Request to the primary GK with parameters such as the user ID and password.
4) The primary GK calls the API functions provided by RTBA for request authentication.
5) RTBA sends a RADIUS authentication Request Access-Request to RTBS.
6) if the user ID-Password pair of the RTBS query center database is the same, the Access-Accept message in the RADIUS is returned to the RTBA.
7) The rtba api function returns the authentication confirmation result to the primary GK.
8) after obtaining the authentication result for the primary GK, send the RCFvRegistrationConfim message to the terminal and receive the user's logon.
If the user ID and password do not match in step 1, RTBS returns the Access-Reject message to RTBA. In the next step, the API returns the authentication rejection result, and sends the RRJRegistration-Reject message to the terminal in the first step.
3. Call request
After the user is verified, the call operation can be performed. When a terminal initiates a call to another terminal, GK determines whether the user can be authorized to initiate the call through the billing system before establishing the call. The call request process and call establishment process are omitted.
4. Check Points
In many billing systems, billing is only performed at the service start and end points. For example, you can notify the billing server at the beginning of a call, and then notify the billing server at the end of the call. Then, the billing server calculates the call fee at one time. This method is relatively simple, but not reliable. If a call starts and lasts for a long time, and GK encounters an exception, the billing server cannot be notified of the end of the call, the billing system will not be able to charge this call, which is a loss to the customer and the supplier. To avoid this loss, we enable the Checkpoint mechanism in the billing system, that is, set the Checkpoint during each call process, check the call status, check the system running status, and do the following:
1) Update the latest customer fee information;
2) write the CDR in the latest status.
The Checkpoint mechanism can be used to minimize the loss. With Keep Alive, exceptions can be detected immediately and processed accordingly. There may be many exceptions in the system. Here are two examples and corresponding solutions.
If GK finds an RTBS exception and the RTBS is responsible for billing of multiple calls, what GK needs to do at this time is to migrate all calls on the RTBS to other RTBS, in addition, you must avoid repeated deduction of the fee because the fee for a period of time before the call has been deducted from the previous Checkpoint. The handling method is not to migrate the latest call status, so that the RTBS will be re-charged from the time of migration, but the original call information, such as the call start time T0, the user's original fee balance0 is transferred to the new RTBS. RTBS can calculate the cost of cost1 from T0 to the current time, and get the latest balance of the customer using the original cost balance0 minus cost1, no matter how many Checkpoint operations the previous RTBS has performed on the call.
If the RTBS detects a GK exception, the system has other methods to remove the call that GK is responsible for when the GK exception occurs. All RTBS can use the time when the GK exception is detected as the call end time, in this way, the handling of such exceptions is simple. RTBS calculates the fee for this period of time and updates it to the customer account, and records the CDR information so far.
5. Last minute notifications
RTBS monitors the maximum call time of each call in real time. It notifies GK 1 minute before the call end, and requires GK to take the initiative to remove the call. This is the key to ensuring that the customer does not overdrawn the fee. After GK receives the last 1 min notification, it will notify the terminal and remove the call 1 min later.
6. Call end handling
When the call ends, a service is completed. This requires a complete record of the service and an accurate fee calculation of the service.
V. Conclusion
Based on the basic theory of Internet billing, this paper studies the functions of the billing system for VoIP services and some key problems in the billing system. Combined with the model of a VoIP system, this section focuses on the implementation of a real-time billing system and its key services.

References
[1] ITU-T. Packet-based multimedia communications systems. ITU-T Recommendation H.323 [S]. September 1999
[2] ITU-T. Call signalling protocols and media stream packetization for packet-based multimedia communication systems [S]. ITU-T Recommendation H.225.0.Feberary 1998
[3] ITU-T. Control protocol for multimedia communica-tion.ITU-T Recommendation H.245 [S]. September 1998
[4] C. Rigney, Livingston. RADIUS Accounting. RFC 2866 [S], Network Working Group, June 2000
[5] Marvin A. Sirbu. Internet Billing Service Design and Prototype Implementation [R]. Report of Information Networking Institute, Carnegie Mellon University