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

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   ;<=..>?@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


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