FR2977430A1 - Procede de filtrage de flux early media dans un reseau ims et serveur mettant en oeuvre ce procede - Google Patents

Abstract

Ce procédé de filtrage est mis en œuvre par un serveur (TERM) dans un réseau IMS, au cours d'une phase d'établissement d'un appel entre un terminal appelant (UA) et un terminal appelé (UB). Il comporte : - une étape (G20) de réception d'un message d'invitation SIP émis par une entité amont (UA, ORIG) en coupure de flux entre le terminal appelant (UA) et ledit serveur (TERM) ; -une étape (G40) d'envoi au serveur S-CSCF gérant la signalisation du terminal appelé (UB), d'un message SIP REGISTER comportant l'identité publique IMPU de l'appelé afin de déterminer les adresses de contact (UB1, UB2) enregistrées en cœur de réseau IMS avec ladite identité IMPU ainsi que la priorité de ces adresses de contact ; - une étape (G80) de détermination d'un ordre de priorité entre lesdites adresses de contact et éventuellement d'autres terminaux de l'appelé, à partir desdites priorités et, le cas échéant, de priorités desdits terminaux ; - une étape (G90) de prolongation dudit message d'invitation SIP vers un serveur CSCF traitant lesdites au moins une adresse de contact (UB1, UB2) ou vers un des terminaux en fonction dudit ordre de priorité ; - une étape (G120) de sélection d'un flux média à restituer audit terminal appelant en fonction de la priorité des adresses de contact et des terminaux ayant répondu (G100) audit message d'invitation SIP ; et - une étape (G140) d'envoi, à ladite entité amont, d'une seule réponse SIP de type 1xx, choisie en fonction dudit flux média pour permettre sa restitution audit terminal appelant.

Description

Arrière-plan de l'invention

La présente invention se situe dans le domaine des télécommunications et plus précisément dans celui des réseaux IMS (pour IP Multimedia Subsystem),.

Dans un réseau IMS, les services sont fournis par des serveurs d'application AS (pour Application Server). Parmi ces serveurs d'application, il est connu de distinguer les serveurs qui offrent un service déclenché à l'émission de l'appel, autrement connu de l'homme du métier sous le nom de « service originating ». Un serveur offrant un service originating est habituellement désigné « serveur originating ». De la même façon, on appelle communément « serveur terminating », un serveur d'application AS offrant un service déclenché à la réception de l'appel, un tel service étant désigné sous le nom de « service terminating ». Certains services originating et terminating connus à ce jour génèrent des flux média à destination du terminal appelant pendant la phase d'établissement d'appel. Ces flux sont souvent désignés sous le nom de « flux early media ». On rappelle que la phase d'établissement d'appel désigne toute la phase comprise entre l'émission du message d'invitation SIP INVITE (SIP pour Session Initiation Protocol) par le terminal appelant et la réception par ce terminal appelant d'une réponse SIP finale de type 2xx, 3xx, 4xx, 5xx, 6xx par exemple une réponse d'acquittement positive 200 OK ou bien un réponse d'acquittement négatif de type 403 Forbidden lorsque l'appel n'est pas autorisé. A titre d'exemple de flux early media connus de l'homme du métier, on peut notamment citer l'annonce vocale émise par un serveur média piloté par un serveur originating lorsque l'appelant utilise le service de consultation des appels entrants n'ayant pas débouché avec possibilité de rappel ou le retour d'appel personnalisé (Colored Ring Back Tone) restitué par un serveur média piloté par le serveur terminating du terminal appelé ou par le terminal appelé. Avec le déploiement de services de plus en plus complexes, il advient fréquemment qu'un équipement SIP soit amené à traiter plusieurs dialogues SIP concurrents en phase d' établissement d'appel, chacun de ces dialogues étant associé ou non à un flux early media. A ce jour, les instances de normalisation (IETF, 3GPP, ...) n'apportent pas de solution pour restituer de manière déterministe une pluralité de flux early media destinés à un même terminal appelant. 1 Objet et résumé de l'invention

