Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 5

Décoder les messages SDP : un guide des champs v, o, s, c, t, m et a

Recommended resources

Bonjour. Dans notre exploration précédente, nous avons appris à interpréter les codes de réponse SIP, ce langage qui nous informe du résultat de chaque requête. Nous avons vu que des erreurs comme 488 Not Acceptable Here signalent un échec de négociation des paramètres média. Aujourd'hui, nous allons ouvrir le "capot" des messages SIP pour examiner précisément où et comment ces paramètres sont décrits.

L'objectif de cette leçon est de vous apprendre à décoder le Session Description Protocol (SDP). Alors que SIP établit, modifie et termine les sessions, SDP se charge de décrire le média qui sera échangé : quels codecs, à quelle adresse IP, sur quel port ? En tant qu'expert en communications unifiées, la maîtrise de la lecture du SDP est une compétence de diagnostic non négociable. C'est le contrat qui régit chaque flux audio ou vidéo.

Nous allons décortiquer la structure d'un corps SDP ligne par ligne, en nous concentrant sur les champs essentiels : v=, o=, s=, c=, t=, m= et les attributs a=. Plus important encore, nous ferons immédiatement le lien entre cette théorie et sa mise en pratique sur les SBC AudioCodes, afin que vous puissiez voir comment ces connaissances s'appliquent directement à la manipulation de messages.

Le Rôle du SDP : L'Offre et la Réponse

SIP est conçu pour être agnostique au média. Il ne se préoccupe pas de savoir si vous parlez en G.711 ou en Opus ; il se contente de transporter la description de la session. Cette description est formatée en SDP.

Le mécanisme fonctionne sur un modèle simple appelé Offer/Answer :

  1. L'appelant envoie une requête INVITE contenant une "offre" SDP. Cette offre est une liste exhaustive de ses capacités : "Voici mon adresse IP pour le média, le port que je vais écouter, et tous les codecs que je supporte."
  2. Le destinataire, s'il accepte l'appel, renvoie une réponse 200 OK contenant une "réponse" SDP. Cette réponse sélectionne les paramètres qui seront utilisés pour la session parmi ceux proposés dans l'offre : "Parfait, j'utiliserai ce codec spécifique et je t'enverrai mon média à cette adresse et ce port."

Pour bien comprendre ce concept fondamental, la ressource suivante offre une excellente introduction.

Understanding Session Description Protocol (SDP)

Cet article de blog par Andrew Prokop pose les bases du SDP et de sa relation avec SIP. Il explique clairement le rôle du protocole et le modèle d'offre/réponse.

Lisez la première partie de l'article, depuis l'introduction jusqu'à la fin de la section listant les différentes lignes. Concentrez-vous sur la distinction clé : SDP décrit le média, il ne le négocie pas au sens d'un va-et-vient.

Anatomie d'un Corps SDP

Maintenant que le concept est clair, analysons la structure d'un corps SDP. Chaque ligne suit un format <caractère>=<valeur>. L'image ci-dessous, tirée d'une capture Wireshark, annote les lignes les plus importantes que nous allons étudier.

Cette capture d'écran détaille un corps SDP. Chaque ligne est annotée pour expliquer sa fonction, comme l'adresse IP de destination du flux RTP, le port, la liste des codecs, etc. Nous allons nous référer à cette structure.

La vidéo suivante propose une visite guidée, ligne par ligne, d'un SDP typique. Nous l'utiliserons pour rythmer notre analyse.

SIP #2 SDP (Session Description Protocol) - Cisco Collaboration

Cette vidéo de la chaîne Collab Crush, intitulée "SIP #2 SDP (Session Description Protocol)", décompose un corps SDP en ses trois sections principales : session, temps et média.

Regardez l'introduction de la structure SDP. Nous allons suivre cette même logique.

1. Description de la Session (Session-level)

Ces lignes définissent les paramètres globaux de la session.

  • v=0 (Version) : Indique la version de SDP. La seule version existante est la 0. C'est toujours la première ligne.
  • o= (Origin) : Identifie le créateur de la session. Sa structure est riche : o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>. Le plus important ici est l'adresse IP de la machine qui a généré le message SDP.
  • s= (Session Name) : Un simple nom textuel pour la session, souvent s=SIP Call.
  • c= (Connection Information) : Ligne cruciale. Elle spécifie l'adresse IP où l'équipement s'attend à recevoir le flux média (RTP). Le format est typiquement c=IN IP4 192.168.1.10. S'il est présent au niveau de la session, il s'applique à tous les flux média décrits plus bas, sauf si un flux média spécifie sa propre ligne c=.
  • t= (Time) : Définit la période d'activité de la session. Pour les appels en temps réel comme la VoIP, elle est presque toujours t=0 0, signifiant que la session est permanente et n'a pas d'heure de début ou de fin prédéfinie.

SIP #2 SDP (Session Description Protocol) - Cisco Collaboration

La vidéo détaille maintenant les lignes de la description de session et de temps.

Regardez les explications pour les lignes de session (v=, o=, s=, c=) puis pour la ligne de temps (t=).

2. Description du Média (Media-level)

