I will have a look at it tomorrow. Best, Christian
On Tue, Feb 7, 2012 at 3:08 PM, andrer <aro...@gmail.com> wrote: > I've had some more time to study both the jsmpp and Camel-smpp code. > > The way Camel-smpp abstracts the data coding by using an Alphabet property > and then deriving a datacode value by using a hard coded Message > Class(class > 1) restricts the possible datacoding values one can send to an smsc. (I am > referring to the SmppSubmitSmCommand class in particular). > > For example, for the Clickatell smsc provider they would like me to send a > datacode value of 0. With camel-smpp I can set the Alphabet property to 0, > but the resulting datacode value will be 17, because it is derived from > "GeneralDataCoding(false, true, MessageClass.CLASS1, > determinedAlphabet).value())". If you unit test that line of code with the > available Alphabet values you will see what I mean. > > So for me to be able to send a 0 to Clickatell, I would need something like > "GeneralDataCoding(false, false, MessageClass.CLASS0, > determinedAlphabet).value())". > > I think in order to provide an abstraction for the data coding, you will > need to provide configuration properties for all the parameters in the > GeneralDataCoding constructor. It would also be nice to have a way of > overriding this abstraction and allow one to explicitly set the datacoding > to a particular value(like my earlier requirement for a value of 245). > > I hope I am making some sense here :-) . > > I am still very impressed with the Camel project and the camel-smpp > component has simplified our smpp solution by a huge amount. > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Datacoding-Alphabet-issue-in-SMPP-tp5281005p5463217.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
