Architecture et protocoles de la téléphonie sur IP
La téléphonie sur IP et le RTC
Le RTPC (Réseau Téléphonique Public Commuté, ou simplement RTC) est le réseau téléphonique qui donne accès à de multiple fonction. Le RTC a essentiellement pour objet le transfert de la voix. En effet outre le fait de pouvoir téléphoner, le RTC permet d’utiliser de multiples services tel que la transmission et réception de fax, l’utilisation d’un minitel, accéder à Internet etc. On distingue deux grandes parties dans ce réseau :
Le réseau capillaire ou de distribution, c’est le raccordement depuis chez l’abonné à un point d’entrée du réseau. Cette partie du réseau est analogique.
Le réseau de transit, effectue pour sa part le transport des communications entre les nœuds de transit (concentrateurs/commutateurs). Cette portion du réseau est actuellement numérique.
Le transport de la voix sur un réseau IP et sur le RTC sont deux opérations radicalement différentes. Sur le RTC, la voix est acheminée sous forme d’un flux constant, alors que sur le réseau IP, ce n’est pas du tout le cas. Le transport sur ce dernier se fait en découpant la voix en paquets au départ, à envoyer ces paquets avec le protocole adéquat sur le réseau IP et à tout reconstitué à l’arrivée.
Voix sur IP vs téléphonie sur IP
La ToIP (Telephony over Internet Protocol) consiste en un ensemble de techniques qui, dans une entreprise ou un organisme, permettent la mise en place des services téléphoniques en utilisant les standards de la voix sur IP (VoIP) pour la transmission de messages vocaux sur des réseaux de données IP. La ToIP est gérée par une entité unique, une entreprise pour ses besoins internes ou un opérateur telecom.Dans le cas de la VoIP, on se contente d’interconnecter des PABXs en encapsulant la voix numérisée, dans les paquets IP . Ces derniers sont ensuite véhiculés au sein du réseau de données, de manière classique, comme des paquets de données. La voix est simplement reconstituée lorsque les paquets arrivent chez le destinataire. Un exemple parlant de VoIP se trouve dans le raccordement de deux sites via une ligne spécialisée qui transporte la voix et les données.
Quant à la ToIP , elle va plus loin que la VoIP en terme de mécanismes et d’équipement, cherchant à apporter aux utilisateurs la qualité de service (qualité de transmission, qualité de voix, disponibilité du service) et les services que ces derniers ont l’habitude de trouver du côté de la téléphonie classique (présentation du numéro, transfert d’appel, conférence, etc.) le tout sans faire appel aux PABXs traditionnels.
Le protocole SIP
SIP (Session Initiation Protocol) , est le standard IETF (Internet Engineering Task Force) pour la signalisation de communications multimédias interactives , A savoir : établissement, redirection, relayage, terminaison de sessions vidéo ou audio entre plusieurs terminaux, sur un réseau à commutation de paquet. Il se base entre autre sur le protocole HTTP, la structure de l’entête est semblable et la transmission se fait également en mode texte.
La première version de SIP [5], SIPv1, a été soumise à l’IETF comme une ébauche d’Internet en février 1996. SIPv1 a employé le protocole SDP (Session Description Protocol) pour décrire les sessions et UDP comme protocole de transport. SIPv1 a été basé sur du texte.
Également en février 1996, Henning Schulzrinne a soumis une ébauche d’Internet à l’IETF spécifiant SCIP (Simple Conference Invitation Protocol). SCIP était également un mécanisme pour inviter les utilisateurs aux sessions point à point et multicast. Il a été basé sur le protocole HTTP (Hypertext Transfer Protocol) et a ainsi utilisé TCP (Transmission Control Protocol) comme protocole de transport. Comme SIPv1, SCIP a été basé sur du texte.
Les protocoles associés à SIP
A la différence de la téléphonie à commutation de circuit, les services de téléphonie Internet sont basés sur une gamme de protocoles à commutation de paquets. Le protocole SDP, défini dans la RFC 2327, est Associé au protocole SIP. Ce dernier est employé pour inviter un ou plusieurs participants à une session, alors que le corps codé par SDP du message SIP contient les informations sur quels codage de médias (par exemple, la voix, la vidéo) les participants peuvent et doivent utilisé. Après que cette information soit échangée et reconnue, tous les utilisateurs reconnaissent les adresses IP des participants, la capacité disponible de transmission, et le type de média. Puis, la transmission de données commence, en utilisant un protocole de transport approprié. Typiquement, le protocole RTP est employé. Durant la session, les participants peuvent faire des changements aux paramètres de la session, tels que de nouveaux types de media ou de nouvelles parties à la session, en utilisant des messages SIP.
L’anonymat et la sécurité des utilisateurs
Dans les systèmes pair-à-pair, il n’est pas souhaitable d’identifier les utilisateurs (par un mécanisme de logins par exemple) puisqu’il y en a en général autant que le nombre très important de ressources. D’autre part, l’utilisateur du système peut ne pas vouloir que des informations le concernant soient disponibles dans le système. De plus, de nombreux fournisseurs d’accès allouent dynamiquement les adresses IP aux machines de leurs clients, ce qui peut rendre difficile leur localisation depuis le système. Ces deux constats mènent donc les développeurs de réseaux pair-à-pair à les concevoir de telle sorte que les utilisateurs soient anonymes et que les mécanismes de localisation des ressources reposent sur d’autres principes que celui des adresses IP.
Un autre problème concerne la sécurité des participants. En effet, l’exécution de l’application sur la machine de l’utilisateur et les connexions entrantes des requêtes des autres utilisateurs ne doivent en aucun cas pouvoir conduire à une corruption de la ressource ou de ses données. Le système doit donc assurer automatiquement la sécurité des participants.
Enfin, les pare-feux de certaines machines bloquent les communications entrantes rendant ainsi impossible les connexions directes entre les pairs. Une situation encore différente mais tout aussi problématique concerne les machines d’un réseau utilisant les technologies NAT (Network Address Translation). Dans ce cas, les machines situées dans ce réseau local ne sont même pas visibles de l’extérieur. Une infrastructure pair-à-pair doit donc proposer des solutions permettant de résoudre ces problèmes de sécurité.
|
Table des matières
Introduction générale
1 Architecture et protocoles de la téléphonie sur IP
1.1 Introduction
1.2 Généralités sur la téléphonie sur IP
1.2.1 Principe de la ToIP
1.2.2 La téléphonie sur IP et le RTC
1.2.3 Voix sur IP vs téléphonie sur IP
1.3 Architecture de la ToIP
1.3.1 Les éléments de bases d’une architecture de ToIP
1.3.2 Scénarios possibles pour la ToIP
1.3.3 Normalisation et standardisation de la ToIP
1.4 Les standards de la ToIP
1.4.1 Le standard H.323
1.4.2 Le protocole SIP
1.4.2.1 Les messages SIP : requêtes et réponses
1.4.2.2 Les adresses SIP
1.4.2.3 Architecture et composantes du protocole SIP
1.4.2.4 Le routage de la signalisation SIP
1.4.2.5 Éléments critiques du routage SIP
1.4.3 Les protocoles associés à SIP
1.4.4 Comparaison des protocoles H.323 et SIP
1.5 Qualité de service et sécurité de la ToIP
1.5.1 Téléphonie sur IP et qualité de service
1.5.2 Téléphonie sur IP et sécurité
1.5.2.1 Menaces héritant directement du modèle réseau de donnée IP
1.5.2.2 Menaces propres à l’utilisation de la VoIP/SIP
1.5.2.3 Solutions pour sécuriser la VoIP
1.6 Conclusion
2 Présentation de l’architecture Pair-à-Pair
2.1 Généralités
2.1.1 Définition
2.1.2 Caractéristiques des systèmes P2P
2.1.2.1 Décentralisation
2.1.2.2 L’extensibilité et l’hétérogénéité
2.1.2.3 Connectivité Ad-hoc et Auto-organisation
2.1.2.4 L’anonymat et la sécurité des utilisateurs
2.1.3 Niveau de décentralisation
2.1.3.1 Le modèle P2P pur
2.1.3.2 Le modèle P2P hybride
2.1.3.3 Le modèle P2P centralisé
2.1.4 P2P structuré vis à vis non-structuré
2.1.5 Problématique générale
2.2 Les tables de hachage distribuées (DHT)
2.2.1 Protocoles fondés sur l’algorithme de Plaxton
2.2.1.1 Algorithme de routage Plaxton
2.2.1.2 Routage dans Pastry
2.2.2 CAN : un protocoles fondés sur un hypercube
2.2.3 Viceroy : un protocoles fondés sur les graphes en anneau
2.2.4 Le protocole Chord
2.2.4.1 Aperçu
2.2.4.2 La fonction de hachage
2.2.4.3 Assignation simple des clés
2.2.4.4 Assignation optimale des clés
2.2.4.5 Opérations de maintenance
2.2.5 Chord2 : un nouveau protocole à deux couche
2.2.6 Comparaison des caractéristiques théoriques
2.3 Aspects de sécurité dans les réseaux P2P structurés
2.3.1 Routage sécurisé dans un réseau structuré
2.3.1.1 Assignation sécurisée des nodeIds
2.3.1.2 Mise à jour sécurisée des tables de routage
2.3.1.3 Retransmission sécurisée
2.4 Skype : une application de ToIP en mode P2P
2.4.1 Architecture de Skype
2.4.2 Fonctionnement
2.4.3 Limites du Skype
2.5 Problèmes des réseaux P2P
2.6 Conclusion
3 Optimisation du routage de la signalisation SIP
3.1 Introduction
3.2 La téléphonie IP basée sur le modèle client-seveur
3.3 La téléphonie IP basée sur une architecture P2P
3.3.1 P2P-SIP
3.3.1.1 L’enregistrement d’un nouveau utilisateur
3.3.1.2 Architecture de P2P-SIP
3.3.1.3 L’enregistrement d’utilisateur
3.3.1.4 Défaillance d’un nœud
3.3.2 SoSimple
3.3.2.1 Arrivée d’un nœud
3.3.2.2 Localisation d’un nœud
3.3.3 Problèmes soulevés des solutions existante
3.4 Proposition
3.4.1 Définition des unités de travail
3.4.2 Processus de localisation et de routage
3.4.3 Enregistrement d’un nouveau nœud
3.4.4 Établissement d’une session
3.4.5 Définition des variables
3.4.6 Propriétés de la solution
3.4.6.1 Interopérabilité
3.4.6.2 Optimisation du nombre de messages échangés
3.4.6.3 Décentralisation
3.4.6.4 Recherche efficace
3.4.6.5 Équilibre des clés
3.5 Conclusion
Conclusion générale et perspective
Télécharger le rapport complet