ARCHITECTURES

MULTIMÉDIA
PROTOCOLES RTP/RTP
CRTP

Idboufker Noureddine
PhD-PMP-PRINCE2-ITIL-ISO27002, Huawei Certified
n.idboufker@uca.ma
n_idboufker@yahoo.fr
https://www.linkedin.com/in/idboufkernoureddine/
Transport en mode paquet

• Contraintes de transport
– Délai de transit ou latence <= 150ms
– Gigue <= 100ms
– Écho <= 50ms
– Perte de paquets <= 10%

• Problématique
– Transport en temps réel

– Réseau de paquets sans garantie

• de bande passante,
• Délai (Gigue)
• et perte de paquets
VoIP : Mise en oeuvre

Application

Présentation : Codec

Session Perte
H= ensemble
de fonctions
à fournir par
le système Transport

Réseau
Liaison
Physique
Métrique Multiplicative : Packet Loss

Forwarding

IP IP IP IP IP

Tail-
drop

– Causé par la surcharge des équipements

et le bruit au niveau du lien de transport
Pertes en IP

• Taux de perte non négligeable

• Plusieurs causes
– Pannes (pertes négligeable idem RTC)
– Overflow dans les routeurs
– Corruption de l’entête du paquet IP
– Corruption du datagramme UDP ou du segment TCP
• Nécessité de traiter les pertes en VoIP
• RTC plus fiable que IP
Délai de bout en bout

• Dans la téléphonie traditionnelle numérique, le signal

analogique est numérisé grâce à un codeur-décodeur,
appelé codec.
• Le codec transforme le signal analogique en une suite de 0 et
de 1.
• Le temps de transit est du même ordre de grandeur que le
transfert du signal analogique, car le signal ne s’arrête nulle
part.
• La seule perte de temps pourrait provenir du codec, mais ces
équipements très rapides ne modifient pas fondamentalement
le temps de transit.
• En revanche, dans un réseau à transfert de paquets, de
nombreux obstacles se dressent tout au long du cheminement
des informations binaires.
Désordre dans Les réseaux IP
1 3 2
1
3
3
2 1
2
1
3

3
2
3 2

• Le traitement IP engendre le délai et le désordre de paquets

Délai dans les réseaux IP

• L’élément le plus contraignant de l’application de téléphonie par paquet reste

le délai pour aller d’une extrémité à l’autre, puisqu’il faut traverser les deux
terminaux, émetteur et récepteur, de type PC par exemple, ainsi que les
modems, les réseaux d’accès, les passerelles, les routeurs, etc.

• Tolérance

– 150-250 ms maxi, au delà

• Problème d’auditivité: synchronisation en réception…

• Problème d’intéractivité: silence ‘’faux’’…

Rappel Modèle OSI

• Deux fonctions essentielles peuvent être distinguées

pour l’interconnexion d’applications informatiques :
– Couches hautes : assurer l’inter fonctionnement des
processus applicatifs distants : orientées application
(dialogue de bout en bout)
• Organiser le dialogue entre applications

– Couches basses : assurer aux couches hautes un service

de transport fiable : orientées transport (dialogue de
proche en proche)
• Organiser le transport des flux de données
Rappel Modèle OSI

Couches Hautes
Couches orientées Couches orientées
Gestion des applications Protocole Gestion des applications

Couches orientées Protocole Couches orientées

Transport Transport
Couches Basses

Transport de proche en
proche Support Physique de transmission
La couche transport

q Couche de bout en bout

q Couche transport : chargée de régler définitivement tous les problèmes relevant du
déplacement d’information et qui n’auraient pas été réglés par les couches
inférieures

q Accepte les données de la couche session :

q Les découpe éventuellement et s’assure de l’ordonnancement
q Multiplexage de plusieurs messages sur un même canal
q La couche transport est la garante de la QoS : débit, taux d’erreurs, délai de transfert, délai de
connexion et de déconnexion,…

q Assure un transfert transparent de qualité et de bout en bout des

