Am 22.08.2016 um 13:26 schrieb Черепанов Алексей Владиславович
<sw_cherepa...@motivtelecom.ru <mailto: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 пишет:
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] Namens Milan P. Stanic
Verzonden: zondag 14 augustus 2016 12:44
Aan: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.
--
С уважением,
Черепанов Алексей
--
С уважением,
Черепанов Алексей
