Brevet FR2827451A1 — publié le 20030117

La présente invention concerne un procédé de diffusion d'un contenu en temps réel à partir d'une source vers une pluralité de terminaux récepteurs, à travers un réseau informatique, par exemple Internet. L'Internet permet aujourd'hui de diffuser en temps réel des contenus multimédias, tels que des émissions de télévision, des films vidéo, des conférences et autres programmes, vers une large audience de terminaux récepteurs. Il existe principalement deux méthodes pour diffuser en temps réel un contenu depuis une source vers une pluralité de terminaux récepteurs, à travers l'Internet. En référence à la figure 1, la première méthode, dite"unicast", consiste à envoyer le même contenu autant de fois qu'il y a de terminaux récepteurs T1,..., Ti, ..., Tn. La source S établit une liaison point-à-point avec chacun des terminaux récepteurs, décompose le contenu à diffuser en paquets de données IP, encore appelés"datagrammes", duplique chaque datagramme IP en n exemplaires, n étant égal au nombre de terminaux récepteurs Ti, et envoie ces n exemplaires vers les n terminaux récepteurs Ti respectivement. En référence à la figure 2, la seconde méthode, dite"multicast", permet à la source S de diffuser un contenu multimédia vers une pluralité de terminaux récepteurs, en un seul envoi. Lors de la diffusion du contenu, la source S émet des datagrammes IP, lesquels sont dupliqués en cascade par des noeuds du réseau, que l'on appellera par la suite des"routeurs", afin d'être acheminés jusqu'aux terminaux récepteurs Ti. Si aucun terminal Ti ne demande à recevoir les datagrammes IP émis par la source, ces derniers ne sont pas acheminés au-delà du premier noeud du réseau et sont donc perdus. Lorsqu'un terminal Ti souhaite recevoir le contenu multimédia diffusé par la source S, il envoie une requête d'acquisition de ce contenu en direction de la source S, à travers Internet, en utilisant le protocole IGMP (Internet Group Management Protocol). Le premier routeur multiast, recevant déjà les datagrammes IP diffusés par la source et qui reçoit cette requête, se charge de dupliquer les datagrammes IP puis les achemine vers le terminal ou vers un autre routeur. Par"routeur multicast", on entend désigner un noeud du réseau qui reçoit les datagrammes diffusés par la source S et les achemine vers au moins un terminal récepteur, après les avoir éventuellement dupliqués. Pour recevoir un contenu multimédia diffusé par une source, en mode unicast ou multiast, chaque terminal récepteur doit au préalable récupérer un fichier descriptif SDP (Session Description Protocol) associé à la source, par exemple par téléchargement depuis un site Web. La structure du fichier SDP, définie par l'IETF (Internet Engineering Task Force), est décrite dans le document RFC2327. Ce fichier est destiné à véhiculer les informations requises pour permettre aux terminaux récepteurs de recevoir les contenus multimédias diffusés par la source. A chaque source correspond un fichier SDP général, contenant toutes les informations requises pour se mettre en réception de cette source, quel que soit le contenu diffusé par celle-ci. En outre, à chaque contenu diffusé (émission TV, film, conférence, etc.) correspond un fichier SDP spécifique contenant toutes les informations nécessaires pour recevoir ce contenu particulier. Le fichier SDP général de la source est valable quel que soit le contenu diffusé par la source, alors que le fichier SDP d'un contenu spécifique n'est valable que pour la diffusion de ce contenu. Le protocole de transmission de données essentiellement utilisé pour la diffusion en temps réel, en mode unicast ou multiast, à travers l'Internet, est le protocole RTP (Real-time Transfer Protocol). Il est généralement associé au protocole RTCP (Real-time Transfer Control Protocol) de contrôle des flux de données qui permet aux terminaux récepteurs de faire remonter vers la source des rapports de réception contenant des informations QoS (Quality of Service) sur la qualité de la réception, telles que l'indication du débit de réception ou le taux de perte de datagrammes. Selon le protocole RTP, pour diffuser un contenu multimédia, la source émet une pluralité de flux véhiculant les données correspondant à une pluralité de média respectivement. A titre d'exemple, pour diffuser un film vidéo en deux langues, la source émet un flux vidéo et deux flux audios pour les deux langues respectivement. En outre, les données d'un même média, par exemple vidéo ou audio, peuvent être véhiculées par plusieurs flux ayant des débits de données différents. A titre d'exemple, pour diffuser la composante vidéo d'un contenu audiovisuel, la source peut émettre trois flux vidéos, à 400kbits/s chacun, dont un flux vidéo de base Vb, un premier flux vidéo de rehaussement Ve1 (Video enhancement 1) et un second flux vidéo de rehaussement Ve2 (Video enhancement 2). En réception, suivant leurs capacités, les terminaux récepteurs utilisent le flux vidéo de base en y ajoutant éventuellement le flux vidéo Ve1 et/ou le flux vidéo Ve2 afin d'obtenir une meilleure qualité vidéo. En variante, la source peut émettre trois flux vidéos à 400kbits/s, 800kbits/s et 1200kbits/s respectivement, les terminaux récepteurs sélectionnant l'un seul de ces trois flux suivant leurs capacités. Pour recevoir un contenu multimédia véhiculé par n flux, les terminaux récepteurs utilisent n paires de ports de communication, chaque paire comprenant un port RTP et un port RTCP, pour recevoir les n flux et émettre les n rapports de réception associés à ces n flux. Les ports de communication RTP et RTCP associés d'une même paire se suivent, le port RTP étant pair et le port RTCP impair. En unicast, la source établit autant de liaisons point-à-point qu'il y a de terminaux récepteurs et reçoit régulièrement des rapports de réception, contenant des informations QoS, à travers ces liaisons point-à-point. La source peut donc sans difficulté être informée d'éventuels problèmes de réception d'un terminal donné. Cependant, la technique unicast est gourmande en bande passante et donc inadaptée à la diffusion vers une large audience. A l'inverse, la technique multiast permet de réduire considérablement la consommation en bande passante. Cependant, les terminaux récepteurs n'étant pas connectés directement à la source, elle ne permet pas d'évaluer de façon simple la qualité de réception par les terminaux. En unicast et en multiast, le protocole RTCP permet certes de faire remonter des informations QoS vers la source, mais ce protocole présente de nombreux inconvénients du fait qu'il est intimement lié au protocole RTP. En effet, dans le cas où le contenu diffusé est véhiculé par une pluralité de flux RTP, les terminaux envoient périodiquement un rapport de réception pour chaque flux RTP reçu. Il en résulte que la source reçoit un nombre considérable de rapports, dont la plupart sont redondants. Le problème technique posé par la présente invention consiste donc à proposer un procédé de diffusion en temps réel d'un contenu à partir d'une source vers une pluralité de terminaux récepteurs, à travers un réseau informatique, dans lequel chaque terminal récupère des données descriptives associées à la source, la source diffuse le contenu à travers le réseau et les terminaux récepteurs acquièrent le contenu diffusé, à partir des données descriptives, qui permette d'évaluer la qualité de réception des terminaux de façon simple. Le problème est résolu par le fait qu'on insère dans lesdites données descriptives une adresse d'un serveur de collecte et, à partir desdites données descriptives, chaque terminal envoie un rapport de réception à ladite adresse. La présente invention tire essentiellement son origine d'un problème de diffusion en multiast. Toutefois, la demanderesse entend ne pas limiter la portée de sa demande à cet exemple particulier mais l'étendre à tout type de diffusion, et notamment à la diffusion en unicast. En séparant la source et le collecteur de rapports, on s'affranchit des inconvénients du protocole RTCP. La solution de la présente invention offre l'avantage supplémentaire de ne pas surcharger la source par des remontées de rapports de réception. La source n'est pas chargée du traitement de ces rapports et peut donc exploiter toutes ses capacités exclusivement pour la diffusion. Un autre avantage réside dans le fait que les rapports de réception donnent des informations sur la qualité globale de réception et non pas sur la qualité de réception d'un flux particulier. Grâce à cela, l'exploitation de ces rapports est considérablement facilitée. En outre, l'adresse étant insérée dans les données descriptives associées à la source, le terminal récepteur la récupère sans effectuer d'action spécifique et sans équipement supplémentaire. Avantageusement, on insère dans lesdites données descriptives une information de périodicité de façon à ce que chaque terminal récepteur envoie périodiquement un rapport de réception au serveur de collecte. De préférence, chaque terminal insère dans le rapport de réception une information sur la qualité de la réception. Il peut aussi y insérer une indication géographique de localisation. Grâce à cela, on peut éventuellement détecter un problème de réception lié à l'infrastructure d'un réseau local desservant des terminaux situés dans une zone géographique donnée. De préférence encore, le serveur de collecte attribue une information d'horodatage à chaque rapport de réception reçu. Grâce à cela, un même horloge permet d'horodater tous les rapports de réception. Avantageusement, le serveur de collecte élabore un bilan de réception, à partir des rapports de réception des terminaux. Ce bilan peut comprendre des histogrammes, pour différents instants donnés, sur lesquels figurent, en abscisses, le débit de réception des terminaux et, en ordonnées, le nombre de terminaux en réception. Ces histogrammes constituent des photographies de la qualité de la réception de la population de terminaux en réception. Dans un mode de réalisation particulier, une pluralité de sources diffusant des contenus vers une pluralité de groupes de terminaux récepteurs, l'ensemble des terminaux appartenant aux différents groupes envoient des rapports de réception vers le même serveur de collecte. Ainsi, le serveur de collecte peut recueillir les rapports de réception des terminaux appartenant à différents groupes multiast et élaborer un bilan de réception pour chacune des sources multiast. On peut insérer les données descriptives dans un fichier SDP. On peut aussi diffuser l'adresse du serveur de collecte à travers un canal de signalisation associé à la source. L'invention concerne également un serveur de collecte pour la mise en oeuvre du procédé défini ci-dessus, comprenant des moyens pour recevoir des rapports de réception d'une source de diffusion, des moyens de traitement agencés pour élaborer un bilan de réception à partir des rapports reçus et des moyens pour émettre ledit bilan vers ladite source. L'invention sera mieux comprise à l'aide de la description suivante d'un mode de réalisation particulier du procédé de diffusion et d'une forme de réalisation particulière du serveur de collecte de l'invention, en référence au dessin annexé sur lequel : - la figure 3 représente une vue schématique d'une pluralité de terminaux récepteurs, d'une source de diffusion et d'un serveur de collecte ; - la figure 4 représente une vue schématique de l'un des terminaux récepteurs, d'un site Web, de la source de diffusion et du serveur de collecte, avec les différentes étapes du procédé de diffusion, selon le mode de réalisation particulier de l'invention ; - les figures 5 à 7 représentent des organigrammes du procédé de diffusion, selon le mode de réalisation particulier de l'invention, et - la figure 8 représente un schéma bloc fonctionnel du serveur de collecte de la figure 1. Sur la figure 3, on a représenté un réseau informatique, en l'espèce l'Internet, une pluralité de terminaux T1, T2,..., Ti,..., Tn, des routeurs Internet RM, une source de diffusion S et un serveur de collecte SC. Les différents terminaux T1, T2,..., Ti,..., Tn ont des capacités de réception de données différentes (1Mbit/s, 2Mbit/s, 500kbit/s, etc. ). La source S est ici une chaîne de diffusion audiovisuelle, que l'on appellera par la suite"chaîne 1", hébergée par un serveur audiovisuel de l'Internet et destinée à diffuser en mode multiast des contenus audiovisuels (émissions télévisées, films vidéos, etc. ), à travers l'Internet, vers des terminaux récepteurs. Le serveur audiovisuel pourrait héberger d'autres sources de diffusion. Un centre de programmation CP, non représenté, est destiné à établir une grille de programmation pour la diffusion des contenus audiovisuels par la source S et à créer, pour la source S, un fichier descriptif SDP général, contenant toutes les informations nécessaires pour permettre à un terminal de se mettre en réception de la source S, ainsi que, pour chaque contenu diffusé, un fichier descriptif SDP spécifique contenant toutes les informations requises pour recevoir ce contenu. Les fichiers descriptifs SDP, associés à la source S, sont transmis au site Web SW à partir duquel ils peuvent être téléchargés par des terminaux. On notera ici que la structure d'un fichier SDP, telle que définie par l'IETF, est la suivante : Session description v= (protocol version) o= (owner/creator and session identifier). s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information-not required if included in all media) b=* (bandwidth information) One or more time descriptions (see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more media descriptions (see below) Time description t= (time the session is active) r=* (zero or more repeat times) Media description m= (media name and transport address) i=* (media title) c=* (connection information-optional if included at session-level) b=* (bandwidth information) k=* (encryption key) a=* (zero or more media attribute lines) Les champs marqués du caractère"*"sont optionnels. Pour plus d'informations concernant la structure de données SDP, le lecteur est invité à se reporter au document RFC2327 issu de l'IETF. Le serveur de collecte SC, connecté à l'Internet, est destiné à recueillir des rapports de réception envoyés par des terminaux récepteurs Ti. Il comprend une interface 90 de connexion à l'Internet, un bloc 91 de réception des rapports, un bloc 92 d'horodatage des rapports, un bloc de traitement 93, un bloc 94 d'émission de ce bilan vers la source S et un bloc 95 de modification de la période d'envoi des rapports. Tous ces éléments sont reliés à une unité centrale de commande, non représentée, destinée à commander le fonctionnement du serveur SC. Les blocs 91, 94 et 95 sont reliés à l'interface de connexion 90. Le bloc d'horodatage 92, interposé entre le bloc de réception 91 et le bloc de traitement 93, est destiné à horodater les rapports reçus. Le bloc de traitement 93, connecté au bloc d'émission 94, est destiné à élaborer des bilans statistiques de réception comprenant des histogrammes établis à partir des rapports reçus. En référence aux figures 4 à 7, on va maintenant décrire le procédé de diffusion en temps réel d'un contenu audiovisuel, à partir de la source S, vers une pluralité de terminaux Ti, à travers l'Internet, en mode multiast. Dans l'exemple particulier de la description, le contenu diffusé est un film vidéo intitulé "la grande vadrouille". Dans une étape 1, le centre de programmation CP insère un champ, intitulé "q", associé au serveur de collecte SC, dans le fichier SDP spécifique du contenu à diffuser, à savoir le film"la grande vadrouille", ainsi que dans le fichier SDP général de la source S. Le champ"q", explicité ci-après, contient toutes les informations requises pour permettre à un terminal récepteur Ti d'envoyer périodiquement un rapport de réception au serveur de collecte SC. Champ q q= Le champ"q", lequel constitue en définitive une commande d'envoi de rapports de réception vers le serveur SC, contient l'indication du réseau auquel appartient le serveur SC, le type de l'adresse du serveur SC, l'adresse du serveur SC, le numéro du port de communication du serveur SC et la période r d'envoi des rapports d'audience vers le serveur SC. Le fichier SDP de la source et le fichier SDP du film sont transmis au site SW et peuvent être téléchargés depuis ce site par des terminaux. A titre d'exemple, le fichier SDP du film contient les informations suivantes : v=O 0=chaise1 IN IP4 126.16. 64.4 s=La grande vadrouille u=http ://www. chaine1. fr/films/la~grande~vadrouille. htm e=i nfos@chaine1. fr c=IN IP4 224.2. 17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb q=IN IP4 224.2. 1.1 32416 300 Le champ"q"indique que : - le serveur SC appartient à l'Internet ; - l'adresse du serveur SC est de type IP4 ; - l'adresse IP du serveur SC est 224.2. 1.1 ; - le numéro du port de communication du serveur SC est 32416 et - la période T d'envoi des rapports de réception est égale à 300 secondes. Dans une étape 2, chaque terminal Ti souhaitant recevoir le film récupère le fichier SDP spécifique associé à ce film ou le fichier SDP général de la source S. On rappelle que le fichier SDP du film n'est valable que pour la diffusion du film considéré, alors que le fichier SDP de la source permet de se mettre en réception de la source à tout moment, quel que soit le contenu diffusé par celle-ci. Pour récupérer l'un de ces deux fichiers SDP, dans une étape 2a, le terminal se connecte au site Web SW et lui adresse une requête d'acquisition du fichier SDP considéré. Sur réception de cette requête, dans une étape 2b, le site Web SW transmet le fichier requis au terminal Ti, qui le mémorise. La source S diffuse le film vidéo en mode multiast, à travers Internet. Pour cela, elle émet des paquets de données IP, véhiculant le contenu audiovisuel, en un seul envoi, à travers Internet, vers une pluralité de terminaux récepteurs. Les données audiovisuelles sont ici véhiculées par trois flux vidéos, à 400kbit/s chacun, dont un flux vidéo de base Vb, un premier flux vidéo de rehaussement Ve1 et un second flux vidéo de rehaussement Ve2, et par deux flux audios, à 400kbit/s chacun, dont un flux audio de base Ab et un flux audio de rehaussement Ae. En réception, suivant leurs capacités, les terminaux Ti utilisent les flux vidéo et audio de base Vb et Ab, en y ajoutant éventuellement au moins l'un des flux vidéos de rehaussement Ve1, Ve2 et/ou le flux audio de rehaussement Ae, afin d'améliorer la qualité vidéo et/ou audio. Dans une étape 3, à partir des informations contenues dans le fichier SDP reçu, chaque terminal Ti souhaitant recevoir le film acquiert les paquets de données IP diffusés par la source S à travers l'Internet. L'étape 3 se décompose en plusieurs sous-étapes : - le terminal Ti envoie une requête d'acquisition du contenu audiovisuel diffusé par la source S, à savoir le film vidéo "la grande vadrouille", en direction de la source S, à travers l'Internet, par le protocole IGMP, (étape 3a) ; - le premier routeur multiast RM qui reçoit cette requête duplique les paquets IP reçus provenant de la source (étape 3b) puis - il achemine les paquets IP dupliqués vers le terminal Ti, à travers t'hternet (étape 3c). On rappelle ici que, par définition, un"routeur multicast"est un noeud du réseau qui reçoit des paquets de données IP diffusés par la source S et les achemine vers un ou plusieurs terminaux, après les avoir éventuellement dupliqués, si nécessaire. Dans une étape 4, sur réception du premier paquet de données IP diffusé par la source S, le terminal Ti envoie un rapport de réception au serveur de collecte SC, à travers l'Internet. Ce premier rapport signale au serveur SC que le terminal Ti vient de se mettre en réception de la source S. Il contient des informations sur la qualité de la réception, à savoir le débit de réception du terminal Ti et le taux de perte de paquets IP, ainsi qu'une indication géographique de localisation du terminal Ti. Le terminal Ti réitère l'étape 4 périodiquement, à la fréquence 1h, jusqu'à ce qu'il interrompe la réception des paquets IP diffusés par la source S. Avant d'interrompre la réception, s'il en a la possibilité, le terminal Ti envoie un dernier rapport de réception spécifiant qu'il va cesser de recevoir. Le serveur SC reçoit les rapports émis par tous les terminaux Ti du groupe multiast associé à la source S et attribue à chaque rapport reçu une information d'horodatage, contenant la date et l'heure de réception de ce rapport, dans une étape 5. Par"groupe multicast", on entend désigner l'ensemble des terminaux en réception d'une même source de diffusion multiast. Dans une étape 6, à partir des rapports reçus, le serveur SC élabore un bilan statistique de réception contenant une pluralité d'histogrammes concernant le débit de réception, le taux de perte de paquets IP et la localisation des terminaux Ti. A titre d'exemple, pour un instant donné, l'histogramme relatif au débit de réception fait apparaître en abscisses, le débit de réception des terminaux et, en ordonnées, le nombre de terminaux en réception. Il transmet ensuite ce bilan à la source S. Dans une étape 7, en tenant compte du bilan de réception, la source S peut modifier les débits des flux audios et/ou vidéos en émission afin de les adapter aux conditions réelles de réception. A titre d'exemple, un nombre important de terminaux ne reçoivent pas les flux vidéo et audio de base, Vb et Ab, à 400kbit/s, avec un niveau de qualité satisfaisant, la source S peut créer de nouveaux flux de base à 200kbit/s. Dans une étape 8, afin de diminuer le nombre de rapports reçus, le serveur SC transmet aux terminaux Ti une commande de modification de la période d'envoi des rapports, avec l'indication d'une nouvelle période T'supérieure à la période T. Sur réception de cette commande, chaque terminal Ti remplace l'ancienne période T par la nouvelle période T'en mémoire. De la même manière, le serveur SC pourrait diminuer la période d'envoi des rapports afin d'en recueillir davantage. Le serveur de collecte SC peut être utilisé par une pluralité de sources de diffusion S. Dans ce cas, les différentes sources multiast S diffusant des contenus audiovisuels vers différents groupes multiast de terminaux récepteurs respectivement, l'ensemble des terminaux récepteurs appartenant aux différents groupes multiast font remonter les rapports de réception vers le même serveur collecte SC, lequel élabore un bilan de réception pour chaque source S et transmet ce bilan à la source S considérée. Dans la description qui précède, on insère les données descriptives associées à la source S dans un fichier SDP et les terminaux récepteurs Ti récupèrent ce fichier SDP par téléchargement depuis un site Web SW. Les terminaux pourraient récupérer les données descriptives associées à la source par tout autre moyen. On pourrait par exemple insérer ces données descriptives dans un courrier électronique, ou"mail", envoyé au terminal Ti. Dans une autre variante de réalisation de l'invention, on diffuse les caractéristiques du serveur de collecte à travers un canal de signalisation associé à la source. Dans ce cas, lorsqu'un terminal souhaite recevoir le contenu diffusé par la source de diffusion, il récupère au préalable les informations utiles pour recevoir le canal de signalisation associé à la source, par exemple par téléchargement depuis un site Web, puis se met en réception de ce canal de signalisation afin d'acquérir les données descriptives associées à la source, contenant des informations utiles pour se mettre en réception de cette source ainsi que les caractéristiques du serveur de collecte contenues dans le champ"q"précédemment décrit. Les données descriptives associées à une source de diffusion, contenant toutes les informations requises pour se mettre en réception de cette source, pourrait être contenues dans un fichier de format autre que SDP, par exemple de format XML. L'invention pourrait s'appliquer à la diffusion en temps réel de tout type de contenu, à travers un réseau informatique autre que l'Internet. Elle pourrait également s'appliquer à la diffusion en unicast. REVENDICATIONS 1. Procédé de diffusion en temps réel d'un contenu à partir d'une source (S) vers une pluralité de terminaux récepteurs (Ti), à travers un réseau informatique, dans lequel chaque terminal (Ti) récupère des données descriptives associées à la source (S), la source (S) diffuse le contenu à travers le réseau et les terminaux récepteurs (Ti) acquièrent le contenu diffusé, à partir des données descriptives, procédé caractérisé par le fait qu'on insère dans lesdites données descriptives une adresse d'un serveur de collecte (SC) et, à partir desdites données descriptives, chaque terminal (Ti) envoie un rapport de réception à ladite adresse. 2. Procédé selon la revendication 1, dans lequel on insère dans lesdites données descriptives une information de périodicité de façon à ce que chaque terminal récepteur (Ti) envoie périodiquement un rapport de réception au serveur de collecte (SC). 3. Procédé selon l'une des revendications 1 et 2, dans lequel chaque terminal (Ti) insère dans le rapport de réception une information sur la qualité de la réception. 4. Procédé selon l'une des revendications 1 à 3, dans lequel chaque terminal (Ti) insère dans le rapport de réception une indication géographique de localisation. 5. Procédé selon l'une des revendications 1 à 4, dans lequel le serveur de collecte (SC) attribue une information d'horodatage à chaque rapport de réception reçu. 6. Procédé selon l'une des revendications 1 à 5, dans lequel le serveur de collecte (SC) élabore un bilan de réception, à partir des rapports de réception des terminaux (Ti). 7. Procédé selon l'une des revendications 1 à 6, dans lequel, une pluralité de sources diffusant des contenus vers une pluralité de groupes de terminaux récepteurs (Ti), l'ensemble des terminaux appartenant aux différents groupes envoient des rapports de réception vers le même serveur de collecte (SC). 8. Procédé selon l'une des revendications 1 à 7, dans lequel on insère également dans lesdites données descriptives au moins l'une des informations du groupe contenant l'indication du réseau du serveur de collecte (SC), le type d'adresse du serveur de collecte (SC) et l'indication d'un port de réception des rapports. 9. Procédé selon l'une des revendications 1 à 8, dans lequel le serveur de collecte (SC) transmet aux terminaux récepteurs (Ti) une nouvelle information de périodicité afin de modifier la périodicité d'envoi des rapports. 10. Procédé selon l'une des revendications 1 à 9, dans lequel on insère les données descriptives dans un fichier SDP. 11. Procédé selon l'une des revendications 1 à 10, dans lequel on diffuse l'adresse du serveur de collecte à travers un canal de signalisation associé à la source. 12. Serveur de collecte pour la mise en oeuvre du procédé de la revendication 1, comprenant des moyens (91) pour recevoir des rapports de réception d'une source de diffusion (S), des moyens (93) de traitement agencés pour élaborer un bilan de réception à partir des rapports reçus et des moyens (94) pour émettre ledit bilan vers ladite source (S). 13. Serveur selon la revendication 11, dans lequel il est prévu des moyens (92) pour horodater les rapports. 14. Serveur selon l'une des revendications 12 et 13, dans lequel il est prévu des moyens (95) pour modifier la périodicité d'envoi des rapports de réception.