données entre entités de session et ce en les déchargeant des détails d’exécution
q Transport des unités de données appelées messages.
q Ex. TP0, 1, 2, 3 ou 4, TCP, UDP, SPX
Les pertes en VoIP

1. Utilisation du protocole TCP ?

2. Utilisation du protocole UDP ?
Protocole TCP

Protocole TCP

Mode contextuel Transport Contrôle Contrôle de

(connecté) fiable de flux congestion
Rappel du protocole UDP

Protocole de transport non fiable en mode non connecté

• PAS de CONTEXTE:
– Envoi de messages de bout en bout avec minimum de
fonctionnalités.

• PAS de CONTRÔLE de FLUX :

– Pas de garantie d ’arrivée
– Pas de contrôle de séquencement

• SÉCURISATION :
– Somme de contrôle (Dont pseudo-entête)
Le protocole UDP

32 bits

0 31

ADRESSE IP SOURCE
Pseudo
ADRESSE IP DESTINATION
Entête
RÉSERVÉ LONGUEUR UDP

PORT SOURCE PORT DESTINATION

LONGUEUR MESSAGE TOTAL CONTROLE

... DONNÉES ...

Message UDP = DATAGRAMME UDP

TCP Vs UDP

• TCP • UDP
1. Phase de signalisation 1. Pas de signalisation
Lourde 2. Taille datagramme petite
2. Traitement d’erreurs 3. Pas de contrôle
3. Traitement du désordre 1. Flux
4. Contrôle de 2. Congestion
1. Flux 4. Pas de fiabilité
2. Congestion
5. Taille Segment
1. Grande
Traitement des pertes en VoIP

• Utiliser TCP ?
– Pertes dans le réseau détectées par le récepteur TCP
– Traitement des pertes par TCP inadéquat en VoIP
• Re-émission du segment TCP perdu: augmentation de gigue !!
• Réduction de la fenêtre d’émission: diminution du débit et
augmentation du délai !!

• Utiliser UDP ?
– Absence de traitement des pertes
– Pertes dans le réseau non détectées par le récepteur UDP
• UDP ne peut pas reconstituer le flux audio !!
Traitement des pertes en VoIP

• Des deux protocoles candidats au transport des

données multimédias à savoir TCP et UDP,
– l’un est « trop complet »
– et l’autre trop limité.

• Il est cependant possible de partir du protocole UDP

et de lui ajouter des fonctionnalités inspirées de TCP
(ordonnancement).
Applications

• Type 1 • Type 2
– Fiabilité – Temps réel
– Débit variable – Débit constant

– TCP – UDP
Traitement des pertes en VoIP

• Utiliser UDP + un autre mécanisme

– Détection des Pertes

– Mesure de la qualité de la transmission….

– Contribuer à la Fiabilité des transmissions

– Permettre différentes stratégies de traitement des pertes au niveau applicatif

Ce mécanisme = les protocoles RTP/RTCP

Protocoles Temps réels: RTP/RTCP

• RTP “ Real-time Transfer Protocol “

– Protocole pour les trafics “Temps Réel”

• RTP est le standard RFC 1889/1890

– H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
• RTP, Transport Protocol for Real-Time Applications.

– proposé pour la gestion du temps réel ainsi que l’administration

de la session multipoint
Transmission de flux « Temps réel »

Emission

Ack
Canaux pour une session audio

Flux RTP Port 1026

Flux RTCP (SR) Port 1027

Ports UDP dynamiques:

Compris entre 1025 et 65535
RTP = port Pair (2n)
RTCP= port Impair (2n+1)
(ports UDP = 5004,5005 ports par défaut)
Canaux pour une session audio

Flux RTP Port 1026

Flux RTCP (SR) Port 1027

Ports UDP dynamiques:

Compris entre 1025 et 65535
RTP = port Pair (2n)
RTCP= port Impair (2n+1)
(ports UDP = 5004,5005 ports par défaut)
Canaux pour une session audio

Flux RTP Port 1026

