Transport Rtp & Rtcp

6.3.1 - Introduction

Rtp est un protocole qui a été développé par l’IETF afin de

facilité le transport temps réel de bout en bout des flots
données audio et vidéo sur les réseaux Ip, c’est à dire sur les
réseaux de paquets. Rtp est un protocole qui se situe au
niveau de l'application et qui utilise les protocoles sous-
jacents de transport Tcp ou Udp. Mais l'utilisation de Rtp se
fait généralement au-dessus de Udp ce qui permet d’atteindre
plus facilement le temps réel. Les applications temps réels
comme la parole numérique ou la visio-conférence constitue
un véritable problème pour Internet. Qui dit application temps
réel, dit présence d’une certaine qualité de service (QoS) que
Rtp ne garantie pas du fait qu'il fonctionne au niveau
Applicatif. De plus Rtp est un protocole qui se trouve dans un
environnement multipoint, donc on peut dire que Rtp possède
à sa charge, la gestion du temps réel, mais aussi
l’administration de la session multipoint.

Rtp et Rtcp sont définis, depuis juillet 2003, par la Rfc 3550
rendant obsolète la version précédente Rfc 1889.

6.3.2 - Les fonctions de Rtp

Le protocole Rtp, Real Time Transport Protocol, standardisé en

1996, a pour but d’organiser les paquets à l’entrée du réseau
et de les contrôler à la sortie. Ceci de façon à reformer les flux
avec ses caractéristiques de départ. Rtp est géré au niveau de
l'application donc ne nécessite pas l'implémentation d’un
Kernel ou de librairies. Comme nous l’avons dit dans
l’introduction, Rtp est un protocole de bout en bout. Rtp est
volontairement incomplet et malléable pour s'adapter aux
besoins des applications. Il sera intégré dans le noyau de
l'application. Rtp laisse la responsabilité du contrôle aux
équipements d'extrémité.

Rtp, est un protocole adapté aux applications présentant des

propriétés temps réel. Il permet ainsi de :

Reconstituer la base de temps des flux (horodatage des

paquets : possibilité de resynchronisation des flux par le
récepteur)

Mettre en place un séquencement des paquets par une

numérotation et ce afin de permettre ainsi la détection des
paquets perdus. Ceci est un point primordial dans la
reconstitution des données. Mais il faut savoir quand même
que la perte d’un paquet n’est pas un gros problème si les
paquets ne sont pas perdus en trop grands nombre. Cependant
il est très important de savoir quel est le paquet qui a été
perdu afin de pouvoir pallier à cette perte. Et ce par le
remplacement par un paquet qui se compose d’une synthèse
des paquets précédent et suivant.
Identifier le contenu des données pour leurs associer un
transport sécurisé.

L’identification de la source c’est à dire l’identification de

l’expéditeur du paquet. Dans un multicast l’identité de la
source doit être connue et déterminée.

Transporter les applications audio et vidéo dans des trames

(avec des dimensions qui sont dépendantes des codecs qui
effectuent la numérisation). Ces trames sont incluses dans des
paquets afin d’être transportées et doivent de ce fait être
récupérées facilement au moment de la phase de
dépaquétisation afin que l’application soit décodée
correctement.

En revanche, ce n'est pas "la solution" qui permettrait

d'obtenir des transmissions temps réel sur IP. En effet, il ne
procure pas de :

Réservation de ressources sur le réseau (pas d'action sur le

réseau, cf. RSVP);

Fiabilité des échanges (pas de retransmission automatique,

pas de régulation automatique du débit);

Garantie dans le délai de livraison (seules les couches de

niveau inférieur le peuvent) et dans la continuité du flux
temps réel.

6.3.3 - Entête Rtp

L'entête d'un paquet Rtp est obligatoirement constitué de 16

octets. Cette entête précède le
"payload" qui représente les données utiles.
6.3.3.1 - V

Ce champ, codé sur 2 bits, permet d'indiquer la version de Rtp.

Actuellement, V=2.

6.3.3.2 - P

Ce bit indique, si il est à 1, que les données possèdent une

partie de bourrage.

6.3.3.3 - X

Ce bit spécifie, si il est à 1, que l'entête est suivie d'une entête

supplémentaire.

6.3.3.4 - CC

Ce champ, codé sur 4 bits, représente le nombre de CSRC qui

suit l'entête.

6.3.3.5 - M

Ce bit, lorsqu'il est à 1, définie que l'interprétation de la

Marque est par un profil d'application.

