Stipe,
ok, interesting thing indeed... We need to discuss here if this is
a logical PDU flow "problem" of the SMPP SMSC, or even if we
(kannel) misbehave in terms of how threads are processing... But
(!) receiver thread inside the smsc_smpp.c module handles all PDUs
from SMSC. So, if DLR (deliver_sm or data_sm) arrive before the
submit_sm_resp, then I assume this is a logical misbehaviour of SMSC.
I had assumed that the deliver_sm would come in on the RX bind, and
the submit_sm_resp as the reply on the TX bind. Are you saying the
same thread handles both these binds? If so is it possible that the
SMSC did in fact deliver the submit_sm_resp fractionally before the
deliver_sm but the thread was processing the RX at the time (say
several deliver_sm PDUs were coming in at the same time - which given
the nature of my app happens a lot as the message flow is pretty
bursty like that) and so got to the deliver_sm before the
submit_sm_resp. However its more than possible that the SMSC could be
to blame.
hmmm... good point. I face also some connectivity issues when
connecting 2 independant SMPP client systems with the same SMPP
upstream account. Kannel receives DLRs for which it has no temp
data in DLR storage and hence "discards" the DLRs without any
meaningfull processing.
Assuming you used a database to store the DLRs and used the same one
for each system it should find them? Or by 2 independent SMPP systems
do you not mean 2 bearerbox instances connected to the same SMSC?
We may put any receiving DLRs that we can't match in teh "DLR MT"
storage table to the "DLR MO" storage table. Hence run 2 tables.
When we insert into "DLR MT" table at the point we receive
submit_sm_resp, we may check that there is no existing entry in
"DLR MO" table. If there is, then we have already received a DLR
for this MT message.
This solves 2 issues:
a) DLR MO tables holds any DLRs that can't be resolved... that
means external applications can "fetch" the DLRs from DLR MO table
to process further on.
b) "race conditioning" between submit_sm_resp with message id and
DLR itself can be hooked together, so we get the usual HTTP
callback even while SMSC sends DLRs before.
Opinions by the others for this approach?
Regards
Ben
