Snom Prepaid Services, 4S Frequently Asked Questions Manual

F REQUENTLY
A SKED
Q UESTION

Prepaid Services

Date: Oct-28-2003
Author: Christian Stredicke
Document: faq-03-10-28-cs

2 snom technology AG

[ F R E Q U E N T L Y A S K E D Q U E S T I O N ]

Prepaid Services 3

[ F R E Q U E N T L Y A S K E D Q U E S T I O N ]

Prepaid calling cards are becoming more
and more popular in SIP-based VoIP telephony.
This FAQ show how the snom 4S can be used
to implement a prepaid service.

Limited Trust

Prepaid calling cards are often sold
without exact knowledge about the user’s
credit, bank account or credit card number.
This implies that abuse of calling cards must
be avoided as there is no way to charge costs
beyond the already paid amount. Specically,
that means when the calling cards becomes
empty, the active call must be terminated.
In order to avoid surprises, the user should
get an indication shortly before the calling
card gets empty ("Your calling card is almost
empty!").

When the user dials into the calling card
system, he is also interested in how much
credit is left on this calling card. An IVR system
should be able to indicate this credit.

The system must also be robust against
cheating attempts like calling the account
twice at the same time, bypassing a proxy or
"pulling the plug" before the end of the call (no
BYE message). In many cases it is desirable
to hide the true destination of the call, may it
be a gateway or another Internet Telephony
Service Provider (no Record-Route on the
client side).

This all makes it necessary that the
calling card service provides both SIP and RTP
data streams. By handling RTP, the system
becomes able to play announcements and mix
messages into the conversation.

Eavesdropping PINs

In many cases in SIP, it is not secure
to choose "pin codes" for authentication.
Eavesdroppers that monitor the SIP trafc
can easily try 10,000 or even 100,000
combinations with all valid pins to guess the
pin for this account.

MS

Full Cone
NAT

Symmetrical
NAT

A

B

C

GW

Client
Side

Service

Side

Public
IP

Prepaid Services 3

[ F R E Q U E N T L Y A S K E D Q U E S T I O N ]

When a user authenticates with the media
server, the situation is a little bit different. The
PINs will not be visible in SIP, they will be
transported in RTP. Because RTP is transported
without encryption, an eavesdropper can
just monitor the PIN. On the other hand, it
will be relatively hard for him to try 10,000
combinations, because that would require
10,000 call attempts to the calling card server.
In addition, he would have to try out a number
of calling cards. In total, this would be an
obvious attack which can easily be detected.
Therefore, we believe that choosing a 10-digit
calling card number together with a 4 digit PIN
gives sufcient security for the calling card
application.

Calling cards in snom 4S

Calling cards are normally not part of
the standard media server. You need to have
a "cc" license type (for example, cc1). Please
approach your snom sales contact if you need
such a license key.

The snom 4S handles calling cards on
the "media server". The media server does
more than just handling RTP, it includes an
application server that performs the necessary
actions to interact with the user and keep
track of the account’s credit. By the close
interaction between application server and put
media handling, synchronization problems and
database integrity problems are avoided.

Technically, this architecture is called
"back to back user agent" (B2BUA). In this

FAQ, the side to the customer is called "client
side", while the side to the gateway or ITSP is
called "service side". The gure illustrates the
situation.

In the ideal case, the caller uses a
phone on the public Internet (A). However,
many customers are using phones in private
networks behind full cone (B) or symmetrical
NAT (C). Because the media server is located
on the public Internet, it is relatively easy to
deal with the NAT problems.

The proxy is usually used for the routing
of the calls. A dial plan can nd the cheapest
route for this call and keep track of additional
information, for example CDR for the service
side. From a architectural point of view, adding
a proxy on the client side or the service side
does not make a difference.

Setting up the snom 4S

First of all, you need to make sure that
the media server can be found via DNS. If you
want that the users directly go to the media
server, you should set up the DNS SRV and A
records accordingly.

On the media server, you need to set up
at least one calling card account. Currently,
this account type has the name "Calling Card
Type 2".

The card account has a few parameters
which control the behavior:

• card_length: This entry describes how

many digits the media server expects for

4 snom technology AG

[ F R E Q U E N T L Y A S K E D Q U E S T I O N ]

Prepaid Services 5

[ F R E Q U E N T L Y A S K E D Q U E S T I O N ]

the calling card number. A typical value is

10.

• pass_length: This is the length of the
password. A value of 4 of 5 is a typical
value.

• gateway: When the media server receives
the destination number, it needs a domain
name to create a SIP URL. It appends the
gateway string to the entry and will attempt
to dial this number. A typical example would
be “example.com” or “12.23.34.45:5062”.

• warning: Before the card expires, the
media server plays an announcement. This
setting tells the media server, how many
seconds before the active call is terminated
the warning messages is mixed into the
conversation.

When you edit such an account type,
you will see additional elds appear on the
web page (the default elds are described
in the media server manual). These elds
take care about the rates that are charged
for a call. To import rate, you need to dene
a CSV (described below) and load it into the
account. Rates are stored together with the
other account information. That means, that
each calling card account has its own rates
associated with it.

Rate Denition

To dene rates, you need to create a
comma separated values (CSV)-le. This can
be easily done with a normal text editor. The
CSV le has the following format.

Every rate is described in a line. A rate
consists of a country code, a pattern, a name
and a price.

The country code can be any number.
Special characters like # or * are not allowed. It
is allowed to use the same country in different
lines. The media server will take the line which
matches best according to the pattern.

The pattern consists of a list of country
code extensions. The list elements are
separated with commas (no space). The
elements themselves may contain a range with
a dash between the minimum and maximum

value. For example, the element 100-104
would describe the extensions 100, 101, 102,
103 and 104. The length of the numbers in the
range must be the same. So the pattern 100­104,110,120 would describe the extensions
100, 101, 102, 103, 104, 110 and 120.

The name is just descriptive and has not

specic function.

The price can be any positive xed or
oating point number. The price is measured
in price per minute.

If the country code is "*", the line
describes the default price for a call. This
line will be taken if no other line matches the
number entered. If the "*" line is not present,
the media server will not initiate a call and
report an error about a wring number.

A typical CSV le would look like this:

01149;177;Germany Cell;0.12
01149;;Germany General;0.18
01141;;Switzerland;0.28
*;;Default;0.20

The media server shows the current rate
table below the load dialog. After importing
the rate table, you should check if the import
was successful.

Creating Calling Cards

After you have created one or more
calling card accounts, you need to set up calling
cards. Typically, this job is done automatically.
Therefore, the user interface to this function is
minimal.

On the navigation bar, you nd the link
"Calling Card". If you click on this link, you will
nd the following dialog:

In the eld "Calling Card Account" you
need to enter the account name (e.g. "100"
in the above example). The media server does
not perform any checks on this eld, so please
make sure that this account exists.

The "Calling Card Number" eld takes the
number of the new calling card. The length
must be as set up in the "card_length" eld

Prepaid Services 5

[ F R E Q U E N T L Y A S K E D Q U E S T I O N ]

of the account. The "Code" eld takes the PIN
code, the length must match "pass_length".

The "Credit" eld takes the initial amount
that is put into this account. Note that writing
this value overwrites previous values.

Typically, you will use automatic tools that
load a large number of calling cards into your
account (note that you need only one account
for them, no matter how many accounts you
load). "curl" is a good tool for performing this
job. Please refer to the FAQ on remote control
of the snom 4S on details of this feature or ask
your support engineer for a ready script.

Testing

Once everything is set up, you should
make a test call to you account and use one of
the calling cards that you have set up.

To see the effect of your action, you
can take a look at the accounts les. The
media server will create subdirectories inside
the chosen account and put the calling card
information into these directories. The les
code.txt and balance.txt contain the PIN and
the remaining credit for this calling card.
You can easily retrieve this information for
statistics.

Creating Backups

The calling card database contains
important information that must not get lost
during a server failure (you don’t want to loose
the current balances on the calling cards). This
release of the media server does not include
automatic replication of stateful information in
the media server.

However, with some simple tricks you
can minimize the risk of loosing data. All you
need to have is a background process that
periodically copies the accounts directory into
a safe place. The period depends on the safely
level that you want to achieve. For example,
if you tolerate a maximum loss of 30 minutes
calling card history, this background process
must run every 30 minutes. In Linux, such a
background process could look like this:

while [ 1 ]; do
sleep 600
cp –rp accounts /home/backup/accounts
done

You may also use cron(8) to perform this

task for you.

You can estimate your risk using a
stochastic approach. If your telephone
termination costs are 100 USD per hour, you
replicate your le system every hour and
statistically the calls are evenly distributed, that
means that your failure damage expectation is
50 USD. However, this simple estimation does
now take lost business into account; therefore
you should make sure that your hardware is
suited for business.

snom technology Aktiengesellschaft

Pascalstr. 10B, 10587 Berlin, Germany

Phone: [phone]

mailto: [e-mail]

http: www.snom.com

sip: [e-mail]

© 2003 snom technology AG
All rights reserved.