-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MessageClass mask placement collides with alphabet #159
Comments
I think we have a problem here. The data coding scheme you mentioned, is the GSM 03.38 / 3GPP 23.040 / 3GPP 23.038 specification. This DCS is used in the mobile network as TP-DCS. The SMPP DCS is specified in the SMPP 3.4 / 5.0 specification. For SMPP, the Latin1 DCS has value 0x03, which can get with GeneralDataCoding(Alphabet.ALPHA_LATIN1). The GenericCoding class uses the MessageClass and compress bit, which are not in the SMPP spec but in the GSM spec (see also https://en.wikipedia.org/wiki/Data_Coding_Scheme). I will have to go through the GeneralCoding class and see how to correct this. It could be that some GSM only SMPP gateways will uses these value transparently. Please also not from the SMPP spec: I also see that in SMPP 3.3, the DCS is defined as GSM Data-Coding-Scheme ( See GSM 03.40 [2] 9.2.3.10), whereby in SMPP 3.4 and 5.0 it is the SMPP specific DCS. |
The GeneralCoding combines the GSM 03.40 and SMPP DCS which is not very clear. The GSM 03.40 only uses the default (GSM), binary and UCS2. But the GeneralCoding doesn't check this. I will refactor this and make a new DataCoding, clearly separating the GSM and SMPP usages. |
After some more thoughts, the Latin1 alphabet is not intended to be used with a message class. The valid calls are below. I will first add a simple check to verify the alphabet when the message class is specified, like:
|
Suppose I want to do the following:
I want to send an uncompressed Message Class 1 with Latin1 alphabet. This would mean, according to the SMPP specification, that I should have a data coding byte that looks like the following.
To do this, I do the following:
The byte value of this is translated to 0x13, which is 00010011. What is going on here? It looks like the message class and encoding are encoded at the same position. I should be getting 0x15, which is 00010101.
Let's try with an uncompressed UCS-2 class 0 message. According to the spec, I should be sending
Which is hex 0x18. Doing this in Java
This looks ok! Ok, to condense this a little bit, a test like this
prints
So the default alphabet and ucs-2 work just fine, but something is off with latin1.
I think the reason is in the
toByte
method of GeneralDataCoding:For alphabets default and ucs-2, the masks are 0b00000000 and 0b00001000. If the message class is defined, this works correctly. But the mask for latin1 is 0x03, 0b00000011. This is the same as the message class mask! So essentially, due to luck, alphabets default and ucs-2 work. What should be done instead is something like
The reason why I'm opening an issue here is to ask for confirmation. Am I thinking this correctly? According to the specification, IF a message class is defined, the alphabet should move to bits 3-2 and the message class should be on bits 0-1.
The text was updated successfully, but these errors were encountered: