> > 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...). > > we got that handling in with the 'msg-id-type' flag that can be used > for smsc groups. You have to be aware of which msg-id-type the > connected SMSC is using and configure Kannel's smsc group accordingly.
I am, but the default specified in Userguide seems not to be working... I solved this using 0x01. > > 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. > > Yep. If you could take Andreas suggestions up and take some more views > on this. This would really be great! > > We appritiate your analysis and thank you a lot for the effort! I also solved this, I was using TIMESTAMP data type for the field ts (once it means "timestamp" :-( ) and that was the main problem. In userguide it should means "SMSC message ID field". I changed to VARCHAR and everithing is ok now.
