Hello Joe and Kannel community: I am facing the same issue as you described. Wondering if you have found a solution to your problem as I don't see a follow-up from you on this. Similarly to you and for obvious redundancy reasons, I have two separate bearerbox and the upstream has multiple SMSC and will sometimes deliver concatenated messages over different SMPP binds and therefore messages ends-up split in between my two servers, preventing the re-assembly and timely delivery of messages.
One idea would be to cluster the bearerbox together by having a shared database table where they could write each parts of a multi-part message. The bearerbox instance in the cluster which receives the last part (will determine this from the UDH) is responsible for concatenating the message to its original form and proceed to hand-off and finally update the database entry status. It would require switching a global bearerbox setting for concatenated message processing. Either *standalone which is current behavior to wait for all parts or *clustered where is would implement the database storage. I'd like to hear feedback from the community about this idea. tnx On Wed, Jan 14, 2015 at 7:40 AM, Joe Power <joe.po...@puca.com> wrote: > Hi folks, > I have inherited a working Kannel platform with binds into multiple > operators. I don't have much experience in configuring Kannel, but have seen > what works on the existing platform. I have discovered an issue we have with > multi-part messages from one of the operators we are connected to. The > operator has 2 SMSCs with a shared SS7 stack (so they are effectively > clustered as I understand it). As MO messages can come into either SMSC we > have a separate bind into each one. However, when a multi-part MO message > comes in, the individual parts can be handled by either SMSC. If a one part > comes into one SMSC and is sent over its bind and the other part comes into > the other SMSC and is sent over its bind then Kannel, as it is currently > configured, won't match the two parts and concatenate them. What is > currently happening is that Kannel is waiting for the other part(s) sent > over the other bind and eventually times out and sends what it has. My > questions are as follows: - > > 1> Is it possible to configure Kannel to treat both binds as connected to > the one "organisation" and concatenate multi-part messages regardless of > which of the two binds the parts come in on ? > > 2> If the above isn't possible, are there any other options to resolve the > issue ? > > 3> What would the config file for such a configuration look like ? > > Any help appreciated. > > Regards, > Joe. >