Flux RTCP Port 1027

Port 7000 RTP

Port 7001 RTCP

Ports UDP dynamiques:

Compris entre 1025 et 65535
RTP = port Pair (2n)
RTCP= port Impair (2n+1)
(ports UDP = 5004,5005 ports par défaut)
Canaux pour une session audio et vidéo

Flux RTP (A) RTP port = 1026

RTP port = 7000 Flux RTP (A)

Flux RTP (V) RTP port = 1028

RTP port = 7002 Flux RTP (V)

RTCP RTCP port = 1027

RTCP port = 7001 RTCP

Principe RTP

• L’architecture liée à RTP repose sur quelques principes simples :

– Les applications multimédias ont besoin d’une référence temporelle que
ne leur fournit aucun protocole de communication existant ;

– Les applications multimédias doivent disposer d’un protocole de transport

dont la structure de données soit adaptée aux informations de
l’application.

– Les applications qui ont des capacités d’adaptation aux comportements

du réseau doivent disposer des moyens d’évaluer les propriétés du système
de communication (taux d’erreur, délai, gigue, etc.).
Mécanismes RTP et RTCP

• RTP est un protocole permettant :

1. Identification de la payload,
2. Faciliter la synchronisation
3. Mettre en œuvre des numéros de séquence de paquets IP
pour reconstituer les informations de voix ou vidéo même si
le réseau sous-jacent change l’ordre des paquets
4. Ajout de marqueurs temporels pour Horodatage,
5. ....
Mécanismes RTP et RTCP

• RTCP
1. Monitoring des livraisons,
2. la récupération des variations de délai et de perte de
paquets
3. …..
La synchronisation d’horloge

• RTP utilise des estampilles temporelles pour dater les paquets émis.
• Ces informations sont la base de calculs permettant d’évaluer le
délai et la gigue introduits par un système de communication.
• La pertinence de ces informations dépend toute entière de la
précision et de la synchronisation des horloges utilisées dans les
machines qui vont appuyer leurs calculs sur ces valeurs.
• Comment garantir cette nécessaire synchronisation ?
Synchronisation

Tout équipement informatique dispose d'une horloge matérielle ou logicielle.

• Bases de données distribuées.

• Documents sécurisés : certification et cryptographie.
• Aviation : contrôle de trafic et enregistrement de positions.
• Programmation télévision et radio.
• Multimédia : synchronisation pour les téléconférences en temps réel.
• Gestion des réseaux
• ...

Problème: horloge, dérive comme toute montre ordinaire.

Solution: synchroniser les équipements.

La synchronisation d’horloge

• Le problème est alors d’accéder à la référence !!

• Deux solutions sont principalement utilisées pour ce faire :

1. accès par le réseau lui-même, via un protocole dédié

2. ou utilisation d’un mécanisme extérieur pour interpréter les

informations diffusées par certains systèmes à l’échelle
planétaire.
Synchro par protocole : NTP

• Le NTP est né d'une initiative de D.L. Mills via RFC958 de Septembre 1985.
• Network Time Protocol ou (NTP) est un protocole qui permet de synchroniser, via un
réseau IP, l'horloge locale d'ordinateurs sur une référence d'heure.
• NTP fut conçu pour offrir une précision de synchronisation inférieure à la seconde.

[RFC 958] : Network Time Protocol (NTP).

[RFC 1059] : Network Time Protocol (Version 1).
[RFC 1119] : Network Time Protocol (Version 2) Specification and Implementation
[RFC 1305] : Network Time Protocol (Version 3) Specification, Implementation and Analysis.
Architecture NTP

Horloge de Référence

Startum 1
Serveurs Primaires

Startum 2
Serveurs Secondaires

Startum 3
Serveurs Tertiaires

Startum 4
Serveurs Quaternaires

Serveurs -Client Peers Symétriques Broadcast/Multicast Serveur vers Clients

Synchronisation des flux

