Re: DCS bug ?

Stipe Tolj <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Organization Wapme Systems AG
Message-ID <[email protected]>
Paul Keogh wrote:
> 
> > 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.

hmmm, sounds like our smppbox you are talking about?! ... you didn't
steal it from us Paul, did you? ;))

Ok getting back serious. So this is a SMPP server (or at least) SMPP
proxy, right?

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

ok, that's an argument that can hold. If we consider proxying an
submit_sm PDU via a chain like this:

  [submit_sm] -> SMPP proxy -> [Msg] -> bearerbox -> [submit_sm] ->
SMPP server

then I do agree to Paul that the data coding values should be
transparently delivered to the submit_sm PDU that goes it's way out of
bearerbox.

Is it possible that we miss some other SMPP specific fields that come
into account while re-converting back again to submit_sm PDU?

Stipe

mailto:[email protected]
-------------------------------------------------------------------
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf, NRW, Germany

phone: +49.211.74845.0
fax: +49.211.74845.299

mailto:[email protected]
http://www.wapme-systems.de/
-------------------------------------------------------------------

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.2 (Cygwin)

mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS
OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2
nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT
dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv
bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl
OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ
K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H
g2HyLAEKQIp30Q==
=aYCI
-----END PGP PUBLIC KEY BLOCK-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.