FR2977430A1

FR2977430A1 - METHOD OF FILTERING EARLY MEDIA FLOW IN AN IMS NETWORK AND SERVER IMPLEMENTING SAID METHOD

Info

Publication number: FR2977430A1
Application number: FR1102073A
Authority: FR
Inventors: Bertrand Bouvet
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2011-06-30
Filing date: 2011-06-30
Publication date: 2013-01-04
Also published as: WO2013001213A1

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.This filtering method is implemented by a server (TERM) in an IMS network, during a call setup phase between a calling terminal (UA) and a called terminal (UB). It comprises: - a step (G20) of receiving a SIP invitation message transmitted by an upstream entity (UA, ORIG) with a break in flow between the calling terminal (UA) and said server (TERM); -a step (G40) of sending to the S-CSCF server managing the signaling of the called terminal (UB), a SIP REGISTER message comprising the public identity IMPU of the called party in order to determine the contact addresses (UB1, UB2) recorded in the heart of the IMS network with said IMPU identity as well as the priority of these contact addresses; - a step (G80) of determining an order of priority between said contact addresses and possibly other terminals of the called party, based on said priorities and, where applicable, priorities of said terminals; - a step (G90) of extending said SIP invitation message to a CSCF server processing said at least one contact address (UB1, UB2) or to one of the terminals according to said order of priority; - a step (G120) of selecting a media stream to be returned to said calling terminal according to the priority of the contact addresses and of the terminals having responded (G100) to said SIP invitation message; and - a step (G140) of sending, to said upstream entity, a single SIP response of type 1xx, chosen according to said media stream to allow its restitution to said calling terminal.

Description

Arrière-plan de l'invention Background of the 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),. The present invention is in the field of telecommunications and more specifically in that of IMS networks (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 In an IMS network, the services are provided by application servers AS (for Application Server). Among these application servers, it is known to distinguish the servers that provide a triggered service to the transmission of the call, otherwise known to those skilled in the art under the name "service originating". A server offering an originating service is usually referred to as an "originating server". In the same way, the term "terminating server" is commonly called an AS application server offering a service triggered upon receipt of the call, such service being referred to as "service terminating". Some originating and terminating services known to date generate media streams to the calling terminal during the call setup phase. These streams are often referred to as "early media streams". It is recalled that the call set-up phase designates the entire phase comprised between the sending of the invitation SIP INVITE message (SIP for Session Initiation Protocol) by the calling terminal and the reception by this calling terminal of a SIP response. type 2xx, 3xx, 4xx, 5xx, 6xx for example a positive acknowledgment response 200 OK or a negative acknowledgment response of type 403 Forbidden when the call is not authorized. As an example of early media flow known to those skilled in the art, mention may in particular be made of the voice announcement sent by a media server controlled by an originating server when the caller uses the incoming call consultation service that has not been used. no outlet with possibility of callback or the personalized callback (Colored Ring Back Tone) returned by a media server controlled by the terminating server of the called terminal or by the called terminal. With the deployment of increasingly complex services, it frequently happens that SIP equipment has to deal with several competing SIP dialogues during the call establishment phase, each of these dialogues being associated or not with an early media flow. To date, the standardization bodies (IETF, 3GPP, ...) do not provide a solution to deterministically restore a plurality of early media streams intended for the same calling terminal. 1 Object and summary of the 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. The invention relates to a filtering method implemented by a server in a first IMS network, during a phase of establishment of a call between a calling terminal and a called terminal. This method comprises: a step of receiving a SIP invitation message sent by an upstream entity in a flow cutoff between the calling terminal and this server; a step of sending to the S-CSCF server managing the signaling of the called terminal, of a SIP REGISTER message comprising the public identity IMPU of the called party in order to determine the contact addresses registered at the core of the IMS network with this identity. IMPU as well as the priority of these contact addresses; a step of determining an order of priority between these contact addresses and possibly other terminals of the called party, based on said priorities and, if appropriate, the priorities of these terminals; a step of extending the invitation message; SIP to an S-CSCF server processing at least one of these contact addresses; a step of selecting a media stream to be restored to the calling terminal according to the priority of the contact addresses and the terminals having responded to this SIP invitation message; and - a step of sending, to the upstream entity, a single SIP response type ixx, chosen according to this media stream to allow its return to the calling terminal. Correlatively, the invention relates to a server belonging to a first IMS network this server comprising, means for implementing, during a phase of establishment of a call between a calling terminal and a called terminal: - means receiving a SIP invitation message sent by an upstream entity in a flow failure between the calling terminal and the server; means for sending, to the S-CSCF server managing the signaling of the called terminal, a SIP REGISTER message comprising the public identity IMPU of the called terminal in order to determine the contact addresses registered at the core of the IMS network with this identity. IMPU as well as the priority of these contact addresses; means for determining an order of priority between these contact addresses and possibly other terminals of the called party, based on these priorities and, where appropriate, priorities of said terminals; 2 - means for extending the SIP invitation message to an S-CSCF server processing at least one of these contact addresses or to one of the terminals, according to the order of priority; means for selecting a media stream to be restored to the calling terminal according to the priority of the contact addresses and the terminals having responded to the SIP invitation message; and means for sending, to the upstream entity, a single SIP response of type 1xx, chosen as a function of said media stream to enable its return to the calling terminal. In this document, the term "upstream entity", the calling terminal, or any entity of the IMS network placed in flux between the calling terminal and the server according to the invention and "downstream entity", the called terminal, or any entity of the IMS network placed in a power failure between the server according to the invention and the called terminal. Those skilled in the art will understand that the originating servers of the calling party and the terminating server of the called party respectively constitute upstream and downstream entities within the meaning of the invention. When the calling terminal belongs to a PSTN / GSM circuit network, an upstream entity is for example an MGCF server. When the calling terminal belongs to another IMS network than the called party, an upstream entity may be an IBCF interconnection server.

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. The "1xx SIP reply" notation refers to any SIP response whose type begins with the digit "1" and in particular the SIP 180 Ringing and 183 In Progress responses. Thus, and very advantageously, the media streams sent to the upstream entity (for example to the calling terminal), during the call establishment phase, these media streams being known to those skilled in the art under the "early media flow" name, are systematically controlled by the server according to the invention, a single 1xx type SIP response back to the calling terminal. This characteristic advantageously makes it possible to define, in a perfectly predictable way, the scenario and the scheduling of restitution of the early media flows by the calling terminal. In a particular embodiment of the invention, the server according to the invention is a terminating server. In a particular embodiment, the filtering method according to the invention comprises: a step of reserving a first resource with an MRF (Multimedia Resource Function) server of said network; a step of reserving at least one second resource with the MRF server, said extended SIP invitation message to said S-CSCF server comprising a SDP (Session Description Protocol) field identifying said second resource; a step of controlling said MRF server to restore, in the first resource, said selected media stream. This characteristic advantageously makes it possible to define, in a perfectly predictable manner, the scenario and the scheduling of rendering of several early media streams by the calling terminal while optimizing the resources of the IMS network through which these early media flows transit.

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. In a particular embodiment, the filtering method according to the invention comprises: a step of sending, to said upstream entity, a 183 In Progress SIP response comprising an SDP field identifying said first resource; a step of controlling said MRF server to restore, in this first resource, a first media stream generated by the server. This characteristic is particularly advantageous because it makes it possible to restore the various early media streams to the caller in the same resource of an MRF server controlled by the server according to the invention. This characteristic advantageously makes it possible to define, in a perfectly predictable manner, the scenario and the scheduling of rendering of several early media streams by the calling terminal. In one embodiment of the invention, the SIP response message sent to the upstream entity may be: a 180 Ringing message, without SDP, if no 1xx response with an SDP field is received; or - the message of type ixx with SDP received. In one embodiment of the invention, the method according to the invention comprises, when the media stream to be restored is received on the second resource, a control step of the MRF server for it to filter the packets received on the second resource to replicate on the first resource, only those of the media stream to render. In one embodiment of the invention, the server according to the invention comprises means for triggering a ringback return media stream on the first resource when the selected message is 1xx type without SDP.

