Yeah, makes sense. CVS is much smarter on non-standard dlr's.
Glad it helped :)

Regards,

Alejandro

On Tue, May 26, 2009 at 9:45 AM, Sayed Hadi Rastgou Haghi <
[email protected]> wrote:

> 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
>

Reply via email to