[Bryon Davis]

Alex,
A feature request has been created for viewing Unicode as readable text in the outbox.

Bryon

[Bryon Davis]

Alex,
Sorry, with Unicode the Outbox will only display the hex values. The Unicode hex values must be encoded and decoded. If you are using the API, many of the programming languages provide methods to convert between Unicode hex values and other encodings.

Bryon

[Bryon Davis]

Alex,
When using Unicode you must set the encoding option “enc” to 2 (Hex) or 3 (Decimal). When using Unicode, you must supply the Unicode values of the characters separated by semicolons.

Here is an example of sending the message “120€” using hex values of Unicode:

http://192.168.2.1:81/sendmsg?user=admin&passwd=admin&cat=1&enc=2&to=”17637654321″&text=31;32;30;20AC

Note that “&enc=2” which means the Unicode values should be hexadecimal values, and the the euro symbols Unicode hex value is “20AC”.

Bryon

[Bryon Davis]

Hi Alex,
Make sure that “Enable PDU Mode” is enabled in the SMS Settings menu.

Any special characters should be URL encoded in the sendmsg request.

Below is a sendmsg request example for sending the sms message “Ää,Öö,Üü,ß”:

http://smsgateway.xxxxx.de/sendmsg?user=admin&passwd=xyz&cat=1&enc=0&to=0123456789&priority=3&text=%C4%E4,%D6%F6,%DC%FC,%DF

Bryon

[Bryon Davis]

Anton,
Sorry, there isn’t a way to block specific numbers on the iSMS. Your cellular provider may be able to block certain senders.

Bryon

[Bryon Davis]

Fleure,
In my testing of the java code I provided I noticed that it was handling special characters correctly. I’ve updated the java code to handle special characters.

import java.io.*;
import java.net.*;

public class TCPServer {
    
    public static void main(String argv[]) throws Exception
    {
        int port = 2040;
        int msgCount = 0;
                 
        ServerSocket welcomeSocket = new ServerSocket(port);
        System.out.println("TCP Server Starting on Port: " + port);

        while(true)
        {
            Socket connectionSocket = welcomeSocket.accept();
            InputStream inStream = connectionSocket.getInputStream();
            DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());

            msgCount++;
            System.out.println("------------------");
            System.out.println("Msg #: " + msgCount);
            
            // Create byte buffer, read data, and convert to ISO-8859-1 string
            byte[] inBytes = new byte[64000];
            inStream.read(inBytes);
            String recvData = new String(inBytes, "ISO-8859-1");
            System.out.println("Received: \r\n" + recvData);
                                   
            // Send "OK" response
            System.out.println("Sending: OK");
            byte[] b = "OK".getBytes();
            outToClient.write(b);

            System.out.println("Done.");
            System.out.println("------------------\n\n");
        }
    }
}

[Bryon Davis]

Sean,
I’m not sure if the following will work on v1.31, but it works on the latest firmware.

Below is one method to reboot the SF100 remotely. Note we recommend saving first so no information is lost.
1. Telnet to the SF100 on port 2222 and login as admin.
2. At the # prompt enter “save” (without the quotes), and wait for the save sequence to complete, a # prompt will be shown when it is done.
3. Enter “reboot”.

Bryon

[Bryon Davis]

For ASCII there isn’t a way.

But if you sent a message as Unicode you could send the euro symbol.

[Bryon Davis]

Florian,
Sorry the euro symbol isn’t currently support with ASCII (7 bit) and Extend ASCII (8 bit) messages on the iSMS. While the euro symbol is supported in the 3GPP 23.038 character set, the iSMS uses ISO-8859-1 internally for ASCII messages, which doesn’t support the euro symbol. Unicode messages do support the euro symbol.

Bryon

[Bryon Davis]

fleure,
I verified that the SF800 firmware currently uses 20 seconds for the timeout value when waiting for a Non-Polling TCP Receive API response. I will increase this to 30 seconds in the next firmware.

If you are receiving time out or “failed to connect to TCP server” messages in the Receive API Live Log, I can make this change available to you.

Bryon

[Bryon Davis]

fleure,
Yes, the sms texts were only delivered once if the OK response was successfully received by the SF800.

Please check the “Receive API Live Log” to see if the Delivery was considered successful by the SF800. If a delivery was considered a failure, the sms texts will be redelivered until it is successful.

If the “Receive API Live Log” shows the deliveries are failing, the delivery message will help determine what the problem may be. A “failed to connect to TCP server” message may indicate that the response took longer than expected or wasn’t receive. If it receive an incorrect response, it will display the response it received.

Bryon

[Bryon Davis]

I tested the previous java code with my SF800 and noticed two problems.

First that the Java code was taking a very long time to readline all of the input stream. It took 20 seconds before it would respond with an OK.

The second issue is that the SF800 wasn’t waiting 30 seconds before timing out. I’m looking into why the SF800 is timing out too quick.

I also updated the java code to use read() instead of readline() which is much quicker. I test with 47 messages on my SF800 and it still successfully delivered.

Here is the updated java code:

import java.io.*;
import java.net.*;

public class TCPServer {
    
    public static void main(String argv[]) throws Exception
    {
        int port = 2040;
        int msgCount = 0;
         
        ServerSocket welcomeSocket = new ServerSocket(port);
        System.out.println("TCP Server Starting on Port: " + port);

        while(true)
        {
            Socket connectionSocket = welcomeSocket.accept();
            BufferedReader inFromClient =
               new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));
            DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());

            msgCount++;
            System.out.println("------------------");
            System.out.println("Msg #: " + msgCount);
            
            char[] inChars = new char[64000];
            inFromClient.read(inChars);
            String recvData = new String(inChars);
            System.out.println("Received: \r\n" + recvData);
                                
            System.out.println("Sending: OK");
            byte[] b = "OK".getBytes();
            outToClient.write(b);

            System.out.println("Done.");
            System.out.println("------------------\n\n");
        }
    }
}

[Bryon Davis]

I updated the java code to show the entire message received. See Below.

import java.io.*;
import java.net.*;

public class TCPServer {
    
    public static void main(String argv[]) throws Exception
      {
         int port = 2040;
         String recvLine = "";
         ServerSocket welcomeSocket = new ServerSocket(port);
         System.out.println("TCP Server Starting on Port: " + port);

         while(true)
         {
            Socket connectionSocket = welcomeSocket.accept();
            BufferedReader inFromClient =
               new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));
            DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());
            String recvData = "";
            while(true)
            {
                recvLine = inFromClient.readLine();
                if (recvLine==null)
                    break;
                recvData += recvLine + "\r\n";
            }
            System.out.println("Received: \r\n" + recvData);
            System.out.println("Sending: OK");
            byte[] b = "OK".getBytes();
            outToClient.write(b);
         }
      }
}

[Bryon Davis]

fleure,
When testing the java code provided with my SF100 v1.51.28 (the SF400 and SF800 should behave the same), my TCP Non-Polling Recv API deliveries were shown as successful in the SF100’s “Receive API Live Log” and were only delivered once.

If you are still getting the same messages multiple times, then I would suggest making sure you are at the latest firmware (v1.51.28), verify that “Non Polling Receive API Status” is set to TCP in the SMS API menu (HTTP requires a different response), and check what the Receive API Live Log is showing. The Receive API Live log should show if it was considered successful, and if it wasn’t it will show the response it received from your server.

Bryon

[Bryon Davis]

fleure,
I was able to create a simple java server program that successfully responds to the iSMS Non-Polling TCP deliveries.

Here it is:

import java.io.*;
import java.net.*;

public class TCPServer {
    
    public static void main(String argv[]) throws Exception
      {
         int port = 6789;
         String recvLine;
         ServerSocket welcomeSocket = new ServerSocket(port);
         System.out.println("TCP Server Starting on Port: " + port);

         while(true)
         {
            Socket connectionSocket = welcomeSocket.accept();
            BufferedReader inFromClient =
               new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));
            DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());
            recvLine = inFromClient.readLine();
            System.out.println("Received: " + recvLine);
            System.out.println("Sending: OK");
            byte[] b = "OK".getBytes();
            outToClient.write(b);
         }
      }
}

[Bryon Davis]

Hi fleure,
Sorry for the delay, I have been looking into this problem some more. In my testing, I just needed to send “OK” (capital letters without the quotes) and it accepted it. I used a simple python script that created a socket to test with. If I sent a different response it failed.

I haven’t had a chance to try with java yet.

Can you copy and paste an example of a failed delivery attempt from the “Receive API Live Log”? This is in the Statistics&Logs -> Log Traces menu. I would suggest omitting any personal data such as names and phone numbers.

If you prefer, you can create a case in the support portal where it would be easier to attach files.

Bryon

[Bryon Davis]

Kirk,
The +CMT message shows that the message is coming from the modem already changed, which most likely means it came from the cellular network already changed. I haven’t seen a case were the modem itself changed characters. I have seen problems when going between different carriers.

Bryon

[Bryon Davis]

Kirk,
You can see the text the modem received by looking at the SMS Live Log in the Statistics&Logs -> Log Traces menu. When a message is received it comes in as a “+CMT” message. If you are using PDU mode, you may need to use an online PDU decoder to see what the text was.

If the +CMT message shows that it received “-” rather than “@” than most likely it was changed in the Cellular Network(s) before reaching the modem.

If the +CMT message contained a “@”, then check the Inbox to see what is shown there, and also the “Receive API Live Log” to see what message was delivered to your web server.

