1.1. Applicabilité
1.1. Applicabilité
Les paquets XR sont utiles dans plusieurs applications et, pour cette raison, ne sont pas définis comme des extensions spécifiques au profil pour les rapports d'émetteur ou de récepteur RTCP [9, Section 6.4.3]. Néanmoins, ils ne sont pas utiles dans tous les contextes. En particulier, le bloc de rapport de métriques VoIP (Section 4.7) est spécifique aux applications vocales, bien qu'il puisse être utilisé dans une grande variété de telles applications.
Le bloc de rapport de métriques VoIP peut être appliqué à toute application vocale un-à-un ou un-à-plusieurs pour laquelle l'utilisation de RTP et RTCP est spécifiée. L'utilisation de métriques conversationnelles (Section 4.7.5), y compris le facteur R (tel que décrit par le modèle E défini dans [3]) et le score d'opinion moyen pour la qualité conversationnelle (MOS-CQ), dans des applications autres que les simples appels entre deux parties n'est pas définie; par conséquent, ces métriques doivent être identifiées comme non disponibles dans les applications de conférence multicast.
Les types de blocs de rapport paquet par paquet, RLE de perte (Section 4.1), RLE de duplication (Section 4.2) et temps de réception de paquets (Section 4.3), ont été définis en tenant compte des applications de tomographie réseau, telles que l'inférence multicast des caractéristiques du réseau (MINC) [11]. MINC nécessite des traces détaillées de réception de paquets des récepteurs de session multicast afin d'inférer la structure brute de l'arbre de distribution multicast et les paramètres, tels que les taux de perte et les délais, qui s'appliquent aux chemins entre les points de branchement de cet arbre.
Toute application multimédia multicast en temps réel peut utiliser les types de blocs de rapport paquet par paquet. Une telle application pourrait utiliser un sous-système d'inférence MINC qui lui fournirait des informations de topologie d'arbre multicast. Une utilisation potentielle d'un tel sous-système serait l'identification des régions à perte élevée dans l'arbre multicast et l'identification des participants à la session multicast bien situés pour fournir des retransmissions de paquets perdus.
Les rapports détaillés paquet par paquet ne doivent pas nécessairement consommer une bande passante disproportionnée par rapport aux autres paquets RTCP. Une application peut plafonner la taille de ces blocs. Un mécanisme appelé "amincissement" est fourni pour ces blocs de rapport et peut être utilisé pour s'assurer qu'ils respectent une limite de taille en restreignant le nombre de paquets rapportés dans un intervalle de numéros de séquence donné. La justification et l'utilisation de ce mécanisme sont décrites dans [13]. De plus, les applications peuvent ne pas nécessiter de blocs de rapport de tous les récepteurs pour répondre à des questions importantes telles que l'emplacement dans l'arbre multicast des chemins qui dépassent un seuil de taux de perte défini. Des décisions intelligentes concernant les récepteurs qui envoient ces blocs de rapport peuvent restreindre davantage la portion de bande passante RTCP qu'ils consomment.
Les blocs de rapport paquet par paquet peuvent également être utilisés par des applications dédiées de surveillance réseau. Pour une telle application, il pourrait être approprié d'autoriser plus de 5% de la bande passante de données RTP à être utilisée pour les paquets RTCP, permettant ainsi des blocs de rapport proportionnellement plus grands et plus détaillés.
Rien dans les types de blocs paquet par paquet ne restreint leur utilisation aux applications multicast. En particulier, ils pourraient être utilisés pour la tomographie réseau similaire à MINC, mais en utilisant des paquets unicast striés à la place. De plus, s'il était jugé utile, ils pourraient être utilisés pour des applications limitées à deux participants.
Une utilisation pour laquelle les rapports paquet par paquet ne sont pas immédiatement adaptés est celle des accusés de réception de paquets de données dans le cadre d'un mécanisme de retransmission de paquets. La raison en est que la technique de comptabilité de paquets suggérée pour ces blocs diffère de la comptabilité de paquets normalement utilisée par RTP. Afin de favoriser les applications de mesure, un effort est fait pour interpréter aussi peu que possible au niveau du récepteur de données et laisser l'interprétation autant que possible aux participants qui reçoivent les blocs de rapport. Ainsi, par exemple, un paquet avec un ID SSRC anormal ou un numéro de séquence anormal pourrait être exclu par la comptabilité RTP normale, mais serait rapporté à des fins de surveillance réseau.
Le bloc de rapport de résumé statistique (Section 4.6) a également été défini en pensant à la surveillance réseau. Ce type de bloc peut être utilisé aussi bien pour rapporter la réception de paquets unicast que multicast.
Les types de blocs liés au temps de référence ont été conçus pour le contrôle de congestion multicast TCP-friendly basé sur le récepteur [18]. En permettant aux récepteurs de données de calculer leurs temps d'aller-retour vers les émetteurs, ils aident les récepteurs à estimer la bande passante descendante qu'ils devraient demander. Notez que si chaque récepteur doit envoyer des blocs de rapport de temps de référence du récepteur (Section 4.4), un émetteur pourrait potentiellement envoyer un nombre de blocs de rapport DLRR (Section 4.5) égal au nombre de récepteurs dont les paquets RTCP sont arrivés à l'émetteur dans son intervalle de rapport. À mesure que le nombre de participants dans une session multicast augmente, une application doit faire preuve de discrétion quant aux participants qui envoient ces blocs et à quelle fréquence.
Les paquets XR complètent les paquets RTCP existants et peuvent être empilés avec d'autres paquets RTCP pour former des paquets RTCP composés [9, Section 6]. L'introduction de paquets XR dans une session ne modifie en aucun cas les règles régissant le calcul de l'intervalle de rapport RTCP [9, Section 6.2]. Comme les paquets XR sont des paquets RTCP, ils comptent comme tels pour les calculs de bande passante. En conséquence, l'ajout d'informations de rapport étendu peut avoir tendance à augmenter la taille moyenne des paquets RTCP, et donc l'intervalle de rapport moyen. Cette augmentation peut être limitée en limitant la taille des paquets XR.
La signalisation SDP définie pour les paquets XR dans ce document (Section 5) a été réalisée en gardant à l'esprit trois scénarios d'utilisation: une application de streaming contrôlée par le protocole de streaming en temps réel (RTSP), une application multimédia multicast un-à-plusieurs telle qu'une conférence de cours avec retour amélioré, et une session conversationnelle contrôlée par le protocole d'initiation de session (SIP) impliquant deux parties. Les applications qui utilisent SDP sont libres d'utiliser une signalisation SDP supplémentaire pour les cas non couverts ici. De plus, les applications sont libres d'utiliser des mécanismes de signalisation autres que SDP.