One possible solution is not to let Kannel handle multiple-part messages but do it yourself.
So instead of passing one long message to Kannel, you split the message up in multiple parts and send the different parts to Kannel (including UDH). Each with a different DLR url. This way, you will get a failure message per message part. == Rene From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Alexander Malysh Sent: Wednesday, 07 March, 2012 13:51 To: Ashish Agarwal Cc: users@kannel.org Subject: Re: NACK reporting help Hi, this is not easy to fix because you send only one but long message and awaiting only one DLR. BUT kannel splits message into peaces for you and receive two DLRs. How would you put both reason codes into one DLR? In you case that would be easy because they both equal but what do you do if not? Thanks, Alex Am 06.03.2012 um 12:20 schrieb Ashish Agarwal: Hello All, Any update on the below query. On Wed, Feb 22, 2012 at 5:59 PM, Ashish Agarwal <ashisha...@gmail.com> wrote: Hello, I have been using kannel for over 2 years now and I am currently using the latest 1.5 version of kannel. I have come across an issue with NACK reports generated for messages that fails or are rejected by the smsc. I have the following problem:- As per the PDU user receives the command_status: 1153 = 0x00000481 from the smsc but the kannel esme does not interpret it correctly. e.g. 2012-02-22 17:24:31 FAILED Send SMS [SMSC:XXXX] [SVC:XXXX] [ACT:XXX] [BINF:] [FID:] [META:] [from:XXX] [to:XXXXXXX] [flags:-1:0:-1:-1:19] [msg:185:1..Create a basic account (Pictorial Representation)..Create a FREE basic account on kareeredge.com <http://kareeredge.com/> and start searching and applying for jobs through your personal dashboard right away.] [udh:0:] 2012-02-22 17:24:31 Receive DLR [SMSC:XXX] [SVC:XXXX] [ACT:] [BINF:] [FID:] [META:] [from:XXXX] [to:XXXXXXX] [flags:-1:-1:-1:-1:16] [msg:5:NACK/] [udh:0:] As you see NACK/ should contain NACK/0x00000481. I have tried this with multiple cases and have found out that when esme submits more than 160 characters of message and the message is rejected by the smppbox we do not receive the NACK report correctly whereas when message text is less than 160 characters esme receive the report correctly as below:- 2012-02-22 17:23:10 FAILED Send SMS [SMSC:XXXX] [SVC:XXXX] [ACT:XXX] [BINF:] [FID:] [META:] [from:XXXX] [to:XXXX] [flags:-1:0:-1:-1:19] [msg:75:Dear This is remind to u that,Please sms to 56767 to get more products Free] [udh:0:] 2012-02-22 17:23:10 Receive DLR [SMSC:SIP11] [SVC:smssip1] [ACT:] [BINF:] [FID:] [META:] [from:INFINI] [to:919900000147] [flags:-1:-1:-1:-1:16] [msg:73:NACK/0x00000481/Vendor-specific error, please refer to your SMPP provider] [udh:0:] Also %A value in dlr-url gives the same output as mentioned above, because of which we are not able to trace the exact reason for the sms failure in case of sms text more than 160 characters. For supporting also find the pdu dump of the message text of 185 characters:- 2012-02-22 17:24:31 [6329] [15] DEBUG: boxc_receiver: sms received 2012-02-22 17:24:31 [6329] [15] DEBUG: new split_parts created 0x2aaab4135f70 2012-02-22 17:24:31 [6329] [15] DEBUG: send_msg: sending msg to boxc: <sqlbox> 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (0.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: Sending PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm 2012-02-22 17:24:31 [6329] [8] DEBUG: command_id: 4 = 0x00000004 2012-02-22 17:24:31 [6329] [8] DEBUG: command_status: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: sequence_number: 192708 = 0x0002f0c4 2012-02-22 17:24:31 [6329] [8] DEBUG: service_type: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_ton: 5 = 0x00000005 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_npi: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr: "XXX" 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_ton: 2 = 0x00000002 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_npi: 1 = 0x00000001 2012-02-22 17:24:31 [6329] [8] DEBUG: destination_addr: "XXXXXXXXXX" 2012-02-22 17:24:31 [6329] [8] DEBUG: esm_class: 67 = 0x00000043 2012-02-22 17:24:31 [6329] [8] DEBUG: protocol_id: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: priority_flag: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: schedule_delivery_time: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: validity_period: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: registered_delivery: 1 = 0x00000001 2012-02-22 17:24:31 [6329] [8] DEBUG: replace_if_present_flag: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: data_coding: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: sm_default_msg_id: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: sm_length: 159 = 0x0000009f 2012-02-22 17:24:31 [6329] [8] DEBUG: short_message: 2012-02-22 17:24:31 [6329] [8] DEBUG: Octet string at 0x2aaab4172160: 2012-02-22 17:24:31 [6329] [8] DEBUG: len: 159 2012-02-22 17:24:31 [6329] [8] DEBUG: size: 1024 2012-02-22 17:24:31 [6329] [8] DEBUG: immutable: 0 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 05 00 03 90 02 01 31 2e 3f 43 72 65 61 74 65 20 ......1.?Create 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 61 20 62 61 73 69 63 20 61 63 63 6f 75 6e 74 20 a basic account 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 28 50 69 63 74 6f 72 69 61 6c 20 52 65 70 72 65 (Pictorial Repre 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 73 65 6e 74 61 74 69 6f 6e 29 0d 0a 43 72 65 61 sentation)..Crea 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 74 65 20 61 20 46 52 45 45 20 62 61 73 69 63 20 te a FREE basic 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 61 63 63 6f 75 6e 74 20 6f 6e 20 6b 61 72 65 65 account on karee 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 72 65 64 67 65 2e 63 6f 6d 20 61 6e 64 20 73 74 redge.com <http://redge.com/> and st 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 61 72 74 20 73 65 61 72 63 68 69 6e 67 20 61 6e art searching an 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 64 20 61 70 70 6c 79 69 6e 67 20 66 6f 72 20 6a d applying for j 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 6f 62 73 20 74 68 72 6f 75 67 68 20 79 6f 75 obs through you 2012-02-22 17:24:31 [6329] [8] DEBUG: Octet string dump ends. 2012-02-22 17:24:31 [6329] [8] DEBUG: more_messages_to_send: 1 = 0x00000001 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU dump ends. 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (1.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: Sending PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm 2012-02-22 17:24:31 [6329] [8] DEBUG: command_id: 4 = 0x00000004 2012-02-22 17:24:31 [6329] [8] DEBUG: command_status: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: sequence_number: 192709 = 0x0002f0c5 2012-02-22 17:24:31 [6329] [8] DEBUG: service_type: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_ton: 5 = 0x00000005 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr_npi: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: source_addr: "XXX" 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_ton: 2 = 0x00000002 2012-02-22 17:24:31 [6329] [8] DEBUG: dest_addr_npi: 1 = 0x00000001 2012-02-22 17:24:31 [6329] [8] DEBUG: destination_addr: "XXXXXXXXXX" 2012-02-22 17:24:31 [6329] [8] DEBUG: esm_class: 67 = 0x00000043 2012-02-22 17:24:31 [6329] [8] DEBUG: protocol_id: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: priority_flag: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: schedule_delivery_time: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: validity_period: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: registered_delivery: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: replace_if_present_flag: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: data_coding: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: sm_default_msg_id: 0 = 0x00000000 2012-02-22 17:24:31 [6329] [8] DEBUG: sm_length: 38 = 0x00000026 2012-02-22 17:24:31 [6329] [8] DEBUG: short_message: 2012-02-22 17:24:31 [6329] [8] DEBUG: Octet string at 0x2aaab4139270: 2012-02-22 17:24:31 [6329] [8] DEBUG: len: 38 2012-02-22 17:24:31 [6329] [8] DEBUG: size: 1024 2012-02-22 17:24:31 [6329] [8] DEBUG: immutable: 0 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 05 00 03 90 02 02 72 20 70 65 72 73 6f 6e 61 6c ......r personal 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 20 64 61 73 68 62 6f 61 72 64 20 72 69 67 68 74 dashboard right 2012-02-22 17:24:31 [6329] [8] DEBUG: data: 20 61 77 61 79 2e away. 2012-02-22 17:24:31 [6329] [8] DEBUG: Octet string dump ends. 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU dump ends. 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (2.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (2.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: Got PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm_resp 2012-02-22 17:24:31 [6329] [8] DEBUG: command_id: 2147483652 = 0x80000004 2012-02-22 17:24:31 [6329] [8] DEBUG: command_status: 1153 = 0x00000481 2012-02-22 17:24:31 [6329] [8] DEBUG: sequence_number: 192708 = 0x0002f0c4 2012-02-22 17:24:31 [6329] [8] DEBUG: message_id: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU dump ends. 2012-02-22 17:24:31 [6329] [8] ERROR: SMPP[XXXX]: SMSC returned error code 0x00000481 (Vendor-specific error, please refer to your SMPP provider) in response to submit_sm. 2012-02-22 17:24:31 [6329] [8] DEBUG: Set split msg status to 3 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (2.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (2.00,0.00) 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: Got PDU: 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU 0x2aaab413ee00 dump: 2012-02-22 17:24:31 [6329] [8] DEBUG: type_name: submit_sm_resp 2012-02-22 17:24:31 [6329] [8] DEBUG: command_id: 2147483652 = 0x80000004 2012-02-22 17:24:31 [6329] [8] DEBUG: command_status: 1153 = 0x00000481 2012-02-22 17:24:31 [6329] [8] DEBUG: sequence_number: 192709 = 0x0002f0c5 2012-02-22 17:24:31 [6329] [8] DEBUG: message_id: NULL 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP PDU dump ends. 2012-02-22 17:24:31 [6329] [8] ERROR: SMPP[XXXX]: SMSC returned error code 0x00000481 (Vendor-specific error, please refer to your SMPP provider) in response to submit_sm. 2012-02-22 17:24:31 [6329] [8] DEBUG: Set split msg status to 3 2012-02-22 17:24:31 [6329] [8] DEBUG: Parts of concatenated message failed. 2012-02-22 17:24:31 [6329] [8] DEBUG: SMSC[XXXX]: creating DLR message 2012-02-22 17:24:31 [6329] [8] DEBUG: SMSC[XXXX]: DLR = http://XX.XX.XX.XX/apps/report1/dlr.php?status=%A <http://XX.XX.XX.XX/apps/report1/dlr.php?status=%25A&type=%25d&id=27-1&smsci d=%25i> &type=%d&id=27-1&smscid=%i 2012-02-22 17:24:31 [6329] [8] DEBUG: SMPP[XXXX]: throughput (2.00,0.00) 2012-02-22 17:24:31 [6329] [18] DEBUG: send_msg: sending msg to boxc: <smsbox> 2012-02-22 17:24:31 [6329] [18] DEBUG: boxc_sender: sent message to <127.0.0.1> 2012-02-22 17:24:31 [6329] [17] DEBUG: boxc_receiver: got ack 2012-02-22 17:24:34 [6329] [17] DEBUG: boxc_receiver: heartbeat with load value 0 received I think it is a bug with smsbox. Please help. -- Regards, Ashish -- Regards, Ashish Agarwal
