WO2011151572A1 - Procede et dispositif de presentation d'un appel entrant dans un reseau ims - Google Patents

Procede et dispositif de presentation d'un appel entrant dans un reseau ims Download PDF

Info

Publication number
WO2011151572A1
WO2011151572A1 PCT/FR2011/051199 FR2011051199W WO2011151572A1 WO 2011151572 A1 WO2011151572 A1 WO 2011151572A1 FR 2011051199 W FR2011051199 W FR 2011051199W WO 2011151572 A1 WO2011151572 A1 WO 2011151572A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
terminal
terminals
impu
call presentation
Prior art date
Application number
PCT/FR2011/051199
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 WO2011151572A1 publication Critical patent/WO2011151572A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/46—Arrangements for calling a number of substations in a predetermined sequence until an answer is obtained
    • H04M3/465—Arrangements for simultaneously calling a number of substations until an answer is obtained
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42187—Lines and connections with preferential service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/46—Arrangements for calling a number of substations in a predetermined sequence until an answer is obtained
    • 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/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/10—Logic circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/14—Delay circuits; Timers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/16—Sequence circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer

Definitions

  • the present invention is in the field of telecommunication networks and more particularly in the field of IMS networks.
  • a UA SIP terminal (in English User Agent) comprises:
  • AoC in English "Address of Contact" corresponding to the IP (Internet Protocol) address of the terminal, its port number and information representative of the transport protocol (UDP, TCP, TLS, ... ) ⁇
  • the IETF document RFC3261 defines a call presentation mechanism making it possible to ring, in the case of an incoming call intended for a given public identity IMPU, one or more terminals in priority among all terminals with this same public identity IMPU registered in IMS core.
  • the contact address AoC of a terminal UA may comprise a parameter q constituted by a real number between 0 and 1 (the value 1 corresponding to the maximum priority, the value 0 to the minimum priority), parameter defining the priority of this terminal in terms of order of presentation of an incoming call.
  • a SIP proxy routes SIP call signaling.
  • This proxy can in particular be an S-CSCF server (proxy called “statefull”, that is to say, managing the context and SIP dialogs) or an I-CSCF server (proxy called “stateless” ie not managing the context).
  • Termination services are defined as services that are triggered or activated during an incoming call, such as Call Forwarding or Caller ID or Caller ID services.
  • a call presentation module of this proxy makes the AU terminals of the same priority q ring in parallel (call presentation in simultaneous or parallel mode ), the terminals having a higher q value ringing priority over the terminals having a lower q value (call presentation in sequential mode).
  • a call presentation timer in English Timer makes it possible to notify the highest priority terminal during the call. duration of this countdown and then in case of no response, the SIP Proxy cancels this call presentation and presents the call on the parameter terminal (s) q less priority.
  • the non-response countdown managed by the application server managing the termination services applies and the call is directed to the voicemail or to a terminal. third number.
  • an AU terminal registers itself at the heart of the network by sending a SIP REGISTER request to a proxy Registrar, this request notably comprising the public identity IMPU of this terminal and its contact address AoC.
  • the proxy REGISTRAR When the registration of a terminal UA of a given public identity IMPU is accepted, the proxy REGISTRAR responds to this terminal UA by sending a response 200 OK containing all the contact addresses AoC associated with this public identity IMPU and an EXPIRES parameter known to those skilled in the art for each of these AoC contact addresses.
  • This EXPIRES parameter defines the period (typically 3600s) that a terminal must respect between two consecutive recordings in the network.
  • a location service module of the IMS core network this module can be implemented in the form of a database or a database.
  • an LDAP directory for example.
  • the S-CSCF proxy When an incoming call is presented to the S-CSCF proxy, the latter sends a request to the location service module, this request comprising the called party's public identity IMPU and receives in response the list of the five AoC contact addresses of the caller. terminals registered at the core of IMS network with this public identity IMPU.
  • the S-CSCF proxy transmits this response to the call presentation module which determines, in the case of Figure 1:
  • the call presentation module then triggers a call presentation countdown initialized in this example to 15 seconds, and directs the call to the two UA terminals of priority q equal to 1 via the sending of a message SIP to each of these terminals.
  • the call presentation module cancels the call presentation by sending a SIP CANCEL message.
  • the module does not reset the call presentation countdown since there remains only one group (in this case three terminals) to notify of the incoming call. If one of these three terminals accepts the incoming call, which results in the sending of a code 200 OK, the call presentation module cancels the call to the other terminals. If none of the terminals accepts the call, the three terminals continue to be notified until the expiration of a non-response timer managed by the application server managing the termination services.
  • the query by the SIP server of the location service module is performed only on receipt of an incoming INVITE message, after execution of the termination services.
  • This mechanism has a major disadvantage: it does not properly manage the registration or de-registration of a terminal in the network.
  • the present invention provides an incoming call presentation method in an IMS network that does not have the disadvantages of the prior art.
  • the invention is directed to a method of presenting an incoming call in an IMS network, this method comprising:
  • the presentation method according to the invention is remarkable in that it comprises, during the call presentation phase:
  • the invention also provides a call presentation module that can be used in an IMS network, this module comprising:
  • a location service module means for querying a location service module to obtain at least one contact address of a terminal registered in the IMS network with this public identity, each contact address being likely to include a priority parameter;
  • This call presentation module is remarkable in that its interrogation module is able to interrogate at least a second time the location service module during the call presentation phase and to update the aforementioned groups according to of the result of these interrogations.
  • the invention also relates to an S-CSCF server comprising such a call presentation module.
  • the invention proposes to interrogate the location service module during the call presentation phase, in order to update the groups of terminals, this making it possible to take into account the recording and the unregistering terminals to present and / or cancel the call based on their priorities.
  • the second interrogation step is performed periodically during the call presentation phase; the interrogation period may for example be chosen equal to one second.
  • the second interrogation step may be performed on detection of an event chosen from:
  • the method according to the invention cancels the call presentation to this terminal.
  • the SIP proxy interrogation of the location service module is performed only on receipt of an incoming INVITE message, after execution of the termination services.
  • the called terminal accepts the call on a terminal that is no longer registered in the IMS network
  • edge effects may occur depending on the implementation, the call may for example be immediately cut after acceptance either by the terminal or by the network.
  • the call presentation method on detecting the de-registration of a terminal comprising the public identity concerned, deletes the terminal from its group.
  • the call presentation method comprises, on detecting the recording of a terminal comprising the public identity concerned, a step of adding this terminal to the group of terminals. with the same priority parameter as this terminal.
  • This mechanism advantageously makes it possible to take into account the recording of terminals of lower priority, on the fly, and to ring them according to their priorities, in the case where the call presentation countdown expires for the terminals of priority, none of whom accepted the incoming call.
  • the SIP terminals not registered at the heart of the network at the time of the incoming call are not notified of this call.
  • the time required for the notification, the start of the application of VoIP, the recovery of the VoIP configuration file via a dedicated server, and its registration in the core network IMS is too long compared to processing of SIP call signaling at the call presentation module which intervenes immediately.
  • the call presentation method does not slow down the establishment upstream of the call presentation function, and does not induce any additional waiting period for linking the call. 'appellant.
  • the call presentation method when the call presentation method detects the recording of a terminal comprising the public identity concerned, it adds this terminal to a group of terminals comprising a priority parameter lower than that of the terminal.
  • the various steps of the call presentation method are determined by computer program instructions.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented by a computer, this program comprising instructions adapted to the implementation of the steps of the method of steering 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 2 to 5 show examples of call presentation methods and S-CSCF servers according to particular embodiments of the invention.
  • FIG. 2 shows an S-CSCF server receiving, during a step E5, an INVITE message comprising a public identity IMPU.
  • the S-CSCF server interrogates, during a step E10, a location service module LS to obtain the AoC contact addresses of the terminals registered in the IMS network with this public identity IMPU.
  • the S-CSCF server starts, during a step E30, a call presentation countdown, and presents the call, by sending an INVITE message, to the UA terminals whose parameter q equals 1.
  • the S-CSCF server performs, during steps E20, several interrogation steps of the location service module during the call presentation phase.
  • the S-CSCF proxy When it detects this desregistration by interrogation of the location service module, the S-CSCF proxy according to the invention updates the call presentation groups.
  • the S-CSCF server cancels the call presentation to this terminal UA during a general step E55, via the message sequence CANCEL, 200 OK, 487 REQUEST TERMINATED, ACK.
  • This particular embodiment of the invention avoids edge effects if the terminal accepted the call after being de-registered.
  • Figure 3 shows a possible implementation of the invention, to process the recording (step E60) of a terminal UA, it has not yet been notified of the incoming call.
  • the S-CSCF server adds this terminal to the group of terminals whose priority parameter q is equal to 1.
  • this terminal is notified of the incoming call during a step E65.
  • the parameter terminal UA2 equal to 1 requests to register (step E60) during the phase of presenting the call to the lower priority parameter terminals 0.5.
  • the call to the highest priority terminals is not presented when the call is being presented to lower priority terminals. Therefore, the UA2 terminal of priority q equal to 1 is not notified.
  • an UA terminal registers itself at the core of the IMS network with a priority parameter q equal to 1 during the phase of presentation of the call to the lower priority UA terminals 0.5.
  • the terminal is added to the group of terminals having a parameter 0.5 less than its parameter 1, during a step E20.
  • this newly registered terminal is notified of the call during a step E75.