Un scénario complet de sélection du flux média à restituer à l'appelant sera détaillé ci-après. A complete scenario for selecting the media stream to be returned to the caller will be detailed below.

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. In a particular embodiment, the various steps of the filtering method according to the invention are determined by instructions of computer programs. Consequently, the invention also relates to a computer program on an information carrier, this program being capable of being implemented by a server, this program comprising instructions adapted to the implementation of the steps of a filtering process as mentioned above. This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape. The invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above. The information carrier may be any entity or device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a diskette (floppy disc) or a disk hard. On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention can be downloaded in particular on an Internet type network. Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.

Brève description des dessins Brief description of the drawings

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. Other features and advantages of the present invention will emerge from the description given below with reference to the drawings which illustrate an embodiment having no limiting character. In the figures: FIGS. 1 and 2 represent, in the form of a chronogram and a flowchart, a filtering method according to a particular embodiment of the invention; - Figure 3 shows the hardware architecture of a server according to a particular embodiment of the invention.

Description détaillée de l'invention Detailed description of the 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. Referring to Figure 1, we will now describe a filtering method according to a particular embodiment of the invention. In order not to overload the figure, the SIP 100 TRYING responses are not represented. In the exemplary embodiment described here, the server according to the invention is an AS terminating application server (referenced TERM in the figures). In this first exemplary embodiment, this Terminating server does not generate an early media stream. In the exemplary embodiment described here, one places oneself in the context in which a user wishes to be put in contact with a SIP subscriber of the same IMS network. For this, the user dials with his terminal UA the number of the called subscriber UB. We will assume here that two SIP terminals with the same public identity IMPU of the called subscriber are registered in the heart of the IMS network. When the calling terminal UA dials the number of the called subscriber, the terminal UA sends, to the server CSCF, an SIP message of INVITE type whose session description SDP field includes the information related to the codecs supported by the terminal UA, and the IP address and port on which the UA terminal expects to receive the negotiated media stream. When the CSCF server receives the SIP INVITE message from the terminal UA, the latter controls the SPDF so as to reserve a resource at the CBGF thereby forcing the media streams sent and received by the calling terminal UA to pass through the CBGF equipment and modifies the SDP of the INVITE message to replace the IP address and port of the UA terminal by the IP address and port on which the CBGF server used by the UA terminal expects to receive the negotiated media stream. Thus the SIP INVITE message sent by the CSCF to the AS originating ORIG server contains the SDP = CBGF-UA field. On receipt of the INVITE message, the originating ORIG server triggers the originating services of the caller, for example the calling number masking positioning service or the verification that the dialed number of the called party is authorized. In the embodiment described here, these services do not generate an early media stream to be transmitted to the caller. The INVITE message is then forwarded to the CSCF of the calling party who routes it according to the standardized IMS method to the CSCF processing the called SIP. The called party's CSCF triggers the AS TERM server in a known manner in step G20 by sending an INVITE invitation message. According to another embodiment of the invention, the caller may belong to a PSTN / GSM circuit network, in which case the INVITE message received by the AS TERM server originates from an MGCF server. According to another embodiment of the invention, the caller may belong to an IMS network different from the called party's IMS network, in which case the INVITE message received by the AS TERM server originates from an IBCF server. According to the invention, the terminating server TERM seeks to anticipate the forking environment managed by the called CSCF server to several terminals called UB, within the meaning of the aforementioned RFC 3261 standard. For this purpose, it sends during a step G40 to the S-CSCF server managing the signaling of the terminal or terminals called UB, a SIP REGISTER message including the public identity IMPU called, the contact address field AoC being empty. In accordance with the RFC3261 standard, the S-CSCF server responds in a G60 step to this message by a 200 OK response including the list of contact addresses registered at the heart of the IMS network with this public identity IMPU, and for each of them. between them the remaining recording time as well as the priority q defined by this standard, knowing that if the parameter q is not provided, this equates to a lowest implicit priority, that is to say q = 0 . According to the invention, the terminating server TERM determines, during a step G80, an order of priority between these contact addresses, from said priorities q. In practice, this step consists in determining if one is in a case of forking (more than one contact address in the SIP 200 OK response of the SIP REGISTER message) and if it is, if it is is sequential, parallel or mixed forking.

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. The terminating server TERM then extends, during a step G90, the SIP invitation message to the S-CSCF server of the called party which splits it to each of the terminals respectively associated with a contact address in accordance with the forking mechanism. described in RFC 3261. The S-CSCF server of the called party modifies the SDP field by replacing the IP address and port number corresponding to the CBGF-UA by the IP address and port number corresponding to the CBGF-UB of in order to force the transmitted and received media flows to pass through the CBGF of the called party UB. In the exemplary embodiment described here, this INVITE message is extended by the SCSCF of the called party to the terminals UB1 and UB2. According to the invention, the terminating server TERM selects a media stream to be restored to the calling terminal UA as a function of the priority q of the contact addresses that have responded to the SIP invitation message, these responses being received during a step G100 . We describe below a possible strategy of the terminating TERM server: In the absence of forking In the embodiment described here, in the absence of forking, when a single terminal UB1 is registered at the core of IMS network, the server AS terminating TERM transmits the SIP INVITE message (SDP = CBGF-UA) initially received in step G20 to the S-CSCF, possibly after applying terminating services. The call is therefore presented to the terminal called unique UB1. If this called terminal does not generate an early media stream, it responds 180 Ringing without SDP and this response is forwarded by the AS terminating upstream. The calling terminal then plays a RBT ringback ring locally. If there was a call originating service generating an early media flow, an MRF server controlled by the originating ORIG server AS would play the ringing tone to the calling terminal UA. If the called terminal generates an early media stream, it responds 180 Ringing (SDP = UB1) and the called party's S-CSCF server pilots the SPDF which reserves a resource on the CBGF and modifies the SDP field of the 180 Ringing response. The codec selected by the terminal UB1 is kept in the SDP but the IP address and port number of the terminal UB1 are replaced by the IP address and port number of the called CBGF so as to force the media streams transmitted and received by the terminal called B to transit in the CBGF. The response is transmitted by the AS Terminating upstream and the calling terminal UA plays this early media flow.

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. In the presence of simultaneous forking only In the exemplary embodiment described here, the AS Terminating waits on the order of one to a few seconds (for example five) to collect the maximum of responses and choose the most appropriate to go back up: if no answer does not include an SDP field (no early media), the AS Terminating TERM server sends a single 180 Ringing response without SDP to the upstream AS Originating server, which itself sends it back to the calling terminal UA. Since the 180 Ringing response does not include an SDP field, the calling terminal UA locally plays the RBT callback; - if at least one response has an SDP field (presence of an Early Media), the AS terminating TERM server selects the one that was received first and sends a 180 Ringing message (SDP = CBGF-B1 / B2) to the server AS Originating upstream which itself returns it to the calling terminal UA. As there is a SDP, the caller restores the Early Media feed played by the terminal of the called party who answered first. In both cases the other 1xx responses received and not selected are filtered by the 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é. In the presence of sequential forking only In this embodiment, the AS terminating TERM restores the response of the highest priority terminal upstream. The calling terminal UA locally plays RBT call back if the highest priority contact address does not generate an Early Media feed, or the Early Media feed played by the highest priority contact address of the called party.

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. In the presence of a mixed forking In the embodiment described here, the terminating server TERM considers the very first phase of call presentation to the terminal or terminals having the highest priority. It then applies the above-described policy of "simultaneous forking only" or "sequential forking only" depending on the simultaneous / sequential type of the first call presentation phase.

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. Returning to FIG. 1, it will be assumed that the two terminals UB1, UB2 generate early media and respond (step G100) by a 180 Ringing message with SDP UB1 / UB2. The SDP of these 2 responses are modified by the CSCF which controls the SPDF which itself controls the CBGF so as to transit the media streams transmitted and received by the CBGF equipment. As a result, the AS TERM receives 180 Ringing responses with SDP CBGF-U1 and SDP CBGF-U2. It is assumed that these two terminals have the same priority parameter q. In step G120, the terminating server TERM selects the media stream of the terminal UB1, the answer of the latter having been received first.

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. The terminating server TERM sends, during a step G140, to the originating upstream server ORIG a SIP response 180 RINGING SDP = CBGF-UB1. This response is extended to the terminal UA, as in a known manner and the terminal UA receives the early media stream generated by the terminal UB1. According to the invention, a single answer ixx is transmitted upstream and the S-CSCF server of the calling party UA does not receive the response 180 RINGING SDP = CBGF-UB2. As a result, the early media stream generated by UB2 is blocked by the calling party's CBGF and is not restored to the calling terminal UA. Referring to Figure 2, we will now describe a filtering method according to another particular embodiment of the invention. The steps already described with reference to FIG. 1 will not be detailed. In this second exemplary embodiment, the Terminating TERM server first reserves a first resource for transmitting the Early Media feeds upstream and a second resource to receive the possible Early Media feeds from the downstream. This second embodiment has the advantage of optimizing the resources of the IMS network by returning to the caller's CBGF only the early media flow corresponding to the selected response. In this second exemplary embodiment, the Terminating TERM server may offer the terminating service Terminating to n destinations in sequential or simultaneous mode known to those skilled in the art. This service, hereinafter referred to as FLS, is an application forking service that consists of forwarding a call intended for a called subscriber of the IMS network to one or more secondary destinations defined beforehand by the called subscriber. To provide the FLS service, the terminating TERM server requests the AS TERM-driven MRF entity to generate a systematic early media flow to make the calling terminal user wait for the time to join the serial terminals until that one of them answers. In the exemplary embodiment described here, after receiving the INVITE message (step G20), the terminating server TERM establishes a SIP dialogue with the called party's MRF server to reserve a first resource MRF1 (step G200). The terminating TERM server then determines during a G21 test whether the called party is subscribed to the FLS forwarding service. Of course, terminating TERM server could also offer services without application forking or not generating early media flow.

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.. 1. Scenario without forking isicative In this case, the called party is not subscribed to the FLS forwarding service, the terminating TERM server does not implement application forking. The result of the G21 test is negative. This test is then followed by the sequence of steps G40-G80 during which the terminating TERM server prioritizes between the contact addresses registered in the IMS network with the public identity of the called party (forking network in the sense of the RFC 3261). In this embodiment of the invention, when there is no application forking, the AS terminating server TERM establishes a SIP dialogue with the MRF server to reserve a single resource MRF2, during a step G81. Remarkably, the SIP INVITE invitation message sent during this step G90 to the S-CSCF includes an SDP field which identifies this second resource. In the example described here, the S-CSCF server extends the INVITE message to each of these two terminals UB1, UB2 by replacing the IP address and port number of the second resource with the IP address and port number of the CBGF. called in order to transit the media streams sent and received by this equipment.

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. We will assume, in this example, that the two terminals UB1, UB2 generate early media and respond (step G100) by a 180 Ringing message with SDP UB1 / UB2, the SDP field being modified by the CSCF with the value CBGF- UB1 / UB2 to force the streams to pass through the CBGF of the called party. These two early media streams are therefore received in the same resource 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. It is assumed that the two terminals UB1, UB2 have the same priority parameter q and that the terminating server TERM selects (G120), by application of the selection policy described above, the media stream of the terminal UB1. The terminating TERM server controls the MRF server to request the resource MRF2 to filter the early media stream received and transmitted by the terminal UB2 by providing it with the IP address and port number of the sender of this early media stream. (on the basis of the information contained in the SDP of the 1) x received and blocked by the AS TERM) and replicates in the first resource MRF1, the packets received in the second resource MRF2, only those sent by the terminal UB1 being retained. The terminating server TERM sends, during a step G140, to the upstream orig originating server a SIP response 180 RINGING SDP = MRF1. This response is extended to the terminal UA, as in a known manner and the terminal UA receives the early media stream generated by the terminal UB1. Thus, advantageously, a single media stream is transmitted in the network to the caller's CBGF.

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. In the event that the terminals UB1 and UB2 respond with a 180 Ringing without SDP without generating an early media flow, the TERM server would drive the MRF to play the ring back on the resource 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. 2. Scenario with application forkina In this scenario, the called user is subscribed to the FLS service. The result of the G21 test is positive, the terminating TERM server must then drive an MRF server to send the caller an early media flow corresponding to the waiting message of the referral service. During a step G210, the AS terminating server TERM sends a 183 In Progress SIP response upstream, in response to the invitation message received in step G20, the SDP field of this response including the identifier MRF1 of the resource. During a step G220, the AS terminating server TERM controls the MRF server to restore, in the first resource MRF1, the media stream associated with the FLS service, intended to make the caller wait. In the exemplary embodiment described here, the terminating server TERM must set up, as part of the FLS service, an application forking. This application forking can be sequential or simultaneous depending on the service defined by the called subscriber. Depending on the type of application forking, the terminating TERM server must extend simultaneously or sequentially the INVITE invitation SIP request received in step G20 to several downstream entities. These downstream entities may belong to the same IMS network as the public identity of the called party, or to a PSTN / GSM circuit network or to another IMS network. The terminating TERM server determines in this example, the public identity of the highest priority destination (step G150), and treats this public identity as previously described by applying steps G40 to G90. In the embodiment described here, for each public identity of a less priority destination, the terminating server TERM reserves a second specific resource MRFi with the MRF server (step G155) and extends the invitation message INVITE to this destination, the SDP field with the identifier MRFi of the resource reserved for this destination. Each destination receiving the INVITE invitation message is likely to send a response to the terminating TERM server in the form of a 1xx message with or without SDP, via MGCF or IBCF server depending on the type of network to which it belongs. the destination. If the terminating TERM server decides, by applying the aforementioned policy, to restore the early media flow of this less priority destination to the calling terminal UA, it is sufficient for it to replicate on the first resource MRF1, the packets received on the resource MRFi, without particular filtering at the packet level.

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. When there is no priority destination, for example if all the terminals have the same priority, or if the priority destination does not return a response, the selection of the media stream to replicate is made according to a priority order. priority associated with the different 1xx responses received. Such an order of priority may for example be determined according to the 1xx type and the presence or absence of an SDP field in the response. An order of priority of the responses received can be defined such that the highest priority response is a 183 In Progress response, then 180 Ringing with SDP and finally 180 Ringing without SDP. As a variant, it is also possible to share the same resource between several public identities and, when the media stream to be restored has been selected, to control the MRF server to ask the resource concerned to filter the received early media stream and issued by the terminals at the origin of unretained early media flows by providing the IP address and port number of the sender of these flows. Thus, in this scenario with application forking, the calling terminal UA receives the early media flow generated by one of the terminals of the subscriber called from the same resource MRF1 that used for the early media flow generated by the call forwarding service. sequential 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. FIG. 3 represents the architecture of an AS application server according to the invention. In the embodiment described here, this server has the hardware architecture of a computer. It comprises a processor 10, a read-only memory ROM 11, a RAM RAM 12 and communication means 14 able to implement the SIP protocol to communicate with other entities implementing the same protocol in a IMS network. ROM type ROM 11 is a medium in the sense of the invention. More specifically, this read-only memory comprises a computer program PGT whose instructions, when executed by the processor 10, implement the filtering method whose main steps have been described with reference to FIG. of the AS server are able to receive, transmit and interpret a SIP invitation message, to create a SIP response with or without an SDP field, to send such a response on the IMS network, to send a SIP Register message to a S-CSCF server and interpret its response, in particular to determine the priority q of terminals with the same identity IMPU according to 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. The processor 10, when it executes the computer program PGT, is able to select a media stream to be restored to a SIP terminal, according to these priorities and to filter the different SIP 1xx responses. The processor 10, when executing the PGT computer program, allows the AS TERM server to reserve one or more resources with an MRF server and to control an MRF server to make it play a RBT call return or to restore an media stream on a given resource and replicate a first resource on a second resource, and then control the MRF to filter certain received media streams.

