Hi Guys,
First of all Merry Christmas, to those of you who celebrate.
I've encountered an issue, we have connected to a new provider, and traffic is
running smooth, but when ever we send a UNICODE message, the DLR that is
returned to us, is also UNICODE, and is given in the message_payload string,
from the looks it seems like Kannel have a hard time dealing with this:
Here's our SMPP logs:
2012-12-17 10:54:42 [11067] [29] DEBUG: SMPP[provider]: Got PDU:
2012-12-17 10:54:42 [11067] [29] DEBUG: SMPP PDU 0x7f3a24007ab0 dump:
2012-12-17 10:54:42 [11067] [29] DEBUG: type_name: deliver_sm
2012-12-17 10:54:42 [11067] [29] DEBUG: command_id: 5 = 0x00000005
2012-12-17 10:54:42 [11067] [29] DEBUG: command_status: 0 = 0x00000000
2012-12-17 10:54:42 [11067] [29] DEBUG: sequence_number: 17 = 0x00000011
2012-12-17 10:54:42 [11067] [29] DEBUG: service_type: NULL
2012-12-17 10:54:42 [11067] [29] DEBUG: source_addr_ton: 1 = 0x00000001
2012-12-17 10:54:42 [11067] [29] DEBUG: source_addr_npi: 1 = 0x00000001
2012-12-17 10:54:42 [11067] [29] DEBUG: source_addr: "4540701272"
2012-12-17 10:54:42 [11067] [29] DEBUG: dest_addr_ton: 5 = 0x00000005
2012-12-17 10:54:42 [11067] [29] DEBUG: dest_addr_npi: 0 = 0x00000000
2012-12-17 10:54:42 [11067] [29] DEBUG: destination_addr: "XXXX"
2012-12-17 10:54:42 [11067] [29] DEBUG: esm_class: 4 = 0x00000004
2012-12-17 10:54:42 [11067] [29] DEBUG: protocol_id: 0 = 0x00000000
2012-12-17 10:54:42 [11067] [29] DEBUG: priority_flag: 0 = 0x00000000
2012-12-17 10:54:42 [11067] [29] DEBUG: schedule_delivery_time: NULL
2012-12-17 10:54:42 [11067] [29] DEBUG: validity_period: NULL
2012-12-17 10:54:42 [11067] [29] DEBUG: registered_delivery: 0 = 0x00000000
2012-12-17 10:54:42 [11067] [29] DEBUG: replace_if_present_flag: 0 =
0x00000000
2012-12-17 10:54:42 [11067] [29] DEBUG: data_coding: 8 = 0x00000008
2012-12-17 10:54:42 [11067] [29] DEBUG: sm_default_msg_id: 0 = 0x00000000
2012-12-17 10:54:42 [11067] [29] DEBUG: sm_length: 0 = 0x00000000
2012-12-17 10:54:42 [11067] [29] DEBUG: short_message: ""
2012-12-17 10:54:42 [11067] [29] DEBUG: message_payload:
2012-12-17 10:54:42 [11067] [29] DEBUG: Octet string at 0x7f3a240058e0:
2012-12-17 10:54:42 [11067] [29] DEBUG: len: 276
2012-12-17 10:54:42 [11067] [29] DEBUG: size: 277
2012-12-17 10:54:42 [11067] [29] DEBUG: immutable: 0
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 69 00 64 00 3a 00 34 00
30 00 30 00 30 00 30 .i.d.:.4.0.0.0.0
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 33 00 44 00 38 00 32 00
44 00 44 00 39 00 32 .3.D.8.2.D.D.9.2
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 31 00 32 00 31 00 37 00
31 00 30 00 31 00 34 .1.2.1.7.1.0.1.4
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 35 00 35 00 33 00 34 00
30 00 20 00 73 00 75 .5.5.3.4.0. .s.u
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 62 00 3a 00 30 00 30 00
30 00 20 00 64 00 6c .b.:.0.0.0. .d.l
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 76 00 72 00 64 00 3a 00
30 00 30 00 30 00 20 .v.r.d.:.0.0.0.
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 73 00 75 00 62 00 6d 00
69 00 74 00 20 00 64 .s.u.b.m.i.t. .d
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 61 00 74 00 65 00 3a 00
31 00 32 00 31 00 32 .a.t.e.:.1.2.1.2
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 31 00 37 00 31 00 30 00
35 00 34 00 20 00 64 .1.7.1.0.5.4. .d
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 6f 00 6e 00 65 00 20 00
64 00 61 00 74 00 65 .o.n.e. .d.a.t.e
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 3a 00 31 00 32 00 31 00
32 00 31 00 37 00 31 .:.1.2.1.2.1.7.1
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 30 00 35 00 34 00 20 00
73 00 74 00 61 00 74 .0.5.4. .s.t.a.t
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 3a 00 44 00 45 00 4c 00
49 00 56 00 52 00 44 .:.D.E.L.I.V.R.D
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 20 00 65 00 72 00 72 00
3a 00 30 00 30 00 30 . .e.r.r.:.0.0.0
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 20 00 54 00 65 00 78 00
74 00 3a 00 4e 00 65 . .T.e.x.t.:.N.e
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 77 00 20 00 6c 00 69 00
6e 00 65 00 73 00 20 .w. .l.i.n.e.s.
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 61 00 70 00 70 00 65 00
6e 00 64 00 65 00 64 .a.p.p.e.n.d.e.d
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 00 20 00 74
. .t
2012-12-17 10:54:42 [11067] [29] DEBUG: Octet string dump ends.
2012-12-17 10:54:42 [11067] [29] DEBUG: message_state: 2 = 0x00000002
2012-12-17 10:54:42 [11067] [29] DEBUG: receipted_message_id:
2012-12-17 10:54:42 [11067] [29] DEBUG: Octet string at 0x7f3a24005ee0:
2012-12-17 10:54:42 [11067] [29] DEBUG: len: 26
2012-12-17 10:54:42 [11067] [29] DEBUG: size: 27
2012-12-17 10:54:42 [11067] [29] DEBUG: immutable: 0
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 34 30 30 30 30 33 44 38 32
44 44 39 32 31 32 31 400003D82DD92121
2012-12-17 10:54:42 [11067] [29] DEBUG: data: 37 31 30 31 34 35 35 33 34
30 7101455340
2012-12-17 10:54:42 [11067] [29] DEBUG: Octet string dump ends.
2012-12-17 10:54:42 [11067] [29] DEBUG: SMPP PDU dump ends.
2012-12-17 10:54:42 [11067] [29] DEBUG: SMPP[provider] handle_pdu, got DLR
2012-12-17 10:54:42 [11067] [29] DEBUG: SMPP[provider]: Couldnot parse DLR
string sscanf way,fallback to old way. Please report!
2012-12-17 10:54:42 [11067] [29] ERROR: SMPP[provider]: got DLR but could not
find message or was not interested in it id<> dst<4540701272>, type<2>
Have any of you guys seen the same behavior somewhere and found a workaround
for this ?
Thanks in advance.
Greeting,
Mads