Hi

I have read through the SMPP v3.4 spec, the Kannel user guide and some other
PDFs from the SMS Forum but I am still a little in the dark about this
field.

Please correct me where I am wrong:

It seems that the data_coding field is made up of 2 distinct sections.
Firstly, coding scheme, bits 3 to 0 are used to indicate to the SMSC what
encoding has been used to encode the short_message field.
The second part, data coding parameter, seems to influence how the handset
will handle the sms by manipulating the MWI (message waiting indicator).

We are trying to send messages to an SMSC and certain symbols are coming out
incorrectly on our handsets. For example the '@' is coming out as a normal
'a'. We know that we needed to change to use ASCII. So we changed our
configuration and added

alt-charset = "ASCII"

I can see from the traces that the short_message data field is now encoded
differently but the data_coding field remains a 0. How do these fields and
settings then relate to the charset, coding, alt-dcs parameters that you can
set in the sendsms URL?

I have also come across in the SMPP v3.4 GSM / UMTS v1.0 guide that the
following are the default encodings offered by most smscs

• SMSC default alphabet (7 or 8-bits)
• LATIN 1 (8-bits)
• US ASCII (7-bits)
• UCS2 (16-bits)

But when I have a look at the data_coding parameter in the SMPP v3.4 spec
GSM 03.38 (which I assume is the standard is not listed). Which leads me to
believe that IF the SMSC will use GSM to decode the message it will be part
of the "SMSC Default Alphabet" and there is no way of asking it to use GSM
specifically because it fall under the "default" umbrella. The SMSC uses
ASCII so we must just encode our messages using ASCII. We could also specify
0x01 in the data_coding field and it should have NO effect because we are
telling the SMSC to use ASCII to decode the message and they use that by
default anyway.

All of this is as clear as mud to me. Any help would be thoroughly
appreciated.

Regards,

Reply via email to