11. RTP over Network and Transport Protocols (RTP au-dessus des protocoles réseau et de transport)

Cette section décrit les questions spécifiques au transport des paquets RTP au sein de protocoles réseau et de transport particuliers. Les règles suivantes s'appliquent sauf si elles sont remplacées par des définitions spécifiques à un protocole en dehors de cette spécification.

RTP s'appuie sur le(s) protocole(s) sous-jacent(s) pour fournir le démultiplexage des flux de données RTP et de contrôle RTCP. Pour UDP et les protocoles similaires, RTP DEVRAIT utiliser un numéro de port de destination pair et le flux RTCP correspondant DEVRAIT utiliser le numéro de port de destination supérieur (impair) suivant. Pour les applications qui prennent un seul numéro de port comme paramètre et dérivent la paire de ports RTP et RTCP à partir de ce numéro, si un nombre impair est fourni alors l'application DEVRAIT remplacer ce nombre par le nombre inférieur (pair) suivant pour l'utiliser comme base de la paire de ports. Pour les applications dans lesquelles les numéros de port de destination RTP et RTCP sont spécifiés via des paramètres explicites et séparés (en utilisant un protocole de signalisation ou d'autres moyens), l'application PEUT ne pas tenir compte des restrictions selon lesquelles les numéros de port doivent être pairs/impairs et consécutifs bien que l'usage d'une paire de ports pair/impair soit toujours encouragé. Les numéros de port RTP et RTCP NE DOIVENT PAS être identiques puisque RTP s'appuie sur les numéros de port pour démultiplexer les flux de données RTP et de contrôle RTCP.

Dans une session unicast, les deux participants doivent identifier une paire de ports pour la réception des paquets RTP et RTCP. Les deux participants PEUVENT utiliser la même paire de ports. Un participant NE DOIT PAS supposer que le port source du paquet RTP ou RTCP entrant peut être utilisé comme port de destination pour les paquets RTP ou RTCP sortants. Quand des paquets de données RTP sont envoyés dans les deux directions, les paquets RTCP SR de chaque participant DOIVENT être envoyés au port que l'autre participant a spécifié pour la réception de RTCP. Les paquets RTCP SR combinent l'information d'émetteur pour les données sortantes plus l'information de rapport de réception pour les données entrantes. Si un côté n'envoie pas activement de données (voir la section 6.4), un paquet RTCP RR est envoyé à la place.

Il est RECOMMANDÉ que les applications à encodage en couches (voir la section 2.4) utilisent un ensemble de numéros de ports contigus. Les numéros de port DOIVENT être distincts à cause d'un défaut répandu dans les systèmes d'exploitation existants qui empêche l'usage du même port avec de multiples adresses multicast, et pour l'unicast, il n'y a qu'une seule adresse permissible. Ainsi, pour la couche n, le port de données est P + 2n, et le port de contrôle est P + 2n + 1. Quand l'IP multicast est utilisée, les adresses DOIVENT aussi être distinctes parce que le routage multicast et l'appartenance au groupe sont gérés avec une granularité d'adresse. Toutefois, l'allocation d'adresses IP multicast contiguës ne peut être supposée parce que certains groupes peuvent requérir des portées différentes et peuvent par conséquent être alloués à partir de plages d'adresses différentes.

Le paragraphe précédent entre en conflit avec la spécification SDP, RFC 2327 [15], qui dit qu'il est illégal de spécifier à la fois de multiples adresses et de multiples ports dans la même description de session parce que l'association des adresses avec les ports pourrait être ambiguë. Il est prévu que cette restriction sera assouplie dans une révision de la RFC 2327 pour permettre qu'un nombre égal d'adresses et de ports soit spécifié avec une correspondance un-à-un implicite.

Les paquets de données RTP ne contiennent aucun champ de longueur ni autre délimitation, par conséquent RTP s'appuie sur le(s) protocole(s) sous-jacent(s) pour fournir une indication de longueur. La longueur maximale des paquets RTP n'est limitée que par les protocoles sous-jacents.

Si des paquets RTP doivent être transportés dans un protocole sous-jacent qui fournit l'abstraction d'un flux d'octets continu plutôt que de messages (paquets), un encapsulement des paquets RTP DOIT être défini pour fournir un mécanisme de trame (framing). Une trame est aussi nécessaire si le protocole sous-jacent peut contenir du remplissage de sorte que l'étendue de la charge utile RTP ne peut être déterminée. Le mécanisme de trame n'est pas défini ici.

Un profil PEUT spécifier une méthode de trame à utiliser même quand RTP est transporté dans des protocoles qui fournissent une trame, afin de permettre le transport de plusieurs paquets RTP dans une seule unité de données de protocole de couche inférieure, telle qu'un paquet UDP. Le transport de plusieurs paquets RTP dans un seul paquet réseau ou de transport réduit la surcharge d'en-tête et peut simplifier la synchronisation entre différents flux.