Aller au contenu principal

RFC 4566 - SDP : Protocole de description de session

  • Statut: Proposed Standard
  • Publié: July 2006
  • Stream: IETF
  • Remplace: RFC2327, RFC3266
  • Remplacé par: RFC8866
  • Errata: Pas d'errata

Résumé (Abstract)​

Ce mémo définit le protocole de description de session (Session Description Protocol, SDP). Le SDP est destiné à décrire les sessions multimédia aux fins d'annonce de session, d'invitation de session et d'autres formes d'initiation de session multimédia.

Table des matières (Contents)​

Ressources associées​

2. Glossaire des termes​

Les termes suivants sont utilisés dans ce document avec des significations spécifiques dans le contexte de ce document.

Conference (conférence) : Une conférence multimédia est un ensemble de deux utilisateurs ou plus qui communiquent, ainsi que les logiciels qu'ils utilisent pour communiquer.

Session (session) : Une session multimédia est un ensemble d'émetteurs et de récepteurs multimédia, ainsi que les flux de données circulant des émetteurs vers les récepteurs. Une conférence multimédia est un exemple de session multimédia.

Session Description (description de session) : Un format bien défini permettant de transmettre suffisamment d'informations pour découvrir une session multimédia et y participer.

Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY » et « OPTIONAL » dans ce document DOIVENT être interprétés comme décrit dans la RFC 2119 [3].

3. Exemples d'utilisation de SDP​

3.1 Session Initiation (initiation de session)​

Le protocole SIP (Session Initiation Protocol) [15] est un protocole de contrôle de couche applicative permettant de créer, modifier et terminer des sessions telles que des conférences multimédia sur Internet, des appels téléphoniques sur Internet et des distributions multimédia. Les messages SIP utilisés pour créer des sessions transportent des descriptions de session permettant aux participants de s'accorder sur un ensemble de types de médias compatibles. Ces descriptions de session sont généralement formatées en SDP. Lorsqu'il est utilisé avec SIP, le modèle offre/réponse (offer/answer model) [17] fournit un cadre limité pour la négociation à l'aide de SDP.

3.2 Streaming Media (médias en flux continu)​

Le protocole RTSP (Real Time Streaming Protocol) [16] est un protocole de niveau applicatif permettant de contrôler la livraison de données ayant des propriétés en temps réel. RTSP fournit un cadre extensible pour permettre la livraison contrôlée à la demande de données en temps réel, telles que l'audio et la vidéo. Les clients et serveurs RTSP négocient un ensemble approprié de paramètres de livraison des médias, en utilisant partiellement la syntaxe SDP pour décrire ces paramètres.

3.3 Email and the World Wide Web (courrier électronique et le Web)​

Les méthodes alternatives pour transmettre des descriptions de session comprennent le courrier électronique et le World Wide Web (WWW). Pour la distribution par courrier électronique et WWW, le type de média « application/sdp » est utilisé. Cela permet aux applications de lancer automatiquement les outils appropriés pour participer à la session depuis un client WWW ou un lecteur de courrier, de manière standardisée.

Notez que les annonces de sessions multicast distribuées uniquement par courrier électronique ou WWW n'ont pas la propriété que les destinataires de l'annonce de session peuvent nécessairement recevoir la session, car la session multicast peut être limitée en portée, et l'accès au serveur WWW ou la réception du courrier électronique peut se trouver en dehors de cette portée.

3.4 Multicast Session Announcement (annonce de session multicast)​

Pour faciliter la diffusion de conférences multimédia multicast et d'autres sessions multicast, et pour communiquer les informations de configuration de session pertinentes aux participants potentiels, un annuaire de sessions distribué peut être utilisé. Une instance d'un tel annuaire de sessions envoie périodiquement des paquets contenant des descriptions de session à un groupe multicast bien connu. Ces annonces sont reçues par d'autres annuaires de sessions afin que les participants distants potentiels puissent utiliser les descriptions de session pour lancer les outils nécessaires à la participation à la session.

Un protocole utilisé pour implémenter un tel annuaire distribué est le protocole SAP (Session Announcement Protocol) [14]. SDP fournit le format de description de session recommandé pour de telles annonces de session.

4. Exigences et recommandations​

L'objectif de SDP est de transmettre des informations sur les flux de médias dans une session multimédia afin de permettre au destinataire d'une description de session de participer à la session. SDP est principalement destiné à être utilisé sur Internet, bien qu'il soit suffisamment générique pour décrire des conférences dans d'autres environnements réseau. Les flux de médias peuvent être de type plusieurs-à-plusieurs. Les sessions n'ont pas besoin d'être actives en permanence.

Jusqu'à présent, les sessions multicast sur Internet se distinguent de nombreuses autres formes de conférence en ce que toute personne recevant le trafic peut rejoindre la session (à moins que le trafic de la session ne soit chiffré). Dans un tel environnement, SDP a deux objectifs principaux. Il constitue un moyen de transmettre l'existence d'une session, et un moyen de transmettre suffisamment d'informations pour permettre de rejoindre la session et d'y participer. Dans un environnement unicast, seul ce dernier objectif peut être pertinent.

Une description de session SDP comprend les éléments suivants :

  • Le nom et l'objet de la session
  • Les horaires pendant lesquels la session est active
  • Les médias composant la session
  • Les informations nécessaires pour recevoir ces médias (adresses, ports, formats, etc.)

Comme les ressources nécessaires à la participation à une session peuvent être limitées, certaines informations supplémentaires peuvent également être nécessaires :

  • Des informations sur la bande passante utilisée par la session
  • Les coordonnées de la personne responsable de la session

En général, SDP DOIT transmettre suffisamment d'informations pour permettre à une application de rejoindre une session (les clés de chiffrement pouvant être une exception), et annoncer les ressources qui seront utilisées à tout non-participant qui pourrait avoir besoin de le savoir. (Cette dernière caractéristique est principalement utile lorsque SDP est utilisé avec un protocole d'annonce de session multicast.)

4.1 Media and Transport Information (informations sur les médias et le transport)​

Une description de session SDP comprend les informations de médias suivantes :

  • Le type de média (vidéo, audio, etc.)
  • Le protocole de transport (RTP/UDP/IP, H.320, etc.)
  • Le format du média (vidéo H.261, vidéo MPEG, etc.)

En plus du format de média et du protocole de transport, SDP transmet également les détails d'adresse et de port. Pour les sessions IP multicast, ceux-ci comprennent :

  • L'adresse du groupe multicast pour le média
  • Le port de transport pour le média

Cette adresse et ce port sont l'adresse de destination et le port de destination du flux multicast, qu'il s'agisse d'envoi, de réception ou des deux.

Pour les sessions IP unicast, les éléments suivants sont transmis :

  • L'adresse distante pour le média
  • Le port de transport distant pour le média

La sémantique de cette adresse et de ce port dépend du média et du protocole de transport définis. Par défaut, cela DEVRAIT être l'adresse distante et le port distant vers lesquels les données sont envoyées. Certains types de médias peuvent redéfinir ce comportement, mais cela n'est PAS RECOMMANDÉ car cela complique les implémentations (y compris les équipements intermédiaires qui doivent analyser les adresses pour ouvrir des trous dans les NAT ou les pare-feux).

4.2 Timing Information (informations de temporisation)​

Les sessions peuvent être délimitées ou non dans le temps. Qu'elles soient délimitées ou non, elles peuvent n'être actives qu'à certains moments. SDP peut transmettre :

  • Une liste arbitraire d'heures de début et de fin délimitant la session
  • Pour chaque délimitation, des temps de répétition, par exemple « chaque mercredi à 10h pendant une heure »

Ces informations de temporisation sont cohérentes à l'échelle mondiale, indépendamment du fuseau horaire local ou de l'heure d'été (voir la section 5.9).

4.3 Private Sessions (sessions privées)​

Il est possible de créer des sessions publiques et des sessions privées. SDP lui-même ne fait pas de distinction entre les deux ; les sessions privées sont généralement transmises en chiffrant la description de session lors de la distribution. Les détails sur la façon dont le chiffrement est effectué dépendent du mécanisme utilisé pour transporter SDP ; des mécanismes sont actuellement définis pour SDP transporté via SAP [14] et SIP [15], et d'autres mécanismes pourront être définis à l'avenir.

Si l'annonce de session est privée, cette annonce privée peut être utilisée pour transmettre les clés de chiffrement nécessaires pour décoder chaque média de la conférence, y compris suffisamment d'informations pour savoir quel schéma de chiffrement est utilisé pour chaque média.

