Hi, there is not enough infos to understand what’s going wrong.
Please post submit_sm to this failing DLR then we at least will see what happened. Thanks, Alex > Am 15.08.2015 um 18:57 schrieb Moazzam <moz...@gmail.com>: > > 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 >> >> >> >> >> >> > >
