Re: patch to allow data_coding to be set to 3

[Andreas Fink]

> On 08 Oct 2015, at 14:04, Hillel  wrote:
> 
> Hi Alex and Andreas,
> 
> Vodacom says send Latin-1 characters and set your data_coding field to 3 to 
> tell the SMSC to translate the characters from Latin-1 to GSM. So that if we 
> want to display the curly bracket ‘}’ you have to send the escape character 
> and the round bracket character: ESC + )  Data values:0x1B 0x29 and on the 
> phone you will see curly bracket ‘}’
> 

this is clearly non standard and it is not Latin1 neither. if you send } in 
UTF8 or latin1 into kannel then kannel will send 1B 29 on SMPP as thats the 
correct representaition in GSM cahracter set (DCS=0)

> How do you send this via Kannel if we can’t touch  the data_coding field?

you send "}" and kannel does the magic. You can see this in a tcpump or a 
kannel bearerbox core logfile (set log-level=0) in the submit_sm statement.

> If we can't send this correctly via Kannel to Vodacom SIM cards, will you 
> allow Kannel users to set the data_coding field?. (This means also allowing 
> the Kannel user to bypass the internal Kannel conversion so you can send 0x1B 
> 0x29 and the external SMSC will convert it to the curly bracket ‘} )

thats happening if you send =0=}

> 
> Below is our attempt to send the curly bracket ‘}’ if we can get this to work 
> we should be able to send all the other characters that are like this.
> If you see http://www.developershome.com/sms/gsmAlphabet.asp 
> 
> Right curly bracket is Hex 1B29 for GSM 7-bit default alphabet and 7D for ISO 
> 8859 Latin 1
> 
> lynx -dump 
> "http://41.185.24.138:13013/cgi-bin/sendsms?username=x=y=27831234567=%7D=27821278120=vodacom
>  
> 
>  "
> 
> In Smsbox it comes out as Right curly bracket:
> 2015-10-08 10:37:32 [28232] [3] INFO: sendsms sender: 
> to:<27831234567> msg:<}>
> 


> In Bearerbox it comes out as Right curly bracket:
> 2015-10-08 10:37:32 [28165] [12] DEBUG: SMPP[vodacom]: Sending PDU:
> 2015-10-08 10:37:32 [28165] [12] DEBUG: SMPP PDU 0x7f10a4007020 dump:
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   type_name: submit_sm
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   command_id: 4 = 0x0004
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   command_status: 0 = 0x
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   sequence_number: 2309 = 0x0905
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   service_type: NULL
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   source_addr_ton: 1 = 0x0001
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   source_addr_npi: 1 = 0x0001
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   source_addr: "27821278120"
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   dest_addr_ton: 1 = 0x0001
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   dest_addr_npi: 1 = 0x0001
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   destination_addr: "27831234567"
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   esm_class: 3 = 0x0003
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   protocol_id: 0 = 0x
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   priority_flag: 0 = 0x
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   schedule_delivery_time: NULL
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   validity_period: "151011103732000+"
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   registered_delivery: 0 = 0x
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   replace_if_present_flag: 0 = 
> 0x
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   data_coding: 0 = 0x
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   sm_default_msg_id: 0 = 0x
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   sm_length: 1 = 0x0001
> 2015-10-08 10:37:32 [28165] [12] DEBUG:   short_message: "}"

you should look at the bytes of the "short_message" not the visual 
representation. The visual representation is } but the bytes should be 1b 29. 
Check that with wireshark.

It could probably mean that your linx command sends some odd character set 
encoding in the HTTP request. The HTTP header will specify in which character 
set the request is.
Or you have some kannel config option to nail it to a specific one. Try the 
same with a browser or wget to see if you have different results.

> 
> But, on the cell phone it comes out as Small letter n with tilde.  Which is 
> 7D for the GSM 7-bit default alphabet
> This means Kannel is converting the 7D to }
> But Vodacom is not converting the 7D to } , as its expects the data_coding to 
> be 3 and to receive ESC + ) i.e. Data values:0x1B 0x29  so the cell phone 
> gets the wrong character.
> 
> If we try another approach and send %1B%29 which is the Right curly bracket 
> in GSM 7-bit default alphabet we get ?)
> on the cell phone.
> From bearerbox:   short_message: "?)"
> 
> Is there any way to send this via Kannel with its current internal encoding?

