camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Pocock <>
Subject camel-smpp clarifications
Date Thu, 06 Nov 2014 08:41:52 GMT

We previously discussed camel-smpp in another thread and there have been
some patches which help receiving messages

I'd like to raise this again for some clarification because I don't know
the full history of this but I can see that things changed at several
points in the history of the repository.

- alphabet vs. data_coding.   data_coding is a message property as
defined in the SMPP spec.  alphabet is not explicitly defined in the
spec.  The camel-smpp page refers to alphabet as Camel 2.5 and
dataCoding as Camel 2.11.  It is very terse.  The casual reader may form
the impression that dataCoding deprecates the alphabet parameter. 
Looking at the code in both camel-smpp and jSMPP I formed the impression
that jSMPP uses the alphabet object to map a subfield of the data_coding
field, a convenience for representing the values permitted in the lower
4 bits of data_coding.  Maybe this needs to be explicitly explained on
the camel-smpp web page so that people don't have to look in multiple
places to figure it out.  Is this a reasonable summary of the
situation?  Could anybody help explain the relationship between these
parameters (and their history in Camel) more concisely?

- automatic detection of alphabet - I still think this is insufficient
and I'll submit a patch.  For example, the determineAlphabet() method
calls String.getBytes() (which returns UTF-8) and gives the bytes to
isGsm0338Encodeable() (which only expects Latin1).  determineCharset()
doesn't work for the case where providedAlphabet == Alphabet.ALPHA_UCS2.

- determineAlphabet appears to assume that all providers use GSM 3.38 as
default (for data_coding==0) although some providers may use Latin1 or
something else.

- Some providers actually ignore the data_coding values sent in the
messages (e.g. Nexmo[1]) and they have some configurable default in
their web control panel.  camel-smpp probably needs to be flexible
enough for users to tell it about such limitations and
determineCharset() should work within these limitations.

- jSMPP only maps the values 0, 4 and 8.  camel-smpp has a
workaround for the value 2.  The value 3, for Latin1, is not handled. 
Was this ever discussed with the jSMPP people?  They appear to use
Github now, maybe I should just send them a pull request to add the
extra values or have they already given some reason for not accepting
changes to this?  Can anybody provide links to any discussion thread
about that?


View raw message