RE: Extensive DLR testing with SMPP found lots of bugs

[Mauricio Ramos]

 

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;

Should be easy to fix. Simply remove entry if buffered is final state because there are no other statuses possible to follow.

[Mauricio Ramos] Well not for me because I'm not a C programmer and our Java programmers would take a long time to get the point. I'll still be pleased to find bugs and test fixes... ;-)

 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;

Not necessarily. The submission of SMS to the SMSC while not having received an ACK is a very temporary transaction. In EMI we decided to store this temporarely solution into the database, but this doesn't have to be this way. The answer is almost immediate by an ACK or NACK to the submission so if you don't ask for any other reports, it can be hold in memory related to pending transactions. It depends on the design of the driver and the DLR code of it.

[Mauricio Ramos]  I still believe this is an error simply because if I sent a sms with dlrmask=16 is because I want to be notified ONLY if the message hasn't been acknowledged by the SMSC.  Hopefully it's not a common situation...