what version of kannel are you using? do you have any settings concerning 
character set in your 

Re: patch to allow data_coding to be set to 3

[hbilman]

Hi Alex and Andreas,

 

Vodacom says send Latin-1 characters and set your data_coding field to 3 to
tell the SMSC to translate the characters from Latin-1 to GSM. So that if we
want to display the curly bracket '}' you have to send the escape character
and the round bracket character: ESC + )  Data values:0x1B 0x29 and on the
phone you will see curly bracket '}'

 

How do you send this via Kannel if we can't touch  the data_coding field? 

If we can't send this correctly via Kannel to Vodacom SIM cards, will you
allow Kannel users to set the data_coding field?. (This means also allowing
the Kannel user to bypass the internal Kannel conversion so you can send
0x1B 0x29 and the external SMSC will convert it to the curly bracket '} ) 

 

Below is our attempt to send the curly bracket '}' if we can get this to
work we should be able to send all the other characters that are like this.

If you see http://www.developershome.com/sms/gsmAlphabet.asp 

Right curly bracket is Hex 1B29 for GSM 7-bit default alphabet and 7D for
ISO 8859 Latin 1

 

lynx -dump
"http://41.185.24.138:13013/cgi-bin/sendsms?username=x=y=2783123
4567=%7D=27821278120=vodacom "

 

In Smsbox it comes out as Right curly bracket:

2015-10-08 10:37:32 [28232] [3] INFO: sendsms sender:
to:<27831234567> msg:<}>

 

In Bearerbox it comes out as Right curly bracket:

2015-10-08 10:37:32 [28165] [12] DEBUG: SMPP[vodacom]: Sending PDU:

2015-10-08 10:37:32 [28165] [12] DEBUG: SMPP PDU 0x7f10a4007020 dump:

2015-10-08 10:37:32 [28165] [12] DEBUG:   type_name: submit_sm

2015-10-08 10:37:32 [28165] [12] DEBUG:   command_id: 4 = 0x0004

2015-10-08 10:37:32 [28165] [12] DEBUG:   command_status: 0 = 0x

2015-10-08 10:37:32 [28165] [12] DEBUG:   sequence_number: 2309 = 0x0905

2015-10-08 10:37:32 [28165] [12] DEBUG:   service_type: NULL

2015-10-08 10:37:32 [28165] [12] DEBUG:   source_addr_ton: 1 = 0x0001

2015-10-08 10:37:32 [28165] [12] DEBUG:   source_addr_npi: 1 = 0x0001

2015-10-08 10:37:32 [28165] [12] DEBUG:   source_addr: "27821278120"

2015-10-08 10:37:32 [28165] [12] DEBUG:   dest_addr_ton: 1 = 0x0001

2015-10-08 10:37:32 [28165] [12] DEBUG:   dest_addr_npi: 1 = 0x0001

2015-10-08 10:37:32 [28165] [12] DEBUG:   destination_addr: "27831234567"

2015-10-08 10:37:32 [28165] [12] DEBUG:   esm_class: 3 = 0x0003

2015-10-08 10:37:32 [28165] [12] DEBUG:   protocol_id: 0 = 0x

2015-10-08 10:37:32 [28165] [12] DEBUG:   priority_flag: 0 = 0x

2015-10-08 10:37:32 [28165] [12] DEBUG:   schedule_delivery_time: NULL

2015-10-08 10:37:32 [28165] [12] DEBUG:   validity_period:
"151011103732000+"

2015-10-08 10:37:32 [28165] [12] DEBUG:   registered_delivery: 0 =
0x

2015-10-08 10:37:32 [28165] [12] DEBUG:   replace_if_present_flag: 0 =
0x

2015-10-08 10:37:32 [28165] [12] DEBUG:   data_coding: 0 = 0x

2015-10-08 10:37:32 [28165] [12] DEBUG:   sm_default_msg_id: 0 = 0x

2015-10-08 10:37:32 [28165] [12] DEBUG:   sm_length: 1 = 0x0001

2015-10-08 10:37:32 [28165] [12] DEBUG:   short_message: "}"

 

But, on the cell phone it comes out as Small letter n with tilde.  Which is
7D for the GSM 7-bit default alphabet

