1. Introduction
Le protocole de transport en temps réel, le protocole de contrôle RTP associé (RTP/RTCP, RFC 3550) [1], et le profil pour les communications audiovisuelles avec un contrôle minimal (RFC 3551) [2] définissent des mécanismes pour transmettre des médias basés sur le temps à travers un réseau IP. Le RTP fournit des moyens pour préserver la synchronisation et détecter les pertes de paquets, entre autres, et les formats de charge utile RTP permettent un tramage approprié des médias (continus) dans un environnement basé sur les paquets. Le RTCP permet aux récepteurs de fournir un retour sur la qualité de réception et permet à tous les membres d'une session RTP d'en apprendre davantage les uns sur les autres.
La spécification RTP ne fournit qu'un support rudimentaire pour le chiffrement des paquets RTP et RTCP. Le RTP sécurisé (RFC 3711) [4] définit un profil RTP ("SAVP") pour les sessions multimédias RTP sécurisées, définissant des méthodes pour le chiffrement approprié des paquets RTP et RTCP, l'intégrité et la protection contre le rejeu. La négociation initiale du SRTP et de ses paramètres de sécurité doit être effectuée hors bande, par exemple en utilisant le protocole de description de session (SDP, RFC 4566) [6] avec des extensions pour transporter le matériel de chiffrement (RFC 4567 [7], RFC 4568 [8]).
La spécification RTP fournit également un support limité pour un retour rapide des récepteurs vers les expéditeurs, généralement au moyen de rapports statistiques de réception à des intervalles quelque peu réguliers en fonction de la taille du groupe, de la taille moyenne des paquets RTCP et de la bande passante RTCP disponible. Le profil RTP étendu pour le retour basé sur le RTCP ("AVPF") (RFC 4585, [3]) permet aux participants à la session de fournir statistiquement un retour immédiat tout en maintenant le débit de données RTCP moyen pour tous les expéditeurs. Comme pour le SAVP, l'utilisation de l'AVPF et de ses paramètres doit être négociée hors bande au moyen du SDP (RFC 4566, [6]) et des extensions définies dans la RFC 4585 [3].
Le SRTP et l'AVPF sont tous deux des profils RTP et doivent être négociés. Cela implique que l'un ou l'autre peut être utilisé, mais que les deux profils ne peuvent pas être négociés pour la même session RTP (en utilisant une seule description de niveau de session SDP). Cependant, l'utilisation conjointe de communications sécurisées et d'un retour rapide est souhaitable. Par conséquent, ce document spécifie un nouveau profil RTP ("SAVPF") qui combine les fonctionnalités du SAVP et de l'AVPF.
Comme le SAVP et l'AVPF sont largement orthogonaux, la combinaison des deux est pour la plupart simple. Aucun algorithme sophistiqué n'a besoin d'être spécifié dans ce document. Au lieu de cela, il est fait référence aux deux profils existants et seules les implications de leur combinaison et les écarts possibles par rapport aux règles des profils existants sont décrits, tout comme le processus de négociation.
1.1. Définitions
Les définitions de la RFC 3550 [1], de la RFC 3551 [2], de la RFC 4585 [3] et de la RFC 3711 [4] s'appliquent.
Les définitions suivantes sont spécifiquement utilisées dans ce document :
-
Session RTP: Une association parmi un ensemble de participants communiquant avec le RTP tel que défini dans la RFC 3550 [1].
-
Description de média (SDP): Ce terme fait référence à la spécification donnée dans une seule ligne m= dans un message SDP. Une description de média SDP ne peut définir qu'une seule session RTP.
-
Session de média: Une session de média fait référence à une collection de descriptions de média SDP qui sont sémantiquement groupées pour représenter des alternatives du même moyen de communication. Dans un tel groupe, une alternative sera négociée ou choisie pour une relation de communication et la session RTP correspondante sera instanciée. Si aucun paramètre de session commun approprié pour les points terminaux concernés ne peut être trouvé, la session de média sera rejetée. Dans le cas le plus simple, une session de média est équivalente à une description de média SDP et équivalente à une session RTP.
1.2. Terminologie
Les mots-clés "MUST" (doit), "MUST NOT" (ne doit pas), "REQUIRED" (requis), "SHALL" (doit), "SHALL NOT" (ne doit pas), "SHOULD" (devrait), "SHOULD NOT" (ne devrait pas), "RECOMMENDED" (recommandé), "MAY" (peut) et "OPTIONAL" (facultatif) dans ce document doivent être interprétés comme décrit dans la RFC 2119 [5].