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.