L'invention concerne un procédé de filtrage mis en oeuvre par un serveur dans un premier réseau IMS, au cours d'une phase d'établissement d'un appel entre un terminal appelant et un terminal appelé. Ce procédé comporte : - une étape de réception d'un message d'invitation SIP émis par une entité amont en coupure de flux entre le terminal appelant et ce serveur ; - une étape d'envoi au serveur S-CSCF gérant la signalisation du terminal appelé, d'un message SIP REGISTER comportant l'identité publique IMPU de l'appelé afin de déterminer les adresses de contact enregistrées en coeur de réseau IMS avec cette identité IMPU ainsi que la priorité de ces adresses de contact ; - une étape de détermination d'un ordre de priorité entre ces adresses de contact et éventuellement d'autres terminaux de l'appelé, à partir desdites priorités et le cas échéant de priorités de ces terminaux - une étape de prolongation du message d'invitation SIP vers un serveur S-CSCF traitant au moins une de ces adresses de contact ; - une étape de sélection d'un flux média à restituer au terminal appelant en fonction de la priorité des adresses de contact et des terminaux ayant répondu à ce message d'invitation SIP ; et - une étape d'envoi, à l'entité amont, d'une seule réponse SIP de type ixx, choisie en fonction de ce flux média pour permettre sa restitution au terminal appelant. Corrélativement, l'invention concerne un serveur appartenant à un premier réseau IMS ce serveur comportant, des moyens pour mettre en oeuvre, au cours d'une phase d'établissement d'un appel entre un terminal appelant et un terminal appelé : - des moyens de réception d'un message d'invitation SIP émis par une entité amont en coupure de flux entre le terminal appelant et le serveur ; - des moyens d'envoi, au serveur S-CSCF gérant la signalisation du terminal appelé, d'un message SIP REGISTER comportant l'identité publique IMPU du terminal appelé afin de déterminer les adresses de contact enregistrées en coeur de réseau IMS avec cette identité IMPU ainsi que la priorité de ces adresses de contact ; - des moyens de détermination d'un ordre de priorité entre ces adresses de contact et éventuellement d'autres terminaux de l'appelé, à partir de ces priorités et, le cas échéant, de priorités desdits terminaux; 2 - des moyens de prolongation du message d'invitation SIP vers un serveur S-CSCF traitant au moins une de ces adresses de contact ou vers un des terminaux, en fonction de l'ordre de priorité ; - des moyens de sélection d'un flux média à restituer au terminal appelant en fonction de la priorité des adresses de contact et des terminaux ayant répondu au message d'invitation SIP ; et - des moyens d'envoi, à l'entité amont, d'une seule réponse SIP de type 1xx, choisie en fonction dudit flux média pour permettre sa restitution au terminal appelant. Dans ce document, on désignera par « entité amont », le terminal appelant, ou toute entité du réseau IMS placée en coupure de flux entre le terminal appelant et le serveur selon l'invention et par « entité aval », le terminal appelé, ou toute entité du réseau IMS placée en coupure de flux entre le serveur selon l'invention et le terminal appelé. L'homme du métier comprendra que les serveurs originating de l'appelant et le serveur terminating de l'appelé constituent respectivement des entités amont et aval au sens de l'invention. Lorsque le terminal appelant appartient à un réseau circuit RTC/GSM, une entité amont est par exemple un serveur MGCF. Lorsque le terminal appelant appartient à un autre réseau IMS que l'appelé, une entité amont peut être un serveur d'interconnexion IBCF.

La notation « réponse SIP de type 1xx », désigne toute réponse SIP dont le type commence par le chiffre « 1 » et notamment les réponses SIP 180 Ringing et 183 In Progress. Ainsi, et de façon très avantageuse, les flux média envoyés à l'entité amont (par exemple au terminal appelant), au cours de la phase d'établissement d'appel, ces flux média étant connus de l'homme du métier sous le nom de « flux early media », sont systématiquement contrôlés par le serveur selon l'invention, une seule réponse SIP de type 1xx remontant vers le terminal appelant. Cette caractéristique permet avantageusement de définir, de façon parfaitement prédictible, le scénario et l'ordonnancement de restitution des flux early media par le terminal appelant. Dans un mode particulier de réalisation de l'invention, le serveur selon l'invention est un serveur terminating. Dans un mode particulier de réalisation, le procédé de filtrage selon l'invention comporte : - une étape de réservation d'une première ressource auprès d'un serveur MRF (pour Multimedia Resource Function) dudit réseau ; - une étape de réservation d'au moins une deuxième ressource auprès du serveur MRF, ledit message d'invitation SIP prolongé vers le dit serveur S-CSCF comportant un champ SDP (pour Session Description Protocol) identifiant cette deuxième ressource ; - une étape de contrôle dudit serveur MRF pour qu'il restitue, dans la première ressource, ledit flux media sélectionné. Cette caractéristique permet avantageusement de définir, de façon parfaitement prédictible, le scénario et l'ordonnancement de restitution de plusieurs flux early media par le terminal appelant tout en optimisant les ressources du réseau IMS à travers lesquelles ces flux early média transitent.

