It's a tough call on whether or not to cache incoming SMS in the SIM.
Overall I think it possibly is a better policy than having Deliver SM's
come straight through to the TE. The "risk" is that messages are not read
and deleted quickly enough to prevent the SIM from filling. As long as
incoming messages have higher priority than outgoing, then all should
be OK.
To get 100% reliability of DeliverSM's, smsc_at simply needs to check
for them on all modem reads. At present it is possible for reads within
Submit SM to "swallow" a Deliver SM. I would like to see a dual-threaded
architecture, with separate read and write threads.
Has anybody tried setting the Message Reference field to anything other than
zero ? I tried with Orange and it seems to ignore it. If the MR could be
set,
then this could be used to synchronise the SubmitSM with the SubmitSMS
Report.
Paul Keogh wrote :-
I'm not sure that catching CMT indications for new messages is fully
reliable either. I've done some prototyping using the Win32 serial
interface (which is quite different from the select() model) and came
to the conclusion that mapping the Kannel pending/read polling onto
the AT+CMGL command never loses a message; however it does mean that
messages are stored onto the SIM by the M20 which has its own
advantages and disadvantages. I've tried various combinations of CNMI=x,x
and would be interested to if others have had 100% success in catching
all new message indications.
