Opening the ShortMessage

[Hurtsich]

Hello, It's me again, we have another issue with the same mobile provider (i know -_-) This provider doesn't respect the standard encoding mapping (0 for GSM7, 1 for ASCII, etc...) We need to create a ShortMessage with a certain encoded message but in the payload we need to specify a different encoding.

With our recent exchanges, I propose two solutions:

• We open the ShortMessage (thus breaking the public interface), by rendering "message", "enc" and "messageData" fields public.
• We add a setter for the encoding which gives us the possibility to override it.

[laduchesneau]

@Hurtsich Did you ever create the code for what you proposed ?

I also ran into this issue because of how the DCS is harcoded to a encoding in the library. For example, DCS 0 as per the spec is the default encoding of the SMSC, but in the gosmpp, DCS 0 means GSM encoding. The SMSC I connect too uses DCS 0 for latin-1, and when receiving a DeliverSM with DCS 0, the library isn't able to decode the message correctly.

[goten4]

@Hurtsich : I think you can use the following constructor :

pdu.NewBinaryShortMessageWithEncoding(data, encoding)

Or simply use :

shortMessage.SetMessageDataWithEncoding(data, encoding)

In both cases, you will first have to encode the message yourself in the data.

[Hurtsich]

@laduchesneau Yeah, we forked the lib for this use cases. I can open a PR with the changes. I wanted to wait the answer of @linxGnu to open it, but i will do it sooner than later ;)

[linxGnu]

@Hurtsich Please feel free to make the PR and assign people here to review 👍

[laduchesneau]

I do like @goten4 solution, it works for me. I don't know why I didn't think of it before. (Merci @goten4)

User can pass their own encoding via CustomEncoding, and force what ever byte they want for DCS.

The user can retrieve the message with a predefine encoding

deliverSM.Message.GetMessageWithEncoding( data.UCS2 )

or with a custom encoding

deliverSM.Message.GetMessageWithEncoding( CustomEncoding )

or without encoding and fully handle message decoding on their end

deliverSM.Message.GetMessageData()

[Hurtsich]

Yeah, the way proposed by @goten4 works and it's already in the lib. My bad :/