SDP — définition, format de description de sessions et rôle dans WebRTC

Qu'est-ce que SDP (Session Description Protocol) ?

SDP est un protocole de couche application conçu pour décrire les paramètres de sessions multimédia au format texte. Il a été développé au sein du groupe de travail MMUSIC (Multiparty Multimedia Session Control) de l'IETF et normalisé pour la première fois dans la RFC 2327 en 1998. En 2021, la spécification actuelle RFC 8866 a été publiée, remplaçant la version précédente RFC 4566.

La tâche principale de SDP est de fournir aux participants de la session toutes les informations nécessaires pour établir une connexion : quels flux multimédia seront transmis, quels codecs sont pris en charge, et sur quelles adresses réseau et ports la transmission aura lieu. SDP ne transmet pas les données multimédia elles-mêmes, mais décrit seulement comment la connexion doit être organisée.

Selon l'IETF RFC 8866, le format SDP consiste en un ensemble de lignes, chacune commençant par un type d'une seule lettre, suivi d'un signe égal et d'une valeur. Par exemple, la ligne m=audio 5004 RTP/AVP 0 signifie que la session inclut un flux audio sur le port 5004 avec le protocole de transport RTP/AVP et le codec PCMU (type 0).

Historique et normalisation de SDP

La première version de SDP a été publiée dans la RFC 2327 en avril 1998 comme résultat du travail du groupe MMUSIC. Le protocole a été initialement créé pour annoncer des sessions multicast au sein de Mbone (Multicast Backbone). Avec le développement de la VoIP et de la visioconférence, le champ d'application de SDP s'est élargi, et en 2006, la spécification mise à jour RFC 4566 a été publiée.

Une véritable percée dans l'utilisation de SDP est survenue avec l'avènement de WebRTC en 2011. Google a intégré SDP comme mécanisme principal de description des sessions média dans son framework de communication en temps réel basé sur le navigateur. Depuis lors, SDP est devenu un composant obligatoire de toute implémentation WebRTC — des navigateurs aux applications mobiles sur iOS et Android.

En 2021, le groupe de travail de l'IETF a publié la RFC 8866 — la spécification actuelle de SDP, remplaçant la RFC 4566. La version mise à jour a clarifié le traitement d'ICE (Interactive Connectivity Establishment), le support de DTLS (Datagram Transport Layer Security) et a élargi les capacités de description des sessions de groupe.

Différence entre SDP et les protocoles de transport

SDP diffère fondamentalement des protocoles de transport en ce qu'il ne participe pas à la transmission des données. Il remplit une fonction purement descriptive — semblable aux métadonnées d'un fichier multimédia. Alors que RTP (Real-time Transport Protocol) transmet les paquets audio et vidéo, et que RTCP contrôle la qualité de transmission, SDP spécifie seulement quels codecs et ports utiliser.

Une analogie tirée du développement web : SDP est comme le balisage HTML décrivant la structure de la page, tandis que RTP est les images et le texte réels. Sans SDP, les participants à la session ne savent pas comment se connecter les uns aux autres, même si la connexion réseau est déjà établie. Le mécanisme de NAT traversal (ICE) repose également sur SDP pour transmettre les informations sur les candidats réseau.

Comment est structuré SDP

La structure SDP est organisée comme une séquence de lignes de texte, chacune suivant le format type=value. Le type d'une seule lettre définit l'objectif de la ligne, et la valeur contient la valeur correspondante. Toutes les lignes sont séparées par un caractère CRLF.

La norme RFC 8866 définit plusieurs champs obligatoires et facultatifs. Les champs obligatoires incluent la version du protocole (v=), le nom de la session (s=) et l'heure de début et de fin de session (t=). Les champs restants sont facultatifs, mais pour les sessions WebRTC, les descriptions de média (m=), les attributs (a=) et les informations réseau (c=) sont également nécessaires.

v=0
o=- 46116397 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 5004 RTP/SAVPF 111 103 104
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
m=video 5006 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

