Re: Interesting issue with DLRs

1. I do know what the term MASK implies.....................hence my
difficulty with it.
and is definitely not straight forward sharing the same value.

2. the dlr database is an internal database ? yeah so what?, what are you
trying to say?
    its still only being used by kannel.

3. "The DLR database is populated at the time of SUBMIT_RESP"
    Is this some rule in concrete??

4. yes, its usually only seconds for the submit_resp to occur, and the cases
where the
    delivery report occurs before then is not often.
    Its always safer to store persistently -  altho one could argue that
since the sequence-no is
    stored in a memory dictionary, if kannel crashes its all over for that
message........
    but hehe, look how your kannel is simply returning a
deliver_sm_resp.............

5.Performance, yes theres more lookups, although since we are using GDBM for
dlr records......
   don't really see a problem.
   It really only one 1 additional lookup, and a posible update. ( and it
should be an in-place update to boot!
   as the record size doesn't change, so should be fast)

   In any case, i'd be willing to bet, even with more sql queries, the
performance limit will still be
   your bandwidth to the carrier's SMSC over the WAN.

6. Someone is being overly defensive with how the code originally written,
blah blah.....
    saying i am WRONG ?.......like i broke some holy grail.....very
childish.

    some people want to debate by committee what to do........
    others just go in and fix it and make it work....

    I was just sharing how I solved the problem.
    You haven't presented how you would solve the problem this thread is
about.



----- Original Message ----- 
From: "Andreas Fink" <[email protected]>
To: "fred" <[email protected]>
Cc: "devel" <[email protected]>
Sent: Monday, October 23, 2006 3:44 PM
Subject: Re: Interesting issue with DLRs



On 23.10.2006, at 07:37, fred wrote:

> dealing with this problem i found the use of dlr_mask a PITA,
> because whilst
> it gets used as a
> mask at times, all of a sudden its behaviour changes to be a dlr
> status,
> when the msg becomes a report,
> and the way its done...well enough said......
> So anyway, I store both a dlr_mask and a dlr_status in DLR
> database, also as
> I mentioned else where,
> have another field - tid (transactionid).
>


dlr_mask is saying which even types you want to receive
dlr_status is the actual event you do receive.

They share the same values for simplicity. This is pretty
straightforward.
The database only has dlr_mask, as dlr_status is not stored at all.
At the time you have a final status, your message is complete and the
record in the TEMPORARY database has been removed.
Some people think the DLR database is their report status database.
This is NOT the case and was never designed to be that way.
DLR is a temporary storage for kannel internal use ONLY. If you need
long term delivery report statuses, you should redirect the output of
the delivery report HTTP request to some useful script updating your
own database.



> Now, if a dlr report is received,
>   1. lookup the DLR db for the messageid
>   2. In this case it is NOT found (submit_sm_resp not occured yet)
>       2.1. add the dlr record, with its dlr_status the status of
> the report.
>   3. Else found but  if tid not set (ie==-1) /* submit_sm_resp
> still not
> occured */
>   3. 1  update dlr_status in DLR db and continue.

This is not a good idea. The lifespan of the delivery report coming
in before the submit response is SECONDS. So it can and should be
mapped in memory. The database is there because delivery reports can
come in as late as 7 days later (if phone was off and switched on
just after expiration time).

> When a submit_sm_resp occurs,
>     1. lookup DLR db for messageid
>     2. It is found! strange? got deliver_sm report already!!,
>     3. tie up msg using the sequence no
>     4. check the stored dlr_status for any final status, send delivery
> report to smsbox
>     4.1  otherwise update dlr_status with SMSC_DELIVERED, and the tid.
>     5.2 continue

Again WRONG. The DLR database is populated at the time of SUBMIT
resüpmse. so we can remember the message id.
If you populate it on the delivery report, then you get into the
problem that you will create an already existing record. In other
words you will end up doing  lots and lots of SQL queries to a
database even for messages you never asked for a delivery report.
This is a performance bottleneck.

>
> any more questions? please ask, it works quite well, at least a
> year or
> so.......
>
> Fred
>
>
> ----- Original Message -----
> From: "Stipe Tolj" <[email protected]>
> To: "Ben Suffolk" <[email protected]>
> Cc: "kannel Devel" <[email protected]>; "Andreas Fink" <[email protected]>
> Sent: Saturday, October 21, 2006 10:58 PM
> Subject: Re: Interesting issue with DLRs
>
>
>> Ben Suffolk wrote:
>>
>>> Andreas,
>>>
>>> How do I do this?
>>>
>>> I only have the one smsc configuration, with the tx and rx ports
>>> set.
>>> So as far as I am aware its only on session anyway? If you mean a
>>> transceiver , they are not supported by the operator.
>>
>> yep, Andreas means the tranceiver mode actually. While this TRX
>> session
> mode is
>> part of v3.4 it won't be supported if operator does only offer v3.3
> capabilities.
>>
>> I definetly see a logical demand for the 2 table DLR (MT and MO)
>> solution
> here.
>>
>> Any more thoughts from the group, please?
>>
>> Stipe
>>
>> -------------------------------------------------------------------
>> Kölner Landstrasse 419
>> 40589 Düsseldorf, NRW, Germany
>>
>> tolj.org system architecture      Kannel Software Foundation (KSF)
>> http://www.tolj.org/              http://www.kannel.org/
>>
>> mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
>> -------------------------------------------------------------------
>>
>