There are a couple of reasons you might not want to use internal
storage. The first is that its wiped out when Kannel restarts, so if
there is a problem, or you want to add a new SMSC into the
configuration any outstanding DLRs are lost.
This is actually NOT necessarily true....
If your .store is not located in /tmp/ (as suggested by the user
guide)
Your store WILL be persistent!
You are talking about the store file which contains the unsent
messages, not the contents of the internal DLR storage, these are
held in memory and not paged to disk. From the user guide :-
"Delivery reports are supported by default internaly, which means all
DLRs are stored in the memory of the bearerbox process. This is
problematic if bearerbox crashes or you take the process down in a
controlled way, but there are still DLRs open"
The second would be if you had 2 Kannel boxes running and there was
the possibility of a DLR coming back into the other Kannel box from
the one that sent it. You would need to have a single database that
both boxes shared.
This also is NOT necessarily true...
If you configure ALL your smsboxes WITHOUT an smsbox-id, then
YES...Ben is
right.
How ever, if you need the DLR to be handled by the box that issued
it...you can name your
smsboxes and bearerbox will send all DLRs to THAT box.
But...Why bother? Who cares WHICH box notifies the sendsms user?
I was talking about running multiple bearerboxes (not smsboxes as you
have interpreted me, sorry should have been clearer - For me I only
run bearerbox's and have my own application interfacing directly to
them), each with the same connections to the same SMSCs (for high
availability). In this way the SMSC could send the DLR back to either
bearerbox.
Its quite possible that people have phones switched off in meetings,
on flights, go on an underground train etc. So whilst most messages
are delivered quickly its possible with a large volume of messages to
see outstanding DLRs for quite some time.
This also is NOT necessarily true...
As I said in an earlier mail, SOME SMSC tell you if the message is
buffered at either the phone or the SMSC
In that case you will receive intermediate DLRs (if you requested
them
with a proper dlr-mask)
In general any message you submit to your supplier should get a
FINAL DLR
within 5 minutes
We allow a latency margin of 1% (meaning that 1% of all traffic
is allowed
to have it's DLR delivered AFTER 5 minutes)
IF this is the case, then a route is considered OK. Because a
small margin
of the handsets you a trying
to reach is indeed switched of or somethin
Its quite true that an SMSC may report a buffered DLR however, until
a final DLR is received you will still have (unless you specifically
set the dlr mask only to report on buffered messages) outstanding
DLRs until the message is received by the phone, which could be hours
or days depending on what situation the user is in. So with a large
volume of messages its quite possible to see outstanding DLRs for
quite some time, not because the DLRs have been delayed, but because
the message has not yet been delivered to the phone.
Regards
Ben
