Hi Nikos, Alex
I will compile Kannel this evening so that is incorporates the mysql
bindings so that i can store dlr's externally and the let you if there
are any issues after that.
Thank you both for your assistance it is very much appreciated.
Regards
Jarratt
On 09/13/2010 12:46 PM, Nikos Balkanas wrote:
No. These are different (C) threads. Throttling errors affect only
outgoing, MT, traffic, while DLRs are incoming, MO.
DLR mismatches happen frequently when using internal dlr-storage. In
this case, whenever you restart bearerbox, you loose all pending DLRs.
This problem is fixed by either not shutting down bearerbox, or using
a DB for permanent dlr-storage.
BR,
Nikos
----- Original Message ----- From: "Jarratt Ingram"
<[email protected]>
Cc: <[email protected]>
Sent: Monday, September 13, 2010 1:35 PM
Subject: Re: DLR and Message Type question
Hi Nikos, Alex
As a note i need to compile the svn version as there is mention of
improved throttling as per my configuration below this particular
network currently limits us to 10 msg per second and i still get
throttling errors, would the throtteling errors trigger DLR issues
due to its sleeping ?
*Log snapshot*
2010-09-13 12:23:31 [7277] [6] WARNING: SMPP: PDU NULL terminated
string (message_id) has no NULL.
2010-09-13 12:23:31 [7277] [6] ERROR: SMPP[3]: SMSC returned error
code 0x00000058 (Throttling error) in response to submit_sm.
2010-09-13 12:23:39 [7277] [6] WARNING: DLR[internal]: DLR from
SMSC<3> for DST<27824578315> not found.
2010-09-13 12:23:39 [7277] [6] ERROR: SMPP[3]: got DLR but could not
find message or was not interested in it
id<27/00/4d6322b8/1127824578315> dst<27824578315>, type<2>
2010-09-13 12:23:46 [7277] [6] WARNING: DLR[internal]: DLR from
SMSC<3> for DST<27722805466> not found.
2010-09-13 12:23:46 [7277] [6] ERROR: SMPP[3]: got DLR but could not
find message or was not interested in it
id<27/00/4d632638/1127722805466> dst<27722805466>, type<2>
2010-09-13 12:23:48 [7277] [7] WARNING: SMPP: PDU NULL terminated
string (message_id) has no NULL.
2010-09-13 12:23:48 [7277] [7] ERROR: SMPP[3]: SMSC returned error
code 0x00000058 (Throttling error) in response to submit_sm.
2010-09-13 12:23:59 [7277] [7] WARNING: DLR[internal]: DLR from
SMSC<3> for DST<27832960656> not found.
2010-09-13 12:23:59 [7277] [7] ERROR: SMPP[3]: got DLR but could not
find message or was not interested in it
id<25/00/4d632cb8/1127832960656> dst<27832960656>, type<2>
2010-09-13 12:24:00 [7277] [6] WARNING: SMPP: PDU NULL terminated
string (message_id) has no NULL.
2010-09-13 12:24:00 [7277] [6] ERROR: SMPP[3]: SMSC returned error
code 0x00000058 (Throttling error) in response to submit_sm.
Config is as follows
dlr-storage = internal
I have 4 different SMPP configurations each with 2 SMPP connections
and each have the same smsc-id just different IP addresses
here is one of them:
group = smsc
smsc = smpp
smsc-id = 3
allowed-smsc-id = 3
host = ***.***.***.***
transceiver-mode = 1
port = 1070
#receive-port = 1070
smsc-username = "****"
smsc-password = "****"
system-type = "VMA"
address-range = ""
interface-version = 34
bind-addr-ton = 1
bind-addr-npi = 1
enquire-link-interval = 300
log-file = "/var/log/kannel/bulksms.log"
log-level = 1
throughput = 10
#msg-id-type = 0x02
#wait-ack = 60
#wait-ack-expire = 0x02
The ldd output appears to confirm that there is only sqllite
connectivity in the fedora rpm
[r...@husqvarna ~]# ldd $(which bearerbox)
linux-vdso.so.1 => (0x00007fff169ff000)
libssl.so.10 => /usr/lib64/libssl.so.10 (0x0000003fa9a00000)
libpcreposix.so.0 => /usr/lib64/libpcreposix.so.0
(0x0000003fa6a00000)
librt.so.1 => /lib64/librt.so.1 (0x0000003fa5e00000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003fa6600000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003faaa00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003fa5a00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003fa4e00000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0000003fabe00000)
libz.so.1 => /lib64/libz.so.1 (0x0000003fa5600000)
libpcre.so.0 => /lib64/libpcre.so.0 (0x0000003fa9e00000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x0000003fa9600000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003fa5200000)
libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0
(0x0000003fad200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003fa4a00000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2
(0x0000003fa8e00000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003fa8a00000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003fa6e00000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003fa9200000)
/lib64/ld-linux-x86-64.so.2 (0x0000003fa4600000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0
(0x0000003fa8200000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003fa8600000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003fa6200000)
Regards
Jarratt
On 09/13/2010 12:06 PM, Nikos Balkanas wrote:
Hi,
No, do not mess up with msg-id-type or you will loose 100% of your
DLRs.
Unmatched DLRs are discarded and erased form storage. You can
examine storage contents from the HTTP admin.
Post your configuration and detailed stsrtup bb logs.
BR,
Nikos
----- Original Message ----- From: "Jarratt Ingram"
<[email protected]>
To: <[email protected]>
Sent: Monday, September 13, 2010 12:37 PM
Subject: DLR and Message Type question
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