4.4 Obtaining Further Information about a Session (obtenir plus d'informations sur une session)​

Une description de session DEVRAIT transmettre suffisamment d'informations pour décider de participer ou non à une session. SDP PEUT inclure des pointeurs supplémentaires vers plus d'informations sur la session sous la forme d'URI (Uniform Resource Identifiers).

4.5 Categorisation (catégorisation)​

Lorsque SAP ou tout autre mécanisme d'annonce distribue de nombreuses descriptions de session, il peut être nécessaire de filtrer les annonces de session intéressantes parmi celles qui ne le sont pas. SDP prend en charge un mécanisme de catégorisation de session pouvant être automatisé (attribut « a=cat: » ; voir la section 6).

4.6 Internationalisation (internationalisation)​

La spécification SDP recommande l'utilisation du jeu de caractères ISO 10646 en encodage UTF-8 [5] pour permettre la représentation de nombreuses langues différentes. Cependant, pour faciliter une représentation compacte, SDP permet également l'utilisation d'autres jeux de caractères tels qu'ISO 8859-1 lorsque cela est nécessaire. L'internationalisation s'applique uniquement aux champs de texte libre (nom de session et informations de contexte), et non à l'ensemble de SDP.

5. Spécification SDP​

Une description de session SDP est représentée par le type de média « application/sdp » (voir la section 8).

Une description de session SDP est entièrement sous forme textuelle utilisant le jeu de caractères ISO 10646 encodé en UTF-8. Les noms de champs SDP et les noms d'attributs utilisent uniquement le sous-ensemble US-ASCII de l'UTF-8, mais les champs de texte et les valeurs d'attributs PEUVENT utiliser le jeu de caractères ISO 10646 complet. Les champs et valeurs d'attributs utilisant le jeu de caractères UTF-8 complet ne sont jamais comparés directement, donc aucune normalisation UTF-8 n'est requise. La forme textuelle (plutôt qu'un encodage binaire tel qu'ASN.1 ou XDR) a été choisie pour améliorer la portabilité, permettre une variété de modes de transport, et permettre l'utilisation d'outils flexibles basés sur le texte pour générer et traiter les descriptions de session.

Format de description SDP​

Une description de session SDP est composée de plusieurs lignes de texte au format :

<type>=<value>

où <type> DOIT être exactement un caractère sensible à la casse, et <value> est du texte structuré dont le format dépend de <type>.

Structure de la description SDP​

Une description de session SDP est composée d'une section de niveau session et de zéro ou plusieurs sections de niveau média. Certaines lignes de la description sont OBLIGATOIRES (REQUIRED) et certaines sont OPTIONNELLES (OPTIONAL), mais toutes DOIVENT apparaître dans l'ordre indiqué ici. Les éléments optionnels sont marqués d'un « * ».

Description de session (Session description) :

  • v= (version du protocole)
  • o= (initiateur et identifiant de session)
  • s= (nom de session)
  • i=* (informations de session)
  • u=* (URI de la description)
  • e=* (adresse électronique)
  • p=* (numéro de téléphone)
  • c=* (informations de connexion — non requises si incluses dans tous les médias)
  • b=* (zéro ou plusieurs lignes d'informations de bande passante)
  • Une ou plusieurs descriptions de temps (lignes « t= » et « r= »)
  • z=* (ajustements de fuseau horaire)
  • k=* (clé de chiffrement)
  • a=* (zéro ou plusieurs lignes d'attributs de session)
  • Zéro ou plusieurs descriptions de médias

Description de temps (Time description) :

  • t= (horaires d'activité de la session)
  • r=* (zéro ou plusieurs temps de répétition)

Description de média (Media description, si présente) :

  • m= (nom du média et adresse de transport)
  • i=* (titre du média)
  • c=* (informations de connexion — optionnelles si incluses au niveau session)
  • b=* (zéro ou plusieurs lignes d'informations de bande passante)
  • k=* (clé de chiffrement)
  • a=* (zéro ou plusieurs lignes d'attributs de média)

Exemple SDP​

v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
[email protected] (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000

Sous-sections​

5.1 Protocol Version ("v=") (version du protocole)​

v=0

Le champ « v= » indique la version du protocole de description de session. Ce mémo définit la version 0. Il n'y a pas de numéro de sous-version.

5.2 Origin ("o=") (origine)​

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

Le champ « o= » indique l'initiateur de la session (son nom d'utilisateur et l'adresse de son hôte), ainsi que l'identifiant et le numéro de version de la session.

5.3 Session Name ("s=") (nom de session)​

s=<session name>

Le champ « s= » est le nom textuel de la session. Chaque description de session DOIT avoir exactement un champ « s= ».

5.4 Session Information ("i=") (informations de session)​

i=<session description>

Le champ « i= » fournit des informations textuelles sur la session. Chaque description de session PEUT avoir au plus un champ « i= » au niveau session, et au plus un champ « i= » par média.

5.5 URI ("u=")​

u=<uri>

Le champ « u= » contient un URI pointant vers plus d'informations sur la session.

5.6 Email Address and Phone Number ("e=" and "p=") (adresse électronique et numéro de téléphone)​

e=<email-address>
p=<phone-number>

Le champ « e= » contient l'adresse électronique de la personne responsable de la conférence. Le champ « p= » contient le numéro de téléphone de la personne responsable de la conférence.

5.7 Connection Data ("c=") (données de connexion)​

c=<nettype> <addrtype> <connection-address>

Le champ « c= » contient les informations nécessaires aux données de connexion.

5.8 Bandwidth ("b=") (bande passante)​

b=<bwtype>:<bandwidth>

Le champ « b= » indique la bande passante proposée pour la session.

5.9 Timing ("t=") (temporisation)​

t=<start-time> <stop-time>

La ligne « t= » spécifie les heures de début et de fin de la session.

5.10 Repeat Times ("r=") (temps de répétition)​

r=<repeat interval> <active duration> <offsets from start-time>

La ligne « r= » spécifie les horaires de répétition d'une session récurrente.

5.11 Time Zones ("z=") (fuseaux horaires)​

z=<adjustment time> <offset> <adjustment time> <offset> ...

La ligne « z= » spécifie les ajustements de fuseau horaire pour compenser les changements d'heure d'été ou d'autres décalages de fuseau horaire.

5.12 Encryption Keys ("k=") (clés de chiffrement)​

k=<method>
k=<method>:<encryption key>

Le champ « k= » est utilisé pour transmettre des clés de chiffrement.

5.13 Attributes ("a=") (attributs)​

a=<attribute>
a=<attribute>:<value>

Les attributs sont le principal moyen d'étendre SDP. Les attributs peuvent être définis au niveau session ou au niveau média.

5.14 Media Descriptions ("m=") (descriptions de médias)​

m=<media> <port> <proto> <fmt> ...

Une description de média commence par une ligne « m= » et contient suffisamment d'informations pour décrire un flux de média.

Remarque : La section 5 contient de nombreux détails techniques et des définitions de syntaxe ABNF. Pour la spécification complète, veuillez consulter le document officiel RFC 4566.

6. Attributs SDP​

Les attributs (Attributes) sont le principal moyen d'étendre SDP. Ils peuvent être définis au niveau session ou au niveau média. Les attributs de niveau session s'appliquent à l'ensemble de la session (sauf s'ils sont remplacés par des attributs de niveau média), et les attributs de niveau média s'appliquent uniquement au flux de média concerné.

Le format d'une ligne d'attribut est :

a=<attribute>
a=<attribute>:<value>

Liste des attributs standard​

Voici les attributs SDP standard définis par cette spécification :

cat (Category) (catégorie)​

a=cat:<category>

Utilisé pour catégoriser la session, facilitant le filtrage et la recherche.

keywds (Keywords) (mots-clés)​

a=keywds:<keywords>

Fournit une liste de mots-clés relatifs à la session.

tool (Tool) (outil)​

a=tool:<name and version of tool>

Identifie l'outil logiciel ayant créé la description de session.

ptime (Packet Time) (durée de paquet)​

a=ptime:<packet time>

Indique la durée du média contenu dans chaque paquet, en millisecondes.

maxptime (Maximum Packet Time) (durée maximale de paquet)​

a=maxptime:<maximum packet time>

Indique la durée maximale de chaque paquet, en millisecondes.

rtpmap (RTP Mapping) (correspondance RTP)​

a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]

Associe un type de charge utile RTP à un nom d'encodage de média.

recvonly (Receive Only) (réception uniquement)​

a=recvonly

Indique que l'outil ne peut que recevoir des médias, sans en envoyer.

sendrecv (Send and Receive) (envoi et réception)​

a=sendrecv

Indique que l'outil peut à la fois envoyer et recevoir des médias (valeur par défaut).

sendonly (Send Only) (envoi uniquement)​

a=sendonly

Indique que l'outil ne peut qu'envoyer des médias, sans en recevoir.

inactive (Inactive) (inactif)​

a=inactive

Indique que le flux de média est actuellement inactif.

orient (Orientation) (orientation)​

a=orient:<whiteboard orientation>

Utilisé pour les types de médias tableau blanc (whiteboard), indique l'orientation du tableau blanc.

type (Conference Type) (type de conférence)​

a=type:<conference type>

Spécifie le type de conférence (par exemple « broadcast », « meeting », « moderated », « test », « H332 »).

charset (Character Set) (jeu de caractères)​

a=charset:<character set>

Spécifie le jeu de caractères utilisé pour les champs texte de la description de session.

sdplang (SDP Language) (langue SDP)​

a=sdplang:<language tag>

Spécifie la langue utilisée dans la description de session.

lang (Language) (langue)​

a=lang:<language tag>

Spécifie la langue utilisée dans le flux de média.

framerate (Frame Rate) (fréquence d'images)​

a=framerate:<frame rate>

Indique la fréquence d'images de la vidéo (images par seconde).

quality (Quality) (qualité)​

a=quality:<quality>

Indique la valeur de qualité d'encodage suggérée.

fmtp (Format Parameters) (paramètres de format)​

a=fmtp:<format> <format specific parameters>

Utilisé pour spécifier des paramètres propres à un format particulier.

Remarque : Ce chapitre liste les attributs fondamentaux de SDP. Les types de médias et les applications individuels peuvent définir des attributs supplémentaires. Pour la liste complète des attributs et leurs descriptions détaillées, veuillez consulter le document officiel RFC 4566, section 6.

7. Considérations de sécurité​

Une description de session SDP ne constitue pas en elle-même un protocole de transport ; elle DOIT être utilisée conjointement avec un protocole de transport pour transmettre la description de session aux participants. Cette section traite des considérations de sécurité liées à l'utilisation de SDP.

Confidentialité (Confidentiality)​

Les descriptions de session peuvent contenir des informations sensibles, notamment :

  • Les informations d'identité des participants
  • Les coordonnées (adresse électronique, numéro de téléphone)
  • Les clés de chiffrement
  • Les informations de topologie réseau (adresses IP, ports)
  • Les horaires et le sujet de la session

Il est recommandé d'utiliser des mécanismes de chiffrement appropriés (tels que TLS, S/MIME) pour protéger la confidentialité des descriptions de session lors de leur transmission.

Intégrité et authenticité (Integrity and Authenticity)​

Les descriptions de session DOIVENT être protégées contre toute modification non autorisée. Un attaquant pourrait modifier une description de session pour :

  • Rediriger les flux de médias vers un serveur malveillant
  • Injecter des attributs malveillants
  • Modifier les clés de chiffrement
  • Changer les horaires de la session

Il est recommandé d'utiliser des signatures numériques ou des codes d'authentification de message (MAC) pour vérifier l'intégrité et l'authenticité des descriptions de session.

Déni de service (Denial of Service)​

Un attaquant pourrait exploiter les descriptions de session pour lancer des attaques par déni de service :

  • Envoyer un grand nombre d'annonces de session falsifiées
  • Créer des descriptions de session très volumineuses pour épuiser les ressources de l'analyseur syntaxique
  • Pointer vers des adresses inexistantes pour consommer des ressources réseau

Les implémentations DEVRAIENT limiter la taille et la complexité des descriptions de session, et traiter correctement les erreurs d'analyse.

Distribution des clés de chiffrement (Encryption Key Distribution)​

Bien que SDP fournisse un mécanisme pour transmettre des clés de chiffrement (champ « k= »), dans de nombreux cas, la transmission de clés via une description de session peut ne pas être sécurisée. Il est recommandé d'utiliser des protocoles de gestion de clés dédiés (tels que MIKEY, ZRTP) ou des méthodes d'échange de clés hors bande.

Considérations de confidentialité (Privacy Considerations)​

Le champ « o= » contient le nom d'utilisateur et l'adresse IP de la personne ayant créé la session, ce qui peut divulguer des informations privées. Dans les scénarios nécessitant la confidentialité, un nom d'utilisateur arbitraire et une adresse privée peuvent être utilisés, à condition que cela n'affecte pas l'unicité globale du champ.

Traduction d'adresses réseau (NAT) et pare-feux​

Les adresses IP et les informations de port contenues dans SDP peuvent devenir invalides lors du passage par un NAT (Network Address Translation) ou un pare-feu. Les applications DEVRAIENT utiliser des mécanismes tels que ICE (Interactive Connectivity Establishment) pour gérer ces situations.

8. Considérations IANA​

Cette section décrit les exigences d'enregistrement IANA pour les différents paramètres utilisés par SDP.

8.1 The "application/sdp" Media Type (type de média « application/sdp »)​

Les descriptions de session SDP utilisent le type de média « application/sdp ».

Nom du type de média : application
Nom du sous-type de média : sdp
Paramètres requis : aucun
Paramètres optionnels : aucun
Considérations d'encodage : Les fichiers SDP sont des fichiers texte utilisant le jeu de caractères ISO 10646 encodé en UTF-8.
Considérations de sécurité : Voir la section 7 de la RFC 4566
Considérations d'interopérabilité : Voir la RFC 4566
Spécification publiée : RFC 4566
Applications utilisant ce type de média : Outils de configuration et d'annonce de sessions multimédia
Informations supplémentaires :

  • Extension de fichier : .sdp
  • Code de type de fichier Macintosh : 'sdp '

8.2 Registration of Parameters (enregistrement des paramètres)​

SDP utilise plusieurs types de paramètres qui peuvent être enregistrés auprès de l'IANA.

8.2.1 Media Types ("media") (types de médias)​

Les noms de types de médias utilisés par SDP DEVRAIENT être enregistrés auprès de l'IANA. Les types de médias initialement enregistrés comprennent :

  • audio (audio)
  • video (vidéo)
  • text (texte)
  • application (application)
  • message (message)

De nouveaux types de médias peuvent être enregistrés via le processus de normalisation IETF ou par examen d'expert.

8.2.2 Transport Protocols ("proto") (protocoles de transport)​

Les protocoles de transport initialement enregistrés comprennent :

  • RTP/AVP (profil audio-vidéo RTP)
  • RTP/SAVP (profil audio-vidéo sécurisé RTP)
  • UDP (protocole de datagramme utilisateur)

De nouveaux protocoles de transport peuvent être enregistrés via le processus de normalisation IETF ou par examen d'expert.

8.2.3 Media Formats ("fmt") (formats de médias)​

L'enregistrement des formats de médias (tels que les types de charge utile RTP) suit les procédures définies dans la RFC 3555.

8.2.4 Attribute Names ("att-field") (noms d'attributs)​

Les noms d'attributs SDP sont enregistrés auprès de l'IANA. L'enregistrement d'un nouvel attribut DEVRAIT inclure :

  • Le nom de l'attribut
  • Le type (niveau session, niveau média ou les deux)
  • La valeur (le cas échéant)
  • L'utilisation et la sémantique
  • La spécification de référence

L'enregistrement des attributs utilise la procédure d'examen d'expert ou d'approbation IESG.

8.2.5 Bandwidth Specifiers ("bwtype") (spécificateurs de bande passante)​

Les spécificateurs de bande passante initialement enregistrés comprennent :

  • CT (Conference Total, bande passante totale de la conférence)
  • AS (Application Specific, bande passante spécifique à l'application)

De nouveaux spécificateurs de bande passante peuvent être enregistrés via le processus de normalisation IETF ou par examen d'expert.

8.2.6 Network Types ("nettype") (types de réseau)​

Les types de réseau initialement enregistrés :

  • IN (Internet)

De nouveaux types de réseau peuvent être enregistrés via le processus de normalisation IETF.

8.2.7 Address Types ("addrtype") (types d'adresses)​

Les types d'adresses initialement enregistrés :

  • IP4 (adresse IPv4)
  • IP6 (adresse IPv6)

De nouveaux types d'adresses peuvent être enregistrés via le processus de normalisation IETF.

8.2.8 Registration Procedure (procédure d'enregistrement)​

Sauf indication contraire, tous les enregistrements de paramètres décrits dans cette section utilisent l'une des procédures suivantes :

  • Standards Action (action de normalisation) : nécessite une RFC IETF
  • Expert Review (examen d'expert) : nécessite l'examen d'un expert désigné
  • IESG Approval (approbation IESG) : nécessite l'approbation explicite de l'IESG

8.3 Encryption Key Access Methods (méthodes d'accès aux clés de chiffrement)​

Les méthodes d'accès aux clés de chiffrement utilisées par le champ « k= » DEVRAIENT être enregistrées auprès de l'IANA. Les méthodes initialement enregistrées comprennent :

  • clear (clé en clair)
  • base64 (clé encodée en Base64)
  • uri (clé obtenue via un URI)
  • prompt (invite l'utilisateur à saisir la clé)

De nouvelles méthodes d'accès aux clés peuvent être enregistrées par examen d'expert.

10. Résumé des modifications par rapport à la RFC 2327​

La RFC 4566 rend obsolètes la RFC 2327 et la RFC 3266. Cette section présente un aperçu des principales modifications par rapport à la RFC 2327.

Principales modifications​

Références normatives​

  • Mise à jour des références aux autres RFC, en utilisant les versions actuelles des documents normatifs
  • Ajout d'une référence à la RFC 3986 (syntaxe URI)

Noms de domaine internationalisés (IDN)​

  • Exigence explicite que les noms de domaine internationalisés DOIVENT utiliser la forme ACE (ASCII Compatible Encoding)
  • Interdiction d'utiliser directement UTF-8 ou d'autres encodages pour représenter les IDN dans SDP

Enregistrement du type de média​

  • Mise à jour des informations d'enregistrement du type de média « application/sdp »
  • Clarification des considérations d'encodage et de sécurité

Syntaxe ABNF​

  • Mise à jour de la syntaxe ABNF pour refléter les pratiques actuelles
  • Correction de quelques erreurs mineures dans les règles de syntaxe
  • Utilisation de la notation ABNF de la RFC 4234 (désormais RFC 5234)

Considérations de sécurité​

  • Extension de la section sur les considérations de sécurité
  • Ajout d'une discussion sur la traversée NAT et les pare-feux
  • Mise en évidence des problèmes de sécurité liés à la distribution des clés de chiffrement

Considérations IANA​

  • Mise à jour des procédures d'enregistrement des paramètres
  • Clarification des exigences d'enregistrement pour les différents paramètres SDP
  • Ajout de nouvelles catégories d'enregistrement

Définitions des attributs​

  • Clarification de la sémantique de certains attributs
  • Mise à jour des exemples d'utilisation des attributs

Adresse de connexion​

  • Clarification de l'utilisation de l'adresse de connexion dans la ligne « c= »
  • Précision de la représentation des adresses IPv4 et IPv6

Description temporelle​

  • Clarification de la sémantique des champs de temps
  • Mise à jour des instructions d'utilisation des horodatages NTP

Modifications éditoriales​

  • Amélioration de la structure du document et de la lisibilité
  • Mise à jour des exemples pour refléter les pratiques actuelles
  • Correction des fautes d'orthographe et de grammaire
  • Uniformisation de l'utilisation de la terminologie

Compatibilité ascendante​

La RFC 4566 maintient la compatibilité ascendante avec la RFC 2327. Les implémentations conformes à la RFC 2327 devraient être capables de traiter les descriptions de session conformes à la RFC 4566, et vice versa.

Remarque : Pour la liste détaillée des modifications et les explications techniques, veuillez consulter le document officiel RFC 4566, section 10.

11. Remerciements​

Le développement de SDP a bénéficié des contributions de nombreux membres de la communauté MBONE (Multicast Backbone). Des remerciements particuliers sont adressés à Eve Schooler, Steve Casner, Bill Fenner, Ron Frederick, Allison Mankin, Scott Shenker, Henning Schulzrinne et à de nombreuses autres personnes pour leurs commentaires et suggestions sur les premières versions de SDP.

Nous remercions tous les membres du groupe de travail MMUSIC pour leur révision et leurs commentaires sur les différentes versions de ce document.

Des remerciements particuliers sont adressés aux personnes suivantes pour leurs contributions et commentaires sur la RFC 4566 :

  • Dave Singer
  • Joerg Ott
  • Jonathan Rosenberg
  • Magnus Westerlund
  • Ainsi que tous les membres de la communauté IETF ayant fourni des retours

La liste complète des remerciements est disponible dans le document officiel RFC 4566, section 11.