SMS via API, in case of flood, lot of SMS are lost

Networking Solutions
1

Hello,

We planned to switch from a homemade solution to send SMS to using a Teltonika device.

For our test we have a RUTX09 , we wrote a small Python script who open a session with user/password and then post a SMS to the “/api/messages/actions/send” end-point.

Everything works fine when sending a single SMS.

But in real life, sometimes we have peaks in number of SMS to send (like 50 or more SMS), so we tried to simulate this behavior by doing a simple loop in a SHELL :

for i in {1..30}; do echo $i; ./send_SMS.py; done

Unfortunately we don’t received 30 SMS, but something like 21.

Even worse, if I do this from 2 different shell at the same time, (so, 2 x 30 SMS sent) I receive only 24 SMS.

For each API call, the RUTX09 respond every time with : {‘success‘: True, ‘data‘: {‘sms_used‘: 1}}, so we expect the SMS to be in queue.

There is a limit when sending SMS simultaneously ? No queue is present ? Why are the SMS ack by the RUTX but lost. ?

Firmware : RUTX_R_00.07.19.4

Thanks

3

Hello,

These limitations are usually set by the operators, not by our devices - normal SIM cards aren’t made to handle to spam SMS messages ever so often.

You can try re-testing by adding a little delay of, say, 15-20 seconds between each SMS message and see if you receive all of them.

Regards,
M.

4

Hello Matas,

Following you message I did some other tests.

With short messages (1 message = 1 SMS)

1st column is the number of simultaneous shell loops

2 x 10 messages, with a “sleep 2”, 100% received.
4 x 10 messages, with a “sleep 2”; 25/40 received.

=> A delay is needed between API calls, RUTX do not manage concurrents calls with a queue.
This is a problem when API calls can be made from different sources.

#########################################################################

With long messages, SMS have to be cut into several SMS (1 message = 2 SMS)

100% received , but sometimes, take ages to get an answer from RUTX. Please look at each “real” lines.

@fedora:~/$ for i in {1..10}; do echo $i; sleep 4; time ./envoiSMS.py; done
1
Return from RUTX : {‘success’: True, ‘data’: {‘sms_used’: 2}}
real	0m1,065s

2
Return from RUTX : {‘success’: True, ‘data’: {‘sms_used’: 2}}
real	0m0,900s

3
Return from RUTX : {‘success’: True, ‘data’: {‘sms_used’: 2}}
real	0m55,818s

4
Return from RUTX : {‘success’: True, ‘data’: {‘sms_used’: 2}}
real	0m0,991s

5
Return from RUTX : {‘success’: True, ‘data’: {‘sms_used’: 2}}
real	0m0,945s

6
Return from RUTX : {‘success’: True, ‘data’: {‘sms_used’: 2}}
real	0m58,782s

7
Return from RUTX : {‘success’: True, ‘data’: {‘sms_used’: 2}}
real	0m55,938s

8
Return from RUTX : {‘success’: True, ‘data’: {‘sms_used’: 2}}
real	0m55,786s

9
Return from RUTX : {‘success’: True, ‘data’: {‘sms_used’: 2}}
real	0m0,961s

10
Return from RUTX : {‘success’: True, ‘data’: {‘sms_used’: 2}}
real	0m0,966s

I did the same on another SMS solution built on Smstools3, the SMS parts are sent without trouble at ~5s interval

2026-02-05 14:25:26,5, Cinterion: SMS sent (part 1/2), Message_id: 184, To: 00000000000, sending time 5 sec.
2026-02-05 14:25:30,5, Cinterion: SMS sent (part 2/2), Message_id: 185, To: 00000000000, sending time 4 sec.
2026-02-05 14:25:34,5, Cinterion: SMS sent (part 1/2), Message_id: 186, To: 00000000000, sending time 4 sec.
2026-02-05 14:25:38,5, Cinterion: SMS sent (part 2/2), Message_id: 187, To: 00000000000, sending time 4 sec.
2026-02-05 14:25:43,5, Cinterion: SMS sent (part 1/2), Message_id: 188, To: 00000000000, sending time 5 sec.
2026-02-05 14:25:49,5, Cinterion: SMS sent (part 2/2), Message_id: 189, To: 00000000000, sending time 6 sec.
2026-02-05 14:25:54,5, Cinterion: SMS sent (part 1/2), Message_id: 190, To: 00000000000, sending time 5 sec.
2026-02-05 14:25:58,5, Cinterion: SMS sent (part 2/2), Message_id: 191, To: 00000000000, sending time 4 sec.

Do you have an idea why sending multipart SMS, give strange results : API response with very high response time (~ 55s) ?

Regards.

5

Hi there,

This is expected behaviour. I suggest using an even longer delay between SMS messages. The API gets stuck and doesn’t give an answer until the modem sends the next SMS message; that’s why it takes up to a minute. A longer SMS means that the modem needs to send 3-5 SMS messages, which takes more time. The maximum SMS length is 160 symbols, so they’re simply divided into smaller parts, hence more SMSes are being sent.

In short - this is expected, higher delay should be used.

Regards,
M.

6

I think there another problem that time to wait between 2 SMS, I just did another test :

  1. Sent 1 SMS (170 chars, 1 API call, but 2 SMS was sent)
  2. Instant received it on my mobile
  3. Waited 12 seconds
  4. Sent 1 SMS (170 chars, 1 API call, but 2 SMS was sent)
  5. Instant received it on my mobile BUT the API do not give any answer before 55s

What can explain the time between when I already received the SMS and the time the API give his response ?

Any debug mode on this side ?

Thanks

7

Hi there,

After consulting with the R&D, I’ve been told that this is usually due to the operator taking a while to respond. You could test this with a different operator SIM card to see if perhaps the timings are different, but this seems to be a limitation from the other end, not from ours.

Regards,
M.