Last modified: Jun 13, 2006 by Kachelhoffer

CC: sending alarm by SMS from Computing Center


 1   Introduction
 2   Presentation of the service
    2.1   Generalities
    2.2   Working principle
 3   Limitations and usage control
    3.1   Limitations on the sms body
    3.2   Quotas on sending sms
    3.3   Access control
 4   Communication protocol with the smsd server
    4.1   Generalities
    4.2   Command for a non registered client
         4.2.1   Command for the client: ENRegistre toto
         4.2.2   Command for the client: DECconnection
         4.2.3   Commane for the client: xxx
    4.3   Commands for a registered client
         4.3.1   Commande for the client: SMS 06xxxxxxxx sms body
         4.3.2   Command for the client: DEConnection
         4.3.3   Commande for the client: xxx
    4.4   Example

1. Introduction

This article describes the way to use the Sms sending service provides by the Computer Center: this service allows experiments which want to, to send alarm messages from their own survey applications by sms technology.

2. Presentation of the service

2.1. Generalities

The Compiter Center provides a service to send alarm messages by sms technology. This service allows experiments which want to, to send alarm from their own servey applications. Sendind an sms alarm allows to notify rapidly a technical staff outside normal working hours in order to have a remote action. The sms are send through a gsm modem linked on a dedicated computer inside the center. The good progress of the sms depends on:

2.2. Working principle

To send a sms, a client application should send a request to the sms sending computer. For that, it should open a socket with the dedicated port of the server and to send the request on this socket, having regard on the protocol detailed further. A short C module, available on demand, can be a first example and provides functions allowing following steps:

3. Limitations and usage control

3.1. Limitations on the sms body

Due to the sms protocol standard and the technical solution chosen, the sms body should respect following limitations:

3.2. Quotas on sending sms

To prevent from an application becoming crazy or a misuse (the sms are invoiced to Computer Center by unit), some quotas have been deployed. These sms sending quotas are put by experiment and also globaly at the server level. These quotas are from 3 types: per hour, per day, per month. For example, it could be like:When a quotas is reached, the sms are rejected (until the quota is reset to zero by going to the next hour, day, month). Some informations are kept at the server level to be used as necessary: the whole sms sended (issuer experiment, phone number, sms body, sending hour) and the monthly number of sending sms per experiment. Note that no private informations could be send in the sms body.

3.3. Access control

In order to secure and improve the control on the use of the sms sending server, each experiment sould be, as a preliminary, be registered at the server level. An experiment will be distinguished by its name. After that, the experiment will be authorized to make sms sending requests from a limited number of IP address. These IP address should also be registered. It can be individual IP address or a whole subnet. You should also ask the Computer Center to open some filters at the network level. Take care that the number of clients simultaneously connected to the server is also limited, especially for a same experiment (5 for example).

4. Communication protocol with the smsd server

4.1. Generalities

Here are two tables discribing the dial protocol between smsd and the client. The commands and the return messages follow the next rules:The dial with the smsd server is made in 3 steps:

4.2. Command for a non registered client

4.2.1. Command for the client: ENRegistre toto

return from smsdcomments
EOK: enregistrement correcttoto is the name of the experiment
EPB: INC: commande incompleteif no experiment name given
EPB: SIM: trop de connections simultaneesif the maximum number of simultaneously connections is reached for this client
EPB: AUT: client non autoriseif the client name is not authorized to use smsd
EPB: AIP: adresse IP non autoriseeif the IP address is not in the list of those authorized for this client

4.2.2. Command for the client: DECconnection

These command perform a properly deconnection to the server.

4.2.3. Commane for the client: xxx

return from smsdcomments
INV : commande invalide (client non enregistre)all other commands than "enregistre" is refused

4.3. Commands for a registered client

4.3.1. Commande for the client: SMS 06xxxxxxxx sms body

return from smsdcomments
SOK: sms a envoyer bien recu06xxxxxxxx: recepient gsm phone number. The sms body should not have cariage return.
SPB: INC: commande incompletesome arguments are not there
SPB: NUM: numero non valideto be valid, the phone number in France should have 10 numbers and begin with "06"
SPB: COR: corps du sms non valideif the sms body is too long or have non authorized characters
SRE: DJA: sms deja envoyeif the same sms is still sended to the same recipient less than 1 hour before
SRE: QTA: quota depasseif the quota (hourly, daily, monthly) for the experiment is reached
SRE: SAT: serveur satureif the overall quota (hourly, daily, monthly) for the server is reached
SRE: MOD: modem indisponibleif there is no gsm modem connected to the server

4.3.2. Command for the client: DEConnection

These command perform a properly deconnection to the server.

4.3.3. Commande for the client: xxx

return from smsdcomments
INC: commande inconnuefor all other commands
Note 1: It is possible to specify the recipient phone number like +336xxxxxxxx for France.

Note 2: The client will be automatically disconnect from the server in next cases:

4.4. Example

For example, the complete process to send an sms is:
client commandsmsd return
ENRegistre totoEOK: enregistrement correct
SMS 0601020304 alarme truc muche biduleSOK: sms envoyer bien recu
DECconnection