Destinations, Rates and Tariffs
Destinations, rates and tariffs are the essential parameters which define
how a certain event should be billed. It is very important to find a
correct
set of *billing* parameters and rules (rates) for every event, and this
is done
by matching a service identifier with the available rates in the rate plan
(tariff). The service identifier specifies exactly how the service was
used.
For example, the service identifier for voice calls would be the
destination
number (Called-Station-Id, or CLD, or DNIS). For SMS messages, it
would likewise be a destination phone number, while for services such as
a pay-per-view movie it could be the movie category (“New *Release*”,
“International” or “Classic”). Since the rating of telephony numbers is the
most complex case, it will be the primary focus of this chapter.
Destinations
Destinations are a list of all possible phone number prefixes to be used in
your system. You generally need a new phone prefix when you have a new
service area for calls which are to be treated differently than others.
For example, if you start providing calls to the Czech Republic, you
should add destination 420 and specify it as Czech Republic. Later, if you
plan to charge calls to Prague differently than calls to the rest of the
Czech Republic, you might need to add another destination with the
phone number prefix 4202. All such destinations have to be entered into
the system before you can use these prefixes. This prevents errors and
helps you to improve data quality. It is recommended that all of your
prefixes be defined in the E.164 format.
It is virtually impossible to have an “ultimate” destination list that
would contain all prefixes for the entire world. First of all, it is quite
difficult to gather and maintain such information. Second, and even more important,
is the fact that having “all possible” prefixes would not offer us any real
benefits, and would only make rate maintenance more difficult. For
instance, if vendor A provides you with a rate of 0.10/min for calls to 420
(Czech Republic) and a 0.18 rate for calls to 420602 and 420603, you will
need to create three prefixes: 420, 420602 and 420603. If you also create
the prefix 4205 (Czech Republic, Brno) it will only take up space in the
database, as it will not ever actually be used.
Therefore, we recommend that you follow a “required minimum”
approach: only create those destinations for which you will need specific
rates for your carriers or customers.
For service types other than those based on phone numbers, you may
create symbolic destinations such as WIFI, DIALUP or MOVIE-
BLOCKBUSTER.
Destination groups
Sometimes you will have several prefixes for the same target destination,
e.g. 420602, 420603 and 420737 for mobile numbers in the Czech
Republic. All of these prefixes can be defined as the single destination
group “CZ Mobile”, so when you enter a new rate for this destination
group it will, in effect, create rates for each individual prefix.
Destination group sets
In happens quite often that different partners will assign a different
meaning to the same destination groups. For instance, your partner A says
that “CZ Mobile” is 420602, 420603 and 420737, but your partner B also
considers prefix 420777 to be part of “CZ Mobile”. So you will need to
have two versions of “CZ Mobile” – one for partner A and one for
partner B. In this situation, you will create two separate destination
group
sets (“A” and “B”), as well as different destination groups inside those
sets.
*Destination group set "MCI"*
*Destination group set "Retail"*
*CZ-Mobile*
420601
420602
420604
...
*UK-Mobile*
4403
4404
4407
4408
...
*CZ-Mobile*
420601
420602
420603
420604
...
*UK-Mobile*
4403
4404
4405
4407
...
You can imagine each destination group set as a binder, with every page in
that binder describing a certain destination group.
Rates
A rate is a combination of *billing* parameters for a specific destination.
For example, you can specify that calls to 420 are charged 0.09 USD/min
during peak time and 0.07 USD/min during off-peak time, while calls to
420609 should not be allowed at all.
Tariffs
A tariff is a complete set of rates for a specific account, customer or
vendor. Thus it should include every possible destination allowed by their
service plan (e.g. in the case of a telephony service, every destination to
which you want to let them call).
It may be that the tariff will contain some prefixes that are part of more
generic ones (for example, you will have a rate for the *420 *prefix and
for
the *4202 *prefix). In this case, the longest prefix match takes
priority. What
happens if a destination is not included in the tariff, and the customer
tries to call there? There are two possibilities:
o If outgoing calls are authorized via PortaBilling (for example, in
the prepaid card’s IVR) the customer will not be authorized to call
this destination.
o If there is no authorization, the customer will actually be able to
make a call, but PortaBilling will not be able to bill it properly,
since required information is missing. An email alert will be sent
and a special CDR will be written into the database, so you will
still have an overview of this call. It is highly recommended that
you always use authorization of calls via PortaBilling.
Relationship between destinations, rates and tariffs
Let’s move from VoIP to a simpler scenario. Imagine you are the owner
of an office supply store. You have to manage your inventory and price
lists for customers and resellers.
• First of all, you must create a catalog of all the items you intend to
sell. This is your internal document containing entries such as
“20001 – ball-point pen, blue; 20002 – ball-point pen; black;
50345 – stapler;” and so on. Note that this is just a description of
the items, without prices, since the price will depend on the
specific vendor/customer.
• You will receive price lists from your suppliers and convert them
into data files for every vendor, such as “Office Depot: 20001 –
$0.35; 20002 – $0.35; etc.”. Note two things: there is no need to
include an item description in every file – you can always extract
this from the catalog of items you have created above. Also, each
data file will contain only some of the items, i.e. those which are
provided by this particular supplier.
• The next step is to create similar price lists, but with the prices you
will apply to your customers. Of course, you might have several
such price lists: e.g. one for retail customers, another for business
customers, another for resellers, and so on. Every data file will
contain all of the items you offer to this category of customers,
including prices.
Now let’s come back to the VoIP business:
• /The catalog of items /corresponds to *destinations *in PortaBilling.
Every destination is similar to an item description in the catalog,
i.e. it provides general information (e.g. 420 – Czech Republic
proper, 420602 – Czech Republic mobile, and so on).
• /The price list (for vendor or customer) /is equal to a *tariff *in
PortaBilling.
The price list includes all items the customer may purchase and all
destinations the customer can make calls to. All tariffs are identical
in structure, but some of them will be used to calculate your costs
(vendor tariffs), while others will be used to charge your
customers.
• /A single line item in the price list /is equivalent to a *rate *in
PortaBilling.
It gives the price per minute and other rating parameters for a
specific destination.
Therefore, the standard sequence for setting up your service is as follows:
• Define the destinations you will use in your business. Basically you
will need to define every unique prefix used by your vendors (an
easy way to do this is by using PortaBilling’s default destination set
and PortaBilling templates).
• Create a tariff for every vendor using the rate list they supply.
• Create a tariff for every customer/product. Once again, note that
each tariff may contain a different set of destinations. For
instance, the tariff for your vendor ABC may contain different
rates for 420 (0.10/min), 4202 (0.09/min) and 420602 (0.18/min).
But you can just list a single rate for your customer in the tariff,
i.e. 420 – 0.20/min.
Relationship between tariffs and destination group sets
As mentioned before, multiple destination group sets may be defined in
the system, with some destination groups (e.g. CZ-Mobile) defined for
each of them. So, when you enter a new rate for CZ-Mobile in a specific
tariff, which destination group definition should be used? To avoid such
ambiguities, you will assign a destination group set for every tariff,
which
will be used to create new rates (if you do not assign a destination group
set to the tariff, then you can only enter rates for individual prefixes).
Thus when you attempt to create a new rate for destination group CZ-
Mobile, the following sequence of events takes place:
• PortaBilling locates the definition of the CZ-Mobile destination
group in the destination group set associated with this tariff.
• For every destination included in this destination group, the new
rate is inserted.
In other words, the result is the same as if you had created multiple rate
entries manually. Rates which are created using a destination group do not
differ in any way from rates created for a single destination. One
important consequence of the foregoing is that if you change the
destinations included in a destination group, it will not affect the
previously created rates. Thus if you had 420602 and 420603 in the CZ-
Mobile destination group, and you now add 420737, this will not affect
any of the tariffs. In order to have correct *billing* for the 420737
prefix,
you must go to the corresponding tariff and add a new rate for the CZ-
Mobile prefix.
Call *Billing* Parameters
Cost-based and volume-based *billing*
The traditional method of *billing* is cost-based *billing*. This means
that,
when a call is completed, the *billing* engine calculates the charges
for the
call based on price parameters for the call destination and duration. This
amount is then applied to the account, customer or vendor balance.
Volume discount plans allow rating of the call based not just on
information about it, but can dynamically adjust *billing* with regard to
other calls already made (e.g. if you have made more than 500 minutes of
calls to US&Canada this month already, the current call will be charged at
a 10% discount to the standard rate).
Cost-based *Billing*
Peak and off-peak prices
It is possible to have two different sets of prices – for peak and off-peak
time. Off-peak periods are defined using the powerful and flexible
Time::Period module. An Off-peak Period Wizard is also available,
allowing you to perform period definition the easy way. See the
*PortaBilling100 Web Reference Guide
<http://www.portaone.com/resources/documentation/>*
manual for more details.
The fundamental concept here is the period definition, which specifies a
certain interval in time (typically a repeating one). In each period you
can
specify conditions for:
• Time of day
• Day of week
• Day of month
© 2000-2013 PortaOne, Inc. All rights Reserved.
Destinations, rates and tariffs are the essential parameters which define
how a certain event should be billed. It is very important to find a
correct
set of *billing* parameters and rules (rates) for every event, and this
is done
by matching a service identifier with the available rates in the rate plan
(tariff). The service identifier specifies exactly how the service was
used.
For example, the service identifier for voice calls would be the
destination
number (Called-Station-Id, or CLD, or DNIS). For SMS messages, it
would likewise be a destination phone number, while for services such as
a pay-per-view movie it could be the movie category (“New *Release*”,
“International” or “Classic”). Since the rating of telephony numbers is the
most complex case, it will be the primary focus of this chapter.
Destinations
Destinations are a list of all possible phone number prefixes to be used in
your system. You generally need a new phone prefix when you have a new
service area for calls which are to be treated differently than others.
For example, if you start providing calls to the Czech Republic, you
should add destination 420 and specify it as Czech Republic. Later, if you
plan to charge calls to Prague differently than calls to the rest of the
Czech Republic, you might need to add another destination with the
phone number prefix 4202. All such destinations have to be entered into
the system before you can use these prefixes. This prevents errors and
helps you to improve data quality. It is recommended that all of your
prefixes be defined in the E.164 format.
It is virtually impossible to have an “ultimate” destination list that
would contain all prefixes for the entire world. First of all, it is quite
difficult to gather and maintain such information. Second, and even more important,
is the fact that having “all possible” prefixes would not offer us any real
benefits, and would only make rate maintenance more difficult. For
instance, if vendor A provides you with a rate of 0.10/min for calls to 420
(Czech Republic) and a 0.18 rate for calls to 420602 and 420603, you will
need to create three prefixes: 420, 420602 and 420603. If you also create
the prefix 4205 (Czech Republic, Brno) it will only take up space in the
database, as it will not ever actually be used.
Therefore, we recommend that you follow a “required minimum”
approach: only create those destinations for which you will need specific
rates for your carriers or customers.
For service types other than those based on phone numbers, you may
create symbolic destinations such as WIFI, DIALUP or MOVIE-
BLOCKBUSTER.
Destination groups
Sometimes you will have several prefixes for the same target destination,
e.g. 420602, 420603 and 420737 for mobile numbers in the Czech
Republic. All of these prefixes can be defined as the single destination
group “CZ Mobile”, so when you enter a new rate for this destination
group it will, in effect, create rates for each individual prefix.
Destination group sets
In happens quite often that different partners will assign a different
meaning to the same destination groups. For instance, your partner A says
that “CZ Mobile” is 420602, 420603 and 420737, but your partner B also
considers prefix 420777 to be part of “CZ Mobile”. So you will need to
have two versions of “CZ Mobile” – one for partner A and one for
partner B. In this situation, you will create two separate destination
group
sets (“A” and “B”), as well as different destination groups inside those
sets.
*Destination group set "MCI"*
*Destination group set "Retail"*
*CZ-Mobile*
420601
420602
420604
...
*UK-Mobile*
4403
4404
4407
4408
...
*CZ-Mobile*
420601
420602
420603
420604
...
*UK-Mobile*
4403
4404
4405
4407
...
You can imagine each destination group set as a binder, with every page in
that binder describing a certain destination group.
Rates
A rate is a combination of *billing* parameters for a specific destination.
For example, you can specify that calls to 420 are charged 0.09 USD/min
during peak time and 0.07 USD/min during off-peak time, while calls to
420609 should not be allowed at all.
Tariffs
A tariff is a complete set of rates for a specific account, customer or
vendor. Thus it should include every possible destination allowed by their
service plan (e.g. in the case of a telephony service, every destination to
which you want to let them call).
It may be that the tariff will contain some prefixes that are part of more
generic ones (for example, you will have a rate for the *420 *prefix and
for
the *4202 *prefix). In this case, the longest prefix match takes
priority. What
happens if a destination is not included in the tariff, and the customer
tries to call there? There are two possibilities:
o If outgoing calls are authorized via PortaBilling (for example, in
the prepaid card’s IVR) the customer will not be authorized to call
this destination.
o If there is no authorization, the customer will actually be able to
make a call, but PortaBilling will not be able to bill it properly,
since required information is missing. An email alert will be sent
and a special CDR will be written into the database, so you will
still have an overview of this call. It is highly recommended that
you always use authorization of calls via PortaBilling.
Relationship between destinations, rates and tariffs
Let’s move from VoIP to a simpler scenario. Imagine you are the owner
of an office supply store. You have to manage your inventory and price
lists for customers and resellers.
• First of all, you must create a catalog of all the items you intend to
sell. This is your internal document containing entries such as
“20001 – ball-point pen, blue; 20002 – ball-point pen; black;
50345 – stapler;” and so on. Note that this is just a description of
the items, without prices, since the price will depend on the
specific vendor/customer.
• You will receive price lists from your suppliers and convert them
into data files for every vendor, such as “Office Depot: 20001 –
$0.35; 20002 – $0.35; etc.”. Note two things: there is no need to
include an item description in every file – you can always extract
this from the catalog of items you have created above. Also, each
data file will contain only some of the items, i.e. those which are
provided by this particular supplier.
• The next step is to create similar price lists, but with the prices you
will apply to your customers. Of course, you might have several
such price lists: e.g. one for retail customers, another for business
customers, another for resellers, and so on. Every data file will
contain all of the items you offer to this category of customers,
including prices.
Now let’s come back to the VoIP business:
• /The catalog of items /corresponds to *destinations *in PortaBilling.
Every destination is similar to an item description in the catalog,
i.e. it provides general information (e.g. 420 – Czech Republic
proper, 420602 – Czech Republic mobile, and so on).
• /The price list (for vendor or customer) /is equal to a *tariff *in
PortaBilling.
The price list includes all items the customer may purchase and all
destinations the customer can make calls to. All tariffs are identical
in structure, but some of them will be used to calculate your costs
(vendor tariffs), while others will be used to charge your
customers.
• /A single line item in the price list /is equivalent to a *rate *in
PortaBilling.
It gives the price per minute and other rating parameters for a
specific destination.
Therefore, the standard sequence for setting up your service is as follows:
• Define the destinations you will use in your business. Basically you
will need to define every unique prefix used by your vendors (an
easy way to do this is by using PortaBilling’s default destination set
and PortaBilling templates).
• Create a tariff for every vendor using the rate list they supply.
• Create a tariff for every customer/product. Once again, note that
each tariff may contain a different set of destinations. For
instance, the tariff for your vendor ABC may contain different
rates for 420 (0.10/min), 4202 (0.09/min) and 420602 (0.18/min).
But you can just list a single rate for your customer in the tariff,
i.e. 420 – 0.20/min.
Relationship between tariffs and destination group sets
As mentioned before, multiple destination group sets may be defined in
the system, with some destination groups (e.g. CZ-Mobile) defined for
each of them. So, when you enter a new rate for CZ-Mobile in a specific
tariff, which destination group definition should be used? To avoid such
ambiguities, you will assign a destination group set for every tariff,
which
will be used to create new rates (if you do not assign a destination group
set to the tariff, then you can only enter rates for individual prefixes).
Thus when you attempt to create a new rate for destination group CZ-
Mobile, the following sequence of events takes place:
• PortaBilling locates the definition of the CZ-Mobile destination
group in the destination group set associated with this tariff.
• For every destination included in this destination group, the new
rate is inserted.
In other words, the result is the same as if you had created multiple rate
entries manually. Rates which are created using a destination group do not
differ in any way from rates created for a single destination. One
important consequence of the foregoing is that if you change the
destinations included in a destination group, it will not affect the
previously created rates. Thus if you had 420602 and 420603 in the CZ-
Mobile destination group, and you now add 420737, this will not affect
any of the tariffs. In order to have correct *billing* for the 420737
prefix,
you must go to the corresponding tariff and add a new rate for the CZ-
Mobile prefix.
Call *Billing* Parameters
Cost-based and volume-based *billing*
The traditional method of *billing* is cost-based *billing*. This means
that,
when a call is completed, the *billing* engine calculates the charges
for the
call based on price parameters for the call destination and duration. This
amount is then applied to the account, customer or vendor balance.
Volume discount plans allow rating of the call based not just on
information about it, but can dynamically adjust *billing* with regard to
other calls already made (e.g. if you have made more than 500 minutes of
calls to US&Canada this month already, the current call will be charged at
a 10% discount to the standard rate).
Cost-based *Billing*
Peak and off-peak prices
It is possible to have two different sets of prices – for peak and off-peak
time. Off-peak periods are defined using the powerful and flexible
Time::Period module. An Off-peak Period Wizard is also available,
allowing you to perform period definition the easy way. See the
*PortaBilling100 Web Reference Guide
<http://www.portaone.com/resources/documentation/>*
manual for more details.
The fundamental concept here is the period definition, which specifies a
certain interval in time (typically a repeating one). In each period you
can
specify conditions for:
• Time of day
• Day of week
• Day of month
© 2000-2013 PortaOne, Inc. All rights Reserved.
Comments
0 comments
Article is closed for comments.