Re: DCS and PID handling in Kannel

On Tue, 2003-02-18 at 07:06, Bruno Rodrigues wrote:

> PID value is passed thru from smsbox http interface to smsc connection
> and kannel doesn't mind with it. 
> DCS is used internally in kannel and thus should be "controled" by it.
> That's why we have seperated fields to build DCS at the end. 
> For example, if you set UDH and don't set coding, kannel will
> automatically (legacy behaviour) select 8 bit text and adapt your text
> data to it.

Which is severely broken. Consider EMS messages, which have (e.g.) a
bitmap in the header and 7-bit text in the remaining space in the user
data field. Interpretation of user data is solely a function of DCS,
that's why it's there.

> Using coding, mclass, mwi and alt-dcs, every dcs combination can be
> done, if smsc modules supports it of course. EMI2 and AT2 surelly
> supports it.
> 
> I can make a table in userguide with it's combinations to describe it.
> 

You will discover that the coding scheme cannot be completely
reconstructed from the data Kannel sends. DCS 0xF5 should be equivalent
to DCS 0x15, but there's no guarantee a mobile phone (or some
third-party app for a smartphone) will be so smart as to recognize the
equivalence. There's also a matter of principle -- if you decide (for
instance) to create a file system that has a case-insensitive namespace,
is it better to force filenames to be ALL CAPS or preserve the filename
given by the user?

> I vote -1 for having a DCS field outside smsbox and I don't see a
> requirement to split pid, but that's only MHO :)
> 

I made these suggestions and sent an SMPP patch because I encountered
problems trying to get Kannel to handle MO messages correctly. One of
these problems is that it screws up DCS.

The "-1" doesn't suprise me at all. It's a pity, though.

David WHITE
CONNECT AUSTRIA