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