Here's an explanation of how the GSM modem sends and receives SMS and
DLRs.
Based on the setting for the +CNMI (New Message Indictor), an MO SMS
(one originating from a phone and heading to your GSM modem) can get
the GSM modem to inform Kannel when it receives an SMS. The first
way is an unsolicited notification with the hexadecimal representation
of the PDU. This would be the "+CMT: ,##" followed by a long string
of hexadecimal numbers in your bearerbox log. When the bearerbox
receives this, it will respond back to the GSM network that it
has received the SMS via a +CNMA (New Message Acknowledgement).
If the modem does not receive an AT+CNMA from the bearerbox with
a specified time, the GSM modem will send back a RP-ERROR to the
GSM network's SMSC indicating problems receiving the SMS. The
Operator's SMSC will reschedule the SMS for another delivery attempt.
Therefore, DELAYING THE NEW MESSAGE ACKNOWLEDGEMENT CAN RESULT IN
RECEPTION OF DUPLICATE SMS.
Another method the GSM modem can use to inform Kannel of an incoming
MO SMS is with a unsolicited notification with the PDU stored in the
store memory (be it the device's [ME] or SIM [SM]). This would be
the "+CMTI: "XX",#" you see in your bearerbox logs. The "XX" indicates
the store memory used (again "ME" means the device's memory and "SM"
means the SIM card's memory) and the # indicates the index number of
of the storage location holding the received MO SMS. In this case,
no New Mesage Acknowledgement is submitted by the bearerbox because
the GSM modem automatically acknowledges the reception for you.
BUT YOU STILL GET THAT UNSOLICITED NOTIFICATION INTERRUPTING ANY
CURRENT TRANSACTION HAPPENING ON THE MODEM!
As you might have noticed, that unsolicited notification (+CMT: or
+CMTI:) can pop up at anytime...even during the middle of the
bearerbox sending out an SMS via the AT+CMGS command. When that
unsolicited notification show up in the middle of a send, the
bearerbox freak out and assumes an error because it expects the
GSM modem to send a '>' at the beginning of the line when it
issues the AT+CMGS command. Actually, depending on wheter that '>'
appears before the +CMT:/+CMTI: or after it, Kannel might see it.
Now, for those of you adding DLR's to the mix, there's an additional
problem.
DLR's are sent to the GSM modem as special SMS and the GSM modem
will inform Kannel about a DLR via another unsolicited notification,
the "+CDS: ,##" (Delivery Status) followed by a long string of hexadecimal
numbers you see in the bearerbox logs. +CDS also needs an AT+CNMA
acknowledgement. And, just like +CMT, +CDS has the same ramifications
for delaying that acknowledgement.
And just like +CMTI:, a delivery report can slip into store memory
and pop up an unsolicited notification of "+CDSI: "XX",#" right in
the middle of things. But one new twist is that newer GSM modems
seem to have additional store memory specifically for delivery reports.
This new "SR" store memory complicates the issue.
Kannel has the capability to check the store memory for both the
device and one other storage location (determined by the
"message-storage" declaration of the modems section). This is the
"sim-buffering" declaration you see in the AT SMSC. Unfortunately,
the bearerbox does not know how to look at 3 different stores
("ME", "SM", "SR") yet.
The consequences are that DLRs could slip into the "SR" memory
and be overlooked by the "check memory store for incoming SMS/DLR"
thread that runs periodcally based on the "keepalive" value or 60 seconds
if the "keepalive" is not set. Also, this thread is responsible
for draining the queue inside of the memory store. If that thread
does not know about the "SR" memory, then the only time a DLR
can be retrieve from the "SR" memory would be when the +CDSI:
shows up...and then only one DLR will be retrieved from the
"SR" memory. I have a feeling that might be the reason why
"JML" was seeing multiple DLRs for the same message ID ("ts" field
in Kannel's DLR logging, "+CMGS: ##" from the GSM modem).
So, in addition to incoming SMS/DLR interrupting out-going SMS you
might also have the problem of DLR slipping into a memory store
overlooked by the bearerbox.
What is a solution to this problem? Rewrite the AT driver with
a more robust state engine that can support unsolicited notifications
better. Also, update the driver to support dipping into more that
two memory stores for SMS/DLR.
Just a note. The AT driver (what us oldies actually call AT2 for
historical reasons) was originally written back in 2001. It was
not designed for high traffic but more of a convenience for testing
services or sending VERY low traffic. Given the fact that circa 2001,
most GSM modems where 9600 baud DCE and one SMS too about 5 seconds
to transmit over-the-air, you can understand how the AT driver was
not really in the same league as a real connection to an SMSC.
See ya...
d.c.
**>From: "JML" <[EMAIL PROTECTED]>
**>To: "'B. Indrawan'" <[EMAIL PROTECTED]>, "'Kannel'" <[email protected]>
**>Subject: RE : Kannel with dlr and wavecom
**>Date: Tue, 22 Feb 2005 14:58:20 +0100
**>
**>Hi,
**>
**>Could you please send us your changes in gw/smsc/smsc_at.c ?
**>Thanks...
**>It may be the better way to do, as the process is slowing down only when
**>receiving DLR.
**>
**>What i am triyng to do seems not to work as SR (Status Reports) causes
**>the following :
**><-- +CDSI: "SR",5
**>+CMTI incoming SMS indication: +CDSI: "SR",5
**>--> AT+CMGR=5^M
**><-- +CMS ERROR: 321
**>CMS ERROR: +CMS ERROR: 321 (Invalid memory index -> don't worry, just
**>memory fragmentation.)
**>failed to get message 5.
**>CMTI notification received, but no message found in memory!
**>
**>I think Kannel search in the "SM" memory instead of "SR" as the modem
**>tells ...
**>
**>
**>-----Message d'origine-----
**>De : B. Indrawan [mailto:[EMAIL PROTECTED]
**>Envoy? : mardi 22 f?vrier 2005 13:46
**>? : [EMAIL PROTECTED]; 'Kannel'
**>Objet : RE: Kannel with dlr and wavecom
**>
**>
**>Hi,
**>
**>I got the same problem, I posted once before but no one response my
**>posting, and then I think only myself who got that pb :(.
**>
**>Could you check, the problem appears when kannel sends a message and the
**>dlr's previous message is coming.
**>
**>Because when kannel waiting for PDU message, it sends AT+CNMA (message
**>ack for incoming dlr). It's caused ' AT2[wavecom]: <-- ERROR '.
**>
**>I modified file gw/smsc/smsc_at.c, so kannel locks sending message ack
**>(AT+CNMA) when the kannel is sending message, and the lock released
**>after kannel finishes sending the message, then message ack sent (if
**>there is a pending message ack).
**>
**>It helps pretty enough, but I know C language not pretty well.
**>
**>Anyone have better idea than mine?
**>
**>Thanks,
**>Indra.
**>
**>-----Original Message-----
**>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
**>Behalf Of JML
**>Sent: Tuesday, February 22, 2005 7:00 PM
**>To: 'Kannel'
**>Subject: RE : Kannel with dlr and wavecom
**>
**>Hi,
**>Encounter the exact same pb...with same config !
**>As far as the modem can't send more than almost 1SMS/5secondes, i added
**>a need-sleep = true And sendline-sleep = 3000. (3s) This for the moment
**>seems to work, but get pb with DLR return ID. You can add keepalive-cmd
**>= "AT+CMEE=1"
**>It should tell you the exact error code (probably 515 : Please wait,
**>init or command processing in progress). In fact while the modem is
**>receiving a status report, kannel try to send a new SMS but get an error
**>becaus the modem is already working. Is it a bug ? Is it a malfunctiun ?
**>I think we need to rewrite the at driver, in order to analize the return
**>error code when occurs and in cas of 515 make a sleep or something like
**>that.
**>
**>I am working on it, but if you get something new please tell me !!
**>
**>Marco
**>
**>
**>-----Message d'origine-----
**>De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la
**>part de [EMAIL PROTECTED] Envoy? : mardi 22 f?vrier 2005 12:19 ? :
**>Kannel Objet : Kannel with dlr and wavecom
**>
**>
**>Hello all,
**>I have recompiled Kannel 1.4 for dlr support with MySql, and configured
**>for use with Wavecom M1206B.
**>
**>The system works well, when i send one sms:
**> dlr table, on mysql server, is populated and i receive correctly dlr
**>responce. The problem is when i send more than one sms, dlr does not
**>work in deterministic way and kannel it answers with
**>
**>2005-02-19 15:44:45 [11825] [7] DEBUG: AT2[wavecom]: <-- 2005-02-19
**>15:44:45 [11825] [7] DEBUG: AT2[wavecom]: <-- ERROR 2005-02-19 15:44:45
**>[11825] [7] ERROR: AT2[wavecom]: Error occurs: ERROR
**>(error number not known to us. ask google and add it.)
**>
**>I explain myself. I have developed a simple php page, based on kannel
**>examples, that, for a given number, send a determined number of
**>messages. I have tried to balance the number of messages per second
**>through the "throughput" variable of smsc group, but it seems to be
**>useless.
**>
**>Finally i have inserted a sleep function, of 15 seconds, between every
**>http get, in this manner the dlr works well, but the throupghput is
**>lowest.
**>
**>Someone of you has faced and resolved the problem?
**>Can i send you configuration files and kannel debug info?
**>
**>Thanks for your help,
**> Nicola Provenzano
