I got CVS version, and it works well 2009-05-26 12:12:12 Receive DLR [SMSC:xxx] [SVC:lkjhfld] [ACT:] [BINF:] [FID:4294967295] [META:?smpp?dlr_err=000&] [from:test] [to:xxx] [flags:-1:-1:-1:-1:1] [msg:93:id:090526121207989121879130 submit date:0905261212 done date:0905261212 stat:DELIVRD err:000 ] [udh:0:]
On Tue, May 26, 2009 at 10:11 AM, Alejandro Guerrieri < [email protected]> wrote: > Well, firsthand, the dlr format doesn't seen to be the standard: > > id:090526082107989121879130 submit date:0905260821 done date:0905260821 > stat:DELIVRD err:000 > > > Kannel expects: > > > id:%64[^s] sub:%d dlvrd:%d submit date:%14[0-9] done date:%14[0-9] > stat:%10[^t^e] > err:%3[^t] > > > Notice "sub" and "dlvrd" fields are missing between "id" and "submit date". > > Kannel should be able to handle this (perhaps there's some debug entry > after the PDU with something like > > "SMPP[XXXXXX]: Couldnot parse DLR string sscanf way, fallback to old way. > Please report!" > > Can you give a shot with latest CVS? It's as stable as 1.4.3 and have some > dlr's fixups in place. > > Regards, > > Alejandro > > On Tue, May 26, 2009 at 6:20 AM, Sayed Hadi Rastgou Haghi < > [email protected]> wrote: > >> thanks >> I tested both 1.4.1, and 1.4.3 and both had same results. >> >> 2009-05-26 08:21:12 [10283] [6] DEBUG: SMPP[xxxx]: Got PDU: >> 2009-05-26 08:21:12 [10283] [6] DEBUG: SMPP PDU 0x81aec50 dump: >> 2009-05-26 08:21:12 [10283] [6] DEBUG: type_name: deliver_sm >> 2009-05-26 08:21:12 [10283] [6] DEBUG: command_id: 5 = 0x00000005 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: command_status: 0 = 0x00000000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: sequence_number: 2 = 0x00000002 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: service_type: NULL >> 2009-05-26 08:21:12 [10283] [6] DEBUG: source_addr_ton: 0 = 0x00000000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: source_addr_npi: 0 = 0x00000000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: source_addr: "xxxxx" >> 2009-05-26 08:21:12 [10283] [6] DEBUG: dest_addr_ton: 0 = 0x00000000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: dest_addr_npi: 0 = 0x00000000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: destination_addr: NULL >> 2009-05-26 08:21:12 [10283] [6] DEBUG: esm_class: 4 = 0x00000004 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: protocol_id: 0 = 0x00000000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: priority_flag: 0 = 0x00000000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: schedule_delivery_time: NULL >> 2009-05-26 08:21:12 [10283] [6] DEBUG: validity_period: NULL >> 2009-05-26 08:21:12 [10283] [6] DEBUG: registered_delivery: 0 = >> 0x00000000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: replace_if_present_flag: 0 = >> 0x00000000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: data_coding: 0 = 0x00000000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: sm_length: 93 = 0x0000005d >> 2009-05-26 08:21:12 [10283] [6] DEBUG: short_message: >> 2009-05-26 08:21:12 [10283] [6] DEBUG: Octet string at 0x81b0ad0: >> 2009-05-26 08:21:12 [10283] [6] DEBUG: len: 93 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: size: 94 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: immutable: 0 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: data: 69 64 3a 30 39 30 35 32 >> 36 30 38 32 31 30 37 39 id:0905260821079 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: data: 38 39 31 32 31 38 37 39 >> 31 33 30 20 73 75 62 6d 89121879130 subm >> 2009-05-26 08:21:12 [10283] [6] DEBUG: data: 69 74 20 64 61 74 65 3a >> 30 39 30 35 32 36 30 38 it date:09052608 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: data: 32 31 20 64 6f 6e 65 20 >> 64 61 74 65 3a 30 39 30 21 done date:090 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: data: 35 32 36 30 38 32 31 20 >> 73 74 61 74 3a 44 45 4c 5260821 stat:DEL >> 2009-05-26 08:21:12 [10283] [6] DEBUG: data: 49 56 52 44 20 65 72 72 >> 3a 30 30 30 20 IVRD err:000 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: Octet string dump ends. >> 2009-05-26 08:21:12 [10283] [6] DEBUG: network_error_code: >> 2009-05-26 08:21:12 [10283] [6] DEBUG: Octet string at 0x81b0fb8: >> 2009-05-26 08:21:12 [10283] [6] DEBUG: len: 3 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: size: 4 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: immutable: 0 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: data: 03 00 00 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: Octet string dump ends. >> 2009-05-26 08:21:12 [10283] [6] DEBUG: receipted_message_id: >> 2009-05-26 08:21:12 [10283] [6] DEBUG: Octet string at 0x81b0f88: >> 2009-05-26 08:21:12 [10283] [6] DEBUG: len: 24 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: size: 25 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: immutable: 0 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: data: 30 39 30 35 32 36 30 38 >> 32 31 30 37 39 38 39 31 0905260821079891 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: data: 32 31 38 37 39 31 33 >> 30 21879130 >> 2009-05-26 08:21:12 [10283] [6] DEBUG: Octet string dump ends. >> 2009-05-26 08:21:12 [10283] [6] DEBUG: SMPP PDU dump ends. >> >> >> >> On Mon, May 25, 2009 at 5:59 PM, Alejandro Guerrieri < >> [email protected]> wrote: >> >>> Sayed, >>> Which Kannel version are you using? >>> >>> Also, please put log-level in 0 and paste the complete deliver_sm PDU for >>> the DLR. >>> >>> Regards, >>> >>> On Mon, May 25, 2009 at 3:29 PM, Sayed Hadi Rastgou Haghi < >>> [email protected]> wrote: >>> >>>> Hi >>>> In access.log >>>> I get this >>>> >>>> 2009-05-25 17:13:50 Receive DLR [SMSC:xxx] [SVC:xxx] [ACT:] [BINF:] >>>> [FID:xxx] [from:xxx] [to:xxx] [flags:-1:-1:-1:-1:*2*] >>>> [msg:93:id:0905... submit date:0905251713 done date:0905251713 * >>>> stat:DELIVRD* err:000 ] [udh:0:] >>>> >>>> as you can see, the delivery flag is set to *2* but in delivery message >>>> you can see *stat:DELIVRD. >>>> >>>> *How can I cover this? >>>> can I force kannel to parse delivery smsc report and get message status >>>> from it? >>>> >>>> -- >>>> Sincerely, >>>> Sayed Hadi Rastgou Haghi >>>> >>>> http://www.ubuntu.com >>>> >>> >>> >> >> >> -- >> Sincerely, >> Sayed Hadi Rastgou Haghi >> >> http://www.ubuntu.com >> > > -- Sincerely, Sayed Hadi Rastgou Haghi http://www.ubuntu.com