6.3.3.6 - PT

Basé sur 7 bits, ce champ identifie le type du payload (audio,

vidéo, image, texte, html, etc.).

6.3.3.7 - Numéro de séquence

Ce champ, d'une taille de 2 octets, représente le numéro

d'ordre d'émission des paquets. Sa valeur initiale est aléatoire
et il s'incrémente de 1 à chaque paquet envoyé, il peut servir à
détecter des paquets perdus.

6.3.3.8 - Timestamp

Ce champ horodatage, de 4 octets, 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.

6.3.3.9 - SSRC

Basé sur 4 octets, ce champ identifie de manière unique la

source de synchronisation, sa valeur est choisie de manières
aléatoire par l'application.

6.3.3.10 - SSRC
Ce champ, sur 4 octets, identifie les sources de contribution.
La liste des participants ayant leur contribution (audio, vidéo)
aux donnée du paquet.

6.3.4 - Les fonctions de Rtcp

Le protocole Rtcp est fondé sur la transmission périodique de

paquets de contrôle à tous les participants d’une session. C’est
le protocole Udp (par exemple) qui permet le multiplexage des
paquets de données Rtp et des paquets de contrôle Rtcp. Le
protocole Rtp utilise le protocole Rtcp, Real-time Transport
Control Protocol, qui transporte les informations
supplémentaires suivantes pour la gestion de la session :

Les récepteurs utilisent Rtcp pour renvoyer vers les émetteurs

un rapport sur la QoS. Ces rapports comprennent le nombre de
paquets perdus, le paramètre indiquant la variance d’une
distribution (plus communément appelé la gigue : c’est à dire
les paquets qui arrivent régulièrement ou irrégulièrement) et
le délai aller-retour. Ces informations permettent à la source
de s’adapter, par exemple, de modifier le niveau de
compression pour maintenir une QoS.

Une synchronisation supplémentaire entre les médias. Les

applications multimédias sont souvent transportées par des
flots distincts. Par exemple, la voix, l’image ou même des
applications numérisées sur plusieurs niveaux hiérarchiques
peuvent voir les flots gérées suivre des chemins différents.

L’identification car en effet, les paquets Rtcp contiennent des

informations d’adresses, comme l’adresse d’un message
électronique, un numéro de téléphone ou le nom d’un
participant à une conférence téléphonique.

Le contrôle de la session, car Rtcp permet aux participants

d’indiquer leur départ d’une conférence téléphonique (paquet
Bye de Rtcp) ou simplement de fournir une indication sur leur
comportement.

Le protocole Rtcp demande aux participants de la session

d’envoyer périodiquement les informations citées ci-dessus. La
périodicité est calculée en fonction du nombre de participants
de l’application. On peut dire que les paquets Rtp ne
transportent que les données des utilisateurs. Tandis que les
paquets Rtcp ne transportent en temps réel, que de la
supervision. On peut détailler les paquets de supervision en 5
types:

200 : rapport de l’émetteur

201 : rapport du récepteur

202 : description de la source

203 : au revoir
204 : application spécifique

Ces différents paquets de supervision fournissent aux nœuds

du réseau les instructions nécessaires à un meilleur contrôle
des applications temps réel.

6.3.5 - Entête Rtcp

Ce protocole défini cinq paquets de contrôle :

200 - SR (Sender Report) : Ce rapport regroupe des

