RE: [PATCH] Re: Bug: extract_msgdata_part_by_coding / message split

"Ehizogie Binitie" <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <!&!AAAAAAAAAAAYAAAAAAAAAGLSml3yFLRPtvqzsoSDE4fCgAAAEAAAAJPQub7v9DNGh/[email protected]>
I pulled the latest version of Kannel from CVS and I'm getting this error
when sending to particular SMSC's.

"Failed to convert string from <UTF-8> to <GSM> - probably broken type
names."


Take a look at the PDU trace below. 
========================================================================

2007-06-01 21:22:25 [20312] [47] DEBUG: send_msg: sending msg to boxc:
<KANNSMSC>
2007-06-01 21:22:25 [20312] [8] ERROR: Failed to convert string from <UTF-8>
to <GSM> - probably broken type names.
2007-06-01 21:22:25 [20312] [8] ERROR: Failed to convert msgdata from
charset <UTF-8> to <GSM>, will send as is.
2007-06-01 21:22:25 [20312] [8] DEBUG: SMPP[mySMSC]: Sending PDU:
2007-06-01 21:22:25 [20312] [8] DEBUG: SMPP PDU 0x99600470 dump:
2007-06-01 21:22:25 [20312] [8] DEBUG:   type_name: submit_sm
2007-06-01 21:22:25 [20312] [8] DEBUG:   command_id: 4 = 0x00000004
2007-06-01 21:22:25 [20312] [8] DEBUG:   command_status: 0 = 0x00000000
2007-06-01 21:22:25 [20312] [8] DEBUG:   sequence_number: 6527 = 0x0000197f
2007-06-01 21:22:25 [20312] [8] DEBUG:   service_type: NULL
2007-06-01 21:22:25 [20312] [8] DEBUG:   source_addr_ton: 2 = 0x00000002
2007-06-01 21:22:25 [20312] [8] DEBUG:   source_addr_npi: 1 = 0x00000001
2007-06-01 21:22:25 [20312] [8] DEBUG:   source_addr: "0"
2007-06-01 21:22:25 [20312] [8] DEBUG:   dest_addr_ton: 2 = 0x00000002
2007-06-01 21:22:25 [20312] [8] DEBUG:   dest_addr_npi: 1 = 0x00000001
2007-06-01 21:22:25 [20312] [8] DEBUG:   destination_addr: "xxxxxxxxxxxx"
2007-06-01 21:22:25 [20312] [8] DEBUG:   esm_class: 3 = 0x00000003
2007-06-01 21:22:25 [20312] [8] DEBUG:   protocol_id: 0 = 0x00000000
2007-06-01 21:22:25 [20312] [8] DEBUG:   priority_flag: 0 = 0x00000000
2007-06-01 21:22:25 [20312] [8] DEBUG:   schedule_delivery_time: NULL
2007-06-01 21:22:25 [20312] [8] DEBUG:   validity_period: NULL
2007-06-01 21:22:25 [20312] [8] DEBUG:   registered_delivery: 0 = 0x00000000
2007-06-01 21:22:25 [20312] [8] DEBUG:   replace_if_present_flag: 0 =
0x00000000
2007-06-01 21:22:25 [20312] [8] DEBUG:   data_coding: 0 = 0x00000000
2007-06-01 21:22:25 [20312] [8] DEBUG:   sm_default_msg_id: 0 = 0x00000000
2007-06-01 21:22:25 [20312] [8] DEBUG:   sm_length: 151 = 0x00000097
2007-06-01 21:22:25 [20312] [8] DEBUG:   short_message:
2007-06-01 21:22:25 [20312] [8] DEBUG:    Octet string at 0x996014f8:
2007-06-01 21:22:25 [20312] [8] DEBUG:      len:  151
2007-06-01 21:22:25 [20312] [8] DEBUG:      size: 152
2007-06-01 21:22:25 [20312] [8] DEBUG:      immutable: 0
2007-06-01 21:22:25 [20312] [8] DEBUG:      data: 40 c2 a3 24 c2 a5 c3 a8 c3
a9 c3 b9 c3 ac c3 b2   @..$............
2007-06-01 21:22:25 [20312] [8] DEBUG:      data: c3 87 c3 98 c3 b8 c3 85 c3
a5 5f c3 86 0d 0a c3   .........._.....
2007-06-01 21:22:25 [20312] [8] DEBUG:      data: a6 c3 9f c3 89 21 23 c2 a4
25 26 27 28 29 2a 2b   .....!#..%&'()*+
2007-06-01 21:22:25 [20312] [8] DEBUG:      data: 2c 2d 2e 2f 0d 0a 30 31 32
33 34 35 36 37 38 39   ,-./..0123456789
2007-06-01 21:22:25 [20312] [8] DEBUG:      data: 3a 3b 3c 3d 0d 0a 3e 3f c2
a1 41 42 43 44 45 46   :;<=..>?..ABCDEF
2007-06-01 21:22:25 [20312] [8] DEBUG:      data: 47 48 49 4a 4b 4c 4d 0d 0a
4e 4f 50 51 52 53 54   GHIJKLM..NOPQRST
2007-06-01 21:22:25 [20312] [8] DEBUG:      data: 55 56 57 58 59 5a c3 84 c3
96 c3 91 0d 0a c3 9c   UVWXYZ..........
2007-06-01 21:22:25 [20312] [8] DEBUG:      data: c2 a7 c2 bf 61 62 63 64 65
66 67 68 69 6a 6c 6d   ....abcdefghijlm
2007-06-01 21:22:25 [20312] [8] DEBUG:      data: 6e 6f 70 71 72 73 74 75 76
77 78 79 7a c3 a4 c3   nopqrstuvwxyz...
2007-06-01 21:22:25 [20312] [8] DEBUG:      data: b6 c3 b1 c3 bc c3 a0
.......
2007-06-01 21:22:25 [20312] [8] DEBUG:    Octet string dump ends.
2007-06-01 21:22:25 [20312] [8] DEBUG: SMPP PDU dump ends.