Dans un mode particulier de réalisation, le procédé de filtrage selon l'invention comporte : - une étape d'envoi, à ladite entité amont, d'une réponse SIP de type 183 In Progress comportant un champ SDP identifiant ladite première ressource ; - une étape de contrôle dudit serveur MRF pour qu'il restitue, dans cette première ressource un premier flux média généré par le serveur. Cette caractéristique est particulièrement avantageuse car elle permet de restituer les différents flux early media à l'appelant dans une même ressource d'un serveur MRF contrôlé par le serveur selon l'invention. Cette caractéristique permet avantageusement de définir, de façon parfaitement prédictible, le scénario et l'ordonnancement de restitution de plusieurs flux early media par le terminal appelant. Dans un mode de réalisation de l'invention, le message de réponse SIP envoyé à l'entité amont peut être : - un message de type 180 Ringing, sans SDP, si aucune réponse de type 1xx avec un champ SDP n'est reçue; ou - le message de type ixx avec SDP reçu. Dans un mode de réalisation de l'invention, le procédé selon l'invention comporte, lorsque le flux média à restituer est reçu sur la deuxième ressource, une étape de contrôle du serveur MRF pour qu'il effectue un filtrage des paquets reçus sur la deuxième ressource pour ne répliquer sur la première ressource, que ceux du flux média à restituer. Dans un mode de réalisation de l'invention, le serveur selon l'invention comporte des moyens pour déclencher un flux média de retour de sonnerie sur la première ressource lorsque le message sélectionné est de type 1xx sans SDP.

Un scénario complet de sélection du flux média à restituer à l'appelant sera détaillé ci-après.

Dans un mode particulier de réalisation, les différentes étapes du procédé de filtrage selon l'invention sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un serveur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de filtrage tel que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Brève description des dessins

D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous en référence aux dessins qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : - les figures 1 et 2 représentent sous forme de chronogramme et d'organigramme un procédé de filtrage conforme à un mode particulier de réalisation de l'invention ; - la figure 3 représente l'architecture matérielle d'un serveur conforme à un mode particulier de réalisation de l'invention.

Description détaillée de l'invention

