Thank you very much :)

On Tue, May 26, 2009 at 11:52 AM, Alejandro Guerrieri <
[email protected]> wrote:

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


-- 
Sincerely,
Sayed Hadi Rastgou Haghi

http://www.ubuntu.com

Reply via email to