RE: [PATCH] Re: Bug: extract_msgdata_part_by_coding / message split
Alexander Malysh <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi,
do u define alt_charset = GSM for the first SMSC? It seems yes. Please don't
define this and this should work as expected.
Ehizogie Binitie wrote:
> 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
--
Thanks,
Alex