En référence à la figure 1, nous allons maintenant décrire un procédé de filtrage conforme à un mode particulier de réalisation de l'invention. Afin de ne pas surcharger la figure, les réponses SIP 100 TRYING ne sont pas représentées. Dans l'exemple de réalisation décrit ici, le serveur selon l'invention est un serveur d'application AS terminating (réferencé TERM sur les figures). Dans ce premier exemple de réalisation, ce serveur Terminating ne génère pas de flux early média. Dans l'exemple de réalisation décrit ici, on se place dans le contexte dans lequel un utilisateur souhaite être mis en relation avec un abonné SIP du même réseau IMS. Pour cela, l'utilisateur compose à l'aide de son terminal UA le numéro de l'abonné appelé UB. Nous supposerons ici que deux terminaux SIP portant la même identité publique IMPU de l'abonné appelé sont enregistrés en coeur du réseau IMS. Lorsque le terminal appelant UA compose le numéro de l'abonné appelé, le terminal UA envoie, à destination du serveur CSCF un message SIP de type INVITE dont le champ SDP de description de session comporte les informations liées aux codecs supportés par le terminal UA, et l'adresse IP et port sur lequel le terminal UA s'attend à recevoir le flux média négocié. Lorsque le serveur CSCF reçoit le message SIP INVITE en provenance du terminal UA, ce dernier pilote le SPDF de manière à réserver une ressource au niveau du CBGF permettant ainsi de forcer les flux médias émis et reçus par le terminal appelant UA à transiter par l'équipement CBGF et modifie le SDP du message INVITE pour remplacer l'adresse IP et port du terminal UA par l'adresse IP et port sur lequel le serveur CBGF utilisé par le terminal UA s'attend à recevoir le flux média négocié. Ainsi le message SIP INVITE émis par le CSCF vers le serveur AS originating ORIG contient le champ SDP=CBGF-UA. Sur réception du message INVITE, le serveur originating ORIG déclenche les services originating de l'appelant, par exemple le service de positionnement du masquage du numéro appelant ou la vérification que le numéro de l'appelé composé est autorisé. Dans le mode de réalisation décrit ici, ces services ne génèrent pas de flux early média à transmettre à l'appelant. Le message INVITE est ensuite retransmis au CSCF de l'appelant qui le route selon la méthode normalisée IMS vers le CSCF traitant l'appelé SIP. Le CSCF de l'appelé déclenche de manière connue le serveur AS TERM en étape G20 par l'envoi d'un message d'invitation INVITE. 6 Selon une autre variante de réalisation de l'invention, l'appelant peut appartenir à un réseau circuit RTC/GSM, dans ce cas, le message INVITE reçu par le serveur AS TERM provient d'un serveur MGCF. Selon une autre variante de réalisation de l'invention, l'appelant peut appartenir à un réseau IMS différent du réseau IMS de l'appelé, dans ce cas, le message INVITE reçu par le serveur AS TERM provient d'un serveur IBCF. Conformément à l'invention, le serveur terminating TERM cherche à anticiper l'environnement de forking géré par le serveur CSCF appelé vers plusieurs terminaux appelés UB, au sens de la norme RFC 3261 précitée. A cet effet, il envoie lors d'une étape G40 au serveur S-CSCF gérant la signalisation du terminal ou des terminaux appelé UB, un message SIP REGISTER comportant l'identité publique IMPU de l'appelé, le champ d'adresse de contact AoC étant vide. Conformément à la norme RFC3261, le serveur S-CSCF répond lors d'une étape G60 à ce message par une réponse 200 OK comportant la liste des adresses de contacts enregistrées en coeur de réseau IMS avec cette identité publique IMPU, et pour chacun d'entre elles la durée d'enregistrement restante ainsi que la priorité q définie par cette norme, sachant que si le paramètre q n'est pas fourni, cela équivaut à une priorité implicite la plus faible, c'est-à-dire q=0. Conformément à l'invention, le serveur terminating TERM détermine, au cours d'une étape G80, un ordre de priorité entre ces adresses de contact, à partir desdites priorités q. En pratique, cette étape consiste à déterminer si l'on se trouve dans un cas de forking (plus d'une adresse de contact dans la réponse SIP 200 OK du message SIP REGISTER) et si c'est le cas, s'il s'agit d'un forking séquentiel, parallèle ou mixte.

Le serveur terminating TERM prolonge ensuite, au cours d'une étape G90, le message d'invitation SIP vers le serveur S-CSCF de l'appelé qui le dédouble vers chacun des terminaux associés respectivement à une adresse de contact conformément au mécanisme de forking décrit dans le document RFC 3261. Le serveur S-CSCF de l'appelé modifie le champ SDP en remplaçant l'adresse IP et numéro de port correspondant au CBGF-UA par l'adresse IP et numéro de port correspondant au CBGF-UB de manière à forcer les flux média émis et reçus à transiter par le CBGF de l'appelé UB. Dans l'exemple de réalisation décrit ici, ce message INVITE est prolongé par le SCSCF de l'appelé vers les terminaux UB1 et UB2. Conformément à l'invention, le serveur terminating TERM sélectionne un flux média à restituer au terminal appelant UA en fonction de la priorité q des adresses de contact ayant répondu au message d'invitation SIP, ces réponses étant reçues au cours d'une étape G100. Nous décrivons ci-dessous une stratégie possible du serveur terminating TERM : En l'absence de forking Dans le mode de réalisation décrit ici, en l'absence de forking, lorsqu'un seul terminal UB1 est enregistré en coeur de réseau IMS, le serveur AS terminating TERM transmet le message SIP INVITE (SDP=CBGF-UA) initialement reçu à l'étape G20 vers le S-CSCF, éventuellement après avoir appliqué des services terminating. L'appel est donc présenté au terminal appelé unique UB1. Si ce terminal appelé ne génère pas de flux early media, il répond 180 Ringing sans SDP et cette réponse est transmise par l'AS terminating vers l'amont. Le terminal appelant joue alors un retour de sonnerie RBT localement. S'il y avait un service Originating de l'appelant générant un flux early Media, un serveur MRF piloté par le serveur AS originating ORIG jouerait la sonnerie d'appel au terminal appelant UA. Si le terminal appelé génère un flux early media, il répond 180 Ringing (SDP=UB1) et le serveur S-CSCF de l'appelé pilote le SPDF qui réserve une ressource sur le CBGF et modifie le champ SDP de la réponse 180 Ringing. Le codec sélectionné par le terminal UB1 est conservé dans le SDP mais l'adresse IP et numéro de port du terminal UB1 sont remplacés par l'adresse IP et numéro de port du CBGF appelé de manière à forcer les flux média émis et reçus par le terminal appelé B à transiter dans le CBGF. La réponse est transmise par l'AS Terminating vers l'amont et le terminal appelant UA joue ce flux early média.

En présence de forking simultané uniquement Dans l'exemple de réalisation décrit ici, l'AS Terminating attend de l'ordre de une à quelques secondes (par exemple cinq) pour recueillir le maximum de réponses et choisir la plus appropriée à remonter : si aucune réponse ne comporte un champ SDP (pas d'early media), le serveur AS Terminating TERM envoie une seule réponse 180 Ringing sans SDP vers le serveur AS Originating amont, qui lui-même le renvoie vers le terminal appelant UA. Comme la réponse 180 Ringing ne comporte pas de champ SDP, le terminal appelant UA joue localement le retour d'appel RBT ; - si au moins une réponse comporte un champ SDP (présence d'un Early Media), le serveur AS terminating TERM sélectionne celle qui a été reçue la première et envoie un message 180 Ringing (SDP=CBGF-B1/B2) vers le serveur AS Originating amont qui lui-même le renvoie vers le terminal appelant UA. Comme il y a un SDP, l'appelant restitue le flux Early Media joué par le terminal de l'appelé qui a répondu le premier. Dans les 2 cas les autres réponses 1xx reçues et non sélectionnées sont filtrées par l'AS TERM.

