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