As you suggested Oded I simply need not perform the gsm_to_latin1 translation (but also remove trailing null character).
To impliment this sensibly I was hoping the data_coding would be set to something other than 0x00 - SMSC default alphabet. Unfortunately this is not the case which would suggest I need another configurable parameter to state what the SMSC default data_coding is ... ie: extra smsc config directive would look something like default_aphabet = 0x03. Corresponding translation can be implimented in smsc_smpp.c, pdu_to_msg - although parsing the smpp structure would also be required. I also noted a tread started about whether or not payload translation should be done at bearerbox level - is there any work being done on this? Cheers, Alan Index: gw/smsc/smsc_smpp.c =================================================================== RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v retrieving revision 1.14 diff -r1.14 smsc_smpp.c 239c239,244 < charset_gsm_to_latin1(msg->sms.msgdata); --- > > if ( pdu->u.deliver_sm.data_coding == 0x00 ) > octstr_truncate(msg->sms.msgdata, octstr_len(msg->sms.msgdata) - 1); > else > charset_gsm_to_latin1(msg->sms.msgdata); > On Wed, 2002-10-23 at 08:42, Alan McNatty wrote: > > Yep - the logic as you described it seems to be how Kannel > handles things. I have not had a chance to recieve unicode data through an SMPP SMSC, but that would seem to be problematic. we don't need to transcode from UCS2, as Kannel should send unicode text as UCS2 to the application (as all other drivers do), we simply should not use gsm_to_latin1 on UCS2 encoded message as that can mangle some characters.
