Forums d'entraide informatique - Astuces - Conseils

LE PROJET HOMESIP :
LA DOMOTIQUE AVEC LE
PROTOCOLE SIP

Patrice Kadionik, Maitre de Conférences a l'ENSEIPB (kadionik@enseirb.fr)
Cet article présente le projet HomeSIP. Il consiste à mettre en place une plate-forme domotique à l'ENSEIRB (École Nationale Supérieure d'Informatique Électronique et Radiocommunications de Bordeaux) mettant en œuvre le protocole SIP. Ce projet est par nature un projet orienté embarqué, composé de différents systèmes électroniques sous Linux embarqué.
Ce projet sera dans un premier temps décrit puis positionné dans le cadre plus général du « M2M » (Machine ta Machine). Une introduction sur le protocole SIP sera ensuite faite afin de bien cerner l'intérêt d'utiliser un tel protocole. La plate- forme matérielle actuelle et son évolution seront ensuite décrites ainsi que les développements logiciels associés mettant en oeuvre Linux.
PRÉSENTATION DU PROJET HOMESIP. LE M2M
HomeSIP est l'acronyme de « Home Automation with SIP ». Plus clairement, il s'agit d'un projet domotique basé sur la mise en oeuvre du protocole SIP (Session Initiation Protocol) utilisé généralement pour la téléphonie sur Internet VolP (Voice Over IP).
L'idée est donc d'utiliser SIP pour collecter des informations provenant de différents capteurs et de piloter aussi différents équipements (actionneurs).
Le projet HomeSIP consiste donc
•    En une infrastructure matérielle composée de capteurs et d'actionneurs connectés à des systèmes embarqués qui sont communicants et qui possèdent tous une connectivité IP'
•    À mettre en place les logiciels adéquats dans les systèmes
embarqués sous Linux
•    À développer des langages dédiés de type DSL (Domain
Specific Language) pour développer de nouveaux services autour de la plate-forme.
Le projet HomeSIP sera intégré au final à la plate-forme TellP (Téléphonie par IP) en exploitation à l'ENSEIRB.
La plate-forme TellP permet des communications VolP au sein de l'école, mais autorise aussi la passerelle vers le réseau téléphonique classique RTC (Réseau Téléphonique Commuté). TellP offre surtout des services intelligents développés à l'aide
d'un nouveau langage dédié de haut niveau. On peut citer comme services l'adaptation des pièces jointes ou d'un flux vidéo en fonction des capacités de son « périphérique SIP » (PC, PDA, téléphone...). Ce travail a été réalisé par l'équipe Phoenix du Labri (Laboratoire Bordelais de Recherche en Informatique).
HomeSIP est donc la continuité de TellP et l'interopérabilité entre les deux plateformes est totale car toutes deux basées sur le protocole SIP, protocole hautement interopérable.
Le projet HomeSIP est par nature un projet de domotique, la domotique étant en fait une composante du marché du M2M. Mais qu'est-ce que le M2M ?
Le M2M (Machine to Machine) est une infrastructure basée autour d'un réseau qui autorise des communications directement entre équipements ou via un serveur central sans aucune intervention humaine. Cela permet par exemple la capture automatique de données et leur traitement par les équipements après transmission.
Ce marché émergent est en fait l'évolution « naturelle » de la mise en place de la connectivité réseau et en particulier la connectivité IP dans les équipements électroniques.
Le marché du M2M s'appuie aussi sur les mutations technologiques opérées depuis quelques années, conséquence de l'inexorable loi de Moore
•    Les protocoles Internet sont des standards de fait.
Ils sont facilement intégrables dans les équipements électroniques
•    Les fonctionnalités électroniques sont toujours de plus
en plus intégrées
41■ Les matériels électroniques sont puissants et bon marché capteurs miniatures MEMS (Micro Electro Mechanical System), tags RFID (Radio Frequency ID)...
•    Le processeur 32 bits va devenir dans les années qui viennent le processeur de base dans l'embarqué et va être prépondérant en volume par rapport au processeur