This means Kannel is converting the 7D to }  

But Vodacom is not converting the 7D to } , as its expects the data_coding
to be 3 and to receive ESC + ) i.e. Data values:0x1B 0x29  so the cell phone
gets the wrong character.

 

If we try another approach and send %1B%29 which is the Right curly bracket
in GSM 7-bit default alphabet 

we get ?) on the cell phone.

>From bearerbox:   short_message: "?)"

 

Is there any way to send this via Kannel with its current internal encoding?

 

Kind Regards

 

Hillel Bilman

Manager eCommunicate

mailto:   hbil...@ecommunicate.co.za

Cell: 083-232

Landline: 011-443-6164

Fax: 088-011-443-6164

 

Mobile Wallets  - .mobi Sites - Mobile Apps(Android, iPhone, Blackberry,
Nokia) -  Premium Rated SMSs and short codes - SMS competitions and
campaigns - Lead Generation - opt-in subscription Billing - MMS campaigns -
USSD campaigns - WAP - Outlook SMS - Bulk SMS and Bulk Email - Email 2 SMS 2
Email - Developer Kit for Mobile Services integration 

 

RE: patch to allow data_coding to be set to 3

[Werner Coetzee]

Hi

Your pdu dump is incorrect, if it was converted to GSM to message data should 
be 1b 29.
Check your bind configuration, you might have alt-charset set to "Latin1" or 
something similar (eg ASCII, or ISO-8859-1).
The reason why Vodacom is asking you to use data-coding 3 is because you are 
submitting your data in Latin1.

We send a lot of messages to Vodacom daily, and don't have this issue.
I just tested a message "{test}" and it was correctly delivered to the phone.  
Here is my pdu dump (msisdns are hidden)

SMPP PDU 0x2aaad0244160 dump:
  type_name: submit_sm
  command_id: 4 = 0x0004
  command_status: 0 = 0x
  sequence_number: 27063026 = 0x019cf2f2
  service_type: NULL
  source_addr_ton: 1 = 0x0001
  source_addr_npi: 1 = 0x0001
  source_addr: "2782xxx"
  dest_addr_ton: 1 = 0x0001
  dest_addr_npi: 1 = 0x0001
  destination_addr: "2782xxx"
  esm_class: 0 = 0x
  protocol_id: 0 = 0x
  priority_flag: 1 = 0x0001
  schedule_delivery_time: NULL
  validity_period: NULL
  registered_delivery: 1 = 0x0001
  replace_if_present_flag: 0 = 0x
  data_coding: 0 = 0x
  sm_default_msg_id: 0 = 0x
  sm_length: 8 = 0x0008
  short_message:
   Octet string at 0x2aaad003f6a0:
 len:  8
 size: 1024
 immutable: 0
 data: 1b 28 74 65 73 74 1b 29   .(test.)
   Octet string dump ends.
SMPP PDU dump ends.

So I agree with Andreas and Alex, you shouldn't need to change anything.
Could you perhaps supply your bind configuration?

Regards
Werner Coetzee





Werner Coetzee - Senior C Developer / Message Engine Tech Lead

E: werner.coet...@clickatell.com
T: (+27) 21 910 7700
[cid:image9994bb.PNG@f34fb7fb.4f9f254d]
Note: This disclaimer 
applies to this email and its attachments

[Twitter]   [LinkedIn] 
[Facebook] 




[cid:image7a502a.GIF@37a7e458.40beffa7]
From: devel [mailto:devel-boun...@kannel.org] On Behalf Of 
hbil...@ecommunicate.biz
Sent: 08 October 2015 14:06
To: amal...@kannel.org; af...@list.fink.org
Cc: devel@kannel.org
Subject: Re: patch to allow data_coding to be set to 3
Importance: High


Hi Alex and Andreas,



Vodacom says send Latin-1 characters and set your data_coding field to 3 to 
tell the SMSC to translate the characters from Latin-1 to GSM. So that if we 
want to display the curly bracket ‘}’ you have to send the escape character and 
the round bracket character: ESC + )  Data values:0x1B 0x29 and on the phone 
you will see curly bracket ‘}’



How do you send this via Kannel if we can’t touch  the data_coding field?

