GSM 7 bot encoding

Hi,
I want to send EMS with picture and text. I can send text and picture
separately. However, when i tried to send both in a same message, the text
wasn't recognizable in the phone. When I used a tool to generate binary
data of EMS with picture and text, I noticed that the data part (encoded
text message) was varying depending on the UDH even though the original
text message remained unchanged.
Pls let me know the encoding scheme of EMS for text or refer me to any
references to this strange encoding.

---

› See More: GSM 7 bot encoding

Peter wrote:

> Hi,
> I want to send EMS with picture and text. I can send text and
> picture separately. However, when i tried to send both in a
> same message, the text wasn't recognizable in the phone. When
> I used a tool to generate binary data of EMS with picture and
> text, I noticed that the data part (encoded text message) was
> varying depending on the UDH even though the original text
> message remained unchanged. Pls let me know the encoding
> scheme of EMS for text or refer me to any references to this
> strange encoding.

The UDH needs to be padded to the next septet boundary if text
following the UDH is to be correctly interpreted.

If the UDH requires 6 octets (48 bits) then bit 49 needs to be a
fill bit so that the actual text starts at bit 50. This is
specified for backwards compatability, so that EMS messages
will display on old phones. On these, the first 49 bits
(assuming a 6 octet UDH) will display as garbage, but the
actual text will display correctly. If follows that without
the necessary fill bits, all text will be unrecognizable on old
and new phones alike.

I don't know if this is your problem, but we need to know you've
got this right before we look further.

John

I wrote:

> If the UDH requires 6 octets (48 bits) then bit 49 needs to be
> a fill bit so that the actual text starts at bit 50. This is
> specified for backwards compatability, so that EMS messages
> will display on old phones. On these, the first 49 bits
> (assuming a 6 octet UDH) will display as garbage, but the
> actual text will display correctly. If follows that without
> the necessary fill bits, all text will be unrecognizable on
> old and new phones alike.

I suppose I should say explicitly that the above also implies
something important about the mechanics of implementing the
7-bit packing algorithm.

It implies that at the septet boundary following the UDH, the
character packing must commence as if the UDH weren't there,
but ordinary septets of packed text were in place of the UDH
instead.

I achieve this in practice by calculating how many octets of UDH
the EMS requires, and then rounding that up to a septet
boundary (a multiple of 7). So in my example of a 6-octet UDH,
that's 7 septets of space that needs to be put aside for the
UDH. Then I put 7 (in this case) "@" characters in front of
the text and pack that longer string into octets (algorithn at
GSM 03.38, clause 6.1.2.1.1). The "@" character is the
"0000000" binary septet, giving me lots of zeros as potential
fill bits. Finally, I overwrite the first 6 octets with the
actual UDH, and my actual text is all correctly packed behind
it.

John