8 ou 16 bits. C'est une condition nécessaire pour pouvoir mettre en oeuvre Linux
é    On dispose maintenant de connexions réseau permanentes à bas prix qui ne sont plus facturées à la durée : réseau ADSL, réseau GPRS...
é    Les connexions sans fil sont de plus en plus utilisées. Le coût d'installation est aussi intéressant car l'on minimise le câblage.
é    On dispose de standards, synonymes d'interopérabilité et de maîtrise des coûts : normes RFC pour les protocoles Internet, normes UIT (ADSL...), normes ETSI (GSM, GPRS), normes IEEE (Wifi, Zigbee)...
Le M2M correspond donc à la convergence électronique- informatique communicante et souvent par Internet. On parle d'Internet diffus ou ambiant (ubiquitous Internet) et d'informatique massivement répartie ou informatique diffuse (ubiquitous computing).
Selon le cabinet d'étude IDATE (http://www.idate.fr) qui a publié en juin 2005 une étude récente sur ce sujet, le marché du M2M se compte en milliards d'équipements électroniques et en centaines de milliards d'objets ou capteurs communicants.
Selon IDATE,92 millions de modules ont été vendus en 2004, quelle que soit la connectivité réseau choisie. Ce chiffre devrait atteindre 500 millions de modules d'ici 2010 pour 2 milliards de machines et de 100 milliards d'objets communicants.
Le M2M se développe autour d'industries verticales par secteur d'activité. On peut citer comme domaines d'application
é    La gestion de sites et de bâtiments, la domotique
é    La sécurité, la vidéosurveillance, la navigation...
é    Les transports, la gestion de flotte automobile
é    La télémesure, le relevé de compteurs
é    La gestion de l'énergie
•    La télémédecine
•    La monétique
•    Le commerce.
LE PROTOCOLE SIP
UNE PETITE INTRODUCTION
STRUCTURE GÉNÉRALE DU PROTOCOLE SIP
Le protocole SIP (Session Initiation Protocol) fait partie de la famille des protocoles Internet. Cela correspond en fait à plusieurs RFC (Request For Comments) disponibles en ligne sur http://rfc-editororg/
é    RFC 3261: SIP : Session Initiation Protocol.
é    RFC 3265 : Session Initiation Protocol (SIP)-Specific Event Notification.
•    RFC 3428 : Session Initiation Protocol (SIP)-Extension for Instant Messaging.
Le groupe de travail SIMPLE (S I P for Instant Messaging and Presence Leveraging Extensions) est aussi à considérer (http://www.ietf. org/html.charters/simple-charterhtml).
SIP est un protocole de signalisation de bout en bout permettant d'établir une session entre deux équipements pour un échange de données (ou d'un flux) par Internet. Il est le descendant des protocoles de signalisation plus classiques comme SS7 (Système de Signalisation numéro 7) de l'UIT-T (Union Internationale desTélécommunications) que l'on retrouve dans le RTC (Réseau Téléphonique Commuté), le RNIS (Réseau Numérique à Intégration de Services), le GSM... .,•'
Il s'en distingue radicalement par sa flexibilité et surtout par le fait qu'il n'est pas lié à un type de données à'échanger et encore moins à un type de réseau de transport.
Cette qualité est sa grande force. On petit l'utiliser pour mettre en relation 2 équipements pour tout type d'échange de données
é Voix sur IP. C'est l'échange de données le plus connu
é    Messagerie instantanée IM (Instant Messaging) é Vidéo ;
é Autres : indication de présence, notification d'événements...
S1P (dont la première version date de 1997 et la 'version courante date de juin 2002) possède aussi un concurrent, normalisé par l'UIT-T, la norme H.323 qui n'a pas su et pu s'imposer !
Les messages SIP peuvent être transportés par
•    Le protocole de transport UDP. C'est le cas le plus usuel.
•    Le protocole TCP.
é    Le protocoleTLS (Transport Layer Security, RFC 3546) utilisant SSL (Secure Socket Layer) sur TCP.
è    Le protocole SCTP (Stream Control Transport Protocol, RFC 2960).
La figure I donne le positionnement de SIP dans la constellation des protocoles Internet.
SIP reprend des éléments techniques des protocoles SMTP (Simple Mail Transport Protocol) et HTTP (Hyper Text Transport Protocol) ; ce qui veut dire que
é    SIP est basé sur le concept d'application client/serveur On a une application d'extrémité cliente qui désire se mettre
Fig. 1 : Positionnement du protocole SIP
parmi les protocoles Internet

DÉDIÉ    /1111
    Po'
   
en relation avec une application d'extrémité serveur. SIP possède un numéro de port réservé : le 5060 ;
•    SIP est un protocole de type commande/réponse. Ces commandes/réponses sont structurées sous forme de chaînes de caractèresASCII directement lisibles par l'humain et ressemblent étrangement à celles de HTTP (les codes d'état pour les réponses par exemple) ;
•    SIP possède un adressage pour identifier les applications SIP : c'est l'URI (Uniform Resource Identifier) comme on a l'URL (Uniform Resource Locator) pour HTTP. Un exemple d'URI est :sip:kadionik@enseirb.fr. Cela ne change pas trop d'une URL du type : http://www.enseirb.fr !
L'URI dans sa forme la plus générale s'écrit :
•    sip:username@hostname:port;paramètres?header ;
•    ou sips:username@hostname:port;paramètres?header (mode sécurisé).
INFRASTRUCTURE SIP
Diverses entités (équipements et/ou applications) sont mises en oeuvre par SIP :
•    L'agent utilisateur SIP (SIP UserAgent).0n distingue l'application cliente qui initie un appel SIP et émet une requête SIP (Client UA ou C-UA) et l'application serveur appelée (Server UA ou S-UA) qui répond à une requête SIP.
•    Le serveur de redirection (Redirect Server). Il aide à localiser un agent SIP ;
•    Le serveur d'enregistrement (Registra!. Server). Il enregistre la disponibilité d'un agent SIR II traite plus particulièrement le message SIP REGISTER.11 peut être intégré à un serveur proxy ;
•    Le serveur proxy (Proxy Server). Il agit comme un proxy HTTP;
•    Le serveur de localisation (Location Server). Ce n'est pas vraiment une entité mais plutôt une base de données utilisée par un serveur de redirection et/ou un serveur proxy.
La figure 2 donne un exemple d'infrastructure SIP.
MESSAGES SIP
En notation informaticienne ABNF (Augmented Backus Naur Form), un message SIP est soit une commande, soit une réponse :
SIP-message    = Request / Response
Une commande SIP est de la forme :
Request    = Request-Line
*( message-header )
CRLF
[ message-body ]
Request-Line    Method SP Request-URI SP SIP•Version CRLF
On retrouve ni plus ni moins la structure d'une commande HTTP.
Les méthodes autorisées sont :
•    REGISTER :message d'enregistrement d'un agent SIP à un Registrar Server ;
♦    INVITE : requête SIP pour établir une session entre 2 agents SIP ;
♦    CANCEL : message pour annuler la requête INVITE en cours ;
•    ACK :acquittement d'une requête INVITE ;
•    BYE :fin d'une session entre 2 agents SIP ;
•    SUBSCRIBE, NOTIFY : souscription et notification d'événements ;
•    MESSAGE :messagerie instantanée ;
•    Autres : REFER, OPTIONS, INFO.
Fig. 2 : Infrastructure SIP
SIP Location
Server
Serveur
DNS
SIP
User Agent
appelé
clip   
User Agent    -7-7»/4   
4
appelant
Session RTP pour échanger un
flux audio ou vidéo
DNS
SIP Registrar
SIP
Proxy SIP  sortant
SIP

