>Hi,
>
>Here's some comments;
>
>
>> this is a unique ID your application specifies. It will be sent back
>> to you when the delivery report arrives so it should be something
>> like a message numer or so.
>
>How do you ensure unique IDs across applications ? ie. What if application
>A and application B are both using the same sendsms interface and are
>specifying identical IDs ?
We dont really care. The ID is sent back to the application so the
unique ID is only of value to the application.
> > Thats how far it is requesting it.
>> The messages are sent out to the SMSC and at some point in time the
>> DLR arrives back from the SMSC. In that case, a incoming SMS is
>> generated and sent back. This incoming SMS is constructed the
>> following way:
>
>How are the generated incoming SMS messages routed back to the correct
>SMS box ? If you have 3 SMS boxes connected, each submitting messages
>requesting DRs, how does the bearer box know which SMS boxes to routes
>the individual DRs to ? (If I've missed the obvious, sorry).
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.
> > a) We want to use some kind of database instead of using a list in
>> memory. This doesnt work well if its having a lot of delivery
>> reports. Of course this introduces an additional library to kannel.
>
>Why don't you use the bb_store.c functionality ? If you represented a DR
>as another option in the Msg struct, it should'nt be too hard to sit on
>top of the functionality offered by the existing store. Given that the
>store is there to support correlation of Msgs and internal Acks, it
>seems a logical choice.
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.
> >
>> b) if we use memory, we want to save it to disk from time to time
>> (especially at shutdown) and reload it at startup.
>
>Again, this is functionality in the store.
>
>>
>> c) We want to clean the list from too old entries
>
>The store includes a background thread, performing correlation. It could
>be extended to do timeouts for DRs (or a new thread introduced).
>
>I think there are two broad approaches to DRs.
>
>1. Applications that want to handle the DR themselves and hence expect the
>gateway to handle it as a message (ie. transparently).
>
>2. Application that want to know the information contained in the DR and
>hence expect the gateway to supply that information in response to a
>query.
>
>As I understand your patch, its roughly case 1 ?
Yes there is no such thing like "give me the status of message x". I
dont think this is really of use.
>I don't think your DR representation is rich enough;ideally you should carry
>as much information as possible back to the originating application to
>allow it make a decision on how to handle the DR. I would prefer a Msg
>based representation to lever on the existing store functionality as stated
>above. I also think this approach makes it easier to deliver case 2 as this
>code evolves.
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.
Also be aware that the message might be stuck in queue 1 for SMSC 1
while the DLR comes back on queue 4 of SMSC 1 if you have multiple
sessions. Thats why the DLR is global and not SMSC specific (that was
the case in our first approach).
Of course there could be done a lot more...
For those of you who tried the patch on CIMD2, there's a bug. I
probably will come out with a new patch tomorrow.
--
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
