Le protocole SDP

Il s’agit ici de résoudre les problèmes que peut rencontrer une communication de point à point, entre deux postes A et B, chacun d’eux hébergé dans un réseau local raccordé à internet par une passerelle faisant office de routeur. Par hypothèse, ces postes n’utilisent aucune NAT statique, et cette communication doit donc utiliser des NAT dynamiques.
De telles NAT dynamiques peuvent avoir été créées auparavant par des connexions initiées par chacun de ces postes, dans le cadre de la session de signalisation précédant cette communication (voir billets précédents).
La communication elle-même sera permise par la mise en œuvre de NAT dynamiques, qu’elle devra elle aussi pouvoir utiliser "dans les deux sens".

Pour ce faire, un premier problème à résoudre fut le suivant :
- lors d’une session TCP, si un poste A émet une requête à destination d’un serveur S à partir d’une adresse IP et d’un port de communication publics – donc après passage de la NAT dynamique incidemment créée -, le serveur S envoie ses réponses à destination de cette même adresse IP et de ce même port. Cette propriété du protocole TCP permet d’envisager d’utiliser "à l’envers" la NAT dynamique créée dans le routeur du réseau local du poste A, lors la connexion de ce poste.
- mais le protocole RTP ("Real-Time Transport Protocol"), généralement utilisé pour les communications audio ou/et vidéo, repose le plus souvent sur UDP (RFC 3550, de juillet 2003). Il en est de même du protocole RTCP ("Real-Time Transport Control Protocol"), le protocole de contrôle des flux RTP, qui permet de véhiculer des informations basiques sur les participants d’une session, et sur la qualité de service.
Or le protocole UDP ne garantit aucunement qu’une réponse à une requête sera envoyée à la même adresse IP et sur le même port de communication que ceux utilisés par la source de cette requête.
Dans un tel cas, il appartient alors au protocole de plus haut niveau utilisé, au-dessus de UDP, de garantir si nécessaire cette symétrie. Par exemple :
- c’est le cas du protocole DNS,
- mas pas du protocole TFTP ("Trivial File Transfer Protocol"), plus simple et plus limité que le FTP qui, lui, utilise TCP.
C’est la RFC 4961 de juillet 2007 qui définit cette propriété pour les protocoles RTP et RTCP. Ces protocoles RTP et RTCP "symétriques" sont donc requis pour franchir des NAT dynamiques.

Pour pouvoir commencer réellement à communiquer, chacun des deux postes concernés doit pouvoir connaître à quelle adresse IP et sur quel port de communication il peut envoyer chaque flux (audio, vidéo). Plus précisément, pour chaque flux :
- le protocole RTP, qui prend en charge ce flux de communication, nécessite la connaissance, pour chacun des deux postes, de l’adresse IP et du port (le plus souvent UDP) publics permettant d’envoyer ce flux à l’autre poste,
- le protocole RTCP nécessite lui aussi des adresses IP et des ports publics permettant à chacun de ces postes d’envoyer un flux de contrôle à l’autre poste.
Ces adresses et ces ports font partie des informations définies par le protocole SDP ("Session Description Protocol"), qui permet de décrire plusieurs autres caractéristiques de la communication envisagée, par exemple les codecs à utiliser.
Le protocole SDP n’a aucune capacité de transport par lui-même : comme indiqué dans les billets précédents, c’est par exemple le protocole SIP, lors de l’envoi de l’invitation à communiquer suivi du retour de la réponse correspondante, qui peut transporter et permettre ainsi d’échanger entre les deux postes les informations définies par ce protocole SDP.

En fait, dans la première RFC décrivant le protocole SDP (RFC 2327, d’avril 1998), ce protocole était présenté dans le contexte de l’annonce d’une session multicast sur le réseau Mbone. Pour le transport, cette RFC mentionnait plutôt :
- le protocole SAP ("Session Announcement Protocol"),
- ou même le mail  : le type de contenu MIME étant alors "application/sdp".
Le protocole SIP n’était même pas mentionné dans le corps de cette RFC, et il n’apparaissait qu’indirectement, par le biais d’une référence à la RFC 3261.

Par la suite, la RFC 3264 de juin 2002 ne place plus seulement le protocole SDP dans le contexte d’une communication multicast, mais aussi dans celui d’une communication unicast, où :
- chacun des postes doit informer l’autre des adresses IP et des ports accessibles,
- une négociation est même nécessaire pour s’accorder sur les codecs à utiliser.
Cette RFC décrit alors un aller-retour entre les deux postes, appelé mécanisme " d’offre/réponse ", par lequel ces postes, utilisant le protocole SDP, s’accordent sur les caractéristiques techniques de la communication envisagée. Le protocole SIP y est explicitement mentionné pour transporter cette offre et cette réponse.

Pour les codecs, le message SDP transporté par une invitation SIP du poste A au poste B indique les codecs utilisables par le poste A. A la réception de cette invitation, le poste B répond positivement ou non pour chacun de ces codecs proposés. Ces réponses, prises en charge par le protocole SDP, sont alors transportées par la réponse SIP du poste B au poste A.

Ce message SDP de réponse contient aussi les adresses IP et les ports de communications que le poste B utilisera pour cette communication.
Pour la traversée des NAT, un premier problème était que dans la première version du protocole SDP (RFC 2327, d’avril 1998), seuls étaient définis, pour chacun des flux de cette communication, les adresses IP et les ports nécessaires pour mettre en œuvre le protocole RTP.
Pour le protocole RTCP, qui utilise alors au minimum des ports différents, cette RFC 2327 indiquait que ces ports se déduisaient de ceux définis pour le protocole RTP "par une méthode algorithmique". La RFC 3264 donnait une précision supplémentaire : des ports de numéros pairs pour RTP, et le numéro de port impair immédiatement supérieur pour RTCP.
Mais il est clair qu’une telle méthode ne garantit en rien que les ports ainsi calculés pour le protocole RTCP permettent de traverser les NAT…
C’est pourquoi la RFC 4566 de juillet 2006 a étendu le protocole SDP : on y trouve maintenant les ports publics utilisables par le protocole RTCP,

Il reste que le principal problème à résoudre est le suivant : comment un poste (A ou B) peut-il déterminer à quelle(s) adresse(s) IP et sur quel(s) port(s) publics l’autre poste peut lui envoyer des flux RTP et RTCP ? Répondre à cette question est indispensable pour permettra l’établissement de la communication elle-même.

Sur ce point, la RFC 5245 d’avril 2010 réunit divers concepts mis au point antérieurement, et décrit une méthode générale pour que des postes puissent "découvrir" le(s) couple(s), adresse/port publics auxquels on peut les joindre dans une communication de poste à poste, et se mettent d’accord entre eux pour utiliser ces adresses et ces ports : c’est le rôle du protocole ICE ("Interactive Connectivity Establishment’), décrit dans cette RFC 5245, et abordé dans le dernier billet de ce groupe de billets.
La partie du protocole ICE qui concerne la découverte de ces adresses et ports de communication s’appuie principalement sur les protocoles STUN et TURN, décrits dans le billet suivant.

 

 

WebRTC et les NAT
Les NAT dynamiques et les NAT statiques
La signalisation SIP et les NAT
Le protocole SDP
Les protocoles STUN et TURN
Le protocole ICE