statistiques concernant la transmission (pourcentage de
perte, nombre cumulé de paquets perdus, variation de
délai (gigue), …Ces rapports sont issus d'émetteurs actifs
d'une session.

201 - RR (Receiver Report) : Ensemble de statistiques portant

sur la communication entre les participants. Ces rapports
sont issus des récepteurs d'une session.

202 - SDES (Source Description) : Carte de visite de la source

(nom, e-mail, localisation).

203 - BYE : Message de fin de participation à une session.

204 - APP : Fonctions spécifiques à une application.

Voici l'en-tête commun à tous les paquets Rtcp.

6.3.5.1 - V

Ce champ, codé sur 2 bits, permet d'indiquer la version de Rtp,

qui est la même que dans les paquets Rtcp. Actuellement,
V=2.
6.3.5.2 - P

Ce bit indique, si il est à 1, que les données possèdent une

partie de bourrage.

6.3.5.3 - RC

Ce champ, basé sur 5 bits, indique le nombre de blocs de

rapport de réception contenus en ce paquet. Une valeur de
zéro est valide.

6.3.5.4 - PT

Ce champ, codé sur 1 octet, est fixé à 200 pour identifier ce

datagramme Rtcp comme SR.

6.3.5.5 - Longueur

Ce champ de 2 octets, représente la longueur de ce paquet

Rtcp incluant l'entête et le bourrage.

6.3.5.6 - SSRC

Basé sur 4 octets, ce champ, représente l'identification de la

source pour le créeateur de ce paquet SR.

6.3.6 - Conclusion

Rtp nécessite le protocole de transport Udp, (en-tête 8 octets),

qui fournira les numéros de port source et destination
nécessaire à la couche application. Pour l’instant le protocole
Rtp se trouve au dessus de Udp, tandis que dans le futur, on
aura une indépendance vis à vis des couches réseaux.

En résumant, ces deux protocoles sont adaptés pour la

transmission de données temps réel. Cependant, ils
fonctionnent en stratégie bout à bout et donc ne peuvent
contrôler l'élément principal de la communication : le réseau.

Ces protocoles sont principalement utilisés en visioconférence

où les participants sont tour à tour émetteurs ou récepteurs.
Pour le transport de la voix, ils permettent une transmission
correcte sur des réseaux bien ciblés. C'est-à-dire, des réseaux
qui implémentent une qualité de service adaptée. Des réseaux
bien dimensionnés (bande passante, déterminisme des
couches sous-jacentes, Cos, ...) peuvent aussi se servir de
cette solution.

6.4 - H261

Le protocole H.261 est décrit dans la RFC 2032, cette norme

décrit le transport d’un flux vidéo sur Rtp. Le format de l’en-
tête est le suivant :
SBIT (Start Bit) - Basé sur 3 bits, ce champ représente le
nombre de bits de poids forts à ignorer dans le premier octet
de données.

EBIT (End Bit) - Basé sur 3 bits, ce champ représente le

nombre de bits de poids faible à ignorer dans le dernier octet
de données.

I (Intra-frame encoded data flag) - Basé sur 1 bit, ce flag doit

être mis à 1 si il contient seulement des intra-frame codé.

V (Motion Vector) - Basé sur 1 bit, ce flag indique si le Motion

Vector est utilisé ou pas.

GOBN (GOB number) - Basé sur 4 bits, ce champ code le

nombre de GOB actif au début du paquet. Placez à 0 si le
paquet commence par un en-tête de GOB.

MBAP (Macroblock Address Predictor) - Basé sur 5 bits, ce

champ code le prédicteur d'adresse de Macroblock. Placez à 0
si le paquet commence par un en-tête de GOB.

QUANT (Quantizer) - Basé sur 5 bits, ce champ représente la

valeur actif avant le début de ce paquet.

HMVD (Horizontal Motion Vector Data) - Basé sur 5 bits, ce

champ doit être à 0 si le flag V est à
0 ou si le paquet commence avec une entête Gob.

VMVD (Vertical Motion Vector Data) - Basé sur 5 bits, ce

champ doit être à 0 si le flag V est à 0 ou si le paquet
commence avec une entête Gob.

6.5 - Audio

Le transport de la voix sur un réseau IP nécessite au préalable

tout ou une partie des étapes suivantes :
Numérisation : dans le cas où les signaux téléphoniques à
transmettre sont sous forme analogique, ces derniers doivent
d’abord être convertis sous forme numérique suivant le format
PCM (Pulse Code Modulation) à 64 Kbps. Si l’interface
téléphonique est numérique (accès RNIS, par exemple), cette
fonction est omise.

Compression : le signal numérique PCM à 64 Kbps est

compressé selon l’un des formats de codec (compression /
décompression) (Tableau 3-3) puis inséré dans des paquets
IP. La fonction de codec est le plus souvent réalisée par un
DSP (Digital Signal Processor). Selon la bande passante à
disposition, le signal voix peut également être transporté dans
son format originel à 64 Kbps.

Décompression : côté réception, les informations reçues sont

décompressées .il est nécessaire pour cela d’utiliser le même
codec que pour la compression- puis reconverties dans le
format approprié pour le destinataire (analogique, PCM
64Kbps, etc.).

L’objectif d’un codec est d’obtenir une bonne qualité de voix

avec un débit et un délai de compression le plus faibles
possibles. Le coût du DSP est lié à la complexité du codec
utilisé. Le Tableau ci-dessous présente les caractéristiques des
principaux codecs standards de l’UIT. Les codecs les plus
souvent mis en oeuvre dans les solutions VoIP sont G.711,
G.729 et G.723.1.

La qualité d’un codec est mesurée de façon subjective en

laboratoire par une population test de personnes. Ces
dernières écoutent tout un ensemble de conversations
compressées selon les différents codecs à tester et les
évaluent qualitativement selon la table suivante :

Tableau : Echelle utilisé pour l'évaluation de la qualité de voix

Qualité de la parole Score

Excellente 5
Bonne 4
Correcte 3
Pauvre 2
Insuffisante 1

Sur la base des données numériques des appréciations, une

opinion moyenne de la qualité d'écoute (Mean Opinion Score .
MOS) est ensuite calculée pour chaque codec. Les résultats
obtenus pour les principaux codecs sont résumés dans le
tableau ci-dessous :

