>
> We dont really care. The ID is sent back to the application so the
> unique ID is only of value to the application.
>
This implies that the DR has to be uniquely routed back to the
application, which presents its own challenges (see later). For
example, a broadcast model for propagating DRs back to the SMS
box is effectively ruled out.
> Theres some work to be done on teh SMS box. The idea was to define a
> keyword for every application. so if you have APP1 and APP2 sending
> messages, the dlrs going back would have keywords like DLR_APP1 and
> DLR_APP2 so they get sent back to the correspodning application.
> Currently this is hardcoded to "DLR" but supposed to be changed soon.
That might work for multiple applications interfacing to a *single*
SMS box. But what about multiple applications interfacing to multiple
SMS boxes ? In that case you need to store information about the
target SMS box in the DR struct to ensure correct routing from the BB
to the SMS box.
> Well the problem is that the DR structure is still there when the
> message has already been trashed. You dont want to keep the full
> message for such a long time. That would betoo much waste of memory.
> But I'll take a look at that code anway, I'm sure I can reuse some of
> it. After all, its the same moment when those things happen.
No, what I mean is to use the Msg struct to wrap your dlr_wle from dlr.c
Adding something like the following to msg-decl.h;
MSG(dlr,
{
OCTSTR(smsc);
OCTSTR(timestamp);
OCTSTR(destination);
OCTSTR(keyword);
OCTSTR(id);
INTEGER (mask);
})
The advantage I see is that there is lots of code to manipulate
this struct and that the store supports it already.
> Assume you send out 1 million SMS a month and you have 7 days of
> delivery reports being queued up, that would result in carrying
> around 250'000 message structures. If we presume the message struct
> is only 200 bytes that results in 50MB memory useage. The
> applications I've seen who want to do delivery report where mainly
> for billing issues. You want to be sure the message got there before
> you bill it kind of thing. Or if it doesnt go through you want to
> requeue it to another SMSC for example. In that case the DLR is sent
> back to the application. Because the application has a unique key, it
> can recreate the message again or it could reverse the billing charge
> etc. etc. I dont think its up to kannel to handle the DLR so thats
> why we dont need the message anymore.
Agree. Kannel should not cache a message purely for the purposes of DR
handling. That belongs to the application.
