Re: DLR with SMPP and CIMD2, Validity with CIMD2

Hi,

please try current CVS, it should be fixed now.

Thanks,
Alex

Am 01.04.2009 um 10:04 schrieb Hervé Nicol:

>
> Hello,
>
> I don't know much about TLVs, but from my understanding these are
> optional parameters.
> So, if I follow you, in this example kannel receives some
> (network_error_code and receipted_message_id), but it's not enough for
> determining the status.
> If ever it does not receive any TLV, Kannel will parse the SMS for the
> status, which will actually work.
>
> So, maybe a fallback to SMS parsing when TLV analysis fails would be a
> workaround?
>
> Thanks for your interest.
>
> -
> Hervé
>
>
>
> Le mardi 31 mars 2009 à 19:11 +0200, Alexander Malysh a écrit :
>> Hi,
>>
>> seems your SMSC operator put only partial TLVs for DLRs.
>> This is easy to fix... I will look into it...
>>
>> Am 31.03.2009 um 16:35 schrieb Hervé Nicol:
>>
>>>
>>> Of course,
>>>
>>> here is a "DELIVRD" DLR PDU as shown in bearerbox.log :
>>>
>>> 2009-03-31 14:22:22.662338 [11214] [6] DEBUG: Optional parameter tag
>>> (0x0423)
>>> 2009-03-31 14:22:22.662377 [11214] [6] DEBUG: Optional parameter
>>> length read as 3
>>> 2009-03-31 14:22:22.662400 [11214] [6] DEBUG: Optional parameter tag
>>> (0x001e)
>>> 2009-03-31 14:22:22.662409 [11214] [6] DEBUG: Optional parameter
>>> length read as 24
>>> 2009-03-31 14:22:22.662419 [11214] [6] DEBUG: SMPP[wams]: Got PDU:
>>> 2009-03-31 14:22:22.662429 [11214] [6] DEBUG: SMPP PDU 0x8ebf158  
>>> dump:
>>> 2009-03-31 14:22:22.662437 [11214] [6] DEBUG:   type_name:  
>>> deliver_sm
>>> 2009-03-31 14:22:22.662445 [11214] [6] DEBUG:   command_id: 5 =
>>> 0x00000005
>>> 2009-03-31 14:22:22.662453 [11214] [6] DEBUG:   command_status: 0 =
>>> 0x00000000
>>> 2009-03-31 14:22:22.662461 [11214] [6] DEBUG:   sequence_number: 2 =
>>> 0x00000002
>>> 2009-03-31 14:22:22.662469 [11214] [6] DEBUG:   service_type: NULL
>>> 2009-03-31 14:22:22.662477 [11214] [6] DEBUG:   source_addr_ton: 0 =
>>> 0x00000000
>>> 2009-03-31 14:22:22.662484 [11214] [6] DEBUG:   source_addr_npi: 0 =
>>> 0x00000000
>>> 2009-03-31 14:22:22.662492 [11214] [6] DEBUG:   source_addr:
>>> "dest_phone"
>>> 2009-03-31 14:22:22.662500 [11214] [6] DEBUG:   dest_addr_ton: 0 =
>>> 0x00000000
>>> 2009-03-31 14:22:22.662508 [11214] [6] DEBUG:   dest_addr_npi: 0 =
>>> 0x00000000
>>> 2009-03-31 14:22:22.662516 [11214] [6] DEBUG:   destination_addr:
>>> "origin_phone"
>>> 2009-03-31 14:22:22.662523 [11214] [6] DEBUG:   esm_class: 4 =
>>> 0x00000004
>>> 2009-03-31 14:22:22.662536 [11214] [6] DEBUG:   protocol_id: 0 =
>>> 0x00000000
>>> 2009-03-31 14:22:22.662548 [11214] [6] DEBUG:   priority_flag: 0 =
>>> 0x00000000
>>> 2009-03-31 14:22:22.662555 [11214] [6] DEBUG:
>>> schedule_delivery_time: NULL
>>> 2009-03-31 14:22:22.662563 [11214] [6] DEBUG:   validity_period:  
>>> NULL
>>> 2009-03-31 14:22:22.662570 [11214] [6] DEBUG:   registered_delivery:
>>> 0 = 0x00000000
>>> 2009-03-31 14:22:22.662596 [11214] [6] DEBUG:
>>> replace_if_present_flag: 0 = 0x00000000
>>> 2009-03-31 14:22:22.662604 [11214] [6] DEBUG:   data_coding: 0 =
>>> 0x00000000
>>> 2009-03-31 14:22:22.662612 [11214] [6] DEBUG:   sm_default_msg_id: 0
>>> = 0x00000000
>>> 2009-03-31 14:22:22.662620 [11214] [6] DEBUG:   sm_length: 92 =
>>> 0x0000005c
>>> 2009-03-31 14:22:22.662627 [11214] [6] DEBUG:   short_message:
>>> 2009-03-31 14:22:22.662636 [11214] [6] DEBUG:    Octet string at
>>> 0x8ec28c0:
>>> 2009-03-31 14:22:22.662644 [11214] [6] DEBUG:      len:  92
>>> 2009-03-31 14:22:22.662651 [11214] [6] DEBUG:      size: 93
>>> 2009-03-31 14:22:22.662659 [11214] [6] DEBUG:      immutable: 0
>>> 2009-03-31 14:22:22.662671 [11214] [6] DEBUG:      data: 69 64 3a 30
>>> 39 30 33 33 31 31 36 32 32 31 37 33   id:0903311622173
>>> 2009-03-31 14:22:22.662682 [11214] [6] DEBUG:      data: 33 36 30 38
>>> 32 35 39 35 30 36 20 73 75 62 6d 69   3608259506 submi
>>> 2009-03-31 14:22:22.662694 [11214] [6] DEBUG:      data: 74 20 64 61
>>> 74 65 3a 30 39 30 33 33 31 31 36 32   t date:090331162
>>> 2009-03-31 14:22:22.662705 [11214] [6] DEBUG:      data: 32 20 64 6f
>>> 6e 65 20 64 61 74 65 3a 30 39 30 33   2 done date:0903
>>> 2009-03-31 14:22:22.662717 [11214] [6] DEBUG:      data: 33 31 31 36
>>> 32 32 20 73 74 61 74 3a 44 45 4c 49   311622 stat:DELI
>>> 2009-03-31 14:22:22.662727 [11214] [6] DEBUG:      data: 56 52 44 20
>>> 65 72 72 3a 30 30 30 20               VRD err:000
>>> 2009-03-31 14:22:22.662735 [11214] [6] DEBUG:    Octet string dump
>>> ends.
>>> 2009-03-31 14:22:22.662743 [11214] [6] DEBUG:   network_error_code:
>>> 2009-03-31 14:22:22.662751 [11214] [6] DEBUG:    Octet string at
>>> 0x8ec1858:
>>> 2009-03-31 14:22:22.662758 [11214] [6] DEBUG:      len:  3
>>> 2009-03-31 14:22:22.662766 [11214] [6] DEBUG:      size: 4
>>> 2009-03-31 14:22:22.662773 [11214] [6] DEBUG:      immutable: 0
>>> 2009-03-31 14:22:22.662782 [11214] [6] DEBUG:      data: 03 00
>>> 00                                          ...
>>> 2009-03-31 14:22:22.662790 [11214] [6] DEBUG:    Octet string dump
>>> ends.
>>> 2009-03-31 14:22:22.662797 [11214] [6] DEBUG:    
>>> receipted_message_id:
>>> 2009-03-31 14:22:22.662805 [11214] [6] DEBUG:    Octet string at
>>> 0x8ebf3c8:
>>> 2009-03-31 14:22:22.662812 [11214] [6] DEBUG:      len:  23
>>> 2009-03-31 14:22:22.662820 [11214] [6] DEBUG:      size: 24
>>> 2009-03-31 14:22:22.662827 [11214] [6] DEBUG:      immutable: 0
>>> 2009-03-31 14:22:22.662838 [11214] [6] DEBUG:      data: 30 39 30 33
>>> 33 31 31 36 32 32 31 37 33 33 36 30   0903311622173360
>>> 2009-03-31 14:22:22.662848 [11214] [6] DEBUG:      data: 38 32 35 39
>>> 35 30 36                              8259506
>>> 2009-03-31 14:22:22.662855 [11214] [6] DEBUG:    Octet string dump
>>> ends.
>>> 2009-03-31 14:22:22.662863 [11214] [6] DEBUG: SMPP PDU dump ends.
>>> 2009-03-31 14:22:22.662871 [11214] [6] DEBUG: SMPP[wams] handle_pdu,
>>> got DLR
>>> 2009-03-31 14:22:22.662879 [11214] [6] WARNING: SMPP[wams]: Got DLR
>>> with unknown 'message_state' (-1).
>>>
>>>
>>> Is this the kind of information you meant?
>>>
>>>
>>> Regards,
>>> -- 
>>> Hervé
>>>
>>>
>>>
>>>
>>>
>>> Le mardi 31 mars 2009 à 09:08 -0500, Alvaro Cornejo a écrit :
>>>> Before diving into generate code,  can you provide more info on  
>>>> "dlr
>>>> does not work with SMPP" ??
>>>>
>>>> It might just be a parameter that needs to be adjusted.
>>>>
>>>> Alvaro
>>>>
>>>> |
>>>> -----------------------------------------------------------------------------------------------------------------|
>>>> Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde
>>>> cualquier
>>>> celular y Nextel
>>>> en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias
>>>> via
>>>> SMS y GPRS online
>>>>             Visitenos en www.perusms.NET www.smsglobal.com.mx y
>>>> www.pravcom.com
>>>>
>>>>
>>>>
>>>> On Tue, Mar 31, 2009 at 8:39 AM, Hervé Nicol
>>>> <[email protected]> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>> As I can see in the feature checklist
>>>>> ( http://kannel.org/download/1.4.3/userguide-1.4.3/userguide.html#AEN2386
>>>>> ), it seems that the DLR was not tested with CIMD2 nor with SMPP
>>>>> protocols.
>>>>>
>>>>> I am glad to inform you that I was successfully receiving DLRs
>>>>> with SMPP
>>>>> until my SMS provider recently changed his SMSC.
>>>>> As I was using Kannel 1.4.1, I tried 1.4.3 but behaves exactly the
>>>>> same.
>>>>>
>>>>> I don't have a clear vision of my provider's architecture and
>>>>> software,
>>>>> so I can't say more than:
>>>>> SMPP DLR works on some platforms, but not on all.
>>>>>
>>>>>
>>>>> Currently my aim is to fix things as quickly as possible, so I  
>>>>> won't
>>>>> investigate on why SMPP DLR won't work with the new config.
>>>>> I tested a CIMD2 connexion, and DLR works nice. So I will go for
>>>>> it as a
>>>>> first step.
>>>>> I just have one remark on these DLR: it seems that DLR_BUFFERED
>>>>> status
>>>>> is not supported with CIMD2.
>>>>>
>>>>> However, I wish I could retreive CIMD2 "062:" value as well as
>>>>> "061:" in
>>>>> %A dlr report. That should be the next step. But if one of you
>>>>> have an
>>>>> advice on this, I'd be happy to hear it.
>>>>>
>>>>>
>>>>> Then, one more feature that I tested is the SMS validity.
>>>>> It didn't work with SMPP on 1.4.1 but we had a hmoe-made patch.
>>>>> But with CIMD2 it seems to work well.
>>>>>
>>>>>
>>>>> Thank you for reading,
>>>>> --
>>>>> Hervé
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
>