Voix sur IP

De nombreuses applications permettent d’utiliser la voix sur IP telles que Skype, Discord ou bien Messenger…

Contraintes d’une application de voix et solutions sur IP

Pour qu’une application de voix fonctionne correctement il est nécessaire que certaines conditions soient réunies. Il ne faut pas qu’il y ait trop de latence, il faut que la gigue soit faible. La gigue est la variation de la latence en fonction du temps. Sur un réseau IP la gigue peut brusquement changer car les paquets IP peuvent ne pas prendre le même chemin et donc mettre plus ou moins de temps selon le chemin emprunté et le trafic sur le réseau. Une application de voix ne doit également pas prendre toute la bande passante du réseau. Il est également important que la voix ne soit pas trop perdue sur le réseau pour que la conversation soit de bonne qualité. Car si sur un réseau IP, sur le chemin d’un paquet IP transportant de la voix se trouve un routeur en situation de congestion, le paquet de voix ne sera pas routé jusqu’à sa destination et se retrouvera perdu. Sur un réseau IP on a par exemple les protocoles SIP, RTP et RTCP qui permettent de répondre à ses contraintes.

Principaux codecs utilisés

Un codec permet de convertir un signal vocal analogique en un signal numérique. Il existe plusieurs codecs différents utilisés pour les applications de voix sur IP: G711: ce codec a un débit binaire élevé, jusqu’à 64Kbps, c’est le codec qui donne la meilleure qualité de voix et qui a le moins de latence grâce à un algorithme peu coûteux. Son inconvénient c’est qu’il prend plus de bande passante que les autres codecs, jusqu’à 84Kbps. G729: Ce codec offre un bon ratio entre qualité de la voix et la bande passante utilisée. Le codec a seulement besoins d’un débit de 8Kbps. Par contre il nécessite plus de ressources pour être traité par le processeur dû à un algorithme plus coûteux. G723.1: Le codec offre un débit de 5,3 ou 6,3Kbps, ce qui en fait le codec le moins gourmand en bande passante, c’est par contre le codec qui a l’algorithme le plus coûteux.

SIP

SIP (Session Initiation Protocol) est un protocole de gestion de sessions utilisé dans les télécommunications. C’est un protocole de la couche application. Le protocole gère l’établissement, la modification et la terminaison des sessions et se charge de l’authentification et de la localisation des participants d’une session. Par contre ce protocole ne s’occupe pas du transports des données qui sont échangées pendant la session. Pour la mise en place d’une session SIP, il est nécessaire d’avoir des “user agent”, les personnes qui veulent communiquer ensemble, un serveur proxy SIP et un registrar. Le registrar est un serveur qui gère les requêtes des “user agent” qui signalent leur position, il possède une base de données qui permet le stockage d’une liste d’associations adresse IP <-> SIP-URI. Une SIP-URI est une adresse de la forme suivante: sip:utilisateur@domaine.com. Le serveur proxy SIP est l’intermédiaire entre les “user agent”. Lorsqu’un utilisateur veut communiquer avec un autre, il donne sa SIP-URI et le serveur proxy va faire le lien avec l’IP courante de l’utilisateur pour établir la communication en interrogeant la base de données du registrar puis acheminer les messages vers le destinataire. Les principales méthodes SIP sont les suivantes: INVITE: établit une session, cette requête est envoyée vers la personne appelée par l’appelant. ACK: permet de confirmer la requête INVITE. BYE: permet de mettre fin à la session en cours. REGISTER: permet de mettre à jour l’emplacement de l’utilisateur auprès du registrar. Les principales réponses sont les suivantes:

  • 100 (Trying): réponse donnée lorsqu’une requête est en cours de transmission.
  • 180 (Ringing): le destinataire a reçu la requête INVITE et son téléphone sonne.
  • 200 (OK): réponse envoyée lorsque la requête a réussie. (par exemple le destinataire décroche son téléphone)

Déroulement d’une session SIP utilisant un serveur proxy SIP

Lien entre SIP et H.323

A la place de SIP, il est également possible d’utiliser le protocole H.323. SIP est un protocole qui a développé par l’IETF et s’inspire du protocole Http alors que H.323 s’inspire de la téléphonie. Le protocole SIP est plus modulaire et peut fonctionner avec d’autres protocoles. Il est donc plus souple que H.323. Aujourd’hui SIP remplace de plus en place H.323.

RTP

RTP (Real Time Transport Protocol) est un protocole de transport de données pour des applications fonctionnant en temps réel, c’est un protocole de la couche application. L’utilisation de RTP se fait généralement au-dessus de UDP et pas au-dessus de TCP car avec TCP si un paquet est perdu, il va attendre de le recevoir à nouveau de la part de l’émetteur, ce qui bloque l’application or pour du temps réel on ne veut pas que cela se produise. Le protocole RTP ajoute plusieurs fonctionnalités par rapport au protocole de la couche réseau qu’il utilise:

  • un numéro de séquence: d’une taille de 2 octets, ce champ permet d’ordonner les paquets. Il peut permettre de détecter les paquets perdus.
  • un timestamp (marquage temporel): d’une taille de 4 octets, ce champ représente l’horloge système ou l’horloge d’échantillonnage de l’émetteur. Elle doit être monotone et linéaire pour assurer la synchronisation des flux.
  • SSRC: d’une taille de 4 octets, ce champ permet d’identifier la source de synchronisation de manière unique.
  • CSRC: d’une taille de 4 octets, ce champ permet d’identifier les sources de contribution. La liste des participants ont leur contributions aux données du paquet.
RTP peut fonctionner en association avec le protocole RTCP (Real Time Transport Control Protocol) ou RTSP (Real Time Streaming Protocol). RTSP est destiné aux systèmes de streaming média. Il permet de contrôler un serveur de média à distance. Le protocole offre des fonctionnalités communes pour un lecteur vidéos telles que “lecture”, “pause”. Après établissement d’une session SIP, pendant les échanges de données via les paquets RTP, le protocole RTCP transmet périodiquement des paquets de contrôle à tous les participants de la session. Le protocole permet de récupérer des informations sur la qualité de service, comme le nombre de paquets perdus, la gigue et le RTT (délai aller retour). Ces informations peuvent ainsi permettre aux participants d’adapter les débits en fonctions de plusieurs paramètres pour assurer une qualité de service minimale.