C'est ici que les détails concrets de chaque flux (audio, vidéo) sont définis. Un SDP peut contenir plusieurs blocs m=, un pour chaque type de média.

  • m= (Media Description) : C'est la ligne qui déclare un flux média. Sa structure est m=<media> <port> <proto> <fmt...>.

    • <media>: audio ou video.
    • <port>: Le port UDP sur lequel l'équipement écoute le flux RTP.
    • <proto>: Le protocole de transport, quasiment toujours RTP/AVP (Real-time Transport Protocol / Audio-Video Profile).
    • <fmt...>: Une liste de numéros séparés par des espaces. Ce sont les identifiants de payload (Payload Type). Chaque numéro correspond à un codec proposé, mais ce n'est pas la ligne m= qui définit cette correspondance.

  • a= (Attribute) : Les lignes d'attributs sont la clé pour interpréter la ligne m=. Elles la qualifient. Il peut y en avoir de nombreuses.

    • a=rtpmap:<payload> <encoding-name>/<clock-rate> : C'est la ligne la plus importante. Elle fait le lien entre un numéro de payload de la ligne m= et un codec spécifique. Par exemple, a=rtpmap:8 PCMA/8000 signifie que le payload 8 correspond au codec G.711 A-law, avec une fréquence d'échantillonnage de 8000 Hz. C'est lors de la comparaison de ces listes de codecs entre l'offre et la réponse qu'un 488 Not Acceptable Here peut être généré.
    • a=ptime:<value> : Définit la durée de paquetisation en millisecondes (par ex. ptime:20 pour 20ms de son par paquet).
    • a=sendrecv / sendonly / recvonly : Indique la direction du flux média. sendrecv est la norme pour un appel standard.
    • a=rtpmap:101 telephone-event/8000 : Un attribut spécial pour la transmission des tonalités DTMF (les chiffres que vous tapez) hors de la bande audio principale, via le standard RFC 2833. Le payload 101 est quasi universellement réservé à cet usage.
Cet exemple illustre bien le lien entre les numéros de payload dans la ligne `m=audio` et les attributs `a=rtpmap` qui définissent les codecs correspondants (PCMA et PCMU).

SIP #2 SDP (Session Description Protocol) - Cisco Collaboration

Cette section de la vidéo est la plus dense. Elle explique en détail le fonctionnement des lignes m= et a=.

Regardez attentivement l'explication sur la description du média. Assurez-vous de bien comprendre comment la ligne m= et les lignes a=rtpmap fonctionnent ensemble pour lister les codecs.

Application Pratique : Le SDP dans l'Univers AudioCodes

Comprendre cette structure est essentiel, mais votre objectif est de la manipuler. C'est là que votre connaissance approfondie des SBC AudioCodes entre en jeu. Le moteur de manipulation de messages d'AudioCodes vous permet de cibler spécifiquement chaque partie du SDP pour lire sa valeur ou la modifier.

Le guide de référence que vous appréciez tant formalise ce lien. Il définit des variables internes qui correspondent directement aux champs SDP que nous venons de voir.

sip-message-manipulation-syntax-reference-guide- ...

Ce document est votre référence pour la manipulation avancée sur AudioCodes. Nous allons ici nous concentrer sur les sections qui mappent les concepts SDP aux variables de manipulation.

Parcourez les sections suivantes pour voir la correspondance directe entre la théorie SDP et la pratique AudioCodes : Origin : Lisez les sections Origin Username et Origin IP Address. Vous verrez que les variables param.message.sdp.originusername et param.message.sdp.originaddress ciblent directement la ligne o=. Media Port & IP : Lisez les sections Port et IP Address (juste après 'Port'). Les variables sdp.port et sdp.address ciblent respectivement le port de la ligne m= et l'adresse IP de la ligne c=. Table de Référence : Pour finir, consultez la Table 3-7 au chapitre 3. Elle résume ces variables (param.message.sdp.ip, param.message.sdp.originusername, param.message.sdp.port, etc.) et confirme leur rôle. Cette lecture vous prépare directement pour le module 5 sur les principes de manipulation et surtout le module 12 sur la manipulation avancée.

Conclusion

Aujourd'hui, nous avons décortiqué le contrat technique d'un appel multimédia : le SDP. Vous êtes maintenant en mesure de lire et d'interpréter sa structure pour comprendre précisément comment les paramètres d'un flux média sont communiqués.

Points clés à retenir :

  • SDP décrit le média selon un modèle Offer/Answer transporté par SIP.
  • Niveau Session : La ligne c= définit l'adresse IP pour le média. La ligne o= identifie l'origine de la session.
  • Niveau Média : La ligne m= annonce un type de média (audio/vidéo), un port et une liste de numéros de payload.
  • Attributs : Les lignes a=rtpmap sont essentielles car elles traduisent les numéros de payload en codecs concrets (G.711, G.729, Opus...).
  • Application AudioCodes : Des variables comme param.message.sdp.ip ou sdp.port vous permettent de cibler ces champs pour les lire ou les réécrire, ce qui est au cœur de la puissance des SBC.

Dans la prochaine et dernière leçon de ce module fondamental, nous allons mettre en pratique tout ce que nous avons appris. Nous verrons comment capturer et filtrer des traces SIP avec Wireshark. Vous pourrez alors voir "en direct" les messages INVITE, les réponses 200 OK, les codes d'erreur et, bien sûr, les corps SDP que nous venons d'étudier.