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

fred fred at 5thfinger.com
Mon Aug 21 01:08:54 CEST 2006

Thanks for bringing this up,
we use many kannel instances, some with the same operator, and on occasion a
DLR would return
via a different bind/instance to which the MT went on...the numbers were
small in comparison so we didn't
do anything about it yet - actually don't know if its still happening, i
should check.
Anyway, this is interesting to perhaps try this ESME_RX_R_APPN for those

and YES, kannel design already handles the response incorrectly,  rather
recently this has
caused a problem
see my message  "probelm:kannel forwards MO msgs to smsbox before


----- Original Message ----- 
From: "Stipe Tolj" <st at tolj.org>
To: "Kannel Development list" <devel at kannel.org>
Sent: Sunday, August 20, 2006 10:12 AM
Subject: [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
> 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,
> refuse to accept it".
> Anyone knows what behaviour after this a SMSC is expected to have? It's
> defined directly via the spec. Will it discard the DLR, or retry, and if
> 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,
> could refuse those simply, either to force the SMSC to pick another RX
> to deliver, or to drop.
> I know that the "design" of this is already the "wrong way to do it". The
> should make sure that a RX session is always logically bound to the
> 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
> -------------------------------------------------------------------

More information about the devel mailing list