Appendix B - Changes from RFC 1889 (Appendice B - Modifications par rapport à la RFC 1889)

La plus grande partie de cette RFC est identique à la RFC 1889. Il n'y a aucun changement dans les formats de paquets sur le réseau, seulement des changements dans les règles et les algorithmes régissant l'usage du protocole. Le plus grand changement est une amélioration de l'algorithme de minuteur passant à l'échelle pour calculer quand envoyer les paquets RTCP :

• L'algorithme de calcul de l'intervalle de transmission RTCP spécifié aux sections 6.2 et 6.3 et illustré à l'appendice A.7 est augmenté pour inclure la « reconsidération » (reconsideration) afin de minimiser la transmission excédant le débit prévu quand de nombreux participants rejoignent une session simultanément, et la « reconsidération inverse » (reverse reconsideration) pour réduire l'incidence et la durée des expirations fausses de participants quand le nombre de participants chute rapidement. La reconsidération inverse est aussi utilisée pour éventuellement raccourcir le délai avant l'envoi d'un SR RTCP lors de la transition du mode récepteur passif au mode émetteur actif.

• La section 6.3.7 spécifie de nouvelles règles contrôlant quand un paquet RTCP BYE devrait être envoyé afin d'éviter une inondation de paquets quand de nombreux participants quittent une session simultanément.

• L'exigence de conserver l'état pour les participants inactifs pendant une période assez longue pour couvrir les partitions réseau typiques a été retirée de la section 6.2.1. Dans une session où de nombreux participants rejoignent pour un bref temps et omettent d'envoyer BYE, cette exigence causerait une surestimation significative du nombre de participants. L'algorithme de reconsidération ajouté dans cette révision compense le grand nombre de nouveaux participants rejoignant simultanément quand une partition se résorbe.

Il devrait être noté que ces améliorations n'ont un effet significatif que lorsque le nombre de participants à la session est grand (des milliers) et que la plupart des participants rejoignent ou quittent en même temps. Cela rend les tests sur un réseau réel difficiles. Toutefois, l'algorithme a été soumis à une analyse et une simulation approfondies pour vérifier ses performances. De plus, l'algorithme amélioré a été conçu pour interopérer avec l'algorithme de la RFC 1889 de sorte que le degré de réduction de la bande passante RTCP excédentaire pendant une jointure par étapes est proportionnel à la fraction des participants qui implémentent l'algorithme amélioré. L'interopérabilité des deux algorithmes a été vérifiée expérimentalement sur des réseaux réels.

Les autres changements fonctionnels étaient :

• La section 6.2.1 spécifie que les implémentations peuvent stocker seulement un échantillonnage des identificateurs SSRC des participants pour permettre la passage à l'échelle de très grandes sessions. Des algorithmes sont spécifiés dans la RFC 2762 [21].

• Dans la section 6.2, il est spécifié que les bandes passantes RTCP émetteur et non-émetteur peuvent être fixées comme des paramètres séparés de la session plutôt qu'un pourcentage strict de la bande passante de session, et peuvent être fixées à zéro. L'exigence que RTCP soit obligatoire pour les sessions RTP utilisant le multicast IP a été assouplie. Toutefois, une clarification a aussi été ajoutée indiquant que désactiver RTCP N'EST PAS RECOMMANDÉ.

• Dans les sections 6.2, 6.3.1 et l'appendice A.7, il est spécifié que la fraction de participants en dessous de laquelle les émetteurs obtiennent une bande passante RTCP dédiée change de la valeur fixe 1/4 à un ratio basé sur les paramètres de bande passante RTCP émetteur et non-émetteur quand ceux-ci sont fournis. La condition qu'aucune bande passante ne soit dédiée aux émetteurs quand il n'y a pas d'émetteurs a été retirée puisqu'on s'attend à ce que ce soit un état transitoire. Cela empêche aussi les non-émetteurs d'utiliser la bande passante RTCP émetteur quand ce n'est pas prévu.

• Toujours dans la section 6.2, il est spécifié que l'intervalle RTCP minimum peut être mis à l'échelle à des valeurs plus petites pour les sessions à haute bande passante, et que le délai RTCP initial peut être fixé à zéro pour les sessions unicast.

• L'expiration d'un participant doit être basée sur l'inactivité pendant un certain nombre d'intervalles de rapport RTCP calculés en utilisant la fraction de bande passante RTCP récepteur même pour les émetteurs actifs.

