When submitting Unicode message using smpp protocol via regular "text"
field by specifying coding=2 and char-set=utf-8, message is delivered
correctly.

&coding=2&charset=utf8&text=Unicode+Greek+Όλα Καλά

    2020-05-25 20:37:03 [24722] [6] DEBUG:   short_message:
    2020-05-25 20:37:03 [24722] [6] DEBUG:    Octet string at
0x7fe9e8006c80:
    2020-05-25 20:37:03 [24722] [6] DEBUG:      len:  44
    2020-05-25 20:37:03 [24722] [6] DEBUG:      size: 45
    2020-05-25 20:37:03 [24722] [6] DEBUG:      immutable: 0
    2020-05-25 20:37:03 [24722] [6] DEBUG:      data: 00 55 00 6e 00 69
00 63 00 6f 00 64 00 65 00 20   .U.n.i.c.o.d.e.
    2020-05-25 20:37:03 [24722] [6] DEBUG:      data: 00 47 00 72 00 65
00 65 00 6b 00 20 03 8c 03 bb   .G.r.e.e.k. ....
    2020-05-25 20:37:03 [24722] [6] DEBUG:      data: 03 b1 00 20 03 9a
03 b1 03 bb 03 ac               ... ........
    2020-05-25 20:37:03 [24722] [6] DEBUG:    Octet string dump ends.
    2020-05-25 20:37:03 [24722] [6] DEBUG: SMPP PDU dump ends.

But when submitting Unicode message in TLV 0x424 field and coding=2 and
char-set=utf-8, message is not converted to ucs2 and delivered as
something that looks like Chinese.

kannel.conf configured with

group = smpp-tlv
name = message-payload
smsc-id = 123
tag = 0x0424
type = nulterminated
length = 65535

&coding=2&charset=utf8&text=&meta-data=%3Fsmpp%3Fmessage-payload%3D%=Unicode+Greek+Όλα
Καλά

[6] DEBUG:    Octet string at 0x7fe9e8006e10:
2020-05-25 21:05:11 [24722] [6] DEBUG:      len:  29
2020-05-25 21:05:11 [24722] [6] DEBUG:      size: 30
2020-05-25 21:05:11 [24722] [6] DEBUG:      immutable: 0
2020-05-25 21:05:11 [24722] [6] DEBUG:      data: 55 6e 69 63 6f 64 65
20 47 72 65 65 6b 20 ce 8c   Unicode Greek ..
2020-05-25 21:05:11 [24722] [6] DEBUG:      data: ce bb ce b1 20 ce 9a
ce b1 ce bb ce ac            .... ........
2020-05-25 21:05:11 [24722] [6] DEBUG:    Octet string dump ends.
2020-05-25 21:05:11 [24722] [6] DEBUG: SMPP PDU dump ends.

When using GSM-7 encoded message in in TLV 0x424 field, message
delivered correctly.

Is it a bug?  Or I am doing encoding meta-data wrong?


Reply via email to