Re: Delivery reports again...

[Carlos Cortijo]

 
Hi, all.

This makes a lot of sense for me overall, though I think your proposal adds some
unnecessary complexity, and some points may have negative impact in performance.

Does the smsbox need to be involved in delivery report? I mean, it is the bearerbox
that detects when a message could / could not be correctly delivered. Then, it could
directly notify to the URL configured for the sendsms-user. Faster, simpler.

Is there a need to generate internal unique IDs? I wouldn't add this complexity to
Kannel. Generating these IDs, and more important, keeping the mapping between
seq. numbers and internal unique IDs is a big overhead for large message volumes.
Furthermore, the delivery report will be for the sendsms-user (in other words,
originating application). In a few words, delivery reports are for itself, so it should
generate sequence numbers meaningful to itself.

Another point, the delivery report can be sent back through HTTP, but it could be
much more efficient with TCP or even UDP (or you can make it configurable for each user
how to receive delivery reports).

There should be the option to receive delivery reports only when message delivery
fails, and this should be a recommended default. This can dramatically reduce the
number of delivery reports.

Hope this helps,
Carlos.
 

Christian Have escribió:

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.

-- 

Name:  Carlos Cortijo
Title: Senior Developer
Civista (CTC)
 
Switch:    +34 952 028 333
Facsimile: +34 952 020 319
e-mail: [EMAIL PROTECTED] 
http://www.civista.com 
 
Services and Applications for a Wireless World 
 
This e-mail and the information that it contains may be confidential and protected by law and is for access by the intended recipient only. Any liability (in negligence or
otherwise) arising from any third party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended
recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Civista Limited and/or its subsidiary companies.
 
While this message is virus checked, Civista can not be held responsible for its integrity.