WO2013001211A1 - 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
WO2013001211A1
WO2013001211A1 PCT/FR2012/051406 FR2012051406W WO2013001211A1 WO 2013001211 A1 WO2013001211 A1 WO 2013001211A1 FR 2012051406 W FR2012051406 W FR 2012051406W WO 2013001211 A1 WO2013001211 A1 WO 2013001211A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
resource
sip
response
entity
Prior art date
Application number
PCT/FR2012/051406
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 WO2013001211A1 publication Critical patent/WO2013001211A1/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
    • 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/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/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.
  • IMS IP Multimedia Subsystem
  • a server offering an originating service is usually referred to as an "originating server”.
  • server terminating is commonly referred to as an application server AS (for Application Server) providing 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.
  • voice announcement sent by a originating server when the caller uses the service of consultation of incoming calls which did not lead to callback or Colored Ring Back Tone returned by the terminating server of the called terminal or by the called terminal.
  • 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:
  • SDP Session Description Protocol
  • 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 this server;
  • 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.
  • the originating servers of the calling party and the terminating server of the called party respectively constitute upstream and downstream entities within the meaning of the invention.
  • 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.
  • 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.
  • the server according to the invention is an originating server, the aforementioned resource server being an MRF (Multimedia Resource Function) server.
  • MRF Multimedia Resource Function
  • the filtering method according to the invention comprises a step of blocking the SIP response type lxx received from the downstream entity.
  • blocking is meant that this SIP response is not transmitted to the upstream entity.
  • the filtering method according to the invention comprises a step of controlling the MRF server to restore, in the first resource, a first media stream generated by it. even.
  • the SIP response sent to the upstream entity is in this case a 183 In Progress SIP response. It is preferably sent just after the reservation of the first resource so that the first early media flow is received as quickly as possible by the calling terminal.
  • the step of reserving the second resource is performed upon receipt of a notification from the MRF server.
  • this notification can be sent by the MRF server on detection of an explicit action by the user of the calling terminal (entering a DTMF key sequence, voice command, etc.) to trigger a new service likely to generate a new early media flow, still in call establishment phase, competing with the first early media flow triggered by the originating server itself.
  • the server according to the invention is an interconnection server between the first IMS network (to which it belongs) and a second IMS network (to which the called terminal and the downstream entity belong).
  • the resource server is an I-BGF entity (for Interconnection Border Gateway Function)
  • the SIP response sent to the upstream entity is of the type of the SIP response received from the downstream entity.
  • the media stream selected and restored on the first resource can be:
  • the media stream is selected according to a priority parameter of the downstream entity at the origin of the response received, in the sense of a forking service as defined in RFC SIP 3261.
  • the server comprises means for triggering a ringing return media stream on the first resource upon reception, from said downstream entity, of a SIP 180 Ringing response 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 timing diagram and a flowchart, a filtering method according to a first variant embodiment of the invention
  • FIGS. 3 and 4 represent, in the form of a timing diagram and a flowchart, a filtering method according to a second variant embodiment of the invention.
  • FIG. 5 represents the hardware architecture of a server conforming to a particular mode of the first or second variant of the invention. Detailed description of the invention
  • the server according to the invention is an AS originating application server (referenced ORIG in the figures), this server offering, in a first IMS network, an originating service of "callback of the last caller".
  • the server ORIG is able to broadcast, to a terminal UA calling this server, a voice announcement mentioning the date and time of incoming calls for this terminal UA and not having opportunity.
  • Such an originating ORIG server then allows the caller via the terminal UA to request to be put in touch with one of these callers.
  • the terminal UA When the calling terminal UA dials the callback service number of the last caller, the terminal UA sends, to the server ORIG through the IMS network, a SIP message of the INVITE type whose session description SDP field contains in particular the information related to to the codec (s) supported by the calling terminal UA as well as the IP address and port number on which it wishes to receive the media stream (s).
  • This INVITE message is received by the originating ORIG server during a step E20.
  • the originating ORIG server determines, during an E21 test, whether to play an early media stream.
  • test E21 is then followed by a step E30 during which the server
  • AS originating ORIG establishes a SIP dialogue with an MRF server of the first IMS network to reserve a first resource MRF1.
  • the originating AS server ORIG sends a 183 In Progress SIP response to the calling terminal UA, in response to the invitation message received in step E20, the SDP field of this response including the SDP identifier MRF1 of the resource (coded chosen following the offer of the terminal UA, IP address and port number on which the resource MRF1 wishes to receive the media stream and / or DTMF sent by the terminal UA).
  • the original originating AS server controls the MRF server to restore, in the first resource MRF1, the media stream associated with the callback service of the last caller.
  • the user of the calling terminal UA requests to be connected, via the input of a DTMF key sequence, to a called SIP (terminal UB) having tried to join it before without success.
  • the originating server is notified of this operation by receiving a notification message from the server MRF, during a step E70.
  • the originating ORIG server if it does not receive such notification during a predetermined TIM time, it releases the call during a step E71.
  • the AS server Upon receipt of this notification, the AS server according to the invention requests, in this embodiment, the reservation of a second MRF2 resource from the aforementioned MRF server, during a step E80.
  • the originating server AS sends, during a step E90, a SIP invitation message destined for a downstream entity, chosen according to the terminal called UB, this invitation message comprising an SDP field identifying this second resource MRF2.
  • this downstream entity is the AS terminating application server, referenced TERM, of the terminal called UB. It is clear to those skilled in the art that the timing diagram of FIG. 1 is simplified and that the SIP invitation message is not sent directly to the downstream entity but to the S-CSCF server which extends it to this downstream entity. .
  • the terminal terminating server TERM of the terminal called UB reserves, with the MRF server, a third resource MRF3 and a fourth resource MRF4.
  • the terminating AS server then establishes a SIP dialogue with the S-CSCF server of the called terminal UB by sending it an invitation message SIP INVITE type whose SDP field includes the identifier MRF4 of the fourth resource.
  • the S-CSCF server splits the call to the two terminals UB1, UB2, of public identity corresponding to that of the terminal called UB, and registered in the core network IMS.
  • This step known to those skilled in the art under the name of forking consists, for the S-CSCF server, in extending the INVITE message to each of these two terminals UB1, UB2.
  • the terminal UB1 responds to this invitation message with a RINGING response 180 including an SDP field (selected coded, IP address and port on which the called terminal expects to receive traffic) associated with the terminal. Bl and identified UB1.
  • This SIP response is received by the AS terminating TERM server from the S-CSCF server.
  • the terminal UB1 starts the restitution of an early media stream on the MRF4 resource of the MRF server.
  • the AS terminating server TERM controls the MRF server to replicate, on the MRF3 resource of the MRF server, the stream received on the resource MRF4.
  • the AS terminating server TERM then sends a SIP 180 RINGING response whose SDP field identifies the resource MRF3, in response to the INVITE invitation message sent to step E90.
  • This SIP response type lxx is received by the originating ORIG server according to the invention during a step E120.
  • the originating ORIGINAL AS server blocks this SIP response, in other words does not transmit it to the calling terminal UA, during a step E130.
  • the originating ORIG server selects, during a general step E140, based on the SIP responses lxx received in step E120, a media stream to be restored to the calling terminal UA.
  • the AS native server ORIG selects: the stream received on the MRF2 resource if the first 1xx SIP response received in step E120 includes an SDP field; or
  • a ringer return media stream generated by the MRF server, if the first lxx SIP response received in step E120 is 180 RINGING without SDP.
  • the AS originating server therefore selects in this example the stream received on the resource MRF2.
  • the AS Originating server controls, during a step E150, the MRF server for restoring the selected media stream on the first resource MRF1.
  • This operation consists, in this example, in replicating the stream received on the resource MRF2 on the resource MRF1.
  • the calling terminal UA receives the media stream generated by the terminal UB1 from the same resource MRF1 that used at the beginning of the callback service of the last caller.
  • the invitation message SIP is extended directly to the called terminal UB, and the first answer type SX answered lxx is transmitted to the calling terminal UA , the other SIP replies of type lxx being blocked.
  • the terminals UB1 and UB2 were SIP terminals of the same IMS network as the calling terminal UA.
  • This second scenario differs from the first scenario in the choice of the downstream entity to which the originating AS sends the SIP invitation message to step E90.
  • the SIP message whose SDP field identifies the second resource MRF2 is sent to an MGCF server able to transform the SIP call signaling into ISUP call signaling and to route the call on the network.
  • RTC or GSM circuit the SIP message whose SDP field identifies the second resource MRF2 is sent to an MGCF server able to transform the SIP call signaling into ISUP call signaling and to route the call on the network.
  • the called number triggers an intelligent network service generating an early media flow in circuit mode to the T-MGF media gateway which itself transmits this early media stream, using the RTP / UDP / IP protocol, to the second MRF2 resource.
  • the MGCF server sends a 183 In Progress SIP response, the SDP field of this response including the identifier of the resource used by the T-MGF gateway for this call.
  • This SIP message of type lxx is received by the server AS originating ORIG according to the invention during step E120 already described.
  • the response 183 In Progress is blocked by the server AS originating ORIG during the step E130 already described.
  • the 183 In Progress response comprising an SDP field
  • the originating AS controls, during the step E150, the MRF server to restore, in the first resource MRF1, the early media stream generated by the smart network.
  • the user of the calling terminal UA can request call setup to the called party UB.
  • this terminal called UB itself would generate an early media stream, for example a Colored Ring Back Tone (CRBT) stream
  • this stream would be transmitted via the media gateway T-MGF and the server AS ORIG ORIG would receive a response from 180 Ringing type with the SDP field containing the identifier of the same resource used by the T-MGF gateway for this call.
  • CBT Colored Ring Back Tone
  • the originating ORIG server would receive, in step 120, a 180 Ringing type response, the SDP field of this response having the same identifier of the resource used by the T-MGF gateway. This response would be blocked by the server ORIG according to this first embodiment of the invention.
  • This third scenario differs from the first two scenarios in the choice of the downstream entity to which the SIP invitation message is sent in step E90.
  • the originating AS server establishes a SIP dialogue with the IBCF interconnection server between the two networks, for sending a SIP INVITE message whose SDP field identifies the second resource MRF2.
  • the server according to the invention is an IBCF interconnection server between two IMS networks.
  • the IBCF server receives, during a step F20, an INVITE message sent by an upstream entity, which may be constituted by a calling terminal UA or by a server placed in an outage. flow between the calling terminal UA and the IBCF server.
  • the IBCF interconnection server according to the invention does not respond directly to the INVITE invitation message.
  • the IBCF server reserves a first resource MRF3 (step F30) and a second resource MRF4 (step F40) with an I-BGF server of the first IMS network.
  • the IBCF interconnection server sends a SIP INVITE invitation message to a downstream entity chosen according to the terminal called UB.
  • this invitation message comprises an SDP field identifying the second resource MRF4 reserved for step F40.
  • this downstream entity is an entity of the second IMS network.
  • this downstream entity is an AS terminating TERM server associated with the terminal called UB.
  • the IBCF interconnection server is capable of receiving, during a step F70, several Ixx type SIP responses in response to the INVITE message sent to the step F60.
  • the terminating server of the terminal called UB is driving an MRF belonging to the second IMS network to play an early media stream, still during the call establishment phase, this stream being received by the IBGF server on the second resource MRF4.
  • the IBCF server selects, during a step F90, a media stream to be restored to the calling terminal UA as a function of the SIP responses received at the step F70.
  • this selection is made on the basis of the first 1xx SIP response received in step F70. If this first response received is 180 Ringing type without SDP, the IBCF server according to the invention responds to the INVITE message received in step F20 by a 180 Ringing response whose SDP field includes the identifier MRF3 of the first resource .
  • the first response received from the second network is a response of the type
  • the IBCF interconnection server responds to the invitation message INVITE received in step F20 by sending a 180 Ringing response whose SDP field identifies the first resource MRF3.
  • the IBCF server responds to the INVITE message received at step F20, by sending a 183 Progress response with the SDP field identifying the first resource MRF3.
  • the IBCF server sends, to the upstream entity, a single response of the type of the first response received from the downstream entity.
  • the selection of step F90 can be performed 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 IBCF server controls, through the SPDF equipment, the interconnection media server IBGF to restore, in the first resource MRF3, the media stream selected at the step F90, either to play a ringback on the MRF3 resource in the case of a 180 Ringing response without SDP, or to replicate the early media stream received on the MRF4 resource to the MRF3 resource in the case of a 180 Ringing response or 183 In Progress with SDP.
  • FIG. 5 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 ROM 11, a RAM RAM 13 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 precisely, when the application server AS is an originating server, this read-only memory comprises a computer program PGO whose instructions, when executed by the processor 10 implement the filtering method whose main steps have been described with reference to Figure 2.
  • this read-only memory comprises an PGI computer program whose instructions, when executed by the processor 10, implement the filtering method, the main ones of which steps have been described with reference to FIG.
  • the communication means 14 of the AS server are able to receive, transmit and interpret a SIP invitation message, to create a SIP response with or without an SDP field, to send such a response on the IMS network and to interpret it.
  • the processor 10 when executing the PGO or PGI computer program, allows the AS server to reserve one or more resources with an MRF or I-BGF server and to control an MRF or I-BGF server so that it renders a media stream on a given resource and replicates a second resource on a first resource.
  • the processor 10 when executing the PGO or PGI computer program, is able to select a media stream to be restored to a SIP terminal, as a function of a SIP response received by the communication means 14.

