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

Reply via email to