• Les sections 7.2 et 7.3 spécifient que les traducteurs et les mélangeurs devraient envoyer des paquets BYE pour les sources qu'ils ne transfèrent plus.

• Les changements de règles pour les encodages en couches sont définis aux sections 2.4, 6.3.9, 8.3 et 11. Dans la dernière de celles-ci, il est noté que la règle d'assignation d'adresse et de port entre en conflit avec la spécification SDP, RFC 2327 [15], mais il est prévu que cette restriction sera assouplie dans une révision de la RFC 2327.

• La convention pour l'usage de paires de ports pair/impair pour RTP et RTCP à la section 11 a été clarifiée pour se référer aux ports de destination. L'exigence d'utiliser une paire de ports pair/impair a été retirée si les deux ports sont spécifiés explicitement. Pour les sessions RTP unicast, des paires de ports distinctes peuvent être utilisées pour les deux extrémités (sections 3, 7.1 et 11).

• Une nouvelle section 10 a été ajoutée pour expliquer l'exigence de contrôle d'encombrement dans les applications utilisant RTP.

• Dans la section 8.2, l'exigence qu'un nouvel identificateur SSRC DOIVE être choisi chaque fois que l'adresse de transport de source est changée a été assouplie pour dire qu'un nouvel identificateur SSRC PEUT être choisi. Corrélativement, il a été clarifié qu'une implémentation PEUT choisir de conserver les paquets de la nouvelle adresse source plutôt que de l'adresse source existante quand une collision SSRC survient entre deux autres participants, et DEVRAIT le faire pour des applications telles que la téléphonie où certaines sources telles que des entités mobiles peuvent changer d'adresses au cours d'une session RTP.

• Un bogue d'indentation dans l'impression RFC 1889 du pseudo-code pour l'algorithme de détection et de résolution de collision de la section 8.2 a été corrigé en traduisant la syntaxe en pseudo-langage C, et l'algorithme a été modifié pour retirer la restriction que RTP et RTCP doivent tous deux être envoyés depuis le même numéro de port source.

• La description du mécanisme de remplissage pour les paquets RTCP a été clarifiée et il est spécifié que le remplissage NE DOIT être appliqué qu'au dernier paquet d'un paquet RTCP composé.

• Dans la section A.1, l'initialisation de base_seq a été corrigée pour être seq plutôt que seq - 1, et le texte a été corrigé pour dire que le numéro de séquence erroné plus 1 est stocké. L'initialisation de max_seq et d'autres variables pour l'algorithme a été séparée du texte pour clarifier que cette initialisation doit être faite en plus de l'appel de la fonction init_seq() (et quelques mots perdus dans la RFC 1889 lors du traitement du document de la source vers la forme de sortie ont été restaurés).

• La limitation du nombre de paquets perdus dans la section A.3 a été corrigée pour utiliser à la fois des limites positives et négatives.

• La spécification de l'horodatage NTP « relatif » dans la section SR RTCP définit maintenant ces horodatages comme basés sur l'horloge spécifique au système la plus commune, telle que le temps de fonctionnement système (uptime), plutôt que sur le temps écoulé de session qui ne serait pas le même pour de multiples applications démarrées sur la même machine à des moments différents.

Changements non fonctionnels :

• Il est spécifié qu'un récepteur DOIT ignorer les paquets avec des types de charge utile qu'il ne comprend pas.

• Dans la figure 2, la valeur d'horodatage NTP à virgule flottante a été corrigée, des zéros de tête manquants ont été ajoutés dans un nombre hexadécimal, et le fuseau horaire UTC a été spécifié.

• L'inconséquence du retour à zéro des horodatages NTP en l'année 2036 est expliquée.

• La politique d'enregistrement des types de paquets RTCP et des types SDES a été clarifiée dans une nouvelle section 15, Considérations IANA. La suggestion que les expérimentateurs enregistrent les numéros dont ils ont besoin puis annulent l'enregistrement de ceux qui s'avèrent inutiles a été retirée au profit de l'usage de APP et PRIV. L'enregistrement des noms de profil a aussi été spécifié.

• La référence pour le jeu de caractères UTF-8 a été changée d'une spécification préliminaire X/Open pour devenir la RFC 2279.

• La référence pour la RFC 1597 a été mise à jour vers la RFC 1918 et la référence pour la RFC 2543 a été mise à jour vers la RFC 3261.

