Les éléments d’un réseau SIP

Contribution

Le projet a pour but d’apporter une certaine amélioration au niveau de la QoS dans le cas d’un serveur SIP qui reçoit une rafale de trafic. Pour ce faire, une plateforme de gestion de flux avec six files d’attente a été élaborée. Le système combine des méthodes de protection contre les effets de la congestion du serveur SIP. On propose une architecture expérimentale de test SIP capable d’ignorer les messages retransmis ainsi qu’une vérification continuelle de la taille des files attente pour des fins de contrôle d’admission. Ceci est combiné avec trois disciplines appliquées sur les files d’attente mises en place. Un gestionnaire de flux SIP (GFSIP) sera mis en place afin d’effectuer un traitement différencié de message. Le GFSIP a permis d’obtenir un nouveau scénario d’échange de message entre les différentes entités SIP. En d’autres termes, la contribution majeure consiste dans la combinaison des éléments mentionnés ci-haut avec une comparaison entre trois disciplines appliquées sur les files d’attente en question. Le résultat devrait conclure l’effet de ces disciplines sur le délai ‘Invite-180’, le délai ‘200-Ack’ et les appels rejetés.

Structure du mémoire

Ce mémoire est structuré comme suit : Le chapitre 1 présente un bref aperçu de SIP. Les composants, ainsi que tous les éléments de base d’un réseau SIP opérationnel y sont décrits. Des scénarios basiques utilisés dans quelques services sont illustrés. Par la suite, une synthèse sur la congestion du protocole est élaborée en se basant sur les travaux de recherches antérieures. Le chapitre 2 décrit l’état de l’art du projet. Il commence par une description détaillée des éléments de la problématique. Il montre la relation entre les messages SIP et la tolérance au délai et au rejet. Par la suite il donne une idée de l’approche de gestion de messages proposée. Finalement, il met en évidence le rôle des disciplines appliquées sur les files d’attente dans la gestion des messages. Le chapitre 3 présente la topologie et l’architecture de l’environnement expérimental. Le chapitre fait appel aux modèles de Markov pour assimiler le comportement des entités SIP ayant l’intention d’établir des sessions médias.

Ces modèles ont facilité l’illustration des tolérances selon les différents états et transactions. L’architecture globale du test a été présentée afin de connaître les éléments SIP qui seront utilisés dans le test. Le chapitre se termine par une présentation détaillée de l’architecture du GFSIP. Le chapitre 4 décrit les scénarios d’échange de messages entre les différentes entités qui composent le réseau de test SIP. Par la suite, l’implémentation de chaque entité est présentée d’une façon détaillée en expliquant les parties essentielles du code et les algorithmes utilisés. La méthode de déploiement et les limitations de l’implémentation sont mises en évidence à la fin du chapitre. Le chapitre 5 donne une description détaillée des tests qui ont été effectués, suivi d’une analyse approfondie des résultats obtenus. L’analyse a ciblé la variation des délais et des rejets dans trois systèmes FIFO-GFSIP, FQ-GFSIP et PQ-GFSIP. Une comparaison entre les différents systèmes a été effectuée dans le but de conclure l’effet des disciplines sur la performance du réseau, lorsque ceci reçoit des rafales de trafic.

SESSION INITIATION PROTOCOL

