Ci-dessous sont présentés des aspects importants qu'il faut connaître pour comprendre le fonctionnement de la VoIP.
L'établissement d'une connexion VoIP nécessite :
D'abord le CAN qui permet de convertir la voix analogique en signaux numériques (bits).
Les bits doivent être ensuite compressés en un format adapté à la transmission : il existe plusieurs protocoles que nous allons examiner ci-dessous.
Il faut ensuite transmettre les données numériques vocales dans des paquets de données à l'aide d'un protocole temps réel (généralement RTP sur UDP sur IP).
Il est nécessaire d'utiliser un protocole de signalisation pour appeler les usagers. ITU-T H323 le permet.
À la réception, il faut désassembler les paquets, extraire les données, les convertir en signaux analogiques représentant la voix, puis les transmettre à une carte son (ou à un téléphone).
Tout cela doit être réalisé en temps réel, afin d'éviter une attente trop longue de la réponse vocale ! (voir la section QoS)
Architecture de base Voix )) CAN - Algorithme de Compression - Assembler RTP dans TCP/IP ----- ----> | <---- | Voix (( CNA - Algorithme de Décompression - Désass. RTP de TCP/IP -----
Celle-ci est faite par le matériel, généralement une carte CAN intégrée.
Aujourd'hui, n'importe quelle carte son vous permet de convertir une bande de 22050 Hz en données de 16 bits (l'échantillonnage doit être réalisé à une fréquence de 44100 Hz en raison du principe de Nyquist), cela donne un débit de 2 octets * 44100 échantillons par seconde = 88200 octets/s soit 176,4 ko/s pour un flux stéréo.
La VoIP ne nécessite pas un tel débit pour la transmission des paquets de voix : nous allons examiner ci-dessous les différents codages qui seront utilisés en pratique.
Comme nous disposons maintenant de données numériques, nous pouvons les convertir dans un format standard qui permet une transmission rapide.
PCM, modulation par impulsion et codage (MIC), norme ITU-T G.711
La bande passante de la voix est de 4 kHz, donc la fréquence d'échantillonnage doit être de 8 kHz (Nyquist).
Nous représentons chaque échantillon par 8 bits (ce qui donne 256 valeurs possibles).
Le débit est de 8000 Hz * 8 bits = 64 kbps, comme une ligne téléphonique typique.
Dans les applications réelles, les variantes à loi mu (Amérique du Nord) et à loi a (Europe) sont utilisées pour encoder le signal analogique sur une échelle logarithmique en utilisant 12 ou 13 bits au lieu de 8 (voir la norme ITU-T G.711).
ADPCM, modulation par impulsion et codage différentiel adaptatif (MICDA), norme ITU-T G.726
Seule la différence entre le paquet de voix actuel et le précédent est converti, ce qui nécessite 32 kbps (Norme ITU-T G.726).
LD-CELP, norme ITU-T G.728 CS-ACELP, normes ITU-T G.729 et G.729a MP-MLQ, norme ITU-T G.723.1, 6.3kbps, Truespeech ACELP, norme ITU-T G.723.1, 5.3kbps, Truespeech LPC-10, norme capable d'atteindre 2.5 kbps!!
Ces derniers protocoles sont les plus importants car ils peuvent garantir une bande minimale très basse par un codage à la source. De plus les codecs G.723.1 ont une note moyenne d'opinion très élevé (utilisée pour mesurer la fidélité de la voix), mais attention aux performances d'élaboration qu'ils nécessitent : jusqu'à 26 MIPS !
Nous disposons maintenant des données brutes, il faut les empaqueter en données de protocole TCP/IP, en respectant le schéma suivant :
paquets de données VoIP RTP UDP IP couches I, II
Les paquets de VoIP sont placés dans des paquets RTP (Real Time Transport Protocol) à l'intérieur de paquets UDP/IP.
On remarque, d'abord, que la VoIP n'utilise pas le protocole TCP, trop lourd pour les applications en temps réel. On utilise, à la place, les datagrammes du protocole UDP.
Ensuite, UDP ne garantit ni l'ordre d'arrivée à destination des paquets, ni leur temps de transfert (principe du datagramme). Ces deux propriétés sont très importantes pour la qualité générale de la voix (la bonne compréhension des paroles de l'interlocuteur) et la qualité de la conversation (la facilité de son déroulement). RTP résout le problème en permettant au destinataire de remettre les paquets dans l'ordre et en évitant une attente excessive des paquets égarés en chemin ou trop longs à parvenir (il n'est pas nécessaire de recevoir chaque paquet, il faut par contre disposer d'un flux continu, en nombre suffisant, de paquets dans l'ordre).
Real Time Transport Protocol 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | numéro de séquence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | empreinte temporelle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | identifiant de la source de synchronization source (SSRC) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | identifiants des sources contribuantes (CSRC) | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Où :
V représente la version utilisée du protocole RTP
P indique la présence d'un octet de bourrage (padding), à la fin du paquet, pour obtenir un paquet de longueur paire
X indique la présence d'une extension d'en-tête
Le champ CC représente le nombre d'identifiants CSRC qui suivent l'en-tête fixe. Les champs CSRC servent, notamment, pour les conférences.
M est un bit marqueur.
PT est le type de charge utile (payload type).
Pour une description complète du protocole RTP et de toutes ses applications, voir les RFC 1889et 1890.
D'autres protocoles sont utilisés en VoIP, comme RSVP, qui peut prendre en charge la Qualité de Service (QoS, Quality of Service).
RSVP est un protocole avec signalisation, qui nécessite une certaine bande passante et un délai à chaque bond réseau le prenant en charge.
Pour des informations détaillées sur RSVP, voir RFC 2205
Nous avons répété à plusieurs reprises que les applications de VoIP nécessitaient un flux de données en temps réel car le but est d'obtenir un échange vocal interactif.
Malheureusement, TCP/IP ne permet pas d'atteindre cet d'objectif, il ne peut que faire « au mieux ». Il va falloir utiliser des astuces et des stratégies pour la gestion du flux des paquets dans CHACUN des routeur que nous allons traverser.
On peut ainsi utiliser :
Le champ TOS du protocol IP, qui indique le type de service : une valeur élevée signifie un degré d'urgence faible, alors que des valeurs faibles signifient un degré d'urgence important, compatible avec le temps réel.
Méthodes de mise en file d'attente des paquets :
FIFO (First In First Out, Premier Entré Premier Sorti), la méthode la plus stupide, qui fait passer les paquets dans leur ordre d'arrivée.
WFQ (Weighted Fair Queuing, file d'attente équitable pondérée) consiste en un passage équitable des paquets (ainsi, FTP ne peut pas consommer la totalité de la bande passante disponible) entre les différents flux de données, avec, en général, un paquet pour UDP et un pour TCP, en alternance.
CQ (Custom Queuing, mise en file d'attente personnalisée), les utilisateurs peuvent décider de la priorité.
PQ (Priority Queuing, file d'attente avec priorité), il existe plusieurs files (en général quatre), chacune disposant d'un niveau de priorité. Les paquets de la file la plus prioritaire sont envoyés en premier puis (quand elle est vide), on passe à la seconde, et ainsi de suite.
CB-WFQ (Class Based Weighted Fair Queuing - Mise en file d'attente par classes, pondérée et équitable), semblable à WFQ, avec en plus une notion de classes (jusqu'à 64) à chaque classe est associée une valeur de bande passante.
La capacité de mise en forme du trafic, qui permet de limiter la source à une bande passante fixe en :
téléchargement (download)
mise en ligne (upload)
Evitement de congestion (Congestion Avoidance), comme RED (Random Early Detection).
Pour des informations exhaustives sur la QoS, voir Differentiated Services à l'IETF.
Le protocole H323 est utilisé par exemple par Microsoft NetMeeting pour faire des appels VoIP.
Ce protocole permet à plusieurs éléments de se parler :
Des terminaux, clients qui initient une connexion VoIP. Bien que les terminaux puissent se parler sans l'aide d'un intermédiaire, nous avons besoin d'éléments additionnels dans la perspective d'une montée en charge.
Des portiers, qui réalisent essentiellement :
un service de traduction d'adresses, pour utiliser des noms à la place des adresses IP
un contrôle des admissions, pour autoriser ou refuser certaines machines ou certains usagers
une gestion de la bande passante
Des passerelles, points de référence pour la conversion TCP/IP-RTCP.
Des Unités de Contrôle Multipoint (MCU, Multipoint Control Units), pour permettre les conférences.
Des serveurs proxies sont également utilisés.
Le protocole H323 concerne non seulement la VoIP mais aussi les communications de données et de vidéo.
En ce qui concerne la VoIP, h323 peut utiliser les codecs audio G.711, G.722, G.723, G.728 et G.729 ; pour la vidéo il prend en charge h261 et h263.
On trouvera des informations complémentaires sur h323 sur les sites Web Openh323 Standards et h323 ainsi que dans le document de définition de la norme : ITU H-series Recommendations.
On le trouve implémenté dans différents logiciels comme Microsoft Netmeeting, Net2Phone, DialPad, ... et aussi dans des produits freeware qu'on peut trouver au site web Openh323.