Wap and Sms Gateway
Wap and Sms Gateway
1 User’s Guide
Open Source WAP and SMS gateway
Lars Wirzenius
Gateway architect
Wapit Ltd
[email protected]
http://www.wapit.com
http://www.kannel.org
Kalle Marjola
Manager
Wapit Ltd
[email protected]
http://www.wapit.com
http://www.kannel.org
Andreas Fink
Chairman & CTO
Global Networks Inc.
Bruno Rodrigues
[email protected]
http://litux.org/bruno
Stipe Tolj
CTO & CIO
Wapme Systems AG
[email protected]
http://www.wapme.de
http://www.kannel.org
Aarno Syvänen
Chief MMS Developer
Global Networks Inc.
[email protected]
http://www.gni.ch
Abstract
This document describes how to install and use Kannel, the Open Source WAP and SMS Gateway originally
developed by Wapit Ltd (now out of business) and now being developed further by the open source community,
namely the Kannel Group.
Revision History
Revision 1.3.1 2006.07.01
iv
vi
vii
With hundreds of millions of mobile phones in use all over the world, the market for services targeted at
mobile users is mind-bogglingly immense. Even simple services find plenty of users, as long as they’re
useful or fun. Being able to get news, send e-mail or just be entertained wherever you are is extremely
attractive to many.
The hottest technology for implementing mobile services is WAP, short for Wireless Application
Protocol. It lets the phone act as a simple web browser, but optimizes the markup language, scripting
language, and the transmission protocols for wireless use. The optimized protocols are translated to plain
old HTTP by a WAP gateway.
Kannel is an open source WAP gateway. It attempts to provide this essential part of the WAP
infrastructure freely to everyone so that the market potential for WAP services, both from wireless
operators and specialized service providers, will be realized as efficiently as possible.
Kannel also works as an SMS gateway for GSM networks. Almost all GSM phones can send and receive
SMS messages, so this is a way to serve many more clients than just those using a new WAP phone.
In addition, Kannel operates as Push Proxy Gateway , or PPG, making possible for content servers to
send data to the phones. This is a new type of WAP service, and have many interesting applications.
Usually servers know whether some data is new, not the users.
Open Source (http://www.opensource.org) is a way to formalize the principle of openness by placing the
source code of a product under a Open Source compliant software license. The BSD license was chosen
over other Open Source licenses by the merit of placing the least amount of limitations on what a third
party is able to do with the source code. In practice this means that Kannel is going to be a fully-featured
WAP implementation and compatible with the maximum number of bearers with special emphasis on
SMSC compatibility. The Kannel project was founded by Wapit Ltd in June, 1999.
Overview of WAP
WAP, short for Wireless Application Protocol, is a collection of various languages and tools and an
infrastructure for implementing services for mobile phones. Traditionally such services have worked via
normal phone calls or short textual messages (e.g., SMS messages in GSM networks). Neither are very
efficient to use, nor very user friendly. WAP makes it possible to implement services similar to the World
Wide Web.
Unlike marketers claim, WAP does not bring the existing content of the Internet directly to the phone.
There are too many technical and other problems for this to ever work properly. The main problem is that
Internet content is mainly in the form of HTML pages, and they are written in such way that they require
fast connections, fast processors, large memories, big screens, audio output and often also fairly efficient
input mechanisms. That’s OK, since they hopefully work better for traditional computers and networks
that way. However, portable phones have very slow processors, very little memory, abysmal and
intermittent bandwidth, and extremely awkward input mechanisms. Most existing HTML pages do not
work on mobiles phones, and never will.
WAP defines a completely new markup language, the Wireless Markup Language (WML), which is
simpler and much more strictly defined than HTML. It also defines a scripting language, WMLScript,
which all browsers are required to support. To make things even simpler for the phones, it even defines
its own bitmap format (Wireless Bitmap, or WBMP).
HTTP is also too inefficient for wireless use. However, by using a semantically similar binary and
compressed format it is possible to reduce the protocol overhead to a few bytes per request, instead of the
usual hundreds of bytes. Thus, WAP defines a new protocol stack to be used. However, to make things
simpler also for the people actually implementing the services, WAP introduces a gateway between the
phones and the servers providing content to the phones.
Figure 1-1. Logical position of WAP gateway (and PPG)between a phone and a content server.
The WAP gateway talks to the phone using the WAP protocol stack, and translates the requests it receives
to normal HTTP. Thus content providers can use any HTTP servers and utilize existing know-how about
HTTP service implementation and administration.
In addition to protocol translations, the gateway also compresses the WML pages into a more compact
form, to save on-the-air bandwidth and to further reduce the phone’s processing requirements. It also
compiles WMLScript programs into a bytecode format.
Kannel is not just a WAP gateway. It also works as an SMS gateway. Although WAP is the hot and
technically superior technology, SMS phones exist in huge numbers and SMS services are thus quite
useful. Therefore, Kannel functions simultaneously as both a WAP and an SMS gateway.
instance, when it must send a mail notification or a stock quote. For this purpose Wapforum defined
WAP Push.
Push is an application level service, sitting on the top of existing WAP stack. It defines two protocols,
OTA and PAP. OTA is a ligthweigth protocol speaking with WAP stack (to be more specific, with WSP),
PAP speaks with the push initiator. It defines three kind of XML documents, one for the push data itself
and another for protocol purposes (these are called pap document or push control documents).
The server does not simply send push content to the phone, the user would surely not accept, for
instance, interrupting of a voice call. Instead it sends a specific XML document, either Service Indication
or Service Loading. These inform the user about the content becomed available, and it is displayed only
when it is not interrupting anything. It contains an URL specifying the service and a text for user
describing the content. Then the user can decide does he accept push or not.
The push content is sended to the phones over SMS, but the content is fetched by the phone over IP
bearer, for instance CSD or GPRS. Because Push Proxy Gateway tokenises SI and SL documents, it may
fit one SMS message (if not, it is segmented for transfer).
Using two bearers seems to be an unnecessary complication. But quite simply, phones currently operate
this way. Push over GPRS can only simplify matters.
Overview of SMS
SMS, short messaging service, is a way to send short (160 character) messages from one GSM phone to
another. It can also be used to send operator logos, ringing tones, business cards and phone
configurations.
SMS services are content services initiated by SMS message to certain (usually short) phone number,
which then answers with requested content, if available.
When SMS services are used, the client (mobile terminal) sends an SMS message to certain number,
usually a very short specialized number, which points to specific SMS center responsible for that number
(plus possibly many others). This SMS center then sends the message onward to specified receiver in
intra- or Internet, using an SMS center specific protocol. For example, a Nokia SMS center uses CIMD
protocol.
As practically every different kind of SMS center uses different protocol, an SMS gateway is used to
handle connections with SMS centers and to relay them onward in an unified form.
Figure 1-2. Logical position of SMS gateway between a phone and a content server.
An SMS gateway can also be used to relay SMS messages from one GSM network to another, if the
networks do not roam messages normally.
Kannel works as an SMS gateway, talking with many different kind of SMS centers, and relaying the
messages onward to content providers, as HTTP queries. Content providers then answer to this HTTP
query and the answer is sent back to mobile terminal, with appropriate SMS center connection using
SMS center specific protocol.
In addition to serving mobile originated (MO) SMS messages Kannel also works as an SMS push
gateway - content providers can request Kannel to send SMS messages to terminals. Kannel then
determines the correct SMS center to relay the SMS message and sends the SMS message to that SMS
center, again using SMS center specific protocol. This way the content provider does not need to know
any SMS center specific protocol, just unified Kannel SMS sending interface.
Features
This section needs to be written.
Requirements
Kannel is being developed on Linux systems, and should be fairly easy to export to other Unix-like
systems. However, we don’t yet support other platforms, due to lack of time. Kannel requires the
following software environment:
• The Gnome XML library (known as gnome-xml and libxml), version 2.2.5 or newer. See
http://xmlsoft.org/xml.html.
• GNU Make.
• Posix threads (pthread.h).
• GNU Bison 1.28 if you modify the WMLScript compiler.
• DocBook markup language tools (jade, jadetex, DocBook stylesheets, etc; see README.docbook), if
you want to format the documentation (pre-formatted versions are available).
Hardware requirements are fluffier. We haven’t benchmarked Kannel yet, so there are no hard numbers,
but a reasonably fast PC workstation (400 MHz Pentium II, 128 MB RAM) should serve several
concurrent users or tens of SMS messages per second without problems.
• C compiler and libraries for ANSI C, with normal Unix extensions such as BSD sockets.
• An implementation of POSIX threads (pthread.h).
• GNU Bison 1.28, if you want to modify the WMLScript compiler (a pre-generated parser is included
for those who just want to compile Kannel).
• DocBook processing tools: DocBook stylesheets, jade, jadetex, etc; see README.docbook for more
information (pre-formatted versions of the documentation are available, and you can compile Kannel
itself even without the documentation tools).
./configure
make
The configure script investigates various things on your computer for the Kannel compilation needs,
and writes out the Makefile used to compile Kannel. make then runs the commands to actually
compile Kannel.
If either command writes out an error message and stops before it finishes its job, you have a problem,
and you either need to fix it yourself, if you can, or report the problem to the Kannel project. See Chapter
10 for details.
For detailed instruction on using the configuration script, see file INSTALL. That file is a generic
documentation for configure. Kannel defines a few additional options:
• --with-defaults=type Set defaults for the other options. type is either speed or debug. The
default is debug.
• --enable-docs (default) Build documentation, b.e., converting the User Guide and the
Architecture Guide from the DocBook markup language to PostScript and HTML.
• --disable-docs Don’t build documentation.
• --enable-drafts When building documentation, include the sections marked as draft.
• --disable-drafts (default) When building documentation, don’t include the sections marked
as draft.
• --enable-debug Enable non-reentrant development time debugging of WMLScript compiler.
• --enable-localtime Write log file time stamps in local time, not GMT.
• --disable-assertions Turn off runtime assertion checking. This makes Kannel faster, but gives
less information if it crashes.
• --with-malloc=type Select memory allocation module to use: type is native, checking (the
default), or slow. For production use you probably want native. The slow module is more thorough
than checking, but much slower.
• --enable-mutex-stats Produce information about lock contention.
• --enable-start-stop-daemon Compile the start-stop-daemon program.
• --enable-pam Enable using PAM for authentication of sendsms users for smsbox.
CFLAGS=’-pthread’ ./configure
The above, for instance, seems to be required on FreeBSD. If you want to develop Kannel, you probably
want to add CFLAGS that make your compiler use warning messages. For example, for GCC:
Replace /path/to/directory with the pathname of the actual directory where the programs should
be installed. The programs that are installed are (as filenames from the root of the source directory):
gw/bearerbox
gw/smsbox
gw/wapbox
The version number of the gateway is added to the file names during installation. This makes it easier to
have several versions installed, and makes it easy to go back to an older version if the new version proves
problematic.
Kannel consists of three programs called boxes: the bearer box is the interface towards the phones. It
accepts WAP and SMS messages from the phones and sends them to the other boxes. The SMS box
handles SMS gateway functionality, and the WAP box handles WAP gateway functionality. There can be
several SMS boxes and several WAP boxes running and they don’t have to run on the same host. This
makes it possible to handle much larger loads.
rpm -q libxml2
Installing Kannel
1. Download the binary RPM packet from the Kannel web site.
2. Log in as root:
su -
Upgrading Kannel
1. Download the binary RPM packet from the Kannel web site.
2. Log in as root
3. Upgrade the RPM package:
Removing Kannel
1. Log in as root:
2. Remove the RPM package:
rpm -e kannel
After you have installed Kannel from the RPM packages you x should now be able to run the Kannel
init.d script that will start Kannel as a WAP gateway. Run the script as root.
/etc/rc.d/init.d/kannel start
To stop the gateway just run the same script with the stop parameter.
/etc/rc.d/init.d/kannel stop
If Kannel is already running and you just want to quickly stop and start the gateway,e.g.to set a new
configuration option, run the script with the restart parameter.
/etc/rc.d/init.d/kannel restart
If you want Kannel to run as a daemon, you need to add a symbolic link to the Kannel script from the
runlevel you want Kannel to run in. E.g. to run Kannel in runlevel 5 add symbolic links to /etc/rc.d/rc5.d/.
cd /etc/rc.d/rc5.d/
ln -s ../init.d/kannel S91kannel
ln -s ../init.d/kannel K91kannel
To run Kannel as a SMS gateway you need to edit the configuration file which is at
/etc/kannel/kannel.conf. In the same directory there is an example file called smskannel.conf. It has some
basic examples of the configuration groups needed to run Kannel as a SMS gateway. For more detailed
information please read the section "SMS gateway configuration" later in this same document.
The logging is disabled by default and you can enable it from the kannel.conf file. Just add the log-file
option to the group of which box you want to log.
The documentation will be installed at /usr/share/doc/kannel-VERSION/ or /usr/doc/kannel-VERSION/
depending on if you used the RedHat 7.x or 6.x package.
In the Kannel documentation directory there is a html file called control.html. It is an example file that
shows how to use the Kannel http administration interface. It also has a template for sending SMS
messages.
dpkg -l libxml2
su -
su -
10
Removing Kannel
1. Log in as root:
2. Remove the package keeping configuration files:
After you have installed Kannel from the DEB packages you should now be able to run the Kannel init.d
script that will start Kannel as a WAP gateway. Run the script as root.
/etc/init.d/kannel start
To stop the gateway just run the same script with the stop parameter.
/etc/init.d/kannel stop
If Kannel is already running and you just want to quickly stop and start the gateway,e.g.to set a new
configuration option, run the script with the restart parameter.
/etc/init.d/kannel restart
If you want to restore Kannel runing as a daemon, you need to add a symbolic link to the Kannel script
from the runlevel you want Kannel to run in. E.g. to run Kannel in default runlevel, just run:
Kannel package starts by default with a wapbox daemon. To activate smsbox or select which box you
want to start, edit /etc/default/kannel and comment/uncomment START_xxxBOX.
To run Kannel as a SMS gateway you need to edit the configuration file which is at
/etc/kannel/kannel.conf. In /usr/share/docs/kannel/examples/ there are example files. They have some
basic examples of the configuration groups needed to run Kannel as a SMS gateway. For more detailed
information please read the section "SMS gateway configuration" later in this same document.
11
12
1 # A do-nothing service.
2 group = sms-service
3 keyword = nop
4 text = "You asked nothing and I did it!"
5
6 # Default service.
7 group = sms-service
8 keyword = default
9 text = "No services defined"
The above snippet defines the keyword nop for an SMS service, and a default action for situation when
the keyword in the SMS message does not match any defined service.
13
Lines 1 and 6 are comment lines. Line 5 separates the two groups. The remaining lines define variables.
The group type is defined by the group variable value.
The various variables that are understood in each type of configuration group are explained below.
Some variable values are marked as ’bool’. The value for variable can be like true, false, yes, no, on,
off, 0 or 1. Other values are treated as ’true’ while if the variable is not present at all, it is treated as being
’false’.
group = core
admin-port = 13000
wapbox-port = 13002
admin-password = bar
wdp-interface-name = "*"
log-file = "/var/log/bearerbox.log"
log-level = 1
box-deny-ip = "*.*.*.*"
box-allow-ip = "127.0.0.1"
include = "wapbox.conf"
include = "configurations"
Above is the main kannel.conf configuration file that includes the following wapbox.conf file with
all required directives for the specific box, and a configurations directory which may include more
files to include.
group = wapbox
bearerbox-host = localhost
log-file = "/var/log/wapbox.log"
log-level = 0
syslog-level = none
The above include statement may be defined at any point in the configuration file and at any inclusion
depth. Hence you can cascade numerous inclusions if necessary.
At process start time inclusion of configuration files breaks if either the included file can not be opened
and processed or the included file has been processed already in the stack and a recursive cycling has
been detected.
14
Core configuration
Configuration for Kannel MUST always include a group for general bearerbox configuration. This group
is named as ’core’ in configuration file, and should be the first group in the configuration file.
As its simplest form, ’core’ group looks like this:
group = core
admin-port = 13000
admin-password = f00bar
Naturally this is not sufficient for any real use, as you want to use Kannel as an SMS gateway, or WAP
gateway, or both. Thus, one or more of the optional configuration variables are used. In following list (as
in any other similar lists), all mandatory variables are marked with (m), while conditionally mandatory
(variables which must be set in certain cases) are marked with (c).
15
16
17
18
19
group = core
admin-port = 13000
admin-password = f00bar
status-password = sTat
admin-deny-ip = "*.*.*.*"
admin-allow-ip = "127.0.0.1;200.100.0.*"
smsbox-port = 13003
wapbox-port = 13004
box-deny-ip = "*.*.*.*"
box-allow-ip = "127.0.0.1;200.100.0.*"
wdp-interface-name = "*"
log-file = "kannel.log"
log-level = 1
access-log = "kannel.access"
unified-prefix = "+358,00358,0;+,00"
white-list = "http://localhost/whitelist.txt"
20
Running Kannel
To start the gateway, you need to start each box you need. You always need the bearer box, and
depending on whether you want WAP and SMS gateways you need to start the WAP and SMS boxes. If
you want, you can run several of them, but we’ll explain the simple case of only running one each.
./bearerbox -v 1 [conffile]
The -v 1 sets the logging level to INFO. This way, you won’t see a large amount of debugging output
(the default is DEBUG). Full explanation of Kannel command line arguments is below.
[conffile] is the name of the configuration file you are using with Kannel. The basic distribution packet
comes with two sample configuration files, smskannel.conf and wapkannel.conf (in gw
subdirectory), of which the first one is for testing out SMS Kannel and the second one for setting up a
WAP Kannel. Feel free to edit those configuration files to set up your own specialized system.
After the bearer box, you can start the WAP box:
./wapbox -v 1 [conffile]
./smsbox -v 1 [conffile]
or both, of course. The order does not matter, except that you need to start the bearer box before the other
boxes. Without the bearer box, the other boxes won’t even start.
21
--verbosity <level>
Kannel statuses
In Kannel, there are four states for the program (which currently directly only apply to bearerbox):
a. Running. The gateway accepts, proceeds and relies messages normally. This is the default state for
the bearerbox.
b. Suspended. The gateway does not accept any new messages from SMS centers nor from UDP ports.
Neither does it accept new sms and wapbox connections nor sends any messages already in the
system onward.
c. Isolated. In this state, the gateway does not accept any messages from external message providers,
which means SMS Centers and UDP ports. It still processes any messages in the system and can
accept new messages from sendsms interface in smsbox.
d. Full. Gateway does not accept any messages from SMS centers, because maximum-queue-length
is achieved.
e. Shutdown. When the gateway is brought down, it does not accept any new messages from SMS
centers and UDP ports, but processes all systems already in the system. As soon as any queues are
emptied, the system exits
22
The state can be changed via HTTP administration interface (see below), and shutdown can also be
initiated via TERM or INT signal from terminal. In addition, the bearerbox can be started already in
suspended or isolated state with -S or -I command line option, see above.
HTTP administration
Kannel can be controlled via an HTTP administration interface. All commands are done as normal HTTP
queries, so they can be easily done from command line like this:
...in which the ’12345’ is the configured admin-port in Kannel configuration file (see above). For most
commands, admin-password is required as a argument as shown above. In addition, HTTP administration
can be denied from certain IP addresses, as explained in configuration chapter.
Note that you can use these commands with WAP terminal, too, but if you use it through the same
Kannel, replies to various suspend commands never arrive nor can you restart it via WAP anymore.
23
24
Wapbox configuration
If you have set wapbox-port variable in the ’core’ configuration group, you MUST supply a ’wapbox’
group.
The simplest working ’wapbox’ group looks like this:
group = wapbox
bearerbox-host = localhost
There is, however, multiple optional variables for the ’wapbox’ group.
25
26
27
Required components
To set up an SMS gateway, you need, in addition to a machine running Kannel, access to (an operator’s)
SMS center, or possibly to multiple ones. The list of supported SMS centers and their configuration
variables is below.
If you do not have such access, you can still use Kannel as an SMS gateway via phone-as-SMSC feature,
by using a GSM phone as a virtual SMS center.
In addition to an SMS center (real or virtual), you need some server to handle any SMS requests
received. This server then has simple or more complex cgi-bins, programs or scripts to serve HTTP
requests generated by Kannel in response to received SMS messages. These services can also initiate
SMS push via Kannel smsbox HTTP sendsms interface.
SMS centers
To set up the SMS center at Kannel, you have to add a ’smsc’ group into configuration file. This group
must include all the data needed to connect that SMS center. You may also want to define an ID
(identification) name for the SMSC, for logging and routing purposes.
SMSC ID is an abstract name for the connection. It can be anything you like, but you should avoid any
special characters. You do not need to use ID, but rely on SMS center IP address and other information.
However, if you use the ID, you do not need to re-define sms-services nor routing systems if the IP of the
SMS Center is changed, for example.
Common ’smsc’ group variables are defined in the following table. The first two (group and smsc) are
mandatory, but rest can be used if needed.
28
29
30
In addition to these common variables there are several variables used by certain SMS center
connections. Each currently supported SMS center type is explained below, with configuration group for
each. Note that many of them use variables with same name, but most also have some specific variables.
NOTE: SMS center configuration variables are a bit incomplete, and will be updated as soon as people
responsible for the protocols are contacted. Meanwhile, please have patience.
31
group = smsc
smsc = cimd
host = 100.101.102.103
port = 600
smsc-username = foo
smsc-password = bar
The driver for CIMD2 is a "receiving SME" and expects the SMSC to be configured for that. It also
expects the SMSC to automatically send stored messages as soon as Kannel logs in (this is the normal
configuration).
group = smsc
smsc = cimd2
host = 100.101.102.103
port = 600
smsc-username = foo
smsc-password = bar
keepalive = 5
sender-prefix = "12345"
32
group = smsc
smsc = emi2
#smsc = emi_ip to use the old implementation
host = 103.102.101.100
port = 600
smsc-username = foo
smsc-password = bar
keepalive = 55
our-port = 600 (optional bind in our end)
receive-port = 700 (the port in which the SMSC will contact)
idle-timeout = 30
group = smsc
smsc = emi
host = 100.102.100.102
phone = ...
device = /dev/tty0
smsc-username = foo
smsc-password = bar
33
34
35
36
SMPP 3.4
This implements Short Message Peer to Peer (SMPP) Protocol 3.4 in a manner that should also be
compatible with 3.3. Sample configuration:
group = smsc
smsc = smpp
host = 123.123.123.123
port = 600
receive-port = 700
smsc-username = "STT"
smsc-password = foo
system-type = "VMA"
address-range = ""
37
38
39
40
41
you find out the more exact meaning, please send a report.
The 5.0 implementation uses X.25 access gateway.
group = smsc
smsc = sema
device = /dev/tty0
smsc_nua = (X121 smsc address)
home_nua = (x121 radio pad address)
wait_report = 0/1 (0 means false, 1 means true)
group = smsc
smsc = ois
host = 103.102.101.100
port = 10000
receive-port = 10000
ois-debug-level = 0
group = smsc
smsc = smasi
host = 10.11.12.13
port = 23456
42
smsc-username = foo
smsc-password = foo
GSM modem
Kannel can use a GSM modem as an SMS center.
group = smsc
smsc = at
modemtype = wavecom
device = /dev/ttyS0
43
pin = 2345
44
GSM modem 2
This new driver is replacing the old GSM Modem driver from Kannel. It allows a GSM Modem or Phone
to be connected to Kannel and work as a virtual SMSC
group = smsc
smsc = at2
modemtype = auto
device = /dev/ttyS0
speed = 9600
pin = 2345
45
46
Modem definitions are now multiple groups present in kannel.conf, either directly or, for example, by
including the example modems.conf. (See Inclusion of configuration files)
47
A note about delivery reports and GSM modems: while it is possible (and supported) to receive delivery
reports on GSM modems, it may not work for you. if you encounter problems, check that your modem’s
init string (if not the default) is set to correctly allow the modem to send delivery reports using unsolicted
notification (check your modem’s manual). If the init-string is not set as si, some modems will store
delivery reports to SIM memory, to get at which you will need to enable sim-buffering. finally your GSM
network provider may not support delivery reports to mobile units.
Fake SMSC
Fake SMSC is a simple protocol to test out Kannel. It is not a real SMS center, and cannot be used to
send or receive SMS messages from real phones. So, it is ONLY used for testing purposes.
48
group = smsc
smsc = fake
port = 10000
connect-allow-ip = 127.0.0.1
group = smsc
smsc = http
system-type = kannel
smsc-username = nork
smsc-password = z0rK
port = 13015
send-url = "http://localhost:20022"
49
Feature checklist
Not all of Kannel’s SMSC drivers support the same set of features. This is because they were written at
different times, and new features are often only added to drivers that the feature author can test.
The table in this section is an attempt to show exactly what features to expect from a driver, and to help
identify areas where drivers need to be updated. Currently most of the entries are marked as "not tested"
because the table is still new.
50
n n n n y n n n n y n n
Can set Validity
? ? ? ? y ? ? ? ? y ? ?
Can set Deferred
? ? ? ? y ? ? ? ? n ? ?
Can set PID
n n n n y y n n n y n n
Can set RPI
n n n n y y n n n n n n
Can send Unicode
? ? ? ? y ? ? ? ? y ? ?
Can send 8 bits
? ? ? ? y ? ? ? ? y ? ?
Correctly send GSM alphabet
? ? ? ? y ? ? ? ? ? ? ?
Notes:
a. To use mclass, mwi, coding and compress fields.
51
Symbol Meaning
? not yet investigated
y driver has this feature, and it has been tested
y? driver probably has this feature, has not been
tested
n driver does not have this feature
N driver claims to have this feature but it doesn’t
work
- feature is not applicable for this driver
Smsbox configuration
You must define an ’smsbox’ group into the configuration file to be able to use SMS Kannel. The
simplest working ’smsbox’ group looks like this:
group = smsbox
bearerbox-host = localhost
...but you would most probably want to define ’sendsms-port’ to be able to use SMS push.
52
smsbox-port
http-proxy-port
http-proxy-host
http-proxy-username
http-proxy-password
http-proxy-exceptions
ssl-certkey-file
53
54
group = smsbox
bearerbox-host = localhost
sendsms-port = 13131
sendsms-chars = "0123456789 "
global-sender = 123456
access-log = "kannel.access"
log-file = "smsbox.log"
55
log-level = 0
group = smsbox
...
smsbox-id = mysmsc
...
group = smsbox-route
smsbox-id = mysmsc
shortcuts = "1111;2222;3333"
which means and inbound message with receiver number 1111, 2222 or 3333 will be delivered to the
smsbox instance that has identified itself via the id "mysmsc" to bearerbox. Using this routing the
smsbox instance (which may be an EMI/UCP or SMPP proxy) is able to send a deliver_sm PDU
smsbox-route inherits from core the following fields:
56
SMS-service configurations
Now that you have an SMS center connection to send and receive SMS messages you need to define
services for incoming messages. This is done via ’sms-service’ configuration groups.
These groups define SMS services in the smsbox, so they are only used by the smsbox. Each service is
recognized from the first word in an SMS message and by the number of arguments accepted by the
service configuration (unless catch-all configuration variable is used). By adding a username and
password in the URL in the following manner "http://luser:[email protected]:port/path?query" we
can perform HTTP Basic authentication.
The simplest service group looks like this:
group = sms-service
keyword = www
get-url = "http://%S"
This service grabs any SMS with two words and ’www’ as the first word, and then does an HTTP request
to an URL which is taken from the rest of the message. Any result is sent back to the phone (or
requester), but is truncated to the 160 characters that will fit into an SMS message, naturally.
Service group default has a special meaning: if the incoming message is not routed to any other
service, default ’sms-service’ group is used. You should always define default service.
Service group black-list has a special meaning: if the incoming message is in service’s black-list, this
service is used to reply to user. If unset, message will be discarded.
57
58
59
60
61
62
group = sms-service
keyword = nop
text = "You asked nothing and I did it!"
catch-all = true
group = sms-service
keyword = complex
get-url = "http://host/service?sender=%p&text=%r"
accept-x-kannel-headers = true
max-messages = 3
concatenation = true
group = sms-service
keyword = default
text = "No action specified"
63
Extended headers
Kannel uses and accepts several X-Kannel headers to be used with SMS-services.
64
Kannel POST
Kannel can do POST if service is contains a post-url="...".
XML Post
Kannel can send and receive XML POST with the following format:
<?xml version="1.0"?>
<!DOCTYPE ...>
<message>
<submit>
<da><number>destination number (to)</number></da>
<oa><number>originating number (from)</number></oa>
<ud>user data (text)</text>
<udh>user data header (udh)</udh>
<dcs>
<mclass>mclass</mclass>
<coding>coding</coding>
<mwi>mwi</mwi>
<compress>compress</compress>
65
<alt-dcs>alt-dcs</alt-dcs>
</dcs>
<pid>pid</pid>
<statusrequest>
<dlr-mask>dlr-mask</dlr-mask>
<dlr-url>dlr-url</dlr-url>
</statusrequest>
<from>
<user>username</user>
<username>username</username>
<pass>password</pass>
<password>password</password>
<account>account</account>
</from>
<to>smsc-id</to>
<from>smsc-id</from>
<to>service-name</to>
</submit>
</message>
There could be several da entries for sendsms-user to enable multi-recipient messages. da doesn’t
make sence in sms-service.
ud
Note: Davi: I still have to test binary and unicode <ud> content
Warning
This is experimental code. XML format could and should change to fully met
IETF’s sms-xml standard (yet in draft) and additional tags needed by kannel
should be pondered.
66
SendSMS-user configurations
To enable an SMS push, you must set sendsms-port into the ’smsbox’ group and define one or more
’sendsms-user’ groups. Each of these groups define one account, which can be used for the SMS push,
via HTTP interface (see below)
67
group = sendsms-user
username = simple
password = elpmis
group = sendsms-user
username = complex
password = 76ftY
user-deny-ip = "*.*.*.*"
user-allow-ip = "123.234.123.234"
max-messages = 3
concatenation = true
forced-smsc = SOL
The second one is very limited and only allows a user from IP "123.234.123.234". On the other hand, the
user can send a longer message, up to 3 SMSes long, which is sent as concatenated SMS.
68
group = mysql-connection
id = mydlr
host = localhost
mysql-username = foo
mysql-password = bar
database = dlr
group = dlr-db
id = mydlr
table = dlr
field-smsc = smsc
field-timestamp = ts
field-destination = destination
field-service = service
field-url = url
field-mask = mask
field-status = status
field-boxc-id = boxc
69
In addition to that you must have a dlr-db group defined that specifies the table field names that are
used to the DLR attributes and a sdb-connection group that defines the LibSDB ressource itself.
Here is the example configuration from doc/examples/dlr-sdb.conf using a MySQL ressource:
group = sdb-connection
id = mydlr
url = "mysql:host=localhost:db=dlr:uid=foo:pwd=bar"
group = dlr-db
id = mydlr
table = dlr
field-smsc = smsc
field-timestamp = ts
field-destination = destination
field-service = service
field-url = url
field-mask = mask
field-status = status
field-boxc-id = boxc
Beware that you have the DB support build in your LibSDB installation when trying to use a specific DB
type within the URL.
70
group = dlr-db
id = dlr-db
table = dlr
field-smsc = smsc
field-timestamp = ts
field-destination = destination
field-service = service
field-url = url
field-mask = mask
field-status = status
Beware that all variables in this group are mandatory, so you have to specify all fields to enable
bearerbox to know how to store and retrieve the DLR information from the external storage spaces.
71
group = mysql-connection
id = dlr-db
host = localhost
mysql-username = foo
mysql-password = bar
database = dlr
In case you use different MySQL connections for several storage issues, i.e. one for DLR and another
different one for sms-service you may use the include configuration statement to extract the MySQL
related configuration groups to a seperate mysql.conf file.
Over-The-Air configurations
To enable Over-The-Air configuration of phones or other client devices that support the protocol you
need to configure a sendsms-user.ota-setting group is not necessary, you can send settings to the
72
phone as a XML document, but this method is perhaps more suitable for continous provisioning.
If you want to send multiple OTA configurations through the smsbox and you do not want to send XML
documents, you will have to declare a ota-id string to the different ota-setting groups.
group = ota-setting
location = http://wap.company.com
service = "Our company’s WAP site"
ipaddress = 10.11.12.13
73
phonenumber = 013456789
bearer = data
calltype = analog
connection = cont
pppsecurity = off
authentication = normal
login = wapusr
secret = thepasswd
group = sendsms-user
username = otauser
password = foo
max-messages = 2
concatenation = 1
group = ota-bookmark
ota-id = wap-link
url = "http://wap.company.com"
service = "Our company’s WAP site"
And a ’sendsms-user’ to use with it, with the same conditions as for the ’ota-setting’ group.
74
Redirected replies
The basic service system always sends the answer back to original requester, but sometimes the content
server needs to send something to other terminals or delay the answer. To create such systems, an SMS
push is used.
The idea is to get the initial request, but then send no reply. Instead, the reply (if any) is sent via HTTP
sendsms-interface as SMS Push. This way the service application has full control of the return content,
and can do all needed formatting beforehand.
Note that when no reply is wanted, remember to set the variable max-messages to zero (0) so that no
reply is sent, unless an error occurs. Simple sample:
group = sms-service
keyword = talk
get-url = "http://my.applet.machine/Servlet/talk?sender=%p&text=%r"
max-messages = 0
group = sms-service
keyword = weather
accepted-smsc = SOL
get-url = "http://my.applet.machine/Servlet/weather?sender=%p&operator=SOL&text=%r"
group = smsc
smsc-id = A
denied-smsc-id = B
...
group = smsc
smsc-id = B
denied-smsc-id = A
...
group = sms-service
accepted-smsc = A
get-url = "..."
group = sms-service
75
accepted-smsc = B
get-url = "..."
As can be seen, the smsc-id is used to identify the SMS center from which the message came. Then, the
denied-smsc-id variable is used to prevent messages originally from the other SMS center from being
sent through the other one. Finally ’sms-service’ groups are defined with accepted-smsc so that they
only accept messages from certain SMS center.
If you want to use SMS push services, requesters should then set the smsc request parameter, or
’sendsms-user’ groups should be defined like this:
group = sendsms-user
username = operator_A
password = foo
forced-smsc = A
group = sendsms-user
username = operator_B
password = bar
forced-smsc = B
Note that if your SMS centers do not set the sender phone number but rely on number transmitted, you
should set faked-sender to all ’sendsms-user’ groups.
http://smsbox.host.name:13013/cgi-bin/sendsms?
username=foo&password=bar&to=0123456&text=Hello+world
Thus, technically, you make an HTTP GET request. This means that all the information is stuffed into
the URL. If you want to use this often via a browser, you probably want to make an HTML form for this.
76
77
78
79
http://smsbox.host.name:13013/cgi-bin/sendota?
otaid=myconfig&username=foo&password=bar&to=0123456
URL containing XML document looks like this (you must URL encode it before sending it over HTTP):
http://smsbox.host.name:13013/cgi-bin/sendota?
username=foo&password=bar&to=0123456&
text=MyURLEncodedXMLdocument&type=settings
80
You can send either settings or bookmark, set CGI variable type accordingly. Default for this variable is
settings.
Here is an example XML document (this one contains CSD settings for logging in to a mobile service;
note that you must store DTD locally):
<?xml version="1.0"?>
<!DOCTYPE CHARACTERISTIC-LIST SYSTEM "file://gw/settings.dtd">
<CHARACTERISTIC-LIST>
<CHARACTERISTIC TYPE="ADDRESS">
<PARM NAME="BEARER" VALUE="GSM/CSD"/>
<PARM NAME="PROXY" VALUE="10.11.12.13"/>
<PARM NAME="PORT" VALUE="9201"/>
<PARM NAME="CSD_DIALSTRING" VALUE="+12345678"/>
<PARM NAME="PPP_AUTHTYPE" VALUE="PAP"/>
<PARM NAME="PPP_AUTHNAME" VALUE="yourusername"/>
<PARM NAME="PPP_AUTHSECRET" VALUE="yourauthsecret"/>
<PARM NAME="CSD_CALLTYPE" VALUE="ISDN"/>
<PARM NAME="CSD_CALLSPEED" VALUE="9600"/>
</CHARACTERISTIC>
<CHARACTERISTIC TYPE="URL"
VALUE="http://wap.company.com/"/>
<CHARACTERISTIC TYPE="NAME">
<PARM NAME="NAME" VALUE="Your WAP Company"/>
</CHARACTERISTIC>
</CHARACTERISTIC-LIST>
<?xml version="1.0"?>
<!DOCTYPE CHARACTERISTIC_LIST SYSTEM "file://gw/settings.dtd">
<CHARACTERISTIC-LIST>
<CHARACTERISTIC TYPE="BOOKMARK">
<PARM NAME="NAME" VALUE="WAP Company"/>
<PARM NAME="URL" VALUE="http://wap.company.com/"/>
</CHARACTERISTIC>
</CHARACTERISTIC-LIST>
Document type definition (DTD) for these documents is not available , from Internet, you must supply it
as a file. Kannel gw directory contains an example, settings.dtd.
81
82
83
group = ppg
ppg-url = /wappush
ppg-port = 8080
concurrent-pushes = 100
users = 1024
ppg-allow-ip = 194.100.32.125;127.0.0.1
ppg-deny-ip = 194.100.32.89;194.100.32.103
trusted-pi = false
84
85
group = wap-push-user
wap-push-user = picom
ppg-username = foo
ppg-password = bar
allow-ip = 62.254.217.163
It goes without saying that in real systems you must use more complex passwords than bar.
86
group = core
admin-port = 13000
smsbox-port = 13001
wapbox-port = 13002
admin-password = b
wdp-interface-name = "*"
log-file = "filename"
log-level = 1
box-deny-ip = "*.*.*.*"
box-allow-ip = "127.0.0.1"
unified-prefix = "00358,0"
You mut set up wapbox, for pulling (fetching) the wap data, and of course starting the push itself. No
new variables here, either.
group = wapbox
bearerbox-host = localhost
log-file = "filename"
log-level = 0
syslog-level = none
To set up smsc connections, for pushing SI or SL over SMS. Here HTTP SMSC is used as an example.
Variables no-sender and no-coding simplify HTTP request generated by Kannel. Send-url specifies
content gateway, or sendsms service.
group = smsc
87
smsc = http
smsc-id = HTTP
port = 10000
system-type = kannel
smsc-username = foo
smsc-password = bar
no-sender = true
no-coding = true
send-url = http://host:port/path
To set up smsbox. This group will eventually disappear, use here only necessary configuration variables.
group = smsbox
bearerbox-host = localhost
gw/bearerbox [conffile]
gw/wapbox [conffile]
http://matrix:8080/phplib/kannelgw.php?user=*deleted*&
pass=*deleted*=to=%2B358408676001&text=3D%02%06%17%AE%96localhost
%3A8080%00%AF%80%8D%CF%B4%80%02%05j%00E%C6%0C%03wap.iobox.fi%00%11%03
1%40wiral.com%00%07%0A%C3%07%19%99%06%25%15%23%15%10%C3%04+%02%060%01
%03Want+to+test+a+fetch%3F%00%01%01&udh=%06%05%04%0B%84%23%F0
88
<?xml version="1.0"?>
<!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP//EN"
"http://www.wapforum.org/DTD/pap_1.0.dtd">
<pap>
<push-message push-id="[email protected]">
<address address-value="WAPPUSH=+358408676001/[email protected]"/>
</push-message>
</pap>
89
1. as HTTP client, i.e. for requesting URLs while acting as WAP gateway and while fetching
information for the SMS services.
2. as HTTP server, i.e. for the administration HTTP interface, the PPG and for the sendsms HTTP
interface.
That is why you can specify seperate certification files within the core group to be used for the HTTP
sides.
You can use one or both sides of the SSL support. There is no mandatory to use both if only one is
desired.
group = core
...
ssl-client-certkey-file = "filename"
Now you are able to use https:// scheme URLs within your WML decks and SMS services.
group = core
...
admin-port-ssl = true
...
ssl-server-cert-file = "filename"
ssl-server-key-file = "filenane"
90
group = core
...
ssl-server-cert-file = "filename"
ssl-server-key-file = "filenane"
group = smsbox
...
sendsms-port-ssl = true
group = ppg
...
ppg-ssl-port = 8090
ssl-server-cert-file = "/home/aarno/kannelcvs/gateway/gw/cert1.pem"
ssl-server-key-file = "/home/aarno/kannelcvs/gateway/gw/key1.pem"
PPG uses a separate port for HTTPS traffic, so so you must define it. This means that you can use both
HTTP and HTTPS, when needed.
91
• Message gets rejected by the SMSC (unknown subscriber, invalid destination number etc).
• Message gets accepted by the SMSC but the phone rejects the message.
• Message gets accepted by the SMSC but the phone is off or out of reach. The message gets buffered.
• Message gets successfully delivered.
When you deliver SMS to Kannel you have to indicate what kind of delivery report messages you would
like to receive back from the system. The delivery report types currrently implemented are:
• 1: delivery success
• 2: delivery failure
• 4: message buffered
• 8: smsc submit
• 16: smsc reject
If you want multiple report types, you simply add the values togeter. For example if you want to get
delivery success and/or failure you set the dlrmask value to 1+2. and so on. If you specify dlrmask on the
URL you pass on to kannel you also need to specify dlrurl. dlrurlshould contain the URL to which kannel
should place a HTTP requests once the delivery report is ready to be delivered back to your system.
An example transaction would work as following.
92
93
94
Setting up fakesmsc
This section sums up needed steps to set up system for fakesmsc use.
Compiling fakesmsc
The fake SMS center should compile at the same time as main Kannel compiles. The outcoming binary,
fakesmsc, is in test directory. The source code is quite simple and trivial, and is easily edited.
Configuring Kannel
To use fakesmsc to test out Kannel, you have to add it to main configuration file (see above). The
simplest form for this configuration group is like this:
group = smsc
smsc = fake
port = 10000
The fakesmsc configuration group accepts all common ’smsc’ configuration group variables, like
smsc-id, preferred-smsc-id or denied-smsc-id, which can be used to test out routing systems
and diverted services, before setting up real SMS center connections. If you include a fakesmsc group
when bearerbox is connected to real SMS centers, you should add the connect-allow-ip variable to
prevent unauthorized use.
To set up multiple fakesmsc’es, just add new groups. Remember to put a different port number to each
one.
95
Options and messages are explained below, but as a quick example, a typical startup can go like this:
test/fakesmsc -i 0.1 -m 100 "100 200 text nop" "100 300 text echo this"
This tells fakesmsc to connect to bearerbox at localhost:10000 (default) and send a hundred messages
with an interval of 0.1 seconds. Each message is from number 100, and is either to number 200 with
message ’nop’ or to 300 with message ’echo this’.
Messages received from bearerbox are shown in the same format (described below).
Fake messages
Each message consists of four or five parts: sender number, receiver number, type, udh (if present) and
main message itself. Sender and receiver numbers do not mean anything except for log files and
number-based routing in Kannel.
The parts of a message are separated with spaces. As each message is taken as one argument, it must be
put in quotation marks.
Message type must be one of the following: "text", "data" and "udh". Here’s an example of using each:
For "text", the rest of the argument is taken as the literal message. For "data", the next part must be the
urlcoded version of the message. Space is coded as ’+’. For "udh", the next 2 parts are the UDH and
main message. Both must be in urlcoded form.
If multiple messages are given, fakesmsc randomly chooses one for each sending.
96
In addition, fakesmsc accepts all common Kannel Command line options like --verbosity.
97
<?xml version="1.0"?>
<!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP//EN"
"http://www.wapforum.org/DTD/pap_1.0.dtd">
<pap>
<push-message push-id="[email protected]"
deliver-before-timestamp="2001-09-28T06:45:00Z"
deliver-after-timestamp="2001-02-28T06:45:00Z"
progress-notes-requested="false">
<address address-value="WAPPUSH=+358408676001/[email protected]"/>
<quality-of-service priority="low"
delivery-method="unconfirmed"
network-required="true"
network="GSM"
bearer-required="true"
bearer="SMS"/>
</push-message>
</pap>
Because the push content is sended to the phone over SMS, rigth value for network-required and
bearer-required is true, for network GSM and for bearer SMS. However, you can omit these
values alltogether, if you use a phone number as an address. Address value is international phone number
and it must start with plus. It is used here as an unique identifier, SMSC, or sendsms script must
transform it to an usable phone number.
Here is an example of Service Indication, a type of push content. Essentially, the phone displays, when it
receives this SI, the text "Want to test a fetch" and if the user wants, fetches the content located by URL
http://wap.iobox.fi.
<?xml version="1.0"?>
<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"
"http://www.wapforum.org/DTD/si.dtd">
<si>
<indication href="http://wap.iobox.fi"
si-id="[email protected]"
action="signal-high"
created="1999-06-25T15:23:15Z"
98
si-expires="2002-06-30T00:00:00Z">
Want to test a fetch?
</indication>
</si>
Note that the date value of the si-expires attribute contains trailing zeroes. They are OK here, because SI
tokenizer removes them. But phones does not accept them in the final SMS data message. You should
probably use action="signal-high" for testing purposes, for it causes an immediate presentation of
the push message. Production usage is a quite another matter.
Another example of push content is Service Loading. In principle, the phone should fetch immediately
content from URL http://wap.iobox.fi when it receives this document. This sounds quite
unsecure, and indeed, user invention is probably required before fetching.
<?xml version="1.0"?>
<!DOCTYPE sl PUBLIC "-//WAPFORUM//DTD SL 1.0//EN"
"http://www.wapforum.org/DTD/sl.dtd">
<sl href="http://wap.iobox.fi"
action="execute-high">
</sl>
gw/bearerbox [conffile]
gw/wapbox [conffile]
Of course you can use more complicated wapbox and bearerbox command line options, if necessary.
To run a http smsc, start http server simulation:
test/test_http_server -p port
You can, of course, select the port at will. Remember, though, that PPG listens at the port defined in the
ppg configuration file. Other test_http_server options are irrelevant here.
Lastly, start making push requests, for instance with a test program test_ppg. Its first argument is a
URL specifying location of push services. Other arguments are two file names, first one push content and
99
second one pap control document. (For command line options, see Table C.1.). For example doing one
push(you can simplify push url by setting a ppg configuration variable, see "Setting up push proxy
gateway"; q flag here prevents dumping of test_ppg program debugging information):
test/test_ppg -q http://ppg-host-name:ppg-port?username=ppg-username’&’
password=ppg-password [content_file] [control_file]
100
<?xml version="1.0"?>
<!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP//EN"
"http://www.wapforum.org/DTD/pap_1.0.dtd">
<pap>
<push-message push-id="[email protected]"
deliver-before-timestamp="2001-09-28T06:45:00Z"
deliver-after-timestamp="2001-02-28T06:45:00Z"
progress-notes-requested="false">
<address address-value="WAPPUSH=192.168.214.1/[email protected]"/>
<quality-of-service priority="low"
delivery-method="unconfirmed"
</quality-of-service>
</push-message>
</pap>
Note address-value format. It is contains type and value, because PAP protocol supports different address
formats.
You must use test_ppg’s -a and -c flags when pushing messages to Toolkit. -A defines the client
application handling pushes, right value for it is ua. -C defines the content type of your push message. SI
works with all Toolkits, wml only with some older versions.
101
group = test-ppg
retries = 2
pi-ssl = yes
ssl-client-certkey-file = /home/aarno/kannelcvs/gateway/gw/certkey.pem
group = configuration
push-url = https://localhost:8900/wappush
pap-file = /home/aarno/test/ipnoqos.txt
content-file = /home/aarno/test/si.txt
username = foo
password = bar
test/test_ppg -q [configuration_file]
102
103
Analog modem
This section explains how to set up a dial-up line with an analog modem.
Download and install the mgetty package.
We need to start the pppd automatically when mgetty receives an AutoPPP request. Add the next line to
/etc/mgetty+sendfax/login.config
In /etc/mgetty+sendfax/mgetty.config you might need to change the connect speed between the computer
and the modem. Note: this is not the connect speed between the WAP client and the server modem. If
you are e.g. going to use a Nokia 7110 as the server side modem you need to change the speed to 19200.
Usually you can just leave the speed to the default value (38400).
speed 38400
refuse-chap
require-pap
lock
modem
crtscts
passive
192.168.1.10:192.168.1.20
debug
104
In /etc/ppp/pap-secrets add the username and password for the ppp account. The IP address is the one
assigned to the phone.
homepage http:/yourhost/hello.wml
connection type continuous
connection security off
bearer data
dial up number (your phone number)
ip address (IP of host running bearerbox)
auth type normal
data call type analogue
data call speed 9600
username wapuser
password wappswd
ISDN terminal
This section needs to be written
105
Log rotation
If Kannel is configured so that the bearerbox, wapbox and/or smsbox log to file each of these log files
will continue to grow unless administered in some way (this is especially true if access logs are created
and/or the log level is set to debug).
A typical way of administering log files is to ’rotate’ the logs on a regular basis using a tool such as
logrotate. A sample logrotate script (to be added to /etc/logrotate.d) is shown below. In this example the
Kannel log files found in /var/log/kannel are rotated and compressed daily over 365 days. See the
documentation for logrotate for more details. Of particular note however is the postrotate command, this
killall -HUP issues a HUP command to each kannel box running. The HUP signal has the effect of
reopening the log file, without this command Kannel will continue to write to the rotated log file.
/var/log/kannel/*.log {
106
daily
missingok
rotate 365
compress
delaycompress
notifempty
create 640 kannel adm
sharedscripts
postrotate
killall -HUP bearerbox smsbox wapbox || true > /dev/null 2> /dev/null
endscript
}
107
M
MO
MT
MWI
MClass
Coding
108
109