• Le dernier paragraphe de l'introduction de la RFC 1889, qui mettait en garde les implémenteurs de limiter le déploiement sur l'Internet, a été retiré parce qu'il était jugé non pertinent.

• Une note non normative concernant l'usage de RTP avec le Multicast Spécifique à la Source (SSM, Source-Specific Multicast) a été ajoutée à la section 6.

• La définition de « session RTP » à la section 3 a été étendue pour reconnaître qu'une seule session peut utiliser de multiples adresses de transport de destination (comme cela a toujours été le cas pour un traducteur ou un mélangeur) et pour expliquer que la caractéristique distinctive d'une session RTP est que chacune correspond à un espace d'identificateur SSRC séparé. Une nouvelle définition de « session multimédia » a été ajoutée pour réduire la confusion au sujet du mot « session ».

• La signification d'« instant d'échantillonnage » (sampling instant) a été expliquée plus en détail dans le cadre de la définition du champ d'horodatage de l'en-tête RTP à la section 5.1.

• De petites clarifications du texte ont été faites en plusieurs endroits, certaines en réponse à des questions de lecteurs. En particulier :

  • Dans la RFC 1889, les cinq premiers mots de la deuxième phrase de la section 2.2 avaient été perdus lors du traitement du document de la source vers la forme de sortie, mais sont maintenant restaurés.

  • Une définition pour « type de média RTP » (RTP media type) a été ajoutée à la section 3 pour permettre à l'explication du multiplexage des sessions RTP à la section 5.2 d'être plus claire concernant le multiplexage de médias multiples. Cette section explique maintenant aussi que le multiplexage de multiples sources d'un même média basé sur les identificateurs SSRC peut être approprié et est la norme pour les sessions multicast.

  • La définition de « moyens non-RTP » (non-RTP means) a été étendue pour inclure des exemples d'autres protocoles constituant des moyens non-RTP.

  • La description du paramètre de bande passante de session est étendue à la section 6.2, incluant une clarification que la bande passante du trafic de contrôle s'ajoute à la bande passante de session pour le trafic de données.

  • L'effet de la variation de la durée des paquets sur le calcul de gigue a été expliqué à la section 6.4.4.

  • La méthode pour terminer et remplir une séquence d'éléments SDES a été clarifiée à la section 6.5.

  • Des exemples d'adresses IPv6 ont été ajoutés dans la description du CNAME SDES à la section 6.5.1, et « example.com » a été utilisé à la place d'autres noms de domaine d'exemple.

  • La section Sécurité a ajouté une référence formelle à IPSEC maintenant qu'il est disponible, et dit que la méthode de confidentialité définie dans cette spécification est principalement pour codifier la pratique existante. Il est RECOMMANDÉ que des algorithmes de chiffrement plus forts tels que Triple-DES soient utilisés à la place de l'algorithme par défaut, et il est noté que le profil SRTP basé sur AES sera le bon choix dans le futur. Une mise en garde concernant la faiblesse de l'en-tête RTP comme vecteur d'initialisation a été ajoutée. Il a aussi été noté que le chiffrement de la seule charge utile est nécessaire pour permettre la compression d'en-tête.

  • La méthode pour le chiffrement partiel de RTCP a été clarifiée ; en particulier, le CNAME SDES est transporté dans une seule partie quand le paquet RTCP composé est scindé.

  • Il est clarifié qu'un seul paquet RTCP composé devrait être envoyé par intervalle de rapport et que s'il y a trop de sources actives pour que les rapports tiennent dans la MTU, alors un sous-ensemble des sources devrait être sélectionné en tourniquet sur de multiples intervalles.

  • Une note a été ajoutée à l'appendice A.1 indiquant que les paquets peuvent être sauvegardés pendant la validation de l'en-tête RTP et livrés en cas de succès.

  • La section 7.3 explique maintenant qu'un mélangeur agrégeant des paquets SDES utilise plus de bande passante RTCP en raison de paquets plus longs, et qu'un mélangeur laissant passer RTCP envoie naturellement des paquets à un débit supérieur au débit d'une source unique, mais que les deux comportements sont valides.

  • La section 13 clarifie qu'une application RTP peut utiliser de multiples profils mais typiquement un seul dans une session donnée.

  • Les termes MUST, SHOULD, MAY, etc. sont utilisés tels que définis dans la RFC 2119.

  • La bibliographie a été divisée en références normatives et informatives.