If we can't send this correctly via Kannel to Vodacom SIM cards, will you allow 
Kannel users to set the data_coding field?. (This means also allowing the 
Kannel user to bypass the internal Kannel conversion so you can send 0x1B 0x29 
and the external SMSC will convert it to the curly bracket ‘} )



Below is our attempt to send the curly bracket ‘}’ if we can get this to work 
we should be able to send all the other characters that are like this.

If you see http://www.developershome.com/sms/gsmAlphabet.asp

Right curly bracket is Hex 1B29 for GSM 7-bit default alphabet and 7D for ISO 
8859 Latin 1



lynx -dump 
"http://41.185.24.138:13013/cgi-bin/sendsms?username=x=y=27831234567=%7D=27821278120=vodacom
 

 "



In Smsbox it comes out as Right curly bracket:

2015-10-08 10:37:32 [28232] [3] INFO: sendsms sender: 
to:<27831234567> msg:<}>



In Bearerbox it comes out as Right curly bracket:

2015-10-08 10:37:32 [28165] [12] DEBUG: SMPP[vodacom]: Sending PDU:

2015-10-08 10:37:32 [28165] [12] DEBUG: SMPP PDU 0x7f10a4007020 dump:

2015-10-08 10:37:32 [28165] [12] DEBUG:   type_name: submit_sm

2015-10-08 10:37:32 [28165] [12] DEBUG:   command_id: 4 = 0x0004

2015-10-08 10:37:32 [28165] [12] DEBUG:   command_status: 0 = 0x

2015-10-08 10:37:32 [28165] [12] DEBUG:   sequence_number: 2309 = 0x0905

2015-10-08 10:37:32 [28165] [12] DEBUG:   service_type: NULL

2015-10-08 10:37:32 [28165] [12] DEBUG:   source_addr_ton: 1 = 0x0001

2015-10-08 10:37:32 [28165] [12] DEBUG:   source_addr_npi: 1 = 0x0001

2015-10-08 10:37:32 [28165] [12] DEBUG:   source_addr: "27821278120"

2015-10-08 10:37:32 [28165] [12] DEBUG:   dest_addr_ton: 1 = 0x0001

2015-10-08 10:37:32 [28165] [12] DEBUG:   dest_addr_npi: 1 = 0x0001

2015-10-08 10:37:32 [28165] [12] DEBUG:   destination_addr: "27831234567"

2015-10-08 10:37:32 [28165] [12] DEBUG:   

Re: patch to allow data_coding to be set to 3

[Kirti Mandwade]

Hi Andreas,

Thanks for the quick response.

Even if i use utf8 charset then also all special characters allowed by GSM
7 are not getting sent properly.
I am url encoding everything before sending as per kannel document.
Can you suggest me how to send all GSM7 allowed special characters properly.

Regards



On Wed, Oct 7, 2015 at 6:54 PM, Andreas Fink  wrote:

