NOTE: This patch was superseded by another one I’ve wrote that adds smsc-admin-id instead. The smsc-admin-id patch was already commited to CVS so the use of the smsc-dlr-alias is now officially deprecated.

A problem you may have faced with dlrs on Kannel: If you’re using dlrs and have more than one bind to a given carrier, you need to name them all the same. Otherwise, if the dlr come back over a different bind than the one you’ve used to send the MT message in the first place, Kannel won’t be able to match them, since they won’t share the same “smsc” field.

This is usually OK. However, you lose the ability to control the binds independently: you cannot shutdown a single bind, for example. The problem worsens yet more if your binds are to different data centers (some carriers have redundant SMSC’s on geographycally distant places).

That’s why I’ve created this patch that adds a new configuration option to SMSC groups:

smsc-dlr-alias

Using this parameter, you can define an alias to use when storing dlrs, so they will match despite being sent/received over different binds.

For example:

…

#carrier link 1

group                      = smsc

smsc                       = smpp

smsc-id                  = “link1″

smsc-dlr-alias     = “myalias”

allowed-smsc-id = “link1;mylink”

host                        = “1.1.1.1″

…

#carrier link 2

group                      = smsc

smsc                       = smpp

smsc-id                  = “link2″

smsc-dlr-alias     = “myalias”

allowed-smsc-id = “link2;mylink”

host                        = “1.1.1.1″

…

Using this configuration, you just have to use the “&smsc=mylink” parameter on your send-sms url. The dlr will be stored using the alias “myalias” no matter which of these 2 routes the message takes. When getting the response back, again, it will be matched against “myalias”.

Download the patch here.

Please try it and let me know what you think.

Regards,

Alex

This patch adds an alternative storage engine that uses mysql as backend, instead of a big file or a spool directory. This makes some interesting setups possible and also allows to ease the disk I/O on the server (by using an external MySQL engine).

To use it, you first need to create a MySQL database, and a table to hold the store messages. We’ll use “kannel” as DB Name and “store” as the table name, but you can choose whatever you want and modify the config file to reflect your setup (more on this later).

To create the “store” table, run the following SQL query:

CREATE TABLE store ( uuid VARCHAR(36) NOT NULL PRIMARY KEY, message TEXT );

Again, you can rename the fields and modify the config to reflect your environment.

Then, on kannel.conf, you need to add a store-db group, and a mysql-connection pool:

group = mysql-connection
id = mypool
host = localhost
username = <user>
password = <password>
database = kannel
max-connections = 1

group = store-db
id = mypool
table = store
field-uuid = uuid
field-message = message

Last but not least, set the store-type to use the mysql storage engine on the core group:

store-type = mysql

As you may have noticed, you can modify the fields table, field-uuid and field-message to suit your particular database schema.

Here’s the patch against latest CVS:

kannel-mysql-storage-engine

This needs further testing (do not use it for production -yet-), please try it and let me know if you find any problems.