2. Formes des paquets RTP et RTCP et comportement du protocole

2. Formes des paquets RTP et RTCP et comportement du protocole

   La section "Profils RTP et spécifications de format de charge utile" de la RFC 3550 énumère un certain nombre d'éléments qui peuvent être spécifiés ou modifiés dans un profil. Cette section traite de ces éléments. En général, ce profil suit les aspects par défaut et/ou recommandés de la spécification RTP.

   En-tête de données RTP : Le format standard de l'en-tête de données RTP fixe est utilisé (un bit de marqueur).

   Types de charge utile : Les types de charge utile statiques sont définis dans la section 6.

   Ajouts à l'en-tête de données RTP : Aucun champ fixe supplémentaire n'est ajouté à l'en-tête de données RTP.

   Extensions de l'en-tête de données RTP : Aucune extension d'en-tête RTP n'est définie, mais les applications fonctionnant sous ce profil PEUVENT utiliser de telles extensions. Ainsi, les applications NE DEVRAIENT PAS supposer que le bit X de l'en-tête RTP est toujours à zéro et DEVRAIENT être prêtes à ignorer l'extension d'en-tête. Si une extension d'en-tête est définie à l'avenir, cette définition DOIT spécifier le contenu des 16 premiers bits de manière à ce que plusieurs extensions différentes puissent être identifiées.

   Types de paquets RTCP : Aucun type de paquet RTCP supplémentaire n'est défini par cette spécification de profil.

   Intervalle de rapport RTCP : Les constantes suggérées doivent être utilisées pour le calcul de l'intervalle de rapport RTCP. Les sessions fonctionnant sous ce profil PEUVENT spécifier un paramètre distinct pour la bande passante du trafic RTCP plutôt que d'utiliser la fraction par défaut de la bande passante de la session. La bande passante du trafic RTCP PEUT être divisée en deux paramètres de session distincts pour les participants qui sont des expéditeurs de données actifs et ceux qui ne le sont pas. Suivant la recommandation de la spécification RTP [1] selon laquelle 1/4 de la bande passante RTCP doit être dédiée aux expéditeurs de données, les valeurs par défaut RECOMMANDÉES pour ces deux paramètres seraient respectivement de 1,25 % et 3,75 %. Pour une session particulière, la bande passante RTCP pour les non-expéditeurs de données PEUT être fixée à zéro lors d'un fonctionnement sur des liens unidirectionnels ou pour des sessions qui ne nécessitent pas de retour sur la qualité de la réception. La bande passante RTCP pour les expéditeurs de données DEVRAIT être maintenue non nulle afin que les rapports d'expéditeur puissent toujours être envoyés pour la synchronisation inter-imédia et pour identifier la source par CNAME. Les moyens par lesquels le ou les deux paramètres de session pour la bande passante RTCP sont spécifiés dépassent le cadre de ce mémo.

   Extension SR/RR : Aucune section d'extension n'est définie pour le paquet RTCP SR ou RR.

   Utilisation de SDES : Les applications PEUVENT utiliser l'un des éléments SDES décrits dans la spécification RTP. Alors que les informations CNAME DOIVENT être envoyées à chaque intervalle de rapport, les autres éléments NE DEVRAIENT être envoyés que tous les trois intervalles de rapport, avec NOM envoyé sept fois sur huit dans ce créneau et les éléments SDES restants prenant cycliquement le huitième créneau, comme défini dans la section 6.2.2 de la spécification RTP. En d'autres termes, NOM est envoyé dans les paquets RTCP 1, 4, 7, 10, 13, 16, 19, tandis que, par exemple, EMAIL est utilisé dans le paquet RTCP 22.

   Sécurité : Les services de sécurité par défaut de RTP sont également les services par défaut sous ce profil.

   Mappage chaîne-clé : Aucun mappage n'est spécifié par ce profil.

   Congestion : RTP et ce profil peuvent être utilisés dans le contexte d'un service réseau amélioré, par exemple, via les services intégrés (RFC 1633) [4] ou les services différenciés (RFC 2475) [5], ou ils peuvent être utilisés avec un service au mieux (best effort).

   Si un service amélioré est utilisé, les récepteurs RTP DEVRAIENT surveiller la perte de paquets pour s'assurer que le service demandé est réellement fourni. Si ce n'est pas le cas, ils DEVRAIENT supposer qu'ils reçoivent un service au mieux et se comporter en conséquence.

   Si un service au mieux est utilisé, les récepteurs RTP DEVRAIENT surveiller la perte de paquets pour s'assurer que le taux de perte de paquets se situe dans des paramètres acceptables. La perte de paquets est considérée comme acceptable si un flux TCP traversant le même chemin réseau et subissant les mêmes conditions réseau atteindrait un débit moyen, mesuré sur une échelle de temps raisonnable, qui n'est pas inférieur à celui que le flux RTP atteint. Cette condition peut être satisfaite en mettant en œuvre des mécanismes de contrôle de congestion pour adapter le taux de transmission (ou le nombre de couches souscrites pour une session multicast en couches), ou en faisant en sorte qu'un récepteur quitte la session si le taux de perte est inacceptablement élevé.

   La comparaison avec TCP ne peut pas être spécifiée exactement, mais est conçue comme une comparaison "d'ordre de grandeur" en termes d'échelle de temps et de débit. L'échelle de temps sur laquelle le débit TCP est mesuré est le temps aller-retour de la connexion. En substance, cette exigence stipule qu'il n'est pas acceptable de déployer une application (utilisant RTP ou tout autre protocole de transport) sur l'Internet au mieux qui consomme de la bande passante de manière arbitraire et ne concurrence pas équitablement TCP dans un ordre de grandeur.

   Protocole sous-jacent : Le profil spécifie l'utilisation de RTP sur UDP unicast et multicast ainsi que sur TCP. (Cela n'exclut pas l'utilisation de ces définitions lorsque RTP est transporté par d'autres protocoles de couche inférieure.)

   Mappage de transport : Le mappage standard de RTP et RTCP vers les adresses de niveau transport est utilisé.

   Encapsulation : Ce profil laisse aux applications la spécification de l'encapsulation RTP dans des protocoles autres que UDP.