Understanding Rating and Billing

Understanding Rating and Billing

Ability to rate calls and bill Accounts, Customers and Vendors for them is a key functionality of the system, so that full understanding of how it works is really important. This chapter explains this subject in depth.

How Calls are Rated and Billed

When the call goes through the Switch there are at least 2 entities in the system to be billed for it: 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.

Algorithm works as follows:

  • When the system needs to rate or bill the call first it locates which Account is making it. After that it finds Tariff for that Account and selects the best matching Rate for the destination number as described above. Since there may be nested customers it checks if Customer to which that Account belongs is not a Root Customer and select the best matching Rate according to the respective Tariff for that Customer if not.

  • It iterates over the customers chain until Root Customer has been reached. This may sound as a complicated process, but in fact it is not. Rates are indexed by the DB server, while in practice really deep nesting is uncommon, so that selection of a best matching one is really quick in majority of cases with only 1-2 iterations.

  • NOTE: In the case when one of 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 somebody in the chain not pays for this call. When traversing the chain the Switch also records the difference between Balance and Credit Limit for each entity and also rejects the call if it finds that for some of them Balance already exceeds respective Credit Limit, thus not allowing customers to overdraw their credits.

  • The call will also be rejected if the system encounters Rate with Forbidden parameter enabled. Such Rates are designed to make it easier to ban particular prefix (for example toll free prefix or pay-per-minute numbers).

  • This procedure brings up several sets of distinct billing parameters for Account and one or more Customers. 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 fixed amount of money charged for each successful call regardless of its duration, and PostCallSurcharge which is additional charge applied, which is calculated as percentage of the amount charged, that is 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 value of the GracePeriod parameter with the duration of the call. The GracePeriod parameter determines the minimum duration of the call that will be subject of charge. Calls with durations of less than this value are not charged at all. GracePeriod value of 0 second and 1 second provide almost the same behavior except that when the GracePeriod is 1 second connected calls with zero duration won't be charged a connection fee.

A ConnectFee is charged immediately upon connection, and all calls shorter than Interval1 will be 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) will be rounded to Interval1 seconds. If call is longer than (Interval1 + FreeSeconds) remaining portion will be rounded up to multiple IntervalN seconds. After that, the PostCallSurcharge is applied to the total amount charged.

The call illustrated in the figure will be charged using the following formula:

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 present in 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 are not recognizing special characters properly (based on rfc 3261), it is possible to restrict the length of the number and reject the calls longer than the E.164 format.

For example, the case vendor removes dot ('.') from incoming CLD = 380.630700341 so that the number becomes 380630700341, and Sippy checks the prefix like 380. (with dot), 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.