Search Results for 'SMS API'

[Jeff Hatch]

Paul,

There is an undocumented API call to send an SMS on the rCell Model MTR. There is some discussion of it in this thread:

http://www.multitech.net/developer/forums/search/?bbp_search=SMS+API

We will be trying to update the API documentation in the future. In summary, to send a text through the API you can make a CURL request to:

https://conduit_ip/api/command/sms_send

with Json data in the following format:

{“recipients”: “phone_number”, “message”:”message text”}

Jeff

[Paul Smith]

I am also curious about this.. Sale pointed us to the rCell Model MTR as a replacement for the iSMS, but I think this was incorrect as there is no API interface for sending SMS messages (unless it’s undocumented). I’m too am looking for a replacement for the iSMS gateway as it’s aging out of the network that we use. API/CURL requests to send simple SMS messages what I need, on a CDMA network.

[Melvin Chow]

Hi Rick,

I think the problem here is not familiar of the JSON data structure and command sequence, and syntax etc….., to use the HTTP to send the SMS, we need to include the Token.

I would like to list out the Multitech testing example below to help all other customer with similar problem. Honestly said I am not an expect to JSON data, and I have no intention to learn it due to this small project, but we just want to use it as application level and solve the problem.

I hope the below http/https sms example provided by Multitech could help all other customer in the future, and solve the problem in a short time.

here is the HTTP send SMS example from Lonny, I changed to Tel number to 12345678

/////////////////////////////////////////////////
###############
Login
###############
root@multitech-MS-7253:/home/multitech/api# wget ‘http://192.168.2.1/api/login?username=admin&password=admin’–2016-05-24 10:57:48– http://192.168.2.1/api/login?username=admin&password=admin
Connecting to 192.168.2.1:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [application/json]
Saving to: 鈥榣ogin?username=admin&password=admin鈥?
[ <=> ] 265 –.-K/s in 0s

2016-05-24 10:57:48 (16.4 MB/s) – 鈥榣ogin?username=admin&password=admin鈥?saved [265]

#############
read token
#############
root@multitech-MS-7253:/home/multitech/api# cat login\?username\=admin\&password\=admin
{
“code” : 200,
“result” : {
“address” : “192.168.2.13”,
“permission” : “admin”,
“port” : “50709”,
“timestamp” : “20:54:11:830”,
“token” : “A26A8ACCE10AEE088AE96255EC64041”,
“user” : “admin”
},
“status” : “success”
}

################
get inbox
################
root@multitech-MS-7253:/home/multitech/api# wget ‘http://192.168.2.1/api/sms/inbox?token=A26A8ACCE10AEE088AE96255EC64041&#8217;
–2016-05-24 10:58:26– http://192.168.2.1/api/sms/inbox?token=A26A8ACCE10AEE088AE96255EC64041
Connecting to 192.168.2.1:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [application/json]
Saving to: 鈥榠nbox?token=A26A8ACCE10AEE088AE96255EC64041鈥?
[ <=> ] 63 –.-K/s in 0s

2016-05-24 10:58:26 (3.86 MB/s) – 鈥榠nbox?token=A26A8ACCE10AEE088AE96255EC64041鈥?saved [63]

##################
read inbox
note: inbox empty
##################
root@multitech-MS-7253:/home/multitech/api# cat inbox\?token\=A26A8ACCE10AEE088AE96255EC64041
{
“code” : 200,
“result” : [],
“status” : “success”
}

###################
send SMS to myself
###################
root@multitech-MS-7253:/home/multitech/api# wget ‘http://192.168.2.1/api/sms/outbox?data={“recipients”: [“12345678”], “message”: “Hello World”}&token=A26A8ACCE10AEE088AE96255EC64041&method=POST’
–2016-05-24 11:00:10– http://192.168.2.1/api/sms/outbox?data=%7B%22recipients%22:%20%5B%2212345678%22%5D,%20%22message%22:%20%22Hello%20World%22%7D&token=A26A8ACCE10AEE088AE96255EC64041&method=POST
Connecting to 192.168.2.1:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [application/json]
Saving to: 鈥榦utbox?data=%7B%22recipients%22:%20[%2212345678%22],%20%22message%22:%20%22Hello%20World%22%7D&token=A26A8ACCE10AEE088AE96255EC64041&method=POST鈥?
[ <=> ] 45 –.-K/s in 0s

