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

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

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

Cheers
Fred




----- Original Message ----- 
From: "Stipe Tolj" <[email protected]>
To: "Kannel Development list" <[email protected]>
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
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
> -------------------------------------------------------------------
>
>