• RTP permet de séparer les flux audio et vidéo, ce qui offre aux
récepteurs une plus grande flexibilité en leur permettant de
choisir indifféremment de recevoir l’un ou l’autre, avec un
système de priorité.
• RTP permet pour des applications vidéo, de décoder et placer
au bon endroit sur l’écran chaque paquet sans attendre ses
prédécesseurs et pour des applications de voix de reconstituer
les échantillons de parole.
Synchronisation des flux

• Si l’audio et la vidéo sont transmis séparément, le destinataire doit

jouer la séquence audio de façon que cette dernière coïncide
avec la séquence vidéo.
• Pour cela, RTP ajoute aux paquets émis une estampille de date,
appelée horodatage, ou timestamp.
• Cette estampille indique le moment où le paquet a été émis, ce qui
permet de reproduire les mêmes délais inter-paquet et de jouer les
paquets audio et vidéo de manière synchronisée
Format RTP

Entête IP Entête UDP Entête RTP Voix numérisée

Trame
20 octets 8 octets 12 octets (longueur variable)

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 | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional header extension |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format RTP

• V=2: indique la version du protocole RTP utilisée. Actuellement, c’est la 2 qui est
exploitée
• P pour padding (sur 1 bit) :
– bit indiquant si un bourrage est effectué dans les champs de données
du flux multimédia.
– Rappelons que la longueur des données doit être un multiple de 4
octets, d’où la nécessité d’octets de bourrage, notamment pour le
dernier paquet.
– Si P= 1 : le paquet contient des octets de bourrage à la fin, le dernier
octet indique le nombre d'octets devant être ignoré de la charge utile.
Format RTP

• X : Extension bit :
– si X=1 présence d’un paquet d’extension pour l’en-tête de longueur variable
• CC pour CSRC Count (sur 4 bits) :
– nombre de sources ayant contribuées à la génération du
paquet.

• M:
– Marker bit :Il s’agit d’un bit de signalisation. Son interprétation
est définie par un profil d'application (profile) .
Format RTP

• PT : Payload type 7 bits

– Décrit le format de données.

– Il est essentiel compte tenu du nombre important de normes de codage de
signaux audio ou vidéo d’inclure un mécanisme à RTP afin de permettre au
destinataire de connaître le codage utilisé et ainsi pouvoir décoder
correctement.
– RTP réalise cette fonction grâce au numéro de type de contenu (payload type
number) dans le header (en-tête) RTP.
– Les numéros de type de contenu sont spécifiés dans le RFC 3551 (RTP Profile for
Audio and Video Conferences with Minimal Control).
Payload types
Format RTP

• Numéro de Séquence: 16 bits:

– Valeur initiale aléatoire

– La valeur de ce champ est incrémentée de 1 à chaque

paquet RTP envoyé alors que sa valeur initiale est aléatoire.

– Ce champ permet de détecter des paquets RTP perdus.

– identifie le paquet pour reséquencer et détecter la perte

de paquets
Format RTP

• Timestamp ou Horodatage: 32 bits:

– Instant d’échantillonage du premier octet de données encapsulées daans RTP

– Un protocole comme RTP utilise des estampilles temporelles pour dater les paquets
émis.

– Ces informations sont la base de calcul permettant d’évaluer le délai et la gigue

introduits par un système de communication.
– La pertinence de ces informations dépend toute entière de la précision et de la
synchronisation des horloges utilisées dans les machines qui vont appuyer leurs calculs
sur ces valeurs.

– valeur initiale aléatoire

Horodatage

• L’estampille temporelle et la numérotation des paquets comportent toutes

deux des fonctionnalités d’ordonnancement, mais il n’y a pas de
redondance entre ces deux paramètres.

• L’estampille temporelle sert à synchroniser les flux, c’est-à-dire à préciser le

moment où le flux doit être joué.

• De la même façon, si les flux vidéo et audio sont envoyés séparément, ce qui
peut se révéler pratique si tous les intervenants d’une conférence ne peuvent
ou ne veulent supporter les flux vidéo mais se contentent des flux audio,
l’estampille temporelle assure la concordance de la voix avec la vidéo.
Horodatage

