It seems you don't understand list etiquette. Maybe someone else can help
you. I guve up.
Nikos
----- Original Message -----
From: "Bopolissimus Platypus Jr" <[email protected]>
To: "Nikos Balkanas" <[email protected]>
Cc: <[email protected]>
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 <[email protected]>:
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 = 0x000000f0
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 11110000.
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"
<[email protected]>
To: <[email protected]>
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:
"99999999991999999999299999999939999999994999999999599999999969999999997999999999899999999Z999999999099999999919999999992999999999399999999949999999995999999999612345"
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[XXXXX-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 = 0x00000005
2010-08-26 04:27:12 [30851] [10] DEBUG: command_status: 0 = 0x00000000
2010-08-26 04:27:12 [30851] [10] DEBUG: sequence_number: 351 =
0x0000015f
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 = 0x00000001
2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr_npi: 1 = 0x00000001
2010-08-26 04:27:12 [30851] [10] DEBUG: source_addr: "64999999999"
2010-08-26 04:27:12 [30851] [10] DEBUG: dest_addr_ton: 2 = 0x00000002
2010-08-26 04:27:12 [30851] [10] DEBUG: dest_addr_npi: 1 = 0x00000001
2010-08-26 04:27:12 [30851] [10] DEBUG: destination_addr: "9999"
2010-08-26 04:27:12 [30851] [10] DEBUG: esm_class: 64 = 0x00000040
2010-08-26 04:27:12 [30851] [10] DEBUG: protocol_id: 0 = 0x00000000
2010-08-26 04:27:12 [30851] [10] DEBUG: priority_flag: 1 = 0x00000001
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 =
0x00000000
2010-08-26 04:27:12 [30851] [10] DEBUG: replace_if_present_flag: 0 =
0x00000000
2010-08-26 04:27:12 [30851] [10] DEBUG: data_coding: 240 = 0x000000f0
2010-08-26 04:27:12 [30851] [10] DEBUG: sm_default_msg_id: 0 =
0x00000000
2010-08-26 04:27:12 [30851] [10] DEBUG: sm_length: 140 = 0x0000008c
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.Z....r.\....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 =
0x00000055
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 not convert GSM (0xb9)
to Unicode.
2010-08-26 04:27:12 [30851] [10] WARNING: Could not convert GSM (0x97)
to Unicode.
Thanks for any clues, discussion and assistance.
Gerald Quimpo
--
Gerald Timothy Quimpo http://bopolissimus.blogspot.com
[email protected] [email protected]
Even Tom Lane said: "Or, if you're worried
about actions from functions, use a trigger
to do the logging. There are approximately
no cases where a rule is really better than
a trigger :-( "
