3

I am facing a problem in sending flash message in Arabic while using SMPP protocol in Java. I am successful with sending in standard English format but when I use Arabic unicodes, the message is being delivered in unknown format.

Below is the related sample request that I am using.

byte protocolId = 0x00;
byte dataCoding = (byte) 0xf0; //(for flash message)
byte smsClass = 0x00;
request.setShortMessage("\u0628", Data.ENC_UTF8);

The SMPP request in the logs is showing the correct Arabic alphabet while sending the request but at the user end the alphabet is in unreadable format. The remaining settings for request are set as default. Would appreciate any suggestion to achieve the goal. Thanks in advance.

ktk
  • 297
  • 4
  • 13
  • I would test to see if Arabic text can be sent. According to SMPP spec 3.4 section 5.2.19, DCS 0x08 should be used to set unicode. Then, I would try sending with DCS 0x88 for flash messages. – Wahid Sadik Mar 11 '13 at 21:19
  • Yes you are right about the spec. But when I use 0x08 for data coding the message can deliver the Arabic though it could not be delivered as flash message. It directly stores in inbox just as a normal message. – ktk Mar 12 '13 at 05:09

2 Answers2

3

You need to set the dcs to 0x18.

There are two ways of encoding to allow access to the message class parameter which is responsible for flash messages.

See http://www.etsi.org/deliver/etsi_ts/100900_100999/100900/07.02.00_60/ts_100900v070200p.pdf section 4 for further reading.

Your value 0xf0 indicates the second way to encoding the dcs and sets message class to 0, which is flash but also the alphabet is set to default. This way doesn't UCS2 by the way.

The other way allows better control. The upper hex nibble is set 1, which just means that the lower hex nibble contains information about the message class. The lower hex nibble then tells that UC2 is used and message class is set to 0.

Martin
  • 640
  • 7
  • 11
1

I have not yet come across a foolproof way that will work across all SMS-Cs.

There are two possibilities; you will have to experiment to see which (if either) method works with your provider.

Option 1. Set the data_coding parameter to 0x18.

This is well explained in @Martin's answer, but strictly this is a GSM/MAP DCS value (search for the spec "TS 23.038"), not an SMPP data_coding value. This option pre-supposes that the SMS-C passes this SMPP data_coding value transparently. There is no guarantee of this - the data_coding range 0x0F-0xBF is reserved in SMPP, so you don't know what the SMS-C will do with it without trying it out.

Option 2. Set data_coding to 0x08 and dest_addr_subunit = 1 ("MS Display")

This is the more standards-compliant way, but relies on both your SMPP stack and the SMS-C's stack supporting the dest_addr_subunit parameter (which is optional).

Neither option is guaranteed to be portable between networks. Therefore, if you are connecting to an aggregator across all the networks in your territory, and the aggregator forwards the fields transparently, you may run into inconsistencies when sending messages to phones on all of your target networks.

Chris Mead
  • 465
  • 1
  • 4
  • 9