SMS data encoding and the 3110

[Osma Suominen]

Hi,

I've continued my quest to bring better 3110 support for gnokii. As I've
said before I have some problems with SMS data encodings. The problem is
that text in the default alphabet is expected by the phone to be in
8-bit ASCII text (which it apparently encodes itself), whereas other
phones want that in packed 7-bit format. gsm-sms.c does this encoding
automatically, so the 3110 driver gets its data served in the wrong
format.

The problematic part is the sms_data_encode() function is gsm-sms.c:

        /* Unicode */
        if ((dcs.type & 0x08) == 0x08) {
                dprintf("Unicode message\n");
                char_unicode_decode(output, message, length);
        } else {
                /* 8bit SMS */
                if ((dcs.type & 0xf4) == 0xf4) {
                        dprintf("8bit message\n");
                        memcpy(output, message + udhlen, length);
                /* 7bit SMS */
                } else {
                        dprintf("Default Alphabet\n");
                        length = length - (udhlen * 8 + ((7-(udhlen%7))%7)) / 7;
                        char_7bit_unpack((7-udhlen)%7, size, length, message, 
output);
                        char_ascii_decode(output, output, length);
                }
        }

What I'd like to see is some change in the last part. In pseudocode it
should be something like this:

dprintf("Default alphabet\n");
IF DRIVER=3110:
        memcpy(output, message + udhlen, length);
ELSE
        length = length - (udhlen * 8 + ((7-(udhlen%7))%7)) / 7;
        char_7bit_unpack((7-udhlen)%7, size, length, message, output);
        char_ascii_decode(output, output, length);
ENDIF

Of course having an explicit check for phone model in common code is not
very clean. There should be another way for the driver to request no
7bit encoding (or for other drivers to request encoding).

The same also applies in the opposite direction (SMS decoding), where a
simple memcpy should be used for the 3110 instead when dealing with text
in the default alphabet.

Note that the 3110 does seem to handle 8-bit and Unicode SMS's quite
correctly, although it can't display either of them (checked this by
reading back stored messages and also moving over the SIM to my 6150,
which can display Unicode messages). So this encoding problem only
appears with simple plaintext messages.

I can't (or don't dare) to "fix" this myself because it requires changes
in the driver infrastructure, and I'm not sure which is the best place
to plug in such an option. Perhaps a boolean field in the gn_driver
structure could be added? Another option would be to store the data
twice in the raw_sms structure, so the drivers could pick the encoding
that suits them best. The other way (driver to gsm-sms.c) is problematic
in that case but could be fixed by yet another field telling in which
raw_sms field (encoded/raw) the message data was stored.

Of course, there's always the possibility to handle this 3110
peculiarity only in its driver. Working around this problem in the
driver is ugly but not impossible to do.

If you have a consensus on what the best way of fixing this is, I'll be
glad to submit a patch making it real. I could code probably 5 different
solutions already, but I'd rather do that after hearing some opinions.

-Osma

-- 
*** Osma Suominen *** address@hidden *** http://www.iki.fi/ozone/ ***