On 20.08.2006, at 02:12, Stipe Tolj wrote: 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?
I would expect the SMSC to retry all the time. This might lock up our connection. 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.
If this happens, then you have two SMPP client connections with the same short ID which is nonsense because the other application will also receive delivery notification of messages kannel is sending. This for sure NOT a good idea.
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?
Would be very implementation specific. on our SMSC it would simply keep the message in the queue and retry with a 50% luck to end up on the "other" session.
Andreas Fink Fink Consulting GmbH --------------------------------------------------------------- Tel: +41-61-6666332 Fax: +41-61-6666331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland --------------------------------------------------------------- ICQ: 8239353 Yahoo: finkconsulting SMS: +41792457333
|