• Pour l’audio:
– l’horloge timestap incrémente par 1 pour chaque paquet
RTP reçu (Ex. 125microsec pour 8khz)
– Si l’application génére des paquets de 160 oct chaque
20ms, le timestamp s’incrémente pour chaque 160oct
reçu
– meme en l’absence de média utilisateur si y’a pas de
VAD le timestamp continue à s’incrémenter
Numéro de Séquence

• l’estampille temporelle ne permet pas de détecter les pertes.

• À l’inverse, la numérotation des paquets n’assure pas la synchronisation des
flux mais permet de détecter les pertes.
• Les paquets perdus ne sont pas réémis, puisque les contraintes de temps ne
le permettent généralement pas.
• Cependant, il est important de les détecter afin de permettre une synthèse
des paquets précédents et suivants et ainsi de rendre la perte de paquets
moins sensible aux interlocuteurs.
Équipements

1. Mixer

2. Translater
Mixer

• Application qui reçoit des flux de données de plusieurs

sources (CSRC), en modifie éventuellement le format et
renvoie un seul flux de données agrégé.
– Conférence, il est économique de regrouper dès que possible les
flots sonores provenant de plusieurs sources, puisque, de toutes
façons, ils seront mélangés chez les destinataires.
– Le mixeur se comporte comme une source particulière (une SSRC)
qui regroupe les données de plusieurs autres sources qu’on
appelle alors des CSRC (Contributing Source).
Mixer

• Les paquets émis par une source, quelle qu’elle soit contienne une
information d’identification de la SSRC qui les émet.
• Ces paquets peuvent contenir également l’identification des CSRC qui
sont les sources réelles des informations lorsqu’il s’agit d’un paquet
construit par transformation.
Format RTP

Entête IP Entête UDP Entête RTP Voix numérisée

Trame
20 octets 8 octets 12 octets (longueur variable)

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 | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional header extension |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rôle du Mixer

T1

de T1 : SSRC=1
T3

SSRC=M

CSRC=1
CSRC=2
de T2 : SSRC=2

T2

Exemple : MCU pour conférence à plusieurs

participants
Rôle du Mixer

• Mixer

– Reçoit plusieurs flux de plusieurs sources appelées SSRCs

(Synchronization SouRCe)

– Modifie éventuellement leurs formats

– Renvoie un flux agrégé constitué des sources initiales qui

deviennent des CSRCs (Contributing SouRCe)
Rôle du Translator

T1

de T1 : SSRC=1
de T1 : SSRC=1
de T2 : SSRC=2
T3

de T2 : SSRC=2

T2

• Politique de sécurité
• Adaptation de débit
• Conversion protocolaire ATMàIP; H.323àSIP
Rôle du Translator

• Le convertisseur permet de modifier les codages et

de traverser les pare-feu.
• Le convertisseur (en anglais translator) adapte la
syntaxe des flux entre les liens.
• Par exemple, si, entre deux réseaux, les débits sont
différents, le convertisseur modifie le codec à la
volée.
Rôle du Translator

• Translator
– Reçoit plusieurs flux de plusieurs sources appelées SSRCs
(Synchronization SouRCe)
– Modifie éventuellement leurs formats, le codage, le débits
– Traite éventuellement leur problème de sécurité (firewall)
– Renvoie les flux traités des différentes SSRCs
– Adaptation de fonctionnalités hétérogènes
Utilisation Mixer & Translator

T1

From T1 :
T3
SSRC=1

From T1 : SSRC=1
From T2 : SSRC=2 SSRC=3

CSRC=1
CSRC=2
T2

From T2 :

SSRC=2

1. Politique de sécurité
2. Adaptation de débit
3. Conversion de protocole ATMàIP
Protocole RTCP

• Décrit dans la RFC 3550, RTCP est un protocole de contrôle et