Landscapes

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

Abstract

Ce procédé de filtrage mis en œuvre par un serveur (ORIG) dans un réseau IMS, comporte les étapes de : - (E20) réception d'un message d'invitation SIP émis par une entité amont (UA); - (E30, E80) de réservation de deux ressources (MRF1, MRF2) auprès d'un serveur; - (E40) d'envoi d'une réponse SIP à l'entité amont (UA) comportant un champ SDP identifiant la première ressource; - (E90) d'envoi à au moins une entité aval, d'un message d'invitation SIP comportant un champ SDP identifiant la deuxième ressource; -(E140) de sélection d'un flux média en fonction (E120, F70) des réponses SIP de type lxx; - (E150) de contrôle du serveur de ressource pour qu'il restitue le flux média dans la première ressource.

Description

Procédé de filtrage de flux Earlv Media dans un réseau IMS et serveur mettant en œuyre 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.
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 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 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 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 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 lxx 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 œ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 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 lxx 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
- 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 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 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 média.
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 lxx 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 média 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 média, toujours en phase d'établissement d'appel, concurrent du premier flux early média 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 lxx 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 œ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 à 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 cœur 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 média.
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 d'invitation reçu à l'étape E20, le champ SDP de cette réponse comportant l'identifiant SDP MRF1 de la ressource (codée 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 S- CSCF 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 cœur 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 (codée sélectionné, adresse IP et port sur lequel le terminal appelé s'attend à recevoir du trafic) associé au terminal Bl 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 UBl 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 lxx étant bloquées.
Dans le premier scénario de la première variante de réalisation qui vient d'être décrit, les terminaux UBl 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 lxx 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 E130 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 média, 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 média, 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 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.
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 œ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, 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 œuvre 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 œuvre 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.

