Re: DLR with SMPP and CIMD2, Validity with CIMD2

Tue, 31 Mar 2009 09:29:09 -0700 

Hi,

This belongs to the users list. You propably need to define a tlv group.

Nikos
----- Original Message ----- From: "Herve Nicol" <[email protected]> 
To: "devel" <[email protected]>
Sent: Tuesday, March 31, 2009 5:35 PM
Subject: Re: DLR with SMPP and CIMD2, Validity with CIMD2




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

Reply via email to