Une réponse SIP est de la forme
Response    Status-Line
*( message-header )
CRLF
[ message-body ]
Status-Line    = SIP-Version SP Status-Code SP Reason-Phrase CRLF
On retrouve ni plus ni moins la structure d'une réponse HTTP. La figure 3 présente un enchaînement typique pour établir une communication VolP par SIR
Fig. 3: Echange de messages SIP pour une communication VolP
-
Plus précisément, voici un exemple de traces d'une requête SIP INVITE:
INVITE sip:laura@home.com SIP/2.0 Via: SIP/2.0/UDP pc11.work.com Max-Forwards: 70
To: Laura <sip:laura@home.com>
From: Bob <sip:bobUwork.com>:ta9=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob0pc11.work.com> Content-Type: application/sdp Content-Length: 131
v=0
o=Bob 289123451 289123451 IN IP4 111.22.33.44
s=Let us talk for a while
c=IN IP4 111.22.33.44
t=0 0
m=audio 20002 RTP/AVP 0
a=rtpmap:0 PCMU/8000
et d'une réponse SIP
SIP/2.0 200 OK
To: Laura <sip:laura@home.com>;tag=a6c85cf
From: Bob <sip:bob@work.com>:tag=1928301774
Cali-ID: a84b4c76e66710 CSeq: 314159 INVITE
Contact: <sip:laura0222.33.44.55>
Content-Type: application/sdp
Content-Length: 131
v=0
o4aura 289123444 289123444 IN IP4 222.33.44.55
s=Let us talk for a while c=IN IP4 222.33.44.55
t=0 0
m=audio 41002 RTP/AVP 0 ertpmap:0 PCMU/8000
Le corps d'une commande/réponse respecte le format MIME (Multipurpose Internet Mail Extensions) dont l'en-tête MIME est sur l'exemple
Content-Type: application/sdp Content-Length: 131
et le corps MIME
v=0
o=Laura 289123444 289123444 IN 1P4 222.33.44.55
On respecte dans le cas présent, le format SDP (Session Description Protocol) qui sert à décrire la session établie
•    Nom de la session
•    Paramètres des flux audio, vidéo... é Adresses IP et numéros de port à utiliser.
Sur l'exemple donné, on établit une session pour l'échange d'un flux audio en mode PCM 8kHz.
LE PROTOCOLE SIP ET LA DOMOTIQUE
ADÉQUATION DU PROTOCOLE SIP AVEC LA DOMOTIQUE
Le protocole SIP possède des qualités intrinsèques pour la domotique
é    II supporte un mode d'adressage abstrait ;
é    II apporte un niveau de confidentialité et de sécurité. Les données échangées peuvent être authentifiées et chiffrées
•    II supporte différents flux d'échange et différents mécanismes de communication
•    II supporte tout type de charge (payload) dans ses messages
en utilisant le format MIME
é    II peut s'interfacer à d'autres technologies domotiques via des passerelles : bus CAN (Control Area Network), courant porteur (norme domotique X 1 0)... ;
•    II supporte la mobilité ;
Bobai    Laura
Bob appelle Laura pour une session VolP
INVITE sip laura@home
180 Ringing
200 OK
ACK
Ca sonne
Laura
decroche
Bla bla bla
Bob raccroche
Bla bla bla
BYE
200- OK