Claims

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. REVENDICATIONS1. A filtering method implemented by a server (TERM) in an IMS network, during a phase of establishment of a call between a calling terminal (UA) and a called terminal (UB), this method comprising: a step (G20) for receiving a SIP invitation message sent by an upstream entity (UA, ORIG) in a flow-off between the calling terminal (UA) and said server (TERM); a step (G40) of sending to the server S-CSCF managing the signaling of the called terminal (UB), of a SIP REGISTER message comprising the public identity IMPU of the called party in order to determine the contact addresses (UB1, UB2) registered at the core of the IMS network with said identity IMPU as well as the priority of these contact addresses; a step (G80) of determining an order of priority between said contact addresses and possibly other terminals of the called party, from said priorities and, if appropriate, priorities of said terminals; a step (G90) of extending said SIP invitation message to a CSCF server processing said at least one contact address (UB1, UB2) or to one of the terminals according to said priority order; a step (G120) for selecting a media stream to be restored to said calling terminal as a function of the priority of the contact addresses and the terminals that responded (G100) to said SIP invitation message; and - a step (G140) of sending, to said upstream entity, a single SIP response type ixx, chosen according to said media stream to allow its return to said calling terminal.

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é. 2. Filtering method according to claim 1 characterized in that it comprises: - a step (G200) for reserving a first resource (MRF1) with an MRF server of said network; a step (G81) of reservation of at least one second resource to the MRF server, said extended SIP invitation message (G90) to said CSCF server comprising an SDP field identifying this second resource; a step of controlling said MRF server to restore, in the first resource, said selected media stream.

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). 3. Filtering method according to claim 2, characterized in that it comprises: a step (G210) of sending, to said upstream entity, a 183 In Progress SIP response comprising an SDP field identifying said first resource; (MRF1) - a step (G220) for controlling said MRF server to restore, in said first resource (MRF1), a first media stream generated by said server (TERM).

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. 4. Method according to claim 1, characterized in that said selected 1xx type message is: a 180 Ringing type message, without SDP, if no 1xx type response with an SDP field is received; or - the message of type ixx with SDP received.

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. 5. Method according to claim 2, characterized in that it comprises, said media stream to be restored being received on said second resource, a step of controlling said MRF server for it to filter received packets on the second resource for replicate to the first resource, only those of said media stream to be rendered.

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. 6. Server (TERM) belonging to a first IMS network, characterized in that it comprises means for implementing, during a phase of establishment of a call between a calling terminal (UA) and a terminal called (UB): means (14) for receiving a SIP invitation message sent by an upstream entity (UA, ORIG) in a flow-off between the calling terminal (UA) and said server (TERM); means (14) for sending, to the server S-CSCF managing the signaling of the called terminal (UB), a SIP REGISTER message comprising the public identity IMPU of the called party in order to determine the addresses of the contacts (UB1 , UB2) registered at the core of the IMS network with said identity IMPU as well as the priority of these contact addresses; - means (11, PGT) for determining an order of priority between said contact addresses and possibly other terminals of the called party, from said priorities, and if necessary, the priorities of said terminals; means (14) for extending said SIP invitation message to a CSCF server processing said at least one contact address (UB1, UB2) or to one of said terminals according to said priority order; means (11, GPT) for selecting a media stream to be restored to said calling terminal as a function of the priority of said contact addresses and the terminals that responded (G100) to said SIP invitation message; and means (14) for sending, to said upstream entity, a single SIP response of type 1xx, chosen as a function of said media stream to enable it to be restored to said calling terminal.357 Server according to claim 6, characterized in that it includes means for triggering a ringback return media stream on the first resource when the selected message is 1xx without SDP. A computer program (PGT) comprising instructions for executing the steps of the filtering method according to claim 1 when said program is executed by a computer (AS). Computer-readable recording medium (11) on which is recorded a computer program comprising instructions for performing the steps of the filtering method according to claim 1.