Abstract

Ce procédé comporte: une étape (E5) de réception d'un message INVITE comportant une identité publique (IMPU) d'au moins un terminal; une première étape (E10) d'interrogation d'un module de service de localisation pour obtenir au moins une adresse de contact (AoC) d'un terminal enregistré dans ledit réseau IMS avec cette identité publique (IMPU), chaque adresse de contact (AoC) étant susceptible de comporter un paramètre (q) de priorité; une étape (E10) de regroupement desdits terminaux dans au moins un groupe, les terminaux d'un même groupe ayant le même paramètre de priorité; et une phase de présentation d'appel au cours de laquelle l'appel est présenté en parallèle à tous les terminaux d'un même groupe, les groupes étant considérés séquentiellement selon la valeur du paramètre de priorité; et pendant la phase de présentation d'appel: au moins une deuxième étape (E20) d'interrogation dudit module de service de localisation; et une étape (E20) de mise à jour desdits groupes en fonction du résultat de ladite deuxième étape d'interrogation.

Description

Procédé et dispositif de présentation d'un appel entrant dans un réseau IMS
Arrière-plan de l'invention
La présente invention se situe dans le domaine des réseaux de télécommunication et plus particulièrement dans le domaine des réseaux IMS.
Le chapitre 10 du document RFC3261 de l'IETF définit la procédure d'enregistrement SIP dans les réseaux IMS.
Dans un tel réseau, un terminal UA SIP (en anglais User Agent) comporte :
- une identité publique IMPU correspondant par exemple à son numéro de téléphone, autrement appelée AoR (Address of Record en anglais) ;
- une adresse de contact AoC (en anglais « Address of Contact ») correspondant à l'adresse IP (Internet Protocol) du terminal, son numéro de port et une information représentative du protocole de transport (UDP, TCP, TLS, ...)■
Plusieurs terminaux pouvant comporter la même identité publique IMPU, le document IETF RFC3261 définit un mécanisme de présentation d'appel permettant de faire sonner, en cas d'appel entrant destiné à une identité publique IMPU donnée, un ou plusieurs terminaux en priorité parmi tous les terminaux possédant cette même identité publique IMPU enregistrés en cœur IMS.
A cet effet, l'adresse de contact AoC d'un terminal UA peut comporter un paramètre q constitué par un nombre réel compris entre 0 et 1 (la valeur 1 correspondant à la priorité maximale, la valeur 0 à la priorité minimale) , ce paramètre définissant la priorité de ce terminal en terme d'ordre de présentation d'un appel entrant.
Conformément au modèle fonctionnel SIP défini dans le document RFC3261, un proxy SIP route la signalisation d'appel SIP. Ce proxy peut notamment être un serveur S- CSCF (proxy dit « statefull », c'est-à-dire gérant le contexte et les dialogues SIP) ou un serveur I-CSCF (proxy dit « stateless » c'est à dire ne gérant pas le contexte).
Dans le cas où plusieurs terminaux partageant la même identité publique IMPU sont enregistrés en cœur de réseau IMS, si un appel entrant est présenté, le proxy SIP, après le traitement des services de terminaison (en anglais « Terminating ») lié à cette IMPU par un serveur d'application téléphonique de terminaison, interroge un module de service de localisation (en anglais « Location Service ») pour router l'appel vers les différents terminaux enregistrés sous cette IMPU. On rappelle que les services de terminaison correspondent aux services déclenchés ou activés lors d'un appel entrant, par exemple les services de renvoi d'appel ou de présentation du numéro ou du nom de l'appelant. Plus précisément, lorsqu'un appel entrant à destination de l'IMPU est présenté au proxy, un module de présentation d'appel de ce proxy fait sonner en parallèle les terminaux UA de même priorité q (présentation d'appel en mode simultané ou parallèle), les terminaux ayant une valeur q supérieure sonnant en priorité par rapport aux terminaux ayant une valeur q inférieure (présentation d'appel en mode séquentiel).
La présentation d'appel en mode simultané ou séquentielle est aussi connue de l'homme du métier sous l'expression « Forking ».
Dans le cas d'une présentation d'appel séquentielle (au moins 2 terminaux enregistrés avec des paramètres "q" différents), un compte à rebours (en anglais Timer) de présentation d'appel permet de notifier le terminal le plus prioritaire pendant la durée de ce compte à rebours puis en cas de non réponse, le Proxy SIP annule cette présentation d'appel et présente l'appel sur le ou les terminaux de paramètre q moins prioritaire.
En cas de non réponse d'un terminal, dernier de la chaîne, le compte à rebours de non réponse géré par le serveur d'application gérant les services de terminaison s'applique et l'appel est dirigé vers la messagerie vocale ou vers un numéro tiers.
On rappelle que dans un réseau IMS, un terminal UA s'enregistre en cœur de réseau en envoyant une requête SIP REGISTER à un proxy Registrar, cette requête comportant notamment l'identité publique IMPU de ce terminal et son adresse de contact AoC.
Lorsque l'enregistrement d'un terminal UA d'une identité publique IMPU donnée est accepté, le proxy REGISTRAR répond à ce terminal UA par l'envoi d'une réponse 200 OK comportant toutes les adresses de contact AoC associées à cette identité publique IMPU et un paramètre EXPIRES connu de l'homme du métier pour chacune de ces adresses de contact AoC.
Ce paramètre EXPIRES définit la période (typiquement 3600s) que doit respecter un terminal entre deux enregistrements consécutifs dans le réseau.
De façon connue, la correspondance entre une identité publique IMPU et les adresses de contact (AoC) est gérée par un module de service de localisation du cœur de réseau IMS, ce module pouvant être implémenté sous la forme d'une base de données ou d'un annuaire LDAP par exemple.
La Figure 1 illustre un exemple dans lequel cinq terminaux UA SIP s'enregistrent avec la même identité publique IMPU, les deux premiers terminaux avec une priorité maximale (q= l) et les trois autres avec une priorité inférieure (q=0,5). On constate que le module LS de service de localisation est mis à jour suite aux différents enregistrements des terminaux UA par le proxy Registrar, implémenté, dans cet exemple par le proxy S-CSCF.
Lorsqu'un appel entrant est présenté au proxy S-CSCF, ce dernier envoie une requête au module de service de localisation, cette requête comportant l'identité publique IMPU de l'appelé et reçoit en réponse la liste des cinq adresses de contact AoC des terminaux enregistrés en cœur de réseau IMS avec cette identité publique IMPU.
Le proxy S-CSCF transmet cette réponse au module de présentation d'appel qui détermine, dans le cas de la figure 1 :
- que deux terminaux UA ont un paramètre de priorité q égal à 1 représentatif d'une priorité maximale et qu'il convient donc de les faire sonner en parallèle et en priorité ; et
- que trois terminaux UA ont un paramètre q égal à 0.5.
Le module de présentation d'appel déclenche alors un compte à rebours de présentation d'appel initialisé dans cet exemple à 15 secondes, et dirige l'appel vers les deux terminaux UA de priorité q égale à 1 via l'envoi d'un message SIP à destination de chacun de ces terminaux.
Si aucun de ces terminaux ne décroche dans le délai de 15 secondes précité, le module de présentation d'appel annule la présentation d'appel par l'envoi d'un message SIP CANCEL.
Le module ne réarme pas le compte à rebours de présentation d'appel puisqu'il ne reste qu'un groupe (en l'espèce de trois terminaux) à notifier de l'appel entrant. Si l'un de ces trois terminaux accepte l'appel entrant, ce qui se traduit par l'envoi d'un code 200 OK, le module de présentation d'appel annule l'appel vers les autres terminaux. Si aucun des terminaux n'accepte l'appel, les trois terminaux continuent à être notifiés jusqu'à l'expiration d'un timer de non réponse géré par le serveur d'application gérant les services de terminaison.
Il est fondamental de constater que dans le mécanisme ci-dessus, l'interrogation par le serveur SIP du module de service de localisation est réalisée uniquement sur réception d'un message INVITE entrant, après exécution des services de terminaison.
Ce mécanisme présente un inconvénient majeur : il ne permet de gérer convenablement ni l'enregistrement ni le dés-enregistrement d'un terminal dans le réseau.
Objet et résumé de l'invention La présente invention propose un procédé de présentation d'appel entrant dans un réseau IMS qui ne présente pas les inconvénients de l'art antérieur.
Plus précisément, et selon un premier aspect, l'invention vise un procédé de présentation d'un appel entrant dans un réseau IMS, ce procédé comportant :
une étape de réception d'un message INVITE comportant une identité publique d'au moins un terminal ;
une première étape d'interrogation d'un module de service de localisation pour obtenir au moins une adresse de contact d'un terminal enregistré dans le réseau IMS avec cette identité publique, chaque adresse de contact étant susceptible de comporter un paramètre de priorité ;
une étape de regroupement des terminaux dans au moins un groupe, les terminaux d'un même groupe ayant le même paramètre de priorité précité ; et une phase de présentation d'appel au cours de laquelle l'appel est présenté en parallèle à tous les terminaux d'un même groupe, les groupes étant considérés séquentiellement selon la valeur du paramètre de priorité précité, jusqu'à acceptation de l'appel par un terminal ou expiration d'un délai déterminé.
Le procédé de présentation selon l'invention est remarquable en ce qu'il comporte, au cours de la phase de présentation d'appel :
- au moins une deuxième étape d'interrogation du module de service de localisation ; et
une étape de mise à jour des groupes précités en fonction du résultat de cette deuxième étape d'interrogation.
Corrélativement, l'invention vise également un module de présentation d'appel pouvant être utilisé dans un réseau IMS, ce module comportant :
des moyens de réception d'un message INVITE comportant une identité publique d'au moins un terminal ;
des moyens d'interrogation d'un module de service de localisation pour obtenir au moins une adresse de contact d'un terminal enregistré dans le réseau IMS avec cette identité publique, chaque adresse de contact étant susceptible de comporter un paramètre de priorité ;
des moyens pour regrouper les terminaux dans au moins un groupe, les terminaux d'un même groupe ayant le même paramètre de priorité précité ; et des moyens pour présenter, au cours d'une phase de présentation d'appel, cet appel en parallèle à tous les terminaux d'un même groupe, les groupes étant considérés séquentiellement selon la valeur de ce paramètre jusqu'à acceptation de l'appel par un terminal ou expiration d'un délai déterminé.
Ce module de présentation d'appel est remarquable en ce que son module d'interrogation est apte à interroger au moins une deuxième fois le module de service de localisation pendant la phase de présentation d'appel et à mettre à jour les groupes précités en fonction du résultat de ces interrogations.
L'invention vise également un serveur S-CSCF comportant un tel module de présentation d'appel.
Ainsi, et de façon générale, l'invention propose d'interroger le module de service de localisation pendant la phase de présentation d'appel, afin de mettre à jour les groupes de terminaux, ceci permettant de prendre en compte l'enregistrement et le dés- enregistrement de terminaux pour présenter et ou annuler l'appel en fonction de leurs priorités.
Dans un mode particulier de réalisation de l'invention, la deuxième étape d'interrogation est effectuée périodiquement pendant la phase de présentation d'appel ; la période d'interrogation peut par exemple être choisie égale à une seconde.
Dans un mode particulier de réalisation de l'invention, la deuxième étape d'interrogation peut être effectuée sur détection d'un événement choisi parmi :
le démarrage du compte à rebours de présentation de l'appel à au moins un terminal ;
l'expiration du compte à rebours de présentation de l'appel à au moins un terminal ;
la réception d'un code de réponse émis par un terminal ; et
la notification d'un événement d'enregistrement ou de dés-enregistrement d'un terminal comportant l'identité publique concernée.
Par exemple, dans un mode de réalisation de l'invention, sur détection du dés- enregistrement d'un terminal comportant l'identité publique concernée, le procédé selon l'invention annule la présentation d'appel à ce terminal.
Ceci résout un problème majeur de l'état actuel de la technique.
En effet, selon la norme RFC3261 dans son état actuel, l'interrogation par le proxy SIP du module de service de localisation est réalisée uniquement sur réception d'un message INVITE entrant, après exécution des services de terminaison.
Par conséquent, dans le cas d'une présentation d'appel séquentielle où la durée d'appel peut être longue, si un ou plusieurs terminaux se dés-enregistrent du réseau après la phase de consultation du module de service de localisation, ces terminaux peuvent potentiellement accepter des appels entrants alors qu'ils n'ont plus le droit au service de voix sur IP.
En termes d'usage, si le terminal appelé accepte l'appel sur un terminal qui n'est plus enregistré dans le réseau IMS, des effets de bord peuvent se produire selon les implémentations, l'appel pouvant par exemple être immédiatement coupé après acceptation soit par le terminal soit par le réseau.
Dans un mode particulier de réalisation de l'invention, sur détection du dés- enregistrement d'un terminal comportant l'identité publique concernée, le procédé de présentation d'appel supprime le terminal de son groupe.
Dans un mode particulier de réalisation de l'invention, le procédé de présentation d'appel comporte, sur détection de l'enregistrement d'un terminal comportant l'identité publique concernée, une étape d'ajout de ce terminal dans le groupe des terminaux comportant le même paramètre de priorité que ce terminal.
Ce mécanisme permet avantageusement de prendre en compte l'enregistrement de terminaux de priorité moindre, à la volée, et de les faire sonner en fonction de leurs priorités, dans le cas où le compte à rebours de présentation d'appel expire pour les terminaux de priorité supérieure, aucun d'entre eux n'ayant accepté l'appel entrant.
Ceci résout un autre problème de l'état actuel de la technique.
En effet, selon les mécanismes de présentation d'appel connus à ce jour, les terminaux SIP non enregistrés en cœur de réseau au moment de l'appel entrant ne sont pas notifiés de cet appel.
Ce point est très pénalisant, notamment pour les terminaux dont la pile de voix sur IP SIP ne supportent pas le multitâche, mais également pour les terminaux pour lesquels on évite d'activer l'application de voix sur IP afin de ne pas décharger prématurément leurs batteries.
Pour ces terminaux en effet, le temps nécessaire à la notification, le démarrage de l'application de voix sur IP, la récupération du fichier de configuration VoIP via un serveur dédié, et son enregistrement en cœur de réseau IMS est trop long par rapport au traitement de la signalisation d'appel SIP au niveau du module de présentation d'appel qui intervient immédiatement.
Du coup, ces terminaux ne peuvent jamais recevoir d'appels sauf à mettre en place dans le réseau IMS des mécanismes applicatifs complexes et coûteux.
On notera en particulier, que le procédé de présentation d'appel selon l'invention ne freine pas l'établissement en amont de la fonction de présentation d'appel, et n'induit aucun délai d'attente complémentaire de mise en relation de l'appelant. Dans un mode particulier de réalisation de l'invention, lorsque le procédé de présentation d'appel détecte l'enregistrement d'un terminal comportant l'identité publique concernée, il ajoute ce terminal dans un groupe de terminaux comportant un paramètre de priorité inférieure à celui du terminal.
Cette solution permet de récupérer des terminaux de priorité supérieure non enregistrés au moment du déclenchement de la phase de présentation d'appel, et donc de leur présenter également l'appel entrant.
Dans un mode particulier de réalisation, les différentes étapes du procédé de présentation d'appel 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 ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes du procédé de pilotage 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 annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif.
Sur les figures :
la figure 1 déjà décrite illustre l'enregistrement de cinq terminaux dans un réseau IMS ; et
les figures 2 à 5 représentent des exemples de procédés de présentation d'appel et de serveurs S-CSCF conformes à des modes particuliers de réalisation de l'invention.
Description détaillée de l'invention
A la Figure 2 on a représenté un serveur S-CSCF recevant, au cours d'une étape E5, un message INVITE comportant une identité publique IMPU.
On considérera, dans cette figure et dans les suivantes, cinq terminaux UA ayant cette identité publique, deux terminaux avec une priorité de présentation maximale q = 1 et les trois autres une priorité inférieure q = 0,5.
Conformément à la norme RFC3261, le serveur S-CSCF interroge, au cours d'une étape E10, un module LS de service de localisation pour obtenir les adresses de contact AoC des terminaux enregistrés dans le réseau IMS avec cette identité publique IMPU.
Dans l'exemple de réalisation décrit ici, le serveur S-CSCF démarre, au cours d'une étape E30, un compte à rebours de présentation d'appel, et présente l'appel, par l'envoi d'un message INVITE, aux terminaux UA dont le paramètre q égal 1.
Conformément à l'invention, le serveur S-CSCF effectue, au cours d'étapes E20, plusieurs étapes d'interrogation du module de service de localisation pendant la phase de présentation d'appel.
Nous supposons dans cet exemple, que l'un des terminaux UA de paramètre q égal à 1, se dés-en registre au cours d'une étape E50 par l'envoi d'un message DEREGISTER, pendant la présentation d'appel vers cet UA.
Lorsqu'il détecte ce dés-enregistrement par interrogation du module de service de localisation, le proxy S-CSCF selon l'invention met à jour les groupes de présentation d'appel.
Conformément à ce mode particulier de réalisation de l'invention, le serveur S- CSCF annule la présentation d'appel vers ce terminal UA au cours d'une étape générale E55, via la séquence de message CANCEL, 200 OK, 487 REQUEST TERMINATED, ACK. Ce mode particulier de réalisation de l'invention permet d'éviter des effets de bord si ce terminal acceptait l'appel après avoir été dés-enregistré.
Dans le cas où le terminal UA venant de se dés-enregistrer n'était pas en cours de notification de l'appel par le S-CSCF, ce terminal serait simplement supprimé du groupe auquel il appartient.
La Figure 3 présente une mise en œuvre possible de l'invention, pour traiter l'enregistrement (étape E60) d'un terminal UA, celui-ci n'ayant pas encore été notifié de l'appel entrant.
Conformément à l'invention, au cours de l'interrogation suivante du module de service de localisation, le serveur S-CSCF ajoute ce terminal dans le groupe des terminaux dont le paramètre q de priorité égale à 1.
Par conséquent, de façon très avantageuse, ce terminal est notifié de l'appel entrant au cours d'une étape E65.
Dans l'exemple de la Figure 4, le terminal UA2 de paramètre q égal à 1 demande à s'enregistrer (étape E60) pendant la phase de présentation de l'appel aux terminaux de paramètre de priorité inférieure 0,5.
Dans ce mode de réalisation de l'invention, on ne présente pas l'appel aux terminaux de plus haute priorité dès lors que l'appel est en cours de présentation aux terminaux de priorité inférieure. Par conséquent, le terminal UA2 de priorité q égale à 1 n'est pas notifié.
Toujours en référence à cette figure, nous supposons que le terminal UA4 de paramètre q égal à 0,5 demande à s'enregistrer (étape E60) pendant la phase de présentation de l'appel aux terminaux de paramètre de priorité égal à 0,5.
Dans ce mode de réalisation de l'invention, après l'étape E20 d'interrogation suivante, l'appel est présenté au terminal UA4. Cela n'aurait pas été possible sans la mise en œuvre de l'invention.
Dans le mode de réalisation de la Figure 5, un terminal UA s'enregistre en cœur de réseau IMS avec un paramètre de priorité q égal à 1 pendant la phase de présentation de l'appel aux terminaux UA de priorité inférieure 0,5.
Dans ce mode particulier de réalisation de l'invention le terminal est ajouté au groupe des terminaux comportant un paramètre 0,5 inférieur à son paramètre 1, au cours d'une étape E20.
Par conséquent, ce terminal nouvellement enregistré est notifié de l'appel au cours d'une étape E75.

