1. Introduction

Le protocole de transport en temps réel (RTP) [1] comprend deux composants : un protocole de transfert de données et un protocole de contrôle associé (RTCP). Historiquement, RTP et RTCP ont fonctionné sur des ports UDP séparés. Avec l'utilisation accrue de la traduction d'adresse et de port réseau (NAPT) [14], cela est devenu problématique, car le maintien de plusieurs liaisons NAT peut être coûteux. Cela complique également l'administration des pare-feu, car plusieurs ports doivent être ouverts pour autoriser le trafic RTP. Ce mémorandum explique comment les flux RTP et RTCP pour un seul type de média peuvent être exécutés sur un port unique, afin de faciliter la traversée du NAT et de simplifier l'administration des pare-feu, et examine quand un tel multiplexage est approprié. Le multiplexage de plusieurs types de médias (par exemple, audio et vidéo) sur un port unique n'est pas envisagé ici (voir toutefois la section 5.2 de [1]).

Ce mémorandum est structuré comme suit : dans la section 2, nous discutons des choix de conception qui ont conduit à l'utilisation de ports séparés et commentons l'applicabilité de ces choix aux environnements réseau actuels. Nous discutons de la terminologie dans la section 3 et de la manière de distinguer les paquets multiplexés dans la section 4 ; nous précisons ensuite quand et comment RTP et RTCP doivent être multiplexés, et comment signaler les sessions multiplexées, dans la section 5. Les questions de qualité de service et de bande passante sont discutées dans la section 6. Nous concluons par des considérations sur la sécurité à la section 7 et des considérations relatives à l'IANA à la section 8.

Ce mémorandum met à jour la section 11 de [1].

2. Contexte

Une session RTP comprend des paquets de données et des paquets de contrôle périodiques (RTCP). Les paquets RTCP sont supposés utiliser "le même mécanisme de distribution que les paquets de données", et le "protocole sous-jacent DOIT assurer le multiplexage des paquets de données et de contrôle, par exemple en utilisant des numéros de port séparés avec UDP" [1]. Le multiplexage a été reporté au protocole de transport sous-jacent, plutôt que d'être assuré au sein de RTP, pour les raisons suivantes :

Simplicité : une implémentation RTP est simplifiée en déplaçant le démultiplexage RTP et RTCP vers la couche transport, car elle n'a pas à se soucier de la séparation des paquets de données et de contrôle. Cela permet à l'implémentation d'être structurée de manière très naturelle, avec une séparation nette des plans de données et de contrôle.
Efficacité : suivant le principe du traitement par couches intégrées [15], une implémentation sera plus efficace lorsque le démultiplexage se produit en un seul endroit (par exemple, selon le port UDP) que lorsqu'il est réparti sur plusieurs couches de la pile (par exemple, selon le port UDP puis selon le type de paquet).
Pour permettre des moniteurs tiers : bien que la voix sur IP monodiffusion ait toujours été envisagée, RTP a également été conçu pour prendre en charge des conférences multidiffusion à couplage lâche [16] et des applications multimédias de streaming multidiffusion à très grande échelle (telles que le service dit "triple-play" de télévision IP (IPTV)). En conséquence, la conception de RTP permet aux paquets RTCP d'être multidiffusés en utilisant un groupe de multidiffusion IP et un port UDP séparés des paquets de données. Cela permet non seulement aux participants d'une session d'obtenir un retour sur la qualité de la réception, mais permet également le déploiement de moniteurs tiers, qui écoutent la qualité de la réception sans avoir accès aux paquets de données. Cela était destiné à assurer la gérabilité des sessions multidiffusion, sans compromettre la confidentialité.

Bien que ces choix de conception soient appropriés pour de nombreuses utilisations de RTP, ils sont problématiques dans certains cas. De nombreux déploiements RTP n'utilisent pas la multidiffusion IP, et avec l'utilisation accrue de la traduction d'adresse réseau (NAT), la simplicité du multiplexage au niveau de la couche transport est devenue un handicap, car elle nécessite une signalisation complexe pour ouvrir plusieurs trous d'épingle NAT. Dans des environnements de ce type, il est souhaitable de fournir une alternative au démultiplexage de RTP et RTCP utilisant des ports UDP séparés, en utilisant à la place un seul port UDP et en effectuant le démultiplexage au sein de l'application.

