1 Année 20052006 GIL Mathieu Electronique 3 année CHANTIT

Document Sample
1 Année 20052006 GIL Mathieu Electronique 3 année CHANTIT Powered By Docstoc
					Année 2005/2006               GIL Mathieu
Electronique 3ème année       CHANTIT Yacin
Systèmes embarqués            DUBOURG J-H


                          1
                                   TABLE DES MATIERES




INTRODUCTION............................................................................................................... 3


1.      Présentation du protocole SIP ................................................................................ 4
     1.1.      Choix de la librairie pour développer l’application ................................................... 4
     1.2.      Qu’est ce que le Libre Logiciel ? ............................................................................... 6
     1.3.      Avantages du Libre Logiciel ...................................................................................... 6


2.      Principe de communication et de contrôle de session .................................... 7
     2.1.      Syntaxe des messages................................................................................................. 7
     2.2.      Signalisation simple ................................................................................................... 9


3.      Application à notre système................................................................................... 10
     3.1.    La requête “SUBSCRIBE”.................................................................................... 11
        3.1.1.   Initialisation...................................................................................................... 11
        3.1.2.   Envoi de la requête “Subscribe”....................................................................... 11
        3.1.3.   Réception de la réponse.................................................................................... 12

     3.2.    La requête “NOTIFY”........................................................................................... 14
        3.2.1.   Initialisation...................................................................................................... 14
        3.2.2.   Lancement de l’écoute ..................................................................................... 14
        3.2.3.   Réception d’une requête................................................................................... 15
        3.2.4.   Envoi de la requête “Notify”............................................................................ 16


4.      Validation de l’application ..................................................................................... 18
     4.1.      Environnement de travail ......................................................................................... 18
     4.2.      Test du système ........................................................................................................ 18


CONCLUSION .................................................................................................................. 21



                                                                    2
                              INTRODUCTION



Notre projet consiste à recueillir une température à distance à l’aide d’une communication IP.
Pour cela nous disposons d’un microprocesseur ARM contenant un noyau linux embarqué,
auquel est implémenté un serveur, et qui est relié à un capteur de température “iButton” ainsi
qu’à Internet.
Ainsi, le client envoi une requête au serveur à partir d’un ordinateur quelconque relié à
Internet également. Celui-ci interroge le capteur pour recueillir la température, puis envoi le
résultat au client.




Schéma de principe :




                          Figure 1. Schéma de principe du système




Nous avons réalisé cette communication avec le protocole SIP (Session Initiation Protocol)
que nous allons décrire dans la partie suivante.




                                              3
1. Présentation du protocole SIP

Le protocole SIP (Session Initiation Protocol) est normalisé et standardisé par l'IETF (décrit
par le RFC 3261 qui rend obsolète le RFC 2543) qui a été conçu pour établir, modifier et
terminer des sessions multimédias. Il se charge de l'authentification et de la localisation des
multiples participants, mais également de la négociation sur les types de média utilisables par
les différents participants en encapsulant des messages SDP (Session Description Protocol).

SIP ne transporte pas les données échangées durant la session comme la voix ou la vidéo. Le
protocole étant indépendant de la transmission des données, tout type de données et de
protocoles peut être utilisé pour cet échange. Cependant le protocole RTP (Real-time
Transport Protocol) assure le plus souvent les sessions audio et vidéo. SIP remplace
progressivement H323.

SIP est le standard ouvert de VoIP (Voice Over IP, voix sur IP) interopérable le plus étendu et
vise à devenir LE standard des télécommunications multimédia (son, image, etc). Il n'est donc
pas seulement destiné à la voix sur IP, mais à d’autres applications telles que la visiophonie,
la messagerie instantanée, etc.

SIP permet l’interaction entre des éléments grâce aux messages de signalisation. Ces derniers
peuvent être utilisés pour différentes fonctions :

     – Enregistrer un utilisateur avec le système.
     – Inviter un utilisateur à établir une session interactive.
     – Négocier les limites et les conditions de session.
     – Etablir un canal de média entre deux bouts ou plus.
     – Terminer la session.




        1.1. Choix de la librairie pour développer l’application


