Understanding Rating and Billing
This article explains how the rating and billing functionality work.
How Calls are Rated and Billed
When a call goes through the softswitch there are at least 2 entities in the system to be billed for it: an Account and one or more Customers. All relevant Accounts and Customers are billed according to rules defined by the Tariff associated with each of them.
The Algorithm applied to Rating and Billing works like this:
When the system needs to rate or bill a call it first locates which Account is making it. Once it recognizes the Account, it finds a Tariff for that Account and selects the best matching Rate for the destination number. Since there may be nested customers (inside the Customer) it checks if the Customer to which that Account belongs is a Root Customer and then it selects the best matching Rate according to the respective Tariff for that Customer.
It iterates over the customer's chain until the Root Customer has been reached. Rates are indexed by the DB server
When one of the links in the chain from the Account to the Root Customer doesn’t have a Rate matching the destination number, the call will not be allowed to go through, since this would mean that nobody in the chain would pay for the call. When traversing the chain the softswitch checks the difference between Balance and Credit Limit for each entity and rejects the call if it finds that at any point the Balance exceeds the respective Credit Limit - in this way the system prevents a customer from exceeding their credit limit
The call is rejected if the system encounters a Rate with a Forbidden parameter enabled; such Rates are designed to make it easier to ban a particular prefix (for example a toll free prefix or a pay-per-minute number)
The algorithm proceeds through several distinct billing parameters in the Account and in each Customer inside the Account. Those parameters and their meaning are described in details below:
From Tariff the system obtains the following parameters:
FreeSeconds : in seconds
ConnectFee : in monetary units
PostCallSurcharge : in percents (0.01 means 1%)
GracePeriod : in seconds
From Rate the system obtains:
Price1 : in monetary units per minute
PriceN : in monetary units per minute
Interval1 : in seconds
IntervalN : in seconds
The simplest parameters are: ConnectFee, which is the fixed amount of money charged for each successful call regardless of its duration, and PostCallSurcharge which is the additional charge applied, calculated as a percentage of the amount charged. So, if the call cost is 1 dollar and the PostCallSurcharge is 0.01, the actual amount charged will be 1.01 dollar.
The following picture illustrates how the calls are charged. The process starts with comparing the value of the GracePeriod parameter with the duration of the call. The GracePeriod parameter determines the time (if any) that will not be charged for each call. Calls with a duration of less than the GracePeriod value are not charged at all. A GracePeriod value of 0 second and 1 second provide almost the same "free" period except that when the GracePeriod value is 1 second, connected calls with 0 second duration are not charged a connection fee.
A ConnectFee is charged immediately upon connection, and all calls shorter than Interval1 are rounded to Interval1 seconds. FreeSeconds are granted after the Interval1, so this part of the call is not charged; therefore, calls shorter than (Interval1 + FreeSeconds) are rounded to Interval1 seconds. If the call is longer than (Interval1 + FreeSeconds) the remaining portion is rounded up to multiple IntervalN seconds. After that, the PostCallSurcharge is applied to the total amount charged.
The call illustrated in the figure is charged using the following formula:
** Value 4 - is a number of intervals N (marked in blue on illustration)
Connect fee : monetary units
Price 1 : monetary units
Price N : monetary units
Interval 1 : seconds
Interval N : seconds
Post call surcharge : fractional based on the setting in the Tariff/Destination Set (E.g. for 10% fractional = 0.1)
Special characters in scope of Rating and Billing
For the proper billing of incoming and outgoing calls it is important to know the meaning of "Reserved" and "Unreserved" characters that can be present in the SIP URI of the call.
Reserved characters are those characters that sometimes have special meaning.
For example, forward @ character is used to separate different parts of a URI.
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / ","
Unreserved characters that are allowed in a URI but do not have a reserved purpose are called unreserved.
These include upper and lower case letters, decimal digits, and a limited set of punctuation marks and symbols.
Those can be used in calls as a part of username and can be used for billing (as a prefix)
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / " ' "/ "(" / ")"
Please refer to RFC 3261 for more details.
If a switch operator wants to protect himself from billing disputes with vendors that do not recognize special characters (based on RFC 3261), it is possible to restrict the length of the number and reject calls with numbers longer than the E.164 format.
For example, the Vendor removes the period ('.') from incoming CLD 380.630700341 so that the number becomes 380630700341, Sippy checks the prefix as if it were 380. (with the period) The operator can set "Min. Length" and "Max. Length" for the 380 prefix to be 12 in the Destinations menu.
After that calls to numbers like 380.630700341 would be properly rejected with the "invalid number" SIP error.