Which distribution is best to run Kannel (sql)box

[Grant Saicom]

Hi Everyone

I am looking for an opinion (good natured discussion please) on which 
distribution is best to run a lean purpose built kannel system for smpp sms 
delivery and replies using sqlbox.

DB is mysql and the DB is running on a separate VM on the same hypervisor with 
SSD drives.

We are currently running debian wheezy 7.8 installed using net install so it 
was as minimal as possible. We are seeing quite a bit of tcp retransmission 
going on between the system and the smsc.

Can anyone advise from their own experience?

Kind regards
Grant

Re: SQLBOX queued messages question

[Grant Saicom]

I suspect the issue I am still experiencing is because of TCP retransmission 
between Kannel and SMSC. The time out for ack is 210ms on the SMSC we are 
sending to and the delay can sometimes be as long as 370ms.

I have not found a solution, but am exploring further optimisations and avenues.

Another Kannel user advised me saying that openSMPP can be problematic some 
times. Is this a generally known and confirmed issue?

Kind regards
Grant
> On 15 Dec 2015, at 12:53, spameden  wrote:
> 
> store-type = spool
> store-location = "/tmp/kannel-spool/"
> 
> put these 2 lines below group = core in /etc/kannel/kannel.conf
> 
> do you use for dlr MySQL as well?
> 
> worth adding index on dlr table as well: KEY `smsc_ts` (`smsc`,`ts`) 
> 
> ALTER table dlr add index `smsc_ts` (`smsc`,`ts`);
> 
> 
> 
> 
> 2015-12-15 13:43 GMT+03:00 spameden  >:
> Yes.
> 
> The only thing that comes to my mind is to use kannel-store = spool and move 
> your spool store to /tmp dir, this way queue will be in multiple files 
> instead of the single file and in RAM, I found this way it's very fast.
> 
> Let me know if it helps.
> 
> If you want to preserve queue (in case of hard reset or something) you can 
> rsync it's contents every 2 minutes or so in some permanent directory.
> 
> 2015-12-15 12:56 GMT+03:00 Grant Saicom  >:
> Haven’t really found my answer yet, but I have another question along this 
> line of thought.
> 
> I see the queue in sqlbox rises quite high, but the queue in the smpp 
> connector to the smsc barely goes above 0.
> 
> Is there a way to control.modify the flow of messages from sqlbox to the smpp 
> queue?
> 
> Architecturally, is this correct in terms of the flow of messages:
> sqlbox queue -> bearerbox sms store-> smpp queue
> 
> Regards
> Grant
> 
>> On 09 Dec 2015, at 11:56, spameden > > wrote:
>> 
>> 
>> 
>> 2015-12-09 12:43 GMT+03:00 Grant Saicom > >:
>> We process the sent_sms into another table on they fly. Maximum size the 
>> sent_sms table gets is maybe 40k tops but mostly it averages around 10K. We 
>> see this once 1 week maybe.
>> 
>> I have really made every attempt to remove any bottlenecks in terms unwieldy 
>> database sizes to allow kannel to work in a favourable environment.
>> 
>> Is there reason to add multiple sqlboxes to feed bearer box?
>> 
>> Is there maybe a concurrency setting I can do for bearer box to receive the 
>> messages? I did not come across documentation aside from email posts with 
>> respect to the limit-per-cycle setting.
>> 
>> I have another question, would we be able to get faster performance if we 
>> went flat file for the kannel operations?
>> 
>> Well you can exclude bottlenecks by simply testing same setup with fakesmsc 
>> daemon and see if speed will be better.
>> 
>> It might be that delay is caused by your SMSC uplinks overall speed and not 
>> database.
>> 
>> You can also try classic smsbox implementation for sending instead of 
>> sqlbox. But I think sqlbox is fastest and more convinient way because of DB 
>> storage.
>> 
>> 
>>  
>> 
>> Regards
>> 
>> 
>>> On 08 Dec 2015, at 15:12, spameden >> > wrote:
>>> 
>>> 
>>> 
>>> 2015-12-08 12:51 GMT+03:00 Grant Vorenberg >> >:
>>>  
>>> 
>>> 
>>> Hi
>>> 
>>> We manage how big send_sms gets. The queue builder puts in 500 messages at 
>>> a time to a total maximum of 3000 from a larger main queue which can go as 
>>> big as 2M.
>>> 
>>> 2M is kinda big table, how big is sent_sms? 10-30M ?
>>> 
>>> I think your issue happens when kannel tries to move from send_sms to 
>>> sent_sms table already submitted message this is where it hangs. You can 
>>> try testing it yourself with simple query:
>>> 
>>> INSERT INTO sent_sms SELECT * from send_sms where sql_id= and measure 
>>> time per query.
>>> 
>>> if it's instant there should be no problem.
>>> 
>>> Generally it's better to leave sent_sms table at around 1M records not 
>>> more, old records you can move to other table daily.
>>>  
>>> 
>>> Actual hardware is a VCenter on blades with plenty ram, cpu and hp 
>>> 3PAR(144GB raid card ram for caching in total) fibre attached storage with 
>>> dedicated SSD specifically for DB. Calculated IOPS are stupidly good.
>>> 
>>> The VMs are as follows:
>>> Queuebuilder: 4 vcpu, 16Gb on SAS
>>> Kannel: 4 vcpu, 8GB on SAS
>>> MysqlDB-Master: 8 vcpu, 32GB on SSD
>>> MysqlDB-Slave: 8 vcpu, 32GB on SSD
>>> 
>>> MySQL on SSDs should work just fine and you should have big number of iops. 
>>> Btw, I recommend to use MariaDB instead of regular MySQL (mariadb.org 
>>> ) it's very fast and reliable, for InnoDB it uses 
>>> 

Re: Which distribution is best to run Kannel (sql)box

[Alberto Mijares]

Running kannel on FreeBSD since the beginning of times ;-)

This is your best bet.

Regards,


Alberto Mijares



