Hi Andreas and everybody interested in SMPP DLR correctness. >> 1) Kannel is not doing multiple DLR notifications per message >> when requested >> (e.g. sendms dlrmask=31) > > Hmm. this is to be considered a BUG. only when a final state > has been reached the db entries should be removed. In a > temporary state (buffered), it should be notified and still > kept (EMI driver does this correctly).
Well, Kannel never removes db entries in ANY situation. It gets the SMSC acknolgedgment through submit_sm_resp PDU as well as gets the SME acknowledgment through deliver_sm PDU, BUT, it doesn't find the respective DLR; >> 2) Kannel is not inserting a record in mysql dlr table when >> sendsms dlrmask >> is "16" > > it might insert one but a different one. for status 1, 2, 4 > the message ID from the remote SMSC are needed. > for 8 and 16, a temporary internal ID is used as the message > ID is not being received back yet. In the EMI driver the > sequence number is used for that. Now in SMPP it might be > done different but be aware that it might not even add > anything as the answer will be back within seconds (worst > case is the timeout of the SMPP session) so the statuses > could be very well kept in memory. Well, but it's not happening. I didn't see any SMSC's message ID stored in DLR's MySQL Table. How Kannel could compare the stored DLR with the deliver_sm message-id? >> 3) Kannel is setting the mysql drl field status to "0" when >> dlrmask is "4" > > Thats an appropriate status for a message not being delivered > to the SMSC yet. > >> or "20" and also setting mysql dlr field timestamp to >> "000000000000000" > > correct. this happens when the SMS is being submitted to the > SMSC. we dont know if it has been buffered yet and we dont > have any update from the other side about the message ID. > >> 4) Dlrmasks 8,9,10,25,26 or 27 are returning dlr-status equal >> to "12" when >> should return "8" > > I've seen that as well. They should return a status 8 and > another message with status 4 instead. My guess is it should return only 8 since the above dlrmasks (8,9,10,25,26 and 27) don't contain the 4 mapped within. >> 5) In many test cases (dlrmasks 9,10,11,13,14,15,25,26, >> 27,29,30 or 31) >> Kannel says "DLR not deleted because we wait on more reports" >> but after >> receiving a correct deliver_sm (DLR) it just didn't find the >> mysql row, >> telling "no rows found" and then "got DLR but could not find >> message or was >> not interested in it" > > then the message-id mapping is wrong. it doesnt find the > message in the database. This is SMSC dependent and requires > proper configuration for really odd SMSC who once send you > message ID in hex, once in alphanumeric and once in decimal > (really stupid...). I knew this and AFAIK I'm using the correct mapping (default) since the message-id-format is hexadecimal for submit_sm_resp and decimal for deliver_sm. Anyway I'll try the other ones... >> 6) When Kannel says "removing DLR from database" the >> respective mysql row >> remains on the dlr table > > Now this is really odd. edit the dlr.c and enable a variable > to do SQL dumps so you see the SQL statements its executing. > This helps a lot to debug those things. Maybe its the same > issue as above, wrong type of message ID. Well, maybe, I'll also check those things out. >> Andreas Fink >> Fink Consulting GmbH Thanks.
