Hi,
it works!
Quite like before (parsing the old way), with one more debug line:
"SMPP[wams]: Partial SMPP v3.4, receipted_message_id present but not
message_state."
Thanks a lot.
Here is the debug log, in case you want to verify it is as you expected:
2009-04-01 09:21:31 [6724] [6] DEBUG: Optional parameter tag (0x0423)
2009-04-01 09:21:31 [6724] [6] DEBUG: Optional parameter length read as 3
2009-04-01 09:21:31 [6724] [6] DEBUG: Optional parameter tag (0x001e)
2009-04-01 09:21:31 [6724] [6] DEBUG: Optional parameter length read as 24
2009-04-01 09:21:31 [6724] [6] DEBUG: SMPP[wams]: Got PDU:
2009-04-01 09:21:31 [6724] [6] DEBUG: SMPP PDU 0x945b340 dump:
2009-04-01 09:21:31 [6724] [6] DEBUG: type_name: deliver_sm
2009-04-01 09:21:31 [6724] [6] DEBUG: command_id: 5 = 0x00000005
2009-04-01 09:21:31 [6724] [6] DEBUG: command_status: 0 = 0x00000000
2009-04-01 09:21:31 [6724] [6] DEBUG: sequence_number: 2 = 0x00000002
2009-04-01 09:21:31 [6724] [6] DEBUG: service_type: NULL
2009-04-01 09:21:31 [6724] [6] DEBUG: source_addr_ton: 0 = 0x00000000
2009-04-01 09:21:31 [6724] [6] DEBUG: source_addr_npi: 0 = 0x00000000
2009-04-01 09:21:31 [6724] [6] DEBUG: source_addr: "orig_phone"
2009-04-01 09:21:31 [6724] [6] DEBUG: dest_addr_ton: 0 = 0x00000000
2009-04-01 09:21:31 [6724] [6] DEBUG: dest_addr_npi: 0 = 0x00000000
2009-04-01 09:21:31 [6724] [6] DEBUG: destination_addr: "dest_phone"
2009-04-01 09:21:31 [6724] [6] DEBUG: esm_class: 4 = 0x00000004
2009-04-01 09:21:31 [6724] [6] DEBUG: protocol_id: 0 = 0x00000000
2009-04-01 09:21:31 [6724] [6] DEBUG: priority_flag: 0 = 0x00000000
2009-04-01 09:21:31 [6724] [6] DEBUG: schedule_delivery_time: NULL
2009-04-01 09:21:31 [6724] [6] DEBUG: validity_period: NULL
2009-04-01 09:21:31 [6724] [6] DEBUG: registered_delivery: 0 = 0x00000000
2009-04-01 09:21:31 [6724] [6] DEBUG: replace_if_present_flag: 0 = 0x00000000
2009-04-01 09:21:31 [6724] [6] DEBUG: data_coding: 0 = 0x00000000
2009-04-01 09:21:31 [6724] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000
2009-04-01 09:21:31 [6724] [6] DEBUG: sm_length: 92 = 0x0000005c
2009-04-01 09:21:31 [6724] [6] DEBUG: short_message:
2009-04-01 09:21:31 [6724] [6] DEBUG: Octet string at 0x9459168:
2009-04-01 09:21:31 [6724] [6] DEBUG: len: 92
2009-04-01 09:21:31 [6724] [6] DEBUG: size: 93
2009-04-01 09:21:31 [6724] [6] DEBUG: immutable: 0
2009-04-01 09:21:31 [6724] [6] DEBUG: data: 69 64 3a 30 39 30 34 30 31 31
31 32 31 32 36 33 id:0904011121263
2009-04-01 09:21:31 [6724] [6] DEBUG: data: 33 36 30 38 32 35 39 35 30 36
20 73 75 62 6d 69 3608259506 submi
2009-04-01 09:21:31 [6724] [6] DEBUG: data: 74 20 64 61 74 65 3a 30 39 30
34 30 31 31 31 32 t date:090401112
2009-04-01 09:21:31 [6724] [6] DEBUG: data: 31 20 64 6f 6e 65 20 64 61 74
65 3a 30 39 30 34 1 done date:0904
2009-04-01 09:21:31 [6724] [6] DEBUG: data: 30 31 31 31 32 31 20 73 74 61
74 3a 44 45 4c 49 011121 stat:DELI
2009-04-01 09:21:31 [6724] [6] DEBUG: data: 56 52 44 20 65 72 72 3a 30 30
30 20 VRD err:000
2009-04-01 09:21:31 [6724] [6] DEBUG: Octet string dump ends.
2009-04-01 09:21:31 [6724] [6] DEBUG: network_error_code:
2009-04-01 09:21:31 [6724] [6] DEBUG: Octet string at 0x9459180:
2009-04-01 09:21:31 [6724] [6] DEBUG: len: 3
2009-04-01 09:21:31 [6724] [6] DEBUG: size: 4
2009-04-01 09:21:31 [6724] [6] DEBUG: immutable: 0
2009-04-01 09:21:31 [6724] [6] DEBUG: data: 03 00 00
...
2009-04-01 09:21:31 [6724] [6] DEBUG: Octet string dump ends.
2009-04-01 09:21:31 [6724] [6] DEBUG: receipted_message_id:
2009-04-01 09:21:31 [6724] [6] DEBUG: Octet string at 0x9454290:
2009-04-01 09:21:31 [6724] [6] DEBUG: len: 23
2009-04-01 09:21:31 [6724] [6] DEBUG: size: 24
2009-04-01 09:21:31 [6724] [6] DEBUG: immutable: 0
2009-04-01 09:21:31 [6724] [6] DEBUG: data: 30 39 30 34 30 31 31 31 32 31
32 36 33 33 36 30 0904011121263360
2009-04-01 09:21:31 [6724] [6] DEBUG: data: 38 32 35 39 35 30 36
8259506
2009-04-01 09:21:31 [6724] [6] DEBUG: Octet string dump ends.
2009-04-01 09:21:31 [6724] [6] DEBUG: SMPP PDU dump ends.
2009-04-01 09:21:31 [6724] [6] DEBUG: SMPP[wams] handle_pdu, got DLR
2009-04-01 09:21:31 [6724] [6] DEBUG: SMPP[wams]: Partial SMPP v3.4,
receipted_message_id present but not message_state.
2009-04-01 09:21:31 [6724] [6] DEBUG: SMPP[wams]: Couldnot parse DLR string
sscanf way,fallback to old way. Please report!
If you want me to do some specific tests, feel free to ask.
-
Hervé Nicol
Le mercredi 01 avril 2009 à 10:44 +0200, Alexander Malysh a écrit :
> 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é
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>
> >
> >
>
