Hi, Thanks for your response but in situation where I use concatenation = true, it should be understood that I am only interested in the first report with actual NACK/xxx value.
Also, in this case only one dlr is pending, which is one complete long message. whats do you say? On Mar 7, 2012 6:21 PM, "Alexander Malysh" <amal...@kannel.org> wrote: > 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 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 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&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 > > >