De nos jours, la croissance des opérateurs de télécommunication est basée, essentiellement, sur la diversité des services offerts. Au départ, les opérateurs pensaient d’utiliser différents réseaux pour chacun des trafics : donnée, voix et télévision, parce que les caractéristiques des trafics diffèrent l’un de l’autre. Le flux donné tolère le délai, mais pas la perte, tandis que la voix peut tolérer la perte, mais pas le délai. Par exemple, les réseaux ATM et Frame Relay sont des réseaux de donnée à commutation par circuit dont le taux d’erreur est très faible, toutefois, le délai est le prix à payer. De plus, la réservation des ressources posait beaucoup de problèmes de bande passante. Ces types de réseau n’étaient donc pas convenables pour supporter le trafic voix. L’internet a pu résoudre ce type de problème. Sa technologie a permis de rassembler plusieurs types de trafic dans un seul réseau. Le ‘Best effort’ a résolu carrément les problèmes de la bande passante (Kadoch, 2008b). La voix est parmi les grands avantages dont l’usager a bénéficié. Les gens, à l’époque, dépensaient des prix exorbitants pour des communications longues distances. L’internet a rendu ces communications pratiquement gratuites. La voix sur IP (VOIP: Voice Over IP) est la technologie utilisée pour faire circuler le trafic voix dans le réseau internet. Son développement nécessite un protocole permettant l’établissement et la terminaison des appels. Ce type de protocole est intitulé: protocole de signalisation. SIP est un protocole de signalisation utilisé dans la voix sur IP. Il permet l’établissement ainsi que la terminaison des appels voix. Sa simplicité et flexibilité lui ont permis d’être adopté dans les réseaux de nouvelles générations. À part la voix, SIP est, aussi, utilisé dans d’autres services tels que la messagerie instantanée et la présence. SIP a été approuvé par l’IETF (Internet Engineering Task Force) en 1999 sous le RFC 2543. Son développement a eu un grand intérêt, ce qui a permis la naissance de deux groupes principaux SIP WG et SIPPING, qui ont fait un travail considérable dans la mise en marche de ce protocole (Henry Sinnreich, 2001).

Le dialogue SIP est un protocole utilisé dans une panoplie de services dont les messages et les scénarios dépendent intimement. Cette partie présente des scénarios basiques de trois services (voix, messagerie instantanée et présence) qui utilisent SIP dans l’établissement et la terminaison des sessions. La figure 1.2 présente un scénario basique d’enregistrement et d’initiation d’un appel. Les opérations d’enregistrement s’effectuent périodiquement par le téléphone sans l’intervention de l’être humain. Un champ ‘Expires’ dans l’en-tête du message ‘Register’ définit le temps d’expiration de l’enregistrement. Les deux UA devraient être préalablement enregistrés avant de pouvoir effectuer les appels. Le serveur SIP sera, donc, en mesure de localiser la machine ou l’URI en question est connecté. Afin d’initier un appel, l’UAC envoie un message ‘Invite’ contenant l’adresse du destinataire. Ce message contient souvent les informations de la session média. Le serveur SIP reçoit le message, consulte l’adresse de destination et transmet le message au UAS. Ce dernier répond par un message ‘180 Ring’ si le téléphone n’est pas occupé. Lorsque l’appelé décroche, un message ‘200 OK’ est envoyé au serveur SIP qui le transmet à l’UAC. Ceci confirme par un message ‘Ack’. La session RTP est établie une fois le UAS reçoit ce message. À la fin de la conversation, les deux messages ‘Bye’ et ‘200 OK’ sont échangés afin de mettre fin à la session courante.

