3. Définitions SDP

3.1. Définition du profil

Les profils AV définis dans la RFC 3551 [2], la RFC 4585 [3] et la RFC 3711 [4] sono indicati come "AVP", "AVPF", e "SAVP", rispettivamente, nel contesto, ad esempio, del Session Description Protocol (SDP) [3]. Le profil combiné spécifié dans ce document est désigné par "SAVPF".

3.2. Définitions d'attributs

Les attributs SDP pour la négociation des sessions SAVP sont définis dans la RFC 4567 [7] et la RFC 4568 [8]. Ces attributs PEUVENT également être utilisés avec le SAVPF. Les règles définies dans [7] et [8] s'appliquent.

Les attributs SDP pour la négociation des sessions AVPF sono definiti nella RFC 4585 [3]. Ces attributs PEUVENT également être utilisés avec le SAVPF. Les règles définies dans [3] s'appliquent.

3.3. Négociation du profil

Les descriptions de session pour les sessions RTP peuvent être transportées à l'aide de protocoles dédiés aux communications multimédias tels que le modèle offre/réponse SDP (RFC 3264, [9]) utilisé avec le protocole d'initiation de session (SIP) [15], le protocole de streaming en temps réel (RTSP) [10] ou le protocole d'annonce de session (SAP) [11], mais possono anche essere distribuite tramite email, NetNews, pagine web, ecc.

Le modèle offre/réponse permet de négocier les paramètres de session résultants à l'aide des attributs SDP définis dans la RFC 4567 [7] et la RFC 4568 [8]. Dans la sous-section suivante, le processus de négociation est décrit en termes de modèle offre/réponse.

Ensuite, les cas qui n'utilisent pas le modèle offre/réponse sont abordés : le support de la négociation spécifique au RTSP est fourni par la RFC 4567 [7] comme discuté dans la section 3.3.2, et le support pour les annonces SAP (sans aucune négociation) est abordé dans la section 3.3.3.

3.3.1. Négociation des descriptions de session basée sur le modèle offre/réponse

Les négociations (par exemple, des profils RTP, des codecs, des adresses de transport, etc.) sono effettuate per ogni sessione multimediale (ad esempio, per ogni riga m= in SDP). Se la negoziazione di una sessione multimediale fallisce, le altre POSSONO comunque avere successo.

Différents profils RTP PEUVENT être utilisés dans différentes sessions multimédias. Pour la négociation d'une description de média, les quatre profils AVP, AVPF, SAVP et SAVPF s'excluent mutuellement. Notez cependant que les entités SAVP et SAVPF PEUVENT être mélangées dans une seule session RTP (voir la section 4). De plus, le mécanisme offre/réponse PEUT être utilisé pour proposer des alternatives pour la même session multimédia et permettre au répondant de choisir l'un des profils.

À condition qu'un mécanisme pour proposer des profils de sécurité alternatifs devienne disponible (comme c'est le cas actuellement [14]), un proposant capable de supporter plus d'un de ces profils pour une certaine session multimédia DEVRAIT toujours proposer toutes les alternatives acceptables dans une certaine situation. Les alternatives DEVRAIENT être listées par ordre de préférence et le proposant DEVRAIT préférer les profils sécurisés aux profils non sécurisés. L'offre NE DEVRAIT PAS inclure à la fois une alternative sécurisée (SAVP et SAVPF) et une alternative non sécurisée (par exemple, AVP et AVPF) dans la même offre, car cela pourrait permettre des attaques de repli (bidding down) et d'autres attaques. Par conséquent, si des profils RTP sécurisés et non sécurisés sont tous deux proposés (par exemple, pour le SRTP best-effort [14]), la signalisation de négociation DOIT être protégée de manière appropriée pour éviter de telles attaques.

Si une offre contient plusieurs profils alternatifs, le répondant DEVRAIT préférer un profil sécurisé (s'il est supporté) aux profils non sécurisés. Parmi les profils sécurisés ou non sécurisés, le répondant DEVRAIT sélectionner la première alternative acceptable pour respecter la préférence du proposant.

Si une description de média dans une offre utilise le SAVPF et que le répondant ne supporte pas le SAVPF, la session multimédia DOIT être rejetée.

Si une description de média dans une offre n'utilise pas le SAVPF mais que le répondant souhaite utiliser le SAVPF, le répondant DOIT rejeter la session multimédia. Le répondant PEUT soumettre une contre-offre avec une description de média indiquant le SAVPF dans un échange offre/réponse initié ultérieurement.

3.3.2. Négociation des descriptions de session basée sur le RTSP

Le RTSP [10] ne supporte pas le modèle offre/réponse. Cependant, le RTSP supporte l'échange de paramètres de session multimédia (y compris le profil et les informations d'adresse) au moyen de l'en-tête Transport. La gestion des clés basée sur le SDP, telle que définie dans la RFC 4567 [7], ajoute un en-tête RTSP (KeyMgmt) pour supporter le transport d'un protocole de gestion des clés (y compris le matériel de chiffrement).

