RE: DCS bug ?

> but it's simple:
> alt_dcs flag is used to define either 0xFX coding (alt_dcs=1) 
> or 0x0X coding 
> (alt_dcs=0). alt_dcs may be SMS_PARAM_UNDEF==-1 only if 
> message was generated 
> on the extern interface (e.g. sendsms in smsbox) and user has 
> not supplied 
> any dcs values. Inverse to that, when we have a dcs value and call 
> dcs_to_fields function, because we allways know which value 
> alt_dcs has, 
> otherwise how was it possible to decode dcs?

My use case is this; I have an application that reads an incoming SMPP
SUBMIT SM PDU and converts it into a Msg, called dcs_to_fields() as
it does.  This operation was setting alt_dcs to 0.

I then send the Msg into the Bearer Box where it gets routed over the
SMPP driver. The code;

    else
        pdu->u.submit_sm.data_coding = fields_to_dcs(msg,
            (msg->sms.alt_dcs != SMS_PARAM_UNDEFINED ?
             msg->sms.alt_dcs : smpp->conn->alt_dcs));

interprets an alt_dcs of 0 as enabling, and consequently sets alt_dcs in
the fields_to_dcs () call. 

So I've taken in an SMPP SUBMIT SM PDU, converted it using dcs_to_fields()
(and others) into a normalised Msg, given it to the Bearer Box which
converts it back into a SMPP SUBMIT SM PDU using fields_to_dcs() and I 
end with a different DCS value from the original PDU.

I agree that its not a problem with Kannel because Kannel does'nt use the
gwapp library like this.