Tableau : Score MOSdes différents codecs

Codec VoIP Débit (Kbps) Score MOS
 G.711 (PCM) 64 4.1
G.726 32 3.85
G.729 8 3.92
G.723.1 6.4 3.9
G.723.1 5.3 3.65
GSM 13 3.5
G.729 x2 3.27
G.729 x3 2.68
G.729 x GSM 3.17

Deux observations principales peuvent être tirées du Tableau

3-5 :

La qualité de la voix obtenue par les codecs G.729 et G.723.1

(à 6.4Kbps) est très proche de celle du service téléphonique
actuel, et ce pour des débits entre 8 et 10 fois inférieurs. Ces
deux codecs présentent une meilleure qualité que celle des
réseaux téléphoniques cellulaires (GSM).

Le cumul, dans une même communication, d’opérations de

compression/décompression conduit à une rapide dégradation
de la qualité. Les solutions mises en oeuvre doivent éviter des
configurations en tandem dans lesquelles un PBX reçoit un
appel d’un poste distant à travers une liaison VoIP et le
redirige vers une autre liaison semblable.

Offrant une qualité de voix très proche, les codecs G.729 et

G.723.1 se distinguent essentiellement par la bande passante
qu’ils requièrent et par le retard que chacun introduit dans la
transmission. Le choix d’un équipement implémentant l’un ou
l’autre de ces codecs devra donc être fait selon la situation, en
fonction notamment de la bande passante à disposition et du
retard cumulé maximum estimé pour chaque liaison (selon les
standards de l’UIT, le retard aller (« one-way delay ») devrait
être inférieur à 150 ms). Le facteur du jitter est primordiale
pour une bonne écoute de la Voip.

7 - Problème & QoS

7.1 - Latence

La maîtrise du délai de transmission est un élément essentiel

pour bénéficier d'un véritable mode conversationnel et
minimiser la perception d'écho (similaire aux désagréments
causés par les conversations par satellites, désormais
largement remplacés par les câbles pour ce type d'usage).

Or la durée de traversée d'un réseau IP dépend de nombreux

facteurs:

Le débit de transmission sur chaque lien

Le nombre d’éléments réseaux traversés

Le temps de traversée de chaque élément, qui est lui même
fonction de la puissance et la charge de ce dernier, du temps
de mise en file d'attente des paquets, et du temps d'accès en
sortie de l’élément

Le délai de propagation de l'information, qui est non

négligeable si on communique à l'opposé de la terre. Une
transmission par fibre optique, à l'opposé de la terre, dure
environ 70 ms.

Noter que le temps de transport de l'information n'est pas le

seul facteur responsable de la durée totale de traitement de la
parole. Le temps de codage et la mise en paquet de la voix
contribuent aussi de manière importante à ce délai.

Il est important de rappeler que sur les réseaux IP actuels

(sans mécanismes de garantie de qualité de service), chaque
paquet IP « fait sont chemin » indépendamment des paquets
qui le précèdent ou le suivent: c'est ce qu'on appelle
grossièrement le « Best effort » pour signifier que le réseau
ne contrôle rien. Ce fonctionnement est fondamentalement
différent de celui du réseau téléphonique où un circuit est
établi pendant toute la durée de la communication.

Les chiffres suivants (tirés de la recommandation UIT-T G114)

sont donnés à titre indicatif pour préciser les classes de
qualité et d'interactivité en fonction du retard de transmission
dans une conversation téléphonique. Ces chiffres concernent
le délai total de traitement, et pas uniquement le temps de
transmission de l'information sur le réseau.

Classe n° Délai par sens Commentaires

Classe n° Délai par sens Commentaires

1 0 à 150 ms Acceptable pour la plupart des

