Re: DCS and PID handling in Kannel

Stipe Tolj wrote:
> If it's DCS is really broken up in MO SMPP, then please re-send the
> patch. Use [PATCH] in the mail subject line.

The SMPP patch just fixes the following issues:

*) 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