===========================================================================
 
Interestingly enough this does not happen with all SMSC's.See below a PDU
trace to a second SMSC

===========================================================================
2007-06-01 21:30:13 [20312] [47] DEBUG: boxc_receiver: sms received
2007-06-01 21:30:13 [20312] [47] DEBUG: send_msg: sending msg to boxc:
<KANNELSMSC>
2007-06-01 21:30:13 [20312] [26] DEBUG: SMPP[mySMSC2]: Sending PDU:
2007-06-01 21:30:13 [20312] [26] DEBUG: SMPP PDU 0x99401088 dump:
2007-06-01 21:30:13 [20312] [26] DEBUG:   type_name: submit_sm
2007-06-01 21:30:13 [20312] [26] DEBUG:   command_id: 4 = 0x00000004
2007-06-01 21:30:13 [20312] [26] DEBUG:   command_status: 0 = 0x00000000
2007-06-01 21:30:13 [20312] [26] DEBUG:   sequence_number: 3277 = 0x00000ccd
2007-06-01 21:30:13 [20312] [26] DEBUG:   service_type: NULL
2007-06-01 21:30:13 [20312] [26] DEBUG:   source_addr_ton: 2 = 0x00000002
2007-06-01 21:30:13 [20312] [26] DEBUG:   source_addr_npi: 1 = 0x00000001
2007-06-01 21:30:13 [20312] [26] DEBUG:   source_addr: "0"
2007-06-01 21:30:13 [20312] [26] DEBUG:   dest_addr_ton: 1 = 0x00000001
2007-06-01 21:30:13 [20312] [26] DEBUG:   dest_addr_npi: 1 = 0x00000001
2007-06-01 21:30:13 [20312] [26] DEBUG:   destination_addr: "2348038388315"
2007-06-01 21:30:13 [20312] [26] DEBUG:   esm_class: 3 = 0x00000003
2007-06-01 21:30:13 [20312] [26] DEBUG:   protocol_id: 0 = 0x00000000
2007-06-01 21:30:13 [20312] [26] DEBUG:   priority_flag: 0 = 0x00000000
2007-06-01 21:30:13 [20312] [26] DEBUG:   schedule_delivery_time: NULL
2007-06-01 21:30:13 [20312] [26] DEBUG:   validity_period: NULL
2007-06-01 21:30:13 [20312] [26] DEBUG:   registered_delivery: 0 =
0x00000000
2007-06-01 21:30:13 [20312] [26] DEBUG:   replace_if_present_flag: 0 =
0x00000000
2007-06-01 21:30:13 [20312] [26] DEBUG:   data_coding: 0 = 0x00000000
2007-06-01 21:30:13 [20312] [26] DEBUG:   sm_default_msg_id: 0 = 0x00000000
2007-06-01 21:30:13 [20312] [26] DEBUG:   sm_length: 122 = 0x0000007a
2007-06-01 21:30:13 [20312] [26] DEBUG:   short_message:
2007-06-01 21:30:13 [20312] [26] DEBUG:    Octet string at 0x994011b8:
2007-06-01 21:30:13 [20312] [26] DEBUG:      len:  122
2007-06-01 21:30:13 [20312] [26] DEBUG:      size: 152
2007-06-01 21:30:13 [20312] [26] DEBUG:      immutable: 0
2007-06-01 21:30:13 [20312] [26] DEBUG:      data: 00 01 02 03 04 05 06 07
08 09 0b 0c 0e 0f 11 1c   ................
2007-06-01 21:30:13 [20312] [26] DEBUG:      data: 0d 0a 1d 1e 1f 21 23 24
25 26 27 28 29 2a 2b 2c   .....!#$%&'()*+,
2007-06-01 21:30:13 [20312] [26] DEBUG:      data: 2d 2e 2f 0d 0a 30 31 32
33 34 35 36 37 38 39 3a   -./..0123456789:
2007-06-01 21:30:13 [20312] [26] DEBUG:      data: 3b 3c 3d 0d 0a 3e 3f 40
41 42 43 44 45 46 47 48   ;<=..>?@ABCDEFGH
2007-06-01 21:30:13 [20312] [26] DEBUG:      data: 49 4a 4b 4c 4d 0d 0a 4e
4f 50 51 52 53 54 55 56   IJKLM..NOPQRSTUV
2007-06-01 21:30:13 [20312] [26] DEBUG:      data: 57 58 59 5a 5b 5c 5d 0d
0a 5e 5f 60 61 62 63 64   WXYZ[\]..^_`abcd
2007-06-01 21:30:13 [20312] [26] DEBUG:      data: 65 66 67 68 69 6a 6c 6d
6e 6f 70 71 72 73 74 75   efghijlmnopqrstu
2007-06-01 21:30:13 [20312] [26] DEBUG:      data: 76 77 78 79 7a 7b 7c 7d
7e 7f                     vwxyz{|}~.
2007-06-01 21:30:13 [20312] [26] DEBUG:    Octet string dump ends.
2007-06-01 21:30:13 [20312] [26] DEBUG: SMPP PDU dump ends.

===========================================================================

I notice that even after a successful conversion to GSM 03.38 in this case,
the size of the message still stays the same as if it were UTF-8

Does anyone have any ideas why this could be happening?



Ehi

-----Original Message-----
From: Stipe Tolj [mailto:[email protected]] 
Sent: Friday, June 01, 2007 11:13 AM
Cc: [email protected]
Subject: Re: [PATCH] Re: Bug: extract_msgdata_part_by_coding / message split

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Malysh wrote:

> Hi,
> 
> why it should be necessary now? we have utf-8 internally and you can send
> any gsm-03.38 chars via smsbox.

yep, +1, confirmed... my ChangeLog at that time:

2006-09-29  Stipe Tolj  <stolj at kannel.org>
    * gw/smsc/smsc_fake.c: add TODO comment to add a SMPP DLR payload text
      for a DLR returned back via fake module.
    * gw/smsc/smsc_smpp.c: obey charset more closely in msg_to_pdu(), where
      we don't call charset_latin1_to_gsm() if charset flag of msg struct
      carries the "GSM-03.38" indication. This is not yet used by smsbox,
but
      may be used by external modules before we have a clean transition to
      UTF-8 as internal charset and target charset indication via msg
struct's
      charset value. Also ensures now that we write a "FAILED DLR SMS"
      access-log entry if we receive a DLR, but can't find it via
handle_dlr().

which makes clear that we don't need it anymore... need to remove it.

Stipe

- -------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany

tolj.org system architecture      Kannel Software Foundation (KSF)
http://www.tolj.org/              http://www.kannel.org/

mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
- -------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGX/9H9ez0oeKvYs0RAssIAKC0H+kOwyIKb9J37NWoXwJ/UTWxjACfeexY
CU19w+VO0E40ZBI6rNM1sr8=
=J9WL
-----END PGP SIGNATURE-----

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.5/826 - Release Date: 5/31/2007
4:51 PM
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.7/830 - Release Date: 6/3/2007
12:47 PM
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.