This shouldn't work (nor should it have worked in 1.1.4 - if it did then that was a 
bug) as in addition to hard setting (in a non comaptible way) the coding type for a 
PDU, you must make sure your message is formatted according to the chosen character 
set - which currently it isn't as messages delivered are formatted either for 8 bit, 7 
bit or unicode.

As an ugly hack, you can hardcode the data_coding pdu parameter, then send messages to 
the smsbox, using send-sms,  in the target character set but don't set the charset 
parameter, and set coding to 2. this way Kannel will not transcode the message and it 
will be delivered as is to the driver.

--
Oded Arbel
m-Wise Mobile Solutions

[EMAIL PROTECTED]
Mobile: +972-67-340014
Tel: +972-9-9581711 (ext: 116)

::..
How much wood could a woodchuck chuck if a woodchuck could chuck wood?


> -----Original Message-----
> From: Arne K. Haaje [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 18, 2002 3:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: sms.coding choice in smsbox (SMPP smsc)
> 
> 
> On Tuesday 18 June 2002 14:40, Oded Arbel wrote:
> > SMPP v3.4 support many character set delivery types but 
> SMPP v3.3 doesn't,
> > and the way the SMPP driver in kannel is written, it 
> supports only the v3.3
> > style of character coding which limits us to GSM 03.38 
> (7bit), iso-8859-1
> > (8bit) or UCS-2 (unicode). Changing the SMPP implementation 
> to support the
> > v3.4 supported charsets is on my todo list, but it wouldn't 
> help any as
> > Kannel does not currently have an infrastructure to support arbitary
> > chracter sets (or just anything besides the 3 coding styles).
> >
> > Currently to send anything other the ISO-8859-1 on SMPP you 
> need to either
> > deliver everything in unicode (UCS-2) or to hack the driver 
> to support your
> > specific charset.
> 
> In 1.1.4 you could put 
> 
> pdu->u.submit_sm.data_coding = 0xf5;
> 
> in smsc_smpp.c
> 
> I am no C guru, but I tried putting this in the version from 
> the latest 
> snapshot (which has changed a bit..). It does'nt seem to 
> work, as I get no 
> messages through.
> 
> Any ideas on where I should hardcode the driver to use 0xf5 
> as the coding?
> 
> Regards,
> 
> Arne
> -- 
> --------------------------------
> Arne K. Haaje | T: 69 92 04 90
> Bregneveien 9 | F: 69 92 04 91
> 1625 Tomter   | M: 92 88 44 66
> --------------------------------
> 
> 
> 

Reply via email to