DÉDIÉ    -.mea
         p.'
   
♦    Il réutilise l'infrastructure SIP classique.
En domotique, on distingue 2 types de transferts de données :
♦    Le transfert synchrone. Une donnée actuelle est acquise par une application, par exemple la valeur courante d'un capteur. On peut vouloir aussi réaliser une action, par exemple changer l'état courant d'un actionneur. Un capteur peut être un capteur de température, un actionneur, une gâchette électrique de porte. On doit pouvoir réaliser des actions « GET input » et « PUT output » ;
♦    Le transfert asynchrone. Une alarme est envoyée de façon asynchrone à une application en cas de survenue d'un problème quelconque. Un exemple d'alarme est la détection d'un début d'incendie.On doit pouvoir collecter des alarmes ou « TRAP ».
Que nous offre SIP pour cela ?Tout ce qu'il nous faut. Suivant les RFC 3261, 3265 et 3428, on peut utiliser :
•    Le message SIP MESSAGE  pour des actions PUT ou GET.Ce message a été originellement introduit pour la messagerie instantanée (RFC 3428) ;
•    Les messages SIP SUBSCRI BE et NOTI FY les événements de type TRAP. Ces messages sont originellement utilisés pour la notification de présence (RFC 3265).
SIP VS SNMP
Le protocole SNMP (Simple Network Management Protocol) a été présenté dans le magazine Linux Magazine numéro 43 d'octobre 2002 ainsi que sa mise en oeuvre pour le contrôle par Internet de systèmes électroniques.
SNMP offre les mêmes possibilités d'échange que SIP dans un contexte domotique. Il possède :
♦    Les messages SNMP PUT et GET pour des actions PUT et GET;
♦    Le message SNMP TRAP les événements de type TRAP.
Mais, SNMP par rapport à SIP possède des défauts majeurs :
♦    SNMP est un protocole complexe malgré son nom ;
♦    Il est difficile à utiliser. L'extension d'un agent SNMP est compliquée ;
♦    SNMP n'est pas un protocole très sécurisé surtout dans sa version I ;
♦    Un agent SNMP n'a pas une empreinte mémoire faible, ce qui est un handicap pour un système embarqué avec peu de mémoire ;
♦    II n'y a pas d'applications clientes populaires. SIP en a de nombreuses (g a i m par exemple).
ÇO-SIP
Réseau de capteurs
Vidéosurveillance - Contrôle d'accès
1%r Passerelle ré de vidéosurvei
Fig. 4 : Plate forme matérielle HomeSIP

