Brevet FR2889012A1 — publié le 20070126

L'invention concerne les réseaux de communication à coeur de réseau de type IP (c'est-à-dire les réseaux IP de bout en bout dans lesquels l'usager dispose d'un lien IP (pour Internet Protocol ), et les réseaux disposant d'un coeur de réseau de type IP auquel on accède par une autre technologie via une passerelle), comme par exemple les réseaux de type IMS (pour IP Multimedia Subsystem ) ou NGN (pour New (or Next) Generation Network ), et plus particulièrement l'accès de terminaux de communication à des services comportant au moins une partie média et mis à la disposition de leurs utilisateurs par de tels réseaux. Comme le sait l'homme de l'art, lorsqu'un terminal de communication doit accéder à un service comportant au moins une partie média, à l'initiative de son utilisateur ou du coeur de réseau, il doit transmettre au réseau dont il est client une demande d'accès audit service. Par exemple, lorsque le message est conforme au protocole d'établissement de communication SIP (pour Session Initiation Protocol - protocole d'initiation de session), qui permet de créer et gérer des sessions d'échange de données (sous toute forme), notamment interactives et en temps réel, entre équipements, indépendamment de la nature des données et du protocole de transport utilisé pour transporter lesdites données, il se présente sous la forme d'un message d'établissement d'appel SIP de type SIP INVITE . II est rappelé qu'un message INVITE contient un SDP décrivant les différents médias que supporte un terminal appelant, et que consécutivement à la réception de ce message INVITE s'effectue une négociation entre équipements pour déterminer le ou les médias qui seront utilisés pendant la session. Lorsque le réseau reçoit la demande, il la route vers le (ou l'un des) serveur(s) d'applications (ou application server(s) ) dédié(s) (au moins) à ce service, c'est-à- dire chargé de gérer et contrôler la fourniture du service demandé au terminal demandeur. Chaque service comportant au moins une partie média doit utiliser au moins un ensemble de fonctions média assurées par un (ou des) serveurs média (ou media server(s) ) pour assurer cette partie média. Un tel ensemble est également appelé capacité (ou capability ). Chaque serveur média dispose d'un certain nombre de ressources (ou canaux) pour assurer sa ou ses capacités. Lorsqu'un serveur d'applications reçoit une demande d'accès à un service comportant au moins une partie média, il doit solliciter (immédiatement ou au cours de la session) au moins un serveur média capable d'assurer les fonctions média de l'ensemble correspondant à cette partie média. Or, cela peut s'avérer impossible dans certaines circonstances. En effet, les serveurs d'applications actuels ne pouvant pas nativement interfacer les serveurs média qui n'ont pas été conçus par leur propre fabricant, ils ne sont donc pas capables d'utiliser nativement n'importe quelle capacité assurée par n'importe quel serveur média. Pour qu'un serveur d'applications puisse interfacer un serveur média particulier (d'un autre fabricant), afin d'utiliser ses capacités et contrôler les traitements média qu'il effectue, il doit alors faire l'objet d'aménagements (ou adaptations) spécifiques. En d'autres termes, soit tous les serveurs d'applications et tous les serveurs média doivent io être regroupés au sein d'une même plateforme, soit chaque fabricant doit concevoir ses propres interfaces d'adaptation, lesquelles doivent être mises à jour chaque fois qu'un nouveau serveur média apparaît et doit être utilisé avec ses serveurs d'applications. Par ailleurs, pour porter la partie média d'un serveur d'applications, initialement conçue pour les réseaux de type IN (pour Intelligent Network ), vers des réseaux de type NGM ou IMS, il faut réécrire complètement cette partie média. En outre, il n'existe pas de mécanisme permettant de rendre transparent pour les serveurs d'applications l'état de disponibilité des ressources des serveurs média. De ce fait, il n'est pas possible d'assigner des priorités d'utilisation de ressources en fonction du type d'application concerné et/ou du type d'appel demandé et/ou d'une éventuelle répartition contractuelle des ressources (ou multi-tenancy ) de certains serveurs média entre clients. L'invention a donc pour but de remédier à tout ou partie des inconvénients précités. Elle propose à cet effet un dispositif dédié à la gestion des ressources de serveurs média, d'un réseau de communication, destinés à offrir à des terminaux de communication clients, requérant des services (comportant au moins une partie média) gérés par des serveurs d'applications, des ensembles de fonctions média (ou capacités) propres à assurer les parties média desdits services requis. Ce dispositif de gestion se caractérise par le fait qu'il comprend: - des moyens de mémorisation chargés de stocker des données représentatives d'ensembles de fonctions média en correspondance d'identifiants de serveurs média, et - des moyens de gestion chargés, lorsqu'ils reçoivent un message provenant d'un serveur d'applications dédié à un service requis par un terminal client et requérant la mise à disposition de ce dernier d'un ensemble de fonctions média propre à assurer une partie média du service requis, de déterminer dans les données stockées par les moyens de mémorisation (au moyen d'une stratégie adaptée, sur laquelle l'exploitant du réseau peut intervenir) l'identifiant d'un serveur média disposant de ressources pour offrir l'ensemble requis, puis d'allouer des ressources du serveur média déterminé afin que le message puisse lui être transmis. Le dispositif selon l'invention peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment: - ses moyens de mémorisation peuvent être agencés pour stocker des données auxiliaires représentatives d'états de disponibilité des ressources des serveurs média et/ou du dimensionnement des serveurs média en fonction des données représentatives des ensembles de fonctions média et des identifiants des serveurs média; - ses moyens de gestion peuvent être chargés de procéder à l'allocation des ressources des serveurs média en fonction des données auxiliaires et/ou d'informations de gestion (par exemple relatives à des priorités et/ou une stratégie d'exploitation et/ou des contraintes géographiques et/ou des répartitions géographiques de serveurs média et/ou d'une qualité de service (QoS) et/ou de l'architecture du réseau (taille des canaux) et/ou de la qualité ou de l'état du réseau à un instant donné) ; - ses moyens de mémorisation peuvent être agencés de manière à être mis à jour dynamiquement, par exemple par les moyens de gestion lorsqu'ils reçoivent, éventuellement des serveurs média, des données d'information représentatives des ensembles offerts par les serveurs média et/ou des ressources disponibles correspondantes; - il peut comprendre, d'une part, une interface d'entrée chargée de recevoir des serveurs d'applications des messages conformes à un premier protocole et de transmettre ces messages aux moyens de gestion, et d'autre part, une interface de sortie chargée de transmettre aux serveurs média des messages communiqués par les moyens de gestion et qui leurs sont destinés; - l'interface de sortie peut par exemple être chargée de convertir des messages conformes au premier protocole en messages conformes à au moins un second protocole, avant de les transmettre aux serveurs média destinataires; - par exemple, le premier protocole est le protocole SIP, encapsulant éventuellement un protocole de type AMSML (pour Alcatel (ou Application) Media Server Markup Language ) ; - le second protocole peut par exemple être choisi parmi le protocole SIP encapsulant un protocole de type XML (MSMUMOML ou MSCML) et un protocole de type H248; il peut être associé à une adresse flottante, de manière à permettre une redondance utile en cas de défaillance. Dans ce cas, les moyens de mémorisation peuvent être partagés par plusieurs moyens de gestion et leur accès peut être sécurisé. L'invention propose également un équipement de réseau équipé d'un dispositif de gestion du type de celui présenté ci-avant. Un tel équipement peut par exemple assurer une fonction proxy particulière d'allocation, notamment lorsque le premier protocole est SIP/AMSML. Dans les autres cas, il peut constituer une machine d'états. L'invention est particulièrement bien adaptée, bien que de façon non exclusive, aux réseaux de communication de type Internet, NGN ou IMS. D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels: la figure 1 illustre de façon très schématique un coeur de réseau IP auquel sont connectés des serveurs d'applications, des serveurs média, ainsi qu'un exemple de réalisation d'un dispositif de gestion selon l'invention, et la figure 2 est un diagramme illustrant les principales étapes nécessaires à l'établissement et au contrôle d'une communication média entre un terminal de communication et un serveur média, selon l'invention. Les dessins annexés pourront non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, le cas échéant. L'invention a pour objet de permettre un interfaçage standard, au moyen d'un dispositif de gestion de ressources, entre la couche de contrôle d'application dans les serveurs d'applications et la couche de plan d'utilisateur dans les serveurs média, au sein d'un réseau de communication comportant un coeur de réseau de type IP ( Internet Protocol ). Elle a également pour objet de cacher aux serveurs d'applications l'organisation physique des serveurs média dans le réseau (adresses, capacités et dimensionnements). Dans ce qui suit, on considère à titre d'exemple non limitatif que le réseau de communication est un réseau de type NGN ou IMS. Mais, l'invention n'est pas limitée à ce type de réseau. Elle concerne en effet tous les réseaux de communication comportant (ou couplés à) un coeur de réseau de type IP, et notamment les réseaux PSTN et PLMN (dès lors qu'ils comprennent un coeur de réseau IP). On se réfère tout d'abord à la figure 1 pour décrire un dispositif de gestion de ressources D, selon l'invention. Comme cela est très schématiquement illustré sur la figure 1, au moins un serveur d'applications ASi et au moins un serveur média MSj peuvent être couplés à un coeur de réseau (ici de type NGN ou IMS) CR. Dans l'exemple non limitatif illustré, d'une part, l'indice i est égal à 1 ou 2, mais il peut prendre n'importe quelle valeur non nulle, et d'autre part, l'indice j est égal à 1, 2 ou 3, mais il peut prendre n'importe quelle valeur non nulle. II est important de noter que la figure 1 ne reflète pas l'organisation physique des modules fonctionnels représentés (serveurs d'applications ASi, serveurs média MSj et dispositif D). En effet, on peut envisager qu'une partie au moins des serveurs média MSj et le dispositif D soient implantés physiquement dans un même équipement. On peut également envisager qu'une partie au moins des serveurs d'applications soit implantée dans le coeur de réseau CR, par exemple dans un commutateur logiciel (ou softswitch ). Chaque serveur d'applications (ou application server ) ASi est dédié à au moins un service comportant au moins une partie média, comme par exemple un service de pré- paiement, ou des services de type CMM (pour Corporate Mobility Manager - bureau virtuel permettant notamment d'accéder à des informations personnelles), messagerie, conférence, portail, kiosque, téléchargement de sonneries ou push to talk . II est par conséquent chargé de gérer et contrôler la fourniture à des terminaux de communication T demandeurs d'un service pour lequel il a été conçu. On entend ici par terminal de communication tout équipement de communication, radio ou filaire, fixe ou mobile (ou portable) capable de se connecter à au moins un réseau IP, éventuellement par l'intermédiaire de passerelle(s) (notamment lorsque l'utilisateur n'a pas conscience du fait qu'il accède à un coeur de réseau IP), afin d'échanger des données sous la forme de signaux avec un autre équipement. Il pourra donc s'agir, par exemple, d'un téléphone fixe ou mobile, ou d'un ordinateur fixe ou portable ou d'un assistant personnel numérique (ou PDA) équipé d'un module de communication, éventuellement sur IP. Par ailleurs, on entend ici par service comportant au moins une partie média tout service relatif, au moins en partie, à une communication ayant pour objet l'échange de flux de données média sous toute forme, comme par exemple des flux de voix (VoIP pour Voice over IP ), des flux vidéo ou des flux de textes (par exemple de type chat ). Il est important de noter que les flux peuvent être interactifs, en temps réel ou non. Chaque serveur média (ou media server ) MSj est conçu de manière à assurer au moins un ensemble (ou groupe) prédéfini de fonctions média, également appelé capacité, pouvant être utilisé par des serveurs d'applications ASi pour assurer une partie média d'un service. On entend ici par fonction média toute fonction relative à une communication média, comme par exemple (et de façon non exhaustive) une annonce audio ou vidéo basique, une session audio ou vidéo interactive (collection de DTMF), une conférence audio ad-hoc ou vidéo basique, une conférence audio ou vidéo étendue, un enchaînement de commandes XML média de type voix (ou audio voice XML scripting ), un enchaînement de commandes VXML média de type vidéo (ou video VXML scripting ), une synthèse vocale (ou te)d to speech ), ou une reconnaissance de paroles (ou speech recognition ). Selon l'invention, chaque ensemble (ou capacité) est défini de façon standardisée et univoque, et est associé à un unique identifiant d'ensemble. En d'autres termes, il ne peut exister plusieurs identifiants d'ensemble différents associés à des ensembles regroupant les mêmes fonctions média. Par conséquent, si des serveurs média sont conçus par des fabricants différents et assurent un ou plusieurs ensembles de fonctions identiques, ces ensembles identiques sont associés à des identifiants d'ensemble identiques. Les serveurs média MSj concernés par l'invention constituent en quelque sorte une base de capacités communes équivalentes, mise à la disposition des serveurs d'applications ASi. Par ailleurs, chaque serveur média MSj dispose d'un certain nombre de ressources (ou canaux) pour assurer chacune de ses capacités. On peut en effet trouver dans un même réseau des serveurs média MSj supportant les mêmes capacités, mais comportant des dimensionnements différents (nombres de ports différents). En outre, chaque serveur média MSj est préférentiellement agencé pour signaler au coeur de réseau CR chacune de ses capacités et l'état de disponibilité des ressources associées à chacune desdites capacités, ainsi qu'éventuellement des priorités d'utilisation de certaines au moins des ressources. Le dispositif de gestion de ressources D, selon l'invention, est destiné à assurer l'interface entre les serveurs d'applications ASi et les serveurs média MSj. II comprend à cet effet au moins des moyens de mémorisation BD et au moins un module de gestion MG. Les moyens de mémorisation BD sont chargés de stocker des données représentatives des différents ensembles de fonctions média de la base commune en correspondance des identifiants des serveurs média MSj et des états de disponibilité de leurs ressources. Par exemple, les données représentatives des ensembles de fonctions média sont les identifiants d'ensemble, et les identifiants des serveurs média MSj sont leurs adresses IP. Ces moyens de mémorisation BD peuvent être réalisés sous n'importe quelle forme, comme par exemple une mémoire ou une base de données (comme c'est le cas ci- après). On notera qu'en fonction des informations qu'elle contient la base de données peut être persistante et/ou redondante. Le module de gestion MG est couplé à la base de données BD et est chargé, chaque fois qu'il reçoit un message provenant d'un serveur d'applications ASi, dédié à un service comportant au moins une partie média et requis par un terminal (de communication) client T, et requérant la mise à disposition de ce dernier d'un ensemble de fonctions média correspondant à la partie média du service requis, de déterminer dans les données stockées par la base de données BD l'identifiant d'un serveur média MSj disposant de ressources pour offrir l'ensemble requis. Puis, une fois que le module de gestion MG a déterminé un serveur média MSj adapté au message reçu, il alloue certaines des ressources de ce serveur média MSj afin que le message reçu puisse lui être transmis et qu'il procède à l'établissement d'une communication avec le terminal client demandeur T en vue de l'échange de flux média (de type RTP) grâce à la mise en oeuvre des fonctions média de l'ensemble (ou capacité) désigné dans ledit message. II est important de noter que grâce à l'invention, le module de gestion MG peut disposer (par exemple dans la base de données BD) de données auxiliaires, comme par exemple l'état de disponibilité des ressources des serveurs média MSj et/ou leurs dimensionnements respectifs, si bien qu'il peut effectuer une gestion globale des ressources dont ils disposent. Pour allouer des ressources le module de gestion MG peut alors prendre en compte des informations de gestion (éventuellement stockées dans la base de données BD), par exemple relatives à des priorités (fonction du type d'application concerné et/ou du type d'appel demandé et/ou d'une éventuelle répartition contractuelle des ressources (ou multi-tenancy ) de certains serveurs média entre clients) et/ou une stratégie d'exploitation et/ou des contraintes géographiques et/ou des répartitions géographiques de serveurs média et/ou une qualité de service (QoS) et/ou l'architecture du réseau (taille des canaux) et/ou la qualité ou l'état du réseau à un instant donné. Préférentiellement, la mise à jour de la base de données BD s'effectue de façon dynamique. Par exemple, le module de gestion MG est chargé de mettre à jour la base de données BD chaque fois qu'il reçoit d'un serveur média MSj (par exemple périodiquement), via le coeur de réseau CR, des données d'information représentatives de son ou ses ensembles et/ou des données auxiliaires (ressources disponibles et/ou dimensionnements). Comme cela est illustré sur la figure 1, à titre d'exemple de réalisation non limitatif, le dispositif D peut comprendre une interface d'entrée IE et une interface de sortie IS, toutes les deux couplées à son module de gestion MG. L'interface d'entrée IE est chargée de recevoir des serveurs d'applications ASi, via le coeur de réseau CR, des messages conformes à un premier protocole et de transmettre ces messages au module de gestion MG, afin qu'il détermine les serveurs média MSj qui sont en mesure d'assurer les services média désignés dans ces messages. Par exemple, le premier protocole est le protocole SIP (pour Session Initiation Protocol ). En variante, le premier protocole peut être le protocole SIP encapsulant un protocole de type AMSML (pour Alcatel (ou Application) Media Server Markup Language ), décrit dans le document ALCATEL 3AT 33 634 AAAA PLZZA Ed 03 It7. L'interface de sortie IS est au moins chargée de transmettre aux serveurs média MSj, déterminés par le module de gestion MG, les messages qui sont communiqués par ce dernier et qui leurs sont destinés. Ces messages peuvent être soit conformes au premier protocole et dans ce cas l'interface de sortie IS n'assure qu'une fonction de distribution, soit conformes à au moins un second protocole et dans ce cas l'interface de sortie IS assure à la fois une fonction de conversion de protocole et une fonction de distribution. Dans ce dernier cas, et comme illustré, l'interface de sortie IS comporte un module de conversion chargé de convertir les messages, transmis par le module de gestion MG et conformes au premier protocole, en messages conformes à un second protocole choisi, compréhensible par les serveurs média MSj. Par exemple, le second protocole est le protocole SIP encapsulant un protocole de type XML (pour eXtended Markup Language ), ou bien un protocole de type H248. Le protocole encapsulé dans le protocole SIP permet à un serveur d'applications ASi de dialoguer avec un serveur média MSj afin de gérer et contrôler la communication média qu'il doit établir avec un terminal demandeur T, au moyen de commandes média dédiées. Selon le type de service requis par un terminal demandeur T, le dialogue peut être soit de type session et dans ce cas plusieurs commandes média dédiées peuvent être échangées, soit de type non-session et dans ce cas une commande média dédiée initiale et une éventuelle commande média dédiée finale peuvent être échangées. Bien que cela ne soit pas illustré sur la figure 1, le coeur de réseau CR peut être couplé soit à deux dispositifs de gestion de ressources D, selon l'invention, soit à un seul dispositif de gestion de ressources D, selon l'invention, comportant au moins deux modules de gestion MG et une base de données BD commune (ou partagée), afin de permettre une redondance utile en cas de défaillance de l'un d'entre eux ou de défaillance de la connexion reliant le coeur de réseau CR à l'un d'entre eux. Afin de pouvoir substituer rapidement l'un des dispositifs de gestion de ressources D par un autre, ou bien l'un des modules de gestion par un autre, on les associe préférentiellement à une adresse IP publique flottante. Ce type d'adresse flottante permet au coeur de réseau CR de router rapidement les messages provenant des serveurs d'applications ASi vers le dispositif de gestion D, ou le module de gestion MG, qui est en mode actif/attente ou qui peut être joint. Il est important de noter qu'en présence d'une base de données BD commune (ou partagée), son accès peut être sécurisé. Le dispositif de gestion D selon l'invention, et notamment son ou ses modules de gestion MG et ses moyens de mémorisation BD, peuvent être réalisés sous la forme de circuits électroniques, de modules logiciels (ou informatiques), ou d'une combinaison de circuits et de logiciels. Comme cela est illustré à titre d'exemple non limitatif sur la figure 1, le dispositif selon l'invention D peut par exemple être implanté dans un équipement de réseau IP SP sous la forme d'un module assurant une fonction proxy particulière d'allocation. On notera que dans une architecture 3GPP le dispositif D peut constituer un équipement io de type MRF-C, tandis que les serveurs média MSj peuvent constituer des équipements de type MRF-P (comme par exemple celui commercialisé par la société Alcatel sous la référence 8688 MRF 4.0). On se réfère maintenant à la figure 2 pour décrire, à titre d'exemple non limitatif, les principales étapes nécessaires à l'établissement et au contrôle d'une communication média entre un terminal client T et un serveur média MSj, selon l'invention. On considère dans ce qui suit que le protocole d'établissement de communication est le protocole SIP. Sur la figure 2, des messages SIP implicites, inutiles à la compréhension de l'invention, ont été omis afin de faciliter la lisibilité. Lorsqu'un terminal T doit accéder à un service particulier, à l'initiative de son utilisateur ou du coeur de réseau CR, il doit initier une session SIP avec l'application chargée de contrôler et gérer ce service. Pour ce faire, le terminal T transmet au coeur de réseau CR un message d'établissement d'appel, ici de type SIP INVITE (flèche F1). Lorsque le coeur de réseau CR reçoit ce message (SIP INVITE), il détermine un serveur d'applications AS1 dédié au service qu'il désigne, puis route le message reçu vers ce serveur d'applications AS1 (flèche F2). Lorsque le serveur d'applications AS1 reçoit le message (SIP INVITE), il peut éventuellement émettre via le coeur de réseau CR (flèche F3) et à destination du terminal demandeur T (flèche F4), un message, par exemple de type 100 TRYING , destiné à lui signaler qu'il a reçu le message (SIP INVITE), afin qu'il désarme certaines temporisations. Puis, le serveur d'applications AS1 détermine chaque capacité (ou l'ensemble de fonctions média) permettant d'assurer chaque partie média du service désigné dans le message reçu (SIP INVITE). II exécute la logique de service correspondant au service demandé, puis génère à destination du dispositif de gestion de ressources D (actif) un message de contrôle média, par exemple de type INVITE, comportant l'identifiant du terminal demandeur T et l'identifiant de la capacité (ou identifiant d'ensemble) qu'il a déterminé. Ce message de contrôle média (INVITE) est destiné à créer une session de contrôle de flux média. Le coeur de réseau CR route le message (INVITE) vers le dispositif de gestion de ressources D actif (flèche F5). A réception de ce message (INVITE), le module de gestion MG du dispositif D détermine l'identifiant d'ensemble qu'il contient, puis accède à la base de données BD pour déterminer l'identifiant d'un serveur média MSj disposant de ressources pour offrir l'ensemble (ou la capacité) requis(e). Puis, une fois que le module de gestion MG a déterminé un serveur média MS3 adapté au message reçu, il alloue des ressources (un canal) de ce serveur média MS3, et lui transmet, via le coeur de réseau CR, le message reçu, après avoir éventuellement converti son protocole d'établissement de communication (flèche F6). II est important de noter que cette allocation peut prendre en compte d'éventuelles données auxiliaires (états de disponibilité des ressources et/ou dimensionnements des serveurs média MSj) et/ou des informations de gestion, comme par exemple des priorités, comme indiqué précédemment. Lorsque le serveur média MS3 reçoit le message (INVITE), il génère à destination du serveur d'applications AS1, via le coeur de réseau CR, un message de réponse, par exemple de type 200 0K , signalant qu'il a bien reçu son message et qu'il va le prendre en compte (flèche F7). Le serveur média MS3 établit ensuite une communication directe, de type RTP, avec le terminal demandeur T désigné dans le message (INVITE) transmis par le dispositif D. Cette communication est bien entendu adaptée au service demandé et donc aux flux média que le serveur média MS3 et le terminal demandeur T doivent s'échanger grâce à la mise en oeuvre des fonctions média de l'ensemble désigné dans le message (INVITE) transmis par le dispositif D. Cet échange de flux média s'effectue indépendamment du dispositif D et du serveur d'applications AS1, bien que sous le contrôle de ce dernier. Dans l'exemple illustré sur la figure 2, le dialogue de contrôle média entre le serveur d'applications AS1 et le serveur média MS3 est de type session. Par conséquent, le serveur d'applications AS1 transmet au serveur média MS3, via le coeur de réseau CR, un message de requête standard, par exemple de type INFO , contenant une commande média lui demandant, par exemple, de transmettre au terminal demandeur T un message de bienvenue (flèche F9). A réception de ce message (INFO), le serveur média MS3 exécute la commande qu'il contient et transmet au serveur d'applications AS1, via le coeur de réseau CR, un message de réponse, par exemple de type INFO, pour lui signaler qu'il a bien exécuté sa commande (flèche F10). Quelques instants plus tard, le serveur d'applications AS1 peut transmettre au serveur média MS3, via le coeur de réseau CR, un autre message de requête standard, par exemple de type INFO , contenant une commande média lui demandant, par exemple, de demander au terminal demandeur T un numéro de carte de crédit (flèche F11). A réception de ce message (INFO), le serveur média MS3 exécute la commande qu'il contient et transmet au serveur d'applications AS1, via le coeur de réseau CR, un message de réponse, par exemple de type INFO, pour lui signaler qu'il a bien exécuté sa commande (flèche F12). Lorsque le serveur d'applications AS1 décide de mettre fin au dialogue avec le serveur média MS3, il lui transmet, via le coeur de réseau CR, un message de fin de session, par exemple de type BYE (flèche F13). A réception de ce message (BYE), le serveur média MS3 il génère à destination du serveur d'applications AS1, via le coeur de réseau CR, un message de réponse, par exemple de type 200 0K , signalant qu'il a bien reçu son dernier message de fin de session (flèche F14). Cela met fin au contrôle de la communication par le serveur d'applications AS1, ainsi qu'à la communication entre le terminal T et le serveur média MS3, mais cela n'implique pas nécessairement la fin de la liaison entre le terminal T et le serveur d'applications AS1 (ce dernier peut en effet décider de mettre en relation le terminal T avec l'équipement d'un autre utilisateur, par exemple dans le cas d'un serveur d'applications dédié au paiement). II est important de noter que l'on peut envisager une mise en oeuvre plus complexe que celle décrite ci-avant en référence à la figure 2. En effet, pour que le dispositif D soit informé de la fin d'une session et de la libération des ressources d'un serveur média, il est préférable que tous les messages échangés par le serveur d'applications AS1 et le serveur média MS3 passent par lui et qu'il implémente un mécanisme de mise à jour de type keep alive . L'invention offre de nombreux avantages parmi lesquels: - une interface standardisée entre les serveurs d'applications et les serveurs média, - un environnement multi-constructeurs, - le partage d'un serveur média par plusieurs serveurs d'applications développés par des fabricants différents, la mise à disposition de services média communs définis par une base de capacités communes, - une séparation entre la couche d'application (plan de contrôle) et la couche média (plan utilisateur), une gestion globale des ressources des serveurs média, prenant éventuellement en compte des priorités de tout type et/ou des situations de multi-répartitions prédéfinies (ou multi-tenancy), notamment, - une allocation de canaux (ressources) de serveurs média basique (par exemple de type round-robin ) ou bien complexe du fait qu'elle prend en compte des paramètres tels que la distribution géographique de serveurs média ou la qualité de service (QoS), - les serveurs d'applications n'ont plus besoin de stocker la liste des serveurs média qu'ils peuvent joindre, si bien qu'il est désormais possible d'ajouter ou de supprimer du réseau un serveur média sans avoir à effectuer la moindre opération au niveau des serveurs d'applications. Réciproquement, les serveurs média n'ont plus besoin de connaître tous les serveurs d'applications, si bien qu'il n'y a plus à effectuer la moindre opération au niveau des serveurs média, - le coût du portage des parties média des applications, initialement conçues pour les réseaux de type IN (pour Intelligent Network ), vers des réseaux de type NGM ou IMS, est notablement réduit. L'invention ne se limite pas aux modes de réalisation de dispositif de gestion et d'équipement de réseau décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ci-après. REVENDICATIONS 1. Dispositif (D) de gestion de ressources de serveurs média (MSj), d'un réseau de communication (CR), propres à offrir à des terminaux de communication clients (T), requérant des services, comportant au moins une partie média, gérés par des serveurs d'applications (ASi), des ensembles de fonctions média propres à assurer les parties média desdits services requis, caractérisé en ce qu'il comprend des moyens de mémorisation (BD) propres à stocker des données représentatives d'ensembles de fonctions média en correspondance d'identifiants de serveurs média (MSj), et des io moyens de gestion (MG) agencés, en cas de réception d'un message provenant d'un serveur d'applications (ASi) dédié à un service requis par un terminal client (T) et requérant la mise à disposition de ce dernier d'un ensemble de fonctions média propre à assurer une partie média dudit service requis, pour déterminer dans lesdits moyens de mémorisation (BD) l'identifiant d'un serveur média (MSj) disposant de ressources pour offrir ledit ensemble requis, puis pour allouer des ressources dudit serveur média déterminé (MSj) afin que ledit message puisse lui être transmis. 2. Dispositif selon la revendication 1, caractérisé en ce que lesdits moyens de mémorisation (BD) sont agencés pour stocker des données auxiliaires représentatives d'états de disponibilité des ressources des serveurs média (MSj) et/ou du dimensionnement des serveurs média (MSj) en fonction desdites données représentatives des ensembles de fonctions média et des identifiants des serveurs média (MSj). 3. Dispositif selon l'une des revendications 1 et 2, caractérisé en ce que lesdits moyens de gestion (MG) sont agencés pour procéder à l'allocation des ressources des serveurs média (MSj) en fonction d'informations de gestion et/ou desdites données auxiliaires. 4. Dispositif selon la revendication 3, caractérisé en ce que lesdites informations de gestion sont choisies dans un groupe comprenant au moins des informations de priorité(s), des informations de stratégie d'exploitation, des informations de contraintes géographiques, des informations de répartitions géographiques de serveurs média, des informations de qualité de service (QoS), des informations d'architecture du réseau, et des informations de qualité du réseau ou d'état du réseau. 5. Dispositif selon l'une des revendications 1 à 4, caractérisé en ce que lesdits moyens de mémorisation (BD) sont agencés pour être mis à jour dynamiquement. 6. Dispositif selon la revendication 5, caractérisé en ce que lesdits moyens de gestion (MG) sont agencés pour mettre à jour lesdits moyens de mémorisation (BD) à réception de données d'information représentatives des ensembles offerts par lesdits serveurs média (MSj) et/ou des ressources disponibles correspondantes. 7. Dispositif selon la revendication 6, caractérisé en ce que lesdites données d'informations proviennent desdits serveurs média (MSj). 8. Dispositif selon l'une des revendications 1 à 7, caractérisé en ce qu'il comprend i) une interface d'entrée (IE) agencée pour recevoir desdits serveurs d'applications (ASi) des messages conformes à un premier protocole et pour transmettre lesdits messages auxdits moyens de gestion (MG), et ii) une interface de sortie (IS) agencée pour transmettre auxdits serveurs média (MSj) des messages communiqués par lesdits moyens de gestion (MG) et qui leurs sont destinés. 9. Dispositif selon la revendication 8, caractérisé en ce que ladite interface de sortie (IS) est agencée pour convertir des messages conformes audit premier protocole en messages conformes à au moins un second protocole, avant de les transmettre auxdits serveurs média (MSj) destinataires. 10. Dispositif selon l'une des revendications 8 et 9, caractérisé en ce que ledit premier protocole est le protocole SIP. 11. Dispositif selon l'une des revendications 8 et 9, caractérisé en ce que ledit premier protocole est le protocole SIP encapsulant un protocole de type AMSML. 12. Dispositif selon l'une des revendications 9 à 11, caractérisé en ce que ledit second protocole est choisi dans un groupe comprenant au moins le protocole SIP encapsulant un protocole de type XML et un protocole de type H248. 13. Dispositif selon l'une des revendications 1 à 12, caractérisé en ce qu'il est associé à une adresse flottante. 14. Equipement de réseau (SP), caractérisé en ce qu'il comprend un dispositif de gestion (D) selon l'une des revendications précédentes.