Re: DLR with SMPP and CIMD2, Validity with CIMD2
Alexander Malysh <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, great. Thanks, Alex Am 01.04.2009 um 11:30 schrieb Hervé Nicol: > 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é >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > >