>
>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?
yes. Its the SMSbox which does the processing of all incoming SMS and
it is the unit which does the URL requests. so it makes a lot of
sense to do it there. Bearerbox is not made for requesting URL's and
might not even be on a network which is able to do that.
>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.
yes but not scalable at all.
>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.
The problem here is that you can accept a ID from the application
being meaningful to the application but that doesnt mean you can pass
this ID through to the SMSC and the delivery report will have it too.
For example on a EMI/UCP system when submitting the SMSC will return
you a timestamp and this is more or less your key to match the
original message to the delivery report. However the application
would have no possibility to match this timestamp (it never got that
one back from Kannel while submitting) to the internal ID. Also
imagine you have a kannel instance where you submit to various
different SMSC's so you would get back once a EMI timestamp and then
a SMPP message ID or whatever those various systems use. We want to
abstract the application from the SMSC type as far as possible so the
only way is to have a unique ID inside kannel.
Now the problem is that the mapping has to be done in bearerbox
because the mapping is specific to the SMSC thread. So it has to be
bearerbox who does this because once the message gets to SMSbox it
doesnt know anything anymore about what kind of SMSC it was generated
from. That makes the solution not scale and have a performance
bottleneck. We should maybe think of having multiple bearerboxes (one
per SMSC link for example) running on multiple machines talking to
multiple SMSBoxes also on multiple machines. The routing would become
very complex but that would scale too.
However we shouldnt worry too much right now about it. people have
very fast CPU's these days so its unlikely to outperform a one CPU
box with one bearerbox and one smsbox unless you run billions of
messages every month.
>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).
I think we should stick to HTTP. It has been choosen because its very
easy to implement on the application side. Lets not generate another
"SMSC" type of interface. There are already enough..
>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.
The number of reports yes. Not all SMSC types might be able to do
that but then we can quickly throw away what we don't need. However
requesting any kind of report means we have to keep track of the
message whatsoever. I personally think on the SMSC level its better
to have a delivery and non delivery report because if it has been
delivered we can throw the saved information away. If we only get
reports on non delivery this would mean we keep track of a message
until timeout (a few days) even it has already been delivered since a
while. That would increase the saved information a lot.
--
Andreas Fink
Fink-Consulting
------------------------------------------------------------------
Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333
Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland
E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com
------------------------------------------------------------------
Something urgent? Try http://www.smsrelay.com/ Nickname afink