> theres no need for having the SMSC do the latin1 to GSM transcoding as
> kannel already does this.
> you feed kannel with latin1 or utf8 and kannel will make GSM out of it
> automatically.
>
> What matters at the end is what the handset receives and the GSM character
> set is hardcoded in billions of phones. You can not send latin1 to phones
> but you can send the GSM character set to phones which has a few more chars
> than IA5 by now (by the use of some escape sequence they added things like
> | { } if I remember correctly). And in GSM things are slightly differnet as
> @ for example is encoded as 0x00.
>
> Kannel does the conversion from whatever you feed it with to the GSM
> character set. There is no need to set coding value for this. This is only
> needed if you want to send raw bytes to kannel (and thus disable the
> internal conversion) for example when you send binary data.
>
> So the key is to have your character set properly set in your http request
> header. Kannel defaults to UTF8. So when you feed latin1 characters to
> kannel, they should be translated already correctly to GSM and have the DCS
> values set correctly.
>
> Its nice that Vodacom's SMSC has a *_proprietary_* extension to do the
>  conversion in the SMSC but Kannel doesn't need it to operate correctly.
>
> On 07 Oct 2015, at 15:12, hbil...@ecommunicate.biz wrote:
>
> Hi Alex,
>
> From this thread that you responded to see
> http://www.kannel.org/pipermail/users/2012-April/017611.html and the
> current
> user guide, it seems Kannel has never allowed data_coding to be set to 3.
> See  the coding parameter in the current spec
>
> http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN5
> 058
> Coding Accepts values 0 to 2, for 7bit, 8bit or UCS-2.
> 0 causes data_coding 0 (for 7bit), 1 causes data_coding 4 (for 8bit) and 2
> causes data_coding 8 (for UCS-2).
>
> Vodacom SA which has the largest mobile network in SA, has said to send the
> Extended GSM characters, we need to use Latin-1 characters and set our
> data_coding field to 3 to tell the SMSC to translate the characters from
> Latin-1 to GSM. (Note that standard ASCII and IA5 is a sub set of Latin-1.)
> However, need to be able to send the extended GSM characters using 7 bits
> without using Unicode as otherwise each SMS would then only be 70
> characters
> and our clients would require many more SMSs to send the same message.
>
> Do you have a patch, that will allow Kannel users to set the coding
> parameter to 3?
> If not, would you be open to someone committing a patch for this?
>
> Thanks for all the amazing work you do for Kannel.
>
> Kind Regards
>
> Hillel Bilman
> Manager eCommunicate
> mailto: hbil...@ecommunicate.co.za
> Cell: 083-232
> Landline: 011-443-6164
> Fax: 088-011-443-6164
>
> Mobile Wallets  - .mobi Sites – Mobile Apps(Android, iPhone, Blackberry,
> Nokia) -  Premium Rated SMSs and short codes - SMS competitions and
> campaigns – Lead Generation - opt-in subscription Billing – MMS campaigns -
> USSD campaigns - WAP - Outlook SMS – Bulk SMS and Bulk Email – Email 2 SMS
> 2
> Email - Developer Kit for Mobile Services integration - Voice Over IP
> services
>
>
>
>
>

Re: patch to allow data_coding to be set to 3

[Andreas Fink]

theres no need for having the SMSC do the latin1 to GSM transcoding as kannel 
already does this.
you feed kannel with latin1 or utf8 and kannel will make GSM out of it 
automatically.

What matters at the end is what the handset receives and the GSM character set 
is hardcoded in billions of phones. You can not send latin1 to phones but you 
can send the GSM character set to phones which has a few more chars than IA5 by 
now (by the use of some escape sequence they added things like | { } if I 
remember correctly). And in GSM things are slightly differnet as @ for example 
is encoded as 0x00.

Kannel does the conversion from whatever you feed it with to the GSM character 
set. There is no need to set coding value for this. This is only needed if you 
want to send raw bytes to kannel (and thus disable the internal conversion) for 
example when you send binary data.

So the key is to have your character set properly set in your http request 
header. Kannel defaults to UTF8. So when you feed latin1 characters to kannel, 
they should be translated already correctly to GSM and have the DCS values set 
correctly.

Its nice that Vodacom's SMSC has a _proprietary_ extension to do the  
conversion in the SMSC but Kannel doesn't need it to operate correctly.

> On 07 Oct 2015, at 15:12, hbil...@ecommunicate.biz wrote:
> 
> Hi Alex,
> 
> From this thread that you responded to see
> http://www.kannel.org/pipermail/users/2012-April/017611.html and the current
> user guide, it seems Kannel has never allowed data_coding to be set to 3.
> See  the coding parameter in the current spec
> http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN5
> 058
> Coding Accepts values 0 to 2, for 7bit, 8bit or UCS-2.
> 0 causes data_coding 0 (for 7bit), 1 causes data_coding 4 (for 8bit) and 2
> causes data_coding 8 (for UCS-2).
> 
> Vodacom SA which has the largest mobile network in SA, has said to send the
> Extended GSM characters, we need to use Latin-1 characters and set our
> data_coding field to 3 to tell the SMSC to translate the characters from
> Latin-1 to GSM. (Note that standard ASCII and IA5 is a sub set of Latin-1.)
> However, need to be able to send the extended GSM characters using 7 bits
> without using Unicode as otherwise each SMS would then only be 70 characters
> and our clients would require many more SMSs to send the same message.
> 
> Do you have a patch, that will allow Kannel users to set the coding
> parameter to 3?
> If not, would you be open to someone committing a patch for this?
> 
> Thanks for all the amazing work you do for Kannel.
> 
> Kind Regards
> 
> Hillel Bilman
> Manager eCommunicate
> mailto: hbil...@ecommunicate.co.za
> Cell: 083-232
> Landline: 011-443-6164
> Fax: 088-011-443-6164
> 
> Mobile Wallets  - .mobi Sites – Mobile Apps(Android, iPhone, Blackberry,
> Nokia) -  Premium Rated SMSs and short codes - SMS competitions and
> campaigns – Lead Generation - opt-in subscription Billing – MMS campaigns -
> USSD campaigns - WAP - Outlook SMS – Bulk SMS and Bulk Email – Email 2 SMS 2
> Email - Developer Kit for Mobile Services integration - Voice Over IP
> services
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: patch to allow data_coding to be set to 3

[Alexander Malysh]

Hi Hillel,

I have to agree to Andreas. You don’t need any special data coding because 
Kannel will do the whole
convert magic to GSM for you.

Alex

> Am 07.10.2015 um 15:24 schrieb Andreas Fink :
> 
> theres no need for having the SMSC do the latin1 to GSM transcoding as kannel 
> already does this.
> you feed kannel with latin1 or utf8 and kannel will make GSM out of it 
> automatically.
> 
> What matters at the end is what the handset receives and the GSM character 
> set is hardcoded in billions of phones. You can not send latin1 to phones but 
> you can send the GSM character set to phones which has a few more chars than 
> IA5 by now (by the use of some escape sequence they added things like | { } 
> if I remember correctly). And in GSM things are slightly differnet as @ for 
> example is encoded as 0x00.
> 
> Kannel does the conversion from whatever you feed it with to the GSM 
> character set. There is no need to set coding value for this. This is only 
> needed if you want to send raw bytes to kannel (and thus disable the internal 
> conversion) for example when you send binary data.
> 
> So the key is to have your character set properly set in your http request 
> header. Kannel defaults to UTF8. So when you feed latin1 characters to 
> kannel, they should be translated already correctly to GSM and have the DCS 
> values set correctly.
> 
> Its nice that Vodacom's SMSC has a _proprietary_ extension to do the  
> conversion in the SMSC but Kannel doesn't need it to operate correctly.
> 
>> On 07 Oct 2015, at 15:12, hbil...@ecommunicate.biz 
>>  wrote:
>> 
>> Hi Alex,
>> 
>> From this thread that you responded to see
>> http://www.kannel.org/pipermail/users/2012-April/017611.html 
>>  and the 
>> current
>> user guide, it seems Kannel has never allowed data_coding to be set to 3.
>> See  the coding parameter in the current spec
>> http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN5 
>> 
>> 058
>> Coding Accepts values 0 to 2, for 7bit, 8bit or UCS-2.
>> 0 causes data_coding 0 (for 7bit), 1 causes data_coding 4 (for 8bit) and 2
>> causes data_coding 8 (for UCS-2).
>> 
>> Vodacom SA which has the largest mobile network in SA, has said to send the
>> Extended GSM characters, we need to use Latin-1 characters and set our
>> data_coding field to 3 to tell the SMSC to translate the characters from
>> Latin-1 to GSM. (Note that standard ASCII and IA5 is a sub set of Latin-1.)
>> However, need to be able to send the extended GSM characters using 7 bits
>> without using Unicode as otherwise each SMS would then only be 70 characters
>> and our clients would require many more SMSs to send the same message.
>> 
>> Do you have a patch, that will allow Kannel users to set the coding
>> parameter to 3?
>> If not, would you be open to someone committing a patch for this?
>> 
>> Thanks for all the amazing work you do for Kannel.
>> 
>> Kind Regards
>> 
>> Hillel Bilman
>> Manager eCommunicate
>> mailto: hbil...@ecommunicate.co.za
>> Cell: 083-232
>> Landline: 011-443-6164
>> Fax: 088-011-443-6164
>> 
>> Mobile Wallets  - .mobi Sites – Mobile Apps(Android, iPhone, Blackberry,
>> Nokia) -  Premium Rated SMSs and short codes - SMS competitions and
>> campaigns – Lead Generation - opt-in subscription Billing – MMS campaigns -
>> USSD campaigns - WAP - Outlook SMS – Bulk SMS and Bulk Email – Email 2 SMS 2
>> Email - Developer Kit for Mobile Services integration - Voice Over IP
>> services
>> 
>> 
>> 
>