I have been running kannel for a month or so and its been great.
I looked at the outstanding DLRs the earlier today and say a few, and identified some as phones that I know people are not using any more, hence no delivery. Thats fine, but then I noticed my number was in the outstanding DLRs, and after a bit of investigation I knew it was a message that I had received.
Looking at the debug from the smsc logs (Im using SMPP, with postgresql as the DLR storage BTW) I see that what has been happening is that the DLR is actually coming in a fraction faster that the submit_sm_resp with the message ID in it. (Or at least the receiver thread is before the transmitter thread).
This means the DLR is being ignored as its not in the table, then its gets created and put in the table immediately after. So its then outstanding, and of course the DLR callback is never run.
I wonder if a) anybody else has come across this, or b) you can think of any good ways to make sure the DLRs are not lost. e.g. maybe we store them, and then when we create them we can see the status has already been updated and trigger the callback?
I suspect its because I am connected directly to an operator as opposed to an aggregator that I am having this occasional (about 30 messages in 600 over 7 days approx) issue.
I should also say that I set-up and did the operator integration testing with 1.4.0 as 1.4.1 was not out at the time (came out a couple of weeks after), so my live service is currently running 1.4.0. I will upgrade, but first need to be sure of the effects of the upgrade, as obviously having been thought the integration testing I need to be careful about using a different version thats does something unexpected to the connection (in which case I would be in danger of loosing the operator connection).
So if you think this issue is only with 1.4.0 then no problem, but I could not see anything in any of the release notes that suggest this has been identified before.
Regards Ben
