Mat wrote:Ok! So if I understand well, I've to spank my operator because he has a broken SMSC ?
The goal is to monitor the SMSC connection with the GSM modem.
For this, I send a specific keyword with the modem, and I wait for the answer.
In order to make the tests more reliable, I use a dlrmask=31 when I send the MO,
so our monitoring don't shout for a stupid network problem.
This part works almost fine, but the success isn't as accurate:
Sometimes when I send an SMS with the modem, I got a DLR call with a value of 1
which should mean that the MO has been delivered. Before the dlrvalue=1, I can
have a DLR call with dlrvalue=8 or dlrvalue=4.
8 (SMSC_SUCCESS) means that the modem successfuly sent the message to the network and received the network's message ID for that SM. 4 (BUFFERED) means that the message was stored on the network (modem's SMSC peer) but was not forwarded to the recipient yet. this message will only be received if the network was unable to deliver the SM imidietly.
The fact is that these messages never came to my servers, and I have incomming traffic.
dlrvalue = 1 (DELIVERED) means that the destination acknowledged the reception of the message and the modem's peer SMSC has forwarded that acknowledgment to the modem. when that DLR is sent out by kannel, you should have already received the MO on your server, if not - check your SMSC connection - apparently, your SMSC acknowledges SM reception for you but does not forward you the message.
At m-Wise we implement similar functionality, and noticed that at times we lose messages on the network even though a DELIVERED dlr has been received. this is usually due to some SMSC abstraction (we usually do not conenct directly to the network SMSCs, but to a network operator's abstraction layer) that drops messages on the floor at convinient times.
-- Oded Arbel
Do you think I can discuss with them if I provide them network message IDs of lost messages ?
Is it easy to make these IDs appear in the kannel logfiles ?
Thank you!