On Wed, Jan 13, 2016 at 6:33 AM, Grant Saicom  wrote:
> Hi Everyone
>
> I am looking for an opinion (good natured discussion please) on which 
> distribution is best to run a lean purpose built kannel system for smpp sms 
> delivery and replies using sqlbox.
>
> DB is mysql and the DB is running on a separate VM on the same hypervisor 
> with SSD drives.
>
> We are currently running debian wheezy 7.8 installed using net install so it 
> was as minimal as possible. We are seeing quite a bit of tcp retransmission 
> going on between the system and the smsc.
>
> Can anyone advise from their own experience?
>
> Kind regards
> Grant

Re: SQLBOX queued messages question

[spameden]

2016-01-13 15:14 GMT+03:00 Grant Saicom :

> Thanks for the advice.
>
> Which smpp implementation does kannel code ship with from the repo? Just
> want to clarify as it sounds it isn’t opensmpp in the answer.
>

Why do you even ask about opensmppbox? I thought original question was
about sqlbox. OpenSMPPBox is basically a simple proxy to kannel for outside
clients. There is not much in it, there is no flow control or accounting.
What bearerbox/kannel implements for smsc is basically what opensmppbox
offers in terms of connections to upstream links.



> With regards to network, all the machines are on the same subnet,
> including the smsc. We have an instance within our network. On top of that,
> they are all on the same hypervisor and data fabric.
>

Another thought I just got: could your network problems be due your
virtualization used? Try using kannel on a bare machine and see if there is
any TCP retransmissions going?

Did you check mtr output as well to your upstream smsc? And also check
reverse network path if it's same or not.




>
> On 13 Jan 2016, at 14:02, spameden  wrote:
>
> opensmppbox is generally not recommended for production, it's very basic
> and there is no accounting at all, for SMPP-server I'd recommended
> contacting Stipe Tolk (you can find his e-mail on the lists archive in
> google), he has commercial solution carrier-grade.
>
> about TCP retransmissions you might need tuning either Linux network
> settings, e.g. MTU if you're behind some sorta NAT or better contact your
> provider with mtr output and tcpdump captures there might be unoptimal
> direct or/and reverse network path between you and your SMSC provider.
>
> 2016-01-13 14:07 GMT+03:00 Grant Saicom :
>
>> I suspect the issue I am still experiencing is because of TCP
>> retransmission between Kannel and SMSC. The time out for ack is 210ms on
>> the SMSC we are sending to and the delay can sometimes be as long as 370ms.
>>
>> I have not found a solution, but am exploring further optimisations and
>> avenues.
>>
>> Another Kannel user advised me saying that openSMPP can be problematic
>> some times. Is this a generally known and confirmed issue?
>>
>> Kind regards
>> Grant
>>
>> On 15 Dec 2015, at 12:53, spameden  wrote:
>>
>> store-type = spool
>> store-location = "/tmp/kannel-spool/"
>>
>> put these 2 lines below group = core in /etc/kannel/kannel.conf
>>
>> do you use for dlr MySQL as well?
>>
>> worth adding index on dlr table as well: KEY `smsc_ts` (`smsc`,`ts`)
>>
>> ALTER table dlr add index `smsc_ts` (`smsc`,`ts`);
>>
>>
>>
>>
>> 2015-12-15 13:43 GMT+03:00 spameden :
>>
>>> Yes.
>>>
>>> The only thing that comes to my mind is to use kannel-store = spool and
>>> move your spool store to /tmp dir, this way queue will be in multiple files
>>> instead of the single file and in RAM, I found this way it's very fast.
>>>
>>> Let me know if it helps.
>>>
>>> If you want to preserve queue (in case of hard reset or something) you
>>> can rsync it's contents every 2 minutes or so in some permanent directory.
>>>
>>> 2015-12-15 12:56 GMT+03:00 Grant Saicom :
>>>
 Haven’t really found my answer yet, but I have another question along
 this line of thought.

 I see the queue in sqlbox rises quite high, but the queue in the smpp
 connector to the smsc barely goes above 0.

 Is there a way to control.modify the flow of messages from sqlbox to
 the smpp queue?

 Architecturally, is this correct in terms of the flow of messages:
 sqlbox queue -> bearerbox sms store-> smpp queue

 Regards
 Grant

 On 09 Dec 2015, at 11:56, spameden  wrote:



 2015-12-09 12:43 GMT+03:00 Grant Saicom :

> We process the sent_sms into another table on they fly. Maximum size
> the sent_sms table gets is maybe 40k tops but mostly it averages around
> 10K. We see this once 1 week maybe.
>
> I have really made every attempt to remove any bottlenecks in terms
> unwieldy database sizes to allow kannel to work in a favourable 
> environment.
>
> Is there reason to add multiple sqlboxes to feed bearer box?
>
> Is there maybe a concurrency setting I can do for bearer box to
> receive the messages? I did not come across documentation aside from email
> posts with respect to the limit-per-cycle setting.
>
> I have another question, would we be able to get faster performance if
> we went flat file for the kannel operations?
>

 Well you can exclude bottlenecks by simply testing same setup with
 fakesmsc daemon and see if speed will be better.

 It might be that delay is caused by your SMSC uplinks overall speed and
 not database.

 You can also try classic smsbox implementation for sending instead of
 

Re: Which distribution is best to run Kannel (sql)box

[spameden]

You need to use distro you know and which suits you best.

I've been using Debian in combination with kannel for quite some time
(about 5 years) and never had any problems.

Currently I'm running kannel as well on top of Debian Wheezy it works just
fine.

If you are having troubles with kannel's performance. You need to read
mailing lists a bit. Main bottlenecks were discussed many times, in most
cases it's not kannel's issue.

Instead of general MySQL I'd recommend using MariaDB 5.5 (mariadb.org). It
uses XtraDB for InnoDB engine and is very well maintained. There is debian
repo for it as well.

