RE: Extensive DLR testing with SMPP found lots of bugs

 

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