RE: SMPP: data_coding (deliver_sm)

Alan McNatty <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <1035937852.6415.592.camel@euclid>
Alternatively we could reuse the alt-dcs used in submit_sm.

On Wed, 2002-10-30 at 12:58, Alan McNatty wrote:
> 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.
> 
> 
-- 
Alan McNatty -- Catalyst IT Ltd -- http://www.catalyst.net.nz
  Level 2, 150-154 Willis St, PO Box 11-053, Wellington, NZ
Mob: +64 21-312136, DDI: +64 4 9167203, Office: +64 4 4992267

... error accessing whit
Segmentation fault (core dumped)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.