Claims

REVENDICATIONS
1. Procédé de présentation d'un appel entrant dans un réseau IMS, ce procédé comportant :
- une étape (E5) de réception d'un message INVITE comportant une identité publique (IMPU) d'au moins un terminal ;
- une première étape (E10) d'interrogation d'un module de service de localisation pour obtenir au moins une adresse de contact (AoC) d'un terminal enregistré dans ledit réseau IMS avec ladite identité publique (IMPU), chaque adresse de contact (AoC) étant susceptible de comporter un paramètre (q) de priorité ;
- une étape (E10) de regroupement desdits terminaux dans au moins un groupe, les terminaux d'un même groupe ayant le même dit paramètre de priorité ; et
- une phase de présentation d'appel au cours de laquelle ledit appel est présenté en parallèle à tous les terminaux d'un même groupe, les groupes étant considérés séquentiellement selon la valeur dudit paramètre de priorité, jusqu'à acceptation de l'appel par un terminal ou expiration d'un délai déterminé ;
ledit procédé étant caractérisé en ce qu'il comporte au moins au cours de ladite phase de présentation d'appel :
- une deuxième étape (E20) d'interrogation dudit module de service de localisation ; et - une étape (E20) de mise à jour desdits groupes en fonction du résultat de ladite deuxième étape d'interrogation.
2. Procédé de présentation d'appel selon la revendication 1 caractérisé en ce que ladite deuxième étape d'interrogation est effectuée périodiquement pendant la phase de présentation d'appel.
3. Procédé de présentation d'appel selon la revendication 1 caractérisé en ce que ladite deuxième étape d'interrogation est effectuée sur détection d'un événement choisi parmi :
- démarrage (E30) du compte à rebours de présentation d'appel à au moins un desdits terminaux ;
- expiration (E40) du compte à rebours de présentation de l'appel à au moins un desdits terminaux ;
- réception d'un code de réponse émis par un desdits terminaux ; et
- notification d'un événement d'enregistrement (E60) ou de dés-enregistrement (E50) d'un terminal comportant ladite identité publique (IMPU).
4. Procédé de présentation d'appel selon la revendication 1, caractérisé en ce qu'il comporte :
- une étape (E50) de détection du dés-enregistrement d'un terminal comportant ladite identité publique (IMPU) ; et
- une étape (E55) d'annulation de ladite présentation d'appel audit terminal.
5. Procédé de présentation d'appel selon la revendication 1, caractérisé en ce qu'il comporte :
- une étape (E50) de détection du dés-enregistrement d'un terminal comportant ladite identité publique (IMPU) ; et
- une étape (E50) de suppression dudit terminal de son groupe.
6. Procédé de présentation d'appel selon la revendication 1, caractérisé en ce qu'il comporte :
- une étape (E60) de détection de l'enregistrement d'un terminal comportant ladite identité publique (IMPU) ; et
- une étape (E60) d'ajout dudit terminal dans le groupe des terminaux comportant le même dit paramètre de priorité (q) que ce terminal.
7. Procédé de présentation d'appel selon la revendication 1, caractérisé en ce qu'il comporte :
- une étape (E60) de détection de l'enregistrement d'un terminal comportant ladite identité publique (IMPU) ; et
- une étape (E60) d'ajout dudit terminal dans un groupe des terminaux comportant un dit paramètre de priorité (q) inférieur à celui dudit terminal.
8. Module de présentation d'appel pouvant être utilisé dans un réseau IMS, ce module comportant :
- des moyens de réception d'un message INVITE comportant une identité publique (IMPU) d'au moins un terminal ;
- des moyens d'interrogation d'un module de service de localisation pour obtenir au moins une adresse de contact (AoC) d'un terminal enregistré dans ledit réseau IMS avec ladite identité publique (IMPU), chaque adresse de contact (AoC) étant susceptible de comporter un paramètre (q) de priorité ; - des moyens pour regrouper lesdits terminaux dans au moins un groupe, les terminaux d'un même groupe ayant le même dit paramètre de priorité ; et
- des moyens pour présenter, au cours d'une phase de présentation d'appel, ledit appel en parallèle à tous les terminaux d'un même groupe, les groupes étant considérés séquentiellement selon la valeur dudit paramètre, jusqu'à acceptation de l'appel par un terminal ou expiration d'un délai déterminé ;
ledit module de présentation d'appel étant caractérisé en ce que ledit module d'interrogation est apte à réinterroger au moins une deuxième fois ledit module de service de localisation pendant la phase de présentation d'appel et à mettre à jour lesdits groupes en fonction du résultat de ladite deuxième interrogation.
9. Serveur S-CSCF comportant un module de présentation d'appel selon la revendication 8.
10. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de présentation d'appel selon l'une quelconque des revendications 1 à 7 lorsque ledit programme est exécuté par un ordinateur.
11. Support d'enregistrement 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 présentation d'appel selon l'une quelconque des revendications 1 à 7.
PCT/FR2011/051199 2010-05-31 2011-05-26 Procede et dispositif de presentation d'un appel entrant dans un reseau ims WO2011151572A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1054202 2010-05-31
FR1054202 2010-05-31

