User Data Header

NOTE: This text is about concatenated messages, as an example. However, with SMSTools 3 you do not have to care about concatenation (multipart messages) while using settings autosplit = 3 for outgoing messages and internal_combine = yes for incoming messages. These are default values.

User Data header was added to the SMS format specification to add new features. Originally SMS was made to send single small binary files or text messages, with a maximum of 140 bytes or 160 7-bit characters. But now mobile devices need to distinguish between different files, for example ringtones, operator logos and wap-push messages. Also users want to send larger messages which was impossible with the original SMS format specification.

Each short message has a flag to indicate if the message part includes a User Data Header or not. If this flag is set to 1 (or true), then the first few bytes of the message are the User Data Header, followed by the message text or data. Example:

When you receive a text message with User Data Header, you would normally see some scrambled characters at the beginning. Starting with version 2.1, smsd automatically removes these characters from the message text and shows them as a hex-dump in the sms file header. Example:

Now you have a more beautiful text-part and the User Data Header is dumped into human readable format which makes reading it much easier. You might use the script hex2dec to convert the hexadecimal numbers to decimal.

The most popular use of User Data Headers are concatenated text messages. If somebody sends a text message that is longer than 160 characters, most phones splits the text automatically into two or more short messages. Each messages contains a header that is used by the receiving mobile phone to combine them in correct order.

Referring to the UDH-DATA in the above example, the 6 bytes have the following meaning:

05 = 5 bytes follow
00 = indicator for concatenated message
03 = three bytes follow
5F = message identification. Each part has the same value here
02 = the concatenated message has 2 parts
01 = this is part 1

When you receive concatenated text messages, the parts might arrive in random order. You might first receive the last part and then the first part. The GSM specification does not force any device to transfer messages in the original order. So when you receive a concatenated message you need to check if all parts have been received before you can put all the parts together.

In case of binary messages, the header is part of the binary data and does not appear in the header, so you will not see any UDH-DATA header in binary message files.