Le SDP (Session Description Protocol, RFC 4566) est le format texte que le SIP transporte pour décrire une session média — l'adresse IP, les ports, les types de média et les codecs offerts par chaque côté. Ce n'est pas un transport ; c'est une description. Le SIP l'utilise dans un échange offre/réponse (RFC 3264) pour négocier les médias que les points d'extrémité échangeront sur RTP.
Ce qu'est le SDP
Le SDP est un petit format texte, ligne à ligne, qui décrit une session multimédia : quels médias (audio, vidéo), où les envoyer (adresse de connexion et port), quels codecs sont acceptables, et dans quelle direction ils peuvent circuler. Le SIP n'interprète pas les médias eux-mêmes ; il porte le SDP dans le corps du message (Content-Type: application/sdp) et laisse les points d'extrémité s'accorder sur les paramètres. Le SDP est purement descriptif — il ne transporte aucun média et ne négocie rien de lui-même ; la négociation vient de la façon dont le SIP échange deux corps SDP.
La structure de lignes
Un corps SDP est une suite de lignes de type à une seule lettre dans un ordre fixe, répartie en une section de niveau session suivie d'une ou plusieurs sections de niveau média commençant chacune par une ligne m=. Les plus importantes sont o= (origine et id de session), c= (adresse de connexion), m= (type de média, port, transport et formats) et les lignes d'attribut a= qui portent les maps de codec et la direction. Les lignes sont ordonnées et sensibles à la casse.
| Ligne | Nom | Transporte |
|---|---|---|
| v= | Version | Version SDP (0) |
| o= | Origine | Nom d'utilisateur, identifiant/version de session, réseau/adresse |
| s= | Nom de la session | Une étiquette pour la session |
| c= | Connexion | Type de réseau, type d'adresse et adresse IP du média |
| t= | Timing | Heure de début/fin (0 0 pour un appel illimité) |
| m= | Média | Type de média, port, transport (RTP/AVP…) et formats |
| a= | Attributs | rtpmap, fmtp, ptime, direction (sendrecv…) et plus encore |
Le modèle offre/réponse
Le SIP négocie les médias avec le modèle offre/réponse de RFC 3264. Un point d'extrémité envoie une offre SDP (généralement dans l'INVITE) listant les flux média et chaque codec qu'il est prêt à utiliser. L'autre renvoie une réponse SDP (généralement dans le 200 OK) sélectionnant parmi ce qui a été offert — ne gardant que les codecs qu'il prend aussi en charge, dans son ordre de préférence, et fixant la direction. Le résultat est l'intersection convenue par les deux côtés. Une absence de codec commun est ce qui produit un 488 Not Acceptable Here.
v=0
o=alice 2890844526 2890844526 IN IP4 host.example.com
s=-
c=IN IP4 198.51.100.10
t=0 0
m=audio 49170 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=ptime:20
a=sendrecvCodecs et payload types
La ligne m= liste les numéros de payload type RTP, et chaque a=rtpmap fait correspondre un numéro à un codec et une fréquence d'horloge. Les payload types 0–95 incluent des affectations statiques (0 = PCMU/G.711 loi µ, 8 = PCMA/G.711 loi A, 9 = G722, 18 = G729), tandis que 96–127 sont dynamiques et doivent être définis par un rtpmap. a=fmtp porte des paramètres propres au codec, et telephone-event (RFC 4733) est la façon dont le DTMF est négocié. Lister les codecs par ordre de préférence permet au répondeur de choisir le meilleur mutuellement pris en charge.
| PT | Codec | Horloge | Note |
|---|---|---|---|
| 0 | PCMU (G.711 µ-law) | 8000 | Statique ; qualité téléphonique (toll quality) ~64 kbit/s |
| 8 | PCMA (G.711 A-law) | 8000 | Statique ; qualité téléphonique (toll quality) ~64 kbit/s |
| 9 | G722 | 8000 | Bande large (audio 16 kHz) |
| 18 | G729 | 8000 | Statique ; ~8 kbit/s compressé |
| 96–127 | Dynamique (Opus, événement téléphonique…) | variable | Défini par a=rtpmap |
Attributs de direction média
Un attribut de direction a= fixe la façon dont les médias circulent pour un flux. sendrecv est le comportement bidirectionnel normal par défaut. sendonly et recvonly restreignent le flux à une seule direction — utilisés pour la mise en attente, les annonces et les médias unidirectionnels. inactive stoppe entièrement les médias tout en gardant la session active. Basculer ces attributs (par exemple sendonly ⇄ sendrecv dans un re-INVITE) est la façon dont la mise en attente, la reprise et la musique d'attente sont implémentées sans abandonner le dialogue.
| Attribut | Signification |
|---|---|
| a=sendrecv | Envoyer et recevoir des médias (par défaut) |
| a=sendonly | Envoi uniquement (par ex. annonce, ou la partie mise en attente) |
| a=recvonly | Recevoir uniquement (par exemple, la partie mise en attente) |
| a=inactive | Aucun média dans les deux sens ; la session reste active |
Questions fréquemment posées
À quoi sert le SDP en SIP ?
Le SDP décrit la session média — l'adresse IP, les ports, les types de média et les codecs offerts par chaque point d'extrémité. Le SIP porte deux corps SDP dans un échange offre/réponse pour négocier l'audio ou la vidéo que les points d'extrémité échangeront sur RTP. Le SDP lui-même ne porte aucun média.
Qu'est-ce que le modèle offre/réponse SIP ?
Défini dans RFC 3264, c'est la façon dont le SIP négocie les médias : un côté envoie une offre SDP (souvent dans l'INVITE) listant ses médias et codecs, et l'autre renvoie une réponse SDP (souvent dans le 200 OK) sélectionnant le sous-ensemble qu'il prend aussi en charge. L'intersection convenue est ce qui circule.
Que signifie la ligne m= en SDP ?
La ligne m= (média) déclare un flux média : son type (audio/vidéo), le port de destination, le transport (par ex. RTP/AVP ou RTP/SAVP pour SRTP), et la liste des numéros de payload type RTP offerts. Chaque payload type est ensuite décrit par une ligne a=rtpmap.
Comment les codecs sont-ils choisis dans un appel SIP ?
L'offreur liste les codecs acceptables par ordre de préférence dans le SDP. Le répondeur ne garde que ceux qu'il prend aussi en charge et les renvoie, sélectionnant de fait le meilleur codec mutuellement pris en charge. Si les ensembles ne se recoupent pas, la négociation échoue, généralement avec un 488 Not Acceptable Here.
Comment la mise en attente est-elle faite avec le SDP ?
En changeant l'attribut de direction média dans un re-INVITE — par exemple en fixant a=sendonly (ou historiquement une adresse de connexion nulle) pour mettre la partie distante en attente, et a=sendrecv pour reprendre. Le dialogue reste actif ; seule la direction média change.
Spécifications sources
Les normes publiées sur lesquelles repose cette page. S'ouvre dans un nouvel onglet.