On Mon, 2016-08-22 at 15:33, amal...@kannel.org wrote: > Please check bind , whether you are using SMPP version > 3.3 ?
Maybe I'm wrong but to me it looks like the DLR message (string) from upstream SMPP provider is not formatted according to kannel expectation, or maybe upstream does not send anything in DLR message (I mean text in the DLR and not DLR packet). Just my assumptions. > Thanks, > Alex > > > Am 22.08.2016 um 13:26 schrieb Черепанов Алексей Владиславович > > <sw_cherepa...@motivtelecom.ru>: > > > > Okay, tried SVN version. Seems like the same issue. > > > > > > Kannel bearerbox version `svn-r5172'. > > Build `Aug 22 2016 13:52:19', compiler `4.9.2'. > > System Linux, release 3.16.0-4-amd64, version #1 SMP Debian > > 3.16.7-ckt25-2+deb8u3 (2016-07-02), machine x86_64. > > Libxml version 2.9.1. > > Using OpenSSL 1.0.1t 3 May 2016. > > Using native malloc. > > Status: running, uptime 0d 1h 0m 10s > > WDP: received 0 (0 queued), sent 0 (0 queued) > > SMS: received 0 (0 queued), sent 3 (0 queued), store size 0 > > SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.02,0.00,0.00) msg/sec > > DLR: received 0, sent 0 > > DLR: inbound (0.00,0.00,0.00) msg/sec, outbound (0.00,0.00,0.00) msg/sec > > DLR: 3 queued, using internal storage > > > > 2016-08-22 16:14:48 [18226] [6] DEBUG: SMPP[SMSC]: Got PDU: > > 2016-08-22 16:14:48 [18226] [6] DEBUG: SMPP PDU 0x7fa2080029c0 dump: > > 2016-08-22 16:14:48 [18226] [6] DEBUG: type_name: submit_sm_resp > > 2016-08-22 16:14:48 [18226] [6] DEBUG: command_id: 2147483652 = 0x80000004 > > 2016-08-22 16:14:48 [18226] [6] DEBUG: command_status: 0 = 0x00000000 > > 2016-08-22 16:14:48 [18226] [6] DEBUG: sequence_number: 16 = 0x00000010 > > 2016-08-22 16:14:48 [18226] [6] DEBUG: message_id: "13F19886" > > 2016-08-22 16:14:48 [18226] [6] DEBUG: SMPP PDU dump ends. > > 2016-08-22 16:14:48 [18226] [6] DEBUG: DLR[internal]: Adding DLR smsc=SMSC, > > ts=334600326, src=3432690000, dst=79028710256, mask=7, boxc=smsbox-web > > > > 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP[SMSC]: Got PDU: > > 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP PDU 0x7fa208002da0 dump: > > 2016-08-22 16:14:53 [18226] [6] DEBUG: type_name: deliver_sm > > 2016-08-22 16:14:53 [18226] [6] DEBUG: command_id: 5 = 0x00000005 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: command_status: 0 = 0x00000000 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: sequence_number: 731929910 = > > 0x2ba05d36 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: service_type: NULL > > 2016-08-22 16:14:53 [18226] [6] DEBUG: source_addr_ton: 1 = 0x00000001 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: source_addr_npi: 1 = 0x00000001 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: source_addr: "79028710256" > > 2016-08-22 16:14:53 [18226] [6] DEBUG: dest_addr_ton: 1 = 0x00000001 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: dest_addr_npi: 1 = 0x00000001 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: destination_addr: "3432690000" > > 2016-08-22 16:14:53 [18226] [6] DEBUG: esm_class: 4 = 0x00000004 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: protocol_id: 127 = 0x0000007f > > 2016-08-22 16:14:53 [18226] [6] DEBUG: priority_flag: 0 = 0x00000000 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: schedule_delivery_time: NULL > > 2016-08-22 16:14:53 [18226] [6] DEBUG: validity_period: NULL > > 2016-08-22 16:14:53 [18226] [6] DEBUG: registered_delivery: 0 = 0x00000000 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: replace_if_present_flag: 0 = > > 0x00000000 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: data_coding: 0 = 0x00000000 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: sm_length: 0 = 0x00000000 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: short_message: "" > > 2016-08-22 16:14:53 [18226] [6] DEBUG: source_subaddress: > > 2016-08-22 16:14:53 [18226] [6] DEBUG: Octet string at 0x7fa208002a60: > > 2016-08-22 16:14:53 [18226] [6] DEBUG: len: 12 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: size: 13 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: immutable: 0 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: data: a0 37 39 30 32 38 37 31 > > 30 30 39 39 .79028710099 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: Octet string dump ends. > > 2016-08-22 16:14:53 [18226] [6] DEBUG: network_error_code: > > 2016-08-22 16:14:53 [18226] [6] DEBUG: Octet string at 0x7fa208003570: > > 2016-08-22 16:14:53 [18226] [6] DEBUG: len: 3 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: size: 4 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: immutable: 0 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: data: 03 00 00 > > ... > > 2016-08-22 16:14:53 [18226] [6] DEBUG: Octet string dump ends. > > 2016-08-22 16:14:53 [18226] [6] DEBUG: message_state: 2 = 0x00000002 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: receipted_message_id: "13F19886" > > 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP PDU dump ends. > > 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP[SMSC] handle_pdu, got DLR > > 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP[SMSC]: Could not parse DLR > > string sscanf way, fallback to old way. Please report! > > 2016-08-22 16:14:53 [18226] [6] ERROR: SMPP[SMSC]: got DLR but could not > > find message or was not interested in it id<> dst<79028710256>, type<2> > > > > > > > > > > 22.08.2016 12:58, amal...@kannel.org <mailto:amal...@kannel.org> пишет: > >> Hi, > >> > >> please try SVN version. Looks like 1.4.4 has issue with TLVs… > >> > >> Alex > >> > >> > >>> Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович > >>> <sw_cherepa...@motivtelecom.ru <mailto:sw_cherepa...@motivtelecom.ru>>: > >>> > >>> Here's the dump of packets. > >>> > >>> > >>> Short Message Peer to Peer, Command: Submit_sm - resp, Status: "Ok", Seq: > >>> 684, Len: 25 > >>> Length: 25 > >>> Operation: Submit_sm - resp (0x80000004) > >>> Result: Ok (0x00000000) > >>> Sequence #: 684 > >>> Message id.: 2D8B40B4 > >>> > >>> Short Message Peer to Peer, Command: Deliver_sm, Seq: 674395051, Len: 95 > >>> Length: 95 > >>> Operation: Deliver_sm (0x00000005) > >>> Sequence #: 674395051 > >>> Service type: (Default) > >>> Type of number (originator): International (0x01) > >>> Numbering plan indicator (originator): ISDN (E163/E164) (0x01) > >>> Originator address: 79028710256 > >>> Type of number (recipient): International (0x01) > >>> Numbering plan indicator (recipient): ISDN (E163/E164) (0x01) > >>> Recipient address: 3432690000 > >>> .... ..00 = Messaging mode: Default SMSC mode (0x00) > >>> ..00 01.. = Message type: Short message contains SMSC Delivery > >>> Receipt (0x01) > >>> 00.. .... = GSM features: No specific features selected (0x00) > >>> Protocol id.: 0x7f > >>> Priority level: GSM: None ANSI-136: Bulk IS-95: Normal > >>> (0x00) > >>> Scheduled delivery time: Immediate delivery > >>> Validity period: SMSC default validity period > >>> .... ..00 = Delivery receipt: No SMSC delivery receipt requested > >>> (0x00) > >>> .... 00.. = Message type: No recipient SME acknowledgement requested > >>> (0x00) > >>> ...0 .... = Intermediate notif: No intermediate notification > >>> requested (0x00) > >>> .... ...0 = Replace: Don't replace (0x00) > >>> Data coding: 0x00 > >>> SMPP Data Coding Scheme: SMSC default alphabet (0x00) > >>> GSM SMS Data Coding > >>> 0000 .... = DCS Coding Group for SMS: SMS DCS: General Data > >>> Coding indication - Uncompressed text, no message class (0x00) > >>> ..0. .... = DCS Text compression: Uncompressed text > >>> ...0 .... = DCS Class present: No message class > >>> .... 00.. = DCS Character set: GSM 7-bit default alphabet (0x00) > >>> GSM CBS Data Coding > >>> 0000 .... = DCS Coding Group for CBS: CBS DCS: Language using the > >>> GSM 7-bit default alphabet (0x00) > >>> ..00 0000 = DCS CBS Message language: German (0x00) > >>> Predefined message: 0 > >>> Message length: 0 > >>> Optional parameters > >>> Optional parameter: message_state (0x0427) > >>> Tag: 0x0427 > >>> Length: 1 > >>> Message state: DELIVERED (2) > >>> Optional parameter: network_error_code (0x0423) > >>> Tag: 0x0423 > >>> Length: 3 > >>> Error type: GSM (3) > >>> Error code: 0x0000 > >>> Optional parameter: receipted_message_id (0x001e) > >>> Tag: 0x001e > >>> Length: 9 > >>> SMSC identifier: 2D8B40B4 > >>> Optional parameter: source_subaddress (0x0202) > >>> Tag: 0x0202 > >>> Length: 12 > >>> Source Subaddress: a03739303238373130303939 > >>> > >>> > >>> 14.08.2016 20:07, Rene Kluwen пишет: > >>>> Even, the message appears in your log files. > >>>> If you set the debug level high enough, you can just see it appear there. > >>>> > >>>> -----Oorspronkelijk bericht----- > >>>> Van: devel [mailto:devel-boun...@kannel.org > >>>> <mailto:devel-boun...@kannel.org>] Namens Milan P. Stanic > >>>> Verzonden: zondag 14 augustus 2016 12:44 > >>>> Aan: devel@kannel.org <mailto:devel@kannel.org> > >>>> Onderwerp: Re: [Couldnot parse DLR string sscanf way,fallback to old > >>>> way. Please report!] -- problem with message id > >>>> > >>>> On Fri, 2016-08-12 at 15:27, Черепанов Алексей Владиславович wrote: > >>>>> Hi, there. Having a problem with handling deliver_sm. > >>>>> Kannel couldn't parse message id: > >>>>> > >>>>> 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Couldnot parse DLR > >>>>> string sscanf way,fallback to old way. Please report! > >>>>> 2016-08-12 14:45:59 [2952] [6] ERROR: SMPP[SMSC]: got DLR but could > >>>>> not find message or was not interested in it id<> dst<79028710256>, > >>>>> type<2> > >>>>> 2016-08-12 14:45:59 [2952] [6] DEBUG: message_id: NULL > >>>> Look like your provider (upstream SMPP server) does not send 'standard' > >>>> DLR message. > >>>> Actually there is no standard format for DLR message but most providers > >>>> format it following sample in SMPP specification document. > >>>> > >>>> Could you check with your provider in what format their server send > >>>> message to your kannel. Or, you can extract it with some network capture > >>>> tools (tcpdump, tshark/wireshark) and see in what format messages are. > >>>> > >>>> > >>>> > >>> > >>> -- > >>> С уважением, > >>> Черепанов Алексей > >> > > > > -- > > С уважением, > > Черепанов Алексей >
