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
