Hi,
The documentation is correct. DLR entries (internal to kannel but without
final status) are created and inserted when the SMS is accepted by the SMSc
and deleted when the external DLR (with final status) arrives from the SMSc.
This could last for the time it takes to deliver the SMS to the mobile. It
could be anything from a few minutes to a couple of days. If DLRs are in
memory, bb is restarted, and the final DLR from the SMSc is still pending,
the entries will be erased from memory. The result is that when the external
status DLR arrives from the SMSc, there is no corresponding entry to match
in kannel, and discarded. This doesn't happen if you use a DB for
dlr-storage.
The DLR tables are to be used only internally by kannel. You can see the DLR
from bb access logs and you can even store it in your external web
application by specifying a dlr-url to your push SMS. You will have to
supply a msg-id to that dlr-url, unique for each MT, since msgid is internal
to kannel and not sent over the dlr-url.
For more info read User's Guide.
BR,
Nikos
----- Original Message -----
From: brett skinner
To: [email protected]
Sent: Wednesday, June 30, 2010 10:44 AM
Subject: Open DLRs
Hi
Reading through the documentation I came across this statement:
This is problematic if bearerbox crashes or you take the process down in a
controlled way, but there are still DLRs open. Therefore you may use
external DLR storage places, i.e. a MySQL database.
Does that mean that the MySQL is temporary storage and that at some point
when the DLR is deemed to be closed that the row will be removed? If so then
When is a DLR closed?
Should we be using the MySQL table to get extra information about the DLR?
If not what should we be using?
Can we get Kannel to send us information about the fields in the DLR in the
URL. Such as message_id field from submit_sm_resp?
Thank you. I really appreciate all the help.