L’échange de message peut différer dans chaque implémentation. Il est possible que les messages ‘Ack’ , ‘Bye’ et ‘200 Ok (Bye)’ s’échangent directement entre les UAs. D’autres implémentations préfèrent passer tous les messages par un serveur SIP pour des raisons de sécurité et de contrôle. Par exemple: le passage des messages ‘Bye’ par un serveur SIP pourrait déterminer la durée de chaque appel. Le protocole SIP est aussi utilisé dans la messagerie instantanée (MI). La figure 1.3 présente un scénario d’échange de message dans ce service. Figure 1.3 Le scénario de la messagerie instantanée Ce service consiste en un échange de message en temps réel pour des fins de communication. Les messages échangés ont une forme texte, et sont naturellement courts. Les utilisateurs commencent une session ‘Chat’ durant laquelle ils s’échangent des messages texte. Le message ‘Message’ est utilisé pour transporter le message instantané. Il est envoyé par l’UAC, reçu par le serveur SIP qui le transmet à l’UAS. Ce dernier répond par un message‘200 OK’ confirmant la réception du message. Le serveur SIP pourrait avoir recours à une base de données afin d’effectuer l’acheminement et la gestion des transactions. Le service MI est souvent combiné avec le service de présence dans les applications de communication. Naturellement, les utilisateurs se connectent à une application donnée et ils se mettent au statut souhaité (Disponible, Occupé, Partis manger…). La gestion des informations de présence s’effectue selon un modèle établi dans (M. Day, 2000). Ce modèle contient trois entités logiques : Presence Service, ‘Presentity’ et le ‘Watcher’.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION
CHAPITRE 1 SESSION INITIATION PROTOCOL
1.1 Les éléments d’un réseau SIP
1.1.1 Les UAs (User Agent)
1.1.2 Les serveurs SIP
1.1.3 Les serveurs de localisation (Location Server)
1.2 Les messages SIP
1.3 L’adressage
1.4 Le dialogue
1.5 La congestion dans les Réseaux SIP
1.5.1 Les causes de la congestion dans les réseaux SIP
1.5.2 Le contrôle de la congestion dans les spécifications SIP
1.5.3 Les travaux de recherche antérieurs
1.6 Conclusion
CHAPITRE 2 L’ÉTAT DE L’ART
2.1 La tolérance aux délais des messages SIP
2.2 Les rejets et la priorité des messages SIP
2.3 La gestion des messages SIP et l’approche proposée
2.4 Les files d’attente et les messages SIP
2.5 Conclusion
CHAPITRE 3 L’ARCHITECTURE EXPÉRIMENTALE DE TEST
3.1 Topologie : Serveur – Serveur vs UA – Serveur
3.2 L’architecture standard de test et Modules utilisés
3.2.1 Le modèle utilisateur
3.2.2 Le modèle enregistrement
3.2.3 Le modèle UAC
3.2.4 Le modèle UAS
3.2.5 Les délais, les rejets et les modèles utilisés
3.3 L’architecture de test proposée
3.4 L’architecture du gestionnaire du flux SIP proposée
3.5 Conclusion
CHAPITRE 4 SCÉNARIOS, IMPLÉMENTATIONS ET TECHNOLOGIES UTILISÉES
4.1 Les Servlets SIP de Java
4.2 Bref aperçu sur SIPp
4.3 Les scénarios utilisés
4.3.1 Le flux de paquet de signalisation et les délais associés
4.3.2 Le flux de paquet d’enregistrement
4.4 Phase de l’implémentation
4.4.1 L’implémentation des UAs
4.4.1.1 L’instance SIPp Client-Appel
4.4.1.2 L’instance SIPp Client-Enregistrement
4.4.1.3 L’instance SIPp serveur
4.4.2 L’implémentation du Serveur SIP
4.4.2.1 Le proxy
4.4.2.2 L’enregistrement
4.4.3 L’implémentation du GFSIP proposé
4.5 L’architecture de l’environnement expérimental
4.6 Le déploiement
4.7 Limitation
4.8 Conclusion
CHAPITRE 5 TESTS ET RÉSULTATS
5.1 La dépendance entre messages SIP
5.2 Tests et statistiques
5.3 L’effet du ramasse-miettes (Garbadge Collector)
5.4 Le système FIFO-GFSIP
5.4.1 L’analyse de la langueur des files d’attente
5.4.2 L’analyse des délais et rejets
5.4.3 L’effet de la longueur maximale sur la tolérance
5.5 Le système FQ-GFSIP
5.5.1 L’analyse des résultats
5.5.2 Les rejets
5.6 Le système PQ-GFSIP
5.6.1 La priorité des messages SIP
5.6.2 L’analyse des résultats
5.7 FIFO-GFSIP vs FQ-GFSIP vs PQ-GFSIP
5.7.1 Les délais
5.7.2 Les rejets
5.7.3 Conclusion
CONCLUSION ET TRAVAIL FUTUR
RECOMMANDATIONS
ANNEXE I LE CODE DES MÉTHODES IMPLÉMENTÉES DANS LE SERVEUR SIP
ANNEXE II LECODE DE LA CLASSE UTILISÉE POUR LES FILES D’ATTENTE
ANNEXE III LE CODE DU CLASSIFICATEUR
ANNEXE IV LE CODE DE L’ORDONNANCEUR AVEC ?LA DISCIPLINE FQ
ANNEXE V LE CODE DE L’ORDONNANCEUR AVEC LA DISCIPLINE PQ
LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES