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 :

1. 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.

2. 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).

3. 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.