En présence de forking séquentiel uniquement Dans ce mode de réalisation, l'AS terminating TERM restitue la réponse du terminal le plus prioritaire vers l'amont. Le terminal appelant UA joue localement un retour d'appel RBT si l'adresse de contact appelée la plus prioritaire ne génère pas de flux Early Media, ou le flux Early Media joué par l'adresse de contact la plus prioritaire de l'appelé.

En présence d'un forking mixte Dans le mode de réalisation décrit ici, le serveur terminating TERM considère la toute première phase de présentation d'appel vers le ou les terminaux ayant la plus haute priorité. Il applique ensuite la politique décrite ci-dessus de « forking simultané uniquement » ou de « forking séquentiel uniquement » en fonction du type simultané/séquentiel de la première phase de présentation d'appel.

De retour à la figure 1, on supposera que les deux terminaux UB1, UB2 génèrent de l'early media et répondent (étape G100) par un message 180 Ringing avec SDP UB1/UB2. Les SDP de ces 2 réponses sont modifiés par le CSCF qui pilote le SPDF qui lui-même pilote le CBGF de manière à faire transiter les flux média émis et reçus par l'équipement CBGF. En conséquence, l'AS TERM reçoit les réponses 180 Ringing avec SDP CBGF-U1 et SDP CBGF-U2. On suppose que ces deux terminaux ont le même paramètre de priorité q. A l'étape G120, le serveur terminating TERM sélectionne le flux média du terminal UB1, la réponse de ce dernier ayant été reçue en premier.

Le serveur terminating TERM envoie, au cours d'une étape G140, au serveur originating amont ORIG une réponse SIP 180 RINGING SDP=CBGF-UB1. Cette réponse est prolongée vers le terminal UA, comme de façon connue et le terminal UA reçoit le flux early media généré par le terminal UB1. Conformément à l'invention, une seule réponse ixx est transmise vers l'amont et le serveur S-CSCF de l'appelant UA ne reçoit pas la réponse 180 RINGING SDP=CBGF- UB2. Par conséquent, le flux early media généré par UB2 est bloqué par l'entité CBGF de l'appelant et n'est pas restituée au terminal appelant UA. En référence à la figure 2, nous allons maintenant décrire un procédé de filtrage conforme à un autre mode particulier de réalisation de l'invention. Les étapes déjà décrites en référence à la figure 1 ne seront pas détaillées. Dans ce deuxième exemple de réalisation, le serveur Terminating TERM réserve au préalable une première ressource pour transmettre les flux Early Media vers l'amont et une deuxième ressource afin de recevoir les éventuels flux Early Média en provenance de l'aval. Ce deuxième exemple de réalisation offre l'avantage d'optimiser les ressources du réseau IMS en ne renvoyant vers le CBGF de l'appelant que le flux early média correspondant à la réponse sélectionnée. Dans ce deuxième exemple de réalisation, le serveur Terminating TERM peut offrir le service Terminating de renvoi vers n destinations en mode séquentiel ou simultané connu de l'homme du métier. Ce service, noté ci-après FLS, est un service de forking applicatif qui consiste à renvoyer un appel destiné à un abonné appelé du réseau IMS vers une ou plusieurs destinations secondaires définies au préalable par l'abonné appelé. Pour assurer le service FLS, le serveur terminating TERM demande à l'entité MRF pilotée par l'AS TERM de générer un flux early media systématique pour faire patienter l'usager du terminal appelant le temps de joindre les terminaux en série jusqu'à ce qu'un d'entre eux décroche. Dans l'exemple de réalisation décrit ici, après réception du message INVITE (étape G20), le serveur terminating TERM établit un dialogue SIP avec le serveur MRF de l'appelé pour réserver une première ressource MRF1 (étape G200). Le serveur terminating TERM détermine ensuite au cours d'un test G21 si l'appelé est abonné au service de renvoi FLS. Bien entendu, le serveur terminating TERM pourrait aussi offrir des services sans forking applicatif ou ne générant pas de flux early média.

