FR 3067552 A1 20181214 FR 1755824 A 20170626 La présente invention concerne les réseaux de communications de type IP (« Internet Protocol »), et notamment ceux parmi les réseaux IP qui sont aptes à mettre en oeuvre des protocoles de contrôle de session évolués. Les réseaux IP permettent la diffusion de données conversationnelles, dans le cadre de services tels que « Voix sur IP » (VolP), « Partage de Contenu », ou « Messagerie Instantanée ». Plus particulièrement, la présente invention concerne les moyens mis en place dans un réseau IP pour assurer la concordance de l'état des ressources média auprès des entités responsables de la réservation de ces ressources. Les protocoles de contrôle de session évolués classiques, tels que le protocole SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'Initiation de Session »), utilisent des messages dits de « signalisation », qui sont des messages permettant à un terminal de demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière. Le protocole SIP a été défini par l'IETF (Internet Engineering Task Force) dans le document RFC 3261. Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Le protocole SIP a ensuite été étendu notamment dans le document RFC 3265. Cette extension définit des procédures de notification d'événements. Le protocole SIP est utilisé en particulier dans les infrastructures de type IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous- système Multimédia sur IP »). L'IMS a été défini par l'organisme de normalisation 3GPP (« Third Generation Partnership Project ») et TIS PAN (« Telecommunications and Internet Converged Services and Protocols for Advanced Networking »). C'est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN pour les réseaux fixes. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau 2 du réseau de transport des flux multimédia. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en oeuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type 5 téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction. Lorsque donc un usager souhaite bénéficier des services offerts par un réseau IMS, il émet vers le réseau des messages de signalisation pouvant inclure notamment divers types de requêtes. 10 Tout d'abord, le dispositif-client de l'usager doit, sauf exceptions (telles que certains appels d'urgence), s'enregistrer sur le réseau. Lorsque le réseau est incapable de faire le lien entre cet enregistrement et un enregistrement précédent (par exemple suite à une panne réseau, ou suite à un arrêt du dispositif-client pendant une durée supérieure à une valeur prédéterminée), 15 l'enregistrement est considéré comme étant un enregistrement initial. Après un enregistrement initial, le dispositif-client de l'usager doit envoyer périodiquement au réseau une requête pour confirmer qu'il souhaite maintenir son enregistrement. Pour pouvoir enregistrer les dispositifs-clients, les réseaux IMS 20 comprennent un ou plusieurs serveurs d'enregistrement, appelés « S-CSCF » (initiales des mots anglais « Serving-Cali Server Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau. 25 Les réseaux IMS comprennent en outre un ou plusieurs serveurs d'interrogation, appelés « I-CSCF » (initiales des mots anglais « InterrogatingCali Server Control Function » signifiant « Fonction de Commande de Session d'Appel Interrogatrice ») - d'ailleurs souvent combinés physiquement avec les serveurs d'enregistrement S-CSCF pour constituer des serveurs d'appel dénotés 30 « I/S-CSCF » - qui, au moment de l'enregistrement d'un dispositif-client, interrogent un serveur de données d'abonné appelé « HSS » (initiales des mots anglais « Home Subscriber Server » signifiant « Serveur d'Abonné de Rattachement »), afin de pouvoir sélectionner un serveur S-CSCF possédant les 3 caractéristiques qui sont obligatoirement (et, le cas échéant, optionnellement) requises pour atteindre le niveau de service souscrit par l'usager. Les serveurs HSS contiennent chacun une base de données-clients, et sont donc l'équivalent dans les réseaux IP des serveurs « HLR » (initiales des mots anglais « Home 5 Location Register » signifiant « Registre de Localisation de Rattachement ») utilisés dans les réseaux GSM. Chaque serveur HSS contient le « profil » d'un certain nombre de dispositifs-clients du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services auxquels il a droit. 10 En effet, après qu'un serveur S-CSCF lui a été ainsi attribué, chaque utilisateur peut faire usage d'un certain nombre de services pendant la session en cours. Il peut par exemple s'agir de services offerts automatiquement à tous les utilisateurs du réseau IMS. Il peut aussi s'agir de services auxquels cet utilisateur a souscrit auprès de l'opérateur du réseau, et qui sont mis 15 automatiquement à sa disposition. Enfin, il peut s'agir de services dont l'utilisateur peut faire usage après avoir émis une requête appropriée (SIP SUBSCRIBE). Ces services comprennent des applications audiovisuelles telles que mentionnées ci-dessus. Il peut s'agir également d'une souscription à l'état d'une 20 ressource, auquel cas des notifications d'évènement (SIP NOTIFY) sont envoyées au dispositif-client dès lors que l'état de la ressource change ; par exemple, lorsque l'utilisateur d'un dispositif-client dispose d'une boîte vocale sur le réseau, il pourra être informé chaque fois qu'un message a été enregistré sur cette boîte vocale ; un utilisateur peut, de même, demander à être notifié de l'état 25 d'enregistrement de son propre dispositif-client. Les réseaux IMS comprennent en outre un ou plusieurs serveurs appelés « P-CSCF » (initiales des mots anglais « Proxy-Ca!! Server Control Function » signifiaOnt « Fonction de Commande de Session d'Appel Mandataire »). Pour chaque dispositif-client connecté à un réseau IMS, il existe un serveur P-CSCF 30 servant d'entité de raccordement entre le coeur de réseau IMS et le réseau d'accès utilisé par ce dispositif-client ; ainsi, toute la signalisation SIP échangée entre le dispositif-client d'une part, et le serveur d'interrogation I-CSCF ou le serveur d'enregistrement S-CSCF d'autre part, passe par le serveur P-CSCF. 4 Pour mettre en oeuvre la taxation des usagers, les réseaux IMS utilisent une architecture appelée PCC (initiales des mots anglais « Policy and Charging Control » signifiant « Commande de Politique et de Taxation »). Cette architecture PCC est également utilisée dans les réseaux mobiles à commutation 5 de paquets comprenant un réseau coeur EPC (initiales des mots anglais « Evolved Packet Core » signifiant « coeur de réseau paquet évolué »), comme décrit dans le document TS 23.203 du 3GPP. L'architecture EPC est illustrée sur la figure 1, qui est adaptée de la figure 5.1.1 dudit document TS 23.203. Cette architecture PCC comprend notamment une entité de contrôle des 10 règles appelée PCRF (initiales des mots anglais « Policy Control and Charging Rules Function » signifiant « Fonction de Commande de Politique et de Règles de Taxation »), qui fournit des règles de taxation et de « politique d'opérateur » (comme par exemple le débit maximum alloué, ou la priorité d'un flux selon son type) à une entité d'application des règles PCEF (initiales des mots anglais 15 « Policy and Charging En forcement Function » signifiant « Fonction d'Application de Politique et de Taxation »). L'entité de contrôle des règles PCRF est apte à déterminer la méthode de taxation pour un flux de service donné ; elle a accès aux données d'abonnement de l'usager afin de pouvoir adapter l'utilisation des ressources de transport faite 20 par ce service, ainsi que la taxation du service, en fonction du profil de l'usager. L'entité de contrôle des règles PCRF collecte depuis plusieurs sources des informations liées aux réseaux (telles que le type d'accès radio, les adresses de passerelles, ou la localisation du terminal du client), des informations liées à l'abonnement du client, et des informations liées aux applications utilisées par le 25 client sur son terminal (telles que le type d'application, ou le type de média). L'entité de contrôle PCRF a accès aux informations de souscription de l'utilisateur de l'entité cliente mémorisées dans une base de données appelée SPR (initiales des mots anglais « Subscription Profile Repository ») afin de pouvoir adapter l'affectation des ressources de transport par le service ainsi que 30 le comptage du service en fonction du profil de l'utilisateur de l'entité cliente. L'entité PCEF, quant à elle, sélectionne une règle PCC pour chaque paquet de données dudit flux en examinant les données de service contenues dans ce paquet. La fonction PCEF est mise en oeuvre au niveau d'une passerelle 5 d'accès (« Gateway » en anglais) au réseau coeur. Le document TS 29.212 du 3GPP (intitulé « Policy and Charging Control over Gx reference point ») définit l'interface « Gx » entre l'entité de contrôle PCRF et l'entité d'application des règles PCEF. Lors de l'ouverture d'une session de communication, l'entité 5 d'application des règles PCEF ouvre une session de commande relative à la session de communication avec l'entité de contrôle des règles PCRF et lui communique des informations associées à cette session de communication (par exemple le type d'accès radio, les paramètres de qualité de service demandés, ou la bande passante demandée). En fonction de ces caractéristiques et d'autres 10 informations provenant de plusieurs autres sources, l'entité de contrôle PCRF détermine la politique initiale (qualité de service, tarification à mettre en place, autorisation d'accès) à appliquer pour les différents services portés par la session de communication en cours. Cette politique peut être modifiée en fonction d'événements se produisant durant la session de communication. 15 Une entité applicative AF (initiales des mots anglais « Application Function ») communique avec l'entité de contrôle des règles PCRF (ou une entité mandataire) pour transmettre des informations de session dynamiques et pour recevoir des notifications, par exemple relatives à l'occurrence d'évènements. Le document TS 29.214 du 3GPP (intitulé « Policy and Charging 20 Control over Rx reference point ») définit l'interface « Rx » entre l'entité de contrôle des règles PCRF et l'entité applicative AF. Lors de l'ouverture d'une session de communication, l'entité applicative AF fait une demande de ressources média auprès de l'entité PCRF. Le serveur P-CSCF d'un réseau IMS, mentionné ci-dessus, est un 25 exemple classique d'entité applicative AF. Enfin, l'entité BBERF (initiales des mots anglais « Bearer Binding and Event Reporting Function » signifiant « fonction de compte-rendu de liens de canaux virtuels et d'évènements ») permet à l'entité de contrôle des règles PCRF de disposer d'informations utiles pour le contrôle et la supervision des réseaux 30 d'accès locaux sans-fil WLAN (initiales des mots anglais « Wireless Local Access Network »). Grâce à ces diverses entités, l'architecture PCC est apte à générer des CDR (initiales des mots anglais « Call Detail Record » signifiant « enregistrement 6 des détails d'appel »). Plus précisément, une entité OCS (initiales des mots anglais « Online Charging System » signifiant « système de taxation en ligne ») génère des CDR au fil de l'eau, cependant qu'une entité OFCS (initiales des mots anglais « Offline Charging System » signifiant « système de taxation hors 5 ligne ») génère un fichier comprenant un ensemble de CDR que l'opérateur du réseau vient récupérer périodiquement (par exemple, toutes les heures ou tous les jours). On notera que toutes les interfaces de l'architecture PCC (hormis l'interface avec la base de données SPR) mettent en oeuvre le protocole de base 10 DIAMETER décrit dans le document RFC 3588 de l'IETF. Lors de la demande de ressources de l'entité applicative AF, celle-ci communique, au travers de l'interface Rx mentionnée ci-dessus, les caractéristiques des ressources désirées. Ces ressources sont essentiellement un ensemble de « média » (par exemple un flux « audio » et un flux « vidéo ») 15 possédant certaines propriétés souhaitées par un usager du réseau. L'information concernant un média se présente ainsi : Media-Component-Description ::= { Media-Cornponent-Number } ; Ordinal number of the media comp. *[ Media-Sub-Component]; Set of flows for one flow identifier 20 [ AF-Application-Identifier ] [ Media-Type ] [ Max-Requested-Bandwidth-UL ] [ Max-Requested-Bandwidth-DL ] [ Max-Supported-Bandwidth-UL 25 [ Max-Supported-Bandwidth-DL [ Min-Desired-Bandwidth-UL ] [ Min-Desired-Bandwidth-DL [ Min-Requested-Bandwidth-UL ] [ Min-Requested-Bandwidth-DL ] 30 [ Flow-Status ] [ Priority-Sharing-Indicator ] [ Reservation-Priority ] [ RS-Bandwidth 7 [ RR-Bandwidth ] *[ Codec-Data ] [ Sharing-Key-DL ] [ Sharing-Key-UL ] 5 [ Content-Version ] *[ AVP ] Chaque média est identifié par un numéro appelé « Media-ComponentNumber », ainsi que par des caractéristiques diverses (débit, type de média, adresses, et ainsi de suite). 10 Or il importe que l'état courant de ces composants média soit connu à l'identique sur l'entité applicative AF et sur l'entité de contrôle des règles PCRF: en effet, un composant connu sur l'entité de contrôle des règles PCRF et inconnu sur l'entité applicative AF constitue une anomalie (un « orphelin »), qu'il est nécessaire de détecter et supprimer car cela se traduit par une consommation 15 inutile de ressources - et à l'extrême à une saturation des ressources du PCRF s'il y a uniquement des orphelins. Or suite à différents évènements réseaux, la formation d'orphelins est possible dans certaines circonstances. A titre d'exemple, si le lien entre l'entité applicative AF et l'entité de contrôle des règles PCRF est perdu pendant un 20 certain laps de temps, des évènements peuvent avoir conduit à la libération de ressources par l'entité de contrôle des règles PCRF sans que l'entité applicative AF puisse en avoir connaissance, par exemple en raison d'une perte de connectivité dans un réseau d'accès radio RAN (initiales des mots anglais « Radio Access Network »). Selon un autre exemple, si l'entité applicative AF a 25 dû être totalement ou en partie réinitialisée, elle a pu perdre la connaissance précise des média en cours d'utilisation. Il en est de même si l'entité applicative AF a été remplacée, par exemple suite à la mise en oeuvre de redondance géographique. Le même problème se pose dans les réseaux fixes TISPAN (Telecommunications and Internet converged Services and Protocols for 30 Advanced Networking) conformes à la norme TS 183 017 de l'ETSI (European Telecommunications Standards lnstitute). 8 La présente invention concerne donc, selon un premier aspect, un procédé de détection de composants média orphelins, comprenant les étapes suivantes : - une entité applicative émet vers une entité de contrôle des règles une 5 requête demandant à ladite entité de contrôle des règles d'envoyer à ladite entité applicative un message décrivant l'état des média contrôlés par cette entité applicative et en cours d'utilisation, - à l'échéance d'un délai par défaut ou contenu dans ladite requête, l'entité de contrôle des règles émet vers l'entité applicative un message dans lequel 10 l'entité de contrôle des règles décrit l'état desdits média, et - suite à la réception dudit message, l'entité applicative - n'entreprend aucune action en conséquence si la liste de média fournie par l'entité de contrôle des règles est identique à celle connue de l'entité applicative, ou 15 - corrige son état desdits média, ou - demande la libération de la session. On notera que l'invention s'applique à tout réseau utilisant un protocole de réservation de flux média, notamment les réseaux de type IMS et EPC. Grâce à ces dispositions, un opérateur dudit réseau permet à l'entité 20 applicative et à l'entité de contrôle des règles de se resynchroniser mutuellement, à des échéances choisies. Selon des caractéristiques particulières, l'entité applicative indique en outre à l'entité de contrôle des règles une période à l'échéance de laquelle l'entité applicative souhaite recevoir lesdits messages décrivant l'état desdits 25 média. Grâce à ces dispositions, l'entité applicative peut indiquer à l'entité de contrôle des règles la périodicité souhaitée pour les notifications de l'état desdits média dans le cas où cette périodicité n'a pas été préconfigurée dans l'entité de contrôle des règles. 30 Selon d'autres caractéristiques particulières, ladite requête et/ou ladite indication de période est présentée par ladite entité applicative lors d'une demande de ressources média auprès de ladite entité de contrôle des règles. 9 Grâce à ces dispositions, on réduit au minimum la signalisation entre l'entité applicative et l'entité de contrôle des règles. Selon encore d'autres caractéristiques particulières, les échanges entre l'entité applicative et l'entité de contrôle des règles sont conformes au protocole 5 Diameter. Grâce à ces dispositions, on utilise le protocole de signalisation classiquement mis en oeuvre dans l'architecture PCC. Selon un deuxième aspect, l'invention concerne divers dispositifs. Elle concerne ainsi, premièrement, une entité applicative comprenant des 10 moyens pour : - émettre vers une entité de contrôle des règles une requête demandant à ladite entité de contrôle des règles d'envoyer à ladite entité applicative un message décrivant l'état des média contrôlés par cette entité applicative et en cours d'utilisation, 15 - recevoir un message dans lequel l'entité de contrôle des règles décrit l'état desdits média, et - suite à la réception dudit message, - n'entreprendre aucune action en conséquence si la liste de média fournie par l'entité de contrôle des règles est identique à celle connue de l'entité 20 applicative, ou - corriger son état desdits média, ou - demander la libération de la session. Selon des caractéristiques particulières, ladite entité applicative comprend en outre des moyens pour indiquer à ladite entité de contrôle des règles une 25 période à l'échéance de laquelle l'entité applicative souhaite recevoir lesdits messages décrivant l'état desdits média. Selon d'autres caractéristiques particulières, ladite entité applicative comprend en outre des moyens pour mettre en oeuvre le protocole Diameter. L'invention concerne aussi, deuxièmement, une entité de contrôle des 30 règles comprenant des moyens pour : - recevoir d'une entité applicative une requête demandant à ladite entité de contrôle des règles d'envoyer à ladite entité applicative un message décrivant l'état des média contrôlés par cette entité applicative et en cours d'utilisation, et 10 - à l'échéance d'un délai par défaut ou contenu dans ladite requête, émettre vers l'entité applicative un message dans lequel l'entité de contrôle des règles décrit l'état desdits média. Selon des caractéristiques particulières, ladite entité de contrôle des 5 règles comprend en outre des moyens pour mettre en oeuvre le protocole Diameter. Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus. On notera qu'il est possible de réaliser ces dispositifs dans le contexte 10 d'instructions logicielles et/ou dans le contexte de circuits électroniques. Selon un troisième aspect, l'invention concerne un système de communication comprenant au moins une entité applicative et au moins une entité de contrôle des règles telles que décrites succinctement ci-dessus. L'invention vise également un programme d'ordinateur téléchargeable 15 depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes du procédé de détection succinctement exposé ci-dessus, lorsqu'il est exécuté sur un ordinateur. 20 Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par ledit procédé. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui 25 l'accompagnent, dans lesquelles : - la figure 1, décrite ci-dessus, représente une architecture PCC classique, et - la figure 2 représente schématiquement un système pour la fourniture de services multimédia apte à mettre en oeuvre l'invention. 30 Bien que la présente invention concerne tout réseau IP faisant usage du protocole DIAMETER, on va considérer à présent, à titre d'exemple de réalisation, une architecture de réseau de type IMS, telle que présentée succinctement ci-dessus. Cette architecture est illustrée sur la figure 2. 11 Les services multimédia offerts par ce réseau IMS 1 peuvent comprendre des services de téléphonie, de vidéo-téléphonie, de partage de contenu (« content-sharing » en anglais), de Présence, de Messagerie Instantanée, ou de télévision. Ces services sont à la disposition de l'utilisateur d'un dispositif-client 5 (« User Equipment », ou UE en anglais) 10 appartenant au réseau 1, qui permet au dispositif-client 10 d'échanger des flux multimédia et des signaux de contrôle de session conformes au protocole SI P, par exemple avec le dispositif-client (non représenté) d'un usager appartenant à un réseau SIP (non représenté) relié au réseau 1. 10 Le dispositif-client 10 peut être un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise, disposant de moyens de signalisation SIP et pouvant comprendre des moyens de restitution d'un contenu audiovisuel. Comme le montre la figure 2, ce réseau IMS 1 comprend, outre une infrastructure de transport IP (non représentée) : 15 - au moins un serveur S-CSCF ; le serveur S-CSCF 27 gère notamment la procédure d'enregistrement des dispositifs connectés au réseau 1 ; le serveur S-CSCF 27 gère également le routage de la signalisation entre le dispositif-client 10 et les serveurs de messagerie vocale VM 25, de Messagerie Instantanée 26, et de téléphonie TAS 29; 20 - au moins un serveur I-CSCF ; le serveur I-CSCF 22 gère notamment le routage en direction d'autres terminaux gérés par le même réseau IMS 1 et le routage de la signalisation entre ce réseau IMS 1 et d'autres réseaux (non représentés) ; - au moins un serveur P-CSCF ; le serveur P-CSCF 21 sert d'entité de 25 raccordement entre le coeur de réseau IMS et le réseau d'accès utilisé par le dispositif-client 10; - au moins un serveur de base de données, de type HSS ; le serveur HSS 24 contient le profil de l'utilisateur du dispositif-client 10 en termes de données d'authentification et de localisation, et de services souscrits ; 30 - au moins un serveur VM 25 de messagerie vocale (« message-summary » en anglais) ; le serveur VM 25 gère la souscription du dispositif-client 10 aux événements de dépôt/consultation des messages à l'intention du 12 dispositif-client 10, et notifie le dispositif-client 10 lors de l'occurrence de ces événements ; - au moins un serveur de Messagerie Instantanée IM 26 ; en cas de souscription de l'utilisateur de l'UE 10 au service de Messagerie 5 Instantanée, cet utilisateur peut dialoguer « instantanément » en ligne avec d'autres abonnés à ce service ; et - au moins un serveur de téléphonie TAS 29 ; le serveur TAS gère les services téléphoniques auxquels l'utilisateur du terminal 10 a souscrits auprès de son opérateur, tels que la présentation du numéro ou le renvoi 10 d'appel. Les serveurs de messagerie vocale VM 25, de Messagerie Instantanée IM 26, et de téléphonie TAS 29 sont des exemples de Serveurs d'Applications (AS). Certains services, comme ceux du serveur VM 25 et du serveur de 15 Messagerie Instantanée IM 26, s'appuient sur la souscription du terminal 10 à des événements prédéterminés, comme expliqué ci-dessus. Sur la figure 2, les lignes en pointillé représentent le chemin réel suivi par les signaux SIP (entre l'UE 10 et l'entité PCEF 31, puis entre l'entité PCEF 31 et le serveur P-CSCF 21). La ligne hachurée (entre l'UE 10 et le serveur P-CSCF 20 21) représente le chemin « logique » de la signalisation SIP. L'entité PCRF 30 est connectée à l'entité PCEF 31 et au serveur P-CSCF 21. Le serveur P-CSCF 21 joue ici le rôle d'entité applicative AF selon l'architecture PCC. De manière connue, cette architecture peut mettre en oeuvre les étapes suivantes. 25 Lors d'une étape El, le serveur P-CSCF 21 reçoit un message de contrôle de session émis par l'UE 10 et contenant une description de flux media conforme au protocole SDP (Session Description Protocol). Lors d'une étape E2, le serveur P-CSCF 21 émet une demande de réservation de flux média auprès de l'entité PCRF 30. Cette demande de 30 réservation de flux média est un message de contrôle de ressources Diameter « AAR » (pour « AA-Request ») tel que défini dans le document RFC 4005 de l'IETF. 13 Lors d'une étape E3, l'entité PCRF 30 envoie au serveur P-CSCF 21 un message d'acquittement de la demande de réservation de flux. Ce message d'acquittement est un message de contrôle de ressources Diameter « AAA » (pour « AA-Answer ») tel que défini dans le document RFC 4005. 5 Lors d'une étape E4, l'entité PCRF 30 envoie à l'entité d'application des règles PCEF 31 un message décrivant les règles à installer pour mettre en oeuvre les flux média. Ce message décrivant les règles à installer est un message de contrôle de ressources Diameter « RAR » (pour « RA-Request ») tel que défini dans le document RFC 4005. 10 Lors d'une étape E5, l'entité PCEF 31 envoie à l'entité PCRF 30 un message d'acquittement d'installation des règles. Ce message d'acquittement est un message de contrôle de ressources Diameter « RAA » (pour « RAAnswer ») tel que défini dans le document RFC 4005. Enfin, lors d'une étape E6, l'entité PCEF 31 met en oeuvre lesdites règles 15 et autorise les flux média. Selon un mode de réalisation de l'invention, lors de ladite étape E2, le serveur P-CSCF émet à destination du PCRF, à travers l'interface Rx, une requête dans laquelle le serveur P-CSCF demande à être notifié de l'état des média contrôlés par ce serveur P-CSCF et en cours d'utilisation. 20 Pour ce faire, le serveur P-CSCF peut par exemple, avantageusement, appliquer la procédure indiquée dans les Sections 4.4.6.4 et 5.3.13 du document TS 29.214 précité, ainsi que dans la section B.1a du document TS 29.213 du 3GPP : cette demande de notification prend alors la forme d'un message Diameter AMI valorisant un champ « Attribute-Value Pair » (AVP) appelé 25 « Specific-Action ». Plus précisément, il est proposé à cet effet une nouvelle valeur de l'AVP « Specific Action », que l'on appellera « PERIODIC MEDIA_STATE ». De plus, en l'absence de période par défaut, le serveur P-CSCF indique au PCRF une période à l'échéance de laquelle il souhaite être notifié de l'état 30 des média en cours d'utilisation. La périodicité de ces notifications peut être indiquée dans un AVP dédié, que l'on appellera « Media_State_Period ». La période ne doit être ni trop courte (et ce, afin de ne pas surcharger inutilement l'interface), ni trop longue (et ce, afin de permettre un « nettoyage » efficace des 14 ressources orphelines). Cet AVP « Media_State_Period » peut, lui aussi, être inséré par le P-CSCF dans le message AAR de demande de ressources mentionné ci-dessus ; le P-CSCF indique ainsi au PCRF un délai à l'échéance duquel le PCRF doit envoyer au P-CSCF un message décrivant l'état courant 5 des média. De préférence, la demande de notification reste valide pendant toute la durée de la session ; ainsi, il ne sera pas nécessaire de la renouveler. A l'échéance du délai indiqué dans l'AVP « Media_State_Period », le PCRF émet vers le serveur P-CSCF un message dans lequel il indique l'état 10 courant des média contrôlés par ce serveur P-CSCF et en cours d'utilisation. De préférence, ce message est un message Diameter RAR (Re-Auth-Request) comprenant la valeur « PERIODIC_MEDIA_STATE », mentionnée ci-dessus, de l'AVP « Specific Action », afin de faire le lien avec la « Specific Action » de l'AAR à l'origine du présent message RAR (parmi, le cas échéant, d'autres REVENDICATIONS1. Procédé de détection de composants média orphelins, comprenant les étapes suivantes : - une entité applicative (AF) émet vers une entité de contrôle des règles (PCRF) une requête demandant à ladite entité de contrôle des règles (PCRF) d'envoyer à ladite entité applicative (AF) un message décrivant l'état des média contrôlés par cette entité applicative (AF) et en cours d'utilisation, - à l'échéance d'un délai par défaut ou contenu dans ladite requête, l'entité de contrôle des règles (PCRF) émet vers l'entité applicative (AF) un message dans lequel l'entité de contrôle des règles (PCRF) décrit l'état desdits média, et - suite à la réception dudit message, l'entité applicative (AF) - n'entreprend aucune action en conséquence si la liste de média fournie par l'entité de contrôle des règles (PCRF) est identique à celle connue de l'entité applicative (AF), ou - corrige son état desdits média, ou - demande la libération de la session. 2. Procédé de détection selon la revendication 1, caractérisé en ce que l'entité applicative (AF) indique en outre à l'entité de contrôle des règles (PCRF) une période à l'échéance de laquelle l'entité applicative (AF) souhaite recevoir lesdits messages décrivant l'état desdits média. 3. Procédé de détection selon la revendication 1 ou la revendication 2, caractérisé en ce que ladite requête et/ou ladite indication de période est présentée par ladite entité applicative (AF) lors d'une demande de ressources média auprès de ladite entité de contrôle des règles (PCRF). 4. Procédé de détection selon l'une quelconque des revendications 1 à 3, caractérisé en ce que les échanges entre l'entité applicative (AF) et l'entité de contrôle des règles (PCRF) sont conformes au protocole Diameter. 5. Procédé de détection selon les revendications 2 à 4, caractérisé en ce que ladite période est indiquée dans un Attribute-Value Pair dédié (Media_State_Period) d'un message Diameter AA-Request. 18 6. Procédé de détection selon les revendications 3 et 4, caractérisé en ce que ladite requête est insérée dans l'Attribute-Value Pair Specific-Action d'un message Diameter AA-Request. 5 7. Procédé de détection selon l'une quelconque des revendications 4 à 6, caractérisé en ce que ledit message contenant l'état desdits média est envoyé à l'entité applicative (AF) par l'entité de contrôle des règles (PCRF) dans un message Diameter RA-Request. 10 8. Entité applicative (AF), comprenant des moyens pour : - émettre vers une entité de contrôle des règles (PCRF) une requête demandant à ladite entité de contrôle des règles (PCRF) d'envoyer à ladite entité applicative (AF) un message décrivant l'état des média contrôlés par cette entité 15 applicative (AF) et en cours d'utilisation, - recevoir un message dans lequel l'entité de contrôle des règles (PCRF) décrit l'état desdits média, et - suite à la réception dudit message, - n'entreprendre aucune action en conséquence si la liste de média fournie 20 par l'entité de contrôle des règles (PCRF) est identique à celle connue de l'entité applicative (AF), ou - corriger son état desdits média, ou - demander la libération de la session. 25 9. Entité applicative (AF) selon la revendication 8, caractérisée en ce qu'elle comprend en outre des moyens pour indiquer à ladite entité de contrôle des règles (PCRF) une période à l'échéance de laquelle l'entité applicative (AF) souhaite recevoir lesdits messages décrivant l'état desdits média. 30 10. Entité applicative (AF) selon la revendication 8 ou la revendication 9, caractérisée en ce qu'elle comprend en outre des moyens pour mettre en oeuvre le protocole Diameter. 19 11. Entité applicative (AF) selon l'une quelconque des revendications 8 à 10, caractérisée en ce qu'elle est associée à un serveur P-CSCF dans un réseau IF Multimedia Subsystem. 5 12. Entité de contrôle des règles (PCRF), comprenant des moyens pour : - recevoir d'une entité applicative (AF) une requête demandant à ladite entité de contrôle des règles (PCRF) d'envoyer à ladite entité applicative (AF) un message décrivant l'état des média contrôlés par cette entité applicative (AF) et 10 en cours d'utilisation, et - à l'échéance d'un délai par défaut ou contenu dans ladite requête, émettre vers l'entité applicative (AF) un message dans lequel l'entité de contrôle des règles (PCRF) décrit l'état desdits média. 15 13. Entité de contrôle des règles (PCRF) selon la revendication 12, caractérisée en ce qu'elle comprend en outre des moyens pour mettre en oeuvre le protocole Diameter. 14. Système de communication, comprenant au moins une entité 20 applicative (AF) selon l'une quelconque des revendications 8 à 11, et au moins une entité de contrôle des règles (PCRF) selon la revendication 12 ou la revendication 13.