Le RTP (Real-time Transport Protocol, RFC 3550) porte la voix ou la vidéo réelle après que le SIP a négocié la session, fonctionnant sur UDP avec un en-tête compact (numéro de séquence, timestamp, SSRC). Le RTCP rapporte la qualité en parallèle. Le SRTP (RFC 3711) ajoute chiffrement et authentification au RTP, avec keying via SDES dans le SDP ou DTLS-SRTP.
RTP : porter les médias
Une fois que le SIP et le SDP se sont accordés sur la session, les médias eux-mêmes circulent sur RTP — presque toujours sur UDP, car l'audio temps réel préfère une remise à l'heure à une remise garantie. Chaque paquet RTP porte un morceau d'audio encodé (une trame de codec telle que 20 ms de G.711) derrière un en-tête de 12 octets. Le RTP est un flux distinct de la signalisation SIP, sur les ports négociés par le SDP, et circule généralement directement entre les points d'extrémité ou via un relais média plutôt qu'en suivant le chemin de signalisation.
L'en-tête RTP
L'en-tête RTP de 12 octets donne au récepteur tout ce qu'il faut pour reconstruire un flux temps réel. Le numéro de séquence détecte les pertes et les réordonnancements. Le timestamp reflète l'instant d'échantillonnage pour que le récepteur restitue l'audio à la bonne cadence et retire la gigue avec un tampon de gigue. Le SSRC identifie de façon unique la source média au sein de la session. Le payload type reprend le codec convenu dans le SDP. Le bit marker signale des événements comme le premier paquet après une période de silence.
| Champ | Taille | Objectif |
|---|---|---|
| V / P / X / CC | 1 octet | Version, bourrage (padding), extension, nombre de CSRC |
| M (marqueur) + PT | 1 octet | Bit marqueur + type de charge utile (codec du SDP) |
| Numéro de séquence | 2 octets | Détection des pertes de paquets et réordonnancement |
| Horodatage | 4 octets | Instant d'échantillonnage ; pilote la restitution / le tampon de gigue |
| SSRC | 4 octets | Source de synchronisation — identifie le flux |
| CSRC (0–15) | 0–60 octets | Sources contributrices (issues de mixeurs) |
RTCP : retour de qualité
Le RTP voyage avec un protocole de contrôle compagnon, le RTCP, sur le port adjacent (impair). Le RTCP ne porte aucun média ; chaque côté envoie plutôt périodiquement des Sender Reports et Receiver Reports décrivant la santé du flux — paquets envoyés et perdus, perte cumulée, gigue d'interarrivée, et le temps aller-retour dérivé des timestamps des rapports. Ces métriques sont la matière première des estimations de MOS et du diagnostic de l'audio unidirectionnel, de la gigue et des pertes sur un appel VoIP. Le RTCP porte aussi la description de source (CNAME) et BYE pour la fin de flux.
| Métrique | Ce que cela vous dit |
|---|---|
| Perte de paquets (fraction + cumulée) | Quelle quantité d'audio est perdue |
| Gigue inter-arrivées | Variation du temps d'arrivée des paquets — difficulté de restitution |
| Temps aller-retour | Latence du chemin (à partir des horodatages SR/RR) |
| Séquence la plus élevée reçue | Détection de progression et de pertes par source |
SRTP : chiffrer les médias
Le RTP simple n'est pas chiffré, si bien que quiconque sur le chemin peut capturer et rejouer l'audio. Le SRTP (RFC 3711) le sécurise : il chiffre la charge utile RTP (par défaut AES en mode compteur) et ajoute un tag d'authentification (par défaut HMAC-SHA1) qui protège l'intégrité et fournit une protection contre le rejeu, tout en laissant l'en-tête RTP lisible pour que routeurs et tampons de gigue fonctionnent encore. Le transport apparaît dans le SDP comme RTP/SAVP au lieu de RTP/AVP. Le SRTP protège confidentialité et intégrité mais dépend entièrement de la façon dont ses clés sont échangées.
Keying du SRTP : SDES vs DTLS-SRTP
Le SRTP a besoin d'une clé maîtresse à chaque extrémité, et les deux façons courantes de la livrer diffèrent nettement en sécurité. SDES (RFC 4568) place la clé dans une ligne a=crypto du SDP — simple, mais seulement aussi sûr que la signalisation SIP, il doit donc être porté sur TLS sous peine d'exposer la clé. DTLS-SRTP (RFC 5763/5764) exécute plutôt un handshake DTLS dans le chemin média pour dériver les clés, si bien que la clé n'apparaît jamais dans la signalisation ; c'est le modèle imposé par WebRTC. Choisissez DTLS-SRTP là où les points d'extrémité le prennent en charge, et protégez toujours SDES avec le SIP sur TLS.
| Méthode | RFC | Où réside la clé | Note |
|---|---|---|---|
| SDES | RFC 4568 | a=ligne crypto dans le SDP | Nécessite SIP sur TLS pour être sûr |
| DTLS-SRTP | RFC 5763/5764 | Dérivé d'une négociation DTLS dans le chemin média | Clé jamais transmise dans la signalisation ; utilisée par WebRTC |
| MIKEY | RFC 3830 | Charge utile de gestion des clés | Utilisé dans certains déploiements IMS |
Questions fréquemment posées
Quelle différence entre SIP et RTP ?
Le SIP est la signalisation qui établit, modifie et termine un appel ; le RTP est le transport média qui porte la voix ou la vidéo réelle une fois l'appel établi. Ils fonctionnent comme des flux distincts sur des ports distincts — le SIP négocie la session, le RTP la remet.
Pourquoi le RTP fonctionne-t-il sur UDP plutôt que TCP ?
L'audio temps réel valorise la ponctualité plus que la fiabilité. La retransmission et le blocage de tête de ligne de TCP ajouteraient latence et gigue qui nuisent à un appel en direct plus qu'un paquet occasionnellement perdu. Le RTP sur UDP permet au récepteur de dissimuler de petites pertes tout en gardant le flux à l'heure.
Que fait le RTCP ?
Le RTCP est le canal de contrôle compagnon du RTP. Il ne porte aucun média ; il rapporte périodiquement la qualité du flux — perte de paquets, gigue et temps aller-retour via les Sender et Receiver Reports — ce qui sert à estimer la qualité d'appel (MOS) et à diagnostiquer des problèmes comme l'audio unidirectionnel.
Qu'est-ce que le SRTP ?
Le SRTP (RFC 3711) est le profil sécurisé du RTP. Il chiffre la charge utile média (généralement AES en mode compteur) et authentifie chaque paquet (généralement HMAC-SHA1) avec protection contre le rejeu, tout en gardant l'en-tête RTP en clair. Dans le SDP, il apparaît comme le transport RTP/SAVP.
Quelle différence entre SDES et DTLS-SRTP ?
Les deux fournissent la clé du SRTP. SDES porte la clé dans une ligne a=crypto du SDP, il n'est donc sûr que si la signalisation SIP est elle-même protégée par TLS. DTLS-SRTP dérive les clés via un handshake DTLS dans le chemin média, si bien que la clé ne touche jamais la signalisation — l'approche exigée par WebRTC.
Spécifications sources
Les normes publiées sur lesquelles repose cette page. S'ouvre dans un nouvel onglet.