Re: DCS and PID handling in Kannel

Citando Dave White <[email protected]>:

> 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.

Kannel should decide for the 0x0x "spelling" unless you pass alt-dcs field,
which will select the 0xFx "spelling". 

see X-Kannel-Alt-DCS



-- 
Davi / Bruno.Rodrigues<at>Litux.Org
Litux.org: 12:55:12 up 87 days, 14:10,  4 users,  load average: 0.15, 0.13, 0.06
'lp1 on fire
	-- One of the more obfuscated kernel messages'