I've finally had time to revisit this issue. Turns out that kannel
sends multi-part smses in *reverse* order. This happens whether
concatenation is true or false.
For example, lets say I send this 220 character-long message:
"test abcde fghijk abcde fghijk abcde fghijk abcde fghijk abcde
fghijk abcde fghijk abcde fghijk abcde fghijk abcde fghijk abcde
fghijk abcde fghijk abcde fghijk abcde fghijk abcde fghijk abcde
fghijk abcde fghijk abcde f"
The kannel modem log looks like this (edited for brevity):
DEBUG: AT2[modem]: TP-Validity-Period: 24.0 hours
DEBUG: AT2[modem]: --> AT+CMGS=79^M
DEBUG: AT2[modem]: <-- >
DEBUG: AT2[modem]: send command status: 1
DEBUG: AT2[modem]: -->
0051000C913629508133000011A74A05000300020240E6333AAD5E83C2E231B90C329FD1
69F51A14168FC96590F98C4EABD7A0B0784C2E83CC67745ABD0685C5637219643EA3D3EA
35282C1E93CB2033
DEBUG: AT2[modem]: --> ^Z
DEBUG: AT2[modem]: <-- >
DEBUG: AT2[modem]: <-- +CMGS: 239
DEBUG: AT2[modem]: <-- OK
DEBUG: AT2[modem]: send command status: 0
DEBUG: AT2[modem]: TP-Validity-Period: 24.0 hours
DEBUG: AT2[modem]: --> AT+CMGS=154^M
DEBUG: AT2[modem]: <-- >
DEBUG: AT2[modem]: send command status: 1
DEBUG: AT2[modem]: -->
0071000C913629508133000011A7A0050003000201E8E5391D14168FC96590F98C4EABD7
A0B0784C2E83CC67745ABD0685C5637219643EA3D3EA35282C1E93CB20F3199D56AF4161
F1985C0699CFE8B47A0D0A8BC7E432C87C46A7D56B50583C269741E6333AAD5E83C2E231
B90C329FD169F51A14168FC96590F98C4EABD7A0B0784C2E83CC67745ABD0685C5637219
643EA3D3EA35282C1E93CB
DEBUG: AT2[modem]: --> ^Z
DEBUG: AT2[modem]: <-- >
DEBUG: AT2[modem]: <-- +CMGS: 239
DEBUG: AT2[modem]: <-- OK
DEBUG: AT2[modem]: send command status: 0
Just eye-balling it looks suspicious. Since the message length is
220, the two parts are not going to be the same size. Shouldn't the
big part get sent first?
In fact, decoding the PDUs confirms my suspicion (using this). The
first pdu sent to the modem is
"fghijk abcde fghijk abcde fghijk abcde fghijk abcde fghijk abcde f"
which is clearly the second part. The second pdu sent to the modem is
"test abcde fghijk abcde fghijk abcde fghijk abcde fghijk abcde
fghijk abcde fghijk abcde fghijk abcde fghijk abcde fghijk abcde
fghijk abcde fghijk abcde"
which is clearly the first part.
Why is kannel reversing the sms order sent to the modem?
Thanks,
aaron
On Nov 5, 2007, at 12:44 PM, info.ubichip wrote:
Hi all,
AFAIK, send content through SMS should be managed by a protocol
such as SAR : Segmentation And Reassembly, this is a Mécanism used
to segment and reassemble the different paquets
SAR is used with wap gateway and is supposed to be handled by the
phone as well.
The fact that the packets are arrived in the correct order is upon
the operator responsibility (typically differents SMS are not
always proceed by the same SMSC), there is nothing to do on the
kannel side.
Hope that helps,
Regards
From: Ady Wicaksono [mailto:[EMAIL PROTECTED]
Sent: dimanche 4 novembre 2007 20:37
To: [EMAIL PROTECTED]
Cc: users@kannel.org
Subject: Re: multi-part sms order
It's normal, and offcourse mobile phone must wait all messages to
arrive first until it can reassemble the message.
On 11/5/07, Aaron Simmons <[EMAIL PROTECTED]> wrote:
My system is sending a lot of multi-part smses. While the sending
works, I've noticed that the parts usually arrive in reverse order
or out of order. e.g., if I'm sending a three-part sms, part three
will arrive at the user's phone first, followed by part two,
followed by part one. The user's phone will of course reassemble
the message, but they must wait to read their message until part
one arrives.
Is anyone else seeing this? Or is it an idiosyncracy of the gsm
phone I'm using to send the messages? I'm using kannel 1.4.1 with
a nokia.
Thanks,
aaron
--
Regards,
Ady Wicaksono
Email:
ady.wicaksono at gmail.com
http://adywicaksono.wordpress.com/
Antivirus avast!: message Sortant sain.
Base de donnees virale (VPS) : 071104-0, 04/11/2007
Analyse le : 04/11/2007 20:44:24
avast! - copyright (c) 1988-2007 ALWIL Software.