L'exemple ci-dessus montre un segment SDP typique pour une session WebRTC. La ligne v=0 indique la version du protocole. Le champ o= contient l'identifiant du propriétaire de la session et sa version. La ligne s=- spécifie le nom de la session (un trait d'union signifie un nom vide). Le champ t=0 0 indique que la session n'est pas limitée dans le temps.

Le champ a=group:BUNDLE audio video est un attribut qui regroupe plusieurs flux multimédia en un seul canal de transport. Le mécanisme BUNDLE permet d'économiser les ressources réseau en transmettant l'audio et la vidéo via une seule connexion. Ceci est particulièrement important pour les appareils mobiles avec une bande passante limitée.

Champs obligatoires de SDP

La spécification RFC 8866 définit un ensemble de champs obligatoires et facultatifs. Les champs obligatoires incluent v= (version), s= (nom de session) et t= (temps). Le champ o= (propriétaire), bien que n'étant pas strictement obligatoire selon la RFC, est presque toujours présent dans les implémentations réelles.

Le champ m= (media) est l'un des plus importants. Il décrit un flux multimédia spécifique et contient le type de média (audio, video, text, application), le port, le protocole de transport et la liste des codecs pris en charge. Dans WebRTC, les types les plus couramment utilisés sont audio et video avec les protocoles de transport RTP/SAVPF (Secure Audio/Video Profile with Feedback) ou UDP/TLS/RTP/SAVPF.

Le champ a= (attribute) est le plus flexible et le plus extensible. Il peut contenir rtpmap (mappage du numéro de codec au nom), fmtp (paramètres du codec), fingerprint (empreinte de la clé DTLS), ice-ufrag et ice-pwd (identifiants ICE) et de nombreux autres attributs. C'est à travers les attributs que SDP prend en charge les mécanismes modernes de sécurité et de NAT traversal.

Comment SDP fonctionne dans WebRTC

Dans l'architecture WebRTC, SDP sert de protocole de signalisation pour décrire et négocier les paramètres de session multimédia entre deux participants. SDP lui-même ne définit pas le mécanisme de transmission de ces descriptions — cette tâche est gérée par le canal de signalisation, que le développeur implémente indépendamment via WebSocket, HTTP ou un autre protocole.

Le processus commence lorsque l'initiateur (appelant) crée une offre SDP (Offer). Pour ce faire, le navigateur appelle la méthode createOffer() sur l'objet RTCPeerConnection. La description SDP générée contient tous les paramètres de session du côté de l'initiateur : codecs pris en charge, adresses réseau, candidats ICE et exigences de sécurité.

const configuration = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };
const pc = new RTCPeerConnection(configuration);

// Ajouter les pistes média avant createOffer
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Créer une offre SDP
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// Envoyer SDP au pair distant via le canal de signalisation
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Après avoir créé l'Offer et défini la description locale via setLocalDescription(), l'initiateur envoie la chaîne SDP au participant distant via le canal de signalisation. Le participant distant, ayant reçu l'SDP Offer, crée une réponse SDP (Answer) et la renvoie. Cet échange est appelé échange de signalisation et est une étape obligatoire avant d'établir une connexion peer-to-peer.

Selon la spécification WebRTC du W3C, l'échange SDP doit avoir lieu avant le début des candidats ICE. En pratique, de nombreuses implémentations envoient les candidats ICE en parallèle avec SDP en utilisant le mécanisme ICE trickle. Cela réduit le temps d'établissement de la connexion, en particulier pour les réseaux mobiles à latence élevée.

Le rôle d'ICE dans SDP

ICE (Interactive Connectivity Establishment) est un mécanisme qui utilise les attributs SDP pour transmettre des informations sur les candidats réseau. Les candidats ICE décrivent les chemins de connexion possibles : host (adresse locale), srflx (adresse après NAT, obtenue via STUN) et relay (adresse du serveur TURN).

Dans SDP, les candidats ICE sont transmis via des attributs a=candidate:, ainsi que via les champs ice-ufrag et ice-pwd pour l'authentification du trafic ICE. Chaque candidat inclut le protocole de transport (UDP, TCP), l'adresse IP, le port et la priorité. Une connexion réussie est établie via le premier candidat qui réussit les tests de connectivité. Le mécanisme ICE restart permet de mettre à jour la connexion lors d'un changement de réseau.

Pour les applications mobiles, les candidats ICE sont particulièrement importants car les appareils sont souvent derrière un NAT ou des pare-feu d'entreprise. Le mécanisme ICE permet de trouver un chemin fonctionnel même dans des conditions réseau complexes, et SDP sert de conteneur de transport pour ces informations.

Sécurité de SDP dans WebRTC

SDP dans WebRTC inclut nécessairement des attributs de sécurité, en particulier l'empreinte DTLS et les paramètres SRTP. Le champ a=fingerprint:sha-256 contient l'empreinte du certificat DTLS, utilisée pour l'authentification et le chiffrement du flux multimédia. Sans cet attribut, la connexion WebRTC ne sera pas établie.

Les mécanismes de sécurité supplémentaires incluent l'attribut a=setup:, qui définit le rôle de la poignée de main DTLS (active, passive, actpass), et a=ice-lite: pour une implémentation ICE simplifiée côté serveur. Tous ces paramètres sont transmis dans SDP et vérifiés par les deux parties avant le début de la transmission des données multimédia.

Types de SDP : Offer et Answer

Dans le modèle WebRTC, il existe deux types de messages SDP : Offer (offre) et Answer (réponse). L'Offer est créée par l'initiateur de la connexion et contient une description complète de la session multimédia souhaitée. La Answer est créée par le participant distant en réponse à l'Offer et contient ses capacités en tenant compte des contraintes imposées par l'offre.

La principale différence entre Offer et Answer réside dans la sémantique des attributs. L'Offer énumère tous les codecs, protocoles de transport et adresses réseau pris en charge que l'initiateur peut proposer. La Answer sélectionne un sous-ensemble de ces capacités que la partie distante prend en charge. Par exemple, si l'Offer propose opus, ISAC et PCMU, la Answer peut sélectionner uniquement opus comme codec le plus préféré.

