About coding=3, yes you're right coding=3 stands for LATIN1 in SMPP v3.4 > documentation. But coding=0 defines "SMSC Default Alphabet". > > So the question is "is LATIN1 encoding the same as 'SMSC Default > Alphabet'" ? And what is "SMSC Default Alphabet" actually ? (Most likely > its a LATIN1 aka ISO8859-1 encoding). >
I assume that data_coding=0 means GSM 03.38, although I understand that the SMSC could be non-conformant and do whatever it wants. > When text is sent from ESME to SMSC in USC2 coding the data will be > transparently sent to the mobile. When the text is coded in LATIN-1 or the > SMSC Default Alphabet, mapping will be performed by the SMSC to the GSM > Default Alphabet before sending the text to the mobile. As the GSM Default > Alphabet is 7-bit coded and uses other codes for some characters (and in > some cases does not even provide a certain character), this implies that > during the mapping process not every character can be mapped one-to-one." > > My understanding is that this behavior is sort of "up the the carriers" and it is possible to have a carrier and handset that does in fact support Latin-1, or even some other character set that it encodes the Latin-1 into without losing characters. It's starting to sound like I just shouldn't worry about attempting to send Latin-1 characters but instead stick to either GSM or UCS-2. The fact that Kannel won't send a PDU with data_coding=3 isn't really important because the handset will likely be reconverted into GSM somewhere down the road and lose all the characters in Latin-1 but not GSM. For non-GSM characters I'll be better off using USC-2 and doing concatenated SMS for anything longer than 70 characters. Anyway, thanks for helping me work through this. Much appreciated.
