Re: carrier retries on SMPP bind

2014-06-09 Thread ha...@aeon.pk
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
>
>


carrier retries on SMPP bind

2014-05-26 Thread Beck, Stuart (ADE-MNT)
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