[PATCH] Parse +CUSD responses.

[andrzej zaborowski]

Hi,

2009/10/16 Denis Kenzior <denkenz at gmail.com>:
> Right now we should simply ignore 8bit data and return an error.

Ok, now we return the "unsupported" status on either an 8-bit response
or a dcs that we don't understand.

>
>> I removed the "TODO: be able to send UCS2 string" because the string
>> we send is first checked to be a valid USSD string so we already know
>> it can be encoded with GSM 7-bits.
>
> Actually valid_ussd_string will accept just about everything.

Ah true.  However I think we should never try to send a UCS2 USSD - we
would first need to know that the modem supports this (so a vendor
quirk set by the plugin would tell us this) and then that the network
supports this too.

Neither of the modems I tried yesterday was able to send a string with
DCS of 0x11 or 0x98 or 0xf8 (all of these are supposed to mean UCS2)
with language code prepended or without, only with 0x48 on TI Calypso.

>
>> +     /* All 7-bit coding schemes - there's no need to distinguish
>> +      * between the different schemes because the modem is tasked
>> +      * with presenting us with only raw 7-bit characters.
>> +      */
>> +     if ((dcs & 0xf0) == 0x00 || dcs == 0x10 || (dcs & 0xf0) == 0x20 ||
>> +                     (dcs & 0xf0) == 0x30 || (dcs & 0xcc) == 0x40 ||
>> +                     (dcs & 0xfc) == 0x90 || (dcs & 0xf4) == 0xf0)
>> +             converted = convert_gsm_to_utf8(content, length,
>> +                                             NULL, NULL, 0);
>> +
>
> What about the evil set of DCSes which indicate a ISO639 2 character code
> preceding the message?

The comment refers to this.  I think 27.007 tries to say the modem has
to take care of this and only give us the actual characters of the
string.

"-       if TE character set other than "HEX" (refer command Select TE
Character Set +CSCS): MT/TA converts GSM alphabet into current TE
character set according to rules of 3GPP TS 27.005 [24] Annex A

-       if TE character set is "HEX": MT/TA converts each 7-bit character of
GSM alphabet into two IRA character long hexadecimal number (e.g.
character ( (GSM 23) is presented as 17 (IRA 49 and 55))"

If we can assume that the same rules apply to encoding and decoding
then the TI Calypso modem and the nokia modems confirm this because
sending a string with DCS = 0x10 works without the language code and
doesn't work with the language prepended.

>
>> +     g_at_chat_send(chat, "AT+CSCS=\"HEX\"", NULL, NULL, NULL, NULL);
>
> This part of 27.007 is utterly and completely broken.  We have to be extra
> careful whenever we mess with CSCS.  Does this have any unfortunate side
> effects, in particular with +COPS, +CPUC, etc?  Also note that since we change
> the CSCS during phonebook import, any USSDs sent/received during this time
> won't actually work properly :)

Oh right, I had forgotten about +COPS etc, I noticed phonebook used
+CSCS and nothing else used it.  So if we can assume that the default
character set is GSM, then we can use it for 7-bit encoded responses,
but we will need to think of something else to interpret the 8-bit
data.  I changed the patch to leave the encoding alone and assume GSM
alphabet.

Regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Parse-CUSD-responses.patch
Type: text/x-patch
Size: 5319 bytes
Desc: not available
URL: <http://lists.ofono.org/pipermail/ofono/attachments/20091016/271e3f8a/attachment.bin>