+

WO2013001213A1 - Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé. - Google Patents

Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé. Download PDF

Info

Publication number
WO2013001213A1
WO2013001213A1 PCT/FR2012/051409 FR2012051409W WO2013001213A1 WO 2013001213 A1 WO2013001213 A1 WO 2013001213A1 FR 2012051409 W FR2012051409 W FR 2012051409W WO 2013001213 A1 WO2013001213 A1 WO 2013001213A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
sip
resource
priority
calling terminal
Prior art date
Application number
PCT/FR2012/051409
Other languages
English (en)
Inventor
Bertrand Bouvet
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2013001213A1 publication Critical patent/WO2013001213A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1094—Inter-user-equipment sessions transfer or sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Definitions

  • the present invention is in the field of telecommunications and more specifically in that of IMS networks (IP Multimedia Subsystem).
  • IMS networks IP Multimedia Subsystem
  • the services are provided by application servers AS (for Application Server).
  • a server offering an originating service is usually referred to as an "originating server”.
  • 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 feeds”.
  • 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.
  • SIP Session Initiation Protocol
  • 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.
  • 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 process comprises:
  • 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;
  • 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;
  • 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.
  • an upstream entity is for example an MGCF server.
  • an upstream entity may be an IBCF interconnection server.
  • SIP response type lxx refers to any SIP response whose type begins with the number "1" and in particular the SIP 180 Ringing and 183 In Progress responses.
  • 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 the name of "early media flow”, are systematically controlled by the server according to the invention, a single lxx type SIP response going back to the calling terminal.
  • This characteristic advantageously makes it possible to define, in a perfectly predictable manner, the scenario and the scheduling of restitution of the early media flows by the calling terminal.
  • the server according to the invention is a terminating server.
  • the filtering method according to the invention comprises:
  • 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.
  • the filtering method according to the invention comprises:
  • This feature is particularly advantageous because it makes it possible to restore the different 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.
  • the SIP response message sent to the upstream entity may be:
  • 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.
  • the server according to the invention comprises means for triggering a ringback return media stream on the first resource when the selected message is of type lxx without SDP.
  • the various steps of the filtering method according to the invention are determined by instructions of computer programs.
  • the invention also relates to a computer program on an information medium, 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.
  • 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 floppy disk or a disk. hard.
  • 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.
  • 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.
  • 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
  • FIG. 3 shows the hardware architecture of a server according to a particular embodiment of the invention.
  • the server according to the invention is an AS terminating application server (referenced as TERM in the figures).
  • this Terminating server does not generate an early media stream.
  • the terminal UA When the calling terminal UA dials the number of the called subscriber, the terminal UA sends, to the CSCF server, 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.
  • the CSCF server 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.
  • the originating ORIG server triggers the originating services of the caller, for example the calling number masking positioning service or the verification that the caller's number the compound call is allowed. 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.
  • 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.
  • 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.
  • 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
  • the terminating server TERM determines, during a step G80, an order of priority between these contact addresses, from said priorities q.
  • 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.
  • 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 called party's P-CSCF server 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 so as to force the transmitted and received media flows to pass through the CBGF called UB.
  • this INVITE message is extended by the P-CSCF of the called party to the terminals UB1 and UB2.
  • 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 .
  • SDP CBGF-UA
  • the call is therefore presented to the terminal called unique UB1.
  • this called terminal 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.
  • 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.
  • 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:
  • SDP 180 Ringing message
  • 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.
  • 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.
  • 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.
  • 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 P-CSCF which controls the SPDF which itself controls the CBGF so as to transit the media streams transmitted and received by the CBGF equipment.
  • the AS TERM receives 180 Ringing responses with SDP CBGF-U 1 and SDP CBGF-U2.
  • step G120 the terminating server TERM selects the media stream of the terminal UB1, the answer of the latter having been received first.
  • 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.
  • 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.
  • 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.
  • the terminating TERM server requests the AS TERM-driven MRF entity to generate a systematic early-stream flow to make the calling terminal user wait for the time to join the serial terminals until that one of them answers.
  • the terminating server TERM 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 determines during a G21 test whether the called party is subscribed to the FLS forwarding service.
  • terminating TERM server could also offer services without application forking or not generating early media flow.
  • 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).
  • the AS terminating server TERM when there is no application forking, establishes a SIP dialogue with the MRF server to reserve a single resource MRF2, during a step G81.
  • the SIP INVITE invitation message sent during this step G90 to the S-CSCF includes an SDP field which identifies this second resource.
  • the S-CSCF server extends the INVITE message to each of these two terminals UB1, UB2 and the P-CSCF replaces the IP address and port number of the second resource with the IP address and number. of the CBGF called in order to transit the media streams transmitted and received by this equipment.
  • step G100 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 P-CSCF with the value CBGF-UB1 / UB2 to force the streams to pass through the CBGF of the called party.
  • the terminating TERM server controls the MRF server to request the resource MRF2 to filter the early media stream received and sent 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 lxx 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.
  • 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.
  • a single media stream is transmitted in the network to the caller's CBGF.
  • the TERM server would drive the MRF to play the ringback on the resource MRF1.
  • the called party 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 an lxx message with or without SDP, via an 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.
  • the selection of the media stream to replicate is made according to a priority order.
  • priority associated with the different lxx responses received can for example be determined according to the type lxx 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.
  • the calling terminal UA receives the early media stream generated by one of the called subscriber terminals from the same MRFI resource used for the early media stream generated by the call forwarding service. sequential FLS.
  • FIG. 3 represents the architecture of an AS application server according to the invention.
  • this server has the hardware architecture of a computer. It comprises a processor 10, a read-only memory ROM 11, a random access memory 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. 2.
  • the communication means 14 of the server AS are able to receive, transmit and interpret a SIP invitation message, to create a SIP response with or without a request.
  • an SDP field to send such a response on the IMS network, to issue a SIP Register message to an S-CSCF server and to interpret its response, in particular to determine the priority q of terminals having the same identity IMPU according to the RFC standard 3261.
  • the processor 10 when it executes the computer program PGT, is able to select a media stream to be delivered to a terminal SIP, according to these priorities and to filter the different SIP responses lxx.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)

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 (UBl, 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 (UBl, 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 lxx, choisie en fonction dudit flux média pour permettre sa restitution audit terminal appelant.

Description

Procédé de filtrage de flux Early Media dans un réseau IMS et serveur mettant en œuvre ce procédé.
Arrière-plan de l'invention
La présente invention se situe dans le domaine des télécommunications et plus précisément dans celui des réseaux IMS (pour IP Multimedia Subsystem).
Dans un réseau IMS, les services sont fournis par des serveurs d'application AS (pour Application Server).
Parmi ces serveurs d'application, il est connu de distinguer les serveurs qui offrent un service déclenché à l'émission de l'appel, autrement connu de l'homme du métier sous le nom de « service originating ». Un serveur offrant un service originating est habituellement désigné « serveur originating ».
De la même façon, on appelle communément « serveur terminating », un serveur d'application AS offrant un service déclenché à la réception de l'appel, un tel service étant désigné sous le nom de « service terminating ».
Certains services originating et terminating connus à ce jour génèrent des flux média à destination du terminal appelant pendant la phase d'établissement d'appel. Ces flux sont souvent désignés sous le nom de « flux early média ».
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 média 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 média. 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 média destinés à un même terminal appelant.
Objet et résumé de l'invention
L'invention concerne un procédé de filtrage mis en œuvre 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 cœur 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 lxx, 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 œuvre, 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 cœur 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;
- 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 lxx, choisie en fonction dudit flux média pour permettre sa restitution au terminal appelant.
Dans ce document, on désignera par « entité amont », le terminal appelant, ou toute entité du réseau IMS placée en coupure de flux entre le terminal appelant et le serveur selon l'invention et par « entité aval », le terminal appelé, ou toute entité du réseau IMS placée en coupure de flux entre le serveur selon l'invention et le terminal appelé.
L'homme du métier comprendra que les serveurs originating de l'appelant et le serveur terminating de l'appelé constituent respectivement des entités amont et aval au sens de l'invention. Lorsque le terminal appelant appartient à un réseau circuit RTC/GSM, une entité amont est par exemple un serveur MGCF. Lorsque le terminal appelant appartient à un autre réseau IMS que l'appelé, une entité amont peut être un serveur d'interconnexion IBCF.
La notation « réponse SIP de type lxx », 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 média », sont systématiquement contrôlés par le serveur selon l'invention, une seule réponse SIP de type lxx 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 média 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 média 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 média par le terminal appelant tout en optimisant les ressources du réseau IMS à travers lesquelles ces flux early média transitent.
Dans un mode particulier de réalisation, le procédé de filtrage selon l'invention comporte :
- une étape d'envoi, à ladite entité amont, d'une réponse SIP de type 183 In Progress comportant un champ SDP identifiant ladite première ressource ;
- une étape de contrôle dudit serveur MRF pour qu'il restitue, dans cette première ressource un premier flux média généré par le serveur.
Cette caractéristique est particulièrement avantageuse car elle permet de restituer les différents flux early média à 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 média 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 lxx avec un champ SDP n'est reçue; ou
- le message de type lxx 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 lxx sans SDP.
Un scénario complet de sélection du flux média à restituer à l'appelant sera détaillé ci-après.
Dans un mode particulier de réalisation, les différentes étapes du procédé de filtrage selon l'invention sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre par un serveur, ce programme comportant des instructions adaptées à la mise en œuvre 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 dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous en référence aux dessins qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : - les figures 1 et 2 représentent sous forme de chronogramme et d'organigramme un procédé de filtrage conforme à un mode particulier de réalisation de l'invention ;
- la figure 3 représente l'architecture matérielle d'un serveur conforme à un mode particulier de réalisation de l'invention.
Description détaillée de l'invention
En référence à la figure 1, nous allons maintenant décrire un procédé de filtrage conforme à un mode particulier de réalisation de l'invention. Afin de ne pas surcharger la figure, les réponses SIP 100 TRYING ne sont pas représentées.
Dans l'exemple de réalisation décrit ici, le serveur selon l'invention est un serveur d'application AS terminating (référencé 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 cœur 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 codées 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.
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 cœur de réseau IMS avec cette identité publique IMPU, et pour chacun d'entre elles la durée d'enregistrement restante ainsi que la priorité q définie par cette norme, sachant que si le paramètre q n'est pas fourni, cela équivaut à une priorité implicite la plus faible, c'est-à-dire q=0.
Conformément à l'invention, le serveur terminating TERM détermine, au cours d'une étape G80, un ordre de priorité entre ces adresses de contact, à partir desdites priorités q.
En pratique, cette étape consiste à déterminer si l'on se trouve dans un cas de forking (plus d'une adresse de contact dans la réponse SIP 200 OK du message SIP REGISTER) et si c'est le cas, s'il s'agit d'un forking séquentiel, parallèle ou mixte.
Le serveur terminating TERM prolonge ensuite, au cours d'une étape G90, le message d'invitation SIP vers le serveur S-CSCF de l'appelé qui le dédouble vers chacun des terminaux associés respectivement à une adresse de contact conformément au mécanisme de forking décrit dans le document RFC 3261. Le serveur P-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 P- CSCF 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 cœur 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 média, 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 média, il répond 180 Ringing (SDP=UB1) et le serveur P-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 codée sélectionné par le terminal UB1 est conservé dans le SDP mais l'adresse IP et numéro de port du terminal UB1 sont remplacés par l'adresse IP et numéro de port du CBGF appelé de manière à forcer les flux média émis et reçus par le terminal appelé B à transiter dans le CBGF. La réponse est transmise par l'AS Terminating vers l'amont et le terminal appelant UA joue ce flux early média.
En présence de forking simultané uniquement
Dans l'exemple de réalisation décrit ici, l'AS Terminating attend de l'ordre de une à quelques secondes (par exemple cinq) pour recueillir le maximum de réponses et choisir la plus appropriée à remonter :
- si aucune réponse ne comporte un champ SDP (pas d'early média), 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 lxx reçues et non sélectionnées sont filtrées par l'AS TERM.
En présence de forklna séquentiel uniquement
Dans ce mode de réalisation, l'AS terminating TERM restitue la réponse du terminal le plus prioritaire vers l'amont. Le terminal appelant UA joue localement un retour d'appel RBT si l'adresse de contact appelée la plus prioritaire ne génère pas de flux Early Media, ou le flux Early Media joué par l'adresse de contact la plus prioritaire de l'appelé. En présence d'un forklna mixte
Dans le mode de réalisation décrit ici, le serveur terminating TERM considère la toute première phase de présentation d'appel vers le ou les terminaux ayant la plus haute priorité. Il applique ensuite la politique décrite ci-dessus de « forking simultané uniquement » ou de « forking séquentiel uniquement » en fonction du type simultané/séquentiel de la première phase de présentation d'appel.
De retour à la figure 1, on supposera que les deux terminaux UB1, UB2 génèrent de l'early média 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 P-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-U 1 et SDP CBGF-U2.
On suppose que ces deux terminaux ont le même paramètre de priorité q.
A l'étape G120, le serveur terminating TERM sélectionne le flux média du terminal UB1, la réponse de ce dernier ayant été reçue en premier. Le serveur terminating TERM envoie, au cours d'une étape G140, au serveur originating amont ORIG une réponse SIP 180 RINGING SDP=CBGF-UB1. Cette réponse est prolongée vers le terminal UA, comme de façon connue et le terminal UA reçoit le flux early média généré par le terminal UB1.
Conformément à l'invention, une seule réponse lxx 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 média 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 média 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.
Scénario sans forking applicatif Dans ce cas, l'appelé n'est pas abonné au service de renvoi FLS, le serveur terminating TERM ne met pas en œuvre 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 UBl, UB2 et le P-CSCF remplaçe l'adresse IP et numéro de port de la deuxième ressource par l'adresse IP et numéro de port du CBGF appelé de manière à faire transiter les flux média émis et reçu par cet équipement..
Nous supposerons, dans cet exemple, que les deux terminaux UBl, UB2 génèrent de l'early média et répondent (étape G100) par un message 180 Ringing avec SDP UB1/UB2, le champ SDP étant modifié par le P-CSCF avec la valeur CBGF-UB1/UB2 pour forcer les flux à transiter dans le CBGF de l'appelé.
Ces deux flux early média sont donc reçus dans la même ressource MRF2.
On suppose que les deux terminaux UBl, 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 UBl.
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 média (sur la base des informations contenues dans le SDP du lxx 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 UBl é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 média généré par le terminal UBl.
Ainsi, de façon avantageuse, un seul flux média est transmis dans le réseau vers le CBGF de l'appelant. Dans le cas où les terminaux UB1 et UB2 répondraient par un 180 Ringing sans SDP donc sans générer de flux early média, le serveur TERM piloterait le MRF pour qu'il joue le retour de sonnerie sur la ressource MRF1. 2. Scénario avec forking 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 lxx avec ou sans SDP, via si besoin un serveur MGCF ou IBCF selon le type de réseau auquel appartient la destination. Si le serveur terminating TERM décide, par application de la politique précitée, de restituer le flux early média de cette destination moins prioritaire au terminal appelant UA, il lui suffit de répliquer sur la première ressource MRF1, les paquets reçus sur la ressource MRFi, sans filtrage particulier au niveau paquet.
Lorsqu'il n'y a pas de destination prioritaire, par exemple si tous les terminaux ont la même priorité, ou si la destination prioritaire ne renvoie pas de réponse, la sélection du flux média à répliquer est faite en fonction d'un ordre de priorité associé aux différentes réponses lxx reçues. Un tel ordre de priorité peut par exemple être déterminé en fonction du type lxx 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 média 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 MRFI que celle utilisée pour le flux early média généré par le service de renvoi d'appel séquentiel FLS.
La figure 3 représente l'architecture d'un serveur d'application AS conforme à l'invention.
Dans le mode de réalisation décrit ici, ce serveur a l'architecture matérielle d'un ordinateur. Il comporte un processeur 10, une mémoire morte de type ROM 11, une mémoire vive de type RAM 12 et des moyens de communication 14 aptes à mettre en œuvre le protocole SIP pour communiquer avec d'autres entités mettant en œuvre 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 œuvre le procédé de filtrage dont les principales étapes ont été décrites en référence à la figure 2.
Les moyens 14 de communication du serveur AS sont aptes à recevoir, émettre et interpréter un message d'invitation SIP, à créer une réponse SIP comportant ou non un champ SDP, à envoyer une telle réponse sur le réseau IMS, à émettre un message SIP Register à un serveur S-CSCF et à interpréter sa réponse, notamment pour déterminer la priorité q de terminaux comportant une même identité IMPU conformément à la norme RFC 3261.
Le processeur 10, lorsqu'il exécute le programme d'ordinateur PGT est apte à sélectionner un flux média à restituer à un terminal SIP, en fonction de ces priorités et à filtrer les différentes réponses SIP lxx.
Le processeur 10, lorsqu'il exécute le programme d'ordinateur PGT permet au serveur AS TERM de réserver une ou plusieurs ressources auprès d'un serveur MRF et à contrôler un serveur MRF pour lui faire jouer un retour d'appel RBT ou restituer un flux média sur une ressource donnée et à répliquer une première ressource sur une deuxième ressource, puis contrôler le MRF pour filtrer certains flux média reçus.

Claims

REVENDICATIONS
1. Procédé de filtrage 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), 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 (UBl, 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 (UBl, 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 lxx, choisie en fonction dudit flux média pour permettre sa restitution audit terminal appelant.
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 média sélectionné.
3. Procédé de filtrage selon la revendication 2 caractérisé en ce qu'il comporte : - une étape (G210) d'envoi, à ladite entité amont, d'une réponse SIP de type 183 In Progress comportant un champ SDP identifiant ladite première ressource (MRF1) ; - une étape (G220) de contrôle dudit serveur MRF pour qu'il restitue, dans ladite première ressource (MRF1), un premier flux média généré par ledit serveur (TERM).
4. Procédé selon la revendication 1, caractérisé en ce que ledit message de type lxx sélectionné est :
- un message de type 180 Ringing, sans SDP, si aucune réponse de type lxx avec un champ SDP n'est reçue; ou
- le message de type lxx avec SDP reçu.
5. Procédé selon la revendication 2, caractérisé en ce qu'il comporte, ledit flux média à restituer étant reçu sur ladite deuxième ressource, une étape de contrôle dudit serveur MRF pour qu'il effectue un filtrage des paquets reçus sur la deuxième ressource pour ne répliquer sur la première ressource, que ceux dudit flux média à restituer.
6. Serveur (TERM) appartenant à un premier réseau IMS, caractérisé à ce qu'il comporte des moyens pour mettre en œuvre, 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 (UBl, UB2) enregistrées en cœur 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 dédits terminaux ;
- des moyens (14) de prolongation dudit message d'invitation SIP vers un serveur CSCF traitant lesdites au moins une adresses de contact (UBl, 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 lxx, choisie en fonction dudit flux média pour permettre sa restitution audit terminal appelant.
7 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 lxx 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.
PCT/FR2012/051409 2011-06-30 2012-06-21 Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé. WO2013001213A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1102073 2011-06-30
FR1102073A FR2977430A1 (fr) 2011-06-30 2011-06-30 Procede de filtrage de flux early media dans un reseau ims et serveur mettant en oeuvre ce procede

Publications (1)

Publication Number Publication Date
WO2013001213A1 true WO2013001213A1 (fr) 2013-01-03

Family

ID=46456907

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/051409 WO2013001213A1 (fr) 2011-06-30 2012-06-21 Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé.

Country Status (2)

Country Link
FR (1) FR2977430A1 (fr)
WO (1) WO2013001213A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080043720A1 (en) * 2006-08-02 2008-02-21 Siemens Communications, Inc. Telecommunications system and method of session initiation protocol (SIP) based communications between endpoints
US20100165976A1 (en) * 2008-12-29 2010-07-01 Microsoft Corporation Handling early media in voip communication with multiple endpoints

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080043720A1 (en) * 2006-08-02 2008-02-21 Siemens Communications, Inc. Telecommunications system and method of session initiation protocol (SIP) based communications between endpoints
US20100165976A1 (en) * 2008-12-29 2010-07-01 Microsoft Corporation Handling early media in voip communication with multiple endpoints

Also Published As

Publication number Publication date
FR2977430A1 (fr) 2013-01-04

Similar Documents

Publication Publication Date Title
EP3777081B1 (fr) Procédé de gestion d'une pluralité de flux média, et dispositif associé
EP2266285B1 (fr) Procede de terminaison d'un appel et terminal de voix sur ip
EP2612482B1 (fr) Procede de traitement de messages sip
EP2148489B1 (fr) Etablissement et contrôle d'appel par équipement tiers
EP2926524B1 (fr) Routage d'une requête de service visant un abonné ims
EP2856732B1 (fr) Procédé et entité de traitement d'un message
WO2012042150A1 (fr) Procédé de gestion de la priorité de flux média préliminaires
EP3158709B1 (fr) Sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
WO2020128258A1 (fr) Procédé de basculement d'une communication de tcp sur udp
WO2013001213A1 (fr) Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé.
WO2017203118A1 (fr) Procédé de repli dans un réseau de télécommunication
WO2013001211A1 (fr) Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé
EP2238727B1 (fr) Procédé de communication pour gérer des sessions de communication au niveau d'une passerelle domestique
WO2017220883A1 (fr) Procédé de détermination d'un ensemble de formats de codage pour établir une communication
WO2013186466A1 (fr) Serveur d'application et procede de traitement d'un message destine a une identite publique partagee par une pluralite de dispositifs
WO2009112760A1 (fr) Procede de gestion d'une session de communication au niveau d'une passerelle domestique
WO2018215719A1 (fr) Procédé de contrôle d'une communication comprenant des transactions multiples
FR2974964A1 (fr) Continuite de service inter-terminal dans un reseau de telecommunications
WO2013156727A1 (fr) Procede de traitement d'un message, entite et cœur de reseau
WO2013102716A1 (fr) Procede dynamique de determination d'une liste de services dans un reseau sip

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12731588

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12731588

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载