Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Wed, 28 Sep 2011 05:45:46 +0000 (UTC)
From: =?utf-8?Q?Christian_M=C3=BCller_=28Assigned=29_=28JIRA=29?=
 <jira@apache.org>
To: dev@camel.apache.org
Message-ID: 
 <894926328.2584.1317188746015.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <179944146.2158.1317111373818.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Assigned] (CAMEL-4491) dataCoding not working properly in
 camel-smpp
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/CAMEL-4491?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian M=C3=BCller reassigned CAMEL-4491:
---------------------------------------

    Assignee: Christian M=C3=BCller
   =20
> dataCoding not working properly in camel-smpp
> ---------------------------------------------
>
>                 Key: CAMEL-4491
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4491
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-smpp
>    Affects Versions: 2.7.0, 2.8.0, 2.9.0
>            Reporter: Jonas Bengtsson
>            Assignee: Christian M=C3=BCller
>         Attachments: patch.txt
>
>
> This is related to CAMEL-3093.
> The way the dataCoding option works is incorrect (or at least very confus=
ing). After reading the documentation I was under the impression that the g=
iven value would be used in the data_coding-part of the submit_sm PDU-packe=
ts, but this is not the case. When 0 is given as dataCoding 0x11 (hexadecim=
al) is sent in the PDU-packets. If 4 is specified 0x15 is sent, and if 8 is=
 specified then 0x19 is sent. This is caused in SmppProducer by the use of =
the constructor with several parameters:
> {code}
> new GeneralDataCoding(
>         false,
>         true,
>         MessageClass.CLASS1,
>         Alphabet.valueOf(submitSm.getDataCoding()))
> {code}
> It constructs a DCS-value as defined in the GSM 03.38 specification, not =
as specified in the SMPP specification. 0x11 is for example a valid DCS-val=
ue in GSM 03.38, but is reserved in SMPP. I think that it would be better a=
nd more logical if the constructor with one parameter was used instead:
> {code}
> new GeneralDataCoding(submitSm.getDataCoding())
> {code}
> This is more flexibal (DCS-values can still be created manually) and is a=
 better default value (0 instead of 0x11). With my SMS-center (this probabl=
y varies between centers though) a data_coding of 0x11 forces me to do the =
7-bit GSM decoding myself. When 0 is specified (or 3) all I have to do is t=
o pass it ISO-8859-1 encoded bytes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira