Re: patch to allow data_coding to be set to 3

Andreas Fink <[email protected]> Wed, 7 Oct 2015 15:24:35 +0200
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
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, [email protected] 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: [email protected]
> Cell: 083-2300002
> 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 (application/pgp-signature, 841 B)
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWFR0UAAoJEOtfx+3l1p1nD04P/02eMrWjOrLfltE/svhtBd47
Da2Hy1L//phhdUgUcfYDMPo7uJhmHmW4wXrG42awNHSiz9Bf+rZJw4i/kUDbzcQk
4TAkYFWSMVr4FhFiszmjemPYfaiuX6IouW+B01wKl2hZq6WzpzR6WQMKQ3hLp0r9
xpogI5cVIVGn0b6moqNtkhfrELcNXCZCrJjjKDditaPeJ1T31IshKia1t8iFEyQB
ODgoE42udL4gyKW63xerZ2i4WyUtkKJQcpFWiuojgECvqaUsJYpZFOAMjJEG7cow
jA7w9yJDMc0sId1t5ViR9x7niWuNSYnv9eJeFcsd/k6bWHi7WYBqCEOkSmregln9
QoMjo5XItxFwbm1lPga3vUIJWm6672YOFT80s0yaW0rA/pNCqCqr3tc2TV8GbYi4
YTAX0uQyFwQ4QmUa9+Nbl+fOFcUMXMAHSzFk9NxLtaVgPP2LS0VsqsaIINswDh7e
B++0sgE3Dol+DH/4cgIa1D4kHeHfzqEeizhCu82YwtNgJgWMgZsVY1OM8Kh0HZqu
BCUFFZ+Kv55HpJk94mKBaaVCQN6FmK4luRgY+oxuJY+okqonYCDnDQC84J0MfiFx
0VVf7J8mwWOgtcpfodZzLL77jlk92DknYuU7P0/KcItDVVzwfThjDRUlYEq5Id7c
tkryB/8sbjsx/Ps68U7R
=26dD
-----END PGP SIGNATURE-----