Combination of max-pending-submits  / throughput should be set accordingly
to your smsc upstream provider. Basically max-pending-submits means a
number of outstanding operations between you and smsc upstream. If you
don't have any errors like throttling or queue full in your smsc log
current values should be fine.

2016-01-13 15:01 GMT+03:00 Otandeka Simon Peter :

> Hi,
>
> Try setting the sms-resend-freq and sms-resend-retry to reduce on the
> number of sms retries. Also set a low figure on the max-pending-submits to
> reduce on your queue. This might help.
>
> But also check on your conxn plus you could be sending to
> non-existent/wrongly formatted numbers, the smsc rejects and your system
> keeps trying to re-send them.
>
> If the issue occurs at a certain period all the time, check with your smsc
> vendor. Sometimes they have queue/throttling problems.
>
> My 2 cents.
>
> @sotandeka
>
>
> On Wed, Jan 13, 2016 at 2:43 PM, Grant Saicom 
> wrote:
>
>> Example log below of one very common warning. I cannot see anything about
>> tcp retransmission in the logs. We see it in tshark when things start going
>> a bit out of sorts.
>>
>> PDU has been sanitised for privacy, so the destination and text has been
>> removed.
>>
>> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP[internal]: Sending PDU:
>> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP PDU 0x1c5bfa0 dump:
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   type_name: submit_sm
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   command_id: 4 = 0x0004
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   command_status: 0 = 0x
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   sequence_number: 6541387 =
>> 0x0063d04b
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   service_type: "P_289361630"
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr_ton: 2 = 0x0002
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr_npi: 1 = 0x0001
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr: "435719276"
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   dest_addr_ton: 2 = 0x0002
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   dest_addr_npi: 1 = 0x0001
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   destination_addr: ""
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   esm_class: 3 = 0x0003
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   protocol_id: 0 = 0x
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   priority_flag: 0 = 0x
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   schedule_delivery_time: NULL
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   validity_period: NULL
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   registered_delivery: 1 =
>> 0x0001
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   replace_if_present_flag: 0 =
>> 0x
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   data_coding: 0 = 0x
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   sm_default_msg_id: 0 = 0x
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   sm_length: 91 = 0x005b
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   short_message:
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:Octet string at 0x1cf1070:
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:  len:  91
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:  size: 92
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:  immutable: 0
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 59
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 48
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 4
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data:
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 49 53
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 4c 5
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:Octet string dump ends.
>> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP PDU dump ends.
>> 2016-01-13 11:00:00 [4771] [7] WARNING: SMPP: PDU element 
>> too long (length is 11, should be 5)
>> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP[internal]: throughput
>> (12.00,0.00)
>> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP[internal]: Sending PDU:
>> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP PDU 0x1d5d380 dump:
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   type_name: submit_sm
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   command_id: 4 = 0x0004
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   command_status: 0 = 0x
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   sequence_number: 6541388 =
>> 0x0063d04c
>> 2016-01-13 11:00:00 [4771] [7] DEBUG:   service_type: "P_289340514"
>> 

Re: Which distribution is best to run Kannel (sql)box

[Grant Saicom]

Example log below of one very common warning. I cannot see anything about tcp 
retransmission in the logs. We see it in tshark when things start going a bit 
out of sorts.

PDU has been sanitised for privacy, so the destination and text has been 
removed.

2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP[internal]: Sending PDU:
2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP PDU 0x1c5bfa0 dump:
2016-01-13 11:00:00 [4771] [7] DEBUG:   type_name: submit_sm
2016-01-13 11:00:00 [4771] [7] DEBUG:   command_id: 4 = 0x0004
2016-01-13 11:00:00 [4771] [7] DEBUG:   command_status: 0 = 0x
2016-01-13 11:00:00 [4771] [7] DEBUG:   sequence_number: 6541387 = 0x0063d04b
2016-01-13 11:00:00 [4771] [7] DEBUG:   service_type: "P_289361630"
2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr_ton: 2 = 0x0002
2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr_npi: 1 = 0x0001
2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr: "435719276"
2016-01-13 11:00:00 [4771] [7] DEBUG:   dest_addr_ton: 2 = 0x0002
2016-01-13 11:00:00 [4771] [7] DEBUG:   dest_addr_npi: 1 = 0x0001
2016-01-13 11:00:00 [4771] [7] DEBUG:   destination_addr: ""
2016-01-13 11:00:00 [4771] [7] DEBUG:   esm_class: 3 = 0x0003
2016-01-13 11:00:00 [4771] [7] DEBUG:   protocol_id: 0 = 0x
2016-01-13 11:00:00 [4771] [7] DEBUG:   priority_flag: 0 = 0x
2016-01-13 11:00:00 [4771] [7] DEBUG:   schedule_delivery_time: NULL
2016-01-13 11:00:00 [4771] [7] DEBUG:   validity_period: NULL
2016-01-13 11:00:00 [4771] [7] DEBUG:   registered_delivery: 1 = 0x0001
2016-01-13 11:00:00 [4771] [7] DEBUG:   replace_if_present_flag: 0 = 0x
2016-01-13 11:00:00 [4771] [7] DEBUG:   data_coding: 0 = 0x
2016-01-13 11:00:00 [4771] [7] DEBUG:   sm_default_msg_id: 0 = 0x
2016-01-13 11:00:00 [4771] [7] DEBUG:   sm_length: 91 = 0x005b
2016-01-13 11:00:00 [4771] [7] DEBUG:   short_message:
2016-01-13 11:00:00 [4771] [7] DEBUG:Octet string at 0x1cf1070:
2016-01-13 11:00:00 [4771] [7] DEBUG:  len:  91
2016-01-13 11:00:00 [4771] [7] DEBUG:  size: 92
2016-01-13 11:00:00 [4771] [7] DEBUG:  immutable: 0
2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 59
2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 48 
2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 4
2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 
2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 49 53
2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 4c 5   
2016-01-13 11:00:00 [4771] [7] DEBUG:Octet string dump ends.
2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP PDU dump ends.
2016-01-13 11:00:00 [4771] [7] WARNING: SMPP: PDU element  too 
long (length is 11, should be 5)
2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP[internal]: throughput (12.00,0.00)
2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP[internal]: Sending PDU:
2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP PDU 0x1d5d380 dump:
2016-01-13 11:00:00 [4771] [7] DEBUG:   type_name: submit_sm
2016-01-13 11:00:00 [4771] [7] DEBUG:   command_id: 4 = 0x0004
2016-01-13 11:00:00 [4771] [7] DEBUG:   command_status: 0 = 0x
2016-01-13 11:00:00 [4771] [7] DEBUG:   sequence_number: 6541388 = 0x0063d04c
2016-01-13 11:00:00 [4771] [7] DEBUG:   service_type: "P_289340514"
2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr_ton: 2 = 0x0002
2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr_npi: 1 = 0x0001
> On 13 Jan 2016, at 13:34, Grant Saicom  wrote:
> 
> Hi
> 
> Thank you for your reply. See my config below. Logs are pretty massive, so I 
> am going to try find an example and send through as well.
> 
> 
> Kannel Conf==
> group = core
> admin-port = 13000
> smsbox-port = 13001
> admin-password = 
> log-file = "/var/log/kannel/kannel-bearerbox.log"
> log-level = 0
> box-deny-ip = "*.*.*.*"
> box-allow-ip = "127.0.0.1"
> dlr-storage = mysql
> store-location = "/var/spool/kannel"
> smsbox-max-pending = 600
> 
> #IQSIM Orphan SMPP Connector
> group=smsc
> smsc=smpp
> smsc-id=internal
> interface-version=34
> host=##
> receive-port=2775
> system-id=sms2
> smsc-username=
> smsc-password=
> system-type=default
> #max-pending-submits=70
> #validityperiod=20160
> 
> #IQSIM Sending SMPP Connector
> group=smsc
> smsc=smpp
> smsc-id=internal
> interface-version=34
> host=
> port=2775
> system-id=sms1
> smsc-username=###
> smsc-password=###
> system-type=default
> max-pending-submits = 410
> #validityperiod=20160
> transceiver-mode=1
> denied-smsc-id=###
> 
> group = smsbox
> bearerbox-host = 127.0.0.1
> sendsms-port = 13013
> global-sender = 13013
> smsbox-id=my_smsbox
> 
> #Routing for standard Kannel messages i.e. no smsc_id
> group=smsbox-route
> smsbox-id=sqlbox
> smsc-id=internal
> 
> 
> #
> #SEND-SMS USERS
> #
> 
> group = sendsms-user
> default-smsc = 

