Re: receiving the messageid - another approach until a DLR parameter is introduced.

**>From: "Hillel Bilman" <[email protected]>
**>To: "Alexander Malysh" <[email protected]>
**>Subject: receiving the messageid - another approach until a DLR parameter is
**>	introduced.
**>Date: Fri, 11 Feb 2005 13:21:26 +0200
**>Cc: Kannel Devel <[email protected]>
**>
**>Dear Alex,
**>
**>The ts is the messageid for smpp.
**>If you use the dlr table for internal Kannel storage, then the ts is stored
**>in the dlr table until the SMS is delivered. Can't Kannel have another
**>column in the dlr storage table called smsid? Then you will at least know
**>which smsid corresponds to which messageid (ts) and if the SMS is not
**>delivered you can look at that table and find the
**>messageid of the SMS with the missing delivery receipt. You can then ask
**>your SMS carrier what is going on. At present you have no way of referring
**>to the SMSs that were not delivered, as you don't have their messageids.

My solution would have been the same...add the sms.id into the
dlr_entry and then have another xxxbox (statusbox?) available that
will return status info on state of an SMS if given a sms.id. This
statusbox would also provide the capability to return a 'ts' field
if given a sms.id.

Doing it this way will allow more than just a message-id in a dlr-url.

I've got 30% of it done (hacking all the dlr_xxx.[hc] to add another
field for the sms.id, updating the urltrans_get_pattern() to support
%II for the 'ts' field content expansion, designing the interface
and protcol for the statusbox...still looking for a better name).
I've still got to finish coding my statusbox. And, the statusbox
will be very preliminary. I'll add in support for allow/deny-ip
and username/password later.

I won't be able to finish it this week, though. If Alex does get
the time, then he should extract and submit his code.  I could
always throw away my dlr_xxx hacks and keep the statusbox code.

See ya...

d.c.