Claims

REVENDICATIONS
1. Procédé de filtrage mis en œuvre 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 lxx 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 lxx.
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.
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 œ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) 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 lxx 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.
PCT/FR2012/051406 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é WO2013001211A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1155873A FR2977433A1 (fr) 2011-06-30 2011-06-30 Procede de filtrage de flux early media dans un reseau ims et serveur mettant en œuvre ce procede
FR1155873 2011-06-30

Publications (1)

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

Family

ID=46456905

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/051406 WO2013001211A1 (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) FR2977433A1 (fr)
WO (1) WO2013001211A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110913084A (zh) * 2019-12-18 2020-03-24 迈普通信技术股份有限公司 会话录音方法、装置、电子设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070058537A1 (en) * 2003-10-16 2007-03-15 Thomas Belling Handling of early media ii
US20080270618A1 (en) * 2002-01-15 2008-10-30 Dynamicsoft, Inc. Establishing and Modifying Network Signaling Protocols

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080270618A1 (en) * 2002-01-15 2008-10-30 Dynamicsoft, Inc. Establishing and Modifying Network Signaling Protocols
US20070058537A1 (en) * 2003-10-16 2007-03-15 Thomas Belling Handling of early media ii

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CAMARILLO G ET AL: "RFC 3312: Integration of Resource Management and SIP", NETWORK WORKING GROUP REQUEST FOR COMMENTS, XX, XX, 1 October 2002 (2002-10-01), pages 1 - 24, XP002281085 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110913084A (zh) * 2019-12-18 2020-03-24 迈普通信技术股份有限公司 会话录音方法、装置、电子设备及存储介质
CN110913084B (zh) * 2019-12-18 2021-09-17 迈普通信技术股份有限公司 会话录音方法、装置、电子设备及存储介质