Ce mémorandum offre une telle alternative en multiplexant les paquets RTP et RTCP sur un port UDP unique, distingués par le type de charge utile RTP et les valeurs de type de paquet RTCP. Cela impose un travail supplémentaire à l'implémentation RTP, en échange d'une traversée du NAT simplifiée.

3. Terminologie

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 [2].

4. Paquets RTP et RTCP distinguables

Lorsque les paquets RTP et RTCP sont multiplexés sur un port unique, le champ du type de paquet RTCP occupe la même position dans le paquet que la combinaison du bit marqueur (M) RTP et du type de charge utile (PT) RTP. Ce champ peut être utilisé pour distinguer les paquets RTP et RTCP lorsque deux restrictions sont observées : 1) les valeurs de type de charge utile RTP utilisées sont distinctes des types de paquets RTCP utilisés ; et 2) pour chaque type de charge utile RTP (PT), PT+128 est distinct des types de paquets RTCP utilisés. La première contrainte exclut un conflit direct entre le type de charge utile RTP et le type de paquet RTCP ; la seconde contrainte exclut un conflit entre un paquet de données RTP avec le bit marqueur activé et un paquet RTCP.

Les conflits suivants entre les types de paquets RTP et RTCP sont connus :

Les types de charge utile RTP 64-65 sont en conflit avec les paquets RTCP FIR et NACK (obsolètes) définis dans le format original "RTP Payload Format for H.261 Video Streams" [3] (qui a été rendu obsolète par [17]).
Les types de charge utile RTP 72-76 sont en conflit avec les paquets RTCP SR, RR, SDES, BYE et APP définis dans la spécification RTP [1].
Les types de charge utile RTP 77-78 sont en conflit avec les paquets RTCP RTPFB et PSFB définis dans le profil RTP/AVPF [4].
Le type de charge utile RTP 79 est en conflit avec les paquets RTCP Extended Report (XR) [5].
Le type de charge utile RTP 80 est en conflit avec les paquets Receiver Summary Information (RSI) définis dans "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback" [6].

De nouveaux types de paquets RTCP pourraient être enregistrés à l'avenir et réduiraient encore les types de charge utile RTP disponibles lors du multiplexage de RTP et RTCP sur un seul port. Pour permettre ce multiplexage, les futures attributions de types de paquets RTCP DEVRAIENT être effectuées après les attributions actuelles dans la plage 209-223, puis dans la plage 194-199, de sorte que seuls les types de charge utile RTP de la plage 64-95 soient bloqués. Les types de paquets RTCP dans les plages 1-191 et 224-254 ne DEVRAIENT être utilisés que lorsque les autres valeurs ont été épuisées.

Compte tenu de ces contraintes, il est RECOMMANDÉ de suivre les directives du profil RTP/AVP [7] pour le choix des valeurs de type de charge utile RTP, avec la restriction supplémentaire que les valeurs de type de charge utile dans la plage 64-95 ne DOIVENT PAS être utilisées. Plus précisément, les types de charge utile RTP dynamiques DEVRAIENT être choisis dans la plage 96-127 lorsque cela est possible. Les valeurs inférieures à 64 PEUVENT être utilisées si cela est insuffisant, auquel cas il est RECOMMANDÉ d'utiliser en premier les numéros de type de charge utile qui ne sont pas attribués de manière statique par [7].

Note : Étant donné que la section 6.1 de [1] stipule que tous les paquets RTCP DOIVENT être envoyés sous forme de paquets composés commençant par un paquet Sender Report (SR) ou Receiver Report (RR), on pourrait se demander pourquoi les types de charge utile RTP autres que 72 et 73 sont interdits lors du multiplexage de RTP et RTCP. Cela est fait pour prendre en charge [18], qui permet l'utilisation de paquets RTCP non composés dans certaines circonstances.