RE: DCS and PID handling in Kannel

Citando Paul Keogh <[email protected]>:

> > > 
> > 
> > This isn't Kannel's decision to make; this is data set by the 
> > end user's 
> > telephone, which may have requirements neither you nor I are 
> > (or could 
> > be) aware of. The analogy to a case-insensitive filesystem 
> > namespace is 
> > quite fitting if you think about it carefully.
> > 
> > I did look at alt-dcs, and I consider it a kludge. Sorry.
> > 
> 
> You're absolutely right. I've had an explicit DCS value in the
> SMS Msg struct for ages. It's required because there are just
> too many SMSCs, MARs, front-ends and some devices that don't
> implement DCS according to the specs. The Kannel code for
> DCS is correct; its just inadequete in the face of so many
> other broken implementations - for example I have an SMSC
> link to an operator that will only accept an MT DCS value of 0
> regardless of any other message characteristics and this is
> an SMPP protocol link. Go figure.

About having dcs from smsc->kannel->appl, it's ok. We already have "text" with
(possibly) processed text, and "binary" with raw UD. We can also have mclass/etc
and raw dcs.

I just object of a dcs going in.

Sorry if I was rude about that.


-- 
Davi / Bruno.Rodrigues<at>Litux.Org
Litux.org: 01:23:08 up 91 days,  2:38,  7 users,  load average: 0.04, 0.10, 0.05
'Make it idiot-proof, and someone will breed a better idiot.
	-- Oliver Elphick'