Hi, @Joe: Technically, SMS splitting over SS7 like you are describing is not possible. If it is indeed the case, your Telco operator has configured his SMSC cluster in a very dumb and stupid way. Apart from A2P/P2A messages, this should also cause a havoc on P2P messaging as well. I wonder if they know what is going on.
I had an issue with single SMSC, in which I was not getting the DLR of my messages, while operator was insisting that he is sending them. After taking traces and all, it turned out that I had 4 sessions of same ESME bind with SMSC, which were named as separate SMSCs on my end. The DLRs were coming back alright, but when the return path (i.e. SMSC channel) was different, kannel was ignoring and discarding them. As a solution, I asked them to define all binds as new ESME (instead of multiple instances of a single account) on their side. This solved the issue. Regards, Hamza On Thu, Jul 16, 2015 at 10:55 PM, Mick Burns <bmx1...@gmail.com> wrote: > 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. > > > >