1. Scénario sans forking areicatif Dans ce cas, l'appelé n'est pas abonné au service de renvoi FLS, le serveur terminating TERM ne met pas en oeuvre de forking applicatif. Le résultat du test G21 est négatif. Ce test est alors suivi par la séquence des étapes G40-G80 au cours de laquelle le serveur terminating TERM établit une priorité entre les adresses de contact enregistrées dans le réseau IMS avec l'identité publique de l'appelé (forking réseau au sens de la norme RFC 3261). Dans ce mode de réalisation de l'invention, lorsqu'il n'y a pas de forking applicatif, le serveur AS terminating TERM établit un dialogue SIP avec le serveur MRF pour réserver une seule ressource MRF2, au cours d'une étape G81. De façon remarquable, le message d'invitation SIP INVITE envoyé au cours de cette étape G90 vers le S-CSCF comporte un champ SDP qui identifie cette deuxième ressource. Dans l'exemple décrit ici, le serveur S-CSCF prolonge le message INVITE vers chacun de ces deux terminaux UB1, UB2 en remplaçant l'adresse IP et numéro de port de la deuxième ressource par l'adresse IP et numéro de port du CBGF appelé de manière à faire transiter les flux média émis et reçu par cet équipement..

Nous supposerons, dans cet exemple, que les deux terminaux UB1, UB2 génèrent de l'early media et répondent (étape G100) par un message 180 Ringing avec SDP UB1/UB2, le champ SDP étant modifié par le CSCF avec la valeur CBGF-UB1/UB2 pour forcer les flux à transiter dans le CBGF de l'appelé. Ces deux flux early media sont donc reçus dans la même ressource MRF2.

On suppose que les deux terminaux UB1, UB2 ont le même paramètre de priorité q et que le serveur terminating TERM sélectionne (G120), par application de la politique de sélection décrite précédemment, le flux média du terminal UB1. Le serveur terminating TERM contrôle le serveur MRF pour qu'il demande à la ressource MRF2 de filtrer le flux early média reçu et émis par le terminal UB2 en lui fournissant l'adresse IP et numéro de port de l'expéditeur de ce flux early media (sur la base des informations contenues dans le SDP du 1)x reçu et bloqué par l'AS TERM) et réplique dans la première ressource MRF1, les paquets reçus dans la deuxième ressource MRF2, seuls ceux émis par le terminal UB1 étant retenus. Le serveur terminating TERM envoie, au cours d'une étape G140, au serveur originating amont ORIG une réponse SIP 180 RINGING SDP=MRF1. Cette réponse est prolongée vers le terminal UA, comme de façon connue et le terminal UA reçoit le flux early media généré par le terminal UB1. Ainsi, de façon avantageuse, un seul flux média est transmis dans le réseau vers le CBGF de l'appelant.

Dans le cas où les terminaux UB1 et UB2 répondraient par un 180 Ringing sans SDP donc sans générer de flux early média, le serveur TERM piloterait le MRF pour qu'il joue le retour de sonnerie sur la ressource MRF1.

2. Scénario avec forkina applicatif Dans ce scénario, l'appelé est abonné au service FLS. Le résultat du test G21 est positif, le serveur terminating TERM doit alors piloter un serveur MRF afin d'envoyer à l'appelant un flux early média correspondant au message d'attente du service de renvoi. Au cours d'une étape G210, le serveur AS terminating TERM envoie une réponse SIP de type 183 In Progress vers l'amont, en réponse au message d'invitation reçu à l'étape G20, le champ SDP de cette réponse comportant l'identifiant MRF1 de la ressource. Au cours d'une étape G220, le serveur AS terminating TERM contrôle le serveur MRF pour qu'il restitue, dans la première ressource MRF1, le flux média associé au service FLS, destiné à faire patienter l'appelant. Dans l'exemple de réalisation décrit ici, le serveur terminating TERM doit mettre en place, dans le cadre du service FLS, un forking applicatif. Ce forking applicatif peut être séquentiel ou simultané selon le service défini par l'abonné appelé. Selon le type de forking applicatif, le serveur terminating TERM doit prolonger de manière simultanée ou de manière séquentielle la requête SIP d'invitation INVITE reçue à l'étape G20 vers plusieurs entités aval. Ces entités aval pouvant appartenir au même réseau IMS que l'identité publique de l'appelé, ou à un réseau circuit RTC/GSM ou encore à un autre réseau IMS. Le serveur terminating TERM détermine dans cet exemple, l'identité publique de la destination la plus prioritaire (étape G150), et traite cette identité publique comme décrit précédemment par application des étapes G40 à G90. Dans le mode de réalisation décrit ici, pour chaque identité publique d'une destination moins prioritaire, le serveur terminating TERM réserve une deuxième ressource spécifique MRFi auprès du serveur MRF (étape G155) et prolonge le message d'invitation INVITE vers cette destination, le champ SDP comportant l'identifiant MRFi de la ressource réservée pour cette destination. Chaque destination recevant le message d'invitation INVITE est susceptible d'envoyer une réponse au serveur terminating TERM sous la forme d'un message de type 1xx avec ou sans SDP, via si besoin un serveur MGCF ou IBCF selon le type de réseau auquel appartient la destination. Si le serveur terminating TERM décide, par application de la politique précitée, de restituer le flux early média de cette destination moins prioritaire au terminal appelant UA, il lui suffit de répliquer sur la première ressource MRF1, les paquets reçus sur la ressource MRFi, sans filtrage particulier au niveau paquet.

