Just to clarify - to avoid a misunderstanding about the case you try to describe: I assume that your (@ hamza at aeon.pk) investigation was about (missing) "Delivery Reports" but you also noticed that the ACK of a "submit_sm" PDU (submit_sm-resp) was coming over a smpp/tcp session, which was different from the session used for the transmission of the "submit_sm"; and probably this is - also - not what Kannel expects and that's why it discards it.
Based on my experience, in the case e.g. of a COMVERSE SMSC a "submit_sm" and the corresponding "submit_sm-resp" must arrive over the same "SMPP" bind always, while "SMSC" transmits DLRs in a load sharing fashion over all existing smpp/tcp sessions. > > I recently had a painful time with a client figuring out the missing DLRs. > SMSC trace showed that DLR was sent back, but nothing used to appear in my > logs. I pinned it down to the problem of multiple sessions with same ESME. > The submit_rsm_resp DOES NOT ALWAYS come back from the same channel. When > it doesn't, it does not appear in the logs (although kannel does receive it > but discards it due to mismatch). I figured this out after taking multiple > tcpdump traces. > > On Wed, Feb 4, 2015 at 2:43 PM, Aristotelis Metsinis < > aristotelis.metsinis at gmail.com> wrote: > >> Let us assume that an ESME has established 10 trx (or tx) binds (tcp >> connections/sessions) and submits a "submit_sm" PDU over one of those 10 >> binds. >> >> Can we assume that the corresponding "submit_sm-resp" PDU "arrives" over >> the same trx (tx) bind; that is over the same tcp stream >> (connection/session) ? >> >> I believe that this is correct. For example, an ESME may "reuse" sequence >> numbers across all binds. That is, ESME may submit a "submit_sm" PDU over >> bind-1 with sequence number "123". In "parallel", this ESME may also submit >> another "submit_sm" over bind-2 with the same sequence number "123". So, if >> we assume that "submit_sm-resp" does not "arrive" over the same bind - >> stream, then there is no way to correlate request /response. So, the >> response must "arrive" over the same bind (tcp session/connection). A "DLR" >> may of course "arrive" over any of the established sessions - the same or a >> different one. >>