Also Published As

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

Similar Documents

Publication Publication Date Title
WO2008084056A2 (fr) Procede de signalisation permettant la prise en compte de la raison de l'appel
US20150222753A1 (en) Method for Handling a Call from a Calling Subscriber Towards a Called Subscriber
EP2266285B1 (fr) Procede de terminaison d'un appel et terminal de voix sur ip
EP3777081B1 (fr) Procédé de gestion d'une pluralité de flux média, et dispositif associé
WO2014094914A1 (fr) Surveillance/interruption en temps réel d'enregistrement de message de messagerie vocale
EP2148489A1 (fr) Etablissement et contrôle d'appel par équipement tiers
EP3903476B1 (fr) Procédé de traitement de messages vocaux, procédé de désactivation d'un codage dtmf et procédé de traitement d'une demande de désactivation d'un codage dtmf
WO2012042150A1 (fr) Procédé de gestion de la priorité de flux média préliminaires
EP2926524A1 (fr) Routage d'une requete de service visant un abonne ims
WO2013001211A1 (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
WO2017168084A1 (fr) Procédé de transfert de réseau d'accès pour un terminal mobile en itinérance
EP3701697A1 (fr) Procédé et entité de gestion d'une session multimédia entre un terminal appelant et au moins un terminal appelé, terminal et programme d'ordinateur correspondants
WO2013001213A1 (fr) Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé.
EP3632078B1 (fr) Procédé de contrôle d'une communication comprenant des transactions multiples
EP3646578B1 (fr) Procédé de synchronisation d'état média
WO2017220883A1 (fr) Procédé de détermination d'un ensemble de formats de codage pour établir une communication
US20150156618A1 (en) Delivery of content over a network
EP1982499A1 (fr) Procede et dispositif d'etablissement d'une communication prioritaire
EP2238727B1 (fr) Procédé de communication pour gérer des sessions de communication au niveau d'une passerelle domestique
FR3057129A1 (fr) Procede d'enregistrement simplifie d'un identifiant dans une liste noire
FR2974964A1 (fr) Continuite de service inter-terminal dans un reseau de telecommunications
WO2009112760A1 (fr) Procede de gestion d'une session de communication au niveau d'une passerelle domestique
EP2481205A1 (fr) Procede de parametrage de la sonnerie d'un terminal et equipement apte a mettre en oeuvre ce procede
CN102307190A (zh) 一种实现多媒体会议的方法及多媒体会议平台

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: 12731586

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: 12731586

Country of ref document: EP

Kind code of ref document: A1