Lorsqu'il n'y a pas de destination prioritaire, par exemple si tous les terminaux ont la même priorité, ou si la destination prioritaire ne renvoie pas de réponse, la sélection du flux média à répliquer est faite en fonction d'un ordre de priorité associé aux différentes réponses 1xx reçues. Un tel ordre de priorité peut par exemple être déterminé en fonction du type 1xx et de la présence ou non d'un champ SDP dans la réponse. Un ordre de priorité des réponses reçues peut être défini tel que la réponse la plus prioritaire est une réponse 183 In Progress, puis 180 Ringing avec SDP et enfin 180 Ringing sans SDP. En variante, il est aussi possible de partager une même ressource entre plusieurs identités publiques et, lorsque le flux média à restituer a été sélectionné, de contrôler le serveur MRF pour qu'il demande à la ressource concernée de filtrer le flux early média reçu et émis par les terminaux à l'origine des flux early media non retenus en lui fournissant l'adresse IP et numéro de port de l'expéditeur de ces flux. Ainsi, dans ce scénario avec forking applicatif, le terminal appelant UA reçoit le flux early média généré par un des terminaux de l'abonné appelé depuis la même ressource MRF1 que celle utilisée pour le flux early media généré par le service de renvoi d'appel séquentiel FLS.

La figure 3 représente l'architecture d'un serveur d'application AS conforme à l'invention. Dans le mode de réalisation décrit ici, ce serveur a l'architecture matérielle d'un ordinateur. Il comporte un processeur 10, une mémoire morte de type ROM 11, une mémoire vive de type RAM 12 et des moyens de communication 14 aptes à mettre en oeuvre le protocole SIP pour communiquer avec d'autres entités mettant en oeuvre le même protocole dans un réseau IMS. La mémoire morte de type ROM 11 constitue un support au sens de l'invention. Plus précisément, cette mémoire morte comporte un programme d'ordinateur PGT dont les instructions, lorsqu'elles sont exécutées par le processeur 10 mettent en oeuvre le procédé de filtrage dont les principales étapes ont été décrites en référence à la figure 2. Les moyens 14 de communication du serveur AS sont aptes à recevoir, émettre et interpréter un message d'invitation SIP, à créer une réponse SIP comportant ou non un champ SDP, à envoyer une telle réponse sur le réseau IMS, à émettre un message SIP Register à un serveur S-CSCF et à interpréter sa réponse, notamment pour déterminer la priorité q de terminaux comportant une même identité IMPU conformément à la norme RFC 3261.

Le processeur 10, lorsqu'il exécute le programme d'ordinateur PGT est apte à sélectionner un flux média à restituer à un terminal SIP, en fonction de ces priorités et à filtrer les différentes réponses SIP 1xx. Le processeur 10, lorsqu'il exécute le programme d'ordinateur PGT permet au serveur AS TERM de réserver une ou plusieurs ressources auprès d'un serveur MRF et à contrôler un serveur MRF pour lui faire jouer un retour d'appel RBT ou restituer un flux média sur une ressource donnée et à répliquer une première ressource sur une deuxième ressource, puis contrôler le MRF pour filtrer certains flux média reçus.

Claims (6)