2016-05-24 11:00:10 (2.65 MB/s) – 鈥榦utbox?data=%7B%22recipients%22:%20[%2212345678%22],%20%22message%22:%20%22Hello%20World%22%7D&token=A26A8ACCE10AEE088AE96255EC64041&method=POST鈥?saved [45]

############
get outbox
############
root@multitech-MS-7253:/home/multitech/api# wget ‘http://192.168.2.1/api/sms/outbox?data={“recipients”: [“12345678”], “message”: “Hello World”}&token=A26A8ACCE10AEE088AE96255EC64041’
–2016-05-24 11:00:53– http://192.168.2.1/api/sms/outbox?data=%7B%22recipients%22:%20%5B%2212345678%22%5D,%20%22message%22:%20%22Hello%20World%22%7D&token=A26A8ACCE10AEE088AE96255EC64041
Connecting to 192.168.2.1:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [application/json]
Saving to: 鈥榦utbox?data=%7B%22recipients%22:%20[%2212345678%22],%20%22message%22:%20%22Hello%20World%22%7D&token=A26A8ACCE10AEE088AE96255EC64041鈥?
[ <=> ] 291 –.-K/s in 0s

2016-05-24 11:00:53 (11.9 MB/s) – 鈥榦utbox?data=%7B%22recipients%22:%20[%2212345678%22],%20%22message%22:%20%22Hello%20World%22%7D&token=A26A8ACCE10AEE088AE96255EC64041鈥?saved [291]

#######################
read outbox
note: sms is in outbox
#######################
root@multitech-MS-7253:/home/multitech/api# cat outbox\?data\=%7B%22recipients%22\:%20\[%2212345678%22\]\,%20%22message%22\:%20%22Hello%20World%22%7D\&token\=A26A8ACCE10AEE088AE96255EC64041
{
“code” : 200,
“result” : [
{
“guid” : “2016052415594100”,
“message” : “Hello World”,
“recipient” : “12345678”,
“retries” : 0,
“status” : “sent”,
“timestamp” : “2016/05/24 15:59:41”
}
],
“status” : “success”
}

###########
get inbox
###########
root@multitech-MS-7253:/home/multitech/api# wget ‘http://192.168.2.1/api/sms/inbox?token=A26A8ACCE10AEE088AE96255EC64041&#8217;
–2016-05-24 11:02:30– http://192.168.2.1/api/sms/inbox?token=A26A8ACCE10AEE088AE96255EC64041
Connecting to 192.168.2.1:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [application/json]
Saving to: 鈥榠nbox?token=A26A8ACCE10AEE088AE96255EC64041.1鈥?
[ <=> ] 237 –.-K/s in 0s

2016-05-24 11:02:30 (14.4 MB/s) – 鈥榠nbox?token=A26A8ACCE10AEE088AE96255EC64041.1鈥?saved [237]

#####################
read inbox
note: inbox now has
received sms
#####################

root@multitech-MS-7253:/home/multitech/api# cat inbox\?token\=A26A8ACCE10AEE088AE96255EC64041.1
{
“code” : 200,
“result” : [
{
“guid” : “2016052415595400”,
“message” : “Hello World”,
“source” : “12345678”,
“timestamp” : “2016/05/24 15:59:54”
}
],
“status” : “success”
}
root@multitech-MS-7253:/home/multitech/api#

///////////////////////////////////////////
////////////////////////////////////////////////

Here is the example to use HTTPS to send and receive SMS from Multitech engineer
/////////////////////////////////////////////
If you want to send sms using api, here is the command:

https://192.168.2.1/api/sms/outbox?data={“recipients”: [“12345678900”], “message”: “Hello World”}&method=POST

Notes: You can also send multiple phone numbers, just separate it with a comma. For example, “1234567890”,”0987654321″
Is it possible to retrieve the SMS response for a message which is sent via the API? (OK, ERROR, etc.)
Answer: https://192.168.2.1/api/sms/outbox
////////////////////////////////////////////////////////

[Jeff Hatch]

Rick,

I am able to log in to the UI with a browser, so the API should be working through the HTTP port 80. Are you using Curl to make your requests? If so, you may have to use some options to keep track of the authentication token for you after the login request.

Jeff

[Rick Wong]

Thanks Jeff. I think that is missed in the development guide. However, the API works well for me if I am using HTTPS.
Due to the application limitation, I can only use HTTP to call the API but HTTP does not work.

It throws when I tried to call api/whoami or api/command/sms_send with HTTP:
{
“code” : 401,
“error” : “not logged in”,
“status” : “fail”
}

I could call api/login with HTTP with code 200 and status success.

[Jeff Hatch]

Rick,

In the previous message, the URL got messed up and should be:

https://[conduit_ip]/api/command/sms_send

and the Json data:

{“recipients”: “phone_number”, “message”:”message text”}

Jeff

[Jeff Hatch]

Rick,

The part of the API that supports sending an SMS message is in the command controller object. The URL for that will be

https:///api/command/sms_send

The Json data (post fields) will be of the following format:

{“recipients”:”“, “message”:”“}

Hope that helps,

Jeff

[Rick Wong]

Hi Lonny,
When I refer to the API development guide under SMS section, it seems that the API is only support for SMS settings but not sending SMS message.
If the API supports SMS message sending, could you please guide me which API object and element I should call?

[Lonny Knudson]

Hi Rick,
The MTR series has an API that will allow you to exchange SMS via http, here is a link to the API manual:
http://www.multitech.com/manuals/s000576_1_2_1.pdf
If you have an existing application that uses 3GPP TS 27.005 AT commands, you can enable telnet access to cellular radio and have your application interact with the radio over a TCP socket. If this method is chosen you will need to dedicate the MTR to the SMS application only.

[Brandon Bayer]

Borut,

No, there’s not an option for that. And yes, you are correct, the API doc really needs updating!

-Brandon

[Borut Milič]

MTR-H6-B16

Is there any option to specify string encoding when using SMS API? Something like

http://192.168.2.1%5B:portnumber%5D/sendmsg?user=user1&passwd=puser1&cat=1%5B
&enc=0]&to=”7657867765”&text=message

in iSMS API?

enc Encoding type to send SMS(Optional field)
Range: 0 to 3
0 – SMS text should be in ASCII form
1 – SMS text should be in Extended ASCII form
…

I am getting strange characters on the mobile, for example | or _ are substituted with ö and section sign.

You guys really have bad API documentation, i didn’t find it even just for sending sms, had to inspect request in chrome..

• This topic was modified 8 years, 1 month ago by Borut Milič.

[Jeff Hatch]

Gavin,

The change to the SMS node was for localhost-only traffic between the node and the SMS API interface on the Conduit. HTTPS consumes a lot of memory in nodejs.

As for the SMTP node, I’m not sure that it does TLS. That may be the issue. Either that or the auth is broken. Either way, it is the stock Node-RED SMTP node, and we haven’t touched it. I haven’t gotten it to work effectively with any “real” email server.

Jeff

[Bryon Davis]

Hi John,
What do you mean by MessageID? Are you referring to a message index number that counts the received sms messages being delivered, or the original Msg ID for the sms that was sent through the iSMS?

If you are referring to the Msg ID given when scheduling to send the sms message, this is only an internal ID value for referencing a send sms job and the receiving sms device won’t receive this information.

If you want a message index, then I suggest upgrading to the v1.51.28 firmware which adds the “Send Message Index” option in the SMS API menu’s Non-Polling Receive API configuration section. See the links below for upgrading to v1.51.28, it includes instructions on upgrading and a list of changes.

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

SF400/SF800 v1.51.28:
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

[Brandon Bayer]

Borut,

I don’t think David is using an MTR. It sounds like he is using a plain SocketModem radio.

But on the MTR, it does have an SMS API for sending and receiving sms. It doesn’t have any advanced application layer sms handling, but you can certainly write an application that uses the MTR’s API to send and receive sms.

-Brandon

[Alex Warden]

Hi Bryon,

thanks for the reply.

I wasn’t aware about the complete lock-up during telnet sessions, good to know. I guess one could pull the signal strength info with a little bit of perl scripting from the web interface…

Maybe you guys could add this feature to API in the future fw version, to make it easier for everyone. I think it’s really needed, especially for alarming purposes.

Recently one of our SF100-Gs devices had zero singnal strength for a few hours (provider problems) and we failed to notice it…
Currently our SMS-script only checks network availability before redirecting SMS-Message to a first reachable/available SMS-modem (we have several SF100-G with different SMS service providers).
So we need to check the signal strength as well, to increase the chances of SMS-delivery.

[Bryon Davis]

Hi Alex,
Sorry, there isn’t an API or SNMP method to check the signal strength. And we don’t recommend using telnet directly to the modem since that takes complete control of the modem and locks out the iSMS firmware until the connection is disconnected. This can interrupt the iSMS sending and receiving and case lost messages.

You may be able to pull the signal strength from web interface’s SMS Statistics menu.

Bryon

[Alex Warden]

Hallo,

is it possible to check Modem’s signal strength over http API or SNMP?
I know there is a way with telnet and AT+CSQ, but telnet queries fail if you build up and close telnet sessions too frequently (+CME ERROR: 3 for AT+CSQ).

Purpose:
We have several SF100-G devices (fw-Ver. 1.51.28) in use for alerting and we would like to check signal strength of each device before a SMS gets sent. Device with the best signal strength should then dispatch the sms.
Since sometimes there are several SMS within 10 secs, telnet is not the best solution for live-status checking of the signal strength.
(P.S. We use bash script and the iSMS-HTTP-Send-API for sending SMS.)

[Richard Lakomy]

I couldn’t find any documentation either but it can be accomplished with a quick and easy bash script:

token=curl -k "https://192.168.2.1/api/login?username=admin&password=admin" |grep token|cut -f4 -d\"`
curl -k -X POST -H "Content-Type: application/json" -d '{
"recipients":["15178765309"],
"message":"test messages are the best!!!!"
}' "https://192.168.2.1/api/sms/outbox/?token=$token"


• This reply was modified 8 years, 4 months ago by Richard Lakomy.
• This reply was modified 8 years, 4 months ago by Richard Lakomy.
• This reply was modified 8 years, 4 months ago by Richard Lakomy.

[Bryon Davis]

Hi Ernest,
Sorry, this currently isn’t possible on the iSMS. You will need to send a separate QUERY to retrieve the status of a SEND API request.

Bryon

[Ernest Masiala]

I know, after sending a message, we get an apimsgid and we should later send a Query API with this msgID too get the delivery status. I understand this logic is because of the time it takes to process the send and get the status back from the network.
But, can the iSMS automatically report the delivery status to our client application when available?

We don’t want to send 2 HTTP requests: SEND and QUERY. The idea would be to just send a HTTP SEND API request and get the msgId and just wait for iSMS to push the delivery status to our client as soon as it is available, without the need of sending a QUERY request.

How could we do that?

[Bryon Davis]

HI Oliver,
The receive API is covered in the Administrator’s Guide in Appendix A. Appendix A starts on page 73 and the Receive API info starts on page 94.

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

Bryon

[Oliver Schönbeck]

Hello,

is there any uptodate Documentation available for the iSMS Receive API?

Regards,
Oliver

[Florian]

Hi Byron,

Thanks for the reply.

