Re: Interesting issue with DLRs

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