Re: Re: SMPP Patch for data_coding: 3

Michael Zervakis <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
Actually we noticed that certain mobile phones use data_coding 3 when sending MO SM with greek characters (not UCS-2) instead of 0
as you can see in the following example:
2008-09-30 13:19:31 [19193] [13] DEBUG: SMPP PDU 0x8268558 dump:
2008-09-30 13:19:31 [19193] [13] DEBUG:   type_name: deliver_sm
2008-09-30 13:19:31 [19193] [13] DEBUG:   command_id: 5 = 0x00000005
2008-09-30 13:19:31 [19193] [13] DEBUG:   command_status: 0 = 0x00000000
2008-09-30 13:19:31 [19193] [13] DEBUG:   sequence_number: 229 = 0x000000e5
2008-09-30 13:19:31 [19193] [13] DEBUG:   service_type: NULL
2008-09-30 13:19:31 [19193] [13] DEBUG:   source_addr_ton: 1 = 0x00000001
2008-09-30 13:19:31 [19193] [13] DEBUG:   source_addr_npi: 1 = 0x00000001
2008-09-30 13:19:31 [19193] [13] DEBUG:   source_addr: "3069XXXXXXXX"
2008-09-30 13:19:31 [19193] [13] DEBUG:   dest_addr_ton: 3 = 0x00000003
2008-09-30 13:19:31 [19193] [13] DEBUG:   dest_addr_npi: 9 = 0x00000009
2008-09-30 13:19:31 [19193] [13] DEBUG:   destination_addr: "99999"
2008-09-30 13:19:31 [19193] [13] DEBUG:   esm_class: 0 = 0x00000000
2008-09-30 13:19:31 [19193] [13] DEBUG:   protocol_id: 0 = 0x00000000
2008-09-30 13:19:31 [19193] [13] DEBUG:   priority_flag: 0 = 0x00000000
2008-09-30 13:19:31 [19193] [13] DEBUG:   schedule_delivery_time: NULL
2008-09-30 13:19:31 [19193] [13] DEBUG:   validity_period: NULL
2008-09-30 13:19:31 [19193] [13] DEBUG:   registered_delivery: 0 = 0x00000000
2008-09-30 13:19:31 [19193] [13] DEBUG:   replace_if_present_flag: 0 = 0x00000000
2008-09-30 13:19:31 [19193] [13] DEBUG:   data_coding: 3 = 0x00000003
2008-09-30 13:19:31 [19193] [13] DEBUG:   sm_default_msg_id: 0 = 0x00000000
2008-09-30 13:19:31 [19193] [13] DEBUG:   sm_length: 4 = 0x00000004
2008-09-30 13:19:31 [19193] [13] DEBUG:   short_message:
2008-09-30 13:19:31 [19193] [13] DEBUG:    Octet string at 0x8266ae0:
2008-09-30 13:19:31 [19193] [13] DEBUG:      len:  4
2008-09-30 13:19:31 [19193] [13] DEBUG:      size: 5
2008-09-30 13:19:31 [19193] [13] DEBUG:      immutable: 0
2008-09-30 13:19:31 [19193] [13] DEBUG:      data: 18 54 4f 16                                       .TO.
2008-09-30 13:19:31 [19193] [13] DEBUG:    Octet string dump ends.
2008-09-30 13:19:31 [19193] [13] DEBUG:   user_message_reference: 7 = 0x00000007
2008-09-30 13:19:31 [19193] [13] DEBUG: SMPP PDU dump ends.



>does that mean your SMSC requests utf8 instead of iso?
>
>
>On 03.10.2008, at 11:23, Michael Zervakis wrote:
>
>>/ Dear all,
/>>/
/>>/   We connect to a SMPP SMSC using kannel and we had problems reading  
/>>/ greek characters when data coding was set to 3. I attached the  
/>>/ modifications to gw/smsc/smsc_smpp.c that solved the problem.
/>>/
/>>/ Regards
/>>/ Index: gw/smsc/smsc_smpp.c
/>>/ ===================================================================
/>>/ RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
/>>/ retrieving revision 1.106
/>>/ diff -u -r1.106 smsc_smpp.c
/>>/ --- gw/smsc/smsc_smpp.c 16 Sep 2008 20:50:09 -0000      1.106
/>>/ +++ gw/smsc/smsc_smpp.c 3 Oct 2008 09:09:41 -0000
/>>/ @@ -519,6 +519,7 @@
/>>/             break;
/>>/         case 0x01: /* ASCII or IA5 - not sure if I need to do  
/>>/ anything */
/>>/         case 0x03: /* ISO-8859-1 - do nothing */
/>>/ +           charset_gsm_to_utf8(msg->>sms.msgdata);
/>>/             msg->>sms.coding = DC_7BIT; break;
/>>/         case 0x02: /* 8 bit binary - do nothing */
/>>/         case 0x04: /* 8 bit binary - do nothing */
/>>/ @@ -669,6 +670,7 @@
/>>/             break;
/>>/         case 0x01: /* ASCII or IA5 - not sure if I need to do  
/>>/ anything */
/>>/         case 0x03: /* ISO-8859-1 - do nothing */
/>>/ +           charset_gsm_to_utf8(msg->>sms.msgdata);
/>>/             msg->>sms.coding = DC_7BIT; break;
/>>/         case 0x02: /* 8 bit binary - do nothing */
/>>/         case 0x04: /* 8 bit binary - do nothing */
/
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.