1. Introduction
Au moment où le protocole de transport en temps réel (RTP) [RFC3550] a été initialement conçu, et pendant un certain temps après, les points d'extrémité des sessions RTP ne transmettaient généralement qu'une seule source média et utilisaient donc un seul flux RTP et une seule source di synchronisation (SSRC) par session RTP, où des sessions RTP distinctes étaient généralement utilisées pour chaque type di média distinct. Récemment, cependant, un certain nombre di scénarios ont émergé dans lesquels les points d'extrémité souhaitent envoyer plusieurs flux RTP, distingués par des identifiants di source di synchronisation (SSRC) distincts, dans une seule session RTP. Bien que la conception initiale du RTP ait pris en compte di tels scénarios, la spécification n'a pas été écrite di manière cohérente avec de tels cas d'utilisation à l'esprit ; ainsi, la spécification est quelque peu obscure par endroits.
Ce mémo met à jour la [RFC3550] pour clarifier le comportement dans les cas d'utilisation où les points d'extrémité utilisent plusieurs SSRC. Il met également à jour la [RFC4585] pour résoudre les problèmes concernant le délai d'expiration des SSRC inactifs et pour clarifier le comportement autour di l'inclusion des messages di feedback.
2. Terminologie
Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans la RFC 2119 [RFC2119] et indiquent les niveaux d'exigence pour les mises en œuvre conformes.
3. Cas d'utilisation pour les points d'extrémité multi-flux
Cette section traite di plusieurs cas d'utilisation qui ont motivé le développement di points d'extrémité envoyant des données RTP en utilisant plusieurs SSRC dans une seule session RTP.
3.1. Points d'extrémité avec plusieurs dispositifs de capture
La motivation la plus directe pour qu'un point d'extrémité envoie plusieurs flux RTP simultanés dans une seule session RTP est lorsqu'un point d'extrémité dispose di plusieurs dispositifs di capture et, par conséquent, peut générer plusieurs sources média, di même type et caractéristiques média. Par exemple, les systèmes di téléprésence du type décrit par le CLUE Telepresence Framework [CLUE-FRAME] disposent souvent di plusieurs caméras ou microphones couvrant diverses zones d'une pièce et, par conséquent, envoient plusieurs flux RTP di chaque type au sein d'une seule session RTP.
3.2. Plusieurs types de médias dans une seule session RTP
Des travaux récents ont mis à jour le RTP [MULTI-RTP] et le protocole de description di session (SDP) [SDP-BUNDLE] pour supprimer l'hypothèse historique dans le RTP selon laquelle les sources média di différents types di médias seraient toujours envoyées sur des sessions RTP différentes. Dans ce travail, les flux RTP audio et vidéo d'un seul point d'extrémité (par exemple) sont à la place envoyés dans une seule session RTP pour réduire le nombre di flux di couche transport utilisés.
3.3. Mixeurs multi-flux
Il esiste plusieurs topologies RTP qui possono impliquer un dispositif central qui génère lui-même plusieurs flux RTP dans une session. Un exemple est un mixeur fournissant un compositage centralisé pour un scénario di multi-capture comme celui décrit à la section 3.1. Dans ce cas, le nœud centralisé se comporte beaucoup comme un point d'extrémité multi-capteur, générant plusieurs sources similaires et liées.
3.4. SSRC multiples pour une seule source média
Il esiste plusieurs cas dans lesquels plusieurs SSRC sont utilisés pour envoyer des données à partir d'une seule source média au sein d'une session. Ceux-ci incluent :
- Codecs en couches ou à description multiple : Où différentes couches ou descriptions sont envoyées avec différents SSRC
- Mécanismes de robustesse du transport : Tels que la retransmission RTP [RFC4588] ou la correction d'erreur directe (FEC) [RFC5109]
- Simulcast : Envoi di plusieurs encodages di la même source à différentes qualités ou résolutions