conversations
2 150 à 300 ms Acceptable pour des
communications faiblement interactives
3 300 à 700 ms Devient pratiquement une
communication half duplex
4 Au delà de 700 ms Inutilisable sans une
bonne pratique de la conversation half duplex

En conclusion, on considère généralement que la limite

supérieure "acceptable" , pour une communication
téléphonique, se situe entre 150 et 200 ms par sens de
transmission (en considérant à la fois le traitement de la voix
et le délai d'acheminement).

7.2 - Perte de paquets

Lorsque les buffers des différents élément réseaux IP sont

congestionnés, ils « libèrent » automatiquement de la bande
passante en se débarrassant d'une certaine proportion des
paquets entrant, en fonction de seuils prédéfinis. Cela permet
également d'envoyer un signal implicite aux terminaux TCP
qui diminuent d'autant leur débit au vu des acquittements
négatifs émis par le destinataire qui ne reçoit plus les paquets.
Malheureusement, pour les paquets de voix, qui sont véhiculés
au dessus d'UDP, aucun mécanisme de contrôle de flux ou de
retransmission des paquets perdus n'est offert au niveau du
transport. D'où l'importance des protocoles RTP et RTCP qui
permettent de déterminer le taux de perte de paquet, et d'agir
en conséquence au niveau applicatif.

Si aucun mécanisme performant de récupération des paquets

perdus n'est mis en place (cas le plus fréquent dans les
équipements actuels), alors la perte de paquet IP se traduit
par des ruptures au niveau de la conversation et une
impression de hachure de la parole. Cette dégradation est bien
sûr accentuée si chaque paquet contient un long temps de
parole (plusieurs trames de voix de paquet). Par ailleurs, les
codeurs à très faible débit sont généralement plus sensibles à
la perte d'information, et mettent plus de temps à «
reconstruire
» un codage fidèle.

Enfin connaître le pourcentage de perte de paquets sur une

liaison n'est pas suffisant pour déterminer la qualité de la voix
que l'on peut espérer, mais cela donne une bonne
approximation. En effet, un autre facteur essentiel intervient;
il s'agit du modèle de répartition de cette perte de paquets,
qui peut être soit « régulièrement » répartie, soit répartie de
manière corrélée, c'est à dire avec des pics de perte lors des
phases de congestion, suivies de phases moins dégradées en
terme de QoS.

7.3 - Gigue

La gigue est la variance statistique du délai de transmission.

En d'autres termes, elle mesure la variation temporelle entre
le moment où deux paquets auraient dû arriver et le moment
de leur arrivée effective. Cette irrégularité d'arrivée des
paquets est due à de multiples raisons dont: l'encapsulation
des paquets IP dans les protocoles supportés, la charge du
réseau à un instant donné, la variation des chemins empruntés
dans le réseau, etc…

Pour compenser la gigue, on utilise généralement des

mémoires tampon (buffer de gigue) qui permettent de lisser
l'irrégularité des paquets. Malheureusement ces paquets
présentent l'inconvénient de rallonger d'autant le temps de
traversée global du système. Leur taille doit donc être
soigneusement définie, et si possible adaptée de manière
dynamique aux conditions du réseau.

La dégradation de la qualité de service due à la présence de

gigue, se traduit en fait, par une combinaison des deux
facteurs cités précédemment: le délai et la perte de paquets;
puisque d'une part on introduit un délai supplémentaire de
traitement (buffer de gigue) lorsque l'on décide d'attendre les
paquets qui arrivent en retard, et que d'autre part on finit tout
de même par perte certains paquets lorsque ceux-ci ont un
retard qui dépasse le délai maximum autorisé par le buffer.

8 - Etat du marché

On compte une bonne vingtaine de firmes sur le marché. Les

