Brevet FR2977433A1 — publié le 20130104

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. Dans un réseau IMS (pour IP Multimedia Subsystem), les services sont fournis par des serveurs d'application AS. 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 (pour Application Server) 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 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 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. 135 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 de réservation d'une première ressource et d'une deuxième ressource auprès d'un serveur de ressource du premier réseau ; - une étape d'envoi d'une réponse SIP à l'entité amont précitée, cette réponse comportant un champ SDP (pour Session Description Protocol) identifiant la première ressource ; - une étape d'envoi d'un message d'invitation SIP à destination d'au moins une entité aval choisie en fonction du terminal appelé, ce message d'invitation comportant un champ SDP identifiant la deuxième ressource ; - une étape de réception d'au moins une réponse SIP de type ixx en provenance d'au moins une de ces entités aval ; et - une étape de sélection d'un flux média en fonction de la ou de ces réponses reçues ; - une étape de contrôle du serveur de ressource pour qu'il restitue ce flux média dans la première ressource, à destination du 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 ce serveur; - des moyens de réservation d'une première ressource et d'une deuxième ressource auprès d'un serveur de ressource dudit premier réseau ; - des moyens d'envoi d'une réponse SIP à ladite entité amont comportant un champ SDP identifiant ladite première ressource ; - des moyens d'envoi d'un message d'invitation SIP à destination d'au moins une entité aval choisie en fonction du terminal appelé, ce message d'invitation comportant un champ SDP identifiant la deuxième ressource ; - des moyens de réception d'au moins une réponse SIP de type ixx en provenance d'au moins une desdites entités aval; - des moyens de sélection d'un flux média en fonction de la ou des réponses reçues ; et 2 - des moyens de contrôle du serveur de ressource pour qu'il restitue ce flux média dans la première ressource, à destination du 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. 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 restitués dans une même ressource d'un serveur de ressources 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 des flux early media. Dans une première variante de réalisation de l'invention, le serveur selon l'invention est un serveur originating, le serveur de ressource précité étant un serveur MRF (pour Multimedia Resource Function). Dans cette première variante de réalisation, le procédé de filtrage selon l'invention comporte une étape de blocage de la réponse SIP de type ixx reçue de l'entité aval. Par « blocage », on entend que cette réponse SIP n'est pas transmise à l'entité amont. Cette caractéristique permet avantageusement d'éviter que le terminal appelant ne génère lui-même un retour d'appel. Dans un mode particulier de cette première variante de réalisation de l'invention, le procédé de filtrage selon l'invention comporte une étape de contrôle du serveur MRF pour qu'il restitue, dans la première ressource, un premier flux média généré par lui-même. La réponse SIP envoyée à l'entité amont est dans ce cas une réponse SIP de type 183 In Progress. Elle est préférentiellement envoyée juste après la réservation de la première ressource pour que ce premier flux early media soit reçu au plus vite par le terminal appelant. Dans un mode particulier de réalisation de cette première variante de réalisation de l'invention, l'étape de réservation de la deuxième ressource est effectuée sur réception d'une notification du serveur MRF. En pratique, cette notification pourra être émise par le serveur MRF sur détection d'une action explicite de l'utilisateur du terminal appelant (saisie d'une séquence de touches DTMF, commande vocale, ...) pour déclencher un nouveau service susceptible de générer un nouveau flux early media, toujours en phase d'établissement d'appel, concurrent du premier flux early media déclenché par le serveur originating lui-même. Dans une deuxième variante de réalisation de l'invention, le serveur selon l'invention est un serveur d'interconnexion entre le premier réseau IMS (auquel il appartient) et un deuxième réseau IMS (auquel appartiennent le terminal appelé et l'entité aval), le serveur de ressource étant une entité I-BGF (pour Interconnection Border Gateway Function) Dans un mode particulier de réalisation de cette deuxième variante, la réponse SIP envoyée à l'entité amont est du type de la réponse SIP reçue de l'entité aval. Dans un mode de réalisation de la première ou de la deuxième variante de réalisation de l'invention, le flux média sélectionné et restitué sur la première ressource peut être : - un flux média reçu dans la deuxième ressource si la réponse SIP de type 1xx reçue de l'entité aval comporte un champ SDP ; ou - un signal de retour d'appel généré par le serveur de ressource dans les autres cas. Dans un mode particulier de réalisation de la première ou de la deuxième variante de l'invention, le flux média est sélectionné en fonction d'un paramètre de priorité de l'entité aval à l'origine de la réponse reçue, au sens d'un service de forking tel que défini dans la norme RFC SIP 3261. Dans un mode particulier de réalisation, le serveur selon l'invention comporte des moyens pour déclencher un flux média de retour de sonnerie sur la première ressource sur réception, en provenance de ladite entité aval, d'une réponse SIP de type 180 Ringing sans SDP. 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 à une première variante de réalisation de l'invention ; - les figures 3 et 4 représentent sous forme de chronogramme et d'organigramme un procédé de filtrage conforme à une deuxième variante de réalisation de l'invention ; et - la figure 5 représente l'architecture matérielle d'un serveur conforme à un mode particulier de la première ou de la deuxième variante de l'invention. Description détaillée de l'invention En référence aux figures 1 et 2, nous allons maintenant décrire une première variante de réalisation de l'invention dans trois scénarios. Dans cette première variante, le serveur selon l'invention est un serveur d'application AS originating (référencé ORIG sur les figures), ce serveur offrant, dans un premier réseau IMS, un service originating de "rappel du dernier appelant". Dans ce service connu de l'homme du métier, le serveur ORIG est apte à diffuser, à un terminal UA appelant ce serveur, une annonce vocale mentionnant la date et l'heure des appels entrants destinés à ce terminal UA et n'ayant pas débouché. Un tel serveur originating ORIG permet ensuite à l'appelant via le terminal UA de demander à être mis en relation avec un de ces appelants. Dans un premier scénario de cette première variante de réalisation, on se place dans le contexte dans lequel un terminal SIP appelant UA a composé le code du service rappel du dernier appelant , service hébergé par le serveur ORIG, puis demandé à être mis en relation avec un abonné SIP appelé appartenant au même réseau IMS. Nous supposerons aussi 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 du service rappel du dernier appelant, le terminal UA envoie, à destination du serveur ORIG à travers le réseau IMS un message SIP de type INVITE dont le champ SDP de description de session comporte en particulier les informations liées aux codec(s) supporté(s) par le terminal appelant UA ainsi que l'adresse IP et numéro de port sur lequel il souhaite recevoir le ou les flux média. Ce message INVITE est reçu par le serveur originating ORIG au cours d'une étape E20. Dans ce scénario, le serveur originating ORIG détermine, au cours d'un test E21, s'il doit jouer un flux early media. Dans l'exemple de réalisation décrit ici c'est le cas, et le résultat du test E21 est positif. Le test E21 est alors suivi par une étape E30 au cours de laquelle le serveur AS originating ORIG établit un dialogue SIP avec un serveur MRF du premier réseau IMS pour réserver une première ressource MRF1. Au cours d'une étape E40, le serveur AS originating ORIG envoie une réponse SIP de type 183 In Progress au terminal appelant UA, en réponse au message 6 35 d'invitation reçu à l'étape E20, le champ SDP de cette réponse comportant l'identifiant SDP MRF1 de la ressource (codec choisi suite à l'offre du terminal UA, adresse IP et N° de port sur laquelle la ressource MRF1 souhaite recevoir le flux média et/ou DTMF émis par le terminal UA). Au cours d'une étape E50, le serveur AS originating ORIG contrôle le serveur MRF pour qu'il restitue, dans la première ressource MRF1, le flux média associé au service de rappel du dernier appelant. Conformément à ce scénario, l'utilisateur du terminal appelant UA demande à être mis en relation, via la saisie d'une séquence de touches DTMF, avec un appelé SIP (terminal UB) ayant essayé de le joindre auparavant sans succès. Dans l'exemple de réalisation décrit ici, le serveur originating est notifié de cette opération par réception d'un message de notification du serveur MRF, au cours d'une étape E70. Dans l'exemple de réalisation décrit ici, si le serveur originating ORIG ne reçoit pas une telle notification pendant un délai TIM prédéterminé, il libère l'appel au cours d'une étape E71. Sur réception de cette notification, le serveur AS selon l'invention demande, dans ce mode de réalisation, la réservation d'une deuxième ressource MRF2 auprès du serveur MRF précité, au cours d'une étape E80. Puis, conformément à l'invention, le serveur originating AS envoie, au cours d'une étape E90, un message d'invitation SIP à destination d'une entité aval, choisie en fonction du terminal appelé UB, ce message d'invitation comportant un champ SDP identifiant cette deuxième ressource MRF2. Dans le scénario décrit ici, cette entité aval est le serveur d'application AS terminating, référencé TERM, du terminal appelé UB. Il est clair pour l'homme du métier que le chronogramme de la figure 1 est simplifié et que le message d'invitation SIP n'est pas envoyée directement à l'entité aval mais au serveur S-CSCF qui le prolonge vers cette entité aval. Dans le scénario décrit ici, le serveur AS terminating TERM du terminal appelé UB réserve, auprès du serveur MRF, une troisième ressource MRF3 et une quatrième ressource MRF4. Le serveur AS terminating établit ensuite un dialogue SIP avec le serveur SCSCF du terminal appelé UB en lui envoyant un message d'invitation SIP de type INVITE dont le champ SDP comporte l'identifiant MRF4 de la quatrième ressource. Le serveur S-CSCF dédouble l'appel vers les deux terminaux UB1, UB2, d'identité publique correspondant à celle du terminal appelé UB, et enregistrés en coeur de réseau IMS. Cette étape connue de l'homme du métier sous le nom de forking consiste, pour le serveur S-CSCF, à prolonger le message INVITE vers chacun de ces deux terminaux UB1, UB2. Nous supposerons dans cet exemple, que le terminal UB1 répond à ce message d'invitation par une réponse 180 RINGING incluant un champ SDP (codec sélectionné, adresse IP et port sur lequel le terminal appelé s'attend à recevoir du trafic) associé au terminal B1 et identifié UB1. Cette réponse SIP est reçue par le serveur AS terminating TERM, en provenance du serveur S-CSCF. Le terminal UB1 commence la restitution d'un flux early média sur la ressource MRF4 du serveur MRF. Dans le scénario décrit ici, le serveur AS terminating TERM contrôle le serveur MRF pour qu'il réplique, sur la ressource MRF3 du serveur MRF, le flux reçu sur la ressource MRF4. Le serveur AS terminating TERM envoie ensuite une réponse SIP 180 RINGING dont le champ SDP identifie la ressource MRF3, en réponse au message d'invitation INVITE envoyé à l'étape E90. Cette réponse SIP de type lxx est reçue par le serveur originating ORIG selon l'invention au cours d'une étape E120. Dans cette première variante de réalisation de l'invention, le serveur AS originating ORIG bloque cette réponse SIP, autrement dit ne l'a transmet pas au terminal appelant UA, au cours d'une étape E130. Conformément à l'invention, le serveur originating ORIG sélectionne, au cours d'une étape générale E140, en fonction des réponses SIP lxx reçues à l'étape E120, un flux média à restituer au terminal appelant UA. Dans l'exemple de réalisation décrit ici, le serveur AS originating ORIG sélectionne : le flux reçu sur la ressource MRF2 si la première réponse SIP de type lxx reçue à l'étape E120 comporte un champ SDP ; ou un flux média de retour de sonnerie, généré par le serveur MRF, si la première réponse SIP de type lxx reçue à l'étape E120 est de type 180 RINGING sans SDP. Le serveur AS originating selon l'invention sélectionne donc dans cet exemple le flux reçu sur la ressource MRF2. Conformément à l'invention, le serveur AS Originating selon l'invention contrôle, au cours d'une étape E150, le serveur MRF pour qu'il restitue le flux média sélectionné sur la première ressource MRF1. Cette opération consiste, dans cet exemple, à répliquer le flux reçu sur la ressource MRF2 sur la ressource MRF1. Ainsi, le terminal appelant UA reçoit le flux média généré par le terminal UB1 depuis la même ressource MRF1 que celle utilisée au début du service de rappel du dernier appelant. Dans le mode de réalisation décrit ici, si le résultat du test E21 est négatif, le message d'invitation SIP est prolongé directement vers le terminal appelé UB, et la première réponse SIP de type lxx reçue en réponse est transmise vers le terminal appelant UA, les autres réponses SIP de type 1xx étant bloquées. Dans le premier scénario de la première variante de réalisation qui vient d'être décrit, les terminaux UB1 et UB2 étaient des terminaux SIP du même réseau IMS que le terminal appelant UA. Dans un deuxième scénario de cette première variante de réalisation de l'invention, nous supposons que le terminal SIP appelant ayant composé le numéro du service rappel du dernier appelant hébergé par le serveur originating ORIG, demande par la saisie d'une séquence de touches DTMF, à être mis en relation avec un abonné du réseau RTC ou GSM et que cette mise en relation déclenche un service du réseau intelligent générant, toujours pendant la phase d'établissement d'appel, un flux early média vers le terminal appelant. Ce deuxième scénario diffère du premier scénario dans le choix de l'entité aval à laquelle l'AS originating envoie le message d'invitation SIP à l'étape E90. Plus précisément, dans ce deuxième scénario, le message SIP dont le champ SDP identifie la deuxième ressource MRF2 est envoyé à un serveur MGCF apte à transformer la signalisation d'appel SIP en signalisation d'appel ISUP et à router l'appel sur le réseau circuit RTC ou GSM. Dans ce deuxième scénario, le numéro appelé déclenche un service du réseau intelligent générant un flux early média en mode circuit à destination de la passerelle média T-MGF qui elle-même transmet ce flux early média, en utilisant le protocole RTP/UDP/IP, vers la deuxième ressource MRF2. Le serveur MGCF envoie une réponse SIP 183 In Progress, le champ SDP de cette réponse comportant l'identifiant de la ressource utilisée par la passerelle T-MGF pour cet appel. Ce message SIP de type 1xx est reçu par le serveur AS originating ORIG selon l'invention au cours de l'étape E120 déjà décrite. Conformément à cette première variante de réalisation de l'invention, la réponse 183 In Progress est bloquée par le serveur AS originating ORIG au cours de l'étape [130 déjà décrite. La réponse 183 In Progress comportant un champ SDP, l'AS originating contrôle, au cours de l'étape E150, le serveur MRF pour qu'il restitue, dans la première ressource MRF1, le flux early média généré par le réseau intelligent. Toujours dans ce deuxième scénario, l'utilisateur du terminal appelant UA peut demander l'établissement d'appel vers l'appelé UB. Dans ce cas où ce terminal appelé UB générerait lui-même un flux early media, par exemple un flux CRBT (Colored Ring Back Tone), ce flux serait transmis via la passerelle média T-MGF et le serveur AS originating ORIG recevrait une réponse de type 180 Ringing avec le champ SDP comportant l'identifiant de la même ressource utilisée par la passerelle T-MGF pour cet appel. Au contraire, si le terminal appelé UB ne génère pas de flux early media, le commutateur de l'appelé génèrerait lui-même un retour de sonnerie RBT en mode early média. Là encore, le serveur originating ORIG recevrait, à l'étape 120, une réponse de type 180 Ringing, le champ SDP de cette réponse comportant le même identifiant de la ressource utilisée par la passerelle T-MGF. Cette réponse serait bloquée par le serveur ORIG conformément à cette première variante de réalisation de l'invention. Dans un troisième scénario de cette première variante de réalisation, on suppose que le terminal appelant UA ayant composé le code du service rappel du dernier appelant hébergé par le serveur ORIG, demande à être mis en relation avec un abonné SIP appartenant à un autre réseau IMS. Ce troisième scénario diffère des deux premiers scénarios dans le choix de l'entité aval à laquelle est envoyé le message d'invitation SIP à l'étape E90. Plus précisément, dans ce troisième scénario, le serveur AS originating établit un dialogue SIP avec le serveur d'interconnexion IBCF entre les deux réseaux, par l'envoi d'un message SIP INVITE dont le champ SDP identifie la deuxième ressource MRF2. En référence aux figures 3 et 4, nous allons maintenant décrire une deuxième variante de réalisation de l'invention. Dans cette deuxième variante de réalisation, le serveur selon l'invention est un serveur IBCF d'interconnexion entre deux réseaux IMS. On suppose, dans cet exemple de réalisation, que le serveur IBCF reçoit, au cours d'une étape F20, un message INVITE émis par une entité amont, celle-ci pouvant être constituée par un terminal appelant UA ou par un serveur placé en coupure de flux entre le terminal appelant UA et le serveur IBCF. Dans cette deuxième variante de réalisation de l'invention, le serveur d'interconnexion IBCF selon l'invention ne répond pas directement au message d'invitation INVITE. Conformément à ce deuxième mode de réalisation de l'invention, le serveur IBCF réserve une première ressource MRF3 (étape F30) et une deuxième ressource MRF4 (étape F40) auprès d'un serveur I-BGF du premier réseau IMS. Au cours d'une étape F60, le serveur d'interconnexion IBCF envoie un message d'invitation SIP INVITE à destination d'une entité aval choisie en fonction du terminal appelé UB. Conformément à l'invention, ce message d'invitation comporte un champ SDP identifiant la deuxième ressource MRF4 réservée à l'étape F40. Dans cette deuxième variante de réalisation de l'invention, cette entité aval est une entité du deuxième réseau IMS. Dans cet exemple, on suppose que cette entité aval est un serveur AS terminating TERM associé au terminal appelé UB. Le serveur d'interconnexion IBCF selon l'invention est susceptible de recevoir, au cours d'une étape F70, plusieurs réponses SIP de type lxx en réponse au message INVITE envoyé à l'étape F60. On suppose dans cet exemple, que le serveur terminating du terminal appelé UB pilote un MRF appartenant au deuxième réseau IMS pour jouer un flux early média, toujours pendant la phase d'établissement d'appel, ce flux étant reçu par le serveur IBGF sur la deuxième ressource MRF4. Conformément à l'invention, le serveur IBCF sélectionne, au cours d'une étape F90, un flux média à restituer au terminal appelant UA en fonction des réponses SIP reçues à l'étape F70. Dans l'exemple de réalisation décrit ici, cette sélection se fait sur la base de la première réponse SIP de type lxx reçue à l'étape F70. Si cette première réponse reçue est de type 180 Ringing sans SDP, le serveur IBCF selon l'invention répond, au message INVITE reçu à l'étape F20, par une réponse 180 Ringing dont le champ SDP comporte l'identifiant MRF3 de la première ressource. Si la première réponse reçue du deuxième réseau est une réponse de type 180 Ringing avec SDP, le serveur d'interconnexion IBCF selon l'invention répond au message d'invitation INVITE reçu à l'étape F20 par l'envoi d'une réponse 180 Ringing dont le champ SDP identifie la première ressource MRF3. Enfin, si la première réponse reçue du deuxième réseau est une réponse de type 183 In Progress avec SDP, le serveur IBCF selon l'invention répond au message INVITE reçue à l'étape F20, par l'envoi d'une réponse 183 Progress avec le champ SDP identifiant la première ressource MRF3. Autrement dit, dans ce mode de réalisation de l'invention, le serveur IBCF envoie, à l'entité amont, une seule réponse du type de la première réponse reçue en provenance de l'entité aval. Selon un autre exemple de réalisation, la sélection de l'étape F90 peut être effectuée en fonction du type ixx 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. Puis, au cours d'une étape F100, le serveur IBCF selon l'invention contrôle à travers l'équipement SPDF le serveur média d'interconnexion IBGF pour qu'il restitue, dans la première ressource MRF3 le flux média sélectionné à l'étape F90, soit pour jouer un retour de sonnerie sur la ressource MRF3 dans le cas d'une réponse 180 Ringing sans SDP, soit répliquer le flux early média reçu sur la ressource MRF4 vers la ressource MRF3 dans le cas d'une réponse 180 Ringing ou 183 In Progress avec SDP. La figure 5 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 13 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, lorsque le serveur d'application AS est un serveur originating, cette mémoire morte comporte un programme d'ordinateur PGO 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. De même, lorsque le serveur d'application AS est un serveur d'interconnexion, cette mémoire morte comporte un programme d'ordinateur PGI 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 4. 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 et à l'interpréter. Le processeur 10, lorsqu'il exécute le programme d'ordinateur PGO ou PGI permet au serveur AS de réserver une ou plusieurs ressources auprès d'un serveur MRF ou I-BGF et à contrôler un serveur MRF ou I-BGF pour qu'il restitue un flux média sur une ressource donnée et à répliquer une deuxième ressource sur une première ressource. Le processeur 10, lorsqu'il exécute le programme d'ordinateur PGO ou PGI est apte à sélectionner un flux média à restituer à un terminal SIP, en fonction d'une réponse SIP reçue par les moyens de communication 14. REVENDICATIONS1. Procédé de filtrage mis en oeuvre par un serveur (ORIG, IBCF) dans un premier 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 (E20, F20) de réception d'un message d'invitation SIP émis par une entité amont (UA) en coupure de flux entre le terminal appelant et ledit serveur ; - une étape (E30, E80, F30, F40) de réservation d'une première ressource (MRF1, MRF3) et d'une deuxième ressource (MRF2, MRF4) auprès d'un serveur de ressource (MRF, I- BGF) dudit premier réseau ; - une étape (E40, F90) d'envoi d'une réponse SIP à ladite entité amont (UA) comportant un champ SDP identifiant ladite première ressource (MRF1, MRF3) ; - une étape (E90, F60) d'envoi d'un message d'invitation SIP à destination d'au moins une entité aval (UB, TERM, S-CSCF, IBCF) choisie en fonction dudit terminal appelé (UB), ledit message d'invitation comportant un champ SDP identifiant ladite deuxième ressource (MRF2, MRF4) ; - une étape (E120, F70) de réception d'au moins une réponse SIP de type 1xx en provenance d'au moins une desdites entité aval; - une étape (E140, F90) de sélection d'un flux média en fonction de ladite au moins une réponse reçue ; - une étape (E150, F100) de contrôle dudit serveur de ressource pour qu'il restitue ledit flux média dans ladite première ressource (MRF1, MRF3) à destination dudit terminal appelant. 2. Procédé de filtrage selon la revendication 1, caractérisé en ce que ledit serveur est un serveur originating (ORIG), ledit serveur de ressource étant un serveur MRF. 3. Procédé de filtrage selon la revendication 2, caractérisé en ce qu'il comporte une étape (E130) de blocage de ladite réponse SIP de type 1xx. 4. Procédé de filtrage selon la revendication 2, caractérisé en ce qu'il comporte une étape (E50) de contrôle dudit serveur MRF pour qu'il restitue, dans ladite première ressource (MRF1), un premier flux média déclenché par ledit serveur originating, ladite réponse SIP étant de type 183 In Progress avec SDP. 35 5. Procédé de filtrage selon la revendication 4, caractérisé en ce que ladite étape (E40) d'envoi de ladite réponse SIP à ladite entité amont est effectuée juste après la réservation (E30) de ladite première ressource. 6. Procédé de filtrage selon la revendication 4, caractérisé en ce que ladite étape (E80) de réservation de ladite deuxième ressource (MRF2) est effectuée sur réception (E70) d'une notification dudit serveur MRF. 7. Procédé de filtrage selon la revendication 1, dans lequel ledit serveur est un serveur d'interconnexion entre ledit premier réseau et un deuxième réseau IMS auquel appartient ladite entité aval, ledit serveur de ressource étant une entité I-BGF. 8. Procédé de filtrage selon la revendication 7, caractérisé en ce que ladite réponse SIP envoyée (F90) à ladite entité amont est du type de ladite réponse SIP reçue de ladite entité aval. 9. Procédé de filtrage selon la revendication 1, caractérisé en ce que ledit flux média sélectionné est : - un flux média reçu dans ladite deuxième ressource (MRF2, MRF4) si ladite réponse SIP de type lxx reçue (E120, F70) de ladite entité aval comporte un champ SDP ; ou - un signal de retour d'appel généré par ledit serveur de ressource dans les autres cas. 10. Procédé de filtrage selon la revendication 1, caractérisé en ce que ledit flux média est sélectionné (F90) en fonction d'un paramètre de priorité de ladite entité aval à l'origine de ladite réponse reçue au sens d'un service de forking tel que défini dans la norme RFC SIP 3261. 11. Serveur (ORIG, IBCF) 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) en coupure de flux entre ledit terminal appelant et ledit serveur ; - des moyens (10, PGO, PGI) de réservation d'une première ressource (MRF1, MRF3) et d'une deuxième ressource (MRF2, MRF4) auprès d'un serveur de ressource (MRF, IBGF) dudit premier réseau ;- des moyens (14) d'envoi d'une réponse SIP à ladite entité amont (UA) comportant un champ SDP identifiant ladite première ressource (MRF1, MRF3) ; - des moyens (14) d'envoi d'un message d'invitation SIP à destination d'au moins une entité aval (UB, TERM, S-CSCF, IBCF) choisie en fonction dudit terminal appelé (UB), ledit message d'invitation comportant un champ SDP identifiant ladite deuxième ressource (MRF2, MRF4) ; - des moyens (14) de réception d'au moins une réponse SIP de type 1xx en provenance d'au moins une desdites entité aval; - des moyens (10, PGO, PGI) de sélection d'un flux média en fonction de ladite au moins une réponse reçue ; et - des moyens (10, PGO, PGI) de contrôle dudit serveur de ressource (MRF, IBGF) pour qu'il restitue ledit flux média dans ladite première ressource (MRF1, MRF3) à destination dudit terminal appelant (UA). 12. Serveur (ORIG, IBCF) selon la revendication 11, caractérisé en ce qu'il comporte des moyens pour déclencher un flux média de retour de sonnerie sur ladite première ressource (MRF1, MRF3) sur réception, en provenance de ladite entité aval, d'une réponse SIP de type 180 Ringing sans SDP. 13. Programme d'ordinateur (PGO, PGI) 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). 14. 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.