de supervision du réseau.
• Le protocole RTCP est basé sur des transmissions périodiques
de paquets de contrôle par tous les participants dans la
session.
• C'est un protocole de contrôle des flux RTP, permettant de
véhiculer des informations basiques sur les participants d'une
session, et sur la qualité de service.
• Le rôle premier de RTCP est de rendre compte du
comportement du réseau en diffusant les résultats de
statistiques réalisées par les participants à une session RTP.
• Il opère comme une sonde qui rend compte aux émetteurs des
performances dont la communication en cours bénéficie.
Protocole RTCP

• Décrit dans la RFC 3550, RTCP est un protocole de

contrôle et de supervision du réseau.
• Le protocole RTCP est basé sur des transmissions
périodiques de paquets de contrôle par tous les
participants dans la session.
• C'est un protocole de contrôle des flux RTP, permettant
de véhiculer des informations basiques sur les
participants d'une session, et sur la qualité de service.
Protocole RTCP

• Le rôle premier de RTCP est de rendre compte du

comportement du réseau en diffusant les résultats de
statistiques réalisées par les participants à une session
RTP.
• Il opère comme une sonde qui rend compte aux
émetteurs des performances dont la communication
en cours bénéficie.
Protocole RTCP

• Par exemple, si un utilisateur fait de la téléphonie et que, par

le biais du protocole RTCP, son correspondant lui envoie des
rapports signalant un fort taux de perte de paquets,
– il peut considérer que le codec qu’il utilise est trop gourmand pour
être supporté dans les conditions actuelles du réseau.

– Il peut dès lors sélectionner un codec nécessitant moins de

ressources.
Protocole RTCP

• Dans sa spécification, RTCP n’est aucunement

indispensable pour le fonctionnement de RTP.
• La réciproque est vraie également.
• Néanmoins, leur association apporte une cohérence
globale dans le traitement des communications
multimédias.
• Tous deux doivent être pensés et intégrés au niveau
applicatif.
• Les rapports fournis par RTCP peuvent optimiser la
qualité de la transmission.
Schéma fonctionnel

Application VoIP
Rapport

RTP-1 RTCP-1

Réseau Réseau

RTP-2 PT, N°Seq, NTP,…

RTCP-2
Rapport

Application VoIP
Protocole RTCP

• 4 fonctions principales
– fournit un compte-rendu de l’état du réseau
– Transporte un identifiant persistent pour une source RTP:
• CNAME = canonical Name : identificateur pour chaque source RTP
– Détermine la cadence d’envoi des messages RTCP en
fonction du nombre d’utilisateurs
– En option peut transporter des informations de contrôle de
session
Canaux pour une session audio

Port 1026
Flux RTP

RTCP (SR)
Port 1027

RTCP (RR)
Canaux pour une session audio

Flux RTP Flux RTP

Canaux pour une session audio

Flux RTP
Flux RTP

Flux RTCP (SR)

Flux RTCP (SR)
RTCP Format de paquets

1. SR: Sender Report

– Transmission et Réception de statistiques des participants

actifs
2. RR: Receiver Report

– Réception de statistiques des participants passifs

3. SDES: Source Description

- inclut le CNAME
4. BYE: Fin de participation
5. APP: Application spécifique
Paquet BYE

V P RC PT=Bye=203 Lenght
SSRC/CSRC Header
……
Lenght Reason for leaving
RTCP: Sender Report
0 1 2 3
0 1 2 3 4 5 6 7 8 9 012 3 4 5 6 7 8 9 0 1 2 3 4 56 7 8 9 01

V=2 P RC PT=SR=200 Longueur

Entête
SSRC emetteur
Horodatage NTP (mot le + significatif)
Horodatage NTP (mot le - significatif)
Horodatage RTP Statistiques de mon émission
Nombre de paquets envoyés
Nombre d ’octets envoyés
SSRC_1: première source

Taux de perte Nombre cumulé de paquets perdus Statistiques

de ma réception
Plus grand numéro de séquence RTP reçus de cette source Bloc 1
Gigue

