RE: Multiple concurrent client connections
Do you mean concurrent connections of the same user? That is by design. == Rene From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Mike Nwaogu Sent: Sunday, 01 April, 2012 01:02 To: users@kannel.org Subject: Multiple concurrent client connections I'm looking to increase the allowable number of concurrent smpp client connections. I run opensmppbox and currently, only two simultaneous connection stay connected after the initial verification process. The others may connect but I'm only able to use two at the same time as the other(s) keep breaking the connection ever so often. Suggestions, will help. Best Regards, Mike Ben Abel.
the tariff code
Dears, I faced problem kannel 1.5.0 in the tariff code; I connect with the USA operator with the SMPP protocol so I have a TLV parameter for the tariff code (0x1401) the following my TLV configuration: group = smpp-tlv name = TLV-name tag = 0x1401 type = octetstring length = 20 smsc-id = x Also in the MT ULR to send message I add the parameter binfo=C500 it mean the handset will be charge the 5 dollars, when use the wireshark to check the packet between my kannel server and SMSC I cannot see the optional parameter so this message not charge with 5 dollars. So I need to help to solve my problem, Best Regards Michael
Incorrect DLR mapping
Hi, I searched the list for incorrect Dlr mapping and found some of the threads discussing what was close to our issue, but that was with CIMD and other smsc types not with SMPP. Hence I ask the following: Bearerbox puts 13 as the 'ts' field value which is also found in the Sent Sms entry in access_server.log. Mentioned below is an example trace: Subtmit_sm: 2012-03-22 11:28:01 [5391] [32] DEBUG: SMPP[R05]: Sending PDU: 2012-03-22 11:28:01 [5391] [32] DEBUG: SMPP PDU 0xff37170 dump: 2012-03-22 11:28:01 [5391] [32] DEBUG: type_name: submit_sm 2012-03-22 11:28:01 [5391] [32] DEBUG: command_id: 4 = 0x0004 2012-03-22 11:28:01 [5391] [32] DEBUG: command_status: 0 = 0x 2012-03-22 11:28:01 [5391] [32] DEBUG: sequence_number: 1147800 = 0x00118398 2012-03-22 11:28:01 [5391] [32] DEBUG: service_type: NULL 2012-03-22 11:28:01 [5391] [32] DEBUG: source_addr_ton: 0 = 0x 2012-03-22 11:28:01 [5391] [32] DEBUG: source_addr_npi: 1 = 0x0001 2012-03-22 11:28:01 [5391] [32] DEBUG: source_addr: Demo 2012-03-22 11:28:01 [5391] [32] DEBUG: dest_addr_ton: 0 = 0x 2012-03-22 11:28:01 [5391] [32] DEBUG: dest_addr_npi: 1 = 0x0001 2012-03-22 11:28:01 [5391] [32] DEBUG: destination_addr: xxx9209x 2012-03-22 11:28:01 [5391] [32] DEBUG: esm_class: 3 = 0x0003 2012-03-22 11:28:01 [5391] [32] DEBUG: protocol_id: 0 = 0x 2012-03-22 11:28:01 [5391] [32] DEBUG: priority_flag: 0 = 0x 2012-03-22 11:28:01 [5391] [32] DEBUG: schedule_delivery_time: NULL 2012-03-22 11:28:01 [5391] [32] DEBUG: validity_period: NULL 2012-03-22 11:28:01 [5391] [32] DEBUG: registered_delivery: 1 = 0x0001 2012-03-22 11:28:01 [5391] [32] DEBUG: replace_if_present_flag: 0 = 0x 2012-03-22 11:28:01 [5391] [32] DEBUG: data_coding: 0 = 0x 2012-03-22 11:28:01 [5391] [32] DEBUG: sm_default_msg_id: 0 = 0x 2012-03-22 11:28:01 [5391] [32] DEBUG: sm_length: 159 = 0x009f 2012-03-22 11:28:01 [5391] [32] DEBUG: short_message: 2012-03-22 11:28:01 [5391] [32] DEBUG:Octet string at 0xbd3fa20: 2012-03-22 11:28:01 [5391] [32] DEBUG: len: 159 2012-03-22 11:28:01 [5391] [32] DEBUG: size: 160 2012-03-22 11:28:01 [5391] [32] DEBUG: immutable: 0 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 53 70 65 63 69 61 6c 20 50 72 69 63 65 20 46 6f Special Price Fo 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 72 20 33 20 44 61 79 73 20 46 6f 72 20 50 72 65 r 3 Days For Pre 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 2d 4c 61 75 6e 63 68 20 50 72 6f 6a 65 63 74 20 -Launch Project 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 49 6e 20 54 68 61 6e 65 20 28 77 29 2e 20 31 2c In Thane (w). 1, 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 20 31 2e 35 2c 20 32 20 26 20 33 20 42 48 4b 731.5, 2 3 BHKs 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 20 34 35 20 6c 61 63 73 20 4f 6e 77 61 72 64 7345 lacs Onwards 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 2e 20 52 69 76 65 72 20 26 20 4d 6f 75 6e 74 61 . River Mounta 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 69 6e 20 56 69 65 77 2e 20 41 6c 6c 20 4d 6f 64 in View. All Mod 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 65 72 6e 20 41 6d 65 6e 69 74 69 65 73 2e 20 43 ern Amenities. C 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 61 6c 6c 20 39 39 33 30 32 35 34 38 38 33 2e all xxx. 2012-03-22 11:28:01 [5391] [32] DEBUG:Octet string dump ends. 2012-03-22 11:28:01 [5391] [32] DEBUG: SMPP PDU dump ends. submit_sm_resp: === 2012-03-22 11:28:02 [5391] [32] DEBUG: SMPP[R05]: Got PDU: 2012-03-22 11:28:02 [5391] [32] DEBUG: SMPP PDU 0xff37170 dump: 2012-03-22 11:28:02 [5391] [32] DEBUG: type_name: submit_sm_resp 2012-03-22 11:28:02 [5391] [32] DEBUG: command_id: 2147483652 = 0x8004 2012-03-22 11:28:02 [5391] [32] DEBUG: command_status: 0 = 0x 2012-03-22 11:28:02 [5391] [32] DEBUG: sequence_number: 1147800 = 0x00118398 2012-03-22 11:28:02 [5391] [32] DEBUG: message_id: 2012-03-22 11:28:02 [5391] [32] DEBUG:Octet string at 0xa9f2ba0: 2012-03-22 11:28:02 [5391] [32] DEBUG: len: 29 2012-03-22 11:28:02 [5391] [32] DEBUG: size: 30 2012-03-22 11:28:02 [5391] [32] DEBUG: immutable: 0 2012-03-22 11:28:02 [5391] [32] DEBUG: data: 64 74 65 63 68 70 6c 2d 31 33 33 32 33 39 35 37 dtechpl-13323957 2012-03-22 11:28:02 [5391] [32] DEBUG: data: 31 33 33 35 37 2d 34 30 2d 30 32 30 3213357-40-0202 2012-03-22 11:28:02 [5391] [32] DEBUG:Octet string dump ends. 2012-03-22 11:28:02 [5391] [32] DEBUG: SMPP PDU dump ends. 2012-03-22 11:28:02 [5391] [32] DEBUG: DLR[mysql]: Adding DLR smsc=R05, ts=13, src=Demo, dst=xxx9209x, mask=3, boxc=SMSZING 2012-03-22 11:28:02 [5391] [32] DEBUG: adding DLR entry into database 2012-03-22 11:28:02 [5391] [32] DEBUG: sql: INSERT INTO `Dlr` (`smsc`, `ts`, `source`, `destination`, `service`, `url`, `mask`, `boxc`, `status`)
redmine.kannel.org gives a 500 error
can you please check? ta
Re: the tariff code
Hi, you have to send metadata in your request that include tlv name. Please check metadata section in userguide. Thanks, Alex Am 01.04.2012 um 12:55 schrieb Michael Farouk: Dears, I faced problem kannel 1.5.0 in the tariff code; I connect with the USA operator with the SMPP protocol so I have a TLV parameter for the tariff code (0x1401) the following my TLV configuration: group = smpp-tlv name = TLV-name…. tag = 0x1401 type = octetstring length = 20 smsc-id = x Also in the MT ULR to send message I add the parameter binfo=C500 it mean the handset will be charge the 5 dollars, when use the wireshark to check the packet between my kannel server and SMSC I cannot see the optional parameter so this message not charge with 5 dollars. So I need to help to solve my problem, Best Regards Michael
Re: Inconsistent behavior around encoding and SMPP
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 coding=2 Then kannel will do it for you. Thanks, Alex Am 31.03.2012 um 00:45 schrieb 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 parameter: from my understand of the docs, it's actually irrelevant to the SMPP stuff, this is just for you to tell smsbox which percent encoding your text is in (URLs only support ascii). It defaults to UTF-8 in the newer versions and this is what prefer to use. But the important thing is that it has no relevance to the data_coding that gets sent over SMPP. On Fri, Mar 30, 2012 at 3:20 PM, spameden spame...@gmail.com wrote: 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 to 2, for 7bit, 8bit or UCS-2. If unset, defaults to 7 bits unless a udh is defined, which sets coding to 8bits. so coding=2 stands for UCS-2 message. 2012/3/31 chad selph chad.se...@gmail.com 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 0 0 0 1 1 Latin1(ISO-8859-1) 0 0 0 0 0 1 0 0 Octet unspecified (8-bit binary) 0 0 0 0 0 1 0 1 JIS(X0208-1990) 0 0 0 0 0 1 1 0 Cyrllic(ISO-8859-5) 0 0 0 0 0 1 1 1 Latin/Hebrew (ISO-8859-8) 0 0 0 0 1 0 0 0 UCS2(ISO/IEC-10646) ... and some others. To initiate MT messages, we're using the sendsms http interface on smsbox (the one here: http://www.kannel.org/download/1.5.0/userguide-1.5.0/userguide.html#AEN4623 ). It looks like the only relevant parameter into the sendsms is the coding parameter, which can only be 0, 1, or 2. 0 causes data_coding 0, 1 causes 4, and 2 causes 8. I don't see a way to set data_coding to 3, for example, in order to do Latin-1. Another thing is that only 0 causes the message text to get encoded from UTF-8 (input encoding from http) into the correct encoding. For example, sending the UTF-8 data with coding=2 does not re-encode the message into USC-2, but just sends your UTF-8 bytes as if they were UCS-2 but sending utf8 data with coding=0 does re-encode them into GSM. These things seem to me to be incorrect behavior, however given the wide use of kannel I figured I should make sure I'm not missing something obvious before I draft a patch to attempt to fix them. Am I missing something?
Re: Inconsistent behavior around encoding and SMPP
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 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 coding=2 Then kannel will do it for you. Thanks, Alex Am 31.03.2012 um 00:45 schrieb 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 parameter: from my understand of the docs, it's actually irrelevant to the SMPP stuff, this is just for you to tell smsbox which percent encoding your text is in (URLs only support ascii). It defaults to UTF-8 in the newer versions and this is what prefer to use. But the important thing is that it has no relevance to the data_coding that gets sent over SMPP. On Fri, Mar 30, 2012 at 3:20 PM, spameden spame...@gmail.com wrote: 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 to 2, for 7bit, 8bit or UCS-2. If unset, defaults to 7 bits unless a udh is defined, which sets coding to 8bits. so coding=2 stands for UCS-2 message. 2012/3/31 chad selph chad.se...@gmail.com 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 0 0 0 1 1 Latin1(ISO-8859-1) 0 0 0 0 0 1 0 0 Octet unspecified (8-bit binary) 0 0 0 0 0 1 0 1 JIS(X0208-1990) 0 0 0 0 0 1 1 0 Cyrllic(ISO-8859-5) 0 0 0 0 0 1 1 1 Latin/Hebrew (ISO-8859-8) 0 0 0 0 1 0 0 0 UCS2(ISO/IEC-10646) ... and some others. To initiate MT messages, we're using the sendsms http interface on smsbox (the one here: http://www.kannel.org/download/1.5.0/userguide-1.5.0/userguide.html#AEN4623). It looks like the only relevant parameter into the sendsms is the coding parameter, which can only be 0, 1, or 2. 0 causes data_coding 0, 1 causes 4, and 2 causes 8. I don't see a way to set data_coding to 3, for example, in order to do Latin-1. Another thing is that only 0 causes the message text to get encoded from UTF-8 (input encoding from http) into the correct encoding. For example, sending the UTF-8 data with coding=2 does not re-encode the message into USC-2, but just sends your UTF-8 bytes as if they were UCS-2 but sending utf8 data with coding=0 does re-encode them into GSM. These things seem to me to be incorrect behavior, however given the wide use of kannel I figured I should make sure I'm not missing something obvious before I draft a patch to attempt to fix them. Am I missing something?
Re: Inconsistent behavior around encoding and SMPP
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 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 coding=2 Then kannel will do it for you. Thanks, Alex Am 31.03.2012 um 00:45 schrieb 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 parameter: from my understand of the docs, it's actually irrelevant to the SMPP stuff, this is just for you to tell smsbox which percent encoding your text is in (URLs only support ascii). It defaults to UTF-8 in the newer versions and this is what prefer to use. But the important thing is that it has no relevance to the data_coding that gets sent over SMPP. On Fri, Mar 30, 2012 at 3:20 PM, spameden spame...@gmail.com wrote: 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 to 2, for 7bit, 8bit or UCS-2. If unset, defaults to 7 bits unless a udh is defined, which sets coding to 8bits. so coding=2 stands for UCS-2 message. 2012/3/31 chad selph chad.se...@gmail.com 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 0 0 0 1 1 Latin1(ISO-8859-1) 0 0 0 0 0 1 0 0 Octet unspecified (8-bit binary) 0 0 0 0 0 1 0 1 JIS(X0208-1990) 0 0 0 0 0 1 1 0 Cyrllic(ISO-8859-5) 0 0 0 0 0 1 1 1 Latin/Hebrew (ISO-8859-8) 0 0 0 0 1 0 0 0 UCS2(ISO/IEC-10646) ... and some others. To initiate MT messages, we're using the sendsms http interface on smsbox (the one here: http://www.kannel.org/download/1.5.0/userguide-1.5.0/userguide.html#AEN4623 ). It looks like the only relevant parameter into the sendsms is the coding parameter, which can only be 0, 1, or 2. 0 causes data_coding 0, 1 causes 4, and 2 causes 8. I don't see a way to set data_coding to 3, for example, in order to do Latin-1. Another thing is that only 0 causes the message text to get encoded from UTF-8 (input encoding from http) into the correct encoding. For example, sending the UTF-8 data with coding=2 does not re-encode the message into USC-2, but just sends your UTF-8 bytes as if they were UCS-2 but sending utf8 data with coding=0 does re-encode them into GSM. These things seem to me to be incorrect behavior, however given the wide use of kannel I figured I should make sure I'm not missing something obvious before I draft a patch to attempt to fix them. Am I missing something?
Re: Inconsistent behavior around encoding and SMPP
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 amal...@kannel.org 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 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 coding=2 Then kannel will do it for you. Thanks, Alex Am 31.03.2012 um 00:45 schrieb 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 parameter: from my understand of the docs, it's actually irrelevant to the SMPP stuff, this is just for you to tell smsbox which percent encoding your text is in (URLs only support ascii). It defaults to UTF-8 in the newer versions and this is what prefer to use. But the important thing is that it has no relevance to the data_coding that gets sent over SMPP. On Fri, Mar 30, 2012 at 3:20 PM, spameden spame...@gmail.com wrote: 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 to 2, for 7bit, 8bit or UCS-2. If unset, defaults to 7 bits unless a udh is defined, which sets coding to 8bits. so coding=2 stands for UCS-2 message. 2012/3/31 chad selph chad.se...@gmail.com 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 0 0 0 1 1 Latin1(ISO-8859-1) 0 0 0 0 0 1 0 0 Octet unspecified (8-bit binary) 0 0 0 0 0 1 0 1 JIS(X0208-1990) 0 0 0 0 0 1 1 0 Cyrllic(ISO-8859-5) 0 0 0 0 0 1 1 1 Latin/Hebrew (ISO-8859-8) 0 0 0 0 1 0 0 0 UCS2(ISO/IEC-10646) ... and some others. To initiate MT messages, we're using the sendsms http interface on smsbox (the one here: http://www.kannel.org/download/1.5.0/userguide-1.5.0/userguide.html#AEN4623). It looks like the only relevant parameter into the sendsms is the coding parameter, which can only be 0, 1, or 2. 0 causes data_coding 0, 1 causes 4, and 2 causes 8. I don't see a way to set data_coding to 3, for example, in order to do Latin-1. Another thing is that only 0 causes the message text to get encoded from UTF-8 (input encoding from http) into the correct encoding. For example, sending the UTF-8 data with coding=2 does not re-encode the message into USC-2, but just sends your UTF-8 bytes as if they were UCS-2 but sending utf8 data with coding=0 does re-encode them into GSM. These things seem to me to be incorrect behavior, however given the wide use of kannel I figured I should make sure I'm not missing something obvious before I draft a patch to attempt to fix them. Am I missing something?
Re: Inconsistent behavior around encoding and SMPP
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 to 0, 4, 8 respectively. I was interested in particular in Latin-1 which is data_coding 3 in the SMPP spec. My current understanding is that you can't sent data_coding=3 over SMPP: is this the case or have I missed something? I never said that coding=2 didn't set data_coding to 8; I just thought that the UTF-8 bytes were sent directly instead of being convert into UCS-2. However, now I realize I need to be passing charset=utf8 explicitly (which I mistakingly thought was default; it's only default when coding=0) in order for the re-encoding to happen. Sorry about asking multiple related questions in the same message, I should have been more clear about their separation. On Sun, Apr 1, 2012 at 3:41 PM, spameden spame...@gmail.com wrote: 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 amal...@kannel.org 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 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 coding=2 Then kannel will do it for you. Thanks, Alex Am 31.03.2012 um 00:45 schrieb 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 parameter: from my understand of the docs, it's actually irrelevant to the SMPP stuff, this is just for you to tell smsbox which percent encoding your text is in (URLs only support ascii). It defaults to UTF-8 in the newer versions and this is what prefer to use. But the important thing is that it has no relevance to the data_coding that gets sent over SMPP. On Fri, Mar 30, 2012 at 3:20 PM, spameden spame...@gmail.com wrote: 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 to 2, for 7bit, 8bit or UCS-2. If unset, defaults to 7 bits unless a udh is defined, which sets coding to 8bits. so coding=2 stands for UCS-2 message. 2012/3/31 chad selph chad.se...@gmail.com 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 0 0 0 1 1 Latin1(ISO-8859-1) 0 0 0 0 0 1 0 0 Octet unspecified (8-bit binary) 0 0 0 0 0 1 0 1 JIS(X0208-1990) 0 0 0 0 0 1 1 0 Cyrllic(ISO-8859-5) 0 0 0 0 0 1 1 1 Latin/Hebrew (ISO-8859-8) 0 0 0 0 1 0 0 0 UCS2(ISO/IEC-10646) ... and some others. To initiate MT messages, we're using the sendsms http interface on smsbox (the one here: http://www.kannel.org/download/1.5.0/userguide-1.5.0/userguide.html#AEN4623). It looks like the only relevant parameter into the sendsms is the coding parameter, which can only be 0, 1, or 2. 0 causes data_coding 0, 1 causes 4, and 2 causes 8. I don't see a way to set data_coding to 3, for example, in order to do Latin-1. Another thing is that only 0 causes the message text to get encoded from UTF-8 (input encoding from http) into the correct encoding. For example, sending the UTF-8 data with coding=2 does not re-encode the message into USC-2, but just sends your UTF-8 bytes as if they were UCS-2 but sending utf8 data with coding=0 does re-encode them into GSM. These things seem to me to be incorrect behavior, however given the wide use of kannel I figured I should make sure I'm not missing something obvious before I draft a patch to attempt to fix them. Am I missing something?
Re: Inconsistent behavior around encoding and SMPP
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 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). Reading from the google: Depending on the chosen ESME data coding the short message text data is sent from the SMSC to the mobile in one of the following ways: Transparently Mapped to the default GSM alphabet 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. 2012/4/2 chad selph chad.se...@gmail.com 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 to 0, 4, 8 respectively. I was interested in particular in Latin-1 which is data_coding 3 in the SMPP spec. My current understanding is that you can't sent data_coding=3 over SMPP: is this the case or have I missed something? I never said that coding=2 didn't set data_coding to 8; I just thought that the UTF-8 bytes were sent directly instead of being convert into UCS-2. However, now I realize I need to be passing charset=utf8 explicitly (which I mistakingly thought was default; it's only default when coding=0) in order for the re-encoding to happen. Sorry about asking multiple related questions in the same message, I should have been more clear about their separation. On Sun, Apr 1, 2012 at 3:41 PM, spameden spame...@gmail.com wrote: 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 amal...@kannel.org 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 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 coding=2 Then kannel will do it for you. Thanks, Alex Am 31.03.2012 um 00:45 schrieb 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 parameter: from my understand of the docs, it's actually irrelevant to the SMPP stuff, this is just for you to tell smsbox which percent encoding your text is in (URLs only support ascii). It defaults to UTF-8 in the newer versions and this is what prefer to use. But the important thing is that it has no relevance to the data_coding that gets sent over SMPP. On Fri, Mar 30, 2012 at 3:20 PM, spameden spame...@gmail.com wrote: 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 to 2, for 7bit, 8bit or UCS-2. If unset, defaults to 7 bits unless a udh is defined, which sets coding to 8bits. so coding=2 stands for UCS-2 message. 2012/3/31 chad selph chad.se...@gmail.com 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 0 0 0 1 1 Latin1(ISO-8859-1) 0 0 0 0 0 1 0 0 Octet
Re: Inconsistent behavior around encoding and SMPP
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.