principaux sont Cisco, Clarent, Avaya, Alcatel, Nortel Network,
Siemens, Ténovis, 3COM … Ce qu’il faut souligner, c’est le fait
qu’il y ait peu de concurrents car comme je l’ai dit
précédemment, la téléphonie sur Ip est un marché très jeune
et très novateur. D’ailleurs, le fait que la téléphonie sur IP soit
un marché chevauchant 2 secteurs qui se rapprochent et
étaient complètement différent auparavant, la téléphonie et
l’informatique, nous assistons ici à une concurrence ayant des
origines différentes. En effet, nous retrouvons le géant de
l’équipement réseaux Cisco en concurrence avec des
entreprises de téléphonies tel que Alcatel ou Siemens. Mais
Cisco et Clarent arrivent largement en tête, sur un marché qui
de 259 millions de dollars cette année pourrait atteindre 2,89
milliards en 2006. La téléphonie sur IP propose 3 types de
terminaux différents : Les hardphones qui sont des téléphones
physiques IP, les softphones qui sont des logiciels permettant
de téléphoner sur IP au travers d’un PC et les téléphones IP
Wi-fi qui sont des téléphones sans-fil IP. Mais la plupart des
concurrents proposent ces 3 produits qui sont plutôt
homogènes. Un softphone Cisco et un Softphone Siemens sont
quasi-identiques. Seule l’interface graphique les distingue.
Pour le client, le produit des 2 concurrents est identique dans
la mesure où il apporte les mêmes services.

9 - Conclusion

Actuellement, il est évident que la téléphonie IP va continuer

de se développer dans les prochaines années. Le marché de la
téléphonie IP est très jeune mais se développe à une vitesse
fulgurante. C’est aujourd’hui que les entreprises doivent
investir dans la téléphonie IP si elles veulent y jouer un rôle
majeur.

Le fait est que IP est maintenant un protocole très répandu,

qui a fait ses preuves et que beaucoup d’entreprises disposent
avantage de la téléphonie IP, car elle demande un
investissement relativement faible pour son déploiement. La
téléphonie IP ouvre la voie de la convergence voix/données et
celle de l’explosion de nouveaux services tels que les CTI.

Maintenant que la normalisation a atteint une certaine

maturité, il n’est plus dangereux de miser sur le standard
H323 qui a été accepté par l’ensemble de la communauté.

La téléphonie IP est une bonne solution en matière

d’intégration, de fiabilité, d’évolutivité et de coût. Elle fera
partie intégrante des Intranets d’entreprises dans les années
à venir et apparaîtra aussi dans la téléphonie publique pour
permettre des communications à bas coût.
Enfin, le développement de cette technologie représente-t-il
un risque ou une opportunité pour les opérateurs traditionnels
? La réponse n’est pas tranchée. D’un coté, une stagnation des
communications classiques; d’un autre coté l’utilisation
massive d’Internet va augmenter le trafic et développer de
nouveaux services que pourront développer les opérateurs.
Bientôt nous téléphonerons tous sur IP...

On peut ainsi vraisemblablement penser que le protocole IP

deviendra un jour un standard unique permettant
l'interopérabilité des réseaux mondialisés. C'est pourquoi
l'intégration de la voix sur IP n'est qu'une étape vers EoIP :
Everything over IP.
 Les concepts de la VoIP

1. Acquisition du signal:
La première étape consiste naturellement à capter la voix à l’aide d’un micro, qu’il
s’agisse de celui d’un téléphone ou d’un micro casque .

2. Numérisation
La voix passe alors dans un convertisseur analogique numérique qui réalise deux
tâches distinctes échantillonnage du signal sonore: un prélèvement périodique de
ce signal, il s'agit d'enregistrer à des intervalles très rapprochés la valeur d'un
signal afin de pouvoir disposer d'un enregistrement proche de la valeur réelle de
ce signal. quantification, qui consiste à affecter une valeur numérique (en binaire)
à chaque échantillon.

Plus les échantillons sont codés sur un nombre de bits important, meilleure
sera la qualité

3. Compression
 Le signal une fois numérisé peut être traité par un DSP (Digital Signal
Processor) qui va le compresser, c’est-à-dire réduire la quantité
d’informations nécessaire pour l’exprimer .

L’avantage de la compression est de réduire la bande passante nécessaire

pour transmettre le signal

4. Habillage des en-têtes

Les données doivent encore être enrichies en informations avant d’être

converties en paquets de données à expédier sur le réseau

Exple: type de traffic syncronisation: s’assurer du

réassemblage des paquets dans l’ordre

4. Emission et transport
Les paquets sont achemianés depuis le point d’émission pour atteindre
le point de réception sans qu’un chemin précis soit réservé pour leur
transport.

6. Réception

Lorsque les paquets arrivent à destination, il est essentiel de les replacer

dans le bon ordre et assez rapidement. Faute de quoi une dégradation
de la voix se fera sentir.

7. Conversion numérique analogique:

La conversion numérique analogique est l’étape réciproque de l’étape 2.

8. Restitution
Dès lors, la voix peut être retranscrite par le haut-parleur du casque, du
combiné téléphonique ou de l’ordinateur.