Here's a patch for DLR support.
Here is how it works.
On the URL, you can request delivery report by specifying
&dlr_mask= { 0, 1, 2, 3}
if set to 0 or dlr_mask is omitted, no delivery reports are requested
if set to 1 you get success reports only
if set to 2 you get failure reports only
if set to 3 you get success & failure reports
&dlr_id=<string>
this is a unique ID your application specifies. It will be sent back
to you when the delivery report arrives so it should be something
like a message numer or so.
Thats how far it is requesting it.
The messages are sent out to the SMSC and at some point in time the
DLR arrives back from the SMSC. In that case, a incoming SMS is
generated and sent back. This incoming SMS is constructed the
following way:
"DLR x y z"
x = 1 means successful delivery
x = 2 means failed delivery
y is the unique ID you passed along
z is the short message center id the message was sent to.
The letters "DLR" are currently hardcoded in smsbox.c but are meant
to be user configurable so you can configure which keyword triggers
which DLR callback. This trigger keyword is send back & forth already.
Current supported SMSC's are EMI2, CIMD2 only.
How does it work internally?
When you request a DLR, the dlr request fields are set on the way out
for success & failure always. The request we made is then added to a
list to remember. When the system sends us back a delivery
notification, positive or negative, we look this list up again and we
remove the entry from that list again. If its a report the user asked
for, we create a message back. If the user didnt ask for it (for
example he asked for failure notification but we asked failure &
success from SMSC) we simply remove it from the list silently. If we
wouldnt do that the list would grow for every message not failing.
Things still to be done:
a) We want to use some kind of database instead of using a list in
memory. This doesnt work well if its having a lot of delivery
reports. Of course this introduces an additional library to kannel.
b) if we use memory, we want to save it to disk from time to time
(especially at shutdown) and reload it at startup.
c) We want to clean the list from too old entries
d) We might want to be able to specify a hold time telling the smsc
until when he should retry sending the message. for example for
normal messages it might be 72 hours but if the user just requested a
logo while on a webpage, there is a 99% chance his phone is on and
waiting for the logo to be received as he is of course eager to get
it. In that case delivery times over 15 minutes most probably
indicate that we cant reach this guy or something else is seriously
wrong.
e) support for all the other SMSC types. I'm not too sure how we
should implement this into HTTP smsc type.
I'm awaiting feedback. We've tested it on EMI2 and CIMD2 on a
separate version so there might still be bugs and memory leaks we
have not gathered yet.
The dlr.c/dlr.h files go into the gw directory by the way.
--
Andreas Fink
SMSRelay
------------------------------------------------------------------
Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333
Address: SMSRelay, Schwarzwaldallee 16, 4058 Basel, Switzerland
E-Mail: afinkgsmsrelay.com Homepage: http://www.smsrelay.com
------------------------------------------------------------------
Something urgent? Try http://www.smsrelay.com/ Nickname afink
DLR.diff
dlr.c
dlr.h
