Re: Wierd DLR problems

Hi Rory,

Quote from the Kannel userguide:

Delivery reports are supported by default internaly, which means all DLRs
are stored in the memory of the bearerbox process. This is problematic if
bearerbox crashes or you take the process down in a controlled way, but
there are still DLRs open. Therefore you may use external DLR storage
places, i.e. a MySQL database.

Using a mysql table to hold dlr's seems the easiest way to make sure that
they dont get lost if you restart..


----- Original Message -----
From: "Rory Campbell-Lange" <[email protected]>
To: "Alexander Malysh" <[email protected]>
Cc: "Bill Brigden" <[email protected]>; <[email protected]>
Sent: Tuesday, September 16, 2003 3:42 PM
Subject: Re: Wierd DLR problems


Ah, very interesting. So should I use a dlr-mask of 19? (smsc reject +
delivery
failure + delivery success)? The "message buffered" value is therefore of no
interest to me?

    * 1: delivery success
    * 2: delivery failure
    * 4: message buffered
    * 8: smsc submit
    * 16: smsc reject

Last question(!)

If I'm using internal dlrs and I need to restart, will the DLRs still be
correctly pointed to my dlr-url? I am expecting to do give the dlr-url a
database row id number.

Thanks again,
Rory

On 16/09/03, Alexander Malysh ([email protected]) wrote:
> you will never get buffered dlr on smpp link, because smpp doesn't request
> intermediately delivery notifications (if you got these, then smsc is 100%
> broken)...
>
> On Tuesday 16 September 2003 16:20, Rory Campbell-Lange wrote:
> > Hi. It works with msg-id-type = 1
> >
> > There is still a small problem though. I set my dlr-mask to 7 but
> > although bearerbox reported that my message was buffered, this did not
> > get reported to the dlr-url.
--
Rory Campbell-Lange
<[email protected]>
<www.campbell-lange.net>