FR 2901943 A1 20071207 FR 0605015 A 20060606 Procédé de réservation de ressource lors de la transmission d'un contenu dans un réseau de communication, produit programme d'ordinateur, moyen de stockage et dispositif correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des transmissions de contenus de données dans un réseau de communication. Plus précisément, l'invention concerne la réservation de ressources pour de telles transmissions dans un contexte de qualité de service. 2. Solutions de l'art antérieur Le standard "Universal Plug and Play" (ci-après désigné par standard UPnP) a pour objectif de permettre de manière simple et efficace à des systèmes et des équipements d'être mis en réseaux et de collaborer, sans configuration préalable. Les équipements compatibles avec le standard UPnP sont notamment des dispositifs audio-vidéo ou des ordinateurs personnels (PCs) fabriqués par diverses sociétés. Ces équipements peuvent être intégrés dans un réseau IP (pour Internet Protocol ) local tel qu'un réseau domestique. Le standard UPnP fournit à un équipement compatible des moyens de connexion dynamique à un réseau UPnP (qui met en oeuvre le standard UPnP), lui permet de découvrir les autres équipements compatibles du réseau et lui permet de communiquer (ou exposer) ses propres capacités. La technologie UPnP est basée sur le protocole réseau TCP/IP, sur le protocole HTTP (pour HyperText Transport Protocol ) et sur le protocole XML (pour Extensible Markup Language ). Les constituants essentiels d'un réseau UPnP sont les équipements, les services offerts par ces équipements et les postes de contrôle (ou control points en anglais). Un équipement UPnP (qui met en oeuvre le standard UPnP) peut supporter plusieurs services, et est catégorisé en fonction de la liste des services (par exemple un service de type serveur de contenus vidéo , un service de type imprimante, etc.) qu'il peut fournir. Un équipement UPnP expose les services qu'il peut mettre en oeuvre (on parlera dans la suite de ses services ) au moyen d'un fichier de description en langage XML. Un service dans un équipement UPnP comprend une machine d'état, un serveur de contrôle et un serveur d'événements. La machine d'état modélise un état du service grâce à la mise à jour de variables d'état caractérisant l'équipement. Le serveur de contrôle reçoit les requêtes d'équipements distants, exécute les commandes associées et met à jour la machine d'état. Le serveur d'événements orchestre la diffusion sur le réseau de cette mise à jour auprès des équipements UPnP ayant montré leur intérêt pour cette information. Un poste de contrôle UPnP est capable de découvrir et de contrôler des équipements UPnP du réseau UPnP. Quand un nouvel équipement est découvert par le poste de contrôle, ce dernier obtient une description de ce nouvel équipement, a ainsi connaissance des services offerts par cet équipement, demande une description précise de chaque service disponible et enfin envoie des requêtes de contrôle du service sélectionné. Le poste de contrôle peut aussi souscrire auprès du serveur d'événements afin d'être notifié de tout changement d'état. Le standard UPnP Audio Visual (pour UPnP audio visuel , ci-après référencé UPnP AV ) définit un ensemble d'équipements UPnP (par exemple les télévisions, les magnétoscopes, lecteurs DVD, les lecteurs MP3, les ordinateurs PC, ...) avec leurs services associés, qui sont plus spécifiquement dédiés au monde audio/vidéo numérique domestique. Les trois entités logiques principales d'un réseau UPnP AV (qui met en oeuvre le standard UPnP AV) sont : un serveur de media (ou Media Server en anglais) ayant accès à des contenus multimédia qu'il peut diffuser sur le réseau local, un lecteur de media (ou Media Renderer ) capable de jouer localement ce type de contenus multimédia reçus du réseau, et un poste de contrôle coordonnant les opérations. Le standard UPnP Quality of Service (pour UPnP Qualité de Service , ci-après référencé UPnP QoS ), tel que décrit dans le document de référence UPnP QoS standard v1.0/v2.0 , définit un ensemble de services UPnP relatifs à la gestion de qualité de service, qui sont intégrés à des équipements UPnP. Trois services sont ainsi définis : le service UPnP QosPolicyHolder , ci-après désigné par QosPolicyHolder , qui gère les politiques de Qualité de Service validées par un utilisateur et à appliquer sur le réseau ; le service UPnP QosDevice , ci-après désigné par QosDevice , qui est un service d'un équipement du réseau permettant de recevoir les consignes de QoS à appliquer à un flot de donnée d'un contenu particulier ; et le service UPnP QosManager , ci-après désigné par QosManager , qui, sur ordre d'un Poste de Contrôle voulant mettre en place un flot multimédia, est en charge de recueillir auprès du QosPolicyHolder la politique à appliquer et d'informer les QosDevice sur le chemin du flot des actions à mettre en place. Conformément à ce standard, lors du processus de recherche d'un chemin (ou trajet physique emprunté par un contenu de données depuis un équipement source vers un équipement récepteur) entre une source et un récepteur UPnP, le QosManager (équipement responsable), interroge chaque QosDevice pour connaître les autres équipements qui lui sont proches (au moyen d'une requête GetPathlnformation qui envoie une liste d'adresse MAC des autres équipements présents dans le réseau local de type IP, et détectés par chaque interface réseau du QosDevice). Cependant, certains équipements d'interconnexion du réseau (par exemple des commutateurs ou switches ) ne divulguent pas leurs adresses MAC lors du routage des messages sur le réseau. Ces équipements sont donc invisibles pour les services UPnP QosDevice. De plus, lorsqu'ils ne supportent pas le service UPnP QosDevice, ces équipements sont aussi invisibles pour les services UPnP QosManager. Le standard UPnP est un standard émergeant, en cours de spécification, et n'est pas encore universellement supporté par les équipements d'infrastructure des réseaux locaux. Les demandes de garantie de QoS proviennent des applications multimédias réparties qui ne se contentent plus du service "au mieux" (ou Best Effort en anglais) de l'Internet. Ces applications vont du simple transfert de données à celles plus complexes telles que la téléphonie, la vidéo à la demande ou la conférence multimédia. Il existe des réseaux locaux traditionnels de type Ethernet qui ne sont pas capables de réserver de la bande passante pour un trafic avec des contraintes spécifiques. Au mieux, les équipements réseau d'interconnexion (tels que des commutateurs ou switches ) établissent une gestion de priorité de leurs files d'attente (classiquement 8 files au maximum) pour des types de flot identiques (par exemple, tous les flots vidéos passent par la même file, ce qui les rendent prioritaires par rapport à un flot Internet classique). Ceci pose problème lorsque l'on considère le cas de plusieurs flots de même priorité, mais avec des contraintes temps réel différentes. Ainsi, le rôle d'un mécanisme de réservation de ressources est d'informer les entités du réseau des besoins QoS des applications multimédia. Ces entités feront alors en sorte de gérer leurs ressources réseaux (telles que la bande passante) afin de supporter tous les critères du flot multimédia à transmettre. Les versions 1 et 2 du standard UPnP QoS sont basées principalement sur une gestion par priorité de QoS. Ainsi, ces versions du standard UPnP QoS ne permettent pas de réaliser de réservation de ressource par flot. On parle pour le standard UPnp QoS de protocole de signalisation centralisée. Le protocole "Resource Reservation Protocol" (ou protocole de réservation de ressources ci-après désigné par protocole RSVP ) est un protocole bien connu de signalisation de réservation de ressource sur Internet. Selon ce protocole, chaque application peut demander l'établissement d'un lien point-à-point et réservé garantissant les critères QoS. On parle alors de protocole de signalisation en ligne. Le protocole RSVP fonctionne au-dessus du protocole [P, et est capable de traverser de multiples réseaux. Ainsi, le protocole RSVP consiste principalement en l'échange de paramètres de QoS entre un équipement source, des équipements intermédiaires et un équipement récepteur avant de mettre en oeuvre une transmission d'un contenu multimédia. Grâce à ces paramètres de QoS, chaque équipement RSVP (équipement mettant en oeuvre le protocole RSVP) participant à la transmission du contenu réserve des ressources propres et configure sa gestion des flots pour répondre aux critères de QoS demandés. Une fois la procédure de réservation achevée, l'équipement source peut envoyer le contenu multimédia. Si l'un des équipements sur le chemin ne peut supporter les paramètres spécifiés pour le nouveau contenu, l'équipement source est informé de cet échec. Cependant, le protocole RSVP ne peut être mis en oeuvre à lui seul dans les réseaux locaux de type Ethernet. En effet, les messages RSVP véhiculés dans la couche réseau 3 sont totalement transparents pour les équipements d'infrastructure réseau évoluant au niveau 2 (par exemple un commutateur). Aussi, le protocole "Subnet Bandwidth Manager" (ci-après désigné par protocole SBM) défini par la norme RFC-2814 est un protocole de signalisation de réservation QoS pour le contrôle d'admission de flux, basé sur le protocole RSVP mais adapté aux réseaux de type IEEE 802. Le protocole SBM consiste à élire un responsable (ou manager en anglais ci-après désigné par DSBM) sur chaque segment du réseau local afin de classifier et garder trace de chaque flot RSVP, et de fournir un contrôle d'admission et une réservation de bande passante pour ces flots. Il est possible que des segments de niveau 2 soient interconnectés par des équipements qui ne sont pas compatibles avec le protocole SBM. Dans ce cas, ces segments sont traités comme un segment unique contrôlé par un DSBM. A la réception d'un message RSVP destiné à un équipement RSVP récepteur appartenant à la couche 3, chaque équipement de ce segment unique doit rechercher le DSBM et lui envoyer ce message RSVP au lieu de l'envoyer à l'équipement récepteur. Actuellement, la plupart des commutateurs de réseau local sont compatibles avec le protocole SBM. Tel qu'expliqué précédemment, le besoin de garantie de QoS (en termes de bande passante et/ou de criticité temps réel) pour des flots multimédia augmente avec le développement des équipements multimédia. Cependant, on s'aperçoit que pour remplir cet objectif de garantie de QoS, une coordination est nécessaire entre les équipements du réseau afin de délivrer des services assurant la QoS depuis la source jusqu'au récepteur. Dans la plupart des réseaux de communication sont intégrés des équipements (noeuds ou terminaux) qui sont compatibles avec le standard UPnP QoS mais également des équipements qui ne le sont pas, on parle alors de réseau hétérogène. Cependant, le standard UPnP QoS ne prévoit aucune interaction avec des équipements qui ne sont pas compatibles avec le standard UPnP QoS. Ainsi, dans ces réseaux hétérogènes, il n'est pas possible d'assurer la QoS de la source au récepteur dans le cas où l'un des équipement traversé n'est pas compatible avec le protocole UPnP QoS. 3. Objectifs de l'invention L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention, dans au moins un de ses modes de réalisation, est de fournir une technique de réservation de ressources QoS lors de la transmission d'un contenu sur un chemin de transmission comprenant des dispositifs compatibles avec un protocole de signalisation centralisée et des dispositifs non compatibles avec ce protocole mais compatibles avec un protocole de signalisation en ligne. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui soit compatible avec les recommandations des protocoles mis en oeuvre. L'invention, dans au moins un de ses modes de réalisation, a encore pour objectif de mettre en oeuvre une telle technique qui soit simple à mettre en oeuvre et pour un faible coût. 4. Exposé de l'invention Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de réservation de ressource dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source et un dispositif récepteur appartenant à un réseau de communication, ledit réseau comprenant : au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et - au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit procédé étant mis en oeuvre par un dispositif gestionnaire qui est un dispositif dudit premier type. Ce procédé comprend les étapes suivantes : - détection de la présence, sur le chemin de transmission, d'au moins un dispositif du second type qui n'est pas compatible avec le protocole de signalisation centralisé ; -détermination d'un dispositif de transition qui est un dispositif du premier type et qui est aussi compatible avec le protocole de signalisation en ligne ; - envoi au dispositif de transition déterminé d'une demande d'envoi, audit ou auxdits dispositif(s) du second type détecté(s), d'une requête de réservation de ressource conforme au protocole de signalisation en ligne Le principe de l'invention consiste en la commande par un dispositif gestionnaire, lors d'une réservation de ressource pour la transmission d'un contenu, d'au moins un dispositif conforme au protocole de signalisation centralisé qui soit capable de transmettre, à au moins un dispositif non compatible avec le protocole de signalisation centralisé mais compatible avec le protocole de signalisation en ligne, une requête de réservation de ressource conforme au protocole de signalisation en ligne. Ainsi, ce procédé de réservation de ressources selon l'invention permet la transmission de contenus sur un chemin de transmission comprenant des dispositifs compatibles avec un protocole de signalisation centralisée et des dispositifs non compatibles avec ce protocole mais compatibles avec un protocole de signalisation en ligne. Ainsi, ce procédé selon l'invention est basé sur des protocoles de réservation de ressource en ligne ou centralisé et suit les recommandations de ces protocoles, ce qui permet de garantir l'interopérabilité entre ces différents protocoles. Par ailleurs, grâce au procédé selon l'invention, il n'est pas nécessaire de modifier les dispositifs qui ne supportent pas le protocole de signalisation centralisé ce qui permet de réduire le coût du réseau de communication. Par ailleurs, le procédé selon l'invention permet de mettre en oeuvre de la réservation de ressource QoS dans un réseau de communication de manière tout à fait transparente pour l'utilisateur. Avantageusement, le procédé selon l'invention comprend également les étapes suivantes : acquisition d'une topologie du réseau de communication ; détermination, parmi les dispositifs du réseau, desdits au moins un dispositifs du premier type. Préférentiellement, le procédé comprend en outre une étape de détermination du chemin de transmission du contenu. Selon un premier mode de réalisation avantageux de l'invention, le procédé comprend également l'étape suivante : sélection sur le chemin de transmission d'un dispositif de transition commun pour au moins deux dispositifs du second type détectés. Ainsi, selon ce premier mode de réalisation, la requête de réservation conforme au protocole de réservation en ligne est transmise depuis le dispositif de transition vers le dispositif récepteur sans être arrêtée sur son parcours. Selon un second mode de réalisation avantageux de l'invention, le procédé comprend également l'étape suivante : pour chaque dispositif du second type détecté, sélection sur le chemin de transmission d'un dispositif de transition distinct. Ainsi, selon ce second mode de réalisation, la requête de réservation conforme au protocole de réservation en ligne est arrêtée par un dispositif du premier type présent sur le chemin de transmission directement en aval du dispositif du second, ce dernier ne la transmet donc pas à d'autres dispositifs du chemin de transmission. Préférentiellement, le procédé de réservation comprend également l'étape suivante : - détermination du ou desdits dispositifs du premier type qui tiennent compte de la requête de réservation de ressource conforme au protocole de signalisation en ligne initiée par le dispositif de transition. Avantageusement, le procédé de réservation comprend également l'étape suivante : - envoi à au moins un du ou desdits dispositifs de premier type qui tiennent compte de la requête de réservation de ressource conforme au protocole de signalisation en ligne d'une requête de réservation de ressource conforme au protocole de signalisation centralisée, préalablement à la demande d'envoi au dispositif de transition d'une requête de réservation de ressource conforme au protocole de signalisation en ligne. Préférentiellement, le procédé de réservation ne comprend pas d'étape d'envoi au(x) dispositif(s) de premier type qui tien(nent) compte de la requête de réservation de ressource conforme au protocole de signalisation en ligne d'une requête de réservation de ressource conforme au protocole de signalisation centralisée. Selon une caractéristique avantageuse de l'invention, le procédé comprend également une étape initiale de réception par le dispositif gestionnaire d'une requête de transmission avec qualité de service du contenu clu dispositif source vers le dispositif récepteur. Avantageusement, le procédé de réservation comprend également une étape de réception d'un rapport provenant du ou desdits dispositif(s) de transition indiquant la réussite ou l'échec de la réservation de ressource pour la transmission du contenu. Dans un autre mode de réalisation, l'invention concerne également un procédé de réservation dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source et un dispositif récepteur appartenant à un réseau de communication, ledit réseau comprenant : au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et - au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit procédé étant mis en oeuvre par un dispositif de transition, qui est un dispositif dudit premier type et qui est aussi compatible avec le protocole de signalisation en ligne. Ce procédé comprend les étapes suivantes : réception d'une demande d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne à un dispositif dudit second type, situé sur le chemin de transmission et qui est non compatible avec le protocole de signalisation centralisé ; - envoi de ladite requête audit dispositif du second type. Avantageusement, la demande d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne est incluse dans un message de demande de réservation de ressource conforme au protocole de signalisation centralisée. Préférentiellement, le procédé de réservation comprend également les étapes suivantes: réception d'une confirmation de réservation de ressource conforme au protocole de signalisation en ligne ; détermination si la confirmation de réservation de ressource correspond à une demande préalable d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne par un dispositif gestionnaire ; dans l'affirmative, transmission au dispositif gestionnaire d'un rapport positif concernant la réservation de ressource pour la transmission du contenu. Selon une caractéristique avantageuse de l'invention, si la confirmation de réservation de ressource correspond à une demande préalable d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne par un dispositif gestionnaire, le procédé de réservation ne comprend pas d'étape d'envoi de ladite confirmation de réservation de ressource vers d'autres dispositifs en amont du dispositif de transition dans le sens de parcours de la requête de réservation sur le chemin entre le dispositif source et le dispositif récepteur. Avantageusement, ce procédé de réservation comprend également les étapes suivantes : réception d'une demande de réservation de ressource conforme au protocole de signalisation en ligne ; détermination si la demande de réservation de ressource conforme au protocole de signalisation en ligne correspond à un contenu pour lequel une demande de réservation de ressource conforme au protocole de signalisation centralisée par un dispositif gestionnaire a déjà été reçue ; dans l'affirmative, le procédé de réservation ne comprend pas d'étape d'envoi de la demande de réservation de ressource conforme au protocole de signalisation en ligne vers les dispositifs en aval du dispositif de transition dans le sens de parcours de la requête de réservation sur le chemin entre le dispositif source et le dispositif récepteur. Préférentiellement, si la demande de réservation de ressource conforme au protocole de signalisation en ligne correspond à un contenu pour lequel une demande de réservation de ressource conforme au protocole de signalisation centralisée par un dispositif gestionnaire a déjà été reçue, le procédé comprend également l'envoi d'un rapport positif concernant la demande de réservation de ressource conforme au protocole de signalisation en ligne. Préférentiellement, le procédé de réservation comprend également les étapes suivantes: - réception d'une demande de libération de ressource conforme au protocole de signalisation centralisée ; détermination si la demande de libération de ressource correspond à un contenu pour lequel une demande de réservation de ressource conforme au protocole de signalisation en ligne par un dispositif gestionnaire a été préalablement reçue pour au moins un dispositif du second type ; dans l'affirmative, envoi d'une demande de libération de ressource conforme au protocole de signalisation en ligne audit au moins un dispositif du second type. Avantageusement le protocole de signalisation centralisée est le protocole UPnP et le protocole de signalisation en ligne est le protocole SBM.L'invention concerne également un produit programme d'ordinateur., comprenant des instructions de code de programme pour l'exécution des étapes d'au moins un des procédés de réservation tels que précédemment décrits lorsque ledit programme est exécuté sur un ordinateur. L'invention concerne également un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre au moins l'un des procédés de réservation tels que précédemment décrits. Dans un autre mode de réalisation, l'invention concerne un dispositif gestionnaire apte à réserver les ressources de dispositifs d'un réseau de communication, à l'aide d'un protocole de signalisation centralisé, dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source et un dispositif récepteur à travers ledit réseau de communication, ledit réseau comprenant : au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit dispositif gestionnaire étant un dispositif dudit premier type. Ce dispositif gestionnaire comprend : - des moyens de détection d'au moins un dispositif du second type compris sur le chemin de transmission et qui n'est pas compatible avec le protocole de signalisation centralisé; - des moyens de détermination d'un dispositif de transition qui est un dispositif du premier type et qui est compatible avec le protocole de signalisation en ligne ; et - des moyens d'envoi au dispositif de transition d'une demande d'envoi audit ou auxdits dispositif(s) du second type détectés d'une requête de 20 réservation de ressource conforme au protocole de signalisation en ligne. Avantageusement, le dispositif gestionnaire comprend également : des moyens de sélection, sur le chemin de transmission, d'un dispositif de transition commun pour au moins deux dispositifs du second type détectés. Selon une variante avantageuse, le dispositif gestionnaire comprend 25 également : des moyens de sélection, sur le chemin de transmission, d'un dispositif de transition commun pour au moins deux dispositifs du second type détectés. Selon une caractéristique avantageuse, le dispositif gestionnaire comprend également des moyens de réception d'un rapport provenant du ou desdits dispositif(s) de transition indiquant la réussite ou l'échec d[e la réservation de ressource pour la transmission du contenu. Dans un autre mode de réalisation, l'invention concerne un dispositif de transition apte à réserver les ressources de dispositifs d'un réseau de communication, à l'aide d'un protocole de signalisation centralisé, dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source et un dispositif récepteur à travers ledit réseau de communication, ledit réseau comprenant : - au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit dispositif de transition étant un dispositif dudit premier type, et qui est aussi compatible avec le protocole de signalisation en ligne. Ce dispositif comprend : des moyens de réception d'une demande d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne à un dispositif dudit second type, situé sur le chemin de transmission et qui est non compatible avec le protocole de signalisation centralisé ; des moyens d'envoi de ladite requête audit dispositif du second type. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un schéma d'un réseau local dans lequel peut être mis en oeuvre le procédé de réservation de ressource selon un mode de réalisation conforme à l'invention ; - la figure 2 présente un schéma d'un équipement générique mettant en oeuvre le procédé de réservation de ressource selon un mode de réalisation conforme à l'invention ; la figure 3 illustre la mise en oeuvre du procédé de réservation de ressource selon un mode de réalisation de l'invention lors de la transmission avec QoS d'un contenu cO sur un chemin de transmission du réseau local de la figure 1 ; la figure 4 présente les étapes principales du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par le QosManager, lors de la transmission de cO ; - la figure 5 présente les étapes principales d'un algorithme de détermination du chemin de transmission de cO mis en oeuvre par le QosManager ; la figure 6 présente les étapes principales du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par un pont sur lechemin de transmission de cO, lors de la transmission de cO ; - les figures 7A et 7B présentent un algorithme des étapes du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par le pont lors de la réception de messages provenant du réseau local relatifs aux protocoles UPnP QoS ou SBM. 6. Description d'un mode de réalisation de l'invention Dans la suite, on se place, dans le cadre d'un mode de réalisation de l'invention, dans un réseau local 100 (dont un schéma est illustré en figure 1) qui comprend notamment : des équipements conformes à un protocole de signalisation centralisée, par exemple le protocole UPnP QoS (dits équipements d'un premier type) ; -des équipements qui ne mettent pas en oeuvre le protocole UPnP QoS mais qui mettant en oeuvre un protocole de signalisation en ligne, par exemple le protocole SBM (dits équipements d'un second type). Bien entendu, les protocoles de signalisation centralisé et en ligne peuvent être tout autre protocole que les protocoles UPnP QoS et SBM. Notamment il est possible de considérer le protocole Ethernet AV à la place du protocole SBM. Le protocole Ethernet AV est une évolution de la norme IEEE 802.3 pour les réseaux locaux avec support QoS pour la transmission de flots de contenus audio/vidéo. Ce protocole est en cours de spécification par le sousgroupe Audio/Video Bridging Task Group du groupe de travail IEEE 802.1. Le réseau local 100 est par exemple un réseau Ethernet mettant en oeuvre le protocole IEEE 802 et permet de mettre en œuvre des communications de type UPnP QoS (au moins entre certains équipements) pour lesquelles chaque équipement UPnP QoS (ou équipement mettant en oeuvre le standard UPnP QoS) du réseau est identifié et communique périodiquement la description de ses services. Le réseau local 100 comprend à la fois des équipements terminaux qui sont visibles par l'utilisateur (par exemple des terminaux multimédia du réseau local 100 qui sont directement contrôlés par l'utilisateur) et des équipements d'infrastructure réseau permettant la liaison entre ces équipements terminaux. On notera que le réseau local 100 peut aussi bien être un réseau domestique qu'un réseau local d'entreprise, constitué partiellement ou totalement de segments sans fil (par exemple conformes aux normes Wifi ou Bluetooth , marques déposées). La catégorie des équipements terminaux comprend notamment : - un serveur de flot multimédia 110 répondant à la norrne UPnP AV (que l'on appelle également UPnP Media Server ) qui est notamment capable d'émettre en continu des contenus vidéo suivant des protocoles réseau et qui fonctionne en mode connecté (par exemple via le protocole HTTP sur IP) et/ou en mode non connecté (par exemple via le protocole RTP sur le protocole UDP). Ce serveur peut notamment être un ordinateur personnel, un lecteur DVD ou une caméra possédant une connectivi.té IP ; un terminal client 120, disposant d'un service UPnP Media Renderer , qui peut notamment être un ordinateur personnel ou un écran de téléviseur apte à afficher les flots multimédia en provenance du serveur 110 ; - un poste de contrôle UPnP 130, qui peut notamment être un ordinateur personnel, une tablette PC, un assistant personnel (ou PDA), une télécommande proposant à l'utilisateur une sélection d'équipements UPnP sur le réseau local 100 et des contenus multimédia à jouer ; des ordinateurs tels que représentés par H3 et H4. La catégorie des équipements d'infrastructure réseau comprend notamment des équipements d'interconnexion 140 qui peuvent notamment être : des équipements de routage de niveau 2 (par exemple des commutateurs ou switches en anglais) ; des ponts entre deux segments du réseau (par exemple, un ordinateur disposant de deux cartes réseau constitue un pont). Ces équipements d'infrastructure réseau 140 implémentent généralement des protocoles de signalisation en ligne QoS tel que le protocole SBM précité (tel que le commutateur 140B ci-après décrit en relation avec la figure 3). Ils peuvent également implémenter le standard UPnP QoS (tel que par exemple le pont 140A ci-après décrit en relation avec la figure 3). Un pont est un matériel d'interconnexion qui relie deux segments Ethernet. A chacun des segments auquel est connecté un pont, est associée une table des adresses MAC des équipements terminaux de ce segment qui est gérée par le pont. Une telle table est construite par le pont à l'aide d'un processus d'apprentissage dans lequel, à chaque émission d'une trame par un équipement, le pont stocke dans la table l'adresse MAC de l'équipement terminal en regard avec le segment concerné. Ces tables permettent au pont de router les trames. En effet, lorsque le pont reçoit une trame provenant de son premier segment, il relaye la trame vers son second segment dans l'un des cas suivants : - l'adresse du destinataire de la trame correspond à une adresse du second segment ; - il s'agit d'une adresse de diffusion (ou broadcast en anglais) ; l'adresse n'est pas connue par le pont. Un commutateur est considéré comme un pont qui a plus de deux interfaces. Des services conformes au standard UPnP QoS peuvent être embarqués dans certains des équipements du réseau local 100. On considère dans la suite que les serveur de flot multimédia 110, terminal client 120 et poste de contrôle UPnP 130 disposent du service UPnP QosDevice (on les désignera dans la suite par équipements QosDevice). Par ailleurs, le réseau local 100 comprend un service UPnP QosManager . Ce service UPnP QosManager peut être embarqué dans n'importe quel équipement du réseau local 100 disposant préférentiellement d'une plateforme matérielle identique à celle de l'équipement générique 200 décrit ci- après en relation avec la figure 2. Par exemple, il est embarqué dans un équipement 150, que l'on désigne ci-après par QosManager 150 (autrement appelé dispositif gestionnaire dans le cadre de la réservation de ressource pour c0). Le service UPnP QosManager est un service unique pour le réseau local 100. Le standard UPnP QoS précité définit plus précisément les procédures à suivre pour choisir le QosManager actif si plusieurs services sont en concurrence. Dans la suite, on décrit le procédé de réservation de ressource selon un mode de réalisation de l'invention, dans le cadre de la transmission d'un contenu de données c0 sur un chemin de transmission entre un dispositif source (serveur de flot multimédia 110) et un dispositif récepteur (terminal client 120) appartenant au réseau local 100. Ainsi lors de la sélection du contenu multimédia c0 par le poste de contrôle 130, un message UPnP est envoyé au terminal client 120 en vue d'avertir son service Media Renderer du type du contenu multimédia c0 à recevoir (par exemple au moyen d'un message de type Avt_SetAvTransportUri désigné par message 1). En parallèle, le poste de contrôle 130 demande au QosManager 150 de préparer les ressources QoS nécessaires au bon acheminement du contenu multimédia c0 entre le serveur de flot multimédia 110 et le terminal client 120 (par exemple au moyen d'un message de type QM_RequestTrafficQos désigné par message 2). Le QosManager 150 cherche à obtenir le chemin à travers le réseau par lequel passera le contenu multimédia c0, afin de déterminer quels sont les équipements QosDevice pour les informer de la réservation de ressources pour ce contenu c0 (message 3). Si tous ces équipements QosDevice admettent les caractéristiques QoS du contenu c0, le QosManager 150 acquittera la requête du poste de contrôle 130, et ce dernier autorisera le terminal client 120 à jouer le contenu multimédia c0 (par exemple au moyen d'un message de type Avt_Play désigné par message 4). Le terminal client 120 enverra alors une requête de lecture du contenu multimédia c0 au serveur de flot multimédia 110 (par exemple par un message de type RTSP afin de recevoir le flot multimédia au format de diffusion RTP). Le procédé de réservation de ressource selon l'invention est mis en oeuvre sous la forme d'un logiciel et/ou d'une pluralité de sous logiciels (comprenant une pluralité d'algorithmes décrits ci-après) qui est (sont) exécuté(s) dans plusieurs machines du réseau local 100, par exemple dans l'équipement générique 200 décrits notamment ci-après en relation avec la figure 2. On présente, en relation avec la figure 2, un schéma d'un équipement générique 200 mettant en oeuvre le procédé de réservation de ressource selon un mode de réalisation conforme à l'invention. Cet équipement générique 200 (qui peut notamment être un micro-ordinateur ou une station de travail) peut notamment être connecté à tout moyen de stockage d'image, de vidéos, ou de sons reliés à une carte graphique et délivrant à l'équipement générique 200 des données multimédia. Ainsi, l'équipement générique 200 comporte un bus de communication 202 auquel sont reliés : une unité centrale de traitement 203 (qui est par exemple un microprocesseur référencé CPU) ; une mémoire morte 204 référencée ROM, pouvant comporter le ou les logiciel(s) précité(s) et référencé(s) Prog ; une mémoire vive 206 (mémoire cache référencée RAM), comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution du ou des logiciel(s) précité(s) ; un écran 208 permettant de visualiser des données et/ou de servir d'interface graphique avec l'administrateur réseau qui pourra interagir avec le ou les logiciel(s) 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 ou un crayon optique ; une interface de communication 218 reliée à un réseau de communication distribué 220, par exemple le réseau local 100, l'interface étant apte à transmettre et à recevoir des données. L'équipement générique 200 comprend également (mais ceci est optionnel) : un disque dur 212 pouvant comporter le ou les logiciel(s) Prog ; - un lecteur de disquette 214 adapté à recevoir une disquette 216 et à y lire ou à y écrire des données traitées ou à traiter conformément au procédé de réservation de ressource selon l'invention. Le bus de communication 202 permet la communication et l'interopérabilité entre les différents dispositifs inclus dans l'équipement générique 200 ou reliés à cet équipement. De manière plus générale, grâce au bus de communication 202, l'unité centrale 203 est susceptible de communiquer des instructions à tout dispositif inclus dans l'équipement générique 200 directement ou par l'intermédiaire d'un autre dispositif de l'équipement générique 200. Le code exécutable de chacun du ou des logiciel(s) précités permettant à l'équipement générique 200 de mettre en oeuvre le procédé de réservation de ressource selon l'invention, peut être stocké, par exemple, dans le disque dur 212 ou dans la mémoire morte 204. Selon un premier mode de mise en oeuvre de l'invention, la disquette 216, contient initialement des données ainsi que le code exécutable de chacun du ou des logiciel(s). Ainsi, une fois que ces données et ce code sont lus par l'équipement générique 200, ce dernier le stocke dans son disque dur 212 (ou plus généralement dans tout moyens de stockage de l'équipement 200 tel que la mémoire morte 204). Selon un second mode de mise en oeuvre de l'invention, le code exécutable de chacun du ou des logiciel(s) est reçu par l'intermédiaire du réseau local 100, via l'interface de communication 218, pour être lus et stocké sur le disque dur 212 (ou plus généralement dans tout moyens de stockage de l'équipement 200 tel que la mémoire morte 204) par l'équipement générique 200. Bien entendu, au lieu de la disquette 216, on peut mettre en oeuvre tout support d'information lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser le ou les logiciel(s) selon l'invention (par exemple, un disque compact (CD-ROM) ou une carte mémoire). L'unité centrale 203 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des logiciel(s) selon l'invention. Lors de la mise sous tension, le ou les logiciels 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 qui contiendra alors le code exécutable du ou des logiciel(s) selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre du procédé de réservation de ressource selon l'invention. Selon un troisième mode de mise en oeuvre de l'invention, l'équipement générique est un appareil programmé qui contient alors le code du ou des logiciel(s) selon l'invention, par exemple figé dans un circuit intégré à application spécifique (tel qu'un circuit ASIC). On illustre, en relation avec la figure 3, la mise en oeuvre du procédé de réservation de ressource selon un mode de réalisation de l'invention lors de la transmission avec QoS de c0 sur un chemin (ou trajet physique emprunté) allant du serveur de flot multimédia 110 (ou dispositif source) vers le terminal client 120 (ou dispositif récepteur) dans le réseau local 100 de la figure 1. On rappelle que le serveur de flot multimédia 110 et le terminal client 120 sont tous deux des équipements QosDevice (c'est-à-dire qu'ils implémentent un service QosDevice conforme au standard UPnP QoS). Entre ces deux équipements sont disposés deux équipements d'interconnexion 140A et 140B (qui peuvent être notamment des équipements de routage de niveau 2 ou des ponts). Ainsi, le chemin de transmission comprend dans le présent cas particulier les dispositifs source 110, récepteur 120 et les deux équipements d'interconnexion 140A et 140B. L'équipement d'interconnexion 140A est par exemple un pont qui conforme au standard UPnP QoS et qui implémente un service QosDevice conforme au mode de réalisation de l'invention. L'équipement d'interconnexion 140B est un commutateur n'implémentant pas de service UPnP mais est conforme avec le protocole de signalisation en ligne SBM. Il s'agit par exemple d'un commutateur classique commercialisé sous la référence CISCO Catalyst de la série 6000. Tel qu'indiqué précédemment en relation avec la figure 1, le service UPnP QosManager est embarqué dans le QosManager 150 qui est identique à l'équipement générique 200 illustré en figure 2. Le QosManager 150 communique avec les équipements QosDevice 110 et 120 conformément au standard UPnP QoS. Le QosManager 150 reçoit du poste de contrôle 130 les caractéristiques du flot du contenu multimédia c0 ainsi que les adresses des équipements QosDevice 110 et 120. Conformément à la politique de QoS active sur le réseau local 100 et qui est conforme au mode de réalisation de l'invention, les caractéristiques du flot du contenu multimédia c0 permettent de déterminer le type de ressources QoS à mettre en oeuvre dans le cadre de la transmission de ce contenu c0. Dans le cas où la transmission du contenu multimédia c0 est qualifiée de service au mieux (ou Best Effort en anglais), alors, il n'est pas nécessaire de mettre en oeuvre le procédé de réservation de ressource selon le mode de réalisation de l'invention pour la transmission de ce contenu c0. Cependant, le protocole d'admission de ce contenu c0 ne doit pas perturber les transmissions QoS des autres contenus en cours. Dans le cas où le flot du contenu c0 (qui peut être de la vidéo ou de la visiophonie) présente des caractéristiques précises concernant le délai de délivrance garanti, ceci impose une mise en oeuvre d'une réservation de ressource QoS dédiée à ce contenu c0. On rappelle ci-après comment est caractérisé un flot d'un contenu multimédia. La QoS au niveau d'un réseau se décline en quatre paramètres : le débit, la latence, la gigue et la perte. Le débit communément appelé "bande passante" représente la ressource de transmission que nécessite le flot du contenu. La gestion de la bande passante est un élément important pour la garantie de QoS. La latence est définie par le délai de transfert de bout-en-bout (du dispositif source vers le dispositif récepteur) d'un paquet du contenu. Les applications interactives comme la téléphonie présentent une latence maximum tolérable. Si un paquet subit un retard important, ce retard est équivalent pour ces applications à une perte de données. La gigue correspond aux variations de latence des paquets du contenu. La cause principale de l'apparition de la gigue dans la transmission du contenu provient des changements d'intensité de trafic dans les commutateurs. La perte de paquets se produit lorsqu'il y a des erreurs d'intégrité sur les données. La perte de paquet se produit aussi lorsque l'intensité du trafic sur les commutateurs devient supérieure à leur capacité d'écoulement. Elle est une indication de congestion. Afin de limiter cette congestion, la méthode d'isolation des flots de contenus consiste à fournir aux flots demandant une QoS particulière une protection contre les flots perturbateurs. Ainsi, le procédé de réservation selon le mode de réalisation de l'invention ne vise pas à détailler comment se fait la caractérisation d'un flot multimédia, mais présenter une solution afin d'acheminer de bout en bout un flot dit critique avec des garanties de QoS strictes. Afin de caractériser un flot, le standard RFC-2215 définit un objet Token_Bucket_Tspec regroupant les notions précédentes, et qui sera par exemple utilisé par la suite. Les équipements QosDevice 110, 120 et 140A, pilotés par le QosManager 150, sont aptes, conformément à l'invention, à adopter une gestion locale de leurs ressources physiques conforme au protocole de signalisation en ligne SBM. Grâce à l'invention, un équipement QosDevice (par exemple l'équipement d'interconnexion 140A) est capable de diriger une requête de réservation de ressource vers le commutateur 140B n'implémentant pas de service UPnP QoS. De plus, comme expliqué ci-après, en relation avec la figure 4, le QosManager 150 possède des moyens particuliers de détection des équipements qui n'implémentent pas le protocole de signalisation centralisé UPnP QoS tels que le commutateur 140B, et des moyens d'obtention de l'équipement QosDevice idéal et apte à s'adresser au commutateur 140B. Le commutateur 140B met en oeuvre le protocole de signalisation en ligne SBM (RFC-2814) précité et, du fait qu'il est connecté sur le réseau Ethernet, il implémente la norme IEEE 802.1-D. On rappelle que la norme IEEE 802.1D définit un protocole de Spanning Tree (ci-après désigné par protocole STP pour Spanning Tree Protocol ) et un algorithme associé. Le protocole STP est un protocole de communication de couche 2 permettant de supprimer les chemins redondants en construisant un arbre à partir d'un graphe cyclique. Il est ainsi mis en oeuvre par les ponts et commutateurs pour : découvrir les boucles sur le réseau ; créer une topologie logique sans boucles en bloquant certains trajets ; -contrôler la disponibilité de la topologie logique ; - basculer sur une topologie logique de secours. Le protocole STP utilise une trame spécifique baptisée BPDU (pour Bridge Protocol Data Unit ) et une adresse multicast qu'en principe seuls les commutateurs écoutent (communications transparentes vis-à-vis des stations finales, qui ne connaissent pas la topologie du réseau). Le programme exécuté dans chaque dispositif de commutation utilisant ce protocole est appelé l'algorithme Spanning Tree (ci-après désigné par algorithme STP). Cet algorithme calcule la topologie du réseau et trouve le meilleur chemin entre deux stations. On présente, en relation avec la figure 4, les étapes principales du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par le QosManager 150 (disposant du service UPnP QosManager ), lors de la transmission avec QoS du contenu c0 du serveur de flot multimédia 110 (dispositif source) vers le terminal client 120 (dispositif récepteur). On rappelle que le service UPnP QosManager peut être embarqué dans n'importe quel équipement du réseau local 100 disposant d'une plateforme matérielle identique à celle de l'équipement générique 200 de la figure 2. Le QosManager 150 est unique dans le réseau à un instant donné mais n'est pas nécessairement situé sur le chemin du flot multimédia du contenu c0 (ou chemin de transmission du contenu c0) pour contrôler la QoS de ce flot. Une tache de fond 470 est exécutée continuellement, et consiste à mettre en oeuvre des étapes 480 et 490. Ces deux étapes 480 et 490 ont pour but de mettre à jour régulièrement les données récupérées du réseau local 100. Dans l'étape 480, le QosManager 150 met en oeuvre les algorithmes spécifiés dans la norme IEEE-802.1D permettant de recueillir la topologie du réseau Ethernet 100. Selon cette norme IEEE-802.1D, les équipements d'interconnexion 140A et 140B se communiquent la topologie Spanning Tree en échangeant des messages de configuration BPDU (pour Bridge Protocol Data Unit ). Ces messages BPDU contiennent notamment des informations relatives à l'adresse de l'équipement d'interconnexion et aux adresses, priorités et coûts de chacun de ses ports. Le QosManager 150 a souscrit à la réception de ces messages BPDU. Une telle souscription peut être effectuée par l'intermédiaire du protocole GMRP (pour GARP Multicast Registration Protocol qui est défini par le protocole IEEE 802.1P). Les messages BPDU sont ainsi obtenus en écoutant sur l'adresse MAC de diffusion nommée "Bridge Group Address". Dans l'étape 490, le QosManager 150 écoute les messages de découverte de services et de machines dans le réseau comprenant les équipements QosDevice implémentant le standard UPnP QoS. Le protocole SSDP (pour Simple Service Discovery Protocol ) spécifié par le standard UPnP utilise le protocole HTTP sur le protocole UDP. Avantageusement, cette étape 490 peut être considérée comme étant une étape d'un poste de contrôle UPnP spécifique au recensement des services UPnP QosDevice du réseau. Les informations échangées entre les équipements QosDevice et le poste de contrôle sont limitées aux messages de détection fournissant des informations de base sur les équipements et leurs services ainsi qu'une URL de description qui peut être utilisée pour rassembler des informations supplémentaires sur les équipements et leurs services : une fois un service découvert, il est possible de récupérer le fichier XML décrivant précisément les fonctionnalités de ce service. Selon une variante de ce mode de réalisation, dans cette étape 490, le QosManager 150 émet des requêtes de découverte relatives au service UPnP QosDevice , afin que les équipements implémentant ce service se fassent connaître. En effet, afin de limiter le nombre de messages SSDP, seuls les changements sont théoriquement envoyés sur le réseau local 100. On notera que le protocole SSDP est cité à titre d'exemple, et que tout autre protocole d'avertissement de modification sur UPnP peut être mis en oeuvre dans le cadre de la présente invention. De manière simple, les résultats issus de cette étape 490 consistent en la mise à jour régulière d'une liste d'équipements UPnP disposant de service UPnP QosDevice . Pour chaque équipement QosDevice, le QosManager 150 envoie un message QD_GetPathlnformation (conforme au standard UPnP QoS) afin que cet équipement QosDevice communique au QosManager 150 les adresses MAC connues par lui (les adresses MAC de tous les ports de l'équipement, ainsi que les adresses MAC d'autres équipements connectés à chacun des ports). Ceci correspond à la méthode de détection UPnP classique de la topologie du réseau local, dont les limitations ont préalablement été décrites. Par exemple, en réponse à une telle requête, un équipement QosDevice de type commutateur de niveau 2 avec 4 ports renvoie une description telle que la description de l'annexe 1. Dans une étape 400, le QosManager 150 reçoit une requête d'établissement d'un flot pour le contenu cO avec qualité de service (par exemple un message QM_RequestTrafficQos spécifié par le standard UPnP QoS pour le service QosManager) en provenance du poste de contrôle UPnP 130. La requête contient notamment des informations sur les caractéristiques du flot du contenu cO à transmettre, ainsi que celle du serveur de flot multimédia 110 (dispositif source) et du terminal client 120 (dispositif récepteur). L'annexe 2 donne un exemple d'une telle requête. Grâce aux informations fournies par les champs SourceAddress et DestinationAddress de la requête de l'annexe 2, dans une étape 410, le QosManager 150 obtient les adresses MAC Ethernet du serveur de flot multimédia 110 et du terminal client 120. Pour ce faire, il peut être mis en oeuvre le protocole DNS et/ou le protocole ARP. Ensuite, à partir des informations obtenues lors de la tâche de fond 470, le QosManager 150 calcule le chemin de transmission de niveau 2 du contenu cO depuis le serveur de flot multimédia 110 vers le terminal client 120. Ce calcul utilise les adresses MAC des serveur de flot multimédia 110 et terminal client 120 afin de mettre en oeuvre l'algorithme Spanning Tree. Ainsi ce procédé de réservation de ressource n'a pas pour but l'optimisation du calcul du chemin du Spanning Tree, mais offre la particularité de détecter les équipements QosDevice rencontrés sur le chemin de transmission du contenu cO. Le calcul du chemin de transmission du contenu cO est plus détaillé ci-après, en relation avec la figure 5. A l'issue de l'étape 410, on obtient la liste des équipements d'interconnexion 140 ordonnancés depuis le serveur de flot multimédia 110 vers le terminal client 120 présents sur le chemin de transmission du contenu cO. Une boucle (comprenant des étapes 420, 430, 440 et 450) est alors mise en oeuvre afin de classifier ces équipements 140 selon qu'ils sont des équipements d'interconnexion implémentant le standard UPnP QoS (tel que le pont 140A) ou des équipements d'interconnexion n'implémentant pas le standard UPnP QoS (tel que le commutateur 140B). Dans l'étape 420, le QosManager 150 se focalise sur un équipement d'interconnexion donné dans la liste des équipements d'interconnexion 140 du chemin de transmission de cO, puis dans l'étape 430, il vérifie si cet équipement donné implémente le protocole de signalisation centralisé UPnP' QoS. Si l'équipement donné n'implémente pas le standard UPnP QoS mais implémente le protocole SBM, le QosManager 150 sélectionne sur le chemin de transmission un unique dispositif de transition conforme au protocole UPnP QoS et qui est situé en amont de l'équipement donné dans le sens de parcours du chemin de transmission par la requête de réservation. Puis, dans une étape 450, le QosManager 150 envol, au dispositif de transition, une demande d'envoi d'une requête de réservation de ressources conforme au protocole de signalisation en ligne. Cette demande d'envoi, sous la forme d'un message UPnP classique, ne fait pas partie des actions classiques du standard UPnP QoS. Selon un premier mode de réalisation de l'invention, le QosManager 150 sélectionne un unique dispositif de transition pour l'ensemble des équipements du chemin n'implémentant pas le standard UPnP QoS mais seulement le protocole SBM. Ainsi, ce dispositif de transition unique est situé en amont de chacun des équipements du chemin n'implémentant pas le standard UPnP QoS mais seulement le protocole SBM. Selon un second mode de réalisation de l'invention, pour chacun des équipements du chemin n'implémentant pas le standard UPnP QoS mais seulement le protocole SBM le QosManager 150 sélectionne un dispositif de transition distinct. Puis, ledispositif de transition, après avoir reçu la demande d'envoi, envoie la requête de réservation de ressources conforme au protocole de signalisation en ligne à l'équipement donné. Du fait que l'équipement donné implémente le protocole SBM, cette 10 demande de réservation de ressource est réalisée en envoyant un message SBM PATH en direction du terminal client 120 (destinataire du flot). Selon une variante de l'invention, le QosManager 150 détermine les QosDevices qui seront impactés par la requête de réservation de ressources conforme au protocole de signalisation en ligne à l'équipement donné, 15 préalablement à la demande d'envoi faite au dispositif de transition. Le QosManager peut ainsi réordonner les requêtes de réservation adressées aux QosDevices sur le chemin de transmission et envoyer aux QosDevices ainsi déterminés un message QD_SetupTrafficQoS tel que spécifié par le standard UPnP QoS. Ainsi, ces QosDevices recevront en premier lieu la requête de 20 réservation selon le protocole UPnP QoS avant de recevoir la requête de réservation selon le protocole SBM qui sera propagée par l'équipement n'implémentant pas le standard UPnP QoS mais seulement le protocole SBM. Ceci permet d'éviter les conflits de réservation de ressources lorsque les deux protocoles, UPnP QoS et SBM, sont conjointement utilisés pour un même chemin 25 de transmission. Selon une autre variante de l'invention, le QosManager 150 après avoir déterminé les QosDevices qui seront impactés par la requête de réservation de ressources conforme au protocole de signalisation en ligne à l'équipement donné, peut ne plus les prendre en compte à l'étape 420. La réservation de ressources 30 auprès de ces QosDevices s'effectuera alors à la propagation de la requête de réservation selon le protocole SBM par l'équipement n'implémentant pas le standard UPnP QoS mais seulement le protocole SBM. Le comportement des équipements QosDevices à la réception d'une requête de réservation de ressources selon les protocoles UPnP QoS et SBM sera détaillé lors de la description des figures 7A et 7B. Conformément à la présente invention, préférentiellement mais non exclusivement, outre l'étape 450, le QosManager 150 demande explicitement à l'équipement QosDevice situé en amont de l'équipement donné d'effectuer une confirmation de la réservation des ressources QoS selon la méthode en vigueur dans le protocole de signalisation en ligne SBM. Du fait que l'équipement donné implémente le protocole SBM, cette confirmation est réalisée en envoyant un message SBM RESV en direction du serveur de flot multimédia 110 (source de c0). Selon une variante (non représentée) du mode de réalisation de l'invention, cette confirmation de réservation n'est pas demandée par le QosManager 150 car les équipements QosDevice peuvent automatiquement répondre à la demande de réservation de ressources dans le protocole de signalisation en ligne SBM (tel que cela est expliqué ci-après en relation avec la figure 8). Si l'équipement donné implémente le standard UPnP QoS, alors dans une étape 440, le QosManager 150 transmet à l'équipement donné une requête de QoS classique du standard UPnP QoS (par exemple cette requête est un message QD_SetupTrafficQoS spécifié par le standard UPnP QoS pour le service QosDevice). Avantageusement, le message QD_SetupTrafficQoS est particularisé. Comme le standard UPnP QoS permet d'ajouter des éléments spécifiques dans une structure XML, par exemple, le QosManager 150 ajoute une variable dans la structure TrafficDescriptor qui sera comprise par l'équipement donné s'il implémente le procédé de réservation de ressource selon l'invention. Cette variable est ignorée par les dispositifs n'implémentant pas le procédé de réservation de ressource selon l'invention. Cette variable est par exemple désignée par: TRUE . La valeur TRUE précise que le terminal client 120 doit envoyer une requête de réservation dans le second protocole. La valeur FALSE (ou l'absence de cette variable) ne modifie pas le comportement habituel. Un exemple de message QD_SetupTrafficQoS envoyé sur le réseau est donné en annexe 3. Selon un mode préférentiel de réalisation de l'invention, le QoSManager est capable d'émettre en parallèle plusieurs messages QD_SetupTrafficQoS sur le réseau. Selon un mode de réalisation de l'invention conforme au standard UPnP QoS, le QoSManager reste en attente d'une réponse à cette requête correspondant au résultat de l'établissement de la réservation de ressource QoS pour la transmission du contenu. Ce rapport est établi par le système de transition comme décrit ci-après à l'étape 660. Selon le mode préférentiel de réalisation de l'invention, une distinction des équipements QosDevice pouvant implémenter le procédé de réservation de ressource selon l'invention et de ceux qui ne peuvent pas est rnise en oeuvre lors de l'étape 490 précitée (permettant de détecter tous les équipements QosDevice du réseau). Par exemple, pour un équipement déterminé, la possibilité d'implémenter le procédé de réservation de ressource selon l'invention ou non peut être testée par l'examen des descriptifs XML (comprenant par exemple un numéro de série, un code produit spécifique, un nom de modèle spécifique ou un numéro de modèle spécifique) de l'équipement déterminé. Une autre solution pour réaliser un tel test peut consister à offrir un champ descriptif propriétaire dans la structure de retour du message GetDeviceCapabilities proposé par l'interface UPnP QosDevice. Ainsi, l'étape 430 (de vérification si l'équipement donné implémente le standard UPnP QoS) peut être modifiée afin de vérifier si l'équipement donné peut également implémenter le procédé de réservation de ressource selon l'invention et de vérifier si cet équipement donné est le dernier de la liste des équipements du chemin de transmission du contenu c0 avant un éventuel prochain équipement n'implémentant pas le standard UPnP QoS. On se place dans le cadre d'un flot multimédia (correspondant au contenu c0) qui est directionnel vers le terminal client 120 (équipement récepteur), cependant l'invention s'applique également dans le cas de flots en direction de plusieurs terminaux clients, auquel cas, il existe plusieurs chemins de transmission du contenu c0 à mettre en oeuvre. On présente, en relation avec la figure 5, les étapes principales d'un algorithme de détermination d'un chemin de transmission de c0 entre le serveur de flot multimédia 110 et le terminal client 120 selon un mode de réalisation de l'invention. Cet algorithme est mis en oeuvre par le QosManager 150 dans le cadre de l'étape 410 de la figure 4 précédemment décrite. Lors d'une étape 510, le QosManager 150 obtient les adresses IP du serveur de flot multimédia 110 et du terminal client 120 du flot du contenu c0 (spécifié dans le message reçu à l'étape 400 du procédé de la figure 4). Lors d'une étape 520, le QosManager 150 obtient à partir de ces adresses IP, leurs adresses MAC Ethernet équivalentes, qui permettront par la suite de déterminer le chemin de transmission de niveau 2 du contenu c0 depuis le serveur de flot multimédia 110 et le terminal client 120. Lors d'une étape 530, le QosManager 150 détermine le chemin de transmission de c0 à l'aide de l'algorithme Spanning Tree tel que spécifié par la norme IEEE 802.1D. Lors d'une étape 540, à l'aide des résultats de lors de l'étape 490 précitée (permettant de détecter tous les équipements QosDevice du réseau), le QosManager 150 recherche dans le chemin de transmission de c0 chaque équipement implémentant le standard UPnP QoS (par comparaison entre les adresses MAC d'un équipement du chemin avec l'adresse MAC de chaque équipement QosDevice). Une fois identifiés les équipements QosDevice présents sur le chemin, à l'étape 550, le QosManager procède à l'identification des équipements n'implémentant pas le standard UPnP QoS. Conformément à l'invention, préférentiellement, on ne recherchera pas à créer un chemin directement avec les informations reçues du standard UPnP QoS, car cela pourrait conduire à plusieurs chemins théoriques. La norme 802.1D prévoit cette hypothèse et l'algorithme Spanning Tree reflète toujours le chemin réel emprunté par le flot multimédia. Le chemin résultant de ces opérations est une liste d'équipements identifiés par leurs adresses MAC, dont ceux supportant le service UPnP QosDevice sont marqués (selon une variante, on peut aussi distinguer ceux ne supportant pas l'invention tel que précédemment expliqué en relation avec la figure 4). On illustre, en relation avec la figure 6, les étapes principales du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par le pont 140A (conforme au protocole UPnP QoS), lors de la transmission de c0 du serveur de flot multimédia 110 vers le terminal client 120 suite à une requête du QosManager 150. Dans une étape 600, le service UPnP QosDevice du pont 140A reçoit une requête, provenant du QosManager 150, d'établissement d'une transmission avec QoS (cette requête est par exemple un message QD_SetupTrafficQos ) du contenu c0 du serveur de flot multimédia 110 vers le terminal client 120. Le standard UPnP QoS précise que la requête contient notamment une indication sur les caractéristiques (notamment sa structure XML TrafficDesriptor, ou sa structure Tspec) du flot du contenu c0 à transmettre, qui correspondent à celles reçues par le QosManager 150 en provenance du poste de contrôle 130. Dans une étape 610, suite à cette requête, le pont 140A met en place les procédures classiques pour valider et préparer les ressources locales à la mise en place de la politique QoS. Par d'exemple, si le flot multimédia du contenu c0 présente des contraintes d'acheminement fortes, alors une réservation de ressources peut consister à offrir une priorité pour ce flot en regard des autres flots en cours de transferts. Pour cela, le pont 140A modifie dynamiquement l'allocation des priorités des FIFO de ses ports d'entrée et de sortie relatifs au chemin de transmission du contenu c0. Au niveau des ressources locales, on utilise dans le cadre de la présente invention les techniques classiques de mise en place de QoS. En effet, il existe un grand nombre de méthodes de l'état de l'art précisant la relation entre les caractéristiques d'un flot et les priorités à appliquer sur les ports d'un équipement de commutation. Dans une étape 620, le pont 140A vérifie si l'admission du flot c0 a été effectuée avec succès. En cas d'échec de l'admission du flot, dans une étape 660, le pont 140A transmet au QosManager 150 un message d'erreur relatif à la réservation de ressource pour la transmission de c0. Ainsi, le résultat de la requête de réservation est retourné au QosManager 150 comme précisé dans le standard UPnP QoS. Un échec de l'étape 610 peut être par exemple dû à une insuffisance de ressources disponibles (par exemple lorsque trop de flots sont réservés dans ce pont 140A). D'autre part, un message d'erreur peut également être transmis au QosManager 150 par le pont 140A lors de l'occurrence d'une double réservation de ressource pour la transmission d'un même contenu. En cas de succès de l'admission du flot, dans une étape 630, le pont 140A vérifie s'il a reçu, en provenance du QosManager 150, une demande d'envoi, à un dispositif non conforme au protocole UPnP QoS mais conforme au protocole SBM tel que le commutateur 104B, d'une requête de réservation de ressource conforme au protocole SBM (tel qu'indiqué ci-dessus en relation avec la figure 4). S'il a reçu une telle demande, alors le pont 140A est un dispositif de transition au sens de la présente invention vis-à-vis du commutateur 140B par exemple. Ainsi, si le pont 140A n'est pas un dispositif de transition au sens de la présente invention, alors un rapport positif est retourné par l'étape 660, confirmant que les ressources locales ont été mises en place correctement. Au contraire, si le pont 140A est un dispositif de transition au sens de la présente invention, alors, dans une étape 640, le pont 140A envoie une requête de réservation de ressource conforme au protocole SBM (construite à partir des spécifications du flot multimédia et ci-après désignée par requête SBM) au commutateur 140B. Puis, dans une étape 650, le pont 140A attend la confirmation SBM à cette requête. Puis dans l'étape 660, le pont 140A confirme au QosManager 150 la réservation de ressource conforme au protocole SBM pour la transmission de c0. En option, lorsque le flot c0 ne comporte pas de caractéristique suffisamment critique pour nécessiter une réservation de ressource, et en accord avec la politique de qualité de service en vigueur sur le réseau, le pont 140A peut mettre en oeuvre une autre technique pour indiquer aux équipements de type 140B la manière de gérer le flot c0. Par exemple, le pont 140A peut enregistrer les caractéristiques du flot (adresses IP et ports utilisés) afin, lors de la détection de paquets de ce flot, d'estampiller ces paquets selon une priorité choisie (par exemple en application de la norme IEEE 802.1Q). On illustre, en relation avec les figures 7A et 7B, un algorithme comprenant les étapes du procédé de réservation de ressource selon un mode de réalisation de l'invention, mises en oeuvre par le pont 140A (conforme au protocole UPnP QoS et au protocole SBM), lors de la réception de messages provenant du réseau local 100 relatifs aux protocoles UPnP QoS ou SBM. Le pont 140A conforme à l'invention doit au préalable (par exemple lors de son initialisation) mettre en place les actions nécessaires au bon déroulement du protocole SBM. Ainsi, par exemple, lors de l'initialisation, le pont 140A : participe à l'élection du responsable DSBM sur les différents segments connectés du réseau local 100, en accord avec la norme SBM ; - se déclare sur le réseau UPnP comme supportant un service QosDevice (de manière classique selon la norme UPnP QoS). Puis, comme pour chaque équipement de commutation classique, une gestion des flots réservés en cours doit être effectuée par le pont 140A. Les protocoles SBM et UPnP QoS sont tous les deux basés sur une description du flot selon un typage token-bucket , ce qui facilite les correspondances entre ces deux protocoles. De manière préférentielle, un objet Tspec tel que définit dans le protocole RFC-2215 est associé à chaque flot multimédia requérant des ressources QoS. Selon une mise en oeuvre particulière de l'invention, deux étiquettes nommées SBM_flag et UPnP_flag sont associées à chaque objet Tspec, et une liste de ces trois éléments est régulièrement mise à jour comme décrit ci-après. Cette liste peut indifféremment être stockée dans une mémoire vive, ou à accès rapide de type flash du pont 140A. Préférentiellement, cette liste comprend des sous-listes dont l'une 10 correspond aux flots validés et l'autre correspond aux flots en attente de validation par le système local. On présente ci-après une liste des valeurs que peuvent prendre les étiquettes SBM_flag et UPnP_flag. L'étiquette SBM_flag peut prendre les valeurs suivantes : 15 - valeur 0 si la QoS pour le flot est gérée par protocole SBM ; valeur 1 si la QoS pour le flot est gérée par le protocole SBM sur le port d'entrée relatif au flot du dispositif commutateur local (le pont 140A) ; valeur 2 si le dispositif local (pont 140A) a initié une réservation SBM sur le port de sortie relatif au flot ; 20 - valeur 3 si le dispositif local (pont 140A) a initié une réservation SBM sur le port de sortie relatif au flot, et si la QoS de ce flot est contrôlée par le protocole SBM sur un port d'entrée du pont 140A. L'étiquette UPnP_flag peut prendre les valeurs suivantes : valeur 0 si la QoS pour le flot n'est pas contrôlée par le protocole UPnP 25 QoS ; valeur 1 si la QoS pour le flot est contrôlée par le protocole UPnP QoS. Dans une étape 700, le pont 140A vérifie si le message reçu est un message conforme au protocole UPnP QoS. Si le message reçu n'est pas un message conforme au protocole UPnP 30 QoS, alors dans une étape 720, le pont 140A vérifie s'il s'agit d'un message conforme au protocole SBM. S'il ne s'agit pas d'un message conforme au protocole SBM, alors il est mis fin à l'algorithme dans une étape 790. S'il s'agit d'un message conforme au protocole SBM, l'algorithme se poursuit (cf. A) tel qu'indiqué ci-après notamment en relation avec l'étape 730. S'il s'agit d'un message UPnP QoS relatif à l'interface offerte au QosManager 150, alors dans une étape 701, le pont 140A vérifie si le message reçu est une commande du QosManager 150 demandant la réservation de ressources QoS pour un contenu donné (par exemple le contenu cO). Il s'agit notamment du message QD_SetupTrafficQoS décrit à l'étape 440 précitée en relation avec la figure 4. Si le message reçu est une commande du QosManager 150 demandant la réservation de ressources QoS pour le contenu cO, alors les étapes 702 à 708 sont mises en oeuvre. Ainsi, pour le contenu spécifié par le message QD_SetupTrafficQos (par exemple le contenu cO), dans l'étape 702, le pont 140A vérifie s'il est demandé d'effectuer une réservation de ressource de type SBM en plus des actions UPnP habituelles. Cette étape correspond à l'étape 630 précitée en relation avec la figure 6. S'il est demandé d'effectuer une réservation de ressource de type SBM, dans l'étape 706, le pont 140A envoie une requête PATH en direction de la machine 120 (donc sur le port de sortie qu'empruntera le contenu cO). Ce message permet de faire en sorte que les équipements non conformes au protocole UPnP QoS admettent cO dans leur liste de réservation de ressources. Dans une étape 706a, le pont 140A vérifie si l'étiquette SBM_flag de cO possède la valeur 1 (un objet Tspec étant associé au contenu cO). Si l'étiquette SBM_flag de cO possède la valeur 1, dans une étape 706b, le contenu cO est tamponné avec les étiquettes UPnP_flag à 1 et SIM_flag à 3. Si l'étiquette SBM_flag de cO ne possède pas la valeur 1, dans une étape 706c, le contenu cO est tamponné avec les étiquettes UPnP_flag à 1 et SBM_flag à . La valeur 2 de l'étiquette SBM_flag indique que c0 à été demandé par le protocole UPnP QoS avec une initiation de réservation SBM pour un flux nouveau, alors que la valeur 3 indique que c0 était déjà connu du côté du port d'entrée du pont 140A et qu'une réservation est lancée sur le port de sortie du pont 140A. Ensuite, les ressources locales sont vérifiées par le pont 140A dans l'étape 707 afin d'appliquer la mise en place de la politique QoS locale pour le contenu c0. Selon une variante conforme à l'invention de ce mode de réalisation, la disponibilité des ressources locales est vérifiée avant la gestion par le protocole SBM des autres machines (ceci correspond au fait que l'étape 707 est mise en oeuvre avant l'étape 706). En cas de succès, dans une étape 708, les caractéristiques du flot multimédia (Tspec, SBM_flag, UPnP_flag) sont stockées dans la liste des flots en cours d'admission (la réponse SBM RESV n'a pas encore été reçue). Dans l'étape 702, s'il n'est pas demandé d'effectuer une réservation de ressource de type SBM, dans l'étape 703, le pont 140A vérifie si la valeur de l'étiquette SBM_flag de c0 est non nulle (un objet Tspec étant associé au contenu c0) c'est-à-dire si c0 est déjà connu localement comme étant conforme au protocole SBM. On peut noter que le fait que l'étiquette SBM_flag soit non nulle équivaut à avoir reçu la description de ce contenu préalablement par un message SBM PATH, par exemple dans le cas d'un équipement 140A placé entre un équipement 140B et le dispositif récepteur 120. Dans le cas où l'étiquette SBM_flag de c0 est nulle, l'étape 705 ci-après décrite est directement mise en oeuvre. Dans le cas où l'étiquette SBM_flag de c0 est non nulle, dans une étape 704, une réponse de confirmation SBM RESV est envoyée en direction du dispositif source 110 dans le but d'être interceptée par le pont 140A ayant émis le message SBM PATH. 38 Ensuite, dans une étape 705, c0 est marqué comme étant connu par le protocole UPnP QoS. Ensuite l'étape 707 précitée est mise en œ uvre suivie par l'étape 708 précitée si ce n'est que les caractéristiques de c0 ('l'spec, SBM_flag, UPnP_flag) sont stockées non plus dans la liste des flots en cours d'admission, mais dans la liste des flots confirmés. Si le message reçu n'est pas une commande du QosManager 150 demandant la réservation de ressources QoS pour le contenu c0, alors, dans une étape 710, le pont 140A vérifie si le message reçu est une commande du QosManager 150 demandant la libération (ou relâche) de ressources QoS pour un flot multimédia donné (par exemple le contenu c0). Il s'agit notamment du message QD_ReleaseTrafficQoS spécifié par le standard UPnP QoS se rapportant au service QosDevice. Si ce n'est pas le cas, dans l'étape 790, il est mis fin à l'algorithme. Si le message reçu est une commande du QosManager 150 demandant la libération de ressources QoS pour c0 et si c0 est référencé comme étant conforme au protocole SBM (étape 711), dans une étape 712, le pont 140A envoie un message de libération des ressources distantes désigné par SBM TEARDOWN en direction du dispositif source 110, dans le but d'être capté par un autre dispositif sur le chemin de transmission de c0. Dans les étapes 713 et 714, les ressources locales sont libérées (étape 713) et les caractéristiques du flot sont supprimées des listes qui les contiennent (étape 714). On se place dans la suite dans le cas où le message reçu n'est pas un message conforme au protocole UPnP QoS, mais est un message conforme au protocole SBM. Dans une étape 730, le pont 140A vérifie si le message reçu est un message SBM PATH rapportant une demande de réservation de ressources. Si le message reçu est un tel message SBM PATH, alors dans une étape 731, le pont 140A vérifie si le flot (par exemple le contenu c0) concerné n'est pas déjà connu localement dans l'une des listes (un objet Tspec étant associé à co). Si c0 n'est pas connu, alors c0 est un nouveau flot commandé par le protocole SBM et, dans une étape 734, le pont 140A enregistre les paramètres Tspec de cO en conservant l'identification de sa provenance (l'étiquette SBM_flag est fixée à 1). Dans une étape 735, les ressources locales sont alors préparées pour cO de la même manière qu'à l'étape 707 précitée. Puis, il est mis fin à l'algorithme dans l'étape 790. Par contre, si cO est déjà référencé, dans une étape 732, le pont 140A vérifie si l'étiquette SBM_flag de cO présente la valeur 0 (c'est-à-dire vérifie si cO n'est pas référencé comme étant conforme au protocole SBM). Si la valeur de l'étiquette SBM_flag est 0, alors, dans une étape 733, le pont 140A met cette valeur à jour en remplaçant la valeur 0 par la valeur 1. Puis, il est mis fin à l'algorithme dans l'étape 790. En effet, les actions de réservation ont déjà été prises en compte car cO est déjà connu. Si la valeur de l'étiquette SBM_flag est non nulle, alors, dans une étape 736, le pont vérifie si la valeur de l'étiquette SBM_flag est 2 (initiation d'une réservation en direction du dispositif récepteur 120). Si la valeur de l'étiquette SBM_flag n'est pas égale à 2, alors, il est mis fin à l'algorithme dans l'étape 790. Si la valeur de l'étiquette SBM_flag est égale à 2, alors, dans une étape 737, le pont 140A met cette étiquette à jour (en remplaçant la valeur 2 par la valeur 3) pour se souvenir que le protocole SBM connaît aussi le flot sur le port d'entrée du commutateur. Puis, il est mis fin à l'algorithme dans l'étape 790. Selon une variante de l'invention, non représentée ici par souci de simplification, lorsque le QosDevice reçoit un message PATH pour l'établissement d'un flot concernant le contenu cO selon le protocole SBM, il vérifie si le flot concerné n'est pas déjà connu localement dans l'une des listes. Si le flot concerné a déjà fait l'objet d'une requête de réservation selon le protocole UPnP QoS, les ressources nécessaires à l'établissement du flot sont déjà réservées. Le QosDevice peut alors envoyer en retour du message PATH un message RESV indiquant que l'étape de réservation a été concluante. Le message PATH n'est alors pas propagé au(x) dispositif(s) en aval du QosDevice dans le sens de parcours de la requête de réservation. Ce message RESV sera alors retourné au dispositif en amont du QosDevice dans le sens de parcours de la requête de réservation. Ce message sera intercepté par le QosDevice qui était émetteur de la requête de réservation selon le protocole SBM sur demande du QosManager. Un rapport sur le résultat de l'allocation des ressources pourra alors être adressé au QosManager. Cette variante est mise en place quand le QosManager 150 a déterminé un équipement non compatible avec le protocole UPnP QoS sur le chemin entre l'équipement source et l'équipement récepteur du contenu c0, puis a sélectionné un QosDevice, dit équipement de transition sur ce chemin et a déterminé les QosDevices qui seront impactés par la requête de réservation de ressources conforme au protocole de signalisation en ligne. Comme déjà décrit, le QosManager 150 peut alors réordonner les requêtes de réservation de ressources et envoyer aux QosDevices, qui seront impactés par la requête de réservation en ligne, une requête de réservation de ressources QD_SetupTrafficQoS tel que spécifié par le standard UPnP QoS avant d'envoyer la requête au dispositif de transition. Ces QosDevices reçoivent ainsi une requête de réservation selon le protocole UPnP QoS avant de recevoir une requête de réservation selon le protocole SBM. Selon les figures 7A et 7B, si le message reçu n'est pas un message SBM PATH, alors dans une étape 740, le pont 140A vérifie s'il s'agit d'un message SBM TEARDOWN rapportant une demande d'annulation de réservation de ressources. Si le message reçu est un message SBM TEARDOWN, alors dans une étape 741, les actions classiques de libération des ressources QoS locales sont exécutées. Dans une étape 742, le pont 1.40A vérifie si la valeur de l'étiquette UPnP_flag est 0. Si la valeur de l'étiquette UPnP_flag n'est pas 0, alors, l'étape 744 ci-après décrite est directement mise en oeuvre. Si la valeur de l'étiquette UPnP_flag est 0, alors dans une étape 743, le pont 140A avertit le QosManager 150 de ce fait. Ensuite, dans une étape 744, les caractéristiques actuelles du contenu sont supprimées des listes. Ainsi, les étapes 742 à 744 permettent d'indiquer au service QosManager 150 toute modification d'un état du pont 140A courant. Ainsi, si le contenu à libérer est référencé comme étant conforme au protocole UPnP QoS (UPnP_flag à 1), l'étape 743 permet d'avertir le QosManager 150 du changement. Ceci permet au QosManager 150 : de localiser précisément une portion de segments non compatibles avec le protocole UPnP QoS dans laquelle il y a eu un problème, et, le cas échéant, de demander l'application d'autres caractéristiques moins sévères pour ce contenu ou de faire passer le contenu par un autre chemin de transmission. Cette notification peut être réalisée par exemple au moyen d'une variable d'événement QosState , dont la modification est aussitôt notifiée au service QosManager 150 selon le protocole GENA (pour General lEvent Notification Architecture ) utilisé par le protocole UPnP QoS. L'interface QD_GetQosState définie par UPnP QoS permet notamment d'indiquer les flots actifs sur le dispositif 140A, et sera appelée par le service QosManager 150 en réception de l'événement. Si le message reçu n'est ni message SBM PATH, ni un message SBM TEARDOWN,alors dans une étape 750, le pont 140A vérifie s'il s'agit d'un message SBM RESV rapportant une confirmation de réservation de ressources. S'il s'agit d'un message SBM RESV rapportant une confirmation de réservation de ressources, dans une étape 751, le pont 140A vérifie si le contenu est en cours de réservation. Si le contenu est totalement inconnu, alors l'algorithme ne prend pas en compte ce message puis, il est mis fin à l'algorithme (ce cas n'est pas représenté sur les figures 7A ou 7B). Lorsque les ressources pour le flot sont réservées (y compris le cas où l'on 30 reçoit ce message SBM RESV pour un flot déjà réservé pour lequel l'étape 751 précitée donne un résultat négatif), alors l'étape 755 ci-après décrite est mise en oeuvre. Le passage direct à l'étape 755 évite d'effectuer une nouvelle réservation des ressources en plus de celle déjà réalisée. Si le flot fait partie des flots en cours de réservation, il passe dans la catégorie/liste des flots acquittés dans une étape 752 : c'est-à-dire que les ressources locales préparées en vue de leur réservation en référence à l'étape 735 sont réellement mise en oeuvre pour la transmission du contenu c0. Dans une étape 753, le pont 140A vérifie si la valeur de l'étiquette UPnP_flag est 0, c'est-à-dire si le contenu est référencé comme étant compatible 10 au protocole UPnP QoS. Si la valeur de l'étiquette UPnP_flag n'est pas 0, alors, l'étape 755 ci-après décrite est directement mise en oeuvre. Si la valeur de l'étiquette UPnP_flag est 0, alors dans une étape 754, le pont 140A avertit le QosManager 150 de ce fait. Ensuite, dans l'étape 755, le pont 15 140A vérifie si le flot réservé est également connu sur le port d'entrée du pont 140A (c'est-à-dire si l'étiquette SBM_flag possède la valeur 3). Si l'étiquette SBM_flag ne possède pas la valeur 3, il est mis fin à l'algorithme dans l'étape 790. Si l'étiquette SBM_flag possède la valeur 3, dans une étape 756, le pont 20 140A autorise la propagation de la confirmation de réservation RESV en direction du dispositif source. Puis, il est mis fin à l'algorithme dans l'étape 790. Si le message reçu n'est ni message SBM PATH, ni un message SBM TEARDOWN, ni un message SBM RESV, alors il est mis fin à l'algorithme dans l'étape 790. 25 Ainsi, à partir de messages élémentaires conformes au protocole UPnP QoS, le procédé de réservation de ressource selon l'invention permet de conduire une réservation de ressource complémentaire envers des équipements non conformes au protocole UPnP QoS. 30 ANNEXE 1 kid> Bridge0 112233aabb03 ethl BridgeO 112233aabbO7 112233aabbO5 eth2 Bridge0 112233aabb02 112233aabbOl 112233aabbO4 eth3 Bridge0 ANNEXE 2 any-string 192.168.1.102 192.168.1.150 1 2 10000 20000 AV 2 3 6666 ANNEXE 3 POST /QosDevice/control HTTP/1.1 HOST: 172.20.3.123:50041 SOAPACTION: "urn:schemas-upnp- org:service:QosDevice:l#SetupTrafficQos" CONTENT-TYPE: text/xml ; charset="utf-8" Content-Length: 1157 any-string 192.168.1.104 24 2 10000 20000 Gaming 2&1t;/ActiveTspeclndex> 3 6666 true QosDevice-0000 REVENDICATIONS 1. Procédé de réservation de ressource dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source (110) et un dispositif récepteur (120) appartenant à un réseau de communication (100), ledit réseau comprenant : au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et - au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit procédé étant mis en oeuvre par un dispositif gestionnaire (150) qui est un dispositif dudit premier type, caractérisé en ce qu'il comprend les étapes suivantes : - détection de la présence, sur le chemin de transmission, d'au moins un dispositif du second type qui n'est pas compatible avec le protocole de signalisation centralisé ; détermination d'un dispositif de transition qui est un dispositif du premier type et qui est aussi compatible avec le protocole de signalisation en ligne ; envoi au dispositif de transition déterminé d'une demande d'envoi, audit ou auxdits dispositif(s) du second type détecté(s), d'une requête de réservation de ressource conforme au protocole de signalisation en ligne. 2. Procédé de réservation selon la revendication 1, caractérisé en ce qu'il comprend également l'étape suivante : - sélection sur le chemin de transmission d'un dispositif de transition commun pour au moins deux dispositifs du second type détectés. 3. Procédé de réservation selon la revendication 1, caractérisé en ce qu'il comprend également l'étape suivante : pour chaque dispositif du second type détecté, sélection sur le chemin de transmission d'un dispositif de transition distinct. 4. Procédé de réservation selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend également l'étape suivante :-détermination du ou desdits dispositifs du premier type qui tiennent compte de la requête de réservation de ressource conforme au protocole de signalisation en ligne initiée par le dispositif de transition. 5. Procédé de réservation selon la revendication 4, caractérisé en ce qu'il comprend également l'étape suivante : - envoi à au moins un du ou desdits dispositifs de premier type qui tiennent compte de la requête de réservation de ressource conforme au protocole de signalisation en ligne d'une requête de réservation de ressource conforme au protocole de signalisation centralisée, préalablement à la demande d'envoi au dispositif de transition d'une requête de réservation de ressource conforme au protocole de signalisation en ligne. 6. Procédé de réservation selon la revendication 4, caractérisé en ce qu'il ne comprend pas d'étape d'envoi au(x) dispositif(s) de premier type qui tien(nen)t compte de la requête de réservation de ressource conforme au protocole de signalisation en ligne d'une requête de réservation de ressource conforme au protocole de signalisation centralisée. 7. Procédé de réservation selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend également une étape initiale de réception par le dispositif gestionnaire (150) d'une requête de transmission avec qualité de service du contenu du dispositif source vers le dispositif récepteur. 8. Procédé de réservation selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comprend également une étape de réception d'un rapport provenant du ou desdits dispositif(s) de transition indiquant la réussite ou l'échec de la réservation de ressource pour la transmission du contenu. 9. Procédé de réservation de ressource dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source (110) et un dispositif récepteur (120) appartenant à un réseau de communication (100), ledit réseau comprenant : au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et- au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit procédé étant mis en oeuvre par un dispositif de transition, qui est un dispositif dudit premier type et qui est aussi compatible avec le protocole de signalisation en ligne, caractérisé en ce qu'il comprend les étapes suivantes : réception d'une demande d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne à un dispositif dudit second type, situé sur le chemin de transmission et qui est non compatible avec le protocole de signalisation centralisé ; envoi de ladite requête audit dispositif du second type. 10. Procédé de réservation selon la revendication 9, caractérisé en ce que la demande d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne est incluse dans un message de demande de réservation de ressource conforme au protocole de signalisation centralisée. 11. Procédé de réservation selon l'une quelconque des revendications 9 et 10, caractérisé en ce qu'il comprend également les étapes suivantes : réception d'une confirmation de réservation de ressource conforme au protocole de signalisation en ligne ; - détermination si la confirmation de réservation de ressource correspond à une demande préalable d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne par un dispositif gestionnaire (150) ; dans l'affirmative, transmission au dispositif gestionnaire (150) d'un rapport positif concernant la réservation de ressource pour la transmission du contenu. 12. Procédé de réservation selon la revendication 11, caractérisé en ce que, si la confirmation de réservation de ressource correspond à une demande préalable d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne par un dispositif gestionnaire (150), le procédé deréservation ne comprend pas d'étape d'envoi de ladite confirmation de réservation de ressource vers d'autres dispositifs en amont du dispositif de transition dans le sens de parcours de la requête de réservation sur le chemin entre le dispositif source (110) et le dispositif récepteur (120). 13. Procédé de réservation selon l'une quelconque des revendications 9 à 12, caractérisé en ce qu'il comprend également les étapes suivantes : réception d'une demande de réservation de ressource conforme au protocole de signalisation en ligne ; - détermination si la demande de réservation de ressource conforme au protocole de signalisation en ligne correspond à un contenu pour lequel une demande de réservation de ressource conforme au protocole de signalisation centralisée par un dispositif gestionnaire a déjà été reçue dans l'affirmative, le procédé de réservation ne comprend pas d'étape d'envoi de la demande de réservation de ressource conforme au protocole de signalisation en ligne vers les dispositifs en aval du dispositif de transition dans le sens de parcours de la requête de réservation sur le chemin entre le dispositif source (110) et le dispositif récepteur (120). 14. Procédé de réservation selon la revendication 13, caractérisé en ce que, si la demande de réservation de ressource conforme au protocole de signalisation en ligne correspond à un contenu pour lequel une demande de réservation de ressource conforme au protocole de signalisation centralisée par un dispositif gestionnaire (150) a déjà été reçue, le procédé comprend également l'envoi d'un rapport positif concernant la demande de réservation de ressource conforme au protocole de signalisation en ligne. 15. Procédé de réservation selon l'une quelconque des revendications 9 à 14, caractérisé en ce qu'il comprend également les étapes suivantes : réception d'une demande de libération de ressource conforme au protocole de signalisation centralisée ; détermination si la demande de libération de ressource correspond à un contenu pour lequel une demande de réservation de ressource conforme auprotocole de signalisation en ligne par un dispositif gestionnaire (150) a été préalablement reçue pour au moins un dispositif du second type - dans l'affirmative, envoi d'une demande de libération de ressource conforme au protocole de signalisation en ligne audit au moins un dispositif du second type. 16. Procédé de réservation selon l'une quelconque des revendications 1 à 15, caractérisé en ce que le protocole de signalisation centralisée est le protocole UPnP et en ce que le protocole de signalisation en ligne est le protocole SBM. 17. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé de réservation selon l'une quelconque des revendications 1 à 8 et/ou 9 à 16, lorsque ledit programme est exécuté sur un ordinateur. 18. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de réservation selon l'une quelconque des revendications 1 à 8 et/ou 9 à 16. 19. Dispositif gestionnaire apte à réserver les ressources de dispositifs d'un réseau de communication, à l'aide d'un protocole de signalisation centralisé, dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source (110) et un dispositif récepteur (120) à travers ledit réseau de communication (100), ledit réseau comprenant : au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et - au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit dispositif gestionnaire (150) étant un dispositif dudit premier type, caractérisé en ce que le dispositif gestionnaire comprend : des moyens de détection d'au moins un dispositif du second type compris sur le chemin de transmission et qui n'est pas compatible avec leprotocole de signalisation centralisé; des moyens de détermination d'un dispositif de transition qui est un dispositif du premier type et qui est compatible avec le protocole de signalisation en ligne ; et - des moyens d'envoi au dispositif de transition d'une demande d'envoi audit ou auxdits dispositif(s) du second type détectés d'une requête de réservation de ressource conforme au protocole de signalisation en ligne. 20. Dispositif gestionnaire selon la revendication 19, caractérisé en ce qu'il comprend également : des moyens de sélection, sur le chemin de transmission, d'un dispositif de transition commun pour au moins deux dispositifs du second type détectés. 21. Dispositif gestionnaire selon la revendication 19, caractérisé en ce qu'il comprend également : des moyens de sélection, sur le chemin de transmission, d'un dispositif de transition distinct pour chaque dispositif du second type détecté. 22. Dispositif gestionnaire selon l'une quelconque des revendications 19 à 21, caractérisé en ce qu'il comprend également des moyens de réception d'un rapport provenant du ou desdits dispositif(s) de transition indiquant la réussite ou l'échec de la réservation de ressource pour la transmission du contenu. 23. Dispositif de transition apte à réserver les ressources de dispositifs d'un réseau de communication, à l'aide d'un protocole de signalisation centralisé, dans le cadre de la transmission d'un contenu de données sur un chemin de transmission entre un dispositif source (110) et un dispositif récepteur (120) à travers ledit réseau de communication (100), ledit réseau comprenant : au moins un dispositif compatible avec un protocole de signalisation centralisée, dit dispositif d'un premier type ; et au moins un dispositif compatible avec un protocole de signalisation en ligne, dit dispositif d'un second type, ledit dispositif de transition étant un dispositif dudit premier type, et qui est aussicompatible avec le protocole de signalisation en ligne, caractérisé en ce qu'il comprend : -des moyens de réception d'une demande d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne à un dispositif dudit second type, situé sur le chemin de transmission et qui est non compatible avec le protocole de signalisation centralisé ; des moyens d'envoi de ladite requête audit dispositif du second type. 24. Dispositif de transition selon la revendication 23, caractérisé en ce qu'il comprend également : - des moyens de réception d'une confirmation de réservation de ressource conforme au protocole de signalisation en ligne ; des moyens de détermination si la confirmation de réservation de ressource correspond à une demande préalable d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne par un dispositif gestionnaire (150) ; - des moyens de transmission au dispositif gestionnaire (150) d'un rapport positif concernant la réservation de ressource pour la transmission du contenu, lesdits moyens de transmission étant activés si la confirmation de réservation de ressource correspond à une demande préalable d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne par un dispositif gestionnaire (150). 25. Dispositif de transition selon la revendication 24, caractérisé en ce que, si la confirmation de réservation de ressource correspond à une demande préalable d'envoi d'une requête de réservation de ressource conforme au protocole de signalisation en ligne par un dispositif gestionnaire (150), le dispositif de transition n'active pas de moyens d'envoi de ladite confirmation de réservation de ressource vers d'autres dispositifs en amont du dispositif de transition dans le sens de parcours de la requête de réservation sur le chemin entre le dispositif source (110) et le dispositif récepteur (120). 26. Dispositif de transition selon l'une quelconque des revendications 23 à 25,caractérisé en ce qu'il comprend également : des moyens de réception d'une demande de réservation de ressource conforme au protocole de signalisation en ligne ; des moyens de détermination si la demande de réservation de ressource conforme au protocole de signalisation en ligne correspond à un contenu pour lequel une demande de réservation de ressource conforme au protocole de signalisation centralisée par un dispositif gestionnaire (150) a déjà été reçue ; - des moyens d'envoi de la demande de réservation de ressource conforme au protocole de signalisation en ligne vers les dispositifs en aval du dispositif de transition dans le sens de parcours de la requête de réservation sur le chemin entre le dispositif source (110) et le dispositif récepteur (120), lesdits moyens d'envoi n'étant pas activés si la demande de réservation de ressource conforme au protocole de signalisation en ligne correspond à un contenu pour lequel une demande de réservation de ressource conforme au protocole de signalisation centralisée par un dispositif gestionnaire (150) a déjà été reçue.