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? 1. https://help.nexmo.com/hc/en-us/articles/204015813-How-to-change-the-character-encoding-in-SMPP-
