Hi,
To check if you have db functionality do:
ldd $(which bearerbox)
Or look at bearerbox initialization in the logs. I believe that most Fedora
rpms come with mysql support.
BR,
Nikos
----- Original Message -----
From: Jarratt Ingram
To: [email protected]
Sent: Monday, September 13, 2010 1:14 PM
Subject: Re: DLR and Message Type question
Hi Alex,
Thank you, I have seen your patch I thought it was related to sql db related
messages only.
I will compile the latest version from svn and add our two DLR patches as I
need the throttling patch and DB DLR functionality which is not in the
current Fedora rpm as far as i know.
I will let everybody know once completed
Kind Regards
Jarratt
On 09/13/2010 11:55 AM, Alejandro Guerrieri wrote:
Some aggregators have issues with the "timeline" of DLR's.
It happened to us with one of them, the DLR's arrive before the
submit_sm_resp, so when the delivery receipt arrives, the DLR is not yet
stored on the DB, thus it fails.
Check the logs to see if that's the case. The entry writing the DLR to the
DB should be _before_ the "got DLR but could not find message..." error.
If that's the case, I've a small patch to retry the DLR's later, but should
be used with caution (if you set the delay too high, under heavy traffic the
retries would hold the thread for extra time and will degrade performance)
Hope it helps,
Alex
On Mon, Sep 13, 2010 at 11:37 AM, Jarratt Ingram
<[email protected]> wrote:
Good Morning All,
I am experiencing some small issues with the DLR mechanism in my current
Kannel configuration,
RPM version of Kannel on Fedora 13 64bit
DLR is currently set to internal storage,
msg-id-type is default as it is not explicitly set.
I have two SMPP connections to a provider both have the same smsc-id and are
both setup with transceiver-mode = 1
The DLR processing works for 90% of the time and every now and again i get
the following in the logs
2010-09-13 11:11:13 [7277] [6] ERROR: SMPP[3]: got DLR but could not find
message or was not interested in it id<27/00/4d599338/1127829048804>
dst<27829048804>, type<2>
This then leaves the message in an ACK/ state and never gets updated to sent
or undelivered, based on the message above does this mean i should rather
set the msg-id-type = 0x02 ? i am assuming that Kannel is able to correctly
determine the DLR's 90% of the time and gets stuck every now and again ?
Also does the Kannel status page EG: DLR: 1247 queued, using internal
storage
directly relate to this i.e id a DLR is not found does the DLR queue get
reduced by 1 ? As i have had over 1k DLR's pending for a few days now
Any help would be appreciated,
Kind regards
Jarratt
