FR 3074396 A1 20190531 FR 1761445 A 20171130 Procédés de détection, de gestion et de relais d'un problème de communication multimédia, entités d'exécution, de contrôle et de gestion de règles et programme d'ordinateur correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des communications multimédia au sein d'au moins un réseau de communication. Plus précisément, l'invention offre une solution pour la gestion d'un problème de communication survenant au cours d'une session multimédia, encore appelé problème de communication multimédia. L'invention trouve notamment, mais non exclusivement, des applications dans les réseaux utilisant l'architecture PCC (en anglais « Policy and Charging Control », en français « contrôle des politiques et de la tarification »), telle que définie par le 3GPP (« Third Generation Partnership Project »), et le protocole IP dans le plan média. 2. Art antérieur Afin d'offrir à leurs abonnés de nouveaux services, les opérateurs de téléphonie ont commencé le déploiement de nouveaux réseaux de communication pour la transmission de la voix sur IP, comme les réseaux VoLTE (en anglais « Voice over LTE », en français « voix sur LTE) ») ou VoWiFi (en anglais « Voice over Wifi », en français « voix sur Wifi »). Ces réseaux disposent de quelques mécanismes de supervision permettant de limiter la durée des communications en cas de problème, par exemple en cas de mauvais raccrochage d'un combiné téléphonique. Ces mécanismes permettent notamment d'éviter la surfacturation des clients, et de protéger les réseaux en évitant que leurs ressources soient utilisées alors qu'un problème est survenu. Parmi ces mécanismes de supervision des appels, on peut citer les temporisateurs de session du protocole SIP, tels que décrits dans le document RFC 4028 (« Session Timers in the Session Initiation Protocol (SIP) »), qui permettent aux agents SIP de libérer les appels en l'absence de réponse aux messages de supervision du plan de signalisation. De tels agents SIP sont par exemple de type UE (en anglais « User Equipement », en français « équipement utilisateur »), x-CSCF (en anglais « x - Call/Session Control Function », en français « Fonction de Commande de Session/d'Appel »), AS (en anglais « Application Server », en français « serveur d'application ))). On peut également citer les mécanismes de détection d'inactivité média, mis en oeuvre sur les passerelles d'accès (AGW, en anglais « access gateway »), qui libèrent la communication si 2 un équipement du plan média (par exemple la passerelle d'accès) détecte l'absence de flux média pendant une durée configurable par l'opérateur. On rappelle qu'on entend notamment par flux média un flux associé à un type de média, comme un flux audio, un flux vidéo, un flux portant des données de type application, un flux portant des données de type texte, un flux portant des 5 données de type image, etc. Néanmoins, il existe des configurations d'appel ou des architectures réseaux pour lesquelles ces mécanismes de supervision d'appel ne sont pas, ou sont peu, efficaces, et pourraient être améliorés. Notamment, si le terminal associé à un client se situe, dans le réseau, derrière un routeur 10 de type traduction d'adresse réseau (NAT/P - « network address translation ») et qu'il perd sa connectivité réseau, le routeur NAT/P renverra, vers un équipement du plan média, des messages ICMP (en anglais « Internet Control Message Protocol », en français « Protocole de message de contrôle sur Internet ») de type « Destination Unreachable » (en français « destination injoignable). De tels messages ICMP, notamment ICMP Type 3 + Code 1,2 ou 3, permettent 15 d'indiquer à l'équipement du plan média que la destination qu'il cherche à joindre n'est plus accessible. On rappelle que le protocole ICMP, tel que défini dans le document RFC 792 notamment, permet de contrôler les erreurs de transmission, en informant un équipement émetteur d'un problème sur le réseau. Le protocole IP ne gère quant à lui que le transport de paquets, et ne permet pas l'envoi de messages d'erreurs. 20 Or si le terminal du client utilise la technologie VoLTE ou VoWiFi, le protocole ICMP n'est pas autorisé dans le réseau. En effet, comme décrit dans la norme TS 29.214 (« Universal Mobile Telecommunications System (UMTS); Policy and charging control over Rx reference point »), seuls les flux négociés lors de la phase préalable à l'établissement d'une communication, conformément au protocole SDP (« Session Description Protocol ») de description de sessions, 25 sont autorisés dans le réseau. Or le protocole ICMP, qui est utilisé pour contrôler les erreurs de transmission, n'est pas négocié dans le SDP lors de la phase préalable à l'établissement d'une communication, et n'est donc pas autorisé lors de la phase de communication. En l'absence d'autorisation du protocole ICMP avec les terminaux utilisant la technologie VoLTE ou VoWiFi, les messages ICMP ne peuvent pas être utilisés pour détecter un problème de 30 communication lors de la phase de communication. Par conséquent, la communication ne peut pas être libérée avant soit l'expiration d'un temporisateur d'inactivité média, soit un audit du plan de signalisation, tel que décrit dans le document RFC 4028 précité. Si l'on considère une libération de la communication au prochain audit du plan de 3 signalisation, la libération de la communication n'est pas immédiate. En effet, dans les réseaux actuels, la durée entre deux audits est habituellement de l'ordre d'une heure. Si l'on considère une libération de la communication sur expiration du temporisateur d'inactivité média, les délais varient habituellement de quelques secondes à quelques minutes. 5 On note cependant qu'un tel temporisateur n'est classiquement mis en oeuvre que sur la passerelle d'accès. Or une telle passerelle d'accès n'est pas nécessairement présente dans l'architecture utilisée, et reste optionnelle dans l'architecture IMS. Il existe donc un besoin pour une nouvelle technique permettant de détecter un problème de communication, et qui soit notamment compatible avec les architectures mettant en 10 oeuvre la technologie VoLTE ou VoWiFi. 3. Exposé de l'invention Selon au moins un mode de réalisation, l'invention propose un procédé de détection d'un problème de communication multimédia, mis en oeuvre par une entité d'exécution. Selon l'invention, un tel procédé de détection comprend une phase de traitement 15 mettant en oeuvre : la réception d'au moins un message, dit message reçu, appartenant à au moins un flux à surveiller se rapportant à au moins un flux média, la vérification d'une correspondance entre ledit au moins un message reçu et au moins une règle associée audit au moins un flux à surveiller, et 20 lorsque ledit au moins un message reçu correspond à ladite règle, l'envoi à une entité de contrôle, par l'intermédiaire d'une entité de gestion de règles, d'un message de détection d'erreur. Ainsi, on définit selon l'invention un ensemble de règles, permettant à une entité d'exécution de détecter un problème de communication multimédia sur le réseau et d'en 25 informer une entité de contrôle. L'entité d'exécution selon l'invention est donc dotée d'une certaine intelligence, puisqu'elle peut analyser les messages qu'elle reçoit et déclencher un message de détection d'erreur si les messages reçus vérifient une règle prédéfinie. Ainsi, un problème de communication peut être détecté rapidement, et par suite une 30 action engagée (comme la libération de la communication), sans attendre l'expiration du temporisateur d'inactivité média ou le prochain audit du plan de signalisation. En particulier, ledit au moins un flux à surveiller est de type flux ICMP, notamment un flux ICMP se rapportant à au moins un flux média. 4 Lorsque le flux à surveiller est de type ICMP, le message reçu est un message d'erreur, par exemple de type « Destination Unreachable ». Dans ce cas, le procédé de détection d'un problème de communication peut notamment mettre en oeuvre une étape d'identification d'un flux média à l'origine du message d'erreur. La ou les règles associées au flux à surveiller peuvent 5 notamment dépendre du flux média à l'origine du message d'erreur. Il est ainsi possible de déterminer rapidement un problème de communication, par exemple une perte de joignabilité, par l'analyse des messages ICMP, notamment dans le contexte d'une architecture 3GPP PCC. Par exemple, suite à l'arrêt d'une application sur un client (terminal appelant par 10 exemple), le système d'exploitation gérant l'application émet classiquement des messages ICMP vers le distant (terminal appelé par exemple), l'application ayant libéré des ressources réseau. L'autorisation de l'exploitation des messages ICMP, dans le contexte de l'invention, permet ainsi d'identifier l'injoignabilité du terminal appelant (dans l'exemple considéré). En particulier, suite à une analyse des messages ICMP reçus, un problème de 15 communication peut être rapidement identifié. En effet, la cadence d'émission des paquets RTP (Real-Time Transport Protocol) est classiquement de 20 ms. Un problème de communication peut donc être confirmé et signalé à l'entité de contrôle dans des délais très brefs. Par exemple, un problème de communication est détecté si le nombre de paquets ICMP reçus dépasse un seuil configurable dans un délai également configurable. Dans le cas d'un flux RTP classique, la 20 réception de 10 messages ICMP consécutifs permet par exemple de confirmer un problème de connectivité. A la cadence de 20 ms par paquet RTP, le problème est confirmé en 200 ms. Selon un mode de réalisation particulier, le procédé de détection comprend une phase de configuration préalable à ladite phase de traitement, mettant en oeuvre la réception d'un message de requête en notification de détection d'erreur, transmis par ladite entité de contrôle 25 par l'intermédiaire de ladite entité de gestion de règles, ledit message de requête en notification de détection d'erreur portant ladite au moins une règle. Ainsi, l'ensemble de règles permettant à une entité d'exécution de détecter un problème de communication multimédia sur le réseau peut être défini par l'entité de contrôle, puis transmis à l'entité d'exécution via l'entité de gestion de règles. 30 En particulier, si ladite au moins une règle définit un seuil de détection d'un problème de communication à partir d'un nombre prédéterminé de messages et une période prédéterminée, ledit message de détection d'erreur est généré, et envoyé à ladite entité de contrôle, lorsque le nombre de messages reçus pendant ladite période prédéterminée est supérieur ou égal au 5 nombre prédéterminé de messages. En d'autres termes, un message de détection d'erreur de type « franchissement de seuil » peut être envoyé à l'entité de contrôle. Dans un autre mode de réalisation, l'invention concerne une entité d'exécution 5 correspondante, apte à détecter un problème de communication multimédia. Une telle entité d'exécution est notamment adaptée à mettre en oeuvre le procédé de détection décrit précédemment. Ainsi, une telle entité peut comporter les différentes caractéristiques relatives au procédé de détection selon l'invention, qui peuvent être combinées ou prises isolément. 10 Par exemple, une telle entité d'exécution est de type PCEF (en anglais « Policy and Charging Enforcement Function », en français « fonction de mise en application des politiques et de la tarification »), et peut notamment être intégrée à une passerelle d'accès. Une telle entité d'exécution peut notamment être une entité purement logicielle, ou une entité physique, comprenant des moyens physique et/ou logiciels. 15 L'invention concerne par ailleurs, selon au moins un mode de réalisation, un procédé de gestion d'un problème de communication multimédia, mis en oeuvre par une entité de contrôle. Selon l'invention, un tel procédé de gestion comprend une phase de traitement mettant en oeuvre : la réception d'un message de détection d'erreur, généré par une entité d'exécution en 20 tenant compte d'au moins une règle associée à au moins un flux à surveiller se rapportant à au moins un flux média, et transmis par l'intermédiaire d'une entité de gestion de règles, et une action sur ladite communication à réception dudit message de détection d'erreur. Ainsi, une action peut être déclenchée dans les meilleurs délais à réception d'un message 25 de détection d'erreur, i.e. sans attendre l'expiration du temporisateur d'inactivité média ou le prochain audit du plan de signalisation. Selon un mode de réalisation particulier, le procédé de gestion comprend une phase de configuration préalable à ladite phase de traitement, mettant en oeuvre : la définition d'au moins une règle associée à au moins un flux à surveiller ; et 30 la transmission d'un message de requête en notification de détection d'erreur à ladite entité d'exécution, par l'intermédiaire de ladite entité de gestion de règles, ledit message de requête en notification de détection d'erreur portant ladite au moins une règle. Comme indiqué précédemment, l'entité de contrôle peut ainsi définir un ensemble de 6 règles permettant à une entité d'exécution de détecter un problème de communication multimédia sur le réseau, puis transmettre ces règles à l'entité d'exécution via l'entité de gestion de règles. En particulier, ladite au moins une règle définit un seuil de détection d'un problème de 5 communication à partir d'un nombre prédéterminé de messages reçus sur une période prédéterminée. Par exemple, lorsque les messages reçus sont de type ICMP, un message de détection d'erreur est déclenché si 20 messages ICMP sont reçus dans un délai d'une seconde. Selon un mode de réalisation particulier, le message de requête en notification de 10 détection d'erreur porte également un attribut relatif à au moins un type de flux autorisé pour transporter des informations sur des flux média. Par exemple, le message de requête en notification de détection d'erreur porte au moins un attribut indiquant que les flux ICMP de type 3 sont autorisés dans le sens « montant » (i.e. en direction du coeur de réseau). 15 En particulier, le message de requête en notification de détection d'erreur porte également un attribut relatif à au moins un flux média auquel se rapporte le flux à surveiller, ce dernier étant par exemple un flux ICMP. Dans un autre mode de réalisation, l'invention concerne une entité de contrôle correspondante, apte à gérer un problème de communication multimédia. 20 Une telle entité de contrôle est notamment adaptée à mettre en oeuvre le procédé de gestion décrit précédemment. Ainsi, une telle entité peut comporter les différentes caractéristiques relatives au procédé de gestion selon l'invention, qui peuvent être combinées ou prises isolément. Par exemple, une telle entité de contrôle est de type AF, notamment P-CSCF. 25 Une telle entité de contrôle peut notamment être une entité purement logicielle, ou une entité physique, comprenant des moyens physique et/ou logiciels. L'invention concerne également, selon au moins un mode de réalisation, un procédé de relais d'un problème de communication multimédia, mis en oeuvre par une entité de gestion de règles. 30 Selon l'invention, un tel procédé de relais comprend une phase de traitement mettant en oeuvre : la réception d'un message de détection d'erreur, généré par une entité d'exécution en tenant compte d'au moins une règle associée à au moins un flux à surveiller se rapportant 7 à au moins un flux média, et la transmission dudit message de détection d'erreur à une entité de contrôle. Un tel procédé de relais permet donc de mettre en forme et de relayer les messages entre une entité de contrôle et une entité d'exécution. Il est notamment adapté à recevoir, à mettre en 5 forme et à renvoyer les messages générés par les procédés de détection et de gestion décrits précédemment, et présente donc les mêmes avantages que ces procédés. En particulier, un tel procédé de relais comprend une phase de configuration préalable à ladite phase de traitement, mettant en oeuvre : la réception d'un message de requête en notification de détection d'erreur, transmis par 10 ladite entité de contrôle, ledit message de requête en notification de détection d'erreur portant ladite au moins une règle, et la transmission dudit message de requête en notification de détection d'erreur à ladite entité d'exécution. Dans un autre mode de réalisation, l'invention concerne une entité de gestion de règles 15 correspondante, apte à relayer un problème de communication multimédia. Une telle entité de gestion de règles est notamment adaptée à mettre en oeuvre le procédé de relais décrit précédemment. Ainsi, une telle entité peut comporter les différentes caractéristiques relatives au procédé de relais selon l'invention, qui peuvent être combinées ou prises isolément. 20 Par exemple, une telle entité de gestion de règles est de type PCRF (en anglais « Policy and charging rules function », en français « fonction de règles des politiques et de la tarification ))). Une telle entité de gestion de règles peut notamment être une entité purement logicielle, ou une entité physique, comprenant des moyens physique et/ou logiciels. 25 Ces entités de contrôle, de gestion de règles et d'exécution définissent l'architecture 3GPP PCC. Ainsi, dans un mode de réalisation particulier, l'invention permet la détection rapide d'un problème de communication par l'analyse des messages ICMP dans l'architecture 3GPP PCC, afin de prendre les mesures appropriées. 30 Dans un autre mode de réalisation, l'invention concerne un ou plusieurs programmes d'ordinateur comportant des instructions pour la mise en oeuvre d'au moins un procédé tel que décrit ci-dessus, lorsque ce ou ces programmes sont exécutés par un processeur. Dans encore un autre mode de réalisation, l'invention concerne un ou plusieurs supports 8 d'informations, inamovibles, ou partiellement ou totalement amovibles, lisibles par un ordinateur, et comportant des instructions d'un ou plusieurs programmes d'ordinateur pour l'exécution des étapes d'au moins un procédé tel que décrit ci-dessus. 4. Liste des figures 5 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 particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 illustre les principales étapes mises en oeuvre pour la détection, le relais et la gestion d'un problème de communication multimédia selon au moins un mode de 10 réalisation ; la figure 2 illustre un exemple de mise en oeuvre de l'invention dans un réseau de communication mettant en oeuvre une architecture PCC selon au moins un mode de réalisation ; la figure 3 présente un chronogramme illustrant les messages échangés entre les 15 différentes entités du réseau de communication selon la figure 2; et les figures 4 à 6 présentent respectivement la structure simplifiée d'une entité d'exécution, d'une entité de contrôle, et d'une entité de gestion des règles selon au moins un mode de réalisation. 5. Description d'un mode de réalisation de l'invention 20 5.1 Principe général L'invention se place dans le contexte d'un réseau de communication mettant en oeuvre une architecture de type PCC comprenant une entité de contrôle, une entité de gestion de règles, et une entité d'exécution. Le principe général de l'invention repose sur la définition de règles et la vérification de ces 25 règles pour détecter un problème de communication multimédia dans le réseau de communication. Ladite communication peut impliquer des points d'extrémité quelconques, par exemple deux terminaux d'abonnés, ou un serveur vocal et un abonné, ou deux machines connectées, et ainsi de suite. On présente, en relation avec la figure 1, les principales étapes mises en oeuvre pour 30 détecter, relayer et gérer un problème de communication multimédia, dans un réseau de communication mettant en oeuvre au moins une entité de contrôle EC sur le plan de contrôle, une entité de gestion de règles EGR, et une entité d'exécution EE sur le plan média. Au cours d'une phase de traitement 11, l'entité d'exécution EE reçoit 111E au moins un 9 message appartenant à un flux à surveiller. Par exemple, le flux à surveiller est de type ICMP et le message reçu est un message d'erreur ICMP (Rx Err.). Lorsque le ou les messages reçus sont de type ICMP, l'entité d'exécution EE peut analyser 112E le ou les messages d'erreur reçus, de façon à identifier le ou les flux média ayant provoqué 5 l'émission du ou des messages d'erreur (Id. F.). L'entité d'exécution EE vérifie 113E alors la correspondance entre le ou les messages reçus et au moins une règle associée au flux à surveiller (Verif.). En d'autres termes, l'entité d'exécution EE vérifie si le ou les messages reçus remplissent au moins une condition définie par au moins une règle connue de l'entité d'exécution. En particulier, la ou les règles associées au flux à surveiller 10 peuvent dépendre du ou des flux média à l'origine du message d'erreur. Les règles peuvent notamment être préalablement définies et stockées dans une mémoire de l'entité d'exécution, ou dans une base de données accessible par l'entité d'exécution. Les règles peuvent également être définies par l'entité de contrôle au cours d'une phase préalable de configuration 10, présentée ci-après. 15 Lorsque le ou les messages reçus correspondent à la règle, l'entité d'exécution EE envoie 114E à l'entité de gestion de règles EGR un message de détection d'erreur (Tx Det. Err.). L'entité de gestion de règles EGR reçoit 115R donc le message de détection d'erreur, généré par l'entité d'exécution EE en tenant compte d'au moins une règle associée au flux à surveiller (Rx. Det. Err). 20 L'entité de gestion de règles EGR met en forme le message de détection d'erreur et le transmet 116R à l'entité de contrôle EC (Tx. Det. Err.). L'entité de contrôle EC reçoit 117c donc le message de détection d'erreur, initialement généré par l'entité d'exécution EE en tenant compte d'au moins une règle associée au flux à surveiller et transmis par l'intermédiaire de l'entité de gestion de règles EGR (Rx. Det. Err.). 25 A réception de ce message de détection d'erreur, l'entité de contrôle peut agir 118c sur la communication multimédia, en effectuant au moins une action appartenant au groupe comprenant : interruption de la communication, émission d'un message spécifique, 30 émission d'une alarme, modification d'au moins un compteur statistique, insertion d'une information dans un ticket de taxation (« Charging Data Record », ou CDR en anglais), 10 etc. De ce fait, dès qu'un message d'un flux à surveiller est reçu par l'entité d'exécution EE, il est possible, pour l'entité de contrôle EC, d'agir rapidement sur la communication multimédia. Comme indiqué précédemment, les règles que l'entité d'exécution doit appliquer peuvent 5 être définies par l'entité de contrôle au cours d'une phase préalable de configuration 10. Plus précisément, au cours d'une telle phase de configuration 10, mise en oeuvre préalablement à la phase de traitement 11, l'opérateur du réseau de communication définit 101c, par l'intermédiaire de son entité de contrôle EC, au moins une règle associée à au moins un flux à surveiller (Def. R.), et éventuellement à au moins un flux média. 10 L'entité de contrôle EC transmet 102c ensuite un message de requête en notification de détection d'erreur à l'entité de gestion de règles EGR (Tx R.). Un tel message de requête en notification de détection d'erreur porte la ou les règles préalablement définies. L'entité de gestion de règles EGR reçoit 103R donc le message de requête en notification de détection d'erreur (Rx R.) 15 L'entité de gestion de règles EGR met en forme le message de requête en notification de détection d'erreur et le transmet 104R à l'entité d'exécution EE (Tx R.) L'entité d'exécution EE reçoit 105E donc le message de requête en notification de détection d'erreur portant la ou les règles préalablement définies, transmis par l'entité de contrôle EC par l'intermédiaire de l'entité de gestion de règles EGR (Rx R.). 20 5.2 Description d'un mode de réalisation particulier On décrit ci-après plus en détail un exemple de mise en oeuvre de l'invention dans un réseau de communication mettant en oeuvre une entité de contrôle de type AF ou P-CSCF, une entité de gestion de règles de type PCRF, et une entité d'exécution de type PCEF intégrée dans une passerelle d'accès GW. 25 La structure d'un tel réseau est illustrée en figure 2. Plus précisément, un tel réseau de communication comprend une entité de contrôle AF 21 communiquant avec une entité de gestion de règles PCRF 22 par l'intermédiaire d'une interface Rx, et une entité d'exécution PCEF 231, intégrée à une passerelle GW 23, communiquant avec l'entité de gestion de règles PCRF 22 par l'intermédiaire d'une interface Gx. L'entité PCEF 231 30 communique également avec un système OCS 24 (en anglais « Online Charging System », en français « système de tarification en ligne ») par l'intermédiaire d'une interface Gy, et avec un système OFCS 25 (en anglais « Offline Charging System », en français « système de tarification hors ligne ») par l'intermédiaire d'une interface Gz. 11 Selon ce mode de réalisation, afin de détecter rapidement un problème de communication multimédia, l'entité de contrôle AF 21 autorise l'entité d'exécution PCEF 231 à analyser les messages ICMP. On rappelle que, selon l'art antérieur, de tels messages ICMP reçus lors d'une phase de 5 communication sont directement écartés par l'entité d'exécution PCEF 231 car non négociés dans le protocole SDP lors de la phase d'établissement de la communication. En particulier, l'entité de contrôle (qui contrôle notamment l'entité d'exécution) ne donne, selon l'art antérieur, aucune instruction à l'entité d'exécution quant au traitement des messages ICMP reçus. En particulier, l'entité de contrôle AF 21 autorise selon ce mode de réalisation les 10 messages ICMP de type « Destination Unreachable ». Les autres types de messages ICMP, notamment les messages de type « Ping », peuvent présenter des failles de sécurité, et restent donc non autorisés. De plus, selon ce mode de réalisation, les entités de contrôle AF 21, de gestion de règles PCRF 22, et d'exécution PCEF 231 autorisent la définition et la communication de règles 15 permettant de détecter un problème de communication multimédia, par exemple lorsqu'un seuil de détection est dépassé, afin de détecter rapidement un problème de communication multimédia. Ainsi, l'invention propose, selon ce mode de réalisation, de modifier le fonctionnement de l'entité de contrôle AF 21, tel qu'actuellement décrit dans la norme TS 29.214, afin d'autoriser le 20 protocole ICMP dans la description des flux médias, de permettre la configuration d'un seuil de détection d'un problème à partir d'un ensemble de règles, et de rendre possible la notification de signalement de franchissement de seuil, i.e. la génération d'un message de détection d'erreur. L'invention propose également, selon ce mode de réalisation, de modifier le fonctionnement de l'entité de gestion de règles PCRF 22, afin de relayer l'information 25 d'autorisation ICMP, de relayer la configuration du seuil de détection d'un problème et en demander la notification à l'entité d'exécution PCEF 231, puis relayer les notifications associées au franchissement de seuil. Enfin, l'invention propose, selon ce mode de réalisation, de modifier le fonctionnement de l'entité d'exécution PCEF 231, afin d'installer les règles correspondantes, prendre en compte le 30 seuil de détection d'un problème reçu, et notifier le franchissement de seuil. On note que l'entité qui contrôle le dépassement de seuil est de préférence l'entité d'exécution PCEF 231. En effet, les flux média sont gérés par l'entité d'exécution PCEF 231, sur le plan média. Comme les flux média sont gérés par le PCEF, les flux ICMP peuvent également être 12 gérés par le PCEF. Ainsi, à réception d'un message d'erreur ICMP, notamment de type « Destination Unreachable », l'entité d'exécution PCEF 231 peut identifier le flux média ayant provoqué le message d'erreur ICMP, et obtenir les règles associées. Afin d'illustrer l'invention, on présente, en relation avec la figure 3, un chronogramme 5 illustrant la détection, le relais et la gestion d'un problème de communication multimédia dans un réseau tel que celui illustré en figure 2. Plus précisément, la figure 3 illustre les messages échangés en utilisant le protocole DIAMETER tel que décrit dans la norme TS 29.211. On considère à titre d'exemple que le seuil de détection d'un problème pour un type de média donné est disponible sur l'entité de contrôle AF 21. Par exemple, l'entité de contrôle AF est 10 le P-CSCF, sur lequel on a configuré que pour les flux RTP associés à un certain type de média (par exemple audio, ou vidéo, ou texte), la réception de 20 messages ICMP de type « Destination Unreachable » dans un délai de 1 seconde est caractéristique d'une perte de connectivité. On définit ainsi au niveau de l'entité de contrôle une règle associée aux flux ICMP, selon laquelle si le nombre de messages ICMP se rapportant aux flux média RTP du type considéré sur une période 15 de 1 seconde est supérieur ou égal à 20, une notification de dépassement de seuil doit être émise. Au cours d'une phase de configuration, mise en oeuvre lors d'une phase préalable à l'établissement d'une communication multimédia ou lorsque la communication multimédia est établie, l'entité de contrôle AF 21 indique à l'entité de gestion des règles PCRF 22, via l'interface Rx, qu'elle souhaite être notifiée pour le dépassement de ce seuil de détection. 20 Pour ce faire, comme indiqué précédemment, l'entité de contrôle AF 21 dispose de nouvelles fonctionnalités lui permettant notamment de transmettre à l'entité d'exécution PCEF 231, par l'intermédiaire de l'entité de gestion de règles PCRF 22, un message de requête en notification de détection d'erreur (i.e., selon cet exemple, en notification de dépassement de seuil). 25 Par exemple, l'entité de contrôle AF 21 envoie à l'entité de gestion de règles PCRF 22 un message AAR (« Authorize/Authenticate-Request ») de requête en notification de détection d'erreur, sous la forme suivante : AAR (Specific-Action = « THRESHOLD REPORT » Flow-Description = filtre ICMP type 3, 30 Flow-Number =X Flow-Packet-Threshold = (Flow-Number=X, Observation-Period=1000 ms, PacketCount = 20) ) 13 En particulier, un tel message AAR porte la ou les règles définies précédemment, et notamment des informations sur le seuil de détection au-delà duquel l'entité de contrôle doit être notifiée d'un problème de communication. Par exemple, le message AAR porte un attribut AVP (« Attribute Value Pair ») relatif à une 5 action spécifique de requête en notification en cas de dépassement d'un seuil de détection, noté « THRESHOLD_REPORT ». Le message AAR porte également un attribut AVP relatif à au moins un type de flux autorisé pour transporter des informations sur des flux média, sous la forme d'un AVP de description de flux, noté AVP « Flow Description ». Le message AAR de requête en notification de 10 détection d'erreur comprend ainsi un attribut permettant d'autoriser les flux ICMP de type 3 lors de la communication des informations de sessions média, notamment dans le sens montant (i.e. en direction du coeur de réseau). Cet AVP « Flow-Description » associé au flux ICMP peut être complété par un identifiant de type de média, par exemple un AVP de numéro de flux, noté AVP « Flow-Number ». 15 Le message AAR porte également un nouvel attribut AVP, noté AVP « Flow-Packet- Threshold » définissant, pour un flux à surveiller, la valeur du seuil de détection. Par exemple, l'AVP « Flow-Packet-Threshold » est de type « groupé » (en anglais « Grouped ») et défini comme suit : Flow-Packet-Threshold ::= [ Flow-Number ] [ Observation-Period ] [ Packet-Count] où l'AVP « Flow-Number » se rapporte ici au flux surveillé (par exemple un flux ICMP), l'AVP 20 « Observation-Period » définit la durée d'un intervalle de mesure, par exemple 1 seconde, et l'AVP « Packet-Count » le nombre maximum de paquets reçus durant cet intervalle, par exemple 20 paquets ICMP se rapportant à un certain flux média. On note que le message AAR de requête en notification de détection d'erreur, par exemple au sein de l'AVP « Flow-Packet-Threshold », peut également porter un attribut AVP 25 permettant d'identifier un type de média (par exemple via un numéro de flux) auquel doit se rapporter le flux ICMP à surveiller. En l'absence d'un tel attribut, on surveille les flux ICMP se rapportant à tout type de média. A réception du message AAR de requête en notification de détection d'erreur par l'entité de gestion de règles PCRF 22, cette dernière peut accuser réception par l'envoi d'un message AAA 14 (« Authorize/Authenticate-Answer ») à l'entité de contrôle AF 21. L'entité de gestion de règles PCRF 22 est chargée de relayer à l'entité d'exécution PCEF 231 la politique de détection demandée. L'entité d'exécution PCEF 231 est quant à elle chargée d'appliquer la politique de détection demandée. 5 Pour ce faire, l'entité de gestion de règles PCRF 22 met en forme le message AAA de requête en notification de détection d'erreur et l'envoie à l'entité d'exécution PCEF 231 sous la forme d'un message RAR (« Re-Auth-Request ») de requête en notification de détection d'erreur, par exemple : RAR (Event-Trigger = « THRESHOLD REPORT » 10 Flow-Description = filtre ICMP type 3, Flow-Number =X Flow-Packet-Threshold = (Flow-Number=X, Observation-Period=1000 ms, Packet- Count = 20) ) 15 Ainsi, grâce à l'utilisation de l'AVP « Flow-Description », l'entité d'exécution PCEF 231 est informée de l'autorisation de réception et d'analyse desdits flux ICMP. De même, l'AVP « Flow-Packet-Threshold »est ajouté dans les règles PCC appropriées (par exemple dans l'AVP « Charging Rule Install »), et transmis à l'entité d'exécution PCEF 231. Enfin, la nouvelle valeur « THRESHOLD_REPORT » est définie pour l'AVP « Event-Trigger », 20 en association avec l'AVP « Flow-Packet-Threshold », qui contiennent l'identifiant « Flow- Number » du ou des flux à superviser. A réception du message RAR de requête en notification de détection d'erreur par l'entité d'exécution PCEF 231, cette dernière peut accuser réception par l'envoi d'un message RAA (« ReAuth -Answer ») à l'entité de gestion de règles PCRF 22. 25 L'entité d'exécution PCEF 231 installe les règles définies dans le message RAR de requête en notification de détection d'erreur, notamment les règles de filtrage. Elle prend également en compte le contenu de l'AVP « Flow-Packet-Threshold » pour déterminer les flux à superviser et les valeurs de seuil de détection. Au cours d'une phase de traitement, mise en oeuvre lorsque la communication 30 multimédia est établie, l'entité d'exécution PCEF 231 surveille le ou les flux identifiés dans le message RAR de requête en notification de détection d'erreur, par exemple le flux ICMP de type 3. Lors de la réception d'un message d'erreur ICMP, l'entité d'exécution PCEF 231 en analyse 15 le contenu. En particulier, l'entité d'exécution PCEF 231 (ou éventuellement la fonction TDF « Traffic Detection Function », équivalente à la fonction DPI « Deep Packet Inspection ») analyse le contenu du champ « en-tête Internet » (en anglais « Internet Header ») du message ICMP, afin d'identifier le message ayant généré l'erreur ICMP, et ainsi rattacher cette erreur au flux média 5 correspondant. Cette identification repose par exemple sur l'analyse des champs « Destination IP » et/ou « Destination Port UDP » contenus dans le champ « Internet Header » du message ICMP de type 3, tels que définis dans le document RFC 792 précité. Lorsque le ou les messages d'erreur ICMP reçus satisfont une règle définit au cours de la phase de configuration, par exemple la règle associée aux flux média RTP de type audio selon 10 laquelle si le nombre de messages ICMP associés aux flux média RTP de type audio sur une période de 1 seconde est supérieur ou égal à 20, une notification de dépassement de seuil est émise. En d'autres termes, si durant la période « Observation-Period » le nombre de paquet ICMP reçus associés aux flux média RTP de type audio est au moins égal à « Packet-Count », 15 l'action spécifique « THRESHOLD REPORT)> est émise de l'entité d'exécution PCEF 231 vers l'entité de gestion de règles PCRF 22, qui la transfère à son tour vers l'entité de contrôle AF 21. Plus précisément, si le nombre de paquets ICMP reçus durant la période d'observation atteint le seuil défini pour les flux média RTP de type audio, l'entité d'exécution PCEF 231 émet un message de détection d'erreur de type CCR (« Credit-Control-Request ») vers l'entité de gestion 20 de règles PCRF 22, en précisant qu'il s'agit de l'évènement Event-Trigger « TH RESHOLD_REPORT » pour le flux ICMP surveillé. Par exemple, le message CCR de détection d'erreur prend la forme suivante : CCR (Event-Trigger = « THRESHOLD REPORT » Threshold-Monitored-Flows = X 25 Flow-Number = Y) où l'AVP « Threshold-Monitored-Flows » permet d'identifier le flux surveillé (ICMP) et l'AVP « Flow-Number » permet d'identifier le type de média qui a généré le dépassement de seuil (flux audio selon l'exemple ci-dessus). Par exemple, l'AVP « Threshold-Monitored-Flows » est de type « Grouped », et défini 30 comme suit : Threshold-Monitored-Flows ::= [ Flow-Number ] 16 On peut alors mettre fin à l'observation pour ce flux ICMP. En variante, la surveillance est maintenue tant qu'une condition d'arrêt n'est pas remplie. A réception du message CCR de détection d'erreur par l'entité de gestion de règles PCRF 22, cette dernière peut accuser réception par l'envoi d'un message CCA (« Credit-Control- 5 Answer ») à l'entité d'exécution PCEF 231. Lorsque l'entité de gestion de règles PCRF 22 reçoit, de l'entité d'exécution PCEF 231, le message CCR de détection d'erreur, et en particulier l'AVP « Event-Trigger » contenant la valeur « THRESHOLD_REPORT », l'entité de gestion de règles PCRF 22 fournit l'information à l'entité de contrôle AF 21. 10 Pour ce faire, l'entité de gestion de règles PCRF 22 met en forme le message CCR de détection d'erreur et l'envoie à l'entité de contrôle AF 21 sous la forme d'un message RAR de détection d'erreur, par exemple : RAR (Specific-Action = « THRESHOLD REPORT » Threshold-Monitored-Flows = X 15 Flow-Number = Y) L'entité de contrôle AF 21 reçoit ainsi un message RAR de détection d'erreur portant l'AVP d'action spécifique « THRESHOLD_REPORT » et éventuellement l'AVP identifiant le flux surveillé ayant conduit à l'émission d'un message de détection d'erreur (AVP « Threshold-MonitoredFlows ))). 20 A réception du message RAR de détection d'erreur par l'entité de contrôle AF 21, cette dernière peut accuser réception par l'envoi d'un message RAA à l'entité de gestion de règles PCRF 22. L'entité de contrôle AF 21 peut alors engager une action sur la communication multimédia, par exemple l'arrêt immédiat de la communication, l'émission d'un message 25 approprié dans le plan de contrôle, et/ou l'émission d'une alarme opérateur, et/ou la modification de compteurs statistiques, et/ou l'insertion d'une information dans un ticket de taxation, etc. De cette façon, on dispose d'un nouveau mécanisme pour détecter un problème de communication, compatible avec les équipements utilisant la technologie VoLTE ou VoWiFi. 30 5.3 Structures On présente finalement, en relation avec les figures 4 à 6, les structures simplifiées d'une entité d'exécution, d'une entité de contrôle, et d'une entité de gestion de règles selon l'un des modes de réalisation décrits ci-dessus. En variante, ces trois entités sont des entités purement 17 logicielles. Comme illustré en figure 4, une entité d'exécution comprend une mémoire 41 comprenant une mémoire tampon, une unité de traitement 42, équipée par exemple d'une machine de calcul reprogrammable ou d'une machine de calcul dédiée, par exemple un 5 processeur P, et pilotée par le programme d'ordinateur 43, mettant en oeuvre le procédé de détection d'un problème de communication multimédia selon un mode de réalisation de l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 43 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de 10 traitement 42. L'unité de traitement 42 reçoit en entrée au moins un message appartenant à au moins un flux à surveiller. Le processeur de l'unité de traitement 42 met en oeuvre les étapes du procédé de détection d'un problème de communication multimédia décrit précédemment, selon les instructions du programme d'ordinateur 43, pour générer un message de détection d'erreur si le 15 ou les messages reçus correspondent à une règle préalablement définie. Comme illustré en figure 5, une entité de contrôle comprend une mémoire 51 comprenant une mémoire tampon, une unité de traitement 52, équipée par exemple d'une machine de calcul reprogrammable ou d'une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d'ordinateur 53, mettant en oeuvre le procédé de 20 gestion d'un problème de communication multimédia selon un mode de réalisation de l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 53 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 52. L'unité de traitement 52 reçoit en entrée au moins un message de détection 25 d'erreur. Le processeur de l'unité de traitement 52 met en oeuvre les étapes du procédé de gestion d'un problème de communication multimédia décrit précédemment, selon les instructions du programme d'ordinateur 53, pour engager une action spécifique, comme l'interruption de la communication, si un message de détection d'erreur est reçu. 30 Enfin, comme illustré en figure 6, une entité de gestion de règles comprend une mémoire 61 comprenant une mémoire tampon, une unité de traitement 62, équipée par exemple d'une machine de calcul reprogrammable ou d'une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d'ordinateur 63, mettant en oeuvre le procédé de relais 18 d'un problème de communication multimédia selon un mode de réalisation de l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 63 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 62. L'unité de traitement 62 reçoit en entrée un message de détection d'erreur. 5 Le processeur de l'unité de traitement 62 met en oeuvre les étapes du procédé de relais d'un problème de communication multimédia décrit précédemment, selon les instructions du programme d'ordinateur 63, pour relayer le message de détection d'erreur à l'entité REVENDICATIONS1. Procédé de détection d'un problème de communication multimédia, mis en oeuvre par une entité d'exécution, caractérisé en ce qu'il comprend une phase de traitement (11) mettant en oeuvre : la réception (111E) d'au moins un message, dit message reçu, appartenant à au moins un flux à surveiller se rapportant à au moins un flux média, la vérification (113E) d'une correspondance entre ledit au moins un message reçu et au moins une règle associée audit au moins un flux à surveiller, et lorsque ledit au moins un message reçu correspond à ladite règle, l'envoi (114E) à une entité de contrôle, par l'intermédiaire d'une entité de gestion de règles, d'un message de détection d'erreur. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une phase de configuration (10) préalable à ladite phase de traitement, mettant en oeuvre la réception d'un message de requête en notification de détection d'erreur, transmis par ladite entité de contrôle par l'intermédiaire de ladite entité de gestion de règles, ledit message de requête en notification de détection d'erreur portant ladite au moins une règle. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que, ladite au moins une règle définissant un seuil de détection d'un problème de communication à partir d'un nombre prédéterminé de messages et une période prédéterminée, ledit message de détection d'erreur est généré, et envoyé à ladite entité de contrôle, lorsque le nombre de messages reçus pendant ladite période prédéterminée est supérieur ou égal au nombre prédéterminé de messages. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit au moins un flux à surveiller est de type ICMP. 5. Procédé de gestion d'un problème de communication multimédia, mis en oeuvre par une entité de contrôle, caractérisé en ce qu'il comprend une phase de traitement (11) mettant en oeuvre : la réception (117c) d'un message de détection d'erreur, généré par une entité d'exécution en tenant compte d'au moins une règle associée à au moins un flux à surveiller se rapportant à au moins un flux média, et transmis par l'intermédiaire d'une entité de gestion de règles, et une action (118c) sur ladite communication à réception dudit message de détection d'erreur. 20 6. Procédé selon la revendication 5, caractérisé en ce que ladite action appartient au groupe comprenant : interruption de ladite communication, émission d'un message spécifique, 5 émission d'une alarme, modification d'au moins un compteur statistique, insertion d'une information dans un ticket de taxation. 7. Procédé selon l'une quelconque des revendications 5 et 6, caractérisé en ce qu'il comprend une phase de configuration (10) préalable à ladite phase de traitement, mettant en 10 oeuvre : la définition (101c) de ladite au moins une règle ; et la transmission (102c) d'un message de requête en notification de détection d'erreur à ladite entité d'exécution, par l'intermédiaire de ladite entité de gestion de règles, ledit message de requête en notification de détection d'erreur portant ladite au moins une 15 règle. 8. Procédé selon la revendication 7, caractérisé en ce que ladite au moins une règle définit un seuil de détection d'un problème de communication à partir d'un nombre prédéterminé de messages reçus sur une période prédéterminée. 9. Procédé selon l'une quelconque des revendications 7 et 8, caractérisé en ce que ledit 20 message de requête en notification de détection d'erreur porte également un attribut relatif à au moins un type de flux autorisé pour transporter des informations sur des flux média. 10. Procédé de relais d'un problème de communication multimédia, mis en oeuvre par une entité de gestion de règles, caractérisé en ce qu'il comprend une phase de traitement (11) mettant en oeuvre : 25 la réception (115R) d'un message de détection d'erreur, généré par une entité d'exécution en tenant compte d'au moins une règle associée à au moins un flux à surveiller se rapportant à au moins un flux média, et la transmission (116R) dudit message de détection d'erreur à une entité de contrôle. 11. Procédé selon la revendication 10, caractérisé en ce qu'il comprend une phase de 30 configuration (10) préalable à ladite phase de traitement, mettant en oeuvre : la réception (103R) d'un message de requête en notification de détection d'erreur, transmis par ladite entité de contrôle, ledit message de requête en notification de détection d'erreur portant ladite au moins une règle, et 21 - la transmission (104R) dudit message de requête en notification de détection d'erreur à ladite entité d'exécution. 12. Entité d'exécution apte à détecter un problème de communication multimédia, caractérisée en ce qu'elle comprend : 5 un module de réception d'au moins un message, dit message reçu, appartenant à au moins un flux à surveiller se rapportant à au moins un flux média, un module de vérification d'une correspondance entre ledit au moins un message reçu et au moins une règle associée audit au moins un flux à surveiller, et un module d'envoi à une entité de contrôle, par l'intermédiaire d'une entité de gestion de 10 règles, d'un message de détection d'erreur lorsque ledit au moins un message reçu correspond à ladite règle. 13. Entité de contrôle apte à gérer un problème de communication multimédia, caractérisée en ce qu'elle comprend : un module de réception d'un message de détection d'erreur, généré par une entité 15 d'exécution en tenant compte d'au moins une règle associée à au moins un flux à surveiller se rapportant à au moins un flux média, et transmis par l'intermédiaire d'une entité de gestion de règles, et un module d'action sur ladite communication à réception dudit message de détection d'erreur. 20 14. Entité de gestion de règles apte à relayer un problème de communication multimédia, caractérisé en ce qu'elle comprend : un module de réception d'un message de détection d'erreur, généré par une entité d'exécution en tenant compte d'au moins une règle associée à au moins un flux à surveiller se rapportant à au moins un flux média, et 25 un module de transmission dudit message de détection d'erreur à une entité de contrôle. 15. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 11 lorsque ce programme est exécuté par un processeur.