Stipe Tolj wrote:
The SMPP patch just fixes the following issues:If it's DCS is really broken up in MO SMPP, then please re-send the patch. Use [PATCH] in the mail subject line.
*) Kannel coding param is overwritten with wrong values by pdu_to_msg (e.g. a Nokia business card, which is 8-bit data encoded as iso-8859-1, is processed by Kannel as 7-bit text, and will be forwarded as coding 1.)
*) UDH is ignored in SMS-MO
I'll repost my revised smsc_smpp.c patch a little later, with [PATCH] in the Subject line. Hopefully, it will apply and be useful.
These bugs made a larger issue with Kannel considerably worse; the DCS problem can be illustrated with the following example:
Say we have a binary (8-bit) message without compression, but with message class 1. These are pretty common; Nokia phones use these for most Smart Messaging MO's.
There are two valid representations of this as a DCS octet:
(WARNING -- try a fixed-width font if this looks like junk)
0001 0101 = 0x15
^^ ^ ^
|| | |_ Message Class 1
|| |___ 8 bit data
||______ Message class present
|_______ No compression
1111 0101 = 0xF5
^ ^ ^
| | |_ Message class 1
| |___ 8 bit data
|______ Message class present
Another fun example is 7-bit "flash" (Class 0) SMs
0001 0000 = 0x10
1111 0000 = 0x240
Given the information Kannel passes over HTTP POST, it is impossible to decide which of the two "spellings" of an equivalent DCS was originally sent in the MO.
My proposal for variant DCS and PID handling was:
*) keep the "parsed" ambiguous representation (mwi,mclass,coding,compress etc.)
*) add the original DCS octet as an additional parameter
*) add "parsed" fields for the bit fields in protocol_id
(in particular, the "replace message class" has some useful properties)
That was the proposal. Sorry if it wasn't clear before.
David WHITE
CONNECT AUSTRIA
