This patch adds separate dlr counters on the status page.

If you use dlrs (Delivery Receipts) with Kannel, you’ve noticed that they’re counted along with MO traffic as incoming messages.

This leads to misunderstandings on how much incoming traffic you’re really sustaining: For example on SMPP, if you request dlrs, depending on the carrier having it enabled or not, you’ll get one or two more “incoming” messages counted (dlrs are very similar to mo messages in structure).

After applying this patch, the status page will display incoming and dlr traffic on separate counter, either for the total amouns as in each and every defined smsc connection. It will also display separate load indicators, so you’ll know at all times if your inbound traffic is actually traffic or just old/delayed dlrs.

Here’s the patch:

kannel-dlr-status

As usual, please try it and let me know what you think.

Alex

If you’re using an external DB for dlr storage, there’s a slight chance that the carrier’s response to your MT (with the dlr information) would arrive after the dlr itself. If this happens, Kannel won’t be able to find the dlr (because it’s not there yet).

This patch implements an sleep and retry mechanism when calling dlr_get(). This aims to solve that problem.

2 new core parameters are defined:

dlr-retry-count -> How many times do we attempt to fetch the dlr? Default: 1
dlr-retry-delay -> How many milliseconds do we sleep before retrying? Default: 0

So, if you don’t set these parameters the behaviour remains as it was before patching. However, if you, for instance, set:

dlr-retry-count = 3
dlr-retry-delay = 200

Kannel will try 3 times in total (the original plus 2 more), pausing 200ms (0.2 seconds) before each attempt. If after the third attempt the DLR’s still missing, Kannel will display a warning as usual.

Download the patch from here: kannel-dlr-retry

Please try it and let me know what you think.

Regards,

Alex

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

Yesterday I’ve published a patch that added Kannel’s DBPool support for MS-SQL and Sybase via the FreeTDS library.

Today’s patch uses that functionality to implement the DLR storage on MS-SQL and Sybase DB Engines.

To use this, you need to:

1. Patch Kannel to support FreeTDS (see yesterday’s link).
2. Patch Kannel using this patch, to add support for DLR’s over FreeTDS.
3. ./configure –with-mssql=[optional path] [--other-switches]
4. make
5. sudo make install
6. Configure dlr-storage = mssql
7. Configure the DB connection (see yesterday’s article for details).
8. Configure the dlr-db group (see the userguide for details).

A simple example:

group = core
…
dlr-storage = mssql
…

group = mssql-connection
id = msdlr
username = myuser
password = mypass
server = mssql
database = mydb

#DLR Configuration
group = dlr-db
id = msdlr
table = dlr
field-smsc = smsc
field-timestamp = ts
field-destination = destination
field-source = source
field-service = service
field-url = url
field-mask = mask
field-status = status
field-boxc-id = boxc

Here is the patch: kannel-dlr-mssql

That’s all. Please try it and let me know.

Regards,

Alex

This patch adds support for the “%w” key on DLR’s, to get the message_id from the SMSC on SMPP connections.

Explanation: When Kannel sends an MT over an SMPP connection, a submit_sm PDU is sent. The carrier responds with a submit_sm_response, carrying a “message_id” attribute. If we have  proper dlr-mask set, this event (the carrier accepting the message) causes Kannel to hit the dlr-url (even if the carrier’s not sending DLR’s).

After applying the patch, a new parameter %w could be added to the dlr-url, which will be loaded with the message_id from the SMSC. This can be useful to correlate sent messages with the carriers response.

Download the patch: kannel-response-message-id

This needs further testing, please try it and let me know if it worked for you (it does for me!).