camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Pocock <>
Subject Re: camel-smpp clarifications
Date Thu, 06 Nov 2014 12:54:57 GMT
On 06/11/14 09:41, Daniel Pocock wrote:
> 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?
I sent a pull request for jSMPP to add extra alphabet values:

If this is accepted, then it means that camel-smpp will need to be
patched to allow the new values.

> 1.

View raw message