Horodatage du dernier Sender Report (LSR) Blocs 1 à 32

Délai par rapport au dernier Sender Report (LSR)

Extension
RTCP: Receiver Report
0 1 2 3
0 1 2 3 4 5 6 7 8 9 012 3 4 5 6 7 8 9 0 1 2 3 4 56 7 8 9 01

V=2 P RC PT=RR=201 Longueur Entête

SSRC emetteur

SSRC_1: première source

Taux de perte Nombre cumulé de paquets perdus

Statistiques
Plus grand numéro de séquence RTP reçus de cette source de ma réception
Bloc 1
Gigue

Horodatage du dernier Sender Report (LSR)

Bloc 1 à 32
Délai par rapport au dernier Sender Report (LSR)

SSRC_2: seconde source

Extension
Optimisation VoIP

• Tous les paquets VoIP sont constitués de deux composantes :

1. Les échantillons voix : de taille compressable
2. Les en-têtes IP/UDP/RTP : de taille fixe
• Constatation pour un même flux
1. Certaines infos des entêtes ne changent pas
• (adresses IP, n° de port UDP, codec…)
2. Certaines infos des entêtes sont prédictibles
• (n° de séquence RTP…)
3. Certains champs sont redondants dans les différentes couches protocolaires.
4. Exemple du champ longueur de l'en-tête IPv4 redondant avec le champ longueur fournit
par le protocole de niveau 2.
• Pour la VoIP presque 50% de l’info transmise est inchangée (durant toute une connexion) lors du
transport ou change de manière prévisible
Champs constants : en-tête IP
32 bits

0 31

VER IHL SERVICE LGR TOTALE

IDENTIFICATION FLG DÉPLACEMENT

DURÉE VIE PROTOCOLE CONTRÔLE

ADRESSE IP SOURCE

ADRESSE IP DESTINATION

OPTIONS BOURRAGE

... DONNÉES ...

Champs constants de l'en-tête IP:

1. version
2. length
3. ToS
4. flags
5. protocol
6. source address
7. destination address
Champs constants : en-tête UDP

• Champs de l'en-tête UDP:

• source port
• destination port
32 bits

0 31

PORT SOURCE PORT DESTINATION

LONGUEUR MESSAGE TOTAL CONTROLE

Champs constants : en-tête RTP

• Champs de l'en-tête RTP:

• version
• extension
• contributing source (CSRC) count
• payload type
• synchronization source (SSRC)
• PT

0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| Contenu RTP| Numéro de séquence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| horodatage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifiant de synchronisation de la source (SSRC) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Identifiant(s) de source de contribution (CSRC) |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Champs variables

• Les champs qui s'incrémentent d'une valeur fixe sont:

– Champs de l'en-tête IP:
• IP identification
– Champs de l'en-tête RTP:
• timestamp
• sequence number
Optimisation VoIP

• Principe
– Ne pas transporter les infos des entêtes inchangées ou prédictibles
– Compresser les autres infos contenues dans les entêtes
– Production d’En-têtes compressés de taille 1 à 5 octets
• cRTP (compressed RTP)
– IETF RFC 2508
• Simple et bien adapté aux accès modem
• Entêtes comprimés de 2 à 5 octets
Mécanismes cRTP

• L’en-tete RTP est de 12 octets

• RTP/UDP/IP è 40 octets
• Les paquets VoIP sont de 60 à 100 octets
– Sur-débit assez grand (40 %)
– Les infos de l’en-tête varient peu d’un paquet à l’autre
– L’idée de compression de l’en-tête RTP : cRTP
– Passage de 40 octets à 2 octets
La Compression de l’en-tete RTP

Avant la compression de l’en-tete RTP

20 bytes 8 bytes 12 bytes 20-160 bytes

IP UDP RTP Payload

Header
40 bytes
• La compression de
l’en-tete RTP nous fait
2 or 4 bytes 20-160 bytes gagner la BP

Header Payload

Après la compression de l’en-tete RTP