Re: Which distribution is best to run Kannel (sql)box

[Grant Saicom]

Hi

Thank you for your reply. See my config below. Logs are pretty massive, so I am 
going to try find an example and send through as well.


Kannel Conf==
group = core
admin-port = 13000
smsbox-port = 13001
admin-password = 
log-file = "/var/log/kannel/kannel-bearerbox.log"
log-level = 0
box-deny-ip = "*.*.*.*"
box-allow-ip = "127.0.0.1"
dlr-storage = mysql
store-location = "/var/spool/kannel"
smsbox-max-pending = 600

#IQSIM Orphan SMPP Connector
group=smsc
smsc=smpp
smsc-id=internal
interface-version=34
host=##
receive-port=2775
system-id=sms2
smsc-username=
smsc-password=
system-type=default
#max-pending-submits=70
#validityperiod=20160

#IQSIM Sending SMPP Connector
group=smsc
smsc=smpp
smsc-id=internal
interface-version=34
host=
port=2775
system-id=sms1
smsc-username=###
smsc-password=###
system-type=default
max-pending-submits = 410
#validityperiod=20160
transceiver-mode=1
denied-smsc-id=###

group = smsbox
bearerbox-host = 127.0.0.1
sendsms-port = 13013
global-sender = 13013
smsbox-id=my_smsbox

#Routing for standard Kannel messages i.e. no smsc_id
group=smsbox-route
smsbox-id=sqlbox
smsc-id=internal


#
#SEND-SMS USERS
#

group = sendsms-user
default-smsc = default
username = playsms1
password = playsms1
concatenation = true
max-messages = 3

group = mysql-connection
id = mydlr
host = 154.72.8.195
username = root
password = at0m1c55
database = kannel
#max-connections = 20

group = dlr-db
id = mydlr

> On 13 Jan 2016, at 13:20, Otandeka Simon Peter  wrote:
> 
> 
> Hi,
> 
> I have used a couple of distros (centos, freebsd ubuntu, wheezy, openSuSE) 
> and they all work well without issues.  It's how you configure your system 
> (resources) that matters a lot i.e. apache, kannel, memory etc.
> 
> You may want to share some bearerbox logs and config so that we can advise on 
> the retransmission bit.  
> 
> @sotandeka
> 
> On Wed, Jan 13, 2016 at 2:03 PM, Grant Saicom  > wrote:
> Hi Everyone
> 
> I am looking for an opinion (good natured discussion please) on which 
> distribution is best to run a lean purpose built kannel system for smpp sms 
> delivery and replies using sqlbox.
> 
> DB is mysql and the DB is running on a separate VM on the same hypervisor 
> with SSD drives.
> 
> We are currently running debian wheezy 7.8 installed using net install so it 
> was as minimal as possible. We are seeing quite a bit of tcp retransmission 
> going on between the system and the smsc.
> 
> Can anyone advise from their own experience?
> 
> Kind regards
> Grant
> 

Re: SQLBOX queued messages question

[spameden]

opensmppbox is generally not recommended for production, it's very basic
and there is no accounting at all, for SMPP-server I'd recommended
contacting Stipe Tolk (you can find his e-mail on the lists archive in
google), he has commercial solution carrier-grade.

