FR 2909241 A1 20080530 FR 0655131 A 20061127 La présente invention est relative aux communications sur des réseaux hétérogènes, filaire et non filaire, et plus particulièrement à la configuration dynamique des points d'interconnexion de réseaux pour la gestion des erreurs de transmission. Les altérations et les pertes d'informations survenues au cours du transfert des données à travers un réseau peuvent être à l'origine d'effets importants pour le traitement des données coté client. Les erreurs de transmission de données multimédia peuvent être, par exemple, à l'origine de fortes distorsions visuelles sur la présentation du contenu multimédia transmis. La mise en oeuvre de mécanismes de gestion d'erreur adaptés s'est avérée nécessaire pour maintenir une certaine qualité de service, d'autant plus que les caractéristiques particulières des réseaux sans fil ont montré les limites des mécanismes existants pour les réseaux filaires basés sur des modèles statiques tels que les mécanismes appelés FEC (Forward Error Correction). En effet ces mécanismes statiques reposant sur l'utilisation de la redondance d'information dans les paquets de données se révèlent d'autant plus efficaces que la redondance introduite est importante. Leur utilisation peut donc générer un surdébit (overhead) et une réservation de bande passante significatifs, bien qu'insuffisants pour corriger des erreurs générées par un réseau sans fil et constants donc inadaptés aux conditions fluctuantes des réseaux sans fil. Les mécanismes dynamiques de gestion d'erreur basés sur la retransmission de type ARQ (Automatic Repeat reQuest) ou Hybrid ARQ, bien que potentiellement à l'origine de retransmissions inutiles, se révèlent de ce point de vue plus adaptés. Cependant, même si ces méthodes présentent dans ce contexte de bons résultats, elles présentent l'inconvénient de conduire l'élément 2909241 2 appliquant le mécanisme à ignorer les données erronées qui n'auraient pu être intégralement corrigées. Or certaines données même erronées, notamment pour les flux vidéo, peuvent s'avérer utiles au client, notamment aux décodeurs pour lesquels le décodage même partiel de 5 données permet de limiter les distorsions dues aux erreurs de transmission. Dans un contexte de transfert en continu (streaming) et en temps réel de flux multimédia, les flux transitent sous forme de paquets du serveur au client. A chaque paquet est associée une échéance : le paquet 10 doit être transmis en respectant une durée de transmission maximale. Dans un système de transfert en continu en temps réel sur des réseaux hétérogènes, chaque paquet transite sur des réseaux filaires et non filaires, avant d'être finalement acheminé jusqu'au client. Les Points d'InterConnexion des réseaux, appelés PICs, reçoivent les paquets d'un 15 réseau et les retransmettent sur un autre. Ils constituent de ce fait des intervenants majeurs dans la gestion des erreurs générées par les réseaux en implémentant des mécanismes de gestion d'erreurs (par exemple de type FEC, ARQ ou hybrid ARQ). Cependant, si les méthodes conventionnellement mises en 20 oeuvre au niveau des PICs pour la gestion des erreurs sur les réseaux sans fil, de type ARQ ou hybrid ARQ, présentent de bons résultats, elles ne permettent pas de transmettre au client les données erronées n'ayant pu être intégralement corrigées. De plus alors que les variations du réseau sans fil sont 25 fréquentes et influent sur la nature et la quantité d'erreurs de transmission, ces mécanismes ne répondent pas au besoin de pouvoir adapter la politique de gestion d'erreur aux conditions de transmission fluctuantes et à la nature des données transmises. Il est donc nécessaire de disposer d'un mécanisme permettant 30 d'accroître la probabilité de distribution des données importantes dans leur intégrité et dans les temps, en adaptant aux conditions variables du réseau la politique de gestion d'erreur que le PIC devra mettre en oeuvre à 2909241 3 partir des méthodes de détection et de correction d'erreur connues (par exemple FEC, ARQ et Hybrid ARQ) en fonction de différents critères, définis dynamiquement à partir d'informations sur les réseaux et les erreurs observées et inhérents à la nature des données gérées. 5 Le brevet US 5,457,701 décrit une méthode permettant d'indiquer au client qu'une erreur ne pouvant être corrigée par le réseau s'est produite durant le transfert des données via des réseaux hétérogènes dans un système de communications multipoints. Ce système permet la détection d'erreurs "irréparables" ne 10 pouvant être corrigées par les moyens disponibles au niveau du réseau. Des bits sont ajoutés par le serveur à chaque paquet avant qu'il ne soit transmis, de façon à réserver un espace d'information pour le contrôle d'erreur. Ces bits sont initialisés par le serveur à leur valeur par défaut indiquant l'intégrité des données. 15 Ainsi, lorsqu'au cours du transfert du paquet vers le client une erreur "irréparable" est détectée par un point d'interconnexion de réseaux, les bits prévus à cet effet sont modifiés pour une valeur prédéfinie indiquant l'altération des données. Le paquet erroné ainsi modifié est ensuite transmis au client 20 dans le flux de données d'origine. Le client doit, à la réception des données, examiner les bits réservés au contrôle d'erreur afin de déterminer l'intégrité des données reçues. Cependant, ce mécanisme repose sur une politique de gestion d'erreur identique pour tous les paquets transférés, quelles que soient 25 leur signification dans le flux et les contraintes qui leur sont liées (par exemple faible délai de latence et haut débit). Par ailleurs cette invention n'exploite que partiellement la phase de correction d'erreur, mise en oeuvre suite à la détection d'erreur, lorsque celle-ci ne peut conduire à la correction intégrale des données erronées. 30 Le mécanisme décrit permet simplement de signaler que l'erreur détectée n'a pu être intégralement corrigée, les données étant par la suite transmises au client telles quelles. 2909241 4 Enfin, dans cette invention, les données irréparables identifiées par la valeur des bits réservés pour le contrôle d'erreur sont transmises au client dans leur flux d'origine avec les données non erronées, obligeant le client à examiner l'ensemble des paquets reçus afin de 5 déterminer le traitement adéquate. Une telle invention requiert donc des systèmes propriétaires pour les clients et les serveurs. L'article intitulé "Link-level partial checksum for real-time video transmission over 802.11 Wireless networks" d'E. Masala, M. Bottero et JC De Martin (IEIIT-CNR di Torino, Vehicular Technology Conference, 2005, VTC 10 2005-Spring, 2005 IEEE 61st) décrit une technique d'évolution du processus de détection des erreurs du standard IEEE 802.11 afin d'assurer une meilleure qualité des échanges de flux vidéo sur les réseaux sans fil, en permettant à certains paquets partiellement corrompus au cours de leur transfert sur le réseau d'être simplement 15 relayés par le PIC au lieu d'être abandonnés. L'étude présentée dans cet article s'intéresse tout particulièrement à l'à-propos d'effectuer une détection d'erreur sur l'ensemble des bits de données transférés. Elle révèle que l'application d'un mécanisme de détection d'erreur limitée aux données les plus 20 pertinentes assure une meilleure qualité de transfert des données en temps réel, les données de moindre importance étant relayées au client telles quelles sans contrôle d'erreur. Le mécanisme proposé qui en découle repose sur l'utilisation d'un contrôle (checksum) partiel permettant une couverture sélective et 25 dynamique des données échangées. Lorsque le PIC détecte une erreur dans la zone de données couverte par le contrôle, il met en oeuvre un mécanisme de correction d'erreur standard de type ARQ. Si la zone couverte par le contrôle ne peut être intégralement corrigée au cours de cette phase, le paquet est alors abandonné. Dans le cas contraire le 30 paquet corrigé sur la zone couverte est transmis au client quelque soit l'état des données non couvertes. 2909241 5 Ce mécanisme repose sur l'évolution de la couverture des données pour la détection d'erreur. L'invention permet de résoudre au moins un des problèmes exposés précédemment. 5 En particulier, l'invention tend à limiter l'impact des erreurs de transmission sur le rendu final en transmettant au client les données erronées au mieux partiellement corrigées, au cours d'un processus de gestion d'erreurs sélectif subordonné à des contraintes et critères imposés de façon dynamique par le client au Point d'InterConnexion 10 mettant en oeuvre le processus, accompagnées d'informations complémentaires, portant notamment sur l'erreur et la donnée d'origine. L'invention a ainsi pour objet un procédé pour optimiser le transfert d'au moins un paquet de données dans un réseau comprenant au moins un serveur et un client, ce procédé comprenant les étapes 15 suivantes, - réception dudit client d'au moins une description de configuration ; - réception dudit serveur dudit au moins un paquet ; détection des erreurs comprises dans ledit au moins un 20 paquet reçu ; et, - si ledit au moins un paquet reçu comprend au moins une erreur, application audit au moins un paquet reçu d'au moins un mécanisme de correction d'erreur spécifié dans ladite au moins une description de configuration. 25 Un intérêt particulier de l'invention concerne les contraintes spécifiques de chaque donnée erronée et du flux dont elle est issue. Chaque PIC détectant une erreur applique de façon sélective, en fonction des contraintes et critères définis dynamiquement dans la description de configuration (en anglais, Configuration Map) que le client lui aura 30 préalablement transmis, les mécanismes de gestion d'erreur appropriés. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de transmission audit client dudit paquet reçu sur 2909241 6 lequel ledit au moins un mécanisme de correction d'erreur spécifié dans ladite au moins une description de configuration a été appliqué si le résultat de cette application a corrigé ladite au moins une erreur. Selon un mode de réalisation particulier, le procédé comprend 5 en outre une étape de sélection dudit au moins un paquet reçu selon au moins un critère de sélection de ladite description de configuration, ladite application dudit au moins un mécanisme de correction d'erreur audit un moins un paquet reçu étant effectuée si ledit au moins un paquet reçu satisfait ledit au moins un critère de sélection. L'invention permet ainsi 10 une application sélective des mécanismes de correction d'erreur. Toujours selon un mode de réalisation particulier, si ledit paquet reçu comprenant au moins une erreur n'est pas intégralement corrigé ou si ledit paquet reçu n'est pas sélectionné selon ledit au moins un critère de ladite description de configuration, le procédé comprend en 15 outre les étapes suivantes, - création d'au moins un nouveau paquet de données comprenant les données dudit paquet reçu comprenant au moins une erreur, potentiellement partiellement corrigées ; et, - transmission dudit au moins un paquet créé audit client. 20 L'invention permet ainsi de capitaliser le travail de détection et de correction d'erreur effectué par le PIC. Ces données sont transmises au client de sorte qu'elles sont facilement identifiables et puissent être ignorées par le client sans surcharge de travail. Avantageusement, ledit au moins un paquet créé est transmis 25 sur un flux particulier, de préférence identifié dans ladite au moins une description de configuration. De façon avantageuse, ledit au moins un paquet créé comprend des informations privées liées à la détection ou à la tentative de correction de ladite au moins une erreur et à l'identification des données 30 et de leur flux d'origine, tel que précisé dans ladite description de configuration. Ledit au moins un critère de ladite description de configuration comprend de préférence au moins une identification de flux. 2909241 7 De même, ledit au moins un critère de ladite description de configuration comprend au moins un paramètre lié à la nature des données des paquets. Ledit au moins un critère de ladite description de configuration comprend également de préférence des informations adaptées à contrôler 5 au moins un mécanisme de gestion d'erreur. Si la phase de correction d'erreur ne permet d'aboutir qu'à une correction partielle des données, ce sont les données partiellement corrigées accompagnées d'informations complémentaires, portant notamment sur l'erreur, la correction obtenue et l'origine de la donnée, qui 10 sont transmises au client, lui évitant ainsi d'avoir à refaire le travail déjà effectué par le PIC. Dans un mode de réalisation particulier, le procédé comprend en outre la mise en oeuvre d'au moins un mécanisme de correction d'erreur par défaut si ledit au moins un paquet reçu comprenant au moins 15 une erreur n'appartient pas à un flux spécifié dans ladite description de configuration. Les données irréparables sont extraites de leur flux d'origine pour être empaquetées dans de nouveaux paquets accompagnées d'informations complémentaires portant notamment sur les données 20 elles-mêmes, en particulier leur flux d'origine et leur numéro de séquence, et sur l'erreur éventuellement partiellement corrigée, en particulier le FEC d'origine, la position et l'étendue de l'erreur à la réception, la position et l'étendue de l'erreur après correction et l'algorithme ayant conduit à la correction partielle, selon les indications fournies par la description de 25 configuration préalablement transmises par le client. Ces paquets sont ensuite transmis dans un nouveau flux, dédié au transfert de données erronées vers ce client et n'appartenant pas à la séquence multimédia d'origine. Ce nouveau flux peut être ignoré par le client, s'il ne dispose pas des moyens ou ressources nécessaires pour le traiter. L'invention 30 peut donc être supportée par des clients et serveurs standards. 2909241 8 L'invention a aussi pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. L'invention a aussi pour objet un point d'interconnexion de 5 réseaux comprenant le programme d'ordinateur défini précédemment et des moyens adaptés à la mise en oeuvre de ce programme d'ordinateur. L'invention a également pour objet un procédé pour optimiser la réception d'au moins un paquet de données dans un réseau comprenant au moins un point d'interconnexion, ce procédé comprenant les étapes 10 suivantes, -définition d'au moins une description de configuration comprenant au moins des informations adaptées à enrichir des paquets de données comprenant des erreurs ayant été préalablement détectées; - transmission audit au moins un point d'interconnexion de 15 ladite au moins une description de configuration ; - réception dudit au moins un paquet dudit au moins un point d'interconnexion ; et, - traitement dudit au moins un paquet reçu selon lesdites informations adaptées à enrichir des paquets de données comprenant des 20 erreurs ayant été préalablement détectées. L'invention permet ainsi de capitaliser le travail de détection et de correction d'erreur effectué par le PIC. Ces données reçues par le client sont facilement identifiables et peuvent être ignorées sans surcharge de travail. 25 L'utilisation de contraintes et de critères définis dynamiquement dans la description de configuration permet au client de recevoir des paquets de données préalablement traités par le PIC de façon adaptée. Avantageusement, la description de configuration comprend des informations adaptées à identifier des paquets de données, le 30 procédé comprenant une étape d'identification dudit au moins un paquet reçu selon lesdites informations adaptées à identifier des paquets de 2909241 9 données, ledit au moins un paquet reçu étant traité si ledit au moins un paquet reçu est identifié. De façon avantageuse, lesdites informations adaptées à identifier des paquets de données comprennent un identifiant d'au moins 5 un flux additionnel pour identifier les paquets de données nécessitant un traitement adapté. Selon un mode de réalisation particulier, ledit au moins un paquet reçu comprend des informations relatives à au moins un mécanisme de détection ou de correction d'erreur préalablement mis en 10 oeuvre sur au moins une partie des données dudit au moins un paquet reçu selon lesdites informations adaptées à enrichir des paquets de données comprenant des erreurs ayant été préalablement détectées. L'invention a aussi pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des 15 étapes du procédé décrit précédemment ainsi qu'un dispositif client comprenant ce programme d'ordinateur et des moyens adaptés à la mise en oeuvre de ce programme d'ordinateur. L'invention a également pour objet un dispositif pour optimiser le transfert d'au moins un paquet de données dans un réseau comprenant 20 au moins un serveur et un client, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, -des moyens pour recevoir dudit client au moins une description de configuration ; - des moyens pour recevoir dudit serveur ledit au moins un 25 paquet; - des moyens pour détecter les erreurs dans ledit au moins un paquet reçu ; et, - des moyens pour appliquer audit au moins un paquet reçu au moins un mécanisme de correction d'erreur spécifié dans ladite au moins 30 description de configuration si ledit au moins un paquet reçu comprend au moins une erreur. 2909241 10 Selon un mode de réalisation particulier, le dispositif comprend en outre des moyens pour transmettre audit client ledit paquet reçu et sélectionné, sur lequel ledit au moins un mécanisme de correction d'erreur spécifié dans ladite au moins une description de configuration a 5 été appliqué, si le résultat de cette application a corrigé ladite au moins une erreur. Selon un mode de réalisation particulier, le dispositif comprend en outre des moyens pour sélectionner ledit au moins un paquet reçu selon au moins un critère de sélection de ladite au moins une description 10 de configuration, ledit au moins un mécanisme de correction d'erreur étant appliqué audit au moins un paquet reçu si ledit au moins un paquet reçu est sélectionné. Toujours selon un mode de réalisation particulier, le dispositif comprend en outre les moyens suivants, 15 - des moyens pour créer au moins un nouveau paquet de données comprenant les données dudit paquet reçu et sélectionné, comprenant au moins une erreur, si ledit paquet reçu et sélectionné comprenant au moins une erreur n'est pas intégralement corrigé ; et, - des moyens pour transmettre ledit au moins un paquet créé 20 audit client. Ainsi, si la phase de correction d'erreur ne permet d'aboutir qu'à une correction partielle des données, ce sont les données partiellement corrigées accompagnées d'informations complémentaires, portant notamment sur l'erreur, la correction obtenue et l'origine de la donnée, qui 25 sont transmises au client, lui évitant ainsi d'avoir à refaire le travail déjà effectué par le PIC. Le dispositif selon l'invention permet ainsi de capitaliser le travail de détection et de correction d'erreur effectué par le PIC. De façon avantageuse, ledit au moins un paquet créé est 30 transmis sur un flux particulier, de préférence identifié dans ladite au moins une description de configuration. 2909241 11 Toujours de façon avantageuse, ledit au moins un paquet créé comprend des informations privées liées à la tentative de correction de ladite au moins une erreur et à l'identification des données et de leur flux d'origine. 5 L'invention a également pour objet un dispositif pour optimiser la réception d'au moins un paquet de données dans un réseau comprenant au moins un point d'interconnexion, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - des moyens pour définir au moins une description de 10 configuration comprenant au moins des informations adaptées à enrichir des paquets de données comprenant des erreurs ayant été préalablement détectées ; - des moyens pour transmettre audit au moins un point d'interconnexion ladite au moins une description de configuration ; 15 -des moyens pour recevoir ledit au moins un paquet dudit au moins un point d'interconnexion ; et, - des moyens pour traiter ledit au moins un paquet reçu selon lesdites informations adaptées à enrichir des paquets de données comprenant des erreurs ayant été préalablement détectées. 20 L'invention permet ainsi de limiter les pertes de données, les paquets de données erronées étant transmis au client final. Selon un mode de réalisation particulier, ladite description de configuration comprend des informations adaptées à identifier des paquets de données, ledit dispositif comprenant des moyens pour 25 identifier ledit au moins un paquet reçu selon lesdites informations adaptées à identifier des paquets de données, ledit au moins un paquet reçu étant traité si ledit au moins un paquet reçu est identifié. L'invention permet également la transmission au client des corrections d'erreur partielles obtenues pour les données irréparables, au 30 cours de l'application des mécanismes de correction d'erreur appropriés sur le PIC, de façon à capitaliser le travail déjà effectué. 2909241 12 L'invention permet aussi d'améliorer le rendu final des données transmises du fait de la moindre importance des pertes de données, les données même erronées étant également transmises au client et de la correction partielle assurée par le PIC sur les données erronées, allégeant 5 la tâche de gestion d'erreur du client. La possibilité d'ignorer le flux dédié aux données erronées permet aux clients standards incapables de gérer ce type de flux ainsi qu'aux clients propriétaires désireux de conserver leurs ressources locales pour d'autres besoins de traiter les flux de données originaux 10 issus d'un PIC mettant en oeuvre l'invention. La définition et la transmission dynamique par le client des critères et des contraintes de choix des données erronées pour l'application de mécanismes d'erreur et la définition et la transmission dynamique par le client de la nature des informations privées à associer 15 aux données erronées transmises au client autorisent une adaptation dynamique du traitement effectué par le PIC des données transmises et permettent l'évolutivité des PIC aux besoins futurs sans modification majeure. Enfin, l'absence de modification côté serveur permet l'utilisation 20 de serveurs standards. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 représente schématiquement un exemple 25 d'environnement permettant la mise en oeuvre de l'invention ; - la figure 2 montre un exemple d'appareil permettant d'implémenter au moins partiellement l'invention ; - la figure 3 illustre certaines étapes de l'algorithme selon l'invention pour gérer les erreurs de transmission d'un réseau ; 30 - la figure 4 représente schématiquement un exemple de l'algorithme mis en oeuvre par le PIC ; 2909241 13 - la figure 5 représente schématiquement un exemple de l'algorithme mis en oeuvre par le client ; - la figure 6 illustre un exemple de description de configuration ; 5 - la figure 7, comprenant les figures 7a et 7b, illustre un exemple d'instanciation de description de configuration pour une séquence multimédia donnée ; et, - la figure 8 montre l'évolution de données traitées selon l'invention. 10 L'invention repose en particulier sur la configuration dynamique du PIC pour la gestion des erreurs générées au cours du transfert des données sur des réseaux non fiables, et sur le transfert vers le client des données erronées au mieux partiellement corrigées. Selon l'invention, la description de configuration (Configuration 15 Map) transmise par le client au PIC préalablement à tout échange de données multimédia et éventuellement au cours de leur transfert, spécifie la politique de gestion d'erreur à appliquer aux données reçues erronées, les informations complémentaires ou "informations privées" qui devront être transmises au client avec les données au mieux partiellement 20 corrigées et éventuellement des informations sur le flux complémentaire dédié au transfert des données erronées vers le client. Après avoir détecté des erreurs parmi les données reçues, le module de gestion des erreurs du PIC sélectionne, en fonction des critères définis dans la description de configuration, les données 25 erronées pour lesquelles un ou plusieurs mécanismes de correction d'erreur doivent être mis en oeuvre. Les mécanismes de correction spécifiés sont mis en oeuvre sur les données sélectionnées afin d'obtenir la meilleure correction partielle pour les données qui ne pourront pas être intégralement corrigées. 30 Un module de création de paquets ( empaquétisation ) de données est en charge de créer de nouveaux paquets à partir des données erronées non réparables, au mieux partiellement corrigées, et 2909241 14 des informations privées correspondantes telles que définies dans la description de configuration. Un module de transmission est en charge de transmettre vers le client les paquets générés par le module de création de paquets à partir 5 des données erronées, dans un flux dédié n'appartenant pas à la séquence multimédia initiale et dont les caractéristiques peuvent être définies dans la description de configuration. Un tel mécanisme permet au PIC de gérer de façon sélective et dynamique les données reçues erronées, afin de fournir au client, dans un 10 flux dédié au transfert de données erronées, la meilleure correction partielle des données erronées n'ayant pu être intégralement corrigées. Les données et les informations associées transmises au client dans ce contexte permettent de limiter les impacts dus aux pertes de données sur le rendu final tout en capitalisant le travail de gestion 15 d'erreur effectué sur le PIC. Ainsi, la transmission de données selon l'invention peut être décomposée selon les grandes phases suivantes, 1/ le client, connecté à un serveur multimédia via des réseaux hétérogènes, filaires et/ou non filaires, échange avec ce serveur, 20 préalablement à tout échange de données multimédia, la description de la séquence multimédia que le client souhaite obtenir. 2/ le PIC, à travers lequel les données multimédia échangées entre le client et le serveur vont transiter, reçoit de la part du client, grâce à des techniques de configuration connues, une description de 25 configuration adaptée à la gestion des erreurs pour l'ensemble ou une partie seulement des flux de la séquence multimédia considérée. La description de configuration spécifie pour chacun des flux considérés la politique de gestion d'erreur à appliquer sur les données erronées reçues, la nature des informations complémentaires ou "informations privées" à 30 joindre aux éventuelles données irréparables retransmises au client, et éventuellement des informations sur le flux complémentaire dédié au transfert des données erronées vers le client. Cette description de 2909241 15 configuration est établie par le client de préférence à partir de la description de la séquence multimédia ainsi que d'éventuelles informations complémentaires notamment sur les services de gestion d'erreur disponibles sur le PIC et sur l'état et la nature des réseaux (bande 5 passante réservée, débit ou temps de latence). Le PIC peut recevoir par la suite, au cours du transfert de données multimédia,de nouvelles descriptions de configuration de la part du client, permettant d'adapter dynamiquement les traitements effectués pour la gestion d'erreur. 3/ lorsque le PIC reçoit du réseau des données multimédia liées 10 à la séquence considérée, sous forme de paquets de données, il applique les méthodes sélectionnées de détection d'erreur pour détecter les éventuelles erreurs. 4/ le PIC sélectionne les données erronées pour lesquelles un ou plusieurs mécanismes de correction d'erreurs, combinés ou non, 15 doivent être mis en oeuvre à partir des critères et des contraintes définis dans la description de configuration envoyée par le client. Pour chacune des données erronées sélectionnées, le PIC applique les mécanismes de correction d'erreurs spécifiés, selon la description de configuration, à partir des techniques connues par exemple de type ARQ, Hybrid ARQ ou 20 recombinaison de bits. 5/ le PIC crée de nouveaux paquets pour les données erronées pour lesquelles les mécanismes de correction d'erreur sélectionnés n'ont permis qu'une correction partielle, ainsi que pour les données erronées n'ayant pas été sélectionnées pour la phase de correction d'erreur, 25 contenant en plus des données erronées des informations complémentaires selon les critères définis par la description de configuration du PIC pour la gestion d'erreurs. 6/ le PIC transmet au client les nouveaux paquets générés dans un nouveau flux de données, appelé "extra flux", différent des flux 30 initialement définis dans la description de la séquence multimédia considérée, dédié à la transmission des données erronées, au mieux partiellement corrigées, pour l'ensemble des flux de données de la 2909241 16 séquence et dont les caractéristiques pourront être spécifiées par la configuration précédemment transmise par le client. L'utilisation de plusieurs extra flux pour le transfert des données erronées, un pour chaque flux considéré par exemple, peut aussi être envisagée. La 5 description de configuration doit alors prévoir de pouvoir décrire les caractéristiques de chacun de ces flux et notamment permettre de spécifier quelles sont les données qui doivent être transférées par un extra flux donné. La figure 1 présente schématiquement un exemple de 10 l'environnement 100 permettant la mise en oeuvre de l'invention dans lequel le client standard 105 et le client propriétaire 110 reçoivent des flux multimédia du serveur 115 à travers les réseaux hétérogènes 125, 130 et 135, filaires et non filaires. Chaque terminal client peut être, par exemple, un dispositif tel que celui décrit en référence à la figure 2 comprenant 15 avantageusement une mémoire de stockage volatile (cache), un serveur de fichiers et une interface homme-machine. Le PIC 120 correspond au point d'interconnexion des réseaux filaires et non filaires à travers lequel les données échangées transitent. Les données transférées depuis le serveur 115 vers les clients 20 105 et 110 transitent par un réseau sans fil 135, sensible aux erreurs générées notamment par d'éventuelles interférences 140, avant d'être relayées par le PIC 120 vers les clients 105 et 110 sur le réseau filaire 130, moins sensible aux erreurs. L'environnement présenté figure 1 n'est bien sur qu'un exemple 25 de système permettant la mise en oeuvre de l'invention. L'invention peut, par exemple, s'appliquer aussi si le réseau 130 est un réseau sans fil. Le PIC (120) peut par exemple être un point d'accès dans un réseau Wi-Fi reliant le réseau sans fil à un réseau filaire tout en reliant les stations sans fils entre elles (mode infrastructure). 30 La figure 2 représente la structure d'un appareil adapté à mettre en oeuvre au moins une partie de l'invention tel que le PIC ou le dispositif client. 2909241 17 Un appareil client mettant en oeuvre l'invention est par exemple un micro-ordinateur, une station de travail, un assistant numérique, un téléphone portable, un téléviseur ou un boîtier de décodage connecté à un dispositif d'affichage (set top box). 5 L'appareil 200 comporte un bus de communication 202 auquel sont reliés : une unité centrale de traitement 203 (microprocesseur) ; - une mémoire morte 204, pouvant comporter les programmes "Prog", "Prog1" et "Prog2" ; 10 - une mémoire vive 206 (mémoire cache), comportant des registres adaptés à l'enregistrement des variables et des paramètres créés et modifiés au cours de l'exécution des programmes précités ; et, - une interface de communication 218 reliée à un réseau de communication distribué 220, par exemple le réseau Ethernet, l'interface 15 étant apte à transmettre et à recevoir des données. Dans le cas d'un PIC, l'appareil comporte de préférence une deuxième interface de communication connectée a un second réseau, par exemple un réseau WiFi (ou 802.11n). Optionnellement, l'appareil 200 peut également disposer : 20 -d'un écran 208 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur, qui pourra interagir avec les programmes selon l'invention à l'aide d'un clavier 210 ou de tout autre moyen, tel qu'un dispositif de pointage, comme par exemple une souris 211, un crayon optique, un écran tactile ou une télécommande ; 25 - d'un disque dur 212 pouvant comporter les programmes "Prog", "Prog1" et "Prog2" précités, et des données traitées ou à traiter selon l'invention ; - d'un lecteur de disquette 214 adapté à recevoir une disquette 216 et à y lire ou à y écrire des données traitées ou à traiter selon 30 l'invention ; et, 2909241 18 - d'un lecteur de cartes mémoires (non représenté) adapté à recevoir une carte mémoire dans le format correspondant et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et 5 l'interopérabilité entre les différents éléments inclus dans l'appareil 200 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément de l'appareil 200 directement ou par l'intermédiaire d'un autre élément de l'appareil 200. 10 Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 212 ou en mémoire morte 204. Selon une variante, la disquette 216, peut contenir des données 15 ainsi que le code exécutable des programmes précités qui, une fois lu par l'appareil 200, sera stocké dans le disque dur 212. En seconde variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 220, via l'interface 218, pour être stocké de façon identique à celle décrite 20 précédemment. Les disquettes peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte mémoire. De manière générale, les disquettes peuvent être remplacées par des moyens de stockage d'information, lisibles par un 25 ordinateur ou par un microprocesseur, intégrés ou non à l'appareil, éventuellement amovibles, et adaptés à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. De manière plus générale, le ou les programmes pourront être 30 chargés dans un des moyens de stockage de l'appareil 200 avant d'être exécutés. 2909241 19 L'unité centrale 203 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 212 ou dans la mémoire morte 204 ou bien dans les autres éléments de stockage 5 précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 212 ou la mémoire morte 204, sont transférés dans la mémoire vive 206 (RAM) qui contiendra alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et 10 paramètres nécessaires à la mise en oeuvre de l'invention. Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application 15 spécifique (ASIC). La figure 3 illustre les étapes de l'invention évoquées précédemment, dans l'environnement 300 de mise en oeuvre de l'invention. Selon une première phase notée OO (correspondant à l'étape 501 20 de la figure 5), le client 305 et le serveur 310 échangent la description de la séquence multimédia que le client 305 souhaite obtenir en utilisant des protocoles tels que RTSP (Real Time Streaming Protocol) et SDP (Session Description Protocol). Une séquence peut contenir plusieurs flux, notamment audio et vidéo. La description et les échanges RTSP pour 25 l'établissement de la session permettent au client 305 de connaître les identifiants, les ports et l'encodage de chacun des flux. Un exemple d'un tel échange est décrit en référence à la figure 7a, en particulier par la référence 700. Dans une deuxième phase notée OO , le client 305 définit et 30 transmet une description de configuration (Configuration Map) pour la gestion des erreurs au point d'interconnexion 315 du réseau, qui fera 2909241 20 transiter les paquets de données des flux multimédia de la séquence considérée. Un exemple de mise en oeuvre des étapes de définition et de transmission de la description de configuration par le client est présenté à 5 la figure 5, en particulier par les étapes 502 et 503. Dans une troisième phase notée OO , le PIC 315 reçoit les paquets de données multimédia liées à la séquence considérée (correspondant à l'étape 402 de la figure 4) et détecte d'éventuelles erreurs, à partir des mécanismes de détection d'erreur connus (correspondant à l'étape 403 de 10 la figure 4). Par exemple, le PIC 315 reçoit le paquet 320' correspondant au paquet 320 émis par le serveur 310, le paquet 320' comprenant les erreurs 325. Les étapes 402 et 403 de l'algorithme du PIC décrites en référence à la figure 4 présentent un exemple de gestion des données reçues. Selon une quatrième phase notée , le PIC 315 sélectionne les 15 paquets de données erronées pour lesquels un ou plusieurs mécanismes de correction d'erreur doivent être mis en oeuvre, ainsi que le type de mécanismes à appliquer (par exemple ARQ ou Hybrid ARQ). Un exemple de mise en oeuvre de ce processus est présenté à la figure 4, aux étapes 404 et 405. A l'issue de cette sélection, le PIC 315 met en oeuvre le ou les 20 mécanismes de correction d'erreurs appropriés (correspondant à l'étape 406 de la figure 4), conformément aux indications de la description de configuration précédemment identifiées, pour les paquets sélectionnés. Les paquets non sélectionnés pour la mise oeuvre de mécanismes de correction d'erreur, sont par ailleurs conservés pour être transmis tel 25 quels au client 305 dans le flux dédié au transfert de données erronées conformément aux étapes 408 et 409 décrites à la figure 4. Selon une cinquième phase notée CO , le PIC 315 crée de nouveaux paquets de données (correspondant à l'étape 408 de la figure 4) pour toutes données erronées n'ayant pu être intégralement corrigées et 30 celles n'ayant pas été sélectionnées pour la mise en oeuvre de mécanismes de correction d'erreur, dans lesquels sont ajoutées les informations privées, conformément à la description de configuration 2909241 21 (voir la référence 730 de la figure 7b). Un exemple de cette préparation est décrit en référence à la figure 4, en particulier aux étapes 408 et 409. Par exemple, le PIC 315 crée le paquet de données 320" à partir des données reçues dans le paquet 320', correspondant au paquet 320 émis par le 5 serveur 310, dont une partie des erreurs détectées 325 a été corrigée. Enfin dans une sixième phase notée , le PIC 315 transmet les paquets créés au client 305 dans un flux complémentaire (extra flux) dédié au transfert des données erronées (correspondant à l'étape 409 de la figure 4 pour le PIC et aux étapes 504 à 509 de la figure 5 pour le client), 10 indépendant des flux de données originaux et initialisé selon les spécifications de la description de configuration (correspondant à l'étape 716 de la figure 7b). La figure 4 décrit un exemple d'algorithme mis en oeuvre par le PIC pour gérer les données qui transitent à travers lui. 15 Les étapes identifiées dans des rectangles ou losanges pointillés sont des étapes mises en oeuvre dans les systèmes selon l'art antérieur, les nouvelles étapes étant identifiées par des rectangles ou losanges ayant des lignes continues. Ce même principe est également utilisé sur la figure 5. 20 Préalablement à tout échange de données multimédia entre le client et le serveur, le PIC reçoit du client une description de configuration (étape 401) selon un protocole propriétaire sur TCP (Transmission Control Protocol), éventuellement de type SOAP (Simple Object Access Protocol). Il convient de noter qu'un PIC peut gérer plusieurs descriptions 25 de configuration, notamment une par client. Un PIC peut également mémoriser plusieurs descriptions de configuration pour un même client, qui pourra alors simplement préciser dynamiquement la description de configuration valide à un instant donné parmi celles déjà transmises et gérées ou transmettre une nouvelle description de configuration. Dans un 30 souci de clarté, la suite de la description ne considère qu'une seule description de configuration par client propriétaire, la gestion de 2909241 22 plusieurs descriptions de configuration étant évidente pour l'homme du métier. Le PIC reçoit de préférence les données encapsulées dans des paquets RTP (Real-time Transport Protocol) sur UDP (User Datagram 5 Protocol), dont les entêtes renferment différentes informations sur l'identification du flux et du paquet, en particulier l'adresses IP (Internet Protocol) et les ports UDP des client et serveur pour l'en-tête UDP, l'identifiant du flux (Synchronization Source identifier) et le numéro de séquence du paquet pour l'entête RTP. 10 Pour chacun des paquets reçus (étape 402), le PIC cherche à détecter la présence éventuelle d'erreur (étape 403) à partir de mécanismes de détection connus et sélectionnés permettant notamment l'utilisation des FECs de type Reed-Solomon, présents dans les paquets transmis, par un décodeur à décision quantifiée capable d'identifier la 15 localisation estimée de l'erreur par définition d'un indice de confiance sur les bits de données. De tels mécanismes sont décrits en particulier dans l'article intitulé "Algebraic soft-decision decoding of Reed-Solomon codes" de R. Koetter et A. Vardy (IEE Trans. Inf. Theory û Volume 49; n 11, pp. 2809-2825, Nov. 2003), dans l'article intitulé "Performance enhancements for 20 algebraic soft-decision decoding of Reed-Solomon codes" de M. El-Khamy, R. J. McEliece et J. Harel (Proc. DIMACS, AMS-DIMACS û Volume on Algebraic Coding Theory and Information Theory) et dans l'article intitulé "Iterative algebraic soft-decision decoding of Reed-Solomon codes" de M. El-Khamy et R. J. McEliece (Proc. Int. Symp. Information Theroy and Its 25 Applications, pp. 1456 û 1461, Parma, Italy - Mar 2004). D'autres mécanismes de détection et de correction d'erreur tels que les CRC (Cyclic Redundancy Check), les codes Turbo, LDPC (Low Density Parity Check) ou "repeat-accumulate" peuvent aussi être utilisés. Lorsqu'aucune erreur n'est détectée, le PIC retransmet 30 normalement le paquet dans son flux d'origine au client final (étape 413). Lorsqu'une erreur est détectée, le PIC peut mettre en oeuvre un mécanisme d'identification de l'erreur, éventuellement basé sur le 2909241 23 mécanisme d'évitement de la couche MAC (Media Access Control) de type DCF (Distributed Coordination Function), afin de déterminer l'origine de cette erreur (collision ou perte). Cette phase, facultative, peut reposer sur d'autres mécanismes. 5 Les traitements appliqués ensuite à la donnée erronée sont liés à différents critères de sélection définis dans la description de configuration, portant sur l'identification du flux d'origine de la donnée, la nature de l'erreur et éventuellement le type de la donnée en elle-même, tel que décrit en référence à la figure 6. 10 Le PIC détermine tout d'abord si le paquet répond aux critères de sélection (étape 404) définis dans la description de configuration en fonction des informations recueillies par l'analyse syntaxique (parsing) des entêtes RTP et UDP du paquet, en particulier l'adresse du serveur, le port UDP du destinataire et l'identifiant SSRC, sur l'identité du flux. Pour 15 cela, le PIC compare ces informations aux éléments de la liste des flux considérés de la description de configuration (référence 611 de la figure 6). II convient de noter que tant qu'aucune donnée n'a été échangée avec le client, celui-ci peut ignorer le SSRC du flux considéré et donc peut 20 ne pas être en mesure de renseigner entièrement le couple d'identifiant de la description de configuration pour ce flux (référence 611 de la figure 6). L'identification du flux est alors basée sur les informations fournies par l'en-tête UDP : l'adresse du serveur ayant transmis ce paquet et le port UDP du destinataire. Dans ce contexte, l'indentification des paquets reçus 25 reste cependant imprécise dans la mesure où les informations disponibles ne permettent pas de différencier deux flux transmis par le serveur vers un même port UDP. II est donc préférable d'identifier un flux à partir de son identifiant SSRC lorsque l'information est disponible, ce qui doit être possible dès lors que la configuration est établie après que la 30 session RTSP ait été initialisée via l'envoi de messages "SETUP" (correspondant à l'étape 706 de la figure 7a) ou mise à jour par le client 2909241 24 après qu'il ait été informé des SSRCs des flux par la réception de messages RTCP de type SR (Sender Report) par exemple. Si le flux n'apparaît pas dans cette liste (par exemple la référence 707 de la figure 7a illustrant un SDP comprend un flux audio 5 français 707-2, audio.fr, absent de la liste des flux considérés dans la description de configuration 713 de la figure 7b), la donnée ne répond pas aux critères essentiels de sélection définis par la description de configuration, le PIC applique alors le traitement d'erreur par défaut, par exemple de type ARQ (étape 410), défini hors du contexte de cette 10 invention. A l'issue de ce traitement, un test est effectué pour déterminer si les données du paquet sont intégralement corrigées (étape 411). Tout paquet de données non intégralement corrigées est ignoré (étape 412) tandis que les paquets de données intégralement corrigées seront retransmis corrigés au client dans le flux d'origine (étape 413). 15 A l'issue de l'étape 404 le PIC sélectionne les données erronées issues des flux considérés selon la description de configuration et il détermine alors le ou les mécanismes de correction d'erreur à mettre en oeuvre (étape 405), à partir des informations suivantes : - l'origine de l'erreur recueillie au cours de l'étape précédente, 20 que le PIC compare à la liste des types d'erreur gérées, éventuellement spécifiées dans la description de configuration (référence 612 de la figure 6). Si le type d'erreur détectée n'est pas considéré, la donnée erronée ne correspond pas aux critères de sélection et aucun mécanisme de correction d'erreur ne doit être mis en oeuvre pour tenter de la corriger. 25 - l'identité du flux d'origine que le PIC utilise pour vérifier l'existence éventuelle dans la description de configuration d'un profil spécifique à ce flux (référence 620 de la figure 6), identifié par le couple identifiant . - si un tel profil existe et définit des mécanismes de 30 correction d'erreur spécifiques (référence 623 de la figure 6, rubrique "Mécanismes de gestion d'erreur à mettre en oeuvre"), éventuellement restrictifs par rapport aux mécanismes définis dans 2909241 25 les informations générales (référence 613 de la figure 6), ce sont ces mécanismes qui doivent être mis en oeuvre dans leur ordre d'apparition dans la liste. - si au contraire aucun profil n'est défini pour ce flux, ce 5 sont les mécanismes définis dans les informations générales (référence 613 de la figure 6) qui doivent être appliqués selon leur ordre d'apparition dans cette liste. Ces informations ainsi que d'autres informations complémentaires, notamment sur le type de données contenues (par 10 exemple le type d'image I, P ou B pour une vidéo, la nature de la couche (base ou améliorée (enhanced)) et l'importance de la NAL (Network Abstraction Layer) : informations disponibles directement dans les paquets notamment dans les bits NRI de l'entête des NALU pour le cas de vidéo H264 ou SVC), peuvent être exploitées à différents niveaux de la 15 description de configuration de façon à préciser les critères de sélection et/ou les mécanismes à mettre en oeuvre en fonction des spécifications de la configuration. La nature des erreurs considérées peut être précisée au niveau du profil d'un flux (référence 722 de la figure 7b), pour ne considérer, par exemple, que les erreurs dues aux collisions. 20 Si la donnée répond aux critères de sélection définis par la description de configuration, le PIC met en oeuvre le ou les mécanismes de correction d'erreur appropriés (étape 406), conformément aux indications de la de la description de configuration. A l'issue des étapes 405 et 406, un test est effectué pour 25 déterminer si la donnée considérée a été intégralement corrigée ou non (étape 407), notamment à partir des FECs éventuellement présents dans les paquets reçus pour cette donnée. Si la donnée est intégralement corrigée au cours du processus, elle est alors retransmise normalement au client dans son flux d'origine 30 (étape 413). Si au contraire la donnée est au mieux partiellement corrigée au cours du processus ou n'a pas été sélectionnée pour la mise en oeuvre de 2909241 26 mécanismes de correction d'erreur, un nouveau paquet à destination du client est créé (étape 408) pour cette donnée. Pour chaque paquet de données erronées créé, des informations privées sont associées aux données, conformément à la 5 description de configuration. Ces informations privées peuvent par exemple comprendre l'identifiant du flux dont est issu la donnée (référence 811 de la figure 8), sa position relative dans ce flux (référence 812 de la figure 8) et le FEC d'origine s'il était présent dans le paquet reçu (référence 831 de la figure 8). Les informations privées sont de préférence 10 protégées par un code FEC de type Reed-Solomon. Pour cela le PIC détermine, pour chaque donnée erronée considérée, les informations privées à recueillir pour la construction du paquet à transmettre à partir de la description de configuration (références 630 et 730 des figures 6 et 7b). 15 Le PIC réunit ensuite les informations privées requises, à partir des informations recueillies aux cours des précédentes étapes, l'identification des données erronées par l'identifiant SSRC de son flux d'origine et son numéro de séquence dans ce flux (références 811 et 812 de la figure 8). 20 - les informations d'origine du point de vue de la gestion d'erreur, c'est-à-dire le FEC d'origine (référence 831 de la figure 8). - la localisation de l'erreur irréparable (référence 822 de la figure 8), recueillie par le décodeur à décision quantifiée (localisation de la zone erronée et son étendue par une indication 25 des zones de moindre confiance). - la localisation de la correction partielle apportée (références 823 et 824 de la figure 8), s'il y en a eu une (localisation de la zone corrigée et identification des mécanismes par ordre d'application ayant permis d'obtenir cette correction). 30 Le PIC crée alors, conformément aux indications de la description de configuration (référence 630 de la figure 6), un nouveau paquet RTP à partir de ces informations complémentaires, des données 2909241 27 erronées au mieux partiellement corrigées et d'un nouveau FEC de type Reed-Solomon calculé sur ces données et ces informations. Le protocole utilisé pour l'extra flux peut être différent de celui utilisé pour le flux de données. Les protocoles TCP et UDP peuvent 5 notamment être utilisés pour ce flux de données. De même, d'autres techniques de gestion d'erreur peuvent être appliquées sur ce nouveau paquet, dont les données utiles appelées payload peuvent être intégralement ou partiellement considérées (les données seules, les informations seules ou un segment de données). 10 En utilisant le même protocole que le flux d'origine (RTP sur UDP), une nouvelle source peut être définie dans la session pour l'extra flux, permettant de le distinguer des flux initiaux. Le PIC transmet ensuite ces nouveaux paquets dans un flux dédié complémentaire, l'extra flux dédié au transfert des données 15 erronées, indépendant des flux de données originaux (étape 409). Pour cela, si aucune des données irréparables n'a encore été transférée au client ou si les indications de la description de configuration pour l'extra flux (référence 614 de la figure 6) ont été modifiées par la dernière mise à jour de la description de configuration, le PIC initialise tout d'abord ce 20 nouveau flux conformément aux consignes de la description de configuration, ferme le précédent extra flux s'il en existait un, puis transmet les nouveaux paquets précédemment créés pour le transfert des données erronées vers le client. Dans un contexte où le protocole utilisé pour l'extra flux est 25 identique à celui des flux initiaux (RTP sur UDP), l'initialisation de ce flux peut consister à créer la nouvelle source et informer les récepteurs qu'une nouvelle source participe à la session en envoyant un paquet de type RTCP SR au client. A l'issue de ce processus, les paquets intégralement corrigés 30 sont donc transmis au client final (étape 413) dans le flux de données d'origine et les nouveaux paquets générés à l'issue du processus de correction d'erreur pour les données erronées au mieux partiellement 2909241 28 corrigées sont transmis dans le flux de données dédié au transfert de données erronées (étape 409). De nombreuses variantes de cet algorithme peuvent être utilisées. 5 Ainsi, les paquets erronés issus de flux pour lesquels aucune politique de gestion d'erreur n'a été définie bien que considérés à d'autres niveaux dans la description de configuration, peuvent être ignorés au lieu d'être retransmis au client dans le flux dédié au transfert des données erronées. De même, seuls les paquets pour lesquels au moins une 10 correction partielle a été obtenue peuvent être retransmis au client. Par ailleurs, dans un contexte où le PIC dispose des moyens nécessaires pour établir des statistiques, il peut être souhaitable qu'il établisse des statistiques sur les données erronées, les corrections apportées et les résultats obtenus afin de les transmettre au client, dans 15 des paquets spécifiques de l'extra flux, lui permettant ainsi de disposer de ces informations pour mettre à jour la description de configuration du PIC pour la gestion d'erreur. La figure 5 illustre un exemple d'algorithme utilisé par un client pour gérer les données transférées depuis le serveur via les points 20 d'interconnexion réseau. Avant tout transfert de données multimédia, le client reçoit du serveur la description de la séquence multimédia qu'il souhaite transférer (étape 501), en utilisant des protocoles de type SDP et RTSP tel que décrit en référence à la figure 7a. La configuration est élaborée une foisla 25 session initialisée par l'envoi de messages "SETUP" pour les flux souhaités de la séquence multimédia, de sorte que le client dispose des identifiants SSRC pour ces flux (références 708 et 709 de la figure 7a). Le client élabore ensuite une description de configuration (étape 502) pour le PIC à travers lequel les données vont transiter au 30 cours de leur transfert vers le client. La description de configuration élaborée peut couvrir l'ensemble ou une partie seulement des flux décrits dans la description de séquence (voir par exemple les références 707 et 2909241 29 713 des figures 7a et 7b où trois flux sont définis dans la description SDP mais où deux seulement sont pris en compte dans la description de configuration). Le client élabore la description de configuration de préférence à 5 partir des données suivantes, - la description de la séquence multimédia qu'il souhaite transférer et des échanges RTSP pour la création de la session, précisant les identifiants et caractéristiques des flux de la séquence multimédia, - des informations sur les services de gestion d'erreur 10 disponibles sur le PIC, définis sur le client par configuration ou découvert par des mécanismes de découverte des services, tels que UPnP (Universal Plug and Play) et SSDP (Simple Service Discovery Protocol), - des informations complémentaires sur l'état des réseaux traversés, par exemple la bande passante réservée, le débit, les temps de 15 latence et les taux d'erreur observés sur le réseau pour ces flux, fournies par une configuration statique ou par des données calculées sur les messages précédemment échangés, - des informations connues du client, par exemple le type d'application du client et sa latence acceptable. Dans le cas d'une vidéo 20 conférence notamment, la latence est très faible et donc les mécanismes de type ARQ doivent être exclus. Au contraire pour une application enregistrant le flux reçu, la qualité doit être maximale même si la latence est importante, le nombre de retransmissions peut alors être augmenté. La description de configuration obtenue est ensuite transmise 25 au PIC (étape 503) en utilisant un protocole propriétaire, par exemple un message SOAP sur TCP. Lorsque les échanges multimédia sont initiés, le client détermine pour chaque paquet de données reçu (étape 504) sa provenance (étape 505), notamment en fonction du port sur lequel il a été 30 reçu, de l'identifiant SSRC du flux et éventuellement du protocole utilisé (par exemple si le protocole utilisé pour l'extra flux diffère de celui des flux initiaux, voir aussi la figure 7a). Dans un contexte où les données 2909241 30 multimédia sont transmises dans leur flux d'origine via des paquets RTP sur UDP, le client effectue une identification précise des flux en effectuant une analyse syntaxique (parsing) de l'en-tête RTP, pour en extraire l'identifiant SSRC du flux. 5 Si le paquet reçu est issu des flux multimédia d'origine, il est alors envoyé aux modules de gestion des données (étape 508) avant d'être transmis aux décodeurs (étape 509). Dans le cas contraire, le paquet contient des données erronées qui nécessitent une préparation avant de pouvoir être transmises aux décodeurs. 10 Si le client dispose des moyens nécessaires pour le traiter, notamment de ressources locales disponibles et de la configuration nécessaire, le paquet est transmis à un module propriétaire (étape 507) capable d'exploiter l'en-tête et les données, notamment pour vérifier l'intégrité du paquet à partir du FEC fourni (référence 800 de la figure 8). Il 15 peut également identifier le flux d'origine (référence 811 de la figure 8) et déterminer s'il est pertinent de transmettre ces données erronées au décodeur approprié, en s'assurant par exemple qu'il ne soit pas déjà saturé ou trop simple pour compenser cette erreur. Avant de transmettre les données erronées aux modules suivants de traitement des données, le 20 module propriétaire est également en charge de préparer les données, c'est-à-dire d'isoler les informations privées qui les précèdent dans la payload du paquet, et les informations complémentaires que le paquet contient (étape 508), à destination des décodeurs en fonction de leurs caractéristiques (étape 509), de sorte qu'ils puissent décider quels 25 traitements de dissimulation d'erreurs (Error Concealment) sont les plus adéquates pour palier à cette erreur. Un autre exemple de traitement de données peut consister en la mise en oeuvre d'un deuxième niveau de FEC, inter paquets, en utilisant pour corriger certaines erreurs plusieurs paquets reçus, de FEC complémentaires envoyés par le serveur et de 30 données partiellement corrigées. Si le client ne dispose pas des moyens nécessaires pour traiter les paquets contenant des données erronées, ces paquets sont ignorés. 2909241 31 A l'issue de l'étape 509 le client est de nouveau disponible pour traiter de nouvelles données ou définir une nouvelle description de configuration pour le PIC. D'autres algorithmes peuvent être utilisés notamment pour 5 inclure une mise à jour régulière de la configuration du PIC en fonction de leurs résultats, c'est-à-dire par exemple de la qualité des processus de correction d'erreur, des caractéristiques du réseau et du changement de débit. La figure 6 représente un exemple de structure de description 10 de configuration (ou Configuration Map). Cette structure permet de définir l'ensemble des informations nécessaires à la configuration d'un PIC pour la gestion des erreurs. La description de configuration a de préférence une représentation hiérarchique pouvant être écrite, par exemple, selon le 15 format XML (Extensible Markup Language). Une première partie 610 contient les informations générales qui comprennent notamment, - l'identification 611 des flux considérés dans cette description de configuration permettant de ne sélectionner, pour d'éventuels 20 traitements de gestion d'erreur, que les données de ces flux (étapes et 404 des figure 3 et 4), à partir d'informations sur : - le serveur initialisant leur transfert vers le client (adresse IP), - les flux multimédia eux-mêmes c'est-à-dire une liste de 25 couples d'identifiants séparés de préférence par des points virgules, où le couple d'identifiants est composé d'un SSRC présent dans les en-têtes des paquets RTP pour identifier de manière unique le flux et d'un numéro de port UDP, présent dans les en-têtes de paquet UDP, par lequel le client reçoit les données 30 de ce flux. Le SSRC peut-être absent de ce couple d'identifiants, l'identification du flux reposera alors sur le port de destination et l'adresse IP du serveur. Deux flux transmis par le même serveur sur 2909241 32 le même port UDP du même client peuvent donc, en l'absence de SSRC, être considérés comme un seul flux. Il est donc préférable que le SSRC d'un flux soit présent dans le couple identifiant. Si le flux d'origine d'une donnée reçue erronée par le PIC n'apparaît pas 5 dans cette liste, bien qu'émise par le serveur désigné dans la description de configuration (par exemple le flux audio français 707- 2 de la figure 7a, audio.fr, est absent de la liste 713 sur la figure 7b), la donnée ne pourra être sélectionnée pour la mise en oeuvre de mécanismes de correction d'erreur dans le cadre de cette invention. 10 - les types d'erreurs 612 pris en charge, désignés par des acronymes dans une liste où chaque item est séparé par un point virgule. Si cette liste 612 contient le mot clé "Ali Types", un mot clé équivalent ou si elle est absente de la description de configuration, cela signifie que tous les types d'erreur sont couverts par le mécanisme sauf contre- 15 indication au niveau des profils spécifiques aux flux. Dans le cas contraire, le PIC doit, pour sélectionner les données pour lesquelles des mécanismes de correction d'erreur pourront être mis en oeuvre (étape 405 de la figure 4), déterminer si l'acronyme utilisé pour le type d'erreur détectée apparaît dans la liste. Si une donnée a été reçue erronée par le 20 PIC du fait d'interférences sur le réseau sans fil, et que la configuration ne couvre que les erreurs dues à de la congestion, aucun mécanisme de correction d'erreur n'est appliqué et la donnée est transmise telle quelle au client via le flux dédié aux données erronées (étapes 408 et 409 de la figure 4). 25 - les mécanismes de correction d'erreur 613 à mettre en oeuvre par défaut pour appliquer cette configuration. Cette liste spécifie, selon un format privé basé sur l'utilisation d'acronymes, un, plusieurs ou une combinaison de mécanismes ainsi que d'éventuels paramètres de fonctionnement (par exemple le nombre de tentatives avant abandon pour 30 I'ARQ) qui doivent être appliqués, selon leur ordre d'apparition dans la liste, sur les données erronées sélectionnées. Les acronymes représentant les mécanismes à mettre en oeuvre sont de préférence 2909241 33 séparés par des points virgules. Les paramètres de ces mécanismes peuvent être spécifiés selon un ordre prédéfini, précédés par deux points (:) et séparés par des virgules. Par exemple, l'expression "Recombinaison de bits : 5, 30" signifie qu'au plus 5 tentatives de types ARQ doivent être 5 mises en oeuvre avant de tenter une recombinaison de bits sur l'ensemble des données reçues pour ce paquet et que seule une combinaison apportant au moins 30% de correction par rapport à l'erreur d'origine peut être conservée. Pour une donnée erronée issue d'un flux considéré par la description de configuration et pour lequel aucun profil spécifique n'est 10 défini dans la description de configuration, si l'erreur a pour origine une raison couverte par la description de configuration, le PIC applique les mécanismes de correction d'erreur tels que spécifiés dans cette liste suivant leur ordre d'apparition (référence 715 de la figure 7b) jusqu'à ce que la donnée ait été intégralement corrigée ou que tous les mécanismes 15 et combinaisons définis n'aient été essayés. - le flux de retransmission des données erronées 614, ou extra flux, afin de pouvoir l'initialiser pour le transfert des données erronées vers le client (étape 409 de la figure 4). Les informations sont fournies selon un format privé reposant sur l'utilisation d'acronymes, elles peuvent 20 ainsi être définies dans un ordre quelconque, voire même pour certaines être omises (par exemple l'"identifiant du flux" pour un protocole de type UDP). La rubrique "identifiant du flux" permet de préciser l'identifiant SSRC du flux, défini par l'application. La rubrique "client" précise les coordonnées du client (son adresse IP et son port) où le PIC devra 25 transmettre les paquets de données erronées. Enfin, la rubrique "protocole" spécifie le protocole réseau à utiliser pour transmettre les données erronées. D'autres informations peuvent être précisées à ce niveau, notamment le moyen de protection à appliquer (de type FEC, CRC, codes 30 turbo ou repeat-accumulate) sur les informations privées et/ou les données erronées pour leur transfert dans l'extra flux ainsi que sa portée éventuelle (l'ensemble des données erronées, la zone corrigée seule ou 2909241 34 les informations privées seules). Une politique de multiplexage des paquets de données peut également être précisée, permettant de limiter le surdébit (overhead) généré par les informations privées notamment si cette politique permet de regrouper plusieurs paquets d'un même flux 5 arrivés erronés dans un espace de temps donné. Ces informations permettent au PIC d'identifier les flux pour lesquels il doit mettre en oeuvre un traitement spécifique de gestion d'erreur et d'initialiser l'extra flux pour le transfert des données erronées qui n'auront pu être corrigées. 10 Il convient de noter que dans cet exemple un seul extra flux peut être créé. II est possible d'étendre le système pour supporter plusieurs extra flux, par exemple un pour chaque flux de données considéré. Une seconde partie 620 est consacrée à la description de profils 15 de gestion d'erreur. Chaque profil définit pour un ou plusieurs flux, parmi ceux identifiés dans les informations générales en 611, la politique de gestion d'erreur à appliquer sur les paquets erronés qui en sont issus. Selon cet exemple, il ne peut être défini qu'un seul profil par flux. Ces profils sont organisés comme suit dans la description de 20 configuration : - le nombre de profils définis est précisé afin de faciliter les recherches pour sélectionner les données et déterminer les mécanismes de correction d'erreur à appliquer (étape 405 de la figure 4). - pour chaque profil, sont définies des informations générales 25 permettant, - d'identifier les flux concernés par ce profil, parmi ceux identifiés dans les informations générales de la description, selon une liste de couples d'identifiants 621 organisée selon le même format que la liste des flux considérés en 611. 30 - d'identifier les types d'erreur considérés à partir de leur origine selon une liste de types d'erreur 622 organisée selon le 2909241 35 même format que la liste des erreurs supportées de façon générale en 612. - de définir les mécanismes et leurs caractéristiques de fonctionnement éventuelles à mettre en oeuvre pour les flux 5 désignés, selon une liste de mécanismes 623 organisée selon le format défini pour la liste des mécanismes à mettre en oeuvre en 613. Cette liste peut être restrictive et faire appel à moins de mécanismes que celle précédemment définie dans les informations générales, simplement redéfinir les paramètres spécifiques des 10 mécanismes utilisés ou encore préciser un ordre de mise en oeuvre ou des combinaisons différentes. Elle peut notamment être vide, précisant ainsi que pour les données erronées issues des flux désignés en 621 aucun traitement de correction d'erreur ne doit être appliqué. Les données sont alors retransmises telles quelles avec 15 les informations recueillies sur l'erreur dans l'extra flux au client (étape 408 de la figure 4). Les mécanismes ou combinaisons de mécanismes définis pour un profil donné sont exécutés en lieu et place des mécanismes définis dans les informations générales 613 pour le traitement des données 20 erronées répondant aux critères de sélection définis par les éléments 611, 612, 621 et 622. Les listes précisant les types d'erreur couverts ou les mécanismes de correction d'erreur à appliquer peuvent être absentes du profil, de telle sorte que si l'une d'entre elle est omise du profil l'autre doit 25 être spécifiée. Ces profils peuvent également être précisés par un ou plusieurs sous-profils définissant les politiques de gestion d'erreur spécifiques pour des types définis de paquets de données issus de flux considérés dans le profil parent. Les critères de sélection peuvent notamment 30 prendre en compte la nature du paquet et\ou sa priorité afin de préciser les mécanismes à mettre en oeuvre dans certains cas particuliers. Pour la vidéo, cela permet notamment de différencier le traitement appliqué aux 2909241 36 images I de celui appliqué aux images P ou B, ou les niveaux d'importance des NALUs (Network Adaptation Level Units). Il est par exemple possible de protéger au maximum les données les plus importantes (images I ou NALUs les plus importantes) et d'abandonner 5 les moins importantes. Cette seconde partie permet de définir différents profils de gestion d'erreur pour l'ensemble ou pour une partie des flux considérés dans la configuration. Une troisième partie 630 permet de définir la nature des 10 informations qui doivent être transmises en tant qu'informations privées complémentaires associées aux données erronées, n'ayant pu être intégralement corrigées au cours du processus (étapes 405 à 407 de la figure 4) dans les paquets de l'extra flux. Les informations requises peuvent considérer différents aspects du processus et des données : 15 - l'identité du flux et du paquet d'origine (références 731, 810, 811 et 812 des figures 7b et 8). - des informations concernant l'erreur : les moyens de détection (références 732 et 831 des figures 7b et 8) utilisés par le PIC au cours du processus (étape 403 20 de la figure 4). -la localisation et la taille de l'erreur, telle qu'elle a été détectée à la réception du paquet par le PIC (références 733 et 822 des figures 7b et 8). - la localisation et la taille de la correction partielle 25 (référence 823 de la figure 8) si une correction partielle a pu être obtenue et les moyens mis en oeuvre pour obtenir ce résultat (références 734 et 824 des figures 7b et 8). Des acronymes sont de préférence utilisés pour désigner les informations à recueillir, dont "identifiant du flux" pour désigner 30 l'identifiant SSRC du flux d'origine de la donnée considérée ou "FEC Original" pour la valeur du FEC éventuellement présent dans le paquet d'origine (référence 730 de la figure 7b). 2909241 37 Les tailles (en nombres d'octets) de chacun des champs constituant les informations privées du nouveau paquet sont précisées, quand elles sont fixes et connues, pour chacune des informations requises de préférence selon un format propriétaire (référence 730 de la 5 figure 7b), identique à celui utilisé pour les paramètres spécifiques des mécanismes de correction d'erreur 613. Cette structure de description de configuration ne constitue bien entendu qu'un exemple. D'autres informations sélectives et déterminantes, notamment celles recueillies au cours des étapes de 10 sélection, concernant éventuellement l'origine de l'erreur (par exemple les interférences et la congestion), sa nature ou son étendue, la nature du flux d'origine (par exemple le type de données multimédia et la couche de base ou améliorée, enhanced layer) ou de la donnée erronée (Image 1, B ou P), peuvent être considérées pour définir profils et sous profils de la 15 description de configuration. En outre les critères de sélection peuvent être organisés différemment et permettre par exemple de définir la nature des informations privées dans les profils ou pour chaque flux considéré. La figure 7, comprenant les figures 7a et 7b, présente une 20 séquence d'échanges de messages entre le client et le serveur pour l'obtention de la description de la séquence multimédia souhaitée au format SDP (figure 7a), ainsi qu'un exemple d'instanciation de la description de configuration présentée sur la figure 6 pour cette séquence multimédia (figure 7b). 25 Le client sollicite le serveur dans une session RTSP, préalablement à tout échange de données multimédia, pour obtenir la description de la séquence multimédia qu'il souhaite obtenir (référence O de la figure 3) et établir une session sur le flux désiré. Ces échanges sont représentés en 700. 30 Le client envoie une première requête "DESCRIBE" (étape 701) au serveur pour obtenir la description de la séquence au format SDP. La 2909241 38 réponse du serveur (étape 702) contient la description de la séquence multimédia 707 au format SDP. Dans cet exemple, la séquence multimédia est constituée de trois flux, un flux vidéo et deux flux audio. Les informations spécifiques à 5 chacun des médias précisent certaines de leurs caractéristiques essentielles. Parmi celles-ci, le port UDP, réservé pour ce flux chez le client, constitue une information intéressante pour l'identification du flux en l'absence d'un identifiant de type SSRC. Lorsque la description de la séquence est prise en compte, le 10 client envoie une requête "SETUP" (étape 703) pour négocier l'allocation des ressources nécessaires pour le flux audio anglais (audio.en) et initialiser la session. La réponse du serveur (étape 704), en plus de reprendre et valider les informations sur les port et protocole utilisés pour ce flux, précise son identifiant SSRC 708, utilisé par la suite au cours des 15 échanges de données par RTP. Le client poursuit l'initialisation de la session par une nouvelle requête "SETUP" (étape 705) pour le flux vidéo de la séquence précédemment décrite. La réponse du serveur (étape 706), précise elle aussi les informations de transport et l'identifiant SSRC 709 relatifs à ce 20 flux. L'identifiant SSRC jouant un rôle important pour l'identification des données reçues erronées et la mise en oeuvre sélective des mécanismes de correction d'erreur appropriés (étapes 404 et 405 de la figure 4 et références 611 et 621 de la figure 6), il est avantageux 25 d'instancier la description de configuration selon le modèle (template) présenté sur la figure 6 lorsque la session RTSP est initialisée et que les identifiants SSRC sont connus. En l'absence des identifiants SSRC l'identification des flux reposera sur l'utilisation des ports UDP réservés sur le client pour ces flux. 30 Une instanciation "Cl" du modèle de description de configuration présenté figure 6 pour la session multimédia décrite en 707 est présentée en 750. 2909241 39 Une première partie 710 concernant les informations générales est composée des informations suivantes, - l'identification des flux considérés dans cette configuration 711 (référence 611 de la figure 6) à partir des informations suivantes, 5 - l'adresse IP du serveur de flux 712 "172.16.2.93 " (cette information est précisée dans la description SDP 707, référence 707-1). - la Liste des identifiants des flux considérés 713, parmi ceux de la séquence multimédia présentée en 707. Seuls deux 10 couples d'identifiants apparaissent dans cette liste, chacun précise le SSRC du flux considéré et le port UDP réservé sur le client pour ce flux (ces éléments sont extraits des réponses correspondant aux étapes 704 et 706) pour faciliter l'identification de ces données par le PIC. Le flux audio français 707-2 (audio.fr) décrit dans la 15 description SDP 707 n'est donc pas considéré dans la description de configuration. Si le client décide par la suite d'initialiser également ce flux dans la session RTSP, les données de ce flux reçues erronées par le PIC ne seront pas sélectionnées (étape 404 de la figure 4) pour la mise en oeuvre des mécanismes de correction 20 décrit ici (715 ou 723), à moins que la configuration ne soit alors mise à jour de façon adéquate. - les types d'erreurs pris en charge 714. La liste contient le mot clé "AII_Types". Tous les types d'erreur sont donc couverts par le processus (référence 612 de la figure 6), sauf contre-indications 25 spécifiées par un ou plusieurs profils (720 à 723). - les mécanismes de correction d'erreur 715 à mettre en oeuvre par défaut, pour appliquer cette configuration. La liste fait référence à trois modes de correction différents, - utilisation des FECs de type Reed-Solomon présents 30 dans les données reçues ; - mise en oeuvre d'un mécanisme de type ARQ pour lequel au plus 10 tentatives devront être envisagées avant d'abandonner si 2909241 40 la donnée n'a pu être intégralement corrigée grâce au mécanisme de FEC ; et, - mise en oeuvre d'un mécanisme de correction d'erreur de type statique basé sur la recombinaison de bits. 5 Si la mise en oeuvre de ces mécanismes tel que spécifiée ci-dessus ne permet pas la correction intégrale des données considérées, la meilleure correction partielle obtenue par l'application de ce dernier mécanisme, ainsi que les informations relatives à la localisation estimée des zones erronée et corrigée obtenues au cours de cette phase de 10 correction d'erreur, sont conservées pour être transmises avec les données, au mieux partiellement corrigées, au client dans l'extra flux (références 820 et 830 de la figure 8). - le flux de retransmission des données erronées ou extra flux 716 afin de pouvoir l'initialiser pour le transfert des données erronées 15 vers le client (étape 409 de la figure 4). La rubrique "identifiant du flux" précise l'identifiant SSRC 717 du flux défini par l'application. La rubrique "client" précise les coordonnées réseau 718 du client, son adresse IP et son port, où le PIC devra transmettre les paquets de données erronées. La rubrique "protocole" spécifie quant à elle le protocole réseau 719 (UDP) à 20 utiliser pour transmettre les données erronées. A ce niveau de la description de configuration les informations fournies permettent de sélectionner les données reçues erronées à partir de l'identité du serveur les ayant transmis et de leur flux d'origine (étape 405 de la figure 4) et d'initialiser l'extra flux pour le transfert des données 25 erronées au mieux partiellement corrigées. Le reste de la configuration doit être parcouru pour déterminer s'il existe un ou plusieurs profils spécifiques aux flux considérés, des mécanismes de correction d'erreur appropriés et des informations privées à recueillir pour le transfert des données dans l'extra flux. 30 La seconde partie 720 de la description de configuration définit un profil. Les informations spécifiques à ce profil se décomposent de la façon suivante, 2909241 41 - un moyen d'identification 721 du ou des flux considérés pour ce profil. La liste des identifiants ne contient que le couple d'identifiants du flux vidéo . Le profil ne concerne donc que le flux vidéo décrit en 707, 708 et 709 de la séquence multimédia considérée. 5 - une liste 722 précisant les types d'erreur couverts. Ici, seules les erreurs dues à des collisions sont considérés pour ce flux vidéo. Lorsque cette liste est absente du profil, l'ensemble des erreurs couvertes par défaut 714 l'ait également au niveau du profil. - une liste 723 précisant les mécanismes d'erreur à appliquer. 10 Cette liste restrictive repose sur l'utilisation d'un seul mécanisme de type ARQ, pour lequel seulement 5 essais devront être réalisés avant abandon en cas d'échec. Lorsque cette liste est absente du profil, les mécanismes définis par défaut en 715 doivent être mis en oeuvre pour les données de ce flux. 15 Bien sûr, si la liste identifiant les erreurs couvertes par un profil est absente de celui-ci, celle précisant les mécanismes de correction d'erreur à mettre en oeuvre pour ce profil ne peut l'être et réciproquement. A ce niveau de la configuration et compte tenu de la portée du profil défini (référence 721), seul le flux vidéo est concerné par ce profil, 20 aucun critère de sélection spécifique n'est donc défini pour les données du flux audio anglais considéré dans cette configuration. Les données issues de ce flux, reçues erronées par le PIC, seront donc soumises aux mécanismes de correction d'erreur définis par défaut en 715 jusqu'à obtention d'une correction totale ou après avoir exécuté l'ensemble des 25 mécanismes requis. En ce qui concerne le flux vidéo, les données qui ont été endommagées sur le réseau du fait de collisions seront soumises au seul mécanisme de correction d'erreur spécifié par le profil (références 722 et 723) tandis que les autres seront soumises, comme les données du flux 30 audio anglais, aux mécanismes de correction définis par défaut en 715 jusqu'à obtention d'une correction totale ou après avoir exécuté l'ensemble des mécanismes requis. 2909241 42 La troisième partie 730 de cette description de configuration définit la nature des informations qui doivent être fournies avec les données erronées dans les paquets du flux dédié au transfert de données erronées. 5 Concernant l'origine 731 de la donnée, la description de configuration requiert que l'identifiant du flux dont est issu la donnée erronée à transférer, ainsi que son numéro de séquence dans ce flux, soient de préférence précisés dans cet ordre, respectivement sur 4 et 2 octets. 10 Concernant l'erreur, différents aspects sont considérés. Ces aspects concernent tout d'abord l'origine 732 de l'erreur (le FEC, s'il est présent, doit de préférence être précisé). Ces aspects concernent également la localisation 733 de l'erreur. Il est pour cela avantageux de préciser sa position dans les données d'origine et son étendue en nombre15 d'octets endommagés. Enfin, ces aspects concernent la correction éventuelle partielle 734 d'une erreur pouvant être obtenue en appliquant les mécanismes correspondant (étape 406 de la figure 4). Sa position dans la donnée d'origine ainsi que les mécanismes qui ont permis d'obtenir cette correction sont de préférence décrits selon le format utilisé 20 dans la description de configuration (référence 715). Cette instanciation n'est qu'un exemple donné à titre d'illustration. La description de configuration peut être complétée par des paramètres réseau pour adapter au mieux les traitements appliqués aux données erronées aux conditions du réseau. 25 La figure 8 illustre l'évolution de données, selon l'invention, transitant via un PIC, qui ont été endommagées durant leur transfert depuis le serveur vers le client via des réseaux hétérogènes. L'état CO correspond à l'état des données multimédia 830 sur le serveur avant qu'elles ne soient transmises au client via un réseau non 30 fiable. Ces données sont protégées par un FEC 831, par exemple de type Reed-Solomon, pouvant être utilisé par le PIC pour la détection et la correction d'erreur (étapes 403 et 406 de la figure 4). 2909241 43 L'état (D représente ces mêmes données, reçues par le PIC après avoir transité à travers un réseau non fiable. Ces données ont été partiellement endommagées sur la zone 840 au cours de ce transfert vers leur destinataire. 5 L'état 20 correspond à l'état des données après application des mécanismes de correction d'erreur tels que définis dans la description de configuration (étape de la figure 3 et étapes 405 et 406 de la figure 4). Ces mécanismes n'ont permis qu'une correction partielle de la donnée, la zone corrigée 850 ne couvre donc que partiellement la zone erronée 840 10 des données 830. L'état présente un exemple d'organisation de ces mêmes données multimédia, partiellement corrigées, au sein d'un paquet généré pour le transfert de ces données vers le client via l'extra-flux. Ces données y sont précédées d'un élément de protection 800 et des 15 informations privées 801 comprenant des informations complémentaires sur l'origine du paquet et l'erreur traitée par le PIC. Les informations privées 801, recueillies ou calculées, sont organisées conformément à ce qui a été établi à l'étape 408 de la figure 4 et à la référence 730 de la figure 7b. 20 Les informations privées 801 adjointes aux données erronées considèrent différents aspects de ces données, notamment les informations suivantes : - l'origine 810 du paquet précisant, conformément aux indications de la description de configuration (référence 731 de la figure 25 7b), un moyen d'identifier - le flux d'origine par son identifiant SSRC (contenu dans l'entête RTP du paquet considéré), précisé en 811 dans une zone réservée de 32 bits et, - le paquet dans son flux d'origine par son numéro de 30 séquence, précisé en 812 dans une zone réservée de 16 bits. - l'erreur détectée, au mieux partiellement corrigée 820, en précisant : 2909241 44 - le FEC d'origine 831 qui a permis de détecter et localiser l'erreur, au cours de l'étape 403 de la figure 4. - la localisation 822 de l'erreur dans les données d'origine, ce champ est composé d'un premier octet indiquant le 5 nombre d'octets à suivre utilisés pour la localisation de l'erreur et des n octets suivants contenant l'information. L'estimation de la position de la zone erronée peut être obtenue au cours de la phase de détection d'erreur 402 de la figure 4 par les mécanismes de détection d'erreur, mis en oeuvre conformément à la configuration, 10 reposant sur l'utilisation d'un décodeur à décision quantifiée et également au cours de la phase de correction d'erreur de l'étape 406 de la figure 4 via l'utilisation combinée des mécanismes de correction d'erreur de type ARQ et la combinaison de bits conformément au moyens spécifiés dans la configuration 613 et 715 15 (figures 6 et 7b), permettant d'obtenir par comparaison des paquets reçus la position estimée de la zone erronée et de la zone corrigée. - la localisation dans les données d'origine et l'étendue de la zone corrigée 823, lorsqu'une correction partielle a été obtenue par l'application des mécanismes de correction appropriés 20 (étape 406 de la figure 4). Comme pour la localisation de la zone erronée dans les données d'origine, ce champ est composé d'un premier octet précisant le nombre d'octets à suivre utilisés pour indiquer la localisation de la zone corrigée, des m octets suivants contenant l'information et d'un dernier octet précisant en nombre 25 d'octets la taille de la zone couverte par la correction. Si aucune correction partielle n'a pu être apportée seul le premier octet est utilisé avec une valeur nulle, précisant que cette information est sans objet pour la donnée considérée. La position relative de la correction partielle peut être obtenue simplement en comparant le 30 paquet contenant la meilleure correction partielle, qui doit être transmis au client, avec le paquet initialement reçu avant la mise en oeuvre des mécanismes de correction d'erreur, conformément aux 2909241 45 spécifications de la description de configuration (référence 715 de la figure 7b). - la description 824 des mécanismes utilisés pour obtenir cette correction partielle. Si aucune correction partielle n'a été 5 obtenue ce champ est absent. Dans le cas contraire ce champ est constitué d'un premier octet indiquant le nombre d'octets à suivre utilisés pour décrire les mécanismes et des x octets suivants contenant la liste des mécanismes appliqués désignés par leurs acronymes (identiques à ceux utilisés pour les désigner dans la 10 description de configuration, référence 613 de la figure 6), séparés d'un point virgule, dans leur ordre d'application. L'élément de protection 800, de type FEC Reed-Solomon, est calculé à l'étape 408 de la figure 4, conformément aux indications fournies dans la description de configuration (référence 730 de la figure 7b) de 15 sorte qu'il couvre à la fois les informations privées 810 et 820 et les données au mieux partiellement corrigées. Les données ainsi préparées sont prêtes à être transmises dans l'extra flux dédié au transfert des données erronées vers le client selon le protocole défini pour ce flux en 714 (figure 7b). 20 La constitution de ces paquets, ainsi générés à l'étape 408 de la figure 4 pour le transfert des données erronées dans l'extra flux peut être différente, notamment pour permettre une configuration dynamique du moyen de protection des données et des informations privées. La création de paquets peut être liée à la description de 25 configuration et ainsi couvrir de façon sélective et dynamique une partie de ces données (les informations privées seules, les données seules ou des segments de données dont la zone corrigée) ou mettre en oeuvre d'autres mécanismes que les FECs de type Reed-Solomon (tels que les codes turbo, LDPC ou repeat-accumulate). 30 L'organisation des informations privées peut également être différente, un octet peut être réservé en "en-tête" de ces informations 2909241 46 pour préciser celles présentes, plusieurs d'entre-elles dépendant de la présence d'une correction partielle des données erronées. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des 5 modifications dans la description précédente. REVENDICATIONS 1. Procédé pour optimiser le transfert d'au moins un paquet de données dans un réseau (125, 130, 135) comprenant au moins un serveur (115) et un client (110), ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception dudit client (110) d'au moins une description de configuration (401) ; - réception dudit serveur (115) dudit au moins un paquet (402) ; - détection des erreurs comprises dans ledit au moins un paquet reçu (403) ; et, - si ledit au moins un paquet reçu comprend au moins une erreur, application audit au moins un paquet reçu d'au moins un mécanisme de correction d'erreur spécifié dans ladite au moins une description de configuration (406). 2. Procédé selon la revendication précédente caractérisé en ce qu'il comprend en outre une étape de transmission audit client (110) dudit paquet reçu sur lequel ledit au moins un mécanisme de correction d'erreur spécifié dans ladite au moins une description de configuration a été appliqué si le résultat de cette application a corrigé ladite au moins une erreur (413). 3. Procédé selon la revendication 1 ou la revendication 2 caractérisé en ce que ladite au moins une description de configuration comprend au moins un critère de sélection et en ce que ladite application dudit au moins un mécanisme de correction d'erreur audit au moins un paquet reçu est effectuée si ledit au moins paquet reçu satisfait ledit au moins un critère de sélection (405). 4. Procédé selon la revendication 3 caractérisé en ce que si ledit paquet reçu comprenant au moins une erreur n'est pas intégralement corrigé (407) ou si ledit paquet reçu n'est pas sélectionné selon ledit au 2909241 48 moins un critère de sélection (405), le procédé comprend en outre les étapes suivantes, - création d'au moins un nouveau paquet de données comprenant les données dudit paquet reçu comprenant au moins une 5 erreur (408), potentiellement partiellement corrigées ; et, - transmission dudit au moins un paquet créé audit client (409). 5. Procédé selon la revendication précédente caractérisé en ce que ledit au moins un paquet créé est transmis sur un flux particulier. 6. Procédé selon la revendication 5 caractérisé en ce que ledit 10 flux particulier est identifié dans ladite au moins une description de configuration (614). 7. Procédé selon l'une quelconque des revendications 4 à 6 caractérisé en ce que ledit au moins un paquet créé comprend des informations privées liées à la détection ou à la tentative de correction de 15 ladite au moins une erreur et à l'identification des données et de leur flux d'origine (630). 8. Procédé selon l'une quelconque des revendications 3 à 7 caractérisé en ce que ledit au moins un critère de sélection comprend au moins une identification de flux (611). 20 9. Procédé selon l'une quelconque des revendications 3 à 8 caractérisé en ce que ledit au moins un critère de sélection comprend au moins un paramètre lié à la nature des données des paquets. 10. Procédé selon l'une quelconque des revendications 3 à 9 caractérisé en ce que ledit au moins un critère de sélection comprend des 25 informations adaptées à contrôler au moins un mécanisme de gestion d'erreur (613, 623). 11. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comprend en outre la mise en oeuvre d'au moins un mécanisme de correction d'erreur par défaut si ledit au 30 moins un paquet reçu comprenant au moins une erreur n'appartient pas à un flux spécifié dans ladite description de configuration. 2909241 49 12. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes. 13. Point d'interconnexion de réseaux (120) comprenant le 5 programme d'ordinateur selon la revendication 12 et des moyens adaptés à la mise en oeuvre de ce programme d'ordinateur. 14. Procédé pour optimiser la réception d'au moins un paquet de données dans un réseau (125, 130, 135) comprenant au moins un point d'interconnexion (120), ce procédé étant caractérisé en ce qu'il comprend 10 les étapes suivantes, - définition d'au moins une description de configuration (502) comprenant au moins des informations adaptées à enrichir des paquets de données comprenant des erreurs ayant été préalablement détectées (614, 630); 15 - transmission audit au moins un point d'interconnexion (120) de ladite au moins une description de configuration (503) ; - réception dudit au moins un paquet dudit au moins un point d'interconnexion (504) ; et, -traitement dudit au moins un paquet reçu selon lesdites 20 informations adaptées à enrichir des paquets de données comprenant des erreurs ayant été préalablement détectées (507). 15. Procédé selon la revendication précédente caractérisé en ce que ladite au moins une description de configuration comprend en outre des informations adaptées à identifier des paquets de données (717) et en 25 ce que ledit procédé comprend en outre une étape d'identification dudit au moins un paquet reçu selon lesdites informations adaptées à identifier des paquets de données (505), ledit au moins un paquet reçu étant traité si ledit au moins un paquet reçu est identifié. 16. Procédé selon la revendication précédente caractérisé en ce 30 que lesdites informations adaptées à identifier des paquets de données comprennent un identifiant d'au moins un flux additionnel (614). 2909241 50 17. Procédé selon l'une des revendications 14 à 16 caractérisé en ce que ledit au moins un paquet reçu comprend des informations relatives à au moins un mécanisme de détection ou de correction d'erreur préalablement mis en oeuvre sur au moins une partie des données dudit 5 au moins un paquet reçu selon lesdites informations adaptées à enrichir des paquets de données comprenant des erreurs ayant été préalablement détectées. 18. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon 10 l'une quelconque des revendications 14 à 17. 19. Dispositif client comprenant le programme d'ordinateur selon la revendication 18 et des moyens adaptés à la mise en oeuvre de ce programme d'ordinateur. 20. Dispositif pour optimiser le transfert d'au moins un paquet 15 de données dans un réseau (125, 130, 135) comprenant au moins un serveur (115) et un client (110), ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - des moyens pour recevoir dudit client au moins une description de configuration ; 20 - des moyens pour recevoir dudit serveur ledit au moins un paquet ; - des moyens pour détecter les erreurs dans ledit au moins un paquet reçu ; et, - des moyens pour appliquer audit au moins un paquet reçu au 25 moins un mécanisme de correction d'erreur spécifié dans ladite au moins description de configuration si ledit au moins un paquet reçu comprend au moins une erreur. 21. Dispositif selon la revendication 20 caractérisé en ce qu'il comprend en outre des moyens pour transmettre audit client (110) ledit 30 paquet reçu, sur lequel ledit au moins un mécanisme de correction d'erreur spécifié dans ladite au moins une description de configuration a 2909241 51 été appliqué, si le résultat de cette application a corrigé ladite au moins une erreur. 22. Dispositif selon la revendication 20 ou la revendication 21 comprenant en outre des moyens pour sélectionner ledit au moins un 5 paquet reçu selon au moins un critère de ladite au moins une description de configuration, ledit au moins un mécanisme de correction d'erreur étant appliqué audit au moins un paquet reçu si ledit au moins un paquet reçu est sélectionné. 23. Dispositif selon la revendication 22 caractérisé en ce qu'il 10 comprend en outre les moyens suivants, - des moyens pour créer au moins un nouveau paquet de données comprenant les données dudit paquet reçu et sélectionné, comprenant au moins une erreur, si ledit paquet reçu et sélectionné comprenant au moins une erreur n'est pas intégralement corrigé ; et, 15 - des moyens pour transmettre ledit au moins un paquet créé audit client. 24. Dispositif selon la revendication 23 caractérisé en ce que ledit au moins un paquet créé est transmis sur un flux particulier de préférence identifié dans ladite au moins une description de 20 configuration. 25. Dispositif selon la revendication 23 ou la revendication 24 caractérisé en ce que ledit au moins un paquet créé comprend des informations privées liées à la tentative de correction de ladite au moins une erreur et à l'identification des données et de leur flux d'origine. 25 26. Dispositif pour optimiser la réception d'au moins un paquet de données dans un réseau (125, 130, 135) comprenant au moins un point d'interconnexion (120), ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - des moyens pour définir au moins une description de 30 configuration comprenant au moins des informations adaptées à enrichir des paquets de données comprenant des erreurs ayant été préalablement détectées ; 2909241 52 - des moyens pour transmettre audit au moins un point d'interconnexion (120) ladite au moins une description de configuration ; - des moyens pour recevoir ledit au moins un paquet dudit au moins un point d'interconnexion (120) ; et, 5 - des moyens pour traiter ledit au moins un paquet reçu selon lesdites informations adaptées à enrichir des paquets de données comprenant des erreurs ayant été préalablement détectées. 27. Dispositif selon la revendication 26 caractérisé en ce que ladite description de configuration comprend en outre des informations 10 adaptées à identifier des paquets de données, le dispositif comprenant en outre des moyens pour identifier ledit au moins un paquet reçu selon lesdites informations adaptées à identifier des paquets de données, ledit au moins un paquet reçu étant traité si ledit au moins un paquet reçu est identifié. 15