You need to tweak your window size, on your side as well as operator side.
This parameter controls the ACK of the messages exchanged between SMSC and
your kannel client.


On Mon, May 26, 2014 at 9:29 PM, Beck, Stuart (ADE-MNT) <
stuart.b...@mnetmobile.com> wrote:

>  Hi All,
>
> I've recently encountered a problem with our SMPP binds to one of our
> carriers That I'm wondering if anyone can help me with.
>
> during a period of higher than usual requests to one of our services we
> started getting reports that multiple MT's were being received at the
> handsets.  During the investigation it was determined that the carrier was
> sending multiple MO requests to us in the belief that we had not received
> the original requests.
>
> Further:
>
>    - The carrier was expecting submit_sm_resp messages back from
>    submit_sm requests within (carrier defined) 13 seconds.  The carrier will
>    not be adjusting this timeout.
>    - Our Kannel gateway was sending the submit_sm_resp messages but not
>    necessarily within the 13 second carrier specified timeout, at which point
>    the carrier retries the request.
>    - more legitimate MO's combining with the retried MO's being delayed
>    just caused the problem to snowball.
>
>
> As part of the process to avoid this in future, I have upgraded Kannel,
> and installed it on a faster box. Now however It is reported that the
> problem is here again.
>
> The new server is running kannel trunk from SVN as of May 8, running on
> Solaris 11.1 with a few modifications to allow it to build.
> Our carrier configuration is as follows: we have 3 binds with the
> following configuration
>
> group = smsc
> smsc = smpp
> smsc-id = smscgroup
> host = aa.bb.cc.dd
> #port = 2775 # disabled, this is a receive bind only
> receive-port = 2775
> transceiver-mode = false
> interface-version = 34
> smsc-username = XXX
> smsc-password = XXX
> system-type = smpp
> address-range = 0
> source-addr-ton = 0
> source-addr-npi = 4
> dest-addr-ton = 1
> dest-addr-npi = 1
> alt-charset="ASCII"
> enquire-link-interval = 30
> allowed-smsc-id = "smscgroup"
> msg-id-type = 0x01
> log-file = /data/kannel/log/bearer-smscgroupX.log
> log-level = 1
> reconnect-delay = 170
>
> I have tried googling around to see if there is anything I might want to
> have a look at but have not had much success.
> max-pending-submits, wait-ack, wait-ack-expire - all seem to operate on
> outbound MTs so I am unsure where to go from here.
>
> I will be enabling debug logging when I am back in the office, however I
> like to find out if anyone else has had any experience of this behavior.
> Any suggestions as to anything I could do to force our gateway to present
> the submit_sm_resp messages within the required timeframe or things I could
> do to help my configuration in general
>
> Stuart.
> ----------
> Stuart Beck
>
>

Reply via email to