RE: Extensive DLR testing with SMPP found lots of bugs

> >      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.