Re: Strange concatenated MO issue
Hi, What is the corresponding access log entry? BR, Nikos - Original Message - From: Bopolissimus Platypus Jr bopolissimus.li...@gmail.com To: users@kannel.org Sent: Monday, August 30, 2010 12:44 AM Subject: Re: Strange concatenated MO issue Sorry about replying directly to you Nikos. I didn't realize that kannel wasn't also replying to the list. Forwarding to the list with additional questions. On Fri, Aug 27, 2010 at 9:57 AM, Bopolissimus Platypus Jr bopolissimus.li...@gmail.com wrote: 2010/8/26 Nikos Balkanas nbalka...@gmail.com: It looks like Unicode (UCS-2). Try mo-recode. However, you should check with your SMSc, why is he sending what is clearly 7bit GSM charset as unicode. Thank you Nikos. I had mo-recode enabled for that test and to be sure, I ensured that mo-recode = true is still in there and restarted kannel. I then sent the same text message and got the same result. These are nokia handsets, so I changed character encoding to Reduced support and sent the test message again. Same result. Sending the same message to another handset on the same network succeeds though, and to a handset on another network also succeeds. Is anyone familiar with compressed SMS messages (GSM 03.42). A scribd document (http://www.scribd.com/doc/6823124/handlingSMS) indicates that my TP-DCS (data_coding in the PDU) might be significant. If the fifth bit is 1 then GSM 03.42 is being used to compress the SMS message. And 240 decimal is binary. Does kannel have support for GSM 03.42? Or if not, does anyone on the list have a patch that decodes GSM 03.42? Thanks for any pointers, Gerald Quimpo
Re: Strange concatenated MO issue
2010/8/30 Nikos Balkanas nbalka...@gmail.com: What is the corresponding access log entry? I've been clearing the logs, so I don't have the corresponding entries for the previous message. Instead I tested again. Attached are both the relevant PDUs from the bearerbox log and the corresponding access log. I've added a bunch of fields in the access log for debugging. I've also semi-obfuscated some identifying information but nothing that would make analysis go wrong. 2010-08-29 23:23:12 [27180] [10] DEBUG: Optional parameter tag (0x0204) 2010-08-29 23:23:12 [27180] [10] DEBUG: Optional parameter length read as 2 2010-08-29 23:23:12 [27180] [10] DEBUG: SMPP[X-XX]: Got PDU: 2010-08-29 23:23:12 [27180] [10] DEBUG: SMPP PDU 0x8fd460 dump: 2010-08-29 23:23:12 [27180] [10] DEBUG: type_name: deliver_sm 2010-08-29 23:23:12 [27180] [10] DEBUG: command_id: 5 = 0x0005 2010-08-29 23:23:12 [27180] [10] DEBUG: command_status: 0 = 0x 2010-08-29 23:23:12 [27180] [10] DEBUG: sequence_number: 384 = 0x0180 2010-08-29 23:23:12 [27180] [10] DEBUG: service_type: NULL 2010-08-29 23:23:12 [27180] [10] DEBUG: source_addr_ton: 1 = 0x0001 2010-08-29 23:23:12 [27180] [10] DEBUG: source_addr_npi: 1 = 0x0001 2010-08-29 23:23:12 [27180] [10] DEBUG: source_addr: 649 2010-08-29 23:23:12 [27180] [10] DEBUG: dest_addr_ton: 2 = 0x0002 2010-08-29 23:23:12 [27180] [10] DEBUG: dest_addr_npi: 1 = 0x0001 2010-08-29 23:23:12 [27180] [10] DEBUG: destination_addr: 4008 2010-08-29 23:23:12 [27180] [10] DEBUG: esm_class: 64 = 0x0040 2010-08-29 23:23:12 [27180] [10] DEBUG: protocol_id: 0 = 0x 2010-08-29 23:23:12 [27180] [10] DEBUG: priority_flag: 1 = 0x0001 2010-08-29 23:23:12 [27180] [10] DEBUG: schedule_delivery_time: NULL 2010-08-29 23:23:12 [27180] [10] DEBUG: validity_period: NULL 2010-08-29 23:23:12 [27180] [10] DEBUG: registered_delivery: 0 = 0x 2010-08-29 23:23:12 [27180] [10] DEBUG: replace_if_present_flag: 0 = 0x 2010-08-29 23:23:12 [27180] [10] DEBUG: data_coding: 240 = 0x00f0 2010-08-29 23:23:12 [27180] [10] DEBUG: sm_default_msg_id: 0 = 0x 2010-08-29 23:23:12 [27180] [10] DEBUG: sm_length: 140 = 0x008c 2010-08-29 23:23:12 [27180] [10] DEBUG: short_message: 2010-08-29 23:23:12 [27180] [10] DEBUG:Octet string at 0x90d870: 2010-08-29 23:23:12 [27180] [10] DEBUG: len: 140 2010-08-29 23:23:12 [27180] [10] DEBUG: size: 141 2010-08-29 23:23:12 [27180] [10] DEBUG: immutable: 0 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 05 00 03 21 02 01 72 b9 5c 2e 97 cb e5 72 b9 58 ...!..r.\r.X 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 2e 97 cb e5 72 b9 5c 4e 96 cb e5 72 b9 5c 2e 97 r.\N...r.\.. 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 9b e5 72 b9 5c 2e 97 cb e5 68 b9 5c 2e 97 cb e5 ..r.\h.\ 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 72 b9 5a 2e 97 cb e5 72 b9 5c ce 96 cb e5 72 b9 r.Zr.\r. 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 5c 2e 97 bb e5 72 b9 5c 2e 97 cb e5 70 b9 5c 2e \r.\p.\. 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 97 cb e5 72 da 5c 2e 97 cb e5 72 b9 1c 2c 97 cb ...r.\r..,.. 2010-08-29 23:23:12 [27180] [10] DEBUG: data: e5 72 b9 5c 2e 17 cb e5 72 b9 5c 2e 97 cb c9 72 .r.\r.\r 2010-08-29 23:23:12 [27180] [10] DEBUG: data: b9 5c 2e 97 cb e5 72 b3 5c 2e 97 cb e5 72 b9 1c .\r.\r.. 2010-08-29 23:23:12 [27180] [10] DEBUG: data: 2d 97 cb e5 72 b9 5c 2e 57 cb e5 72 -...r.\.W..r 2010-08-29 23:23:12 [27180] [10] DEBUG:Octet string dump ends. 2010-08-29 23:23:12 [27180] [10] DEBUG: user_message_reference: 109 = 0x006d 2010-08-29 23:23:12 [27180] [10] DEBUG: SMPP PDU dump ends. 2010-08-29 23:23:12 [27180] [10] DEBUG: SMPP[X-XX]: UDH length read as 6 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xb9) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0x97) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xcb) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xe5) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xb9) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0x97) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xcb) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xe5) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xb9) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0x96) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xcb) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xe5) to Unicode. 2010-08-29 23:23:12 [27180] [10] WARNING: Could not convert GSM (0xb9) to Unicode. 2010-08-29 23:23:12 [27180] [10]
Re: Strange concatenated MO issue
Please never truncate emails. Problem is lost and thread looses coherence. I don't know your issue anymore. Repost. BR, Nikos - Original Message - From: Bopolissimus Platypus Jr bopolissimus.li...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Cc: users@kannel.org Sent: Monday, August 30, 2010 3:04 AM Subject: Re: Strange concatenated MO issue 2010/8/30 Nikos Balkanas nbalka...@gmail.com: What is the corresponding access log entry? I've been clearing the logs, so I don't have the corresponding entries for the previous message. Instead I tested again. Attached are both the relevant PDUs from the bearerbox log and the corresponding access log. I've added a bunch of fields in the access log for debugging. I've also semi-obfuscated some identifying information but nothing that would make analysis go wrong.
Re: Strange concatenated MO issue
It seems you don't understand list etiquette. Maybe someone else can help you. I guve up. Nikos - Original Message - From: Bopolissimus Platypus Jr bopolissimus.li...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Cc: users@kannel.org Sent: Monday, August 30, 2010 6:27 AM Subject: Re: Strange concatenated MO issue Hi Nikos, Reposting from earlier in the thread. I hope you don't mind if I comment in-line instead of top or bottom posting. 2010/8/26 Nikos Balkanas nbalka...@gmail.com: It looks like Unicode (UCS-2). Try mo-recode. However, you should check with your SMSc, why is he sending what is clearly 7bit GSM charset as unicode. Yes, mo-recode = true for the previous PDU and also for the new, attached, sample. Attached are results from a recent test. Handset sent the same long (digits only) SMS as in the example below. You had asked for access log entry. Since this is a new test I've attached a more complete bearerbox log, (PDUs for both parts of the concatenated SMS) and the corresponding access log entry (with a bunch of extra GET parameters for debugging). After some digging, this: 2010-08-26 04:27:12 [30851] [10] DEBUG: data_coding: 240 = 0x00f0 seems to indicate that the text is GSM 03.42 compressed. It's pretty clear it isn't unicode since kannel assumes the data is unicode but fails to convert to unicode. I'm assuming that data_coding corresponds to TP-DCS and our TP-DCS here is 240 which is binary . The document at: http://www.scribd.com/doc/6823124/handlingSMS indicates that if bit 5 is 1 then the text is compressed using GSM 03.42. Does Kannel support GSM 03.42? Or am I wrong about the equivalence of data_coding and TP-DCS? Gerald BR, Nikos - Original Message - From: Bopolissimus Platypus Jr bopolissimus.li...@gmail.com To: users@kannel.org Sent: Thursday, August 26, 2010 8:20 AM Subject: Strange concatenated MO issue Hello all, I have an SMSC connection to Telecom New Zealand. When I test my connection by sending a multipart text message from a handset to a shortcode I get weird text at kannel. Sending a single part text message from exactly the same handset works correctly. My long text message is: 99192939495969798Z9091929394959612345 What I receive at the get-url for the text is: text=r%C3%96.rX.r%C3%96Nr%C3%96.r%C3%96.h%C3%96.rZ.r%C3%96r%C3%96.r%C3%96.p%C3%96.r%C3%96.r%C3%86%2Cr%C3%96.%CE%A8r%C3%96.r%C3%96.r%C3%96.r%C3%86-r%C3%96.Wrr%C3%96.d3Z When I urldecode that I get (in hex, with a space between characters): c3 96 2e 72 58 2e 72 c3 96 4e 72 c3 96 2e 72 c3 96 2e 68 c3 96 2e 72 5a 2e 72 c3 96 72 c3 96 2e 72 c3 96 2e 70 c3 96 2e 72 c3 96 2e 72 c3 86 2c 72 c3 96 2e ce a8 72 c3 96 2e 72 c3 96 2e 72 c3 96 2e 72 c3 86 2d 72 c3 96 2e 57 72 72 c3 96 2e 64 33 5a Has anyone seen something similar to this and can point me at a solution (or in the direction of likely things to look at)? The initial PDU (with some information obfuscated and with some following messages) is: 2010-08-26 04:27:12 [30851] [10] DEBUG: Optional parameter tag (0x0204) 2010-08-26 04:27:12 [30851] [10] DEBUG: Optional parameter length read as 2 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP[X-XX]: Got PDU: 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP PDU 0xe0f580 dump: 2010-08-26 04:27:12 [30851] [10] DEBUG: type_name: deliver_sm 2010-08-26 04:27:12 [30851] [10] DEBUG: command_id: 5 = 0x0005 2010-08-26 04:27:12 [30851] [10] DEBUG: command_status: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: sequence_number: 351 = 0x015f 2010-08-26 04:27:12 [30851] [10] DEBUG: service_type: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr_ton: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr_npi: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr: 649 2010-08-26 04:27:12 [30851] [10] DEBUG: dest_addr_ton: 2 = 0x0002 2010-08-26 04:27:12 [30851] [10] DEBUG: dest_addr_npi: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: destination_addr: 2010-08-26 04:27:12 [30851] [10] DEBUG: esm_class: 64 = 0x0040 2010-08-26 04:27:12 [30851] [10] DEBUG: protocol_id: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: priority_flag: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: schedule_delivery_time: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: validity_period: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: registered_delivery: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: replace_if_present_flag: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: data_coding: 240 = 0x00f0 2010-08-26 04:27:12 [30851] [10] DEBUG: sm_default_msg_id: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: sm_length: 140 = 0x008c 2010-08-26 04:27:12 [30851] [10] DEBUG: short_message: 2010-08-26 04:27:12 [30851] [10] DEBUG: Octet string at 0xe0f4b0: 2010-08-26
Re: Strange concatenated MO issue
Hi, It looks like Unicode (UCS-2). Try mo-recode. However, you should check with your SMSc, why is he sending what is clearly 7bit GSM charset as unicode. BR, Nikos - Original Message - From: Bopolissimus Platypus Jr bopolissimus.li...@gmail.com To: users@kannel.org Sent: Thursday, August 26, 2010 8:20 AM Subject: Strange concatenated MO issue Hello all, I have an SMSC connection to Telecom New Zealand. When I test my connection by sending a multipart text message from a handset to a shortcode I get weird text at kannel. Sending a single part text message from exactly the same handset works correctly. My long text message is: 99192939495969798Z9091929394959612345 What I receive at the get-url for the text is: text=r%C3%96.rX.r%C3%96Nr%C3%96.r%C3%96.h%C3%96.rZ.r%C3%96r%C3%96.r%C3%96.p%C3%96.r%C3%96.r%C3%86%2Cr%C3%96.%CE%A8r%C3%96.r%C3%96.r%C3%96.r%C3%86-r%C3%96.Wrr%C3%96.d3Z When I urldecode that I get (in hex, with a space between characters): c3 96 2e 72 58 2e 72 c3 96 4e 72 c3 96 2e 72 c3 96 2e 68 c3 96 2e 72 5a 2e 72 c3 96 72 c3 96 2e 72 c3 96 2e 70 c3 96 2e 72 c3 96 2e 72 c3 86 2c 72 c3 96 2e ce a8 72 c3 96 2e 72 c3 96 2e 72 c3 96 2e 72 c3 86 2d 72 c3 96 2e 57 72 72 c3 96 2e 64 33 5a Has anyone seen something similar to this and can point me at a solution (or in the direction of likely things to look at)? The initial PDU (with some information obfuscated and with some following messages) is: 2010-08-26 04:27:12 [30851] [10] DEBUG: Optional parameter tag (0x0204) 2010-08-26 04:27:12 [30851] [10] DEBUG: Optional parameter length read as 2 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP[X-XX]: Got PDU: 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP PDU 0xe0f580 dump: 2010-08-26 04:27:12 [30851] [10] DEBUG: type_name: deliver_sm 2010-08-26 04:27:12 [30851] [10] DEBUG: command_id: 5 = 0x0005 2010-08-26 04:27:12 [30851] [10] DEBUG: command_status: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: sequence_number: 351 = 0x015f 2010-08-26 04:27:12 [30851] [10] DEBUG: service_type: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr_ton: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr_npi: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr: 649 2010-08-26 04:27:12 [30851] [10] DEBUG: dest_addr_ton: 2 = 0x0002 2010-08-26 04:27:12 [30851] [10] DEBUG: dest_addr_npi: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: destination_addr: 2010-08-26 04:27:12 [30851] [10] DEBUG: esm_class: 64 = 0x0040 2010-08-26 04:27:12 [30851] [10] DEBUG: protocol_id: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: priority_flag: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: schedule_delivery_time: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: validity_period: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: registered_delivery: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: replace_if_present_flag: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: data_coding: 240 = 0x00f0 2010-08-26 04:27:12 [30851] [10] DEBUG: sm_default_msg_id: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: sm_length: 140 = 0x008c 2010-08-26 04:27:12 [30851] [10] DEBUG: short_message: 2010-08-26 04:27:12 [30851] [10] DEBUG:Octet string at 0xe0f4b0: 2010-08-26 04:27:12 [30851] [10] DEBUG: len: 140 2010-08-26 04:27:12 [30851] [10] DEBUG: size: 141 2010-08-26 04:27:12 [30851] [10] DEBUG: immutable: 0 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 05 00 03 16 02 01 72 b9 5c 2e 97 cb e5 72 b9 58 ..r.\r.X 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 2e 97 cb e5 72 b9 5c 4e 96 cb e5 72 b9 5c 2e 97 r.\N...r.\.. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 9b e5 72 b9 5c 2e 97 cb e5 68 b9 5c 2e 97 cb e5 ..r.\h.\ 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 72 b9 5a 2e 97 cb e5 72 b9 5c ce 96 cb e5 72 b9 r.Zr.\r. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 5c 2e 97 bb e5 72 b9 5c 2e 97 cb e5 70 b9 5c 2e \r.\p.\. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 97 cb e5 72 da 5c 2e 97 cb e5 72 b9 1c 2c 97 cb ...r.\r..,.. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: e5 72 b9 5c 2e 17 cb e5 72 b9 5c 2e 97 cb c9 72 .r.\r.\r 2010-08-26 04:27:12 [30851] [10] DEBUG: data: b9 5c 2e 97 cb e5 72 b3 5c 2e 97 cb e5 72 b9 1c .\r.\r.. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 2d 97 cb e5 72 b9 5c 2e 57 cb e5 72 -...r.\.W..r 2010-08-26 04:27:12 [30851] [10] DEBUG:Octet string dump ends. 2010-08-26 04:27:12 [30851] [10] DEBUG: user_message_reference: 85 = 0x0055 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP PDU dump ends. 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP[MAS01-RX]: UDH length read as 6 2010
Strange concatenated MO issue
Hello all, I have an SMSC connection to Telecom New Zealand. When I test my connection by sending a multipart text message from a handset to a shortcode I get weird text at kannel. Sending a single part text message from exactly the same handset works correctly. My long text message is: 99192939495969798Z9091929394959612345 What I receive at the get-url for the text is: text=r%C3%96.rX.r%C3%96Nr%C3%96.r%C3%96.h%C3%96.rZ.r%C3%96r%C3%96.r%C3%96.p%C3%96.r%C3%96.r%C3%86%2Cr%C3%96.%CE%A8r%C3%96.r%C3%96.r%C3%96.r%C3%86-r%C3%96.Wrr%C3%96.d3Z When I urldecode that I get (in hex, with a space between characters): c3 96 2e 72 58 2e 72 c3 96 4e 72 c3 96 2e 72 c3 96 2e 68 c3 96 2e 72 5a 2e 72 c3 96 72 c3 96 2e 72 c3 96 2e 70 c3 96 2e 72 c3 96 2e 72 c3 86 2c 72 c3 96 2e ce a8 72 c3 96 2e 72 c3 96 2e 72 c3 96 2e 72 c3 86 2d 72 c3 96 2e 57 72 72 c3 96 2e 64 33 5a Has anyone seen something similar to this and can point me at a solution (or in the direction of likely things to look at)? The initial PDU (with some information obfuscated and with some following messages) is: 2010-08-26 04:27:12 [30851] [10] DEBUG: Optional parameter tag (0x0204) 2010-08-26 04:27:12 [30851] [10] DEBUG: Optional parameter length read as 2 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP[X-XX]: Got PDU: 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP PDU 0xe0f580 dump: 2010-08-26 04:27:12 [30851] [10] DEBUG: type_name: deliver_sm 2010-08-26 04:27:12 [30851] [10] DEBUG: command_id: 5 = 0x0005 2010-08-26 04:27:12 [30851] [10] DEBUG: command_status: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: sequence_number: 351 = 0x015f 2010-08-26 04:27:12 [30851] [10] DEBUG: service_type: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr_ton: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr_npi: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr: 649 2010-08-26 04:27:12 [30851] [10] DEBUG: dest_addr_ton: 2 = 0x0002 2010-08-26 04:27:12 [30851] [10] DEBUG: dest_addr_npi: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: destination_addr: 2010-08-26 04:27:12 [30851] [10] DEBUG: esm_class: 64 = 0x0040 2010-08-26 04:27:12 [30851] [10] DEBUG: protocol_id: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: priority_flag: 1 = 0x0001 2010-08-26 04:27:12 [30851] [10] DEBUG: schedule_delivery_time: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: validity_period: NULL 2010-08-26 04:27:12 [30851] [10] DEBUG: registered_delivery: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: replace_if_present_flag: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: data_coding: 240 = 0x00f0 2010-08-26 04:27:12 [30851] [10] DEBUG: sm_default_msg_id: 0 = 0x 2010-08-26 04:27:12 [30851] [10] DEBUG: sm_length: 140 = 0x008c 2010-08-26 04:27:12 [30851] [10] DEBUG: short_message: 2010-08-26 04:27:12 [30851] [10] DEBUG:Octet string at 0xe0f4b0: 2010-08-26 04:27:12 [30851] [10] DEBUG: len: 140 2010-08-26 04:27:12 [30851] [10] DEBUG: size: 141 2010-08-26 04:27:12 [30851] [10] DEBUG: immutable: 0 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 05 00 03 16 02 01 72 b9 5c 2e 97 cb e5 72 b9 58 ..r.\r.X 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 2e 97 cb e5 72 b9 5c 4e 96 cb e5 72 b9 5c 2e 97 r.\N...r.\.. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 9b e5 72 b9 5c 2e 97 cb e5 68 b9 5c 2e 97 cb e5 ..r.\h.\ 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 72 b9 5a 2e 97 cb e5 72 b9 5c ce 96 cb e5 72 b9 r.Zr.\r. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 5c 2e 97 bb e5 72 b9 5c 2e 97 cb e5 70 b9 5c 2e \r.\p.\. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 97 cb e5 72 da 5c 2e 97 cb e5 72 b9 1c 2c 97 cb ...r.\r..,.. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: e5 72 b9 5c 2e 17 cb e5 72 b9 5c 2e 97 cb c9 72 .r.\r.\r 2010-08-26 04:27:12 [30851] [10] DEBUG: data: b9 5c 2e 97 cb e5 72 b3 5c 2e 97 cb e5 72 b9 1c .\r.\r.. 2010-08-26 04:27:12 [30851] [10] DEBUG: data: 2d 97 cb e5 72 b9 5c 2e 57 cb e5 72 -...r.\.W..r 2010-08-26 04:27:12 [30851] [10] DEBUG:Octet string dump ends. 2010-08-26 04:27:12 [30851] [10] DEBUG: user_message_reference: 85 = 0x0055 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP PDU dump ends. 2010-08-26 04:27:12 [30851] [10] DEBUG: SMPP[MAS01-RX]: UDH length read as 6 2010-08-26 04:27:12 [30851] [10] WARNING: Could not convert GSM (0xb9) to Unicode. 2010-08-26 04:27:12 [30851] [10] WARNING: Could not convert GSM (0x97) to Unicode. 2010-08-26 04:27:12 [30851] [10] WARNING: Could not convert GSM (0xcb) to Unicode. 2010-08-26 04:27:12 [30851] [10] WARNING: Could not convert GSM (0xe5) to Unicode. 2010-08-26 04:27:12 [30851] [10] WARNING: Could