Le processus d'échange est régi par la spécification WebRTC du W3C et comprend plusieurs états de RTCPeerConnection. Après avoir créé l'Offer via createOffer() et l'avoir définie comme description locale, la connexion entre dans l'état have-local-offer. Après avoir reçu la Answer et l'avoir définie comme description distante via setRemoteDescription(), la connexion entre dans l'état stable — l'état final prêt pour la transmission multimédia.

Utilisation de SDP dans les SDK mobiles

Les SDK mobiles pour WebRTC — Google WebRTC pour Android et WebRTC.framework pour iOS — prennent entièrement en charge l'échange SDP via Offer et Answer. Sur Android, la classe PeerConnection avec la méthode createOffer() est utilisée pour créer une Offer, similaire à l'API du navigateur. La description SDP résultante est transmise sous forme de chaîne via le canal de signalisation.

Sur iOS, le travail avec SDP se fait via la classe RTCSessionDescription du framework WebRTC. Lors de l'initialisation, le type (RTCSdpTypeOffer ou RTCSdpTypeAnswer) et la chaîne SDP sont spécifiés. La plateforme analyse automatiquement le SDP et configure la connexion selon les paramètres transmis.

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// Créer une offre SDP sur Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Envoyer la chaîne SDP au pair distant
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

La possibilité de travailler directement avec la chaîne SDP donne de la flexibilité aux développeurs : ils peuvent modifier le SDP avant de l'envoyer, ajouter ou supprimer des codecs spécifiques, configurer les paramètres ICE ou ajouter des attributs personnalisés. Pour les applications Android, il est souvent nécessaire de désactiver la vidéo dans SDP lorsque la bande passante réseau est faible — cela se fait en supprimant les lignes m= correspondantes de la description SDP.

SDP dans le développement mobile

Dans le développement mobile, SDP est utilisé principalement dans le contexte de WebRTC — pour créer des applications avec appels vidéo, chats vocaux et streaming. Les applications mobiles sur Android et iOS peuvent agir à la fois comme initiateur et comme récepteur de messages SDP, permettant des connexions peer-to-peer symétriques.

Une caractéristique des applications mobiles est la nécessité de travailler avec SDP dans des conditions de qualité réseau variable. Lors du passage entre le Wi-Fi et l'Internet mobile, ainsi que lors des changements de bande passante, la génération d'une nouvelle description SDP peut être nécessaire. Cela se fait via le mécanisme de renégociation — un échange SDP répété via createOffer() et setLocalDescription().

Selon l'équipe Google WebRTC (2023), l'optimisation de l'échange SDP pour les appareils mobiles inclut l'utilisation d'ICE restart lors des changements de réseau, la priorisation des codecs à faible débit (opus pour l'audio, VP8 pour la vidéo) et la minimisation de la taille de la chaîne SDP en excluant les flux multimédia inutiles. L'avantage clé est la réduction de la latence lors de l'établissement d'une connexion dans des conditions de réseaux mobiles.

Optimisation de SDP pour les réseaux mobiles

L'une des tâches clés lors du travail avec SDP sur les appareils mobiles est de minimiser la taille de la description SDP. Un SDP complet pour une session WebRTC typique avec audio et vidéo peut prendre 2 à 5 Ko, ce qui est significatif pour les réseaux lents. L'optimisation inclut l'utilisation de BUNDLE (multiplexage de flux), la suppression des codecs non pris en charge et la compression des candidats ICE.

Un problème supplémentaire pour les appareils mobiles est la durée de vie limitée du SDP. Dans des conditions de connexion instables, le SDP peut devenir obsolète avant que le participant distant puisse le traiter. La solution consiste à utiliser des délais d'attente courts pour recevoir la Answer et à renvoyer le SDP si nécessaire. Le mécanisme ICE restart permet de mettre à jour la connexion sans recréer complètement le RTCPeerConnection. L'attribut a=ice-lite simplifie l'implémentation ICE côté serveur.

Bibliothèques populaires pour travailler avec SDP

Les développeurs d'applications mobiles ont accès à des bibliothèques prêtes à l'emploi qui simplifient le travail avec SDP. libjingle_peerconnection (Google WebRTC) est la bibliothèque principale pour Android, fournissant une API complète pour la gestion de SDP. Pour iOS, WebRTC.framework avec des fonctionnalités similaires est utilisé. Les deux bibliothèques génèrent et analysent automatiquement le SDP, mais donnent accès à la chaîne SDP brute si nécessaire.

Pour un contrôle plus précis sur SDP, il existe des solutions tierces : sdp-transform (JavaScript ou Node.js) pour analyser et modifier SDP, NICENICE (Java) pour travailler avec les candidats ICE, et des SDK prêts à l'emploi de fournisseurs d'infrastructure WebRTC qui prennent en charge tout l'échange de signalisation, y compris SDP.