For now i use the “Non Polling Mode Receive SMS API” by filtering with the phone number.

I admit it would have been easier for my use to change reply number.

[Bryon Davis]

Hi,
Sorry, it currently isn’t possible to set what the sending (reply) number is when sending through the API on the iSMS. The reply number will be the phone number associated with the SIM in the modem is was sent on. I’m not aware of a method to do this using AT commands either. Perhaps your cellular provider has options for making all the SIMs appear to be coming from the same number.

The iSMS doesn’t track conversations, so you can’t have it show a response to a specific message. If you are using the API, your software may be able to track conversations based on the phone number that the messages were sent and received from.
Bryon

[Florian]

Hi,

Is it possible to include a reply number when sending an SMS ? Through the API or using AT commands ?
For example, in my case i send SMS with number 123456 but i want to get the responses on the number 654321.

Or, is it possible to get the reply to a specific message ?

[Wouter Camps]

Bryon,

Thx for clearing out the exact nature of the fix.
All tmp files have already been deleted, it took a while, but luckily our other isms appliance didn’t suffer from the same problem so I didn’t have to do it twice. I guess the ‘boa-session-*’ files on our problematic isms where generated under special circumstances that never occured like that on the second one.

Kind regards,
Wouter

[Bryon Davis]

Hi Wouter,
The new firmware won’t clean up the existing ‘/usr/local/tmp’ files, but it should prevent new files from building up over time. To remove the existing ‘/usr/local/tmp’ files, you would need to follow the directions previously given and manually delete the files using a telnet session.

Sorry for the inconvenience.

Bryon

[Wouter Camps]

Hi Bryon,

I upgraded the gateway to the latest firmware as a part of my troubleshooting, but this didn’t seem to change anything about the number of ‘boa-session-*’ files already present in ‘/usr/local/tmp’. More than a day after the upgrade to firmware version 1.51.28, more than 78 000 files were still present in the tmp directory (after I’d already done a lot of manual deleting the previous day). In the end I deleted all ‘boa-session-*’ files manually. Can you confirm that the new firmware is supposed to avoid creating those files in the first place (or cleaning them up immediately) instead of just cleaning up older files like I presumed?

Wouter

[Bryon Davis]

Hi Wouter,
The newer firmware resolves this issue.

Please upgrade to the latest firmware from the link below. I’m including a link for SF100 for the convenience of others. The instructions for upgrading is included in the zip file.

SF100 v1.51.28:
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 v1.51.28:
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

[Wouter Camps]

Hi Bryon,

Thanks for your fast response, but because of the time zone difference I guess, it took more time than I wanted to waste (with no more backup device, failure of our second gateway would mean no more alerting at all and the ‘disk space like’ problem seemed a scenario that could also happen to our only remaining device). So I did a grep on ‘ssh’ and ‘telnet’ on the exported config of our other gateway and already figured out there was an open telnet port at 2222 like you said in your post. I logged in and noticed with df -k there was no disk space problem (‘/usr/local’) was only 14% full, but even so, I wasn’t able to make a new file in /usr/local/tmp using ‘touch’. I tried to ‘rm /usr/local/tmp/*’, but I got an error message, saying ‘sh: /bin/rm: Argument list too long’. ‘ls /usr/local/tmp/*’ also took very long and resulted in a huge huge number of files. I found some patterns to rm a lot of files at once (e.g. ‘rm boa-session-V3*’). Next, I retried to log in using the web interface, and this time I got past the login screen! So in the end, the problem didn’t seem to be the disk space, but the sheer number of files.

Can you tell me what we can do to avoid this problem in the future, because as I see it, it’s just a question of time before the number of files in /usr/local/tmp grows too big again and our gateway(s) will cease to function again. Is this firmware related (we’re currently at 1.50.7) and solved in a more recent software version? Or is there a way to clean ‘/usr/local/tmp’ on a regular basis by using some function in the webinterface? It seems there should be at least some sort of cron job in the appliance deleting ‘old’ tmp files after a while.