Well I would have thought that the converting from UTF-8 to GSM 03.38 would reflect as a different message size.
When its sent as UTF 2007-06-01 21:22:25 [20312] [8] DEBUG: len: 151 2007-06-01 21:22:25 [20312] [8] DEBUG: size: 152 When its sent as GSM 03.38 >> 2007-06-01 21:30:13 [20312] [26] DEBUG: len: 122 >> 2007-06-01 21:30:13 [20312] [26] DEBUG: size: 152 It just seemed a little odd. -----Original Message----- From: Alexander Malysh [mailto:[EMAIL PROTECTED] Sent: Monday, June 04, 2007 1:25 PM To: [email protected] Subject: RE: [PATCH] Re: Bug: extract_msgdata_part_by_coding / message split Ehizogie Binitie wrote: > Thanks, that fixed the problem. Would you know why the PDU size still > reads as though it were UTF-8..? > why not? it depends on chars you send. > Ehi > > > -----Original Message----- > From: Alexander Malysh [mailto:[EMAIL PROTECTED] > Sent: Monday, June 04, 2007 12:42 PM > To: [email protected] > Subject: RE: [PATCH] Re: Bug: extract_msgdata_part_by_coding / message > split > > 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 ;<=..>[EMAIL PROTECTED] >> 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 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.7/830 - Release Date: 6/3/2007 12:47 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