Le protocole SIP s'impose de lui-même dans un contexte domotique et de convergence électronique-informatique- réseaux.
HOMESIP •
PLATE-FORME MATERIELLE
La plate-forme matérielle HomeSIP est présentée figure 4. Elle se greffe sur la plate-forme SIP actuelle de l'ENSEIRB. Les périphériques SIP utilisés sont des PC, des téléphones SIP ainsi que des PDA.
Seules, deux passerelles SIP/réseau de capteurs sont actuellement déployées et les développements logiciels sont en cours.
Il est prévu à terme d'intégrer les passerelles SIP/X10 pour la commande d'appareils électriques et les passerelles SIP/ réseau de surveillance...
Le réseau Ethernet de l'ENSEIRB sert d'ossature à la plate- forme HomeSIP
Revenons à la passerelle SIP/réseau de capteurs. Cette passerelle est composée de matériels du commerce pour ne pas avoir de développements hardware à réaliser. Elle se compose
•    D'une carte ARM9 d'Eukréa. Cette carte est présentée en détail dans l'article d'Eric Benard. Son grand avantage est qu'elle supporte bien sûr Linux, mais qu'elle possède de nombreuses E/S pour pouvoir connecter différents capteurs et actionneurs : liaisons série, bus I2C, E/S, bus USB... La carte possède aussi une interface réseau pour pouvoir remplir son rôle de passerelle.
•    De capteurs de température iButton® DSI920 de Dallas Semiconductor avec une interface pour les connecter à une liaison série. L'interface de pilotage d'un iButton® étant standard, il est possible d'en rajouter d'autres...
HOMESIP :
DÉVELOPPEMENTS LOGICIELS
Les développements logiciels s'articulent actuellement autour de la passerelle SIP/réseau de capteurs.
Il convient pour cela de
•    Porter Linux sur la carte cible ARM9. Cela a déjà été fait par Eukréa
•    Trouver une pile SIP à faible empreinte mémoire et la porter sur la carte cible. A défaut, il faut développer une pile SIP
•    Développer les applications Linux embarqué pour piloter
les capteurs de température connectés à la carte cible.
PORTAGE D'UNE PILE SIP POUR LA PASSERELLE
Il existe différentes piles SIP libres que l'on peut utiliser sachant qu'il convient de privilégier celles qui sont développées en langage C ou C++. Après différents tests, le choix s'est porté sur la pile GNU oS I P et son extension eXos p développées par Aymeric Moizard.
La pile oSIP étant écrite en langage C, elle est fortement portable et à faible empreinte mémoire. eXosi p est une bibliothèque de fonctions (Application Programming Interface) basée sur oS I P pour faciliter l'écriture des applications SIP. L'API eXosi p a bien sûr été privilégiée ici.
Le PC hôte est sous Linux Fedora Core 4. Son nom est
host !
La cible est sous Linux embarqué. C'est la passerelle SIP/ réseaux de capteurs. Son nom est a rm0 1 !
Après installation du compilateur croisé GNU C/C++ gcc
pour processeur ARM fourni par Eukréa, le et d'eXosi p est alors possible...            portage d'oS I P
Environnement de travail           
$ cd           
$ pwd           
/home/guest           
$    cd    arm           
$    ls    iButton    1ibeXosip2-2.2.2.tar.gz    libosip2-   
goarm_eXosip           
2.2.2.tar.gz goarm_osip    src       
Décompression d'oSIP et d'eXosi p
$ tar -xvzf libosip2-2.2.2.tar.gz $ ln -s libosip2-2.2.2 libosip    libosip    SrC
$ tar -xvzf libeXosip2-2.2.2.tar.gz $ ln -s libeXosip2-2.2.2 libeXosip $ ls    libosip2-2.2.2 libosip2-2.2.2.tar.gz   
goarm_eXosip libeXosip       
goarm_osip    1ibeXosip2-2.2.2       
iButton    libeXosip2-2.2.2.tar.gz       
Compilation croisée pour processeur ARM9 d'o Si
r :
$ cat ./goarm_osip
cd ./libosip
CC=arm-linux-gcc CFLAGS=-02 ./configure --prefix=$HOME/arm --disable-trace --disable-debug --host=arm-linux
make
make install
$./goarm_osip bla bla bla...
Compilation croisée pour processeur ARM9 d'e Xosip
$ cat ./goarm_eXosip
cd ./libeXosip
CC=arm-linux-gcc CFLAGS=-02 ./configure --disable-josua --prefix=$HOME/arm --disable-trace --disable-debug --host=arm-linux
make
cake install
$ ./goarm_eXosip
bla bla bla...
On a au final les bibliothèques oSI P et eXosi p pour la cible et les fichiers i n cl ude pour la compilation croisée de nos applications Linux embarqué
$ ls
bin    iButton libeXosip    libosip    man
goarm_eXosip include libeXosip2-2.2.2    libosip2-2.2.2    src
goarm_osip    lib    libeXosip2-2.2.2.tar.gz libosip2-2.2.2.tar.gz

