_sm_respsuccess"
Cheers
Fred
- Original Message -
From: "Stipe Tolj" <[EMAIL PROTECTED]>
To: "Kannel Development list"
Sent: Sunday, August 20, 2006 10:12 AM
Subject: [RFC] SMPP: refusing DLRs that are not found in DLR storage?
> Hi list,
>
&g
st
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
On 20.08.2006, at 16:31, Stipe Tolj wrote:Andreas Fink wrote: 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. ok, that's the "default" behaviour, round-robin or random transmission of DLR
Andreas Fink wrote:
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.
ok, that's the "default" behaviour, round-robin or random transmission of DLRs
to any RX session bound for the s
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
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
