Hi.
I've tried to write a few things down about, how I think delivery report
could be implemented. I'm sure you guys can give me some comments,
pointers and suggestions..
I will from now on use the abbreviation dlr, short for delivery report,
since I'm
going to write it a lot :P
I've decided that the following constraints should be imposed:
- It should be possible to use kannel without generating dlrs.
- Kannel should remain as scalable even if using running with dlr
support
- When kannel runs without dlr support, performance should remain
unchanged.
- The overhead of using dlrs should be kept to a minimum.
First I will try to explain how I expect it work:
I imagine that the smsbox http interface will accept an sequence number,
for
generation of a delivery report. The message type for sms messages will
of
course have to extented with a field corresponding to this.
The sequence number will be sent together with the message to the
bearerbox,
and the smsbox will forget everything. When the bearerbox receives the
message, it will
add the sequence number to an internal mapping (unique_key -
smsbox_seq_num).
A unique key will be generated for each sms which requires dlr. This key
can
then be used to map to the original sequence number, specified from the
smsbox. This means the bearerbox does not have to rely on the smsbox (or
user)
for generating unique ids. In the message the sequence number is
replaced
with the unique key generated. I think, first step at least, would
be to implement the mapping in memory. Maybe it should be persistant
later on. I don't see any scalability issues with this, since the
bb doesn't scale anyway. I'll wrap it nicely.
So now the the seq_num has been mapped and the
bearerbox goes on with processing the message.
Unfortunately, it is protocol dependant (as Leo pointed out in an
earlier mail)
how delivery confirmations are constructed. Leo noted this in a previous
mail. So of course handling these confirmations should be handled by the
specific
protocol implementation. Of course some sort of abstraction is needed. I
imagine the abstraction would be a couple of callback functions. The
protocol would have to remember the message until, a dlr has been
recv. from the smsc.
When the message has been delivered, a callback function should be
called.
Something like bb_smscconn_message_delivered or in case it has not been
delivered, bb_smscconn_message_deliver_failure. The callback functions
should take the sequence number or msg containing the seq.num.,
and an free-text explanation phrase.
The callback function will create a message (a new message type will
have to
be specified) containing relevant delivery information (I imagine that
this
would include a status (eg. delivered/not delivered/not support/error or
something), a timestamp (when was the message delivered). Additionally
it will
map the bb seq_number to the sequence number the smsbox sent with the
original
message.
This is how I imagined the delivery report sent between the sms and the
bearerbox could look like:
MSG(delivery_report,
{
INTEGER(sequence_number);
INTEGER(delivery_status);
INTEGER(explanation_text)
INTEGER(time);
})
One thing i've thought about is if the data from the original message
should
be included in the dlr? It could, of course, but is there any need for
this
information to be included?
The smsbox will recieve the dlr message, and act accordingly to the
configuration upon it. Andreas Fink suggested that this should be
pr. user, which I think seems quite reasonable. His initial suggestion
looked like this:
group = sendsms-user
username = my-username
password = my-password
reports = http://www.xyz.com/delivery-reports?id=%d;
override-reports = true
I still haven't figured out you meant by override-reports, but maybe you
could explain that. Besides that, it looks nice. Substitution parameters
could be:
%d Sequence number.
%t the time the delivery report was created.
%s Status of the delivery in human readable form.
%c Status code.
The different status codes still need to be figured out. At least we
need something for representing:
* Message succesfully delivered.
* Error: Message could not be delivered.
* Message delivery status is not available/not supported.
An other thing:
Either all protocol implementations will have to call the callback
functions for each sms, or some cleanup function/thread is needed
to remove keys from the mapping, when they time out.
(eg. No dlr has been generated). It should also generate a dlr
with an error msg an send back to the smsbox. I'm not sure what
would be best, what do you guys think??
Does all this seem reasonable? Am I doing it all wrong? What am I
forgetting?
Sincerely,
Christian Theil Have.