about TCP retransmissions you might need tuning either Linux network
settings, e.g. MTU if you're behind some sorta NAT or better contact your
provider with mtr output and tcpdump captures there might be unoptimal
direct or/and reverse network path between you and your SMSC provider.

2016-01-13 14:07 GMT+03:00 Grant Saicom :

> I suspect the issue I am still experiencing is because of TCP
> retransmission between Kannel and SMSC. The time out for ack is 210ms on
> the SMSC we are sending to and the delay can sometimes be as long as 370ms.
>
> I have not found a solution, but am exploring further optimisations and
> avenues.
>
> Another Kannel user advised me saying that openSMPP can be problematic
> some times. Is this a generally known and confirmed issue?
>
> Kind regards
> Grant
>
> On 15 Dec 2015, at 12:53, spameden  wrote:
>
> store-type = spool
> store-location = "/tmp/kannel-spool/"
>
> put these 2 lines below group = core in /etc/kannel/kannel.conf
>
> do you use for dlr MySQL as well?
>
> worth adding index on dlr table as well: KEY `smsc_ts` (`smsc`,`ts`)
>
> ALTER table dlr add index `smsc_ts` (`smsc`,`ts`);
>
>
>
>
> 2015-12-15 13:43 GMT+03:00 spameden :
>
>> Yes.
>>
>> The only thing that comes to my mind is to use kannel-store = spool and
>> move your spool store to /tmp dir, this way queue will be in multiple files
>> instead of the single file and in RAM, I found this way it's very fast.
>>
>> Let me know if it helps.
>>
>> If you want to preserve queue (in case of hard reset or something) you
>> can rsync it's contents every 2 minutes or so in some permanent directory.
>>
>> 2015-12-15 12:56 GMT+03:00 Grant Saicom :
>>
>>> Haven’t really found my answer yet, but I have another question along
>>> this line of thought.
>>>
>>> I see the queue in sqlbox rises quite high, but the queue in the smpp
>>> connector to the smsc barely goes above 0.
>>>
>>> Is there a way to control.modify the flow of messages from sqlbox to the
>>> smpp queue?
>>>
>>> Architecturally, is this correct in terms of the flow of messages:
>>> sqlbox queue -> bearerbox sms store-> smpp queue
>>>
>>> Regards
>>> Grant
>>>
>>> On 09 Dec 2015, at 11:56, spameden  wrote:
>>>
>>>
>>>
>>> 2015-12-09 12:43 GMT+03:00 Grant Saicom :
>>>
 We process the sent_sms into another table on they fly. Maximum size
 the sent_sms table gets is maybe 40k tops but mostly it averages around
 10K. We see this once 1 week maybe.

 I have really made every attempt to remove any bottlenecks in terms
 unwieldy database sizes to allow kannel to work in a favourable 
 environment.

 Is there reason to add multiple sqlboxes to feed bearer box?

 Is there maybe a concurrency setting I can do for bearer box to receive
 the messages? I did not come across documentation aside from email posts
 with respect to the limit-per-cycle setting.

 I have another question, would we be able to get faster performance if
 we went flat file for the kannel operations?

>>>
>>> Well you can exclude bottlenecks by simply testing same setup with
>>> fakesmsc daemon and see if speed will be better.
>>>
>>> It might be that delay is caused by your SMSC uplinks overall speed and
>>> not database.
>>>
>>> You can also try classic smsbox implementation for sending instead of
>>> sqlbox. But I think sqlbox is fastest and more convinient way because of DB
>>> storage.
>>>
>>>
>>>
>>>

 Regards


 On 08 Dec 2015, at 15:12, spameden  wrote:



 2015-12-08 12:51 GMT+03:00 Grant Vorenberg :

> 
> 
>
> Hi
>
> We manage how big send_sms gets. The queue builder puts in 500
> messages at a time to a total maximum of 3000 from a larger main queue
> which can go as big as 2M.
>

 2M is kinda big table, how big is sent_sms? 10-30M ?

 I think your issue happens when kannel tries to move from send_sms to
 sent_sms table already submitted message this is where it hangs. You can
 try testing it yourself with simple query:

 INSERT INTO sent_sms SELECT * from send_sms where sql_id= and
 measure time per query.

 if it's instant there should be no problem.

 Generally it's better to leave sent_sms table at around 1M records not
 more, old records you can move to other table daily.


