It is possible to send 160 'a's as a single sms because I suppose these should each fit in 1 septet in the GSM alphabet. Please take a look at the PDU dump below:
2009-10-01 15:37:10 [31609] [7] DEBUG: SMPP PDU 0xab200c30 dump: 2009-10-01 15:37:10 [31609] [7] DEBUG: type_name: submit_sm 2009-10-01 15:37:10 [31609] [7] DEBUG: command_id: 4 = 0x00000004 2009-10-01 15:37:10 [31609] [7] DEBUG: command_status: 0 = 0x00000000 2009-10-01 15:37:10 [31609] [7] DEBUG: sequence_number: 418 = 0x000001a2 2009-10-01 15:37:10 [31609] [7] DEBUG: service_type: "6502" 2009-10-01 15:37:10 [31609] [7] DEBUG: source_addr_ton: 0 = 0x00000000 2009-10-01 15:37:10 [31609] [7] DEBUG: source_addr_npi: 1 = 0x00000001 2009-10-01 15:37:10 [31609] [7] DEBUG: source_addr: "6502" 2009-10-01 15:37:10 [31609] [7] DEBUG: dest_addr_ton: 1 = 0x00000001 2009-10-01 15:37:10 [31609] [7] DEBUG: dest_addr_npi: 1 = 0x00000001 2009-10-01 15:37:10 [31609] [7] DEBUG: destination_addr: "254722683186" 2009-10-01 15:37:10 [31609] [7] DEBUG: esm_class: 0 = 0x00000000 2009-10-01 15:37:10 [31609] [7] DEBUG: protocol_id: 0 = 0x00000000 2009-10-01 15:37:10 [31609] [7] DEBUG: priority_flag: 0 = 0x00000000 2009-10-01 15:37:10 [31609] [7] DEBUG: schedule_delivery_time: NULL 2009-10-01 15:37:10 [31609] [7] DEBUG: validity_period: NULL 2009-10-01 15:37:10 [31609] [7] DEBUG: registered_delivery: 1 = 0x00000001 2009-10-01 15:37:10 [31609] [7] DEBUG: replace_if_present_flag: 0 = 0x00000000 2009-10-01 15:37:10 [31609] [7] DEBUG: data_coding: 0 = 0x00000000 2009-10-01 15:37:10 [31609] [7] DEBUG: sm_default_msg_id: 0 = 0x00000000 2009-10-01 15:37:10 [31609] [7] DEBUG: sm_length: 160 = 0x000000a0 2009-10-01 15:37:10 [31609] [7] DEBUG: short_message: 2009-10-01 15:37:10 [31609] [7] DEBUG: Octet string at 0xab2007a8: 2009-10-01 15:37:10 [31609] [7] DEBUG: len: 160 2009-10-01 15:37:10 [31609] [7] DEBUG: size: 161 2009-10-01 15:37:10 [31609] [7] DEBUG: immutable: 0 2009-10-01 15:37:10 [31609] [7] DEBUG: data: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 2009-10-01 15:37:10 [31609] [7] DEBUG: data: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 2009-10-01 15:37:10 [31609] [7] DEBUG: data: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 2009-10-01 15:37:10 [31609] [7] DEBUG: data: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 2009-10-01 15:37:10 [31609] [7] DEBUG: data: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 2009-10-01 15:37:10 [31609] [7] DEBUG: data: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 2009-10-01 15:37:10 [31609] [7] DEBUG: data: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 2009-10-01 15:37:10 [31609] [7] DEBUG: data: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 2009-10-01 15:37:10 [31609] [7] DEBUG: data: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 2009-10-01 15:37:10 [31609] [7] DEBUG: data: 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa 2009-10-01 15:37:10 [31609] [7] DEBUG: Octet string dump ends. 2009/10/1 Nikos Balkanas <[email protected]>: > No, they are not! As it says in debug log, and can verify from pdu dump, > sm_length = 80. Guess what? oct_length is also 80! Where is your evidence > that any single character is split in more than 1 byte? > > You cannot send 160 B of text in a single SMS. You have to leave space for > UDH. Where the SMS will split (middle, end, etc.) is configured with the > split-chars variable in sendsms-user group. > > Have you tried sending 160 'a's as a single sms? > > BR, > Nikos > ----- Original Message ----- From: "Jason Mule" <[email protected]> > To: "Nikos Balkanas" <[email protected]> > Cc: <[email protected]> > Sent: Thursday, October 01, 2009 11:36 AM > Subject: Re: message split in SUBMIT_SM pdu due to extended GSM characters > > >> Please take a look at the PDU dump below. It seems that these >> characters are counted as occupying 2 bytes and yet we are using >> ASCII: >> >> 2009-10-01 11:18:52 [9435] [7] DEBUG: type_name: submit_sm >> 2009-10-01 11:18:52 [9435] [7] DEBUG: command_id: 4 = 0x00000004 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: command_status: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: sequence_number: 1775 = 0x000006ef >> 2009-10-01 11:18:52 [9435] [7] DEBUG: service_type: "6502" >> 2009-10-01 11:18:52 [9435] [7] DEBUG: source_addr_ton: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: source_addr_npi: 1 = 0x00000001 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: source_addr: "6502" >> 2009-10-01 11:18:52 [9435] [7] DEBUG: dest_addr_ton: 1 = 0x00000001 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: dest_addr_npi: 1 = 0x00000001 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: destination_addr: "250789112112" >> 2009-10-01 11:18:52 [9435] [7] DEBUG: esm_class: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: protocol_id: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: priority_flag: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: schedule_delivery_time: NULL >> 2009-10-01 11:18:52 [9435] [7] DEBUG: validity_period: NULL >> 2009-10-01 11:18:52 [9435] [7] DEBUG: registered_delivery: 1 = >> 0x00000001 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: replace_if_present_flag: 0 = >> 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data_coding: 0 = 0x00000000 >> <-- default coding (ASCII) >> 2009-10-01 11:18:52 [9435] [7] DEBUG: sm_default_msg_id: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: sm_length: 80 = 0x00000050 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: short_message: >> 2009-10-01 11:18:52 [9435] [7] DEBUG: Octet string at 0x9360ed0: >> 2009-10-01 11:18:52 [9435] [7] DEBUG: len: 80 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: size: 81 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: immutable: 0 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data: 7b 7d 7b 7d 7b 7d 7b >> 7d 7b 7d 7b 7d 7b 7d 7b 7d {}{}{}{}{}{}{}{} >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data: 7b 7d 7b 7d 7b 7d 7b >> 7d 7b 7d 7b 7d 7b 7d 7b 7d {}{}{}{}{}{}{}{} >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data: 7b 7d 7b 7d 7b 7d 7b >> 7d 7b 7d 7b 7d 7c 7c 7c 7c {}{}{}{}{}{}|||| >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data: 7c 7c 7c 7c 7c 7c 7c >> 7c 7b 7d 7b 7d 7b 7d 7b 7d ||||||||{}{}{}{} >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data: 7b 7d 7b 7d 7b 7d 7b >> 7d 7b 7d 7b 7d 7b 7d 7b 7d {}{}{}{}{}{}{}{} >> 2009-10-01 11:18:52 [9435] [7] DEBUG: Octet string dump ends. >> 2009-10-01 11:18:52 [9435] [7] DEBUG: SMPP PDU dump ends. >> ...(split occurs here and the second part is sent out) >> 2009-10-01 11:18:52 [9435] [7] DEBUG: SMPP[MAGPIE1]: Sending PDU: >> 2009-10-01 11:18:52 [9435] [7] DEBUG: SMPP PDU 0x936a260 dump: >> 2009-10-01 11:18:52 [9435] [7] DEBUG: type_name: submit_sm >> 2009-10-01 11:18:52 [9435] [7] DEBUG: command_id: 4 = 0x00000004 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: command_status: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: sequence_number: 1776 = 0x000006f0 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: service_type: "6502" >> 2009-10-01 11:18:52 [9435] [7] DEBUG: source_addr_ton: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: source_addr_npi: 1 = 0x00000001 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: source_addr: "6502" >> 2009-10-01 11:18:52 [9435] [7] DEBUG: dest_addr_ton: 1 = 0x00000001 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: dest_addr_npi: 1 = 0x00000001 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: destination_addr: "250789112112" >> 2009-10-01 11:18:52 [9435] [7] DEBUG: esm_class: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: protocol_id: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: priority_flag: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: schedule_delivery_time: NULL >> 2009-10-01 11:18:52 [9435] [7] DEBUG: validity_period: NULL >> 2009-10-01 11:18:52 [9435] [7] DEBUG: registered_delivery: 0 = >> 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: replace_if_present_flag: 0 = >> 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data_coding: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: sm_default_msg_id: 0 = 0x00000000 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: sm_length: 80 = 0x00000050 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: short_message: >> 2009-10-01 11:18:52 [9435] [7] DEBUG: Octet string at 0x936d0f8: >> 2009-10-01 11:18:52 [9435] [7] DEBUG: len: 80 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: size: 81 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: immutable: 0 >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data: 7b 7d 7b 7d 7b 7d 7b >> 7d 7b 7d 7b 7d 7b 7d 7c 7c {}{}{}{}{}{}{}|| >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data: 7c 7c 7c 7c 7c 7c 7c >> 7c 7c 7c 7c 7c 7c 7c 7c 7c |||||||||||||||| >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data: 7c 7c 7c 7c 7c 7c 7c >> 7c 7c 7c 7c 7c 7c 7c 7c 7c |||||||||||||||| >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data: 7c 7c 7c 7c 7c 7c 7c >> 7c 7c 7c 7c 7c 7c 7c 7c 7c |||||||||||||||| >> 2009-10-01 11:18:52 [9435] [7] DEBUG: data: 7c 7c 7c 7c 7c 7c 7c >> 7c 7c 7c 7c 7d 7c 5e 5e 5e |||||||||||}|^^^ >> >> >> >> >> 2009/9/30 Nikos Balkanas <[email protected]>: >>> >>> Hi, >>> >>> Well, you should also count in UDH. I believe this is 7 chars. So in >>> reality >>> you are sending 167 chars. >>> >>> BR, >>> Nikos >>> ----- Original Message ----- From: "Jason Mule" <[email protected]> >>> To: <[email protected]> >>> Sent: Wednesday, September 30, 2009 8:38 PM >>> Subject: message split in SUBMIT_SM pdu due to extended GSM characters >>> >>> >>>> Hello, >>>> >>>> It appears that a 160 character message containing extended gsm >>>> characters e.g. [,\,],^,{,|,},~ will be split into 2 messages even >>>> though the default SMSC alphabet is ASCII. I have just tested this >>>> using Kannel 1.4.3. Is anyone able to shed more light on this? Thanks. >>>> >>>> -- >>>> Kind regards >>>> Jason Mule >>>> >>> >>> >> >> >> >> -- >> Kind regards >> Jason Mule > > -- Kind regards Jason Mule ............................................ MOBILE PLANET for Work, for Fun, for Africa tel: +254 (20) 4456182, 4456183 fax: +254(20)4456184 cel: +254 (722) 389022, (734) 330061 Westlands Office Park Waiyaki Way, Westlands www.mobileplanet.co.ke This e-mail, its attachments and any rights attaching hereto are, unless the content clearly indicates otherwise, the property of Mobile Planet Limited and its associate companies. It is confidential, private and intended for only the addressee. Should you not be the addressee and receive this e-mail by mistake, kindly notify the sender, and delete this e-mail immediately. Do not disclose or use it in any way. Views and opinions expressed in this e-mail are those of the sender unless clearly stated as those of Mobile Planet Limited. Further, this e-mail and its contents are not intended to disclose any legally binding intention and must not be taken as an offer, acceptance of an offer or representation giving rise to legal obligations. Mobile Planet Limited accepts no liability for any loss or damages howsoever incurred, or suffered, resulting or arising, from the use of this email or its attachments. Mobile Planet Limited does not warrant the integrity of this e-mail nor that it is free of errors, viruses, interception or interference.
