Hi Guys, I follow some Andreas' tips and found that most of my problems were due to:
1) Wrong type of MySQL dlr field 'ts'. I used TIMESTAMP type and now using VARCHAR type for correctness. It would be great to have sample dlr field data types in userguide! 2) Not in accordance with the userguide, the default msg-id-type IS NOT 1. I still doesn't know what is the default for msg-id-type BUT setting this to 1 solved the problem. Another thing to fix in userguide! These two misconfigurations above were enough to make a big mess. The only things that last were: 1) The use of DLRMASK equal to 4 or 20 inserts a DLR that potentially will remain in database forever. Although this is an error, it can be avoided; 2) The use of DLRMASK equal to 16 never inserts a DLR in databas. Comparing with previous situation, this maybe considered an error, it can be avoided too; Thanks to Andrea, hope I didn't confuse anybody and also hope this experience will further helps somebody. Mauricio > -----Original Message----- > From: Mauricio Ramos [mailto:[EMAIL PROTECTED]] > Sent: segunda-feira, 13 de janeiro de 2003 11:42 > To: 'Andreas Fink'; [EMAIL PROTECTED] > Subject: RE: Extensive DLR testing with SMPP found lots of bugs > > > 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. >
