SMS tool improvements

RouterOS General
1

Hello,

SMS tool improvements sugestions:

1. Logging
Please do not log misleading gsm error if SMS is received when allowed-number property is set and sender number that is not in that list when it’s message text not contains syntax for performing script commands (starting with ":cmd ").
Logged error example:

gsm,error allowed number does not match with: +XXXXXXXXXX

Some operators regularly sends info SMS messages and log is bloated with these errors. I know that is possible to dismiss in log settings this topic, but I want to have it when SMS with command syntax is recevived and sender is not in allowed-number or just to have log if any other gms error occours.

SMS tool properties:

/tool/sms print
           status: running
  receive-enabled: yes
             port: lte1
          channel: 0
           secret: xxxxxxx
   allowed-number: +XXXXXXXXXXX,00XXXXXXXXXXX,+XXXXXXXXXXX,00XXXXXXXXXXX
       auto-erase: no
          sim-pin: 
        last-ussd:

2. Segmented (multipart) SMS
Please add support for segmented SMS messages (at least for receiving). When segmented SMS is received, messages are splitted in inbox into several messages, but for readability purposes or script automation per message (eg. I have scheduled script that monitors SMS inbox and forwards new messages onto email) proper solution will be that these messages are merged into single.

3. Unicode SMS
Please add support for Unicode (UCS-2 encoded) characters in SMS messages (at least for receiving). Eg. info SMS messages from operators can contain messages that have UCS-2 encoded characters and these characters are not correctly displayed (? characters are dislayed instead correct ones).

I’m using Chateau LTE12 with RouterOS 7.6.

2

+1

Only thing I’d add is that /tool/sms/send accepting UTF-8 be more useful – RouterOS could do the needed PDU stuff to convert/flag/pack the UTF-8 to UCS-2 internally. Since some SSH client and REST API already will get UTF-8 into RouterOS, this be a more natural API than accepting the raw big-endian UCS-2 which in nearly all cases require encoding before calling /tool/sms. e.g. Perhaps some “format=” option:

 /tool/sms/send format=utf8 message="\D0\9A\D1\80\D1\83\D1\82\D0\BE\D0\B9"

(message=Крутой in UTF-8 encoded as Mikrotik String)

If this was called from REST, it already be UTF-8 encoded using most clients.

3

Making multipart / segmented SMS-messages visible as a single message in the inbox would indeed be a great advantage.