L'en-tête RTSP Transport PEUT être utilisé pour déterminer le profil de la session multimédia. Conceptuellement, les règles définies dans la section 3.3.1 s'appliquent en conséquence. Le fonctionnement détaillé est le suivant : une description SDP (par exemple, récupérée du serveur RTSP au moyen de DESCRIBE) contient la description des flux multimédias de la ressource RTSP particulière.

Le client RTSP DOIT sélectionner exactement un des profils par flux multimédia qu'il souhaite recevoir. Il DOIT le faire dans la requête SETUP. Le client RTSP DOIT indiquer le profil RTP choisi en indiquant le profil et l'adresse de transport complète du serveur (adresse IP et numéro de port) dans l'en-tête Transport inclus dans la requête SETUP. La réponse du serveur RTSP au message SETUP du client DOIT confirmer cette sélection de profil ou refuser la requête SETUP (ce qu'il ne devrait pas faire après avoir proposé les profils en premier lieu).

Note : Pour modifier l'un des profils utilisés, le client doit fermer ce flux multimédia (et éventuellement toute la session RTSP) en utilisant la méthode TEARDOWN et le rétablir en utilisant SETUP. Cela pourra changer dès que la mise à jour des médias (similaire à un SIP UPDATE ou re-INVITE) sera spécifiée.

Lors de l'utilisation de la gestion des clés SDP [7], l'en-tête KeyMgmt DOIT être inclus dans les messages RTSP appropriés si un profil sécurisé est choisi. Si différents profils sécurisés sont proposés dans la description SDP (par exemple, SAVP et SAVPF) et que différents matériels de chiffrement sont fournis pour ceux-ci, après avoir choisi un profil dans le message SETUP, seul l'en-tête KeyMgmt correspondant à celui choisi DOIT être fourni. Les règles pour faire correspondre les en-têtes KeyMgmt aux flux multimédias selon la RFC 4567 [7] s'appliquent.

3.3.3. Annonce des descriptions de session

Les protocoles qui ne permettent pas de négocier les descriptions de session de manière interactive (par exemple, SAP [11], descriptions publiées sur une page web ou envoyées par courrier) font porter la responsabilité d'un accès adéquat aux sessions multimédias à l'initiateur de la session.

L'initiateur DEVRAIT fournir des descriptions de session alternatives pour plusieurs profils RTP dans la mesure où cela est acceptable pour l'application et l'objectif de la session. Si la sécurité est souhaitée, le SAVP peut être proposé comme alternative au SAVPF — mais les sessions AVP ou AVPF NE DEVRAIENT PAS être annoncées à moins que d'autres moyens de sécurité ne reposant pas sur le SRTP ne soient employés.

Les attributs SDP définis dans la RFC 4567 [7] et la RFC 4568 [8] possono anche essere utilizzati per la distribuzione dei parametri di sicurezza delle descrizioni di sessione annunciate.

La description du schéma de sécurité définie dans la RFC 4568 [8] richiede un canale di comunicazione sicuro per impedire a terzi di intercettare i parametri di cifratura e di manipolarli. Par conséquent, la sécurité SAP (telle que définie dans la RFC 2974 [11]), S/MIME [12], HTTPS [13] ou d'autres mécanismes appropriés DEVRAIENT être utilisés pour distribuer ou accéder à ces descriptions de session.

3.3.4. Description des profils de session alternatifs

Les entités SAVP et SAVPF PEUVENT être mélangées dans la même session RTP (voir aussi la section 4), tout comme les entités AVP et AVPF. D'autres combinaisons — c'est-à-dire entre profils sécurisés et non sécurisés — dans la même session RTP sont incompatibles et NE DOIVENT PAS être utilisées ensemble.

Si la négociation entre les pairs concernés est possible (comme avec le modèle offre/réponse selon la section 3.3.1 ou le RTSP selon la section 3.3.2), des profils alternatifs (sécurisés et non sécurisés) PEUVENT être spécifiés par une entité (par exemple, le proposant) et un choix d'un profil DOIT être fait par l'autre. Si aucune négociation de ce type n'est possible (par exemple, avec le SAP selon la section 3.3.3), des profils incompatibles NE DOIVENT PAS être spécifiés comme alternatives.

La négociation de profils alternatifs fera l'objet d'études ultérieures.