Il existe un certain nombre de librairies différentes permettant d’implémenter le protocole
SIP, qui sont décrites dans le tableau de la page suivante :




                                                 4
                 Sofia-SIP     oSIP i.e.                   reSIProcate SipX         Opal      Vocal

VxWorks port     Non           Oui                         Non             Non      Oui       Non
Win32 port       prochainement Oui                         Oui             Oui      Oui       Non
Linux port       Oui           Oui                         Oui             Oui      Oui       Oui

RFC 3261         Oui           Oui                         Oui             Oui      Oui       Partiellement
RFC       2327
(SDP)            Oui           Oui                         Oui             Oui      Oui       Oui
RFC 3264 (O/A)   Oui           Oui                         Oui             Oui      Oui       ?
RFC 3263 (SIP
DNS)             Oui           Par l’application           Partiellement   Oui      Non       ?
RFC       3515
(REFER)          Oui           Oui                         Oui             Oui      Oui       Oui
RFC       3262
(100rel)         Oui           Non                         Non             Non      Non       ?
RFC       3311
(UPDATE)         Oui           Oui                         Non             Non      Non       ?

TCP              Oui           Transport indépendant       Oui             Oui       Oui
UDP              Oui           Transport indépendant       Oui             Oui       Oui
TLS              Oui           Transport indépendant       Oui             Pas testé Non

Taille           < 500 kB      < 400 kB                    < 2,5 MB        < 4 MB   Important Important
Licence          LGPL          LGPL                        Vovida          LGPL               Vovida

ACK              Oui           Oui                         Oui
BYE              Oui           Oui                         Oui
CANCEL           Oui           Oui                         Oui
INFO             Oui           Oui                         Oui
INVITE           Oui           Oui                         Oui
MESSAGE          Oui           Oui                         Oui
NOTIFY           Oui           Oui                         Oui
OPTIONS          Oui           Oui                         Oui
PRACK            Oui           Oui                         Oui
PYBLISH          Oui           Oui                         Oui
REFER            Oui           Oui                         Oui
REGISTER         Oui           Oui                         Oui
SUBSCRIBE        Oui           Oui                         Oui
UPDATE           Oui           Oui                         Oui



                        Figure 2. Tableau comparatif des différentes librairies SIP


      La pile Osip présente les avantages d’avoir une faible taille et de disposer de nombreuses
      fonctionnalités.
      Etant donné que la taille est un critère déterminant pour les systèmes embarqués, nous avons
      choisis cette librairie.
      On peut également noter que la pile Osip est un logiciel libre.


                                                       5
        1.2. Qu'est-ce que le Libre Logiciel ?

Le Libre Logiciel ("Free Software" en anglais) est le mouvement pour le développement et la
diffusion de logiciels libres, c'est à dire librement et intégralement disponibles, avec leurs
sources et le droit de les modifier et de les redistribuer. Il s'oppose en cela à la propriété
intellectuelle en informatique, qui prône le développement de logiciels exclusifs ("proprietary
software" en anglais, aussi parfois appelé logiciel propriétaire en français), qui ne sont
disponibles que dans une version immédiatement exécutable dans un environnement restreint,
sans possibilité d'inspecter ou de modifier les sources, ni de redistribuer quoi que ce soit.

Les sources sont l'essence des logiciels : plus que les plans du logiciel, ils sont le logiciel
même. Un logiciel distribué sous forme d'exécutable sans les sources n'en est qu'un extrait très
partiel, d'usage limité.

Le Libre Logiciel impose tout de même des contraintes sur les modifications, qui relèvent du
respect des utilisateurs autant que des auteurs. Les auteurs originaux doivent être bien
identifiés, ainsi que le logiciel original ; l'auteur des modifications et la nature des
modifications doit l’être également. Les auteurs originaux et le logiciel original ne sauraient
être cités ou au contraire être délaissés contre leur gré au cours de promotion d'un logiciel ;
l'amalgame de leur image avec celle d'un produit différent doit être puni.



        1.3. Avantages du Libre Logiciel


   •   Pour l'utilisateur de logiciel, le Libre Logiciel est gage de qualité : du fait de la
       visibilité des sources, tous les bogues et trous de sécurité deviennent apparents, et
       donc corrigibles.
   •   Pour l'utilisateur de logiciel, le Libre Logiciel est garantie de flexibilité : les sources
       modifiables permettent d'adapter le logiciel très exactement aux besoins de
       l'utilisateur, plutôt que de requérir que l'utilisateur s'adapte aux déficiences du logiciel.
   •   Pour l'utilisateur de logiciel, le Libre Logiciel est gage de pérennité des programmes et
       des données.
   •   Pour l'utilisateur de logiciel, le Libre Logiciel assure une documentation et une
       assistance technique de qualité à prix raisonnable, de par l'existence d'un libre marché
       plutôt que d'un monopole.
   •   Pour le programmeur, le Libre Logiciel, s'il est universel, est gage qu'il ne sera pas
       désavantagé par une concurrence biaisée en faveur de gros éditeurs.
   •   Pour l'administrateur, le Libre Logiciel est la garantie qu'il pourra travailler en
       collaboration avec des programmeurs compétents et à son écoute, plutôt que d'être
       attaché à des programmeurs par la barrière d'entrée du coût de leur formation à des
       logiciels propriétaires et douteux, et la barrière de sortie de la peur qu'il ne divulgue
       les "secrets" liés à cette appropriation.




                                                6
2. Principe de communication et de contrôle de session


       2.1 Syntaxe des messages


Les messages SIP sont codés en utilisant la syntaxe de message HTTP/1.1 (RFC2068).
Il existe deux types de message : les requêtes et les réponses.

Leur structure est présentée ci-dessous :




                             Figure 3. Structure d’un message SIP


Certains champs d’en-têtes sont toujours présents dans les requêtes et les réponses, et forment
l’en-tête général :


 Call-ID        : ce champ d’en-tête contient un identificateur globalement unique pour
                un appel.
 Cseq           : c’est un identificateur qui sert à rapprocher.
 From           : il identifie l’appelant et doit être présent dans toutes les requêtes et les
                réponses.
 To             : il indique la destination et doit être présent dans toutes les requêtes. Il
                est simplement recopié dans les réponses.
 Via            : il est utilisé pour enregistrer la route d’une requête, de manière à
                permettre aux serveurs SIP intermédiaires de faire suivre un chemin
                exactement inverse aux réponses.
 Encryption     : champ d’en-tête qui spécifie que le corps du message et éventuellement
                certains en-têtes ont été chiffrés.
 Content-Type   : champ d’en-tête qui décrit le type de média contenu dans le corps du
                message.
 Content-Length : nombre d’octets du corps du message.
 Content-Bodie : corps du message.




                                              7
Les messages de requêtes sont envoyés d’un client SIP à un serveur SIP :

• INVITE    : Inviter un utilisateur pour un appel
• ACK       : Message d’acquittement du message INVITE
• BYE       : Fin de communication ou refus d’un appel.
• CANCEL    : Fin d’une requête ou recherche un utilisateur.
• INFO      : Information de session en cours.
• OPTION    : Demander d’informations sur le serveur.
• REGISTRER : Enregistrement de la position d’un utilisateur.
• MESSAGE   : Permettre l'envoi de messages instantanés
• NOTIFY    : Envoyer des notifications d'événements.
• PRACK     : implémente le mécanisme spécial de sécurisation des réponses provisoires.
• PREFER    : permet la redirection d'appels.
• SUSCRIBE  : demande une notification d'événements.
• UPDATE



Le format des requêtes SIP :




                               Figure 4. Allure d’une requête SIP


Un serveur SIP répond à une requête SIP au moyen d’une ou plusieurs réponses.
Celles-ci, dont les codes sont de la forme 2xx, 3xx, 4xx, 5xx et 6xx, sont des réponses finales
et terminent la transaction courante. Celles dont la forme est 1xx sont des réponses provisoires
et ne terminent pas la transaction courante.

         1xx – Message d’information.
         2xx – Message de succès.
         3xx – Message de redirection.
         4xx – Message d’erreur sur le client.
         5xx – Message d’erreur sur le serveur.
         6xx – Destination occupée, non accessible ou refusant la communication.


                                               8
Le format des réponses SIP :




                           Figure 5. Allure d’une réponse SIP


       2.2 Signalisation simple
Pour établir un appel simple entre deux agents, on utilise seulement 3 requêtes : INVITE,
ACK, BYE auxquelles on obtient 3 réponses.




                        Figure 6. Protocole de communication SIP




                                           9
Exemple de contenu d’un message “INVITE” :

INVITE             :   sip:john@192.168.106.179 SIP/2.0
From               :   Mark <sip:mark@192.168.106.189>
To                 :   John <sip:john@192.168.106.179>
Via                :   SIP/2.0/UDP 131.215.131.131, SIP/2.0 foo.com
Call-ID            :   3678134014
Content-Type       :   application/sdp
Content-Length     :   187
CSeq               :   8348 INVITE
Subject            :   New error codes
                       v=0
                       c=IN
                       IP4 128.59.16.191
                       m=audio 1848 RTP/AVP 0


3. Application à notre système

La communication entre l’ordinateur et le système est établie à l’aide des requêtes
“SUBSCRIBE” et “NOTIFY”, que nous décrivons ci-dessous.
Pour la programmation de ces requêtes, nous utilisons la bibliothèque eXosip2 qui présente
une API de programmation de haut niveau du protocole SIP.




                 Figure 7. Communication SUBSCRIBE/NOTIFY
                                          10
       3.1 La requête “SUBSCRIBE”
Le client interroge tout d’abord le serveur au moyen d’une requête SUBSCRIBE.
Si celle-ci est acceptée, le serveur en retourne le message “200 OK” et une communication est
établie pendant une durée déterminée par le champ “EXPIRE ” contenu dans le “Subscribe”.
Pour la programmation de cette requête “Subscribe” nous utilisons la bibliothèque eXosip2
qui présente une API de programmation de haut niveau du protocole SIP.

NB     : il est à noter que les codes détaillés par la suite ne contiennent pas la déclaration des
         variables utilisées afin d’alléger le document, mais une version complète de ces
         programmes se trouve en annexe.


3.1.1 Initialisation

Au lancement du programme gérant le “Subscribe”, il faut tout d’abord initialiser le contexte,
c'est-à-dire la pile Osip, puis préciser le protocole utilisé pour le transport.
Nous utilisons ainsi le protocole UDP (car il n y a pas de version de eXosip utilisant TCP)
avec le port 5000, qui est réservé au protocole SIP.

Le code correspondant à l’initialisation est présenté ci-dessous :




3.1.2 Envoi de la requête “Subscribe”

Une fois les conditions de communication établies, il faut construire la requête en indiquant
l’adresse IP du microprocesseur, celle de l’ordinateur client, le type de “Notify” que l’on veut
(car il en existe 3 différents en fait et nous avons choisit un “Notify” de type “presence”), puis
le durée de la communication. Pour cela, nous utilisons une fonction de la librairie qui va
placer ces différents éléments dans une structure adaptée. Ensuite, on place le message à
envoyer dans le corps de la requête, qui est “La température est de x”, puis on précise le type
de message envoyé, qui dans notre cas est “text/plain”. Il ne reste alors plus qu’à envoyer le
tout au serveur.


                                               11
La procédure d’envoi de requête SIP est assez simple avec la bibliothèque eXosip2.
Les différentes étapes sont les suivantes :

       1- On construit le message qu’on veut envoyer.
       2- On verrouille les ressources d’eXosip2 car on ne peut envoyer qu’un seul message
          à la fois (cas de plusieurs User Agent en concurrence).
       3- On envoi le message.
       4- On déverrouille les ressources.



Le code est le suivant :




3.1.3 Réception de la réponse

Une fois la requête envoyée, on lance une boucle infinie qui va durer tout le temps de la
communication, puis on attend une réponse que l’on traite suivant le cas.
En principe, le serveur envoi en premier lieu un “200 OK”, puis ensuite le “Notify”
comportant la température dans le “corps” de la requête (il s’agit du “case” :
EXOSIP_SUBSCRIPTION_NOTIFY). On affiche alors le résultat à l’écran.
On peut voir le déroulement de la communication à la page 19.

Le code se trouve à la page suivante.




                                             12
13
       3.2 La requête “NOTIFY”
Une requête de notification est émise par un système auquel on demande des informations à
travers une souscription.
Ainsi, le serveur va envoyer des requêtes de notifications comportant les informations à une
certaine fréquence pendant la durée annoncée par le client.


3.2.1 Initialisation de eXosip2

Tout comme pour le “Subscribe”, il faut initialiser le contexte en premier lieu. On utilise donc
également le protocole UDP avec le port 5000.

Le code correspondant à l’initialisation est présenté ci-dessous :




3.2.2 Lancement de l’écoute

Une fois le contexte de fonctionnement initialisé, on peut “lancer” l’écoute. Celle-ci se
caractérise par une boucle infinie avec l’attente d’un évènement, qui dans notre cas est une
requête “Subscribe”. Cette dernière peut être :

       - soit une nouvelle requête de “Subscribe”
       - soit une demande de mise à jour d’un “Subscribe”




Le code correspondant à cette partie se trouve à la page suivante :




                                               14
3.2.3 Réception d’une requête

Une fois le corps du programme conçu, il faut déterminer les actions à effectuer lorsqu’on
reçoit une des 2 requêtes vues ci-dessus, en complétant les 2 “case” du “switch” présent dans
le code précédent.

Si on reçoit une requête de “Subscribe”, on doit tout d’abord informer l’émetteur de la bonne
réception de sa requête en lui envoyant une requête SIP de type “200 OK”. Celle-ci joue un
rôle d’accusé de réception (ACK) dans un dialogue SIP.
Le principe d’envoi est le même que pour la fonction “Subscribe”.

Pour envoyer la requête SIP “200 OK” il suffit d’ajouter dans les “case” de réception le code
suivant :




                                             15
3.2.4 Envoie de la requête “Notify”

La première étape consiste à récupérer la durée de la demande de souscription, en lisant le
champ associé dans la requête “Subscribe” reçu :




Ensuite le serveur envoi des requêtes “Notify” à l’émetteur à une fréquence d’une toutes les 5
secondes pendant toute la durée du “Subscribe”. La procédure utilisé pour envoyer les
requêtes est la même que celle présenté précédemment pour le “Subscribe” même si les
fonctions utilisé ne sont pas les même.

   •   Gestion de la durée

Pour déterminer la durée de la souscription, nous la comparons avec l’heure courante que l’on
recueille avec une fonction la librairie “time.h” appelée “gmtime (time_t * heure)” (“time_t”
est une structure). Ensuite on converti l’heure obtenue en secondes (car la durée placée dans
la variable “expire” est exprimée en secondes) puis nous l’additionnons à la durée “expire”
pour obtenir l’heure d’expiration.
La boucle de notification est alors lancée jusqu’à ce que l’heure d’expiration soit atteinte.




                                             16
   •   Récupération et envoi de la température


Pour recueillir la température auprès du capteur “iButton”, nous utilisons une petite
application que nous exécutons à l’aide de la fonction C “system” à chaque envoi de requête
“Notify” (pour mettre à jour la température envoyée), qui permet de récupérer la température
et de l’écrire dans un fichier appelé “temperature.txt”.
Ensuite, nous récupérons le contenu du fichier, grâce aux fonctions “fopen” et “fread”, que
nous plaçons dans une chaîne de caractère appelée “buffer”.
Le contenu est de la forme : 0BCXE568 23.4
On voit ainsi que la température se trouve après une chaîne de caractère qui correspond au
nom du capteur ; il va donc falloir écrire un code permettant de récupérer uniquement la
valeur de la température.
De plus, la chaîne que le serveur va renvoyer au client contient “la température est de x”, donc
il va falloir écrire la température à la place du caractère x.


Le code correspondant est le suivant :




NB : Le traitement effectué pour répondre à une requête de mise à jour d’un “Subscribe” est
     similaire à celui effectué dans le cas d’un “Subscribe” normale.




                                              17
Le code permettant ainsi d’envoyer la température à travers une requête est le suivant:




                                              18
4. Validation de l’application

       4.1 Environnement de travail


L’environnement de travail est constituer d’un PC sous Linux et d’une carte cible à base d’un
processeur ARM avec un Linux pré-installé en mémoire ROM.

Le développement est effectué en premier lieu sur le PC afin de tester les programmes et
d’optimiser au mieux leur emprunte mémoire, pour pouvoir les charger par la suite dans le
système embarqué dans les meilleur conditions.

Avant de charger les programmes sur la cible, nous les avons compilés pour l’architecture
ARM avec le compilateur “arm-linux-gcc”.

Il existe deux façons de charger le compilateur dans la cible :

           -   soit par ligne série
           -   soit par tftp (trivial file transfert protocol)

Nous avons opté pour la 2ème solution car elle est plus rapide.


       4.2 Test du système

La procédure de test est la suivante :

1 - On charge le serveur de “Notify” sur la cible et on le lance en écoute sur le port 5000 (port
    réservé au protocole SIP) de la cible.
2 - On lance le client “Subscribe” à partir du PC.
3 - On reçoit alors immédiatement la réponse de la part du serveur sous la forme d’un accusé
    de réception “200 OK” suivit d’une première requête de notification.
4 – Ensuite, suivant la configuration du serveur, on reçoit des requêtes de notification durant
    toute la durée de la souscription.

Nous pouvons observer les différentes étapes de la communication entre le PC et la cible à
l’aide d’un analyseur de réseaux qui s’appel “ethereal”, que l’on présente à la page suivante.


Déroulement de la communication sur “ethereal” :

- En envoyant la requête “Subscribe” vers la cible, on reçoit une réponse de classe 1xx :
  il s’agit de “101” pour établir le dialogue entre les deux systèmes.
- Ensuite, après avoir accepté la requête du PC par un “200 OK”, la cible nous envoi des
  notifications à la fréquence de une toutes les 5 secondes, ce qui est visible dans la colonne
  “Time”.



                                                 19
Figure 8. Relevé avec “ethereal”des requêtes SIP échangées entre le PC et la cible




                                       20
                                 CONCLUSION


La particularité de ce projet a été l’utilisation originale du protocole SIP (avec les méthodes
Subscribe/Notify) utilisé plus habituellement dans le domaine de la téléphonie sur IP.
En effet, la communication entre les deux systèmes aurait pu être réalisée avec d’autres
protocoles de messagerie, comme par exemple avec le protocole SMTP (en embarquant un
client SMTP sur la cible).

Cela nous a ainsi permit de découvrir un nouveau protocole qui est également bien adapté
pour ce type d’application, étant donné que notre système final fonctionne correctement.

Il est à noter cependant que l’aspect de sécurité n’a pas été pris en compte dans notre système
car notre application ne présente pas de grands dangers face aux pirates. Nous n’avons donc
pas effectué de filtrage d’adresse IP.
Ainsi, lors de sa conception, il est important de bien évaluer les risques auxquels le système
est exposé, afin de se prémunir de tout danger.




                                              21

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:6
posted:1/8/2010
language:French
pages:21