Re: Inconsistent behavior around encoding and SMPP

2012-04-01 Thread Alexander Malysh
Hi, cyrillic can only be send with ucs2 therefore coding=2. Kannel behavior for coding=2 and 3 is simple: don't touch it it's binary and up to user to encode it BUT if you need that kannel converts some charset to ucs2 for you then just use two params: charset=YOUR_CHARSET

Re: Inconsistent behavior around encoding and SMPP

2012-04-01 Thread spameden
Exactly what I've said :) If your source text is in utf8 you need to specify charset=utf8 and coding=2. 2012/4/2 Alexander Malysh amal...@kannel.org Hi, cyrillic can only be send with ucs2 therefore coding=2. Kannel behavior for coding=2 and 3 is simple: don't touch it it's binary and up

Re: Inconsistent behavior around encoding and SMPP

2012-04-01 Thread Alexander Malysh
Then I don't understand what should be the issue here :-) ? Thanks, Alex Am 01.04.2012 um 23:15 schrieb spameden: Exactly what I've said :) If your source text is in utf8 you need to specify charset=utf8 and coding=2. 2012/4/2 Alexander Malysh amal...@kannel.org Hi, cyrillic can only

Re: Inconsistent behavior around encoding and SMPP

2012-04-01 Thread spameden
I think Chad was referring to But the important thing is that it has no relevance to the data_coding that gets sent over SMPP to the coding specified in the SMPP message... I've just checked in kannel smpp logs it sets data_coding: 8 = 0x0008 when coding=2 specified. 2012/4/2 Alexander Malysh

Re: Inconsistent behavior around encoding and SMPP

2012-04-01 Thread chad selph
That sentence was about the charset parameter (not coding). The charset parameter has no effect on data_coding integer. Only the coding can effect it, but its effects are quite limited. SMPP has several encodings in the spec (listed in my first email) but coding 0,1,2 can only set data_coding

Re: Inconsistent behavior around encoding and SMPP

2012-04-01 Thread spameden
Correct, sir. Also had this problem when was testing out kannel's functionality for non-english symbols. (i.e. if you don't set charset=utf8 you'd get bollocks on your phone instead). Would be good if this moment could be covered in kannel's user guide. About coding=3, yes you're right coding=3

Re: Inconsistent behavior around encoding and SMPP

2012-04-01 Thread chad selph
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

Inconsistent behavior around encoding and SMPP

2012-03-30 Thread chad selph
I'm trying to figure out how to send different data encodings from Kannel 1.5.0 over SMPP. The SMPP Spec lists the following options for data_coding field: 0 0 0 0 0 0 0 0 SMSC Default Alphabet 0 0 0 0 0 0 0 1 IA5(CCITTT.50)/ASCII(ANSIX3.4) 0 0 0 0 0 0 1 0 Octet unspecified (8-bit binary) 0 0 0

Re: Inconsistent behavior around encoding and SMPP

2012-03-30 Thread spameden
utf8 + coding=0 never worked for me for cyrillic text messages. the only combination is coding=2 charset=utf8, otherwise I'm getting bollocks on mobile screen. according to the kannel's documentation, coding is: coding number Optional. Sets the coding scheme bits in DCS field. Accepts values 0

Re: Inconsistent behavior around encoding and SMPP

2012-03-30 Thread chad selph
I understand that coding=2 stands for UCS-2 but the problem I'm pointing out is that it doesn't actually re-encode the UTF8 bytes into actual UCS-2 bytes. This is inconsistent because it will convert utf8 to GSM, or to Latin-1 (if the alt-charset is set to Latin1). As far as the charset