>
> Actual hardware is a VCenter on blades with plenty ram, cpu and hp
> 3PAR(144GB raid card ram for caching 

Re: Which distribution is best to run Kannel (sql)box

[Otandeka Simon Peter]

Hi,

Try setting the sms-resend-freq and sms-resend-retry to reduce on the
number of sms retries. Also set a low figure on the max-pending-submits to
reduce on your queue. This might help.

But also check on your conxn plus you could be sending to
non-existent/wrongly formatted numbers, the smsc rejects and your system
keeps trying to re-send them.

If the issue occurs at a certain period all the time, check with your smsc
vendor. Sometimes they have queue/throttling problems.

My 2 cents.

@sotandeka


On Wed, Jan 13, 2016 at 2:43 PM, Grant Saicom 
wrote:

> Example log below of one very common warning. I cannot see anything about
> tcp retransmission in the logs. We see it in tshark when things start going
> a bit out of sorts.
>
> PDU has been sanitised for privacy, so the destination and text has been
> removed.
>
> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP[internal]: Sending PDU:
> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP PDU 0x1c5bfa0 dump:
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   type_name: submit_sm
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   command_id: 4 = 0x0004
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   command_status: 0 = 0x
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   sequence_number: 6541387 =
> 0x0063d04b
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   service_type: "P_289361630"
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr_ton: 2 = 0x0002
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr_npi: 1 = 0x0001
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr: "435719276"
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   dest_addr_ton: 2 = 0x0002
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   dest_addr_npi: 1 = 0x0001
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   destination_addr: ""
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   esm_class: 3 = 0x0003
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   protocol_id: 0 = 0x
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   priority_flag: 0 = 0x
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   schedule_delivery_time: NULL
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   validity_period: NULL
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   registered_delivery: 1 = 0x0001
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   replace_if_present_flag: 0 =
> 0x
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   data_coding: 0 = 0x
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   sm_default_msg_id: 0 = 0x
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   sm_length: 91 = 0x005b
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   short_message:
> 2016-01-13 11:00:00 [4771] [7] DEBUG:Octet string at 0x1cf1070:
> 2016-01-13 11:00:00 [4771] [7] DEBUG:  len:  91
> 2016-01-13 11:00:00 [4771] [7] DEBUG:  size: 92
> 2016-01-13 11:00:00 [4771] [7] DEBUG:  immutable: 0
> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 59
> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 48
> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 4
> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data:
> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 49 53
> 2016-01-13 11:00:00 [4771] [7] DEBUG:  data: 4c 5
> 2016-01-13 11:00:00 [4771] [7] DEBUG:Octet string dump ends.
> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP PDU dump ends.
> 2016-01-13 11:00:00 [4771] [7] WARNING: SMPP: PDU element 
> too long (length is 11, should be 5)
> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP[internal]: throughput
> (12.00,0.00)
> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP[internal]: Sending PDU:
> 2016-01-13 11:00:00 [4771] [7] DEBUG: SMPP PDU 0x1d5d380 dump:
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   type_name: submit_sm
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   command_id: 4 = 0x0004
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   command_status: 0 = 0x
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   sequence_number: 6541388 =
> 0x0063d04c
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   service_type: "P_289340514"
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr_ton: 2 = 0x0002
> 2016-01-13 11:00:00 [4771] [7] DEBUG:   source_addr_npi: 1 = 0x0001
>
> On 13 Jan 2016, at 13:34, Grant Saicom  wrote:
>
> Hi
>
> Thank you for your reply. See my config below. Logs are pretty massive, so
> I am going to try find an example and send through as well.
>
>
> Kannel Conf==
> group = core
> admin-port = 13000
> smsbox-port = 13001
> admin-password = 
> log-file = "/var/log/kannel/kannel-bearerbox.log"
> log-level = 0
> box-deny-ip = "*.*.*.*"
> box-allow-ip = "127.0.0.1"
> dlr-storage = mysql
> store-location = "/var/spool/kannel"
> smsbox-max-pending = 600
>
> #IQSIM Orphan SMPP Connector
> group=smsc
> smsc=smpp
> smsc-id=internal
> interface-version=34
> host=##
> receive-port=2775
> system-id=sms2
> smsc-username=
> smsc-password=
> system-type=default
> #max-pending-submits=70
> #validityperiod=20160
>
> #IQSIM Sending SMPP Connector
> group=smsc
> smsc=smpp
> 

Re: SQLBOX queued messages question

[Grant Saicom]

Thanks for the advice.

Which smpp implementation does kannel code ship with from the repo? Just want 
to clarify as it sounds it isn’t opensmpp in the answer.

With regards to network, all the machines are on the same subnet, including the 
smsc. We have an instance within our network. On top of that, they are all on 
the same hypervisor and data fabric.

> On 13 Jan 2016, at 14:02, spameden  wrote:
> 
> opensmppbox is generally not recommended for production, it's very basic and 
> there is no accounting at all, for SMPP-server I'd recommended contacting 
> Stipe Tolk (you can find his e-mail on the lists archive in google), he has 
> commercial solution carrier-grade.
> 
> about TCP retransmissions you might need tuning either Linux network 
> settings, e.g. MTU if you're behind some sorta NAT or better contact your 
> provider with mtr output and tcpdump captures there might be unoptimal direct 
> or/and reverse network path between you and your SMSC provider.
> 
> 2016-01-13 14:07 GMT+03:00 Grant Saicom  >:
> I suspect the issue I am still experiencing is because of TCP retransmission 
> between Kannel and SMSC. The time out for ack is 210ms on the SMSC we are 
> sending to and the delay can sometimes be as long as 370ms.
> 
> I have not found a solution, but am exploring further optimisations and 
> avenues.
> 
> Another Kannel user advised me saying that openSMPP can be problematic some 
> times. Is this a generally known and confirmed issue?
> 
> Kind regards
> Grant
> 
>> On 15 Dec 2015, at 12:53, spameden > > wrote:
>> 
>> store-type = spool
>> store-location = "/tmp/kannel-spool/"
>> 
>> put these 2 lines below group = core in /etc/kannel/kannel.conf
>> 
>> do you use for dlr MySQL as well?
>> 
>> worth adding index on dlr table as well: KEY `smsc_ts` (`smsc`,`ts`) 
>> 
>> ALTER table dlr add index `smsc_ts` (`smsc`,`ts`);
>> 
>> 
>> 
>> 
>> 2015-12-15 13:43 GMT+03:00 spameden > >:
>> Yes.
>> 
>> The only thing that comes to my mind is to use kannel-store = spool and move 
>> your spool store to /tmp dir, this way queue will be in multiple files 
>> instead of the single file and in RAM, I found this way it's very fast.
>> 
>> Let me know if it helps.
>> 
>> If you want to preserve queue (in case of hard reset or something) you can 
>> rsync it's contents every 2 minutes or so in some permanent directory.
>> 
>> 2015-12-15 12:56 GMT+03:00 Grant Saicom > >:
>> Haven’t really found my answer yet, but I have another question along this 
>> line of thought.
>> 
>> I see the queue in sqlbox rises quite high, but the queue in the smpp 
>> connector to the smsc barely goes above 0.
>> 
>> Is there a way to control.modify the flow of messages from sqlbox to the 
>> smpp queue?
>> 
>> Architecturally, is this correct in terms of the flow of messages:
>> sqlbox queue -> bearerbox sms store-> smpp queue
>> 
>> Regards
>> Grant
>> 
>>> On 09 Dec 2015, at 11:56, spameden >> > wrote:
>>> 
>>> 
>>> 
>>> 2015-12-09 12:43 GMT+03:00 Grant Saicom >> >:
>>> We process the sent_sms into another table on they fly. Maximum size the 
>>> sent_sms table gets is maybe 40k tops but mostly it averages around 10K. We 
>>> see this once 1 week maybe.
>>> 
>>> I have really made every attempt to remove any bottlenecks in terms 
>>> unwieldy database sizes to allow kannel to work in a favourable environment.
>>> 
>>> Is there reason to add multiple sqlboxes to feed bearer box?
>>> 
>>> Is there maybe a concurrency setting I can do for bearer box to receive the 
>>> messages? I did not come across documentation aside from email posts with 
>>> respect to the limit-per-cycle setting.
>>> 
>>> I have another question, would we be able to get faster performance if we 
>>> went flat file for the kannel operations?
>>> 
>>> Well you can exclude bottlenecks by simply testing same setup with fakesmsc 
>>> daemon and see if speed will be better.
>>> 
>>> It might be that delay is caused by your SMSC uplinks overall speed and not 
>>> database.
>>> 
>>> You can also try classic smsbox implementation for sending instead of 
>>> sqlbox. But I think sqlbox is fastest and more convinient way because of DB 
>>> storage.
>>> 
>>> 
>>>  
>>> 
>>> Regards
>>> 
>>> 
 On 08 Dec 2015, at 15:12, spameden > wrote:
 
 
 
 2015-12-08 12:51 GMT+03:00 Grant Vorenberg >:
  
 
 
 Hi
 
 We manage how big send_sms gets. The queue builder puts in 500 messages at 
 a time to a total maximum of 3000 from a larger 

an opensmppbox question

[Alexander Grechishkin]

Hello,


I have a small question about opensmppbox configuration and I will
appreciate any help.

I want to use opensmppbox as a gateway for my customers, so they connect to
me via SMPP protocol.
But I want to use http as an smsc (customers's smppclient -> opensmppbox ->
kannel -> smsc=http -> operator HTTP-gateway)

How can I make a delivery reporting in this case?
Is there any way opensmppbox can send DELIVER_SM back to client on any http
request?
Or what would be the best way to inform opensmppbox about new delivery
reports so it can send them back to a client?


sincerely, alexander

Re: SQLBOX queued messages question

[spameden]

2016-01-13 18:30 GMT+03:00 Grant Saicom :

> I might have the wrong end of the stick here, but I was under the
> impression that kannel/bearerbox used openSMPP libraries to implement its
> smpp functionality. I have done a bit of googling and cannot see anything
> confirming this. So I guess this is not the case :)
>

