WO2012049404A1 - Procede de traitement des flux de presence dans un reseau sip - Google Patents

Procede de traitement des flux de presence dans un reseau sip Download PDF

Info

Publication number
WO2012049404A1
WO2012049404A1 PCT/FR2011/052332 FR2011052332W WO2012049404A1 WO 2012049404 A1 WO2012049404 A1 WO 2012049404A1 FR 2011052332 W FR2011052332 W FR 2011052332W WO 2012049404 A1 WO2012049404 A1 WO 2012049404A1
Authority
WO
WIPO (PCT)
Prior art keywords
uri
sip
network
correspondent
server
Prior art date
Application number
PCT/FR2011/052332
Other languages
English (en)
Inventor
Thibaut Coadic
Marc Bailly
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 WO2012049404A1 publication Critical patent/WO2012049404A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4557—Directories for hybrid networks, e.g. including telephone numbers
    • 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
    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users

Definitions

  • the present invention relates to telecommunications networks of IP ("Internet Protocol") type, and in particular those of IP networks that are able to implement advanced session control protocols.
  • IP networks allow the transmission of conversational data, in the context of services such as "Voice over IP” (VoIP), "Content Sharing", or "Instant Messaging”.
  • the present invention relates to the means implemented in an IP network using the session control protocol SIP (initials of the words “Session Initiation Protocol” meaning “Session Initiation Protocol”), designated hereinafter by "SIP network”, to provide a service called "Presence”.
  • SIP session control protocol
  • a device-client ("User Equipment” in English) "belongs” to the network of a given operator when the user of this device-client has an account with this operator, and this, whatever the Access network used by the client device to connect to the operator network.
  • These client devices may for example be a fixed or mobile terminal, or a residential gateway (English) or located in a company, or a network operator gateway (“Voice Gateway” in English) such as a DSLAM-SIP (DSLAM) are the initials of the words “Digital Subscriber Line Access Multiplexer” meaning “Digital Subscriber Line Access Multiplexer", it is a device that collects DSL data traffic that passes through on a number of telephone lines).
  • DSLAM-SIP DSLAM-SIP
  • the SIP protocol has been defined by the IETF in RFC 3261. This protocol allows the establishment, modification and termination of multimedia sessions in a network using the protocol IP. The SIP protocol was then extended in particular in RFC 3265. This extension allows event notification procedures.
  • the SIP protocol is used in particular in infrastructure type IMS (initials of the words "IP Multimedia Subsystem” meaning “Multimedia subsystem over IP”).
  • the IMS has been defined by the 3rd Generation Partnership Project (3GPP) and TISPAN (Telecommunications and Internet Converged Services and Protocols for Advanced Networking). It is a network architecture introduced by 3GPP for mobile networks, then taken over by TISPAN for fixed networks. This architecture enables the dynamic establishment and control of multimedia sessions between two clients as well as the reservation of resources at the level of the network for transporting multimedia streams. Through this architecture, network operators can conveniently implement a management policy, provide a predetermined Quality of Service, and calculate the amounts to be billed to customers.
  • the IMS currently provides access to telephony, videophone, Presence and Instant Messaging services, which it also manages.
  • the client device of the user must, with some exceptions (in the case of certain emergency calls), register on the network.
  • the network is unable to link this record to a previous record (for example, due to a network failure, or following a termination of the terminal for a duration longer than a predetermined value)
  • the record is considered to be a initial registration.
  • the client device of the user must periodically send to the network a request to confirm that he wishes to maintain his registration.
  • the IMS networks comprise one or more servers, generally called “S-CSCF” (initials of the English words “Serving-Call Server Control Function” meaning “Control Function of the Service Call Server” "), Able (among other functions) to manage the registration procedure of devices connected to the network.
  • S-CSCF server-Call Server Control Function
  • Able able (among other functions) to manage the registration procedure of devices connected to the network.
  • these networks include one or more servers, generally referred to as "l-CSCF” (initials of the English words “Interrogating-Call Server Control Function” meaning “Query Call Server Control Function”) - incidentally often physically combined with S-CSCF servers to build servers denoted “l / S-CSCF” - which, at the time of registration of a client-device, query a server called “HSS” (initials of words English “Home Subscriber Server” meaning “Nominal Subscriber Server”), in order to be able to select an S-CSCF server with the characteristics that are obligatorily (and, if necessary, optionally) required to reach the level of service subscribed by the 'user.
  • HSS Home Subscriber Server
  • the HSS servers each contain a client database, and are therefore the equivalent in IP networks of the "HLR” servers (initials of the English words “Home Location Register” meaning “Nominal Location Register”) used in GSM networks. .
  • Each HSS server contains the "profile" of a number of client devices in the network, this profile including their registration status, authentication and location data, and subscribed services.
  • each user can, after an S-CSCF server has been so assigned, send a subscription request to certain services valid for the current connection.
  • SIP client device can subscribe to the state of a resource from a server using a SIP signaling message called SUBSCRIBE, and that server can then send notifications to this client device to the server. using a SIP signaling message called NOTIFY. For example, notifications are sent as soon as the status of the resource changes.
  • this terminal may be an event notification service: when the user of a terminal has a voice mailbox on the network, this terminal may subscribe to a message deposit notification; that is, it can request to be notified each time a message has been recorded on that mailbox; the user's terminal can likewise request to be notified of its own registration status, and so on.
  • Initial subscription requests are issued either automatically just after the start of an application, or following a user action on the terminal interface.
  • the client device After the initial subscription request, the client device must send periodically to the server a SIP request SUBSCRIBE to renew its subscription (we speak of "refreshment" of the subscription).
  • the server For each subscription (whether an initial subscription or a refresh), the server indicates to the client device the refresh period desired by the network operator for this subscription.
  • these mechanisms can be used to provide a Presence service for exchanging Presence information.
  • This Presence information may include the willingness and ability of a user to communicate with other users.
  • the client device of a user can provide, via a network connection to a Presence server, Presence information that is stored in a Presence data record, which can be made available. for distribution to other users (called "observers") who have previously requested this information.
  • Presence information has many applications in many communication services, and is one of the innovations behind the recent popularity of Instant Messaging and some Voice over IP services.
  • a user can publish a Presence status to indicate his current communication status. This published report informs other users wishing to contact the user of his availability and his agreement to communicate.
  • the most common use of the Presence service is the display on Instant Messaging client devices of an indicator icon, usually chosen from graphic symbols with easy-to-convey meanings, as well as a list of corresponding textual descriptions. for each state of Presence.
  • Presence services are a rapidly growing tool in the business world for more effective communication. Presence information allows someone to immediately see who's available in their corporate network, giving them more flexibility to set up meetings and conference calls on short notice.
  • Presence information is highly sensitive, and in complex systems the Presence service can set limits to respect for Presence information to be disclosed to different observers. For example, a worker may want his coworkers to see detailed Presence information about him only during office hours. Simple versions of this idea are already common in Instant Messaging clients, such as the "Blocking" feature, which allows users to appear as unavailable to selected observers.
  • 2.5G and even 3G mobile networks can offer access to Presence services and their management for mobile handsets.
  • the Presence requires collaboration between, on the one hand, a number of electronic devices (for example an Instant Messaging client device, a home phone, a mobile phone, and an electronic calendar), and on the other hand the servers Presence with which each of them is connected. Significant efforts have therefore been and are being made in several working groups to standardize Presence service protocols.
  • electronic devices for example an Instant Messaging client device, a home phone, a mobile phone, and an electronic calendar
  • SIMPLE Working Group initials of the "Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions” meaning “Extensions to the Session Initiation Protocol on Instant Messaging and Presence
  • the SIMPLE protocol specifies extensions to the SIP protocol that pertain to a publication and subscription mechanism for Presence and Instant Messaging information. for sending Instant Messages. These extensions include rich Presence document formats, privacy control, "partial" publications and notifications, past and future Presence, and so on.
  • These IETF standards were then used by other standardization bodies to specify Presence services as well as the architectures needed to render these services.
  • the OMA (initials of the English words “Open Mobile Alliance” meaning “Alliance Mobile Open”) defines an architecture using the SIMPLE protocol and intended to implement the Presence service. This standardized architecture allows an operator (or service provider) to offer a Presence service to its users, but also to interconnect with other operators (or service providers) offering the same service (provided that they use the same protocol).
  • the architecture proposed to ⁇ relies, for implementing the Presence service, on servers RLS (initials of the words “Resource List Server” meaning “Resource List Server”), on Presence servers, and on an IMS core network (including in particular the servers S-CSCF and l-CSCF). More precisely :
  • an RLS server is an entity that manages subscriptions to lists of correspondents, and is responsible for subscribing to the Presence information of each of the correspondents present in these lists; thus, a user merely subscribes once for the list of his correspondents with his RLS server; the RLS server then takes care of subscribing to the presence information of each member of the user's list of correspondents;
  • a Presence server is an entity that receives, stores and distributes Presence information of a user; this entity receives and manages subscription requests for the presence of the users it manages, and takes care of the notification of Presence information of its users.
  • the only identifiers known to the users of the service are their telephone numbers. These identifiers do not make it possible to determine the network SI P managing the correspondent associated with this telephone number.
  • the server RLS therefore sends to its heart network SI P requests (SUBSCRIBE) Presence for this correspondent.
  • the heart of network SI P has the particular function of routing these requests to the network hosting this correspondent.
  • the identities SI P can be of the form “SIP-URI” as defined in RFC 3261, or of the form “tel-URI” as defined in RFC 3966.
  • a SI P-URI is of the form “user @ host” (for example, alice @ domain1), where the "host” part identifies the network of the operator responsible for the identity represented by the "user” part.
  • Such a URI is of the form “tel: telephone_number” (for example, tel: +3361 23456789).
  • One way of routing an SI P request destined for such a URI is to use an ENUM base (defined in RFC 3761), in order to recover a SI P-URI associated with the telephone number contained in the tel-URI.
  • the interrogation of this base ENUM can be carried out by the core network SI P, and in particular, in the case of an IMS network, by the function S-CSCF. Finally, the knowledge of the SI P-URI makes it possible to obtain the address I P of an equipment of the network of the operator managing this correspondent.
  • this routing process is performed for each of the SUBSCRIBE requests generated by the RLS server each time the application of Presence of the client device is started.
  • a SIP network receives requests for initial registration and initial subscription, as well as registration refresh and subscription requests, as the users of the SIP network network connect, initialize and then renew their registration and their subscriptions at the end of the respective refreshment periods.
  • Each SIP network operator must of course plan the processing capacity of the nodes of his network so as to be able to cope with the corresponding request frequency, in particular according to the usual number of users of the network.
  • the architecture and the protocol mechanisms of the OMA pose serious problems of scalability on the equipments of the SIP backbone when an interconnection with one or more other operators is setup.
  • the traditional implementation of the Presence service implies, for all SIP network core equipment located on the Presence flow path, a significant workload, and which is constantly increasing as as the use of Presence services increases.
  • the present invention therefore relates to a method for processing Presence flows in an SI P network.
  • This method is remarkable in that, when a user A belonging to a first SIP network has requested to be notified of changes in the state of Presence of an external correspondent B to said first SIP network and identified by such a URI containing its telephone number, said method comprises the following steps:
  • the present invention applies to Presence service implementations in which the correspondents are known only by their telephone number.
  • these Presence services rely on the heart of the SIP network to exploit its routing function. They concluded that it was sufficient to remedy (at least partially) this single problem of routing by the backbone, to relieve it in the implementation of Presence services, which are among the most consumer-intensive services. resources for the core network. It is clear, however, that the solution according to the invention alone makes it possible to subscribe effectively to the presence state of a correspondent only if the presumed SIP-URI of this correspondent is correct.
  • the authors of the present invention have realized that, for a given correspondent, the SIP-URI associated with his telephone number is information which, admittedly, may occasionally change when the correspondent changes operator (portability) or SIP network by keeping the same operator (for example in case of evolution or reorganization of the network of the operator), but without these changes are, all things considered, very common.
  • the invention advantageously makes it possible to reduce the number of treatments, as well as the number of invocations of the functions necessary for allow the core of the first network to route Presence requests to the SIP network and the Presence server managing the correspondent concerned.
  • the workload of the core equipment of the SIP networks is thus considerably reduced.
  • said alias has been obtained beforehand by means of the following steps:
  • said RLS server in case, in response to said subscription request, receives a notification from said second SIP network that said SIP-URI is unknown, the storage in said database of this SIP-URI as an alias of said tel-URI of the corresponding B is deleted.
  • the invention relates to a device for processing Presence flows in a SIP network.
  • Said device is remarkable in that, when a user A belonging to a first SIP network has requested to be notified of changes in the presence status of a correspondent B external to said first SIP network and identified by such a URI containing its telephone number, said device comprises means for:
  • EPIRBs of the first SIP network or associated with said RLS server a presumed SIP-URI of said correspondent B stored as an alias of said tel- URI, and
  • said device comprises means for:
  • said device comprises means for deleting in said base storage of this SIP-URI as an alias of said tel-URI of the correspondent B.
  • the invention relates to an RLS server comprising a device as briefly described above.
  • the invention also relates to a computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • This computer program is notable in that it includes instructions for performing the steps of the Presence flow processing method succinctly set forth above, when executed on a computer.
  • FIG. 1 already described, schematically represents the topography of Presence flows in a telecommunications system comprising SIP networks,
  • FIG. 2 schematically represents the structure of an IMS network
  • FIG. 3 represents, according to an embodiment of the invention, a procedure for discovering a SIP-URI and storing this SIP-URI as an alias for such a URI,
  • FIG. 4 represents, according to one embodiment of the invention, the use of a SIP-URI aka of such a URI, and
  • FIG. 5 represents, according to an embodiment of the invention, the deletion of a SIP-URI aka of such a URI.
  • the multimedia services offered by this IMS network 1 may include telephony services, video telephony, content-sharing ("content-sharing" in English), presence, instant messaging, or television. These services are available to the user A of a UE client device belonging to the network 1, which enables the client device 10 to exchange multimedia streams and session control in accordance with the SIP protocol, in particular with the UE client device 1 1 (not shown) of a user B belonging to a SIP network 2 (not shown) connected to the network 1.
  • Each of the client devices 10 and 11 may be a fixed or mobile terminal, or a home or enterprise gateway, having SIP signaling means and may include means for rendering audiovisual content.
  • this IMS network 1 comprises:
  • IP transport infrastructure (not shown);
  • an L / S-CSCF call server 22 manages in particular the procedure for registering the devices connected to the network 20; the l / S-CSCF server 22 also manages the routing of the signaling between the client device 10 and the VM 25 voicemail servers, Presence PS 26, Resource List RLS 27, and telephony TAS 29, as well as routing to other terminals managed by the same IMS network and the routing of the signaling between this IMS network 1 and other networks (not shown);
  • P-CSCF one (or more) server (s) P-CSCF (initials of the words “Proxy-Call Server Control Function” meaning "Control Function of the Proxy Call Server”);
  • the P-CSCF server 21 is the SIP contact point of the client device 10 in the IMS network; thus, all the SIP signaling exchanged between the client device 10 and the l / S-CSCF call server 22 passes through this P-CSCF server 21;
  • an HSS server 24 contains the profile of the user A of the client device 10 in terms of authentication data, location and subscribed services;
  • a server type SLF for "Subscriber Location Function" 23; an SLF server is used in IP networks comprising several HSS servers; more specifically, this SLF server 23 is queried by the functions l-CSCF and S-CSCF to find the address of the HSS server 24 hosting the data concerning the user A of the client device 10;
  • VM 25 voicemail ("message-summary" in English);
  • a VM server 25 manages the subscribing the client device 10 to the message deposit / viewing events for the user A, and notifying the client device 10 at the occurrence of these events;
  • PS 26 Presence server • one (or more) PS 26 Presence server (s); a PS server 26 receives, stores and distributes the Presence information of the user A of the client device 10;
  • RLS 27 • one or more server (s) of Resource Lists RLS 27; an RLS server 27 (moreover often often physically combined with a Presence server) manages the subscriptions to lists of correspondents of the user A, and is responsible for subscribing to the presence information of each of the correspondents present in these lists; and
  • TAS 29 telephony server manages the telephone services to which the user of the terminal 10 has subscribed with his operator, such as the presentation of the number or call forwarding.
  • the voicemail servers VM 25, Presence PS 26, Resource Lists RLS 27 and telephony TAS 29 are examples of so-called AS (initials of the English words “Application Servers” meaning “Servers”). Applications ").
  • the initial subscription procedure of the terminal 10 with the network 1 is normally executed when the terminal (or an application installed on this terminal) is started by the user just after the initial registration procedure.
  • An initial subscription procedure is executed for each type of event subscribed (for example, the initial subscription to the message deposit / consultation events is carried out independently of the initial subscription to the event events. Presence).
  • a subscription has a limited duration in time. This duration may be different for each type of event subscribed, and it is also independent of the recording lease duration. Under normal operating conditions, the client device 10 must renew its subscription (s) automatically and periodically.
  • event subscription procedures use a request called "SUBSCRIBE".
  • the procedure can then be reiterated: discovery, storage, use, and so on.
  • FIG. 3 illustrates, according to an embodiment of the invention, a procedure for discovering a SIP-URI and storing this SIP-URI as an alias for such a URI.
  • the RLS server 27 of a user A belonging to the IMS network 1 wishes to be notified, on behalf of the latter, changes in the presence status of an external correspondent B belonging to a subscriber.
  • the RLS server initially only knows the tel-URI of this external correspondent (for example tel: +33123456789).
  • the RLS server 27 sends its Presence request (SUBSCRIBE) to its IMS network 1, which is then responsible for routing it to the SIP network 2 of the correspondent B. This request will then be transmitted to the presence server. corresponding B.
  • the response 200 OK indicating the acceptance of the subscription and received from the SIP network 2 then makes it possible to recover a SIP-URI (for example, sip: bob @ domain2) from the external correspondent B; indeed, the SIP header called "P-Asserted-ldentity" contained in this response to the SUBSCRIBE request makes it possible to convey a SIP-URI identifying the recipient B of the initial request.
  • a SIP-URI for example, sip: bob @ domain2
  • this SIP-URI is then stored, in the RLS server 27 of the user A or in an associated database, as an alias of the tel-URI of the external correspondent B.
  • User A's RLS server 27 could, for example, rely on a routing based on telephone number ranges, similar to the routing performed in public switched telephone network (PSTN) networks, but implemented here by the core of the IMS network 1.
  • the RLS server 27 could also recover a SIP-URI by directly interrogating the ENUM server (which supposes the setting up of a non-standard interface).
  • the RLS server 27 could also retrieve a SIP-URI used as GRUU (initials of the Globally Routable User Agent URI words meaning "Globally Routable User Agent URI"), as defined in RFC 5627, which would be inserted by the presence server of the external correspondent B in the response 200 OK to the request SUBSCRIBE.
  • GRUU initials of the Globally Routable User Agent URI words meaning "Globally Routable User Agent URI”
  • the second phase of the present embodiment of the invention is to use the SIP-URI previously stored as an alias of the tel-URI B.
  • the SIP-URI identifies the SIP network hosting the external correspondent B (here the network 2), and allows the RLS server 27 to route its request to this network 2, either directly using the function l-CSCF of the network 2, or indirectly by sending the request to an interconnection function of the IBCF type (initials of the English words "Interconnection Border Control Function” meaning "Interconnection Border Control Function”). This request will then be transmitted to the presence server of the correspondent B.
  • the RLS server 27 of the user A does not need to send its request to the S-CSCF server 22 of its own IMS network 1, which avoids having to invoke the routing functions of the core network. IMS.
  • the SIP-URI of the correspondent B stored as an alias is temporary insofar as it functions only as long as the correspondent does not change SIP-URI. If the correspondent changes operator, or SIP network dependent on the same operator, the RLS server receives an appropriate SIP error message (for example a SIP error message "404 Not Found") indicating that the resource does not. could not be found.
  • an appropriate SIP error message for example a SIP error message "404 Not Found"
  • FIG. 5 illustrates this case according to one embodiment of the invention.
  • the SIP-URI sip: bob @ domain2 stored as alias of the tel- URI of B then no longer allows to reach the correspondent B since it is no longer in the SIP network 2, but in a SIP network 3.
  • the RLS server thus deletes this SIP-URI, then it uses again the tel-URI of the correspondent B to discover the new SIP-URI sip: bobby @ domain3 to which the correspondent B can now be joined.
  • This mechanism makes it possible to cover situations where a correspondent B would change operator or service provider, while keeping his telephone number.
  • the invention can be implemented within the nodes, for example RLS servers, SIP networks, by means of software and / or hardware components.
  • the present invention also relates to a computer system.
  • This computer system conventionally comprises a central processing unit controlling signals by a memory, as well as an input unit and an output unit.
  • this computer system may be used to execute a computer program having instructions for implementing any of the Presence flow processing methods of the invention.
  • the invention also relates to a downloadable computer program from a communication network comprising instructions for executing the steps of a Presence flow processing method according to the invention, when it is executed on a network.
  • This computer program may be stored on a computer readable medium and may be executable by a microprocessor.
  • 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 another desirable form.
  • 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 means, for example a floppy disk. ) or a hard disk.
  • 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 computer program according to the invention can in particular be downloaded to an Internet type network.
  • the information carrier may be an integrated circuit in which the program is embedded, the circuit being adapted to execute or to be used in the execution of any of the Presence flow processing methods according to the present invention. invention.

Landscapes

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

Abstract

Lorsqu'un utilisateur A appartenant un premier réseau SIP (1) a demandé à être notifié des changements de l'état de Présence d'un correspondant B externe audit premier réseau SIP (1) et identifié par une tel-URI contenant son numéro de téléphone, le procédé selon l'invention comprend les tapes suivantes : identification, dans une base de donnes contenue dans un serveur RLS (27) du premier réseau SIP (1) ou associe audit serveur RLS (27), dune SIP-URI présume dudit correspondant B stocke en tant qu'alias de ladite tel-URI; et envoi un deuxième réseau SIP (2) contenant ladite SIP-URI présume dune requête de souscription l'état de Présence du correspondant B. Ledit alias a t obtenu préalablement au moyen des tapes suivantes : découverte de la SIP-URI du correspondant B au moyen de ladite tel-URI du correspondant B; et stockage dans ladite base de donnes de cette SIP-URI en tant qu'alias de la tel-URI du correspondant B. Application aux réseaux IMS.

Description

PROCEDE DE TRAITEMENT DES FLUX DE PRESENCE
DANS UN RESEAU SIP
La présente invention concerne les réseaux de télécommunications de type IP (« Internet Protocol »), et notamment ceux parmi les réseaux IP qui sont aptes à mettre en œuvre des protocoles de contrôle de session évolués. Les réseaux IP permettent la diffusion de données conversationnelles, dans le cadre de services tels que « Voix sur IP » (VoIP), « Partage de Contenu », ou « Messagerie Instantanée ».
Plus particulièrement, la présente invention concerne les moyens mis en place dans un réseau IP utilisant le protocole de contrôle de session SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'Initiation de Session »), désigné ci-après par « réseau SIP », pour assurer un service dit de « Présence ».
On dira qu'un dispositif-client (« User Equipment » en anglais) « appartient » au réseau d'un opérateur donné lorsque l'utilisateur de ce dispositif-client possède un compte auprès de cet opérateur, et ce, quel que soit le réseau d'accès utilisé par le dispositif-client pour se connecter au réseau de l'opérateur. Ces dispositifs-clients peuvent par exemple être un terminal fixe ou mobile, ou une passerelle domestique (« Residential Gateway » en anglais) ou située dans une entreprise, ou encore une passerelle d'opérateur réseau (« Voice Gateway » en anglais) telle qu'un DSLAM-SIP (DSLAM sont les initiales des mots anglais « Digital Subscriber Line Access Multiplexer » signifiant « Multiplexeur d'Accès de Lignes d'Abonnés Numériques » ; il s'agit d'un dispositif collectant le trafic de données DSL qui transite sur un certain nombre de lignes téléphoniques).
Le protocole SIP a été défini par l'IETF dans le document RFC 3261 . Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Le protocole SIP a ensuite été étendu notamment dans le document RFC 3265. Cette extension permet des procédures de notification d'événements.
Le protocole SIP est utilisé en particulier dans les infrastructures de type IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous-système Multimédia sur IP »). L'IMS a été défini par les organismes de normalisation 3GPP (« 3rd Génération Partnership Project ») et TISPAN (« Télécommunications and Internet Converged Services and Protocols for Advanced Networking »). C'est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN pour les réseaux fixes. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en œuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction.
Lorsqu'un utilisateur souhaite bénéficier des services offerts par un réseau IMS, il émet vers le réseau des messages de signalisation pouvant inclure notamment divers types de requêtes.
Tout d'abord, le dispositif-client de l'utilisateur doit, sauf exceptions (cas de certains appels d'urgence), s'enregistrer sur le réseau. Lorsque le réseau est incapable de faire le lien entre cet enregistrement et un enregistrement précédent (par exemple suite à une panne réseau, ou suite à un arrêt du terminal pendant une durée supérieure à une valeur prédéterminée), l'enregistrement est considéré comme étant un enregistrement initial. Après un enregistrement initial, le dispositif-client de l'utilisateur doit envoyer périodiquement au réseau une requête pour confirmer qu'il souhaite maintenir son enregistrement.
Pour pouvoir donc enregistrer les dispositifs-clients, les réseaux IMS comprennent un ou plusieurs serveurs, généralement appelés « S- CSCF » (initiales des mots anglais « Serving-Call Server Control Function » signifiant « Fonction de Contrôle du Serveur d'Appels de Service »), aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau.
En outre, ces réseaux comprennent un ou plusieurs serveurs, généralement appelés « l-CSCF » (initiales des mots anglais « Interrogating-Call Server Control Function » signifiant « Fonction de Contrôle du Serveur d'Appels d'Interrogation ») - d'ailleurs souvent combinés physiquement avec les serveurs de type S-CSCF pour constituer des serveurs dénotés « l/S-CSCF » - qui, au moment de l'enregistrement d'un dispositif-client, interrogent un serveur appelé « HSS » (initiales des mots anglais « Home Subscriber Server » signifiant « Serveur d'Abonné Nominal »), afin de pouvoir sélectionner un serveur S-CSCF possédant les caractéristiques qui sont obligatoirement (et, le cas échéant, optionnellement) requises pour atteindre le niveau de service souscrit par l'utilisateur. Les serveurs HSS contiennent chacun une base de données-clients, et sont donc l'équivalent dans les réseaux IP des serveurs « HLR » (initiales des mots anglais « Home Location Register » signifiant « Registre de Localisation Nominal ») utilisés dans les réseaux GSM. Chaque serveur HSS contient le « profil » d'un certain nombre de dispositifs-clients du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits.
En effet, chaque utilisateur peut, après qu'un serveur S-CSCF lui ait été ainsi attribué, envoyer une requête de souscription à certains services valable pour la connexion en cours. Le principe général est qu'un dispositif-client SIP peut souscrire à l'état d'une ressource auprès d'un serveur à l'aide d'un message de signalisation SIP appelé SUBSCRIBE, et que ce serveur peut ensuite envoyer des notifications à ce dispositif- client à l'aide d'un message de signalisation SIP appelé NOTIFY. Des notifications sont par exemple envoyées dès lors que l'état de la ressource change. Il peut s'agir par exemple d'un service de notification d'événement : lorsque l'utilisateur d'un terminal dispose d'une boîte vocale sur le réseau, ce terminal peut souscrire à une notification de dépôt de message, c'est-à-dire qu'il peut demander à être informé chaque fois qu'un message a été enregistré sur cette boîte vocale ; le terminal de l'utilisateur peut, de même, demander à être notifié de son propre état d'enregistrement, et ainsi de suite.
Les requêtes de souscription initiales sont émises soit de manière automatique juste après le démarrage d'une application, soit suite à une action de l'utilisateur sur l'interface du terminal. Après la requête de souscription initiale, le dispositif-client doit envoyer périodiquement au serveur une requête SIP SUBSCRIBE pour renouveler sa souscription (on parle de « rafraîchissement » de la souscription). Pour chaque souscription (qu'il s'agisse d'une souscription initiale ou d'un rafraîchissement), le serveur indique au dispositif-client la période de rafraîchissement souhaitée par l'opérateur du réseau pour cette souscription.
En particulier, ces mécanismes peuvent être utilisés pour fournir un service de Présence permettant d'échanger des informations de Présence. Ces informations de Présence peuvent être notamment la volonté et la capacité d'un utilisateur à communiquer avec d'autres utilisateurs. Le dispositif-client d'un utilisateur peut par exemple fournir, via une connexion réseau à un serveur de Présence, des informations de Présence qui sont enregistrées dans ce qui constitue un enregistrement de données de Présence, lesquelles peuvent être rendues disponibles pour distribution à d'autres utilisateurs (appelés des « observateurs ») ayant préalablement demandé à recevoir ces informations. Les informations de Présence ont de nombreuses applications dans beaucoup de services de communication, et sont une des innovations à la base de la popularité récente de la Messagerie Instantanée et de certains services de Voix sur IP.
Un utilisateur peut ainsi publier un état de Présence pour indiquer son statut de communication actuel. Cet état publié informe d'autres utilisateurs souhaitant entrer en contact avec l'utilisateur de sa disponibilité et de son accord pour communiquer. L'utilisation la plus commune du service de Présence est l'affichage sur les dispositifs-clients de Messagerie Instantanée d'une icône indicatrice, habituellement choisie parmi des symboles graphiques ayant des significations faciles à transmettre, ainsi qu'une liste de descriptions textuelles correspondantes pour chacun des états de Présence.
Parmi les états classiques concernant la disponibilité d'un utilisateur, on trouve : « libre pour bavarder », « occupé », « sorti », « ne pas déranger », et « parti déjeuner ». De tels états existent dans beaucoup de variations dans les dispositifs-clients de Messagerie Instantanée modernes. Les normes actuelles proposent un choix abondant d'attributs de Présence supplémentaires, comme l'humeur de l'utilisateur ou sa localisation.
Les services de Présence sont un outil en rapide croissance dans le monde des affaires, pour une communication plus efficace. Les informations de Présence permettent à quelqu'un de voir immédiatement qui est disponible dans son réseau d'entreprise, ce qui donne plus de flexibilité pour mettre en place à court délai des réunions et des conférences téléphoniques.
Les informations de Présence sont hautement sensibles, et dans les systèmes complexes le service de Présence peut définir des limites à respecter pour que les informations de Présence puissent être divulguées aux différents observateurs. Par exemple, un travailleur peut souhaiter que ses collègues ne voient des informations de Présence détaillées le concernant que pendant les heures de bureau. Des versions simples de cette idée sont déjà courantes dans les clients de Messagerie Instantanée, par exemple la fonction de « Blocage » , qui permet aux utilisateurs d'apparaître comme indisponibles à certains observateurs choisis.
Les réseaux de téléphonie mobile 2.5G et a fortiori 3G peuvent offrir l'accès aux services de Présence et leur gestion pour les combinés téléphoniques des utilisateurs mobiles.
La Présence exige une collaboration entre, d'une part, un certain nombre de dispositifs électroniques (par exemple un dispositif-client de Messagerie Instantanée, un téléphone domestique, un téléphone mobile, et un calendrier électronique), et d'autre part les serveurs de Présence avec lesquels chacun d'entre eux est connecté. Des efforts importants ont donc été fournis, et le sont encore, dans plusieurs groupes de travail pour normaliser les protocoles concernant le service de Présence.
En 2001 , le groupe de travail SIMPLE (initiales des mots anglais « Session Initiation Protocol for Instant Messaging and Présence Leveraging Extensions » signifiant « Extensions au Protocole d'Initiation de Session portant sur la Messagerie Instantanée et la Présence ») a été formé au sein de l'I ETF pour mettre au point des normes pour les applications de Présence et de Messagerie Instantanée utilisant le protocole SI P. Le protocole SIMPLE spécifie des extensions au protocole SIP qui concernent un mécanisme de publication et de souscription pour les informations de Présence et pour l'envoi de Messages Instantanés. Ces extensions incluent de riches formats de document de Présence, le contrôle de la vie privée, des publications « partielles » et des notifications, la Présence passée et future, et ainsi de suite. Ces normes IETF ont ensuite été utilisées par d'autres organismes de normalisation pour spécifier des services de Présence ainsi que les architectures nécessaires pour rendre ces services. L'OMA (initiales des mots anglais « Open Mobile Alliance » signifiant « Alliance Mobile Ouverte ») définit ainsi une architecture utilisant le protocole SIMPLE et destinée à mettre en œuvre le service de Présence. Cette architecture normalisée permet à un opérateur (ou fournisseur de service) d'offrir un service de Présence à ses utilisateurs, mais aussi de s'interconnecter avec d'autre opérateurs (ou fournisseurs de service) offrant ce même service (à condition qu'ils utilisent le même protocole).
L'architecture proposée à ΓΟΜΑ s'appuie, pour mettre en œuvre le service de Présence, sur des serveurs RLS (initiales des mots anglais « Resource List Server» signifiant « Serveur de Listes de Ressources»), sur des serveurs de Présence, et sur un cœur de réseau IMS (comprenant notamment les serveurs S-CSCF et l-CSCF). Plus précisément :
• un serveur RLS est une entité qui gère les souscriptions à des listes de correspondants, et est chargé de souscrire aux informations de Présence de chacun des correspondants présents dans ces listes ; ainsi, un utilisateur se contente de souscrire une seule fois pour la liste de ses correspondants auprès de son serveur RLS ; le serveur RLS se charge ensuite de souscrire aux informations de Présence de chaque membre de la liste de correspondants de l'utilisateur ;
· un serveur de Présence est une entité qui reçoit, stocke et distribue les informations de Présence d'un utilisateur ; cette entité reçoit et gère les demandes de souscription à la présence des utilisateurs qu'il gère, et se charge de la notification des informations de Présence de ses utilisateurs. Dans la mise en œuvre de certains services de Présence, les seuls identifiants connus des utilisateurs du service sont leurs numéros de téléphone. Ces identifiants ne permettent pas de déterminer le réseau SI P gérant le correspondant associé à ce numéro de téléphone. Le serveur RLS envoie donc à son cœur de réseau SI P les requêtes (SUBSCRIBE) de Présence destinées à ce correspondant. Le cœur de réseau SI P a notamment pour fonction de router ces requêtes vers le réseau hébergeant ce correspondant.
On rappelle à cet égard que les identités SI P peuvent être de la forme « SIP-URI » telle que définie dans la RFC 3261 , ou de la forme « tel-URI » telle que définie dans la RFC 3966. Une SI P-URI est de la forme « user@host » (par exemple, alice@domaine1 ), où la partie « host » identifie le réseau de l'opérateur responsable de l'identité représentée par la partie « user » . Une tel-URI est de la forme « tel :numéro_de_téléphone » (par exemple, tel :+3361 23456789). Une façon de router une requête SI P destinée à une tel-URI est d'utiliser une base ENUM (définie dans la RFC 3761 ), afin de récupérer une SI P-URI associée au numéro de téléphone contenu dans la tel-URI. L'interrogation de cette base ENUM peut être réalisée par le cœur de réseau SI P, et notamment, dans le cas d'un réseau IMS, par la fonction S-CSCF. Enfin, la connaissance de la SI P-URI permet d'obtenir l'adresse I P d'un équipement du réseau de l'opérateur gérant ce correspondant.
Selon l'état de l'art, ce processus de routage est effectué pour chacune des requêtes SUBSCRIBE engendrées par le serveur RLS à chaque démarrage de l'application de Présence du dispositif-client.
Dans ce contexte, pendant le fonctionnement normal d'un réseau SIP, ce dernier reçoit des requêtes d'enregistrement initial et de souscription initiale, ainsi que des requêtes de rafraîchissement d'enregistrement et de souscription, au fur et à mesure que les usagers du réseau se connectent, initialisent puis renouvellent leur enregistrement et leurs souscriptions au bout des périodes de rafraîchissement respectives prévues. Chaque opérateur de réseau SIP doit évidemment prévoir la capacité de traitement des nœuds de son réseau de manière à pouvoir faire face à la fréquence de requêtes correspondante, notamment en fonction du nombre habituel d'usagers du réseau.
Or prédire la capacité requise est un problème difficile. En effet, les normes de la 3GPP relatives aux architectures SIP prévoient simplement que le routage d'appels est assuré par le cœur de réseau, sans jamais prendre en compte les effets de synergie de ce routage avec tel ou tel service IP, dont la définition est fournie indépendamment par une norme spécifique.
En ce qui concerne en particulier le service de Présence, l'architecture et les mécanismes protocolaires de l'OMA posent de sérieux problèmes de montée en charge sur les équipements du cœur de réseau SIP dès lors qu'une interconnexion avec un ou plusieurs autres opérateurs est mise en place. En effet, la mise en œuvre classique du service de Présence implique, pour l'ensemble des équipements du cœur de réseau SIP situés sur le chemin des flux de Présence, une charge de travail importante, et qui plus est en constant accroissement au fur et à mesure de l'utilisation de plus en plus répandue des services de Présence.
Cette question de la montée en charge est par exemple décrite dans le « draft » IETF http://tools.ietf.org/html/draft-ietf-simple- interdomain-scalinq-analysis-08. Elle est notamment liée au fait que, pour un utilisateur d'un réseau SIP donné, tout souhait de récupérer les informations de Présence d'un correspondant appartenant à un autre réseau SIP engendre un dialogue SIP de type SUBSCRIBE/NOTIFY à l'interconnexion entre les réseaux respectifs des deux utilisateurs. Ce dialogue est établi tant que l'utilisateur souhaite être notifié des changements de l'état de Présence de ce correspondant externe ; de plus, comme illustré sur la figure 1 , si la liste de correspondants d'un utilisateur appartenant à un réseau d'opérateur 1 donné contient plusieurs correspondants appartenant à des réseaux tiers (réseaux d'opérateurs 2 et 3 sur la figure), il y aura plusieurs dialogues de ce type établis simultanément lors de l'interconnexion.
La présente invention concerne donc un procédé de traitement des flux de Présence dans un réseau SI P. Ce procédé est remarquable en ce que, lorsqu'un utilisateur A appartenant à un premier réseau SIP a demandé à être notifié des changements de l'état de Présence d'un correspondant B externe audit premier réseau SIP et identifié par une tel- URI contenant son numéro de téléphone, ledit procédé comprend les étapes suivantes :
- identification, dans une base de données contenue dans un serveur RLS du premier réseau SIP ou associée audit serveur RLS, d'une SIP-URI présumée dudit correspondant B stockée en tant qu'alias de ladite tel-URI, et
- envoi à un deuxième réseau SIP contenant ladite SIP-URI présumée d'une requête de souscription à l'état de Présence du correspondant B.
Ainsi, la présente invention s'applique aux mises en œuvre du service de Présence dans lesquelles les correspondants ne sont connus que par leur numéro de téléphone. En effet, les auteurs de la présente invention se sont rendu compte que, selon l'état de l'art, ces services de Présence ne font appel au cœur de réseau SIP que pour exploiter sa fonction de routage. Ils en ont conclu qu'il suffisait de remédier (au moins partiellement) à cet unique problème du routage par le cœur de réseau, pour pouvoir le soulager dans la mise en œuvre des services de Présence, lesquels figurent parmi les services les plus consommateurs de ressources pour le cœur de réseau. Il est clair toutefois que la solution selon l'invention ne permet, à elle seule, de souscrire effectivement à l'état de Présence d'un correspondant que si la SIP-URI présumée de ce correspondant est correcte. En effet, les auteurs de la présente invention ont réalisé que, pour un correspondant donné, la SIP-URI associée à son numéro de téléphone est une information qui, certes, peut changer occasionnellement lorsque ce correspondant change d'opérateur (portabilité) ou de réseau SIP en gardant le même opérateur (par exemple en cas d'évolution ou de réorganisation du réseau de l'opérateur), mais sans que ces changements ne soient, tout bien considéré, très fréquents.
Les inventeurs ayant trouvé moyen, comme expliqué en détail ci- dessous, de gérer les situations de changement de SIP-URI, l'invention permet, avantageusement, de réduire le nombre de traitements, ainsi que le nombre d'invocations des fonctions nécessaires pour permettre au cœur du premier réseau de router les requêtes de Présence vers le réseau SIP et le serveur de Présence gérant le correspondant considéré. La charge de travail des équipements de cœur des réseaux SIP est donc ainsi considérablement réduite.
Selon des caractéristiques particulières, ledit alias a été obtenu préalablement au moyen des étapes suivantes :
- découverte de la SIP-URI du correspondant B au moyen de ladite tel-URI du correspondant B, et
- stockage dans ladite base de données de cette SIP-URI en tant qu'alias de la tel-URI du correspondant B.
Grâce à ces dispositions, on peut obtenir l'alias requis pour la mise en œuvre de l'invention, au moyen d'une procédure de découverte quelconque, classique ou non. On notera à cet égard que, s'il est classique d'utiliser des bases de données statiques alimentées par les fournisseurs de services et permettant de stocker la SIP-URI associée à un numéro de téléphone, il est en revanche contraire aux habitudes des spécialistes des réseaux SIP de créer une telle base de données sur la base d'informations découvertes dynamiquement lors d'échanges SIP, comme c'est le cas ici.
Selon d'autres caractéristiques particulières, au cas où, en réponse à ladite requête de souscription, ledit serveur RLS reçoit une notification de la part dudit deuxième réseau SIP selon laquelle ladite SIP-URI est inconnue, le stockage dans ladite base de données de cette SIP-URI en tant qu'alias de ladite tel-URI du correspondant B est supprimé.
Grâce à ces dispositions, couplées à la réitération des étapes, décrites succinctement ci-dessus, de découverte et stockage de la SIP- URI du correspondant B, on peut avantageusement gérer les situations de changement de SIP-URI, comme annoncé ci-dessus.
Corrélativement, l'invention concerne un dispositif de traitement des flux de Présence dans un réseau SIP. Ledit dispositif est remarquable en ce que, lorsqu'un utilisateur A appartenant à un premier réseau SIP a demandé à être notifié des changements de l'état de Présence d'un correspondant B externe audit premier réseau SIP et identifié par une tel- URI contenant son numéro de téléphone, ledit dispositif comprend des moyens pour :
- identifier, dans une base de données contenue dans un serveur
RLS du premier réseau SIP ou associée audit serveur RLS, une SIP-URI présumée dudit correspondant B stockée en tant qu'alias de ladite tel- URI, et
- envoyer à un deuxième réseau SIP contenant ladite SIP-URI présumée une requête de souscription à l'état de Présence du correspondant B.
Selon des caractéristiques particulières, pour obtenir ledit alias, ledit dispositif comprend des moyens pour :
- découvrir la SIP-URI du correspondant B au moyen de ladite tel- URI du correspondant B, et - stocker dans ladite base de données cette SIP-URI en tant qu'alias de la tel-URI du correspondant B.
Selon d'autres caractéristiques particulières, au cas où, en réponse à ladite requête de souscription, ledit serveur RLS reçoit une notification de la part dudit réseau SIP selon laquelle ladite SIP-URI est inconnue, ledit dispositif comprend des moyens pour supprimer dans ladite base de données le stockage de cette SIP-URI en tant qu'alias de ladite tel-URI du correspondant B.
Selon un autre aspect, l'invention concerne un serveur RLS comprenant un dispositif tel qu'exposé succinctement ci-dessus.
Les avantages offerts par ces dispositifs et ce serveur RLS sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus.
On notera qu'il est possible de réaliser ces dispositifs dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques.
L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes du procédé de traitement des flux de Présence succinctement exposé ci-dessus, lorsqu'il est exécuté sur un ordinateur.
Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par ledit procédé.
D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles : - la figure 1 , déjà décrite, représente schématiquement la topographie des flux de Présence dans un système de télécommunications comprenant des réseaux SIP,
- la figure 2 représente schématiquement la structure d'un réseau IMS,
- la figure 3 représente, selon un mode de réalisation de l'invention, une procédure de découverte d'une SIP-URI et de stockage de cette SIP- URI comme alias d'une tel-URI,
- la figure 4 représente, selon un mode de réalisation de l'invention, l'utilisation d'une SIP-URI alias d'une tel-URI, et
- la figure 5 représente, selon un mode de réalisation de l'invention, la suppression d'une SIP-URI alias d'une tel-URI.
Bien que la présente invention concerne les réseaux SIP en général, on va considérer à présent, à titre d'exemple de réalisation, une architecture de réseau de type IMS, telle que présentée succinctement ci- dessus. Cette architecture est illustrée sur la figure 2.
Les services multimédia offerts par ce réseau IMS 1 peuvent comprendre des services de téléphonie, de vidéo-téléphonie, de partage de contenu (« content-sharing » en anglais), de Présence, de Messagerie Instantanée, ou de télévision. Ces services sont à la disposition de l'utilisateur A d'un dispositif-client UE (pour « User Equipment » en anglais) 10 appartenant au réseau 1 , qui permet au dispositif-client 10 d'échanger des flux multimédias et des signaux de contrôle de session conformes au protocole SIP, notamment avec le dispositif-client UE 1 1 (non représenté) d'un utilisateur B appartenant à un réseau SIP 2 (non représenté) relié au réseau 1 .
Chacun des dispositifs-clients 10 et 1 1 peuvent être un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise, disposant de moyens de signalisation SIP et pouvant comprendre des moyens de restitution d'un contenu audiovisuel. Comme le montre la figure 2, ce réseau IMS 1 comprend :
une infrastructure de transport IP (non représentée) ;
un ou plusieurs serveurs d'appel l/S-CSCF ; un serveur d'appel l/S- CSCF 22 gère notamment la procédure d'enregistrement des dispositifs connectés au réseau 20 ; le serveur l/S-CSCF 22 gère également le routage de la signalisation entre le dispositif-client 10 et les serveurs de messagerie vocale VM 25, de Présence PS 26, de Listes de Ressources RLS 27, et de téléphonie TAS 29, ainsi que le routage en direction d'autres terminaux gérés par le même réseau IMS et le routage de la signalisation entre ce réseau IMS 1 et d'autres réseaux (non représentés) ;
un (ou plusieurs) serveur(s) P-CSCF (initiales des mots anglais « Proxy-Call Server Control Function » signifiant « Fonction de Contrôle du Serveur d'Appels Mandataire ») ; le serveur P-CSCF 21 est le point de contact SIP du dispositif-client 10 dans le réseau IMS ; ainsi, toute la signalisation SIP échangée entre le dispositif- client 10 et le serveur d'appel l/S-CSCF 22 passe par ce serveur P- CSCF 21 ;
un ou plusieurs serveurs de base de données, de type HSS ; un serveur HSS 24 contient le profil de l'utilisateur A du dispositif-client 10 en termes de données d'authentification, de localisation et de services souscrits ;
optionnellement, un serveur de type SLF (pour « Subscriber Location Function ») 23 ; on utilise un serveur SLF dans les réseaux IP comprenant plusieurs serveurs HSS ; plus précisément, ce serveur SLF 23 est interrogé par les fonctions l-CSCF et S-CSCF pour trouver l'adresse du serveur HSS 24 hébergeant les données concernant l'utilisateur A du dispositif-client 10 ;
un (ou plusieurs) serveur(s) VM 25 de messagerie vocale (« message-summary » en anglais) ; un serveur VM 25 gère la souscription du dispositif-client 10 aux événements de dépôt/consultation des messages à l'intention de l'utilisateur A, et notifie le dispositif-client 10 lors de l'occurrence de ces événements ;
• un (ou plusieurs) serveur(s) de Présence PS 26 ; un serveur PS 26 reçoit, stocke et distribue les informations de Présence de l'utilisateur A du dispositif-client 10 ;
• un (ou plusieurs) serveur(s) de Listes de Ressources RLS 27 ; un serveur RLS 27 (d'ailleurs souvent combiné physiquement avec un serveur de Présence) gère les souscriptions à des listes de correspondants de l'utilisateur A, et est chargé de souscrire aux informations de Présence de chacun des correspondants présents dans ces listes ; et
• un (ou plusieurs) serveur(s) de téléphonie TAS 29 ; un serveur TAS gère les services téléphoniques auxquels l'utilisateur du terminal 10 a souscrits auprès de son opérateur, tels que la présentation du numéro ou le renvoi d'appel.
Les serveurs de messagerie vocale VM 25, de Présence PS 26, de Listes de Ressources RLS 27 et de téléphonie TAS 29 sont des exemples de ce que l'on appelle des AS (initiales des mots anglais « Application Servers » signifiant « Serveurs d'Applications »).
Certains services comme ceux du serveur VM 25, du serveur PS 26 et du serveur RLS 27 s'appuient sur la souscription du terminal 10 à des événements prédéterminés. La procédure de souscription initiale du terminal 10 auprès du réseau 1 est normalement exécutée lors du démarrage du terminal (ou d'une application installée sur ce terminal) par l'utilisateur, juste après la procédure d'enregistrement initial. Une procédure de souscription initiale est exécutée pour chaque type d'événement souscrit (par exemple, la souscription initiale aux événements de dépôt/consultation de message est effectuée indépendamment de la souscription initiale aux événements de Présence). Une souscription a une durée limitée dans le temps. Cette durée peut être différente pour chaque type d'événement souscrit, et elle est également indépendante de la durée de bail d'enregistrement. Dans des conditions de fonctionnement normal, le dispositif-client 10 doit renouveler sa, ou ses, souscription(s) automatiquement et périodiquement. Dans le cadre du protocole SIP, les procédures de souscription à des événements utilisent une requête appelée « SUBSCRIBE ».
Le présent mode de réalisation de l'invention peut être décomposé en plusieurs phases :
- la découverte d'une SIP-URI associée à un correspondant, et le stockage de cette SIP-URI comme alias de la tel-URI connue du serveur RLS,
- l'utilisation de cette SIP-URI tant que celle-ci permet de joindre le serveur de Présence de ce correspondant, et
- la suppression de cette SIP-URI lorsqu'elle ne permet plus de joindre le serveur de Présence du correspondant, par exemple lorsque le correspondant change d'opérateur ou de réseau SIP.
La procédure peut ensuite être réitérée : découverte, stockage, utilisation, et ainsi de suite.
Ces différentes phases sont décrites ci-dessous.
La figure 3 illustre, selon un mode de réalisation de l'invention, une procédure de découverte d'une SIP-URI et de stockage de cette SIP-URI comme alias d'une tel-URI.
On suppose ici que, lorsque le serveur RLS 27 d'un utilisateur A, appartenant au réseau IMS 1 souhaite être notifié, pour le compte de celui-ci, des changements de l'état de Présence d'un correspondant externe B appartenant à un réseau SIP externe, le serveur RLS ne connaît initialement que la tel-URI de ce correspondant externe (par exemple tel :+33123456789). Ne connaissant pas le réseau SIP 2 auquel appartient ce correspondant externe B, le serveur RLS 27 envoie sa requête de Présence (SUBSCRIBE) à son réseau IMS 1 , qui se charge ensuite de la router vers le réseau SIP 2 du correspondant B. Cette requête sera alors transmise au serveur de Présence du correspondant B.
La réponse 200 OK indiquant l'acceptation de la souscription et reçue de la part du réseau SIP 2 permet ensuite de récupérer une SIP- URI (par exemple, sip:bob@domaine2) du correspondant externe B ; en effet, l'en-tête SIP appelé « P-Asserted-ldentity » contenu dans cette réponse à la requête SUBSCRIBE permet de véhiculer une SIP-URI identifiant le destinataire B de la requête initiale.
Dans le présent mode de réalisation, cette SIP-URI est alors stockée, dans le serveur RLS 27 de l'utilisateur A ou dans une base de données associée, en tant qu'alias de la tel-URI du correspondant externe B.
II est à noter que d'autres procédures de découverte de SIP-URI peuvent également être utilisées. Le serveur RLS 27 de l'utilisateur A pourrait par exemple s'appuyer sur un routage à base de tranches de numéros de téléphone, semblable au routage effectué dans les réseaux RTCP (Réseaux Téléphoniques Commutés Publics), mais mis ici en œuvre par le cœur du réseau IMS 1 . Le serveur RLS 27 pourrait également récupérer une SIP-URI en interrogeant directement le serveur ENUM (ce qui suppose la mise en place d'une interface non standard). Le serveur RLS 27 pourrait également récupérer une SIP-URI utilisée comme GRUU (initiales des mots anglais « Globally Routable User Agent URI » signifiant « URI Mondialement Routable d'Agent Utilisateur »), telle que définie dans la RFC 5627, qui serait insérée par le serveur de Présence du correspondant externe B dans la réponse 200 OK à la requête SUBSCRIBE.
A chaque fois que, subséquemment, l'application de Présence de l'utilisateur A sera à nouveau lancée, son serveur RLS 27 devra à nouveau demander à être notifié des changements de l'état de Présence du correspondant externe B. Comme illustré sur la figure 4, la deuxième phase du présent mode de réalisation de l'invention consiste à utiliser la SIP-URI précédemment stockée comme alias de la tel-URI de B. La SIP- URI permet d'identifier le réseau SIP hébergeant le correspondant externe B (ici le réseau 2), et permet au serveur RLS 27 de router sa requête vers ce réseau 2, soit directement en utilisant la fonction l-CSCF du réseau 2, soit indirectement en envoyant la requête à une fonction d'interconnexion de type IBCF (initiales des mots anglais « Interconnection Border Control Function » signifiant « Fonction de Contrôle de Frontière d'Interconnexion »). Cette requête sera alors transmise au serveur de Présence du correspondant B.
Ainsi, le serveur RLS 27 de l'utilisateur A n'a pas besoin d'envoyer sa requête au serveur S-CSCF 22 de son propre réseau IMS 1 , ce qui évite d'avoir à invoquer les fonctions de routage du cœur de réseau IMS.
La SIP-URI du correspondant B stockée comme alias est temporaire dans la mesure où elle ne fonctionne qu'aussi longtemps que le correspondant ne change pas de SIP-URI. Si le correspondant change d'opérateur, ou de réseau SIP dépendant du même opérateur, le serveur RLS reçoit un message d'erreur SIP approprié (par exemple un message d'erreur SIP « 404 Not Found ») lui indiquant que la ressource n'a pas pu être trouvée.
La figure 5 illustre ce cas selon un mode de réalisation de l'invention. La SIP-URI sip:bob@domaine2 stockée comme alias de la tel- URI de B ne permet alors plus de joindre le correspondant B puisque celui-ci ne se trouve plus dans le réseau SIP 2, mais dans un réseau SIP 3. Le serveur RLS supprime donc cette SIP-URI, puis il utilise à nouveau la tel-URI du correspondant B pour découvrir la nouvelle SIP-URI sip:bobby@domaine3 à laquelle le correspondant B peut à présent être joint. Ce mécanisme permet notamment de couvrir des situations où un correspondant B changerait d'opérateur ou de fournisseur de service, tout en gardant son numéro de téléphone.
La description ci-dessus d'un mode de réalisation de l'invention a, pour simplifier l'exposé, fait mention d'un unique correspondant B pour un utilisateur A donné. Mais on peut bien sûr aisément généraliser ce mode de réalisation à un ensemble de correspondants de l'utilisateur A, comme illustré sur la figure 1 .
On peut aussi, inversement, mutualiser la mise en œuvre de l'invention pour une pluralité d'utilisateurs A1 , A2, qui partageraient un même serveur RLS 27 et souhaiteraient connaître l'état de Présence d'un même correspondant distant B.
L'invention peut être mise en œuvre au sein des nœuds, par exemple des serveurs RLS, de réseaux SIP, au moyen de composants logiciels et/ou matériels.
Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en œuvre de l'un quelconque des procédés de traitement des flux de Présence selon l'invention.
En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de traitement des flux de Présence selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur.
Ce programme peut utiliser n'importe quel langage de programmation, et se présenter 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" en anglais) 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 d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
En variante, 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 de l'un quelconque des procédés de traitement des flux de Présence selon l'invention.

Claims

R E V E N D I C A T I O N S
1 . Procédé de traitement des flux de Présence dans un réseau SIP, caractérisé en ce que, lorsqu'un utilisateur A appartenant à un premier réseau SIP (1 ) a demandé à être notifié des changements de l'état de Présence d'un correspondant B externe audit premier réseau SIP (1 ) et identifié par une tel-URI contenant son numéro de téléphone, ledit procédé comprend les étapes suivantes :
- identification, dans une base de données contenue dans un serveur RLS (27) du premier réseau SIP (1 ) ou associée audit serveur RLS (27), d'une SIP-URI présumée dudit correspondant B stockée en tant qu'alias de ladite tel-URI, et
- envoi à un deuxième réseau SIP (2) contenant ladite SIP-URI présumée d'une requête de souscription à l'état de Présence du correspondant B.
2. Procédé de traitement des flux de Présence selon la revendication 1 , caractérisé en ce que ledit alias a été obtenu préalablement au moyen des étapes suivantes :
- découverte de la SIP-URI du correspondant B au moyen de ladite tel-URI du correspondant B, et
- stockage dans ladite base de données de cette SIP-URI en tant qu'alias de la tel-URI du correspondant B.
3. Procédé de traitement des flux de Présence selon la revendication 1 ou la revendication 2, caractérisé en ce que, au cas où, en réponse à ladite requête de souscription, ledit serveur RLS (27) reçoit une notification de la part dudit réseau SIP (2) selon laquelle ladite SIP- URI est inconnue, le stockage dans ladite base de données de cette SIP- URI en tant qu'alias de ladite tel-URI du correspondant B est supprimé.
4. Dispositif de traitement des flux de Présence dans un réseau SIP, caractérisé en ce que, lorsqu'un utilisateur A appartenant à un premier réseau SIP (1 ) a demandé à être notifié des changements de l'état de Présence d'un correspondant B externe audit premier réseau SIP (1 ) et identifié par une tel-URI contenant son numéro de téléphone, ledit dispositif comprend des moyens pour :
- identifier, dans une base de données contenue dans un serveur
RLS (27) du premier réseau SIP (1 ) ou associée audit serveur RLS (27), une SIP-URI présumée dudit correspondant B stockée en tant qu'alias de ladite tel-URI, et
- envoyer à un deuxième réseau SIP (2) contenant ladite SIP-URI présumée une requête de souscription à l'état de Présence du correspondant B.
5. Dispositif de traitement des flux de Présence selon la revendication 4, caractérisé en ce que, pour obtenir ledit alias, ledit dispositif comprend des moyens pour :
- découvrir la SIP-URI du correspondant B au moyen de ladite tel-
URI du correspondant B, et
- stocker dans ladite base de données cette SIP-URI en tant qu'alias de la tel-URI du correspondant B.
6. Dispositif de traitement des flux de Présence selon la revendication 4 ou la revendication 5, caractérisé en ce que, au cas où, en réponse à ladite requête de souscription, ledit serveur RLS (27) reçoit une notification de la part dudit réseau SIP (2) selon laquelle ladite SIP- URI est inconnue, ledit dispositif comprend des moyens pour supprimer dans ladite base de données le stockage de cette SIP-URI en tant qu'alias de ladite tel-URI du correspondant B.
7. Serveur RLS (27), caractérisé en ce qu'il comprend un dispositif selon l'une quelconque des revendications 4 à 6.
8. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de traitement des flux de Présence selon l'une quelconque des revendications 1 à 3.
9. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de traitement des flux de Présence selon l'une quelconque des revendications 1 à 3, lorsqu'il est exécuté sur un ordinateur.
PCT/FR2011/052332 2010-10-12 2011-10-06 Procede de traitement des flux de presence dans un reseau sip WO2012049404A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1058289 2010-10-12
FR1058289A FR2965999A1 (fr) 2010-10-12 2010-10-12 Procede de traitement des flux de presence dans un reseau sip

Publications (1)

Publication Number Publication Date
WO2012049404A1 true WO2012049404A1 (fr) 2012-04-19

Family

ID=44009929

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2011/052332 WO2012049404A1 (fr) 2010-10-12 2011-10-06 Procede de traitement des flux de presence dans un reseau sip

Country Status (2)

Country Link
FR (1) FR2965999A1 (fr)
WO (1) WO2012049404A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008041830A1 (fr) * 2006-10-03 2008-04-10 Samsung Electronics Co., Ltd. Systèmes et procédés pour fournir une règle de notification concernant le serveur de listes de ressources pour plusieurs parties de présence

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008041830A1 (fr) * 2006-10-03 2008-04-10 Samsung Electronics Co., Ltd. Systèmes et procédés pour fournir une règle de notification concernant le serveur de listes de ressources pour plusieurs parties de présence

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HOURI IBM E AOKI AOL LLC S PARAMESWAR T RANG MICROSOFT CORPORATION V SINGH H SCHULZRINNE COLUMBIA U A: "Presence Interdomain Scaling Analysis for SIP/SIMPLE; draft-ietf-simple-interdomain-scaling-analysis-08.txt", PRESENCE INTERDOMAIN SCALING ANALYSIS FOR SIP/SIMPLE; DRAFT-IETF-SIMPLE-INTERDOMAIN-SCALING-ANALYSIS-08.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, vol. simple, no. 8, 27 August 2009 (2009-08-27), XP015063989 *

Also Published As

Publication number Publication date
FR2965999A1 (fr) 2012-04-13

Similar Documents

Publication Publication Date Title
EP3085065B1 (fr) Procédé de mise a jour dynamique d'informations obtenues de la part d'un serveur dns
EP2504982B1 (fr) Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
EP2386169B1 (fr) Procédé et système de regulation du trafic de redémarrage dans un réseau de télécommunications
EP2449745A1 (fr) Procede de selection d'une ressource reseau
EP2396950A1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP3158709A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
WO2020128258A1 (fr) Procédé de basculement d'une communication de tcp sur udp
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP3472993B1 (fr) Procédé de détermination d'un ensemble de formats de codage pour établir une communication
WO2012085429A2 (fr) Procédé de localisation et d'identification d'un abonné connecté à un réseau émulant le rtc/rnis
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
EP3646578B1 (fr) Procédé de synchronisation d'état média
EP3583757B1 (fr) Procédé de changement de réseau mobile
WO2015181505A1 (fr) Procédé pour informer une entité d'un réseau ip du type de réseau d'accès utilisé par un terminal
FR3004612A1 (fr) Procede de restauration de service dans un reseau ims
WO2018215719A1 (fr) Procédé de contrôle d'une communication comprenant des transactions multiples
WO2018150150A1 (fr) Procédé de changement de réseau mobile
WO2012117178A1 (fr) Procédé de gestion d'identites publiques par un utilisateur d'un reseau ims

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

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

Country of ref document: EP

Kind code of ref document: A1