Les profils RTP PEUVENT être mélangés arbitrairement à travers différentes sessions RTP.

3.4. Exemples

Cette section contient des exemples d'utilisation du SDP pour négocier l'utilisation de profils sécurisés et non sécurisés. Selon le mécanisme de chiffrement utilisé et la manière dont il est paramétré, les messages SDP nécessitent généralement une protection de l'intégrité et, pour certains mécanismes, une protection de la confidentialité. Par exemple, on pourrait dire que la protection de l'intégrité est requise pour l'attribut a=fingerprint de Datagram Transport Layer Security - Secure Real-time Transport Protocol (DTLS-SRTP) [16], et que la confidentialité est requise pour l'attribut a=crypto de la RFC 4568 [8] (Security Descriptions).

Exemple 1 : La description de session suivante indique une session sécurisée composée d'audio et de multifréquence bitonal (DTMF) pour une communication point à point dans laquelle le flux DTMF utilise des NACK génériques. Le protocole de gestion des clés indiqué est MIKEY. Cette description de session (l'offre) pourrait être contenue dans un message SIP INVITE ou 200 OK pour indiquer que son expéditeur est capable de et disposé à recevoir des retours pour le flux DTMF qu'il transmet. La réponse correspondante peut être transportée dans un message 200 OK o un ACK. Les paramètres du protocole de sécurité sont négociés comme décrit par les extensions SDP définies dans la RFC 4567 [7].

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...

Exemple 2 : Cet exemple montre les mêmes paramètres de retour que l'exemple 1, mais utilise la syntaxe des descriptions sécurisées [8]. Notez que la partie clé de l'attribut a=crypto n'est pas protégée contre l'espionnage et que la description de session doit donc être échangée via un canal de communication sécurisé.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=crypto:AES_CM_128_HMAC_SHA1_32
  inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1
  :32

Exemple 3 : Cet exemple est une reproduction de l'exemple 1 ci-dessus, mais montre l'interaction entre le proposant et le répondant dans un échange offre/réponse, en utilisant à nouveau MIKEY pour négocier le matériel de chiffrement :

Offre :

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

Réponse :

v=0
o=alice 3203093521 3203093521 IN IP4 host.another.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.another.example.com
a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD...
m=audio 53012 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

Exemple 4 : Cet exemple montre l'échange pour le streaming vidéo contrôlé via RTSP. Un client acquiert une description de média auprès d'un serveur à l'aide de DESCRIBE et obtient une description SDP statique sans aucun paramètre de chiffrement, mais la description de média montre que des sessions médiatiques sécurisées et non sécurisées utilisant le (S)AVPF sont disponibles. Un mécanisme permettant l'identification explicite de ces alternatives (c'est-à-dire les sessions sécurisées et non sécurisées) dans la description de session est actuellement en cours de définition [14]. Le client émet ensuite une requête SETUP et indique son choix en incluant le profil respectif dans le paramètre Transport. De plus, le client inclut un en-tête KeyMgmt pour transporter ses paramètres de sécurité, auquel correspond un en-tête KeyMgmt du serveur dans la réponse. Une seule session multimédia est choisie de sorte que l'URI RTSP agrégé soit suffisant pour l'identification.

Paire requête-réponse RTSP DESCRIBE (facultative) :

DESCRIBE rtsp://movies.example.org/example RTSP/2.0
CSeq: 314
Accept: application/sdp

200 OK
CSeq: 314
Date: 25 Nov 2005 22:09:35 GMT
Content-Type: application/sdp
Content-Length: 316

v=0
o=alice 3203093520 3203093520 IN IP4 movies.example.com
s=Media with feedback
t=0 0
c=IN IP4 0.0.0.0
m=video 49170 RTP/SAVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack
m=video 49172 RTP/AVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack

Paire requête-réponse RTSP SETUP

SETUP rtsp://movies.example.org/example RTSP/2.0
CSeq: 315
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..."

200 OK
CSeq: 315
Date: 25 Nov 2005 22:09:36 GMT
Session: 4711
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
           src_addr="192.0.2.15:60000"/"192.0.2.15:60001"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..."
Accept-Ranges: NPT, SMPTE

Exemple 5 : La description de session suivante indique une session audio/vidéo multidiffusion (utilisant PCMU pour l'audio et soit H.261 soit H.263+) avec la source vidéo acceptant les NACK génériques pour les deux codecs et la sélection d'image de référence per H.263. Les paramètres du protocole de sécurité sont négociés comme décrit par les extensions SDP définies dans la RFC 4567 [7], utilisées au niveau de la session. Une telle description peut avoir été transportée à l'aide du protocole d'annonce de session (SAP).

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/SAVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi