No not using multi part MT my all messages are carrying
[flags:-1:0:-1:-1:31] within 140 char length limit.
On 8/15/2015 9:42 PM, spameden wrote:
2015-08-15 18:03 GMT+03:00 Moazzam <moz...@gmail.com
<mailto:moz...@gmail.com>>:
Thanks Alvaro, however, I do not think this is related to the dlr
type. Most of the time its working fine only couple of time we see
this. For example there were 146 such occurrence out of 28580
where we got this error which is about 5% of the total SMS sent on
that day.
[kannel]# cat gateway.log |grep "2015-08-14"|grep -c "got DLR but
could not find message"
146
[kannel]# cat access.log|grep "2015-08-14"|grep -c "Sent"
28580
Perhaps the final DLR is not reach in due time and causing this.
Is there anyway to fine tune this with a configuration change?
Hi. Do you send multipart MT? Kannel only asks for DLR for the first
part of the MT, but many SMSC operators sending for all parts DLR
reports that's why you might be getting such errors in your error log.
You can check by sending multipart message (for coding=0 it would be
more than 140 symbols or for coding=2 >70).
On 8/14/2015 7:39 PM, Alvaro Cornejo wrote:
Hi
Check the format of dlr-id some smsc use hex and some dec.
Adjust kannel config accordingly
I think the parameter to adjust is dlr-type
Regards
|-----------------------------------------------------------------------------------------------------------------|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde
cualquier celular y Nextel
en el Perú, México y en mas de 180 paises. Use aplicaciones 2
vias via SMS y GPRS online
Visitenos en www.perusms.com
<http://www.perusms.com> <http://www.perusms.com>
On Fri, Aug 14, 2015 at 8:48 AM, Moazzam <moz...@gmail.com
<mailto:moz...@gmail.com> <mailto:moz...@gmail.com
<mailto:moz...@gmail.com>>> wrote:
Hi,
I have a production kannel v1.4.4 instance running with
sqlbox and
opensmppbox along with mysql as DLR storage. So far so
good but
I am facing an issue with the DLR where DLR are being
queued and
strange error related to the message id & destination is
appearing
the the gateway log as below. Please advise how to get rid
of this
problem.
2015-06-23 01:33:00 [32056] [6] DEBUG: SMPP[crs]: Got PDU:
2015-06-23 01:33:00 [32056] [6] DEBUG: SMPP PDU
0x7fceb0000a10 dump:
2015-06-23 01:33:00 [32056] [6] DEBUG: type_name: deliver_sm
2015-06-23 01:33:00 [32056] [6] DEBUG: command_id: 5 =
0x00000005
2015-06-23 01:33:00 [32056] [6] DEBUG: command_status: 0 =
0x00000000
2015-06-23 01:33:00 [32056] [6] DEBUG: sequence_number: 2 =
0x00000002
2015-06-23 01:33:00 [32056] [6] DEBUG: service_type: NULL
2015-06-23 01:33:00 [32056] [6] DEBUG: source_addr_ton: 1 =
0x00000001
2015-06-23 01:33:00 [32056] [6] DEBUG: source_addr_npi: 1 =
0x00000001
2015-06-23 01:33:00 [32056] [6] DEBUG: source_addr:
"2xxxxxxxxxxx"
2015-06-23 01:33:00 [32056] [6] DEBUG: dest_addr_ton: 5 =
0x00000005
2015-06-23 01:33:00 [32056] [6] DEBUG: dest_addr_npi: 0 =
0x00000000
2015-06-23 01:33:00 [32056] [6] DEBUG: destination_addr:
"Zxxxxx"
2015-06-23 01:33:00 [32056] [6] DEBUG: esm_class: 4 =
0x00000004
2015-06-23 01:33:00 [32056] [6] DEBUG: protocol_id: 0 =
0x00000000
2015-06-23 01:33:00 [32056] [6] DEBUG: priority_flag: 0 =
0x00000000
2015-06-23 01:33:00 [32056] [6] DEBUG:
schedule_delivery_time: NULL
2015-06-23 01:33:00 [32056] [6] DEBUG: validity_period: NULL
2015-06-23 01:33:00 [32056] [6] DEBUG:
registered_delivery: 0 =
0x00000000
2015-06-23 01:33:00 [32056] [6] DEBUG:
replace_if_present_flag: 0
= 0x00000000
2015-06-23 01:33:00 [32056] [6] DEBUG: data_coding: 0 =
0x00000000
2015-06-23 01:33:00 [32056] [6] DEBUG: sm_default_msg_id: 0 =
0x00000000
2015-06-23 01:33:00 [32056] [6] DEBUG: sm_length: 112 =
0x00000070
2015-06-23 01:33:00 [32056] [6] DEBUG: short_message:
2015-06-23 01:33:00 [32056] [6] DEBUG: Octet string at
0x7fceb0001110:
2015-06-23 01:33:00 [32056] [6] DEBUG: len: 112
2015-06-23 01:33:00 [32056] [6] DEBUG: size: 113
2015-06-23 01:33:00 [32056] [6] DEBUG: immutable: 0
2015-06-23 01:33:00 [32056] [6] DEBUG: data: 69 64 3a 35 39
33 38 35 38 38 35 31 34 38 33 30 id:5938588514830
2015-06-23 01:33:00 [32056] [6] DEBUG: data: 36 36 34 20 73
75 62 3a 30 30 31 20 64 6c 76 72 664 sub:001 dlvr
2015-06-23 01:33:00 [32056] [6] DEBUG: data: 64 3a 30 30 31
20 73 75 62 6d 69 74 20 64 61 74 d:001 submit dat
2015-06-23 01:33:00 [32056] [6] DEBUG: data: 65 3a 31 35 30
36 32 32 31 38 30 31 32 37 20 64 e:150622180127 d
2015-06-23 01:33:00 [32056] [6] DEBUG: data: 6f 6e 65 20 64
61 74 65 3a 31 35 30 36 32 33 30 one date:1506230
2015-06-23 01:33:00 [32056] [6] DEBUG: data: 31 33 33 31 33
20 73 74 61 74 3a 44 45 4c 49 56 13313 stat:DELIV
2015-06-23 01:33:00 [32056] [6] DEBUG: data: 52 44 20 65 72
72 3a 30 30 30 20 74 65 78 74 3a RD err:000 text:
2015-06-23 01:33:00 [32056] [6] DEBUG: Octet string
dump ends.
2015-06-23 01:33:00 [32056] [6] DEBUG: network_error_code:
2015-06-23 01:33:00 [32056] [6] DEBUG: Octet string at
0x7fceb0002900:
2015-06-23 01:33:00 [32056] [6] DEBUG: len: 3
2015-06-23 01:33:00 [32056] [6] DEBUG: size: 4
2015-06-23 01:33:00 [32056] [6] DEBUG: immutable: 0
2015-06-23 01:33:00 [32056] [6] DEBUG: data: 03 00 00
...
2015-06-23 01:33:00 [32056] [6] DEBUG: Octet string
dump ends.
2015-06-23 01:33:00 [32056] [6] DEBUG: message_state: 2 =
0x00000002
2015-06-23 01:33:00 [32056] [6] DEBUG: receipted_message_id:
"5938588514830664"
2015-06-23 01:33:00 [32056] [6] DEBUG: SMPP PDU dump ends.
2015-06-23 01:33:00 [32056] [6] DEBUG: SMPP[crs]
handle_pdu, got DLR
2015-06-23 01:33:00 [32056] [6] DEBUG: DLR[internal]:
Looking for
DLR smsc=crs, ts=5938588514830664, dst=2xxxxxxxxxxx, type=1
2015-06-23 01:33:00 [32056] [6] WARNING: DLR[internal]:
DLR from
SMSC<crs> for DST<2xxxxxxxxxxx> not found.
2015-06-23 01:33:00 [32056] [6] ERROR: SMPP[crs]: got DLR but
could not find message or was not interested in it
id<5938588514830664> dst<2xxxxxxxxxxx>, type<1>
2015-06-23 01:33:00 [32056] [6] DEBUG: SMPP[crs]: Sending PDU:
2015-06-23 01:33:00 [32056] [6] DEBUG: SMPP PDU
0x7fceb00016e0 dump:
2015-06-23 01:33:00 [32056] [6] DEBUG: type_name:
deliver_sm_resp
2015-06-23 01:33:00 [32056] [6] DEBUG: command_id: 2147483653
<tel:2147483653> = 0x80000005
2015-06-23 01:33:00 [32056] [6] DEBUG: command_status: 0 =
0x00000000
2015-06-23 01:33:00 [32056] [6] DEBUG: sequence_number: 2 =
0x00000002
2015-06-23 01:33:00 [32056] [6] DEBUG: message_id: NULL
2015-06-23 01:33:00 [32056] [6] DEBUG: SMPP PDU dump ends.
2015-06-23 01:33:00 [32056] [6] DEBUG: SMPP[crs]: throughput
(0.00,0.00)
2015-06-23 01:33:03 [32056] [9] DEBUG: boxc_receiver: sms
received
2015-06-23 01:33:03 [32056] [9] DEBUG: send_msg: sending
msg to
boxc: <sqlbox>
2015-06-23 01:33:03 [32056] [6] DEBUG: SMPP[crs]: throughput
(0.00,0.00)
2015-06-23 01:33:03 [32056] [6] DEBUG: SMPP[crs]: Manually
forced
source addr ton = 5, source add npi = 0
2015-06-23 01:33:03 [32056] [6] DEBUG: SMPP[crs]: Manually
forced
dest addr ton = 1, dest add npi = 1