No. Kannel is basically is a set of bearerbox, smsbox, wapbox.

sqlbox is a box too as well.

opensmppbox is kinda -box too.

each *box is connected to bearerbox or sometimes sqlbox connected to smsbox
for further processing.

each *box got its own functionality, but main thing is bearerbox which
routes all messages / manages your smsc uplinks and processing own internal
queues.

so if you want to just send messages through kannel you need only:

1) bearerbox
2) sqlbox

you just insert into send_sms your MT message with certain values in fields
and it's submitted to bearerbox, which sends it to upstream SMSC you
specified (smsc_id field).

this is basically how it works.


> With respect to mtr (both gateways are same device, juniper mx-140 with
> dual 10Gbit direct connection to blade hypervisor data fabric):
>  HostLoss%   Snt   Last   Avg
>  Best  Wrst StDev
>  1. smsc-gateway0.0%950.4   0.5   0.3
> 0.9   0.0
>  2. kannel 0.0%940.8   0.6
> 0.4   1.0   0.0
>
>  HostLoss%   Snt   Last   Avg
>  Best  Wrst StDev
>  1. kannel-gateway  0.0%730.4   0.3   0.3
> 0.5   0.0
>  2. smsc   0.0%720.5   0.6
> 0.4   2.7   0.4
>

Better run mtr for at least 1000 packets, but I guess since both hosts are
on the same network there shouldn't be any problem.


>
> Average on both is sub 1ms. MTU are is 1500 on both.
>

What's the software on SMSC server? Or It's some commercial solution? It
could be this is the problem.


>
> I am loathe to think it is the hypervisor or hardware as it is all service
> provider grade. I have a spare HP DL380 in the rack at the DC which was
> scheduled for collection. I may just wipe that and put kannel there and see
> how it behaves there.
>

Waiting for your results.


>
> Thank you for the advice.
>
> On 13 Jan 2016, at 15:09, spameden  wrote:
>
>
>
> 2016-01-13 15:14 GMT+03:00 Grant Saicom :
>
>> Thanks for the advice.
>>
>> Which smpp implementation does kannel code ship with from the repo? Just
>> want to clarify as it sounds it isn’t opensmpp in the answer.
>>
>
> Why do you even ask about opensmppbox? I thought original question was
> about sqlbox. OpenSMPPBox is basically a simple proxy to kannel for outside
> clients. There is not much in it, there is no flow control or accounting.
> What bearerbox/kannel implements for smsc is basically what opensmppbox
> offers in terms of connections to upstream links.
>
>
>
>> With regards to network, all the machines are on the same subnet,
>> including the smsc. We have an instance within our network. On top of that,
>> they are all on the same hypervisor and data fabric.
>>
>
> Another thought I just got: could your network problems be due your
> virtualization used? Try using kannel on a bare machine and see if there is
> any TCP retransmissions going?
>
> Did you check mtr output as well to your upstream smsc? And also check
> reverse network path if it's same or not.
>
>
>
>
>>
>> On 13 Jan 2016, at 14:02, spameden  wrote:
>>
>> opensmppbox is generally not recommended for production, it's very basic
>> and there is no accounting at all, for SMPP-server I'd recommended
>> contacting Stipe Tolk (you can find his e-mail on the lists archive in
>> google), he has commercial solution carrier-grade.
>>
>> about TCP retransmissions you might need tuning either Linux network
>> settings, e.g. MTU if you're behind some sorta NAT or better contact your
>> provider with mtr output and tcpdump captures there might be unoptimal
>> direct or/and reverse network path between you and your SMSC provider.
>>
>> 2016-01-13 14:07 GMT+03:00 Grant Saicom :
>>
>>> I suspect the issue I am still experiencing is because of TCP
>>> retransmission between Kannel and SMSC. The time out for ack is 210ms on
>>> the SMSC we are sending to and the delay can sometimes be as long as 370ms.
>>>
>>> I have not found a solution, but am exploring further optimisations and
>>> avenues.
>>>
>>> Another Kannel user advised me saying that openSMPP can be problematic
>>> some times. Is this a generally known and confirmed issue?
>>>
>>> Kind regards
>>> Grant
>>>
>>> On 15 Dec 2015, at 12:53, spameden  wrote:
>>>
>>> store-type = spool
>>> store-location = "/tmp/kannel-spool/"
>>>
>>> put these 2 lines below group = core in /etc/kannel/kannel.conf
>>>
>>> do you use for dlr MySQL as well?
>>>
>>> worth 