1. REVENDICATIONS1. Procédé de filtrage mis en oeuvre par un serveur (TERM) dans un réseau IMS, au cours d'une phase d'établissement d'un appel entre un terminal appelant (UA) et un terminal appelé (UB), ce procédé comportant : - une étape (G20) de réception d'un message d'invitation SIP émis par une entité amont (UA, ORIG) en coupure de flux entre le terminal appelant (UA) et ledit serveur (TERM) ; - une étape (G40) d'envoi au serveur S-CSCF gérant la signalisation du terminal appelé (UB), d'un message SIP REGISTER comportant l'identité publique IMPU de l'appelé afin de déterminer les adresses de contact (UB1, UB2) enregistrées en coeur de réseau IMS avec ladite identité IMPU ainsi que la priorité de ces adresses de contact ; - une étape (G80) de détermination d'un ordre de priorité entre lesdites adresses de contact et éventuellement d'autres terminaux de l'appelé, à partir desdites priorités et, le cas échéant, de priorités desdits terminaux ; - une étape (G90) de prolongation dudit message d'invitation SIP vers un serveur CSCF traitant lesdites au moins une adresse de contact (UB1, UB2) ou vers un des terminaux en fonction dudit ordre de priorité ; - une étape (G120) de sélection d'un flux média à restituer audit terminal appelant en fonction de la priorité des adresses de contact et des terminaux ayant répondu (G100) audit message d'invitation SIP ; et - une étape (G140) d'envoi, à ladite entité amont, d'une seule réponse SIP de type ixx, choisie en fonction dudit flux média pour permettre sa restitution audit terminal appelant.
2. 2. Procédé de filtrage selon la revendication 1 caractérisé en ce qu'il comporte : - une étape (G200) de réservation d'une première ressource (MRF1) auprès d'un serveur MRF dudit réseau ; - une étape (G81) de réservation d'au moins une deuxième ressource auprès du serveur MRF, ledit message d'invitation SIP prolongé (G90) vers le dit serveur CSCF comportant un champ SDP identifiant cette deuxième ressource ; - une étape de contrôle dudit serveur MRF pour qu'il restitue, dans la première ressource, ledit flux media sélectionné.
3. 3. Procédé de filtrage selon la revendication 2 caractérisé en ce qu'il comporte : - une étape (G210) d'envoi, à ladite entité amont, d'une réponse SIP de type 183 In Progress comportant un champ SDP identifiant ladite première ressource (MRF1) ;- une étape (G220) de contrôle dudit serveur MRF pour qu'il restitue, dans ladite première ressource (MRF1), un premier flux média généré par ledit serveur (TERM).
4. 4. Procédé selon la revendication 1, caractérisé en ce que ledit message de type 1xx sélectionné est : - un message de type 180 Ringing, sans SDP, si aucune réponse de type 1xx avec un champ SDP n'est reçue; ou - le message de type ixx avec SDP reçu.
5. 5. Procédé selon la revendication 2, caractérisé en ce qu'il comporte, ledit flux média à restituer étant reçu sur ladite deuxième ressource, une étape de contrôle dudit serveur MRF pour qu'il effectue un filtrage des paquets reçus sur la deuxième ressource pour ne répliquer sur la première ressource, que ceux dudit flux média à restituer.
6. 6. Serveur (TERM) appartenant à un premier réseau IMS, caractérisé à ce qu'il comporte des moyens pour mettre en oeuvre, au cours d'une phase d'établissement d'un appel entre un terminal appelant (UA) et un terminal appelé (UB) : - des moyens (14) de réception d'un message d'invitation SIP émis par une entité amont (UA, ORIG) en coupure de flux entre le terminal appelant (UA) et ledit serveur (TERM) ; - des moyens (14) d'envoi, au serveur S-CSCF gérant la signalisation du terminal appelé (UB), d'un message SIP REGISTER comportant l'identité publique IMPU de l'appelé afin de déterminer les adresses des contacts (UB1, UB2) enregistrées en coeur de réseau IMS avec ladite identité IMPU ainsi que la priorité de ces adresses de contact ; - des moyens (11, PGT) de détermination d'un ordre de priorité entre lesdites adresses de contact et éventuellement d'autres terminaux de l'appelé, à partir desdites priorités, et le cas échéant, des priorités dedits terminaux ; - des moyens (14) de prolongation dudit message d'invitation SIP vers un serveur CSCF traitant lesdites au moins une adresses de contact (UB1, UB2) ou vers un desdits terminaux en fonction dudit ordre de priorité ; - des moyens (11, GPT) de sélection d'un flux média à restituer audit terminal appelant en fonction de la priorité desdites adresses de contact et des terminaux ayant répondu (G100) audit message d'invitation SIP ; et - des moyens (14) d'envoi, à ladite entité amont, d'une seule réponse SIP de type 1xx, choisie en fonction dudit flux média pour permettre sa restitution audit terminal appelant.357 Serveur selon la revendication 6, caractérisé en ce qu'il comporte des moyens pour déclencher un flux média de retour de sonnerie sur la première ressource lorsque le message sélectionné est de type 1xx sans SDP. 8. Programme d'ordinateur (PGT) comportant des instructions pour l'exécution des étapes du procédé de filtrage selon la revendication 1 lorsque ledit programme est exécuté par un ordinateur (AS). 9. Support d'enregistrement (11) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de filtrage selon la revendication 1.