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 Alphabet.java 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:
https://github.com/uudashr/jsmpp/pull/39
If this is accepted, then it means that camel-smpp will need to be
patched to allow the new values.
>
> 1.
> https://help.nexmo.com/hc/en-us/articles/204015813-How-to-change-the-character-encoding-in-SMPP-
>
>
