2. Formats de paquets RTP et RTCP et comportement du protocole
2.1. RTP
Les règles définies dans [2] s'appliquent également à ce profil, sauf celles mentionnées ci-dessous :
Types de paquets RTCP (RTCP packet types) :
Deux types de paquets RTCP supplémentaires sont enregistrés et les messages FB correspondants pour transporter les informations de retour sont définis à la section 6 de ce mémo.
Intervalles de rapports RTCP (RTCP report intervals) :
Ce document décrit trois modes de fonctionnement qui influencent les intervalles de rapports RTCP (voir la section 3.2 de ce mémo). En mode Regular RTCP, toutes les règles de [1] s'appliquent, sauf l'intervalle minimal recommandé de cinq secondes entre deux rapports RTCP de la même entité RTP. En modes Immediate Feedback et Early RTCP, l'intervalle minimal de cinq secondes entre deux rapports RTCP est supprimé et, en outre, les règles spécifiées à la section 3 de ce mémo s'appliquent si des paquets RTCP contenant des messages FB (définis à la section 4 de ce mémo) doivent être transmis.
Les règles énoncées dans [1] peuvent être remplacées par des descriptions de session spécifiant des paramètres différents (par ex. la part de bande passante assignée à RTCP pour les émetteurs et les récepteurs, respectivement). Pour les sessions définies avec le Session Description Protocol (SDP) [3], les règles de [4] s'appliquent.
Contrôle de congestion (Congestion control) :
Les mêmes règles de base que détaillées dans [2] s'appliquent. Au-delà, la section 7 examine davantage l'impact du retour et la réaction d'un émetteur aux messages FB.
2.2. Protocoles de transport sous-jacents (Underlying Transport Protocols)
RTP est destiné à être utilisé au-dessus de protocoles de transport non fiables, dont UDP et le Datagram Congestion Control Protocol (DCCP). Cette section décrit brièvement les particularités au-delà du fonctionnement RTP simple introduites par le retour RTCP tel que spécifié dans ce mémo.
UDP : UDP assure une livraison best-effort des datagrammes pour les communications point à point ainsi que multicast. UDP ne prend pas en charge le contrôle de congestion ni la réparation d'erreurs. Le retour basé sur RTCP défini dans ce mémo peut fournir un soutien minimal à une réparation d'erreurs limitée. Comme le retour RTCP n'est pas garanti de fonctionner à des échelles de temps suffisamment courtes (de l'ordre du RTT), le retour RTCP ne convient pas pour soutenir le contrôle de congestion. Ce mémo traite à la fois l'unicast et le multicast.
DCCP : DCCP [19] fournit des flux de datagrammes contrôlés en congestion mais non fiables pour les communications unicast. Avec un contrôle de congestion basé sur TCP Friendly Rate Control (TFRC) [20] (CCID 3), DCCP convient particulièrement aux communications audio et vidéo. Les messages d'accusé de réception de DCCP peuvent fournir un rapport de retour détaillé sur les datagrammes reçus et manqués (et donc sur la congestion).
Lorsque RTP s'exécute sur DCCP, le contrôle de congestion est effectué au niveau DCCP et aucun mécanisme supplémentaire n'est requis au niveau RTP. De plus, un émetteur capable de retour RTCP peut tirer parti du retour plus fréquent basé sur DCCP et ainsi un récepteur peut s'abstenir d'utiliser des messages Generic Feedback (supplémentaires) le cas échéant.