Hi, We were running into similar issues at one time. we have multiple bearerboxes and multiple backend processing server that handle the MO's from kannel via haproxy.
The way we handle multi part messages is to move the problem to our processing engine(s) First disable message re-assembly in kannel by setting max-messages = 1 Then all messages are passed to the proxy with UDH header information intact in the get url get-url = http://127.0.0.1:10880/api/kannel/sms?s=%p&d=%P&c=%i&t=%T&m=%b&i=%I&e=%c&u=%u<http://xx.xx.xx.xx/api/kannel/sms?s=%p&d=%P&c=%i&t=%T&m=%b&i=%I&e=%c&u=%u> The proxies are individual to the bearerbox but are configured the identically on all servers. The proxy configuration then detects if there is UDH data by looking for '&u=%' (single messages will just have '&u=') If the proxy detects a UDH header then the message will be sent to a single specific server dedicated to handle multi part messages (obviously with backup servers configured so if the original server goes away there is a single replacement server to handle the UDH messages) Our processing engine then detects the multi part messages, does the re-assembly and processes the entire message. This works for us because our server are geographically close, depending on your specific SMS processing requirements this may or may not be suitable for geographically separated services I am aware that this will also catch other messages that have UDH attached, e.g. font/colour specification and other such things, this is sufficiently low volume that a single server handles our load for these requests easily. if all our traffic were to have UDH information attached we would have to re-think how we detected / processed the multi-part messages in general Stuart. On Thu, 2015-07-23 at 00:25 +0500, ha...@aeon.pk wrote: 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<mailto: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<mailto: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. > -- [cid:1438152441.30526.12.camel@mnetmobile.com] Stuart Beck Systems Administrator P +61 8 8115 6649 E stuart.b...@mnetmobile.com<mailto:stuart.b...@mnetmobile.com> A Level 1, 16 Anster Street, Adelaide SA 5000 [cid:1438152441.30526.13.camel@mnetmobile.com]
