On Freitag, Januar 10, 2003, at 12:36 Uhr, Mauricio Ramos wrote:

Hi All,

We spent a lot of time testing almost all possible DLR conditions with SMPP;
We did it using Kannel stable 1.2.1, 1.3.0 and also CURRENT CVS. So, this
behaviour is VERY OLD;
We are using external dlr storage with MySQL and SMPP interface-version
"33";
The SMSC is a CMG one;
I will further do the same tests with Logica's SMSC and with interface
version "34" when Kannel supports message payload;

If somebody want to join us in testing SMPP DLR, feel free to look inside
the attached Excel spreadsheet, with all testing data and also DEBUG
information extracted from Kannel's logfiles.

The summary of symptoms are:

1) Kannel is not doing multiple DLR notifications per message when requested
(e.g. sendms dlrmask=31)

Hmm. this is to be considered a BUG. only when a final state has been reached the db entries should be removed. In a temporary state (buffered), it should be notified and still kept (EMI driver does this correctly).

2) Kannel is not inserting a record in mysql dlr table when sendsms dlrmask
is "16"

it might insert one but a different one. for status 1, 2, 4 the message ID from the remote SMSC are needed.
for 8 and 16, a temporary internal ID is used as the message ID is not being received back yet. In the EMI driver the sequence number is used for that. Now in SMPP it might be done different but be aware that it might not even add anything as the answer will be back within seconds (worst case is the timeout of the SMPP session) so the statuses could be very well kept in memory.

3) Kannel is setting the mysql drl field status to "0" when dlrmask is "4"

Thats an appropriate status for a message not being delivered to the SMSC yet.

or "20" and also setting mysql dlr field timestamp to "000000000000000"

correct. this happens when the SMS is being submitted to the SMSC. we dont know if it has been buffered yet and we dont have any update from the other side about the message ID.

4) Dlrmasks 8,9,10,25,26 or 27 are returning dlr-status equal to "12" when
should return "8"

I've seen that as well. They should return a status 8 and another message with status 4 instead.

5) In many test cases (dlrmasks 9,10,11,13,14,15,25,26, 27,29,30 or 31)
Kannel says "DLR not deleted because we wait on more reports" but after
receiving a correct deliver_sm (DLR) it just didn't find the mysql row,
telling "no rows found" and then "got DLR but could not find message or was
not interested in it"

then the message-id mapping is wrong. it doesnt find the message in the database. This is SMSC dependent and requires proper configuration for really odd SMSC who once send you message ID in hex, once in alphanumeric and once in decimal (really stupid...).

6) When Kannel says "removing DLR from database" the respective mysql row
remains on the dlr table

Now this is really odd. edit the dlr.c and enable a variable to do SQL dumps so you see the SQL statements its executing. This helps a lot to debug those things. Maybe its the same issue as above, wrong type of message ID.

Andreas Fink
Fink Consulting GmbH

---------------------------------------------------------------
Tel: +41-61-6666332 Fax: +41-61-6666331 Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail: [EMAIL PROTECTED]
Homepage: http://www.finkconsulting.com
---------------------------------------------------------------

Reply via email to