Publications (1)

Publication Number Publication Date
WO2011151572A1 true WO2011151572A1 (fr) 2011-12-08

Family

ID=42731836

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2011/051199 WO2011151572A1 (fr) 2010-05-31 2011-05-26 Procede et dispositif de presentation d'un appel entrant dans un reseau ims

Country Status (1)

Country Link
WO (1) WO2011151572A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009148931A2 (fr) * 2008-06-06 2009-12-10 Motorola, Inc.(1/5) Gestion de groupe d'appel utilisant le protocole d'ouverture de session

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009148931A2 (fr) * 2008-06-06 2009-12-10 Motorola, Inc.(1/5) Gestion de groupe d'appel utilisant le protocole d'ouverture de session

Similar Documents

Publication Publication Date Title
EP2772035B1 (fr) Procede de gestion d'une communication destinee a un utilisateur et serveur d'application
EP2266285B1 (fr) Procede de terminaison d'un appel et terminal de voix sur ip
EP2856732B1 (fr) Procédé et entité de traitement d'un message
EP2550776B1 (fr) Procede de gestion des enregistrements dans un reseau ims et serveur s-cscf mettant en oeuvre ce procede
WO2013079865A1 (fr) ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP
WO2012089954A2 (fr) Gestion des equipements utilisateurs ayant la meme identite publique par un serveur d'application dans un reseau ims
WO2011151572A1 (fr) Procede et dispositif de presentation d'un appel entrant dans un reseau ims
WO2017168084A1 (fr) Procédé de transfert de réseau d'accès pour un terminal mobile en itinérance
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP2859704B1 (fr) Serveur d'application et procede de traitement d'un message destine a une identite publique partagee par une pluralite de dispositifs
WO2012085429A2 (fr) Procédé de localisation et d'identification d'un abonné connecté à un réseau émulant le rtc/rnis
EP3632078B1 (fr) Procédé de contrôle d'une communication comprenant des transactions multiples
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
EP2429145A1 (fr) Procédé de présentation d'appel dans un réseau IMS et serveur d'application apte à mettre en oeuvre ce procédé
WO2014114871A1 (fr) Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication
WO2013001211A1 (fr) Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé
WO2012072920A1 (fr) Procédé et dispositif de gestion d'une souscription a un service dans un réseau ims
WO2012117178A1 (fr) Procédé de gestion d'identites publiques par un utilisateur d'un reseau ims
WO2013156727A1 (fr) Procede de traitement d'un message, entite et cœur de reseau
WO2009112760A1 (fr) Procede de gestion d'une session de communication au niveau d'une passerelle domestique
WO2013001213A1 (fr) Procédé de filtrage de flux early media dans un réseau ims et serveur mettant en oeuvre ce procédé.
EP1903751A1 (fr) Procédé de routage d'une demande d'établissement d'appel
EP2801178A1 (fr) Procede dynamique de determination d'une liste de services dans un reseau sip
FR2991540A1 (fr) Procede et dispositif de selection d'une entite communicante pour recevoir une signalisation d'un appel entrant

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

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

Country of ref document: EP

Kind code of ref document: A1