I think this is an SMSC related issue. Probably you will get different results based on different SMSC's. Especially if it is not mentioned in any specs.
You are right about this being a client-side issue. I know for once that -in my platforms- I have a single receive process that receives incoming messages from all connected threads. So in short: I don't think we will actually solve an issue if we start doing things this way. Rene Kluwen Chimit -----Original Message----- From: Stipe Tolj [mailto:[EMAIL PROTECTED] Sent: zondag 20 augustus 2006 2:13 To: Kannel Development list 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 -------------------------------------------------------------------