Re: SQLBOX queued messages question

[Grant Saicom]

I might have the wrong end of the stick here, but I was under the impression 
that kannel/bearerbox used openSMPP libraries to implement its smpp 
functionality. I have done a bit of googling and cannot see anything confirming 
this. So I guess this is not the case :)

With respect to mtr (both gateways are same device, juniper mx-140 with dual 
10Gbit direct connection to blade hypervisor data fabric):
 HostLoss%   Snt   Last   Avg  Best 
 Wrst StDev
 1. smsc-gateway0.0%950.4   0.5   0.3   0.9   
0.0
 2. kannel 0.0%940.8   0.6   0.4   
1.0   0.0

 HostLoss%   Snt   Last   Avg  Best 
 Wrst StDev
 1. kannel-gateway  0.0%730.4   0.3   0.3   0.5   
0.0
 2. smsc   0.0%720.5   0.6   0.4   
2.7   0.4

Average on both is sub 1ms. MTU are is 1500 on both.

I am loathe to think it is the hypervisor or hardware as it is all service 
provider grade. I have a spare HP DL380 in the rack at the DC which was 
scheduled for collection. I may just wipe that and put kannel there and see how 
it behaves there.

Thank you for the advice.
> On 13 Jan 2016, at 15:09, spameden  wrote:
> 
> 
> 
> 2016-01-13 15:14 GMT+03:00 Grant Saicom  >:
> Thanks for the advice.
> 
> Which smpp implementation does kannel code ship with from the repo? Just want 
> to clarify as it sounds it isn’t opensmpp in the answer.
> 
> Why do you even ask about opensmppbox? I thought original question was about 
> sqlbox. OpenSMPPBox is basically a simple proxy to kannel for outside 
> clients. There is not much in it, there is no flow control or accounting. 
> What bearerbox/kannel implements for smsc is basically what opensmppbox 
> offers in terms of connections to upstream links.
> 
> 
> 
> With regards to network, all the machines are on the same subnet, including 
> the smsc. We have an instance within our network. On top of that, they are 
> all on the same hypervisor and data fabric.
> 
> Another thought I just got: could your network problems be due your 
> virtualization used? Try using kannel on a bare machine and see if there is 
> any TCP retransmissions going?
> 
> Did you check mtr output as well to your upstream smsc? And also check 
> reverse network path if it's same or not.
>  
> 
>  
> 
>> On 13 Jan 2016, at 14:02, spameden > > wrote:
>> 
>> opensmppbox is generally not recommended for production, it's very basic and 
>> there is no accounting at all, for SMPP-server I'd recommended contacting 
>> Stipe Tolk (you can find his e-mail on the lists archive in google), he has 
>> commercial solution carrier-grade.
>> 
>> about TCP retransmissions you might need tuning either Linux network 
>> settings, e.g. MTU if you're behind some sorta NAT or better contact your 
>> provider with mtr output and tcpdump captures there might be unoptimal 
>> direct or/and reverse network path between you and your SMSC provider.
>> 
>> 2016-01-13 14:07 GMT+03:00 Grant Saicom > >:
>> I suspect the issue I am still experiencing is because of TCP retransmission 
>> between Kannel and SMSC. The time out for ack is 210ms on the SMSC we are 
>> sending to and the delay can sometimes be as long as 370ms.
>> 
>> I have not found a solution, but am exploring further optimisations and 
>> avenues.
>> 
>> Another Kannel user advised me saying that openSMPP can be problematic some 
>> times. Is this a generally known and confirmed issue?
>> 
>> Kind regards
>> Grant
>> 
>>> On 15 Dec 2015, at 12:53, spameden >> > wrote:
>>> 
>>> store-type = spool
>>> store-location = "/tmp/kannel-spool/"
>>> 
>>> put these 2 lines below group = core in /etc/kannel/kannel.conf
>>> 
>>> do you use for dlr MySQL as well?
>>> 
>>> worth adding index on dlr table as well: KEY `smsc_ts` (`smsc`,`ts`) 
>>> 
>>> ALTER table dlr add index `smsc_ts` (`smsc`,`ts`);
>>> 
>>> 
>>> 
>>> 
>>> 2015-12-15 13:43 GMT+03:00 spameden >> >:
>>> Yes.
>>> 
>>> The only thing that comes to my mind is to use kannel-store = spool and 
>>> move your spool store to /tmp dir, this way queue will be in multiple files 
>>> instead of the single file and in RAM, I found this way it's very fast.
>>> 
>>> Let me know if it helps.
>>> 
>>> If you want to preserve queue (in case of hard reset or something) you can 
>>> rsync it's contents every 2 minutes or so in some permanent directory.
>>> 
>>> 2015-12-15 12:56 GMT+03:00 Grant Saicom >> >:
>>> Haven’t really found my answer yet, but I have another question along this 
>>> line of thought.
>>> 
>>> I see