DÉDIÉ   
   
Installation des bibliothèques °SI P et eXosip sur la cible a rm01 en utilisant un montage NFS du répertoire de travail du PC host depuis la cible arm01 :
Côté host :
$ /usr/sbin/exportfs
/home/guest    arm01
/home/guest    arm02
Côté arm01 :
# mount -t nfs host:/home/guest /mnt
# cd /mnt
# ls
CPUAT91    HomeSIP    bin    iButton    src
Desktop    arm    doc    packages
# cp -r /mnt/arm/lib /
// release the 1-Wire Net owRelease(portnum); exit(1);
1
owRelease(portnum); exit(0);
L'application temp c est cross-compilée pour la cible a rm0.1 pour donner l'exécutable gettemp_ds1920 :
cat ./go_ds1920
make temp LINKFILE.linuxlnk.o CC.arm-linux-gcc mv ./temp gettemp_ds1920
$ ./go_ds1920
bla bla bla...
#include <stdlib.h> #include <stdio.h> #include "ownet.h" #include "templO.h" #include "findtype.h"
    #define MAXDEVICES    2
// global serial numbers
uchar FamilySN[MAXDEVICES][8]; int family_code;
int main(int argc, char **argv)
float current_temp; int i    0;
int NumDevices.0; int portnum    0;
// check for required port none
if (argc != 2) {
printf("Error. Syntax: ./gettemp_ds1920 /devatySx\n"); exit(1);
// attempt to acquire the 1-Wire Net if((portnum    owAcquireEx(argv[1])) < 0)
exit(1);
// Find the device(s)
NumDevices    FindDevices(portnum, gamilySN[0], 0x10,
MAXDEVICES);
// read the temperature and print serial number and temperature for (i = 0; i < NumDevices; i++) {
if (ReadTemperature(portnum, FamilySN[i],kurrent_temp)) { PrintSerialNum(FamilySN[i]);
    printf("    %5.1f \n", current_temp);
}
else {
    printf("    Error reading temperature, verify device
present: \n");
CONTRÔLE DES CAPTEURS DE LA PASSERELLE
Pour les capteurs, on met en oeuvre ici les capteurs de température iButton® DS 1920. Dallas Semiconductor fournit une bibliothèque libre de fonctions C pour piloter ces capteurs à partir d'un port série moyennant l'usage d'un adapteur bus 1-VVireCi/liaison série (DS9097U-S09) :
Décompression de la bibliothèque pour le DS 1920 :
$ cd iButton
$ unzip ulinuxgnu300.zip
L'application temp . c fournie est modifiée comme suit pour son utilisation sur la cible a rm01 :
L'application Linux embarquée gettemp_ds1920 est copiée sur la cible a rm01 puis testée :
# cp /mnt/arm/iButton/gettemp_ds1920 . # ./gettemp_ds1920 /dev/ttyS2
6B000800BC7BAF10    25.1
# echo S?
0
EXEMPLE 1 : MISE EN CEUVRE DU MESSAGE SIP MESSAGE
Le premier exemple de mise en oeuvre du protocole SIP est l'envoi périodique de la température mesurée par le capteur DSI920. C'est un exemple basique basé sur l'utilisation du message SIP MESSAGE.Un agent SIP send_i m embarqué sur la cible d rm01 envoie un message instantané vers un agent SIP du PC hôte. On utilisera pour cela l'agent SIP gai m côté PC mais aussi l'agent josua fourni avec oSI P. Cela correspond à la première méthode pour récupérer des informations en provenance de capteurs par SIP.
Le code source de l'application send_i m. c est le suivant :
#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <netdb.h> #include <syslog.h> #include <pthread.h> #include <eXosip2/eXosip.h>
main (int argc, char *argv[])
char buf[256];
osip_message_t *message; int i;
eXosip_event_t *event; int port    5060;
// For trace
// osip_trace_initialize(6, stdout);
if(argc I. 4) {
printf("send_message from(sip:root@target) to(sip: root@host) info\n");
exit(-1);
1
if (eXosip_init (1) {
printf("eXosip_init failed\n"); exit (1);
i = eXosip_listen_addr (IPPROTO_UDP, NULL, port, AF_INET, 0); if ri!=0) {

EXEMPLE 2 : MISE EN CEUVRE DES MESSAGES SIP SUBSCRIBE/NOTIFY
Ce dernier exemple de mise en ceuvre du protocole SIP est l'envoi périodique de la température mesurée par le capteur après souscription. C'est un exemple basé sur l'utilisation du couple de messages SIP SUBSCR I BE/NOT I FY. Un agent SIP s'inscrit (SUBSC R I BE) auprès de la passerelle pour recevoir pendant une durée déterminée la valeur courante du capteur de température. La passerelle lui renvoie durant toute la durée de souscription la valeur courante de la température (NOT I FY). Une application send_not i fy embarquée sur la cible a rm0 1 envoie l'information température à une application agent SIP send_s ub sc ri be du PC host. L'exemple étant plus compliqué que le précédent, on pourra récupérer les fichiers sources à l'adresse donnée dans la bibliographie. L'échange de messages SIP doit être celui de la figure 9. L'outil Ethereal nous fournit les traces des échanges de messages SIP de la figure 10 ; ce qui est bien conforme à ce qui est attendu. La réponse 101 (Diolog Etablishement) est informationnelle et facultative.
CONCLUSION
A travers cet article, nous avons pu voir la mise en oeuvre du protocole SIP pour le pilotage de capteurs. La plate-forme HomeSIP a été aussi décrite ainsi que les objectifs attendus. Des exemples pratiques ont été proposés et testés afin de démontrer la mise en application du concept. Lancé début 2006, le projet HomeSIP en est à ses débuts et il reste  beaucoup de choses à faire comme l'intégration des autres passerelles du point de vue matériel, le développement des applications embarquées, la structuration des échanges en utilisant XML par exemple et enfin le développement d'un langage de type DSL pour spécifier et créer des services SIP pour la domotique. Pour terminer, il est toujours étonnant et « magique » de constater la facilité d'intégration de Logiciels libres sans perte de temps dans un projet Linux ou Linux embarqué !