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