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 >