When you reboot, the logs are wiped, so you would have to wait for it to occur again and then look at the SMS Live Log for that modem.

Bryon

[Bryon Davis]

fleure,
What programming language are you using?

Bryon

[Bryon Davis]

Hi Kirk,
If it is only happening 1%, then it is unlikely the iSMS is changing these messages. If possible, I would first verify that the message was sent correctly. Next see if only certain users, phones or carriers are having the issue. If it’s random, then it will be difficult to track down the problem.

Bryon

[Bryon Davis]

fleure,
Looking at the code, for TCP Non-Polling API we are expecting the response to start with “OK” (no quotes). I don’t believe it needs special format like a HTTP response.

Bryon

[Bryon Davis]

fleure,
The TCP response should be “OK” (without the quotes).

What firmware version are you using? There is a known issue with v1.50.7 where the OK response isn’t always recognized, and the same messages are repeatedly sent.

The firmware at the links below is the latest firmware and includes a fix for this:

SF100:
https://webfiles.multitech.com/engineering/unofficial-releases/iSMS%20(Formerly%20SMSFinder)/Firmware/SF100/1.51.28/SF100-u-v1.51.28-25Nov2014.zip

SF400 and SF800:
https://webfiles.multitech.com/engineering/unofficial-releases/iSMS%20(Formerly%20SMSFinder)/Firmware/SF400_SF800/1.51.28/SF400-800-u-v1.51.28-25Nov2014.zip

Bryon

[Bryon Davis]

fleure,
It looks like you are using Polling mode for the Receive API. Make sure that “Non Polling Receive API Status” is disabled in the SMS API menu. If using TCP, also select TCP as the Protocol and click save.

In my testing I would receive a “System Busy” error when sending a TCP recvmsg request if “Non Polling Receive API Status” was enabled. Once I disabled this, then I was able to successfully send the TCP recvmsg request.

The format of the recvmsg request is:

GET /recvmsg?user=admin&passwd=admin[&count=][&from][&fdate=][&tdate=][&ftime=][&ttime=][&text=]

An example of a simple TCP recvmsg request would be (requests all unread received sms messages):

/recvmsg?user=admin&passwd=admin

Note: that the above request must end with a carriage return and linefeed.

Bryon

[Bryon Davis]

Tim,
Sorry, I haven’t tried any of the 3rd party software, so I can’t suggest one that would do what you want. We don’t have any suggestions for a programmer either.

Bryon

[Bryon Davis]

Hi fleure,
Which Receive API mode do you want to use, Polling or Non-Polling?

With Non-Polling, the iSMS will automatically deliver incoming messages to a server when they are received.

With Polling, your software would need to send a recvmsg request to get the unread incoming sms messages.

For more information see the MultiModem iSMS Administrator’s Guide’s “Appendix A – Application Programming Interface (API)” section. See link below.

http://www.multitech.com/manuals/s000461f.pdf

Regards,
Bryon

[Bryon Davis]

Hi Tim,
The built in action triggers currently don’t allow you add a number to a group without semicolons. It would need to be done through a custom software using API commands to communicate with the iSMS.

Through the Receive API, the software could receive the “Add groupname” sms message. That software could then issue a sendmsg command to add that sender to the group indicated.

An example of a HTTP sendmesg to add a number to a group would be:
http://192.168.2.1:81/sendmsg?user=user1&passwd=user1&cat=3&enc=0&text=ADDG;groupname;sendername;sendernumber

You could also maintain groups in your software, which would give you more flexibility.

Regards,
Bryon

[Bryon Davis]

Try changing the following line to end with “\r\n” (carriage return and linefeed):

socket.setSoTimeout(0); String sms=”sendmsg?user=admin&passwd=mdp&cat=1&enc=1&priority=3&modem=0&to=%22xxxxxxxx%22&text=HellowviaCode\r\n”;

[Bryon Davis]

The 609 error indicates that there was “Timeout waiting for a TCP API request”.

The “/sendmsg?user=admin&passwd=mdp&cat=1&enc=1&priority=3&modem=0&to=%22xxxxxxxx%22&text=Hellow.” request must end with a carriage return and linefeed. Otherwise the iSMS will wait for more data and eventually timeout.

[Bryon Davis]

Hi fleure,
There is a Java API example at the link below:

https://webfiles.multitech.com/engineering/sample-code/sms-finder/java/Response/

Hopefully with this example and removing the %20 between / and sendmsg (see your other post) will resolve the issue.

Regards,
Bryon

[Bryon Davis]

Hi fleure,
Based on your other post, it appears that you have a %20 (space) between the / and sendmsg which shouldn’t be there.

Try your API request without this space:

/sendmsg?user=admin&passwd=mdp&cat=1&enc=1&priority=3&modem=0&to=%22xxxxxxxx%22&text=Hellow.

Regards,
Bryon

[Author]

Posts