[RFC] SMPP: refusing DLRs that are not found in DLR storage?

Hi list,

I wonder if we should/can change logic to refuse any deliver_sm PDU containing a 
DLR information when we don't find the associated DLR temp data in our internal 
storage?

This could be done by responding with deliver_sm_resp.command_status = 
ESME_RX_R_APPN, which reads for me in the spec like "I got the message, but 
refuse to accept it".

Anyone knows what behaviour after this a SMSC is expected to have? It's not 
defined directly via the spec. Will it discard the DLR, or retry, and if yes, 
how often?

The case issue is: connecting Kannel to a SMPP account, that is already bound by 
an other SMPP client application. The other application injects MTs, but 
randomly Kannel get's DLR MOs for the MTs of the other application. Now, we 
could refuse those simply, either to force the SMSC to pick another RX session 
to deliver, or to drop.

I know that the "design" of this is already the "wrong way to do it". The client 
should make sure that a RX session is always logically bound to the application 
layer that needs the DLR processing.

But just currious if this is a simple add-on feature and what SMSC will do if we 
reject "unknown" DLRs. Comments? Experimental results please?

Stipe

-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany

tolj.org system architecture      Kannel Software Foundation (KSF)
http://www.tolj.org/              http://www.kannel.org/

mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------