How to send a UCS2 message with Datacoding=8 by jSMPP client

[ThangPro]

Dear All,

any help for this problem:
I am testing JSMPP code as client(latest version on githup stream) to send a UCS2 message to SMPP server (version 3.4):

- Send and receive were successfull.

- Problem with Datacoding at server side: Server got Datacoding = 25. it's not expectation value. Actually, it should be =8
------------------------------------------------------------------------------------------

The test code at jsmpp client:  
 // this is how to write "house" in arabic
        String house = "\u0628" + "\u064e" + "\u064a" +
                        "\u0652" + "\u067a" + "\u064f";
       
        TimeFormatter timeFormatter = new RelativeTimeFormatter();
       
        // 4. Specify the data coding using UCS2
        DataCoding dataCoding = new GeneralDataCoding(Alphabet.ALPHA_UCS2, MessageClass.CLASS1, false);
       
        // 5. UCS-2 is subset of the UTF-16BE charset, only the Basic Multilingual Plane codepoints are encodeable as UCS-2
        byte[] data = house.getBytes(StandardCharsets.UTF_16BE);
       
        // 6. Submit the short message
        SubmitSmResult submitSmResult = session.submitShortMessage("CMT",
                TypeOfNumber.INTERNATIONAL, NumberingPlanIndicator.UNKNOWN,
                "1616", TypeOfNumber.INTERNATIONAL, NumberingPlanIndicator.UNKNOWN,
                "628176504657", new ESMClass(), (byte)0, (byte)1,  
                timeFormatter.format(new Date(System.currentTimeMillis() + 60000)), null,
                new RegisteredDelivery(SMSCDeliveryReceipt.DEFAULT), (byte)0,
                dataCoding,
                (byte)0, data);

---------------------------------------------------------------------

- Question is: how to set datacoding at client =8 

anyone can help me on this problem.

[Francis kinyuru]

This might be an issue on the server, not on the client side.

Had a similar issue which was resolved on the server side.

[ThangPro]

Hi Francis kinyuru,

thanks for your comment.

however, I did test same case with current jSMPP server (both of server and client version 3.0.1) then Server also received datacode=25 for UCS2 and =17 for ASCII.

I test new case: 

- client is openSMPP3.4 (version 3.0.2): Send test message ucs2 (unicode)

- Server is jSMPP5.0 ( version 3.0.1): server received and decode that datacoding = 8  

Then, problem might be in jsmpp client when set datacoding as example codes.

Could you please help more detail on this? 

Thanks a lot.

Vào lúc 01:31:09 UTC+7 ngày Thứ Năm, 18 tháng 7, 2024, francisk...@gmail.com đã viết:

[Francis kinyuru]

To be sure you are sending the correct data coding scheme you can capture a tcpdump and share for review 

[Francis kinyuru]

Actually did some research and 25 is the correct values

Data Coding Scheme values used in SMPP:

1. 0: Default Alphabet - 7-bit ASCII encoding.
2. 1: Latin-1 - ISO 8859-1 encoding (8-bit single-byte encoding for Western European languages).
3. 2: Unicode UCS-2 - 16-bit encoding (supporting a wide range of international characters).
4. 3: Reserved for Future Use.
5. 4: JIS (Japanese Industrial Standards) - For Japanese characters.
6. 5: ISO-2022-JP - Another encoding for Japanese characters.
7. 6: KSC5601 - Korean encoding.
8. 7: ISO-2022-KR - Another encoding for Korean characters.
9. 8: GB2312 - Simplified Chinese encoding.
10. 9: ISO-2022-CN - Another encoding for Simplified Chinese characters.
11. 10: Reserved for Future Use.
12. 11: Reserved for Future Use.
13. 12: Reserved for Future Use.
14. 13: Reserved for Future Use.
15. 14: Reserved for Future Use.
16. 15: Reserved for Future Use.
17. 16: Reserved for Future Use.
18. 17: Reserved for Future Use.
19. 18: Reserved for Future Use.
20. 19: Reserved for Future Use.
21. 20: Reserved for Future Use.
22. 21: Reserved for Future Use.
23. 22: Reserved for Future Use.
24. 23: Reserved for Future Use.
25. 24: Reserved for Future Use.
26. 25: UCS-2 (16-bit Unicode encoding).
27. 26: Reserved for Future Use.
28. 27: Reserved for Future Use.
29. 28: Reserved for Future Use.
30. 29: Reserved for Future Use.
31. 30: Reserved for Future Use.

[Francis kinyuru]

This might be an issue on the server, not on the client side.

Had a similar issue which was resolved on the server side.

--
You received this message because you are subscribed to the Google Groups "jsmpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsmpp+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jsmpp/73f97b62-3372-43af-b186-9672a0dfa184n%40googlegroups.com.